ANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3)

ANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3) Profª Andrea Padovan Jubileu Desenvolvimento Iterativo de Software (LARMAN, 2007) Desenvolvendo Software com UML 2.0 (MEDEIROS, 2004) Modelo de Projeto

O que já foi visto Caso de Uso: Emprestar Livros Diagrama de Casos de Uso Profª Andrea Padovan Jubileu 2

O que já foi visto Profª Andrea Padovan Jubileu 3

ELABORAÇÃO - Processo Unificado Disciplina Artefato Iteração -> Modelagem de Negócio Modelo de domínio (*) Requisitos Modelo de casos de uso (*) i r Visão i r Especificações suplementares (*) i r Glossário i r Projeto Modelo de projeto (*) Implementação... Concepção C1 Elaboração E1...En Construção Ct1...Ctn Transição T1...Tn i i r Artefatos integrantes do Modelo de Projeto Diagrama de Pacotes da Arquitetura Lógica (visão estática) Diagrama de Classes (visão estática) Diagramas de Interação (visão dinâmica) 4

5

Diagrama de Pacotes da Arquitetura Lógica Arquitetura lógica: é a organização em larga escala das classes de software em pacotes, subsistemas e camadas. É chamada arquitetura lógica porque não há decisão sobre como esses elementos são implantados pelos diferentes processos do S.O. ou pelos computadores físicos em uma rede (estas decisões posteriores são parte da arquitetura de implantação). Uma arquitetura de software é um conjunto de decisões significativas sobre a organização de um software, a seleção dos elementos estruturais e suas interfaces pelas quais o sistema é composto, juntamente com seu comportamento (especificado nas colaborações entre esses elementos), a composição desses elementos estruturais e comportamentais, e o estilo arquitetural que dirige essa organização esses elementos e suas interfaces, suas colaborações e sua composição. 6

Diagrama de Pacotes da Arquitetura Lógica Uma camada é um agrupamento de classes, pacotes ou subsistemas que tem responsabilidade coesa sobre um tópico importante do sistema. Também, as camadas são organizadas de modo que as mais altas (como a camada de IU) solicitem serviços das mais baixas. Camadas em um sistema OO incluem: Interface com o Usuário (IU) Lógica da Aplicação e Objetos do Domínio: objetos de software representando conceitos do domínio (por ex, uma classe de software Venda) que satisfazem requisitos da aplicação, como calcular um total de venda. Serviços Técnicos: objetos de propósito geral e subsistemas que fornecem serviços técnicos de apoio, como interfaceamento com um banco de dados ou registro de erros. Esses serviços, geralmente, são independentes da aplicação e reusáveis entre diversos sistemas. 7

Exemplo: Diag. de Pacotes da Arq.Lógica Mostra dependência (acoplamento ) entre os pacotes. A seta aponta para o pacote dependente. 8

Diagrama de Pacotes da Arquitetura Lógica É muito comum organizar a arquitetura lógica do sistema em camadas. Usar camadas ajuda a tratar problemas, tais como: A lógica da aplicação está entrelaçada com a interface do usuário, de modo que não pode ser reusada com uma interface diferente; Modificações do código fonte se espalham por todo o sistema muitas partes do sistema são altamente acopladas. 9

Da Análise ao Projeto Artefatos de análise capturam os resultados do processo de investigação do domínio do problema Casos de Uso Quais são os processos do domínio? Modelo Conceitual (de Domínio) Quais são os conceitos, termos? Diagrama de Seqüência Qual a sequência de mensagens entre os objetos? Diagrama de Classes Quais atributos, métodos e relaçòes necessárias para atender a necessidade do negócio? 10

O Começo da Fase Projetar A partir dos artefatos da fase de análise é desenvolvida uma solução lógica baseada no paradigma orientado a objetos. Quem construir primeiro: DIs ou Diag. De Classes? Alternativas: 1) Os Diagramas de Interação podem ser construídos primeiramente para serem a base de tal solução lógica, e posteriormente, é criado o Diagrama de Classes. 2) Elaborar os Diagramas de Interação e o Diagrama de Classes em paralelo. 11

