MODELAGEM DE SISTEMAS

autor

JOO PAULO BROGNONI CASATI

1 edio
SESES
rio de janeiro 2016

Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza
Autor do original joo paulo casati
Projeto editorial roberto paes
Coordenao de produo gladis linhares
Coordenao de produo EaD karen fernanda bortoloti
Projeto grfico paulo vitor bastos
Diagramao bfs media
Reviso lingustica amanda carla duarte aguiar
Imagem de capa cc0 public domain / faq

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogao na Publicao (cip)

C336m Casati, Joo Paulo

Modelagem de sistemas / Joo Paulo Casati

Rio de Janeiro : SESES, 2016.

96 p. : il.

isbn: 978-85-5548-211-3

1. Modelagem de software. 2. Orientao a objetos. 3. Sistemas de informao.

4. UML. I. SESES. II. Estcio.

cdd 004

Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063

Sumrio
Prefcio 5
1. Introduo Engenharia de Software e Modelagem 7
1.1 O que a engenharia de software? 9
1.2 O processo de software 10
1.2.1 O modelo cascata
11
1.2.2 O modelo evolucionrio
12
1.2.3 O modelo incremental
14
1.3 Princpios de modelagem de sistemas
16
1.3.1 A importncia da modelagem
16
1.4 A modelagem orientada a objetos
18
1.5 A linguagem UML
18

2. Ferramentas Case e Casos de Uso

23

2.1 Vises de sistema

2.2 Ferramentas CASE
2.2.1 A ferramenta Astah

25
26
27

2.3 Casos de uso

2.3.1 Diagrama de casos de uso
2.3.2 Exemplos de casos de uso

29
31
37

3. Diagrama de Classes

41

3.1 Classes e objetos

3.2Relacionamentos
3.2.1Herana
3.2.2Associao
3.2.3Agregao

43
48
48
53
55

3.2.4Composio
3.2.5Dependncia
3.3 Estudo de caso

56
57
58

4. Descrio de Casos de Uso e Outros Diagramas da

UML 63
4.1 Descrio de casos de uso
4.2 Diagramas de Interao
4.2.1 Diagrama de sequncia
4.2.2 Diagrama de comunicao
4.2.3 Diagrama de estados
4.2.4 Diagrama de atividade

65
68
69
72
73
75

5. Diagrama de Classe de Projeto e Diagrama de

Implementao 79
5.1 Diagrama de classe de projeto
5.2 Diagramas de implementao
5.2.1 Diagrama de componentes
5.2.2 Diagramas de implantao

81
88
88
90

Prefcio
Prezados(as) alunos(as),
Sejam bem-vindos disciplina de modelagem de sistemas. Esta disciplina
oferece uma viso sistmica muito importante para futuros desenvolvedores e
analistas de sistemas, pois o seu entendimento facilita toda uma vida de tomada de decises quanto abordagem a ser utilizada na resoluo de problemas
com o uso de software.
Neste captulo so abordados os conceitos iniciais de engenharia de software e seus ciclos de desenvolvimento. Posteriormente, conceitos de modelagem
so apresentados, indicando a importncia da criao de modelos em desenvolvimento de software.
Logo aps, entra-se no mundo orientado a objetos. Um tema empolgante
e de grande importncia para o desenvolvimento de software contemporneo.
O estudo do paradigma orientado a objetos (tambm conhecido pela sigla OO)
traz grandes benefcios ao raciocnio lgico visando criao de programas para
soluo de problemas.
Desejo bons estudos e muita ateno nos conceitos de orientao a objetos
que vo sendo explicados e revistos ao longo de todo o livro.
Bons estudos!

1
Introduo
Engenharia
de Software e
Modelagem

Este captulo visa introduzir os conceitos de engenharia de software, apresentando um panorama geral de processos de desenvolvimento e o ciclo de vida do
desenvolvimento de software. Uma introduo aos conceitos de modelagem de
sistemas tambm apresentada, assim como a explicao do que orientao
a objetos e os conceitos iniciais da linguagem de modelagem chamada UML.
A orientao a objetos um paradigma muito utilizado em desenvolvimento de
software e traz tambm um nvel de raciocnio e abstrao interessantes para
alunos de graduao.

OBJETIVOS
Ao final deste captulo, o aluno conhecer:
Conceitos bsicos de engenharia de software;
Os principais ciclos de vida do processo de desenvolvimento de software;
Conceitos bsicos de modelagem de sistemas;
Uma viso crtica do porqu se utilizar de modelos em desenvolvimento de software;
Conceitos iniciais de orientao a objetos;
Conceitos iniciais sobre a UML.

captulo 1

1.1 O que a engenharia de software?

O software est presente, nos dias de hoje, em quase tudo que existe. Como definido por Pressman (2011), os campos de aplicao de software so:
Software de sistema: programas de computador com a finalidade de
atender s necessidades de outros programas;
Software de aplicao: programas que possuem o objetivo de solucionar
necessidades especficas de negcio (atividade fim);
Software cientfico ou de engenharia: algoritmos que visam processamento numrico pesado (custoso computacionalmente), utilizado em diversas
reas de pesquisa e simulaes;
Software embutido: programas que residem em um produto ou sistema,
utilizados para controlar as atividades do equipamento, como o software que
controla o funcionamento de um ar condicionado digital.
Software para linha de produtos: tambm conhecido como softwares generalistas ou de prateleira, so programas que podem suprir as necessidades
de diversos clientes diferentes, por exemplo, softwares de criao de planilhas
eletrnicas, editores de textos, entre outros;
Aplicaes para a web: tambm conhecidas como WebApps, so programas que so executados em um servidor conectado rede e que pode ser
acessado e utilizado por diferentes usurios, desde que possuam acesso;
Software de inteligncia artificial: algoritmos no numricos utilizados
para a resoluo de problemas complexos, com aplicaes em redes neurais
artificiais, robtica, jogos, entre outras.
Com a crescente dependncia de tecnologias de software por parte de diversas organizaes (empresas, rgos governamentais, entre outras), o processo
de fabricao (desenvolvimento) precisou ser amadurecido, padronizado e melhorado por meio de tcnicas de engenharia de software.
A necessidade de se desenvolver softwares com maior qualidade deu-se pela
procura em se reduzir custos com manuteno e erros, visto que quanto mais
cedo os erros so descobertos no processo de desenvolvimento, menos trabalhosa sua correo.
A engenharia de software consiste de um conjunto de procedimentos e tcnicas aplicadas ao processo de software com o objetivo de obter maior qualidade nos processos de software. importante frisar que este termo no abrange
apenas a etapa de desenvolvimento do software, mas tambm sua manuteno.
captulo 1

CONCEITO
O autor Sommerville (2007) define o termo engenharia de software como:
Uma disciplina de engenharia relacionada com todos os aspectos da produo de software,
desde os estgios iniciais de especificao do sistema at sua manuteno, depois que este
entrar em operao.

1.2 O processo de software

O processo de software o conjunto de atividades que so executadas com o
objetivo de criar um produto, neste caso um software. De uma forma genrica,
Pressman (2011) define cinco atividades para o processo de software de acordo
com a disciplina de engenharia de software, so elas:
Comunicao: visa a compreenso dos objetivos dos interessados, definindo os requisitos para o desenvolvimento do produto;
Planejamento: tem como objetivo a criao de um mapa (tambm conhecido como plano de projeto de software) que contm a descrio das tarefas, possveis
riscos, cronograma de execuo, os recursos demandados e o resultado esperado;
Modelagem: criao de modelos (esboos) para representar o produto
que deseja desenvolver, fazendo assim com que as necessidades do produto final possam ser melhor entendidas e o projeto de software possa ser melhor definido antes do incio do desenvolvimento, reduzindo assim os custos
de mudanas (quanto mais cedo se identificar uma mudana, menor o custo
de reparo);
Construo: desenvolvimento do cdigo do software, assim como o teste
dos mesmos;
Emprego: entrega do produto ao cliente, seja este totalmente finalizado
ou parcial.
As disciplinas da engenharia de software, abrangendo agora todo o processo, tambm podem ser definidas por:
Gerncia de projeto: planejamento das funes a serem executadas;
Levantamento de requisitos: levantar conhecimento sobre o negcio do
cliente, identificando suas necessidades;
Anlise: detalhamento dos requisitos e definio lgica dos procedimentos;

10

captulo 1

 Projeto: definio fsica dos procedimentos, inclusive abrangendo os recursos tecnolgicos a serem utilizados;
Implementao: construo do sistema (cdigos);
Teste: validao do sistema, verificando se os requisitos levantados foram
devidamente desenvolvidos, se atendem s expectativas do cliente e se o sistema funciona sem erros;
Implantao: disponibilizar o produto ao cliente (usurio), inclusive treinamentos e carga de dados;
Manuteno: efetuar os ajustes necessrios em caso de erros no programa, no levantamento de requisitos ou at mesmo no desenvolvimento de novas
funcionalidades, conforme necessidade do cliente; e a
Qualidade: efetuar medidas para a verificao e busca pela excelncia
do sistema.
A abordagem utilizada neste livro considera as cinco atividades definidas por Pressman (2011) por se tratar de uma abordagem mais simples e de
fcil entendimento, porm, pode-se facilmente adaptar outras definies
mais detalhadas.
A padronizao no processo de software pode melhorar o desempenho e reduzir custos do desenvolvimento de software. Com isto, alguns modelos so comumente adotados com o objetivo de otimizar o processo de desenvolvimento
de software (SOMMERVILLE, 2007).
Os modelos de processos, tambm conhecidos como ciclos de vida de software mais utilizados so:
O modelo cascata;
O modelo evolucionrio; e
O modelo incremental.
Todos estes modelos podem acomodar as cinco atividades definidas anteriormente (comunicao, planejamento, modelagem, construo e emprego) e
so mais detalhadamente descritas a seguir.

1.2.1 O modelo cascata

Tambm conhecido como ciclo de vida clssico, o modelo cascata possui suas
atividades sendo executadas de forma linear. A figura 1.1 apresenta a sequncia
de execuo das atividades utilizando o modelo cascata.
captulo 1

11

 Levantamento
de requisitos

Comunicao

Planejamento

Estimativas e
cronograma
Modelagem

Anlise e
projeto
Construo

Codificao e
testes
Emprego

Entrega e
suporte

Figura 1.1 Modelo cascata, adaptado de Pressman (2011).

Como possvel observar na figura 1.1, as etapas so executadas de forma

linear, sendo assim, a etapa seguinte dependente da anterior. Em outras palavras, uma etapa s pode ser iniciada quando a etapa anterior finalizada.
Um problema recorrente do uso deste modelo : se uma das etapas no for devidamente cumprida, a etapa seguinte tende a ser desenvolvida erroneamente.

EXEMPLO
Ao utilizar-se do modelo cascata, quando um requisito entendido de forma errada na etapa
de comunicao e este erro persiste at a etapa de emprego, preciso retornar etapa de
comunicao e passar novamente por todas as outras etapas at que o emprego seja executado novamente. Sendo assim, ao utilizar-se deste modelo, imprescindvel que cada etapa
seja exaustivamente checada antes de se passar para a prxima, a fim de se evitar custos
adicionais e atrasos no prazo de entrega.

1.2.2 O modelo evolucionrio

Com a necessidade de alteraes e mudanas nas definies do projeto conforme o desenvolvimento avana, o modelo evolucionrio visa amenizar o problema de interdependncia das atividades do modelo cascata (PRESSMAN, 2011).

12

captulo 1

Esta abordagem tem como objetivo desenvolver o software de maneira que

este evolua com o passar do tempo. Com isto, a atividade de emprego (entrega
do produto ao cliente) pode ser feita sem o software estar finalizado, mas com
uma parcela deste para que as entregas sejam mais rpidas e o cliente possa
acompanhar o desenvolvimento do produto.
Este modelo pode ser dividido em duas diferentes abordagens:
Prototipao; e
Modelo espiral.
A prototipao utilizada como ferramenta para a descoberta de requisitos
de forma interativa. As atividades so executadas seguindo a ordem exibida na
figura 1.2 e, quando da atividade de emprego do software, pondera-se a necessidade de reavaliao dos requisitos, fazendo assim com que todas as etapas
sejam revistas e ao final, um novo prottipo seja entregue ao cliente.
A vantagem desta abordagem para a clssica (cascata) que o produto final
no totalmente desenvolvido para a avaliao dos requisitos pelo cliente e sim
um prottipo, de mais fcil manuteno e alterao e mais rapidamente entregue.
Prottipo

Emprego

Comunicao

Construo

Planejamento

Modelagem

Figura 1.2 Modelo de prototipao, adaptado de Pressman (2011).

Para a utilizao da abordagem de prototipao, necessrio que todos os

envolvidos estejam de acordo que os prottipos a serem desenvolvidos so mecanismos para a definio mais precisa dos requisitos, evitando assim problemas de entendimento (PRESSMAN, 2011).
captulo 1

13

A segunda abordagem do modelo evolucionrio o modelo espiral, proposto por Boehm (1988) em seu artigo cientfico.
Uma das diferenas do modelo espiral para os outros modelos que seu
ciclo no necessariamente termina quando o software entregue, ele pode ser
adaptado para perdurar por toda a vida do software (PRESSMAN, 2011).
Segundo Sommerville (2007), o modelo espiral orientado a riscos. Ele
busca definir os riscos a cada iterao (volta no ciclo) e minimiz-los durante
o processo.
Analisando a figura 1.3 pode-se ter uma ideia melhor de como o modelo espiral funciona.
Custo Acumulado
Progresso atravs das fases

Determina
Objetivo
Alternativas
Restries

Avalia alternativas
identifica e
resolve riscos
Anlise de
riscos
Anlise de
riscos

Reviso

Anlise de
riscos

Comprometimento
Plano de Requisitos
Plano de Ciclo de Vida

partio

Planeja a
prxima fase

Anlise
de Prottipo
Prottipo
risco
1 Prottipo 2 Prottipo 3 Operacional

Ideia de
Operao
Requisitos de
Software Projeto do
Projeto
Produto
Requisitos de
Plano de
Detalhado
Soflware
Validao
Desenvolvimento
Projeto da
Cdigo
Plano de Testes
Teste
Verificao e
Plano de integrao
de
Validao
Teste
Unidade
de
Teste
Integrao
Desenvolve e verifica
de

