UML

SETAS DE MENSAGENS - UML

Blocos de Construção da UML

O vocabulário da UML abrange três tipos de blocos de construção:

1) ItensSão abstrações identificadas como cidadãos de primeira classe em um modelo. Podem ser:       - Itens estruturais

São os substantivos, elementos conceituais ou físicos. Representam as partes estáticas do modelo, coletivamente chamados de classificadores. São as classes, interfaces, colaborações, casos de uso, classes ativas, componentes, artefatos e nós.        - Itens comportamentais

São as partes dinâmicas dos modelos UML. São os verbos, representando comportamentos no tempo e no espaço. São as interações, as máquinas de estados e as atividades.

        - Itens de agrupamento

São as partes organizacionais dos modelos UML. São os pacotes

         - Itens anotacionais

São as partes explicativas dos modelos UML. São as notas."

2) Relacionamentos- Associação

Relacionamento estrutural entre dois itens, que descreve um conjunto de conexões entre objetos. Ele pode ser, inclusive, de Agregação (entre o todo e suas partes).

- Dependencia Relacionamento semântico entre dois itens, nos quais a alteração de um pode

afetar a semântica do outro.- Generalização

Relacionamento de especialização/generalização, onde objetos “filhos” compartilham a estrutura e o comportamento dos objetos “pais”;

- RealizaçãoRelacionamento semântico entre classificadores em que um classificador

especifica um contrato que outro classificador garante executar.Realização (implementação): é uma relação entre uma interface e a classe

que a implementa, que provê os serviços definidos pela interface.

3) Diagramas  São todos os diagramas relacionados abaixo.

Os itens são as abstrações identificadas como cidadãos de primeira classe em um modelo; os relacionamentos reúnem esses itens; os diagramas agrupam coleções interessantes de itens;

A UML dispõe de regras semânticas para Visibilidade, Nomes, Escopo, Integridade e Execução

Nomes - Quais nomes podem ser atribuídos a itens, relacionamentos e diagramas.Escopo - O contexto que determina um significado específico para um nome.Visibilidade - Como esses nomes pode ser vistos e utilizados pelos outros.Integridade - Como os itens se relacionam entre si de forma adequada e consistente.Execução - O que significa executar ou simular um modelo dinâmico.

Fonte: BOOCH, el all. UML: Guia do Usuário

DIAGRAMAS UML

Diagramas são meios utilizados para a visualização dos blocos de construção da UML, utilizando representações gráficas de um conjunto de elementos que permitem visualizar o sistema sob diferentes perspectivas.

UML - Objetivos

Unified Modeling Language

Modelo - abstração(ou ainda simplificação) da realidade que auxilia a entender a problema.

1) Gerenciar a complexidade da construção de um sistema OO2) Ajuda a definir o Foco, Capturar, Documentar, Priorizar os principais aspectos.3) Mostra a semântica4) Independente do processo

Elementos da UMLDe estrutura:ClasseObjetosInterfaceComponenteColaboraçãoNóDe comportamento:

Casos de usoIteraçãoMáquina de estadosDe agrupamento:PacoteModeloSubsistema FrameworkDe anotação:Notas

A UML oferece três mecanismos para a extensão da sintaxe e da semântica da linguagem, são eles: Estereótipos; Valores atribuídos; Restrições.

Um valor atribuído estende as propriedades das novas construções criadas com estereótipos. É representado como uma particular projeção em elementos do conjunto que representa o estereótipo.

Os estereótipos são um dos três mecanismos de extensibilidade da UML. Eles dão mais poder à UML, permitindo classificar elementos "com algo em comum". Por exemplo, ao modelar uma rede pode ser necessário ter símbolos para representar roteadores e hubs. Ao fazer isso você estará estereotipando um elemento, visto que todos os hubs terão o mesmo simbolo.

As restrições permitem estender ou alterar a semântica natural de um elemento gráfico. Este mecanismo geral especifica restrições sobre um ou mais valores de um ou mais elementos de um modelo.

SETAS NA UML

UML - relações

Dependência: rel. de utilização, indica que os objs de uma classe usam serviços dos objs de outra classe.

Associação: rel. estrutural entre instancias especifica que objs de uma classe estão ligados objs de outras classes

