DOCUMENTANDO VARIABILIDADE EM CASOS DE USO EM LINHAS DE PRODUTOS DE SOFTWARE

(1)

DOCUMENTANDO VARIABILIDADE EM CASOS DE USO

EM LINHAS DE PRODUTOS DE SOFTWARE

IGOR WANDERLEY CAVALCANTI

Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao

(2)

IGOR WANDERLEY CAVALCANTI

DOCUMENTANDO VARIABILIDADE EM CASOS DE USO EM

LINHAS DE PRODUTOS DE SOFTWARE

Monografia apresentada ao Curso de pós-graduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos.

Professor: Prof. Jaelson Brelaz de Castro

(3)

RESUMO

Pouca atenção tem sido dispensada à engenharia de requisitos pelas fábricas de software. Além de poucas fábricas de software se preocuparem em promoção de reuso de componentes no desenvolvimento de seus produtos. As empresas tendem a documentar produtos que poderiam fazer parte de uma linha de produtos separadamente. Dificultando assim, encontrar similaridades e variabilidades entres os produtos desenvolvidos e gerando retrabalho na geração de especificações e componentes para seus produtos. Se técnicas de linhas de produtos de software fossem utilizadas esse problema seria menor. Este trabalho introduz duas técnicas para especificação de linhas de produto de software.

(4)

LISTA DE FIGURAS

Figura 1: Processo de Construção e Produção de uma LPS...9

Figura 2: Feature Model da Mobile MMS application...9

Figura 3: Carregamento de classes no Tomcat...11

Figura 4: Logging no Tomcat...11

Figura 5: Overview do processo de combinação...15

Figura 6: Feature Model do eShop...16

Figura 7: Exemplo de Configuração de Produto...20

Figura 8: Exemplo de notação do Feature Model do PLUSS...21

Figura 9: Meta-modelo do PLUSS...23

Figura 10: Notação para descrição de variações no PLUSS...24

(5)

SUMÁRIO

RESUMO...3

1. Introdução...6

2. Conceitos abordados...7

2.1 Linha de Produtos de Software...7

2.2 Orientação à Aspectos...10

3. Modelos de Modelagem de Variabilidade de Cenários...14

3.1. MSVCM – Modelling Scenario as Crosscutting Mechanisms...14

3.1.1 Feature Model...15

3.1.2 Especificação de Casos de Uso...16

3.1.3 Configuration Knowledge ...18

3.1.4 Configuração do Produto...19

3.2. PLUSS – Product Line Use case modeling for Systems and Software engineering...21

3.2.1 Modelagem de Casos de Uso...22

3.2.2 Notação de variabilidade na especificação de casos de uso ...23

3.2.3 Geração de produtos no PLUSS ...24

3.2.4 Comparativos das abordagens...24

4 Conclusões...27

5 Referências...28

6 Anexo...29

6.1 Modelo MSVCM para o Crisis Management System...29

(6)

1. Introdução

Devido à grande competitividade na indústria de software e o aumento de capacidade de produção, também cresce a demanda por sistemas mais complexos e com mais qualidade [1, 15]. Desta forma, a competitividade aumenta de acordo com a sua habilidade para reagir rapidamente às mudanças do mercado e aos requisitos dos usuários.

Então, hoje em dia vemos que a necessidade de software se torna cada vez mais presente. Contudo, ao mesmo tempo em que essa necessidade aumenta, a exigência do público consumidor também aumenta.

Um tendência se torna mais presente, é que o usuário final de produtos de software quer que o produto final seja cada vez mais customizável, e não um simples produto de caixa, em que o produto de software é igual para todos os consumidores. Essa tendência também é válida tanto para os desenvolvedores de software, que querem componentes de software cada vez mais customizáveis, como para os grandes clientes que gostariam de utilizar esse software em diversos produtos diferentes.

Esses consumidores querem aplicações com personalização, que possam permitir a seleção de todas as funcionalidades presentes, sem que, para isso, haja aumento dos custos ou atraso da entrega do aplicativo. Entretanto, o custo de desenvolvimento de uma aplicação personalizada é alto, em contraste com o desenvolvimento em massa de um único sistema, através do qual o custo se dilui pelas diversas cópias iguais que são vendidas. Esse é o cenário ideal para o conceito de linhas de produto de software (LPS), que permite o desenvolvimento de aplicações customizadas em massa.

Um importante fator para o sucesso de uma LPS é a documentação para o gerenciamento de seus requisitos. Facilitando, assim, o gerenciamento da LPS, a análise de impacto de modificações, a evolução da linha e a validação da mesma. Nesse trabalho serão abordadas duas soluções de documentação de casos de uso em LPS.

No capítulo dois são descritos os principais conceitos estudados durante a composição desse trabalho, Linha de Produtos de Software e Orientação à Aspectos. No capítulo três as duas soluções de documentação de requisitos em LPS são introduzidas e, após isso, uma pequena comparação entre elas é efetuada. No quarto e último capítulo, são apresentadas as conclusões obtidas nessa monografia.

(7)

2. Conceitos abordados

2.1 Linha de Produtos de Software

Nos últimos anos o uso de computadores cresceu intensamente. Com isso cresceu também a demanda e a complexidade do software exigido. O comportamento do público consumidor de software se modificou bastante. Os clientes de hoje não se contentam mais com uma única versão de um programa, que seja igual para todos. Eles querem sistemas personalizados, que tenham apenas um determinado leque de funcionalidade escolhido por eles, mas não querem que isso comprometa o custo final e nem o prazo de entrega das aplicações. Além disso, o mercado de software vem se tornando cada vez mais competitivo, novas empresas são criadas constantemente e, com elas, novos produtos são lançados no mercado. Com isso, os desenvolvedores de sistemas são praticamente obrigados a atenderem todas as necessidades dos consumidores, com o menor custo possível, para não perder o cliente. Entretanto, o desenvolvimento de aplicações personalizadas gera altos custos, em contraste com o desenvolvimento de aplicações em massa, que possui um baixo custo por reutilizar a mesma aplicação para diversos clientes, mas limita as funcionalidades dos sistemas.

Hoje as empresas têm que produzir software em larga escala e deve ser customizado para vários clientes. Um exemplo seria um empresa de jogos para celulares. Essa empresa não poderia se restringir à um único celular de uma única empresa. Já que temos celulares produzidos por diversas empresas, onde cada celular pode ter tamanhos de telas diferentes, APIs diferentes, diversos recursos (capacidade de som, de rede, recurso gráfico, etc), que acarretam mudanças no produto final entregue ao cliente da empresa.

Nesse cenário surge o conceito de Linhas (ou famílias) de Produtos de Software. Onde essa abordagem de desenvolvimento procura promover o reuso planejado de componentes, permitindo produção em larga escala de diversos produtos customizados.

