anÁlise e projeto orientados a objetos - mÉtodo fusion expandido e adaptado À uml

Análise e Projeto Orientados a Objetos

Por Maurício F. Galimberti

1

ANÁLISE E PROJETO ORIENTADOS A OBJETOS:MÉTODO FUSION EXPANDIDO E ADAPTADO À UML


[email protected]

Departamento de Informática

Centro de Ciências Exatas e Tecno log ia

Universidade de Caxias do Sul

Equ ipe do Projeto FILM

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

Colaboradores:Prof. MSc. José Eduardo C. BussmannProf. MSc. Giovanni E. RoccoProf. MSc. Daniel L. Notari

Bolsistas:Fabrício Lazzari

ResumoO 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 expandecom uma fase inicial de coleta e especificação de requisitos, conduzindo-a como um processo linear. Asdemais fases de análise, projeto e implementação serão tratadas em um processo cíclico de evolução dodesenvolvimento de sistemas onde serão utilizadas as notações padrão UML (Unified ModelingLanguage) 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).



2

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 - Condução das Fases do Método de Especificação e Construção do Software................15

PARTE I - 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



3

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 - "Visibil idade" .....................................................................................................................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



4

1. Introdução à Análise e Projeto de Sistemas Orientados a ObjetosA 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 aosobjetos existentes no mundo físico, o que produz um modelo de programação muito diferente datradicional 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.

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 nosvalores 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;

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



5

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 demaneira bem definida.

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

Historicamente foram desenvolvidas metodologias para tratar o ciclo de desenvolvimento desoftware 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, aomesmo tempo, divergências e similaridades entre os diversos métodos.

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

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

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

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

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



6

software” [OMG, 2001].

Mais especificamente, a UML se concretiza como um conjunto de notações bem definidas eespecíficas para a construção dos diversos modelos necessários desde a definição de um sistema orientadoa 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, dentreeles os principais métodos são Booch, OMT e OOSE, concebidos, respectivamente, por três autores derenome internacional, sendo Grady Booch, James Rumbaugh e Ivar Jacobson (referenciadosmundialmente como "The Three Amigos"), que extraíram de suas metodologias anteriores aspectospositivos de cada uma delas. Além disso, suas experiências mostraram que é ineficiente uma metodologiaestanque 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á existentesou que por ventura venham a ser criadas.

A partir deste quadro mundial, foi criada uma comissão internacional que iniciou um processo depadronização da área de orientação a objetos, sendo atualmente a UML versão 1.3 (com proposta daversão 1.4 em avaliação) reconhecida com exclusividade por esta comissão, denominada ObjectManagement Group (OMG) [OMG, 2001], como padrão de notação de construção de modelos orientadosa objetos.

Este contexto, aliado ao fato de existir proposta semelhante, quando da adequação da UML aoprocesso Objectory de Engenharia de Software, através do trabalho "UML Extension for ObjectoryProcess 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 propostospelo método Fusion. Além disso, permite a expansão do método Fusion em relação à fase inicial dedefinição de requisitos, buscando-se enquadrar a notação da UML para a geração de modelos para estafase.

No entanto, a principal motivação para a criação deste trabalho vem da atual estrutura curricular doscursos do Dpto. de Informática desta Universidade e, consequentemente, da inserção de seus egressos nomercado de desenvolvimento de software. Sendo estes cursos formadores de profissionais com perfis deanalistas e projetistas de software, considera-se que os mesmos devem cada vez mais se enquadrar aocontexto mundial da tecnologia de orientação a objetos. Deve-se, portanto, considerar o processogradativo de mudança do paradigma estruturado pelo orientado a objetos, pelo qual passam as empresasdo setor de informática da região, o que as levará, certamente, à adoção de padrões estabelecidos para osegmento 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étodosistemático que deve abranger também as demais fases do processo de desenvolvimento de sistemascomputacionais 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 dousuário;

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



7

