A linguagem de modelagem UML

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração, ou seja, uma linguagem projetada para ser facilmente entendida por

pessoas, com suporte a nomes e variáveis. A UML não é um método de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como desenhar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a

comunicação entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu

trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido

utilizando a UML. É importante distinguir entre um modelo UML e um diagrama (ou conjunto de

diagramas) de UML, o último é uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. O XMI (XML Metada ta Interchange) na sua versão corrente disponibiliza troca de modelos, mas não de diagramas.

A UML (Unified Modeling Language) é uma linguagem para especificação, documentação, visualização e desenvolvimento de sistemas orientados a objetos.

Sintetiza os principais métodos existentes, sendo considerada uma das linguagens mais expressivas para modelagem de sistemas orientados a objetos. Por meio de seus diagramas é possível representar sistemas de softwares sob diversas perspectivas de

visualização. Facilita a comunicação de todas as pessoas envolvidas no processo de desenvolvimento de um sistema - gerentes, coordenadores, analistas, desenvolvedores -

por apresentar um vocabulário de fácil entendimento.

A origem

A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de

Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de

modelagem padrão para modelar sistemas concorrentes e distribuídos. Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos

Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Método Unificado (como era conhecido). Nesta mesma época,

Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML. Assim que a primeira versão foi lançada, diversas grandes empresas atuantes na área de

software passaram a contribuir com o projeto, fornecendo sugestões para melhorar e ampliar a linguagem. Finalmente a UML foi adotada pela OMG(Object Management

Group) em 1997, como a linguagem padrão de modelagem. Em 2002 foi lançado a última versão, a UML 2.0. A UML integrou muitas idéias adversas, e esta integração acelera o uso do

desenvolvimento de softwares orientados a objetos.

Perspectivas para o futuro

Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros

aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi

baseado em técnicas antigas e marcantes da orientação a objetos, mas muitas outras

influenciarão a linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se

fazer necessário redefinir a sua estrutura interna. A UML será a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulações e ambientes de desenvolvimento. Um exemplo disto é o

RUP(Rational Unified Process) usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML para ilustrar os

processos em ação. O RUP utiliza técnicas e práticas aprovadas comercialmente.

Conceitos Iniciais

Um diagrama é uma representação gráfica de um sistema sob determinada visão.

Existem diversos motivos para utilizá-los. Eles são úteis na documentação, tornando a manutenção mais fácil, ajudam a compreender melhor os requisitos de um sistema antes

de implementá- lo, simplificam o entendimento de sistemas comlpexos usando a técnica de dividir para conquistar. Os diversos diagramas da UML podem ser divididos em dois grandes grupos, os

diagramas estruturais e os comportamentais. Nas duas lições seguintes você aprenderá um pouco sobre cada um desses diagramas.

Estruturais: Diagrama de classes; Diagrama de componentes;

Diagrama de objetos; Diagrama de artefatos;

Diagrama de implantação. Comportamentais:

Diagrama de casos de uso;

Diagrama de seqüência; Diagrama de colaboração;

Diagrama de gráfico de estados; Diagrama de atividades.

Programas

Para facilitar a tarefa de modelagem é preferível que você utilize um programa

específico para desenhar diagramas em UML. Existem muitos programas que fazem isto, entre eles estão o Jude(com versões freeware

e shareware) , que pode ser baixado no endereço http://jude.change-vision.com/jude-web/download/index.html, e o Umbrello( livre ), que pode ser instalado com o comando "apt-get install umbrello".

Diagramas Estruturais

Classes

Na lógica de programação orientada a objetos uma classe é uma abstração de um

conjunto de objetos com as mesmas características (atributos, operações, relacionamentos e semântica). Uma classe define os atributos de seus objetos e

métodos.

Os atributos são elementos das classes semelhantes as variáveis da lógica de

programação estruturada. Cada atributo representa uma propriedade do item que está sendo modelado. Para cada atributo é definido um intervalo de valores possíveis. Por

exemplo, a classe funcionário pode ter os atributos nome, endereço, telefone, número de identidade, salário, cargo. Na UML, os Atributos são mostrados como tendo o seu nome, pelo menos, e poderão

mostrar também o seu tipo, o seu valor inicial e outras propriedades. Os atributos também poderão ser mostrados com a sua visibilidade:

+ Representa atributos públicos; # Representa atributos protegidos; - Representa atributos privados.

Veja a seguir a representação de uma classe com seus atributos na linguagem UML:

Além de atributos as classes têm métodos. Um método é uma operação que pode ser

executada sobre os objetos de uma classe. São os métodos que executam todas as funcionalidades do programa, como fazer cálculos, exibir mensagens, gerar relatórios, etc.

As operações (métodos) são também mostradas contendo pelo menos o seu nome e poderão também mostrar os seus parâmetros e tipos de valor devolvidos. As operações

podem, assim como os Atributos, mostrar a sua visibilidade: + Corresponde a operações públicas; # Corresponde a operações protegidas;

- Corresponde a operações privadas. A próxima figura mostra a representação em UML para uma classe com as operações

latir, morder e comer.

Relacionamentos

Além de identificar as classes do seu sistema será preciso representar os relacionamentos que existem entre elas. Há três tipos de re lacionamentos: dependências, generalizações e associações.

Dependência Uma dependência é um relacionamento em que um item usa dados e serviços de outro item. Representa-se uma dependência em UML com uma linha tracejada apontando do item que depende de alguma informação para o que a fornece.

Generaliz ação

Uma generalização é um relacionamento entre ítens gerais e itens mais específicos. Esse

tipo de relacionamento indica que objetos da classe específica podem ser utilizados em qualquer lugar onde a classe geral ocorra. A classe específica, que pode ser chamada de

filha, herda todas as características da classe geral, ou classe mãe. Isto é, a filha tem todos os atributos e todos os métodos da classe geral. Ela pode ter também atributos e métodos próprios, que não estão na classe mãe. Na UMl representa-se uma

generalização com uma linha que aponta da filha para a mãe.

Associaç ão

Uma associação representa uma relação entre classes e dá a semântica e a estrutura

comum para vários tipos de "ligações" entre os objetos. As associações são o mecanismo que permite aos objetos comunicarem uns com os outros. Descrevem a ligação entre as diferentes classes (a ligação entre os objetos em si

é chamada de ligação do objeto). As associações podem ter um papel que indica o objetivo da associação e pode ser

unidirecionais ou bidirecionais (indica se os dois objetos que participam na relação poderão enviar mensagens um para o outro, ou se só um deles é que conhece o outro). Cada extremo da associação também tem um valor de multiplicidade, que define

quantos objetos desse lado da associação poderão se relacionar com um objeto do outro lado.

No UML, as associações são representadas como linhas que ligam as classes que participam na relação e poderá também mostrar o papel e a multiplicidade de cada um dos participantes. A multiplicidade é mostrada como um intervalo [mín..máx] de

valores não-negativos ou com um asterisco (*) no lado do máximo que representa o infinito.

Agregação

As agregações são um tipo especial de associações nas quais as duas classes participantes não têm um estado igual, mas têm uma relação "do 'todo' para as partes".

Uma agregação diz como é que a classe que tem o papel do 'todo' é composta (ou tem) as outras classes, que tem o papel das partes. Para as agregações, a classe que atua como

o 'todo' tem sempre uma multiplicidade de um. No UML, as agregações são representadas por uma associação com um losango do lado do 'todo'.

Composição

As composições são associações que representam agregações muito fortes. Isto significa

que as composições formam também relações do 'todo' para as partes, mas a relação é tão forte que as partes não podem existir por si só. Elas só existem dentro do todo e se o

todo for destruído, as partes desaparecem também. No UML, as Composições são representadas por um losango a cheio do lado do 'todo'.

Diagrama de Classes

Os Diagramas de Classes mostram as diferentes classes que compõem um sistema e como elas se relacionam umas com as outras. Os Diagramas de Classes são apontados

normalmente como "estáticos" porque mostram as classes, em conjunto com os seus métodos e atributos, assim como as relações estáticas entre elas, quais as classes que

"conhecem" outras classes ou que "fazem parte" de outra classe, mas não mostram as chamadas de métodos entre elas. Diagramas de Classe podem conter diversos outros ítens além das classes:

Interfaces

Interfaces são classes abstratas que significam instâncias que não podem ser diretamente criadas delas. Elas podem conter operações, mas não podem conter atributos. Classes

podem derivar de interfaces (através da realização de uma associação) e instâncias podem então ser feitas destes diagramas.

