Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Transcrição

1 Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Modelagem de processos de software com SPEM Conheça a notação padrão para modelagem de processos De que se trata o artigo: Atualmente o SPEM (Software & Systems Process Engineering Metamodel) é a notação padrão da OMG (Object Management Group) para modelagem de processos de desenvolvimento de software. Com seu meta modelo é possível manter e apoiar uma ampla gama de fragmentos de método e processos no desenvolvimento de projetos. A forte ligação do SPEM com a UML (Unified Modeling Language) faz essa notação se destacar entre as abordagens mais discutidas na literatura técnica relacionada à engenharia de processos. Em que situação o tema é útil: Esse tema é útil para gerentes, arquitetos e engenheiros de software que buscam soluções para aprimorar a modelagem de processos de software. Edson A. Oliveira Junior edson@din.uem.br Professor de Engenharia de Software na Universidade Estadual de Maringá (UEM). Doutor em Ciência da Computação pelo Instituto de Ciências Matemáticas e de Computação (ICMC) da Universidade de São Paulo (USP). Principais temas de pesquisa: linha de processo de software, linha de produto de software, arquitetura de software e avaliação, métricas, engenharia de software experimental, modelos e metamodelos UML. Possui as certificações Java: SCJA, SCJP, SCJD, SCWCD e SCBCD. Maicon Giovane Pazin maiconpazin@gmail.com Graduado em Informática pela Universidade Estadual de Maringá. Trabalha com sistemas para Web, com experiência em tecnologias como PHP, Javascript, CSS, HTML5 e Java. Modelagem de processos de software com SPEM: Neste artigo serão apresentadas especificações de processos de desenvolvimento de software utilizando a linguagem SPEM, mantida pela OMG. Como forma de demonstrar os principais conceitos do SPEM será utilizado o Processo Unificado (PU) para representar um processo de software usual. Atualmente padrões estão emergindo no escopo da modelagem de processos. Alguns vindos da evolução de especificações antigas, enquanto outros são novos conceitos introduzidos ao domínio. Nesse contexto a Object Management Group (OMG) se destaca como uma das mais relevantes organizações internacionais responsáveis por manter padrões abertos para aplicações orientadas a objetos. Um dos principais padrões desenvolvidos pela OMG é o metamodelo SPEM, sendo o SPEM 2.0 a notação padrão da OMG para modelagem de processos de desenvolvimento de software e seus componentes. Essa linguagem possui forte ligação com a UML por meio do seu metamodelo especificado na forma de um modelo MOF (Meta Object Facility) e do seu perfil UML utilizado para definir um conjunto de estereótipos para representação de elementos de processos. Nesse artigo serão apresentados os principais conceitos envolvidos na especificação de processos de desenvolvimento de software utilizando o SPEM 2.0. O Processo Unificado (PU) será utilizado Edição 56 - Engenharia de Software Magazine 37

