Post on 07-Nov-2018
Marcos Dóseamarcosdosea@gmail.com
Análise e Projeto de SoftwareParte II
Agenda
• Aula III– Análise de Software Orientado à Objetos
Motivação
Marcos Dóseamarcosdosea@gmail.com
O que é análise e projeto?
Qual a importância?
Por onde começar?
• Visão do Sistema
Modelagem de Negócio
Requisitos
Análise
Projeto
Implementação
Análise de Software Orientada a Objetos
Marcos Dóseamarcosdosea@gmail.com
Agenda
• Introdução• Analisar Caso de Uso
Introdução
• Onde estamos?
Introdução
• Análise x Projeto
Modelo complexo.Modelo simples
Requisitos Funcionais e Não Funcionais
Requisitos Funcionais
Representação próximado código.
Estrutura geral daarquitetura do sistema
Detalha operações e atributos dos objetos
Comportamento caixapreta
Foco na soluçãoFoco no problemaProjetoAnálise
Introdução
• O que faremos?– Análisar o Software
Introdução
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
Analisar Caso de Uso
1) Identificar as Classes de Análise2) Identificar Persistência3) Identificar Responsabilidades das
Classes4) Identificar Atributos e
Relacionamentos
1) Identificar as Classes de Análise
• Para cada Caso de Uso são identificadasos três tipos de classe de análise:– Fronteira: modela iteração entre ator e sistema.
– Entidade: Modela a informação manipuladapelo sistema. Conceito análogo ao modeloER.
– Controle: Controla o fluxo de execução do caso de uso.
1) Identificar as Classes de Análise
• Exemplo
1) Identificar as Classes de Análise
• Como encontrar?– Classes de Fronteira?– Classes de Controle?– Classes de Entidade?
1) Identificar as Classes de Análise
• Classes de Fronteira– Regra: Uma classe para cada interaçãoentre ator e um caso de uso.
Usuário
Devolver Livro
TelaDevolverLivro
1) Identificar as Classes de Análise
• Classe de Controle– Regra: Uma classe de controle para cadacaso de uso. Quando muito simples pode-se utilizar uma única classe de controle paravários casos de uso. Outra possibilidade éusar uma classe de controle por entidademanipulada.
1) Identificar as Classes de Análise
• Classe de Controle
Devolver Livro
Usuário
ControladorBibliotecaControladorDevolucao
ou ou
ControladorLivro
1) Identificar as Classes de Análise
• Classe de Entidade– Regra: Abordagem tradicional de filtrarsubstantivos. Ex: Objetos Físicos outangíveis, Lugares, Papéis de Pessoas, Eventos, etc.
Balconista
Usuario
Livro
Emprestimo
1) Identificar as Classes de Análise
• Classe de Entidade – Passo a Passo– Identifique substantivos nas fontes de informação (modelo de negócio, casos de uso, glossário, etc.).
– Remova candidatos redundantes e vagos.– Remova atores que apenas interagem com o sistema mas não participam da modelagem.
– Remova atributos (serão pensados maistarde) e operações (devem ficar na classecontroladora).
Analisar Caso de Uso
1) Identificar as Classes de Análise2) Identificar Persistência3) Identificar Responsabilidades das
Classes4) Identificar Atributos e
Relacionamentos
2) Identificar Persistência
• Identifica entre as classe de análise do tipo entidade aquelas que deverão ser persistidas.
• Classes persistentes são aquelas cujosatributos devem ser armazenados emmeio não volátil (Ex: SGBD).
• Para cada classes persistente criar umaclasse de cadastro usando o esteriótipo<<entity collection>>
2) Identificar Persistência
• Classes de Entidade Persistentes
Livro BalconistaUsuarioEmprestimo
CadastroLivros<<entity collection>>
CadastroUsuarios<<entity collection>>
CadastroBalconistas<<entity collection>>
CadastroEmprestimos<<entity collection>>
Analisar Caso de Uso
1) Identificar as Classes de Análise2) Identificar Persistência3) Identificar Responsabilidades das
Classes4) Identificar Atributos e
Relacionamentos
3) Identificar Responsabilidadesdas Classes
• Os diagramas de sequência e comunicação devem ser utilizados nessafase para identificação das responsabilidades das classes.
• Cada caso de uso analisado adicionanovos comportamentos as classes.
• Cada caso de uso pode gerar um ou maisdiagramas de sequência.
3) Identificar Responsabilidadesdas Classes
3) Identificar Responsabilidadesdas Classes
• Métodos identificados– Importante utilizar boas ferramentas de modelagem para automatizar o processo.
TelaDevolverLivro<<<boundary>>>
+devolverLivro()
Emprestimo
CadastroEmprestimos<<entity collection>>
+buscarEmprestimo()+atualizaEmprestimo()
Analisar Caso de Uso
1) Identificar as Classes de Análise2) Identificar Persistência3) Identificar Responsabilidades das
Classes4) Identificar Atributos e
Relacionamentos
4) Identificar Atributos e Relacionamentos
• Onde encontrar os atributos e relacionamentos?– Modelo de negócio– Requisitos de Usuário e de Sistema– Glossário– etc.
4) Identificar Atributos e Relacionamentos
• As classes identificadas não funcionamsem relacionar-se com as outras.
• Os diagramas de sequência e comunicação são muito úteis nessatarefa.
• Para cada ligação nesses diagramas deveser gerado um relacionamento.
4) Identificar Atributos e Relacionamentos
• Exemplo:
A ligação indica que
existe um
relacionamento entre
a classe
ControladorDevolucao
e a classe
CadastroEmprestimo
4) Identificar Atributos e Relacionamentos
• Relacionamentos Identificados
TelaDevolverLivro<<<boundary>>>
+devolverLivro(emprestimo: Emprestimo)
ControladorDevolucao<<control>>
+buscarEmprestimo(emprestimo: Emprestimo)+devolverLivro(emprestimo: Emprestimo)+calculaMultaPorAtraso(emprestimo: Emprestimo)
CadastroEmprestimos<<entity collection>>
+buscar(emprestimo: Emprestimo)+atualizar(emprestimo: Emprestimo)
Emprestimo<<entity>>
*
1
1
*
11
Livro<<entity>>
possui
**
Balconista<<entity>>
é realizado
1*
4) Identificar Atributos e Relacionamentos
• Atributos Identificados
TelaDevolverLivro<<<boundary>>>
+devolverLivro(emprestimo: Emprestimo)
ControladorDevolucao<<control>>
+buscarEmprestimo(emprestimo: Emprestimo)+devolverLivro(emprestimo: Emprestimo)+calculaMultaPorAtraso(emprestimo: Emprestimo)
CadastroEmprestimos<<entity collection>>
+buscar(emprestimo: Emprestimo)+atualizar(emprestimo: Emprestimo)
Emprestimo<<entity>>
*
1
1
*
11
Livro<<entity>>
+isbn+nomepossui
**
Balconista<<entity>>
+cpf+nome
é realizado
1*
Em resumo…
Modelo de Análise
Documento da
arquitetura
Modelo de caso de uso
Documento de
requisitos
Glossário
Analisar
caso de usoRealização de caso de uso
(atualizada)
Classes de Análise
(detalhada)
Próximos passos…
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
Atividade Sala III
Crie o modelo de análise para o Caso de Uso Emprestar Livro
Agenda
• Aula IV– Projetar Arquitetura– Projeto do Software
Projetar Arquitetura
Marcos Dóseamarcosdosea@gmail.com
Agenda
• Introdução• Projetar Arquitetura
Introdução
• Onde estamos?
Introdução
• O que faremos?– Projetar Arquitetura
Introdução
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 Arquitetura
• Avaliar o conjunto das classes de análise.
• Definir elementos de projeto (classes de projeto e subsistemas) e organizá-los em pacotes.
• Definir a estrutura da aplicação para os projetistas possam detalhar a aplicação nas próximas fases.
Projetar Arquitetura
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
2) Identificar subsistemas3) Identificar oportunidades de Reuso4) Definir a estrutura da aplicação
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
• Para cada classe de análise deve-se definir se ela dará origem a:– Uma classe de projeto.– Mais de uma classe de projeto.– Um subsistema– Zero classes de projeto, ela seráincorporada a uma outra classe de projetojá existente.
• A definição do mapeamento é muitodependente da experiência do arquitetoe do estilo arquitetural escolhido.
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
• Algumas sugestões para definição…– Sugestão 1) 1 classe de análise é mapeadapara 1 classe de projeto se ela for simples e representar uma única abstração.
– Sugestão 2) Classes de análises muitosimples devem ser combinada em uma únicaclasse de projeto.
– Sugestão 3) Classes de análises muitocomplexas devem ser quebradas em classes mais simples ou gerar um subsistema.
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
• Algumas sugestões para definição…– Sugestão 4) Toda classe de entidade gerauma classe de projeto excluindo o esteriótipo.
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
• Exemplos:
TelaDevolverLivro<<<boundary>>>
+devolverLivro()
TelaDevolverLivro
+processa()ITela
Para cada classe de fronteira identificada que for uma tela de
interação com o usuário deve-se criar uma classe com o
mesmo nome que implementa a interface ITela. Essa classe
deve conter apenas o método processa() que obtém os dados
da interface e realiza a próxima operação.
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
• Exemplos:
Livro<<entity>>
+isbn+nome
Livro
+isbn+nome
Para cada classe de entidade identificada deve existir uma
classe de projeto correspondente sem o esteriótipo.
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
• Exemplos:ControladorEmprestimo
<<control>>
+emprestarLivro()
ControladorDevolucao<<control>>
+buscarEmprestimo()+devolverLivro()+calculaMultaPorAtraso()
Classes de controle que manipulem uma mesma entidade
devem ser unidas em uma única classe que implementa uma
interface de projeto que vai unir as interfaces dessas classes
de análise. O nome da classe de projeto e da interface criada
deve referenciar a entidade que ela manipula.
ControladorLivro
+buscarEmprestimo()+devolverLivro()+calcularMultaAtraso()+emprestarLivro() IControladorLivro
Projetar Arquitetura
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
2) Identificar subsistemas3) Identificar oportunidades de Reuso4) Definir a estrutura da aplicação
2) Identificar Subsistemas
• O que é um subsistema?
O subsistema divide o sistema em partesindependentes (componentes) que possuemuma interface bem definida e que pode ser desenvolvido, testado e implantado de forma
independente dos demais.
2) Identificar Subsistemas
• O que é um subsistema?– Cada subsistema deve possuir uma classefachada que implementa a sua interface.
Subsistema
FachadaSubsistema
ISubsistema
2) Identificar Subsistemas
• Como identificar subsistemas?– Experiência do arquiteto conta muito.– Algumas regras que podem ajudar:
• Sugestão 1) Classes de análise fronteira quefazem interface com outros sistemas sãonormalmente candidatos a serem subsistemas.
ComunicacaoEditora<<boundary>>
+atualizarLivro(isbn: long)
ComunicacaoEditora
IComunicacaoEditora
+atualizarLivro(isbn: String)
Fachada
2) Identificar Subsistemas
• Como identificar subsistemas?• Sugestão 2) Classes que fornecem serviçoscomplexos.
• Sugestão 3) Classes utilitárias e que dão suporteao acesso ao banco de dados.
• Sugestão 4) Classes reusáveis autocontidascomo softwares de comunicação, estruturas de dados, etc.
ComunicacaoCatraca
IComunicacaoCatraca
+registraEntrada(matricula: String)+registraSaida(matricula: String)
Fachada
Projetar Arquitetura
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
2) Identificar subsistemas3) Identificar oportunidades de Reuso4) Definir a estrutura da aplicação
3) Identificar Oportunidades de Reuso
• Verifica se um subsistema pode ser comprado ou reutilizado, ao invés de desenvolvido.– Ex: Subsistema da catraca e utilitários.
• Deve-se analisar o impacto de mudar a interface do subsistema para adaptá-la ànecessidade do novo sistema.
• Deve-se também avaliar a possibilidade de modificar um subsistema existente de forma a torná-lo reutilizável.
Projetar Arquitetura
1) Definir o mapeamento entre as classes de análise e os elementos de projeto
2) Identificar subsistemas3) Identificar oportunidades de Reuso4) Definir a estrutura da aplicação
4) Definir a Estrutura daAplicação
• O arquiteto define o estilo arquitetural que seráadotado, os padrões de projeto e idiomas.
• Essas definições devem estar registradas no documento de arquitetura.
• O documento de arquitetura é normalmentepadrão para todos os sistemas de organizaçãomas deve ser atualizado a cada necessidade de sistema.
• As regras de mapeamento devem ser atualizadaspara adptar-se à estrutura da aplicaçãoescolhida.
4) Definir a Estrutura daAplicação
• Exemplo: Biblioteca– Estilo Arquitetural: Camadas (Layer)– Padrões de Projeto:
• Façade (Fachada): Para abstrair a camada de negócio.
• Singleton: Apenas uma instância para cadaobjeto responsável pela pela persistência dos dados.
4) Definir a Estrutura daAplicação
• Exemplo: Biblioteca– Estilo Arquitetural: Camadas (Layer)
Interface com o usuário(GUI)
Negócio
Dados
4) Definir a Estrutura daAplicação
• Por usar o estilo em camadas?– Mudanças em uma camada não afeta as camadas adjascentes, desde que as interfaces sejam preservadas.
– Uma mesma versão da camada trabalhandocom diferentes versões de outra camadas.• Ex: Diferentes interfaces gráficas
Diferentes forma de acesso a dados.
4) Definir a Estrutura daAplicação
• No nosso exemplo da biblioteca temos:– Camada GUI: Responsável por obter osdados da interface e invocar um método de negócio
– Camada de Negócio: Contém toda lógica de negócio da aplicação e caso necessáriochama a camada de acesso a dados.
– Camada de Dados: Contém toda lógicanecessária para acessar um meiopersistente.
4) Definir a Estrutura daAplicação
• Exemplo: Criando a Camada GUI
TelaDevolverLivro<<<boundary>>>
+devolverLivro()
Interface com o usuário(GUI)
TelaDevolverLivro
+processa()
ITela
Análise Projeto
4) Definir a Estrutura daAplicação
• Por que utilizar essa estrutura?– Define uma forma padrão para processar osdados provenientes da interface.
4) Definir a Estrutura daAplicação
• Exemplo: Criando a Camada Negocio
Análise Projeto
Negócio
ControladorEmprestimo<<control>>
+emprestarLivro()
ControladorDevolucao<<control>>
+buscarEmprestimo()+devolverLivro()+calculaMultaPorAtraso()
ControladorLivro
IControladorLivro
+buscarEmprestimo()+devolverLivro()+calcularMultaAtraso()+emprestarLivro()
IFachada
+buscarEmprestimo()+devolverLivro()+calcularMultaAtraso()+emprestarLivro()
Fachada
4) Definir a Estrutura daAplicação
• Por que utilizar essa estrutura?– A Fachada oferecer uma interface únicapara um conjunto de interfaces de um subsistema.
– Minimiza a dependência entre ossubsistemas.
– Facilidade para os clientes da camada de negócio que precisam conhecer apenas umaúnica classe.
4) Definir a Estrutura daAplicação
• Exemplo: Criando a Camada de Dados
AnáliseProjeto
Dados
Emprestimo<<entity>>
CadastroEmprestimos<<entity collection>>
+buscar()+atualizar()
*1 IRepositorioEmprestimo
+buscar()+atualizar()+inserir()
RepositorioEmprestimoBDR
+getInstance()
Emprestimo
4) Definir a Estrutura daAplicação
• Por que utilizar essa estrutura?
IRepositorioEmprestimo
+buscar()+atualizar()+inserir()
RepositorioEmprestimoBDR
+getInstance()
RepositorioEmprestimoBDOO
+getInstance()
RepositorioEmprestimoFile
+getInstance()
4) Definir a Estrutura daAplicação
• Por que utilizar essa estrutura?– O padrão singleton:
• Usado porque é desnecessário existirem váriasinstâncias de classes para acessar o banco de dados. Melhor utilização da memória.
• Define como acessar de forma controlada umaúnica instância da classe.
• Permite facilmente variar o número de instâncias caso seja necessário.
4) Definir a Estrutura daAplicação
GUI
Negocio
Dados
ITela
TelaDevolverLivro
+processa()
Fachada
IControladorLivro
IFachada
ControladorLivro ControladorAluno
IControladorAluno
IRepositorioEmprestimo
RepositorioEmprestimoBDR
+getInstance()
Em Resumo…
Modelo de análise e projeto
(classes de análise)
Projetar ArquiteturaDocumento
de requisitos
Modelo de casos de uso
Documento daarquitetura
Mapeamento das classes de análise em elementos de projeto
Modelo de análise e projeto
(classes de projeto e
subsistemas)
Próximos passos…
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
Projeto de Software Orientada a Objetos
Marcos Dóseamarcosdosea@gmail.com
Agenda
• Introdução• Projetar Caso de Uso
Introdução
• Onde estamos?
Introdução
• Análise x Projeto
Modelo complexo.Modelo simples
Requisitos Funcionais e Não Funcionais
Requisitos Funcionais
Representação próximado código.
Estrutura geral daarquitetura do sistema
Detalha operações e atributos dos objetos
Comportamento caixapreta
Foco na soluçãoFoco no problemaProjetoAnálise
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 usosubstituindo os elementos de análise (elaboradas na análise de casos de uso) por elementos de projeto definido no mapeamento 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 uso2) Simplificar os diagramas de interação.
1) Refinar as Realizações de Casode Uso
• Substitui as classes de projeto e ouinterfaces dos subsistemas associadosseguindo as recomendações da arquitetura.
• Incorporar a persistência• Atualizar os diagramas que realizam o casode uso:– Diagramas de interação– Diagramas de Classes
1) Refinar as Realizações de Casode Uso
• Como era a análise?
: Balconista
: TelaDevolverLivro<<boundary>>
: ControladorDevolucao<<control>>
: Emprestimo<<entity>>
: CadastroEmprestimos<<entity collection>>
1 : devolverLivro()
2
<<create>>
34 : devolverLivro()
5 : buscar()
6
7 : calculaMultaPorAtraso()
8 : atualizar()
9
1011 : resultado()
1) Refinar as Realizações de Casode Uso
• Como era na análise?
1) Refinar as Realizações de Casode 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 peloarquiteto.
– Para cada diagrama de interação de análisedeve 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 Casode Uso
• Como ficou no projeto?
1) Refinar as Realizações de Casode 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 projetoDocumento de
requisitos
Realização de
caso de uso
Atividade Sala IV
Criar o modelo de projeto para o Caso de Uso Emprestar Livro.
Projeto da Disciplina
1) Criar o modelo de análise para o estudode caso proposto, ou seja, para cadacaso de uso identificado, apresentar osdiagramas de interação e o diagramade classes que o realizam. Crie um documento único que agrupe os váriosmodelos de análise criados.
Projeto da Disciplina
2) Definir (i) arquitetura do sistema do projeto proposto e (ii) as regras de mapeamento para os elementos de projeto. Utilize o template do RUP para documentação desses doisdocumentos.
Projeto da Disciplina
3) Crie o modelo de projeto de software utilizando as regras de mapeamentodefinidas pelo arquiteto. Crie um documento único que agrupe os váriosmodelos de projeto criados.
Projeto da Disciplina
Em resumo...(1) Documento com Modelos de Análise(2)Documento da Arquitetura(3)Documento com Mapeamentos entre
Modelos de Análise e Projeto(4)Documento com Modelos de Projeto