Tipos de dados

Tipos de dados são primitivos uma vez que são tipicamente construídos numa linguagem de programação. Exemplos comuns são inteiros e lógicos. Eles não podem ser relacionados à classes, mas classes podem se relacionar com eles.

Enumerações

Enumerações são uma lista simples de valores. Um exemplo típico é uma enumeração para dias da semana. As opções de uma enumeração são chamadas Literais de

Enumeração. Como tipos de dados, elas não podem ter relacionamentos para classes, mas classes podem relacionar-se com elas.

Pacotes

Pacotes representam um espaço de nomes numa linguagem de programação. Num diagrama eles são usados para representar partes de um sistema que contém mais de uma classe, talvez centenas de classes.

Veja na figura a seguir um exemplo de um diagrama de classes:

Objetos

Os objetos são instanciações de classes. Enquanto as classes são abstrações, os objetos existem no mundo real. Um objeto representa uma entidade que pode ser física,

conceitual ou de software. É uma abstração de algo que possui fronteira definida e significado para a aplicação. Na UML a representação de um objeto é quase igual a de

uma classe. A única diferença é que o nome dos objetos aparecem sublinhados, como na figura a seguir. Se você quiser pode escrever o nome da classe depois do nome do objeto para que fique mais claro a que classe ele pertence.

Diagrama de Objetos

O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram

instanciados das classes. O diagrama de objetos é como se fosse o perfil do sistema em um certo momento de sua execução.

A mesma notação do diagrama de classes é utilizada com duas exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como os diagramas de

classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados como

parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema são mostrados.

Diagrama de Componentes

Componente de Software é o termo utilizado para descrever o elemento de software que

encapsula uma série de funcionalidades. Um componente é uma unidade independente, que pode ser utilizado com outros componentes para formar um sistema mais complexo.

Em programação orientada a objetos um componente é o objeto que implementa uma

interface e é autônomo em relação a outros componentes do sistema. Na UML existem cinco estereótipos de componentes: executável, biblioteca, tabela, documento e arquivo.

A figura abaixo mostra a representação de um componente na UML:

Um diagrama de componentes ilustra os componentes de software e os relacionamentos

entre eles, representando a estrutura do código gerado. O d iagrama de componentes não mostra instâncias de componentes, mostra apenas componentes como tipos. As

instâncias de componentes são mostradas no diagrama de execução. As dependências entre componentes são representadas por uma linha tracejada apontando para o componente que fornece a informação da qual o outro precisa, assim como no diagrama

de classes. O diagrama de componentes é utilizado para:

Modelar os componentes do código-fonte, do código executável do software; Organizar o código fonte, mostrando as dependências entre os diferentes

arquivos fonte de modo que fique claro quais arquivos precisarão ser

recompilados quando for feita uma modificação em algum deles; Destacar a função de cada módulo para facilitar a sua reutilização;

Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos.

Diagrama de Artefatos

Um artefato é o produto de uma ou mais atividades dentro do contexto do desenvolvimento de um sistema. Pode ser um documento de texto, código fonte, um programa executável, uma biblioteca, etc.

O diagrama de artefatos mostra a organização dos artefatos do sistema e o relacionamento entre eles. Geralmente os diagramas de artefatos são utilizados para a modelagem de um dos seguintes ítens:

Código fonte; Versões executáveis;

Bancos de dados físicos; Sistemas adaptáveis.

Diagrama de Implantação

O diagrama de implantação mostra a organização do hardware do sistema. Ele é utilizado para a representação de sistemas distribuídos (sistemas que utilizam vá rios computadores ligados em rede), mostrando quais processos serão executados em cada

máquina. Neste diagrama cada máquina é chamada de nó. Pode-se dizer que os diagramas de implatação são diagramas de classes que mostram os nós do sistema e os

artefatos que existem neles.

Diagramas Comportamentais

Atores

Os atores representam os usuários do sistema, eles podem ser pessoas, dispositivo de

hardware ou outro sistema. Por exemplo, em uma escola pode haver os atores aluno, professor, diretor, coordenador, representante de turma, etc. Também podem ser atores

o sistema de cobranças que envia emails aos pais, o sistema de cálculo das notas, etc. Cada ator tem determinados papéis dentro do sistema. Atores não representam as pessoas físicas ou sistemas, mas sua regra. Isto significa que