Implementao

Aceitao

o produto no nvel
seguinte

Figura 1.3 Modelo espiral (NEPOMUCENO, 2015), adaptado de Boehm (1988).

A anlise de riscos feita na etapa de planejamento e a cada volta em torno

do eixo do espiral pode ser utilizada para o desenvolvimento de um prottipo
(PRESSMAN, 2011).

1.2.3 O modelo incremental

Muito utilizado nos dias de hoje devido s metodologias de desenvolvimento geis,
este modelo, tambm conhecido como ciclo interativo, visa combinar as vantagens
do modelo cascata com as vantagens do modelo espiral (SOMMERVILLE, 2007).

14

captulo 1

CONEXO
Uma das metodologias geis mais utilizadas para o desenvolvimento de software o Scrum.
Informaes sobre esta metodologia podem ser encontradas no site:
http://www.desenvolvimentoagil.com.br/scrum/

Os servios a serem fornecidos pelo software a ser produzido so devidamente identificados e desenvolvidos independentemente. Sendo assim, logo
na primeira entrega, o sistema j pode ser utilizado.
A figura 1.4 apresenta a forma como o modelo incremental funciona, onde
cada etapa de emprego a entrega do software incrementado para o cliente.
Incremento 2
Comunicao

Planejamento

Modelagem

Construo

Emprego

Planejamento

Modelagem

Construo

Emprego

Planejamento

Modelagem

Construo

Emprego

Incremento 2
Comunicao

Incremento N
Comunicao

Figura 1.4 Modelo incremental, adaptado de Pressman (2011).

Cada incremento entregue ao cliente um produto perfeitamente opervel. Geralmente se divide o sistema em diversas funcionalidades e em cada
incremento, escolhe-se algumas destas funcionalidades para integrarem a
prxima verso do sistema. Estas funcionalidades so completamente desenvolvidas e a verso do software gerada a partir do novo incremento perfeitamente utilizvel.
De acordo com Pressman (2011), um dos problemas do modelo incremental
definir as funcionalidades em tamanho adequado, visto que os incrementos devem
ser relativamente pequenos, com o objetivo de serem entregues em pouco tempo.

captulo 1

15

1.3 Princpios de modelagem de sistemas

Para que haja uma melhor compreenso daquilo que se quer desenvolver, uma
das medidas adotadas no processo de desenvolvimento de software a criao
de modelos (BOOCH; RUMBAUGH; JACOBSON, 2005).
Os modelos de sistemas, diferentemente dos modelos apresentados anteriormente (modelos de processo de software), buscam representar o sistema (software) em si com relao aos requisitos do mesmo. Em outras palavras, os modelos
representam a estrutura do software a ser desenvolvido e suas funcionalidades.
So apresentados por Sommerville (2007) alguns tipos de modelos de sistema, so eles:
Modelo de fluxo de dados: exibe o processamento dos dados em diferentes estgios do sistema;
Modelo de composio: tambm conhecido como modelo de agregao,
exibe como as entidades do sistema so compostas por outras entidades;
Modelo de arquitetura: apresentam os subsistemas que compem
um sistema;
Modelo de classificao: mostram como as entidades de um sistema possuem caractersticas em comum; e
Modelo de estmulo-resposta: apresenta a reao do sistema a estmulos
externos e internos, conhecido tambm como diagrama de transio de estados ou mquina de estados.
Os modelos de sistemas so criados com base nos requisitos de um sistema e podem ter diferentes nveis de abstrao, dependendo da necessidade.
Informaes sobre o porqu da criao de modelos em desenvolvimento de
software so apresentadas a seguir.

1.3.1 A importncia da modelagem

Como dito anteriormente, os modelos so representaes da realidade e segundo Booch, Rumbaugh e Jacobson (2005), esta representao simplificada. Com esta simplificao da realidade, o modelo tende a ser mais facilmente
entendido por pessoas do que a realidade (um modelo mais facilmente compreensvel que o cdigo-fonte do sistema).

16

captulo 1

A possibilidade de se fazer alteraes e redefinies do projeto de software

na fase de modelagem pode trazer reduo de custos, pois as alteraes que so
feitas na fase de construo do software so mais difceis de serem executadas.

COMENTRIO
A criao de um modelo facilita o entendimento do software, facilita a definio dos requisitos e pode trazer reduo de custos possibilitando alteraes no software ainda na fase
de modelagem.

Alm da fase de desenvolvimento do software, os modelos de um sistema

apoiam tambm a fase de manuteno, pois podem fornecer uma viso mais
prxima do requisito e do funcionamento do sistema, facilitando o emprego de
novas funcionalidades e identificao de reas falhas para a correo de erros.
Outra grande vantagem de se modelar os sistemas que, quando uma equipe de desenvolvimento de software alterada, os novos membros precisam
entender o sistema para que possam atuar e continuar o desenvolvimento, ou
mesmo dar manuteno no cdigo criado por outra pessoa. Modelos de sistemas auxiliam neste entendimento do sistema como um todo, assim como o entendimento especfico de suas funcionalidades, agilizando, assim o processo
de integrao de novos membros.
Como princpios da modelagem, Booch, Rumbaugh e Jacobson (2005) definem:
A definio de solues de um problema influenciada pela escolha de
quais modelos sero criados;
Os nveis de abstrao e preciso de cada modelo podem variar;
Modelos so mais efetivos se relacionados com a realidade; e
Sistemas mais complexos so melhor representados por um conjunto de
modelos com vrios pontos de vista.
A escolha correta dos modelos a serem criados para o desenvolvimento de
software pode priorizar os principais problemas, auxiliando em sua resoluo.
Escolhas erradas podem distrair a ateno para questes irrelevantes.
O ideal que se possua um conjunto de modelos para a descrio dos problemas e, se possvel, criados segundo diferentes pontos de vista e inter-relacionados quando necessrio.

captulo 1

17

1.4 A modelagem orientada a objetos

Diferentemente da viso tradicional do desenvolvimento de software, onde a modularizao feita por meio de procedimentos e funes, a orientao a objetos
um paradigma contemporneo. Na viso orientada a objetos os blocos de construo dos programas so classes e objetos (BOOCH; RUMBAUGH; JACOBSON, 2005).
O completo entendimento sobre a orientao a objetos e como aplic-la no desenvolvimento de software demanda um nvel de abstrao elevado. O nvel de abstrao e a definio de quais sero as classes componentes do software dependem
do problema a ser atacado, isto , pode-se ter diferentes interpretaes para cada
problema. Esta abstrao parte de princpios do que uma classe e o que um objeto, conceitos que sero apresentados e exemplificados no decorrer do livro.

COMENTRIO
Uma vez, quando cursava a graduao em sistemas de informao, ouvi de um professor de
anlise de sistemas, que o conceito de orientao a objetos parecia fcil, mas que o amadurecimento do conhecimento demora a acontecer e que em alguns anos, talvez uns 5 anos,
ns alunos teramos noo do que realmente a orientao a objetos, at mesmo depois de
utiliz-la em nosso dia-a-dia. Em termos ele estava correto, a utilizao plena da orientao a
objetos vai muito alm daquilo que aprendemos em uma disciplina, s o tempo e a experincia nos faro amadurecer este conhecimento e aplic-la plenamente em nossos softwares.

1.5 A linguagem UML

A linguagem de modelagem unificada, UML (Unified Modeling Language) foi
elaborada por Grady Booch, James Rumbaugh e Ivar Jacobson e sua primeira
verso foi lanada em janeiro de 1997 (ERIKSSON et al., 2004).
Algumas mudanas relevantes surgiram na verso 2.0 da UML. Estas mudanas aprimoraram a linguagem para certos paradigmas e vises, adicionando mais funcionalidades e deixando-a mais intuitiva (ERIKSSON et al., 2004).
Neste livro, a verso abordada a mais recente, a verso 2.0, abordada no livro
de 2005 escrito pelos criadores da linguagem.

18

captulo 1

A UML no apenas uma linguagem de modelagem de software, mas tambm pode ser empregada em diversas outras reas de conhecimento. Algumas
destas reas so citadas por Booch, Rumbaugh e Jacobson (2005):
Fluxo de trabalho no sistema legal;
Estrutura de sistemas de sade; e
Projeto de hardware.
Apenas de poder trafegar por diversas reas do conhecimento, o foco principal da UML ser empregada em sistemas de software complexos. So alguns casos onde a UML pode ser aplicada, segundo Booch, Rumbaugh e Jacobson (2005):
Sistemas de informao corporativos;
Servios bancrios;
Servios financeiros;
Setor de transportes;
Setor de telecomunicaes;
Sistemas de eletrnica mdica;
Softwares cientficos;
Servios distribudos na internet;
Entre muitas outras.
A UML abrange no s a documentao da arquitetura do sistema, mas tambm de seus detalhes, podendo expressar requisitos e modelar as atividades de
planejamento (BOOCH; RUMBAUGH; JACOBSON, 2005).

AUTOR
Os autores Grady Booch, James Rumbaugh e Ivar Jacobson so os criadores originais da
UML. Estes autores so reconhecidos mundialmente por suas contribuies significativas
para a tecnologia de objetos.

De acordo com seus criadores, Booch, Rumbaugh e Jacobson (2005), a UML

possui um total de 13 diagramas, so eles:
Diagrama de classes;
Diagrama de objetos;
Diagrama de componentes;
Diagrama de estruturas compostas;

captulo 1

19

 Diagrama de casos de uso;

Diagrama de sequncias;
Diagrama de comunicaes;
Diagrama de grficos de estados;
Diagrama de atividades;
Diagrama de implantao;
Diagrama de pacote;
Diagrama de temporizao; e
Diagrama de viso geral da interao.
Apenas para exemplificar o que seria uma classe representada em um diagrama de classes, a figura 1.5 mostra a classe Pessoa, com seus atributos e mtodos.

PESSOA
- nome : string
- idade: int
- altura: float
- peso: float

+ faladr(): voi
+ andar (): void
+ dormir(): void
+ ler(): void
Figura 1.5 Representao de uma classe na UML.

A representao apresentada na figura 1.5 mostra uma classe chamada

Pessoa. Como visto, o nome da classe aparece no primeiro espao retangular.
Logo abaixo, no segundo espao retangular, ficam os atributos da classe,
que so as caractersticas que faro parte da descrio dos objetos que forem
instanciados da classe Pessoa. Neste caso, temos os atributos nome, idade,
altura e peso. Portanto, cada objeto instanciado possui seu valor para estes atributos, em outras palavras, cada pessoa possuiria seu prprio nome, sua idade,
sua altura e peso.

20

captulo 1

No terceiro espao retangular, so exibidos os mtodos. Estes mtodos

nada mais so que as aes que as pessoas (objetos instanciados da classe
Pessoa) podem executar. Neste caso, o objeto tem a possibilidade de falar,
andar, dormir e ler.
As classes fazem parte da estrutura do sistema e podem ser relacionadas
entre si, porm estes e outros conceitos de orientao a objetos so exaustivamente discutidos no restante do livro (vamos com calma, pois o conceito de
orientao a objetos extenso e complexo).
Na modelagem de um sistema no necessrio que se utilize de todos os
diagramas disponveis. O nvel de detalhamento e uso dos diagramas depende do tipo de sistema e da abordagem desejada para a documentao do mesmo. necessrio que haja bom senso por parte de quem analisa e documenta
o software.

ATIVIDADES
01. Cite duas desvantagens de se utilizar o modelo cascata em desenvolvimento de software.
02. Em um sistema de locao de carros, cite o nome de duas possveis classes.
03. Qual dos modelos de processo de software comumente utilizado quando se adota uma
metodologia gil?

REFLEXO
Neste captulo foram apresentados os conceitos bsicos de engenharia de software assim
como os principais ciclos de vida de desenvolvimento de software, uma viso essencial para
desenvolvedores que desejam aplicar tcnicas reconhecidas e amplamente testadas em
seus processos de desenvolvimento. Tambm foram abordados conceitos de modelagem de
sistemas, apresentando a necessidade e as vantagens de se modelar software no processo
de desenvolvimento, permitindo ao aluno adquirir uma viso crtica sobre diversos aspectos
do desenvolvimento de software. A linguagem UML foi apresentada neste captulo, esta ser
utilizada durante quase todo o livro, portanto, seus conceitos bsicos so de fundamental
importncia para um bom aprendizado prtico.

captulo 1

21

LEITURA
Na pgina 45 do livro Engenharia de Software: uma abordagem profissional de Roger S.
Pressman (PRESSMAN, 2011) so apresentados alguns mitos relativos software, abordando gerenciamento, clientes e profissionais da rea. importante ficar a par do que mito
e do que realidade neste caso.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto
Alegre: Amgh, 2011.

REFERNCIAS BIBLIOGRFICAS
BOEHM, B. W.. A spiral model of software development and enhancement. Computer, [s.l.], v. 21, n. 5,
p.61-72, maio 1988. Institute of Electrical & Electronics Engineers (IEEE). DOI: 10.1109/2.59.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 2. ed. Rio de Janeiro:
Campus, 2005.
ERIKSSON, Hans-erik et al. UML 2 Toolkit. Indianapolis: Wiley, 2004.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto Alegre:
Amgh, 2011.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Pearson: So Paulo, 2007.
NEPOMUCENO, Dnys. Modelos Incremental, Espiral e de Prototipao. Disponvel em: <http://
engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html>. Acesso em: 22 set. 2015.

22

captulo 1

2
Ferramentas Case
e Casos de Uso

Este captulo aborda uma questo subjetiva, porm de grande importncia na

modelagem de sistemas, a viso de sistema, que permite variaes na modelagem e foco em diferentes pontos de vista.
O uso de ferramentas CASE tambm abordado e voc ver que o trabalho de
modelagem e anlise de sistemas pode ser assistido por computador, trazendo
grandes vantagens e facilidades.
Diagramas de casos de uso so um dos mais utilizados modelos para a descrio de software. Com estes diagramas pode-se representar cenrios de atuao
no software por fatores externos. Este captulo traz os conceitos de casos de uso
e exemplos de diagramas para diversos cenrios de sistemas, visando sua familiarizao com este tipo de modelo.

OBJETIVOS
Ao final deste captulo, o aluno conhecer:
As diferentes vises de sistema;
Ferramentas CASE; e
Casos de uso.

24

captulo 2

2.1 Vises de sistema

