Curso UML Unipampa

Ministério da Educação
Universidade Federal do Pampa

Unipampa – Campus Bagé
Linguagem UML
Prof. MSc. Carlos Michel Betemps
carlos.betemps@unipampa.edu.br
1 Modelagem e Projeto Baseados em Objetos

Modelagem 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 Objetos

Orientaçã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
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 Classes
Um 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 real
2) oferecem uma base real para a implementação em computador
Todos 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 Classes
Uma 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étodos

Um 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ções

Ligaçõ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.
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 Multiplicidade
A 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ção

Um 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éis

Um 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ção
Habitualmente 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ção
Uma 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ção
Agregaçã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 Iterativo

Nesta 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 Iterativo

Alguns 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.
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 UP

Outra 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 UP
O 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).
ciclo de desenvolvimento
iteração fase
Concepção Elaboração Construção Transição
Marco Versão Versão de

Incremento Produção Final
( Milestone ) ( r elease )
( release )
Um ponto final Um subconjunto A diferença Neste ponto, o
da iteração executável e (delta) entre sistema é
quando alguma estável do os releases liberado para uso
decisão produto final. O de 2 iterações em produção
significante ou final de cada subseqüentes
avaliação iteração é uma
ocorre versão
secundária
( minor release )
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 Artefato Concepção Elaboração Construção Transição
Iteração I1 E1 .. En C1 .. Cn T1 .. T2
Modelagem de Negócios Modelo de Domínio I
Requisitos Modelo de Caso de Uso I R
Visão I R
Especificação Suplementar I R
Glossário I R
Projeto Modelo de Projeto I R
Documento de Arquitetura de I
Software
Modelo de Dados I R
Implementação Modelo de Implementação I R R
Gerenciamento de Projeto Plano de Desenvolvimento de I R R R
Software
Teste Modelo de Teste I R
Ambiente Caso de Desenvolvimento I R
3.5 O UP Ágil
O 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 Arquitetura
Visualizar, 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 Uso
Aspectos 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
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)
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 Componentes
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ção
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 Arquiteturais

Um 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 UML
2) Regras que determinam como estes blocos deverão ser combinados
3) 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 UML

Para compreensão da UML, é necessário o entendimento dos seus três elementos principais.
4.1.1 Blocos básicos de construção da UML

Existem três tipos de blocos de construção:
1. Itens
2. Relacionamentos
3. Diagramas
Itens da UML
Quatro tipos:
1. Itens estruturais
2. Itens comportamentais
3. Itens de agrupamentos
4. Itens anotacionais
Itens Estruturais
Os 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 comportamentais
Sã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 agrupamentos
Sã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 anotacionais
Sã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 UML

Quatro 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 UML
Um 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 UML

Regras 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 UML

Sã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).
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 Uso
Componentes e Instâncias de Componentes
Nó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ção
Ex.:
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 UML
Quatro mecanismos
1. Especificações
2. Adornos
3. Divisões Comuns
4. Mecanismos de Extensibilidade
5.1 Uso de Adornos e Mecanismos de Extensibilidade

Adornos
Notas: É 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 Adornos
São itens gráficos ou visuais, adicionados à notação básica.
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 Extensibilidade

Permitem 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ótipos
Pode 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ídos
Permite 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ções
Uma 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ão
A 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 modelagem

Modelagem 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ção

Utilizaçã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 propriedades

Utilização de valores atribuídos.
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ântica

Utilização de restrições:
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 Relacionamentos
Na 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.
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

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çados

