ndice

1.

INTRODUO..............................................................................................................................................................2

2.

ENFOQUES DOS MTODOS DE ANLISE DE SISTEMAS.................................................................................3

2.1
2.2
2.3
2.4

3.

PRINCPIOS DA ORIENTAO A OBJETOS.........................................................................................................6

3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8

4.

ENFOQUE DA MODELAGEM USANDO DECOMPOSIO FUNCIONAL.............................................................................3

ENFOQUE DA MODELAGEM USANDO FLUXO DE DADOS.............................................................................................3
ENFOQUE MODELAGEM DE INFORMAES..................................................................................................................4
ENFOQUE DA MODELAGEM ORIENTADA A OBJETOS...................................................................................................4
ABSTRAO.................................................................................................................................................................6
ENCAPSULAMENTO.......................................................................................................................................................7
CLASSE E OBJETO........................................................................................................................................................8
HERANA.....................................................................................................................................................................9
ESCALA......................................................................................................................................................................10
ASSOCIAO..............................................................................................................................................................11
COMUNICAO COM MENSAGENS.............................................................................................................................12
POLIMORFISMO...........................................................................................................................................................14

PRINCIPAIS MTODOS ORIENTADOS A OBJETOS.........................................................................................15

4.1 MTODO WIRFS-BROCK [WIRFS-BROCK ET ALII 90]................................................................................................16
4.2 MTODO COAD/YOURDON ORIENTADO A OBJETOS[COAD E YOURDON 91A, 91B]..................................................16
4.3 MTODO FUSION [COLEMAN ET ALII 94]...................................................................................................................18
4.3.1
Anlise.............................................................................................................................................................19
4.3.2
Projeto.............................................................................................................................................................28
4.3.3
Implementao.................................................................................................................................................31
4.3.4
Dicionrio de Dados.......................................................................................................................................32
4.4 MTODO UML [UML 97, UML 98, BLAHA AND PREMERLANI 98]..........................................................................33
4.4.1
Use Case View.................................................................................................................................................37
4.4.2
Logical View....................................................................................................................................................49
4.4.3
Component View..............................................................................................................................................56
4.4.4
Deployment View.............................................................................................................................................59

1.

Introduo

Os sistemas desenvolvidos hoje tm caractersticas diferentes dos sistemas de 10 a 15 anos

atrs. So maiores, mais complexos e mais sujeitos a alteraes constantes. Tambm, os sistemas
interativos e on-line dedicam mais ateno interface com o usurio do que os sistemas antigos,
tipicamente com entradas em batch. Hoje, alguns sistemas chegam a ter 75 a 80 porcento da
codificao relacionada interface, que inclui manipulao de janelas, menus pull-down, cones,
movimentos de mouse, etc. Por outro lado, muitas organizaes consideram seus sistemas atuais mais
"baseados em dados" e com menor complexidade funcional do que os sistemas dos anos 70 e 80. A
verdade que o uso de Bancos de Dados tem-se tornado mais comum nos sistemas atuais.
Os mtodos para desenvolvimento de software orientado a objetos so relativamente novos e a
tendncia serem aperfeioados cada vez mais na prtica. Esta Nota de Aula(NA) apresenta os
conceitos essenciais do desenvolvimento orientado a objetos, servindo como ponto de partida na
habilitao do desenvolvedor para aplicao da Anlise Orientada a Objetos(AOO) e Projeto
Orientado a Objetos(POO). O mtodo usado nos exemplos e estudos de caso segue a Unified
Modeling Language (UML), podendo contudo ser adequado e expandido de acordo com suas
necessidades de projeto ou sua organizao especfica.
Com relao Implementao Orientada a Objetos(IOO), sabe-se que esta teve incio nos anos
70 com a linguagem SIMULA, parte da linguagem Smaltalk desenvolvida pela Xerox PARC. At
ento o paradigma das linguagens imperativas, funcionais e lgicas dominava a programao de
sistemas desenvolvidos usando mtodos: de decomposio funcional e particionado em dados. Os
conceitos bsicos do desenvolvimento de software orientado a objetos levaram mais de 10 anos para
amadurecerem. Da mesma forma que era difcil pensar em programao estruturada quando as
linguagens disponveis eram Assembler e Fortran, tambm ficava difcil pensar em programao
orientada a objetos quando no se dispunha de linguagens como C++, Smaltalk, Ada, Delphi e Java.
Os Estudos de Caso foram implementados em Java, porm outras linguagens como Delphi ou
C++ poderiam ser utilizadas.
Esta NA apresenta a AOO, POO e IOO em 7 captulos. O captulo 2 apresenta uma viso geral
do Mtodo de Anlise de Sistemas segundo os principais enfoques: funcional, de fluxo de dados, de
modelagem de informaes e orientado a objetos. O captulo 3 apresenta os princpios da orientao a
objetos, que so fundamentais para o entendimento do novo paradigma. No captulo 4 so
apresentados os principais mtodos para modelagem orientada a objetos. No captulo 5 apresenta-se o
Mtodo UML, usando um estudo de caso implementado em Java com Banco de Dados Relacional. O
captulo 6 apresenta o mesmo estudo de caso usando um Banco de Dados Orientado a Objetos.
Finalmente o captulo 7 apresenta um outro estudo de caso usando Banco de Dados Relacional com
Stored Procedures.

2.

Enfoques dos Mtodos de Anlise de Sistemas

Neste captulo, sero apresentados, de uma forma sucinta, os principais enfoques utilizados
pelos mtodos tradicionais de desenvolvimento de sistemas para auxiliar na elicitao de
requisitos[Davis 90]. Quatro enfoques so apresentados: Decomposio Funcional, Fluxo de Dados,
Modelagem de Informaes e Modelagem Orientada a Objetos.

2.1

Enfoque da Modelagem usando Decomposio Funcional

Na decomposio funcional, o domnio do problema deve ser mapeado para uma hierarquia de
funes e subfunes. Por exemplo, o mtodo HIPO(Hierarchy plus Input-Process-Output),
desenvolvido pela IBM, baseia-se em dois componentes principais: Representao Hierrquica, que
mostra como uma funo se subdivide em vrias funes e Representao de Entrada-Processo-Sada,
que mostra cada funo na hierarquia em termos de suas entradas e sadas. De uma forma geral, na
decomposio funcional, o desenvolvedor apresenta como resultado os nveis de sistema, subsistema,
funo e subfuno.
Os principais problemas do enfoque da decomposio funcional so relacionados com a
instabilidade da funcionalidade do sistema e com a dificuldade de se obter alta coeso e baixo
acoplamento, na descrio da composio dos componentes do sistema e nas interfaces entre estes
componentes. Muitos desenvolvedores encontraram dificuldades para identificar funes capazes de
suportar os novos requisitos do sistema com mnimas alteraes na anlise e organizao da
especificao.
Na prtica, a AOO usa a decomposio funcional, porm num contexto muito especfico,
quando se deseja dividir um grande Servio (comportamento que um objeto deve apresentar) em partes
menores para tornar mais claro e diminuir a complexidade. Esta definio, bom ressaltar, feita
dentro de um contexto muito limitado, no sendo usada como estrutura organizacional principal da
anlise.

2.2

Enfoque da Modelagem usando Fluxo de Dados

Este enfoque talvez seja o mais conhecido, pois tem sido utilizado largamente no
desenvolvimento da maioria dos sistemas. Mtodos conhecidos como anlise estruturada mapeiam o
mundo real atravs de Atividades e fluxos de dados. Os problemas com a anlise estruturada e mais
recentemente anlise estruturada moderna, so relacionados com a dificuldade de conexo do
Diagrama de Fluxo de Dados(DFD) com a modelagem de informaes e da transio da anlise para o
projeto. Tambm, o lado funcional deste enfoque muito forte e acaba tendo os mesmos problemas da
decomposio funcional. A utilizao do Diagrama de Entidade e Relacionamento(DER) em conjunto
com o DFD e o particionamento do sistema por eventos da Anlise Essencial trouxe alguns resultados
positivos, porm ainda continua traumtica a conexo prtica do DFD e DER e a passagem do DFD,
uma representao em rede das atividades e dos depsitos de dados, para o Diagrama Estruturado(DE)
com representao hierrquica dos mdulos. Ainda, a utilizao de notaes distintas para

funes(DFD) e dados(DER), embora suportado por ferramentas CASE, no muito bom porque leva
a raciocnios separados.
Outro aspecto a ser mencionado com relao a este enfoque de fluxo de dados o tamanho do
dicionrio de dados que tende a ficar enorme no caso de existirem vrios nveis de DFDs, quando
centenas de equaes de nivelamento de fluxo de dados podem ser necessrias. Outra considerao
que DFDs no so muito teis para sistemas ou partes de sistemas que principalmente atualizam ou
recuperam dados, ao contrrio dos sistemas voltados para o processamento de transaes.

2.3

Enfoque Modelagem de Informaes

A modelagem de informaes numa abordagem mais moderna consiste em mapear objetos do

mundo real atravs de seus atributos; adicionar relacionamentos entre estes objetos; aperfeioar com
supertipos/Subtipos (para extrair atributos comuns) e objetos associativos (para descrever certos
relacionamentos); e finalmente normalizar (um enfoque passo a passo para reduzir redundncias de
dados, o que uma implementao tpica de banco de dados relacional). A principal ferramenta deste
enfoque o DER.

2.4

Enfoque da Modelagem Orientada a Objetos

Muito se tem pesquisado segundo este enfoque, que representa o mundo real com objetos e
suas interaes. Busca-se a soluo dos problemas atravs de uma modelagem orientada a objetos,
conforme mostra a Figura 2.1. Os autores [Rumbaugh et alii 91] em seu ltimo livro, apresentam
conceitos importantes nos quais se baseia a AOO.

Mundo
dos
Objetos

Modelagem

Problemas

Sistemas

Solues

Figura 2.1 - Paradigma da Orientao a Objetos

Na AOO a interao entre o usurio e o sistema baseada em mensagens, que correspondem,

na anlise estruturada moderna, associao dos fluxo de dados com os eventos que documentam as
solicitaes do usurio.
Os grandes problemas da anlise de sistemas em quase todos os sistemas esto relacionados
com: a compreenso do domnio do problema, comunicao dos fatos, evoluo contnua e
reutilizao. O desenvolvedor precisa compreender e modelar o domnio do problema, especialmente
no caso de sistemas grandes e complexos. A partir do domnio do problema, concentrar-se- nos
aspectos especficos do seu problema, ou seja, na descrio das responsabilidades do sistema que est
sendo considerado, estabelecendo dessa forma as fronteiras do sistema.
O desenvolvedor precisa tambm se comunicar efetivamente para extrair informaes sobre o
domnio do problema e sobre os requisitos do sistema. A engenharia de software depende muito mais
das pessoas do que das frmulas complicadas, como ocorre nas demais engenharias.
Os requisitos para um sistema so mutveis. Sabe-se que novos requisitos podem surgir devido
s mudanas de software, hardware, legislaes, melhorias, etc. A identificao de caractersticas
comuns facilita a absoro de alteraes.
Hoje, a reutilizao est presente em todo o ciclo de vida do software. O reuso da anlise,
projeto e cdigo em sistemas semelhantes economiza tempo e recursos. Sabe-se que o domnio de
problemas mudou muito pouco nos ltimos anos. Os resultados da anlise podem ser reutilizados e
aperfeioados em novos sistemas, com solues especficas de acordo com as restries de
cronograma e oramento.
Assim, a AOO aceitou o desafio de, se no resolver, pelo menos amenizar estes problemas de:
compreenso do domnio do problema, comunicao dos fatos, evoluo contnua e reutilizao. Para
tal, a AOO baseia-se na aplicao uniforme dos princpios para administrao da complexidade de um
domnio de problemas e das responsabilidades do sistema dentro dele. Um dos maiores problemas
do desenvolvedor a definio do domnio do problema, que abrange um campo de atividades sob
estudo ou considerao. Exemplos de domnios incluem as linguagens, as leis, as finanas e o controle
do espao areo.
Definido o domnio do problema, o desenvolvedor se concentrar nos aspectos especficos do
seu trabalho, ou seja, na descrio das responsabilidades do sistema que est sendo considerado. Sendo
sistema um conjunto ou arranjo de elementos relacionados ou interligados de modo a formar uma
unidade ou um todo orgnico[Webster's 77] (como por exemplo o sistema rodovirio, de contabilidade
ou de irrigao), tem-se que as responsabilidades do sistema podem ser definidas como uma
organizao de elementos relacionados de modo a formar um todo.
A grande dificuldade que o desenvolvedor tem que conhecer o domnio do problema no qual
trabalha. Por exemplo, considere um domnio de bibliotecas. O desenvolvedor precisa conhecer tudo
sobre bibliotecas, regras gerais, linguagem usada, detalhes e excees. Uma vez definido o domnio
pode-se ento desenvolver sistemas especficos de biblioteca. Se o desenvolvedor simplesmente
assumir certos conhecimentos sobre o assunto, provavelmente, estabelecer requisitos confusos ou
invlidos.
A AOO baseia-se em princpios cujo conhecimento importante para o entendimento dos
mtodos utilizados no desenvolvimento de sistemas segundo este novo paradigma orientado a objetos.
Estes princpios, usados em diferentes mtodos de anlise e projeto orientado a objetos, para
administrar a complexidade e facilitar a modelagem de sistemas, sero apresentados a seguir.

3.

Princpios da Orientao a Objetos

O conhecimento dos princpios da Orientao a Objetos de grande importncia porque

facilita o entendimento das idias, tcnicas e ferramentas deste novo paradigma. Um mtodo, uma
ferramenta, um ambiente ou uma linguagem tanto mais orientado a objeto quanto mais atende aos
princpios da orientao a objeto.

