UML - parte 1

www.labes.ufpa.br

Abril de 2015

ESPECIALIZAÇÃO EM P

PROJETO DE SOFTWARE COM UML (DOCUMENTAÇÃO DE ARQUITETURA DE SOFTWARE)

PROF. RODRIGO QUITES REIS

easo5ware, ufpa, 2015 1

www.labes.ufpa.br


Obje9vo da Disciplina

•  Fornecer ao aluno a capacitação no uso de UML para documentar Requisitos e Arquitetura de So5ware

•  Engenharia Avante –  Construção de modelos como forma de se refinar o entendimento dos requisitos, estabelecer o comportamento, e gerar código/esquemas de banco de dados

•  Engenharia Reversa –  Geração de documentação a par9r de so5ware já desenvolvido

www.labes.ufpa.br Conteúdo

•  Visão Geral sobre o Processo de Engenharia de So5ware

•  Revisão de Orientação a Objetos •  UML

–  Histórico –  Núcleo da UML –  Especificação de Requisitos –  Arquitetura de so5ware

•  Exemplos e Exercícios permeiam a disciplina


www.labes.ufpa.br

Orientação a Objetos


www.labes.ufpa.br Antes da Orientação a Objetos

•  Modelo predominante: Programação Estruturada –  Estrutura de Sequência

•  Ação1; Ação2; Ação3; Ação4; Ação5; –  Estrutura de Seleção

•  Se, então, senão –  Estrutura de Repe9ção

•  Repe9r … Até ; •  Enquanto …;



•  Programação Estruturada – Muito código foi desenvolvido e con9nua operacional –  Dificuldades em manter e reu9lizar código em grande escala

–  Principais unidades de manutenção/reuso: •  Módulos funcionais

–  Procedures e Func9ons (Pascal) –  Func9ons (em C)



•  Abstrações Procedimentais


Problema

Proc proc1; Begin

... End; Proc proc2(a,b,c); Begin

... End; FuncJon f1(x, y); Begin

... End; Begin

// principal End;

Programa em Pascal

Mapeamento

Mecanismos de abstração da Programação Estruturada: Procedimentos e funções

www.labes.ufpa.br Orientação a Objetos

•  Obje9vos –  Facilitar o mapeamento do Problema para Código executável •  O mundo não é composto por procedimentos •  Estrutura é relacionável com Matemá9ca Discreta

–  Facilitar a manutenção e reu9lização •  Classes são cápsulas que englobam (estruturas de dados + operações) com controle de acesso

•  Modificações tendem a ficar restritas a um módulo



•  Conceitos básicos –  Classe & Objeto –  Composição de objetos –  Herança de Classes (sub-‐9pos) – Método & Mensagem



•  Abstração Orientada a Objetos


Problema

Classe Pessoa { ...

} Classe Obra {

... } void main() { … }

Programa em C++/Java

Mapeamento

Mecanismos de abstração da Orientação a Objetos:

Classes, Métodos, Herança, Composição, etc.


•  Conceito: Classe –  Definição de um conjunto de objetos que compar9lham estrutura e comportamento comuns

–  Objetos são criados a par9r das classes –  Na construção de uma classe, a abstração mais importante diz respeito aos dados

–  O principal modelo semân9co adotado é a Teoria dos Conjuntos (para definição dos dados)



•  Conceito: Classe e Objeto


Funcionário Nome: João Cargo: Analista Grupo: Desenvolvimento

Nome: Maria Cargo: Gerente Grupo: Desenvolvimento

Classe (conjunto)

Objetos (elementos do

conjunto)


•  O uso de computador é baseado em abstrações –  Abstração: representação simplificada da realidade, segundo um ponto de vista

–  Exemplos: •  Zeros e Uns para representar valores de portas eletrônicas de um computador

•  Linguagens de Programação •  Interface gráfica baseada em Mouse e Janelas



•  Abstrações


Booch, 1991


•  Conceito: Encapsulamento


Booch, 1991


•  Encapsulamento


htp://www.dsc.ufcg.edu.br/~jacques/cursos/p2/html/oo/objetoconta.gif


•  Encapsulamento –  Influência dos circuitos integrados

–  Podem ser livremente combinados

–  Não podem ser modificados



•  Encapsulamento & Mensagens –  “Muralha” em volta do objeto –  No funcionamento do sistema, objetos respondem mensagens de outros objetos

–  Alteração no estado interno do objeto só através dos métodos


Objeto

Encapsulamento


•  Encapsulamento & Mensagens


Void violacao { ObjetoExterno o; o.Nome = “Fulano”; o.Endereco = “Av. Tal”; ....

Void não_viola { ObjetoExterno o; o.setNome(“Fulano”); o.setEndereco(“Av. Tal”); ....


•  Encapsulamento & Mensagens –  Lei de Deméter


X Y z

obj

obj.mensagem(parâmetros)

mensagem(p) begin ... // qualquer valor manipulado aqui é x, y, z ou p. end;


•  Outros elementos importantes –  Classificação

•  Associar objetos às classes –  Associação

•  Conexão entre objetos –  Agregação

•  Um objeto é composto por outro –  Generalização/Especialização

•  Herança



•  Classificação



•  Associação (ou conexão) entre objetos –  Objetos exis9ndo de forma associada –  Poderoso mecanismo de reu9lização de objetos –  Exemplo: Biblioteca


Biblioteca = usuário reserva obra

www.labes.ufpa.br Orientação a Objetos •  Agregação: componentes de so5ware/hardware


System

Subsystem 1 Subsystem 2 Subsystem 3

Assembly a Assembly b Assembly c

So5ware Program y Hardware Device x

Notação para acesso em OO: System.subsystem2.assemblyc.y


•  Generalização/Especialização


Classes




Funcionário

Proje9sta

Engenheiro

Gerente


•  Estado, Comportamento e Iden9dade de Objetos – Estado: •  Conjunto de valores armazenados em um objeto

– Comportamento: •  Ações que o objeto pode realizar, isto é, o conjunto de métodos implementados na classe associada

–  Iden9dade: •  Todo objeto é criado com uma chave primária implícita determinada pelo sistema (Object Iden9fier -‐ OID) •  O OID é usado para definir conexões entre objetos



•  Estado, Comportamento e Iden9dade de Objetos

easo5ware, ufpa, 2015 28 Estado Comportamento IdenJdade

www.labes.ufpa.br

Processo de Análise e Projeto Orientado a Objetos




Problema

Análise Orientada a Objetos

Solução


31

Processo Top-‐Down BD Relacional

Classes OO

Consulta SQL

Métodos (algoritmos)

easo5ware, ufpa, 2015


•  Orientação a Objetos e Modelo Relacional

32

Banco deDadosRelacional

InterfaceGráficacomUsuário


InterfaceGráficacomUsuário

Modelo deObjetos doNegócio


Modelo deObjetos doNegócio

InterfaceGráfica c/Usuário

Processo Bottom-Up Arquitetura de 3 camadas

easo5ware, ufpa, 2015

www.labes.ufpa.br

O Modelo MPS de So5ware e seu relacionamento com

Análise/Projeto de Sistemas


www.labes.ufpa.br MPS.BR

•  MPS.BR –  Programa de Melhoria do Processo de So5ware e Serviços de TI voltado a pequenas e médias empresas brasileiras

•  MR-‐MPS-‐SW – Modelo de Referência para Melhoria do Processo de So5ware com base no CMMi-‐DEV

–  600+ avaliações realizadas – Modelo de maturidade brasileiro Avaliação da qualidade de so5ware através do seu processo de construção


www.labes.ufpa.br Programa MPS.BR


www.labes.ufpa.br

Níveis de Maturidade


www.labes.ufpa.br Níveis de Maturidade MPS-‐SW

37 easo5ware, ufpa, 2015

www.labes.ufpa.br Processo GRE


www.labes.ufpa.br Níveis de Maturidade MPS


www.labes.ufpa.br Processo PCP


www.labes.ufpa.br Processo DRE


www.labes.ufpa.br

Um rápido histórico da UML


www.labes.ufpa.br Histórico da UML

•  Diversas metodologias e métodos surgiram para apoiar OO –  Evolução a par9r de linguagens C++ e SmallTalk –  Anos 80-‐90: diversidade de autores –  Anos 98-‐2000: unificação em torno de UML



•  Exemplos de Notações –  Classes


Booch

Schlaer-Mellor

OMT Coad-Yourdon


•  A diversidade de notações para representar sistemas orientados a objetos nas décadas de 1980 e 1990 criou o caos para –  Desenvolvedores e Empresas de So5ware –  Fabricantes de Ferramentas –  Treinamentos

•  Cenário ideal para unificação em torno de uma única notação



•  Grady Booch –  Um dos pioneiros da OO –  1980: ênfase em técnicas de projeto para Ada –  1992-‐1994: livros

•  Object-‐Oriented Design with Applica6ons –  projeto de programas em C++ e Ada


Bastante a9vo no Twiter @Grady_Booch


•  1994: Object-‐Oriented Analysis and Design with Applica6ons

•  texto sobre conceitos de OO e modelagem de objetos

•  projeto de várias aplicações-‐exemplo com diferentes linguagens da época

•  base de UML para o Design

–  1998: Fundação da Ra9onal



•  Ivar Jacobson – Modelagem OO baseado em Casos de Uso

–  Objectory •  Processo centrado em casos de uso que fornece a base teórica usada atualmente no Unified Process



•  James Rumbaugh –  Object Modeling Technique (OMT) –  Desenvolvida na GE – Metodologia baseada em notações pré-‐existentes (ER, DTE, DFD) –  Clara dis9nção entre as três visões do problema –  Base da UML para Análise



•  James Rumbaugh (cont.)




Booch

Rumbaugh

OMT

Jacobson

OOSE

UML



Metodologia Booch OMT

Unified Method 0.8OOPSLA ´95 Unified Method 0.8OOPSLA ´95

OOSEOutras metodologias

UML 0.9Web - June ´96

OOSEOutras metodologias

UML 0.9Web - June ´96 UML 0.9Web - June ´96 UML 0.9Web - June ´96

Período deFeedback

público

Período deFeedback

público

Submissão final ao OMG, Set ‘97

1a submissão ao OMG, Jan ´97UML 1.1

Aceitação como padrão OMG, Nov 1997Submissão final ao OMG, Set ‘97

1a submissão ao OMG, Jan ´97UML 1.1

Aceitação como padrão OMG, Nov 1997UML 1.4UML 1.4UML 1.4

UML 1.0Parceiros UML UML 1.0UML 1.0Parceiros UML

UML 2.1OMG: Object Management Group

UML 2.4.1



Meyer

Before and after conditions

Meyer


Meyer


Harel

Statecharts

Harel

Statecharts

Harel

StatechartsGamma, et al

Frameworks and patterns,

Gamma, et al


Gamma, et al


HP Fusion

Operation descriptions and message numbering

HP Fusion


HP Fusion


Embley

Singleton classes andhigh-level view

Embley


Embley


Wirfs-Brock

Responsibilities

Wirfs-Brock

Responsibilities

Wirfs-Brock

Responsibilities

Odell

Classification

Odell

Classification

Odell

Classification

Shlaer - Mellor

Object lifecycles

Shlaer - Mellor

Object lifecycles

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Rumbaugh

OMT

Booch

Booch method

Booch

Booch method

Jacobson

OOSE

Jacobson

OOSE


•  O que é UML –  Linguagem visual para especificação (modelagem) de sistemas orientados a objetos •  Fornece representação gráfica para os elementos essenciais do paradigma de objetos –  Classes, atributos, objetos, troca de mensagens, ...


Pessoa Comitê

Membro-‐de

Presidente-‐de

{subconjunto}

0..*

0..*

0..* Telefone Celular

Usuário

Uso programado


•  O que é UML – De propósito geral •  Não está presa a uma etapa do desenvolvimento de so5ware –  Análise –  Projeto –  Implementação –  Testes

•  Não está presa a um processo –  Ciclo de vida em cascata –  Incremental –  Processo Unificado –  ...

•  Não está presa a uma linguagem de programação



•  UML apóia o desenvolvimento incremental


Usuário Serviço habilita

data

* *

Serviço habilita

data

* * Serviço

Nome Preço

Usuário Nome CPF

Serviço habilita

data

* * Serviço

Nome Preço

Usuário Nome CPF

suspende(período)

Modelos podem evoluir com a inclusão de novos detalhes Analogia: aula com transparências sobrepostas

www.labes.ufpa.br UML

•  O que é UML –  De propósito geral

•  Não está presa a uma linguagem de programação


Serviço habilita

data

* * Serviço

Nome Preço

Usuário Nome CPF

suspende(período)

public class Usuario { private String nome; private String cpf; private Vector lnkServico; }

Programador Java

Possível implementação


•  O que é UML – Padrão OMG •  Em htp://www.omg.org estão disponíveis documentos eletrônicos que contém – Sumário da UML – Semân9ca – Guia da Notação – Extensões da Linguagem



•  O que é UML –  Privilegia a descrição de um sistema segundo três perspec9vas: •  Dados (estrutural)

–  Diagrama de Classes

•  Operações (funcional) –  Diagrama de Caso de Uso

•  Eventos (temporal/dinâmica) –  Diagramas de Seqüência, A9vidades, de Transição de Estados



•  O Processo de Análise


Funções Dados Problema Análise

Eventos

Sistema (conceitual)

(entrevistas, leituras especializadas, brainstorming, etc.)


•  O Processo de Projeto


FunçõesDados Projeto

Eventos

Sistema(conceitual)

(resultado da análise)

•Mapeamento•Requisitos Arquiteturais•Requisitos da plataforma•Aspectos de deploy

Funções

Dados

Eventos

Outros Aspectos

www.labes.ufpa.br

Falando um pouco sobre ferramentas para UML


www.labes.ufpa.br

•  Astah

Algumas das principais ferramentas na atualidade


www.labes.ufpa.br

•  Astah –  iPad



www.labes.ufpa.br

•  Visual Paradigm



www.labes.ufpa.br

•  Enterprise Architect



www.labes.ufpa.br

•  Alguns critérios para avaliação –  Aspectos comerciais: preço, disponibilidade –  Suporte técnico –  Performance –  Usabilidade –  Exigências de Hardware –  Suíte (cobre todo o processo) ou Isolada –  Plataforma de Execução –  Integração com ferramentas de desenvolvimento existentes (IDEs,

Gerência de Requisitos, etc) –  Geração de Código e Esquema de BD (e importação) à conhecido em

inglês como round-‐trip engineering –  ...

Como estas ferramentas se diferenciam entre si?


www.labes.ufpa.br

Casos de Uso

Notação da UML e especificações textuais suplementares


www.labes.ufpa.br Casos de Uso

•  Resumo –  Um caso de uso é uma forma específica de uso do sistema composta por uma seqüência de ações que produz um resultado de valor para algum agente externo.

– Mostram apenas o que o sistema faz, não como. –  Capturam o comportamento pretendido para um sistema, sem a necessidade de especificar como esse comportamento será implementado.



•  Um caso de uso realiza um aspecto maior da funcionalidade do produto: – deve gerar um ou mais bene�cios para o cliente ou para os usuários

– Podem representar: •  roteiros de interação com usuário •  roteiros do manual de usuário •  casos de teste


Filho, W.P.P em “Engenharia de So5ware: Fundamentos, Métodos e Padrões”


•  Casos de Uso (CDU) –  Técnica para documentar os requisitos potenciais para um novo sistema ou para uma modificação em um so5ware;

–  Cada CDU provê um ou mais cenários que descrevem como o sistema deve interagir com seus usuários finais ou outros sistemas para a9ngir um obje9vo de negócio;

–  CDUs devem evitar jargão técnico, usando ao invés a linguagem do usuário ou do especialista de domínio.



•  CDUs não descrevem o funcionamento interno de um sistema tampouco explicam como o sistema deve ser implementado

•  Ao invés, mostram os passos que um usuário deve seguir para realizar uma tarefa.

•  Um CDU define interações entre atores externos e o sistema sob consideração para se a9ngir um obje9vo de negócio.

•  Atores são en9dades externas ao sistema. Um ator pode ser uma classe de usuários, um papel que usuários podem desempenhar, ou outro sistema.



•  CDUs são efe9vos para descrever requisitos funcionais, mas não para todos os 9pos de projetos. CDUs focalizam nas interações de um usuário com o sistema, ou em interações sistema a sistema.

•  Contudo, não são úteis em projetos onde a complexidade não está associada com a intera9vidade, e sim com a funcionalidade interna –  P.Ex: Processamento batch, Data Wareshousing, cálculos complexos

•  CDUs também não são adequados para descrever requisitos não funcionais. Entretanto, o raciocínio em cima de CDUs pode ser ú9l para iden9ficar requisitos de performance.



•  Casos de uso servem como guia para: – Criação e validação da arquitetura do sistema. – Definição de casos e procedimentos de testes. – Planejamento da iterações, elaboração de cronograma, organização do 9me.

– Criação da documentação do usuário.


www.labes.ufpa.br Modelagem de Casos de Uso

•  Notação Gráfica


Caixa eletrônico

Consultar saldo

Solicitar extrato

Realizar Saque Cliente Funcionário

Abastecer dinheiro

Recolher envelopes de

depósitos

[Furlan98]

Realizar depósito


•  Notação gráfica (em ferramenta CASE)


Consultar saldo

Emitir extrato

Realizar saque

Cliente

Realizar depós ito

Retirar envelopes de depósito

FuncionárioAbastecer com dinheiro


•  Oferecem uma maneira intui9va e sistemá9ca para capturar os requisitos FUNCIONAIS

•  Foco no conceito de “valor adicionado” (added value) ao cliente

•  Podem ser u9lizados para guiar o processo de desenvolvimento


[Unified So5ware Development Process – Jacobson, Booch, Rumbaugh]

www.labes.ufpa.br “Valor adicionado”

•  Perguntar aos clientes/usuários o que eles gostariam que o sistema fizesse não funciona: –  Lista de funcionalidades que pode parecer ú9l a princípio, mas na verdade... •  Ex: modificar endereço da cobrança

•  Estratégia de Caso de Uso: –  Refrazear para “O que você quer que o sistema faça PARA CADA USUÁRIO?”



•  Notação -‐ Elementos:

easo5ware, ufpa, 2015 79 Ator

Ator. Elemento externo do sistema que sempre inicia o uso ou recebe um valor do caso de uso

Caso de Uso. Serviço que o sistema fornece aos usuários.

Sistema

Caso de uso 1

Interação. Estímulos recebidos pelo sistema.

Sistema. Contexto aonde o caso de uso é utilizado


•  Conceito – CDU –  Normalmente associado com uma tela de entrada e/ou saída de dados, ou um relatório



•  Conceito -‐ Cenário –  Exemplo (Realizar Saque):

•  Saque com sucesso •  Tenta9va de saque MAS senha incorreta •  Tenta9va de saque MAS saldo insuficiente

–  Cada caso de uso encapsula uma coleção de cenários, tanto de sucesso como de falha.


Cliente

Realizar saque


•  Conceito -‐ Ator –  Qualquer coisa que possui interface com o sistema a ser desenvolvido

–  Definem um papel par9cular exercido por uma coisa ou pessoa

–  São sempre externos ao sistema


ClienteExemplo de Ator: (Sempre com aparência humanóide)


•  Conceito – Ator –  Uma mesma pessoa pode desempenhar diferentes papéis em um sistema

–  Cada papel é representado por um ator.


Funcionário AdministradorBeltrano

Papéis que pode exercer


•  Conceito -‐ Pacotes –  Servem para agrupar casos de uso relacionados –  Critérios para agrupamento:

•  Ator •  Funcionalidades correlatas •  Processos


Consultar saldo

Emitir extrato

Realizar saque

Cliente

Realizar depósito

PacoteCliente


•  Conceito – Comunicação Ator e CDU –  Representa quais atores estão ligados a quais casos de uso


Telefone Celular

A comunicação é representada através de um arco simples

Usuário Fazer ligação


•  Tipos de Interação –  Inclusão

•  Um caso inclui (precisa de, é composto de) outro •  Representada através de um arco pon9lhado com o rótulo <<inclui>> ou <<include>> (UML 1.4+) ou <<uses>> (UML 1.3-‐)

•  Normalmente um CDU componente é usado em mais de um outro


Telefone Celular

Usuário Fazer ligação Identificar destinatário

<<include>>


•  Tipos de Interação –  Extensão

•  Um caso de uso pode opcionalmente u9lizar um outro


Telefone Celular

Usuário Receber ligação

Receber Ligação Adicional

<<extend>>

Opcional


•  Extensão


Servir entrada Servir sobremesa

Servir refeição

<<extend>>

<<extend>>


•  Conceito -‐ Herança –  Generalização / Especialização

•  Pode ser aplicada para CDU e Ator


Super tipo

Sub tipos

Pagamento a vista Pagamento com cartão

Usuário Efetua pagamento


•  Conceito – Herança –  Herança de Atores


Administrador

Usuário Visitante

Correto? Usuário não é um 9po de Visitante


•  Conceito – Herança –  Herança de Atores


Atendente Realiza venda

Gerente Cancela venda

<<extend>>

Consulta estoqueFuncionário


•  Exemplo


Busca itens

Cliente

Solicita ajuda Sistema de ajuda online

Realiza pedido

Processador de pagamentos

Tempo Realiza pagamento de impostosAutoridade de impostos

1o release

2o release

3o release


•  Exemplo -‐ Telefone Celular


Telefone Celular

Usuário

Rede Celular

Fazer ligação

Receber ligação

Fazer uso programado

Fazer ligação em conferência

Receber ligação adicional

<<extend>>

<<extend>>

Iden9ficar des9natário

<<include>>


•  Exemplo


Cliente

Cliente Pessoa Física

Cliente Pessoa Jurídica

Sistema de Venda com Cartão de Crédito

Varejista

Administradora de

cartão de crédito

Transação

Venda

Cancelamento de venda

<<extends>>

Obs: padrão de análise


•  Caso de Uso Transação –  Abstrato

•  É usado como generalização –  É usado para representar serviços da organização que precisam ter a sua ocorrência registrada •  O registro obrigatoriamente contém

–  o momento em que ocorreu a transação (data/hora) –  quem par9cipou (cliente e vendedor) –  o quê esteve envolvido (o produto da venda)



•  Exemplo – Máquina de Venda de Bebidas


Vender bebidaConsumidor

Abrir máquina

Fechar máquina

Fornecedor

Repor Bebidas

<<include>>

<<include>>

Dono

Retirar dinheiro

<<include>>

<<include>>


•  Exemplo: Restaurante


Servir entrada Servir sobremesa

Servir almoço

Servir jantar

Cobrar refeição

Comprar bensFornecedor

ClienteServir refeição

<<extend>>

<<extend>>

<<include>>


•  Granularidade de CDUs –  Um CDU deve representar uma unidade de funcionalidade menor possível, que uma vez implementada, acrescenta valor (do ponto de vista dos autores) ao sistema

–  Exemplo em ATM bancário •  “Introduzir cartão” não é CDU (não tem valor isoladamente) •  “Realizar saque” é CDU pois tem valor para o corren9sta



•  Granularidade de CDUs –  Devido a dúvida sobre o valor de CDUs, o processo de modelagem é normalmente itera9vo



•  Heurís9cas (1) –  Evitar um número muito elevado de casos de uso

•  Fragmentar o sistema em sub-‐sistemas (ou em sub-‐pacotes) •  Usar casos de uso com denominação genéricas como Manter ou Gerenciar para descrever as funções de Cadastro de uma en9dade

•  Evitar detalhamento algorítmico



•  Heurís9cas (2) –  Diagramas de Caso de Uso têm sido usados para auxiliar no diálogo do usuário

–  Deve-‐se ter atenção para o fato que o diagrama tem semân9ca informal •  Isto é, não é preciso •  Para um mesmo problema, múl9plas soluções válidas são admi9das

•  Exige descrição textual para elucidação



•  Heurís9cas (3) –  Evitar o uso de <<include>> e <<extend>> nas primeiras iterações


www.labes.ufpa.br

Modelagem de Casos de Uso

•  Conceito – Modelo de Casos de Uso –  Modelo que descreve os casos de uso do sistema e atores relacionados.

–  Diagramas e especificações textuais

Atores Casos de Uso

Especificações de casos de uso


www.labes.ufpa.br Como encontrar Atores e CDUs?

•  Atores e CDUs são elementos de primeira ordem –  Atores: papéis desempenhados por usuários ou sistemas externos

–  CDUs: serviços fornecidos pelo sistema novo sendo concebido


www.labes.ufpa.br Como encontrar atores?

•  Quem usa o sistema? •  Quem instala/mantém o sistema? •  Quem inicia/desliga o sistema? •  Que outros sistemas usam o sistema? •  Quem recebe informação do sistema? •  Quem provê informação ao sistema?


www.labes.ufpa.br Como encontrar casos de uso?

•  Atores são fundamentais para a descoberta dos casos de uso •  Pergunte:

–  Que funções o ator vai querer do sistema? –  O sistema armazena informações? Que informações atores irão criar,

ler, atualizar ou apagar? –  O sistema precisa no9ficar o ator sobre mudanças no seu estado

interno? –  Existe algum evento externo que o sistema precisa saber? Que ator

informa o sistema desses eventos?


www.labes.ufpa.br

Escopo do sistema

•  É preciso delimitar as fronteiras do sistema –  Se a fronteira for o círculo interno, então Caixa e o Sistema Bancário são atores e não precisarão ser implementados.

Cliente

Caixa


Sistema BancárioSistema de Caixa Automático Qual é a

fronteira do sistema?

www.labes.ufpa.br

Especificação detalhada dos casos de uso


www.labes.ufpa.br Quando e por que realizá-‐las?

•  Quando? –  Após fazer levantamento dos principais casos de uso do sistema.

•  Por que? –  Descrever detalhes dos casos de uso –  Descrever fluxos de eventos e outras propriedades –  Uniformizar entendimento entre clientes, usuários e equipe de desenvolvimento.


www.labes.ufpa.br Especificando casos de uso

•  Casos de uso não precisam ser especificados todos de uma vez

•  Casos de uso devem ser priorizados por iteração – Prioridade técnica – Prioridade do usuário


www.labes.ufpa.br Especificação de um caso de uso

•  Iden9ficador •  Nome e breve descrição •  Ator(es) •  Prioridade •  Requisitos não funcionais associados •  Pré-‐condições •  Pós-‐condições •  Fluxo de eventos principal •  Fluxos secundários: alterna9vos e de exceção


www.labes.ufpa.br Iden9ficação do caso de uso


•  Deve ser única

•  Não deve mudar nunca, pois casos de uso podem ser referenciados por seu iden9ficador.

www.labes.ufpa.br Breve descrição do caso de uso


•  Dar uma idéia do propósito do caso de uso, do seu obje9vo

•  Deve ser feita ao se iden9ficar o caso de uso, para evitar mal-‐entendidos

•  2 ou 3 linhas!

www.labes.ufpa.br Atores

•  Descrição dos atores envolvidos com o caso de uso


Usuário Fazer ligação

Atores Descrição

Usuário É o responsável por iniciar e o principal interessado na realização de uma ligação. Para tanto, deve ser cliente de uma operadora de telefonia celular.

www.labes.ufpa.br Prioridades de casos de uso


•  Essencial para gerenciar requisitos e para montar iterações

•  Definir prioridade de todos os casos de uso •  Exemplo de classificação da prioridade:

–  Essencial –  Importante –  Desejável

www.labes.ufpa.br Pré e pós condições

•  O que deve ser verdade antes e depois da realização do caso de uso! –  Pré-‐condição:

•  estado em que o sistema deve estar para realizar o caso de uso.

–  Pós-‐condição: •  lista de possíveis estados em que o sistema pode estar imediatamente após o término da realização do caso de uso.


www.labes.ufpa.br

Pré e pós condições: exemplos

•  Caso de uso “Entregar pedido” –  Pré-‐condição: Os itens do pedido devem exis9r em estoque

–  Pós-‐condição: Os itens enviados devem ser aba9dos do estoque.

•  Caso de uso “Recadastramento de CPF” –  Pré-‐condição: o usuário deve possuir um CPF –  Pós-‐condição: a situação do contribuinte é atualizada.


www.labes.ufpa.br

Fluxo de eventos básico ou principal

•  Funcionalidade básica ou central do caso de uso •  Representa o caminho que é seguido na maioria das vezes que o caso de uso é executado.

•  Descreve a situação mais simples do caso de uso, na qual o obje9vo é a9ngido.

•  Pense nos fluxos secundários depois!


www.labes.ufpa.br

Exemplo de um fluxo básico

•  Caso de uso “Sacar dinheiro” 1. O cliente passa o cartão 2. O sistema solicita senha e valor do saque 3. O cliente digita os valores solicitados 4. O sistema verifica se há saldo suficiente 5. O sistema debita da conta do cliente o valor do saque.

6. O dinheiro é entregue ao cliente.


www.labes.ufpa.br

Exemplo de um fluxo básico

•  Caso de uso “Sacar dinheiro” •  MAS...

–  E se a senha não conferir? –  E se não houver saldo? –  E se não houver dinheiro suficiente na máquina? Calma, vamos deixar esses detalhes para depois!


www.labes.ufpa.br

•  Pré-‐condição: usuário não está suspenso •  1. Usuário solicita um item do acervo •  2. Funcionário verifica disponibilidade do item solicitado

•  3. Sistema informa a localização do item •  4. Funcionário registra o emprés9mo •  5. O sistema emite um comprovante do emprés9mo (em duas vias)


www.labes.ufpa.br Subfluxos

•  As vezes, o fluxo principal possui várias alterna9vas igualmente prováveis de ocorrer

•  Nestes casos, pode-‐se usar o conceito de subfluxos

•  Cada subfluxo representa um dos possíveis caminhos do fluxo principal


www.labes.ufpa.br

Subfluxos -‐ Exemplo

•  Caso de uso “Cadastrar Produtos” –  Fluxo básico

1. O funcionário seleciona a opção de cadastro, iniciando o caso de uso.

2. O sistema solicita que o funcionário indique a operação que deseja efetuar: inclusão, atualização ou remoção de produtos.

3. De acordo com a opção fornecida pelo funcionário, um dos subfluxos abaixo é executado.


www.labes.ufpa.br Subfluxos – Exemplo (2)

–  Subfluxo Incluir produto 1. O sistema solicita o nome, descrição e preço do novo produto. 2. O funcionário fornece os dados 3. O sistema gera um iden9ficador único para o produto e o armazena as

informações fornecidas. –  Subfluxo Alterar informações do produto

1. O sistema solicita o nome ou iden9ficador do produto a ser alterado. 2. O funcionário fornece o iden9ficador do produto. 3. Os sistema apresenta os dados do produto para alteração (os mesmos

dados solicitados no subfluxo “Incluir produto”) 4. O funcionário atualiza os dados do produto e o sistema armazena os

novos dados. –  Subfluxo Remover produto

...


www.labes.ufpa.br Fluxos secundários

•  Só devem ser analisados e descritos após a descrição dos fluxos básicos. –  Para cada CDU, perguntar: “o que pode dar errado?”, “o que pode ser diferente?”

•  Fluxos alterna9vos –  Situações especiais (desconto para um cliente)

•  Fluxos de erro –  Situações de erro


www.labes.ufpa.br Reuso de fluxos secundários

•  Fluxos secundários, principalmente de erros, podem ser referenciados por diferentes casos de uso

•  Evitar duplicação de informação!


www.labes.ufpa.br Resumo – Fluxos de eventos


•  Fluxo normal ou básico (“Happy Path”) –  Pode conter subfluxos

•  Fluxos alterna9vos –  Variações regulares –  Casos incomuns

•  Fluxos de exceção –  Tratam situações de erro do fluxo básico.

www.labes.ufpa.br

Requisitos não funcionais associados •  Listar RNFs associados ao CDU específico

–  Exemplos: •  Tempo de resposta (máximo de 2 seg para 100 transações concorrentes)

•  Segurança: Controle de acesso •  …


www.labes.ufpa.br


www.labes.ufpa.br Exemplo


www.labes.ufpa.br


Padrão do Ra9onal Unified Process


•  Comentário Final –  Os casos de uso são elementos muito importantes no Processo Unificado

–  Todas as a9vidades de desenvolvimento são organizadas em função dos casos de uso


www.labes.ufpa.br

Papel do Modelo de CDU no Processo

easo5ware, ufpa, 2015 134 Fonte: Alexandre Vasconcelos - O Fluxo de Requisitos

www.labes.ufpa.br Checklists: Modelo de Casos de Uso •  O modelo de caso de usos está fácil de se entender?

•  Estudando o modelo de caso de usos, você pode ter uma idéia clara das funções do sistema e como elas estão relacionadas?

•  Todos os requisitos foram levantados? •  O modelo de caso de usos contém algum comportamento supérfluo?

•  A divisão em pacotes do modelo de caso de usos está apropriada?


www.labes.ufpa.br Checklists: Atores

•  Todos os atores foram iden9ficados? •  Cada ator está envolvido com pelo menos um caso de uso? •  Cada ator desempenha um papel? Algum deveria ser fundido

com outro ou ser dividido em dois? •  Existem dois ou mais atores desempenhando o mesmo papél

em relação a um caso de uso? •  Os atores têm nomes intui9vos e descri9vos? Tanto os

usuários como os patrocinadores do so5ware têm um entendimento comum?


www.labes.ufpa.br Checklists: Casos de Uso

•  Cada caso de uso está envolvido com pelo menos um ator? •  Os caso de usos são independentes uns dos outros? •  Algum dos caso de usos tem comportamento ou fluxo de

eventos muito similares? •  Os caso de usos têm nomes únicos, intui9vos e explica9vos de

modo que não podem ser confundidos em um estágio posterior?

•  Os patrocinadores e usuários entendem os nomes e descrições dos caso de uso?


www.labes.ufpa.br

Checklists: Especificação de Caso de Uso

•  Está claro quem deseja executar um caso de uso? •  A finalidade de cada caso de uso está clara? •  A descrição breve dá uma idéia clara do significado do caso de uso? •  Está claro como e quando os fluxos de eventos de cada caso de uso

começam e terminam? •  A seqüência de comunicação entre um ator e um caso de uso está de

acordo com as expecta9vas do usuário? •  As interações e trocas de informação entre os atores e o sistema estão

claras? •  Existe algum caso de uso demasiadamente complexo? •  Os fluxos de eventos (básicos e alterna9vos) estão modelados de forma

clara?


www.labes.ufpa.br

Encadeamento dos diagramas da UML


www.labes.ufpa.br Processo Simplificado

•  Artefatos


Sistema

Usuário

XPTO

Diagrama de Casos de Uso

Diagrama de Classes

: Atendente : Atendente Tela de Geração de Conta

Tela de Geração de Conta

: Sessão : Sessão : Item : Item

conta : Contaconta : Conta

: Promoção : Promoção

1: gerarContaSessão(s)

2: obter(s)

3: s

4: obterItensConsumidos

5: obterItens

6: itens

7: itens

10: obterPreço

11: preçoUnitário

12: obterQuantidade(item)

13: quantidade

8: obterNome

9: nome

repetir enquanto houver itens na sessão de consumo

15: criar(s, i tens)

16: conta

17: conta

14:

Diagrama de Sequência e Colaboração

Planejado

Cancelado

transferência( novaData, novaHora ) / data := novaData; hora := novaHora

Pago

Realizado

Realizado com pagamento pendente

Realizado com pagamento antecipado


pagamentoEfetuado Realizado com pagamento antecipado

solicitaçãoPaciente / criarCancelamento(dataHoraAtual, motivo=paciente)

solicitaçãoMédico / criarCancelamento(dataHoraAtual, motivo=médico)

autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio ] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)

pagamentoEfetuado[ tipo == particular ]

Diagrama de Estados

Diagrama de AJvidades


•  Relacionamento entre artefatos (1)


Sistema

Usuário

XPTO








2: obter(s)

3: s


5: obterItens

6: itens

7: itens

10: obterPreço

11: preçoUnitário


13: quantidade

8: obterNome

9: nome



16: conta

17: conta

14:


Fornece os cenários

Valida as interações


•  Relacionamento entre artefatos (2)


Sistema

Usuário

XPTO


Diagrama de Classes

Fornece os cenários

Validas as interações (*)

(*) isto é, se não forem achadas as classes envolvidas em um CDU, há indícios que não se trata de um CDU em si.


•  Relacionamento entre Artefatos (3)


Diagrama de Classes







2: obter(s)

3: s


5: obterItens

6: itens

7: itens

10: obterPreço

11: preçoUnitário


13: quantidade

8: obterNome

9: nome



16: conta

17: conta

14:


Fornece objetos e classes

Valida o modelo e fornece detalhes

(atributos e operações)




Diagrama de Classes

Planejado

Cancelado

transferência( novaData, novaHora ) / data := novaData; hora := novaHora

Pago

Realizado


Realizado com pagamento antecipado


pagamentoEfetuado Realizado com pagamento antecipado

