Aula 14 Projeto de Software OO

Prévia do material em texto

Projeto de Software 
Orientado a Objetos
Marcos Dósea
dosea@ufs.br
Atualizado por:
Breno Santos
breno.itatechjr@gmail.com
Agenda
• Introdução.
• Projetar Caso de Uso.
• Projetar Subsistemas.
• Projetar Classes.
Introdução
• Onde estamos?
Introdução
• Análise x Projeto:
Análise Projeto
Foco no problema. Foco na solução.
Comportamento caixa
preta.
Detalha operações e
atributos dos objetos.
Estrutura geral da
arquitetura do sistema.
Representação próxima
do código.
Requisitos Funcionais.
Requisitos Funcionais e
Não Funcionais.
Modelo simples. Modelo complexo.
Introdução
• O que faremos?
– Projetar o Software.
Fluxo de Análise e Projeto
Analisar 
caso de usoProjetista
Projetista de 
banco de 
dados
Revisar 
projeto
Projetar 
caso de uso
Arquiteto
Revisor do 
projeto
Projetar 
base de 
dados
Projetar 
arquitetura
Projetar 
subsistema
Projetar 
classes
Projetar Caso de Uso
• Refinar as realizações de casos de uso
substituindo os elementos de análise
(elaboradas na análise de casos de uso)
por elementos de projeto definido no
mapeamento do projeto da arquitetura.
• Incorporar persistência nas realizações.
• O modelo final serve de referência para
a implementação do caso de uso.
Projetar Caso de Uso
1) Refinar as realizações de casos de uso.
2) Simplificar os diagramas de interação.
1) Refinar as Realizações de Caso
de Uso
• Substitui as classes de projeto e/ou
interfaces dos subsistemas associados,
seguindo as recomendações da
arquitetura.
• Incorporar a persistência.
• Atualizar os diagramas que realizam o
caso de uso:
– Diagramas de Interação.
– Diagramas de Classes.
1) Refinar as Realizações de Caso
de Uso
• Como era na análise?
 : Balconista
 : TelaDevolverLivro
<<boundary>>
 : ControladorDevolucao
<<control>>
 : Emprestimo
<<entity>>
 : CadastroEmprestimos
