Curso UML Unipampa

Ministério da EducaçãoUniversidade Federal do Pampa

Unipampa – Campus Bagé

Linguagem UMLProf. MSc. Carlos Michel [email protected]

1 Modelagem e Projeto Baseados em ObjetosModelagem e Projeto Baseados em Objetos é um modo de estudar problemas com utilização de modelos

fundamentados em conceitos do mundo real. A estrutura básica é o objeto, que combina a estrutura e o comportamento dos dados em uma única entidade (o objeto) (Rumbaugh et. al., 1994).

O termo Orientação a Objetos (ou baseado em objetos) significa que o software é organizado como uma coleção de objetos separados (fracamente acoplados []) que incorporam tanto a estrutura quanto o comportamento dos dados. Isso contrasta com a programação convencional, segundo qual a estrutura e o comportamento dos dados têm pouca vinculação entre si (Rumbaugh et. al., 1994).

2 Princípios da Orientação a ObjetosOrientação a objetos é um termo desprovido de um significado inerente. O termo orientação a objetos não

possui um significado que seja um consenso na área e tem havido pouco consenso histórico sobre o conjunto de propriedades que a definam.

Alguns conceitos associados a Orientação a Objetos são apresentados por Page-Jones (PAG 2001).

1. Encapsulamento: é o agrupamento de idéias afins em uma unidade, conceito esse que pode então ser informado em uma só palavra. Na OO, o encapsulamento é o pacote de operações e atributos o qual representa o estado em um tipo de objetos, de tal forma que o estado é acessível somente pela interface provida pelo encapsulamento.

2. Ocultação de informações e implementações: é a utilização de encapsulamento para restringir a visibilidade externa de certos detalhes de informações ou implementações, os quais são internos à estrutura de encapsulamento.

3. Retenção de estado: habilidade de um objeto reter seu estado.4. Identidade de objeto: é a propriedade pela qual cada objeto (independente de sua classe ou de seu estado)

pode ser identificado e tratado como uma entidade distinta de software. OID (object identifier - identificador de objeto). Duas regras: (1) o mesmo identificador permanece com o objeto por toda sua vida; e (2) dois objetos nunca podem ter o mesmo identificador.

5. Mensagens: é o veículo pelo qual um objeto remetente obj1 transmite a um objeto destinatário obj2 um pedido para o obj2 aplicar um de seus métodos. Estruturas de Mensagens; Argumentos de mensagens; Papéis dos objetos em mensagens; Tipos de mensagens;

6. Classes: é o estêncil a partir do qual são criados (gerados) objetos. Cada objeto tem a mesma estrutura e comportamento da classe na qual ele teve origem. Se o objetos obj pertence à classe C, dizemos que "obj é uma instância de C". Operações de Instâncias de Objetos; Atributos de Instâncias de Objetos; Operações de Classe; Atributos de Classe.

7. Herança: A herança (de D a partir de C) é a habilidade que uma classe D tem implicitamente definida em cada um dos atributos e operações da classe C, como se esses atributos e operações tivessem sido definidos com base na própria classe D. C é caracterizada como uma superclasse de D. Em contrapartida, D é caracterizada como uma subclasse de C.

8. Polimorfismo: (a) Polimorfismo é a habilidade pela qual uma única operação ou nome de atributo pode ser definido em mais de uma classe a assumir implementações diferentes em cada uma dessas classes. (b) Polimorfismo é a propriedade por meio da qual um atributo ou variável pode apontar para (ou manter o identificador de) objetos de diferentes classes em horas diferentes. Ligação Dinâmica (dynamic binding): (ligação de run-time ou ligação tardia) é a técnica pela qual a exata linha de código a ser executada é determinada somente no run-time (diferentemente do que ocorre no compile-time). Redefinição (Overriding): é a redefinição de um método, definido em uma classe C, em uma das subclasses de C. Sobreposição(overloading): de um nome ou símbolo ocorre quando diversas operações (ou operadores), definidos na mesma classe, têm esse nome ou símbolo. Dizemos então que esse nome ou símbolo está sobreposto.

9. “Generalização”: é a construção de uma classe C de forma que uma ou mais das classes que ela utiliza internamente é fornecida somente em tempo de execução (run-time) (na hora em que um objeto da classe C é gerado). A generalização permite que uma classe parametrizada (classe genérica) tome uma classe como um argumento sempre que um objeto for gerado. Isso confere fácil criação de classes contêiner "genéricas" que servem como classes "esqueléticas", em que a específica "carne" pode ser acrescentada durante o run-time.

Rumbaugh et. al. (1994) apresentam como características da Orientação a Objetos os seguintes conceitos:1. Abstração: A abstração consiste na concentração nos aspectos essenciais, próprios, de uma entidade e em

ignorar suas propriedades acidentais. No desenvolvimento de sistemas, isso significa concentrar-se no que um objeto é e faz, antes de decidir como ele deve ser implementado. Uso de abstração preserva a liberdade de se tomar decisões


Unipampa – Campus Bagéevitando, tanto quanto possível, comprometimentos prematuros com detalhes, isto é, durante a análise lida-se apenas com conceitos do domínio de aplicação, e não se deve tomar decisões sobre o projeto e a implementação antes do problema ser compreendido (Rumbaugh et. al., 1994).

2. Encapsulamento (Ocultamento de informação): Consiste na separação dos aspectos externos de um objeto, acessíveis por outros objetos, dos detalhes internos da implementação daquele objeto, que ficam ocultos dos demais objetos. Este conceito impede que um programa se torne tão interdependente que uma pequena modificação possa causar grandes efeitos de propagação. A capacidade de combinar estrutura de dados e seu comportamento em uma única entidade torna o encapsulamento na OO mais poderoso do que em linguagens convencionais (Rumbaugh et. al., 1994). Encapsulamento é a capacidade de ocultar dados dentro dos modelos, permitindo que somente operações especializadas ou dedicadas manipulem os dados ocultos. O Encapsulamento é um dos benefícios mais palpáveis de programação orientada a objetos (Santos, 2003).

3. Compartilhamento: As técnicas OO promovem o compartilhamento em diversos níveis. A herança da estrutura de dados e seu comportamento permitem que a estrutura comum seja compartilhada por diversas subclasses semelhantes sem redundâncias. O compartilhamento de código, com utilização de herança, é uma das principais vantagens das linguagens baseadas em objetos (Rumbaugh et. al., 1994). A OO também permite a reutilização de modelos e códigos em projetos futuros (bibliotecas de componentes reutilizáveis).

4. Ênfase na Estrutura de Objetos e Não na Estrutura de Procedimentos: A OO preocupa-se em especificar o que um objeto é, e não em como ele é utilizado. Os usos de um objeto são altamente dependentes dos detalhes da aplicação e freqüentemente mudam durante o desenvolvimento. À medida que os requisitos evoluem, as características de um objeto permanecem, muito mais estáveis do que os modos como ele é utilizado, e, por causa disso, o software construído com base na estrutura de objetos são mais estáveis em longo prazo (Rumbaugh et. al., 1994).

2.1 Conceitos da Orientação a Objetos

2.1.1 Objetos e ClassesUm objeto é definido como um conceito, uma abstração, algo com limites nítidos e significado em relação ao

problema em causa (Rumbaugh et. al., 1994). Objetos servem a dois objetivos:1) facilitam a compreensão do mundo real2) oferecem uma base real para a implementação em computadorTodos objetos têm uma identidade e são distinguíveis.Um objeto ou instância é uma materialização da classe, e assim pode ser usado para representar dados e

executar operações. Para que objetos ou instâncias possam ser manipulados, é necessária a criação de referências a estes objetos, que são basicamente variáveis do "tipo" da classe (Santos, 2003).

2.1.2 ClassesUma classe de objetos descreve um grupo de objetos com propriedades semelhantes (atributos), o mesmo

comportamento (operações), os mesmo relacionamentos com outros objetos e a mesma semântica (Rumbaugh et. al., 1994).

Programadores que utilizam o paradigma de programação orientada a objetos criam e usam objetos a partir de classes, que são relacionadas diretamente com os modelos descritos anteriormente (Santos, 2003).

Classes são estruturas das linguagens de programação orientadas a objetos que pode conter, para determinado modelo, os dados que devem ser representados e as operações que devem ser efetuadas sobre estes dados. Cada classe deve ter um nome que seja facilmente associável ao modelo que a classe representa (Santos, 2003).

2.1.3 Atributos, Operações e MétodosUm atributo é um valor de dado guardado pelos objetos de uma classe (Rumbaugh et. al., 1994).Uma operação é uma função ou transformação que pode ser aplicada a objetos ou por estes a uma classe.

Todos os objetos de uma classe compartilham as mesmas operações (Rumbaugh et. al., 1994).Cada operação tem um objeto-alvo como argumento implícito. O comportamento da operação depende da

classe de seu alvo. Um objeto "sabe" qual é a sua classe, e, portanto, a correta implementação da operação.A mesma operação pode se aplicar a muitas classes diferentes. Uma operação assim dita ser polimórfica, isto é,

a mesma operação toma formas diferentes em classes diferentes. Um método é a implementação de uma operação para uma classe.

2.1.4 Ligações e AssociaçõesLigações e Associações são os meios para estabelecer-se relacionamentos entre objetos e classes (Rumbaugh

et. al., 1994).Uma ligação é uma conexão física ou conceitual entre instâncias de objetos (Joe Smith Trabalha-para a

empresa Simplex). Uma ligação é uma instância de uma associação.


Unipampa – Campus BagéUma associação descreve um grupo de ligações com estrutura e semântica comuns (uma pessoa Trabalha-

para uma empresa). As associações e ligações muitas vezes aparecem como verbos em enunciados de problemas. Uma associação descreve um conjunto de potenciais ligações da mesma maneira que uma classe descreve um conjunto de potenciais objetos. As associações muitas vezes são implementadas em linguagens de programação como ponteiros de um objeto para outro.

2.1.5 MultiplicidadeA multiplicidade especifica quantas instâncias de uma classe relacionam-se a uma única instância de uma

classe associada. A multiplicidade restringe a quantidade de objetos relacionados (Rumbaugh et. al., 1994).Exemplos de multiplicidade:

um-para-um (1 1)

um-para-muitos (1 *)

muitos-para-um (* 1)

zero ou um - para - ... (0..1 ...)

um ou mais - para - ... (1..* ...)

2.1.6 Atributos de LigaçãoUm Atributo de Ligação é uma propriedade das ligações de uma associação (Ex.: Classes "Arquivo" e

"Usuário" ligadas com uma associação, cujas ligações possuem um atributo "permissão de acesso") (Rumbaugh et. al., 1994). Associação como uma classe gera uma “Classe de Associação”.

2.1.7 Nomes de PapéisUm papel (role) é uma extremidade de uma associação. Uma associação binária tem dois papéis, cada um dos

quais pode ter um nome de papel. Nome de papel é um nome que identifica inequivocamente uma extremidade de uma associação ("Pessoa" - "Empresa" --> papéis "empregado" e "empregador") (Rumbaugh et. al., 1994).

2.1.8 OrdenaçãoHabitualmente os objetos do lado "muitos" de uma associação não têm uma ordem explícita, e podem ser

encarados como um conjunto. Às vezes, entretanto, os objetos são ordenados explicitamente. por exemplo, uma tela de uma estação de trabalho contendo algumas janelas que se sobrepõem. As janelas são explicitamente ordenadas, de modo que somente a janela de cima é visível de qualquer ponto da tela (Rumbaugh et. al., 1994). {ordered} ou {ordenado} no lado da associação "muitos" define que se tem um conjunto explicitamente ordenado.

2.1.9 QualificaçãoUma associação qualificada inter-relaciona duas classes de objetos e um qualificador. O qualificador é um

atributo especial que reduz a multiplicidade efetiva de uma associação. As associações um-para-muitos e muitos-para-muitos podem ser qualificadas. O qualificador faz distinções no conjunto de objetos na extremidade "muitos" de uma associação (uma forma de associação ternária) (Rumbaugh et. al., 1994).

Exemplo: Um diretório com muitos arquivos. Um arquivo só pode pertencer a um único diretório. Dentro do contexto de um diretório, um nome de arquivo especifica um único arquivo.Diretório e Arquivo são classes de objetos e nome de arquivo é o qualificador.

2.1.10 AgregaçãoAgregação é o relacionamento "parte-todo" ou "uma-parte-de" no qual objetos que representam os

componentes de alguma coisa são associados a um objeto que representa a estrutura inteira (Rumbaugh et. al., 1994).A agregação é uma forma estreitamente acoplada de associação com algumas questões semânticas a mais

(Transitividade, anti-simétrica). Agregação Multinivelada - Exemplo: Carro(Motor(Carburador, Filtros, Pistão, Cilindro, ..,), Rodas, Chassi,

...).

3 Desenvolvimento Iterativo e o Processo Unificado (Unified Process - UP)O Processo Unificado (UP) é um exemplo de processo iterativo para projetos usando Análise e Projeto

Orientados a Objetos (Larman, 2003).Informalmente, um processo de desenvolvimento de software descreve uma abordagem para construir,

implantar e manter software. O UP surgiu como um popular processo de desenvolvimento de software para construção de sistemas orientados a objetos. O Rational Unified Process (RUP) é um refinamento detalhado, e grandemente adotado, do Processo Unificado (UP).

O UP combina as melhores práticas, já normalmente aceitas, para construção de software. São elas:



Um ciclo de vida iterativo

Desenvolvimento dirigido por riscos

Descrição bem documentada e coesa.

A UML é amplamente independente do processo. Para tirar o máximo proveito da UML, é necessário considerar um processo com as seguintes características:

Orientado a caso de uso

Centrado na arquitetura

Iterativo e incremental

Orientado a caso de uso significa que esses casos são utilizados como o principal artefato para o estabelecimento do comportamento desejado do sistema, para a verificação e a validação da arquitetura do sistema, para a realização de testes e para a comunicação entre os participantes do projeto.

Centrado na arquitetura significa que a arquitetura do sistema é utilizada como principal artefato para a conceituação, a construção, o gerenciamento e a evolução do sistema em desenvolvimento.

Um processo Iterativo é aquele que envolve o gerenciamento de seqüências de versões executáveis. Um processo Incremental é aquele que envolve a integração contínua da arquitetura do sistema para a produção dessas versões, de maneira que cada nova versão incorpora os aprimoramentos incrementais em relação às demais. Em conjunto, um processo iterativo e incremental é orientado a riscos, ou seja, cada nova versão tem como foco atacar e reduzir os riscos mais significativos para o sucesso do projeto.

3.1 Desenvolvimento IterativoNesta abordagem, o desenvolvimento é organizado em uma série de mini-projetos, curtos e de tamanho fixo

("Timeboxed" - Iterações de tamanho fixo), chamadas iterações (Larman, 2003).A saída de cada iteração é um sistema testado, integrado e executável. Cada iteração inclui suas próprias

atividades de análise de requisitos, projeto (design), implementação e teste.O ciclo de vida iterativo é baseado em um crescimento e refinamento de um sistema através de múltiplas

iterações, com uma realimentação e adaptação como diretivas básicas para convergir para o sistema desejado. O sistema cresce incrementalmente, iteração a iteração. Esta abordagem é denominada como Desenvolvimento Iterativo e Incremental (Modelos iterativos anteriores são: Desenvolvimento Espiral e Desenvolvimento Evolucionário).

O resultado de cada iteração é um sistema executável, mas incompleto, não pronto para a entrega (e não o estará até as primeiras 10 (ou mais) iterações, no caso de sistemas maiores e mais complexos) (Larman, 2003). A saída de uma iteração não é um sistema experimental ou um protótipo. É um sistema que contempla um subconjunto dos requisitos do sistema.

O UP não tenta "congelar" os requisitos antes de iniciar a implementação. Este processo permite que os interessados no sistema (stakeholders) possam tornar suas "visões" sobre o sistema mais claras e adaptadas para as mudanças do mercado. O UP faz um balanço entre a necessidade de estabilizar um conjunto de requisitos básicos e a realidade das mudanças de requisitos impostas pelo mercado.

Cada iteração "ataca" um pequeno conjunto de requisitos e, rapidamente, são realizados um projeto (design), implementação e testes.

Além da melhor definição dos requisitos (através dos usuários) em cada iteração, atividades como testes de carga irão provar se o projeto e implementação parciais estão no caminho correto, ou se na próxima iteração será necessária uma modificação na arquitetura básica do software (sistema).

Iterações iniciais podem estar "longe" do "verdadeiro caminho" do sistema. Através da realimentação (avaliação) e adaptação, o sistema converge em direção aos requisitos e projeto mais apropriados.

3.2 Benefícios do Desenvolvimento IterativoAlguns dos benefícios do Desenvolvimento Iterativo são os seguintes (Larman, 2003):

Redução, mais cedo, dos mais altos riscos (técnicos, de requisitos, objetivos, usabilidade, etc.)

Progresso visível mais cedo

Retorno (avaliação), mais cedo, dos interessados no sistema, engajamento dos usuários e adaptação; levando a um sistema refinado que contempla melhor (mais próximo) as reais necessidades dos stakeholders.

Gerenciamento da complexidade. O grupo de desenvolvimento não fica "estupefado" pela "paralisia da análise" ou passos muito complexos e longos.

O aprendizado dentro de cada iteração pode ser metodicamente utilizado para melhorar o processo de desenvolvimento em si, iteração a iteração.


