MK: FERRAMENTA PARA MODELAGEM DE REQUISITOS NO FORMATO KAOS

Transcrição

1 MK: FERRAMENTA PARA MODELAGEM DE REQUISITOS NO FORMATO KAOS Emerson Ricardo Gasparotto [Bolsista PIBITI/Voluntário] 1, Elias Canhadas Genvigir [Orientador] 2 12 Coordenação de Informática COINF Campus Cornélio Procópio Universidade Tecnólogica Federal do Paraná UTFPR Avenida Alberto Carazzai, 1640 Cornélio Procópio, PR ergasparotto@gmail.com, elias@utfpr.edu.br Resumo - Na Engenharia de Requisitos pergunta-se o que o sistema precisa fazer. Na Engenharia de Requisitos Orientada a Metas, use-se as perguntas: Por que e Como para verificar se uma determinada funcionalidade é necessária e como ela pode ser implementada. As duas engenharias citadas têm como atividade a documentação de requisitos, e neste trabalho, foi desenvolvida uma ferramenta open source de modelagem de requisitos para ambiente desktop, baseado nos modelos de metas e responsabilidades da metodologia KAOS. Para criar a ferramenta foi utilizadaa a API Visual Library 2.0 e as APIs nativas DOM e SAX do JDK foram utilizados para manipular os arquivos XML no qual os diagramas são armazenados. Palavra-chave: Engenharia de Requisitos; Engenharia de Requisitos Orientada a Metas; KAOS; Visual Library. Abstract In the Requirements Engineering it questioned what the system must do. In the Goals-Oriented Requirements Engineering, used the question words of Why and How to check if a certain functionality needed and how it can be implemented. Both cited engineerings have as the requeriments of documentation, and in this works, was developed a modeling toll of requeriments open source to desktop environments, based on the models of goals and responsibilities of the KAOS methodology. To create the tool was used the Visual Library 2.0 API and Java s native like DOM and SAX for manipulate XML files in which the diagrams are stored. Keywords: Requirements Engineering, Goals-Oriented Requirements Engineering, KAOS, Visual Library. INTRODUÇÃO Este artigo tem como objetivo apresentar o projeto desenvolvido de iniciação científica. O projeto tem como base o desenvolvimento de uma ferramenta open source de modelagem de requisitos para o ambiente desktop, baseada em GORE (do inglês Goal-Oriented Requirements Engineering), utilizando o método KAOS (do inglês Knowledge Acquisition in AutOmated Specification). A finalidade desta ferramenta é a de documentar requisitos, permitindo a rastreabilidade através dos diagramas que poderão ser criados pelos módulos desta. A rastreabilidade de requisitos é uma forma de entender e gerenciar as informações dos requisitos visando compreender a origem dos requisitos, gerenciar e avaliar o impacto das mudanças, verificar se todos os requisitos estão satisfeitos pela implementação e verificar se realmente o que está especificado está sendo feito [1]. Segundo [2], o GORE é um método para Engenharia de Requisitos que visa empregar o conceito de metas para elicitar, elaborar, estruturar, especificar, analisar, negociar, documentar e modificar requisitos. Ele

