P R O F. M E .

H É L I O

E S P E R I D I Ã O

AS TREVAS

• No final dos anos 80 e início dos anos 90, tínhamos muitos

conflitos de definições e nomenclaturas na área de modelagem.

• A escolha para utilização de um determinado padrão era

definido mais pelo “gosto” pessoal do que por fatores técnicos

oferecidos.

• Então, os três mais respeitados nomes nesse campo, cada qual

com seu conceito e implementação de modelo, Ivar Jacobson

(OOSE – Object Oriented Software Engineering), Grady

Booch (The Booch Method) and James Rumbaugh (OMT –

Object Modeling Technique) decidiram por fim aos debates e

trabalhar juntos na definição de um modelo único que veio a

ser a UML.

UMA “PLANTA” DO SEU SISTEMA

• UML permite que você “desenhe” uma “planta” do

seu sistema.

C A S O S D E U S O

AGREGAÇÃO

• Tipo especial de associação

• Demonstra que as informações de um objeto precisam ser complementadas por um objeto de

outra classe

• Um losango na extremidade da classe que contém os objetos-todo

COMPOSIÇÃO

• Uma variação do tipo agregação

• Representa um vínculo mais forte entre objetos-todo

e objetos-parte

• Objetos-parte têm que pertencer ao objeto-todo

• O todo não existe (ou não faz sentido) sem as partes

• Ou, as partes não existem sem o todo

ESPECIALIZAÇÃO GENERALIZAÇÃO

• Identificar super-classe

(geral) e subclasses

(especializadas)

• Semântica “é um”

• Tudo que a classe geral

pode fazer, as classes

específicas também podem.

• Atributos e métodos

definidos na classe-mãe são

herdados pelas classes-filhas

ESPECIALIZAÇÕES DE FUNCIONÁRIO

C A S O S D E U S O

Objetivo é a compreensão do comportamento externo do sistema por qualquer stakeholder

Adota uma linguagem simples

Acessível ao cliente

Stakeholder: público estratégico e

descreve uma pessoa ou grupo que

tem interesse

CASO DE USO

• Diagrama mais abstrato da UML

– Diagrama mais abstrato da UML

• usado no início da modelagem do sistema

– Especificação de requisitos

• Apresenta uma visão externa geral das funções e serviços do sistema

– Define o que o sistema faz

– Não se preocupa em como o sistema faz

FUNCIONALIDADE

• Um caso de uso indica uma funcionalidade que o

sistema deve oferecer

– Abrir conta, Sacar, Verificar Saldo, etc.

COMPONENTES DO DIAGRAMA

• Atores: Quem executa a funcionalidade

• Casos de Uso : Qual é a funcionalidade

• Relacionamentos: Como atores e casos de uso se relacionam

ATORES

• Os atores representam os papéis desempenhados pelos diversos usuários Cliente, Caixa do

Banco, Gerente, etc

• Casos de Uso descrevem interações entre o sistema e estes atores

• Atores podem ser Pessoas que interagem com o sistema Um hardware especial que dispara

uma interação Outro software que comunica com o sistema

• O ator é algo (usuário, software ou hardware) que não faz parte do sistema mas que interage

com ele em algum momento

EXEMPLOS

• Atores:

FUNCIONALIDADES

• Definem os serviços, tarefas ou funções do sistema

• Os nomes indicam ação (verbos) Cadastrar venda : loja Sacar : banco Consultar um filme :

locadora

R E P R E S E N T A Ç Ã O D E C A S O S D E U S O

R E P R E S E N T A D O S P O R E L I P S E S : U M T E X T O D E N T R O D E S C R E V E A F U N C I O N A L I D A D E D O C A S O D E U S O

RELACIONAMENTOS

• Representam as interações ou associações entre:

• Atores e Casos de Uso

• Dois ou mais Casos de Uso

• Dois ou mais Atores

• Principais tipos de relacionamentos Inclusão Extensão Generalização

ASSOCIAÇÕES

INCLUSÃO (INCLUDE)

• Utilizado quando um caso de

uso é usado dentro de outro

caso de uso

• Os relacionamentos de

inclusão indicam

obrigatoriedade

• A execução do primeiro

obriga a execução do

segundo

EXTENSÃO DE CASO DE USO

• Geralmente usado em funcionalidades

opcionais de um caso de uso

• Exemplo: cenários que somente

acontecerão em uma situação

específica Se uma determinada

situação for satisfeita

• Extensão pode necessitar um teste

para determinar se o caso de uso será

estendido