As vantagens em se ter um método sistemático para análise e projeto de sistemas (sistemasorientados 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 projetode 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 parao desenvolvimento de software orientado a objetos, mas que não são o foco deste trabalho. Contudo, serãoenfatizados, nas seções subsequentes, o método Fusion (seção 1.1.2) e o padrão UML (seção 1.1.3) por secaracterizarem 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çãodescreve características básicas, a grande maioria sob o ponto de vista de [Coleman, 1996], sobrepropostas pioneiras na orientação a objetos. Desejando-se conhecer melhor estes trabalhos, são citadassuas 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 relacionamentosatributos e operações que caracterizam cada classe

notação: diagrama E-R estendidoModelo Dinâmico:

captura o comportamento dinâmico de cada classe:máquina de estados: como objetos da classe respondem aos eventosevento representa um estímulo externoestado é 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 subsistemasaloca processos e defini a arquitetura geral

Projeto de Objetos:algoritmos dos métodosdetermina métodos das classesparticiona projeto em módulos para a programação



8

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

PRÓSAnálise possui um processo bem definidoModelos da análise com notações concisas e inteligíveisCONTRASRelacionamento entre modelos da análise não é claroModelos da análise dificultam percepção do cenário globalProjeto não possui abordagem passo a passoNã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-Resboços são produzidos no início do desenvolvimento e completados durante aidentificação dos relacionamentos

Diagramas de Objetos:objetos e “relacionamentos” (dinâmico): troca de mensagensesboços são produzidos no início do desenvolvimento e completados durante aidentificaçã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 sistemadiagrama 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 objetosCONTRASNotação complexaInformações se duplicam entre os vários modelosAusê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



9

Adota o termo agentes: usuários do sistemaUse Cases capturam funcionalidades do sistemaDemais modelos são construídos sobre use casesUse cases -- elos de ligação entre as fasesREQUISITOS: 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 operanotaçã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 telaenvolve o usuário no processo de desenvolvimento

ANÁLISE: refina os modelos dos requisitos.Modelo é uma forma de modelo E-RObjetos e classes requeridos em cada use caseSUBSISTEMAS:

grupos de objetos com comportamento similarcritérios para agrupamento:

forte acoplamento entre objetosflexibil idade 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 sistemaCada 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ÓSContribui com o conceito de use case: base do processoCONTRASModelos e notações: inadequados e insuficientesDifícil compreensão de alguns modelosDificuldade 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õesAções dos objetos transformadas em responsabil idades das classes: tarefas a seremexecutadas pela classe

ATRIBUIR RESPONSABILIDADES:Responsabilidades são alocadas às classesDistribuição das tarefas do sistema



10

IDENTIFICAR COLABORAÇÕES:Identificação das interações entre as classes: exame de cada par classe/responsabilidadebuscando suas dependências com outras classes

PRÓSComo técnica exploratória (não é um método) é bastante avançadaÚtil no projeto de estruturas de herançaMuito poderosa para o projeto das interações entre os objetosCONTRASCartões de referência: único registro para as decisões tomadasInadequadas para fins de manutençãoNão trata da criação/destruição de objetos

MÉTODOS FORMAISAbordagem de engenharia de software baseada na aplicação de matemática discreta à programaçãode 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”, natradução de uma fusão de abordagens e métodos. Deixaremos os detalhes do método Fusion para asubseção a seguir e, como bem será fundamentado, este método será visto ao longo de todo o nossotrabalho.

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



11

seção específica para tratá-la (seção 1.1.3). Neste momento vale lembrar apenas que a UML é umalinguagem 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 estefato, e a sua padronização, os avais para sua utilização em nosso trabalho, o que também poderá ser feitoem empresas de desenvolvimento que adotem métodos e processos proprietários/particulares paraconstruçã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çãode software orientado a objetos. Este método estabelece uma rota direta entre a definição dos requisitos e aimplementaçã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 ecompleto de notações bem-definidas.

A construção do software a partir do método Fusion considera um processo dividido em fases. OFusion estabelece o que deve ser feito em cada fase, orientando a sequência de ações de cada fase e oscrité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 requisitossejam fornecidos por usuários e documentados seguindo-se alguma técnica de elicitação e deespecificaçã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 comportamentodos 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:



12

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 aobjetos.

DICIONÁRIOS DE DADOS: são adotados durante todo o processo de desenvolvimento eidentificam as entidades existentes no sistema.

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

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 JimRumbaugh, da Rational Software Corporation, começaram seus trabalhos de unificar os métodos Booch e



13

OMT. Em 1995 juntou-se com aqueles Ivar Jacobson e sua companhia uniu-se à Rational e seu métodoOOSE 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 duaspáginas. Procurar uma figura representativa.

1.2 - Método Fusion Expand ido e Adaptado à UML

A proposta deste trabalho é resultado do projeto FILM, o qual está institucionalizado naUniversidade de Caxias do Sul pelo Departamento de Informática e tem como objetivo adaptar e expandiro método Fusion de análise e projeto de sistemas orientado a objetos. Este ajuste do método tambémexpande o espectro do método Fusion, acrescentando ao mesmo a abordagem da fase inicial deespecificaçã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 UnifiedModeling Language (UML). A UML propõe flexibil idade aos diversos processos de desenvolvimento desoftware, expandindo métodos orientados a objetos e disponibil izando um conjunto de notações para aconstruçã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 deEstruturaçã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çõestextuais 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 foiconstruída a partir das notações de use case da UML. Esta figura objetiva visualizar a estrutura geralproposta através dos processos e de suas fases. A partir da seção 1.2.1 será oferecida uma visão maisespecífica sobre as informações a serem documentadas em cada fase através de seus modelos.



14

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



15

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 fasespropostas 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ãosendo elicitadas conforme a figura 1.6 abaixo. Os principais documentos serão o Documento Contextualdo Sistema, Modelo de Objetivos, Visão de Use Case e Cenários e Ciclo de Vida do Sistema. OPlanejamento do restante do processo cíclico de desenvolvimento do sistema marca o encerramento destafase de Especificação de Requisitos.

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



16

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õeum conjunto de modelos a serem desenvolvidos conforme a figura 1.7. Considerando os ciclos planejadosna fase anterior, todos os modelos deverão ser construídos para cada ciclo. Portanto, as principaisinformaçõ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 emquestão sejam refinados antes de se iniciar o processo de modelagem dos objetos e operações.

Figura 1.7 - Fase de Análise



17

Fase de Projeto

A fase de Projeto caracteriza-se pela modelagem dinâmica do sistema principalmente em termos dasmensagens e dos objetos necessários às operações especificadas na fase de Análise. Portanto, conforme afigura 1.8, as principais informações serão modeladas através dos Grafos de Interação de Objetos. Isto iráviabil izar, 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.

Figura 1.8 - Fase de Projeto



18

Fase de Implementação

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

Figura 1.9 - Fase de Implementação



19

PARTE I - PROCESSO LINEAR

Figura Parte I – Processo Linear



20

2. Fase de Estruturação e Especificação de RequisitosA 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 osobjetivos que serão buscados quando da preparação da solução do problema. Futuramente, após asdefinições dos ciclos que se iniciam na fase de Análise, todos os requisitos voltarão a ser melhordocumentados a partir de outras ferramentas de modelagem.

Para facil itar o trabalho de documentação de requisitos, este capítulo orienta o estudante a buscarum 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 osModelos de Objetivos e a Visão de Use Cases para expressar os principais processos identificados nodomínio do problema em estudo. Logo após a construção dos use cases será descrita uma maneira de sedocumentar 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 oplanejamento 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 deTermos, necessário durante todo o tempo em que será construído o sistema e que, por se constituir emalgo bastante simples, não mereceu um capítulo específico para seu estudo.



21

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ãomacro do sistema. A partir deste documento já se pode ter uma idéia do sistema e seu enquadramento noambiente ao qual vai servir, podendo-se prever a viabil idade 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 asnecessidades que ele pretende atender e o resultado esperado após sua implementação.

Prob lema Original

É uma exposição da situação atual do ambiente onde o sistema irá atuar, descrevendo todas asdificuldades existentes e que devem ser solucionadas, ou pelo menos simplificadas, pelo sistema que seestá propondo.

Origem do sistema



22

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 sobreum sistema já existente, deve-se analisar o quanto do mesmo poderá ser aproveitado e qual será o volumede alterações que necessitam ser realizadas sobre ele para que o mesmo possa suprir as necessidades dosclientes. Também no caso da atualização, deve-se analisar a relação custo-benefício para que não sejamais oneroso efetuar as alterações sobre o sistema existente do que desenvolver um sistema novo, jávoltado para as atuais necessidades.

Contexto de utili zação

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

Limites do sistema

Esta cláusula definirá as responsabil idades do sistema dentro dos objetivos. Devem ser definidosquais objetivos serão atendidos pelo sistema e quais deles ficarão sob responsabil idade dos usuários ou deoutros 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çãodas informações. A estrutura das informações prevê a definição do objetivo e a descrição dos objetos queo compõem. São sugeridas questões que tem o propósito de descobrir, ante ao objetivo, os objetosresultado, sujeitos, objetos e ferramentas, conforme as figuras 2.2 e 2.3.

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



23

“ Esquema” de Descrição de Objetivo

Objetivo Elicitadas as informações, pode-se definir um objetivo para o sistema emquestão. Descrição do objetivo, que em geral responde a umquestionamento 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 oobjeto?

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 cadaobjetivo. Neste momento apenas os requisitos de nível mais alto são abordados, pois para contemplar umrequisito outros requisitos podem ser necessários. Essa estrutura é dada pela associação entre objetivo erequisitos 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 deabstração, nos quais os requisitos são associados por qualificadores E, que indica requisitoscomplementares, e por qualificadores OU, que indica requisitos opcionais para o atendimento à atividadeou à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 oestabelecimento dos ciclos prioritários para o desenvolvimento.

Figura 2.4 – Estrutura dos Objetivos [Rocco, 2001]



24

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 estesrequisitos são somente os de nível 0.

“ Esquema” de Descrição de Requisito

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

Ação

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

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

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

Recurso Objeto que corresponde à interface entre o agente e o software, ou a informaçãoque o agente envia para os objetos do domínio do software para que possamexecutar 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 estruturagráfica abrangendo o sistema a partir de seus principais processos e agentes. Portanto, a construção doDiagrama de Use Cases apresenta os atores envolvidos no sistema que está sendo elicitado e com quaisprocessos 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 quesejam derivados diretamente dos objetivos quando estes possuírem requisitos de nível 0 simples ou empequena quantidade, o que pode ser mais conveniente para a geração do modelo de Use Cases.



25

Estratégias para Modelagem

A orientação para modelagem dos Use Cases sugere que sejam derivados dos Objetivosidentificados anteriormente. Todavia, não sendo usada a abordagem por objetivos, pode-se partir daespecificação de requisitos listando-se possíveis Use Cases e, a partir disso, montar o diagramaassociando-os aos seus respectivos atores.

Notações para Modelagem

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 temcomo 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 emExpressões Ciclo de Vida.


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


A modelagem do ciclo de vida só pode ser feita dominando-se a sequência e repetições deocorrência dos Use Cases, caso isto ocorra. Portanto, observando-se os objetivos e requisitos, e os UseCases derivados, deve-se ter clareza do sequenciamento dos Use Cases para se estabelecer uma sentençade Ciclo de Vida do sistema conforme ocorrência destes Use Cases.


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



26

gramatical para sua representação. Inicialmente serão utilizadas as notações Fusion até que sejammapeadas 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 utili zado 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



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

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


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

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



27

necessária a sua conclusão para que possa ser encaminhado o início de um novo ciclo. Isto não inviabilizaa construção incremental de ciclos, pois também se tem como objetivo o escalonamento dodesenvolvimento através de versões diferentes de construção dos use cases ou objetivos do sistema.

Estudo de Caso



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 dedados também no método Fusion, será referenciado como glossário de termos pelo seu caráter de registrarnão apenas dados, mas também quaisquer informações e restrições que não possam ser colocadas nosdiagramas 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 serencontradas. Manter o glossário de termos é uma atividade contínua durante todo processo de construçãodo sistema e por menor que seja a descrição de um item, ainda assim é a melhor forma de deixar claro oseu significado.

O método Fusion orienta para a construção de um glossário, porém não obriga a uma sintaxe enotações específicas. Portanto, neste trabalho, é sugerida uma forma básica para documentação dos itensatravés de tabelas. As coleções de itens de mesma categoria podem ser documentadas em tabelasespecíficas, otimizando a localização dos termos.


Considerando que a manutenção do glossário de termos seja uma atividade constante durante todo oprocesso de construção do sistema, orienta-se para que o mesmo seja atualizado ou durante a construçãodos diagramas ou logo após o encerramento dos mesmos. Segue abaixo uma sugestão de como estruturaras informações dentro do glossário de termos.


A documentação do glossário, em geral, será possível através de uma tabela de três colunas comoabaixo. No entanto, conforme o momento do processo de construção do sistema, outras colunas poderãoser acrescentadas para melhor descrever determinados termos.

Nome do Termo Categoria Descrição

Identificação do termomodelado

Designação do tipo do termo emrelação ao seu propósito demodelagem

Texto descritivo

Figura 2.8 – Glossário de Termos



28

PARTE II - PROCESSO CÍCLICO

Figura Parte I I - Processo Cíclico



29

3. Fase de AnáliseA 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 osrelacionamentos entre elas e definir as operações que poderão ser executadas pelo sistema. A fase deAná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 deaspectos diferentes, sendo o Modelo de Objetos e o Modelo de Interfaces, este último sendo compostopelos Cenários e seus Modelos de Ciclo de Vida e pelo Modelo de Operações. Assim, esta fase doprocesso é responsável pelas seguintes descrições: classes de objetos (sem associar quaisquer métodos àsclasses); relacionamentos entre classes; operações do sistema; sequência permissível de operações. Noentanto, a proposta de um processo cíclico exige que os requisitos a serem tratados sejam melhordetalhados. 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 deAná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 fasede definição de requisitos em modelos que representem as estruturas estáticas do sistema e ocomportamento do mesmo. No entanto, a partir da fase de Análise o sistema será modelado através de umprocesso cíclico. Este processo foi estabelecido de forma a viabil izar a construção incremental do sistema.



30

Assim sendo, o primeiro passo da fase de Análise será estruturar o ciclo em questão, o que deve serfeito com o aprimoramento dos requisitos documentados na fase anterior, caraterizando em umrefinamento dos requisitos a partir dos objetivos antes brevemente descritos. Inicialmente, anterior aosdetalhes dos requisitos, deve ser modelado o comportamento do sistema de forma a identificar quais sãoas 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 qualseve ser visto como uma caixa preta.

Modelagem Fusion:

Cenários do Sistema por Objetivo: utilizar notações padrão UML para Diagrama deSequências;

Modelagem de Refinamento de Requisitos:

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

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

Modelagem Fusion:

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

As próximas informações a serem modeladas caracterizam-se por representar a estruturacomportamental do sistema. O comportamento do sistema deve ser documentado de forma a identificarquais são as interações existentes entre o sistema e o meio em que está inserido. Isto já deve ter sido feitonos cenários através da representação de eventos de entrada e de saída entre o sistema, no entanto agoradeve ser modelada a sequência permissível para ocorrência destes eventos dentro do ciclo de vida dosistema. Portanto, neste momento da fase de Análise deve-se modelar os eventos de entrada comooperações do sistema. Assim, as operações serão documentadas de forma a identificar quais estruturas deobjetos deverão ser manipuladas para realizar cada operação e suas responsabilidades. As operaçõesmodelam os eventos de entrada e seus efeitos no sistema, os quais podem ser as alterações no estado dosistema 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 doSistema, onde serão mantidas as estruturas de classes e associações necessárias às operações do sistemajuntamente 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: utili zar notações padrão UML do Diagrama de Classes



31

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 é partirdos requisitos documentados, na fase anterior, no formato de objetivos e aprimorar os conhecimentossobre 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 porObjetivo.

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 ocomportamento 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çãode 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 utili zada para a modelagem dos Cenários, o qualadota o padrão UML para Diagrama de Sequências.


A construção dos cenários deve partir da especificação de requisitos, mais especificamente a partirdo Modelo de Objetivos e dos Use Cases. Seu desenvolvimento também depende do Modelo deRequisitos por Objetivo, sugerindo que sejam construídos em paralelo.


A principal orientação para montagem dos Cenários está na identificação dos atores e suas ações, oque pode ser feito observando-se as cláusulas dos “Esquemas” de Descrição de Requisitos do objetivo emquestão. As principais cláusulas são “Ação”, “Agente” e “Recurso” .



32


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

Estudo de Caso



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 serutilizada é exatamente a mesma vista na seção 2.2 de Modelo de Objetivos, porém agora os requisitosdeverã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áusulascomentadas na seção 2.2.1, na figura 2.6.


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


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


Ver seção 2.2.1, figura 2.6.

Estudo de Caso




33


3.3 - Modelo de Objetos (Modelo Conceitual)

A abordagem do modelo de objetos visa representar as classes de objetos através de conceitosidentificados nas informações até então documentadas. Estes conceitos serão modelados como classes deobjetos que se relacionam entre si através de associações e restrições de cardinalidades. São identificadostambé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 eespecializações para um momento mais propício da fase de Projeto.

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


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 dedesenvolvimento, vale lembrar em observar os modelos de objetos já construídos, pois pode-se reutilizarclasses de objetos já modeladas.


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

O procedimento básico, contudo, é partir das especificações de requisitos correspondentes ao cicloem 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 derequisitos, os quais serão candidatos a classes. A partir daí deve-se buscar sua identificação nas tabelas decategorias de [Larman, 2000] buscando qualificar o conceito como classe de objeto ou como atributo. Alista de substantivos gerada também facil ita a eliminação de redundâncias (conceitos de objetossemelhantes ou repetidos).

Busque não modelar chaves (primárias, estrangeiras, ...) como em bancos de dados. Isto deverá serfeito no momento de mapear as classes de objetos para uma estrutura de dados persistentes.



34


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

Estudo de Caso



3.4 - Modelo de Interfaces

O comportamento do sistema deve ser documentado de forma a identificar quais são as interaçõesexistentes entre o sistema e o meio em que está inserido. Isto já deve ter sido feito através darepresentação de eventos de entrada e de saída entre o sistema, através dos Cenários anteriores, mas agoradeve ser modelada a sequência permissível para ocorrência destes eventos dentro do ciclo de vida dosistema. 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 estardisponíveis para realizar cada operação e suas responsabil idades. As operações modelam os eventos deentrada e seus efeitos no sistema, os quais podem ser as alterações no estado do sistema e os eventos



35

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 asequê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.


A construção das expressões ciclo de vida são baseadas nos Cenários e fundamentadas nosrequisitos especificados nos use cases e objetivos em questão no ciclo.


A modelagem do ciclo de vida só pode ser feita dominando-se a sequência e repetições deocorrência dos eventos previamente modelados. Portanto, deve-se ter clareza do funcionamento do usecase em questão e dos requisitos para se alcançar o objetivo que está sendo abordado. Lembra-se que foiespecificado, ainda na fase de Definição de Requisitos, um Modelo Ciclo de Vida baseado em use cases, oque facilita o refinamento de suas expressões/subexpressões.


A modelagem do ciclo de vida é feita de forma declarativa, necessitando-se de um conjuntogramatical para sua representação. Inicialmente serão utilizadas as notações Fusion até que sejammapeadas para UML. O conjunto notacional está especificado abaixo, sendo o mesmo descrito na seção2.4.

-Alfabeto:qualquer evento de entrada ou saída pode ser utili zado 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




36


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 investigaras estruturas internas do sistema em construção. As operações serão modeladas através de fichas com umconjunto de cláusulas. Cada cláusula tem seu propósito de transformar os requisitos do objetivo emreferências às estruturas até então modeladas como objetos. Portanto, cada evento de entrada setransformará em uma operação, merecendo uma ficha/esquema de modelagem, a partir da qual serãodocumentadas 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.


A construção do Modelo de Operações depende praticamente de todas informações documentadasaté então para o ciclo em questão. A base da modelagem das operações, contudo, é formada pelo Modelode Objetos, Cenários e Ciclo de Vida além, é claro, das especificações de requisitos através do Modelo deRequisitos por Objetivo.


A estratégia para modelagem das operações deve iniciar observando-se os Cenários e as expressõesCiclo 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.



37


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

“ Esquema” de Operação

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

Responsabili dades Texto descriti vo sobre as características principais da operação, principalmente no que serefere às responsabili dades da mesma;

Referências Reads Itens.

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

ReferênciasChanges

Itens.

Análogo à cláusula anterior, nesta devem ser relacionados quais itens objeto necessita-semanipular (com acesso de gravação/escrita) para executar a operação. Possível uso dapalavra-reservada new (novo) precedendo um Item-objeto, o que indica que esta operaçãoirá 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 osdestinatários dos mesmos. Portanto, é uma li sta com todos os agentes e os eventos que aoperação deve lhes enviar. Cada Agente_E_Evento engloba o nome de um agente e todosos 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 aoperação possa ser executada. Todas/cada cláusula deve ser True para que o predicado sejasatisfeito (E lógico). Referencia apenas parâmetros ou partes do estado que tenham sidodefinidos em Reads e Changes;

Pós-condições Condição.

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

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

Estudo de Caso



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 osrelacionamentos podem especificar conceitos pertencentes ao ambiente do sistema, bem como os inerentesao próprio sistema.

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



38

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].


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


