Como ressaltado anteriormente, além da especificação dos requisitos, é importante a gestão destes requisitos, de forma que um controle maior dos requisitos, suas mudanças, bem como o impacto destas nas decisões do projeto seja suportado. Esta gestão deve incluir sobretudo requisitos não funcionais, muito rígidos no domínio de embarcados. Como mencionado anteriormente, abordagens baseadas somente no padrão UML, não suportam a especificação ou gestão de requisitos não funcionais.
Esta preocupação com a gestão de requisitos não é nova para os engenheiros de software e ferramentas podem ser encontradas que suportam a gerência de requisitos de software. No entanto, muitas destas ferramentas focam mais em requisitos funcionais e no impacto de suas mudanças nas decisões de projeto e ou componentes do sistema.
Para Zhu e Gorton (2007), a arquitetura do software é composta por um conjunto de decisões de projetos. No entanto, normalmente, a arquitetura de um software foca na representação de conectores e componentes do sistema e as decisões de projeto e sua relação como RNFs são frequentemente capturadas separadamente. Essas dissociações dificultam a compreensão e a evolução da arquitetura. Zhu e Gorton propõem perfis UML para a modelagem das decisões de projeto e para a modelagem dos NFRs, de forma que os NFRs sejam tratados como elementos principais na modelagem do sistema. O perfil para modelagem de decisões de projeto identifica aspectos como: decisão, regras de projeto, restrições do projeto, participação de elementos, enquanto que o perfil para NFR define estereótipos usados para representar os NFR, como por exemplo <<performance>> e <<scalability>>. Esses NFR são conectados às decisões de projeto (<<designDecision>>) através de ligações definidas pelos autores. Estas ligações facilitam a rastreabilidade de requisitos. O estudo de caso usado (ZHU e GORTON, 2007) demonstra a criação de requisitos não funcionais como escalonabilidade e desempenho, através dos novos perfis propostos. Porém, não há necessidade da criação de novos perfis UML, para representar esses tipos de requisitos, uma vez que, o perfil MARTE possui recursos para representá-los.
Vários trabalhos podem ser encontrados na literatura que estudam a usabilidade de SysML e de MARTE para a especificação de sistemas embarcados (ALBINET, BEGOC, et al., 2008) (DUBOIS, PERALDI-FRATI e LAKHAL, 2010). No entanto, a gestão baseada em modelos é um problema que foi atacado recentemente por um número bem reduzido de autores (ESPINOZA, CANCILA, et al., 2009) (ALBINET, BEGOC, et al., 2008), (ALBINET, BOULANGER, et al., 2007). A gestão de requisitos no domínio de embarcados pode ser beneficiada pela combinação dessas extensões da UML, como discutido em Espinoza et. al. (2009).
Em Albinet et al. (2008), a metodologia MeMVaTEx foi estendida objetivando o suporte à modelagem de requisitos (funcionais e não-funcionais), rastreabilidade e verificação, com foco no projeto de aplicações automotivas. Esta metodologia
46
baseia-se em três modelos diferentes utilizados em cada nível de abstração do processo. Os modelos são: modelo de requisitos, modelo de solução e modelo de validação e verificação. Para representar os requisitos do sistema, os autores definiram o perfil RPM (Requirement Profile Memvatex), uma extensão da UML específica para esta abordagem. Para o estudo de caso feito nesse trabalho também foram utilizadas ferramentas diferentes para cada nível de abstração, sendo assim o modelo criado não é integrado e dificulta a utilização desta metodologia em qualquer outro estudo. Como este trabalho baseia-se em linguagens como EAST-ADL e no perfil RPM, este se restringe ao subdomínio automotivo. A rastreabilidade dos requisitos nesta abordagem é feita entre os modelos definidos e são utilizadas as ligações para realizar a rastreabilidade entre os requisitos.
Focando na gerência e especificação de requisitos no domínio de sistemas embarcados, Dubois et al. (2010) propõe o meta-modelo DARWIN4Req para rastreabilidade de requisitos. Tal meta-modelo está baseado em três fluxos independentes, que são: modelo de requisitos, modelo da solução e modelo validação & verificação. Este metamodelo DARWIN4Req estabelece um link entre os fluxos e permite total rastreabilidade dos requisitos incluindo modelos heterogêneos. Nesta abordagem, SysML é usado para modelagem dos requisitos, facilitando a rastreabilidade dos mesmos. Os requisitos que podem ser relacionados a outros elementos do modelo usando relacionamentos definidos pelas notações SysML, facilitado assim a rastreabilidade. No entanto, nesse projeto, são utilizadas várias ferramentas para modelagem do sistema, pois cada modelo é feito em uma ferramenta específica, dificultando a rastreabilidade e automação do projeto. Além disso, como os autores definem um meta-modelo, ou seja, utilizam uma extensão da linguagem de modelagem padrão, o emprego desta metodologia é dificultado, pois exige a utilização de uma ferramenta especifica.
O diferencial da abordagem proposta nesta dissertação em relação aos trabalhos citados anteriormente é que a abordagem proposta é baseada em UML e nas extensões padronizados pela OMG, SysML e MARTE, sem redefinir estas linguagens e, portanto, é suportada por qualquer ferramenta de modelagem disponível no mercado. Além disso, nossa abordagem integra a engenharia de requisitos no domínio de software embarcado o que favorece a gestão dos requisitos em qualquer fase do desenvolvimento do software. Esta abordagem não foca em
nenhum subdomínio específico e foi definida com o intuito de poder ser empregada em qualquer aplicação embarcada.
Os trabalhos relacionados estendem a linguagem SysML pois tem a necessidade de incluir atributos para melhorar o controle dos requisitos. Exemplos desses atributos seriam: quem vai testar, data de teste, situação do requisito, entre outras. Para nossa abordagem, a preocupação está na descrição correta e no acompanhamento do requisito e não na gerência do projeto como um todo. A abordagem proposta possui matrizes que possibilitam a rastreabilidade do ciclo de vida de um requisito.
4 ABORDAGEM PROPOSTA
Para resolver os problemas de especificação e gestão de requisitos encontrados no desenvolvimento do software embarcado, a abordagem MDEReq (do inglês, Model Driven Engineering for Requirement Management) é proposta neste trabalho. Esta abordagem é dirigida por modelos e foca na engenharia de requisitos para o domínio de software embarcado com o objetivo de fornecer um processo organizado e padrão para tratamento dos requisitos neste domínio. Esta abordagem visa facilitar a especificação de softwares embarcados através da construção de modelos abstratos baseados em linguagens padronizadas, além de suportar a modelagem e gestão de requisitos funcionais e não funcionais (por exemplo: temporais, de confiabilidade, consumo, entre outros). A gestão de requisitos é uma atividade importante e que deve ser considerada durante todo o processo de desenvolvimento de um software embarcado.
O uso de modelos para representar os requisitos de um sistema é importante desde as fases iniciais do processo de software, oferecendo uma visão abstrata do sistema a todos os envolvidos (ALBINET, BEGOC, et al., 2008). A abordagem proposta se baseia nos princípios da MDE, onde modelos guiam todas as decisões de projeto e são detalhados e refinados a cada etapa, até que a implementação seja alcançada (SELIC, 2006). Desta forma, a MDEReq propõe atividades que direcionam o trabalho dos engenheiros de software embarcado, guiando a especificação e a gerência de requisitos. Além das atividades, a abordagem define notações a serem empregadas a cada etapa.
Nesta abordagem, os modelos são construídos utilizando as linguagens de modelagem UML e SysML e o perfil MARTE, uma extensão da UML para o domínio de Sistemas Embarcados e de Tempo Real. Esta combinação de notações padronizadas pela OMG garante um melhor tratamento dos requisitos deste
domínio, permitindo modelar requisitos funcionais e não funcionais do sistema, além de permitir a gestão de mudanças nos requisitos. Diagramas UML de casos de uso, de sequência e de classes são adotados para proporcionar à equipe de desenvolvimento uma visão funcional, comportamental e estrutural do sistema. Estes diagramas são decorados com estereótipos do perfil MARTE, o que permite a modelagem dos requisitos não funcionais do sistema, tais como requisitos temporais, frequentes neste domínio. Já a utilização do diagrama de requisitos da SysML permite aos projetistas de sistemas embarcados um controle mais efetivo das mudanças de requisitos e de seus impactos nos demais artefatos do projeto em todas as etapas do processo.
A MDEReq é baseada no modelo de processo de desenvolvimento de software tradicional. Este processo tem o objetivo de produzir requisitos que não sejam ambíguos, e que sejam facilmente compreendidos, corretos, concisos, rastreáveis e verificáveis (FRIEDENTHAL, MOORE e STEINER, 2012). A metodologia para o processo de desenvolvimento de software da MDEReq está baseada na engenharia de requisitos e pode ser aplicada em qualquer projeto de software embarcado, não se restringindo a uma área de aplicação específica. No processo de desenvolvimento de um software embarcado, a engenharia de requisitos auxilia na definição dos objetivos e restrições do sistema (KRÜGER, FARCAS, et al., 2007) de maneira que os erros cometidos nas fases de levantamento e especificação sejam corrigidos antes mesmo da implementação do sistema, consequentemente com custo mais baixo.
A primeira atividade da MDEReq é a definição de requisitos, que serve de base para as atividades seguintes. Esta definição de requisitos faz parte do processo de Engenharia de Requisitos, revisado na seção 2.3.1, o qual define atividades que envolvem concepção, levantamento, elaboração, negociação, especificação, validação e gestão de requisitos (PRESSMAN, 2011). Com base neste processo, foi definido o fluxo para a MDEReq, ilustrado na Figura 7.
O fluxo proposto é composto de quatro atividades: o levantamento, a análise e especificação, a validação e a gestão de requisitos que, segundo Pressman (2011), são as principais atividades da Engenharia de Requisitos.
50
Figura 7 – Fluxo abordagem MDEReq
A atividade de levantamento de requisitos tem como meta identificar, classificar e organizar os requisitos do sistema. Estes requisitos são levantados com os stakeholders (os usuários e demais interessados no projeto). A técnica para o levantamento dos requisitos não é definida pela MDEReq, sendo assim, nesta abordagem pode ser aplicada qualquer técnica de levantamento que se adequa à equipe de analistas de sistemas. O artefato gerado por esta atividade é uma lista de requisitos. Nesta lista, os requisitos do sistema devem ser classificados em funcionais e não funcionais e podem ser priorizados, conforme decisão do cliente. Os requisitos também são classificados de acordo com as categorias de requisitos da SysML, apresentadas na Tabela 2 do capitulo 2 . Nesta abordagem, o estereótipo <<functionalrequirement>> é usado para identificar os requisitos funcionais e outros estereótipos específicos são usados para identificar os requisitos não funcionais, como por exemplo, o estereótipo <<performancerequirement>> é usado para representar características temporais do sistema.
Esta lista pode ser usada como base para a construção da primeira versão do diagrama de requisitos. Com este diagrama, é possível visualizar os relacionamentos entre todos os requisitos modelados, até este instante. Este diagrama utiliza os relacionamentos de derivação e de composição definidos na SysML. Estes relacionamentos foram escolhidos, uma vez que, esta versão do
diagrama baseia-se unicamente na lista de requisitos. Então, o relacionamento entre os requisitos pode ser por uma derivação, quando um requisito é derivado de outro requisito origem, ou por uma decomposição, que normalmente ocorre quando um requisito complexo é decomposto em um ou mais requisitos.
Durante o levantamento dos requisitos observa-se que, estes, possuem origens distintas. No nicho de embarcados, vale citar o exemplo do desenvolvimento de um aparelho celular, onde, normalmente a solicitação é feita pela equipe do departamento de marketing da empresa. Essa equipe fornece as características necessárias do produto para a equipe de desenvolvimento de software, sendo que, tais características devem superar as expectativas do público alvo, portanto, neste cenário são vários stakeholders fornecendo informações do produto. Isto dificulta a obtenção de requisitos não contraditórios e que reflitam adequadamente as necessidades dos envolvidos.
A segunda atividade estabelecida na MDEReq é a Análise e Especificação, onde as informações obtidas na fase anterior são refinadas (PRESSMAN, 2011). Esta atividade é responsável pelo detalhamento dos requisitos levantados. Para isso, modelos UML são construídos. Os diagramas UML escolhidos para serem utilizados, são: de casos de uso, de classes e de sequência, pois proporcionam para a equipe de desenvolvimento um modelo que possui diferentes visões do sistema (visão funcional, estrutural e comportamental de seus requisitos). No entanto, para um maior detalhamento de um sistema embarcado, os diagramas de classes e sequência, são decorados com estereótipos do MARTE para anotar características específicas do domínio de sistemas embarcados, por exemplo, deadlines, período de tarefas ou modelagem de outros requisitos não funcionais, ou ainda a modelagem da interação com componentes físicos do sistema, implementados em hardware.
Na fase de especificação de um sistema, nota-se que existe uma grande dificuldade em gerenciar os requisitos desde o nível de especificação até os níveis mais baixos, como por exemplo, o código, devido à falta de rastreabilidade dos requisitos (BERGSJO, ALMEFELT e MALMQVIST, 2010). Sendo assim, durante a atividade de Análise e Especificação da MDEReq, o diagrama de requisitos construído anteriormente é evoluído, de forma a agregar novos elementos do modelo e relaciona-los aos requisitos já modelados.
52
A evolução do diagrama de requisitos permite visualizar os relacionamentos entre os requisitos e entre requisitos e outros elementos do modelo. Na nossa abordagem, elementos do modelo podem ser diagramas de sequência, casos de uso e classes. Sendo assim, além dos relacionamentos de derivação e composição, são adicionados ao diagrama de requisitos elementos do modelo com relacionamentos de <<satisfy>> e <<refine>>. O relacionamento <<satisfy>> é utilizado para indicar que um requisito deve ser satisfeito por outro elemento do modelo e, na nossa proposta, isto é feito através do diagrama de sequência, ou seja, existem ações descritas no diagrama de sequência que satisfazem um determinado requisito. O relacionamento <<refine>> indica que um requisito é refinado por outro elemento do modelo, no caso da MDEReq, um caso de uso. Ou seja, isto ocorre quando há necessidade de um detalhamento do requisito.
Na atividade de validação, casos de teste são relacionados aos requisitos. Atualmente, a MDEReq não define como os casos de teste são detalhados. A intenção é que sejam identificados, previamente, quais requisitos devem ser testados e quais os casos de teste responsáveis por testá-los, auxiliando a gestão dos testes. Nesta etapa, o diagrama de requisitos sofre outra alteração. Além, dos relacionamentos indicados anteriormente também é incluído o relacionamento de <<verify>> disponível na SysML. Este relacionamento é utilizado para identificar que um requisito deve ser verificado por outro elemento do modelo que, no caso da MDEReq, é um caso de teste.
A atividade de gestão da MDEReq baseia-se na geração de matrizes de rastreabilidade, as quais são geradas com base no diagrama de requisitos. Este diagrama é primeiramente construído durante o levantamento e à medida que as atividades são realizadas, o diagrama de requisitos evolui e novas matrizes de rastreabilidade mais completas podem ser geradas. Esta atividade ocorre em paralelo às atividades de levantamento, análise e especificação e validação, pois o nosso objetivo é um processo de desenvolvimento de software, onde, requisitos podem se rastreados durante todas as fases. Além disso, a gerência de requisitos proposta na MDEReq reduz custos ao projeto, pois os requisitos são acompanhados desde a primeira fase da abordagem até o fim e estes requisitos só serão implementados quando estiverem de acordo com as necessidades, caso contrário, retornam para a atividade de levantamento.
Para suportar o acompanhamento da vida dos requisitos, evitando erros e inconsistências, a abordagem MDEReq define matrizes de rastreabilidade. As matrizes de rastreabilidade definidas para a MDEReq tem apenas uma direção (para frente). Esta direção se dá sempre de um requisito para outro requisito, de um requisito para um artefato de projeto ou de um requisito para um caso de teste. Considerando as classificações de rastreabilidade apresentadas na seção 2.3.1, nossa abordagem suporta a rastreabilidade vertical apenas, uma vez que, esta abordagem usa um modelo integrado em que todas as definições fazem parte deste modelo.
Na MDEReq, são utilizados os relacionamentos derive, composite, refine, verify e satisfy do diagrama de requisitos para dar suporte a matrizes de rastreabilidade em diferentes níveis de abstração ou em diferentes fases do projeto. A combinação desses relacionamentos com as atividades da engenharia de requisitos propostas na abordagem geram diferentes matrizes de rastreabilidade, conforme detalhado na Tabela 3.
Tabela 3 – Matrizes propostas pela MDEReq
Relacionamento SysML Atividade Matriz de Rastreabilidade
derive / composite Levantamento Requisitos X Requisitos
refine / satisfy Análise e
Especificação
Requisitos X Artefatos de Projeto
verify Validação Requisitos X Casos de Testes
Na atividade de levantamento é gerada a matriz de rastreabilidade de requisito para requisito, podendo esses requisitos ser funcionais ou não funcionais, usando relacionamentos do tipo derive e composite. Esta matriz tem a finalidade de apoiar a gestão de mudanças nos requisitos, quando um requisito é derivado a partir de um requisito base ou quando um requisito é decomposto em outros. Nestes casos, esta matriz indica quais requisitos são impactados por mudanças em um determinado requisito.
A matriz de rastreabilidade dos requisitos para os artefatos de projeto é gerada durante a atividade de análise e especificação através dos relacionamentos de refine e satisfy, indicando que um elemento do modelo refina ou satisfaz um requisito. Neste caso, os elementos do modelo são casos de uso e diagramas de
54
sequência. Desta forma, quando o requisito é alterado, é possível identificar de forma gráfica quais elementos do modelo devem ser alterados.
Por fim, a matriz de rastreabilidade de requisitos para casos de testes, gerada durante a atividade de validação, se destina a equipe de testes e indica quais testes são usados para testar a satisfação de um requisito e também pode indicar quais testes devem ser redefinidos em função de uma mudança nos requisitos.
As matrizes propostas na MDEReq permitem que os envolvidos no projeto tenham várias visões dos requisitos do sistema em vários níveis de abstração, facilitando a visualização das mudanças e de seus impactos nos artefatos do projeto, além de permitir um controle mais rígido sobre requisitos funcionais e não funcionais do sistema.
Para dar apoio a abordagem proposta está sendo criada, em nosso grupo de pesquisa, uma ferramenta que tem como entrada o modelo integrado (UML/MARTE e SysML) e gera automaticamente as matrizes propostas pela abordagem. Esta ferramenta indica nas matrizes inconsistências quando ocorre uma mudança em um determinado requisito, de forma a salientar quais elementos estão relacionados ao requisito que sofreu a alteração e, consequentemente, devem ser revisados.
No próximo capítulo, um estudo de caso será apresentado o qual será usado para demonstrar a aplicabilidade da abordagem proposta. Neste estudo, modelos construídos em cada atividade da abordagem são apresentados e discutidos, bem como as matrizes de rastreabilidade usadas.
5 ESTUDO DE CASO
Este capítulo tem como objetivo principal, demonstrar a abordagem MDEReq através de um estudo de caso. Tal estudo de caso trata da modelagem do software de controle de um freio ABS (do inglês, Anti-lock Braking System). Para o melhor entendimento do estudo de caso realizado, este capítulo está dividido em duas seções. A seção 5.1 apresenta uma visão geral da aplicação alvo, o freio ABS, e a seção 5.2 é responsável por demonstrar a aplicação da abordagem proposta para a modelagem e gerência de requisitos do software de controle do freio ABS.