Diagramas de Interação Um Diagrama de Interação (modelo dinâmico) ilustra como os objetos interagem por meio de mensagens para a realização de um caso de uso. Uma mensagem é uma solicitação de execução de uma operação em outro objeto. A criação de um DI depende da criação prévia dos seguinte artefatos: Casos de Uso Reais ou Essencias: subsidia a coleta de informações sobre quais tarefas os DIs ilustram. Modelo Conceitual: subsidia a definição de classes de software correspondentes a conceitos, cujos objetos participam dos DIs. 12

Diagramas de Interação Diagramas de Comunicação (antigo Colaboração) Ênfase na organização estrutural dos objetos que enviam e recebem mensagens Os objetos podem ser colocados em qualquer lugar do diagrama mensagem1( ) :Instância_ClasseA 1: mensagem2( ) :Instância_ClasseB 2: mensagem3( ) Diagramas de Seqüência (DS) Ênfase na ordenação temporal das mensagens, ou seja, na seqüência em que são executados os métodos (trocas de mensagens entre objetos) :Instância_ClasseA :Instância_ClasseB mensagem1( ) 1: mensagem2( ) 2: mensagem3( ) 13

Diagramas de Interação Exemplo de Diagrama de Seqüência para a operação RegistrarPagamento (Sistema POST): :POST Obs: parâmetro qf = quantia fornecida :Venda 1: registrarpagamento(qf) 2: criar(qf) :Pagamento - A mensagem registrarpagamento é enviada para uma instância de um POST (registradora). O objeto que a envia não está identificado. - O objeto POST envia a mensagem a uma instância de Venda. - A instância de Venda cria uma instância de Pagamento. 14

Como Fazer um Diagrama de Seqüência Regras úteis: 1. Criar um diagrama em separado para cada um dos casos de uso do sistema em desenvolvimento. 2. Se um diagrama se tornar muito complexo, o diagrama deve ser dividido. 3. Utilizar a descrição dos casos de uso e as pós-condições dos casos de uso para delimitação de início,meio e fim. 4. Um diagrama de seqüência também é visto como uma tradução do caso de uso desde a interação do usuário até a finalização de um dado processo. 5. Regra básica, divida em pequenos cenários a descrição do caso de uso e vá evoluindo o diagrama de acordo com as ações necessárias. Exemplos: Locar DVD e Vender Item. 15

Notação Básica para DS Classes e Instâncias :Venda POST classe p1:pagamento instância instância nomeada 16

Notação Básica para DS Resposta ou retornos Há dois modos de mostrar o resultado de retorno de uma mensagem: A) Usando a sintaxe de mensagem varderetorno = mensagem(parâmentro) B) Usando uma linha de mensagem de resposta (ou retorno) no final da barra de ativação. Barra de ativação mostra o foco de controle.

Notação Básica para DS Mensagens para self ou this Você pode mostrar uma mensagem sendo enviada de um objeto para ele mesmo.

Notação Básica para DS Criação de instância e linhas de vida de objetos

Notação Básica Iteração Uma moldura de loop UML, com guarda de expressão boleana. :A :B 1: iniciarnovavenda() loop [ mais itens ] 2: entraritem(iditem, qtdade) 3: descrição, total 4: finalizarvenda()

Notação Básica para DS Mensagens Condicionais Expressa que a mensagem só deve ser enviada se o valor da guarda (nova venda) for TRUE em tempo de execução. :POST opt :Venda [nova venda] 1: criar() Na notação UML 1.x, as mensagens condicionais são mostradas entre [ ] antes da mensagem. 21

Notação Básica Caminhos Condicionais Mutuamente Exclusivos :A alt :B :C [ X < 10 ] 1: calcular() [ else ] 2: calcular() 22

Notação Básica Mensagens e casos polimórficos Pagamento é uma superclasse abstrata, com subclasses concretas que implementam a operação polimórfica autorizar. :Registradora (II) :Pagamento {abstract} :PagamentoPor Débito 1: autorizar() :X 1: autorizar() :Pagamento 2: fazera() (I) autorizar() PagamentoPorCrédito autorizar()...() PagamentoPorDébito autorizar()...() (III) :PagamentoPor Crédito 1: autorizar() Obs: O polimorfismo pode ser mostrado por meio de vários DSs. Um mostra a mensagem polimórfica para a superclasse abstrata (I) e os outros detalha cada caso polimórfico (II e III). 2: fazerb() :Y