O processo de desenvolver um conjunto de produtos que compartilha um conjunto de features é chamado de prática de desenvolvimento de software utilizando Linhas de Produto de Software [2, 14].

Assim, uma LPS nada mais é do que um conjunto de produtos (software) com várias funcionalidades em comum, mas com variações entre si. Parnas [16] diz que “em uma LPS o conjunto de propriedades comuns dos programas é tão grande que é mais vantajoso estudar as propriedades comuns entre os programas antes de analisar as características individuais de cada membro”. Já Clements e Northrop [17] definem LPS como “um conjunto de sistemas de software

(8)

que compartilham um conjunto gerenciável comum de características que satisfazem as necessidades específicas de um segmento de mercado particular e que são desenvolvidas de um conjunto de ativos base comum, de modo planejado”. Assim, em uma LPS, é feito um planejamento de que características comuns serão reutilizadas entre os produtos que serão desenvolvidos.

O processo de desenvolvimento de software utilizando a abordagem de produção de linhas de produtos de software tem duas atividades importantes: O desenvolvimento de Core Assets e o desenvolvimento do produto em si. Esses processos também podem ser chamados de Engenharia de Domínio (Domain Engineering) e Engenharia de Aplicação (Application Engineering). A Engenharia de Domínio é responsável por definir a estrutura que representará toda a família de produtos, incluindo os pontos comuns e as variações presentes nos produtos da linha. Essa estrutura é formada pelos artefatos gerados, como documentos de requisitos, diagramas arquiteturais, diagramas UML [18], arquivos fonte de código, documentos de teste, etc.

Na Engenharia de Aplicação, as aplicações da linha (produtos) são derivadas da LPS gerada no processo anterior. Ou seja, nessa etapa são exploradas as variações da linha, cada produto é ligado às suas variações, de acordo com suas necessidades. Os artefatos gerados no primeiro processo são denominados artefatos de domínio (domain artifacts), enquanto os gerados no último processo são conhecidos como artefatos de aplicação (application artifacts).

Na Figura 1 temos uma visão geral do processo de desenvolvimento de uma LPS. Repare que, os produtos gerados (Product models, parte inferior da figura) possuem artefatos que são variações dos artefatos de domínio. Na literatura, diversos modelos gráficos foram propostos para representar uma LPS (modelos esses que servem para especificar variações em linhas de produtos), sendo o modelo de features (feature model, Figura 2) proposto em [5, 19] uma das mais utilizadas.

(9)

Na Figura 2, a aresta com uma bola aberta indica que uma determinada feature é opcional, as arestas com a bola preenchida são features obrigatórias. Já as arestas que são separadas por um arco aberto indicam que suas respectivas features são alternativas (somente um entre as alternativas), enquanto que se o arco for preenchido, qualquer quantidade de features pode ser escolhida, inclusive zero e todas.

Diversas são os benefícios trazidos pelo uso de LPS [2, 20], dentre eles destacam-se:

1. Redução nos custos de desenvolvimento, devido ao reuso de artefatos de domínio que são construídos uma única vez;

2. Melhora na qualidade dos produtos, pois os artefatos presentes nos produtos gerados já foram previamente utilizados e testados em outros produtos, assim, a probabilidade desses artefatos

Figura 2: Feature Model da Mobile MMS application Figura 1: Processo de Construção e Produção de uma LPS

(10)

apresentarem erros é bastante reduzida;

3. Redução no tempo de desenvolvimento, pois apenas os artefatos específicos de uma determinada aplicação precisam ser desenvolvidos. Grande parte de um produto gerado é fruto do reuso dos artefatos de domínio;

4. Redução nos custos de manutenção, pois agora a manutenção é feita em um único lugar e todos os produtos podem ser gerados novamente já com os erros corrigidos.

Apesar de tantos benefícios, existem também alguns fatores que devem ser considerados antes de se optar pelo uso LPS, como o custo e o tempo total do desenvolvimento do primeiro produto, que são consideravelmente maiores do que no desenvolvimento de um sistema único (estima-se que o custo de uma LPS passa a ser menor do que o custo de sistemas únicos quando a LPS gera, pelo menos, três produtos [17]). Assim, é recomendável que uma instituição faça um estudo detalhado antes de adotar a abordagem de LPS em seu processo de desenvolvimento, pesando os pontos positivos e negativos, com objetivo de verificar se essa abordagem pode ou não trazer benefícios para essa determinada empresa.

2.2 Orientação à Aspectos

A Orientação a Objetos está consolidada e seu uso cresce a cada dia. Hoje vemos diversos tutoriais sobre esse paradigma e universidades ensinando esse novo paradigma para seus alunos.

A Orientação a Aspectos (OA) é um paradigma que estende a Orientação a Objetos (e outros, como o paradigma estruturado) introduzindo novas abstrações. Estes novos elementos são destinados a suprir deficiências na capacidade de representação de algumas situações[7, 8, 9].

Um dos elementos centrais da OA é o conceito de Interesse (concern), que são as características relevantes de uma aplicação. Um interesse pode ser dividido em uma série de aspectos que representam os requisitos. Os aspectos podem ser agrupados no domínio da aplicação, compondo os interesses funcionais, que formam a lógica de negócio. Ou podem ser agrupados em elementos que prestam suporte aos interesses funcionais nomeados por interesses sistêmicos, e também chamados de ortogonais ou transversais. Quando duas propriedades devem ser compostas de maneira diferente e ainda se coordenarem, diz-se que elas são ortogonais entre si. A tentativa de implementar um interesse sistêmico com a aplicação da Orientação a Objetos tem como resultado códigos que se espalham por todo o programa. Para isso dá-se o nome de código espalhado ( Scattering Code ).

(11)

O código espalhado pode ser classificado em: 1. Bloco duplicado.

2. Bloco complementar.

A implementação de vários interesses sistêmicos e funcionais em um mesmo módulo com a orientação a objeto resulta no código chamado de emaranhado ( Tangled Code ). O código espalhado e emaranhado dificulta da manutenção e a reutilização de código.

Como exemplo de espalhamento e emaranhamento de código, temos o exemplo do servidor de aplicações Tomcat [25]. Este exemplo foi usado em diversos artigos que falam sobre programação orientada a aspectos.

Nas figuras 3 e 4 temos a decomposição do Tomcat em classes. As barras verticais indicam os diversos pacotes do servidor de aplicações. O comprimento dessas barras indica a quantidade de linhas de código desses pacotes. Na figura 3, o código correspondente ao interesse de carregamento

Figura 3: Carregamento de classes no Tomcat

(12)

