Uml

UNISUL UNIVERSIDADE DO SUL DE SANTA CATARINA
PR-REITORIA ACADMICA
CENTRO DE CINCIAS EXATAS, AGRRIAS E DAS ENGENHARIAS
CURSO DE CINCIA DA COMPUTAO
PESQUISA E DESENVOLVIMENTO EM UML
ALEXANDRE DE ALMEIDA
REGINALDO DAROLT
ARARANGU SC
2001

PESQUISA E DESENVOLVIMENTO EM UML
ALEXANDRE DE ALMEIDA
REGINALDO DAROLT
Projeto apresentado disciplina de

Projetos em Cincia da Computao II,
coordenado pelo Professor Luciano
Savio
orientado
Alessandro Zanini.
ARARANGU SC
2001
pelo
Professor
ii
TERMO DE APROVAO
PROJETO DE CONCLUSO DE CURSO
Aprovamos o Projeto PESQUISA E DESENVOLVIMENTO EM UML, elaborado

pelos alunos ALEXANDRE DE ALMEIDA e REGINALDO DAROLT,
apresentado com requisito parcial para a obteno de Grau em Bacharel em
Cincia da Computao.
Prof. Carlos Fernando Buss

Coord. do Curso de Cincias da Computao
Banca de Avaliao
Prof. Luciano Savio

Coordenador de PCC
Prof. Alessandro Zanini

Orientador
Prof. Ana Cludia G. Barbosa

Convidada
Prof. Juarez Bento Da Silva

Convidado
ARARANGU SC
2001
iii
Dedicamos este Trabalho a nossos pais, namoradas e familiares que

sempre nos apoiaram e estiveram a nosso lado em todos os momentos.
iv
AGRADECIMENTOS
A Deus.
A todos os colegas e professores, em especial Alessandro Zanini,
Ana Claudia, Rafael vila Faraco, Luciano Savio e Carlos Fernando Buss, os
quais nos incentivaram e deram apoio no desenvolvimento deste Projeto.
As empresas Seara Alimentos S/A, Domnio Sistemas Ltda e Betha
Sistemas Ltda, em especial ao colega Cristiano Tomasi(Betha Sistemas Ltda).
SUMRIO
LISTA DE FIGURAS ............................................................................................ xii

RESUMO............................................................................................................. xiv
ABSTRACT.......................................................................................................... xv
Captulo 1 - INTRODUO ................................................................................... 1
1.1 Apresentao ............................................................................................ 1
1.2 Objetivos Geral e Especficos ................................................................... 2
1.3 Justificativa................................................................................................ 3
1.4 Abrangncia .............................................................................................. 4
1.5 Metodologia............................................................................................... 4
1.6 Estrutura ................................................................................................... 5
Captulo 2 - ANLISE E PROJETOS ORIENTADOS A OBJETOS ..................... 8
2.1 Conceito.................................................................................................... 8
2.2 Anlise Orientada a Objetos ..................................................................... 9
2.3 Projeto Orientado a Objetos.................................................................... 10
2.4 Classes ................................................................................................... 11
2.5 Objetos.................................................................................................... 11
2.6 Abstrao ................................................................................................ 12
vi
2.6.1 Abstrao de Procedimentos ........................................................... 12
2.6.2 Abstrao de dados.......................................................................... 12
2.7 Encapsulamento ..................................................................................... 13
2.8 Herana .................................................................................................. 13
2.9 Polimorfismo ........................................................................................... 14
Captulo 3 - UML ................................................................................................. 15
3.1 Introduo ............................................................................................... 15
3.2 Histrico .................................................................................................. 16
3.3 Aceitao ................................................................................................ 18
3.4 Padronizao OMG................................................................................. 19
3.5 Aplicao ................................................................................................ 19
Captulo 4 - ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML ....... 20
4.1 Anlise de Requisitos.............................................................................. 20
4.2 Anlise .................................................................................................... 21
4.3 Projeto..................................................................................................... 21
4.4 Programao........................................................................................... 22
4.5 Testes ..................................................................................................... 23
Captulo 5 - FERRAMENTAS CASE................................................................... 24
5.1 Conceito.................................................................................................. 24
5.2 Vantagens............................................................................................... 26
5.3 Aceitao no Mercado ............................................................................ 27
5.4 O Futuro .................................................................................................. 28
5.5 Rational Rose.......................................................................................... 28
Captulo 6 - VISES DE SISTEMAS................................................................... 30
6.1 Conceito.................................................................................................. 30
vii
6.2 Viso USE-CASE.................................................................................... 31
6.3 Viso Lgica............................................................................................ 31
6.4 Viso de Componentes........................................................................... 32
6.5 Viso de concorrncia............................................................................. 32
6.6 Viso de Organizao............................................................................. 33
Captulo 7 - MODELOS DE ELEMENTOS.......................................................... 34
7.1 Definio ................................................................................................. 34
7.2 Classes ................................................................................................... 35
7.2.1 Nomes .............................................................................................. 36
7.2.2 Atributos ........................................................................................... 37
7.2.3 Operaes ........................................................................................ 38
7.3 Objetos.................................................................................................... 39
7.4 Estados ................................................................................................... 40
7.5 Pacotes ................................................................................................... 42
7.6 Componentes.......................................................................................... 43
7.7 Relacionamentos .................................................................................... 43
7.7.1 Associaes ..................................................................................... 44
7.7.1.1 Associaes Normais .................................................................... 44
7.7.1.2 Associaes Recursivas ................................................................ 45
7.7.1.3 Associaes Qualificadas .............................................................. 46
7.7.1.4 Associaes Exclusivas ................................................................. 46
7.7.1.5 Associaes Ordenadas ................................................................ 47
7.7.1.6 Associaes de Classe .................................................................. 47
7.7.1.7 Associaes Ternrias................................................................... 48
7.7.1.8 Agregao...................................................................................... 49
viii
7.7.2 Generalizaes................................................................................. 50
7.7.2.1 Generalizao Normal ................................................................... 50
7.7.2.2 Generalizao Restrita .................................................................. 51
7.7.3 Dependncias e Refinamentos ........................................................ 52
7.8 Mecanismos Gerais ................................................................................ 53
Captulo 8 - DIAGRAMAS ................................................................................... 55
8.1 Conceito.................................................................................................. 55
8.2 Diagramas de Casos de Uso .................................................................. 56
8.3 Diagramas de Classes ............................................................................ 57
8.4 Diagramas de Objetos ............................................................................ 59
8.5 Diagramas de Estados............................................................................ 61
8.6 Diagramas de Seqncia........................................................................ 62
8.7 Diagramas de Colaborao .................................................................... 63
8.8 Diagramas de Atividade .......................................................................... 64
8.9 Diagramas de Componentes .................................................................. 65
8.10 Diagramas de Implantao ................................................................... 66
Captulo 9 - METODOLOGIA DESENVOLVIDA................................................. 68
9.1 Introduo ............................................................................................... 68
9.2 Documentao ........................................................................................ 69
9.2.1 Fonte ................................................................................................ 69
9.2.2 Gravao da Documentao ............................................................ 70
9.2.3 Extenso de Arquivos....................................................................... 71
9.2.4 Impresso......................................................................................... 71
9.2.5 Backup ............................................................................................. 72
9.2.6 Controle de Verses......................................................................... 72
ix
9.3 Eventos Iniciais ....................................................................................... 73
9.3.1 Contatos ........................................................................................... 74
9.3.2 Estudo dos Dados ............................................................................ 74
9.3.3 Definio dos Participantes .............................................................. 75
9.4 Anlise de requisitos ............................................................................... 76
9.4.1 Reunio/Entrevista ........................................................................... 76
9.4.2 Preenchimento da ata da reunio..................................................... 79
9.4.3 Definies de responsabilidades ...................................................... 79
9.4.4 Resumo do Projeto........................................................................... 79
9.4.5 Atores ............................................................................................... 80
9.4.6 Casos de Uso ................................................................................... 80
9.4.7 Escopo ............................................................................................. 81
9.4.8 Diagrama de caso de uso................................................................. 82
9.4.9 Anlise de riscos .............................................................................. 82
9.4.10 Cronograma ................................................................................... 83
9.4.11 Aprovao ...................................................................................... 84
9.5 Anlise .................................................................................................... 84
9.5.1 Diagrama de Classes ....................................................................... 84
9.5.2 Diagrama de Objetos........................................................................ 85
9.5.3 Diagramas de Interao ................................................................... 86
9.5.3.1 Diagrama de Seqncia ................................................................ 87
9.5.3.2 Diagrama de Colaborao ............................................................. 88
9.5.4 Diagrama de Estado......................................................................... 89
9.5.5 Diagrama de Atividade ..................................................................... 89
9.6 Projeto..................................................................................................... 90
x
9.6.1 Diagrama de implementao............................................................ 91
9.6.1.1 Diagrama de componente.............................................................. 91
9.6.1.2 Diagrama de implantao .............................................................. 93
9.7 Implementao........................................................................................ 95
9.7.1 Traduo .......................................................................................... 95
9.7.2 Escolha da Linguagem ..................................................................... 95
9.7.3 Documentao do Cdigo ................................................................ 97
9.8 Testes ..................................................................................................... 99
9.8.1 Planejamento de Testes................................................................... 99
9.8.2 Execuo de Testes ....................................................................... 100
9.8.2.1 Teste de Unidade......................................................................... 100
9.8.2.2 Teste de Integrao ..................................................................... 102
9.8.2.3 Teste de Validao ...................................................................... 103
9.8.2.4 Teste de Sistemas ....................................................................... 104
9.8.3 Avaliao dos Resultados .............................................................. 104
Captulo 10 - Validao da Metodologia ......................................................... 106
10.1 Introduo ........................................................................................... 106
10.2 Formulrio de Documentao ............................................................. 106
10.3 Contatos Iniciais.................................................................................. 107
10.4 Ata da Reunio ................................................................................... 108
10.5 Resumo do Projeto ............................................................................. 109
10.6 Escopo ................................................................................................ 110
10.7 Lista de Casos de Uso ........................................................................ 111
10.8 Diagrama de Caso de Uso .................................................................. 112
10.9 Diagrama de Classes.......................................................................... 113
xi
10.10 Escolha da Linguagem...................................................................... 114
Captulo 11 - RESULTADOS OBTIDOS ........................................................... 115
Captulo 12 - CONCLUSO .............................................................................. 119
12.1 Recomendaes ................................................................................. 120
Captulo 13 - BIBLIOGRAFIA ........................................................................... 121
xii
LISTA DE FIGURAS
Figura 2.1 : Anlise Orientada a Objeto............................................................ 10

Figura 2.2 : Projeto Orientado a Objetos .......................................................... 11
Figura 6.1 : Vises de Sistemas ........................................................................ 31
Figura 7.1 : Classes ............................................................................................ 36
Figura 7.2 : Nomes ............................................................................................. 37
Figura 7.3 : Atributos.......................................................................................... 38
Figura 7.4 : Operaes ....................................................................................... 39
Figura 7.5 : Objetos ............................................................................................ 40
Figura 7.6 : Estados............................................................................................ 41
Figura 7.7 : Pacotes............................................................................................ 42
Figura 7.8 : Componentes.................................................................................. 43
Figura 7.9 : Associaes Normais .................................................................... 45
Figura 7.10 : Associaes Recursiva................................................................ 46
Figura 7.11 : Associaes Qualificadas ........................................................... 46
Figura 7.12 : Associaes Exclusivas .............................................................. 47
Figura 7.13 Associaes de Classe .................................................................. 48
Figura 7.14 : Associaes Ternrias................................................................. 48
xiii
Figura 7.15 : Agregao ..................................................................................... 49
Figura 7.16 : Agregao Compartilhada ........................................................... 49
Figura 7.17 : Agregao de Composio ......................................................... 49
Figura 7.18 : Generalizao Normal .................................................................. 50
Figura 7.19 : Generalizao de Sobreposio ................................................. 51
Figura 7.20 : Generalizao Completa .............................................................. 52
Figura 7.21 : Relao de Dependncia ............................................................. 52
Figura 7.22 : Refinamentos................................................................................ 53
Figura 7.23 : Ornamentos e Nota ...................................................................... 54
Figura 8.1 : Diagramas de Casos de Uso ......................................................... 57
Figura 8.2 : Diagramas de Classes ................................................................... 59
Figura 8.3 : Diagramas de Objeto...................................................................... 60
Figura 8.4 : Diagramas de Estados ................................................................... 62
Figura 8.5 : Diagramas de Seqncia ............................................................... 63
Figura 8.6 : Diagramas de Colaborao ........................................................... 64
Figura 8.7 : Diagramas de Atividade ................................................................. 65
Figura 8.8 : Diagramas de Componentes ......................................................... 66
Figura 8.9 : Diagramas de Implantao ............................................................ 67
Figura 10.1 Escopo do Sistema....................................................................... 111
Figura 10.2 Diagrama de Caso de Uso do Sistema de Contabilidade.......... 113
Figura 10.3 Diagrama de Classes do Sistema de Contabilidade.................. 114
xiv
RESUMO
Usar uma metodologia de desenvolvimento de sistema para captar

desde os primeiros contatos, at a concluso das etapas de desenvolvimento
de software, de extrema importncia. A UML(Unified Modeling Language) a
juno das trs mais conceituadas linguagens de modelagem orientados a
objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh), porm
a UML no possui um mtodo de trabalho a ser seguido.
Este trabalho estuda a UML para que se possa criar uma
metodologia de desenvolvimento de sistemas que englobe todas as fases do
processo, desde os eventos iniciais, passando pela Anlise de Requisitos,
Anlise, Projeto, Programao e Testes.
Para a validao da metodologia desenvolvida ser aplicada no
desenvolvimento de um prottipo. Utilizaremos a ferramenta case Rational
Rose, da Rational Software Corporation no apoio a modelagem do sistema.
Ao final do desenvolvimento de cada fase sero feitas observaes
que serviro de concluso e base para futuros melhoramentos.
xv
ABSTRACT
To use a metodology of system development to obtain since the first

contacts until the final version is very important. The UML (Unified Modeling
Language) is the junction of three most respected language of model oriented
for objects (Booch of Grady, OOSE of Jacobson and OMT of Rumbaugh)
[Booch,2001], but the UML doesnt have a work metod to be follwed.
The paper studies the UML in order to create a metodology of
system development that joints all the steps of the process, since the first
events, passing through the Analysis of Requisites, Analysis, Project,
Programming and Tests.
For the validation of the developed metodology well aplicate on the
development of a prototype, where it will be used the instrument Rational Rose,
of Ratonal Software Corporation, to support the system model.
By the end of the development of each phasis, will be made
observations that will serve as conclusion and basis for future improvement.
Captulo 1 - INTRODUO
1.1 Apresentao
Um grande problema no desenvolvimento de novos sistemas

utilizando a orientao a objetos o fato de no existir uma notao
padronizada e realmente eficaz que possa abranger qualquer tipo de aplicao.
Cada metodologia existente possui suas prprias notaes (smbolos usados
para projetar modelos orientados a objetos), processos e ferramentas. Isso faz
com que a escolha do mtodo a ser utilizado torne-se uma deciso
extremamente importante e freqentemente leva a discusses e debates sobre
qual o melhor mtodo, o mais avanado e adequado para ser utilizado em um
projeto especfico.
Com
lanamento
da
UML
(Unified
Modeling
Language)
desenvolvedores da rea de orientao a objetos, ficaram entusiasmados com

sua abrangncia. Pois a UML traz novos conceitos que normalmente no so
usados. Um bom entendimento da UML no somente um conhecimento de
2
sua smbologia e significados, mas tambm um contexto geral de modelagem
orientada a objetos.
Com a juno das trs mais conceituadas metodologias(Booch de
Grady, OOSE de Jacobson e o OMT de Rumbaugh) de modelagem orientado
a objetos criou-se a UML aproveitando o que havia de melhor em cada uma
delas adicionando conceitos e vises da linguagem. UML permite comunicar
certos conceitos mais claramente que as linguagens alternativas [Fowler,
2000].
A UML uma padronizao de modelagem orientado a objetos de
forma que qualquer sistema, seja qual for o tipo, possa ser modelado
corretamente, com consistncia, fcil de se comunicar com outras aplicaes,
simples de ser atualizado e compreensvel.
Com este projeto pretendemos justamente pesquisar sobre esta
linguagem de modelagem, suas aplicaes, vantagens e desvantagens. Como
conseqncia
dessa
pesquisa
definiremos
uma
metodologia
de
desenvolvimento de sistemas baseada em UML, a qual analisamos ser o mais

eficaz s necessidades atuais de desenvolvimento.
1.2 Objetivos Geral e Especficos
Objetivamos com esta pesquisa o estudo aprofundado de uma

metodologia unificada de desenvolvimento de sistemas orientado a objetos
baseado em UML, com a perspectiva de desenvolver uma metodologia e
aplic-la
desenvolvendo um prottipo,
funcionalidade.
comprovando
sua
eficincia
3
Especificamente, os objetivos apresentados so:
Obter amplos conhecimentos sobre UML;
Mostrar a sociedade a importncia do uso de uma metodologia no

desenvolvimento de sistemas;
Estudar como se desenvolve uma metodologia de desenvolvimento de

sistemas;
Desenvolver uma metodologia de trabalho baseado em UML;
Estudo de uma ferramenta CASE, para modelagem do sistema.
Desenvolvimento de um prottipo usando a metodologia;
Apresentao do prottipo desenvolvido.
1.3 Justificativa
Com as constantes inovaes que surgem em ferramentas de

desenvolvimento de sistemas orientados a objetos e a necessidade de
desenvolvimento de sistemas mais complexos e precisos, faz com que um
estudo sobre uma metodologia unificada de desenvolvimento torne-se um
grande atrativo a ser pesquisado.
Com este interesse, desenvolveremos o presente projeto com o
intuito de apresentar a analistas uma metodologia de desenvolvimento e
salientar a importncia de sua aplicao, a qual poder resolver muitos
problemas encontrados no decorrer de todo o desenvolvimento de um sistema.
Para isto ser desenvolvido um prottipo utilizando-se desta metodologia.
1.4 Abrangncia
A UML tende a ser uma linguagem de desenvolvimento de sistemas

orientado a objetos dominante, comum entre os melhores analistas e
desenvolvedores. Por conseqncia este projeto pretende comprovar a eficcia
do uso desta metodologia, com base no desenvolvimento de um prottipo.
Destacamos os principais tpicos :
A modelagem de sistemas (no apenas de software) usando os
conceitos da orientao a objetos;
Estabelecer uma unio fazendo com que mtodos conceituais sejam
tambm executveis;
Estabelecer um mtodo de comunicao entre toda a equipe
envolvida (cliente, analista, desenvolvedor, etc);
Mostrar a sociedade a qualidade de um sistema desenvolvido com o
uso da UML.
1.5 Metodologia
Para o desenvolvimento do Trabalho de Concluso de Curso (TCC),

