Analise e Projeto

(1)

Engenharia de Software

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

Departamento de Ciências Exatas

Prof. Jorge Dias

www.jorgediasjr.com

jorge@dce.ufpb.br

(2)

Análise e Projeto

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

(3)

Ciclo de vida do software

Qual o próximo passo?

Usar modelos para tornar mais técnica a linguagem natural

usada inicialmente

Detalhar melhor as informações coletadas num primeiro

momento

Traduzir os requisitos discutidos em funcionalidades do

sistema

(4)

Análise e Modelos

Um modelo de sistema é uma abstração do sistema

em estudo

O modelo deve simplificar a realidade, realçando as

características mais importantes

Existem diferentes tipos de modelo, cada um

enfatizando um aspecto (Ex: interface, arquitetura,

BD, etc)

(5)

Análise e Modelos

Vantagens de usar um modelo

Entender melhor o sistema

Ter uma base para o projeto, permitindo que o

problema real seja mapeado para um contexto de

implementação

Ter uma síntese das informações coletadas para

posterior avaliação do sistema

(6)

Análise e Projeto

Algumas atividades baseadas no RUP

Analisar casos de uso

Projetar e Validar arquitetura

Projetar casos de uso

(7)

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)

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

(8)

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 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; Classes de Entidade: representam as entidades do sistema.

(9)

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.

não.

(10)

(11)

Classe de Entidade

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

(12)

Classe de Entidade (com Persistência)

<<entity>> <<entity>> <<entity>>

BancoDestino <<entity>> Favorecido <<entity>> Comprovante <<entity>> CadastroFavorecido <<entity collection>> DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino CadastroBancoDestino <<entity collection>> CadastroDOC <<entity collection>> CadastroConta <<entity collection>> CadastroCliente <<entity collection>>

(13)

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 par ator-caso de

uso;

Exemplos: GUI, interfaces com dispositivos periféricos,

interfaces com outros sistemas etc.

(14)

Classe de Fronteira

Cliente Banco Destino

Realizar DOC

TelaRealizarDOC

<<boundary>>

ComunicacaoBancoDestino

(15)

Classe de Controle

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

Possui a lógica do caso de uso

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

complexidade do fluxo de eventos). Estereótipo <<control>>

(16)

Classe de Controle

Cliente Banco Destino

Realizar DOC

ControladorRealizarDOC

(17)

Classes de Análise

TelaRealizarDOC <<boundary>> ControladorRealizarDOC <<control>> ComunicacaoBancoDestino <<boundary>> DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino <<entity>> Favorecido <<entity>> Comprovante <<entity>> CadastroBancoDestino <<entity collection>> CadastroDOC <<entity collection>> CadastroConta <<entity collection>> CadastroCliente <<entity collection>> CadastroFavorecido <<entity collection>>

(18)

Diagrama de Classes - Análise

TelaRealizarDOC <<boundary>> ControladorRealizarDOC <<control>> ComunicacaoBancoDestino <<boundary>> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 DOC <<entity>> Conta <<entity>> Cliente <<entity>> BancoDestino <<entity>> Favorecido <<entity>> Comprovante <<entity>> CadastroBancoDestino <<entity collection>> CadastroDOC <<entity collection>> CadastroConta <<entity collection>> CadastroCliente <<entity collection>> CadastroFavorecido <<entity collection>> 1 0..* 0..* 1 1 1 0..* 1 0..* 1 1 0..* 0..* 1 0..* 1 1 1 1 1

(19)

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 3) Identificar classes de fronteiras, criando uma classe Boundary

para cada uma

4) Identificar classes de Controle, criando classe Control para cada

(20)

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

(21)

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

eles, no decorrer do tempo

(22)

Analisar Casos de Uso

(23)

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)

(control)

O controlador realiza as atividades, chamando classes de entidade e coleções de entidade, outras classes de fronteira (como banco de dados), etc.

(24)

(25)

(26)

Arquitetura

(27)

Arquitetura

2 7

(28)

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

Arquitetura de Software

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

(29)

Funcionais Não funcionais

Diferentes Requisitos

Disponibilidade Segurança 2 9 Disponibilidade Manutenabilidade Tolerância a falhas Usabilidade Desempenho Escalabilidade Reusabilidade

(30)

Papel da arquitetura

Ponte entre requisitos e código [Garlan, 2000]

Requisitos

Código Arquitetura

(31)

Diante de tal complexidade, é preciso pensar melhor no sistema

Criar componentes

Modularizarmos as nossas estruturas

Objetivos

Arquitetura de Software

Objetivos

Organizar a estrutura do nosso software Satisfazer os requisitos não funcionais

Como garantir disponibilidade por exemplo? Como garantir segurança?

(32)

