erir Título Aqui Modelagem de Sistemas Orientada a Objetos part 2

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Modelagem de Sistemas 
Orientada a Objetos
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Responsável pelo Conteúdo:
Prof. Me. Artur Ubaldo Marques Júnior
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução;
• Diagrama de Classe;
• Diagrama de Atividade;
• Diagrama de Máquina de Estado;
• Diagrama de Sequência.
Fonte: iStock/Getty Im
ages
Objetivos
• Compreender a sistematização da linguagem universal de modelagem
• Identificar os artefatos chave para desenvolvimento da modelagem.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Métodos de Desenvolvimento 
de Sistemas Orientados a Objetos 
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Contextualização
A UML como linguagem de modelagem de software orientado a objetos é mais que 
um idioma, trata-se de um padrão mundial de designação de artefatos que vão ajudar 
você a planejar seu software antes de escrever a primeira linha de código.
Como motivador, ofereço este vídeo curto que conta um pouco da história da UML 
de forma rápida e de fácil compreensão para que possamos entrar de cabeça na expli-
cação e uso desses diagramas.
Este vídeo intitulado UML - Linguagem de Modelagem Unificada, de autoria de Daniel 
Santos da Costa e Paulo Santos de Jesus, de fácil assimilação e usa linguagem simples.
Disponível em: https://youtu.be/7afWiUDiHqs
Assim, iniciaremos nossa caminhada pela UML para podermos trabalhar com mode-
lagem software orientado a objeto de maneira fundamentada, entendendo o divisor de 
aguas que a UML trouxe para o mundo da engenharia e desenvolvimento de software.
6
7
Introdução
UML - Unified Modeling Language ou em português, Linguagem de Modelagem 
Unificada, veio suceder uma grande quantidade de formas de análise de projetos OO e 
que apareceram entre fim da década de 1980 até meados da década de 1990.
Unificou os modelos desenvolvidos por Booch, Jacobson, Coad/Yourdon, Shlaer-
-Mellor, Rumbaugh e Wirfs-Brock num grupo coeso de artefatos focados em OO.
UML é nos dias atuais um padrão mantido pela OMG, portanto é considerada o 
padrão para modelagem de sistemas. Com ela é possível a visualização, construção, 
especificação e documentação de artefatos de software, combinando aspectos como: 
negócios, dados, objetos e componentes entre outros.
Trata-se de uma linguagem visual. No final de 1997 virou padrão da OMG e vem sen-
do sustentada até hoje com melhorias e extensões, tendo uma aceitação praticamente 
unanime entre os gestores e desenvolvedores de software em geral.
Objetivos da UML, segundo a própria OMG em sua página uml.org, é:
 · visualizar sistemas orientados a objetos;
 · especificar sistemas orientados a objetos;
 · construir sistemas orientados a objetos;
 · documentar sistemas orientados a objetos.
Lembrando que OO nada mais é que tática para instituir coleções de objetos que 
interagem entre si, produzindo sistemas através da combinação de condutas e dados.
Para tanto, o objeto que poderá formar uma classe deve possuir um estado, uma con-
duta (comportamento) e uma identidade unívoca. Dessa forma, podemos entender um 
sistema OO como uma coleção de objetos que se inter-relacionam com comportamen-
tos conhecidos e que utilizam interfaces para cumprirem seus objetivos e colaborando 
entre si, atendendo aos objetivos ou objetivo do próprio sistema de software.
Dessa maneira, quais são os diagramas existentes em UML:
 · Estruturais ou Estáticos:
 » Diagrama de classes;
 » Diagrama de estrutura composta;
 » Diagrama de objetos;
 » Diagrama de componentes;
 » Diagrama de distribuição;
 » Diagrama de pacotes.
 · Comportamentais ou Dinâmicos:
 » Diagrama de atividades;
