Modelagem de Software (TUSKA)

30/08/2011
PONTIFCIA UNIVERSIDADE CATLICA DE SO PAULO

CURSO DE ESPECIALIZAO EM ENGENHARIA DE SOFTWARE
Modelagem de Software
Orientado a Objetos
Apresentao da disciplina
Mdulo I 2 semestre de 2011
Prof. Dr. Maurcio Nacib Pontuschka

tuska@pucsp.br
Orientado a Objetos
Apresentaes iniciais
Prof. Maurcio Nacib Pontuschka

Bacharel em Cincia da Computao PUC-SP
Mestre em Engenharia Eltrica Mackenzie
Ps Graduado pelo MBIS
Master Business Information Systems PUC-SP
Doutor em Comunicao e Semitica PUC-SP
Professor e Coordenador do Curso de
Cincia da Computao da PUC-SP
Consultor nas reas de Desenvolvimento de Sistemas e Gesto de
Projetos de TI, Business Games e Processamento de Imagens
30/08/2011
Orientado a Objetos
Apresentaes iniciais
Sua empresa
Seu cargo
Sua experincia
experincia com tecnologia de objetos
experincia em desenvolvimento de software
Suas espectativas com esta disciplina
Orientado a Objetos
Pblico alvo
Graduados nas reas de Computao, Sistemas de
Informao, Anlise de Sistemas e Tecnologia da
Informao.
Desenvolvedores de software interessados em
modelagem visual de sistemas.
Gerentes de desenvolvimento que desejam entender
melhor a tecnologia de objetos.
Desejvel que conhea e tenha alguma experincia em
programao de computadores.
30/08/2011
Orientado a Objetos
Objetivos previstos na disciplina MSOO
Definir o histrico e a aplicao atual da tecnologia
de objetos.
Explicar o que a UML representa.
Explicar abstrao, encapsulamento, modularidade e
hierarquia.
Descrever a estrutura fsica de uma classe.
Identificar o relacionamento entre objetos e classes.
Definir polimorfismo e generalizao.
Orientado a Objetos
Estrutura da disciplina
Disciplina: MSOO
Parte 1
Parte 2
Parte 3
Parte 4
Princpios de
orientao a
objetos
Princpios de
modelagem
UML
Anlise de
modelos de
software
Estudos de
Caso
6 horas
9 horas
9 horas
6 horas
30/08/2011
Orientado a Objetos
CRAIG LARMAN, Applying UML and Patterns: An
Introduction to Object-Oriented Analysis and Design and
Iterative Development,Bookman, 3rd Edition, 2007.
ERIC FREEMAN, ELISABETH FREEMAN, Use a

Cabea - Padres de Projetos, Alta Books, 2005.
Orientado a Objetos
ERIC GAMMA, RICHARD HELM, RALPH JOHNSON,
JOHN VLISSIDES, Design Patterns,Addison Wesley,
1995.
GRANDY BOOCH, IVAR JACOBSON,

JAMES RUMBAUGH Uml Guia do Usuario, Campus,
2006.
30/08/2011
Orientado a Objetos
ALISTAIR COCKBURN Surviving Object-Oriented
Projects, Addison Wesley, 1998.
BRUCE F. WESTER "Pitfalls of Object-Oriented

Development",M&T Books, 1995.

Orientado a Objetos
Parte 1 Princpios de Orientao a Objetos
Introduo
tuska@pucsp.br
30/08/2011
Modelagem de Software Orientada a Objetos

Princpios de Orientao a Objetos
Tecnologia de Objetos
O que a tecnologia de objetos?
Modelagem de Software Orientado a Objetos

Um conjunto de princpios utilizado na construo
de software, em conjunto com linguagens, bancos
de dados e outras ferramentas que suportam estes
princpios.
Object Technology A Managers Guide, Taylor, 1997.
30/08/2011

Vantagens da Tecnologia de Objetos

Reflete um nico paradigma
Facilita o reuso de arquitetura e de cdigo
Possui modelos mais prximos do mundo real
Oferece uma maior estabilidade
suscetvel a mudanas

Marcos da Tecnologia de Objetos

Simula
C ++
1967
Final de
UML
1980
1996
1972
1991
2004
Smalltalk
Java
UML 2
30/08/2011

Onde a tecnologia de objetos utilizada
atualmente?

Sistemas cliente/servidor e
Desenvolvimento WEB
A tecnologia de objetos permite as empresas a
encapsular as informaes de negcios em objetos e
ajuda a distribuir o processo por meio da Internet ou
uma rede convencional.
30/08/2011

Sistemas em tempo real

A tecnologia de objetos permite o desenvolvimento
de sistemas em tempo real de maior qualidade e
flexibilidade.

Orientao a objetos
Une dados e os processos de fluxo de dados nos
primeiros momentos do ciclo de vida de
desenvolvimento.
Possui um alto nvel de encapsulamento.
Promove o reuso de cdigo.
Permite uma maior abrangncia do software.
30/08/2011

Referncias
IBM Software Group, Essentials of Visual Modeling with UML 2.0.
Rational Web site
http://www-306.ibm.com/software/rational/
Rational developerWorks
http://www-136.ibm.com/developerworks/
UML Resource Center

http://www-306.ibm.com/software/rational/uml/
Rational Edge
http://www-106.ibm.com/developerworks/rational/rationaledge/

Dvidas?
10
30/08/2011

Orientado a Objetos
Parte 1 Princpios de Orientao a Objetos
Continuao
tuska@pucsp.br

O que modelagem?
Um modelo uma simplificao da realidade.
11
30/08/2011

Objetivos da modelagem
Ajudar a visualizar o sistema como gostaramos
que ele fosse
Permitir a especificao da arquitetura e
comportamento de um sistema
Fornecer padres de desenvolvimento que serve
como guia de construo do sistema
Documentar as decises tomadas durante o
processo de desenvolvimento

Por que modelar?

Modelos de sistemas complexos so construdos
porque nem sempre possvel compreend-los em
sua totalidade
Modelos auxiliam o entendimento dos sistemas
que construmos
12
30/08/2011

Importncia da modelagem
Menos importante
Avio de papel
Mais importante
Jato militar

Muitas equipes de desenvolvimento

desenvolvem seus sistemas como se estivessem
construindo avies de papel
Iniciam a codificao diretamente a partir das
especificaes do projeto.
Trabalham durante horas e produzem mais cdigo.
Falta de um plano de arquitetura de software.
Desenvolvimento fadado ao fracasso.
13
30/08/2011

Por que modelar?

A modelagem uma tarefa comum em projetos
bem sucedidos.

Model Driven Architecture (MDA)

Uma abordagem de utilizar modelos no desenvolvimento
de software.
Separar a especificao de uma operao dos detalhes da
forma como o sistema utiliza os recursos da plataforma
utilizada.
Especificar um sistema independentemente da plataforma que o
suportar.
Especificar plataformas.
Escolher uma determinada plataforma para um sistema.
Transformar a especificao de um sistema especfica para uma
determinada plataforma.
14
30/08/2011

Pontos de viso do MDA

CIM Computational Independent Model
O foco est no ambiente do sistema e seus requisitos.
PIM Platform Independent Model

O foco est na operao do sistema, independentemente da
plataforma.
PSM Platform Specific Model

O foco est na utilizao detalhada do sistema em uma
plataforma especfica.

Quatro princpios da modelagem visual

O modelo que criado influencia na forma como o
problema atacado.
Todo modelo pode ser expresso em vrios nveis
de preciso.
Os melhores modelos so os mais prximos
realidade.
Nenhum modelo nico suficiente.
15
30/08/2011

Principio 1: A escolha do modelo importante

Os modelos criados influenciam profundamente em como
o problema atacado e como a sua soluo elaborada.
Modelo de Processo
Modelo de Implantao
Modelo de Projeto

Principio 2: Nveis de preciso podem ser diferenciados

Todo modelo pode ser expresso em diferentes nveis de
preciso.
Quem visualiza o modelo e por que precisam visualiz-lo?
Viso dos
consumidores
Viso dos
desenvolvedores
16
30/08/2011

Principio 3: Os melhores modelos esto ligados realidade

Todos os modelos so simplificaes da realidade.
Um bom modelo reflete caractersticas reais.

Principio 4: Nenhum modelo nico suficiente

Todo sistema (no trivial) melhor abordado por um
conjunto de modelos.
Viso lgica
Viso de Implementao
Analistas/Projetistas
Programadores
Estrutura
Gesto de software
Viso de Casos de Uso

Usurio Final
Funcionalidade
Viso de
processo
Integradores de Sistemas
Performance, escalabilidade,
acoplamento
Viso de
Implantao
Engenharia de Sistemas
Topologia do sistema, entrega,
instalao, comunicao
17
30/08/2011

Prximos objetivos
Descrever uma abstrao, encapsulamento, modularidade
e herana.
Descrever a estrutura fsica de uma classe.
Descrever o relacionamento entre uma classe e um
objeto.
Definir polimorfismo e generalizao.

O que um objeto?
Quatro princpios da OO
O que uma classe?
Polimorfismo e Generalizao
Organizando elementos de modelo
18
30/08/2011

Informalmente, um objeto representa uma entidade

que pode ser fsica, conceitual ou de software.
Entidade fsica
Caminho
Entidade conceitual
Processo qumico
Entidade de software
Lista ligada

Atributos
Em uma definio mais formal:

Um objeto uma entidade com
uma fronteira bem definida e
uma identidade que encapsula
estados e comportamento.
Estado representado por
atributos e relacionamentos.
Comportamento representado
por operaes, mtodos e
mquinas de estados.
Objeto
Operaes
19
30/08/2011

Objetos possuem estados
O estado de um objeto a condio ou situao durante o ciclo de
vida de um objeto o qual satisfaz algumas condies, executa alguma
atividade ou aguarda algum evento. O estado de um objeto
normalmente mudo ao longo do tempo.
Nome: J Clark
ID: 567138
DtContr: 07/25/1991
Area: Finance
Nome: J Clark
ID Funcionrio: 567138
Contratao: 25 de Julho de 1991
rea: Finanas
Professor Clark

Objetos possuem comportamento
O comportamento determina como um objeto age e reage. O
comportamento observvel de um objeto modelado por um
conjunto de mensagens que ele pode responder. (operaes que
o objeto executa).
Comportamento do Professor Clark

