21 Arquitetura de Software

(1)

Arquitetura de

So-ware – Parte I

Centro de Informá-ca -‐ Universidade Federal de Pernambuco Sistemas de Informação

Vinicius Cardoso Garcia [email protected]

Slides originais elaborados por Ian Sommerville

(2)

PROJETO DE ARQUITETURA DE

SOFTWARE

(3)

Leitura complementar

Len Bass, Paul Clements, Rick Kazman

SoPware Architecture in Prac-ce, 2nd_Edi-on

Capítulos 1, 2 e 3

(4)

(5)

Programação Modular

(6)

Programação Modular

Implementação

(7)

Programação Modular

Implementação Interface Provida Interface Requerida

(8)

Programação Modular

Implementação Interface Provida Interface Requerida Visível apenas dentro do Módulo

(9)

BeneCcios Esperados da Programação

Modular [Parnas, 1972]

•  _{Tempo
de
desenvolvimento
encurtado,
já
que} grupos de desenvolvimento separados podem trabalhar em módulos dis-ntos, com pouca

necessidade de comunicação

•  _{Possibilidade
de
aplicar
mudanças
drás-cas
a} um módulo sem a necessidade de mudar

outros

•  _{Possibilidade
de
estudar
o
sistema
olhando} para um módulo de cada vez

(10)

Arquitetura de So-ware

•  _A_estrutura_{de
um
sistema
de
soPware,
que} engloba

– componentes de soPware;

– suas propriedades visíveis externamente;

– e os relacionamentos e interações entre eles

•  _{As
primeiras}_decisões_{tomadas
no}_projeto_de um sistema

– As mais importantes!

•  _{Uma
arquitetura
de
soPware
é
composta
por}

(11)

Arquitetura em Camadas

Clientes web (Mozilla, IE, etc.)‏

Servidor WEB Local Rede

Banco de Dados Relacional Internet

(12)

Arquitetura em Camadas

Componente Componente Componente

Clientes web (Mozilla, IE, etc.)‏

Servidor WEB

Internet Rede

Local

Banco de Dados Relacional

(13)

Arquitetura em Camadas

Banco de Dados Relacional Conector (Ponte SQL)‏ Conector (HTTP, RMI)‏ Clientes web (Mozilla, IE, etc.)‏

Servidor WEB Local Rede

(14)

Projeto Arquitetural

•  _{O
processo
de
projeto
que
estabelece}

– Os subsistemas que cons-tuem um sistema

– A maneira como esses componentes interagem

•  _{Incluindo
algumas
decisões
tecnológicas}

– Ex. Plataforma de componentes, SGBD

•  _{A
saída
desse
processo
de
projeto
é
uma} descrição da arquitetura de so-ware. •  _{A
arquitetura
de
soPware
lida
com
os}

(15)

Projeto Arquitetural

•  _{É
o
primeiro
estágio
do
projeto
do
sistema} •  Representa a ligação entre os processos de

especiﬁcação e de projeto

•  É freqüentemente conduzido em paralelo com algumas a-vidades de especiﬁcação

– Às vezes junto com a elicitação de requisitos

•  _{Envolve
a
iden-ﬁcação
dos
componentes} principais do sistema e sua interação

(16)

Vantagens de uma Arquitetura

Explícita

•  _{Comunicação
com
os
stakeholders}

– A arquitetura pode ser usada como um foco de discussão pelos stakeholders do sistema.

•  _{Análise
de
sistema}

– Se há possibilidade de o sistema atender a seus requisitos de qualidade (não-‐funcionais)

•  _{Reuso
em
larga
escala}

– A arquitetura pode ser reusável em uma variedade de sistemas

(17)

Conﬂitos de Arquitetura

•  O uso de componentes de alta granularidade

aprimora o desempenho mas diminui a facilidade

de manutenção

•  A introdução de dados redundantes aprimora a disponibilidade, mas torna a proteção mais diCcil

–  E cria diﬁculdades para tornar o sistema conﬁável em outras partes

•  Localizar as funcionalidades crí-cas de segurança em poucos locais pode criar gargalos de

desempenho

(18)

Decisões de Projeto

•  Projeto de arquitetura é um processo criativo

–  Cada sistema envolve diferentes decisões/ requisitos/conflitos/restrições

–  Envolve solucionar os problemas representados pelos requisitos

•  Decisões de projeto:

–  Escolhas feitas durante o projeto de um sistema –  Afetam sua capacidade de fornecer seu serviço –  Normalmente resultam em compromissos

–  É importante avaliar as opções existentes –  Não estão restritas ao projeto arquitetural!

(19)

Exemplos de Decisões de Projeto

•  Como representar o mapa em um sistema que traça rotas percorridas por ônibus de modo a minimizar o trabalho da equipe?

•  Como garan-r a conﬁabilidade de um servidor a um baixo custo?

•  Qual a maneira mais eﬁciente de se construir uma grade de horários levando-‐se em conta as várias restrições impostas por professores, diretores e regras departamentais?

•  Qual a melhor tecnologia para se construir uma ferramenta de análise de programas?

