Linguagem de
Programação II
Carlos Oberdan Rolim
Ciência da Computação
Sistemas de Informação
Um pouco sobre UML
Diferenças de Notação
As diferenças de notação são muitas, e a ordem na qual o
analista desenvolve o modelo em uma e outra técnica é
completamente diferente;
Em técnicas Estruturadas, você coloca suas fundações sobre as
Funções do sistema - Coisas que mudam a toda hora;
Em OO você coloca suas fundações sobre os Dados do sistema
- algo que muda e evolui, mas não de forma tão dramática, a toda
hora;
A UML, em especial, é uma técnica muito flexível, com uma
notação estendível, o que possibilita utilizá-la em diversos
aspectos de um sistema sem ter de trocar de técnica - Dados,
real-time, Interface, etc… .
Diferentes padrões
Em fins dos anos 80 e inicio dos anos 90 vários métodos
orientados a objetos surgiram entre eles de Grady Booch,
Jim Rumbaugh (OMT) e Ivar Jacobson
A UML foi uma tentativa de unificar as notações destes três
métodos. Foi concebida por esses profissionais
A idéia era produzir um padrão com as melhores práticas
adotadas pela indústria, levando mais desenvolvedores a
modelar seus sistemas de software antes de construí-los
Grady Booch
Um dos pioneiros da OO
1980: ênfase em técnicas de projetos para ADA
1992-1994: livros
Object-Oriented Design With Applications
Projeto de programas em C++ e Ada
Grady Booch
1994: Object-Oriented Analysis and
Design with Applications
Texto sobre conceitos de OO e modelagem de
objetos
Projeto de várias aplicações-exemplo com
diferentes linguagens da época
Base da UML
1998
Fundação da Rational
Booch
Ivar Jacobson
Modelagem OO baseada em
casos de uso
James Rumbaugh
Object Modeling Technique (OMT)
Desenvolvida na GE
Metodologia baseada em notações préexistentes (ER, DTE, DFD)
Clara distinção entre as três visões do
problema
OMT
Visão Geral da UML
A UML é uma linguagem para:
visualizar
especificar
construir
documentar
Artefatos de um sistema intensivamente baseado em
software
Elementos de modelagem
Relacionamentos
Mecanismos de extensibilidade
Diagramas
História da UML
Desenvolvimento do UML
começou no final de 1994, quando Booch e Rumbaugh passaram a
trabalhar em conjunto
Versão Preliminar do UML (versão 0.8)
outubro de 1995, quando Jacobson se une ao grupo
A partir dos esforços de Booch, Rumbaugh e Jacobson
versão 0.91 (outubro de 1996), liberada para a comunidade
História da UML
Uma RFP (Request for Proposal) foi realizada pela OMG
(Object Management Group)
buscando contribuições da comunidade para o estabelecimento de uma
linguagem unificada
diversas contribuições lançaram o UML 1.0
Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON
Computing, MCI Systemhouse, Microsoft, Oracle, Rational
Software, TI e Unisys.
Em janeiro 1997, novas contribuições lançaram o UML 1.1
IBM & ObjecTime, Platinum Technology, Ptech, Taskon & Reich
Technologies e Softeam
História da UML
A Partir da Versão 1.1
comunidade de desenvolvimento de software faz uma aderência maciça
ao UML
Em novembro 1997
O UML 1.1 foi adotado como norma pela OMG
OMG estabeleceu um RTF (Revision Task Force) para aperfeiçoar
pequenos detalhes na linguagem
Em Junho 1999
O RTF libera a versão UML 1.3
UML 1.4
Liberada em Setembro de 2001
UML 2.0
Liberada em Julho de 2005
Criação da UML
UML 2.0
Aceitação Final dOMG – Nov 1997
UML 1.5
Submissão Final OMG – Set 1997
feedbackPrimeira submissão OMG – Jan 1997
UML 1.3
UML 1.1
Parcerias UML
UML 1.0
Web – Junho 1996
UML 0.9
OOPSLA ´95
Outros Métodos
Unified Method 0.8
Método Booch
OMT
OOSE
Contribuições à UML
Harel
Meyer
Máquinas de Estados
Pré e Pós Condições
Gamma, et al
“Frameworks” e “patterns”,
HP Fusion
Booch
Descrições de Operações e
Numeração de Menssagens
Booch method
Embley
Rumbaugh
Classes Singleton e
Visão de Alto Nível
OMT
Wirfs-Brock
Jacobson
Responsabilidades
OOSE
Shlaer - Mellor
Odell
Ciclos de Vida de Objetos
Classificação
Sócios da UML
Rational Software Corporation
Hewlett-Packard
I-Logix
IBM
ICON Computing
Intellicorp
MCI Systemhouse
Microsoft
ObjecTime
Oracle
Platinum Technology
Taskon
Sterling Software
Unisys
Unified Modeling Language
UML significa Linguagem de Modelagem Unificada
A UML combina o melhor do melhor de:
Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento)
Modelagem de Negócios (Fluxo de trabalhos)
Modelagem de Objetos
Modelagem de Componentes
A UML é a linguagem padrão para visualizar, especificar,
construir e documentar os artefatos de um sistema intensamente
baseado em software
Pode ser usada com todos os processos, durante todo o ciclo de
desenvolvimento, e com diferentes tecnologias de implementação
Modelos, Visões, Diagramas
Iteração
Use Case
Use Case
Diagramas
Diagramas
Sequência
Use Case
Use Case
Diagramas
Diagramas
Caso de Uso
Scenario
Scenario
Diagramas
Diagramas
Colaboração
Modelos
Scenario
Scenario
Diagramas
Diagramas
Estado
Atividade
Visões dinâmicas
State
State
Diagramas
Diagramas
Classes
State
State
Diagramas
Diagramas
Objetos
State
State
Diagramas
Diagramas
Componentes
Component
Component
Diagramas
Diagramas
Distribuição
Visões estáticas
Modelos, Visões, Diagramas
Visão estrutural
Visão de implementação
Objetos
Componentes
Classes
Visão do usuário
Caso de Uso
Iteração
Sequência
Colaboração
Estado
Distribuição
Atividade
Visão comportamental
Visão de ambiente
Atenção
Como o foco da disciplina é orientação a objetos não iremos
nos aprofundar demais em diagramas e sim trabalharmos de
forma mais intensa os conceitos envolvidos na orientação a
objetos ao longo semestre.
A cadeira de Engenharia de Software proporciona o conhecimento
necessário e aprofundado...
O Modelo de Objetos
Um modelo de objetos busca capturar a estrutura estática
de um sistema mostrando os objetos existentes, seus
relacionamentos, e atributos e operações que
caracterizam cada classe de objetos.
É através do uso deste modelo que se enfatiza o
desenvolvimento em termos de objetos ao invés de
mecanismos tradicionais de desenvolvimento baseado em
funcionalidades, permitindo uma representação mais
próxima do mundo real.
Objeto
Objeto é definido como um conceito, abstração ou coisa
com limites e significados bem definidos para a
aplicação em questão.
Objetos têm dois propósitos: promover o entendimento do
mundo real e suportar uma base prática para uma
implementação computacional.
Não existe uma maneira “correta” de decompor um
problema em objetos; esta decomposição depende do
julgamento do projetista e da natureza do problema. Todos
objetos têm identidade própria e são distinguíveis.
Objeto
Objetos são a chave para se compreender a tecnologia
orientada a objetos. Você olha ao seu redor e tudo o que vê
são objetos: carro, mesa, janela, livro, pessoa, etc.
Os objetos do mundo real têm duas carecterísticas em
comum: ESTADO e COMPORTAMENTO.
Estado
O estado de um objeto revela seus dados importantes. Por exemplo,
uma pessoa tem: idade, peso, altura, cor de cabelo, cor da pele.
Comportamento
O comportamento são as ações que aquele objeto pode exercer ou
executar. Por exemplo, uma pessoa pode: andar, falar, ouvir, pular.
Objeto
Esses objetos podem ser tanto objetos concretos (carro,
livro, nota fiscal), quanto conceitos abstratos (conta
corrente, venda, pessoa jurídica).
Na Orientação a Objetos, os objetos do mundo real são
modelados e representados no mundo computacional,
ou seja, dentro do sistema, por meio de objetos de sotware.
Cada objeto deve ser conhecido, bem definido e ter seu
limite e um significado dentro do sistema.
Os objetos de software, assim como os objetos do mundo
real, também possuem estado e comportamento.
Classe
Uma classe é um “modelo” que define as variáveis (estado) e
os métodos (comportamento) comuns a todos os objetos do
mesmo tipo.
Um objeto nada mais é que uma instância de uma classe
Ex.: Grupo de pessoas. Cada pessoa pode ser vista como um objeto
mas todas elas pertencem a classe Pessoa
Representação de classes e objetos
Classe
Nome da classe podem ser simples ou pode ser precedido pelo
nome do pacote em que a classe está contida
(Exceções::ClienteCadastrado)
Representação
Identificador - Nome (obrigatório)
Atributos (opcional)
Operações (opcional)
Curso
nome
créditos
abrir()
incluir()
Classe
Nome da Classe
Visibilidade atributo: Tipo = ValorInicial
Visibilidade operação (lista arg): Tipo retorno
Atributos
Representa alguma propriedade do que está sendo modelado identifica as características próprias da classe
Descrevem os dados contidos nas instâncias de uma classe
Podem ser identificados apenas com nomes
Podem ter seus tipos (Classes) especificados e terem valores
padrão definidos
Atributos
Parede
altura : real
largura : real
espessura : real
viga : boolean = false
Visibilidade
Usar marcações de acesso para especificar o tipo de acesso permitido
aos atributos e operações
Visibilidade:
+ público
: visível em qualquer classe
# protegido : qualquer descendente poderá usar
- privado
: visível somente dentro da classe
+ saldoEM (date: Date): Money
Operações/Métodos
Uma operação é uma função ou transformação que pode
ser aplicada a/ou por objetos em uma classe. Por exemplo,
abrir, salvar e imprimir são operações que podem ser
aplicadas a objetos da classe Arquivo. Todos objetos em
uma classe compartilham as mesmas operações
Operação é algo que é executado em um objeto
(procedimento de chamada)
Operações/Métodos
Um método é a implementação de uma operação para uma
classe.
Descreve o comportamento da classe e por consequencia todos
os objetos daquela classe
Operações/Métodos
Visibilidade
+público
#protegido
-privado
Diagrama de Classes
Objetivo
Descrever os vários tipos de objetos no sistema e o
relacionamento entre eles.
São os principais diagramas estruturais da UML
As classes especificam a estrutura e o comportamento
(operações) dos objetos, que são instâncias das classes
Exemplo de diagrama
Diagrama de classes
Um diagrama de classes contém
Entidades
Representação de cada uma das pequenas partes daquilo que está
se querendo representar
Classes
Interface  vamos ver mais adiante o que é isso
Relacionamentos
Representa a forma como ocorrerá o relacionamento entre as
partes
Associações
Generalização (herança)
Dependências
Atenção
Novamente falando, não iremos nos deter nos vários
aspectos do diagrama o qual será detalhado nas
disciplinas de engenharia de software.
Vamos somente ver o essencial para prosseguimento
do conteúdo....
Relacionamentos
**** Poucas classes vivem sozinhas ****
Comunicação entre classes - definem
responsabilidades
Construir uma casa
casa, parede, porta, janela, cômodo, luz
Casa tem janelas, que têm vários tipos!
Janelas podem ser abertas no sentido vertical e/ou horizontal
Existem semelhanças entre as janelas e diferenças....
Relacionamentos
3 Tipos:
Associações
Agregação
Composição
Generalização (herança)
Dependências
Associação
Agregação
Composição
Herança
Dependência
Associação
Define um relacionamento entre duas entidades conceituais do
sistema
Especifica que objetos de uma classe estão conectados a objetos
de outras
Ex: as salas são formadas por paredes
É o tipo de ligação de classe mais utilizado nos diagramas de
classe
Dependência
Dependência - relacionamentos de utilização, no qual uma
mudança na especificação de um elemento pode alterar a
especificação do elemento dependente
Ex: os canos dependem do aquecedor para fornecerem água quente
Indica que mudanças em um elemento (o servidor) podem afetar
outro elemento (o cliente)
Dependência entre classes indica que os objetos de uma classe
usam serviços dos objetos de outra classe
Cliente
Servidor
Generalização
Generalização (herança simples e múltipla) - relacionamento entre
um elemento mais geral e um mais específico
Herda de alguém alguma coisa ou características
é um relacionamento de taxonomia entre um elemento mais geral e um
mais específico, que é totalmente consistente com o primeiro, somando-o
informação especializada
O comportamento da classe ou característica da classe muda com relação
as outras associações existentes
A classe sendo refinada é chamada de superclasse ou classe base,
enquanto que a versão refinada da classe é chamada uma subclasse ou
classe derivada
As vezes é chamada de relacionamento is-a (é-um), porque cada instância
de uma classe derivada é também uma instância da classe base.
Ex: Veículo terrestre pode ser do tipo automóvel ou caminhão (TIPO DE),
Tipos de Animal (mamífero, ave, peixe)
Generalização
Clube
Associado
Dependente
Exemplo de associação
e dependencia
Import java.awt.Graphics;
class HelloWorld extends java.applet.Applet
{
public void paint (Graphics g)
g.drawString(“Hello, world!”, 10, 10);
}
Applet
HelloWorld
Graphics
paint()
Tipos des associação (agregação ou
composição)
Agregação - tipo especial de associação - relacionamento
“é parte de, todo/parte” (diamante aberto)
O objeto que contém a referência a outros objetos (todo) PODE EXISTIR
independentemente da existência dos objetos referenciados (parte).
Todo
Parte
Agregação
Estudante
Disciplina
Agregação
Ex.:
Temos o objeto Carro que por sua vez faz referência ao objeto
Rodas, porém o objeto "Carro" pode existir mesmo que vc
destrua "Rodas", ou seja "faz sentido a existência do carro
mesmo sem seus pneus".
Objeto TODO mantém um ponteiro ou uma referência para
suas partes