Publicar notas finais
Aceitar oferta de curso
Corrigir notas
Professor Clark
20
30/08/2011

Um objeto possui identidade
Cada objeto possui uma identidade nica, mesmo que o estado do
objeto seja idncico ao de outro objeto.
Nome: J Clark
Ensina: Biologia
Nome: J Clark
Ensina: Biologia

O que um objeto?
O que uma classe?
21
30/08/2011

Princpios Bsicos de Orientao a Objetos
Hierarquia
Modularidade
Encapsulamento
Abstrao
Orientao a Objetos

O que abstrao?
So caractersticas essenciais de
uma entidade que a distingue de
todos os outros tipos de entidade.
Define uma fronteira relativa
perspectiva do observador.
No uma manifestao
concreta, denota a essncia ideal
de alguma coisa.
22
30/08/2011

Exemplos de Abstao
Estudante
Oferta de curso (9:00h,

segunda-quarta-sexta)
Professor
Curso (ex: lgebra)

O que encapsulamento?
Esconde a implementao dos clientes
Clientes dependem da interface.
Favorece a adaptabilidade
23
30/08/2011

Exemplo de Encapsulamento
Professor Clark
precisa ser capaz de
ministrar quatro
turmas no prximo
semestre.
Professor Clark
setCargaMxima(4)
Nome: J Clark
ID: 567138
DtContr: 07/25/1991
Disciplina: Finanas
CargaMxima:4

O que Modularidade?
Quebra algo complexo em partes
gerenciveis.
Auxilia as pessoas a entender sistemas
complexos.
24
30/08/2011

Exemplo de Modularidade
Por exemplo, quebrar um sistema
complexo em mdulos menores.
Sistema
de
cobrana
Sistema de
catlogo de
cursos
Sistema de registro
de cursos
Sistema de
gerenciamento
de estudantes

O que hierarquia?
Maior
abstrao
Ativo
Conta Bancria
Menor
abstrao
Poupana
Conta
Corrente
Valores Mobilirios
Aes
Ttulos
Governamentais
Aplices
Elementos em um mesmo nvel hierrquico

devem estar no mesmo nvel de abstrao.
25
30/08/2011

Representao de Objetos em UML

Um objeto representado por um retngulo com um
nome sublinhado.
J Clark :
Professor
Objeto nomeado
: Professor
Professor J Clark
Objeto annimo

O que um objeto?
O que uma classe?
26
30/08/2011

O que uma classe?

Uma classe uma descrio de um conjunto
de objetos que compartilham os mesmos
atributos, operaes, relacionamentos e
semntica.
Um objeto uma instncia de uma classe.
Uma classe uma abstrao que:

evidencia caractersticas relevantes.
suprime outras caractersticas.

Exemplo de Classes
Classe
Curso
Propriedades
Comportamento
Nome
Localizao
Carga horria
crditos
Hora de incio
Hora de trmino
Adicionar estudante
Remover estudante
Obter lista de nomes
Indicar turma lotada
27
30/08/2011

Representando classes em UML

Uma classe representada utilizando um retngulo com
trs compartimentos:
Professor
- nome
- codigoFuncional
- dataDeContratacao
- status
- disciplina
- cargaMax
O nome da classe
A estrutura (atributos)
O comportamento (operaes)
+ publicarNotasFinais()
+ aceitarOfertaDecurso()
+ setCargaMax()

Relacionamento entre classes e objetos

Uma classe uma definio abstrata de um objeto.
Ela define a estrutura e o comportamento de cada objeto da
classe.
Se comporta como um padro (template) para criao de
objetos.
Classes no so colees de objetos.

Professor
Professor Torpie
Professor Meijer
Professor Allen
28
30/08/2011

O que um atributo?
Um atributo uma propriedade nomeada de uma classe e
descreve um conjunto de valores que as instncias desta
propriedade podem assumir.
Uma classe pode possuir um nmero qualquer de atributos
inclusive nenhum.
Estudante
Atributos
- nome
- endereco
- cpf
- nascimento

Atributos em classes e objetos

Classe
:Estudante
Estudante
- nome
- endereco
- cpf
- nascimento
- nome = M. Modano
- endereco = R. Augusta,2
- cpf = 123.456.789/10
- nascimento = 03/10/1967
Objetos
:Estudante
- nome = Ivone Teixeira
- endereco = Av. Paulista,1
- cpf = 111.213.141/51
- nascimento = 12/11/1969
29
30/08/2011

O que uma operao?

Um servio que pode ser requisitado de um objeto para
afetar seu comportamento. Uma operao possui uma
assinatura a qual define a forma e os parmetros da
operao.
A classe pode ter nenhuma ou muitas operaes.
Estudante
operaes
+ getTitulacao()
+ addCalendario()
+ getCalendario()
+ delCalendario()
+ possuiPreRequisitos()

O que um objeto?
O que uma classe?
30
30/08/2011

O que polimorfismo?
Habilidade de esconder muitas implementaes por
trs de uma nica interface.
Fabricante A
Fabricante B
Fabricante C
Princpio OO:
Encapsulamento
Controle Remoto

Exemplo: Polimorfismo
instrumentoFinanceiro.getValorCorrente()
Ao
Ttulo
Fundo de Investimento
31
30/08/2011

O que sobrecarga?
Em uma mesma classe pode possuir operaes com o
mesmo nome e parmetros diferentes.
Quando isso ocorre dizemos que este mtodo foi
sobrecarregado.

O que sobreposio?
Em uma hierarquia de classes caso exista um
mtodo na sub-classe com a mesma assinatura de
um mtodo da classe pai, este se sobrepor o
mtodo da super-classe.
32
30/08/2011

O que Generalizao?
Um relacionamento entre classes onde uma classe
compartilha sua estrutura e/ou seu comportamento de
uma ou mais classes.
Define uma hierarquia de abstraes na qual uma
subclasse herda elementos de uma hierarquia de
superclasses, recebendo como herana suas
caractersticas e comportamento.
Herana simples.
Herana mltipla.
um relacionamento um.

Exemplo: Herana Simples

Uma classe herana de outra.
Ancestral
Conta
- balanco
- nome
- numero
Superclasse
(pai)
+ saque()
+ criarDeclaracao()
Relacionamento
de
generalizao
Subclasses
(filha)
Poupanca
Corrente
Descendentes
33
30/08/2011

Exemplo: Herana Mltipla
Uma classe pode ser herdeira de vrias classes.
Voadores
Animal
Herana Mltipla
Aviao
Helicoptero
Passaro
Lobo
Cavalo
Use a herana mltipla somente quando realmente

necessrio e mesmo assim com muita ateno!

O que Herana?
Um subclasse herda os atributos, operaes e
relacionamentos da superclasse.
Uma subclasse pode:
Adicionar atributos, operaes e relacionamentos novos.
Redefinir operaes herdadas. (Use com cuidado!)
Atributos, operaes e relacionamentos, so mostrados

no nvel mais alto aplicvel da hierarquia.
A herana alavanca as similaridades atravs das classes.
34
30/08/2011

O que um objeto?
O que uma classe?

O que Pacote?
Um mecanismo de proposta geral para organizar
elementos em grupos.
Um elemento de modelagem que pode conter outros
elementos de modelagem.
Um pacote pode ser usado:
Para organizar o modelo em desenvolvimento.
Como uma unidade de gesto de configurao.
Artefatos da
Universidade
35
30/08/2011

Um pacote pode conter classes
O pacote Artefatos da Universidade contm um pacote e cinco
classes.
Artefatos
dos
estudantes
Artefatos
da
Universidade
Curso
Estudante
Professor
Calendario
CursosOferecidos

Representao grfica de um diagrama

Cada diagrama possui um quadro, um compartimento de
cabealho no canto superior esquerdo e uma rea de
contedo.
Se o quadro no fornecer nenhuma informao adicional, este
pode ser omitido e a borda da rea do diagrama fornecida pela
ferramenta ser o quadro indicado se necessrio.
<cabealho>
<contedo>
36
30/08/2011

Reviso
O que um objeto?
Quais so os quatro princpios de orientao a
objetos? Descrever cada um.
O que uma classe? Como relacionar classes e
objetos?
O que um atributo? Uma operao?
Defina polimorfismo. Fornea um exemplo de
polimorfismo.
O que generalizao?
Por que usar pacotes?

Dvidas?
37
30/08/2011

Orientado a Objetos
Parte 2- Princpios de Modelagem UML

tuska@pucsp.br

Princpios de Modelagem UML
O que a UML?
Uma linguagem para:
visualizao,
especificao,
construo e
documentao
de artefatos de um sistema de software
38
30/08/2011

A UML uma linguagem de visualizao

Comunicar modelos conceituais para
outras pessoas tende a erros a no ser
que todos falem a mesma lngua.
Existem coisas a respeito de sistemas de
software que no podem ser entendidas
sem a construo de modelos.
Um modelo explcito facilita a
comunicao.

A UML uma linguagem de especificao

possvel, por meio da UML construir
modelos de forma
precisa, com um mnimo de
ambigidades.
39
30/08/2011

A UML uma linguagem para construo

Modelos UML podem ser conectados
diretamente a uma ampla variedade de
linguagens de programao (Java, C++, C#,
Ruby entre outras).
Mapeamento para tabelas em um SGBDR ou
armazenamento persistente em um SGBDOO.
Permite a engenharia e engenharia reversa.

A UML uma linguagem para Documentao

Documenta a arquitetura do sistema, requisitos, testes,
planejamento do projeto e gesto de versionamento.
Diagrama de
Casos de Uso
Diagrama de Implantao

- 95 :
- NT: -
- : - -, -
- IBM : -, -
Windows95
Window95
Windows95
Use Case 1
-
.EXE
-
Windows
NT
Actor A
Solaris
Actor B
Use Case 2
- .EXE
Alpha
UNIX
-.EXE
Windows
NT
IBM
Mainframe
Use Case 3
-
DocumentList
mainWnd
fileMgr :
document :
gFile
repository
Document
FileMgr
user
Document
FileMgr
add( )
name : int
delete( )
fetchDoc( )
docid : int
sortByName( )
numField : int
get( )
1: Doc view request ( )
read() fill the
open( )
close( )
2: fetchDoc( )
code..
read( )
FileList
sortFileList( )
fList
create( )
3: create ( )
fillDocument( )
add( )
delete( )
1
4: create ( )
5: readDoc ( )
6: fillDocument ( )
- .
rep
7: readFile ( )
File
Repository
8: fillFile ( )
(from Persistence)
read( )
-

