Contexto Após a análise de requisitos, temos documentos de

requisitos e os casos de uso em mãos.

Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso (requisitos funcionais).

Este modelo é chamado de modelo de análise.

Analisando os requisitos não funcionais, é feita escolha da Arquitetura a ser usada;

Definida a arquitetura, geramos um modelo de projeto a ser implementado.

2/28

2012 2

Contexto

3/28

Requisitos Análise Projeto

2012 3

Arquitetura

Atividade de Análise Vai proporcionar um método que permita que

criemos um modelo de classes do sistema a partir dos casos de uso

Trará a resposta para a pergunta:

Quais classes preciso para implementar estes casos de uso?

4/28

2012 4

Análise & RUP A maneira como vamos realizar a etapa de análise se

baseia no processo do RUP (Rational Unified Process)

A análise será orientada a casos de uso, ou seja, os casos de uso servirão de guia para a etapa de análise

2012 5

Casos de Uso X Análise

casos de uso análise

Descritos na linguagemdo cliente

Descrito na linguagemdos desenvolvedores

Visão externa dosistema

Visão interna do sistema

Captura as

funcionalidades dosistema

Mostra, de modo

abstrato, como afuncionalidade pode serrealizada

Estruturado por casosde uso

Estruturado por classese pacotes

2012 6

Análise & Projeto

Os objetivos do fluxo:

Transformar os requisitos em um projeto do

sistema do que o sistema será

Derivar uma arquitetura robusta do sistema

Adaptar o projeto

2012 7

Análise versus Projeto Foco no entendimento do

problema

Projeto idealizado

Comportamento

Estrutura do sistema

Requisitos funcionais

Modelos simples

Foco no entendimento da solução

Operações e atributos

Performance

Pensamento no código

Ciclo de vida de objetos

Requisitos não-funcionais

Modelo complexo

2012 8

Visão geral dos artefatos

Análise e

projeto

Modelo de análise e projeto

Documento da arquitetura

Modelo de caso de uso

Modelo de dados

Documento requisitos

Glossário

2012 9

Modelo de Analise e Projeto A construção do modelo de análise e projeto é o

principal objetivo desta disciplina

O modelo de análise e projeto contém as realizações de casos de uso

Pode ser particionado em dois modelos Modelo de Analise

Modelo de Projeto

2012 10

Realização de Caso de Uso

Realização de Caso

de Uso

Caso de Uso

Diagramas de ColaboraçãoDiagramas de ColaboraçãoDiagramas de Classe Diagramas de Classe

Diagramas de SequênciaDiagramas de Sequência

Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto

Requisitos Analise e projeto

2012 11

Fluxo de Análise e Projeto

Diagrama de Atividades

2012 12

Realizar síntese da arquitetura

2012 13

Objetivo Construir e avaliar uma prova de conceito arquitetural

Mostrar que existe uma solução possível de satisfazer os requisitos do sistema relevantes à arquitetura

2012 14

Definir a arquitetura candidata

2012 15

Objetivo Criar o esqueleto inicial da arquitetura do sistema

Identificar classes de análise dos casos de uso arquiteturalmente relevantes

Atualizar a realização de caso de uso com as interações entre classes de análise

2012 16

Analisar comportamento

2012 17

Objetivo Transformar as descrições sobre o comportamento

providas pelos caso de uso em um conjunto de elementos nos quais o modelo de projeto vai se basear

2012 18

Projetar componentes

2012 19

Objetivo Refinar as definições dos elementos acrescentado

detalhes sobre como estes elementos implementam o comportamento requerido

Refinar e atualizar as realizações de casos de uso com os novos elementos identificados

2012 20

Projetar Banco de Dados

2012 21

Objetivo Identificar classes persistentes no modelo de projeto

Projetar as estruturas de banco de dados (Modelo de dados)

Definir mecanismos e estratégias para armazenar e recuperar dados

2012 22

Refinar Arquitetura

2012 23

Objetivo Permitir uma transição entre os elementos e

mecanismos de análise para os de projeto