de classes foi marcado em vermelho. Este interesse no Tomcat é um interesse modular considerando a decomposição do sistema. A implementação deste interesse está contido em poucas classes e não interfere na implementação de outros interesses da aplicação. A figura 4 representa a implementação do interesse de logging no Tomcat. O interesse de logging no Tomcat é transversal e sua implementação se espalha por diversas classes da aplicação, e sua implementação interfere na implementação de outros interesses..

Segundo Winck e Goeten [9, 11], a programação orientada a aspectos foi criada no fim da década de 1990, mais precisamente no ano de 1997, em Palo Alto, nos laboratórios da Xerox, por Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier e John Irwin [12, 13]. O objetivo era construir uma abordagem que fosse um conjunto não necessariamente homogêneo, que permitisse à linguagem de programação, composta por linguagem central e várias linguagens específicas de domínio, expressar de forma ideal as características sistêmicas (também chamadas de ortogonais ou transversais) do comportamento do programa. A essa abordagem dá-se o nome de meta-programação.

Uma forma de caracterizar uma linguagem de meta-programação é pelo seu compilador. A princípio, os compiladores destinados à orientação a aspectos não geram um produto final (um programa compilado e executável ou interpretável), mas um novo código. Nessa primeira compilação são acrescidos elementos ao código, para dar suporte às novas abstrações. O código resultante necessita ser novamente compilado para que seja, então, gerado o produto final. Outra característica da meta-programação presente na POA é a reflexão computacional, em que parte do código gerado é destinada a alterar características do próprio programa.

A POA estende outras técnicas, como a POO ou programação estruturada, propondo não apenas uma decomposição funcional, mas também sistêmica do problema. Isso permite que a implementação de um sistema seja separada em requisitos funcionais e não-funcionais, disponibilizando a abstração de aspectos para a decomposição de interesses sistêmicos, além dos recursos já oferecidos pelas linguagens de componentes, como Java, por exemplo.

A programação orientada a aspectos tem alguns conceitos fundamentais [7, 10, 11]:

Pontos de junção (join points): O pontos de junção podem ser qualquer parte local de um

código. Por exemplo: chamada de método, criação de determinados tipos de objetos, ocorrência de exceções, etc.

(13)

Pontos de Atuação (pointcuts): Pointcuts são elementos do paradigma que ajuda a definir

um ponto de junção. Basicamente, opintcuts são regras para definir os eventos que os pontos de junção irão atuar.

Adendos (advices): São pedaços de código que serão executados nos pontos de junção.

Então cada advice tem o seu pointcut e seu código associado.

Aspectos: Um aspecto funciona como uma classe para a POO. Um aspecto agrupa advices

(14)

3. Modelos de Modelagem de Variabilidade de Cenários

Para o suporte adequado de pontos de variação, e, consequentemente termos uma boa gerência tantos dos requisitos e dos core assets que devem ser desenvolvidos para uma família de produtos de software, é necessário uma boa documentação onde seja possível ver claramente onde estão os pontos de variação do produto e qual o impacto de introduzir um novo requisito na família.

Para tanto, existem diversas propostas de como fazer isso. Temos diversas abordagens e ferramentas para auxiliar nessa tarefa. Temos as abordagens PLUC [24], PLUSS[22], MSVCM[21], Modelagem de Casos de Uso de linhas de produtos de software baseado em Aspectos. E, para cada abordagem citada existe uma ferramenta de apoio.

Nesta seção abordaremos dois tipos de modelagem de casos de uso com variabilidade de produtos. Abordaremos a metodologia PLUSS e o MSVCM. Ambas as abordagens foram vistas na cadeira de Linhas de Produtos de Software do Programa de Pós-Graduação do Centro de Informática da UFPE.

Será dada uma explicação de como funciona as abordagens de modelagem de casos de uso com variabilidade e no capítulo seguinte faremos um breve comparativo. Será usado tanto os exemplos que constam nos artigos base para este texto, assim como, os exercícios que foram feitos em sala de aula para a aplicação das abordagens.

3.1. MSVCM – Modelling Scenario as Crosscutting Mechanisms

O MSVCM [21] foi motivado pelo trabalho de Kiczales, onde foi introduzida a noção de programação orientada à aspectos. Então, o MSVCM se preocupa em fazer uma separação entre a especificação de cenários e a gerência de variabilidade. Essa metodologia usa alguns artefatos, são eles: Casos de uso, Modelo de Features (Feature Model – FM), Configuração do produto (Product Configuration – PC) e a Configuração de Conhecimento (Configuration Knowledge – CK).

Essa abordagem confia no processo de combinação (weaving process) dos interesses (concerns), dos artefatos citados acima, que cruza cada um resultando num modelo de casos de uso de um produto específico (ver figura 5).

(15)

3.1.1 Feature Model

O Feature Model [2, 5, 6 ] tem uma contribuição importante para o processo de combinação do MSVCM, pois ele é usado para verificar se a configuração de um produto é uma configuração válida para a linha de produto. Foram implementadas algumas funções em Haskell para tratar esse tipo de validação. Essas funções verificam se todas as contraints definidas no Feature Model são satisfeitas pela configuração do produto.

Os modelos de caso de uso definem comportamentos esperados pelo membros da LPS. Os cenários podem ser opcionais, ter parâmetros e modificar o comportamento de outro cenários. O modelo de casos de uso do MSVCM é composto de casos de uso e de casos de uso aspectuais. Aqui vemos a proximidade da abordagem MSVCM com a programação orientada à aspectos. Pois os casos de uso são definidos normalmente, o caso de uso tem um nome, uma descrição e uma lista de cenários (que são compostos por um conjunto de passos (usuário x sistema)). E os casos de uso aspectuais tem um nome e uma lista de adendos (advices), que podem ser usados para estender o comportamento dos casos de uso. Acontece das mesma forma na programação orientada a objetos onde as classes e métodos são definidos normalmente e os aspectos podem modificar tanto as classes e métodos sem precisar alteração do código original.

Assim como é definido em vários artigos que tratam de Linhas de Produtos de Software, “Uma LPS é um conjunto de produtos que compartilham características, mas diferem um do outro

de acordo com um conjunto de variabilidades.” Ainda temos a seguinte definição: “ Engenharia de Linhas de Produtos de Software explora similaridades numa linha de sistemas de software enquanto gerencia as variabilidades para prover reusabilidade (de artefatos como requisitos, modelos, componentes, etc), redução de 'time to market' e aumento da qualidade do produto”.

(16)

Para o exemplos da abordagem será usado o eShop [23] que é largamente utilizado em artigos sobre linhas de produtos de software.

3.1.2 Especificação de Casos de Uso

Abaixo teremos alguns cenários e advices para demostrar o funcionamento da abordagem:

Proceed to Purchase: Este cenário obrigatório especifica o comportamento comum para