Observando-se os Cenários e os Modelos de Operações, deve-se filtrar os Modelos de Objetos deforma a manter apenas objetos necessários à própria estrutura interna do sistema. O método Fusionorientava para que fosse criada uma espécie de fronteira, através de uma linha pontilhada, delimitando osobjetos do sistema e os agentes. No entanto, com a UML poderemos utili zar a notação paraagentes/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.


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

Estudo de Caso



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 paraa verificação dos modelos de análise no que se refere à inteireza e à consistência em relação aosrequisitos.

Inteireza com requisitos: releia com cuidado o documento de requisitos e resolva quaisquer dúvidascom 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 nomodelo de objetos do sistema. Todos os outros conceitos devem estar definidos no glossário de



39

termos ou em alguma outra fonte de referência;

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

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

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



40

4. Fase de ProjetoA 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. Asinformações da fase de Projeto caracterizam a modelagem dinâmica do sistema, principalmente em termosdos objetos necessários às operações através da troca de mensagens entre os mesmos. Ao final da fase deProjeto busca-se ter uma estrutura hierárquica de classes e o refinamento do Modelo de Objetos doSistema da fase de Análise, o que irá caracterizar os requisitos essenciais à passagem para a fase deImplementação.

Os objetivos da fase de Projeto passam pela construção inicial dos Grafos de Interação de Objetos, a partirdo 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 viabil izar a estruturahierá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 afase 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 emestruturas arquiteturais de projeto com o objetivo de viabil izar a implementação do sistema. Asinformações da fase de Projeto caracterizam a modelagem dinâmica do sistema principalmente em termosdos objetos necessários às operações através da troca de mensagens entre os mesmos.