Composição
Composição - relacionamento entre um elemento (o todo) e outros
elementos (as partes) indica que as partes só podem pertencer
ao “todo” e são criadas e destruídas com ele
A parte não vive sem o todo
O objeto que contém a referência a outros objetos NÃO FAZ
SENTIDO EM EXISTIR sem a existência dos objetos referenciados.
É semanticamente esquivalente a um ATRIBUTO, mas pode ser
mais atraente quando a parte tem uma estrutura interna
Todo
Parte
Composição
Estudante
Disciplina
Composição
Ex.:
Objeto Pedido que por sua vez faz referência ao objeto Itens, portanto o objeto
"Itens" não faz sentido sem o objeto "Pedido". Qual o principal "conteúdo" do
pedido ? São seus itens certo ?
Computador
Monitor
Teclado
Mouse
Janela
Menu
Botão
Título
Associação x Agregação x Composição
Como você modelaria:
Dependente e Funcionário?
Pedido e Item do pedido?
Funcionário e Cartão de ponto?
Carro, Roda, Direção e Carburador?
Na dúvida, use agregação!
Na dúvida, use associação!
Multiplicidade
Multiplicidade define quantos objetos participam do
relacionamento
O número de instâncias de uma classe relacionada a uma instância de
outra classe
Especificado em cada uma das pontas da associação
A multiplicidade em uma das extremidades da associação
especifica para cada objeto da classe encontrada na
extremidade oposta deve haver a determinada
quantidade de objetos na extremidade próxima
Tipos de Multiplicidade
Não especificada
Exatamente um
Zero ou mais
Muitos (mesmo que 0..*)
1
0..*
*
Um ou mais
1..*
Zero ou um
0..1
Intervalo determinado
2..4
Valores múltiplos
2, 4..6
Exemplo: Multiplicidade
Multiplicidade
Estudante
1
1..*
Disciplina
Uma instância de Disciplina pode conter 1 ou mais Estudantes
Uma instância de Estudante pode 1 Disciplina
Navegação
Especifica a direção da associação
Associações e agregações são bidirecionais por default
Estudante
1
1..*
Disciplina
Navegação
Nesse caso Disciplina não sabe o vinculo de multiplicidade com Estudante