Um sistema de software complexo, para ser desenvolvido, demanda uma srie
de precaues por parte de seus analistas e desenvolvedores. A possibilidade de
se enxergar este sistema por diferentes pontos de vista enriquece o detalhamento dos modelos.
De acordo com Bezerra (2007), cada viso enfatiza aspectos distintos,
so elas:
Viso de casos de uso;
Viso de projeto;
Viso de implementao; e
Viso de processo.
A figura 2.1 exibe o esquema de como funcionam as diferentes vises
de sistema.

Viso de
Projeto

Viso de
Implementao

Viso de
Casos de Uso
Viso de
Processo

Viso de
Implantao

Figura 2.1 Vises de sistema, adaptado de Bezerra (2007).

A viso de casos de uso utiliza o contexto externo para a modelagem do sistema, isto , modela as interaes do sistema com o ambiente e agentes externos.
Segundo Bezerra (2007) os modelos criados a partir desta viso geralmente servem de direcionamento para os modelos das demais vises.
As demais vises do suporte a reas especficas do sistema. A viso de projeto d suporte a funcionalidades externamente visveis, a viso de implementao d suporte ao gerenciamento de verses, mdulos e subsistemas, a viso
de processo evidencia caractersticas de desempenho e paralelismo e a viso

captulo 2

25

de implantao foca na distribuio fsica do sistema, sua instalao e acoplamento dos subsistemas (BEZERRA, 2007).
Nem todas as vises devem ser obrigatoriamente construdas, isto depende da complexidade e do foco do sistema, da documentao e dos modelos necessrios.

2.2 Ferramentas CASE

Ferramentas de modelagem de software so muito utilizadas em processos
de desenvolvimento por auxiliarem a criao dos modelos, alm de algumas
outras vantagens, estas ferramentas so chamadas de CASE (Computer-Aided
Software Engineering, em portugus, Engenharia de Software Assistida por
Computador). Pode-se citar como algumas das vantagens do uso de ferramentas CASE:
Agilidade na criao de modelos;
Facilidade de alterao nos modelos;
Padronizao na apresentao de modelos;
Gerao automtica de cdigo-fonte a partir dos modelos;
Possibilidade de compartilhar os modelos salvos em arquivos; e
Sincronizar modelos com o cdigo-fonte da aplicao.
Algumas ferramentas CASE so pagas, outras gratuitas. Mesmo as gratuitas podem ter alguns recursos pagos. Seguem alguns exemplos de ferramentas
CASE para UML:
Jude;
Rational Rose;
Dia;
ArgoUML;
StarUML;
Omondo Eclipse UML;
Enterprise Architect;
Astah; e
Umbrello;

26

captulo 2

Um recurso muito interessante do uso de ferramentas CASE (algumas delas) o sincronismo entre o modelo do software e o cdigo-fonte. Este recurso
permite que o modelo esteja sempre atualizado, mesmo aps alteraes serem
feitas diretamente no cdigo, mantendo a documentao sempre vlida e atual.
Em alguns casos, alteraes feitas no modelo podem repercutir em alteraes
automticas no cdigo-fonte e sua estrutura, mas esta abordagem pouco utilizada por programadores e analistas de sistemas.
Os modelos apresentados neste livro so criados utilizando a ferramenta
Astah. O uso bsico desta ferramenta descrito a seguir.

2.2.1 A ferramenta Astah

A ferramenta CASE Astah existe na verso professional (paga) e a community
(gratuita). Estudantes podem fazer a requisio da licena da verso professional de forma gratuita.

CONEXO
No site oficial da ferramenta Astah pode-se obter maiores informaes e fazer o download
do software.
http://astah.net/

Esta ferramenta possui uma srie de recursos. Para a elaborao dos modelos necessrios para o acompanhamento da disciplina, a sua verso community
suficiente. Por possuir uma interface grfica de fcil utilizao e permitir a
criao de uma srie de modelos da UML, esta ferramenta utilizada na elaborao deste livro.
A interface do Astah apresentada na figura 2.2.

captulo 2

27

Figura 2.2 interface inicial da ferramenta Astah.

Diversos diagramas podem ser criados utilizando a ferramenta Astah, sejam eles da UML ou no, como pode-se observar na figura 2.3. Porm, alguns
destes somente na verso professional, marcados com [PAID].

Figura 2.3 Diagramas do Astah.

Os diagramas possveis de serem criados com a verso community do Astah,

traduzindo para o portugus, so:

28

captulo 2

 Diagrama de classes;
Diagrama de casos de uso;
Diagrama de grfico de estados;
Diagrama de atividades;
Diagrama de sequncia;
Diagrama de comunicao;
Diagrama de componentes;
Diagrama de implantao; e
Diagrama de estruturas compostas.
A seguir, os primeiros diagramas sero apresentados: os diagramas de casos de uso.

2.3 Casos de uso

Como o prprio nome faz-se lembrar, os casos de uso so descries de utilizao do sistema. Em outras palavras, os modelos de casos de uso visam descrever como o sistema operado por agentes externos.
De acordo com Sommerville (2007), a tcnica baseada em cenrios e so de
fundamental importncia para a modelagem de requisitos de sistemas orientados a objetos utilizando a UML.
Um exemplo de caso de uso apresentado na figura 2.4. Pode-se observar
que a representao de um caso de uso em um modelo de sistema feita por
uma elipse e, internamente, o nome do caso de uso.

Cadastrar Veculo

Figura 2.4 Exemplo bsico de caso de uso.

No caso do exemplo apresentado na Figura 2.4, a funo de cadastramento

de veculo est sendo representada pelo caso de uso em questo. Portanto, pode-se definir que o caso de uso representa o requisito do sistema.

captulo 2

29

Na utilizao de casos de uso para modelagem de sistemas, deve-se ater em

representar claramente a funcionalidade no nome do caso de uso, a fim de que
o modelo seja entendido com facilidade.

CONEXO
O link a seguir leva a uma pgina da Universidade Federal de Campina Grande a qual possui
um resumo sobre os diagramas de casos de uso.
http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SI-II/Uml/diagramas/
usecases/usecases.htm

Para que se possa interagir diretamente com o caso de uso, necessrio que
um agente externo seja representado tambm. Este agente externo chamado
de ator.
Podemos dizer que o ator quem realiza o caso de uso. Sua representao
grfica demonstrada na figura 2.5.

Secretria
Figura 2.5 Exemplo de representao de ator.

O ator no precisa necessariamente ser uma pessoa, ele pode representar

setores, outros sistemas, organizaes, entre outros.
Assim como outros modelos, os casos de uso podem ser de diversas complexidades, dependendo do nvel de abstrao que se pretende atingir com
o modelo.
A interao entre casos de uso e atores so explicados e exemplificados
a seguir.

30

captulo 2

2.3.1 Diagrama de casos de uso

A forma mais bsica do diagrama de caso de uso a interao entre um ator e um
caso de uso. Neste caso, a interao representa que o ator est realizando o caso
de uso. demonstrado na figura 2.6 a interao entre um ator e um caso de uso.

Realizar cadastro

Usurio
Figura 2.6 Interao entre ator e caso de uso.

No caso apresentado na figura 2.6, o ator usurio quem realiza cadastro,

portanto ele o executor do caso de uso realizar cadastro. Para representar
esta interao utiliza-se uma linha que liga o ator ao caso de uso.
Existem tambm interaes entre casos de uso. Estas interaes representam um caso de uso que responsvel por realizar outro caso de uso (e no mais
um ator realiza um caso de uso).
As relaes entre casos de uso podem ser de dois tipos:
<<include>> ou
<<extend>>.
O exemplo de diagrama de caso de uso exibido na Figura 2.7 apresenta os
dois tipos de relao entre casos de uso.

Vender produto

Vendedor

<<include>>

Emitir nota fiscal

<<extend>>

Cadastrar cliente

Figura 2.7 Exemplo de relao entre casos de uso.

captulo 2

31

No exemplo da Figura 2.7 um vendedor realiza a venda de um produto.

Porm, quando o caso de uso vender produto efetuado, outros casos de uso
podem ser realizados automaticamente. Neste caso, pode-se fazer uma analogia em que o ator dos casos de uso emitir nota fiscal e cadastrar cliente o
caso de uso vender produto.
No caso de emitir nota fiscal, por se tratar de uma relao de <<include>>,
este caso de uso ser obrigatoriamente realizado. Em outras palavras, ao vender
um produto, a nota fiscal emitida obrigatoriamente no sistema.
J no caso de uso cadastrar cliente, por ser uma relao do tipo <<extend>>,
no obrigatrio que o cliente seja cadastrado a cada venda de produto efetuada.
Pode-se dizer, analisando o exemplo da Figura 2.7, que este sistema trabalha da seguinte forma:
O vendedor o responsvel por efetuar a venda de produtos;
Ao se realizar uma venda, a nota fiscal obrigatoriamente emitida;
Caso o cliente ainda no seja cadastrado, ao efetuar uma venda, pode-se
cadastrar o cliente.
Os atores podem ser representados como uma hierarquia, tambm chamada de herana ou de generalizao. Conceitos mais aprofundados de herana
so apresentados no prximo captulo. A generalizao de atores representada na figura 2.8.

Cliente

Pessoa Fsica

Pessoa Jurdica

Figura 2.8 Generalizao de atores.

Em generalizao podemos agrupar tipos de atores, como no exemplo da

figura 2.8, onde os tipos de clientes so agrupados em um ator chamado cliente. Isto facilita na hora de criar os casos de uso que so realizados por mais de

32

captulo 2

um ator. Neste exemplo, subentende-se que existam casos de uso que podem
ser realizados tanto pelo ator pessoa fsica quanto pelo ator pessoa jurdica.
Para facilitar e simplificar o modelo, pode-se generalizar estes atores criando o
ator cliente, que executar o caso de uso. Um exemplo de como isto pode ser
feito apresentado na Figura.

Realizar cadastro
Cliente

Pessoa Fsica

Pessoa Jurdica

No exemplo da figura pode-se entender que tanto o cliente pessoa fsica

quanto o cliente pessoa jurdica realizam o caso de uso criar conta bancria,
Neste caso, ao invs de se representar duas realizaes do mesmo caso de uso,
pode-se representar utilizando apenas uma realizao.
Outro exemplo de generalizao pode ser citado quando os tipos de ator
executam tarefas diferentes, como apresentado na figura 2.9.

Realizar cadastro
Cliente

Pessoa Fsica

Pagar Conta

Pessoa Jurdica

Solicitar Emprstimo

Figura 2.9 Generalizao de ator com aes especficas.

captulo 2

33

A Figura 2.9 traz um exemplo onde qualquer tipo de cliente pode criar uma
conta bancria, porm apenas o cliente pessoa jurdica pode solicitar emprstimos e o cliente pessoa fsica o nico que pode pagar contas.

COMENTRIO
A generalizao, tambm conhecida como herana, um conceito de orientao a objetos e
utilizada em diversos diagramas da UML.

Alm da generalizao de atores, pode-se adotar tambm a generalizao de

casos de uso, seguindo o mesmo conceito e aplicaes. Na Figura 2.10 apresentado um exemplo de generalizao de casos de uso.
Cadastrar Aluno

Cadastrar Aluno
de Graduao

Cadastrar Aluno
de Ps-graduao

Figura 2.10 Generalizao de casos de uso.

A figura 2.10 representa uma generalizao de casos de uso onde, a ao

de cadastrar um aluno generaliza as outras duas aes de forma que, em casos
especficos, pode-se realizar um dos casos de uso especiais (cadastrar aluno
de graduao e cadastrar aluno de ps-graduao) e em casos gerais pode-se
realizar o caso de uso cadastrar aluno.
Para exemplificar melhor o uso da generalizao de casos de uso, a figura
2.11 exibe um diagrama onde pode-se observar a realizao na forma mais geral
e tambm mais especializada.

34

captulo 2

Cadastrar Aluno

Secretria-chefe
Cadastrar Aluno
de Graduao

Cadastrar Aluno
de Ps-graduao

Secretria de
Graduao

Secretria de
Ps-graduao

Figura 2.11 Utilizando a generalizao de casos de uso.

PERGUNTA
Por que, no modelo demonstrado na figura 2.11, no se pode generalizar as secretrias de
graduao e ps-graduao, como filhas de secretria-chefe?

Observando o exemplo apresentado na figura 2.11, tm-se trs atores e trs

casos de uso. O ator secretria-chefe realiza o caso de uso cadastrar aluno,
isto significa que este ator pode cadastrar qualquer tipo de aluno, seja ele de
graduao ou de ps-graduao, pois este caso de uso est generalizando os
casos cadastrar aluno de ps-graduao e cadastrar aluno de graduao.
Nota-se que o ator secretria de graduao, diferentemente do ator secretria-chefe, no realiza o caso de uso generalizado, e sim o especializado, chamado cadastrar aluno de graduao. Sendo assim, este ator impossibilitado

captulo 2

35

de realizar o caso de uso cadastrar aluno de ps-graduao. O mesmo acontece com o ator secretria de ps-graduao, que impossibilitado de realizar o
caso de uso cadastrar aluno de graduao.
De forma resumida, quando se utiliza generalizao em casos de uso, podese deixar os modelos mais concisos e enxutos, alm de possibilitar descrio
mais abrangente e detalhada do requisito.
Outro termo utilizado em casos de uso so os assuntos. A figura 2.12 exibe
um exemplo de diagrama de casos de uso utilizando assunto.
Cadastro

Cadastrar Pessoas

Funcionrio

Pedidos

Atendimento

Chamada

Figura 2.12 Assunto em casos de uso.

Os assuntos do exemplo apresentado na Figura 2.12 so:

Cadastros; e
Pedidos.
Os assuntos so basicamente uma forma de segregar o contexto dos casos
de uso, podendo tambm ser usado para representar diversos tipos de agrupamentos (BOOCH; RUMBAUGH; JACOBSON, 2005).
de suma importncia a exemplificao de alguns cenrios para que o entendimento quanto aos casos de uso seja pleno, portanto, na prxima sesso,
um estudo de caso apresentado.

36

captulo 2

2.3.2 Exemplos de casos de uso

No exemplo aqui demonstrado tem-se uma funcionalidade de um sistema de
solicitaes de servios, onde um cliente pode solicitar servios a tcnicos de
uma empresa e o tcnico, por sua vez, atua nesta solicitao at encerr-la. Na
figura 2.13 apresentado o cenrio onde o cliente solicita o servio.