sero definidas as seguintes etapas:
Estudo da metodologia UML;
Conceitos sobre esta metodologia;
Aprimoramento da metodologia usada, visando sua melhor performance;
Estudo e definio de uma ferramenta CASE que melhor atenda a essa

metodologia;
Estudo e definio de ferramentas para desenvolvimento do sistema;
Escolha de um sistema para aplicao da metodologia estudada

comprovando sua eficcia;
Desenvolvimento de um prottipo do sistema;
Concluso sobre a metodologia estudada e sua aplicao.
1.6 Estrutura
Este captulo apresentar a voc leitor, uma breve descrio de

cada captulo que constitui este trabalho.
No captulo 2 descreveremos um breve conceito da anlise e

projetos orientado a objetos bem como sua necessidade, surgimento, etc.
Faremos uma descrio da base da anlise e projetos orientado a objetos
descrevendo seus pontos principais como classes, objetos, abstraes, etc.
Este captulo importante para o entendimento da anlise orientada a objetos.
O captulo 3 faz uma introduo UML(Linguagem Unificada de

Modelagem) dizendo o que ela nos disponibiliza, sua aceitao, padronizao
e aplicaes. Para um melhor entendimento do processo de criao da UML
apresentaremos um histrico completo, desde o incio das pesquisas at a
concluso da ltima verso.
O captulo 4 descreve as etapas tcnicas da UML, baseada nos

conceitos tradicionais das atividades de desenvolvimento. Estas etapas vo
desde os primeiros passos(Anlise de Requisitos) at a fase de testes.
O captulo 5 faz uma descrio sobre ferramenta CASE, apresenta

algumas vantagens da aplicao desta ferramenta e tambm descreve sua
aceitao no mercado. Ao final deste captulo ainda apresentamos uma viso
do futuro desta ferramenta.
No captulo 6 apresentado um conceito sobre vises em UML e

qual a importncia destas vises para o entendimento do sistema. Descreve-se
ainda em detalhes as 5(cinco) vises utilizadas e o uso de cada uma destas
vises.
O captulo 7 traz uma definio de modelos de elementos e

descreve detalhadamente todos os modelos de elementos utilizados pela UML,
tais
como
Classes,
Objetos,
Estados,
Pacotes,
Componentes
Relacionamentos.
O captulo 8 apresenta um conceito genrico sobre diagramas em

UML, descreve detalhadamente os 9(nove) tipos de diagramas utilizados pela
UML, exemplificando graficamente e indicando o uso de alguns tipos de
diagramas.
7
No captulo 9 apresentaremos a metodologia desenvolvida.
O captulo 10 mostra um prottipo desenvolvido aplicando a

metodologia do captulo anterior.
No captulo 11 mostraremos os resultados obtidos durante a

validao de cada fase da metodologia.
No captulo 12 faremos nossas concluses sobre todo o TCC.
captulo
13
desenvolvimento do TCC.
apresenta
toda
bibliografia
utilizada
no
Captulo 2 - ANLISE E PROJETOS ORIENTADOS A

OBJETOS
2.1 Conceito
Com os enormes computadores da dcada de 1950 e 1960, e a

pouca capacidade de processamento, desenvolvedores de programas tinham
que aproveitar ao mximo todo bit que o hardware disponibilizava. J na
dcada de 1960 computadores transistorizados foram surgindo, o que na
poca j era um grande avano, substituindo os enormes computadores de
vlvulas.
Desenvolvedores mais radicais afirmavam que os algoritmos para os
sistemas que esses computadores rodavam
tinham que ser monolticos. Ou
seja, se j se chegou na melhor fase do algoritmo no necessrio mais

alteraes ou manutenes, ficando do mesmo jeito at deixar de ser usado.
Desenvolvedores menos radicais e com uma viso um pouco
diferente, afirmavam que os sistemas tinham que ser modularizados para que
9
fossem de mais fcil manuteno e compreenso. Este conceito foi mais aceito
a medida que os computadores foram aumentando sua capacidade.
Precursores da analise orientada a objeto, defendiam que devamos
estruturar programas de computador de acordo com o problema a ser
resolvido. O termo Orientao a Objetos sugere abstraes do mundo real e
trechos de programas de computador, ou objeto.
Um grande fator da orientao a objetos a reusabilidade. Estamos
reutilizando cdigos de programas desde o incio da computao. As tcnicas
de orientao a objetos nos permitem muito mais que a reutilizao de cdigos,
podemos reutilizar requisitos, anlise, projeto, planejamento de testes,
interfaces de usurio e arquiteturas, ou seja todos os componentes de
engenharia de software podem ser encapsulados como reutilizveis.
2.2 Anlise Orientada a Objetos
Anlise o estudo de um problema, antes de qualquer ao [De

Marco, 1978]
Anlise o estudo do domnio de um problema que leva a uma
especificao
de
comportamentos
observveis
externamente.
uma
declarao completa, consistente e possvel do que necessrio, um conjunto

de caractersticas operacionais quantificadas e funcionais.
Analisar obter as necessidades de um sistema e o que este
precisa ser desenvolvido para satisfazer as necessidades do usurio. Analisar
no definir como o sistema ser desenvolvido, mas sim investigar o problema
conforme mostra a Figura 2.1.
10
A AOO tem dois propsitos. Primeiramente formalizar uma viso
do mundo real dentro do qual o sistema ser desenvolvido, estabelecendo os
objetos que serviro como principais estruturas organizacionais do sistema de
software e tambm as que o mundo real impe. Em segundo lugar, a AOO
formaliza a colaborao de um dado conjunto de objetos na execuo do
trabalho do sistema de software que est sendo especificado. Esta
formalizao representa como cada objeto se comunica com os demais.
Figura 2.1 : Anlise Orientada a Objeto
2.3 Projeto Orientado a Objetos
O Projeto Orientado a Objetos (PjOO) visto como o processo de

especificao das partes da
construo, ou seja, instrues,
recomendaes, estipulaes, qualificaes, regras, etc..
guias,
Utilizamos estes
processos para implementar um sistema em um ambiente especfico, em busca

da soluo do problema conforme mostra a Figura 2.2.
11
Durante a PjOO dado nfase na elaborao dos elementos lgicos
do software [Larman, 2000]. Sendo implementados em uma linguagem de
programao orientada a objetos, os quais possuem atributos e mtodos.
Figura 2.2 : Projeto Orientado a Objetos
2.4 Classes
Uma Classe em linguagens Orientadas a Objetos a possibilidade

de combinar num nico registro, campos de dados e campos que so funes
para operar os campos de dados do registro [Furlan, 1998].
2.5 Objetos
Um objeto simplesmente alguma coisa que faz sentido no contexto

de uma aplicao [Rumbaugh, 1994]. Objeto uma entidade independente,
assncrona e concorrente, armazena dados, encapsula servios, troca
12
mensagens com outros objetos, e modelado para executar as funes finais
do sistema.
2.6 Abstrao
Abstrao o princpio de ignorar os aspectos de um assunto no

relevante para o propsito em questo, tornando possvel uma concentrao
maior nos assuntos principais [Cood, 1991]. Consiste na seleo que o analista
faz de alguns aspectos, ignorando outros. Existem duas formas de abstrao,
de Procedimentos e de Dados.
2.6.1 Abstrao de Proc edimentos

Princpio de que qualquer operao com um efeito bem definido
pode ser tratada por seus usurios como uma entidade nica, mesmo que a
operao seja realmente conseguida
atravs de alguma seqncia de
operaes de nvel mais baixo.
2.6.2 Abstrao de dado s

Consiste em definir um tipo de dado conforme as operaes
aplicveis aos objetos deste tipo. Porm, estes objetos s podem ser
modificados e observados atravs destas operaes.
13
2.7 Encapsulamento
Encapsular omitir informaes pelo princpio de que uma

determinada entidade esconde informaes as quais so necessrias apenas
mesma. fundamental que o objeto proteja seus dados, no permitindo que o
usurio do objeto os acesse diretamente. Mas sim atravs de mtodos se
houver necessidade[Furlan, 1998].
2.8 Herana
Esta provavelmente a caracterstica mais discutida da abordagem

orientada a objetos [Mazzola, 1999].
principal
caracterstica
do
processo
de
Generalizao/Especializao. Atravs da herana uma determinada subclasse herda todos os atributos e mtodos da superclasse.
Permite a um analista especificar servios e atributos comuns uma
s vez, assim como especializar e estender estes atributos e servios em
casos especficos.
14
2.9 Polimorfismo
o conceito usado em linguagens de programao orientada a

objetos para denotar a caracterstica de que a linguagem suporta a utilizao
do mesmo identificador (o mesmo nome) para mtodos de classes diferentes.
Um conceito em teoria de tipo no qual
um nome (como uma
declarao de varivel) pode denotar objetos de muitas subclasses diferentes

que so relacionadas por alguma superclasse comum, assim, qualquer objeto
denotado por esse nome tem a capacidade de responder a algum conjunto
comum de operaes de modos diferentes [Booch, 2000].
Captulo 3 - UML
3.1 Introduo
A UML a linguagem padro para especificar, visualizar,

documentar e construir artefatos de um sistema e pode ser utilizada com todos
os processos ao longo do ciclo de desenvolvimento e atravs de diferentes
tecnologias de implementao [Furlan, 1998].
A UML disponibiliza uma forma padro de modelagem de projetos
de Sistemas, incluindo seus aspectos conceituais tais como processos de
negcios e funes do sistema, alm de itens concretos como as classes
escritas em determinada linguagem de programao, processos de banco de
dados e componentes de software reutilizveis.
16
3.2 Histrico
As linguagens de modelagem orientadas a objetos surgiram entre a

metade da dcada de 1970 e o final da dcada de 1980, medida que o
pessoal envolvido com metodologia, diante de um novo gnero de linguagens
de programao
orientadas a objeto e de aplicaes cada vez mais
complexas, comeou a experimentar mtodos alternativos de anlise e projeto.

