análise e projeto orientados a objetos

Anlise e Projeto Orientados a Objetos

Por Maurcio F. Galimberti1

ANLISE E PROJETO ORIENTADOS A OBJETOS:MTODO FUSION EXPANDIDO E ADAPTADO UML

Por Maurcio F. [email protected]

Departamento de InformticaCentro de Cincias Exatas e Tecnologia

Universidade de Caxias do Sul

Equipe do Projeto FILMCoordenador:

Prof. MSc. Maurcio F. GalimbertiColaboradores:

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

Bolsistas:Fabrcio Lazzari

ResumoO presente trabalho prope abordar a anlise e projeto orientados a objetos a partir de um mtodo

sistemtico e didtico, utilizando para construo de seus modelos um conjunto padronizado de notaes.Ser adotado o mtodo Fusion de anlise e projeto de sistemas orientados a objetos, o qual se expandecom uma fase inicial de coleta e especificao de requisitos, conduzindo-a como um processo linear. Asdemais fases de anlise, projeto e implementao sero tratadas em um processo cclico de evoluo dodesenvolvimento de sistemas onde sero utilizadas as notaes padro UML (Unified ModelingLanguage) para modelagem dos artefatos do sofware.

Palavras-chave: anlise e projeto orientados a objetos; mtodo orientado a objetos; mtodo Fusion;Unified Modeling Language (UML).



1. Introduo Anlise e Projeto de Sistemas Orientados a Objetos ................................................ 41.1 - Anlise e Projeto Orientados a Objetos................................................................................ 6

1.1.1 - Mtodos de Anlise e Projeto Orientados a Objetos ...................................................... 71.1.2 - Mtodo Fusion de Anlise e Projeto Orientado a Objetos.............................................111.1.3 - Padres de Modelagem de Objetos usando UML - Unified Modeling Language...........12

1.2 - Mtodo Fusion Expandido e Adaptado UML ...................................................................131.2.1 - Conduo das Fases do Mtodo de Especificao e Construo do Software................15

PARTE I - PROCESSO LINEAR...................................................................................................192.Fase de Estruturao e Especificao de Requisitos .....................................................................20

2.1 - Documento Contextual do Sistema .....................................................................................212.2 - Modelo de Objetivos ..........................................................................................................22

2.2.1 Estrutura dos Objetivos ..................................................................................................232.3 - Viso de Use Cases.............................................................................................................242.4 - Cenrios e Ciclo de Vida do Sistema ..................................................................................252.5 - Planejamento dos Ciclos de Construo do Sistema............................................................262.6 - Manuteno de um Glossrio de Termos ............................................................................27

PARTE II - PROCESSO CCLICO ................................................................................................283. Fase de Anlise...........................................................................................................................29

3.1 - Conduo da Fase de Anlise .............................................................................................293.2 - Refinamento dos Requisitos por Ciclo ................................................................................31

3.2.1 Cenrios do Sistema por Objetivo ..................................................................................313.2.2 Modelo de Requisitos por Objetivo ................................................................................32

3.3 - Modelo de Objetos (Modelo Conceitual) ............................................................................333.4 - Modelo de Interfaces ..........................................................................................................34

3.4.1 Cenrios e Modelo Ciclo de Vida...................................................................................353.4.2 Modelo de Operaes.....................................................................................................36

3.5 - Modelo de Objetos do Sistema (Modelo Conceitual) ..........................................................373.6 - Verificao dos Modelos da Fase de Anlise ......................................................................38

4. Fase de Projeto ...........................................................................................................................404.1 - Conduo da Fase de Projeto ..............................................................................................404.2 - Grafos de Interao de Objetos ...........................................................................................41



4.3 - Refinamento do Modelo de Objetos do Sistema..................................................................424.3.1 Agregaes ....................................................................................................................424.3.2 Herana - Estrutura Hierrquica de Classes ....................................................................43

4.4 - "Visibilidade" .....................................................................................................................444.5 - Verificao dos Modelos da Fase de Projeto .......................................................................44

5. Fase de Implementao...............................................................................................................465.1 - Conduo da Fase de Implementao .................................................................................465.2 - Gerao dos Prottipos e Estruturas de Classes de Objetos .................................................475.3 - Verificao das Estruturas de Classes de Objetos................................................................47

6. Concluses .................................................................................................................................48Bibliografia ....................................................................................................................................49Apndice A - Estudo de Caso MiniBib (Biblioteca Departamental) ................................................50


Por Maurcio F. Galimberti

4

1. Introduo Anlise e Projeto de Sistemas Orientados a ObjetosA orientao a objetos surgiu como uma abordagem de programao que procura explorar o nosso

lado intuitivo. Os "tomos" da computao orientada a objetos (os prprios objetos), so anlogos aosobjetos existentes no mundo fsico, o que produz um modelo de programao muito diferente datradicional viso "funcional" e "procedimental" [Coleman, 1996].

Modelo computacional orientado a funes:Os "tomos" da computao so as funes;Funes atuam sobre um nico estado compartilhado;Qualquer funo pode atuar sobre qualquer parte do estado.

Figura 1.1 - Modelo Computacional Orientado a Funes [Coleman, 1996]Neste modelo a estrutura no se altera com o passar do tempo, apesar de ocorrerem alteraes nos

valores armazenados na mesma: modelo computacional esttico.Modelo computacional orientado a objetos:A nica maneira de se obter ou alterar o estado de um objeto pelo envio de mensagens;Cada objeto responsvel pela resposta a uma determinada mensagem;Os objetos, quando compartilham uma nica interface, so agrupados em classes;

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

Durante a execuo do sistema os objetos podem ser construdos, executar aes, serem destrudos



5

ou se tornarem inacessveis: modelo computacional dinmico.Assim sendo, os tomos do processo de computao so os objetos:Objetos trocam mensagens entre si;As mensagens resultam na ativao de mtodos;O emissor da mensagem no 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, alm do processo de programao, abranger

tambm as demais fases do processo de desenvolvimento de sistemas computacionais em especfico.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 evoluo de "novas"tecnologias, este tema ainda proporciona novas propostas de abordagem para o assunto, gerando, aomesmo tempo, divergncias e similaridades entre os diversos mtodos.

Tendo como base este contexto, foram desenvolvidas as primeiras metodologias e tambmabordagens parciais para tratar o assunto, como linguagens de especificao e mtodos de projeto, porexemplo.

Considerando-se como abordagens (mtodos, tcnicas, linguagens de especificao) 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-Responsability-Collaboration)", tcnica exploratria que orienta odesenvolvimento atravs do registro das classes em cartes de referncia. Estas abordagens sero melhorcomentadas na seo 1.1.1, sem contudo aprofundarmo-nos nas mesmas por no ser este nosso objetivocom o presente trabalho.

Devido a esta miscelnea de mtodos, surgiram duas boas abordagens com propostas de fuso deconceitos, sendo elas: Fusion [Coleman, 1996] e UML (Unified Modeling Language) [OMG, 2001]. Estasse caracterizam como a base de nossas atividades e sero devidamente apresentadas com o transcorrerdeste programa.

Atualmente sendo adotada como base para a prtica da orientao a objetos nas disciplinas deAnlise e Projeto de Sistemas I e II, seguindo os currculos dos cursos de Bacharelado em Cincia daComputao e Tecnologia em Processamento de Dados da Universidade de Caxias do Sul, o mtodoFusion se apresenta bastante sistemtico e didtico para o processo de desenvolvimento de softwareorientado a objetos, estabelecendo uma rota direta entre a definio dos requisitos e a implementao dosistema. No entanto, os modelos por ele criados tornam-se s vezes bastante confusos devido asimilaridade de notao entre os mesmos. Alm disso, o mtodo no prope abordagem para a definiode requisitos, que uma das fases iniciais do processo de produo de software, que precede as atividadesde desenvolvimento.

J em relao UML, padro estabelecido pela OMG (Object Management Group) esta umalinguagem grfica para visualizar, especificar, construir e documentar os artefatos de um sistema desoftware. A UML oferece uma forma padro para se escrever/modelar projetos de sistemas, incluindoconceitos, tais como processos de negcios e funes de sistema, bem como coisas concretas comosentenas de linguagem de programao, projetos de bancos de dados e componentes reutilizveis de



6

software [OMG, 2001].Mais especificamente, a UML se concretiza como um conjunto de notaes bem definidas e

especficas para a construo dos diversos modelos necessrios desde a definio de um sistema orientadoa objetos at a sua implementao.

A UML a unificao e evoluo das propostas de vrios mtodos de orientao a objetos, dentreeles os principais mtodos so Booch, OMT e OOSE, concebidos, respectivamente, por trs autores derenome internacional, sendo Grady Booch, James Rumbaugh e Ivar Jacobson (referenciadosmundialmente como "The Three Amigos"), que extraram de suas metodologias anteriores aspectospositivos de cada uma delas. Alm disso, suas experincias mostraram que ineficiente uma metodologiaestanque e que no se adeque a outros processos de desenvolvimento de software, o que os motivou criao da UML como uma linguagem flexvel, que possa se adaptar a outras metodologias j existentesou que por ventura venham a ser criadas.