9: sortByName ( )
GrpFile
name : char * = 0
-
.
readDoc( )
readFile( )
read( )
open( )
create( )
fillFile( )
Diagrama de Seqncia
Diagrama de Classe
40
30/08/2011

UML 2.0
Hstria da UML
(2004)
UML 1.5
(Mar, 2003)
UML
UML 1.1
Experincias
de parceiros
UML 1.0
(Set. 1997)
(Jan. 1997)
UML 0.9 and UML 0.91

(Jun, 1996)
(Out. 1996)
Feedback
do pblico
Unified Method 0.8

(OOPSLA, 1995)
Booch, 1993 OMT - 2
OOSE
Outros
Mtodos
Booch 1991
OMT - 1

Contribuies para a UML

Rumbaugh
Booch
Jacobson
Meyer
Fusion
Condies anteriores
e posteriores
Descrio de operaes
Numerao de
mensagens
Harel
Embley
Classes Singleton,
Viso de alto nvel
Diagrama de estados
Gamma, et.al
Wirfs-Brock
Frameworks, padres,
notas
Shlaer- Mellor
Ciclo de vida de objetos
Responsabilidades
Selic, Gullekson, Ward
Odell
ROOM (Real-Time
Object-Oriented Modeling)
Classificao
41
30/08/2011

A linguagem no suficiente para

construir um sistema
Desenvolvimento
Baseado em Equipes
Linguagem
de Modelagem
Processo
Unificado

Que tipo de processo benificia mais a UML?
A UML independente de processo. Um processo

beneficia completamente a UML quando ele :
guiado por casos de uso;
centrado em arquitetura;
iterativo e incremental.
42
30/08/2011

Processo guiado por casos de uso

Casos de uso definidos para um sistema so base para o
processo de desenvolvimento inteiro.
Benefcios dos casos de uso:
Concisos, simples e de fcil entendimento por um
grande nmero de stakeholders.
Ajudam a sincronizar o contedo de diferentes
modelos.
Tirar extrato
Cliente
Sacar dinheiro

Um processo centrado na arquitetura

A arquitetura do sistema usada como artefato primrio
na concepo, construo, gerenciamento e para
envolver o sistema sob desenvolvimento..
Benefcios:
Controle intelectual sobre o projeto para gerenciar a
complexidade do projeto a fim de manter a integridade co
sistema.
Base efetiva para reso em larga escala.
Uma base para o gerenciamento do projeto.
Assistncia no desenvolvimento baseado em componentes.
43
30/08/2011

Um processo iterativo e incremental

Riscos crticos so resolvidos antes de realizar grandes
investimentos.
Iteraes iniciais habilitam um feedback de usurio
antecipado.
Testes e integrao so contnuos.
Foco em etapas objetivas a curto prazo.
O progresso mensurado atravs do fornecimento de
implementaes.
Implementaes parciais podem ser disponibilizadas.

Desenvolvimento Iterativo
Iterao 1
Iterao 2
Iterao 3
R
D
R
D
D
C
C
I
I
T
TEMPO
Iteraes mais recentes endeream os maiores riscos.

Cada iterao produz uma verso executvel, um
incremento adicional do sistema.
Cada iterao inclui integrao e teste.
44
30/08/2011

Reviso
O que a UML? Descreva cada um de seus

benefcios.
Quais caractersticas de processo melhor se
adapta UML? Descreva cada caracterstica.
O que uma iterao?

Dvidas?
45
30/08/2011

Orientado a Objetos
Modelagem por Casos de Uso
tuska@pucsp.br

Objetivos
Descrever o comportamento de um sistema e mostrar
como captur-lo em um modelo.
Demostrar como ler e interpretar:
um diagrama de casos de uso;
um diagrama de atividades.
46
30/08/2011

Onde estamos?
Conceitos na modelagem de casos de uso

Diagramas de caso de uso
Diagramas de atividade

O que comportamento do sistema?
Comportamento do sistema como o sistema age

e reage.
representado pelas aes e atividades de um sistema.
O comportamento do sistema capturado em

casos de uso.
Casos de uso descrevem as interaes entre sistema e
(partes do) ambiente.
47
30/08/2011

O que um modelo de casos de uso?

Um modelo descreve um requisito funcional do
sistema em termos de casos de uso.
Um modelo das necessidades pretendidas do sistema
(casos de uso) e seu ambiente (atores).
Ver boletim de
notas
Matricular em cursos
Estudante
Requerer
certificado

Quais so os benefcios de um modelo de casos de uso?
Comunicao
Identificao
Verificao
Comunicao
Usurio
final
Especialista no
domnio
Identificao
Caso de Uso
Verificao
Usurios
48
30/08/2011

Conceitos principais na modelagem de casos de uso

Um ator representa qualquer coisa
que interage com o sistema.
Ator
Um caso de uso descreve uma

seqncia de eventos, realizados pelo
sistema, que produzam resultados de
valor observveis a um ator em
particular.
Caso de Uso

Onde estamos?

49
30/08/2011

O que um ator?
Atores representam papis que os
usurios do sistema podem assumir.
Podem representar uma pessoa,
uma mquina ou outros sistemas.
Podem trocar informaes com o
sistema ativamente.
Podem ser fornecedores de
informao.
Podem ser receptores passivos de
informao.
Atores no fazem parte do sistema
Ator
Atores so EXTERNOS.

O que um caso de uso?

Define um conjunto de instncias de casos de uso onde
cada instncia uma seqncia de aes que o sistema
executa e que produz resultados de valor a um ator em
particular.
Um caso de uso modela um dialogo entre um ou mais atores
com o sistema.
Um caso de uso descreve as aes que o sistema realiza para
produzir algo de valor ao ator.
Caso de Uso
50
30/08/2011

Casos de Uso e Atores
Um caso de uso modela um dilogo entre atores e

o sistema.
Um caso de uso iniciado por um ator para
invocar uma determinada funcionalidade no
sistema.
Caso de Uso
Associao
Ator

Como voc l este diagrama?

Consulta Boletim
Catlogo de cursos
Mantm cadastro de
professor
Matricula-se em
cursos
Estudante
Mantm informaes
do estudante
Funcionrio
Seleciona cursos
para ministrar
Fecha matrcula
Professor
Publica notas
Sistema de Cobrana
51
30/08/2011

Onde estamos?


O que um diagrama de atividades?

Um diagrama de atividades em um modelo de casos de uso podem
ser usados para capturar as atividades e aes executadas em um
caso de uso.
em sua essncia um diagrama de fluxo evidenciando o controle
do fluxo entre as atividades.
Fluxo de Eventos
Este caso de uso inicia quando o Funcionrio requisitar que
o sistema feche a matrcula.
1. O sistema verifica se existe uma matrcula em
andamento. Se estiver, uma mensagem exibida ao
Funcionrio e o caso de uso termina. O fechamento do
processo de matrcula no pode ser fechado se houve
matrcula em andamento.
2. Para cada oferta de curso o sistema verifica se um
professor est designado a ministrar o curso oferecido e
pelo menos trs estudantes tenham sido matriculados. No
caso positivo, o sistema realiza a oferta de curso para cada
horrio dos cursos.
Atividade 2
Atividade 1
Atividade 3
52
30/08/2011

O que uma atividade?

Uma especificao do comportamento expresso como um fluxo de
execuo atravs de uma seqncia de unidades subordinadas.
Unidades subordinadas incluem atividades internas e resultantes de aes
individuais.
Pode conter expresses booleanas quando a atividade iniciada ou

finalizada.
Atividade 2
<<Pr-condio>>
Boolean restrio
Atividade 4
<<Ps-condio>>
Boolean restriot
Atividade 5

Exemplo:
Diagrama de Atividades
Deciso
Seleciona
Curso
Threads
Paralelos
[ apaga curso ]
Atividade/Ao
Apaga curso
[ adiciona curso ]
Synchronization
Bar (Fork)
Condio
de fluxo
Verifica
Calendrio
[ verificao ok ]
Matricular
no curso
Verifica
Pr-requisitos
[verificao falha]
Resolver
Conflitos
Barra de
sincronizao
(Join)
Transio
Atualizar
Calendrio
53
30/08/2011

Descrio textual de casos de uso
possvel tambm descrever um caso de uso

utilizando outros recursos que no diagramas de
atividades como por exemplo, por meio de textos
ao invs de diagramas.
O texto a seguir descreve um caso de uso sem a
utilizao de diagramas.

MN# 01 Publicar Notas
Ator Principal: Professor
Pr-Condies: O Professor deve estar alocado em algum curso em andamento.
Ps-Condies: As notas de uma determinada turma do professor estar com as notas de seus alunos lanadas.
FLUXO PRINCIPAL
ATOR
SISTEMA
1. Acessa a opo de publicar notas.

2. Solicita a turma.
3. Informa a turma.
4. Mostra tela com os nomes dos alunos com os
respectivos campos para digitao das notas.
5. Digita as notas dos alunos.
6. Registra e disponibiliza as notas dos alunos.
54
30/08/2011

FLUXO ALTERNATIVO
FA1
FLUXO DE ORIGEM: FP
FLUXO DE RETORNO: FP
ATOR
SISTEMA
4. Informa que a turma no existe
5. Solicita abertura de nova turma.

6. Solicita o nome da nova turma
7. Informa o nome.
8. Registra o nome da turma e continua no passo 4 do
Fluxo Principal.

FLUXO EXCEPCIONAL
FE1
FLUXO DE ORIGEM: FP
ATOR
FLUXO DE RETORNO: SISTEMA

4. Informa que a turma no existe
5. Cancela a operao.
OBSERVAO
Embora nestes slides os fluxos tenham sido colocados de forma separada para uma melhor
visualizao no formato de apresentao, estes podem ser contnuos em uma mesma tabela.
55
30/08/2011

Reviso
O que comportamento do sistema?

O que modelo de casos de uso?
Quais so os seus benefcios?
O que um ator? E um caso de uso?
O que um diagrama de atividades?

Exerccio
Dados:
Casos de uso, atores e associaes
Desenhe:
Um diagrama de casos de uso
Dados:
Aes, estados e atividades
Desenhe:
Um diagrama de atividades
56
30/08/2011

