Linguagem Unificada de Modelagem

Pesquisa sobre UML e seus Diagramas

ALUNO

Sumrio
Introduo ......................................................................................................................... 3 Histria ............................................................................................................................. 4 Mtodo ............................................................................................................................. 4 Viso Geral ....................................................................................................................... 5 Diagramas de UML: ......................................................................................................... 5 Relacionamentos utilizados no UML: .............................................................................. 7 Conceitos de UML: ........................................................................................................ 13 Descrio dos Diagramas ................................................................................................. 14
Caso de Uso: ........................................................................................................................... 14 Classes: ................................................................................................................................... 18 Interao / Sequncias / Colaborao: ..................................................................................... 21 Atividades:................................................................................................................................ 24 Comunicao: .......................................................................................................................... 26 Mquina de Estado: ................................................................................................................. 27 Componentes: .......................................................................................................................... 29 Temporal: ................................................................................................................................. 30 Objetivos: ................................................................................................................................. 31 Implantao:............................................................................................................................. 32 Estrutura Composta: ................................................................................................................ 33 Pacote: ..................................................................................................................................... 34

Referncias Bibliogrficas: ................................................................................................ 35

Introduo:
UML (Unified Modeling Language), significa Linguagem Unificada de Modelagem uma linguagem padro para modelagem orientada a objetos. Surgiu da fuso de trs grandes mtodos, BOOCH, OMT (Rumbaugh) e OOSE (Jacobson). Essa linguagem de modelagem no proprietria de terceira gerao, no um mtodo de

desenvolvimento. Tm como funo auxiliar a visualizar o desenho e a comunicao entre objetos. Ela permite que os desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados, criar modelos visuais de software de sistemas intensivos, combinando as melhores tcnicas de modelagem de dados, negcios, objetos e componentes e muito usada para criar modelos de sistemas de software. Fornecer a tecnologia necessria para apoiar a prtica de engenharia de

software orientada a objetos. uma linguagem de modelagem nica, comum e amplamente utilizvel. Embora com a UML seja possvel representar o software atravs de modelos orientados a objetos, ela no demonstra que tipo de trabalho deve ser feito, ou seja, no possui um processo que define como o trabalho tem que ser desenvolvido. O objetivo ento descrever o que fazer, como fazer, quando fazer e porque deve ser feito. necessria a elaborao completa de um dicionrio de dados , para descrever todas as entidades envolvidas, refinando, com isso, os requisitos funcionais do software. A Linguagem Unificada de Modelagem possui diagramas (representaes grficas do modelo parcial de um sistema) que so usados em combinao, com a finalidade de obter todas as vises e aspectos do sistema.

Histria:
A UML tem origem na compilao das melhores prticas de engenharia que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa nica linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de modelagem padro para modelar sistemas concorrentes e distribudos. A UML ainda no um padro da indstria, mas esse objetivo est a tomar forma sob os auspcios do Object Management Group (OMG). O OMG pediu informao acerca de metodologias orientadas a objetos que pudessem criar uma linguagem rigorosa de modelagem de software. Muitos lderes da indstria responderam na esperana de ajudar a criar o padro. Os esforos para a criao da UML tiveram incio em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os mtodos Booch e OMT, decorrido um ano de trabalho, foi lanado, em outubro de 1995, o esboo da verso 0.8 do Unified Process Processo Unificado (como era conhecido). Nesta mesma poca, Jacobson se associou Rational e o escopo do projeto da UML foi expandido para incorporar o mtodo OOSE. Nasceu ento, em junho de 1996, a verso 0.9 da UML. Finalmente em 1997, a UML foi aprovada como padro pelo OMG (Object Management Group), um consrcio internacional de empresas que define e ratifica padres na rea de Orientao a Objetos.

Mtodo:
A UML no um mtodo uma linguagem de modelagem designada para especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem a notao que o mtodo utiliza para expressar projetos enquanto que o processo indica quais passos seguir para desenvolver um projeto. A especificao da UML consiste de duas partes:
4

