uml - unified modeling language Álvaro vinícius de souza coêlho [email protected]

UML - Unified Modeling Language

Álvaro Vinícius de Souza Coê[email protected]

Roteiro

Histórico da ModelagemDecomposição FuncionalAnálise EstruturadaEngenharia de InformaçãoAnálise Estruturada ModernaAbismo Análise / ProjetoOrientação a Objetos

Roteiro

UMLDesenvolvimento em EspiralAcrescentando-se novas características a cada giroO Projeto

Comportamento do SistemaCasos de UsoCasos de Uso EssenciaisCasos de Uso Reais

Roteiro

Objetos e ClassesComo descobrir as ClassesAnálise dos Casos de UsoClasses EntidadesClasses FronteiriçasClasses de ControleAtributos das Classes

RoteiroAssociações entre Classes

AssociaçãoCardinalidade e OpcionalidadeAssociação ReflexivaAgregaçãoGeneralizaçãoHerança SimplesHerança MúltiplaClasse Associativa

Roteiro

Interação entre ObjetosDiagrama de SeqüênciaDiagrama de ColaboraçãoMétodos e Mensagens

Transição de EstadosEstadoEventoTransição

Conclusão

1. Histórico da Modelagem

• Um dia alguém quis fazer um programa (provavelmente no ENIAC ou no UNIVAC) e não conseguiu terminá-lo.

• Era o problema da Administração da Complexidade

• Percebeu-se a necessidade de se fazer um estudo preliminar antes de qualquer ação.


• À medida que se caminhou, os princípios de administração da complexidade foram sendo descobertos.

• Metodologias e Técnicas foram sendo desenvolvidas para atender a esses princípios


• Decomposição Funcional– Um Sistema é uma Função– Composto de Funções– Sucessivamente até que a função seja de

implementação básica ou trivial– Princípios Observados:

• Abstração• Escala


• Decomposição Funcional– Abordagem extremamente inteligente– Empírica – Aprende-se logo que se começa a

programar– Reflete um importante aspecto da organização

geral dos Sistemas• Interfaces• Processos• Dados


• Análise Estruturada– Enfoque no Fluxo de Dados– Científico: Ferramentas de Administração e de

Desenvolvimento– DFD– Especificação de Processos– Transformação de Dados (Estados)


• Análise Estruturada– Princípios Observados:

• Abstração• Escala• Comportamento


• Engenharia de Informação– Enfoque: Informações– Entidades– Associações entre Entidades: Relacionamentos– Organização de Informações


• Engenharia de Informação– Entidades Associativas– Supertipos e Subtipos– Atributos– MER – Poderosa ferramenta de Organização de

Informações


• Engenharia de Informação– Princípios Observados

• Abstração• Herança• Associação• Métodos de organização• Escala


• Análise Estruturada Moderna– Incorporação da Engenharia de Informação na

Análise Estruturada– DFD– MER– Referência Cruzada– Modelo de Dados e de Processos


• Análise Estruturada Moderna– Princípios Observados:

• Abstração (de dados e de procedimentos)• Herança• Associação• Métodos de Organização• Escala• Comportamento


• Análise Estruturada Moderna– Problemas:

• Alguns princípios não observados• O que modelar primeiro, Dados ou Processos?• O projeto (??)


• O Abismo Análise / Projeto– DFD, MER, Evento-Resposta, Diagrama de

Contexto, Diagrama de Transição de Estados, Especificação de Processos – Tudo reflete O QUE

– Objetivo, afinal, da Análise– Mas e o COMO?


• O Abismo Análise / Projeto– Novas ferramentas. Abordagem distinta.– Mais um problema a ser Administrado?– Soluções:

• Mecanismos automáticos de construção dos artefatos de projeto

• Desenvolvimento de ferramentas aplicáveis tanto à Análise quanto ao Projeto


• Orientação a Objetos– Aborda um Conceito – Composto de Informações

conhecidas (atributos) e funções (métodos)• Não há mais a necessidade de discutir o que se estuda antes, se

Dados ou Processos

– Os conceitos são• Coisas do Domínio do Problema• Recursos Computacionais• Aplicável à Análise e ao Projeto


