Upload
noah-fuentes
View
30
Download
0
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
Marcio de Carvalho [email protected]
Processo Unificado
Unidade V: Projeto OO(Aspectos Estáticos)
3
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.
4
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.
5
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.
6
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.
7
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.
8
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.
9
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
10
Especificação de Atributos
Público (+) Package (~) Protegido (#) Privado (-)
#nome : String-dataNascimento : Data-telefone : String#/ idade : int#limiteCrédito : Moeda = 500.0-quantidadeClientes : int-idadeMédia : float
Cliente
11
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.
12
Especificação de Operações
visibilidade nome(parâmetros): tipo-retorno
Visibilidade e encapsulamento. Tipo pode ser um TAD. Tipo de retorno e dos parâmetros
dependentes de linguagem. Escopo da operação
nome-parâmetro: tipo-parâmetro
Onde, para cada parâmetro:
13
Especificação de Operações
+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
Cliente
14
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.
15
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.
16
Navegabilidade de Associações
-nome : String-dataNascimento : Data-telefone : String-/ idade : int-limiteCrédito : Moeda = 500.0-quantidadeClientes : int-idadeMédia : float
Cliente
+obterTotal() : Moeda
-data : Data-hora : Horário-situação : ESituação
Pedido
1 0..*
Realiza
17
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.
18
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.
19
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.
20
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.
21
Generalização
Caminhão Trator
Veículo
{incompleta}
Elipse Quadrado
FiguraGeométrica
{incompleta, disjunta}
Círculo
Homem Mulher
Indivíduo
{completa, disjunta}
Nadador Corredor
Atleta
{incompleta, sobreposta}
22
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.
23
Herança de Associações Atributos e operações e associações
são herdados pelas subclasses.
ClientePessoaFísica ClientePessoaJurídica
Cliente Pedido1 *
Realiza
24
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.
25
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).
Carro Barco
CarroAnfíbio
26
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.
27
Classes Abstratas
ContaCorrente ContaPoupança
ContaBancária
28
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.
29
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.
30
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.
31
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.).
32
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.
33
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
cliente-servidor 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.
34
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
35
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.
36
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.
37
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.
38
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.)
39
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
40
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
41
Diagrama de Componentes
42
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.
43
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.
44
Diagrama de Implantação Os nós são conectados uns aos outros através das
conexões. 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.). Um nó é representado através de um cubo.
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.
45
Diagrama de Implantação
cliente:Browser Servidor de Aplicação BD Corporativo
:Impressora
<<LAN>>
<<HTTP>> <<ODBC>>
FIM