Solicitar Servio

Cliente

<<include>>

Notificar responsveis

<<include>>

Validar cliente

Figura 2.13 Exemplo de caso de uso onde o cliente solicita um servio.

O cenrio apresentado na figura 2.13 demonstra que, no sistema em questo, no momento em que um cliente registra uma solicitao de servio, o sistema automaticamente valida o cliente (verifica se o mesmo cadastrado) e
notifica os responsveis.
Por se tratar de um <<include>>, a notificao dos responsveis e a validao do cliente so aes obrigatrias na realizao do caso de uso solicitar servio.

PERGUNTA
Se o requisito descrito pela figura 2.13 fosse tal que o cliente pudesse optar por enviar ou
no uma notificao aos responsveis, quais seriam as alteraes necessrias no diagrama
para que representasse esta mudana no requisito?

captulo 2

37

Em outro cenrio, a figura 2.14 demonstra um diagrama de casos de uso

onde o funcionrio tcnico da empresa atua na solicitao feita anteriormente.

Finalizar solicitao

Tcnico

<<include>>

<<extend>>

Notificar superior

Notificar solicitante
<<extend>>

<<extend>>

Registrar atuao

Figura 2.14 Exemplo de caso de uso onde o tcnico atua na solicitao de servio.

O ator tcnico pode realizar dois casos de uso:

Registrar atuao; e
Finalizar solicitao.
O caso de uso registrar atuao significa que o tcnico estaria registrando
um trabalho efetuado para a resoluo da solicitao do cliente. Ao realizar este
caso de uso, no obrigatrio que se realize tambm notificar solicitante e
notificar superior, pois estes relacionamentos so do tipo <<extend>>.
Na realizao do caso de uso finalizar solicitao, necessrio (obrigatrio) que se notifique o solicitante. Portanto, o relacionamento entre finalizar solicitao e notificar solicitante deve ser do tipo <<include>>. J o
relacionamento entre finalizar solicitao e notificar superior do tipo
<<extend>>, o que significa que no obrigatria a notificao do superior
quando um tcnico finaliza a solicitao.

38

captulo 2

ATIVIDADE
01. Crie um diagrama de casos de uso que represente a funcionalidade de cadastro de um
material didtico por um professor em um sistema de gesto de materiais de disciplinas.
Os requisitos do sistema so:
O professor cadastra material didtico;
O sistema checa se o professor vinculado disciplina em questo;
O sistema checa se a extenso do arquivo do material condizente e segura;
O professor pode escolher proteger o material cadastrado com uma senha.

REFLEXO
Neste captulo foram apresentados alguns conceitos de vises de sistemas, onde pde-se
observar que dependendo da necessidade e do foco que se quer alcanar com a modelagem,
utiliza-se um certo conjunto de modelos. Outro tema importante abordado aqui foi a utilizao
de ferramentas CASE, estas so de grande valia para analistas de sistemas, ajudando na
tarefa de modelagem e at gerao automtica de cdigo-fonte. A ferramenta Astah, que
utilizada para a criao dos modelos apresentados, mostra-se poderosa e pode ser de grande ajuda para estudos e utilizao real.
Os casos de uso foram apresentados e sua importncia destacada, assim como diversos
exemplos. Estes exemplos so de grande utilidade pois alm de ajudar a fixar os conceitos
do diagrama de casos de uso, tem-se uma viso de como modelar sistemas simples, partindo
de requisitos corriqueiros, para ento se aprofundar em complexidade.

LEITURA
O livro de Ana Cristina Melo (MELO, 2006) apresenta uma srie de exerccios resolvidos utilizando a modelagem UML. De forma didtica, as resolues so bem comentadas exemplificadas.
MELO, Ana Cristina. Exercitando modelagem em UML: 51 exerccios resolvidos. Rio de
Janeiro: Brasport, 2006.

captulo 2

39

REFERNCIAS BIBLIOGRFICAS
BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML: Um Guia Prtico Para
Modelagem De Sistemas Orientados A Objetos Atravs Da Linguagem De Modelagem Unificada. 2.
ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 2. ed. Rio de Janeiro:
Campus, 2005.
MELO, Ana Cristina. Exercitando modelagem em UML: 51 exerccios resolvidos. Rio de Janeiro:
Brasport, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Pearson: So Paulo, 2007.

40

captulo 2

3
Diagrama de
Classes

Este captulo aborda o diagrama responsvel por modelar a estrutura de um sistema. Em muitos casos, a modelagem utilizando este diagrama feita para que,
aps discutida e definida, sejam gerados automaticamente os cdigos-fonte da
lgica de negcios do sistema a ser desenvolvido. Os conceitos de orientao
a objetos apresentados neste captulo so de grande utilidade para o entendimento do paradigma e para futuras aplicaes em desenvolvimento e modelagem de sistemas.
No final do captulo existe um estudo de caso para que os conceitos apresentados no decorrer deste possam ser melhor fixados e posteriormente estudados.

OBJETIVOS
Este captulo apresenta a modelagem utilizando o diagrama de classes conceitual da UML,
alm de importantes conceitos de orientao a objetos muito teis para modelagem e desenvolvimento de software.

42

captulo 3

3.1 Classes e objetos

Os conceitos de classes e objetos so fundamentais para o desenvolvimento
de software e de modelos de software neste paradigma. De acordo com Booch, Rumbaugh e Jacobson (2005) as classes so a estrutura mais importante na
construo de sistemas orientados a objetos.
A representao de classe na UML (figura 3.1) um retngulo dividido em
trs partes:
Nome da classe;
Atributos; e
Mtodos.

NOME
atributo 1: tipo
atributo 2: tipo

mtodo 1(): tipo

mtodo 2(parmetro:tipo): tipo
Figura 3.1 Exemplo de classe com atributos e mtodos tipados.

O nome da classe costuma iniciar com letra maiscula, para os mtodos e

atributos, a letra inicial minscula. No exemplo da Figura 3.1 observa-se que
a primeira diviso do retngulo contm o nome da classe. Na segunda diviso
(a do meio), contm os atributos da classe enquanto a terceira diviso possui
os mtodos.
O nome da classe deve ser algo que represente uma entidade no sistema a
ser modelado. Em um sistema bem simples de cadastro de clientes, pode-se
destacar, por exemplo, a entidade Cliente.
De acordo com Fowler (2005), para se entender os atributos de uma classe,
pode-se fazer uma analogia campos (variveis pertencentes uma estrutura)

captulo 3

43

de uma linguagem de programao. Em outras palavras, os atributos so as

qualidades que um objeto possuir quando instanciado seguindo o modelo de
uma classe.
Os mtodos de uma classe so as aes que um objeto instanciado pode
executar, recebendo ou no parmetros, retornando ou no valores.
Na classe apresentada na figura 3.1, os valores de nome, atributos e mtodos so fictcios e meramente ilustrativos. Como pode-se perceber, o nome da
classe Nome, seus atributos so atributo1 e atributo2 e seus mtodos
so mtodo1 e mtodo2. Os tipos que aparecem na classe servem para
tipar os campos, isto , definir se so campos de texto, nmeros, caracteres,
objetos de outras classes e etc.
Os tipos dos mtodos so basicamente o tipo do valor que ser retornado.
Quando no h retorno, define-se o tipo void. No mtodo2 existe uma varivel sendo enviada como parmetro para a execuo do mtodo (est entre parnteses), enquanto o mtodo1 no precisa de parmetros para ser executado.

ATENO
A notao utilizada para os tipos de variveis e atributos (String, Integer, Float, entre outros)
advinda da linguagem de programao Java, que implementa a orientao a objetos.

Um exemplo real de classe apresentado na figura 3.2.

VENTILADOR
voltagem: Integer
peso: Float
rotaoMxima: Integer
nmeroPs: Integer
cor: String

44

captulo 3

VENTILADOR
girarAntiHorrio(valocidade:Integer): void
girarHorrio(valocidade:Integer): void
desligar(): void
checarSeEstLigado(): Boolean
Figura 3.2 A classe ventilador.

A classe Ventilador (figura 3.2) possui os seguintes atributos:

Voltagem: um nmero inteiro e armazena em qual voltagem que o ventilador funciona;
Peso: um nmero com ponto flutuante (real) e armazena o peso
do ventilador;
Rotao mxima: um nmero inteiro que indica qual a rotao mxima
que o ventilador pode alcanar (voltas por minuto);
Nmero de ps: um nmero inteiro que indica quantas ps o ventilador
possui; e
Cor: do tipo texto e armazena a cor que o ventilador possui.
Os mtodos da classe ventilador so:
Girar anti-horrio: o ventilador comea a girar em sentido anti-horrio
e ao executar este mtodo, nenhum valor retornado, porm no momento da
execuo do mtodo, necessrio que se transmita a velocidade desejada;
Girar horrio: o ventilador comea a girar em sentido horrio de acordo
com a velocidade recebida por parmetro e ao ser executado, este mtodo no
retorna valor;
Desligar: o ventilador desligado e para de girar, este mtodo no recebe
parmetro nem retorna valor;
Checar se est ligado: para ser executado, este mtodo no necessita
de parmetro, porm o valor booleano (verdadeiro ou falso) retornado, indicando verdadeiro para quando o ventilador est ligado e falso para quando
est desligado.

captulo 3

45

CURIOSIDADE
A escrita que aparece na Figura 3.2, onde as palavras so juntas, porm, ao iniciar uma nova
palavra utiliza-se a primeira letra maiscula chama-se CamelCase, pelas frases ficarem com
ondulaes parecidas com corcovas de camelo. Esta escrita adotada como padro em
muitas linguagens de programao, como Java.

A classe, como dito anteriormente, um modelo para a criao (instanciao) de objetos. A tabela 3.1 exibe uma srie de objetos que poderiam ser instanciados da classe Ventilador com seus respectivos atributos.

Ventilador 1

Ventilador 2

46

captulo 3

voltagem

220

peso

2,13

rotao mxima

700

nmero de ps

cor

rosa

voltagem

220

peso

1,54

rotao mxima

650

nmero de ps

cor

preto

Ventilador 3

voltagem

110

peso

1,95

rotao mxima

800

nmero de ps

cor

branco

Tabela 3.1 Objetos da classe ventilador.

Nota-se nos ventiladores da Tabela 3.1 que seus valores obedecem ao tipo
definido na classe, isto , onde na classe definido que o atributo um nmero
inteiro, no objeto o valor a ser atribudo deve obedecer ao modelo, portanto,
deve ser um nmero inteiro tambm, acontecendo isto para todos os atributos
de um objeto instanciado.

EXEMPLO
Um exemplo clssico de classe a classe Carro. Seus atributos podem ser cor, modelo,
renavam, placa, ano de fabricao, entre outros. Como mtodos, pode-se citar acelerar,
frear, trocar a marcha, ligar o rdio, desligar o rdio, entre outros.

Para se modelar um sistema utilizando o diagrama de classes preciso

identificar suas classes, isto explicado com mais detalhes no estudo de caso
deste captulo. Porm, no basta identificar as classes, necessrio que se identifique tambm sua funo e interao dentro do sistema a ser modelado. Estes
conceitos de interao entre classes, importncia vital para um bom modelo de
software, so apresentados a seguir.

captulo 3

47

3.2 Relacionamentos
Os blocos de construo de um sistema so basicamente as classes, porm classes por si s no o descrevem suficientemente. Para que o entendimento do
modelo seja satisfatrio e cumpra seu objetivo de representar o funcionamento
do sistema de software, necessrio que as classes interajam entre si.
As interaes entre classes so chamadas de relacionamentos. Estes relacionamentos podem ser de diversos tipos, dependendo da funo que a classe
exerce no sistema a ser modelado.
Os tipos de relacionamento entre classes em um diagrama de classes so:
Herana;
Associao;
Agregao;
Composio; e
Dependncia.
Estes quatro tipos de relacionamentos so detalhados nos prximos itens.

3.2.1 Herana
Para se identificar um relacionamento de herana (tambm conhecido como
generalizao ou especializao) entre duas ou mais classes, costuma-se utilizar da pergunta: um(a)?. Ao fazer esta pergunta entre duas classes, se a
resposta for sim, pode-se ento considerar o emprego de um relacionamento
de herana.
Na herana da vida real as caractersticas dos pais so passadas aos filhos.
Os filhos, herdando as caractersticas dos pais, desenvolvem as suas prprias e
tambm seu prprio comportamento.
Em sistemas orientados a objetos, tem-se tambm a classe pai e a classe
filha. Em algumas linguagens de programao, um filho pode ter mais de um
pai, como o caso de C++ e Python, isto chamado de herana mltipla. A herana simples quando uma classe s pode ter uma classe pai, como no caso
da linguagem Java.
Para exemplificar este tipo de relacionamento, so utilizadas classes de animais, imaginando-se que um sistema necessite das classes de animais para seu

48

captulo 3

funcionamento, portanto, tm-se as classes de alguns tipos de animais em seu

modelo, como exibido na figura 3.3.
Animal

Mamfero

Ave

Peixe

Figura 3.3 Classes da herana de animais.

O exemplo da figura 3.3 considera apenas os nomes das classes pois o intuito de identificao da herana, na figura 3.4 o modelo est completo.
Para a identificao da herana de animais, a pergunta proposta um(a)?
utilizada. Portanto, quando se dirige a pergunta de MamferoTerrestre para
Animal, a resposta sim, portanto, MamferoTerrestre filho de Animal
(todo mamfero terrestre um animal). J quando dirigimos a pergunta de
Animal para Ave, a resposta no, portanto, Animal no filho de Ave.
No modelo apresentado na figura 3.3, MamferoTerrestre, Ave e Peixe
so filhos de Animal, pois todos so obrigatoriamente animais. Alm disto,
a herana pode conter vrios nveis. Poderamos modelar mais classes como
filhas de MamferoTerrestre, filhas de Ave e filhas de Peixe, e assim
por diante.
Outra propriedade da herana entre classes que uma classe filha pode sobrescrever os mtodos da classe pai, se desejar que ele seja executado de forma
especfica (o nome e o tipo dos parmetros devem ser idnticos aos do mtodo
a ser sobrescrito). Na figura 3.4, um exemplo de sobrescrio de mtodo apresentado na classe Peixe, onde o mtodo respirar sobrescrito, visto que os
animais do tipo peixe executariam este mtodo (respirariam) de uma forma diferente que seu pai (animal).