•  Como a arquitetura do sistema deve ser documentada?

(20)

Caracterís`cas de um Sistema que

decorrem de sua Arquitetura

•  Desempenho

–  Localizar operações crí-cas e minimizar comunicações. Usar componentes de alta ao invés de baixa granularidade.

•  Proteção (security)

–  Usar uma arquitetura em camadas com itens crí-cos nas camadas mais internas.

•  Segurança (safety)

–  Localizar caracterís-cas crí-cas de segurança em um pequeno número de subsistemas.

•  Disponibilidade

–  Incluir componentes redundantes e mecanismos para tolerância à falhas.

•  Facilidade de manutenção

(21)

Representação de Arquiteturas

•  Arquiteturas são um ativo importante no desenvolvimento

– Podem ser a diferença entre o sucesso e o fracasso

•  Representá-las é importante

– Torna possível “falar” sobre ela

– O projeto de arquitetura é normalmente expresso como um diagrama de blocos

•  Modelos mais específicos também podem ser desenvolvidos.

(22)

Sistema de controle robo`zado de

empacotamento

(23)

Diagramas caixa e linha

•  Muito abstrato – não mostram a natureza

dos relacionamento de componentes, nem suas propriedades externamente visíveis •  Contudo, são úteis para comunicação com

os stakeholders e para planejamento de projeto.

•  Alternativas:

– Notações formais

(24)

Visões Arquiteturais

•  A arquitetura de um sistema software

normalmente é representada através de várias visões

•  Visões são maneiras diversas de se enxergar uma mesma arquitetura

– Enfocando diferentes aspectos de interesse

– Ex.: as várias plantas de uma casa

•  Arquiteturas de software são

especificadas através de uma ou mais de suas visões

(25)

Correio Eletrônico – Visão 1

•  Três principais elementos:

–  agentes de usuário (UA). –  servidores de correio. –  simple mail transfer

protocol: SMTP. caixa de correio do usuário fila de mensagens de saída agente de usuário servidor de correio SMTP SMTP agente de usuário agente de usuário agente de usuário agente de usuário servidor de correio servidor de correio POP3/IMAP

(26)

Correio Eletrônico – Visão 2

1)  Alice usa o UA para compor uma mensagem “para”

[email protected] 2)  O UA de Alice envia a

mensagem para o seu servidor de correio; a mensagem é

colocada na ﬁla de mensagens. 3)  O lado cliente do SMTP abre

uma conexão TCP com o servidor de correio de Bob.

4)  O cliente SMTP envia a

mensagem de Alice através da conexão TCP.

5)  O servidor de correio de Bob coloca a mensagem na caixa de entrada de Bob.

6)  Bob chama o seu UA para ler a mensagem. user agent mail server mail server user agent 1 2 ₃ 4 ₅ 6

(27)

Correio Eletrônico – Visão 3

Fonte: Axigen Mail Server Documentation - Mail Server Architecture. Consultado em 24 de março de 2008

(28)

Um Exemplo de Sistema de

Controle de Tráfego Aéreo

M&C Console G.A.M Local/Group A.M. ATC Console A.S.O.U O/S E. A. S.

Network Operating System

Processor I/O Devices

Attachments Exceções Exceções Exceções Exceções Exceções

Fonte: Bass, Clements, and Kazman, Software Architecture in Practice, 2nd_{Edition, 2003.}

(29)

Sobre Visões

•  Algumas são genéricas

– Lógica

– De interação

– Física ou de Alocação

•  As três acima deverão ser entregues no projeto da disciplina

•  Outras servem a fins específicos

(30)

Reuso de arquitetura

•  Sistemas do mesmo domínio freqüentemente têm arquiteturas similares que refletem os

conceitos de domínio

–  Resultam em decisões de projeto similares •  Linhas do produto de software são

construídas em torno de um núcleo de arquitetura

–  Variantes satisfazem requisitos de cada cliente.

•  Reuso de arquiteturas é capturado através

da noção de padrões ou estilos

(31)

DOCUMENTANDO ARQUITETURAS

DE SOFTWARE

Slides originais elaborados pelo prof. Fernando Castor

(32)

Warm up

•  Projeto (design) de alto nível de um sistema de software •  Meio através do qual um sistema torna-se capaz de

satisfazer diversos requisitos:

–  Segurança

–  Disponibilidade –  Escalabilidade –  Desempenho

•  Normalmente representadas através de diversas visões

–  Cada uma enfatiza diferentes características do sistema

(33)

Documentação de Arquiteturas

•  Documenta-se visões

–  Não se documenta a arquitetura “inteira”

•  A escolha das visões a documentar depende

–  Da informação que se deseja documentar/ comunicar

–  Das análises que serão feitas

–  De quem usará a documentação –  Do objetivo de se documentar

•  Também é preciso analisar o grau de detalhe

necessário

(34)

Usos de Documentação Arquitetural

•  Arquitetos e engenheiros de requisitos:

–  Negociar trade-offs entre requisitos conflitantes

•  Arquiteto e projetistas das partes:

–  Resolver disputas por recursos e estudar desempenho esperado

e outras características relativas ao consumo de recursos

•  Implementadores:

–  Definir restrições que precisam ser respeitadas por atividades

subsequentes de desenvolvimento

•  Testadores:

–  Estabelecer o comportamento caixa-preta das partes que

precisam trabalhar juntas

•  Desenvolvedores de outros sistemas:

(35)

Usos de Documentação Arquitetural

•  Especialistas em qualidade:

–  Prover modelos analíticos que permitam a análise (semi-)

automatizada da arquitetura

•  Gerentes:

–  Quebrar a equipe de desenvolvimento em termos de módulos

arquiteturais de alta granularidade

•  Responsáveis por manutenção:

–  Entender o impacto de uma mudança

•  Gerentes de linhas de produtos:

–  Determinar se um novo membro de uma família de produtos

está ou não dentro do escopo da linha

•  Novo arquiteto

(36)

Como Documentar Arquiteturas

•  Três passos simples:

1. Escolher as visões relevantes

2. Documentar as visões escolhidas

3. Documentar informação que se aplica a mais de uma visão

(37)

Tipos de Visão Arquitetural

•  Em geral, visões descrevem um entre três

aspectos complementares de um sistema

– Como ele é dividido em unidades de

implementação

– Como ele é estruturado em unidades que têm

comportamento e interações em tempo de execução

– Como ele se relaciona a elementos externos

(38)

Tipos de Visão Arquitetural

•  Em geral, visões descrevem um entre três

aspectos complementares de um sistema

–  Como ele é quebrado em unidades de implementação => MÓDULOS

–  Como ele é estruturado em unidades que têm

comportamento e interações em tempo de execução

=> COMPONENTES E CONECTORES

–  Como ele se relaciona a elementos externos que não sejam software => ALOCAÇÃO

(39)

Exemplos de Visões

•  Visões de Módulos: – Decomposição hierárquica – Classes – Camadas •  Componentes e conectores – Interação/Clientes e Servidores – Processos •  Alocação – Implantação/Física – Quebra de trabalho

(40)

Documentando

(41)

Documentando

Visões

Seções

relevantes para o projeto

(42)

Seções

relevantes para o projeto

Documentando

Visões

O conteúdo destas seções depende da visão documentada O conteúdo destas

seções depende diretamente da visão documentada

(43)

Documentando Visões de

Módulos

•  Camadas:

–  Diagramas de blocos (na UML => pacotes) mostrando os pontos

de interação entre as camadas

•  Classes

–  Diagramas de classes da UML

•  Decomposição hierárquica

–  Diagramas de pacotes da UML

•  Cada pacote representando um sub-sistema/componente

arquitetural

•  Relacionando cada componente arquitetural com os sub-sistemas

que o compõem

(44)

Documentação de

Comportamento

•  Sequências de mensagens na interação

entre dois ou mais elementos em tempo de execução

–  Diagramas de interação da UML: sequência e

colaboração

•  Estados do sistema e de seus componentes

–  Statecharts

–  Incluem as transições que levam de um estado

para outro

–  Verificação automática

(45)

(46)

(47)

Escolhas de Projeto

(Design Rationale)

•  Rationale => justificativas para as escolhas

•  Mostram como a arquitetura inteira soluciona os

problemas propostos pelos requisitos

•  Ajudam a explicar questões como as seguintes:

–  Como o sistema satisfaz seus requisitos?

–  Como a arquitetura pode ser afetada pela adição de

novas funcionalidades?

–  Que restrições são impostas sobre desenvolvedores

implementando a solução?

(48)

(49)

(50)

(51)

(52)

(53)

Visão e Alocação / Implantação

•  Diagramas de Implantação mostram a alocação

dos componentes de soPware do sistema aos elementos de hardware

•  Incluem os protocolos de interação entre as partes do sistema

•  Podem também indicar informações adicionais,

como:

–  Ambientesdeexecução(comomáquinasvirtuaise servidores de aplicação)

–  Sistemasoperacionais –  Tecnologias especíﬁcas

(54)

Diagramas de Implantação: Ex. 1

17/4/2012

4

Slide 19/72

UML: Visão de Módulos

Slide 20/72

UML: Visão de Módulos

Slide 21/72

UML: Visão de Interação

Slide 22/72

UML: Visão de Alocação

• Diagramas de Implantação mostram a alocação dos componentes de software do sistema aos elementos de hardware

• Incluem os protocolos de interação entre as partes do sistema

• Podem também indicar informações adicionais, como:

• Ambientes de execução (como máquinas virtuais e servidores de aplicação) • Sistemas operacionais • Tecnologias específicas Slide 23/72

Diagramas de Implantação:

Exemplo 1

Slide 24/72

Diagramas de Implantação:

Exemplo 2

54

(55)

(56)

CRIAÇÃO DO MODELO DE ANÁLISE NO

OPENUP – ANÁLISE DE CASOS DE USO

(57)

Contexto

•  _{Com
base
nos
casos
de
uso,
queremos
agora} gerar um primeiro modelo de arquitetura do sistema.

(58)

Contexto

58

[if977] Engenharia de SoPware -‐ SI -‐ CIn -‐ UFPE

17/4/2012

5

Slide 25/72

Criação do Modelo de Análise no

OpenUP – Análise de Casos de

Uso

Slide 26/72

Contexto

• Com base nos casos de uso, queremos agora gerar um primeiro modelo de arquitetura do

sistema.

• Este modelo é chamado de modelo de análise.

26/28

Slide 27/72

15/03/2005 27/28

Contexto

Requisitos Análise Projeto

Slide 28/72

15/03/2005 28/28

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

Slide 29/72

Análise no OpenUP

• A maneira como vamos realizar a etapa de análise se baseia no processo usado no

OpenUP

• 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

15/03/2005 29/28

Slide 30/72

Casos de Uso X Análise

!"#$#%&'%(#$ ")*+,#' -'#!.,/$#%)"%+,)0("0'1 &$%!+,')/' -'#!.,/$%)"%+,)0("0'1 &$#%&'#')2$+2'&$.'# 3,#4$%'5/'.)"%&$ #,#/'1" 3,#4$%,)/'.)"%&$%#,#/'1" 6"7/(."%"# 8()!,$)"+,&"&'#%&$ #,#/'1" 9$#/.":%&'%1$&$ ";#/."/$:%!$1$%" 8()!,$)"+,&"&'%7$&'%#'. .'"+,<"&" =#/.(/(."&$%7$.%!"#$# &'%(#$ =#/.(/(."&$%7$.%!+"##'#'%7"!$/'# 15/03/2005 30/28

(59)

A A`vidade de Análise

•  _{Vai
proporcionar
um
método
que
permita
que} criemos um modelo de classes do sistema a

par-r dos casos de uso

•  _{Trará
a
resposta
para
a
pergunta:}

– Quais classes preciso para implementar estes

(60)

Análise no OpenUP

•  _{A
maneira
como
vamos
realizar
a
etapa
de} análise se baseia no processo usado no

OpenUP

•  _{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

(61)

(62)

Passos da A`vidade de Análise

• _{Iden-ﬁcar
as
classes}

– 

Iden-ﬁcar persistência

• Iden-ﬁcar responsabilidades das

classes

• Iden-ﬁcar relacionamentos

• Iden-ﬁcar atributos

(63)

Iden`ﬁcando as classes

•  _{No
primeiro
passo
de
análise,
iden-ﬁcaremos} três -pos de classes:

– Fronteira

– En-dade

– Controle

•  _{Tais
classes
são
iden-ﬁcadas
separadamente} para cada de uso

(64)

Classes de Fronteira

•  _{U-lizada
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

(65)

Classes de En`dade

•  _{U-lizadas
para
modelar
a
informação} manipulada pelo sistema

•  Podem ser persistentes ou não

•  Conceito análogo às en-dades dos diagramas ER

•  _{São
iden-ﬁcadas
a
par-r
do
ﬂuxo
de
eventos} do caso de uso

(66)

Classes de Controle

•  _{Classes
responsáveis
por
controlar
o
ﬂuxo
de} execução do caso de uso

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

(67)

Exemplo

17/4/2012

6

Slide 31/72

15/03/2005 31/28

Passos da Atividade de Análise

• Identificar as classes

• Identificar persistência

• Identificar responsabilidades das classes • Identificar relacionamentos

• Identificar atributos

Slide 32/72

15/03/2005 32/28

Identificando as classes

• No primeiro passo de análise, identificaremos três tipos de classes:

• Fronteira • Entidade • Controle

• Tais classes são identificadas separadamente para cada de uso

Slide 33/72

15/03/2005 33/28

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

Slide 34/72

15/03/2005 34/28

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

Slide 35/72

15/03/2005 35/28

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

Slide 36/72 15/03/2005 36/28 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-mail adicionar alunos Secret ária Usuario efetuar login

Exemplo

67

(68)

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

(69)

Exemplo

•  _{Que
classes
preciso
criar?}

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

– uma classe de en-dade para representar as informações relevantes do aluno

– uma classe de controle para gerenciar o ﬂuxo de execução do caso de uso

(70)

Exemplo

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

(71)

Persistência

•  _{Mas
caso
alguma
classe
de
en-dade
precise} ser persistente?

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

•  _{Para
cada
classe
de
en-dade
que
precise
ser} persistente, é criada uma nova classe com o estereó-po <<en-ty collec-on>>

(72)

Exemplo

72

17/4/2012

7

Slide 37/72

15/03/2005

37/28

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

Slide 38/72

15/03/2005

38/28

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

Slide 39/72

15/03/2005

39/28

Exemplo

ControladorLogin Usuario TelaLogin ControladorLogin < < c ontrol> > Us uario < < 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>>).

Slide 40/72

15/03/2005

40/28

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

Slide 41/72

15/03/2005

41/28

Exemplo

TelaLogin <<boundary>> CadastroUsuarios <<entity collection>> ControladorLogin <<control>> Usuario <<entity>> Slide 42/72

15/03/2005

42/28

Diagramas de interação

• Após a identificação das classes, é necessário

descobrir quais são as responsabilidades de

cada classe, o que cada uma precisa fazer.

• Os diagramas de interação (seqüência e

(73)

Diagramas de interação

•  _{Após
a
iden-ﬁcação
das
classes,
é
necessário} descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer.

•  _{Os
diagramas
de
interação
(seqüência
e} colaboração) são muito úteis nesta tarefa

(74)

Exemplo

17/4/2012

8

Slide 43/72 15/03/2005 43/28

Exemplo

: usuário : TelaLogin : Con trolado rLogin : CadastroA lunos

efetuarLogin(login, senha)

efetua rLogin(log in, se nha)

checar(login, senh a)

registrarS essao()

Slide 44/72

15/03/2005 44/28

Alocando responsabilidades

• Após identificarmos as responsabilidades

(métodos) pelos diagramas de interação,

devemos acrescentar os métodos nas classes previamente identificadas (1º passo)

Slide 45/72

15/03/2005 45/28

Classes com métodos

TelaLogin

efetuarLogin(login, senha) <<boundary>>

CadastroUsuarios

checar(login, senha) <<entity collec tion>>

ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> Usuario <<entity>> Slide 46/72 15/03/2005 46/28

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

Slide 47/72

15/03/2005 47/28

Classes com relacionamentos

Usuario <<entity>> TelaLogin

efet uarLogin(login, senha) <<boundary>> ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> 1 * CadastroUsuarios checar(login, senha) <<enti ty collec tion>> ₁

1 * ₁ 1 1 Slide 48/72 15/03/2005 48/28

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

74

(75)

Alocando responsabilidades

•  _{Após
iden-ﬁcarmos
as
responsabilidades} (métodos) pelos diagramas de interação,

devemos acrescentar os métodos nas classes previamente iden-ﬁcadas (1º passo)

(76)

Classes com métodos

17/4/2012

8

Slide 43/72

15/03/2005

43/28

Exemplo

registrarS essao()

Slide 44/72

15/03/2005

44/28

Alocando responsabilidades

• Após identificarmos as responsabilidades

(métodos) pelos diagramas de interação,

devemos acrescentar os métodos nas classes

previamente identificadas (1º passo)

Slide 45/72

15/03/2005

45/28

Classes com métodos

TelaLogin

CadastroUsuarios checar(login, senha) <<entity collec tion>>

ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> Usuario <<entity>> Slide 46/72

15/03/2005

46/28

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

Slide 47/72

15/03/2005

47/28

Classes com relacionamentos

1 * ₁ 1 1 Slide 48/72

15/03/2005

48/28

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

76

(77)

Iden`ﬁcando relacionamentos

•  _{As
classes
iden-ﬁcadas
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

(78)

Classes com relacionamentos

17/4/2012

8

Slide 43/72 15/03/2005 43/28

Exemplo

registrarS essao()

Slide 44/72

15/03/2005 44/28

Alocando responsabilidades

• Após identificarmos as responsabilidades

(métodos) pelos diagramas de interação,

devemos acrescentar os métodos nas classes

previamente identificadas (1º passo)

Slide 45/72

15/03/2005 45/28

Classes com métodos

TelaLogin

CadastroUsuarios checar(login, senha) <<entity collec tion>>

ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> Usuario <<entity>> Slide 46/72 15/03/2005 46/28

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

Slide 47/72

15/03/2005 47/28

Classes com relacionamentos

1 * ₁ 1 1 Slide 48/72 15/03/2005 48/28

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

78

(79)

Iden`ﬁcando Atributos

•  _{Também
é
necessário
iden-ﬁcar
quais
os} atributos das classes

•  Um bom conhecimento do domínio do

problema é bastante importante para esta tarefa, principalmente na iden-ﬁcação de atributos das classes de en-dade

•  Nesta etapa ainda não precisamos indicar quais os -pos dos atributos

(80)

Diagrama ﬁnal

17/4/2012

9

Slide 49/72

15/03/2005

49/28

Diagrama final

Usuario login senha <<entity>> TelaLogin efetuarLogin(login, senha) <<boundary>> ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> 1 * CadastroUsuarios checar(login, senha) <<entity collection>> ₁ 1 * ₁ 1 1 Slide 50/72

15/03/2005

50/28

Exemplo – adicionar aluno

Fluxo de eventos:

1. Secretária informa dados do aluno

2. Secretária seleciona a opção “confirmar cadastro” 3. Sistema checa se os dados são válidos

4. Sistema adiciona o aluno à base de dados

5. Sistema envia um e-mail para o aluno, informando-o seu login e senha

6. Sistema exibe uma mensagem de confirmação de cadastro

Secretária adicionar alunos Servidor de e-mail

Slide 51/72

09/12/2004

51/21

Exemplo – Análise adicionar aluno

Aluno nome em ail login senha Aluno() <<entity>> Email Email() <<entity>> TelaAdicionarAluno adicionarAluno() <<boundary>> Ca das troAlun os adicionarAl uno() <<entity collection>> ControladorAdicionarAluno adicionarAluno() <<control>> 1 1..* 1 1 ComunicacaoServidorEmail en via rEm ail ()

<<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 52/72

Modelo de Projeto – um

Refinamento do Modelo de

Análise

Slide 53/72

09/12/2004

53/21

Contexto

• Após a etapa de análise temos um primeiro

modelo do sistema

• Queremos agora melhorar esse modelo, a ponto

de gerarmos facilmente a implementação do

sistema

• Este modelo é chamado de modelo de Projeto

Slide 54/72

09/12/2004

54/21

Contexto

80

(81)

Exemplo: Adicionar Aluno

•  Fluxo de Eventos:

1.  Secretária informa dados do aluno

2.  Secretária seleciona a opção “conﬁrmar cadastro” 3.  Sistema checa se os dados são válidos

4.  Sistema adiciona o aluno à base de dados

5.  Sistema envia um e-‐mail para o aluno, informando-‐o seu login e senha

6.  Sistema exibe uma mensagem de conﬁrmação de cadastro

81

17/4/2012

9

Slide 49/72 15/03/2005 49/28

Diagrama final

Usuario login senha <<entity>> TelaLogin efetuarLogin(login, senha) <<boundary>> ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> 1 * CadastroUsuarios checar(login, senha) <<entity collection>> ₁ 1 * ₁ 1 1 Slide 50/72 15/03/2005 50/28

Exemplo – adicionar aluno

Slide 51/72

09/12/2004 51/21

Exemplo – Análise adicionar aluno

Aluno nome em ail login senha Aluno() <<entity>> Email Email() <<entity>> TelaAdicionarAluno adicionarAluno() <<boundary>> Ca das troAlun os adicionarAl uno() <<entity collection>> ControladorAdicionarAluno adicionarAluno() <<control>> 1 1..* 1 1 ComunicacaoServidorEmail

en via rEm ail () <<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 52/72

Modelo de Projeto – um

Refinamento do Modelo de

Análise

Slide 53/72 09/12/2004 53/21

Contexto

• Após a etapa de análise temos um primeiro modelo do sistema

• Queremos agora melhorar esse modelo, a ponto de gerarmos facilmente a implementação do

sistema

• Este modelo é chamado de modelo de Projeto

Slide 54/72

09/12/2004 54/21

Contexto

(82)

Exemplo: Adicionar Aluno

17/4/2012

9

Slide 49/72 15/03/2005 49/28

Diagrama final

Exemplo – adicionar aluno

Slide 51/72

09/12/2004 51/21

Exemplo – Análise adicionar aluno

<<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 52/72

Modelo de Projeto – um

Refinamento do Modelo de

Análise

Slide 53/72 09/12/2004 53/21

Contexto

sistema

Slide 54/72

09/12/2004 54/21

Contexto

82

(83)

MODELO DE PROJETO – UM REFINAMENTO DO MODELO DE ANÁLISE

(84)

Contexto

•  _{Após
a
etapa
de
análise
temos
um
primeiro} modelo do sistema

•  Queremos agora melhorar esse modelo, a ponto de gerarmos facilmente a

implementação do sistema

(85)

Contexto

17/4/2012

9

Slide 49/72 15/03/2005 49/28

Diagrama final

Exemplo – adicionar aluno

Slide 51/72

09/12/2004 51/21

Exemplo – Análise adicionar aluno

<<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 52/72

Modelo de Projeto – um

Refinamento do Modelo de

Análise

Slide 53/72 09/12/2004 53/21

Contexto

sistema

Slide 54/72

09/12/2004 54/21

Contexto

85

(86)

Análise X Projeto

•  _{Abstrato
X
Concreto}

•  Independente X dependente da tecnologia de implementação

•  Simples X detalhado

•  Modelos por caso de uso X uniﬁcação em um único modelo

(87)

A`vidades -‐ Projeto

•  _{Reﬁnar
o
modelo
de
classes} •  Projetar arquitetura

– Camadas

– Separação em pacotes

(88)

Reﬁnar o modelo de classes

•  _{Juntar
todas
as
classes
em
um
só
diagrama}

•  Analisar se é necessário criar novas classes ou remover classes existentes

•  Eliminar os estereó-pos de análise

•  Adicionar modiﬁcadores de visibilidade aos métodos e atributos

(89)

Exemplo – Análise login

89

17/4/2012

10

Slide 55/72 09/12/2004 55/21

Análise X Projeto

• Abstrato X Concreto

• Independente X dependente da tecnologia de

implementação

• Simples X detalhado

• Modelos por caso de uso X unificação em um

único modelo

Slide 56/72

09/12/2004 56/21

Atividades – Projeto

• Refinar o modelo de classes

• Projetar arquitetura

• Camadas

• Separação em pacotes

• Projetar Banco de Dados

Slide 57/72

09/12/2004 57/21

Refinar o modelo de classes

• Juntar todas as classes em um só diagrama

• Analisar se é necessário criar novas classes ou

remover classes existentes

• Eliminar os estereótipos de análise

• Adicionar modificadores de visibilidade aos

métodos e atributos

• Definir os tipos dos atributos

Slide 58/72

09/12/2004 58/21

Exemplo – Análise login

Usuario logi n senha <<entity>> TelaLogin efetuarLogin(login, senha) <<boundary>> CadastroUsuarios checar(login, senha) <<entity collection>> ControladorLogin efetuarLogin(login, senha) registrarSessao() <<control>> 1 * ₁ * 1 1 1 1 Slide 59/72 09/12/2004 59/21

Exemplo – Análise adicionar aluno

Aluno nome em ail login senha Aluno() <<entity>> Email Email() <<entity>> TelaAdicionarAluno adicionarAluno() <<boundary>> Ca das troAlun os adicionarAl uno() <<entity collection>> ControladorAdicionarAluno adicionarAluno() <<control>> 1 1..* 1 1 ComunicacaoServidorEmail

en via rEm ail ()

<<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 60/72 09/12/2004 60/21

Exemplo – diagrama único

TelaLogin efet uarLogin() TelaAdicionarAluno adicionarAluno() CadastroUsuarios checar() ControladorLogin efetuarLogin() registrarSessao() * 1 * 1 1 1 1 1 CadastroAlunos adicionarAluno() ComunicacaoServidorEmail

envi arEm ail()

ControladorA dic ionarAluno adicionarAluno() 1..* 1 1..* 1 1 1 1 1 1 1 1 1 Email Email() Aluno nome : String email : String login : String senha : String Aluno() Usuario logi n : St ri ng senha : St ri ng Email assunt o : S tring remetente : String destinat ari o : String corp o : String Emai l()

(90)

Exemplo – Análise adicionar aluno

17/4/2012

10

Slide 55/72 09/12/2004 55/21

Análise X Projeto

• Abstrato X Concreto

• Independente X dependente da tecnologia de implementação

• Simples X detalhado

• Modelos por caso de uso X unificação em um único modelo

Slide 56/72

09/12/2004 56/21

Atividades – Projeto

• Refinar o modelo de classes • Projetar arquitetura

• Camadas

• Projetar Banco de Dados

Slide 57/72

09/12/2004 57/21

Refinar o modelo de classes

• Juntar todas as classes em um só diagrama

• Analisar se é necessário criar novas classes ou remover classes existentes

• Eliminar os estereótipos de análise

• Adicionar modificadores de visibilidade aos métodos e atributos

• Definir os tipos dos atributos

Slide 58/72

09/12/2004 58/21

Exemplo – Análise login

Exemplo – Análise adicionar aluno

<<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 60/72 09/12/2004 60/21

Exemplo – diagrama único

envi arEm ail()

90

(91)

Exemplo – diagrama único

17/4/2012

10

Slide 55/72 09/12/2004 55/21

Análise X Projeto

• Abstrato X Concreto

• Independente X dependente da tecnologia de

implementação

• Simples X detalhado

• Modelos por caso de uso X unificação em um

único modelo

Slide 56/72

09/12/2004 56/21

Atividades – Projeto

• Refinar o modelo de classes

• Projetar arquitetura

• Camadas

• Projetar Banco de Dados

Slide 57/72

09/12/2004 57/21

Refinar o modelo de classes

• Juntar todas as classes em um só diagrama

• Analisar se é necessário criar novas classes ou

remover classes existentes

• Eliminar os estereótipos de análise

• Adicionar modificadores de visibilidade aos

métodos e atributos

• Definir os tipos dos atributos

Slide 58/72

09/12/2004 58/21

Exemplo – Análise login

Exemplo – Análise adicionar aluno

<<boundary>> 1 1 1..* 1 1 1 ₁ ₁ Slide 60/72 09/12/2004 60/21

Exemplo – diagrama único

envi arEm ail()

91

(92)

Reﬁnar o modelo de classes

•  _{Detalhar
assinatura
dos
métodos}

– deﬁnir todos os parâmetros dos métodos, seu -pos e o -po de retorno dos métodos

•  Mapear associações em atributos

(93)

Exemplo – diagrama melhorado

17/4/2012

11

Slide 61/72

09/12/2004 61/21

Refinar o modelo de classes

• Detalhar assinatura dos métodos

• definir todos os parâmetros dos métodos, seu tipos e o tipo de retorno dos métodos

• Mapear associações em atributos

• Analisar a possibilidade de utilizar herança

Slide 62/72

09/12/2004 62/21

Exemplo – diagrama melhorado

TelaLogin efet uarLogin() TelaLogin() ControladorLogin efetuarLogin() registrarSessao() ControladorLogin() * 1 * 1 CadastroUsuarios checar() CadastroUsuarios() 1 1 1 1 TelaAdicionarAluno adicionarAluno() TelaAdicionarAluno() CadastroAlunos adicionarAluno() CadastroAlunos() ControladorAdicionarAluno adicionarAluno() ControladorAdicionarAluno() 1..* 1 1..* 1 1 1 1 1 ComunicacaoServidorEmail enviarEmail() ComunicacaoServidorEmail() 11 11 Email assunto : String remetente : String destinatario : String corpo : String Email() Aluno nome : String email : String Aluno() Usuario login : String senha : String Usuario() Slide 63/72 09/12/2004 63/21

Refinar o modelo de classes

• Identificar padrões de projeto a serem aplicados

! Abstrações de uma solução de projeto recorrente

! Envolvem dependências, estruturas, interações e

convenções relativos a classes e objetos

• Ex: Singleton, Fachada

• Revisar as classes Slide 64/72

Exemplo de Padrão –

Fachada (Façade)

Façade Slide 65/72 09/12/2004 65/21

Modelo Melhorado com Padrões

de Projeto

CadastroUsuarios checar() CadastroUsuarios() CadastroAlunos adicionarAluno() CadastroAlunos() ComunicacaoServidorEmail enviarEmail() ComunicacaoServidorEmail() Email assunto : String remetente : String destinatario : String corpo : String Email() Aluno nome : String email : String Aluno() Usuario login : String senha : String Usuario() TelaAdicionarAluno adicionarAluno() TelaAdicionarAluno() TelaLogin efetuarLogin() TelaLogin() ControladorAdicionarAluno adicionarAluno() ControladorAdic ionarAluno() 1 1 1 1 1 1 1 1 Fachada adic ionarAluno() efet uarLogin() <<singleton>> 1 1..* 1 1..* 1 1 ControladorLogin efet uarLogin() registrarSessao() ControladorLogin() 1 1 1 1 1 1 1 1 1..* 1..* 1 1 1 ₁ Fachada Singleton Slide 66/72 09/12/2004 66/21

Projetar arquitetura

• Dividir o sistema em camadas.

Apresentação

Negócio Dados

Interface com o usuário

Regras de negócio inerentes à aplicação

Código relacionado ao mecanismo de persistência utilizado

Comunicação

Comunicação entre

apresentação e negócio e com outros sistemas

93

(94)

Reﬁnar o modelo de classes

•  _{Iden-ﬁcar
padrões
de
projeto
a
serem} aplicados

– Abstrações de uma solução de projeto recorrente

– Envolvem dependências, estruturas, interações e

convenções rela-vos a classes e objetos

•  Ex: Singleton, Fachada

(95)

Exemplo de Padrão – Fachada (Façade)

17/4/2012

11

Slide 61/72

09/12/2004 61/21

Refinar o modelo de classes

• Detalhar assinatura dos métodos

• definir todos os parâmetros dos métodos, seu tipos e o tipo de retorno dos métodos

• Mapear associações em atributos

• Analisar a possibilidade de utilizar herança

Slide 62/72

09/12/2004 62/21

Exemplo – diagrama melhorado

TelaLogin efet uarLogin() TelaLogin() ControladorLogin efetuarLogin() registrarSessao() ControladorLogin() * 1 * 1 CadastroUsuarios checar() CadastroUsuarios() 1 1 1 1 TelaAdicionarAluno adicionarAluno() TelaAdicionarAluno() CadastroAlunos adicionarAluno() CadastroAlunos() ControladorAdicionarAluno adicionarAluno() ControladorAdicionarAluno() 1..* 1 1..* 1 1 1 1 1 ComunicacaoServidorEmail enviarEmail() ComunicacaoServidorEmail() 11 11 Email assunto : String remetente : String destinatario : String corpo : String Email() Aluno nome : String email : String Aluno() Usuario login : String senha : String Usuario() Slide 63/72 09/12/2004 63/21

Refinar o modelo de classes

• Identificar padrões de projeto a serem aplicados

! Abstrações de uma solução de projeto recorrente ! Envolvem dependências, estruturas, interações e

convenções relativos a classes e objetos

• Ex: Singleton, Fachada

• Revisar as classes Slide 64/72

Exemplo de Padrão –

Fachada (Façade)

Façade Slide 65/72 09/12/2004 65/21

Modelo Melhorado com Padrões

de Projeto

CadastroUsuarios checar() CadastroUsuarios() CadastroAlunos adicionarAluno() CadastroAlunos() ComunicacaoServidorEmail enviarEmail() ComunicacaoServidorEmail() Email assunto : String remetente : String destinatario : String corpo : String Email() Aluno nome : String email : String Aluno() Usuario login : String senha : String Usuario() TelaAdicionarAluno adicionarAluno() TelaAdicionarAluno() TelaLogin efetuarLogin() TelaLogin() ControladorAdicionarAluno adicionarAluno() ControladorAdic ionarAluno() 1 1 1 1 1 1 1 1 Fachada adic ionarAluno() efet uarLogin() <<singleton>> 1 1..* 1 1..* 1 1 ControladorLogin efet uarLogin() registrarSessao() ControladorLogin() 1 1 1 1 1 1 1 1 1..* 1..* 1 1 1 ₁ Fachada Singleton Slide 66/72 09/12/2004 66/21

Projetar arquitetura

• Dividir o sistema em camadas.

Apresentação

Negócio

Dados

Interface com o usuário

Regras de negócio inerentes à aplicação

Código relacionado ao mecanismo de persistência utilizado

Comunicação

Comunicação entre

apresentação e negócio e com outros sistemas

95