Unipampa – Campus BagéO UP (e desenvolvedores iterativos experientes) recomenda que o tamanho de iteração deve ser entre 2 e 6

semanas (para grandes grupos de desenvolvimento não mais do que 6 meses - devido ao tempo excedente necessário para a comunicação e coordenação).

Passos pequenos, realimentação rápida e adaptação são as idéias centrais do desenvolvimento iterativo.

3.3 Melhores Práticas e Conceitos Adicionais do UPOutra idéia central do UP é o uso de tecnologia de objetos, incluindo Análise e Projeto Orientados a objetos e

Programação Orientada a Objetos (Larman, 2003). Algumas “dicas” para uso do UP:

Evitar assuntos de alto risco e alto valor nas iterações iniciais

Engajar os usuários continuamente para avaliação, realimentação (feedback) e requisitos

Construir um núcleo arquitetural coeso nas iterações iniciais

Verificar a qualidade continuamente; testar cedo, freqüentemente, e realisticamente

Aplicar Casos de Uso (use cases)

Modelar o software visualmente (com a UML)

Gerir os requisitos cuidadosamente

Gerir requisições de mudança e configuração de software

3.4 Fases do UPO processo UP pode ser desmembrado em fases. Uma fase é o intervalo de tempo decorrido entre dois

importantes pontos marcos do processo (milestones), quando um conjunto bem-definido de objetivos é alcançado, os artefatos são concluídos e decisões são tomadas para se passar à fase seguinte.

Um projeto UP organiza o trabalho e iterações através de quatro fases (Booch, Rumbaugh e Jacobson, 2000) (Larman, 2003):

1. Concepção (Inception): visão aproximada, caso de negócio, escopo, estimativas iniciais. É um tipo de fase de possibilidade de execução do projeto (exeqüibilidade). Uma investigação adequada é realizada para suportar uma decisão de continuar ou não o projeto;

2. Elaboração (Elaboração): visão refinada, implementação iterativa do núcleo arquitetural, resolução dos riscos mais elevados, identificação da maioria dos requisitos e escopo e estimativas mais realísticas.

3. Construção (Construction): implementação iterativa do restante dos riscos menos elevados e elementos mais fáceis e preparação para a implantação (deployment).

4. Transição (Transition): testes beta, implantação.

A Concepção é a primeira fase do processo, em que a idéia inicial para o desenvolvimento é levada até o ponto de ser suficientemente bem-fundamentada para assegurar a passagem à fase de elaboração

A Elaboração é a segunda fase do processo, quando a visão do produto e sua arquitetura são definidas. É uma fase onde o núcleo da arquitetura é implementado iterativamente e os riscos mais elevados são amenizados. Nesta fase os requisitos do sistema são articulados e são definidos as prioridades e o baseline. Os requisitos do sistema podem abranger desde declarações de caráter geral até critérios precisos de avaliação, em que cada requisito especifica determinado comportamento funcional ou não-funcional e proporciona uma base para a realização de testes.

A Construção é a terceira fase do processo, em que o software chega a uma arquitetura baseline executável e destinada à transferência para a comunidade de usuários. Também aqui os requisitos do sistema e principalmente seus critérios de avaliação são constantemente reexaminados em relação às necessidades comerciais do projeto e os recursos são alocados de modo adequado a atacar ativamente os riscos ao projeto.

A Transição é a quarta fase do processo, em que o software chega às mãos da comunidade de usuários. Raramente o processo de desenvolvimento do software termina aqui, pois, até durante essa fase, o sistema é aprimorado continuamente, bugs são eliminados e são acrescentadas novas características.

O único elemento que diferencia esse processo e que está presente e todas as quatro fases é uma iteração. Uma iteração é um conjunto distinto de atividades, com um plano básico e critérios de avaliação que resultam em uma versão, interna ou externa. isso significa que o ciclo de vida de desenvolvimento de um software pode ser caracterizado como um fluxo contínuo de evolução de versões executáveis da arquitetura do sistema. É a ênfase na arquitetura como um artefato importante que orienta a UML para o foco na modelagem das diferentes visões da arquitetura de um sistema.

Um ciclo de desenvolvimento (o qual encerra-se com a entrega de uma versão do sistema para produção) é composto de muitas iterações (Larman, 2003).



Figura 1 - Termos orientados pelo calendário no UP (Fases do UP) (Larman, 2003)

3.4.1 As disciplinas do UP (originalmente chamadas de workflows)O UP descreve atividades de trabalho, como escrever um caso de uso, dentro de disciplinas (Larman, 2003).Uma disciplina é um conjunto de atividades (e artefatos relacionados) em uma área específica, tais como as

atividades dentro da análise de requisitos.Artefato é um termo geral para qualquer produto de trabalho: código-fonte, código, gráficos Web, esquema de

banco de dados (database schema), documento de texto, diagramas, modelos, etc.Existem várias disciplinas no UP:

Modelagem de Negócios - quando desenvolvendo uma aplicação única, este inclui a modelagem de objetos do domínio. Quando engajado em análise de negócio em grande escala ou reengenharia de processos de negócio, este inclui modelagem dinâmica dos processos de negócios em toda a organização.

Requisitos - análise de requisitos para uma aplicação, tais como construir casos de uso e identificar requisitos não-funcionais.

Projeto (Design) - todos aspectos de projeto, incluindo arquitetura do sistema, objetos, banco de dados, rede de comunicação, etc.

No UP, implementação significa programação e construção do sistema, não implantação. A disciplina de Ambiente refere-se a estabelecer as ferramentas e adaptar o processo para o projeto.

Uma percepção/lição aprendida (insight) do UP é que todas as atividades e artefatos são opcionais (talvez não o código). O grupo de desenvolvimento deveria selecionar um pequeno conjunto de artefatos que abordam problemas e necessidades em particular (um pequeno conjunto de artefatos que demonstram ter um alto valor prático)

A escolha dos artefatos para um projeto pode ser escrita em um curto documento chamado "Caso de Desenvolvimento" (Development Case - um artefato da disciplina de Ambiente).

Tabela 1 - Exemplo de "Caso de Desenvolvimento" dos Artefatos do UP (Larman, 2003)

Legenda: I - Iniciar; R - Refinar

Disciplina ArtefatoIteração

ConcepçãoI1

ElaboraçãoE1 .. En

ConstruçãoC1 .. Cn

TransiçãoT1 .. T2

Modelagem de Negócios Modelo de Domínio IRequisitos Modelo de Caso de Uso I R

Visão I REspecificação Suplementar I RGlossário I R

Projeto Modelo de Projeto I RDocumento de Arquitetura de Software

I

Modelo de Dados I R

Concepção Construção Transição

ciclo de desenvolvimento

iteração fase

Elaboração

Marco( Milestone )

Versão( r elease )

Versão deProdução Final

( release )

Um ponto finalda iteraçãoquando algumadecisãosignificante ouavaliaçãoocorre

Um subconjuntoexecutável eestável doproduto final. Of inal de cadaiteração é umaversãosecundária( minor release )

Neste ponto, osistema éliberado para usoem produção

Incremento

A diferença(delta) entreos releasesde 2 iteraçõessubseqüentes


Unipampa – Campus BagéImplementação Modelo de Implementação I R RGerenciamento de Projeto Plano de Desenvolvimento de

SoftwareI R R R

Teste Modelo de Teste I RAmbiente Caso de Desenvolvimento I R

3.5 O UP ÁgilO UP foi construído para ser considerado um processo leve (Larman, 2003).

Processos pesados vs. leves (heavy vs. light)

Processos preditivos vs. adaptativos (predictive vs. adaptive)

Processo pesado:- muitos artefatos criados em uma atmosfera burocrática- rigidez e controle- planejamento elaborado, de longo prazo e elaborado- preditivo ao invés de adaptativo

Processo Preditivo prever as atividades e recursos necessários (planejar em detalhe) - ciclo de vida seqüencial

Processo Adaptativo aceita modificações e encoraja adaptações. Ciclo de vida iterativo

Um Processo Ágil implica em um processo leve e adaptativo, hábil em resposta às necessidades de mudança.Para aplicar o UP Ágil:

Preferir um pequeno conjunto de atividades e artefatos do UP

Desde que o UP é iterativo, requisitos e projeto (design) não estão completos antes da implementação

Não existe um plano detalhado para o projeto inteiro. Existe um plano de alto nível (Plano de Fase) que estima o final do projeto e outros marcos (milestones) principais, mas não detalha os passos em granulação fina para obter estes marcos. Um plano detalhado (Plano de Iteração) planeja somente em maior detalhe uma iteração adiante.

3.6 ArquiteturaVisualizar, especificar, construir e documentar sistemas complexos de software são tarefas que requerem a

visualização desses sistemas sob várias perspectivas. Cada participante no processo de desenvolvimento de software traz contribuições ao projeto e observa o sistema de maneira distinta em momentos diferentes.

A Arquitetura do sistema talvez seja o artefato mais importante a ser utilizado com o objetivo de gerenciar esses diferentes pontos de vista e, assim, tornar possível um controle do desenvolvimento iterativo e incremental de um sistema durante seu ciclo de vida.

A Arquitetura é o conjunto de decisões significativas acerca dos seguintes itens:

A organização do sistema de software

A seleção dos elementos estruturais e suas interfaces, que compõem o sistema

Seu comportamento, conforme especificado nas colaborações entre esses elementos

A composição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores

O estilo de arquitetura que orienta a organização: os elementos estáticos e dinâmicos e suas respectivas interfaces, colaborações e composição.

A arquitetura de software não está apenas relacionada à estrutura e ao comportamento, mas também ao uso, à funcionalidade, ao desempenho, à flexibilidade, à reutilização, à abrangência, a adequações e a restrições de caráter econômico e tecnológico, além de questões estéticas.

A arquitetura pode ser descrita por cinco visões interligadas:

1. A Visão do Caso de Uso abrange os casos de uso que descrevem o comportamento do sistema conforme é visto pelos usuários finais, analistas e pessoal de teste.

Aspectos estáticos - Diagramas de Caso de UsoAspectos dinâmicos - diagramas de interação, de estados e de atividades

2. A Visão de Projeto de um sistema abrange as classes, interfaces e colaborações que formam o vocabulário do problema e de sua solução (perspectiva de suporte aos requisitos funcionais)

Aspectos estáticos - Diagramas de Classes e de objetos


Unipampa – Campus BagéAspectos dinâmicos - diagramas de interação, de estados e de atividades

3. A Visão de Processo abrange os threads e os processos que formam os mecanismos de concorrência e de sincronização do sistema (perspectiva referente ao desempenho, à escalabilidade e ao throughput do sistema)

Aspectos estáticos - Diagramas de Classes (foco para classes ativas)Aspectos dinâmicos - diagramas de interação, de estados e de atividades

4. A Visão de Implementação de um sistema abrange os componentes e os arquivos utilizados para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o gerenciamento da configuração das versões do sistema, compostas por componentes e arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para a produção de um sistema executável.

Aspectos estáticos - Diagramas de ComponentesAspectos dinâmicos - diagramas de interação, de estados e de atividades

5. A Visão de Implantação de um sistema abrange os nós que formam a topologia de hardware em que o sistema é executado. Esta visão direciona principalmente a distribuição, o fornecimento e a instalação das partes que constituem o sistema físico.

Aspectos estáticos - Diagramas de ImplantaçãoAspectos dinâmicos - diagramas de interação, de estados e de atividades

Estas visões também interagem entre si: os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez, representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões de projeto e de processo.

3.7 Camadas ArquiteturaisUm típico sistema de informação orientado a objetos é projetado em termos de várias camadas ou subsistemas

arquiteturais (Larman, 2003). Por exemplo:

Interface com o Usuário - interface gráfica (Janelas)

Lógica da Aplicação e Objetos do Domínio - objetos de software representando conceitos do domínio que contemplam os requisitos da aplicação.

Serviços Técnicos - objetos de propósito geral a subsistemas que fornecem serviços técnicos de suporte, tais como: interface com um banco de dados ou log´s de erros.

Análise e Projeto (Analysis and Design) são, geralmente, mais relevantes para a modelagem da lógica da aplicação e das camadas de serviços técnicos.

4 UML - Linguagem de Modelagem Unificada - Unified Modeling Language

Praticamente todo o texto abordando a UML – seus elementos, diagramas, mecanismos, etc. – é baseado no livro “UML: guia do usuário”, de autoria do Grady Booch, James Rumbaugh e Ivar Jacobson (os “três amigos”) (Booch, Rumbaugh e Jacobson, 2000). Qualquer utilização de outra referência bibliográfica será indicada explicitamente.

A UML é uma linguagem-padrão para a elaboração da estrutura de projetos. Pode ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software. Adequada para a modelagem de sistemas:

- Sistemas de Informação Corporativos- Sistemas baseados na Web- Sistemas de Tempo Real, etc.

Possui três elementos principais:1) Blocos básicos de construção da UML2) Regras que determinam como estes blocos deverão ser combinados3) Mecanismos básicos que se aplicam a toda a linguagem

A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para desenvolvimento de software. A UML é independente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental.

A UML é destinada a:

Visualizar (notação com semântica bem-definida)

Especificar (definir modelos precisos, sem ambigüidades e completos)



Construir (modelos podem ser mapeados para linguagens de programação e tabelas de BD (Relacionais ou OO). É possível a execução direta dos modelos, a simulação e a instrumentação de sistemas em execução)

Documentar (construção de artefatos críticos para controlar, medir e comunicar determinado sistema durante seu desenvolvimento e após sua implantação)

os artefatos de um sistema complexo (ou não) de software.

A UML é uma linguagem, e como tal, fornece um vocabulário e as regras para a combinação de palavras desse vocabulário com a finalidade de comunicar algo.

O vocabulário e as regras de uma linguagem como a UML indicam como criar e ler modelos bem formados, mas não apontam quais modelos deverão ser criados, nem quando deverão ser criados. Essa tarefa cabe ao processo de desenvolvimento de software. Um processo bem-definido servirá como guia para decidir quais artefatos serão produzidos, quais atividades e trabalhadores serão escolhidos para criá-los e gerenciá-los e como esses artefatos serão empregados para medir e controlar o projeto como um todo.

A UML pode ser empregada para a modelagem de sistemas em vários domínios:

Sistemas de informações corporativos, Serviços bancários e financeiros, Telecomunicações, Transportes, Defesa/espaço aéreo, Vendas de varejo, Eletrônico médica, Científicos, Serviços distribuídos baseados na Web, etc.

4.1 Um modelo conceitual da UMLPara compreensão da UML, é necessário o entendimento dos seus três elementos principais.

4.1.1 Blocos básicos de construção da UMLExistem três tipos de blocos de construção:1. Itens2. Relacionamentos3. Diagramas

Itens da UMLQuatro tipos:1. Itens estruturais2. Itens comportamentais3. Itens de agrupamentos4. Itens anotacionais

Itens EstruturaisOs itens estruturais são os substantivos utilizados em modelos da UML. São as partes estáticas do modelo,

representando elementos conceituais ou físicos.Existem sete tipos de itens estruturais:

As classes são descrições como conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.

Uma Interface é uma coleção de operações que especificam serviços de uma classe ou componente. Descreve o comportamento externamente visível desse elemento. Pode representar todo, ou parte, o comportamento de uma classe ou componente. Define um conjunto de especificações de operações (suas assinaturas), mas nunca um conjunto de implementações de operações. Uma interface costuma aparecer anexada à classe ou ao componente que realiza a interface.

As colaborações definem interações e são sociedades de papéis e outros elementos que funcionam em conjunto para proporcionar um comportamento cooperativo superior à soma de todos os elementos. Possuem dimensões estruturais, assim como comportamentais. Uma classe pode participar em várias colaborações.

Um caso de uso é a descrição de um conjunto de seqüência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. É utilizado para estruturar o comportamento de itens em um modelo. Um caso de uso é realizado por uma colaboração.

Os três tipos de itens restantes - classes ativas, componentes e nós - são semelhantes a classes, porém, estes são suficientemente diferentes e necessários para a modelagem de certos aspectos de sistemas orientados a objetos e, portanto, merecem um tratamento especial.

Os cinco primeiros tipos de itens são itens conceituais ou lógicos. Os dois últimos (componentes e nós) representam itens físicos.



As classes ativas são classes cujos objetos têm um ou mais processos ou threads e, portanto, podem iniciar a atividade de controle. Uma classe ativa é semelhante a uma classe, exceto pelo fato de que seus objetos representam elementos cujo comportamento é concorrente com o de outros elementos.

Os componentes são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces. Em um sistema, encontram-se deferentes tipos de componentes próprios da implantação, como os componentes COM+ ou Java Beans, assim como componentes que são artefatos do processo de desenvolvimento, como arquivos de código-fonte. Tipicamente os componentes representam o pacote físico de elementos lógicos diferentes, como classes, interfaces e colaborações.

Um nó é um elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, freqüentemente, capacidade de processamento. Um conjunto de componentes poderá estar contido em um nó e também poderá migrar de um nó para outro.

Além desses sete tipos de itens estruturais, existem, também, variações desses, como: atores, sinais e utilitários (tipos de classes), processos e threads (tipos de classes ativas), e aplicações, documentos, arquivos, bibliotecas, páginas e tabelas (tipos de componentes).

Itens comportamentaisSão as partes dinâmicas dos modelos UML. São os verbos de um modelo, representando comportamentos no

tempo e no espaço.Existem dois tipos de itens comportamentais:

Uma interação é um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para a realização de propósitos específicos. O comportamento de uma sociedade de objetos ou de uma operação individual poderá ser especificado por meio de uma interação. As interações envolvem outros elementos, inclusive mensagens, seqüências de ações (os comportamentos chamados pelas mensagens) e ligações (as conexões entre os objetos).

Uma máquina de estado é um comportamento que especifica as seqüências de estados pelas quais objetos ou interações passam durante sua existência em resposta a eventos, bem como suas respostas a esses eventos. Uma máquina de estado abrange outros elementos, incluindo estados, transições (o fluxo de um estado a outro), eventos (itens que disparam uma transição) e atividades (as respostas às transições)

Itens de agrupamentosSão as partes organizacionais dos modelos UML. São os blocos em que os modelos podem ser decompostos.

Existe apenas um tipo de itens de agrupamento, chamado Pacote.Um pacote é um mecanismo de propósito geral para a organização de elementos em grupos. Os itens

estruturais, os itens comportamentais e até outros itens de grupos podem ser colocados em pacotes. Ao contrário dos componentes (que existem em tempo de execução), um pacote é puramente conceitual (existem apenas em tempo de desenvolvimento).

Existem algumas variações, como frameworks, modelos e subsistemas (tipos de pacotes).

Itens anotacionaisSão as partes explicativas dos modelos UML. São comentários, incluídos para descrever, esclarecer e fazer

alguma observação sobre qualquer elemento do modelo. Existe somente um tipo de item anotacional, chamado nota. Uma nota é apenas um símbolo para representar restrições e comentários anexados a um elemento ou a uma coleção de elementos.

4.2 Relacionamentos na UMLQuatro tipos de relacionamentos:1. Dependência - é um relacionamento semântico entre dois itens, nos quais a alteração de um (o item

independente) pode afetar a semântica do outro (o item dependente).2. Associação - é um relacionamento estrutural que descreve um conjunto de ligações, em que as ligações

são conexões entre objetos. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes. A composição é um tipo especial de agregação.

3. Generalização - é um relacionamento de especialização/generalização, nos quais os objetos dos elementos especializados (os filhos) são substituíveis por objetos de elemento generalizado (os pais). Dessa maneira, os filhos compartilham a estrutura e o comportamento dos pais.

4. Realização - é um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar. Os relacionamentos de realizações serão encontrados em dois locais: entre interfaces e as classes ou componentes que as realizam; e entre casos de uso e as colaborações que os realizam.



4.3 Diagramas na UMLUm diagrama é a apresentação gráfica de um conjunto de elementos. Geralmente representada como gráficos

de vértices (itens) e arcos (relacionamentos). Os diagramas são desenhados para permitir a visualização de um sistema sob diferentes perspectivas.

Um diagrama, ao menos talvez para sistemas triviais, representa uma visão parcial dos elementos que compõem o sistema.

Um mesmo elemento pode aparecer em todos os diagramas, em apenas alguns ou em nenhum diagrama. Na teoria, um diagrama pode conter qualquer combinação de itens e de relacionamentos. Na prática, porém, aparecerá um pequeno número de combinações comuns, que são consistentes com as cinco visões mais úteis da arquitetura de um sistema complexo de software (abordadas adiante).

A UML inclui nove diagramas:1. Diagrama de classes - exibe um conjunto de classes, interfaces e colaborações, bem como seus

relacionamentos. Maior freqüência em sistemas de modelagem orientados a objeto. Abrangem uma visão estática do sistema.

2. Diagrama de objetos - exibe um conjunto de objetos e seus relacionamentos. Representa "retratos" estáticos de instâncias de itens encontrados em diagramas de classes. Também abrangem uma visão estática, mas sob perspectiva de casos reais ou de protótipos.

3. Diagrama de casos de uso - exibe um conjunto de casos de uso e atores (um tipo especial de classe) e seus relacionamentos. Abrangem a visão estática de casos de uso do sistema

Tanto diagramas de seqüências como os de colaborações são tipos de diagramas de interações. Um diagrama de interação exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Este tipo de diagrama abrange uma visão dinâmica de um sistema.

4. Diagrama de seqüências - é um diagrama de interação cuja ênfase está na ordenação temporal das mensagens.

5. Diagrama de colaborações - é um diagrama de interação cuja ênfase está na organização estrutural dos objetos que enviam e recebem mensagens.

6. Diagrama de gráficos de estados - exibem uma máquina de estados, formada por estados, transições, eventos e atividades. Os diagramas de gráfico de estados abrangem uma visão dinâmica de um sistema e são importantes para a modelagem de comportamento de uma interface, classe ou colaboração; e para dar ênfase a comportamentos de objetos ordenados por eventos (sistemas reativos).

7. Diagrama de atividades - é um tipo especial de diagrama de gráfico de estados, exibindo o fluxo de uma atividade para outra no sistema. Abrange a visão dinâmica do sistema e é importante principalmente para a modelagem da função de um sistema e dá ênfase ao fluxo de controle entre objetos.

8. Diagrama de componentes - exibe as organizações e as dependências existentes em um conjunto de componentes. Abrange a visão estática da implementação de um sistema. Está relacionado aos diagramas de classes, pois tipicamente os componentes são mapeados para uma ou mais classes, interfaces ou colaborações.

9. Diagrama de implantação - mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes. Abrange a visão estática do funcionamento de uma arquitetura. Está relacionado aos diagramas de componentes, pois tipicamente um nó inclui um ou mais componentes.

4.4 Regras da UMLRegras que determinam como os blocos da UML deverão/poderão ser combinados.A UML dispõe de regras semânticas para:

Nomes - quais nomes podem ser atribuídos a coisas, relacionamentos e diagramas

Escopo - o contexto que determina um significado específico para um nome

Visibilidade - como esses nomes podem 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

4.5 Mecanismos básicos da UMLSão os mecanismos básicos que se aplicam a toda a linguagem, que são:1. Especificações - Cada parte da notação gráfica possui uma especificação capaz de fornecer uma declaração textual da sintaxe e

da semântica do respectivo bloco de construção.Exemplo: Ícone de classe - existe uma especificação que fornece o conjunto completo de atributos, operações e

comportamentos de classe. O ícone poderia exibir somente uma parte de interesse em determinado diagrama.O ícone de classe permite a visualização da mesma no sistema (visualização do sistema).


Unipampa – Campus BagéA especificação determina os detalhes da classe (detalhes dos elementos do sistema).

2. Adornos Em sua maioria, os elementos da UML possuem uma notação gráfica única e direta (representação visual). Por

exemplo; a notação gráfica para classes expõe os aspectos mais importantes da classe (nome, atributos e operações).Através de adornos pode-se definir detalhes como:

Se uma classe é Abstrata (nome da classe em itálico)

Visibilidade de atributos e operações

Todos os elementos da notação da UML possuem símbolos básicos que podem ser adornados.

3. Divisões comuns O mundo costuma ser dividido pelo menos de duas maneiras.Primeiro, a Divisão Classe/Objeto: classe é a abstração; objeto é a manifestação concreta dessa abstração.Quase todos os blocos de construção disponíveis na UML apresentam este mesmo tipo de dicotomia

classe/objeto (abstração do elemento e instância desta abstração)Ex.:Casos de Uso e Instâncias de Casos de UsoComponentes e Instâncias de ComponentesNós e Instâncias de Nós

Segundo, separação de interface e implementação.Interface declara um contrato.Implementação representa uma realização completa desse contrato, responsável pela manutenção fiel da

semântica completa da interface.Quase todos blocos de construção da UML apresentam esse mesmo tipo de dicotomia interface/implementaçãoEx.:Casos de Uso e as Colaborações que as realizam.Operações e Métodos que as implementam.

4. Mecanismos de extensão A UML permite a sua própria ampliação (de maneira controlada), para isto são utilizados os mecanismos de

extensibilidade da UML, os quais incluem:

Estereótipos - amplia o vocabulário da UML, permitindo a criação de novos tipos de blocos de construção que são derivados dos já existentes, mas específicos a determinados problemas. Por exemplo: Modelar as exceções de linguagens como Java e C++ como uma classe marcada com um estereótipo (<<exception>>).

Valores atribuídos - estende as propriedades dos blocos de construção permitindo a criação de novas informações na especificação de um elemento. Por exemplo: Produtos com muitas versões ao longo do tempo. Marcar, com valores atribuídos, a versão e o autor deste produto.

Restrições - amplia a semântica dos blocos de construção permitindo acrescentar novas regras ou modificar as já existentes. Por exemplo: restringir um método de uma classe de modo que todos acréscimos (através de uma operação add(), por exemplo) sejam feitos ordenadamente.

O importante na utilização dos mecanismos de extensão é que seja controlada, para que um dos propósitos da UML não seja perdido - a comunicação de informações.

5 Mecanismos da UMLQuatro mecanismos1. Especificações2. Adornos3. Divisões Comuns4. Mecanismos de Extensibilidade

5.1 Uso de Adornos e Mecanismos de ExtensibilidadeAdornosNotas: É o tipo mais importante de adorno. Símbolo gráfico para a representação de restrições ou de

comentários anexados a um elemento ou a uma coleção de elementos.Use as notas para anexar informações a um modelo, como requisitos, observações, revisões e explicações.Outros AdornosSão itens gráficos ou visuais, adicionados à notação básica.


Unipampa – Campus BagéPor exemplo: A notação básica para uma associação é uma linha, mas podem ser incluídos adornos referentes a

detalhes como o papel e a multiplicidade de cada extremidade.Regra geral: inicialmente utilize a notação básica da UML, depois, somente para os elementos necessários,

adicione adornos.Em itens como classes, componentes e nós, pode ser adicionado um compartimento extra, abaixo dos usuais,

para fornecer informações que não podem ser acomodadas como um texto simples ou em imagens gráficas (adornos como estereótipos, elementos estereotipados graficamente, notas).

5.2 Mecanismos de ExtensibilidadePermitem estender a linguagem de uma maneira controlada. Incluem estereótipos, valores atribuídos e

restrições.Estereótipos: ampliam o vocabulário da UML, permitindo a criação de novos tipos de blocos de construção,

derivados de outros já existentes, mas específicos a determinado problema. Representado graficamente como um nome entre ângulos. Como uma opção, o elemento estereotipado pode ser representado com um novo ícone.

Valores atribuídos: estende as propriedades de blocos de construção da UML, permitindo a criação de novas informações nas especificações desses elementos. Representado graficamente como uma seqüência de caracteres entre chaves (abaixo do nome).

Restrições: estende a semântica dos blocos de construção da UML, permitindo adicionar novas regras ou modificar as existentes. Use esses mecanismos para ajustar a UML às necessidades específicas do seu domínio ou cultura de desenvolvimento. Representada graficamente como uma seqüência de caracteres entre chaves (próxima ou conectada por dependência ao elemento associado ou por meio de uma nota).

EstereótiposPode ser representado pelo nome entre ângulos, pode incluir um ícone para o estereótipo e apresentá-lo à

direita do nome ou usar esse ícone como símbolo básico.

Valores atribuídosPermite acrescentar novas propriedades aos elementos da UML. Valores atribuídos são como metadados, pois

seus valores se aplicam aos próprios elementos e não às respectivas instâncias.Representado como uma seqüência de caracteres entre chaves, colocado abaixo do nome do elemento. Esta

seqüência de caracteres inclui um nome (a etiqueta), um separador (o símbolo =) e um valor (atribuído).Obs.: Uma das utilizações mais comuns dos valores atribuídos é a especificação de propriedades relevantes

para a geração de código ou de gerenciamento de configurações (mapeamento de uma classe para uma linguagem de programação ou especificar o autor e a versão de um componente).

RestriçõesUma restrição especifica condições que devem ser mantidas como verdadeiras para que o modelo seja bem-

formado (ex.: especificar que uma associação é criptografada, ou especificar que, em um conjunto de associações, somente uma é manifestada).

Representada como uma seqüência de caracteres entre chaves, colocada próxima ao elemento associado.

5.2.1 Elementos-padrãoA UML define um conjunto de estereótipos-padrão para classificadores, componentes, relacionamentos e

outros elementos da modelagem. Existe um estereótipo-padrão, que interessa principalmente aos construtores de ferramentas, capaz de permitir a modelagem dos próprios estereótipos.

- estereótipo: especifica que o classificador é um estereótipo que pode ser aplicado a outros elementos

A UML também especifica um valor atribuído padrão, que se aplica a todos os elementos da modelagem.- documentação: especifica um comentário, descrição ou explanação do elemento a que está anexado

5.3 Técnicas básicas de modelagemModelagem de comentários

Inclua seu comentário como um texto em uma nota e coloque-a próxima ao elemento a que ela se refere (pode ser usada dependência).

Elementos podem ser ocultados nos modelos. Exiba comentários somente na medida em que sejam necessários para a comunicação de informações em um determinado contexto.

Se o comentário for muito extenso ou envolver algo mais rebuscado do que texto simples, considere a possibilidade de colocá-lo em documento externo (e vinculá-lo)



À medida que o modelo evoluir, mantenha aqueles comentários que registram decisões significativas e que não possam ser inferidos a partir do próprio modelo e - a menos que tenham algum interesse histórico - exclua os demais comentários.

Modelagem de novos blocos de construçãoUtilização de estereótipos.Para fazer a modelagem de novos blocos de construção:

Verifique se já não existe uma forma para expressar o que você deseja, utilizando apenas a notação básica da UML.

Caso não exista outra maneira, identifique o item primitivo que seja mais semelhante ao que você deseja modelar e defina um novo estereótipo para esse item.

Especifique a semântica e as propriedades comuns encontradas no elemento básico que está sendo estereotipado, definindo um conjunto de valores atribuídos e de restrições para o estereótipo.

Se quiser que esses elementos de estereótipos tenham uma indicação visual distintiva, defina novos ícones para os estereótipos.

Modelagem de novas propriedadesUtilização de valores atribuídos.

Verifique se já não existe uma forma para expressar o que você deseja, utilizando apenas a notação básica da UML

Caso contrário, adicione a nova propriedade a um elemento individual ou a um estereótipo. As regras de generalização serão aplicadas - os valores atribuídos definidos para um tipo de elemento são aplicados aos respectivos elementos-filhos.

Modelagem de uma nova semânticaUtilização de restrições:

Verifique se já não existe uma forma para expressar o que você deseja, utilizando apenas a notação básica da UML

Caso contrário, escreva a nova semântica como texto em uma restrição e coloque-a ao lado do elemento ao qual ela se refere. Pode ser utilizado em relacionamento de dependência.

Se for necessário especificar sua semântica de modo mais preciso e formal, escreva a nova semântica usando a OCL.

Figura 2 - Modelagem de uma nova semântica

6 RelacionamentosNa maioria dos casos, classes não trabalham sozinhas. Em vez disso, a maioria das classes colaboram com

outras de várias maneiras. Além de modelar os itens que formam o vocabulário do sistema, é necessário modelar como esses itens relacionam-se entre si.

Um relacionamento é uma conexão entre itens.Existem três tipos de relacionamentos (OO)1. Dependências - representam relacionamentos de utilização entre as classes (incluindo relacionamentos de

refinamento, rastreamento e vínculos) - Ex.: os canos dependem do aquecedor para fornecerem água quente.É representada graficamente por uma linha tracejada apontando o item do qual o outro depende.Usada normalmente no contexto das classes para mostrar que uma classe usa outra como argumento na

assinatura de uma operação.


Unipampa – Campus Bagé2. Generalizações - relacionam classes generalizadas a suas especializações (relacionamentos

subclasse/superclasse). Ex.: janelas panorâmicas são grandes e com painéis fixos de vidro; janelas de quartos costumam ter mais de um painel de vidro e abrir de um lado para outro. Também chamada de relacionamento "é um tipo de".

A generalização significa que os objetos da classe-filha podem ser utilizados em qualquer local em que a classe-mãe ocorra, mas não vice-versa. A classe filhe herda as propriedades da mãe (atributos e operações). Freqüentemente - mas não sempre - as filhas têm atributos e operações além daqueles encontrados nas respectivas mães. A operação de uma filha, que tenha a mesma assinatura de uma operação da mãe, prevalecerá em relação à operação da mãe (polimorfismo).

Representada graficamente como uma linha sólida apontando para a mãe. Podem existir herança simples e herança múltipla (a classe filha herda todos os atributos, operações e

associações de todas as suas classes mãe).

Figura 3 - Generalização

3. Associações - representam relacionamentos estruturais entre objetos (instâncias). Ex.: As salas são formadas por paredes e outros itens; as próprias paredes podem ter portas e janelas embutidas; os canos podem ser passados por dentro das paredes.

Através de uma associação á possível navegar do objeto de uma classe até o objeto de outra classe e vice-versa. Podem existir associações entre objetos de uma mesma classe.

Representada graficamente como uma linha sólida conectando a mesma classe oi classes diferentes. Use as associações sempre que desejar exibir relacionamentos estruturais.

A representação gráfica para cada um destes tipos de relacionamentos é mostrada na figura abaixo:

Figura 4 - Relacionamentos da UML


Unipampa – Campus BagéNome: Uma associação pode ter um nome, que pode ser utilizado para descrever a natureza do relacionamento.

Figura 5 - Nomes de Associações

Papel: quando uma classe participa de uma associação, ela tem um papel específico a executar neste relacionamento; o papel é apenas a face que a classe próxima a uma das extremidades apresenta à classe encontrada na outra extremidade da associação