A partir deste quadro mundial, foi criada uma comisso internacional que iniciou um processo depadronizao da rea de orientao a objetos, sendo atualmente a UML verso 1.3 (com proposta daverso 1.4 em avaliao) reconhecida com exclusividade por esta comisso, denominada ObjectManagement Group (OMG) [OMG, 2001], como padro de notao de construo de modelos orientadosa objetos.

Este contexto, aliado ao fato de existir proposta semelhante, quando da adequao da UML aoprocesso Objectory de Engenharia de Software, atravs 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, eficincia e padronizao construo dos modelos propostospelo mtodo Fusion. Alm disso, permite a expanso do mtodo Fusion em relao fase inicial dedefinio de requisitos, buscando-se enquadrar a notao da UML para a gerao de modelos para estafase.

No entanto, a principal motivao para a criao deste trabalho vem da atual estrutura curricular doscursos do Dpto. de Informtica desta Universidade e, consequentemente, da insero 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 orientao a objetos. Deve-se, portanto, considerar o processogradativo de mudana do paradigma estruturado pelo orientado a objetos, pelo qual passam as empresasdo setor de informtica da regio, o que as levar, certamente, adoo de padres estabelecidos para osegmento de produo de software.

1.1 - Anlise e Projeto Orientados a ObjetosEsta seo apresenta a importncia de se ter, alm do processo de programao, um mtodo

sistemtico que deve abranger tambm as demais fases do processo de desenvolvimento de sistemascomputacionais em especfico.

Como principais caractersticas em se ter um mtodo, cita-se:Oferecer sistemtica para as fases de definio de requisitos, anlise, projeto e implementao;Evitar codificao precoce: programas de difcil manuteno e que no satisfazem os requisitos dousurio;Mtodos sistemticos consomem mais tempo nas fases iniciais do desenvolvimento de software.



7

As vantagens em se ter um mtodo sistemtico para anlise e projeto de sistemas (sistemasorientados a objetos, no nosso caso) nem sempre so apreciadas. Entre elas temos [Coleman, 1996]:

Verificao de requisitos;Conceitos mais claros;Maior adequao do projeto ao problema;Melhor decomposio do projeto para trabalho em equipe;Melhor comunicao da equipe de desenvolvimento;Menor esforo de manuteno;No restante desta seo sero apresentadas as principais abordagens existentes para anlise e projeto

de sistemas orientados a objetos. Na subseo 1.1.1 sero brevemente abordadas, conforme [Coleman,1996], algumas das propostas pioneiras da orientao a objetos, as quais ainda contribuem em muito parao desenvolvimento de software orientado a objetos, mas que no so o foco deste trabalho. Contudo, seroenfatizados, nas sees subsequentes, o mtodo Fusion (seo 1.1.2) e o padro UML (seo 1.1.3) por secaracterizarem como a base de nosso projeto.

1.1.1 - Mtodos de Anlise e Projeto Orientados a ObjetosSem ter o objetivo de aprofundar os conhecimentos em quaisquer trabalhos abaixo, esta seo

descreve caractersticas bsicas, a grande maioria sob o ponto de vista de [Coleman, 1996], sobrepropostas pioneiras na orientao a objetos. Desejando-se conhecer melhor estes trabalhos, so citadassuas principais referncias bibliogrficas.

OMT (OBJECT MODELING TECHNIQUE) [Rumbaugh, 1991]ANLISE: modelagem do mundo real.

Modelo de Objetos:captura estrutura esttica de um sistema:

classes e relacionamentosatributos e operaes que caracterizam cada classe

notao: diagrama E-R estendidoModelo Dinmico:

captura o comportamento dinmico de cada classe:mquina de estados: como objetos da classe respondem aos eventosevento representa um estmulo externoestado uma abstrao dos valores dos atributos e relacionamentos

Modelo Funcional:mostra o que o sistema deve fazer: uso de DFDs

PROJETO: decises 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 mtodosdetermina mtodos das classesparticiona projeto em mdulos para a programao



8

IMPLEMENTAO: codificao do projeto dos objetos.

PRSAnlise possui um processo bem definidoModelos da anlise com notaes concisas e inteligveisCONTRASRelacionamento entre modelos da anlise no claroModelos da anlise dificultam percepo do cenrio globalProjeto no possui abordagem passo a passoNo fica claro onde/quando deve-se comear projeto

BOOCH [Booch, 1994]Processo com natureza descritiva (o que podemos fazer) e no prescritiva (o que devemos fazer)Notaes (sem ordenamento do processo):

Diagramas de Classes:classes e relacionamentos (esttico): variao do E-Resboos so produzidos no incio do desenvolvimento e completados durante aidentificao dos relacionamentos

Diagramas de Objetos:objetos e relacionamentos (dinmico): troca de mensagensesboos so produzidos no incio do desenvolvimento e completados durante aidentificao dos relacionamentos

Diagramas de Tempo:apresentam informaes de ordenao (sem mensagens)eixo-x (tempo ) e eixo-y (fluxo de controle entre os objetos)tambm identificam tempo de criao e destruio de objetos

Diagramas de Estados:transio de estados dos objetos

Diagramas de Mdulos e Diagramas de Processos:grafos identificam viso fsica do sistemadiagrama de Mdulos:alocao de classes e objetos em mdulos e dependncia dos mdulos

Diagrama de Processos:processadores, dispositivos e conexo de comunicao entre eles

PRSConjunto de notaes abrangem todos os aspectos de um sistema orientado a objetosCONTRASNotao complexaInformaes se duplicam entre os vrios modelosAusncia de processo bem-definido para o desenvolvimento de sistema

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

dilogo/transaes entre o sistema e um usurio



9

Adota o termo agentes: usurios do sistemaUse Cases capturam funcionalidades do sistemaDemais modelos so construdos sobre use casesUse cases -- elos de ligao entre as fasesREQUISITOS: declarao em linguagem natural.Modelo Caso-de-Uso:

identifica agentes e seus casos-de-uso:Modelo de Objetos do Domnio:

suporta os casos-de-uso: conceitos com o qual o sistema operanotao similar a de um modelo E-R

Descries da Interface com o Usurio:esboos das janelas que os usurios vero na telaenvolve o usurio no processo de desenvolvimento

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

grupos de objetos com comportamento similarcritrios para agrupamento:

forte acoplamento entre objetosflexibilidade para suportar mudanas nos requisitos

CONSTRUO: modelos da anlise so refinados.Modelo de Blocos:

Identifica blocos (abstrao de blocos de cdigo) do sistemaCada bloco composto por um ou mais objetos da anlise

Diagrama de Interaes:Participao dos blocos (atravs de mensagens) com use cases

Modelo de Interface de Blocos:Interface operacional: formada pela extrao das operaes realizadas sobre um bloco

Especificao de Blocos:Modelo opcional sobre o comportamento interno do bloco: mquinas de estados

PRSContribui com o conceito de use case: base do processoCONTRASModelos e notaes: inadequados e insuficientesDifcil compreenso de alguns modelosDificuldade para verificar inteireza e/ou consistncia do sistema desenvolvido

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

Objetos so agrupados, gerando classes em cartesAes dos objetos transformadas em responsabilidades das classes: tarefas a seremexecutadas pela classe

ATRIBUIR RESPONSABILIDADES:Responsabilidades so alocadas s classesDistribuio das tarefas do sistema



10

IDENTIFICAR COLABORAES:Identificao das interaes entre as classes: exame de cada par classe/responsabilidadebuscando suas dependncias com outras classes

PRSComo tcnica exploratria (no um mtodo) bastante avanadatil no projeto de estruturas de heranaMuito poderosa para o projeto das interaes entre os objetosCONTRASCartes de referncia: nico registro para as decises tomadasInadequadas para fins de manutenoNo trata da criao/destruio de objetos

MTODOS FORMAISAbordagem de engenharia de software baseada na aplicao de matemtica discreta programaode computadoresPropriedades do sistema so capturadas em um alto nvel de abstraoTrabalhos recentes tentam estender estes mtodos aos sistemas orientados a objetosAlto custo de aceitao: exigido muito conhecimento matemticoMtodo promissor: a longo prazo

FUSION [Coleman, 1996]O mtodo Fusion caracteriza o centro dos estudos para nossa abordagem de orientao a objetos.

Portanto, neste contexto apenas apresentada a figura 1.3 que representa o sentido de seu batismo, natraduo de uma fuso de abordagens e mtodos. Deixaremos os detalhes do mtodo Fusion para asubseo a seguir e, como bem ser fundamentado, este mtodo ser visto ao longo de todo o nossotrabalho.

Figura 1.3 - Mtodo Fusion [Coleman, 1996]

UNIFIED MODELING LANGUAGE (UML) [OMG, 2001]A UML, juntamente com o mtodo Fusion, forma a base de nossos estudos. Portanto haver uma