Trê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ência
Existem 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ção
Em 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ções
1. 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ção
Quatro 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ção
Possibilidade 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
Visibilidade
Em 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ção
Relacionado 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).
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ção
A 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ção
Em 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ções
A 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ção
Utiliza-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 Diagramas
Um 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 Uso
2. A Visão de Projeto
3. A Visão de Processo
4. A Visão de Implementação
5. 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 classes
2. Diagrama de objetos
3. Diagrama de componentes
4. 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 uso
2. Diagrama de seqüências
3. Diagrama de colaboração
4. Diagrama de gráfico de estados
5. Diagrama de atividades
Diagramas devem possuir nomes únicos em seus contextos e normalmente são organizados em pacotes.
Diagramas estruturais
Os 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ções
2. Diagrama de objetos - Objetos
3. Diagrama de componentes - Componentes
4. 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 comportamentais
Os 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 sistema
2. Diagrama de seqüências - Tem, como foco, a ordem temporal das mensagens
3. Diagrama de colaboração - Tem, como foco, a organização estrutural de objetos que enviam e recebem
mensagens
4. Diagrama de gráfico de estados - Tem, como foco, o estado de mudança de um sistema orientado por
eventos
5. 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 Pacotes
Visualizar, especificar, construir e documentar sistemas grandes envolve a manipulação de quantidades
potencialmente grandes de classes, interfaces, componentes, nós, diagramas e outros elementos.
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 pacotes
Um 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".
Visibilidade
Cada elemento do pacote recebe um prefixo definindo sua visibilidade (como acontece com as classes).
Importação e exportação
Importaçã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ção
Utilizada 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 elementos

O 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 Classes
Sã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,
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

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 Temperatura
nomes 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ções
Uma 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 Classes
Exemplo 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 simples

Nenhuma 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 dados

Objetos 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 reversa

Modelagem é importante, mas o produto principal de uma equipe de desenvolvimento é o software e não os
diagramas. Modelos para atingir o objetivo software
Exemplo: 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çadas
As 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.
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 Web
Vocabulário do Sistema: Cliente, Transação
No 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,
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

Escopo
O 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ística
2. 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órficos

Em 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.
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
Multiplicidade
O 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.
Atributos
Cada 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
+ origin
origin : Point
head: *Item
name [0..1] : String
origin: Point = (0, 0)
id: Integer {frozen}
Três propriedades que podem ser utilizadas com os atributos:

1. chageable - sem restrições de modificação
2. 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 alterado
3. frozen - depois do objeto iniciado, o valor do atributo não poderá ser modificado
Operações
Alé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
+ display
set(n: Name, s: String)
getID(): Integer
restart() {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-template
Um 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 reais
O 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ão
A UML define 4 estereótipos-padrão que se aplicam às classes.
1. metaclass: especifica um classificador cujos objetos são todas as classes
2. powertype: especifica um classificador cujos objetos são as filhas de uma determinada mãe
3. stereotype: especifica que o classificador é um estereótipo que pode ser aplicado a outros elementos
4. utility: especifica uma classe cujos atributos e operações pertencem ao escopo da classe.
12Instâncias
Instâ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
:Frame
t:
Operações
Um 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
Estado
Pode-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ísticas
Os 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ão
Todos 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 Objetos
Os 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údo
Os 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ções
Objetos 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
Mensagens
Uma 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ção

Em 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ção
Existem 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 Controle
2. 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 comuns
Modelagem 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.
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 Uso
Um 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 Atores

Embora 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 atores
Atores 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 Eventos
Pode-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ários

Um 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ções

Os 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

Organização dos casos de uso
Casos 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 Order
Fluxo 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 Order
Fluxo 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 Uso

Um 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 Uso

Visã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.
Modelagem do Contexto do Sistema
Contexto: 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 Sistema

Um 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 Atividade
Um 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údo
O diagrama de atividades costuma conter:
Estados de atividade e estados de ação
Transições
Objetos
Um 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ções
Quando 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ção
Pode-se incluir nos diagramas de atividades ramificações, especificando caminhos alternativos, tomados com
base em alguma expressão booleana.
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ão
Podem ser modelados fluxos concorrentes
Bifurcaçã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 Objetos
Os 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 Comuns
1. Para fazer a modelagem de um fluxo de trabalho
Fluxos 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 varejo

Fluxo: Cliente devolve um item de um pedido postal
Figura 52 - Modelagem de um Fluxo de Trabalho

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 Sinais
Evento: é 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 receber
Os 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 Estados
Usando 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

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)
Estados
Um 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ções
Uma 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ção
Ocorrê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ção
Somente é 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ída
Ação de entrada (entry): ação realizada sempre na entrada no estado
Ação de saída (exit): ação realizada sempre na saída no estado
Transições internas
Uma 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.
Atividades
Modelagem 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.
Subestados
Um 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 concorrentes
Quando 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 estados
1. 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 Estados

