Ağaç-tohum Algoritması

de Software

O Metamodelo SPEM 2.0 (Software Process Engineering Metamodel) especificado pela OMG [OMG, 2008b] foi utilizado como base para a criação do Metamodelo RAISE. Isso porque o SPEM é um dos metamodelos para o processo de desenvolvimento de software mais referenciados na literatura acadêmica e possui muito dos elementos ne- cessários para a definição do RAISE. Entretanto, a capacidade de expressão do SPEM é insuficiente para descrever o RAISE. Por exemplo, a semântica de regras de negócio de uma tarefa não está estruturada no SPEM, mas é necessária para o RAISE. Ele- mentos necessários para a descrição do Metamodelo RAISE não encontrados no SPEM foram cobertos pelo metamodelo especificado por Eriksson e Penker para processos de negócio [Eriksson & Penker, 2000]. Apesar de esse metamodelo ser mais genérico que o SPEM 2.0 (lembrando que o “processo de desenvolvimento de software” é um “processo de negócio”, quando o negócio é desenvolver software), há nele definições úteis para a Rastreabilidade e que são aplicáveis ao processo de desenvolvimento de software. Esta seção descreve alguns conceitos do metamodelo de Eriksson e Penker e do metamodelo SPEM 2.0 com o detalhamento necessário para o entendimento do Metamodelo RAISE. Para se entender o metamodelo de Eriksson e Penker, deve-se inicialmente en- tender o seu conceito de processo de negócio: “tarefas executadas para o negócio que fazem o estado dos recursos de negócio mudar”. Sendo que Recursos são “objetos do negócio, como pessoas, material, informação, e produtos, que são usados ou produzidos no negócio”. A Figura 3.1 mostra esses elementos no metamodelo.

Nesse contexto, toda tarefa executada que muda o estado do negócio é um Pro- cesso (“Process”). Os Processos descrevem como o trabalho é executado. Processo é composto de Processos (“part of ”), e, principalmente, processos são governados por regras de negócio (“rule”).

Uma regra de negócio é uma sentença que pode controlar ou afetar a execução de um processo de negócio tanto quanto as estruturas dos recursos do negócio. As

Figura 3.1. Metamodelo dos conceitos de modelagem de negócio proposto por Eriksson/Penker (extraído do livro “Business Modeling with UML: Business Pat- terns at Work” [Eriksson & Penker, 2000])

regras de negócio são conceitos importantes para o entendimento do Metamodelo de Informação de Rastreabilidade RAISE e por isso são detalhadas a seguir.

James Odell [Odell, 1998] divide as regras de negócio em regras de derivação (“derivation”) e regras de restrição (“constraint”). Regras de derivação definem como o conhecimento ou a informação pode ser transformada em outro conhecimento ou informação. Uma derivação pode ser uma regra computacional (ex. uma fórmula para calcular um valor) ou uma regra de inferência (ex. se algum fato é verdade, então outro fato inferido precisa ser verdade)[Eriksson & Penker, 2000, pág. 153].

Regras de restrições restringem tanto a estrutura quanto o comportamento de objetos ou processos; restringem a forma como objetos são relacionados uns com outros ou a forma como mudanças de estados de objetos ou processos podem ocorrem.

Uma categoria adicional de regras de negócio definida por Eriksson e Penker e não mencionada por Odell é a categoria que engloba as regras de existência (“existence”). Regras de existência definem sobre que circunstâncias alguma coisa pode existir (o ciclo de vida de um objeto) e quando pode vir a existir (isto é, quando um objeto é criado

ou destruído).

As regras de negócio operam sobre os recursos (“resource”). Recursos são objetos que agem ou são usados nos negócios. São consumidos, produzidos, transformados ou usados pelo processo de negócio. Exemplos incluem material, energia, produtos, pessoas, informação e serviços. Eriksson e Penker definem diferentes tipos de recursos. Um metamodelo dos tipos de recursos está indicado na Figura 3.1, e é inspirado nas definições de Gale e Eldred de quatro tipos recursos concretos [Gale & Eldred, 1997].

• Físico (“Physical”): Uma entidade com realidade material que ocupa um volume no espaço. É alguma coisa que pode ser tocado.

• Abstrato (“Abstract”): Uma ideia ou conceito, normalmente uma composição de outros objetos. Envolve coisas ou conceitos que não são físicos e não podem ser tocados, mas são de importância para o negócio.

• Objeto de informação (“Information”): Uma representação de um conceito, coisa, ou outro objeto de informação. É importante separar o objeto de informação do conceito ou coisa que ele representa.

