Análise e Projeto de Software Parte II. Marcos Dósea

Análise e Projeto de Software Parte II Marcos Dósea marcosdosea@gmail.com

Agenda Aula III Análise de Software Orientado à Objetos

Motivação Marcos Dósea marcosdosea@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ósea marcosdosea@gmail.com

Agenda Introdução Analisar Caso de Uso

Onde estamos? Introdução

Introdução Análise x Projeto Análise Foco no problema Comportamento caixa preta Estrutura geral da arquitetura do sistema Requisitos Funcionais Modelo simples Projeto Foco na solução Detalha operações e atributos dos objetos Representação próxima do código. Requisitos Funcionais e Não Funcionais Modelo complexo.

Introdução O que faremos? Análisar o Software

Introdução Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados

Analisar Caso de Uso 1) Identificar as Classes de Análise 2) Identificar Persistência 3) Identificar Responsabilidades das Classes 4) Identificar Atributos e Relacionamentos

1) Identificar as Classes de Análise Para cada Caso de Uso são identificadas os três tipos de classe de análise: Fronteira: modela iteração entre ator e sistema. Entidade: Modela a informação manipulada pelo sistema. Conceito análogo ao modelo ER. Controle: Controla o fluxo de execução do caso de uso.

1) Identificar as Classes de Exemplo Análise

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ção entre ator e um caso de uso. Devolver Livro Usuário TelaDevolverLivro

1) Identificar as Classes de Classe de Controle Análise Regra: Uma classe de controle para cada caso de uso. Quando muito simples pode-se utilizar uma única classe de controle para vários casos de uso. Outra possibilidade é usar uma classe de controle por entidade manipulada.

1) Identificar as Classes de Classe de Controle Análise Devolver Livro Usuário ou ou ControladorDevolucao ControladorBiblioteca ControladorLivro

1) Identificar as Classes de Classe de Entidade Análise Regra: Abordagem tradicional de filtrar substantivos. Ex: Objetos Físicos ou tangíveis, Lugares, Papéis de Pessoas, Eventos, etc. Balconista Livro Usuario 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 mais tarde) e operações (devem ficar na classe controladora).

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 cujos atributos devem ser armazenados em meio não volátil (Ex: SGBD). Para cada classes persistente criar uma classe de cadastro usando o esteriótipo <<entity collection>>

2) Identificar Persistência Classes de Entidade Persistentes Livro Usuario Balconista Emprestimo <<entity collection>> CadastroLivros <<entity collection>> CadastroUsuarios <<entity collection>> CadastroBalconistas <<entity collection>> CadastroEmprestimos

3) Identificar Responsabilidades das Classes Os diagramas de sequência e comunicação devem ser utilizados nessa fase para identificação das responsabilidades das classes. Cada caso de uso analisado adiciona novos comportamentos as classes. Cada caso de uso pode gerar um ou mais diagramas de sequência.

3) Identificar Responsabilidades das Classes

3) Identificar Responsabilidades das Classes Métodos identificados Importante utilizar boas ferramentas de modelagem para automatizar o processo. Emprestimo <<entity collection>> CadastroEmprestimos +buscaremprestimo() +atualizaemprestimo() <<<boundary>>> TelaDevolverLivro +devolverlivro()

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 funcionam sem relacionar-se com as outras. Os diagramas de sequência e comunicação são muito úteis nessa tarefa. Para cada ligação nesses diagramas deve ser gerado um relacionamento.

4) Identificar Atributos e Exemplo: Relacionamentos A ligação indica que existe um relacionamento entre a classe ControladorDevolucao e a classe CadastroEmprestimo

4) Identificar Atributos e Relacionamentos Relacionamentos Identificados <<entity>> Livro <<<boundary>>> TelaDevolverLivro <<entity>> Emprestimo possui * * +devolverlivro(emprestimo: Emprestimo) é realizado * 1 * 1 <<entity>> Balconista 1 * <<control>> ControladorDevolucao <<entity collection>> CadastroEmprestimos +buscaremprestimo(emprestimo: Emprestimo) +devolverlivro(emprestimo: Emprestimo) +calculamultaporatraso(emprestimo: Emprestimo) 1 1 +buscar(emprestimo: Emprestimo) +atualizar(emprestimo: Emprestimo)