Um 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ções
Uma 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.
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.
23Componentes
Os 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ária
O 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ão
Todos 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 Componentes
Mostra 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 comuns
Modelagem 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ãe
2. 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ção
Um 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:

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ões
Relacionamento 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 dispositivos

Pode-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 componentes
Para 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ção
O 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 Comuns
1. Para fazer a modelagem de sistemas embutidos
2. 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 Modelos
Um 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.

Idioma

Curso UML Unipampa

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso UML Unipampa

Enviado por

Direitos autorais:

Formatos disponíveis

Ministério da Educação

Universidade Federal do Pampa

1 Modelagem e Projeto Baseados em Objetos

2 Princípios da Orientação a Objetos

2.1 Conceitos da Orientação a Objetos

2.1.3 Atributos, Operações e Métodos

2.1.4 Ligações e Associações

2.1.6 Atributos de Ligação

2.1.7 Nomes de Papéis

3 Desenvolvimento Iterativo e o Processo Unificado (Unified Process - UP)

3.1 Desenvolvimento Iterativo

3.2 Benefícios do Desenvolvimento Iterativo

3.3 Melhores Práticas e Conceitos Adicionais do UP

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

Marco Versão Versão de

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)

No UP, implementação significa programação e construção do sistema, não implantação. A disciplina de

3. A Visão de Processo abrange os threads e os processos que formam os mecanismos de concorrência e de

4. A Visão de Implementação de um sistema abrange os componentes e os arquivos utilizados para a

3.7 Camadas Arquiteturais

4 UML - Linguagem de Modelagem Unificada - Unified Modeling

Possui três elementos principais:

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

4.1 Um modelo conceitual da UML

4.1.1 Blocos básicos de construção da UML

4.2 Relacionamentos na UML

4.4 Regras da UML

4.5 Mecanismos básicos da UML

Segundo, separação de interface e implementação.

5.1 Uso de Adornos e Mecanismos de Extensibilidade

5.2 Mecanismos de Extensibilidade

5.3 Técnicas básicas de modelagem

Modelagem de novos blocos de construção

Modelagem de novas propriedades

Modelagem de uma nova semântica

Figura 2 - Modelagem de uma nova semântica

Figura 4 - Relacionamentos da UML

Figura 5 - Nomes de Associações

Figura 6 - Papéis nas Associações

Figura 7 - Multiplicidade dos Relacionamentos

Figura 8 - Agregação na UML

Figura 9 - Herança na UML

Figura 10 - Relacionamentos Estruturais na UML

6.1 Relacionamentos Avançados

Figura 11 - Relacionamentos Avançados na UML

Existem outros dois estereótipos que são aplicados aos pacotes.

Para as interações entre objetos, a UML define três estereótipos:

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

Figura 13 - Visibilidade dos Relacionamentos

Figura 14 - Associação Qualificada

Figura 15 - Relacionamento de Composição

Figura 16 - Classe de Associação

Figura 17 - Realização de Interface

Figura 18 - Realização de Caso de Uso

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

A UML define cinco estereótipos-padrão que se aplicam aos pacotes.

Figura 20 - Generalização entre Pacotes

Modelagem de grupos de elementos

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

Figura 21 - Arquitetura de Três Camadas - Pacotes