1

UML (Unified Modeling Language) Viso Geral

1. Introduo
A UML uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de Orientao a Objetos. A UML tornou-se, nos ltimos anos, a linguagem padro de modelagem de software adotada internacionalmente pela indstria de Engenharia de Software. A UML no uma linguagem de programao e sim uma linguagem de modelagem. O objetivo da UML auxiliar os engenheiros de software a definir as caractersticas do software: o requisitos; o comportamento; o estrutura lgica; o dinmica de processos; o necessidades fsicas (equipamento), etc.

2. Engenharia de Software
Envolve fatores como levantamento e anlise de requisitos, prototipao, tamanho do projeto, complexidade, prazos, custos, documentao, manuteno e reusabilidade, entre outros. Possui, em geral, as seguintes etapas: Levantamento de requisitos, Anlise de requisitos, Projeto, Codificao, Testes e Implantao.

2.1 Levantamento de requisitos O Engenheiro de Software busca compreender as necessidades do usurio e o que ele deseja que o sistema a ser desenvolvido realize. Feito por meio de entrevistas, onde o Engenheiro tenta compreender como funciona atualmente o processo a ser informatizado e quais servios o cliente precisa que o software fornea. Devem ser realizadas tantas entrevistas quantas forem necessrias para que as necessidades do usurio sejam bem compreendidas. Durante as entrevistas o Engenheiro deve auxiliar o cliente a definir quais informaes devero ser fornecidas, quais informaes devero ser produzidas e qual o nvel de desempenho exigido do software. Problema de comunicao: dificuldade em compreender um conjunto de conceitos vagos, abstratos e difusos, que representam as necessidades e desejos dos clientes, e transforma-los em conceitos concretos e inteligveis. Outro problema que, muitas vezes, os clientes no sabem exatamente o que querem ou no enxergam o real potencial de um sistema de informao. Muitas vezes os Engenheiros precisam sugerir muitas caractersticas e funes do sistema que o cliente no sabia como formular o sequer havia imaginado. 2.2 Anlise de requisitos Analisar as necessidades apresentadas pelo cliente: o verificar se as necessidades foram realmente bem compreendidas; o verificar se os requisitos foram especificados corretamente; o verificar se algum tpico deixou de ser abordado; o verificar se algum conceito precisa ser mais bem explicado; o determinar as reais necessidades do sistema de informao. Propor uma reestruturao na maneira como as informaes so geridas e utilizadas pela empresa, apresentando novas maneiras de combin-las e apresenta-las para que possam ser melhor aproveitadas pelos usurios. Deve gerar as informaes necessrias para a construo de um prottipo.

2.3 Prototipao A prototipao tcnica bastante popular e de fcil aplicao. Consiste em desenvolver um rascunho do que seria o sistema de informao. Apresenta basicamente a Interface do software a ser desenvolvido. Ilustra como as informaes seriam inseridas e recuperadas do sistema. Mostra tambm o comportamento do sistema. Apresenta alguns exemplos com dados fictcios e mostra os resultados, principalmente os relatrios gerados pelo sistema. O prottipo pode evitar que, aps meses de desenvolvimento, se descubra que o software no atende completamente as necessidades do cliente devido principalmente a falhas de comunicao na fase de levantamento de requisitos. Ferramentas: Delphi, C++ Builder, Visual Basic, etc. 2.4 Prazos e Custos Os prottipos, geralmente, induzem o cliente a acreditar que o software se encontra em um estgio bastante avanado de desenvolvimento. Muitas vezes, o cliente no compreende e nem aceita prazos longos e valores altos para o desenvolvimento do sistema, pois para ele, o esboo apresentado j o prprio sistema praticamente acabado, precisando apenas de alguns ajustes, quando na verdade o desenvolvimento ainda no foi realmente iniciado. Uma boa modelagem do sistema ajuda a estimar: o a quantidade de profissionais necessrios para o desenvolvimento; o o custo do desenvolvimento; o a complexidade do desenvolvimento; o o prazo de entrega do sistema. Estimativas podem ser feitas analisando-se a documentao de outros sistemas j desenvolvidos pela empresa. Estimativas erradas provocam: o descontentamento do cliente pelo prazo no cumprido; o prejuzos empresa que desenvolve o sistemas, pois tem que manter a remunerao de seus profissionais por um tempo maior que o previsto e fica impedida de iniciar novos projetos por no ter profissionais disponveis. 2.5 Manuteno e Documentao Representa de 40 a 60% do custo total do projeto. Um dos objetivos da modelagem diminuir a manuteno do sistema devido a erros. Porm, mudanas so sempre necessrias, devido evoluo do sistema para atender as novas necessidades da empresa. Neste caso, a modelagem serve para facilitar a compreenso do sistema para quem tiver que mant-lo ou ampli-lo. Pior problema: cdigo escrito por diferentes profissionais, que no se encontram mais na empresa, cada um com um estilo diferente e que geraram cdigo sem documentao. 2.6 Documentao A documentao auxilia na reutilizao de rotinas, funes e algoritmos, pois permite responder questes do tipo: o Onde as rotinas se encontram? o Para que foram utilizadas? o Em que projetos esto documentadas? o Se elas so adequadas para o software atualmente em desenvolvimento? o Qual o nvel de adaptao necessrio para que essas rotinas possam ser utilizadas no sistema atual?

A documentao de projetos anteriores tambm utilizada no levantamento de prazos e custos de um novo projeto, pois ajuda a responder questes do tipo: o Qual a mdia de custo de modelagem? o Qual a mdia de custo de desenvolvimento? o Qual a mdia de tempo despendido at a finalizao do projeto? o Quantos profissionais so necessrios para o desenvolvimento do projeto?

3. Os diagramas da UML
A UML um conjunto de diagramas que permite fornecer mltiplas vises o sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos. Cada diagrama analisa o sistema, ou parte dele, sob uma determinada tica. Alguns diagramas enfocam o sistema de forma mais geral, apresentando uma viso externa do sistema (Diagramas de Casos de Uso, por exemplo). Outros diagramas oferecem uma viso de uma camada mais profunda do software, apresentando um enfoque mais tcnico (Diagramas de Classes, por exemplo). Cada diagrama complementa os demais.

3.1 Diagrama de Casos de Uso o diagrama mais geral e informal da UML. Utilizado nas fases de Levantamento e Anlise de Requisitos, embora seja consultado durante todo o processo de desenvolvimento e sirva de base para outros diagramas. Apresenta uma linguagem simples e de fcil compreenso, para que os usurios possam ter uma idia geral de como o sistema ir se comportar. Procura identificar os atores (usurios, outros sistemas, hardware especial), que iro interagir com o software de alguma forma. Tambm identifica os servios (aes) que o sistema disponibilizar aos atores. Esses servios, neste diagrama, so conhecidos como Casos de Uso.

Figura 1 Diagrama de Casos de Uso

3.2 Diagrama de Classes o diagrama mais utilizado e o mais importante da UML. Serve de apoio para a maioria dos outros diagramas. Define a estrutura das classes utilizadas pelo sistema. Determina os atributos e mtodos de cada classe. Estabelece como as classes se relacionam e trocam informaes entre si.

Figura 2 Diagrama de Classes 3.3 Diagrama de Objetos Este diagrama est amplamente relacionado ao Diagrama de Classes, sendo praticamente um complemento deste. Fornece uma viso dos valores armazenados pelos objetos de um Diagrama de Classes em um determinado momento da execuo de um processo de software. Tornou-se um diagrama independente na UML 2. Antes era considerado uma extenso do Diagrama de Classes.

Figura 3 Diagrama de Objetos

3.4 Diagrama de Estrutura Composta Descreve a estrutura interna de um classificador, como uma classe ou componente, detalhando as partes internas que o compem, como estas se comunicam e colaboram entre si. Tambm utilizado para descrever uma Colaborao onde um conjunto de instncias cooperam entre si para realizar uma tarefa. um dos trs novos diagramas propostos pela UML 2.

