Origem Object Management Group (OMG) um consrcio internacional de empresas que define e ratifica padres na rea de Orientao a Objetos,

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. AUnified Modeling Language (UML) ou Linguagem de Modelagem Unificada teve finalmente o inicio de sua criao na metade da dcada de 1990, exatamente em outubro de 1994, Grady Booch (Software Corpporation ), Ivar Jacobson (Objectory) e James Rumbaugh (General Electris) criadores de mtodos orientados a objetos, comearam a compilar as melhores ideias e partiram para a criao de uma linguagem unificada de modelagem. Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com os quais os desenvolvedores de ferramentas pudessem criar uma ferramenta mais utilizvel. Usando tcnicas orientadas a objeto criariam uma linguagem que iria desde o conceito at o sistema executvel, no somente a sistemas complexos mas tambm a sistemas menores e tambm a outros problemas que no fossem sistemas de informao, podendo ser utilizado por seres humanos e mquinas. 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, mas somente 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.

Elementos UML

Diagrama de Caso de Uso

Diagramas de Caso de Uso descrevem relacionamentos e dependncias entre um grupo de Caso de Uso e os Atores participantes no processo. importante observar que Diagramas de Caso de Uso no so adequados para representar o desenho, e no podem descrever os mecanismos internos de um sistema. Diagramas de Caso de Uso so feitos para facilitar a comunicao com os futuros usurios do sistema, e com o cliente, e so especialmente teis para determinar os recursos necessrios que o sistema deve ter. Diagramas de Caso de Uso dizem o qu o sistema deve fazer, mas no fazem e no podem especificar como isto ser conseguido.

Caso de Uso

Um Caso de Uso descreve do ponto de vista dos atores um grupo de atividades num sistema que produz um resultado concreto e tangvel. Casos de Uso so descries de interaes tpicas entre os usurios de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um conjunto de exigncias do que o sistema deve fazer (lembre-se: somente o qu, no como). Quando trabalhar com Casos de Uso, importante lembrar-se de algumas regras simples:

Cada Caso de Uso est relacionado com no mnimo um ator Cada Caso de Uso possui um iniciador (isto um ator) Cada Caso de Uso liga-se a um resultado relevante (um resultado com valor de negcio)

Casos de Uso tambm podem ter relacionamentos com outros Casos de Uso. Os trs tipos mais comuns de relacionamento entre Casos de Uso so:

<<inclui-se>> que especifica que um Caso de Uso toma lugar dentro de outro Caso de Uso <<estende>> que especifica que em determinadas situaes, ou em algum ponto (chamado um ponto de extenso) um Caso de Uso ser estendido por outro. Generalizao especifica que um Caso de Uso herda as caractersticas do Super Caso de Uso, e pode sobrepor algumas delas ou adicionar novas de maneira semelhante a herana entre classes.

Ator

Um ator uma entidade externa (fora do sistema) que interage com o sistema participando (e frequentemente iniciando) um Caso de Uso. Atores podem ser pessoas reais (por exemplo usurios do sistema), outro sistema de computador ou eventos externos. Atores no representam as pessoa fsica ou sistemas, mas sua regra. Isto significa que quando uma pessoa interage com o sistema de diferentes maneiras (assumindo diferentes regras) ela ser representada por diversos atores. Por exemplo um pessoa que fornece suporte ao cliente por telefone e recebe ordens do cliente para o sistema pode ser representado por um ator da Equipe de Suporte e um ator Representante de Vendas
Descrio do Caso de Uso

Descrio do Caso de Uso so narrativas de texto do Caso de Uso. Elas usualmente tomam a forma de uma nota ou um documento que de alguma maneira ligada ao Caso de Uso, e explana o processo ou atividades que tomaro lugar no Caso de Uso.

Diagrama de Classe
Diagramas de Classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe so chamados diagramas estticos porque mostram as classes, com seus mtodos e atributos bem como os relacionamentos estticos entre elas: quais classes conhecem quais classes ou quais classes so parte de outras classes, mas no mostram a troca de mensagens entre elas.

