Explorar E-books
Categorias
Explorar Audiolivros
Categorias
Explorar Revistas
Categorias
Explorar Documentos
Categorias
Linguagem UML
Prof. MSc. Carlos Michel Betemps
carlos.betemps@unipampa.edu.br
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
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
evitando, tanto quanto possível, comprometimentos prematuros com detalhes, isto é, durante a análise lida-se apenas
com conceitos do domínio de aplicação, e não se deve tomar decisões sobre o projeto e a implementação antes do
problema ser compreendido (Rumbaugh et. al., 1994).
2. Encapsulamento (Ocultamento de informação): Consiste na separação dos aspectos externos de um objeto,
acessíveis por outros objetos, dos detalhes internos da implementação daquele objeto, que ficam ocultos dos demais
objetos. Este conceito impede que um programa se torne tão interdependente que uma pequena modificação possa
causar grandes efeitos de propagação. A capacidade de combinar estrutura de dados e seu comportamento em uma
única entidade torna o encapsulamento na OO mais poderoso do que em linguagens convencionais (Rumbaugh et. al.,
1994). Encapsulamento é a capacidade de ocultar dados dentro dos modelos, permitindo que somente operações
especializadas ou dedicadas manipulem os dados ocultos. O Encapsulamento é um dos benefícios mais palpáveis de
programação orientada a objetos (Santos, 2003).
3. Compartilhamento: As técnicas OO promovem o compartilhamento em diversos níveis. A herança da
estrutura de dados e seu comportamento permitem que a estrutura comum seja compartilhada por diversas subclasses
semelhantes sem redundâncias. O compartilhamento de código, com utilização de herança, é uma das principais
vantagens das linguagens baseadas em objetos (Rumbaugh et. al., 1994). A OO também permite a reutilização de
modelos e códigos em projetos futuros (bibliotecas de componentes reutilizáveis).
4. Ênfase na Estrutura de Objetos e Não na Estrutura de Procedimentos: A OO preocupa-se em
especificar o que um objeto é, e não em como ele é utilizado. Os usos de um objeto são altamente dependentes dos
detalhes da aplicação e freqüentemente mudam durante o desenvolvimento. À medida que os requisitos evoluem, as
características de um objeto permanecem, muito mais estáveis do que os modos como ele é utilizado, e, por causa disso,
o software construído com base na estrutura de objetos são mais estáveis em longo prazo (Rumbaugh et. al., 1994).
2.1.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.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.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,
...).
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.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).
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
ciclo de desenvolvimento
iteração fase
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
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
Aspectos dinâmicos - diagramas de interação, de estados e de atividades
5. A Visão de Implantação de um sistema abrange os nós que formam a topologia de hardware em que o
sistema é executado. Esta visão direciona principalmente a distribuição, o fornecimento e a instalação das partes que
constituem o sistema físico.
Aspectos estáticos - Diagramas de Implantação
Aspectos dinâmicos - diagramas de interação, de estados e de atividades
Estas visões também interagem entre si: os nós na visão de implantação contêm componentes da visão de
implementação que, por sua vez, representa a realização física de classes, interfaces, colaborações e classes ativas
provenientes das visões de projeto e de processo.
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.
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)
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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)
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.
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
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.
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
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
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
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
2. Generalizações - relacionam classes generalizadas a suas especializações (relacionamentos
subclasse/superclasse). Ex.: janelas panorâmicas são grandes e com painéis fixos de vidro; janelas de quartos costumam
ter mais de um painel de vidro e abrir de um lado para outro. Também chamada de relacionamento "é um tipo de".
A generalização significa que os objetos da classe-filha podem ser utilizados em qualquer local em que a
classe-mãe ocorra, mas não vice-versa. A classe filhe herda as propriedades da mãe (atributos e operações).
Freqüentemente - mas não sempre - as filhas têm atributos e operações além daqueles encontrados nas respectivas mães.
A operação de uma filha, que tenha a mesma assinatura de uma operação da mãe, prevalecerá em relação à operação da
mãe (polimorfismo).
Representada graficamente como uma linha sólida apontando para a mãe.
Podem existir herança simples e herança múltipla (a classe filha herda todos os atributos, operações e
associações de todas as suas classes mãe).
Figura 3 - Generalização
3. Associações - representam relacionamentos estruturais entre objetos (instâncias). Ex.: As salas são formadas
por paredes e outros itens; as próprias paredes podem ter portas e janelas embutidas; os canos podem ser passados por
dentro das paredes.
Através de uma associação á possível navegar do objeto de uma classe até o objeto de outra classe e vice-versa.
Podem existir associações entre objetos de uma mesma classe.
Representada graficamente como uma linha sólida conectando a mesma classe oi classes diferentes. Use as
associações sempre que desejar exibir relacionamentos estruturais.
A representação gráfica para cada um destes tipos de relacionamentos é mostrada na figura abaixo:
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.
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.
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)
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
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
Realização
Utiliza-se "realização" em duas circunstâncias: no contexto de interfaces e no contexto de colaborações
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
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
Surge, assim, a necessidade de organizar esses itens em grupos maiores. na UML, o pacote é um mecanismo de
propósito geral para a organização de elementos da modelagem em grupos.
Pode-se controlar a visibilidade dos elementos dentro dos pacotes (alguns visíveis fora do pacote e outros
ocultos).
Podem ser empregados para apresentar diferentes visões da arquitetura do sistema.
Pacotes bem-estruturados são fracamente acoplados em forte coesão, com acesso altamente controlado ao
conteúdo do pacote.
Utilizando pacotes pode-se compreender com maior facilidade os modelos.
Todo pacote deve ter um nome que o diferencie de outros 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.
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)
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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,
relacionamentos e semântica.
Classes podem incluir abstrações que são parte do domínio do problema, assim como as classes que fazem uma
implementação. Pode-se utilizar classes para representar itens de software, de hardware e até itens que sejam puramente
conceituais.
Uma classe é uma abstração de itens que fazem parte de seu vocabulário (no contexto de um domínio de
aplicação). A classe não é um objeto individual, mas representa um conjunto inteiro de objetos.
A representação gráfica de classe é mostrada da figura abaixo.
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
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
Classificadores (e principalmente as classes) possuem características avançadas:
Multiplicidade
Visibilidade
Assinaturas
Polimorfismo
À medida que um projeto prosseguir, a arquitetura (e, por conseqüência, seus elementos) é aprimorada.
Exemplo de propriedades avançadas:
Cada abstração terá instâncias. Alguns itens da UML não possuem instâncias (pacotes e os relacionamentos de
generalização). Em geral, os elementos que podem ter instâncias são chamados classificadores.
O tipo mais importante de classificador na UML é a classe.
As classes são descrições como conjuntos de objetos que compartilham os mesmos atributos, operações,
relacionamentos e semântica.
As classes não são o único tipo de classificador:
Interface: uma coleção de operações que especificam serviços de uma classe ou componente.
Tipos de dados: um tipo cujos valores não têm identidade (tipos primitivos e enumerados)
Sinal: a especificação de um estímulo assíncrono, comunicado entre as instâncias
Componente: uma parte física e substituível de um sistema, adequada à realização de um conjunto de
interfaces e que proporciona essa realização
Nó: um elemento físico existente em tempo de execução que representa um recurso computacional,
geralmente com pelo menos alguma memória e, freqüentemente, capacidade de processamento.
Casos de uso: uma descrição de um conjunto de uma seqüência de ações, incluindo variantes, que um
sistema realiza, proporcionando um resultado observável do valor para um determinado ator.
Subsistema: um grupo de elementos em que alguns constituem uma especificação do comportamento
oferecido pelos outros elementos contidos no grupo.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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 (-)
C++ operações e atributos estáticos (termo também utilizado na ferramenta Jude) (Jude, 2005).
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}
Sintaxe:
[visibilidade] nome [(lista-de-parâmetros)] [:tipo-de-retorno] [{string-propriedade}]
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
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
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).
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:
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.
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)
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).
Vínculos: é uma conexão semântica existente entre os objetos. Em geral, é uma instância de uma associação.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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)
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
2. Para a modelagem de fluxos de controle por organização (Colaboração).
Visualização de iteração e ramificação complexas e para a visualização de vários fluxos de controle
concorrentes.
Defina o contexto para a interação (sistema, subsistema, operação ou classe, cenário de caso de uso ou
colaboração).
Distribuir os objetos como vértices de um gráfico (ou grafo), deixando os mais importantes no centro.
Defina as propriedades iniciais. Se as propriedades de um objeto se modificarem durante a interação,
duplique estes objetos (conecte-os com <<become>> ou <<copy>>) e mostre estas propriedades sendo
atualizadas.
Especifique os vínculos entre os objetos (e as mensagens).
1. Distribua primeiro os vínculos da associação (conexões estruturais)
2. Após os outros vínculos e adorne-os (<<global>>, <<local>>) para especificar como esses objetos
estão relacionados.
Define número de seqüência entre as mensagens
Se for necessário especificar restrições de tempo ou espaço, adorne cada mensagem (marca de tempo e
restrições de tempo ou espaço)
Se for necessário especificar o fluxo de controle de modo mais formal, anexe pré e pós- condições a cada
mensagem
16Casos de 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)
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.
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.
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
Ramificação
Pode-se incluir nos diagramas de atividades ramificações, especificando caminhos alternativos, tomados com
base em alguma expressão booleana.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
As proteções (guard) associadas às transições de uma ramificação não podem se sobrepor (ambíguas) mas
devem cobrir todas as possibilidades (caso contrário, o fluxo de controle congelaria).
A palavra "else" pode ser mascada como uma transição de saída.
Bifurcação e Uniã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.
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).
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 55 - Sinal
Chamada: representa a ativação de uma operação (pode ativar a transição de estado). Em geral, é um evento
síncrono.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
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.
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 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
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.
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
As colaborações são empregadas para especificar a realização de casos de uso e operações e para fazer a
modelagem de mecanismos significativos da arquitetura do sistema.
Estrutura de uma Colaboração
Parte estrutural: combinação de classificadores (classes, interfaces, componentes e nós) que trabalham em
conjunto para executar a colaboração. Ex. Modelo de classes.
Parte comportamental: especifica a dinâmica de como esses elementos interagem. Ex. Diagrama de
interação.
Usos Comuns
Modelagem da realização de um caso de uso.
Modelagem da realização de uma operação.
Modelagem de um mecanismo.
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
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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.
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.
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.
Ministério da Educação
Universidade Federal do Pampa
Unipampa – Campus Bagé
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).
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.
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.
Usos Comuns
1. Para fazer a modelagem de sistemas embutidos
2. Para fazer a modelagem de sistemas cliente/servidor
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.