Pessoa
Trabalha para
1..*
*
funcionário
empregador
Empresa
1
*
Departamento
Notações
Diagrama de classe
Nome das classes sõa substantivos
Primeiro caractere maiúsculo (Customer, java::awt::Rectangle)
Atributo:
substantivo, aparece como maiúsculo o primeiro caractere
de cada palavra existente no nome do atributo, exceto a
primeira letra: nomeProfessor
Operação
verbo ou locução verbal, aparece como maiúsculo o primeiro
caractere de cada palavra existente no nome da operação,
exceto a primeira letra: isEmpty
Sugestões de desenvolvimento
Não comece a construir um modelo de objetos simplesmente
definindo classes, associações e heranças. A primeira coisa a se
fazer é entender o problema a ser resolvido.
Tente manter seu modelo simples. Evite complicações
desnecessárias.
Escolha nomes cuidadosamente. Nomes são importantes e
carregam conotações poderosas. Nomes devem ser descritivos,
claros e não deixar ambiguidades. A escolha de bons nomes é um
dos aspectos mais difíceis da modelagem.
Não ”enterre” apontadores ou outras referências a objetos dentro
de objetos como atributos. Ao invés disto, modele estas
referências como associações. Isto torna o modelo mais claro e
independente da implementação.
Sugestões de desenvolvimento
Tente evitar associações que envolvam três ou mais classes
de objetos. Muitas vezes, estes tipos de associações podem ser
decompostos em termos de associações binárias, tornando o
modelo mais claro.
Não transfira os atributos de ligação para dentro de uma das
classes.
Tente evitar hierarquias de generalização muito profundas.
Não se surpreenda se o seu modelo necessitar várias revisões; isto
é o normal.
Nem sempre todos os símbolos são necessárias para descrever
uma aplicação. Use apenas aquelas que forem adequadas para o
problema analisado.