7
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
 » Diagrama de casos de uso;
 » Diagrama de máquina de estados;
 » Diagrama de interação:
 ▫ Diagrama de sequência;
 ▫ Diagrama de colaboração;
 ▫ Diagrama de Tempo;
 ▫ Diagrama Geral de Interação.
Graficamente essa hierarquia pode ser mais bem visualizada na figura 1, logo abaixo:
Diagram
Structure
Diagram
Class
Diagram
Component
Diagram
Deployment
Diagram
Package
Diagram
Interaction
Diagram
Sequence
Diagram
Communication
Diagram
Timing
Diagram
Interaction
Overview
Diagram
Composite
Structure
Diagram
Object
Diagram
Activity
Diagram
Use Case
Diagram
State Machine
Diagram
Behaviour
Diagram
Figura 1 – Tipos de Diagrama UML
Devemos utilizar sempre todos os 14 diagramas da UML 2.0? Não, claro que não. 
De forma geral, para você entender quais os diagramas mais utilizados, colocamos um 
gráfico para ver o peso de cada um no ambiente de desenvolvimento da modelagem 
orientada a objeto.
Uso dos diagramas da UML: https://goo.gl/ZVuUBZ
O diagrama central da UML é o diagrama de partida da MOO, ou seja, o diagrama de 
Classe, seguido por: diagrama de atividade, diagrama de sequência, diagrama de caso de 
uso e diagrama de máquina de estado, de onde tomamos a seguinte conclusão de que, 
via de regra, esses são os diagramas utilizados, em geral, em projetos de Modelagem 
Orientada a Objetos:
 · Classe;
 · Caso de uso;
 · Sequência;
8
9
 · Atividade;
 · Máquina de estado.
Os outros são importantes, todavia, dependem do tipo de modelagem que você está 
realizando e precisará de mais ou menos detalhamento ou artefatos. Mas, para poder-
mos trabalhar, temos o necessário inicialmente.
Se você duvida do que escrevemos, saiba que, Grady Booch, o mais influente e tam-
bém um dos desenvolvedores mais importantes da UML, afirmou que: “Para 80% de 
todos os softwares, apenas 20% da UML é necessária”. Bom, logo acima colocamos os 
20% necessários.
Vamos apresentar rapidamente cada um deles e nos deteremos naqueles que vere-
mos nesta unidade. UML é extensa e complexa, devemos segmentar seguindo certa 
ordem construtiva.
Diagramas de estrutura: destacam o que as coisas DEVEM SER no sistema.
 · Classe: descreve a estrutura, mostrando as classes do sistema, atributos e 
relações;
 · Componentes: descreve a divisão do sistema em componentes e as depen-
dências entre eles;
 · Estrutura Composta: descreve a parte interior de uma classe e colaborações 
possíveis com essa estrutura;
 · Implantação: modela o hardware para as implementações, bem como os 
ambientes onde será rodado o sistema;
 · Objeto: da visão total ou parcial do arcabouço do sistema em um momento 
particular;
 · Pacote: mostra a divisão de agrupamentos lógicos no sistema, chamados de 
pacotes, mostrando as dependências entre eles.
Diagramas de comportamento: são focados no que deve acontecer no sistema.
 · Atividade: apresenta passo a passo os fluxos de trabalho dos componentes 
em um sistema. Foca no fluxo geral de controle;
 · Maquina de Estado: apresenta os estados do sistema e como ele pode mudar;
 · Caso de Uso: visualização da funcionalidade entregue em termos de atores, 
objetivos e dependências entre eles. Abordaremos esse diagrama separada-mente devido a sua complexidade.
Diagramas de interação: focam no fluxo de controle e dados entre as coisas no sistema.
 · Sequência: apresenta a forma de comunicação entre os objetos em termos 
de sequência de mensagens. Além disso, permite saber o tempo de vida (du-
ração) dos objetos através dessas mensagens;
 · Comunicação: foca nas interações entre objetos ou partes, ou seja, sequên-
