Você está na página 1de 94

Índice

• Introdução • Fase Evolutiva


Análise
• Conceitos OO
APSOO • Análise de Sistemas OO
- Fluxo de Eventos
- Cenários
• Introdução a UML - Casos de Teste
- Rascunho de IU
• Desenvolvimento de software - Diagrama de Seqüência
Francisco Araújo Lima • Método OO Projeto
• Fase Exploratória - Diagrama de Comunicação
- Diagrama Transição de Estados
- Declaração de Objetivos
Julho / 2010 - Diagrama de Casos de Uso
- Completar diagrama de classe
- Projeto final da IU
- Diagrama de Classes - Projeto de Estruturas de Dados
- Ambiente Tecnológico Programação
- Planejamento da Fase Evolutiva Teste

Araújo 1 Araújo 2

Introdução ... ... Introdução ...


Modelo Modelar é
• Representar de forma gráfica ou textual partes reais ou
• Representa de forma abstrata e simplificada nosso imaginárias do sistema
entendimento de uma parte do mundo real • Por no papel a concepção que se tem de como funcionará
• Permite simular, testar, prever o funcionamento do o sistema concebido
sistema modelado • Fazer o projeto de um BD
• Captura aspectos do mundo real observado • Documentar de forma gráfica ou em texto um sistema
existente (engenharia reversa):
• Ex.: maquete de obra, modelo reduzido de barragem, – croquis de uma edificação
aeromodelo, planta de edificação, especificação textual – planta de um navio
de uma casa, escultura, modelo de dados,... – modelo de dados de um sistema em funcionamento

Araújo 3 Araújo 4
... Introdução ... ... Introdução ...
Modelo de dados Mundo real Abstração Modelo de dados
• Conjunto de conceitos que descrevem a estrutura e as
operações de um banco de dados Projetos Aloca Funcionários
• Representa o entendimento que se faz a respeito de
entidades do mundo real
Fornece Lota
• Modelo de dados é uma representação abstrata e
simplificada dos objetos do mundo real adequada às
aplicações que usarão o banco de dados
Produtos Fornecedores Departamentos

Araújo 5 Araújo 6

... Introdução ... Introdução ...


Evolução da Modelagem de Dados... Modelos são abstrações que:
• retratam a essência de um problema ou de uma
Semântica MODELAGEM DE estrutura do mundo real facilitando o entendimento
INFORMAÇÕES • focam no que é importante em cada instante, deixando
(OBJETOS)
os detalhes para depois (abstração)
• representam em escala reduzida, numa dada
perspectiva, um sistema existente ou a desenvolver
SEMÂNTICA
(SDM, MER-E)
Abstração é uma maneira de se enfrentar a
complexidade dos problemas de software
E-R (DADOS)

Araújo Tempo 7 Araújo 8


... Introdução ... ... Introdução ...
Características OO ... ... Características OO
Hierarquização Encapsulamento (ocultação de informação)
• após dividir um computador em CPU, vídeo e teclado, é
possível subdividir a CPU em memórias RAM, ROM, disco, • forma de esconder detalhes de armazenamento
processador,... dos dados e implementação de operações,
• é possível fazer o mesmo com sistemas aplicativos, protegendo-os contra acesso indevido
hierarquizando-os via divisão em subsistemas
• possibilita o uso de algo sem que se conheça
Classificação
como foi construído ou implementado
• enquadramento dos objetos em categorias (classes),
conforme suas características e suas funções • usa-se carro com injeção eletrônica sem
• mamífero que mia é gato, que late é cachorro necessitar saber detalhes de implementação da
• uma bicicleta e um automóvel são meios de transporte mesma
tendo em vista sua funcionalidade
Araújo 9 Araújo 10

... Introdução ... ... Introdução ...


UML - Unified Modeling Language A TRÍADE DO DESENVOLVIMENTO
- linguagem usada para visualizar, especificar e documentar • O método é essencial
o desenvolvimento de sotware de forma OO Método
(RUP, OPEN, • A notação padroniza a
- não é uma linguagem de programação nem uma SCRUM, XP) comunicação
metodologia de desenvolvimento de software • A ferramenta agiliza
Metodologistas OO (notações diferentes): automatizando
•Rumbaugh - OMT - forte em análise • Dá para trabalhar sem uma
•Booch - forte em projeto Notação Ferramenta ferramenta
•Jacobson - forte em análise de requisitos (UML) (ROSE, JUDE, • Fica muito ruim sem uma
EA, POSEIDON) notação conhecida
UML unifica as 3 notações e contempla o melhor
• É improdutivo sem método
de cada uma delas e de outras metodologias OO
Araújo 11 Araújo 12
... Introdução Conceitos de OO ...
• OBJETO - algo sobre o que se armazenam dados e as
O MÉTODO
operações que manipulam esses dados. Ex.: aluno,
Fase Exploratória Fase Evolutiva mestre, veículo, disciplina, nota fiscal, reserva aérea, tela de
• Declaração de Objetivos Várias iterações com: uma aplicação, um ícone,...
• Diagrama de Casos de Uso • Análise • OBJETO (dados e operações) é diferente de ENTIDADE
• Diagrama de Classes • Projeto (apenas dados)
• Ambiente tecnológico • Programação • Um objeto pode ser composto por outros objetos
• Planejamento da fase (computador => monitor, teclado; pedido => itens do pedido)
evolutiva • Teste edclass
Trial Version
Class Mo...

ed TrialPedido
Version ItemDoPedido
1..*

Araújo 13 Araújo
ed Trial Version 14

... Conceitos de OO ... ... Conceitos de OO ...


OBJETO - tem suas propriedades representadas por dados e Identidade do Objeto (OID)
seu comportamento, pelas operações (métodos) • um identificador independente dos atributos do objeto, gerado
automaticamente (surrogate key), sem qualquer semântica
• Operações de um objeto: • o programador de aplicação nem vê o valor desse OID
– manipulam os dados desse objeto Propriedades(dados): código do livro, título do livro, nome do aluno,...
– não acessam diretamente dados de outro objeto Operações(métodos): emprestar livro, cancelar reserva livro, depositar
dinheiro na conta, admitir funcionário, ...
• Operações do objeto reservaDePassagem: Estado do objeto: conjunto de valores que um objeto armazena num
– cancelar a reserva, confirmar a reserva, ... dado instante;
a mudança do valor de um atributo, muda o estado do objeto;
• Dados do objeto reservaDePassagem: um objeto após ser acionado, mantém o estado (seus dados);
– data da reserva, hora da reserva, status da reserva, ... diferente de uma função (linguagem estruturada) que sempre funciona
• Objeto tem: identidade, propriedades, operações e estado “iniciando do zero”

Araújo 15 Araújo 16
... Conceitos de OO ... ... Conceitos de OO ...
...Tipos de Método: ...
Tipos de Método: ... (Método–implementação de
class Livro { // sem encapsulamento
Operação)
String nmLivro; // atributos
Construtor (do tipo NEW) String nmAutor;
• Tem o mesmo nome da classe }
• É executado quando um objeto é criado public class TestLivro { // classe p/ testar Livro
public static void main (String [ ] args) {
• Usualmente inicializa variáveis de objeto Livro lv = new Livro(); // lv-nova instância de Livro
Destrutor (do tipo DELETE) lv.nmLivro = ("O Guarani");
• É executado quando um objeto é destruído lv.nmAutor = ("José de Alencar");
• Usado para liberar recursos do sistema (RAM) System.out.println("Nome Livro = " + lv.nmLivro);
System.out.println("Nome Autor = " + lv.nmAutor); }
• Nem todas LPOO suportam }
Araújo 17 Araújo 18

... Conceitos de OO ... ... Conceitos de OO ...


...Tipos de Método: ... ...Tipos de Método:
Acessador (do tipo GET) public class Livro { // Java Bean Component
private String nmLivro; // atributos
• Retorna o valor de um atributo
private String nmAutor;
• Permite que objetos externos acessem dados public Livro() { setNmLivro(""); // construtor
encapsulados de outro objeto setNmAutor(""); }
Alterador (do tipo SET) public String getNmLivro() {return nmLivro;} // operações
• Armazena valor em um atributo public String getNmAutor() {return nmAutor;}
• Permite que objetos externos alterem dados public void setNmLivro(String nmL) {nmLivro = nmL;}
encapsulados de outro objeto public void setNmAutor(String nmA) {nmAutor = nmA;}
}
Araújo 19 Araújo 20
... Conceitos de OO ... ... Conceitos de OO ...
...Tipos de Método: MENSAGEM...
public class TesteLivro { // classe p/ testar Livro
public static void main (String [ ] args) {
Livro lv = new Livro(); // lv nova instância de Livro Dados Dados
lv.setNmLivro ("O Guarani");
Operações Operações
lv.setNmAutor ("José de Alencar");
System.out.println("Nome Livro = " + lv.getNmLivro()); • Os dados de um objeto devem ser acessíveis
System.out.println("Nome Autor = " + lv.getNmAutor()); apenas através de suas operações
} • Os objetos comunicam-se através de mensagens
} (solicitações de execução de operação)
Araújo 21 Araújo 22

... Conceitos de OO ... ... Conceitos de OO ...


...MENSAGEM...
...MENSAGEM... • Solicitação de execução de uma operação em outro objeto
obj1 obj2 • Requisição feita por um objeto remetente a um receptor
obj2.op21 • Conteúdo da mensagem especifica dados a serem
op14 op11 op24 op21 passados para que a operação possa ser executada pelo
objeto receptor
op23 op22
• Objetos relacionam-se e uns solicitam colaboração aos
op13 op12 obj1.op13 outros via troca de mensagens
• Similar a uma empresa onde os departamentos se
relacionam e, uns solicitam serviços a outros, via
Um objeto pede a outro que execute uma de suas operações mensagens

Araújo 23 Araújo 24
... Conceitos de OO ... ... Conceitos de OO ...
...MENSAGEM... ...MENSAGEM
• Meio através do qual um objeto Ob1 pede a outro • Formato de mensagem:
objeto Ob2 que execute uma de suas operações objDestino.oper (argsEntrada, out argsSaida)
• Para enviar mensagem a Ob2, Ob1 deve saber: Ex.: produto.obterPreco(), conta.depositar(val)
- o OID de Ob2 (armazenado em uma variável)
- o nome da operação de Ob2 a ser executada • Notação UML objeto
- os argumentos necessários à execução da oper.
obterPreco ( )
it:ItemNF p:Produto
Cliente obtervlNF( ) NotaFisc obtervlLinNF( ) LinNF

• call obter vlNF (nf) – seria o equivalente não OO obterPreco () é uma operação da classe Produto
Araújo 25 Araújo 26

... Conceitos de OO ... ... Conceitos de OO ...


Objeto Cone class Cone {
int r; double h; double a; double v;
• Propriedades do cone: raio da base, altura void calcVol (int r, double h) {v = 3.14 * (r * r) * h / 3;}
void calcVol (double h, int r) {v = 3.14 * (r * r) * h / 3;}
• Operações do cone: void calcAreaBase (int r) {a = 3.14 * (r * r);}}
- calcular o volume class TesteCone {
- calcular a área da base public static void main (String [] args) {
Cone c = new Cone();
- calcular a área da superfície lateral c.calcVol(2, 6.0);
• Mensagens enviadas ao objeto cone: c.calcAreaBase(2);
System.out.println("Vol = " + c.v);
– calcVolume(R,H) método: {PI * R ** 2 * H / 3} System.out.println("Area = " + c.a);
– calcAreaBase(R) método: {PI * R ** 2} c.calcVol(6.0, 2);
System.out.println("Volum = " + c.v); }}
Araújo 27 Araújo 28
... Conceitos de OO ... ... Conceitos de OO ...
Objeto contaCorrente
abrir
• Propriedades: número da conta, saldo, tipo, ...
Conta
saldo médio, data da última movimentação encerrar
obterSldMed Conta
• Operações: abrir conta, encerrar conta, obter nrCta
vlSld
saldo, depositar, sacar, obter saldo médio vlSldMed
• Exemplos de mensagens enviadas ao objeto dtUltMov obter
depositar
contaCorrente: Saldo
emitir
– contaCorrente.obterSaldo ( ) sacar
Extrato
– contaCorrente.depositar (2560.00)
Objeto Conta Corrente: Dados + Operações
Araújo 29 Araújo 30

... Conceitos de OO ... ... Conceitos de OO ...


...OBJETO
OBJETO...
• Os valores dos atributos variam de uma instância para
• tem interface e implementação outra; as operações são as mesmas para todas instâncias
• a implementação é privada e pode ser alterada • Por economia de memória, apenas uma cópia de cada
operação de instância é armazenada
sem afetar a interface
• Há operações e atributos de instância (de objeto)
• a interface é pública e permite acesso a outros (responsabilidade de cada objeto)
objetos • Há operações e atributos de classe (responsabilidade da
classe); ex.: operações new (cria novo objeto),
• mensagem é formada por objeto e método a ser obterQtAlunos, atributo qtAlunos,,... (static em Java)
aplicado ao objeto: conta.obterSaldo ou • O conjunto de atributos e operações de uma classe, vale
conta.saldo para todos seus objetos não importa quantos objetos tenha
a classe
Araújo 31 Araújo 32
... Conceitos de OO ... ... Conceitos de OO ...
ENCAPSULAMENTO... ... ENCAPSULAMENTO
• Conjunto de atributos (propriedades) e de • usuário sabe o que um objeto pode fazer mas não conhece
operações do objeto de forma que apenas estas detalhes de como ele faz
possam acessar e alterar os atributos do objeto • garante a um objeto que envia uma mensagem não
precisar conhecer a estrutura interna do receptor
• A execução de cada operação (procedimento ou
• facilita a manutenção: alteração de objeto afeta apenas
função) pode ser solicitada por outros objetos seus dados e operações (maior controle)
• As operações formam uma camada protetora em • permite desenvolvimento, compilação e teste isolados
torno do núcleo que contém os dados • código cliente apenas conhece (sabe usar)a interface das
• Encapsular atributo: private operações do objeto servidor, logo não é afetado por
alterações na implementação do servidor

Araújo 33 Araújo 34

... Conceitos de OO ... ... Conceitos de OO ...


CLASSE CLASSE X OBJETO ...
• conjunto de objetos com características estruturais e • com base na planta de uma casa, diversas
funcionais semelhantes. Ex.: Aluno, Mestre, Veículo,
casas de um conjunto habitacional podem ser
Disciplina, NotaFiscal,...
• possui estrutura de dados e métodos que determinam as
construídas
operações que podem ser executadas sobre os dados dos • cada casa construída, terá seu endereço, sua
objetos da classe cor, seu proprietário,... propriedades
• a classe serve de molde para a criação dos seus objetos • a planta representa a classe
• algo que encapsula dados e comportamentos
um objeto é uma instância de uma classe • as casas construídas objetos

Araújo 35 Araújo 36
... Conceitos de OO ... ... Conceitos de OO ...
Definição da classe Conta
... CLASSE X OBJETO
class Conta {
Instanciação // definindo atributos
String nrCta;
double vlSld;
Classificação
// definindo métodos
void Creditar (double val) {vlSld = vlSld + val;}
Classe Objetos void Debitar (double val) {vlSld = vlSld - val;}
}

Araújo 37 Araújo 38

... Conceitos de OO ... ... Conceitos de OO ...


class CtaEncapsulada {
Criação e manipulação de objeto da classe Conta private String nrCta;
class CriaConta { private double vlSld;
public static void main (String [ ] args) { public String getNrCta() { return nrCta; }
public void setNrCta (String aNrCta) { nrCta = aNrCta; }
Conta ct = new Conta (); public double getVlSld() { return vlSld; }
ct.nrCta = “345-6”; public void setVlSld(double aVlSld) { vlSld = aVlSld; }
ct.vlSld = 0; public void Creditar (double val) {vlSld = vlSld + val;}
public void Debitar (double val) {vlSld = vlSld - val;} }
ct.Creditar(140.00); class TesteCtaEncapsulada {
ct.Debitar(80.00); public static void main (String [ ] args) {
System.out.println(“Saldo=“ + ct.vlSld); }} CtaEncapsulada ct = new CtaEncapsulada ();
ct.setNrCta("345-6");
Compilando o programa.... javac CriaConta.java ct.setVlSld(0);
Executando o programa....: java CriaConta ct.Creditar(140.00);
Resultado da execução..... Saldo=60.0 ct.Debitar(80.00);
Araújo 39 Araújo System.out.println("Saldo=" + ct.getVlSld()); }} 40
... Conceitos de OO ... ... Conceitos de OO ...
HERANÇA ... ... HERANÇA
•uma subclasse herda da superclasse, tanto os
atributos (propriedades) quanto as operações Conta Conta de poupança herda conta
(métodos) Propriedades Propriedades
• número
•uma subclasse pode ter atributos e operações • aniversário
• titular
próprios além dos que herda da classe mãe • saldo • saldo-min-do-periodo
•uma operação em uma subclasse pode redefinir Operações Operações
• abrir • calcular rendimentos
(override) a operação de mesma assinatura em uma • depositar
classe ascendente • fazer retirada
• sacar
•pode ser simples ou múltipla • encerrar
Araújo 41 Araújo 42

... Conceitos de OO ... ... Conceitos de OO ...


Conta Conta de Poupança Generalização ...
• GENERALIZAÇÃO - formação de superclasses a partir
de outras classes; ...é um ..., ...é do tipo..., ...é um
abrir depositar abrir depositar subconjunto de ... Professor
Número cdProf : Integer
Número sacar sacar nmProf : String
Titular
Titular Especialização Generalização
Saldo
Saldo
encerrar SldMinDoPer encerrar
Aniversário
fazer retirada
Concursado Visitante
calcular rendimento classif : Integer nmInstituicao : String
dtConcurso : Date periodo : String
Herança
Araújo 43 Araújo
Concursado é um professor 44
... Conceitos de OO ... ... Conceitos de OO ...
GENERALIZAÇÃO... MER ...GENERALIZAÇÃO...
Func
Generalização pode ser Total (T), Parcial (P),
Exclusiva (E) ou com Interseção (I)
Engenh Secretar Gerente Mensalist Comission
Pessoa Pessoa {P,I}
1 1 {T, E}
nr-crea toq-p-hora sal-mes vlc
Gerencia Emite Nomeado Concursado
3 Espec de Func:
Homem Mulher {P,E}
Engenh/Secretar
1 N
Gerentes
Projeto N.Fiscal Restrição (UML)
Mensalist/Comission Eng. Secret.
Araújo 45 Araújo 46

... Conceitos de OO ... ... Conceitos de OO ...