Fbio um construtor de casas para condomnios de alto padro em uma
cidade do interior de So Paulo. Em suas atividades profissionais ele
necessita realizar alguns controles de forma a garantir que seus projetos
sejam executados com qualidade.
Uma das principais necessidades de Fbio a de controlar a compra,
utilizao e estoque de materiais de construo. Muitas vezes materiais
acabam sendo comprados em duplicidade, uma vez que o chefe de obras
possui uma pequena verba para compras de materiais em situaes de
emergncia.
Outro controle que representa um fator crtico em suas atividades
controle de mo de obra. Os operrios devem ser cadastrados e
acompanhados em termos de horas trabalhadas a fim de realizar os
pagamentos no final da semana.
Fbio gostaria de criar um mapa de atividades das obras e de vincular os
operrios a cada uma das atividades a fim de permitir otimizaes no
processo.

Dvidas?
57
30/08/2011

Orientado a Objetos
Diagramas de Interao
tuska@pucsp.br

Objetivos
Descrever a dinmica comportamental e mostar

como captur-la em um modelo.
Demonstrar como ler e interpretar:
Um diagrama de seqncia
Um diagrama de comunicao
Explicar as similaridades e diferenas entre os

diagramas de comunicao e de seqncia.
58
30/08/2011

Objetos precisam colaborar
Objetos so inteis a no ser que possam

colaborar na soluo de problemas.
Cada objeto responsvel por seu comportamentoe
estado.
Nenhum objeto pode assumir toda a responsabilidade
sozinho.
Como os objetos interagem entre si?

Eles interagem por meio de mensagens.

Objetos interagem por meio de mensagens
Uma mensagem mostra como um objeto pede a

outro para que alguma atividade seja executada.
Mensagem
getOfertaCursos(semestre)
: Car buyer
:ControladorMatrcula
:SistemaCatalogoCurso
59
30/08/2011

O que um diagrama de interaes?
um termo genrico que se aplica a vrios

diagramas que enfatizam as interaes entre
objetos
Diagrama de Seqncia
Diagrama de Comunicao
Variantes Especializadas
Diagrama de Tempo
Diagrama Geral de Interao

Diagrama de Seqncia
Viso cronolgica das interaes
dos objetos.
Diagramas de
Seqncia
Diagrama de Comunicao
Viso estrutural das mensagens
dos objetos.
Diagramas de
Comunicao
60
30/08/2011

Diagrama de Tempo
Viso de restries de tempo das
mensagens envolvidas em uma
interao.
Diagramas de Tempo
Diagrama Geral de Interao

Viso de alto nvel dos conjuntos
de interao combinados em
seqncias lgicas.
Diagramas Gerais de
Interaes

Onde estamos?
Diagramas de Seqncia
Diagramas de Comunicao
Comparao dos diagramas de interao
61
30/08/2011

O que um diagrama de seqncia?

Um diagrama de seqncia um diagrama de interao
que enfatiza a ordem cronolgica de mensagens.
O diagrama exibe:
Os objetos que participam da interao.
A seqncia de mensagens trocadas.
Diagrama de
seqncia

Exemplo: Diagrama de seqncia

: Student
:RegisterForCoursesForm
:RegistrationController
:CourseCatalogSystem
: Course Catalog
1: create schedule( )
2: get course offerings( )
3: get course offerings(forSemester)
5: display course offerings( )
6: display blank schedule( )
ref
Select Offerings
62
30/08/2011

Elementos do Diagrama de Seqncia: Objetos

Objetos annimos
SWTSU Catalog :
CourseCatalogSystem
Objetos nomeados
Linhas
de vida

Elementos do Diagrama de Seqncia: Atores

: Student
SWTSU Catalog :
CourseCatalogSystem
: Course Catalog
Instncias de atores
63
30/08/2011

Elementos do Diagrama de Seqncia: Mensagens

: Student
SWTSU Catalog :
CourseCatalogSystem
: Course Catalog

3: get course offerings(for Semester)
Mensagem
Mensagens
Reflexivas

Elementos do Diagrama de Seqncia: Processo

: Student
SWTSU Catalog :
CourseCatalogSystem
: Course Catalog
Processo em
execuo
64
30/08/2011

Elementos do Diagrama de Seqncia: Ocorrncia de evento
: Student
SWTSU Catalog :
CourseCatalogSystem
: Course Catalog
Ocorrncia de
evento

Elementos do Diagrama de Seqncia: Ocorrncia de Interao
: Student
SWTSU Catalog :
CourseCatalogSystem
: Course Catalog

ref
Ocorrncia
de
interao
Select Offerings
65
30/08/2011

Onde estamos?

O que um diagrama de comunicao?

Um diagrama de comunicao enfatiza a organizao de objetos
em uma interao.
Um diagrama de comunicao mostra:
Os objetos que participam da interao.
Ligaes entre os objetos.
Mensagens passadas entre os objetos.
66
30/08/2011

Exemplo: Diagrama de Comunicao

: Course Catalog
: RegisterForCoursesForm
: Student

: RegistrationController
: CourseCatalogSystem

Elementos do Diagrama de Comunicao: Objetos

Objetos
SWTSU Catalog
67
30/08/2011

Elementos do Diagrama de Comunicao: Atores

: Course Catalog
: Student
Atores
SWTSU Catalog

Elementos do Diagrama de Comunicao:
Ligaes e mensagens
Mensagens

Ligaes
: Course Catalog
: Student

68
30/08/2011

Onde estamos?

Similaridades entre os diagramas de Seqncia e de
Comunicao
So semanticamente equivalentes
Podem ser convertidos de um para o outro sem perda
de informao
Modelam aspectos dinmicos de um sistema

Modelam o cenrio de um caso de uso
69
30/08/2011

Diferenas entre diagramas de Seqncia e de Comunicao
Exibem explicitamente a
seqncia de mensagens.
Exibem as ocorrncias de
execuo.
Melhores para a
visualizao geral do fluxo.
Melhores para
especificaes de temporeal e cenrios complexos.
Exibem relacionamentos,
alm das interaes.
Melhores para visualizao
de padres de comunicao.
Melhores para visualizao
de todos os efeitos de um
dado objeto.
Mais fceis de serem
utilizados em sesses de
brainstorming.

Resumo
Qual a proposta de um diagrama de interao?
O que um diagrama de seqncia? E um diagrama de comunicao?
O que um diagrama de tempo? E um diagrama geral de interao?
Quais so as similaridades entre os diagramas de seqncia e de
comunicao?
Quais so as diferenas entre os diagramas de seqncia e de
comunicao?
70
30/08/2011

Exerccio
Dado:
Um conjunto de objetos, suas
ligaes e mensagens.
Produzir:
Um diagrama de seqncia.
Um diagrama de mensagens.

Dvidas?
71
30/08/2011

Orientado a Objetos
Diagrama de Classes
tuska@pucsp.br

Objetivos
Descrever uma viso esttica do sistema e

mostrar como captur-la em um modelo.
Demonstrar como ler e interpretar um diagrama
de classes.
Modelar associaes e agregaes e mostrar
como incluir o modelo em um diagrama de
classes.
Modelar generalizaes em um diagrama de
classes.
72
30/08/2011

Onde Estamos?
Diagrama de Classes
Relacionamento de Classes
Associao
Agregao
Generalizao

O que um diagrama de classes?
Viso esttica de um sistema
CloseRegistrationForm
Schedule
CloseRegistrationController
- semester
+ open()
+ close registration()
Student
+ get tuition()
+ add schedule()
+ get schedule()
+ delete schedule()
+ has pre-requisites()
+ commit()
+ select alternate()
+ remove offering()
+ level()
+ cancel()
+ get cost()
+ delete()
+ submit()
+ save()
+ any conflicts?()
+ create with offerings()
+ update with new selections()
+ is registration open?()
+ close registration()
Professor
- name
- employeeID : UniqueId
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()
+ teachClass()
73
30/08/2011

Utilidade de um diagrama de classes
Ao modelar a viso esttica de um sistema, o

diagrama de classes tipicamente utilizado de
trs formas, para modelar:
o vocabulrio de um sistema,
colaboraes,
Esquema lgico de um banco de dados.

Exempo: Diagrama de Classes
Existe uma melhor forma de se organizar um

diagrama de classes?
RegistrationController
LoginForm
RegisterForCoursesForm
Schedule
Professor
Student
Course
CourseOffering
CourseCatalogSystem
BillingSystem
74
30/08/2011

Reviso: O que um pacote?
Um mecanismo genrico para organizao de

elementos em grupos.
Um elemento de modelo que pode conter outros
elementos de modelo..
Um pacote pode ser utilizado para:
Organizar um modelo sob
desenvolvimento;
Como unidade de gesto de configurao.
Artefatos da
Universidade

Exemplo: Pacote Registration
Registration
75
30/08/2011

Onde Estamos?
Diagrama de Classes
Associao
Agregao
Generalizao

O que uma associao?
Relacionamento semntico entre dois ou mais

classificadores que especifica conexes entre as
suas instncias.
Um relacionamento estrutural que especifica que
objetos de uma classe esto conectados aos da
outra classe.
Estudante
Calendrio
Curso
76
30/08/2011

Exemplo: Que associaes voc pode encontrar?

1: submit schedule( )
2: submit schedule( )
: Student
8: any conflicts?( )
3: save( )
4: submit( )
: Schedule
7: still open?( )
9: add student(Schedule)
6: has pre-requisites(CourseOffering)
: CourseOffering
: Student
5: is selected?( )
10: mark as enrolled in( )
: PrimaryScheduleOfferingInfo

O que multiplicidade?
Multiplicidade o nmero de instncias de uma classe qual se
relaciona com UMA instncia da outra classe.
Para cada associao, existem duas decises de multiplicidade a
serem tomadas, uma para cada extremidade da associao.
Para cada instncia de Professor, muitas ofertas de cursos podem existir.
Para cada instncia de oferta de curso, podem haver um ou nenhum
professor como instrutor.
Professor
- instrutor
0..1
Oferta de Curso
0..*
77
30/08/2011

Indicadores de Multiplicidade
No especificado
Exatamente um
Zero ou mais
0..*
Zero ou mais
Um ou mais
1..*
Zero ou um (valor opcional)
0..1
Faixa especfica
2..4
Mltiplas Faixas descontnuas
2, 4..6

Exemplo: Multiplicidade
1
0..1
0..1
Student
Schedule
0..*
0..*
CourseOffering
0..4
78
30/08/2011