“Arquitetura de Software de um programa consiste na estrutura do sistema, que compreendem (i) elementos de software, (ii) propriedades externamente visíveis destes elementos e (iii) os relacionamentos entre eles.” [Bass et

Arquitetura de Software

elementos e (iii) os relacionamentos entre eles.” [Bass et al., 2003]

(33)

Algumas atividades

Selecionar meio de armazenamento que será utilizado Definir tecnologias a serem utilizadas

Definir ambiente de produção

Definir o estilo arquitetura do sistema (camadas?)

Arquitetura de Software

Definir o estilo arquitetura do sistema (camadas?) Definir padrões de projeto

(34)

No início...

GUI

Sistemas Monolíticos

Lógica

(35)

Divisão da aplicação em camadas:

Alto grau de escalabilidade, flexibilidade, alta coesão, baixo acoplamento, ...

Dois tipos de camadas:

Arquitetura em Camadas

Dois tipos de camadas:

Camada Física (Tier) Camada Lógica (Layer)

(36)

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

Camada Física

2 camadas 3 camadas N camadas

(37)

Também conhecido como cliente-servidor

Cliente com executável e regras de negócio e Servidor com banco de dados.

(38)

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

Amplamente utilizado por sistemas Web

(39)

Utilizada para aplicações que exigem um alto grau de distribuição de seus componentes internos

(40)

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

Camadas Lógicas (Layer)

Exemplo: Apresentação Negócio Dados Alta coesão Baixo acoplamento

(41)

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.

Apresentação

pela camada imediatamente inferior a ele.

Exemplo: Camada de apresentação acessa serviços da camada de negócio

(42)

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,

Negócio

as classes básicas do negócio, as classes coleções de negócio e a Fachada do sistema

(43)

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

Acesso a Dados (Infra-Estrutura)

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

(44)

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.

Basicamente cada padrão de projeto resolve um problema já

Padrões de Projeto

Basicamente cada padrão de projeto resolve um problema já conhecido e enfrentado em projetos de software

(45)

Exemplo

Considerando que a arquitetura foi projetada em camadas: apresentação, negócio e dados A comunicação entre Apresentação e Negócio ficariam mais ou menos como mostra a figura

Padrões de Projeto

Apresentação

ficariam mais ou menos como mostra a figura

Podemos diminuir o acoplamento e simplificar o acesso a camada de negócio? Apresentação Apresentação Negócio Negócio Dados Dados Tela X Controlador A Controlador B Controlador C Negócio Tela Y

(46)

Facade (Fachada)

(47)

Aplicando o padrão Facade ao nosso projeto teríamos:

Padrões de Projeto

Controlador A Tela X Controlador B Controlador C Tela Y Apresentação Negócio Fachada

(48)

Padrões de Projeto

CadastroCliente

Controlador A _SGBD

Possui o código para acessar o SGBD

Camada de Dados Camada de Negócio

Agora como conseguimos isolar a camada de dados? Como isolar a lógica da tecnologia de persistência? Como flexibilizar esta camada de dados?

(49)

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

Padrões de Projeto

regras de negócio fiquem isoladas de toda persistência com o banco de dados CadastroCliente Controlador A _SGBD Possui o código para acessar o SGBD Camada de Dados Camada de Negócio ClienteDAOMySQL

(50)

Será que precisamos de várias fachadas ou uma só? No sistema, precisa ter mais de um objeto do tipo Fachada rodando?

E no caso dos DAOs? Precisamos conectar várias vezes ao Banco de dados?

Como garantir então que teremos apenas uma instância de objeto

Padrões de Projeto

Como garantir então que teremos apenas uma instância de objeto rodando no sistema nestes casos?

(51)

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() { }

Padrões de Projeto

private ClasseSingleton() { }

public static ClasseSingleton getInstance() {

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

return instance;

} }

Uso:

(52)

Visões da arquitetura

Clientes diferentes apresentam diferentes informações sobre suas necessidades

(53)

Modelos

Um modelo de sistema é uma

abstração do sistema

em estudo

O modelo deve

simplificar a realidade

, realçando as

características mais importantes

Existem diferentes tipos de

modelo, cada um

enfatizando

um aspecto

(Ex: interface,

(54)

Análise e Modelos

Vantagens de usar um modelo

Documentar

decisões

Entender

melhor o sistema

Guiar a implementação

e outras disciplinas do ciclo de

vida

(55)

Janela para o sistema em uma perspectiva particular que serve como comunicação entre os envolvidos no sistema, expressa geralmente em texto e/ou diagramas UML

No RUP, as visões arquiteturais são conhecidas por Modelo de Visão

Visões Arquiteturais

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

(56)

(57)

Responsável pela organização conceitual do software em termos de

camadas, subsistemas, pacotes, frameworks, classes e interfaces mais

importantes

(58)

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

(59)

Neste modelo todo o sistema é organizado para identificarmos sua

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

(60)

Responsável por mapear os processos e as threads, suas responsabilidades, colaborações e a alocação dos elementos da visão lógica

(61)

Responsável por dirigir

as quatro visões

(62)

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 Artefatos de entrada

Documento de Arquitetura

Diagrama e Especificação de casos de uso DDR (opcional)

(63)

Projetar casos de uso

(64)

Projetar casos de Uso

(65)

(66)