To em UML

UNISUL – UNIVERSIDADE DO SUL DE SANTA CATARINA
PRÓ-REITORIA ACADÊMICA
CENTRO DE CIÊNCIAS EXATAS, AGRÁRIAS E DAS ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
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 Ciência da Computação II,
coordenado pelo Professor Luciano
Savio e orientado pelo Professor
Alessandro Zanini.
ARARANGUÁ – SC
2001
ii

TERMO DE APROVAÇÃO
PROJETO DE CONCLUSÃO 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 obtenção de Grau em Bacharel em
Ciência da Computação.
Prof. Carlos Fernando Buss

Coord. do Curso de Ciências da Computação
Banca de Avaliação
Prof. Luciano Savio

Coordenador de PCC
Prof. Alessandro Zanini

Orientador
Prof. Ana Cláudia 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, Domínio Sistemas Ltda e Betha
Sistemas Ltda, em especial ao colega Cristiano Tomasi(Betha Sistemas Ltda).

v
SUMÁRIO
LISTA DE FIGURAS ............................................................................................ xii
RESUMO............................................................................................................. xiv
ABSTRACT.......................................................................................................... xv
Capítulo 1 - INTRODUÇÃO ................................................................................... 1
1.1 Apresentação ............................................................................................ 1
1.2 Objetivos Geral e Específicos ................................................................... 2
1.3 Justificativa................................................................................................ 3
1.4 Abrangência .............................................................................................. 4
1.5 Metodologia............................................................................................... 4
1.6 Estrutura ................................................................................................... 5
Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A OBJETOS ..................... 8
2.1 Conceito.................................................................................................... 8
2.2 Análise Orientada a Objetos ..................................................................... 9
2.3 Projeto Orientado a Objetos.................................................................... 10
2.4 Classes ................................................................................................... 11
2.5 Objetos.................................................................................................... 11
2.6 Abstração ................................................................................................ 12

vi
2.6.1 Abstração de Procedimentos ........................................................... 12
2.6.2 Abstração de dados.......................................................................... 12
2.7 Encapsulamento ..................................................................................... 13
2.8 Herança .................................................................................................. 13
2.9 Polimorfismo ........................................................................................... 14
Capítulo 3 - UML ................................................................................................. 15
3.1 Introdução ............................................................................................... 15
3.2 Histórico .................................................................................................. 16
3.3 Aceitação ................................................................................................ 18
3.4 Padronização OMG................................................................................. 19
3.5 Aplicação ................................................................................................ 19
Capítulo 4 - ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML ....... 20
4.1 Análise de Requisitos.............................................................................. 20
4.2 Análise .................................................................................................... 21
4.3 Projeto..................................................................................................... 21
4.4 Programação........................................................................................... 22
4.5 Testes ..................................................................................................... 23
Capítulo 5 - FERRAMENTAS CASE................................................................... 24
5.1 Conceito.................................................................................................. 24
5.2 Vantagens............................................................................................... 26
5.3 Aceitação no Mercado ............................................................................ 27
5.4 O Futuro .................................................................................................. 28
5.5 Rational Rose.......................................................................................... 28
Capítulo 6 - VISÕES DE SISTEMAS................................................................... 30
6.1 Conceito.................................................................................................. 30
vii
6.2 Visão USE-CASE.................................................................................... 31
6.3 Visão Lógica............................................................................................ 31
6.4 Visão de Componentes........................................................................... 32
6.5 Visão de concorrência............................................................................. 32
6.6 Visão de Organização............................................................................. 33
Capítulo 7 - MODELOS DE ELEMENTOS.......................................................... 34
7.1 Definição ................................................................................................. 34
7.2 Classes ................................................................................................... 35
7.2.1 Nomes .............................................................................................. 36
7.2.2 Atributos ........................................................................................... 37
7.2.3 Operações ........................................................................................ 38
7.3 Objetos.................................................................................................... 39
7.4 Estados ................................................................................................... 40
7.5 Pacotes ................................................................................................... 42
7.6 Componentes.......................................................................................... 43
7.7 Relacionamentos .................................................................................... 43
7.7.1 Associações ..................................................................................... 44
7.7.1.1 Associações Normais .................................................................... 44
7.7.1.2 Associações Recursivas ................................................................ 45
7.7.1.3 Associações Qualificadas .............................................................. 46
7.7.1.4 Associações Exclusivas ................................................................. 46
7.7.1.5 Associações Ordenadas ................................................................ 47
7.7.1.6 Associações de Classe .................................................................. 47
7.7.1.7 Associações Ternárias................................................................... 48
7.7.1.8 Agregação...................................................................................... 49
viii
7.7.2 Generalizações................................................................................. 50
7.7.2.1 Generalização Normal ................................................................... 50
7.7.2.2 Generalização Restrita .................................................................. 51
7.7.3 Dependências e Refinamentos ........................................................ 52
7.8 Mecanismos Gerais ................................................................................ 53
Capítulo 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 Seqüência........................................................................ 62
8.7 Diagramas de Colaboração .................................................................... 63
8.8 Diagramas de Atividade .......................................................................... 64
8.9 Diagramas de Componentes .................................................................. 65
8.10 Diagramas de Implantação ................................................................... 66
Capítulo 9 - METODOLOGIA DESENVOLVIDA................................................. 68
9.1 Introdução ............................................................................................... 68
9.2 Documentação ........................................................................................ 69
9.2.1 Fonte ................................................................................................ 69
9.2.2 Gravação da Documentação ............................................................ 70
9.2.3 Extensão de Arquivos....................................................................... 71
9.2.4 Impressão......................................................................................... 71
9.2.5 Backup ............................................................................................. 72
9.2.6 Controle de Versões......................................................................... 72

ix
9.3 Eventos Iniciais ....................................................................................... 73
9.3.1 Contatos ........................................................................................... 74
9.3.2 Estudo dos Dados ............................................................................ 74
9.3.3 Definição dos Participantes .............................................................. 75
9.4 Análise de requisitos ............................................................................... 76
9.4.1 Reunião/Entrevista ........................................................................... 76
9.4.2 Preenchimento da ata da reunião..................................................... 79
9.4.3 Definições 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 Análise de riscos .............................................................................. 82
9.4.10 Cronograma ................................................................................... 83
9.4.11 Aprovação ...................................................................................... 84
9.5 Análise .................................................................................................... 84
9.5.1 Diagrama de Classes ....................................................................... 84
9.5.2 Diagrama de Objetos........................................................................ 85
9.5.3 Diagramas de Interação ................................................................... 86
9.5.3.1 Diagrama de Seqüência ................................................................ 87
9.5.3.2 Diagrama de Colaboração ............................................................. 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 implementação............................................................ 91
9.6.1.1 Diagrama de componente.............................................................. 91
9.6.1.2 Diagrama de implantação .............................................................. 93
9.7 Implementação........................................................................................ 95
9.7.1 Tradução .......................................................................................... 95
9.7.2 Escolha da Linguagem ..................................................................... 95
9.7.3 Documentação do Código ................................................................ 97
9.8 Testes ..................................................................................................... 99
9.8.1 Planejamento de Testes................................................................... 99
9.8.2 Execução de Testes ....................................................................... 100
9.8.2.1 Teste de Unidade......................................................................... 100
9.8.2.2 Teste de Integração ..................................................................... 102
9.8.2.3 Teste de Validação ...................................................................... 103
9.8.2.4 Teste de Sistemas ....................................................................... 104
9.8.3 Avaliação dos Resultados .............................................................. 104
Capítulo 10 - Validação da Metodologia ......................................................... 106
10.1 Introdução ........................................................................................... 106
10.2 Formulário de Documentação ............................................................. 106
10.3 Contatos Iniciais.................................................................................. 107
10.4 Ata da Reunião ................................................................................... 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
Capítulo 11 - RESULTADOS OBTIDOS ........................................................... 115
Capítulo 12 - CONCLUSÃO .............................................................................. 119
12.1 Recomendações ................................................................................. 120
Capítulo 13 - BIBLIOGRAFIA ........................................................................... 121

xii
LISTA DE FIGURAS
Figura 2.1 : Análise Orientada a Objeto............................................................ 10
Figura 2.2 : Projeto Orientado a Objetos .......................................................... 11
Figura 6.1 : Visões de Sistemas ........................................................................ 31
Figura 7.1 : Classes ............................................................................................ 36
Figura 7.2 : Nomes ............................................................................................. 37
Figura 7.3 : Atributos.......................................................................................... 38
Figura 7.4 : Operações ....................................................................................... 39
Figura 7.5 : Objetos ............................................................................................ 40
Figura 7.6 : Estados............................................................................................ 41
Figura 7.7 : Pacotes............................................................................................ 42
Figura 7.8 : Componentes.................................................................................. 43
Figura 7.9 : Associações Normais .................................................................... 45
Figura 7.10 : Associações Recursiva................................................................ 46
Figura 7.11 : Associações Qualificadas ........................................................... 46
Figura 7.12 : Associações Exclusivas .............................................................. 47
Figura 7.13 Associações de Classe .................................................................. 48
Figura 7.14 : Associações Ternárias................................................................. 48

xiii
Figura 7.15 : Agregação ..................................................................................... 49
Figura 7.16 : Agregação Compartilhada ........................................................... 49
Figura 7.17 : Agregação de Composição ......................................................... 49
Figura 7.18 : Generalização Normal .................................................................. 50
Figura 7.19 : Generalização de Sobreposição ................................................. 51
Figura 7.20 : Generalização Completa .............................................................. 52
Figura 7.21 : Relação de Dependência ............................................................. 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 Seqüência ............................................................... 63
Figura 8.6 : Diagramas de Colaboração ........................................................... 64
Figura 8.7 : Diagramas de Atividade ................................................................. 65
Figura 8.8 : Diagramas de Componentes ......................................................... 66
Figura 8.9 : Diagramas de Implantação ............................................................ 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 conclusão das etapas de desenvolvimento
de software, é de extrema importância. A UML(Unified Modeling Language) é a
junção das três mais conceituadas linguagens de modelagem orientados a
objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh), porém
a UML não possui um método 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 Análise de Requisitos,
Análise, Projeto, Programação e Testes.
Para a validação da metodologia desenvolvida será aplicada no
desenvolvimento de um protótipo. Utilizaremos a ferramenta case Rational
Rose, da Rational Software Corporation no apoio a modelagem do sistema.
Ao final do desenvolvimento de cada fase serão feitas observações
que servirão de conclusão 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 doesn’t 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 we’ll 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.
Capítulo 1 - INTRODUÇÃO
1.1 Apresentação
Um grande problema no desenvolvimento de novos sistemas
utilizando a orientação a objetos é o fato de não existir uma notação
padronizada e realmente eficaz que possa abranger qualquer tipo de aplicação.
Cada metodologia existente possui suas próprias notações (símbolos usados
para projetar modelos orientados a objetos), processos e ferramentas. Isso faz
com que a escolha do método a ser utilizado torne-se uma decisão
extremamente importante e freqüentemente leva a discussões e debates sobre
qual o melhor método, o mais avançado e adequado para ser utilizado em um
projeto específico.
Com o lançamento da UML (Unified Modeling Language)
desenvolvedores da área de orientação a objetos, ficaram entusiasmados com
sua abrangência. Pois a UML traz novos conceitos que normalmente não são
usados. Um bom entendimento da UML não é somente um conhecimento de

2
sua símbologia e significados, mas também um contexto geral de modelagem
orientada a objetos.
Com a junção das três 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 visões da linguagem. UML permite comunicar
certos conceitos mais claramente que as linguagens alternativas [Fowler,
2000].
A UML é uma padronização de modelagem orientado a objetos de
forma que qualquer sistema, seja qual for o tipo, possa ser modelado
corretamente, com consistência, fácil de se comunicar com outras aplicações,
simples de ser atualizado e compreensível.
Com este projeto pretendemos justamente pesquisar sobre esta
linguagem de modelagem, suas aplicações, vantagens e desvantagens. Como
conseqüência 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 Específicos
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 protótipo, comprovando sua eficiência e
funcionalidade.
3
Especificamente, os objetivos apresentados são:
• Obter amplos conhecimentos sobre UML;
• Mostrar a sociedade a importância 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 protótipo usando a metodologia;
• Apresentação do protótipo desenvolvido.
1.3 Justificativa
Com as constantes inovações 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 importância de sua aplicação, a qual poderá resolver muitos
problemas encontrados no decorrer de todo o desenvolvimento de um sistema.
Para isto será desenvolvido um protótipo utilizando-se desta metodologia.

4
1.4 Abrangência
A UML tende a ser uma linguagem de desenvolvimento de sistemas
orientado a objetos dominante, comum entre os melhores analistas e
desenvolvedores. Por conseqüência este projeto pretende comprovar a eficácia
do uso desta metodologia, com base no desenvolvimento de um protótipo.
Destacamos os principais tópicos :
A modelagem de sistemas (não apenas de software) usando os
conceitos da orientação a objetos;
Estabelecer uma união fazendo com que métodos conceituais sejam
também executáveis;
Estabelecer um método de comunicação 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 Conclusão de Curso (TCC),
serão definidas as seguintes etapas:
• Estudo da metodologia UML;
• Conceitos sobre esta metodologia;
• Aprimoramento da metodologia usada, visando sua melhor performance;

5
• Estudo e definição de uma ferramenta CASE que melhor atenda a essa
metodologia;
• Estudo e definição de ferramentas para desenvolvimento do sistema;
• Escolha de um sistema para aplicação da metodologia estudada
comprovando sua eficácia;
• Desenvolvimento de um protótipo do sistema;
• Conclusão sobre a metodologia estudada e sua aplicação.
1.6 Estrutura
Este capítulo apresentará a você leitor, uma breve descrição de
cada capítulo que constitui este trabalho.
No capítulo 2 descreveremos um breve conceito da análise e
projetos orientado a objetos bem como sua necessidade, surgimento, etc.
Faremos uma descrição da base da análise e projetos orientado a objetos
descrevendo seus pontos principais como classes, objetos, abstrações, etc.
Este capítulo é importante para o entendimento da análise orientada a objetos.
O capítulo 3 faz uma introdução à UML(Linguagem Unificada de
Modelagem) dizendo o que ela nos disponibiliza, sua aceitação, padronização
e aplicações. Para um melhor entendimento do processo de criação da UML
apresentaremos um histórico completo, desde o início das pesquisas até a
conclusão da última versão.