2 como um processo de software usual para exemplificar o uso do SPEM na modelagem de processos de software. Além disso, algumas ferramentas de modelagem que suportam o SPEM como o EPF (Eclipse Process Framework) Composer e a Enterprise Architect (EA) serão apresentadas. Processos de Software Um processo define quem está fazendo o que, quando e como para alcançar certo objetivo. Na engenharia de software o objetivo de um processo é construir ou alterar um produto de software já existente. Para um processo ser efetivo, ele deve promover diretrizes para o eficiente desenvolvimento de software de qualidade. Quando processos são descritos e discutidos, suas atividades (activities) são normalmente tratadas, como, por exemplo, na especificação de modelos de dados, do projeto e da interface do usuário, além da ordenação cronológica dessas atividades. Quando complexas, as atividades podem incluir subatividades (sub-activities), as quais são tratadas nesse artigo como passos (steps) para a realização de tarefas no contexto de uma atividade. Entretanto, descrições de processos podem também ser incluídas: Produtos (Products) ou Artefatos, os quais são resultados de uma atividade; Papéis (Roles), que refletem as responsabilidades de pessoas envolvidas no processo; Pré e Pós-condições, as quais são declarações que são verdadeiras antes e depois de uma atividade de processo ter sido promulgada ou um produto criado. A definição de um processo de software deve estabelecer e formalizar informações sobre: as atividades e os papéis responsáveis, os artefatos de entrada e de saída que devem ser criados ou mantidos em cada atividade, os procedimentos e ferramentas utilizadas, e o modelo de ciclo de vida utilizado. Há vários anos, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore a produtividade e qualidade dos produtos. Porém, não existe um modelo de processo consolidado que atenda a todos os possíveis domínios de aplicação. Um modelo de processo de software é uma representação abstrata de um processo de software que representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informações parciais sobre o processo. Alguns modelos de processos de softwares existentes na literatura são: Modelo em Cascata, Modelo V, Prototipação, Especificação Operacional, Modelo Transformacional, Desenvolvimento faseado - incrementos e iteração, Modelo Espiral e Métodos Ágeis. O Processo Unificado (PU) é um dos processos de software mais conceituado e pode ser entendido como um framework de processo de desenvolvimento de software para a construção de sistemas orientados a objetos, centrado na arquitetura, iterativa e incremental. O Software and System Process Engineering Metamodel (SPEM) O Software and System Process Engineering Meta-model (SPEM) é um framework conceitual usado para modelagem, apresentação, gerenciamento, intercâmbio e definição de métodos e processos de desenvolvimento de software. A especificação formal da versão 2.0 do SPEM é dividida em duas partes: O SPEM 2.0 Meta-model, que define todas as regras de estruturação, especificadas como um modelo MOF e reutiliza algumas classes fundamentais da UML 2. Também define a notação de diagramas de processo específicos; O perfil do SPEM 2.0, que define um conjunto de estereótipos da UML 2. Tal definição abrange apenas sua representação, tornando-se dependente do SPEM 2.0 Meta-model para as declarações semânticas e de restrições. O principal objetivo do SPEM 2.0 Meta-model é manter e apoiar uma ampla gama de fragmentos de método e processos de diferentes estilos, cenários, níveis de formalidade, modelos de ciclo de vida e comunidades para desenvolvimento de projetos. O perfil UML do SPEM 2.0 torna mais fácil a modelagem de elementos de processos em ferramentas UML através da definição de um conjunto de estereótipos. Uma das principais características do SPEM 2.0 é a possibilidade de especificação de diferentes processos a partir de uma base de conhecimento independente de qualquer processo específico. Para isso, é definida uma clara separação entre conteúdo e processo. O primeiro representa a base de conhecimento, enquanto o segundo representa o processo especificado. O conteúdo expressa elementos para a definição de Produtos de Trabalho (Work Product Definition), de Papéis (Role Definition), de Tarefas (Task Definition), Categorias (Category) e Diretrizes (Guidance). O processo permite expressar os elementos Atividade (Activity), Uso da Tarefa (Task Use), Uso do Papel (Role Use), Uso do Produto de Trabalho (Work Product Use), Processo (Process) e Diretriz (Guidance), representando a instanciação de elementos a partir dos elementos definidos no conteúdo, conforme Figura 1. Figura 1. Terminologia chave definida nesta especificação mapeado para o Conteúdo do Método versus Processo 38 Engenharia de Software Magazine - Modelagem de processos de software com SPEM

