UNIVERSIDADE FEDERAL DE PELOTAS
Centro de Desenvolvimento Tecnológico
Programa de Pós-Graduação em Computação
Dissertação
Engenharia de Requisitos Baseada em Modelos para o Domínio de Software Embarcado
Milena Rota Sena Marques
Milena Rota Sena Marques
Engenharia de Requisitos Baseada em Modelos para o Domínio de Software Embarcado
PELOTAS 2013
Dissertação de mestrado apresentada ao Programa de Pós-Graduação em Computação da Universidade Federal de Pelotas, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação.
Dados Internacionais de Publicação (CIP)
M357e Marques, Milena Rota Sena
Engenharia de requisitos baseada em modelos para o domínio de software embarcado / Milena Rota Sena Marques; Lisane Brisolara de Brisolara, orientador. – Pelotas, 2013.
74 f.: il.
Dissertação (Mestrado em Computação), Centro de Desenvolvimento Tecnológico, Universidade Federal de Pelotas. Pelotas, 2013.
1.Software embarcado. 2.Engenharia de requisitos. 3.rastreabilidade. 4.SysML. 5.MARTE. 6.UML. I. Brisolara, Lisane Brisolara de, orient. II. Título.
CDD: 005.1
Catalogação na Fonte: Leda Cristina Peres Lopes CRB:10/2064 Universidade Federal de Pelotas
Banca examinadora:
... Profa. Dra. Lisane Brisolara de Brisolara (Orientadora)
... Profa. Dra. Erika Fernandes Cota
... Prof. Dr. Júlio C. B. Mattos
... Prof. Dr. Rafael Iankowski Soares
AGRADECIMENTOS
A conclusão desta dissertação finaliza uma etapa muito importante da minha vida. Gostaria de agradecer a todos as pessoas que estiveram envolvidas, direta ou indiretamente, durante este período, porém, esta é uma tarefa difícil e pode ser injusta.
Primeiramente, gostaria de agradecer ao programa de pós-graduação da UFPel, por proporcionar esta evolução profissional na minha vida. Aos professores do curso de pós-graduação em computação pelos ensinamentos ao longo do curso e amizade construída.
Neste período, também, o convivi com os colegas de pesquisa do GACI (Grupo de Arquitetura e Circuitos Integrados) e gostaria de agradecer ao aprendizado diário com todos, ao acolhimento, pelas conversas descontraídas, churrascos e, principalmente, pela amizade resultante desse convívio.
Agradecimento especial a minha colega Eliane Siegert que participou ativamente do desenvolvimento deste trabalho, ajudando em diversas tarefas.
Dedico outro agradecimento especial, a minha orientadora, Lisane Brisolara que além de minha orientadora, é uma grande amiga e foi extremamente importante para o meu crescimento como aluna, pessoa e pesquisadora. Este ciclo finaliza e nossa amizade fica mais fortalecida.
Muito obrigada por toda a compreensão dos meus amores, Felipe e Clara. Ao Felipe por me propor desafios que me fortalecem pessoalmente e profissionalmente, pelo carinho e dedicação a nossa família. E a minha pequena, Clara, sempre me fez sorrir nos momentos mais difíceis, me mostrando a inocência de ser criança em contra ponto com as dificuldades impostas pelos adultos.
Agradeço a minha Mãe, Mano, Lulu, Camila, Helena, muito obrigada por entenderem minha ausência, do convívio familiar, neste período árduo. Ao meu Pai.
Não poderia deixar de agradecer a Maria. Obrigada Maria, por me permitir sair de casa tranquila.
A finalização deste ciclo, com pessoas tão importantes ao meu lado, me dá coragem para seguir em frente.
“A vida não basta ser vivida, deve ser sonhada”. Mario Quintana
RESUMO
MARQUES, Milena Rota Sena A. Engenharia de Requisitos Baseadas em Modelos para o Domínio de Software Embarcado. 2013. 74f. Trabalho acadêmico (Mestrado) – Pós-Graduação em Ciência da Computação. Universidade Federal de Pelotas, Pelotas.
O projeto de Sistemas Embarcados envolve alta complexidade, pois inclui hardware, software e muitos requisitos tanto funcionais como não funcionais. Todos estes requisitos devem ser considerados durante todo o projeto, sendo devidamente especificados e gerenciados. Para lidar com esta complexidade, modelos descritos em linguagens de modelagem com alto poder de abstração, como UML, são adotados. No entanto, UML não permite representar requisitos não funcionais e relacionamentos entre requisitos, assim a gerência de requisitos não é suportada por abordagens baseadas em UML. O objetivo deste trabalho é apresentar a abordagem MDEReq, que propõe uma engenharia de requisitos orientada a modelos para o domínio de software embarcado. Esta abordagem suporta rastreabilidade de requisitos, que permite gerenciar requisitos desde a especificação até a validação. Para suportar a completa especificação dos requisitos, diagramas UML decorados com estereótipos do perfil MARTE são usados, enquanto a rastreabilidade é suportada pelo uso de notações SysML. Estes modelos são integrados, facilitando a rastreabilidade dos requisitos em todas as fases do projeto, além de permitir que uma única ferramenta possa ser utilizada para a modelagem de todo o projeto e para a gestão de requisitos. Um estudo de caso é usado para demonstrar a abordagem proposta.
Palavras-chave: Software Embarcado, Engenharia de Requisitos, baseada em modelos, SysML, MARTE, UML, Gerência de Requisitos, Rastreabilidade.
ABSTRACT
MARQUES, Milena Rota Sena A. Engenharia de Requisitos Baseadas em Modelos para o Domínio de Software Embarcado. 2013. 74f. Trabalho acadêmico (Mestrado) – Pós-Graduação em Ciência da Computação. Universidade Federal de Pelotas, Pelotas.
The design of an Embedded System has high complexity. It includes hardware, software and several functional or non-functional requirements. All requirements have to be well specified and managed during the whole project. In order to handle this complexity, description models are created using modeling languages such as UML. However, UML is neither able to represent non-functional requirements nor relationship between requirements. Therefore, management requirements are not supported on UML based approaches. The main objective of this work is to introduce a MDEReq approach that presents a model driven engineering requirements applied to embedded software. This approach provides requirements traceability that allows management of requirements from the specification to the validation. To support the complete requirement specification, UML diagrams are decorated with stereotypes of the MARTE profile, while the traceability is supported through the use of SysML notations. These models are integrated to ease the requirements traceability in all steps of the project. Furthermore, it allows the usage of a single tool for both design modeling and management requirements. One case study is used to demonstrate our approach.
Keywords: Embedded Software, Requirement Engineering, model-driven, SysML, MARTE, UML, requirement management, rastreability.
LISTA DE FIGURAS
Figura 1 – Níveis de abstração no processo do projeto de SE... 19
Figura 2 – Diagramas da UML2 ... 22
Figura 3 – Sobreposição entre a UML 2.0 e a SysML ... 25
Figura 4 - Diagrama da Linguagem SysML ... 26
Figura 5 – Pacote RTEM (OMG, 2011b) ... 33
Figura 6 – Modelo de Processo de Software Tradicional ... 36
Figura 7 – Fluxo abordagem MDEReq ... 50
Figura 8 – Componentes do Freio ABS. ... 56
Figura 9 – Diagrama de Requisitos – Atividade de Levantamento ... 58
Figura 10 – Diagrama de Casos de Uso do sistema de freio ABS ... 59
Figura 11 – Diagrama de Classes do sistema de freio ABS ... 60
Figura 12 – Diagrama de Sequência do caso de uso “Calcular pressão”... 61
Figura 13 – Diagrama de Sequência do caso de uso “Ler Sensor” ... 62
Figura 14 – Diagrama de Requisitos – Atividade de Análise e Especificação ... 63
Figura 15 – Diagrama de Requisitos – Atividade de Validação ... 64
Figura 16 – Matriz de rastreabilidade de requisitos ... 65
Figura 17 – Matriz de Rastreabilidade de Artefatos do Projeto ... 66
LISTA DE TABELAS
Tabela 1 – Relacionamentos disponíveis na SysML ... 29 Tabela 2 – Categorias de estereótipos para <<requirement>>. ... 30 Tabela 3 – Matrizes propostas pela MDEReq ... 53 Tabela 4 – Listagem e Classificação dos requisitos para a modelagem do sistema de
LISTA DE ABREVIATURAS E SIGLAS
ABS Anti-lock Braking System
Alloc Allocation Modeling
CCSL Clock Constraint Specification Language DRM Detail Resource Modeling
GCM Generic Component Model GPS Global Positioning System GQAM
GRM
Generic Quantitative Analysis Modeling Generic Resource Modeling
HLAM High-Level Application Modeling HRM Hardware Resource Modeling
MARTE Modeling and Analysis of Real-time and Embedded System MDE Model Driven Engineering
MDEReq Model Driven Engineering for Requirement Management MPSoC Multiprocessor System-on-chip
NFP Non-Functional Properties Modeling OMG Object Management Group
PAM Performance Analysis Modeling RPM Requirement Profile Memvatex RSM Repetitive Structure Modeling SAM Schedulability Analysis Modeling
SE RFP System Engineering Request for Proposal SOC System-on-a-chip
SPT Schedulability, Performance and Time Specification SRM Software Resource Modeling
SysML Systems Modeling Language
UML Unified Modeling Language UTP UML Testing Profile
INDICE 1 INTRODUÇÃO ... 13 1.1 Motivação ... 15 1.2 Objetivos... 16 1.3 Organização do Trabalho ... 17 2 Fundamentação Teórica ... 18 2.1 Sistemas Embarcados ... 18 2.2 Linguagens de Modelagem ... 21 2.2.1 UML ...21 2.2.2 SysML ... 25 2.2.2.1 Diagrama de Requisitos ... 28 2.2.2.2 Diagrama Paramétrico ... 31 2.2.3 MARTE ... 32 2.2.4 Discussão ... 34 2.3 Engenharia de Software ... 35 2.3.1 Engenharia de Requisitos ... 37
2.3.2 Engenharia Dirigida a Modelos ... 40
3 TRABALHOS RELACIONADOS ... 42
3.1 Especificação baseada em modelos ... 42
3.2 Gestão dos requisitos ... 44
4 Abordagem proposta ... 48
5.1 Visão geral do freio ABS ... 55
5.2 Modelagem do controle do freio ABS ... 56
5.2.1 Levantamento ... 56
5.2.2 Análise e Especificação ... 58
5.2.3 Validação ... 63
5.2.4 Gerência de Requisitos... 64
6 CONCLUSÕES E TRABALHOS FUTUROS ... 67
7 Referências ... 69
1 INTRODUÇÃO
Devido ao avanço tecnológico grande parte das tarefas executadas por seres humanos são auxiliadas por computadores. Nesse pressuposto, sistemas computacionais embarcados estão presentes em diversas atividades, por exemplo, uso de mp3, telefone celular, GPS entre outros equipamentos eletrônicos. Estes sistemas são dedicados por possuírem uma funcionalidade restrita para atender uma tarefa específica em sistemas maiores nos quais estão inseridos (MARWEDEL, 2006). Estes sistemas são naturalmente heterogêneos, envolvendo diferentes modelos de computação (LEE e SESHIA, 2011) e sendo usualmente constituídos de componentes de hardware e de software (BRISOLARA, 2009).
O projeto de desenvolvimento de softwares embarcados é distinto do desenvolvimento de softwares de propósito geral. Os primeiros possuem requisitos extremamente relevantes como: consumo de potência e energia, desempenho, tamanho, peso, memória, restrições de tempo, custo de projeto, entre outras. Um software é dito embarcado quando é projetado para executar em um sistema embarcado. Todos estes aspectos, aliados à sofisticação crescente dos produtos e o curto período para lançamento dos mesmos, aumentam a complexidade envolvida no projeto.
Para lidar com projetos complexos, linguagens de alto nível de abstração têm sido utilizadas. A abstração é um mecanismo fundamental que possibilita, aos projetistas de software, extrair características essenciais de um problema complexo, com a finalidade de reduzir a complexidade e aumentar a produtividade (PASSERONE, HAFAIEDH, et al., 2009). Dentre essas linguagens, destaca-se a UML (Unified Modeling Language) considerada padrão para modelagem de software. Os avanços no uso de modelos motivaram a definição de abordagens de engenharia dirigida por modelos, conhecidas como MDE (do inglês, Model-driven Engineering).
14
A UML é uma linguagem genérica que pode ser utilizada para modelar diferentes tipos de sistemas. No entanto, a generalidade faz com que a UML não suporte a modelagem de alguns aspectos específicos em um determinado domínio de aplicação, motivando a definição de linguagens de domínio específico.
Para atender esta demanda, a UML oferece mecanismos de extensão através da criação de perfis específicos para um dado domínio de aplicação. No domínio de sistemas embarcados, o suporte à descrição de comportamentos heterogêneos (hardware/software e diferentes modelos de computação) e a especificação de requisitos não funcionais são exemplos de necessidades específicas do domínio. Dentre as extensões propostas pela OMG (Object Management Group) (OMG, 2011a), com enfoque no domínio de embarcados, destaca-se o perfil MARTE (Modeling and Analysis of Real-time and Embedded System) (OMG, 2011b). O MARTE suporta a modelagem e análise de sistemas embarcados e de tempo real, contribuindo principalmente com a modelagem de requisitos não funcionais. No entanto, estes requisitos não funcionais são aspectos transversais que influenciam vários artefatos do software e várias atividades do processo de desenvolvimento (AMELLER, AYALA e J. CABOT, 2012), o que indica a necessidade de um procedimento que permita além da modelagem, a completa gerência destes requisitos.
No domínio da Engenharia de Software, a engenharia de requisitos define um caminho desde o levantamento dos requisitos até a verificação/validação do software, incluindo a gestão dos requisitos durante todas as fases do projeto (PRESSMAN, 2011). A gestão de requisitos ajuda a equipe de projeto a identificar, controlar e acompanhar as necessidades e suas mudanças a qualquer momento do projeto. Para a gestão, a rastreabilidade de requisitos é uma necessidade, a qual implica em estabelecer um relacionamento claro entre os requisitos e artefatos do projeto como casos de uso, componentes e casos de teste. A linguagem SysML (OMG, 2012), outra extensão da UML, oferece recursos para a modelagem de requisitos e relacionamentos entre eles e por esta razão vem sendo também aplicada no domínio de sistemas embarcados.
Embora existam algumas abordagens baseadas em modelos para engenharia de software embarcado (ALBINET, BEGOC, et al., 2008) (DUBOIS, PERALDI-FRATI e LAKHAL, 2010), poucas oferecem suporte à gerência de requisitos. Além disso, usualmente estas abordagens propõem extensões das
linguagens de modelagem padrão e focam em um subdomínio específico dos sistemas embarcados, dificultando o seu uso em qualquer aplicação de software embarcado.
O objetivo deste trabalho é apresentar a MDEReq (do inglês, Model Driven Engineering for Requirement Management), uma abordagem para engenharia de requisitos orientada a modelos no domínio de software embarcado focada na modelagem e gerência de requisitos. Os modelos usados nesta abordagem são baseados em padrões e, portanto facilmente compreendidos e suportados pelas ferramentas de modelagem já disponíveis. A linguagem UML é usada como a linguagem principal, mas os modelos UML são decorados com estereótipos do MARTE para suportar a modelagem de requisitos não funcionais (temporais, de confiabilidade, consumo, etc). Nesta abordagem, a gerência de requisitos é focada na técnica de rastreabilidade de requisitos. Para suportar esta técnica, o modelo UML é integrado a notações da SysML que permitem representar relacionamentos entre requisitos e outros elementos do modelo. Estes modelos são integrados permitindo a completa modelagem do sistema usando uma única ferramenta de modelagem e facilitando a rastreabilidade dos requisitos em todas as fases do projeto.
1.1 Motivação
A complexidade dos sistemas embarcados aliada à relevância dos requisitos não funcionais no desenvolvimento do software embarcado, motiva o estudo de abordagens de modelagem que suportem a especificação tanto de requisitos funcionais como não funcionais. Estes requisitos não funcionais devem ser devidamente anotados e ao término deve-se assegurar que a solução atende estes requisitos.
Além disso, os requisitos não funcionais afetam decisões de projeto e, portanto devem ser gerenciados, de forma que quando uma mudança em um determinado requisito é realizada, facilmente sejam identificados quais artefatos devem ser revisados. A rastreabilidade de requisitos, uma técnica de gestão de requisitos, pode ser vista como a habilidade de acompanhar e descrever a vida de um requisito (HAZAN e LEITE, 2003) e que, quando aplicada evita, requisitos
16
duplicados e, até mesmo, requisitos com descrições errôneas, pois a gerência torna esses erros evidentes (KRÜGER, FARCAS, et al., 2007). A rastreabilidade é uma necessidade da equipe de software e implica em estabelecer um relacionamento claro entre os requisitos em diferentes níveis do fluxo de modelagem (DUBOIS, PERALDI-FRATI e LAKHAL, 2010). A gerência de requisitos é uma das atividades da engenharia de requisitos, processo bem conhecido no domínio de engenharia de software, mas que muitas vezes não é aplicada por engenheiros de software embarcado, ou ainda é realizada de forma manual ou com base em especificações textuais.
A linguagem SysML oferece recursos de modelagem que facilitam a rastreabilidade de requisitos, além de suportar a representação de requisitos funcionais e não funcionais para sistemas genéricos. No entanto, para a completa especificação de requisitos do domínio de sistemas embarcados, o emprego do perfil MARTE também é necessário de forma a dar suporte à modelagem de requisitos não funcionais específicos deste domínio. Como por exemplo, no sistema de controle de uma cadeira de rodas automática ou do freio ABS de um automóvel, onde é necessário representar os requisitos temporais associados a estes sistemas. No caso do freio ABS, devem ser definidos o tempo limite para que o ABS seja ativado e o tempo de leitura dos sensores, já para a cadeira de rodas deve ser definida a periodicidade da leitura dos comandos enviados via joystick.
Algumas abordagens podem ser encontradas que combinam UML, MARTE e SysML para engenharia de requisitos no domínio de embarcados. No entanto, estas abordagens usualmente focam em algum subdomínio de embarcados e estendem as notações existentes para alguma área específica. A motivação deste trabalho é propor uma abordagem para engenharia de requisitos que utilize apenas notações padronizadas e já suportadas por ferramentas de modelagem disponíveis e que suporte tanto a especificação quanto a gerência de requisitos.
1.2 Objetivos
O Objetivo deste trabalho é propor uma abordagem baseada em modelos para o desenvolvimento de software embarcado. A abordagem proposta se baseia em notações padronizadas e permite modelar tanto requisitos funcionais como não funcionais, além dos relacionamentos entre os requisitos. Desta forma, esta abordagem incorpora atividades da engenharia de requisitos ao processo de
desenvolvimento de software embarcado, garantindo uma maior qualidade no processo de desenvolvimento.
1.3 Organização do Trabalho
Este trabalho divide-se em seis capítulos. O segundo capítulo apresenta a fundamentação teórica relacionada a esta dissertação, incluindo conceitos básicos do domínio de sistemas embarcados, revisão das linguagens de modelagem e do processo de engenharia de requisitos. Já no terceiro capítulo são apresentados os trabalhos relacionados com esta dissertação. No quarto capítulo é apresentada a abordagem proposta para engenharia de requisitos baseada em modelos para o domínio de software embarcado. No capítulo cinco, um estudo de caso é usado para demonstrar a abordagem proposta. Logo após, no capítulo seis, as conclusões são discutidas e trabalhos futuros são elencados.
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo tem por objetivo apresentar a fundamentação teórica necessária para compreensão do trabalho. Esta fundamentação envolve conceitos e práticas de duas áreas da ciência da computação, “Engenharia de Software” e “Sistemas Embarcados”, que são integradas neste trabalho. Na seção 2.1 é apresentado o domínio de sistemas embarcados, enquanto na seção 2.2, é realizada uma revisão das linguagens de modelagem usadas para este domínio. Já a revisão da área de Engenharia de Software é apresentada na seção 2.3, incluindo conceitos específicos e a revisão de abordagens como Engenharia de Requisitos e Engenharia orientada a modelos, ambas usadas como base para esta dissertação.
2.1 Sistemas Embarcados
Sistemas embarcados são sistemas dedicados que possuem uma funcionalidade restrita para atender uma tarefa específica em sistemas maiores nos quais estão inseridos (MARWEDEL, 2006). Usualmente, sistemas embarcados são heterogêneos por envolverem software, hardware (MATTOS e BRISOLARA, 2009) e diferentes modelos de computação, o que dificulta o projeto dos mesmos.
As aplicações de computação embarcada estão incorporadas em muitos domínios de aplicação tais como: eletrônica automotiva, eletrônica de aeronaves, sistemas de telecomunicação, eletrônica de consumo, equipamentos médicos, aplicações militares, entre outros. Estas aplicações possuem características que as diferem dos demais sistemas e que devem ser consideradas no desenvolvimento de um sistema embarcado. Dentre estas características, destacam-se: sistemas dedicados, sistemas reativos, confiabilidade, restrições de tempo real, tamanho do código, desempenho, baixo consumo de potência e energia, além de restrições
físicas (tamanho e peso). Estas restrições aliadas à funcionalidade complexa das aplicações aumentam a complexidade do projeto destes sistemas.
Para lidar com essa complexidade, são utilizadas linguagens de modelagem (ou de especificação) de alto nível de abstração na construção de um sistema embarcado. Sendo assim, o projeto de um sistema embarcado parte de uma visão abstrata que ao longo do desenvolvimento é refinada até o produto ser finalizado, seguindo um fluxo de projeto top-down.
A Figura 1 ilustra etapas envolvidas em um fluxo de projeto de um sistema embarcado, bem como os níveis de abstração usados em cada etapa (WOLF, 2008). A primeira etapa deste fluxo é Análise de Requisitos, na qual é realizada a definição dos requisitos do sistema. Na etapa seguinte, é realizado o detalhamento destes requisitos, gerando a Especificação do sistema. A partir desta especificação, é gerada a Arquitetura do sistema através do detalhamento de quais componentes farão parte do sistema. Após a definição da arquitetura, é realizado o projeto dos componentes e por fim, a integração dos componentes e a validação do sistema.
20
O fluxo da Figura 1 considera o projeto de sistemas embarcados no nível de sistema, que pode incluir componentes de software e hardware. As abordagens baseadas neste fluxo podem ser usadas tanto para o projeto de hardware quanto de software. Tradicionalmente, duas abordagens podem ser adotadas para o desenvolvimento de sistemas: a abordagem top-down e a abordagem bottom-up. Na abordagem top-down, o projeto se inicia com uma visão mais abstrata e através de refinamentos sucessivos obtém-se o sistema propriamente dito. Já na abordagem bottom-up, o projeto é iniciado com uma descrição em nível de componentes e a partir destes componentes constrói-se o sistema completo. Em projetos reais são utilizadas as duas abordagens. A abordagem bottom-up permite tomar decisões quanto ao custo dos componentes. Por exemplo, para a decisão de qual será a melhor arquitetura para o sistema. Por outro lado, uma abordagem top-down lida melhor com projetos complexos. Quando um misto das duas abordagens é usado, as decisões críticas podem ser tomadas a tempo, evitando o retrabalho (WOLF, 2008).
O projeto de qualquer sistema inicia com a captura de informações e necessidades a serem atendidas pelo sistema a ser desenvolvido. Nesta etapa, são levantados os requisitos obtidos a partir do conhecimento do cliente e refinados para uma especificação que contém informações suficientes para o inicio do projeto da arquitetura do sistema. Estes requisitos podem ser funcionais ou não funcionais. Requisitos funcionais descrevem as funcionalidades que se espera que o sistema disponibilize, de forma completa e consistente. Já os requisitos não funcionais mapeiam os aspectos qualitativos de um sistema, como: desempenho, portabilidade, consumo energético, consumo de potência, características físicas (tamanho e peso). No domínio de software embarcado, onde muitas aplicações são de tempo-real, ou ainda possuem limitações quanto a recursos de hardware (bateria, memória, entre outros), os requisitos não funcionais representam restrições rígidas.
Usualmente, esta primeira definição dos requisitos é feita de forma textual. A partir desta, é construída a especificação do sistema e após, os detalhamentos da arquitetura, onde um rigor e formalismo são exigidos para evitar ambiguidades. As linguagens de modelagem como UML têm sido empregadas de forma que os requisitos sejam modelados desde os primeiros níveis de abstração.
O foco deste trabalho é no software embarcado, que é o software que executará em um sistema embarcado. Este software pode ser dividido em software
básico (sistema operacional) e software aplicativo. Como o sistema operacional não costuma ser projetado de forma totalmente customizada, o foco deste trabalho é na engenharia de software aplicativo. Muitas das restrições de projeto citadas anteriormente como desempenho, consumo, tamanho de memória também são restrições para os engenheiros de software embarcado e devem ser devidamente consideradas no processo de engenharia.
2.2 Linguagens de Modelagem
Esta seção tem por objetivo apresentar as principais linguagens de modelagem utilizadas durante o projeto de um sistema embarcado. O foco neste trabalho é em linguagens que oferecem notações gráficas, visto que modelos gráficos facilitam discussões sobre a solução do problema, podem ser usados para guiar a construção do sistema e documentar as decisões tomadas ao longo do desenvolvimento do projeto. Esta revisão também foca-se em linguagens consideradas como padrões na área. Neste contexto, primeiramente, é apresentada a linguagem UML, linguagem padrão para a modelagem de software de propósito geral. Logo após, são apresentadas, SysML e MARTE, extensões da UML utilizadas no projeto de software embarcado.
2.2.1 UML
A UML (Unified Modeling Language) é uma linguagem padrão para visualizar, especificar, construir e documentar artefatos de um sistema de informação (OMG, 2011a). A UML destaca-se, por ser uma linguagem padrão para modelagem de software orientado a objetos. Esta linguagem proporciona ao usuário visões de alto nível de abstração do sistema, que são estabelecidas através do conjunto de diagramas oferecidos pela linguagem.
Este padrão evoluiu desde a sua criação e atualmente encontra-se na versão 2.3, sendo que a maior evolução ocorreu na definição da UML2. A UML2 suporta 13 diagramas, conforme ilustrado na Figura 2. Estes são divididos em duas categorias: Diagramas Estruturais (diagrama de classe, diagrama de componente, diagrama de objetos, diagrama de estrutura, diagrama de implantação, diagrama de pacotes) e Diagramas Comportamentais (diagrama de atividades, diagrama de casos de uso, diagrama de máquina de estados, diagrama de sequência, diagrama
22
de temporização, diagrama de visão geral de interação e diagrama de comunicação).
Figura 2 – Diagramas da UML2 (OMG, 2011a)
Segundo Fowler (2005), a visão estrutural do sistema se dá a partir dos seguintes diagramas:
Diagrama de Classe: é um dos artefatos da UML para representar o modelo de negócio, onde os principias conceitos da aplicação são representados por classes. Este diagrama descreve os tipos de objetos presentes no sistema e os vários tipos de relacionamentos estáticos entre eles. O diagrama de classes também representa as propriedades, as operações de uma classe e as restrições que se aplicam à maneira como os objetos estão conectados. Este é o principal diagrama da visão estrutural do sistema.
Diagrama de Componentes: representa os vários componentes de software de um sistema, além das dependências entre eles.
Diagrama de Objetos: representa os objetos do sistema (instâncias das classes) existentes em um determinado momento. Este diagrama
oferece uma visão estrutural do sistema complementar ao diagrama de classes.
Diagrama de Estrutura: utilizado para representar uma estrutura composta, ou seja, um conjunto de elementos interconectados que colaboram em tempo de execução, por exemplo, a estrutura interna de uma classe. Este diagrama também provê uma visão estrutural do sistema complementar ao diagrama de classe.
Diagrama de Implantação: modela a arquitetura do sistema em tempo de execução, podendo representar a plataforma de hardware, artefatos de software (código fonte, condigo binário, código executável) e ambiente de execução. Este diagrama proporciona a visão da estrutura física do sistema.
Diagrama de Pacotes: representa os pacotes e suas dependências. Este diagrama é útil em sistemas de grande porte, para obter uma visão das dependências entre os principais elementos de um sistema. Uma visão lógica dos artefatos do projeto e de sua organização é provida por este diagrama.
Já para a representação do comportamento do sistema, segundo Fowler (2005), podem ser adotados os diagramas classificados como comportamentais na Figura 2. Estes diagramas podem ser combinados, visto que representam diferentes aspectos do comportamento de um sistema.
Diagrama de Atividade: é uma técnica para descrever a lógica de procedimento, processo de negócio e o fluxo de trabalho. Esse diagrama é similar a um fluxograma, podendo representar ações sequenciais, concorrentes ou ainda fluxos condicionais. Pode ser usado para detalhar casos de uso ou até o comportamento de classes. Diagrama de Casos de Uso: é uma técnica utilizada para capturar os requisitos funcionais de um sistema. Este diagrama possibilita descrever as interações típicas entre os usuários de um sistema e o próprio sistema, proporcionando uma visão funcional do sistema.
Diagrama de Máquina de Estados: representa o estado que um objeto pode assumir durante a execução de um sistema e também pode ser
24
usado para representar o comportamento de um sistema orientado a controle.
Diagrama de Visão Geral de Interação: é uma variação do diagrama de atividades, onde, os nodos são frames que podem encapsular interações, podendo representar um fluxo de controle de interações, pois permite conectar várias interações descritas em outro diagrama. Diagrama de Sequência: captura a sequencia de processos. Este
diagrama é usado para representar a interação ou a troca de mensagens entre os objetos e indica a ordem com que as interações devem ocorrer. Este diagrama pode ser usado para detalhar um caso de uso, em um nível de detalhe bem próximo à implementação.
Diagrama de Temporização: é utilizado para representar o comportamento de um ou mais objeto em um dado instante de tempo. Diagrama de Comunicação: mostra de maneira semelhante ao
diagrama de sequencia, a colaboração dinâmica entre os objetos, porém, sem a obrigação de indicar a ordem de envio das mensagens. Desta forma, se a ênfase do diagrama for o decorrer do tempo, a melhor escolha é o diagrama de sequencia, mas se a ênfase for o contexto do sistema, vale priorizar o diagrama de comunicação.
A UML, por ser um padrão já consolidado na área de Engenharia de software, é suportada por uma diversidade de ferramentas comercias, acadêmicas e de código aberto. A linguagem UML define notações, mas não define uma metodologia, embora ela se adequa melhor ao desenvolvimento orientado a objetos. Além disso, esta linguagem foi proposta como uma linguagem genérica que pode ser empregada para modelar diferentes tipos de sistemas.
No entanto, a generalidade faz com que a UML não suporte a modelagem de alguns aspectos específicos de um determinado domínio de aplicação, como por exemplo, aspectos relacionados à temporização, frequentes nas aplicações embarcadas e de tempo real. No entanto, uma das vantagens da UML são os mecanismos de extensão, que permitem a criação de perfis específicos para um dado domínio. Um perfil é um mecanismo padronizado pela OMG para criação de linguagens de modelagem de domínio específico, onde conceitos existentes na linguagem padrão podem ser redefinidos.
No domínio de sistemas embarcados, o suporte à descrição de comportamentos heterogêneos (hardware/software e diferentes modelos de computação) e a especificação de requisitos não funcionais são exemplos de necessidades específicas do domínio. Para modelar esses aspectos, de sistemas embarcados, tem-se utilizado a combinação do perfil MARTE com a linguagem de modelagem SysML. Ambos serão detalhados nas próximas seções.
2.2.2 SysML
A SysML (System Modeling Language) é uma linguagem de modelagem de propósito geral aplicada a área de engenharia de sistemas que suporta especificação, análise, projeto, verificação e validação de sistemas complexos (OMG, 2012). Estes sistemas podem incluir hardware, software, dados, processos, pessoas e infra-estrutura (OMG, 2012). A intenção da SysML é unificar as várias linguagens de modelagens, ferramentas e técnicas que são utilizadas nos projetos de desenvolvimento de sistemas.
Como mostra a Figura 3, a SysML reutiliza um subconjunto da UML e adiciona extensões para atender aos requisitos da UML para SE RFP ( Systems Engineering Request for Proposal) (OMG, 2012). O subconjunto da UML reutilizado pela SysML é chamado de UML4SysML. A região marcada com “Perfil SysML” na referida figura define os novos recursos disponíveis no perfil SysML. Enquanto que, a região “UML2” representa a parte da UML que não é utilizada pelo perfil SysML.
26
A SysML reutiliza muitos dos diagramas da UML2. Alguns destes diagramas, como por exemplo, diagrama de casos de uso, de sequência, máquina de estados e diagramas de pacotes são utilizados conforme definidos pela UML. Porém, outros diagramas UML são modificados ou estendidos pela SysML, como é o caso dos diagramas de classe, de estruturas compostas e de atividades. A SysML provê o diagrama de definição de blocos e o diagrama interno de bloco, que são similares ao diagrama de classe e ao diagrama de estrutura compostas da UML. Neste novo padrão o diagrama de atividades é alterado por meio das extensões das atividades. Conforme ilustrado na Figura 4, além de reusar ou modificar diagramas da UML, a SysML também provê novos diagramas como diagrama de requisitos e diagrama paramétrico. Nesta figura, os diagramas são classificados em três classes: comportamentais, estruturais e de requisitos.
Figura 4 - Diagrama da Linguagem SysML (OMG, 2012)
Sem alteração
Alterados a partir da UML 2.0 Novos diagramas Diagramas SysML Diagramas Comportamentais Diagramas de Estrutura Diagrama de Blocos Diagrama de Bloco Interno Diagrama de Pacote Diagrama Paramétrico Diagrama de Requisitos Diagramas SysML Diagramas Comportamentais Diagramas de Estrutura Diagrama de Blocos Diagrama de Bloco Interno Diagrama de Pacote Diagrama Paramétrico Diagrama de Requisitos Diagramas SysML Diagramas de Estrutura Diagrama de Atividade Diagrama de Seqüência Diagrama Máquina Estados Diagrama de Casos de Uso Diagramas Comportamentais Diagrama de Blocos Diagrama de Bloco Interno Diagrama de Pacote Diagrama Paramétrico Diagrama de Requisitos Diagramas SysML Diagramas de Estrutura
Os construtores estruturais definem os elementos estáticos e de estruturas utilizados na SysML. Diagramas que incluem esses construtores são: o diagrama de pacotes, o diagrama de blocos, o diagrama de bloco interno e o diagrama paramétrico. O diagrama de blocos reusa e estende a estrutura de classes da UML2 podendo descrever a estrutura de qualquer elemento do sistema, como: hardware, software, dados, processos. Também é possível descrever as características de bloco, como: propriedades, operações, restrições, alocações, requisitos que o bloco satisfaz; portas e fluxos (provem a semântica para definir como blocos e partes interagem através de portas e como e quais itens fluem através delas); blocos de restrições (definem como os blocos são estendidos para serem usados sobre diagramas paramétricos que modelam a rede de restrições sobre as propriedades de um sistema, para dar suporte a análise de desempenho e outros).
As partes dinâmicas do sistema são especificadas por construções comportamentais providas pelos diagramas de atividade, de sequência, de máquina de estados e de casos de uso. O diagrama de atividades foi estendido e é utilizado para descrever o fluxo de controle e o fluxo de entradas e saídas entre as ações. O diagrama de sequência define construções do tipo interações e são usados para representar comportamento baseado em troca de mensagens. Já o diagrama de máquina de estados é usado para descrever o comportamento de um sistema baseado em seus estados e suas transições. Por fim, o diagrama de casos de uso descreve o comportamento e a utilização de um sistema em termos da sua funcionalidade de alto nível.
Além dos construtores comportamentais e estruturais, a SysML provê construções cruzadas (crosscutting), as quais são aplicadas nas construções estruturais e comportamentais. Essas construções são definidas em: alocações, requisitos (representam as relações que mapeiam um elemento do modelo a outro) e modelos de biblioteca.
Dentre as construções cruzadas estão os requisitos, representado pelo diagrama de requisitos. Este é um novo tipo diagrama provido pela SysML. Este diagrama provê uma visão gráfica dos requisitos e da relação entre os requisitos e entre requisitos e outros elementos do modelo que satisfazem ou verificam tais requisitos. Porém, o detalhamento dos requisitos neste diagrama é baseado em texto. Além dos requisitos, as alocações também são construções cruzadas da SysML, que disponibilizam mecanismos para associação de diferentes tipos de
28
elementos, ou diferentes hierarquias em um mesmo nível de abstração que garantem a eficácia do modelo, uma vez que, estabelecem relacionamentos cruzados que proveem um meio eficaz para a navegação pelo modelo e garante que várias partes do modelo sejam devidamente integradas.
Assim como o diagrama de requisitos, o diagrama paramétrico também é um novo diagrama da SysML. Este diagrama é utilizado para integrar modelos comportamentais e estruturais com modelos de análises de engenharia, tais como desempenho, confiabilidade e modelos de propriedade de massa. Segundo Espinoza, et al., (2009), as contribuições mais relevantes da SysML foram as inclusões dos novos diagramas de requisitos e paramétrico, visto que com esses diagramas, é possível modelar os requisitos e restrições matemáticas do software. Estes diagramas são revisados nas seções 2.2.2.1 e 2.2.2.2.
A utilização de SysML beneficia o desenvolvimento de sistemas complexos. Um dos benefícios se refere à abstração dos detalhes, uma vez que os detalhes dos requisitos são enriquecidos à medida que a modelagem evolui. As linguagens padrão como SysML e UML reduzem ambiguidades e erros, pois proveem notações que minimizam os problemas de interpretação. Além desses benefícios, pode-se destacar a possibilidade de modelar hardware e software, que proporciona a reusabilidade e agilidade no desenvolvimento de sistemas. E por fim, uma das
principais vantagens da SysML em relação a outras linguagens de modelagem de sistema é a possibilidade de representar relacionamentos entre requisitos e outros elementos do modelo, o que facilita a implementação de mecanismos de rastreamento dos requisitos em diferentes níveis de abstração do modelo.
2.2.2.1 Diagrama de Requisitos
Um requisito especifica uma funcionalidade ou condição que deve ser satisfeita pelo sistema, ou seja, uma função que um sistema deve executar ou uma condição de desempenho que um sistema deve alcançar (OMG, 2012). A SysML provê notações de modelagem para representar requisitos baseados em texto e relacioná-los entre si ou com outros elementos do modelo. Os requisitos modelados podem ter três tipos de estrutura: gráfica, tabular ou em estrutura de árvores. Um requisito não está designado a pertencer somente ao diagrama de requisitos. Conforme o nível de detalhamento do modelo e a relação do requisito com outros
elementos do modelo, um requisito pode ser detalhado ou se relacionar com outro diagrama UML.
A definição padrão de um requisito inclui os atributos: identificador único (ID) e texto (TEXT). No diagrama de requisitos, um requisito é representado graficamente por um retângulo com o estereótipo <<requirement>>. Os relacionamentos entre requisitos também são representados graficamente por linhas, usualmente direcionais. A SysML define diversos relacionamentos para permitir a representação de relações entre os requisitos e entre requisitos e outros elementos do modelo. A Tabela 1 elenca e detalha estes relacionamentos, quanto ao estereótipo usado, origem e destino do relacionamento. Com a utilização destes relacionamentos, é possível representar a hierarquia, derivação, satisfação, verificação e refinamento dos requisitos. O relacionamento de satisfação (satisfy) é a dependência entre um requisito e o elemento do modelo que satisfaz este requisito, enquanto a relação de verificação (verify) representa a dependência entre um requisito e um caso de teste. Já o relacionamento de refinamento (refine) pode ser utilizado para descrever como um elemento do modelo ou um conjunto de elementos detalham um requisito. O relacionamento derive indica derivação entre dois requisitos. O relacionamento de cópia (copy) que especifica a dependência entre dois requisitos, o requisito fornecedor e o cliente. O trace tem o propósito de relacionar o requisito com um elemento do modelo.
Tabela 1 – Relacionamentos disponíveis na SysML
Nome Estereótipo Lado sem seta – origem Lado com seta – destino Satisfy <<satisfy>> Requisito satisfeito por
elemento do modelo
Elemento do modelo que satisfaz um requisito
Verify <<verify>> Requisito verificado por elemento do modelo
Elemento do modelo que verifica um requisito
Refine <<refine>> Requisito refinado por um elemento do modelo
Elemento do modelo que refina um requisito
Derive <<derive>> Requisito derivado por um requisito
Requisito que derivado a partir de um requisito base
Copy <<copy>> Requisito cópia de um requisito
Requisito que é cópia a partir de um requisito base
30
do modelo requisito
Além dos relacionamentos citados na Tabela 1, a SysML suporta também o relacionamento de decomposição que permite que requisitos complexos sejam decompostos em requisitos filhos. Através da decomposição dos requisitos é possível visualizar a hierarquia dos requisitos, pois um requisito pode conter sub-requisitos, e também, facilita a reusabilidade dos requisitos. Outro recurso disponível na SysML é a notação Rationale que pode ser incluída em qualquer relacionamento do diagrama de requisitos e se destina a incluir um comentário ou observação relevante para o modelo. O comentário feito a partir do Rationale pode referir-se a um documento externo ou outro elemento do modelo, como por exemplo, a um diagrama paramétrico.
A SysML permite que requisitos sejam customizados pela definição de uma subclasse adicional de estereótipos de requisitos. Um estereótipo permite adicionar restrições que possibilitam limitar um tipo específico do modelo para que um determinado requisito seja especificado. Por exemplo, um requisito funcional pode ser restrito de forma que só pode ser satisfeito por um elemento do modelo comportamental como: atividade ou máquina de estados. A Tabela 2 apresenta as categorias de estereótipos para <<requirement>>.
Com essas categorias disponíveis na SysML é possível representar tipos específicos de requisitos ou estender um requisito. O estereótipo <<extendRequirement>> permite que um requisito seja detalhado através da inclusão de atributos aos requisitos. Também permite especificar que um requisito é funcional, através do estereótipo <<functionalRequirement>> indicando que o requisito especifica um comportamento. O estereótipo <<interfaceRequirement>> representa os conectores do sistema, enquanto o desempenho do sistema pode ser especificado através do estereótipo <<performanceRequirement>>. Os requisitos que representam características físicas do sistema são representados pelo estereótipo <<physicalRequirement>>, enquanto as restrições de implementação do projeto são definidas pelo estereótipo <<designRequirement>>.
Tabela 2 – Categorias de estereótipos para <<requirement>>.
<<extendedRequirement>> N/A
<<functionalRequirement>> Deve ser satisfeito por uma operação ou comportamento.
<<interfaceRequirement>> Deve ser satisfeito por uma porta, conector, fluxo, e/ou propriedade restritiva.
<<performanceRequirement>> Deve ser satisfeito por uma propriedade de valor
<<physicalRequirement>> Deve ser satisfeito por um elemento estrutural
<<designConstraint>> Deve ser satisfeito por um bloco ou parte
2.2.2.2 Diagrama Paramétrico
Os diagramas paramétricos capturam as propriedades restritivas do sistema, tais como desempenho e confiabilidade, para serem analisadas por ferramentas de análise apropriadas (OMG, 2012). As restrições são apresentadas por equações, cujos parâmetros estão vinculados às propriedades do sistema (FRIEDENTHAL, MOORE e STEINER, 2012). Os parâmetros desse diagrama podem ter tipos, unidades, dimensões e distribuições de probabilidade.
A SysML introduz a construção conhecida como bloco de restrições para suportar a construção de modelos paramétricos. Um bloco de restrição é um tipo especial usado para definir equações. Tal bloco é definido livre de contexto, permitindo a criação de uma biblioteca de restrições que pode ser facilmente reutilizada em vários projetos. A linguagem também inclui o conceito de restrições que podem corresponder a qualquer expressão matemática ou lógica, incluindo expressões com variáveis temporais e equações diferenciais.
No entanto, a SysML não especifica uma linguagem de restrições, mas permite que a linguagem seja especificada como parte da definição das restrições (FRIEDENTHAL, MOORE e STEINER, 2012). No bloco de restrição, também, são definidos um conjunto de parâmetros, que podem ser unidades, dimensões e
32
distribuições de probabilidade, relacionados uns aos outros pela expressão de restrição.
2.2.3 MARTE
A UML tem sido adotada como uma linguagem de modelagem de propósito geral. No entanto, a UML não possui suporte para modelar aspectos como: tempo, escalonamento ou desempenho. Sendo assim, a primeira alternativa para tratar essa deficiência foi a definição do perfil SPT (Schedulability, Performance and Time Specification) (OMG, 2011b). Este perfil fornecia conceitos para análise de escalonabilidade, análise de desempenho, além de permitir a modelagem de aspectos temporais. Porém, no perfil SPT havia restrições quanto à modelagem temporal, pois se baseava em anotações no modelo. Sendo assim, a OMG definiu um novo perfil, que ficou conhecido como MARTE (Modeling and Analysis of Real-Time Embedded Systems) (OMG, 2011b).
O perfil MARTE é dedicado à modelagem de Sistemas Embarcados e de Tempo Real. Este perfil disponibiliza conceitos necessários para modelagem de sistemas embarcados no âmbito de hardware e software; alocação de elementos; análise de escalonabilidade e desempenho; especificação de características de sistemas embarcados, como tamanho de memória e consumo energético.
O perfil MARTE é estruturado em três pacotes: Fundamentos do MARTE (MARTE Foundation), Modelo de projeto do MARTE (MARTE Design Model) e Modelo de análise do MARTE (MARTE Analysis Model), conforme ilustra a Erro! onte de referência não encontrada.. O pacote MARTE Foundation é composto pelos sub pacotess: Elementos Principais (Core Elements), Propriedades não-funcionais (NFP – Non-Functional Properties Modeling), Modelagem Temporal (Time), Modelagem para Recursos Genéricos (GRM – Generic Resource Modeling) e Modelagem de Alocação (Alloc – Allocation Modeling). Estes conceitos são compartilhados com os pacotes, MARTE Design Model e MARTE Analysis Model. O sub pacote CoreElements fornece conceitos fundamentais usados como base nas descrição da maioria dos demais pacotes do MARTE, enquanto o pacote NFP provê recursos para anotar os modelos UML com requisitos não-funcionais. Para representar valores para os NFRs, este pacote utiliza a linguagem VSL (Value
Specification Language). Por sua vez, com o pacote Time é possível modelar conceitos temporais com mecanismos apropriados. Já o pacote GRM possibilita a modelagem de uma plataforma genérica para a execução de aplicações embarcadas e de tempo real. Por fim, o sub pacote Alloc disponibiliza extensões para a modelagem de alocação de recursos.
Segundo Peralti-Frati e Yves (2008), a contribuição do perfil MARTE está no seu modelo de tempo, enriquecendo a UML com elementos de modelo explícitos para representar tais modelos (relógios, tipos de clocks, etc.). Este perfil provê três classes de abstração de tempo. A primeira classe é a de tempo causal, se preocupa com a precedência e dependência entre eventos. A segunda classe é a de tempo síncrono, tem o objetivo de modelar simultaneidade entre eventos. E a terceira classe é a de tempo físico que possibilita modelar as características do tempo físico. O pacote MARTE Analysis Model consiste na definição de modelos de tempo real para sistemas embarcados, no qual inclui conceitos para modelagem e análise (LISANE, KREUTZ e LUIGI, 2009) com o propósito de detectar problemas nas primeiras fases de desenvolvimento e reduzir riscos e erros. Este é composto dos subpacotes GQAM (Generic Quantitative Analysis Modeling), SAM
34
(Schedulability Analysis Modeling) e PAM (Performance Analysis Modeling) . No sub pacote GQAM, uma análise quantitativa genérica é suportada, podendo analisar desempenho, escalonabilidade, energia, memória, confiabilidade e segurança com base no comportamento do software. Este sub pacote é especializado em escalonabilidade e desempenho através dos outros dois subpacotes SAM e PAM.
O pacote MARTE Design Model disponibiliza o suporte para uma especificação detalhada de um projeto de software de tempo real. Este pacote é composto dos subpacotes GCM, HLAM e DRM. O sub pacote GCM (Generic Component Model) é utilizado na abordagem de projeto baseada em componentes e permite a modelagem de componentes, já o sub pacote HLAM (High-Level Application Modeling) possibilita a modelagem das características de sistemas de tempo real como deadline, períodos, características quantitativas referentes ao comportamento, comunicação e concorrência. Por fim, o subpacote DRM (Detail Resource Modeling) é dividido em SRM (Software Resourse Modeling) e HRM (Hardware Resource Modeling), para modelagem de recursos de hardware e software, respectivamente.
Além, destes pacotes e sub pacotes, o MARTE contém o pacote Annexes onde estão disponíveis informações e recursos adicionais tais como a linguagem VSL e o RSM (Repetitive Structure Modeling). O MARTE Library define um modelo de biblioteca do MARTE com tipos primitivos, também inclui operações pré-definidas comumente usadas no domínio de sistemas embarcados e de tempo real.
Segundo Espinoza et al. (2009), MARTE tem vantagens em relação a UML, devido à adição de recursos para a modelagem de requisitos não funcionais, à modelagem de tempo refinada, aos recursos para a modelagem de hardware e software e o alto nível de abstração, que possibilitam sua aplicabilidade em uma variedade de softwares. Os autores ressaltam também o suporte à análise quantitativa como uma vantagem importante, pois esta permite que os modelos feitos com este perfil sejam avaliados por ferramentas de estimativa.
2.2.4 Discussão
Este trabalho foca em resolver problemas no que diz respeito à modelagem de sistemas embarcados e de tempo real bem como a gerência de requisitos durante o desenvolvimento desses projetos. Sendo assim, foram revisadas as linguagens de modelagem que oferecem recursos para suportar estes objetivos. O
perfil MARTE, é específico para o domínio de sistemas embarcados e de tempo real. Seu emprego junto aos modelos UML permite representar requisitos não funcionais e de hardware. Porém, o MARTE não apresenta nenhum recurso para gerência dos requisitos apenas para a especificação dos mesmos. A linguagem SysML dispõe do diagrama de requisitos que permite a representação dos requisitos funcionais e não funcionais bem como dependências entre os mesmos e entre elementos do projeto. Estas dependências permitem o emprego da técnica de rastreabilidade dos requisitos. No entanto, os requisitos na SysML são descritos textualmente e a linguagem não provê os mesmos recursos do MARTE para detalhamento de requisitos não funcionais do domínio de embarcados. Desta forma, as extensões SysML e MARTE podem ser vistas como complementares.
2.3 Engenharia de Software
A Engenharia de Software está relacionada com os aspectos de produção de software, que envolvem desde as fases iniciais de especificação até a manutenção. Os engenheiros de software devem adotar uma abordagem sistemática e organizada em seu trabalho, para produzir um software de alta qualidade (SOMMERVILLE, 2007), entregue no prazo e com o custo previsto, e que atenda às expectativas do cliente (SCHACH, 2009).
A Figura 6 ilustra o modelo de processo de software tradicional segundo Sommerville (2007). Devido ao encadeamento de uma fase com outra, esse modelo é conhecido como modelo em cascata ou ciclo de vida do software. Os principais estágios do modelo demonstram as atividades fundamentais de desenvolvimento. Essas atividades são: definição dos requisitos, projeto do sistema, implementação e testes de unidade, integração e testes de sistema e operação e manutenção.
Na atividade de Análise são criadas as especificações do sistema, através da definição detalhada dos serviços e restrições do sistema. Durante a atividade de Projeto de sistema, os requisitos são divididos em sistemas de hardware, para estabelecer uma arquitetura geral do sistema, ou de software, que envolve identificação e a descrição das abstrações fundamentais do sistema de software e suas relações. Outra atividade importante, durante o desenvolvimento de um software é a Implementação e teste de unidade. O projeto de software é realizado como um conjunto de programas ou unidades de programas e o teste unitário
36
envolve a verificação de cada unidade. Na fase de Integração e teste de sistema, as unidades de programa são integradas e testadas como um sistema completo para garantir que todos os requisitos sejam atendidos, logo após o sistema é liberado para o cliente. A instalação e operação do sistema são feitas durante a atividade de Operação e Manutenção.
Figura 6 – Modelo de Processo de Software Tradicional (SOMMERVILLE, 2007)
No decorrer do desenvolvimento de software surgem desafios. Dentre estes, destacam-se a compreensão do problema, antes de desenvolver a solução de software, e a complexidade dos requisitos. Como os requisitos de software estão cada vez mais complexos, durante o processo de desenvolvimento de software, estes precisam ser detalhados em passos sucessivos. A cada passo, o nível de abstração é reduzido. Desta forma, a complexidade pode ser minimizada e os requisitos implementados conforme a necessidade do usuário. Duas abordagens de Engenharia de Software, a Engenharia de Requisitos e a Engenharia dirigida a modelos, estão relacionadas ao desafio de lidar com requisitos complexos. Estas abordagens são apresentadas na Seção 2.3.1 e 2.3.2.
2.3.1 Engenharia de Requisitos
No processo de desenvolvimento de software, a engenharia de requisitos é uma atividade que tem início durante o levantamento dos requisitos e continua na modelagem e validação dos requisitos. Segundo Pressman (2011), a Engenharia de Requisitos fornece técnicas apropriadas para o entendimento do problema, desta forma, o produto entregue será o que o cliente realmente deseja. A Engenharia de Requisitos, segundo Pressman (2011), inclui sete etapas, que são: concepção, levantamento, elaboração, negociação, especificação, validação e gestão.
A primeira etapa é de concepção do software. Um projeto de software pode iniciar pelo acontecimento de vários eventos. Porém, geralmente o início ou a motivação para a concepção do projeto se dá pela identificação de uma necessidade do mercado. Durante esta etapa, deve ser estabelecido um entendimento básico do problema através da comunicação entre os stakeholders e os analistas de sistemas. Sendo que, os stakeholders são aquelas pessoas que se beneficiam de forma direta ou indireta do sistema que está sendo construído (SOMMERVILLE e SAWYER, 1997).
Durante a etapa de levantamento, as necessidades são discutidas e os requisitos do sistema são investigados, com a ajuda dos stakeholders, para que então a especificação do produto a ser construído seja definida. Nesta etapa da Engenharia de Requisitos, são identificados problemas de escopo, entendimento e priorização das necessidades (CHRISTEL e KANG, 1992). Estes problemas podem resultar em um software que não atende às necessidades do cliente e com tempo de desenvolvimento excedido. Para que estes problemas não prejudiquem a qualidade do software, é necessário fazer o levantamento das necessidades do sistema com a ajuda de stakeholders que tenham um bom nível de conhecimento do problema. Além disso, o analista de sistemas do projeto deve ser capaz de capturar as inconsistências, requisitos que estão duplicados e ajudar o usuário a priorizar as necessidades.
A terceira etapa é a de elaboração, onde as informações obtidas, junto ao usuário, nas fases de concepção e levantamento são então detalhadas. Nesta fase, com o detalhamento dos requisitos é possível identificar aspectos de funcionalidade e comportamento do software.
38
A etapa de negociação tem o objetivo de conciliar os conflitos gerados durante o processo de desenvolvimento de software. Para isto, é necessário que os stakeholders ordenem os requisitos e discutam avaliando a prioridade dos mesmos. Sendo assim, é interessante a utilização de uma abordagem iterativa que priorize os requisitos avaliando custos e riscos, para que o sucesso do projeto seja alcançado.
No decorrer da etapa de especificação é feita a documentação dos requisitos do software. Esta documentação pode ser feita no formato escolhido pela equipe de desenvolvimento do projeto. Usualmente, são utilizadas especificações em formato de texto, mas diagramas também podem ser usados para especificar requisitos ou detalhar um determinado requisito. Os artefatos produzidos nesta fase devem estar sempre atualizados para não causar nenhum prejuízo no desenvolvimento do software.
Os artefatos produzidos durante as etapas anteriores da engenharia de requisitos são avaliados quanto a sua qualidade durante a etapa de validação dos requisitos. Durante a validação, as especificações são revisadas pelos stakeholders para assegurar que todos os requisitos estão especificados de maneira que o produto entregue seja realmente o esperado por eles.
Em um processo de desenvolvimento de software, os requisitos estão em constante evolução (HAZAN e LEITE, 2003) uma vez que o processo de produção de requisitos, com todos os seus detalhamentos, pode resultar em alterações no requisito ou em outros requisitos a este relacionados. Sendo assim, é essencial que as mudanças ocorridas durante o processo sejam controladas pela gestão de requisitos. Tais mudanças podem ocorrer pela identificação de novas necessidades, ou pela deficiência nos requisitos que foram levantados. As mudanças ocorridas durante o desenvolvimento de um software podem ter efeito negativo na qualidade do sistema. Para evitar isso, o impacto de qualquer alteração em um requisito deve ser analisado de modo que sua implementação seja executada de forma eficiente e com baixo custo.
A gerência de requisitos preocupa-se com: gerenciar mudanças nos requisitos acordados, gerenciar os relacionamentos entre os requisitos, gerenciar as dependências entre o documento de requisitos e outros documentos produzidos ao longo do processo (KOTONYA e SOMMERVILLE, 1998), esses fatores influenciam na estabilidade dos requisitos. Num projeto de desenvolvimento de software a
estabilidade dos requisitos está relacionada com a rastreabilidade estabelecida, de modo que, os requisitos possam ser acompanhados durante todo seu ciclo de vida.
A rastreabilidade de requisitos propicia o entendimento entre os relacionamentos dos requisitos e entre outros artefatos gerados durante o processo de desenvolvimento de software. A rastreabilidade é uma forma de garantir que os artefatos produzidos durante o processo de desenvolvimento, satisfazem os requisitos do cliente (HAZAN e LEITE, 2003). A matriz de rastreabilidade é um mecanismo que proporciona visibilidade ao rastreamento e ao relacionamento entre os requisitos, artefatos do modelo, código e casos de teste. A evolução de um sistema se dá pelo resultado das mudanças solicitadas, por isto, é importante que os requisitos levantados sejam rastreáveis.
A rastreabilidade dos requisitos pode ser horizontal e vertical. A rastreabilidade vertical se refere à capacidade de relacionar artefatos dependentes dentro do modelo. A rastreabilidade horizontal é a habilidade de relacionar artefatos entre diferentes modelos. Entre os artefatos que podem estar relacionados estão: os requisitos, artefatos de análise e de design, código fonte, casos de teste, entre outros. (DALL'OGLIO, 2010).
Conforme explicado anteriormente, os requisitos são definidos nas fases iniciais do projeto, essas fases compreendem as fases de concepção, levantamento e elaboração, (SOMMERVILLE, 2007) e, são utilizados como especificação do que deve ser implementado. Tais requisitos, geralmente, são classificados em funcionais e não funcionais. Os requisitos funcionais descrevem as funções do sistema de forma detalhada, isto inclui como sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações (SOMMERVILLE, 2007). Os requisitos não funcionais NFR (do inglês, Non-Functional Requirements) descrevem as restrições sobre as funções disponibilizadas pelo sistema, como, por exemplo, restrições temporais, de desempenho, de segurança ou qualidade.
No domínio de software embarcado, os requisitos não funcionais devem ser devidamente especificados, pois restringem muitas decisões de projeto. O perfil MARTE oferece recursos para a modelagem destes requisitos com foco no domínio de embarcados, enquanto a SysML oferece um suporte mais genérico para engenharia de sistemas.