11

seo especfica para trat-la (seo 1.1.3). Neste momento vale lembrar apenas que a UML umalinguagem grfica para visualizar, especificar, construir e documentar artefatos de sistemas de software.Assim, a UML no se caracteriza como um mtodo ou processo de construo de software, sendo estefato, e a sua padronizao, os avais para sua utilizao em nosso trabalho, o que tambm poder ser feitoem empresas de desenvolvimento que adotem mtodos e processos proprietrios/particulares paraconstruo de software.

1.1.2 - Mtodo Fusion de Anlise e Projeto Orientado a ObjetosO Fusion se caracteriza como um mtodo de anlise e projeto de sistemas voltado para a produo

de software orientado a objetos. Este mtodo estabelece uma rota direta entre a definio dos requisitos e aimplementao do sistema, partindo, contudo, de uma definio de requisitos pr-estabelecida.

Para a conduo das fases de anlise e projeto, o mtodo Fusion estabelece um conjunto conciso ecompleto de notaes bem-definidas.

A construo do software a partir do mtodo Fusion considera um processo dividido em fases. OFusion estabelece o que deve ser feito em cada fase, orientando a sequncia de aes de cada fase e oscritrios que suportam o ponto de passagem para as fases subsequentes.

O mtodo Fusion no cobre a captura de requisitos. Portanto, o mesmo prev que os requisitossejam fornecidos por usurios e documentados seguindo-se alguma tcnica de elicitao e deespecificao de requisitos "qualquer".

Assim sendo, a diviso proposta pelo mtodo Fusion para o processo de desenvolvimento Anlise,Projeto e Implementao, conforme segue um breve resumo.

ANLISE: o que o sistema faz e no como feito.Descobre os objetos e as classes existentes no sistema e seus relacionamentos;Define o comportamento esperado do sistema;Modelos so produzidos para identificar:

Classes de objetos que existem no sistema;Relacionamentos entre essas classes;Operaes que podem ser executadas no sistema;Sequncias permissveis para eventos de entrada e de sada;

No associa mtodos s classes.PROJETO: define como sero implementadas as operaes do sistema atravs do comportamento

dos objetos em tempo de execuo.Operaes so divididas em interaes de objetos;Operaes so associadas s classes;Como objetos faro referncias mtuas entre si;Relacionamentos de herana entre as classes;Modelos do projeto identificam:



12

Como operaes sero implementadas pelas interaes entre os objetos;Como as classes faro referncias mtuas e como iro se relacionar por herana;Os atributos das classes e suas operaes;

IMPLEMENTAO: transforma projeto em cdigo.Herana, referncias e atributos so codificados nas classes especficas;Interaes entre objetos so transformadas nos mtodos dos objetos;Mquinas de estado so usadas para se reconhecer as sequncias permitidas para as operaes;Tambm so consideradas tcnicas de inspeo e teste para avaliao de sistemas orientados aobjetos.DICIONRIOS DE DADOS: so adotados durante todo o processo de desenvolvimento e

identificam as entidades existentes no sistema.Segue abaixo uma viso geral do mtodo Fusion. So identificadas as fases e os modelos gerados

por cada uma delas e como esto interligados.

Figura 1.4 - Estrutura do Mtodo Fusion [Coleman, 1996]

1.1.3 - Padres de Modelagem de Objetos usando UML - Unified Modeling LanguageA UML teve seu desenvolvimento iniciado em outubro de 1994 quando Grady Booch e Jim

Rumbaugh, da Rational Software Corporation, comearam seus trabalhos de unificar os mtodos Booch e



13

OMT. Em 1995 juntou-se com aqueles Ivar Jacobson e sua companhia uniu-se Rational e seu mtodoOOSE passou a colaborar com a proposta da UML.

//?? Continuar com uma viso estrutural da UML a partir da OMG: no mais de uma ou duaspginas. Procurar uma figura representativa.

1.2 - Mtodo Fusion Expandido e Adaptado UMLA proposta deste trabalho resultado do projeto FILM, o qual est institucionalizado na

Universidade de Caxias do Sul pelo Departamento de Informtica e tem como objetivo adaptar e expandiro mtodo Fusion de anlise e projeto de sistemas orientado a objetos. Este ajuste do mtodo tambmexpande o espectro do mtodo Fusion, acrescentando ao mesmo a abordagem da fase inicial deespecificao de requisitos, a qual no considerada na verso original do mtodo Fusion [Galimberti,2001].

Para a expanso do mtodo e adequao de seus modelos, utiliza-se da proposta da UnifiedModeling Language (UML). A UML prope flexibilidade aos diversos processos de desenvolvimento desoftware, expandindo mtodos orientados a objetos e disponibilizando um conjunto de notaes para aconstruo dos modelos da orientao a objetos [Galimberti, 2001].

Para a fase de Definio de Requisitos o projeto est baseado na proposta Um Modelo deEstruturao de Requisitos para o Mtodo Fusion Adaptado UML [Rocco, 2001]. No entanto,dependendo dos objetivos e carga horria de um curso de APOO, ser possvel partir de especificaestextuais e, preferencialmente, adoo de use cases para a definio de requisitos.

A estrutura geral proposta pelo projeto FILM est demonstrada na figura 1.5 abaixo, a qual foiconstruda a partir das notaes de use case da UML. Esta figura objetiva visualizar a estrutura geralproposta atravs dos processos e de suas fases. A partir da seo 1.2.1 ser oferecida uma viso maisespecfica sobre as informaes a serem documentadas em cada fase atravs de seus modelos.



14

Figura 1.5 Estrutura do FILM com atores e processos (linear e cclico)



15

1.2.1 - Conduo das Fases do Mtodo de Especificao e Construo do SoftwareO projeto FILM prev as fases de Estruturao e Especificao de Requisitos, Anlise, Projeto,

Implementao e Testes. A seguir sero apresentadas e comentadas as estruturas de cada uma das fasespropostas no projeto FILM e a serem abordadas nos captulos posteriores.

Fase de Estruturao e Especificao de RequisitosA metodologia a ser trabalhada inicia com a Fase de Estruturao e Especificao de Requisitos.

Considerando um processo linear para sua abordagem, deveremos documentar as informaes que estosendo elicitadas conforme a figura 1.6 abaixo. Os principais documentos sero o Documento Contextualdo Sistema, Modelo de Objetivos, Viso de Use Case e Cenrios e Ciclo de Vida do Sistema. OPlanejamento do restante do processo cclico de desenvolvimento do sistema marca o encerramento destafase de Especificao de Requisitos.

Figura 1.6 - Fase de Estruturao e Especificao de Requisitos



16

Fase de AnliseA fase de Anlise de nosso trabalho marca o incio da investigao interna sobre o sistema e prope

um conjunto de modelos a serem desenvolvidos conforme a figura 1.7. Considerando os ciclos planejadosna fase anterior, todos os modelos devero ser construdos para cada ciclo. Portanto, as principaisinformaes modeladas durante a fase de Anlise estaro nos Modelos de Objetos e Modelo de Interfaces.No entanto, conforme a proposta cclica, o primeiro passo desta fase sugere que os requisitos do ciclo emquesto sejam refinados antes de se iniciar o processo de modelagem dos objetos e operaes.

Figura 1.7 - Fase de Anlise



17

Fase de ProjetoA fase de Projeto caracteriza-se pela modelagem dinmica do sistema principalmente em termos das

mensagens e dos objetos necessrios s operaes especificadas na fase de Anlise. Portanto, conforme afigura 1.8, as principais informaes sero modeladas atravs dos Grafos de Interao de Objetos. Isto irviabilizar, para o final da fase de Projeto, que sejam feitos melhoramentos em nossos Modelos de Objetos,buscando iniciar a fase de Implementao com as estruturas/prottipos de classes.

Figura 1.8 - Fase de Projeto



18

Fase de ImplementaoNossa fase de implementao estar caracterizada em se traduzir informaes, presentes

principalmente nos modelos da fase de Projeto, em Estruturas/Prottipos de Classes de Objetos, conformeobserva-se na figura 1.9.

Figura 1.9 - Fase de Implementao



19

PARTE I - PROCESSO LINEAR

Figura Parte I Processo Linear



2. Fase de Estruturao e Especificao de RequisitosA fase de Estruturao e Especificao de Requisitos ser tratada atravs de um processo linear,

onde sero definidos os requisitos para todo o sistema em funo de seus objetivos principais. Portanto,esta fase se prope a investigar e documentar o domnio do problema em estudo tendo como foco osobjetivos que sero buscados quando da preparao da soluo do problema. Futuramente, aps asdefinies dos ciclos que se iniciam na fase de Anlise, todos os requisitos voltaro a ser melhordocumentados a partir de outras ferramentas de modelagem.