A quantidade de mtodos orientados a objetos aumentou de pouco mais de 10
para mais de 50 durante o perodo de 1989 a 1994. Muitos usurios desses
mtodos tiveram dificuldades para encontrar uma linguagem de modelagem
capaz de atender inteiramente s suas necessidades. Destacaram-se algumas
linguagens como o Booch, o OOSE (Object-Oriented Software Engineering) de
Jacobson, e o OMT (Object Modeling Technique) de Rumbaugh. Podemos citar
outros mtodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon.
Todos eram mtodos completos, alguns se destacavam em algum ponto,
porm tinham suas limitaes. O mtodo Booch destacava-se durante as fases
de projeto e construo de sistemas, o OOSE fornecia excelente suporte para
captura de requisitos, a anlise e o projeto em alto nvel; o OMT-2 era mais til
com a anlise e sistemas de informaes com uso de dados[Booch, 2000].
Na metade da dcada de 1990, Grady Booch (Rational Software
Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics)
criadores de mtodos orientados a objetos, comearam a pegar as melhores
idias e partiram para a criao de uma linguagem unificada de modelagem.
Com isso esperavam fornecer ao mercado uma linguagem mais concreta e
madura com os quais os desenvolvedores de ferramentas pudessem criar uma
17
ferramenta mais utilizvel. Usando tcnicas orientadas a objeto criariam uma
linguagem que iria desde o conceito at o sistema executvel, no somente a
sistemas complexos mas tambm a sistemas menores e tambm a outros
problemas que no fossem sistemas de informao, podendo ser utilizado por
seres humanos e mquinas[Furlan, 1998].
A criao da UML iniciou oficialmente em outubro de 1994, quando
Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a
unificao dos mtodos Booch e OMT[Furlan, 1998]. O esboo da verso 0.8
do Mtodo Unificado foi lanado em outubro de 1995. Mais ou menos na
mesma poca Jacobson se associou Rational com a finalidade de incorporar
o OOSE no escopo inicial da verso 0.8, resultando o lanamento da verso
0.9 da UML em junho de 1996[Booch, 2000]. Foi ento aprovada pela
comunidade de engenharia de software em geral. Muitas empresas ficaram
interessadas, foi ento criada um consrcio com vrias empresas interessadas
em dedicar recursos com o propsito de trabalhar uma definio mais forte e
completa da UML.
Empresas que contriburam para a definio da UML 1.0, Digital
Equipment Corporationm Hewlett-Packard, I-Logix, Intel-licorp, IBM, ICON
Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments
e Unisys. Resultando uma linguagem de modelagem bem definida , expressiva,
poderosa, e que poderia ser aplicada a uma grande variedade de tipos de
problemas[Booch, 2000]. A UML foi oferecida para a OMG (Object
Management Group) em janeiro de 1997, em resposta solicitao do prprio
OMG de propostas para uma linguagem padro de modelagem[Furlan, 1998].
18
Entre janeiro a julho de 1997, o grupo original se expandiu,
passando a incluir virtualmente todos os participantes e colaboradores da
resposta inicial ao OMG, entre os quais se encontravam Andersen Consulting,
Ericson, Object Time Limited, Platinum Technology, Ptech, Reich Technologies,
Softeam, Sterling Software e Taskon. Um grupo foi formado, liberado por Cris
Kobryn da MCI Systemhouse e administrado por Ed Eykholt da Rational, com o
propsito de formalizar a especificao da UML e de integrar a linguagem a
outros esforos de padronizao. A verso 1.1 foi entregue a OMG em julho de
1997. Em setembro do mesmo ano, essa verso foi aceita pela ADTF (Analysis
and Design Task Force) e pelo Architecture Board do OMG e, posteriormente
submetida a votao de todos os membros da OMG. A verso 1.1 foi adotada
pela OMG em 14 de novembro de 1997[Booch, 2000].
A manuteno da UML foi ento assumida pela RTF (Revision Task
Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lanou uma
reviso editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF
lanou a UML 1.3[Furlan, 1998].
3.3 Aceitao
Os criadores da UML procuraram desenvolver uma linguagem

unificada padro que pudesse ser de fcil entendimento a todos. Preocuparamse em deix-la aberta aos desenvolvedores, onde os mesmos pudessem criar
seu prprio mtodo de trabalho.
Empresas desenvolvedoras de ferramentas esto livres para criarem
uma ferramenta aqueda ao uso da UML. Devido a necessidade de criao da
19
UML empresas e profissionais liberais da rea esto desenvolvendo estudos
para melhor aplic-la.
3.4 Padronizao OM G
Quando se iniciaram os trabalhos para criao da UML, os criadores

tinham como inteno fazer sua aceitao com a distribuio da linguagem a
vrios desenvolvedores.
A OMG (Object Management Group) fez um requerimento por uma
linguagem de modelagem padro. Ento houve interesse dos criadores da
UML em padroniz-la, para isso foi preciso que os mesmos aprimorassem a
qualidade da linguagem para tal. Pois para serem realmente utilizadas por
empresas era necessrio sua padronizao.
3.5 Aplicao
A UML pode ser usada para modelar vrias fases de um sistema,

desde os primeiros contatos at a gerao do cdigo. aplicada em qualquer
tipo de sistemas em termos de diagramas de orientao a objeto.
Geralmente mais usada na modelagem de Softwares usando o
conceito de orientao a objetos, mas tambm pode ser aplicada em sistemas
mecnicos, de engenharia em geral, pode tambm ajudar na organizao de
processos de uma organizao.
Captulo 4 - ETAPAS DO DESENVOLVIMENTO DE

SISTEMAS EM UML
4.1 Anlise de Requis itos
Esta fase captura as intenes e necessidades dos usurios do

sistema a ser desenvolvido atravs do uso de funes chamadas "use-cases"
[Barros, 2001]. a descrio das necessidades ou desejos de um determinado
sistema. O princpio bsico da anlise de requisitos identificar e documentar o
que realmente necessrio, desta forma comunicando a todos os envolvidos
no projeto da forma mais clara possvel, de maneira no-ambgua de modo que
os riscos sejam identificados sem correr riscos de imprevistos.
Atravs do desenvolvimento de casos de uso(em UML chamamos
de use-cases), as entidades externas ao sistema (em UML chamamos de
"atores externos") que interagem e possuem interesse no sistema so
modelados entre as funes que eles requerem, funes estas chamadas de
"use-cases". Os atores externos e os "use-cases" so modelados com
21
relacionamentos que possuem comunicao associativa entre eles ou so
desmembrados em hierarquia. Descrevemos um use-case atravs de um
texto especificando os requisitos do ator externo que utilizar este use-case.
Um use-case tanto pode depender de um ou mais use-case como pode ter
seus dependentes. Atravs do diagrama de use-cases mostraremos aos
atores externos(futuros usurios) o que estes podem esperar do sistema.
A anlise de requisitos tambm pode ser desenvolvida baseada em
sistemas de negcios, e no apenas para sistemas de software
4.2 Anlise
A fase de anlise preocupa-se com as primeiras abstraes(classes

e objetos) e mecanismos presentes no contexto do problema[Larman, 2000].
Descrevemos as classes nos Diagramas de Classes e tambm para ajudar na
descrio dos use-cases, podendo estas estar ligados uma nas outras
atravs de relacionamentos.
Nesta fase modelamos somente as classes que pertencem ao
domnio principal do problema, ou seja, classes tcnicas mais detalhadas no
estaro neste diagrama.
4.3 Projeto
Projeto cria uma representao do domnio de problema do mundo

real e leva-a a um domnio de soluo que o software [Pressman, 1995].
22
Nesta fase partimos para as solues tcnicas, atravs dos
resultados obtidos na fase da anlise. Sero adicionadas novas classes para
oferecer uma infra-estrutura tcnica tais como: interface do usurio e
perifricos, banco de dados, interao com outros sistemas, e outras mais.
feita uma juno das classes da fase da anlise com as classes tcnicas da
nova infra-estrutura, podendo assim alterar tanto o domnio principal do
problema quanto a infra-estrutura.
Com a elaborao do projeto obtemos detalhadamente as
especificaes para dar inicio a fase de programao.
4.4 Programao
Para que uma fase de programao possa ter um bom desempenho,

necessitamos de um projeto bem elaborado, consequentemente converteremos
as classes da fase do projeto para o cdigo da linguagem orientada a objetos
escolhida. Se o desenho foi elaborado corretamente e com detalhes
suficientes, a tarefa de codificao facilitada [Furlan, 1998].A complexidade
dessa converso vai depender da capacidade da linguagem escolhida, no
entanto esta pode tornar-se fcil ou difcil de se realizar.
Em UML durante a elaborao dos modelos de anlise e projeto,
devemos evitar traduzi-los em cdigos. Cabendo esta tarefa fase de
programao.
23
4.5 Testes
Na fase de teste executamos um programa com a inteno de

descobrir um erro[Pressman, 1995]. Testamos cada rotina ou processo
detalhadamente, bem como a integrao de todos os processos e a aceitao.
As rotinas devem ser testadas de duas formas, uma pelos programadores,
pois estes tem um conhecimento das classes e grupo de classes que envolvem
esta rotina, sabendo desta forma onde esto os pontos mais crticos que
podem causar falhas. A outra forma de testes de uma rotina feita por outro
usurio, pois este ir fazer um teste do seu modo, tendo a viso da rotina como
um todo. Os testes de integrao so feitos usando as classes e seus
componentes de integrao para verificar se estas classes esto realmente
colaborando uma com as outras conforme especificado nos
modelos. Nos
testes de aceitao verificado se o sistema est de acordo com o

especificado no diagramas de use-cases.
Por fim, o sistema ser testado pelo usurio final e este verificar se
os resultados apresentados esto realmente de acordo com suas intenes
expressas no incio do projeto.
Captulo 5 - FERRAMENTAS CASE
5.1 Conceito
O termo CASE(Computer-Aided Software Engineering) significa

Engenharia de Software Auxiliada por Computador. Antigamente, os analistas
desenvolviam software para outras reas (como Engenharia, Arquitetura,
Medicina, etc) mas no se utilizavam de software para fazer seu trabalho.
Tinham necessidade de visualizar o projeto como um todo, ao invs de analislo em partes. difcil de acreditar que ferramentas de software to simples
estejam ficando cada vez mais importantes nos dias de hoje [Cood, 1991].
Com a crescente demanda pela qualidade e integrao de
softwares, e tambm pela unificao de planejamentos administrativos com a
anlise, projeto e gerao de sistemas, surgiu ento as denominadas
Ferramentas Case.
25
Uma Ferramenta Case um software que auxilia no ciclo de
desenvolvimento de um sistema desde a fase de anlise at a fase de testes,
auxiliando tambm na manuteno do sistema.
Apoiam na utilizao de metodologias e mtodos, armazenam
informaes em sua base de dados, tanto em forma de textos como em forma
grfica, possibilitando a comunicao com o usurio, a aprovao das
definies de processos, fluxos de informaes e atributos de entidades, no
esquecendo de nenhum passo da metodologia usada, proporcionando alto
nvel de documentao.
As ferramentas CASE se dividem em 3 tipos:
Integrated System CASE (I-CASE) , que visam desde a anlise/projeto at a

gerao do cdigo. Tentam abranger tudo, porm "superlota" uma etapa
com vrios tipos de sub-ferramentas com a inteno de abranger vrias
metodologias.
Case's de automao de uma fase(ou mais) de desenvolvimento, so

ferramentas que se prendem a uma etapa do desenvolvimento tal como
ferramentas de modelagem de dados(modelo de dados) e ferramentas de
testes (testes do sistema).
Ferramentas que seguem uma metodologia especifica, tal como antigo

Composer By IEF que seguia a engenharia da informao. O prprio
Rational Rose, segue como linha base a Orientao a Objetos.
26
5.2 Vantagens
Citamos algumas vantagens com a utilizao de Ferramentas CASE
Maior qualidade dos produtos finais: as ferramentas CASE diminuem a

probabilidade de erros, uma vez que podem ajudar no controle de
consistncia dos dados em um ambiente de desenvolvimento, tambm
proporcionam maior eficcia dos produtos, ao auxiliarem as fases de
Anlise e Teste do produto pelo usurio;
Produtividade: ao ajudar na realizao de tarefas e at mesmo ao realizar

algumas automaticamente, as ferramentas contribuem para uma maior
agilidade no desenvolvimento de software, isto , mais produtos em menos
tempo;
Eliminao de trabalho que muitas vezes no agregam valor ao produto

final: as ferramentas CASE podem realizar algumas tarefas cansativas para
os desenvolvedores, tais como procurar informaes e desenhar smbolos
de um diagrama, as quais so mais sucetveis ao erro;
Mais tempo para a tomada de deciso: em conseqncia de as ferramentas

realizarem certas atividades pelas pessoas, estas ficam liberadas para
outras tarefas, geralmente mais nobres, que exigem tomada de deciso e
criatividade, ao invs de tarefas repetitivas;
Flexibilidade para mudanas: as ferramentas permitem que sejam mudados

dados e diagramas de maneira mais rpida e fcil, o que ajuda o
desenvolvedor no trabalho de tentar satisfazer o usurio;
Menos programao: as ferramentas eliminam muito tempo do trabalho de

programao, deixando mais tempo para que a equipe tcnica se preocupe
27
com a Anlise do Sistema, que onde se define como solucionar o
problema do usurio;
Melhor
documentao:
por
armazenarem
dados
diagramas,
as
ferramentas tambm contribuem para uma melhor documentao do

sistema, agilizando relatrios, busca de informaes e alteraes;
Manuteno mais fcil e gil: por conseqncia do item anterior, possvel

ter mais informaes sobre o software na hora de realizar sua manuteno
(correo, atualizao ou expanso).
As Ferramentas Case nos auxiliam em todas as fases do projeto,
portanto seu uso de extrema importncia, considerando suas vantagens no

vemos outra sada para um projeto bem desenvolvido e documentado.
5.3 Aceitao no Mer cado
A aceitao de ferramentas CASE ocorreu com diagramas como o

DFD e o E-R, que s foram amplamente utilizados quando surgiram as
primeiras ferramentas para auxiliar na tarefa de diagramao.
Hoje em dia, h tambm a difuso do termo I-CASE, que usado
para caracterizar um grupo de ferramentas CASE integradas, isto , que se
relacionam entre si (entradas e sadas) e que permitem controlar a consistncia
dos dados quando seguimos uma metodologia.
28
5.4 O Futuro
Podemos dizer que as ferramentas CASE, evoluiro no de uma

forma fechada, mas de uma forma aberta de maneira que as mesmas cada vez
mais se integraro com outras ferramentas de fabricantes distintos.
A palavra de ordem dos CASE's de amanh diversidade e
especializao. O conceito de CASE's apenas se transformou. O conceito de
CASE de amanh nasceu hoje. Ou melhor, sofreu uma mutao mercadolgica
dado o poder dos fabricantes. Entender o conceito importante, mas entender
a evoluo do mesmo tambm importante.
5.5 Rational Rose
Rational Rose uma ferramenta CASE para desenvolvimento de

sistemas orientados a objetos, sendo tambm, um repositrio para os produtos
gerados por processos de anlise e projetos orientados a objetos. Ela acelera
esse desenvolvimento de anlise e projetos utilizando metodologias de
desenvolvimento muito difundidas no meio da informtica, principalmente o
padro Unified Modeling Language (UML). O padro UML o mais utilizado
hoje em dia, pois com ele h uma documentao interativa e automtica dos
processos de modelagem, sendo tambm possvel a gerao, pela ferramenta,
de cdigos a partir da mesma modelagem. As verses mais novas ferramenta
contemplam at a interao com ambientes de desenvolvimento das mais
variadas linguagens existentes no mercado [DBSERVER, 2001].
29
Por quatro anos consecutivos o IDC nomeou a Rational Rose como
a ferramenta principal de projeto e de construo baseada em anlise
orientada a objetos [DBSERVER, 2001].
Segundo RATIONAL, a ferramenta Rational Rose uma soluo
completa para [2001]:
Empresas e Analistas de Sistemas : Permite analistas visualizar e modelar

processos de empresas e requisitos de sistemas.
Projetos : Permite projetar modelos de sistemas baseados em UML

mantendo o sincronismo entre o cdigo e o projeto.
Modelagem de Banco de Dados e Anlise : Oferece em uma nica

ferramenta linguagem e notao para toda a equipe.
Desenvolvedores Web : Fornece suporte a XML, Java, EJB. Permite

visualizar a arquitetura da Web de forma compreensiva, at mesmo sites
mais complexos.
Desenvolvedores UNIX : Suporta a interoperabilidade completa entre UNIX

e Windows, oferece aos usurios UNIX a mesma interface do usurio
Windows e suporta os mesmos formatos de
arquivo,
permitindo
compartilhar modelos e projetos de desenvolvimento.
Para todos : O modelo integrado permite melhor o desempenho da equipe

de desenvolvimento. Conhecendo mais profundamente seus algoritmos, ir
gerar um bom resultado ao final do projeto.
Captulo 6 - VISES DE SISTEMAS
6.1 Conceito
O desenvolvimento de um sistema complexo no uma tarefa fcil.

O ideal seria que o sistema inteiro pudesse ser descrito em um nico grfico e
que este representasse por completo as reais intenes do sistema sem
ambigidades, sendo facilmente interpretvel [Barros, 2001].
Um sistema composto por diversos aspectos: funcional (que sua
estrutura esttica e suas interaes dinmicas), no funcional (requisitos de
tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais
(organizao do trabalho, mapeamento dos mdulos de cdigo, etc.).
Descrevemos um sistema em vrias vises, cada viso mostra alguma
particularidade do sistema e esto em alguns de diagramas.
Algumas vises esto interligadas atravs de diagramas, podendo
uma viso fazer parte de uma ou mais vises. Os diagramas que compem as
31
vises contm os modelos de elementos do sistema. A Figura 6.1 apresenta as
cinco vises de sistemas.
Figura 6.1 : Vises de Sistemas
6.2 Viso USE-CASE
Descreve a funcionalidade do sistema desempenhada pelos atores

externos do sistema (usurios). A viso use-case central, j que seu
contedo base do desenvolvimento das outras vises do sistema. Essa viso
montada sobre os diagramas de use-case e eventualmente diagramas de
atividade.
6.3 Viso Lgica
Descreve como a funcionalidade do sistema ser implementada.

feita principalmente pelos analistas e desenvolvedores. Em contraste com a
viso use-case, a viso lgica observa e estuda o sistema internamente. Ela
32
descreve e especifica a estrutura esttica do sistema (classes, objetos, e
relacionamentos) e as colaboraes dinmicas quando os objetos enviarem
mensagens uns para os outros para realizarem as funes do sistema.
Propriedades como persistncia e concorrncia so definidas nesta fase, bem
como as interfaces e as estruturas de classes. A estrutura esttica descrita
pelos diagramas de classes e objetos. O modelamento dinmico descrito
pelos diagramas de estado, seqncia, colaborao e atividade.
6.4 Viso de Compon entes
uma descrio da implementao dos mdulos e suas

dependncias. principalmente executado por desenvolvedores, e consiste
nos componentes dos diagramas.
6.5 Viso de concorr ncia
Trata a diviso do sistema em processos e processadores. Este

aspecto, que uma propriedade no funcional do sistema, permite uma melhor
utilizao do ambiente onde o sistema se encontrar, se o mesmo possui
execues paralelas, e se existe dentro do sistema um gerenciamento de
eventos assncronos. Uma vez dividido o sistema em linhas de execuo de
processos concorrentes (threads), esta viso de concorrncia dever mostrar
como se d a comunicao e a concorrncia destas threads. A viso de
concorrncia suportada pelos diagramas dinmicos, que so os diagramas
33
de estado, seqncia, colaborao e atividade, e pelos diagramas de
implementao, que so os diagramas de componente e execuo.
6.6 Viso de Organiza o
Finalmente, a viso de organizao mostra a organizao fsica do

sistema, os computadores, os perifricos e como eles se conectam entre si.
Esta viso ser executada pelos desenvolvedores, integradores e testadores, e
ser representada pelo diagrama de execuo.
Captulo 7 - MODELOS DE ELEMENTOS
7.1 Definio
Os conceitos usados nos diagramas so chamados de modelos de

elementos [Barros, 2001]. Um modelo de elemento definido com a semntica,
a definio formal do elemento com o exato significado do que ele representa
sem definies duvidosas ou ambguas e tambm define sua representao
grfica que mostrada nos diagramas da UML.
Um elemento pode existir em diversos tipos de diagramas, mas
existem regras que definem quais elementos podem ser mostrados em que
tipos de diagramas. Alguns exemplos de modelos de elementos so as
classes, objetos, estados, pacotes e componentes. Os relacionamentos
tambm so modelos de elementos, e so usados para conectar outros
modelos de elementos entre si.
35
7.2 Classes
As classes so os blocos de construo mais importantes de

qualquer sistema orientado a objetos [Booch, 2000].
Uma classe uma descrio de um conjunto de objetos que
compartilham os mesmo atributos, operaes, relacionamentos e semntica.
Podem ser implementadas em uma ou mais interfaces.
Todos os objetos so instncias de classes, onde a classe descreve
as propriedades e comportamentos daquele objeto.
Em UML as classes so representadas por um retngulo dividido em
trs compartimentos: o compartimento de nome, que conter apenas o nome
da classe modelada, o de atributos, que possuir a relao de atributos que a
classe possui em sua estrutura interna, e o compartimento de operaes, que
sero os mtodos de manipulao de dados e de comunicao de uma classe
com outras do sistema(ver Figura 7.1). A sintaxe usada em cada um destes
compartimentos independente de qualquer linguagem de programao,
embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
36
Figura 7.1 : Classes
7.2.1 Nomes
Todas as classes devem ter um nome que as diferencie das demais.
Usamos uma seqncia de caracteres para identific-las. Uma classe pode ter
um nome simples, ou com caminho como mostra a Figura 7.2. O caminho
identifica o pacote ao qual a classe pertence.
37
Figura 7.2 : Nomes
7.2.2 Atributos
Um atributo uma propriedade de uma classe, que descreve um
intervalo de valores que as instncias da propriedade podem apresentar. Uma
classe pode ter qualquer nmero de atributos ou nenhum. Um atributo
representa o tipo de dados ou estados que cada item de uma classe pode
assumir, so representados logo aps o nome da classe (veja Figura 7.3).
38
Figura 7.3 : Atributos
7.2.3 Operaes
Operaes so os processos que a classe pode realizar.
Operaes correspondem claramente a mtodos em uma classe. No
nvel de especificao, as operaes correspondem a mtodos pblicos.
Normalmente, voc no mostra as operaes que simplesmente manipulam
atributos, porque elas podem ser freqentemente inferidas. Entretanto, voc
poder ter que identificar seu um dado atributo somente para leitura(isto , o
seu valor nunca muda). No modelo de implementao, voc tambm pode
querer mostrar operaes privativas(private) e protegidas(protected).
Uma classe pode ter vrias operaes ou at mesmo nenhuma, so
representadas logo aps os atributos (veja Figura 7.4).
39
Figura 7.4 : Operaes
7.3 Objetos
Os objetos so elementos que podemos manipular, acompanhar seu

comportamento, criar, interagir com ele, ou at destrui-lo. Um objeto pode
existir no mundo real ou pode ser uma derivao de estudos da estrutura e
comportamento de outros objetos do mundo real. Corresponde a qualquer
coisa que tenha algum significado para uma dada aplicao [Mazzola,
1999].Por exemplo, uma mquina, uma organizao, ou negcio.
Em UML um objeto mostrado como uma classe s que seu nome
sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do
nome da classe, conforme mostra a Figura 7.5.
40
Figura 7.5 : Objetos
7.4 Estados
Um estado uma condio ou situao na vida de um objeto

durante a qual o objeto satisfaz alguma condio, realiza alguma atividade ou
aguarda um evento [Booch, 2000]. Todos os objetos possuem um estado que
significa o resultado de atividades executadas pelo objeto, normalmente este
estado determinado pelos valores dos atributos e ligaes com outros
objetos.
Um objeto muda de estado quando acontece algo, o fato do objeto
alterar o seu estado chamamos de evento. Analisando as mudanas de estado
que um objeto pode sofrer, podemos prever todos os possveis comportamento
de um objeto de acordo com os eventos que o mesmo possa sofrer.
Um estado pode ter trs compartimentos (veja Figura 7.6): Nome do
Evento, Atributos e Atividades.
41
Nome do Evento - mostra o nome do evento, geralmente este nome

descreve o que este estado realiza;
Atributos mostra as variveis de estado, onde os atributos do objeto em

questo pode ser listados e atualizados;
Atividades o compartimento de atividades onde podemos listar os

eventos e aes. Est dividido em trs eventos padres : Entrar, Sair e
Fazer.
Entrar : usado para definir atividades no momento em que o objeto
entra naquele estado;

Sair : usado para definir atividades que o objeto executa antes de
passar para o prximo estado;
Fazer : usado para definir atividades que o objeto executa enquanto
se encontra naquele estado.
Figura 7.6 : Estados
42
7.5 Pacotes
Pacote um mecanismo de propsito geral para organizar

elementos de modelo em grupos, podendo, inclusive, estar aninhando dentro
de outros pacotes(pacotes subordinados) [Furlan, 1998] (ver Figura 7.7).
Todos os modelos de elementos que so ligados ou referenciados
por um pacote so chamados de "Contedo do pacote". Um pacote possui
vrios modelos de elementos, e isto significa que estes no podem ser
includos em outros pacotes.
Figura 7.7 : Pacotes
Pacotes podem importar modelos de elementos de outros pacotes.

Quando um modelo de elemento importado, refere-se apenas ao pacote que
possui o elemento. Na grande maioria dos casos, os pacotes possuem
relacionamentos com outros pacotes. Embora estes no possuam semnticas
definidas para suas instncias. Os relacionamentos permitidos entre pacotes
so de dependncia, refinamento e generalizao (herana).
43
O pacote tem uma grande similaridade com a agregao. O fato de
um pacote ser composto de modelos de elementos cria uma agregao de
composio. Se este for destrudo, todo o seu contedo tambm ser.
7.6 Componentes
Um componente pode ser tanto um cdigo em linguagem de

programao como um cdigo executvel j compilado. Por exemplo, em um
sistema desenvolvido em Java, cada arquivo .java ou .class um componente
do sistema, e ser mostrado no diagrama de componentes que os utiliza. Veja
na Figura 7.8 a representao de componentes.
Figura 7.8 : Componentes
7.7 Relacionamentos
Os relacionamentos ligam classes/objetos entre si criando relaes

lgicas entre estas entidades [Barros, 2001]. Possumos trs tipos de
relacionamentos: associao, generalizao e Dependncia/Refinamentos.
44
Associao: uma conexo entre classes, e tambm significa que uma

conexo entre objetos daquelas classes. Em UML, uma associao
definida com um relacionamento que descreve uma srie de ligaes, onde
a ligao definida como a semntica entre as duplas de objetos ligados.
Generalizao: um relacionamento de um elemento mais geral e outro

mais especfico. O elemento mais especfico pode conter apenas
informaes adicionais. Uma instncia (um objeto uma instncia de uma
classe) do elemento mais especfico pode ser usada onde o elemento mais
geral seja permitido.
Dependncia e Refinamentos: Dependncia um relacionamento entre

elementos, um independente e outro dependente. Uma modificao um
elemento independente afetar diretamente elementos dependentes do
anterior. Refinamento um relacionamento entre duas descries de uma
mesma entidade, mas em nveis diferentes de abstrao.
7.7.1 Associaes
Associao uma relao que descreve um conjunto de vnculos
entre elementos de modelo [Furlan, 1998].Representa a ligao entre classes
ou objetos de classes, podendo ambas conhecer-se. Uma associao
definida em UML como relacionamento.
7.7.1.1 Associaes Norm ais

O tipo mais comum de associao apenas uma conexo entre
classes. representada por uma linha slida entre duas classes. A associao
45
possui um nome (junto linha que representa a associao), normalmente um
verbo, mas substantivos tambm so permitidos.
Pode-se tambm colocar uma seta no final da associao indicando
que esta s pode ser usada para o lado onde a seta aponta. Mas associaes
tambm podem possuir dois nomes, significando um nome para cada sentido
da associao (ver Figura 7.9).
Para expressar a multiplicidade entre os relacionamentos, um
intervalo indica quantos objetos esto relacionados na ligao. O intervalo pode
ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios
(1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel
expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrito
nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou
apenas 1).
Figura 7.9 : Associaes Normais
7.7.1.2 Associaes Recu rsivas

Podemos conectar uma classe a ela mesma, usando uma
associao recursiva, e ainda podemos representar a conexo entre dois
objetos, sendo os mesmos da mesma classe, conforme mostra a Figura 7.10.
46
Figura 7.10 : Associaes Recursiva
7.7.1.3 Associaes Quali ficadas

Associaes qualificadas so usadas com associaes de um para
vrios (1..*) ou vrios para vrios (*). O "qualificador" (identificador da
associao qualificada) especifica como um determinado objeto no final da
associao "n" identificado, e pode ser visto como um tipo de chave para
separar todos os objetos na associao. O identificador desenhado como
uma pequena caixa no final da associao junto classe de onde a navegao
deve ser feita (ver Figura 7.11).
Figura 7.11 : Associaes Qualificadas
7.7.1.4 Associaes Exclu sivas

Podemos encontrar em alguns modelos combinaes no vlidas.
Uma associao exclusiva uma restrio em duas ou mais associaes. Ela
especifica que objetos de uma classe podem participar de no mximo uma das
associaes em um dado momento. Uma associao exclusiva representada
47
por uma linha tracejada entre as associaes que so parte da associao
exclusiva, com a especificao "{ou}" sobre a linha tracejada.
Figura 7.12 : Associaes Exclusivas
Conforme figura 7.12 um contrato no pode se referir a uma pessoa

e a uma empresa ao mesmo tempo, significando que o relacionamento
exclusivo a somente uma das duas classes.
7.7.1.5 Associaes Orden adas

As associaes entre objetos podem ter uma ordem implcita. O
padro para uma associao desordenada ou seja no possui uma ordem
especfica. Podemos resolver este problemas usando a associao ordenada,
ajudando pois existem casos que a ordem precisa estar concisa para o
entendimento da associao. Podemos escrever est associao apenas como
{ordenada} junto a linha da associao.
7.7.1.6 Associaes de Cl asse

Uma classe pode ser associada a uma outra associao. Este tipo
de associao no conectada a nenhuma das extremidades da associao j
existente, mas na prpria linha da associao. Esta associao serve para se
adicionar informaes extra a associao j existente (ver Figura 7.13).
48
Figura 7.13 Associaes de Classe
A associao da classe Fila com a associao das classes Cliente e

Processo pode ser estendida com operaes de adicionar processos na fila,
para ler e remover da fila e de ler o seu tamanho. Se operaes ou atributos
so adicionados associao, ela deve ser mostrada como uma classe.
7.7.1.7 Associaes Tern rias

A associao ternria e a associao entre trs classes. Ela
mostrada como um grade losango (diamante) e ainda suporta uma associao
de classe ligada a ela, traaria-se, ento, uma linha tracejada a partir do
losango para a classe onde seria feita a associao ternria.
Figura 7.14 : Associaes Ternrias
Conforme mostra a Figura 7.14 a associao ternria especifica que

um cliente poder possuir 1 ou mais contratos e cada contrato ser composto
de 1 ou vrias regras contratuais.
49
7.7.1.8 Agregao
A agregao uma caso particular da associao, indica que uma
das classes do relacionamento uma parte, ou est contida em outra classe.
As palavras chaves usadas para identificar uma agregao so: "consiste em",
"contm", " parte de" (ver Figura 7.15).
Figura 7.15 : Agregao
Existem tipos especiais de agregao que so as agregaes

compartilhadas e as compostas.
Agregao Compartilhada: dita compartilhada quando uma das classes

uma parte, ou est contida na outra, mas esta parte pode estar contida na
outra vrias vezes em um mesmo momento (ver Figura 7.16).
Figura 7.16 : Agregao Compartilhada
Agregao de Composio: uma agregao onde uma classe que est

contida na outra "vive" e constitui a outra. Se o objeto da classe que contm
for destrudo, as classes da agregao de composio sero destrudas
juntamente j que as mesmas fazem parte da outra (ver Figura 7.17).
Figura 7.17 : Agregao de Composio
50
7.7.2 Generalizaes
Um relacionamento de taxinomia entre um elemento mais geral e um
elemento mais especfico que completamente consistente com o primeiro
elemento somando-o informao adicional especializado [Furlan, 1998].
Um objeto mais especfico pode ser usado como uma instncia do
elemento mais geral. A generalizao, tambm chamada de herana, permite a
criao de elementos especializados em outros.
Existem alguns tipos de generalizaes que variam em sua
utilizao a partir da situao. So elas: generalizao normal e restrita. As
generalizaes restritas se dividem em generalizao de sobreposio,
disjuntiva, completa e incompleta.
7.7.2.1 Generalizao Nor mal

Na generalizao normal a classe mais especfica, chamada de
subclasse, herda tudo da classe mais geral, chamada de superclasse (ver
Figura 7.18). Os atributos, operaes e todas as associaes so herdadas.
Figura 7.18 : Generalizao Normal
Uma classe pode ser tanto uma subclasse quanto uma superclasse,
se ela estiver numa hierarquia de classes que um grfico onde as classes
esto ligadas atravs de generalizaes.
A generalizao normal representada por uma linha entre as duas
classes que fazem o relacionamento, sendo que coloca-se uma seta no lado da
linha onde encontra-se a superclasse indicando a generalizao.
51
7.7.2.2 Generalizao Res trita

Uma restrio aplicada a uma generalizao especifica informaes
mais precisas sobre como a generalizao deve ser usada e estendida no
futuro. As restries a seguir definem as generalizaes restritas com mais de
uma subclasse:
Generalizaes
de
Sobreposio
Disjuntiva:
Generalizao
de
sobreposio significa que quando subclasses herdam de uma superclasse

por sobreposio, novas subclasses destas podem herdar de mais de uma
subclasse (ver Figura 7.19). A generalizao disjuntiva exatamente o
contrrio da sobreposio e a generalizao utilizada como padro.
Figura 7.19 : Generalizao de Sobreposio
Generalizaes Completa e Incompleta: Uma restrio simbolizando que

uma generalizao completa significa que todas as subclasses j foram
especificadas, e no existe mais possibilidade de outra generalizao a
partir daquele ponto (ver Figura 7.20). A generalizao incompleta
exatamente o contrrio da completa e assumida como padro da
linguagem.
52
Figura 7.20 : Generalizao Completa
7.7.3 Dependncias e Re finamentos

Uma dependncia indica a ocorrncia de um relacionamento
semntico entre dois ou mais elementos do modelo onde uma classe cliente
dependente de alguns servios da classe fornecedora, mas no tem uma
dependncia estrutural interna com esse fornecedor [Furlan, 1998].
Uma mudana no elemento independente ir afetar o modelo
dependente. Como no caso anterior com generalizaes, os modelos de
elementos podem ser uma classe, um pacote, um use-case e assim por diante.
Quando uma classe recebe um objeto de outra classe como parmetro, uma
classe acessa o objeto global da outra. Nesse caso existe uma dependncia
entre estas duas classes, apesar de no ser explcita.
Uma relao de dependncia simbolizada por uma linha tracejada
com uma seta no final de um dos lados do relacionamento. E sobre essa linha
o tipo de dependncia que existe entre as duas classes. Conforme mostra a
figura 7.21, as classes "Amigas" provenientes do C++ so um exemplo de um
relacionamento de dependncia.
Figura 7.21 : Relao de Dependncia
53
Os refinamentos so um tipo de relacionamento entre duas
descries de uma mesma coisa, mas em nveis de abstrao diferentes e
podem ser usados para modelar diferentes implementaes de uma mesma
coisa (uma implementao simples e outra mais complexa, mas tambm mais
eficiente).
Os refinamentos so simbolizados por uma linha tracejada com um
tringulo no final de um dos lados do relacionamento e so usados em modelos
de coordenao (ver Figura 7.22). Em grandes projetos, todos os modelos que
so feitos devem ser coordenados. Coordenao de modelos pode ser usada
para mostrar modelos em diferentes nveis de abstrao que se relacionam e
mostram tambm como modelos em diferentes fases de desenvolvimento se
relacionam.
Figura 7.22 : Refinamentos
7.8 Mecanismos Gera is
A UML utiliza alguns mecanismos em seus diagramas para tratar

informaes adicionais.
Ornamentos: ornamentos grficos so anexados aos modelos de

elementos em diagramas e adicionam semnticas ao elemento. Um
exemplo de um ornamento o da tcnica de separar um tipo de uma
instncia. Quando um elemento representa um tipo, seu nome mostrado
em negrito. Quando o mesmo elemento representa a instncia de um tipo,
54
seu nome escrito sublinhado e pode significar tanto o nome da instncia
quanto o nome do tipo. Outros ornamentos so os de especificao de
multiplicidade de relacionamentos, onde a multiplicidade um nmero ou
um intervalo que indica quantas instncias de um tipo conectado pode estar
envolvido na relao.
Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem
importar o quanto extensa ela seja. Para permitir adicionar informaes a
um modelo no poderia ser representado de outra forma, UML prov a
capacidade de adicionar Notas. Uma Nota pode ser colocada em qualquer
lugar em um diagrama, e pode conter qualquer tipo de informao (ver
Figura 7.23).
Figura 7.23 : Ornamentos e Nota
Captulo 8 - DIAGRAMAS
8.1 Conceito
Quando voc faz modelagem, voc simplifica a realidade para um

melhor entendimento do sistema em desenvolvimento. Em UML voc
desenvolve seus modelos a partir de blocos distintos tais como : classes,
interfaces,
colaboraes,
componentes,
dependncias,
generalizaes,
associaes, etc. Os diagramas so meios utilizados para visualizao de

blocos de construo [Booch, 2000].
Os diagramas utilizados pela UML so compostos de nove tipos:
diagramas de casos de uso, classes, objetos, estados, sequncia, colaborao,
atividade, componentes e execuo. A seguir trataremos cada um destes tipos
de diagramas. Os exemplos utilizados para apresentar os diagramas foram
retirados de livros utilizados neste projeto e de material encontrado na internet.
56
8.2 Diagramas de Cas os de Uso
Um diagrama de caso de uso ilustra um conjunto de casos de uso

para um sistema, os atores e a relao entre os atores e os casos de uso
[Larman, 2000].
Os casos de uso so usados para modelar como um sistema ou
empresa funciona, ou como os usurios desejam que ele funcione. Os casos
de uso geralmente so o ponto de partida da anlise orientada a objetos
utilizando a UML.
O modelo de caso de uso consiste de atores e casos de uso. Os
atores representam usurios e outros sistemas que interagem com sistema
modelado. Eles so representados graficamente por um homem palito. Os
casos de uso mostram o comportamento do sistema, cenrios que o sistema
percorre em resposta ao estmulo de um ator. Eles so desenhados como
elipses conforme mostra a Figura 8.1.
No modelo de caso de uso o relacionamento entre um ator e um
caso de uso representa a participao deste ator no caso de uso. Alm deste
relacionamento, existe dois outros tipos de relacionamentos entre casos de
uso:
o relacionamento estender: representado graficamente por uma seta com

o esteretipo <<extends>>, mostrando que o caso de uso destino pode
incluir o comportamento especificado pelo caso de uso origem;
o relacionamento usar: representado por uma seta com o esteretipo

<<uses>>, mostrando que o caso de uso origem inclui o comportamento
especificado pelo caso de uso destino.
57
A figura 8.1 mostra um diagrama de casos de uso.
Figura 8.1 : Diagramas de Casos de Uso
8.3 Diagramas de Cla sses
uma estrutura lgica esttica em uma superfcie de duas

dimenses mostrando
uma coleo de elementos declarativos de modelo,
como classes, tipos e seus respectivos contedos e relaes [Furlan, 1998]

(ver Figura 8.2).
58
Uma classe em UML representada por uma caixa retangular com
trs compartimentos: um com o nome da classe, o outro com a lista de
atributos da classe e o ltimo com a lista de operaes da classe.
As associaes representam relacionamentos estruturados entre
objetos de diferentes classes, e so representados graficamente atravs de
uma linha conectando as classes. Uma associao pode ter um nome. E as
extremidades da linha que representa uma associao pode ter nome de
papis mostrando como a classe vista pelas outras classes na associao.
A multiplicidade de uma associao especifica quantas instncias de
uma classe relacionam-se a uma nica instncia de uma classe associada.
Uma multiplicidade representada por um intervalo de valores possveis, no
seguinte formato: limite_inferior..limite_superior, onde esses limites so valores
inteiros ( o caracter * pode ser usado como limite_superior para indicar falta de
limite).
A agregao uma forma especial de associao que representa o
relacionamento todo-parte entre objetos. Ela representada incluindo-se um
losango na extremidade do objeto todo do relacionamento todo-parte.
A generalizao uma ferramenta poderosa para a abstrao. A
generalizao um relacionamento existente entre uma classe mais
geral(superclasse) e uma classe mais especfica(subclasse), onde a classe
mais especfica consistente com a mais geral e adiciona informaes a ela.
Uma generalizao representada por uma linha com um tringulo, que liga a
classe mais especfica a mais genrica. Veja figura 8.2.
59
Figura 8.2 : Diagramas de Classes
8.4 Diagramas de Ob jetos
Os diagramas de objetos fazem a modelagem de instncias de itens

contidos em diagramas de classes. Um diagrama de objetos mostra um
conjunto de objetos e seus relacionamentos em determinado ponto no tempo.
Estes
diagramas
no
so
importantes
apenas
para
visualizao,
especificao e documentao de modelos estruturais, mas tambm para a

construo de aspectos estticos de sistemas por meio de engenharia de
produo e engenharia reversa [Booch, 2000] (ver Figura 8.3).
A UML permite a utilizao de diagramas de classes para uma
visualizao dos aspectos estticos dos blocos de construo do sistema. Voc
usa os diagramas de interao para visualizar os aspectos dinmicos de seu
60
sistema, formados por instncias desses blocos de construo e mensagens
enviadas entre eles. Os diagramas de objetos cobrem um conjunto de
instncias dos itens encontrados nos diagramas de classes. O diagramas de
objetos, portanto, expressa a parte esttica de uma interao, composta pelos
objetos que colaboram entre si, mas sem qualquer uma das mensagens
passadas entre eles. Nos dois casos, o diagrama de objetos congela um
momento no tempo.
Os diagramas de objetos so usados para fazer a modelagem da
viso de projeto esttica ou da viso de processo esttica de um sistema, da
mesma forma como faz com os diagramas de classes, mas a partir da
perspectiva de instncias reais ou prototpicas. Isso envolver a modelagem de
um retrato do sistema em determinado momento e a representao de um
conjunto de objetos, seus estados e relacionamentos. Essa viso atende
principalmente aos requisitos funcionais do sistema ou seja, os servios que
o sistema dever proporcionar aos seus usurios finais. Os diagramas de
objetos permitem que voc faa a modelagem de estruturas de dados
estticos.
Figura 8.3 : Diagramas de Objeto
61
8.5 Diagramas de Est ados
Os
diagramas
de
estados
so
usados
para
modelar
comportamento dinmico de um sistema. Mostram o ciclo de vida de um objeto

em nveis de detalhe arbitrariamente simples ou complexos [Larman, 2000].
Visualizam a seqncia de estados que um objeto ou uma interao percorre
durante sua vida em resposta a estmulos recebidos, junto com suas prprias
aes e respostas conforme mostra a Figura 8.4.
Por exemplo, o comportamento de um objeto modelado em funo
de qual estado ele est inicialmente, e para qual estado ele vai passar quando
um determinado evento ocorrer.
Os estados representam as condies dos objetos em um
determinado momento.
Os eventos representam incidentes que causam a mudana de um
estado para outro. As linhas de transio descrevem o movimento de um
estado para o outro. Cada linha de transio rotulada com o evento que
causou a transio.
62
Figura 8.4 : Diagramas de Estados
8.6 Diagramas de Seq ncia
Os diagramas de seqncias so usados para modelar a interao

entre objetos em um sistema. Tipicamente, um diagrama de seqncia captura
o comportamento de um nico caso de uso. O diagrama apresenta os objetos e
as mensagens que so passadas entre estes objetos dentro do caso de uso,
conforme mostra a Figura 8.5. Os objetos so representados por linhas
tracejadas verticais, e a passagem de mensagens entre dois objetos so
representados por vetores horizontais. As mensagens so desenhadas
cronologicamente do topo base do diagrama.
63
Figura 8.5 : Diagramas de Seqncia
8.7 Diagramas de Col aborao
Os diagramas de colaborao uma outra alternativa para a

modelagem de interaes entre objetos de um sistema. Diferentemente do
diagrama de seqncia que focaliza na seqncia cronolgica do cenrio que
est sendo modelado, o diagrama de colaborao focaliza no relacionamento
entre os objetos e na compreenso dos efeitos sobre um objeto durante um
cenrio. Os objetos so conectados atravs de associaes e cada associao
representa uma instncia de associao entre as respectivas classes
envolvidas. As associaes mostram as mensagens enviadas entre os objetos,
e a seqncia destas mensagens determinada usando-se nmeros
seqenciais (ver Figura 8.6).
Uma Colaborao uma viso de um conjunto de elementos de
modelagem relacionados para um propsito particular em apoio a interaes
[Furlan, 1998].
64
Figura 8.6 : Diagramas de Colaborao
8.8 Diagramas de Ativ idade
Um diagrama de atividade essencialmente um grfico de fluxo,

mostrando o fluxo de controle de uma atividade para outra [Booch, 2000] (ver
Figura 8.7).
Os diagramas de atividades so um caso especial de diagramas de
estado, onde todos os estados tm uma ao interna e nenhuma transio tem
um evento de entrada. O propsito de um diagrama de atividades focar nos
fluxos dirigidos pelo processamento interno e descrever o comportamento de
processamentos paralelos.
Os diagramas de atividades so usados para detalhar classes,
implementao de operaes e casos de uso, enquanto os diagramas de
estado so usados para especificar o comportamento global de um tipo.
Os diagramas de atividades representam o que acontece, mas no
representam quem faz o que. Isso significa que o diagrama no diz qual classe
responsvel por cada atividade. Os divisores contornam esse problema
atravs da organizao das responsabilidades da atividades dentro de uma
classe. Atravs dos divisores podemos separar as atividades de acordo com as
classes responsveis por essas atividades. Os divisores so representados por
linhas verticais tracejadas.
65
Figura 8.7 : Diagramas de Atividade
8.9 Diagramas de Com ponentes
Mostram dependncias entre componentes de software [Furlan,

1998].
Os diagramas de componentes representam, de forma esttica,
aspectos fsicos do sistema sendo modelado. So importantes tanto para
visualizar, especificar e documentar sistemas baseados em componentes
quanto para construir sistemas atravs de engenharia reversa (reverse) e direta
(forward). Eles mostram um conjunto de componentes e seus relacionamentos
conforme mostra a Figura 8.8. So tipicamente usados para:
Modelar a organizao do cdigo fonte;
Modelar lanamento de executveis (verses);
Modelar fisicamente um banco de dados;
Modelar sistemas adaptativos;
Engenharia de produo e engenharia reversa;
66
Figura 8.8 : Diagramas de Componentes
8.10 Diagramas de Imp lantao
Os diagramas de implantao so diagramas que mostram a

configurao de ns de processamento em tempo de execuo e os
componentes que neles existem (ver Figura 8.9).
Os diagramas de implantao no so importantes somente para
visualizar, especificar e documentar sistemas embutidos, cliente/servidor e
distribudos, mas tambm para o gerenciamento de sistemas por engenharia
de produo e engenharia reversa.
Os diagramas de implantao so empregados para modelagem da
viso esttica de implantao de um sistema. Essa viso direciona
primariamente a distribuio, entrega e instalao das partes que formam o
sistema fsico. Na maior parte, isso envolve a modelagem da topologia do
hardware em que o sistema executado. Os diagramas de implantao so
essencialmente diagramas de classes que focalizam os ns do sistema.
67
Figura 8.9 : Diagramas de Implantao
Captulo 9 - METODOLOGIA DESENVOLVIDA
9.1 Introduo
A UML uma linguagem para especificao, visualizao,

documentao e construo que tornam possvel expressar modelos
orientados a objetos. Porm no prescreve como o trabalho deve ser feito.
A utilizao da UML em grandes projetos pode ajud-lo a tornar-se
mais eficiente, mas para tal devemos adotar um mtodo de desenvolvimento.
O mtodo de desenvolvimento adotado deve descrever um nmero
de atividades a ser seguidas em uma determinada ordem. Para alcanar com
xito nossos objetivos devemos ter bem definido a expectativa do projeto.
Um mtodo tradicional de desenvolvimento orientado a objetos
dividido em anlise de requisitos, anlise, projeto, implementao e teste
[Barros, 2001], que uma viso tcnica do desenvolvimento. O RUP(Rational
Unfied Process) um outro mtodo, desenvolvido pela Rational Inc. que
69
dividido em concepo, elaborao, construo e transio, que mostra uma
viso mais gerencial do desenvolvimento [Booch,2000].
Ferramentas
desenvolvimento
de
modernas
sistemas
devem
alm
da
suportar
linguagem
um
de
mtodo
de
modelagem
programao. Um exemplo o Rational Rose da Rational Inc. que suporta bem

tanto a linguagem quanto o mtodo de desenvolvimento.
A
partir
deste
ponto
descreveremos
nossa
metodologia,
apresentando cada fase da metodologia detalhadamente. Tomaremos como

base para desenvolvimento de nossa metodologia a viso tcnica da UML que
divide-se em 5(cinco) etapas: Anlise de Requisitos, anlise, projeto,
programao e testes.
Ao final do desenvolvimento de cada fase sero feitas observaes
que serviro de concluso e de base para futuros melhoramentos.
9.2 Documentao
Estabelecemos alguns procedimentos inicias, a fim de manter a

documentao organizada. Esses procedimentos podem interagir com outras
documentaes em outros projetos usando a mesma metodologia em
plataformas diferentes.
9.2.1 Fonte
Na documentao ser exigido a confeco de alguns documentos,
cujo os quais deve-se redigi-los corretamente para um bom entendimento. Para
70
uma melhor visualizao determina-se antes do incio do projeto o tipo e o
tamanho da fonte, para que todos os documentos escritos tenham o mesmo
aspecto.
O tipo da fonte usada na documentao tem que ser bem definida,
partindo do princpio que nem todos tero as mesmas ferramentas e que
existem editores que no possuem determinadas fontes. Devemos nos
preocupar em estabelecer uma fonte que toda a equipe envolvida e at mesmo
pessoas no envolvidas naquele projeto possuam. Numa apresentao do
projeto criado os documentos tem que ser facilmente visualizados.
Quanto
ao
tamanho,
fontes
pequenas
demais
tornam
documentao um pouco cansativa para ser lida, fontes grandes gerariam

muitas folhas e tambm traria um aspecto desfigurado. O tamanho da fonte
dever estar relacionada com o seu tipo, normalmente usamos o tamanho de
10 a 14.
9.2.2 Gravao da Docu mentao

Para que todos os envolvidos no projeto possam ter acesso
documentao do projeto, e para uma melhor organizao e entendimento,
devemos gravar todos os processos envolvidos com o projeto numa mesma
pasta. Estas pastas devem estar identadas sempre abaixo de uma que englobe
o projeto como um todo, ou at mesmo o nome do projeto. Cria-se uma pasta
me com o nome do projeto e abaixo dela conforme a necessidade cria-se
outras pastas filhas. Todas as pastas criadas devem sempre fazer relao com
os arquivos que estaro armazenados na mesma.
71
Na confeco de um novo projeto pode-se copiar estas pastas para
um outro local e renome-las. Faz-se necessrio uma reviso de todas as
pastas para adequao com o novo projeto.
9.2.3 Extenso de Arqui vos

Na preocupao que nosso projeto possa se comunicar com outros
ou at mesmo a juno dos mesmos, devemos estabelecer extenses de
arquivos que possam ser abertas em qualquer plataforma, sistema operacional,
editor, etc. Muito importante para uma boa definio deste item, saber quais
sero os possveis editores usados, sistemas operacionais que os envolvidos
no projeto possuem.
Arquivos do tipo .txt seriam de bastante abrangncia, exceto no
caso de criao de arquivos um pouco mais complexos, necessitando
ferramentas com um pouco mais de recursos, pois arquivos com este tipo de
extenso podem ser abertas em muitas plataformas. Se houver realmente a
necessidade de criao de arquivos com recursos um pouco mais complexos
que os .txt (modo caracter), procurar usar extenses de arquivos que abram na
grande maioria dos editores.
9.2.4 Impresso
Para que todos os documentos, diagramas, etc., que vierem a ser
gerados e impresso no projeto possam ser bem visualizados e arquivados,
devemos definir anteriormente um tamanho de papel padro.
As margens podem ser configuradas de acordo com a necessidade,
pois dentro do projeto haver diagramas que necessitaro de margens um
72
pouco menores ou maiores devido a sua complexidade. Sendo que para sua
melhor visualizao s vezes necessrio o uso do papel at sua extremidade.
9.2.5 Backup
Deve-se criar um sistema de backup, sugerindo um responsvel pela
execuo do mesmo, para que no haja surpresas no decorrer do projeto,
como perdas de dados. Ocasionando atraso na concluso do projeto, alterando
as datas as quais a equipe se submeteu a cumprir.
A periodicidade dos backups depende do envolvimento da equipe e
das informaes armazenadas diariamente, se houver necessidade pode-se
realizar os backups diariamente, semanalmente ou mensalmente.
Criaremos
um
formulrio
sugesto
que
envolve
todos
os
procedimentos da documentao, conforme anexo 01.
9.2.6 Controle de Verse s

Desejamos com o controle de verses que os desenvolvedores
possam manter o sistema atualizado de acordo com sua documentao. Serve
tambm para diferenciar um software dele mesmo, porm qualquer tipo de
alterao feita ser registrada uma nova verso do software.
Uma verso dever ser representada de modo a controlar desde
pequenas alteraes at novas funcionalidades e/ou grandes alteraes que
mudem a funcionalidade do sistema.
Sugerimos a representao da verso em seqncias de trs blocos
de caracteres (N.NX-NN) onde :
N um caracter numrico no intervalo de 1 a 9;
73
NX : N um caracter numrico no intervalo de 1 a 9; X um caracter

alfanumrico no intervalo de A-Z;
NN so caracteres numricos no intervalo de 01 a 99;

Os dois primeiros caracteres (N.N) representam a verso principal.
Somente so alterados quando se tratar de grandes modificaes e/ou

inovaes, como por exemplo : troca de linguagem, incluso de novo mdulo
no sistema, troca ou incluso de nova plataforma.
O terceiro caracter (X) destinado a alteraes de mdio porte e/ou
incluso de novas rotinas, como por exemplo : cadastros, relatrios,
lanamentos, consultas.
Nos dois ltimos caracteres (NN) registramos pequenas alteraes
e correes em rotinas j existentes no sistema, como por exemplo : alteraes
de relatrios, consultas, cadastros, etc.
9.3 Eventos Iniciais
Aps concludo o item documentao, trataremos alguns eventos

que ocorrem antes da anlise de requisitos. Trata-se de eventos iniciais de
extrema importncia para um bom desenvolvimento da anlise de requisitos,
onde so feitos os primeiros contatos, um estudo dos dados e definio de
possveis envolvidos no projeto.
74
9.3.1 Contatos
Um
determinado
usurio
faz
um
contato
solicitando
desenvolvimento de um software. Este contato pode ser de forma mais varivel

possvel: Fone, Fax, email, pessoal, etc.
A empresa ou pessoa que recebeu o contato, solicita ao usurio, ou
acompanha o mesmo no preenchimento de um formulrio padro. Trata-se de
um formulrio que servir para registrar a solicitao do usurio e tambm para
a convocao de algumas pessoas para uma possvel reunio a qual ser
marcada. Como trata-se de algo bem genrico, atravs deste formulrio ainda
no se sabe com certeza quem ser envolvido no sistema. Define-se tanto os
participantes por parte do usurio quanto da empresa de desenvolvimento de
software.
Este
formulrio
dever
ser
preenchido
em
meio
magntico(aconselhvel) ou papel, este ltimo depois de preenchido ser

transformado em meio magntico.
Criaremos um formulrio sugesto que contm todos os itens
necessrios para registrar um contato, conforme anexo 02.
9.3.2 Estudo dos Dados

Tratando-se de um desenvolvimento de um novo software ser
analisado:
Aps uma anlise da rea de negcio, concluindo-se que a empresa no

pode atender a solicitao, ser retornado ao mesmo que trata-se de uma
rea de negcio a qual a empresa no oferece solues. Esta resposta
75
tambm poder ser dada no momento do preenchimento do formulrio
padro, dependendo de quem e da capacidade do atendente.
A rea de negcio da solicitao abrangida pela empresa, ento ser feita

uma avaliao sobre a descrio e com base nesta avaliao e na rea de
negcio, sero convocados para uma reunio os possveis envolvidos no
projeto, tanto por parte do solicitante, quanto por parte da empresa
desenvolvedora.
9.3.3 Definio dos Part icipantes

A definio dos participantes deve sempre girar em torno da rea de
negcio e da descrio, pois ali que contm alguns conceitos bsicos que
podem ajudar os responsveis a convocar as pessoas certas para definir os
possveis participantes.
Nesta definio procura-se envolver todos que de alguma forma
podero contribuir para o projeto de ambas as partes. Logicamente de acordo
com o andamento do projeto sero filtrados, ficando apenas aqueles que
podem contribuir para o bom desenvolvimento do projeto. Aps definir todos os
participantes da reunio, ser marcada a data da mesma e os envolvidos sero
convocados.
At este ponto trata-se de um evento que antecede as fases da
metodologia de desenvolvimento de sistemas.
76
9.4 Anlise de requis itos
Esta fase a base do projeto, dever ser bem elaborada para um

bom desenvolvimento das demais fases. Sero abordados itens necessrios
para a concepo do projeto, definio de equipe envolvida e tambm alguns
itens tcnicos como: atores, casos de uso, diagrama de casos de uso e anlise
de riscos.
9.4.1 Reunio/Entrevista
Nas reunies, das quais as pessoas convocadas a participar, no
existe nenhuma hierarquia. Todos os participantes, sejam eles analistas,
gerentes, diretores ou escriturrios, devem se posicionar livremente, pois se
foram convidados a participar porque tm alguma contribuio a dar com o
seu conhecimento especfico no assunto objeto da reunio. Em uma situao
normal, a hierarquia funciona como um agente inibidor e a opinio da pessoa
de nvel mais alto prevaleceria sobre as demais, sem nenhuma garantia de que
fosse a mais indicada.
Para dar incio a comunicao entre os participantes, Gause e
Weinberg sugerem que o analista comece fazendo perguntas de livre contexto,
concentrando-se no cliente, nas metas globais e nos benefcios. Por exemplo,
o analista poderia perguntar :
Quem est por trs do pedido deste trabalho?
Quem usar a soluo?
Qual o benefcio econmico de uma soluo bem-sucedida?
H outra fonte para a soluo exigida?
77
Em seguida, o analista pode fazer perguntas que o ajudaro na
compreenso do problema e ter uma idia da soluo:
Como voc caracteriza um "bom" resultado(sada) que seria gerado por

uma soluo bem-sucedida?
Qual o(s) problema(s) essa soluo resolver?
Voc poderia mostrar-me(ou descrever-me) o ambiente que a soluo ser

utilizada?
Existem questes de desempenho ou restries especiais que afetaro a

maneira pela qual a soluo abordada?
Por fim, o analista far perguntas decisivas, que concentram-se na
efetividade da reunio:
Voc a pessoa certa para responder a essas perguntas? Suas respostas

so "oficiais"?
Minhas perguntas so pertinentes ao problema que voc tem?
Estou fazendo perguntas demais?
H mais algum que possa fornecer informaes adicionais?
Existe algo mais que eu possa perguntar-lhe?

Uma abordagem coleta de exigncias orientadas a equipes
aplicada durante as primeiras etapas de anlise e especificao a

FAST(Facilitaded Application Specification Techniques). Essa abordagem
estimula a criao de uma equipe conjunta de clientes e desenvolvedores que
trabalhem juntos para identificar o problema, propor elementos de soluo,
negociar diferentes abordagens e especificar um conjunto preliminar de
requisitos de soluo. Hoje, a FAST usada predominantemente pela
78
comunidade de sistemas de informao, mas a tcnica oferece potencial para
uma melhor comunicao em aplicaes de todos os tipos.
Outra abordagem especializada de entrevista que pode ser usada
o JAD(Joint Application Development). Consiste numa rpida entrevista e um
processo acelerado de coleta de dados em que todos os principais usurios e o
pessoal da anlise de sistemas agrupam-se em uma nica e intensiva
reunio(que pode prolongar-se de um dia a uma semana) para documentar os
requisitos do usurio. A reunio costuma ser supervisionada por um
especialista treinado que atua como mediador para encorajar melhores
comunicaes entre os analistas de sistemas e os usurios.
Esses mtodos citados possuem suas diferenas, mas todos tem
alguns princpios bsicos :
Um encontro
levado
a efeito
num local neutro
e participam
desenvolvedores e clientes;
Usam-se regras para preparao e participao;
Uma agenda formal para captar os pontos importantes, agindo de forma

livre o suficiente para encorajar o fluxo de idias e sugestes;
Um moderador (Cliente, Desenvolvedor ou algum de fora) para controlar a

reunio;
Utilizao de um mecanismo de definio que pode ser uma planilha, um

cavalete, adesivos de parede ou cartazes;
Identificao do problema, propor elementos de soluo, negociar

diferentes abordagens e especificar um conjunto preliminar de requisitos de
soluo num clima que facilite a realizao da atividade.
79
9.4.2 Preenchimento da ata da reunio

Nesta primeira reunio aparecero muitas idias sobre como se
deve comportar o sistema ou o que ele deve atingir. Todas as idias devem ser
includas na ata pois sero a partir delas que ser dado o start no projeto.
A ata da reunio dever ser compostas de alguns elementos
essenciais .
Criaremos um formulrio sugesto que contm todos os elementos
essenciais, conforme anexo 03.
9.4.3 Definies de resp onsabilidades

Aqui definiremos a responsabilidade de cada um dos envolvidos no
projeto. Coordenador da equipe: Responsvel pelo andamento do Projeto.
9.4.4 Resumo do Projeto

Um texto geral sobre o sistema que ser desenvolvido. Neste texto
ser descrito as principais caractersticas e funcionalidades do sistemas.
Tambm ser descrita a abrangncia de todo o Projeto, com quem interage e
por quem interagido(isto pode ser representado por diagramas de casos de
uso) .
Discriminar alguns requisitos mnimos para um bom funcionamento
do projeto tambm faz parte deste resumo, tais como equipamentos, fontes de
dados, ambiente de trabalho, etc.
Cria-se um arquivo com o nome do sistema cujo o resumo faz
referncia.
80
9.4.5 Atores
Atores so usurios e/ou outros meios externos que desenvolvem
algum papel em relao ao sistema. Os meios externos so hardwares e/ou
softwares que, assim como os usurios, geram informaes para o sistema ou
necessitam de informaes geradas a partir do sistema. Existem atores que
podem desempenhar mais de um papel no sistema, quando se pensar em
atores sempre bom pensar neles como papis em vez de pensar como
pessoas, cargos, mquinas. No sistema podem ter usurios com diferentes
permisses, para isto necessrio criar um ator para cada diferente tipo de
permisses. Os atores so quem desempenham os casos de uso, um mesmo
ator pode estar em um ou mais casos de uso.
Cada ator deve possuir um nome cujo ter relao direta com a sua
funo, possuir uma descrio que definir o que ele faz e com quem ele
interage.
Criaremos um formulrio sugesto para listar os atores do sistema,
conforme anexo 04.
9.4.6 Casos de Uso

Antes da definio de casos de uso, devemos ter definidos os atores
e ter a idia da funcionalidade do sistema, a partir disto, comearemos a definir
os casos de uso.
Casos de uso especificam o comportamento do sistema ou parte(s)
dele e descrevem a funcionalidade do sistema desempenhada pelos atores.
Voc pode imaginar um caso de uso como um conjunto de cenrios, onde cada
81
cenrio uma seqncia de passos a qual descreve uma interao entre um
usurio e o sistema. Os casos de uso so representados em forma de elipse.
No deve-se detalhar muito um determinado caso de uso, o seu
detalhamento vai depender do risco que o mesmo corre, quanto maior o risco,
mais detalhes ter o caso de uso.
Ao definir os casos de uso a serem desenvolvidos, trate apenas dos
casos de usos mais crticos para o sistema, os casos de uso que so tarefas
rotineiras no precisam ser desenvolvidos. Dessa forma sua documentao
no se tornar montona. Numericamente falando, em modo geral trate apenas
de 10 20(%) dos casos de uso mais crticos de seu sistema, estes nmeros
citados claro que podem variar dependendo do sistema a ser desenvolvido.
Os nomes dos casos de usos devemos sempre usar verbos, pois
assim facilitar no entendimento dos mesmos. Devemos possuir uma lista com
todos os nomes dos casos de usos para facilitar na identificao dos mesmos.
Preencher todos os requisitos de um caso de uso de extrema importncia.
Criaremos um formulrio sugesto para listar os casos de uso,
conforme anexo 05. Tambm criaremos outro formulrio sugesto contendo
todos os requisitos de uma caso de uso, conforme anexo 06.
9.4.7 Escopo
Uma viso grfica do sistema, mostrando a idia geral do sistema
como ele ir interagir com o mundo externo. Esta viso transformao de
funcionalidades, interao e abrangncia descritos no resumo do projeto para
uma representao grfica. Deve-se usar os atores e casos de uso.
82
9.4.8 Diagrama de caso de uso

O diagrama de caso de uso um ponto importante de comunicao
entre a equipe de desenvolvimento e o usurio, portanto dever ser de fcil
entendimento. Sua definio deve deixar bem transparente a idia do sistema.
Nos diagramas de casos de uso ilustramos conjuntos dos casos de
uso do sistema, os atores e a relao entre os atores e os casos de uso.
Devemos definir o nome do diagrama de caso de uso sempre
relacionado-o com o seu propsito. Ento relacionamos os casos de uso de
uma determinada parte ou de todo o sistema e os relacionamos com seus
respectivos
atores.
Deve-se
documentar
cada
diagrama
desenvolvido
observando alguns itens importantes como: nome do diagrama, descrio,

atores e casos de uso relacionados.
Criaremos um formulrio sugesto que contm todos os itens de
diagrama de caso de uso, conforme anexo 07.
9.4.9 Anlise de riscos

Em todo projeto surgem vrias incertezas, devemos considerar
algumas mais crticas, estas devero ser tratadas com mais importncia, pois
podero comprometer todo o desenvolvimento do sistema. Dentre elas
podemos citar as mais crticas e que geralmente ocorrem na maioria dos
projetos:
Est realmente claro a importncia deste projeto?
Baseado nos casos de uso, tem-se condies de implementar as funes

dentro prazo previsto?
Analisar os problemas tcnicos que podero ocorrer ao longo do projeto.
83
Caso encontre problemas, estes sero resolvidos de forma que no altere o

cronograma do projeto?
Os requisitos foram bem definidos de modo que se ocorrerem eventuais

mudanas, estas no geraro alteraes considerveis no tempo e nem nos
custos de desenvolvimento?
Empenho dos envolvidos no projeto, todos que se comprometeram

realmente iro participar?
A anlise de riscos uma tarefa de grande importncia no
gerenciamento de um projeto de software, embora, em muitos casos, esta

atividade nem seja considerada.
O seu objetivo determinar um conjunto de passos a serem
seguidos para determinar os riscos envolvidos no projeto: identificao,
avaliao, classificao, definio de estratgias para administrar os riscos,
resoluo dos riscos, etc...
9.4.10 Cronograma
Os cronogramas so metas que devem ser atingidas, definindo
prazos nos quais os envolvidos devero empenhar-se na execuo de suas
atividades para o cumprimento dos mesmos.
Dever ser criada uma representao (grfico ou tabela) que
exprima o tempo dedicado a cada tarefa, determinando assim o prazo final do
projeto.
Criaremos um formulrio sugesto que contm todos os itens para
um correto preenchimento de um cronograma, conforme anexo 08.
84
9.4.11 Aprovao
Cria-se um formulrio onde responsveis devero aprovar a fase.
Criaremos um formulrio modelo conforme anexo 09.
9.5 Anlise
Esta fase preocupa-se com as primeiras abstraes e mecanismos

que estaro presentes no domnio do problema. Traremos dos diagramas de
classes em conjunto com diagramas de objetos, os diagramas de interao os
dividiremos em seqncia e colaborao, trataremos tambm dos diagramas
de estado e atividade.
9.5.1 Diagrama de Class es

Nos diagramas de classes modelamos a viso esttica do sistema, o
conjunto de classes, interfaces, colaboraes e seus relacionamentos. Nestes
relacionamentos dar-se- mais ateno aos quatro principais tipos que so:
Generalizao/especificao, Agregao, Associao e Dependncia.
Em sistema de grande complexidade podemos dividir o diagrama de
classes em diagramas menores, logicamente observando sempre a integrao
de todas as partes.
Deve-se considerar alguns procedimentos no desenvolvimento de
diagramas de classes:
Praticamente, ter em mos todas as informaes sobre um modelo de

objetos pouco provvel. Deve-se ter conhecimento dos comportamentos
85
iniciais
destes
objetos,
defini-los,
classific-los
identificar
os
relacionamentos entre eles. Devemos nos direcionar mais as abstraes

comportamentais, reduzindo o nmero de objetos.
No devemos nos preocupar muito em usar toda a teoria envolvida nos

diagramas de classes, mas sim as mais simples: classes, associaes,
atributos e generalizao usando logicamente outras abstraes quando
forem necessrias.
Ter conhecimento e compreenso da idia do projeto fundamental.
Cria-se modelos apenas das reas chaves do sistema.
Atribuir-lhe um nome que indique sua finalidade.
Na definio das classes podemos usar para definir os nomes substantivos,

para os mtodos usamos verbos e para os atributos usamos propriedades
da classe.
A ateno em todos os detalhes desenvolvidos neste diagrama ser
de grande influncia na construo de um bom sistema.
9.5.2 Diagrama de Objet os

Os diagramas de objetos so utilizados para visualizar, especificar,
construir e documentar a estrutura de um conjunto de objetos, onde cada um
est num estado especfico e em um determinado relacionamento com demais
objetos.
Os diagramas de objetos ajudam principalmente na modelagem de
estruturas complexas. Quando construmos diagramas de classes, de
componentes ou de implementao o que captamos realmente um conjunto
de abstraes que nos interessa como um conjunto e, deste ponto de vista,
86
mostra-se sua semntica e seus relacionamentos com outras abstraes
existentes neste conjunto. Se imaginarmos um determinado momento num
sistema modelado, encontraremos um conjunto de objetos, cada um em um
estado especfico e em um determinado relacionamento com os demais
objetos.
Um diagrama de objetos mostra um nico conjunto de objetos
relacionados uns com os outros em um momento especfico.
Segundo
Booch,
citamos
algumas
consideraes
para
desenvolvimento de diagramas de objetos [1995]:
Identifique alguma funo ou comportamento de parte do sistema cuja

modelagem voc est fazendo e que resultante da interao de uma
sociedade de classes, interfaces e outros itens.
Para cada funo ou comportamento, identifique as classes, interfaces e

outros elementos e seus relacionamentos entre si que participem nessa
colaborao.
Considere apenas um nico cenrio capaz de percorrer tudo isto, congele o

cenrio em determinado momento e represente cada objeto participante.
Exponha o estado e os valores dos atributos de cada um desses objetos,

conforme seja necessrio, para compreenso do cenrio.
De forma semelhante, exponha os vnculos existentes entre esses objetos,

representando instncias de associaes entre eles.
9.5.3 Diagramas de Inter ao

O diagrama de interao enfatiza a interao de objetos, uma
especificao comportamental que inclui uma seqncia de trocas de
87
mensagens entre objetos dentro de um contexto a fim de realizar um
determinado propsito.
Devemos utilizar diagramas de interao quando necessitamos ver o
comportamento de vrios objetos dentro de um nico caso de uso, a partir de
mensagens que so trocadas entre eles. Estes diagramas modelam os
aspectos dinmicos do sistema.
Os diagramas de interao podem ser apresentados de duas
formas: Diagrama de Seqncia e Diagrama de Colaborao.
9.5.3.1 Diagrama de Seq ncia

O diagrama de seqncia expe o aspecto do modelo que enfatiza o
comportamento dos objetos em um sistema, incluindo suas operaes,
interaes, colaboraes e histrias de estado em seqncia temporal de
mensagem e representao explcita de ativao de operaes [Furlan, 1998].
Em um diagrama de seqncia, um objeto representado por um
retngulo no topo de uma linha vertical tracejada projetada para baixo. Esta
linha representa o ciclo de vida de um objeto durante uma interao. As
mensagens so representadas por linhas horizontais entre as linhas verticais
de dois objetos, e a ordem de como as mensagens acontecem tambm
mostrada de cima para baixo.
O diagrama de seqncia mostra uma seqncia explcita de
mensagens e devemos us-lo para especificaes de tempo real e para
cenrios complexos.
88
9.5.3.2 Diagrama de Colab orao

Um diagrama de colaborao um contexto, um grfico de objetos e
vnculos com fluxos de mensagens anexados [Furlan, 1998].
Num diagrama de colaborao, os objetos so desenhados como
cones, e as setas indicam as mensagens enviadas entre objetos para realizar
um caso de uso.
O diagrama de colaborao auxilia no entendimento de um
comportamento de um conjunto de objetos que trocam mensagens entre si
para realizar um propsito em uma interao global, atravs deste diagrama
podemos ver somente os objetos e as mensagens envolvidas. Uma
colaborao anexada a um tipo, uma operao ou um caso de uso para
descrever seus efeitos externos.
Em diagramas complexos devemos separ-los em diagramas
menores para facilitar seu entendimento. Utilizamos a descrio do caso de
uso como ponto de partida para a confeco do diagrama.
Como podemos observar os diagramas de seqncia e colaborao
expressam informaes semelhantes, porm de forma diferente. Quando
tivermos que decidir entre qual diagrama devemos adotar para estudar uma
interao, podemos escolher primeiramente o diagrama de colaborao
quando o objeto e seus vnculos facilitam a compreenso da interao, e
somente escolher o diagrama de seqncia se a seqncia precisar ser
evidenciada.
89
9.5.4 Diagrama de Estad o

O diagrama de estado exibe os eventos e os estados interessantes
de um objeto e o comportamento de um objeto em resposta a um evento. O
diagrama de estado implica na importncia da ordem de execuo dos
eventos. Este diagrama faz a modelagem dos aspectos dinmicos de sistemas.
Para melhor definir estes diagramas, deve-se desenvolver de forma
individualizada um diagrama para cada classe existente, desta forma
detalhando todos os estados da classe.
Um estado representado por um retngulo com cantos
arredondados e pode ter de um trs compartimentos que so: compartimento
do nome do estado, compartimento de variveis e compartimento de atividade
interna.
Deve-se considerar alguns procedimentos no desenvolvimento de
diagramas de estados:
Atribuir-lhe um nome capaz de comunicar seu propsito
Comece modelando os estados estveis do objeto e, em seguida faa a

modelagem das transies legais de um estado para outro.
No grfico deste diagrama, procure organizar seus componentes de forma

que reduza o cruzamento de ligaes de componentes.
9.5.5 Diagrama de Ativid ade

Podemos fazer uma analogia com um grfico de fluxo(fluxograma),
pois os diagramas de atividades controlam o fluxo de controle de uma atividade
para outra. Focalizando as atividades que ocorrem entre objetos, modelando
aspectos dinmicos do sistema.
90
Nos Diagramas de Atividades modelamos a ordem pela qual as
coisas devem ser feitas, em processos seqncias ou paralelos, o que os
diferencia de um fluxograma que so limitados a processos seqnciais.
Usamos os Diagrama de Atividades para diferentes propsitos
como:
Anlise de Caso de Uso e compreenso do fluxo de trabalho entre vrios

casos de uso;
Capturar o funcionamento interno de um objeto;
Entender as aes quando executamos uma operao;
Mostrar o funcionamento de um processo de negcio em termos de atores,

fluxos de trabalho, organizaes e objetos;
Mostrar como uma instncia de caso de uso pode ser realizada em termos
de ao e mudanas de estado de objetos;
Mostrar como um conjunto de aes relacionadas pode ser executado e

como afetar objetos ao seu redor.
9.6 Projeto
Baseado na anlise, trataremos nesta fase de solues tcnicas.

Para essas solues sero usados os diagramas de implementao, os quais
esto divididos em diagramas de componentes e implantao.
91
9.6.1 Diagrama de imple mentao

Os diagramas de implementao modelam os aspectos fsicos.
Apresentam aspectos de implementao, inclusive da estrutura de cdigo fonte
e de implementao de runtime.
Esto divididos em diagramas de Componentes e diagramas de
implantao.
9.6.1.1 Diagrama de comp onente

O diagrama de implantao mostra a configurao dos ns de
processamento em tempo de execuo e os componentes que nele existem.
Os diagramas de componentes mostram a organizao e as
dependncias existentes entre um conjunto de componentes, transformam seu
projeto lgico em bits. Modelam os itens fsicos que residem em um n como
executveis, bibliotecas, tabelas, arquivos e documentos.
Devemos atribuir-lhe um nome que demonstre seu propsito, seu
contedo costuma conter: componentes, interfaces, relacionamentos de
dependncia, generalizao, associao e realizao. Podem conter notas e
restries.
So usados para a modelagem da viso esttica de implementao
de um sistema. A reunio das partes modeladas ajudaro na formao do
sistema executvel. Usamos os Diagramas de Componentes nas seguintes
formas:
Para modelagem de cdigo-fonte:
Identificar um conjunto de arquivos de cdigo-fonte de interesse e

transform-lo em componentes;
92
Em sistemas grandes, devemos usar pacotes para mostrar grupos de

arquivos de cdigo-fonte;
No diagrama de componentes a exposio da verso do arquivo de

cdigo-fonte ajuda no entendimento das dependncias de compilao;
Para modelagem de verses executveis:
Identificar o conjunto de componentes, isso envolver alguns ou todos

que vivem em um nico n ou a distribuio desse conjunto de
componentes por todos os ns existentes no sistema;
Considere o esteretipo de cada componente desse conjunto;
Para
cada
componente
existente
no
conjunto,
faa
seus
relacionamentos.
Para modelagem de bancos de dados fsicos:
Identificar as classes existentes no modelo que representam o esquema

de seu banco de dados lgico;
Faa o mapeamento de suas classes em tabelas;
Esteretipe suas tabelas para um diagrama de componentes;
Transforme seu projeto lgico em fsico
Para modelagem de sistemas adaptveis:
Identificar a distribuio fsica dos componentes que podero mover de

um n para outro. Especifique a localizao de uma instncia do
componente, atribua a ela o valor location.
Para modelagem das causas de mudanas de um componente use um

diagrama de interao para auxili-lo.
Para uma melhor compreenso dos diagramas de componentes
podemos usar notas e cores como indicaes visuais com a finalidade de
93
chamar a ateno a pontos importantes do diagrama. E tambm devemos usar
elementos estereotipados com cuidado, escolhendo um conjunto pequeno de
cones e utilizando-o de maneira consistente.
9.6.1.2 Diagrama de impla ntao

Diagrama de Implantao usada para mostrar a organizao do
hardware e a ligao do software aos dispositivos fsicos. Este diagrama
denota vrios dispositivos de hardware e interfaces fsicas determinadas por
seus esteretipos, como processador, impressora, memria, disco; suficientes
para que o engenheiro de software especifique a plataforma em que o sistema
executado.
O diagrama de implantao modela a viso esttica da implantao
de um sistema entre seus ns fsicos e seus relacionamentos e para
especificar seus detalhes referente a construo. Usamos os Diagramas de
Implantao em uma das trs formas :
Para modelar Sistemas Embutidos :
Identificar os dispositivos e os ns que so nicos para o sistema;
Crie indicaes visuais para dispositivos de hardware e outros tipos

dispositivos;
Modele os relacionamentos entre os dispositivos;
Se necessrio crie diagramas de implantao mais detalhado em

dispositivos inteligentes.
Para modelar sistema Cliente/Servidor :
Identificar os ns que representem os processadores do cliente e do

servidor do sistema;
94
Junte os dispositivos importantes para o comportamento do sistema.
Crie indicaes visuais para processadores e dispositivos usando

esteretipos
Modele a topologia dos ns, especificando seus relacionamentos.
Para modelar sistema totalmente distribudo :
Identificar os dispositivos e processadores para sistemas cliente/servidor

mais simples;
Caso precise analisar o desempenho da rede do sistema ou

modificaes na rede, modele esses dispositivos em um nvel de detalhe
que previna essas avaliaes;
Analise os agrupamentos lgicos de ns, especificando-os em pacotes;
Identifique a topologia do seu sistema;
Se for preciso focalizar a dinmica do sistema, introduza diagramas de

casos de uso para especificar o comportamento em foco e crie diagrama
de interao para expandir esses casos de uso.
Os diagramas de implantao no so muito utilizados em sistema
que residem em uma mquina e que interagem somente com dispositivos

padro(teclado, monitor, mouse, modem pessoal) dessa mquina, que j so
gerenciados pelo S.O. host. Em contrapartida se estiver desenvolvendo
software que interaja com dispositivos que o sistema operacional host
tipicamente no gerencia, ou por processadores distribudos fisicamente no
mesmo host, o diagrama de implantao ajudar a analisar o mapeamento de
software para hardware de seu sistema.
Para uma melhor compreenso dos diagramas de implantao
devemos atribuir-lhe um nome que identifique seu propsito, podemos usar
95
notas e cores como indicaes visuais com a finalidade de chamar a ateno a
pontos importantes do diagrama. E tambm devemos usar elementos
estereotipados com cuidado, escolhendo um conjunto pequeno de cones e
utilizando-o de maneira consistente.
9.7 Implementao
A fase da implementao , na prtica, a construo fsica do

sistema proposto [Silva,1998]. onde todos os modelos desenvolvidos no
projeto so traduzidos para cdigo que a mquina possa reconhecer.
muito importante que as fases anteriores j estejam concludas,
pois a codificao uma conseqncia natural do projeto.
9.7.1 Traduo
O processo de traduo acontece quando a compilador aceita o
cdigo-fonte como entrada e gera um cdigo-objeto como sada.
Para que o cdigo-fonte no seja gerado de maneira diferente do
projeto, deve-se ter todos os detalhes do projeto bem elaborados e estudados.
9.7.2 Escolha da Lingua gem

Linguagem de codificao complexa ou pouco conhecida pode levar
a cdigos mal elaborado e de difcil legibilidade. Devemos nos concentrar em
escolher linguagens de codificao que tenha suporte ao projeto.
96
A escolha de uma linguagem de programao para um projeto
especfico deve-se considerar as suas facilidades e aonde ela ir ajudar o
melhor desenvolvimento do projeto.
PRESSMAN sugere alguns critrios a serem avaliados durante a
escolha de uma linguagem de programao [1995]:
A rea de aplicao geral;
A complexidade computacional e algortmica;
O ambiente em que o software ser executado;
Consideraes de desempenho;
A complexidade da estrutura de dados;
O conhecimento da equipe de desenvolvimento do software;
A disponibilidade de um bom compilador.

Geralmente considera-se a rea de aplicao geral como um dos
itens mais estudados na escolha da linguagem.

O lanamento de novas linguagens ou verses muito constante,
portanto muitas vezes necessitamos escolher linguagens do conhecimento da
equipe, que geralmente no so os ltimos lanamentos. Porm novas
linguagens devem ser cuidadosamente estudadas e a mudana da linguagem
atual para nova tem que ocorrer.
Na escolha de uma linguagem orientada a objetos deve-se
considerar suporte para definies de classes, herana, encapsulao e
transmisso de mensagens ou ainda caractersticas adicionais como herana
mltipla e polimorfismo.
As novas geraes de ferramentas CASE possuem uma variedade
de linguagens, com isto elas podem gerar cdigos-fonte baseadas no modelo
97
desenvolvido. Porm devem ser bastante estudadas pois uma falha no modelo
pode comprometer todo o produto final.
9.7.3 Documentao do Cdigo

Um cdigo-fonte bem estruturado e documentado ser de grande
importncia para futuras manutenes no sistema.
A estruturao e documentao comea com a escolha de nomes
identificadores(variveis
rtulos),
prosseguindo
com
colocao
composio do comentrio e por fim com a organizao visual do cdigo.

Na escolha de nomes de identificadores devemos considerar alguns
itens a fim de facilitar a interpretao :
Expressar diretamente o seu propsito.
Identificao do tipo e de sua abrangncia(global, local) no sistema. Podem

ser feitas algumas definies de nomes antes do incio da programao.
No usar nomes muito extensos, mas que expresse o seu propsito. Neste
caso dever prevalecer o bom censo e experincia por parte do
programador.
Na colocao e composio de comentrios, tomaremos alguns
cuidados para que estes realmente ajudem outros leitores de cdigo na

compreenso do cdigo e at mesmo para que o desenvolvedor possa
localizar-se com mais facilidade e rapidez em futuras manutenes. Isto de
extrema importncia no desenvolvimento de sistemas e/ou funes complexas.
Segundo PRESSMAN, comentrios em forma de prlogo so
bastante usados, eles aparecem no incio de cada mdulo, e seguem o formato
abaixo [1995]:
98
Uma declarao de propsitos que indique a funo do mdulo.
Uma descrio da interface("seqncia de chamada", descrio de todos os

argumentos e uma lista de todos os mdulos subordinados).
Uma discusso de dados pertinente, tais como variveis importantes e suas

restries e limitaes de uso.
Um histrico de desenvolvimento(autor do mdulo, auditor e data, datas e

descrio das modificaes).
Para uma melhor documentao em mdulos e/ou funes muito
complexas devemos utilizar tambm comentrios descritivos embutidos no

decorrer do cdigo-fonte. Este tipo de comentrio ser de grande utilidade para
documentarmos linhas ou conjunto de linhas especficas em determinado local
dentro de um mdulo e/ou funo. Este comentrio dever sempre anteceder o
bloco de comandos que se deseja documentar, faa apenas a identificao da
funcionalidade de tal linha ou conjunto de linhas, no necessrio documentar
outros dados como datas, autores, etc.
Ao escrevermos cdigo-fontes e tambm seus comentrios devemos
sempre nos preocupar com sua esttica, procuramos sempre elaborar cdigos
identados e seus comentrios devem sempre ter uma boa visualizao.
Algumas dicas de PRESSMAN para simplificar a codificao [1995]:
Evitar o uso de testes condicionais complicados;
Evitar os testes em condies negativas;
Evitar um intenso alinhamento de laos ou condies;
Usar parnteses para esclarecer expresses lgicas ou aritmticas;
Usar smbolos de espaamento e/ou legibilidade para esclarecer o

contedo da instruo;
99
Usar somente caractersticas com padro ANSI;
Auto questionar-se: Ser que entenderia este cdigo se no fosse eu o

autor deste?
9.8 Testes
A atividade de teste visa executar um programa ou parte dele com a

inteno de encontrar erros.
Um teste bem executado aquele que encontra um maior nmero
de erros com o menor nmero de tentativas, em um tempo e esforo mnimo.
Certamente que os projetistas codificam o software para que no haja erros.
Uma estratgia de teste de software deve estar dividida nas
seguintes fases : planejamento de teste, projeto de casos de teste, execuo
de teste e a resultante coleta e avaliao de dados [Pressman, 1995].
Para tornar esta estratgia mais flexvel e customizada sem perder
sua validade e regidez, objetivando a reduo de custos e tempo adotamos a
seguinte estratgia : planejamento, execuo e avaliao dos resultados.
9.8.1 Planejamento de T estes

Antes do incio dos teste devemos definir a equipe responsvel pelos
testes. Devemos formar um grupo de testes independentes (GTI), envolvendo
tambm os desenvolvedores principalmente na etapa de teste de unidade da
fase de execuo que ser abordado a seguir.
100
Devemos tomar como base para testes os casos de usos
desenvolvido na fase de anlise de requisitos, verificando se seu propsito est
contemplado, observando seu fluxo normal e quando este fluxo no seguido
se os fluxos alternativos esto atendendo tal situao.
9.8.2 Execuo de Teste s

Nesta etapa so realizados os testes na integra, abordaremos os
testes de Unidade, Integrao, Validao e Sistema.
Durante a execuo dos testes, deve-se fazer um relatrio de
acompanhamento para registro de todos as ocorrncias encontradas.
9.8.2.1 Teste de Unidade

Nestes testes cada unidade de software(classe, procedimento,
funo, arquivo, etc) testado individualmente garantindo que ele funcione
adequadamente. Aqui a participao dos desenvolvedores
tambm
recomendada, pois estes tem um melhor conhecimento interno de cada

unidade.
Alguns aspectos a serem testados: so a interface, as estruturas de
dados, as condies limite, os caminhos independentes e os caminhos de
tratamento de erros.
A interface, em busca de erros de passagem de dados para dentro e para

fora do mdulo. Deve ser realizada em primeiro lugar, durante a realizao
deste teste os seguintes aspectos devem ser observados :
1. Consistncia entre o nmero e o tipo de parmetros de entrada com o
nmero e tipo de argumentos;
101
2. Consistncia entre o nmero e o tipo de argumentos transmitidos aos
mdulos chamados com os parmetros;
3. Consistncia de variveis globais ao longo dos mdulos;
4. Existncia de referncias a parmetros no associados ao ponto de
entrada atual;
5. Modificao de argumentos de entrada/sada.
As estruturas de dados locais, para se prover a garantia de que todos os

dados armazenados localmente mantm sua integridade ao longo da
execuo do mdulo. Neste teste devemos nos preocupar em :
1. Digitao inconsistente ou imprpria;
2. Iniciao ou valores default errneos;
3. Tipos de dados errados;
4. Underflow e Overflow.
As condies limite, que permitem verificar que o mdulo executa

respeitando os valores mximos e mnimos estabelecidos para seu
processamento.
Os caminhos independentes (ou caminhos bsicos) da estrutura de controle

so analisados para ter garantia de que todas as instrues do mdulo
foram executadas pelo menos uma vez. Os erros mais comuns so :
1. Precedncia aritmtica incorreta;
2. Operaes em modo misto;
3. Inicializao incorreta;
4. Erros de preciso;
5. Representao simblica de uma expresso incorreta;
6. Laos mal definidos;
102
7. Comparao de diferentes tipos de dados;
8. Operadores lgicos utilizados incorretamente.
Os caminhos de tratamento de erros (se existirem), sero testados para

observar a robustez do mdulo. Devemos observar os seguintes itens :
1. Descrio incompreensvel do erro;
2. O erro exibido no o erro encontrado;
3. Interveno da condio de erro no sistema antes do seu tratamento;
4. O processamento das condies de excees incorreto;
5. A descrio do erro no ajuda na localizao da causa do erro.
9.8.2.2 Teste de Integra o

O teste de integrao uma tcnica sistemtica para a construo
da estrutura de programa, realizando-se em paralelo, testes com o objetivo de
descobrir erros associados a interfaces. Seu objetivo montar, a partir dos
mdulos testados ao nvel de unidade construir a estrutura de programa que foi
determinado pelo projeto.
Este teste est divido em incremental e no incremental. Incremental
aborda o teste de integrao top-down o programa construdo e testado em
pequenos seguimentos, onde os erros so mais fceis de ser isolados e
corrigidos. O teste no incremental aborda o teste de integrao bottom-up o
programa testado como um todo, um conjunto de erros encontrado e sua
correo difcil porque o isolamento das causas complicado pela vasta
amplitude do programa inteiro [Pressman,1995].
1. Integrao top-down : Os mdulos so integrados movimentando-se
de cima para baixo atravs da hierarquia de controle, iniciado-se do
103
mdulo principal. Os mdulos subordinados ao mdulo principal de uma
maneira depth-first(pela profundidade) ou breadth-first(pela largura).
2. Integrao bottom-up : Inicia-se a construo e testes com mdulos
localizados nos nveis mais baixos da estrutura do programa dirigindo-se
ao mdulo principal.
9.8.2.3 Teste de Validao

Ao final do teste de integrao, o software finalmente estruturado
na forma de um pacote ou sistema. O teste de validao a validao e
verificao de que o software como um todo cumpre os requisitos do sistema.
Na fase de anlise de requisitos so definidos critrios que serviro
de validao para aprovao ou no do software. O teste de validao aborda
as seguintes estratgias : reviso de configurao e teste alfa e beta.
1. Reviso de configurao: onde so verificados os elementos de
configurao do software se esto adequadamente desenvolvidos e
detalhados para futuras manutenes.
2. Teste alfa: feito por um cliente nas instalaes do desenvolvedor.
O software usado num ambiente controlado com o desenvolvedor
"olhando sobre os ombros" do usurio e registrando erros e
problemas de uso.
3. Teste beta: feito nas instalaes do cliente pelo usurio final do
sistema. O desenvolvedor no est presente. O cliente registra os
problemas(reais ou imaginveis) que so encontrados e relata-os ao
desenvolvedor em intervalos regulares.
104
9.8.2.4 Teste de Sistemas

O software apenas um elemento de um sistema baseado em
computador mais amplo. Este teste envolve um grande nmero de diferentes
testes, cujo propsito pr completamente prova o sistema baseado em
computador.
Entre os tipos de testes de sistemas destacamos: De recuperao,
de segurana, de estresse e de desempenho.
O teste de recuperao um teste de sistema que fora o software a falhar

de diversas maneiras e verifica se a recuperao executada.
O teste de segurana verifica se todos os mecanismos de proteo

embutidos no sistema o protegero.
O teste de estresse fora o sistema a usar recursos em quantidade,

freqncia ou volumes anormais.
O teste de desempenho feito para testar o desempenho do software em

tempo real.
9.8.3 Avaliao dos Res ultados

Completadas a fase de execuo dos testes, passaremos para a
avaliao dos mesmos. Isto ser feito analisando os relatrios elaborados
durante a fase anterior.
Esta fase de grande valia para vrios aspectos do sistema. Nesta
poderemos ter uma idia por completo de todo o desenvolvimento do projeto.
Podemos apontar falhas em determinadas fases do projeto
baseando-se nesta avaliao, bem como certificar-se da qualidade e/ou bom
desempenho do projeto.
105
Ocorrendo pequenos erros ou observaes que no interfiram no
objetivo do projeto, estes devero ser tratados diretamente com o responsvel
pela fase onde ocorreu o problema.
Quando na avaliao ocorrem problemas do tipo que tenha que ser
refeito alguma unidade por completo, isto geralmente estar comprometendo
os objetivos do projeto e, consequentemente dever ser de conhecimento de
toda a equipe envolvida no projeto.
Aps feitas as correes dos problemas encontrados, estando de
acordo com as especificaes definidas na anlise de requisitos e aceitas pelo
cliente, o software estar pronto para uso.
Captulo 10 - Validao da Metodologia
10.1 Introduo
Neste captulo documentaremos o prottipo desenvolvido baseado

na metodologia, mostrando a idia principal do sistema.
Sero abordados os seguintes itens : Formulrio de Documentao,
Contatos Iniciais, Ata da Reunio, Resumo do Projeto, Escopo, Lista de Caso
de Uso, Diagrama de Caso de Uso, Diagrama de Classes e Escolha da
Linguagem.
10.2 Formulrio de Do cumentao
Fonte
Tipo : Times New Roman
Gravao
Tamanho : 12
107
Pasta Me : Contabilidade
Descrio : Esta pasta contm toda a documentao do projeto do
sistema de contabilidade.
Extenso de Arquivos : .rtf
Impresso
Tamanho do papel: A4(210 X 297mm)
Backup
Responsvel: Reginaldo Darolt / Alexandre de Almeida
Periodicidade: Semanal.
Verso: 1.0A-01
10.3 Contatos Iniciais
Data: 14/03/2001
Razo Social: Escritrio Criciumense de Contabilidade
Solicitante: Joo da Silva
Departamento: Gerencial
Fone: 048-4371159
Fax : 048-4376020
Ramal: 203
Email: joaocri@terra.com.br
Descrio: Sistema de Contabilidade com capacidade de emitir os
relatrios legais como: dirio, razo, balancete aps os lanamentos nas
contas contbeis do plano de contas da empresa. Ir receber tambm
108
lanamentos dos sistemas de livros fiscais, folha de pagamento e controle
patrimonial. Ir gerar informaes gerenciais para o administrativo.
Tipo do pedido: (X ) Novo
( ) Alterao
rea de negcio do problema: Contbil

Prioridade:
(X) Normal
( ) Alta
( ) Urgente
Data pretendida para soluo: 12 meses
10.4 Ata da Reunio
Data : 21/03/2001
Hora Incio : 19:00 Hora Final: 22:30
Participantes: Alexandre de Almeida, Reginaldo Darolt e Joo da

Silva
Objetivos:
1.Definir a abrangncia do sistema.
2.Definir as possveis entradas de dados.
3.Definir os procedimentos padres do sistema.
4.Definir as sadas/relatrios que o usurio necessita.
5.Definir os possveis tipos de usurio do sistema.
Observaes: Utilizamos o mtodo questionrio para alcanar os
objetivos da reunio.
Definies da reunio:
1.O sistema ir abranger somente o mdulo de contabilidade
2.As
possveis
entradas
de
dados
no
sistema
sero:
Manual(atravs de digitao) e tambm automticas por outros sistemas.

Quando geradas por outros sistemas, estes devero estar conectados no
109
mesmo banco de dados e sem o auxlio de nenhuma rotina do mdulo de
contabilidade para execuo de tal tarefa.
3.Procedimentos:
Cadastro de Usurios.
Cadastro de Contas Contbeis e Histricos Padres.
Lanamentos.
Emisso de relatrios.
Definio
de
parmetros
do
sistema
como
perodo
de
lanamento e mscara contbil.

4.Relatrios:
Cadastrais: Contas e Histricos.
Acompanhamento de lanamentos.
Legais: Dirios, Razo, DRE, Balano e Livro Caixa.
Tempo gasto no sistema por usurio.
5.Usurios:
Contador
Digitador
Usurios de outros sistemas que somente faro lanamentos no

sistema quando conectados no mesmo banco de dados.
10.5 Resumo do Proje to
Um sistema de Contabilidade com cadastros de contas, histricos e

lanamentos. Recebe lanamentos do sistema de Livros Fiscais nos
110
lanamentos de notas, apurao e pagamento de impostos. Do Controle
Patrimonial recebe lanamentos na atualizao dos bens e no fechamento de
perodo. Na Folha de Pagamento recebe lanamentos no momento do clculo
mensal.
Este sistema gera informaes sobre tempo gasto do usurio para o
sistema administrativo. Emite relatrios cadastrais, de acompanhamentos e
tambm os relatrios legais tais como: Dirio, Razo, DRE, Balano e Livro
Caixa.
Para um bom desempenho do sistema ser necessrio o uso de
mquinas com configurao igual ou superior a PII 233 Mhz com 32 Mb.
Ambiente Windows95 ou Windows98, e para uma boa apresentao dos
relatrios faz-se necessrio impressora Jato de Tinta ou Laser. No caso de
mais de uma estao de trabalho, estas devero estar conectadas atravs de
uma rede que suporte as estaes no ambiente citado.
10.6 Escopo
Na figura 10.1 apresentamos o escopo do sistema:
111
Figura 10.1 Escopo do Sistema
10.7 Lista de Casos de Uso
UC001 - EFETUAR LANAMENTO

UC002 - MANTER CONTA CONTBIL
UC003 - MANTER PARMETROS
UC004 - MANTER PERMISSES
112
UC005 - EFETUAR LANAMENTOS LIVROS FISCAIS
UC006 - APURAR IMPOSTOS LIVROS FISCAIS
UC007 - PAGAR IMPOSTOS LIVROS FISCAIS
UC008 - FECHAR PERODO CONTROLE PATRIMONIAL
UC009 - MANTER BENS CONTROLE PATRIMONIAL
UC010 - NAVEGAR EM REGISTROS
UC011 - CALCULAR FOLHA DE PAGAMENTO
10.8 Diagrama de Caso de Uso
A figura 10.2 mostra o diagrama de casos de uso do Sistema de

Contabilidade.
113
Figura 10.2 Diagrama de Caso de Uso do Sistema de Contabilidade
10.9 Diagrama de Clas ses
Na figura 10.3 mostramos o diagrama de classes do Sistema de

Contabilidade.
114
Figura 10.3 Diagrama de Classes do Sistema de Contabilidade
10.10 Escolha da Lingu agem
Para desenvolvimento do Sistema de Contabilidade, escolhemos a

linguagem PowerBuilder verso 5.0.02 da Powersoft com o banco de dados
Sybase SQL Anywhere verso 5.0.03.
Captulo 11 - RESULTADOS OBTIDOS
Aps a validao da metodologia desenvolvida, obtemos alguns

resultados os quais julgamos ser necessrios destacar.
Neste captulo discriminaremos os pontos fortes e pontos fracos de
cada fase da metodologia desenvolvida.
Documentao
Pontos Fortes:
A extenso de arquivos utilizada nos auxiliou na comunicao

entre a equipe envolvida no projeto, devido ao fato de poder ser
manipulado nos diversos ambientes encontrados.
O backup nos salvou de refazer boa parte do projeto, pois

tivemos problemas com vrus na mquina principal onde estava o
projeto e a mesma teve de ser formatada.
Pontos Fracos:
Necessidade de um arquivo leia-me.rtf contendo todos os

arquivos utilizados no desenvolvimento do projeto e uma
pequena descrio de cada arquivo.
Estabelecimento de uma padronizao para nome de arquivos.
116
Eventos Iniciais
Pontos Fortes:
De um modo geral atendeu as necessidades, pois desde o

primeiro contato do cliente com a empresa, tudo foi registrado,
facilitando as prximas etapas.
Com o estudo da rea de
negcio ficou definido que a empresa atenderia a solicitao do

cliente.
Anlise de Requisitos
Pontos Fortes:
Com os tpicos abordados na reunio, obteve-se os objetivos

gerais e especficos pretendidos com o sistema. Ao final ficou
registrado na ata da reunio.
Os casos de uso foram bem detalhados, de modo que qualquer

membro do projeto entendeu o seu funcionamento. Facilitou no
desenvolvimento durante a fase de implementao.
O diagrama de caso de uso auxiliou na comunicao entre o

cliente e os desenvolvedores.
Pontos Fracos:
Na lista de Atores deveria ter tambm a data da criao do ator e

o autor que o criou, desta forma facilitaria no esclarecimento de
possveis dvidas sobre o ator.
Anlise
Pontos Fortes:
Seguindo as definies da metodologia, o diagrama de classes

foi facilmente desenvolvido e compreendido por toda a equipe.
117
Os diagramas de interao mostraram o fluxo de funcionamento

do sistema, como as informaes trafegam no mesmo.
Auxiliando desta forma na compreenso comportamental do
sistema.
O diagrama de estado mostrou de forma clara os eventos da

principal rotina do sistema que a rotina de lanamentos.
O diagrama de atividade mostrou de forma clara a ordem de

funcionamento do caso de uso manter contas.
Pontos Fracos:
O diagrama de objetos deveria ser detalhado na metodologia

para facilitar seu desenvolvimento.
Projeto
Pontos Fortes:
O diagrama de componentes nos auxiliaram na estruturao do

cdigo fonte, separando seus objetos de acordo com sua
finalidade.
O diagrama de implantao mostrou a toda a equipe a estrutura

fsica do cliente, bem como informaes essenciais para o
software como por exemplo o servidor de banco de dados.
Implementao
Pontos Fortes:
Conforme sugerido na metodologia, escolhemos uma linguagem

conhecida pelos desenvolvedores e que atendesse os requisitos
do projeto.
118
A documentao do cdigo foi de grande importncia durante o

desenvolvimento do sistema, pois todos os programadores
poderiam facilmente compreender as rotinas independentes do
autor da mesma. Esta documentao ainda ser muito utilizada
em futuras manutenes do sistema.
Testes
Na estratgia de testes no adotamos a fase de projetos porque
seus mtodos torna essa tarefa cansativa e tambm eleva os custos. uma
fase que pode ser eliminada sem comprometer a fase de testes do projeto.
Nas fases de teste demos nfase ao teste de unidade, cujo no nosso
ponto de vista o mais importante, os demais so apenas citados para que
sejam explorados caso algum tenha esta necessidade.
119
Captulo 12 - CONCLUSO
Em virtude das constantes inovaes que surgem em ferramentas

de desenvolvimento de sistemas orientadas a objetos, podemos afirmar a
importncia do uso de uma metodologia que englobe todas as fases do
processo, desde os eventos iniciais, passando pela anlise de requisitos,
anlise, projeto, implementao e testes. Durante a realizao do trabalho
constatamos o interesse por parte de desenvolvedores de software, de uma
metodologia deste nvel.
Com o desenvolvimento de sistemas mais complexos, necessrio
o uso de uma metodologia unificada, tanto para a comunicao entre toda a
equipe envolvida (cliente, analista, programador, etc), quanto para a
documentao(requisitos e cdigo-fonte).
Neste contexto, foi proposta uma metodologia de desenvolvimento
de sistemas orientados a objetos baseada em UML(Unified Modeling
Language), a partir da qual o desenvolvedor poder seguir suas etapas para o
fluxo correto do desenvolvimento de um projeto.
Aps o estudo da ferramenta CASE Rational Rose da Rational
Software Corporation, utilizamos a mesma no apoio a validao da
120
metodologia. Esta ferramenta mostrou-se bastante complexa e eficaz, pois ela
possui uma documentao interativa e automtica dos processos de
modelagem, permitindo at mesmo gerar cdigo-fonte a partir do modelo. Na
implementao do sistema utilizamos a ferramenta de desenvolvimento
chamada Power Builder pela facilidade da programao orientada a objetos,
bem como pelo conhecimento que todos envolvidos tinham da mesma.
Com o desenvolvimento do prottipo utilizando a metodologia,
podemos afirmar que os resultados esperados foram alcanados, tendo em
vista que esta atendeu todas as fases de desenvolvimento do prottipo. Desta
forma podemos dizer que a metodologia se torna necessria para um bom
desenvolvimento de sistema orientados a objetos.
12.1 Recomendaes
Este trabalho est aberto a futuros melhoramentos, e como

recomendaes futuras podemos ressaltar:
Aplicao da metodologia em um sistema complexo.
Estudo de novas ferramentas CASE.
Desenvolver
novas
pesquisas
visando
corrigir
os
pontos-fracos
encontrados.
Desenvolvimento de uma ferramenta CASE baseado-se na metodologia

desenvolvida.
Utilizao da metodologia no apoio s aulas de engenharia de software.
Captulo 13 - BIBLIOGRAFIA
1. BOOCH Grady et al. UML : Guia do Usurio, O mais avanado tutorial

sobre Unified Modeling Language. Rio de Janeioro. Campus, 2000.
2. SCHNEIDER, Geri et al. Applying Use Cases : A Pratical Guide.
Massachusetts. Addison-Wesley, 1998.
3. Technologies,
ADD.
Histrico
da
UML.
http://www.addtech.com.br.
Consultada em 24/03/2001.
4. CABRAL, Adelino Manuel de Oliveira et al. UML : Unified Modeling
Language. http://www.tutprog.cjb.net. Consultada em 24/03/2001.
5. SILVA, Leonardo de Arajo et al. UML : Diagrama de Atividade.
http://www.dcc.ufmg.br/~marcosfg/. Consultada em 24/03/2001.
6. UML - Diagramas de Implementao : importantes quando trata de
questes
como
reutilizao
http://www.dcc.ufmg.br/~gorgulho/tbd/seminario.html.
desempenho.
Consultada
em
24/03/2001.
7. UML Introduo : ao modelar alguma coisa, estamos criando uma
simplificao da realidade para um melhor entendimento do sistema.
http://www.dcc.ufmg.br/~lucanaan/tbd/texto.htm. Consultada 24/03/2001.
122
8. ARAJO, Bethnia Lagoeiro. Uma Contribuio para o Problema de
Compatibilizao
de
Modelos
na
http://www.dcc.ufmg.br/pos/html/spg98/node3.html
UML.
Consultada
em
24/03/2001.
9. CNPQ, UFSC. UML : Unified Modeling Language. Abrange sua histria,
definies, arquivos e sites relacionados. http://www.eps.ufsc.br/~wolff .
10. BARROS, Pablo. UML : Linguagem de Modelagem Unificada em
Portugus. http://cc.usu.edu/~slqz9/uml . Consultada em 24/03/2001 .
11. TECHMARK,
Engenharia
de
Software.
Tutoriais.
http://www.techmark.com.br/download.html . Consultada em 24/03/2001.

12. LARMAN, Craig. UTILIZANDO UML E PADRES : Uma introduo
anlise e ao projeto orientados a objetos. Porto Alegre -
Bookman,
2000.
13. FOWLER, Martin, Kendal Scott. UML ESSENCIAL : Um breve guia para a
linguagem padro de modelagem de objetos. Porto Alegre - Bookman,
2000.
14. PRESSMAN, Roger S. . ENGENHARIA DE SOFTWARE. So Paulo Makron Books ,1995.
15. RUMBAUGH, James, Michael Blaha, William Premerlani, Frederick Eddy,
Willian
Lorensen.
MODELAGEM
PROJETOS
BASEADOS
EM
OBJETOS. Rio de Janeiro - Campus, 1994.

16. FURLAN, Jos Davi. MODELAGEM DE OBJETOS ATRAVS DA UML :
The Unified Modeling Languagem. So Paulo - Makron Books, 1998.
123
17. MAZZOLA, Vitrio Bruno. CONCEITOS BSICOS DA ORIENTAO A
OBJETOS : Captulo 1, 1999.
18. COOD, Peter, Edward Yourdon. ANLISE BASEADA EM OBJETOS. Rio
de Janeiro - Campus, 1991.
19. YOURDON, Edward, Carl Argila. ANLISE E PROJETO ORINTADOS A
OBJETOS : Estudos de Casos. So Paulo - Makron Books, 1999.
20. SILVA, Nelson Peres da. PROJETO E DESENVOLVIMENTO DE
SISTEMAS. So Paulo - rica, 1998.
21. MIZRAHI, Victorine Viviane. TREINAMENTO EM C++. So Paulo - Makron
Books.
22. RATIONAL, Software Corporation. Rational Rose. www.rational.com.
23. DBSERVER, Ferramentas Case. Parceria Rational. www.dbserver.com.br.
124
1. Anexo 01 - Formulrio de documentao.

Fonte
Tipo : <nome da fonte>
Tamanho : <tamanho da fonte>
Gravao
Pasta Me : <Nome do Sistema>
Descrio : <Abaixo desta pasta me esto todos os arquivos
necessrios referentes a documentao do software>.
Extenso de Arquivos : <tipo da extenso>
Impresso
Tamanho do papel: <medidas do formulrio>
Backup
Responsvel: <Nome do responsvel pelo Backup>
Periodicidade:
Verso: <N.NX-NN>
125
2. Anexo 02 - Formulrio de contato.

Data: <dd/mm/aaaa> Data do contato do cliente
Razo Social: <Nome da Empresa solicitante do software>
Solicitante: <Nome para contato na empresa>
Departamento: <Departamento do solicitante>
Fone:
Fax :
Ramal:
Email:
Descrio: <Neste item deve-se tentar passar o mximo de
informaes possveis sobre a solicitao>
Tipo do pedido: ( ) Novo
( ) Alterao <Informar neste item se
trata-se de software e/ou rotina novos ou alterao>

rea de negcio do problema: < De acordo com o pedido deve-se
definir a rea de negcio, para que os envolvidos possam verificar se podem
atender ou no>
Prioridade:
( ) Normal
( ) Alta
( ) Urgente <Definir aqui a
prioridade do pedido>
Data pretendida para soluo: <O preenchimento se faz necessrio,
pois ser estudada pela equipe onde ser discutido a possibilidade ou no de
ser efetuada>
126
3. Anexo 03 - Formulrio da ata de reunio

Data : <dd/mm/aaaa> Hora Incio : <hh:mm>Hora Final: <hh:mm>
Participantes: <Nome1>, <Nome2>,....
Objetivos: <Deve definir o que se pretende alcanar com o sistema,
os setores atendidos>
Observaes:
<Definio
dos
itens
que
ajudaro
no
desenvolvimento do sistema>
Definies da reunio: <A definio engloba tudo o que foi definido
na reunio>
127
4. Anexo 04 - Formulrio lista de atores

Nome
Descrio
<Nome do ator>
<Descrever em poucas palavras
o que o ator faz e com o que ele interage>
128
5. Anexo 05 - Formulrio lista de casos de uso.

arquivo
caso de uso
<nome do arquivo >
<Nome do caso de uso que est no arquivo>
129
6. Anexo 06 - Formulrio de requisitos de caso de uso.

NOME : <Nome do caso de uso>
DESCRIO: <Descrever a funcionalidade do caso de uso>
ATORES: <Listar os atores que interagem no caso de uso>
DATA
ALTERAO
AUTOR
<data>
<Descrio da alterao>
<Listar os autores>
SITUAO INICIAL DO PROCESSO : <O que precisa para existir o

caso de uso>
FLUXO NORMAL: <Seqncia de passos que ocorre naturalmente
com maior freqncia. Esta seqncia dever ser ordenada e cada passo
corresponde a uma ao do usurio e uma resposta do sistema ou vice-versa>
FLUXOS ALTERNATIVOS: <Usa-se quando o fluxo normal no for
seguido. Neste caso, tambm sero feitas seqncias de passos alternativos
ordenados e identados conforme o fluxo normal que o gerou>
REQUISITOS MNIMOS: <Os dados que tem que existir ou eventos
que tem que ocorrer para que o caso de uso seja vlido>
PONTOS DE EXTENSO: <So casos de uso que usam outro caso
de uso>
VARIAES DE DADOS E TECNOLGICAS: <Mudanas que
podem ocorrem que iro afetar no funcionamento do sistema>
130
7. Anexo 07 - Formulrio Diagrama de caso uso

NOME : <Nome do diagrama>
DESCRIO: <Descrever em poucas palavras o propsito do
diagrama>
ATORES RELACIONADOS: <Listar todos os atores relacionados no
diagrama>
CASOS DE USO RELACIONADOS: <Listar todos os casos de uso
relacionados no diagrama>
DATA <data da criao/alterao>
ALTERAO <descrio da alterao>
AUTOR <nome do responsvel da criao/alterao>
131
8. Anexo 08 - Formulrio de Cronograma

Fase: <Fase do projeto>
Responsveis:
Nome do Responsvel
Assinatura
<Nome(s) do(s) responsvel(is) pela fase> <Assinatura de cada responsvel>
Data Prevista: <Data prevista para concluso da fase>
132
9. Anexo 09 - Formulrio de Aprovao

Fase: <Fase do projeto>
Declaramos que a presente fase est de acordo com o propsito do sistema.
Aprovado por
Nome
Assinatura
<Nome(s) do(s) responsvel(is) pela fase> <Assinatura de cada responsvel>

Data da Aprovao: <Data que fase foi aprovada>

Uml

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uml

Enviado por

Direitos autorais:

Formatos disponíveis

UNISUL UNIVERSIDADE DO SUL DE SANTA CATARINA

PESQUISA E DESENVOLVIMENTO EM UML

UNISUL UNIVERSIDADE DO SUL DE SANTA CATARINA

PESQUISA E DESENVOLVIMENTO EM UML

Projeto apresentado disciplina de

Aprovamos o Projeto PESQUISA E DESENVOLVIMENTO EM UML, elaborado

Prof. Carlos Fernando Buss

Prof. Luciano Savio

Prof. Alessandro Zanini

Prof. Ana Cludia G. Barbosa

Prof. Juarez Bento Da Silva

Dedicamos este Trabalho a nossos pais, namoradas e familiares que

LISTA DE FIGURAS ............................................................................................ xii

Figura 2.1 : Anlise Orientada a Objeto............................................................ 10

Usar uma metodologia de desenvolvimento de sistema para captar

To use a metodology of system development to obtain since the first

Um grande problema no desenvolvimento de novos sistemas

desenvolvedores da rea de orientao a objetos, ficaram entusiasmados com

desenvolvimento de sistemas baseada em UML, a qual analisamos ser o mais

1.2 Objetivos Geral e Especficos

Objetivamos com esta pesquisa o estudo aprofundado de uma

Obter amplos conhecimentos sobre UML;

Mostrar a sociedade a importncia do uso de uma metodologia no

Estudar como se desenvolve uma metodologia de desenvolvimento de

Desenvolver uma metodologia de trabalho baseado em UML;

Estudo de uma ferramenta CASE, para modelagem do sistema.

Desenvolvimento de um prottipo usando a metodologia;

Apresentao do prottipo desenvolvido.

Com as constantes inovaes que surgem em ferramentas de

A UML tende a ser uma linguagem de desenvolvimento de sistemas

Para o desenvolvimento do Trabalho de Concluso de Curso (TCC),

Estudo da metodologia UML;

Conceitos sobre esta metodologia;

Aprimoramento da metodologia usada, visando sua melhor performance;

Estudo e definio de uma ferramenta CASE que melhor atenda a essa

Estudo e definio de ferramentas para desenvolvimento do sistema;

Escolha de um sistema para aplicao da metodologia estudada

Desenvolvimento de um prottipo do sistema;

Concluso sobre a metodologia estudada e sua aplicao.

Este captulo apresentar a voc leitor, uma breve descrio de

No captulo 2 descreveremos um breve conceito da anlise e

O captulo 3 faz uma introduo UML(Linguagem Unificada de

O captulo 4 descreve as etapas tcnicas da UML, baseada nos

O captulo 5 faz uma descrio sobre ferramenta CASE, apresenta

No captulo 6 apresentado um conceito sobre vises em UML e

O captulo 7 traz uma definio de modelos de elementos e

O captulo 8 apresenta um conceito genrico sobre diagramas em

O captulo 10 mostra um prottipo desenvolvido aplicando a

No captulo 11 mostraremos os resultados obtidos durante a

No captulo 12 faremos nossas concluses sobre todo o TCC.

Captulo 2 - ANLISE E PROJETOS ORIENTADOS A

Com os enormes computadores da dcada de 1950 e 1960, e a

tinham que ser monolticos. Ou

seja, se j se chegou na melhor fase do algoritmo no necessrio mais

2.2 Anlise Orientada a Objetos

Anlise o estudo de um problema, antes de qualquer ao [De

declarao completa, consistente e possvel do que necessrio, um conjunto

Figura 2.1 : Anlise Orientada a Objeto

2.3 Projeto Orientado a Objetos

O Projeto Orientado a Objetos (PjOO) visto como o processo de

construo, ou seja, instrues,

recomendaes, estipulaes, qualificaes, regras, etc..

processos para implementar um sistema em um ambiente especfico, em busca

Figura 2.2 : Projeto Orientado a Objetos