Figura 4 Diagrama de Estrutura Composta 3.5 Diagrama de Seqncia Preocupa-se com a ordem temporal em que as mensagens so trocadas entre os objetos envolvidos em um determinado processo. Em geral, baseia-se em um Caso de Uso. Utiliza o diagrama de classes para determinar os objetos envolvidos em um processo. So funes do Diagrama de Seqncia: o identificar o evento gerador do processo modelado; o identificar o ator responsvel por esse evento; o determinar como o processo deve se desenrolar e ser concludo por meio da chamada de mtodos disparados por mensagens trocadas entre os objetos.

Figura 5 Diagrama de Seqncia

3.6 Diagrama de Colaborao (Comunicao na UML 2) Este diagrama est amplamente associado ao Diagrama de Seqncia, complementando-o. As informaes contidas nestes dois diagramas so praticamente as mesmas, porm o Diagrama de Colaborao no h preocupao com a temporalidade do processo, concentrando-se em como os objetos esto vinculados e quais mensagens trocam entre si.

Figura 6 Diagrama de Colaborao 3.7 Diagrama de Grfico de Estados (Mquina de Estados na UML 2) Este diagrama acompanha as mudanas sofridas por um objeto dentro de um determinado processo. Da mesma forma que o Diagrama de Seqncia, este diagrama muitas vezes baseia-se em um Caso de Uso e apia-se no Diagrama de Classes. Usado para: o acompanhar os estados por que passa uma instncia de uma classe; o representar os estados de um Caso de Uso; o representar os estados gerais de um sub-sistema ou de um sistema completo.

Figura 7 Diagrama de Grfico de Estados

3.8 Diagrama de Atividades Era considerado um caso especial do antigo Diagrama de Grfico de Estados e se tornou independente na UML 2. Este diagrama descreve os passos a serem percorridos para a concluso de uma atividade especfica, concentrando-se na representao do fluxo de controle. Esta atividade especfica muitas vezes representa um mtodo com certo grau de complexidade e no um processo completo como nos diagramas de Seqncia ou Colaborao.

Figura 8 Diagrama de Atividades 3.9 Diagrama de Componentes Este diagrama est amplamente associado Linguagem de Programao que ser utilizada para desenvolver o sistema modelado. Representa os componentes do sistema quando este for implementado m termos de mdulos de cdigo-fonte, bibliotecas, formulrios, arquivos de ajuda, mdulos executveis, etc. Determina como estes componentes estaro estruturados e como iro interagir para que o sistema funcione de maneira adequada.

Figura 9 Diagrama de Componentes

3.10 Diagrama de Implantao Determina as necessidades fsicas do sistema: hardware, servidor, estaes, topologias e protocolos de comunicao, etc. Os diagramas de Componentes e de Implantao so bastante associados, podendo ser representados em conjunto ou separadamente.

Figura 10 Diagrama de Implantao 3.11 Diagrama de Pacotes Tem por objetivo representar os subsistemas englobados por um sistema, de forma a determinar as partes que o compem.

Figura 11 Diagrama de Pacotes 3.12 Diagrama de Tempo Descreve a mudana no estado ou condio de uma instncia de uma classe ou seu papel durante o tempo. Tipicamente utilizada para demonstrar a mudana no estado de um objeto no tempo em resposta a eventos externos. Foi criado na UML 2.

Figura 12 Diagrama de Tempo

3.13 Diagrama de Interao Geral uma variao do Diagrama de Atividades que fornece uma viso geral dentro de um sistema ou processo de negcio.

Figura 13 Diagrama de Interao Geral

3.14 Sntese Geral dos Diagramas

Figura 14 Sntese Geral dos Diagramas

10

UML e Orientao a Objetos

1. Classes de Objetos
As Classes so utilizadas para representar objetos que possuem as mesmas caractersticas e que se comportam de maneira semelhante. As classes so representadas na UML por um retngulo que pode possuir at trs divises: o a primeira diviso armazena o nome pela qual a classe identificada. o a segunda diviso enuncia os possveis atributos (caractersticas ou propriedades) pertencentes classe; o a terceira diviso mostra os possveis mtodos que a classe possui.

Figura 1 Exemplo de uma classe com atributos e mtodos

2. Atributos ou Propriedades
Representam caractersticas dos objetos de uma classe (Cor de um carro, por exemplo). Dois objetos de uma mesma classe podem ser diferenciados atravs de suas propriedades. Os atributos so apresentados na segunda diviso da classe e, geralmente, contm duas informaes: o nome do atributo e o seu tipo (caractere, inteiro, etc.). No possvel trabalhar diretamente com as classes. necessrio criar uma instncia da classe para poder manipul-la. Todas as instncias de uma classe possuem os mesmos atributos, porm com valores diferentes.

3. Mtodos ou Comportamentos
Um mtodo representa uma atividade que um objeto de uma classe pode executar. Toda vez que um mtodo invocado, um conjunto de instrues correspondente quele mtodo executado. Um mtodo, assim como uma funo escrita em uma linguagem de programao como C ou C++, pode (ou no) ter parmetros e pode (ou no) retornar um valor.