3 engenharia A Figura 1 fornece uma visão geral de como os principais conceitos definidos na especificação, estão posicionados para representar conteúdo e processo. Estrutura do metamodelo do SPEM 2.0 A estrutura do metamodelo do SPEM 2.0 é composta por sete pacotes principais, que se dividem em unidades lógicas. As classes envolvidas no metamodelo são definidas em unidades de baixo-nível, porém podem ser estendidas para largas unidades, através de mecanismos que combinam pacotes com adicionais propriedades e relacionamentos para atender requisitos mais complexos na modelagem. Figura 2. Metamodelo do SPEM 2.0 A Figura 2 apresenta os pacotes envolvidos na estrutura do metamodelo do SPEM 2.0 e seus relacionamentos. O pacote Core do metamodelo do SPEM 2.0 é composto por classes e abstrações que servem de base para todos os demais pacotes. O pacote Process Structure define a base para todos os modelos de processos e suporta a criação de modelos de processos simples e flexíveis. O pacote Process Behavior permite estender as estruturas do pacote Process Structure com modelos comportamentais. Entretanto, não define seu próprio comportamento, mas provê links para modelos de comportamento externamente definidos. O pacote Managed Content introduz conceitos para gerenciar o conteúdo textual das documentações construídas em linguagem natural. O pacote Method Content provê conceitos de SPEM 2.0 para usuários e organizações para construir uma base de conhecimento sobre desenvolvimento que seja independente de qualquer processo específico. O pacote Process with Method define novas estruturas existentes para integrar processos definidos com o pacote Process Structure com instâncias do pacote Method Content. Por fim, o pacote Method Plugin introduz conceitos para projetar e gerenciar bibliotecas ou repositórios de processos de larga escala, reusáveis e configuráveis. Elementos de processos definidos pelos SPEM 2.0 Os estereótipos existentes pelo perfil UML do SPEM 2.0 são utilizados para representar todos os elementos definidos pelo seu metamodelo. Além disso, utiliza ícones para representa-los. A Tabela 1 apresenta a relação de alguns ícones com seus respectivos estereótipos. Diversos outros elementos de processos de software são definidos pelo SPEM 2.0, mas nesse artigo estão sendo apresentados apenas os principais elementos utilizados para modelagem de processos de software, conforme apresentado na Tabela 1. A partir dos elementos é possível identificar as atividades que compreendem um processo de software por meio de Atividade, também as tarefas envolvidas em cada atividade por meio do elemento Uso da Tarefa, o passo-a-passo para realização de Ícone Estereótipo Descrição Activity TaskUse Elemento Atividade, que representa um agrupamento de elementos, tais como, outras instâncias de Atividades (Activity), de Uso de Tarefas (Task Uses), de Uso de Papéis (Role Uses) e de Uso de Produtos de Trabalho (Work Product Uses). Elemento Uso da Tarefa (Task Uses), que representa uma Tarefa sendo realizada por um Papel no contexto de uma Atividade. Step Elemento Passo (Step), que representa um dos passos necessários para realizar a Tarefa. WorkProductUse Elemento Uso do Produto de Trabalho (Work Product Uses), que representa um Artefato consumido ou produzido no contexto de uma Atividade específica. RoleUse Elemento Uso do Papel (Role Uses), que representa um Papel responsável por uma ou mais Tarefas específicas. Tabela 1. Ícones para representação de estereótipos do perfil UML do SPEM 2.0 Edição 56 - Engenharia de Software Magazine 39