confirmação de uma compra. Repare no parâmetro <SM> no passo P2 do caso de uso. Este parâmetros permitem o reuso do cenário Proceed to Purchase para diferentes configurações da feature Shipping Method. O artefato Configuration Knowledge é responsável por relacionar os parâmetros com as features.

A anotação [CustomerPreferences] (Passo 3) é outro ponto de variação do cenário Proceed

to Purchase. Esta anotação também é usada no passo S3 do cenário Search for Products (Tabela

4) , esta anotação pode ser usada como ponto de junção (pointcuts) nos advices definidos nos casos de uso aspectuais.

(17)

Id: SC01

Descrição: Proceed to Purchase

Id User Action System Response

P1 Fill in the requested information and select the

proceed option Request the shipping method and address P2 Select one of the available shipping methods

( <SM> ), fill in the destination address and proceed.

Calculate the shipping costs

P3 Confirm the purchase Execute the order and send a request to the Delivery System to dispatch the products. [CustomerPreferences]

Tabela 1: Cenário Proceed to Purchase

Buy Product: Este advice permite a um cliente comprar produtos de uma loja de comércio

eletrônico. Esta opção só é disponível para membros da LPS que não tenham as features Shopping

Cart e Bonus configuradas. Este advice introduz um comportamento opcional antes do joint point

identificado na cláusula especificada no caso de uso aspectual. Neste caso foi definido como o passo P1 definido no cenário Proceed to Purchase. Esta cláusula pode referenciar tanto Ids de passo como anotações constantes nos casos de uso. Aqui vemos que seriam mais recomendado o uso de anotações ao invés de identificadores de passos para os advices, pois os requisitos podem mudar bastante, assim como a numeração dos passos dos casos de uso. Isso implicaria em revisar todos os casos de uso e modificar os joinpoints de possíveis advices associados, para a corretude da documentação.

Id: ADV01

Descrição: Buy a specific product Before: P1

B1 Select the buy product option Present the selected product. The user can change the quantity of items he wants to buy. Calculate and show the amount to be paid.

B2 Select the confirm option. Request payment information. Tabela 2: Advice Buy a Specifc Product

Buy Products with Shopping Cart and Bonus: Este advice permite a compra de produtos

que foram adicionados previamente no carrinho de compras. Este advice estende o comportamento do cenário Proceed to Purchase introduzindo o comportamento específico para as features

(18)

Id: ADV02

Descrição: Buy Products using a Shopping Cart Before: P1

C1 Select the checkout option Present the items in the shopping cart and the amount to be paid. The user can remove items from the shopping cart.

C2 Select the confirm option. Request bonus and payment information. Tabela 3: Advice Buy Products using a shopping cart

Search for Products: Este cenário obrigatório permite a um usuário pesquisar por produtos. Será apresentado somente o passo S3 para este exemplo. O passo apresentado faz a busca de acordo com o critério de entrada. Deve ser notado que este cenário também contém a anotação

[CustomerPreferences]. Portanto, qualquer advice que contenha esta anotação como joinpoint

estenderá este cenário.

Id: SC02

Descrição: Search for products

... ... ...

S3 Inform the search criteria. Retrieve the products tat satisfy the search criteria. Show a list with the resulting products. [CustomerPreferences]

Tabela 4: Cenário Search for Products

Register User Preferences: Este advice atualiza as preferencias do usuário de acordo com a

história de buscas e compras do usuário. Este comportamento é iniciado após qualquer passo com a anotação [CustomerPreferences] e a feature Update User Preferences esteja presente.

Id: ADV03

Descrição: Register User Preferences After: [CustomerPreferences]

R1 - Update the preferences based on the search results or purchased items.

Tabela 5: Advice Register User Preferences

3.1.3 Configuration Knowledge

O Configuration Knowledge contém uma lista de items de configuração em que expressões de features e tarefas (tranformações) são usadas para geração automática de membros da LPS.

(19)

da família de produtos de software. Abaixo na tabela 6, temos um exemplo de um configuration knowledge válido para um produto.

Feature Expression Tasks

eShop select scenario SC01

select scenario SC02

not (Shopping Cart and Bonus) evaluate advice ADV01 (Shopping Cart and Bonus) evaluate advice ADV02 Update User Preferences evaluate advice ADV03 Shipping Method bind SM to Shipping Method

Tabela 6: Exemplo de Configuration Knowledge A partir da tabela 6 podemos concluir algumas coisas:

1. Os cenários Proceed to Purchase(SC01) e o cenário Search for Products (SC02) são obrigatórios, já que os cenários citados estão relacionados com a feature raiz obrigatória do Feature Model da LPS.

2. O advice Buy Product (ADV01) é usado em produtos que não tem as features

Shopping Cart e Bonus selecionadas. Se ambas forem selecionadas o advice Buy Product with Cart (ADV02) deve ser selecionado para o produto. Como vemos

que existe uma dependência mútua entre as features, elas não podem ser selecionadas isoladamente.

3. O advice Register User Preferences (ADV03) não é usado a menos que na composição do produto, a feature Update User Preferences tenha sido selecionada.

4. Referências à variável SM são ligadas as alternativas selecionadas da feature

Shipping Method.

3.1.4 Configuração do Produto

Este artefato do MSVCM identifica um membro específico da LPS. Essa identificação é caracterizado pela configuração das features do produto. Um propriedade importante dessa configuração do produto, é que esta deve estar de acordo com a feature model do produto. Um modo de se fazer essa representação é utilizando o Feature Modeling Plugin [26], que é um plugin do eclipse. Abaixo temos um exemplo de configuração de 2 produtos da família do eShop.

(20)

Nas tabelas 7 e 8 temos os cenários SC01 e SC02 gerados a partir da configuração 2 do exemplo da figura 4. A seleção dos cenários SC01 e SC02 é consequência da configuration knowledge visto na tabela 6, e diretamente responsável pelos cenários vistos nas tabelas 7 e 8. Podemos ver que os passos dos advices ADV02 e ADV03 foram incluídos pois as features

Shopping Cart, Bonus e Update Preferences foram selecionadas na configuração do produto. E por

último vimos que a variável SM no quarto passo do cenário Proceed to Purchase foi substituída pelos valores selecionados na configuração do produto.

Cenário: Search for Products

… ... ...

3 Inform the search

criteria Retrieve the products that satisfy the search criteria. Show a list with the resulting products. 4 - Update the preferences based on the search results or purchased items.

Tabela 7: Cenário SC02 gerado depois da configuração do produto

Cenário: Proceed to Purchase

1 Select the checkout option. Present the items in the shopping cart and the amount to be paid. The user can remove items from the shopping cart.

2 Select the confirm option. Request bonus and payment information. 3 Fill in the requested information and

select the proceed option. Request the shipping method and address. 4 Select one of the available shiping

methods (Economical, Fast), fill in the destination address an proceed.

Calculate the shipping costs.

