Você está na página 1de 50

Análise e Projeto Orientados a Objetos

ANÁLISE E PROJETO ORIENTADOS A OBJETOS:

MÉTODO FUSION EXPANDIDO E ADAPTADO À UML

Por Maurício F. Galimberti

MFGalimb@ucs.tche.br

Departamento de Informática

Centro de Ciências Exatas e Tecnologia

Universidade de Caxias do Sul

Equipe do Projeto FILM

Coordenador:

Prof. MSc. Maurício F. Galimberti Colaboradores:

Prof. MSc. José Eduardo C. Bussmann Prof. MSc. Giovanni E. Rocco Prof. MSc. Daniel L. Notari Bolsistas:

Fabrício Lazzari

Resumo

O presente trabalho propõe abordar a análise e projeto orientados a objetos a partir de um método sistemático e didático, utilizando para construção de seus modelos um conjunto padronizado de notações. Será adotado o método Fusion de análise e projeto de sistemas orientados a objetos, o qual se expande com uma fase inicial de coleta e especificação de requisitos, conduzindo-a como um processo linear. As demais fases de análise, projeto e implementação serão tratadas em um processo cíclico de evolução do desenvolvimento de sistemas onde serão utilizadas as notações padrão UML (Unified Modeling Language) para modelagem dos artefatos do sofware.

Palavras-chave: análise e projeto orientados a objetos; método orientado a objetos; método Fusion; Unified Modeling Language (UML).

1

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

1.

Introdução à Análise e Projeto de Sistemas Orientados a Objetos

4

1.1

- Análise e Projeto Orientados a Objetos

6

1.1.1 - Métodos de Análise e Projeto Orientados a Objetos

7

1.1.2 - Método Fusion de Análise e Projeto Orientado a Objetos

11

1.1.3 - Padrões de Modelagem de Objetos usando UML - Unified Modeling Language

12

1.2

- Método Fusion Expandido e Adaptado à UML

13

1.2.1

15

PARTE I

- Condução das Fases do Método de Especificação e Construção do Software - PROCESSO LINEAR

19

2.Fase de Estruturação e Especificação de Requisitos

20

 

2.1 - Documento Contextual do Sistema

21

2.2 - Modelo de Objetivos

 

22

2.2.1

Estrutura dos Objetivos

23

2.3 - Visão de Use Cases

 

24

2.4 - Cenários e Ciclo de Vida do Sistema

25

2.5 - Planejamento dos Ciclos de Construção do Sistema

26

2.6 - Manutenção de um Glossário de Termos

27

PARTE II - PROCESSO CÍCLICO

28

3. Fase de Análise

 

29

 

3.1 - Condução da Fase de Análise

29

3.2 - Refinamento dos Requisitos por Ciclo

31

3.2.1 Cenários do Sistema por Objetivo

31

3.2.2 Modelo de Requisitos por Objetivo

32

3.3 - Modelo de Objetos (Modelo Conceitual)

33

3.4 - Modelo de Interfaces

 

34

3.4.1 Cenários e Modelo Ciclo de Vida

35

3.4.2 Modelo

de

Operações

36

3.5 - Modelo de Objetos do Sistema (Modelo Conceitual)

37

3.6 - Verificação dos Modelos da Fase de Análise

38

4. Fase de Projeto

 

40

 

4.1 - Condução da Fase de Projeto

40

4.2 - Grafos de Interação de Objetos

41

 

2

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

4.3

- Refinamento do Modelo de Objetos do Sistema

42

4.3.1 Agregações

42

4.3.2 Herança - Estrutura Hierárquica de Classes

43

4.4 - "Visibilidade"

44

4.5 - Verificação dos Modelos da Fase de Projeto

44

5. Fase de Implementação

46

5.1 - Condução da Fase de Implementação

46

5.2 - Geração dos Protótipos e Estruturas de Classes de Objetos

47

5.3 - Verificação das Estruturas de Classes de Objetos

47

 

6. Conclusões

48

Bibliografia

49

Apêndice A - Estudo de Caso MiniBib (Biblioteca Departamental)

50

3

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

1. Introdução à Análise e Projeto de Sistemas Orientados a Objetos

A orientação a objetos surgiu como uma abordagem de programação que procura explorar o nosso lado intuitivo. Os "átomos" da computação orientada a objetos (os próprios objetos), são análogos aos objetos existentes no mundo físico, o que produz um modelo de programação muito diferente da tradicional visão "funcional" e "procedimental" [Coleman, 1996].

Modelo computacional orientado a funções:

Os "átomos" da computação são as funções;

Funções atuam sobre um único estado compartilhado;

Qualquer função pode atuar sobre qualquer parte do estado.

Qualquer função pode atuar sobre qualquer parte do estado. Figura 1.1 - Modelo Computacional Orientado a

Figura 1.1 - Modelo Computacional Orientado a Funções [Coleman, 1996]

Neste modelo a estrutura não se altera com o passar do tempo, apesar de ocorrerem alterações nos valores armazenados na mesma: modelo computacional estático.

Modelo computacional orientado a objetos:

A única maneira de se obter ou alterar o estado de um objeto é pelo envio de mensagens;

Cada objeto “é responsável” pela resposta a uma determinada mensagem;

Os objetos, quando compartilham uma única interface, são agrupados em classes;

uma única interface, são agrupados em classes; Figura 1.2 - Modelo Computacional Orientado a Objetos,

Figura 1.2 - Modelo Computacional Orientado a Objetos, [Coleman, 1996]

Durante a execução do sistema os objetos podem ser construídos, executar ações, serem destruídos

4

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

ou se tornarem inacessíveis: modelo computacional dinâmico.

Assim sendo, os “átomos” do processo de computação são os objetos:

Objetos trocam mensagens entre si;

As mensagens resultam na ativação de métodos;

O emissor da mensagem não precisa saber como o objeto receptor organiza o seu estado interno;

Ao emissor da mensagem basta saber que o objeto receptor/servidor responde a certas mensagens de maneira bem definida.

Entretanto, o paradigma orientado a objetos deve, além do processo de programação, abranger também as demais fases do processo de desenvolvimento de sistemas computacionais em específico.

Historicamente foram desenvolvidas metodologias para tratar o ciclo de desenvolvimento de software sob o ponto de vista de objetos. Contudo, como um processo natural de evolução de "novas" tecnologias, este tema ainda proporciona novas propostas de abordagem para o assunto, gerando, ao mesmo tempo, divergências e similaridades entre os diversos métodos.

Tendo como base este contexto, foram desenvolvidas as primeiras metodologias e também abordagens parciais para tratar o assunto, como linguagens de especificação e métodos de projeto, por exemplo.

Considerando-se como abordagens (métodos, técnicas, linguagens de especificação) conhecidas mundialmente, e altamente influentes para este trabalho, cita-se: "Booch", de Grady Booch; "OMT (Object Modeling Technique)", de James Rumbaugh; "OOSE (Object-Oriented Software Engineering)", de Ivar Jacobson; "CRC (Class-Responsability-Collaboration)", técnica exploratória que orienta o desenvolvimento através do registro das classes em cartões de referência. Estas abordagens serão melhor comentadas na seção 1.1.1, sem contudo aprofundarmo-nos nas mesmas por não ser este nosso objetivo com o presente trabalho.

Devido a esta miscelânea de métodos, surgiram duas boas abordagens com propostas de fusão de conceitos, sendo elas: Fusion [Coleman, 1996] e UML (Unified Modeling Language) [OMG, 2001]. Estas se caracterizam como a base de nossas atividades e serão devidamente apresentadas com o transcorrer deste programa.

Atualmente sendo adotada como base para a prática da orientação a objetos nas disciplinas de Análise e Projeto de Sistemas I e II, seguindo os currículos dos cursos de Bacharelado em Ciência da Computação e Tecnologia em Processamento de Dados da Universidade de Caxias do Sul, o método Fusion se apresenta bastante sistemático e didático para o processo de desenvolvimento de software orientado a objetos, estabelecendo uma rota direta entre a definição dos requisitos e a implementação do sistema. No entanto, os modelos por ele criados tornam-se às vezes bastante confusos devido a similaridade de notação entre os mesmos. Além disso, o método não propõe abordagem para a definição de requisitos, que é uma das fases iniciais do processo de produção de software, que precede as atividades de “desenvolvimento”.

Já em relação à UML, – padrão estabelecido pela OMG (Object Management Group) – esta “é uma linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de software. A UML oferece uma forma padrão para se escrever/modelar projetos de sistemas, incluindo conceitos, tais como processos de negócios e funções de sistema, bem como coisas concretas como sentenças de linguagem de programação, projetos de bancos de dados e componentes reutilizáveis de

5

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

software” [OMG, 2001].

Mais especificamente, a UML se concretiza como um conjunto de notações bem definidas e

específicas para a construção dos diversos modelos necessários desde a definição de um sistema orientado

a objetos até a sua implementação.

A UML é a unificação e evolução das propostas de vários métodos de orientação a objetos, dentre eles os principais métodos são Booch, OMT e OOSE, concebidos, respectivamente, por três autores de renome internacional, sendo Grady Booch, James Rumbaugh e Ivar Jacobson (referenciados mundialmente como "The Three Amigos"), que extraíram de suas metodologias anteriores aspectos positivos de cada uma delas. Além disso, suas experiências mostraram que é ineficiente uma metodologia estanque e que não se adeque a outros processos de desenvolvimento de software, o que os motivou à criação da UML como uma linguagem flexível, que possa se adaptar a outras metodologias já existentes ou que por ventura venham a ser criadas.

A partir deste quadro mundial, foi criada uma comissão internacional que iniciou um processo de