captulo 3

49

Animal
nome: String
peso: Float
altura: Float
comprimento: Float
respirar(): void

Mamfero Terrestre

Peixe

Ave

quantidadeLeit: Float

tamanhoAsa: Float

tamanhoNadadeira: Float

andar (velocidade: Integer): void

voar (altura: Integer): void

Nadar (velocidade: Integer): void

respirar(): void

Figura 3.4 Herana entre animais com as classes completas.

Cada classe herdeira possui todos os atributos e mtodos que so herdados

da classe pai, somados aos seus especficos. A classe pai possui apenas os seus
especficos. Se uma das classes filho, por exemplo Ave, tivesse seu prprio
filho, este herdaria tudo desde Animal, somando com tudo da classe Ave,
somando com seus atributos e mtodos prprios. Para melhor exemplificar a
herana, a tabela 3.2 exibe objetos instanciados dos filhos da classe Animal.

Ave 1

50

captulo 3

nome

Piu-Piu

peso

0,55

altura

0,35

comprimento

0,25

tamanho Asa

0,28

Ave 2

Mamfero terrestre1

Mamfero terrestre2

nome

Blue

peso

1,65

altura

0,30

comprimento

0,35

tamanho Asa

0,40

nome

Tom

peso

12,8

altura

0,55

comprimento

0,70

quantidade Leite

nome

Rex

peso

25,45

altura

0,80

comprimento

1,15

quantidade Leite

captulo 3

51

Peixe1

Peixe2

nome

Adam

peso

0,07

altura

0,03

comprimento

0,08

tamanho Nadadeira

0,02

nome

Zeus

peso

0,15

altura

0,07

comprimento

0,12

tamanho Nadadeira

0,06

Tabela 3.2 Objetos das classes filhas de Animal.

EXERCCIO RESOLVIDO
Treine o relacionamento de herana utilizando a pergunta um(a)? entre as seguintes classes de uma loja de departamentos (utilize apenas o nome das classes):
Televiso;
Eletrnico;
Cadeira;
Computador;
Produto;

52

captulo 3

 Livro;
Mvel;
Mesa; e
Tablet.
Resoluo:
Produto

Eletrnico

Computador

Televiso

Livro

Tablet

Mvel

Cadeira

Mesa

Uma aplicao real de herana em um modelo de sistema demonstrada no

estudo de caso deste captulo. A seguir, outros tipos de relacionamento entre
classes so apresentados.

3.2.2 Associao
O relacionamento de associao a base da interao entre as classes de um
projeto de sistema. A associao entre classes pode ser:
Simples;
De agregao;
De composio; e
De dependncia.
Este item trata da associao simples, as outras modalidades so apresentadas nos itens seguintes.
As associaes so relaes entre classes que possuem um rtulo e uma
cardinalidade (tambm conhecida como multiplicidade). O rtulo um nome
descritivo dado ao relacionamento para que o entendimento da relao entre

captulo 3

53

as classes seja mais objetiva. A cardinalidade o modo com que as classes so

relacionadas no sistema, o que de grande importncia para a implementao do mesmo. Uma cardinalidade mal especificada pode trazer muitas consequncias para o desenvolvimento e operao do software.
Na UML, para se representar uma associao simples utilizada uma linha
reta e contnua que conecta as duas classes relacionadas, como exibido na figura 3.5.
Cliente

Produto
1 Compra

Figura 3.5 Exemplo de associao simples entre classes.

As classes Cliente e Produto esto relacionadas por uma associao

simples no exemplo da Figura 3.5. A cardinalidade representada pelos smbolos 1 e * e o rtulo pelo texto compra.
O rtulo indica o porqu de as classes estarem relacionadas e a seta que o
segue indica a direo do relacionamento. Neste caso (figura 3.5), pode-se entender que na estrutura do sistema a ser modelado, o cliente compra produto,
portanto deve-se saber qual cliente comprou um certo produto e quais produtos foram comprados por um cliente.
Para que se chegue ao entendimento da cardinalidade e como ela atua no
relacionamento, preciso que se saiba que os tipos de cardinalidade existentes so:
1;
*;
0..*;
1..*; e
1..1.
O asterisco (*) representa a palavra muitos enquanto os nmeros 0 e 1 representam quantidades definidas. Na ocasio onde se tem dois smbolos separados por dois pontos (0..*, 1..* e 1..1) o primeiro significa a quantidade mnima
e o segundo a quantidade mxima. Em ocasies onde s se tem um smbolo,
apenas a quantidade mxima est especificada. Entende-se ento que, ao utilizar apenas o asterisco como cardinalidade (como no exemplo da figura 3.6),
qualquer quantidade pode ser associada.

54

captulo 3

Existem casos em que se utiliza de constantes numricas (diferentes de zero

e um), isto significa que os objetos de uma classe se relacionam em quantidades exatas (ou faixas de valores definidos) com os objetos de outra classe. Como
exemplo, podemos ter a cardinalidade 5 ou 3..8, representando respectivamente um relacionamento com exatamente cinco objetos da outra classe e outro
que pode variar de 3 a 8 objetos. O uso destas constantes no muito comum,
mas pode ser necessrio especificar relacionamentos desta maneira dependendo da funcionalidade e estrutura do software que est sendo modelado.
No caso da figura 3.5, um cliente pode comprar muitos produtos mas um
produto s pode ser comprado por no mximo um cliente (as quantidades mnimas no esto especificadas).
Outro exemplo de associao simples apresentado na figura 3.6, onde so
utilizadas outras cardinalidades.
Funcionrio

Setor
1..* Trabalha em

Figura 3.6 Exemplo de associao simples entre funcionrio e setor.

As cardinalidades do relacionamento da figura 3.6 podem ser entendidas como:

Um funcionrio trabalha em, no mximo, um setor; e
Um setor pode ter um ou mais funcionrios ligados ele;
Caso a cardinalidade de setor ao invs de 1 fosse 1..1, significaria que um
funcionrio deve estar obrigatoriamente associado a um setor.
No estudo de caso deste captulo h mais exemplos de associao simples.
A seguir so apresentados dois tipos de associao chamados de todo-parte: a
agregao e a composio.

3.2.3 Agregao
Este relacionamento uma associao diferente da associao simples apresentada no item anterior. A agregao considera as classes relacionadas como
sendo uma o todo e a outra a parte. Por tal motivo tambm conhecida,
juntamente com a composio, como relacionamento todo-parte.

captulo 3

55

O smbolo que identifica a agregao apresentado na figura 3.7. Um losango vazado utilizado para identificar qual a classe todo e qual a classe
parte. Como pode-se observar, o losango indica a classe todo.
Todo

Parte

Figura 3.7 Exemplo bsico de agregao.

Na figura 3.7 o relacionamento apresentado indica que um objeto da classe

Todo possui um conjunto de objetos da classe Parte.
Na agregao pode-se incluir tambm, assim como na associao, a cardinalidade e o rtulo do relacionamento.
Um exemplo real apresentado na Figura 3.8, onde pode-se observar um
pedido de compra com os itens que sero comprados.
Pedido
cdigo: Integer
data: Date

Item
cdigo: Integer
nome: String
preo: Flota

Figura 3.8 Exemplo real de agregao.

Cada pedido do exemplo da figura 3.8 possui itens. No caso da agregao,

os itens podem existir no sistema mesmo antes de fazerem parte de um pedido. Em outras palavras, a existncia de Item independe da existncia de seu
Pedido.

3.2.4 Composio
A representao grfica da composio feita com um losango cheio (pintado).
Um exemplo desta representao apresentado na figura 3.9.
Todo

Parte

Figura 3.9 Exemplo de composio.

A utilizao da composio muito similar agregao, porm, com uma diferena principal: a existncia da parte no faz sentido se o todo no existir.

56

captulo 3

CONCEITO
Na agregao, o objeto parte pode pertencer a mais de um todo, enquanto na composio,
o objeto parte pode pertencer somente a um todo. Na composio, as partes so destrudas
como consequncia na destruio do seu respectivo todo (PODESWA, 2005).

Para melhor entendimento de como a composio funciona em modelagem de sistemas, a figura 3.10 exibe um exemplo real de utilizao.
Galeria
cdigo: Integer
nome: String

Foto
cdigo: Integer
Descrio: String

Figura 3.10 Exemplo real do uso de composio.

Um mdulo de galeria de fotos simplificado exibido na figura 3.10.

Segundo a modelagem apresentada, uma galeria composta (por isso o termo
composio) de fotos. Pode-se chegar a duas concluses com os conceitos apresentados anteriormente:
a existncia da foto no faz sentido se no for para compor uma galeria; e
uma galeria, quando destruda no sistema, as fotos tambm so.
Os relacionamentos todo-parte podem ser muito teis em modelagem
de sistemas, podendo representar diversas situaes reais de agregao
ou composio.

3.2.5 Dependncia
A dependncia de classes utilizada quando, para que aes sejam executadas
por um objeto, necessrio que exista um objeto de outra classe.
Um exemplo prtico deste uso apresentado na figura 3.11, onde um caixa
de banco possui o mtodo de depositar (no caso, dinheiro). Este mtodo recebe
dois parmetros: o valor a ser depositado e a conta em que o valor ser creditado. Para que a conta possa ser especificada, necessrio que um objeto da
classe Conta seja passado como parmetro para o mtodo, portanto, a classe
Caixa tem uma relao de dependncia com a classe Conta.

captulo 3

57

Caixa
cdigo: Integer
nome: String
depositar (valor: Float, conta: Conta): void

Conta
nmero: Integer

Figura 3.11 Exemplo de relacionamento de dependncia entre classes.

Como pode ser observado na figura 3.11, o relacionamento de dependncia

representado por uma linha tracejada e uma seta. A seta indica a classe dependente, neste caso, a classe Caixa depende da classe Conta.
Um estudo de caso de modelagem utilizando diagrama de classes apresentado no item seguinte, com o objetivo de fixar os conceitos de orientao a
objetos apresentados e tambm os conceitos da modelagem utilizando a UML.

3.3 Estudo de caso

Este estudo de caso tem como objetivo a fixao dos conceitos apresentados
neste captulo. A abordagem que ser utilizada a de modelagem de um sistema de uma escola. O sistema da escola apresentado de forma simplificada
para atuar de forma didtica.
O modelo do estudo de caso apresentado na figura 3.12 discutido neste
item. Este modelo possui apenas os nomes das classes e seus atributos, informao suficiente para o entendimento e aprendizado do modelo.

CURIOSIDADE
No momento do desenvolvimento do sistema orientado a objetos, os relacionamentos de muitos
para muitos, tambm conhecidos como N para N, possuem uma implementao onde cada um dos
objetos possui uma lista do objeto com o qual est se relacionando. Ao utilizar bancos de dados relacionais para o desenvolvimento, a soluo para este relacionamento de forma diferente, criandose uma tabela entre as outras duas relacionadas para que se possa fazer a navegao entre ambas.

58

captulo 3

Telefone

Pessoa
nome: String
cpf: Strin

Possui

0 . .*

cdigo: Integer
dds: Integer
nmero: String

Aluno

Professor

registroAcademico: Integer

codigoInterno: String

Leciona para

Contm
1

Disciplina
cdigo: Integer
nome: String

Turma
*

Estuda

nmero: Integer
nome: String
ano: Integer

Figura 3.12 Estudo de caso de diagrama de classes.

No estudo de caso apresentado (figura 3.12) h uma herana entre Pessoa

e Aluno e Pessoa e Professor. Sendo assim, a composio entre Pessoa
e Telefone vlida para ambos os filhos (Professor e Aluno). Em outras
palavras, alunos e professores tero a possibilidade de ter telefones includos
em seu cadastro. Neste caso, a existncia de um telefone s faz sentido se seu
dono tambm existir, para que no haja telefones cadastrados no sistema
sem uma relao com algumas das pessoas tambm cadastradas.
Ambas as classes Professor e Aluno tm relacionamento com a classe
Turma, porm de maneiras diferentes. O professor leciona para diferentes
turmas, enquanto o aluno parte de apenas uma turma.
As disciplinas que so estudadas por uma turma podem ser vrias, por isto
a cardinalidade (*). Uma mesma disciplina pode ser estudada por mais de uma
turma, portanto, o outro lado da associao simples tambm possui cardinalidade (*). Neste caso, pode-se optar por detalhar o modelo criando uma classe associativa.

captulo 3

59

CONEXO
Uma explicao sucinta e didtica sobre classes associativas apresentada no seguinte link:
http://www.inf.ufpr.br/silvia/ESNovo/UML/pdf/ModeloConceitualAl.pdf

Este estudo de caso simples pode servir de guia para o desenvolvimento de

novos modelos de software orientados a objeto, porm, trata-se de um modelo conceitual. Em modelos conceituais no so necessrios identificar os tipos
das variveis e as dependncias, estes e outros conceitos so abordados em diagramas de classes de projeto, no captulo 5.

ATIVIDADE
01. Crie um diagrama de classes que modele um sistema bancrio simplificado, onde devem ser abordados os clientes, as contas, e os gerentes de conta. Utilize apenas os nomes
das classes.

REFLEXO
A apresentao de conceitos importantes de orientao a objetos, guiados pelo diagrama de
classe, foram apresentados neste captulo. A construo de um sistema informatizado passa
pela definio de suas estruturas bsicas, sendo assim, o diagrama de classes d o suporte
necessrio para que esta estrutura seja montada e modelada de acordo com o paradigma
orientado a objetos. Classes, objetos e os diversos relacionamentos apresentados do suporte criao de modelos de sistemas simples a complexos.

LEITURA
O segundo captulo do livro UML for the IT Business Analyst (UML para o analista de negcios de TI) de Howard Podeswa (2005) apresenta de forma sucinta, objetiva e didtica
conceitos de orientao a objetos direcionados analistas de TI.

60

captulo 3

PODESWA, Howard. UML for the IT Business Analyst: A Practical Guide to Object-Oriented
Requirements gathering. 1. ed. Boston: Thomsom, 2005.