...GENERALIZAÇÃO... ...GENERALIZAÇÃO... Restrição
• Generalização Total (T) - todo objeto da superclasse {P,E}
Funcionário
{T,E}
está em uma das subclasses
• Generalização Parcial (P) - algum objeto da
superclasse não está em nenhuma subclasse Secretária Engenheiro Mensalista Comissionista
• Generalização Exclusiva (E) - um objeto da
superclasse não pertence a mais de uma subclasse
• Generalização com Interseção (I) - um objeto da Herança Subclasse
superclasse pode estar em mais de uma subclasse Múltipla Eng-Mensalista
compartilhada
Araújo 47 Araújo 48
... Conceitos de OO ... ... Conceitos de OO ...
...GENERALIZAÇÃO...
É importante modelar subclasses quando: ...GENERALIZAÇÃO...
• Certos atributos aplicam-se somente a alguns e não a Automóvel Caminhão
todos os objetos da superclasse (CPF só para pessoa • Placa • Placa
física ; uma subclasse é um conjunto de objetos ao qual • Marca
estes atributos se aplicam • Marca
• Km • Km
• Alguns relacionamentos podem envolver apenas os
objetos da subclasse (apenas os comissionistas emitem • AnoFabricação • AnoFabricação
nota fiscal, apenas os gerentes gerenciam projetos, ... ) • Preço • Preço
• Uma instância de uma subclasse não pode se tornar • NrPassageiros • Tonelagem
uma instância de outra subclasse (classe irmã) • VelocidadeMáxima • NrEixos

Araújo 49 Araújo 50

... Conceitos de OO ... ... Conceitos de OO ...


...GENERALIZAÇÃO Veiculo • Herança múltipla – uma classe pode ter mais de uma
placa superclasse
marca
anoFabric • Classe abstrata – não gera instância e existe apenas
km
preco em hierarquias Gen / Espec (nome da classe em
itálico na UML)
• Uma classe abstrata pode ter subclasses abstratas,
Automovel Caminhao mas nos níveis mais baixos (especializados) devem
qtPassageiros qtEixos estar classes concretas
velMaxima tonelagem
• Uma classe abstrata Java pode ter operação concreta
Caminhão “é um” veículo (operação com implementação)
Automóvel jamais será um caminhão
Araújo 51 Araújo 52
... Conceitos de OO ... ... Conceitos de OO ...
abstract class Animal { // Herança POLIMORFISMO
String a = "dados comuns aos animais";
public Animal() {System.out.println("Apanhando " + a);}} • operações com mesma assinatura atuam de forma
abstract class Mamifero extends Animal {
protected String m = "dados comuns aos mamiferos"; diferente conforme o objeto receptor da mensagem
public Mamifero() {System.out.println("Apanhando " + m);}}
class Leao extends Mamifero {
• calcular área (retângulo, triângulo)
String l = "dados de um leao"; • baixar (um bem, uma duplicata, um pedido)
public Leao () {System.out.println("Apanhando " + l);}}
class TesteGenEspec { • sacar dinheiro de conta (de poupança, corrente,
public static void main (String [ ] args) { especial)
System.out.println("Instanciando leao .............");
Leao le = new Leao(); o método varia conforme a classe referenciada
System.out.println("Exibindo ......................");
System.out.println("Exibindo " + le.a);
System.out.println("Exibindo " + le.m);
System.out.println("Exibindo " + le.l); } }
Araújo 53 Araújo 54

... Conceitos de OO ... ... Conceitos de OO ...


Sobrecarga de Método Redefinição Sobrecarga
Uma classe pode ter métodos sobrecarregados, • Overriding • Overloading
ou seja, métodos com mesmo nome mas com • Assinaturas iguais • Assinaturas diferentes
parâmetros diferentes (interfaces distintas): • Operações em • Operações em uma
• altPreco (cdProd, valor) classes diferentes mesma classe, em geral
• altPreco (percent) • Classe filha tem nova • Exemplo:
• impExtrato (mês) implementação para impExtrato (mês)
método herdado impExtrato (dtIni, dtFim)
• impExtrato (dtIni, dtFim)
Araújo 55 Araújo 56
... Conceitos de OO ... ... Conceitos de OO ...
Interface ... ...Interface <<entity>>
Clien
(from Cli)
• É um conjunto de especificações de serviços (operações)
<<Int erface>> nrCli <<Interface>>
• Um serviço tem especificação e implementação (método) Ifax nmCli Ifone
vlLimCred
• A especificação define “o que” o serviço (operação) faz nrFone
passarFax() nrFax discar()
• A implementação define “como” o serviço é feito
• As operações de uma interface têm apenas especificação discar()
Marketing passarFax() Cobranca
• Há semelhança entre interface e classe abstrata
• Uma interface não gera instância, não contém atributos e
Quando as classes Marketing e Cobranca
todas as operações são abstratas usam as Interfaces Ifax e Ifone, tudo se
passa como se usassem a classe Clien
Araújo 57 Araújo 58

... Conceitos de OO ... ... Conceitos de OO ...


Outra notação Cliente Cliente realiza (implementa) Uma classe pode implementar mais de uma interface
para Interface a interface Ifone <<Interface>>
nrCli Cobrança depende de Ifone <<Inte rface >>
IV oa r
vlLim Cred IN avegar
Ifax Ifone
nrFone levantarVoo()
nrFax navega r()
ate rrissa r()
atracar()
voar()
H idroAviao
Marketing discar() Cobranca
pass arFax() atracar()
navegar()
. As interfaces Ifax e Ifone são realizadas pela classe Cliente levantarVoo()
Simula herança
. A classe Cliente implementa as operações especificadas nas aterrissar()
voar() múltipla
Interfaces Ifax e Ifone
Araújo 59 Araújo 60
... Conceitos de OO ... ... Conceitos de OO ...
IVoar
Interface – tem apenas as assinaturas das operações
Interfaces INavegar
Classe Abstrata – não instanciável mas pode ter alguma
navegar() levantarVoo() operação concreta
atracar() aterrissar() Realização
voar()
<<entity>>
Login
<<Interface>>
<<realiza>> cdU ILogin
Hidro Aviao nmU
Aviao
senha
a tra car() vercdU()
navegar() levantarVoo()
levantarVoo()
verSenha()
aterrissar() vercdU()
aterrissar() voar()
Araújo voar() Aviao() 61 Araújo
verSenha() 62

... Conceitos de OO ... ... Conceitos de OO ...


< <Interface >> public interface IVoar <<In te rfa c e >>
Interface IColecao { public void levantarVoo(); IV oa r
classe
abstrata
public void aterrissar();
equals()
add() public void voar(); } le va nta rVo o ()
public class Aviao implements IVoar a te rris s a r()
{ public Aviao() vo a r()
Li sta
P ed ido
< <Interface >> { }
ILi sta
itensPed[*] equals() public void levantarVoo()
<<realiza> > < <r e aliza >>
get() add() {//acelera e sobe; recolhe trem de pouso }
get()
public void aterrissar()
{//bx trem de pouso; desacelera; freia } Avia o
public void voar()
dependência A rrayList
{ // mantém motores funcionando } le va nta rVo o ()
a te rris s a r()
get() }
Martin Fowler add()
vo a r()
Araújo 63 Araújo 64
... Conceitos de OO ... ... Conceitos de OO ...
Eco Isom
<<usa>>
Eco Isom interface Isom { void soar(); }
abstract class Animal implements Isom { emitirSom(t : Isom) : void soar()
abstract public void soar(); }
emitirSom() soar()
class Cao extends Animal {public void soar()
{ System.out.println("Au, au!"); } } Animal Relogio
<<realiza>> class Gato extends Animal {public void soar()
{ System.out.println("Miau, miau!."); } } soar() soar()
Anim al
class Eco {
static void emitirSom(Isom t)
soar() { t.soar(); } }
Gato Cao Cuco
class Executar {
public static void main(String[] args) {
soar() soar() soar()
Animal g = new Gato();
Cao G ato Eco.emitirSom(g); <<instancia>>
Animal c = new Cao();
TesteAnimal
Eco.emitirSom(c); } }
soar() soar()
Araújo 65 Araújo main() 66

... Conceitos de OO ... ... Conceitos de OO


Visibilidade das Operações (C++) Cliente
Visibilidade em Java
A D
PesFísica pode usar : op1() Variável ou Pode ser
op1( ) // pública op2() Método em A acessado por
op3( ) // protegida op3() -------------------- --------------------- B
opf1( ) + Público A, B, C , D , E
opf2( ) // privada
opf3( ) # Protegido A, B, C , D C E
opj1( ) P esFis ica P es Juridic a
Pacote A, B, D
opf1() opj1()
opf2() opj2()
opf3() - Privado A Maior encapsulamento
opj3()

Araújo 67 Araújo 68
Modelagem OO ... ... Modelagem OO ...
• A modelagem tradicional tende a quebrar os Por que OO?
objetos para facilitar a implementação • Linguagem do pessoal de TI coincide com a
• A modelagem OO mantém a mesma linguagem do usuário: ambas tratam de objetos
representação de alto nível da aplicação, da do mundo real
análise à implementação. • A modelagem OO fornece uma representação
• BD visto como uma coleção de objetos mais natural do mundo real
complexos inter-relacionados • Do mundo real à máquina não precisa mudar
notação de modelagem (mapeamento)
• Facilita reuso e manutenção
Araújo 69 Araújo 70

... Modelagem OO
Análise de Sistemas Tradicional
• Possibilidade de reuso dos objetos em mais de
uma aplicação Perspectiva dos Dados Perspectiva dos Processos
- MER - Análise dos requisitos
• A análise de sistemas OO é basicamente uma - MER Æ MR - DFD
técnica de abstração para identificação de - Esquema Relacional - Codificação
classes de objetos e os relacionamentos entre
elas que permitem a troca de mensagens entre
os objetos para a realização das funcionalidades DD integra as
duas perspectivas Dicionário de Dados
e mantém a con- - Repositório de Informações
- Preservação de Consistência
sistência

Araújo 71 Araújo 72
Análise de Sistemas OO ... ...Análise de Sistemas OO...
Identificação de Casos de Uso
Perspectiva da Orientação a Objeto • Identificar as funcionalidades (requisitos funcionais)
do sistema que serão descritas e implementadas
- Identificação de Casos de Uso através dos Casos de Uso (seqüência de operações)
- Identificação de Objetos e seus Atributos • Ex.: matricular aluno numa disciplina,
- Identificação de Relacionamentos trancar matrícula,
- Identificação das Operações de cada Objeto alterar cargo do funcionário,
transferir funcionário entre departamentos

Araújo 73 Araújo 74

...Análise de Sistemas OO... ... Análise de Sistemas OO ...


Identificação de Objetos Identificação de Operações
• Encontrar conjuntos (classes) de objetos com estrutura e
Há três tipos comuns de operação:
comportamento comuns
• Uma classe deve ter propriedades e operações que • Inclusão / Exclusão: abrir / encerrar conta
“valham a pena” ser mantidas pelo sistema • Consulta / Cálculo: informar saldo, calcular IOF
• Ex.: escritórios situam-se em cidades ; cidade é um de uma conta no período
atributo de escritório ou um objeto da classe cidades?
• Se cidade tem propriedades (nome, área, população,..),
• Atualização: depositar em uma conta, sacar
operações e tem existência própria independentemente do dinheiro de uma conta
seu relacionamento com escritório, então cidade deve ser
um objeto da classe cidade
Araújo 75 Araújo 76
... Análise de Sistemas OO ... ... Análise de Sistemas OO ...
“Diagrama de Classe” UML
Exemplo ...
...Exemplo classe empresa
classe conta-corrente herda conta classe hotel propriedades
propriedades propriedades nome: string; nom, ender, fone:
ender: string; propriet: empresa; string
saldo : dinheiro;
servicos: set(opçao); ... operacoes ...
operações gerent : pessoa; fim empresa
cadastrar() --> conta-corrente; operacoes
depositar (valor : dinheiro) cadastrar(); classe pessoa
reserv-ap(nr-ap: integer; hosp: propriedades ....
sacar (valor : dinheiro) pessoa; dt-in, dt-sai: date) operacoes ...
fim conta-corrente. fim hotel. fim pessoa.
Araújo 77 Araújo 78

... Análise de Sistemas OO ... ... Análise de Sistemas OO ...


“Diagrama de Objeto” UML • As propriedades gerente e proprietário são objetos
Instância de Empresa e não chaves estrangeiras como no modelo
Instância de Hotel relacional ou ponteiros como no modelo hierárquico.
Nome: Azulmar Nome: Xico Silva S/A
Ender: R. do Ceu. 25 • É possível acessar as propriedades gerente e
Ender: Av. do Mar, 38 Fone: 234.1654 proprietário de dentro do objeto hotel sem explicitar
Propriet: (instância de junções (joins)
empresa) Instância de Pessoa • A implementação física do SGBDOO pode até
Gerent: (instância de Nome: Zemaria Silva executar um join ou fazer buscas via ponteiros, mas
Ender: Av. da Lua, 34 estas operações são detalhes de implementação do
pessoa)
DtNasc: 10.10.50 SGBD, ficando portanto escondidas do usuário
Serviços: sauna, tênis

Araújo 79 Araújo 80
... Análise de Sistemas OO Introdução a UML ...
O modelo de caso de uso:
Relacional Orientado a Objeto
FUNC(nom, dtnasc, sal) • documenta o comportamento de um sistema,
PESSOA(nom, dtnasc)
• morrer isto é, suas funcionalidades
• morrer
• casar • casar • mostra as funções do sistema (casos de uso)
• receber salário • mostra o ambiente externo ao sistema (atores)
FUNC(salario)
ALUN(nom, dtnasc, nota)
• receber salário • exibe os relacionamentos entre atores e casos
• morrer
ALUNO(nota) de uso (diagrama de casos de uso)
• casar
• ser avaliado (6 proc) • ser avaliado (4 proc)

Araújo 81 Araújo 82

... Introdução a UML ... ... Introdução a UML ...


Ator - interage, de fora, com o sistema: Usuário não é a mesma coisa que Ator
• Usuário é alguém que usa o sistema
• fornecendo-lhe dados
• Ator representa o papel que um usuário
• recebendo informações do sistema desempenha junto ao sistema
• fornecendo dados e recebendo informações • Um usuário pode desempenhar mais de um
Atores num sistema de recursos humanos: papel (João pode usar o sistema como gerente
– funcionário, sistema de contabilidade, ... e como vendedor)
Atores num sistema de controle acadêmico: • Um ator pode ser representado por mais de um
usuário ( Zé e Sá são exemplos de vendedor)
– aluno, professor, departamento...

Araújo 83 Araújo 84
... Introdução a UML ... ... Introdução a UML ... P ed ido

P a gam e nto
DIAGRAMA DE CONTEXTO
Identificação de atores (entidades externas) De v oluç ão
P ed ido ao
Fo rn ec e do r
C lie nte

• que grupo de usuários recebe informações do sistema? C o nfir m aç ã o


P ed ido F or ne c ed or

• que grupo de usuários fornece dados para o sistema? P ag am en to ao


Fo rn ec e do r

• que grupo de usuários usa o sistema para realizar suas N ota F is c al


S a ída
N ot a F is c a l

tarefas? F atu ra d o
1
E ntr ad a
F a tur a do
F o rn ec e do r
C om pr a

• onde o sistema será usado na empresa? R e em bo ls o


C lie nte
e V en da
de
M e rc a do ria s

• quem se beneficiará com o uso do sistema?


• o sistema interage com algum sistema externo? P o lític as de
V e nd as e C ot as
La nç am e nto
Co nt ábil

diagrama de contexto e lista de eventos ajudam


D ep. E s ta tís t ic a
de V e nda s C ont ab ilida de
V e nd as
Araújo 85 Araújo 86

... Introdução a UML ... ... Introdução a UML ...


LISTA DE EVENTOS DCU
EVENTOS EXTERNOS (sujeito + verbo + objeto)
01. Vendedor registra pedido Registrar Pedido Registrar Pagamento
02. Vendedor cancela pedido
03. Vendedor registra devolução de mercadoria
Sangrar Caixa Caixa
04. Caixa registra pagamento Vendedor Cancelar Pedido
05. Caixa sangra caixa
06. Caixa encerra o caixa
EVENTOS TEMPORAIS (“é hora de” + verbo no infinitivo + objeto) Registrar Devolução de Encerrar Caixa
Mercadoria
07. Aos domingos gerar o Relatório Estatística de Vendas
08. Lançamentos contábeis devem estar prontos dia 01 de cada mês
EVENTOS DE CONTROLE (“se condição” + verbo no infinitivo + objeto)
09. Ao atingir o ponto de ressuprimento,emitir pedido ao fornecedor Gerar Estatítica de Cron Gerar Lançamentos SistContab
Vendas Contábeis
Araújo 87 Araújo 88
... Introdução a UML ... ... Introdução a UML ...
Caso de Uso (processo) Exemplos de Caso de Uso (processo)
• modela um diálogo entre um ator e o sistema Num sistema de recursos humanos:
• representa uma funcionalidade do sistema • admitir funcionário, emitir contracheque,
demitir funcionário, ...
• mostra que recursos o sistema fornece a um ator
Num sistema de controle acadêmico:
• seqüência de transações do sistema que
produzem resultado mensurável para um ator • emitir lista de freqüência, efetuar matrícula,
trancar matrícula, ...
• produz algo de valor para um ator
Num sistema de conta corrente bancária:
• seqüência de ações executadas por um ou mais
• emitir extrato, transferir valor entre contas,
atores e pelo próprio sistema para produzir
efetuar saque, ...
resultado de valor para um ou mais atores
Araújo 89 Araújo 90

... Introdução a UML ... ... Introdução a UML ...


Identificação de casos de uso (processos) Casos de uso
• que faz o sistema em resposta a ação de um ator? • Na fase exploratória do projeto, em tempo de definição
• algum ator armazena, altera, remove, lê dados do sistema? de escopo do sistema, é necessário identificar os casos
de uso e fazer uma descrição sucinta de cada um
• algum ator precisa ser informado de certas ocorrências do
• Na fase exploratória do projeto, caso se deseje usar
sistema? Análise de Pontos de Caso de Uso para estimar o
• que casos de uso suportam e mantêm o sistema? tamanho do software, é necessário identificar os cenários
• que requisitos funcionais podem ser realizados pelo de cada caso de uso
sistema? • Na fase evolutiva, em tempo de análise detalhada, vale
a pena descrever um fluxo de eventos dos casos de uso
lista de eventos ajuda a identificar respostas do sistema
mais complexos

Araújo 91 Araújo 92
... Introdução a UML ... ... Introdução a UML ...
Caso de uso PROCESSAR PEDIDO (descrição sucinta) Casos de uso
• Descrição • Na fase exploratória do projeto, caso se deseje
– Inicia quando um cliente faz um pedido
– Efetua os procedimentos necessários para registro e atendimento usar Análise de Pontos de Caso de Uso para
de um pedido estimar o tamanho do software, é necessário
– Termina quando o vendedor completa o atendimento (a sessão)
do cliente identificar os cenários de cada caso de uso,
• Pré-condição conforme modelo a seguir
– Vendedor se loga ao sistema
Cenários são caminhos (seqüências de ações)
• Pós-condição
– Pedido é gravado no sistema possíveis num caso de uso
– Estoque é atualizado

Araújo 93 Araújo 94

... Introdução a UML ... ... Introdução a UML ...


Caso de uso PROCESSAR PEDIDO... (cenários) ...Caso de uso PROCESSAR PEDIDO (cenários)
• Caminho (cenário) principal • Caminhos de exceção
– Cliente solicita produtos com pagamento no – Cliente solicita produtos com pagamento via cartão e
crediário, sem entrada este está bloqueado
• Caminhos alternativos – Cliente solicita produtos com pagamento no crediário,
– Cliente solicita produtos com pagamento via cartão mas está registrado no SPC
– Cliente solicita produtos com pagamento no crediário – Cliente solicita produtos com pagamento via cheque
com entrada pré e tem registro de cheque devolvido
– Cliente ... com pagamento via cheque pré-datado

Araújo 95 Araújo 96
... Introdução a UML ... ... Introdução a UML ...
• Cliente faz pedido ( Evento da Análise Essencial) • Cliente faz pedido ( Evento da Análise Essencial)

3 2
Cliente Processar Pedido 1
1 4 ... 7
2 3 3e 2e
Cenários
Cenários
1 – Cliente solicita produtos pagando no crediário sem entrada
1 – Cliente solicita produtos pagando no crediário sem entrada
2 – Cliente solicita produtos pagando com cartão de crédito 2 – Cliente solicita produtos pagando com cartão de crédito
3 – Cliente solicita produtos pagando com cheque pré-datado 2e– Cliente solicita produtos pagando com cartão de crédito bloqueado
4 – Cliente solicita produtos pagando ... 3 – Cliente solicita produtos pagando com cheque pré-datado
3e – Cliente solicita produtos pagando com cheque pré-datado, no SERASA ...
Araújo 97 Araújo 98

... Introdução a UML ... ... Introdução a UML ...


Como encontrar fluxos alternativos e de exceção
8 Cenários
• Que variações podem acontecer?
1 B
• Há situações opcionais no caso de uso? 2 B + A1

• O que pode dar errado em cada passo? 3 B + A1 + A2


4 B + A3
• O que pode deixar de acontecer? 5 B + A4
• O que pode interromper o fluxo de eventos? 6 B + A3 + A1
7 B + A3 + A1 + A2
• Que tipo de recurso pode cessar? 8 B + A3 + A4

Rational
Araújo 99 Araújo 100
... Introdução a UML ... ... Introdução a UML ...
• Fluxo de eventos – sucessão de ações que Fluxo de eventos do caminho principal do caso de
uso PROCESSAR PEDIDO ...
ocorrem durante a realização de um caso de
• Pré-condições
uso ou de um cenário
– Vendedor se loga
• Na fase evolutiva, em tempo de análise • Fluxo ...
detalhada, vale a pena descrever fluxo de – Cliente informa seu número de cliente ou CPF ou
eventos para os cenários dos casos de uso, nome e data de nascimento
conforme modelo a seguir. – Sistema identifica o crédito do cliente como OK e o
respectivo valor disponível para compra no crediário

Araújo 101 Araújo 102

... Introdução a UML ... ... Introdução a UML ...


Fluxo de eventos do caminho principal do caso de Fluxo de eventos de mudar cargo de funcionário: ...
uso PROCESSAR PEDIDO ... Atores
• Auxiliar de Pessoal
• ... Fluxo Pré-condições
– Para cada produto solicitado pelo cliente: • Ator acessa o sistema
Fluxo Básico
- obter preço e quantidade em estoque 1. Sistema apresenta tela de Logon (usuário e senha)
- digitar a quantidade solicitada pelo cliente 2. Ator informa código do usuário e senha
- calcular o valor (quantidade X preço unitário) 3. O sistema valida código do usuário e senha [A1]
4. Sistema apresenta tela com opções que ator pode usar
– Calcular o total do pedido 5. Ator seleciona opção Mudar Cargo
– Selecionar o plano de pagamento desejado 6. Sistema apresenta tela Mudança de Cargo
7. Ator seleciona funcionário [A2]
– Confirmar o pedido 8. Ator seleciona novo cargo [A3]
– Atualizar o estoque e emitir o carnet 9. Sistema solicita confirmação
10. Ator digita “S” ou “N” [A4]
11. Se digitou “S” : Trocar Cargo [S1]
12. Se digitou “N” : fim do caso de uso
Araújo 103 Araújo 104
... Introdução a UML ... ... Introdução a UML ...
...Fluxo de eventos mudar o cargo de funcionário: ... ...Fluxo de eventos mudar o cargo de funcionário:
Sub-Fluxo
•[S1] Efetivar troca de cargo, Fluxos Alternativos
Auditar •[A3] Ator seleciona novo cargo
Incrementar qt-promoções do funcionário 1. Sistema exibe mensagem “Cargo não existe”
Fluxos Alternativos
2. Caso de uso encerrado
•[A1] Usuário ou Senha inválida
1. Sistema exibe mensagem “Usuário ou senha invalido” •[A4] Ator digitou algo diferente de S e de N
2. Ator seleciona opção OK 1. Sistema exibe mensagem “Digitar S ou N”
3. Caso de uso retorna ao passo 1 do fluxo básico 2. Caso de uso retorna para o passo 9 do fluxo básico
•[A2] Ator seleciona funcionário
1. Funcionário não existe no cadastro
2. Caso de uso encerrado

Araújo 105 Araújo 106

... Introdução a UML ... ... Introdução a UML ...


Relacionamento Caso de Uso - Ator (Associação) Relacionamento Caso de Uso - Caso de Uso (Inclusão)
• Unidirecional (seta indica onde teve início a comunicação)
• Inclui - indica uma funcionalidade compartilhada por
• Cliente inicia comunicação com caso de uso Atender Pedido
• Atender Pedido inicia comunicação com Sist Contab (apesar vários casos de uso (fatoração de código)
de fluir dado nos dois sentidos, a seta indica que Atender
Pedido iniciou a comunicação com o ator Sist Contab) << inclui >>
Ator primário Estereótipo Ator secundário Digitar Notas
<< inclui >>
<< comunica >> Secretário Checar DV

Cliente Atender Pedido Digitar Pagtos


Sist Contab
Araújo 107 Araújo 108
... Introdução a UML ... ... Introdução a UML ...
Relacionamento Caso de Uso - Caso de Uso (Extensão) Contabilidade Diagrama de Casos de Uso
• Estende - descreve comportamento opcional de um Efetuar Lanc

caso de uso, executado sob certas condições


AuxContab Estornar Lanc

Caso de uso concreto Caso de uso abstrato


Consultar Lanc

<< estende >>


Manter Contas
Atendente Liberar Crédito Pedir Avalista
Contador

Encerrar Exercício
Araújo 109 Araújo 110

... Introdução a UML ... ... Introdução a UML ...


Ator Abstrato – não tem instância (multiplicidade = 0) Fazer uma ligação telefônica Include Use Case...
Caso de Uso Abstrato – é iniciado por outro caso de uso 1. Pessoa tira fone do gancho.
2. Sistema apresenta tom de discagem.
3. Pessoa tecla um dígito .
<<include>> 4. Sistema elimina tom de discagem.
Funcionário Alterar Endereço 5. Pessoa tecla dígitos restantes do número.
6. Sistema analisa os dígitos e determina o endereço da rede
Consultar Cad
do fone discado.
7. Sistema determina se um circuito virtual pode ser
<<extend>> estabelecido entre origem e destino.
Ver Contracheque 8. Sistema aloca os recursos para circuito virtual e estabelece
a conexão.
Horista Mensalista 9. Sistema toca o fone discado.
Araújo 111 Araújo 112
... Introdução a UML ... ... Introdução a UML ...
Inicializar o Sistema ...Include Use Case... ...Include Use Case...
1. Operador ativa o sistema. • Os textos em itálico (azul) são bem similares e
correspondem ao mesmo comportamento nos dois
2. Sistema testa todos os componentes.
casos.
3. Sistema testa conexões com sistemas adjacentes.
• Esta similaridade pode ser transformada em um novo
Para cada sistema adjacente, o Sistema determina se
caso de uso Estabelecer Circuito Virtual.
um circuito virtual pode ser estabelecido entre ele e o
sistema adjacente. O Sistema aloca os recursos para • Substituindo os comportamentos similares nos dois
o circuito virtual e estabelece a conexão. casos de uso por Inclui caso de uso Estabelecer
Circuito Virtual, teremos:
4. Sistema responde que está pronto para operação.

Araújo 113 Araújo 114

... Introdução a UML ... ... Introdução a UML ...


Fazer uma ligação telefônica ...Include Use Case... Inicializar o Sistema ...Include Use Case...
1. Pessoa tira fone do gancho. 1. Operador ativa o sistema.
2. Sistema apresenta tom de discagem. 2. Sistema testa todos os componentes.
3. Pessoa tecla um dígito .
4. Sistema elimina tom de discagem. 3. Sistema testa conexões com sistemas adjacentes.
5. Pessoa tecla dígitos restantes do número. Para cada sistema adjacente, Inclui o caso de
6. Sistema analisa os dígitos e determina o endereço da rede uso Estabelecer Circuito Virtual para
do fone discado.
7. Inclui o caso de uso Estabelecer Circuito Virtual para fazer fazer a conexão na rede, entre origem e
a conexão na rede, entre origem e destino.
8. Sistema toca o fone discado. destino.
4. Sistema responde que está pronto para operação.
Araújo 115 Araújo 116
... Introdução a UML ... ... Introdução a UML ...
...Include Use Case Extend Use Case

Estabelecer Circuito Virtual


Origem Fazer Ligação Telefônica Destino
<<include>> <<include>>
<<extend>>
<<extend>>

Exibir Call Id
Inicializar o Sistema Fazer Ligação Telefônica Destino1 Fazer Conferência

Araújo 117 Araújo 118

... Introdução a UML ... ... Introdução a UML ...


Relacionamento entre Casos de Uso Relacionamento entre Casos de Uso
• Qual o relacionamento entre os casos de uso? • Qual o relacionamento entre os casos de uso?

Caso de uso concreto Caso de uso abstrato Caso de uso concreto Caso de uso abstrato

<< inclui >>


Vendedor Efetuar Venda Emitir Nota Fiscal Vendedor Efetuar Venda Emitir Nota Fiscal

Araújo 119 Araújo 120


... Introdução a UML ... ... Introdução a UML ...
Casos de Uso Base – B1 e B2 Fatorar código quando houver:
Casos de Uso Abstratos – A e C (existem só para outros casos de uso)
• Comportamento comum Æ Include
• Comportamento opcional Æ Extend
<<include>> A C
• Comportamento excepcional Æ Extend
<<extend>>
• Comportamento que deve ser desenvolvido em
B1 B2
iteração posterior
A1
A2
Se Base sabe qdo/onde/pq outro UC deve ser executado Æ Include
Se outro UC sabe qdo/onde/pq deve ser executado Æ Extend
Araújo 121 Araújo 122

... Introdução a UML ... ... Introdução a UML ...


Realização de Caso de Uso Caixa Eletrônico uc Use Case Model

<<Realiza>>
Colaboração EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
representa os Efetuar pagamento

Transferir Dinheiro Colaboração Transferir Diagramas de Emitir Extrato EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
Sacar dinheiro

Dinheiro Classe e de executado 300 EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
Sequência vezes por dia
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
<<entity>>
Cliente
C liente +por dia Efetuar transferencia
<<control>>
CtlTrf
(from Logical View) Cliente Emite EA 6.5300
Unregistered Trial Version EA 6.5 Unregistered
nrCli
<<boundary>>
iniciarTrf()
nmCli
dsU serID
2 Extratos por EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
FrmTrf
habilitarC tas()
transferir()
password
ctasC li
mês
verifD isponib() EA 6.5 Unregistered 2Trial Version Consultar
EA 6.5saldo
Unregistered
confirmarTrf() obte rCta sCli() +por mês

<<entity>> EA 6.5 Unregistered Trial Version EA 6.5 Unregistered


C onta Emitir extrato

<< entity>>
sldCta Fronteira EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
LogTrf
obterSld()
debitarTrf ()
gravarLo g()
Araújo creditarTrf () 123 Araújo EA 6.5 Unregistered Trial Version EA 6.5 Unregistered 124
... Introdução a UML ... ... Introdução a UML ...
Granularidade dos Casos de Uso Hotel
Cadastrar Hóspede
• Casos de uso não devem ser muito pequenos Registrar Despesa
Estornar Despesa
nem muito grandes, devem ter o tamanho
suficiente para produzir um resultado de valor Fazer Reserva

observável para um ou mais atores.


Abrir Conta Atendente Cancelar Reserva Hóspede
• Um caso de uso é uma seqüência de transações
<<extend>>
que o sistema realiza para produzir um resultado
de valor observável para um ou mais atores.
Fechar Conta

Listar Despesas Consultar Reserva

Araújo 125 Araújo 126

... Introdução a UML ... ... Introdução a UML ...


Cliente <<extend>> <<extend>> Casos de Uso
de e-mail • Funções que o sistema deve executar em atendimento
Criptografar Msg Compor Mensagem Verificar Ortografia
às necessidades do cliente
<<extend>>
• Funcionam como um contrato entre cliente e
Manter Contatos <<extend>> <<include>>
Anexar arquivo
desenvolvedor
<<extend>> • Capturam e modelam os requisitos funcionais
• Descrição textual simples focada no negócio, no
Enviar Mensagem
Escolher Destintário problema e não na solução informatizada
Responder Mensagem

<<extend>>
<<extend>> • Registram o que o sistema deve fazer
Usuário <<include>>
• São úteis durante todo o ciclo de desenvolvimento
<<extend>> do sistema: análise, projeto, implementação, teste
Encaminhar mensagem documentação
<<extend>>
Ler Mensagem
Araújo Desencriptar Mensagem 127 Araújo 128
... Introdução a UML ... ... Introdução a UML ...
Objeto
Desenvolvimento Dirigido por Caso de Uso
• é a representação de uma entidade
• pode representar algo concreto (veículo, cliente, produto) ou um
conceito (pedido, transação bancária, histórico escolar)
Casos Classes de Classes de Código Executáveis
De Uso Análise Projeto Fonte
• possui as características: atributos (dados), comportamento
(operações), estado e identidade
• encapsula dados e comportamento
Exemplos de objetos
Num sistema de recursos humanos:
• funcionário, departamento, dependente, projeto, cargo, ...
Num sistema de controle acadêmico:
• aluno, histórico escolar, professor, turma, disciplina
ofertada, ...
Componentes
Araújo 129 Araújo 130

... Introdução a UML ... ... Introdução a UML ...


Estado de um objeto Comportamento de um objeto
• definido por um conjunto de propriedades (atributos) com seus • define como o objeto responde às solicitações
respectivos valores e mais os relacionamentos com outros de outros objetos
objetos
• pode mudar ao longo do tempo • descreve tudo que o objeto pode fazer
• uma das possíveis condições em que ele pode existir • descreve a funcionalidade do objeto
Exemplos de estado de objeto • é implementado pelo conjunto de operações
• Um objeto disciplina ofertada pode estar aberto (ainda há (métodos) do objeto
vagas) ou fechado (não há mais vagas) • disponibiliza as operações que manipulam seus
• Um objeto funcionário pode ter vários estados: normal, de dados
férias, afastado por doença, demitido, ...
Araújo 131 Araújo 132
... Introdução a UML ... ... Introdução a UML ...
Exemplos de comportamento de objetos Identidade de um objeto
Num sistema de recursos humanos:
• funcionário: aumentar salário, alterar nome, alterar estado • cada objeto é único, mesmo que tenha estado
civil,... idêntico ao de outro objeto
• dependente: incluir, excluir, alterar tipo de dependência, ...
• projeto: fixar orçamento, acompanhar orçamento, iniciar, • na UML, um dado objeto é representado por um
cancelar,... retângulo com o nome do objeto sublinhado
• cargo: incluir, estabelecer número de vagas, definir pré-
requisitos, ...
Num sistema de controle acadêmico:
francisco1230 bancoDeDados
• aluno: incluir, jubilar, alterar nome, excluir,...
• disciplina: incluir, definir pré-requisitos, excluir,...
• professor: incluir, excluir, alterar nome,...
Araújo 133 Araújo 134

... Introdução a UML ... ... Introdução a UML ...


Uma classe deve capturar uma só abstração
Classe - grupo de objetos com iguais: • Uma classe com informações do funcionário e informações
• propriedades (atributos) Aluno sobre os cargos por ele ocupados, captura mais de uma
abstração, logo, é melhor definir duas classes ao invés de
• comportamentos (operações) nome
uma: funcionário e cargo do funcionário
• relacionamentos • Uma classe com mais de 15 atributos merece ser
incluir ( ) examinada para ver se não pode ser dividida em duas
• semânticas Classes num sistema de recursos humanos:
Cada objeto é uma instância de uma classe • Funcionário, Departamento, Dependente, Projeto, Histórico
de cargos, ...
UML: Nome da classe | Atributos | Operações Classes num sistema de controle acadêmico:
• Aluno, Disciplina, HistóricoEscolar, Professor, Turma,...

Araújo 135 Araújo 136


... Introdução a UML ... ... Introdução a UML ...
Departamento ...Exemplo de classe Turma
Exemplo de classe...
No Controle Acadêmico, a
A classe departamento no RH, tem: descrição local
• atributos: código, descrição, classe turma tem:
cadastrar ( ) obter sala( )
orçamento • atributos: código, local, horário
• operações: cadastrar departamento, mudar o • operações: obter sala, definir horário
chefe do departamento, fixar orçamento, ... • objetos da classe turma: turma1M , turma1N ,
• objetos da classe departamento: computação, turma2M .
estatística, história, geografia, matemática, ...

Araújo 137 Araújo 138

... Introdução a UML ... ... Introdução a UML ...


• Classes, em tempo de análise, podem ser do tipo <<Classes de Fronteira>>
• Manipulam entrada e saída de dados
(estereótipo): Entidade, Fronteira, Controle • Cada form é um objeto criado por classe de fronteira
• Estereótipo é um conceito da UML que permite • Interface entre um ator e o sistema
• Uma para cada form, relatório, interface com outro sistema
estender os elementos básicos de modelagem para <<Classes de Controle>>
criação de novos elementos • Não gerenciam dados nem têm saída visível
• Controlam o fluxo operacional de caso de uso
• Estereótipos usados em diagramas de caso de uso: • Atuam entre as classes de fronteira e as de negócio
<<comunica>>, <<inclui>>, <<estende>> • Uma para cada caso de uso
<<Classes de Entidade>>
• Criam objetos que gerenciam dados
• Núcleo do domínio da aplicação
• Uma para cada entidade participante do sistema
Araújo 139 Araújo 140
... Introdução a UML ... ... Introdução a UML ...
• Estereótipos pré-definidos para classes, em Classes do tipo entidade
tempo de análise, são: <<entidade>>, • modelam entidades do mundo real, geralmente
<<fronteira>> e <<controle>> independentes do ambiente externo e, às vezes,
utilizadas em mais de uma aplicação
<< entidade>> <<fronteira>> <<controle>>
• são classes do domínio do problema
Funcionario FrmMudaCargo CtrMudaCargo
• identificadas via exame de fluxos de eventos de
nome caso de uso, onde cumprem responsabilidade;
incluir ( )
Ex.: auxiliar de pessoal seleciona funcionário
para mudança de cargo

Araújo 141 Araújo 142

... Introdução a UML ... ... Introdução a UML ...


Classes de fronteira (boundary) Classes de controle...
• coordenam os eventos necessários para execução das
• modelam as interfaces entre sistema e atores operações específicas no caso de uso
• identificadas via exame em pares ator / caso de uso; • é como se executassem (rodassem) o caso de uso
Ex.: tela (form) para mudar cargo do funcionário • não devem fazer mais que controlar o fluxo de eventos no
caso de uso
• em tempo de análise, não é necessário identificar • opcionais, mas se usadas, uma por caso de uso
todos os componentes do form (combo, controle de • conhecem e executam as regras de negócio
dados, ... ); esta tarefa deve ser feita em tempo de • coordenam os esforços de outras classes
projeto • enviam muitas mensagens para outras classes
• não recebem muitas mensagens de outras classes

Araújo 143 Araújo 144


... Introdução a UML ... ... Introdução a UML ...
...Classes de controle MVC – Model View Controller
<<entidade>>
Num Controle Acadêmico, a classe de controle para
matricular aluno tem atividades como:
• Buscar na classe Disciplina seus pré-requisitos <<fronteira>> <<controle>> <<entidade>>
• Verificar em Histórico se os pré-requisitos foram A tor

satisfeitos
• Informar se faltar algum pré-requisito <<entidade>>

• Verificar se há vaga na DisciplinaOfertada


VIEW CONTROLLER MODEL
• Se houver vaga, solicitar a inclusão do aluno
(MVC – é um exemplo de padrão de arquitetura)
Araújo 145 Araújo 146

... Introdução a UML ... ... Introdução a UML ...


Relacionamentos
Relacionamento tipo associação...
• os sistemas OO possuem classes e objetos
• significa que há uma ligação entre os objetos das
• a colaboração entre os objetos determina o classes associadas, logo pode haver envio de
comportamento do sistema mensagem entre eles
• os objetos interagem via troca de mensagens • uma associação entre Funcionário e Projeto
• os relacionamentos fornecem o meio (duto) para a significa que os objetos da classe Funcionário
interação entre os objetos estão conectados aos objetos da classe Projeto
• tipos de relacionamento UML: associação, • é representado por uma linha cheia ligando as
generalização, dependência, realização classes
Araújo 147 Araújo 148
... Introdução a UML ... ... Introdução a UML ...
...Relacionamento tipo Associação Relacionamento tipo agregação...
• é um relacionamento entre o todo e suas partes
NF
Cli
nrNF : Integer
• um pequeno losango é desenhado ao lado da classe que
nrCli : Integer +comprador +notaFis dtNF : java.util.Date representa o todo
nmCli : String
1 0..* • cabe o uso das expressões “é-parte-de”, “todo-parte”
total() • há uma certa subordinação entre as classes
Cli()
NF()
• Ex.:uma disciplina pode ser ofertada em mais de um
Um cliente tem, de 0 a n notas fiscais horário no semestre, um pedido tem vários itens, um time
Uma nota fiscal é de 1 cliente tem onze atletas,...
comprador é o papel de Cli na associação • algumas operações do todo são automaticamente
aplicadas às partes: excluir uma disciplina implica
notaFis é o papel desempenhado por NF na associação excluir as ofertas dessa disciplina, excluir uma nota
fiscal implica excluir os itens da nota
Araújo 149 Araújo 150

... Introdução a UML ... ... Introdução a UML ...


...Relacionamento tipo Agregação Associação ou Agregação?
Pnf
• Se as duas classes interagem na forma “todo-
NF parte”, temos uma agregação
cdPro : Integer
nrNF : Integer 1..*
dtNF : java.util.Date
qtd : Integer • a escolha entre agregação ou associação não
val : Integer
+theNF +itNota causa maiores problemas na prática
total()
NF()
totalProd() • ser uma associação ou uma agregação depende
Pnf()
do domínio do problema:
Uma nota fiscal tem 1 ou mais produtos (linhas da nota) Que tipo de relacionamento modela um carro e
seus pneus?
Um produto da nota fiscal (linha da nota) é parte da nota
Araújo 151 Araújo 152
... Introdução a UML ... ... Introdução a UML ...
AGREGAÇÃO COMPOSIÇÃO
Que tipo de relacionamento modela um carro
e seus pneus? ... • A multiplicidade do lado “todo” • A multiplicidade do lado “todo”
pode ser maior que 1 é sempre 1
• na aplicação de uma oficina, onde os serviços • As partes não morrem • As partes vivem e morrem
podem se estender aos pneus, como obrigatoriamente com o todo obrigatoriamente com o todo
componentes do carro agregação • Uma mesma parte pode estar • Uma mesma parte não pode
estar em mais de um “todo”
• na loja de venda de pneus, onde o importante é em mais de um “todo”
saber que carro usa qual pneu, deve ser • As partes são semelhantes • Em geral, as partes não são
modelado como associação semelhantes
Válvula
Equipe Pessoa Veículo
n Vela
1
Araújo 153 Araújo 154

... Introdução a UML ... ... Introdução a UML ...

Nomes dos Relacionamentos... Rolenames...


• a extremidade de uma associação, na conexão
• associações - usa-se um verbo que permita formar com a classe, é denominada “o papel que o
frase da forma “classe1 + verbo + classe2” objeto desempenha na associação”
Ex.: professor chefia departamento • pode-se usar rolename (papel) nas
extremidades, ao invés do verbo
Professor 1 chefia 1
Departamento • o rolename é colocado na associação, perto da
classe a que se refere

Araújo 155 Araújo 156


... Introdução a UML ... ... Introdução a UML ...
...Rolenames Rolename - Indica a função desempenhada por
um objeto em relação ao outro numa associação
Pessoa emprega Empresa
dirige +veículo Automovel
0 ..* 1

+motorista
Pessoa Empresa
funcionário empregador
Pessoa +empregado +empregador Empresa
0 ..* 1
emprega

Há uma tendência de se usar rolenames ao invés +proprietario


de verbo para descrever a associação +propriedade Imovel
possui
Araújo 157 Araújo 158

... Introdução a UML ... ... Introdução a UML ...


Multiplicidade
indica o número de objetos com que cada classe Exemplos de Multiplicidade
participa do relacionamento Empresa
1 Exatamente um Fiscal 2 0 .. *
* Zero ou mais
0 .. * Zero ou mais
1 .. * Um ou mais OfertaDisc 0 .. 4 1
Professor
0 .. 1 Zero ou um
5 .. 9 De 5 a 9 (5, 6, 7, 8 ou, 9)
4 .. 7, 9 De 4 a 7 ou 9 (4, 5, 6, 7, ou 9) Aluno 0 .. 30 Turma
0 .. 6

Araújo 159 Araújo 160


... Introdução a UML ... ... Introdução a UML ...
Relacionamento Reflexivo... ...Relacionamento Reflexivo
• envolve objetos de uma mesma classe Uma agregação reflexiva indica
• pode ser agregação ou associação que uma instância de uma classe Produto
• rolenames facilitam entendimento do modelo é composta por uma ou mais
instâncias da mesma classe.
0 ..* 0..1
é-prereq Disciplina chefe Funcionário Um produto pode ser composto por
outros produtos
tem-como-prereq 0 ..* subordinado 0 .. *

Araújo 161 Araújo 162

... Introdução a UML ... ... Introdução a UML ...


Classe Associativa
Relacionamento ternário
Um relacionamento pode também ter estrutura e
comportamento; ocorre quando a informação tem
a ver com os dois objetos; Ex.: nota e período têm a Poema
ver com as duas classes
Aluno 5 .. 15 0 .. 4 OfertaDisciplina Leitor Biblioteca

Historico Leitura
Classe
nota, período Associativa Classe associativa
Araújo 163 Araújo 164
... Introdução a UML ... ... Introdução a UML ...
Relacionamento quaternário Classe e Interface (operações abstratas) em UML
<<estereótipo>> << classe>> << interface>>
Cliente Funcionario NomeDaClasse Pessoa IPessoa
Atributo de Classe qtPessoas
+ Atrib Publico + cdPessoa
- Atrib Privado - nmPessoa
Aplicacao Tarefa # Atrib Protegido # dtNascPessoa
Operação de Classe obterQtPessoas obterQtPessoas
+ Oper Publica + getnmPessoa() + getnmPessoa()
OrdemServ - Oper Privada - getcdPessoa() + getcdPessoa()
Classe associativa # Oper Protegida # setnmPessoa() + setnmPessoa()
Araújo 165 Araújo 166

... Introdução a UML ... ... Introdução a UML ...


ASSOCIAÇÃO... (entre classes independentes) ... ASSOCIAÇÃO ...
• Há vínculo entre objetos e associação entre classes C liente
D uplicata
(vínculo é uma instância de uma associação) cdC li : int
nrD up : int
• Associação representa responsabilidade do ponto de vista nmC li : String
dtVen : date
limC re : int +devedor +titulo vlD up : double
de implementação; assim, a associação entre Cliente e
Duplicata significa que: 1 0..* stD up : boolean
incD up()
a) há método na classe Cliente que obterá as duplicatas de excD up()
bxD up()
um cliente altLimC re()
D uplicata()
C liente()
b) há método na classe Duplicata que permite saber a que
cliente pertence uma dada duplicata
public Duplicata titulo[ ]; public Cliente devedor;

Araújo 167 Araújo 168


... Introdução a UML ... ... Introdução a UML ...
... ASSOCIAÇÃO ... public class Cliente { ... ASSOCIAÇÃO public class Duplicata {

C liente private int cdCli; private int nrDup;


private String nmCli; D uplicata
cdC li : int private date dtVen;
nmCli : String private int limCre; nrD up : int
dtV en : date private double vlDup;
limC re : int +d eved or public Duplicata titulo[ ]; +titulo vlDup : double
private boolean stDup;
public Cliente() {…}
incD up() 1 0..* stD up : boolea n
public void incDup() {…}
public Cliente devedor;
excD up()
altLimC re() public void excDup() { … } bxD up() public Duplicata() { … }
Cliente () public void altLimCre() { … } }
D uplicata () public void bxDup() { … } }
Araújo 169 Araújo 170

... Introdução a UML ... ... Introdução a UML ...


Navegabilidade nas associações... ...Navegabilidade nas associações...

Cliente cli Pedido Cliente Pedido


unidirecional cli : Cliente bidirecional
Cliente não tem Pedido tem a
obterPedidos ( ) obterCli ( )
responsabilidade responsabilidade
de identificar seus de identificar seu /* em JAVA -----------------
/* em JAVA ---------------------
pedidos cliente class Pedido {
class Cliente {
private set peds = new Set( ); private Cliente cli;
Cliente não tem Pedido tem referência public Cliente ObterCli ( )}
public set obterPedidos( )}
referência para Pedido para cliente
Araújo 171 Araújo 172
... Introdução a UML ... ... Introdução a UML ...
Atributos de Conexão +marido
...Navegabilidade nas associações Pedido
0.. 1
Cliente +esposa
0..1
nrPed +ped +cli cdC
Cliente Pedido dtPed 0..* 1 nmC 1 +pai

peds : set of Pedido 0..*


+filho
+itemPed 1..*

ProPed Produto
Cliente Pedido qtd cdP
cli : Cliente val dsP

Cliente Pedido Atrib conexão em Pedido Atrib conexão em Cliente


--------------------------------- ---------------------------------
peds : set of Pedido cli : Cliente public Cliente cli; public Pedido ped [ ];
public ProPed itemPed [ ]; public Cliente marido;
public Cliente esposa;
public Cliente filho [ ];
Araújo 173 Araújo 174

... Introdução a UML ... ... Introdução a UML ...


Dependência – uma classe usa a outra, depende da outra Atributos de Conexão
Voo • Associação unidirecional – atributo de conexão
nrVoo
dtVoo
Passageiro apenas na classe cliente (aponta p/ servidora)
<<usa>> nmPass
cancVoo()
enPass • Em Java, não há diferença no código gerado
foPass
altHorario() para agregação forte (composição) ou fraca
incPass(p : Passageiro) : Boolean
excPass(p : Passageiro) : Boolean • Em VB há diferença: agregação – por referência,
composição – por valor
Dependência não gera atributo de conexão
• Dependência e Generalização – não geram
A classe Voo usa a classe Passageiro via argumento de
operação do tipo Passageiro atributos de conexão
Araújo 175 Araújo 176
... Introdução a UML ... ... Introdução a UML ...
Classe Associativa Código gerado pelo Rose
public class Leitor { public class Livro {
Emprestimo private int cdLe; private int cdLiv;
+theEmpr nrEmp +theEmpr
dtEmp private int nmLe; private int nmLiv;
0..* 0..*
dtDev public Emprestimo theEmpr[ ]; public Emprestimo theEmpr[ ];
+leitor 1 1 +livro
Emprestimo() public Livro theLivro[ ]; public Leitor theLeitor[ ];
Leitor Livro
cdLe +theLeitor +theLivro cdLiv
nmLe nmLiv public class Emprestimo { public class Reserva {
0..* 0..* private int nrEmp; private int dtRes;
Leitor() Livro()
Reserva private int dtEmp; private int hrRes;
dtRes private int dtDev;
hrRes
public Leitor leitor;
Reserva() public Livro livro;
Araújo 177 Araújo 178

... Introdução a UML ... ... Introdução a UML ...


Generalização ... ...Generalização ...
• é uma hierarquia onde se pode dizer “é-subconjunto-de” • as subclasses são criadas com base em um atributo discriminador
(tipo de cliente, tipo de salário, sexo,...)
ou “é-do-tipo” ou “é-um” • o discriminador tem normalmente um conjunto finito de valores e
• as subclasses herdam atributos, operações e os pode ser criada uma subclasse para cada valor
relacionamentos das superclasses • uma árvore de herança compreende as classes referentes a um
dado discriminador
• subclasses são adicionadas para especializar o • na herança simples uma classe tem uma cadeia de superclasses,
comportamento de uma classe existente um conjunto de ascendentes
• uma superclasse abstrata não gera objetos • na herança múltipla, uma classe tem mais de uma cadeia de
superclasses
• uma operação abstrata não gera um método • herança múltipla:
• uma subclasse pode oferecer sua própria implementação – não é suportada por algumas linguagens
de uma operação - polimorfismo – leva a código de mais difícil manutenção
Araújo 179 Araújo 180
... Introdução a UML ... ... Introdução a UML ...
...Generalização Reuso via generalização
• Subclasse herda comportamento de superclasse
Veículo
• Pode envolver classe abstrata
• Fere um pouco o encapsulamento, uma vez que as
subclasses acessam detalhes das superclasses
• Reuso é especificado estaticamente (+ performance)
Motorizado Terrestre Aquatico • Não é recomendável usar herança quando um objeto
de uma subclasse puder transformar-se em objeto de
uma subclasse irmã (metamorfose). Ex.: funcionário
pode tornar-se cliente
VeicAnfíbio Herança múltipla

Araújo 181 Araújo 182

... Introdução a UML ... ... Introdução a UML ...


Reuso via delegação Em caso de metamorfose (classificação dinâmica – um
• Quando um objeto não pode realizar uma operação, ele objeto de uma subclasse pode transformar-se em objeto de
pode delegar para outro(s) objeto(s); funciona como se outra subclasse), é melhor usar reuso via delegação
o objeto reusasse as operações do objeto que recebeu a Pessoa
Pessoa
delegação; não há reuso de atributos
• É mais genérico pois um objeto pode reusar o casar()
Pessoa()
comportamento de outro sem que o primeiro precise ser +pesFun +pesCli
de uma subclasse da superclasse do segundo
Funcionario CL ien te
• Reuso utilizado em tempo de execução Func Clie n FunCli

• Menor performance que reuso por generalização casar() casar()


Funcionario() CLiente()
• Não pode envolver classes abstratas
Reuso por Generalização Reuso por Delegação
Araújo 183 Araújo (Pior) (Melhor) 184
... Introdução a UML ... ... Introdução a UML ...
Reuso via Delegação class Pessoa { // --- Delegação class Pessoa { // --- Herança
// Retorna qtd de casamentos // Retorna qtd de casamentos
Funciona rio Pe ssoa public int casar() { public int casar() {
+pes System.out.println("Pes. vai casar."); System.out.println("Pes. vai
casar.");
casar() casar() return 1; } }
return 1; } }
Funciona rio () Pessoa() class Funcionario { class Funcionario extends Pessoa {
private Pessoa pes = new Pessoa(); }
public int casar() {return pes.casar();}} class TesteHeranca {
casa r class TesteDelegacao { public static void main(String[] args){
casar
{System.out.println public static void main(String[] args) { Funcionario f = new Funcionario();
{return pes.casar()} int num = f.casar(); } }
("Pessoa vai casar.")} Funcionario f = new Funcionario();
int num = f.casar(); } }
Araújo 185 Araújo 186

... Introdução a UML ... ... Introdução a UML ...


Reuso via generalização X via delegação Diagrama de classe
• Generalização e delegação são mecanismos para Pessoa
reutilizar funcionalidade
• A generalização (herança) estende atributos e
métodos de uma classe Professor Aluno
• A delegação “estende” (amplia) uma classe
0..* 0..30 AlunDisc
delegando o trabalho para objeto de outra classe
• Herança (generalização) era a ferramenta básica 0..6
de extensão e reuso de funcionalidade DiscOfert
0..4 0..*
• Reuso por delegação é muito superior (flexível)
Disciplina Pre-req
ao reuso por generalização, na maioria dos casos
0..*
Araújo 187 Araújo 188
... Introdução a UML ... ... Introdução a UML ...
Relacionamento entre pacotes
Pacotes • linha pontilhada do cliente para o fornecedor
• coleção de pacotes, classes ou casos de uso • relacionamento de dependência
relacionados • se pacote A depende de B, uma ou mais classes
• em sistemas complexos, pacotes são criados em A iniciam a comunicação com classes de B
para facilitar comunicação Version EA 7.1 Unregistered Trial Version
class Class Mo...

• sistemas simples estão num único pacote: o PackageA PackageB


próprio sistema Version EA 7.1 Unregistered Trial Version
• pacotes no controle acadêmico: interfaces,
Version EA 7.1 Unregistered Trial Version
pessoas (professores, alunos,...)
Araújo 189 Araújo 190

... Introdução a UML ... ... Introdução a UML ...


Cenários
• descrevem como funciona o caso de uso
• são instâncias de um caso de uso
• são caminhos através do fluxo de eventos de um caso de uso
• ajudam a identificar objetos, classes e interação entre
objetos que desenvolvem a funcionalidade de casos de uso
• são documentados via diagramas de interação(seqüência e
comunicação)
• documentam como as responsabilidades especificadas no
caso de uso são distribuídas entre os objetos e classes do
sistema
Araújo 191 Araújo 192
... Introdução a UML ... ... Introdução a UML ...
Diagramas de Interação Diagrama de seqüência do cenário Criar novo curso
• Documentam os aspectos dinâmicos do software
oCurso :
• Descrevem a seqüência de mensagens trocadas pelos frmCurso ctlCurso
Curso
objetos que participam de um cenário : Secret

• Diagrama de Seqüência – ressalta a ordem Linha da vida


1 : inf. curso
cronológica das mensagens trocadas entre os objetos
• Diagrama de Comunicação – ressalta o relacionamento 2 : processar
3 : inc. curso
entre os objetos facilitando visualizar todas as
4 : novo curso
mensagens trocadas entre dois objetos
Exibição Aplicação Dados
Araújo 193 Araújo Camadas 194

... Introdução a UML ... ... Introdução a UML ...


Diagrama de seqüência Diagrama de seqüência...
• mostra a interação entre objetos tendo em vista
a seqüência das mensagens no tempo Produção Nome de um dado Objeto
• mostra no cenário
– objetos e classes envolvidos Produção : Departamento Nome de um Objeto de Classe
– a seqüência de mensagens trocadas pelos
objetos, necessárias para desenvolver a
funcionalidade do cenário : Departamento Instância de Classe

Os dois primeiros são objetos NOMEADOS e o último é


um objeto ANÔNIMO
Araújo 195 Araújo 196
... Introdução a UML ... ... Introdução a UML ...
frmEmprest : c tlEmprest : Leitor : Livro : Emprest
:
...Diagrama de seqüência Bibliotec ario
1: Abrir

Nomeado – recebe um nome e necessita Ari : Cliente Cenário: 2: Em prestar


3: CarregarLeitor
ser referenciado posteriormente Emprestar Livro 4: CarregarLivro

5: Selec ionaLeitor

6: SelLeitor
Anônimo – não recebe um nome específico : Cliente 7: ValidarLeitor

8: SelLivro

Às vezes, uma mensagem é enviada para 9: SelLivro

uma classe. 10: ValidarLivro

Neste caso, a operação a ser executada é 11: Confirmar

uma operação de classe. 12: Emprestar

13: AltStLeitor

14: AltStLivro

Araújo 197 Araújo 1 5: Grava r Emp resti mo 198

... Introdução a UML ... ... Introdução a UML ...


Diagrama de seqüência : C li

opcao Trf
: FrmTrf : C tlTrf : C liente : C onta : LogTrf

• A linha vertical pontilhada é chamada linha da vida DSE iniciarTrf( )


ob terC tasC li( )

• Um retângulo na linha da vida (controle de foco) habilitarC tas( )

representa a duração da ação realizada pelo objeto dadosTrf


solicitarTrf

transferir( )
obterS ld( )
• O topo do retângulo indica o início da execução da verifD isponib( )

operação solicitada pela mensagem recebida e a


base inferior do retângulo marca o fim da execução confirmar
so licitC o nfirm Trf

da operação confirmarTrf( )
debitarTrf( )

• O diagrama de seqüência exibe uma visão creditarTrf( )

dinâmica do sistema gravarLog( )


exibirNrTrf

Araújo 199 Araújo 200


... Introdução a UML ... ... Introdução a UML ...
Mensagem num diagrama de seqüência... • É possível usar scripts para tornar mais claro o
alsdVersion EA 7.1 Unregistered Tria
Use Case Mo...
Assíncrona – objeto remetente continua Diagrama de Seqüência
al Version EA 7.1 Unregistered Tria processamento sem esperar término da
:B :C
execução da operação solicitada • O script pode explicar melhor um if
al Version assincrona()
EA 7.1 Unregistered Tria Síncrona – objeto remetente só continua
• Evitar por muito if em um diagrama: melhor fazer
:D processamento após o término da
new()
al Version EA 7.1 Unregistered Tria execução da operação solicitada
sincrona()
um diagrama para a lógica referente ao if, e
reply()
al Version EA 7.1 Unregistered Tria Reply – mensagem de retorno
outro diagrama para a parte da lógica
delete() correspondente ao else
al Version EA 7.1 Unregistered Tria New – criação de um objeto

al Version EA 7.1 Unregistered Tria Delete – exclusão de objeto

l VAraújo
i EA 7 1 U i t dT i 201 Araújo 202

... Introdução a UML ... ... Introdução a UML ...


DSE com Script

: ProcCredit
Script : Cli : frmCred : SistCartCred : fr mConfir m fr mNe ga cao

entrDadosCred( )
verCred( )
ve rifCr ed ( )
se cred O K
marcarAssento( )

exibirLocalizador( )

confirma( )

se cred n O K negarCredit( )

Araújo 203 Araújo 204


... Introdução a UML ... ... Introdução a UML ...
EA 6.5 Unregistered Trial Vers
sd instancias

EA 6.5:Aluno
Unregistereda:Aluno
Trial Vers

EA 6.5 Unregistered Trial Vers

EA 6.5 Unregistered Trial Vers

EA 6.5 Unregistered
Instância não Trial Vers
Instância da
identificada da classe Aluno com
classe Aluno o nome a
EA 6.5 Unregistered Trial Vers
Araújo 205 Araújo 206
EA 6 5 Unregistered Trial Vers

... Introdução a UML ... ... Introdução a UML ...


Version
sd instancias EA 6.5 Unregistered Tria

alunos:ArrayList<Aluno> alunos[i]:Aluno
Version EA 6.5 Unregistered Tria

Version EA 6.5 Unregistered Tria

Version EA 6.5 Unregistered Tria


Instância da
Instância da
classe ArrayList
Version EA 6.5 Unregistered
classe Aluno
parametrizada Tria
selecionada da
para conter
coleção
objetos do tipo
Version EA 6.5 Unregistered Tria
Aluno
ArayList<Aluno>

Araújo 207 Araújo 208


Version EA 6 5 Unregistered Tria
... Introdução a UML ... ... Introdução a UML ...
registered
sd Loop Trial Version EA 6.5 Unregistered T
:M :N :P
registered Trial Version EA 6.5 Unregistered T

registered
opM1 Trial Version
opN1 EA 6.5 Unregistered T
loop
registered Trial Version EA 6.5 Unregistered T
[x < 20] opP1

registered Trial Version EA 6.5 opP2


Unregistered T

registered Trial Version EA 6.5 Unregistered T

registered Trial Version EA 6 5 Unregistered T


Araújo 209 Araújo 210

... Introdução a UML ... ... Introdução a UML ...


Diagrama de comunicação
Controle
Descentralizado • outra forma de representar cenários
• mostra interações entre os objetos
• é formado por:
– objetos (retângulos)
– interações entre objetos (linhas ligando
Controle objetos)
Centralizado
– mensagens (texto e setas do cliente para o
fornecedor)
Araújo 211 Araújo 212
... Introdução a UML ... ... Introdução a UML ...
Diagrama de comunicação para Criar novo curso Ao enviar uma mensagem,
um objeto está:
: ctlAcesso : Usuario . Pedindo colaboração
1 : inf. Curso
2 : processar frmCurso validarUsu(usu : char, senha : char)
. Sabendo que o objeto
destinatário possui esta
: Secret operação
. Definindo uma operação
3 : inc. curso na classe do objeto receptor

<<entity>>
4 : novo curso Mensagem de:
Usuario
oCurso : :ctlCurso . Ator para um form não define
usu : char
Curso senha : char uma operação no form
. Form para objeto de controle
validarUsu(usu : char, senha : char) : boolean
define operação neste
Araújo 213 Araújo 214

... Introdução a UML ... ... Introdução a UML ...


Por que os dois diagramas ? Transição de Estados... DTE de OfertaDisciplina
Diagrama de Seqüência Diagrama de Comunicação
• muito útil no início da • mais útil em tempo de Iniciada Ação Condição de Guarda
análise projeto
Inclusão Aluno/Count=1
• exibe o cenário dando • fornece uma visão geral Inc Aluno[Count=10]
ênfase à ordem do cenário Inc Aluno[Count<10]
Exc Aluno[Count>0]
cronológica em que as • ajuda a identificar todas Aberta Fechada
mensagens ocorrem entre as interações entre os Exc Aluno
os objetos objetos
Evento Cancelamento Cancelamento
• pode ter controle de foco • não tem controle de foco
• numeração opcional de • numeração obrigatória Cancelada
mensagens de mensagens
Araújo 215 Araújo 216
... Introdução a UML ... ... Introdução a UML ...
...Transição de Estados...
...Transição de Estados... • um objeto pode estar em um dos seus diversos possíveis
• cenários e casos de uso descrevem o comportamento estados
do sistema, ou seja, a interação entre os objetos • uma lâmpada pode estar acesa, apagada, queimada
• às vezes, é necessário examinar o comportamento de • evento que desencadeia mudança de estado: pressão
no interruptor torna acesa a lâmpada
um objeto Diagrama de Transição de Estado
• mudança de estado que desencadeia operação: ao ser
• o Diagrama de Transição de Estado (DTE) mostra: demitido, calcular rescisão do func.
– os estados de um objeto • estados de uma reserva de passagem aérea: solicitada,
– os eventos ou mensagens que causam transição confirmada, alterada, atendida, na lista de espera,
cancelada
– as ações que resultam de uma mudança de estado
Araújo 217 Araújo 218

... Introdução a UML ... ... Introdução a UML ...


...Transição de Estados...
...Transição de Estados... • um estado de um objeto pode ser caracterizado pelo valor
DTE de uma Lâmpada de um ou mais atributos do objeto
• estados de uma disciplina ofertada: aberta (há vaga),
Pressão no Evento fechada (não há mais vaga), cancelada
Apagada Interruptor /
Acender Ação • no caso anterior, o estado é caracterizado pelo número de
alunos matriculados
Pressão no
Interruptor / • um DTE mostra todas as mensagens que um objeto pode
Apagar Acesa enviar e receber
/Queimar
• nem toda classe necessita de um DTE: apenas aquelas
cujos objetos apresentam um comportamento dinâmico
significativo
Queimada
Araújo 219 Araújo 220
... Introdução a UML ... ... Introdução a UML ...

...Transição de Estados... ...Transição de Estados...


• o ciclo de vida de um objeto compreende
• um estado é uma condição na vida de um
suas diversas mudanças de estado
objeto:
• um funcionário é entrevistado, admitido,
– quando ele satisfaz alguma condição treinado, afastado, reciclado, demitido
– quando realiza alguma atividade • um sinal de trânsito fica verde, amarelo,
– quando espera por um evento vermelho, ... (continuamente)
• um pedido é solicitado, fica pendente, é
atendido ou é cancelado (tem início e fim)
Araújo 221 Araújo 222

... Introdução a UML ... ... Introdução a UML ...

...Transição de Estados... ... Transição de Estados ...


DTE de um Sinal de Trânsito • há dois estados especiais num DTE:
Verde – inicial apenas um por DTE
– parada pode haver mais de um por DTE
• uma transição de estado pode ter uma ação e/ou
uma condição de guarda associada e pode
Amarelo disparar um evento
• uma ação é o comportamento que acompanha a
Vermelho transição de estado

Araújo 223 Araújo 224


... Introdução a UML ... ... Introdução a UML ...

Pseudoestado
Superestado Histórico (armazena
último subestado)
Araújo 225 Araújo 226

... Introdução a UML ... ... Introdução a UML ...


... Transição de Estados ... ... Transição de Estados ...
• O rótulo de transição de estado tem três
componentes , todos opcionais, no formato: Estado1
evento [condição de guarda] / ação entry: atividade1
do: atividade2
• Ação é associada à transição entre estados exit: atividade3

enquanto atividade está associada a estado


• Quando só existe ação no rótulo de uma transição, evento [condição de guarda] / ação
esta ocorre quando uma atividade associada ao
estado é completada Estado2
• A condição de guarda deve retornar verdadeiro para entry: atividade1

a transição ocorrer
Araújo 227 Araújo 228
... Introdução a UML ... ... Introdução a UML ...

... Transição de Estados ... ... Transição de Estados ...


• Uma condição de guarda é uma expressão
Ação Atividade
booleana de valores de atributos que permite a
• Processo associado a • Processo associado a um transição de estado somente se a condição for
uma transição de estado estado verdadeira; Ex.: [haEstoque] / atenderPedido
• Processo de curta • Processo mais duradouro • Tanto ações como condições definem
duração • Uma atividade pode ser comportamentos do objeto que se transformam
• Não pode ser eventualmente em operações
interrompida interrompida (por um
evento)

Araújo 229 Araújo 230

... Introdução a UML ... ... Introdução a UML ...


Iniciada
Conta Especial ... Transição de Estados ...
Encerrada
abertura / sld=vlDepositado • Diagrama de Transição de Estado modela o
saque[ sld >= 0 ] deposito comportamento de um objeto, através de vários
encerramento casos de uso
Aberta deposito[ sld >= 0 ] • Diagramas de interação modelam o
saque[ -sld > lim ]
comportamento de vários objetos em um único
saque[ 0 < -sld <= lim ] deposito[ -sld > lim ] caso de uso
deposito[ sld >= 0 ] • Diagramas de atividade modelam a seqüência
Negativa saque[ -sld > lim ] Bloqueada
geral de ações para vários objetos e casos de
deposito[ 0 < -sld <= lim ]
uso
saque[ 0 < -sld <= lim ]
deposito[ 0 < -sld <= lim ]
Araújo 231 Araújo 232
... Introdução a UML ... ... Introdução a UML ...
Diagrama de Atividades... Diagrama de Atividades modela
Receber
Pedido Separação • lógica de caso de uso
Início
Emitir N. Emitir • processo de negócio
Desvio Fatura
Fiscal • comportamento paralelo
Atividade
• programação com multithreading
Entrega Entrega Receber
Motoq. Normal Pagto • workflow entre vários casos de uso

Intercalação Fim
Junção Encerrar
Araújo Pedido 233 Araújo 234

... Introdução a UML ... ... Introdução a UML ...


Checar Diagrama de Atividades para ... Diagrama de Atividades
limite s Inscrever Aluno na Disciplina Modela o fluxo de atividades na realização de uma tarefa
[ for a limite ] Informar que já fez as Quando usar:
inscr içõe s po ssíve is
[ ok ] • Ao analisar um caso de uso (sem preocupação em alocar
[ não há vaga ] Colocar na lista ações a objetos)
de espera
[ ok ] • Ao analisar um processo de negócio
• Ao trabalhar com processamento paralelo
Info rma r S ist Inscrever na Não usar o Diagrama de Atividades para ver:
de Cobrança Disciplina
• Como os objetos colaboram (DSE ou DCO)
• O ciclo de vida de um objeto (DTE)

Araújo 235 Araújo 236


... Introdução a UML ... ... Introdução a UML ...
Escolher
Diagrama de Atividades Produto
DAT – Carrinho de Compra
Seleciona Cria Msg e mostra
Compor Msg em branco Adic ionar
Carrinho
[mais produto]

Escolher
Contato

[ escolhe destinatário ] [cartão de crédito]


[cheque pré] [crediário]

Consultar Consultar SPC Solicitar


SERASA Autorização
Digita Subject Selec iona Livro Ex ibe Lista
Endereços Contatos [OK] Imprimir Carnet
[OK]
[ñ OK]

Digita Corpo da Salva Msg Gravar Avisar Cli Registrar Venda


Cheque
Msg

Atualizar
Es toque
Araújo 237 Araújo 238

... Introdução a UML ... ... Introdução a UML ...


Passageiro Vendedor Empresa Aérea Extensibilidade na UML
Servidor de BD
Solicitar
passagem
• Tagged Value – extensão das {processadores = 3}
Verificar
Voos propriedades de um elemento UML
Dar Informacao
Informar voos e
de Voo para adicionar informação na
Selecionar
precos especificação do elemento
Voo PJuridic a
• Constraint – extensão da
semântica de um elemento UML Cont aCorrente
Solicitar Reservar { ou }
Pagamento Lugares para adicionar ou modificar regras
PFisica
Confirmar • Estereótipo – extensão de
Efetuar
Pagamento
Reserva Lugar vocabulário para criar novos blocos
de construção similares aos << comunica >>
existentes, mas específicos ao
Emitir problema
Bilhete
Araújo 239 Araújo 240
... Introdução a UML ... ... Introdução a UML
Captura de Requisitos Análise e Projeto Implementação • Um pedreiro esperto constrói uma
Diagramas de garagem sem necessidade de plantas
Estados

Diagramas de Diagramas de • Uma equipe precisa de plantas para


Sequência Implantação
construir uma casa de alguns cômodos
Diagramas de
Diagramas
Casos de Uso
de Classes
• Nenhuma construtora construiria um
Diagramas de
Diagramas de
Componentes edifício sem um conjunto completo e
Comunicação
detalhado de plantas
Diagramas de Diagramas de
Atividade Atividade "You can model 80 percent of most problems by
using about 20 percent of the UML."-- Grady Booch
Araújo 241 Araújo 242

Desenvolvimento de Software... ...Desenvolvimento de Software...


O que se comenta sobre desenvolvimento de SW: O que se comenta sobre desenvolvimento de SW:
• Prazos de desenvolvimento não são cumpridos • Menos de 5% do software desenvolvido é usado
sem alterações
• 31% dos projetos de software não terminam
• Mais de 95% são alterados ou não são
• 53% custam 200% do valor original estimado utilizados
• Empresas e governo americanos gastaram em – Usados após alterações
1995, U$ 81 bi em projetos de software que – Grande reprogramação
foram cancelados – Entregue mas não utilizado
– Pago mas não entregue
Dados do governo americano
Araújo 243 Araújo 244
...Desenvolvimento de Software... ...Desenvolvimento de Software...
• 56% dos bugs encontrados referem-se a erros • Empresa com bom desempenho gasta 80% de
durante a análise dos requisitos seu esforço na prevenção de problemas
• 31% dos projetos de software são cancelados • Empresa com baixo desempenho gasta 90% de
antes de sua conclusão seu tempo corrigindo sintomas ao invés de
• 53% dos projetos custam 189% do estimado causas
• 9% dos projetos em grandes empresas • Nos EUA, software comercial típico apresenta
cumprem prazo e preço orçados cerca de 3.000 defeitos / MLOC
• 16% dos projetos em pequenas empresas • Fujitsu Æ 10 defeitos / MLOC
cumprem prazo e preço orçados • Testes detectam apenas 70% dos defeitos
latentes no código
Pesquisa do Standish Group em 253 empresas
• Inspeções podem detectar 80 a 90% dos erros
antes dos testes
Araújo 245 Araújo 246

...Desenvolvimento de Software... ...Desenvolvimento de Software...


Desenvolver software é complicado ao… O que se comenta sobre desenvolvimento de SW:
– Capturar os requisitos com precisão
– Entender os requisitos • Foco no conjunto de características mínimas do
– Analisar e projetar soluções que cumpram os sistema
requisitos • Cultura centrada em resultados
– Implementar soluções que contemplem a rápida • Modelagem Orientada a Objetos
mudança e obsolecência dos requisitos
– Testar o software • Forte ênfase na arquitetura
– Distribuir o software • Ciclo de desenvolvimento iterativo e incremental
– Incrementar
Cinco Hábitos para Sucesso em Projetos - Grady Booch

Araújo 247 Araújo 248


...Desenvolvimento de Software... ...Desenvolvimento de Software...
O que se comenta sobre desenvolvimento de SW: A Tríade do desenvolvimento • O método é essencial
• Máximas na Volvo Sueca Método • A notação padroniza a
comunicação
– Reuse antes de comprar (RUP)
• A ferramenta agiliza
– Compre antes de codificar automatizando
• Dá para trabalhar sem uma
– Codifique para reusar ferramenta
• Fica muito ruim sem uma
notação conhecida
Notação Ferramenta • É improdutivo sem método
(UML) (ROSE)

Araújo 249 Araújo 250

...Desenvolvimento de Software... ...Desenvolvimento de Software...


Cascata X Iterativo e Incremental
Processo Cascata

• Cascata – uma etapa é iniciada somente


quando a anterior é concluída
• Iterativo – aplicação repetitiva de tarefas a fim
de melhorar um produto intermediário
• Incremental – criação de produtos intermediários
de modo que cada um acrescente valor ao
projeto global Proposta de Winston Royce, prevendo retroalimentação.
Com o tempo, a retroalimentação foi abandonada.
Araújo 251 Araújo 252
...Desenvolvimento de Software... ...Desenvolvimento de Software...
• No modelo cascata é comum “congelar” os Etapa do desenvolvimento Custo relativo do reparo
requisitos levantados antes de iniciar a análise
• Alguns requisitos são voláteis, podem mudar Requisitos 0,1 a 0,2
durante o desenvolvimento Análise e Projeto 0,5
• Congelar requisitos é impraticável diante das
mudanças e competitividade das empresas e da Implementação 1
complexidade das aplicações atuais Testes 2 a 5
• Recursos podem ser desperdiçados desenvolvendo
Manutenção 20
em cascata usando requisito incorreto – pode sair
muito caro Carper Jones examinando 6.700 sistemas, em 1997

Araújo 253 Araújo 254

...Desenvolvimento de Software... ...Desenvolvimento de Software...


• No método cascata é difícil mensurar o Método Iterativo e Incremental
andamento do projeto • Surgiu para resolver os problemas do método cascata
• Se após 4 meses foram implementadas 25% das • O desenvolvimento é dividido em iterações
funcionalidades, estima-se mais 12 meses? • Em cada iteração há análise, projeto, programação, teste
• Após alguns meses, tem-se apenas farta e liberação de parte do sistema
documentação de análise e projeto • O método incremental e iterativo é como se fosse a
• Fica difícil estimar quanto tempo falta para aplicação do método cascata em cada iteração
concluir por falta de uma parte do sistema pronta • Alguns métodos Incrementais e Iterativos:
• Ainda se usa bastante o método cascata OPENUP, RUP, XP, ICONIX

Araújo 255 Araújo 256


...Desenvolvimento de Software... ...Desenvolvimento de Software
Vantagens de um método Iterativo e Incremental: esforço
• Complexidade controlada porque cada iteração
cuida de uma pequena parte da funcionalidade
• Feedback gerado muito cedo, a partir da t
liberação de cada iteração para os usuários Cascata 100 %
• Requisitos podem ser reajustados para atender
às necessidades dos usuários e negócios esforço
• Motivação para desenvolvedores e satisfação Inc 3 Inc 4
para usuários pela rápida liberação das Inc 1 Inc 2
primeiras iterações t
100 % 100 % 100 % 100 %
Iterativo / Incremental
Araújo 257 Araújo 258

O Método ... ... O Método ...


Fase Exploratória Fase Evolutiva
Planejamento da
• Declaração de Objetivos Várias iterações com: Fase Exploratória Fase Evolutiva
• Diagrama de Casos de Uso • Análise Ambiente
• Diagrama de Classes Tecnológico
• Projeto
• Ambiente tecnológico Diagrama
• Programação de Classes
• Planejamento da fase
evolutiva • Teste Diagrama de
Casos de Uso
Declaração
de Objetivos

Araújo 259 Araújo 260


... O Método ... ... O Método ...
FASE EVOLUTIVA (Várias iterações) Fase Exploratória Fase Evolutiva
1 1 1 ¾Declaração de Objetivos Várias iterações com:
2 2 1. Análise
3 3 2 • Diagrama de Casos de • Análise
4 3 2. Projeto
4 Uso
4 • Projeto
3. Programação • Diagrama de Classes
• Programação
• Ambiente tecnológico
4. Teste • Teste
• Planejamento da fase
evolutiva
t

Araújo 261 Araújo 262

... O Método ...


Declaração de Objetivos
... O Método ...
Descrever, de forma sucinta e objetiva, em uma Fase Exploratória Fase Evolutiva
página, no máximo, a finalidade do sistema. 9 Declaração de Objetivos Vários iterações com:
O Sistema de Compra e Venda de Mercadorias tem ¾ Diagrama de Casos de Uso • Análise
como objetivos automatizar de forma integrada as • Diagrama de Classes • Projeto
atividades de: • Ambiente tecnológico
• COMPRAS DE MERCADORIAS • Programação
• Planejamento da fase
• VENDAS DE MERCADORIAS evolutiva • Teste
• CONTROLE DO ESTOQUE
• CONTABILIZAÇÃO

Araújo 263 Araújo 264


... O Método ... ... O Método ...
Diagrama de Casos de Uso ... ... Diagrama de Casos de Uso ...

Desenhar Diagrama de Casos de Uso Relacionar, com descrição sucinta ao lado, os


principais casos de uso do sistema.
• Manter dados pessoais – auxiliar de pessoal acessa
Manter Dados cadastro do funcionários e faz alterações em seus dados
Pessoais pessoais
• Calcular folha – auxiliar de pessoal inicia cálculo da folha
de pagamento; um contracheque é gerado para cada
Calcular Folha
Funcionário funcionário
Auxiliar
• Avaliar pessoal – auxiliar de pessoal inicia processo de
Pessoal
avaliação de pessoal
Manter Registro • Manter registro funcional – auxiliar de pessoal acessa
Avaliar Pessoal Funcional cadastro do funcionários e altera registro funcional
Araújo 265 Araújo 266

... O Método ... ... O Método ...


... Diagrama de Casos de Uso ... ... Diagrama de Casos de Uso ...

Para estimar tempo usando UCPA... ...Para estimar tempo usando UCPA
Caso de uso PROCESSAR PEDIDO... ...Caso de uso PROCESSAR PEDIDO
• Caminho (cenário) principal • Caminhos de exceção
– Cliente solicita produtos com pagamento no – Cliente solicita produtos com pagamento com cartão
crediário, sem entrada e este está bloqueado
• Caminhos alternativos – Cliente solicita produtos com pagamento no crediário,
– Cliente solicita produtos com pagamento via cartão mas está registrado no SPC
– Cliente solicita produtos com pagamento no – Cliente solicita produtos com pagamento com cheque
crediário com entrada pré e tem registro de cheque devolvido
– Cliente ... com pagamento via cheque pré-datado
Araújo 267 Araújo 268
... O Método ... ... O Método ...
Diagrama de Classes ...

Fase Exploratória Fase Evolutiva Desenhar um diagrama com:


9 Declaração de Objetivos Várias iterações com:
• as principais classes de negócio referentes ao
9 Diagrama de Casos de Uso • Análise
¾ Diagrama de Classes domínio do problema,
• Projeto
• Ambiente tecnológico • Programação • os principais atributos
• Planejamento da fase • os relacionamentos
evolutiva • Teste

Araújo 269 Araújo 270

... O Método ... ... O Método ...


... Diagrama de Classes ... ... Diagrama de Classes ...

Produto Descrever sucintamente cada classe


Pr oP ed
q tProP ed
cdPro
dsPro
• Cliente - dados e operações dos clientes da
vlP roP ed 0..* 1 qtE stoq empresa
vlPreco • Pedido – dados e operações dos pedidos
1..* solicitados pelos clientes e atendidos pelo vendedor
• Vendedor – dados e operações de vendedores
1 • Produto – informações e operações relativas aos
Cliente
Vendedor produtos que podem ser pedidos
cdC li Pedido
cdV en
nmC li nrP ed
nmVen • ProPed – dados e operações referentes aos
enC li 1 0..* dtP ed 0..* 1
d tNa sc
sxV en produtos de cada pedido

Araújo 271 Araújo 272


... O Método ... ... O Método ...
... Diagrama de Classes ... ... Diagrama de Classes ...
Relacionamento tipo associação Agregação
• conexão semântica entre classes independentes que
podem trocar mensagens entre si num diagrama de
• É uma forma mais forte de associação
interação (DSE ou DCO) • Relacionamento entre o todo e suas partes
• associação bidirecional entre classes A e B coloca em A • Representado por uma reta cheia com um
um atributo do tipo B, e em B um do tipo A, permitindo
que cada uma conheça a outra pequeno losango na extremidade do lado todo
• representada com uma reta cheia Pnf
NF cdPro : Integer
NF
Clien nrNF : Integer nrNF : Integer
nrNF : Integer 1..*
nrCli : Integer +comprador +notFis dtNF : java.util.Date qtd : Integer
dtNF : java.util.Date
nmCli : String val : Integer
1 0..* total() +theNF +itNota
total()
Cli() NF() totalProd()
NF()
Pnf()
Araújo 273 Araújo 274

... O Método ... ... O Método ...


... Diagrama de Classes ... ... Diagrama de Classes ...
Dependência Realização
• Unidirecional com reta pontilhada com seta aberta • Modela o relacionamento entre uma classe e uma
em uma das extremidades interface (a classe realiza a interface)
• Não há atributo de conexão nas classes • Separa uma interface de sua implementação
• Quando uma classe é passada como parâmetro ou • Reta pontilhada com seta triangular (fechada)
como tipo de retorno da outra apontando para a interface
• Uma classe não acessa atributos da outra • Modela também o relacionamento entre uma pacote e
sua interface ou entre um caso de uso e a realização
Eco Isom do caso de uso Clien
emitirSom (Isom t) <<Interface>> nrCli : Integer
emitirSom() ICli nmCli : String
soar()
Eco()
Araújo 275 Araújo Cli() 276
... O Método ...
... O Método ... Ambiente Tecnológico ...

Fase Exploratória Fase Evolutiva Definir o que será usado como:


9 Declaração de Objetivos Várias iterações com: • Sistema operacional no cliente e no servidor
9 Diagrama de Casos de Uso • Análise • Banco de dados
9 Diagrama de Classes • Projeto
¾ Ambiente tecnológico • Linguagem de programação
• Programação
• Planejamento da fase • Ferramenta CASE
evolutiva • Teste
• Interface com o usuário (CUI, GUI, WEB)
• Número de camadas (2, 3, 5 ou 6)

Araújo 277 Araújo 278

... O Método ... ... O Método ...


... Ambiente Tecnológico ... ... Ambiente Tecnológico ...
Desenvolvimento em 3 camadas lógicas... • Vantagens da arquitetura em camadas
• Apresentação – GUI / NUI (browser) – Desacoplamento
• Lógica – Manutenibilidade
– parte muito dinâmica – Reuso
– regras de negócio mudam muito – Escalabilidade (maior número de usuários)
– não deve conter lógica de interface com o usuário
nem lógica de acesso a dados • Desvantagens da arquitetura em camadas
• Dados – Performance ( a representação dos objetos sofre
– parte mais estática da aplicação transformações, de camada a camada)
– solicitações de dados (SQL) – Dificuldade de implementação
– modelos de acesso variam (DAO, ADO,...)
Araújo 279 Araújo 280
... O Método ... ... O Método ...
... Ambiente Tecnológico ... ... Ambiente Tecnológico ...
As 3 camadas lógicas podem ser implementadas
em apenas 2 camadas físicas As 3 camadas lógicas podem ser
CLIENTE GORDO SERVIDOR implementadas em 3 camadas físicas:
• Serviços de apresentação • Serviços de dados
• Serviços de negócio
CLIENTE – serviços de apresentação
ou SERVIDOR DE APLICAÇÃO – serviços de
CLIENTE MAGRO SERVIDOR negócio
• Serviços de apresentação • Serviços de negócio
• Serviços de dados
SERVIDOR DE DADOS – serviço de dados

Araújo 281 Araújo 282

... O Método ... ... O Método ...


... Ambiente Tecnológico ... ... Ambiente Tecnológico ...
Serviços de negócios pode ser dividida em 2 camadas: Desenvolvimento em 6 camadas lógicas...
• Serviços de validação • Apresentação – form VB (.EXE) ou HTML
• Regras de negócio propriamente ditas • Validação – ASP ou JSP ou VB (.EXE)
Serviços de dados pode ser dividida em 3 camadas: • Regras de Negócio – Java Beans ou EJB ou
VB (ActiveX .DLL ou .EXE)
• Tradução de dados – comandos DML de SQL • Tradução de Dados – DML SQL - Java Beans
• Acesso a dados – JDBC, ADO, ODBC, ... com JDBC ou VB (ActiveX .DLL ou .EXE)
• Banco de dados – tecnologia de BD (Oracle, DB2) • Acesso a Dados – JDBC ou ADO / ODBC
• Tecnologia de BD – Oracle / DB2 / SQL Server

Araújo 283 Araújo 284


... O Método ...
... Ambiente Tecnológico ... ... O Método ...
Vantagens das 6 camadas lógicas
• Manutenibilidade – alteração em Regra de Negócio não Fase Exploratória Fase Evolutiva
altera form, em lay-out de form não altera Regra de 9 Declaração de Objetivos Várias iterações com:
Negócio 9 Diagrama de Casos de Uso • Análise
• Portabilidade – fácil trocar as camadas extremas (GUI / 9 Diagrama de Classes • Projeto
NUI) ou (SQL Server / Oracle) 9 Ambiente tecnológico • Programação
• Flexibilidade – possível GUI e NUI simultâneas ¾ Planejamento da fase
evolutiva • Teste
Desvantagens das 6 camadas lógicas
• Muitas camadas reduzem performance de execução
• Solução para transações muito lentas – Stored Procedure
(reduz portabilidade)
Araújo 285 Araújo 286

... O Método ... ... O Método ...


Planejamento da Fase Evolutiva ... ... Planejamento da Fase Evolutiva ...

• A fase evolutiva consiste de iterações de • Determinar que casos de uso farão parte de
desenvolvimento que devem durar de duas a cada iteração de desenvolvimento na fase
oito semanas cada uma evolutiva (um caso de uso pode ser feito,
• Cada iteração tem as etapas de análise, parte em uma iteração, e parte noutra iteração)
projeto, programação e teste e ao final é
liberada para o usuário final ou só internamente • Estimar o tempo gasto para liberação de cada
iteração de desenvolvimento (entre duas e oito
• Nas iterações iniciais incluir casos de uso que semanas cada uma)
oferecem riscos tecnológicos e os de maior
retorno para a organização
Araújo 287 Araújo 288
... O Método ... ... O Método ...
... Planejamento da Fase Evolutiva ...
• Iteração 01 (4 semanas) • Iteração 03 (2 semanas)
– Registrar venda à vista – Receber pagamento de
prestação Fase Exploratória Fase Evolutiva
– Calcular comissão de
vendedores – Agendar pagamento de 9 Declaração de Objetivos Várias iterações com:
– Receber mercadoria duplicata
(atualiza estoque mas não – Registrar pagamento de 9 Diagrama de Casos de Uso ¾ Análise
verifica pedido de compra) duplicata 9 Diagrama de Classes
• Iteração 02 (3 semanas) • Iteração 04 (3 semanas)
• Projeto
– Aprovar crédito de cliente – Registrar cliente no SPC
9 Ambiente tecnológico • Programação
– Registrar venda a prazo – Regularizar cliente no SPC 9 Planejamento da fase
(contrato) evolutiva • Teste
– Emitir sugestão de compra
– Receber mercadoria
(verifica pedido de compra)

Araújo 289 Araújo 290

... O Método ... ... O Método ...


Análise ... ... Análise ...
Para cada caso de uso da iteração: Caso de Uso Alugar Fita ...
• Descrever fluxo de eventos Fluxo Principal
• Especificar Caso de Teste para cada cenário 1. Cliente leva ao balcão as fitas a alugar
• Rascunhar desenho de telas e relatórios 2. Cliente diz seu nome e dá as fitas ao atendente
• Desenhar diagramas de seqüência para os 3. Atendente digita nome do cliente e inicia o aluguel
cenários 4. Atendente registra cada fita recebida
• Identificar as classes de fronteira do usuário a 5. Atendente encerra aluguel, entrega fitas ao cliente
partir de telas e relatórios e informa data de devolução e valor do aluguel

Araújo 291 Araújo 292


... O Método ... ... O Método ...
... Análise ... ... Análise ...
... Caso de Uso Alugar Fita ... ... Caso de Uso Alugar Fita
Fluxo alternativo Fluxos de Alternativo ...
3a. Cliente não possui cadastro 3b. Cliente inadimplente
3b. 1. Cliente paga atrasado
3a. 1. Cliente fornece dados para cadastro
3b. 2. Atendente registra quitação e normaliza situação do cliente
3a. 2. Atendente cadastra o cliente
3b. 3. Voltar para item 3
3a. 3. Voltar para item 3 4a. Fita não está disponível
4a. 1. Atendente informa indisponibilidade da fita
4a. 2. Aluguel prossegue item 3 sem incluir a fita
Araújo 293 Araújo 294

... O Método ... ... O Método ...


... Análise ... ... Análise ...
Caso de Uso Alterar Cargo de Funcionário 1. Vendedor se loga
Fluxo de eventos Atender Pedido:
Auxiliar de Pessoal Sistema 2. Vendedor informa nº do cliente ou CPF ou nome + data nasc
1. Seleciona funcionário 3. Sistema identifica cliente
2. Exibe cargo atual 4. Para cada produto solicitado:
3. Seleciona novo cargo 4.1 Obter preço e quantidade em estoque
4. Verifica existência de vagas 4.2 Digitar quantidade solicitada pelo cliente
4.3Calcular valor = quantidade X preço
6. Confirma 5. Verifica se funcionário preenche requisitos
5. Calcular total do pedido
7. Incrementa qtd de promoções 6. Selecionar forma de pagamento:
8. Grava novo cargo 6.1 Crediário sem entrada:
6.1.1 Sistema exibe os planos de pagamento sem entrada
9. Audita mudança de cargo 6.1.2 Vendedor seleciona o plano
6.1.3 Sistema acessa SPC
4e. Exibe msg: “Não há vaga” Se credito OK e vendedor confirma plano selecionado
Plano confirmado
5e. Exibe msg: “Func. n preenche requisitos senão
Araújo 295 Araújo Plano não confirmado 296
... O Método ... ... O Método ...
... Análise ... ... Análise ...
Fluxo de eventos Atender Pedido: Fluxo de eventos Atender Pedido:
6.2 Crediário com entrada: 6.4 Cheque pré-datado
6.2.1 Sistema exibe os planos de pagamento com entrada 6.4.1 Sistema exibe planos de pagamento com cheque
6.2.2 Vendedor seleciona o plano 6.4.2 Vendedor seleciona o plano
6.2.3 Sistema acessa SPC 6.4.3 Sistema acessa SERASA
Se crédito OK e vendedor confirma plano selecionado Se OK e vendedor confirma plano selecionado
Plano confirmado
senão
Plano confirmado
Plano não confirmado senão
Plano não confirmado
6.3 Cartão de crédito
6.3.1 Sistema exibe as opções de cartão 7. Se plano confirmado:
6.3.2 Vendedor seleciona cartão 7.1 Registrar pedido
6.3.3 Sistema acessa administradora de cartão 7.2 Atualizar estoque
Se OK , pedido confirmado
senão, pedido não confirmado 7.3 Emitir carnet
Araújo 297 Araújo 298

... O Método ... ... O Método ...


... Análise ... ... Análise ...
Caso de Teste: CT001 Caso de Teste: CT002
• Cenário: Atender pedido com pagamento no • Cenário: Atender pedido com pagamento no
crediário, sem entrada crediário e cliente no SPC
• Condição: Pedido atendido com sucesso • Condição: Pedido não atendido – cliente no SPC
• Entradas: • Entradas:
– Código do cliente (V) – Código de cliente no SPC (V)
– * [Código do produto (V), Quantidade (V)] – * [Código do produto (V), Quantidade (V)]
– Plano de pagamento sem entrada (V) – Plano de pagamento do crediário (V)
• Resultado: Pedido atendido com sucesso • Resultado: Mensagem de erro “Cli no SPC”
Araújo 299 Araújo 300
... O Método ... ... O Método ...
... Análise ... ... Análise ...
Rascunhar forms Diagrama de Seqüência: Receber Mercadoria

frmRecMerc : :Produto
: Almoxarife RecebMerc

1 : Abrir
2 : Consulta Produtos
3 : Seleciona Produto
4 : Obter Produto
5: Qtd. Entrada
6: Calc. Estoque. Atual
7 : Confirmar
8 : Atualizar estoque

Araújo 301 Araújo 302

... O Método ... ... O Método ...


... Análise
Diagrama de Seqüência: Cancelar Pedido
frm P edido c tlP edido : Cliente : P edido : P roP ed : Item E s to q
: Rep res
Fase Exploratória Fase Evolutiva
1. A brir()
9 Declaração de Objetivos Várias iterações com:
2. obterCli()

3. obterCli ente() 9 Diagrama de Casos de Uso 9 Análise


4. obt erP ed()
9 Diagrama de Classes ¾ Projeto
5. obterP edido() 9 Ambiente tecnológico • Programação
6. c anc P ed() 9 Planejamento da fase
6.1. c anc P edido()
6.1.1. * c anP roP ed()
evolutiva • Teste
6.1.1.1. atuE s toq()

Araújo 303 Araújo 304


... O Método ... ... O Método ...
Projeto ... ... Projeto ...
Para cada caso de uso da iteração: Diagrama de comunicação: Receber Mercadoria
• Desenhar diagrama de comunicação (ajuda a
determinar as operações das classes) 6: Calc. Estoque. Atual
: Almoxarife frmRecMerc :
• Desenhar diagramas de transição de estado para RecebMerc
classes que necessitem 1 : Abrir
3 : Seleciona Produto 2 : Consulta Produtos
• Completar os atributos e operações das classes 5: Qtd. Entrada 4 : Obter Produto
de negócio 7 : Confirmar 8 : Atualizar estoque
• Projetar estruturas de dados persistentes
• Fazer projeto final da interface com o usuário :Produto

Araújo 305 Araújo 306

... O Método ... ... O Método ...


... Projeto ... ... Projeto ...
Diagrama de Seqüência Diagrama de Comunicação Desenhar diagramas de estado para classes que necessitem
• muito útil no início da • mais útil em tempo de DTE de OfertaDisciplina
análise projeto Iniciada
• exibe o cenário dando • fornece uma visão geral
ênfase à ordem do cenário Inclusão Aluno/Count=1
Inc Aluno[Count=10]
cronológica em que as • ajuda a identificar todas Inc Aluno[Count<10]
Exc Aluno[Count>0]
mensagens ocorrem entre as interações entre os Fechada
Aberta
os objetos objetos Exc Aluno
• pode ter controle de foco • não tem controle de foco Cancelamento Cancelamento
• numeração opcional de • numeração obrigatória
mensagens de mensagens Cancelada

Araújo 307 Araújo 308


... O Método ... ... O Método ...
... Projeto ... ... Projeto ...
Completar DCL com atributos e operações Completar DCL com atributos e operações

Conta Atributos valor default


cdCta : int + nmCliente : String = ‘Pedro José’
vlSld : BigDecimal tipo atributo
Visibilidade tipo de argumento tipo retorno
depositar(val : BigDecimal)
sacar(val : BigDecimal) Operações
transf(para : Conta, val : BigDecimal) + calcTotal (mmaaIni : int, mmaaFim : int) : float
Argumentos de entrada
Araújo 309 Araújo 310

... O Método ... ... O Método ...


... Projeto ... ... Projeto ..
Completar DCL com atributos e operações Completar DCL com atributos e operações
Visibilidade de atributos e operações: Funcionário
+ pública Æ atributos e métodos são visíveis a todos os + nmFunc : string // público
os métodos de todas as classes (sem encapsulamento) - dtNasc : date // privado
# protegida Æ vistos pelos métodos da classe e das vlSalario : moeda // pacote
suas subclasses e pelas classes do pacote # cdCargo : integer // protegido
não especificada Æ vistos apenas pelos métodos das / idade : integer // derivado
classes pertencentes ao mesmo pacote qtDeFunc : integer // de classe
– privada Æ vistos só pelos métodos da própria classe obterQtDeFunc ( ) // de classe
(máximo encapsulamento)
Sintaxe: <nome> : <tipo de dado> = <valor inicial>
Araújo 311 Araújo 312
... O Método ... ... O Método ...
... Projeto .. ... Projeto ...
• Em tempo de projeto é possível categorizar as classes, Operações
usando estereótipos: • mensagens em diagramas de interação são mapeadas
Em VB: para operações de classes receptoras; Ex.:
– Class Module, incluirDepartamento, excluirDependente
– Collection,
frmDepa oDepa :
– Form,...
Depa
Em Java: :Aux.Pess
– Session 1 : infdepa
– Servlet
2 : processar
– Interface,...
3 : incluirDepa

Araújo 313 Araújo 314

... O Método ... ... O Método ...


... Projeto ... ... Projeto ...
Operações Operações podem ser criadas para apoiar outras
• mensagens em diagramas de interação para classe de • antes de ofertar uma disciplina, verificar capacidade do
fronteira tipo form devem ser implementadas como controle professor Æ validarCapacidadeProfessor ( )
GUI (botão,...); Ex.: processar no diagrama anterior • antes de matricular aluno numa disciplina, verificar se
cursou os pré-requisitos Æ validarPreRequisitos ( )
• mensagem de / para sistema externo (ator) deve ser
mapeada como operação da classe criada para efetuar a • antes de promover o funcionário Æ verificarVagas ( )
comunicação entre os sistemas (geração de arquivo p/ outro Operações podem ser criadas independentemente de DSE
sistema) • nem todo cenário é representado em diagrama de seqüência
• nome de operação deve indicar “a classe que executa a – calcularDV ( )
operação”; Ex.: excluirDependente ( ) – imprimirValorExtenso ( )
– validarSenha ( )
Araújo 315 Araújo 316
... O Método ... ... O Método ...
... Projeto ... ... Projeto ...
Diagrama de classe Diagrama de classe <<entity>>
C liente
<<control>> (from Logical View)
• Se há apenas operações a herdar, usar interface CtlTrf
nrCli
<<boundary>> nmCli
• Uma classe realiza uma interface quando fornece FrmTrf
iniciarTrf()
habilitarC tas()
dsU serID
password
a implementação concreta para a interface: a transferir() ctasC li
verifD isponib()
classe funciona como um subtipo da interface confirmarTrf() obte rCta sCli()

• Se há classificação dinâmica, fazer reuso por <<entity>>


C onta
delegação sldCta
<< entity>>

VOPC LogTrf
obterSld()
debitarTrf ()
gravarLo g() creditarTrf ()
Araújo 317 Araújo 318

... O Método ... ... O Método ...


... Projeto ... ... Projeto ...
Projetar estruturas de dados persistentes
Projetar estruturas de dados persistentes
• Com SGBDOO – as classes de negócio (DCL) Usando SGBDOO (O2, Iris, Poet, Versant, Object Store,...)
serão as classes persistentes (O2, Iris, Poet, • Não maduros mas não sofrem de “impedance
Versant, Object Store,...) mismatch”
• Com SGBDR – as classes de negócio devem ser • Ausência de teoria completa
mapeadas para o modelo relacional • Navegação rápida
• Com SGBDOR – as classes de negócio devem • Ótimo suporte a tipos de dados variados
ser mapeadas para o modelo relacional, • Têm recursos interessantes: longas transações,
aproveitando as extensões OO do SGBD (Caché, controle de versão
PostgreSQL, Oracle v8, DB2, Informix,...)
Araújo 319 Araújo 320
... O Método ... ... O Método ...
... Projeto ... ... Projeto ...
Mapeamento OO para Relacional ( 1 : 1)
Projetar estruturas de dados persistentes
• Criar uma tabela para cada classe
Usando SGBDR
• PK de uma tabela será FK na outra tabela
• consolidados mas há “impedance mismatch”
entre objetos e relações • Se o relacionamento é total dos dois lados, ou se há
• lentos devido aos joins poucas linhas sem associação, melhor será
implementar com uma única tabela
• poucos tipos de dados
• tudo tem que ser uma tabela, pelo menos na
primeira forma normal Medico (idM, nmM, CRM)
Hospital (idH, nmH, idMedDiretor)

Araújo 321 Araújo 322

... O Método ... ... O Método ...


... Projeto ... ... Projeto ...
Mapeamento OO para Relacional ( 1 : N)
Mapeamento OO para Relacional (M : N)
• Criar uma tabela para cada classe
• Criar uma tabela para cada classe
• PK da tabela do lado 1 será FK na tabela do lado N
• Criar uma tabela associativa
• PK de cada uma das tabelas originais será FK
Departamento (idD, nmD, idGerente)) na tabela associativa
• A PK da tabela associativa pode ser uma
Funcionario (idF, nmF, CPF, RG, idDepartamento) surrogate key ou pode ser formada com as FK’s
que vieram das tabelas originais
Funcionário gerencia Departamento (1 : 1)
Funcionário trabalha no Departamento (N : 1)

Araújo 323 Araújo 324


... O Método ... ... O Método ...
... Projeto ... ... Projeto ... OO Æ MR
Alternativa 1 Generalização
Mapeamento OO para Relacional (Agregação) CONTR(idC, endereco)
Contribuinte
Implementar como se fosse associação, tendo PFIS (idF, cpf, nome, dtNasc) endereco
em vista que: PJUR(idJ, cnpj, razaoSocial)
• na composição a exclusão de uma linha da VFIS: select * from CONTR, PFIS
tabela pai deve excluir as linha correspondentes where CONTR.idC = PFIS.idF
da tabela filho VJUR: select * from CONTR, PJUR ...
Pfisica Pjuridica
• na agregação a exclusão de linha da tabela pai Alternativa 2 cpf cnpj
pode não excluir as linhas filho correspondentes PJUR(idJ, cnpj, razaoSocial, endereco) nome razaoSocial
PFIS(idF, cpf, nome, dtNasc, endereco) dtNasc

Alternativa 3
CONTR(idC, endereco, cpf, nome, dtNasc, cnpj, razaoSocial, tpContr)
Araújo 325 Araújo 326

... O Método ... ... O Método ...


... Projeto ... OO Æ MR ... Projeto ... OO Æ MR

Associação Reflexiva 1 : N +marido +supe rvisor Associação Reflexiva M : N +marido


0..1 1 0..n
Func Func
mat
nome mat
dtAdm nome
FUNC (idF, mat, nome, dtAdm)
n
dtAdm
0..1 +supe rvisiona do CASA (id, idEsposa, idMarido)
+esposa
0..n
FUNC (idF, mat, nome, dtAdm, idSupervisor, idConjuge) +esposa
Araújo 327 Araújo 328
... O Método ... ... O Método ...
... Projeto ... OO Æ MR ... Projeto final da IU ...

Classe Associativa 1 +lider 0..1 Fazer projeto final da interface com o usuário
Func
Proj
ma t
nmP
nome
ver ba
d tAd m 0..n 1..n

Trabalha
ca rg aHor
PROJ (idP, nmP, verba, idLider) remun
FUNC (idF, mat, nome, dtAdm)
TRABALHA (idT, idF, idP,cargaHor, remun)
Araújo 329 Araújo 330

... O Método ... ... O Método ...


... Projeto final da IU ... ... Projeto final da IU ...

CARACTERÍSTICAS DE UMA IU MODELOS MENTAIS


• A IU afeta o sentimento, as emoções e o humor • A aplicação tem um modelo mental e o usuário
do usuário também tem um. A IU atinge seu objetivo
• Usuário fica feliz se a interface é esperta e as quando os dois modelos coincidem
coisas acontecem como ele espera
• Para descobrir qual o modelo mental do usuário:
• A interface bem sucedida deixa o usuário submeter um protótipo a 5 ou 6 usuários
sentindo-se no comando do ambiente
• Se o modelo mental sugerido pela aplicação não
• Com uma IU intuitiva, o programa funciona
exatamente como o usuário espera for trivial, não será bom para o usuário

Araújo 331 Araújo 332


... O Método ... ... O Método ...
... Projeto final da IU ... ... Projeto final da IU ...

METÁFORAS CONSISTÊNCIA...
• Metáforas ajudam ao usuário a utilizar a IU • Mesmas cores
• Exemplo de metáfora: uma lente de aumento • Mesmo significado para ícones
como ícone é uma bela metáfora para indicar
como dar um zoom • Mesmo significado para atalhos
• Uma metáfora mal escolhida é pior que nenhuma • Mesmos nomes para rótulos de campos
metáfora • Mesma posição para mensagens de erro
• My Briefcase (ícone do Windows 95) não é uma • Mesma posição de botões em todas as páginas
boa metáfora

Araújo 333 Araújo 334

... O Método ... ... O Método ...


... Projeto final da IU ... ... Projeto final da IU ...

...CONSISTÊNCIA... ...CONSISTÊNCIA...
• Consistência facilita treinamento e operacionalidade da IU • Consistência tem a ver com modelo mental do
• Exemplo de falta de consistência para encerrar usuário coincidir com o do software: daí a
programas:
facilidade de aprendizagem e uso
– q!
– [CTRL] + X • A criatividade dos projetistas de IU conspira
– [CTRL] + C contra a consistência
– F3 • Usar padrões em IU significa consistência:
– quit não vale a pena reinventar a roda
– stop

Araújo 335 Araújo 336


... O Método ...
... Projeto final da IU ...
... O Método ...
...CONSISTÊNCIA... com líderes de mercado
Fase Exploratória Fase Evolutiva
• Duplo clique - seleciona palavra num texto
• [CTRL] + S - salvar 9 Declaração de Objetivos Várias iterações com:
• F1 - ajuda 9 Diagrama de Casos de Uso 9 Análise
• Carrinho de compras da Amazon é mantido durante 90 9 Diagrama de Classes 9 Projeto
dias - num site de e-commerce, vale a pena fazer o mesmo 9 Ambiente tecnológico ¾ Programação
• Se quer ser diferente, e sua empresa não tem um padrão 9 Planejamento da fase
de IU, mantenha a consistência pelo menos dentro do seu evolutiva • Teste
aplicativo
• Se usou uma vez F4 para ajuda, usar F4 em todas as
demais ocasiões para ajuda: os usuários podem não ficar
felizes, mas, pelo menos a IU mantém coerência
Araújo 337 Araújo 338

... O Método ...


Programação ... O Método ...
• Codificar os métodos das classes Fase Exploratória Fase Evolutiva
componentes da iteração 9 Declaração de Objetivos Várias iterações com:
9 Diagrama de Casos de Uso 9 Análise
• Reusar componentes sempre que possível 9 Diagrama de Classes 9 Projeto
• Ao codificar, levar em conta a possibilidade 9 Ambiente tecnológico 9 Programação
de futuro reuso 9 Planejamento da fase
evolutiva ¾ Teste

Araújo 339 Araújo 340


... O Método ... ... O Método ...
Teste ... Teste ...

• Testar a codificação produzida na etapa • Teste de Unidade – testa unidade que é formada por
chamadas de métodos e de dados de entrada e saída
anterior • Teste de Integração – verificação após a integração de
• Integrar o código testado ao já existente de um novo módulo a módulos testados anteriormente
• Teste Estrutural (caixa branca) – verificação dos
iterações anteriores diversos caminhos (fluxos) em um programa
• Teste Funcional (caixa preta) – verificação da
• Fazer testes de integração implementação de atendimento a requisito funcional
• Desenhar Diagrama de Componentes • Teste de Sistema – verificação completa do sistema
após os demais testes
• Desenhar Diagrama de Implantação • Teste de Stress – verificação do funcionamento do
sistema em situações limite (dados, usuários,...)

Araújo 341 Araújo 342

... O Método ... ... O Método ...


Teste ... ... Teste ...
Caso de Teste: CT001 Desenhar Diagrama de Componentes
• Cenário: Atender pedido com pagamento no Cobranca.exe Matricula.exe
Executável
crediário, sem entrada Cobrança

• Condição: Pedido atendido com sucesso


Pessoa.dll
• Entradas: Binário Curso.dll
Usuário
Curso
– Código do cliente (V)
– * [Código do produto (V), Quantidade (V)] Prof.cls
Aluno.cls
– Plano de pagamento (V) Fonte Curso.cls Oferta.cls

• Resultado: Pedido atendido com sucesso


Araújo 343 Araújo 344
... O Método ... ... O Método ...
... Teste ... ... Teste ...
Componente Componente
• Unidade de software que pode ser usada na • Uma classe pode fornecer objetos para vários
construção de vários sistemas e que pode ser componentes
substituída por outra unidade que tenha mesma • Componente representa um conceito físico;
funcionalidade classes e subsistemas são conceitos lógicos
• É um módulo físico de código fonte ou runtime • Um componente pode envolver a colaboração
• As tecnologias COM, CORBA, EJB são entre diversos objetos
baseadas em componentes • Conforme a UML:
• Um componente pode prover serviços “componente de software é um módulo, pacote ou
acessados via Interface subsistema que tem uma função e uma interface
claramente definidas e pode ser integrado em um
• Um componente pode envolver mais de uma ou mais sistemas”
classe
Araújo 345 Araújo 346

... O Método ... ... O Método ...


... Teste ... ... Teste ...
Componente Dependência entre Componentes
• Uma classe C++ é mapeada para dois
componentes (.cpp e .h) e uma classe Java é A B
mapeada para um componente (.java)
• Dependência é o único relacionamento entre
componentes
• Uma dependência sugere que um componente A depende de B:
fonte deve ser compilado antes do outro • alguma classe em A depende de alguma classe em B
• Os componentes em UML podem ser do tipo: • B deve ser compilado antes de A
– fonte • alteração em B pode afetar A
– runtime • A é mais difícil de reusar que B
Araújo 347 Araújo 348
... O Método ...
... O Método ... ... Teste ...
... Teste ...
Diagrama de Componentes PlacaMae
- Fornece (implementa) interface Iteclado – interpreta os sinais
crédito deve ser Credito enviados pelo teclado
compilado antes
de vôo - Requer interface Imonitor que exibe os sinais enviados pela
PlacaMae

Vôo Reserva classes: Trial


cmp Version
Componente EA 7.1 Unregiste
Reserva e
frmConfirma

páginas client e
Trial Version EA 7.1 Unregiste
PlacaMae
server para <<DLL>> classes:Cliente,
Servidor Imonitor
procurar vôo e Vôo, ListadoVôo Iteclado
DeVôo
exibir dados ...
Trial Version EA 7.1 Unregiste
Araújo 349 Araújo 350

... O Método ... ... O Método ...


... Teste ... ... Teste
Desenhar Diagrama de Liberação
Diagrama de Implantação (Liberação)
W in 98 S E
P III 500 M hz
• Representa a topologia física do sistema, 128 M B de RA M
12 GB de disco
podendo ou não exibir os componentes que são
executados nessa tecnologia B ro wse r

• Elementos do diagrama: nós e conexões < < TCP /IP > >

• Nó é um um recurso computacional dotado de W in 2000 S erver


2 P roce ssadore s
memória e processador P III - 800 Mhz
5 12 M B de RA M
• Conexão é uma ligação entre os nós 8 0 GB RA ID 5

WE B S e rv e r
S Q l Se r ve r 2 00 0
Araújo 351 Araújo M a trícu l a 352
... O Método Diagrama de Estrutura Composta
... Teste EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial V
class Diag Classe

Desenhar Diagrama de Liberação


EA 7.1 Unregistered Trial Adquirir
Version Prod EA 7.1 Unregistered Trial V
Cliente Servidor de BD
EA 7.1 Unregistered Trial Version
Comprar EA 7.1 Unregistered Trial V
Produto
<<Internet>>
IE 6 EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial V
Windows XP Servidor WEB
Oracle 8
EA 7.1 Unregistered
Produto Trial Fornecedor
Version EA 7.1 Unregistered Trial V
Pedido

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial V


IIS
Servidor de ASP EA 7.1 Unregistered Trial Version
ItemPed
EA 7.1 Unregistered Trial V
Aplicação Wi ndows 2000
Printer EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial V

Ve rifica Cre d
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial V
Araújo 353 Araújo 354

Diagrama de Interação Geral Diagrama de Tempo


Exibe as mudanças de estado de um objeto ao longo do tempo
Trial Version
sd Interação Geral EA 7.1 Unregistered Trial Version EA 7.1 Unregistered EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
sd Tempo
ref
Trial Versionref EA 7.1 Unregistered Trial
[Cli ñVersion
Cadastrado] EA 7.1 Unregistered EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
Iniciar Pedido Cadastrar Cliente

Sinal de Trânsito
Trial Version
Ini EA 7.1 Unregistered Trial Version EA 7.1 Unregistered EA 7.1 Unregistered
Verde
Trial Version
Amarelo
EA 7.1 UnregisteredVerde
Vermelho
Trial Version EA 7.1Vermelho
Amarelo
Unregistered T
[Cli Cadastrado]
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered
Seg 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125 130 135
1 40
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
ref
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered
Fazer Pedido EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
sd Tempo

Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
Sinal de Trânsito

Verde
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
Amarelo

Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
Vermelho

Fim Seg 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125 130 135
1 40
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered
Araújo 355 Araújo 356
Breve Resumo ... ... Breve Resumo ...
Técnicas OO - quando usar ... ... Técnicas OO - quando usar ...
Diagrama Para examinar o comportamento de vários objetos num
Diagrama de Na definição do escopo da aplicação de caso de uso
Casos de Uso Na captura de requisitos Interação Para identificar a colaboração entre os objetos
No planejamento e controle de um projeto iterativo
Diagrama Em diagramas de classe que não cabem em uma folha
de Pacotes A4
Diagrama de Na fase exploratória Em grandes projetos, para subdividir em subsistemas,
Classes Na fase evolutiva, em tempo de análise por exemplo
Ao desenhar modelos de especificação Diagrama Para descrever o comportamento de um objeto ao
Ao desenhar modelos conceituais de Estado longo de vários casos de uso
Para modelar objeto dotado de comportamento muito
dinâmico
Araújo 357 Araújo 358

... Breve Resumo ... ... Breve Resumo


... Técnicas OO - quando usar
Diagrama de Em caso de comportamento paralelo Visão Geral
Atividade Em caso de modelagem de Workflow D Caso de Uso
Em caso de programação com multithreading
Para entender workflow entre vários casos de uso Visão Estática Visão Dinâmica
D CLasse D SEqüência
D COmunicação
Diagrama de Para exibir distribuição e relacionamento entre os D ATividade
Liberação servidores (hardware) D Transição Estado
Diagrama de Para exibir o relacionamento entre os Visão Implantação
Componentes componentes de software (executáveis, DLLs, D ComPonente
fontes) D LIberação
Araújo 359 Araújo 360
UML Bibliografia
• Princípios de Análise e Projeto de Sistemas com UML – Eduardo
Bezerra – Campus
• Análise e Projeto de Sistemas de Informação Orientados a Objetos
– Raul Sidnei Wazlawick – CAMPUS
• UML 2.0 Do Requisito à Solução – Adilson da Silva Lima - ÉRICA
• Desenvolvendo Aplicativos com Visual Basic e UML – Paul R. Reed
– Makron Books
• Developing Applications with JAVA and UML – Paul R. Reed, Jr.
– Addison Wesley
• Applying UML and Patterns – Craig Larman – Prentice Hall
• Fundamentos do Desenho Orientado a Objeto com UML – Meilir
Page-Jones – Makron Books
• UML Distilled Third Edition – Martin Fowler – Addison Wesley

Araújo 361 Araújo 362

Exercício 1 Exercício 2
1. A seu ver, as maiores vantagens em se adotar a Orientação a Relacionar as principais propriedades (atributos) e operações, para:
Objeto são... Veículo
Propriedades... Operações...
2. O que você entende por:
Carteira de Habilitação
a) Encapsulamento ... Propriedades... Operações...

Guarda de trânsito
b) Polimorfismo ... Propriedades... Operações...

Exame
c) Herança ... Propriedades... Operações...

Infração
Propriedades... Operações...

Araújo 363 Araújo 364


Exercício 3 Exercício 4
1. Marcar com V as afirmativas que correspondem ao significado de Marcar com V ou F as afirmações abaixo:
Encapsulamento em OO: ( ) pode haver atributos em uma classe que não são armazenados
em cada Instância
( ) geração de uma estrutura de software (objeto) formada por um
anel de operações que protege os atributos que representam o ( ) o OID de um objeto é facilmente acessada pelo usuário final
estado do objeto ( ) duas instâncias de uma classe podem ter o mesmo estado
( ) uma classe é algo que se projeta e programa; um objeto, a
( ) em termos de implementação, só os métodos do anel de gente cria
operações devem manipular variáveis capazes de manter ( ) mensagem é o meio através do qual um objeto requisita a
(alterar) o estado do objeto execução de uma operação
( ) não favorece a ocultação de informação e implementação ( ) duas operações de uma classe podem ter mesmo nome e
quantidade de argumentos diferentes
2. A classe Pessoa é um bom exemplo de generalização de Cliente e ( ) um objeto funciona como um módulo (função) estruturado:
Funcionário ... (F / V) após sua execução perde seu estado e ao ser novamente
acionado é como se renascesse sem lembrança de sua
existência anterior

Araújo 365 Araújo 366

Exercício 5 Exercício 6
1. Após definir e implementar uma classe M, surgiu uma classe N Na informatização de uma biblioteca é necessário registrar as datas
idêntica (mesmas operações e atributos de M) tendo a mais apenas de empréstimo e de devolução dos livros. É preciso ainda poder
localizar os livros consultando por autor, título, editora, assunto
novos três atributos e três operações. A forma mais racional de principal. Deve ser armazenado um resumo de cada livro com até 200
aproveitar M na implementação de N, sem duplicar esforço de caracteres. Os periódicos não são emprestados. Devem-se controlar
desenvolvimento, é a característica OO : as reservas de livros. Deseja-se poder responder às questões:
. Que periódicos são referenciados pelo periódico P?
( ) agregação ( ) encapsulamento . Quais os autores do livro L?
( ) herança ( ) ocultação de informação . Quais os livros cujo assunto principal é Banco de Dados
2. Numerar a coluna da direita conforme a da esquerda: relacional?
1. Classe ( ) :Aluno . Que livros são referenciados pelo periódico P?
. Quais os autores do periódico P?
2. Um dado objeto ( ) José Carlos Aparecido da Silva e Lima Desenhar um diagrama de casos de uso para o enunciado acima.
3. Objeto ( ) oAluno : Aluno Desenhar um diagrama de classe para o enunciado acima.
( ) Aluno
Araújo 367 Araújo 368
Exercício 7 Exercício 8
1. Numerar a coluna da direita conforme a da esquerda: 1. Numerar a coluna da direita conforme o número do diagrama da
1. Ator ( ) Instância de caso de uso esquerda:
2. Caso de uso ( ) Departamento de compras 1. Classe ( ) modela a interação entre objetos
3. Cenário ( ) Entidade externa 2. Seqüência ( ) modela a parte estática da aplicação
2. São estereótipos de classe em tempo de análise... 3.Caso de Uso ( ) modela o comportamento de um objeto
4. Estado ( ) modela a funcionalidade da aplicação
3. São estereótipos de relacionamentos entre casos de uso... 2. Um atributo derivado (nome iniciado por /), significa uma
redundância.... (F/V)
4. Num sistema de contabilidade, dar exemplos de: 3. Numa classe Pedido, numerar a coluna da direita conforme a da
1. Atores... esquerda:
2. Casos de uso... 1. vlPedido ( ) atributo de classe
3. Classes de entidade... 2. qtdDePedidos ( ) atributo de instância
4. Classes fronteira (relatórios)... 3. obterVlPedido ( ) operação de classe
5. Classes fronteira (telas)... 4. obterQtdDePedidos ( ) operação de instância
Araújo 369 Araújo 370

Exercício 9 Exercício 10
Uma aplicação controla as despesas de viagens feitas pelos 1. Cenários são melhor documentados via...
funcionários de uma empresa a partir de relatórios que registram as 2. Fluxo de evento é documentado via...
despesas. Cada relatório compõe-se de uma ou mais linhas de despesa 3. Multiplicidade é...
com data, tipo de despesa (táxi, refeição, ...) e valor. Cada linha contém
apenas um tipo de despesa. Os funcionários têm um limite máximo de 4. Identificar os caminhos (cenários) do caso de uso Alugar Fitas numa
despesas por relatório (viagem). Há limite também por tipo de despesa Locadora de vídeo.
para cada funcionário (Ex.: funcionário X pode gastar um máximo de R$ 5. Numerar a coluna da direita conforme a da esquerda:
100,00 com táxi numa viagem). Alguns tipos de despesa têm um limite 1. Agregação ( ) discriminador
que vale para todos os funcionários (Ex.: o máximo valor gasto com 2. Generalização ( ) uma empresa tem funcionários
refeição por qualquer funcionário é R$ 500,00). Cada relatório, após 3. Associação ( ) uma nota fiscal tem itens da nota
preenchimento, pode estar em um dos estados: aguardando aprovação, 6. Numerar a coluna da direita conforme a da esquerda:
aprovado ou rejeitado. Funcionário preenche relatório de despesas de 1. Caso de uso ( ) Caminho através do fluxo de eventos
viagem via web e seu gerente aprova ou rejeita relatório de despesas de 2. Ator ( ) Processo
viagem via web. Desenhar DCU e DCL. 3. Cenário ( ) Aplicativo
Araújo 371 Araújo 372
Exercício 11 Exercício 12
Uma empresa de confecção de médio porte fabrica calças, camisas, bermudas, bonés, cuecas, ... As
vendas são efetuadas por representantes da empresa que fazem pedidos para cada loja. Um representante 1. Marcar com V os tipos de relacionamentos válidos num diagrama de
atende a várias empresas e cada empresa tem várias lojas. Uma empresa é atendida por um único classes e com F os inválidos:
representante. É necessário saber a quantidade em estoque na indústria, de cada produto, de cada cor e cada ( ) associação ( ) agregação ( ) generalização
tamanho, isto é, ao tirar um pedido via Internet, de 12 calças de linho branco tamanho 42, um representante ( ) dependência ( ) realização ( ) comunicação
deve saber se há esta quantidade disponível para imediato atendimento. O representante pode também 2. O relacionamento Generalização pode existir entre:
cancelar um pedido ou consultar a posição do mesmo. O lojista também pode consultar a posição de seus
pedidos, vendo via Internet, as datas de solicitação, de expedição e de previsão de chegada à loja, além do
( ) classes ( ) atores ( ) casos de uso
status atual do mesmo (cancelado, expedido, solicitado). Um pedido só é expedido para a loja cliente quando ( ) pacotes ( ) interfaces ( ) relacionamentos
todos os itens desse pedido estiverem disponíveis. Este site fica numa máquina fora da rede da indústria, 3. Realização pode haver entre:
havendo troca de arquivos entre o servidor da rede da indústria e o servidor de banco de dados do site, duas ( ) classe e interface ( ) classes
vezes por dia. Do site para o servidor da indústria são enviados os dados de pedidos efetuados pelos ( ) pacote e interface ( ) componente e interface
representantes enquanto da indústria para o site são enviados dados de preços, novos produtos, quantidade
disponível de itens em cada cor e tamanho, além da expedição de pedidos. O industrial pode consultar via
( ) caso de uso e realização de caso de uso
Internet, enquanto viaja: - 4. Numerar a coluna da direita conforme a da esquerda:
- resumo dos pedidos feitos (quantidade e valor), por representante, por mês 1. Diagrama de seqüência ( ) núm. de seqüência nas mensagens
- resumo dos pedidos feitos (quantidade e valor), por empresa, por mês 2. Diagrama de comunicação ( ) controle de foco
- resumo dos pedidos feitos no mês atual (quantidade e valor) por status 3. Diagrama de classe ( ) dependência
Desenhar um Diagrama de Casos de Uso e um Diagrama de Classe ( ) linha da vida

Araújo 373 Araújo 374

Exercício 13
1. Um atributo estático é compartilhado por todas as
instâncias da classe... (F/V)
2. O diagrama de atividade também é usado pelas
ferramentas CASE para geração de código... (F/V)
3. Uma classe que só tem associações unidirecionais
chegando nela, é bem mais reusável... (F/V)
4. O que poderia haver de errado numa hierarquia de
classes, com superclasse Carro e subclasses Pneu e
Porta?
5. Identificar os caminhos (cenários) do caso de uso
Matricular um Aluno numa Disciplina num Sistema de
Controle Acadêmico de uma universidade.

Araújo 375

Você também pode gostar