Figura 6 - Papéis nas Associações

Multiplicidade: uma associação representa um relacionamento estrutural existente entre objetos. Em muitas situações de modelagem é importante determinar a quantidade de objetos que podem ser conectados pela instância de uma associação (multiplicidade). Ao determinar a multiplicidade em uma das extremidades de uma associação, você está especificando que, para cada objeto da classe encontrada na extremidade oposta, deve haver a mesma quantidade de objetos na próxima extremidade.

Podem ser apresentadas multiplicidades de exatamente um (1), zero ou um (0..1), muitos (0..*) ou um ou mais (1..*). Pode ser determinado um número exato (por exemplo, 3)

Figura 7 - Multiplicidade dos Relacionamentos

Agregação: uma associação pura entre duas classes representa um relacionamento estrutural entre partes, significando que essas duas classes estão conceitualmente em um mesmo nível. Em alguns casos será necessário modelar um relacionamento "todo/parte". Uma classe representa o item maior ("todo"), formado por itens menores ("partes"). Representa um relacionamento do tipo "tem um".

E representada graficamente como uma associação simples com um diamante aberto na extremidade do todo.



Figura 8 - Agregação na UML

Todos esses relacionamentos costumam ser visualizados em diagramas de classes.

Figura 9 - Herança na UML

Figura 10 - Relacionamentos Estruturais na UML

6.1 Relacionamentos AvançadosTrês blocos de construção relacionais mais importantes da UML: dependências, generalizações e associações.Pode-se fazer a modelagem de heranças múltiplas, navegação, refinamentos e outras características.Tem-se um quarto tipo de relacionamento - a realização.Com a utilização de realização, pode-se fazer a modelagem da conexão existente entre uma interface e uma

classe ou componente, ou entre um caso de uso e uma colaboração.



Figura 11 - Relacionamentos Avançados na UML

6.2 DependênciaExistem oito estereótipos aplicáveis aos relacionamentos de dependências (classes e objetos):1. bind: especifica que a origem instancia o template de destino, usando os parâmetros atuais fornecidos.

Utilizado para fazer a modelagem de detalhes das classes-template.2. derive: especifica que a origem poderá ser computada a partir do destino. Utilizado para fazer a modelagem

do relacionamento entre dois atributos ou duas associações, em que um é concreto e o outro e conceitual. Ex. atributos "dataDeNascimento" e "idade" da classe "Pessoa".

3. friend: especifica que a origem recebe visibilidade especial no destino. Ex. classes friend do C++.4. instanceOf: especifica que o objeto de origem é uma instância do classificador de destino.5. instantiate: especifica que a origem cria instâncias do destino. Ex. Relacionamentos classe/objeto explícitos

e entre classe e sua metaclasse (instanceOf). Especificar qual elemento cria objetos a partir de outros (instantiate)6. powertype: especifica que o alvo á um powertype do destino. um powertype é um classificador cujos objetos

são filhos de um determinado pai. Ex. classes que abrangem outras classes (modelagem de BD).7. refine: especifica que o destino é um grau mais apurado de abstração do que o destino. Ex. mesmas classes

em diferentes níveis de abstração.8. use: especifica que a semântica do elemento de origem depende da semântica da parte pública do destino.

Ex.: marcar explicitamente uma dependência como um relacionamento de uso.

Existem outros dois estereótipos que são aplicados aos pacotes.1. access: especifica que o pacote de origem tem o direito de fazer referência aos elementos do pacote de

destino.2. import: um tipo de acesso especificando que o conteúdo público do pacote de destino fornece o espaço do

nome da origem, como se tivesse sido declarado na origem.

Dois estereótipos são aplicados aos relacionamentos de dependência existentes entre casos de uso:1. extend: especifica que o caso de uso de destino estende o comportamento da origem.2. include: especifica que o caso de uso de origem incorpora explicitamente o comportamento de outro caso de

uso em um local especificado pela origem.

Para as interações entre objetos, a UML define três estereótipos:1. become: especifica que o destino é o mesmo objeto que a origem, mas em um ponto adiante no tempo e com

valores, estados ou papéis possivelmente diferentes.2. call: especifica que a operação de origem chama a operação de destino.3. copy: especifica que o objeto de destino é uma cópia exata, mas independente, da origem.

O estereótipo encontrado no contexto de máquinas de estados é o seguinte:

send: especifica que a operação de origem envia o evento de destino.

O estereótipo encontrado no contexto da organização de elementos do sistema em subsistemas e modelos é o seguinte:



trace: especifica que o destino é um antecessor histórico da origem.Ex.: um caso de uso (requisito funcional) pode ser rastreado em um pacote do modelo de projeto (artefatos que

realizam esse caso de uso).

6.3 GeneralizaçãoEm alguns casos pode ser necessária a utilização de herança múltipla. Mas, deve ser utilizada com cautela, pois

muitas vezes esta não pode ser implementada em linguagem de implementação.A UML define um estereótipo e quatro restrições que podem ser aplicadas aos relacionamentos de

generalização

Estereótipo:

implementation: especifica que a filha herda a implementação da mãe, mas não torna pública, nem fornece suporte às suas interfaces, violando assim a capacidade de substituição.

Ex. heranças privadas (C++)

Restrições1. complete: especifica que todas as filhas na generalização foram especificadas no modelo e que nenhuma

filha adicional é permitida.2. incomplete: especifica que nem todas as filhas na generalização foram especificadas no modelo e que filhas

adicionais são permitidas.3. disjoint: especifica que os objetos da mãe não poderão ter mais de uma filha como um tipo.4. overlapping: especifica que os objetos da mãe poderão ter mais de uma filha como um tipo.

6.4 AssociaçãoQuatro tipos básicos de adornos aplicáveis às associações:

nome, papel em cada extremidade, a multiplicidade em cada extremidade e a agregação.

Para recursos avançados, existem algumas outras propriedades que podem ser utilizadas para a modelagem de detalhes sutis, como navegação, qualificação e vários tipos de agregação.

NavegaçãoPossibilidade de navegação de objetos de uma classe (tipo) até objetos de outra classe (tipo). De maneira

padrão, a navegabilidade é bidirecional, a não ser se explicitamente especificada.

Figura 12 - Navegação

VisibilidadeEm determinadas situações deseja-se limitar a visibilidade em uma associação, relativa a objetos externos à

associação.Três níveis de visibilidade: pública (padrão), privada (indica que os objetos existentes nessa extremidade não

estão acessíveis a qualquer objeto externo à associação) e protegida (indica que os objetos encontrados nessa extremidade não estão acessíveis a qualquer objeto externo à associação, com exceção dos filhos existentes na outra extremidade)

Figura 13 - Visibilidade dos Relacionamentos

QualificaçãoRelacionado ao problema de busca associado à modelagem no contexto de uma associação.Utilização de um qualificador, que é um atributo de associação cujos valores particionam o conjunto de objetos

relacionados a um objeto da associação. O qualificador é representado como um pequeno retângulo anexo à extremidade da associação, contendo os atributos.

O objeto de origem, juntamente com os valores dos atributos do qualificador, gera um objeto de destino (no caso de a multiplicidade do destino ser limitada a um) ou um conjunto de objetos (se a multiplicidade do destino for igual a muitos).


Unipampa – Campus BagéEx. Pode-se criar uma estrutura de dados a ser pesquisada em uma extremidade de uma associação (tabela hash

ou uma árvore B) e depois manifestar esse índice como um qualificador. Na maioria dos casos, a multiplicidade da extremidade de origem será de muitos e a multiplicidade da extremidade de destino será "0..1".

Figura 14 - Associação Qualificada

ComposiçãoA agregação simples não modifica o significado da navegação pela associação entre o todo e suas partes, nem

vincula o tempo de vida do todo e suas partes.A composição é uma forma de agregação, com propriedade bem-definida e tempo de vida coincidente como

parte do todo. As partes sem multiplicidade fixada podem ser criadas após a composição, mas, uma vez criadas, vivem e morrem com ela. Estas partes podem ser removidas explicitamente antes da morte do objeto composto.

Numa agregação composta um objeto poderá ser uma parte de somente uma composição em determinado momento. O "todo" geri a criação e destruição de suas partes.

Figura 15 - Relacionamento de Composição

Classes de associaçãoEm uma associação entre duas classes, a própria associação poderá ter propriedades.Uma associação que também tem propriedades de classe ou como uma classe que também tem propriedades de

associação

Figura 16 - Classe de Associação

RestriçõesA UML define cinco restrições a serem aplicadas aos relacionamentos de associações:1. implicit: especifica que o relacionamento não é manifestado, mas apenas conceitual (associação entre classes

base, pode-se colocar uma associação entre as classes-filha com esta restrição)2. ordered: especifica que o conjunto de objetos em uma das extremidades da associação se encontra em uma

ordem explícita. (Usuário/Senha)3. changeable: entre objetos poderão ser adicionados, removidos e modificados livremente.4. addonly: novos vínculos poderão ser adicionados a partir de um objeto existente na existente oposto da

associação.5. frozen: após ter sido adicionada a partir de um objeto existente na extremidade oposta da associação, não

poderá ser modificado ou excluído.



RealizaçãoUtiliza-se "realização" em duas circunstâncias: no contexto de interfaces e no contexto de colaborações

Figura 17 - Realização de Interface

Figura 18 - Realização de Caso de Uso

7 DiagramasUm diagrama é uma representação gráfica de um conjunto de elementos, geralmente representados como um

gráfico conectado de vértices (itens) e arcos (relacionamentos).Diagramas são usados para visualizar o sistema sob diversas perspectivas.No contexto de modelagem de software, existem cinco visões (perspectivas) complementares. Estas visões são

importantes para a visualização, a especificação, a construção e a documentação da arquitetura de um software.1. A Visão do Caso de Uso2. A Visão de Projeto3. A Visão de Processo4. A Visão de Implementação5. A Visão de Implantação

Os diagramas da UML podem ser usados de duas maneiras básicas: para especificar modelos a partir dos quais será construído um sistema executável (engenharia de produção); e para reconstruir modelos a partir de partes de um sistema executável (engenharia reversa). Em qualquer uma dessas maneiras, a tendência será a criação de diagramas incrementalmente (ampliando-se uma parte de cada vez) e iterativamente (repetindo o processo de projetar uma pequena parte e construí-la).

Um sistema é uma coleção de subsistemas organizados para a realização de um objetivo e descritos por um conjunto de modelos, possivelmente sob diferentes pontos de vista.

Um subsistema é um agrupamento de elementos, alguns dos quais constituem uma especificação do comportamento proporcionado pelos outros elementos contidos.

Um modelo é uma abstração semanticamente fechada de um sistema, o que significa que representa uma simplificação autoconsistente e completa da realidade, criada com a finalidade de permitir uma melhor compreensão a respeito do sistema.

No contexto de arquitetura, uma visão é uma projeção da organização e estrutura do modelo de um sistema, cujo foco está voltado para um único aspecto desse sistema.

Um mesmo item em um sistema poderá aparecer várias vezes no mesmo diagrama ou até em diagramas diferentes. Em cada caso, será o mesmo item.

Tipicamente, para as partes estáticas do sistema, serão utilizados para visualização um (ou mais) dos seguintes quatro diagramas:

1. Diagrama de classes2. Diagrama de objetos3. Diagrama de componentes4. Diagramas de implantação

Para a visualização dinâmica do sistema, serão utilizados os seguintes cinco diagramas adicionais:1. Diagrama de caso de uso2. Diagrama de seqüências


Unipampa – Campus Bagé3. Diagrama de colaboração4. Diagrama de gráfico de estados5. Diagrama de atividades

Diagramas devem possuir nomes únicos em seus contextos e normalmente são organizados em pacotes.

Diagramas estruturaisOs diagramas estruturais da UML são organizados em função dos principais grupos de itens encontrados na

modelagem de um sistema.1. Diagrama de classes - Classes, interfaces e colaborações2. Diagrama de objetos - Objetos3. Diagrama de componentes - Componentes4. Diagramas de implantação - Nós

Diagrama de classes - exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos. Maior freqüência em sistemas de modelagem orientados a objeto. Abrangem uma visão estática do sistema. Os diagramas que incluem classes ativas são empregados para direcionar a visão estática do processo de um sistema.

Diagrama de objetos - exibe um conjunto de objetos e seus relacionamentos. Representa "retratos" estáticos de instâncias de itens encontrados em diagramas de classes. Também abrangem uma visão estática, mas sob perspectiva de casos reais ou de protótipos.

Diagrama de componentes - exibe as organizações e as dependências existentes em um conjunto de componentes (conjunto de componentes e seus relacionamentos). Abrange a visão estática da implementação de um sistema. Está relacionado aos diagramas de classes, pois tipicamente os componentes são mapeados para uma ou mais classes, interfaces ou colaborações.

Diagrama de implantação - mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes (nós e seus relacionamentos). Abrange a visão estática do funcionamento de uma arquitetura (implantação de uma arquitetura). Está relacionado aos diagramas de componentes, pois tipicamente um nó inclui um ou mais componentes.

Diagramas comportamentaisOs diagramas comportamentais são basicamente organizados a partir das principais maneiras disponíveis para

se fazer a modelagem da dinâmica de um sistema.1. Diagrama de caso de uso - Organiza os comportamentos do sistema2. Diagrama de seqüências - Tem, como foco, a ordem temporal das mensagens3. Diagrama de colaboração - Tem, como foco, a organização estrutural de objetos que enviam e recebem

mensagens4. Diagrama de gráfico de estados - Tem, como foco, o estado de mudança de um sistema orientado por

eventos5. Diagrama de atividades - Tem, como foco, a organização estrutural de objetos que enviam e recebem

mensagens

Diagrama de casos de uso - exibe um conjunto de casos de uso e atores (um tipo especial de classe) e seus relacionamentos. Abrangem a visão estática de casos de uso do sistema. Importantes para a organização e modelagem dos comportamentos de um sistema.

Os diagramas de seqüências, de colaboração, de gráfico de estados e de atividades são equivalentes, isso significa que se pode fazer a modelagem da dinâmica de um sistema usando um único tipo de diagrama comportamental e depois transformá-lo em outro tipo de diagrama sem perder informações.

Diagrama de seqüências - é um diagrama de interação cuja ênfase está na ordenação temporal das mensagens. Mostra conjunto de objetos e as mensagens enviadas e recebidas por estes.

Diagrama de colaborações - é um diagrama de interação cuja ênfase está na organização estrutural dos objetos que enviam e recebem mensagens. Mostra conjunto de objetos, as conexões existentes e as mensagens enviadas e recebidas pelos objetos.

Diagrama de gráficos de estados - exibem uma máquina de estados, formada por estados, transições, eventos e atividades. Os diagramas de gráfico de estados abrangem uma visão dinâmica de um sistema. Importantes para a modelagem de comportamento de uma interface, classe ou colaboração e para dar ênfase aos comportamentos de objetos ordenados por eventos (sistemas reativos).

Diagrama de atividades - é um tipo especial de diagrama de gráfico de estados, exibindo o fluxo de uma atividade para outra no sistema. Abrange a visão dinâmica do sistema e é importante principalmente para a modelagem da função de um sistema e dá ênfase ao fluxo de controle entre objetos.

8 PacotesVisualizar, especificar, construir e documentar sistemas grandes envolve a manipulação de quantidades

potencialmente grandes de classes, interfaces, componentes, nós, diagramas e outros elementos.


Unipampa – Campus BagéSurge, assim, a necessidade de organizar esses itens em grupos maiores. na UML, o pacote é um mecanismo de

propósito geral para a organização de elementos da modelagem em grupos.Pode-se controlar a visibilidade dos elementos dentro dos pacotes (alguns visíveis fora do pacote e outros

ocultos). Podem ser empregados para apresentar diferentes visões da arquitetura do sistema.Pacotes bem-estruturados são fracamente acoplados em forte coesão, com acesso altamente controlado ao

conteúdo do pacote.Utilizando pacotes pode-se compreender com maior facilidade os modelos.Todo pacote deve ter um nome que o diferencie de outros pacotesUm pacote pode conter outros elementos, incluindo classes, interfaces, componentes, nós, colaborações, casos

de uso, diagramas e até outros pacotes.Os elementos de um pacote formam um relacionamento composto.Identificação de elementos de um pacote pode ser feita utilizando-se "nomes de caminho".

VisibilidadeCada elemento do pacote recebe um prefixo definindo sua visibilidade (como acontece com as classes).

Importação e exportaçãoImportação de um pacote por outro. Fornece uma permissão unilateral para os elementos de um pacote (o que

importou) tenham acesso aos elementos de outro pacote (o importado ou exportado).As partes exportadas por um pacote são visíveis somente para o conteúdo dos pacotes que importam aquele

pacote explicitamente.As dependências de importação e de acesso não são transitivas.São representadas por dependências estereotipadas (<<import>>) entre pacotes.

Figura 19 - Importação e Exportação entre Pacotes

GeneralizaçãoUtilizada para especificar famílias de pacotes.Semelhante a generalização entre classes.Todos os mecanismos de extensibilidade da UML se aplicam aos pacotes.Valores atribuídos podem ser usados para atribuir novas propriedades (autor)

A UML define cinco estereótipos-padrão que se aplicam aos pacotes.1. facade: especifica um pacote que é apenas uma visualização de algum outro pacote.2. framework: especifica um pacote que é formado principalmente por padrões.3. stub: especifica um pacote que serve como proxy para o conteúdo público de outro pacote.4. subsystem: especifica um pacote representando uma parte independente de todo o sistema cuja modelagem