padronização da área de orientação a objetos, sendo atualmente a UML versão 1.3 (com proposta da versão 1.4 em avaliação) reconhecida com exclusividade por esta comissão, denominada Object Management Group (OMG) [OMG, 2001], como padrão de notação de construção de modelos orientados

a objetos.

Este contexto, aliado ao fato de existir proposta semelhante, quando da adequação da UML ao processo Objectory de Engenharia de Software, através do trabalho "UML Extension for Objectory Process for Software Engineering" [//??], vem a motivar o presente projeto, com o qual buscar-se-á utilizar a UML para acrescentar clareza, eficiência e padronização à construção dos modelos propostos pelo método Fusion. Além disso, permite a expansão do método Fusion em relação à fase inicial de definição de requisitos, buscando-se enquadrar a notação da UML para a geração de modelos para esta fase.

No entanto, a principal motivação para a criação deste trabalho vem da atual estrutura curricular dos cursos do Dpto. de Informática desta Universidade e, consequentemente, da inserção de seus egressos no mercado de desenvolvimento de software. Sendo estes cursos formadores de profissionais com perfis de analistas e projetistas de software, considera-se que os mesmos devem cada vez mais se enquadrar ao contexto mundial da tecnologia de orientação a objetos. Deve-se, portanto, considerar o processo gradativo de mudança do paradigma estruturado pelo orientado a objetos, pelo qual passam as empresas do setor de informática da região, o que as levará, certamente, à adoção de padrões estabelecidos para o segmento de produção de software.

1.1 - Análise e Projeto Orientados a Objetos

Esta seção apresenta a importância de se ter, além do processo de programação, um método sistemático que deve abranger também as demais fases do processo de desenvolvimento de sistemas computacionais em específico.

Como principais características em se ter um método, cita-se:

Oferecer sistemática para as fases de definição de requisitos, análise, projeto e implementação;

Evitar codificação precoce: programas de difícil manutenção e que não satisfazem os requisitos do usuário;

Métodos sistemáticos consomem mais tempo nas fases iniciais do desenvolvimento de software.

6

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

As vantagens em se ter um método sistemático para análise e projeto de sistemas (sistemas orientados a objetos, no nosso caso) nem sempre são apreciadas. Entre elas temos [Coleman, 1996]:

Verificação de requisitos;

Conceitos mais claros;

Maior adequação do projeto ao problema;

Melhor decomposição do projeto para trabalho em equipe;

Melhor comunicação da equipe de desenvolvimento;

Menor esforço de manutenção;

No restante desta seção serão apresentadas as principais abordagens existentes para análise e projeto de sistemas orientados a objetos. Na subseção 1.1.1 serão brevemente abordadas, conforme [Coleman, 1996], algumas das propostas pioneiras da orientação a objetos, as quais ainda contribuem em muito para o desenvolvimento de software orientado a objetos, mas que não são o foco deste trabalho. Contudo, serão enfatizados, nas seções subsequentes, o método Fusion (seção 1.1.2) e o padrão UML (seção 1.1.3) por se caracterizarem como a base de nosso projeto.

1.1.1 - Métodos de Análise e Projeto Orientados a Objetos

Sem ter o objetivo de aprofundar os conhecimentos em quaisquer trabalhos abaixo, esta seção descreve características básicas, a grande maioria sob o ponto de vista de [Coleman, 1996], sobre propostas pioneiras na orientação a objetos. Desejando-se conhecer melhor estes trabalhos, são citadas suas principais referências bibliográficas.

OMT (OBJECT MODELING TECHNIQUE) [Rumbaugh, 1991] ANÁLISE: modelagem do mundo real. Modelo de Objetos:

captura estrutura estática de um sistema:

classes e relacionamentos atributos e operações que caracterizam cada classe notação: diagrama E-R estendido Modelo Dinâmico:

captura o comportamento dinâmico de cada classe:

máquina de estados: como objetos da classe respondem aos eventos evento representa um estímulo externo estado é uma abstração dos valores dos atributos e relacionamentos Modelo Funcional:

mostra o que o sistema deve fazer: uso de DFDs PROJETO: decisões a respeito dos subsistemas e aspectos gerais da arquitetura. Projeto do Sistema:

divide em subsistemas aloca processos e defini a arquitetura geral Projeto de Objetos:

algoritmos dos métodos determina métodos das classes particiona projeto em módulos para a programação

7

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

IMPLEMENTAÇÃO: codificação do projeto dos objetos.

PRÓS Análise possui um processo bem definido Modelos da análise com notações concisas e inteligíveis CONTRAS Relacionamento entre modelos da análise não é claro Modelos da análise dificultam percepção do cenário global Projeto não possui abordagem passo a passo Não fica claro onde/quando deve-se começar projeto

BOOCH [Booch, 1994] Processo com natureza descritiva (o que podemos fazer) e não prescritiva (o que devemos fazer) Notações (sem ordenamento do processo):

Diagramas de Classes:

classes e relacionamentos (estático): variação do E-R esboços são produzidos no início do desenvolvimento e completados durante a identificação dos relacionamentos Diagramas de Objetos:

objetos e “relacionamentos” (dinâmico): troca de mensagens esboços são produzidos no início do desenvolvimento e completados durante a identificação dos relacionamentos Diagramas de Tempo:

apresentam informações de ordenação (sem mensagens) eixo-x (tempo ) e eixo-y (fluxo de controle entre os objetos) também identificam tempo de criação e destruição de objetos Diagramas de Estados:

transição de estados dos objetos Diagramas de Módulos e Diagramas de Processos:

grafos identificam visão física do sistema diagrama de Módulos:

alocação de classes e objetos em módulos e dependência dos módulos Diagrama de Processos:

processadores, dispositivos e conexão de comunicação entre eles

PRÓS Conjunto de notações abrangem todos os aspectos de um sistema orientado a objetos CONTRAS Notação complexa Informações se duplicam entre os vários modelos Ausência de processo bem-definido para o desenvolvimento de sistema

OBJECTORY [Jacobson, 1992] Baseia-se em use cases:

diálogo/transações entre o sistema e um usuário

8

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Adota o termo agentes: usuários do sistema Use Cases capturam funcionalidades do sistema Demais modelos são construídos sobre use cases Use cases -- elos de ligação entre as fases REQUISITOS: declaração em linguagem natural. Modelo Caso-de-Uso:

identifica agentes e seus casos-de-uso:

Modelo de Objetos do Domínio:

suporta os casos-de-uso: conceitos com o qual o sistema opera notação similar a de um modelo E-R Descrições da Interface com o Usuário:

esboços das janelas que os usuários verão na tela envolve o usuário no processo de desenvolvimento ANÁLISE: refina os modelos dos requisitos. Modelo é uma forma de modelo E-R Objetos e classes requeridos em cada use case SUBSISTEMAS:

grupos de objetos com comportamento similar critérios para agrupamento:

forte acoplamento entre objetos flexibilidade para suportar mudanças nos requisitos CONSTRUÇÃO: modelos da análise são refinados. Modelo de Blocos:

Identifica blocos (abstração de blocos de código) do sistema Cada bloco é composto por um ou mais objetos da análise Diagrama de Interações:

Participação dos blocos (através de mensagens) com use cases Modelo de Interface de Blocos:

Interface operacional: formada pela extração das operações realizadas sobre um bloco Especificação de Blocos:

Modelo opcional sobre o comportamento interno do bloco: máquinas de estados

PRÓS Contribui com o conceito de use case: base do processo CONTRAS Modelos e notações: inadequados e insuficientes Difícil compreensão de alguns modelos Dificuldade para verificar inteireza e/ou consistência do sistema desenvolvido

CRC (CLASSE-RESPONSABILIDADE-COLABORADOR) [Beck, 1989] IDENTIFICAR CLASSES E RESPONSABILIDADES:

Objetos são agrupados, gerando classes em cartões Ações dos objetos transformadas em responsabilidades das classes: tarefas a serem executadas pela classe ATRIBUIR RESPONSABILIDADES:

Responsabilidades são alocadas às classes Distribuição das tarefas do sistema

9

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

IDENTIFICAR COLABORAÇÕES:

Identificação das interações entre as classes: exame de cada par classe/responsabilidade buscando suas dependências com outras classes

PRÓS

Como técnica exploratória (não é um método) é bastante avançada

Útil no projeto de estruturas de herança Muito poderosa para o projeto das interações entre os objetos

CONTRAS

Cartões de referência: único registro para as decisões tomadas

Inadequadas para fins de manutenção Não trata da criação/destruição de objetos

MÉTODOS FORMAIS

Abordagem de engenharia de software baseada na aplicação de matemática discreta à programação

de computadores

Propriedades do sistema são capturadas em um alto nível de abstração

Trabalhos recentes tentam estender estes métodos aos sistemas orientados a objetos

Alto custo de aceitação: exigido muito conhecimento matemático

Método promissor: a longo prazo

FUSION [Coleman, 1996]

O método Fusion caracteriza o centro dos estudos para nossa abordagem de orientação a objetos.

Portanto, neste contexto apenas é apresentada a figura 1.3 que representa o sentido de seu “batismo”, na tradução de uma fusão de abordagens e métodos. Deixaremos os detalhes do método Fusion para a subseção a seguir e, como bem será fundamentado, este método será visto ao longo de todo o nosso trabalho.

este método será visto ao longo de todo o nosso trabalho. Figura 1.3 - Método Fusion

Figura 1.3 - Método Fusion [Coleman, 1996]

UNIFIED MODELING LANGUAGE (UML) [OMG, 2001]

A UML, juntamente com o método Fusion, forma a base de nossos estudos. Portanto haverá uma

10

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

seção específica para tratá-la (seção 1.1.3). Neste momento vale lembrar apenas que a UML é uma linguagem gráfica para visualizar, especificar, construir e documentar artefatos de sistemas de software. Assim, a UML não se caracteriza como um método ou processo de construção de software, sendo este fato, e a sua padronização, os avais para sua utilização em nosso trabalho, o que também poderá ser feito em empresas de desenvolvimento que adotem métodos e processos proprietários/particulares para construção de software.

1.1.2 - Método Fusion de Análise e Projeto Orientado a Objetos

O Fusion se caracteriza como um método de análise e projeto de sistemas voltado para a produção

de software orientado a objetos. Este método estabelece uma rota direta entre a definição dos requisitos e a implementação do sistema, partindo, contudo, de uma definição de requisitos pré-estabelecida.

Para a condução das fases de análise e projeto, o método Fusion estabelece um conjunto conciso e completo de notações bem-definidas.

A construção do software a partir do método Fusion considera um processo dividido em fases. O

Fusion estabelece o que deve ser feito em cada fase, orientando a sequência de ações de cada fase e os critérios que suportam o ponto de passagem para as fases subsequentes.

O método Fusion não “cobre” a captura de requisitos. Portanto, o mesmo prevê que os requisitos

sejam fornecidos por usuários e documentados seguindo-se alguma técnica de elicitação e de especificação de requisitos "qualquer".

Assim sendo, a divisão proposta pelo método Fusion para o processo de desenvolvimento é Análise, Projeto e Implementação, conforme segue um breve resumo.

ANÁLISE: o que o sistema faz e não como é feito.

“Descobre” os objetos e as classes existentes no sistema e seus relacionamentos;

Define o comportamento esperado do sistema;

Modelos são produzidos para identificar:

Classes de objetos que existem no sistema;

Relacionamentos entre essas classes;

Operações que podem ser executadas no sistema;

Sequências permissíveis para eventos de entrada e de saída;

Não associa métodos às classes.

PROJETO: define como serão implementadas as operações do sistema através do comportamento dos objetos em tempo de execução.

Operações são divididas em interações de objetos;

Operações são associadas às classes;

Como objetos farão referências mútuas entre si;

Relacionamentos de herança entre as classes;

Modelos do projeto identificam:

11

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Como operações serão implementadas pelas interações entre os objetos;

Como as classes farão referências mútuas e como irão se relacionar por herança;

Os atributos das classes e suas operações;

IMPLEMENTAÇÃO: transforma projeto em código.

Herança, referências e atributos são codificados nas classes específicas;

Interações entre objetos são transformadas nos métodos dos objetos;

Máquinas de estado são usadas para se reconhecer as sequências permitidas para as operações;

Também são consideradas técnicas de inspeção e teste para avaliação de sistemas orientados a objetos.

e

identificam as entidades existentes no sistema.

Segue abaixo uma visão geral do método Fusion. São identificadas as fases e os modelos gerados por cada uma delas e como estão interligados.

DICIONÁRIOS DE

DADOS:

são

adotados durante todo o

processo

de desenvolvimento

Figura 1.4 - Estrutura do Método Fusion [Coleman, 1996]

1.1.3 - Padrões de Modelagem de Objetos usando UML - Unified Modeling Language

A UML teve seu desenvolvimento iniciado em outubro de 1994 quando Grady Booch e Jim Rumbaugh, da Rational Software Corporation, começaram seus trabalhos de unificar os métodos Booch e

12

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

OMT. Em 1995 juntou-se com aqueles Ivar Jacobson e sua companhia uniu-se à Rational e seu método OOSE passou a colaborar com a proposta da UML.

//?? Continuar com uma visão estrutural da UML a partir da OMG: não mais de uma ou duas páginas. Procurar uma figura representativa.

1.2 - Método Fusion Expandido e Adaptado à UML

A proposta deste trabalho é resultado do projeto FILM, o qual está institucionalizado na Universidade de Caxias do Sul pelo Departamento de Informática e tem como objetivo adaptar e expandir o método Fusion de análise e projeto de sistemas orientado a objetos. Este ajuste do método também expande o espectro do método Fusion, acrescentando ao mesmo a abordagem da fase inicial de especificação de requisitos, a qual não é considerada na versão original do método Fusion [Galimberti,

2001].

Para a expansão do método e adequação de seus modelos, utiliza-se da proposta da Unified Modeling Language (UML). A UML propõe flexibilidade aos diversos processos de desenvolvimento de software, expandindo métodos orientados a objetos e disponibilizando um conjunto de notações para a construção dos modelos da orientação a objetos [Galimberti, 2001].

Para a fase de Definição de Requisitos o projeto está baseado na proposta “Um Modelo de Estruturação de Requisitos para o Método Fusion Adaptado à UML” [Rocco, 2001]. No entanto, dependendo dos objetivos e carga horária de um curso de APOO, será possível partir de especificações textuais e, preferencialmente, adoção de use cases para a definição de requisitos.

A estrutura geral proposta pelo projeto FILM está demonstrada na figura 1.5 abaixo, a qual foi construída a partir das notações de use case da UML. Esta figura objetiva visualizar a estrutura geral proposta através dos processos e de suas fases. A partir da seção 1.2.1 será oferecida uma visão mais específica sobre as informações a serem documentadas em cada fase através de seus modelos.

13

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Análise e Projeto Orientados a Objetos Figura 1.5 – Estrutura do FILM com atores e processos

Figura 1.5 – Estrutura do FILM com atores e processos (linear e cíclico)

14

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

1.2.1 - Condução das Fases do Método de Especificação e Construção do Software

O projeto FILM prevê as fases de Estruturação e Especificação de Requisitos, Análise, Projeto,

Implementação e Testes. A seguir serão apresentadas e comentadas as estruturas de cada uma das fases propostas no projeto FILM e a serem abordadas nos capítulos posteriores.

Fase de Estruturação e Especificação de Requisitos

A metodologia a ser trabalhada inicia com a Fase de Estruturação e Especificação de Requisitos.

Considerando um processo linear para sua abordagem, deveremos documentar as informações que estão sendo elicitadas conforme a figura 1.6 abaixo. Os principais documentos serão o Documento Contextual do Sistema, Modelo de Objetivos, Visão de Use Case e Cenários e Ciclo de Vida do Sistema. O Planejamento do restante do processo cíclico de desenvolvimento do sistema marca o encerramento desta fase de Especificação de Requisitos.

o encerramento desta fase de Especificação de Requisitos. Figura 1.6 - Fase de Estruturação e Especificação

Figura 1.6 - Fase de Estruturação e Especificação de Requisitos

15

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Fase de Análise

A fase de Análise de nosso trabalho marca o início da investigação interna sobre o sistema e propõe um conjunto de modelos a serem desenvolvidos conforme a figura 1.7. Considerando os ciclos planejados na fase anterior, todos os modelos deverão ser construídos para cada ciclo. Portanto, as principais informações modeladas durante a fase de Análise estarão nos Modelos de Objetos e Modelo de Interfaces. No entanto, conforme a proposta cíclica, o primeiro passo desta fase sugere que os requisitos do ciclo em questão sejam refinados antes de se iniciar o processo de modelagem dos objetos e operações.

se iniciar o processo de modelagem dos objetos e operações. Figura 1.7 - Fase de Análise

Figura 1.7 - Fase de Análise

16

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Fase de Projeto

A fase de Projeto caracteriza-se pela modelagem dinâmica do sistema principalmente em termos das mensagens e dos objetos necessários às operações especificadas na fase de Análise. Portanto, conforme a figura 1.8, as principais informações serão modeladas através dos Grafos de Interação de Objetos. Isto irá viabilizar, para o final da fase de Projeto, que sejam feitos melhoramentos em nossos Modelos de Objetos, buscando iniciar a fase de Implementação com as estruturas/protótipos de classes.

de Implementação com as estruturas/protótipos de classes. Figura 1.8 - Fase de Projeto 17 Por Maurício

Figura 1.8 - Fase de Projeto

17

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Fase de Implementação

Nossa fase de implementação estará caracterizada em se traduzir informações, presentes principalmente nos modelos da fase de Projeto, em Estruturas/Protótipos de Classes de Objetos, conforme observa-se na figura 1.9.

de Classes de Objetos, conforme observa-se na figura 1.9. Figura 1.9 - Fase de Implementação 18

Figura 1.9 - Fase de Implementação

18

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

PARTE I - PROCESSO LINEAR

e Projeto Orientados a Objetos PARTE I - PROCESSO LINEAR Figura Parte I – Processo Linear

Figura Parte I – Processo Linear

19

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

2. Fase de Estruturação e Especificação de Requisitos

A fase de Estruturação e Especificação de Requisitos será tratada através de um processo linear,

onde serão definidos os requisitos para todo o sistema em função de seus objetivos principais. Portanto, esta fase se propõe a investigar e documentar o domínio do problema em estudo tendo como foco os objetivos que serão buscados quando da preparação da solução do problema. Futuramente, após as definições dos ciclos que se iniciam na fase de Análise, todos os requisitos voltarão a ser melhor documentados a partir de outras ferramentas de modelagem.

Para facilitar o trabalho de documentação de requisitos, este capítulo orienta o estudante a buscar um conjunto inicial de informações constantes do Documento Contextual do Sistema. Em seguida será abordada uma técnica para se documentar requisitos a partir de objetivos, onde serão utilizados os Modelos de Objetivos e a Visão de Use Cases para expressar os principais processos identificados no domínio do problema em estudo. Logo após a construção dos use cases será descrita uma maneira de se documentar a interação dos agentes/atores com o sistema e em que sequência isto pode ocorrer.

O tratamento dado aos requisitos antes da fase de Análise estará temporariamente encerrado com o

planejamento das fases seguintes em termos de processos cíclicos de construção do sistema.

Haverá, contudo, uma seção a parte no capítulo voltada a abordar a manutenção de um Glossários de Termos, necessário durante todo o tempo em que será construído o sistema e que, por se constituir em algo bastante simples, não mereceu um capítulo específico para seu estudo.

20

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Análise e Projeto Orientados a Objetos Figura 2.1 – Fase de Estruturação e Especificação de Requisitos

Figura 2.1 – Fase de Estruturação e Especificação de Requisitos

2.1 - Documento Contextual do Sistema

O Documento Contextual do Sistema é dividido em cinco cláusulas que ajudam a criar uma visão

macro do sistema. A partir deste documento já se pode ter uma idéia do sistema e seu enquadramento no ambiente ao qual vai servir, podendo-se prever a viabilidade de construção do projeto.

A orientação é para que este documento contenha as cláusulas, ou seções, conforme abaixo:

Descrição Inicial

Essa descrição expõe uma visão geral do sistema, citando quais módulos o compõem, quais as necessidades que ele pretende atender e o resultado esperado após sua implementação.

Problema Original

É uma exposição da situação atual do ambiente onde o sistema irá atuar, descrevendo todas as

dificuldades existentes e que devem ser solucionadas, ou pelo menos simplificadas, pelo sistema que se está propondo.

Origem do sistema

21

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Esta cláusula deverá identificar se o projeto a ser desenvolvido será de um sistema “novo” ou será uma manutenção para a atualização de um sistema “já existente”. No caso de ser uma atualização sobre um sistema já existente, deve-se analisar o quanto do mesmo poderá ser aproveitado e qual será o volume de alterações que necessitam ser realizadas sobre ele para que o mesmo possa suprir as necessidades dos clientes. Também no caso da atualização, deve-se analisar a relação custo-benefício para que não seja mais oneroso efetuar as alterações sobre o sistema existente do que desenvolver um sistema novo, já voltado para as atuais necessidades.

Contexto de utilização

Esta cláusula consiste na descrição do ambiente onde o sistema irá atuar, tanto em nível local físico quanto em relação ao tipo de agente que irá interagir com ele.

Limites do sistema

Esta cláusula definirá as responsabilidades do sistema dentro dos objetivos. Devem ser definidos quais objetivos serão atendidos pelo sistema e quais deles ficarão sob responsabilidade dos usuários ou de outros sistemas, evitando a criação de falsas expectativas por parte das pessoas envolvidas no projeto.

2.2 - Modelo de Objetivos

O processo de elicitação deve ser concomitante ao modelo de objetivos, o qual define a estruturação das informações. A estrutura das informações prevê a definição do objetivo e a descrição dos objetos que o compõem. São sugeridas questões que tem o propósito de descobrir, ante ao objetivo, os objetos resultado, sujeitos, objetos e ferramentas, conforme as figuras 2.2 e 2.3.

objetos e ferramentas, conforme as figuras 2.2 e 2.3. Figura 2.2 – A definição de um

Figura 2.2 – A definição de um objetivo [Rocco, 2001]

22

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

 

“Esquema” de Descrição de Objetivo

Objetivo

Elicitadas as informações, pode-se definir um objetivo para o sistema em questão. Descrição do objetivo, que em geral responde a um questionamento por quê.

Resultado

Qual o resultado esperado? Por que há a necessidade?

Objeto

Para o que esse objetivo se faz necessário ao sistema?

Sujeito

Quem atua em prol desse objetivo?

Ferramenta

Quais são os recursos necessários para os sujeitos interagirem com o objeto?

Figura 2.3 - Estrutura para a descrição de objetivo [Rocco, 2001]

2.2.1 Estrutura dos Objetivos

Esta estrutura tem por finalidade compor a estrutura hierárquica dos requisitos derivados de cada objetivo. Neste momento apenas os requisitos de nível mais alto são abordados, pois para contemplar um requisito outros requisitos podem ser necessários. Essa estrutura é dada pela associação entre objetivo e requisitos e refinamentos entre os requisitos. O objetivo define uma atividade realizada no sistema, enquanto que os requisitos definem as ações necessárias para a realização completa da atividade.

Essa abordagem hierárquica do modelo permite estruturar os requisitos em níveis verticais de abstração, nos quais os requisitos são associados por qualificadores E, que indica requisitos complementares, e por qualificadores OU, que indica requisitos opcionais para o atendimento à atividade ou às ações hierarquicamente sobrejacentes. A figura 2.4 representa a estrutura dos objetivos.

Em uma primeira etapa do processo proposto, os requisitos são expressos somente em nível inicial, ficando os demais requisitos derivados a serem identificados e definidos posteriormente, após o estabelecimento dos ciclos prioritários para o desenvolvimento.

dos ciclos prioritários para o desenvolvimento. Figura 2.4 – Estrutura dos Objetivos [Rocco, 2001] 23 Por

Figura 2.4 – Estrutura dos Objetivos [Rocco, 2001]

23

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Análise e Projeto Orientados a Objetos Figura 2.5 – Definição de Requisito [Rocco, 2001] Descrição dos

Figura 2.5 – Definição de Requisito [Rocco, 2001]

Descrição dos requisitos nível 0

Cada requisito é descrito segundo estrutura representada na figura 2.6, valendo lembrar que estes requisitos são somente os de nível 0.

 

“Esquema” de Descrição de Requisito

Ação

Nome:

Nome: identificador da ação, como ela é reconhecida dentre os casos de uso do sistema.

Descrição:

Descrição: informação elicitada; tipicamente, uma narrativa como os envolvidos descrevem a ação requerida ao software.

Agente

Solicitante da ação; quem age. É o ente que emite um estímulo requerendo a execução de alguma ação ao sistema.

Produto

Objeto produzido por uma ação realizada na criação, transformação ou destruição do objeto definido no objetivo. Desta maneira, os produtos do requisito são composições dos objetos do objetivo.

Recurso

Objeto que corresponde à interface entre o agente e o software, ou a informação que o agente envia para os objetos do domínio do software para que possam executar alguma ação em prol da produção de algum produto.

Anotação

Descrições de requisitos não funcionais que compõem um requisito modelado.

Figura 2.6 – Estrutura para Descrição de um Requisito [Rocco, 2001]

2.3 - Visão de Use Cases

A seção de Use Cases da especificação de requisitos tem como objetivo apresentar uma estrutura gráfica abrangendo o sistema a partir de seus principais processos e agentes. Portanto, a construção do Diagrama de Use Cases apresenta os atores envolvidos no sistema que está sendo elicitado e com quais processos os mesmos estão em contato.

Atividades e Dependências

Em geral os Use Cases poderão ser convertidos dos requisitos de nível 0. Contudo é possível que sejam derivados diretamente dos objetivos quando estes possuírem requisitos de nível 0 simples ou em pequena quantidade, o que pode ser mais conveniente para a geração do modelo de Use Cases.

24

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Estratégias para Modelagem

A orientação para modelagem dos Use Cases sugere que sejam derivados dos Objetivos

identificados anteriormente. Todavia, não sendo usada a abordagem por objetivos, pode-se partir da especificação de requisitos listando-se possíveis Use Cases e, a partir disso, montar o diagrama associando-os aos seus respectivos atores.

Notações para Modelagem

aos seus respectivos atores. Notações para Modelagem Figura 2.7 – Diagrama de Use Case Estudo de

Figura 2.7 – Diagrama de Use Case

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

2.4 - Cenários e Ciclo de Vida do Sistema

Dentro da fase de Especificação de Requisitos, a construção dos Cenários e do Ciclo de Vida tem como finalidade visualizar a interação dos Atores com o sistema, em um alto nível através dos Use Cases, e a sequência permissível de ocorrência/”execução” destes Use Cases, os quais serão convertidos em Expressões Ciclo de Vida.

Atividades e Dependências

A construção das expressões ciclo de vida são baseadas nos Modelos dos Objetivos e na Visão de Use Case do sistema.

Estratégias para Modelagem

A modelagem do ciclo de vida só pode ser feita dominando-se a sequência e repetições de

ocorrência dos Use Cases, caso isto ocorra. Portanto, observando-se os objetivos e requisitos, e os Use Cases derivados, deve-se ter clareza do sequenciamento dos Use Cases para se estabelecer uma sentença de Ciclo de Vida do sistema conforme ocorrência destes Use Cases.

Notações para Modelagem

A modelagem do ciclo de vida é feita de forma declarativa, necessitando-se de um conjunto

25

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

gramatical para sua representação. Inicialmente serão utilizadas as notações Fusion até que sejam mapeadas para UML. A sintaxe geral para o modelo ciclo de vida segue apresentada abaixo.

Life Cycle [Nome:] Expressão-Regular

(Nome-Local-Expressão = Expressão-Regular)*

-Alfabeto:

qualquer evento de entrada ou saída pode ser utilizado em uma expressão

eventos de saída: precedidos pelo símbolo #

-Operadores: sendo x e y expressões ciclo-de-vida:

x . y denota x seguido por y

x | y denota a ocorrência de x ou y

x * denota zero ou mais ocorrências de x

x + denota uma ou mais ocorrências de x

[ x ] denota que x é opcional

x | | y significa intercalação arbitrária de x e y

-Substituições

Nome = expressão ciclo-de-vida

-Precedência de Operadores (ordem decrescente)

[ ],

*,

+, . ,

|

,

|

|

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

2.5 - Planejamento dos Ciclos de Construção do Sistema

A tarefa de planejar os ciclos de desenvolvimento do sistema não sugere atualmente nenhuma forma específica de modelagem. As diretrizes básicas, contudo, orientam que os ciclos de construção do sistema sejam programados com o objetivo de liberar pequenos módulos aos usuários para que possam ser gradativamente testados e melhorados. A tendência é que cada ciclo não consuma mais de dois meses para ser construído (analisado, projetado e implementado).

Atividades e Dependências

O planejamento dos ciclos, partindo de prazos estabelecidos e necessidades dos usuários, sugere a estruturação de cronogramas de construção por ciclo. Assim sendo, as informações de objetivos e use cases, bem como o ciclo de vida do sistema, devem ser o ponto inicial de observação para organizar os ciclos por prioridades do sistema e dos usuários e preparar a passagem para as fases seguintes do processo de construção do software.

Os ciclos devem ser planejados considerando o tempo para sua conclusão, tendo como objetivo sua implantação e colocação em teste junto aos usuários. O objetivo é que cada ciclo seja estanque, sendo

26

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

necessária a sua conclusão para que possa ser encaminhado o início de um novo ciclo. Isto não inviabiliza

a construção incremental de ciclos, pois também se tem como objetivo o escalonamento do

desenvolvimento através de versões diferentes de construção dos use cases ou objetivos do sistema.

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

2.6 - Manutenção de um Glossário de Termos

O glossário de termos serve para documentar informações que requeiram melhores esclarecimentos,

de modo a melhorar a comunicação e evitar mal-entendidos. Originalmente denominado dicionário de dados também no método Fusion, será referenciado como glossário de termos pelo seu caráter de registrar não apenas dados, mas também quaisquer informações e restrições que não possam ser colocadas nos diagramas construídos ao longo do processo de análise e projeto de sistemas.

Um glossário de termos representa uma ferramenta vital onde todas as definições feitas devem ser

encontradas. Manter o glossário de termos é uma atividade contínua durante todo processo de construção

do sistema e por menor que seja a descrição de um item, ainda assim é a melhor forma de deixar claro o

seu significado.

O método Fusion orienta para a construção de um glossário, porém não obriga a uma sintaxe e

notações específicas. Portanto, neste trabalho, é sugerida uma forma básica para documentação dos itens através de tabelas. As coleções de itens de mesma categoria podem ser documentadas em tabelas específicas, otimizando a localização dos termos.

Estratégias para Modelagem

Considerando que a manutenção do glossário de termos seja uma atividade constante durante todo o

processo de construção do sistema, orienta-se para que o mesmo seja atualizado ou durante a construção dos diagramas ou logo após o encerramento dos mesmos. Segue abaixo uma sugestão de como estruturar

as informações dentro do glossário de termos.

Notações para Modelagem

A documentação do glossário, em geral, será possível através de uma tabela de três colunas como

abaixo. No entanto, conforme o momento do processo de construção do sistema, outras colunas poderão ser acrescentadas para melhor descrever determinados termos.

Nome do Termo

 

Categoria

Descrição

Identificação

do

termo

Designação do tipo do termo em relação ao seu propósito de modelagem

Texto descritivo

modelado

Figura 2.8 – Glossário de Termos

27

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

PARTE II - PROCESSO CÍCLICO

e Projeto Orientados a Objetos PARTE II - PROCESSO CÍCLICO Figura Parte II - Processo Cíclico

Figura Parte II - Processo Cíclico

28

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

3. Fase de Análise

A função da fase de Análise é, baseada no documento de requisitos, ou seja, no resultado gerado

pelo documento do sistema, identificar as classes de objetos existentes no sistema, descrever os relacionamentos entre elas e definir as operações que poderão ser executadas pelo sistema. A fase de Análise mostra "o que" o sistema faz e não "como" ele é feito, obtendo-se ao final desta fase um "documento de especificações".

A construção de dois modelos estáticos são os objetivos da fase de Análise, os quais tratam de

aspectos diferentes, sendo o Modelo de Objetos e o Modelo de Interfaces, este último sendo composto pelos Cenários e seus Modelos de Ciclo de Vida e pelo Modelo de Operações. Assim, esta fase do processo é responsável pelas seguintes descrições: classes de objetos (sem associar quaisquer métodos às classes); relacionamentos entre classes; operações do sistema; sequência permissível de operações. No entanto, a proposta de um processo cíclico exige que os requisitos a serem tratados sejam melhor detalhados. Assim, a proposta para a fase de Análise prevê que os requisitos sejam refinados modelando- os por Objetivo (Modelo de Requisitos por Objetivo) e adotando-se os Cenários para melhor visualizá-los. A figura 3.1 oferece uma visualização, através de use cases, da estrutura a ser modelada durante a fase de Análise.

da estrutura a ser modelada durante a fase de Análise. Figura 3.1 – Fase de Análise

Figura 3.1 – Fase de Análise

3.1 - Condução da Fase de Análise

A fase de análise deve ser conduzida de forma a transformar as informações coletadas durante a fase

de definição de requisitos em modelos que representem as estruturas estáticas do sistema e o comportamento do mesmo. No entanto, a partir da fase de Análise o sistema será modelado através de um processo cíclico. Este processo foi estabelecido de forma a viabilizar a construção incremental do sistema.

29

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Assim sendo, o primeiro passo da fase de Análise será estruturar o ciclo em questão, o que deve ser feito com o aprimoramento dos requisitos documentados na fase anterior, caraterizando em um refinamento dos requisitos a partir dos objetivos antes brevemente descritos. Inicialmente, anterior aos detalhes dos requisitos, deve ser modelado o comportamento do sistema de forma a identificar quais são as interações existentes entre o sistema, durante o(s) use case(s) em questão, e o meio em que está inserido. Isto será feito através da representação de eventos de entrada e de saída entre o sistema, o qual seve ser visto como uma caixa preta.

Modelagem Fusion:

Cenários

Sequências;

do

Sistema

por

Objetivo:

utilizar

notações

padrão

Modelagem de Refinamento de Requisitos:

UML

para

Diagrama

de

Modelo de Requisitos por Objetivo: utilizar notações da abordagem de Requisitos por Objetivo

Com uma abordagem orientada a objetos, as primeiras modelagens devem representar as classes de objetos através de conceitos relevantes à solução do problema em análise – em geral substantivos que podem ser submetidos a uma lista de categorias, conforme [Larman, 2000] – identificados nas informações até então documentadas. Estes conceitos serão modelados como classes de objetos que se relacionam entre si através de restrições de cardinalidades. São identificados também os primeiros atributos de cada classe de objeto. A sugestão inicial é que as associações (relacionamentos) sejam simples, protelando-se associações dos tipos agregações, generalizações e especializações para um momento mais propício da fase de Projeto.

Modelagem Fusion:

Modelo de Objetos: utilizar notações padrão UML do Diagrama de Classes.

As próximas informações a serem modeladas caracterizam-se por representar a estrutura comportamental do sistema. O comportamento do sistema deve ser documentado de forma a identificar quais são as interações existentes entre o sistema e o meio em que está inserido. Isto já deve ter sido feito nos cenários através da representação de eventos de entrada e de saída entre o sistema, no entanto agora deve ser modelada a sequência permissível para ocorrência destes eventos dentro do ciclo de vida do sistema. Portanto, neste momento da fase de Análise deve-se modelar os eventos de entrada como operações do sistema. Assim, as operações serão documentadas de forma a identificar quais estruturas de objetos deverão ser manipuladas para realizar cada operação e suas responsabilidades. As operações modelam os eventos de entrada e seus efeitos no sistema, os quais podem ser as alterações no estado do sistema e/ou os eventos gerados na saída.

A fase de Análise será encerrada estabelecendo-se as fronteiras do sistema, no Modelo de Objetos, em relação ao meio em que está inserido. Isto será feito com a construção do Modelo de Objetos do Sistema, onde serão mantidas as estruturas de classes e associações necessárias às operações do sistema juntamente com os atores/agentes que interagem com o mesmo.

Modelagem Fusion:

Modelo de Interfaces:

Modelo Ciclo de Vida: utilizar notações Fusion até adaptação à UML; Modelo de Operações: utilizar notações padrão UML para Contratos; Modelo de Objetos do Sistema: utilizar notações padrão UML do Diagrama de Classes

30

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

juntamente com Atores dos Use Cases.

3.2 - Refinamento dos Requisitos por Ciclo

Considerando o processo cíclico a ser abordado na fase de Análise, o primeiro passo agora é partir dos requisitos documentados, na fase anterior, no formato de objetivos e aprimorar os conhecimentos sobre cada um deles, dentro de seu respectivo ciclo.

O refinamento dos requisitos é feito a partir dos Modelos de Objetivos do(s) Use Case(s) do ciclo.

Serão desenvolvidos os Cenários respectivos aos Use Case(s) em questão e os Modelos de Requisitos por Objetivo.

3.2.1 Cenários do Sistema por Objetivo

Em paralelo à expansão dos requisitos, descritos na seção 3.2.2, deve ser modelado o comportamento do sistema de forma a identificar quais são as interações existentes entre o sistema, durante o(s) use case(s) em questão, e o meio em que está inserido. Isto será feito através da representação de eventos de entrada e de saída entre o sistema, o qual deve ser visto como uma “caixa preta”.

Abaixo segue um esquema com a notação a ser utilizada para a modelagem dos Cenários, o qual adota o padrão UML para Diagrama de Sequências.

Atividades e Dependências

A construção dos cenários deve partir da especificação de requisitos, mais especificamente a partir

do Modelo de Objetivos e dos Use Cases. Seu desenvolvimento também depende do Modelo de Requisitos por Objetivo, sugerindo que sejam construídos em paralelo.

Estratégias para Modelagem

A principal orientação para montagem dos Cenários está na identificação dos atores e suas ações, o

que pode ser feito observando-se as cláusulas dos “Esquemas” de Descrição de Requisitos do objetivo em questão. As principais cláusulas são “Ação”, “Agente” e “Recurso”.

31

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Notações para Modelagem

e Projeto Orientados a Objetos Notações para Modelagem Figura 3.2 – Cenários com notação UML de

Figura 3.2 – Cenários com notação UML de Diagrama de Sequência

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

3.2.2 Modelo de Requisitos por Objetivo

Os requisitos deverão agora ser expandidos para o Objetivo em questão no ciclo. A estrutura a ser utilizada é exatamente a mesma vista na seção 2.2 de Modelo de Objetivos, porém agora os requisitos deverão ser melhor detalhados, abaixo do nível 0. Vale voltar e observar as figuras 2.4, 2.5 e 2.6.

Portanto, cada requisito será refinado conforme definição da figura 2.5, estando suas cláusulas comentadas na seção 2.2.1, na figura 2.6.

Atividades e Dependências

Como bem pode-se observar, a construção deste modelo está diretamente ligada ao Modelo de Objetivos e aos Cenários.

Estratégias para Modelagem

Partindo do Modelo de Objetivos, a cláusula “Ação” deve ser o ponto inicial de investigação para a descrição do requisito em si, buscando-se definir outros objetos que compõem o requisito.

Notações para Modelagem

Ver seção 2.2.1, figura 2.6.

Estudo de Caso

SistSW01 (Apêndice A);

32

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

SistSW02 (Apêndice B).

3.3 - Modelo de Objetos (Modelo Conceitual)

A abordagem do modelo de objetos visa representar as classes de objetos através de conceitos

identificados nas informações até então documentadas. Estes conceitos serão modelados como classes de objetos que se relacionam entre si através de associações e restrições de cardinalidades. São identificados também os primeiros atributos de cada classe de objeto. A sugestão inicial é que as associações (relacionamentos) sejam simples, protelando-se associações dos tipos agregações, generalizações e especializações para um momento mais propício da fase de Projeto.

Abaixo segue um esquema com a notação a ser utilizada para a modelagem dos objetos, o qual adota o padrão UML para Diagrama de Classes.

Atividades e Dependências

A modelagem dos objetos depende dos requisitos até então coletados para o ciclo em questão.

Devem ser observados os Cenários e os Modelos de Requisitos por Objetivo. A partir do segundo ciclo de desenvolvimento, vale lembrar em observar os modelos de objetos já construídos, pois pode-se reutilizar classes de objetos já modeladas.

Estratégias para Modelagem

Uma das tarefas mais complicadas quando se começa a modelar objetos é a identificação das classes de objetos. Várias são as técnicas utilizadas para sua modelagem, no entanto não existe nenhuma fórmula mágica para este fim.

O procedimento básico, contudo, é partir das especificações de requisitos correspondentes ao ciclo

em questão. Nossa sugestão é utilizar de duas técnicas em conjunto, sendo a técnica gramatical de Booch [Booch, 1994] e de uma lista de categorias sugerida em [Larman, 2000].

A tarefa inicial é formar uma lista dos substantivos encontrados ao longo da especificação de

requisitos, os quais serão candidatos a classes. A partir daí deve-se buscar sua identificação nas tabelas de categorias de [Larman, 2000] buscando qualificar o conceito como classe de objeto ou como atributo. A lista de substantivos gerada também facilita a eliminação de redundâncias (conceitos de objetos semelhantes ou repetidos).

) como em bancos de dados. Isto deverá ser