Semntica - especifica a sintaxe abstrata e a semntica dos conceitos de modelagem esttica e dinmica de objetos; Notao especifica a notao grfica para a representao visual da semntica.

A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental o processo de desenvolvimento de sistemas em pequenos passos. Uma iterao um lao de desenvolvimento que resulta na liberao de um subconjunto de produtos que evolui at o produto final percorrendo as seguintes atividades:

Anlise de requisitos Anlise Projeto Implementao Teste

O detalhamento de cada etapa destas atividades define o mtodo de desenvolvimento de sistemas.

Viso Geral:

Diagramas de UML: Na verso 1.0 da UML os diagramas eram apresentados em duas categorias:
5

Esttica composta por 5 diagramas e Dinmica composta por 4 diagramas.

Diagramas de viso esttica: Caso de Uso Classe Objeto Componentes Implantao

Diagramas de Viso Dinmica: Sequncia Colaborao Estado Atividade

J na verso atual 2.0 os diagramas estticos passaram a ser denominados estruturais e tambm passaram a fazer parte da UML os diagramas de (Viso Geral, Comunicao, Temporal, Pacotes e Estrutura Composta) as categorias da verso atual da UML se apresentam com 6 diagramas estruturais e 7 diagramas dinmicos. Como so apresentados na tabela abaixo:

Relacionamentos utilizados no UML: Associao Agregao Generalizao

Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos:

Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados.

Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido.

Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e dois casos de uso ou um ator e um caso de uso e assim sucessivamente. O relacionamento representado atravs de uma seta: Exemplo: Diagrama de "Use Cases" para um sistema automatizado de Matrcula num Curso

Tipo de Relacionamento - Associaes

8

Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando, por exemplo, que elas "conhecem uma a outra", "esto conectadas com", "para cada X existe um Y" e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas complexos

Associaes Normais O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos. Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um nome para cada sentido da associao. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrita nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).

Duas classes se relacionando por associao normal No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associao.

Associao Recursiva possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe. Uma associao deste tipo chamada de associao recursiva.

Exemplo de uma associao recursiva

Associao Ternria Mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes. Ela mostrada como uma grade losango (diamante) e ainda suporta uma associao de classe ligada a ela, traaria-se, ento, uma linha tracejada a partir do losango para a classe onde seria feita a associao ternria.

Exemplo de uma associao ternria No exemplo acima a associao ternria especifica que um cliente poder possuir 1 ou mais contratos e cada contrato ser composto de 1 ou vrias regras contratuais.

Agregao A agregao um caso particular da associao. A agregao indica que uma das classes do relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para identificar uma agregao so: "consiste em", "contm", " parte de".

uma forma especializada de associao na qual um todo relacionado com suas partes. Tambm conhecida como relao de contedo.

representada como uma linha de associao com um diamante junto Classe agregadora.

A multiplicidade representada da mesma maneira que nas associaes.

10

Tipo de Relacionamento - Generalizaes A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais particularidades. Um objeto mais especfico pode ser usado como uma instncia do elemento mais geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados em outros. Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta.

Generalizao Normal Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdados.

Exemplo de uma generalizao normal

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes. A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalizao.

Generalizao Restrita
11

Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem as generalizaes restritas com mais de uma subclasse:

Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio significa que quando subclasses herdam de uma superclasse por sobreposio, novas subclasses destas podem herdar de mais de uma subclasse. A generalizao disjuntiva exatamente o contrrio da sobreposio e a generalizao utilizada como padro

Exemplo de uma generalizao de sobreposio

Generalizaes Completa e Incompleta: Uma restrio simbolizando que uma generalizao completa significa que todas as subclasses j foram especificadas, e no existe mais possibilidade de outra generalizao a partir daquele ponto. A generalizao incompleta exatamente o contrrio da completa e assumida como padro da linguagem.

12

Conceitos de UML: Ator Definir o papel que um utilizador representa relativamente ao sistema informtico modelado. Tipicamente, um ator representa um papel que um ser humano, um dispositivo de hardware ou at outro sistema desempenha com o sistema. Pode ser: Pessoa; Outro sistema informtico; Equipamento hardware especializado; Uma entidade pode ser representada por vrios atores, j que pode estar a assumir diferentes papis. Atividade Representa os fluxos conduzidos por processamentos; modelagem de aspectos dinmicos de um sistema; Interface Abstrao de comportamentos a serem implementados pelas classes; Package ou Pacote Agrupamentos de elementos; Classe

