Apostila Análise e Projeto Orientados por Objetos - UML

Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 1

FABRAI

FACULDADE BRASILEIRA DE INFORMÁTICA

CURSO DE TECNOLOGIA EM PROCESSAMENTO DE DADOS

ANÁLISE E PROJETO DE SISTEMAS II

(Análise e Projeto Orientados por Objetos - UML) Parte I

Prof. Rodrigo de Matos Vargas

[email protected] http://www.rmatos.com.br

Proibida reprodução desta apostila por quaisquer meio

@Copyright 2003 By Rodrigo de Matos Vargas Todos os direitos reservados


ÍNDICE

1 – Plano de Estudo Pág 3 2- Bibliografia Pág 4 3- Capítulo I – Introdução Pág 5 4- Capítulo II – Conceitos Básicos Programação Orientada a Objetos Pág 16 5- Capítulo III – Modelagem através UML Pág 20 5.1 – Diagrama de Estudo de Caso Pág 23 5.2 -Introdução a Classe Pág 30 5.3 – Diagrama de Classe Pág 34 5.4 – Diagrama de Objetos Pág 56 5.5 – Diagrama de Interação Pág 58 5.6 – Diagrama de Estado Pág 59 5.7 – Diagrama de Atividade Pág 60 5.8 – Diagrama de Implantação


1. Plano de Estudo 1.Introdução ( 6 h/a)

Conceitos de Orientação por Objetos Visão geral da Análise e Projeto OO Vantagens e Desvantagens da Análise e Projeto OO Metodologias OO Visão geral da UML 2.Análise Orientada por Objetos através da UML (40 h/a) Diagrama de Caso de Uso Diagrama de Classes Herança Simples e Múltipla Associação unária, binária e ternária. Agregação Empacotamento Diagrama de Seqüência Diagrama de Colaboração Diagrama de Estado Diagrama de Atividade Diagrama de Objetos Estudos de Casos Práticos 3.Projeto Orientado por Objetos (14 h/a) Modelagem da Arquitetura Diagrama de Componentes Diagrama de Implantação Projeto de Banco de Dados OO Diagrama de Classes Objeto Relacional Projeto de Interface Estudos de Casos Práticos


2. Bibliografia Bibliografia Básica:

[1] Furlan, José Davi. Modelagem de Objetos através da UML – Análise e Desenho Orientados a Objeto. São Paulo, Makron Books, 1998. [2] Booch, Grady; Rumbaugh, James and Jacobson, Ivair. UML – Guia do Usuário. Rio de Janeiro, Campus, 2000. [3] Larman, Craig. Utilizando UML e Padrões – Uma Introdução à Análise e ao Projeto Orientados a Objetos. Porto Alegre, Bookman, 2000. Bibliografia Complementar: [4] Booch, Grady. Object-Oriented Analysis and Design with Applications, Second Edition, Addison-Wesley, 1994. ISBN:0-8053-5340-2 [5] Yourdon, Edward and Argila, Carl. Análise e Projeto Orientados a Objetos. Estudos de caso. Makron Books, São Paulo,1999. [6] Coad, Peter e Yourdon, Edward. Análise Baseada em Objetos. Campos, 1996. [7] Martin, James. Análise e Projeto Orientados a Objetos. Macron Books, 1995. [8] Rumbaugh, James. et al. Modelagem e Projetos Baseados em Objetos. Campos, 1994. [9] Shlaer, Sally. Análise de Sistemas Orientado para Objetos. Makron Books, 1994.


CAPÍTULO I - INTRODUÇÃO

I – Introdução ao Desenvolvimento de Software Software é um produto da inteligência humana, é também um dos poucos produtos capaz de absorver a idéia de alguém e colocar a disposição dos outros. Existem livros, fitas e outros meios, mas nenhum deles possui tamanha interatividade igual ao software. Figura 01 Na construção de um software, além de criatividade, é necessário conhecimento técnico e lógico além de um trabalho disciplinado. A atividade de programação é apenas uma das etapas do trabalho de desenvolvimento de um software. A Engenharia de Software é a ciência aplicada na transformação do computador em uma ferramenta de trabalho para seus utilizadores.O Software hoje está mais que presente, e faz parte de nossas vidas em tudo que utilizamos, desde um telefone até ao avião. As práticas da Engenharia de Software se intensificaram com o agravamento dos problemas relativos ao Software, já afirmava Pressman ( 1995 ) :

• As sofisticações dos Problemas ultrapassaram nossa capacidade de construir um Software que extraia toda a potencialidade do Hardware.

• Nossa capacidade de construir Software de qualidade não pode acompanhar a demanda por novas aplicações.

• Nossa capacidade de manter Softwares existentes foi ameaçada por projetos ruins e recursos inadequados.

Observa-se que a Engenharia de Software trata intimamente das limitações da capacidade humana em criar software.

Sistema de Software Idéia

Desenvolvedor

Habilidade

Usuário Especialista


II – A importância da Modelagem

É fácil observar que outras áreas do conhecimento, que se utilizam um produto final, utiliza-se de um projeto anterior para chegar ao produto. Na engenharia antes da construção temos a planta (projeto da casa) e este projeto é que permite ao usuário (proprietário da casa) de avaliar e garantir que o produto final saía de acordo ou o mais próximo possível do produto final.

A Engenharia de Software procura trazer para a ciência da computação essas lições e incentivar a elaboração de um projeto de Software, em um modelo orientado a objetos. Projetar Software nada mais é que criar um modelo do software, um modelo que permita que o usuário consiga visualizar antes mesmo do produto pronto, qual será o produto final e seu comportamento.

A modelagem consiste em construir um modelo visando reduzir a incerteza do Software, aproximando-se ao máximo a expectativa da realização. A modelagem Orientada a Objetos tem como objetivo, além do citado acima, de padronizar, automatizar, incentivar a reutilização de componentes e aumentar a maturidade em uma equipe de desenvolvimento de um projeto. III – Processos de Desenvolvimento de Software O Ciclo de Vida Figura 02 – Ciclo de Vida

1 Levantamento 2- Análise 3- Projeto

4- Implementação 5- Geração Testes 6- Manuais

7- Controle Qualidade

8- Conversão do Banco de Dados

9- Instalação


Nesta Disciplina estudaremos a atividade de Análise de Sistemas

Figura 03 – Análise de Sistemas Objetivos Básicos:

• Desenvolver a especificação lógica, independente do Software e Hardware utilizado.

• Elaborar um Modelo de Sistema (Ex: Planta de uma Casa) • Analisar as características importantes ao sistema, tais como, levantamento dos

dados, processos e informações que usuário necessita. • Documentar o processo de análise, para que se tenha uma fidelidade no

momento da construção do Software por parte dos projetistas e Desenvolvedores.

Técnicas Básicas de Análise:

• Análise Estruturada • Análise Essencial • Análise Orientada a Objetos

Análise Estruturada Análise Essencial Análise Orientada a

Objetos Surgiu em 74 – Crise de Software

Surgiu em 1982 (J. Palmer e S. McMenamin)

1990 – Diversos Autores

Baseada em DER / DFD ( DC + DFD Nível um + DFD Expandido ) DHF / Especificação dos Processos e Dicionário de Dados

Mais Fácil de Entender os DFds / Mais completa / Mais simples nos DFDs (eventos baseado em estímulos e respostas)

Diagrama de Classe Diagrama de Caso de Uso Diagrama de Interação Diagrama de Estado Diagrama de Implementação

1.Levanta-mento

Usuários

2.2.AnáliseAnálise

Dadospara o Modelo

Rotinasdo Usuário

Direção

RestriçõesEspecificação

da Análise

6.Manuais

Especificaçãoda Documentação

3.Projeto1.

Levanta-mento

Usuários

2.2.AnáliseAnálise

Dadospara o Modelo

Rotinasdo Usuário

Direção

RestriçõesEspecificação

da Análise

6.Manuais

Especificaçãoda Documentação

3.Projeto


Abordagem Top Down Foco em Processos

Abordagem Middle – Up – Down – Foco em Funções, Dados e comportamento do sistema de forma integrada.

Coletânea de Objetos que interagem entre si.

DFD pode se tornar muito difícil Abordagem Top Down não se mostrou eficiente na prática

Não serve para sistema baseado em Real Time Sistema Complexo se mostrou inadequada As fases de Análise / Projeto e Implementação apresentam um descontínuo

Busca a estrutura do Problema e não apenas da informação. Mostra-se extremamente eficaz. Linguagens OO complementam esta abordagem

Figura 04 – Quadro Comparativo Em Síntese

A Análise Orientada a Objetos é formada por um conjunto de objetos que interagem entre si, apresentam características próprias representadas pelos atributos e operações.

A Análise Tradicional baseia-se na idéia que um sistema é um conjunto de programas que executam processos sobre os dados. Motivos que Levaram ao surgimento da AOO

• Dificuldade de resolver problemas complexos com o uso das análises tradicionais

• Surgimento de linguagens de Programação Orientada a Objetos (C++) • Necessidade de Desenvolvimento de sistemas baseado em Real Time com muito

mais freqüência Benefícios da Análise e Projeto Orientado a Objetos

• Reusabilidade => Reaproveitamento de classes (Bibliotecas) em diversos sistemas

• Interoperabilidade => Classe podem ser usadas por diversas empresas em plataformas variadas.

• Classes absorvem a complexidade => Complexos componentes podem ser construídos a partir de componentes já existentes (Herança)

• Manutenção mais fácil => Independência entre as classes ajuda no processo de manutenção. Cada classe executa suas operações independentemente.


• Modelagem mais realística => Análise, Projeto e Implementação usam o mesmo paradigma.

Justificativa de Mudança “Objetos já existem na natureza antes de haver qualquer tipo de aplicação deles pelo negócio: Equipamentos, pessoas, minerais, etc..., existem por si só, apresentam características peculiares representadas por seus atributos e, adiante, pelo seu comportamento no mundo real”. Problemas da Análise e Projeto Orientado a objetos

• Fundamentação teórica da AOO não é simples • Os SGBDs ainda não são totalmente orientado a objetos • A mudança de mentalidade e introdução de uma nova tecnologia sempre traz

desconfiança • Existência de várias abordagens para APOO

UML – Unified Modeling Language Características: • Uma tentativa de padronização das linguagens de modelagem para APOO criada a