solicitaçãoPaciente / criarCancelamento(dataHoraAtual, motivo=paciente)

solicitaçãoMédico / criarCancelamento(dataHoraAtual, motivo=médico)

autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio ] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)

pagamentoEfetuado[ tipo == particular ]

Diagrama de Estados

Fornece os objetos e classes

Valida o modelo e fornece detalhes

(atributos e operações)



easo5ware, ufpa, 2015 145 htp://www.voxxel.com.br/pages/introdiauml.html

www.labes.ufpa.br

Diagrama de Classes

III.1 Modelagem de Dados III.2 Mapeamento para Banco de Dados III.3 Projeto com Interfaces III.4 Diagrama de Pacotes


www.labes.ufpa.br Diagrama de Classes

•  Resumo –  Diagrama base para qualquer discussão acerca da arquitetura de um sistema com UML



•  Propósito –  Representação dos dados manipulados e armazenados pelos programas de acordo com os conceitos de Orientação a Objetos

–  Notação fortemente baseada no Diagramas En9dade-‐Relacionamento de Peter Chen



•  Diagrama de Classe –  Notação


Nome da classe

atributo: 9po de dado atributo: 9po de dado = valor inicial

Operação(lista de argumentos): 9po do resultado

Opcionais (fornecidos somente após um melhor entendimento do sistema)