Agregação: Associação onde o obj. parte é um att do todo; os objs partes pertencem ao todo ao qual estão agregados

Composição: rel. entre um elem.(o todo) e outros elem(as partes) onde as partes só podem pertencer ao todo e são criadas e destruídas com ele (tempo de vida controlado).

Associação Qualificada: Apresenta a Multiplicidade: ____*

Generalização: rel. entre elem mais geral e um + especif. Elem + especif. herda as props. e metodos do elem. + geral.

Refinamento: Relação que representa uma especificacão mais detalhado de algo que já foi especificado a um dado nível de detalhe. ----->

Esteriótipo: metatipo ou tipo que descreve um tipo. Serve para definir novos tipos de elementos. O seu nome deve ser representado entre os caracteres "<<" e ">>".Para um estereótipo pode ser definido:Propriedades; Semântica; Notação (Icones próprios);Classe base do metamodelo extendido.

PACOTES

Os pacotes proporcionam uma maneira de agrupar elementos UML relacionados criando, assim, um escopo dos seus nomes. Os diagramas de pacotes proporcionam uma ótima maneira para se visualizar dependências entre partes do sistema. Quase todos os elementos UML podem ser agrupados em pacotes, incluindo os próprios pacotes.Diagramas UML.

Uma vez que representa um agrupamento, um pacote é, em geral, dono de diversos elementos:

•Classes;• Interfaces;• Componentes;• Nós;• Colaborações;• Casos de uso.

DIAGRAMAS UML

Os diagramas utilizados pela UML são compostos de nove tipos: diagrama de use case, de classes, de objeto, de estado, de seqüência, de colaboração, de atividade, de componente e o de execução.(UML 1.5). Já na sua versão UML 2.0 temos as seguintes modificações:

Diagramas da UML 2.0Diagramas EstruturaisDiagrama de objetosDiagrama de classesDiagrama de componentesDiagrama de instalaçãoDiagrama de pacotesDiagrama de estrutura compostaDiagrama de Perfil(UML2.2)Diagramas ComportamentaisDiagrama de Caso de UsoDiagrama de transição de estadosDiagrama de atividadeDiagramas de InteraçãoDiagrama de sequênciaDiagrama de InteratividadeDiagrama de colaboração ou comunicaçãoDiagrama de tempo

Abordaremos agora cada um destes tipos de diagrama:

9.1. Diagrama Use-Case/Contexto

A modelagem de um diagrama use-case é uma técnica usada para descrever e definir os requisitos funcionais de um sistema. Eles são escritos em termos de atores externos, use-cases e o sistema modelado. Os atores representam o papel de uma entidade externa ao sistema como um usuário, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicação com o sistema através dos use-cases, onde o use-case representa uma seqüência de ações executadas pelo sistema e recebe do ator que lhe utiliza dados tangíveis de um tipo ou formato já conhecido, e o valor de resposta da execução de um use-case (conteúdo) também já é de um tipo conhecido, tudo isso é definido juntamente com o use-case através de texto de documentação. São diagramas feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, sendo especialmente úteis para determinar os recursos necessários que o sistema deve ter, mas não são adequados para representar o desenho e não podem descrever os mecanismos internos de um sistema

Atores e use-cases são classes. Um ator é conectado a um ou mais use-cases através de associações, e tanto atores quanto use-cases podem possuir relacionamentos de generalização que definem um comportamento comum de herança em superclasses especializadas em subclasses.

O diagrama de contexto ou caso de uso é uma forma de representar o objeto do estudo (projeto), com relação ao ambiente em que se insere. Uma definição para o Diagrama de Contexto seria: Um diagrama que mostra as entradas e saídas externas de uma organização / área funcional (em estudo: Compras) e os relacionamentos internos (produtos e serviços fornecidos por uma área funcional a outra).

Um diagrama de contexto ou caso de uso permite identificar os limites dos processos, as áreas envolvidas com o processo e os relacionamentos com outros processos e elementos externos à empresa (ex.: clientes, fornecedores)

O uso de use-cases em colaborações é muito importante, onde estas são a descrição de um contexto mostrando classes/objetos, seus relacionamentos e sua interação exemplificando como as classes/objetos interagem para executar uma atividade específica no sistema. Uma colaboração é descrita por diagramas de atividades e um diagrama de colaboração.