Para facilitar o trabalho de documentao de requisitos, este captulo orienta o estudante a buscarum conjunto inicial de informaes constantes do Documento Contextual do Sistema. Em seguida serabordada uma tcnica para se documentar requisitos a partir de objetivos, onde sero utilizados osModelos de Objetivos e a Viso de Use Cases para expressar os principais processos identificados nodomnio do problema em estudo. Logo aps a construo dos use cases ser descrita uma maneira de sedocumentar a interao dos agentes/atores com o sistema e em que sequncia isto pode ocorrer.

O tratamento dado aos requisitos antes da fase de Anlise estar temporariamente encerrado com oplanejamento das fases seguintes em termos de processos cclicos de construo do sistema.

Haver, contudo, uma seo a parte no captulo voltada a abordar a manuteno de um Glossrios deTermos, necessrio durante todo o tempo em que ser construdo o sistema e que, por se constituir emalgo bastante simples, no mereceu um captulo especfico para seu estudo.



Figura 2.1 Fase de Estruturao e Especificao de Requisitos

2.1 - Documento Contextual do SistemaO Documento Contextual do Sistema dividido em cinco clusulas que ajudam a criar uma viso

macro do sistema. A partir deste documento j se pode ter uma idia do sistema e seu enquadramento noambiente ao qual vai servir, podendo-se prever a viabilidade de construo do projeto.

A orientao para que este documento contenha as clusulas, ou sees, conforme abaixo:

Descrio InicialEssa descrio expe uma viso geral do sistema, citando quais mdulos o compem, quais as

necessidades que ele pretende atender e o resultado esperado aps sua implementao.

Problema Original uma exposio da situao 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 seest propondo.

Origem do sistema



Esta clusula dever identificar se o projeto a ser desenvolvido ser de um sistema novo ou seruma manuteno para a atualizao de um sistema j existente. No caso de ser uma atualizao sobreum sistema j existente, deve-se analisar o quanto do mesmo poder ser aproveitado e qual ser o volumede alteraes que necessitam ser realizadas sobre ele para que o mesmo possa suprir as necessidades dosclientes. Tambm no caso da atualizao, deve-se analisar a relao custo-benefcio para que no sejamais oneroso efetuar as alteraes sobre o sistema existente do que desenvolver um sistema novo, jvoltado para as atuais necessidades.

Contexto de utilizaoEsta clusula consiste na descrio do ambiente onde o sistema ir atuar, tanto em nvel local fsico

quanto em relao ao tipo de agente que ir interagir com ele.

Limites do sistemaEsta clusula definir as responsabilidades do sistema dentro dos objetivos. Devem ser definidos

quais objetivos sero atendidos pelo sistema e quais deles ficaro sob responsabilidade dos usurios ou deoutros sistemas, evitando a criao de falsas expectativas por parte das pessoas envolvidas no projeto.

2.2 - Modelo de ObjetivosO processo de elicitao deve ser concomitante ao modelo de objetivos, o qual define a estruturao

das informaes. A estrutura das informaes prev a definio do objetivo e a descrio dos objetos queo compem. So sugeridas questes que tem o propsito de descobrir, ante ao objetivo, os objetosresultado, sujeitos, objetos e ferramentas, conforme as figuras 2.2 e 2.3.

Figura 2.2 A definio de um objetivo [Rocco, 2001]



Esquema de Descrio de ObjetivoObjetivo Elicitadas as informaes, pode-se definir um objetivo para o sistema em

questo. Descrio 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 necessrio ao sistema?Sujeito Quem atua em prol desse objetivo?Ferramenta Quais so os recursos necessrios para os sujeitos interagirem com o

objeto?Figura 2.3 - Estrutura para a descrio de objetivo [Rocco, 2001]

2.2.1 Estrutura dos ObjetivosEsta estrutura tem por finalidade compor a estrutura hierrquica dos requisitos derivados de cada

objetivo. Neste momento apenas os requisitos de nvel mais alto so abordados, pois para contemplar umrequisito outros requisitos podem ser necessrios. Essa estrutura dada pela associao entre objetivo erequisitos e refinamentos entre os requisitos. O objetivo define uma atividade realizada no sistema,enquanto que os requisitos definem as aes necessrias para a realizao completa da atividade.

Essa abordagem hierrquica do modelo permite estruturar os requisitos em nveis verticais deabstrao, nos quais os requisitos so associados por qualificadores E, que indica requisitoscomplementares, e por qualificadores OU, que indica requisitos opcionais para o atendimento atividadeou s aes hierarquicamente sobrejacentes. A figura 2.4 representa a estrutura dos objetivos.

Em uma primeira etapa do processo proposto, os requisitos so expressos somente em nvel inicial,ficando os demais requisitos derivados a serem identificados e definidos posteriormente, aps oestabelecimento dos ciclos prioritrios para o desenvolvimento.

Figura 2.4 Estrutura dos Objetivos [Rocco, 2001]



Figura 2.5 Definio de Requisito [Rocco, 2001]

Descrio dos requisitos nvel 0Cada requisito descrito segundo estrutura representada na figura 2.6, valendo lembrar que estes

requisitos so somente os de nvel 0.

Esquema de Descrio de Requisito

Nome: Nome: identificador da ao, como ela reconhecida dentre oscasos de uso do sistema.

Ao

Descrio: Descrio: informao elicitada; tipicamente, uma narrativa comoos envolvidos descrevem a ao requerida ao software.

Agente Solicitante da ao; quem age. o ente que emite um estmulo requerendo aexecuo de alguma ao ao sistema.

Produto Objeto produzido por uma ao realizada na criao, transformao oudestruio do objeto definido no objetivo. Desta maneira, os produtos dorequisito so composies dos objetos do objetivo.

Recurso Objeto que corresponde interface entre o agente e o software, ou a informaoque o agente envia para os objetos do domnio do software para que possamexecutar alguma ao em prol da produo de algum produto.

Anotao Descries de requisitos no funcionais que compem um requisito modelado.

Figura 2.6 Estrutura para Descrio de um Requisito [Rocco, 2001]

2.3 - Viso de Use CasesA seo de Use Cases da especificao de requisitos tem como objetivo apresentar uma estrutura

grfica abrangendo o sistema a partir de seus principais processos e agentes. Portanto, a construo doDiagrama de Use Cases apresenta os atores envolvidos no sistema que est sendo elicitado e com quaisprocessos os mesmos esto em contato.

Atividades e DependnciasEm geral os Use Cases podero ser convertidos dos requisitos de nvel 0. Contudo possvel que

sejam derivados diretamente dos objetivos quando estes possurem requisitos de nvel 0 simples ou empequena quantidade, o que pode ser mais conveniente para a gerao do modelo de Use Cases.



Estratgias para ModelagemA orientao para modelagem dos Use Cases sugere que sejam derivados dos Objetivos

identificados anteriormente. Todavia, no sendo usada a abordagem por objetivos, pode-se partir daespecificao de requisitos listando-se possveis Use Cases e, a partir disso, montar o diagramaassociando-os aos seus respectivos atores.

Notaes para Modelagem

Figura 2.7 Diagrama de Use Case

Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).

2.4 - Cenrios e Ciclo de Vida do SistemaDentro da fase de Especificao de Requisitos, a construo dos Cenrios e do Ciclo de Vida tem

como finalidade visualizar a interao dos Atores com o sistema, em um alto nvel atravs dos Use Cases,e a sequncia permissvel de ocorrncia/execuo destes Use Cases, os quais sero convertidos emExpresses Ciclo de Vida.

Atividades e DependnciasA construo das expresses ciclo de vida so baseadas nos Modelos dos Objetivos e na Viso de

Use Case do sistema.

Estratgias para ModelagemA modelagem do ciclo de vida s pode ser feita dominando-se a sequncia e repeties de

ocorrncia 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 sentenade Ciclo de Vida do sistema conforme ocorrncia destes Use Cases.

Notaes para ModelagemA modelagem do ciclo de vida feita de forma declarativa, necessitando-se de um conjunto



gramatical para sua representao. Inicialmente sero utilizadas as notaes Fusion at que sejammapeadas para UML. A sintaxe geral para o modelo ciclo de vida segue apresentada abaixo.

Life Cycle [Nome:] Expresso-Regular(Nome-Local-Expresso = Expresso-Regular)*

-Alfabeto: qualquer evento de entrada ou sada pode ser utilizado em uma expresso eventos de sada: precedidos pelo smbolo #

-Operadores: sendo x e y expresses ciclo-de-vida: x . y denota x seguido por y x | y denota a ocorrncia de x ou y x * denota zero ou mais ocorrncias de x x + denota uma ou mais ocorrncias de x [ x ] denota que x opcional x | | y significa intercalao arbitrria de x e y

-Substituies Nome = expresso ciclo-de-vida

-Precedncia de Operadores (ordem decrescente) [ ], *, +, . , | , | |


2.5 - Planejamento dos Ciclos de Construo do SistemaA tarefa de planejar os ciclos de desenvolvimento do sistema no sugere atualmente nenhuma forma