41

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

Modelagem Fusion:

• Grafos de Interação de Objetos: utilizar notações padrão UML do Diagrama deColaboração;

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

Modelagem Fusion:

• Refinamento do Modelo de Objetos do Sistema: utili zar notações padrão UML doDiagrama de Classes;

• Grafos de Herança: utilizar notações padrão UML para estrutura de Herança do Diagramade Classes;

4.2 - Grafos de Interação de Objetos

A abordagem dos Grafos de Interação de Objetos visa representar a troca de mensagens entre osobjetos para satisfazer as operações modeladas na fase de Análise. Deve ser desenvolvido um Grafo deInteração de Objetos para cada operação modelada no sistema.

Abaixo segue um esquema com a notação a ser utili zada para a modelagem destes grafos, o qualadota o padrão UML para Diagramas de Colaboração.


A modelagem das trocas de mensagens entre os objetos depende diretamente da observação dosModelos de Operações, do Modelo de Objetos do Sistema e do Modelo Ciclo de Vida em um segundoplano. A principal colaboração dos GIO serão os métodos que os objetos passarão a ter após suamodelagem o que fornece a estrutura dinâmica do sistema em projeto.


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. Apartir daí, deve ser gerado um GIO para cada Modelo de Operação. Assim sendo, cada cláusula doModelo de Operações deverá ser observada buscando as informações necessárias para a modelagem dosGIO, conforme descrito abaixo.