Onde Estamos?
Diagrama de Classes
Associao
Agregao
Generalizao

O que uma agregao?
Uma forma especial de associao a qual modela

um relacionamento parte-de entre a agregao
(o todo) e suas partes.
Uma agregao um relacionamento parte-de. A
multiplicidade representada da mesma forma que em
outras associaes.
Todo
Parte
0..1
79
30/08/2011

Exemplo: Agregao
1
0..1
0..1
Student
Schedule
0..*
0..*
CourseOffering
0..4

Onde Estamos?
Diagrama de Classes
Associao
Agregao
Generalizao
80
30/08/2011

Reviso: O que Generalizao?
Um relacionamento entre classes onde uma

classe compartilha sua estrutura e/ou seu
comportamento de uma ou mais classes.
Define uma hierarquia de abstraes onde a
subclasse herda elementos de uma ou mais
superclasses.
Herana simples
Herana mltipla
um relacionamento -um.

Exemplo: Herana simples
Uma classe herda elementos de outra

Ancestral
Account
- balance
- name
- number
Superclasse
(pai)
+ withdraw()
+ createStatement()
Relacionamento
de
generalizao
Subclasse
(filha)
Savings
Checking
Descendentes
81
30/08/2011

Exemplo: Herana Mltipla
Uma classe pode ser herdeira de vrias outras

Voador
Animal
Herana Mltipla
Aviao
Helicoptero
Ave
Lobo
Cavalo
Utilize herana mltipla somente se for necessrio e

sempre com muita ateno!

Reviso
O que um diagrama de classes
representa?
Qual benefcio os pacotes propiciam
ao modelo?
Defina associao, agregao e
generalizao.
Como encontramos associaes?
O que multilicidade?
Quais informaes a multiplicidade
fornece ao modelador?
82
30/08/2011

Exerccio
Dado:
Um conjunto de classes e seus
relacionamentos
Desenhe:
Um diagrama de classes

Dvidas?
83
30/08/2011

Orientado a Objetos
Outros Diagramas da UML
tuska@pucsp.br

Objetivos
Demonstrar como ler e interpretar um:

Diagrama de mquina de estados
Diagrama de componentes
Diagrama de Implantao
84
30/08/2011

Onde Estamos?

Diagrama de implantao

Reviso: Um objeto possui estados

Estado a condio ou situao durante a vida de um objeto, a qual
satisfaz alguma condio, executa alguma atividade ou aguarda por
algum evento.
O estado de um objeto normalmente muda ao longo do tempo.
Nome: J Clark
ID: 567138
Contr: 07/25/1991
Estado: Titular
Disciplina: Finanas
Carga mx.: 3
Nome: J Clark
ID: 567138
Data Contratao: July 25, 1991
Estado: Titular
Disciplina: Finanas
Carga mxima: 3 classes
Professor Clark
85
30/08/2011

Exemplo: Professor
Existe uma seqncia de eventos entre um

instrutor se tornar um professor universitrio.
Professor assistente (ser efetivo atravs de um
nmero de publicaes de qualidade)
Professor Efetivo/Associado
Titular
(baseado na sua contribuio acadmica)

O que so diagramas de mquina de estados?

Um diagrama de mquina de modela o comportamento
dinmico.
Ele especifica a seqncia de estados nos quais um
objeto pode existir:
Os eventos e condies que levam o objeto a alcanar tais
estados
As aes acionadas quando tais estados so alcanados
Professor
assistente
Efetivo
86
30/08/2011

Estados especiais
O estado inicial o estado que o objeto se encontra
quando ele criado.
Um estado inicial obrigatrio
S pode haver um estado inicial.
O estado inicial representado por um crculo slido.
Um estado final indica o final do ciclo de vida de um

objeto.
Um estado final opcional.
Um estado final indicado por um crculo slido circuscrito
por um outro crculo vazado.
Pode haver mais de um estado final.
Applied

O que so eventos?
Um evento uma especificao de uma

ocorrncia significante que possui uma
localizao no tempo e no espao.
Um evento uma ocorrncia de um estmulo que pode
disparar uma transio de estado.
Exemplo:
Publicao com sucesso de um certo nmero de artigos
Professor
assistente
Evento
Efetivo
87
30/08/2011

O que so transies?
Uma transio a mudana de um estado original
para um estado sucessor como resultado de algum
estmulo.
O estado sucessor pode ser inclusive o prprio estado
original.
A transio pode ser a resposta a um evento.

Transies podem ser rotuladas com nomes de
eventos.
Professor
assistente
Efetivo
numArtigos
Transio
Nome do evento

Exemplo: Mquina de estados

Contratado
Exame
admissional
aceito
H
Professor
assistente
numArtigos
Efetivo
recusado
Titulao/maturidade
aposentadoria
Titular
H
retornar
tirarLicena
Estado de histrico
Afastado
88
30/08/2011

Onde Estamos?


O que um diagrama de componentes?
Um diagrama que mostra a organizao e

dependncias entre componentes
<<component>>
<<component>>
ComponenteA
ComponenteB
<<component>>
<<component>>
ComponenteC
ComponenteD
89
30/08/2011

O que um componente?
Parte modular de um sistema a qual esconde sua implementao
por trs de um conjunto de interfaces externas.
Parte de um sistema lgico ou fsico
Se adequa e fornece a realizao fsica de um conjunto de

interfaces.
Especifica a dependncia fsica para as interfaces que a requerem.
<<component>>
<<component>>
NomeDoComponente
Component Name
Nome da Interface
Nome requerido
da Interface

Onde Estamos?

90
30/08/2011

O que um diagrama de implantao?
Um diagrama de implantao mostra:

Configurao dos ns de processo em tempo de
execuo
Ligaes de comunicao entre os ns
Artefatos de implantao

O que um n?
Representa um recurso
computacional em tempo de
execuo
Normalmente possui a memria
mnima e capacidade de
processamento.
Tipos:
Dispositivo
Recurso computacional fsico com sua
capacidade de processamento.
<<device>>
Nome do dispositivo
<<device>>
Nome do
sub dispositivo
<<exe env>>
nome do
ambiente
Pode ser atachado.
Ambiente de execuo
Representa plataformas particulares de
execuo.
91
30/08/2011

O que um conector?
Um conector representa um:
Mecanismo de comunicao
Mdia fsica
Protocolo de software
<<client workstation>>
Kiosk
<<100-T Ethernet>>
Conector
<<application server>>
Server
Console
<<RS-232>>

Exemplo: Diagrama de Implantao

PC
<<Campus LAN>>
0..2000
1
1
<<Campus LAN>>
1
<<legacy RDBMS>>
Course Catalog
Registration Server
<<Campus LAN>>
1
1
<<legacy>>
Billing
System
92
30/08/2011

Exemplo: Diagrama de Implantao com processos

PC
StudentApplication
<<Campus LAN>>
0..2000
1
<<Campus LAN>>
1
Registration Server
CourseCatalogSystemAccess
CourseRegistrationProcess
BillingSstemAccess
<<legacy RDBMS>>
Course Catalog
<<Campus LAN>>
1
<<legacy>>
Billing
System

Reviso
Defina estado. Como voc
determina classes com estados
significantes?
O que um diagrama de mquina
de estados? Descreva as diferentes
partes do diagrama.
O que um diagrama de
componentes?
Qual a proposta do diagrama de
implantao?
93
30/08/2011

Dvidas?

Orientado a Objetos
Padres de Projeto
(Design Patterns)
tuska@pucsp.br
94
30/08/2011

Objetivos
Entender o que so Padres de Projeto

Conhecer alguns dos padres definidos pelo GoF
(Gang of Four por conta de serem quatro autores)
Categorias de Padres de Projeto
Apresentao de alguns padres de projeto
(Composite, Observer, Strategy, Factory, Mediator e Faade)

Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Factory Method
Padro: Mediator
Padro: Faade
95
30/08/2011

Categorias de Padres de Projeto?
da natureza do desenvolvimento de software o

fato de que os mesmos problemas tendem a
acontecer diversas vezes.
Padres de projeto so formas padronizadas para
atacar problemas conhecidos.
ver mais detalhers em
Design Patterns, Eric Gamma


No livro Design Patterns os autores catalogaram 23
padres de projeto. Estes padres foram divididos em 3
categorias: Criacionais, Estruturais e Comportamentais.
CRIACIONAIS
Procuram separar a operao de uma

aplicao de como os seus objetos so
criados.
ESTRUTURAIS
Provem generalidade para que a estrutura

da soluo possa ser estendida no futuro.
COMPORTAMENTAIS
Utilizam herana para distrituir o

comportamento entre subclasses, ou
agregao e composio para construir
comportamento complexo a partir de
componentes simples.
96
30/08/2011


Os padres definidos pelos autores do livro Design
Patterns so:
CRIACIONAIS
Abstract Factory; Builder; Factory Method;

Propotype; Singleton
ESTRUTURAIS
Adapter; Bridge; Composite; Decorator;

Faade; Flyweight; Proxy
COMPORTAMENTAIS
Chain of Responsibility; Command;

Interpreter; Iterator; Madiator; Memento;
Observer; State; Strategy; Template
Method; Visitor

Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Mediator
Padro: Faade
97
30/08/2011

Padro: Composite (Estrutural)
Se prope a definir uma relao hierrquica entre

objetos de tal forma que tanto o objeto todo
quanto os objetos parte sejam equivalentes em
certos aspectos.

Padro: Composite (Estrutural)
98
30/08/2011

Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Mediator
Padro: Faade

Padro: Observer (Comportamental)
Possui o objetivo de definir de forma flexvel uma

dependncia um para muitos entre objetos. Esta
dependncia no sentido de que, se houver
alguma modificao no estado do objeto central,
os objetos dependentes devem ser notificados. A
preocupao aqui com o acoplamento:
necessitamos que o objeto central seja capaz de
enviar mensagens de notificao sem, no entanto,
conhec-los diretamente.
99
30/08/2011

Padro: Observer (Comportamental)

Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Mediator
Padro: Faade
100
30/08/2011

Padro: Strategy (Comportamental)
Tem o objetivo de encapsular diferentes

algoritmos para realizao de alguma tarefa
computacional por trs de uma interface e
permitir que a regio de cdigo cliente dessa
tarefa possa utilizar qualquer desses algoritmos
sem precisar ser modificada.

Padro: Strategy (Comportamental)
101
30/08/2011

Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Mediator
Padro: Faade