• Orientação a Objetos– Implementa os princípios:

• Abstração• Encapsulamento• Herança• Associação• Comunicação com Mensagens• Métodos de Organização• Escala• Comportamento

2. UML

• Não é um método. É uma linguagem.• Modelo = Linguagem + Método• Histórico

– Início dos anos 90: Métodos Orientados a Objeto (Rumbaugh, Coad, Jacobson, etc.)

– OMG (Object Management Group) Inicia um trabalho de Unificação

– 1997: UML vira padrão OMG

2. UML

• Desenvolvimento em Espiral– Concepção– Elaboração– Construção– Transição

• Para cada fase, diferentes artefatos

2. UML

• A cada volta– Novas características concebidas– Elaboração destas e correção das anteriores– Construção das partes novas/modificadas– Liberação de protótipos ou versões alfa e beta

2. UML

• O Projeto– Nas metodologias estruturadas: “Abismo” entre

Análise e Projeto• Diferentes artefatos• Diferentes compromissos

– Nas metodologias OO:• Mesmos artefatos, acrescentados de objetos de

projeto– Redução (supressão) do abismo

3. Comportamento do Sistema

• Visão das coisas que o sistema deve fazer• Inicialmente uma visão superficial e

simplificada• A cada iteração deve ser ampliada e

aprofundada


• Casos de Uso (Use Cases)• São descrições de eventos que ocorrem no

sistema• Um Ator interage com um sistema (ação e

resposta)• Pode ser descrito e/ou diagramado


• Descrição de um Caso de Uso• Mostrar sua seqüência típica de eventos

CabeçalhoSeqüência Típica de Eventos

1. Este caso de Uso começa...

2. Ação do Ator 3. Resposta do Sistema


• CabeçalhoCaso de Uso:Atores:Finalidade:Visão Geral:Tipo:


• ExemploCaso de Uso: Reservar Livro na BibliotecaAtores: UsuárioFinalidade: Reservar um tomo para uma pessoaVisão Geral: Um usuário solicita a reserva de um

livro, que é feita em caso ded disponibilidadeTipo: (a se ver adiante)


Seqüência Típica de Eventos

1. Este caso de Uso começa quando o usuário solicita uma reserva

2. O usuário se identifica

3. O usuário aponta um tomo a ser reservado

4. O sistema verifica a disponibilidade e faz a reserva


• Diagrama de Casos de Uso

Ator Caso de Uso

3. Comportamento do Sistema• Ator:

– Interage com o Sistema– Tem uma identificação (um nome)

Cliente

3. Comportamento do Sistema• Ator:

– Não é parte do sistema (entidade externa)– Interage com o sistema– Recebe informações do sistema– Ser humano, máquina, sensor, outro sistema


• Caso de Uso– Sequencia de ações que o sistema executa– Padrão de comportamento– Acionado por um ator (evento)– Modela o diálogo: Atores-Sistema e Casos de Uso entre

si– Invocado por um ator ou por outro caso de uso– Fluxo de eventos completo e consistente– Conjunto dos Casos de Uso = Situações possíveis de

funcionamento do sistema

3. Comportamento do Sistema• Exemplos


• Associação– Conexão dinâmica entre Casos de Uso e atores– Unidirecionais (segue o fluxo)

Usuário

Reservar LivroDados da Reserva

Confirmação


• Associação– Pode ser detalhada

Usuário

Reservar LivroDados da Reserva

Confirmação

Verificar Disponibilidade

Dados do Livro

Disponibilidade do Livro


• Associação– Qualquer semelhança com

• Diagrama de Contexto• DFD (e as explosões das bolhas)

–NÃO é mera coincidência– Ambas as ferramentas expressam processos e

fluxo de informações (comportamento)


• Casos de Uso Essenciais• Expressam a essência do comportamento

(similar à análise essencial)• Independente de tecnologia


• O mesmo ExemploCaso de Uso: Reservar Livro na BibliotecaAtores: UsuárioFinalidade: Reservar um tomo para uma pessoaVisão Geral: Um usuário solicita a reserva de um

