Aula06-AnaliseeProjeto

(1)

Prof. Jorge Dias

www.jorgediasjr.com

jorge@dce.ufpb.br

Engenharia de Software

Análise e Projeto

Universidade Federal da Paraíba – Campus IV Centro de Ciências Aplicadas e Educação

(2)

Análise e Projeto

 Onde estamos? Requisitos Modelage m de Negócio Análise e Projeto • DDR • Regras de Negócio • Regras de Validação • Casos de uso • Matriz de rastreabilidade • Missão, ambiente, estratégias, metas • Diagrama de Processos de Negócio • Glossário

(3)

Análise e Projeto



Algumas atividades



Analisar casos de uso



Projetar e Validar arquitetura



Projetar casos de uso

(4)

Analisar Casos de Uso

 Investiga o comportamento do sistema dentro

do escopo de um caso de uso

 Proporciona um aprofundamento no

funcionamento do caso de uso e resulta em uma modelagem superficial (Realização do Caso de Uso de Análise)

 O objetivo desta atividade consiste em

identificar as classes iniciais do sistema (classes de análise) e distribuir o

comportamento do caso de uso entre elas

 Cada classe identificada deve ter seus

atributos, responsabilidades (métodos) e relacionamentos descritos

(5)

Analisar Casos de Uso

 Artefatos de Entrada

 Obrigatórios

 Diagrama de Caso de Uso

 _{Documento de Descrição de Requisitos (DDR)}  Especificação de Caso de Uso

 Opcionais

 Documento de Arquitetura de Software  Glossário

 _{Regras de Negócio}  Regras de Validação

(6)

Analisar Casos de Uso

 _{Identificar classes de análise}

 Consiste na primeira iniciativa para modelar como o

sistema irá realizar o caso de uso

 _{Não serão implementadas (codificadas) neste ponto}  _{Nas atividades seguintes, as classes de análise de um}

caso de uso serão mapeadas em elementos de projetos e estas irão compor o projeto do caso de uso o qual guiará codificação do próprio

 As classes de análise são associadas aos seguintes

estereótipos: Fronteira (Boundary), Controle (Control) e Entidade (Entity)

 _{Classes de Fronteira: estão entre os atores e os casos de uso;}  _{Classes de Controle: controlam a lógica do caso de uso;}

(7)

Classe de Entidade

 Representa uma entidade, contendo

informações recebidas ou geradas pelo sistema;

 Diferente de persistente

 Uma entidade armazena dados que podem

ser persistidos ou não.

(8)

Classe de Entidade

DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino<<entity>> Favorecido<<entity>> Comprovante<<entity>>

(9)

Classe de Entidade (com Persistência)

DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino<<entity>> Favorecido<<entity>> Comprovante<<entity>>

CadastroBancoDestino<<entity collection>> <<entity collection>>CadastroDOC <<entity collection>>CadastroConta <<entity collection>>CadastroCliente CadastroFavorecido<<entity collection>>

(10)

Classe de Fronteira



Representa uma interação do sistema com

o ambiente no qual ele está inserido;



Os atores devem interagir com sistema por

meio destas classes;



Regra: uma classe de fronteira para cada

caso de uso;



Exemplos: GUI, interfaces com dispositivos

periféricos, interfaces com outros sistemas

etc.

(11)

Classe de Fronteira

Cliente Banco Destino

Realizar DOC

(12)

Classe de Controle

 _{Representa a interface entre fronteira e entidade,} coordenando o comportamento do caso de uso;

 _{Provê uma separação nítida entre os seguintes itens:}

1. Comunicação do sistema com o ambiente (classes

de fronteira);

2. Comportamento do sistema (classes de controle); 3. Comportamento das entidades do sistema (classes

de entidade).

 Regra: usualmente, uma classe de controle por caso de uso (depende da complexidade do fluxo de eventos).

(13)

Classe de Controle

Cliente Banco Destino

Realizar DOC

(14)

Classes de Análise

TelaRealizarDOC<<boundary>> ControladorRealizarDOC<<control>> DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino<<entity>> Favorecido<<entity>> Comprovante<<entity>>

CadastroBancoDestino<<entity collection>> <<entity collection>>CadastroDOC <<entity collection>>CadastroConta <<entity collection>>CadastroCliente ComunicacaoBancoDestino<<boundary>>

(15)

Diagrama de Classes -

Análise

TelaRealizarDOC<<boundary>> ControladorRealizarDOC<<control>> DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino<<entity>> Favorecido<<entity>> Comprovante<<entity>>

CadastroBancoDestino<<entity collection>> <<entity collection>>CadastroDOC <<entity collection>>CadastroConta <<entity collection>>CadastroCliente ComunicacaoBancoDestino<<boundary>> 1 1 1 1 1 1 1 1 1 1 CadastroFavorecido<<entity collection>>