está sendo feita.5. system: especifica um pacote representando todo o sistema cuja modelagem está sendo feita.

facade é empregado para fornecer visualizações ocultas encontradas em pacotes que, de outra forma, seriam muito complexos (Pacote ModelodeNegócio: subconjuntos diferentes de elementos para conjuntos diferentes de usuários). facade sempre importam, nunca têm, elementos de outros pacotes.

stub são utilizados quando se possui ferramenta capaz de dividir um sistema em pacotes que são manipulados em diferentes momentos e potencialmente em diferentes locais. (equipes de desenvolvimento trabalhando em locais geograficamente diferentes)



Figura 20 - Generalização entre Pacotes

Modelagem de grupos de elementosO propósito mais comum para pacotes é organizar os elementos da modelagem em grupos que você pode

nomear e manipular como um conjunto.Para aplicações triviais provavelmente não será necessário usar pacotes.Pode-se utilizar pacotes para agrupar o mesmo tipo básico de elementos.

Visão de projeto: todas as classes e relacionamentos

Visão de implementação: componentes, arquivos de configuração, executáveis, código, etc.

Exemplo: pacotes organizando um sistema em uma arquitetura clássica de três camadas:

Figura 21 - Arquitetura de Três Camadas - Pacotes

9 ClassesSão os blocos de construção mais importantes de qualquer sistema orientado a objetos.Uma classe é a descrição de um conjunto de objetos que compartilham os mesmos atributos, operações,

relacionamentos e semântica.Classes podem incluir abstrações que são parte do domínio do problema, assim como as classes que fazem uma

implementação. Pode-se utilizar classes para representar itens de software, de hardware e até itens que sejam puramente conceituais.

Uma classe é uma abstração de itens que fazem parte de seu vocabulário (no contexto de um domínio de aplicação). A classe não é um objeto individual, mas representa um conjunto inteiro de objetos.

A representação gráfica de classe é mostrada da figura abaixo.

Figura 22 - Classe na UML


Unipampa – Campus BagéA notação permite visualizar uma abstração independente de qualquer linguagem de programação específica e

de uma maneira que torna possível dar ênfase às partes mais importantes de uma abstração: seu nome, atributos e operações (pode ainda existir uma seção de responsabilidades).

Cada classe deve ter um nome que a diferencia de outras classes. O nome é uma seqüência de caracteres. Sozinho, é conhecido como nome simples; o nome do caminho é o nome da classe, tendo como prefixo o nome do pacote a que essa classe pertence.

nome simples: Cliente; Parede; Sensor de Temperaturanomes de caminho: java::awt::Rectangle; Regras de Negócio::Agente de Fraude

Nomes da classe normalmente iniciam com letras maiúsculas.

AtributosÉ uma propriedade nomeada de uma classe que descreve um intervalo de valores que as instâncias da

propriedade podem apresentar.Uma classe pode apresentar qualquer número de atributos ou mesmo nenhum atributo.Um atributo representa alguma propriedade do item que está sendo modelado, compartilhado por todos os

objetos desta classe.Um atributo é, portanto, uma abstração do tipo de dados ou estados que os objetos da classe podem abranger.Os atributos podem ser representados exibindo somente seus nomes, mas também pode incluir a sua classe

(tipo) e um possível valor inicial; assim como se podem especificar características de um atributo como sua visibilidade. Nomes de atributo: normalmente cada palavra do nome inicia com letras maiúsculas, exceto a primeira letra.

OperaçõesUma operação é a "implementação" (um contrato) de um serviço que pode ser solicitado por algum objeto da

classe para modificar o comportamento (estado).É uma abstração de algo que pode ser feito com um objeto e que é compartilhado por todos os objetos dessa

classe.Uma classe pode ter qualquer número de operações ou até não ter nenhuma operação.As operações podem ser representadas exibindo somente seus nomes, mas pode-se especificar uma operação

indicando sua assinatura (que contém o nome, o tipo e o valor-padrão de todos os parâmetros e o tipo a ser retornado, no caso das funções).

Nomes de operações: normalmente cada palavra do nome inicia com letras maiúsculas, exceto a primeira letra.Na representação de uma classe não é preciso exibir todos os atributos e operações ao mesmo tempo

(normalmente isto não é possível ou mesmo adequado). Pode-se mostrar somente os atributos e operações que sejam relevantes para uma determinada visão.

Para representar, explicitamente, que uma classe possui mais atributos e/ou operações, utiliza-se reticências (...) no final de cada lista.

Para melhor organizar grandes listas de atributos e operações, pode-se agrupá-los, através de um prefixo, em uma categoria descritiva.

ResponsabilidadesÉ um contrato ou obrigações de uma determinada classe. Podem ser representadas graficamente em um

compartimento separado (abaixo dos compartimentos dos atributos e operações) ao final do ícone da classe.Técnicas como cartões CRC e análises baseadas em casos de uso podem ajudar na construção de definições de

Responsabilidades.

Outras característicasÀs vezes pode ser necessário especificar outras características em uma classe como a visibilidade de atributos e

operações individuais, características da linguagem em relação a uma operação (como a possibilidade de ser polimórfica ou constante ou mesmo as exceções que os objetos da classe poderiam produzir ou manipular). As representações dessas características são tratadas como conceitos avançados (abordados adiante).

Às vezes pode ser necessário (ou adequado) separar a implementação de uma classe de sua especificação. Isso pode ser feito através da utilização de interfaces.

Ao começar a construir modelos mais complexos, você descobrirá que serão encontrados os mesmos tipos de classes repetidamente, como as classes que representam processos e threads concorrentes ou classes que representam itens físicos, como applets, Java Beans, objetos COM+, arquivos, páginas da Web e hardware. Uma vez que esses tipos de classes são tão comuns e representam abstrações de arquiteturas importantes, a UML oferece classes ativas, componentes e nós.

10Diagramas de ClassesExemplo de Diagrama de Classes



Figura 23 - Diagrama de Classes

Os diagramas de classes costumam conter os seguintes itens:

Classes

Interfaces

Colaborações

Relacionamentos de dependência, generalização e associação.

Podem conter notas e restrições.Servem para fazer a modelagem estática do sistema, dando suporte, principalmente, aos requisitos funcionais

de um sistema (serviços que o sistema deverá fornecer aos usuários finais).

Os Diagrama de Classes são usados, tipicamente, de três formas:1. Para fazer a modelagem do vocabulário de um sistema (abstrações do domínio do problema)2. Para fazer a modelagem de colaborações simples: uma colaboração é uma sociedade de classes,

interfaces e outros elementos que funcionam em conjunto para proporcionar algum comportamento cooperativo, maior do que a soma de todos os elementos.

3. Para fazer a modelagem do esquema lógico de um banco de dados

Técnicas básicas de modelagem

Modelagem de colaborações simplesNenhuma classe é utilizada sozinha.Cada diagrama de classes deverá ter como foco uma única colaboração por vez.Para fazer a modelagem de uma colaboração:

Identificar o mecanismo do sistema cuja modelagem será feita (função ou comportamento de parte do sistema)

Para cada um desses mecanismos, identifique as classes, interfaces e outras colaborações que participam dessa colaboração (também os relacionamentos).

Use cenários para percorrer esses itens (verificação)

Certifique-se de preencher esses elementos com o respectivo conteúdo. Obtenha um bom equilíbrio de responsabilidades. Após, converta-as em operações e atributos.



Figura 24 - Modelagem dos mecanismos de movimentação de um robô autônomo

Modelagem do esquema lógico de um banco de dadosObjetos persistentes.

Utilização de Banco de Dados Relacional, Orientados a Objetos ou Híbrido (relacional/OO)

Diagramas da UML são um superconjunto dos diagramas de entidade/relacionamento (ER), uma ferramenta básica de modelagem para o projeto lógico de banco de dados.

O diagrama de classes permite a modelagem, além dos próprios dados, de comportamentos (que podem ser implementados como procedimentos armazenados).

Para fazer a modelagem de um esquema:

Identificar as classes persistentes

Crie um diagrama de classes e marque-as como persistentes (valores atribuídos)

Amplie os detalhes estruturais dessas classes (detalhes de atributos, associações e cardinalidades).

Procure padrões comuns que complicam o projeto de BD físicos, como associações cíclicas, associações de um-para-um e associações diárias (n-árias)

Considere também o comportamento dessas classes, expandindo as operações que são importantes para o acesso e a integridade dos dados (para melhor separação de questões, regras de negócios em uma camada superior).

Onde possível, use ferramentas para transformar o projeto lógico em projeto físico.

Exemplo: Conjunto de classes definido a partir de um sistema de informações para uma escola.



Figura 25 - Sistema de Informações para uma Escola

Engenharia de produção e reversaModelagem é importante, mas o produto principal de uma equipe de desenvolvimento é o software e não os

diagramas. Modelos para atingir o objetivo softwareExemplo: diagrama de classes simples, especificando uma instanciação da cadeia de padrões de

responsabilidades. Todas as classes especificam um mapeamento para a linguagem Java.

Figura 26 - Instanciação da Cadeia de Padrões de Responsabilidades

Código gerado (Java):

public abstract class EventHandler {private int currentEventID;private String source;private EventHandler sucessor;

EventHandler( ) { }public void handleRequest() {}

}

11Classes AvançadasAs classes são apenas um dos tipos de um bloco de construção ainda mais geral existente na UML: os

classificadores.Um classificador é um mecanismo que descreve características estruturais e comportamentais. Os

classificadores incluem classes, interfaces, tipos de dados, sinais, componentes, nós, casos de uso e subsistemas.


Unipampa – Campus BagéClassificadores (e principalmente as classes) possuem características avançadas:

Multiplicidade

Visibilidade

Assinaturas

Polimorfismo

À medida que um projeto prosseguir, a arquitetura (e, por conseqüência, seus elementos) é aprimorada. Exemplo de propriedades avançadas:

Figura 27 - Propriedades Avançadas de Classes

Durante a modelagem, certas abstrações representam itens do mundo real e itens que existem apenas na solução.

Exemplo: Sistema de Pedidos na WebVocabulário do Sistema: Cliente, TransaçãoNo sistema implementado: preço

Cada abstração terá instâncias. Alguns itens da UML não possuem instâncias (pacotes e os relacionamentos de generalização). Em geral, os elementos que podem ter instâncias são chamados classificadores.

O tipo mais importante de classificador na UML é a classe.As classes são descrições como conjuntos de objetos que compartilham os mesmos atributos, operações,

relacionamentos e semântica.As classes não são o único tipo de classificador:

Interface : uma coleção de operações que especificam serviços de uma classe ou componente.

Tipos de dados : um tipo cujos valores não têm identidade (tipos primitivos e enumerados)

Sinal : a especificação de um estímulo assíncrono, comunicado entre as instâncias

Componente : uma parte física e substituível de um sistema, adequada à realização de um conjunto de interfaces e que proporciona essa realização

Nó : um elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, freqüentemente, capacidade de processamento.

Casos de uso : uma descrição de um conjunto de uma seqüência de ações, incluindo variantes, que um sistema realiza, proporcionando um resultado observável do valor para um determinado ator.

Subsistema : um grupo de elementos em que alguns constituem uma especificação do comportamento oferecido pelos outros elementos contidos no grupo.



Figura 28 - Classificadores

Visibilidade Um dos mais importantes detalhes que se pode especificar para os atributos e operações de um classificador.

Especifica se uma característica pode ser utilizada por outros classificadores. Importante para a utilização do conceito de ocultação da informação.

1. público: qualquer classificador externo com visibilidade para que determinado classificador seja capaz de usar a característica (+). É a visibilidade padrão.

