Etapa de Planejamento

As atividades realizadas durante a etapa de planejamento do desenvolvimento são mostradas na Figura 32. A primeira atividade é a especificação dos requisitos que o sistema deve cumprir. A partir da especificação de requisitos e do conhecimento do domínio do pro-

blema, os atores e os casos de uso são identificados. A seguir, os casos de usos são descritos de forma simplificada, usualmente em duas ou três sentenças. Através dos diagramas de casos de uso, ilustram-se todos os casos de uso identificados e seus relacionamentos. Pode-se

criar então uma versão preliminar do modelo de conceitos, com o objetivo de auxiliar no entendimento do vocabulário do domínio, especialmente no que diz respeito aos casos de uso e à especificação de requisitos. Neste ponto, um esboço da arquitetura imaginada para o sistema também pode ajudar, embora sua criação possa ser postergada. Os termos (nomes dos conceitos) e quaisquer informações associadas, tais como restrições e regras devem ser regis- tradas num glossário. Essa atividade, embora apareça como a última desta etapa, normalmente é realizada em paralelo com as demais e estende-se por todo o desenvolvimento. Finalmente, os casos de uso identificados devem ser priorizados e distribuídos pelos diversos ciclos de desenvolvimento, com os de maior prioridade sendo tratados logo nas iterações iniciais. Dessa forma, os ciclos de desenvolvimento são organizados em torno dos casos de uso. Em um ciclo de desenvolvimento podem ser alocados um ou mais casos de uso, ou mesmo versões simpli- ficadas de um caso complexo. A seqüência de desenvolvimento estabelecida deve ser docu- mentada em um cronograma de desenvolvimento.

Planejamento _{Desenvolvimento 1}Ciclo de _{Desenvolvimento 2}Ciclo de ...

6. Registrar termos

no Glossário b

1. Definir requisitos 3. Criar Diagramas

de Casos de Uso 5. Esboçar Arquitetu- ra do Sistema a 7. Definir cronogra- ma 4. Esboçar Diagra- mas de Conceitos a

a. pode ser adiada b. contínua 2. Definir Casos de

Uso simplificados

5.4.2 Ciclos de Desenvolvimento

As atividades realizadas em um ciclo de desenvolvimento são agrupadas em fases, conhecidas como fases de análise, projeto, implementação, teste e sincronização de artefa-

tos (Figura 33). Os modelos e artefatos descritos na Seção 5.3 são construídos e refinados, de

forma incremental, principalmente nas fases de análise e projeto de cada ciclo. Ao final de cada ciclo, tem-se implementado um sistema, que satisfaz os requisitos descritos pelos casos de uso atribuídos ao ciclo em questão e a todos os seus antecessores.

Ciclo de Desenvolvimento 1

Ciclo de

Desenvolvimento 2 ...

Análise Projeto Implementação Teste Sincronização

Figura 33: Fases de um ciclo de desenvolvimento

5.4.3 Fase de Análise

Durante a fase de análise, a ênfase está na investigação dos conceitos do domínio do problema relacionados aos casos de uso tratados no ciclo em questão. Deste modo, as ativida- des dessa fase concentram-se em refinar os Modelos de Casos de Uso, de Conceitos e de Comportamento do Sistema. Os casos de uso escolhidos para serem tratados durante o ciclo corrente de desenvolvimento são descritos em maiores detalhes, sem que, no entanto, sejam introduzidas informações relativas à implementação e tecnologia a ser utilizada, especialmen- te no que se refere à interface de usuário. Essa forma de descrição de um caso de uso, deta- lhada, mas sem decisões de projeto, é denominada descrição detalhada essencial. Os dia- gramas de casos de uso e os diagramas de conceitos devem ser refinados para refletirem os detalhes introduzidos nessa descrição, da mesma forma que o glossário. Se for o caso, os conceitos devem ser agrupados em pacotes e os relacionamentos e dependências entre os pa-

cotes documentados através dos diagramas de pacotes de conceitos. Tomando-se como pon- to de partida principalmente o Modelo de Casos de Uso, definem-se, então, os diagramas de

seqüência de sistema e os contratos para suas operações; se necessário, define-se também

o diagrama de estados de sistema. Esses artefatos compõem o modelo de comportamento

sistêmico, para o ciclo de desenvolvimento em questão.