Possui o objetivo de criar uma forma de instanciar

objetos sem que a regio do cdigo que realiza a
instanciao do objeto fique acoplada classe e
sua forma especfica de prover o servio
requerido. Este servio de instanciao, por
vezes, pode ser muito complexo.
102
30/08/2011


Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Mediator
Padro: Faade
103
30/08/2011

Padro: Mediator
Permite um grupo de objetos interagir com outro

grupo de objetos ao mesmo tempo que mantm
um acoplamento fraco. A soluo a criao de
um objeto mediador para encapsular interaes
transferindo as requisies de um grupo para o
outro. (exemplo: objetos Controller do MVC)

Padro: Mediator
104
30/08/2011

Onde Estamos?

Padro: Composite
Padro: Observer
Padro: Strategy
Padro: Mediator
Padro: Faade

Padro: Faade
Permite a definio de interfaces de comunicao

entre subsistemas deixando-os fracamente
acoplados. Define-se um uma interface de alto nvel
que torna o subsistema mais fcil de ser utilizado de
tal forma que um cliente s se comunique com este
subsistema atravs desta interface.
105
30/08/2011

Padro: Faade
X
Z
Y
<<interface>>
Faade

Dvidas?
106
30/08/2011

Orientado a Objetos
Parte 3 Anlise de Modelos de Software

tuska@pucsp.br

Anlise de Modelos de Software
Objetivos
Entender os vnculo entre os principais modelos

da UML em um contexto de um processo de
desenvolvimento de software.
Conhecer alguns dos principais erros de
modelagem em algumas das principais etapas no
processo de desenvolvimento de software.
Praticar a modelagem de software sob uma
perspectiva de qualidade e coerncia dos modelos
na linguagem UML.
107
30/08/2011

Onde estamos?
Vnculo entre Modelos
Problemas de Modelagem
Modelagem de Domnio
Modelagem de Casos de Uso
Reviso de Requisitos
Anlise de Robustez
Reviso Preliminar de Design
Elaborao dos Diagramas de Seqncia
Reviso Crtica de Design
Anlise de Modelos UML

Vnculo entre modelos UML

Para esta primeira anlise levaremos em conta apenas alguns dos diagramas UML
Diagramas de casos de uso representam o escopo de sistemas ou partes deste
escopo identificando metas ou necessidades dos seus atores.
Diagramas de classes representam vises estruturais do sistema e especificam as
classes de objetos com os quais o sistema ir operar.
Diagramas de interao representam funcionalidades internas de possveis
interaes no sistema em termos de trocas de mensagens entre os objetos da
aplicao de forma a dar conta de uma interao do sistema.
Diagramas de atividades podem ser utilizados para representar a lgica da
seqncia de passos para se resolver uma determinada interao existente no
sistema.
108
30/08/2011

Casos de Uso
Para cada caso de uso pode haver um conjunto de alguns artefatos
relevantes:
descrio do caso de uso;
especificao do caso de uso;
diagrama de atividades;
esboos de tela.
Caso de Uso
Pargrafo explicando o que faz o caso de uso.
Normalmente utilizamos este pargrafo nas
primeiras rodadas de levantamento de requisitos
antes de realizar uma especificao formal.
MN#01 Caso de Uso

Ator Principal: Ator
Pr-condies:
Ps-Condies:
ATOR
SISTEMA
1. Primeira ao
Ator
Caso de Uso
2. Primeira resposta
3. Segunda ao
4. Segunda resposta
5. Terceira ao
6. Terceira resposta
7. Ao
ATOR
SISTEMA
3. Segunda ao
4. Segunda resposta
5. Terceira ao
6. Terceira resposta
7. Ao

Casos de Uso
Estes artefatos devem manter um alto grau de coerncia entre eles.
Cada um possui um objetivo especfico mas esto contribuindo para
o modelo da mesma interao do usurio com o sistema.
109
30/08/2011

Modelo de Domnio
O modelo de domnio representa os conceitos envolvidos no projeto
de desenvolvimento do software no que diz respeito ao domnio da
aplicao. Estes conceitos so identificados a partir dos artefatos
que detalham os casos de uso. Os termos importantes so
identificados e representados em um diagrama de classes, que neste
momento ainda no apresentar detalhes como os mtodos e
atributos das classes.

Modelo de Domnio X Diagramas de Interao

As classes do modelo de domnio representam timas referncias de
como distribuir os objetos no momento de se elaborar os diagramas
de Interaes (Diagrama de Seqncia de Mensagens e o Diagrama
de Comunicao).
110
30/08/2011

Modelo de Domnio X Diagramas de Interao

Aps a elaborao dos modelos de Interao, ser possvel refinar o
modelo de classes registrando atributos e mtodos identificados
nesta etapa.
Refinamento

Onde estamos?
Modelagem de Domnio
Anlise de Robustez
111
30/08/2011

Uma srie de problemas de modelagem foram
levantadas e podem ser estudadas com maior
profundidade no livro:
Applying Use Case Driven Object Modeling with
UML
dos autores Doug Rosemberg e Kendall Scott.

Onde estamos?
Modelagem de Domnio
Modelagem de Casos de so
Anlise de Robustez
112
30/08/2011

10 principais erros na Modelagem do Domnio
1. Iniciar descrevendo as multiplicidades para associaes logo no
comeo. Ter certeza de que toda associao possui uma
multiplicidade.
2. Realizar anlise de substantivos e verbos exaustivamente por
todos os documentos de levantamento.
3. Associar operaes classes sem explorar os diagramas de
seqncia e de casos de uso.
4. Otimizar o seu cdigo para reuso antes de ter certeza de estar
satisfeito com os requisitos do sistema.
5. Debater a respeito de agregao, associao ou composio para
cada associao do modelo.

10 principais erros na Modelagem do Domnio
6. Presumir uma implementao especfica sem modelar o
contexto do problema.
7. Utilizar nomes de difcil entendimento como cGerPortIntf ao
invs de nomes intuitivos e bvios como Gerenciador de
Portiflio.
8. Pular diretamente para construes de implementao como
acessibilidade dos relacionamentos e classes parametrizadas.
9. Criar um relacionamento de um para um entre classes e as
tabelas de um banco de dados relacional.
10. Realizar uma padronizao precoce a qual envolve solues
legais as quais possuem pouca ou nenhuma conexo com os
problemas do usurio.
113
30/08/2011

Onde estamos?
Modelagem de Domnio
Anlise de Robustez

10 principais erros na Modelagem de Casos de Uso

1. Escrever requisitos funcionais ao invs de um cenrio
textual.
2. Descrever atributos e mtodos ao invs de suas
utilidades.
3. Escrever casos de uso muito sucintos.
4. Desvincular totalmente a interface com o usurio.
5. Descartar nomes explcitos para objetos de fronteira.
114
30/08/2011

10 principais erros na Modelagem de Casos de Uso

6. Escrever utilizando a perspectiva diferente da do
usurio na voz passiva.
7. Descrever somente interaes de usurio; ignorando as
respostas do sistema.
8. Omitir texto para aes de fluxos alternativos.
9. Foco em algo diferente do que est dentro do caso de
uso, assim como como voc chega quela situao ou o
que ocorre depois dela.
10. Perder um ms decidindo quando utilizar includes ou
extends.

Onde estamos?
Modelagem de Domnio
Anlise de Robustez
115
30/08/2011

10 principais erros na Reviso de Requisitos

1. No revisar requisitos. Ao invs disto deixar que os
programadores construam o que quiserem.
2. No ter certeza de que o texto do caso de uso se
encaixa com o comportamento desejado do sistema.
3. No utilizar nenhum tipo de prottipo de tela a fim de
validar o comportamento do sistema.
4. Manter seus casos de uso em um grau to alto de
abstrao que seus clientes (no tecnicos) no possuem
nem uma pista do que o caso de uso trata.
5. No garantir que o modelo de domnio realmente
reflete objetos do mundo real.

10 principais erros na Reviso de Requisitos

6. No ter certeza de que o texto do caso de uso
referencia a objetos do domnio.
7. No questionar casos de uso sem fluxo alternativo
algum.
8. No questionar cada ao do fluxo principal dos casos
de uso a respeito de possveis fluxos alternativos.
9. No se preocupar se os casos de uso esto escritos na
voz passiva.
10. No se preocupar se um caso de uso possui 4 pginas
de comprimento.
116
30/08/2011

Onde estamos?
Modelagem de Domnio
Anlise de Robustez

4 regras dos Diagramas de Robustez

1. Atores s podem falar com objetos de fronteira
2. Objetos de fronteira s falam com controles e
atores.
3. Objetos de entidade s falam com controles.
4. Controles podem falar com objetos de fronteira,
objetos de entidade e outros controles mas
nunca com atores
D. Rosenberg, Use Case DrivenObjectModelingwithUML: A PracticalApproach
117
30/08/2011

10 principais erros na Anlise de Robustez

1. Violar uma ou mais regras do diagrama de robustez.
2. No utilizar anlise de robustez para auxiliar o uso de
um formato consistente dos textos do caso de uso.
3. No incluir fluxos alternativos nos diagramas de
robustez.
4. No utilizar anlise de robustez para garantir
consistncia entre os nomes de classe do diagrama de
classes e no texto dos casos de uso.
5. Alocar comportamentos a classes nos diagramas de
robustez.

10 principais erros na Anlise de Robustez

6. Incluir muito poucos ou controladores demais.
7. Gastar muito tempo tentando deixar o diagrama
de robustez perfeito.
8. Tentar realizar um desenvolvimento detalhado
nos diagramas de robustez.
9. No realizar simulaes visuais entre o texto
caso de uso e o diagrama de robustez.
10. No atualizar o seu modelo esttico.
118
30/08/2011

Onde estamos?
Modelagem de Domnio
Anlise de Robustez

10 principais erros na Reviso Preliminar de Design

1. No garantir que os clientes sabem que esta a ltima
chance de alterar o comportamento antes que uma
verso do sistema seja construda.
2. No garantir que os textos dos casos de uso e os
diagramas de robustez estejam em conformidade.
3. No garantir que um novo objeto de entidade foram
adicionados ao modelo de domnio.
4. No procurar por atributos nas classes de domnio.
5. Esperar que operaes sejam alocadas s classes
durante a reviso preliminar do design.
119
30/08/2011