• Pessoa (“People”): Um ser humano que age no negócio.

São esses os conceitos do metamodelo de Eriksson e Penker que são explorados neste trabalho. Quando necessário servirão como complemento às definições do SPEM 2.0 (Software Process Engineering Metamodel). A Figura 3.2 descreve parte do Me- tamodelo do SPEM. O SPEM, especificado e mantido pela OMG [OMG, 2008b], foi propositalmente concebido com o mínimo de elementos necessários para definir qual- quer processo de desenvolvimento de software. O seu principal objetivo é acomodar uma grande faixa de métodos e processos de desenvolvimento de diferentes estilos, contextos sociais, níveis de formalismos, modelos de ciclo de vida e comunidades.

No SPEM, o trabalho executado no processo de desenvolvimento de software é especificado pelo elemento “Work Definition”. Já o “Task Definition” e “Step” descre- vem o desenvolvimento do trabalho. Essa descrição mostra o comportamento de um papel definido que executa o trabalho ou de muitos papéis definidos participantes e colaboradores durante a execução do “Work Definition”.

O “Work Definition” é um “Classifier” que generaliza todas as definições de traba- lho no SPEM 2.0. Pode conter um conjunto de pré e pós-condições com restrições que necessitam ser validadas antes da execução dos trabalhos e após eles terem terminados. Além dessas restrições há ainda restrições que são atribuídas ao “Work Definition” por ser um “Classifier”.

Figura 3.2. SPEM 2.0 (Extraído do documento “Software & Systems Process Engineering Meta-Model Specification” [OMG, 2008b])

O “Work Definition Parameter” é uma generalização abstrata para elementos que representam parâmetros das definições do trabalho. É usado para declarações de entradas e saídas. As meta-classes dos tipos concretos de entrada ou saída devem ser definidas como subtipos de “Work Definition Parameter”.

O “Work Definition Performer” representa o relacionamento do executor do tra- balho com a definição do trabalho. Diferentes especializações do trabalho irão intro- duzir diferentes tipos de executores.

“Role Use” representa tanto o executor do trabalho (definido no “Work Defini- tion”), como algum participante do trabalho. Se for o executor, o “Role Use” se associa ao “Work Definition Performer” através da especialização “Process Performer”. Sendo um participante, o “Role Use” é registrado na composição “nested Breakdown Element” (vide Figura 3.3) da tarefa e pode ser usada por uma das sub-tarefas como o executor ou “Process Responsibility Assignment”. “Role Use” é valido apenas no contexto de uma tarefa. Não é reusado entre tarefas.

O “Work Product Use” é um elemento que representa um tipo de entrada ou saída para uma tarefa ou representa um participante da tarefa. Se for uma entrada ou saída, então o “Work Product Use” precisa ser relacionado com a tarefa através do “Process Parameter”. Sendo um participante, então o “Work Product Use” é gravado na composição “nested Breakdown Element” (vide Figura 3.3) da tarefa e pode ser usado por uma das sub-tarefas como uma entrada ou saída ou ser relacionado a um

Figura 3.3. A composição Nested Breakdown Element do modelo SPEM (Adap- tado do documento “Software & Systems Process Engineering Meta-Model Spe- cification” [OMG, 2008b])

“Role Use” via “Process Responsibility Assignment”.

“Work Product Use Relationship” expressa uma relação entre produtos de traba- lho. Pode ser usado para expressar diferentes tipos de relacionamentos entre “Work product Uses”. Os tipos de relacionamentos típicos descritos na especificação do SPEM 2.0 são:

• “composição”: expressa que uma instância de produto de trabalho é parte de outra instância de outro produto de trabalho.

• “agregação”: indica que o um produto de trabalho é usado com outro produto de trabalho.

• “dependência” ou “impactado por”: indica que um produto de trabalho impacta outro produto. Esse tipo de relacionamento indica dependência de Rastreabili- dade entre as instâncias dos produtos de trabalho que devem ser consideradas quando se cria ou altera esses produtos de trabalho.

Os tipos de relacionamentos entre os “Work Product Use”, principalmente o de “dependência”, devem ser usados para registrar Ligações de Rastreabilidade. Apesar disso, esses relacionamentos não são usados no Metamodelo RAISE. Outros mecanismos com semântica mais rica do ponto de vista da Rastreabilidade são utilizados para representar essas ligações.

São esses os elementos do SPEM 2.0 e do metamodelo Eriksson e Penker relevantes para este trabalho. O Metamodelo de Informação de Rastreabilidade RAISE, que utiliza os elementos aqui apresentados, é mostrado na seção seguinte, 3.3.