especfica de modelagem. As diretrizes bsicas, contudo, orientam que os ciclos de construo do sistemasejam programados com o objetivo de liberar pequenos mdulos aos usurios para que possam sergradativamente testados e melhorados. A tendncia que cada ciclo no consuma mais de dois meses paraser construdo (analisado, projetado e implementado).

Atividades e DependnciasO planejamento dos ciclos, partindo de prazos estabelecidos e necessidades dos usurios, sugere a

estruturao de cronogramas de construo por ciclo. Assim sendo, as informaes de objetivos e usecases, bem como o ciclo de vida do sistema, devem ser o ponto inicial de observao para organizar osciclos por prioridades do sistema e dos usurios e preparar a passagem para as fases seguintes do processode construo do software.

Os ciclos devem ser planejados considerando o tempo para sua concluso, tendo como objetivo suaimplantao e colocao em teste junto aos usurios. O objetivo que cada ciclo seja estanque, sendo



necessria a sua concluso para que possa ser encaminhado o incio de um novo ciclo. Isto no inviabilizaa construo incremental de ciclos, pois tambm se tem como objetivo o escalonamento dodesenvolvimento atravs de verses diferentes de construo dos use cases ou objetivos do sistema.


2.6 - Manuteno de um Glossrio de TermosO glossrio de termos serve para documentar informaes que requeiram melhores esclarecimentos,

de modo a melhorar a comunicao e evitar mal-entendidos. Originalmente denominado dicionrio dedados tambm no mtodo Fusion, ser referenciado como glossrio de termos pelo seu carter de registrarno apenas dados, mas tambm quaisquer informaes e restries que no possam ser colocadas nosdiagramas construdos ao longo do processo de anlise e projeto de sistemas.

Um glossrio de termos representa uma ferramenta vital onde todas as definies feitas devem serencontradas. Manter o glossrio de termos uma atividade contnua durante todo processo de construodo sistema e por menor que seja a descrio de um item, ainda assim a melhor forma de deixar claro oseu significado.

O mtodo Fusion orienta para a construo de um glossrio, porm no obriga a uma sintaxe enotaes especficas. Portanto, neste trabalho, sugerida uma forma bsica para documentao dos itensatravs de tabelas. As colees de itens de mesma categoria podem ser documentadas em tabelasespecficas, otimizando a localizao dos termos.

Estratgias para ModelagemConsiderando que a manuteno do glossrio de termos seja uma atividade constante durante todo o

processo de construo do sistema, orienta-se para que o mesmo seja atualizado ou durante a construodos diagramas ou logo aps o encerramento dos mesmos. Segue abaixo uma sugesto de como estruturaras informaes dentro do glossrio de termos.

Notaes para ModelagemA documentao do glossrio, em geral, ser possvel atravs de uma tabela de trs colunas como

abaixo. No entanto, conforme o momento do processo de construo do sistema, outras colunas poderoser acrescentadas para melhor descrever determinados termos.

Nome do Termo Categoria DescrioIdentificao do termomodelado

Designao do tipo do termo emrelao ao seu propsito demodelagem

Texto descritivo

Figura 2.8 Glossrio de Termos



PARTE II - PROCESSO CCLICO

Figura Parte II - Processo Cclico



3. Fase de AnliseA funo da fase de Anlise , 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 operaes que podero ser executadas pelo sistema. A fase deAnlise mostra "o que" o sistema faz e no "como" ele feito, obtendo-se ao final desta fase um"documento de especificaes".

A construo de dois modelos estticos so os objetivos da fase de Anlise, os quais tratam deaspectos diferentes, sendo o Modelo de Objetos e o Modelo de Interfaces, este ltimo sendo compostopelos Cenrios e seus Modelos de Ciclo de Vida e pelo Modelo de Operaes. Assim, esta fase doprocesso responsvel pelas seguintes descries: classes de objetos (sem associar quaisquer mtodos sclasses); relacionamentos entre classes; operaes do sistema; sequncia permissvel de operaes. Noentanto, a proposta de um processo cclico exige que os requisitos a serem tratados sejam melhordetalhados. Assim, a proposta para a fase de Anlise prev que os requisitos sejam refinados modelando-os por Objetivo (Modelo de Requisitos por Objetivo) e adotando-se os Cenrios para melhor visualiz-los.A figura 3.1 oferece uma visualizao, atravs de use cases, da estrutura a ser modelada durante a fase deAnlise.

Figura 3.1 Fase de Anlise

3.1 - Conduo da Fase de AnliseA fase de anlise deve ser conduzida de forma a transformar as informaes coletadas durante a fase

de definio de requisitos em modelos que representem as estruturas estticas do sistema e ocomportamento do mesmo. No entanto, a partir da fase de Anlise o sistema ser modelado atravs de umprocesso cclico. Este processo foi estabelecido de forma a viabilizar a construo incremental do sistema.



Assim sendo, o primeiro passo da fase de Anlise ser estruturar o ciclo em questo, 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 soas interaes existentes entre o sistema, durante o(s) use case(s) em questo, e o meio em que estinserido. Isto ser feito atravs da representao de eventos de entrada e de sada entre o sistema, o qualseve ser visto como uma caixa preta.

Modelagem Fusion:Cenrios do Sistema por Objetivo: utilizar notaes padro UML para Diagrama deSequncias;

Modelagem de Refinamento de Requisitos:Modelo de Requisitos por Objetivo: utilizar notaes da abordagem de Requisitos por Objetivo

Com uma abordagem orientada a objetos, as primeiras modelagens devem representar as classes deobjetos atravs de conceitos relevantes soluo do problema em anlise em geral substantivos quepodem ser submetidos a uma lista de categorias, conforme [Larman, 2000] identificados nasinformaes at ento documentadas. Estes conceitos sero modelados como classes de objetos que serelacionam entre si atravs de restries de cardinalidades. So identificados tambm os primeirosatributos de cada classe de objeto. A sugesto inicial que as associaes (relacionamentos) sejamsimples, protelando-se associaes dos tipos agregaes, generalizaes e especializaes para ummomento mais propcio da fase de Projeto.

Modelagem Fusion:Modelo de Objetos: utilizar notaes padro UML do Diagrama de Classes.

As prximas informaes a serem modeladas caracterizam-se por representar a estruturacomportamental do sistema. O comportamento do sistema deve ser documentado de forma a identificarquais so as interaes existentes entre o sistema e o meio em que est inserido. Isto j deve ter sido feitonos cenrios atravs da representao de eventos de entrada e de sada entre o sistema, no entanto agoradeve ser modelada a sequncia permissvel para ocorrncia destes eventos dentro do ciclo de vida dosistema. Portanto, neste momento da fase de Anlise deve-se modelar os eventos de entrada comooperaes do sistema. Assim, as operaes sero documentadas de forma a identificar quais estruturas deobjetos devero ser manipuladas para realizar cada operao e suas responsabilidades. As operaesmodelam os eventos de entrada e seus efeitos no sistema, os quais podem ser as alteraes no estado dosistema e/ou os eventos gerados na sada.

A fase de Anlise ser encerrada estabelecendo-se as fronteiras do sistema, no Modelo de Objetos,em relao ao meio em que est inserido. Isto ser feito com a construo do Modelo de Objetos doSistema, onde sero mantidas as estruturas de classes e associaes necessrias s operaes do sistemajuntamente com os atores/agentes que interagem com o mesmo.

Modelagem Fusion:Modelo de Interfaces:

Modelo Ciclo de Vida: utilizar notaes Fusion at adaptao UML;Modelo de Operaes: utilizar notaes padro UML para Contratos;

Modelo de Objetos do Sistema: utilizar notaes padro UML do Diagrama de Classes



juntamente com Atores dos Use Cases.

3.2 - Refinamento dos Requisitos por CicloConsiderando o processo cclico a ser abordado na fase de Anlise, o primeiro passo agora partir

dos 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.Sero desenvolvidos os Cenrios respectivos aos Use Case(s) em questo e os Modelos de Requisitos porObjetivo.

3.2.1 Cenrios do Sistema por ObjetivoEm paralelo expanso dos requisitos, descritos na seo 3.2.2, deve ser modelado o

comportamento do sistema de forma a identificar quais so as interaes existentes entre o sistema,durante o(s) use case(s) em questo, e o meio em que est inserido. Isto ser feito atravs da representaode eventos de entrada e de sada entre o sistema, o qual deve ser visto como uma caixa preta.

Abaixo segue um esquema com a notao a ser utilizada para a modelagem dos Cenrios, o qualadota o padro UML para Diagrama de Sequncias.

Atividades e DependnciasA construo dos cenrios deve partir da especificao de requisitos, mais especificamente a partir

do Modelo de Objetivos e dos Use Cases. Seu desenvolvimento tambm depende do Modelo deRequisitos por Objetivo, sugerindo que sejam construdos em paralelo.

Estratgias para ModelagemA principal orientao para montagem dos Cenrios est na identificao dos atores e suas aes, o