4) Identificar Atributos e Relacionamentos Atributos Identificados <<<boundary>>> TelaDevolverLivro +devolverlivro(emprestimo: Emprestimo) * <<entity>> Emprestimo 1 possui * * é realizado * 1 <<entity>> Livro +isbn +nome <<entity>> Balconista 1 * +cpf +nome <<control>> ControladorDevolucao <<entity collection>> CadastroEmprestimos +buscaremprestimo(emprestimo: Emprestimo) +devolverlivro(emprestimo: Emprestimo) +calculamultaporatraso(emprestimo: Emprestimo) 1 1 +buscar(emprestimo: Emprestimo) +atualizar(emprestimo: Emprestimo)

Em resumo Glossário Documento da arquitetura Classes de Análise (detalhada) Documento de requisitos Analisar caso de uso Realização de caso de uso (atualizada) Modelo de caso de uso Modelo de Análise

Próximos passos Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados

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ósea marcosdosea@gmail.com

Agenda Introdução Projetar Arquitetura

Introdução O que faremos? Projetar Arquitetura

Introdução Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados

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 subsistemas 3) Identificar oportunidades de Reuso 4) 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 projeto já existente. A definição do mapeamento é muito dependente da experiência do arquiteto e 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 é mapeada para 1 classe de projeto se ela for simples e representar uma única abstração. Sugestão 2) Classes de análises muito simples devem ser combinada em uma única classe de projeto. Sugestão 3) Classes de análises muito complexas 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 gera uma classe de projeto excluindo o esteriótipo.

1) Definir o mapeamento entre as classes de análise e os elementos de projeto Exemplos: <<<boundary>>> TelaDevolverLivro +devolverlivro() ITela TelaDevolverLivro +processa() 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: <<entity>> Livro +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: <<control>> ControladorEmprestimo +emprestarlivro() <<control>> ControladorDevolucao +buscaremprestimo() +devolverlivro() +calculamultaporatraso() ControladorLivro +buscaremprestimo() +devolverlivro() +calcularmultaatraso() +emprestarlivro() IControladorLivro 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.

2) Identificar Subsistemas O que é um subsistema? O subsistema divide o sistema em partes independentes (componentes) que possuem uma 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 classe fachada 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 que fazem interface com outros sistemas são normalmente candidatos a serem subsistemas. <<boundary>> ComunicacaoEditora +atualizarlivro(isbn: long) ComunicacaoEditora Fachada IComunicacaoEditora +atualizarlivro(isbn: String)

2) Identificar Subsistemas Como identificar subsistemas? Sugestão 2) Classes que fornecem serviços complexos. Sugestão 3) Classes utilitárias e que dão suporte ao acesso ao banco de dados. Sugestão 4) Classes reusáveis autocontidas como softwares de comunicação, estruturas de dados, etc. ComunicacaoCatraca Fachada IComunicacaoCatraca +registraentrada(matricula: String) +registrasaida(matricula: String)

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 da Aplicaçã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 é normalmente padrão para todos os sistemas de organização mas deve ser atualizado a cada necessidade de sistema. As regras de mapeamento devem ser atualizadas para adptar-se à estrutura da aplicação escolhida.

4) Definir a Estrutura da Aplicaçã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 cada objeto responsável pela pela persistência dos dados.

4) Definir a Estrutura da Aplicação Exemplo: Biblioteca Estilo Arquitetural: Camadas (Layer) Interface com o usuário (GUI) Negócio Dados

4) Definir a Estrutura da Aplicaçã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 trabalhando com diferentes versões de outra camadas. Ex: Diferentes interfaces gráficas Diferentes forma de acesso a dados.

4) Definir a Estrutura da Aplicação No nosso exemplo da biblioteca temos: Camada GUI: Responsável por obter os dados 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ário chama a camada de acesso a dados. Camada de Dados: Contém toda lógica necessária para acessar um meio persistente.