1 0..* 1 1 0..* 1 1 1 0..* 1 0..* 1 1 1 1 0..* 0..* 1 0..* 1 1 1 1 1

(16)

Analisar Casos de Uso



Resumo

1) Identificar classes de entidade e seus

relacionamentos

2) Identificar classes persistentes, criando uma

classe Entity Collection para cada uma

3) Identificar classes de fronteiras, criando uma

classe Boundary para cada uma

4) Identificar classes de Controle, criando

classe Control para cada uma (geralmente uma por caso de uso)

(17)

Analisar Casos de Uso

 Distribuir comportamento entre as

classes

 Deve ser executado durante a confecção do

Diagrama de Seqüência do caso de uso

 Esta interação sempre é iniciada por um ator e,

do lado do sistema, envolve troca de mensagens entre as instâncias (objetos) das classes, cada qual com suas responsabilidades

 Deve-se ter em mente que o objetivo é modelar

as interações das instâncias das classes para atender a semântica do fluxo de eventos do caso de uso

 _{As responsabilidades de uma classe}

caracterizam os serviços que os objetos da classe devem prover para os outros objetos

(18)

Analisar Casos de Uso

 Mas o que é mesmo um diagrama de

sequência, hein?

 Diagrama de Sequência

 Mostrar classes/objetos/conceitos e as

mensagens trocadas entre eles, no decorrer do tempo

 _{Ênfase no conjunto de passos e na seqüência na qual}

(19)

Analisar Casos de Uso

(20)

Analisar Casos de Uso

 Para criar o diagrama de sequência, considere

os estereótipos das classes criadas anteriormente

 O ator acessará o sistema através da fronteira

(boundary)

 A fronteira chama o controlador responsável

pelo caso de uso (control)

 O controlador realiza as atividades, chamando

classes de entidade e coleções de entidade, outras classes de fronteira (como banco de dados), etc.

(21)

(22)

(23)

(24)

Arquitetura de Software

 _{Em pequenos projetos, a equipe de desenvolvimento} consegue criar uma representação mental sobre a estrutura do produto a ser desenvolvido

 Estrutura de dados e algoritmos são os mais importantes

 Na medida em que o tamanho do software aumenta, fica mais difícil de entender este produto

 Temos mais partes para gerenciar  É mais complexo de se entender  _{Mais riscos envolvidos}

 _{Engenheiros de software buscam abstrações para melhor}

entender o software em construção

(25)

Arquitetura de Software

 Diante de tal complexidade, é preciso pensar

melhor no sistema  Criar componentes

 Modularizarmos as nossas estruturas

 O objetivo é organizar a estrutura do nosso

(26)

Arquitetura de Software

 “Arquitetura de Software de um programa ou

sistema computacional consiste na estrutura ou conjunto de estruturas do sistema, que compreendem (i) elementos de software, (ii) propriedades externamente visíveis destes elementos e (iii) os relacionamentos entre eles.” Bass et al., 2003

(27)

Arquitetura de Software



Algumas atividades

 Definir infraestrutura de desenvolvimento e

plataforma de produção

 Selecionar meio de armazenamento que será

utilizado

 Definir ferramentas de desenvolvimento  _{Definir tecnologias a serem utilizadas}

 Definir ambiente de produção

 Definir o estilo arquitetura do sistema

(camadas?)

 Definir padrões de projeto  Documentar a arquitetura

(28)

Padrões de Projeto

 Um padrão de projeto é uma estrutura

recorrente no projeto de software orientado a objetos. Pelo fato de ser recorrente, vale a

pena que seja documentada e estudada..

 Exemplos  Façade

 DAO (Data Access Object)  _Factory

(29)

Padrões de Projeto

(30)

Padrões de Projeto

 DAO (Data Access Object)

 é um padrão de projetos desenvolvido para

melhorar a forma como trabalhamos com abstração de banco de dados

 Separa internamente seu código, fazendo com

que a parte lógica e as regras de negócio fiquem isoladas de toda persistência com o banco de

(31)

Padrões de Projeto

 Exemplo DAO

public class Cliente { String nome;

String codigo; }

public interface ClienteDAO {

public void inserir(); public void remover(); //e o resto do CRUD  }

public class ClienteDAOMySQL implements ClienteDAO { public void inserir() {

//código JDBC }

public void remover() { //código JDBC

} }

(32)

Padrões de Projeto

 Factory

 Quando estamos trabalhando com uma interface

e temos mais de uma implementação para esta interface, podemos utilizar uma fábrica para

criar um objeto que implementa a interface; a fábrica pode selecionar a implementação que ela retorna

(33)

Padrões de Projeto

 Singleton