2 baseia-se nos objetivos dos stakeholders 1, com a finalidade de desenvolver o software que realmente satisfaça os requisitos destes. A metodologia KAOS, por sua vez, é uma abordagem para o método GORE que visa dar suporte a todo o processo de requisitos partindo das metas de alto nível, até alcançar os requisitos, objetos e operações a serem estabelecidas pelos vários agentes. A metodologia fornece uma linguagem de especificação, um método elaborado e formas de diagramação [3]. Segundo [4], o entendimento do que são os requisitos é uma parte importante para o sucesso do desenvolvimento de um software e caso os requisitos não sejam bem especificados, muito dificilmente o software atenderá todas as necessidades esperadas. A relevância deste projeto está na possibilidade de fornecer uma ferramenta para a fase de elicitação e documentação de requisitos e permitir avaliar o impacto de eventuais mudanças nos artefatos produzidos no desenvolvimento do projeto e manutenção do software, baseado em uma abordagem orientada a metas. Justificativa. A atividade de levantamento de requisitos é de grande importância para o desenvolvimento do software. Esta fase decide precisamente o que construir e transmite para todos os envolvidos no projeto, as razões que justificam a existência dos requisitos. Outra atividade, também importante é a rastreabilidade de requisitos, que visa garantir a conformidade do software com os seus requisitos, tendo a finalidade de gerenciar e avaliar as mudanças [5]. Pensando neste contexto, foi desenvolvida uma ferramenta open source para modelagem de requisitos baseado em metas. A abordagem orientada a metas é uma técnica eficaz na definição dos porquês do software e na identificação dos requisitos [6]. Em GORE, usa-se fazer perguntas de Por que e Como, para justificar o porquê da necessidade de uma determinada funcionalidade e como ela poder ser implementada. Existem vários métodos de GORE, por exemplo: GBRAM (do inglês Goal Based Requirements Analysis Method) [7]; GSTH (do inglês General System Thinking Heuristics) [8]; TROPOS [9]; KAOS [10]. GBRAM é um método de identificação de requisitos e metas do sistema que se foca na identificação e na abstração inicial de metas a partir de várias fontes de informações, pressupondo que as metas não foram documentadas pelas partes interessadas [11]. GSTH é método que concerne o levantamento de requisitos, definindo metas de mais alto nível de abstração e propõe um conjunto de heurísticas baseadas em GST (do inglês General System Thinking) e Cibernética [8]. TROPOS é uma metodologia de elicitação de requisitos para o desenvolvimento de sistema multi-agentes [12]. A metodologia utiliza o framework i* 2 para estruturar o modelo de caso de uso, com o propósito de capturar um melhor entendimento dos relacionamentos organizacionais entre os diversos atores. Os objetivos da metodologia KAOS são a modelagem formal de requisitos em termos de metas, restrições, hipóteses, objetos, ações, eventos, agentes, utilizando-se de técnicas de refinamento de metas, detecção de resolução de conflitos e atribuições de responsabilidades a agentes [13]. O KAOS possui quatro modelos: modelo de metas, modelo de responsabilidade, modelo de objetos e modelo de operações. Os modelos são criados a partir do refinamento das metas obtidas em descrições preliminares, fazendo perguntas de Como e Porquê (etapa de elaboração de metas); os agentes são identificados e as responsabilidades são atribuídas (etapa de identificação de agentes); as classes, as associações e atributos são derivados das especificações das metas (etapa de modelação de objetos); as operações, as respectivas pré e pós-condições e condições de trigger são identificadas para garantir a satisfação das metas (etapa de operacionalização) [10][14][3]. Com relação a este projeto foi escolhido a metodologia KAOS, por ser uma metodologia conhecida na comunidade de Engenharia de Requisitos e possuir ferramentas para modelar diagramas KAOS, tais como Dia e Objectiver. Objetivo geral. Como objetivo principal do projeto foi à implementação de dois módulos da ferramenta para documentação de requisitos baseados em modelos da metodologia KAOS: módulos de metas e módulos de responsabilidades. 1 Segundo o dicionário Michaelis, inglês/português, stake significa marcar, delimitar com estacas, aposta, dinheiro apostado, risco, interesse, parte, ação. Hold significa ação de segurar, pegar, reter, possuir, ocupar (p. 506). Literalmente, seria aquele que retém, possui um interesse, ocupa um espaço de influência. O termo stakeholders foi criado para designar todos os indivíduos, pessoas, instituições ou ambiente que, de alguma maneira, são ou poderão vir a ser afetados pelas atividades de uma empresa. Exemplo disso, são os empregados, os clientes, os fornecedores, o meio ambiente, a comunidade do entorno, a sociedade como um todo. 2 i* - lê-se i star ou i estrela.