Polimorfismo É o princípio em que classes derivadas de uma mesma superclasse podem invocar operações que têm a mesma assinatura, mas comportamentos diferentes em cada subclasse, produzindo resultados diferentes, dependendo de como cada objeto implementa a operação.

Atribuição de Responsabilidades Diagramas de Interação: ilustram a solução, em termos de objetos inter-atuantes, que satisfazem responsabilidades do caso de uso e pós-condições. POO -> Atribuição de Responsabilidade -> Bons Projetos OO 25

Responsabilidades e Métodos Responsabilidade é um contrato ou obrigação de um tipo ou classe (Booch e Rumbaugh, 1997) Relacionada às obrigações dos objetos em termos de comportamento. Tipos básicos De fazer (alguma coisa) Ex: fazer algo individualmente, iniciar ações em outros objetos, controlar ou coordenar atividades em outros objetos De saber (alguma coisa) Ex: dados privados encapsulados, objetos relacionados, informação derivada ou calculada 26

Responsabilidades e Métodos Responsabilidades são atribuídas aos objetos do sistema durante o Projeto OO Uma Venda é responsável por imprimir a si própria (de fazer) Uma Venda é responsável por conhecer sua data (de saber) Tradução de responsabilidades para classes e métodos é influenciada pela granularidade da responsabilidade Um único método para imprimir venda Dezenas de métodos para prover um mecanismo de acesso a SGBDR 27

Responsabilidades e Métodos Métodos são implementados para cumprir responsabilidades Podem agir sozinhos ou em colaboração com outros métodos e objetos Exemplo: A classe Venda pode definir um ou mais métodos específicos para cumprir a responsabilidade de imprimir Esse método, por sua vez, pode precisar colaborar com outros objetos, possivelmente enviando mensagens de impressão para cada um dos objetos ItemVenda associados à Venda. 28

Responsabilidades e DI Diagramas de Interação ilustram decisões de atribuição de responsabilidades a objetos. Quais mensagens são enviadas para diferentes classes e objetos? imprimir( ) Implica que objetos Venda têm a responsabilidade de imprimirem a si mesmos. :Venda 1:[para cada] iv:=next( ) 2:imprimir( ) :ItemVenda iv:itemvenda iv:itemvenda Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP. 29

Padrões (Patterns) Um padrão é um par nomeado problema/solução que pode ser aplicado em novos contextos, com conselhos sobre sua aplicação em novas situações e uma discussão sobre as conseqüências de seu uso. Capturam princípios fundamentais da engenharia de software. Em geral, não contêm novas idéias nem soluções originais Codificam soluções existentes comprovadas Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problemas. 30

Padrões GRASP (General Responsibility Assignment Software Patterns) Atribuição competente de responsabilidades a objetos: Cruciais no POO e ocorre na construção dos Diagramas de Interação Padrões: pares de problema/solução que codificam orientações e princípios freqüentemente relacionados com a atribuição de responsabilidades. Cinco padrões mais comuns (Especialista; Criador; Alta Coesão; Baixo Acoplamento; Controlador) 31

Padrão Especialista (Expert) Problema Qual é o princípio básico de atribuição de responsabilidades a objetos? Solução Atribuir responsabilidade para o especialista na informação (a classe que tem a informação necessária para cumprir a responsabilidade). Exemplo: Quem deve ser responsável por conhecer o total de uma venda? Segundo o padrão EXPERT, devemos procurar a classe de objetos que tem a informação necessária para determinar o total. Informação necessária: conhecer todas as instâncias ItemVenda da Venda e o subtotal de cada uma delas. Somente uma instância de venda conhece isso. 32

Padrão Especialista (Expert) Pelo padrão, a classe Venda deve ser a responsável. Venda t:obter_total( ) data hora, status :Venda contém Venda 1..* ItemVenda quantidade * descrito EspecificaçãoProduto descrição preço UPC data hora obter_total() Aqui ocorrem as definições de responsabilidade. Modelo Conceitual Parcial 33