2. protegido: qualquer descendente do classificador é capaz de usar a característica (#)3. privado: somente o próprio classificador é capaz de usar a característica (-)

Figura 29 - Visibilidade de Atributos e Operações

EscopoO escopo do proprietário especifica se uma característica aparece em cada instância do classificador ou se

haverá uma única instância da característica para todas as instâncias do classificador.Dois tipos:1. Instância: cada instância do classificador mantém seu próprio valor para a característica2. Classificador: exibe apenas um valor da característica para todas as instâncias do classificador.

C++ operações e atributos estáticos (termo também utilizado na ferramenta Jude) (Jude, 2005).

Figura 30 - Escopo de Atributos

Elementos abstratos, raiz, folha e polimórficosEm hierarquias de classes, é comum se especificar que certas classes são abstratas - significando que não

poderão apresentar instâncias diretas. Uma classe abstrata é especificada escrevendo seu nome em itálico.Uma classe pode ser definida de modo que não terá classes-filha. Este tipo de classe é chamado de classe-

folha. Na UML define-se uma classe-folha pela escrita da propriedade "leaf" abaixo do nome da classe.Menos comum, mas mesmo assim útil, é a capacidade de se especificar que uma classe poderá não ter classe-

mãe (classe raiz). Na UML define-se uma classe-raiz pela escrita da propriedade "root" abaixo do nome da classe.As operações têm propriedades semelhantes. Tipicamente, uma operação é polimórfica, significando que, em

uma hierarquia de classes, pode-se especificar operações com a mesma assinatura em pontos diferentes da hierarquia.


Unipampa – Campus BagéOperações nas classes-filha anulam o comportamento das operações da classe-mãe. Quando uma operação é despachada em tempo de execução, a operação a ser invocada na hierarquia é escolhida polimorficamente, ou seja, uma correspondência é determinada em tempo de execução de acordo com o tipo de objeto.

Operação abstrata - operação incompleta, precisa de uma filha para fornecer a implementação da operação. Na UML escreve-se o nome da operação abstrata em itálico.

Figura 31 - Elementos Abstratos, Raiz, Folha e Polimórficos

MultiplicidadeO número de instâncias que uma classe poderá ter é chamado sua multiplicidade. A multiplicidade é a

especificação do intervalo permitido de cardinalidade que uma entidade poderá assumir. Restrição da quantidade de instâncias que uma classe poderá ter. A multiplicidade também se aplica aos atributos.

Pode-se especificar os seguintes tipos de Multiplicidade:

Zero instâncias: trata-se de uma classe utilitária que exibe somente as operações e os atributos do escopo de classe

Uma instância: classe unitária

Um número específico de instâncias ou

Muitas instâncias: o caso padrão.

AtributosCada atributo pode ter especificado, além de seu nome, sua visibilidade, escopo e multiplicidade.Também é possível especificar o tipo (classe), valor inicial e a mutabilidade de cada atributo.Sintaxe:[visibilidade] nome [multiplicidade] [:tipo] [= valor-inicial][{string-propriedade}]Exemplos de declarações válidas:

origin+ originorigin : Pointhead: *Itemname [0..1] : Stringorigin: Point = (0, 0)id: Integer {frozen}

Três propriedades que podem ser utilizadas com os atributos:1. chageable - sem restrições de modificação2. addOnly - para o caso de atributos com multiplicidade maior que 1, valores adicionais poderão ser

incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado3. frozen - depois do objeto iniciado, o valor do atributo não poderá ser modificado


Unipampa – Campus BagéOperaçõesAlém do nome, pode-se especificar, também, a visibilidade e o escopo de cada operação. Além destes, pode-se

especificar os parâmetros, o tipo de retorno, semântica de concorrência e outras propriedades.

Sintaxe:[visibilidade] nome [(lista-de-parâmetros)] [:tipo-de-retorno] [{string-propriedade}]

Exemplos de declarações válidas:display+ displayset(n: Name, s: String)getID(): Integerrestart() {guarded}

Podem ser fornecidos zero ou mais parâmetros, seguindo a seguinte sintaxe:[direção] nome: tipo [= valor-padrão]

Direção pode ser in | out | inout

Além da propriedade "leaf", descrita anteriormente, existem outras quatro propriedades para operações.1. isQuery: a execução da operação mantém inalterado o estado do sistema (função pura, sem efeitos

secundários).2. sequential: os autores da chamada devem coordenar externamente o objeto, de maneira que exista

um único fluxo no objeto por vez. Na presença de vários fluxos de controle, a semântica e a integridade do objeto não podem ser garantidas.

3. guarded: a semântica e a integridade do objeto são garantidas na presença de vários fluxos de controle, devido à definição de uma seqüência de todas as chamadas para todas as operações do objeto, que têm a propriedade guarded (somente uma operação por vez pode ser invocada - semântica seqüencial).

4. concurrent: a semântica e a integridade do objeto são garantidas na presença de vários fluxos de controle, devido ao tratamento da operação como atômica. Várias chamadas a partir de fluxos concorrentes de controle poderão ocorrer simultaneamente para um objeto em qualquer operação concorrente e todas poderão prosseguir concorrentemente com a semântica correta; as operações concorrentes devem ser designadas para que possam ser executadas corretamente no caso de uma operação seqüencial ou com propriedade guarded no mesmo objeto.

Estas três últimas propriedades são relevantes somente na presença de objetos ativos, processos ou threads.

Classes-templateUm template é um elemento parametrizado.Um template inclui slots para classes, objetos e valores e esses slots servem como parâmetros do template. Para

utilizá-lo, é necessário instanciá-lo; e isto envolve a vinculação desses parâmetros formais do template a valores reaisO uso mais comum das classes-template é a especificação de recipientes que podem ser instanciados para

elementos específicos, tornando-os um tipo-seguro.

Elementos-padrãoA UML define 4 estereótipos-padrão que se aplicam às classes.1. metaclass: especifica um classificador cujos objetos são todas as classes2. powertype: especifica um classificador cujos objetos são as filhas de uma determinada mãe3. stereotype: especifica que o classificador é um estereótipo que pode ser aplicado a outros elementos4. utility: especifica uma classe cujos atributos e operações pertencem ao escopo da classe.

12InstânciasInstâncias e Objetos são sinônimos e, portanto, poderão ser permutados na maioria dos casos.Uma instância é a manifestação concreta de uma abstração à qual um conjunto de operações poderá ser

aplicado e que poderá ter um estado que armazena os efeitos das operações.A abstração denota a essência ideal de uma coisa; a instância denota uma manifestação concreta.A UML permite fazer a representação de abstrações e suas instâncias. Quase todos os blocos de construção da

UML - principalmente as classes, os componentes, os nós e os casos de uso - poderão ser modelados em termos de sua essência ou em termos de suas instâncias.

A notação característica para instâncias dentro da UML é a utilização do nome (simples ou de caminho) da instância sublinhado.

Uma instância pode ser nomeada ou anônima



Exemplos:keystrokes: Queue:Framet:

OperaçõesUm objeto pode fazer coisas.Se a classe Transaction possui uma operação commit; então, associada a uma instância t desta classe, pode ter

a seguinte expressão:t.commit

EstadoPode-se utilizar a UML para representar os valores doa atributos de um objeto (instância de uma classe).Uma máquina de estados pode estar associada com uma classe, o que é de grande ajuda, principalmente ao se

fazer a modelagem de sistemas orientados a eventos ou do tempo de vida de uma classe.

Figura 32 - Instância de Objeto - Estado e Atributos

Outras característicasOs processos e threads são elementos importantes da visão de processo de um sistema (elementos que se

encontram ativos - instanciados a partir de classes ativas).

Figura 33 - Instância de Classe Ativa

Elementos-padrãoTodos os mecanismos de extensibilidade da UML se aplicam aos objetos (normalmente derivados da abstração

associada - classe).A UML define dois estereótipos-padrão que se aplicam aos relacionamentos de dependência entre objetos e

entre classes:

1. instanceOf: especifica que o objeto cliente é uma instância do classificador do fornecedor.2. instantiate: especifica que a classe cliente cria instâncias da classe do fornecedor.

Também existem dois estereótipos relativos a objetos que se aplicam às mensagens e transições:

1. become: especifica que o cliente é o mesmo objeto que o fornecedor, mas em um momento posterior e com valores, estados ou papéis possivelmente diferentes.

2. copy: especifica que o objeto cliente é uma cópia exata, mas independente, do fornecedor.

A UML define uma restrição padrão aplicada a objetos:- transient: especifica que uma instância de um papel é criada durante a execução de uma interação fechada,

mas é destruída após o término da execução.Exemplo: Modelagem de Instâncias Concretas



Figura 34 - Instâncias Concretas

13Diagramas de ObjetosOs diagramas de objetos fazem a modelagem de instâncias de itens contidos em diagramas de classes. Um

diagrama de objetos mostra um conjunto de objetos e seus relacionamentos em determinado ponto no tempo.Utiliza-se estes diagramas para fazer a modelagem da visão estática do projeto ou do processo de um sistema,

como se faz com os diagramas de classes, mas a partir da perspectiva de instâncias reais ou prototípicas.Isso envolverá a modelagem de um retrato do sistema em determinado momento e a representação de um

conjunto de objetos, seus estados e relacionamentos.ConteúdoOs diagramas de objetos costumam conter:

Objetos (Classes) e Vínculos (associações)

Figura 35 - Diagrama de Objetos - Sistema de Empregados



Figura 36 - Diagrama de Objetos - Robô

14InteraçõesObjetos interagem entre si passando mensagens uns para os outros.A interação é um comportamento que compreende um conjunto de mensagens trocadas entre um conjunto de

objetos dentro de um contexto para a execução de um determinado propósito.Uma mensagem é a especificação de uma comunicação entre objetos, a qual contém informações relacionadas

ao que se espera resultar dessa atividade.São utilizadas para a modelagem dos aspectos dinâmicos das colaborações, representando sociedades de

objetos que executam papéis específicos.A modelagem de interação pode ser feita de duas maneiras:1. Dando-se ênfase à ordem temporal das mensagens (diagramas de seqüência).2. Dando-se ênfase à seqüência das mensagens no contexto de alguma organização estrutural de objetos

(diagramas de colaboração).

Com muita freqüência, as mensagens envolvem a chamada a uma operação ou o envio de um sinal; as mensagens ainda poderão abranger a criação e a destruição de outros objetos.

A interação é empregada para a modelagem do fluxo de controle de uma operação, uma classe, um componente, um caso de uso ou do sistema como um todo.

A UML fornece uma representação gráfica das mensagens. Esta notação torna possível visualizar uma mensagem (nome, parâmetros e seqüência).

Figura 37 - Visualização de Mensagens

Os objetos que participam em uma interação são itens concretos ou prototípicos.Observação: Em uma colaboração, os objetos encontrados são algo prototípico que desempenham

determinados papéis, e não objetos específicos do mundo real (instâncias).

Vínculos: é uma conexão semântica existente entre os objetos. Em geral, é uma instância de uma associação.



Figura 38 - Vínculos entre Objetos

Um vínculo especifica um caminho pelo qual um objeto pode enviar uma mensagem para outro (ou para o mesmo) objeto.

Caso seja necessário especificar a maneira como um vínculo existe, pode-se utilizar um adorno apropriado no vínculo (estereótipos-padrão).

association: especifica que o objeto correspondente é visível pela associação

self: especifica que o objeto correspondente é visível, por ser o emissor da operação

global: especifica que o objeto correspondente é visível, por estar no escopo que o contém

local: especifica que o objeto correspondente é visível, por estar em um escopo local

parameter: especifica que o objeto correspondente é visível, por ser um parâmetro

MensagensUma mensagem é a especificação de uma comunicação entre objetos, que contém informações sobre a

expectativa a respeito do resultado dessa atividade.Quando uma mensagem é passada, a ação resultante é uma instrução executável que forma uma abstração de

um procedimento computacional. Uma ação poderá resultar em uma mudança de estado.Na UML existem vários tipos de ações:

Call: invoca uma operação em um objeto; o objeto poderá enviar uma mensagem a si mesmo, resultando em chamada local de uma operação.

Return: retorna um valor para quem o solicitou.

Send: envia um sinal para outro objeto.

Create: cria um objeto.

Destroy: destrói um objeto; o objeto poderá cometer suicídio, destruindo a si próprio.



Figura 39 - Tipos de Mensagens - Diagrama de Seqüência

Criação, modificação e destruiçãoEm algumas interações os objetos participantes poderão ser criados (<<create>>) e destruídos (<<destroy>>).

O mesmo é verdadeiro em relação aos vínculos (links). Os relacionamentos entre objetos poderão ocorrer e desaparecer. Para especificar se um objeto ou vínculo entra e/ou sai durante uma interação, pode-se anexar uma das seguintes restrições ao elemento:

new: especifica que a instância ou vínculo é criado durante a execução da interação que os contém.

destroyed: especifica que a instância ou vínculo é destruído antes de concluída a execução da interação que os contém.

transient: especifica que a instância ou vínculo é criado durante a execução da interação que os contém, mas é destruído antes de concluída sua execução.

Para representar cada variante de um objeto, em um diagrama de seqüência, pode-se colocar cada variante na mesma linha de vida e conectá-las (em qualquer diagrama de interação) com uma mensagem "become".

Diagramas de Seqüência - permitem a modelagem da linha de vida de um objeto. A linha de vida de um objeto representa a existência desse objeto em um determinado período, possivelmente abrangendo sua criação e destruição.

Diagramas de Colaboração - permitem fazer a modelagem de vínculos estruturais que possam existir entre os objetos em uma interação.

O propósito mais comum para o qual se utilizará uma interação é a modelagem do fluxo de controle que caracteriza o comportamento do sistema como um todo, incluindo casos de uso, padrões, mecanismos e frameworks, ou o comportamento de uma classe ou operação individual.

15Diagramas de InteraçãoExistem dois diagramas de interação:1. Diagramas de Seqüência: dão ênfase à ordenação temporal das mensagens.

Linha de Vida (<<create>>, <<destroy>>); Foco de Controle2. Diagramas de Colaboração: dão ênfase aos relacionamentos estruturais entre os objetos que interagem uns

com os outros.Caminho (<<local>>, <<parameter>>, <<global>> e <<self>>); Número de Seqüência

Ambos diagramas possuem equivalência semântica, isto é, podem ser convertidos de um diagrama para outro. Entretanto, isso não significa que os dois diagramas visualizarão as mesmas informações explicitamente. Por exemplo:

Diagrama de colaboração mostra como os objetos estão vinculados (estereótipos <<local>> e <<global>>)

Diagrama de seqüência mostra o retorno da mensagem (committed)



Figura 40 - Equivalência entre Diagrama de Seqüência e Diagrama de Colaboração

Usos comunsModelagem de aspectos dinâmicos (classes e classes ativas, interfaces, componentes e nós)Modelagem de aspectos dinâmicos do sistema no contexto do sistema como um todo, um subsistema, uma

operação ou uma classe.Pode-se anexar diagramas de interação aos casos de uso (cenário) e às colaborações (modelagem dos aspectos

dinâmicos de uma sociedade de objetos).Para modelagem dos aspectos dinâmicos de um sistema, existem duas maneiras de utilizar os diagramas de

interação:1. Para a modelagem dos fluxos de controle por ordenação temporal (Seqüência).

Cenário de um Caso de Uso. Visualização de iteração e ramificação simples.

Defina o contexto para a interação (sistema, subsistema, operação ou classe, cenário de caso de uso ou colaboração).

Distribuir os objetos da esquerda para a direita (+ importantes).

Definir a linha de vida de cada objeto.

Distribuir as mensagens de cima para baixo.

Se for necessário visualizar o aninhamento das mensagens ou dos pontos no tempo, adorne a linha de vida de cada objeto.

Se for necessário especificar restrições de tempo ou espaço, adorne cada mensagem (marca de tempo e restrições de tempo ou espaço).

Se for necessário especificar o fluxo de controle de modo mais formal, anexe pré e pós- condições a cada mensagem.

Mostrar em um diagrama um fluxo de controle, se necessário mostrar variações, construa outro diagrama.Pode-se agrupar os diagramas de interação em pacotes.


Unipampa – Campus Bagé2. Para a modelagem de fluxos de controle por organização (Colaboração).

Visualização de iteração e ramificação complexas e para a visualização de vários fluxos de controle concorrentes.

Defina o contexto para a interação (sistema, subsistema, operação ou classe, cenário de caso de uso ou colaboração).

Distribuir os objetos como vértices de um gráfico (ou grafo), deixando os mais importantes no centro.

Defina as propriedades iniciais. Se as propriedades de um objeto se modificarem durante a interação, duplique estes objetos (conecte-os com <<become>> ou <<copy>>) e mostre estas propriedades sendo atualizadas.

Especifique os vínculos entre os objetos (e as mensagens).1. Distribua primeiro os vínculos da associação (conexões estruturais)2. Após os outros vínculos e adorne-os (<<global>>, <<local>>) para especificar como esses objetos

estão relacionados.

Define número de seqüência entre as mensagens

Se for necessário especificar restrições de tempo ou espaço, adorne cada mensagem (marca de tempo e restrições de tempo ou espaço)

Se for necessário especificar o fluxo de controle de modo mais formal, anexe pré e pós- condições a cada mensagem

16Casos de UsoUm caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma descrição de um

conjunto de seqüências de ações, incluindo variantes realizadas pelo sistema realizadas pelo sistema para produzir um resultado observável do valor de um ator.

Os casos de uso podem ser aplicados para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado.

Os casos de uso servem para ajudar a validar a arquitetura e para verificar o sistema à medida que ele evolui durante seu desenvolvimento.

Um caso de uso descreve um conjunto de seqüências, cada uma representando a interação de itens externos ao sistema (seus atores) com o próprio sistema (e suas principais abstrações). Representa um requisito funcional do sistema como um todo. Ex. um caso de uso central em um banco é o processamento de empréstimos.

Um caso de uso envolve a interação dos atores com o sistema.Um ator representa um conjunto coerente de papéis que os usuários dos casos de uso desempenham quando

interagem com esses casos.Os atores podem ser humanos ou sistemas automatizados.Um caso de uso poderá ter variantes. Qualquer sistema interessante terá casos de uso que são versões

especializadas de outros casos de uso, que são incluídos como parte de outro caso de uso e que estendam o comportamento de outro caso de uso básico.

Representação gráfica de Caso de Uso e Ator (Ator que é empregado encarregado por empréstimos e o caso de uso para processo de empréstimos)

Figura 41 - Ator e Caso de Uso

Nomes: utiliza-se as mesmas regras aplicadas para outros elementos da UML

Casos de Uso e AtoresEmbora sejam utilizados atores durante a modelagem, estes não são, de fato, parte do sistema. Eles residem

fora do sistema.Pode-se utilizar relacionamentos de generalização entre atoresAtores conectados aos casos de uso indicam que estes se comunicam, cada um com a possibilidade de enviar e

receber mensagens.



Figura 42 - Generalização entre Atores

Casos de Uso e Fluxo de EventosPode-se especificar o comportamento de um caso de uso através da descrição do fluxo de eventos no texto de

maneira suficientemente clara para que alguém de fora possa compreendê-lo facilmente.Ao escrever o fluxo de eventos, deve-se incluir:

Como e quando o caso de uso inicia e termina;

Quando o caso de uso interage com os atores;

Quais objetos são transferidos;

Fluxo básico do comportamento (cenário básico);

Fluxo alternativo do comportamento (cenário alternativo).

Exemplo: no contexto de um sistema de caixa eletrônico, pode existir o caso de uso "Validar Usuário" (ValidateUser)

Quadro 1 - Descrição Textual do Caso de Uso Validar Usuário

Caso de Uso – Validar Usuário (ValidateUser)Fluxo de eventos principal: o caso de uso começa quando o sistema solicitar ao "Cliente" (Customer) um número PIN, seu número de identificação pessoal. O "Cliente" agora pode digitar o número PIN via teclado numérico. O "Cliente" confirma a entrada, pressionando a tecla 'Enter'. O sistema então verifica o número PIN para saber ser é válido. Se o número PIN for válido, o sistema reconhece a entrada, finalizando o caso de uso.Fluxo excepcional de eventos: o "Cliente" pode cancelar uma transação a qualquer momento, pressionando o botão Cancelar, reiniciando assim o caso de uso. Nenhuma alteração é realizada na conta do "Cliente".Fluxo excepcional de eventos: o "Cliente" pode limpar o número PIN a qualquer momento antes de submetê-lo e redigitar um novo número PIN.Fluxo excepcional de eventos: se o "Cliente" entrar um número PIN inválido, o caso de uso é reiniciado. Se isso ocorrer três vezes seguidas, o sistema cancela toda a transação, impedindo ao "Cliente" interagir com o caixa eletrônico por 60 segundos.

Pode-se especificar o fluxo de eventos de um caso de uso de diversas maneiras, incluindo texto estruturado informal, texto estruturado formal (com pré e pós-condições) e pseudocódigo.

Casos de Uso e CenáriosUm caso de uso descreve um conjunto de seqüências e não apenas uma seqüência isolada.Cada seqüência é chamada de cenário. Um cenário é uma seqüência específica de ações que ilustra o

comportamento.Os cenários estão para os casos de uso como as instâncias estão para as classes. Um cenário é basicamente uma

instância de um caso de uso.

Casos de Uso e ColaboraçõesOs casos de uso devem ser implementados e isso é feito pela criação de uma sociedade de classes e de outros

elementos que trabalham em conjunto para a implementação do comportamento desse caso de uso. Essa sociedade de elementos, incluindo as estruturas estática e dinâmica, é modelada na UML como uma colaboração.

Figura 43 - Caso de Uso e Colaboração


Unipampa – Campus BagéOrganização dos casos de usoCasos de Uso podem ser organizados em pacotes. Podem existir relacionamentos de generalização, inclusão e extensão entre casos de uso.Estes relacionamentos são aplicados com a finalidade de fatorar o comportamento comum (obtendo esse

comportamento a partir de outros casos de uso que ele inclui - <<include>>) e de fatorar variantes (obtendo esse comportamento em outros casos de uso que o estendem - <<extend>>)

Generalização: o caso de uso filho acrescenta ou sobrescreve o comportamento de seu caso de uso pai.Inclusão: caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma

localização especificada na base. Para especificar a localização em um fluxo de eventos no qual o caso de uso base inclui o comportamento de um outro, simplesmente escreve-se "include", seguido pelo nome o caso de uso que se deseja incluir. Exemplo:

Quadro 2 - Caso de Uso Track Order

Caso de Uso: Track OrderFluxo principal de eventos: Obter e verificar o número do pedido. include (Validate User). Para cada parte do pedido, consulte seu status e depois retorne um relatório para o usuário.

Extensão: o caso de uso base incorpora implicitamente o comportamento de um outro caso de uso em um local especificado indiretamente pelo caso de uso estendido. O caso de uso base poderá permanecer isolado, mas, sob certas condições, seu comportamento poderá ser estendido pelo comportamento de um outro caso de uso. Esse caso de uso base poderá ser estendido somente em determinados pontos (pontos de extensão). Considere extensão como casos de uso estendido que envia um comportamento para o caso de uso base. A extensão é utilizada para a modelagem de um comportamento opcional do sistema. Os pontos de extensão são apenas rótulos que poderão aparecer no fluxo do caso de uso base. Exemplo:

Quadro 3 - Casos de Uso Place Order

Caso de Uso: Place OrderFluxo principal de eventos: include(Validate User). Receba os itens do pedido do usuário. (set priority). Submeta o pedido para o processamento.

Organizar os casos de uso, extraindo o comportamento comum (por meio de relacionamentos de inclusão) e diferenciando as variantes (por relacionamentos estendidos) é uma parte importante para a criação de um conjunto de casos de uso simples, equilibrado e compreensível, para o sistema em modelagem.

Figura 44 - Relacionamentos entre Casos de Uso

Casos de Uso podem possuir atributos (objetos encontrado no caso de uso cujo comportamento externo você precisará descrever) e operações (ações do sistema cujo fluxo de eventos será necessário descrever).

Pode-se também anexar máquinas de estado aos casos de uso (uma outra forma de descrever o comportamento).

Aplicação de casos de uso é importante por:1. Especificar uma visão externa em um grau suficiente para o entendimento de todos. Comunicação entre os

interessados no sistema.2. Fornecer uma forma de os desenvolvedores abordarem um elemento e compreendê-lo.3. Fornecer uma base para testar cada elemento. Validação de implementação do caso de uso (teste de

regressão).Exemplo: Sistema de Vendas a Varejo interage com os clientes que incluem e acompanham seus pedidos. O sistema, por

sua vez, remeterá pedidos e cobrará dos clientes.



Figura 45 - Casos de Uso com Inclusão e Extensão

17Diagrama de Casos de UsoUm diagrama de caso de uso é um diagrama que mostra um conjunto de casos de uso e atores e seus

relacionamentos.Os diagramas de casos de uso são importantes para visualizar, especificar e documentar o comportamento de

um elemento (aspectos dinâmicos).

Figura 46 - Diagrama de Casos de Uso

Diagramas de casos de uso costumam conter:

Casos de Uso

Atores

Relacionamentos de dependência, generalização e associação

Usos Comuns dos Diagramas de Casos de UsoVisão estática do Caso de Uso do Sistema (comportamento do sistema - serviços externamente visíveis que o

sistema fornece no contexto de seu ambiente)

Duas maneiras de utilização:1. Fazer a modelagem do contexto de um sistema. É desenhada a fronteira do sistema. São declarados

quais atores interagem com o sistema e o significado de seus papéis.2. Fazer a modelagem dos requisitos de um sistema. Especificação do que o sistema deverá fazer

(ponto de vista externo ao sistema). Comportamento desejado do sistema.


Unipampa – Campus BagéModelagem do Contexto do SistemaContexto: são todos os elementos externos ao sistema e que interagem com o mesmo.Para fazer a modelagem do contexto de um sistema:

Identificar os atores que se encontram ao redor do sistema. Que grupos precisam de sistemas de ajuda, que são necessários para a execução de funções do sistema, que interagem com algum hardware externo ou outros sistemas e que grupos realizam funções secundárias de administração e de manutenção.

Organizar os atores semelhantes em uma hierarquia

Ofereça um estereótipo para cada ator

Preencher um diagrama de caso de uso com esses atores a especificar os caminhos de comunicação entre os atores e os casos de uso.

Figura 47 - Modelagem do Contexto de um Sistema

Modelagem dos Requisitos de um SistemaUm requisito é uma característica de projeto, uma propriedade ou um comportamento de um sistema

(contrato). Pode-se expressar a maioria, se não todos, os requisitos de um sistema através de casos de uso e os diagramas de casos de uso são essenciais para o gerenciamento desses requisitos.

Para fazer a modelagem dos requisitos de um sistema:

Estabelecer o contexto do sistema (atores)

Para cada ator, considerar o comportamento que cada um espera ou requer

Nomear os comportamentos comuns (casos de uso)

Faça a fatoração do comportamento comum (<<include>>) e comportamento variante (<<extend>>).

Faça a modelagem desses casos de uso, atores e seus relacionamentos em um diagrama de casos de uso

Inclua adornos nesses casos de uso com notas declarando requisitos não-funcionais; poderá ser necessário anexar alguns deles à todo o sistema.



Figura 48 - Modelagem dos Requisitos de um Sistema

18Diagramas de AtividadeUm diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma

atividade para outra.Uma atividade é uma execução não-atômica em andamento em uma máquina de estados. Resultam em alguma

ação, formada pelas computações atômicas executáveis que resultam em uma mudança de estado do sistema ou o retorno de um valor.

As ações abrangem a chamada a outras operações, enviando um sinal, criando ou destruindo um objeto ou alguma computação pura, como o cálculo de uma expressão.

Um diagrama de atividades é essencialmente um "fluxograma" que dá ênfase à atividade que ocorre ao longo do tempo.

ConteúdoO diagrama de atividades costuma conter:

Estados de atividade e estados de ação

Transições

ObjetosUm diagrama de atividades é basicamente a projeção de elementos encontrados em um gráfico de atividades,

um caso especial de uma máquina de estados, em que todos ou a maioria dos estados de atividades e em que todas ou a maioria das transições são ativadas pela conclusão de atividades no estado de origem. Como o diagrama de atividades á um tipo de máquina de estados, aplicam-se todas as características de máquina de estados. Isso significa que os diagramas de atividades podem conter estados simples e compostos, ramificações, bifurcações e uniões.



Figura 49 - Diagrama de Atividades

Estado de Ação: Computações atômicas executáveis são chamadas estados de ação, porque são estados do sistema. Cada uma representando a execução de uma ação.

Os estados de ação não podem ser decompostos e são atômicos (não é interrompido)

Figura 50 - Estados de Ação

Estado de Atividade: os estados de atividades podem ser decompostos, suas atividades sendo representadas por outros diagramas de atividades.

Os estados de atividades são não-atômicos, significando que poderão ser interrompidos e, em geral, são considerados como tomando algum tempo para serem completados.

Não existe distinção notacional entre estados de ação e de atividades, exceto que estados de atividades podem admitir partes adicionais (ações de entrada e saída e especificações de submáquinas).

Figura 51 - Estados de Atividades

TransiçõesQuando a ação ou atividade de um estado está completa, o fluxo de controle passa imediatamente ao estado

seguinte de ação ou de atividade.Esse fluxo é especificado utilizando transições.

RamificaçãoPode-se incluir nos diagramas de atividades ramificações, especificando caminhos alternativos, tomados com

base em alguma expressão booleana.


Unipampa – Campus BagéAs proteções (guard) associadas às transições de uma ramificação não podem se sobrepor (ambíguas) mas

devem cobrir todas as possibilidades (caso contrário, o fluxo de controle congelaria).A palavra "else" pode ser mascada como uma transição de saída.

Bifurcação e UniãoPodem ser modelados fluxos concorrentesBifurcação - uma única transição de entrada e duas ou mais transições de saída.União - pode ter duas ou mais transições de entrada e uma única transição de saída.

Raias de natação (Swimlane)Particionam em grupos de estados de atividades de um diagrama de atividades.Cada grupo representa a organização de negócio responsável por essas atividades.Cada grupo é chamado de um raia de natação.

Fluxo de ObjetosOs objetos poderão estar envolvidos no fluxo de controle associado com um diagrama de atividade.Objetos envolvidos em um diagrama de atividades podem ser produzidos, alterados ou destruídos pelas

atividades.

Usos Comuns1. Para fazer a modelagem de um fluxo de trabalhoFluxos de Trabalho costumam ser processos de negócio. Pode-se usar diagramas de atividades para especificar

processos de desenvolvimento de software (gerenciamento de configuração) ou processos que não são software (fluxo de pacientes em um sistema de assistência médica).

Estabelecer um foco para o fluxo de trabalho

Selecionar os objetos de negócio que têm responsabilidades

Identificar as pré-condições do estado inicial e as pós-condições do estado final

Especificar as atividades e ações realizadas

Ações complicadas ou conjunto de ações (estados de atividades)

Represente as transições

Caso existam objetos importantes envolvidos, represente-os (mostrando estado e valores modificados)

Exemplo: Modelagem de um fluxo de trabalho de uma empresa de varejoFluxo: Cliente devolve um item de um pedido postal

Figura 52 - Modelagem de um Fluxo de Trabalho


Unipampa – Campus Bagé2. Para fazer a modelagem de uma operação

Colecione as abstrações envolvidas na operação (parâmetros, atributos e classes vizinhas)

Identificar as pré-condições do estado inicial e as pós-condições do estado final

Especificar as atividades e ações realizadas

Use ramificações conforme necessário

Se for uma operação pertencente a uma classe ativa, use bifurcações e uniões para especificar fluxos de controle paralelos.

Figura 53 - Modelagem de uma Operação

19Eventos e SinaisEvento: é a especificação de uma ocorrência significativa que tem uma localização no tempo e no espaço. No

contexto de máquina de estados, o evento é uma ocorrência de um estímulo capaz de ativar a transição de um estado.Na UML pode-se fazer a modelagem de quatro tipos de eventos: sinais, chamadas, contagem de tempo e

alteração no estado.

Figura 54 – Eventos e Sinais

Sinal: é um tipo de evento que representa a especificação de um estímulo assíncrono comunicado entre instâncias. Eventos podem ser externos e internos. Um sinal representa um objeto nomeado que é despachado (lançado) de maneira assíncrona por um objeto e então recebido (pego) pelo outro. As exceções são suportadas pela maioria das linguagens de programação mais contemporâneas e são os tipos de sinal internos mais comuns cuja modelagem pode ser necessária.

Figura 55 - Sinal

Chamada: representa a ativação de uma operação (pode ativar a transição de estado). Em geral, é um evento síncrono.



Figura 56 - Chamada

Eventos de tempo e alteração

um evento de tempo representa a contagem de tempo.. Utiliza-se a palavra reservada "after" seguida de alguma expressão calculada que estima um período de tempo.

um evento de alteração representa uma mudança no estado ou a satisfação de alguma condição. Utiliza-se a palavra reservada "when" seguida de alguma expressão booleana.

Figura 57 - Eventos de Tempo e Alteração

Eventos enviar e receberOs eventos de sinal e de chamada contêm pelo menos dois objetos: o objeto que envia o sinal ou chama a

operação e o objeto para onde o evento é direcionado. Modelagem de uma família de sinais

Figura 58 - Modelagem de uma família de sinais

Modelagem de Exceções



Figura 59 - Modelagem de Exceções

20Máquinas de EstadosUsando uma interação, pode-se fazer a modelagem do comportamento de uma sociedade de objetos que

trabalham em conjunto. Usando uma máquina de estados, pode-se fazer a modelagem do comportamento de um objeto individual. As máquinas de estados servem para a modelagem de aspectos dinâmicos de um sistema, envolvendo a especificação do tempo de vida das instâncias de uma classe, um caso de uso ou um sistema inteiro.

Estas instâncias poderão responder a eventos como sinais, operações ou passagem de tempo. Quando um evento ocorre, alguma atividade acontecerá, dependendo do estado atual do objeto.

Uma atividade é uma execução não-atômica em andamento em uma máquina de estados.As atividades acabam resultando em alguma ação, formada por computações atômicas executáveis que

resultam em uma alteração do estado do modelo ou no retorno de um valor. O estado de um objeto é a condição ou situação durante a vida de um objeto durante o qual ele satisfaz alguma condição, realiza alguma atividade ou aguarda algum evento.

Uma máquina de estados pode ser visualizada de duas maneiras:1. Dando ênfase ao fluxo de controle de uma atividade para outra (diagrama de atividades). Foco nas

atividades realizadas no objeto.2. Dando ênfase aos estados potenciais dos objetos e às transições entre esses estados (diagramas de

gráficos de estados). Foco no comportamento ordenado por eventos de um objeto, o que é de grande ajuda para a modelagem de sistemas reativos.

Uma máquina de estados o tempo de vida de um único objeto, seja ele a instância de uma classe, um caso de uso ou até o sistema inteiro.

Figura 60 - Máquina de Estados


Unipampa – Campus BagéObjetos não precisam de uma máquina de estados para especificar seu comportamento quando o

comportamento atual não depende de seu passado (Cliente - operação pegarSaldo - ContaCorrente).Objetos cujo comportamento depende de seu comportamento passado. (Sistema de orientação de mísseis

aéreos)

EstadosUm Estado tem várias partes:1. Nome : nome único que o diferencie dos demais estados. Um estado pode ser anônimo.2. Ações de entrada/saída: ações executadas na entrada e saída do estado.3. Transições internas: transições manipuladas sem causar alteração do estado.4. Subestados : a estrutura aninhada de um estado, envolvendo subestados disjuntos (seqüencialmente ativos)

ou concorrentes (concorrentemente ativos).5. Eventos adiados: uma lista de eventos que não são manipulados nesse estado, mas, em vez disso, são

adiados e colocados em fila para serem manipulados pelo objeto em outro estado.

TransiçõesUma transição tem cinco partes:1. Estado de origem : o estado afetado pela transição; se um objeto estiver no estado de origem, uma

transição de saída poderá ser iniciada quando o objeto receber o evento de ativação da transição e se a condição de proteção, se houver, for satisfeita.

2. Evento de ativação : o evento cuja recepção pelo objeto no estado de origem faz com que a transição possa ser escolhida para ser ativada, desde que sua condição de proteção seja satisfeita.

3. Condição de proteção : uma expressão booleana que á avaliada quando a transição é iniciada pela recepção do evento de ativação; se a expressão for avaliada como verdadeira, a transição será escolhida para iniciar; se a expressão for avaliada como falsa, a transição não será iniciada e, caso não haja outra transição que possa ser iniciada pelo mesmo evento, esse evento é perdido.

4. Ação : uma computação atômica executável que poderá agir diretamente no objeto ao qual a máquina de estados pertence e indiretamente em outros objetos que são visíveis ao objeto.

5. Estado destino : o estado que está ativo após a conclusão da transição.

Figura 61 - Transições

Evento de ativaçãoOcorrência de um estímulo capaz de ativar uma transição de estado.Pode existir uma transição não-ativada, representada por uma transição sem um evento de ativação. A transição

não-ativada (transição de conclusão) é iniciada implicitamente, quando seu estado de origem completa sua atividade.

Condição de proteçãoSomente é avaliada após o evento de ativação para sua transição ocorrer. Pode haver várias transições a partir

do mesmo estado de origem e com o mesmo evento de ativação, desde que essas condições não se sobreponham.

Transições e estados avançados

Figura 62 - Transições e Estados Avançados

Ações de entrada e saídaAção de entrada (entry): ação realizada sempre na entrada no estadoAção de saída (exit): ação realizada sempre na saída no estado



Transições internasUma vez no estado, você encontrará eventos que desejará manipular sem sair desse estado. Estes casos são

chamados transições internas e são sutilmente diferentes das autotransições.Em uma autotransição, um evento ativa a transição, o foco de execução sai do estado, uma ação (se houver) é

iniciada e depois a execução volta novamente para o mesmo estado. A autotransição realiza a ação de saída do estado e depois inicia a ação de autotransição; por fim, ela ativa a ação de entrada no estado.

Se há a necessidade de manipular eventos dentro de um estado, mas sem a execução de ações de saída e entrada, então se utiliza uma transição interna para manipular estes eventos.

AtividadesModelagem de uma atividade em andamento, isto é, enquanto a execução estiver em um determinado estado,

uma ação permanecerá sendo realizada até ser interrompida por um evento. Marca-se a atividade com "do".

Eventos adiadosÉ marcado com "defer". Um evento pode acontecer enquanto estiver em um estado, mas será adiado e

nenhuma ação resultará devido à presença desse evento. Um evento adiado é uma lista de eventos cuja ocorrência no estado é adiada até um estado em que os eventos listados não são adiados e se tornam ativos; nesse momento eles ocorrem e podem ativar transições como se tivesse acabado de ocorrer.

SubestadosUm estado simples é um estado que não tem subestrutura. Um estado que contém subestados - ou seja, estados

aninhados - é chamado um estado composto. Um estado composto pode conter outros subestados concorrentes (ortogonais) ou seqüenciais (disjuntos) - que podem, também, ser estados compostos.

Subestados seqüenciais

Figura 63 - Estados de um caixa eletrônico

Estados de histórico (estado com o símbolo H)Modelagem de um objeto de forma que ele lembre o último subestado que se encontrava ativo antes de deixar

o estado composto.



Figura 64 - Estados de Histórico

O símbolo H designa um histórico superficial (ShallowHistory), capaz de lembrar somente o histórico da máquina de estados aninhada imediata. Você também poderá especificar um histórico profundo (DeepHistory), mostrado como um pequeno círculo contendo o símbolo H*. O histórico profundo é capaz de lembrar o estado aninhado mais interno em qualquer profundidade.

Subestados concorrentesQuando o controle passa para um estado composto com subestados concorrentes, o controle se divide em dois

ou mais fluxos concorrentes. A máquina de estados aninhada concorrente não precisa ter um estado inicial, final ou de histórico. Entretanto, os subestados seqüenciais que formam um estado concorrente precisarão ter essas características.

Figura 65 - Subestados Concorrentes

O propósito mais comum de uma máquina de estados é a modelagem do tempo de vida de um objeto (instância de classes, casos de uso e o sistema como um todo).

Neste tipo de modelagem, é necessário especificar três itens essencialmente: os eventos aos quais o objeto pode responder, a resposta a esses eventos e o impacto do passado no comportamento atual.

Para fazer a modelagem do tempo de vida de um objeto:

Defina o contexto para a máquina de estados1. Se o contexto é uma classe ou um caso de uso, coleciona as classes vizinhas (classe mãe e

quaisquer classes que possam ser alcançadas por associações ou dependências). Esses vizinhos são prováveis alvos de ações e são candidatos para a inclusão de condições de proteção.

2. Se o contexto é o sistema, restrinja o foco a um único comportamento.

Estabelecer estados iniciais e finais (e pré e pós-condições de cada)

Definir a quais eventos esse objeto irá responder.

Distribuir os estados de nível superior em que o objeto poderá estar e conecte-os com transições ativadas pelos eventos apropriados.



Identificar ações de entrada e saída.

Expanda, quando necessário, os estados com subestados

Figura 66 - Modelagem do tempo de vida de um objeto

Controlador de um sistema de segurança doméstico

21Diagramas de Gráficos de EstadosUm diagrama de gráfico de estados mostra uma máquina de estados, dando ênfase ao fluxo de controle de um

estado para o outro. Um diagrama de gráfico de estados costuma conter:

Estados simples e estados compostos

Transições, incluindo eventos e ações

Um diagrama de gráfico de estados é basicamente uma projeção dos elementos encontrados em uma máquina de estados. Isso significa que os diagramas de gráficos de estados poderão conter ramificações, bifurcações, uniões, estados de ações, estados de atividades, objetos, estados iniciais e finais, estados de históricos e assim por diante. Na verdade, um diagrama de gráficos de estados poderá conter toda e qualquer característica de uma máquina de estados. O que diferencia um diagrama de atividades de um diagrama de gráficos de estados é que um diagrama de atividades é basicamente uma projeção dos elementos encontrados em um gráfico de atividades, um caso especial de uma máquina de estados em que todos ou a maioria dos estados são estados de atividades e que todas ou a maioria das transições são ativadas pela conclusão de atividades no estado de origem.

Os diagramas de gráficos de estados podem ser empregados para fazer a modelagem dos aspectos dinâmicos de um sistema. Esses aspectos dinâmicos podem envolver o comportamento ordenado por eventos de qualquer tipo de objeto em qualquer visão da arquitetura do sistema, incluindo classes (classes ativas), interfaces, componentes e nós.

Tipicamente utiliza-se os diagramas de gráficos de estados para a modelagem no contexto do sistema como um todo, de um subsistema ou de uma classe (e também casos de uso para a modelagem de um cenário).

Então, normalmente, utiliza-se os diagramas de gráficos de estados para fazer a modelagem dos aspectos dinâmicos de "Objetos Reativos"

Um objeto reativo - ou orientado por eventos - é aquele cujo comportamento é mais bem caracterizado pela sua resposta a eventos ativados externamente ao seu contexto.

A modelagem de objetos reativos (instâncias de classes, casos de uso e sistema) é o propósito mais comum dos diagramas de gráficos de estados.

Enquanto as interações modelam o comportamento de uma sociedade de objetos trabalhando em conjunto, o diagrama de gráficos de estados modela o comportamento de um único objeto ao longo de seu tempo de vida. Enquanto o diagrama de atividades modela o fluxo de controle de uma atividade para a outra, o diagrama de gráficos de estados modela o fluxo de controle de um evento para outro.

22ColaboraçõesUma colaboração permite nomear um agrupamento conceitual que abrange aspectos estáticos e dinâmicos. Uma colaboração nomeia uma sociedade de classes, interfaces e outros elementos que trabalham em conjunto

para fornecer algum comportamento cooperativo maior do que a soma de todas as suas partes.


Unipampa – Campus BagéAs colaborações são empregadas para especificar a realização de casos de uso e operações e para fazer a

modelagem de mecanismos significativos da arquitetura do sistema.Estrutura de uma Colaboração

Parte estrutural: combinação de classificadores (classes, interfaces, componentes e nós) que trabalham em conjunto para executar a colaboração. Ex. Modelo de classes.

Parte comportamental: especifica a dinâmica de como esses elementos interagem. Ex. Diagrama de interação.

Usos Comuns

Modelagem da realização de um caso de uso.

Modelagem da realização de uma operação.

Modelagem de um mecanismo.

23ComponentesOs componentes vivem no mundo material dos bits e, portanto, são um dos mais importantes blocos de

construção para a modelagem de aspectos físicos de um sistema. Um componente é a parte física e substituível de um sistema ao qual se adapta e fornece a realização de um conjunto de interfaces.

Os componentes são empregados para a modelagem de coisas físicas que podem residir em um nó, como executáveis, bibliotecas, tabelas, arquivos e documentos. Um componente tipicamente representa o pacote físico de elementos lógicos, como classes, interfaces e colaborações.

Bons componentes definem abstrações com interfaces bem-definidas, tornando possível substituir facilmente componentes mais antigos por outros componentes mais novos.

Na UML, todas as coisas físicas (residem nos nós) são modeladas como componentes. Um componente é a coisa física que se adapta e realiza um conjunto de interfaces.

Muitos SO (Sistemas Operacionais) e LP (Linguagens de Programação) oferecem suporte direto para o conceito de um componente. As bibliotecas de objetos, os executáveis, os componentes COM+ e Enterprise Java Beans são todos exemplos de componentes que poderão ser representados diretamente na UML pela utilização dos componentes.

Figura 67 - Componentes

Os componentes são semelhantes às classes. Ambos possuem nome, podem realizar um conjunto de interfaces, podem participar de um relacionamento de dependência, generalização e associação, podem ser aninhados, admitem instâncias, podem ser participantes de interações.

Entretanto, existem algumas diferenças:

As classes representam abstrações lógicas; os componentes representam coisas físicas que vivem no mundo dos bits. Componentes podem viver em nós, as classes não.

Os componentes representam o pacote físico de componentes lógicos e se encontram em um nível diferente de abstração.

As classes podem ter atributos e operações diretamente. Em geral, os componentes somente têm operações que são alcançadas por meio de suas interfaces.

Componentes e interfaces



Figura 68 - Componentes e Interfaces

Uma interface realizada por um componente é chamada "Interface de Exportação".Uma interface utilizada pelo componente é chamada "Interface de Importação".

Substituição bináriaO propósito básico de qualquer facilidade de um SO baseado em componentes consiste em permitir a

montagem de sistemas a partir de partes binárias substituíveis.Um componente é uma parte física e substituível de um sistema, que está em conformidade e proporciona a

realização de um conjunto de interfaces.

Tipos de componentes:1. Componentes de Implantação - componentes necessários e suficientes para formar um sistema

executável, como as bibliotecas (DLL´s) e os executáveis (EXE´s). A definição da UML para componentes é suficientemente ampla para incluir modelos clássicos de objeto, como COM+, CORBA e Enterprise Java Beans, além de modelos alternativos de objeto, talvez envolvendo páginas da Web dinâmicas, tabelas de BD e executáveis utilizando mecanismos proprietários de comunicação.

2. Componentes de Produto de Trabalho - são essencialmente o resíduo do processo de desenvolvimento, formado por coisas como arquivos de código-fonte e arquivos de dados a partir dos quais os componentes de implantação são criados.

3. Componentes de Execução - são criados como uma conseqüência de um sistema em execução, como um objeto COM+, que é instanciado a partir de uma DLL.

Componentes podem ser agrupados em pacotes.

Elementos-padrãoTodos os mecanismos de extensibilidade da UML se aplicam aos componentes. Normalmente, utiliza-se

valores atribuídos para estender as propriedades (versão) e estereótipos para especificar novos tipos de componentes (componentes específicos de SO)

A UML define cinco estereótipos-padrão que se aplicam aos componentes:1. executável: especifica um componente que poderá ser executado em um nó.2. biblioteca: especifica uma biblioteca de objetos estática ou dinâmica.3. tabela: especifica um componente que representa uma tabela de BD.4. arquivo: especifica um componente que representa um documento contendo código-fonte ou dados.5. documento: especifica um componente que representa um documento.

Figura 69 - A modelagem de executáveis e de bibliotecas



Figura 70 - A modelagem de tabelas, arquivos e documentos

Figura 71 - A modelagem de um API (interfaces de programação de aplicações)

Figura 72 - A modelagem de código-fonte

24Diagrama de ComponentesMostra a organização e as dependências existentes entre um conjunto de componentes.São utilizados principalmente para a modelagem de itens físicos que residem em um nó (executáveis,

bibliotecas, tabelas, arquivos e documentos).

Usos comunsModelagem de visão estática de implementação de um sistema.Esta perspectiva primariamente proporciona suporte ao gerenciamento da configuração das partes de um

sistema.Quatro maneiras de utilização:1. Modelagem de código-fonte

Podem ser utilizados para o gerenciamento de configuração dos arquivos de código-fonte.

Visualizar as dependências de compilação.

Gerenciamento de versões.



Figura 73 - Modelagem de Código-Fonte

2. Modelagem de versões executáveis

Uma versão focaliza as partes necessárias para a liberação do sistema em execução. Possibilitam a visualização, especificação e documentação das decisões a respeito das partes físicas que constituem o software (componentes a serem entregues).

Configuração das versões executáveis

Ao criar diagramas de componentes, se está modelando apenas uma parte dos itens e relacionamentos que formam a visão de implementação de um sistema.

Figura 74 - Modelagem de uma versão executável

3. Modelagem de banco de dados físicos

Representa o armazenamento de informações nas tabelas de um BD relacionam ou nas páginas de um BDOO.

Um esquema de BD lógico captura o vocabulário de dados persistentes de um sistema, juntamente com a semântica de seus relacionamentos.

Mapeamento de um BD lógico para um BDOO é relativamente simples

Mapeamento de um BD lógico para um BD relacional não é tão simples

Na presença de herança, é necessário decidir como mapear classes em tabelas. Estratégias:1. Definir um tabela separada para cada classe. Solução simples, mas ingênua. Trabalhoso

para adicionar classes-filha ou modificar classes-mãe2. Resumir as heranças, de forma que todas as instâncias de qualquer classe em uma

hierarquia tenham o mesmo estado. Armazenamento de informações supérfluas para muitas instâncias.

3. Separar estados de classes-mãe e filha em tabelas diferentes. Reflete melhor a herança, mas a desvantagem é que para o cruzamento dos seus dados serão necessárias várias uniões de tabelas de referência cruzada.

Como mapear operações definidas no esquema de BD lógico: Opções:1. Para simples operações de criar, ler, atualizar e excluir, implemente-as com chamadas

SQL ou ODBC padrão.2. Para um comportamento mais complexo (como regras de negócios), mapeie-as para

ativação ou para procedimentos de armazenamento.



Figura 75 - Modelagem de um banco de dados físico

4. Modelagem de sistemas adaptáveis.

Alguns sistemas são dinâmicos, envolvendo agentes móveis ou componentes que migram com a finalidade de equilibrar a carga de trabalho e evitar erros. Os diagramas de componentes são utilizados em conjunção com alguns diagramas da UML destinados à modelagem de comportamento, para representar esses tipos de sistemas.

Modelagem de visões dinâmicas

Modelagem de agentes móveis (componentes que migram de um nó para outro executando alguma transação).

Figura 76 - Modelagem de sistemas adaptáveis

25ImplantaçãoUm nó é um elemento físico que existe em tempo de execução e representa um recurso computacional,

geralmente tendo pelo menos alguma memória e, freqüentemente, capacidade de processamento. Os nós são empregados para a modelagem da topologia do hardware em que o sistema é executado. Um nó

tipicamente representa um processador ou um dispositivo em que os componentes poderão ser instalados.Quando se define a arquitetura de um sistema complexo de software, é preciso considerar as dimensões lógica

e física do sistema. Na parte lógica encontram-se ítens como classes, interfaces, colaborações, interações e máquinas de estados. Na parte física encontram-se os componentes (que representam o pacote físico desses itens lógicos) e os nós (que representam o hardware em que esses componentes são instalados e executados).

Figura 77 - Nós - Implantação

Nós e Componentes são semelhantes:


Unipampa – Campus BagéAmbos possuem nome, podem participar de relacionamentos de dependência, generalização e associação,

podem ser aninhados, admitem instâncias, podem ser participantes de interações.Entretanto, existem algumas diferenças:

Os componentes são itens que participam da execução de um sistema; os nós são itens que executam os componentes.

Os componentes representam os pacotes físicos de elementos lógicos; os nós representam o funcionamento físico dos componentes.

Um conjunto de objetos ou componentes que são alocados a um nó como um grupo é chamado de "unidade de distribuição".

Os nós podem ser organizados em pacotes e podem possuir relacionamentos de dependência, generalização e associação (incluindo agregação) entre si.

ConexõesRelacionamento mais comum entre os nós. Representa uma conexão física entre os nós (como uma conexão

Ethernet, uma linha serial ou um barramento compartilhado).Podem ser utilizadas associações para fazer a modelagem de conexões indiretas, como uma ligação de satélite

entre processadores distantes.Como os nós são parecidos com as classes, pode-se utilizar todo os elementos disponíveis através de

associações, como: papéis, multiplicidade e restrições.

Figura 78 - Conexões entre Nós

A modelagem dos processadores e dispositivos que formam a topologia de sistemas isolados, embutidos, cliente/servidor ou distribuídos é a utilização mais comum dos nós.

Modelagem de processadores e dispositivosPode-se utilizar os seguintes estereótipos:

processador: é um nó que tem capacidade de processamento (pode executar um componente)

dispositivo: é um nó que não tem capacidade de processamento e, em geral, representa algo como interfaces para o mundo real.

Figura 79 - Processadores e dispositivos (estereotipados)

Modelagem de distribuição de componentesPara fazer a modelagem da distribuição dos componentes

Para cada componente significativo existente no sistema, faça sua alocação para um determinado nó.

Considerar as localizações duplicadas para os componentes (não é incomum para o mesmo tipo de componente residir em vários nós simultaneamente).

Representar esta alocação:1. Não tornando visível, mas na especificação de cada nó.2. Utilizando relacionamentos de dependência conectando cada nó com os componentes nele instalados.3. Liste os componentes instalados em um nó em um compartimento adicional.



Figura 80 - A modelagem da distribuição de componentes

26Diagramas de ImplantaçãoO diagrama de implantação mostra a configuração dos nós de processamento em tempo de execução e os

componentes que nele existem.Os diagramas de implantação podem ser utilizados para visualizar o aspecto estático desses nós físicos e seus

relacionamentos e para especificar seus detalhes referentes à construção.

Figura 81 - Diagrama de Implantação

Usos Comuns1. Para fazer a modelagem de sistemas embutidos2. Para fazer a modelagem de sistemas cliente/servidor

Figura 82 - Modelagem de sistemas cliente/servidor

3. Para fazer a modelagem de sistemas totalmente distribuídos



Figura 83 - Modelagem de sistemas totalmente distribuídos

27Sistemas e ModelosUm sistema, possivelmente decomposto em uma coleção de subsistemas, é um conjunto de elementos

organizados para a realização de um propósito e é descrito como um conjunto de modelos, possivelmente sob pontos de vista diferentes. Um subsistema é um agrupamento de elementos, alguns dos quais constituem a especificação do comportamento oferecido por outros elementos nele contidos.

Uma visão é uma projeção de um modelo, visto sob uma perspectiva ou ponto de vista e omite entidades que não sejam relevantes nessa perspectiva.

Na UML é possível se fazer a modelagem de sistemas e subsistemas.

Referências Bibliográficas(Booch, Rumbaugh e Jacobson, 2000) BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. (2000). UML: guia do

usuário. Rio de Janeiro: Campus. 472 p.(Jude, 2005) JUDE: Java and UML Developers´ Environment. (2005). Disponível na www em: <http://jude.esm.jp/>.

Acesso em 27 Set. 2005.(Larman, 2000)LARMAN, Craig, (2000). Utilizando UML e Padrões: uma introdução à análise e ao projeto orientados

a objetos. Porto Alegre: Bookman.(Larman, 2003)LARMAN, Craig. (2003). Applying UML and Patterns: An Introduction to Object-Oriented Analysis

and Design and the Unified Process. 2nd. Upper Saddle River: Prentice Hall.(Medeiros, 2004) MEDEIROS, Ernani. (2004). Desenvolvendo Software com UML 2.0: Definitivo. São Paulo:

Pearson - Makron Books. 264p.(Page-Jones, 2001) PAGE-JONES, Meilir. (2001). Fundamentos do Desenho Orientado a Objeto com UML.

São Paulo: Pearson Education do Brasil. 462 p.(Pfleeger, 2004) PFLEEGER, Shari Lawrence. (2004). Engenharia de Software: teoria e prática. 2ª Ed. São

Paulo: Prentice Hall. 537 p.(Rumbaugh et. al., 1994) RUMBAUGH, James; et al. (1994). Modelagem e Projetos baseados em Objetos.

Tradução: Dalton C. de Alencar. Rio de Janeiro: Campus.(Santos, 2003) SANTOS, Rafael. (2003). Introdução à Programação Orientada a Objetos usando JAVA. Rio de

Janeiro: Campus. 319 p.(Sommerville, 2003) SOMMERVILLE, Ian. (2003). Engenharia de Software. São Paulo: Addison Wesley

(Makron Books). 592 p.

Curso UML Unipampa

Documents

Transcript of Curso UML Unipampa