6
O capítulo 4 descreve as etapas técnicas da UML, baseada nos
conceitos tradicionais das atividades de desenvolvimento. Estas etapas vão
desde os primeiros passos(Análise de Requisitos) até a fase de testes.
O capítulo 5 faz uma descrição sobre ferramenta CASE, apresenta
algumas vantagens da aplicação desta ferramenta e também descreve sua
aceitação no mercado. Ao final deste capítulo ainda apresentamos uma visão
do futuro desta ferramenta.
No capítulo 6 é apresentado um conceito sobre visões em UML e
qual a importância destas visões para o entendimento do sistema. Descreve-se
ainda em detalhes as 5(cinco) visões utilizadas e o uso de cada uma destas
visões.
O capítulo 7 traz uma definição de modelos de elementos e
descreve detalhadamente todos os modelos de elementos utilizados pela UML,
tais como Classes, Objetos, Estados, Pacotes, Componentes e
Relacionamentos.
O capítulo 8 apresenta um conceito genérico 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 capítulo 9 apresentaremos a metodologia desenvolvida.
O capítulo 10 mostra um protótipo desenvolvido aplicando a
metodologia do capítulo anterior.
No capítulo 11 mostraremos os resultados obtidos durante a
validação de cada fase da metodologia.
No capítulo 12 faremos nossas conclusões sobre todo o TCC.
O capítulo 13 apresenta toda a bibliografia utilizada no
desenvolvimento do TCC.
Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A
OBJETOS
2.1 Conceito
Com os enormes computadores da década de 1950 e 1960, e a
pouca capacidade de processamento, desenvolvedores de programas tinham
que aproveitar ao máximo todo bit que o hardware disponibilizava. Já na
década de 1960 computadores transistorizados foram surgindo, o que na
época já era um grande avanço, substituindo os enormes computadores de
válvulas.
Desenvolvedores mais radicais afirmavam que os algoritmos para os
sistemas que esses computadores rodavam tinham que ser monolíticos. Ou
seja, se já se chegou na melhor fase do algoritmo não é necessário mais
alterações ou manutenções, ficando do mesmo jeito até deixar de ser usado.
Desenvolvedores menos radicais e com uma visão um pouco
diferente, afirmavam que os sistemas tinham que ser modularizados para que
9
fossem de mais fácil manutenção e compreensão. Este conceito foi mais aceito
a medida que os computadores foram aumentando sua capacidade.
Precursores da analise orientada a objeto, defendiam que devíamos
estruturar programas de computador de acordo com o problema a ser
resolvido. O termo Orientação a Objetos sugere abstrações do mundo real e
trechos de programas de computador, ou objeto.
Um grande fator da orientação a objetos é a reusabilidade. Estamos
reutilizando códigos de programas desde o início da computação. As técnicas
de orientação a objetos nos permitem muito mais que a reutilização de códigos,
podemos reutilizar requisitos, análise, projeto, planejamento de testes,
interfaces de usuário e arquiteturas, ou seja todos os componentes de
engenharia de software podem ser encapsulados como reutilizáveis.
2.2 Análise Orientada a Objetos
Análise é o estudo de um problema, antes de qualquer ação [De
Marco, 1978]
Análise é o estudo do domínio de um problema que leva a uma
especificação de comportamentos observáveis externamente. É uma
declaração completa, consistente e possível do que é necessário, um conjunto
de características operacionais quantificadas e funcionais.
Analisar é obter as necessidades de um sistema e o que este
precisa ser desenvolvido para satisfazer as necessidades do usuário. Analisar
não é definir como o sistema será desenvolvido, mas sim investigar o problema
conforme mostra a Figura 2.1.

10
A AOO tem dois propósitos. Primeiramente formalizar uma “visão”
do mundo real dentro do qual o sistema será desenvolvido, estabelecendo os
objetos que servirão como principais estruturas organizacionais do sistema de
software e também as que o mundo real impõe. Em segundo lugar, a AOO
formaliza a colaboração de um dado conjunto de objetos na execução do
trabalho do sistema de software que está sendo especificado. Esta
formalização representa como cada objeto se comunica com os demais.
Figura 2.1 : Análise Orientada a Objeto
2.3 Projeto Orientado a Objetos
O Projeto Orientado a Objetos (PjOO) é visto como o processo de
especificação das partes da construção, ou seja, instruções, guias,
recomendações, estipulações, qualificações, regras, etc.. Utilizamos estes
processos para implementar um sistema em um ambiente específico, em busca
da solução do problema conforme mostra a Figura 2.2.

11
Durante a PjOO é dado ênfase na elaboração dos elementos lógicos
do software [Larman, 2000]. Sendo implementados em uma linguagem de
programação orientada a objetos, os quais possuem atributos e métodos.
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 são funções
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 aplicação [Rumbaugh, 1994]. Objeto é uma entidade independente,
assíncrona e concorrente, armazena dados, encapsula serviços, troca

12
mensagens com outros objetos, e é modelado para executar as funções finais
do sistema.
2.6 Abstração
Abstração é o princípio de ignorar os aspectos de um assunto não
relevante para o propósito em questão, tornando possível uma concentração
maior nos assuntos principais [Cood, 1991]. Consiste na seleção que o analista
faz de alguns aspectos, ignorando outros. Existem duas formas de abstração,
de Procedimentos e de Dados.
2.6.1 Abstração de Proc edimentos
Princípio de que qualquer operação com um efeito bem definido
pode ser tratada por seus usuários como uma entidade única, mesmo que a
operação seja realmente conseguida através de alguma seqüência de
operações de nível mais baixo.
2.6.2 Abstração de dado s
Consiste em definir um tipo de dado conforme as operações
aplicáveis aos objetos deste tipo. Porém, estes objetos só podem ser
modificados e observados através destas operações.

13
2.7 Encapsulamento
Encapsular é omitir informações pelo princípio de que uma
determinada entidade esconde informações as quais são necessárias apenas à
mesma. É fundamental que o objeto proteja seus dados, não permitindo que o
usuário do objeto os acesse diretamente. Mas sim através de métodos se
houver necessidade[Furlan, 1998].
2.8 Herança
Esta é provavelmente a característica mais discutida da abordagem
orientada a objetos [Mazzola, 1999].
É a principal característica do processo de
Generalização/Especialização. Através da herança uma determinada sub-
classe herda todos os atributos e métodos da superclasse.
Permite a um analista especificar serviços e atributos comuns uma
só vez, assim como especializar e estender estes atributos e serviços em
casos específicos.
14
2.9 Polimorfismo
È o conceito usado em linguagens de programação orientada a
objetos para denotar a característica de que a linguagem suporta a utilização
do mesmo identificador (o mesmo nome) para métodos de classes diferentes.
Um conceito em teoria de tipo no qual um nome (como uma
declaração de variável) pode denotar objetos de muitas subclasses diferentes
que são relacionadas por alguma superclasse comum, assim, qualquer objeto
denotado por esse nome tem a capacidade de responder a algum conjunto
comum de operações de modos diferentes [Booch, 2000].

Capítulo 3 - UML
3.1 Introdução
A UML é a linguagem padrão 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 através de diferentes
tecnologias de implementação [Furlan, 1998].
A UML disponibiliza uma forma padrão de modelagem de projetos
de Sistemas, incluindo seus aspectos conceituais tais como processos de
negócios e funções do sistema, além de itens concretos como as classes
escritas em determinada linguagem de programação, processos de banco de
dados e componentes de software reutilizáveis.