livro, que é feita em caso ded disponibilidadeTipo: Essencial




2. O usuário se identifica

3. O usuário aponta um tomo a ser reservado

4. O sistema verifica a disponibilidade e faz a reserva


• Casos de Uso Reais• Expressam a implementação do

comportamento (a encarnação em análise essencial)

• Visão da tecnologia


• O Exemplo - RealCaso de Uso: Reservar Livro na BibliotecaAtores: UsuárioFinalidade: Reservar um tomo para uma pessoaVisão Geral: Um usuário solicita a reserva de um

livro, que é feita em caso ded disponibilidadeTipo: Real




2. O usuário passa o cartão e digita a senha

3. O sistema consulta sua situação no Banco de Dados

4. O sistema mostra um Menu



5. O usuário solicita a opção Reserva no Menu

6. O sistema pede que ele indique ou autor, ou título ou assunto

E a descrição segue como se pode imaginar

4. Objetos e Classes

• Objetos– Coisas que existem, e que são importantes para

o domínio e as responsabilidades que se está considerando

– À medida que os ciclos se fazem e a amplitude e profundidade das considerações aumentam, mais objetos são considerados


• Objetos– Exemplos:

• O aluno José, ou João, ou Antônio• O automóvel Monza placa MMX 1280• O avião Boeing 737-700 com 115 assentos e

autonomia de 5000 nm• A janela principal de um programa• O botão Botão1 com os eventos associados a On

Pressed


• Classes– Descrição de objetos– Fôrma de se fazer um objeto– Visão geral dos aspectos dos objetos em

intenção– Aumentam também de quantidade a cada ciclo


• Classes– Exemplos

• Alunos• Automóveis• Aviões• Janelas de Interface• Botões


• Representação– Uma classe possui um nome– Possui um conjunto de atributos (que terão

valores específicos para cada objeto)– Possui um conjunto de métodos (que definem

seu comportamento – independente da instância)


• Em UML:

Classe

Atributos

Métodos


• Como descobrir as Classes• As classes devem ser percebidas

– Em entrevistas– Em descrições do domínio– Na observação– Enfim, nos processos

• Quem modela os processos?


• Análise dos casos de uso• Para sua descrição, os casos de uso se

referem a “coisas”– Externas ao sistema – Os atores– Internas a ele – As classes (e os atributos)


• Da descrição de um caso de uso tome os nomes das coisas (normalmente substantivos)– Exclua as referências a atores– O restante são candidatos a ser referências a

classes e seus atributos


• No Exemplo:– Um usuário solicita a reserva de um livro, que é

feita em caso de disponibilidade• Substantivos – Usuário, Reserva, Livro,

Disponibilidade• Tudo isso é Classe?


• Usuário, Reserva e Livro parecem realmente ser.

• A Disponibilidade, a depender de como vai-se verificar se um livro possui ou não disponibilidade.


• Duas opções – A classe Livro se refere a cada título, e Disponibilidade

tem a ver com o número de volumes disponíveis – nesse caso é um atributo

– A classe Livro se refere a cada volume, e Disponibilidade passa a ser a verificação (processo) de quantos estão disponíveis.

• E escolha depende das responsabilidades do Sistema


• Classes Entidade– Modela objetos de caráter geralmente

persistente– As entidades essenciais– Livro, Autor, Reserva, Empréstimo


• Classe Fronteiriça– Modela a comunicação entre a vizinhança do

sistema e suas operações internas.– Objetos de Interface– Formulário de Reserva, Janela de Menu– Em geral:

• Janelas, Relatórios, E-Mail, etc.


• Classes de Controle– Modela o comportamento de controle específico para

um ou mais Caso de Uso• Cria, ativa e anula objetos controlados• Controla a operação de objetos controlados • Controla a concorrência de pedidos de objetos controlados• Em muitos casos corresponde a implementação de um objeto

intangível

– Gerentes, Gestores, SGBDs, SOs, etc.


• Atributos de Classes• Para cada classe – sem perder de vista o Domínio

do Problema e as Responsabilidades do Sistema:– O que é necessário para se executar os processos?– O que é necessário vir de ou ir para os atores?