Padrão Especialista (Expert) Mas quem deve ser o responsável por conhecer o subtotal de um ItemVenda? Informação necessária: ItemVenda.quantidade e EspecificaçãoProduto.preço Pelo padrão, a classe ItemVenda deve ser a responsável. t:obter_total( ) :Venda Aqui ocorrem as definições de responsabilidade. 2:st:=obter_subtotal() iv:itemvenda Venda 1*:[para cada] iv:next( ) :ItemVenda :ItemVenda data hora obter_total( ) ItemVenda quantidade obter_subtotal() 34

Padrão Especialista (Expert) Porém, para cumprir essa responsabilidade de conhecer ou informar seu subtotal um ItemVenda precisa conhecer o preço do Item. Portanto, o ItemVenda deve mandar uma mensagem para a EspecificaçãoProduto para saber o preço do item. t:obter_total( ) :Venda 1*:[para cada]iv:next( ) 2:st:=obter_subtotal( ) iv:itemvenda 2.1:p:=obter_preço( ) :Especificação Produto EspecificaçãoProduto Venda descrição preço UPC data hora, status obter_preço( ) obter_total( ) :ItemVenda :ItemVenda ItemVenda Aqui ocorrem as definições de responsabilidade. quantidade obter_subtotal() 35

Padrão Especialista (Expert) Concluindo, para cumprir a responsabilidade de conhecer e informar o total da venda, três responsabilidades foram atribuídas a três classes de objetos: Classe Responsabilidade Venda Conhecer total da venda ItemVenda Conhecer subtotal do item EspecificaçãoProduto Conhecer preço do produto 36

Padrão Especialista (Expert) Benefícios Mantém o encapsulamento, pois objetos usam sua própria informação, favorecendo o baixo acoplamento Comportamento é distribuído através das classes que tem a informação necessária para cumprir a responsabilidade, obtendo alta coesão 37

Princípios Básicos Acoplamento1 O acoplamento é uma medida da interconexão entre os módulos de uma estrutura de software ; Coesão1 Um módulo coeso executa uma única tarefa dentro do procedimento de software, exigindo pouca interação com procedimentos executados em outras partes de um programa. 1 Segundo o autor Pressman. 38

Padrão Criador (Creator) Problema Quem deve ser responsável por criar uma nova instância de alguma classe (A)? Solução Atribuir à classe B a responsabilidade de criar uma instância da classe A se umas das seguintes condições forem verdadeiras: Algumas vezes um criador é encontrado ao observar a classe que tem os dados iniciais que serão passados na criação. B agrega instâncias de A (*) B contém instâncias de A (*) B registra instâncias de A B usa instâncias de A de maneira muita próxima B tem os dados de inicialização para criar instâncias de A (B portanto é um especialista na criação de A) (*) priorizar 39

Padrão Criador (Creator) Exemplo Quem deve ser responsável por criar uma instância de ItemVenda? Pelo padrão, Venda deve ser responsável. criar_iv(quantidade) :Venda 1:criar_iv(quantidade) Venda data hora criar_iv( ) obter_total( ) :ItemVenda Benefícios (garante baixo acoplamento) 40

Padrão Baixo Acoplamento (Low Coupling) Problema Como conseguir menor dependência (entre as classes) e maior reuso? Solução Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo. Acoplamento Baixo: Não depende de outros elementos (classes) Alto: Depende de muitos outros elementos (classes) Tais classes podem ter os seguintes problemas: mudanças em classes relacionadas forçam mudanças locais; difíceis de compreender isoladamente; difíceis de serem reutilizadas. 41

Padrão Baixo Acoplamento (Low Coupling) Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, poderia ser POST (uma vez que POST registra pagamentos no mundo real) RegistrarPagamento( ) :POST 1:criar( ) 2:adicionar_pagamento (p) p:pagamento :Venda 42

Padrão Baixo Acoplamento (Low Coupling) Uma solução melhor, do ponto de vista do padrão, que preserva baixo acoplamento é a própria Venda criar o Pagamento: RegistrarPagamento( ) :POST 1:RegistrarPagamento( ) :Venda 1.1:criar( ) :Pagamento 43