que pode ser feito observando-se as clusulas dos Esquemas de Descrio de Requisitos do objetivo emquesto. As principais clusulas so Ao, Agente e Recurso.




Figura 3.2 Cenrios com notao UML de Diagrama de Sequncia


3.2.2 Modelo de Requisitos por ObjetivoOs requisitos devero agora ser expandidos para o Objetivo em questo no ciclo. A estrutura a ser

utilizada exatamente a mesma vista na seo 2.2 de Modelo de Objetivos, porm agora os requisitosdevero ser melhor detalhados, abaixo do nvel 0. Vale voltar e observar as figuras 2.4, 2.5 e 2.6.

Portanto, cada requisito ser refinado conforme definio da figura 2.5, estando suas clusulascomentadas na seo 2.2.1, na figura 2.6.

Atividades e DependnciasComo bem pode-se observar, a construo deste modelo est diretamente ligada ao Modelo de

Objetivos e aos Cenrios.

Estratgias para ModelagemPartindo do Modelo de Objetivos, a clusula Ao deve ser o ponto inicial de investigao para a

descrio do requisito em si, buscando-se definir outros objetos que compem o requisito.

Notaes para ModelagemVer seo 2.2.1, figura 2.6.

Estudo de CasoSistSW01 (Apndice A);



SistSW02 (Apndice B).

3.3 - Modelo de Objetos (Modelo Conceitual)A abordagem do modelo de objetos visa representar as classes de objetos atravs de conceitos

identificados nas informaes at ento documentadas. Estes conceitos sero modelados como classes deobjetos que se relacionam entre si atravs de associaes e restries de cardinalidades. So identificadostambm os primeiros atributos de cada classe de objeto. A sugesto inicial que as associaes(relacionamentos) sejam simples, protelando-se associaes dos tipos agregaes, generalizaes eespecializaes para um momento mais propcio da fase de Projeto.

Abaixo segue um esquema com a notao a ser utilizada para a modelagem dos objetos, o qual adotao padro UML para Diagrama de Classes.

Atividades e DependnciasA modelagem dos objetos depende dos requisitos at ento coletados para o ciclo em questo.

Devem ser observados os Cenrios e os Modelos de Requisitos por Objetivo. A partir do segundo ciclo dedesenvolvimento, vale lembrar em observar os modelos de objetos j construdos, pois pode-se reutilizarclasses de objetos j modeladas.

Estratgias para ModelagemUma das tarefas mais complicadas quando se comea a modelar objetos a identificao das classes

de objetos. Vrias so as tcnicas utilizadas para sua modelagem, no entanto no existe nenhuma frmulamgica para este fim.

O procedimento bsico, contudo, partir das especificaes de requisitos correspondentes ao cicloem questo. Nossa sugesto utilizar de duas tcnicas em conjunto, sendo a tcnica 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 especificao derequisitos, os quais sero candidatos a classes. A partir da deve-se buscar sua identificao nas tabelas decategorias de [Larman, 2000] buscando qualificar o conceito como classe de objeto ou como atributo. Alista de substantivos gerada tambm facilita a eliminao de redundncias (conceitos de objetossemelhantes ou repetidos).

Busque no modelar chaves (primrias, estrangeiras, ...) como em bancos de dados. Isto dever serfeito no momento de mapear as classes de objetos para uma estrutura de dados persistentes.




Figura 3.3 Modelo de Objetos com Notaes UML do Diagrama de Classes


3.4 - Modelo de InterfacesO comportamento do sistema deve ser documentado de forma a identificar quais so as interaes

existentes entre o sistema e o meio em que est inserido. Isto j deve ter sido feito atravs darepresentao de eventos de entrada e de sada entre o sistema, atravs dos Cenrios anteriores, mas agoradeve ser modelada a sequncia permissvel para ocorrncia destes eventos dentro do ciclo de vida dosistema. A fase de Anlise se encerra modelando-se os eventos de entrada como operaes do sistema.Portanto, as operaes sero documentadas de forma a identificar quais estruturas de objetos devero estardisponveis para realizar cada operao e suas responsabilidades. As operaes modelam os eventos deentrada e seus efeitos no sistema, os quais podem ser as alteraes no estado do sistema e os eventos



gerados na sada.

3.4.1 Cenrios e Modelo Ciclo de VidaDentro do Modelo de Interfaces, a construo do Ciclo de Vida tem como finalidade modelar a

sequncia permissvel de ocorrncia dos eventos de entrada e de sada, considerando que os Cenrios,construdos no incio da fase de Anlise, no tem este propsito.

Atividades e DependnciasA construo das expresses ciclo de vida so baseadas nos Cenrios e fundamentadas nos

requisitos especificados nos use cases e objetivos em questo no ciclo.

Estratgias para ModelagemA modelagem do ciclo de vida s pode ser feita dominando-se a sequncia e repeties de

ocorrncia dos eventos previamente modelados. Portanto, deve-se ter clareza do funcionamento do usecase em questo e dos requisitos para se alcanar o objetivo que est sendo abordado. Lembra-se que foiespecificado, ainda na fase de Definio de Requisitos, um Modelo Ciclo de Vida baseado em use cases, oque facilita o refinamento de suas expresses/subexpresses.

Notaes para ModelagemA modelagem do ciclo de vida feita de forma declarativa, necessitando-se de um conjunto

gramatical para sua representao. Inicialmente sero utilizadas as notaes Fusion at que sejammapeadas para UML. O conjunto notacional est especificado abaixo, sendo o mesmo descrito na seo2.4.

-Alfabeto:qualquer evento de entrada ou sada pode ser utilizado em uma expressoeventos de sada: precedidos pelo smbolo #

-Operadores: sendo x e y expresses ciclo-de-vida:x . y denota x seguido por yx | y denota a ocorrncia de x ou yx * denota zero ou mais ocorrncias de xx + denota uma ou mais ocorrncias de x[ x ] denota que x opcionalx | | y significa intercalao arbitrria de x e y

-SubstituiesNome = expresso ciclo-de-vida

-Precedncia de Operadores (ordem decrescente)[ ], *, +, . , | , | |

Estudo de CasoSistSW01 (Apndice A);



SistSW02 (Apndice B).

3.4.2 Modelo de OperaesA construo do modelo de operaes marca o momento do processo em que se comea a investigar

as estruturas internas do sistema em construo. As operaes sero modeladas atravs de fichas com umconjunto de clusulas. Cada clusula tem seu propsito de transformar os requisitos do objetivo emreferncias s estruturas at ento modeladas como objetos. Portanto, cada evento de entrada setransformar em uma operao, merecendo uma ficha/esquema de modelagem, a partir da qual serodocumentadas as responsabilidades da operao e os efeitos causados ao sistema aps sua execuo.

Possveis resultados associados a uma operao do sistema, so:Criar uma nova instncia de classe;Alterar atributos de objetos existentes/instanciados;Criar/eliminar tuplas de relacionamentos;Envia um evento a um agente.

Atividades e DependnciasA construo do Modelo de Operaes depende praticamente de todas informaes documentadas

at ento para o ciclo em questo. A base da modelagem das operaes, contudo, formada pelo Modelode Objetos, Cenrios e Ciclo de Vida alm, claro, das especificaes de requisitos atravs do Modelo deRequisitos por Objetivo.

Estratgias para ModelagemA estratgia para modelagem das operaes deve iniciar observando-se os Cenrios e as expresses

Ciclo de Vida do ciclo, transformando cada evento de entrada em uma ficha de operao. A partir disso,as tarefas restantes tero o propsito de preencher as demais clusulas do esquema de operaes.



Notaes para ModelagemA modelagem das operaes feita de forma declarativa, adotando-se clusulas da notao padro UMLdos Contratos. As clusulas devem estar dispostas em um esquema de operao, conforme sugestoabaixo.

Esquema de OperaoNome Nome da operao, geralmente o mesmo do evento de entrada que a originou;

Responsabilidades Texto descritivo sobre as caractersticas principais da operao, principalmente no que serefere s responsabilidades da mesma;

Referncias Reads Itens.Nesta clusula devem ser relacionados quais itens objeto necessita-se manipular (comacesso de leitura) para executar a operao. Possvel uso da palavra-reservada supplied(fornecido) precedendo um parmetro da operao;

RefernciasChanges

Itens.Anlogo clusula anterior, nesta devem ser relacionados quais itens objeto necessita-semanipular (com acesso de gravao/escrita) para executar a operao. Possvel uso dapalavra-reservada new (novo) precedendo um Item-objeto, o que indica que esta operaoir criar um novo objeto no estado do sistema;

Sada Agentes_E_Eventos.Especificar, quando houver, eventos gerados ao final da operao juntamente com osdestinatrios dos mesmos. Portanto, uma lista com todos os agentes e os eventos que aoperao deve lhes enviar. Cada Agente_E_Evento engloba o nome de um agente e todosos eventos que lhe possam ser enviados;