Manter a consistência e integração da arquitetura

Descrever a arquitetura de execução e produção da aplicação

2012 24

Simplificando/Instanciando o processo para um contexto específico

Motivação O RUP é um Framework

Genérico e complexo demais, pois visa atender todos os tipos de projetos de desenvolvimento de software

Toda disciplina do RUP deve ser analisada e customizada de acordo com as necessidades específicas do projeto antes de sua implantação

2012 26

Passos da Atividade de Análise Identificar as classes

Identificar persistência

Identificar responsabilidades das classes

Identificar relacionamentos

Identificar atributos

2012 27

Fluxo de atividades simplificado

1. Analisar Caso de Uso

2. Analisar Arquitetura

3. Projetar Classes

4. Projetar Banco de Dados

2012 28

Objetivos Identificar as classes que executam o fluxo de eventos

do caso de uso

Distribuir o comportamento do caso de uso nestas classes

Identificar atributos, responsabilidades e associações das classes

2012 30

Passos para Analisar Caso de Uso Para cada caso de uso:

1. Encontrar classes de análise

2. Distribuir comportamento entre as classes

Para cada classe:

3. Descrever responsabilidades

4. Descrever atributos e associações

5. Qualificar mecanismos de análise

2012 31

Passo 1: Encontrar classes de análise O comportamento do caso de uso é distribuído em

classes de análise

2012 32

O que são classes de análise? Representam o conceito mais abstrato dos elementos do sistema

Primeiro passo concreto até chegar em um sistema executável

Categorização temporária São convertidas para classes de projeto

Servem para diminuir o gap entre os requisitos e projeto

Podem ser dos seguintes tipos Fronteira (<<boundary>>)

Controle (<<control>>)

Entidade (<<entity>>)

2012 33

Classes de Fronteira Utilizada para modelar a interação entre um ator e o

sistema

Para cada interação entre um ator e caso de uso, é criada uma classe de fronteira

Possuem o estereótipo <<boundary>>

2012 34

Classes de Fronteira Itermediam a interface para qualquer coisa externa ao

sistema

Exemplos de classes fronteira

GUI

Interface com outros sistemas

Interface com dispositivos

Uma classe de Fronteira por interação ator X caso de uso

<<boundary>>

Notação em UML

2012 35

O Papel de uma Classe de Fronteira

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Modela interação entre o sistema e seu ambiente

2012 36

Exemplo de classes de fronteira

Matricular-se Em disciplina Estudante Sistema

Academico

<<boundary>> FormRegistroCursos

<<boundary>> SistemaAcademico

2012 37

Classes de Entidade Utilizadas para modelar a informação manipulada

pelo sistema

Podem ser persistentes ou não

Conceito análogo às entidades dos diagramas ER

São identificadas a partir do fluxo de eventos do caso de uso

Possuem o estereótipo <<entity>>

2012 38

Classes de Entidade Abstrações chave dos casos de uso

<<entity>>

Glossário

Descrição do

Caso de uso

<<entity>>

<<entity>>

2012 39

O Papel de uma Classe de Entidade <<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Armazenam e gerenciam informação no sistema

2012 40

Exemplo de classes de entidade

<<entity>> Estudante

<<entity>> Curso

<<entity>> Horario

2012 41

Classes de Controle Classes responsáveis por controlar o fluxo de

execução do caso de uso

Normalmente é criada uma classe de controle para cada caso de uso

Possuem o estereótipo <<control>>

2012 42

Classes de Controle Coordenam o comportamento (lógica de controle) do

caso de uso

Interface entre fronteira e entidade

<<control>>

2012 43

O Papel de uma Classe de Controle

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Usuário

Coordenam o comportamento do caso de uso

2012 44

Exemplo de Classe de Controle

Matricular-se Em disciplina Estudante Sistema

Academico

<<control>> ControladorMatricula

matricurlarAluno()

2012 45

registrar faltas

registrar súmulas

das aulas

Professor

consultar freqüência

Aluno

editar alunos remover alunos

adicionar turma

remover turma