partir da Rational Corporation (http://www.rational.com) e aprovada pela OMG – Object Management Group (http://www.omg.org). As revisões da UML encontram-se em http://uml.shl.com.

• A UML não é uma metodologia e sim uma linguagem de modelagem que procura integrar as melhores práticas existentes no mercado.

• “É uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software...”.

• “É um sistema de notação dirigida à modelagem de sistemas, usando conceitos orientados a objetos”.

• Tem se tornado um padrão mundial utilizado por desenvolvedores, autores e fornecedores de ferramentas Upper e Meta CASE.

• É independente de linguagens de programação OO.


Elementos Fundamentais da Análise OO

O texto a seguir foi adaptado do livro texto Modelagem de Objetos através da UML –

Análise e Desenho Orientados a Objeto, de José Davi Furlan. Diretamente derivada dos conceitos da programação e do projeto orientado a objeto, a análise e o desenho1 orientados a objeto são certamente a mais nova das abordagens de desenvolvimento de sistemas. A tecnologia de objetos apresenta componentes chaves que fundamentam a mudança de enfoque no processo de modelagem e desenvolvimento de aplicações, trazendo benefícios intrínsecos à filosofia. Rumbaugh define orientação a objetos como "uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma única entidade". O sucesso em desenvolvimento de software depende em grande parte do conhecimento que não só envolve programação e habilidades de gerenciamento, mas também conhecimento e compreensão das mais recentes inovações na indústria de software. Um fato curioso no campo da tecnologia da informação é que sempre a última inovação tecnológica nos parece ser definitiva e que nada mais será possível ser inventado para suplantá-la. Isso ocorreu com todas as tecnologias do passado, e certamente virá o dia em que também acontecerá com a tecnologia de objetos. Analisando-se o comportamento de evolução dos enfoques de desenvolvimento precedentes, vemos que a última proposta apresentada - a Engenharia da Informação (abrangendo modelagem funcional, de dados e estratégica) e os bancos de dados relacionais - começou a tomar vulto em nível mundial no final da década de 80 decolando de fato a partir do início dos anos 90. A supor essa mesma evolução para a orientação a objeto, é provável que até o ano 2000 essa tecnologia ainda esteja tentando ganhar espaço nas organizações e que realmente decole a partir de então. Todavia, há uma curva exponencial de time-to-market que diz que as inovações ocorrem em períodos de tempo cada vez mais curtos. Se assim for, tal expectativa poderá ser antecipada. A tecnologia de objetos oferece modularidade de seus elementos podendo-se tomar um subconjunto existente e integrá-lo de uma maneira diferente em outra parte do sistema - uma aplicação no universo de objetos consiste de um conjunto de blocos de construção autocontidos (seff-contained code) e predefinidos que podem ser localizados, reparados ou substituídos. A construção de código autocontido propicia o teste completo antes de ser usado dentro da lógica do sistema de informação. Apresenta também uma correspondência com o mundo real, visualizando objetos da natureza conforme são, individualizados e caracterizados com finalidade própria. Tais objetos permitem ser combinados ou utilizados separadamente, pois, em tese, apresentam baixa dependência externa e alta coesão interna de seus componentes, o que permite promover substituições sem afetar interconexões ou interferir com a

1 A análise é a parte do processo de desenvolvimento de software com o propósito primário de formular um modelo de domínio de problema; já o desenho é parte do processo que visa decidir como esse modelo será implementado.


operação dos demais objetos. Possibilita ainda incrementações graduais de componentes aos já instalados, ampliando a abrangência do sistema. A combinação de módulos provê inicialmente um nível básico de funcionalidade que é estendido sucessivamente para cobrir novas situações, em um processo contínuo de progresso da aplicação perante os usuários. Por fim, apresenta um forte direcionamento ao uso de artefatos preexistentes que são criados uma única vez e disseminados ao longo da estrutura sistêmica resultante - a reutilização facilita o emprego de conceitos similares em situações apropriadas. Faremos a seguir, uma breve introdução aos principais conceitos da orientação a objeto. IV – Modelagem Orientada a Objetos

Quando Matt Flavin criou o primeiro método de AOO, empregava o que hoje é conhecido como modelo entidade / relacionamento estendido como base do enfoque. Nas últimas décadas houve o aprimoramento constante das técnicas e metodologias. Métodos de Modelagens orientados a objetos começaram a aparecer entre a década de 70 e meados dos anos 80. Apesar da diversidade conceitual e bibliográfica, muitos usuários não encontraram satisfação completa nos enfoques disponíveis. Todos os métodos têm suportado, no entanto, os mesmos conceitos básicos. Dados que os métodos Booch e OMT estavam crescendo independentemente e sendo reconhecidos pela comunidade seus autores Grady Rooch e James Rumbaugh juntaram forças e através da Rational Corporation lançaram um rascunho de um método unificado, como foi chamado a princípio. Também de m 1995, Ivar Jacobson juntou-se a equipe de desenvolvimento fundindo o método OOSE (Object-Oriented Software Engineering). Como autores de modelagem unificada, eles trataram de criar uma linguagem de modelagem unificada que tratasse de assuntos de escalas inerentes, complexos e de missão crítica. Muitos reconheceram este esforço e a UML (Unified Modeling Language) surgiu e ganhou parceiro importante. Em Janeiro de 1997, surgiu a versão 1.0 da UML, sendo uma linguagem expressiva, poderosa e geralmente aplicável. E o melhor, não é proprietária e aberta a todos. Em novembro de 1997, a UML foi aprovada pela OMG- Object Management Group- então a guerra dos métodos OO tinha chegado ao fim. A partir desse momento a OMG, através de seu grupo de revisão RTF – Revision Task Force – passou a assumir a responsabilidade da evolução da UML. A UML pode ser usada para :

• Mostrar as fronteiras de um sistema e suas funções utilizando atores e casos de uso

• Ilustrar a realização de casos de usos com diagramas de interação • Representar uma estrutura estática de um sistema utilizando diagramas

de classe • Modelar o comportamento de objetos através dos diagramas de transição

de estado


• Revelar a arquitetura de implementação física com diagramas de

comportamento e de implantação • Entender sua funcionalidade através de estereótipos.

A UML vai além de uma simples padronização em busca de uma notação unificada, uma vez que contem conceitos novos que não são encontrados em outros métodos orientados a objetos. A UML é uma linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema e poder ser utilizado com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação. A UML é uma linguagem de modelagem, não uma metodologia. Muitas metodologias consistem, pelo menos em princípio de uma linguagem de modelagem, e um procedimento de uso dessa linguagem. A UML não prescreve explicitamente esse procedimento de utilização. Apesar de ser valiosa uma padronização de uma metodologia, uma linguagem padrão já é mais que suficiente. A metodologia Objectory ( Rational Corporation Process) utilizando a UML é uma referência em desenvolvimento orientado a objeto.

Em seu estado atual a UML define uma notação e um metamodelo. A notação é o material gráfico visto em modelos, é a sintaxe da linguagem de modelagem. Por exemplo, a notação de diagrama de classe, associação e multiplicidade. Claro que isso conduz à pergunta do que exatamente isto significa. Tecnologia Back End para Orientação a Objeto

A tecnologia de banco de dados tem permitido o armazenamento, recuperação e

processamento de dados que descrevem entidades existentes no mundo real. Já estamos chegando na 5 geração de banco de dados. Geração Suporte 1 Arquivos seqüenciais – processamento batch 2 Banco de Dados Hierárquico 3 Banco de Dados em Rede 4 Banco de Dados Relacional 5 Banco de Objetos Atualmente Banco de Dados relacionais prevalecem no mercado, mas os fabricantes já estão desenvolvendo e soltando para o mercado o Banco de Objetos. À medida que a complexidade do software vai aumentando o desempenho do Banco de Dados Relacional cai assustadoramente. Apesar dos fornecedores assegurarem que seus produtos são capazes de manipular estruturas complexas, a mudança para este tipo de arquitetura tem seu preço. Para se utilizar Banco de Objetos, os profissionais necessitam investir razoável parcela de tempo e esforços na fase de modelagem. Levando-se em consideração que ainda exista obstáculos para a utilização deste tipo de arquitetura, os Banco de Objetos possuem um extraordinário potencial de crescimento.


Obs: Banco de Dados relacional estendido e objeto relacional seguem um padrão híbrido entre relacional e objeto, ou seja, a interface, operações e quareis podem residir tanto no código da aplicação quanto no Banco de Dados (na forma de Chore Procederes). Devido ao enorme dinamismo do mercado tecnológico, podemos citar abaixo alguns dos principais fabricantes e distribuidores de Banco de Objetos. Fabricante Produto Características GEMSTONE GEMSTONE Arquitetura Cliente / Servidor

Ambiente de Desenvolvimento Visual Suporta C++, Cobol, Fortran e outros

OBJECT DESIGN

OBJECTSTORE Aplicações intensiva em dados Compatível com C++ Interface de aplicação acompanha o produto Ferramenta de Programação Energize Visual C++

VERSANT OBJECT TECHNOLOGY

VERSANT Criar Objetos reutilizáveis e modificáveis Conceito de Banco de Dados distribuído que está diretamente ligado a linguagens orientadas a objetos Suporta aplicações Cliente / Servidor Inclui uma ferramenta gráfica

OBJECTIVITY / DB

OBJECTIVITY / DB

Ambiente Integrado de desenvolvimento Usuários podem definir e manipular objetos Manipulação complexa de dados

OBJECT SYSTEM SF

EASY / DB Linguagens de programação C++, Ada Linguagem interativa de consulta O-SQL Capacidade de manipulação de erros, conflitos e tratamento de exceções.

ONTOS / DB ONTOS DB Banco de Objetos Distribuído Modelo Cliente / Servidor Linguagens Genéricas C++ Utiliza-se de SQL Administrador e Manipulador gráfico de dados

COMPUTER ASSOCIATES

JASMINE Plataforma Cliente / Servidor e Internet O Gerenciador de Banco de Objetos e de desenvolvimento é totalmente voltado a orientação a objeto Suporte a herança Múltipla / classes / métodos Cada objeto tem um único identificador Vem com ODQL linguagem de desenvolvimento


Base de Dados Objeto / Relacional Especialistas dizem que há pouca coisa em comum entre o modelo de objetos e o modelo relacional. Entretanto na prática existem similaridades.

• A estrutura de uma tabela => A estrutura de atributos de uma classe • Índice de uma tabela => índice de todos ou parte da estrutura de atributos de

uma classe • Visão Modelo Entidade / Relacionamento => Pacotes e interfaces de classes

que ditam como a classe é acessada.

Podemos citar outras semelhanças entre os dois modelos, mas este não é nosso objetivo. Para entendermos um modelo banco de dados objeto tem de incorporar algumas mudanças. Essas mudanças serão enfocadas em nosso próximo capítulo. Enquanto a tecnologia de banco de objetos não for adotada em escala, a estratégia de incorporação da orientação a objeto irá certamente permanecer durante a fase de modelagem do negócio sendo implementada em seguida em banco de dados relacionais ou híbridos. Tecnologia Front-End para Orientação a Objeto As linguagens de programação orientada a objetos evoluíram, trabalhando atualmente com funções GUI ( Graphical User Interface ), ferramentas case e programação visual. O Smalltalk foi a primeira linguagem orientada a objetos, desenvolvida pela Xerox. De uma maneira geral uma linguagem deve possui quatro elementos de modo que possa suportar a programação orientada a objetos:

• Proteção de dados => utilização de módulos • Abstração de dados => Definição de um tipo abstrato de dados • Coesão Dinâmica => Módulo chamador recebe o endereço da rotina associando

uma mensagem • Hereditariedade => Herança

As principais linguagens de programação orientada a objetos incluem o C++, e

atualmente com maior ênfase temos o Java. O Java é uma linguagem desenvolvida pela Sun Microsystems Inc, é de fácil aprendizado e utilização, poderosa e principalmente com enorme portabilidade. Sua sintaxe é próxima ao C++ favorecendo aqueles que já trabalharam com esta linguagem.

Enquanto as linguagens procedurais estão voltadas para processos e dados, as linguagens de programação orientadas a objetos visam os objetos e as mensagens. A programação orientada a objetos não separa os dados dos processos e sim traz juntos esses dois conceitos. Não há, entretanto um consenso quanto à definição de linguagem orientada a objeto e os conceitos na UML. Mas existe sim uma generalização entre os conceitos de UML e a linguagem orientada a objetos.


Elementos da UML Java Ação Declarações Atributo Constante (Imutável) Final Estático Atributo de Classe Variável de Classe – estático Atributo de Objeto Variável de Instância Atenção: Quadro comparativo poderá ser encontrado no livro Modelagem de Objetos através da UML – autor José Davi Furlan Ferramentas de Modelagem A necessidade de novos produtos, pela demanda da programação orientada a objetos levou a indústria do software a desenvolver novos produtos. Algumas ferramentas suportam a UML, como é o caso da Rational Rose da Rational Corporation. Ao avaliar Ferramentas de modelagem devemos considerar os seguintes fatores:

• Métodos Suportados e ambiente tecnológico • Suporte aos diagramas da linguagem de modelagem • Participação no mercado de ferramentas • Presença de um repositório para armazenar dados • Projetos de grande porte • Navegação no modelo com rastreamento de um elemento • Ambiente multiusuário • Engenharia Reversa • Complexidade das Ferramentas • Integração com outras ferramentas • Preço • Treinamento Oferecido

Várias ferramentas estão surgindo e avaliação de cada uma, deverá ser feita de

forma independente e imparcial.


CAPÍTULO II – CONCEITOS BÁSICOS

Conceitos Básicos da Programação Orientada a Objetos

Diversos são os princípios e conceitos que a análise e projeto orientado a objeto baseia-se. Os principais conceitos serão listados e discutidos nos próximos tópicos. Conceitos e Princípios

• Objeto • Encapsulamento • Mensagens • Tipos, Classes • Herança • Polimorfismo

Objeto Como já foi falado um dos principais elementos da programação orientada a objetos é o próprio objeto. Um objeto nada mais é que uma ocorrência específica de uma classe e é similar a uma entidade no modelo entidade / relacionamento até no ponto que uma coleção de dados une-se para formar um tema em comum. Exemplificando, temos o nome e endereço de uma editora, a Makron Books. Os dados nome e endereço pertencem à entidade [organização] ou ao objeto [Makron Books]. A diferença entre objeto e entidade é que o primeiro é uma ocorrência de uma classe. Um objeto poderá encapsular operações, atributos, operações podendo estas encapsulações ser privadas ou públicas. Exemplo : Classe x Objeto

Veículos Funcionários

GOX 3444

GOL 1243

Maria, Caixa

Pedro, Gerente

Classes

Objetos


Classe Classe é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações. Representam uma idéia ou um conceito simples e categoriza objetos que possuem propriedades similares. Todos os objetos de uma classe possuem as mesmas definições, mas podem possuir valores diferentes nos dados, respondendo de modo diferente as mensagens enviadas. SuperClasse e SubClasse Na criação de classe existe a possibilidade de ocorrer uma conexão de elementos no modelo Pai / Filho em que uma classe filha ( Subclasse ) herda as propriedades de seu pai ( superclasse ) direta ou indiretamente. Cada classe pode ter suas propriedades particulares herdadas diretamente da classe pai, podendo ser substituídas ou mascaradas nessa transição. Novas propriedades poderão ser acrescentadas a classe filha. Todo esse processo narrado acima descreve mais um dos princípios da orientação a objeto: Herança. Atenção: Alguns autores mudam o termo superclasse para supertipo e subclasse para subtipo, mas a essência do propósito continua o mesmo. Outras terminologias também poderão ser encontradas. Herança É a capacidade de um novo objeto tomar atributos e operações de um objeto existente, permitindo criar classes complexas sem ter que repetir o código. Se uma classe herda comportamento e atributos de mais de uma classe damos a ela o nome de herança múltipla, uma variação semântica de generalização, na qual um tipo pode ter mais de um supertipo.

Classe Automóvel

Automóvel Esportivo

Porsche

A Classe Automóvel contém informações como potência , passageiros, etc... A sub Classe Esportivo herda todas essas propriedades e acrescenta outras. Por Fim Porsche herda todas as propriedades das classes acima.


Mensagens Os objetos se comunicam através de mensagens, isto é, um sinal é enviado a um objeto requisitando um serviço, as operações são executadas e o resultado da operação é enviado ao objeto solicitante. Uma mensagem é a chamada de uma função de um objeto, o acionamento de uma operação encapsulada no objeto de destino, feita a partir do objeto de origem. A informação transmitida é passada ao objeto de destino através dos parâmetros de uma função, enquanto a resposta é passada pelo parâmetro de retorno da função. Para que os objetos se comuniquem é necessário que haja algum tipo de ligação / vínculo entre eles. Esses vínculos podem ser relacionamentos entre os objetos. Exemplo: O controle remoto envia uma mensagem para a tv, mas essa só consegue interpretar a mensagem por que possui uma interface de recepção. A definição das interfaces e das mensagens a serem implementadas nos objetos é uma importante atividade de modelagem de software, é feita na fase de design de um projeto de software. Polimorfismo Polimorfismo é a propriedade que o emissor de uma mensagem não precisa saber a instância da classe que recebe esta mensagem. Essa propriedade leva ao fato de que uma mensagem pode ser interpretada de várias formas daí o nome Polimorfismo. Geralmente as pessoas confundem polimorfismo e encapsulamento porque ambos referem-se ao ocultamento da implementação do mundo externo ao objeto.

Controle Remoto

Envia

Televisão

Po lim orf ism o

Saldo(C orrentista)

SALD O

Saldo Poupança

Saldo Fundo de A ções Saldo fundo Balanceado

Saldo Renda F ixa


Adicionalmente aos conceitos vistos acima podemos destacar ainda

os conceitos de dependência e coesão de classe. Dependência refere-se ao conhecimento que uma classe possui de outra – o ideal é a minimização da dependência para evitar impactos na modificação de uma classe sobre a outra. Coesão é uma medida de integridade conceitual de uma classe – o objetivo é o de maximizar a coesão para assegurar o agrupamento de operações e com isso reduzir esforços de manutenção. Segue abaixo uma breve descrição dos principais conceitos da teoria de objetos:

Palavra – Chave Definição Exemplo Atributo Característica particular de uma

ocorrência da classe Indivíduo possui nome, sexo e data de nascimento.

Classe Agrupamento de objetos similares que apresentam os mesmos atributos e operações

Veículo, caracterizado pelos veículos do mundo.

Encapsulamento Combinações de atributos e operações dentro de uma classe

Atributo: Data Nascimento Operação: Cálculo de sua idade

Especificação Atributos e operações diferentes de uma subclasse, acrescentando ou substituindo características herdadas da classe pai

Subclasse Organização e Indivíduo acrescentam atributos e operações distintos da superclasse Parte

Estado Situação de um objeto em um dado instante de tempo

Emitindo Nota Fiscal

Evento Uma ocorr6encia significativa no mundo real que deve ser tratada

Pedido efetivado, entrega efetuada

Generalização Atributos e operações comuns compartilhados por classe

Superclasse veículos como generalização da classe veículo esportivo

Herança Compartilhamento pela subclasse dos atributos e operações da classe pai

Subclasse [Eucalipto] herda as características da classe [árvore]

Instância de Classe É o mesmo que objeto Uma pessoa, organização, equipamento, uma localização geográfica.

Mensagem Solicitação entre os objetos Informar a idade do cliente “Fulano”

Objeto Sinônimo de Instância de Classe Uma pessoa, organização, equipamento, uma localização geográfica.

Operações Lógica contida em uma classe para designar-lhe um comportamento

Cálculo de uma idade Verificação de Cpf

Polimorfismo Habilidade para usar a mesma mensagem para invocar comportamentos diferentes dos objetos

Ex: Verificar Saldo, Saldo em CC, Saldo em Renda Fixa, Saldo Poupança.

Subclasse Característica Particular de uma classe

Classe [árvore] => subclasse [ipê]


CAPÍTULO III – MODELAGEM ATRAVÉS DA UML

Os dois primeiros capítulos desta apostila foram dedicados a uma introdução ao mundo da orientação a objetos, seus métodos, suas tecnologias e ferramentas. Agora vamos entrar precisamente na modelagem de objetos através do uso de uma linguagem unificada de modelagem – UML (Unfield Modeling Language). O modo para descrever os vários aspectos da modelagem pela UML é através da notação definida pelos vários tipos de diagramas. Um diagrama é uma representação gráfica de uma coleção de elementos. Modelar um sistema complexo é uma tarefa extensiva sendo necessária a descrição de vários aspectos, conforme citado abaixo:

• Aspecto funcional (estrutura estática e interação dinâmica) • Não funcional (tempo de processamento, confiabilidade, produção). • Organizacional (Organização do trabalho, mapeamento e codificação).

Cada visão é descrita em um número de diagramas que contêm informação

enfatizando um aspecto particular do sistema. A UML distingue as noções de modelo e diagramas.

1) Um modelo contém informações a respeito dos elementos subjacentes de um