Padrão Baixo Acoplamento (Low Coupling) Benefícios Responsabilidade não é (ou é pouco) afetada por mudanças em outros componentes. Responsabilidade é mais simples de entender isoladamente. Maior chance para reuso. 44

Padrão Alta Coesão (High Cohesion) Problema Como manter a complexidade (das classes) sob controle? Solução Atribuir uma responsabilidade de modo que a coesão permaneça alta. Coesão Em POO a Coesão Funcional mede o quanto as responsabilidade s de um elemento são fortemente relacionadas. Alta: Um elemento com responsabilidades altamente relacionadas e que não executa um grande volume de trabalho. Baixa: Uma classe faz muitas coisas não relacionadas ou executa muitas tarefas (indesejável pois fica difícil de: compreender, reutilizar e manter; e são constantemente afetadas pelas mudanças) 45

Padrão Alta Coesão (High Cohesion) Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, seria POST. Mas, se POST for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e sem coesão. :POST RealizarPagamento( ) :Venda criar( ) p:pagamento adicionar_pagamento (p) 46

Padrão Alta Coesão (High Cohesion) Exemplo Outra forma para atribuição da responsabilidade RealizarPagamento que favorece uma coesão mais alta :POST RealizarPagamento( ) :Venda RealizarPagamento( ) criar( ) :Pagamento 47

Padrão Alta Coesão (High Cohesion) Níveis de coesão Muito baixa Um única classe é responsável por muitas coisas em áreas funcionais muito diferentes. Baixa Um classe é a única responsável por uma tarefa complexa em uma área funcional. Moderada Uma classe tem peso leve e responsabilidades exclusivas em algumas áreas logicamente relacionadas ao conceito da classe, mas não uma com a outra. Alta Uma classe tem responsabilidades moderadas em uma área funcional e colabora com outras classes para realizar tarefas. 48

Padrão Alta Coesão (High Cohesion) Benefícios Aumento da clareza e compreensão do projeto Simplificação da manutenção Favorece baixo acoplamento Reuso facilitado 49

Padrão Controlador Problema: qual é o primeiro objeto, além da camada de IU, que recebe e coordena (controla) uma operação do sistema? Solução: atribua a responsabilidade a uma classe que representa uma das seguintes escolhas: Representa o sistema global, um objeto raiz, um dispositivo dentro do qual o software está sendo processado, ou um subsistema importante essas são todas variantes de um controlador fachada (facade controller). Representa um cenário de um casos de uso (controlador de caso de uso) dentro do qual ocorre o evento do sistema, freqüentemente denominado TratadorDo<NomeDoCasoDeUso>, CoordenadorDo<NomeDoCasoDeUso> ou SeçãoDo<NomeDoCasoDeUso>. Use a mesma classe controladora para todos os eventos do sistema do mesmo cenário do caso de uso. Informalmente, uma seção é uma instância de conversação com um ator. Seções podem ser de qq tamanho, mas freqüentemente são organizadas em casos de uso (ou seções de caso de uso).

Obs: classes de IU não devem executar as tarefas associadas aos eventos de sistema, somente devem receber esses eventos e os delegar a uma classe do tipo controlador. Quem deve ser o controlador para o evento

Padrão Controlador A primeira categoria de controlador é um controlador fachada, que representa todo o sistema, um dispositivo ou um subsistema. A idéia é escolher algum nome de classe que sugira uma capa ou fachada, sobre as outras camadas da aplicação e que forneça o ponto principal de chamada de serviço da camada de IU para as outras camadas. A fachada pode ser uma abstração de uma unidade física global, por exemplo, Registradora, CentralComutadoraDeTelecomunicação, Telefone, Robô,...; uma classe que representa todo o sistema de software, por ex, SistemaPDV, ou qq outro conceito que o projetista escolha para representar todo o sistema ou um subsistema, como por ex JogoDeXadrez, no caso de um software de jogos. Os controladores fachada são adequados quanto não existem demasiados eventos de sistema ou quando não é possível, para a interface do usuário, redirecionar mensagens de eventos de sistema para controladores alternativos.

Padrão Controlador Outra categoria de controlador é o controlador de caso de uso, onde há um controlador para cada caso de uso. Essa espécie de controlador não é um objeto do domínio; é uma construção artificial para apoiar o sistema. Por exemplo, se a aplicação ProxGer contém casos de uso tais como Processar Vendas e Tratar Devoluções, então pode haver um classe TratadorDeProcessarVenda, e assim por diante. Considere essa alternativa quando colocar a responsabilidade em um controlador fachada levar a projetos com baixa coesão ou forte acoplamente, tipicamente, quando o controlador fachada está se tornando sobrecarregado, com excesso de responsabilidades.

Diagramas de Classe Um diagrama de classe ilustra as especificações de software para as classes e interfaces do sistema Inclui: Classes, associações e atributos Interfaces (com operações e constantes) Métodos Informação sobre o tipo dos atributos Navegabilidade Dependências UML não diferencia modelo conceitual de diagrama de classe (o termo classe de implementação é usado para distinguir o segundo do primeiro)

Diagramas de Classe Diagrama parcial para as classes POST e Venda no sistema POST: informações sobre tipos Venda POST 1 entraritem( ) métodos captura 1 data, hora status:boolean obter_total( ) navegabilidade

Como Fazer um Diagrama de Classe Regras úteis: 1. Construir o diagrama de classes por partes, evoluí-lo; 2. Identificar todas as classes participantes da solução, propostas pelos diagramas de interação; 3. Desenhar as classes em um diagrama de classe; 4. Incluir os atributos identificados no modelo conceitual; 5. Adicionar métodos tal como identificados nos diagramas de interação; 6. Adicionar informação sobre tipos aos atributos e métodos; 7. Adicionar as associações necessárias para permitir a visibilidade de atributos; 8. Adicionar setas de navegabilidade para indicar a direção da visibilidade de atributos; 9. Adicionar relacionamentos de dependência para indicar outros tipos de visibilidade. 57

Modelo de Conceitual X Diagrama de Classe Modelo Conceitual: abstração de conceitos do mundo real Diagrama de Classe: especificação de componentes de software Venda POST Modelo Conceitual 1 captura 1 Venda POST Diagrama de Classe 1 entraritem( ) data, hora status:boolean captura 1 data, hora status:boolean obter_total( )

POST Criando Diagramas de Classe Identificando classes e atributos Observar os DIs e o Modelo Conceitual POST CataladoDeProdutos quantidade Loja nome endereco Venda data hora status EspecificacaoDeProduto descricao preco UPC ItemVenda quantidade Pagamento quantia

Criando Diagramas de Classe para o Sistema POST Adicionando nomes aos métodos Observe as mensagens dos DIs POST CataladoDeProdutos quantidade TerminarVenda() EntrarItem() RegistrarPagamento() Loja nome endereco EspecificacaoDeProduto descricao preco UPC Especificação() Venda ItemVenda data hora status quantidade Completar() Criar_iv() RealizarPagamento() Obter_Total() Obter_Subtotal() Pagamento quantia

Criando Diagramas de Classe para o Sistema POST Adicionando associações e navegabilidade Investigar os DI EspecificacaoDeProduto Loja nome endereco usa 1 1 descricao preco UPC CataladoDeProdutos quantidade 1 contém 1 1..* Especificação() possui 1 1 POST busca_em 1 1 1 1 * ItemVenda Venda captura TerminarVenda() EntrarItem() RegistrarPagamento() descreve data hora status Completar() Criar_iv() RealizarPagamento() Obter_Total() contém 1 quantidade 1..* Obter_Subtotal() pago_por 1 1 Pagamento quantia Navegabilidade implica visibilidade, geralmente visibilidade de atributo.

Bibliografia BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio de Janeiro: Elsevier, 2000. LARMAN, Craig. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman, 2007. WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Elsevier, 2004. BRAGA, R. V. Notas de Aula. ICMC-USP, 2007. DÓRIA, E. S. Notas de Aula. FIPP-UNOESTE, 2006. MEDEIROS, Ernani; Desenvolvendo com UML Definitivo 2.0. São Paulo: Pearson Makron Books, 2004. 62