3.1

Abstrao

Abstrao a habilidade de ignorar os aspectos de um assunto no relevantes para o propsito

em questo, tornando possvel uma concentrao maior nos assuntos principais[Oxford 86]. A
abstrao consiste portanto na seleo que um desenvolvedor faz de alguns aspectos, suprimindo
outros. Pessoas, lugares, coisas e conceitos do mundo real so normalmente complexos. Quando
queremos diminuir a complexidade selecionamos parte do que estamos analisando, em vez de
tentarmos compreender o todo.
A abstrao pode ser de: procedimentos e objetos.
Abstrao de procedimentos baseia-se no princpio de que qualquer operao com um efeito
bem definido pode ser tratada por seus usurios como uma entidade nica, mesmo que a operao seja
realmente conseguida atravs de alguma seqncia de operaes de nvel mais baixo[Oxford 86].
Normalmente, usamos abstrao de procedimentos quando definimos em nossos DFDs
macrofunes que se decompem em funes, as quais por sua vez se decompem em subfunes. Um
sistema em seu nvel mais alto pode ser abstrado como um caixa preta que, uma vez executado,
produz os resultados desejados. Dividir o sistema em processos e subprocessos, muito usado na anlise
estruturada, no a forma principal de particionamento ou abstrao da AOO. Na AOO a abstrao de
procedimentos usada dentro do contexto limitado da especificao e descrio de servios.
Abstrao de objetos consiste em definir os servios e atributos aplicveis a estes objetos. Estes
objetos s podem ser modificados e observados atravs destes servios[Oxford 86].
A abstrao de objetos serve de base para a organizao do pensamento e a especificao das
responsabilidades do sistema. a habilidade de descrever novos tipos de dados em termos de seus
formatos e servios que agem sobre eles.
Ao aplicar a abstrao de objetos, o desenvolvedor define:
- atributos e
- servios que manipulam exclusivamente estes atributos.
Atributo qualquer propriedade, qualidade ou caracterstica que pode ser atribuda a uma
pessoa ou objeto[Webster's 77]. Na AOO, o termo atributo definido de forma a refletir o domnio do
problema e as responsabilidades do sistema, ou seja, atributo um dado (informao de estado) para o
qual cada objeto em uma classe tem seu prprio valor. Os atributos s podem ser acessados atravs de
um servio.

Servio uma atividade executada para permitir que as pessoas utilizem alguma coisa
[Webster's 77]. Na AOO, o termo servio definido de forma a refletir o domnio do problema e as
responsabilidades do sistema, ou seja, servio um comportamento especfico que um objeto deve
exibir.
A abstrao tambm depende do ponto de vista. Por exemplo, o coelho da Figura 3.1, sob o
ponto de vista da moa tem atributos cor, aparncia, etc, e sob o ponto de vista do veterinrio tem
atributos peso, tamanho, etc. Da mesma forma, tem-se os servios correr e brincar, sob o ponto de
vista da moa, e criar e comer sob o ponto de vista do veterinrio.

cor
aparncia

peso
tamanho

Correr
Brincar

Criar
Comer

Figura 3.2- Abstrao

3.2

Encapsulamento

Princpio usado no desenvolvimento de uma estrutura global de programa, que estabelece que
cada componente do programa deve conter uma nica deciso de projeto. A interface para cada
mdulo definida de forma a revelar o menos possvel sobre seu funcionamento interno[Oxford 86].
O objetivo do encapsulamento (ocultamento de informaes) restringir o escopo ou
visibilidade da informao para obter melhor legibilidade, manutebilidade e principalmente
reutilizabilidade no desenvolvimento de um novo sistema. O encapsulamento permite que o
desenvolvedor reuna os aspectos mais instveis de forma a facilitar sua localizao e manuteno em
caso de alteraes, hoje muito comum nos sistemas.
O encapsulamento pode ainda ser visto como um processo pelo qual se combinam os atributos
e os servios que agem sobre estes atributos, em uma definio que oculta detalhes de implementao.
Por exemplo, a calculadora da Figura 3.2, tem internamente seus registradores, que so ocultos por
uma interface que disponibiliza para o usurio apenas os servios de Somar, Subtrair e outras

operaes. Note ainda que detalhes dos processos pelos quais se obtem um resultado no esto
diretamente visveis para quem est usando a calculadora, e nem mesmo isto interessa. Em resumo,
juntam-se atributos e servios disponibilizando apenas o que interessa mostrar, normalmente os
servios.

Figura 3.2- Encapsulamento : Calculadora

3.3

Classe e Objeto

Das idias de abstrao e encapsulamento tem-se o Tipo Abstrato de Dados(TAD), que possui
uma interface para ocultar detalhes de implementao, possibilitando que se tenham diferentes
especificaes, em diferentes tempos, sem afetar as aplicaes que utilizam o TAD. Um TAD
tambm chamado de Classe, a qual pode ser vista como uma fbrica de objetos idnticos no que diz
respeito sua interface e implementao. Assim por exemplo, tem-se, na Figura 3.3, o TAD Pessoa, ou
a Classe Pessoa, cujos atributos so Nome, Endereo, Identidade, Estado Civil e outros, e cujos
servios so Estudar, Trabalhar, Dirigir, Passear, e outros. Uma classe portanto um conjunto de
objetos similares. Uma instncia de uma classe chamada Objeto da Classe. Na Figura 3.3 tem-se que
Maria e Pedro so duas instncias da classe Pessoa.

classe Pessoa

objeto Maria

objeto Pedro

Figura 3.3 Classe e Objeto Pessoa

3.4

Herana

A abstrao de dados uma tcnica efetiva para se definir um conceito nico e claro, como os
TADs. Contudo, muitas vezes pode-se ter um TAD que quase, mas no exatamente o que queremos
e, neste caso, a herana uma tcnica til para ampliar a abstrao de dados. Baseado nestes conceitos,
define-se:
Herana o mecanismo para expressar a similaridade entre Classes, simplificando a definio
de Classes iguais a outras que j foram definidas.
Este princpio permite representar membros comuns, servios e atributos uma s vez, assim
como especializar estes membros em casos especficos.
A herana permite, portanto, a reutilizao de especificaes comuns, logo no incio das
atividades de anlise. A herana define uma relao entre classes do tipo -um(a), onde uma classe
compartilha a estrutura e o comportamento definidos em uma ou mais classes. O reconhecimento da
similaridade entre classes forma uma hierarquia de classes, onde superclasses representam abstraes
generalizadas e subclasses representam abstraes, onde atributos e servios especficos so
adicionados, modificados ou removidos. As classes so conectadas por uma estrutura de
generalizao e especializao, tornando explcitos os atributos e servios comuns em uma
hierarquia de Classes.
Na Figura 3.4, tem-se, por exemplo, que Estudante uma Pessoa, Professor uma Pessoa. Um
objeto da classe Estudante, tem no apenas os atributos e servios de Estudante, como tambm os
atributos herdados da classe Pessoa. Por exemplo, o estudante Joo tem atributos e servios de Pessoa,
como Nome, Endereo, Dirigir, Viajar, e atributos e servios que expressam o comportamento
especfico de um estudante, como Curso, Nota, Estudar e Realizar Prova. A classe Pessoa
reconhecida como uma generalizao e Estudante como uma classe especializao, a qual herda os
servios e atributos de Pessoa. Alm disso, uma classe derivada (uma especializao) pode incluir
novos servios e atributos ou redefinir os servios herdados. Dessa forma, Funcionrio pode incluir

atributos como Salrio e Profisso e servios como CalcularSalrio, que podem no ser relevantes ou
apropriados para Pessoa em geral.

Pessoa

Estudante

Professor

Funcionrio

Diretor

Figura 3.4 - Herana : Classe Pessoa e classes derivadas

3.5

Escala

o princpio que permite ao desenvolvedor considerar algo muito grande atravs do enfoque
Todo-Parte. Todo-Parte um dos servios bsicos naturais de organizao dos seres humanos que
orienta o desenvolvedor atravs de um modelo extenso.
Todo-Parte tambm conhecido como Agregao, que um mecanismo que permite a
construo de uma classe agregada a partir de outras classes componentes. Usa-se dizer que um objeto
da classe agregada(Todo) tem objetos das classes componentes(Parte). Por exemplo, na Figura 3.5
tem-se que uma casa tem portas, janelas, paredes, escadas e outras partes.
TODO

PARTES

Figura 3.5 - Todo-Parte : Classe Casa e classes compostas

Mesmo em se tratando de entidades abstratas, pode-se compor um objeto a partir de outros

objetos. A Figura 3.6 mostra que um Pedido (Todo) composto ou tem ItensPedidos(Partes), no
caso Relgio e Computador.

TODO

PEDIDO

PARTES

Item 1: Relgio

Item 2: Computador

Figura 3.6 - Todo-Parte : Classe Pedido e classes compostas

3.6

Associao

A associao vem do relacionamento entre as entidades do mundo real, e usada para agrupar
certos objetos que ocorrem em algum ponto no tempo ou sob circunstncias similares.
Associao uma unio ou conexo de idias[Webster's 77]. Na AOO, a associao
modelada atravs de uma conexo de ocorrncias. Uma conexo de ocorrncia um relacionamento
que um objeto precisa ter com outro(s) objeto(s), para cumprir suas responsabilidades. Por exemplo, a
Figura 3.7 mostra a associao entre Estudante, Teste e Sala. Neste relacionamento ternrio, tem-se
que cada estudante faz determinado teste em uma sala. Outros tipos de relacionamentos binrios ou de
maior ordem podem existir, como o mostrado na Figura 3.8 onde Cliente faz determinado Pedido.

Estudante

Faz

Teste

Sala

Figura 3.7 Associao : Relacionamento Estudante-Teste-Sala

Cliente

Faz

Pedido

Figura 3.8 Associao: Relacionamento Cliente - Pedido

3.7

Comunicao com Mensagens

Mensagem qualquer comunicao, escrita ou oral feita entre pessoas[Webster's 77]. Na AOO,
a comunicao entre objetos, feita atravs de mensagens modeladas usando conexes de mensagens.
Uma conexo de mensagem modela a dependncia de processamento de um objeto, indicando quais
servios ele precisa para cumprir suas responsabilidades. As conexes de mensagens existem somente
em funo dos servios, e fazem o mapeamento:

de um objeto para outro objeto;

de um objeto para uma classe (criao de objetos) e
de uma classe para outra classe (criao de objetos dentro de outros objetos).

Numa conexo de mensagem, tem-se uma classe ou objeto emissor que envia a mensagem para
uma classe ou objeto receptor para realizao de algum processamento. O processamento necessrio
nomeado na especificao de servios do emissor, e definido na especificao de servios do
receptor.
Na Figura 3.9, uma estudante, objeto da classe Estudante, dispara uma mensagem para o
professor, objeto da classe Professor. A mensagem tratada e retornada uma resposta.

Abram seus
livros na
pgina 36

Qual a
prxima
lio?

Figura 3.9 Conexo de Mensagem : Aluno e Professor

Os servios modelam o comportamento dos objetos.

Trs tipos de classificao de comportamento so mais freqentemente usados:
(1) com base na causa imediata;
(2) conforme similaridade de evoluo histrica(alterao com o tempo) e
(3) conforme a similaridade de funo.
Considerando que, na AOO, a considerao central na definio de servios definir o
comportamento requerido que um objeto deve refletir, estes princpios so incorporados nas
estratgias que definem:
(1) Estados de objeto - elaborada com base no princpio de alterao com o tempo.
(2) Servios requeridos - elaborada com base nos princpios de similaridade de funo e causa
imediata.

3.8

Polimorfismo

Polimorfismo o princpio relacionado com as diferentes formas de um objeto.

Operacionalmente, o polimorfismo pode ser visto conforme mostra a Figura 3.10, onde se pode
instanciar um objeto Janela de vrias formas. Tambm pode-se observar que operadores podem ser
sobrecarregados para realizar operaes com diferentes tipos de objetos. Por exemplo, o operador +
est sendo utilizado para somar inteiros e matrizes.

Polimorfismo
Janela ( )
Janela ( 1 x 2 , 2 )
Janela ( 1 x 2 , 2, Azul )

95 + 5 = 100
3
23
0

-7
76
45

4
21
-9

+
13
23
11

45
56
46

8
3
18

Figura 3.10 - Polimorfismo

Finalizando este captulo, conclu-se que o conhecimento dos princpios da orientao a objetos
de fundamental importncia, principalmente porque nos ajuda a pensar em objetos e no apenas em
dados ou funes, como era no paradigma tradicional de desenvolvimento de software. Em seguida,
sero apresentados os principais mtodos utilizados para o desenvolvimento de software orientado a
objetos.

4. Principais Mtodos Orientados a Objetos

O termo orientado a objetos pode no apresentar uma idia clara, porque o nome objeto tem
sido usado de formas diferentes em duas reas diferentes:
(1) Na modelagem de informaes para representar alguma coisa real e suas ocorrncias.
Aqui, objetos dizem respeito apenas a dados; e
(2) Nas linguagens de programao orientada a objetos, significa uma instncia em tempo de
execuo de algum processamento e valores, definidos por uma descrio esttica chamada
classe.
Convm observar que na modelagem pura de informaes no h mecanismo de dependncia
uniforme de processamento e nem herana. Peter Wegner[Wegner 89] d o seguinte enfoque para as
linguagens de programao definidas segundo o paradigma orientado a objetos:
(1) Baseada em Objetos: Suporta a funcionalidade de objetos, mas no possui nem classes e
nem herana. Por exemplo, ADA.
(2) Baseada em Classes: Suporta a mesma funcionalidade da linguagem baseada em objetos e
inclui o conceito de classe. Por exemplo, CLU.
(3) Orientada a Objetos: Possui as mesmas caractersticas da linguagem baseada em classes e
inclui o princpio de herana. Por exemplo, C++ e Smalltalk[Goldberg and Robson 83].
A verdade que uma linguagem, um mtodo ou mesmo uma ferramenta CASE tanto mais
orientado a objetos quanto mais atende aos princpios do paradigma da orientao a objetos. A AOO
baseada nos conceitos da modelagem de informaes, das linguagens orientadas a objetos e ainda dos
sistemas baseados em conhecimentos, ou seja, nos princpios bsicos para a administrao da
complexidade.
Existem hoje no mercado vrios mtodos para desenvolvimento de sistemas orientados a
objetos. Alguns mtodos cobrem melhor as fases iniciais da coleta de fatos e anlise de requisitos e
outros a fase de projeto e implementao. Poucas propostas cobrem todo ciclo de vida do software. A
seguir apresentaremos uma descrio sucinta de alguns mtodos mais conhecidos, elaborada por
Cabral e outros [Cabral et alii 93]. Uma descrio mais detalhada pode ser encontrada nas
bibliografias referenciadas.

4.1

Mtodo Wirfs-Brock [Wirfs-Brock et alii 90]

Esta metodologia utiliza a viso cliente-servidor, enfatizando o comportamento dinmico e as

responsabilidades das classes.
A nfase dada s fases de Projeto e Implementao. O processo exploratrio e informal,
sendo mais adequado ao desenvolvimento de pequenos projetos. A introduo de novas terminologias
(contrato, responsabilidades e colaboraes) podem dificultar a sua aceitao, por apresentar
mudanas radicais em relao s metodologias j utilizadas.
A sua notao formada por:
Cartes de classes e subsistemas;
Diagrama de hierarquia de classes;
Diagrama de Venn: que ajudam a definir as responsabilidades das classes;
Diagrama de colaborao entre classes: que representa o comportamento dinmico destas e
Cartes de contrato: que documentam todos os contratos entre clientes e servidores.

4.2
91b]

Mtodo Coad/Yourdon Orientado a Objetos[Coad e Yourdon 91a,

O modelo AOO proposto por Coad/Yourdon consiste em cinco atividades principais:

identificao de Assuntos;
localizao de Classes-e-Objetos;
identificao de Estruturas;
definio de Atributos e
definio de Servios.

Estas atividades podem ser executadas em ordens diferentes, dependendo do domnio do

problema analisado e da experincia do desenvolvedor. Decidir quando a anlise e a especificao
termina depende do domnio, da responsabilidade dos sistema e das verificaes, tudo conforme as
exigncias de cronograma e oramento. Assim, o modelo de AOO apresentado e revisado em cinco
nveis, mostrados na Figura 4.1.

 Camadas da Analise OO

Assunto
Classe e Objeto
Estrutura
Atributo
Servico
Figura 4.3 - Nveis da AOO

Estes cinco nveis podem ser vistos como cinco camadas de especificaes superpostas,
conforme mostra o exemplo da Figura 4.2, que modela um sistema de distribuidora de produtos. Os
resultados da Anlise so representados pelo componente Domnio do Problema (CDP), atravs dos
diferentes nveis: Classe e Objetos, Atributo, Estrutura e Servio. O sistema est particionado num
nico Assunto, que no est representado no modelo.
Conforme se pode notar, ainda no se tm idias bem consolidadas sobre qual a melhor
abordagem a aplicar no desenvolvimento de sistemas orientados a objetos. O mtodo Coad/Yourdon,
apesar de apresentar pequenos problemas denotacionais quando usado em sistemas de grande escala,
tem as vantagens de ser bastante divulgado, muito didtico e de facilitar a compreenso dos novos
conceitos da AOO, POO e IOO.
O mtodo representa Classe e Objeto por retngulos com cantos arredondados, sendo o mais
interno a representao da Classe e o mais externo os Objetos. Na parte superior, tem-se o nome da
classe, no meio os atributos e na parte inferior os Servios.
A estrutura de Generalizao-Especializao (herana) representada por uma meia lua,
ligando a classe pais s classes derivadas (filhos). Todo-Parte representado por um tringulo, que
aponta o Todo. As conexes de ocorrncias so representadas por linhas cheias que ligam objetos de
uma classe a objetos de outra classe. Tanto no Todo-Parte como nas conexes de ocorrncias so
indicadas as respectivas cardinalidades (mnima, mxima), que indicam as ocorrncias de objetos nos
relacionamentos.
Conexes de mensagens so representadas por linhas mais cheias, ou tambm tracejadas,
partindo da classe emissora da mensagem e apontando a classe receptora da mensagem.
O mtodo usa a mesma notao para anlise e projeto. Outras ferramentas como Diagramas de
Servios e Diagramas de Transio de Estados so utilizados na modelagem.

Requisicao

Pedido
Nmero
Data
Atender

0,m

1,m

Detalhe
Requisio

Detalhe
Pedido
Quantidade
Situao

Cliente
Cod
Nome
End

1,m

0,m

0,m

Fornecedor

Produto
Cdigo
Nome

0,m

0,m

1,m

Listar

Pessoa
Fsica
CPF

0,m

1
0,m

Pagar

Emitir
TratarNota

Quantidade
Preo

1
0,m

Nmero
Data
NmeroNE
DataNE
Situao

1,n

Cdigo
Nome
End
Pagar

Fatura

Pessoa
Jurdica
CGC
1

Nmero
Valor
Vencimento
Situao

Emitir
Liquidar

Figura 4.4 CDP : Distribuidora de Produtos - Camadas Classe e Objetos, Atributo, Estrutura e Servio

4.3

Mtodo Fusion [Coleman et alii 94]

O mtodo Fusion foi desenvolvido para prover uma abordagem sistemtica para
desenvolvimento de software orientado a objetos.
O processo de desenvolvimento de software conta com dois estgios: produo e montagem. A
produo cobre as trs fases do ciclo de vida do software: Anlise (O que o sistema faz), Projeto
(define Como o comportamento especificado na anlise obtido) e Implementao (codificao do
projeto em linguagem de programao). Neste estgio obtm-se qualidade, evitando os erros. No
estgio da montagem do software, obtm-se qualidade pela deteco e remoo dos erros.
Quanto mais tarde um erro encontrado, mais cara ser a sua reparao. Um mtodo confivel
deve usar tcnicas que reduzam a probabilidade de erros, e deve conter checagem de erros que possam
ocorrer, pois mais eficiente evitar os erros que corrigi-los. O mtodo Fusion, ento, se concentra na
produo, ao invs da montagem do modelo.
Mtodos sistemticos gastam mais tempo nas fases prvias do desenvolvimento do software. O
cdigo leva mais tempo para aparecer, e seus benefcios incluem:

checagem de requisitos;
conceitos mais claros;
menos reprojeto de trabalho;
melhor fabricao do trabalho de projeto (decomposio do problema em partes
independentes);
melhoria das comunicaes entre os desenvolvedores e
necessidade de menos esforo na manuteno.

Fusion um mtodo de desenvolvimento que fornece

gerenciais do desenvolvimento de software:

suporte em aspectos tcnicos e

Divide o processo de desenvolvimento em fases e indica o que deve ser feito em cada fase;
Fornece notaes compreensveis e bastante formais e
Possui verificaes para assegurar a consistncia dentro e entre as fases.
Na anlise, os modelos so produzidos com objetivo de descrever:

classes de objetos que existem no sistema;

relacionamentos entre as classes;
operaes que podem ser executadas no sistema e
seqncias permissveis das operaes.

No projeto, o desenvolvedor decide como as operaes do sistema devem ser implementadas,

pelo comportamento em tempo de execuo da interao entre os objetos. Durante o processo,
operaes se prendem s classes, e o desenvolvedor escolhe tambm como os objetos vo se referir
uns aos outros, e quais so os relacionamentos de herana apropriados entres as classes. Os modelos
desta fase mostram:

Como operaes de sistemas so implementadas pela interao entre objetos;

Como as classes se referem umas s outras e como se relacionam por herana;
Classes, atributos e operaes em classes.

Na fase de implementao, o projeto deve ser transformado em cdigo numa linguagem de

programao executvel. A codificao numa linguagem orientada a objetos facilita a implementao.
Convm observar que:

Herana, referncia e atributos de classes so implementados em linguagem de programao;

Interaes entre objetos so codificadas como servios pertencendo determinada classe e
As seqncias permitidas de operaes so reconhecidas por mquina de estados.

O Fusion tambm oferece informao em questes de performance, e sugere como a inspeo

tradicional e as tcnicas de teste devem ser modificadas para software orientado a objetos.
4.3.1

Anlise

A anlise focaliza o domnio do problema, e diz respeito ao comportamento visivelmente

externo do sistema. A preocupao principal com os requisitos do sistema, ou seja, O Que? se
deseja do sistema. As restries de implementao e os problemas de tecnologias como por exemplo,
limitaes de processadores, memria, tempo de resposta e outros, no so relevantes nesta fase. A
fase de anlise produz dois modelos que capturam diferentes aspectos de um sistema:

Modelo Objeto: define a estrutura esttica de informao no sistema e

Modelo de Interface: define as comunicaes de entrada e sada do sistema.

Dependendo da complexidade do sistema, pode-se ter mais de um Modelo Objeto. Uma diviso
por assuntos pode proporcionar uma viso geral que orienta o desenvolvedor em um modelo extenso.
Os assuntos tambm so teis para a organizao de pacotes de trabalho em grandes projetos, para
facilitar a visibilidade e compreenso do modelo.
4.3.1.1 Modelo Objeto
Modela as classes de objetos e a associao entre objetos pertencentes s classes. Objeto uma
instncia da classe que pode ser univocamente identificada.
A parte esttica do objeto composta de:

Identificador;

nmero de atributos e

nome dos atributos.

Na fase de anlise, raramente nos preocupamos em como um objeto pode ser univocamente
identificado. Deve haver um identificador ou alguma combinao de atributos que contenha
informaes suficientes para tornar a identificao possvel. sempre possvel distinguir objetos
distintos, mesmo que tenham os mesmos valores de atributos. O objeto possui uma identidade que no
pode ser mudada.
Os objetos se comunicam para executar operaes atravs de mtodos ou servios. Os
servios tratam da parte comportamental dos objetos.
Uma classe uma abstrao que representa a idia ou a noo geral de um conjunto de objetos
similares. Objetos podem ter instncias de conexes um com o outro, mas no necessariamente ter
relacionamentos de subordinao. Estas conexes complementam a representao do estado do objeto
feita pelos seus atributos, modelando a unio ou conexo de idias. As pessoas usam estas conexes
para modelar certas coisas que acontecem em um determinado instante ou sob circunstncias similares,
ou seja, para mapear os relacionamentos entre os objetos, para que estes cumpram suas
responsabilidades. Na Figura 4.3 tem-se duas classes: Professor e Curso, cujos objetos se relacionam
atravs do relacionamento ensina, representado pelo losango que liga as duas classes.
Professor
Nome
Disciplina

Curso
+

ensina

1 Nome

Figura 4.3 - Relacionamento entre classes

O relacionamento entre as classes utiliza o limite de cardinalidade para restringir o nmero de

objetos que devem participar do relacionamento. As formas de representao so:
12
1..4
*
+

numrica
intervalo
zero ou mais (representao default)
um ou mais
todos os objetos da classe adjacente devem aparecer no
relacionamento.

Quando o relacionamento obscuro, podemos atribuir papis aos objetos, por exemplo no caso
em que um objeto pessoa pai ou me de outra pessoa ou casado com outra pessoa.
Algumas perguntas, apresentadas a seguir, podem orientar o desenvolvedor na definio dos
atributos. Supondo ser um objeto especfico, pergunte:

Como sou descrito em geral?

Como sou descrito neste domnio de problemas?
Como sou descrito no contexto das responsabilidades do sistema?
O que preciso saber?
De quais informaes de estado preciso sempre me lembrar?
Quais podem ser meus estados?

Seguindo os princpios bsicos da anlise, no crie atributos como Chave e TotalParcial, apenas
para atender restries de implementao. Identificadores explcitos como Chave servem para
identificar um objeto especfico, porm necessitam de garantias que evitem duplicatas, o que implica
em decises de projeto no importantes em nvel de anlise. TotalParcial representa um valor batch
dos resultados de processamentos anteriores. Na AOO mais adequado especificar o clculo
requerido, atravs de um Servio CalcularTotalParcial, do que especificar o atributo TotalParcial. Outro
caso, o da normalizao, que exige que no se tenha atributo multivalorado, porm esta preocupao
tambm no importante durante esta fase da modelagem, mesmo porque nesta fase o desenvolvedor
ainda no sabe se ir normalizar os dados.
A Figura 4.4 mostra um relacionamento entre Mdico e PacienteInterno, tal que cada paciente
de PacienteInterno tem obrigatoriamente um mdico, e um mdico pode ter 0 ou mais pacientes. Isto
significa que paciente no existe sem mdico e mdico existe mesmo sem paciente.
Mdico

PacienteInterno

Id
Nome
Endereo

examina

Quarto
Leito
Medicao

Figura 4.4 - Conexo de Ocorrncia

O caso especial com relacionamento muitos-para-muitos, como o mostrado na Figura 4.5, em

que os atributos DataHora e Quantia descrevem a interao, em determinado instante, entre um autor e
um livro, podem requerer a adio ao modelo, na fase de implementao, de uma classe do tipo
evento lembrado.
Autor
Nome
Endereo

Livro

Publica

DataHora
Quantia
Figura 4.5 - Conexo de Ocorrncia muitos-para-muitos

Ttulo
ISBN
Ano

A Figura 4.6 mostra um relacionamento entre objetos de uma nica classe. Se o significado de
um mapeamento for simples, como por exemplo, Proprietrio que casado com outro, ento apenas a
Conexo de Ocorrncia suficiente. Caso contrrio, adicione uma nova Classe-e-Objeto do tipo
evento lembrado.
Proprietrio

Casado

Marido

1
Esposa

Figura 4.6 - Relacionamento entre objetos de uma nica classe

Outro caso especial de Conexo de Ocorrncia ocorre quando for necessrio mais de um
mapeamento entre objetos, os quais precisam de alguma distino semntica, que pode ser obtida com
a adio de uma outra Classe-&-Objeto, evento lembrado. Na Figura 4.7, a Classe-e-Objeto
eventodeacesso capta a diferena semntica entre os diferentes mapeamentos das conexes ler e
modificar.
eventolegal

ler

modificar

eventolegal
1

tem

eventode
acesso
datahora
tipoacesso

escriturrio

escriturrio
*

faz

Figura 4.7 - Mltiplas Conexes de Ocorrncias entre objetos

Para um mapeamento correto, no domnio do problema e nas responsabilidades do sistema,

verifique as Conexes de Ocorrncias para cada par de objetos. Se for necessrio, ento adicione a
conexo correspondente.
O mtodo Fusion permite a agregao de classes, ou seja, a implementao do Todo-Parte.
Permite a construo de uma classe agregada formada por outras classes componentes. Tambm
possvel implementar a herana de classes, tanto simples como mltipla, atravs de estruturas de
Generalizao e Especializao(Gen-Esp).
Gen-Esp representa a abstrao que captura a relao geral/especfico entre entidades ou
problemas no mundo real, e pode ser pensada como uma estrutura um ou um tipo de, sob o

ponto de vista de Especializao. a implementao da herana. Por exemplo, em um sistema

hospitalar, PacienteInterno e PacienteExterno so vistos como especializaes da Classe Paciente,
conforme mostra a Figura 4.8. Relacionamentos do tipo Gen-Esp implicam que objetos
subordinados(PacienteInterno e PacienteExterno) sejam membros de Classe(Paciente). O tringulo
slido indica que as subclasses particionam a superclasse, ou seja, s existem PacienteInterno e
PacienteExterno. Caso contrrio, o tringulo vazio, como no caso das classes Rel01 e Rel02,
derivadas de Relatrio, indicando que existem outras subclasses de Relatrio, alm de Rel01 e Rel02.
Paciente
Nome
Nascimento
Altura
Peso

PacienteInterno
Quarto
Leito
Medicao

PacienteExterno
ltimaVisita
PrximaVisita
Mdico

Figura 4.8 - Exemplos de Estrutura Generalizao-Especializao

A estrutura Gen-Esp representada com uma classe de generalizao no topo e classe(s) de

especializao abaixo, refletindo um mapeamento entre classes e no entre objetos. conveniente
nomear as especializaes com o nome da classe pai seguido de um qualificador que descreve a
natureza da especializao. Por exemplo, no caso da classe Sensor, a especializao SensorCrtico
preferida em relao a apenas Crtico, conforme se pode ver na Figura 4.9.
Sensor
Modelo
SequnciaInicial
Converso
Intervalo
Limiar
Estado
Valor

SensorCrtico
Tolerncia

Figura 4.9 - Sistema Sensor - Generalizao-Especializao

Todo-Parte representa o particionamento que captura a relao agregao/parte de entre

entidades e problemas no mundo real, e pode ser pensada como uma estrutura tem um, sob o ponto
de vista do Todo. Por exemplo, no sistema hospitalar, Corao, Rim e Vista so vistos como partes do
Objeto Paciente, conforme mostra a Figura 4.10. Relacionamentos do tipo Todo-Parte implicam que
objetos subordinados(Corao, Rim e Vista) sejam partes de outro Objeto (Paciente). Todo-Parte
normalmente usado para descrever um problema ou sua soluo em termos de sua partes. Por
exemplo, para descrever o problema de DefesaDeUmaNao contra msseis balsticos fica mais fcil
descrev-lo em termos de sua partes: Deteco, Comunicao, Reconhecimento, Lanamento e
Defensiva. Decompondo o problema em subproblemas facilita a anlise.

Paciente
Nome
Nascimento
Altura
Peso

1,2

Corao

Rim

0,2

Natural/Artificial
Implantado
Tipo

Natural/Artificial
Implantado
Bpm

Vista
Natural/Artificial
Viso
Tipo

Figura 4.10 - Exemplo de Estrutura Todo-Parte

A notao usada para representar a estrutura Todo-Parte permite expressar os diferentes

relacionamentos entre os objetos. Em particular, na Figura 4.10, Paciente tem obrigatoriamente 1
Corao e 1 ou 2 Rins e at 2 Vistas. Uma estrutura Todo-Parte pode indicar: Montagem de partes,
Contedos de Recipiente e Membros de Conjunto. Na Figura 4.11 tem-se que 1 Avio uma
montagem com Motor como Parte. Note que posso ter vrios motores em um avio, cujas montagens
so realmente fsicas.
Avio

1,4

Motor

Figura 4.11 - Estrutura Todo-Parte - Montagem-Partes

Na Figura 4.12, tem-se que o Avio considerado como um recipiente no qual Passageiro est
dentro dele.
Avio

Passageiro

Figura 4.12 - Estrutura Todo-Parte - Recipiente-Contedos

Na Figura 4.13, tem-se que 1 Organizao um conjunto de Escriturrio. Um PlanoDeGuerra

pode ser visto como um conjunto ordenado de Ao, conforme mostra a Figura 4.14.
Organizao

Escriturrio

Figura 4.13 - Estrutura Todo-Parte - Conjunto-Membros

PlanoGuerra
1,m
Ao

Especificao Adicional
Ao
um conjunto ordenado

Figura 4.14 - Estrutura Todo-Parte - Conjunto-Membros (com uma restrio)

4.3.1.2 Modelo de Interface

Um sistema modelado como uma entidade ativa que interage com outras entidades chamadas
agentes. Os agentes modelam usurios humanos ou outros sistemas de hardware e software. O
ambiente constitudo de agentes com os quais o sistema se comunica. A comunicao entre o sistema
e o ambiente se d atravs de eventos. Um evento pode ser disparado por agentes externos ou pelo
tempo. Associado a cada evento externo tem-se um estmulo que vai disparar uma atividade do

sistema. A interface de um sistema o conjunto de operaes associadas aos eventos que podem ser
disparados.
O Modelo de Interface composto de:
Modelo de Operao: Especifica o comportamento das operaes do sistema
declarativamente, definindo o seu efeito em termos de mudana de estado e dos eventos que
so disparados.
Modelo de Ciclo de Vida: O modelo de ciclo de vida o segundo componente do modelo de
interface. Um esquema de modelo objeto descreve o comportamento de uma operao
individual do sistema, enquanto o modelo de ciclo de vida descreve o comportamento, de uma
perspectiva mais ampla de como o sistema se comunica com o seu ambiente, da criao at a
sua morte.
No processo da anlise, devem ser desenvolvidos todos os modelos da fase da anlise do
sistema:

Modelo Objeto para o domnio do problema;

Determinar a interface do sistema com o ambiente;
Identificar agentes, operaes do sistema, e eventos;
Produzir o Modelo Objeto do Sistema adicionando o limite ao Modelo Objeto;
Desenvolver o Modelo de Interface;
Produzir um Modelo de Ciclo de Vida do sistema;
Produzir um Modelo de Operao com as operaes do sistema;
Checar os modelos de anlise e
Produzir o Dicionrio de Dados com as informaes modeladas.

O desenvolvimento do Modelo Objeto retorna ao analista as classes e os relacionamentos entre

estas. O modelo mostra os relacionamentos de generalizao, agregao, atributos, cardinalidade,
invariantes e relacionamentos derivados.
Durante a anlise, um sistema se comunica com outras entidades ativas atravs de eventos. Um
evento de entrada e seu efeito associado so uma operao do sistema. A interface de um sistema o
conjunto de operaes do sistema, as quais o sistema pode responder, e os eventos que o sistema pode
disparar. Uma operao do sistema sempre invocada por um agente ou pelo tempo, que dispara o
evento associado.
No desenvolvimento do Modelo de Interface, produz-se o Modelo de Operao, e o Modelo de
Ciclo de Vida. O Modelo de Ciclo de Vida composto de dois processos: generalizao dos cenrios
para formar expresses nomeadas ciclos de vida (um cenrio uma seqncia de eventos fluindo
entre agentes e o sistema para algum propsito), e combinao de expresses de ciclo de vida para
formar o Modelo Ciclo de Vida.
O Modelo Operao define a semntica de cada operao do sistema na interface do sistema.
Cada esquema possui entre outras, as clusulas de pr-condio e ps-condio: ASSUMES e
RESULTS respectivamente, como um contrato entre a operao e seus usurios. O contrato garante
que a operao retorna um estado final, no qual a clusula RESULTS verdadeira desde que seja
satisfeita a clusula ASSUMES. Os modelos de anlise podem ser checados quanto a:

Completitude com relao aos requisitos;

Consistncia simples (reas que no se sobrepem nos modelos de anlise) e
Consistncia semntica (se as implicaes do modelo so consistentes).

Uma operao um comportamento especfico que um objeto deve exibir. Na determinao de

operaes deve ser considerada:
a identificao dos estados de objeto, com base na alterao com o tempo;
a identificao das conexes de mensagens que fazem a comunicao entre objetos e
a especificao das operaes.
Um estado de objeto a identificao dos valores dos atributos que refletem uma alterao no
comportamento do objeto, ou seja, o estado de um objeto representado pelos valores de seus
atributos.
Por exemplo, no sistema de monitorao de sensores e de sensores crticos, dos atributos
Modelo, SeqnciaInicial, Converso, Intervalo, Endereo, Limiar, Estado e Valor, apenas Estado

reflete uma alterao necessria no comportamento, cujos valores so: desligado, ligado e
disponvel.
As operaes podem ser divididas em: operaes relacionadas com a existncia dos
objetos(criao/inicializao, acesso, conexo, liberao, etc) e operaes mais complexas que
executam clculos e monitoram um sistema ou um dispositivo externo.
As operaes relacionadas com a existncia dos objetos, podem ser omitidas na AOO, e
consideradas implicitamente definidas. As quatro operaes algoritmicamente simples so: Criar(cria e
inicia um novo objeto em uma classe), Conectar(conecta e desconecta um objeto a outro),
Acessar(obtm ou estabelece os valores de Atributos de um objeto) e Liberar(libera, ou seja elimina e
desconecta, um objeto). Nada impede contudo que estas operaes sejam explicitadas no modelo de
operaes.
Para que objetos executem servios para outros objetos, mensagens precisam ser enviadas.
Estas conexes de mensagens implicam na definio de operaes que disparam a mensagem e
operaes que tratam a mensagem na classe receptora. Para identificar todas as Conexes de
Mensagens, percorra cada objeto e verifique se:

ele precisa dos servios de outros objetos e

quais outros objetos precisam de seus servios.

Em sistemas de tempo real, onde as restries de tempo so rigorosas e precisam ser atendidas,
pode ser usada, semelhana da idia de autmato, uma notao adicional no diagrama que representa
as mensagens, que consiste em numerar a seqncia de execuo das mensagens. Esta especificao,
vital nos sistemas de tempo real, chamada de linha crtica de execuo.

4.3.2

Projeto
Fusion apresenta quatro tcnicas para suportar a modelagem na fase de projeto:

Grafos de Interao entre Objetos;

Grafos de Visibilidade;
Descries de Classes e
Grafos de Herana.

4.3.2.1 Grafos de Interao entre Objetos

A proposta desta fase construir as estruturas de mensagem do objeto que realizam a definio
abstrata do comportamento. Um grafo de interao construdo para cada operao do sistema. Este
define as seqncias de mensagens que ocorrem entre uma coleo de objetos para realizar uma
operao particular. O desenvolvimento do Grafo de Interao entre Objetos composto de quatro
passos:
(1) Identificar os objetos relevantes envolvidos na computao.
(2) Estabelecer o papel de cada objeto:
Identificar o controlador (ou seja, o objeto responsvel pela operao do sistema).
Identificar os colaboradores envolvidos.
(3) Definir as mensagens entre os objetos.
(4) Gravar como os objetos identificados interagem em um grafo de interao entre objetos.
Os grafos de interao entre objetos so desenvolvidos para cada esquema no modelo de
operao. Duas verificaes bsicas necessitam ser executadas: consistncia com a especificao do
sistema (todas as classes do sistema esto representadas em pelo menos um grafo de interao entre
objetos), e verificao de efeito funcional (verifica se cada clusula RESULT do esquema satisfeita).
4.3.2.2 Grafos de Visibilidade
Objetos devem ter acesso a outros objetos para permitir a comunicao requerida pelos grafos
de interao entre objetos. A identificao e o endereamento que os objetos devem ter para comunicar
uns com os outros so chamados de referncia. A proposta de um grafo de visibilidade definir a
estrutura de referncia entre as classes do sistema, identificando, para cada classe, os objetos que as
instncias da classe necessitam referenciar, e os tipos apropriados de referncias a estes objetos.
Um grafo de visibilidade um diagrama cujos componentes so caixas clientes, caixas
servidores e setas de visibilidade, que conectam ambas as caixas. Vrias decises devem ser tomadas
considerando a estrutura de referncia entre as classes. So elas:

Tempo de vida da referncia (permanente/dinmica);

Visibilidade do servidor (exclusiva/compartilhada);
Ligao do servidor (ligado/no ligado) e
Mutabilidade da referncia (fixa/varivel).

Os grafos de visibilidade so desenvolvidos a partir dos grafos de interao entre objetos da

seguinte maneira:
Todos os grafos de interao entre objetos so inspecionados. Para cada seta indo de um objeto a
outro, a classe do objeto emissor requer uma referncia de visibilidade ao objeto receptor.
Anotar a seta com as informaes sobre a visibilidade apropriadas.
Para cada classe, construir um grafo de visibilidade considerando-a uma caixa cliente e
conectando-a atravs de setas de visibilidade s caixas servidores.
Seguem-se alguns grafos de visibilidade, como exemplos.
class pedido
constant For1:
fornecedor

pedido
constant
Lista_det1:
detalhe
pedido

constant Lista_fat:
fatura

pedido tem:
Lista_det1: permanente, compartilhado, ligado e fixo.
For1 : permanente, compartilhado, no ligado e fixo.
Lista_fat : permanente, compartilhado, no ligado e fixo
class sensor
Sensor

constant
Dispositivo_Alarme1:
Dispositivo_Alarme

sensor tem:
Dispositivo_Alarme1: permanente, compartilhado, no ligado e fixo
constant P1:
pedido

class fatura

fatura

constant Cli1:
cliente

constant Lista_det:
detalhepedido

fatura tem:
P1 : permanente, compartilhado, no ligado e fixo
Cli1 : permanente, compartilhado, no ligado e fixo
Lista_det : permanente, compartilhado, no ligado e fixo
4.3.2.3 Verificao dos modelos
As referncias nos grafos de visibilidade so ligaes estruturais necessrias para implementar
a troca de mensagens definida durante a fase do grafo de interao entre objetos. Trs importantes
checagens devem ento ser feitas:
Consistncia com os modelos da anlise;
Consistncia mtua (checar se servidores exclusivos no so referenciados por mais de um
cliente) e
Completitude (todas as trocas de mensagens definidas nos grafos de interao entre objetos
devem estar representadas nos grafos de visibilidade).
4.3.2.4 Descrio das Classes
Depois de desenvolver os grafos de visibilidade para todas as classes, o prximo passo
coletar informaes do modelo objeto do sistema, dos grafos de interao entre objetos, e dos grafos
de visibilidade para construir as descries das classes.
Uma descrio de classe uma descrio de um conjunto de objetos que tm os mesmos
atributos e servios, alguns dos quais, herdados de superclasses. A descrio consiste das informaes:
nome da classes, superclasse(s) imediata(s), atributos da classe, e os servios providos pela classe.
Descries de classes so as especificaes das quais surge o cdigo. Elas especificam o estado
interno e o externo da classe. Existem quatro tipos de informaes coletadas na descrio das classes:
servios e parmetros, atributos dos dados, atributos dos objetos, e dependncias de herana.
Em resumo, a notao da descrio de classes usada para coletar as informaes das classes a
partir de outras notaes. A interface do servio derivada dos grafos de interao entre objetos, os
atributos dos objetos so derivados dos grafos de visibilidade, e os atributos dos dados so definidos
atravs do modelo objeto do sistema e do dicionrio de dados. Os relacionamentos de herana so
derivados dos grafos de herana. As descries de classes proporcionam o ponto de partida para a
implementao da classe.
O exemplo mostra a descrio de uma classe. Palavras como class, atribute, endclass e outras
no utilizadas no exemplo como exclusive, bound e constant so consideradas reservadas.
class Pessoa
attribute nome: string;
attribute endereco: string;
attribute idade: int;
method cadastrar(n:string, e: string, i:int);
method exibir( );
endclass

As informaes nas descries de classes so derivadas, e no geradas. Devem ento estar

consistentes com as descries produzidas anteriormente na anlise e no projeto. Entretanto, algumas
checagens devem ser feitas:
Atributos dos dados (checar se todos os atributos de dados do modelo objeto do sistema so
descritos);
Atributos dos objetos (checar se todas as referncias de visibilidade so descritas);
Servios e Parmetros (se todos os servios dos grafos de interao entre objetos so descritos);
Herana (todas as superclasses herdadas devem estar descritas).
4.3.2.5 Grafos de Herana
Uma importante considerao em projeto orientado a objetos a herana, um mecanismo pelo
qual uma classe pode ser definida como uma especializao de outra qualquer.
A notao usada para a herana a mesma usada para o modelo objeto (da anlise). Uma caixa
representa uma classe, estando o nome da classe na parte superior da caixa, e os atributos abaixo do
nome. O tringulo preenchido indica que as subclasses so disjuntas e que sua unio forma a
superclasse. Implica tambm que a superclasse abstrata, ou seja, no possui nenhuma instncia.
Os grafos de herana devem ser checados com os seguintes modelos: modelo objeto do
sistema, grafos de interao entre objetos, grafos de visibilidade, descries de classes.
4.3.3

Implementao

O estgio final do mtodo Fusion, o mapeamento do projeto numa implementao eficiente.

A implementao deve estar correta, de acordo com as descries da fase de projeto e deve satisfazer
os requisitos da fase de anlise.
A base para a fase de implementao a descrio das classes, os grafos de interao entre
objetos, o dicionrio de dados, e o ciclo de vida do sistema gerado na fase de anlise. O processo de
implementao compe-se de trs partes: codificao, performance e reviso.
Na maioria das aplicaes, as descries das classes podem ser implementadas diretamente. As
semnticas para classe so extradas da documentao que acompanha os grafos de interao entre
objetos, e os grafos de visibilidade.
Na codificao, as classes podem ser implementadas atravs de suas descries da fase de
projeto, em dois passos:
Especificar a representao e a interface das classes.
Implementar o corpo dos servios. A maioria das informaes necessrias para a
implementao do corpo dos servios esto contidas nos grafos de interao entre objetos e
no dicionrio de dados (funes, predicados, tipos e verificao das proposies).
Para os ciclos de vida sem intercalao:
Traduzir as expresses regulares do ciclo de vida em uma mquina de estados finita no
determinstica.
Implementar a mquina de estados.
Para os ciclos de vida com intercalao:
Implementar as sub-expresses livres de intercalao.
Ligar as mquinas de estados resultantes.

A performance deve ser considerada ao longo dos processos de anlise, projeto e

implementao e a otimizao de cdigo, raramente executada, ineficiente. Tcnicas de verificao
devem ser aplicadas ao software aps sua codificao. A reviso composta de inspeo, que uma
das tcnicas para a deteco de falhas no software, e dos testes, que complementam a inspeo do
cdigo orientado a objeto.
4.3.4

Dicionrio de Dados

O dicionrio de dados serve para relacionar nomes utilizados nos diferentes modelos, cujos
significados no puderam ser colocados nos diagramas. Existem vrios modelos de dicionrio de
dados que so hoje normalmente utilizados, e que podem ser adaptados para o Fusion. Uma sugesto
utilizar uma tabela, mostrada a seguir, onde tem-se o nome, seguido de uma palavra chave que indica
o tipo e um texto que descreve o nome.
Nome
<classe>.<item>

Tipo

Descrio

atributo | predicado | funo | servio

assertiva | classe | relacionamento | evento
operao | agente | definio de tipo

Comentrios
descrevendo, com
mais detalhes, o
Nome

No caso de atributos ou servios, um nome pode incluir o nome da classe ou do relacionamento

a que pertence. Outras colunas podem ser adicionadas, caso se julgue necessrio, como por exemplo
para registrar os argumentos dos servios.
Nome
AtenderPedido

Tipo
operao

Argumentos
nome_cliente
id_cliente
end_cliente
cod_produto
qtd_pedida

Cliente

Descrio
Quando o cliente faz um pedido,
este cadastrado, caso ainda
no exista, e seu pedido
atendido, caso existam os
produtos solicitados

classe

nenhum

Um cliente que faz pedido

agente

nenhum

Entidade externa que faz um

pedido

DetalhePedido

relacionamento

nenhum

Relaciona um pedido com os

seus produtos e respectivas
quantidades

Cliente.Endereo

atributo

nenhum

endereo do cliente

SituaoPedido

tipo

nenhum

enumerao. Pode ser:

pendente | requisitado | atendido

Na prxima seo apresenta-se o metodo UML.

4.4

Mtodo UML [UML 97, UML 98, Blaha and Premerlani 98]

A UML (Unified Modeling Language) uma linguagem para especificao, construo,

visualizao e documentao de sistemas de software.
A UML uma evoluo das linguagens para especificao dos conceitos de Booch, OMT
(Object Modeling Technique-Rumbaugh), OOSE (Object-Oriented Software Engineering - Jacobson) e
tambm de outros mtodos de especificao de requisitos de software orientados a objetos ou no. A
notao UML uma unio de sintaxe grfica de vrios mtodos, com certo nmero de smbolos
removidos (porque so confusos, suprfluos ou pouco usados) e com outros smbolos adicionados. O
resultado uma nica, comum e ampla linguagem de modelagem utilizvel por desenvolvedores de
software orientado a objetos.
Os autores da UML preocuparam-se com a modelagem de sistemas concorrentes e
distribudos. Os esforos so concentrados em um metamodelo comum, que unifica as semnticas, e
em uma notao comum que fornece uma interpretao humana destas semnticas. O uso do termo
metamodelo se justifica considerando que se trata de uma linguagem para especificar modelos,
contendo os elementos bsicos de informao de um sistema. Este metamodelo fornece uma
declarao nica e comum da sintaxe e semntica dos elementos da UML.
A UML formada por tcnicas de diversos mtodos, que so mostrados na Figura 4.15. O
mtodo OOSE uma abordagem orientada a use case que fornece excelente suporte para especificao
de requisitos. As tcnicas OOSE utilizadas pela UML foram o Diagrama de Use Cases e Packages. O
OMT, especialmente expressivo para a anlise de sistemas de informao, contribuiu com o Diagrama
de Classes e Diagrama de Estados. Do BOOCH, a UML utilizou a idia de Diagrama de Estados,
Diagrama de Classes, Diagrama de Objetos (que originou o Diagrama de Colaborao), Diagrama de
Processos (que originou o Diagrama de Deployment) e o Diagrama de Mdulos (que originou o
Diagrama de Componentes). O mtodo Fusion tambm colaborou com o Grafo de Interao de
Objetos. O Statecharts de Harel, contribuiu para a criao do Diagrama de Atividades.
Grafo de Interao
de Objetos

FUSION
(Coleman)

Statecharts
(Harel)

Diagrama de Statecharts
(Diagrama de Atividades)

BOOCH
Diagrama de Estados
Diagrama de Classes
Diagrama de Objetos
(Diagrama de Colaborao)
Diagrama
de Processos

(Diagrama de Deployment)
Diagrama de Mdulos
(Diagrama de Componentes)

UML

OMT

(Rumbaugh)
Diagrama de Classes
Diagrama de Estados

OOSE
Diagrama Use Cases
(Jacobson) Subsistema (Package)

Figura 4.15 - Formao da Metodologia UML

O Processo de Desenvolvimento de Software com a UML est estruturado, segundo o tempo,

em quatro fases:

Concepo quando se especifica da viso do sistema.

Elaborao quando se faz o planejamento das atividades necessrias e dos recursos

requeridos e a especificao do sistema e design da sua arquitetura.

Construo desenvolvimento do produto como uma srie de interaes incrementais.

Transio fornecimento do produto para o usurio (fabricao, distribuio e

treinamento).

Em cada uma destas fases, diferentes artefatos so produzidos usando diferentes atividades e
tcnicas. Em cada uma das fases do processo, tem-se as fases normais do ciclo de vida do software:

Anlise dos Requisitos descrio do que o sistema deve fazer.

Design como o sistema ser construdo na fase de implementao.

Implementao a produo do cdigo que resultar em um sistema executvel.

Teste a verificao de todo o sistema.

A Figura 4.16 mostra cada atividade da dimenso/componente do processo, aplicada a cada

fase da dimenso/tempo:
dimenso/tempo
dimenso/componente

Concepo

Elaborao

Construo

Transio

Anlise de
Requisitos

Design

Nvel de
arquitetura
Nvel de
classe
Implementao
Teste
Figura 4.16 Processo de Desenvolvimento de Software com UML

Baseado nestas fases do Processo de Desenvolvimento de Software, a ferramenta ROSE, que

implementa a UML, especifica o sistema segundo quatro vises:

Use Case View descreve o sistema como um conjunto de transaes do ponto de vista dos
atores externos. Esta viso inicialmente criada na fase de concepo do ciclo de vida e
direciona o resto do processo.

Logical View - contm a coleo de packages, classes e relacionamentos. Esta viso

inicialmente criada na fase de elaborao e refinada na fase de construo.

Component View contm mdulos e subsistemas. Esta viso inicialmente criada na fase
de elaborao e refinada na fase de construo.

Deployment View contm a parte fsica do sistema e a conexo entre estas partes. Esta
viso criada na fase de elaborao do processo.

Segue-se uma lista das principais tcnicas disponveis no ROSE para suportar este Processo de
Desenvolvimento de Software, segundo as quatro vises:

Use Case View

Diagrama de Use Case
Descrio do Use Case
Diagrama de Seqncia
Diagrama de Colaborao
Diagrama de Estados

Logical View
Diagrama de Classes

Compenent View
Diagrama de Componentes

Deployment View
Diagrama Deployment

A UML faz tambm uso de packages.

Um package um mecanismo que pode agrupar classes, mdulos ou outros packages. Cada
package deve ter um nome nico no modelo, como mostra a Figura 4.17.

nome-do-package

Distribuidora

Figura 4.17 - Packages

Os packages podem ser classificados como lgicos e de componentes.

Packages Lgicos servem para particionar o modelo lgico de um sistema. So clusters de
classes relacionadas entre si e altamente acopladas. Pode-se usar packages para agrupar classes ou os
prprios packages.
Embora muitas linguagens de programao orientadas a objetos ainda no suportam o uso
de packages, estes so importantes porque permitem expressar e agrupar elementos lgicos do sistema.
Pode-se capturar um projeto de alto nvel do sistema, criando um diagrama de classes que
consiste somente de packages.
possvel representar um relacionamento de dependncia de um package para o outro. Este
tipo de relacionamento significa que as classes contidas no package cliente podem herdar, conter
instncias, usar e por outro lado depender de classes que so exportadas do package servidor.
Caso um package contenha classes comuns que so usadas pela maioria dos packages no
modelo, pode-se colocar a palavra global rotulada no cone que representa o package, ao invs de
colocar cones representando essas classes comuns em vrios diagramas de alto nvel, conforme
mostra a Figura 4.18. No exemplo, o package Venda agrupa as classes Cliente, Pedido, ItemPedido e
Produto e o package Compra agrupa classes Fornecedor, Requisio, ItemRequisio e Produto. O
package Interface contm as classes de interface comuns aos packages Venda e Compra. A linha de
dependncia entre os packages Venda e Compra mostra que o package Compra utiliza a classe Produto
que foi definida no package Venda.

Interface
global

Venda

Compra

Figura 4.18 - Exemplo de Package Lgico

Packages de Componentes permitem particionar o modelo fsico do sistema. Cada package

de componente pode conter componentes e outros packages de componentes. Cada componente do
sistema deve estar em um nico package de componentes ou em um package de componentes de nvel
mais alto.

Um package de componentes pode ter dependncias com outros packages de componentes,

como mostra a Figura 4.19, onde o package c:\projeto\aplicao importa o package c:\projeto\class.
Um package de componentes tambm pode ter dependncia com componentes, como mostra a Figura
4.20. Pode existir tambm a dependncia de um componente com outro componente.
Cada package de componentes deve ter um nome nico no modelo. Tipicamente, o nome do
package de componente o nome do diretrio do arquivo do sistema.

c:\projeto\class

c:\projeto\aplicao

Figura 4.19 - Exemplo de Package de Componentes com Package de Componentes

Menu.java
c:\sistema\financeiro

Figura 4.20 - Exemplo de Package de Componentes com Componente

A seguir so apresentadas as principais tcnicas da UML, iniciando pelo Diagrama de Use

Cases.
4.4.1

Use Case View

Diagrama de Use Cases

Um Diagrama de Use Cases [Jacobson ,Ericsson and Jacobson 95] representa uma coleo
de use cases e atores e tipicamente usado para especificar ou caracterizar a funcionalidade e o
comportamento de um sistema de aplicao, interagindo com um ou mais atores externos.
Os agentes externos e qualquer outro sistema que possa interagir com o sistema que est
sendo modelado so chamados de atores. Uma vez que os atores representam os agentes externos do
sistema, eles ajudam a delimit-lo e fornecem uma viso clara do que ser realizado. Os use cases so
desenvolvidos de acordo com os eventos que ocorrem entre os agentes externos e o sistema.
Diagramas de use cases contm elementos representando os atores, relacionamentos de
associao, relacionamentos de generalizao, packages e use cases. Pode ser criado um diagrama de
use cases de alto nvel para visualizar o contexto e limites do sistema. possvel tambm criar um ou
mais diagramas de use cases para descrever um sistema por partes. Os use cases podem incluir outros
diagramas de use cases, seqncia, colaborao, estados e de classes, como parte de seu
comportamento. Um diagrama de use cases pode ser usado durante as fases de anlise e projeto, como
mostra a tabela 4.1.

Durante
Anlise

Usar o Diagrama de Use Cases para

Capturar os requisitos do sistema e compreender o que o sistema faz.

Projeto

Especificar o comportamento do sistema que ser implementado, e/ou

especificar as semnticas do mecanismo do use case.
Tabela 4.1 - Uso do Diagrama de Use Case

Um ator modela um tipo de objeto que interage diretamente com o sistema. Cada ator deve
ter um nome, como AtorCliente, mostrado na Figura 4.21.

<<Actor>>
AtorCliente

Figura 4.21 - Exemplo de Ator

<<Actor>> representa um stereotype. Um stereotype tem a capacidade de criar um novo tipo

de elemento de modelagem. Um stereotype representa a metaclassificao de um elemento, isto ,
mostra uma classe dentro do metamodelo da UML (isto , um tipo de elemento de modelagem).
Embora existam stereotypes j pr-definidos, novos tipos podem ser adicionados. Um stereotype
representado pela seguinte notao: <<NomeDoStereotype>>. A Figura 4.22 mostra exemplos de
stereotypes.
<<uses>>

<<Actor>>
AtorFuncionario

ReceberProduto

VerificarPedido

<<extends>>

CadastrarProduto

Figura 4.22 - Exemplos de stereotypes: <<actor>>, <<uses>> e <<extends>>

Um use case uma seqncia de transaes realizadas pelo sistema em resposta ao disparo
de um evento. Um use case, quando realizado completamente, fornece um valor avalivel para o ator.
Um use case modela a dilogo entre um ator e o sistema.
Um use case mostrado como uma elipse contendo um nome, que pode ser colocado acima,
dentro ou abaixo do smbolo, como CadastrarCliente, mostrado na Figura 4.23.

CadastrarCliente

Figura 4.23 - Exemplo de Use Case

Nomes de use cases freqentemente iniciam com um verbo. Por exemplo, em um sistema
bancrio: IdentificarConta e VerificarSaldo.
A Tabela 4.2 descreve os relacionamentos permitidos nos use cases:
Relacionamento
Associao

De um Use Case para

Um ou mais atores.

Generalizao

Um use case.

Tabela 4.2 - Tipos de Relacionamentos dos Use Cases

Uma associao representa uma conexo semntica entre um use case e atores. Associaes
so unidirecionais e so mais comuns que generalizaes. O nome da associao usado para
identificar o propsito do relacionamento.
A Figura 4.24 apresenta um diagrama de use case com relacionamento de associao: o ator
AtorCliente relaciona-se atravs da associao DadosCliente, com o use case CadastrarCliente. O use
case CadastrarCliente relaciona-se com AtorCliente atravs da associao RespostaCadastro.

DadosCliente

AtorCliente

CadastrarCliente
RespostaCadastro

Figura 4.24 - Exemplo de Relacionamento de Associao

Um relacionamento de generalizao entre use cases mostra que um use case pode
compartilhar o comportamento definido em um ou mais use cases.

A Figura 4.25 apresenta um diagrama de use case com relacionamento de generalizao: o

ator AtorCliente conecta-se atravs do relacionamento de associao DadosEmprstimo, com o use
case RealizarEmprstimo. O use case RealizarEmprstimo conecta-se com o use case
IdentificarCliente, atravs do relacionamento de generalizao, o qual faz a identificao do cliente e
conecta-se tambm com o ator AtorCliente atravs do relacionamento RespostaEmprstimo

DadosEmprstimo
RealizarEmprstimo

AtorCliente

CPFCliente
RespostaEmprstimo

IdentificarCliente

Figura 4.25- Exemplo de Relacionamento de Generalizao

Um relacionamento de generalizao tambm suporta os stereotypes uses e extends. O tipo

de generalizao <<uses>> usado para descrever o comportamento comum entre dois ou mais use
cases. um dos mecanismos utilizados para identificar comportamentos reutilizveis pelas regras de
negcio. Por exemplo, a Figura 4.26 mostra uma generalizao <<uses>> do use case ValidarCliente.
A generalizao <<uses>> indica que uma instncia de RealizarPedido utiliza todos os
comportamentos descritos por ValidarCliente. O comportamento descrito por ValidarCliente
obrigatrio para o use case RealizarPedido.

DadosPedido
RealizarPedido

AtorCliente
RespostaPedido

<<uses>
>CPFCliente

ValidarCliente
Figura 4.26 - Exemplo de Generalizao <<uses>>

O tipo de generalizao <<extends>> usado para expressar comportamento opcional por

um use case. Por exemplo, a Figura 4.27 mostra uma generalizao <<extends>> do use case
RealizarPedido para o use case CadastrarCliente.
A generalizao <<extends>> indica que o use case RealizarPedido pode utilizar o use case
CadastrarCliente. O comportamento descrito por CadastrarCliente opcional para o use case
RealizarPedido.

DadosPedido
RealizarPedido

AtorCliente

<<extends>
>CPFCliente

RespostaPedido

CadastrarCliente
Figura 4.27 - Exemplo de Generalizao <<extends>>

Diagrama de Seqncia
Diagramas de Seqncia mostram uma interao organizada em uma seqncia de tempo
entre os objetos participantes de uma operao e as trocas de mensagens entre eles. Esses diagramas
so bastante utilizados para especificar sistemas de tempo real e sistemas complexos. Um diagrama de
seqncia possui duas dimenses: vertical que representa o tempo e horizontal que representa
diferentes objetos (se for necessrio as dimenses podem ser invertidas).
A Figura 4.28 mostra um exemplo de um diagrama de seqncia para uma operao de
chamada telefnica.

Pedro : Chamador

a
{b - a < 1 seg.}
b
c
{d - c < 1 seg.}
d

EmpresaTelefnica:
Central

Mario : Chamado

1: retira fone do gancho

2: tom de discar
3: discagem do nmero chamado
4: tom de controle

5: toque de chamada
6: retira fone do gancho

7: conversao

8: conversao

9: repe fone no gancho

10: tom de ocupado
11: repe fone no gancho

Figura 4.28 - Diagrama de Seqncia - Operao de Chamada Telefnica

O primeiro passo para o estabelecimento de uma conexo o reconhecimento do objeto

Pedro do tipo Chamador. Isso ocorre com o envio de um sinal EmpresaTelefnica do tipo Central,

indicando que Pedro retirou o fone do gancho (1). O nmero desse telefone ento anexado lista de
telefones ocupados e emitido um tom de discar para o Pedro (2).
Uma vez recebido o nmero do telefone desejado (3), a EmpresaTelefnica verifica se este
pertence lista de telefones ocupados. Em caso positivo, um tom de ocupado enviado a Pedro e a
fase de desconexo iniciada. Caso contrrio, um tom de controle de chamada enviado a Pedro (4), e
a campainha do objeto Mrio, do tipo Chamado, acionada (5), e o nmero de Mrio includo na
lista de telefones ocupados.
A ao do chamado de atender ao telefone (6), determina o fim da fase de conexo e o incio
da fase de conversao (7,8). Caso ele no atenda em um determinado intervalo de tempo, a
campainha do Chamado desativada, um tom de ocupado enviado ao Chamador, o nmero do
Chamado retirado da lista de telefones ocupados e a fase de desconexo iniciada.
O fim da fase de conversao ocorre quando Pedro repe o fone no gancho (9), e emitido
um tom de ocupado para o outro objeto Chamado (10). O fim da fase de desconexo ocorre somente
quando o Mrio tambm coloca o telefone no gancho (11).
Vrios rtulos (como marca de sincronizao e descries de aes durante uma ativao)
podem ser representados na margem, prximo s mensagens ou ativaes do diagrama de seqncia,
como mostra a Figura 4.28.
Uma ativao mostra o perodo de tempo que um objeto est realizando uma mensagem
para ele mesmo ou para outro objeto. representada como um retngulo fino alinhado com a linha do
tempo. As mensagens a serem realizadas podem ser rotuladas com um texto prximo ao smbolo de
ativao ou na margem esquerda, conforme mostra a Figura 4.28.
Uma mensagem uma comunicao entre objetos e transporta informaes que resultaro
em uma ao. A recepo de uma mensagem considerada um evento. Uma mensagem mostrada
como uma seta slida horizontal da linha de vida de um objeto para outro. No caso de uma mensagem
de um objeto para ele mesmo, a seta comea e termina no prprio objeto. A seta rotulada com o
nome de uma mensagem (operao ou sinal) e os valores de argumentos. Uma seta tambm rotulada
com uma seqncia de nmeros para mostrar a ordem de seqncia das mensagens, que sero
realizadas entre os objetos, conforme mostra a Figura 4.28.
A UML contm notaes, que podem ser adicionadas a qualquer mensagem para indicar um
comportamento concorrente. Esses smbolos foram trazidos do trabalho de Booch [Booch 91], e so
mostrados na Figura 4.29.

Simple
Synchronous
Balking
Timeout
Asynchronous

Figura 4.29 - Notaes de Mensagens

Mensagem simple indica uma linha simples de controle, isto , um objeto envia uma
mensagem para um objeto passivo.
Mensagem synchronous, indica que o processo ocorre somente quando o cliente envia uma
mensagem para o servidor e este recebe a mensagem. O cliente envia a mensagem e fica esperando at
que a mensagem seja recebida pelo servidor.
Na sincronizao balking, o cliente pode enviar uma mensagem somente se o servidor est
pronto para receb-la, caso contrrio, o cliente abandona a mensagem.
Na sincronizao timeout, o cliente envia uma mensagem e fica esperando at que a
mensagem seja recebida pelo servidor, durante um tempo determinado. O cliente abandona a
mensagem se o servidor no puder trat-la dentro do tempo.
Comunicao asynchronous ocorre quando o cliente envia uma mensagem para o servidor
processar e continua sua execuo normal sem esperar o reconhecimento da mensagem pelo servidor,
ficando de prontido para receber a resposta.
Diagrama de Colaborao
Um Diagrama de Colaborao representa a interao entre instncias de classes simples e de
classes utility, objetos e entidades atravs de uma seqncia de mensagens que implementam uma
operao ou uma transao. Esse diagrama mostra objetos , seus links e mensagens. Cada diagrama de
colaborao supre uma viso das interaes ou relacionamentos que ocorrem entre objetos e/ou
agentes externos no modelo corrente.
O diagrama de colaborao no mostra a dimenso do tempo, por isso as seqncias de
mensagens e linhas concorrentes devem ser determinadas usando a seqncia de nmeros.
Os diagramas de colaborao contm smbolos que representam objetos. As notaes
grficas para um objeto so mostradas na Figura 4.30 e podem ser: um retngulo com o nome do
objeto, ou um retngulo com o nome do objeto e sua classe, usando a seguinte sintaxe:
NomeObjeto : NomeClasse

Pedro

Pedro : Pessoa

Figura 4.30 - Exemplo de Objetos do Diagrama de Colaborao

Se existem mltiplos objetos que so instncias da mesma classe, possvel modificar o

cone do objeto selecionando Multiple Instances na especificao do objeto. Quando esta opo
selecionada o smbolo trocado por um objeto de trs camadas, como mostra a Figura 4.31.

Pedro : Pessoa

Figura 4.31 - Exemplo de Mltiplas Instncias de Objetos

Objetos interagem com outros objetos atravs de seus links. Um link uma associao entre
objetos e/ou agentes externos.
Um link pode existir entre dois objetos (inclusive classe utility) somente se existir um
relacionamento entre essas classes. A existncia de um relacionamento entre duas classes simboliza um
meio de comunicao entre instncias de uma classe: um objeto pode enviar mensagens para outro.
Um link representado por uma linha reta entre objetos ou entre objetos e agentes externos.
Tambm pode ser representado um link para o prprio objeto. A Figura 4.32 mostra um exemplo de
link entre objetos.

Pea

Carro
1: InserirPea (integer)

Figura 4.32 - Exemplo de Link entre Objetos

Uma mensagem transporta a chamada de uma operao do objeto origem linkado com o
objeto destino. Cada mensagem pode estar associada a um nmero, que indica a ordem em que a
mensagem ser executada. Como no diagrama de seqncia, as mensagens podem ser classificadas
como: Simple, Synchronous, Timeout, Balking ou Asynchronous. Links suportam mltiplas mensagens
em ambas direes.
O diagrama com links e mensagens denominado diagrama de colaborao. O diagrama de
colaborao correspondente ao diagrama de seqncia da Operao de Chamada Telefnica,
mostrado na Figura 4.33.

1: retira fone do gancho

3: discagem do nmero chamado
9: repe fone no gancho

EmpresaTelefnica : Central

7: conversao
4: tom de controle
2: tom de discar
Pedro : Chamador

5: toque de chamada
8: conversao
10: tom de ocupado

11: repe fone no gancho

6: retira fone do gancho

Mario :
Chamado

Figura 4.33 - Exemplo de Diagrama de Colaborao - Operao de Chamada Telefnica

Diagrama de Estados
O Diagrama de Estados usado para mostrar os estados dos objetos de uma classe. Os
eventos do diagrama de estados causam uma transio de um estado para outro e as aes resultam na
mudana de estado. Cada diagrama de estados est associado a uma classe ou a um diagrama de
estados de um nvel mais alto.
Diagrama de estados um grafo direcionado de estados conectados por transies que
mostra um estado inicial, um ou mais estados, um ou mais estados finais e as transies de estados
entre eles. Cada classe que possui eventos significativos, pode conter um diagrama de estados para
descrever este comportamento.
Um estado inicial um estado especial que mostra o incio do diagrama e conectado ao
primeiro estado normal com uma transio, rotulada ou no. Em cada diagrama de estado h somente
um estado inicial. A notao grfica de um estado inicial mostrada na Figura 4.34.

Figura 4.34- Estado Inicial

Um estado uma condio durante a vida de um objeto que satisfaz alguma ao, realiza
alguma ao ou espera por algum evento. Um objeto permanece em um estado por um tempo finito. A
notao grfica e um exemplo de estado mostrada na Figura 4.35.
nome do estado

Liquidado

Figura 4.35 - Estado

Um evento possui a seguinte sintaxe: nome-evento (lista-argumentos) [condio]

Uma transio pode ser rotulada no somente com o evento, mas tambm, opcionalmente,
com uma ao, separado do evento por uma barra como se segue: evento/ao. Se ocorrer a transio e
quando ocorrer, a ao especificada executada instantaneamente.
Algumas aes simplesmente geram um evento, elas podem tambm causar outros efeitos
como: modificar valores de condies e itens de dados, iniciar ou parar atividades, entre outros.
NomeDoEvento(ListaDeArgumentos) [Condio] / Ao
A ao pode ser interna, sendo executada em resposta a eventos recebidos pelo estado. Uma
ao interna est associada com um estado e consome tempo para ser executada, mas pode ser
interrompida por outro evento.

Os tipos de aes internas so as seguintes:

entry: a ao tem incio quando entra no estado e pra a execuo por conta prpria;
exit: a ao tem incio quando sai do estado e pra a execuo por conta prpria;
do: uma ao onde um processo realizado enquanto o objeto est no estado, podendo ser
interrompida por eventos externos. iniciada quando o estado ativado, podendo terminar
por conta prpria ou quando o estado for desativado e
on an activity: uma ao onde um evento interno ir disparar uma ao que pode conter
argumentos e condies (opcionais). Esta ao fornece um controle para os eventos internos
sem o disparo de aes entry e exit.

A Figura 4.36 mostra exemplos de aes entry e do. O exemplo refere-se a um relgio
despertador. A partir do momento em que o evento IniciaAcerto foi recebido, as aes
HabBotoConfirma, HabBotoCancela e DesBotoAcerto so executadas. O evento
IniciaControle ou Cancelamento esperado e ento ou ocorre a confirmao da hora
escolhida ou seu cancelamento. Se ocorrer a confirmao da hora escolhida, as aes
DesBotoCancela, DesBotoConfirma e HabBotoAcerto associadas ao evento
IniciaControle so realizadas; por outro lado, as aes DesBotoCancela,
DesBotoConfirma e HabBotoAcerto associadas ao evento Cancelamento so executadas.
Aguardando com Alarme Desligado

IniciaAcerto / HabBotoConfirma
^HabBotoCancela
DesBotoAcerto

Acertando Hora do Alarme

entry: AcertarHoraAlarme

Cancelamento / DesBotoCancela
^DesBotoConfirma
HabBotoAcerto
Cancelamento / DesBotoCancela
^DesBotoConfirma
HabBotoAcerto

IniciaControle / DesBotoCancela
^DesBotoConfirma
HabBotoAcerto

Controlando Alarme Ligado

do: MonitorarAlarmeLigado

Figura 4.36 - Exemplos de eventos/aes entry e do

Estado final representa o termino de um sistema. A Figura 4.37 mostra a notao grfica de
um estado final. Podem existir mais de um estado final por diagrama.

Figura 4.37 - Estado Final

Uma transio de estado um relacionamento entre dois estados, indicando que um objeto
no primeiro estado entrar no segundo estado e realizar aes especificadas quando um evento
ocorrer e se suas condies (caso existam) forem satisfeitas. Uma transio disparada quando o
evento ocorrer. Se um evento no habilitar nenhuma transio, ignorado. Se ele habilitar mais do que
uma transio, ser disparada aquela que atender a condio.
A Figura 4.38 mostra a notao de transio de estado e a Figura 4.39 mostra um exemplo.
Evento( Argumentos )[ Condio ] / Ao

Estado

Evento( Argumentos )[ Condio ] / Ao

EstadoInicial

Evento( Argumentos )[ Condio ] / Ao

Transio de Estado

Transio de Estado

EstadoFinal

Figura 4.38 - Transio de Estado

ObterPrximoItem
[ TodosItensNoVerificados ]

Verificando

[ TodosItensVerificados
&& TodosItensDisponveis ]

Despachando
do: IniciarLiberao

do: VerificarItem

ItemRecebido
[ TodosItensVerificados [ ItensForaEstoque ]
&&ItensForaEstoque ]

Liberado
ItemRecebido
[ TodosItensDisponveis ]

Aguardando

Liberado

Figura 4.39 -Exemplo de Transies de Estados

Somente um evento permitido por transio. Uma mesma transio pode ser colocada em
mais de um estado se pelo menos uma delas estiver rotulada com uma condio, como mostrado no
estado Aguardando, onde h duas transies com o nome ItemRecebido, mas as condies so
diferentes.
Quando uma transio possui um evento no rotulado, significa que a transio ocorre
quando uma ao interna associada a um estado completada. Isto ocorre, por exemplo, com o estado
Verificando. Trs transies com condies saem do estado Verificando. Uma condio retorna
verdadeiro ou falso; a transio que contm uma condio ocorre somente se a condio for
verdadeira.

Somente uma transio de um estado pode ser disparada por vez e as condies so
exclusivas para um evento. Na Figura 4.39 existem trs condies:
(1) Para todos os itens que no foram verificados obtido o prximo item e retorna para o
estado Verificando.
(2) Se todos os itens foram verificados e todos esto no estoque, v para o estado
Despachando.
(3) Se todos os itens foram verificados mas nem todos esto no estoque, v para o estado
Aguardando.
Na Figura 4.40 pode-se observar mais um exemplo do Diagrama de Estados, que trata da
abertura de cursos e seus estudantes de uma certa escola, onde cada curso s pode ter 10 estudantes.
Caso o curso no complete todas as vagas ele pode ser cancelado. Se o curso for fechado o professor
tambm pode cancelar o curso.
Inicializao

AdicionaEstudante / Set Cont = 0 ^EstDoCurso. Cri ar

AdicionarEstudante[ Cont < 10 ]

Aberto
entry: RegistrarEstudante
exit: ^EstDoCurso.AdicionarEstudante(Estudante)

[ Cont = 10 ]
Canc ela

Fechado

Canc elado
Canc ela

do: FinalizarCurso

^EstDoCurso.Remover

Figura 4.40 - Exemplo de Diagrama de Estado

Uma transio de estado pode ter uma ao e/ou uma condio associada, ou pode ainda
disparar um evento. Uma ao o comportamento que ocorre quando a transio de estado ocorre. Um
evento uma mensagem que enviada para outro objeto no sistema. Uma condio deve ser
verdadeira para que ocorra a transio de estado.
A transio de estado do estado Inicializao para o estado Aberto tem o evento
AdicionaEstudante juntamente com a ao Set Cont = 0, que um contador que vai at 10 e o evento
Criar que uma mensagem disparada para o objeto da classe EstDoCurso.
No estado Aberto so executados a ao RegistrarEstudante e o evento AdicionarEstudante de
EstDoCurso passando o Estudante como argumento. H tambm uma transio de estado que tem o
evento AdicionarEstudante com a condio Cont < 10, que ocorre at Cont atingir o nmero mximo
de 10 estudantes.
Do estado Aberto pode-se passar para um dos dois estados: o estado Cancelado atravs da
transio de estado que tem o evento Cancela ou o estado Fechado atravs da transio de estado que
tem a condio Cont = 10.
No estado Cancelado h uma transio de estado que envia a mensagem Remover para o
objeto da classe EstDoCurso, que remove todos os estudantes de um curso, passando para o estado
final.
No estado Fechado a ao FinalizarCurso executada e pode passar para um dos dois estados:
o estado Cancelado atravs da transio de estado que tem o evento Cancela, caso o professor deseje
cancelar o curso aps de ter preenchido todas as vagas, ou o estado final que finaliza o curso.
4.4.2

Logical View

Diagrama de Classes
Um Diagrama de Classes uma representao grfica para descries genricas do sistema.
Pode conter packages, tipos, relacionamentos e instncias de classes. A Tabela 4.3 mostra como pode
ser usado o diagrama de classes nas fases de anlise e projeto de um sistema.

Durante
Anlise

Usar o Diagrama de Classes para

Mostrar regras e responsabilidades comuns de entidades que fornecem
o comportamento do sistema.

Projeto

Capturar a estrutura das classes que formam a arquitetura do sistema.

Tabela 4.3 - Uso do Diagrama de Classes

Uma classe captura a estrutura e o comportamento comum de um conjunto de objetos.

uma abstrao de elementos do mundo real. Quando esses elementos existem no mundo real, so
instncias de classe e so referidos como objetos. Para cada classe que tem comportamento temporal
significativo pode ser criado um diagrama de estados para descrever este comportamento.

A Tabela 4.4 apresenta as caractersticas de uma classe.

Tipo
Abstrata

Descrio
Define a classe como uma classe base, sem instncias.

Atributos

Informaes do objeto da classe.

Cardinalidade

Nmero de instncias da classe.

Concorrncia

Semntica na presena de mltiplas threads de controle.

Operaes

Servios fornecidos pela classe.

Visibilidade

Especifica como a classe vista fora do package em que

definida.
Tabela 4.4 - Caractersticas de uma Classe

A Figura 4.41 mostra a notao usada para representar uma classe e os diferentes tipos de
visibilidade.
Os tipos de visibilidade dos atributos e servios de uma classe, como a de Produto,
exemplificada na Figura 4.42, so:
public: os elementos so acessveis por todas as classes, como o atributo Observao e o
servio Cadastrar;
private: os elementos so acessveis por subclasses, classes friends ou pela prpria classe
como o atributo Cdigo e o servio ValidarQuantidade;
protected: os elementos so acessveis somente pela prpria classe ou pelas classes
friends como o atributo Saldo e o servio CalcularDesconto; e
implemented: os elementos so acessveis somente pela prpria classe como o atributo
Preo.
Classe
Atributo
Servio( )

Figura 4.41- Notao de Classe, Atributo, Servio e Visibilidade

Produto
Cdigo : integer
Saldo : float
Preo : float
Observao : memo
Cadastrar (cod : integer = default, saldo : float = default) : Produto
ValidarQuantidade (quant : float = default) : boolean
CalcularDesconto (vr : float = default) : valor
ImprimirDetalhe (cod : integer = default, quant : float = default)
BaixarEstoque (cod : integer = default, quant : float = default) : return

Figura 4.42 - Exemplo de Classe, Atributo, Servio e Visibilidade

Uma classe parametrizada um template para instanciar classes que seguem este padro
formatado. Uma classe parametrizada declara parmetros formais. Pode-se usar outras classes, tipos e
expresses constantes como parmetros. Essas classes no podem ser usadas como parmetros. A
Figura 4.43 mostra a notao e exemplo de uma classe parametrizada. No caso, T e K so
metavariveis que podem ser qualquer classe ou tipo.
Parmetro
NomeDaClasse
T,K

Array

Figura 4.43 - Classe Parametrizada

Uma classe utility contm um conjunto de operaes de uso comum. Uma utility modelada
como um tipo de uma classe, e a sua notao apresentada na Figura 4.44. A classe utility usada
para:
Denotar um ou mais subprogramas livres (uma funo que no membro de um objeto).
Nomear uma classe que somente fornece membros e/ou funes estticas que so usadas
independentemente das instncias da classe.
Uma classe utility tem a mesma notao de uma classe simples, com adio de uma sombra
que ilustra o tipo utility, como mostra a Figura 4.44.

String
Tamanho
Concatenar( )

Figura 4.44 - Exemplo de Classe Utility

Uma classe utility parametrizada contm um conjunto de operaes que no esto

associadas com outras classes. Estas operaes so subprogramas livres definidos atravs de
parmetros formais. Uma classe utility parametrizada usada como um template para criar classe
utility instanciada, e sua notao e exemplo so mostrados na Figura 4.45.
Parmetro

Lista

NomeDaClasse

Tipo

Remover()
Inserir()
Figura 4.45 - Classe Utility Parametrizada

Uma classe utility instanciada criada substituindo-se os parmetros formais de uma classe
utility parametrizada por valores atuais. A notao de uma classe utility instanciada mostrada na
Figura 4.46, onde a classe Lista instanciada como uma lista de inteiros.

Lista
Remover()
Inserir()
Figura 4.46 - Exemplo de Classe Utility Instanciada

Uma metaclasse uma classe cujas instncias so classes. Em geral, uma classe est
relacionada com apenas uma metaclasse. Metaclasses fornecem operaes para criar objetos da classe
e definem atributos e servios que so compartilhados por todos os objetos da classe criada.
Smalltalk e CLOS suportam o uso de metaclasses. A linguagem C++ suporta metaclasse
atravs de servios e atributos static da classe. A notao de uma metaclasse mostrada na Figura
4.47.
nome-da-metaclasse

Figura 4.47 - Notao de Metaclasse

Relacionamentos
Os relacionamentos, entre classes, que podem existir na UML so: Generalizao,
Dependncia, Associao e Agregao.

Um relacionamento de generalizao entre classes mostra que a subclasse compartilha a

estrutura ou comportamento definido em uma ou mais superclasses. Representa o relacionamento
-um entre as classes. A notao de um relacionamento de generalizao mostrada na Figura 4.48.

superclasse

subclasse

Pessoa
Cdigo : integer
Nome : string

PessoaFsica
CPF : string

PessoaJurdica
CGC : string

Figura 4.48 - Relacionamento de Generalizao

A Tabela 4.5 mostra os possveis relacionamentos de generalizao entre classes.

De uma
Classe

Para
Uma classe ou uma classe instanciada.

Classe utility

Uma classe utility ou uma classe utility instanciada.

Classe parametrizada

Uma classe, uma classe parametrizada ou uma classe instanciada.

Classe utility parametrizada

Uma classe utility, uma classe utility parametrizada, uma classe

utility ou uma classe utility instanciada.

Tabela 4.5 - Relacionamentos de Generalizao entre as Classes

A cardinalidade, que especifica o nmero de instncias de uma classe em relao a outra em

um relacionamento, mostrada atravs do nmero mnimo e mximo. A Tabela 4.6 resume as
possveis variaes de uma cardinalidade, onde <literal> qualquer inteiro maior ou igual a 1:

Notao
0..1

Significado
Zero ou uma instncia.

Somente uma instncia.

0..*

Zero ou mais instncias.

Default, nmero mnimo e mximo de instncias

so ilimitados.

1..*

Uma ou mais instncias.

<literal>..*

Nmero exato ou mais instncias.

<literal>

O nmero exato de instncias.

<literal>..<literal>

Faixa de instncias especificadas.

<literal>..<literal>,<literal>

Nmero exato de instncias ou o nmero de

instncias estar na faixa especificada.

<literal>..<literal>,
<literal>.. <literal>

Nmero de instncias estar em uma das faixas

especificadas.
Tabela 4.6 - Notaes de Cardinalidade

Um relacionamento de dependncia entre duas classes mostra que a classe cliente depende
da classe servidora, para sua existncia. Por exemplo, a Figura 4.49 mostra que a classe Dependente
depende da classe Funcionrio para existir.

Funcionario

Dependente
1

0..n

Figura 4.49 - Exemplo de Dependncia entre Classes

Um relacionamento de dependncia tambm pode ser desenhado entre packages. Por

exemplo, a Figura 4.50 mostra que o package ContasReceber depende do package Vendas.

Vendas

ContasReceber

Figura 4.50 - Exemplo de Dependncia entre Packages

Um relacionamento de associao representa uma conexo semntica entre duas classes e

o relacionamento mais utilizado. bidirecional e representado por uma linha ligando as classes. A
Figura 4.51 mostra um relacionamento de associao entre as classes Fornecedor e Pedido.

Fornecedor

Pedido
1

0..*

Figura 4.51 - Exemplo de Relacionamento de Associao

Um relacionamento de associao tambm pode ser representado entre as classes mostradas

na Tabela 4.7.

Relacionamento:
Associao

De uma classe para

uma outra classe, uma classe parametrizada, uma classe instanciada,
uma metaclasse, uma classe utility, uma classe utility parametrizada ou
uma classe utility instanciada.
Tabela 4.7 - Relacionamento de Associao entre as Classes.

Caso o relacionamento interesse apenas em uma direo este pode ser indicado conforme a
Figura 4.52.
Pedido

Cliente
1

0..*

Figura 4.52 Exemplo de Relacionamento de Associao Unidirecional

Um relacionamento de agregao uma forma especial de associao, que usada para

mostrar que um tipo de objeto composto de outro objeto. Um relacionamento de agregao tambm
chamado de todo-parte.
A agregao pode ser implementada na UML como agregao por referncia ou por valor. O
default por referncia, e significa que o objeto todo mantm um ponteiro ou uma referncia para
suas partes. O losango vazio usado para indicar a implementao por referncia.
A agregao por valor indica que o tempo de vida das partes so dependentes do tempo de
vida do todo. Quando a agregao por valor, o objeto todo declara uma instncia atual do objeto
parte dentro do corpo do prprio objeto todo. O objeto todo composto fisicamente pelo objeto
parte. O contedo por valor indicado por um losango cheio no lado agregado do relacionamento. A
Figura 4.53 mostra, no lado esquerdo, uma agregao por referncia onde a instncia da classe curso
mantm um ponteiro de referncia para uma instncia da classe Aluno. No lado direito mostra uma
agregao por valor onde a instncia da classe Pedido cria instncias da classe DetalhePedido.

Curso

Pedido

Aluno

DetalhePedido

Agregao por referncia

Agregao por valor

Figura 4.53 - Exemplos de Tipos de Agregao

Um relacionamento de agregao pode ser representado entre as classes mostradas na

Tabela 4.8.

Classe

De uma:

Para:
Outra classe ou uma classe instanciada.

Classe utility

Uma classe ou uma classe instanciada.

Classe instanciada

Uma classe ou uma classe instanciada.

Classe utility instanciada

Uma classe ou uma classe instanciada.

Classe parametrizada

Uma classe ou uma classe instanciada.

Classe utility parametrizada

Uma classe ou uma classe instanciada.

Tabela 4.8 - Relacionamento de Agregao entre as Classes

4.4.3

Component View

Diagrama de Componentes
Um Diagrama de Componentes mostra as dependncias entre componentes de software,
incluindo componentes de cdigo fonte, componentes de cdigo binrio e componentes executveis.
Um mdulo de software representado como um tipo de componente.
Componentes so derivados do mtodo Booch [Booch 91], compostos pelos seguintes
elementos: packages, programa principal, subprogramas e tarefas. Cada diagrama de componentes
fornece uma viso fsica de um modelo do software.

Um diagrama de componentes contm elementos que representam:

 Packages de componentes
Componentes ou Mdulos
Packages
Programa principal
Subprogramas
Tarefas
Dependncias

Componentes so conectados com outros componentes atravs de relacionamentos de

dependncias. Isto indica que um componente usa os servios de outro componente.
Em um diagrama de componentes um package consiste em um mdulo de especificao e
um mdulo de implementao, sendo que este ltimo freqentemente referido como um corpo do
mdulo. Por default, uma classe declarada no package.
Cada package contm o nome do arquivo. Na linguagem Java pode-se usar uma
especificao de package para representar as interfaces (so um tipo de classe abstrata, que no
possuem variveis de instncia e os servios so declarados sem corpo). A Figura 4.54 mostra a
notao e exemplo de uma especificao de package.
package

Runnable.java

Figura 4.54 - Especificao de Package

Em Java, pode-se usar um corpo de package para representar o arquivo .java, onde so
implementadas as classes. A Figura 4.55 mostra a notao e exemplo de um corpo de package.

CorpoDoPackage

Cliente.java

Figura 4.55 - Corpo de Package

Um programa principal, em um diagrama de componente, consiste em um mdulo que

representa um arquivo que contm a raiz (origem) de um programa. Por exemplo, em Java este mdulo

pode representar um arquivo com extenso .java que contm a funo main ou Init. H somente um
programa principal por mdulo de programa.
O nome de um programa principal um nome de arquivo. A Figura 4.56 mostra a notao
grfica e o exemplo de um programa principal.
main

Distribuidora.java

Figura 4.56 - Programa Principal

Mdulo de subprogramas podem conter um ou mais subprogramas. Cada subprograma

deve ter um nome de arquivo. A Figura 4.57 mostra a notao da especificao e do corpo de um
subprograma.
Especificao

Corpo

Figura 4.57 - Especificao e Corpo de Subprograma

Mdulos de tarefas representam packages com linhas de controle independentes. Cada

tarefa deve possuir um nome. O nome da tarefa um nome de arquivo. A Figura 4.58 mostra a notao
da especificao e do corpo de uma tarefa. Em Java usa-se Mdulos de tarefas para representar classes
Threads, que geram objetos executados em paralelo.
Especificao

Corpo

Figura 4.58 - Especificao e Corpo de Tarefa

Um relacionamento de dependncia indica que um mdulo em um diagrama de

componente usa servios ou facilidades de outra. Dependncias em um diagrama de componente
representam dependncias de compilao. Uma dependncia pode ser rotulada com uma descrio
significativa no contexto, mas o nome no obrigatrio. A Figura 4.59 mostra um exemplo de
relacionamento de dependncia, onde ContasPagar usa servios do mdulo Financeiro.

Financeiro

ContasPagar

Figura 4.59 - Exemplo de Relacionamento de Dependncia

A Tabela 4.9 mostra os tipos de processos, usados pelos processadores e sua respectivas
descries:
Tipo:
Preemptivo (default)
No preemptivo

Descrio:
Processos de alta prioridade que esto prontos para executar, podendo
suspender os processos de baixa prioridade que esto sendo
executados.
Um novo processo aguarda que o processo corrente termine.

Cclico

O controle passa de um processo para outro, aps determinado tempo.

Executivo

Um algoritmo controla o processo de escalonamento.

Manual

Processos so escalonados pelo usurio fora do sistema.

Tabela 4.9 - Tipos de Processos Escalonados pelo Processador

4.4.4

Deployment View

Diagrama Deployment
Um Diagrama Deployment mostra as conexes fsicas entre os processadores, dispositivos e a
alocao dos processos aos processadores.
Este diagrama mostra a organizao do hardware e a ligao do software com os dispositivos
fsicos. O tipo do dispositivo de hardware dado pelo seu stereotype, tais como, processador, vdeo,
dispositivo, memria, disco e outros.
Um processador um componente do hardware capaz de executar programas. A Figura 4.60
mostra um exemplo de processador.

PC
Pentium

Figura 4.60 - Exemplo de Processador

Um dispositivo um componente do hardware sem efeito computacional. Cada dispositivo

deve ter um nome, podendo ser genrico, como modem ou terminal. A Figura 4.61 mostra um
exemplo de dispositivo.

Impressora
HP 600

Figura 4.61 - Exemplo de Dispositivo

Uma conexo representa interligao entre processadores ou dispositivos de hardware. A

ligao de hardware pode ser direta ou indireta, sendo bidirecional. Um exemplo de conexo
mostrada na Figura 4.62.

PC
Pentium

Cabo

Impressora
HP 600

Figura 4.62 - Exemplo de Conexo

A Figura 4.63 mostra um PC conectado no servidor atravs do Protocolo de Comunicao

TCP/IP.

Servidor da Unidade Pedido

Banco de
Dados

Domnio da
Aplicao
Configurao da Unidade Pedido
Unidade
Pedido
Servidor da
Aplicao

Configurar
Usurios
Configurao

Aplicao

TCP/IP

Objeto
Contido

Interface
Hardware

Conexo

PC Windows
Unidade Pedido
AtenderCliente

Componente

Unidade Pedido
Interface do
Usurio

Figura 4.63 Diagrama Deployment