sistema em estudo de maneira independente de como são apresentadas visualmente.

2) Um diagrama, por sua vez, é uma visualização particular de certos elementos

de tipos de um modelo e geralmente expõe apenas um subconjunto de informações detalhadas sobre esses elementos.

A maioria dos diagramas UML refere-se a gráficos que contêm nós conectados por caminhos, sendo que a informação está principalmente na topologia e não no tamanho ou na colocação dos símbolos. Há três tipos de relacionamentos topológicos importantes:

• Conexão => Normalmente de linhas forma 2-d • Retenção => De símbolos para formas 2-d com limites • Anexo Visual => Um símbolo que está próximo a outro em um diagrama

Elementos gráficos usados na UML:

• Ícones • Símbolos 2-d • Caminhos • Textos


A notação da UML é uma combinação de sintaxe vinda de várias fontes, mas

com vários símbolos removidos das técnicas anteriores, e outros símbolos novos agregados.

Principais Diagramas

Os diagramas descrevem mais precisamente os fenômenos observados no problema, assim como permitem encaminhar o sistema à sua implementação. Cada um dos diagramas enquadra-se em uma finalidade e o conjunto de diagramas tem como principal finalidade demonstrar a essência do funcionamento do sistema.

Diagrama Enfoque Descrição Classe Estrutural Estrutura estática do sistema Seqüência Dinâmica Mensagens entre classes no

tempo Colaboração Dinâmica Mensagens por entre

vínculos da classe Estados Dinâmica Dinâmica interna de uma

classe Atividades Dinâmica Dinâmica interna e externa

de uma classe Componentes Implementação Estrutura dos componentes

de Software Distribuição Implementação Estrutura dos processadores

de Hardware Exemplos de Navegação entre os diagramas UML Comportamento Externo Estrutura Comportamento Interno Implementação

Casos de Uso

Classe Pacotes

Eventos Colaboração Atividade Estado

Componentes Distribuição


Em síntese:

As classes, identificadas no modelo conceitual, formam a base sobre a qual ao erguidos os componentes do sistema. As classes mostram apenas uma visão estática do sistema. Uma visão dinâmica é oferecida pelos diagramas de seqüência e interação, que representam as mensagens trocadas entre as classes. O diagrama de estado mostra o ciclo de vida de uma classe, representando sua dinâmica interna. Para serem construídas, as classes podem ser agrupadas em componentes de software que são distribuídas pelos servidores. Essas situações são descritas pelos diagramas de componentes e distribuição. O modelo de contexto define o comportamento externo do sistema, que é distribuído, na modelagem conceitual, para as classes do sistema. Essas classes participam dos processos que podem ser modelados pelos diagramas de seqüência, atividades ou colaboração. Internamente as classes têm seus ciclos de vida modelados pelo diagrama de estados. No modelo de contexto e conceitual, o analista se coloca em uma posição de alguma distância em relação ao sistema para conseguir a visão de um todo. Já nos modelos detalhados, o analista deve aproximar-se muito mais do sistema e das suas partes para conseguir enxergar os detalhes.


Diagrama de Casos de Uso Objetivo: • Modelar o comportamento dinâmico do sistema (especifica). • Mostrar as funções essenciais do sistema (requisitos). • Proporciona uma visão geral do sistema ou de um subsistema (contexto). • Indica os limites e a abrangência do sistema (escopo). Componentes: • Casos de Uso. • Atores. • Relacionamentos (interação) entre atores e casos de uso. • Sistema.

Histórico: • Criado e divulgado por Ivar Jacobson a partir de 1994. • Primeiramente utilizado na metodologia OOSE/Objectory. • Não é exclusividade da UML: � Diversas outras metodologias foram adaptadas para utilizar Casos de Uso para

representar a especificação funcional do sistema.

Sistema

Ator

Caso deUso N

Caso deUso 1

Notação UML: Diagrama de Caso de Uso

Interação

Interação


Casos de Uso (Use Case): • Um conjunto de seqüência de ações realizadas pelo sistema ou parte de um sistema

para produzir um resultado observável por um ator (entidade externa). • Descreve os requisitos funcionais do sistema. • Demonstram o comportamento essencial do sistema a partir da lista de eventos: ♦ Comportamento: funções para visualizar, especificar, construir e documentar. ♦ Não deveriam ser nem amplamente gerais, nem muito específicos. • Um caso de uso especifica o que um sistema faz e não especifica como isso é feito. • Notação UML:

• Alguns autores utilizam nomes dos casos de uso que indicam o evento (matrícula de aluno, solicitação de extrato) e não a ação (matricular aluno, emitir extrato).

• Um Caso de Uso é composto por: � Um conjunto de passos (steps) que caracteriza a seqüência de ações. � Descrição (description) do caso de uso (dicionário de dados). � Pré-condições que caracterizam ações que devem ocorrer antes do caso de uso

ocorrer e pós-condições que caracterizam ações que devem logo depois. • Exemplo com o uso da ferramenta CASE System Architect 2001.

Utilitários::PreencherCheque

CadastrarDependente

MatricularAluno

ComprarProdutos


Observações: Um erro muito comum ao identificar um Caso de Uso é representar como Casos de Usos passos individuais, operações, ou transações. Exemplo: Imprimir nota de caixa, não é um novo Caso de Uso e sim um passo no processo mais amplo que é "Comprar Produtos". 2) O nome do Caso de Uso deve ser claro e sucinto de modo que alguém de fora seja capaz de compreendê-lo com facilidade. Atores: • É uma Entidade Externa que interage com o sistema: � Entidade Externa: usuários, grupo de usuários, outros sistemas, dispositivos

elétricos ou mecânicos. � Interagir: fornecer dados ou receber informações do sistema. Notação UML: (stick man - "homenzinhos")

• Não são partes do sistema. Representam papéis que um usuário pode desempenhar. • Um Caso de Uso sempre é iniciado por um ator que lhe envia um estímulo. • Originam classes no Diagrama de Classes contendo o estereótipo <<actor>>.

Sistema de Compras Computador CentralCliente Caixa


• As respostas às seguintes perguntas podem auxiliar a identificar atores: ♦ Quem vai utilizar as principais funções do sistema? (atores principais). ♦ Quem irá manter, administrar e fazer com que o sistema permaneça operando?

(atores secundários). ♦ Com quais outros sistemas o sistema em foco vai interagir? ♦ Quais os dispositivos de hardware são necessários ao sistema? Relacionamentos do Diagrama de Casos de Uso: • Relacionamentos entre ator e caso de uso: ♦ Relacionamento de comunicação (default). ♦ Navegável em ambas as direções ou em apenas uma.

Observações: ♦ Não se indica o "fluxo de dados" ♦ No System Architect não se indica a direção. Sempre são bidirecionais. • Relacionamentos entre Casos de Uso: Indica um tipo de herança:

1) Uso <<include>>: ♦ Aparece quando alguns casos de uso têm comportamentos comuns. Este

comportamento pode ser modelado como um único caso de uso que é usado pelos demais.

♦ A relação de uso implica que todo caso de uso mais genérico vai ser utilizado pelo caso de uso mais específico. É um tipo de herança.

Cliente Caixa

Iniciar usoCaixa

ComprarProdutos

<<actor>>Caixa

transitory

Caixa


Exemplo:

2) Extensão <<extends>>:

♦ Aparece quando um caso de uso tem um comportamento opcional em relação a um outro.

♦ O Caso de Uso mais geral fornece uma extensão (faz um pouco mais) ao caso de uso mais específico.

Cliente Caixa

Fechar Caixa

ValidarSenha

Iniciar usoCaixa

ComprarProdutos

<<uses>>

<<uses>>

ComprarProdutos

com CartãoCliente Caixa

ComprarProdutos

<<extends>>

imprimirpara

arquivo

Imprimirdocumento

<<extends>>


Métodos para identificar Casos de Usos: • Um método usado para identificar casos de usos é baseado nos atores: ♦ Identificar os atores relacionados aos sistemas ou organização. ♦ Para cada ator identificar os processos que eles iniciam ou dos quais eles participam. • Outro método usado para identificar casos de usos é baseado em eventos: ♦ Identificar os eventos aos quais o sistema deve responder. ♦ Construir a matriz de eventos contendo "Nome do evento", "Estímulos", "Ações" e

"Respostas". ♦ Relacionar os eventos aos atores e aos casos de uso. Diagrama de Caso de Uso: • Visão gráfica de alguns ou todos os atores, casos de usos e suas interações. • Cada sistema possui um diagrama principal indicando os limites e funcionalidades

do sistema. Exemplo: • Outros diagramas podem ser necessários:

♦ Um diagrama com todos os casos de uso de um pacote de classes. ♦ Um diagrama com todos os casos de uso de um dado ator.

Sistema de Caixa Supermercado

ComprarProdutos

com Cartão

ComprarProdutos

com Cheque

Gerente

Cliente Caixa

CadastrarCaixa

EncerrarCaixa

ValidarSenha

Iniciar usoCaixa

ComprarProdutos

<<uses>>

<<extends>> <<extends>>

<<uses>>

<<uses>>


Um Diagrama de Caso de Uso é bem estruturado quando: • Tem como objetivo representar uma visão dinâmica do sistema. • Contém atores e Casos de Uso essenciais à compreensão do sistema. • Tem uma distribuição dos seus elementos que minimize cruzamentos de linhas. • Tem seus elementos organizados espacialmente de maneira que os casos de usos

estejam semanticamente próximos e relacionados. Classes • Agrupamento de objetos similares que possuem os mesmos atributos e operações. • "É a representação de um conjunto de coisas reais ou abstratas que são reconhecidas

como sendo do mesmo tipo por compartilhar as mesmas características de atributos, relações e semântica" - José Davi Furlan.

• São os principais componentes de um Sistema Orientado a Objetos. • A UML representa graficamente uma Classe como um retângulo contendo seu

nome, atributos, operações (métodos) e tipo da classe (persistente ou transitória).

• Atributos, operações ou tipo da classe são opcionais e portanto, podem ser suprimidos mas as linhas devem aparecer.

• Nome da Classe: ♦ Substantivos ou expressões breves que indique o significado da classe no contexto

do sistema que está sendo especificado. ♦ Tipicamente, aparece como maiúsculo o primeiro caractere de cada palavra

existente no nome da classe. ♦ Exemplos: Cliente, MatrículaAluno, SensorTemperatua, Pessoa, Empréstimo. ♦ Uma classe pode ser:

Objeto real: Equipamento, Livro, Máquina, NotaFiscal, Avião. Pessoa: Empregado, Cidadão, Dependente, Gerente, Cliente, Fornecedor. Conceito abstrato: Curso, Cor, Projeto, Departamento, Cargo, Escolaridade. Acontecimento: Casamento, Compra, Venda, PedidoCliente, ReservaLivro. Dispositivos ou sistemas exteriores: SistemaMatrícula, LeitoraOtica, Ícone, Arquivo, ProgramaExecutável, JanelaMédico.

NomeDaClasse

Atributos : Tipo

Operações

TipoDaClasse

NomeClasse


• Atributos: ♦ Elemento que caracteriza/descreve um objeto de uma classe.

♦ + Visibilidade pública: o atributo é visível por todas as operações declaradas em outras classes do sistema.

♦ # Visibilidade protegida: o atributo é visível por todas as operações declaradas no pacote em que a classe é declarada.

♦ - Visibilidade privada: o atributo é visível somente pelas operações da classe em que o atributo foi definido

♦ A visibilidade pode ser suprimida indicando que não se conhece com antecedência a visibilidade do atributo.

♦ Barra (/) antes da visibilidade indica que o atributo é um atributo derivado. Exemplo: /+ ValorTotalFatura, /# SalárioLiquido, /- SaldoConta

♦ Um atributo pode ser: 1. Atributos simples ou compostos:

Simples: Nome_Cliente, CPF_Funcionário, Salário_Bruto, Quantidade, Descrição. Composto: Endereço [rua, número, cep, cidade, estado], Data_Nascimento [Dia, Mês, Ano].

2. Atributos monovalorados ou multivalorados: Monovalorado: CPF, CI, Data_Nascimento, Telefone, Endereço. Multivalorado: Telefones(0,n), Cores(0,5), Endereços(0,2).

3. Atributos obrigatório ou opcional: Obrigatório: Nome_Cliente, Título_Livro, Quantidade_Estoque. Opcional: Sexo(0,1), Data_Pagamento(0,1), Salário_Líquido(0,1), CPF(0,1), Telefone(0,n).

♦ Atributo Identificador da Classe: • Toda classe tem um atributo identificador chamado Object Identifier (OID). • Serve para identificar cada objeto de uma classe semelhante aos atributos chaves

(primary key) dos bancos de dados relacionais. • O OID não é visível para os usuários do sistema. • O identificador (OID) é criado e atribuído automaticamente pelo SGBDOO e não

deve ser identificado pelo analista na classe. Se o atributo "chave" existir no mundo real ele deve ser identificado mas, não terá a propriedade do atributo identificador. Será apenas mais um atributo da classe.

♦ Sintaxe padrão de atributos na classe: • Visibilidade NomeDoAtributo : Tipo = Valor Inicial {propriedade/descrição}

Cliente

+ NomeDoCliente : char# Situação : byte- LimiteDeCrédito : double

Visibilidade pública

Visibilidade protegida

Visibilidade privada


• Tipo: Tipo de dado do atributo que depende da linguagem de programação escolhida.

• Exemplo Java: byte, short, int, long, float, double, char, Boolean ou none (indefinida).

• Operações: ♦ Comportamento resultante de um procedimento algorítmico (Operação

= algo invocado pelo objeto da classe; método = corpo do procedimento que implementa a operação).

♦ As operações devem ter nomes que indique seu resultado através de um verbo: VerificarItemEstoque, ObterDadosCliente, RegistrarProduto, EmitirNotaFiscal, CancelarCliente, CalcularMulta, CalcularSaldoDevedor, ValidarSenha.

♦ As operações são identificadas através do diagrama de caso de uso (Steps, Exceptions e pré e pós condições). Posteriormente veremos que as operações serão agregadas a uma classe através do diagrama de seqüência dos casos de usos.

♦ Uma operação pode ser: 1. Construtura : cria e/ou inicializa o estado de um ou mais objetos da

classe. Exemplos: RegistrarAluno, GravarPedido, CriarJanelaMatricula, IncluirLivro.

2. Seletora: operação que tem acesso, mas não pode alterar o valor de um objeto. Exemplos: ObterDadosCliente, VerificarSenha, LerSituaçãoAluno, CalcularTotalFatura, EmitirEstoque.

3. Modificadora : operação que altera o valor ou estado de um objeto. Exemplos: RegistrarNota, AlterarStatusPedido, AlterarDadosFornecedor, DarBaixaEstoque.

4. Destrutora: operação que destrói/desabilita um objeto. Exemplos: ExcluirDependente, RetirarItemPedido, FecharJanelaMatrícula, RemoverExemplarLivro.

Boleta

+ NumeroBoleta : int# ValorTotal : float# DataPagamento : char

persistent

Aproveitamento

+ Semestre : char+ Freqüência : int# Nota : double- SituaçãoFinal : boolean

persistent

Disciplina

+ Nome : char# CargaHorária : double

persistent

Aluno

+ Nome : char+ Endereço : char+ Telefone(0,n) : char

persistent


♦ Sintaxe padrão das operações: • Visibilidade NomeDaOperação (Parâmetros) : TipoDeRetorno

{propriedade} ♦ Pode ser definido um estereótipo (marca) para um classe: Actor,

Interface, Entity, Utility, ... ♦ Lembre-se: • Ao definir uma operação é melhor que ela faça apenas uma função. Isto

aumenta a reusabilidade da operação em outras classes. • Operações com mesmo nome em classes diferentes são operações

polimórficas. Isto é interessante na fase de modelagem quando não sabemos ainda se a regra de negócio é diferente para classes diferentes. Exemplo: CalcularSaldo nas classes (ContaCorrente e ContaPoupança).

• Como identificar uma classe? ♦ Através das descrições (description) do Caso de Uso identificar os

substantivos ou locuções substantivas: elegê-lo ou não como uma classe candidata. A lista de eventos também pode ajudar.

♦ Classes que compartilharem atributos em comum devem ser agrupadas gerando superclasses.

Aproveitamento

+ Semestre : char+ Freqüência : int# Nota : double- SituaçãoFinal : boolean

- RegistrarFreqüênca- RegistrarNotaGravarSituaçãoFinal# EmitirHistóricoEscolar(ra)

persistent

Disciplina

+ Nome : char# CargaHorária : double

# VerificarPréRequisito+ ObterDadosDisciplina+ VerificarVagas : int

persistent

Aluno

+ ra : int+ Nome : char+ Endereço : char+ Telefone(0,n) : char

+ RegistrarAluno(ra)# EmitirSituação

persistent

<<utility>>Utilitarios

PreencherCheque(Valor) : charValidarSenhaValidarData(Data)

<<interface>>JanelaMatricula

AbrirFecharMoverMinimizarMaximizar

<<actor>>SetorCompras

<<entity>>Medico


♦ Busque equilíbrio entre funcionalidade e reutilização, resistindo-se ao desejo de criar classes grandes que abrangem tudo. Classes menores são mais fáceis de serem compreendidas e implementadas. Se uma classe for difícil de entender, não podendo ser explicadas em poucas linhas, ou ainda tiver muitas operações é forte candidata a ser dividida em classes menores. Diagrama de Classe

Gráfico bidimensional de elementos de modelagem que podem conter tipos, pacotes, relacionamentos, instâncias, objetos e vínculos (conexão entre dois objetos). O diagrama é considerado estático, pois sua estrutura é sempre válida em qualquer ponto no ciclo de vida do sistema. Um diagrama de objeto é uma variação do diagrama de classe e utiliza quase a mesma notação. A diferença entre os dois diagramas é que o diagrama de objeto mostra um número de instância de classes, em vez de uma classe real, e apresenta o nome do objeto sublinhado dentro do retângulo. Os diagramas de objetos não são tão úteis quanto os digramas de classes. Objetivos

• Representação das classes e a relação entre elas • Visão estática e estrutural do sistema • Semelhante ao DER para Banco de Dados relacionais

Tipos de Relacionamentos

• Herança • Associação • Agregação • Dependência

Herança

• Relacionamento entre classes onde uma classe compartilha a estrutura e

comportamento de uma ou mais classes. • Uma classe mais geral, a superclasse, tem atributos, operações e associações

comuns que são compartilhadas por uma classe mais especializada a subclasse. • Subclasse herda atributos, operações e relacionamentos. • Subclasse pode incluir : atributos , operações e relacionamentos • Subclasse pode redefinir as operações herdadas (Polimorfismo)


As classes são identificadas por retângulos divididos em 03 porções, como mostrado

na figura abaixo: Representação Típica Representação Simples Exemplo 01

Nome da Classe

Atributos

Operações

Nome da Classe

Figura

+Origem : Int

Move Open

Display Resize Close

Polígono

+Pontos: Vetor

Display

Círculo

+Raio: Float

Retângulo

+Largura: Float +Altura :Float

Quadrado


Exemplo 2 :

• Restrições para Herança

♦ Herança Completa (N não conhecido) ou Herança Incompleta (N não é

conhecido). ♦ Herança Disjunção (B,C, ..., N são mutuamente exclusivos) ou Herança

Sobreposição (B, C, ..., N podem ocorrer simultaneamente).

Pessoa

+Nome :Char +Endereço : Char +Telefone(0,n): char

Regitrar

PessoaFísica

+CPF : Char +RG : Char +DataNascimento: Date

Validar CPF

PessoaJurídica

+CGC : Char

ValidarCGC

A

Restrição de Herança

NCB


Exemplo

Exemplo 4: Teoricamente não há limite no número de níveis da hierarquia

Exemplo – Incorreto ?

ClienteDependente

SobreposiçãoIncompleta

DisjunçãoCompleta

ClienteTitular

Cliente

AdministradorSecretáriaEngenheiro

Empregado

SobreposiçãoCompleto

SobreposiçãoCompleto

SubordinadoSupervisorGerenteExtensãoPosGraduaçãoGraduação

FuncionárioProfessorAluno

Usuário

DisjunçãoIncompleto

ClienteMasculino ClienteFeminino

Cliente


♦ Num sistema de biblioteca isto seria errado: as subclasses se comportam da mesma

forma. ♦ Num sistema de pesquisa de mercado é aplicável, pois os hábitos de compra são

diferentes para as subclasses. • Quando criar superclasses e subclasses? ♦ A subclasse tem atributos ou operações adicionais? ♦ As subclasses têm associações adicionais que represente melhor a realidade? Exemplo 6:

♦ As classes possuem atributos e operações comuns? Junte-as em uma superclasse se achar conveniente, mas use o bom senso. Evite criar superclasses grandes demais que agregam tudo. Isto não facilita a implementação ...

Exemplo: a) Não fica bom: Superclasse Parte se especializando em Indivíduo e

Organização. b) Fica bom: Superclasse Pessoa se especializando em Funcionário, Cliente e

Fornecedor. Exemplo 7a: Ruim

Exemplo 7b: Bom

CorreçãoMonetáriaContaPoupançaContaCorrente

Conta

sofre

Engenheiro

EletricistaMetalúrgicoMinasMecânicoNuclearCivil

Engenheiro CategoriaEngenheiroPossui


• Herança Múltipla: ♦ Tipo de herança que indica que um uma subclasse herda atributos e

comportamentos de duas ou mais classes ao mesmo tempo. Exemplo 8:

♦ Conceitualmente é necessária para modelar o mundo real de forma mais precisa. ♦ Na prática pode gerar dificuldades na implementação. L4G e BDOO não suportam. Nota: • Use herança entre duas classes quando a regra de negócio sugere que um objeto na

classe pai "é do tipo de" ou "se especializa em" um objeto na classe filha. • Formam herança: PessoaFísica/PessoaJurídica, PessoaLocatária/PessoaLocador,

Periódico/Livro, SócioTitular/SócioDependente, PeçaManufaturada/PeçaTorneada, Gerente/Supervisor, etc.

• Não formam herança: Empresa e Departamento, Cinema e Salas, Livro e Exemplar, Disciplina e Turma, Escola e Aluno, Pedido e Item de Pedido, etc.

2.1 Associação • Relacionamento entre classes que indica a ligação entre objetos de duas ou mais

classes. • Usado pelo SGBDOO para gerar as informações necessárias ao sistema OO. • As associações são representadas por uma linha ligando as classes associadas. • Só se deve associar as classes se a informação que está sendo representada for

importante na regra de negócio.

Animal

+ Cor : char

ObterCor

AlgoQueVoa

+ Cor : char

ObterCorSobreposiçãoIncompleto

VeículoAquáticoVeículoTerrestre

VeículoAnfíbio

Veículo

PássaroConflito de Atributos e Operações

Classe 2Classe 1 Nome da Associação


• Exemplos:

É desejável saber quais funcionários estão associados a quais departamentos da

empresa: É desejável saber quais são as disciplinas um aluno cursou ou está cursando na

universidade:

• Geralmente não é desejável saber quais os relatórios uma pessoa emite ou já emitiu

... • Geralmente não é desejável saber quem foi o funcionário que cadastrou o aluno ...

Funcionário DepartamentoEstá Lotado

DisciplinaAluno Cursa/Cursou

Funcionário AlunoCadastra

RelatórioPessoa Emite


• Notas: Ações que indicam processos não geram associações entre classes. O nome da associação deve ser um verbo representativo que indique o fato

observado.Entre duas classes pode existir mais de uma associação e uma associação

pode conter atributos próprios. Obs: Pode-se colocar os atributos da associação assim: Gerencia (Gratificação, DataGerência). • Uma associação pode ter qualificador tipo papel, que indica o propósito que uma

classe se associa a outra. O nome de um papel é colocado ao longo da linha da associação, próximo à classe referenciada.

• Multiplicidade de Associações: representa um número de instâncias de uma classe relacionada a uma instância de outra classe.

Empregado

+ Nome : char+ Endereço : char+ Telefone(0,n) : char

Departamento

+ Sigla : char+ Descrição : char

Atributos_Gerencia

GratificaçãoDataGerência

Gerencia

Está Lotado

DisciplinaPessoa Leciona

Professor

EmpresaPessoa Trabalha Em

Funcionário Empregador


• Funciona como uma restrição a ser imposta de acordo com a regra de negócios. • Tipos:Associação 1:N

• Indica que um objeto de uma classe pode estar associado a vários objetos de outra classe.

• Exemplo 1: • Exemplo 2: Qual a realidade?

Lotação (Data_Inicio)

Classe

Classe

Classe

Classe

ClasseClasse

Classe

Classe

5..60

Seqüência Especificada

*Zero ou Mais

m..n

Seqüência Especificada

2..*

Mais de Um

1..*

Um ou Mais

0..*

Zero ou Mais

1

Exatamente Um

0..1

Zero ou Um

AlunoCurso 1

0..*

Possui

Sentido de Leitura

Departamento Empregado



EmpregadoDepartamento

0..1

1..*

Lotação

1

1..*

Lotação

0..1

0..*

Lotação

1

0..*

Lotação


• Exemplo 3:

Notas: 1. Mesmo que uma classe tenha somente um objeto pode ser interessante criá-la para

facilitar a manutenção futura no sistema. É o caso da classe Empresa no DC anterior.

2. Sempre que verificar a ocorrência de redundância de dados em relação a atributos que se repetem para objetos diferentes de uma classe separe-os criando novas classes (Classes devem estar normalizadas). É o caso das classes Formacao_Escolar e Cargo.

3. Sempre que verificar a ocorrência de atributos multivalorados numa classe separe-os criando novas classes. É caso da classe Telefone. Por quê?

4. Seria correto criar uma associação entre as classes Empresa e Funcionário? • Exemplo 4: Uma associação pode gerar uma nova classe. Esta classe será chamada

classe de associação: é um elemento de modelagem UML com propriedades de associação e de classe. As classes de associação são representadas com um símbolo de classe anexado a uma associação por uma linha tracejada conforme mostra o

FormaçãoEscolar

Cargo

Gerente Administrador

Funcionário

Telefone

Departamento

Empresa

0..1

1..*

Gerencia

0..*0..1

PossuiFormação

0..*

0..1

PossuiCargo

0..*

1

1

0..*Tem

0..1

0..*

Lotação

Compra

+ Data : char# PrecoCompra : double+ Desconto : float

# EmitirTotalVendasMes(Mes) : double+ EmitirNotaFiscal# CalcularLucro(Mes) : double

persistent

Fita

+ Titulo : char+ DataLançamento : char+ QuantidadeEstoque : int

ExemplarFita

+ DataAquisição : char+ PreçoPago : char

Cliente

+ Nome : char+ Endereço : char+ Telefone : char

ClienteDependente

+ Relaçao : char

ClienteTitular

# Salário : float

1..*

1

Tem

1 0..*Possui

0..1

0..*


exemplo: Notas: • Gere classes associativas se existirem atributos /operações a serem

acrescentadas na classe. • Observe que as associações Possuem (entre Cliente Titular e Cliente Dependente) e

Tem (entre Fita e ExemplarFita) não deram origem a novas classes associativas. • Uma alternativa à geração de classes associativas para associações 1:N seria colocar

os atributos e operações da associação na classe do lado N, semelhante ao modelo físico de Banco de Dados relacionais. Embora possível, esta técnica não é interessante em Orientação a Objetos, pois: a) A separação de fatos distintos em novas classes melhora o entendimento do

sistema. b) Há uma maior possibilidade de reuso separando os fatos em classes associativas. c) Na maioria dos casos existe um ganho de espaço de armazenamento no

SGBDOO. d) Na maioria dos casos existe um ganho de desempenho nas consultas que

envolvem os dados armazenados nas classes associativas. • Sempre use a estratégia de gerar classes normalizadas (como em DERs). Exemplo 5a: Faça uma análise crítica do seguinte diagrama de classes.

Exemplo 5b: Faça uma análise crítica do seguinte diagrama de classes.

SexoEmpregado0..*

0..1

Possui

Escritório

FuncionárioDepartamento

0..*

1

Possui

1..*

1 Trabalha_Em

1

1..*

Lotação


Exemplo 5c: Faça uma análise crítica do seguinte diagrama de classes.

Exemplo 6: Se a multiplicidade da associação for maior que 1 ela pode ser ordenada.

Isto significa que o conjunto de objetos do lado N se encontra em uma ordem explícita. O exemplo acima significa que os pedidos dos clientes estão ordenados segundo uma restrição pré-definida no dicionário de dados. Por exemplo, os pedidos podem ser ordenados no banco de dados pelo dia em que foram feitos pelos clientes. Notas finais: • Evite o uso de participação total / total nos relacionamentos. Por que? Mesmo a

participação parcial / total deve ser evitada. Use sempre o bom senso !!! • Indique sempre classes associativas caso exista atributos e/ou operações próprias da

associação.

ClienteRua

BairroCidade

Estado 0..1

0..*

mora

1

0..*

Tem_Rua

1

0..*

Tem_Bairro

1

0..*Tem_Cidade

PedidoCliente 1

0..*

{ordered}Faz


Associação N:N • Indica que um objeto de uma classe pode estar associado a vários

objetos de uma outra classe e vice-versa. • Exemplo 1: A cobertura de um exame é um fato que deve ser armazenado no

sistema? Exemplo 2: O elenco de um filme é um fato que deve ser armazenado no sistema?

Exemplo 3: A associação tem atributos e operações adicionais?

Exemplo 4a: Vários para vários ou duas vezes um para vários?

EmpresaConveniada

TipoDeExame0..*

0..*

Cobre

AtorFilme1..*

1..*

Possui

Elenco

Consulta

+ DataConsulta : char+ PreçoPago : double+ Diagnóstico : char

MarcarConsultaRemarcarConsultaCancelarConsultaEncerrarConsulta

Médico

+ CRM : int+ Nome : char+ Endereço : char+ Telefone : char

Paciente

+ Nome : char+ Endereço : char+ Telefone : double

1..*

0..*

Consulta

ItemPedido

+ Quantidade : int+ PreçoPago : float

ProdutoPedidoCliente0..*

1..*

Possui1

0..*

Faz


Exemplo 4b: Vários para vários ou duas vezes um para vários?

Associação Qualificada: • Tipo de associação um para vários ou vários p/ vários que permite, dado um objeto

de uma extremidade da associação, identificar os objetos associados no outro lado da associação.

• Funciona como uma chave estrangeira usada p/ particionar o conjunto de objetos associados.

• O qualificador é um atributo da associação e não aparece na classe qualificada. • É interessante que o atributo exista na regra de negócio não sendo um atributo

artificial. Exemplo 5a: Sem a associação qualificada (N:N):

Exemplo 5b: Com a associação qualificada (N:N):

Exemplo 6a: Sem a associação qualificada:

ItemPedido

+ Quantidade : int+ PreçoPago : float

Cliente Pedido Produto

1

0..*1

1..*

1

0..*

Faz

TransaçãoConta

+ NumeroTransação : int+ Data : char- Valor : float+ Tipo : char

Conta

+ NumeroConta : int+ DataAbertura : char+ Tipo : char

TipoTransação

+ Descrição : char+ Tarifa : float

0..* 0..*é movimentada

TransaçãoConta

+ Data : char- Valor : float+ Tipo : char

Conta

+ NumeroConta : int+ DataAbertura : char+ Tipo : char

TipoTransação

+ Descrição : char+ Tarifa : float

NúmeroTransação0..* 0..1

é movimentada

Cinema


Sala

+ Capacidade : int1

1..*

Possui


Exemplo 6b: com a associação qualificada:

Nota: Prefira no modelo a associação não qualificada, pois algumas linguagens OO não implementam associações qualificadas. Histórico de Objetos: Em algumas situações é necessário manter históricos das ocorrências anteriores de objetos nas classes. Isto geralmente altera a multiplicidade das associações. Exemplo 7:

• Pode-se separar os objetos da situação atual dos objetos que são históricos em classes diferentes:

Exemplo 8a: Situação atual e Históricos são guardados na mesma classe.

HistóricoLotação

+ DataInicio : char+ DataFim : char

Empregado Departamento0..*

1..*

lotação

HistóricoMatricula

+ Semestre : double+ Nota : float+ Frequencia : int+ SituaçãoFinal : char

TurmaDisciplina DisciplinaAluno

0..*

0..* Possui0..*

0..*

Matricula

Sala

+ Capacidade : int

persistent

Cinema


NumeroSala1

1

Possui


Exemplo 8b: Situação atual e Históricos são separados em classes diferentes.

Vantagens: O desempenho do sistema tende a ser melhor no caso b. Por quê? Notas: Lembre-se 1. O SGBDOO aceita associações N:N, o que não ocorre com SGBDRs. 2. Nas classes associativas não deve ser identificados atributos que pertencem a outras

classes, ou seja, o SGBDOO não utiliza o conceito de chaves estrangeiras dos SGBDRs.

3. Apenas uma classe de associação é permitida por associação. Associação 1:1 • Indica que um objeto de uma classe pode estar associado à no máximo um objeto de

uma outra classe e vice-versa. • Exemplo 1: Exemplo 2a:

HistóricoEscolar

+ Semestre : char+ NotaFinal : float+ FreqüênciaFinal : int+ SituaçãoFinal : char

MatriculaAtual

+ Nota : float+ Frequencia : int

TurmaDisciplina DisciplinaAluno

0..* 0..*

HistóricoEscolar

0..*

0..1

Gera

0..*

0..* Possui0..*

0..*

Matricula

GovernadorEstadoFrigobarQuarto 1

0..1

é governado0..1

0..1

Possui

CoordenaçãoCurso

+ Data : char+ Gratificação : float

CursoProfessor0..1

0..1

Coordena


Exemplo 2b:

Vantagens: Reusabilidade melhor e o desempenho tende a ser melhor. Por quê? Exemplo 3:

Auto Associação: • Indica que um objeto de uma classe pode estar associado a outro objeto da mesma

classe. Exemplo 1:

CoordenaçãoCurso

+ Data : char+ Gratificação : float

Professor

CursoCoordenador 0..1

1Coordena

EmgenheiroProjetoSobreposição Incompleta

Administrador

Disjunção Incompleta

Departamento

Projeto

Cargo

GerenciaGerente Supervisor

SecretáriaEngenheiro

Empregado1

0..*

Possui

0..1

1

Gerencia

0..1

0..* Supervisiona

0..*

0..1

Lotação

0..*

0..* TrabalhaEm

Disciplina Funcionário

0..*

0..1

Supervisiona

0..*

0..*

Pré_Requisito


Exemplo 2:

• Alguns SGBDOOs não implementam auto associação, pois sempre é possível evitá-

la num diagrama de classes. Exemplo 3a: Com auto associação

Exemplo 3b: Sem auto associação

Casamento

+ DataCasamento : char+ TipoCasamento : char

Pessoa

Marido0..1

Esposa0..1

Casamento

Composição

+ Quantidade : charProduto

0..*

0..*

Composição

Composição

+ Quantidade : char

Produto Composto ProdutoComponente

Produto

0..* 0..*


Exemplo 4a: Com auto associação

Exemplo 4b: Sem auto associação

Exercício: Transforme os modelos dos exemplos 1 e 2 em modelos sem auto associação. Associação de grau superior a dois: • Associação que envolve três ou mais classes simultaneamente. Exemplo 1:

É Filho

É Filho

É Pai É Mãe

Pessoa

0..1

0..*

Mãe

0..1

0..*

Pai

Pessoa

PessoaMãePessoaFilhoPessoaPai

0..10..* Possui0..1 0..*Possui

Fornecimento

+ Data : char+ Quantidade : int+ Preço : float

Fornecimento

Peça

ProjetoFornecedor

10..*

1

0..*

1

0..*


Exemplo 2: Supondo que em uma cidade um produto tenha um representante exclusivo:

Nota: Uma associação ternária não é equivalente a três associações binárias. 2.2 Agregação • Forma especial de associação que indica que uma classe está contida noutra classe. • Indica que uma classe depende de outra para existir. • É útil para indicar um relacionamento tipo "Todo/Parte" ou "É composto de". Exemplo 1:

Exemplo 2:

Distribuição

+ Data : char+ Quantidade : int

DistribuiçãoDistribuidor

Produto

Cidade

1

0..*

10..11 0..*

DepartamentoEmpresaExemplarLivroLivro

1 0..*

Tem1 0..*

Possui


Exemplo 3: Classes fracas devem ser modeladas como agregação

ProdutoItemPedidoPedido 0..*

1

Possui1 1..*

Tem

TurmaDisciplinaDisciplina ContraChequeFuncionário

SalaCinemaCinemaBoletaAlunoAluno

1 0..*

Recebe1 0..*

Tem

1 0..*

Possui

1 0..*

Paga


Exemplo 4: Agregação compartilhada (N:N)

Exemplo 5:

Notas: • Somente um lado, no máximo, de uma associação pode ser agregação. • Se o objeto da classe "Todo" for destruído os objetos da classe "Parte" também

serão destruídos. Alguns autores denominam este fato de "agregação por composição" e a representam através de um losango escuro.

• Como diferenciar Agregação de Associação? ♦ Dois objetos estão estreitamente ligados por uma associação "Parte-Todo" ou "É

composto de": Agregação. ♦ Dois objetos estão ligados, mas usualmente são considerados independentes:

Associação. Exemplo 6:

PessoaTime

0..* 1..*

é composto

SócioDependenteSócioTitular

Sócio

1 0..*Tem

HistóricoEscolar

InstrutorCursoAluno

DepartamentoEscola

0..1

0..1 É Chefiado

0..*

1..* Está Vinculado1..*

0..*

Administra

0..*

1..*

Ministra0..*

0..*

Frequenta

0..*

0..*

Possui

1 0..*

Tem


Parte II – Apostila de APS II

Diagrama de Objetos

Um diagrama de objetos consiste em uma instância do diagrama de classe, no qual cada classe temos um objeto ( sua instância) em um determinado ponto de tempo. Você deve estar se perguntando, para que isso serve ? Primeiramente, muitas vezes estamos naqueles dias em que a criatividade está muito difícil e não muito claro. O diagrama de objetos vem com o objetivo de simularmos uma situação de funcionamento do sistema em um dado instante. Vantagens

� Úteis para facilitar a modelagem de estrutura de dados � Identificar problemas na execução de uma aplicação � Durante o Debugging podemos visualizar os objetos que estão sendo

manipulados e seus relacionamentos. Representação Gráfica

É um objeto similar a classe. Consiste em um retângulo com dois compartimentos, sendo que o primeiro mostra o nome do objeto e o segundo mostra os atributos, um em cada linha, com seus valores.

Nome do objeto : nomedaclasse

Por exemplo : CoordenadaFigura1:coordenada É possível omitir o nome do objeto, preservando dois pontos, representando um objeto anônimo ou omitir o nome da classe. Em qualquer um dos casos, mantém-se sublinhado. Exemplos : :coordenada / CoordenadaFigura1 Quando os atributos são exibidos:

Func1:Funcionário :Funcionário Funcionário1

Caneta:Produto

Cor = ‘Azul’ Preço = R$ 2,00


Atributos não relevantes ao sistema podem ser omitidos. É possível

também representar atributos cujos valores mudam durante um processamento. Nesse caso, representa-se essa mudança por meio de uma lista. Os links são os responsáveis pela ligação entre os objetos. Os links podem conter adornos tais como:

� Nome do papel = final de cada linha pode ser exibida � Nome da associação = exibido próximo a linha � Qualificadores = terminação dos links

Exemplos dos adornos:

a) Qualificadores É um atributo ou lista de atributos, presentes em uma associação, cujos valores servem para particionar o conjunto de instanciais associadas com outra instância do lado qualificado. Num relacionamento entre nota fiscal e itens da nota fiscal, sabemos que para determinada nota não podemos ter a repetição de produtos, ou seja, cada produto só pode aparecer uma única vez nos itens da nota fiscal. Com isso qualificamos com o atributo produto.

b) Nome da associação Geralmente utilizada próxima a linha para facilitar o entendimento da associação, não é aconselhável seu uso em situações explícitas.

Cursa

c) Nome do Papel Geralmente para explicar o papel de uma classe, quando a mesma pode exercer vários papéis em uma mesma classe. Na maioria das vezes a classe por si só já explica seu papel.

Gerente Setor

NotaFiscal Produto ItemNotaFiscal

Aluno Disciplina

Funcionário Departamento


Diagrama de Interação

Diagramas de interação, é um nome genérico que se aplica a vários tipos de diagramas que enfatizam a interações dos objetos.Esses diagramas devem ser utilizados quando se deseja visualizar o comportamento de vários objetos dentro de um único caso de uso, a partir das mensagens que são passadas entre eles. Diagramas de interação são apresentadas sob duas formas na UML :

• Diagrama de Seqüência • Diagrama de Colaboração

Desenvolvedores diferentes têm preferências próprias ao escolher o tipo de diagrama de interação a ser utilizado. Alguns podem preferir o diagrama de seqüência, outros o diagrama de colaboração. O diagrama de seqüência permite dar maior ênfase aos quesitos de seqüência tornando fácil à visualização da ordem na qual as coisas acontecem.

O importante é que qualquer um dos dois diagramas adotados, o que importa é

sua simplicidade, permitindo uma fácil visualização. Diagrama de Seqüência Foram encontrados em vários métodos de orientação a objetos, diagramas de seqüência sob variados nomes. Notação :

• Objeto é desenhado no topo como um retângulo tendo uma linha tracejada projetada para baixo.

• Linha vertical é chamada de linha de vida do objeto • Cada mensagem é representada por uma linha horizontal • A ordem na qual estas mensagens acontecem ( Fluxo de tempo ) é mostrada de

maneira top down • Cada mensagem é etiquetada com seu nome, mas também pode incluir

argumentos e informações de controle. • Se um objeto é excluído então utilizamos um X • A dimensão vertical representa o tempo e a dimensão horizontal representa

objetos diferentes • Uma condição é indicada dividindo uma seta de mensagem em dois objetivos

paralelos • Autodelegação ocorre através de chamada recursiva


Diagrama de Colaboração

Ao contrário de um diagrama de seqüência, um diagrama de colaboração mostra os relacionamentos entre os objetos, mas não trata o tempo como uma dimensão separada. Dentro de um diagrama de colaboração, os objetos são desenhados como ícones, e como nos diagramas de seqüência, setas indicam as mensagens enviadas aos objetos para realizar um caso de uso. Notação

• Ícones • Setas • Uma condicional é indicada com uma condição de guarda entre colchetes, ou

seja, exibe uma condição que deve ser satisfeita para causar o disparo de uma transição associada.

Diagrama de Estado A existência de estado de um objeto implica que a ordem na qual as operações são executadas é importante, o que leva a idéia de objetos como máquinas independentes. Uma das desvantagens deste diagrama refere-se a sistema de maior complexidade já que este diagrama visa definir todos os possíveis estados de um sistema. A UML propõe o emprego deste diagrama de maneira individualizada para cada classe ( o que também vale para classes estereotipadas de interface do usuário), com o objetivo de tornar o estudo simples, o bastante para se ter um diagrama de estado compreensível. Modelos de estado são ideais para descrever os comportamentos de um único objeto, mas não para descrever adequadamente o comportamento que envolve vários objetos, neste caso o melhor é utilizar um diagrama de interação ou um diagrama de atividade.


Diagrama de Atividade

É o diagrama menos conhecido, sendo utilizado para diferentes propósitos, incluindo:

• Capturar o funcionamento interno de um objeto • Capturar as ações que serão desempenhadas quando uma operação é executada • Mostrar como um processo de negócio funciona em termos de atores, fluxo de

trabalho, organização e objetos. • Mostrar como uma instância de caso de uso pode ser realizada em termos de

ações e mudanças de estado de objetos. • Mostrar como um conjunto de ações relacionadas pode ser executado e como

afetará objetos ao redor.

O ponto forte do diagrama de atividade reside no fato de suportar e encorajar comportamento paralelo, tornando-se uma boa técnica para a modelagem de fluxo de trabalho e programação para multiprocessamento. O uso do diagrama de atividade é indicado nos seguintes casos:

• Análise de caso de uso

Nesse caso não há interesse em designar ações aos objetos. Há somente a necessidade de se compreender quais ações precisam ser realizadas e quais são as dependências comportamentais.

• Compreensão de fluxo de trabalho entre vários casos de uso

Quando casos de uso interagem entre si. Não devemos utilizar os diagramas de atividade quando :

• Colaboração de Objetos Um diagrama de interação é mais simples e provê uma visão mais clara de

colaborações

• Comportamento de objetos em seu ciclo de vida

Um diagrama de estado oferece melhores recursos para esse caso. O Diagrama de atividades é um caso especial do diagrama de estado no qual todos ( ou pelo menos a maioria ) os estados são ações ou subatividades nos estados de origem. Este diagrama tem como propósito focalizar um fluxo de atividades que ocorrem internamente em um processamento, dentro de um período de tempo.


Modelando Diagramas de Atividades

Exemplificando temos a situação mais comum a nossa saída de casa para o local de trabalho. Poderíamos descrever esses passos assim:

� Saindo de casa � Escolher um meio de transporte � Se for ônibus devemos ir até ao ponto de ônibus � Aguardar o ônibus � Descer ponto mais próximo do trabalho � Se for metrô devemos ir até a estação � Comprar um bilhete � Pegar a composição � Descer na estaca mais próxima ao local de trabalho. � Nos dois casos devemos descer e caminhar até o local de trabalho

Vejamos nosso exemplo de diagrama de atividades:

S a ir d e C a s a E s c o lh e r m e io d e tr a n s p o r te

Ir p a ra p o n to d e ô n ib u s Ir p a ra e s ta ç ã o

ô n ib u s M e trô

P e g a r C o n d u ç ã o

P a g a r P a s s a g e m

C o m p ra r B i lh e te

P e g a r C o m p o s iç ã o

D e s c e r P ró x im o


Podemos ter ainda um processamento em paralelo, conforme

exemplo abaixo: Diagrama de atividades liberação de mercadoria

Preparando liberação de produto

Separando Produto em estoque Verificando Programa de entrega do caminhão

Embalar Produto

Remanejar Entrega

Emitir Liberação entrega

Atrasados

Sem atraso

Emitir Nota Fiscal


Estado de Ação

Um estado de ação é um tipo simplificado de um estado de uma máquina de estados. Estados de ação não devem ter transições internas. Para estas situações, utilize os estados normais. As transições entre atividades são implicitamente disparadas pela execução de uma ação em um estado. As Transições podem incluir condições de guarda e ações. Um uso comum de estado de ação é a modelagem de um passo específico da execução de um processo de workflow.

Um estado de ação é mostrado graficamente como uma figura retangular

com as laterais arredondadas e com a expressão ação dentro da figura.

Remanejar Entrega

Obter Autorização

Estado de subatividade Um estado de subatividade indica que quando este é inciado, o gráfico de

atividade aninhado a ele é executado como um gráfico de atividade independente. O estado de subatividade não é finalizado até que o estado final do

gráfico aninhado seja alcançado, ou quando eventos disparadores ocorrerem em transições vindas de fora do estado de subatividade.

Transições Mostra o fluxo de um estado de ação para outro. É representado

graficamente por uma seta que vai de um estado ou subatividade para outro estado ou subatividade.

Decisões Uma decisão ocorre em um diagrama de atividades quando condições de guarda

são utilizadas para indicar diferentes transições mutuamente exclusivas, que dependem de condições booleanas do objeto proprietário. A representação gráfica é um losango.

A mesma representação pode ser utilizada para finalizar uma decisão, neste caso é chamada de merge(intercalação).

Bifurcação ou união.

Fazemos o uso de bifurcação ( Fork ) e União ( Join ) principalmente em fluxos concorrentes, no intuito de criar uma ligação entre os diversos fluxos. A bifurcação separa uma transição de entrada em várias transições concorrentes, sendo que estas são disparadas ao mesmo tempo. A União concatena transições concorrentes em uma transição simples.


Raias ( SwinLanes ) Ações e subatividades podem ser organizadas dentro de raias, que são usadas

para agrupar responsabilidades para ações ou subatividades. Um diagrama pode ser dividido em diversas raias, cada qual separada de sua vizinha por uma linha sólida vertical de ambos os lados. Cada ação é determinada por uma raia. Transições podem atravessar as zonas das raias.

ClienteVendedor

Solicitação de Compra

Efetuar pagamento Lançar Venda

Liberar Mercadoria

Exemplo de diagrama de atividades utilizando raias.


DIAGRAMAS DE IMPLEMENTAÇÃO Assim como o diagrama de interação, o diagrama de implementação é formado

basicamente por dois tipos de diagramas :

� Diagrama de Componentes � Diagrama de Implantação

O Diagrama de componentes mostra a estrutura dos componentes, incluindo os

classificadores que eles especificam e os artefatos que eles implementam. O Diagrama de Implantação mostra a estrutura de nós nos quais os componentes

representam a organização de unidades e recursos ( humanos e outros ) do negócio. Esses diagramas também podem ser aplicados na modelagem de negócios, no qual os componentes representam artefatos e procedimentos de negócios e os nós de implantação representam a organização de unidades e recursos. Diagrama de Componentes Um diagrama de componentes mostra as dependências entre componentes de software, incluindo classificadores que eles especificam ( isto é classes de implementação ) e os artefatos que eles implementam ( isto é arquivos de códigos fonte, arquivos de código binário, arquivos executáveis, scripts, etc...). Um diagrama de componentes representa um tipo e não a instância. Para mostrar a instância de componentes utilize um diagrama de implantação. O diagrama de componentes é conectado através de setas pontilhadas. Um diagrama de componentes pode ser usado para mostrar dependências estáticas. Um componente corresponde às interfaces que ele expõe, interfaces que representam serviços providos pelos elementos que residem no componente. Um componente pode ser implementado por um ou mais artefatos, tais como arquivos, arquivos executáveis,script, etc... Notação Gráfica :

Pedidos.exe


Diagrama de Implantação

Diagramas de implantação mostram a configuração dos elementos de processamento em tempos de execução e os componentes de software.

Um diagrama de implantação é um gráfico de nós que conectados por associações de comunicação.

Nó

É um objeto Físico que representa um recurso de processamento, freqüentemente possuindo capacidade de processamento.

Apostila Análise e Projeto Orientados por Objetos - UML

Documents

Transcript of Apostila Análise e Projeto Orientados por Objetos - UML