13

Estrutura que abstrai um conjunto de objetos com caractersticas similares; define o comportamento de seus objetos atravs de mtodos e os estados possveis destes objetos atravs de atributos;

Evento Resultado de uma ao;

Descrio dos Diagramas:

Caso de Uso: O Diagrama de Caso de Uso descreve a funcionalidade proposta para um novo sistema, que ser projetado. Segundo Ivar Jacobson, podemos dizer que um Caso de Uso um documento narrativo que descreve a sequncia de eventos de um ator que usa um sistema para completar um processo. Caso de uso representado por uma elipse, com o nome do caso de uso dentro ou abaixo. Se h limites do sistema no diagrama, o caso de uso deve ficar dentro. Os casos de Uso so tipicamente relacionados a atores. (Iremos ver a definio de ator abaixo.) Imaginem o caso de uso como um palco de teatro, onde vocs tm o cenrio e seus atores, cada um executando uma ao com o cenrio a sua volta. O palco (limite) seria a parte do sistema em que o cenrio se encaixa. Use os casos de uso para descrever o sistema e como ele executa a ao, utilize uma linguagem simples e objetiva. Algumas regras para fazer um bom caso de uso:

Um caso de uso sempre se inicia por um Ator. Um caso de uso deve oferecer possveis situaes do mundo real para testes do sistema.

Um caso de uso deve ser completo. Um caso de uso deve ser uma descrio completa do sistema, o mesmo no estar completo at que o valor final seja produzido.

Para identificar os casos de uso devemos fazer algumas perguntas:

14

O ator precisa ler, modificar, alterar alguma informao no sistema? O trabalho do ator pode ser facilitado, simplificado com o uso de mais funes no sistema?

O ator tem que receber ou enviar notificaes ao sistema? Quais as funes que o ator precisa do sistema? O que o ator precisa fazer? Quais os problemas com a implantao atual?

Ator Especifica um papel executado que interage com o cenrio (caso de uso). Um ator deve ter associaes exclusivamente para casos de uso. A exceo um ator que possa herdar o papel de outro. Um ator representado por um boneco (stick man).

Um ator pode ser um usurio, um humano, uma mquina, hardware, uma aplicao. Um ator deve representar uma interao com o sistema. Para identificar um ator de um sistema podemos fazer as seguintes perguntas:

Quem est interessado na exigncia? O sistema usa um recurso externo? Quem fornece a informao ir usar e modificar, ou s remover? Uma pessoa representa um papel? O sistema interage com um sistema legado?

Interao em caso de uso O ator comunica-se com o sistema atravs do envio e recebimento de mensagens. Um ator comunica-se com o caso de uso, esta comunicao e mostrada conectando-se o smbolo do ator ao smbolo do caso de uso por um caminho slido.

15

Tipos de relacionamento

Uso <<use>>

Quando os casos de uso tm um comportamento comum eles podem ser modelados em um simples caso de uso que utilizado por outro caso de uso. Ocorre quando h uma parcela de comportamento similar sugerindo um reutilizao.

Incluso <<include>>

No relacionamento de incluso, o cenrio mais comum quando existem dois casos de uso que sero utilizados em um caso de uso base, para que outros casos de uso utilizem estes servios. Desta forma evita-se descrever a mesma sequncia em casos de uso que usam outros casos de uso.

16

Extenso <<extend>>

Extenses so usadas para mostrar um comportamento semelhante, mas com alguma particularidade.

Como fazer um bom caso de uso Eu tenho uma receita que costumo seguir para montar os meus casos de uso. Vou pass-la a vocs, mas com o tempo vocs iro melhorar a receita ou adequar s suas necessidades. Passo 1: Identificao dos atores
o o

Listar os atores; Nomear os atores, d nomes reais Sr. Joo , Impressora HH900, CGQ;