4) Definir a Estrutura da Aplicação Exemplo: Criando a Camada GUI <<<boundary>>> TelaDevolverLivro +devolverlivro() ITela TelaDevolverLivro +processa() Análise Projeto Interface com o usuário (GUI)

4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? Define uma forma padrão para processar os dados provenientes da interface.

4) Definir a Estrutura da Aplicação Exemplo: Criando a Camada Negocio <<control>> ControladorEmprestimo Fachada IFachada +emprestarlivro() <<control>> ControladorDevolucao ControladorLivro IControladorLivro +buscaremprestimo() +devolverlivro() +calcularmultaatraso() +emprestarlivro() +buscaremprestimo() +devolverlivro() +calculamultaporatraso() +buscaremprestimo() +devolverlivro() +calcularmultaatraso() +emprestarlivro() Análise Projeto Negócio

4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? A Fachada oferecer uma interface única para um conjunto de interfaces de um subsistema. Minimiza a dependência entre os subsistemas. Facilidade para os clientes da camada de negócio que precisam conhecer apenas uma única classe.

4) Definir a Estrutura da Aplicação Exemplo: Criando a Camada de Dados <<entity collection>> CadastroEmprestimos +buscar() +atualizar() RepositorioEmprestimoBDR +getinstance() Emprestimo * 1 <<entity>> Emprestimo IRepositorioEmprestimo +buscar() +atualizar() +inserir() Análise Projeto Dados

4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? RepositorioEmprestimoBDR +getinstance() RepositorioEmprestimoBDOO IRepositorioEmprestimo +getinstance() +buscar() +atualizar() +inserir() RepositorioEmprestimoFile +getinstance()

4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? O padrão singleton: Usado porque é desnecessário existirem várias instâ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 da Aplicação TelaDevolverLivro GUI ITela +processa() Negocio Fachada IFachada ControladorLivro ControladorAluno IControladorLivro IControladorAluno Dados RepositorioEmprestimoBDR IRepositorioEmprestimo +getinstance()

Em Resumo Modelo de casos de uso Mapeamento das classes de análise em elementos de projeto Documento de requisitos Projetar Arquitetura Documento da arquitetura Modelo de análise e projeto (classes de análise) Modelo de análise e projeto (classes de projeto e subsistemas)

Próximos passos Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados

Projeto de Software Orientada a Objetos Marcos Dósea marcosdosea@gmail.com

Agenda Introdução Projetar Caso de Uso

Introdução Análise x Projeto Análise Foco no problema Comportamento caixa preta Estrutura geral da arquitetura do sistema Requisitos Funcionais Modelo simples Projeto Foco na solução Detalha operações e atributos dos objetos Representação próxima do código. Requisitos Funcionais e Não Funcionais Modelo complexo.

Introdução O que faremos? Projetar o Software

Fluxo de Análise e Projeto Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados

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 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 a análise? <<boundary>> : TelaDevolverLivro <<control>> : ControladorDevolucao <<entity collection>> : CadastroEmprestimos : Balconista 1 : devolverlivro() <<create>> 2 <<entity>> : Emprestimo 4 : devolverlivro() 3 5 : buscar() 6 7 : calculamultaporatraso() 8 : atualizar() 11 : resultado() 10 9

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 TelaDevolverLivro GUI ITela +processa() Negocio Fachada IFachada ControladorLivro ControladorAluno IControladorLivro IControladorAluno Dados RepositorioEmprestimoBDR IRepositorioEmprestimo +getinstance()

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 Documento de requisitos Subsistemas de projeto Realização de caso de uso Projetar Caso de Uso Realização de caso de uso Caso de uso Classes de projeto

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 estudo de caso proposto, ou seja, para cada caso de uso identificado, apresentar os diagramas de interação e o diagrama de classes que o realizam. Crie um documento único que agrupe os vários modelos 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 dois documentos.

Projeto da Disciplina 3) Crie o modelo de projeto de software utilizando as regras de mapeamento definidas pelo arquiteto. Crie um documento único que agrupe os vários modelos 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