 Ele é usado quando for necessária a existência de

apenas uma instância de uma classe

public class ClasseSingleton {

private static ClasseSingleton instance; private ClasseSingleton() { }

public static ClasseSingleton getInstance() {

if (instance == null) instance=new Singleton();

return instance;

} }

(34)

Arquitetura em Camadas

 Divisão da aplicação em camadas:

 Alto grau de escalabilidade, flexibilidade, alta

coesão, baixo acoplamento, ...

 Dois tipos de camadas:  _{Camada Física (Tier)}

(35)

Camada Física

 Representado pela parte física ou estrutural

dos componentes de infra-estrutura da arquitetura que vão desde o hardware, o sistema operacional, os serviços, até os servidores

 Tipos de arquiteturas com camadas físicas:  2 camadas

 _{3 camadas}  N camadas

(36)

2 Camadas

 Também conhecido como cliente-servidor

 Cliente com executável e regras de negócio e

(37)

3 Camadas

 Entre o lado cliente e o lado servidor entrou um

servidor de aplicação onde ficam todas as regras de negócio compartilhadas para os clientes

(38)

N Camadas

 Utilizada para aplicações que exigem um alto

grau de distribuição de seus componentes internos

(39)

Camadas Lógicas (Layer)

 Padrão arquitetural que serve para organizar e

separar as responsabilidades dos componentes internos de uma aplicação

 A arquitetura em camadas prevê que cada

camada deve prover serviços para a camada diretamente superior

 Provê independência entre as camadas que as

compõe

(40)

Apresentação

 Responsável por conter as interfaces dos usuários e

as regras inerentes a qualquer componente visual, regras de validação de entrada de dados

 _{A camada de apresentação deve fazer uso dos}

serviços oferecidos pela camada imediatamente inferior a ele.

 Caso esta camada seja a camada de negócio, a

camada GUI deve conter uma referência para a Fachada do sistema que é o ponto de acesso para os serviços

oferecidos pelo sistema. Portanto, neste exemplo, a Fachada é responsável por fazer a integração entre as camadas de apresentação e a camada de negócio.

(41)

Negócio

 _{A camada de negócio contempla a implementação da} lógica do negócio que do sistema.

 É núcleo do sistema e contém todas as classes inerentes ao domínio da aplicação:

 _{as classes básicas do negócio,}  _{as classes coleções de negócio e}  _{a Fachada do sistema.}

 _{A Fachada também centraliza as instâncias das classes} controladoras.

 _{Por este motivo, as classes controladoras também podem}

ser chamadas de sub-fachadas, já que representam uma Fachada para um determinado caso de uso.

(42)

Acesso a Dados (Infra-Estrutura)

 Responsável por conter toda a lógica para

acesso aos dados, seja via banco de dados, arquivos texto ou XML.

 Os serviços providos pela camada de dados

são utilizados pelas classes coleções de

negócio, que são pertencentes à camada de negócio

 As coleções de negócios realizam operações

de inserção, edição, exclusão e consulta das instâncias das classes básicas de negócio

(43)

Acesso a Dados

(Infra-Estrutura)

(44)

Visões Arquiteturais

 Janela para o sistema em uma perspectiva

particular que serve como comunicação entre os envolvidos no sistema, expressa em texto e diagramas UML

 No RUP, as visões arquiteturais são conhecidas

por Modelo de Visão Arquitetural 4+1, sendo

todas elas dirigidas pela visão de caso de uso

 Ficam documentados no artefato Documento de Arquitetura de Software

(45)

(46)

Visão Lógica

 Responsável pela organização conceitual do software

em termos de camadas, subsistemas, pacotes,

(47)

Visão de Deployment

 Responsável pela instalação física dos processos e

componentes nos nós de processamento e a configuração física da rede entre os nós

(48)

Visão de Implementação

 Neste modelo todo o sistema é organizado para

identificarmos sua estrutura, por exemplo: pacotes java, componentes, arquivos JAR e EAR, etc.

(49)

Visão de Processo

 Responsável por mapear os processos e as threads,

suas responsabilidades, colaborações e a alocação dos elementos da visão lógica

(50)

Visão de Caso de Uso

Responsável por dirigir

as quatro visões

(51)

Projetar Casos de Uso

 Após a definição da arquitetura, os casos de

uso que foram analisados durante a atividade

Analisar Caso de Uso, devem ter seus modelos

atualizados para que fiquem em conformidade com a arquitetura estabelecida

 Artefatos de entrada

 Documento de Arquitetura

 _{Diagrama e Especificação de casos de uso}  DDR (opcional)

(52)

Projetar casos de uso

(53)

Projetar casos de Uso

(54)

(55)

Projetar Banco de Dados

 Vocês verão esta atividade na disciplina de