Descrever o papel de cada ator;

Passo 2: Identificao dos Cenrios (Casos de Uso)

o o

Listar os casos de uso; Nomear os casos de uso (verbos);

17

Descrever os casos de uso;

Passo 3: Definir as interaes (Atores x Casos de Uso)

o o

Descrever as interaes; Analisar os esteretipos dos relacionamentos

<<include>>, <<use>>, <<extend>>) Passo 4: Montar o diagrama

o o

Desenhe o diagrama; Descreva o diagrama;

Passo 5: Estabelecer as ligaes

o

Agrupe pelo tipo de cenrio;

Classes: O diagrama de classes representa a estrutura dos objetos que iro compor o sistema, as classes podem se relacionar de vrias maneiras entre elas. (Leia Tipos de Relacionamentos para se familiarizar com os tipos). Ao meu ver, este diagrama um dos mais utilizados para a modelagem orientada a objetos.

Tipos de classes

Conceitual:
o

Usada para a anlise dos objetos;

Persistncia:
o

Comumente usada para representar as tabelas de uma base de dados, mas pode ser usada para representar qualquer objeto que precise ser serializado;

Controle:
o

So nossas camadas, utilitrios, componentes; Representam a fronteira entre o sistema e o usurio. So nossas telas ou Interfaces de Usurio;

Limite:
o

Interface/ Abstrao:
o o

Definem padres; Servem para agrupar objetos comuns;

Concretas:
18

So as classes finais da hierarquia e as mais sero utilizadas dentro do nosso sistema;

Conhecendo as partes de uma classe Uma classe dividida em partes, veja: Classe de um objeto Pessoa

Classe de uma tabela Pessoa

Dependendo da ferramenta que voc estiver utilizando, a mesma pode gerar para voc o cdigo para cada tipo de classe que voc tenha criado. Veja aqui o cdigo gerado pelo Enterprise Architect. Para o objeto:

19

Para a tabela:

5 passos para fazer um bom diagrama de classe 1. Analisar os cenrios e o ambiente do usurio, casos de uso, neste momento dever ser feito uma lista de classes que iro compor o sistema; 2. Estabelecer os relacionamentos entre as classes; 3. Definir os atributos, propriedades, mtodos e eventos que iro compor suas classes;
20

4. Documente cada classe, propriedades, mtodos e eventos com uma documentao descritiva rica em detalhes; 5. Aps a anlise, separe as classes de objeto, de interfaces, de tabelas;

Interao / Sequncias / Colaborao: Os diagramas de sequncia do nfase sequncia lgica em que as mensagens so trocadas. Os diagramas de colaborao do nfase a ordenao estrutural em que os objetos se colaboram. Para facilitar o entendimento iremos ver os dois em detalhe abaixo.

Diagrama de Sequencia Usamos o diagrama de sequncia para modelar a interao entre os objetos e normalmente esto associados a apenas um caso de uso. Este diagrama mostra a colaborao dinmica de vrios objetos, com isso podemos ver a execuo de um ponto especfico da aplicao. O diagrama de sequncia possui dois eixos, horizontal que mostra os objetos envolvidos e o eixo vertical que mostra o tempo em que a ao acontece, este tempo representado por uma linha tracejada a qual chamamos de linha de vida. Para visualizar o tempo olhamos o diagrama de cima para baixo. Os objetos so representados por cones no topo do diagrama e as setas representam as direes das mensagens. Os diagramas de sequncia podem representar objetos que so criados ou destrudos no decorrer da aplicao. Podem representar acessos concorrentes (threads). Vejamos um diagrama de Exemplo:

21

Este diagrama representa um processo simples de saque. Desde a insero do carto at o momento em que gravado pelo banco.

Diagramas de Colaborao Os diagramas de colaborao, diferente dos diagramas de sequncia que focam na ordem cronolgica, focam no relacionamento dos objetos e em sua compreenso. So ligados por associaes cada associao representa uma mensagem e so marcadas com nmeros para vermos sua sequncia. O diagrama de colaborao semelhante ao de sequncia, ambos mostram a colaborao dinmica entre os objetos. No precisamos usar os dois diagramas, algumas dicas que podero ajudar a identificar qual usar:

Se a necessidade for usar um diagrama para mostrar uma sequncia cronolgica utilize o diagrama de sequncia;

Se a necessidade for mostrar o contexto prefira o diagrama de colaborao; Prefira os diagramas de sequncia para cenrios complexos;
22

Utilize o diagrama de colaborao para cenrios mais simples.

Exemplo de um diagrama de Colaborao:

Vimos aqui que os diagramas de sequncia e colaborao formam o diagrama de interao, eles representam a dinmica de um sistema.

Os objetos colaboram entre si a partir da interao existente entre os atores e o sistema. A partir de eventos gerados teremos as operaes, podemos dizer que os eventos so estmulos gerados e as operaes as respostas estes estmulos.

Caractersticas dos diagramas de interao

Representam a dinmica de um sistema; Representam as colaboraes e comportamentos entre os objetos; Simplicidade, pois as mensagens podem ser lidas ao observar os diagramas; Representam a ordem que as coisas acontecem; Possui dois diagramas para representar as interaes; Podemos ver os passos gerados para cada cenrio; As operaes de cada sistema e sua importncia;

Como fazer 1. Defina o caso de uso que deseja representar; 2. Define quais sero os comportamentos que voc ir representar; 3. Crie notas para deixar a descrio de seus diagramas mais informativas; 4. Defina seus relacionamentos; 5. Defina a ordem em que acontecem os eventos;
23

Atividades: No diagrama de atividades podemos representar as aes que so executadas. Podemos documentar os mtodos que iremos escrever na instncia de um objeto. Os estados no diagrama de atividades mudam quando uma ao executada, estes estados podem ser representados com swimlanes. Uma swimlane agrupa a atividade e as organizam de acordo com suas responsabilidades. So representadas por retngulos que englobam os objetos que esto ligados a atividade. Abaixo uma imagem de exemplo da swimlane

Os diagramas de atividade representam o fluxo das informaes dentro de um objeto do sistema, podemos representar as condies e as execues paralelas. O propsito do digrama de atividades e focar no fluxo do sistema e descrever o processamento interno e paralelo. Podemos comparar o diagrama de atividades ao antigo fluxograma. Exemplo de um diagrama para Fritar um Ovo:

24

Definies:

Atividade

Representa a execuo de alguma coisa, uma mtodo, uma rotina, um trabalho, etc.

Separao

Representa as execues paralelas, tm uma entrada e podem ter vrias sadas.

Juno

Usamos a juno para unir as sadas de duas ou mais separaes.

Desvio

a representao de uma nica entrada em vrias sadas. um tipo de comportamento condicional.

25

Intercalao

Ao contrrio do desvio aqui temos vrias entradas com uma nica sada.

Incio

Marca o incio das atividades no diagrama.

Fim

Marca o fim das atividades no diagrama.

Como Fazer: 1. Identificar os cenrios; 2. Modelar a parte bsica; 3. Modelar as junes, decises, separaes. Se houver; 4. Se houver a necessidade, organizar com o uso de swimlanes;

Comunicao: Este diagrama era conhecido como Diagrama de Colaborao at a verso 1.5 da UML, tendo o seu nome modificado para Diagrama de Comunicao a partir da verso 2.0 e est amplamente associado ao Diagrama de Sequncia, na verdade, um complementa o outro. As informaes mostradas no Diagrama de Comunicao so, com frequncia, praticamente as mesmas apresentadas no Diagrama de Sequncia, porm com um enfoque diferente, visto que este diagrama no se preocupa com a linha de tempo do processo, concentrando-se em como os objetos so vinculados e quais mensagens trocam entre si durante o processo.

26

Mquina de Estado: Podemos ver o diagrama de estados como um complemento para o diagrama de classes. Neste diagrama podemos mostrar qual o estado em que o nosso objeto est naquele momento. O diagrama de estado deve ser construdo para os objetos que tem seus estados definidos e onde o comportamento do objeto muda por causa de um determinado estado. Podemos representar aqui o ciclo de vida dos objetos e como so afetados pelos eventos (erros, mensagens, condies). Os diagramas de estado comeam com um estado inicial (um crculo preto todo preenchido) e podem ter vrias sadas (um crculo com um X) ou fins (Um crculo com outro crculo menor preenchido).

Vamos pensar em um objeto que faz pedidos de venda. Este objeto pode ter vrios estados:

Em Anlise de Crdito; Crdito Aprovado; Crdito no aprovado; Aguardando Liberao; Pedido Entregue; Cancelado; Neste caso teremos que representar tambm algumas condies e transies de um estado para outro. Vamos ver como fica nosso diagrama

27

Caractersticas Principais

Demonstrar os estados possveis de um objeto; Demonstrar a transio de um objeto para outro; Ajudam a visualizar a complexidade do sistema de forma simples;

Como fazer

Defina o objeto que ir representar; Aqui podemos usar os diagramas de interao para nos ajudar Defina os eventos e estados que o objeto vai ter; Estabelea o incio e fim do seu objeto; Estabelea os estados de seu objeto, se possvel na ordem em que acontecem;

28

Componentes: O diagrama de componente mostra o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos. Este diagrama descreve os componentes e as dependncias, representando a estrutura do cdigo gerado. Um sistema pode ter dezenas ou centenas de componentes que formaram um conjunto e daro sentido ao sistema. Podero existir componentes que sero responsveis pela implementao de uma ou mais classes. Os componentes tambm podem ser uma tabela, documentos, outros sistemas. Todo este conjunto ir compor o sistema Um componente representado como um retngulo e dois pequenos retngulos do lado esquerdo e o nome do componente pode ser escrito dentro ou abaixo do componente. Os componentes podem ser implementados por meios diferentes de arquivos, linguagens de programao, tabelas, equipamentos. Para determinar o tipo do componente usamos esteretipos. Abaixo alguns diagramas de exemplo com alguns esteretipos (<<esteretipo>>) para definir o seu tipo e alguns relacionamentos.

29

Ao contrrio de outras implementaes, uma das principais vantagens de um sistema componentizado a modularidade. O sistema pode ser construdo por componentes agrupados em mdulos e cada um com uma funo distinta, desta forma facilitamos a construo de novas funcionalidades no sistema.

Como Fazer: 1. Identifique os componentes que iro fazer parte do sistema; 2. Defina os esteretipos dos componentes; 3. Identifique as interfaces que iro compor o diagrama; 4. Identifique os documentos que iro compor o sistema, arquivos, tabelas, documentos.

Temporal: Este diagrama descreve a mudana no estado ou condio de uma instncia de uma classe ou seu papel durante um tempo. Tipicamente utilizado para demonstrar a mudana no estado de um objeto no tempo em resposta a eventos externos. Este o terceiro diagrama criado a partir da nova verso da linguagem.

30

Objetivos: O diagrama de objetos uma variao do diagrama de classes. A diferena que neste diagrama voc pode colocar os nomes reais aos seus objetos. O diagrama de objetos no to importante quanto o de classes, mas ele vai ajudar a exemplificar um diagrama de classes muito complexo. Por exemplo, uma pessoa fsica que se chama Marcelo, voc pode definir um objeto Marcelo e representar ele aqui. Tecnicamente podemos dizer que o diagrama de objetos representa uma instncia da classe. Os diagramas de objetos tm seu nome sublinhado e todos os seus relacionamentos so mostrados. Seus nomes vm separados das classes que ele representa por (dois pontos). Ex: Marcelo:Pessoa

Os diagramas de objetos so importantes para visualizar, especificar e documentar os modelos estruturais, assim como aspectos dentro de um sistema. Exemplo de um diagrama:

Como fazer: 1. Escolha o cenrio que deseja representar; 2. Identifique as classes; 3. Defina os relacionamentos entre os objetos;
4. Defina os nomes e valores para os atributos de seu objeto;

31

Implantao: O diagrama de implantao representa a configurao e a arquitetura do sistema em que estaro ligados os respectivos componentes. Neste diagrama tambm podemos representar toda a estrutura de hardware e requisitos mnimos onde o sistema ser executado.

Caractersticas do Diagrama

Pode representar a estrutura da plataforma em que ser utilizado; Pode representar bancos de dados, Componentes de Terceiros; Pode representar os servidores, a rede; Pode representar a configurao dos equipamentos; Este diagrama no especfico do desenvolvedor, mas em uma equipe onde existe o responsvel pela implantao do sistema, este deve estar preocupado com o hardware e a configurao em que o sistema dever ser executado e a compatibilidade entre os dois.

Os Diagramas de Implantao tambm podem ser usados para especificar os mdulos do sistema que devero ser instalados no cliente.

32

Como Fazer: 1. Identifique os dispositivos e o ambiente que a aplicao dever ser executada; 2. Se for possvel utilize alguma ferramenta para descobrir a configurao adequada de hardware; 3. Se a instalao ficar complexa crie mais de um diagrama, cada um focando em um determinado ponto da instalao; 4. Utilize as notas para explicar melhor cada passo do diagrama;

Estrutura Composta: Este diagrama utilizado para modelar Colaboraes. Uma colaborao descreve uma viso de um conjunto de entidades cooperativas interpretadas por instncias que cooperam entre si para executar uma operao especfica. Este diagrama tambm pode ser utilizado para definir a estrutura interna de um classificador. Este um dos novos diagramas propostos pela UML 2.0.

33

Pacote: Os diagramas de pacotes ou diagrama de mdulos, organizam os modelos criados, todos os blocos, casos de uso, classes, componentes, etc. Estes diagramas podem ser organizados em pacotes. (namespace em .net ou package em java). Deve-se fazer a organizao dos pacotes observando a semelhana de cada diagrama e no que diz respeito soluo do problema que cada um est sendo empregado. Neste diagrama podemos representar a dependncia entre os mdulos do sistemas, isso quer dizer que pacotes podem depender de outros pacotes. Exemplo de uma diagrama de pacotes:

Como Fazer: 1. Identificar objetos semelhantes; 2. Nomear os pacotes (mdulos); 3. Definir os nomes dos pacotes;

34

Referncias Bibliogrficas:
Larman, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007. Booch, Grady. UML: guia do usurio. 2. ed. rev e atual. Rio de Janeiro: Elsevier, c2006. Fowler, Martin. UML essencial: um breve guia para a linguagem-padro de modelagem de objetos. 3. ed. Porto Alegre: Bookman, 2005. 160 p. : il. Nunes, Daltro Jose. Educao em Engenharia de Software. In: A carreira de pesquisador em engenharia de software: princpios, conceitos e direes. Salvador: [s.n.], 2010. Paula Filho, Wilson de Pdua. Engenharia de software: fundamentos, mtodos e padres. 3. ed. Rio de Janeiro: LTC, c2009. BLAHA, Michael, RUMBAUGH, James; Modelagens e projetos baseados em objetos. Rio de Janeiro: Elsevier,2006. BOOCH, Grady; RUMBAUGH, James e JACOBSON, Ivar. UML Guia do Usurio. 1. ed. Rio de Janeiro: Campus, 2006. GUEDES, Gilleanes T. A. UML, Uma abordagem prtica. So Paulo: Novatec, 2004. KRUCHTEN, Philippe. Introduo ao RUP - Rational Unified Process. Rio de Janeiro: Editora Cincia Moderna Ltda, 2003. LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007. MARTINS, Jos Carlos Cordeiro Martins. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2004. MEDEIROS, Ernani Sales de. Desenvolvendo Software com UML 2.0: definitivo. So Paulo: Pearson Makron Books, 2004. MELO, Ana Cristina. Desenvolvendo Aplicaes com UML 2.0. Rio de Janeiro: Brasport, 2004. ArgoUML. Software de modelagem UML e documentao. <http://argouml.tigris.org/>. Acesso em 05 set. 2013. Disponvel em

ASTAH. Astah UML e Community - Software de modelagem UML, documentao e gerao de cdigo fonte. Disponvel em <http://astah.net/editions/uml>. Acesso em 05 set. 2013.

35