3 O objetivo foi modularizar os modelos, e em cada módulo, fornecer objetos gráficos que suportem ligações de acordo com os conceitos da metodologia, verificando a consistência à medida que os diagramas vão sendo criados. Durante o desenvolvimento tentou-se evitar a complexidade visual, separando os refinamentos das metas em módulos para facilitar a leitura individual dos refinamentos, permitindo executar a rastreabilidade de requisitos, avaliando o impacto de mudanças no desenvolvimento e na manutenção de projetos. Objetivos específicos. No módulo de metas, os requisitos serão identificados e estruturados para satisfazer as necessidades de requisitos dos stakeholders: requisitos funcionais e requisitos não-funcionais. Cada meta, exceto a meta-raíz 3, poderá ser justificada, pelo menos, por outra meta para explicar o porquê da meta introduzida no modelo. Cada meta, exceto os nós 4, é refinado como uma submeta, representando como a meta refinada pode ser alcançada. Os diagramas construídos neste módulo terão formato acíclico, que significa que os diagramas não podem possuir nós, retornando arestas para nós superiores. No módulo de responsabilidade, serão construídos todos os diagramas de responsabilidade. Os requisitos e as expectativas serão associados para cada agente, representando a relação de responsabilidade que conecta um agente para a exigência de que o agente é responsável e a atribuição de expectativa de algum agente. Arquitetura. A arquitetura da ferramenta está baseada na metodologia KAOS. O KAOS possui quatro modelos: Modelo de Metas, Modelo de Responsabilidade, Modelo de Objetos e Modelo de Operações. Os modelos contemplados no âmbito desse projeto são os dois primeiros, isto é, Modelo de Metas e Modelo de Responsabilidades. Na Figura 1 é possível visualizar a arquitetura da ferramenta. EDIÇÃO VISUAL LIBRARY Modelo De Metas Regra de completude Gerenciamento de diagramas refinamento Modelo de Responsabilidade s Regra de completude Gerenciamento de diagramas Modelo de objetos Regras de completudes Gerenciamento de diagramas Modelo de Operações Regras de completudes Gerenciamento de diagramas XML Figura 1. Arquitetura da ferramenta MK. 3 meta-raíz é uma meta estratégica de mais alto nível do modelo de metas. 4 o termo nó é utilizado para fazer referências aos vértices.