Quando um use-case é implementado, a responsabilidade de cada passo da execução deve ser associada às classes que participam da colaboração, tipicamente especificando as operações necessárias dentro destas classes juntamente com a definição de como elas irão interagir. Um cenário é uma instância de um use-case, ou de uma colaboração, mostrando o caminho específico de cada ação. Por isso, o cenário é um importante exemplo de um use-case ou de uma colaboração. Quando visto a nível de um use-case, apenas a interação entre o ator externo e o use-case é vista, mas já observando a nível de uma colaboração, toda as interações e passos da execução que implementam o sistema serão descritos e especificados.

O diagrama de use-cases acima demonstra as funções de um ator externo de um sistema de controle bancário de um banco fictício que foi modelado no estudo de caso no final deste trabalho. O diagrama especifica que funções o administrador do banco poderá desempenhar. Pode-se perceber que não existe nenhuma preocupação com a implementação de cada uma destas funções, já que este diagrama apenas se resume a determinar que funções deverão ser suportadas pelo sistema modelado.

Casos de uso - Relacionamentos permitidos:

Associação:GeneralizaçãoDependência: Extensão e Inclusão

Relacionamento de associação

* Indica que há uma interação (comunicação) entre um caso de uso e um ator;* Um ator pode se comunicar com vários casos de uso;

Relacionamento de generalização

Atores:

* Quando dois ou mais atores podem se comunicar com o mesmo conjunto de casos de uso;* Um filho (herdeiro) pode se comunicar com todos os casos de uso que seu pai se comunica.Casos de Uso:

* O caso de uso filho herda o comportamento e o significado do caso de uso pai;* O caso de uso filho pode incluir ou sobrescrever o comportamento do caso de uso pai;* O caso de uso filho pode substituir o caso de uso pai em qualquer lugar que ele apareça;

Relacionamento de dependência:

Extensão:

* Representa uma variação/extensão do comportamento do caso de uso base* O caso de uso estendido só é executado sob certas circunstâncias* Separa partes obrigatórias de partes opcionais* Partes obrigatórias: caso de uso base* Partes opcionais: caso de uso estendido* Fatorar comportamentos variantes do sistema (podendo reusar este comportamento em outros casos de uso)Inclusão:

* Evita repetição ao fatorar uma atividade comum a dois ou mais casos de uso* Um caso de uso pode incluir vários casos de uso

Relacionamento entre Casos de Uso

Inclusão - Possibilita a subdivisão de casos de uso, bem como evita a descrição de uma mesma sequência de interações. Permite agrupar funcionalidades comuns em um ponto único de utilização.

A Seta sai do caso de uso base e aponta para um caso de usoEX. 1)

Generalização - Pode existir entre dois casos de uso ou entre dois atores. Permite que tanto um caso de uso como um ator herdem características de outro mais genérico. O caso de uso ou ator herdeiro pode especializar o comportamento do caso de uso ou ator base. Utiliza o mesmo símbolo da herança de classes. UML também permite utilizar o conceito de entidade abstrata ao Caso de Uso - descrito em itálico.

Extensão - Não confundir com generalização. Utilizado para expressar diferentes sequências de interações entre casos de uso. Caminhos alternativos ou exceções. Cada uma das diferentes sequências representa um comportamento opcional, que só ocorre sob certas condições ou cuja realização depende da escolha do ator.

A Seta sai do caso de uso e aponta para um caso de uso base

Nesse caso, ao encerrar a conta temos dois casos excepcionais. Caso o usuário tenha dinheiro na conta ele deve fazer um saque. Caso o usuário tenha algum débito ele deve fazer um depósito.EX.2

9.2. Diagrama de Classes

O diagrama de classes demonstra a estrutura estática das classes de um sistema onde estas representam as "coisas" que são gerenciadas pela aplicação modelada. Classes podem se relacionar com outras através de diversas maneiras: associação (conectadas entre si), dependência (uma classe depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), ou em pacotes (classes agrupadas por características similares). Todos estes relacionamentos são mostrados no diagrama de classes juntamente com as suas estruturas internas, que são os atributos e operações. O diagrama de classes é considerado estático já que a estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, já que não são todas as classes que estão inseridas em um único diagrama e uma certa classes pode participar de vários diagramas de classes.Uma classe num diagrama pode ser diretamente implementada utilizando-se uma linguagem de programação orientada a objetos que tenha suporte direto para construção