42


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

Estudo de Caso



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 aodomínio do sistema, deve agora ser refinado de forma a melhorar o significado e a visualização de suasestruturas.

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

4.3.1 Agregações

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


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 reconhecercaracterísticas de agregação.


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



43

agregarem. Em geral a agregação modela relacionamentos "parte de" ou "contém um". Portanto, umaclasse 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 deobjetos, identificar nos relacionamentos verbos ou expressões verbais como: tem um, contém um, está em,é parte de, ...


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

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

Estudo d e Caso



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 aspropriedades da classe herdada (superclasse/supertipo), podendo também possuir outras mais, o que noslevará a construir uma Estrutura Hierárquica de Classes, objetivando-se assim a reutilização de classes emoutros projetos.


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



44


A orientação para se identificar generalizações/especializações (herança) é semalhante à usada paraidentificar agregações e diz respeito à análise da expressão (geralmente contendo um verbo) existente norelacionamento 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).


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

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

Estudo d e Caso



4.4 - "Visibil idade"

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 nosgrafos de interação de objetos sejam consideradas como parte do modelo de objetos do sistema paraposterior implementação. Novas classes poderão ser introduzidas durante a fase de projeto sem que sejammostradas no modelo de objetos do sistema desenvolvido durante a análise.



45

Verificação do efeito funcional:

• Verificar se o efeito funcional de cada grafo de interação de objetos satisfaz à especificação da suaoperaçã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:

• Verificar se as associações originais do modelo de objetos do sistema foram devidamenteconvertidas, quando possível, em estruturas de agregação e generalização para otimização dorespectivo modelo.



46

5. Fase de ImplementaçãoA 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 dosmétodos inerentes a cada classe de objeto e o Refinamento do Modelo de Objetos do Sistema permitiu amelhora estrutural dos mesmos, o objetivo agora será escrever o código-fonte relativo às estruturas dosobjetos em termos de seus atributos e métodos.

A proposta deste trabalho é a flexibilidade, orientando apenas para que seja gerado código com asintaxe de uma linguagem de programação orientada a objetos. Os exemplos serão construídos em C++ ouem 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 afase de Projeto.

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



47

durante a fase de Projeto juntamente com as especificações contidas no Glossário de Termos. Lembra-seque serão montados protótipos estruturais das classes de objetos projetadas, os quais estarão formadospelo 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 umalinguagem de programação orientada a objetos.

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

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


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


Para que sejam identificadas quais classes serão implementadas, deve-se observar quais delas sãonecessárias às operações do sistema. Portanto, os Grafos de Interação de Objetos fornecem a informaçãosobre quais classes implementar. Considerando, contudo, que houve o refinamento do Modelo de Objetosdo Sistema após a construção dos GIO, provavelmente a tarefa de selecionar as classes a seremimplementadas já pode ter sido feita, isto é, através da “exclusão” , do MOS, das classes desnecessárias àsoperaçõ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 deTermos e os métodos nos Grafos de Interação de Objetos, caso ainda não tenham sido atualizados noModelo 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 Sistemaapareçam nas estruturas de classes;

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

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

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



