Uml   Diagramas estruturais - parte escrita
Upcoming SlideShare
Loading in...5
×
 

Uml Diagramas estruturais - parte escrita

on

  • 3,799 views

Conteúdo teórico sobre Diagramas estruturais.

Conteúdo teórico sobre Diagramas estruturais.

Statistics

Views

Total Views
3,799
Views on SlideShare
3,798
Embed Views
1

Actions

Likes
3
Downloads
107
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Uml   Diagramas estruturais - parte escrita Uml Diagramas estruturais - parte escrita Document Transcript

  • UNIVERSIDADE FEDERAL DE OURO PRETO INSTITUTO DE CIÊNCIAS EXATAS E APLICADAS DEPARTAMENTO DE CIÊNCIAS EXATAS E APLICADAS ENGENHARIA DE SOFTWARE II UML , Diagramas estruturaisJéssica Pires – 09.1.8068, Priscila de Ávila - 09.1.8050, Rafaela Priscila - 09.1.8080, Thaise Delfino - 09.2.8115
  • SumárioIntrodução ................................................................................................................................ 2História do UML ........................................................................................................................ 3Diagramas Estruturais ............................................................................................................... 4Diagrama de Classes ................................................................................................................. 5Diagrama de objetos ................................................................................................................. 8Diagramas de Pacotes ............................................................................................................. 11Diagrama de Estrutura Composta............................................................................................ 12Diagrama de Componentes ..................................................................................................... 13Diagramas de Implantação ...................................................................................................... 16Diferenças entre os Diagramas ................................................................................................ 17Aplicação ................................................................................................................................ 18Conclusões.............................................................................................................................. 19Referências Bibliográficas ....................................................................................................... 20 1
  • Introdução Modelagem nada mais é do que uma representação do software a ser feito sobreimagens e aspectos que facilite o usuário a enxergar o que deve ser feito em seu trabalho.Geralmente são feito diagramas e existem inúmeras ferramentas no mercado para ajudar aelaborar esses diagramas. A UML (Unified Modeling Language) é uma linguagem para fazerexatamente isso: modelagem de software. A UML é uma linguagem na qual se obtém a especificação desejada, a documentaçãocorreta e uma fácil visualização do projeto para um sistema orientado a objetos. Através deseus diversos diagramas podemos obter diferentes perspectivas de visualização. Facilita nacomunicação entre as pessoas envolvidas com o sistema, como gerentes, coordenadores,analistas e desenvolvedores, pois apresenta uma forma fácil de entender o problema como umtodo. 2
  • História do UML No início da utilização de programas orientados à objetos, vários foram os métodos demodelagem que surgiram, porém apenas três deles se destacaram por não estender osmétodos estruturados já existentes, erro cometido pelos demais. Cada método possuía pontosfontes e diferentes entre si, um deles era focado em casos de uso (OOSE de Ivar Jacobson),outro focava na fase de projeto (Booch’93 de Grady Booch) e o terceiro era voltado paraanálise de sistemas de informação (OMT-2 de James Rumbaugh). Em outubro de 1994 começaram os projetos para a junção destes três métodos. Em1995, dois deles já eram unificados (Booch’93 e o OMT-2), um tempo depois, OOSE passou afazer parte desse conjunto, formando assim o “método unificado”. Em julho de 1996, os três criadores do “método unificado” lançaram uma versão dessenovo método com a união dos outros três já existentes. A versão foi batizada de UML e maistarde lançaram várias outras novas versões. A OMG3 (organização internacional que aprova padrões abertos para aplicaçõesorientadas a objetos) contribuiu imensamente para o crescimento da UML, pois ela lançouuma solicitação de proposta para que outras empresas também pudessem contribuir com ocrescimento do UML, depois disso ela chegou a sua versão 1.1 e a OMG3 passou a seresponsabilizar pelas revisões e a adotou como linguagem padrão. As revisões são feitas com ocuidado de não modificar a ideia principal do projeto e isso acaba sendo um motivo paradisseminar a linguagem para o mundo inteiro.A linguagem UML chegou a sua versão 2 em 2003. Essa versão é composta por trezediagramas, esses diagramas são divididos em diagramas de comportamento e diagramasestruturais, da qual iremos tratar no restante do nosso trabalho. 3
  • Diagramas Estruturais Os diagramas estruturais são aspectos estáticos, ou seja, representação da estruturade um sistema. Eles são classificados em diagramas de classe, objetos, de pacotes, de estruturacomposta, de componentes e de implementação. DIAGRAMAS ESTRUTURAIS DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE ESTRUTURA CLASSES OBJETOS PACOTES COMPONENTES IMPLEMENTAÇÃO COMPOSTA 4
  • Diagrama de Classes O diagrama de classes é o diagrama principal do modelo estrutural, ele é o diagramaque chega mais perto do código do programa, onde é fácil visualizar as classes, seus métodos,atributos e os relacionamentos, de acordo com a especificação do sistema podemos fazer umamodelagem utilizando esses dados. Precisamos, antes de tudo, saber o que é uma linguagem com orientação a objetos.Basicamente é abstração de conceitos do mundo real. Para compreendermos melhor,podemos citar o exemplo de uma locadora de filmes, temos que pensar em dividir esseproblema em objetos. Neste exemplo temos os seguintes objetos: CD’s e Fitas, Clientes, etc. Amelhor forma de conceituar é imaginar objetos do mundo real e tentar abstrair essesconceitos. Um exemplo real: Meu cachorro Thor. Posso descrever seus atributos físicos: é grande, sua cor principalé castanha, olhos pretos, orelhas grandes e caídas, rabo grande. Além de seus atributos físicos,posso descrever algumas ações que ele costuma fazer: balança o rabo quando chego em casa,late quando ouve um barulho estranho, trás a bola pra mim quando quer brincar. Temos baixoa representação do Thor.Temos então a representação de um objeto (Thor) que possui determinadaspropriedades e métodos: Propriedades: Cor do corpo: castanha, Cor dos olhos: preto, Altura: 30 cm Comprimento: 80 cm, Largura: 24 cm. Métodos: Balançar o rabo, Brincar, Latir, Deitar. Para tratar objetos, temos as classes. Então temos uma classe: Cachorro, onde euposso representar o Thor. Podemos pensar em classe como um modelo para criar várias outrosobjetos. Funciona como um carimbo, temos o carimbo e com ele podemos fazer quantascópias do mesmo modelo quisermos. A representação gráfica de uma classe é feita em um triangulo com três divisões: nomeda classe, atributos e métodos. 5
  • Atributos: Um atributo especifica características gerais para um objeto. Mas cadaobjeto pode receber valores diferentes em cada atributo. Então, no exemplo do cachorro Thor,temos que os atributos dele são aqueles descrito acima, mas podemos criar um outro objetocachorro com outras propriedades, ou seja, outros atributos. Podemos representar avisibilidade dos atributos utilizando as seguintes marcações:  + público - visível em qualquer classe  # protegido - qualquer descendente pode usar  - privado - visível somente dentro da classe Métodos: são ações que representam um determinado objeto. Como no exemploanterior, temos que o meu cachorro, Thor, pode latir, sentar, comer, etc. Os objetos possuem relações entre si, uma classe pode se relacionar com outra. OUML reconhece três importantes tipos de relação: dependência, associação e generalização(ou herança). As relações são esquematizadas da seguinte forma. Associação: São relacionamentos entre instâncias, indica que objetos de duas classesdiferentes podem estar relacionados. Por exemplo, uma classe professor e uma classedisciplina, onde uma instância da classe professor terá uma associação com uma instância daclasse disciplina. Dependência: Relacionamentos em que um elemento de uma classe depende de umelemento de outra classe, logo, se houver alteração em um elemento o outro também sealterará. Generalização: Relacionamento entre elementos generalistas e especialistas, na qual aclasse especialista herda da outra propriedades e métodos gerais. Agregação Regular: É a associação onde o objeto parte é um atributo do todo. Osobjetos parte são criados apenas quando o todo ao qual está agregado também é criado. Umexemplo prático seria uma classe Pedido e uma classe Item. O pedido só pode ser feito quandoos itens do pedido estão disponíveis. 6
  • Composição – Relacionamento onde existe um elemento como o todo e um como aparte do todo. A parte do todo só pertence ao todo e são criadas e destruídas nele. O diagrama de classes é consequência de um levantamento de requisitos feitospreviamente. Como exemplo podemos fazer o levantamento de requisitos para um sistema deconsultório dentário. As etapas são:  Levantamento e análise de requisitos do sistema a ser desenvolvido. Entrevista com o cliente, no caso o proprietário de uma clinica, um dentista, ou mesmo funcionários que saibam dar as informações de maneira clara e especifica.  Definição dos objetos do sistema: Paciente, agenda, dentista, serviço, contrato, consulta, pagamento, etc..  Definição e detalhamento das ações: marcar consulta confirmar consulta cadastrar paciente, cadastrar serviços, etc.  Definição das classes: paciente, dentista, exame, agenda, serviço.  Definir os atributos e métodos das classes. Após toda esta análise, podemos construir o diagrama que represente esse problema. Neste exemplo, temos as classes paciente, Agenda, serviço, consulta, horário,limpeza/Restauração e Exame. Cada classe possui seus atributos e métodos e cada uma possuiuma relação com outras classes. 7
  • Diagrama de objetos O Diagrama de Objetos é uma variação do Diagrama de Classes, e é muito poucoutilizado. Eles são usados, também, como parte dos diagramas de comunicação, onde osobjetos do sistema possuem um vínculo. Nessa variação do diagrama, podem ser atribuídosnomes reais aos objetos. Os diagramas de Objetos não são tão importantes como osdiagramas de classes, mas são muito úteis para simplificar diagramas de classes maiscomplexos e de difícil entendimento, ajudando muito em sua compreensão. Existem apenas duas diferenças entre a notação desse diagrama com o diagrama declasses:  Os objetos são escritos com seus nomes sublinhados  Todas as instâncias num relacionamento são mostradas. Com esse diagrama, temos o perfil do sistema em um certo momento de sua execução,tendo a possibilidade, assim, de conferir se os dados estão atribuídos corretamente e se sãoconsistentes. Os diagramas de objetos têm seu nome sublinhado e todos os seusrelacionamentos são mostrados. Seus nomes vêm separados das classes que ele representapor “:” (dois pontos). Nesse Diagrama, os atributos já podem se receber seus respectivosvalores. Por exemplo, o cachorro que se chama Thor, você pode definir um objeto “Thor” erepresentar ele aqui.Por exemplo, Thor:Cachorro Thor:Cachorro Os diagramas de objetos são importantes para visualizar, especificar e documentar osmodelos estruturais, assim como aspectos dentro de um sistema. Exemplo de um diagrama: Thor:Cachorro +cor: Castanho: string Jessica:Dona +peso: 37: int +cpf:12345678901:int +numCarteirinha:2345: int latir() comer() correr() 8
  • O diagrama pode ser lido da seguinte maneira: O objeto Jéssica da classe Dona está associado ao objeto Thor da classe Cachorro. Podemos com os diagramas, projetar um jogo por exemplo. Onde o jogador está preso em uma casa de tortura e ele deve tentar sair de lá. O jogo tem as seguintes regras (não nos preocuparemos com objetos no jogo, somente com o projeto da cena):  A casa onde o jogador está possui dois quartos espelhados;  Cada quarto reconhece quatro elementos da casa (uma porta, uma parede, ou outro quarto);  Se o jogador entra em um quarto, sua localização é alterada;  Se ele entra em uma porta e a porta estiver o Aberta: o jogador muda de quarto; o Fechada: o jogador se machuca;  Se o jogador se depara com a parede, se machuca. Criando o diagrama de classes para esse jogo, temos: <<interface>> ElementoDoJogo 4 elementos Joga() 1Porta Quarto Parede CasaEspelhadaestaAberta:boolean +QuartoNumeroQuartoUM:Elemento n 1DeCasaEsp() Entra() Entra()Entra() getQuartoViz() getQuartoViz() adicionaQuarto()QuartoEspDoOutroLa getQuarto(int):Quartodo(:QuartoEsp) A classe Quarto herda elementos da classe CasaEspelhada, e a Interface herda os elementos de Parede . Porta tem uma relação de associação com Quarto, o que quer dizer que os atributos de quarto e de porta se relacionam (Por exemplo, cada quarto possui uma porta). Vários quartos dependem da existência de uma casaEspelhada e os elementos do jogo dependem da existência de um quarto. Podemos simplificar a visualização desse diagrama, criando o Diagrama de Objetos para esse mesmo problema: 9
  •  Escolhemos o cenário que desejamos representar (casos de uso);  Identificamos as classes (diagrama de classes);  Defina os relacionamentos entre os objetos (tipos de relacionamento); nJogo:JogosMortais nArea:CasaEspelhada + QuartoUM:Quarto QuartoDOIS:Quarto + + + + aPorta:Porta + :Parede :Parede :Parede :Parede :Parede+ + + + + O diagrama de objetos traz uma visualização muito mais sucinta do que será o projeto: A casa espelhada possui dois quartos, e esses quartos devem reconhecer paredes, portas ou outro quarto. E, por ultimo, devemos:  Definir os nomes e valores para os atributos dos objetos; 10
  • Diagramas de Pacotes O diagrama de pacotes mostra as relações entre diferentes pacotes e dependênciasentre suas classes. Os pacotes e dependências são importantes para fazer testes de sistema e visamorganizar o modelo de sistema UML. Com isso os desenvolvedores conseguem ver asdependências do sistema em larga escala e minimizar impactos nas modificações.Loja O exemplo abaixo ilustra um diagrama de pacotes de uma loja qualquer onde cadapacote é composto por um conjunto de classes. As setas representam a dependência entre osmesmos. Clientes Serviços Produtos 11
  • Diagrama de Estrutura Composta O Diagrama de estrutura composta mostra a estrutura interna de uma classe, ou seja,como seus objetos estão interligados, com um objetivo comum. O diferencial desse diagrama éque ele expressa tempo de execução, padrões de uso e o relacionamento entre os objetos.Porém ele não é muito utilizado na prática, pois sua estrutura é bastante complexa. A figura abaixo ilustra um exemplo de diagrama de estrutura composta, onde, porexemplo, um usuário que imprimir um documento através de um programa de computador evai utilizar a impressora. Computador Programa Impressora Neste outro exemplo, o objetivo é chegar a um diagnóstico do paciente, para issoprecisa de uma colaboração do médico com o paciente em uma consulta. Médico Consulta Paciente Diagnóstico 12
  • Diagrama de Componentes O Diagrama de componentes da UML mostra como as classes deverão se encontrarorganizadas através da noção de componentes. O diagrama tem por objetivo apresentar adisposição dos componentes físicos de um sistema, como interfaces e suas relações,mostrando os elementos reutilizáveis de software e sua interdependência. Um componentepode ser um pedaço de software retulizável, bem encapsulado e facilmente substituido. O principal objetivo deste diagrama é possibilitar a construção de artefatos para operfil de arquitetura da solução, seja para a arquitetura técnica ou a de negócios. Umcomponente é formado por um conjunto de classes que se encontram nele implementadas. O componente em si pode ser um código em linguagem de programação como umcódigo executável já compilado. Por exemplo, em um sistema desenvolvido em Java, cadaarquivo .java ou .class é um componente do sistema. Exemplo de componente: Cliente.java Graficos.dll Um componente é mostrado em UML como um retângulo com uma elipse e doisretângulos menores do seu lado esquerdo. Na figura abaixo segue uma forma derepresentação mais antiga de componentes, temos o exemplo anterior e a seguinte forma: Widget No diagrama de componentes também é possível mostrar a configuração de umsistema de software mostrando, graficamente, a dependência entre os diversos arquivos quecompõem o sistema, ou seja, um componente, assim como as classes que ele possui,dependem funcionalmente das classes de outro componente. 13
  • Gerenciador Gerenciador de Graficos de Banco de Comunicação dados Graficos.dll Comm.dll DB.dll Aplicação App.exe No exemplo acima, a dependência entre componentes pode ser mostrada como umalinha tracejada com uma seta, simbolizando que um componente precisa do outro parapossuir uma definição completa. Nota-se facilmente que arquivos .dll são necessários paraexecutar a aplicação. Em outro tipo de notação, o diagrama é composto normalmente por componentes,interfaces e portas. Os componentes são representados pelo estereótipo da uml <> . Interfacessão representadas através de uma linha com um círculo ou semicírculo ligado ao componente.Portas são representados através de retângulos saindo dos componentes. Segundo MACORATTI, a UML reconhece cinco estereótipos de componentes:  Um executável: Um componente que pode ser executado (um programa).  Uma biblioteca: Uma biblioteca de classes ou funções, dinâmica ou estática.  Uma tabela: Uma tabela de um banco de dados.  Um documento: Uma parte da documentação (texto livre, diagramas, documentos de ajuda, etc.)  Um arquivo: Outros arquivos, geralmente, se trata de um arquivo de código fonte, mas pode ser também um arquivo de dados, um ``script ou outros arquivos. Exemplo de um diagrama de componente exibindo os componentes para um sistema delocadora na web : 14
  • <<HTML>> <<Aplication>> Interface GerenteDeBusca.java Cliente.html <<HTML>> <<HTML>> InterfaceEstatica InterfaceDinamica .html .html <<dataBase>> BancoDeVideos.mdb <<Aplication>> MontaApplet <<HTML>> InterfaceExibida .html <<Aplication>> Servidor.java <<Applet>> <<Aplication>> Cliente.java TransmissorAV.java Neste exemplo, utiliza-se << >> para falar o que é utilizado para implementar ocomponente e, o nome do componente. Estas duas informações vão dentro de um retângulo.Normalmente é utilizado para:  Modelar os componentes do código-fonte, do código executável do software.  Destacar a função de cada módulo para facilitar a sua reutilização.  Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos. 15
  • Diagramas de Implantação Um diagrama de implantação, também chamado de digrama de utilização, modela orelacionamento entre recursos de infraestrutura, de rede ou artefatos de sistemas. Estediagrama é normalmente utilizado em projetos onde há muita interdependência entre partesde hardware e software. Cada nó deste diagrama é uma unidade física que representa umrecurso computacional, como processadores, dispositivos, roteadores ou qualquerequipamento de importância para o sistema de software.  Modela o mundo físico do sistema, considerando: o Computadores o Dispositivos e o Suas interconexões FAX Terminal 1 Impressora Matricial Servidor Terminal 2 Impressora Laser 16
  • Diferenças entre os Diagramas O diagrama de classes é o diagrama principal do modelo estrutural, ele é o diagramaque chega mais perto do código do programa, onde é fácil visualizar as classes, seus métodos,atributos e os relacionamentos, de acordo com a especificação do sistema podemos fazer umamodelagem utilizando esses dados. Os diagramas de Objetos são muito parecidos com os Diagramas de Classes, e sãousados, mormente, para exemplificar Diagramas de Classes mais complexos. Nos Diagramas deObjetos, seus objetos recebem nomes reais e é muito mais fácil compreender as relaçõesentre eles. Já os Diagramas de Pacotes, devem mostrar as relações entre pacotes e pacotes, ouseja, a relação entre um grupo de classes ou outro grupo de classes através de uma relação dedependência. O principal objetivo do Diagrama de Estrutura Composta é mostrar a estrutura internade uma classe, a interligação de seus objetos. Os Diagramas de Componentes apresentam a disposição dos componentes físicos deum sistema, como interfaces e suas relações. Os Diagramas de Implantação são utilizados, na maioria das vezes em projetos onde hámuita interdependência entre partes de hardware e software. Este diagrama modela orelacionamento entre recursos de infraestrutura, de rede ou artefatos de sistemas. 17
  • AplicaçãoUtilização da ferramenta case StarUML.StarUML é uma plataforma de modelagem de software que suporta UML. Com ela você podemodelar diagramas e ter uma melhor visualização dos mesmos. Agência +Número: int +Nome: string +Endereço: string +abrirconta(cliente: Cliente, tipo: string): Conta +obterCliente(id; int): Cliente +autenticar(cliente: int, conta: int, senha: int): void 1 0..n ContaBancária +Titular: Cliente +Número: int +Dígito: int +Saldo: float +deposito(valor: float): void +saque(valor: float): void 0..n 1..n Cliente +Código: int +CPF +Nome: string +Endereço: string +obterConta(numero: int): void 18
  • Conclusões A UML é uma ferramenta adequada para poder visualizar características decomportamento de um software ou sistema, por isso é considerada uma das linguagens maisexpressivas no quesito modelagem. Muitas técnicas avançadas de modelagem podem ser definidas usando UML comobase, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna. Aferramenta integrou muitas idéias adversas, e esta integração acelera o uso dodesenvolvimento de softwares orientados a objetos. Mostra uma relação de dependênciaentre os diagramas que a compõe (Pacote, componente, implantação, etc.), seja demodelagem ou infraestrutura física do sistema. Os diagramas UML permite em si que a construção de um sistema possa ser eficiente,justamente por permitir uma detalhada análise de requisitos principalmente para linguagensorientadas a objeto, além de facilitar a comunicação entre todas as pessoas envolvidas noprocesso. A UML é método satisfatório para construção de sistema. 19
  • Referências BibliográficasPrincipais:http://staruml.sourceforge.netSILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florian ́ polis: Visual Books, 2007.VARGAS, Thânia Clair de Souza. A história de UML e seus diagramas .BOOCH, G.; RUMBAUGH,J.; JACOBSON,I. UML Guia do Usuário.2.ed. Rio de Janeiro:Elsevier,2006.PFLEEGER, S.L.Engenharia de Software - Teoria e Prática. 2.ed. São Paulo: Prentice Hall,2004.CRAIG, L. Utilizando UML e padrões - Uma introdução à análise e ao projeto orientados aobjetos e ao desenvolvimento iterativo.BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. – Rio de Janeiro :Elsevier, 2003.PENDER, Tom. UML A Bíblia – Rio de Janeiro:Elsevier, 2004.BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML Guia do Usuário. – Rio de Janeiro :Elsevier, 2006.MARTIN, James.; ODELL, James. Análise e Projeto Orientados a Objeto. 639 p. – São Paulo:Makron Books, 1995.Relevantes:http://www.lavailama.com.brhttp://pt.wikipedia.orghttp://www.cassao.eti.brhttp://irup.rsuzano.comhttp://www.novatec.com.brhttp://pt.wikipedia.org/wiki/Diagrama_de_objetoshttp://techblog.desenvolvedores.net/2011/05/28/diagrama-de-objeto-uml/http://portalarquiteto.blogspot.com.br/2008/03/diagrama-de-objetos.htmlhttp://www.portalarquiteto.com.br/diagrama-de-componentes/http://www.etelg.com.br/paginaete/downloads/informatica/apostila_uml.pdfhttp://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-elements.htmlhttp://www.macoratti.net/net_uml3.htmMELO, Ana Cristina. Desenvolvendo aplicações com UML. 255 p. – Rio de Janeiro: Brasport,2002. 20