quando uma pessoa interage com o sistema de diferentes maneiras (assumindo diferentes regras) ela será representada por diversos atores. Por exemplo um pessoa que

fornece suporte ao cliente por telefone e recebe ordens do cliente para o sistema pode ser representado por um ator da "Equipe de Suporte" e um ator "Representante de Vendas".

Na figura abaixo é mostrada a representação de atores na UML.

Casos de Uso

Um caso de uso descreve uma funcionalidade provida pelo sistema, um grupo de

atividades num sistema que produz um resultado concreto e tangível. Casos de Uso são descrições de interações típicas entre os usuários de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um

conjunto de exigências do que o sistema deve fazer (lembre-se: somente o quê, não como).

O conjunto de casos de uso representa todas as funções do sistema. Ele não deve fazer nada além do que é descrito nos casos de uso, ou melhor, não deve haver nenhuma funcionalidade que não é descrita pelos casos de uso.

Quando trabalhar com Casos de Uso, é importante lembrar-se de algumas regras simples:

Cada Caso de Uso está relacionado com no mínimo um ator;

Cada Caso de Uso possui um iniciador (isto é um ator); Cada Caso de Uso liga-se a um resultado relevante (um resultado com "valor de

negócio"). Casos de Uso também podem ter relacionamentos com outros Casos de Uso. Os três tipos mais comuns de relacionamento entre Casos de Uso são:

<<inclui-se>> que especifica que um Caso de Uso toma lugar dentro de outro Caso de Uso;

<<estende>> que especifica que em determinadas situações, ou em algum ponto (chamado um ponto de extensão) um Caso de Uso será estendido por outro;

Generalização especifica que um Caso de Uso herda as características do "Super" Caso de Uso, e pode sobrepor algumas delas ou adicionar novas de

maneira semelhante a herança entre classes. Na UML os casos de uso são representados por elipses.

Descrição do Caso de Uso

Descrição do Caso de Uso são narrativas de texto do Caso de Uso. Elas usualmente

tomam a forma de uma nota ou um documento que é de alguma maneira ligado ao Caso de Uso, e explana o processo ou atividades que tomarão lugar no Caso de Uso.

Diagrama de Casos de Uso

O diagrama de casos de uso ilustra os comportamentos que o programa terá quando estiver pronto. Ele descreve relacionamentos e dependências entre um grupo de Caso de Uso e os Atores participantes no processo.

Quando há uma comunicação entre um ator e um caso de uso ela é representada por um relacionamento. Um caso de uso pode se relacionar com vários atores. Por exemplo, o

caso de uso matrícula de alunos pode ter os atores aluno e sistema de matrículas. Em UML representa-se um relacionamento com uma linha reta. Se esta linha não apontar para nenhuma direção adimite-se que a comunicação parte do ator. Se você quiser

indicar um relacionamento em que a iniciativa parte do processo basta usar uma seta apontando do caso de uso para o ator.

O nome dado aos casos de uso é muito importante para que a interpretação do diagrama seja fácil e rápida. É aconselhável que se utilize um padrão para estes nomes. Como casos de uso são processos de preferência use verbos para seus nomes.

Diagrama de Seqüência

Um diagrama de seqüência mostra a seqüência dos processos (mais especificamente de mensagens passadas entre os objetos) num sistema. Ele é usado para representar o comportamento das operações, métodos (procedimentos ou funções) entre objetos de

um cenário. Um cenário é uma forma de ocorrência de um caso de uso. Este diagrama é construído a partir do Diagrama de Casos de Usos. Primeiro, se define qual o papel do

sistema (Uses Case), depois, é definido como o software realizará seu papel (Seqüência de operações). Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram

em algum comportamento ao longo do tempo. Ele registra o comportamento de um

único caso de uso. Ele exibe os objetos e as mensagens passadas entre esses objetos no

caso de uso. Um design pode ter uma grande quantidade de métodos em classes diferentes. Isso torna difícil determinar a seqüência global do comportamento. Esse

diagrama é simples e lógico, a fim de tornar óbvios a seqüência e o fluxo de controle. Geralmente para cada caso de uso é feito um diagrama de seqüência mostrando a operação normal do sistema para este caso de uso e depois são feitos outros diagramas

mostrando as seqüências alternativas e o tratamento de erros. Em Diagramas de Seqüência objetos são representados através de linhas verticais

tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com a operação e os nomes dos parâmetros.

Mensagens podem ser síncronas, o tipo normal de mensagem de chamada onde o controle é passado para o objeto chamado até o método ter terminado sua execução, ou

assíncronas onde o controle é passado diretamente para o objeto chamado. Mensagens síncronas possuem uma caixa vertical no lado do objeto chamado para mostrar o controle do fluxo do programa.

A figura seguinte mostra um exemplo de um diagrama de seqüência:

Diagramas de Colaboração mostram as interações que ocorrem entre os objetos participantes numa situação específica. Isto é mais ou menos a mesma informação

mostrada pelos Diagramas de Seqüência, mas neste a ênfase é colocada em como as interações ocorrem no tempo, enquanto os Diagramas de Colaboração colocam os

relacionamentos entre os objetos e sua topologia em destaque. Em Diagramas de Colaboração as mensagens enviadas de um objeto para outro são representadas por setas, mostrando o nome da mensagem, parâmetros, e a seqüência da

mensagem. Diagramas de Colaboração são especialmente indicados para mostrar um fluxo ou situação específica do programa e são um dos melhores tipos de diagrama para

rapidamente demonstrar ou explanar um processo na lógica do programa.

Estados

Estados são os blocos construídos dos Diagramas de Estado. Um Estado pertence a exatamente uma classe e representa um resumo dos valores dos atributos que uma classe

pode tomar. Um Estado UML descreve o estado interno de um objeto para uma classe em particular

Observe que nem toda mudança em um dos atributos de um objeto pode ser representada por um Estado, mas somente aquelas mudanças que podem afetar significativamente o trabalho do objeto

Existem dois tipos especiais de Estados: Inicial e Final. Eles são especiais porque nenhum evento pode fazer com que um Objeto retorne para seu estado Inicial, e da

mesma maneira nenhum evento pode tirar um Objeto de seu estado Final uma vez que ele já o tenha alcançado.

Diagrama de Estados

Diagramas de Estado mostram os diferentes estados de um Objeto durante sua vida, e o

estímulo que faz com que o Objeto mude seu estado. Diagramas de Estado veem Objetos como máquinas de estado ou automatismos finitos

que podem ser um de um conjunto de estados finitos e que podem mudar seu estado através de um conjunto finito de estímulos. Por exemplo, um tipo de Objeto ServidorRede pode estar em um dos seguintes estados durante sua vida:

1. Pronto; 2. Ouvindo;

3. Trabalhando; 4. Parado.

e os eventos que podem fazer com que o Objeto mude de estado são:

Objeto é criado; Objeto recebe mensagem ouvir;

Um Cliente solicita uma conexão através da rede; Um Cliente termina um pedido; O pedido é executado e terminado;

Objeto recebe mensagem parar;. etc.

Atividade

Uma Atividade é um passo simples num processo. Uma Atividade é um estado no sistema com atividade interna e, pelo menos, uma transição de saída. Atividades podem

também ter mais de uma transição de saída se elas possuem condições diferentes. Atividades podem formar hierarquias, isto significa que uma Atividade pode ser composta por diversas Atividades em "detalhe", na qual as transições de entrada e saída

devem corresponder às transições de entrada e saída do diagrama de detalhe.

Diagrama de Atividade

O Diagrama de Atividade descreve a seqüência de atividades num sistema com a ajuda

as Atividades. Diagramas de Atividade são uma forma especial de Diagramas de Estado, que somente (ou principalmente) contém Atividades.

Diagramas de Atividade são similares aos Diagramas de Fluxo de procedimentos, com a diferença de que todas as Atividades são claramente anexas aos Objetos. Diagramas de Atividade são sempre associados a um Classe, uma Operação ou um Caso

de Uso. Diagramas de Atividade suportam Atividades seqüenciais bem como paralelas. A

execução paralela é representada pelos ícones Forquilha/Esperar, e para as Atividades executadas em paralelo, não é importante a ordem na qual e las se executam (elas podem ser executadas ao mesmo tempo ou uma após a outra).

Exercícios:

1. Marque as alternativas corretas sobre UML:

( ) A UML tem origem na compilação das "melhores práticas de engenharia". ( ) A UML 1.4 é versão mais recente da UML. ( ) A UML é uma linguagem de modelagem proprietária.

2. Julgue a afirmação seguinte como verdadeira ou falsa:

( ) O Jude é o único programa livre que pode ser usado para fazer diagramas UML.

3. Qual dos seguintes símbolos é usado para indicar que um atributo é público?

( ) % ( ) -

( ) + ( ) *

4. Qual é o relacionamento em que um item usa dados e serviços de outro item?

( ) agregação ( ) composição

( ) generalização ( ) dependência

5. Julgue as seguintes afirmações como verdadeira ou falsa:

( ) Uma lista dos meses do ano são um exemplo de enumeração. ( ) Na representação de objetos da UML o nome do objeto aparece sublinhado.

( ) Um componente é uma unidade independente, que pode ser utilizado com outros componentes para formar um sistema mais complexo.

( ) Tanto o diagrama de artefatos quanto o de implantação são utilizados para

modelagem física. 6. Das alternativas seguintes qual não pode ser um ator?

( ) Cadastrar usuário ( ) Aluno ( ) Sistema de vendas

( ) Gerente 7. Qual das seguintes frases se refere a um caso de uso?

( ) Representa os usuários do sistema. ( ) Descreve uma funcionalidade provida pelo sistema. ( ) Mostra a seqüência dos processos num sistema.

( ) Mostra os diferentes estados de um Objeto durante sua vida. 8. Julgue a afirmação seguinte como verdadeira ou falsa:

( ) No diagrama de seqüência o tempo é representado por linhas verticais, aumentando para baixo. 9. Associe cada descrição ao diagrama correspondente:

(A) Diagrama de Gráfico de Estados (B) Diagrama de Atividade

(C) Diagrama de Colaboração (D) Diagrama de Sequência ( ) É sempre associado a uma Classe, uma Operação ou um Caso de Uso.

( ) Mostra os diferentes estados de um Objeto durante sua vida. ( ) Descreve a maneira como os grupos de objetos colaboram em algum

comportamento ao longo do tempo. ( ) Mostra as interações que ocorrem entre os objetos participantes numa situação específica.

10. Das alternativas seguintes qual não é uma função de um diagrama de

componentes?

( ) A. mostrar a seqüência dos processos (mais especificamente de mensagens passadas entre os objetos) num sistema ( ) B. Modelar os componentes do código-fonte, do código executável do software.

( ) C. Destacar a função de cada módulo para facilitar a sua reutilização. ( ) D. Auxiliar no processo de engenharia reversa, por meio da organização dos

módulos do sistema e seus relacionamentos. 11. Qual dos seguintes itens não aparece nos diagramas de classes?

( ) A. objetos

( ) B. classes ( ) C. tipos de dados

( ) D. pacotes 12. Julgue as afirmações abaixo:

( ) "Geralmente para cada caso de uso é feito um diagrama de seqüência mostrando a

operação normal do sistema para este caso de uso e depois são feitos outros diagramas mostrando as seqüências alternativas e o tratamento de erros."

( ) "A agregação é um exemplo de tipo especial de associação" ( ) "Diagramas de Atividade somente suportam Atividades sequenciais." 13. Das seguintes alternativas, quais são tipos de relacionamentos apresentados

neste curso?

( ) A. dependência

( ) B. generalização ( ) C. associação

( ) D. enumeração

14. Julgue as afirmações:

( ) "O desenvolvimento da UML foi baseado em técnicas antigas e marcantes da

orientação a objetos." ( ) Assim que a primeira versão foi lançada, diversas grandes empresas atuantes na área de software passaram a contribuir com o projeto, fornecendo sugestões para

melhorar e ampliar a linguagem. A UML ainda não foi adotada pela OMG(Object Management Group) como a linguagem padrão de modelagem.

( ) Os atores representam os usuários do sistema, eles podem ser pessoas, dispositivo de hardware ou outro sistema. 15. Marque a opção que não é uma das vantagens de se usar UML em um projeto.

( ) A. Torna a manutenção do sistema mais fácil. ( ) B. Diagramas UML são úteis na documentação.

( ) C. Implementação do código dos métodos automaticamente. ( ) D. Simplificam o entendimento de sistemas complexos usando a técnica de dividir para conquistar.