Pr-condies Condio.Introduz predicado (lista de clusulas) que define condies a serem assumidas para que aoperao possa ser executada. Todas/cada clusula deve ser True para que o predicado sejasatisfeito (E lgico). Referencia apenas parmetros ou partes do estado que tenham sidodefinidos em Reads e Changes;

Ps-condies Condio.Introduz predicado (lista de clusulas) que define os resultados (alteraes no estado dosistema e/ou eventos de sada) aps a execuo da operao. Relaciona estado do sistemaantes e depois de ter sido ativada a operao. Palavras-reservadas initial e final podempreceder um identificador quando da necessidade de especificar o estado do sistema antes eaps a execuo da operao.

Figura 3.4 Esquema de Operao com recursos UML para Contratos


3.5 - Modelo de Objetos do Sistema (Modelo Conceitual)Um modelo de objetos apresenta um modelo do domnio do problema. Assim, as classes e os

relacionamentos podem especificar conceitos pertencentes ao ambiente do sistema, bem como os inerentesao prprio sistema.

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



relacionado ao sistema a ser construdo. Este modelo ser derivado do Modelo de Objetos excluindo-seas classes e relacionamentos que pertenam unicamente ao ambiente do sistema e no ao prprio sistema[Coleman, 1996].

Atividades e DependnciasO Modelo de Objetos do Sistema est diretamente vinculado ao Modelo de Objetos, devendo-se

tambm observar informaes de requisitos que identifiquem agentes do sistema, como Cenrios eModelo de Operaes.

Estratgias para ModelagemObservando-se os Cenrios e os Modelos de Operaes, deve-se filtrar os Modelos de Objetos de

forma a manter apenas objetos necessrios prpria estrutura interna do sistema. O mtodo Fusionorientava para que fosse criada uma espcie de fronteira, atravs de uma linha pontilhada, delimitando osobjetos do sistema e os agentes. No entanto, com a UML poderemos utilizar a notao paraagentes/atores, atravs de bonecos-palito, e os objetos que no forem nem agentes nem objetos do sistema,sero excludos deste novo modelo.

Notaes para ModelagemAs notaes para o Modelo de Objetos do Sistema sero padro UML onde a nica diferena da

notao do Diagrama de Classes UML (ver seo 3.3) a substituio de algumas classes-agentes porbonecos-palito na funo de atores/agentes, sendo este ltimo padro dos Diagramas de Use Case (verseo 2.3).


3.6 - Verificao dos Modelos da Fase de AnliseSeguindo as orientaes de [Coleman, 1996], nesta seo sero apresentadas algumas diretrizes para

a verificao dos modelos de anlise no que se refere inteireza e consistncia em relao aosrequisitos.

Inteireza com requisitos: releia com cuidado o documento de requisitos e resolva quaisquer dvidascom o cliente/usurios. Em seguida, verifique se:

Todos os cenrios possveis foram tratados pelo ciclo de vida;Todas as operaes do sistema foram definidas com o uso de um esquema de operaes;Todas as informaes estticas foram capturadas pelo modelo de objetos do sistema;Todas as outras informaes esto documentadas no glossrio de termos.Consistncia: essas verificaes relacionam-se com a sobreposio entre os modelos de anlise.

Verifique se:Todas as classes, relacionamentos e atributos mencionados no modelo de operaes aparecem nomodelo de objetos do sistema. Todos os outros conceitos devem estar definidos no glossrio de



termos ou em alguma outra fonte de referncia;A fronteira do modelo de objetos do sistema consistente com a interface do sistema fornecida pelomodelo ciclo-de-vida;Todas as operaes do sistema, presentes no modelo ciclo-de-vida, possuem um esquema deoperaes;Todos os identificados utilizados em todos modelos se encontram do glossrio de termos.



4. Fase de ProjetoA fase de Projeto caracteriza-se por transformar as informaes modeladas durante a fase de Anlise

em estruturas arquiteturais de projeto com o objetivo de viabilizar a implementao do sistema. Asinformaes da fase de Projeto caracterizam a modelagem dinmica do sistema, principalmente em termosdos objetos necessrios s operaes atravs da troca de mensagens entre os mesmos. Ao final da fase deProjeto busca-se ter uma estrutura hierrquica de classes e o refinamento do Modelo de Objetos doSistema da fase de Anlise, o que ir caracterizar os requisitos essenciais passagem para a fase deImplementao.Os objetivos da fase de Projeto passam pela construo inicial dos Grafos de Interao de Objetos, a partirdo qual so modeladas as operaes do sistema atravs da troca de mensagens entre os objetos.Posteriormente o Modelo de Objetos do Sistema poder ser refinado de forma a viabilizar a estruturahierrquica de classes, ao final do projeto, prevendo o incio da implementao.

A figura 4.1 oferece uma visualizao, atravs de use cases, da estrutura a ser modelada durante afase de Projeto.

Figura 4.1 Fase de Projeto

4.1 - Conduo da Fase de ProjetoA fase de Projeto deve ser conduzida buscando transformar as informaes da fase de Anlise em

estruturas arquiteturais de projeto com o objetivo de viabilizar a implementao do sistema. Asinformaes da fase de Projeto caracterizam a modelagem dinmica do sistema principalmente em termosdos objetos necessrios s operaes atravs da troca de mensagens entre os mesmos.



Tudo o que foi analisado deve ser observado para se iniciar a fase de Projeto, onde deve-se construiras estruturas dinmicas de trocas de mensagens entre os objetos necessrias para satisfazer os Modelos deOperaes da fase de Anlise. Assim, para a modelagem dos Grafos de Interao de Objetos devero serobservados os Modelos de Objetos do Sistema, o Modelo de Operaes e o Modelo de Ciclo de Vida.

Modelagem Fusion: Grafos de Interao de Objetos: utilizar notaes padro UML do Diagrama deColaborao;

Ao final da fase de Projeto deve haver uma espcie de lapidao das estruturas de classes de forma ase otimizar os Modelos de Objetos do Sistema. Isto ser feito melhorando estes modelos atravs derelacionamentos de agregao e atravs da montagem de uma estrutura hierrquica de classes feita atravsde associaes de generalizao e especilizao, estas ltimas comumente conhecidas como Grafos deHerana dentro do mtodo Fusion.

Modelagem Fusion: Refinamento do Modelo de Objetos do Sistema: utilizar notaes padro UML doDiagrama de Classes; Grafos de Herana: utilizar notaes padro UML para estrutura de Herana do Diagramade Classes;

4.2 - Grafos de Interao de ObjetosA abordagem dos Grafos de Interao de Objetos visa representar a troca de mensagens entre os

objetos para satisfazer as operaes modeladas na fase de Anlise. Deve ser desenvolvido um Grafo deInterao de Objetos para cada operao modelada no sistema.

Abaixo segue um esquema com a notao a ser utilizada para a modelagem destes grafos, o qualadota o padro UML para Diagramas de Colaborao.

Atividades e DependnciasA modelagem das trocas de mensagens entre os objetos depende diretamente da observao dos

Modelos de Operaes, do Modelo de Objetos do Sistema e do Modelo Ciclo de Vida em um segundoplano. A principal colaborao dos GIO sero os mtodos que os objetos passaro a ter aps suamodelagem o que fornece a estrutura dinmica do sistema em projeto.

Estratgias para ModelagemO primeiro passo para modelar as interaes entre os objetos partir Modelos de Operaes,

geralmente com as operaes tendo o mesmo nome dos eventos de entradas do Modelo Ciclo de Vida. Apartir da, deve ser gerado um GIO para cada Modelo de Operao. Assim sendo, cada clusula doModelo de Operaes dever ser observada buscando as informaes necessrias para a modelagem dosGIO, conforme descrito abaixo.




Figura 4.2 Grafos de Interao de Objetos com notaes UML de Diagramas de Colaborao


4.3 - Refinamento do Modelo de Objetos do SistemaO Modelo de Objetos do Sistema, inicialmente construdo na fase de Anlise e delimitado ao

domnio do sistema, deve agora ser refinado de forma a melhorar o significado e a visualizao de suasestruturas.

Usaremos de dois mecanismos para melhorar nossos modelos, sendo as associaes de Agregao eHerana, conforme descrito abaixo.

4.3.1 AgregaesA Agregao 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 outraclasse, podendo possuir atributos e participar de relacionamentos.

Atividades e DependnciasA identificao das agregaes depende diretamente dos Modelos de Objetos do Sistema j

construdos at ento, podendo tambm ser necessrio consultar documentos de requisitos para reconhecercaractersticas de agregao.

Estratgias para ModelagemUma orientao bastante til para se identificar agregaes diz respeito anlise da expresso

(geralmente contendo um verbo) existente no relacionamento entre classes que esto prestes a se



agregarem. Em geral a agregao modela relacionamentos "parte de" ou "contm um". Portanto, umaclasse que est associada a outra atravs de um relacionamento do tipo "has a" forte cadidata agregao. Assim sendo, uma forma de se identificar este tipo de associao , alm dos requisitos deobjetos, identificar nos relacionamentos verbos ou expresses verbais como: tem um, contm um, est em, parte de, ...