cia de mensagens. São uma combinação de dados concatenados da Classe, 
9
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Sequência e Caso de Uso. A partir da estrutura estática, descreve a dinâmica;
 · Visão de Interação: considerado um tipo de diagrama de atividade em que 
os nós representam interações;
 · Tempo: foco está nas restrições de tempo.
Diagrama de Classe
Conforme mencionado por BELL (2004), o diagrama de classe fornece um conjunto 
inicial de elementos de notação que todos os outros diagramas de estrutura usam.
Ele foca na representação dos tipos que modelarão um software, por exemplo, a 
própria classe, interface, dados e componentes, sendo que esses tipos mencionados 
recebem o nome de classificadores.
Sample Class Diagram
Super 
class
Customer Order
1 n
Generalization
Sub class
NormalOrderSpecialOrder
name: String
location: String
sendOrder()
receiveOrder()
date:Date
number:String
date:Date
number:String
date:Date
number:String
con�rm()
close()
con�rm()
close()
dispatch()
con�rm()
close()
dispatch()
receive()
Figura 2 – Exemplo de Diagrama de Classes - UML
Como você pode verificar nos diagramas acima, a representação de uma classe é um 
retângulo contendo 3 compartimentos verticais:
 · compartimento superior mostra o nome da classe;
 · compartimento do meio lista os atributos da classe;
 · compartimento inferior lista as operações da classe.
10
11
Além disso, há os parâmetros de visibilidade de um membro, ou seja, atributo ou 
método, para tanto usamos as notações abaixo.
 + Público
 - Privado
 # Protegido
 / Derivado (pode ser combinado com um dos outros)
 ~ Pacote
 * Aleatória
Para relacionarmos uma classe com outra, podemos utilizar os seguintes tipos de ligação:
Figura 3 – Exemplo de Diagrama de Classes - UML
Alguns propósitos de um diagrama de classes:
 · analisar e desenvolver a visão estática de uma aplicação;
 · engenharia avançada e reversa;
 · servir de base para diagramas de componentes e implementação;
 · descrever as responsabilidades de um sistema.
11
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Há também os indicadores de multiplicidade que devem ser postos em cada classe 
para poderem indicar a implicação entre uma classe e outra, ou seja, sua multiplicidade 
de associação. As possibilidades são demonstradas na tabela 1
Tabela 1 – Tabela de tipos de multiplicidade de implicações entre classes – UML com exemplo
Indicador Significado
0..1 Zero ou um
1 Apenas um
0 .. * Zero ou mais
1 .. * Um ou mais
n Apenas n (onde n > 1)
0.n Zero para n (onde n > 1)
1.n Um para n (onde n > 1)
Class A
multiplicity A
role A role B
label multiplicity B
Class B
Descrevemos abaixo, na forma de tabela, com exemplos, todos os relacionamentos 
entre classes que poderão ser utilizados para a modelagem inicial orientada a objeto.
Tabela 2 – Tabela de tipos de relacionamentos em classes – UML com exemplos
ASSOCIAÇÃO bidirecional: é uma ligação entre duas classes. Uma associação bidirecional é indicada por uma linha sólida 
entre as duas classes. Em qualquer extremidade da linha, você coloca um nome de função e um valor de multiplicidade.
Person 0..* 0..*subscribes
+ subscribes + subscribes magazine
Magazine
ASSOCIAÇÃO unidirecional: é desenhada como uma linha sólida com uma ponta de seta aberta (não a ponta de seta 
fechada ou triângulo, usada para indicar herança) apontando para a classe conhecida. As classes contidas não possuem 
uma forte dependência de ciclo de vida no contêiner. O conteúdo do contêiner ainda existe quando o contêiner é destruído
0..*
overdrawnAccounts
OverdrawnAccountsReport BankAccount
owner : String
balance : Dollars
deposit ( amount : Dollars )
withdrawal ( amount : Dollars )
generatedOn : Date
refresh ( )
CLASSE DE ASSOCIAÇÃO: uma classe de associação é representada como uma classe normal. A diferença é que a linha de 
associação entre as classes primárias intercepta uma linha pontilhada conectada à classe de associação.
�ights
passengers
Flight
MileageCredit
0..*
0..*
FrequentFlyer
	rstName : String
