Elementos do modelo de análise

Há várias maneiras de examinar os requisitos para um sistema baseado em computador. Al- guns profissionais de software argumentam que é melhor selecionar um modo de representação (por exemplo, o caso de uso) e aplicá-lo em detrimento de todos os demais. Outros profissionais acreditam que vale a pena usar uma série de modos de representação para representar o modelo de requisitos. Modos de representação diferentes nos forçam a considerar as necessidades de diferentes pontos de vista — uma abordagem com maior probabilidade de revelar omissões, inconsistências e ambiguidades.

Os elementos específicos do modelo de análise são ditados pelo método de modelagem de análise (Capítulos 6 e 7) que será usado. Entretanto, um conjunto de elementos genéricos é co- mum à maioria dos modelos de análise.

Elementos baseados em cenários. O sistema é descrito sob o ponto de vista do usuário

usando uma abordagem baseada em cenários. Por exemplo, casos de uso básicos (Seção 5.4) e seus diagramas de casos de uso correspondentes (Figura 5.2) evolui para casos de uso mais elaborados baseados em modelos. Elementos do modelo de requisitos baseado em cenários são em geral a primeira parte do modelo a ser desenvolvida. Como tal, servem como entrada para a criação de outros elementos de modelagem. A Figura 5.3 mostra um diagrama17 _{de atividades} em UML para o levantamento de requisitos e os representa utilizando casos de uso. São mostra- dos três níveis da elaboração, culminando em uma representação baseada em cenários.

Elementos baseados em classes. Cada cenário de uso implica um conjunto de objetos

manipulados à medida que um ator interage com o sistema. Esses objetos são categorizados em classes — um conjunto de coisas que possuem atributos similares e comportamentos comuns. Por exemplo, um diagrama de classes UML pode ser utilizado para representar uma classe Sen- sor para a função de segurança do CasaSegura (Figura 5.4). Note que o diagrama enumera os

atributos dos sensores (por exemplo, nome, tipo) e as operações (por exemplo, identificar, ha- bilitar) que podem ser aplicadas para modificar tais atributos. Além dos diagramas de classes, outros elementos de modelagem de análise descrevem o modo pelo qual as classes colaboram entre si e os relacionamentos e interações entre as classes. Estes são discutidos de forma mais detalhada no Capítulo 7.

Elementos comportamentais. O comportamento de um sistema baseado em computado-

res pode ter um efeito profundo sobre o projeto escolhido e a abordagem de implementação

16 Ao longo deste livro, uso os termos modelo de análise e modelo de requisito como sinônimos. Ambos se referem às represen- tações dos domínios de informação, funcional e comportamental que descrevem as necessidades dos problemas.

17 Um breve tutorial sobre a UML é apresentado no Apêndice 1 para aqueles que não estão familiarizados com sua notação.

5.5

É sempre uma boa ideia fazer com que os interessados se envolvam. Uma das melhores formas para tal é pedir a cada interessado que escreva casos de uso que descrevam como o software será utilizado.

AVISO

Uma maneira de isolar classes é procurar substantivos descritivos em um texto de caso de uso. Pelo menos alguns dos substantivos serão candidatos a classes. Mais sobre isso no Capítulo 8.

capítulo 5 eNGeNHarIa De reqUIsItos 143

aplicada. Portanto, o modelo de análise deve fornecer elementos de modelagem que descrevem comportamento.

O diagrama de estados é um método para representar o comportamento de um sistema através da representação de seus estados e dos eventos que fazem com que o sistema mude de estado. Estado é qualquer modo de comportamento externamente observável. Além disso, o diagrama de estados indica ações (por exemplo, ativação de processos) tomadas em decorrência de determinado evento.

Para ilustrar o uso de um diagrama de estados, considere o software embutido no painel de controle do CasaSegura responsável pela leitura das entradas feitas pelos usuários. A Figura 5.5 mostra um diagrama de estados UML simplificado.

Além das representações comportamentais do sistema como um todo, o comportamento de classes individuais também pode ser modelado. Uma discussão mais aprofundada de modela- gem comportamental é apresentada no Capítulo 7.

Elementos orientados a fluxos. Informações são transformadas à medida que fluem através

de um sistema baseado em computador. O sistema aceita entrada em uma variedade de formas, aplica funções para transformá-las e gera saída também em uma variedade de formas. A entrada pode ser um sinal de controle transmitido por um transdutor, uma série de números digitados por um operador, um pacote de informações transmitido em um link de rede ou um arquivo de dados volumoso recuperado de armazenamento secundário. A(s) transformação(ões) pode(m) compreen- der desde uma única comparação lógica, um algoritmo numérico complexo até uma abordagem por inferência de regras de um sistema especialista. A saída poderia acender um único LED ou gerar um relatório de 200 páginas. Na realidade, podemos criar um modelo de fluxos para qual- quer sistema baseado em computadores, indiferentemente de seu tamanho e complexidade. Uma discussão mais detalhada da modelagem de fluxos é apresentada no Capítulo 7.

Figura 5.3

diagramas de atividades uml para levantamento de requisitos Priorização formal? Sim Não Realizar reuniões Fazer listas de funções, classes Fazer listas de restrições etc. Usar o QFD para priorizar necessidades Priorizar necessidades informalmente Criar casos de uso Definir os atores Escrever o cenário Completar o modelo completo Extrair os requisitos Desenhar diagrama de caso de uso Um estado é um modo de comportamento externamente observável. Estímulos externos provocam transições entre estados.