editar turma

Servidor de e-mailadicionar alunos

Secretária

Usuarioefetuar login

Exemplo

2012 46

Exemplo Efetuar Login

Fluxo de eventos:

1. Usuário informa login e senha

2. Sistema checa se o login e senha conferem

3. Sistema registra a sessão do aluno e a tela principal do sistema é exibida

2012 47

Exemplo Que classes preciso criar?

uma classe de fronteira para lidar com a interação dos atores com o sistema

uma classe de entidade para representar as informações relevantes do aluno

uma classe de controle para gerenciar o fluxo de execução do caso de uso

2012 48

Exemplo

ControladorLogin UsuarioTelaLogin

ControladorLogin

<<control>>

Usuario

<<entity>>

TelaLogin

<<boundary>>

Há diferentes opções de visualização dos estereótipos. A opção padrão é mostrada acima - os estereótipos são visualizados através da mudança dos ícones das classes. Há também a opção de se visualizar os estereótipos do modo convencional (<<estereótipo>>).

2012 49

Persistência Mas caso alguma classe de entidade precise ser

persistente?

Que classe será responsável por realizar as tarefas de persistência?

Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>>

2012 50

Exemplo

TelaLogin

<<boundary>>

CadastroUsuarios

<<entity collection>>

ControladorLogin

<<control>>

Usuario

<<entity>>

2012 51

Passo 2: Distribuir comportamento Para cada fluxo de eventos

Identificar classes de análise participantes

Alocar responsabilidades do caso de uso às classes de análise

Modelar interações entre as classes através dos diagramas de interação

2012 52

Distribuindo comportamento entre as classes

Caso de uso

Diagrama de seqüência Diagrama de colaboração

Classes de análise

Classes de análise com

responsabilidades

2012 53

Alocando responsabilidades Use estereótipos de análise como guia

Classes de fronteira

Comportamento que envolve comunicação com um ator

Classes de entidade

Comportamento que envolve informação encapsulada na abstração

Classes de controle

Comportamento específico ao (lógica de controle do) caso de uso

2012 54

Guia: Alocando responsabilidades Quem tem a informação necessária para realizar a

responsabilidade

isso pode envolver apenas uma classe, mas pode ser preciso criar novas classes ou relacionamentos entre classes

2012 55

Modelando interações Diagramas de interação (colaboração e seqüência)

modelam interações do sistema com seus atores

A interação é iniciada por um ator e envolve instâncias (objetos) das classes

Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes, responsabilidades e

relacionamentos

Mecanismo de validação da arquitetura

2012 56

Vários diagramas podem ser necessários

2012 57

Anatomia de um Diagrama de Seqüência

:Cliente :Fornecedor

Objetos

Linha da vida

1: Solicita serviço

1.1: Solicita outro serviço

Mensagem reflexiva

Foco do controle Numeração

hierárquica

Mensagem

2012 58

Exemplo de diagrama de Seqüência

: Aluno janela de

matrícula controle de

matrícula

mat 101

1: preenche info

2: submete

3: ad curso(Jose, mat 101)

4: ad(Jose)

5: curso aberto?

6: ad(Jose)

mat 101

section 1

2012 59

Diagrama de Colaboração

:Cliente :Fornecedor

Objetos

Mensagem

1: Solicita serviço

Ligação

2012 60

Exemplo de diagrama de colaboração

: Secretaria

janela de curso :

JanelaCurso

gerenciador :

GerenciadorCurriculo

curso :

Curso

1: informação do curso

2: processa

3: adiciona curso

4: novo curso

2012 61

Exemplo

: usuário : TelaLogin : ControladorLogin : CadastroAlunos

efetuarLogin(login, senha)

efetuarLogin(login, senha)

checar(login, senha)

registrarSessao()

2012 62

Colaboração X Sequência Colaboração

Mostra os relacionamentos, além das interações

Melhor para visualizar a colaboração

Melhor de ser usado em reuniões

Sequência

Mostra a sequência explicíta de mensagens

Melhor para visualizar o fluxo