A Figura 34 mostra as atividades executadas durante a fase de análise de um ciclo de desenvolvimento e a seqüência de realização proposta. Variações dessa seqüência básica tam- bém são possíveis.

Análise Projeto Implementação Teste Sincronização

a. se necessário b. contínua 1. Definir Casos de Uso Essenciais 8. Refinar Glossário b 2. Refinar Diagramas

de Casos de Uso 3. Refinar Diagramasde Conceitos

4. Criar Diagramas de Pacotes de Conceitos a 5. Criar Diagramas de Seqüência de Sistema 6. Definir Contratos para Operações de Sistema 7. Criar Diagramas de Estados de Sistema b

Figura 34: Atividades realizadas na fase de análise

5.4.4 Fase de Projeto

Quando os documentos de análise de um ciclo de desenvolvimento estão completos, é possível iniciar-se a fase de projeto. Através das atividades dessa fase, é construída uma solução lógica para o sistema, baseada no paradigma de orientação a objetos. Essa solução é documentada através dos modelos de comportamento de objetos, de classes e de arquite-

tura do sistema. A espinha dorsal dessa solução é a criação dos diagramas de interação, os

quais ilustram como os objetos irão se comunicar de forma a satisfazerem o subconjunto de requisitos tratados no ciclo corrente. Seguindo a geração desses diagramas, podem-se dese-

nhar os diagramas de classes, os contratos para suas operações e, se necessário, seus dia-

gramas de estados. Esses artefatos sintetizam as definições das classes e interfaces a serem

implementadas. O glossário também deve ser atualizado com a inclusão dos novos termos identificados. Nessa fase, também podem ser definidos os mecanismos de armazenamento

persistente de dados, suas estruturas e suas interfaces com os subsistemas do domínio do

problema.

Para dar suporte à criação dos diagramas de interação, pode ser útil, embora não seja estritamente necessário, descrever os casos de uso selecionados para o ciclo de desenvolvi- mento corrente num formato real ou concreto. Essa descrição detalhada real dos casos de

uso, criada a partir da descrição detalhada essencial, é realizada em termos da tecnologia con-

creta de entrada e saída a ser utilizada para o sistema. Por exemplo, se uma interface gráfica de usuário for utilizada, a descrição detalhada real dos casos de uso incluirá os diagramas das janelas de entrada e saída envolvidas e a discussão das interações dos atores com elementos visuais, tais como botões e caixas de entrada de texto.

A Figura 35 mostra as atividades executadas durante a fase de projeto de um ciclo de desenvolvimento e a seqüência de realização proposta. Variações dessa seqüência básica tam- bém são possíveis.

Análise Projeto Implementação Teste Sincronização

a. em paralelo b. se necessário c. contínua 1. Esboçar Interface de Usuáriob 4. Criar Diagramas de Classes a

2. Definir Casos de Uso Reais 3. Criar Diagramas de Interação a 10. Refinar Glossário c 8. Refinar Diagramas de Pacotes da Arquitetura

6. Definir Contratos para Operações de Classes e Interfaces

7. Criar Diagramas de

Estados de Classes b 9. Definir Esquema do_{Banco de Dados} b

5. Criar Diagramas de

Pacotes de Classes b

5.4.5 Fase de Implementação

Quando os modelos de classes e de comportamento de objetos, para o ciclo de de- senvolvimento em progresso, estiverem completos, já existirão informações suficientes para a geração do código dos objetos da camada do domínio do problema. Desta forma, pode-se dar início à fase de implementação do sistema de software. Essa implementação, em uma lingua- gem de programação orientada a objetos, requer a criação dos códigos-fonte para as assinatu-

ras das classes e interfaces, dos métodos, das janelas de entrada e saída de dados e das interfaces de acesso aos mecanismos de armazenamento persistente. Ao longo da imple-

mentação, as dependências entre os diversos elementos de software gerados e a sua distribui- ção pelos nós de processamento que hospedarão o sistema são documentadas através dos dia-

gramas de componentes e de distribuição. A Figura 36 mostra a seqüência básica de execu-

ção dessas atividades.

Análise Projeto Implementação Teste Sincronização

1. Implementar as- sinaturas de Clas- ses e Interfaces 4. Implementar Esquema de Banco de Dados 2. Implementar Métodos 3. Implementar Janelas de Entrada e Saída a 5. Criar Diagramas de Componetes 6. Criar Diagrama de Implantação a a. se necessário

