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

Método Booch OMT

Unified Method 0.8

OOSEOutros Métodos

UML 0.9

feedback

UML 1.0

UML 1.5

UML 2.0

UML 1.1

UML 1.3

Aceitação Final dOMG – Nov 1997

Submissão Final OMG – Set 1997

Primeira submissão OMG – Jan 1997

Parcerias UML

Web – Junho 1996

OOPSLA ´95

Meyer

Pré e Pós Condições

Harel

Máquinas de EstadosGamma, et al

“Frameworks” e “patterns”,

HP Fusion

Descrições de Operações eNumeração de Menssagens

Embley

Classes Singleton eVisão de Alto Nível

Wirfs-Brock

Responsabilidades

Odell

Classificação

Shlaer - MellorCiclos de Vida de Objetos

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Contribuições à UML

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

Use CaseDiagramasUse Case

DiagramasCaso de Uso

ScenarioDiagramasScenario

DiagramasColaboração

StateDiagramasState

DiagramasComponentes

ComponentDiagramasComponent

DiagramasDistribuição

StateDiagramasState

DiagramasObjetos

ScenarioDiagramasScenario

DiagramasEstado

Use CaseDiagramasUse Case

DiagramasSequência

StateDiagramasState

DiagramasClasses

Atividade

Modelos

Iteração

Visões dinâmicas

Visões estáticas

Modelos, Visões, Diagramas

Caso de Uso

Componentes

Distribuição

Objetos

Estado

Classes

Atividade

Colaboração

Sequência

Iteração

Visão do usuárioVisão do usuário

Visão comportamentalVisão comportamental Visão de Visão de ambienteambiente

Visão estruturalVisão estrutural Visão de Visão de implementaçãoimplementação

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 é 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

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

Curso

nomecréditos

abrir()incluir()

Identificador - Nome (obrigatório)

Atributos (opcional)

Operações (opcional)

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 : reallargura : realespessura : realviga : 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

ObjetivoDescrever 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

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

Herança

Composição

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);

}

HelloWorld

paint()

Graphics

Applet

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).

DisciplinaEstudante

Todo ParteAgregação

Agregação

Objeto TODO mantém um ponteiro ou uma referência parasuas partes

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".

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

DisciplinaEstudante

Todo ParteComposição

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

Teclado MouseMonitor

Janela

Botão TítuloMenu

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..*)

Um ou mais

Zero ou um

Intervalo determinado

Valores múltiplos

1

0..*

*

1..*

0..1

2..4

2, 4..6

Exemplo: Multiplicidade

DisciplinaEstudante

Multiplicidade

1..*1

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

DisciplinaEstudante

Navegação

1..*1

Nesse caso Disciplina não sabe o vinculo de multiplicidade com Estudante

Pessoa Empresafuncionário empregador

1..* *Trabalha para

Departamento

1

*

Notações

Diagrama de classeNome 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.