lastName : String
frequentFlyerNumber : String
�ightNumber : Integer
departureTime : Date
�ightDuration : Minutes = 60
baseMiles : Integer
bonusMiles : Integer
delayFlight ( numberOnMinutes : Minutes )
getArrivalTime ( ) : Date
AGREGAÇÃO: é uma associação que representa um relacionamento parcial ou total. Uma agregação não pode envolver 
mais de duas classes; deve ser uma associação binária.
Professor 1 1..*
+ listOfStudents : list
Class
+ Students : list
12
13
COMPOSIÇÃO: às vezes, um objeto é composto de outros objetos. No exemplo abaixo, um carro é composto por um carburador.
Car
0..1 1..1
Carburetor
GENERALIZAÇÃO ou Herança: modelos de herança “é um” e “é como” relacionamentos, permitindo que você reutilize 
facilmente dados e códigos existentes.
Person
+ name : string
+age : int = 0
Student
+ grades : list
Professor
+ listOfStudents : list
DEPENDÊNCIA: é uma forma mais fraca de vínculo que indica que uma classe depende de outra porque a usa em algum momento.
Car
Wheel
-size:int
<< use >>
+ model:string
- manufacturer:string
+ turnRight():void
+ turnLeft():void
+ driveStraight():void
Mas, como desenhar um diagrama de classes quando você está modelando orientado 
a objeto? Veja algumas pistas dadas por BELL (2004):
 · use um nome significativo para a classe, relevante e único;
 · seja proativo e identifique os elementos e os relacionamentos dessa classe;
 · aproveite para identificar atributos e métodos, ou seja, os papeis dessa classe;
 · pense apenas em colocar propriedades necessárias à classe;
 · anote aspectos do diagrama, eles devem ser inteligíveis para o desenvolvedor;
 · revise o diagrama quantas vezes for necessário antes de publicar.
Diagrama de Atividade
É basicamente um fluxograma para representar o fluxo de uma atividade para ou-
tra. A atividade pode ser descrita como uma operação do sistema. O fluxo de controle 
é desenhado de uma operação para outra. Esse fluxo pode ser sequêncial, ramificado 
ou simultâneo.
13
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Para termos êxito no desenho de um diagrama de atividades, precisamos levar em 
consideração os seguintes elementos:
 · Atividades;
 · Associações;
 · Condições;
 · Restrições.
[ Não ]
[ Não ]
[ Não ]
[ Sim ]
[ Sim ]
[ Sim ]
Pedido Desejado Encontrado?
Diagrama de Atividade
Cadastro de Pedido
Consulta Pedido
Edita Lista de Pedidos
Consulta Lista de Produtos
Cadastra novo Produto
Con�rma Alterações
Adiciona produto à lista de Pedidos
Cadastra nova Lista 
de Pedidos
Pedido Desejado Encontrado?
Incluir novo item à lista?
Figura 5 – Exemplo de um Diagrama de Atividades e seus elementos - UML
AMBLER (2005) descreve os elementos componentes desse diagrama, a saber:
 · Nó inicial: O círculo preenchido é o ponto de partida do diagrama;
 · Nó final da atividade: O círculo preenchido com uma borda é o ponto final;
 · Atividade: Os retângulos arredondados representam atividades. Uma ativi-
dade pode ser física ou eletrônica;
 · Fluxo / borda: São as setas no diagrama;
 · Garfo: Uma barra preta com um fluxo entrando e vários saindo. Isso denota 
o começo da atividade paralela;
 · Juntar: Uma barra preta com vários fluxos entrando e um saindo dela. Todos 