•  Aspectos tratados pelos Diagramas de Classe: Dados e Funções


Dados Funções

Eventos

Sistema

Obs: a ordem da execução das funções (aspecto temporal) não é tratada explicitamente nos diagramas de classe


•  Associações –  Permitem descrever as relações existentes entre os elementos (objetos) dos conjuntos (classes)


Livros

Pessoas Autor de

Escrito por


•  Associações


Livro Pessoa escrito por 0..* 1..*

Multiplicidade da associação

Rótulo da associação


•  Associações –  Interpretação:

•  Um objeto de Livro está associado com no mínimog um objeto de Pessoa, e no máximo com uma quan9dade indeterminada

•  Um objeto de Pessoa pode não estar vinculado com qualquer objeto de Livro ou com uma quan9dade indeterminada


Livro Pessoa escrito por 0..* 1..*


•  Associações –  Classes:

•  Nome de “Coisas” •  Rotuladas no Singular

–  Associações •  Leitura no sen9do “convencional” (esquerda para direita, de cima para baixo)




Jogador

Gol0..* +autor0..*

Relação

18..*

0..*

18..*

0..*

Substituição0..* +substituto0..*

0..*+substituído

0..*

Expulsão

0..*

+expulso

0..*Estádio

Arbitro

Torneio

Jogo

0..*0..*

+local

0..*0..*+principal

2

0..*+auxiliar2

0..*

1

0..*

+reserva

1

0..*

0..1

1..*

0..1

1..*

HistoriaEquipeJogo

0..*0..*

0..*0..*

0..*0..*

0..*

Equipe2

0..*

2

0..*

0..*0..*0..*

Exem

plo de

diagram

a conceitual

(9picamen

te produ

zido nas p

rimeiras iterações)

realizado em


•  Atributos


Pessoa

Nome: Str Endereço: { Logradouro: Str, Bairro: Str, Cidade: Str. } Telefones: Array of Int Obs: Atributos Compostos e

Multivalorados são permitidos pelo modelo de dados OO


•  Associações –  Observe: não há chave-‐primária


Livro

Título: Str ISBN: Int Editora: Str

Pessoa

Nome: Str Endereço: { Logradouro: Str, Bairro: Str, Cidade: Str. } Telefones: Array of Int

escrito por 0..* 1..*

Multiplicidade da associação

Rótulo da associação


•  Associações –  Papel de Classe/Objeto em uma Associação (em inglês, role)

–  Pode ocorrer simultaneamente com o nome (rótulo / label) da associação

–  O papel é usado na geração de código e BD


Livro

Título: Str ISBN: Int Editora: Str

Pessoa

Nome: Str Endereço: { Logradouro: Str, Bairro: Str, Cidade: Str. } Telefones: Array of Int

escrito por 0..* 1..* autor obra

Papéis


•  Atributos e Métodos


Conta Bancária

número saldo dataAbertura

criar() bloquear() desbloquear() creditar() debitar()

Pessoa

Nome: Str Endereço: {

Logradouro: Str, Bairro: Str, Cidade: Str. }

Telefones: Array of Int

1 0..*

9tular

dependente 0..2 0..*


•  Associações –  Exemplo de Geração de Código em Java


ContaBancariaPessoa 0..*

1

0..*

1

+titular possui

0..* 0..*+dependente 0..*0..*

Class ContaBancaria { String numero; float saldo; Date dataAbertura; Pessoa 9tular; Vector dependente; }

Omi9dos do diagrama por simplificação Os atributos que

Implementam as Associações não devem Ser inseridos no diagrama


•  Associações –  Exemplos: Associação Unária


Funcionário

0..1

*

Supervisiona

Funcionário

João

supervisiona

É supervisionado por




Funcionário

0..1

*

Supervisiona Funcionario

0..*

0..1 supervisiona

0..*

0..1+chefe

+subordinado

Evolução: acréscimo dos papéis facilita a implementação e o entendimento




l Class Funcionario { l Xxx; l Funcionario chefe; l Vector subordinado;

Funcionario0..*

0..1 supervisiona

0..*

0..1+chefe

+subordinado


•  Associações –  Navegabilidade das Associações

•  Associação binária e bidirecional


Funcionário Departamento 0..* trabalha 1

Funcionário trabalha em Departamento

Funcionário

João

Departamento

Financeiro



•  Associação binária e unidirecional


Funcionário Departamento 0..* trabalha

Funcionário

João

Departamento

Financeiro



•  Associação Unidirecional –  Razão da existência è mais fácil a implementação



•  Associações – Mul9plicidade: limiar inferior..limiar superior


Multiplicidade Significado 0..1 Zero ou um 1 Somente 1 (opcional)

0..* Maior ou igual a zero * Maior ou igual a zero

1..* Maior ou igual a 1 1..15 ( m..n) De 1 a 15 (m a n), inclusive


•  Exercício: qual o mais correto?


Funcionário Departamento 1 trabalha 0..1

Funcionário Departamento 0..* trabalha

Funcionário Departamento 0..* trabalha 0..*

(adaptado de BEZ02)


•  Exemplos

–  Funcionário = { João, Maria, José } –  Depto = {A, B} –  Trabalha = { (João, A), (Maria, B), (José, B)} –  Gerente = { (João, B), (Maria, A) }


Funcionário Departamento

trabalha 1 *

gerente 0..1




Financeiro

TI

João

Marcela

Amanda


trabalha 1 *

gerente 0..1


•  Exemplo


Financeira

código nome

Venda

data hora

Vendedor número nenha nívelAutorização

financia 0..1 * *

realizada por


•  Classes associa9vas –  Informação que surge a par9r da associação de duas outras classes

–  Podem ser anônimas –  Um objeto de classe associa9va está associado com exatamente um objeto de cada extremidade


Fulano, Cálculo I, INS, 75%, 1º 2005 Fulano, Cálculo I, BOM, 100%, 2º 2005 Beltrano, Mat, BOM, 90%, 2º 2005


•  Classes associa9vas


Pessoa

NomeEndereço: {Logradouro;

Bairro;Cidade. }

Sexo

marido

esposa

0..1

0..1

casamento DataRegime

Pessoa


Bairro;Cidade. }

Sexo

Pessoa


Bairro;Cidade. }

Sexo

marido

esposa

0..1

0..1


DataRegime

DataRegime



Pessoa


Bairro;Cidade. }

Sexo

marido

esposa

0..1

0..1


Pessoa


Bairro;Cidade. }

Sexo

Pessoa


Bairro;Cidade. }

Sexo

marido

esposa

0..1

0..1


DataRegime

DataRegime

Pessoa

João

Marcela

Amanda

Jorge

Abel

dataX regimeX

dataY regimeY


•  Classes associa9vas


Financeira

código nome

Venda

data hora

Vendedor número nenha nívelAutorização

financia 0..1 * *

realizada por

registroAprovação dataAprovação

Financiamento


•  Classes associa9vas –  Observação importante: o conceito de “Classe Associa9va” não é permi9do em todas as linguagens de programação e sistemas de banco de dados OO

–  Assim, em muitos casos as classes associa9vas encontradas em Análise são subs9tuídas por classes regulares em Projeto



•  Classes associa9vas –  Classe associa9va subs9tuída por normal


Obs: sempre vai ser mul9plicidade 1, neste caso

Original (Análise)

Modificado (Projeto)




Observar que neste caso a subs9tuição não é trivial visto que o objeto de devolução só é criado após a associação de Emprés9mo e Item.

www.labes.ufpa.br



•  Exercício – Fazer diagrama de classes para a súmula de campeonatos de futebol


www.labes.ufpa.br



•  Agregação –  Associa de todo/parte –  Ação realizada sobre todo a9nge as partes –  Tipo especial de associação


Documento Parágrafo Sentença 0..* 0..*

Documento Parágrafo Sentença 0..* 0..*

composto-por composto-por


•  Agregação –  Exemplo


Associação Espor9va

Equipe Jogador 0..* 0..* ◀ afiliada


•  Generalização/Especialização –  Todos os exemplos anteriores envolviam a ligação entre instâncias de classes (objetos)

–  Com a Herança, o relacionamento fornecido é o de subconjunto

–  Ú9l para definir hierarquias de classes (não de objetos!) que possuem propriedades comuns



•  Generalização/Especialização –  Associação do 9po “é um”


Cliente

nome

PessoaFísica CPF RG Sexo DataNascimento

PessoaJurídica

CGC RazãoSocial

Super-classe

Sub-classes (herdeiras)


•  Generalização/Especialização –  Em Ra9onal Rose


Cliente

PF PJ


•  Generalização/Especialização –  Polimorfismo de dados:

•  Uma associação pode ocorrer com objetos de diferentes classes (deste que tenham suas classes relacionadas por herança).



•  Generalização/Especialização –  Polimorfismo de dados: exemplo

•  não há necessidade de se criar uma associação entre Compra e subclasses de Cliente


Cliente

nome

PessoaFísicaCPFRGSexoDataNascimento

PessoaJurídica

CGCRazãoSocial

Compra*realiza

www.labes.ufpa.br



•  Generalização/Especialização –  Herança Múl9pla: caso especial


Veículo an�bio

Veículo

Veículo terrestre

Veículo aquá9co

Conceito pouco usado na prática: • Poucas linguagens de programação permitem o uso • Adiciona maior complexidade ao modelo


•  Generalização/Especialização –  Classe Abstrata

•  Classe que não instancia objetos. •  Serve apenas para gerar novas sub-‐classes a par9r da herança. •  Freqüentemente é uma classe ar9ficial, isto é, que não existe no Domínio do Problema e surge para acomodar propriedades comuns de classes concretas.

•  Representada com �tulo em itálico ou com uma restrição {abstrata} (ou {abstract})





Cliente

ContaBancária número dataAbertura saldo

debitar(quantia) creditar(quantia)

Transação

ContaCorrente

limiteSaque

ContaPoupança

dataAniversário

* *

Classe Abstrata

possui


•  Generalização/Especialização –  Em Ra9onal Rose


www.labes.ufpa.br



•  Restrições –  São regras especificadas com lógica ou com linguagem específica (*) para impedir / condicionar a criação de objetos e associações

–  Úteis para especificar regras de negócios no diagrama –  (*) Object Constrain Language -‐ OCL



•  Restrições – Exemplo {ou} –  Restrição {ou} implica na seleção exclusiva entre duas ou mais associações existentes em uma classe


Conta corrente

Indivíduo

Organização

0..*

0..* 0..1

0..1

{ou}

cliente

cliente


•  Restrições


Conta corrente

Cliente

Organização

0..* 0..1

cliente

Indivíduo

Conta corrente

Indivíduo

Organização

0..*

0..* 0..1

0..1

{ou}

cliente

cliente

Obs: são equivalentes Notar classe abstrata


•  Restrições


Contrato de Seguro

Indivíduo

Empresa

0..*

0..* 1..*

1..*

{ou}

Contrato

Cliente

Organização

0..* 1..*

Indivíduo OBS: Não são equivalentes!

Por que?


•  Restrições


Significado: seja uma pessoa (empregado), seu empregador é mesmo do seu chefe


•  Restrições –  Restrição {subconjunto} ou {subset}

•  Estabelece relação de subconjunto entre duas associações


Pessoa Comitê

Membro-‐de

Presidente-‐de

{subconjunto}

0..*

0..*

0..*


•  Restrições


Pessoa Comitê

Membro-‐de

Presidente-‐de

{subconjunto}

0..*

0..*

0..*

Pessoa = {joão, josé, maria} Comitê = { é9ca, licitações } Membro-‐de = { (joão, é9ca), (josé, licitações), (maria, licitações),

(maria, é9ca) } Opções (A) Presidente-‐de = {(joão, é9ca), (maria, licitações)} (B) Presidente-‐de = {(maria, licitações), (maria, é9ca)} (C) Presidente-‐de = {(josé, é9ca)} (errado, não é subconjunto de Membro-‐de) (D) Presidente-‐de = {(maria, licitações)} (errado, pois cada comitê deve possuir um presidente – e, no caso, é9ca não tem presidente)


•  Restrições



trabalha 1 *

gerente 0..1

{subconjunto}

Funcionário = { rodrigo, carla, dio } Departamento = { informá9ca, administração } (A) Trabalha = { (rodrigo, informá9ca), (dio, administração), (carla, informá9ca) } Gerente = { (rodrigo, informá9ca) }

[errado, pois o departamento de administração não possui gerente] (B) Trabalha = { (rodrigo, informá9ca), (dio, administração) , (carla, administração) } Gerente = { (dio, informá9ca) , (dio, administração) }


•  Restrições: exemplos diversos


Empregado

salário chefe

{Empregado.salário < Empregado.chefe.salário}

Janela comprimento largura

{0,8<=comprimento/largura<=1,5} Cargo

prioridade

{prioridade nunca cresce}

1..*

1

Janela Tela Visível em

{ordenado}

*




Pessoa

Nome Endereço: { Logradouro;

Bairro; Cidade. } Sexo

marido

esposa

0..1

0..1 casamento

Data Regime

{pessoa.sexo=Feminino}

{pessoa.sexo=Masculino}




Pessoa

Nome Endereço: { Logradouro;

Bairro; Cidade. } Sexo

cônjuge 0..1

0..1 casamento

Data Regime

{pessoa.sexo <> pessoa.cônjuge.sexo}


Restrições: exemplos diversos




Pessoa = { joão, maria, márcio, fulano, beltrano} Condomínio = { Greenville I, Greenville II, Costa e Silva } condômino = { (joão, greenville I),

(maria, greenville II), (márcio, greenville II), (fulano, costa e silva), (beltrano, costa e silva) }

Síndico = { (joão, greenville I), (márcio, greenville II), (fulano, costa e silva) }

Pessoa Condomínio

condômino

síndico

*

{subconjunto}

0..1


•  Restrições


Conta Bancária


criar() bloquear() desbloquear() creditar() debitar()

Pessoa

nome: Str endereço: { logradouro: Str, bairro: Str, cidade: Str. } telefones: Array of Int

1..* * corren9sta

9tular

{subconjunto}

*



Conta Bancária


Pessoa

nome: Str endereço: { logradouro: Str, bairro: Str, cidade: Str. } telefones: Array of Int

1..* * corren9sta

9tular

{subconjunto}

*

Conta Bancária = { 001, 002, 003 } Pessoa = {rodrigo, carla, fulana } Corren9sta = { (001, carla), (002, rodrigo), (001, rodrigo)

(001, fulana) (003, fulana) (003, rodrigo} Titular = { (001, rodrigo), (002, rodrigo) , (003, rodrigo), (001, carla) }



Conta Corrente


PessoaJurídica

nome: Str

1..* * corren9sta

9tular

{subconjunto}

* 1

PessoaFísica

Representante

1..* *



Aluno Turma 1..*

representante * {subconjunto}

Exemplo válido: Aluno = { amanda , breno } Turma = {01, 02} Representante = { (amanda, 01), (amanda, 02) } Membro = { (amandav, 01), (amanda, 02), (breno, 01) }

1..*


•  Transmutação ou Metamorfose de Objetos – Monitor, Professor, Aluno: herança


Pessoa

Aluno Professor

Monitor


•  Transmutação ou Metamorfose de Objetos – Monitor, Professor, Aluno: herança

•  Problemas –  Acomodação inábil de objetos que mudam de classes


Pessoa

Aluno Professor

Monitor


•  Transmutação ou Metamorfose de Objetos –  Solução Geral: Combinar herança e associação


PapelPessoa

Aluno Professor Monitor

Pessoa *

nome cpf dataNascimento

exerce

matrícula matrícula

1. Início: 01/02 2. Início: 01/11 Fim: 31/12

3. Fim: 31/12 4. Início: 01/01/próximo ano

0. criação

dataInicio dataFim


•  Erros Comuns –  Usar classes ou associações para representar consultas ou operações do sistema que não devem ser registradas •  Exemplo 1


Usuário Acervo consulta


•  Erros Comuns –  Usar classes ou associações para representar consultas ou operações do sistema que não devem ser registradas

–  Exemplo 2


Usuário Consulta faz *


•  Erros Comuns –  Iden9ficar métodos nas classes sem ter feito a modelagem temporal


O que é sintonizar? - Quem usa? - Quais os parâmetros?


•  Erros Comuns –  Inserir atributos quando o ideal é criar uma classe


Canal

EstiloMusical

Refere-se a

*


•  Erros Comuns –  Usar herança quando a quan9dade de 9pos é grande ou dinâmica


EstiloMusical

Pagode Rock Axé

EstiloMusical

Nome: string


•  Erros Comuns –  Inserir chaves-‐estrangeiras no diagrama de classes

•  As associações são suficientes


Funcionário

codFunc codDepto

Depto

codDepto ...

trabalha *

Chave primária? Usar OID!

Chave estrangeira? Redundante!

UML - parte 1

Software

Transcript of UML - parte 1