5 Confirm the purchase Execute the order and send a request to the Delivery System to dispatch the products.

6 - Update the preferences based on the search results

(21)

Tabela 8: Cenário SC01 gerado depois da configuração do produto

3.2. PLUSS – Product Line Use case modeling for Systems and Software

engineering

O PLUSS é baseado no trabalho de Griss et al. no FeatuRSEB[27]. Assim como no trabalho de Griss et al., Eriksson argumenta que o feature model se encaixa melhor na análise de domínio que os diagramas de casos de uso da UML e que o feature model pode ser usado como um modelo de alto nível para visualização da LPS.

Então, o PLUSS propõe uma abordagem melhorada de como gerenciar variações de comportamento nos modelos de caso de uso. Sendo melhor para se fazer um rastreamento de variações de comportamentos nos casos de uso e também melhor para se gerar modelos de caso de uso específicos de um produto de acordo com modelos de caso de uso de uma família de produtos de software.

O uso de Feature Model foi proposto por Kang et al. em 1990 como parte da Feature

Oriented Domain Analysis (FODA) [5, 6, 19]. Originalmente o FODA descreveu as features como:

Obrigatórias, Opcionais e Alternativas e que poderiam se relacionar como “requer” ou “exclui” com outras features. Eriksson et al. fez algumas modificações no feature model proposto por Kang et al.. A primeira delas foi alterar a relação de features alternativas do FODA, que seria “exatamente de um de muitos” para “pelo menos um de muitos”. Essa tipo de relacionamento é chamado de “Multiple Adaptor”. O relacionamento de features alternadas do FODA é definido pelo PLUSS como “Single Adaptor”. E, por último, o PLUSS fez pequenas modificações nas notações do Feature Model definidos pelo FODA como vemos na figura 8 .

(22)

3.2.1 Modelagem de Casos de Uso

O PLUSS segue o procedimento padrão de escrita de casos de uso. A diferença é que o PLUSS coloca notação especial para identificação dos passos. Então é feito um caso de uso único para a família inteira de produtos, com a intenção de se fazer um melhor gerenciamento de variabilidade no modelo.

Foram identificados alguns tipos de variações de casos de uso que poderiam existir numa família de produtos.

A primeira é a respeito do caso de uso como um todo. Ou seja, o caso de uso pode estar presente em um produto e não em outro na mesma família de produtos. Então o PLUSS modela isto relacionando um ou mais casos de uso com uma feature presente no feature model.

A segunda variação é a respeito de cenários presentes nos casos de uso. O PLUSS modela isto relacionando um ou mais cenários com uma feature de qualquer tipo presente na feature model.

A terceira variação acontece de acordo com a inclusão de passos nos cenários de caso uso. Para se fazer esta modelagem o PLUSS relaciona um ou mais passos com features de qualquer tipo presente na feature model.

A quarta variação ocorre em interesses transversais que podem afetar os casos de uso nos mais diferentes níveis. Esses interesses transversais são modelados como parâmetros de caso. E, estes parâmetros podem relacionados a um conjunto de single adaptors da feature model.

O PLUSS também propôs um meta-modelo para descrever a integração de features, casos de uso e realização de casos de uso. Este meta-modelo visa descrever como casos de uso, cenários e passos de cenários são incluídos na seleção de features. Na figura 9 temos o meta-modelo do PLUSS.

(23)

3.2.2 Notação de variabilidade na especificação de casos de uso

Assim como na UML, o PLUSS identifica cada passo do caso de uso com um número. Mas, para a identificação das variabilidades da LPS, é feita uma modificação de como esses passos são numerados. A seguir veremos como seria a notação proposta pela abordagem PLUSS.

Cada passo identificado com um número, está descrevendo um passo obrigatório para o cenário, assim como a notação usual de casos de uso o faz.

Agora, se vários passos forem identificados com o mesmo número de identificação, está sendo mostrados passos obrigatórios mutuamente exclusivos de um passo de um cenário. Estes passos devem estar relacionados com um conjunto de features que se relacionam como single

adaptor e este conjunto com uma feature obrigatória, que seria “feature-pai” na árvore de features

no feature model.

Vários passos identificados com o mesmo número e este número é seguido de uma letra, ali é identificado passos alternativos de uma feature obrigatória, onde pelo menos um passo deve ser escolhido. Estes passos devem estar relacionados a um conjunto de features “multiple adaptor” onde estas features sejam filhas de uma feature obrigatória no feature model.

Um passo identificado com um número entre parênteses indica um passo opcional no cenário. Passos opcionais precisam estar relacionados à uma feature opcional no feature model.

Passos identificados com o mesmo número entre parênteses e este número é seguido de uma letra, ali é identificado um conjunto de alternativas para um passo opcional do cenário e pelo menos um passo deve ser selecionado. Estes passos devem estar relacionados com um conjunto de features “multiple adaptor” e estas features devem ser filhas de uma feature opcional no feature model.

Se tivermos vários passos identificados pelo mesmo número entre parênteses, então esses

(24)

passos são mutuamente exclusivos para um passo opcional no cenário. Estes passos devem estar relacionados a um conjunto de features que se relacionam como “single adaptor” e que sejam filhas de uma feature opcional no feature model.

Por fim, o PLUSS utiliza a notação de variáveis dentro dos casos de uso. As variáveis locais são identificadas quando o nome da variável é precedida por um '$' e uma variável global é identificada quando seu nome é precedida por uma '@'. Na figura 10 é demonstrada toda a notação de casos de uso explicada.

3.2.3 Geração de produtos no PLUSS

A geração da especificação dos casos de uso de um produto de um LPS é feita escolhendo as features que devem estar presentes no produto e então é feito um filtro no modelo onde as features que não tenham sido escolhidas sejam retiradas dos relatórios gerados. O PLUSS pode gerar três tipos de relatórios: Use Case Survey, onde serão incluídos todos os casos de uso do produto e os relatórios Use Case Specifications e Use Case Realizations para os casos de uso incluídos no Use Case Survey.

3.2.4 Comparativos das abordagens

As duas abordagens apresentadas foram largamente utilizadas e estudadas na segunda parte

(25)

do centro de informática da UFPE.

Nesta cadeira as duas abordagens nos foram apresentadas e discutidas. Depois tivermos a parte de aplicação das abordagens apresentadas. Nos eram dadas especificações de produtos de uma mesma família, as features de cada produto e a feature model da linha de produtos a ser documentada. As especificações nos eram dadas na forma de casos de uso normais. Assim como foi dito na introdução, para uma linha de produtos de software se torna inviável a documentação separada de cada produto da linha. Pois dificulta muito a manutenção desta e também o encontro de similaridades entre os produtos. Assim como também foi dito, o reuso se torna oportuno e ocasional. Se equipes diferente desenvolvem os produtos da família, pode haver reimplementação dos componentes do produto, gerando assim, retrabalho entre as equipes. Com uma documentação capaz de gerar a documentação de uma linha de produtos que seja capaz de isolar a base da linha e suas variações, o reuso de componentes é promovido. Facilitando a manutenção tanto dos componentes como de sua documentação.