144 paRtE 2 MoDeLaGeM

Figura 5.4

diagrama de classes

para Sensor _Nome

Tipo Local Área Características Identificar() Habilitar() Desabilitar() Reconfigurar() Sensor Figura 5.5 Notação de um diagrama de estados uml

System status = "Ready" Display msg = "enter cmd" Display status = steady

Nome do estado Variáveis de estado

Atividades de estado Entry/subsystems ready

Do: poll user input panel Do: read user input Do: interpret user input

Reading commands

Modelagem comportamental inicial Cena: Sala de reuniões, na qual prossegue a primeira reunião para levantamento de re- quisitos.

Atores: Jamie Lazar, membro da equipe de software; Vinod raman, membro da equipe de software; Ed robbins, membro da equipe de software; Doug Miller, gerente da engenharia de soft- ware; três membros do Depto. de Marketing; um representante da Engenharia de Produto e um facilitador.

Conversa:

Facilitador: Estamos prestes a finalizar nossa discussão sobre a funcionalidade segurança domiciliar do CasaSegura. Antes de fazê-lo, gostaria de discutir o comportamento da função. Representante do Depto. de Marketing: Não entendi o que você quis dizer com comportamento.

Ed (sorrindo): Trata-se de dar ao produto um “tempo de espe- ra” caso ele se comporte mal.

Facilitador: Não exatamente. Permita-me explicar.

(O facilitador explica os fundamentos da modelagem comporta- mental à equipe de levantamento de requisitos.)

Representante do Depto. de Marketing: Isso me parece um tanto técnico. Não estou certo se serei de alguma ajuda aqui. Facilitador: Certamente que você pode ajudar. Que comporta- mento você observa do ponto de vista de usuário?

Representante do Depto. de Marketing: Bem, o sistema estará monitorando os sensores. Lendo comandos do proprietá- rio. Mostrando seu estado.

Facilitador: Viu, você pode fazê-lo.

Jamie: Ele também irá indagar o PC para determinar se há qualquer entrada dele proveniente, por exemplo, acesso basea- do em Internet ou informações de configuração.

Vinod: Sim, de fato, configurar o sistema é um estado em si. Doug: Pessoal, vocês estão enrolando.

Pensemos um pouco mais... Existe uma maneira de colocar esta coisa em um diagrama?

Facilitador: Existe, mas adiemos para logo depois da reunião.

capítulo 5 eNGeNHarIa De reqUIsItos 145 5.5.2 padrões de análise

Qualquer um que tenha feito engenharia de requisitos em mais do que uns poucos projetos de software começa a perceber a recorrência de certos problemas ao longo de todos os projetos em um campo de aplicação específico.18 _{Tais padrões de análise [Fow97] sugerem soluções (por} exemplo, uma classe, função ou comportamento) no campo de aplicação que pode ser reutiliza- do na modelagem de muitas aplicações.

Geyer-Schulz e Hahsler [Gey01] sugerem dois benefícios que podem estar associados ao uso de padrões de análise:

Primeiro, os padrões de análise aceleram o desenvolvimento de modelos de análise abstratos que captu- ram os principais requisitos do problema concreto, fornecendo modelos de análise reutilizáveis com exemplos, bem como uma descrição de vantagens e limitações. Em segundo lugar, os padrões de aná- lise facilitam a transformação do modelo de análise em um modelo de projeto, sugerindo padrões de projeto e soluções confiáveis para problemas comuns.

Os padrões de análise são integrados ao modelo de análise por meio de referência ao nome do padrão. Eles também são armazenados em um repositório de modo que os engenheiros de requisitos podem usar recursos de busca para encontrá-los e aplicá-los. Informações sobre um padrão de análise (e outros tipos de padrões) são apresentadas em um modelo padrão [Gey01]19 discutido de maneira mais detalhada no Capítulo 12. Exemplos de padrões de análise e uma discussão mais ampla deste tópico são apresentados no Capítulo 7.

n

r

Em um contexto de engenharia de requisitos ideal, as tarefas de início, levantamento e ela- boração determinam os requisitos do cliente com detalhes suficientes para prosseguir para ati- vidades de engenharia de software subsequentes. Infelizmente, isso raramente acontece. Na realidade, talvez você tenha de iniciar uma negociação com um ou mais interessados. Na maio- ria dos casos, solicita-se aos interessados contrabalançar funcionalidade, desempenho e outras características do produto ou sistema, em função do custo e tempo para chegar ao mercado. O intuito da negociação é desenvolver um plano de projeto que atenda às necessidades dos inte- ressados e, ao mesmo tempo, reflita as restrições do mundo real (por exemplo, tempo, pessoal, orçamento) impostas à equipe de software.

As melhores negociações buscam ao máximo um resultado “ganha-ganha”.20 _{Ou seja, os} interessados ganham obtendo um sistema ou produto que satisfaz a maioria de suas necessi- dades e você (como membro da equipe de software) ganha trabalhando com prazos de entrega e orçamentos reais e atingíveis.

Boehm [Boe98] define um conjunto de atividades de negociação no início de cada iteração do processo de software. Mais do que uma simples atividade de comunicação com o cliente, são definidas as seguintes atividades: