Processo Unificado
Marcio de Carvalho Victorino
[email protected]
Unidade V: Projeto OO
(Aspectos Estáticos)
Introdução



Em sistemas OO, a mesma representação é
utilizada durante a análise e o projeto.
Vantagem: há uma uniformidade na modelagem do
sistema.
Desvantagem: torna menos nítida a separação
entre o que é feito na análise e o que é feito no
projeto.
3
Introdução


É na fase de projeto de uma iteração que essas
definições são feitas.
As atividades realizadas na fase de projeto são as
seguintes:
1. Detalhamento dos aspectos dinâmicos do sistema.
2. Refinamento dos aspectos estáticos e estruturais do
sistema.
3. Definição de outros aspectos da solução.

Após essas atividades, os modelos estão em um
nível de detalhamento suficiente para serem
implementados.
4
Transformação de Classes de Domínios
em Classes de Especificação


O modelo de classes de especificação é resultante
de refinamentos no modelo de classes de domínio.
Após sua construção, o modelo de especificação é
passado aos programadores para que eles o
implementem.
5
Especificação de Classes de Fronteira


Durante a análise, considera-se que há uma única
classe de fronteira para cada ator.
Na passagem para o modelo de especificação,
algumas dessas classes podem resultar em várias
outras.


Interface como seres humanos: projeto da interface
gráfica produz o detalhamento das classes.
Equipamentos: uma ou mais classes para encapsular o
protocolo de comunicação do equipamento.

O mesmo vale para comunicação com outros sistemas.
6
Especificação de Classes de Entidade



Normalmente precisam de armazenamento
persistente.
As classes de entidades que devem ser
armazenadas de modo persistente devem ser
identificadas na especificação.
Também devem ser identificados os padrões de
acesso a cada classe de entidade cujos objetos
devem ser persistentes.

A taxa de acesso a uma coleção influencia na política de
armazenamento.
7
Especificação de Classes de Controle


Na especificação, deve-se analisar a verdadeira
utilidade de cada classe de controle identificada
durante a análise.
Em casos de uso simples (manutenção de dados),
classes de controle não são realmente necessárias.


classes de fronteira podem repassar os dados fornecidos
pelos atores diretamente para as classes de entidade
correspondentes.
Em casos de uso complexos, uma classe de
controle de análise pode resultar em duas ou mais
classes de especificação.
8
Especificação de Atributos

A especificação completa de um atributo deve
seguir a sintaxe:
visibilidade nome : tipo = valor-inicial





Visibilidade e encapsulamento.
Tipo pode ser um TAD.
Tipo e valor inicial dependentes de linguagem.
Atributo derivado
Escopo do atributo
9
Especificação de Atributos
Cliente
#nome : String
-dataNascimento : Data
-telefone : String
#/idade : int
#limiteCrédito : Moeda = 500.0
-quantidadeClientes : int
-idadeMédia : float




Público (+)
Package (~)
Protegido (#)
Privado (-)
10
Especificação de Operações

Operação: um processamento realizado por (um
objeto de) uma classe.


Em termos de implementação: é uma rotina (método)
associada a uma classe.
Na construção do modelo de interações, operações
identificadas na análise são validadas e várias
outras operações são identificadas.

Essas operações devem ser adicionadas ao diagrama de
classes e documentadas através da definição de sua
assinatura.
11
Especificação de Operações
visibilidade nome(parâmetros): tipo-retorno
Onde, para cada parâmetro:
nome-parâmetro: tipo-parâmetro




Visibilidade e encapsulamento.
Tipo pode ser um TAD.
Tipo de retorno e dos parâmetros dependentes de
linguagem.
Escopo da operação
12
Especificação de Operações
Cliente
+obterNome() : String
+definirNome(in umNome : String)
+obterDataNascimento() : Data
+definirDataNascimento(in umaData : Data)
+obterTelefone() : String
+definirTelefone(in umTelefone : String)
+obterLimiteCrédito() : Moeda
+definirLimiteCrédito(in umLimiteCrédito : float)
+obterIdade() : int
+obterQuantidadeClientes() : int
+obterIdadeMédia() : float
13
Relacionamento de Dependência

Na UML, há três tipos de relacionamentos entre
objetos:




Associações
Generalizações
Dependências
No modelo de classes de domínio, os
relacionamentos entre objetos são identificados
como associações.
14
Navegabilidade de Associações




Associações, agregações e composições podem ser
bidirecionais e unidirecionais.
Uma associação bidirecional indica que há um
conhecimento mútuo entre os objetos associados.
Na UML, associações são, por omissão, navegáveis
em ambos os sentidos.
Uma associação unidirecional é representada
adicionando-se um sentido à seta da associação.
15
Navegabilidade de Associações
Cliente
-nome : String
-dataNascimento : Data
-telefone : String
-/idade : int
-limiteCrédito : Moeda = 500.0
-quantidadeClientes : int
-idadeMédia : float
Realiza
1
0..*
Pedido
-data : Data
-hora : Horário
-situação : ESituação
+obterTotal() : Moeda
16
Navegabilidade de Associações

No modelo de classes de especificação, a
navegabilidade de todas as associações deve ser
definida.



Algumas associações permanecem bidirecionais.
Se não houver essa necessidade, recomenda-se
transformar a associação em unidirecional.
A escolha do sentido da navegabilidade pode ser
feita através dos diagramas de interação.

Mensagens influenciam na existência ou não de
navegabilidade em um sentido.
17
Implementação de Associações



Para associações de conectividade um para um, a
implementação é trivial: é definido um atributo do
tipo Cb na classe Ca.
Navegabilidade bidirecional: aplica-se o
procedimento acima para as duas classes.
Portanto, em associações um para um, não há
necessidade de um refinamento adicional do
diagrama de classes.
18
Implementação de Associações


Em associações de conectividade um para muitos
ou muitos para muitos, detalhes adicionais podem
ser representados para esclarecer como
implementar tais associações.
O detalhamento de associações se baseia em
classes que representam coleções de elementos.
19
Generalização



Também pode ser chamado de relacionamento de
especialização, pois a generalização e a
especialização são dois pontos de vista do mesmo
relacionamento.
O termo herança também é comumente utilizado
como sinônimo do relacionamento de
generalização. (implementação)
A generalização pode ser utilizada tanto no modelo
de classes de domínio quanto no de especificação.
20
Generalização
FiguraGeométrica
Veículo
{incompleta, disjunta}
{incompleta}
Caminhão
Homem
Trator
Elipse
Quadrado
Círculo
Indivíduo
Atleta
{completa, disjunta}
{incompleta, sobreposta}
Mulher
Nadador
Corredor
21
Generalização X Associação

Importante: a generalização difere da associação
(agregação, composição ) porque a primeira se
trata de um relacionamento entre classes.



“Gerentes são tipos especiais de funcionários”.
“Gerentes chefiam departamentos”.
Na associação, objetos específicos de uma classe se
associam entre si ou com objetos específicos de
outras classes.
22
Herança de Associações

Atributos e operações e associações são
herdados pelas subclasses.
Realiza
Cliente
1
ClientePessoaFísica
Pedido
*
ClientePessoaJurídica
23
Hierarquias de Generalização

A generalização pode ser aplicada em vários níveis
(hierarquia de generalização).


uma classe que herda propriedades de uma outra classe
pode ela própria servir como superclasse.
Características importantes:


Transitividade: uma classe em uma hierarquia herda
propriedades e relacionamentos de todos os seus
ancestrais.
Assimetria: dadas duas classes A e B, se A for uma
generalização de B, então B não pode ser uma
generalização de A. Ou seja, não pode haver ciclos em
uma hierarquia de generalização.
24
Herança Múltipla

Herança múltipla: Uma classe pode ter mais de uma
superclasse.


Tal classe herda de todas a suas superclasses.
O uso de herança múltipla deve ser evitado.


Esse tipo de herança é difícil de entender.
Algumas LPs não dão suporte à implementação desse tipo de
herança (Java e Smalltalk).
Barco
Carro
CarroAnfíbio
25
Classes Abstratas



Usualmente, a existência de uma classe se justifica
pelo fato de haver a possibilidade de gerar
instâncias (classes concretas).
No entanto, podem existir classes que não geram
instâncias diretas: classes abstratas.
Utilizadas para organizar e simplificar uma
hierarquia de generalização.


Propriedades comuns a diversas classes podem ser
organizadas e definidas em uma classe abstrata a partir
da qual as primeiras herdam.
Subclasses de uma classe abstrata também podem
ser abstratas, mas a hierarquia deve terminar em
uma ou mais classes concretas.
26
Classes Abstratas
ContaBancária
ContaCorrente
ContaPoupança
27
Arquitetura em Camadas


Uma forma de organizar a arquitetura de um
sistema complexo em partes menores é através de
camadas de software.
Uma camada de software, é uma coleção de
subsistemas.



Cada camada corresponde a um conjunto de
funcionalidades de um sistema de software.
Funcionalidades de alto nível dependem de
funcionalidades de baixo nível.
Camadas fornecem um nível de abstração através
do agrupamento lógico de subsistemas
relacionados.
28
Arquitetura em Camadas


Princípio geral: camadas de abstração mais alta
devem depender das camadas de abstração mais
baixa, e não o contrário.
Permite que o sistema de software seja mais
portável e modificável.


Uma mudança em uma camada mais baixa que não afete
a sua interface não implicará em mudanças nas camadas
mais altas.
E vice-versa, uma mudança em uma camada mais alta
que não implica na criação de um novo serviço em uma
camada mais baixa não irá afetar estas últimas.
29
Arquitetura em Camadas


A UML não tem nenhum elemento gráfico préespecífico para representar camadas de um
sistema.
No entanto, pacotes também podem ser utilizados
para representar camadas.


O estereótipo <<camada>> pode ser utilizado no pacote
que represente uma camada.
O fato de uma camada utilizar outra pode ser
representado por um relacionamento de dependência.
30
Sistema Cliente-Servidor



Um sistema cliente-servidor clássico é dividido em
duas camadas. A primeira (cliente) requisita
serviços à segunda (servidor).
O cliente é normalmente responsável pela interface
gráfica com o usuário.
O servidor é normalmente pode servir a diversos
clientes para fornecer diversos serviços (segurança,
impressão, correio eletrônico, gerenciamento de
janelas, etc.).
31
Sistema Cliente-Servidor


Sistemas cliente-servidor em duas camadas foram
dominantes durante aproximadamente toda a
década de 90 e são utilizados até hoje.
A construção de sistemas cliente-servidor é
vantajosa quando o número de clientes não é tão
grande

por exemplo, uma centena de clientes interagindo com o
servidor através de uma rede local.
32
Sistema Cliente-Servidor

No entanto, com o surgimento da Internet.
Rapidamente, originou-se uma demanda pela
construção de sistemas de software que pudessem
ser utilizados nesse ambiente.


Isto causou problemas em relação à estratégia clienteservidor de duas camadas, principalmente em relação à
construção de clientes gordos.
Internet: permitir o acesso a variados recursos através de
um programa navegador (browser), que não fornece
grande suporte à construção daquele tipo de cliente.
33
Sistema em três Camadas



Solução encontrada: adição de um nova camada de
software.
Sistemas construídos segundo essa estratégia são
denominados sistemas cliente-servidor em três
camadas.
Essas camadas normalmente recebem os seguintes
nomes:



camada de apresentação
camada da lógica do negócio
camada de acesso
34
Camada Apresentação

Classes que contêm funcionalidade para
visualização dos dados pelos usuários.



As classes de fronteira para atores humanos se
encontram nessa camada.
Objetivo: exibir informações ao usuário e traduzir
ações do usuário em requisições às demais partes
do sistema.
Exemplos de camadas de apresentação:



um sistema de menus baseados em texto;
uma página escrita em HTML ou XHTML com JavaScript
apresentada em um navegador de Internet;
uma interface gráfica construída em algum ambiente de
programação visual.
35
Camada da Lógica do Negócio




Consiste da camada existente no servidor de
aplicação.
Classes que implementam as regras do negócio no
qual o sistema está para ser implantado.
Além disso, essa camada deve decidir que parte da
camada de acesso de ser ativada com base em
requisições
provenientes
da
camada
de
apresentação.
Nessa camada, são realizadas computações com
base nos dados armazenados ou nos dados de
entrada.
36
Camada de Acesso



Contém classes que se comunicam com outros
sistemas para realizar tarefas ou adquirir
informações para o sistema.
Tipicamente essa camada é implementada
utilizando algum mecanismo de armazenamento
persistente (SGBD).
Pode haver uma subcamada dentro desta camada:
a camada de persistência

isola o restante do sistema de modificações no
mecanismo de armazenamento persistente.
37
Arquitetura Física


Representa a disposição física do sistema de
software pelo hardware disponível.
A divisão de um sistema em camadas é
independente da sua disposição física.


As camadas de software podem estar fisicamente
localizadas em uma única máquina, ou podem estar
distribuídas por diversos processadores.
Alternativamente, essas camadas podem estar
distribuídas fisicamente em vários processadores. (Por
exemplo, quando a camada da lógica do negócio é
dividida em duas ou mais máquinas.)
38
Arquitetura Física


O modelo que representa a arquitetura física é
denominado modelo de implantação ou modelo
da arquitetura física.
Há dois tipos de diagramas na UML utilizados para
modelar a arquitetura física:


diagrama de implantação
diagrama de componentes
39
Diagrama de Componentes


Mostra os vários componentes de software
de um sistema, além das dependências entre
estes últimos.
Os elementos gráficos desse diagrama:
Componente
Interface
Dependência
40
Diagrama de Componentes
41
Diagrama de Componentes

A UML define diversos estereótipos para
componentes:





<<executável>>: um componente que pode ser
executado.
<<documento>>: um documento. Por exemplo, um
manual de instalação ou um manual do usuário.
<<tabela>>: uma tabela em um banco de dados.
<<arquivo>>: um arquivo de dados.
<<biblioteca>>: uma biblioteca de objetos ou de
funções. Por exemplo, uma DLL.
42
Diagrama de Implantação

Representa a topologia física do sistema e
opcionalmente os componentes que são executados
nesta topologia.



Apresenta um mapeamento entre os componentes de
software e o hardware utilizado.
Elementos: nós e conexões.
Um nó é uma unidade física que representa um
recurso computacional.


Normalmente possui uma memória e alguma capacidade
de processamento.
Exemplos: processadores, dispositivos, sensores,
roteadores ou qualquer equipamento de importância para
o sistema de software.
43
Diagrama de Implantação

Os nós são conectados uns aos outros através das
conexões.



Um nó é representado através de um cubo.




Conexões mostram mecanismos de comunicação entre os nós.
Meios físicos (cabo coaxial, fibra ótica, etc.) ou protocolos de
comunicação (TCP/IP, HTTP, etc.).
Nome e tipo do nó definidos no interior do cubo.
A sintaxe para o nome e o tipo do nó é similar à utilizada para os
diagramas de objetos.
Tanto o nome quanto o tipo são opcionais.
Uma conexão é representada graficamente por uma linha
(estereotipada) ligando dois nós.
44
Diagrama de Implantação
cliente:Browser
<<HTTP>> Servidor de Aplicação
<<ODBC>> BD Corporativo
<<LAN>>
:Impressora
45
FIM