os fluxos que entram na junção devem alcançá-lo antes que o processamento 
possa continuar. Isso denota o fim do processamento paralelo;
14
15
 · Condição: Textos como [Formulário incorreto] em um fluxo, definindo uma 
condição que deveser avaliada como verdadeira para ultrapassar o nó;
 · Decisão: Um diamante com um fluxo entrando e vários saindo. Os fluxos 
que saem incluem condições;
 · Fusão: Um diamante com vários fluxos entrando e um saindo. A implicação 
é que um ou mais fluxos de entrada devem atingir esse ponto até que o 
processamento continue, com base em quaisquer proteções no fluxo de saída;
 · Partição: Também chamadas de raias, indicando quem / o que está execu-
tando as atividades.
Consultant
Fill Out 
Expense Fom
Validate
Expenses
Enter Expenses
In P ayroll
Pay Employees
:Expense
Fom
[ Initial]
:Expense
Fom
[ Error]
:Expense
Validator
:P ayroll
File
Accountant
Payroll
Service
[invalid]
[valid]
Figura 6 – Exemplo de um Diagrama de Atividades com raias - UML
Diagrama de Máquina de Estado
Retratam o comportamento dinâmico de uma entidade com base em sua resposta 
a eventos, mostrando como a entidade reage a vários eventos, dependendo do estado 
atual que se encontra.
Figura 7 – Exemplo de um Diagrama de Máquina de Estado e seus elementos - UML
Fonte: uml-diagrams.org
15
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Vejamos uma explicação de FAKHROUTDINOV (2009) adaptada na tabela logo 
abaixo para cada elemento desse diagrama:
Tabela 3 – Componentes do diagrama de Máquina de Estados – UML
ESTADOS - um retângulo redondo com o nome do estado escrito dentro dele.
ESTADOS INICIAIS E FINAIS - O estado inicial é denotado por um círculo preto preenchido e pode ser 
rotulado com um nome.
O estado final é denotado por um círculo com um ponto dentro e também pode ser rotulado com um nome.
TRANSIÇÕES - são indicadas por linhas com pontas de seta. Uma transição pode ter um gatilho, uma 
proteção e um efeito.
“Gatilho” é a causa da transição, que pode ser um sinal, um evento, uma mudança em alguma condição 
ou a passagem do tempo.
“Guarda” é uma condição que deve ser verdadeira para que o gatilho cause a transição. 
“Efeito” é uma ação que será invocada diretamente no objeto que possui a máquina de estado como 
resultado da transição.
AÇÕES DO ESTADO - definir ações que ocorrem em eventos ou ações repetitivas.
16
17
AUTO-TRANSIÇÕES - uma transição que retorna a si mesma, como no diagrama a seguir. Isso é mais útil 
quando um efeito está associado à transição.
ESTADOS COMPOSTOS - pode incluir diagramas de submáquina.
 ou 