Figura 36: Atividades realizadas durante a fase de implementação

5.4.6 Fase de Testes

Embora a Figura 33 mostre a fase de teste como sendo a penúltima de um ciclo de- senvolvimento, de fato, suas atividades são executadas ao longo da fase de implementação. A Figura 37 mostra as principais atividades da fase de testes. O teste de unidade é normalmente executado à medida que as classes, interfaces e métodos são implementados. Os testes de

sistema e de integração são dirigidos pelos casos de teste que por sua vez são criados com

base nos casos de uso e nos contratos para as operações de sistema. Por outro lado, nem todos os testes apresentados nessa figura são realizados em todos os ciclos de desenvolvimento. Esse é o caso dos testes de integração, de aceitação e de documentação.

Análise Projeto Implementação Teste Sincronização

a. dirigidos pelos casos de uso e pelos contratos das operações 2. Testes de Unidade

6. Testes de Aceitação

3. Testes de Integração a

4. Testes de Sistema a 5. Testes de Desempe-

nho 1. Definir Casos de Teste

Figura 37: Atividades realizadas durante a fase de teste

5.4.7 Fase de Sincronização

Usualmente, durante as fases de implementação e testes, surgirão diversos problemas e detalhes não identificados durante as fases de análise e projeto. Como conseqüência, deve- se esperar que ocorram desvios entre o projeto original e o sistema realmente implementado. Portanto, com o objetivo de manter-se uma documentação consistente e preparar a próxima iteração, a última fase de um ciclo de desenvolvimento deve ser destinada à sincronização

dos artefatos gerados durante a análise e projeto com o código efetivamente construído.

Finalmente, a Figura 38 (LARMAN, 1998) mostra as dependências de construção entre os principais artefatos descritos.

Cronograma de Desenvolvimento Especificação de Requisitos Descrição Resumida dos Casos de Uso Esboços dos Diagramas de Conceitos Glossário Esboço da Arquitetura do Sistema Descrição Deta- lhada Essencial dos Casos de Uso

Diagramas de Casos de Uso Diagramas de Casos de Uso Diagramas de Conceitos Diagramas de Seqüência de Sistema Contratos para as Operações de Sistema Diagramas de Pacotes de Conceitos Descrição Detalhada Real dos

Casos de Uso Diagramas de Interação Diagramas de Classes Esboço da Interface de Usuário Diagramas de Pacotes da Arquitetura Diagramas de Estados de Classes Contratos para as Operaçoes das Classes Janelas de Entrada e Saída Métodos Assinaturas das Classes e Interfaces Diagramas de Componentes Diagrama de Implantação Casos de Teste Planejamento do Desenvolvimento

Análise Projeto Implementação Teste

Diagramas de Estados de Casos de Uso e de Sistema Diagramas de Pa- cotes de Classes

pode ser adiado se necessário Legenda:

Figura 38: Dependência entre os artefatos

5.5 Considerações Finais

A notação apresentada neste capítulo será utilizada na definição da arquitetura geral proposta para o Framework de Inteligência realizada no Capítulo 6 e, em maior grau, na do- cumentação do desenvolvimento de seu núcleo, apresentado no Capítulo 7, e do mecanismo concreto de inferência, descrito no Capítulo 8.

Embora existam outros processos de desenvolvimento de software propostos na lite- ratura, como, por exemplo, o Fusion (COLEMAN, 1994) e o Object Models (COAD, 1995), até o momento, o Rational Unified Process (RUP) da Rational (2000) é o mais promissor porque além de dar grande ênfase aos aspectos de gerenciamento do trabalho em equipe é o

herdeiro direto de três processos anteriores de enorme aceitação, Object Modeling

Techniques (OMT) de James Rumbaugh (RUMBAUGH et al., 1991), Object-Oriented Software Engineering (OOSE) de Ivar Jacobson (JACOBSON et al., 1992) e o método de

Booch (BOOCH, 1994). No entanto, neste trabalho optou-se pela utilização do Recommend

Models and Patterns (RMP) apresentado em Larman (1998) uma vez que ele pode ser consi-

derado uma simplificação do RUP para o desenvolvimento de sistemas mais simples, que não exijam o desenvolvimento por equipes.

107