4 determinadas tarefas por meio do elemento Passo, os papéis responsáveis por realizar cada tarefa por meio do elemento Uso do Papel e os artefatos consumidos ou produzidos em cada uma das tarefas por meio do elemento Uso do Produto de Trabalho. Ferramentas que suportam o SPEM 2.0 Atualmente é possível encontrar diversas ferramentas que suportam o SPEM 2.0. Entre as opções disponíveis existem ferramentas comerciais e gratuitas que possuem suporte completo para a especificação de processos e diagramas baseados na notação UML. Existem também ferramentas baseadas na notação UML que não possuem suporte padrão para o SPEM 2.0, mas que podem ser utilizadas para importar seu perfil UML, como no caso da ferramenta MagicDraw. Uma das ferramentas mais conhecidas é o Eclipse Process Framework Composer (EPF Composer), que trata-se de um editor gratuito do SPEM 2.0 que utiliza uma abordagem baseada em formulários para definição do conteúdo de método (papéis, tarefas, e produtos de trabalho) em uma IDE Eclipse. Nessa ferramenta o conteúdo de método é configurado em padrões de processo usando várias divisões estruturais e modelos de Figura 3. Workflow de Requisitos Modelado com SPEM 2.0 Figura 4. Workflow de Análise Modelado com SPEM 2.0. atividade. A ferramenta IBM Rational Method Composer (RMC) é a versão comercial do EPF Composer. A Enterprise Architect distribuída pela Sparx System é uma ferramenta que oferece uma solução completa para criar diversos modelos de processos de negócios, softwares e sistemas de tempo real baseados na UML. Ela também possui suporte para a versão 2.0 do SPEM permitindo que os usuários possam modelar diagramas utilizando elementos de processos do SPEM de forma rápida e simplificada. O processo unificado de acordo com o SPEM 2.0 O processo unificado fornece diretrizes para desenvolver software com qualidade. Além disso, pode ser especializado para uma ampla classe de sistemas de software, diferentes áreas de aplicação, diferentes tipos de organização, diferentes tipos de níveis e diferentes tamanhos de projetos. O PU organiza o desenvolvimento de software em quatro diferentes fases: Concepção, Elaboração, Construção e Transição. Nessas quatro fases são realizadas diversas iterações que executam de forma linear diferentes workflows definidos pelo processo, que são de Requisitos, de Análise, de Projeto, de Implementação e de Teste. A Figura 3 apresenta dois diagramas modelados na ferramenta Enterprise Architect, apoiada pelo SPEM 2.0, que representa o workflow de requisitos do PU. Os diagramas apresentam o fluxo de atividades realizadas, assim como os elementos de processos envolvidos em cada atividade. O workflow de requisitos tem como propósito essencial permitir descrever os requisitos de um sistema de forma que os stakeholders entendam de forma clara o que o sistema deve ou não fazer. Observe que no diagrama da Figura 3 definimos atividades de identificação de atores e casos de uso, priorização de casos de uso, detalhamento de casos de uso e prototipação da interface com usuário. Além disso, são definidos também os atores que participam das atividades: analista de sistema, arquiteto, especificador do caso de uso, projetista de interface com usuário, dentre outros. Por fim, vale destacar também que o diagrama registra os artefatos consumidos e gerados durante as atividades. Alguns exemplos são: glossário, caso de uso e descrição da arquitetura. A Figura 4 apresenta a modelagem do workflow de análise, responsável por refinar e estruturar os requisitos capturados do sistema, tendo como propósito fornecer um entendimento mais preciso dos requisitos e uma descrição que torne fácil a construção e a manutenção da estrutura de todo um sistema, incluindo a sua arquitetura. Observe a definição de atividades como análise arquitetural, análise de casos de uso e de classes. Note também que os responsáveis por executar 40 Engenharia de Software Magazine - Modelagem de processos de software com SPEM