<<entity collection>>
1 : devolverLivro()
2
<<create>>
3
4 : devolverLivro()
5 : buscar()
6
7 : calculaMultaPorAtraso()
8 : atualizar()
9
10
11 : resultado()
1) Refinar as Realizações de Caso
de Uso
• Como era na análise?
1) Refinar as Realizações de Caso
de Uso
• Como ficou no projeto?
– Para projetar as classes, deve-se obedecer
as regras de mapeamento entre classes de
análise e classe de projeto definidas pelo
arquiteto.
– Para cada diagrama de interação de análise,
deve ser criado um diagrama de interação
com as classes de projeto.
– É recomendado também criar o diagrama de
classes de projeto que realizam o caso de
uso.
Lembrando a Arquitetura…
GUI
Negocio
Dados
ITela
TelaDevolverLivro
+processa()
Fachada
IControladorLivro
IFachada
ControladorLivro ControladorAluno
IControladorAluno
IRepositorioEmprestimo
RepositorioEmprestimoBDR
+getInstance()
1) Refinar as Realizações de Caso
de Uso
• Como ficou no projeto?
1) Refinar as Realizações de Caso
de Uso
• Como ficou no projeto?
2) Simplificar os diagramas de
interação
• Identifique subfluxos comuns nos diagramas
de interação e encapsule-os em subsistemas
(possivelmente novos).
• Substitua os elementos internos pela
interface dos subsistemas (nos diagramas).
• Interações internas ao subsistema serão
descritas na atividade "Projetar subsistema".
2) Simplificar os diagramas de
interação
• Quando encapsular fluxos em subsistemas?
– Quando um subfluxo:
• ocorre em vários casos de uso.
• possui potencial de reuso.
• é complexo e de fácil encapsulamento.
• é responsabilidade de uma equipe/pessoa
específica.
• produz um resultado bem definido.
• é encapsulado dentro de um componente de
implementação.
• É importante nessa etapa estabilizar a
interface.
Projetar Caso de Uso
Classes de projeto
Projetar
Caso de Uso
Caso de uso
Realização de
caso de uso
Subsistemas de projeto
Documento de
requisitos
Realização de
caso de uso
Exercício Sala I
Faça o projeto de casos de uso do sistema
de biblioteca.
Fluxo de Análise e Projeto
Analisar 
caso de usoProjetista
Projetista de 
banco de 
dados
Revisar 
projeto
Projetar 
caso de uso
Arquiteto
Revisor do 
projeto
Projetar 
base de 
dados
Projetar 
arquitetura
Projetar 
subsistema
Projetar 
classes
Projetar Subsistemas
• Identificar elementos internos ao
subsistema (classes e outros
subsistemas) que realizem a interface
do subsistema.
• Este processo pode gerar novas
dependências do subsistema com
elementos externos.
• A atividade é realizada uma vez para
cada subsistema, podendo ser recursiva
(gerando outros subsistemas).
Projetar Subsistema
1) Identificar elementos de projeto do
subsistema (classes e/ou outros
subsistemas) e distribuir o
comportamento do subsistema entre
eles.
2) Documentar os elementos do
subsistema.
3) Descrever as dependências do
subsistema com elementos externos.
1) Identificar elementos de projeto do
subsistema e distribuir o comportamento do
subsistema entre eles
• Identifique novas classes e subsistemas
que, cooperativamente, realizem o
comportamento do subsistema.
– crie novos elementos de projeto, ou reuse
elementos existentes.
• O comportamento do subsistema pode
ser identificado a partir das operações
na interface.
– As operações podem ser realizadas por
classes internas ou subsistemas internos.
1) Identificar elementos de projeto do
subsistema e distribuir o comportamento do
subsistema entre eles
• Desenvolva um ou mais diagramas de
interação para cada operação da
interface, alocando responsabilidades
aos elementos de projeto.
– os diagramas ajudam a encontrar os
elementos.
• Incorpore persistência, quando aplicável.
2) Documentar os elementos do
subsistema
• A estrutura interna do subsistema é definida
neste passo, através de diagrama(s) de classe,
incluindo os relacionamentos entre elementos
de projeto.
• A técnica usada é a mesma usada na atividade
"Analisar caso de uso".
– As mensagens trocadas entre os objetos apontam
as responsabilidades.
– Os links entre objetos indicam os relacionamentos.
3) Descrever as dependências do
subsistema
• Os passos anteriores identificaram os
elementos internos, com as respectivas
responsabilidades, e as associações
entre esses elementos.
• O objetivo aqui é documentar
associações com elementos externos
necessários à realização da interface do
subsistema.
3) Descrever as dependências do
subsistema
• Dependência de um Subsistema.
• Dependência de um Pacote.
Fornecedor
IFornecedor
Cliente
Cliente Util
Projetar Subsistemas
Classes de projeto
Projeto de 
Subsistema
Realização de
caso de uso
Subsistemas e interfaces de projeto
Subsistemas e interfaces de projeto
(atualizado)
Realização de
caso de uso
(atualizado)
Exercício Sala II
Faça o projeto dos subsistemas do
sistema de biblioteca.
Fluxo de Análise e Projeto
Analisar 
caso de usoProjetista
Projetista de 
banco de 
dados
Revisar 
projeto
Projetar 
caso de uso
Arquiteto
Revisor do 
projeto
Projetar 
base de 
dados
Projetar 
arquitetura
Projetar 
subsistema
Projetar 
classes
Projetar Classes
• Realizado para cada classe identificada.
• Detalha a estrutura interna (atributos e
operações) das classes de projeto.
• Identifica classes e relacionamentos
adicionais.
• Garante que as classes fornecem o
comportamento necessário à realização dos
casos de uso.
• Atenção para os requisitos não funcionais.
• Na verdade, essa etapa revê tudo que já foi
feito adicionando detalhes.
Projetar Classes
1) Identificar classe de Projeto.
2) Definir atributos.
3) Definiroperações.
4) Refinar relacionamentos.
1) Identificar Classes de Projeto
• Revisar mapeamento entre as classes de
análise e projeto.
– Todas as classes de fronteira foram
mapeadas corretamente?
– Todas as classes de controle foram
mapeadas corretamente?
– Todas as classes de entidade foram
mapeadas corretamente?
2) Definir Atributos
• Onde encontrar atributos?
– Documento de Requisitos.
– Modelo de Negócio.
– Glossário.
• É necessário criar atributos derivados?
– Exemplo: Criar o atributo média do aluno ou
calcular a média sempre que necessário?
2) Definir Atributos
• Verificar ainda nos atributos…
– O tipo foi definido?
– É necessário valor inicial?
– A visibilidade foi definida?
• Visibilidade privada por padrão.
– O escopo foi definido?
• Atributos de instância.
• Atributos de classe.
3) Definir Operações
• Mapear as operações encontradas em
análise para operações nas classes de
projeto.
• Deve-se verificar ainda…
– Nome, assinatura e descrição da operação.
– Visibilidade.
– Escopo da operação.
• Operação de classe.
• Operação de instância.
3) Definir Operações
• Deve-se verificar ainda…
– Parâmetros das operações.
• Foram todos definidos?
• Os tipos foram definidos?
• Quanto menos parâmetro no método, mais fácil
de entender e reutilizar.
• Exemplo: É melhor passar um objeto do tipo
Aluno ao invés de passar como parâmetro todos
os dados do aluno (matrícula, nome, endereço,
etc).
4) Refinar Relacionamentos
• Detalhar e avaliar as associações entre
classes quanto ao:
– Tipo.
– Navegabilidade.
– Multiplicidade.
4) Refinar Relacionamentos
• Quanto ao tipo das associações:
– Dependência.
– Associação.
– Agregação.
– Composição.
– Generalização.
Menor nível de
acoplamento
Maior nível de
acoplamento
4) Refinar Relacionamentos
• Quanto a navegabilidade:
– Quais as direções são necessárias?
– A análise dos diagramas de interação é
muito importante nessa definição.
4) Refinar Relacionamentos
• Quanto a multiplicidade:
– Simples de definir, mas essencial para
entender o modelo.
– Quando a multiplicidade é maior que zero,
siginifica que a classe irá trabalhar com uma
coleção do objeto.
Projetar Classes
Classes de projeto
Projetar 
classesRealização de
casos de uso
Requisitos não 
funcionais
Classes de projeto
Modelo de 
análise e projeto
Exercício Sala III
Faça o projeto das classes do sistema de
biblioteca.
Projeto – ES
Criar o modelo de projeto do
sistema proposto.