Nas aulas, a turma era dividida em duas. Uma parte fazia a documentação utilizando a aboradagem PLUSS e outra utilizava a abordagem MSVCM.

De acordo com os exercícios feitos, foi percebido algumas coisas:

1. A abordagem PLUSS, apesar de pregar que cada caso de uso deve ser unificado e que sua notação seja responsável por mostrar as variabilidades de produtos. A leitura do caso de uso se torna confusa. Não se consegue se fazer uma leitura fácil do caso de uso.

2. A abordagem MSVCM modulariza bem as variabilidades dos produtos da linha de produtos. A abordagem não dificulta a leitura do caso de uso.

3. Com a abordagem MSVCM podemos reutilizar variações em diversos casos de uso, enquanto que com o PLUSS não é possível.

4. Quando um caso de uso é/deve ser modificado, tal modificação é bem mais fácil de se fazer no MSVCM do que no PLUSS, pois com o MSVCM, dependendo de como foi feita a escrita dos casos de uso, podemos fazer com que as variações não dependam dos identificadores de passos dos casos de uso, possibilitando assim, a modificação da especificação tanto da base da linha de produtos como das variabilidades sem gerar impactos em outros pontos da documentação.

5. Tanto no MSVCM como no PLUSS, pela leitura de artigos sobre as abordagens e sua aplicação prática, vemos que as duas abordagens funcionam bem com a utilização de ferramentas auxiliares, pois tais ferramentas de acordo com a leitura da documentação, é capaz de

(26)

gerar a documentação de um produto individual.

6. Não foi encontrada no PLUSS, como satisfazer certas restrições que podem existir no feature model da linha. Tomando como exemplo o feature model do eShop, vemos que existe a restrição dizendo que sempre que a feature Shopping Cart estiver presente, a feature Bonus deve estar presente.

(27)

4 Conclusões

O grande desafio das empresas de software é produzir um software de qualidade, bem documentado e dentro do prazo estipulado. Além disso, as empresas devem produzir software para vários clientes onde o software é bem parecido entre os clientes. Poucas empresas aplicam procedimentos de reuso de software, pois encaram cada software que deve ser produzido para cada cliente como um software único. Vimos que os clientes querem cada vez mais produtos customizados. Mas entendendo que geralmente uma fábrica de software geralmente só produz software para um nicho de mercado (Software hospitalar, jogos, PDV, etc), o reuso de software poderia ser muito bem aplicado nessas fábricas.

Por isso, vemos a Engenharia de Requisitos atrai muito interesse e investimento, assim como, o crescimento cada vez maior de interesse sobre os processos de reuso de software e o uso de técnicas de linhas de produtos de software.

Este trabalho introduz duas abordagens de como se documentar casos de uso que podem ser utilizadas na prática por fábricas de software.

As duas abordagens vistas no trabalho foram desenvolvidas para se fazer um melhor gerenciamento das similaridades e variabilidades de produtos de uma linha de produtos de software. Com a utilização dessas abordagens, é possível se fazer um melhor gerenciamento dos requisitos de uma linha de produtos de software. Além disso, com as abordagens vistas o reuso de documentação e de componentes podem ser promovidos nas empresas.

Estudos que poderiam ser feitos em cima do que foi apresentado neste trabalho seriam: 1. Utilização das técnicas em empresas, com análise das dificuldades e facilidades encontradas no seu uso. Com a análise, poderiam ser feitas melhorias nas abordagens.

2. Desenvolvimento e/ou melhoramento de ferramentas que apoiem o uso destas técnicas em empresas. E da mesma forma, poderia ser feita uma análise de uso dessas ferramentas nas empresas para melhorias nas ferramentas.

(28)

5 Referências

[ 1 ] http://www.sei.cmu.edu/productlines/ [ 2 ] http://www.softwareproductlines.com

[ 3 ] Kotonya, G. & Sommerville, I. (1998), Requirements Engineering: Processes and Techniques, [ 4 ] John Wiley & Sons, Inc. New York, NY, USA.

[ 5 ] http://www.sei.cmu.edu/domain-engineering/FODA.html [ 6 ] http://wwwiti.cs.uni-magdeburg.de/iti_db/lehre/epmd/2007/bib/foda.pdf [ 7 ] http://en.wikipedia.org/wiki/AspectJ [ 8 ] http://eclipse.org/aspectj [ 9 ] http://javafree.uol.com.br/artigo/871488/AspectJ-em-20-minutos.html [10] http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html

[11] GOETTEN Junior, WINCK Diogo, 2006. AspectJ - Programação Orientada a Aspectos com Java. São Paulo - SP: Novatec Editora, 2006.

[12] KICZALES, G.; LAMPING, J.; MENDHEKAR, A.; MAEDA, C. et al. Aspect-oriented programming. Para apresentação em: ECOOP ' 97, LNCS 1241. Springer, 1997

[13] http://en.wikipedia.org/wiki/Aspect-oriented_software_development

[14] Kuloor, C. ; Eberlein,A. Requirements Engineering for Software Product Lines Em: ICSSEA2002 [15] WEISS, David. LAI, Robert: Software Product-Line Engineering. A Family-Based Software Development Process. 1. Ed. Boston: Addison-Wesley Professional, 1999. 448p.

[16] PARNAS, David L: On the design and development of program families. IEEE Trans-actions on Software Engineering, 1976, 2:1–9.

[17] CLEMENTS, Paul, NORTHROP, Linda: Software Product Lines: Practices and Patterns. 3. ed. Boston: Addison-Wesley, 2002. 608 p.PARNAS, David L: On the design and development of program families. IEEE Trans-actions on Software Engineering, 1976, 2:1–9.

[18] http://twiki.cin.ufpe.br/twiki/bin/view/TAES/LPS200901

[19] KANG, Kyo. C., COHEN, Sholom. G., HESS, James. A., NOVAK, William E., and PETERSON, A. Spencer: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Repot CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1990

[20] POHL, Klaus, BÖCKLE, Günter, VAN DER LINDEN, Frank: Software Product Line Engineering: Foundations, Principles, and Techniques. 1. ed. New York: Springer, 2005. 468 p.

[21] Bonifácio, R.;Borba P. Modeling Scenario Variability as Crosscutting Mechanisms

[22] M. Eriksson, J. Borstler, and K. Borg. The PLUSS approach - domain modeling with features, use cases and use case realizations. In SPLC’ 2005, pages 33–44, Rennes, France, 2005.