17
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
ESCOLHA PSEUDO-ESTADO - um pseudo-estado de escolha é mostrado como um diamante com uma 
transição chegando e duas ou mais transições saindo. O diagrama a seguir mostra que qualquer estado, 
após o pseudo-estado de escolha, depende do formato de mensagem selecionado durante a execução 
do estado anterior.
JUNÇÃO PSEUDO-ESTADOS - junção pseudo-estados são usadas para encadear várias transições.
REGIÕES SIMULTÂNEAS - um estado pode ser dividido em regiões contendo subestados que existem e 
são executados simultaneamente.
Diagrama de Sequência
BELL (2004) ensina que o diagrama de sequência é usado principalmente para mos-
trar as interações entre os objetos na ordem sequencial, em que essas interações ocor-
rem. Serve também para definir sequências de eventos que resultem em algum resultado 
desejado. O foco é menos nas próprias mensagens e mais na ordem em que as mensa-
gens ocorrem.
18
19
Vamos conhecer os elementos que compõem esse diagrama comportamental obser-
vando a tabela abaixo:
Tabela 4 – Componentes do diagrama de SEQUÊNCIA – UML adaptado de IBM-RATIONAL
QUADRO – como o limite gráfico de um diagrama é elaborado.
LINHAS DE VIDA - representam funções ou instâncias de objeto que participam da sequência que está 
sendo modelada.
MENSAGENS - para mostrar um objeto (ou seja, linha de vida) enviando uma mensagem para outro 
objeto, você desenha uma linha para o objeto receptor com uma ponta de seta sólida (se uma operação 
de chamada síncrona) ou com uma ponta de seta (se um sinal assíncrono).
MENSAGEM DE AUTOCHAMADA - ao modelar um diagrama de sequência, haverá momentos em que um 
objeto precisará enviar uma mensagem para si próprio.
19
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
GUARDAS - ao modelar interações de objetos, haverá momentos em que uma condição deve ser 
atendida para que uma mensagem seja enviada para o objeto.
ALTERNATIVAS - são usadas para designar uma escolha mutuamente exclusiva entre duas ou mais 
sequências de mensagens. As alternativas permitem a modelagem da clássica lógica “if then else” (por 
exemplo, se eu comprar três itens, então recebo 20% de desconto em minha compra; caso contrário, 
recebo 10% de desconto em minha compra).
20
21
OPÇÃO - é usado para modelar uma sequência que, dada uma determinada condição, ocorrerá; caso 
contrário, a sequência não ocorre. Uma opção é usada para modelar uma simples declaração “se então”.
Fonte: adaptadas de formal.iti.kit.edu
21
UNIDADE 
Métodos de Desenvolvimento de Sistemas Orientados a Objetos 
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Object-Oriented Systems Analysis: Modeling the World in Data
SHLAER, S. MELLOR, S.T. Object-Oriented Systems Analysis: Modeling the World 
in Data. Yourdon Press, Englewood Cliffs, N.J., 1988
Designing Object-Oriented Software
WIRFS-BROCK, R. WILKERSON, B. WIENER, L. Designing Object-Oriented Softwa-
re. Prentice Hall, Englewood Cliffs, N.J., 1990.
Object-Oriented Analysis
COAD,P. YOURDON, E. Object-Oriented Analysis, 2nd ed. Yourdon Press, Englewood 
Cliffs, N.J., 1991.
Object-Oriented Analysis and Design with Applications
BOOCH, G. Object-Oriented Analysis and Design with Applications, 1st ed. Benja-
min/Cummings, Redwood City, Calif., 1991.
Object-Oriented Modeling and Design
RUMBAUGH, J. BLAHA, M. PREMERLANI, W. EDDY, F. LORENSEN,W. Object-
-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, N.J., 1991.
22
23
Referências
AMBLER, S. Diagramas de atividade da UML 2: uma introdução ágil, 2005, Agile 
Modeling, disponível em: <http://agilemodeling.com/artifacts/activityDiagram.htm>. 
Acesso em: 18/03/2018
BELL, D. O diagrama de classe, 2004, IBM, disponível em: <https://www.ibm.com/deve-
loperworks/rational/library/content/RationalEdge/sep04/bell/>. Acesso em: 24/02/2018
BELL, D. Fundamentos da UML - O diagrama de sequência, 2004, IBM, disponível 
em: <https://www.ibm.com/developerworks/rational/library/3101.html> Acessoe em: 
20/02/2018.
BECKERT, B. Formal Specification of Software - UNIVERSITÄT KOBLENZ-LAN-
DAU, disponivel em: <https://formal.iti.kit.edu/~beckert/teaching/Spezifikation-
-SS04/10StateCharts.pdf>. Acesso em: 15/03/2018.
FAKHROUTDINOV, K. State Machine Diagrams, 2009, UML Diagrams, disponí-
vel em: <https://www.uml-diagrams.org/state-machine-diagrams.html>. Acesso em: 
20/03/2018. 
23