• Deste conjunto encontrar e suprimir– Quais podem ser derivadas a partir de outras?


• Atributos de Classes• No exemplo:

Usuário

-Nome-Privilégio-Status

Métodos

Reserva

-DataInício-DataFim-Data

Métodos

Livro

-Título-Autor-Assunto-Editora-Ano

Métodos

4. Objetos e Classes• Atributos de Classes

– Atributos que sugerem outras classes devem ser evitados• Em reserva não cabe nem Livro nem Usuário

– Atributos que devem ser transformados em Classes• Referidos com mais especificidade em algum caso de uso• Multi-Valorados

4. Objetos e Classes• Atributos de Classes• No exemplo: Assunto e Autor: Multivalorado. Editora: Referido

especificamente num caso de uso hipotético “Adquirir Volumes”

Usuário

-Nome-Privilégio-Status

Métodos

Reserva

-DataInício-DataFim-Data

Métodos

Livro

-Título-Ano

Métodos

4. Objetos e Classes• Atributos de Classes• E as novas:

Autor-Nome-Nacionalidade-DataNasc

Métodos

Assunto

-Descrição

Métodos

Editora-Nome-Endereço-Telefone-Contato

Métodos

5. Associações entre Classes

• De modo geral uma classe representa um conceito bem estabelecido

• O Sistema, porém, é composto ded várias delas

• As classes podem se associar umas às outras• A Associação modela uma dependência de

idéias


• De modo geral pode-se observar três grandes tipos de associação entre classes:– Associação (ou Relacionamento)– Agregação– Generalização


• Associação• Uma associação é a idéia de que a uma

classe ocorre a existência de outra• Ex: Professor – Aluno, Paciente – Médico,

Livro - Autor.


• Em UML uma associação é representada por uma linha conectando as classes relacionadas

Livro

-Título-Editora-Ano

Métodos

Autor

-Nome-Nacionalidade-DataNasc

Métodos


• Uma associação deverá ser identificada por um nome (normalmente uma ação que uma classe exerce sobre a outra)

Livro

-Título-Editora-Ano

Métodos

Autor

-Nome-Nacionalidade-DataNasc

Métodos

Escreve


• Podem haver (embora mais raras) associações entre mais de duas classes

Agência-Nome-Endereço

Métodos

Cliente-CPF-Nome

Métodos

PossuiConta

-Número-Saldo

Métodos

5. Associações entre Classes• Cardinalidade:• Uma associação é representada pelas quantidades envolvidas• Há 3 tipos de cardinalidade:• 1 para 1• As classes se relacionam, de forma que a cada instância de uma delas corresponderá uma e somente

uma instância da outra


• Exemplos:

Veículo-Descrição-Ano Fabricação

Métodos

PossuiReNaVaM

-Codigo-EstadoOrigem

Métodos

11

Funcionário-Nome-Sexo-DataAdmissão

Métodos

Casado ComConjuge

-Nome-Idade

Métodos

11

5. Associações entre Classes• Um veículo qualquer (um Corsa 1999) possui um e somente um ReNaVaM (No3042384794908

da Bahia) e a recíproca é verdadeira.• Para qualquer Veículo e qualquer ReNaVaM considerado.• Um funcionário (Maria) casou com um e somente um Cônjuge (José) e a recíproca é verdadeira.• Válido para qualquer Funcionário e qualquer Cônjuge considerado.

5. Associações entre Classes• Opcionalidade• A associação entre as classes possui importância também a respeito da

opcionalidade.• Dadas as condições de cardinalidade, é obrigatório que as classes estejam

associadas sempre que ocorrerem? Ou pode haver caso delas ocorrerem sozinhas?


• O mesmo exemplo:

Veículo-Descrição-Ano Fabricação

Métodos

PossuiReNaVaM

-Codigo-EstadoOrigem

Métodos

11

Funcionário-Nome-Sexo-DataAdmissão

Métodos

Casado ComConjuge

-Nome-Idade

Métodos

0..11