Melhor para cenários complexos

2012 63

Passo 3: Descrever Responsabilidades Atualizar os diagramas de classes com as

responsabilidades identificadas no de iteração

Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras

2012 64

Como fazer?

:Cliente :Fornecedor

// Executar responsabilidade

Fornecedor

// Executar responsabilidade

diagrama de

classe

diagrama de

interação

2012 65

Classes com métodos

66 2012

Passo 4: Descrever atributos e associações

Definir atributos

Estabelecer agregações e associações

2012 67

Identificando Atributos Também é necessário identificar quais os atributos

das classes

Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade

Nesta etapa ainda não precisamos indicar quais os tipos dos atributos

2012 68

Encontrando Atributos Possíveis fontes: conhecimento do negócio, requisitos, glossário,

modelo do negócio, etc.

São propriedades/características das classes identificadas

informação de propriedade exclusiva do objeto

informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor

Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe

2012 69

Identificando relacionamentos As classes identificadas não funcionam

isoladamente, elas se relacionam com as demais classes

Os diagramas de interação são muito úteis nesta tarefa

Para cada ligação presente nos diagramas de interação, é necessário um relacionamento no diagrama de classes

2012 70

Encontrando Relacionamentos

Interações entre objetos nos diagrama de interação pode indicar a necessidade de definir um relacionamento entre as classes

Adicionar os elementos de um relacionamento Tipo e nome

Navegabilidade

Multiplicidade

Papéis

2012 71

Encontrando Relacionamentos

:Client :Supplier

Link

Supplier

PerformResponsibility()

Diagrama

de classe

Diagrama de

Colaboração

Association

Client Supplier

Client

1: PerformResponsibility

Prime suppliers

0..* 0..*

2012 72

Diagrama final

2012 73

Gerenciando a consistência Classes com responsabilidades similares são

candidatas a serem combinadas

Uma classe com responsabilidades disjuntas é candidata a ser dividida

Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas

2012 74

Passo 5: Qualificar mecanismos de análise

Mapear classes de análise em mecanismos de análise

Classes de análise Mecanismos de análise

Estudante Persistente

ControladorMatricula Distribuição, Segurança

Curso Persistente, Interface Legado

2012 75

Passo 6: Unificar classes de análise

Realização de Caso

de Uso

Diagramas de Classe Diagramas de Classe

…

Realização de Caso

de Uso

Diagramas de Classe Diagramas de Classe

…

Realização de Caso

de Uso

Diagramas de Classe Diagramas de Classe

…

Diagramas de Classe Diagramas de Classe

2012 76

Analisar Arquitetura Esforço inicial em definir as partes do sistema e seus

relacionamentos (Arquitetura Inicial)

Definir as convenções de modelagem

Identificar os mecanismos de análise

Identificação das abstrações-chave

2012 78

Arquitetura Inicial Quais as principais partes do sistema?

Como elas interagem entre si?

Que padrões arquiteturais utilizar (no todo ou internamente nas partes) ?

MVC

Baseado em camadas

Canais e filtros

Centrado em repositório

2012 79

Exemplo de arquitetura inicial

Interface Gráfica

Negócio

Dados

Módulo de Vendas

Módulo de Estoque

Socket

2012 80

Convenções de modelagem O que são?

Que diagramas e elementos de modelagem utilizar

Definir as regras para utilização desses componentes

Convenções de nome

Exemplos Casos de uso devem ser nomeados como ações (Cadastrar

usuário)

Cada realização de caso de uso deve conter:

Um diagrama de classes

No mínimo um diagrama de seqüência representando o fluxo principal de ações

2012 81

Mecanismos de análise O que são?

Focam nos requisitos não-funcionais do sistema

Decisão estratégica sobre padrões, politicas e práticas a serem utilizadas no projeto

Exemplos

Persistência

Comunicação

Gerenciamento de transações

Segurança

2012 82

Identificar Abstrações-chave Definir classes de análise preliminares

Conhecimento do domínio

Requisitos

Outros artefatos (Glossário e modelo de negócio)

