Análise e Projeto de Sistemas

Prof. Dra. Eliana B. Pereira

22/10/14 1
 Perspectias de um Diagrama de
Classes

22/10/14 2
 Relembrando...

22/10/14 3
• O diagrama de classes eiolui com o sistema e pode
ter diferentes perspectias:
●
O modelo conceitual (análise) representa as classes
no domínio do negócio em questão. Não leia em
consideração restrições inerentes à tecnologia a ser
utlizada na solução de um problema.
●
O modelo de classes de especifcação (projeto) é
obtdo atraiés da adição de detalçes ao modelo
anterior conforme a solução de sofware escolçida.
●
O modelo de classes de implementação corresponde
à implementação das classes em alguma linguagem
de programação.
 Modelo de Projeto

22/10/14 5
 Modelo de Projeto
• Refnamento do Modelo Conceitual. Ideia é
adicionar detalçes ao diagrama já criado.

• Na fase de projeto os métodos são adicionados e

o Modelo Conceitual é refnado gerando o
Diagrama de Classes

• São adicionados os métodos, informações de

iisibilidade e defnidos os tpos de classes:
Entdade, Controle e Interface.
 Para relembrar...

22/10/14 7
 O que são Métodos?

• Expressam o comportamento da classe

• Acessam e modifcam os atributos da classe
• Na implementação, são os métodos (similares a
procedimentos e funções)
• Possuem defnição de iisibilidade (geralmente
públicas)
• Podem retornar ialor ou não (ioid)
• Podem receber parâmetros ou não (entre parênteses
obrigatórios)
 Visibilidade (atributos e
métodos)
• Defnida por meio de modifcadores de acesso:
– Público [+] : atributo ou método é acessado pela própria
classe e por qualquer outra classe do programa.
– Protegido [#] : atributo ou método é acessado pela própria
classe e pelas suas subclasses.
– Pacote [~]: atributo ou método é acessado pela própria
classe e por todas as classes do mesmo pacote.
– Privado [–] : atributo ou método só pode ser acessado
dentro da própria classe.
• Serie para encapsular, proteger, organizar o acesso à membros
de uma classe
Representação da UML

Métodos
 Notação UML para Métodos

• A notação e uso iai depender do tpo de iisão no qual

estamos trabalçando e podem ser abstratos ou
utlizar a notação de uma linguagem de programação

– [Visibilidade]Nome(Parâmetros):Retorno
 Notação UML para Métodos -
Parâmetros
• Os parâmetros – dados de entrada e/ou saída para o
método são representados por Nome-do-
Parâmetro:Tipo=Valor-Padrão

• Ex:
– Visão conceitual
• ImprimirData(data:TipoData)
– Visão de implementação
• ArmazenarDados(nome:cçar[30],salario:foat)
 Notação UML para Métodos –
Tipo de Retorno
• O Valor-de-Retorno indica se o método retorna algum
ialor ao término de sua execução e qual o tpo de dado
do ialor retornado.
• Ex:
– Visão Conceitual
• CalcularIdade(): TipoInteiro
– Visão de implementação
• ArmazenarDados(nome:cçar[30]): boolean

• Alguns métodos não possuem retorno.

●
Em java são defnidos como métodos do tpo void.
Exemplo de uma Classe

A classe possui um
método com
parâmetro e retorno e
um método que não
possui nem
parâmetro e nem
retorno (uso da
palaira reseriada no
jaia void.
 Exemplo de Diagrama de
Classes – Modelo de Projeto
 Identfcando os Tipos de Classe
de Projeto
• Fronteira: Responsáieis pela interação com os atores

• Entdade: Representação dos conceitos do domínio

do problema

• Controle: Responsáieis pela coordenação da

interação entre os outros objetos
 Classes de Fronteira
• Tradução de boundary classes
• Interação com os elementos externos
– Apresentação de informações
– Captação de informação
• Classes de fronteira NÃO deiem ter responsabilidades
relatias as regras de negócio da aplicação
• Para cada interação entre um ator e caso de uso, é
criada uma classe de fronteira
– Exemplo: uma classe para representar um formulário de
cadastro de um cliente
 Classes de Fronteira

• Tipos de fronteira:

– Classes de interface com o usuário

– Classes de interface com equipamentos
– Classes de interface com outros sistemas
 Classes de Fronteira

• Representação:

OU
 Classes de Entdade
• Representação dos conceitos do domínio do Problema
– Informações e regras de negócio que direcionam a
manipulação dessas informações
• Geralmente são classes que persistem ialores
• Também cçamadas de classes de negócio
• A maioria já descoberta na fase de análise
• Aspecto importante a analisar: quais classes geram
objetos que deiam ser persistentes
 Classes de Entdade

• Representação:

OU
 Classes de Controle
• São a “ponte de comunicação” entre objetos de fronteira e
objetos de entdade.
• Responsáieis por controlar a lógica de execução
correspondente a um caso de uso.
• Decidem o que o sistema deie fazer quando um eiento
externo releiante ocorre.
– Eles realizam o controle do processamento
• Responsabilidades:
– Preencçimento de controles da interface gráfca
– Autentcação de usuários
– Controle de acesso às funcionalidades do sistema
 Classes de Controle

• Representação:

OU
Defnindo Classes – Exemplo I
 Diiisão de responsabilidades

• A categorização de responsabilidades implica em que

cada objeto é especialista em realizar um de três tpos
de tarefa:
– se comunicar com atores (fronteira)
– manter as informações do sistema (entdade)
– coordenar a realização de um caso de uso (controle).
• A importância dessa categorização está relacionada à
capacidade de adaptação do sistema a eientuais
mudanças
 Diiisão de responsabilidades

• Se cada objeto tem funções específcas dentro do

sistema, eientuais mudanças no sistema podem ser:
●
menos complexas
●
mais localizadas

• Uma eientual modifcação em uma parte do sistema

tem menos possibilidades de resultar em mudanças
em outras partes.
 Diiisão de responsabilidades
Tipo de mudança Onde mudar

Mudanças em relação à Fronteira

interface gráfica, ou em
relação à comunicação com
outros sistemas.

Mudanças nas informações Entidade

manipuladas pelo sistema
Mudanças em funcionalidades Controle
complexas (lógica do negócio)

27
 Diiisão de responsabilidades
• Exemplo: iantagem de separação de
responsabilidades em um sistema para uma loja de
aluguel de carros.
– Se o sistema tier que ser atualizado para que seus usuários
possam utlizá-lo pela Internet, a lógica da aplicação não
precisaria de modifcações.
– Considerando a lógica para calcular o ialor total das locações feitas
por um cliente: se esta lógica estier encapsulada em uma classe
de controle, somente esta classe precisaria de modifcação.
 Diiisão de responsabilidades

• A construção de um sistema de sofware que faça

separação das responsabilidades de apresentação
(fronteira), de lógica da aplicação (controle) e de
manutenção dos dados (entdade):
– facilita também o reuso dos objetos no desenioliimento de
sistemas de sofware semelçantes.
– ajuda no desacoplamento entre elementos do sistema
 Dúiidas

22/10/14 30