Notaes para ModelagemA modelagem das Agregaes utiliza de uma notao grfica especfica, eliminando-se o nome doverbo/expresso verbal relativa associao que est sendo substituda.

Figura 4.3 Agregao como parte da notao UML do Diagrama de Classes


4.3.2 Herana - Estrutura Hierrquica de ClassesA Herana um tipo de relacionamento onde a classe que herda (subclasse/subtipo) possui todas as

propriedades da classe herdada (superclasse/supertipo), podendo tambm possuir outras mais, o que noslevar a construir uma Estrutura Hierrquica de Classes, objetivando-se assim a reutilizao de classes emoutros projetos.

Atividades e DependnciasA identificao das Estruturas de Herana tambm depende diretamente dos Modelos de Objetos do

Sistema j construdos at ento, sendo necessrio consultar as mesmas Estruturas j construdas edocumentos de requisitos para reconhecer caractersticas de herana, s vezes tambm citadas comogeneralizaes/especializaes.



Estratgias para ModelagemA orientao para se identificar generalizaes/especializaes (herana) semalhante usada para

identificar agregaes e diz respeito anlise da expresso (geralmente contendo um verbo) existente norelacionamento entre classes envolvidas. A generalizao modela relacionamentos "tipo de" ou " um".Portanto, uma classe que est associada a outra atravs de um relacionamento do tipo "king of" ou "is a" forte cadidata a se tornar subclasse de outra (superclasse).

Notaes para ModelagemA modelagem de Herana utiliza de uma notao grfica especfica, tambm eliminando-se o nome doverbo/expresso verbal relativa associao que est sendo substituda.

Figura 4.4 Herana como parte da notao UML do Diagrama de Classes


4.4 - "Visibilidade"O Documento

4.5 - Verificao dos Modelos da Fase de ProjetoNesta seo apresenta-se orientaes para a verificao dos modelos de projeto em relao

especificao da fase de anlise e s funcionalidades do sistema, conforme [Coleman, 1996].Consistncia com a especificao do sistema: verificar que somente as classes representadas nos

grafos de interao de objetos sejam consideradas como parte do modelo de objetos do sistema paraposterior implementao. Novas classes podero ser introduzidas durante a fase de projeto sem que sejammostradas no modelo de objetos do sistema desenvolvido durante a anlise.



Verificao do efeito funcional: Verificar se o efeito funcional de cada grafo de interao de objetos satisfaz especificao da suaoperao definida no modelo de operaes.

Verificar se todas as clusulas Result do esquema de operaes encontram-se satisfeitas.Refinamento do modelo de objetos do sistema: Verificar se as associaes originais do modelo de objetos do sistema foram devidamenteconvertidas, quando possvel, em estruturas de agregao e generalizao para otimizao dorespectivo modelo.



5. Fase de ImplementaoA fase de Projeto de nosso trabalho ter como caracterstica transformar as informaes modeladas

durante a fase de Projeto em estruturas de cdigo no formato de prottipos de classes de objetos.Considerando que a modelagem dos Grafos de Interao de Objetos permitiu a especificao dos

mtodos 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 cdigo-fonte relativo s estruturas dosobjetos em termos de seus atributos e mtodos.

A proposta deste trabalho a flexibilidade, orientando apenas para que seja gerado cdigo com asintaxe de uma linguagem de programao orientada a objetos. Os exemplos sero construdos em C++ ouem Java, dependendo da comodidade em relao s atividades desenvolvidas no curso.

A figura 5.1 oferece uma visualizao, atravs de use cases, da estrutura a ser modelada durante afase de Projeto.

Figura 5.1 Fase de Implementao

5.1 - Conduo da Fase de ImplementaoA fase de Implementao deve ser conduzida observando-se os modelos construdos principalmente



durante a fase de Projeto juntamente com as especificaes contidas no Glossrio de Termos. Lembra-seque sero montados prottipos estruturais das classes de objetos projetadas, os quais estaro formadospelo nome da classe, seus atributos e tipos e as assinaturas dos mtodos.

Modelagem: No h regras notacionais para a estruturao das classes, sugerindo-se apenas o uso da sintaxe de umalinguagem de programao orientada a objetos.

5.2 - Gerao dos Prottipos e Estruturas de Classes de ObjetosA estruturao das classes de objetos ser feita codificando-se estas classes em linguagem de

programao orientada a objetos, escrevendo-se seus atributos e assinaturas de mtodos, semnecessariamente implementar estes ltimos.

Atividades e DependnciasA codificao das estruturas de classes poder ser feita unicamente observando-se os modelos

gerados na fase de Projeto. Para quaisquer outras informaes pode ser necessrio consultar o Glossriode Termos.

Estratgias para ModelagemPara que sejam identificadas quais classes sero implementadas, deve-se observar quais delas so

necessrias s operaes do sistema. Portanto, os Grafos de Interao de Objetos fornecem a informaosobre quais classes implementar. Considerando, contudo, que houve o refinamento do Modelo de Objetosdo Sistema aps a construo dos GIO, provavelmente a tarefa de selecionar as classes a seremimplementadas j pode ter sido feita, isto , atravs da excluso, do MOS, das classes desnecessrias soperaes. Assim sendo, bastar observar o Modelo de Objetos do Sistema.

Portanto, os atributos podem ser identificados no Modelo de Objetos do Sistema e/ou Glossrio deTermos e os mtodos nos Grafos de Interao de Objetos, caso ainda no tenham sido atualizados noModelo de Objetos do Sistema.

5.3 - Verificao das Estruturas de Classes de ObjetosPara checar as estruturas de classes, algumas verificaes bsicas sero teis:Atributos de Dados: verificar que todos os atributos de dados do Modelo de Objetos do Sistema

apaream nas estruturas de classes;Atributos Objeto: em geral as estruturas de agregao identificadas nos Modelos de Objetos do

Sistema daro origem a atributos objeto;Mtodos e Parmetros: garantir que todos os mtodos e argumentos dos Grafos de Interao de

Objetos apaream nas estruturas de classes;Herana: verificar que todas as estruturas de herana estejam registradas; garantir que as estruturas

de classes contenham todos os mtodos comuns preliminarmente definidos, respeitando as estruturas deherana.



6. ConclusesA proposta de adaptao do Fusion para a UML ainda um trabalho em andamento, considerando

que ainda existem modelos que no encontram similares na atual verso da UML. No entanto, os objetivosesto sendo alcanados com as atuais trocas de notaes.

O balano final do trabalho pode considerar que dos praticamente oito modelos/tcnicasdesenvolvidos pelo Fusion, j se conseguiu adaptar totalmente cinco deles. Cita-se o mapeamentocompleto do Modelo de Objetos, o Modelo de Interfaces, enquanto tratamento dos Cenrios e dos Modelode Operaes, o Modelo de Objetos do Sistema, o Grafo de Interao de Objetos e os Grafos de Herana.Enquanto adaptaes parciais, considera-se em vias de concluso o mapeamento do Modelo Ciclo deVida. Por fim, cita-se tambm o estudo do Diagrama de Componentes da UML para adaptao fase deImplementao do Fusion, podendo vir a auxiliar o gerenciamento dos processos de codificao dosistema de software.

Portanto, os resultados do trabalho somente no so totais em virtude dos Grafos de Visibilidade,pois no caso das Descries de Classes as mesmas so direcionadas especificamente para cdigo-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. Anlise Baseada em Objetos. Rio de Janeiro: Campus, 1992.COLEMAN, D. et All. Desenvolvimento Orientado a Objetos - O Mtodo 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, 1991JACOBSON, I., CHRISTERSON, M., JONSSON, P. & VERGAARD, G. Object-Oriented Software

Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.LARMAN, Craig. Utilizando UML e Padres Uma Introduo Anlise e ao Projeto Orientados a

Objetos. Porto Alegre: Editora Bookman, 2000.MARTIN, J. & ODELL, J. J. Anlise e Projeto Orientados a Objeto. So Paulo: MakronBooks, 1995.PAGE-JONES, M. O que Todo Programador Deveria Saber Sobre Projeto Orientado a Objeto. So Paulo:

MakronBooks, 1997.PENKER, M. & ERIKSSON, H-E. UML Toolkit. John Wiley, 1997.PRESSMAN, R. S. Engenharia de Software. So Paulo, MakronBooks, McGraw-Hill, 1995.RUMBAUGH, J. et all. Object-Oriented Modeling and Design. Prentice-Hall, 1991.SHLAER, S. & MELLOR, S. J. Anlise de Sistemas Orientada para Objetos. So Paulo: McGraw-Hill,

1990.WINBLAD, A. L. et alii. Software Orientado a Objeto. So Paulo: Makron Books, 1993.BECK, Kent. & CUNNINGHAM, W. A Laboratory For Teaching

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



Apndice A - Estudo de Caso MiniBib (Biblioteca Departamental)