4 METODOLOGIA O desenvolvimento da ferramenta feito baseado no modelo iterativo e incremental. O ciclo de vida Iterativo e Incremental divide o desenvolvimento de um projeto de software em ciclos. Cada ciclo de desenvolvimento é composto pelas atividades de levantamento de requisitos, análise de requisitos, projeto, implementação e testes. À medida que as iterações são realizadas, o desenvolvimento evolui em versões até chegar ao produto final. A escolha deste modelo de desenvolvimento deve-se a possibilidade de planejar iterações para cada módulo da ferramenta e utilizar a UML para criar os artefatos. Foram planejadas quatro iterações, a primeira e a segunda iteração é voltada para o módulo de metas e a terceira e quarta iteração para o módulo de responsabilidades.a segunda e quarta iteração foram reservadas para revisões e melhoramentos. Conceitos sobre a metodologia kaos. Os objetivos ou metas são os conceitos mais importantes na abordagem KAOS e são propriedades desejadas do sistema que são expressas pelos stakeholders[2][15]. Eles podem ser formulados em diferentes níveis de abstração[2][15]. Com a metodologia KAOS, os objetivos de um novo sistema podem ser identificados por meio de entrevistas atuais e futuras, análises de sistema recentes e a interpretação de documentos técnicos [17]. Na abordagem KAOS, os objetivos podem ser decompostos através de ligações E (AND) e OU (OR), e estas denominam-se por refinamento. As ligações de refinamento AND relacionam um objetivo com um conjunto de sub-objetivos, isto significa que satisfazer todos os sub-objetivos ou submetas no refinamento é a condição para satisfazer o objetivo. As ligações de refinamento OR relacionam um objetivo com um conjunto alternativo de refinamentos, isto significa que satisfazer um dos refinamentos é a condição para satisfazer o objetivo. A estrutura do refinamento AND/OR dos objetivos para um determinado sistema, pode ser representada através de um grafo acíclico dirigido [18][15]. Quando se fala de objetivos em KAOS, é necessário distingui-los de acordo com os diferentes tipos de categoria de requisitos, isto é, requisitos funcionais e os não-funcionais [2][15]. Na Figura 2 pode ser visualizado um exemplo de refinamento de metas de requisitos funcionais e a não funcionais. Figura 2. Exemplo de refinamento de metas funcionais e não funcionais. Fonte adaptada de [2]. Os Agentes também representam um conceito importante na abordagem KAOS, pois são responsáveis em alcançar os requisitos e as expectativas. Os agentes podem ser humanos ou componentes automatizados. Um requisito é um objetivo colocado sob a responsabilidade de um agente de software e expectativa é um tipo de objetivo ser atingido por um agente que é parte do ambiente do sistema. [17]. Os conflitos estão focados em problemas entre pares de requisitos não-funcionais, o que significa que os dois objetivos não podem ser satisfeitos simultaneamente [15]. Os obstáculos são situações que violam um objetivo, um requisito ou uma expectativa. Neste caso, diz-se que o obstáculo obstrui o objetivo, requisito ou expectativa. O tratamento de obstáculos permite que os analistas identifiquem e localizem as circunstâncias excepcionais durante a engenharia de requisitos, a fim de produzir, por exemplo, requisitos robustos ou até mesmo novos requisitos para evitar ou reduzir o impacto dos obstáculos, resultando num software de confiança. Os obstáculos impedem com que os objetivos de um sistema

5 sejam alcançados. Lidar com obstáculos é muito importante para a construção de sistemas seguros e robustos [16][19]. As propriedades de domínio são propriedades relevantes no domínio da aplicação. Eles são utilizados em refinamentos para provar que um refinamento é completo [17]. São dois tipos: Hipótese de domínio: são propriedades de domínio do objeto esperado para alcançar um requisito. Eles podem ser usados quando discutindo sobre integralidade de refinamentos de metas. Invariantes de domínio: são propriedades mantidas para segurar o estado de algum objeto de domínio. Modelo de metas. É composto por um conjunto de diagramas de metas interrelacionados que foram reunidos para refinar diferentes metas para alcançar um requisito. No modelo de metas há paralelogramas que representa uma meta e conexões com círculos amarelos que representam refinamentos de uma meta pai (apontado por uma seta amarela) e uma lista de submetas, que representam os requisitos não-funcionais de uma regra de negócios [17]. O modelo de metas possui a seguinte de completude: Um modelo de meta é completo com respeito ao relacionamento de refinamento, se e só se, todo meta folha é uma expectativa, uma propriedade do domínio ou um requisito. Modelo de responsabilidades. O modelo de responsabilidade contém todos os diagramas de responsabilidade de um sistema. Estes diagramas descrevem para cada agente, os requisitos e expectativas dos quais ele é responsável ou que tenha sido atribuído a ele. Deste modo, para que um modelo seja completo com respeito o relacionamento de responsabilidade, é necessário cumprir o seguinte critério de integridade [17]: Regra de completude 2: Um modelo é dito completo com respeito a relação de responsabilidade, se e só se, todo o requisito e expectativa é posto sob a responsabilidade de um e só um agente. Elementos da metodologia kaos. A Tabela 1 contém os elementos KAOS e as descrições que são suportados nos módulos de metas e responsabilidades da ferramenta MK. Tabela 1. Elementos KAOS. Meta Submeta Refinamento de metas Representa os requisitos funcionais de uma regra de negócio Representa os requisitos não-funcionais de uma rega de negócio. Relação que conecta uma meta a outras metas que são chamados de submetas Propriedade de domínio Obstáculo Conexão de obstáculo Conexão de resolução Conexão de conflito Requisito Expectativa Agente Conexão de responsabilidade Conexão de atribuição Representa uma propriedade relevante da aplicação. Situação em que um objetivo do sistema é violado. Relação que conecta um obstáculo a uma meta, a uma expectativa e um requisito. Relação que conecta uma meta de resolução a um obstáculo. Relação que conecta um conflito a uma meta que não pode ser alcançada. Representa uma meta que é colocada sob a responsabilidadee de um agente. Representa uma meta a ser atribuída a um agente. Representa um ator que é responsável por alcançar um requisito e uma expectativa. Relação entre um agente e um requisito. Relação ente um agente e uma expectativa.