feito no momento de mapear as classes de objetos para uma estrutura de dados persistentes.

Busque não modelar chaves (primárias, estrangeiras,

33

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Notações para Modelagem

e Projeto Orientados a Objetos Notações para Modelagem Figura 3.3 – Modelo de Objetos com Notações

Figura 3.3 – Modelo de Objetos com Notações UML do Diagrama de Classes

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

3.4 - Modelo de Interfaces

O comportamento do sistema deve ser documentado de forma a identificar quais são as interações existentes entre o sistema e o meio em que está inserido. Isto já deve ter sido feito através da representação de eventos de entrada e de saída entre o sistema, através dos Cenários anteriores, mas agora deve ser modelada a sequência permissível para ocorrência destes eventos dentro do ciclo de vida do sistema. A fase de Análise se encerra modelando-se os eventos de entrada como operações do sistema. Portanto, as operações serão documentadas de forma a identificar quais estruturas de objetos deverão estar disponíveis para realizar cada operação e suas responsabilidades. As operações modelam os eventos de entrada e seus efeitos no sistema, os quais podem ser as alterações no estado do sistema e os eventos

34

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

gerados na saída.

3.4.1 Cenários e Modelo Ciclo de Vida

Dentro do Modelo de Interfaces, a construção do Ciclo de Vida tem como finalidade modelar a sequência permissível de ocorrência dos eventos de entrada e de saída, considerando que os Cenários, construídos no início da fase de Análise, não tem este propósito.

Atividades e Dependências

A construção das expressões ciclo de vida são baseadas nos Cenários e fundamentadas nos

requisitos especificados nos use cases e objetivos em questão no ciclo.

Estratégias para Modelagem

A modelagem do ciclo de vida só pode ser feita dominando-se a sequência e repetições de

ocorrência dos eventos previamente modelados. Portanto, deve-se ter clareza do funcionamento do use case em questão e dos requisitos para se alcançar o objetivo que está sendo abordado. Lembra-se que foi especificado, ainda na fase de Definição de Requisitos, um Modelo Ciclo de Vida baseado em use cases, o que facilita o refinamento de suas expressões/subexpressões.

Notações para Modelagem

A modelagem do ciclo de vida é feita de forma declarativa, necessitando-se de um conjunto

gramatical para sua representação. Inicialmente serão utilizadas as notações Fusion até que sejam

mapeadas para UML. O conjunto notacional está especificado abaixo, sendo o mesmo descrito na seção

2.4.

-Alfabeto:

qualquer evento de entrada ou saída pode ser utilizado em uma expressão eventos de saída: precedidos pelo símbolo #

-Operadores: sendo x e y expressões ciclo-de-vida:

x

. y denota x seguido por y

x

| y denota a ocorrência de x ou y

x

* denota zero ou mais ocorrências de x

x

+ denota uma ou mais ocorrências de x

[

x ] denota que x é opcional

x

| | y significa intercalação arbitrária de x e y

-Substituições

Nome = expressão ciclo-de-vida

-Precedência de Operadores (ordem decrescente)

[ ],

*, +, . ,

|

,

|

|

Estudo de Caso

SistSW01 (Apêndice A);

35

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

SistSW02 (Apêndice B).

3.4.2 Modelo de Operações

A construção do modelo de operações marca o momento do processo em que se começa a investigar

as estruturas internas do sistema em construção. As operações serão modeladas através de fichas com um conjunto de cláusulas. Cada cláusula tem seu propósito de transformar os requisitos do objetivo em referências às estruturas até então modeladas como objetos. Portanto, cada evento de entrada se transformará em uma operação, merecendo uma ficha/esquema de modelagem, a partir da qual serão documentadas as responsabilidades da operação e os efeitos causados ao sistema após sua execução.

Possíveis resultados associados a uma operação do sistema, são:

Criar uma nova instância de classe;

Alterar atributos de objetos existentes/instanciados;

Criar/eliminar “tuplas” de relacionamentos;

Envia um evento a um agente.

Atividades e Dependências

A construção do Modelo de Operações depende praticamente de todas informações documentadas

até então para o ciclo em questão. A base da modelagem das operações, contudo, é formada pelo Modelo de Objetos, Cenários e Ciclo de Vida além, é claro, das especificações de requisitos através do Modelo de Requisitos por Objetivo.

Estratégias para Modelagem

A estratégia para modelagem das operações deve iniciar observando-se os Cenários e as expressões

Ciclo de Vida do ciclo, transformando cada evento de entrada em uma ficha de operação. A partir disso, as tarefas restantes terão o propósito de preencher as demais cláusulas do esquema de operações.

36

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Notações para Modelagem

A modelagem das operações é feita de forma declarativa, adotando-se cláusulas da notação padrão UML dos Contratos. As cláusulas devem estar dispostas em um “esquema de operação”, conforme sugestão abaixo.

 

“Esquema” de Operação

Nome

Nome da operação, geralmente o mesmo do evento de entrada que a originou;

Responsabilidades

Texto descritivo sobre as características principais da operação, principalmente no que se refere às responsabilidades da mesma;

Referências Reads

Itens.

Nesta cláusula devem ser relacionados quais itens objeto necessita-se manipular (com acesso de leitura) para executar a operação. Possível uso da palavra-reservada supplied (fornecido) precedendo um parâmetro da operação;

Referências

Itens.

Changes

Análogo à cláusula anterior, nesta devem ser relacionados quais itens objeto necessita-se manipular (com acesso de gravação/escrita) para executar a operação. Possível uso da palavra-reservada new (novo) precedendo um Item-objeto, o que indica que esta operação irá criar um novo objeto no estado do sistema;

Saída

Agentes_E_Eventos.

Especificar, quando houver, eventos gerados ao final da operação juntamente com os destinatários dos mesmos. Portanto, é uma lista com todos os agentes e os eventos que a operação deve lhes enviar. Cada Agente_E_Evento engloba o nome de um agente e todos os eventos que lhe possam ser enviados;

Pré-condições

Condição.

Introduz predicado (lista de cláusulas) que define condições a serem assumidas para que a operação possa ser executada. Todas/cada cláusula deve ser True para que o predicado seja satisfeito (E lógico). Referencia apenas parâmetros ou partes do estado que tenham sido definidos em Reads e Changes;

Pós-condições

Condição.

Introduz predicado (lista de cláusulas) que define os resultados (alterações no estado do sistema e/ou eventos de saída) após a execução da operação. Relaciona estado do sistema antes e depois de ter sido ativada a operação. Palavras-reservadas initial e final podem preceder um identificador quando da necessidade de especificar o estado do sistema antes e após a execução da operação.

Figura 3.4 – “Esquema” de Operação com recursos UML para Contratos

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

3.5 - Modelo de Objetos do Sistema (Modelo Conceitual)

“Um modelo de objetos apresenta um modelo do domínio do problema. Assim, as classes e os relacionamentos podem especificar conceitos pertencentes ao ambiente do sistema, bem como os inerentes ao próprio sistema.

Um Modelo de Objetos do Sistema representa um subconjunto de um Modelo de Objetos

37

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

relacionado ao sistema a ser construído. Este modelo será derivado do Modelo de Objetos “excluindo-se” as classes e relacionamentos que pertençam unicamente ao ambiente do sistema e não ao próprio sistema [Coleman, 1996].

Atividades e Dependências

O Modelo de Objetos do Sistema está diretamente vinculado ao Modelo de Objetos, devendo-se também observar informações de requisitos que identifiquem agentes do sistema, como Cenários e Modelo de Operações.

Estratégias para Modelagem

Observando-se os Cenários e os Modelos de Operações, deve-se filtrar os Modelos de Objetos de forma a manter apenas objetos necessários à própria estrutura interna do sistema. O método Fusion orientava para que fosse criada uma espécie de fronteira, através de uma linha pontilhada, delimitando os objetos do sistema e os agentes. No entanto, com a UML poderemos utilizar a notação para agentes/atores, através de bonecos-palito, e os objetos que não forem nem agentes nem objetos do sistema, serão excluídos deste “novo” modelo.

Notações para Modelagem

As notações para o Modelo de Objetos do Sistema serão padrão UML onde a única diferença da notação do Diagrama de Classes UML (ver seção 3.3) é a substituição de algumas classes-agentes por bonecos-palito na função de atores/agentes, sendo este último padrão dos Diagramas de Use Case (ver seção 2.3).

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

3.6 - Verificação dos Modelos da Fase de Análise

Seguindo as orientações de [Coleman, 1996], nesta seção serão apresentadas algumas diretrizes para a verificação dos modelos de análise no que se refere à inteireza e à consistência em relação aos requisitos.

Inteireza com requisitos: releia com cuidado o documento de requisitos e resolva quaisquer dúvidas com o cliente/usuários. Em seguida, verifique se:

Todos os cenários possíveis foram tratados pelo ciclo de vida;

Todas as operações do sistema foram definidas com o uso de um esquema de operações;

Todas as informações estáticas foram capturadas pelo modelo de objetos do sistema;

Todas as outras informações estão documentadas no glossário de termos.

Consistência: essas verificações relacionam-se com a sobreposição entre os modelos de análise. Verifique se:

Todas as classes, relacionamentos e atributos mencionados no modelo de operações aparecem no modelo de objetos do sistema. Todos os outros conceitos devem estar definidos no glossário de

38

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

termos ou em alguma outra fonte de referência;

A fronteira do modelo de objetos do sistema é consistente com a interface do sistema fornecida pelo modelo ciclo-de-vida;

Todas as operações do sistema, presentes no modelo ciclo-de-vida, possuem um esquema de operações;

Todos os identificados utilizados em todos modelos se encontram do glossário de termos.

39

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

4. Fase de Projeto

A fase de Projeto caracteriza-se por transformar as informações modeladas durante a fase de Análise

em estruturas arquiteturais de projeto com o objetivo de viabilizar a implementação do sistema. As informações da fase de Projeto caracterizam a modelagem dinâmica do sistema, principalmente em termos dos objetos necessários às operações através da troca de mensagens entre os mesmos. Ao final da fase de Projeto busca-se ter uma estrutura hierárquica de classes e o refinamento do Modelo de Objetos do Sistema da fase de Análise, o que irá caracterizar os requisitos essenciais à passagem para a fase de Implementação.

Os objetivos da fase de Projeto passam pela construção inicial dos Grafos de Interação de Objetos, a partir do qual são modeladas as operações do sistema através da troca de mensagens entre os objetos. Posteriormente o Modelo de Objetos do Sistema poderá ser refinado de forma a viabilizar a estrutura hierárquica de classes, ao final do projeto, prevendo o início da implementação.

A figura 4.1 oferece uma visualização, através de use cases, da estrutura a ser modelada durante a

fase de Projeto.

da estrutura a ser modelada durante a fase de Projeto. Figura 4.1 – Fase de Projeto

Figura 4.1 – Fase de Projeto

4.1 - Condução da Fase de Projeto

A fase de Projeto deve ser conduzida buscando transformar as informações da fase de Análise em

estruturas arquiteturais de projeto com o objetivo de viabilizar a implementação do sistema. As informações da fase de Projeto caracterizam a modelagem dinâmica do sistema principalmente em termos dos objetos necessários às operações através da troca de mensagens entre os mesmos.

40

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Tudo o que foi analisado deve ser observado para se iniciar a fase de Projeto, onde deve-se construir as estruturas dinâmicas de trocas de mensagens entre os objetos necessárias para satisfazer os Modelos de Operações da fase de Análise. Assim, para a modelagem dos Grafos de Interação de Objetos deverão ser observados os Modelos de Objetos do Sistema, o Modelo de Operações e o Modelo de Ciclo de Vida.

Modelagem Fusion:

de

Colaboração;

Grafos

Interação

de

Objetos:

utilizar

notações

padrão

UML

do

Diagrama

de

Ao final da fase de Projeto deve haver uma espécie de lapidação das estruturas de classes de forma a se otimizar os Modelos de Objetos do Sistema. Isto será feito melhorando estes modelos através de relacionamentos de agregação e através da montagem de uma estrutura hierárquica de classes feita através de associações de generalização e especilização, estas últimas comumente conhecidas como Grafos de Herança dentro do método Fusion.

Modelagem Fusion:

Refinamento

Diagrama de Classes;

Grafos de Herança: utilizar notações padrão UML para estrutura de Herança do Diagrama

de Classes;

UML do

do Modelo

de Objetos do Sistema: utilizar notações padrão

4.2 - Grafos de Interação de Objetos

A abordagem dos Grafos de Interação de Objetos visa representar a troca de mensagens entre os

objetos para satisfazer as operações modeladas na fase de Análise. Deve ser desenvolvido um Grafo de Interação de Objetos para cada operação modelada no sistema.

Abaixo segue um esquema com a notação a ser utilizada para a modelagem destes grafos, o qual adota o padrão UML para Diagramas de Colaboração.

Atividades e Dependências

A modelagem das trocas de mensagens entre os objetos depende diretamente da observação dos

Modelos de Operações, do Modelo de Objetos do Sistema e do Modelo Ciclo de Vida em um segundo plano. A principal colaboração dos GIO serão os métodos que os objetos passarão a ter após sua modelagem o que fornece a estrutura dinâmica do sistema em projeto.

Estratégias para Modelagem

O primeiro passo para modelar as interações entre os objetos é partir Modelos de Operações,

geralmente com as operações tendo o mesmo nome dos eventos de entradas do Modelo Ciclo de Vida. A partir daí, deve ser gerado um GIO para cada Modelo de Operação. Assim sendo, cada cláusula do Modelo de Operações deverá ser observada buscando as informações necessárias para a modelagem dos GIO, conforme descrito abaixo.

41

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Notações para Modelagem

e Projeto Orientados a Objetos Notações para Modelagem Figura 4.2 – Grafos de Interação de Objetos

Figura 4.2 – Grafos de Interação de Objetos com notações UML de Diagramas de Colaboração

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

4.3 - Refinamento do Modelo de Objetos do Sistema

O Modelo de Objetos do Sistema, inicialmente construído na fase de Análise e delimitado ao

domínio do sistema, deve agora ser refinado de forma a melhorar o significado e a visualização de suas estruturas.

Usaremos de dois mecanismos para melhorar nossos modelos, sendo as associações de Agregação e Herança, conforme descrito abaixo.

4.3.1 Agregações

A Agregação é um mecanismo que permite construir uma classe agregada a partir de outras classes componentes e de relacionamentos de classes. Uma classe agregada pode ser tratada como qualquer outra classe, podendo possuir atributos e participar de relacionamentos.

Atividades e Dependências

A identificação das agregações depende diretamente dos Modelos de Objetos do Sistema já

construídos até então, podendo também ser necessário consultar documentos de requisitos para reconhecer características de agregação.

Estratégias para Modelagem

Uma orientação bastante útil para se identificar agregações diz respeito à análise da expressão (geralmente contendo um verbo) existente no relacionamento entre classes que estão prestes a se

42

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

agregarem. Em geral a agregação modela relacionamentos "parte de" ou "contém um". Portanto, uma classe que está associada a outra através de um relacionamento do tipo "has a" é forte cadidata à agregação. Assim sendo, uma forma de se identificar este tipo de associação é, além dos requisitos de objetos, identificar nos relacionamentos verbos ou expressões verbais como: tem um, contém um, está em, é parte de,

Notações para Modelagem

A modelagem das Agregações utiliza de uma notação gráfica específica, eliminando-se o nome do verbo/expressão verbal relativa à associação que está sendo substituída.

relativa à associação que está sendo substituída. Figura 4.3 – Agregação como parte da notação UML

Figura 4.3 – Agregação como parte da notação UML do Diagrama de Classes

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

4.3.2 Herança - Estrutura Hierárquica de Classes

A Herança é um tipo de relacionamento onde a classe que herda (subclasse/subtipo) possui todas as propriedades da classe herdada (superclasse/supertipo), podendo também possuir outras mais, o que nos levará a construir uma Estrutura Hierárquica de Classes, objetivando-se assim a reutilização de classes em outros projetos.

Atividades e Dependências

A identificação das Estruturas de Herança também depende diretamente dos Modelos de Objetos do Sistema já construídos até então, sendo necessário consultar as mesmas Estruturas já construídas e documentos de requisitos para reconhecer características de herança, às vezes também citadas como generalizações/especializações.

43

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Estratégias para Modelagem

A orientação para se identificar generalizações/especializações (herança) é semalhante à usada para identificar agregações e diz respeito à análise da expressão (geralmente contendo um verbo) existente no relacionamento entre classes envolvidas. A generalização modela relacionamentos "tipo de" ou "é um". Portanto, uma classe que está associada a outra através de um relacionamento do tipo "king of" ou "is a" é forte cadidata a se tornar subclasse de outra (superclasse).

Notações para Modelagem

A modelagem de Herança utiliza de uma notação gráfica específica, também eliminando-se o nome do verbo/expressão verbal relativa à associação que está sendo substituída.

relativa à associação que está sendo substituída. Figura 4.4 – Herança como parte da notação UML

Figura 4.4 – Herança como parte da notação UML do Diagrama de Classes

Estudo de Caso

SistSW01 (Apêndice A);

SistSW02 (Apêndice B).

4.4 - "Visibilidade"

O Documento

4.5 - Verificação dos Modelos da Fase de Projeto

Nesta seção apresenta-se orientações para a verificação dos modelos de projeto em relação à especificação da fase de análise e às funcionalidades do sistema, conforme [Coleman, 1996].

Consistência com a especificação do sistema: verificar que somente as classes representadas nos grafos de interação de objetos sejam consideradas como parte do modelo de objetos do sistema para posterior implementação. Novas classes poderão ser introduzidas durante a fase de projeto sem que sejam mostradas no modelo de objetos do sistema desenvolvido durante a análise.

44

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Verificação do efeito funcional:

Verificar se o efeito funcional de cada grafo de interação de objetos satisfaz à especificação da sua

operação definida no modelo de operações.

Verificar se todas as cláusulas Result do esquema de operações encontram-se satisfeitas.

Refinamento do modelo de objetos do sistema:

modelo de objetos do sistema foram devidamente

convertidas, quando possível, em estruturas de agregação e generalização para otimização do respectivo modelo.

Verificar se as associações originais do

45

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

5. Fase de Implementação

A fase de Projeto de nosso trabalho terá como característica transformar as informações modeladas

durante a fase de Projeto em estruturas de código no formato de protótipos de classes de objetos.

Considerando que a modelagem dos Grafos de Interação de Objetos permitiu a especificação dos métodos inerentes a cada classe de objeto e o Refinamento do Modelo de Objetos do Sistema permitiu a melhora estrutural dos mesmos, o objetivo agora será escrever o código-fonte relativo às estruturas dos objetos em termos de seus atributos e métodos.

A proposta deste trabalho é a flexibilidade, orientando apenas para que seja gerado código com a

sintaxe de uma linguagem de programação orientada a objetos. Os exemplos serão construídos em C++ ou em Java, dependendo da comodidade em relação às atividades desenvolvidas no curso.

A figura 5.1 oferece uma visualização, através de use cases, da estrutura a ser modelada durante a

fase de Projeto.

da estrutura a ser modelada durante a fase de Projeto. Figura 5.1 – Fase de Implementação

Figura 5.1 – Fase de Implementação

5.1 - Condução da Fase de Implementação

A fase de Implementação deve ser conduzida observando-se os modelos construídos principalmente

46

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

durante a fase de Projeto juntamente com as especificações contidas no Glossário de Termos. Lembra-se que serão montados protótipos estruturais das classes de objetos projetadas, os quais estarão formados pelo nome da classe, seus atributos e tipos e as “assinaturas” dos métodos.

Modelagem:

Não há regras notacionais para a estruturação das classes, sugerindo-se apenas o uso da sintaxe de uma

linguagem de programação orientada a objetos.

5.2 - Geração dos Protótipos e Estruturas de Classes de Objetos

A estruturação das classes de objetos será feita codificando-se estas classes em linguagem de programação orientada a objetos, escrevendo-se seus atributos e “assinaturas” de métodos, sem necessariamente implementar estes últimos.

Atividades e Dependências

A codificação das estruturas de classes poderá ser feita unicamente observando-se os modelos gerados na fase de Projeto. Para quaisquer outras informações pode ser necessário consultar o Glossário de Termos.

Estratégias para Modelagem

Para que sejam identificadas quais classes serão implementadas, deve-se observar quais delas são necessárias às operações do sistema. Portanto, os Grafos de Interação de Objetos fornecem a informação sobre quais classes implementar. Considerando, contudo, que houve o refinamento do Modelo de Objetos do Sistema após a construção dos GIO, provavelmente a tarefa de selecionar as classes a serem implementadas já pode ter sido feita, isto é, através da “exclusão”, do MOS, das classes desnecessárias às operações. Assim sendo, bastará observar o Modelo de Objetos do Sistema.

Portanto, os atributos podem ser identificados no Modelo de Objetos do Sistema e/ou Glossário de Termos e os métodos nos Grafos de Interação de Objetos, caso ainda não tenham sido atualizados no Modelo de Objetos do Sistema.

5.3 - Verificação das Estruturas de Classes de Objetos

Para checar as estruturas de classes, algumas verificações básicas serão úteis:

Atributos de Dados: verificar que todos os atributos de dados do Modelo de Objetos do Sistema apareçam nas estruturas de classes;

Atributos Objeto: em geral as estruturas de agregação identificadas nos Modelos de Objetos do Sistema darão origem a atributos objeto;

Métodos e Parâmetros: garantir que todos os métodos e argumentos dos Grafos de Interação de Objetos apareçam nas estruturas de classes;

Herança: verificar que todas as estruturas de herança estejam registradas; garantir que as estruturas de classes contenham todos os métodos comuns preliminarmente definidos, respeitando as estruturas de herança.

47

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

6. Conclusões

A proposta de adaptação do Fusion para a UML ainda é um trabalho em andamento, considerando que ainda existem modelos que não encontram similares na atual versão da UML. No entanto, os objetivos estão sendo alcançados com as atuais “trocas” de notações.

O balanço final do trabalho pode considerar que dos praticamente oito modelos/técnicas desenvolvidos pelo Fusion, já se conseguiu adaptar totalmente cinco deles. Cita-se o mapeamento completo do Modelo de Objetos, o Modelo de Interfaces, enquanto tratamento dos Cenários e dos Modelo de Operações, o Modelo de Objetos do Sistema, o Grafo de Interação de Objetos e os Grafos de Herança. Enquanto adaptações parciais, considera-se em vias de conclusão o mapeamento do Modelo Ciclo de Vida. Por fim, cita-se também o estudo do Diagrama de Componentes da UML para adaptação à fase de Implementação do Fusion, podendo vir a auxiliar o gerenciamento dos processos de codificação do sistema de software.

Portanto, os resultados do trabalho somente não são totais em virtude dos Grafos de Visibilidade, pois no caso das Descrições de Classes as mesmas são direcionadas especificamente para código-fonte.

48

Por Maurício F. Galimberti

Análise e Projeto Orientados a Objetos

Bibliografia

ALHIR, S. Si. UML in a Nutshell - A Desktop Quick Reference. O'Reilly & Associates, 1998.

BOOCH, G. Object-Oriented Analysis and Design with Applications. Addison Wesley, 1994.

COAD, P. & YOURDON, E. Análise Baseada em Objetos. Rio de Janeiro: Campus, 1992.

COLEMAN, D. et All. Desenvolvimento Orientado a Objetos - O Método Fusion. Rio de Janeiro:

Campus, 1996.

FOWLER, M. & SCOTT, Kendall. UML Distilled - Applying the Standard Object Modeling Language. Massachusetts: Addison-Wesley, 1997.

GHEZZI, C. et All. Fundamentals of Software Engineering. New Jersey, Prentice-Hall International Editions, 1991

JACOBSON, I., CHRISTERSON, M., JONSSON, P. & ÖVERGAARD, G. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.

LARMAN, Craig. Utilizando UML e Padrões – Uma Introdução à Análise e ao Projeto Orientados a Objetos. Porto Alegre: Editora Bookman, 2000.

MARTIN, J. & ODELL, J. J. Análise e Projeto Orientados a Objeto. São Paulo: MakronBooks, 1995.

PAGE-JONES, M. O que Todo Programador Deveria Saber Sobre Projeto Orientado a Objeto. São Paulo:

MakronBooks, 1997.

PENKER, M. & ERIKSSON, H-E. UML Toolkit. John Wiley, 1997.

PRESSMAN, R. S. Engenharia de Software. São Paulo, MakronBooks, McGraw-Hill, 1995.

RUMBAUGH, J. et all. Object-Oriented Modeling and Design. Prentice-Hall, 1991.

SHLAER, S. & MELLOR, S. J. Análise de Sistemas Orientada para Objetos.

São Paulo: McGraw-Hill,

1990.

WINBLAD, A. L. et alii. Software Orientado a Objeto. São Paulo: Makron Books, 1993.

BECK,

Kent.

&

CUNNINGHAM,

W.

A

Laboratory

For

Teaching

Object-Oriented Thinking.

OOPSLA'89

Conference

Proceedings

October, Louisiana, 1989. http://c2.com/doc/oopsla89/paper.html

HEWLETT-PACKARD LABORATORIES

TEAM FUSION

- Software Development using UML. http//www.hpl.hp.com/fusion/me_method.html

-

 

Systematic

HEWLETT-PACKARD LABORATORIES - Fusion

http://www.hpl.hp.com/fusion/news/feb97.html

Newsletter-Fevereiro/1997.

OBJECT

MANAGEMENT

GROUP

-

Technology

Adoptions

-

UML

Documents.

http://www.omg.org/library/schedule/Technology_Adoptions.htm#tbl_UML_Specification

RATIONAL

SOFTWARE

CORPORATION

-

Technical

Papers.

http://www.rational.com/support/techpapers/

Análise e Projeto Orientados a Objetos

Apêndice A - Estudo de Caso MiniBib (Biblioteca Departamental)