de classes. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas e relacionadas entre si.

9.3. Diagrama de Objetos

O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma notação. Exibe um único conjunto de objetos relacionados uns com os outros em um determinado momento. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos é como se fosse o perfil do sistema em um certo momento de sua execução.Tem com função visualizar um conjunto de objetos e as suas relações num determinado instante de tempo.Diagrama de objeto é uma instância do diagrama de classe A mesma notação do diagrama de classes é utilizada com 2 exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como os diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema são mostrados.

9.3.0 Diagrama de PerfilO Diagrama de Perfil é um diagrama auxiliar que permite definir tipos padronizados de estereótipos, valores rotulados e restrições. A UML define o mecanismo de perfis como um “mecanismo leve de extensão” da linguagem, permitindo adaptar os modelos UML para diferentes plataformas e domínios.Na versão 2.2 da UML foi acrescentado o diagrama de perfil que é um diagrama estrutural, ou seja, mostra as características estáticas de um sistema. Esse diagrama representa mecanismos de extensibilidade, permitindo que metaclasses de metamodelos existentes sejam estendidos para se adaptar a diferentes propósitos, como, por exemplo, adaptar metamodelos UML a diferentes plataformas (como J2EE ou .NET) ou domínios (como sistemas de tempo real ou modelagem de processos de negócio). O diagrama de perfil() está de acordo com o OMG meta Object Facility (MOF).

9.3.1 Diagrama de Estrutura Composta (Composite structure Diagrams, Estrutura)

O diagrama de estrutura composta fornece meios de definir a estrutura de um elemento e de focalizá-la no detalhe, na construção e em relacionamentos internos. É um dos novos diagramas propostos na segunda versão de UML, voltado a detalhar elementos de

modelagem estrutural, como classes, pacotes e componentes, descrevendo sua estrutura interna.

O diagrama de estrutura composta introduz a noção de "porto" (tradução errada, o correto seria "Porta") (ports), um ponto de conexão do elemento modelado, a quem podem ser associadas interfaces. Também utiliza a noção de "colaboração", que consiste em um conjunto de elementos interligados através de seus portos para a execução de uma funcionalidade específica – recurso útil para a modelagem de padrões de projeto (SILVA, 2007).

* Este é o símbolo de componente amplamente conhecido na litetura.

9.4. Diagrama de Estado

Usado para modelagem de sistemas de tempo real. Descreve como um sistema responde aos estímulos internos e externos. Mostra as diferentes situações do sistema e os estímulos que provocam transições de uma para outra situação.O diagrama de estado é tipicamente um complemento para a descrição das classes. Este diagrama mostra todos os estados possíveis que objetos de uma certa classe podem se encontrar e mostra também quais são os eventos do sistemas que provocam tais mudanças. Os diagramas de estado não são escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um número definido de estados conhecidos e onde o comportamento das classes é afetado e modificado pelos diferentes estados.Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condições sendo satisfeitas) afetam estes estados ao passar do tempo.Diagramas de estado possuem um ponto de início e vários pontos de finalização. Um ponto de início (estado inicial) é mostrado como um círculo todo preenchido, e um ponto de finalização (estado final) é mostrado como um círculo em volta de um outro círculo menor preenchido. Um estado é mostrado como um retângulo com cantos arredondados. Entre os estados estão as transições, mostrados como uma linha com uma seta no final de um dos estados. A transição pode ser nomeada com o seu evento causador. Quando o evento acontece, a transição de um estado para outro é executada ou disparada.Uma transição de estado normalmente possui um evento ligado a ela. Se um evento é anexado a uma transição, esta será executada quando o evento ocorrer. Se uma transição não possuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do código do estado for executada (se existir ações internas como entrar, sair, fazer ou outras ações definidas pelo desenvolvedor). Então quando todas as ações forem executadas pelo estado, a transição será disparada e serão iniciadas as atividades do próximo estado no diagrama de estados.