5. Associações entre Classes• Um veículo qualquer (um Corsa 1999) possui um e somente um ReNaVaM (No3042384794908 da

Bahia) e a recíproca é verdadeira.• Todo veículo possui ReNaVaM e todo ReNaVaM é de um veículo• Um funcionário (Maria) casou com ninguém ou com um e somente um Cônjuge (José) mas a

recíproca não é verdadeira.• Todo Cônjuge, porém, é casado com um Funcionário (ou não há sentido mantê-lo)

5. Associações entre Classes• 1 para Vários• As classes se relacionam, de forma que a cada instância de uma

delas (chamada Dominante) corresponde várias instâncias da outra• A opcionalidade também é relevante aqui


• Exemplos

Empresa-Nome-CNPJ

Métodos

ContrataTrabalhador

-Matrícula-Nome

Métodos

*0..1

Museu-Nome-Endereço

Métodos

PossuiQuadros

-Nome-Autor-Data

Métodos

0..*0..1

5. Associações entre Classes• Uma empresa contrata um grupo de vários trabalhadores mas cada trabalhador

só pode estar contratado por uma (ou nenhuma, para seu azar) única empresa.• No caso do museu, ele pode ter nenhum ou vários quadros em seu acervo, e

cada quadro só pode estar em um museu, ou mesmo em nenhum (Particular, Roubado, Perdido...)

5. Associações entre Classes• Vários para Vários• As classes se relacionam, de forma que a cada instância de uma delas corresponde várias instâncias

da outra e vice-versa• É o tipo de associação mais complexo de ser implementado em Bancos de Dados• É, porém, o mais comum.• A opcionalidade é relevante aqui, mais uma vez


• Exemplos

Empresa-Nome-CNPJ

Métodos

ContrataAg_Publicidade

-Nome-Telefone

Métodos

**

Fornecedor-Nome-Endereço

Métodos

Dispõe dePeças

-Nome-Autor-Data

Métodos

0..**

5. Associações entre Classes• Uma empresa pode contratar (não é obrigatório) agências de publicidade, e possivelmente

mais de uma (AmBev por exemplo). As agências, por sua vez, podem servir a algumas empresas ou a nenhuma (trabalhar com o governo, ou com políticos).

• Um fornecedor dispõe de várias peças, embora possivelmente nenhuma no momento, e as peças são ofertadas por vários fornecedores (no mínimo um) para que numa compra seja escolhido alguém.

5. Associações entre Classes• Associação Reflexiva• Também chamado de Auto-Relacionamento• Uma classe poded se relacionar com... Ela Mesma!• Um exemplo:• Num sistema que controle empresas que prestam serviço a outrras.


• Um banco, que é uma instância da classe Empresa, contrata uma Companhia de Segurança, e uma de Limpeza, mais duas instâncias de Empresa.

• Cada uma delas possui conta no banco, e podem se contratar mutuamente, ou ainda contratar empresas de viagem, publicidade, etc.

5. Associações entre Classes• E assim sucessivamente.• Como modelar isso?• A semântica é que há uma classe empresa, que se relaciona com ela mesma, de

forma que as empresas associadas ocorram quando se olhar para uma dessas.• A cada empresa, pode haver uma ou mais empresas associadas (cardinalidade).


• Fica assim:

Empresa-Nome-Área-CNPJ-Endereço

MétodosContrata

*

*


• Um exemplo interessante:• Desta estrutura, qualquer grau de parentesco

carnal pode ser derivado

Pessoa-Nome-Sexo

Métodos Progenitor

*

*

5. Associações entre Classes• Agregação• É uma especialização da Associação propriamente dita• Reflete o fato de que um objeto é parte de outro• Também é referido como relacionamento Todo-Parte por alguns autores como

Coad e Yourdon

5. Associações entre Classes• Este tipo de associação, na análise estrtuturada, era modelado

por um relacionamento comum• Em UML ganha semântica e notação específica• Um Losango indica uma relação de agregação


• ExemploEmpresa

-Nome-CNPJ

Métodos

Setor-Nome-Ramal

Métodos

Vôo-Empresa-Distância-Duração

Métodos

Passageiro-Nome-CPF

Métodos

*

1..*

5. Associações entre Classes• O losango cheio indica que o objeto parte não pode existir