4. Visibilidade
A visibilidade utilizada para indicar o nvel de acessibilidade de um determinado atributo ou mtodo. A visibilidade indicada por um smbolo esquerda do nome do atributo ou mtodo. Existem trs modos de visibilidade: o Pblica representada por um smbolo de mais (+) e significa que o atributo ou mtodo pode ser utilizado por qualquer classe; o Privada representada por um smbolo de menos () e significa que somente a classe possuidora do atributo ou mtodo pode utiliz-lo; o Protegida representada por um smbolo de sustenido (#) e significa que somente a classe possuidora do atributo ou mtodo, ou suas subclasses, podem ter acesso ao mesmo.

11

5. Herana
Uma das caractersticas mais poderosas e importantes da Orientao a Objetos (junto com o polimorfismo). Permite reaproveitamento de atributos e mtodos, otimizando o tempo de desenvolvimento, diminuindo a quantidade de linhas de cdigo e facilitando a manuteno. Uma Superclasse, ou Classe Me, a classe que possui outras classes derivadas dela, chamadas de Subclasses ou Classes Filhas. As classes filhas herdam as caractersticas (atributos e mtodos) da classe me. Nas classes filhas no necessrio redeclarar atributos e mtodos j declarados e implementados na classe me. A reutilizao do cdigo automtica. S necessrio se preocupar com os atributos e mtodos exclusivos da subclasse. A Herana Mltipla ocorre quando uma subclasse herda caractersticas de mais de uma superclasse.

Figura 2 Exemplo de Herana

Figura 3 Exemplo de Herana Mltipla

6. Polimorfismo
a redeclarao de mtodos herdados por uma classe. Esses mtodos, embora semelhantes, diferem de alguma forma da implementao utilizada na superclasse, sendo, portanto necessrio reimplement-los na subclasse.

Figura 4 Exemplo de Polimorfismo

12

Diagrama de Casos de Uso

1. Introduo
o diagrama mais abstrato da UML e, portanto, o mais flexvel e informal. Por meio de uma linguagem simples, possibilita a compreenso do comportamento externo do sistema por qualquer pessoa. Apresenta o sistema atravs de uma perspectiva do usurio. Apresenta uma viso geral das funes e servios que o sistema dever oferecer aos usurios, sem se preocupar em como essas funes sero implementadas. utilizado principalmente nas fases de Levantamento e Anlise de Requisitos. Na Anlise de Requisitos, ajuda a especificar, visualizar e documentar as caractersticas, funes e servios desejados pelo usurio. Este diagrama tenta identificar os tipos de usurio que iro interagir com o sistema, quais papis esses usurios iro assumir e quais funes sero requisitadas por cada usurio especfico. Consultado e modificado durante o processo de engenharia. Serve de apoio para outros diagramas. Deve ser apresentado durante as reunies iniciais com o cliente, de forma a ilustrar o comportamento do sistema, facilitar a compreenso do usurio e detectar possveis falhas na especificao.

2. Atores
Representam os papis desempenhados pelos diversos usurios que podero utilizar de alguma maneira os servios e funes do sistema. Eventualmente, um ator pode representar um hardware especial ou mesmo um outro software que interaja com o sistema. Portanto, qualquer elemento externo que interage com o sistema um ator. Os atores so representados por smbolos de bonecos magros com uma descrio de seu papel logo abaixo.

3. Casos de Uso
So os servios, tarefas ou funes que podem ser utilizados pelos atores. So utilizados para expressar e documentar os comportamentos pretendidos para as funes do sistema. Muitas vezes, pode-se associar um Caso de Uso uma Tela do sistema (s vezes so vrias telas; s vezes apenas uma parte de uma tela). So representados por elipses contendo um texto que descreve o servio.

Os Casos de Uso, geralmente, possuem uma documentao que fornece informaes do tipo: o como ser seu funcionamento; o quais atividades devero ser executadas; o qual evento forar a sua execuo; o quais atores podero utiliz-lo; o quais suas possveis restries e validaes.

13

4. Documentao dos Casos de Uso

No existe um formato especfico de documentao definido pela UML. Em geral, utiliza-se uma linguagem simples para que usurios leigos possam entend-la.

O ator principal aquele que mais interage com o sistema e que est interessado em obter resultados.

5. Associaes
As associaes representam as interaes ou relacionamentos: o entre os Atores que fazem parte do diagrama; o entre os Atores e os Casos de Uso; o entre os Casos de Uso e outros Casos de Uso. Uma associao entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se, de alguma maneira, da funo do sistema representada pelo Caso de Uso, seja requisitando a execuo daquela funo, seja recebendo o resultado produzido por ela a pedido de outro Ator. A associao representada por uma reta unindo o Ator ao Caso de Uso. O sentido em que as informaes trafegam em uma associao indicado atravs de setas nas extremidades da reta. Se no houver setas, as informaes so transmitidas nas duas direes. A associao pode possuir uma descrio prpria quando h necessidade de esclarecer a natureza da informao que est sendo transmitida ou quando se quer apenas dar um nome associao.

6. Associao de Especializao/Generalizao
O relacionamento de Especializao/Generalizao uma forma de associao entre Casos de Uso na qual existem dois ou mais casos com caractersticas semelhantes. Facilita a documentao, evitando a repetio de informaes.

14

Caso de Uso Geral descreve caractersticas compartilhadas por todos os casos. Caso de Uso Especfico herda toda a estrutura do Caso de Uso Geral e define as caractersticas especficas. Herda inclusive associaes de Incluso, de Extenso e com Atores que o Caso de Uso Geral venha a possuir. Este tipo de associao representado por uma reta com uma seta mais larga apontando para o Caso de Uso Geral. Este tipo de relacionamento tambm pode ser aplicado a Atores.

7. Associao de Incluso
Esta associao utilizada quando existe um servio, situao ou rotina comum a mais de um Caso de Uso. Evita descrever uma mesma seqncia de passos em vrios Casos de Uso. Os relacionamentos de Incluso indicam obrigatoriedade. Quando um determinado Caso de Uso possui um relacionamento de Incluso com outro, a execuo do primeiro obriga tambm a execuo do segundo. Pode ser comparado chamada de uma sub-rotina. representada por uma reta tracejada contendo uma seta em uma das extremidades, apontando para o Caso de Uso includo. Costuma apresentar o esteretipo <<include>>.

8. Associao de Extenso
As associaes de extenso descrevem cenrios opcionais de um Caso de Uso, que sero executados apenas se uma determinada condio for satisfeita. Exigem um teste para determinar se necessrio executar tambm o Caso de Uso Estendido. Tambm so representadas por uma reta tracejada contendo uma seta em uma das extremidades, apontando para o Caso de Uso que usa o Caso de Uso Estendido. Possui o esteretipo <<extend>>.

15

9. Exemplo: Sistema de Controle de Aplices de Seguro

Todos os Casos de Uso descritos como Manter ... referem-se a cadastros simples com funes do tipo: incluso, alterao, excluso, consulta, etc. Manter Clientes e Manter Veculos Cliente fornece informaes pessoais e do veculo. Corretor insere informaes no sistema. Note que a navegabilidade do Cliente unidirecional. Verifica Veculos Vistoriador verifica estado do veculo e passa seu parecer ao Corretor. Verifica Valor Seguro Corretor consulta Matriz para obter valores e condies do seguro. Gerar Aplice Corretor informa ao Cliente os valores da aplice. Cliente decide em quantas parcelas quer pagar. A aplice gerada. Faz chamada ao Caso de Uso Manter Parcelas a Receber. Manter Parcelas a Receber Registra o valor de cada parcela, data de pagamento, se a mesma j est quitada ou no, etc. Passa as informaes ao Ator Contas a Pagar e Receber. Manter sinistro Recebe as informaes de sinistro do Cliente e informaes adicionais do Vistoriador. Os dados so inseridos no sistema pelo Ator Secretria. Note que o Ator Vistoriador aparece duas vezes no diagrama para evitar congestionamento. Quitar Parcela Cliente paga parcela. Secretria recebe notificao de pagamento. O Caso de Uso Manter Parcelas a Receber atualizado. Existem trs momentos distintos no processo: cliente solicita aplice de seguro, cliente informa sinistro e cliente paga parcela. Porm, o Diagrama de Casos de Uso no se preocupa com a questo da temporalidade, pois existem outros diagramas especficos para isto.

16

10. Exemplo: Sistema de Controle Bancrio

Retngulo representa a Fronteira do Sistema, que separa Atores externos dos servios e funes do software. Atores externos representam o ambiente onde o sistema ser executado (Contexto do Sistema). Cliente pode solicitar a abertura de trs tipos de conta: o Conta comum no permite saque maior do que o saldo; o Conta Especial permite saque extra at um determinado limite; o Conta Poupana rende juros quando o dinheiro depositado no movimentado. Abertura de Conta (Comum, Especial ou Poupana) Cliente fornece informaes para abertura de conta e faz depsito inicial. Funcionrio realiza abertura e faz manuteno no cadastro do cliente se for necessrio. Manter Clientes utilizado frequentemente pelo funcionrio. Quando uma conta aberta, s vezes necessria a incluso do cliente (se ele ainda no cliente do banco) ou a atualizao de seu cadastro. Quando a conta encerrada, pode ser necessria atualizao. Associaes de Extenso. Depsito obrigatrio na abertura de conta. Associao de Incluso. Encerrar Conta antes de encerrar a conta precisamos: o Verificar o Saldo. Associao de Incluso. o Efetuar Saque, se o saldo for positivo. Associao de Extenso. o Efetuar Depsito, se o saldo for negativo. Associao de Extenso. o Atualizar cadastro do Cliente. Se for a nica conta, o cliente passa a ser inativo. Associao de Extenso. Saldo, Depsito, Saque e Extrato podem ser utilizados diretamente pelo Cliente atravs de um Funcionrio ou atravs de um Caixa Eletrnico, por exemplo, representados pelo Ator Banco. Os servios de Saque e Depsito precisam Registrar Movimento. Associao de Incluso.

17

11. Elementos comuns a todos os Diagramas da UML

11.1 Notas Apresenta um texto explicativo a respeito de um determinado elemento do diagrama. As Notas so representadas por retngulos com uma dobra no canto superior direto e ligados ao elemento do diagrama atravs de uma linha tracejada.

11.2 Pacotes Permitem organizar elementos em grupos. Utilizados em modelagem de sistemas muito extensos, principalmente quando existem vrios sistemas ou subsistemas integrados. Demonstram os limites de cada subsistema e como eles se inter-relacionam. So representados por retngulos contendo uma aba no canto superior esquerdo. A principal forma de relacionamento dos pactos a de Dependncia, representada por uma seta tracejada apontando para o pacote que depende do outro.

11.3 Esteretipos So utilizados para destacar algum componente do diagrama, especificando o seu tipo ou funo. A maioria dos esteretipos so textos que aparecem entre os sinais de << e >>.

O esteretipo acima deixa claro que Abertura de Conta um processo.

O esteretipo acima grfico e representa uma fronteira (boundary) do sistema. Indica que o componente uma interface dos usurios externos com o sistema.

18

Documentao do Diagrama de Casos de Uso do Sistema de Controle Bancrio

1. Abertura Conta Comum

2. Abertura Conta Especial

19

3. Abertura Conta Poupana

4. Encerrar Conta

20

5. Manter Clientes

6. Saldo

21

7. Extrato

8. Depsito

22

9. Saque

10. Registrar Movimento

23

Diagrama de Classes
1. Introduo
o mais importante e mais utilizado diagrama da UML. Serve de base para a construo da maioria dos outros diagramas. Permite visualizar as classes que iro compor o sistema com seus respectivos atributos e mtodos. Permite demonstrar como as classes se relacionam, complementam e transmitem informaes entre si. Apresenta uma viso esttica de como as classes esto organizadas e define a estrutura lgica das mesmas. Modelagem de Vocabulrio abstrao da classe com seus atributos e mtodos. Modelagem de Colaborao definio de como as classes se relacionam e colaboram para a execuo de um determinado processo.

2. Classes, Atributos e Mtodos

Atributos armazenam os dados dos objetos da classe. Contedo varia de instncia para instncia, o que nos permite diferenciar objetos da mesma classe. Mtodos funes que uma instncia da classe pode executar. So idnticos para todas as instncias. Embora o Diagrama de Classes identifique os parmetros e valores de retorno dos mtodos, no sua funo definir como estes mtodos iro funcionar quando invocados. Isto competncia do diagrama de Seqncia e/ou do diagrama de Atividades. Uma classe representada por um retngulo com at trs divises: a primeira contm a descrio ou o nome da classe; a segunda armazena os atributos e seus tipos de dados; a terceira lista os mtodos da classe. No obrigatrio uma classe possuir todas as trs divises. Apenas o Nome obrigatrio. O smbolos (+), () e (#) que aparecem ao lado dos atributos e mtodos representam a sua visibilidade (como j vimos anteriormente). Classe Persistente aquela que preserva de maneira permanente o contedo de suas instncias, geralmente atravs de tabelas em bancos de dados relacionais.

3. Relacionamentos
Permitem que as classes compartilhem informaes e colaboram umas com as outras para permitir a execuo de algum processo.

3.1 Associaes Descrevem o vnculo que ocorre entre as classes, como elas so unidas e interagem entre si, compartilhando informaes. A associao de classes representada da mesma forma que a associao de Casos de Uso, utilizando retas com setas nas extremidades. As associaes tambm podem ter Ttulos para determinar o tipo de vnculo estabelecido entre as classes. Tipos de associao: o Unria ou Reflexiva vincula uma classe a si mesma; o Binria feita entre duas classes; o Ternria ou N-ria feita entre trs (ternria) ou mais (n-ria) classes.

24

3.1.1 Associao Unria ou Reflexiva Relacionamento de uma classe consigo mesma.

No exemplo acima: o Chefe tambm funcionrio. o Um chefe pode chefiar nenhum (0) ou vrios (*) funcionrios (multiplicidade 0..*). o Todo funcionrio, obrigatoriamente, tem que ter um (1) chefe (multiplicidade 1..1 pode ser omitida na outra extremidade do relacionamento). o A associao identificada pelo ttulo Chefia. Mutiplicidade: o 0..1 No mnimo 0 e no mximo 1. o 1..1 Um e somente 1. Pode ser omitida. o 0..* No mnimo nenhum e no mximo muitos. o * Muitos. o 1..* No mnimo 1 e no mximo muitos o 3..5 No mnimo 3 e no mximo 5. Outras observaes obre o exemplo: o A classe Funcionrio deve ser persistente (associada a um banco de dados). o Atributo Cdigo serve como chave primria para as instncias da classe. o As classes UML j supem um cdigo-chave implcito, portanto o Atributo Cdigo no precisava ser declarado. o Da mesma forma, no precisaria ser declarado o atributo Cdigo Chefe, pois associaes com multiplicidade de muitos (*) em qualquer extremidade foram a transmisso do atributo-chave da outra extremidade.

3.1.2 Associao Binria Relacionamento entre duas classes. a associao mais comum.

No exemplo acima: o Um objeto da classe Scio pode ou no se relacionar com instncias da classe Dependente. Multiplicidade 0..*. o Um objeto da classe Dependente, obrigatoriamente, tem que se relacionar com uma instncia da classe Scio. Multiplicidade 1..1 (implcita).

25

Podemos adicionar um nome para a associao e indicar um sentido de navegabilidade.

No exemplo acima: o Uma instncia da classe Scio possui nenhuma (0) ou muitas (*) instncias da classe Dependente. o A classe dependente possuda por uma, e apenas uma, instncia da classe Scio (1..1).

3.1.3 Associao Ternria ou N-ria Relacionamento de trs ou mais classes. Representada por um losango para onde convergem todas as ligaes das associaes.

No exemplo acima: o Um professor leciona apara no mnimo uma turma e no mximo muitas. o Uma turma possui no mnimo um professor e no mximo muitos. o Um professor, lecionando em uma determinada turma, utiliza no mnimo uma sala de aula e no mximo muitas. As associaes N-rias devem ser evitadas, pois so de difcil interpretao.

3.1.4 Agregao um tipo especial de associao. Montra que as informaes de um objeto (chamado objeto-todo) precisam ser complementadas por um ou mais objetos de outra classe (chamados objetos-parte). Objetos-parte no podem ser destrudos por um objeto que no seja o objeto-todo. A associao contm um losango na extremidade da classe que contm os objetos-todo.

No exemplo acima: o A associao binria entre Itens Pedido e Produto indica que um produto pode compor muitos itens de pedido e um item de pedido composto de um nico produto. o A agregao entre Pedido (objeto-todo) e Itens Pedido (objeto-parte) indica que um pedido composto por um ou mais itens. o Quando um pedido apresentado, todos os seus itens tambm devem ser mostrados. o Quando um pedido deletado, todos os seus itens tambm devem ser removidos.

26

3.1.5 Composio A Composio uma variao da Agregao. Objetos-parte tm que pertencer exclusivamente a um nico objeto-todo. O smbolo de Composio um losango preenchido.

No exemplo acima: o Uma Revista Cientfica publica vrias edies (pelo menos uma). Cada edio tem que pertencer nica e exclusivamente a uma determinada revista. o Cada edio pode ter de 6 a 10 artigos. Os artigos so exclusivos de uma determinada edio. Observao: no exemplo visto em Agregao, vrios pedidos podem ter um mesmo item.

3.2 Especializao/Generalizao Relacionamento similar associao, mas com o objetivo de identificar classes-me (gerais) e classes-filhas (especializadas). Permite mtodos polimrficos nas classes especializadas (filhas).

27

3.3 Dependncia Este relacionamento no encontrado com freqncia. Indica que se uma classe sofrer mudanas, todas que dependem dela tambm devero sofrer. Representada por uma linha tracejada com uma seta na direo oposta classe dependente.

No exemplo acima, Item Carrinho depende de Carrinho de Compras.

3.4 Realizao Mistura caractersticas de Generalizao e Dependncia. Identifica classes responsveis por executar funes para classes que representam interfaces. Este tipo de relacionamento herda o comportamento de uma classe, mas no a sua estrutura. representado por uma linha tracejada com uma seta vazia que aponta para a classe de interface. Na outra extremidade est a classe que realiza o comportamento pretendido pela interface.

No exemplo acima: o A classe Pgina de Submisso de Artigos, que tem o esteretipo de <<interface>>, pretende ter o comportamento de aceitar artigos, porm no realiza esta tarefa, apenas repassa as informaes para a classe Artigos Submetidos. o A classe Artigos Submetidos que realmente realiza a tarefa atravs do mtodo RegistrarArtigos().

4. Classe Associativa
So produzidas quando da ocorrncia de associaes que possuem multiplicidade muitos (*) em todas as extremidades. So necessrias porque no existe nenhum repositrio que possa armazenar as informaes produzidas pelas associaes. representada por uma linha tracejada partindo do meio da associao em direo classe associativa.

No exemplo acima: o Um autor pode escrever vrios artigos e um artigo pode ter vrios autores. o A classe Escreve deve armazenar, em cada instncia, o cdigo do artigo e o cdigo do autor. Esses cdigos no aparecem no diagrama, pois so implcitos.

28

As classes associativas podem ser substitudas por classes normais, chamadas neste caso de Classes Intermedirias.

5. Restrio
As restries so informaes extras que devem ser validadas durante a implementao do relacionamento. Podem ser utilizadas na maioria dos diagramas UML, mas so comumente encontradas nos diagramas de classes. So representadas por textos delimitados por chaves.

A validao de um atributo ou mtodo tambm pode ser feita atravs de Notas.

Restries tambm podem ser utilizadas para representar o ou-exclusivo (xor).

No exemplo acima, uma pessoa fsica ou jurdica pode possuir uma ou mais contas comuns (1..*). Porm, uma Conta Comum pode ser possuda por apenas uma pessoa (fsica ou jurdica) (1..1). As restries tambm podem ser utilizadas para definir melhor a semntica das classes especializadas derivadas das classes gerais.

29

As restries pr-definidas so: o Completa todas as subclasses possveis foram derivadas. o Incompleta ainda possvel derivar novas subclasses. o Separada ou Disjunta classes mutuamente exclusivas. Uma instncia que pertence a uma classe especializada no pode pertencer outra. o Sobreposta instncia pode pertencer a mais de uma subclasse (hidro-avio).

6. Exemplo: Sistema de Controle de Aplices de Seguro

Cliente pode segurar vrios veculos (1..*). Veculo pertence a um nico cliente (composio). Veculo segurado possui de 1 a 4 parcelas (1..4). Cada parcela possuda por um nico veculo segurado (composio). Marca produz vrios modelos (1..*). Modelo produzido por uma nica marca (composio). Cada veculo pertence a um modelo (1..1). Cada modelo possui nenhum ou vrios (0..*) veculos segurados. Cada veculo segurado sofre nenhum ou vrios (0..*) sinistros. Cada sinistro sofrido por um nico veculo (1..1). Um sinistro pode ser de vrios tipos (1..*): roubo, perda total, etc. Cada sinistro s pode ser de um tipo (1..1). Um sinistro pode produzir nenhum (roubo) ou vrios danos no veculo (0..*). Cada descrio de dano exclusiva de um veculo (1..1). Obs.: as associaes de composio poderiam ser definidas como associaes binrias simples. A diferena que em uma associao, em uma consulta de aplice, por exemplo, as informaes adicionais (parcelas) tambm sero exibidas. No associao binria, no sero exibidas.

30

7. Exemplo: Sistema de Controle de Locaes de Revistas Cientficas

Uma revista cientfica publica uma ou mais edies (1..*). Cada edio s pode pertencer a uma nica revista cientfica (composio). Uma edio contm de 6 a 10 artigos (6..10). Cada artigo s pode pertencer a uma nica edio (composio). Um Artigo pode ser escrito por vrios autores (1..*). Um autor pode escrever vrios artigos (1..*). Escreve uma classe associativa. Uma edio pode compor nenhum ou vrios itens de locao (0..*). Um item de locao composto por uma nica edio (1..1). Uma locao pode ter um ou mais itens (1..*). Cada item pode pertencer a mais de uma locao (agregao). A classe Item Locao complementa a classe Locao, constituindo uma agregao. No uma composio, pois uma mesma edio pode ser locada mais de uma vez, para diferentes scios em diferentes tempos. Um scio pode fazer nenhuma ou vrias locaes (0..*). Cada locao pertence a um nico scio (1..1).

31

8. Exemplo: Sistema de Controle Bancrio

Especializao/Generalizao o As classes Pessoa e Conta Comum possuem, cada uma, duas especializaes (subclasses) que herdam seus atributos e mtodos. o Os mtodos destas duas classes so protegidos, tornando-os visveis s suas subclasses. o A classe Pessoa uma classe abstrata. No podem ser instanciados objetos desta classe. Associaes o Uma pessoa pode possuir 1 ou mais contas (1..*). Uma conta s pode ser possuda por uma pessoa (1..1). A associao do tipo composio indica que a classe conta complementa as informaes da classe pessoa. Assim, sempre que uma pessoa for consultada, as informaes de suas contas tambm devem aparecer. o Uma conta pode ter um ou mais itens no histrico (1..*). Cada item de histrico pertence a uma nica conta(1..1). No uma composio. Atributos: o Pessoa: Nome, Endereo, Telefone, Renda, Situao (1=ativa ou 0=inativa) e Tipo (fsica ou jurdica) o Pessoa Fsica: CPF e Carteira de Identidade o Pessoa Jurdica: CNPJ o Conta Comum: Nmero da conta, Saldo, Data de abertura, Tipo (comum, especial ou poupana), Data de encerramento, Situao (1=ativa ou 0=inativa) e Senha o Conta Especial: Limite o Conta Poupana: sem atributos adicionais o Histrico: Nmero da conta, Tipo (0=saque e 1=depsito), Valor e Data Mtodos (retornam 1 se forem concludos com sucesso e 0 caso contrrio) o Conta Comum: Abertura o mtodo construtor da classe. Parmetros: saldo (depsito feito na abertura), tipo de conta aberta (1=comum, 2=especial e 3=poupana) e senha. Os demais atributos so iniciados na implementao do mtodo: nmero da conta gerado automaticamente, data de abertura capturada diretamente do Sistema Operacional, situao sempre ativa (1) e data de encerramento fica em branco. O valor de retorno ser o nmero da conta ou 0 se ocorrer algum erro.

32

Encerramento encerra uma conta, porm no atua como mtodo destrutor, apenas coloca 0 no atributo situao, indicando que a conta est inativa. Este mtodo no possui parmetros. O nmero da conta necessrio para o encerramento, porm o mesmo j se encontra na memria, pois antes de todo encerramento chamado o mtodo Consulta. Consulta determina se o nmero da conta vlido. Recebe como parmetro o nmero da conta e retorna 1 se a conta existe e 0 caso contrrio. Este mtodo seguido pelo que valida a senha executado antes de diversos outros mtodos. ValSenha - determina se a senha vlida. Recebe como parmetro a senha da conta e retorna 1 se a senha estiver correta e 0 caso contrrio. VerSaldo retorna o saldo atual da conta. Como este mtodo chamado aps o mtodo Consulta, o nmero da conta no precisa ser informado. Saque diminui o valor especificado do saldo da conta. Tem como parmetro o valor a ser sacado. No precisa do nmero da conta, pois executado depois do mtodo Consulta. Depsito acrescenta o valor especificado ao saldo da conta. Tem como parmetros o valor a ser depositado e o nmero da conta. Precisa do nmero da conta, pois nem sempre executado depois do mtodo Consulta. O depsito pode ser feito por outra pessoa. Conta Especial: Abertura este mtodo redeclarado (polimorfismo) para que o atributo que estabelece o limite da conta possa ser iniciado. No necessrio passar como parmetro o tipo de conta, pois sempre especial (2). Saque este mtodo tambm precisa ser redeclarado (polimorfismo), pois o cliente pode sacar todo o saldo da conta mais o valor limite. JurCheqEsp diminui diariamente do saldo da conta o valor correspondente aos juros do cheque especial. Recebe como parmetro a porcentagem de juros que dever ser aplicada ao saldo negativo da conta. No precisa saber o nmero da conta, pois, quando invocado, este mtodo varre todo o cadastro de contas especiais e aplica os juros todas as contas que estiverem negativas. Conta Poupana Rendimento acrescenta o rendimento mensal ao saldo da conta. Recebe como parmetro a data do dia e o percentual de juros a ser aplicado. Varre todo o arquivo de contas poupana e aplica os juros a todas as contas que fazem aniversrio naquele dia. Pessoa Fsica: Gravar Recebe como parmetros todos os atributos da classe. Os parmetros no foram especificados no diagrama por falta de espao e para maior clareza. ValCPF faz a validao do CPF. ConCPF faz consulta ao CPF. Pessoa Jurdica: Gravar idem da pessoa fsica. ValCNPJ faz a validao do CNPJ. ConCNPJ faz consulta ao CNPJ. Histrico Gravar registra um movimento (saque ou depsito) efetuado na conta. Possui como parmetros o nmero da conta, o valor e o tipo de operao (0=saque e 1=depsito). A data capturada do prprio Sistema Operacional. Extrato retorna todos os movimentos de uma conta dentro de um determinado perodo. Tem como parmetros: o nmero da conta, o perodo inicial e o perodo final.

33

9. Esteretipos do Diagrama de Classes

Os esteretipos so uma maneira de destacar os componentes de um diagrama, ressaltando suas funes.

9.1 Esteretipo <<entity>> Tem como objetivo tornar explcito que a classe uma entidade, ou seja, contm informaes recebidas ou geradas pelo sistema.

No confundir classes com esteretipo <<entity>> com classes persistentes. Uma classe do tipo <<entity>> no precisa necessariamente preservar seus dados permanentemente. Na figura acima a classe Conta Comum no persistente. Para declarar uma classe persistente, usar o esteretipo <<persistente>> ou colocar uma restrio ao lado ou abaixo do nome da classe. Nas figuras abaixo, a classe Conta Comum persistente ( esquerda atravs do uso de esteretipo e direita atravs do uso de restrio).

9.2 Esteretipo <<boundary>> Identifica uma classe que serve de comunicao entre os atores externos e o sistema propriamente dito. Tambm conhecido como esteretipo de fronteira (boundary). Muitas vezes uma classe <<boundary>> est associada interface do sistema. Em geral, trabalha em conjunto com classes do tipo <<control>> que sero vistas a seguir. 9.3 Esteretipo <<control>> Identifica classes que servem de intermdio entre as classes <<boundary>> e as outras classes do sistema. Os objetos <<control>> so responsveis por interpretar os eventos ocorridos sobre os objetos <<boundary>>, como os movimentos de mouse ou o pressionamento de um boto, e retransmitilos para os objetos das classes de entidades que compem o sistema.

34

Na figura acima: o Uma classe (boundary) representa a interface do Caixa Eletrnico (labels, Caixas de Texto, Botes, Formulrio). o A outra classe (control) interpreta os eventos ocorridos sobre estes objetos e os repassa para outras classes se for necessrio.

A figura acima mostra o sistema de controle bancrio com esteretipos, restries e interface de um Caixa Eletrnico.

10. Diagrama de Objetos

um complemento do Diagrama de Classes. No um diagrama independente. Fornece uma viso dos valores armazenados pelos objetos em um determinado instante da execuo de um determinado processo do sistema. No apresenta mtodos, apenas atributos com seus respectivos valores atuais. O nome do objeto pode ser apresentado de trs formas: o nome com letras minsculas, seguido de dois pontos (:) e o nome da classe a qual o objeto pertence; o nome do objeto omitido, mas mantendo o dois pontos e o nome da classe; o somente o nome do objeto.

35

Os objetos deste diagrama podem possuir vnculos entre si. Esses vnculos so instncias das associaes existentes no Diagrama de Classes. Os vnculos so representados pelos mesmos smbolos das associaes, porm sem multiplicidade ( sempre 1..1).

No exemplo abaixo: o O objeto vei1 possui vnculo com quatro objetos da classe Parcela. o As duas primeiras parcelas esto quitadas. o A Marca Fiat produz dois modelos (Uno Mille e Marea), porm apenas um deles est associado a um veculo segurado.

36

Diagrama de Seqncia
1. Introduo
Este diagrama determina a seqncia de eventos que ocorrem em um determinado processo. Indica quais condies devem ser satisfeitas, quais mtodos devem ser disparados e em que ordem. Baseia-se no diagrama de casos de uso. O Diagrama de Casos de Uso (nico) pode gerar vrios Diagramas de Seqncia, um para cada processo. Geralmente, para cada Caso de Uso existe um Diagrama de Seqncia. Casos de Uso do tipo <<include>> geralmente no possuem Diagrama de Seqncia, pois o seu diagrama embutido no diagrama do Caso de Uso que o utiliza. Utiliza tambm informaes do Diagrama de Classes.

2. Atores
So entidades externas que interagem com o sistema, solicitando servios e gerando eventos que iniciam processos. No Diagrama de Seqncia, os atores so representados por bonecos magros com uma linha grossa abaixo deles representando a sua linha da vida.

Ator

Objeto

3. Objetos
Representam instncias das classes envolvidas no processo. So representados por um retngulo que contm o nome da instncia, dois pontos e o nome da classe. Abaixo temos uma linha fina tracejada representando a linha da vida do objeto. Objetos podem existir desde o comeo do processo ou serem criados durante o mesmo. A linha da vida de um objeto interrompida com um X quando o mesmo destrudo.

4. Foco de Controle ou Ativao

Identifica momentos em que um objeto participa ativamente do processo, executando um ou mais mtodos. representado por uma linha mais grossa em alguns trechos da linha da vida do objeto. No exemplo abaixo o objeto s participa de forma ativa quando executa os mtodos Consultar CPF, Gravar e Validar CPF.

37

5. Mensagens ou Estmulos
As mensagens so usadas para demonstrar a ocorrncia de eventos, disparando ou no algum mtodo. Um Diagrama de Seqncia, geralmente, iniciado por um evento externo, causado por algum ator, o que acarreta o disparo de algum mtodo. As mensagens podem ser disparadas entre: o dois atores no muito comum, no dispara mtodos, permite uma melhor compreenso do sistema; o um ator e um objeto ator gera um evento que dispara um mtodo do objeto; o dois objetos a mensagem mais comum. Um objeto envia uma mensagem para outro solicitando a execuo de um mtodo. Um objeto pode enviar mensagem para si mesmo (auto-chamada); o um objeto e um ator objeto envia mensagem de retorno em resposta a um mtodo solicitado. As mensagens so representadas por retas horizontais com uma seta na extremidade que aponta para o elemento que recebe a mensagem. As mensagens devem ser colocadas em ordem de temporalidade (na vertical) e devem ser numeradas (tambm obedecendo temporalidade). Os textos contidos nas mensagens seguem o seguinte formato: mensagem identificando o evento ocorrido, dois pontos e nome do mtodo disparado. Quando uma mensagem dispara um mtodo, a seta deve ser mais grossa.

Quando uma mensagem dirigida a um objeto que j existe, ao atingir a sua linha da vida, a mesma se torna mais grossa identificando que o Foco de Controle est sobre o objeto. Quando uma mensagem dirigida a um objeto que no existe, o mesmo deve ser criado atravs do aparecimento do retngulo que representa o objeto.

Uma mensagem tambm pode representar um mtodo destrutor. Neste caso, quando a mensagem atinge a linha da vida do objeto, a mesma interrompida por um X.

38

6. Mensagens de Retorno
Representadas por uma reta tracejada com uma seta fina apontando para o objeto ou ator que recebe a resposta. Podem retornar informaes especficas ou apenas um valor indicando se o mtodo foi executado com sucesso ou no.

7. Auto-chamadas ou delegaes
Mensagens que um objeto envia para si mesmo.

8. Condies ou Condies de Guarda

As Condies ou Condies de Guarda indicam que uma mensagem s pode ser enviada se uma condio for verdadeira. Normalmente so colocadas entre colchetes, mas podem aparecer no formato de restries.

As Condies de Guarda tambm podem representar o disparo de uma mensagem para vrios objetos, atravs da utilizao do smbolo asterisco (*), conhecido como Smbolo de Iterao. O asterisco deve ser posicionado antes da Condio de Guarda, que deve definir quantas vezes a mensagem deve ser disparada.

39

9. Exemplo: Abertura de uma Conta Comum

10. Exemplo: Encerramento de uma Conta Comum

40

11. Exemplo: Solicitao de Extrato atravs de Caixa Eletrnico

41

Diagrama de Colaborao (Comunicao na UML 2)

1. Introduo
Este diagrama muito parecido com o Diagrama de Seqncia, mostrando as mesmas informaes, mas com uma outra viso. Estes dois diagramas so conhecidos como Diagramas de Interao e complementam-se um ao outro. O Diagrama de Colaborao no est preocupado com a temporalidade e sim com a organizao estrutural dos objetos, em como os objetos esto vinculados e as mensagens que estes trocam entre si.

2. Objetos
So representados da mesma forma que no diagrama de seqncia, porm no possuem linha da vida ou foco de controle.

3. Vnculos
Um dos principais objetivos deste diagrama identificar os vnculos (ligaes) existentes entre os objetos de um processo, indicando que os mesmos colaboram entre si. Um vnculo representando por uma reta unindo dois objetos.

4. Mensagens
So as mesmas do Diagrama de Seqncia, geralmente representam chamadas de mtodos e so disparadas entre elementos do processo. A nica noo temporal deste diagrama a numerao das mensagens indicando a ordem em que elas ocorrem. A mensagem representada por uma seta que aponta para o receptor da mesma. No existem mensagens de retorno. Para que uma mensagem possa ser inserida no diagrama necessria a existncia de um vnculo. Um nico vnculo pode suportar vrias mensagens e no pode haver mais de um vnculo unindo dois objetos.

5. Atores
Os atores so os mesmos do Diagrama de Seqncia e so representados como no Diagrama de Casos de Uso (boneco magro com descrio abaixo). Possui vnculo com objetos ou outros atores, enviando e recebendo mensagens.

42

6. Condies
As condies podem ser inseridas da mesma forma que no Diagrama de Seqncia, isto , entre colchetes antes da mensagem. Indicam que uma mensagem s ser enviada se uma determinada condio for satisfeita.

7. Auto-chamadas
Objeto dispara mensagem para si prprio.

8. Exemplo: Abertura de uma Conta Comum

43

9. Exemplo: Encerramento de uma Conta Comum

10. Exemplo: Solicitao de Extrato atravs de Caixa Eletrnico

44

Diagrama de Grfico de Estados (Diagrama de Estados na UML 2)

1. Introduo
Representa uma Mquina de Estados. Este diagrama acompanha as mudanas de estado sofridas por um objeto dentro de um determinado processo. Geralmente est associado a objetos de uma classe. Pode haver diversos Diagramas de Estado em um processo, pois vrios objetos esto envolvidos.

2. Estado
Representa a situao que um objeto se encontra em um determinado momento. Transio a mudana de um estado para outro. Um estado pode demonstrar: o a espera pela ocorrncia de um evento; o a reao a um estmulo; o a execuo de alguma atividade; o a satisfao de alguma condio. Um estado representado por um retngulo com pontas arredondadas que pode ter duas ou trs divises: o a primeira diviso armazena a descrio do estado; o a segunda indica possveis aes ou atividades executadas pelo objeto quando estiver no estado. Seu preenchimento no obrigatrio; o a terceira define possveis transies internas. Uma transio interna no causa mudana de estado no objeto. uma diviso opcional.

Atividades e Aes so semelhantes: o Atividade possuem um tempo de execuo maior. Geralmente so mtodos executados pelo objeto. Uma atividade est sempre associada a um Estado. o Aes possuem um tempo de execuo mais curto. Por exemplo, uma atribuio de um valor a um atributo ou a gerao de uma sada. Uma ao est associada Transio. A segunda diviso pode armazenar trs clusulas diferentes: o Entry representa aes realizadas no momento em que o objeto entra no estado; o Exit identifica aes executadas antes de o objeto mudar de estado; o Do identifica aes executadas enquanto o objeto se encontra no estado.

Geralmente a descrio de um estado feita no gerndio, indicando que o objeto est realizando alguma atividade enquanto estiver naquele estado. Alguns estados estticos, como aqueles que esto aguardando eventos, no devem ser descritos no gerndio.

45

3. Transio
Uma transio representa a ocorrncia de um evento, conhecido como Evento de Ativao, que causa mudana de estado em um objeto. representada por uma reta com uma seta na extremidade apontando para o novo estado. As transies podem ter uma descrio, uma Condio de Guarda e parmetros.

No exemplo acima: o O primeiro estado faz a consulta da pessoa invocando o mtodo ConCPF(). o O segundo estado atualiza os dados da pessoa atravs do mtodo Gravar(). o A transio que possui a descrio Atualizar pessoa indica que aps terminar a tarefa Consultando Pessoa devemos iniciar a tarefa Atualizando Pessoa. o A Condio de Guarda [se necessrio] indica que a transio s ocorrer se a atualizao for necessria. Transies No-Ativadas so aquelas geradas pela simples concluso da atividade anterior. Transies Internas no causam mudana de estado e sero vistas mais adiante.

4. Estados Inicial e Final

O estado inicial, representado por um crculo preenchido, um estado abstrato cuja nica funo determinar onde o diagrama se inicia. O estado final, representado por um crculo preenchido envolvido por outro crculo, tambm um estado abstrato que determina onde o diagrama acaba.

5. Transies internas
No provocam mudana de estado. No exemplo a seguir, no estado Atualizando Pessoa, existe uma transio interna para validar o CPF. O mtodo ValCPF() invocado pelo mtodo Gravar().

46

6. Auto-Transies
So parecidas com as transies internas, porm saem do estado atual, podendo executar alguma ao durante a sada, e retornam para o mesmo estado. No exemplo a seguir, enquanto todos os itens no forem adquiridos de seus fornecedores, o diagrama permanece no estado Atendendo Pedido.

7. Exemplo: Encerramento de Conta Comum

8. Estado de Ponto de Escolha Dinmico

Indica um ponto em uma transio de estados em que uma deciso deve ser tomada. Representada por um crculo de onde partes duas ou mais transies.

47

9. Barra de sincronizao
Uma barra de sincronizao utilizada quando ocorrem estados paralelos causados por transies concorrentes. Determina o momento em que o processo passou a ser executado em paralelo e em quantos subprocessos se dividiu (evento conhecido como Bifurcao) ou determina o momento em que dois ou mais sub-processos se uniram (evento conhecido como Unio). Pode ser representada por uma barra grossa, preenchida, horizontal ou vertical. O ponto de juno representado por um smbolo idntico ao de estado inicial.

10. Estados Compostos

um estado que contm internamente dois ou mais estados (sub-estados). Utilizado para a anlise detalhada de um estado, facilitando a sua compreenso.

No exemplo acima: o o estado Atualizando Pessoa foi expandido; o a transio interna Validando CPF foi transformada em um estado independente; o criou-se um estado novo Gravando Pessoa para abrigar o mtodo Gravar(); o os estados Validando CPF e Gravando Pessoa formam um estado composto.

48

11. Exemplo: Diagrama de Estados com Barras de Sincronizao

12. Estados Concorrentes

um estado composto em que ocorrem estados paralelos, forando o processo a ser dividir em dois ou mais sub-processos concorrentes. Os processos concorrentes so separados por uma linha tracejada dentro de um estado concorrente. Pode servir de alternativa para as barra de sincronizao em alguns casos.

49

13. Estado de Sincronismo

Utilizado quando h necessidade de sincronismo entre processos paralelos. As vezes um processo pode precisar esperar pelo trmino de outro que est sendo executado em paralelo. representado por um asterisco dentro de um crculo.

No exemplo acima, quando o primeiro sinal de trnsito (parte superior) est no estado Sinal Aberto e recebe uma ordem para trocar de estado, ele gera duas transies: uma para mudar seu prprio estado para Sinal Fechado e outra para avisar o Estado de Sincronismo (*) para alterar o estado do segundo sinal.

14. Estado de Sub-Mquina

equivalente a um estado composto ou concorrente, porm seus sub-estados no so descritos no diagrama, pois so detalhados em outro diagrama. representado por um retngulo com os cantos arredondados contendo no canto inferior direito um smbolo que indica a existncia de estados internos.

50

Diagrama de Atividades
1. Introduo
Era considerado um caso especial do Diagrama de Grficos de Estado e tornou-se independente na UML 2. Baseia-se em Redes de Petri ao invs de Mquinas de Estado. o diagrama de maior nfase para a descrio de algoritmos, sendo muito parecido com os antigos fluxogramas. Este diagrama descreve os passos a serem percorridos para a concluso de um mtodo ou algoritmo especfico. No se preocupa com o processo completo, apenas com uma atividade. Utiliza os mesmos componentes dos Diagramas de Estado: estados inicial e final, transies e barras de sincronizao.

2. Estado de Ao
Representa a realizao de uma ao dentro de um fluxo de controle. No pode ser dividido em sub-estados, no possui aes internas e no pode ser interrompido. representado por um retngulo com bordas arredondadas com a descrio da ao. Essa descrio pode ser uma frmula, uma instruo em pseudocdigo ou at mesmo uma instruo em uma linguagem de programao.

3. Ponto de Deciso
Representa um ponto no fluxo de controle onde deve ser realizado um teste. representado por um losango de onde partem pelo menos duas transies. As transies geradas pelo ponto de deciso devem possuir Condies de Guarda que sero utilizadas para o teste. Dependendo do resultado do teste, uma das transies escolhida para dar prosseguimento ao fluxo.

O ponto de deciso tambm utilizado para unificar o fluxo.

51

4. Exemplo: Consulta de uma Conta

5. Exemplo: Clculo de Fatorial

52

6. Exemplo: Validao de CPF

53

7. Estado de Sub-Atividade
Representa um estado que pode ser dividido em sub-estados. Pode ser comparado a uma sub-rotina (do usurio ou de biblioteca). Possui um smbolo no canto inferior direito representando um Diagrama de Atividades.

8. Concorrncia Dinmica
Determina que um Estado de Ao pode se repetir vrias vezes. Utiliza-se o smbolo de multiplicidade (*) no final da descrio do estado.

9. Fluxo de Objetos
Representa o estado dos objetos envolvidos na atividade.

No exemplo acima, podemos ver dois fluxos de objetos: o o primeiro determina que o nmero da conta naquele momento 58247; o o segundo informa que o objeto conta1 est no estado Pesquisando Conta enquanto a atividade Pesquisar Conta est sendo realizada.

54

10. Envio e Recebimento de Sinal

Indicam a transmisso ou recebimento de um sinal de um dispositivo externo. So representados por um retngulo com a extremidade triangular (ver figura).

11. Raias de Natao

uma extenso do Diagrama de Atividades. Identifica os diversos setores, departamentos ou atores que interagem com um processo. So formadas por retngulos que identificam as zonas de influncia de um determinado setor sobre um determinado processo.

55

Diagramas de Componentes e Implantao

1. Diagrama de Componentes
Apresenta uma viso esttica de como o sistema ser implementado e quais os seus componentes (mdulos de software). Este diagrama est amplamente associado Linguagem de Programao utilizada na implementao do sistema. Determina os arquivos que comporo o software: mdulos, bibliotecas, formulrios, tabelas, documentos, arquivos de ajuda, etc. Pode ser utilizado para modelar os componentes do cdigo fonte do sistema, do cdigo executvel do software e dos bancos de dados fsicos. Pode ser utilizado para auxiliar no processo de Engenharia Reversa para modelagem e documentao de um sistema j desenvolvido.

1.1 Componentes Cada arquivo que compe o sistema um componente. representado por um retngulo com dois retngulos menores esquerda. Vrios esteretipos podem ser usados para identificar o tipo de componente: o executvel (executable) arquivos j compilados e link-editados; o biblioteca (library) conjunto de sub-rotinas da linguagem ou do sistema, arquivos de cabealho, etc.; o tabela (table) repositrios fsicos de dados; o documento (document) arquivos texto, arquivos de ajuda, etc.; o arquivo (file) qualquer outro tipo de arquivo, como arquivos fonte, por exemplo. O usurio pode criar esteretipos prprios.

1.2 Dependncia Indica que um componente depende de outro. Representada por uma linha tracejada com uma seta apontando para o componente do qual outro componente depende.

A dependncia tambm pode ser utilizada para identificar as classes (representadas por retngulos) que esto sendo implementadas ou manipuladas por um componente.

56

Outra maneira de mostrar as classes associadas a um componente e coloca-las dentro do mesmo.

Um relacionamento de dependncia tambm pode ter uma descrio. A figura abaixo utiliza o esteretipo <<ODBC>> para identificar o protocolo utilizado entre os componentes. A comunicao entre o Gerenciador de Contas e o Sistema Gerenciador de Bancos de Dados (SGBD) feita por meio do protocolo ODBC (Open DataBase Connectivity).

1.3 Exemplo Simples de Diagrama de Componentes

A figura acima ilustra um sistema desenvolvido utilizando o ambiente C++ Builder da Borland. Os arquivos cpp (cdigo fonte) dependem dos arquivos h (cabealhos) e dfm (formulrio). O cadastro de pessoas e contas dependem do menu. O projeto todo gerenciado pelo arquivo bpr que possui a funo WinMain.

1.4 Interface Representa um servio realizado por uma Classe ou por um Componente. No possui implementao ou especificao interna. Representada por um crculo que pode apresentar dois tipos de relacionamento com componentes: o Realizao (reta contnua) se o componente implementa alguma funo da interface; o Dependncia (reta tracejada com seta) se o componente utiliza a interface.

57

No exemplo anterior: o Interface a interface do sistema atravs da qual o usurio interage. do tipo <<boundary>> visto anteriormente; o Controlador interpreta os eventos gerados pela interface e repassa para outros mdulos (Gerenciador, por exemplo). do tipo <<control>> visto anteriormente. o Gerenciador processa os eventos gerados pela Interface e recebidos do Controlador.

1.4 Sub-Sistemas Podem ser representados por meio de Pacotes (retngulos com uma aba no canto superior esquerdo).

No exemplo acima: o o sistema foi dividido em dois sub-sistemas: Auto-Atendimento e Gerenciamento de Contas; o o sub-sistema Gerenciamento de Contas possui o mdulo Funcionrios, onde diversos funcionrios do banco tero que se logar para utilizar o sistema; o os mdulos Pessoas, Relatrios e Gerenciador de Contas possuem um relacionamento de dependncia com o mdulo Funcionrios, pois so utilizados a partir deste.

58

2. Diagrama de Implantao
Mostra a organizao da estrutura fsica sobre a qual o software ser implantado, isto , o hardware que suportar o sistema, suas conexes e protocolos.

2.1 Ns So os componentes bsicos do Diagrama de Implantao. Representa uma mquina onde um ou mais mdulos de software sero executados ou uma mquina que armazene arquivos consultados pelos mdulos do sistema. Ns sem nome so usados para designar equipamentos genricos e ns com nomes representam equipamentos especficos.

2.2 Associaes So ligaes fsicas entre os ns atravs das quais os equipamentos podem se comunicar e trocar informaes. As associaes tambm podem determinar a forma como a comunicao feita indicando, por exemplo, o protocolo utilizado.

2.3 Exemplo de Diagrama de Implantao

No exemplo acima: o os Caixas Eletrnicos se comunicam com o Servidor de Comunicao denominado Pegasus usando protocolo TCP/IP; o o Firewall (Kerberos) e responsvel por impedir a invaso de pessoas no autorizadas. Ele recebe o trfego do Servidor de Comunicao e repassa para o Servidor de Aplicao (Poseidon); o o Servidor de Aplicao o responsvel por executar os mdulos do sistema. Ele se comunica com o Servidor de Arquivos (Hera) onde esto armazenados os repositrio de dados gerenciados por algum SGBD.

59

3. Ns com Componentes
Os diagramas de Implantao e Componentes podem ser associados, identificando-se os componentes que so executados em cada n. Existem duas maneiras de fazer esta representao como podemos ver na figura abaixo.

4. Exemplo: Diagrama de Implantao junto com Diagrama de Componentes