9.5. Diagrama de Sequência

Um diagrama de seqüência mostra a colaboração dinâmica entre os vários objetos de um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a seqüência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, alguma coisa que acontecerá em um ponto específico da execução do sistema. No diagrama de sequência, linha de vida é uma linha tracejada vertical que representa o tempo de vida de um objeto. Foco de controle é um retângulo fino vertical sobreposto à linha de vida que mostra o período durante o qual um objeto está realizando uma ação. Os dois conceitos(linha de vida e foco de controle) não existem no diagrama de comunicação.Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadas entre esses objetos no caso de uso. O diagrama de seqüência consiste em um número de objetos mostrado em linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos que se relacionam. OS OBJETOS são representados na dimensão horizontal. Na dimensão vertical são representadas as linhas de vida dos objetos. No diagrama de sequência, os métodos das classes ( que em UML são conhecidos também por serviços, operações ou comportamentos) são chamados de mensagens.Diagramas de seqüência possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos na seqüência de uma certa atividade. Eles também mostram as interações para um cenário específico de uma certa atividade do sistema.No eixo horizontal estão os objetos envolvidos na seqüência. Cada um é representado por um retângulo de objeto (similar ao diagrama de objetos) e uma linha vertical

pontilhada chamada de linha de vida do objeto, indicando a execução do objeto durante a seqüência, como exemplo citamos: mensagens recebidas ou enviadas e ativação de objetos. A comunicação entre os objetos é representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem é síncrona, assíncrona ou simples. As mensagens podem possuir também números seqüenciais, eles são utilizados para tornar mais explícito as seqüência no diagrama.As linhas de vida compõem a dimensão vertical (tempo). A dimensão vertical é a sequência onde a vida do objeto durante a interação é representada. Usada em um diagrama de seqüência uma linha de vida do objeto representa a existência de um objeto em um determinado momento. Se o objeto for criado ou destruído durante o período de tempo que o diagrama representa, a linha da vida irá parar ou começar no ponto apropriado. A destruição de um objeto é marcada com um grande X.Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como ativação, mensagens assíncronas, ou objetos assíncronos.Os diagramas de sequência podem mostrar objetos que são criados ou destruídos como parte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos através de mensagens. A mensagem que cria ou destroi um objeto é geralmente síncrona, representada por uma seta sólida.

O diagrama de seqüência permite que decisões sejam tomadas durante o fluxoPara isso são utilizados quadros (frames) do tipo alt ou opt com condições de guarda.

A tag é alt, é a estrutura do operador de controle, sendo dividido em várias  sub-regiões, por linha horizontais tracejadas. Cada sub-região  representa um ramo de uma condicional. Sendo uma execução condicional.Lembrem de alt como alternativas (if x alternativa 1, eles if y alternativa 2)além de alt temos, loop para repetição, opt (opcional), break, par (paralelismo), region (região critica).

Operadores de controle estruturado nos diagramas de sequência

Alt – Execução condicional. Escolha entre dois ou mais comportamentos.

Opt – Execução Opcional. Escolha de comportamento onde este será ou não executado.

Par - Execução paralela de dois ou mais comportamentos.

Loop – Execução Iterativa. Laço que poderá ser repetido várias vezes.

Break - Quebra na execução normal do processo.

Critical Region - Indica que uma operação atômica não pode ser interrompida até ser concluída.

Esse são menos utilizados:

Neg - Eventos inválidos, que não devem ocorrer.

Assertion - Oposto ao neg, representa eventos válidos.

Ignore - As mensagens do fragmento devem ser ignoradas.

Consider - Mensagens devem ser desconsideradas.

Seq - situação onde ocorrência de eventos devem atender a outras propriedades.

Strict - Garante que todas as mensagens são ordenadas do início ao fim.

O Diagrama de tempo (Timing Diagram) incluído a partir da UML 2.0 apresenta o comportamento dos objetos e sua interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período.

9.5.5 O Diagrama de tempo (Timing Diagram)Incluído a partir da UML 2.0 apresenta o comportamento dos objetos e sua

interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período.

9.6. Diagrama de Colaboração ou Comunicação