48

6. ConclusõesA 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 objetivosestã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écnicasdesenvolvidos pelo Fusion, já se conseguiu adaptar totalmente cinco deles. Cita-se o mapeamentocompleto do Modelo de Objetos, o Modelo de Interfaces, enquanto tratamento dos Cenários e dos Modelode 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 deVida. Por fim, cita-se também o estudo do Diagrama de Componentes da UML para adaptação à fase deImplementação do Fusion, podendo vir a auxiliar o gerenciamento dos processos de codificação dosistema de software.

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



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 Distill ed - Applying the Standard Object Modeling Language.Massachusetts: Addison-Wesley, 1997.

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

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

LARMAN, Craig. Utilizando UML e Padrões – Uma Introdução à Análise e ao Projeto Orientados aObjetos. 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 TeachingObject-Oriented Thinking. OOPSLA'89 Conference ProceedingsOctober, Louisiana, 1989. http://c2.com/doc/oopsla89/paper.html

HEWLETT-PACKARD LABORATORIES - TEAM FUSION - Systematic Software Development using UML. http//www.hpl.hp.com/fusion/me_method.html

HEWLETT-PACKARD LABORATORIES - Fusion Newsletter-Fevereiro/1997.http://www.hpl.hp.com/fusion/news/feb97.html

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/...



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