apostila apsii rodrigo completa
TRANSCRIPT
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 2
Í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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 3
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 4
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 5
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 6
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 7
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 8
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 9
• 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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 10
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 11
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 12
• 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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 13
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 14
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 15
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 16
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 17
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 18
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 19
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ê]
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 20
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 21
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 22
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 23
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 24
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 25
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 26
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 27
• 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 28
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>>
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 29
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>>
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 30
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 31
• 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 32
• 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 33
♦ 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 34
♦ 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)
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 35
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 36
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 37
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 38
♦ 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 39
• 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 40
• 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 41
• 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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 42
• 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
Departamento Empregado
Departamento Empregado
EmpregadoDepartamento
0..1
1..*
Lotação
1
1..*
Lotação
0..1
0..*
Lotação
1
0..*
Lotação
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 43
• 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..*
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 44
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 45
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 46
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 47
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
+ Nome : char+ Endereço : char+ Telefone : char
Sala
+ Capacidade : int1
1..*
Possui
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 48
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
+ Nome : char+ Endereço : char+ Telefone : char
NumeroSala1
1
Possui
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 49
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 50
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 51
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..*
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 52
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..*
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 53
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 54
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 55
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 56
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 57
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 58
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 59
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 60
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 61
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 62
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 63
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 64
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.
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 65
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
Professor : Rodrigo de Matos Vargas – Todos os direitos reservados 66
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.