sem o objeto todo.• O losango vazio indica que, apesar de ser parte dele, o

segundo objeto pode existir sem o primeiro

5. Associações entre Classes• O primeiro exemplo indica que uma empresa possui vários setores, no

mínimo 1, e que os setores não podem existir sem uma empresa.• O segundo exemplo aponta o fato de que um vôo pode ter vários

passageiros, ou nenhum, e que podem haver passageiros em nenhum vôo

5. Associações entre Classes• Generalização• É um dos mais poderosos recursos da Orientação a Objeto• O conceito é que um ou mais objetos podem ser agrupados sob uma égide comum.• Por definição, os primeiros objetos são chamados de especializações (ou sub-classe)

e o segundo de generalização (ou super-classe ou ainda meta-classe).

5. Associações entre Classes• É uma modelagem de um aspecto comum na natureza:• Vários exemplos

– Mamífero• Canino

– Cão– Lobo

• Equino– Cavalo

– ...

5. Associações entre Classes• Em UML uma relação de Generalização é

expressa com um triângulo vazio na ponta da seta que indica a relação

Volume-Localização-Título

Métodos

Livro-ISBN-Encadernação

Métodos

Periódico-Data-Período

Métodos...

5. Associações entre Classes• Herança• A grande vantagem da Generalização• O que há na Meta-Classe (ou no Meta-Objeto, por instância) é compartilhado pelas sub-classes

– Atributos– Associações– Métodos

5. Associações entre Classes• No exemplo, os atributos Localização e Título são compartilhados

pelas classes Livro e Periódico (e outras que houverem)• As relações que existirem entre Periódico e outras classes também

são herdadas

5. Associações entre Classes• Isso significa que um objeto da classe Livro, por ser um Volume, possui os atributos

Localização e Título• Um objeto da classe Periódico possui também os mesmos atributos• Mas os atributos ISBN e Encadernação são específicos dos objetos da classe Livro• E os atributos Data e Período são específicos dos da classe Periódico

5. Associações entre Classes• Herança de Métodos• Não vimos os métodos com detalhes até agora• Mas a herança, nas relações de generalização, dão-se também com os métodos• Métodos definidos nas super-classes são compartilhados entre todos os objetos das

sub-classes

5. Associações entre Classes• Acoplamento Dinâmico e Polimorfismo• Uma chamada a um método que não é encontrado num objeto leva-o a buscá-lo na super-classe

a que ele pertence• Caso não encontre, ele prossegue na busca indefinidamente (ou retorna um erro de chamada)• A esse processo dá-se o nome de Acoplamento Dinâmico

5. Associações entre Classes• Por exemplo, na super-classe Volume pode-se definir o método AlarmeManutenção().

– AlarmeManutenção(): Informa que a última revisão das condições gerais daquele volume já venceu, e é necessário fazer outra para corrigir possíveis estragos, desgastes, etc.

• Nesse momento as classes Livro e Periódico passam a compartilhar juntas este método.• Opcionalmente pode-se considerar um parâmetro, o que não traria grandes modificações

5. Associações entre Classes• Mas uma observação mais cuidadosa pode revelar diferenças:

– Á exceção dos periódicos, os volumes podem ser danificados em suas encadernações, e em suas fichas catalográficas, coisa que ele não tém.

• Isso sugere que o método AlarmeManutenção() seja implementado de forma diferente na Classe Periódico, embora permaneça igual nas demais

5. Associações entre Classes• Isso faz surgir o método AlarmeManutenção() em periódico,

que funcionará diferente do AlarmeManutenção() de Volume (e das dedmais Sub-Classes)

• A este mecanismo chama-se Polimorfismo

5. Associações entre Classes• Herança Múltipla• Embora seja raro, uma classe pode herdar atributos e/ou métodos de mais de uma super-classe• A esse mecanismo denomina-se Herança Múltipla• No caso de Herança Múltipla, Atributos e Métodos das Super-Classes devem ser distintos (ou

deve-se estabelecer um método de distinção)

5. Associações entre Classes• Como descobrir Generalizações• Observar as classes• Procurar por