6 VISUAL LIBRARY 2.0 A biblioteca Visual Library foi criada pela Netbeans, a fim permitir uma maior variedade de formatos de visualização e modelagem gráfica de objetos, seu objetivo é facilitar a programação visual [20]. A escolha desta biblioteca se deve por estar focada em modelagem, representação e visualização de dados e também pelo vários exemplos de implementações disponíveis no site do NetBeans. INTERFACE DA FERRAMENTA A Tela Inicial, Figura 3, fornece a barra de menu que contém as funcionalidades criar projeto, criar novo diagrama, abrir projeto e imprimir diagrama e a barra de ferramentas com as mesmas funcionalidades. Painel de Estrutura Painel de Editor Figura 3. Tela Inicial da Ferramenta MK. Após acessar as funcionalidades NOVO PROJETO e NOVO DIAGRAMA, o painel de editor ativa a área de trabalho do editor e é apresentada a barra de elementos KAOS que contém os elementos do modelo de metas (metas, submetas, obstáculo, propriedade de domínio e os links refinamento, obstáculo, conflito e resolução) e os elementos do modelo de responsabilidades (requisito, expectativa, agente e os links de atribuição de responsabilidade e expectativa, como pode ser visto na Figura 4. Figura 4. Barra de elementos KAOS e área de trabalho do editor ativos para modelar requisitos.

7 Com a área de trabalho do editor ativa, é possível acessar as funcionalidades inserir elementos e conectar elementos, para isso, o usuário acessa os elementos da metodologia KAOS localizados na barra de elementos KAOS e insere na área de trabalho do editor e em seguida acessa um elemento de link e a seleção partirá primeiramente pelo elemento filho e uma linha surgirá representando a conexão e deverá ser arrastada até o elemento pai. O resultado deste procedimento pode ser visto na Figura 5. Figura 5. Diagrama de teste de um modelo de metas incompleto. CONCLUSÃO O trabalho apresentou o desenvolvimento dos módulos de metas e responsabilidades da ferramenta MK (Modelagem KAOS) para documentação de requisitos baseados nos modelos da metodologia KAOS. Os conceitos estudados da metodologia mostram que requisitos elaborados com KAOS tendem ser mais completos e são aplicados para documentar requisitos de projetos de sistemas críticos. O desenvolvimento da ferramenta MK, possibilitou conhecer algumas APIs nativas do JAVA, que foram necessárias para implementação dos requisitos funcionais. O uso da API Visual Library para implementar a notação da metodologia KAOS foi um trabalho arduo, pois não há atualização de códigos e foi necessário criar adaptações de algumas classes da própria API. Além da implementação dos modelos de objetos e operações, há outros requisitos que poderão ser utilizados no desenvolvimento de trabalhos futuros como: a) Inclusão das funções copiar, recortar, colar, desfazer e refazer. b) Função de salvar diagramas no formato de imagem jpeg. c) Função de imprimir diagrama no formato pdf. d) Alterar a forma como os elementos KAOS são apresentados na área de trabalho do editor com a descrição no interior do elemento. REFERÊNCIAS [1] STEHLE, G. Requirements traceability for real-time systems. Proc. EuroCASE II, London 1990.