[23] K. Pohl and A. Metzger. The eshop product line. online: http://www.sei.cmu.edu/splc2006/eShop.pdf [24] A. Bertolino and S. Gnesi. Use case-based testing of product lines. In ESEC/FSE’ 2003, pages 355–358, Helsinki, Finland, 2003.

[25] http://en.wikipedia.org/wiki/Aspect-oriented_software_development

[26] M. Antkiewicz and K. Czarnecki. Feature plugin: feature modeling plug-in for eclipse. In OOPSLA workshop on eclipse technology eXchange, pages 67–72, New York, NY, USA, 2004.

[27] Griss M., Favaro J., d’Alessandro M.: Integrating Feature Modeling with the RSEB, Proceedings of the Fifth International Conference on Software Reuse, Vancouver, BC, Canada, (1998) 76-85.

(29)

6 Anexo

6.1 Modelo MSVCM para o Crisis Management System

6.1.1 Scenario SC01 6.1.1.1 Description:

This scenario allows a crisis analyst (the coordinator) to create a crisis record (here, a car crash record) based on the information obtained from witnesses.

6.1.1.2 Flow of events

Code Feature User Action System Response

SC01.1 - Coordinator informs location and type

of crisis as reported by the witness. CMS (Crisis Management System) provides Coordinator with a crisis focused checklist.

SC01.2 - Coordinator provides crisis information to CMS as reported by the witness.

CMS assigns an initial emergency level to the crisis and sets the crisis status to active.

SC01.3 - - CMS recommends to Coordinator the

missions (< MISSIONS >) that are to be executed based on the current information about the crisis and available resources. SC01.4 - Coordinator selects one or more

missions recommended by the sys-tem.

For each selected mission, the CMS assigns internal and external re-sources so as to properly solve the crisis.

After a previous assignment, this scenario allows an (local site) Observer to monitor the situation at the crisis site and to notify the CMS any relevant information related to the crisis.

(30)

Code Feature User Action System Response

SC02.1 - Observer noties the CMS his (her) arrival at the

mission location. CMS sends a crisis-specic checklist to Observer. SC02.2 - Observer feeds CMS with additional crisis

information. CMS reports the information to the system coordinator. SC02.3 - Observer judges that his (her) presence is no

longer needed at the crisis location and request the CMS to finish the corresponding mission.

CMS finishes the observer mission.

[LogFile]

After a previous assignment, this scenario allows the crisis analyst to monitor the process of transporting possible victims of the car crash

SC03.1 - - CMS interacts with the Hospital External System, requesting an appropriate hospital for receiving the victims.

SC03.2 - - CMS recommends to the Coordinator the

list of suitable hospitals. SC03.3 - Based on his (her) experience,

coordinator selects one of the recommended hospitals.

CMS interacts with the Hospital External System, informing that all possible victims of the accident will be sent to the selected hospital.

SC03.4 - - After receiving a notication of the Hospital

External System, CMS noties the Coordinator that the victims had arrived at the hospital.

SC03.5 - The coordinator request the CMS to finish the corresponding mission.

CMS nishes the transporting mission. [LogFile]

After a previous assignment, this scenario allows the crisis analyst to monitor the process of first aid procedures.

(31)

SC04.1 - The First Aid Leader acknowledges the mission assignment to the CMS.

CMS presents detailed information (possible number of victims, location, transporting data) about the car crash.

SC04.2 - - CMS presents a list of rst aid collaborators

that are present. SC04.3 - The First Aid Leader selects one

more collaborators to send to the car crash location.

CMS sends a beep message to the selected collaborators.

SC04.4 - - CMS request transporting to bring the selected collaborators to the car crash location.

SC04.5 - At the car crash location, the First Aid Leader informs each medical procedure that had been taken at the car crash location.

CMS reports the information to the system coordinator.

SC04.6 - The First Aid Leader requests the CMS to finish the corresponding mission.

CMS finishes the rescue mission. [LogFile]

6.1.5 Advice ADV-CAM-SURV 6.1.5.1 Description:

This advice is related to the Camera Surveillance feature.

6.1.5.2 Pointcut:

After SC01.2

ADV- CAM-SURV-1

- Coordinator request visual

information from CMS. CMS requests video feed from Surveillance System.

ADV- CAM-SURV-2

- - Surveillance System starts sending video

feed to CMS.

ADV- CAM-SURV-3

- - CMS starts displaying video feed for

Coordinator.

6.1.6 Advice ADV-LOG 6.1.6.1 Description:

This advice details the Log behavior, which is applied to all supported missions.

6.1.6.2 Pointcut:

(32)

ADV-LOG-1

- - CMS updates the log le, registering all relevant actions performed for concluding this mission.

ADV-LOG-2 - - CMS updates the statistics data about crisis handling.

6.1.7 Advice ADV-REG-LOCAL 6.1.7.1 Description:

This advice is related to the specic behavior required when the software is deployed in local regions.

6.1.7.2 Pointcut:

Before SC03.1

ADV- REG-LOCAL-1

- The Transporting Leader acknowledges the mission assignment to the CMS.

CMS presents the list of available ambulances to the Transporting Leader. Detailed data of the ambulances (equipment, current location, distance to the car crash site, etc.) have to be presented.

ADV- REG-LOCAL-2

- The transporting leader selects one or more of the available ambulances.

CMS places a radio voice message to the corresponding ambulance drivers.

ADV- REG-LOCAL-3

- - CMS waits until each ambulance driver

informs the estimated time of arrival.

6.1.8 Advice ADV-REG-REMOTE 6.1.8.1 Description:

This advice is related to the specic behavior required when the software is deployed in remote regions.

6.1.8.2 Pointcut:

(33)

ADV-REG-REMOTE-1

- The External Transport Manager acknowledges the mission assignment to the CMS.

CMS sends detailed information about the crisis location to the Transport Manager.

ADV-REG-REMOTE-2 - - CMS request transport data (such as estimated time of arrival and helicopter identification) to the Transport Manager.

ADV-REG-REMOTE-3

- The External Transport Manager fills in the requested data.

CMS updates the crisis data and notifies the Coordinator.

6.1.9 Advice ADV-REQ-ADD-MISS 6.1.9.1 Description:

This advice is related to the Request Additional Missions feature

6.1.9.2 Pointcut:

After SC02.2

ADV-REQ-ADD-MISS-1 - - CMS suggests crisis-specific missions to Observer.

ADV-REQ-ADD-MISS-2 - For each mission he (she) wants to create, the observer selects one of the suggested missions.

CMS sends a mission-specific information request to Observe

ADV-REQ-ADD-MISS-3 - Observer sends mission-specic information to CMS. CMS acknowledges the mission creation to Observe