Um diagrama de colaboração mostra de maneira semelhante ao diagrama de sequencia, a colaboração dinâmica entre os objetos. Normalmente pode-se escolher entre utilizar o diagrama de colaboração ou o diagrama de sequência.O diagrama de comunicação é voltado a descrever objetos interagindo e seus principais elementos sintáticos são “objeto” e “mensagem”. Mostra a estrutura dessa comunicação. Uma numeração da ordem das mensagens deve ser mostrada senão perdemos a informação de quem envia a mensagem p/ quem primeiro.No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, percebe-se também os objetos com os seus relacionamentos. A interação de mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de sequência, mas se a ênfase for o contexto do sistema, a ordem estrutural é melhor dar prioridade ao diagrama de Comunicação/Colaboração.O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As linhas cheias que ligam os objetos no diagrama de comunicação representam vínculos(links entre objetos, que se relacionam entre si estruturalmente) e as Setas representam as mensagens(seta de ponta vazada representa mensagem assíncrona). As mensagens são nomeadas, que entre outras coisas mostram a ordem em que as mensagens são enviadas. Também podem mostrar condições, interações, valores de resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que executam paralelamente com outros.

No Diagrama de Colaboração/Comunicação, um vínculo é representado por uma linha cheia entre dois objetos. A seta com ponta representa uma mensagem trocada entre esses objetos, conforme mostrado na imagem:

9.7. Diagrama de AtividadeDiagramas de atividade capturam ações e seus resultados. Eles focam o trabalho executado na implementação de uma operação (método), e suas atividades numa instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar ações (trabalho e atividades que serão executados) e seus resultados em termos das mudanças de estados dos objetos.Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é executada (sem ser necessário especificar nenhum evento como no diagrama de estado). Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como "swimlanes". Uma swimlane agrupa atividades, com respeito a quem é responsável e onde estas atividades residem na organização, e é representada por retângulos que englobam todos os objetos que estão ligados a ela (swimlane).

Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a possibilidade de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos), quando elas são executadas (sequência das ações), e onde elas acontecem (swimlanes).

O diagrama de atividades apresenta o fluxo de tarefas executadas sobre o processo, e neste caso, a utilização do recurso swinlanes (raias de natação) permitiria separar os diferentes departamentos que atuam no trâmite processual.Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:

Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este é o uso mais comum para o diagrama de atividade.

Para capturar o trabalho interno em um objeto. Para mostrar como um grupo de ações relacionadas podem ser executadas, e

como elas vão afetar os objetos em torno delas. Para mostrar como uma instância pode ser executada em termos de ações e

objetos. Para mostrar como um negócio funciona em termos de trabalhadores (atores),

fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no negócio).

O diagrama de atividade mostra o fluxo sequencial das atividades, é normalmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema. Consistem em estados de ação, que contém a especificação de uma atividade a ser desempenhada por uma operação do sistema. Decisões e condições, como execução paralela, também podem ser mostrados na diagrama de atividade. O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas.

No diagrama de atividades da UML há a presença de comportamento paralelo modelado através de forks e joins. Quando uma transição de entrada é acionada, há uma separação dos processos e todas as transições de saída são executadas em paralelo.Depois de cada separação e realização dos processos é necessário de efetuar a junção, ou seja, separação e junção devem se completar. Sendo assim, toda vez que você tiver uma separação, deve ter uma junção que una a threads iniciadas por aquela separação. Esta é a regra que a questão se refere.Existe uma exceção a essa regra, essa exceção chamada de thread condicional. A thread condicional prega que você ao sair de uma separação pode colocar uma condição para realização da thread.* a thread conditional é uma exceção pelo fato da sincronização ser dispensada (em relação a esta thread) no caso da condição de guarda que dispara a thread conditional não ser satisfeita. Ou seja, qdo a thread conditional não for executada. * tendo sido disparada a thread conditional, a sincronização na junção deverá ser observada sim.

9.8. Diagrama de Componente

O diagrama de componente e o de execução são diagramas que mostram o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos durante sua execução.O diagrama de componente descreve os componentes de software e suas dependências entre si, representando a estrutura do código gerado. Os componentes são a implementação na arquitetura física dos conceitos e da funcionalidade definidos na arquitetura lógica (classes, objetos e seus relacionamentos). Eles são tipicamente os