8 [2] LAMSWEERDE, A. V. Goal-Oriented Requirements Enginnering: A Guided Tour, Agosto Artigo Convidado para RE 01-5th IEEE International Symposium on Requirements Engineering. [3] LAMSWEERDE, A. van, Requirements Engineering in the Year 00: A Research Perspective. Invited Keynote Paper, Proc. ICSE 2000: 22nd International Conference on Software Engineering, ACM Press, [4] PRESSMAN, R. S., Engenharia de Software, Makron Books, [5] CASTOR, A.P. Rastreamento de Requisitos no processo de desenvolvimento de software orientado a agentes. Dissertação apresentada à Coordenação da Pós-Graduação em Ciência da Informática da Universidade Federal de Pernambuco. Agosto, [6] ÁNTON, A.I. Goal-Based Requirements Analysis. Proceedings of Second IEEE International Conference on Requirements Engineering, Colorado Springs, USA, April, pp , [7] ÁNTON, A.I. Goal Identification and Refinement in the Specification of Software-Based Information Systems, Ph.D. Dissertation, Georgia Institute of Technology, Atlanta GA, [8] REGEV, G. and WEGMANN, A., Where do Goals Come from: the Underlying Principles of Goal- Oriented Requirements Engineering, 13th IEEEInternational Requirements Engineering Conference, Paris, France, August, [9] MYLOPOULOS, J. and CASTRO, J., Tropos: A Framework for Requirements-Driven Software Development, In: Brinkkemper, J. and Solvberh, A. (eds), Information Systems Engineering: State of Art and Research Themes, Lectures Notes in Computer Science, Springer-Verlag, June (2000). [10] DARDENNE, A. LAMSWEERDE, A. Van and FICKAS, S., Goal-Directed Requirements Acquisition, Science of Computer Programming, Vol. 20, [11] LAPOUCHNIAN, A. Goal-Oriented Requirements Engineering: An Overview of the Current Research. Technical report, Universidade de Toronto, Canadá, [12] CASTRO, J., KOLP, M. e MYLOPOULOS, J.: Towards Requirements-Driven Information Systems Engineering: The Tropos Project, 35 pages, In: Information Systems, Elsevier, Amsterdam, The Netherlands, (2002). [13] SANTOS, C. O. DOS. Aplicação do modelo i* em um processo de análise de requisitos orientado a metas. Dissertação apresentada ao Mestrado em Ciência da Computação, da Faculdade de Ciências Exatas e da Natureza, da Universidade Metodista de Piracicaba UNIMEP [14] LAMSWEERDE, A. van. DARIMONT, R. and Ph. MASSONET, "Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt", Proc. RE 95-2nd Intl. IEEE Symp. On Requirements Engineering, March [15] DIAS, A. C. FREITAS. Uma Linguagem Específica do Domínio para uma abordagem Orientada aos Objectivos baseada em KAOS. Trabalho apresentado no âmbito do Mestrado em Engenharia Informática, como requisito parcial para obtenção do grau de Mestre em Engenharia Informática, [16] LAMSWEERDE A. KAOS Tutorial. Cediti, [17] RESPECT-IT. A KAOS Tutorial [18] KAVAKLI E. Modeling organizational goals: analysis of current methods, Proceedings of the 2004 ACM symposium on Applied Computing: Nicosia, Cyprus, [19] BATISTA, D. R. M. C. Adaptar Abordagem KAOS para Especificar Linhas de Produtos de Software. Dissertação apresentada na Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa para obtenção de grau de Mestre. Abril, [20] GAMELEIRA, T. A. MOURA, R. S. GUEDES, L. A. Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica. Universidade Federal do Rio Grande do Norte, Universidade Federal do Piauí, 2008.