10 principais erros na Reviso Preliminar de Design
6. No advertir seus clientes (novamente) que os textos dos casos
de uso representam um contrato entre os desenvolvedores e os
clientes.
7. Desejar que a desenho esttico preliminar realize um uso
extensivo de padres de projeto.
8. No revisar as regras dos diagramas de robustez.
9. Esperar que os diagramas de robustez mostrem um projeto
completo e detalhado e no um projeto conceitual.
10. Revisar a direo de cada seta em um diagrama de robustez
cuidadosamente ao invs de realizar uma rpida ligao para
verificar se foi levado em conta todo o comportamento
necessrio.

Onde estamos?
Modelagem de Domnio
Anlise de Robustez
120
30/08/2011

1.
2.
3.
4.
5.
10 principais erros na elaborao dos

No realizar um diagrama de seqncia para cada caso
de uso.
No colocar o texto do caso de uso no diagrama de
seqncia.
No identificar todos os objetos necessrios primeiro,
em um diagrama de robustez.
No realizar uma conferncia visual entre o texto do
caso de uso e as setas de mensagem.
No mostrar os meandros; ao invs disso, manter os
diagramas de seqncia em um alto grau de abstrao.

10 principais erros na elaborao dos
6. Transformar o seu diagrama de seqncia em um fluxograma ao
invs de utiliz-lo para alocar comportamento aos objetos.
7. No focar em mtodos interessantes (comportamento real do
software), como os mtodos gets e sets.
8. No pensar cuidadosamente a respeito das origens da mensagem
(qual o objeto que est no controle).
9. No acompanhar os princpios bsicos de orientao a
responsabilidade quando estiver alocando comportamentos ao
definir setas de mensagens.
10. No atualizar o modelo esttico durante a construo do
diagrama de classes para cada pacote de casos de uso.
121
30/08/2011

Onde estamos?
Modelagem de Domnio
Anlise de Robustez

Quatro critrios bsicos de uma boa classe

(Halbert e OBrien)
1. Reusabilidade: Quanto mais genricos forem os
objetos e classes, maior a probabilidade de reuso.
2. Aplicabilidade: Coerncia das classes com seus
respectivos mtodos.
3. Complexidade: Diz respeito a facilidade de construo
das classes de acordo com a alocao dos mtodos.
4. Conhecimento para implementao: Quanto da
implementao do comportamento da classe depende
de detalhes internos aos mtodos associados.
122
30/08/2011

Critrios gerais dos relacionamentos de classes
1. Acoplamento: medida da fora das conexes entre classes
2. Coeso: medida a fora da conexo entre os atributos e os
mtodos de uma classe.
3. Suficiencia: condio em que uma classe encapsula abstraes
suficientes para oferecer algo eficiente e significativo.
4. Completude: condio em que uma dada interface de uma
classe captura todas as abstraes relevantes.
5. Primitividade: condio em que a operao pode ser
eficientemente construda atravs da colaborao entre classes
de forma construtiva.

10 principais erros na Reviso Crtica de Design

1. Convidar clientes sem o perfil tcnico para a reviso de
projeto.
2. No verificar os textos dos casos de uso
cuidadosamente relacionando-os com o conjunto de
diagramas de seqncia.
3. No verificar a origem e o destino de cada mensagem
em cada diagrama de seqncia cuidadosamente.
4. No pensar atravs dos critrios de Halbert/OBrien ao
revisar os diagramas de seqncia.
5. No revisar os modelos estticos por critrios de
qualidade de classes.
123
30/08/2011

10 principais erros na Reviso Crtica de Design
6. No se preocupar a respeito de descrever os meandros do
software; deixar que isto ocorra naturalmente ao longo do
projeto.
7. No considerar utilidade da utilizao de padres de projeto no
projeto.
8. Mostrar diagramas de seqncia genricos os quais
desconsideram a implementao de tecnologias como DCOM
ou EJBs.
9. No revisar os diagramas de seqncia para cada cenrio
presente na atual verso do software.
10. No se preocupar a respeito de detalhes do projeto antes de
iniciar a codificao. Assumindo ento que a reengenharia a
partir do cdigo ir consertar tudo posteriormente.

Onde estamos?
Modelagem de Domnio
Anlise de Robustez
124
30/08/2011

Exerccio de anlise de modelagem

Modele um sistema simples de desenho de retas na
tela. Um desenhista clica sobre uma tela
identificando pontos e a cada 2 ponto identificado
o software deve criar uma reta interligando as duas
posies definidas pelo usurio. O software no
prev uma condio de trmino.

Exerccio de anlise de modelagem

Troque o seu modelo com um colega da turma e
avalie os relacionamento entre os modelos
apresentados.
Devolva o modelo ao seu colega juntamente com os
seus comentrios.
125
30/08/2011

Resumo
Qual a relao entre um caso de uso e um
diagrama de atividades?
Por que no desejado incluir mtodos e
atributos antes do desenho dos diagramas
de interao?
Qual o objetivo geral deste conjunto de
diagramas?
O que representa o diagrama de classes
neste contexto?
Estas etapas de desenvolvimento so
determinadas pela UML?

Dvidas?
126
30/08/2011

Orientado a Objetos

tuska@pucsp.br

Objetivos
Exercitar a elaborao de modelos de software

explorando caractersticas sintticas e semnticas
nos diagramas da UML.
Interpretar modelos diagramados com a UML.
Destacar erros de sintaxe e de semntica em
diagramas UML mais especificamente em
diagramas de casos de uso e diagramas de
127
30/08/2011

Onde estamos?
Exerccio 1 Jogo da Velha

Alguns Erros de Diagramao
Restries de Relacionamentos
Exerccio 2 Forum de Notcias
Exerccio 3 Jogo Sudoku

Jogo da Velha
O objetivo deste exerccio realizar a modelagem

de um software por meio da UML de forma a
implementar o mundialmente conhecido Jogo da
Velha.
128
30/08/2011

Jogo da Velha
Diagrama de casos de uso

Jogo da Velha
Descrio de casos de uso

MN#: Iniciar novo jogo
Ator: Jogador
Pr-Condies: nenhuma
Ps-condies: jogo iniciado
FLUXO PRINCIPAL
1 O jogador solicita iniciar o jogo
2 O sistema apresenta um tablado sem
nenhuma marca para o incio do jogo
129
30/08/2011

Jogo da Velha

MN#: Realizar jogada
Ator: Jogador
Pr-Condies: jogo iniciado
Ps-condies: jogada realizada
FLUXO PRINCIPAL
1 O jogador seleciona uma posio do tablado
2 O sistema verifica se a posio est livre
3 Caso a posio esteja livre a marca do
jogador (O ou X) ser colocada na posio
solicitada.
4 O sistema verifica se o jogo terminou.
5 Se no terminou, o sistema alterna a vez do
jogador.

Jogo da Velha

FLUXO ALTERNATIVO 1
3 O sistema solicita outra posio ao jogador e
o processo volta ao passo 1 do fluxo
principal.
FLUXO ALTERNATIVO 2
4 Se algum jogador alinhou 3 marcas ou no
existirem mais posies livres o sistema
informa o final do jogo.
130
30/08/2011

Jogo da Velha
Modelo Conceitual

Jogo da Velha
Diagrama de Robustez
131
30/08/2011

Jogo da Velha

Jogo da Velha
132
30/08/2011

Jogo da Velha Diagrama de Seqncia de Mensagens

Onde estamos?

Alguns erros de Diagramao
133
30/08/2011

Erro de sincronismo de processos em diagramas de

seqncia de mensagens
T:Tela
Qual o erro presente no diagrama ao lado?
joo:Desenhista
marcar()


T:Tela
joo:Desenhista
marcar()
O processo marcar() iniciado por outro

processo e deve estar aninhado em relao a
ele. Note que neste diagrama o processo
marcar() termina depois do processo que o
chamou.
134
30/08/2011


T:Tela
Como resolver o problema?
joo:Desenhista
marcar()


T:Tela
joo:Desenhista
marcar()
1) Se o processo marcar() necessariamente

deve finalizar aps a finalizao do
processo que o chamou, isto significa que
a chamada deveria ser assncrona!
135
30/08/2011


T:Tela
joo:Desenhista
2) Normalmente o problema est em

definir realmente que o processo marcar()
deve terminar antes do processo que o
chamou. Portanto devemos prolongar o
tempo de execuo do processo que
emitiu a mensagem at que todas as
mensagens que ele chamou tenham
finalizado.
marcar()

Erro na especificao de loops ou blocos restritivos
T:Tela
joo:Desenhista
Loop
marcar()
136
30/08/2011

T:Tela
joo:Desenhista
Loop
Note que o bloco restritivo inicia no meio

de um processo que encerrado dentro do
prprio bloco. Um processo no pode
finalizar vrias vezes!
marcar()

T:Tela
joo:Desenhista
Loop
marcar()
137
30/08/2011

T:Tela
joo:Desenhista
Loop
Devemos garantir que o incio e o trmino

do bloco de restrio ou estejam
inteiramente dentro de um processo ou os
processos estejam inteiramente dentro do
bloco.
marcar()

T:Tela
joo:Desenhista
Loop
marcar()
Devemos garantir que o incio e o trmino

do bloco de restrio ou estejam
inteiramente dentro de um processo ou os
processos estejam inteiramente dentro do
bloco.
138
30/08/2011

Erro no retorno de mensagens
T:Tela
T:TracaCirculo
joo:Desenhista
marcar()
Qual o erro presente no diagrama

ao lado?
tracar()
ok

T:Tela
joo:Desenhista
marcar()
tracar()
ok
T:TracaCirculo
Qual o erro presente no diagrama

ao lado?
O retorno do processo enviado a
outro objeto que no o que enviou
a mensagem.
139
30/08/2011

T:Tela
T:TracaCirculo
joo:Desenhista
marcar()
tracar()
ok
ok
O retorno remete a resposta para o

objeto que o chamou e este objeto
retransmite a mensagem.

T:Tela
T:TracaCirculo
joo:Desenhista
marcar()
tracar()
ok
Outra forma ao invs de enviar a

resposta atravs do retorno, envie
uma nova mensagem.
140
30/08/2011

Onde estamos?


Semntica em relacionamento de classes
Classe1
Classe2
Associao
Classe1
Classe2
Agregao
Classe1
Classe2
Composio
Classe1
Classe2
Generalizao
141
30/08/2011

Estudante
Secretaria
Associao
As classes vinculadas por uma associao podem trocar