REFERNCIAS BIBLIOGRFICAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 2. ed. Rio de Janeiro:
Campus, 2005.
FOWLER, Martin. UML Essencial: Um breve guia para a linguagem-padro de modelagem de objetos.
3. ed. Porto Alegre: Bookman, 2005.
PODESWA, Howard. UML for the IT Business Analyst: A Practical Guide to Object-Oriented
Requirements gathering. 1. ed. Boston: Thomsom, 2005.

captulo 3

61

62

captulo 3

4
Descrio de
Casos de Uso e
Outros Diagramas
da UML

Este captulo apresenta um aprofundamento nos casos de uso j apresentados

anteriormente com um conceito muito importante chamado de descrio de
casos de uso. As descries de casos de uso geralmente contm mais informaes e de forma mais detalhada que os diagramas apresentados no captulo 2,
portanto, comum que se utilize das duas tcnicas em conjunto. Alguns outros
diagramas tambm so apresentados neste captulo, cada um com seu objetivo
e foco principal, permitindo que se possa modelar software com mais qualidade e apresentar modelos concisos e condizentes com o objetivo final.

OBJETIVOS
Ao final deste captulo, o aluno conhecer:
Conceitos de descrio de casos de uso;
Os diagramas de interao da UML;
O diagrama de estados; e
O diagrama de atividade;

64

captulo 4

4.1 Descrio de casos de uso

Os casos de uso, como vistos no captulo 2, so os principais componentes do diagrama de casos de uso. Este diagrama limitado quanto aos procedimentos de execuo e detalhamento dos casos de uso, por este motivo, tem-se a descrio destes.
Esta descrio feita de forma textual e detalha o funcionamento de um caso
de uso. De acordo com Larman (2007), manter o foco nos diagramas de caso de
uso e esquecer sua forma textual um erro comum para quem est iniciando em
anlise de sistemas. Deste modo, pode-se concluir que as narrativas textuais dos
casos de uso so mais importantes e contm mais informao que os diagramas.
Para cada caso de uso feita uma descrio independente. Cada descrio
dividida em duas partes:
Cabealho; e
Descrio.
Conforme exibido na tabela 4.1, o cabealho possui os seguintes itens:
Nome do caso de uso;
Objetivo: descrio sucinta do objetivo do caso de uso no contexto do sistema;
Pr-condio: as condies que devem existir para que o caso de uso que
est sendo descrito possa ser realizado;
Ps-condio: so as regras cumpridas pelo caso de uso que est sendo descrito e que podem ser utilizadas como pr-condio de procedimentos futuros.
Nome:
Objetivo:
Pr-condio:

Ps-condio

C
A
B
E

A
L
H
O

Tabela 4.1 Formato do cabealho da descrio de casos de uso.

So dois os tipos de descrio de casos de uso, cada um com um objetivo

especfico:
Descrio no expandida; e
Descrio expandida.

captulo 4

65

A descrio no expandida utilizada para descrever requisitos (ou casos de

uso) que so menos complexos, que possuem poucas regras e que no utilizem
mecanismos de outros casos de uso. Outro cenrio que demanda a utilizao deste
tipo de descrio quando o caso de uso de conhecimento de todos os envolvidos.
De forma prtica, a descrio no expandida trata-se de um texto curto que
apresenta de forma sucinta o que o caso de uso deve fazer (seus objetivos). Um
exemplo desta descrio exibido na tabela 4.2.

COMENTRIO
Utilize a descrio no expandida para casos de uso corriqueiros e de fcil entendimento.
Desta forma diminui-se o cansao com leitura excessiva, alm de evitar documentao desnecessria do sistema.

Nome: Cadastrar cliente.

Objetivo: Registrar os dados de um novo cliente.
Pr-condio: No h.

Ps-condio: Efetuar venda.

O cadastro do cliente trata-se da incluso de

seus dados em formulrio e armazenamento das
informaes no sistema.

C
A
B
E

A
L
H
O
D
E
S
C
R
I

Tabela 4.2 Exemplo de descrio de caso de uso no expandida.

A descrio expandida utilizada em casos de uso mais complexos, por se tratar de uma descrio detalhada. Um passo-a-passo da realizao do caso de uso
exibida nesta descrio, que possui seu fluxo normal e seus fluxos alternativos.
O fluxo normal de uma descrio de casos de uso a maneira comum com
que este realizado. Seus fluxos alternativos so acionados caso uma particularidade acontea durante sua realizao.

66

captulo 4

As particularidades ou excees, para que sejam pertinentes, devem ser de

ordem lgica. Uma indisponibilidade no sistema, uma indisponibilidade de
bancos de dados, por exemplo, no so contempladas nesta descrio (exemplos de excees so exibidos na tabela 4.3).
Uma descrio expandida deve contemplar de forma detalhada o fluxo normal e tambm os fluxos alternativos. Um exemplo de descrio de caso de uso
expandida apresentado na tabela 4.3.
Nome: Efetuar venda.
Objetivo: Registrar os dados da venda de produtos a um cliente.
Pr-condio: Ter acesso ao sistema.
Ps-condio: Gerar boleto de cobrana. Produtos sairo do estoque.
Fluxo normal:
1.
Sistema apresenta interface de venda
2.
Vendedor informa produtos a serem vendidos
3.
Sistema obtm dados de produtos
4.
Vendedor escolhe o cliente
5.
Sistema obtm dados do cliente
6.
Vendedor conclui a venda
7.
Sistema registra venda
8.
Sistema inclui Gerar cobrana
9.
Sistema inclui Atualizar estoque
10.
Sistema emite comprovante de venda
11.
Sistema encerra caso de uso
Fluxo alternativo:
4. Vendedor escolhe cliente
4.1 Cliente no cadastrado
4.1.1 Sistema inclui Cadastrar cliente
4.1.2 Sistema retorna para item 5
6. Vendedor conclui venda
6.1 Vendedor cancela venda
6.1.1 Sistema retorna para item 1

C
A
B
E

A
L
H
O

D
E
S
C
R
I

Tabela 4.3 Exemplo de descrio de caso de uso expandida.

A incluso de outros casos de uso pode ocorrer na descrio (como nos itens
8 e 9 do fluxo normal da tabela 4.3), porm as descries destes que esto sendo includos devem ser feitas de forma separada. importante frisar que cada
descrio contempla apenas um caso de uso.

captulo 4

67

Na descrio expandida o sistema quem realiza a primeira e a ltima tarefa, em outras palavras, quem inicia e finaliza o caso de uso o sistema.

CURIOSIDADE
A descrio do caso de uso pode conter um esboo da tela do sistema que ser utilizada para
sua realizao, desta forma, adiciona-se mais valor descrio.

comum que durante a descrio de um caso de uso se identifique a necessidade de criao de novos destes. Quando isto ocorre, necessrio que se
reveja o modelo do software para que este contemple a nova necessidade.

4.2 Diagramas de Interao

Os diagramas de interao modelam a interao entre objetos e seus relacionamentos. Isto inclui as mensagens que podem ser trocadas entre eles (BOOCH;
RUMBAUGH; JACOBSON, 2005).
Cada diagrama de interao contempla apenas um caso de uso, provendo
uma visualizao da interao entre seus objetos.

CONEXO
O site da Microsoft Developer Network traz informaes sobre modelagem de software, apesar de ser direcionado ao uso do software Visual Studio, conceitos so apresentados de
forma didtica e aplicada.
https://msdn.microsoft.com/pt-br/library/dd409445.aspx

So dois os tipos de diagramas de interao:

Diagrama de sequncia; e
Diagrama de comunicao.
De acordo com Booch, Rumbaugh e Jacobson (2005) os diagramas de interao so constitudos basicamente por:

68

captulo 4

 Papis ou objetivos;
Comunicaes ou vnculos; e
Mensagens.
Os diagramas de interao so explicados e exemplificados a seguir.

4.2.1 Diagrama de sequncia

Como visto anteriormente, o diagrama de classes representa os dados do sistema e o diagrama de casos de uso, o uso do sistema. O diagrama de sequncia
tem uma juno destes dois mundos, representando o uso do sistema com relao aos dados que so acessados e como feita a interao entre eles. Este
diagrama pode ser dividido em dois tipos:
Diagrama de sequncia; e
Diagrama de sequncia de sistema.
O diagrama de sequncia de sistema um caso particular de diagrama de
sequncia e explicado logo em seguida ao diagrama de sequncia.
A ordenao temporal o foco do diagrama de sequncia (BOOCH;
RUMBAUGH; JACOBSON, 2005).
Um exemplo simples de diagrama de sequncia exibido na figura 4.1. Podese observar retngulos organizados na horizontal, na parte superior do diagrama,
estes so os objetos que participam da interao. Abaixo de cada objeto, existe
uma linha vertical tracejada chamada de linha da vida. O eixo vertical representa o tempo, portanto, esta linha representa a durao da vida de um objeto.
Cliente1: Cliente

produto1: Produto
1: avalia ()

<<confirmao de avaliao>>

Figura 4.1 Exemplo simples de diagrama de sequncia.

captulo 4

69

Os dois objetos que participam deste diagrama so:

Cliente 1: objeto da classe Cliente; e
Produto 1: objeto da classe Produto.
A seta que parte do cliente para o produto indica a mensagem enviada entre
os dois objetos, enquanto a seta tracejada que parte de produto para cliente
representa a resposta da interao.
Os retngulos observados nas linhas de vida representam a durao das interaes.
O smbolo de destruio do objeto (fim da linha da vida) representado por um X.

CONEXO
O documento em PDF do link apresentado (disponibilizado pela wiki da PUC-RIO traz, em slides, informaes aprofundadas sobre o diagrama de sequncia, com detalhes interessantes).
http://www.les.inf.puc-rio.br/wiki/images/e/ef/Aula02-diagrama_sequencia.pdf

Os objetos podem trocar mensagens de criao e destruio de objetos entre si e uma mensagem pode ser enviada de um objeto para ele prprio. As mensagens so mtodos, onde podem ser passados parmetros para sua execuo.
O exemplo apresentado na figura 4.1, apesar de ser muito simples, d uma
viso de artefatos que podem ser utilizados neste tipo de diagrama.
Um exemplo mais complexo apresentado na figura 4.2, onde se tem includos alguns conceitos como a criao e destruio de objetos e a utilizao de atores (mais informaes sobre os atores so apresentadas no captulo 2 deste livro).

Figura 4.2 Exemplo de diagrama de sequncia.

70

captulo 4

Na figura 4.2 pode-se observar a sequncia de execuo do sistema na ao

de um vendedor para registrar uma venda. A leitura do diagrama feita de cima
para baixo e da esquerda para a direita:
1. Vendedor acessa a interface do sistema;
2. Sistema l a lista de produtos e os exibe ao vendedor;
3. Vendedor escolhe os produtos a serem vendidos;
4. Vendedor escolhe o cliente comprador (neste caso, o sistema ainda no
leu as informaes de cliente);
5. Sistema busca informaes do cliente selecionado e as exibe ao vendedor;
6. Vendedor confirma a venda;
7. Sistema envia mensagem de venda efetuada ao vendedor.
O diagrama de sequncia de sistema representa a interao entre o usurio e
o sistema (entradas e sadas do sistema) de forma semelhante ao diagrama de sequncia, porm, sem detalhar os objetos participantes da realizao do caso de uso.
Um exemplo de diagrama de sequncia de sistema apresentado na figura
4.3, onde o vendedor efetua uma venda utilizando o sistema.
: sistema
vendedor1: Vendedor
1: acessa()

<<lista de produtos>>
2: escolhe produtos ()

3: escolhe cliente ()
<<dados do cliente>>
4: clica em confirmar ()

<<envia confirmao>>

Figura 4.3 Diagrama de sequncia de sistema.

captulo 4

71

Nota-se na figura 4.3 que o diagrama exibe apenas as informaes que entram e saem do sistema, sem detalhamento de quais objetos esto participando, portanto, trata-se de um caso particular de diagrama de sequncia onde
apenas a interao do sistema com o mundo externo modelada.

4.2.2 Diagrama de comunicao

Antigamente chamado de diagrama de colaborao, este diagrama foca na organizao dos objetos participantes de uma interao (BOOCH; RUMBAUGH;
JACOBSON, 2005).
Enquanto o diagrama de sequncia apresenta uma viso da interao ao
longo do tempo, o diagrama de comunicao apresenta uma viso de interao
dos objetos no contexto do sistema.

CURIOSIDADE
Engenharia de produo em desenvolvimento de software fazer a codificao (produto)
a partir de um modelo (projeto). A engenharia reversa criar o modelo (projeto) a partir do
cdigo-fonte (produto). Existem softwares que auxiliam a criao de modelos a partir da
anlise de cdigo-fonte.

A figura 4.4 traz um exemplo de diagrama de comunicao onde um objeto

do tipo Computador envia uma mensagem para a impresso de um arquivo a
um objeto Servidor de Impresso. Caso a impressora esteja ocupada, o Servidor
de Impresso envia uma mensagem para armazenamento do arquivo na fila de
impresso e caso a Impressora (objeto) esteja desocupada, o arquivo enviado
para ela para que seja impresso.

CONEXO
O arquivo disponibilizado no link a seguir, desenvolvido por Aristfanes Corra Silva, possui
uma descrio detalhada sobre os diagramas de comunicao (SILVA, 2015).
http://www.deinf.ufma.br/~acmo/MOO_Com.pdf

72

captulo 4

Apesar de manter o sequenciamento da ordem do envio das mensagens, o diagrama de colaborao no tem o enfoque temporal que o diagrama de sequncia possui.
: Computador
1: imprimir ()

2: [se impressora ocupada] armazenar ()

: ServidorDeImpressora

: FilaDeImpressora

3: [se impressora desocupada] imprimir ()

: Impressora

Figura 4.4 Diagrama de comunicao (ERIKSSON et al., 2004).

Pode-se observar com clareza a interao entre objetos do exemplo da figura

4.4, assim como alguns elementos da notao do diagrama de comunicao.
A ligao entre os objetos feita pela linha slida interligando dois objetos. As mensagens so representadas pelas setas e podem ter respostas (assim
como no diagrama de sequncia). Na realidade, o diagrama de comunicao
tem a notao muito parecida com o diagrama de sequncia, porm, sua formatao um pouco diferente para enfatizar outros aspectos do sistema.