arquivos implementados no ambiente de desenvolvimento. Um componente é uma parte física e substituível de um sistema, que realiza um conjunto de interfaces.Um componente é mostrado em UML como um retângulo com uma elipse e dois retângulos menores do seu lado esquerdo. O nome do componente é escrito abaixo ou dentro de seu símbolo.Componentes são tipos, mas apenas componentes executáveis podem ter instâncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instâncias de componentes, deve ser usado um diagrama de execução, onde as instâncias executáveis são alocadas em nodes.A dependência entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definição completa. Com o diagrama de componentes é facilmente visível detectar que arquivos .dll são necessários para executar a aplicação.Componentes podem definir interfaces que são visíveis para outros componentes. As interfaces podem ser tanto definidas ao nível de codificação (como em Java) quanto em interfaces binárias usadas em run-time (como em OLE). Uma interface é mostrada como uma linha partindo do componente e com um círculo na outra extremidade. O nome é colocado junto do círculo no final da linha. Dependências entre componentes podem então apontar para a interface do componente que está sendo usada.Portas de componentes têm elementos representados por círculos e semicírculos

Interface fornecida ou realizada * Interface requerida ou usada.

Uma interface é uma coleção de operações utilizadas para especificar um serviço de uma classe ou de um componente.

Uma interface realizada por um componente é chamada de interface fornecida, em que o componente fornece um serviço para outros componentens. A interface utilizada pelo componente é chamada interface requerida, no qual o componente se adapta quando solicita serviços de outros componentes.O Componente que tem acesso aos serviços do outro componente por meio da interface é conectado a ela usando um relacionamento de dependência.

9.9. Diagrama de ExecuçãoO diagrama de execução mostra a arquitetura física do hardware e do software no sistema. Pode mostrar os atuais computadores e periféricos, juntamente com as conexões que eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses computadores e periféricos. Especifica-se também os componentes executáveis e objetos que são alocados para mostrar quais unidades de software são executados e em que destes computadores são executados.O diagrama de execução demonstra a arquitetura run-time de processadores, componentes físicos (devices), e de software que rodam no ambiente onde o sistema desenvolvido será utilizado. É a última descrição física da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade.O diagrama de execução é composto por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos físicos que fazem parte do sistema, podendo ser uma máquina cliente numa

LAN, uma máquina servidora, uma impressora, um roteador, etc., e conexões entre estes nodes e componentes que juntos compõem toda a arquitetura física do sistema.

9.10. Diagrama de Implantação

O diagrama de implantação representa a configuração e a arquitetura do sistema em que estarão ligados os respectivos componentes.

Neste diagrama também podemos representar toda a estrutura de hardware e requisitos mínimos onde o sistema será executado. O diagrama de instalação mostra o layout físico de um sistema, revelando quais partes do software serão executadas em quais partes do hardware.

Nós de processamento em tempo de execução e os artefatos que neles existem são representados graficamente por intermédio do diagrama de Implantação.Os itens principais do diagrama são nos conectados dos caminhos de comunicação. Um nó é algo que pode conter algum software.

Características 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 configuração dos equipamentos;

Este diagrama não é específico do desenvolvedor, mas em uma equipe onde existe o responsável pela implantação do sistema, este deve estar preocupado com o hardware e a configuração em que o sistema deverá ser executado e a compatibilidade entre os dois.

Algumas considerações sobre a UML

Um evento é uma entrada para um objeto, um tempo ou data  alcançada, uma notificação ou o início de um Processo de  Negócio. Este evento pode ser utilizado e transformado (por  exemplo, uma ordem de cliente) ou simplesmente age como um  catalisador (por exemplo, trabalho de grupo a noite).

Sequencia: comportamento do objeto em relação a outro.

Estado: comportamento do objeto em um dado momento da execução do sistema.

Casos de Uso: comportamento geral do sistema para o usuário final.

Maneira rápida de decorar os diagramas estruturais

C = classes

O = objetos

C = componentes

I = implantação

P = pacotes

E = Estrutura composta

"C O C I P E"

Assim, vc guarda essa palavra e o que não for estrutural é comportamental.

Restrições predefinidas pela UML:

Sobreposta/Overlapping; Disjunta;

Completa;

Incompleta