– Atributos em comum– Associações em comum– Métodos em Comum

• Num mesmo contexto semântico!– Nome numa classe Cliente e numa classe Peça não justifica subcategorizá-los numa mesma generalização!

5. Associações entre Classes• Estabelecidos padrões comuns de atributos, associações e

métodos, criar uma super-classe • Incluir ali o que for comum aos objetos• Deixar as características específicas em cada um deles

5. Associações entre Classes• Caso a alguma classe não reste atributo nem associação nem método,

esta deve ser excluída• Caso todas as sub-classes sejam excluídas, extingue-se a generalização

5. Associações entre Classes• Classe Associativa• Em alguns casos, uma associação é importante por haver a necessidade de se manter

– Atributos– Novas associações– Métodos (muito raro)

5. Associações entre Classes• Para este caso, deve-se criar uma nova classe• Oriunda de uma associação, portanto denominada Classe Associativa• Por Exemplo uma associação entre as classes Alunos e Disciplina num

histórico acadêmico

5. Associações entre Classes• É interessante saber:

– Que nota ele obteve– Em que período cursou

• E no caso de várias “tentativas”, todos os resultados (similares ao anterior) devem ser mantidos.• Isso justifica a criação de uma Classe Associativa


• Originalmente é:

Aluno-Nome-Matrícula

Métodos

CursouDisciplina

-Nome-Ementa

Métodos

**


• Pode ser:


Métodos

Disciplina-Nome-Ementa

Métodos

**

Cursou-Período-Nota

Métodos


• Ou ainda (com o uso de outra classe para o histórico)


Métodos

Disciplina-Nome-Ementa

Métodos

**

Cursou

MétodosMatriculou

-Período-Nota

Métodos

1 *

6. Interação entre Objetos

• É com a interação entre objetos que se constrói as funcionalidades do sistema

• Cada ação de um sistema é um método, solicitado a um objeto

• Numa modelagem acurada, os casos de uso serão representativos das ações do sistema


• Para cada caso de uso haverá um método em classes fronteiriças para atendê-lo

• Estas classes, provavelmente, vão solicitar serviços de outras – provavelmente as Classes-Entidade

• No final, se houver uma rsposta a ser dada pelo sistema, um método de alguma classe fronteiriça será mais uma vez invocado.


• Existem duas formas de se representar a interação ente objetos em UML. O Diagrama de Seqüência e o Diagrama de Colaboração.

• O primeiro mostra a evolução da tarefa através dos objetos ao longo do tempo.

• O segundo é voltado para ilustrar a dependência entre objetos para cada tarefa

6. Interação entre Objetos• Diagrama de Sequencia

UsuárioUsuário PublicaçãoReserva

Reservar()VerificaStatus(Usuário)

StatusUsuário

VerificaAcervo(Livro)

SituaçãoLivroAcervo

RespReserva


• Este cenário atende ao caso de uso Solicitar Reserva

• Naturalmente a representação é para o caso essencial, pois para o caso real haveria a necessidade de se estabelecer as classes fronteiriças


• Os métodos de cada classe começam a aparecer

• VerificaStatus() na classe Usuário e VerificaAcervo() na classe Livro.

• Além, evidentemente, de Reservar() na classe Reserva


• Alguns métodos são chamados Puros, Intrínsecos ou Imediatos:– Criar() – Cria uma nova instância de uma classe– Associar() – Associa uma classe a outra– Destruir() – Exclui uma instância ded uma classe– PegaXXX(), FazXXX() – XXX é um atributo, são

métodos que acessam atributos (para Ler ou Mudar seu valor)

• Estes métodos intrínsecos não precisam ser modelados


• A descrição de cada método pode ser feita em pseudo-código ou especificada formalmente.

• Os diagramas de colaboração propõem uma alternativa muitas vezes interessante


• Diagramas de Colaboração

Usuário

Usuário

Publicação

ReservaReservar(Publ)

Status=VerificaStatus(Usuário)

Disponibilidade =VerificaAcervo(Publ)

RespReserva


• Os diagramas de colaboração fornecem uma série de vantagens