EXEMPLO
Caso um objeto possua muitas entradas, ou seja, receba muitas mensagens de outros objetos, esta representao pode ficar confusa no diagrama de comunicao, pois todas as
mensagens so representadas na mesma ligao. A vantagem de se utilizar o diagrama de
comunicao neste caso ter uma viso abrangente de todas as mensagens enviadas a um
nico objeto sem ter que percorrer toda a linha do tempo do diagrama de sequncia.

4.2.3 Diagrama de estados

Tambm conhecido como mquina de estados, este diagrama utilizado para a
apresentao dos estados que um objeto ou um caso de uso pode assumir, assim

captulo 4

73

como os eventos que fazem com que o estado seja alterado, sendo uma tcnica muito utilizada para tratar as restries do sistema que so impostas pelos requisitos.
O exemplo exibido na figura 4.5 traz um diagrama onde o objeto em questo
pode assumir trs estados. O incio do diagrama representado pela esfera preta, sendo o estado 1 o estado inicial do objeto, antes de qualquer ocorrncia. O
objeto assume o estado 2 quando o evento 1 acontece. O estado final do objeto, representado pela esfera preta com um crculo externo, assumido quando o
evento 2 acontece. H tambm a possibilidade de um objeto retornar ao mesmo
estado (auto-transio). Portanto, este diagrama composto basicamente por:
Incio;
Estado: nome do estado e atividade;
Transio: mudana de estado; e
Fim.

estado 1
entry/ atividade
evento1
estado 2
evento 2

Figura 4.5 Exemplo simples de diagrama de estados.

Um estado, representado por um retngulo, possui duas partes:

Nome do estado;
Atividade: o que est sendo executado enquanto o objeto permanece
no estado;
A descrio das transies dividida em trs partes:
Evento: a ocorrncia para que aquele estado seja alterado;
Guarda: condio lgica que deve ser satisfeita para que o estado
seja alterado;
Ao: procedimento do sistema responsvel por efetivar a alterao de estado.

74

captulo 4

LEITURA
O captulo 22 do livro UML: Guia do Usurio traz uma especificao de mquinas de estados
complexas, com conceitos especficos e avanados sobre o uso deste diagrama, como sub
estados sequenciais, estados concorrentes, entre outros conceitos (BOOCH; RUMBAUGH;
JACOBSON, 2005).

Um exemplo prtico e simples de diagrama de estados exibido na figura

4.6, onde um objeto produto pode assumir trs estados em um sistema.

em estoque
cliente desiste da compra

cliente reserva produto

reservado

cliente compra produto

cliente confirma compra

vendido
produto sai da loja

Figura 4.6 Exemplo prtico de diagrama de estados.

4.2.4 Diagrama de atividade

Os diagramas de atividade so meramente grficos de fluxo e podem remeter a
fluxogramas, porm, uma diferena essencial os distinguem: os diagramas de
atividade podem modelar processos paralelos.
Para melhor entendimento deste diagrama, feita uma discusso sobre o
exemplo apresentado na figura 4.7.

captulo 4

75

Gerente

Vendedor

cadastrar
produto
vender
produto
Cliente no
cadastrado
Cliente cadastrado

cadastrar
cliente

concluir
venda
notificar
gerente

registrar
notificao
de venda

gerar relatrio
para diretoria

Figura 4.7 Exemplo de diagrama de atividade.

Observando a parte de cima da Figura 4.7, temos duas divises chamadas de

raias. Estas raias definem os responsveis pela execuo das aes descritas mais
abaixo. Neste caso, no retngulo da esquerda esto as aes que so executadas
pelo gerente e direita as aes executadas pelo vendedor.
As aes so os blocos em maior nmero no diagrama apresentado (Figura
4.7), os quais so executados em sequncia partindo do incio (esfera preta) ao fim
(esfera preta com crculo externo). A sequncia dada pelas setas indicando qual
seria a prxima ao a ser executada.

76

captulo 4

As ramificaes sequenciais, tambm denominadas ns de deciso, so representadas por um losango e so utilizadas para definir qual ao ser tomada
dependendo de uma condio. No caso do exemplo da Figura 4.7, a condio o
cliente estar ou no cadastrado no sistema. O losango pode tambm representar
intercalao, com o objetivo de unir sadas de aes, assim como feito antes da
concluso da venda.
As bifurcaes concorrentes e unies concorrentes so representadas por
barras onde, a prxima ao s executada aps todas as aes da bifurcao
serem executadas. Neste caso (Figura 4.7), a atividade s finalizada quando ambas aes descritas na bifurcao forem completamente executadas (o registro da
notificao da venda e a emisso do relatrio para a diretoria).

ATIVIDADES
Responda s seguintes questes:
01. Sobre casos de uso, geralmente qual detm maior quantidade de informao, o diagrama ou a descrio?
02. Cite uma vantagem de se utilizar diagrama de sequncia ao invs do diagrama
de comunicao.
03. Como eram conhecidos os diagramas de comunicao?
04. Qual a principal diferena entre um diagrama de atividade e um fluxograma?

REFLEXO
Este captulo abordou uma grande quantidade de informao sobre modelagem de software.
Primeiramente foi apresentada a descrio de casos de uso e pde-se observar que o nvel
de detalhamento aumenta consideravelmente quando se opta por fazer a descrio estendida. Refletindo sobre algo que foi dito no incio do livro, no comum que se utilize de todos
os diagramas ao modelar software, porm uma viso abrangente e conhecimento sobre os
modelos pode trazer qualidade modelagem, pois a chance de serem selecionados diagramas que representem melhor o que se quer modelar maior.

captulo 4

77

LEITURA
O quinto captulo do livro UML 2 Toolkit aborda modelagem dinmica, que trata tambm
dos diagramas apresentados neste captulo. Alguns exemplos e aprofundamento podem ser
encontrados nesta leitura altamente recomendada.
ERIKSSON, Hans-erik et al. UML 2 Toolkit. Indianapolis: Wiley, 2004.

REFERNCIAS BIBLIOGRFICAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 2. ed. Rio de Janeiro:
Campus, 2005.
ERIKSSON, Hans-erik et al. UML 2 Toolkit. Indianapolis: Wiley, 2004.
LARMAN, Craig. Utilizando UML e Padres: Uma introduo anlise e ao projeto orientados a
objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007.
SILVA, Aristfanes Corra. Unified Modeling Language (UML). Disponvel em:
<http://www.deinf.ufma.br/~acmo/MOO_Com.pdf>. Acesso em: 16 out. 2015.

78

captulo 4

5
Diagrama de
Classe de Projeto
e Diagrama de
Implementao

Chegamos ao ltimo captulo do livro de modelagem de sistemas. Aqui, abordado o diagrama de classes de projeto, que uma derivao do diagrama de
classes j apresentado no captulo 3 (inclusive sua apresentao teve alguns aspectos de projeto embutidos). Este diagrama, diferentemente do diagrama de
classes conceitual j visto, enfoca na implementao do sistema e no em sua
lgica de negcios. Porm, o entendimento do diagrama de classes conceitual
de suma importncia para que se possa transferir seus conceitos para o diagrama de classes de projeto.
O aspecto fsico da modelagem de sistemas tambm abordado neste captulo, onde so enfatizados itens fsicos da implementao e implantao do
software a ser desenvolvido.
Espero que tenha absorvido os conceitos apresentados at aqui e que este
ltimo captulo lhe fornea uma viso de programao do software aliada
modelagem.

OBJETIVOS
Ao final deste captulo, o aluno conhecer:
Diagrama de classes de projeto;
Diagrama de componentes; e
Diagrama de implantao.

80

captulo 5

5.1 Diagrama de classe de projeto

No captulo 3 so apresentados os diagramas de classe, porm de uma forma
conceitual (modelo de domnio). Os diagramas de classe de projeto so derivados do modelo de domnio, sendo definidos como um diagrama de classes na
viso de implementao.
As classes de projeto abordam:
As classes;
As associaes;
Os atributos;
As interfaces;
Os mtodos;
O tipo dos atributos;
A visibilidade dos atributos;
A navegabilidade entre objetos; e
A dependncia.
Estes itens no so necessrios no diagrama de classes (modelo de domnio), apesar de terem sido apresentados juntamente com estes no captulo 3.

CONCEITO
O diagrama de classes (modelo de domnio) apresenta os objetos do sistema dentro de uma
viso lgica, representando as funcionalidades do sistema independente de tecnologia. As
classes de projeto representam um modelo dependente de tecnologia, com a adio de itens
que so pertinentes implementao do software.

Pelo fato dos diagramas de classe de projeto serem dependentes de tecnologia, necessrio adotar uma para que se possa desenvolver os modelos. Neste
captulo, subentende-se que o projeto desenvolvido utilizando a linguagem
de programao Java.
Vale a pena relembrar os tipos de atributos que vamos utilizar nos diagramas apresentados:
String: atributo do tipo texto;
Integer: atributo do tipo nmero inteiro;

captulo 5

81

 Float: atributo do tipo nmero real;

Date: utilizado para datas;
As atividades da fase de projeto, de acordo com Bezerra (2007), so
as seguintes:
Definio detalhada de aspectos dinmicos do sistema;
Aprimoramento de aspectos estticos e estruturais do sistema; e
Detalhamento e definio de outros aspectos da soluo.
Algumas dessas etapas so cumpridas nos diagramas de interao, outras
no diagrama de classe de projeto.

CURIOSIDADE
O diagrama de classes de projeto possui informao suficiente para a criao do banco de
dados do sistema, portanto, pode ser utilizado para este fim.

O diagrama de classes de projeto aborda um tipo especfico de classe: as

classes de fronteira. Estas classes so representaes da interao do sistema
(formulrios, atores, outros sistemas, entre outros) e no devem conter lgica
de negcio embutida. comum que se tenha uma classe de fronteira para cada
ator participante do caso de uso, porm podem ter casos em que sero necessrias mais de uma classe ou at modelos de subsistemas (BEZERRA, 2007).
As classes de entidade so basicamente as classes do modelo conceitual
apresentado no captulo 3. Estas classes modelam a lgica de negcio do sistema e geralmente so transportadas para o modelo de classes de projeto sem
grandes alteraes.
Um exemplo de diagrama de classe de projeto apresentado na figura
5.1, onde se modela um caso de uso de registro de emprstimo de livro em
uma biblioteca.

82

captulo 5

Usurio
Formulrio
- cpf: String
- isbn: String

identifica

+ registrarEmprestimo (): void

captura

Livro

- cpf: String
- nome: boolean
- dataNascimento: String
+ ler (): Usuario
+ incluir (): void
+ atualizar (): void
+ remover (): void

Emprtimos

- isbn: String
- titulo: String
- exemplares: Integer
+ ler (): Livro
+ incluir (): void
+ atualizar (): void
+ remover (): void

- cdigo: Integer
- dataEmprestimo: Date
- dataDevolucao: Date
- dataDevolvido: Date
+ registrar (): void
+ ler (): Empretimo

Autor
- cdigo: Integer
- nome: String
- citao: String
+ ler (): Autor

Figura 5.1 Diagrama de classes de projeto de um sistema de registro de emprstimos

de livros.

No exemplo da figura 5.1, a classe Emprstimo pode ser considerada uma

entidade associativa, pois est entre o relacionamento de usurio com livro
(usurio empresta livro), sendo que um usurio pode emprestar vrios livros e
um livro pode ser emprestado a vrios usurios.
As setas entre as classes indicam a visibilidade entre os objetos. A seta que
parte de Autor para Livro indica que autor enxerga livro, em outras palavras, a informao identificadora de Livro adicionada ao objeto Autor.
Podemos definir tambm que na implementao, a classe Autor possui um
objeto da classe Livro como atributo. No modelo conceitual, neste caso especfico, a modelagem mostra que um autor pode escrever apenas um livro, mas
um livro pode possuir vrios autores.

captulo 5

83

No caso da classe associativa Emprstimo, pode-se afirmar que esta possui um objeto da classe Livro e um objeto da classe Usurio como atributos.
Segundo a visibilidade de objetos, pode-se afirmar que Emprstimo enxerga
Usurio e Livro.

CURIOSIDADE
Do ponto de vista de implementao, pode-se utilizar listas de objetos para facilitar o desenvolvimento, como no exemplo da Figura 5.1, pode-se ter uma lista de objetos da classe
Autor como atributo da classe Livro.

Para que um objeto possa enviar mensagens a outro, este destinatrio deve
ser visvel ao remetente. A visibilidade pode ser conseguida de quatro maneiras:
1. Por atributo: quando uma classe detm um objeto de outra como seu
atributo, assim como apresentado no exemplo da figura 5.1.
2. Por parmetro: quando um objeto de uma classe parmetro de algum
mtodo de outra. Se uma classe A possui um mtodo que recebe um objeto da
classe B como parmetro, ento B visvel para A.
3. Declarao local: quando um objeto de uma classe declarado como
varivel local em um mtodo de outra. Se a classe A possui um mtodo e, neste
mtodo, declarado um objeto da classe B, ento B visvel para A. Este mtodo muito utilizado com listas, inclusive resultados de pesquisas em bancos
de dados.
4. Visibilidade global: quando uma varivel, objeto de uma classe, visvel globalmente no sistema. Deste modo, visvel para todos os outros objetos.
A navegabilidade indica a associao unidirecional, ou seja, a navegao de
um objeto de origem para o objeto-alvo. A navegao s permitida se o objeto
-alvo for visvel, portanto, a rota de navegao dada pela seta de visibilidade.
No exemplo da figura 5.1, podemos interpretar a navegabilidade entre
Emprstimo e Livro como: um Emprstimo possui um Livro.
O conceito de dependncia, explicado no item 3.2.5 deste livro, utilizado
em diagramas de classes de projeto. A dependncia indica que um objeto tem
conhecimento de outro por um curto prazo e associado visibilidade por parmetro, por definio local ou por definio global.

84

captulo 5

A cardinalidade dos relacionamentos no diagrama de classes conceitual

utilizada para checar a navegabilidade entre as classes:
Em relacionamentos onde a cardinalidade de 1 para muitos (de um lado
a cardinalidade mxima 1 e do outro *), o lado onde aparece o asterisco possui um objeto da classe em que est se relacionando (vide figura 5.2);
Em relacionamentos de onde a cardinalidade de 1 para 1, a navegabilidade acontece a gosto do analista, pois geralmente irrelevante qual classe
possuir um objeto de seu relacionamento como atributo.
Em relacionamentos onde a cardinalidade de muitos para muitos, utiliza-se uma classe associativa que possui um objeto de cada classe relacionada
(vide figura 5.3).
Conceitual
Funcionrio