O Umbrello UML Modeller mostrando um Diagrama de Classe

Classe

Um Classe define os atributos e os mtodos de um conjunto de objetos. Todos os objetos desta classe (instncias desta classe) compartilham o mesmo comportamento, e possuem o mesmo conjunto de atributos (cada objeto possui seu prprio conjunto). O termo Tipo algumas vezes usado ao invs de Classe, mas importante mencionar que estes dois termos no so a mesma coisa, e Tipo um termo mais genrico.

Em UML Classes so representadas por retngulos, com o nome da classe, e podem tambm mostrar os atributos e operaes da classe em dois outros compartimentos dentro do retngulo.

Representao visual de uma Classe em UML

Atributos

Na UML, atributos so mostrados com pelo menos seu nome, e podem tambm mostrar seu tipo, valor inicial e outras propriedades. Atributos podem tambm ser exibidos com sua visibilidade:
+ # -

indica atributos pblicos indica atributos protegidos indica atributos privados

Operaes

Operaes (mtodos) tambm so exibidos com pelo menos seu nome, e podem tambm mostrar seus parmetros e valores de retorno. Operaes podem, como os Atributos, mostras sua visibilidade:
+ # -

indica operaes pblicas indica operaes protegidas indica operaes privadas

Modelos

Classes podem ter modelos, um valor que usado para uma classe ou tipo no especificado. O tipo de modelo especificado quando uma classe iniciada (isto um objeto criado). Modelos existem no C++ moderno e foram introduzidos no Java 1.5 onde eles so chamados de Genricos.
Associaes de Classe

Classes podem relacionar-se (ser associada com) com outras de diferentes maneiras:

Generalizao

A herana um dos conceitos fundamentais da programao orientada por objetos, nos quais uma classe ganha todos os atributos e operaes da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operaes prprias. EM UML, uma associao Generalizao entre duas classes coloca-as numa hierarquia representando o conceito de herana de uma classe derivada de uma classe base. Em UML, Generalizaes so representadas por uma linha conectando duas classes, com uma seta no lado da classe base.

Representao visual de uma generalizao em UML

Associaes