• Mas não exprimem mui fielmente as complexidades de cada método no que tange ao código em si, independente de troca de mensagens


• Mensagens e Parâmetros

Classe2Classe1Mensagem()

Classe2Classe1Mensagem(Param1:tipo)


• Valor de Retorno• Sintaxe geral de uma mensagem (os tipos são opcionais em

modelos essenciais):Ret = msg(param1:tipo1, ...):TipoRetorno

Classe2Classe1Ret=Mensagem(Param1:tipo)


• Mensagens para a própria Classe (Self ou This em Linguagens de Programação

Classe1Msg()

ReservaCriar()

Usuário

Reservar(Publ)RespReserva


• Iteração: Usa-se um *. Possivelmente uma cláusula de teste

Classe2Classe1*(i=1..10) R=Mensagem()

Msg1()

6. Interação entre Objetos• Caso hajam múltiplas mensagens dentro da

mesma cláusula repete-se a cláusula de Iteração

Classe2Classe1*(i=1..10) R1=MensagemA()

Msg1()

Classe3*(i=1..10) R2=MensagemB()

6. Interação entre Objetos• Não seria mais simples usar

Para i=1 até 10 faça {R1 = Classe2.MensagemA()R2 = Classe3.MensagemB()

}???

• Parece que muitas vezes é melhor seguir pela informalidade!!!!!


• A interação entre objetos é extremamente útil para ilustrar a troca de mensagens

• Por conseguinte, os métodos de cada classe

Usuário-Nome-Privilégio-StatusVerificaStatus()

Reserva-DataInício-DataFim-DataReservar()

Publicação-Título-Autor-Assunto-Editora-AnoVerificaAcervo()


• A implementação (código) de cada método, qualquer que seja a linguagem, ainda é uma tarefa de criação acima de tudo

7. Transição de Estados• Em muitos casos é interessante ilustrar o comportamento de uma certa classe• Em UML isso é feito através do Diagrama de Transição de Estados (Grande Novidade...)• O DTE descreve

– o ciclo de vida de uma dada classe– os eventos que causam a transição de um estado para outro – as ações resultantes da mudança de estado

7. Transição de Estados

• Estado• Uma das possíveis condições na qual o objeto

pode existir• Compreende todas as propriedades do objetos• Em UML um estado é representado por um

retângulo de bordas arredondadas


• Um Estado

Nome do Estado

7. Transição de Estados• Estados e Atributos• Estados podem ser distinguidos pelos valores assumidos por certos atributos

Publicação Disponível

Num_Exemplares >= 0

Publicação não Disponível

Num_Exemplares = 0

• Estados e Associações• Estados também podem ser distinguidos pela

existência de certas associações

• Professor pode estar Ensinando (há associação) ou Licensiado(não há)


0..*1Professor Curso

• Estados Especiais:– Inicial

• Único• Obrigatório

– Final• Múltiplos (possivelmente)• Opcional


• Evento• Uma ocorrência que acontece em algum ponto

no tempo• Pode modificar o estado de um objeto• Pode gerar uma resposta


• Transição• É a mudança do estado atual para o estado

subseqüente • Resultado de algum estímulo• O estado subseqüente pode ser igual ao estado

original• Pode ocorrer em resposta a um evento• As transições rotuladas com o nome dos eventos


• Exemplo


Curso AbertoCurso Completado

Adicionar Aluno

Registro fechado

• UML: Uma ferramenta poderosa• Orientação a Objetos: Abordagem inteligente• Não é melhor, não modela mais• Mas é mais fácil e mais rápido

8. Conclusão

• Problemas com a codificação ainda não resolvidos

• Problemas de gestão de desenvolvimento de sistema ainda não resolvidos

• Problemas de métrica de custos e tempo de desenvolvimento – mal foram tocados

8. Conclusão

• A última palavra ainda não foi dada...

8. Conclusão

FIM!

“As perspectivas de sobrevivência da raça humana eram bem maiores quando éramos

indefesos contra os tigres do que hoje, indefesos que somos contra nós mesmos”

Arnold ToynbeeEscher

uml - unified modeling language Álvaro vinícius de souza coêlho [email protected]

Documents