Setor
*

Trabalha em

Projeto
Funcionrio

Setor

Figura 5.2 Exemplo de relacionamento de um para muitos.

Conceitual
Funcionrio

Setor
Trabalha
Trabalha

Projeto
Funcionrio

Setor

FuncionarioSetor

Figura 5.3 Exemplo de classe associativa em diagrama de classes de projeto.

No conceito de herana, h trs formas ou abordagens das classes envolvidas serem transportadas para o diagrama de classes de projeto:
Criando todas as classes envolvidas;
Criando apenas a classe pai;
Criando apenas as classes filhas;

captulo 5

85

A figura 5.4 exibe um exemplo de herana no diagrama de classes conceitual

para que em seguida sua utilizao no diagrama de classes de projeto seja explicada para cada uma das trs abordagens.
Funcionrio

Diretoria

Gerncia

Operao

Figura 5.4 Exemplo de herana em um diagrama de classes conceitual.

A primeira abordagem melhor utilizada quando todas as classes possuem

relacionamentos especficos com outras classes e seus atributos so bem distribudos, isto , as classes possuem um nmero parecido de atributos. Neste caso,
o diagrama de classes de projeto possuiria as quatro classes: Funcionrio,
Diretoria, Gerncia e Operao. Cada classe possuir seus atributos e
seus mtodos, assim como seus relacionamentos especficos.
A segunda abordagem a criao apenas da classe pai (neste caso, a classe Funcionrio). Ao utilizar esta abordagem, apenas uma classe aparece no
diagrama de classes de projeto, isto , apenas uma tabela criada no banco de
dados. Esta classe deve conter todos os seus prprios atributos, mtodos e relacionamentos, como tambm todos os atributos, mtodos e relacionamentos de
cada um dos seus filhos. Este caso bem empregado quando se tem uma grande quantidade de atributos e relacionamentos na classe pai e poucos atributos
e relacionamentos nas classes filhas.
A terceira abordagem a criao apenas das classes filhas. Nesse caso (figura 5.4), as classes que apareceriam no diagrama de classes de projeto so:
Diretoria, Gerncia e Operao. No banco de dados deste sistema, estariam implementadas apenas trs tabelas, uma para cada classe. Cada classe
deve conter seus atributos, mtodos e relacionamentos e tambm os atributos,
mtodos e relacionamentos da classe pai.

86

captulo 5

CURIOSIDADE
comum que se utilize a abordagem de criao de todas as classes (primeira abordagem)
para a implementao no sistema, porm no banco de dados isto varia com mais frequncia.

Outro conceito utilizado em diagramas de classes de projeto so as interfaces. Estas no podem ser confundidas com as interfaces grficas do sistema,
pois so aes que um objeto pode realizar dentro de um sistema especfico.
Na figura 5.5 tem-se um exemplo de interface em um diagrama de classes
de projeto.
<<interface>>
Tributvel
calcularTributacao (): Float

Salrio
valor: Float
calcularTributacao (): Float

Benefcio
valor: Float

Figura 5.5 Exemplo de interface em diagrama de classes de projeto.

Quando uma classe realiza a ao de uma interface, diz-se que esta classe
implementa tal interface. Portanto, no exemplo da figura 5.5, pode-se dizer
que a classe Salrio implementa a interface Tributvel, enquanto a classe
Benefcio no.
Uma interface contm um conjunto de mtodos (aes), porm, estes mtodos no so implementados pela interface. O que acontece que a interface
possui apenas a assinatura destes mtodos, em outras palavras, ela descreve o
que fazer, mas no como faz-lo.
A implementao dos mtodos da interface de responsabilidade das classes que a implementam e esta implementao deve ser feita utilizando a assinatura idntica a que apresentada na interface, inclusive tipos de parmetros
e de retorno. Neste caso, no exemplo da Figura 5.5, a implementao de como

captulo 5

87

 calculada a tributao (mtodo calcular Tributao) de responsabilidade

da classe Salrio.
A classe benefcio no tem a obrigao de implementar o (mtodo calcular
Tributao) pois esta no implementa a interface Tributvel.
Para a indicao de uma implementao entre uma classe e uma interface
utiliza-se de uma seta tracejada com a ponta vazada, esta seta parte da classe
para a interface (assim como demonstrado na Figura 5.5).
Pode-se dizer, utilizando o conceito de interface, que o salrio tributvel e
o benefcio no tributvel.

5.2 Diagramas de implementao

Estes diagramas modelam aspectos fsicos e descrevem hardware e software
que cercam a implementao de um sistema. So abordados dois tipos de diagramas de implementao, pertencentes UML:
Diagrama de componentes; e
Diagramas de implantao.
A seguir, estes dois diagramas so explicados e discutidos.

5.2.1 Diagrama de componentes

O diagrama de componentes utilizado para modelar itens fsicos que podem
residir em um n, como exemplo tem-se:
Arquivos executveis;
Bibliotecas;
Documentos;
Tabelas; arquivos em geral.
O componente a menor representao de um programa, portanto, necessrio que se estabelea a modelagem fsica do sistema executvel, que pode ser
um conjunto de programas.
De acordo com Booch, Rumbaugh e Jacobson (2005), estes diagramas mostram as dependncias entre os diversos componentes de um software, inclui-se
desta forma:

88

captulo 5

 Componentes de cdigo-fonte;
Componentes de cdigo binrio; e
Componentes executveis;
Pode-se definir este diagrama como um grafo de componentes conectados
por relacionamentos de dependncia.

CONEXO
Grafos so definidos de forma terica no link a seguir, disponibilizado pela Universidade
Federal de Santa Catarina:
http://www.inf.ufsc.br/grafos/definicoes/definicao.html

A notao deste diagrama possui trs smbolos:

Componente (vide figura 5.6);
Interface; e
Dependncia.
Componente
Figura 5.6 Exemplo de componente.

Um exemplo didtico deste diagrama apresentado na Figura 5.7.

Lanamento
de notas

Interface 1

Interface 1

Interface 1

Alunos

Professores

Turmas

Figura 5.7 Exemplo didtico de diagrama de componentes.

captulo 5

89

No exemplo apresentado na figura 5.7, o componente Lanamento de

notas dependente das interfaces fornecidas pelos componentes Alunos,
Professores e Turmas. Isto significa que para as notas serem lanadas no
sistema, os alunos, professores e as turmas devem estar disponveis.
Outro exemplo, agora mais prtico e adaptado de Fowler (2005), apresentado na figura 5.8. Neste exemplo pode-se observar um diagrama de componentes onde um caixa efetua uma venda em uma loja.
Caixa

Tela do Sistema
Servio de Vendas
Processador de Transaes

Driver de Contabilidade

Figura 5.8 Exemplo de diagrama de componentes (adaptado de FOWLER, 2005).

Ao observar a figura 5.8, um componente Caixa, para efetuar uma venda,

requerida uma interface fornecida pelo componente Servidor de Vendas. Os
componentes citados Processador de Transaes e Driver de Contabilidade
so parte do componente maior, o Servidor de Vendas. O processador de
transaes, por sua vez, dependente do driver de contabilidade, que far os
clculos necessrios para a transao da venda.

5.2.2 Diagramas de implantao

De acordo com os criadores da linguagem UML, os diagramas de implantao
so empregados para a modelagem de uma viso esttica do sistema, envolvendo inclusive a topologia de hardware na qual o sistema executado. Este diagrama tem como objetivo visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribudos (BOOCH; RUMBAUGH; JACOBSON, 2005).

90

captulo 5

CONCEITO
Um sistema embutido uma coleo complexa de software para o hardware que interage
com o mundo fsico. Os sistemas embutidos envolvem software que controla dispositivos
como motores, atuadores e monitores e que, por sua vez, controlado por estmulos externos
como entrada de um sensor, movimentao e mudana de temperatura. (BOOCH; RUMBAUGH; JACOBSON, 2005)

CONCEITO
O sistema cliente/servidor uma arquitetura comum, cujo foco a criao de uma clara
separao de questes entre a interface para o usurio (que vive no cliente) e os dados
persistentes no sistema (que vive no servidor). (BOOCH; RUMBAUGH; JACOBSON, 2005)

CONCEITO
Sistema distribudo
Um sistema distribudo um conjunto de computadores independentes que se apresenta
a seus usurios como um sistema nico e coerente (TENENBAUM; VAN STEEN, 2007)

Os diagramas de implantao mostram a configurao de ns de processamento em tempo de execuo e seus componentes. Os componentes que no
existem em tempo de execuo no so abordados por estes diagramas.
Basicamente, o diagrama de implantao um grafo de ns conectados
por associaes de comunicaes. A representao de um n neste diagrama
apresentada na figura 5.9.
N

Figura 5.9 Exemplo de representao de n em um diagrama de implantao.

captulo 5

91

Os ns geralmente so:
Computadores;
Impressoras;
Leitores de carto;
Dispositivos de comunicao;
Entre outros.
Na figura 5.10 apresentado um exemplo de diagrama de implantao simplificado e didtico. Neste exemplo, um cliente acessa um servidor de aplicao na internet por meio do protocolo HTTP (Hyper-Text Transfer Protocol),
enquanto este servidor faz o acesso ao banco de dados para coletar e gravar informaes.
O banco de dados do sistema modelado possui um sistema gerenciador
(SGBD) e a unidade de persistncia (os dados propriamente ditos). A persistncia destes dados dependente do sistema gerenciador, pois ele quem controla as transaes.
O sistema tambm possui uma impressora, que acessada pelo cliente via
rede local (LAN)
Cliente: Browser

Servidor de Aplicao
<<HTTP>>

<<ODBC>>
<<LAN>>

Banco de Dados
SGBD

Impressora
Persistncia

Figura 5.10 Exemplo de diagrama de implantao.

92

captulo 5

ATIVIDADES
01. Qual o foco do diagrama de classes de projeto para modelagem de sistemas?
02. Pensando em um sistema fictcio e puramente didtico, faa um diagrama de classes
de projeto com apenas duas classes: Elefante e Urubu, onde uma delas deve implementar
uma interface chamada Voador, que define o mtodo voar.
03. D trs exemplos de itens que podem ser representados por ns em diagramas
de implementao.

REFLEXO
Os modelos de classes de projeto so uma alternativa muito rica para modelagem de software visando a implementao do cdigo-fonte, assim como os modelos de implementao
trazem aspectos prticos da especificao fsica do funcionamento e implantao do software como produto.
importante lembrar que os modelos podem ter diferentes nveis de abstrao e detalhamento, portanto, devem ser definidos pelo analista conforme a necessidade.

LEITURA
No stimo captulo do livro Engenharia de Software: uma abordagem profissional de Roger
S. Pressman (PRESSMAN, 2011) abordada modelagem de software especfica para aplicaes web.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto
Alegre: Amgh, 2011.

REFERNCIAS BIBLIOGRFICAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 2. ed. Rio de Janeiro:
Campus, 2005.

captulo 5

93

FOWLER, Martin. UML Essencial: Um breve guia para a linguagem-padro de modelagem de objetos.
3. ed. Porto Alegre: Bookman, 2005.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto Alegre:
Amgh, 2011.
TENENBAUM, Andrew S.; VAN STEEN, Maarten. Sistemas Distribudos: princpios e paradigmas. 2.
ed. So Paulo: Pearson Prentice Hall, 2007.

GABARITO
Captulo1
01. A primeira desvantagem que pode ser citada que se ocorrer algum erro de especificao do software, necessrio que se retorna ao ponto de especificao para que este seja
refeito, o que reflete em retrabalho tambm nas prximas etapas. Uma segunda desvantagem pode ser a entrega do produto pronto, pois o cliente pode identificar erros na execuo,
e ento o projeto todo deve ser revisado.
02. Neste tipo de sistema pode-se identificar uma srie de classes. Para citar apenas duas,
podem ser escolhidas a classe Cliente e a classe Carro.
03. Na adoo de metodologia gil de desenvolvimento de software, comum utilizar o
processo incremental.

Captulo2
Existem diversas maneiras de se especificar software em diagramas de casos de uso, com
diferentes nveis de detalhamento. Uma delas apresentada a seguir:
proteger material

<<extend>>

cadastrar material
professor
<<include>>

checar extenso de arquivo

94

captulo 5

<<include>>

verificar vnculo

Captulo3
O diagrama de classes representa a estrutura lgica do sistema, e desta forma, um sistema
bem simplificado de uma instituio bancria abrangendo apenas cliente, conta e gerente
pode ser como a seguir:

Cliente

Conta
1

PessoaFisica

tem

1..*

1..*

gerencia
1
Gerente

Pessoa Juridica

Neste modelo, um cliente pode ser de dois tipos: pessoa fsica ou pessoa jurdica e ambos
podem ter contas bancrias. Uma conta bancria pode ser de apenas um cliente. Um gerente
pode gerenciar diversas contas, porm, uma conta s pode ter um gerente.
Esta modelagem pode variar conforme interpretao e lgica de negcios, portanto, variaes podem estar corretas.

Captulo4
01. A descrio de casos de uso detm mais informao, por descrever a realizao do
caso de uso passo a passo, provendo inclusive informaes sobre os fluxos alternativos que
podem ocorrer em uma realizao.
02. O diagrama de sequncia pode ser utilizado em casos que o processo precisa ser
analisado de forma temporal, ou seja, identificar a sequncia das mensagens trocadas entre objetos.
03. Antigamente, os diagramas de comunicao eram conhecidos como diagramas de
colaborao (at a verso 1.5 da UML). A partir da seu nome foi alterado para diagrama
de comunicao.
04. A principal diferena entre um diagrama de atividade e um fluxograma que o diagrama
de atividade capaz de implementar processos paralelos.

captulo 5

95

Captulo5
01. O foco do diagrama de classes de projeto na implementao do sistema, definindo
tipos de variveis, mtodos, entre outros termos. Isto o torna dependente de tecnologia.
02. Um modelo bsico que satisfaz o que pedido na questo exibido abaixo:

<<interface>>
Voador
voar(): void

Urubu

Efefante

voar(): void
03. Trs dos itens que podem ser representados por ns nestes diagramas podem ser:
a) computadores (como processadores);
b) impressoras; e
c) dispositivos de comunicao.

96

captulo 5