16
3.2 Histórico
As linguagens de modelagem orientadas a objetos surgiram entre a
metade da década de 1970 e o final da década de 1980, à medida que o
pessoal envolvido com metodologia, diante de um novo gênero de linguagens
de programação orientadas a objeto e de aplicações cada vez mais
complexas, começou a experimentar métodos alternativos de análise e projeto.
A quantidade de métodos orientados a objetos aumentou de pouco mais de 10
para mais de 50 durante o período de 1989 a 1994. Muitos usuários desses
métodos 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 métodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon.
Todos eram métodos completos, alguns se destacavam em algum ponto,
porém tinham suas limitações. O método Booch destacava-se durante as fases
de projeto e construção de sistemas, o OOSE fornecia excelente suporte para
captura de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil
com a análise e sistemas de informações com uso de dados[Booch, 2000].
Na metade da década de 1990, Grady Booch (Rational Software
Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics)
criadores de métodos orientados a objetos, começaram a pegar as melhores
idéias e partiram para a criação 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 utilizável. Usando técnicas orientadas a objeto criariam uma
linguagem que iria desde o conceito até o sistema executável, não somente a
sistemas complexos mas também a sistemas menores e também a outros
problemas que não fossem sistemas de informação, podendo ser utilizado por
seres humanos e máquinas[Furlan, 1998].
A criação da UML iniciou oficialmente em outubro de 1994, quando
Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a
unificação dos métodos Booch e OMT[Furlan, 1998]. O esboço da versão 0.8
do Método Unificado foi lançado 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 versão 0.8, resultando o lançamento da versão
0.9 da UML em junho de 1996[Booch, 2000]. Foi então aprovada pela
comunidade de engenharia de software em geral. Muitas empresas ficaram
interessadas, foi então criada um consórcio com várias empresas interessadas
em dedicar recursos com o propósito de trabalhar uma definição mais forte e
completa da UML.
Empresas que contribuíram para a definição 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 à solicitação do próprio
OMG de propostas para uma linguagem padrão 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
propósito de formalizar a especificação da UML e de integrar a linguagem a
outros esforços de padronização. A versão 1.1 foi entregue a OMG em julho de
1997. Em setembro do mesmo ano, essa versão foi aceita pela ADTF (Analysis
and Design Task Force) e pelo Architecture Board do OMG e, posteriormente
submetida a votação de todos os membros da OMG. A versão 1.1 foi adotada
pela OMG em 14 de novembro de 1997[Booch, 2000].
A manutenção da UML foi então assumida pela RTF (Revision Task
Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lançou uma
revisão editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF
lançou a UML 1.3[Furlan, 1998].
3.3 Aceitação
Os criadores da UML procuraram desenvolver uma linguagem
unificada padrão que pudesse ser de fácil entendimento a todos. Preocuparam-
se em deixá-la aberta aos desenvolvedores, onde os mesmos pudessem criar
seu próprio método de trabalho.
Empresas desenvolvedoras de ferramentas estão livres para criarem
uma ferramenta aqueda ao uso da UML. Devido a necessidade de criação da

19
UML empresas e profissionais liberais da área estão desenvolvendo estudos
para melhor aplicá-la.
3.4 Padronização OM G
Quando se iniciaram os trabalhos para criação da UML, os criadores
tinham como intenção fazer sua aceitação com a distribuição da linguagem a
vários desenvolvedores.
A OMG (Object Management Group) fez um requerimento por uma
linguagem de modelagem padrão. Então 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 necessário sua padronização.
3.5 Aplicação
A UML pode ser usada para modelar várias fases de um sistema,
desde os primeiros contatos até a geração do código. É aplicada em qualquer
tipo de sistemas em termos de diagramas de orientação a objeto.
Geralmente é mais usada na modelagem de Softwares usando o
conceito de orientação a objetos, mas também pode ser aplicada em sistemas
mecânicos, de engenharia em geral, pode também ajudar na organização de
processos de uma organização.

Capítulo 4 - ETAPAS DO DESENVOLVIMENTO DE
SISTEMAS EM UML
4.1 Análise de Requis itos
Esta fase captura as intenções e necessidades dos usuários do
sistema a ser desenvolvido através do uso de funções chamadas "use-cases"
[Barros, 2001]. É a descrição das necessidades ou desejos de um determinado
sistema. O princípio básico da análise de requisitos é identificar e documentar o
que é realmente necessário, desta forma comunicando a todos os envolvidos
no projeto da forma mais clara possível, de maneira não-ambígua de modo que
os riscos sejam identificados sem correr riscos de imprevistos.
Através 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 são
modelados entre as funções que eles requerem, funções estas chamadas de
"use-cases". Os atores externos e os "use-cases" são modelados com

21
relacionamentos que possuem comunicação associativa entre eles ou são
desmembrados em hierarquia. Descrevemos um “use-case” através 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. Através do diagrama de “use-cases” mostraremos aos
atores externos(futuros usuários) o que estes podem esperar do sistema.
A análise de requisitos também pode ser desenvolvida baseada em
sistemas de negócios, e não apenas para sistemas de software
4.2 Análise
A fase de análise preocupa-se com as primeiras abstrações(classes
e objetos) e mecanismos presentes no contexto do problema[Larman, 2000].
Descrevemos as classes nos Diagramas de Classes e também para ajudar na
descrição dos “use-cases”, podendo estas estar ligados uma nas outras
através de relacionamentos.
Nesta fase modelamos somente as classes que pertencem ao
domínio principal do problema, ou seja, classes técnicas mais detalhadas não
estarão neste diagrama.
4.3 Projeto
Projeto cria uma representação do domínio de problema do mundo
real e leva-a a um domínio de solução que é o software [Pressman, 1995].

22
Nesta fase partimos para as soluções técnicas, através dos
resultados obtidos na fase da análise. Serão adicionadas novas classes para
oferecer uma infra-estrutura técnica tais como: interface do usuário e
periféricos, banco de dados, interação com outros sistemas, e outras mais. É
feita uma junção das classes da fase da análise com as classes técnicas da
nova infra-estrutura, podendo assim alterar tanto o domínio principal do
problema quanto a infra-estrutura.
Com a elaboração do projeto obtemos detalhadamente as
especificações para dar inicio a fase de programação.
4.4 Programação
Para que uma fase de programação possa ter um bom desempenho,
necessitamos de um projeto bem elaborado, consequentemente converteremos
as classes da fase do projeto para o código da linguagem orientada a objetos
escolhida. Se o desenho foi elaborado corretamente e com detalhes
suficientes, a tarefa de codificação é facilitada [Furlan, 1998].A complexidade
dessa conversão vai depender da capacidade da linguagem escolhida, no
entanto esta pode tornar-se fácil ou difícil de se realizar.
Em UML durante a elaboração dos modelos de análise e projeto,
devemos evitar traduzi-los em códigos. Cabendo esta tarefa à fase de
programação.
23
4.5 Testes
Na fase de teste executamos um programa com a intenção de
descobrir um erro[Pressman, 1995]. Testamos cada rotina ou processo
detalhadamente, bem como a integração de todos os processos e a aceitação.
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 estão os pontos mais críticos que
podem causar falhas. A outra forma de testes de uma rotina é feita por outro
usuário, pois este irá fazer um teste do seu modo, tendo a visão da rotina como
um todo. Os testes de integração são feitos usando as classes e seus
componentes de integração para verificar se estas classes estão realmente
colaborando uma com as outras conforme especificado nos modelos. Nos
testes de aceitação é verificado se o sistema está de acordo com o
especificado no diagramas de “use-cases”.
Por fim, o sistema será testado pelo usuário final e este verificará se
os resultados apresentados estão realmente de acordo com suas intenções
expressas no início do projeto.

Capítulo 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 não se utilizavam de software para fazer seu trabalho.
Tinham necessidade de visualizar o projeto como um todo, ao invés de analisá-
lo em partes. É difícil de acreditar que ferramentas de software tão simples
estejam ficando cada vez mais importantes nos dias de hoje [Cood, 1991].
Com a crescente demanda pela qualidade e integração de
softwares, e também pela unificação de planejamentos administrativos com a
análise, projeto e geração de sistemas, surgiu então as denominadas
Ferramentas Case.
25
Uma Ferramenta Case é um software que auxilia no ciclo de
desenvolvimento de um sistema desde a fase de análise até a fase de testes,
auxiliando também na manutenção do sistema.
Apoiam na utilização de metodologias e métodos, armazenam
informações em sua base de dados, tanto em forma de textos como em forma
gráfica, possibilitando a comunicação com o usuário, a aprovação das
definições de processos, fluxos de informações e atributos de entidades, não
esquecendo de nenhum passo da metodologia usada, proporcionando alto
nível de documentação.
As ferramentas CASE se dividem em 3 tipos:
• Integrated System CASE (I-CASE) , que visam desde a análise/projeto até a
geração do código. Tentam abranger tudo, porém "superlota" uma etapa
com vários tipos de sub-ferramentas com a intenção de abranger várias
metodologias.
• Case's de automação de uma fase(ou mais) de desenvolvimento, são
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 informação. O próprio
Rational Rose, segue como linha base a Orientação a Objetos.

26
5.2 Vantagens
Citamos algumas vantagens com a utilização de Ferramentas CASE
• Maior qualidade dos produtos finais: as ferramentas CASE diminuem a
probabilidade de erros, uma vez que podem ajudar no controle de
consistência dos dados em um ambiente de desenvolvimento, também
proporcionam maior eficácia dos produtos, ao auxiliarem as fases de
Análise e Teste do produto pelo usuário;
• Produtividade: ao ajudar na realização 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;
• Eliminação de trabalho que muitas vezes não agregam valor ao produto
final: as ferramentas CASE podem realizar algumas tarefas cansativas para
os desenvolvedores, tais como procurar informações e desenhar símbolos
de um diagrama, as quais são mais sucetíveis ao erro;
• Mais tempo para a tomada de decisão: em conseqüência de as ferramentas
realizarem certas atividades pelas pessoas, estas ficam liberadas para
outras tarefas, geralmente mais nobres, que exigem tomada de decisão e
criatividade, ao invés de tarefas repetitivas;
• Flexibilidade para mudanças: as ferramentas permitem que sejam mudados
dados e diagramas de maneira mais rápida e fácil, o que ajuda o
desenvolvedor no trabalho de tentar satisfazer o usuário;
• Menos programação: as ferramentas eliminam muito tempo do trabalho de
programação, deixando mais tempo para que a equipe técnica se preocupe

27
com a Análise do Sistema, que é onde se define como solucionar o
problema do usuário;
• Melhor documentação: por armazenarem dados e diagramas, as
ferramentas também contribuem para uma melhor documentação do
sistema, agilizando relatórios, busca de informações e alterações;
• Manutenção mais fácil e ágil: por conseqüência do item anterior, é possível
ter mais informações sobre o software na hora de realizar sua manutenção
(correção, atualização ou expansão).
As Ferramentas Case nos auxiliam em todas as fases do projeto,
portanto seu uso é de extrema importância, considerando suas vantagens não
vemos outra saída para um projeto bem desenvolvido e documentado.
5.3 Aceitação no Mer cado
A aceitação 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 diagramação.
Hoje em dia, há também a difusão do termo I-CASE, que é usado
para caracterizar um grupo de ferramentas CASE integradas, isto é, que se
relacionam entre si (entradas e saídas) e que permitem controlar a consistência
dos dados quando seguimos uma metodologia.

28
5.4 O Futuro
Podemos dizer que as ferramentas CASE, evoluirão não de uma
forma fechada, mas de uma forma aberta de maneira que as mesmas cada vez
mais se integrarão com outras ferramentas de fabricantes distintos.
A palavra de ordem dos CASE's de amanhã é diversidade e
especialização. O conceito de CASE's apenas se transformou. O conceito de
CASE de amanhã nasceu hoje. Ou melhor, sofreu uma mutação mercadológica
dado o poder dos fabricantes. Entender o conceito é importante, mas entender
a evolução do mesmo é também importante.
5.5 Rational Rose
Rational Rose é uma ferramenta CASE para desenvolvimento de
sistemas orientados a objetos, sendo também, um repositório para os produtos
gerados por processos de análise e projetos orientados a objetos. Ela acelera
esse desenvolvimento de análise e projetos utilizando metodologias de
desenvolvimento muito difundidas no meio da informática, principalmente o
padrão Unified Modeling Language (UML). O padrão UML é o mais utilizado
hoje em dia, pois com ele há uma documentação interativa e automática dos
processos de modelagem, sendo também possível a geração, pela ferramenta,
de códigos a partir da mesma modelagem. As versões mais novas ferramenta
contemplam até a interação 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 construção baseada em análise
orientada a objetos [DBSERVER, 2001].
Segundo RATIONAL, a ferramenta Rational Rose é uma solução
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 código e o projeto.
• Modelagem de Banco de Dados e Análise : Oferece em uma única
ferramenta linguagem e notação 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 usuários UNIX a mesma interface do usuário
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.

Capítulo 6 - VISÕES DE SISTEMAS
6.1 Conceito
O desenvolvimento de um sistema complexo não é uma tarefa fácil.
O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e
que este representasse por completo as reais intenções do sistema sem
ambigüidades, sendo facilmente interpretável [Barros, 2001].
Um sistema é composto por diversos aspectos: funcional (que é sua
estrutura estática e suas interações dinâmicas), não funcional (requisitos de
tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais
(organização do trabalho, mapeamento dos módulos de código, etc.).
Descrevemos um sistema em várias visões, cada visão mostra alguma
particularidade do sistema e estão em alguns de diagramas.
Algumas visões estão interligadas através de diagramas, podendo
uma visão fazer parte de uma ou mais visões. Os diagramas que compõem as
31
visões contém os modelos de elementos do sistema. A Figura 6.1 apresenta as
cinco visões de sistemas.
Figura 6.1 : Visões de Sistemas
6.2 Visão USE-CASE
Descreve a funcionalidade do sistema desempenhada pelos atores
externos do sistema (usuários). A visão use-case é central, já que seu
conteúdo é base do desenvolvimento das outras visões do sistema. Essa visão
é montada sobre os diagramas de use-case e eventualmente diagramas de
atividade.
6.3 Visão Lógica
Descreve como a funcionalidade do sistema será implementada. É
feita principalmente pelos analistas e desenvolvedores. Em contraste com a
visão use-case, a visão lógica observa e estuda o sistema internamente. Ela

32
descreve e especifica a estrutura estática do sistema (classes, objetos, e
relacionamentos) e as colaborações dinâmicas quando os objetos enviarem
mensagens uns para os outros para realizarem as funções do sistema.
Propriedades como persistência e concorrência são definidas nesta fase, bem
como as interfaces e as estruturas de classes. A estrutura estática é descrita
pelos diagramas de classes e objetos. O modelamento dinâmico é descrito
pelos diagramas de estado, seqüência, colaboração e atividade.
6.4 Visão de Compon entes
É uma descrição da implementação dos módulos e suas
dependências. É principalmente executado por desenvolvedores, e consiste
nos componentes dos diagramas.
6.5 Visão de concorrê ncia
Trata a divisão do sistema em processos e processadores. Este
aspecto, que é uma propriedade não funcional do sistema, permite uma melhor
utilização do ambiente onde o sistema se encontrará, se o mesmo possui
execuções paralelas, e se existe dentro do sistema um gerenciamento de
eventos assíncronos. Uma vez dividido o sistema em linhas de execução de
processos concorrentes (threads), esta visão de concorrência deverá mostrar
como se dá a comunicação e a concorrência destas threads. A visão de
concorrência é suportada pelos diagramas dinâmicos, que são os diagramas

33
de estado, seqüência, colaboração e atividade, e pelos diagramas de
implementação, que são os diagramas de componente e execução.
6.6 Visão de Organiza ção
Finalmente, a visão de organização mostra a organização física do
sistema, os computadores, os periféricos e como eles se conectam entre si.
Esta visão será executada pelos desenvolvedores, integradores e testadores, e
será representada pelo diagrama de execução.

Capítulo 7 - MODELOS DE ELEMENTOS
7.1 Definição
Os conceitos usados nos diagramas são chamados de modelos de
elementos [Barros, 2001]. Um modelo de elemento é definido com a semântica,
a definição formal do elemento com o exato significado do que ele representa
sem definições duvidosas ou ambíguas e também define sua representação
gráfica 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 são as
classes, objetos, estados, pacotes e componentes. Os relacionamentos
também são modelos de elementos, e são usados para conectar outros
modelos de elementos entre si.

35
7.2 Classes
As classes são os blocos de construção mais importantes de
qualquer sistema orientado a objetos [Booch, 2000].
Uma classe é uma descrição de um conjunto de objetos que
compartilham os mesmo atributos, operações, relacionamentos e semântica.
Podem ser implementadas em uma ou mais interfaces.
Todos os objetos são instâncias de classes, onde a classe descreve
as propriedades e comportamentos daquele objeto.
Em UML as classes são representadas por um retângulo dividido em
três compartimentos: o compartimento de nome, que conterá apenas o nome
da classe modelada, o de atributos, que possuirá a relação de atributos que a
classe possui em sua estrutura interna, e o compartimento de operações, que
serão os métodos de manipulação de dados e de comunicação de uma classe
com outras do sistema(ver Figura 7.1). A sintaxe usada em cada um destes
compartimentos é independente de qualquer linguagem de programação,
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 seqüência 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 instâncias da propriedade podem apresentar. Uma
classe pode ter qualquer número de atributos ou nenhum. Um atributo
representa o tipo de dados ou estados que cada item de uma classe pode
assumir, são representados logo após o nome da classe (veja Figura 7.3).
38
Figura 7.3 : Atributos
7.2.3 Operações
Operações são os processos que a classe pode realizar.
Operações correspondem claramente a métodos em uma classe. No
nível de especificação, as operações correspondem a métodos públicos.
Normalmente, você não mostra as operações que simplesmente manipulam
atributos, porque elas podem ser freqüentemente inferidas. Entretanto, você
poderá ter que identificar seu um dado atributo é somente para leitura(isto é, o
seu valor nunca muda). No modelo de implementação, você também pode
querer mostrar operações privativas(private) e protegidas(protected).
Uma classe pode ter várias operações ou até mesmo nenhuma, são
representadas logo após os atributos (veja Figura 7.4).

39
Figura 7.4 : Operações
7.3 Objetos
Os objetos são 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 derivação de estudos da estrutura e
comportamento de outros objetos do mundo real. Corresponde a qualquer
coisa que tenha algum significado para uma dada aplicação [Mazzola,
1999].Por exemplo, uma máquina, uma organização, ou negócio.
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 condição ou situação na vida de um objeto
durante a qual o objeto satisfaz alguma condição, 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 ligações com outros
objetos.
Um objeto muda de estado quando acontece algo, o fato do objeto
alterar o seu estado chamamos de evento. Analisando as mudanças de estado
que um objeto pode sofrer, podemos prever todos os possíveis comportamento
de um objeto de acordo com os eventos que o mesmo possa sofrer.
Um estado pode ter três 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 variáveis de estado, onde os atributos do objeto em
questão pode ser listados e atualizados;
• Atividades – o compartimento de atividades é onde podemos listar os
eventos e ações. Está dividido em três eventos padrões : 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 próximo 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 propósito 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 são ligados ou referenciados
por um pacote são chamados de "Conteúdo do pacote". Um pacote possui
vários modelos de elementos, e isto significa que estes não podem ser
incluídos 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 não possuam semânticas
definidas para suas instâncias. Os relacionamentos permitidos entre pacotes
são de dependência, refinamento e generalização (herança).

43
O pacote tem uma grande similaridade com a agregação. O fato de
um pacote ser composto de modelos de elementos cria uma agregação de
composição. Se este for destruído, todo o seu conteúdo também será.
7.6 Componentes
Um componente pode ser tanto um código em linguagem de
programação como um código executável 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 representação de componentes.
Figura 7.8 : Componentes
7.7 Relacionamentos
Os relacionamentos ligam classes/objetos entre si criando relações
lógicas entre estas entidades [Barros, 2001]. Possuímos três tipos de
relacionamentos: associação, generalização e Dependência/Refinamentos.

44
• Associação: É uma conexão entre classes, e também significa que é uma
conexão entre objetos daquelas classes. Em UML, uma associação é
definida com um relacionamento que descreve uma série de ligações, onde
a ligação é definida como a semântica entre as duplas de objetos ligados.
• Generalização: É um relacionamento de um elemento mais geral e outro
mais específico. O elemento mais específico pode conter apenas
informações adicionais. Uma instância (um objeto é uma instância de uma
classe) do elemento mais específico pode ser usada onde o elemento mais
geral seja permitido.
• Dependência e Refinamentos: Dependência é um relacionamento entre
elementos, um independente e outro dependente. Uma modificação é um
elemento independente afetará diretamente elementos dependentes do
anterior. Refinamento é um relacionamento entre duas descrições de uma
mesma entidade, mas em níveis diferentes de abstração.
7.7.1 Associações
Associação é uma relação que descreve um conjunto de vínculos
entre elementos de modelo [Furlan, 1998].Representa a ligação entre classes
ou objetos de classes, podendo ambas conhecer-se. Uma associação é
definida em UML como relacionamento.
7.7.1.1 Associações Norm ais
O tipo mais comum de associação é apenas uma conexão entre
classes. É representada por uma linha sólida entre duas classes. A associação
45
possui um nome (junto à linha que representa a associação), normalmente um
verbo, mas substantivos também são permitidos.
Pode-se também colocar uma seta no final da associação indicando
que esta só pode ser usada para o lado onde a seta aponta. Mas associações
também podem possuir dois nomes, significando um nome para cada sentido
da associação (ver Figura 7.9).
Para expressar a multiplicidade entre os relacionamentos, um
intervalo indica quantos objetos estão relacionados na ligação. O intervalo pode
ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários
(1..*), dois (2), cinco para 11 (5..11) e assim por diante. É também possível
expressar uma série de números como (1, 4, 6..12). Se não for descrito
nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou
apenas 1).
Figura 7.9 : Associações Normais
7.7.1.2 Associações Recu rsivas
Podemos conectar uma classe a ela mesma, usando uma
associação recursiva, e ainda podemos representar a conexão entre dois
objetos, sendo os mesmos da mesma classe, conforme mostra a Figura 7.10.

46
Figura 7.10 : Associações Recursiva
7.7.1.3 Associações Quali ficadas
Associações qualificadas são usadas com associações de um para
vários (1..*) ou vários para vários (*). O "qualificador" (identificador da
associação qualificada) especifica como um determinado objeto no final da
associação "n" é identificado, e pode ser visto como um tipo de chave para
separar todos os objetos na associação. O identificador é desenhado como
uma pequena caixa no final da associação junto à classe de onde a navegação
deve ser feita (ver Figura 7.11).
Figura 7.11 : Associações Qualificadas
7.7.1.4 Associações Exclu sivas
Podemos encontrar em alguns modelos combinações não válidas.
Uma associação exclusiva é uma restrição em duas ou mais associações. Ela
especifica que objetos de uma classe podem participar de no máximo uma das
associações em um dado momento. Uma associação exclusiva é representada

47
por uma linha tracejada entre as associações que são parte da associação
exclusiva, com a especificação "{ou}" sobre a linha tracejada.
Figura 7.12 : Associações Exclusivas
Conforme figura 7.12 um contrato não 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 Associações Orden adas
As associações entre objetos podem ter uma ordem implícita. O
padrão para uma associação é desordenada ou seja não possui uma ordem
específica. Podemos resolver este problemas usando a associação ordenada,
ajudando pois existem casos que a ordem precisa estar concisa para o
entendimento da associação. Podemos escrever está associação apenas como
{ordenada} junto a linha da associação.
7.7.1.6 Associações de Cl asse
Uma classe pode ser associada a uma outra associação. Este tipo
de associação não é conectada a nenhuma das extremidades da associação já
existente, mas na própria linha da associação. Esta associação serve para se
adicionar informações extra a associação já existente (ver Figura 7.13).

48
Figura 7.13 Associações de Classe
A associação da classe Fila com a associação das classes Cliente e
Processo pode ser estendida com operações de adicionar processos na fila,
para ler e remover da fila e de ler o seu tamanho. Se operações ou atributos
são adicionados à associação, ela deve ser mostrada como uma classe.
7.7.1.7 Associações Terná rias
A associação ternária e a associação entre três classes. Ela é
mostrada como um grade losango (diamante) e ainda suporta uma associação
de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do
losango para a classe onde seria feita a associação ternária.
Figura 7.14 : Associações Ternárias
Conforme mostra a Figura 7.14 a associação ternária especifica que
um cliente poderá possuir 1 ou mais contratos e cada contrato será composto
de 1 ou várias regras contratuais.

49
7.7.1.8 Agregação
A agregação é uma caso particular da associação, indica que uma
das classes do relacionamento é uma parte, ou está contida em outra classe.
As palavras chaves usadas para identificar uma agregação são: "consiste em",
"contém", "é parte de" (ver Figura 7.15).
Figura 7.15 : Agregação
Existem tipos especiais de agregação que são as agregações
compartilhadas e as compostas.
• Agregação Compartilhada: É dita compartilhada quando uma das classes é
uma parte, ou está contida na outra, mas esta parte pode estar contida na
outra várias vezes em um mesmo momento (ver Figura 7.16).
Figura 7.16 : Agregação Compartilhada
• Agregação de Composição: É uma agregação onde uma classe que está
contida na outra "vive" e constitui a outra. Se o objeto da classe que contém
for destruído, as classes da agregação de composição serão destruídas
juntamente já que as mesmas fazem parte da outra (ver Figura 7.17).
Figura 7.17 : Agregação de Composição

50
7.7.2 Generalizações
Um relacionamento de taxinomia entre um elemento mais geral e um
elemento mais específico que é completamente consistente com o primeiro
elemento somando-o informação adicional especializado [Furlan, 1998].
Um objeto mais específico pode ser usado como uma instância do
elemento mais geral. A generalização, também chamada de herança, permite a
criação de elementos especializados em outros.
Existem alguns tipos de generalizações que variam em sua
utilização a partir da situação. São elas: generalização normal e restrita. As
generalizações restritas se dividem em generalização de sobreposição,
disjuntiva, completa e incompleta.
7.7.2.1 Generalização Nor mal
Na generalização normal a classe mais específica, chamada de
subclasse, herda tudo da classe mais geral, chamada de superclasse (ver
Figura 7.18). Os atributos, operações e todas as associações são herdadas.
Figura 7.18 : Generalização Normal
Uma classe pode ser tanto uma subclasse quanto uma superclasse,
se ela estiver numa hierarquia de classes que é um gráfico onde as classes
estão ligadas através de generalizações.
A generalização 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 generalização.

51
7.7.2.2 Generalização Res trita
Uma restrição aplicada a uma generalização especifica informações
mais precisas sobre como a generalização deve ser usada e estendida no
futuro. As restrições a seguir definem as generalizações restritas com mais de
uma subclasse:
• Generalizações de Sobreposição e Disjuntiva: Generalização de
sobreposição significa que quando subclasses herdam de uma superclasse
por sobreposição, novas subclasses destas podem herdar de mais de uma
subclasse (ver Figura 7.19). A generalização disjuntiva é exatamente o
contrário da sobreposição e a generalização é utilizada como padrão.
Figura 7.19 : Generalização de Sobreposição
• Generalizações Completa e Incompleta: Uma restrição simbolizando que
uma generalização é completa significa que todas as subclasses já foram
especificadas, e não existe mais possibilidade de outra generalização a
partir daquele ponto (ver Figura 7.20). A generalização incompleta é
exatamente o contrário da completa e é assumida como padrão da
linguagem.
52
Figura 7.20 : Generalização Completa
7.7.3 Dependências e Re finamentos
Uma dependência indica a ocorrência de um relacionamento
semântico entre dois ou mais elementos do modelo onde uma classe cliente é
dependente de alguns serviços da classe fornecedora, mas não tem uma
dependência estrutural interna com esse fornecedor [Furlan, 1998].
Uma mudança no elemento independente irá afetar o modelo
dependente. Como no caso anterior com generalizações, 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 parâmetro, uma
classe acessa o objeto global da outra. Nesse caso existe uma dependência
entre estas duas classes, apesar de não ser explícita.
Uma relação de dependência é simbolizada por uma linha tracejada
com uma seta no final de um dos lados do relacionamento. E sobre essa linha
o tipo de dependência que existe entre as duas classes. Conforme mostra a
figura 7.21, as classes "Amigas" provenientes do C++ são um exemplo de um
relacionamento de dependência.
Figura 7.21 : Relação de Dependência

53
Os refinamentos são um tipo de relacionamento entre duas
descrições de uma mesma coisa, mas em níveis de abstração diferentes e
podem ser usados para modelar diferentes implementações de uma mesma
coisa (uma implementação simples e outra mais complexa, mas também mais
eficiente).
Os refinamentos são simbolizados por uma linha tracejada com um
triângulo no final de um dos lados do relacionamento e são usados em modelos
de coordenação (ver Figura 7.22). Em grandes projetos, todos os modelos que
são feitos devem ser coordenados. Coordenação de modelos pode ser usada
para mostrar modelos em diferentes níveis de abstração que se relacionam e
mostram também 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
informações adicionais.
• Ornamentos: ornamentos gráficos são anexados aos modelos de
elementos em diagramas e adicionam semânticas ao elemento. Um
exemplo de um ornamento é o da técnica de separar um tipo de uma
instância. Quando um elemento representa um tipo, seu nome é mostrado
em negrito. Quando o mesmo elemento representa a instância de um tipo,

54
seu nome é escrito sublinhado e pode significar tanto o nome da instância
quanto o nome do tipo. Outros ornamentos são os de especificação de
multiplicidade de relacionamentos, onde a multiplicidade é um número ou
um intervalo que indica quantas instâncias de um tipo conectado pode estar
envolvido na relação.
• Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem
importar o quanto extensa ela seja. Para permitir adicionar informações a
um modelo não 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 informação (ver
Figura 7.23).
Figura 7.23 : Ornamentos e Nota

Capítulo 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, colaborações, componentes, dependências, generalizações,
associações, etc. Os diagramas são meios utilizados para visualização de
blocos de construção [Booch, 2000].
Os diagramas utilizados pela UML são compostos de nove tipos:
diagramas de casos de uso, classes, objetos, estados, sequência, colaboração,
atividade, componentes e execução. 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 relação entre os atores e os casos de uso
[Larman, 2000].
Os casos de uso são usados para modelar como um sistema ou
empresa funciona, ou como os usuários desejam que ele funcione. Os casos
de uso geralmente são o ponto de partida da análise orientada a objetos
utilizando a UML.
O modelo de caso de uso consiste de atores e casos de uso. Os
atores representam usuários e outros sistemas que interagem com sistema
modelado. Eles são representados graficamente por um homem palito. Os
casos de uso mostram o comportamento do sistema, cenários que o sistema
percorre em resposta ao estímulo de um ator. Eles são 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 participação deste ator no caso de uso. Além deste
relacionamento, existe dois outros tipos de relacionamentos entre casos de
uso:
• o relacionamento estender: é representado graficamente por uma seta com
o estereótipo <<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 estereótipo
<<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 lógica estática em uma superfície de duas
dimensões mostrando uma coleção de elementos declarativos de modelo,
como classes, tipos e seus respectivos conteúdos e relações [Furlan, 1998]
(ver Figura 8.2).

58
Uma classe em UML é representada por uma caixa retangular com
três compartimentos: um com o nome da classe, o outro com a lista de
atributos da classe e o último com a lista de operações da classe.
As associações representam relacionamentos estruturados entre
objetos de diferentes classes, e são representados graficamente através de
uma linha conectando as classes. Uma associação pode ter um nome. E as
extremidades da linha que representa uma associação pode ter nome de
papéis mostrando como a classe é vista pelas outras classes na associação.
A multiplicidade de uma associação especifica quantas instâncias de
uma classe relacionam-se a uma única instância de uma classe associada.
Uma multiplicidade é representada por um intervalo de valores possíveis, no
seguinte formato: limite_inferior..limite_superior, onde esses limites são valores
inteiros ( o caracter * pode ser usado como limite_superior para indicar falta de
limite).
A agregação é uma forma especial de associação que representa o
relacionamento todo-parte entre objetos. Ela é representada incluindo-se um
losango na extremidade do objeto todo do relacionamento todo-parte.
A generalização é uma ferramenta poderosa para a abstração. A
generalização é um relacionamento existente entre uma classe mais
geral(superclasse) e uma classe mais específica(subclasse), onde a classe
mais específica é consistente com a mais geral e adiciona informações a ela.
Uma generalização é representada por uma linha com um triângulo, que liga a
classe mais específica a mais genérica. 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 instâncias 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 não são importantes apenas para a visualização,
especificação e documentação de modelos estruturais, mas também para a
construção de aspectos estáticos de sistemas por meio de engenharia de
produção e engenharia reversa [Booch, 2000] (ver Figura 8.3).
A UML permite a utilização de diagramas de classes para uma
visualização dos aspectos estáticos dos blocos de construção do sistema. Você
usa os diagramas de interação para visualizar os aspectos dinâmicos de seu

60
sistema, formados por instâncias desses blocos de construção e mensagens
enviadas entre eles. Os diagramas de objetos cobrem um conjunto de
instâncias dos itens encontrados nos diagramas de classes. O diagramas de
objetos, portanto, expressa a parte estática de uma interação, 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 são usados para fazer a modelagem da
visão de projeto estática ou da visão de processo estática de um sistema, da
mesma forma como faz com os diagramas de classes, mas a partir da
perspectiva de instâncias reais ou prototípicas. Isso envolverá a modelagem de
um retrato do sistema em determinado momento e a representação de um
conjunto de objetos, seus estados e relacionamentos. Essa visão atende
principalmente aos requisitos funcionais do sistema – ou seja, os serviços que
o sistema deverá proporcionar aos seus usuários finais. Os diagramas de
objetos permitem que você faça a modelagem de estruturas de dados
estáticos.
Figura 8.3 : Diagramas de Objeto

61
8.5 Diagramas de Est ados
Os diagramas de estados são usados para modelar o
comportamento dinâmico de um sistema. Mostram o ciclo de vida de um objeto
em níveis de detalhe arbitrariamente simples ou complexos [Larman, 2000].
Visualizam a seqüência de estados que um objeto ou uma interação percorre
durante sua vida em resposta a estímulos recebidos, junto com suas próprias
ações e respostas conforme mostra a Figura 8.4.
Por exemplo, o comportamento de um objeto é modelado em função
de qual estado ele está inicialmente, e para qual estado ele vai passar quando
um determinado evento ocorrer.
Os estados representam as condições dos objetos em um
determinado momento.
Os eventos representam incidentes que causam a mudança de um
estado para outro. As linhas de transição descrevem o movimento de um
estado para o outro. Cada linha de transição é rotulada com o evento que
causou a transição.
62
Figura 8.4 : Diagramas de Estados
8.6 Diagramas de Seq üência
Os diagramas de seqüências são usados para modelar a interação
entre objetos em um sistema. Tipicamente, um diagrama de seqüência captura
o comportamento de um único caso de uso. O diagrama apresenta os objetos e
as mensagens que são passadas entre estes objetos dentro do caso de uso,
conforme mostra a Figura 8.5. Os objetos são representados por linhas
tracejadas verticais, e a passagem de mensagens entre dois objetos são
representados por vetores horizontais. As mensagens são desenhadas
cronologicamente do topo à base do diagrama.

63
Figura 8.5 : Diagramas de Seqüência
8.7 Diagramas de Col aboração
Os diagramas de colaboração é uma outra alternativa para a
modelagem de interações entre objetos de um sistema. Diferentemente do
diagrama de seqüência que focaliza na seqüência cronológica do cenário que
está sendo modelado, o diagrama de colaboração focaliza no relacionamento
entre os objetos e na compreensão dos efeitos sobre um objeto durante um
cenário. Os objetos são conectados através de associações e cada associação
representa uma instância de associação entre as respectivas classes
envolvidas. As associações mostram as mensagens enviadas entre os objetos,
e a seqüência destas mensagens é determinada usando-se números
seqüenciais (ver Figura 8.6).
Uma Colaboração é uma visão de um conjunto de elementos de
modelagem relacionados para um propósito particular em apoio a interações
[Furlan, 1998].
64
Figura 8.6 : Diagramas de Colaboração
8.8 Diagramas de Ativ idade
Um diagrama de atividade é essencialmente um gráfico de fluxo,
mostrando o fluxo de controle de uma atividade para outra [Booch, 2000] (ver
Figura 8.7).
Os diagramas de atividades são um caso especial de diagramas de
estado, onde todos os estados têm uma ação interna e nenhuma transição tem
um evento de entrada. O propósito de um diagrama de atividades é focar nos
fluxos dirigidos pelo processamento interno e descrever o comportamento de
processamentos paralelos.
Os diagramas de atividades são usados para detalhar classes,
implementação de operações e casos de uso, enquanto os diagramas de
estado são usados para especificar o comportamento global de um tipo.
Os diagramas de atividades representam o que acontece, mas não
representam quem faz o que. Isso significa que o diagrama não diz qual classe
é responsável por cada atividade. Os divisores contornam esse problema
através da organização das responsabilidades da atividades dentro de uma
classe. Através dos divisores podemos separar as atividades de acordo com as
classes responsáveis por essas atividades. Os divisores são representados por
linhas verticais tracejadas.

65
Figura 8.7 : Diagramas de Atividade
8.9 Diagramas de Com ponentes
Mostram dependências entre componentes de software [Furlan,
1998].
Os diagramas de componentes representam, de forma estática,
aspectos físicos do sistema sendo modelado. São importantes tanto para
visualizar, especificar e documentar sistemas baseados em componentes
quanto para construir sistemas através de engenharia reversa (reverse) e direta
(forward). Eles mostram um conjunto de componentes e seus relacionamentos
conforme mostra a Figura 8.8. São tipicamente usados para:
Modelar a organização do código fonte;
Modelar lançamento de executáveis (versões);
Modelar fisicamente um banco de dados;
Modelar sistemas adaptativos;
Engenharia de produção e engenharia reversa;

66
Figura 8.8 : Diagramas de Componentes
8.10 Diagramas de Imp lantação
Os diagramas de implantação são diagramas que mostram a
configuração de nós de processamento em tempo de execução e os
componentes que neles existem (ver Figura 8.9).
Os diagramas de implantação não são importantes somente para
visualizar, especificar e documentar sistemas embutidos, cliente/servidor e
distribuídos, mas também para o gerenciamento de sistemas por engenharia
de produção e engenharia reversa.
Os diagramas de implantação são empregados para modelagem da
visão estática de implantação de um sistema. Essa visão direciona
primariamente a distribuição, entrega e instalação das partes que formam o
sistema físico. Na maior parte, isso envolve a modelagem da topologia do
hardware em que o sistema é executado. Os diagramas de implantação são
essencialmente diagramas de classes que focalizam os nós do sistema.

67
Figura 8.9 : Diagramas de Implantação

Capítulo 9 - METODOLOGIA DESENVOLVIDA
9.1 Introdução
A UML é uma linguagem para especificação, visualização,
documentação e construção que tornam possível expressar modelos
orientados a objetos. Porém não prescreve como o trabalho deve ser feito.
A utilização da UML em grandes projetos pode ajudá-lo a tornar-se
mais eficiente, mas para tal devemos adotar um método de desenvolvimento.
O método de desenvolvimento adotado deve descrever um número
de atividades a ser seguidas em uma determinada ordem. Para alcançar com
êxito nossos objetivos devemos ter bem definido a expectativa do projeto.
Um método tradicional de desenvolvimento orientado a objetos é
dividido em análise de requisitos, análise, projeto, implementação e teste
[Barros, 2001], que é uma visão técnica do desenvolvimento. O RUP(Rational
Unfied Process) é um outro método, desenvolvido pela Rational Inc. que é

69
dividido em concepção, elaboração, construção e transição, que mostra uma
visão mais gerencial do desenvolvimento [Booch,2000].
Ferramentas modernas devem suportar um método de
desenvolvimento de sistemas além da linguagem de modelagem e
programação. Um exemplo é o Rational Rose da Rational Inc. que suporta bem
tanto a linguagem quanto o método de desenvolvimento.
A partir deste ponto descreveremos nossa metodologia,
apresentando cada fase da metodologia detalhadamente. Tomaremos como
base para desenvolvimento de nossa metodologia a visão técnica da UML que
divide-se em 5(cinco) etapas: Análise de Requisitos, análise, projeto,
programação e testes.
Ao final do desenvolvimento de cada fase serão feitas observações
que servirão de conclusão e de base para futuros melhoramentos.
9.2 Documentação
Estabelecemos alguns procedimentos inicias, a fim de manter a
documentação organizada. Esses procedimentos podem interagir com outras
documentações em outros projetos usando a mesma metodologia em
plataformas diferentes.
9.2.1 Fonte
Na documentação será exigido a confecção de alguns documentos,
cujo os quais deve-se redigi-los corretamente para um bom entendimento. Para

70
uma melhor visualização determina-se antes do início 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 documentação tem que ser bem definida,
partindo do princípio que nem todos terão as mesmas ferramentas e que
existem editores que não possuem determinadas fontes. Devemos nos
preocupar em estabelecer uma fonte que toda a equipe envolvida e até mesmo
pessoas não envolvidas naquele projeto possuam. Numa apresentação do
projeto criado os documentos tem que ser facilmente visualizados.
Quanto ao tamanho, fontes pequenas demais tornam a
documentação um pouco cansativa para ser lida, fontes grandes gerariam
muitas folhas e também 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 Gravação da Docu mentação
Para que todos os envolvidos no projeto possam ter acesso à
documentação do projeto, e para uma melhor organização 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
mãe com o nome do projeto e abaixo dela conforme a necessidade cria-se
outras pastas filhas. Todas as pastas criadas devem sempre fazer relação com
os arquivos que estarão armazenados na mesma.

71
Na confecção de um novo projeto pode-se copiar estas pastas para
um outro local e renomeá-las. Faz-se necessário uma revisão de todas as
pastas para adequação com o novo projeto.
9.2.3 Extensão de Arqui vos
Na preocupação que nosso projeto possa se comunicar com outros
ou até mesmo a junção dos mesmos, devemos estabelecer extensões de
arquivos que possam ser abertas em qualquer plataforma, sistema operacional,
editor, etc. Muito importante para uma boa definição deste item, é saber quais
serão os possíveis editores usados, sistemas operacionais que os envolvidos
no projeto possuem.
Arquivos do tipo .txt seriam de bastante abrangência, exceto no
caso de criação de arquivos um pouco mais complexos, necessitando
ferramentas com um pouco mais de recursos, pois arquivos com este tipo de
extensão podem ser abertas em muitas plataformas. Se houver realmente a
necessidade de criação de arquivos com recursos um pouco mais complexos
que os .txt (modo caracter), procurar usar extensões de arquivos que abram na
grande maioria dos editores.
9.2.4 Impressão
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 padrão.
As margens podem ser configuradas de acordo com a necessidade,
pois dentro do projeto haverá diagramas que necessitarão de margens um

72
pouco menores ou maiores devido a sua complexidade. Sendo que para sua
melhor visualização às vezes é necessário o uso do papel até sua extremidade.
9.2.5 Backup
Deve-se criar um sistema de backup, sugerindo um responsável pela
execução do mesmo, para que não haja surpresas no decorrer do projeto,
como perdas de dados. Ocasionando atraso na conclusão do projeto, alterando
as datas as quais a equipe se submeteu a cumprir.
A periodicidade dos backup´s depende do envolvimento da equipe e
das informações armazenadas diariamente, se houver necessidade pode-se
realizar os backup´s diariamente, semanalmente ou mensalmente.
Criaremos um formulário sugestão que envolve todos os
procedimentos da documentação, conforme anexo 01.
9.2.6 Controle de Versõe s
Desejamos com o controle de versões que os desenvolvedores
possam manter o sistema atualizado de acordo com sua documentação. Serve
também para diferenciar um software dele mesmo, porém qualquer tipo de
alteração feita será registrada uma nova versão do software.
Uma versão deverá ser representada de modo a controlar desde
pequenas alterações até novas funcionalidades e/ou grandes alterações que
mudem a funcionalidade do sistema.
Sugerimos a representação da versão em seqüências de três blocos
de caracteres (N.NX-NN) onde :
• N é um caracter numérico no intervalo de 1 a 9;

73
• NX : N é um caracter numérico no intervalo de 1 a 9; X é um caracter
alfanumérico no intervalo de A-Z;
• NN são caracteres numéricos no intervalo de 01 a 99;
Os dois primeiros caracteres (N.N) representam a versão principal.
Somente são alterados quando se tratar de grandes modificações e/ou
inovações, como por exemplo : troca de linguagem, inclusão de novo módulo
no sistema, troca ou inclusão de nova plataforma.
O terceiro caracter (X) é destinado a alterações de médio porte e/ou
inclusão de novas rotinas, como por exemplo : cadastros, relatórios,
lançamentos, consultas.
Nos dois últimos caracteres (NN) registramos pequenas alterações
e correções em rotinas já existentes no sistema, como por exemplo : alterações
de relatórios, consultas, cadastros, etc.
9.3 Eventos Iniciais
Após concluído o item documentação, trataremos alguns eventos
que ocorrem antes da análise de requisitos. Trata-se de eventos iniciais de
extrema importância para um bom desenvolvimento da análise de requisitos,
onde são feitos os primeiros contatos, um estudo dos dados e definição de
possíveis envolvidos no projeto.

74
9.3.1 Contatos
Um determinado usuário faz um contato solicitando o
desenvolvimento de um software. Este contato pode ser de forma mais variável
possível: Fone, Fax, email, pessoal, etc.
A empresa ou pessoa que recebeu o contato, solicita ao usuário, ou
acompanha o mesmo no preenchimento de um formulário padrão. Trata-se de
um formulário que servirá para registrar a solicitação do usuário e também para
a convocação de algumas pessoas para uma possível reunião a qual será
marcada. Como trata-se de algo bem genérico, através deste formulário ainda
não se sabe com certeza quem será envolvido no sistema. Define-se tanto os
participantes por parte do usuário quanto da empresa de desenvolvimento de
software.
Este formulário deverá ser preenchido em meio
magnético(aconselhável) ou papel, este último depois de preenchido será
transformado em meio magnético.
Criaremos um formulário sugestão que contém todos os itens
necessários para registrar um contato, conforme anexo 02.
9.3.2 Estudo dos Dados
Tratando-se de um desenvolvimento de um novo software será
analisado:
• Após uma análise da área de negócio, concluindo-se que a empresa não
pode atender a solicitação, será retornado ao mesmo que trata-se de uma
área de negócio a qual a empresa não oferece soluções. Esta resposta

75
também poderá ser dada no momento do preenchimento do formulário
padrão, dependendo de quem e da capacidade do atendente.
• A área de negócio da solicitação é abrangida pela empresa, então será feita
uma avaliação sobre a descrição e com base nesta avaliação e na área de
negócio, serão convocados para uma reunião os possíveis envolvidos no
projeto, tanto por parte do solicitante, quanto por parte da empresa
desenvolvedora.
9.3.3 Definição dos Part icipantes
A definição dos participantes deve sempre girar em torno da área de
negócio e da descrição, pois é ali que contém alguns conceitos básicos que
podem ajudar os responsáveis a convocar as pessoas certas para definir os
possíveis participantes.
Nesta definição procura-se envolver todos que de alguma forma
poderão contribuir para o projeto de ambas as partes. Logicamente de acordo
com o andamento do projeto serão filtrados, ficando apenas aqueles que
podem contribuir para o bom desenvolvimento do projeto. Após definir todos os
participantes da reunião, será marcada a data da mesma e os envolvidos serão
convocados.
Até este ponto trata-se de um evento que antecede as fases da
metodologia de desenvolvimento de sistemas.

76
9.4 Análise de requis itos
Esta fase é a base do projeto, deverá ser bem elaborada para um
bom desenvolvimento das demais fases. Serão abordados itens necessários
para a concepção do projeto, definição de equipe envolvida e também alguns
itens técnicos como: atores, casos de uso, diagrama de casos de uso e análise
de riscos.
9.4.1 Reunião/Entrevista
Nas reuniões, das quais as pessoas convocadas a participar, não
existe nenhuma hierarquia. Todos os participantes, sejam eles analistas,
gerentes, diretores ou escriturários, devem se posicionar livremente, pois se
foram convidados a participar é porque têm alguma contribuição a dar com o
seu conhecimento específico no assunto objeto da reunião. Em uma situação
normal, a hierarquia funciona como um agente inibidor e a opinião da pessoa
de nível mais alto prevaleceria sobre as demais, sem nenhuma garantia de que
fosse a mais indicada.
Para dar início a comunicação 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 benefícios. Por exemplo,
o analista poderia perguntar :
• Quem está por trás do pedido deste trabalho?
• Quem usará a solução?
• Qual o benefício econômico de uma solução bem-sucedida?
• Há outra fonte para a solução exigida?

77
Em seguida, o analista pode fazer perguntas que o ajudarão na
compreensão do problema e ter uma idéia da solução:
• Como você caracteriza um "bom" resultado(saída) que seria gerado por
uma solução bem-sucedida?
• Qual o(s) problema(s) essa solução resolverá?
• Você poderia mostrar-me(ou descrever-me) o ambiente que a solução será
utilizada?
• Existem questões de desempenho ou restrições especiais que afetarão a
maneira pela qual a solução é abordada?
Por fim, o analista fará perguntas decisivas, que concentram-se na
efetividade da reunião:
• Você é a pessoa certa para responder a essas perguntas? Suas respostas
são "oficiais"?
• Minhas perguntas são pertinentes ao problema que você tem?
• Estou fazendo perguntas demais?
• Há mais alguém que possa fornecer informações adicionais?
• Existe algo mais que eu possa perguntar-lhe?
Uma abordagem à coleta de exigências orientadas a equipes
aplicada durante as primeiras etapas de análise e especificação é a
FAST(Facilitaded Application Specification Techniques). Essa abordagem
estimula a criação de uma equipe conjunta de clientes e desenvolvedores que
trabalhem juntos para identificar o problema, propor elementos de solução,
negociar diferentes abordagens e especificar um conjunto preliminar de
requisitos de solução. Hoje, a FAST é usada predominantemente pela

78
comunidade de sistemas de informação, mas a técnica oferece potencial para
uma melhor comunicação em aplicações de todos os tipos.
Outra abordagem especializada de entrevista que pode ser usada é
o JAD(Joint Application Development). Consiste numa rápida entrevista e um
processo acelerado de coleta de dados em que todos os principais usuários e o
pessoal da análise de sistemas agrupam-se em uma única e intensiva
reunião(que pode prolongar-se de um dia a uma semana) para documentar os
requisitos do usuário. A reunião costuma ser supervisionada por um
especialista treinado que atua como mediador para encorajar melhores
comunicações entre os analistas de sistemas e os usuários.
Esses métodos citados possuem suas diferenças, mas todos tem
alguns princípios básicos :
• Um encontro é levado a efeito num local neutro e participam
desenvolvedores e clientes;
• Usam-se regras para preparação e participação;
• Uma agenda formal para captar os pontos importantes, agindo de forma
livre o suficiente para encorajar o fluxo de idéias e sugestões;
• Um moderador (Cliente, Desenvolvedor ou alguém de fora) para controlar a
reunião;
• Utilização de um mecanismo de definição que pode ser uma planilha, um
cavalete, adesivos de parede ou cartazes;
• Identificação do problema, propor elementos de solução, negociar
diferentes abordagens e especificar um conjunto preliminar de requisitos de
solução num clima que facilite a realização da atividade.

79
9.4.2 Preenchimento da ata da reunião
Nesta primeira reunião aparecerão muitas idéias sobre como se
deve comportar o sistema ou o que ele deve atingir. Todas as idéias devem ser
incluídas na ata pois serão a partir delas que será dado o start no projeto.
A ata da reunião deverá ser compostas de alguns elementos
essenciais .
Criaremos um formulário sugestão que contém todos os elementos
essenciais, conforme anexo 03.
9.4.3 Definições de resp onsabilidades
Aqui definiremos a responsabilidade de cada um dos envolvidos no
projeto. Coordenador da equipe: Responsável 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 características e funcionalidades do sistemas.
Também será descrita a abrangência de todo o Projeto, com quem interage e
por quem é interagido(isto pode ser representado por diagramas de casos de
uso) .
Discriminar alguns requisitos mínimos para um bom funcionamento
do projeto também 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
referência.
80
9.4.5 Atores
Atores são usuários e/ou outros meios externos que desenvolvem
algum papel em relação ao sistema. Os meios externos são hardwares e/ou
softwares que, assim como os usuários, geram informações para o sistema ou
necessitam de informações 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 papéis em vez de pensar como
pessoas, cargos, máquinas. No sistema podem ter usuários com diferentes
permissões, para isto é necessário criar um ator para cada diferente tipo de
permissões. Os atores são 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á relação direta com a sua
função, possuirá uma descrição que definirá o que ele faz e com quem ele
interage.
Criaremos um formulário sugestão para listar os atores do sistema,
conforme anexo 04.
9.4.6 Casos de Uso
Antes da definição de casos de uso, devemos ter definidos os atores
e ter a idéia da funcionalidade do sistema, a partir disto, começaremos 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 cenários, onde cada
81
cenário é uma seqüência de passos a qual descreve uma interação entre um
usuário e o sistema. Os casos de uso são representados em forma de elipse.
Não 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 críticos para o sistema, os casos de uso que são tarefas
rotineiras não precisam ser desenvolvidos. Dessa forma sua documentação
não se tornará monótona. Numericamente falando, em modo geral trate apenas
de 10 à 20(%) dos casos de uso mais críticos de seu sistema, estes números
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 identificação dos mesmos.
Preencher todos os requisitos de um caso de uso é de extrema importância.
Criaremos um formulário sugestão para listar os casos de uso,
conforme anexo 05. Também criaremos outro formulário sugestão contendo
todos os requisitos de uma caso de uso, conforme anexo 06.
9.4.7 Escopo
Uma visão gráfica do sistema, mostrando a idéia geral do sistema
como ele irá interagir com o mundo externo. Esta visão é transformação de
funcionalidades, interação e abrangência descritos no resumo do projeto para
uma representação gráfica. 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 comunicação
entre a equipe de desenvolvimento e o usuário, portanto deverá ser de fácil
entendimento. Sua definição deve deixar bem transparente a idéia do sistema.
Nos diagramas de casos de uso ilustramos conjuntos dos casos de
uso do sistema, os atores e a relação entre os atores e os casos de uso.
Devemos definir o nome do diagrama de caso de uso sempre
relacionado-o com o seu propósito. Então 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, descrição,
atores e casos de uso relacionados.
Criaremos um formulário sugestão que contém todos os itens de
diagrama de caso de uso, conforme anexo 07.
9.4.9 Análise de riscos
Em todo projeto surgem várias incertezas, devemos considerar
algumas mais críticas, estas deverão ser tratadas com mais importância, pois
poderão comprometer todo o desenvolvimento do sistema. Dentre elas
podemos citar as mais críticas e que geralmente ocorrem na maioria dos
projetos:
• Está realmente claro a importância deste projeto?
• Baseado nos casos de uso, tem-se condições de implementar as funções
dentro prazo previsto?
• Analisar os problemas técnicos que poderão ocorrer ao longo do projeto.

83
• Caso encontre problemas, estes serão resolvidos de forma que não altere o
cronograma do projeto?
• Os requisitos foram bem definidos de modo que se ocorrerem eventuais
mudanças, estas não gerarão alterações consideráveis no tempo e nem nos
custos de desenvolvimento?
• Empenho dos envolvidos no projeto, todos que se comprometeram
realmente irão participar?
A análise de riscos é uma tarefa de grande importância 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: identificação,
avaliação, classificação, definição de estratégias para administrar os riscos,
resolução dos riscos, etc...
9.4.10 Cronograma
Os cronogramas são metas que devem ser atingidas, definindo
prazos nos quais os envolvidos deverão empenhar-se na execução de suas
atividades para o cumprimento dos mesmos.
Deverá ser criada uma representação (gráfico ou tabela) que
exprima o tempo dedicado a cada tarefa, determinando assim o prazo final do
projeto.
Criaremos um formulário sugestão que contém todos os itens para
um correto preenchimento de um cronograma, conforme anexo 08.

84
9.4.11 Aprovação
Cria-se um formulário onde responsáveis deverão aprovar a fase.
Criaremos um formulário modelo conforme anexo 09.
9.5 Análise
Esta fase preocupa-se com as primeiras abstrações e mecanismos
que estarão presentes no domínio do problema. Traremos dos diagramas de
classes em conjunto com diagramas de objetos, os diagramas de interação os
dividiremos em seqüência e colaboração, trataremos também dos diagramas
de estado e atividade.
9.5.1 Diagrama de Class es
Nos diagramas de classes modelamos a visão estática do sistema, o
conjunto de classes, interfaces, colaborações e seus relacionamentos. Nestes
relacionamentos dar-se-á mais atenção aos quatro principais tipos que são:
Generalização/especificação, Agregação, Associação e Dependência.
Em sistema de grande complexidade podemos dividir o diagrama de
classes em diagramas menores, logicamente observando sempre a integração
de todas as partes.
Deve-se considerar alguns procedimentos no desenvolvimento de
diagramas de classes:
• Praticamente, ter em mãos todas as informações sobre um modelo de
objetos é pouco provável. Deve-se ter conhecimento dos comportamentos

85
iniciais destes objetos, defini-los, classificá-los e identificar os
relacionamentos entre eles. Devemos nos direcionar mais as abstrações
comportamentais, reduzindo o número de objetos.
• Não devemos nos preocupar muito em usar toda a teoria envolvida nos
diagramas de classes, mas sim as mais simples: classes, associações,
atributos e generalização usando logicamente outras abstrações quando
forem necessárias.
• Ter conhecimento e compreensão da idéia do projeto é fundamental.
• Cria-se modelos apenas das áreas chaves do sistema.
• Atribuir-lhe um nome que indique sua finalidade.
• Na definição das classes podemos usar para definir os nomes substantivos,
para os métodos usamos verbos e para os atributos usamos propriedades
da classe.
A atenção em todos os detalhes desenvolvidos neste diagrama será
de grande influência na construção de um bom sistema.
9.5.2 Diagrama de Objet os
Os diagramas de objetos são utilizados para visualizar, especificar,
construir e documentar a estrutura de um conjunto de objetos, onde cada um
está num estado específico e em um determinado relacionamento com demais
objetos.
Os diagramas de objetos ajudam principalmente na modelagem de
estruturas complexas. Quando construímos diagramas de classes, de
componentes ou de implementação o que captamos realmente é um conjunto
de abstrações que nos interessa como um conjunto e, deste ponto de vista,

86
mostra-se sua semântica e seus relacionamentos com outras abstrações
existentes neste conjunto. Se imaginarmos um determinado momento num
sistema modelado, encontraremos um conjunto de objetos, cada um em um
estado específico 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 específico.
Segundo Booch, citamos algumas considerações para
desenvolvimento de diagramas de objetos [1995]:
• Identifique alguma função ou comportamento de parte do sistema cuja
modelagem você está fazendo e que é resultante da interação de uma
sociedade de classes, interfaces e outros itens.
• Para cada função ou comportamento, identifique as classes, interfaces e
outros elementos e seus relacionamentos entre si que participem nessa
colaboração.
• Considere apenas um único cenário capaz de percorrer tudo isto, congele o
cenário em determinado momento e represente cada objeto participante.
• Exponha o estado e os valores dos atributos de cada um desses objetos,
conforme seja necessário, para compreensão do cenário.
• De forma semelhante, exponha os vínculos existentes entre esses objetos,
representando instâncias de associações entre eles.
9.5.3 Diagramas de Inter ação
O diagrama de interação enfatiza a interação de objetos, uma
especificação comportamental que inclui uma seqüência de trocas de

87
mensagens entre objetos dentro de um contexto a fim de realizar um
determinado propósito.
Devemos utilizar diagramas de interação quando necessitamos ver o
comportamento de vários objetos dentro de um único caso de uso, a partir de
mensagens que são trocadas entre eles. Estes diagramas modelam os
aspectos dinâmicos do sistema.
Os diagramas de interação podem ser apresentados de duas
formas: Diagrama de Seqüência e Diagrama de Colaboração.
9.5.3.1 Diagrama de Seqüê ncia
O diagrama de seqüência expõe o aspecto do modelo que enfatiza o
comportamento dos objetos em um sistema, incluindo suas operações,
interações, colaborações e histórias de estado em seqüência temporal de
mensagem e representação explícita de ativação de operações [Furlan, 1998].
Em um diagrama de seqüência, um objeto é representado por um
retângulo no topo de uma linha vertical tracejada projetada para baixo. Esta
linha representa o ciclo de vida de um objeto durante uma interação. As
mensagens são representadas por linhas horizontais entre as linhas verticais
de dois objetos, e a ordem de como as mensagens acontecem também é
mostrada de cima para baixo.
O diagrama de seqüência mostra uma seqüência explícita de
mensagens e devemos usá-lo para especificações de tempo real e para
cenários complexos.
88
9.5.3.2 Diagrama de Colab oração
Um diagrama de colaboração é um contexto, um gráfico de objetos e
vínculos com fluxos de mensagens anexados [Furlan, 1998].
Num diagrama de colaboração, os objetos são desenhados como
ícones, e as setas indicam as mensagens enviadas entre objetos para realizar
um caso de uso.
O diagrama de colaboração auxilia no entendimento de um
comportamento de um conjunto de objetos que trocam mensagens entre si
para realizar um propósito em uma interação global, através deste diagrama
podemos ver somente os objetos e as mensagens envolvidas. Uma
colaboração é anexada a um tipo, uma operação 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 descrição do caso de
uso como ponto de partida para a confecção do diagrama.
Como podemos observar os diagramas de seqüência e colaboração
expressam informações semelhantes, porém de forma diferente. Quando
tivermos que decidir entre qual diagrama devemos adotar para estudar uma
interação, podemos escolher primeiramente o diagrama de colaboração
quando o objeto e seus vínculos facilitam a compreensão da interação, e
somente escolher o diagrama de seqüência se a seqüência 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 importância da ordem de execução dos
eventos. Este diagrama faz a modelagem dos aspectos dinâmicos 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 retângulo com cantos
arredondados e pode ter de um à três compartimentos que são: compartimento
do nome do estado, compartimento de variáveis e compartimento de atividade
interna.
Deve-se considerar alguns procedimentos no desenvolvimento de
diagramas de estados:
• Atribuir-lhe um nome capaz de comunicar seu propósito
• Comece modelando os estados estáveis do objeto e, em seguida faça a
modelagem das transições legais de um estado para outro.
• No gráfico deste diagrama, procure organizar seus componentes de forma
que reduza o cruzamento de ligações de componentes.
9.5.5 Diagrama de Ativid ade
Podemos fazer uma analogia com um gráfico 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 dinâmicos do sistema.

90
Nos Diagramas de Atividades modelamos a ordem pela qual as
coisas devem ser feitas, em processos seqüências ou paralelos, o que os
diferencia de um fluxograma que são limitados a processos seqüênciais.
Usamos os Diagrama de Atividades para diferentes propósitos
como:
• Análise de Caso de Uso e compreensão do fluxo de trabalho entre vários
casos de uso;
• Capturar o funcionamento interno de um objeto;
• Entender as ações quando executamos uma operação;
• Mostrar o funcionamento de um processo de negócio em termos de atores,
fluxos de trabalho, organizações e objetos;
• Mostrar como uma instância de caso de uso pode ser realizada em termos
de ação e mudanças de estado de objetos;
• Mostrar como um conjunto de ações relacionadas pode ser executado e
como afetará objetos ao seu redor.
9.6 Projeto
Baseado na análise, trataremos nesta fase de soluções técnicas.
Para essas soluções serão usados os diagramas de implementação, os quais
estão divididos em diagramas de componentes e implantação.

91
9.6.1 Diagrama de imple mentação
Os diagramas de implementação modelam os aspectos físicos.
Apresentam aspectos de implementação, inclusive da estrutura de código fonte
e de implementação de runtime.
Estão divididos em diagramas de Componentes e diagramas de
implantação.
9.6.1.1 Diagrama de comp onente
O diagrama de implantação mostra a configuração dos nós de
processamento em tempo de execução e os componentes que nele existem.
Os diagramas de componentes mostram a organização e as
dependências existentes entre um conjunto de componentes, transformam seu
projeto lógico em bits. Modelam os itens físicos que residem em um nó como
executáveis, bibliotecas, tabelas, arquivos e documentos.
Devemos atribuir-lhe um nome que demonstre seu propósito, seu
conteúdo costuma conter: componentes, interfaces, relacionamentos de
dependência, generalização, associação e realização. Podem conter notas e
restrições.
São usados para a modelagem da visão estática de implementação
de um sistema. A reunião das partes modeladas ajudarão na formação do
sistema executável. Usamos os Diagramas de Componentes nas seguintes
formas:
• Para modelagem de código-fonte:
• Identificar um conjunto de arquivos de código-fonte de interesse e
transformá-lo em componentes;
92
• Em sistemas grandes, devemos usar pacotes para mostrar grupos de
arquivos de código-fonte;
• No diagrama de componentes a exposição da versão do arquivo de
código-fonte ajuda no entendimento das dependências de compilação;
• Para modelagem de versões executáveis:
• Identificar o conjunto de componentes, isso envolverá alguns ou todos
que vivem em um único nó ou a distribuição desse conjunto de
componentes por todos os nós existentes no sistema;
• Considere o estereótipo de cada componente desse conjunto;
• Para cada componente existente no conjunto, faça seus
relacionamentos.
• Para modelagem de bancos de dados físicos:
• Identificar as classes existentes no modelo que representam o esquema
de seu banco de dados lógico;
• Faça o mapeamento de suas classes em tabelas;
• Estereótipe suas tabelas para um diagrama de componentes;
• Transforme seu projeto lógico em físico
• Para modelagem de sistemas adaptáveis:
• Identificar a distribuição física dos componentes que poderão mover de
um nó para outro. Especifique a localização de uma instância do
componente, atribua a ela o valor location.
• Para modelagem das causas de mudanças de um componente use um
diagrama de interação para auxiliá-lo.
Para uma melhor compreensão dos diagramas de componentes
podemos usar notas e cores como indicações visuais com a finalidade de

93
chamar a atenção a pontos importantes do diagrama. E também 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 ntação
Diagrama de Implantação é usada para mostrar a organização do
hardware e a ligação do software aos dispositivos físicos. Este diagrama
denota vários dispositivos de hardware e interfaces físicas determinadas por
seus estereótipos, como processador, impressora, memória, disco; suficientes
para que o engenheiro de software especifique a plataforma em que o sistema
é executado.
O diagrama de implantação modela a visão estática da implantação
de um sistema entre seus nós físicos e seus relacionamentos e para
especificar seus detalhes referente a construção. Usamos os Diagramas de
Implantação em uma das três formas :
• Para modelar Sistemas Embutidos :
• Identificar os dispositivos e os nós que são únicos para o sistema;
• Crie indicações visuais para dispositivos de hardware e outros tipos
dispositivos;
• Modele os relacionamentos entre os dispositivos;
• Se necessário crie diagramas de implantação mais detalhado em
dispositivos inteligentes.
• Para modelar sistema Cliente/Servidor :
• Identificar os nós que representem os processadores do cliente e do
servidor do sistema;
94
• Junte os dispositivos importantes para o comportamento do sistema.
• Crie indicações visuais para processadores e dispositivos usando
estereótipos
• Modele a topologia dos nós, especificando seus relacionamentos.
• Para modelar sistema totalmente distribuído :
• Identificar os dispositivos e processadores para sistemas cliente/servidor
mais simples;
• Caso precise analisar o desempenho da rede do sistema ou
modificações na rede, modele esses dispositivos em um nível de detalhe
que previna essas avaliações;
• Analise os agrupamentos lógicos de nós, especificando-os em pacotes;
• Identifique a topologia do seu sistema;
• Se for preciso focalizar a dinâmica do sistema, introduza diagramas de
casos de uso para especificar o comportamento em foco e crie diagrama
de interação para expandir esses casos de uso.
Os diagramas de implantação não são muito utilizados em sistema
que residem em uma máquina e que interagem somente com dispositivos
padrão(teclado, monitor, mouse, modem pessoal) dessa máquina, que já são
gerenciados pelo S.O. host. Em contrapartida se estiver desenvolvendo
software que interaja com dispositivos que o sistema operacional host
tipicamente não gerencia, ou por processadores distribuídos fisicamente no
mesmo host, o diagrama de implantação ajudará a analisar o mapeamento de
software para hardware de seu sistema.
Para uma melhor compreensão dos diagramas de implantação
devemos atribuir-lhe um nome que identifique seu propósito, podemos usar

95
notas e cores como indicações visuais com a finalidade de chamar a atenção a
pontos importantes do diagrama. E também devemos usar elementos
estereotipados com cuidado, escolhendo um conjunto pequeno de ícones e
utilizando-o de maneira consistente.
9.7 Implementação
A fase da implementação é, na prática, a construção física do
sistema proposto [Silva,1998]. É onde todos os modelos desenvolvidos no
projeto são traduzidos para código que a máquina possa reconhecer.
É muito importante que as fases anteriores já estejam concluídas,
pois a codificação é uma conseqüência natural do projeto.
9.7.1 Tradução
O processo de tradução acontece quando a compilador aceita o
código-fonte como entrada e gera um código-objeto como saída.
Para que o código-fonte não 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 codificação complexa ou pouco conhecida pode levar
a códigos mal elaborado e de difícil legibilidade. Devemos nos concentrar em
escolher linguagens de codificação que tenha suporte ao projeto.

96
A escolha de uma linguagem de programação para um projeto
específico deve-se considerar as suas facilidades e aonde ela irá ajudar o
melhor desenvolvimento do projeto.
PRESSMAN sugere alguns critérios a serem avaliados durante a
escolha de uma linguagem de programação [1995]:
• A área de aplicação geral;
• A complexidade computacional e algorítmica;
• O ambiente em que o software será executado;
• Considerações 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 aplicação geral como um dos
itens mais estudados na escolha da linguagem.
O lançamento de novas linguagens ou versões é muito constante,
portanto muitas vezes necessitamos escolher linguagens do conhecimento da
equipe, que geralmente não são os últimos lançamentos. Porém novas
linguagens devem ser cuidadosamente estudadas e a mudança da linguagem
atual para nova tem que ocorrer.
Na escolha de uma linguagem orientada a objetos deve-se
considerar suporte para definições de classes, herança, encapsulação e
transmissão de mensagens ou ainda características adicionais como herança
múltipla e polimorfismo.
As novas gerações de ferramentas CASE possuem uma variedade
de linguagens, com isto elas podem gerar códigos-fonte baseadas no modelo

97
desenvolvido. Porém devem ser bastante estudadas pois uma falha no modelo
pode comprometer todo o produto final.
9.7.3 Documentação do Código
Um código-fonte bem estruturado e documentado será de grande
importância para futuras manutenções no sistema.
A estruturação e documentação começa com a escolha de nomes
identificadores(variáveis e rótulos), prosseguindo com a colocação e
composição do comentário e por fim com a organização visual do código.
Na escolha de nomes de identificadores devemos considerar alguns
itens a fim de facilitar a interpretação :
• Expressar diretamente o seu propósito.
• Identificação do tipo e de sua abrangência(global, local) no sistema. Podem
ser feitas algumas definições de nomes antes do início da programação.
• Não usar nomes muito extensos, mas que expresse o seu propósito. Neste
caso deverá prevalecer o bom censo e experiência por parte do
programador.
Na colocação e composição de comentários, tomaremos alguns
cuidados para que estes realmente ajudem outros leitores de código na
compreensão do código e até mesmo para que o desenvolvedor possa
localizar-se com mais facilidade e rapidez em futuras manutenções. Isto é de
extrema importância no desenvolvimento de sistemas e/ou funções complexas.
Segundo PRESSMAN, comentários em forma de prólogo são
bastante usados, eles aparecem no início de cada módulo, e seguem o formato
abaixo [1995]:
98
• Uma declaração de propósitos que indique a função do módulo.
• Uma descrição da interface("seqüência de chamada", descrição de todos os
argumentos e uma lista de todos os módulos subordinados).
• Uma discussão de dados pertinente, tais como variáveis importantes e suas
restrições e limitações de uso.
• Um histórico de desenvolvimento(autor do módulo, auditor e data, datas e
descrição das modificações).
Para uma melhor documentação em módulos e/ou funções muito
complexas devemos utilizar também comentários descritivos embutidos no
decorrer do código-fonte. Este tipo de comentário será de grande utilidade para
documentarmos linhas ou conjunto de linhas específicas em determinado local
dentro de um módulo e/ou função. Este comentário deverá sempre anteceder o
bloco de comandos que se deseja documentar, faça apenas a identificação da
funcionalidade de tal linha ou conjunto de linhas, não é necessário documentar
outros dados como datas, autores, etc.
Ao escrevermos código-fontes e também seus comentários devemos
sempre nos preocupar com sua estética, procuramos sempre elaborar códigos
identados e seus comentários devem sempre ter uma boa visualização.
Algumas dicas de PRESSMAN para simplificar a codificação [1995]:
• Evitar o uso de testes condicionais complicados;
• Evitar os testes em condições negativas;
• Evitar um intenso alinhamento de laços ou condições;
• Usar parênteses para esclarecer expressões lógicas ou aritméticas;
• Usar símbolos de espaçamento e/ou legibilidade para esclarecer o
conteúdo da instrução;
99
• Usar somente características com padrão ANSI;
• Auto questionar-se: Será que entenderia este código se não fosse eu o
autor deste?
9.8 Testes
A atividade de teste visa executar um programa ou parte dele com a
intenção de encontrar erros.
Um teste bem executado é aquele que encontra um maior número
de erros com o menor número de tentativas, em um tempo e esforço mínimo.
Certamente que os projetistas codificam o software para que não haja erros.
Uma estratégia de teste de software deve estar dividida nas
seguintes fases : planejamento de teste, projeto de casos de teste, execução
de teste e a resultante coleta e avaliação de dados [Pressman, 1995].
Para tornar esta estratégia mais flexível e customizada sem perder
sua validade e regidez, objetivando a redução de custos e tempo adotamos a
seguinte estratégia : planejamento, execução e avaliação dos resultados.
9.8.1 Planejamento de T estes
Antes do início dos teste devemos definir a equipe responsável pelos
testes. Devemos formar um grupo de testes independentes (GTI), envolvendo
também os desenvolvedores principalmente na etapa de teste de unidade da
fase de execução que será abordado a seguir.

100
Devemos tomar como base para testes os casos de usos
desenvolvido na fase de análise de requisitos, verificando se seu propósito está
contemplado, observando seu fluxo normal e quando este fluxo não é seguido
se os fluxos alternativos estão atendendo tal situação.
9.8.2 Execução de Teste s
Nesta etapa são realizados os testes na integra, abordaremos os
testes de Unidade, Integração, Validação e Sistema.
Durante a execução dos testes, deve-se fazer um relatório de
acompanhamento para registro de todos as ocorrências encontradas.
9.8.2.1 Teste de Unidade
Nestes testes cada unidade de software(classe, procedimento,
função, arquivo, etc) é testado individualmente garantindo que ele funcione
adequadamente. Aqui a participação dos desenvolvedores também é
recomendada, pois estes tem um melhor conhecimento interno de cada
unidade.
Alguns aspectos a serem testados: são a interface, as estruturas de
dados, as condições 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 módulo. Deve ser realizada em primeiro lugar, durante a realização
deste teste os seguintes aspectos devem ser observados :
1. Consistência entre o número e o tipo de parâmetros de entrada com o
número e tipo de argumentos;

101
2. Consistência entre o número e o tipo de argumentos transmitidos aos
módulos chamados com os parâmetros;
3. Consistência de variáveis globais ao longo dos módulos;
4. Existência de referências a parâmetros não associados ao ponto de
entrada atual;
5. Modificação de argumentos de entrada/saída.
• As estruturas de dados locais, para se prover a garantia de que todos os
dados armazenados localmente mantêm sua integridade ao longo da
execução do módulo. Neste teste devemos nos preocupar em :
1. Digitação inconsistente ou imprópria;
2. Iniciação ou valores default errôneos;
3. Tipos de dados errados;
4. Underflow e Overflow.
• As condições limite, que permitem verificar que o módulo executa
respeitando os valores máximos e mínimos estabelecidos para seu
processamento.
• Os caminhos independentes (ou caminhos básicos) da estrutura de controle
são analisados para ter garantia de que todas as instruções do módulo
foram executadas pelo menos uma vez. Os erros mais comuns são :
1. Precedência aritmética incorreta;
2. Operações em modo misto;
3. Inicialização incorreta;
4. Erros de precisão;
5. Representação simbólica de uma expressão incorreta;
6. Laços mal definidos;

102
7. Comparação de diferentes tipos de dados;
8. Operadores lógicos utilizados incorretamente.
• Os caminhos de tratamento de erros (se existirem), serão testados para
observar a robustez do módulo. Devemos observar os seguintes itens :
1. Descrição incompreensível do erro;
2. O erro exibido não é o erro encontrado;
3. Intervenção da condição de erro no sistema antes do seu tratamento;
4. O processamento das condições de exceções é incorreto;
5. A descrição do erro não ajuda na localização da causa do erro.
9.8.2.2 Teste de Integraçã o
O teste de integração é uma técnica sistemática para a construção
da estrutura de programa, realizando-se em paralelo, testes com o objetivo de
descobrir erros associados a interfaces. Seu objetivo é montar, a partir dos
módulos testados ao nível de unidade construir a estrutura de programa que foi
determinado pelo projeto.
Este teste está divido em incremental e não incremental. Incremental
aborda o teste de integração top-down o programa é construído e testado em
pequenos seguimentos, onde os erros são mais fáceis de ser isolados e
corrigidos. O teste não incremental aborda o teste de integração bottom-up o
programa é testado como um todo, um conjunto de erros é encontrado e sua
correção é difícil porque o isolamento das causas é complicado pela vasta
amplitude do programa inteiro [Pressman,1995].
1. Integração top-down : Os módulos são integrados movimentando-se
de cima para baixo através da hierarquia de controle, iniciado-se do

103
módulo principal. Os módulos subordinados ao módulo principal de uma
maneira depth-first(pela profundidade) ou breadth-first(pela largura).
2. Integração bottom-up : Inicia-se a construção e testes com módulos
localizados nos níveis mais baixos da estrutura do programa dirigindo-se
ao módulo principal.
9.8.2.3 Teste de Validação
Ao final do teste de integração, o software é finalmente estruturado
na forma de um pacote ou sistema. O teste de validação é a validação e
verificação de que o software como um todo cumpre os requisitos do sistema.
Na fase de análise de requisitos são definidos critérios que servirão
de validação para aprovação ou não do software. O teste de validação aborda
as seguintes estratégias : revisão de configuração e teste alfa e beta.
1. Revisão de configuração: é onde são verificados os elementos de
configuração do software se estão adequadamente desenvolvidos e
detalhados para futuras manutenções.
2. Teste alfa: é feito por um cliente nas instalações do desenvolvedor.
O software é usado num ambiente controlado com o desenvolvedor
"olhando sobre os ombros" do usuário e registrando erros e
problemas de uso.
3. Teste beta: é feito nas instalações do cliente pelo usuário final do
sistema. O desenvolvedor não está presente. O cliente registra os
problemas(reais ou imagináveis) que são 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 número de diferentes
testes, cujo propósito é pôr completamente à prova o sistema baseado em
computador.
Entre os tipos de testes de sistemas destacamos: De recuperação,
de segurança, de estresse e de desempenho.
• O teste de recuperação é um teste de sistema que força o software a falhar
de diversas maneiras e verifica se a recuperação é executada.
• O teste de segurança verifica se todos os mecanismos de proteção
embutidos no sistema o protegerão.
• O teste de estresse força o sistema a usar recursos em quantidade,
freqüência ou volumes anormais.
• O teste de desempenho é feito para testar o desempenho do software em
tempo real.
9.8.3 Avaliação dos Res ultados
Completadas a fase de execução dos testes, passaremos para a
avaliação dos mesmos. Isto será feito analisando os relatórios elaborados
durante a fase anterior.
Esta fase é de grande valia para vários aspectos do sistema. Nesta
poderemos ter uma idéia por completo de todo o desenvolvimento do projeto.
Podemos apontar falhas em determinadas fases do projeto
baseando-se nesta avaliação, bem como certificar-se da qualidade e/ou bom
desempenho do projeto.
105
Ocorrendo pequenos erros ou observações que não interfiram no
objetivo do projeto, estes deverão ser tratados diretamente com o responsável
pela fase onde ocorreu o problema.
Quando na avaliação 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.
Após feitas as correções dos problemas encontrados, estando de
acordo com as especificações definidas na análise de requisitos e aceitas pelo
cliente, o software estará pronto para uso.

Capítulo 10 - Validação da Metodologia
10.1 Introdução
Neste capítulo documentaremos o protótipo desenvolvido baseado
na metodologia, mostrando a idéia principal do sistema.
Serão abordados os seguintes itens : Formulário de Documentação,
Contatos Iniciais, Ata da Reunião, Resumo do Projeto, Escopo, Lista de Caso
de Uso, Diagrama de Caso de Uso, Diagrama de Classes e Escolha da
Linguagem.
10.2 Formulário de Do cumentação
Fonte
Tipo : Times New Roman Tamanho : 12
Gravação
107
Pasta Mãe : Contabilidade
Descrição : Esta pasta contém toda a documentação do projeto do
sistema de contabilidade.
Extensão de Arquivos : .rtf
Impressão
Tamanho do papel: A4(210 X 297mm)
Backup
Responsável: Reginaldo Darolt / Alexandre de Almeida
Periodicidade: Semanal.
Versão: 1.0A-01
10.3 Contatos Iniciais
Data: 14/03/2001
Razão Social: Escritório Criciumense de Contabilidade
Solicitante: João da Silva
Departamento: Gerencial
Fone: 048-4371159
Fax : 048-4376020
Ramal: 203
Email: joaocri@terra.com.br
Descrição: Sistema de Contabilidade com capacidade de emitir os
relatórios legais como: diário, razão, balancete após os lançamentos nas
contas contábeis do plano de contas da empresa. Irá receber também

108
lançamentos dos sistemas de livros fiscais, folha de pagamento e controle
patrimonial. Irá gerar informações gerenciais para o administrativo.
Tipo do pedido: (X ) Novo ( ) Alteração
Área de negócio do problema: Contábil
Prioridade: (X) Normal ( ) Alta ( ) Urgente
Data pretendida para solução: 12 meses
10.4 Ata da Reunião
Data : 21/03/2001 Hora Início : 19:00 Hora Final: 22:30
Participantes: Alexandre de Almeida, Reginaldo Darolt e João da
Silva
Objetivos:
1.Definir a abrangência do sistema.
2.Definir as possíveis entradas de dados.
3.Definir os procedimentos padrões do sistema.
4.Definir as saídas/relatórios que o usuário necessita.
5.Definir os possíveis tipos de usuário do sistema.
Observações: Utilizamos o método questionário para alcançar os
objetivos da reunião.
Definições da reunião:
1.O sistema irá abranger somente o módulo de contabilidade
2.As possíveis entradas de dados no sistema serão:
Manual(através de digitação) e também automáticas por outros sistemas.
Quando geradas por outros sistemas, estes deverão estar conectados no

109
mesmo banco de dados e sem o auxílio de nenhuma rotina do módulo de
contabilidade para execução de tal tarefa.
3.Procedimentos:
• Cadastro de Usuários.
• Cadastro de Contas Contábeis e Históricos Padrões.
• Lançamentos.
• Emissão de relatórios.
• Definição de parâmetros do sistema como período de
lançamento e máscara contábil.
4.Relatórios:
• Cadastrais: Contas e Históricos.
• Acompanhamento de lançamentos.
• Legais: Diários, Razão, DRE, Balanço e Livro Caixa.
• Tempo gasto no sistema por usuário.
5.Usuários:
• Contador
• Digitador
• Usuários de outros sistemas que somente farão lançamentos no
sistema quando conectados no mesmo banco de dados.
10.5 Resumo do Proje to
Um sistema de Contabilidade com cadastros de contas, históricos e
lançamentos. Recebe lançamentos do sistema de Livros Fiscais nos

110
lançamentos de notas, apuração e pagamento de impostos. Do Controle
Patrimonial recebe lançamentos na atualização dos bens e no fechamento de
período. Na Folha de Pagamento recebe lançamentos no momento do cálculo
mensal.
Este sistema gera informações sobre tempo gasto do usuário para o
sistema administrativo. Emite relatórios cadastrais, de acompanhamentos e
também os relatórios legais tais como: Diário, Razão, DRE, Balanço e Livro
Caixa.
Para um bom desempenho do sistema será necessário o uso de
máquinas com configuração igual ou superior a PII 233 Mhz com 32 Mb.
Ambiente Windows95 ou Windows98, e para uma boa apresentação dos
relatórios faz-se necessário impressora Jato de Tinta ou Laser. No caso de
mais de uma estação de trabalho, estas deverão estar conectadas através de
uma rede que suporte as estações 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 LANÇAMENTO
UC002 - MANTER CONTA CONTÁBIL
UC003 - MANTER PARÂMETROS
UC004 - MANTER PERMISSÕES

112
UC005 - EFETUAR LANÇAMENTOS LIVROS FISCAIS
UC006 - APURAR IMPOSTOS LIVROS FISCAIS
UC007 - PAGAR IMPOSTOS LIVROS FISCAIS
UC008 - FECHAR PERÍODO 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 versão 5.0.02 da Powersoft com o banco de dados
Sybase SQL Anywhere versão 5.0.03.

Capítulo 11 - RESULTADOS OBTIDOS
Após a validação da metodologia desenvolvida, obtemos alguns
resultados os quais julgamos ser necessários destacar.
Neste capítulo discriminaremos os pontos fortes e pontos fracos de
cada fase da metodologia desenvolvida.
• Documentação
Pontos Fortes:
• A extensão de arquivos utilizada nos auxiliou na comunicação
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 vírus na máquina 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 descrição de cada arquivo.
• Estabelecimento de uma padronização 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 próximas etapas. Com o estudo da área de
negócio ficou definido que a empresa atenderia a solicitação do
cliente.
• Análise de Requisitos
Pontos Fortes:
• Com os tópicos abordados na reunião, obteve-se os objetivos
gerais e específicos pretendidos com o sistema. Ao final ficou
registrado na ata da reunião.
• 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 implementação.
• O diagrama de caso de uso auxiliou na comunicação entre o
cliente e os desenvolvedores.
Pontos Fracos:
• Na lista de Atores deveria ter também a data da criação do ator e
o autor que o criou, desta forma facilitaria no esclarecimento de
possíveis dúvidas sobre o ator.
• Análise
Pontos Fortes:
• Seguindo as definições da metodologia, o diagrama de classes
foi facilmente desenvolvido e compreendido por toda a equipe.

117
• Os diagramas de interação mostraram o fluxo de funcionamento
do sistema, como as informações trafegam no mesmo.
Auxiliando desta forma na compreensão comportamental do
sistema.
• O diagrama de estado mostrou de forma clara os eventos da
principal rotina do sistema que é a rotina de lançamentos.
• 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 estruturação do
código fonte, separando seus objetos de acordo com sua
finalidade.
• O diagrama de implantação mostrou a toda a equipe a estrutura
física do cliente, bem como informações essenciais para o
software como por exemplo o servidor de banco de dados.
• Implementação
Pontos Fortes:
• Conforme sugerido na metodologia, escolhemos uma linguagem
conhecida pelos desenvolvedores e que atendesse os requisitos
do projeto.
118
• A documentação do código foi de grande importância durante o
desenvolvimento do sistema, pois todos os programadores
poderiam facilmente compreender as rotinas independentes do
autor da mesma. Esta documentação ainda será muito utilizada
em futuras manutenções do sistema.
• Testes
Na estratégia de testes não adotamos a fase de projetos porque
seus métodos torna essa tarefa cansativa e também 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 são apenas citados para que
sejam explorados caso alguém tenha esta necessidade.

119
Capítulo 12 - CONCLUSÃO
Em virtude das constantes inovações que surgem em ferramentas
de desenvolvimento de sistemas orientadas a objetos, podemos afirmar a
importância do uso de uma metodologia que englobe todas as fases do
processo, desde os eventos iniciais, passando pela análise de requisitos,
análise, projeto, implementação e testes. Durante a realização do trabalho
constatamos o interesse por parte de desenvolvedores de software, de uma
metodologia deste nível.
Com o desenvolvimento de sistemas mais complexos, é necessário
o uso de uma metodologia unificada, tanto para a comunicação entre toda a
equipe envolvida (cliente, analista, programador, etc), quanto para a
documentação(requisitos e código-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.
Após o estudo da ferramenta CASE Rational Rose da Rational
Software Corporation, utilizamos a mesma no apoio a validação da

120
metodologia. Esta ferramenta mostrou-se bastante complexa e eficaz, pois ela
possui uma documentação interativa e automática dos processos de
modelagem, permitindo até mesmo gerar código-fonte a partir do modelo. Na
implementação do sistema utilizamos a ferramenta de desenvolvimento
chamada Power Builder pela facilidade da programação orientada a objetos,
bem como pelo conhecimento que todos envolvidos tinham da mesma.
Com o desenvolvimento do protótipo utilizando a metodologia,
podemos afirmar que os resultados esperados foram alcançados, tendo em
vista que esta atendeu todas as fases de desenvolvimento do protótipo. Desta
forma podemos dizer que a metodologia se torna necessária para um bom
desenvolvimento de sistema orientados a objetos.
12.1 Recomendações
Este trabalho está aberto a futuros melhoramentos, e como
recomendações futuras podemos ressaltar:
• Aplicação 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.
• Utilização da metodologia no apoio às aulas de engenharia de software.

Capítulo 13 - BIBLIOGRAFIA
1. BOOCH Grady et al. UML : Guia do Usuário, O mais avançado 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. Histórico 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 Araújo et al. UML : Diagrama de Atividade.
http://www.dcc.ufmg.br/~marcosfg/. Consultada em 24/03/2001.
6. UML - Diagramas de Implementação : importantes quando trata de
questões como reutilização e desempenho.
http://www.dcc.ufmg.br/~gorgulho/tbd/seminario.html. Consultada em
24/03/2001.
7. UML – Introdução : ao modelar alguma coisa, estamos criando uma
simplificação da realidade para um melhor entendimento do sistema.
http://www.dcc.ufmg.br/~lucanaan/tbd/texto.htm. Consultada 24/03/2001.

122
8. ARAÚJO, Bethânia Lagoeiro. Uma Contribuição para o Problema de
Compatibilização de Modelos na UML.
http://www.dcc.ufmg.br/pos/html/spg98/node3.html . Consultada em
24/03/2001.
9. CNPQ, UFSC. UML : Unified Modeling Language. Abrange sua história,
definições, arquivos e sites relacionados. http://www.eps.ufsc.br/~wolff .
10. BARROS, Pablo. UML : Linguagem de Modelagem Unificada em
Português. 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 PADRÕES : Uma introdução à
análise e ao projeto orientados a objetos. Porto Alegre - Bookman,
2000.
13. FOWLER, Martin, Kendal Scott. UML ESSENCIAL : Um breve guia para a
linguagem padrão de modelagem de objetos. Porto Alegre - Bookman,
2000.
14. PRESSMAN, Roger S. . ENGENHARIA DE SOFTWARE. São Paulo -
Makron Books ,1995.
15. RUMBAUGH, James, Michael Blaha, William Premerlani, Frederick Eddy,
Willian Lorensen. MODELAGEM E PROJETOS BASEADOS EM
OBJETOS. Rio de Janeiro - Campus, 1994.
16. FURLAN, José Davi. MODELAGEM DE OBJETOS ATRAVÉS DA UML :
The Unified Modeling Languagem. São Paulo - Makron Books, 1998.

123
17. MAZZOLA, Vitório Bruno. CONCEITOS BÁSICOS DA ORIENTAÇÃO A
OBJETOS : Capítulo 1, 1999.
18. COOD, Peter, Edward Yourdon. ANÁLISE BASEADA EM OBJETOS. Rio
de Janeiro - Campus, 1991.
19. YOURDON, Edward, Carl Argila. ANÁLISE E PROJETO ORINTADOS A
OBJETOS : Estudos de Casos. São Paulo - Makron Books, 1999.
20. SILVA, Nelson Peres da. PROJETO E DESENVOLVIMENTO DE
SISTEMAS. São Paulo - Érica, 1998.
21. MIZRAHI, Victorine Viviane. TREINAMENTO EM C++. São 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 - Formulário de documentação.
Fonte
Tipo : <nome da fonte> Tamanho : <tamanho da fonte>
Gravação
Pasta Mãe : <Nome do Sistema>
Descrição : <Abaixo desta pasta mãe estão todos os arquivos
necessários referentes a documentação do software>.
Extensão de Arquivos : <tipo da extensão>
Impressão
Tamanho do papel: <medidas do formulário>
Backup
Responsável: <Nome do responsável pelo Backup>
Periodicidade:
Versão: <N.NX-NN>
125
2. Anexo 02 - Formulário de contato.
Data: <dd/mm/aaaa> Data do contato do cliente
Razão Social: <Nome da Empresa solicitante do software>
Solicitante: <Nome para contato na empresa>
Departamento: <Departamento do solicitante>
Fone:
Fax :
Ramal:
Email:
Descrição: <Neste item deve-se tentar passar o máximo de
informações possíveis sobre a solicitação>
Tipo do pedido: ( ) Novo ( ) Alteração <Informar neste item se
trata-se de software e/ou rotina novos ou alteração>
Área de negócio do problema: < De acordo com o pedido deve-se
definir a área de negócio, para que os envolvidos possam verificar se podem
atender ou não>
Prioridade: ( ) Normal ( ) Alta ( ) Urgente <Definir aqui a
prioridade do pedido>
Data pretendida para solução: <O preenchimento se faz necessário,
pois será estudada pela equipe onde será discutido a possibilidade ou não de
ser efetuada>
126
3. Anexo 03 - Formulário da ata de reunião
Data : <dd/mm/aaaa> Hora Início : <hh:mm>Hora Final: <hh:mm>
Participantes: <Nome1>, <Nome2>,....
Objetivos: <Deve definir o que se pretende alcançar com o sistema,
os setores atendidos>
Observações: <Definição dos itens que ajudarão no
desenvolvimento do sistema>
Definições da reunião: <A definição engloba tudo o que foi definido
na reunião>
127
4. Anexo 04 - Formulário lista de atores
Nome Descrição
<Nome do ator> <Descrever em poucas palavras
o que o ator faz e com o que ele interage>

128
5. Anexo 05 - Formulário 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 - Formulário de requisitos de caso de uso.
NOME : <Nome do caso de uso>
DESCRIÇÃO: <Descrever a funcionalidade do caso de uso>
ATORES: <Listar os atores que interagem no caso de uso>
DATA ALTERAÇÃO AUTOR
<data> <Descrição da alteração> <Listar os autores>
SITUAÇÃO INICIAL DO PROCESSO : <O que precisa para existir o
caso de uso>
FLUXO NORMAL: <Seqüência de passos que ocorre naturalmente
com maior freqüência. Esta seqüência deverá ser ordenada e cada passo
corresponde a uma ação do usuário e uma resposta do sistema ou vice-versa>
FLUXOS ALTERNATIVOS: <Usa-se quando o fluxo normal não for
seguido. Neste caso, também serão feitas seqüências de passos alternativos
ordenados e identados conforme o fluxo normal que o gerou>
REQUISITOS MÍNIMOS: <Os dados que tem que existir ou eventos
que tem que ocorrer para que o caso de uso seja válido>
PONTOS DE EXTENSÃO: <São casos de uso que usam outro caso
de uso>
VARIAÇÕES DE DADOS E TECNOLÓGICAS: <Mudanças que
podem ocorrem que irão afetar no funcionamento do sistema>

130
7. Anexo 07 - Formulário Diagrama de caso uso
NOME : <Nome do diagrama>
DESCRIÇÃO: <Descrever em poucas palavras o propósito 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 criação/alteração>
ALTERAÇÃO <descrição da alteração>
AUTOR <nome do responsável da criação/alteração>

131
8. Anexo 08 - Formulário de Cronograma
Fase: <Fase do projeto>
Responsáveis:
Nome do Responsável Assinatura
<Nome(s) do(s) responsável(is) pela fase> <Assinatura de cada responsável>
Data Prevista: <Data prevista para conclusão da fase>

132
9. Anexo 09 - Formulário de Aprovação
Fase: <Fase do projeto>
Declaramos que a presente fase está de acordo com o propósito do sistema.
Aprovado por
Nome Assinatura
<Nome(s) do(s) responsável(is) pela fase> <Assinatura de cada responsável>
Data da Aprovação: <Data que fase foi aprovada>

To em UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

To em UML

Uploaded by

Copyright:

Available Formats

UNISUL – UNIVERSIDADE DO SUL DE SANTA CATARINA

PESQUISA E DESENVOLVIMENTO EM UML

PESQUISA E DESENVOLVIMENTO EM UML

Projeto apresentado à disciplina de

UNISUL – UNIVERSIDADE DO SUL DE SANTA CATARINA

Aprovamos o Projeto PESQUISA E DESENVOLVIMENTO EM UML, elaborado

Prof. Carlos Fernando Buss

Prof. Luciano Savio

Prof. Alessandro Zanini

Prof. Ana Cláudia G. Barbosa

Prof. Juarez Bento Da Silva

Dedicamos este Trabalho a nossos pais, namoradas e familiares que

sempre nos apoiaram e estiveram a nosso lado em todos os momentos.

A todos os colegas e professores, em especial Alessandro Zanini,

quais nos incentivaram e deram apoio no desenvolvimento deste Projeto.

As empresas Seara Alimentos S/A, Domínio Sistemas Ltda e Betha

Sistemas Ltda, em especial ao colega Cristiano Tomasi(Betha Sistemas Ltda).

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

Capítulo 1 - INTRODUÇÃO ................................................................................... 1

1.1 Apresentação ............................................................................................ 1

1.2 Objetivos Geral e Específicos ................................................................... 2

1.4 Abrangência .............................................................................................. 4

1.6 Estrutura ................................................................................................... 5

Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A OBJETOS ..................... 8

2.2 Análise Orientada a Objetos ..................................................................... 9

2.3 Projeto Orientado a Objetos.................................................................... 10

2.4 Classes ................................................................................................... 11

2.6 Abstração ................................................................................................ 12

2.6.1 Abstração de Procedimentos ........................................................... 12

2.6.2 Abstração de dados.......................................................................... 12

2.7 Encapsulamento ..................................................................................... 13

2.8 Herança .................................................................................................. 13

2.9 Polimorfismo ........................................................................................... 14

Capítulo 3 - UML ................................................................................................. 15

3.1 Introdução ............................................................................................... 15

3.2 Histórico .................................................................................................. 16

3.3 Aceitação ................................................................................................ 18

3.4 Padronização OMG................................................................................. 19

3.5 Aplicação ................................................................................................ 19

Capítulo 4 - ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML ....... 20

4.1 Análise de Requisitos.............................................................................. 20

4.2 Análise .................................................................................................... 21

4.5 Testes ..................................................................................................... 23

Capítulo 5 - FERRAMENTAS CASE................................................................... 24

5.3 Aceitação no Mercado ............................................................................ 27

5.4 O Futuro .................................................................................................. 28

5.5 Rational Rose.......................................................................................... 28

Capítulo 6 - VISÕES DE SISTEMAS................................................................... 30

6.2 Visão USE-CASE.................................................................................... 31

6.3 Visão Lógica............................................................................................ 31

6.4 Visão de Componentes........................................................................... 32

6.5 Visão de concorrência............................................................................. 32

6.6 Visão de Organização............................................................................. 33

Capítulo 7 - MODELOS DE ELEMENTOS.......................................................... 34

7.1 Definição ................................................................................................. 34

7.2 Classes ................................................................................................... 35

7.2.1 Nomes .............................................................................................. 36

7.2.2 Atributos ........................................................................................... 37

7.2.3 Operações ........................................................................................ 38

7.4 Estados ................................................................................................... 40

7.5 Pacotes ................................................................................................... 42

7.7 Relacionamentos .................................................................................... 43

7.7.1 Associações ..................................................................................... 44