Um associao representa um relacionamento entre classes, e fornece a semntica comum e a estrutura para muitos tipos de conexes entre objetos. Associaes so o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem a conexo entre diferentes classes (a conexo entre os objetos atuais chamada conexo do objeto, ou link. Associaes podem ter um regra que especifica o propsito da associao e pode ser uni ou bidirecional (indicando se os dois objetos participantes do relacionamento podem mandar mensagens para o outro, ou se apenas um deles sabe sobre o outro). Cada ponta da associao tambm possui uma valor de multiplicidade, que dita como muitos objetos neste lado da associao pode relacionar-se com o outro lado. Em UML, associaes so representadas como linhas conectando as classes participantes do relacionamento, e podem tambm mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade exibida como um intervalo [min...mx] de valores no negativos, com uma estrela (*) no lado mximo representando infinito.

Representao visual de uma Associao em UML

Agregao

Agregaes so um tipo especial de associao no qual as duas classes participantes no possuem em nvel igual, mas fazem um relacionamento todo-parte. Uma Agregao descreve como a classe que possui a regra do todo, composta (tem) de outras classes, que possuem a regra das partes. Para Agregaes, a classe que age como o todo sempre tem uma multiplicidade de um. Em UML, Agregaes so representadas por uma associao que mostra um romboide no lado do todo.

Representao visual de um relacionamento Agregao em UML

Composio

Composies so associaes que representam agregaes muito fortes. Isto significa que Composies formam relacionamentos todo-parte tambm, mas o relacionamento to forte que as partes no pode existir independentes. Elas existem somente dentro do todo, e se o todo destrudo as partes morrem tambm. Em UML, Composies so representadas por um romboide slido no lado do todo.

Outros Itens do Diagrama de Classe

Diagramas de Classe podem conter diversos outros itens alm das classes.
Interfaces

Interfaces so classes abstratas que significam instncias que no podem ser diretamente criadas delas. Elas podem conter operaes mas no podem conter atributos. Classes podem derivar de interfaces (atravs da realizao de uma associao) e instncias podem ento ser feitas destes diagramas.

Tipos de dados

Tipos de dados so primitivos uma vez que so tipicamente construdos numa linguagem de programao. Exemplos comuns so inteiros e lgicos. Eles no podem ser relacionados classes mas classes pode se relacionar com eles.
Enumeraes

Enumeraes so uma lista simples de valores. Um exemplo tpico uma enumerao para dias da semana. As opes de uma enumerao so chamadas Literais de Enumerao. Como tipos de dados, elas no podem ter relacionamentos para classes mas classes podem relacionar-se com elas.
Pacotes

Pacotes representam um espao de nomes numa linguagem de programao. Num diagrama eles so usados para representar partes de um sistema que contm mais de uma classe, talvez centenas de classes.

Diagramas de Sequncia
Diagramas de Sequncia mostram a troca de mensagens (isto chamada de mtodo) entre diversos Objetos, numa situao especfica e delimitada no tempo. Objetos so instncias de classes. Diagramas de Sequncia colocam nfase especial na ordem e nos momentos nos quais mensagens para os objetos so enviadas. Em Diagramas de Sequncia objetos so representados atravs de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo tambm vertical, aumentando para baixo, de modo que as mensagens so enviadas de um Objeto para outro na forma de setas com a operao e os nomes dos parmetros.

O Umbrello UML Modeller mostrando um Diagrama de Sequncia

Mensagens pode ser sncronas, o tipo normal de mensagem de chamada onde o controle passado para o objeto chamado at o mtodo ter terminado sua execuo, ou assncronas onde o controle passado diretamente para o objeto chamado. Mensagens sncronas possui uma caixa vertical no lado do objeto chamado para mostrar o controle do fluxo do programa.

Diagramas de Colaborao
Diagramas de Colaborao mostram as interaes que ocorrem entre os objetos participantes numa situao especfica. Isto mais ou menos a mesma informao mostrada pelos Diagramas de Seqncia, mas neste a nfase colocada em como as interaes ocorrem no tempo, enquanto os Diagramas de Colaborao colocam os relacionamentos entre os objetos e sua topologia em destaque. Em Diagramas de Colaborao as mensagens enviadas de um objeto para outro so representadas por setas, mostrando o nome da mensagem, parmetros, e a sequncia da mensagem. Diagramas de Colaborao so especialmente indicados para mostrar um fluxo ou situao especfica do programa e so um dos melhores tipos de diagrama para rapidamente demonstrar ou explanar um processo na lgica do programa.

O Umbrello UML Modeller mostrando um Diagrama de Colaborao

Diagrama de Estado
Diagramas de Estado mostram os diferentes estados de um Objeto durante sua vida, e o estmulo que faz com que o Objeto mude seu estado. Diagramas de Estado veem Objetos como mquinas de estado ou automatismos finitos que podem ser um de um conjunto de estados finitos e que podem mudar seu estado atravs de um de um conjunto finito de estmulos. Por exemplo um tipo de Objeto ServidorRede pode estar em um dos seguintes estados durante sua vida:

Pronto Ouvindo Trabalhando Parado

e os eventos que podem fazer com que o Objeto mude de estado so

Objeto criado Objeto recebe mensagem ouvir Um Cliente solicita uma conexo atravs da rede Um Cliente termina um pedido O pedido executado e terminado Objeto recebe mensagem parar etc

O Umbrello UML Modeller mostrando um Diagrama de Estado

Estado

Estados so os blocos construdos dos Diagramas de Estado. Um Estado pertence a exatamente uma classe e representa um resumo dos valores dos atributos que uma classe pode tomar. Um Estado UML descreve o estado interno de um objeto para uma classe em particular Observe que nem toda mudana em um dos atributos de um objeto pode ser representada por um Estado mas somente aquelas mudanas que podem afetar significativamente o trabalho do objeto Existem dois tipos especiais de Estados: Inicial e Final. Eles so especiais porque nenhum evento pode fazer com que um Objeto retorne para seu estado Inicial, e da

mesma maneira nenhum evento pode tirar um Objeto de seu estado Final uma vez que ele j o tenha alcanado.

Diagrama de Atividade
O Diagrama de Atividade descreve a sequncia de atividades num sistema com a ajuda as Atividades. Diagramas de Atividade so uma forma especial de Diagramas de Estado, que somente (ou principalmente) contm Atividades.

O Umbrello UML Modeller mostrando um Diagrama de Atividade

Diagramas de Atividade so similares as Diagramas de Fluxo de procedimentos, com a diferena de que todas as Atividades so claramente anexas aos Objetos. Diagramas de Atividade so sempre associados a um Classe, uma Operao ou um Caso de Uso. Diagramas de Atividade suportam Atividades sequenciais bem como paralelas. A execuo paralela representada pelos cones Forquilha/Esperar, e para as Atividades executadas em paralelo, no importante a ordem na qual elas se executam (elas podem ser executadas ao mesmo tempo ou uma aps a outra).

Atividade

Uma Atividade um passo simples num processo. Uma Atividade um estado no sistema com atividade interna e, pelo menos, uma transio de sada. Atividades podem tambm ter mais de uma transio de sada se elas possuem condies diferentes. Atividades podem formar hierarquias, isto significa que uma Atividade pode ser composta por diversas Atividades em detalhe, na qual as transies de entrada e sada devem corresponder s transies de entrada e sada do diagrama de detalhe.

Elementos Auxiliares
Existem dois elementos em UML que no possuem nenhum valor real semntico para o modelo, mas auxiliam a elucidar partes do diagrama. Estes elementos so

Linhas de texto Notas de Texto e ncoras Caixas

Linhas de texto so teis para adicionar informaes curtas de texto ao diagrama. So textos livres e no possuem nenhum significado para o Modelo propriamente dito. Notas so teis para adicionar informaes mais detalhadas sobre um objeto ou situao especfica. Elas possuem a grande vantagem de poderem ser ancoradas a Elementos UML para mostrar que a nota pertence a um objeto especfico ou situao. Caixas so retngulos de forma livre que podem ser usados para agrupar itens tornando os diagramas mais legveis. Eles no possuem nenhum significado lgico no modelo.

Diagramas de Componente
Diagramas de Componente mostram os componentes do software (sejam componentes de tecnologias como KParts, componentes CORBA ou Java Beans ou apenas sees do sistema que so claramente distintas) e os artefatos de que eles so feitos como arquivos de cdigo-fonte, bibliotecas de programao ou tabelas de bancos de dados relacionais. Componentes pode possui interfaces (isto classes abstratas com operaes) que permitem associaes entre componentes.

Diagramas de Distribuio
Diagramas de distribuio mostram as instncias dos componentes de tempo de execuo e suas associaes. Eles incluem Ns que so recursos fsicos, tipicamente um computador simples. Eles tambm mostram interfaces e objetos (instncias da classe).

Diagramas de Entidade-Associao
Os Diagramas de Entidade-Associao (Diagramas ER) mostram o desenho conceitual dos aplicativos de bancos de dados. Eles definem as vrias entidades (conceitos) no

sistema de informao e as relaes e restries entre eles. Uma extenso dos Diagramas Entidade-Associao, chamada 'Diagramas Extendidos EntidadeAssociao' (EER) so usados para incorporar as tcnicas de desenho Orientado por Objetos nos diagramas ER.

O Umbrello mostrando um Diagrama de Entidade-Associao

Entidade

Uma Entidade qualquer conceito no mundo real com uma existncia independente. Poder ser um objeto com uma existncia fsica (exemplo, Computador, Rob) ou poder ser um objeto com uma existncia conceitual ( p.ex.: Curso Universitrio). Cada entidade possui um conjunto de atributos que descrevem as propriedades da Entidade. Nota: No existem ainda notaes normalizadas para desenhar Diagramas ER. Os diferentes textos sobre este assunto usam notaes diferentes. Os conceitos e notaes para os diagramas ER usados no Umbrello so do seguinte livro: Elmasri R. e Navathe S. (2004). Fundamentals of Database Systems 4 ed. Addison Wesley

Num Diagrama ER, as Entidades so representadas por retngulos com o nome da classe, e podero tambm mostrar os atributos de uma entidade noutro compartimento dentro do retngulo.

Representao visual de uma entidade num Diagrama ER

Atributos da Entidade

Nos Diagramas ER, os Atributos das Entidades aparecem com o seu nome num compartimento diferente da Entidade a que pertencem.
Restries

As restries nos diagramas ER definem as limitaes sobre os dados no esquema de informao. Existem quatro tipos de restries suportados no Umbrello :

Chave Primria: O conjunto de atributos declarado como chave primria nico para a entidade. S poder existir uma chave primria numa Entidade e nenhum dos seus atributos constituintes poder ser nulo. Chave nica: O conjunto de atributos declarado como chave nica nico para a entidade. Podero existir vrias restries de chaves nicas. Os seus atributos constituintes podero ser nulos. As Chaves nicas e Chaves Primrias identificam de forma nica uma linha numa tabela (entidade) Chave Estrangeira: Uma Chave Estrangeira uma restrio de referncia entre duas tabelas. A chave estrangeira identifica uma coluna ou conjunto de colunas numa tabela (de referncia) que aponta para uma coluna ou conjunto de colunas noutra tabela (referenciada). As colunas da tabela referenciada devero formar uma chave primria ou nica. Restrio de Verificao: Uma restrio de verificao (tambm conhecida como restrio de verificao de tabelas) uma condio que define os dados vlidos ao adicionar ou atualizar um item numa tabela de um banco de dados relacional. Uma restrio de verificao aplicada a cada linha na tabela. A tabela dever ser um predicado. Poder fazer uma referncia a uma ou vrias colunas da tabela. Exemplo: preo >= 0

Conceitos Extendidos dos Diagramas de Entidade-Associao (ER)

Especializao

A especializao uma forma de criar novas entidades com base em entidades que j tenham sido definidas. As entidades novas, conhecidas como entidades derivadas, recebem (ou herdam) os atributos das entidades pr-existentes, as quais so referenciadas como entidades de base. Pretende ajudar a reutilizar os dados existentes com pouca ou nenhuma modificao. No Umbrello, uma pessoa poder definir Especializaes Disjuntas e Sobrepostas
Especializao Disjunta

A Especializao Disjunta especifique que as subclasses de especializao devem ser disjuntas. Isto significa que uma entidade pode ser um membro de pelo menos uma das entidades derivadas da especializao

Representao visual de uma Especializao Disjunta num Diagrama EER

Especializao Sobreposta

Quando as entidades derivadas no so foradas a serem disjuntas, este conjunto de entidades so ditos como sendo de uma especializao sobreposta. Isto significa que a

mesma entidade do mundo real pode ser membro de mais de uma entidade derivada de especializao.

Representao visual de uma Especializao Sobreposta num Diagrama EER

Categoria

Uma Entidade derivada chamada de Categoria quando ela representa uma coleo de objetos que um subconjunto da Unio de tipos de entidade distintos. Uma Categoria modelada quando existe a necessidade de uma nico relacionamento de superclasse/subclasse com mais de uma superclasse, onde as superclasses representam diferentes tipos de entidade. ( Como a herana mltipla em Programao Orientada a Objeto ).

Representao visual de uma Categoria num Diagrama EER