Marcio de Carvalho Victorino mcvictorino@uol.com.br Processo Unificado Marcio de Carvalho Victorino mcvictorino@uol.com.br

Unidade IV: Análise OO (Aspectos Estáticos)

Modelo de Classes O Modelo de Classes evolui durante as iterações do desenvolvimento do sistema. À medida que o sistema é desenvolvido, o Modelo de Classes é incrementado com novos detalhes. Há três níveis de abstração pelos quais o Modelo de Classes passa: Modelo de Classes de Domínio. Modelo de Classes de Especificação. Modelo de Classes de Implementação.

Modelo de Classes Modelo de Classes de Domínio: Representa as classes de domínio do negócio em questão. É construído durante a atividade de análise das iterações. Não leva em consideração restrições inerentes à tecnologia a ser utilizada na solução de um problema.

Modelo de Classes Modelo de Classes de Especificação: É uma extensão do Modelo de Classes de Domínio. Possui detalhes específicos inerentes a solução de software escolhida. São definidas novas classes necessárias para desenvolver a solução do problema. É construído na atividade de projeto das iterações.

Modelo de Classes Modelo de Classes de Implementação: É uma extensão do Modelo de Classes de Especificação. Corresponde à implementação das classes em alguma linguagem de programação, normalmente OO. É construído na atividade de implementação das iterações.

Diagrama de Classes Os diagramas de classes também podem conter pacotes ou subsitemas, utilizados para agrupar elementos do seu modelo em um conjunto maior. Elementos de UML presentes nos Diagramas de Classes: Classes, suas estruturas internas e comportamento; Interfaces; Associações, agregações, dependências, e relações de herança; Multiplicidade e indicadores de navegação; Nomes de papéis (O que uma classe representa para outra).

Classes ContaBancaria ContaBancaria numero numero saldo ContaBancaria Nome da Classe ContaBancaria numero saldo dataAbertura creditar() debitar() ContaBancaria numero saldo dataAbertura Atributos ContaBancaria Operações 3 formas de representar classes

Relacionamentos Ao construir modelo de classe você irá descobrir que há um numero muito pequeno de classes que trabalham sozinhas. Ao fazer modelagem de um sistema é preciso ver como os itens relacionam-se entre si. Três tipos especialmente importantes: Dependência - que representa relacionamento de utilização entre as classes. Generalização - que relacionam classes generalizadas a suas especializações. Associações - representam relacionamentos estruturais entre objeto.

Dependência ContaBancaria ObjValor public class ContaBancaria { private int numero; private float saldo; private Date dataAbertura; public void creditar(ObjValor valor) { . }

Generalização ContaBancaria numero saldo dataAbertura creditar() public class ContaBancaria { private int numero; private float saldo; private Date dataAbertura; public void creditar(ObjValor valor) { . } ContaBancaria numero saldo dataAbertura creditar() debitar() public class Poupanca extends ContaBancaria { private int variacao; . } Poupanca variacao

multiplicidade da associação nome da associação Empresta de Pessoa Banco papéis na associação devedor credor Pessoa Banco multiplicidade da associação 1..* * Pessoa Banco

Associação: Multiplicidade Não Especificado Exatamente um Zero ou mais (vários, ilimitado) Um ou mais Zero ou um Intervalo especificado Intervalos múltiplos 1 0..* * 1..* 0..1 2..4 2, 4..6

Associação Cliente ContaBancaria Movimenta 1 * public class Cliente { private String nome; private long cpf; private ContaBancaria contas[ ]; . }

Associação: Classe Associativa Pessoa empregado empregador Empresa * * nome telefone endereco rezaoSocial endereco Emprego salario dataContratacao

Associação: Classe Associativa Pessoa nome telefone endereco Emprego salario dataContratacao Empresa rezaoSocial endereco 1 * 1 *

Associação Reflexiva Empregado nome telefone endereco 1 * Supervisao supervisionado supervisor

Agregação Banco 1..* * Cliente

Composição * Banco Filial 1

Agregação & Composição * Banco Filial 1 Cliente 1..*

Responsabilidades & Colaborações Costuma-se categorizar os objetos de um sistema de acordo com o tipo de responsabilidade a ele atribuída. objetos de entidade objetos de controle objetos de fronteira Esta categorização foi proposta por Ivar Jacobson (Jacobson et al, 1992) em uma técnica denominada Análise de Robustez.

Objetos de Entidade Um objeto de entidade é um repositório para alguma informação manipulada pelo sistema. Esses objetos representam conceitos do domínio do negócio. Normalmente esses objetos armazenam informações persistentes. Há várias instâncias de uma mesma classe de entidade coexistindo no sistema.

Objetos de Fronteira Esses objetos traduzem os eventos gerados por um ator em eventos relevantes ao sistema. Também são responsáveis por apresentar os resultados de uma interação dos objetos em algo inteligível pelo ator. Um objeto de fronteira existe para que o sistema se comunique com o mundo exterior. Por conseqüência, estes objetos são altamente dependentes do ambiente.

Objetos de Controle São a “ponte de comunicação” entre objetos de fronteira e objetos de entidade. Responsáveis por controlar a lógica de execução correspondente a um caso de uso. Decidem o que o sistema deve fazer quando um evento externo relevante ocorre. Eles realizam o controle do processamento Agem como gerentes (coordenadores, controladores) dos outros objetos para a realização de um ou mais caso de uso.

Divisão de responsabilidades A categorização de responsabilidades implica em que cada objeto é especialista em realizar um de três tipos de tarefa: se comunicar com atores (fronteira) manter as informações do sistema (entidade) 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 eventuais mudanças

Divisão de responsabilidades

Classes Avançadas Visibilidade (UML): A visibilidade de uma característica indica se ela pode ser utilizada por outras classes: Público (+) – membros da classe são acessíveis por todos os clientes. Package (~) - membros da classe são acessíveis somente pelas classes do mesmo pacote (package) e pela própria classe. Protegido (#) – membros da classe são acessíveis somente por subclasses e pela própria classe. Privado (-) - membros da classe são acessíveis somente pela própria classe.

Classes Avançadas Escopo: O escopo da propriedade especifica se uma característica aparece em cada instancia da classe ou se haverá uma única instancia da característica para todas as instancias da classe: Instância – cada instancia da classe mantém seu próprio valor para a característica. Static (Classe) – existe apenas um valor da característica para todas as instancias do classificador.

Classes Avançadas Elementos abstratos, herança e polimorfismo: É comum especificar classes abstratas, significando que não poderão apresentar instancias diretas. Na UML são representadas por nome em itálico. Generalização (herança) é usada para fazer a modelagem de estruturas de classes com abstrações mais gerais no topo da hierarquia e outras mais específicas na parte inferior. Uma operação é polimórfica, significando que, em uma hierarquia de classes, você pode especificar operações com a mesma assinatura em pontos diferentes da hierarquia. Você pode especificar uma operação abstrata escrevendo o respectivo nome em itálico.

Diagrama de objetos Além do diagrama de classes, A UML define um segundo tipo de diagrama estrutural, o diagrama de objetos. Pode ser visto com uma instância de diagramas de classes Representa uma “fotografia” do sistema em um certo momento. exibe as ligações formadas entre objetos conforme estes interagem e os valores dos seus atributos.

Exemplo (Diagrama de objetos) Supervisao Empregado nome telefone endereco * 1 supervisionado supervisor

FIM