Análise e Projeto de Software Parte II · Atividade Sala III Crie o modelo de análise para o Caso de Uso Emprestar Livro. Agenda • Aula IV ... Definira Estruturada Aplicação

Marcos Dó[email protected]

Análise e Projeto de SoftwareParte II

Agenda

• Aula III– Análise de Software Orientado à Objetos

Motivação


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


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.


• Exemplo


• Como encontrar?– Classes de Fronteira?– Classes de Controle?– Classes de Entidade?


• Classes de Fronteira– Regra: Uma classe para cada interaçãoentre ator e um caso de uso.

Usuário

Devolver Livro

TelaDevolverLivro


• 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.


• Classe de Controle

Devolver Livro

Usuário

ControladorBibliotecaControladorDevolucao

ou ou

ControladorLivro


• 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


• 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).




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>>




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.



• Métodos identificados– Importante utilizar boas ferramentas de modelagem para automatizar o processo.

TelaDevolverLivro<<<boundary>>>

+devolverLivro()

Emprestimo


+buscarEmprestimo()+atualizaEmprestimo()




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.


• 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.


• Exemplo:

A ligação indica que

existe um

relacionamento entre

a classe

ControladorDevolucao

e a classe

CadastroEmprestimo


• Relacionamentos Identificados


+devolverLivro(emprestimo: Emprestimo)

ControladorDevolucao<<control>>

+buscarEmprestimo(emprestimo: Emprestimo)+devolverLivro(emprestimo: Emprestimo)+calculaMultaPorAtraso(emprestimo: Emprestimo)


+buscar(emprestimo: Emprestimo)+atualizar(emprestimo: Emprestimo)

Emprestimo<<entity>>

*

1

1

*

11

Livro<<entity>>

possui

**

Balconista<<entity>>

é realizado

1*


• Atributos Identificados


+devolverLivro(emprestimo: Emprestimo)


+buscarEmprestimo(emprestimo: Emprestimo)+devolverLivro(emprestimo: Emprestimo)+calculaMultaPorAtraso(emprestimo: Emprestimo)


+buscar(emprestimo: Emprestimo)+atualizar(emprestimo: Emprestimo)


*

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…



Revisar projeto


Arquiteto

Revisor do projeto



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


Agenda

• Introdução• Projetar Arquitetura

Introdução

• Onde estamos?

Introdução

• O que faremos?– Projetar Arquitetura

Introdução



Revisar projeto


Arquiteto

Revisor do projeto



Projetar subsistema

Projetar classes


• 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.


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


• 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.


• 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.


• Algumas sugestões para definição…– Sugestão 4) Toda classe de entidade gerauma classe de projeto excluindo o esteriótipo.


• Exemplos:


+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.


• 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.


• Exemplos:ControladorEmprestimo

<<control>>

+emprestarLivro()


+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




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.


• O que é um subsistema?– Cada subsistema deve possuir uma classefachada que implementa a sua interface.

Subsistema

FachadaSubsistema

ISubsistema


• 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


• 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




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.




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.


• 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.


• Exemplo: Biblioteca– Estilo Arquitetural: Camadas (Layer)

Interface com o usuário(GUI)

Negócio

Dados


• 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.


• 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.


• Exemplo: Criando a Camada GUI


+devolverLivro()

Interface com o usuário(GUI)

TelaDevolverLivro

+processa()

ITela

Análise Projeto


• Por que utilizar essa estrutura?– Define uma forma padrão para processar osdados provenientes da interface.


• Exemplo: Criando a Camada Negocio

Análise Projeto

Negócio

ControladorEmprestimo<<control>>

+emprestarLivro()


+buscarEmprestimo()+devolverLivro()+calculaMultaPorAtraso()

ControladorLivro

IControladorLivro

+buscarEmprestimo()+devolverLivro()+calcularMultaAtraso()+emprestarLivro()

IFachada

+buscarEmprestimo()+devolverLivro()+calcularMultaAtraso()+emprestarLivro()

Fachada


• 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.


• Exemplo: Criando a Camada de Dados

AnáliseProjeto

Dados



+buscar()+atualizar()

*1 IRepositorioEmprestimo

+buscar()+atualizar()+inserir()

RepositorioEmprestimoBDR

+getInstance()

Emprestimo


• Por que utilizar essa estrutura?

IRepositorioEmprestimo

+buscar()+atualizar()+inserir()


+getInstance()

RepositorioEmprestimoBDOO

+getInstance()

RepositorioEmprestimoFile

+getInstance()


• 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.


GUI

Negocio

Dados

ITela

TelaDevolverLivro

+processa()

Fachada

IControladorLivro

IFachada

ControladorLivro ControladorAluno

IControladorAluno



+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…



Revisar projeto


Arquiteto

Revisor do projeto



Projetar subsistema

Projetar classes

Projeto de Software Orientada a Objetos


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



Revisar projeto


Arquiteto

Revisor do projeto



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


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


• 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()


• Como era na análise?


• 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



+getInstance()


• Como ficou no projeto?


• 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.


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.


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.


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.


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

Documents

Análise e Projeto de Software Parte II · Atividade Sala III Crie o modelo de análise para o Caso de Uso Emprestar Livro. Agenda • Aula IV ... Definira Estruturada Aplicação