mensagens.
Exemplo:
Estudante fala com a Secretria

Meias
Gaveta
Agregao
Um relacionamento de agregao indica que objetos de

uma determinada classe possui objetos de outra classe.
Exemplo:
Gaveta possui Meias
142
30/08/2011

Assento
Cadeira
Composio
Um relacionamento de composio indica que o objetos de

uma determinada classe so partes de objetos de uma outra
classe.
Exemplo:
Assento parte de uma Cadeira

Passaro
Animal
Generalizao
Um relacionamento de generalizao indica uma relao de

herana entre classes e especifica que o objetos de uma
determinada classe so objetos de uma outra classe.
Exemplo:
Pssaro um Animal
143
30/08/2011

Restries em relacionamentos
Alm de especificar os relacionamentos, ns

podemos especificar restries em relacionamentos.
Repare as afirmaes:
Uma gaveta pode conter meias
Um menino pode ser mordido por cachorros
Como podemos modelar estas afirmaes?
Imaginaremos que o relacionamento entre gaveta e
meia seria guardar e de menino com cachorro
seria morder.

guarda
Meias
0..*
mordida
Gaveta
Cachorro 0..*
Menino
Se as multiplicidades dos relacionamentos em ambos os casos

forem 5, quantas meias eu estaria referenciando? E quantos
cachorros?
Os modelos se diferenciam pois no caso das meias estamos
querendo modelar cardinalidadeque referencia diretamente ao
nmero de meias guardadas e no caso dos cachorros
multiplicidade o que referencia o nmero de mordidas e no de
cachorros.
144
30/08/2011

guarda
Meias
mordida
Gaveta
Cachorro 5
Menino
No caso das meias, o nmero de meias o prprio nmero de

relacionamentos, no caso do cachorro, o nmero de cachorros
pode ser menor ou igual ao nmero de relacionamentos
(mordidas).
As restries de relacionamento que podemos utilizar para
expressar estes tipos de relacionamento so: SET e BAG.

Meias
guarda
{set}
Gaveta
Cachorro 5
mordida
{bag}
Menino
SET: Indica conjunto e portanto no admite mais de um

relacionamento com um mesmo objeto.
BAG: Indica irrestrio, isto , nada se diz a respeito do nmero
de objetos. possvel que todas as mordidas tenham sido
provenientes de um mesmo cachorro.
145
30/08/2011

Onde estamos?

Restries em Relacionamentos

Forum de Notcias
Elabore um frum de notcias de forma que seja

possvel um usurio cadastrar questes, consultar as
questes, responder questes e consultar respostas.
146
30/08/2011

Onde estamos?

Jogo Sudoku
O jogo Sudoku trata-se de uma matriz 9X9 em que alguns
nmeros so dispostos como um enunciado.
O jogador deve posicionar nmeros de 1 a 9 nesta matriz
de forma que em nenhuma linha, coluna ou quadrantes
da matriz sejam alocados numeros repetidos.
Um quadrante uma parte da matriz geral e possui as
dimenses 3X3. Existem 9 quadrantes no sobrepostos
nesta matriz.
147
30/08/2011

Jogo Sudoku
Coluna
Quadrante
Casa
Linha

Dvidas?
148
30/08/2011

Orientado a Objetos

tuska@pucsp.br

Objetivos
Exercitar a elaborao de modelos de software

explorando caractersticas sintticas e semnticas
nos diagramas da UML.
Interpretar modelos diagramados com a UML.
Destacar erros de sintaxe e de semntica em
diagramas UML mais especificamente em
diagramas de casos de uso e diagramas de
149
30/08/2011

Frum de Discusses
O sistema Frum de Notcias permite que questes sejam
postadas e permite que vrias respostas sejam anexadas a
cada questo. O diagrama acima identifica os casos de uso
previstos para o software.
Qualquer usurio assume o mesmo papel ao utilizar o
sistema por tanto todas as funcionalidades estaro
disponveis para qualquer usurio do sistema.
Como se trata de um sistema cujo foco a modelagem e
no efetivamente sua usabilidade, foram descartados
aspectos importantes como persistncia (armazenamento
em disco) das informaes entre outras tantas possveis
funcionalidades aderentes ao projeto.

Jogo da Velha

Cadastrar questes
Este caso de uso representa a
necessidade de um usurio publicar
uma questo de seu interesse para
compartilhar com outros usurios e
futuramente, poder consultar suas
respostas. Cada questo colocada
de forma independente sem
qualquer tipo de classificao ou
conferncia.
150
30/08/2011

Jogo da Velha

Consultar questes
Um usurio pode percorrer a lista
de questes a fim de verificar temas
de interesse de outros usurios e at
verificar se alguma questo de seu
interesse tanto na leitura das
respostas como at, eventualmente,
contribuir com sua resposta no
futuro.

Jogo da Velha

Responder questes
Um usurio pode registrar sua
opinio a respeito de temas
levantados por outros usurios do
Frum de Notcias. A sua resposta
anexada questo e
disponibilizada para qualquer outro
usurio.
151
30/08/2011

Jogo da Velha

Consultar respostas
O usurio pode se interessar em ler
as respostas de questes postadas
ou no por ele. Caso tenha
interesse, ele poder navegar pelas
questes do Frum e consultar as
vrias possveis respostas anexadas
a cada questo.

Frum de Discusses
MN#01 Caso de Uso Cadastrar Questes
Ator Principal: Usurio
Pr-condies Nenhuma
Ps-Condies: Questo Cadastrada
1. Seleciona a opo de cadastrar uma nova
questo.
2. Exibe uma tela para a redao da nova
questo com os campos: nome do usurio e
questo. A data e a hora sero armazenadas
automaticamente juntamente com os dados de
entrada do usurio.
3. Digita as informaes da tela e submete a
questo para o Frum de Discusso.
4. Acrescenta a questo do usurio no sistema.
152
30/08/2011

Frum de Discusses
Diagrama de Robustez para o caso de uso Cadastrar Questes

Frum de Discusses
Diagrama de Seqncia para o caso de uso Cadastrar Questes
153
30/08/2011

Frum de Discusses
MN#02 Caso de Uso Consultar Questes
Pr-condies Nenhuma
Ps-Condies: Questes consultadas
1. Seleciona a opo de consultar questes.
2. Exibe uma tela com a lista de todas as
questes j cadastradas no sistema.
3. Consulta as questes cadastradas e depois
solicita a volta ao menu principal.
4. Fecha a tela de consulta.

Frum de Discusses
Diagrama de Robustez para o caso de uso Consultar Questes
154
30/08/2011

Frum de Discusses
Diagrama de Seqncia para o caso de uso Consultar Questes

Frum de Discusses
MN#03 Caso de Uso Responder Questo
Pr-condies: Questo cadastrada
Ps-Condies: Questo com resposta anexada
1. Seleciona a opo de responder uma questo.
2. Exibe uma tela com todas as questes para que o
usurio escolha a questo a ser respondida.
3. Escolhe uma das questes apresentadas na tela.
4. Apresenta uma tela com a pergunta escolhida e um
espao para que o usurio preencha seu nome e
resposta para a questo.
5. Preenche seu nome e a resposta questo.
6. Registra o nome, a resposta, a data e a hora do
sistema e anexa questo.
155
30/08/2011

Frum de Discusses
Diagrama de Robustez para o caso de uso Responder Questes

Frum de Discusses
Diagrama de Robustez para o caso de uso Responder Questes
156
30/08/2011

Frum de Discusses
MN#04 Caso de Uso Consultar Respostas das Questes
Pr-condies: Questo cadastrada
Ps-Condies: Respostas da questo consultadas
1. Seleciona a opo de consultar respostas de uma
questo.
2. Exibe uma tela com todas as questes para que o
usurio escolha a questo para a consulta de suas
respostas.
3. Escolhe uma das questes apresentadas na tela.
4. Apresenta uma tela com a pergunta escolhida e todas
as respostas associadas esta questo.
5. Consulta as respostas associadas questo e depois
solicita a volta ao menu principal.
6. Fecha a tela de consulta de respostas.

Frum de Discusses
Diagrama de Robustez para o caso de uso Consultar Respostas das Questes
157
30/08/2011

Frum de Discusses
Diagrama de Seqncia para o caso de uso Consultar Respostas das Questes

Frum de Discusses
Refinamento do diagrama de classes

Caso de Uso Cadastrar Questo
158
30/08/2011

Dvidas?
159

Modelagem de Software (TUSKA)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Modelagem de Software (TUSKA)

Hochgeladen von

Copyright:

Verfügbare Formate

30/08/2011

PONTIFCIA UNIVERSIDADE CATLICA DE SO PAULO

Prof. Dr. Maurcio Nacib Pontuschka

Prof. Maurcio Nacib Pontuschka

ERIC FREEMAN, ELISABETH FREEMAN, Use a

GRANDY BOOCH, IVAR JACOBSON,

BRUCE F. WESTER "Pitfalls of Object-Oriented

PONTIFCIA UNIVERSIDADE CATLICA DE SO PAULO

Modelagem de Software Orientada a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Vantagens da Tecnologia de Objetos

Modelagem de Software Orientado a Objetos

Marcos da Tecnologia de Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Sistemas em tempo real

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

UML Resource Center

Modelagem de Software Orientado a Objetos

PONTIFCIA UNIVERSIDADE CATLICA DE SO PAULO

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Por que modelar?

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Muitas equipes de desenvolvimento

Modelagem de Software Orientado a Objetos

Por que modelar?

Modelagem de Software Orientado a Objetos

Model Driven Architecture (MDA)

Modelagem de Software Orientado a Objetos

Pontos de viso do MDA

PIM Platform Independent Model

PSM Platform Specific Model

Modelagem de Software Orientado a Objetos

Quatro princpios da modelagem visual

Modelagem de Software Orientado a Objetos

Principio 1: A escolha do modelo importante

Modelagem de Software Orientado a Objetos

Principio 2: Nveis de preciso podem ser diferenciados

Modelagem de Software Orientado a Objetos

Principio 3: Os melhores modelos esto ligados realidade

Modelagem de Software Orientado a Objetos

Principio 4: Nenhum modelo nico suficiente

Viso de Casos de Uso

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Informalmente, um objeto representa uma entidade

Modelagem de Software Orientado a Objetos

Em uma definio mais formal:

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Comportamento do Professor Clark

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos