Apostila Análise e Projeto Orientados Por Objetos - UML

FABRAI FACULDADE BRASILEIRA DE INFORMTICA
CURSO DE TECNOLOGIA EM PROCESSAMENTO DE DADOS
ANLISE E PROJETO DE SISTEMAS II

(Anlise e Projeto Orientados por Objetos - UML)
Parte I
Prof. Rodrigo de Matos Vargas

rmatos@rmatos.com.br http://www.rmatos.com.br
Proibida reproduo 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
NDICE
1 Plano de Estudo 2- Bibliografia 3- Captulo I Introduo 4- Captulo II Conceitos Bsicos Programao Orientada a Objetos 5- Captulo III Modelagem atravs UML 5.1 Diagrama de Estudo de Caso 5.2 -Introduo a Classe 5.3 Diagrama de Classe 5.4 Diagrama de Objetos 5.5 Diagrama de Interao 5.6 Diagrama de Estado 5.7 Diagrama de Atividade 5.8 Diagrama de Implantao Pg 3 Pg 4 Pg 5 Pg 16 Pg 20 Pg 23 Pg 30 Pg 34 Pg 56 Pg 58 Pg 59 Pg 60
1. Plano de Estudo
1.Introduo ( 6 h/a) Conceitos de Orientao por Objetos Viso geral da Anlise e Projeto OO Vantagens e Desvantagens da Anlise e Projeto OO Metodologias OO Viso geral da UML 2.Anlise Orientada por Objetos atravs da UML (40 h/a) Diagrama de Caso de Uso Diagrama de Classes Herana Simples e Mltipla Associao unria, binria e ternria. Agregao Empacotamento Diagrama de Seqncia Diagrama de Colaborao Diagrama de Estado Diagrama de Atividade Diagrama de Objetos Estudos de Casos Prticos 3.Projeto Orientado por Objetos (14 h/a) Modelagem da Arquitetura Diagrama de Componentes Diagrama de Implantao Projeto de Banco de Dados OO Diagrama de Classes Objeto Relacional Projeto de Interface Estudos de Casos Prticos
2. Bibliografia
Bibliografia Bsica: [1] Furlan, Jos Davi. Modelagem de Objetos atravs da UML Anlise e Desenho Orientados a Objeto. So Paulo, Makron Books, 1998. [2] Booch, Grady; Rumbaugh, James and Jacobson, Ivair. UML Guia do Usurio. Rio de Janeiro, Campus, 2000. [3] Larman, Craig. Utilizando UML e Padres Uma Introduo Anlise 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. Anlise e Projeto Orientados a Objetos. Estudos de caso. Makron Books, So Paulo,1999. [6] Coad, Peter e Yourdon, Edward. Anlise Baseada em Objetos. Campos, 1996. [7] Martin, James. Anlise e Projeto Orientados a Objetos. Macron Books, 1995. [8] Rumbaugh, James. et al. Modelagem e Projetos Baseados em Objetos. Campos, 1994. [9] Shlaer, Sally. Anlise de Sistemas Orientado para Objetos. Makron Books, 1994.
CAPTULO I - INTRODUO
I Introduo ao Desenvolvimento de Software Software um produto da inteligncia humana, tambm um dos poucos produtos capaz de absorver a idia de algum e colocar a disposio dos outros. Existem livros, fitas e outros meios, mas nenhum deles possui tamanha interatividade igual ao software.
Desenvolvedor Idia Sistema de Software Habilidade
Especialista Figura 01
Usurio
Na construo de um software, alm de criatividade, necessrio conhecimento tcnico e lgico alm de um trabalho disciplinado. A atividade de programao apenas uma das etapas do trabalho de desenvolvimento de um software. A Engenharia de Software a cincia aplicada na transformao 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 avio. As prticas da Engenharia de Software se intensificaram com o agravamento dos problemas relativos ao Software, j afirmava Pressman ( 1995 ) : As sofisticaes dos Problemas ultrapassaram nossa capacidade de construir um Software que extraia toda a potencialidade do Hardware. Nossa capacidade de construir Software de qualidade no pode acompanhar a demanda por novas aplicaes. Nossa capacidade de manter Softwares existentes foi ameaada por projetos ruins e recursos inadequados.
Observa-se que a Engenharia de Software trata intimamente das limitaes da capacidade humana em criar software.
II A importncia da Modelagem fcil 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 construo temos a planta (projeto da casa) e este projeto que permite ao usurio (proprietrio da casa) de avaliar e garantir que o produto final saa de acordo ou o mais prximo possvel do produto final. A Engenharia de Software procura trazer para a cincia da computao essas lies e incentivar a elaborao 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 usurio 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 mximo a expectativa da realizao. A modelagem Orientada a Objetos tem como objetivo, alm do citado acima, de padronizar, automatizar, incentivar a reutilizao de componentes e aumentar a maturidade em uma equipe de desenvolvimento de um projeto. III Processos de Desenvolvimento de Software O Ciclo de Vida
1 Levantamento
2- Anlise
3- Projeto
6- Manuais
5- Gerao Testes
4- Implementao
7- Controle Qualidade Figura 02 Ciclo de Vida
8- Converso do Banco de Dados
9- Instalao
Nesta Disciplina estudaremos a atividade de Anlise de Sistemas
Usurios
Dados para o Modelo
Rotinas do Usurio Restries 2. Anlise
Direo
Especificao da Anlise 3. Projeto
1. Levantamento
Especificao da Documentao
6. Manuais
Figura 03 Anlise de Sistemas Objetivos Bsicos: Desenvolver a especificao lgica, independente do Software e Hardware utilizado. Elaborar um Modelo de Sistema (Ex: Planta de uma Casa) Analisar as caractersticas importantes ao sistema, tais como, levantamento dos dados, processos e informaes que usurio necessita. Documentar o processo de anlise, para que se tenha uma fidelidade no momento da construo do Software por parte dos projetistas e Desenvolvedores.
Tcnicas Bsicas de Anlise: Anlise Estruturada Anlise Essencial Anlise Orientada a Objetos
Anlise Estruturada Surgiu em 74 Crise de Software Baseada em DER / DFD ( DC + DFD Nvel um + DFD Expandido ) DHF / Especificao dos Processos e Dicionrio de Dados
Anlise Orientada a Objetos Surgiu em 1982 (J. Palmer e 1990 Diversos Autores S. McMenamin) Mais Fcil de Entender os Diagrama de Classe DFds / Mais completa / Diagrama de Caso de Uso Mais simples nos DFDs Diagrama de Interao (eventos baseado em Diagrama de Estado estmulos e respostas) Diagrama de Implementao
Anlise Essencial
Abordagem Middle Up Down Foco em Funes, Dados e comportamento do sistema de forma integrada. DFD pode se tornar muito No serve para sistema difcil baseado em Real Time Abordagem Top Down no Sistema Complexo se se mostrou eficiente na mostrou inadequada prtica As fases de Anlise / Projeto e Implementao apresentam um descontnuo
Abordagem Top Down Foco em Processos
Coletnea de Objetos que interagem entre si.
Busca a estrutura do Problema e no apenas da informao. Mostra-se extremamente eficaz. Linguagens OO complementam esta abordagem
Figura 04 Quadro Comparativo
Em Sntese A Anlise Orientada a Objetos formada por um conjunto de objetos que interagem entre si, apresentam caractersticas prprias representadas pelos atributos e operaes. A Anlise Tradicional baseia-se na idia 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 anlises tradicionais Surgimento de linguagens de Programao Orientada a Objetos (C++) Necessidade de Desenvolvimento de sistemas baseado em Real Time com muito mais freqncia
Benefcios da Anlise 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 construdos a partir de componentes j existentes (Herana) Manuteno mais fcil => Independncia entre as classes ajuda no processo de manuteno. Cada classe executa suas operaes independentemente.
Modelagem mais realstica => Anlise, Projeto e Implementao usam o mesmo paradigma.
Justificativa de Mudana Objetos j existem na natureza antes de haver qualquer tipo de aplicao deles pelo negcio: Equipamentos, pessoas, minerais, etc..., existem por si s, apresentam caractersticas peculiares representadas por seus atributos e, adiante, pelo seu comportamento no mundo real.
Problemas da Anlise e Projeto Orientado a objetos Fundamentao terica da AOO no simples Os SGBDs ainda no so totalmente orientado a objetos A mudana de mentalidade e introduo de uma nova tecnologia sempre traz desconfiana Existncia de vrias abordagens para APOO
UML Unified Modeling Language Caractersticas: Uma tentativa de padronizao 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 revises da UML encontramse em http://uml.shl.com. A UML no uma metodologia e sim uma linguagem de modelagem que procura integrar as melhores prticas existentes no mercado. uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software.... um sistema de notao dirigida modelagem de sistemas, usando conceitos orientados a objetos. Tem se tornado um padro mundial utilizado por desenvolvedores, autores e fornecedores de ferramentas Upper e Meta CASE. independente de linguagens de programao OO.
Elementos Fundamentais da Anlise OO O texto a seguir foi adaptado do livro texto Modelagem de Objetos atravs da UML Anlise e Desenho Orientados a Objeto, de Jos Davi Furlan. Diretamente derivada dos conceitos da programao e do projeto orientado a objeto, a anlise e o desenho1 orientados a objeto so certamente a mais nova das abordagens de desenvolvimento de sistemas. A tecnologia de objetos apresenta componentes chaves que fundamentam a mudana de enfoque no processo de modelagem e desenvolvimento de aplicaes, trazendo benefcios intrnsecos filosofia. Rumbaugh define orientao 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 no s envolve programao e habilidades de gerenciamento, mas tambm conhecimento e compreenso das mais recentes inovaes na indstria de software. Um fato curioso no campo da tecnologia da informao que sempre a ltima inovao tecnolgica nos parece ser definitiva e que nada mais ser possvel ser inventado para suplant-la. Isso ocorreu com todas as tecnologias do passado, e certamente vir o dia em que tambm acontecer com a tecnologia de objetos. Analisando-se o comportamento de evoluo dos enfoques de desenvolvimento precedentes, vemos que a ltima proposta apresentada - a Engenharia da Informao (abrangendo modelagem funcional, de dados e estratgica) e os bancos de dados relacionais - comeou a tomar vulto em nvel mundial no final da dcada de 80 decolando de fato a partir do incio dos anos 90. A supor essa mesma evoluo para a orientao a objeto, provvel que at o ano 2000 essa tecnologia ainda esteja tentando ganhar espao nas organizaes e que realmente decole a partir de ento. Todavia, h uma curva exponencial de time-to-market que diz que as inovaes ocorrem em perodos 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 aplicao no universo de objetos consiste de um conjunto de blocos de construo autocontidos (seff-contained code) e predefinidos que podem ser localizados, reparados ou substitudos. A construo de cdigo autocontido propicia o teste completo antes de ser usado dentro da lgica do sistema de informao. Apresenta tambm uma correspondncia com o mundo real, visualizando objetos da natureza conforme so, individualizados e caracterizados com finalidade prpria. Tais objetos permitem ser combinados ou utilizados separadamente, pois, em tese, apresentam baixa dependncia externa e alta coeso interna de seus componentes, o que permite promover substituies sem afetar interconexes ou interferir com a A anlise a parte do processo de desenvolvimento de software com o propsito primrio de formular um modelo de domnio 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 10
1
operao dos demais objetos. Possibilita ainda incrementaes graduais de componentes aos j instalados, ampliando a abrangncia do sistema. A combinao de mdulos prov inicialmente um nvel bsico de funcionalidade que estendido sucessivamente para cobrir novas situaes, em um processo contnuo de progresso da aplicao perante os usurios. Por fim, apresenta um forte direcionamento ao uso de artefatos preexistentes que so criados uma nica vez e disseminados ao longo da estrutura sistmica resultante - a reutilizao facilita o emprego de conceitos similares em situaes apropriadas. Faremos a seguir, uma breve introduo aos principais conceitos da orientao a objeto.
IV Modelagem Orientada a Objetos Quando Matt Flavin criou o primeiro mtodo de AOO, empregava o que hoje conhecido como modelo entidade / relacionamento estendido como base do enfoque. Nas ltimas dcadas houve o aprimoramento constante das tcnicas e metodologias. Mtodos de Modelagens orientados a objetos comearam a aparecer entre a dcada de 70 e meados dos anos 80. Apesar da diversidade conceitual e bibliogrfica, muitos usurios no encontraram satisfao completa nos enfoques disponveis. Todos os mtodos tm suportado, no entanto, os mesmos conceitos bsicos. Dados que os mtodos Booch e OMT estavam crescendo independentemente e sendo reconhecidos pela comunidade seus autores Grady Rooch e James Rumbaugh juntaram foras e atravs da Rational Corporation lanaram um rascunho de um mtodo unificado, como foi chamado a princpio. Tambm de m 1995, Ivar Jacobson juntou-se a equipe de desenvolvimento fundindo o mtodo 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 misso crtica. Muitos reconheceram este esforo e a UML (Unified Modeling Language) surgiu e ganhou parceiro importante. Em Janeiro de 1997, surgiu a verso 1.0 da UML, sendo uma linguagem expressiva, poderosa e geralmente aplicvel. E o melhor, no proprietria e aberta a todos. Em novembro de 1997, a UML foi aprovada pela OMG- Object Management Group- ento a guerra dos mtodos OO tinha chegado ao fim. A partir desse momento a OMG, atravs de seu grupo de reviso RTF Revision Task Force passou a assumir a responsabilidade da evoluo da UML. A UML pode ser usada para : Mostrar as fronteiras de um sistema e suas funes utilizando atores e casos de uso Ilustrar a realizao de casos de usos com diagramas de interao Representar uma estrutura esttica de um sistema utilizando diagramas de classe Modelar o comportamento de objetos atravs dos diagramas de transio de estado
11
Revelar a arquitetura de implementao fsica com diagramas de comportamento e de implantao Entender sua funcionalidade atravs de esteretipos.
A UML vai alm de uma simples padronizao em busca de uma notao unificada, uma vez que contem conceitos novos que no so encontrados em outros mtodos orientados a objetos. A UML uma linguagem padro 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 atravs de diferentes tecnologias de implementao. A UML uma linguagem de modelagem, no uma metodologia. Muitas metodologias consistem, pelo menos em princpio de uma linguagem de modelagem, e um procedimento de uso dessa linguagem. A UML no prescreve explicitamente esse procedimento de utilizao. Apesar de ser valiosa uma padronizao de uma metodologia, uma linguagem padro j mais que suficiente. A metodologia Objectory ( Rational Corporation Process) utilizando a UML uma referncia em desenvolvimento orientado a objeto. Em seu estado atual a UML define uma notao e um metamodelo. A notao o material grfico visto em modelos, a sintaxe da linguagem de modelagem. Por exemplo, a notao de diagrama de classe, associao e multiplicidade. Claro que isso conduz pergunta do que exatamente isto significa. Tecnologia Back End para Orientao a Objeto
A tecnologia de banco de dados tem permitido o armazenamento, recuperao e processamento de dados que descrevem entidades existentes no mundo real. J estamos chegando na 5 gerao de banco de dados. Gerao 1 2 3 4 5 Suporte Arquivos seqenciais processamento batch Banco de Dados Hierrquico Banco de Dados em Rede Banco de Dados Relacional Banco de Objetos
Atualmente Banco de Dados relacionais prevalecem no mercado, mas os fabricantes j esto 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 so capazes de manipular estruturas complexas, a mudana para este tipo de arquitetura tem seu preo. Para se utilizar Banco de Objetos, os profissionais necessitam investir razovel parcela de tempo e esforos na fase de modelagem. Levando-se em considerao que ainda exista obstculos para a utilizao deste tipo de arquitetura, os Banco de Objetos possuem um extraordinrio potencial de crescimento. Professor : Rodrigo de Matos Vargas Todos os direitos reservados 12
Obs: Banco de Dados relacional estendido e objeto relacional seguem um padro hbrido entre relacional e objeto, ou seja, a interface, operaes e quareis podem residir tanto no cdigo da aplicao quanto no Banco de Dados (na forma de Chore Procederes). Devido ao enorme dinamismo do mercado tecnolgico, podemos citar abaixo alguns dos principais fabricantes e distribuidores de Banco de Objetos. Fabricante GEMSTONE Caractersticas Arquitetura Cliente / Servidor Ambiente de Desenvolvimento Visual Suporta C++, Cobol, Fortran e outros OBJECT OBJECTSTORE Aplicaes intensiva em dados DESIGN Compatvel com C++ Interface de aplicao acompanha o produto Ferramenta de Programao Energize Visual C++ VERSANT VERSANT Criar Objetos reutilizveis e modificveis OBJECT Conceito de Banco de Dados distribudo que TECHNOLOGY est diretamente ligado a linguagens orientadas a objetos Suporta aplicaes Cliente / Servidor Inclui uma ferramenta grfica OBJECTIVITY OBJECTIVITY / Ambiente Integrado de desenvolvimento / DB DB Usurios podem definir e manipular objetos Manipulao complexa de dados OBJECT EASY / DB Linguagens de programao C++, Ada SYSTEM SF Linguagem interativa de consulta O-SQL Capacidade de manipulao de erros, conflitos e tratamento de excees. ONTOS / DB ONTOS DB Banco de Objetos Distribudo Modelo Cliente / Servidor Linguagens Genricas C++ Utiliza-se de SQL Administrador e Manipulador grfico de dados COMPUTER JASMINE Plataforma Cliente / Servidor e Internet ASSOCIATES O Gerenciador de Banco de Objetos e de desenvolvimento totalmente voltado a orientao a objeto Suporte a herana Mltipla / classes / mtodos Cada objeto tem um nico identificador Vem com ODQL linguagem de desenvolvimento Produto GEMSTONE
13
Base de Dados Objeto / Relacional
Especialistas dizem que h pouca coisa em comum entre o modelo de objetos e o modelo relacional. Entretanto na prtica 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 Viso Modelo Entidade / Relacionamento => Pacotes e interfaces de classes que ditam como a classe acessada.
Podemos citar outras semelhanas entre os dois modelos, mas este no nosso objetivo. Para entendermos um modelo banco de dados objeto tem de incorporar algumas mudanas. Essas mudanas sero enfocadas em nosso prximo captulo. Enquanto a tecnologia de banco de objetos no for adotada em escala, a estratgia de incorporao da orientao a objeto ir certamente permanecer durante a fase de modelagem do negcio sendo implementada em seguida em banco de dados relacionais ou hbridos.
Tecnologia Front-End para Orientao a Objeto As linguagens de programao orientada a objetos evoluram, trabalhando atualmente com funes GUI ( Graphical User Interface ), ferramentas case e programao 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 programao orientada a objetos: Proteo de dados => utilizao de mdulos Abstrao de dados => Definio de um tipo abstrato de dados Coeso Dinmica => Mdulo chamador recebe o endereo da rotina associando uma mensagem Hereditariedade => Herana
As principais linguagens de programao orientada a objetos incluem o C++, e atualmente com maior nfase temos o Java. O Java uma linguagem desenvolvida pela Sun Microsystems Inc, de fcil aprendizado e utilizao, poderosa e principalmente com enorme portabilidade. Sua sintaxe prxima ao C++ favorecendo aqueles que j trabalharam com esta linguagem. Enquanto as linguagens procedurais esto voltadas para processos e dados, as linguagens de programao orientadas a objetos visam os objetos e as mensagens. A programao orientada a objetos no separa os dados dos processos e sim traz juntos esses dois conceitos. No h, entretanto um consenso quanto definio de linguagem orientada a objeto e os conceitos na UML. Mas existe sim uma generalizao entre os conceitos de UML e a linguagem orientada a objetos. Professor : Rodrigo de Matos Vargas Todos os direitos reservados 14
Elementos da UML Ao Atributo Constante (Imutvel) Atributo de Classe Atributo de Objeto
Java Declaraes Final Esttico Varivel de Classe esttico Varivel de Instncia
Ateno: Quadro comparativo poder ser encontrado no livro Modelagem de Objetos atravs da UML autor Jos Davi Furlan
Ferramentas de Modelagem A necessidade de novos produtos, pela demanda da programao orientada a objetos levou a indstria 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: Mtodos Suportados e ambiente tecnolgico Suporte aos diagramas da linguagem de modelagem Participao no mercado de ferramentas Presena de um repositrio para armazenar dados Projetos de grande porte Navegao no modelo com rastreamento de um elemento Ambiente multiusurio Engenharia Reversa Complexidade das Ferramentas Integrao com outras ferramentas Preo Treinamento Oferecido
Vrias ferramentas esto surgindo e avaliao de cada uma, dever ser feita de forma independente e imparcial.
15
CAPTULO II CONCEITOS BSICOS
Conceitos Bsicos da Programao Orientada a Objetos
Diversos so os princpios e conceitos que a anlise e projeto orientado a objeto baseia-se. Os principais conceitos sero listados e discutidos nos prximos tpicos. Conceitos e Princpios Objeto Encapsulamento Mensagens Tipos, Classes Herana Polimorfismo
Objeto Como j foi falado um dos principais elementos da programao orientada a objetos o prprio objeto. Um objeto nada mais que uma ocorrncia especfica de uma classe e similar a uma entidade no modelo entidade / relacionamento at no ponto que uma coleo de dados une-se para formar um tema em comum. Exemplificando, temos o nome e endereo de uma editora, a Makron Books. Os dados nome e endereo pertencem entidade [organizao] ou ao objeto [Makron Books]. A diferena entre objeto e entidade que o primeiro uma ocorrncia de uma classe. Um objeto poder encapsular operaes, atributos, operaes podendo estas encapsulaes ser privadas ou pblicas. Classes Veculos Funcionrios
GOX 3444 GOL 1243 Exemplo : Classe x Objeto
Objetos
Maria, Caixa Pedro, Gerente
16
Classe Classe uma coleo de objetos que podem ser descritos com os mesmos atributos e as mesmas operaes. Representam uma idia ou um conceito simples e categoriza objetos que possuem propriedades similares. Todos os objetos de uma classe possuem as mesmas definies, mas podem possuir valores diferentes nos dados, respondendo de modo diferente as mensagens enviadas. SuperClasse e SubClasse
Na criao de classe existe a possibilidade de ocorrer uma conexo 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 substitudas ou mascaradas nessa transio. Novas propriedades podero ser acrescentadas a classe filha. Todo esse processo narrado acima descreve mais um dos princpios da orientao a objeto: Herana. Ateno: Alguns autores mudam o termo superclasse para supertipo e subclasse para subtipo, mas a essncia do propsito continua o mesmo. Outras terminologias tambm podero ser encontradas.
Herana a capacidade de um novo objeto tomar atributos e operaes de um objeto existente, permitindo criar classes complexas sem ter que repetir o cdigo. Se uma classe herda comportamento e atributos de mais de uma classe damos a ela o nome de herana mltipla, uma variao semntica de generalizao, na qual um tipo pode ter mais de um supertipo. Classe Automvel A Classe Automvel contm informaes como potncia , passageiros, etc... A sub Classe Esportivo herda todas essas propriedades e acrescenta outras. Por Fim Porsche herda todas as propriedades das classes acima.
Automvel Esportivo
Porsche
17
Mensagens Os objetos se comunicam atravs de mensagens, isto , um sinal enviado a um objeto requisitando um servio, as operaes so executadas e o resultado da operao enviado ao objeto solicitante. Uma mensagem a chamada de uma funo de um objeto, o acionamento de uma operao encapsulada no objeto de destino, feita a partir do objeto de origem. A informao transmitida passada ao objeto de destino atravs dos parmetros de uma funo, enquanto a resposta passada pelo parmetro de retorno da funo. Para que os objetos se comuniquem necessrio que haja algum tipo de ligao / vnculo entre eles. Esses vnculos podem ser relacionamentos entre os objetos. Exemplo: Controle Remoto Envia O controle remoto envia uma mensagem para a tv, mas essa s consegue interpretar a mensagem por que possui uma interface de recepo. A definio 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. Televiso
Polimorfismo Polimorfismo a propriedade que o emissor de uma mensagem no precisa saber a instncia da classe que recebe esta mensagem. Essa propriedade leva ao fato de que uma mensagem pode ser interpretada de vrias formas da o nome Polimorfismo. Geralmente as pessoas confundem polimorfismo e encapsulamento porque ambos referem-se ao ocultamento da implementao do mundo externo ao objeto.
P o lim o rf ism o
S ald o (C o rren tista)
SALD O
S ald o P o u p an a S ald o F u n do d e A es
S ald o R en d a F ix a
S ald o fu n d o Balan cead o
18
Adicionalmente aos conceitos vistos acima podemos destacar ainda os conceitos de dependncia e coeso de classe. Dependncia refere-se ao conhecimento que uma classe possui de outra o ideal a minimizao da dependncia para evitar impactos na modificao de uma classe sobre a outra. Coeso uma medida de integridade conceitual de uma classe o objetivo o de maximizar a coeso para assegurar o agrupamento de operaes e com isso reduzir esforos de manuteno. Segue abaixo uma breve descrio dos principais conceitos da teoria de objetos: Palavra Chave Atributo Classe Definio Caracterstica particular de uma ocorrncia da classe Agrupamento de objetos similares que apresentam os mesmos atributos e operaes Combinaes de atributos e operaes dentro de uma classe Atributos e operaes diferentes de uma subclasse, acrescentando ou substituindo caractersticas herdadas da classe pai Situao de um objeto em um dado instante de tempo Uma ocorr6encia significativa no mundo real que deve ser tratada Atributos e operaes comuns compartilhados por classe Compartilhamento pela subclasse dos atributos e operaes da classe pai o mesmo que objeto Exemplo Indivduo possui nome, sexo e data de nascimento. Veculo, caracterizado pelos veculos do mundo. Atributo: Data Nascimento Operao: Clculo de sua idade Subclasse Organizao e Indivduo acrescentam atributos e operaes distintos da superclasse Parte Emitindo Nota Fiscal Pedido efetivado, entrega efetuada Superclasse veculos como generalizao da classe veculo esportivo Subclasse [Eucalipto] herda as caractersticas da classe [rvore] Uma pessoa, organizao, equipamento, uma localizao geogrfica. Informar a idade do cliente Fulano Uma pessoa, organizao, equipamento, uma localizao geogrfica. Clculo de uma idade Verificao de Cpf Ex: Verificar Saldo, Saldo em CC, Saldo em Renda Fixa, Saldo Poupana.
Encapsulamento
Especificao
Estado Evento Generalizao
Herana
Instncia de Classe
Mensagem Objeto
Solicitao entre os objetos Sinnimo de Instncia de Classe
Operaes Polimorfismo
Subclasse
Lgica contida em uma classe para designar-lhe um comportamento Habilidade para usar a mesma mensagem para invocar comportamentos diferentes dos objetos Caracterstica Particular de uma Classe [rvore] => subclasse classe [ip] 19
CAPTULO III MODELAGEM ATRAVS DA UML
Os dois primeiros captulos desta apostila foram dedicados a uma introduo ao mundo da orientao a objetos, seus mtodos, suas tecnologias e ferramentas. Agora vamos entrar precisamente na modelagem de objetos atravs do uso de uma linguagem unificada de modelagem UML (Unfield Modeling Language). O modo para descrever os vrios aspectos da modelagem pela UML atravs da notao definida pelos vrios tipos de diagramas. Um diagrama uma representao grfica de uma coleo de elementos. Modelar um sistema complexo uma tarefa extensiva sendo necessria a descrio de vrios aspectos, conforme citado abaixo: Aspecto funcional (estrutura esttica e interao dinmica) No funcional (tempo de processamento, confiabilidade, produo). Organizacional (Organizao do trabalho, mapeamento e codificao). Cada viso descrita em um nmero de diagramas que contm informao enfatizando um aspecto particular do sistema. A UML distingue as noes de modelo e diagramas. 1) Um modelo contm informaes a respeito dos elementos subjacentes de um sistema em estudo de maneira independente de como so apresentadas visualmente. Um diagrama, por sua vez, uma visualizao particular de certos elementos de tipos de um modelo e geralmente expe apenas um subconjunto de informaes detalhadas sobre esses elementos.
2)
A maioria dos diagramas UML refere-se a grficos que contm ns conectados por caminhos, sendo que a informao est principalmente na topologia e no no tamanho ou na colocao dos smbolos. H trs tipos de relacionamentos topolgicos importantes: Conexo => Normalmente de linhas forma 2-d Reteno => De smbolos para formas 2-d com limites Anexo Visual => Um smbolo que est prximo a outro em um diagrama Elementos grficos usados na UML: cones Smbolos 2-d Caminhos Textos
20
A notao da UML uma combinao de sintaxe vinda de vrias fontes, mas com vrios smbolos removidos das tcnicas anteriores, e outros smbolos novos agregados. Principais Diagramas Os diagramas descrevem mais precisamente os fenmenos observados no problema, assim como permitem encaminhar o sistema sua implementao. Cada um dos diagramas enquadra-se em uma finalidade e o conjunto de diagramas tem como principal finalidade demonstrar a essncia do funcionamento do sistema. Diagrama Classe Seqncia Colaborao Estados Atividades Componentes Distribuio Enfoque Estrutural Dinmica Dinmica Dinmica Dinmica Implementao Implementao Descrio Estrutura esttica do sistema Mensagens entre classes no tempo Mensagens por entre vnculos da classe Dinmica interna de uma classe Dinmica interna e externa de uma classe Estrutura dos componentes de Software Estrutura dos processadores de Hardware
Exemplos de Navegao entre os diagramas UML Comportamento Externo Casos de Uso
Estrutura
Classe
Pacotes
Comportamento Interno
Eventos
Colaborao
Atividade
Estado
Implementao
Componentes
Distribuio
21
Em sntese: As classes, identificadas no modelo conceitual, formam a base sobre a qual ao erguidos os componentes do sistema. As classes mostram apenas uma viso esttica do sistema. Uma viso dinmica oferecida pelos diagramas de seqncia e interao, que representam as mensagens trocadas entre as classes. O diagrama de estado mostra o ciclo de vida de uma classe, representando sua dinmica interna. Para serem construdas, as classes podem ser agrupadas em componentes de software que so distribudas pelos servidores. Essas situaes so descritas pelos diagramas de componentes e distribuio. O modelo de contexto define o comportamento externo do sistema, que distribudo, na modelagem conceitual, para as classes do sistema. Essas classes participam dos processos que podem ser modelados pelos diagramas de seqncia, atividades ou colaborao. Internamente as classes tm seus ciclos de vida modelados pelo diagrama de estados. No modelo de contexto e conceitual, o analista se coloca em uma posio de alguma distncia em relao ao sistema para conseguir a viso 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.
22
Diagrama de Casos de Uso Objetivo: Modelar o comportamento dinmico do sistema (especifica). Mostrar as funes essenciais do sistema (requisitos). Proporciona uma viso geral do sistema ou de um subsistema (contexto). Indica os limites e a abrangncia do sistema (escopo). Componentes: Casos de Uso. Atores. Relacionamentos (interao) entre atores e casos de uso. Sistema.
Notao UML: Diagrama de Caso de Uso
Sistema Ator
Interao Caso de Uso 1
Interao
Caso de Uso N
Histrico: Criado e divulgado por Ivar Jacobson a partir de 1994. Primeiramente utilizado na metodologia OOSE/Objectory. No exclusividade da UML: Diversas outras metodologias foram adaptadas para utilizar Casos de Uso para representar a especificao funcional do sistema.
23
Casos de Uso (Use Case): Um conjunto de seqncia de aes realizadas pelo sistema ou parte de um sistema para produzir um resultado observvel por um ator (entidade externa). Descreve os requisitos funcionais do sistema. Demonstram o comportamento essencial do sistema a partir da lista de eventos: Comportamento: funes para visualizar, especificar, construir e documentar. No deveriam ser nem amplamente gerais, nem muito especficos. Um caso de uso especifica o que um sistema faz e no especifica como isso feito. Notao UML:
Comprar Produtos Matricular Aluno Cadastrar Dependente Utilitrios:: Preencher Cheque
Alguns autores utilizam nomes dos casos de uso que indicam o evento (matrcula de aluno, solicitao de extrato) e no a ao (matricular aluno, emitir extrato). Um Caso de Uso composto por: Um conjunto de passos (steps) que caracteriza a seqncia de aes. Descrio (description) do caso de uso (dicionrio de dados). Pr-condies que caracterizam aes que devem ocorrer antes do caso de uso ocorrer e ps-condies que caracterizam aes que devem logo depois. Exemplo com o uso da ferramenta CASE System Architect 2001.
24
25
Observaes: Um erro muito comum ao identificar um Caso de Uso representar como Casos de Usos passos individuais, operaes, ou transaes. Exemplo: Imprimir nota de caixa, no 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 algum de fora seja capaz de compreend-lo com facilidade. Atores: uma Entidade Externa que interage com o sistema: Entidade Externa: usurios, grupo de usurios, outros sistemas, dispositivos eltricos ou mecnicos. Interagir: fornecer dados ou receber informaes do sistema. Notao UML: (stick man - "homenzinhos")
Cliente Caixa Sistema de Compras Computador Central
No so partes do sistema. Representam papis que um usurio pode desempenhar. Um Caso de Uso sempre iniciado por um ator que lhe envia um estmulo. Originam classes no Diagrama de Classes contendo o esteretipo <<actor>>.
26
Caixa <<actor>> Caixa
transitory
As respostas s seguintes perguntas podem auxiliar a identificar atores: Quem vai utilizar as principais funes do sistema? (atores principais). Quem ir manter, administrar e fazer com que o sistema permanea operando? (atores secundrios). Com quais outros sistemas o sistema em foco vai interagir? Quais os dispositivos de hardware so necessrios ao sistema? Relacionamentos do Diagrama de Casos de Uso: Relacionamentos entre ator e caso de uso: Relacionamento de comunicao (default). Navegvel em ambas as direes ou em apenas uma.
Cliente
Comprar Produtos
Caixa
Iniciar uso Caixa
Observaes: No se indica o "fluxo de dados" No System Architect no se indica a direo. Sempre so bidirecionais. Relacionamentos entre Casos de Uso: Indica um tipo de herana: 1) Uso <<include>>: Aparece quando alguns casos de uso tm comportamentos comuns. Este comportamento pode ser modelado como um nico caso de uso que usado pelos demais. A relao de uso implica que todo caso de uso mais genrico vai ser utilizado pelo caso de uso mais especfico. um tipo de herana.
27
Exemplo:
Cliente
Comprar Produtos
Caixa
Iniciar uso Caixa
<<uses>> Fechar Caixa <<uses>> Validar Senha
2) Extenso <<extends>>: Aparece quando um caso de uso tem um comportamento opcional em relao a um outro. O Caso de Uso mais geral fornece uma extenso (faz um pouco mais) ao caso de uso mais especfico.
Imprimir documento
<<extends>>
imprimir para arquivo
Cliente <<extends>>
Comprar Produtos com Carto
Caixa
Comprar Produtos
28
Mtodos para identificar Casos de Usos: Um mtodo usado para identificar casos de usos baseado nos atores: Identificar os atores relacionados aos sistemas ou organizao. Para cada ator identificar os processos que eles iniciam ou dos quais eles participam. Outro mtodo 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", "Estmulos", "Aes" e "Respostas". Relacionar os eventos aos atores e aos casos de uso. Diagrama de Caso de Uso: Viso grfica de alguns ou todos os atores, casos de usos e suas interaes. Cada sistema possui um diagrama principal indicando os limites e funcionalidades do sistema. Exemplo: Outros diagramas podem ser necessrios:
Sistema de Caixa Supermercado
Comprar Produtos com Cheque Comprar Produtos com Carto
Cliente
Caixa
<<extends>> Comprar Produtos
<<extends>>
Iniciar uso Caixa Gerente Validar Senha <<uses>> Encerrar Caixa
<<uses>> <<uses>>
Cadastrar Caixa
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.
29
Um Diagrama de Caso de Uso bem estruturado quando: Tem como objetivo representar uma viso dinmica do sistema. Contm atores e Casos de Uso essenciais compreenso do sistema. Tem uma distribuio dos seus elementos que minimize cruzamentos de linhas. Tem seus elementos organizados espacialmente de maneira que os casos de usos estejam semanticamente prximos e relacionados. Classes
Agrupamento de objetos similares que possuem os mesmos atributos e operaes. " a representao de um conjunto de coisas reais ou abstratas que so reconhecidas como sendo do mesmo tipo por compartilhar as mesmas caractersticas de atributos, relaes e semntica" - Jos Davi Furlan. So os principais componentes de um Sistema Orientado a Objetos. A UML representa graficamente uma Classe como um retngulo contendo seu nome, atributos, operaes (mtodos) e tipo da classe (persistente ou transitria).
NomeDaClasse Atributos : Tipo Operaes TipoDaClasse NomeClasse
Atributos, operaes ou tipo da classe so opcionais e portanto, podem ser suprimidos mas as linhas devem aparecer. Nome da Classe: Substantivos ou expresses breves que indique o significado da classe no contexto do sistema que est sendo especificado. Tipicamente, aparece como maisculo o primeiro caractere de cada palavra existente no nome da classe. Exemplos: Cliente, MatrculaAluno, SensorTemperatua, Pessoa, Emprstimo. Uma classe pode ser: Objeto real: Equipamento, Livro, Mquina, NotaFiscal, Avio. Pessoa: Empregado, Cidado, Dependente, Gerente, Cliente, Fornecedor. Conceito abstrato: Curso, Cor, Projeto, Departamento, Cargo, Escolaridade. Acontecimento: Casamento, Compra, Venda, PedidoCliente, ReservaLivro. Dispositivos ou sistemas exteriores: SistemaMatrcula, LeitoraOtica, cone, Arquivo, ProgramaExecutvel, JanelaMdico.
30
Atributos: Elemento que caracteriza/descreve um objeto de uma classe.
Visibilidade pblica Visibilidade protegida Visibilidade privada
Cliente + NomeDoCliente : char # Situao : byte - LimiteDeCrdito : double
+ Visibilidade pblica: o atributo visvel por todas as operaes declaradas em outras classes do sistema. # Visibilidade protegida: o atributo visvel por todas as operaes declaradas no pacote em que a classe declarada. - Visibilidade privada: o atributo visvel somente pelas operaes da classe em que o atributo foi definido A visibilidade pode ser suprimida indicando que no se conhece com antecedncia a visibilidade do atributo. Barra (/) antes da visibilidade indica que o atributo um atributo derivado. Exemplo: /+ ValorTotalFatura, /# SalrioLiquido, /- SaldoConta Um atributo pode ser: 1. Atributos simples ou compostos: Simples: Nome_Cliente, CPF_Funcionrio, Salrio_Bruto, Quantidade, Descrio. Composto: Endereo [rua, nmero, cep, cidade, estado], Data_Nascimento [Dia, Ms, Ano]. 2. Atributos monovalorados ou multivalorados: Monovalorado: CPF, CI, Data_Nascimento, Telefone, Endereo. Multivalorado: Telefones(0,n), Cores(0,5), Endereos(0,2). 3. Atributos obrigatrio ou opcional: Obrigatrio: Nome_Cliente, Ttulo_Livro, Quantidade_Estoque. Opcional: Sexo(0,1), Data_Pagamento(0,1), Salrio_Lquido(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 no visvel para os usurios do sistema. O identificador (OID) criado e atribudo automaticamente pelo SGBDOO e no deve ser identificado pelo analista na classe. Se o atributo "chave" existir no mundo real ele deve ser identificado mas, no ter a propriedade do atributo identificador. Ser apenas mais um atributo da classe. Sintaxe padro de atributos na classe: Visibilidade NomeDoAtributo : Tipo = Valor Inicial {propriedade/descrio}
31
Tipo: Tipo de dado do atributo que depende da linguagem de programao escolhida.

Aproveitamento
Aluno + Nome : char + Endereo : char + Telefone(0,n) : char persistent
Disciplina
Boleta + NumeroBoleta : int # ValorTotal : float # DataPagamento : char persistent
+ Semestre : char + Nome : char # CargaHorria : double + Freqncia : int # Nota : double - SituaoFinal : boolean persistent persistent
Operaes: Comportamento resultante de um procedimento algortmico (Operao = algo invocado pelo objeto da classe; mtodo = corpo do procedimento que implementa a operao). As operaes devem ter nomes que indique seu resultado atravs de um verbo: VerificarItemEstoque, ObterDadosCliente, RegistrarProduto, EmitirNotaFiscal, CancelarCliente, CalcularMulta, CalcularSaldoDevedor, ValidarSenha. As operaes so identificadas atravs do diagrama de caso de uso (Steps, Exceptions e pr e ps condies). Posteriormente veremos que as operaes sero agregadas a uma classe atravs do diagrama de seqncia dos casos de usos. Uma operao pode ser: 1. Construtura: cria e/ou inicializa o estado de um ou mais objetos da classe. Exemplos: RegistrarAluno, GravarPedido, CriarJanelaMatricula, IncluirLivro. 2. Seletora: operao que tem acesso, mas no pode alterar o valor de um objeto. Exemplos: ObterDadosCliente, VerificarSenha, LerSituaoAluno, CalcularTotalFatura, EmitirEstoque. 3. Modificadora: operao que altera o valor ou estado de um objeto. Exemplos: RegistrarNota, AlterarStatusPedido, AlterarDadosFornecedor, DarBaixaEstoque. 4. Destrutora: operao que destri/desabilita um objeto. Exemplos: ExcluirDependente, RetirarItemPedido, FecharJanelaMatrcula, RemoverExemplarLivro.
Exemplo Java: byte, short, int, long, float, double, char, Boolean ou none (indefinida).
32
<<actor>> SetorCompras
<<entity>> Medico
<<utility>> Utilitarios PreencherCheque(Valor) : char ValidarSenha ValidarData(Data)
<<interface>> JanelaMatricula Abrir Fechar Mover Minimizar Maximizar
Aluno + ra : int + Nome : char + Endereo : char + Telefone(0,n) : char + RegistrarAluno(ra) # EmitirSituao persistent
Disciplina + Nome : char # CargaHorria : double # VerificarPrRequisito + ObterDadosDisciplina + VerificarVagas : int persistent
Aproveitamento + Semestre : char + Freqncia : int # Nota : double - SituaoFinal : boolean - RegistrarFreqnca - RegistrarNota GravarSituaoFinal # EmitirHistricoEscolar(ra) persistent
Sintaxe padro das operaes: Visibilidade NomeDaOperao (Parmetros) : TipoDeRetorno {propriedade} Pode ser definido um esteretipo (marca) para um classe: Actor, Interface, Entity, Utility, ... Lembre-se: Ao definir uma operao melhor que ela faa apenas uma funo. Isto aumenta a reusabilidade da operao em outras classes. Operaes com mesmo nome em classes diferentes so operaes polimrficas. Isto interessante na fase de modelagem quando no sabemos ainda se a regra de negcio diferente para classes diferentes. Exemplo: CalcularSaldo nas classes (ContaCorrente e ContaPoupana). Como identificar uma classe? Atravs das descries (description) do Caso de Uso identificar os substantivos ou locues substantivas: eleg-lo ou no como uma classe candidata. A lista de eventos tambm pode ajudar. Classes que compartilharem atributos em comum devem ser agrupadas gerando superclasses.
Professor : Rodrigo de Matos Vargas Todos os direitos reservados 33
Busque equilbrio entre funcionalidade e reutilizao, resistindo-se ao desejo de criar classes grandes que abrangem tudo. Classes menores so mais fceis de serem compreendidas e implementadas. Se uma classe for difcil de entender, no podendo ser explicadas em poucas linhas, ou ainda tiver muitas operaes forte candidata a ser dividida em classes menores.
Diagrama de Classe Grfico bidimensional de elementos de modelagem que podem conter tipos, pacotes, relacionamentos, instncias, objetos e vnculos (conexo entre dois objetos). O diagrama considerado esttico, pois sua estrutura sempre vlida em qualquer ponto no ciclo de vida do sistema. Um diagrama de objeto uma variao do diagrama de classe e utiliza quase a mesma notao. A diferena entre os dois diagramas que o diagrama de objeto mostra um nmero de instncia de classes, em vez de uma classe real, e apresenta o nome do objeto sublinhado dentro do retngulo. Os diagramas de objetos no so to teis quanto os digramas de classes.
Objetivos Representao das classes e a relao entre elas Viso esttica e estrutural do sistema Semelhante ao DER para Banco de Dados relacionais
Tipos de Relacionamentos Herana Associao Agregao Dependncia Herana Relacionamento entre classes onde uma classe compartilha a estrutura e comportamento de uma ou mais classes. Uma classe mais geral, a superclasse, tem atributos, operaes e associaes comuns que so compartilhadas por uma classe mais especializada a subclasse. Subclasse herda atributos, operaes e relacionamentos. Subclasse pode incluir : atributos , operaes e relacionamentos Subclasse pode redefinir as operaes herdadas (Polimorfismo)
34
As classes so identificadas por retngulos divididos em 03 pores, como mostrado na figura abaixo: Representao Tpica Nome da Classe Atributos Operaes Exemplo 01 Figura +Origem : Int Move Open Display Resize Close Representao Simples Nome da Classe
Polgono +Pontos: Vetor Display
Crculo +Raio: Float
Retngulo +Largura: Float +Altura :Float
Quadrado
35
Exemplo 2 : Pessoa +Nome :Char +Endereo : Char +Telefone(0,n): char Regitrar
PessoaFsica +CPF : Char +RG : Char +DataNascimento: Date Validar CPF
PessoaJurdica +CGC : Char
ValidarCGC
Restries para Herana
A Restrio de Herana B C N
Herana Completa (N no conhecido) ou Herana Incompleta (N no conhecido). Herana Disjuno (B,C, ..., N so mutuamente exclusivos) ou Herana Sobreposio (B, C, ..., N podem ocorrer simultaneamente).
36
Exemplo
Empregado Sobreposio Incompleta Engenheiro Secretria Administrador ClienteTitular Cliente Disjuno Completa ClienteDependente
Exemplo 4: Teoricamente no h limite no nmero de nveis da hierarquia

Usurio Sobreposio Completo
Aluno Sobreposio Completo
Professor
Funcionrio Disjuno Incompleto
Graduao
PosGraduao
Extenso
Gerente
Supervisor
Subordinado
Exemplo Incorreto ?
Cliente
ClienteMasculino
ClienteFeminino
37
Num sistema de biblioteca isto seria errado: as subclasses se comportam da mesma forma. Num sistema de pesquisa de mercado aplicvel, pois os hbitos de compra so diferentes para as subclasses. Quando criar superclasses e subclasses? A subclasse tem atributos ou operaes adicionais? As subclasses tm associaes adicionais que represente melhor a realidade? Exemplo 6:
Conta
ContaCorrente
ContaPoupana
sofre
CorreoMonetria
As classes possuem atributos e operaes comuns? Junte-as em uma superclasse se achar conveniente, mas use o bom senso. Evite criar superclasses grandes demais que agregam tudo. Isto no facilita a implementao ... Exemplo: a) No fica bom: Superclasse Parte se especializando em Indivduo e Organizao. b) Fica bom: Superclasse Pessoa se especializando em Funcionrio, Cliente e Fornecedor. Exemplo 7a: Ruim
Engenheiro
Civil
Nuclear
Mecnico
Minas
Metalrgico
Eletricista
Exemplo 7b: Bom
Engenheiro
Possui
CategoriaEngenheiro
38
Herana Mltipla: Tipo de herana que indica que um uma subclasse herda atributos e comportamentos de duas ou mais classes ao mesmo tempo. Exemplo 8:
AlgoQueVoa Veculo + Cor : char Sobreposio Incompleto VeculoTerrestre VeculoAqutico ObterCor + Cor : char ObterCor Animal
Pssaro VeculoAnfbio
Conflito de Atributos e Operaes
Conceitualmente necessria para modelar o mundo real de forma mais precisa. Na prtica pode gerar dificuldades na implementao. L4G e BDOO no suportam. Nota: Use herana entre duas classes quando a regra de negcio sugere que um objeto na classe pai " do tipo de" ou "se especializa em" um objeto na classe filha. Formam herana: PessoaFsica/PessoaJurdica, PessoaLocatria/PessoaLocador, Peridico/Livro, ScioTitular/ScioDependente, PeaManufaturada/PeaTorneada, Gerente/Supervisor, etc. No formam herana: Empresa e Departamento, Cinema e Salas, Livro e Exemplar, Disciplina e Turma, Escola e Aluno, Pedido e Item de Pedido, etc. 2.1 Associao Relacionamento entre classes que indica a ligao entre objetos de duas ou mais classes. Usado pelo SGBDOO para gerar as informaes necessrias ao sistema OO. As associaes so representadas por uma linha ligando as classes associadas. S se deve associar as classes se a informao que est sendo representada for
Classe 1
Nome da Associao
Classe 2
importante na regra de negcio.
39
Exemplos: desejvel saber quais funcionrios esto associados a quais departamentos da
Funcionrio
Est Lotado
Departamento
empresa: desejvel saber quais so as disciplinas um aluno cursou ou est cursando na universidade:
Aluno
Cursa/Cursou
Disciplina
Geralmente no desejvel saber quais os relatrios uma pessoa emite ou j emitiu
Pessoa
Emite
Relatrio
... Geralmente no desejvel saber quem foi o funcionrio que cadastrou o aluno ...
Funcionrio
Cadastra
Aluno
40
Notas: Aes que indicam processos no geram associaes entre classes. O nome da associao deve ser um verbo representativo que indique o fato observado.Entre duas classes pode existir mais de uma associao e uma associao
Empregado + Nome : char + Endereo : char + Telefone(0,n) : char
Est Lotado
Departamento + Sigla : char + Descrio : char
Gerencia
Atributos_Gerencia Gratificao DataGerncia
pode conter atributos prprios. Obs: Pode-se colocar os atributos da associao assim: Gerencia (Gratificao, DataGerncia). Uma associao pode ter qualificador tipo papel, que indica o propsito que uma classe se associa a outra. O nome de um papel colocado ao longo da linha da associao, prximo classe referenciada.
Pessoa Professor
Leciona
Disciplina
Pessoa Funcionrio
Trabalha Em Empregador
Empresa
Multiplicidade de Associaes: representa um nmero de instncias de uma classe relacionada a uma instncia de outra classe.
41
Funciona como uma restrio a ser imposta de acordo com a regra de negcios. Tipos:Associao 1:N
Zero ou Um
0..1
Classe
Exatamente Um
1
Classe
Zero ou Mais
0..*
Classe
Zero ou Mais
Classe
Um ou Mais
1..* m..n
Classe
Mais de Um
2..*
Classe
Classe
5..60
Classe
Seqncia Especificada
Seqncia Especificada
Indica que um objeto de uma classe pode estar associado a vrios objetos de outra classe. Exemplo 1: Exemplo 2: Qual a realidade?
1
Curso
Possui
0..*
Sentido de Leitura
Aluno
Departamento
Lotao
0..*
Empregado
Departamento
0..1
Lotao
0..*
Empregado
Departamento
Lotao
1..*
Empregado
Departamento
0..1
Lotao
1..*
Empregado
Lotao (Data_Inicio)
42
Exemplo 3:
Empresa
Telefone
0..*
Tem
0..* 1 0..1 0..*
PossuiFormao Lotao
0..*
FormaoEscolar
Departamento
Funcionrio
0..1 0..*
1..*
PossuiCargo
0..1
Cargo
Gerencia
0..1
Gerente
Administrador
Notas: 1. Mesmo que uma classe tenha somente um objeto pode ser interessante cri-la para facilitar a manuteno futura no sistema. o caso da classe Empresa no DC anterior. 2. Sempre que verificar a ocorrncia de redundncia de dados em relao 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 ocorrncia de atributos multivalorados numa classe separe-os criando novas classes. caso da classe Telefone. Por qu? 4. Seria correto criar uma associao entre as classes Empresa e Funcionrio? Exemplo 4: Uma associao pode gerar uma nova classe. Esta classe ser chamada classe de associao: um elemento de modelagem UML com propriedades de associao e de classe. As classes de associao so representadas com um smbolo de classe anexado a uma associao por uma linha tracejada conforme mostra o
Cliente + Nome : char + Endereo : char + Telefone : char
0..1 0..*
ExemplarFita + DataAquisio : char + PreoPago : char
Compra + Data : char # PrecoCompra : double + Desconto : float ClienteTitular # Salrio : float ClienteDependente + Relaao : char # EmitirTotalVendasMes(Mes) : double + EmitirNotaFiscal # CalcularLucro(Mes) : double persistent
1
1..*
Tem
1
Fita + Titulo : char + DataLanamento : char + QuantidadeEstoque : int
Possui
0..*
43
exemplo: Notas: Gere classes associativas se existirem atributos /operaes a serem acrescentadas na classe. Observe que as associaes Possuem (entre Cliente Titular e Cliente Dependente) e Tem (entre Fita e ExemplarFita) no deram origem a novas classes associativas. Uma alternativa gerao de classes associativas para associaes 1:N seria colocar os atributos e operaes da associao na classe do lado N, semelhante ao modelo fsico de Banco de Dados relacionais. Embora possvel, esta tcnica no interessante em Orientao a Objetos, pois: a) A separao 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 espao 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 estratgia de gerar classes normalizadas (como em DERs).
Exemplo 5a: Faa uma anlise crtica do seguinte diagrama de classes.
Empregado
0..*
Possui
0..1
Sexo
Exemplo 5b: Faa uma anlise crtica do seguinte diagrama de classes.
Departamento
Lotao
1..*
Funcionrio
1..*
Possui
0..*
Escritrio
Trabalha_Em
44
Exemplo 5c: Faa uma anlise crtica do seguinte diagrama de classes.
Estado
Rua
0..1
mora
0..*
Cliente
1 0..*
0..* 1
Tem_Cidade
1
Tem_Rua
Cidade
Tem_Bairro
0..*
Bairro
Exemplo 6: Se a multiplicidade da associao for maior que 1 ela pode ser ordenada.
Cliente
Faz
{ordered} 0..*
Pedido
Isto significa que o conjunto de objetos do lado N se encontra em uma ordem explcita. O exemplo acima significa que os pedidos dos clientes esto ordenados segundo uma restrio pr-definida no dicionrio 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 participao total / total nos relacionamentos. Por que? Mesmo a participao parcial / total deve ser evitada. Use sempre o bom senso !!! Indique sempre classes associativas caso exista atributos e/ou operaes prprias da associao.
45
Associao N:N Indica que um objeto de uma classe pode estar associado a vrios objetos de uma outra classe e vice-versa. Exemplo 1: A cobertura de um exame um fato que deve ser armazenado no
Empresa Conveniada
0..*
Cobre
0..*
TipoDeExame
sistema? Exemplo 2: O elenco de um filme um fato que deve ser armazenado no sistema?
1..*
Filme
Possui
1..*
Ator
Elenco
Exemplo 3: A associao tem atributos e operaes adicionais?

Mdico + CRM : int + Nome : char + Endereo : char + Telefone : char
1..*
Paciente Consulta
0..*
+ Nome : char + Endereo : char + Telefone : double
Consulta + DataConsulta : char + PreoPago : double + Diagnstico : char MarcarConsulta RemarcarConsulta CancelarConsulta EncerrarConsulta
Exemplo 4a: Vrios para vrios ou duas vezes um para vrios?
Cliente
Faz
0..*
Pedido
0..*
Possui
1..*
Produto
ItemPedido + Quantidade : int + PreoPago : float
46
Exemplo 4b: Vrios para vrios ou duas vezes um para vrios?

Cliente
1
Faz
0..*
Pedido
1 1..*
ItemPedido + Quantidade : int + PreoPago : float
0..* 1
Produto
Associao Qualificada: Tipo de associao um para vrios ou vrios p/ vrios que permite, dado um objeto de uma extremidade da associao, identificar os objetos associados no outro lado da associao. Funciona como uma chave estrangeira usada p/ particionar o conjunto de objetos associados. O qualificador um atributo da associao e no aparece na classe qualificada. interessante que o atributo exista na regra de negcio no sendo um atributo artificial. Exemplo 5a: Sem a associao qualificada (N:N):
Conta + NumeroConta : int + DataAbertura : char + Tipo : char movimentada
0..*
0..*
TipoTransao + Descrio : char + Tarifa : float
TransaoConta + NumeroTransao : int + Data : char - Valor : float + Tipo : char
Exemplo 5b: Com a associao qualificada (N:N):

Conta + NumeroConta : int + DataAbertura : char + Tipo : char movimentada
0..*
0..1
TipoTransao + Descrio : char + Tarifa : float
NmeroTransao TransaoConta + Data : char - Valor : float + Tipo : char
Exemplo 6a: Sem a associao qualificada:

Cinema + Nome : char + Endereo : char + Telefone : char
1
Sala Possui + Capacidade : int

1..*
47
Exemplo 6b: com a associao qualificada:
Cinema + Nome : char + Endereo : char + Telefone : char

1
Sala Possui
1
+ Capacidade : int persistent
NumeroSala
Nota: Prefira no modelo a associao no qualificada, pois algumas linguagens OO no implementam associaes qualificadas. Histrico de Objetos: Em algumas situaes necessrio manter histricos das ocorrncias anteriores de objetos nas classes. Isto geralmente altera a multiplicidade das associaes. Exemplo 7:
0..*
Empregado
lotao
1..*
Departamento
HistricoLotao + DataInicio : char + DataFim : char
Pode-se separar os objetos da situao atual dos objetos que so histricos em classes diferentes: Exemplo 8a: Situao atual e Histricos so guardados na mesma classe.
Aluno
0..*
Matricula
0..*
TurmaDisciplina
0..*
Possui
0..*
Disciplina
HistricoMatricula + Semestre : double + Nota : float + Frequencia : int + SituaoFinal : char
48
Exemplo 8b: Situao atual e Histricos so separados em classes diferentes.

Aluno
0..*
Matricula
0..*
TurmaDisciplina
0..*
Possui
0..*
Disciplina
0..*
MatriculaAtual + Nota : float + Frequencia : int

0..*
Gera
0..1
HistricoEscolar + Semestre : char + NotaFinal : float + FreqnciaFinal : int + SituaoFinal : char
0..*
HistricoEscolar
Vantagens: O desempenho do sistema tende a ser melhor no caso b. Por qu? Notas: Lembre-se 1. O SGBDOO aceita associaes N:N, o que no ocorre com SGBDRs. 2. Nas classes associativas no deve ser identificados atributos que pertencem a outras classes, ou seja, o SGBDOO no utiliza o conceito de chaves estrangeiras dos SGBDRs. 3. Apenas uma classe de associao permitida por associao. Associao 1:1 Indica que um objeto de uma classe pode estar associado no mximo um objeto de uma outra classe e vice-versa. Exemplo 1: Exemplo 2a:
Quarto
0..1
Possui
0..1
Frigobar
Estado
governado
0..1
Governador
Professor
0..1
Coordena Curso
0..1
CoordenaoCurso + Data : char + Gratificao : float
49
Exemplo 2b:
Professor
CoordenaoCurso + Data : char + Gratificao : float
Coordenador
0..1
Curso Coordena
1
Vantagens: Reusabilidade melhor e o desempenho tende a ser melhor. Por qu? Exemplo 3:
Cargo Projeto
1
Possui
0..*
0..*
Empregado
0..*
Lotao Supervisiona
Disjuno Incompleta
0..1
0..*
TrabalhaEm
0..*
Engenheiro
Secretria
Administrador
Departamento
EmgenheiroProjeto
Sobreposio Incompleta Gerente
0..1
Supervisor Gerencia
Gerencia
0..1
Auto Associao: Indica que um objeto de uma classe pode estar associado a outro objeto da mesma classe. Exemplo 1:
0..*
0..1
Disciplina
Pr_Requisito
Funcionrio
Supervisiona
0..*
0..*
50
Exemplo 2:
0..1
Esposa Casamento
Casamento + DataCasamento : char + TipoCasamento : char
Pessoa
0..1
Marido
Alguns SGBDOOs no implementam auto associao, pois sempre possvel evitla num diagrama de classes.
Exemplo 3a: Com auto associao
0..*
Composio Composio + Quantidade : char
Produto
0..*
Exemplo 3b: Sem auto associao

Produto
Produto Composto
ProdutoComponente
0..*
0..*
Composio + Quantidade : char
51
Exemplo 4a: Com auto associao Me Pai

0..1 0..1
Pessoa Pai
0..* 0..*
Me
Filho Filho Exemplo 4b: Sem auto associao
Pessoa
PessoaPai
PessoaFilho
PessoaMe
0..1
Possui
0..*
0..*
Possui
0..1
Exerccio: Transforme os modelos dos exemplos 1 e 2 em modelos sem auto associao. Associao de grau superior a dois: Associao que envolve trs ou mais classes simultaneamente. Exemplo 1:
Pea
1 0..*
Fornecedor
1 0..*
Fornecimento
0..* 1
Projeto
Fornecimento + Data : char + Quantidade : int + Preo : float
52
Exemplo 2: Supondo que em uma cidade um produto tenha um representante exclusivo:
Produto
1 0..*
Cidade
0..*
0..1
Distribuio
Distribuidor
Distribuio + Data : char + Quantidade : int
Nota: Uma associao ternria no equivalente a trs associaes binrias. 2.2 Agregao Forma especial de associao 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:
Livro
1
Possui
0..*
ExemplarLivro
Empresa
1
Tem
0..*
Departamento
Exemplo 2:
53
Pedido
1
Tem
1..*
ItemPedido
0..*
Possui
1
Produto
Exemplo 3: Classes fracas devem ser modeladas como agregao
Aluno
1
Paga
0..*
BoletaAluno
Cinema
1
Possui
0..*
SalaCinema
Disciplina
1
Tem
0..*
TurmaDisciplina
Funcionrio
1
Recebe
0..*
ContraCheque
54
Exemplo 4: Agregao compartilhada (N:N)
Time
0..*
composto
1..*
Pessoa
Exemplo 5:
Scio
ScioTitular
1
ScioDependente Tem
0..*
Notas: Somente um lado, no mximo, de uma associao pode ser agregao. Se o objeto da classe "Todo" for destrudo os objetos da classe "Parte" tambm sero destrudos. Alguns autores denominam este fato de "agregao por composio" e a representam atravs de um losango escuro. Como diferenciar Agregao de Associao? Dois objetos esto estreitamente ligados por uma associao "Parte-Todo" ou " composto de": Agregao. Dois objetos esto ligados, mas usualmente so considerados independentes: Associao. Exemplo 6:
0..1
Escola
1 0..*
Tem
0..*
Departamento
1..*
Chefiado
1..*
Est Vinculado
Possui
0..* 0..* 0..*
Administra
0..* 0..* 0..1
Aluno
Frequenta
0..*
Curso
Ministra
1..*
Instrutor
HistricoEscolar
55
Parte II Apostila de APS II

Diagrama de Objetos Um diagrama de objetos consiste em uma instncia do diagrama de classe, no qual cada classe temos um objeto ( sua instncia) 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 difcil e no muito claro. O diagrama de objetos vem com o objetivo de simularmos uma situao de funcionamento do sistema em um dado instante. Vantagens teis para facilitar a modelagem de estrutura de dados Identificar problemas na execuo de uma aplicao Durante o Debugging podemos visualizar os objetos que esto sendo manipulados e seus relacionamentos. Representao Grfica um objeto similar a classe. Consiste em um retngulo 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 possvel omitir o nome do objeto, preservando dois pontos, representando um objeto annimo ou omitir o nome da classe. Em qualquer um dos casos, mantm-se sublinhado. Exemplos : :coordenada / CoordenadaFigura1 :Funcionrio Funcionrio1
Func1:Funcionrio
Quando os atributos so exibidos: Caneta:Produto Cor = Azul Preo = R$ 2,00
56
Atributos no relevantes ao sistema podem ser omitidos. possvel tambm representar atributos cujos valores mudam durante um processamento. Nesse caso, representa-se essa mudana por meio de uma lista. Os links so os responsveis pela ligao entre os objetos. Os links podem conter adornos tais como: Nome do papel = final de cada linha pode ser exibida Nome da associao = exibido prximo a linha Qualificadores = terminao dos links Exemplos dos adornos: a) Qualificadores um atributo ou lista de atributos, presentes em uma associao, cujos valores servem para particionar o conjunto de instanciais associadas com outra instncia do lado qualificado. Num relacionamento entre nota fiscal e itens da nota fiscal, sabemos que para determinada nota no podemos ter a repetio de produtos, ou seja, cada produto s pode aparecer uma nica vez nos itens da nota fiscal. Com isso qualificamos com o atributo produto. NotaFiscal
Produto
ItemNotaFiscal
b) Nome da associao Geralmente utilizada prxima a linha para facilitar o entendimento da associao, no aconselhvel seu uso em situaes explcitas. Aluno Disciplina
Cursa
c) Nome do Papel Geralmente para explicar o papel de uma classe, quando a mesma pode exercer vrios papis em uma mesma classe. Na maioria das vezes a classe por si s j explica seu papel. Funcionrio Gerente Setor Departamento
57
Diagrama de Interao
Diagramas de interao, um nome genrico que se aplica a vrios tipos de diagramas que enfatizam a interaes dos objetos.Esses diagramas devem ser utilizados quando se deseja visualizar o comportamento de vrios objetos dentro de um nico caso de uso, a partir das mensagens que so passadas entre eles. Diagramas de interao so apresentadas sob duas formas na UML : Diagrama de Seqncia Diagrama de Colaborao
Desenvolvedores diferentes tm preferncias prprias ao escolher o tipo de diagrama de interao a ser utilizado. Alguns podem preferir o diagrama de seqncia, outros o diagrama de colaborao. O diagrama de seqncia permite dar maior nfase aos quesitos de seqncia tornando fcil visualizao da ordem na qual as coisas acontecem. O importante que qualquer um dos dois diagramas adotados, o que importa sua simplicidade, permitindo uma fcil visualizao. Diagrama de Seqncia Foram encontrados em vrios mtodos de orientao a objetos, diagramas de seqncia sob variados nomes. Notao : Objeto desenhado no topo como um retngulo 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 tambm pode incluir argumentos e informaes de controle. Se um objeto excludo ento utilizamos um X A dimenso vertical representa o tempo e a dimenso horizontal representa objetos diferentes Uma condio indicada dividindo uma seta de mensagem em dois objetivos paralelos Autodelegao ocorre atravs de chamada recursiva
58
Diagrama de Colaborao
Ao contrrio de um diagrama de seqncia, um diagrama de colaborao mostra os relacionamentos entre os objetos, mas no trata o tempo como uma dimenso separada. Dentro de um diagrama de colaborao, os objetos so desenhados como cones, e como nos diagramas de seqncia, setas indicam as mensagens enviadas aos objetos para realizar um caso de uso. Notao cones Setas Uma condicional indicada com uma condio de guarda entre colchetes, ou seja, exibe uma condio que deve ser satisfeita para causar o disparo de uma transio associada.
Diagrama de Estado
A existncia de estado de um objeto implica que a ordem na qual as operaes so executadas importante, o que leva a idia de objetos como mquinas independentes. Uma das desvantagens deste diagrama refere-se a sistema de maior complexidade j que este diagrama visa definir todos os possveis estados de um sistema. A UML prope o emprego deste diagrama de maneira individualizada para cada classe ( o que tambm vale para classes estereotipadas de interface do usurio), com o objetivo de tornar o estudo simples, o bastante para se ter um diagrama de estado compreensvel. Modelos de estado so ideais para descrever os comportamentos de um nico objeto, mas no para descrever adequadamente o comportamento que envolve vrios objetos, neste caso o melhor utilizar um diagrama de interao ou um diagrama de atividade.
59
Diagrama de Atividade
o diagrama menos conhecido, sendo utilizado para diferentes propsitos, incluindo: Capturar o funcionamento interno de um objeto Capturar as aes que sero desempenhadas quando uma operao executada Mostrar como um processo de negcio funciona em termos de atores, fluxo de trabalho, organizao e objetos. Mostrar como uma instncia de caso de uso pode ser realizada em termos de aes e mudanas de estado de objetos. Mostrar como um conjunto de aes 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 tcnica para a modelagem de fluxo de trabalho e programao para multiprocessamento. O uso do diagrama de atividade indicado nos seguintes casos: Anlise de caso de uso Nesse caso no h interesse em designar aes aos objetos. H somente a necessidade de se compreender quais aes precisam ser realizadas e quais so as dependncias comportamentais. Compreenso de fluxo de trabalho entre vrios casos de uso Quando casos de uso interagem entre si. No devemos utilizar os diagramas de atividade quando : Colaborao de Objetos
Um diagrama de interao mais simples e prov uma viso mais clara de colaboraes 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 so aes ou subatividades nos estados de origem. Este diagrama tem como propsito focalizar um fluxo de atividades que ocorrem internamente em um processamento, dentro de um perodo de tempo.
60
Modelando Diagramas de Atividades Exemplificando temos a situao mais comum a nossa sada de casa para o local de trabalho. Poderamos 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 prximo do trabalho Se for metr devemos ir at a estao Comprar um bilhete Pegar a composio Descer na estaca mais prxima 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 t e
n ib u s
I r p a r a p o n to d e n ib u s
M e tr
Ir p a r a e s t a o
P egar C ondu o
C o m p r a r B ilh e t e
P ag ar P assa gem
P e g a r C o m p o s i o
D e s c e r P r x im o
61
Podemos ter ainda um processamento em paralelo, conforme exemplo abaixo: Diagrama de atividades liberao de mercadoria
Preparando liberao de produto
Separando Produto em estoque
Verificando Programa de entrega do caminho
Atrasados
Remanejar Entrega
Sem atraso
Embalar Produto Emitir Liberao entrega
Emitir Nota Fiscal
62
Estado de Ao Um estado de ao um tipo simplificado de um estado de uma mquina de estados. Estados de ao no devem ter transies internas. Para estas situaes, utilize os estados normais. As transies entre atividades so implicitamente disparadas pela execuo de uma ao em um estado. As Transies podem incluir condies de guarda e aes. Um uso comum de estado de ao a modelagem de um passo especfico da execuo de um processo de workflow. Um estado de ao mostrado graficamente como uma figura retangular com as laterais arredondadas e com a expresso ao dentro da figura.
Remanejar Entrega Obter Autorizao
Estado de subatividade
Um estado de subatividade indica que quando este inciado, o grfico de atividade aninhado a ele executado como um grfico de atividade independente. O estado de subatividade no finalizado at que o estado final do grfico aninhado seja alcanado, ou quando eventos disparadores ocorrerem em transies vindas de fora do estado de subatividade.
Transies
Mostra o fluxo de um estado de ao para outro. representado graficamente por uma seta que vai de um estado ou subatividade para outro estado ou subatividade.
Decises
Uma deciso ocorre em um diagrama de atividades quando condies de guarda so utilizadas para indicar diferentes transies mutuamente exclusivas, que dependem de condies booleanas do objeto proprietrio. A representao grfica um losango. A mesma representao pode ser utilizada para finalizar uma deciso, neste caso chamada de merge(intercalao).
Bifurcao ou unio.
Fazemos o uso de bifurcao ( Fork ) e Unio ( Join ) principalmente em fluxos concorrentes, no intuito de criar uma ligao entre os diversos fluxos. A bifurcao separa uma transio de entrada em vrias transies concorrentes, sendo que estas so disparadas ao mesmo tempo. A Unio concatena transies concorrentes em uma transio simples.
63
Raias ( SwinLanes )
Aes e subatividades podem ser organizadas dentro de raias, que so usadas para agrupar responsabilidades para aes ou subatividades. Um diagrama pode ser dividido em diversas raias, cada qual separada de sua vizinha por uma linha slida vertical de ambos os lados. Cada ao determinada por uma raia. Transies podem atravessar as zonas das raias.
Vendedor Cliente
Solicitao de Compra
Efetuar pagamento
Lanar Venda
Liberar Mercadoria
Exemplo de diagrama de atividades utilizando raias.
64
DIAGRAMAS DE IMPLEMENTAO
Assim como o diagrama de interao, o diagrama de implementao formado basicamente por dois tipos de diagramas : Diagrama de Componentes Diagrama de Implantao O Diagrama de componentes mostra a estrutura dos componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam. O Diagrama de Implantao mostra a estrutura de ns nos quais os componentes representam a organizao de unidades e recursos ( humanos e outros ) do negcio. Esses diagramas tambm podem ser aplicados na modelagem de negcios, no qual os componentes representam artefatos e procedimentos de negcios e os ns de implantao representam a organizao de unidades e recursos. Diagrama de Componentes Um diagrama de componentes mostra as dependncias entre componentes de software, incluindo classificadores que eles especificam ( isto classes de implementao ) e os artefatos que eles implementam ( isto arquivos de cdigos fonte, arquivos de cdigo binrio, arquivos executveis, scripts, etc...). Um diagrama de componentes representa um tipo e no a instncia. Para mostrar a instncia de componentes utilize um diagrama de implantao. O diagrama de componentes conectado atravs de setas pontilhadas. Um diagrama de componentes pode ser usado para mostrar dependncias estticas. Um componente corresponde s interfaces que ele expe, interfaces que representam servios providos pelos elementos que residem no componente. Um componente pode ser implementado por um ou mais artefatos, tais como arquivos, arquivos executveis,script, etc... Notao Grfica :
Pedidos.exe
65
Diagrama de Implantao Diagramas de implantao mostram a configurao dos elementos de processamento em tempos de execuo e os componentes de software. Um diagrama de implantao um grfico de ns que conectados por associaes de comunicao.
N um objeto Fsico que representa um recurso de processamento, freqentemente possuindo capacidade de processamento.
66

Apostila Análise e Projeto Orientados Por Objetos - UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Análise e Projeto Orientados Por Objetos - UML

Enviado por

Direitos autorais:

Formatos disponíveis

FABRAI FACULDADE BRASILEIRA DE INFORMTICA

CURSO DE TECNOLOGIA EM PROCESSAMENTO DE DADOS

ANLISE E PROJETO DE SISTEMAS II

Prof. Rodrigo de Matos Vargas

Proibida reproduo desta apostila por quaisquer meio

@Copyright 2003 By Rodrigo de Matos Vargas

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Desenvolvedor Idia Sistema de Software Habilidade

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

7- Controle Qualidade Figura 02 Ciclo de Vida

8- Converso do Banco de Dados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Nesta Disciplina estudaremos a atividade de Anlise de Sistemas

Rotinas do Usurio Restries 2. Anlise

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Abordagem Top Down Foco em Processos

Coletnea de Objetos que interagem entre si.

Figura 04 Quadro Comparativo

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Base de Dados Objeto / Relacional

Elementos da UML Ao Atributo Constante (Imutvel) Atributo de Classe Atributo de Objeto

Java Declaraes Final Esttico Varivel de Classe esttico Varivel de Instncia

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

CAPTULO II CONCEITOS BSICOS

Conceitos Bsicos da Programao Orientada a Objetos

GOX 3444 GOL 1243 Exemplo : Classe x Objeto

Maria, Caixa Pedro, Gerente

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

S ald o (C o rren tista)

S ald o fu n d o Balan cead o

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Estado Evento Generalizao

Solicitao entre os objetos Sinnimo de Instncia de Classe

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

CAPTULO III MODELAGEM ATRAVS DA UML

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Exemplos de Navegao entre os diagramas UML Comportamento Externo Casos de Uso

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Notao UML: Diagrama de Caso de Uso

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Caixa <<actor>> Caixa

Iniciar uso Caixa

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Iniciar uso Caixa

<<uses>> Fechar Caixa <<uses>> Validar Senha

imprimir para arquivo

Comprar Produtos com Carto

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

<<extends>> Comprar Produtos

Iniciar uso Caixa Gerente Validar Senha <<uses>> Encerrar Caixa

Professor : Rodrigo de Matos Vargas Todos os direitos reservados

Professor : Rodrigo de Matos Vargas Todos os direitos reservados