2012 83

Objetivo Detalhar as partes do sistema

Concretização dos conceitos definidos até o momento Detalhes de implementação e ambiente de produção

Produtos utilizados

Linguagem de programação

Distribuição

Performance

Restrições físicas

2012 85

Passos do projeto de classes

1. Criar classes de projeto

2. Identificar classes persistentes

3. Definir métodos

4. Definir atributos

5. Definir estados

6. Definir relacionamentos

7. Contemplar os requisitos não-funcionais

Para cada classe:

2012 86

Passo 1: Criar classes de projeto Converter classes de análise (Fronteira, Controle e

Entidade) em classes de projeto

Padrões de projeto podem ser incorporados

As classes são refinadas para incorporar os mecanismos arquiteturais

2012 87

Projetando classes de fronteira GUI (Graphical User Interface)

Que ferramenta de desenvolvimento de interface gráfica será utilizada?

Quant pode ser criada pela ferramenta?

Que padrões serão utilizados?

Sistemas Externos

Que tecnologias/mecanismos de integração?

Que padrões?

Projetar como um subsistema…

2012 88

Projetando classes de entidade Classes de Entidade são

Transitórias

Persistentes

São detalhadas no passo “Identificar classes persistentes”

2012 89

Projetando classes de controle Decisões que deve ser tomadas:

Elas são realmente necessárias?

Elas podem/devem ser agrupadas?

Como decidir?

Complexidade

Operações relacionadas

Probabilidade de mudar

Performance e distribuição

2012 90

Passo 2: Identificando classes persistentes Instancias da classe precisam preservar o seu estado

Estratégia de persistencia é definida para cada classe persistente

Curso BD Relacional

Candidato Arquivo

JDBC

Serialização

2012 91

Passo 3: Definir Métodos Tem como propósito mapear responsabilidades

identificada na análise para métodos na classe

Deve-se considerar

Nome, assinatura e visibilidade dos métodos

2012 92

Mapeando operações

:Fornecedor :Cliente

// Realizar alguma operação

:Fornecedor :Cliente

fazerAlgo()

Projeto

Análise

+ concreto

- concreto

2012 93

Passo 4: Definir Atributos Tem como propósito formalizar a definição dos

atributos

Deve-se considerar

Persistência

Visibidade, nome, tipo e valor inicial

2012 94

Passo 5: Definir estado Tem como objetivo definir como o objeto se comporta

Relevante apenas para objetos com ciclo de vida complexo

Pode ser especificado em UML

Diagrama de estados

Diagrama de atividades

2012 95

Diagrama de Estados Um diagrama de estados mostra o ciclo de vida de um

objeto

Nome do estado

Variavel: Tipo = valor

Ação de entrada Ação de saída

Atividade

Evento(args)

[condição]

/ Operacao(args)

^obj.enviarMensagem(args) Estado

Ações

Atividades Transição

2012 96

Exemplo de diagrama de estado

Inicializado Aberto

Fechado

Cancelado

do: Incializa Curso

do: Finaliza curso

do: Notifica Alunos

Adiciona Aluno / contador = 0

Adiciona Aluno[ contador < 10 ]

[ contador = 10 ]

Cancela

Cancela

Cancela

2012 97

Passo 6: Definir Relacionamentos

Dependências

Associações

Simples

Agregação

Composição

Generalização

2012 98

Passo 7: Contemplar os requisitos não-funcionais Concretização dos mecanismos de análise

Incorporar responsabilidades em algumas classes

Criar novas classes

Exemplos: Segurança Como armazenar as senhas? Que algoritmo

usar para criptografar uma mensagem?

Distribuição Que tecnologia utilizar? Qual o impacto da tecnologia nos objetos já definidos?

Tratamento de logs Que tipo de operações deve ter log (Acesso a dados, execução de negócio, …)

2012 99

2012 100

Projetar Banco de Dados

Mapear as classes persistentes em conceitos do Banco de Dados

Definir os tipos de dados mais adequados para o BD

Normalizar se necessário

2012 101