5 engenharia estas atividades são o arquiteto, engenheiro de caso de uso e engenheiro de componentes. Alguns dos artefatos gerados são a descrição da arquitetura e das classes do projeto. A Figura 5 apresenta a modelagem do workflow de projeto, responsável por traduzir os requisitos para as tecnologias que serão utilizadas no projeto, captura de requisitos sobre subsistemas individuais, interfaces e classes, decomposição do trabalho de implementação em partes menores gerenciadas e captura inicial das interfaces entre subsistemas. Observe que no diagrama da Figura 5 definimos atividades de projeto arquitetural, projeto de casos de uso, projeto de classes e projeto do sistema. Além disso, são definidos também os atores que participam das atividades: arquiteto, engenheiro de caso de uso e engenheiro de componente. Por fim, vale destacar também que o diagrama registra os artefatos consumidos e gerados durante as atividades. Alguns exemplos são: modelo de análise, requisitos suplementares, descrição da arquitetura, dentre outros. A Figura 6 apresenta a modelagem do workflow de implementação, responsável pela construção do sistema a partir dos artefatos gerados pelos anteriores. Nesse workflow também é realizado o planejamento das integrações do sistema em cada iteração do processo e a criação dos testes dos componentes. Observe que no diagrama da Figura 6 definimos atividades da etapa de implementação. Para ela definimos as atividades de implementação da arquitetura, integração de sistemas, implementação de classes, realização de testes unitários, dentre outras. Além disso, são definidos também os atores que participam das atividades: arquiteto, integrador do sistema e engenheiro de componente. Por fim, vale destacar também que o diagrama registra os artefatos utilizados pelas atividades. Alguns exemplos são: plano de integração, modelo de implantação, dentre outros. Por fim, a Figura 7 apresenta a modelagem do workflow de teste, responsável por verificar o resultado da implementação do sistema. Dentre esses propósitos está o planejamento dos testes para cada iteração do processo, além do projeto, implementação, integração e execução dos testes de forma sistemática, gerenciando os resultados obtidos. O diagrama da Figura 7 ilustra o processo de teste modelado. Suas principais atividades são: planejamento, projeto, implementação, execução e avaliação dos testes. O principal ator envolvido nas atividades é o engenheiro de testes. Por fim, temos a definição dos artefatos utilizados e gerados. Figura 5. Workflow de Projeto Modelado com SPEM 2.0 Figura 6. Workflow de Implementação Modelado com SPEM 2.0 Neste processo destaca-se os artefato plano de teste, casos de teste, procedimentos de teste, modelo de testes e avaliação dos testes. Conclusões O SPEM 2.0 é um dos principais padrões desenvolvidos pela OMG para especificações de processos. Através do seu metamodelo é possível realizar uma especificação completa de processos de desenvolvimento de software, enquanto que seu perfil UML fornece uma simplificação desse metamodelo. Também é definida uma clara separação entre conteúdo de método e processos, permitindo o reuso de fragmentos de processos pré-definidos. Edição 56 - Engenharia de Software Magazine 41

6 Figura 7. Workflow de Teste Modelado com SPEM 2.0 A estrutura do SPEM 2.0 é totalmente baseada na UML 2.0. Seu metamodelo é especificado na forma de um MOF enquanto que o perfil UML define estereótipos para cada elemento de processo especificado pelo metamodelo, o que explica as diversas ferramentas já existentes no mercado que suportam esse padrão de forma integral ou parcial. Atualmente o SPEM 2.0 e as ferramentas relacionadas não abordam a execução do processo definidos pela linguagem. Entretanto, diversas pesquisas têm sido publicadas com o intuito de adaptar o SPEM para realizar essa tarefa. Apesar da dificuldade de encontrar estudos sobre a validação do SPEM 2.0 em casos reais, é possível verificar que seu padrão definido pela OMG disponibiliza uma forma organizada para especificação de processos de desenvolvimento de software. O exemplo de aplicação apresentado neste artigo mostra que até mesmo um processo consolidado, como é o caso do processo unificado, pode ser especificado utilizando o SPEM 2.0. Referências BENEDICTO, J.; ROSENBERG, I.; SOLER, I.; ARANA, N.; ESPINOZA, H. Analysis of Standard Process Models. Online, ECLIPSE. Eclipse Process Framework Project (EPF). FUGGETTA, A. Software Process: a Roadmap. In: International Conference on Software Engineering (ICSE), Limerick, Ireland. Anais. New York: ACM, p IBM. Rational Method Composer. Online, JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Software Development Process. Ed. A.W. Longman. 1999, Reading: Addison Wesley Longman. 463, NO MAGIC. MagicDraw. Online, Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: Dê seu Feedback sobre esta edição OMG. Software & Systems Process Engineering Metamodel. Online, OMG. Unified Modeling Language (OMG UML), Superstructure. online, 2011a. OMG. OMG s MetaObject Facility (OMG MOF). Online, 2011b. PFLEEGER, S. L.; ATLEE, J. M. Software Engineering: Theory and Practice. 4a Edição, Publisher: Prentice Hall, Engenharia de Software Magazine - Modelagem de processos de software com SPEM