ADV-REQ-ADD-MISS-4 - - After being notified by each specific mission, CMS informs Observer that all additional missions were completed successfully.

6.1.10 Advice ADV-WIT-REG 6.1.10.1 Description:

This advice is related to the Registered Witness feature

6.1.10.2 Pointcut:

(34)

ADV-WIT-REG-1

- - CMS requests the witness data (name,

residence and phone)

ADV-WIT-REG-2

- Coordinator fills in the requested data.

CMS contacts Phone Company to verify witness information.

ADV-WIT-REG-3

- - CMS validates information received

from the Phone Company. This scenario proceeds only if the witness information is correct.

ADV-WIT-REG-4 - - CMS update the crisis information by providing witness data.

6.1.11 Configuration Knowledge

Expression Transformations

Crisis Management System select scenario SC01,

bind parameter MISSIONS to Mission

Observe select scenario SC02

Transport select scenario SC03

Rescue select scenario SC04

Mission evaluate advice ADV-LOG

Camera Surveillance evaluate advice ADV-CAM-SURV

Registered evaluate advice ADV-WIT-REG

Request Additional Missions evaluate advice ADV-REQ-ADD-MISS

Local evaluate advice ADV-REG-LOCAL

Remote evaluate advice ADV-REG-REMOTE

6.2 Modelo PLUSS para o Crisis Management System

This scenario allows a crisis analyst (the coordinator) to create a crisis record (here, a car crash record) based on the information obtained from witnesses.

6.2.1.2 Related feature

(35)

6.2.1.3 Flow of Events

SC01.1 None Coordinator informs location and type of crisis as reported by the witness.

CMS (Crisis Management System) provides Coordinator with a crisis-focused checklist.

SC01.2 None Coordinator provides crisis information to CMS as reported by the witness.

CMS assigns an initial emergency level to the crisis and sets the crisis status to active.

SC01.3

(A) Camera Surveillance Coordinator request visual information from CMS. CMS requests video feed from Surveillance System. SC01.3

(B) Camera Surveillance - Surveillance System starts sending video feed to CMS. SC01.3

(C) Camera Surveillance - CMS starts displaying video feed for Coordinator. SC01.4

(A) Registered - CMS requests the witness data (name, residence and phone) SC01.4

(B) Registered Coordinator fills in the requested data. CMS contacts Phone Company to verify witness information. SC01.4

(C) Registered - CMS validates information received from the Phone Company. This scenario proceeds only if the witness information is correct.

SC01.4

(D) Registered - CMS update the crisis information by providing witness data.

SC01.5 None - CMS recommends to Coordinator the

missions ($Mission) that are to be executed based on the current information about the crisis and available resources. SC01.6 None Coordinator selects one or more

missions recommended by the system.

For each selected mission, the CMS assigns internal and external resources so as to properly solve the

crisis.

After a previous assignment, this scenario allows an (local site) Observer to monitor the situation at the crisis site and to notify the CMS any relevant information related to the crisis.

(36)

SC02.1 None Observer notifies the CMS his (her) arrival at the mission location.

CMS sends a crisis-specific checklist

to Observer. SC02.2 None Observer feeds CMS with additional

crisis information. CMS reports the information to thesystem's coordinator. SC02.3(A) Observe Request Add. Missions - CMS suggests crisis-specific missions to Observer. SC02.3(B) Observe Request Add. Missions

For each mission he (she) wants to create, the observer selects one of the suggested missions.

CMS sends a mission-specific information request to Observer. SC02.3(C) Observe

Request Add. Missions

Observer sends mission-specic information to CMS.

CMS acknowledges the mission creation to Observer.

SC02.3(D) Observe

Request Add. Missions

- After being notified by each

specific mission, CMS informs Observer that all additional missions were completed successfully.

SC02.4 None Observer judges that his (her) presence is no longer needed at the crisis location and request the CMS to finish the corresponding mission.

CMS finishes the observer mission.

SC02.5 None - CMS updates the log file.

registering all relevant actions performed for concluding this mission.

SC02.6 None - CMS updates the statistics data

about crisis handling.

After a previous assignment, this scenario allows the crisis analyst to monitor the process of transporting possible victims of the car crash.

(37)

Code Featur

e User Action System Response

SC03.01

A Remote The External Transport Manager acknowledges the mission assignment to the CMS.

CMS sends detailed information about the crisis location to the Transport Manager. SC03.01

B Local The Transporting Leader acknowledges the mission assignment to the CMS.

CMS presents the list of available ambulances to the Transporting Leader. Detailed data of the ambulances (equipment, current location, distance to the car crash site, etc.) have to be presented.

SC03.02 A

Remote - CMS request transport data (such as estimated time of arrival and helicopter identification) to the Transport Manager. SC03.02

B Local The transporting leader selects one more of the available ambulances. CMS places a radio voice message to the corresponding ambulance drivers. SC03.03

A Remote The External Transport Manager fills in the requested data. CMS updates the crisis data and notifies the Coordinator. SC03.03

B Local - CMS waits until each ambulance driver informs the estimated time of arrival. SC03.04 None - CMS interacts with the Hospital External System, requesting an appropriate hospital for receiving the

victims.

SC03.05 None - CMS recommends to the Coordinator the

list of suitable hospitals.

SC03.06 None - After receiving a notification of theHospital External System, CMS notifies the Coordinator that the victims had arrived at the hospital.

SC03.07 None Based on his (her) experience, coordinator selects one of the recommended hospitals.

CMS interacts with the Hospital External System, informing that all possible victims of the accident will be sent to the selected hospital.

SC03.08 None The coordinator request the CMS to finish the corresponding mission.

CMS finishes the transporting mission.

SC03.09 None - CMS updates the log file. registering all relevant actions performed for concluding this mission.

SC03.10 None - CMS updates the statistics data about crisis handling.

(38)

After a previous assignment, this scenario allows the crisis analyst to monitor the process of first aid procedures.

4.2 Related feature

Rescue

4.3 Flow of events

SC04.1 None The First Aid Leader acknowledges the mission assignment to the CMS.

CMS presents detailed information (possible number of victims, location, transporting data) about the car crash.

SC04.2 None - CMS presents a list of first aid collaborators that are present.

SC04.3 None The First Aid Leader selects one more collaborators to send to the car crash location.

CMS sends a beep message to the selected collaborators.

SC04.4 None - CMS request transporting for bring

the selected collaborators to the car crash location.

SC04.5 None At the car crash location, the First Aid Leader informs each medical procedure that had been taken at the car crash location.

CMS reports the information to the system coordinator.

SC04.6 None The First Aid Leader the CMS to finish the corresponding mission.

CMS finishes the rescue mission.

SC04.7 None - CMS updates the log file. registering all relevant actions performed for concluding this mission.

SC04.8 None - CMS updates the statistics data about crisis handling.