Pos UML

Curso de Pós-Graduação Lato Sensu
Especialização em
Engenharia de Software
(EngSw) a Distância
Disciplina/Aula: Análise e Modelagem

de Objetos com UML
João Caldas Júnior

Elisamara de Oliveira
1
Sumário
Apresentação ...................................................................................................................... 5
Capítulo 1 ............................................................................................................................ 6
Fundamentos da Orientação a Objetos ............................................................................ 6
1.1. Processo de Software e Modelos de Ciclo de Vida ................................................. 6
1.2. Introdução à Orientação a Objetos .......................................................................... 8
1.2.1. Abstração ...................................................................................................... 10
1.2.2. Objetos e Classes ......................................................................................... 11
1.2.3. Atributos ........................................................................................................ 12
1.2.4. Operações e Métodos ................................................................................... 13
1.2.5. Encapsulamento ............................................................................................ 14
1.2.6. Herança ......................................................................................................... 14
1.2.7. Polimorfismo .................................................................................................. 15
1.3. RUP - Rational Unified Process ............................................................................... 16
Exercícios do Capítulo 1 ...................................................................................................... 18
Capítulo 2 .......................................................................................................................... 19
UML – Unified Modeling Language ................................................................................. 19
2.1. Breve Histórico da UML ........................................................................................... 19
2.2. Organização dos Diagramas da UML ...................................................................... 21
2.3. Diagramas da UML .................................................................................................. 22
2.3.1. Diagrama de Casos de Uso ............................................................................... 23
2.3.2 Diagrama de Classes .......................................................................................... 23
2.3.3. Diagrama de Objetos ......................................................................................... 23
2.3.4. Diagrama de Pacotes......................................................................................... 23
2.3.5. Diagrama de Sequência ..................................................................................... 24
2.3.6. Diagrama de Comunicação ................................................................................ 24
2.3.7. Diagrama de Atividades ..................................................................................... 24
2.3.8. Diagrama de Estrutura Composta ...................................................................... 25
2.3.9. Diagrama de Componentes .............................................................................. 25
2.3.10. Diagrama de Implantação ............................................................................... 25
2.3.11. Diagrama de Tempo ....................................................................................... 26
2.3.12. Diagrama de Máquina de Estados .................................................................. 26
2.3.13. Diagrama de Interação Geral .......................................................................... 26
2
2.4. O Futuro da UML...................................................................................................... 27
Capítulo 3 .......................................................................................................................... 29
Diagrama de Casos de Uso ............................................................................................. 29
3.1. Análise de Requisitos e Diagramas de Casos de Uso ............................................. 29
3.2. Componentes de um Diagrama de Casos de Uso ................................................... 30
3.2.1. Atores e Casos de uso ....................................................................................... 30
3.2.2. Relacionamentos ............................................................................................... 31
3.2.2. Documentação de um Caso de Uso .................................................................. 33
Capítulo 4 .......................................................................................................................... 36
Diagrama de Classes........................................................................................................ 36
4.1. O Modelo Entidade-Relacionamento e o Diagrama de Classes............................... 36
4.2. Componentes de um Diagrama de Classes ............................................................. 37
4.2.1. Classes ............................................................................................................. 37
4.2.2. Relacionamentos ............................................................................................... 38
4.2.3. Estereótipo ......................................................................................................... 41
4.2.4. Interface ............................................................................................................ 41
4.2.5. Classes de Associação ...................................................................................... 41
4.2.6. Enumeração ...................................................................................................... 42
4.2.7. Associação Reflexiva ........................................................................................ 42
4.2.8. Escopo de Classe (visibilidade) ........................................................................ 43
4.2.9. Classe Abstrata .................................................................................................. 44
4.3. Construindo um Diagrama de Classes ..................................................................... 44
4.4. Estereótipos da Classe ............................................................................................ 45
4.4. 1. Classes de Fronteira ........................................................................................ 45
4.4.2. Classes de Controle ........................................................................................... 48
4.4.3. Classes de Entidade .......................................................................................... 50
Capítulo 5 .......................................................................................................................... 53
Diagramas de Interação ................................................................................................... 53
5.1. Os Diagramas de Interação...................................................................................... 53
5.2. Diagrama de Sequência .......................................................................................... 54
5.3. Componentes de um Diagrama de Sequência ......................................................... 55
5.3.1. Objetos ............................................................................................................... 55
5.3.2. Atores ................................................................................................................ 56
5.3.3. Mensagens........................................................................................................ 56
5.4. Distribuição de Fluxo de Controle em Diagramas de Sequência ............................ 56
5.5. Diagramas de Comunicação .................................................................................... 60
Capítulo 6 .......................................................................................................................... 64
Diagrama de Máquina de Estados e Diagrama de Atividades ...................................... 64
6.1. Máquina de Estados e Atividades ............................................................................ 64
6.2. Diagrama de Máquina de Estados ........................................................................... 65
6.3. Componentes de um Diagrama de Máquina de Estados ......................................... 66
6.3.1. Estados ............................................................................................................. 66
6.3.2. Transições.......................................................................................................... 67
6.3.3. Condições de Guarda ....................................................................................... 68
6.3.4. Ações ................................................................................................................ 68
6.4. Construindo um Diagrama de Máquina de Estado .................................................. 68
6.5. Diagrama de Atividades .......................................................................................... 69
6.6. Componentes de um Diagrama de Atividades ......................................................... 69
6.7. Construindo um Diagrama de Atividades ................................................................. 72
6.8. Diagramas de Atividades Aninhados ....................................................................... 73
Considerações Finais....................................................................................................... 76
Respostas Comentadas dos Exercícios ......................................................................... 77
Bibliografia ........................................................................................................................ 82
Apresentação
Com o advento da modelagem de software, que é a atividade de construir modelos
que expliquem as características ou o comportamento de um software ou sistema, surgiu a
necessidade de transcrever elementos do mundo real para o mundo conceitual, de modo a
se construir modelos de software capazes de serem compreendidos por profissionais dos
mais diversos segmentos. Para melhor se construir um projeto, podem ser utilizados
diversos paradigmas de modelagem, ou seja, diferentes “formas de abordar um problema”.
Nesta disciplina vamos estudar o paradigma orientado a objetos, que é um
paradigma de análise, projeto e desenvolvimento de sistemas de software baseado na
composição e interação entre diversas unidades de software chamadas de “objetos”.
O paradigma de orientação a objetos visualiza um sistema de software como uma
coleção de agentes interconectados denominados objetos. Cada objeto é responsável por
realizar tarefas específicas. É através da interação entre objetos que uma tarefa
computacional é realizada. A principal vantagem da técnica orientada a objetos para a
modelagem de sistemas é a diminuição da diferença semântica entre a realidade sendo
modelada e os modelos construídos.
Para apresentar o modelo de objetos é necessário o uso de uma ferramenta de
modelagem. Utilizaremos nesta disciplina o modelo proposto pela UML. A UML - Unified
Modeling Language é uma linguagem de modelagem que permite que os desenvolvedores
visualizem o produto de seu trabalho através de diagramas padronizados. Junto com a
notação gráfica, a UML também especifica os significados, isto é, a semântica dos
modelos. Assim, a UML não é uma metodologia de desenvolvimento, o que significa que
ela não diz o que se deve fazer primeiro e em seguida como projetar seu sistema, mas ela
auxilia a visualizar o desenho e a comunicação entre objetos do sistema sendo modelado.
Nós lhe convidamos a conhecer o mundo da modelagem de software por meio das
técnicas da modelagem unificada baseada na UML, caro aluno. Os aspectos teóricos e os
conceitos da UML serão mesclados com a notação, modelagem e relacionamento entre os
diagramas. Você terá, além dos fundamentos teóricos, a possibilidade de ver exemplos
práticos nos quais os diagramas foram aplicados na modelagem. Então, prepare-se, e
venha junto conosco conhecer este tema interessante nas próximas páginas deste
material!
João Caldas Júnior
Elisamara de Oliveira
Capítulo 1
Fundamentos da Orientação a Objetos
Caro aluno, neste capítulo falaremos sobre a importância do processo de
desenvolvimento de software no ambiente da Engenharia de Software, relembraremos
os conceitos sobre os ciclos de vida e abordaremos os conceitos básicos da Orientação
a Objetos, bem como a relevância desses conceitos no cenário atual de
desenvolvimento de software. Exemplificaremos alguns dos principais problemas no
que se refere ao desenvolvimento de sistemas OO.
1.1. Processo de Software e Modelos de Ciclo de Vida

Caro aluno, para entendermos melhor os conceitos fundamentais que envolvem a
modelagem de um software, faremos uma pequena introdução sobre a importância do
processo de desenvolvimento de software, seu contexto e os modelos de ciclo de vida.
Como vimos na disciplina
Engenharia de Software e de
Requisitos, um processo de
desenvolvimento de software, ou
simplesmente processo de
software, pode ser definido
como um conjunto de
disciplinas, atividades e tarefas
necessárias para a geração de
um produto de software,
abordando desde sua Fonte: http://imasters.com.br/artigo/3834/software/inovacao-do-
processo-de-software
concepção até o seu estado
operacional entregue ao usuário.
Um processo de software deve contemplar todo o acompanhamento e controle da
produção do software, abordando os aspectos gerenciais que se fazem necessários no
transcorrer do desenvolvimento. As atividades de gerenciamento de um projeto de
software prezam pelo correto andamento das atividades e tarefas executadas, bem como
pela administração de falhas, imprevistos e mudanças que possam ocorrer em qualquer
uma das disciplinas do processo.
6
Pressman (2006) define processo como sendo “uma série de etapas que envolvem
atividades, restrições e recursos para alcançar a saída desejada”. Sua abordagem sobre o
significado de processo é ampla e cita algumas características que, segundo ele, estão
presentes em todos os processos:
O processo prescreve todas as suas principais atividades;
O processo utiliza recursos, está sujeito a um conjunto de restrições (como um
cronograma) e gera produtos intermediários e finais;
O processo pode ser composto de sub processos de algum modo relacionados.
Ele pode ser definido como uma hierarquia de processos, organizados de tal
maneira que cada sub processo tenha seu próprio modelo de processo;
Cada atividade do processo tem critérios de entrada e saída, de modo que seja
possível saber quando o processo começa e quando termina;
As atividades são organizadas em uma sequência, para que a ordem de
execução de uma atividade em relação às outras seja clara;
Todo processo tem um conjunto de diretrizes que explicam os objetivos de cada
atividade.
A forma como se encadeiam as etapas em um processo de desenvolvimento é

conhecida como modelo de processo ou modelo de ciclo de vida. Existe, porém, o ciclo
de vida do projeto de software e o ciclo de vida do produto de software. Este último
estende-se além do projeto e acompanha o produto de software da sua operação inicial,
passando por possíveis manutenções até quando o software entra em desuso. O ciclo de
vida do processo, por sua vez, é temporário e acaba ao final do projeto de
desenvolvimento, porém deve ser maduro e capaz de ser repetido com o mesmo padrão
de qualidade a cada novo produto que seja desenvolvido.
Há diversos modelos de ciclo de vida, no entanto, é consenso que não existe um
modelo único que atenda a todos os projetos. O ciclo de vida deve ser escolhido de acordo
com a natureza e características do projeto.Os modelos de ciclo de vida diferem um do
outro na forma em que as diversas etapas de processo de software se relacionam entre si.
Caro aluno, você já viu diversos processos de software na disciplina Engenharia de
Software e de Requisitos. Sugiro que você volte àquele material e revise o Modelo Cascata
e o Modelo Iterativo Incremental, que são 2 dos modelos mais conhecidos e utilizados nas
empresas de desenvolvimento de software.
7
Leia o artigo “Conquistando Qualidade para o Projeto” de Marcelo Jacintho
Disponível em: http://www.internativa.com.br/artigo_gestao.html
“...O ciclo de vida a ser adotado será uma das tônicas agora, pois dependendo das
características do projeto, do cliente e da própria equipe, alguns modelos de ciclo de vida não
são recomendáveis. Ainda, o famigerado e tão perseguido ciclo de vida Cascata, se estiver com
grandes chances de ser escolhido, precisará sempre passar por uma crítica muito severa, haja
vista que as estatísticas de desempenho da indústria mundial de TI, largamente divulgadas
pelo Standish Group, apontam para um sucesso menor que 30% no resultado dos projetos, e,
pesquisas correlatas apontam que a utilização de um ciclo de vida que não permite uma
antecipação de riscos, nem testes de parciais do sistema em desenvolvimento, e que ignora a
natureza mutável dos requisitos, está ligada a este ciclo e a este resultado. É claro que não
podemos esquecer que é possível ser bem sucedido utilizando o Cascata, porém o mercado
vem sinalizando muito forte para a utilização de modelos diferentes. ...”
1.2. Introdução à Orientação a Objetos

O termo OO- Orientação a Objetos pressupõe uma organização de software em
termos de coleção de objetos discretos incorporando estrutura e comportamento próprios.
Esta abordagem de organização é essencialmente diferente do desenvolvimento
tradicional de software, onde estruturas de dados e rotinas são desenvolvidas de forma
apenas fracamente acopladas.
O paradigma OO tem como sua entidade essencial o objeto que recebe e envia
mensagens, executa processamentos e pode mudar de estado. Problemas são resolvidos
através de objetos enviando mensagens a objetos.
A tabela 1 mostra, de forma simplificada, um paralelo entre a programação OO e a
programação tradicional.
Tabela 1 – Programação OO x Programação Tradicional
Programação OO Programação Tradicional
Métodos Procedimentos ou funções
Atributos Variáveis e dados
Mensagens Chamadas a procedimentos ou funções
Classes Tipos abstratos de dados
Hereditariedade -
Chamadas sob o controle do sistema Chamadas sob o controle do programador
8
Na OO as funções e os dados são fundidos para formar a entidade objeto. Os
objetos, diferentemente dos dados passivos das linguagens tradicionais, podem atuar.
Suas ações são ativadas pelas mensagens enviadas e depois processadas por funções
chamadas métodos.
Uma coleção de objetos similares é chamada classe. Uma instância de uma classe
é um objeto. A maior abstração é conseguida pelo uso da hierarquia de classes. Para
reutilizar métodos, as hierarquias de classe recorrem ao mecanismo exclusivo da OO que
é a herança ou hereditariedade.
Quando um programa OO é executado ocorrem 3 eventos:
Os objetos são criados de acordo com a necessidade
As mensagens movimentam-se de um objeto para outro
Quando os objetos não são mais necessários, eles são apagados e a área na
memória recuperada
Fonte: http://ccsourcecode.blogspot.com.br/2011/05/o-que-e-orientacao-objetos.html
O paradigma de orientação a objetos favorece a aplicação de diversos conceitos

considerados fundamentais para o desenvolvimento de bons programas, tais como
abstração, encapsulamento, herança e polimorfismo. Alguns conceitos não são exclusivos
desta abordagem, mas são suportados de forma melhor no desenvolvimento orientado a
objetos do que em outras metodologias.
Técnicas de orientação a objetos promovem o compartilhamento de recursos em
diversos níveis distintos. Herança de estruturas de dados e comportamento permite que
estruturas comuns sejam compartilhadas entre diversas classes derivadas similares sem
9
redundância. O compartilhamento de código usando herança é uma das grandes
vantagens da orientação a objetos. Ainda mais importante que a economia de código é a
clareza conceitual de reconhecer que operações sobre objetos diferentes podem ser a
mesma coisa, o que reduz o número de casos distintos que devem ser entendidos e
analisados.
O desenvolvimento orientado a objetos não apenas permite que a informação dentro
de um projeto seja compartilhada como também oferece a possibilidade de reaproveitar
projetos e código em projetos futuros. As ferramentas para alcançar este
compartilhamento, tais como abstração, encapsulamento, polimorfismo e herança, estão
presentes na metodologia; uma estratégia de reuso entre projetos é a definição de
bibliotecas de elementos reusáveis. Entretanto, orientação a objetos não é uma fórmula
mágica para se alcançar reusabilidade; para tanto, é preciso planejamento e disciplina para
se pensar em termos genéricos, não voltados simplesmente para a aplicação corrente.
No que se segue vamos estudar um pouco mais sobre os principais conceitos
ligados à OO.
1.2.1. Abstração
Abstração consiste em focalizar nos aspectos essenciais inerentes a uma entidade e
ignorar propriedades “acidentais”. Em termos de desenvolvimento de sistemas, isto
significa concentrar-se no que um objeto é e faz antes de se decidir como ele será
implementado. O uso de abstração dá ao programador a liberdade de tomar decisões de
desenvolvimento ou de implementação apenas quando há um melhor entendimento do
problema a ser resolvido.
Muitas linguagens de programação modernas suportam o conceito de abstração de
dados, porém, o uso de abstração juntamente com polimorfismo e herança, como
suportado em orientação a objetos, é um mecanismo muito mais poderoso.
O uso apropriado de abstração permite que um mesmo modelo conceitual
(orientação a objetos) seja utilizado para todas as fases de desenvolvimento de um
sistema, desde sua análise até sua documentação.
Na modelagem orientada a objetos uma das questões mais importantes consiste na
identificação de abstrações que melhor descrevem o domínio do problema. É a capacidade
de identificação de aspectos semelhantes quanto à forma e ao comportamento que
permitem a organização das classes.
10
1.2.2. Objetos e Classes
Um objeto é definido como uma entidade concreta com limites e significados bem
definidos para a aplicação sendo desenvolvida. Um objeto possui:
Identidade: característica que o distingue dos demais objetos
Estado: conjunto de valores de seus atributos em um determinado instante
Comportamento: reação apresentada às solicitações feitas por outros objetos
com os quais se relaciona
Os objetos têm dois propósitos: promover o entendimento do mundo real e suportar
uma base prática para uma implementação computacional. Não existe uma maneira
“correta” de decompor um problema em objetos; esta decomposição depende do
julgamento do projetista e da natureza do problema. Todos os objetos têm identidade
própria e são distinguíveis.
Uma classe descreve um grupo de objetos com propriedades (atributos) similares,
comportamento (operações) similares, relacionamentos comuns com outros objetos e uma
semântica comum. Por exemplo, considere que PessoaFisica e PessoaJuridica
sejam classes de objetos. Entretanto, devido à distinção semântica, elas provavelmente
estariam agrupadas em outra classe como Entidade.
A figura 1 mostra outro exemplo de classe e objeto. Na figura 1 existe a classe
Pessoa e uma enfermeira, um musico e um jogador seriam objetos desta classe.
Figura 1 – Exemplo de Classe e Objeto
Como se pode observar, o agrupamento em classes não leva em conta apenas o

compartilhamento de propriedades. O agrupamento de objetos em classes é um poderoso
mecanismo de abstração. Desta forma, é possível generalizar definições comuns para uma
11
classe de objetos, ao invés de repeti-las para cada objeto em particular. Esta é uma das
formas de reutilização e economia que a abordagem de orientação a objetos suporta.
Nas classes são encontrados atributos e métodos que resumem as características
comuns de vários objetos.
Diferença fundamental entre classes e objetos:

um objeto constitui uma entidade concreta com tempo e
espaço de existência
a classe é somente uma abstração (tipo de dado definido
pelo usuário)
1.2.3. Atributos
Um atributo é um valor de dado assumido pelos objetos de uma classe. É um dado
ou informação de estado, para o qual cada objeto em uma classe tem seu próprio valor.
Por exemplo, um objeto da classe PessoaFisica tem um nome e uma idade; cada
objeto da classe PessoaJuridica também tem um nome e uma idade a partir da sua
data de fundação; estes seriam atributos comuns das duas classes.
Se considerarmos uma outra classe Transportes, por exemplo, cor,
fabricante e modelo seriam possíveis atributos de objetos Carro, que seriam
instâncias da classe Transporte.
Cada atributo tem um valor para
cada instância de objeto. Diferentes
instâncias de objetos podem ter o mesmo
valor para um dado atributo. A figura 2
mostra um exemplo de atributos de objetos
da classe Pessoa mostrada na figura 1.
Estes atributos: nome, rg e idade são
comuns a todos os objetos, mas seus
valores são diferentes, neste caso.
Figura 2 – Exemplo de Atributos dos Objetos

da Classe Pessoa
12
1.2.4. Operações e Métodos
Uma operação é uma função ou transformação que pode ser aplicada a objetos em
uma classe. Por exemplo, abrir, salvar e imprimir são operações que podem ser
aplicadas a objetos da classe Arquivo. Todos os objetos em uma classe compartilham as
mesmas operações.
Toda operação tem um objeto-alvo como um argumento implícito. O comportamento
de uma operação depende da classe de seu alvo. Como um objeto “sabe” qual é sua
classe, é possível escolher a implementação correta da operação. Além disto, outros
argumentos (parâmetros) podem ser necessários para uma operação.
Uma mesma operação pode se aplicar a diversas classes diferentes. Quando isso
acontece, uma operação como esta é chamada de polimórfica, ou seja, ela pode assumir
distintas formas em classes diferentes.
Um método é a implementação de uma operação para uma classe. Por exemplo, a
operação imprimir pode ser implementada de forma distinta, dependendo se o arquivo a
ser impresso contém apenas texto não formatado, é um arquivo de um processador de
texto ou um arquivo binário. Todos estes métodos executam a mesma operação -- imprimir
o arquivo; porém, cada método será implementado por um diferente código.
Voltando ao exemplo da classe Pessoa, a figura 3 mostra alguns métodos que
poderiam ser aplicados aos seus objetos, como cadastrar, alterar, excluir.
Figura 3 – Exemplo de Métodos da Classe Pessoa
13
A assinatura de um método é dada pelo número e tipos de argumentos do método,
assim como por seu valor de retorno. Uma estratégia de desenvolvimento recomendável é
manter assinaturas coerentes para métodos implementando uma dada operação, assim
como um comportamento consistente entre as implementações.
1.2.5. Encapsulamento
Encapsular, ou “esconder informação”, consiste em separar os aspectos externos de
um objeto, que são acessíveis a outros objetos, dos detalhes internos de sua
implementação, que permanecem escondidos. O uso de encapsulamento evita que um
programa torne-se interdependente de tal maneira que uma pequena mudança possa
provocar grandes efeitos colaterais.
O uso de encapsulamento permite que a implementação de um objeto possa ser
modificada sem afetar as aplicações que utilizam este objeto. Motivos para modificar a
implementação de um objeto podem ser, por exemplo, melhoria de desempenho, correção
de erros, mudança de plataforma de execução, dentre outros.
Assim como a abstração, o conceito de encapsulamento não é exclusivo da
abordagem de orientação a objetos. Entretanto, a habilidade de se combinar estrutura de
dados e comportamento em uma única entidade, torna o encapsulamento mais elegante e
mais poderoso do que em paradigmas convencionais que separam estruturas de dados e
comportamento.
1.2.6. Herança
Herança e generalização são abstrações poderosas para compartilhar similaridades
entre classes e ao mesmo tempo preservar suas diferenças. Generalização é o
relacionamento entre uma classe e uma ou mais versões refinadas (especializadas) desta
classe. A classe sendo refinada é chamada de superclasse ou classe base, enquanto que
a versão refinada da classe é chamada uma subclasse ou classe derivada. Atributos e
operações comuns a um grupo de classes derivadas são colocadas como atributos e
operações da classe base, sendo compartilhados por cada classe derivada. Diz-se que
cada classe derivada herda as características de sua classe base. Algumas vezes,
generalização é chamada de relacionamento is-a (é-um), porque cada instância de uma
classe derivada é também uma instância da classe base.
14
Herança e generalização são transitivas, isto é, podem ser recursivamente aplicadas
a um número arbitrário de níveis. Cada classe derivada não apenas herda todas as
características de todos seus ancestrais como também pode acrescentar seus atributos e
operações específicos.
A herança é uma característica exclusiva da OO e permite ao programador criar
novas classes programando apenas as diferenças entre elas e a classe-pai, já que herdam
dados e métodos desta. É o fruto de um mecanismo de hierarquia entre as classes, onde
uma classe mais especializada (classe-filha) herda as propriedades da classe mais geral
(classe-pai) a que ela está imediatamente subordinada. Como falamos antes, a classe
mais geral é denominada superclasse (ou classe base) e a classe mais especializada é
chamada de subclasse (ou classe derivada). Através da herança pode-se compartilhar
automaticamente métodos e atributos entre diferentes classes.
A figura 4 mostra um exemplo de herança na classe Pessoa mostrada nas figuras
1, 2 e 3. No exemplo, nome, rg e idade são atributos da classe base Pessoa, que serão
herdados pelas classes derivadas Aluno e Professor.
Figura 4 – Exemplo de Herança
1.2.7. Polimorfismo
Objetos agem em resposta às mensagens que recebem. A mesma mensagem pode
resultar em ações diferentes quando recebidas por objetos diferentes. Esse fenômeno é
conhecido como polimorfismo, que permite que um usuário possa enviar uma mensagem
genérica e deixar os detalhes de implementação para o objeto receptor. Uma mensagem
15
de impressão, por exemplo, quando enviada a uma figura pode acessar métodos
diferentes daqueles acessados quando é enviada para um texto.
Polimorfismo significa “várias formas”. Para se aplicar polimorfismo é necessário
que haja uma relação de herança entre classes. Consiste em utilizar o mesmo método em
situações diferentes, de acordo com a classe em que foi definido. O polimorfismo em uma
mesma classe é chamado de sobrecarga de método (overloading).
Como exemplo, consideremos a figura 6, em que o exemplo da classe Pessoa
apresentado na figura 5 é retomado.
Na figura 5 podemos observar que os métodos cadastrar, alterar e excluir
são os mesmos herdados da classe Pessoa, mas certamente estas operações
relacionadas com Aluno e Professor têm implementações bastante distintas, em função
dos dados associados a cada um deles.
Figura 5 – Exemplo de Polimorfismo
1.3. RUP - Rational Unified Process
Caro aluno, você também já estudou sobre o Processo Unificado na disciplina

Engenharia de Software e de Requisitos. Vamos retomar um pouco este tema aqui.
Aproveite e volte ao material para relembrar...
16
O IBM Rational Unified Process®, ou RUP®, é uma plataforma de processo de
desenvolvimento de software configurável que oferece melhores práticas comprovadas e
uma arquitetura configurável. O RUP é baseado na metodologia orientada a objetos que
define claramente quem é responsável pelo quê, como e quando as atividades devem ser
feitas e descreve todas as metas de desenvolvimento para que sejam alcançadas.
O RUP suporta a customização e autoria de processos e uma grande variedade de
processos, ou de configuração de processos, podem ser montadas em sua plataforma.
Essas configurações do RUP podem ser criadas para suportar tanto equipes grandes
quanto pequenas, que trabalhem com técnicas de desenvolvimento bem disciplinadas ou
menos formais. O produto RUP contém várias configurações e visões de processos
prontas que guiam analistas, desenvolvedores, testadores, gerentes de projeto, gerentes
de configuração, analistas de dados, e outros membros da equipe de desenvolvimento, em
como desenvolver o software. Ele tem sido utilizado por muitas empresas em diferentes
setores da indústria.
Para apresentarmos exemplos compreensíveis utilizando a UML ou Linguagem
Unificada de Modelagem teremos de utilizar alguma noção de processo, visto que a UML
não define a relação entre os diagramas. Portanto, em nossos exemplos, para especificar,
modelar e documentar a relação entre os diagramas apresentados, utilizaremos conceitos
relacionados ao processo RUP.
Leia mais sobre RUP – Rational Unified Process online e utilize-o!
UP significa Unified Process ou Processo Unificado e é um processo que define

quem (papel funcional) faz o quê (artefato), como (atividades) e quando (disciplina)
em um projeto de software. O RUP – Rational Unified Process é uma instância
detalhada do UP. Possui uma grande quantidade de materiais para ajudar a melhorar a
produtividade da equipe. O RUP é um produto proprietário da Rational (IBM), mas no
site colaborativo abaixo pode-se usá-lo e usufruir muitas das características do
processo.
http://www.wthreex.com/rup/portugues/index.htm (em português)
http://www.wthreex.com/rup/smallprojects/index.htm (em inglês)
17
Exercícios do Capítulo 1
1) O que é um Modelo de Ciclo de Vida de um software?
2) Quais as restrições à utilização do Modelo Cascata?
3) Categorize os relacionamentos listados a seguir. Atenção, podem existir

associações binárias ou agregações na lista, portanto não presuma que todo
relacionamento seja uma generalização.
a) Um país possui uma capital

b) Um filósofo à mesa de jantar está usando uma faca
c) Uma conta corrente pode ser Normal ou Especial
d) Uma pessoa utiliza uma linguagem de programação em um projeto
18
Capítulo 2
UML – Unified Modeling Language
Caro aluno, neste capítulo falaremos sobre a UML, uma ferramenta essencial na
modelagem de sistemas orientados a objetos. Abordaremos os conceitos básicos da modelagem
unificada, como e quando ela surgiu, sua estrutura e seu futuro.
2.1. Breve Histórico da UML

A sigla UML é o acrônimo de Unified Modeling
Language ou Linguagem de Modelagem Unificada de
projetos orientados a objetos. Como o próprio nome diz,
UML é uma linguagem de modelagem e não um método,
metodologia, processo ou linguagem de programação!
A UML é uma linguagem padrão de notação de projetos OO. Notação se refere aos
instrumentos para especificar, visualizar e documentar os elementos de um sistema OO. A
UML é importante, pois:
serve como linguagem para expressar decisões de projeto que não são óbvias
ou que não podem ser deduzidas do código;
provê uma semântica que permite capturar as decisões estratégicas e táticas do
projeto;
provê uma forma concreta o suficiente para a compreensão das pessoas e para
ser manipulada pelas máquinas;
é independente das linguagens de programação e dos métodos de
desenvolvimento
Além de fornecer a tecnologia necessária para apoiar a prática de Engenharia de
Software orientada a objetos, a UML pode ser, também, a linguagem de modelagem
padrão para modelar sistemas concorrentes e distribuídos.
Nos anos 1990, conhecida como a época da “guerra dos métodos”, vários métodos
coexistiam com notações muitas vezes conflitantes entre si. Dentre estes, os mais
conhecidos eram:
OMT- Object Modeling Technique, de Rumbaugh
Método de Booch
OOSE- Object Oriented Software Engineering, de Jacobson
19
Inicialmente, Rumbaugh e
Booch fundiram seus métodos (e
notações) resultando no Método
Unificado. em 1995. quando
trabalhavam juntos na Rational
Software (atualmente uma divisão da
IBM). Jacobson juntou-se a eles mais
tarde e seu método OOSE foi
incorporado ao novo processo
denominado RUP- Rational Unified
Process. Além do método, eles
unificaram a notação de projeto e a
chamaram de UML – Unified Modeling
Language. Assim, UML representa a
unificação das notações de Booch,
Fonte:http://anaclaudiarocha.eti.br/imagens/Charge%20h
Rumbaugh e Jacobson. istorico%20da%20UML.JPG
A UML também agrega as ideias de vários outros autores, tais como Harel e seu
diagramas de estados, Shlaer-Mellor e o ciclo de vida dos objetos. Em resumo, a UML é o
resultado da busca pela padronização dos artefatos de análise e projeto, quais sejam:
modelos semânticos, sintaxe de notação e diagramas.
Na década de 1990, surge uma organização importante no mundo do paradigma
orientado a objetos, a OMG - Object Management Group, uma entidade sem fins lucrativos
da qual participam empresas e academias para definirem padrões de tecnologias OO.
No que se segue, apresentamos os principais marcos do desenvolvimento da UML:
• Em outubro de 1995 é lançada a primeira versão rascunho, versão 0.8 draft.
• Em Julho de 1996 é feita uma revisão devido ao ingresso de Jacobson, versão
0.9 draft.
• Parceiros da UML - HP, IBM, Microsoft, Oracle e Rational Software-
desenvolveram a versão 1.1 e a propuseram para a OMG
• Em novembro de 1997 a OMG aceita a proposta e assume a responsabilidade
de realizar a manutenção e a revisão da UML
• Em março de 2003 a OMG lança a versão 1.5
• Em outubro de 2004 a OMG lança a versão 2.0
20
2.2. Organização dos Diagramas da UML
A UML utiliza-se de um conjunto de técnicas de notação gráfica para criar modelos
visuais de software, combinando técnicas de modelagem de dados, negócios, objetos e
componentes. É uma linguagem de modelagem unificada, comum e amplamente utilizável.
Embora possibilite representar o software através de modelos orientados a objetos,
a UML não mostra que tipo de implementação deve ser feita, ou seja, não possui um
processo que define detalhes de como o trabalho tem que ser desenvolvido. O seu objetivo
é descrever “o que fazer”, “como fazer”, “quando fazer” e “porque deve ser feito”. É
necessária a elaboração completa de um dicionário de dados para descrever todas as
entidades envolvidas. Este processo permite que se realize o refinamento dos requisitos
funcionais do software.
A Linguagem Unificada de Modelagem possui modelos ou diagramas
(representações gráficas do modelo parcial de um sistema) que são usados, de forma
combinada, com a finalidade de obter todas as visões e aspectos do sistema. Os
diagramas da UML (veja figura 6) estão divididos em Estruturais e Comportamentais e são
os seguintes:
• Diagramas Estruturais
Diagrama de Classe
Diagrama de Objeto
Diagrama de Componentes
Diagrama de Implantação
Diagrama de Pacotes
Diagrama de Estrutura Composta
• Diagramas Comportamentais
Diagrama de Caso de Uso
Diagrama de Máquina de Estados
Diagrama de Atividades
Diagramas de Interação, que dividem-se em:
o Diagrama de Sequência
o Diagrama de Interação Geral
o Diagrama de Comunicação
o Diagrama de Tempo
21
Figura 6 – Diagramas da UML
Fonte: http://www.infoescola.com/wp-content/uploads/2010/03/DiagramasdaUML.jpg
2.3. Diagramas da UML

Um diagrama é uma representação gráfica de um conjunto de elementos, como
classes, interfaces, colaborações, componentes, nós, etc. Os diagramas são usados para
visualizar o sistema sob diferentes perspectivas. A UML define um grande número de
diagramas que permite dirigir o foco para aspectos diferentes do sistema de maneira
independente. Se bem usados, os diagramas facilitam a compreensão do sistema que está
sendo desenvolvido.
Nas próximas seções serão apresentados, de forma resumida, os diagramas que
compõem a linguagem UML em sua versão 2.0. Nos próximos capítulos deste material, os
principais diagramas serão abordados separadamente e com maior detalhamento.
22
2.3.1. Diagrama de Casos de Uso
O diagrama de casos de uso especifica um conjunto de funcionalidades, através do
elemento sintático “casos de uso”, e os elementos externos que interagem com o sistema,
através do elemento sintático “ator”. [SILVA, 2007] Além de casos de uso e atores, este
diagrama contém relacionamentos de dependência, generalização e associação.
Estes diagramas são basicamente usados para fazer a modelagem de visão estática
dos casos de uso do sistema. Essa visão proporciona suporte principalmente para o
comportamento de um sistema, ou seja, os serviços externamente visíveis que o sistema
fornece no contexto de seu ambiente. Os diagramas de caso de uso são usados para fazer
a modelagem do contexto de um sistema e fazer a modelagem dos requisitos de um
sistema.
2.3.2 Diagrama de Classes

Um diagrama de classes é um modelo fundamental de uma especificação orientada
a objetos. Produz a descrição mais próxima da estrutura do código de um programa, ou
seja, mostra o conjunto de classes com seus atributos e métodos e os relacionamentos
entre classes. Classes e relacionamentos constituem os elementos sintáticos básicos do
diagrama de classes. [SILVA, 2007]
2.3.3. Diagrama de Objetos

O diagrama de objetos consiste em uma variação do diagrama de classes em que
são representadas instâncias e ligações entre instâncias de classes, que constituem os
objetos. A finalidade é descrever um conjunto de objetos e seus relacionamentos em um
ponto no tempo. Contém objetos e vínculos e são usados para fazer a modelagem da
visão de projeto estática de um sistema a partir da perspectiva de instâncias reais.
2.3.4. Diagrama de Pacotes

Um pacote, em orientação a objetos, funciona como um “agrupador” que une e
organiza um conjunto de classes, diagramas, arquivos ou mesmo outros pacotes de um
sistema. Um diagrama de pacotes tem por finalidade tratar a modelagem estrutural do
sistema particionando o modelo em divisões lógicas, descrevendo as interações entre os
23
pacotes e mostrando as dependências entre eles, uma vez que pacotes podem depender
de outros pacotes.
Este diagrama é muito utilizado para representar a arquitetura de um sistema
mostrando o agrupamento de suas classes, já que um pacote pode representar um grupo
de classes que se relacionam com outros pacotes através de uma relação de dependência.
2.3.5. Diagrama de Sequência

O diagrama de sequência mostra a troca de mensagens entre diversos objetos, em
uma situação específica e delimitada no tempo. Dá ênfase à ordenação temporal em que
as mensagens são trocadas entre os objetos de um sistema. Mensagens são os serviços
solicitados de um objeto a outro e as respostas desenvolvidas para as solicitações.
O diagrama de sequência descreve a maneira como os grupos de objetos
colaboram em algum comportamento ao longo do tempo. Geralmente registra o
comportamento de um único caso de uso e exibe os objetos e as mensagens passadas
entre eles no caso de uso.
2.3.6. Diagrama de Comunicação

O diagrama de comunicação normalmente é utilizado como complemento do
diagrama de sequência, embora possua um enfoque diferente já que concentra-se em
como os objetos estão vinculados através de mensagens. Assim, pode ser gerado a partir
do diagrama de sequência por representar os mesmos dados.
Este diagrama descreve objetos interagindo e seus principais elementos sintáticos
são “objeto” e “mensagem”. Apresenta um formato alternativo para descrever a interação
entre objetos. Ao contrário do diagrama de sequência, o tempo não é modelado
explicitamente, uma vez que a ordem das mensagens é definida através de enumeração.
Vale ressaltar que tanto o diagrama de comunicação como o diagrama de sequência são
diagramas de interação.
2.3.7. Diagrama de Atividades

O diagrama de atividades representa a execução das ações e as transições que são
acionadas pela conclusão de outras ações ou atividades. Diagramas de atividade são
similares aos diagramas de fluxo de dados, com a diferença que as atividades são
24
relacionadas aos objetos. Estes diagramas estão sempre associados a uma Classe,
uma Operação ou um Caso de Uso.
Os diagramas de atividade suportam atividades sequenciais e paralelas. Para as
atividades executadas em paralelo não é importante a ordem na qual elas são executadas,
já que podem ser executadas ao mesmo tempo ou uma após a outra. As atividades
sequenciais são registradas através de ações e transições que seguem um ordenamento.
2.3.8. Diagrama de Estrutura Composta

O diagrama de estrutura composta detalha elementos de modelagem estrutural,
como classes, pacotes e componentes, descrevendo sua estrutura interna.
Este diagrama é utilizado essencialmente para modelar colaborações. Uma
colaboração descreve uma visão de um conjunto de entidades representadas por
instâncias que cooperam entre si para executar uma função específica. Reflete a
colaboração interna das classes para descrever uma funcionalidade. O termo estrutura
desse diagrama refere-se a uma composição de elementos interconectados,
representando instâncias que colaboram, na linha do tempo de execução, por meio de
vínculos de comunicação, para atingir algum objetivo comum. [GUEDES, 2007]
2.3.9. Diagrama de Componentes

O Diagrama de Componentes tem por finalidade indicar os componentes do
software e seus relacionamentos. Um componente define seu comportamento em termos
de interfaces fornecidas e requeridas. O diagrama pode ilustrar como as classes devem se
encontrar organizadas através da noção de componentes de trabalho, podendo-se
explicitar, para cada componente, qual das classes que ele representa. Este diagrama
mostra os artefatos de que os componentes são feitos, como arquivos de código fonte,
bibliotecas de programação ou tabelas de bancos de dados. As interfaces é que
possibilitam as associações entre os componentes.
2.3.10. Diagrama de Implantação

O diagrama de implantação, também denominado diagrama de instalação, consiste
na organização do conjunto de elementos de um sistema para a sua execução. Descreve
os componentes de hardware e software e sua interação com outros elementos de suporte
ao processamento. O principal elemento deste diagrama é o nó, que representa um
25
recurso computacional. Podem ser representados tanto os nós como as instâncias de nós.
O diagrama de implantação é útil em projetos onde há muita interdependência entre partes
de hardware e software.
2.3.11. Diagrama de Tempo

O diagrama de tempo consiste na modelagem de restrições temporais do sistema.
Apresenta o comportamento dos objetos e sua interação em uma escala de tempo,
enfatizando as condições que mudam no decorrer desse período.
Este diagrama descreve a mudança no estado ou condição de uma instância de
uma classe durante um período de tempo. É tipicamente utilizado para mostrar a mudança
no estado de um objeto no tempo em resposta a eventos externos.
2.3.12. Diagrama de Máquina de Estados

O diagrama de máquina de estados tem como elementos principais o estado, que
modela uma situação na qual o elemento modelado pode estar ao longo de sua existência,
e a transição, que leva o elemento modelado de um estado para o outro. O diagrama
procura acompanhar as mudanças sofridas por um objeto dentro de um determinado
processo. Como o diagrama de sequência, este diagrama muitas vezes baseia-se em um
Caso de Uso descrito em um diagrama de caso de uso e apoia-se no diagrama de classes.
O diagrama de máquina de estados é utilizado geralmente para acompanhar os
estados pelos quais uma instância de uma classe (objeto) passa. No entanto, pode ser
utilizado para representar os estados de um caso de uso, os estados gerais de um
subsistema ou mesmo de um sistema completo.
2.3.13. Diagrama de Interação Geral

O diagrama de interação geral é uma variação do diagrama de atividades e seus
elementos sintáticos são os mesmos do diagrama de atividades. Fornece uma visão geral
dentro de um sistema ou processo de negócio. As interações que fazem parte deste
diagrama podem ser referências a diagramas de interação existentes na especificação do
sistema sendo modelado.
26
2.4. O Futuro da UML
Um sistema de software é
inerentemente muito abstrato e,
portanto, difícil de ser visualizado. Uma
linguagem de modelagem, como a UML,
contribui para se quebrar este alto nível
de abstração, permitindo que o software
possa ser visualizado em diferentes
dimensões, de forma que o sistema
possa ser compreendido antes de ser
implementado. Além disso, a UML pode
ser usada para produzir vários modelos
do sistema com níveis crescentes de detalhamento.
Um aspecto muito interessante, também, é que não somente sistemas novos
podem ser modelados. A UML pode ser utilizada para modelar um sistema já existente,
fornecendo uma visão mais adequada do mesmo para facilitar sua manutenção ou
atualização. Além disso, a UML documenta um sistema. Um software bem documentado
apresenta grande vantagem, já que o torna visível e transparente, facilitando sua
compreensão e manutenção.
A UML é uma linguagem unificada e universal e pode ser aplicada em muitas áreas
de desenvolvimento de software, já que foi concebida para fornecer mecanismos de
especialização e extensão que permitem a modelagem de requisitos específicos de
diferentes sistemas. Adicionalmente, a UML é independente das linguagens de
programação usadas e dos processos de desenvolvimento.
Com todas estas vantagens, a UML vem se tornando um padrão mundialmente
utilizado para a modelagem de sistemas. Embora seu uso e sua aceitação sejam
crescentes, o seu desenvolvimento não está estagnado e seus mecanismos estão sujeitos
a aperfeiçoamentos. Além disso, novas técnicas de modelagem podem ser definidas
usando a própria UML como base.
Cada vez mais ferramentas de integração e padrões de implementação estão sendo
criados baseados na UML. Isso vem facilitando o trabalho dos desenvolvedores e
disseminando, cada vez mais, o desenvolvimento de sistemas orientados a objetos.
27
1) Assinale “F” para falso ou “V” para verdadeiro:
( ) A UML pode ser utilizada somente para modelagem de sistemas ligados à área de
Informática.
( ) UML é uma linguagem para especificação, documentação, visualização e

desenvolvimento de sistemas orientados a objetos.
( ) Ao se modelar um sistema utilizando a UML, segundo normas do grupo gestor da

UML (Object Management Group - OMG), tem-se que utilizar pelo menos quatro de seus
diagramas.
( ) A UML é um método de desenvolvimento, o que significa que ela diz o que fazer
primeiro e em seguida como desenhar seu sistema.
2) Faça a relação entre os conceitos e os diagramas:
28
Capítulo 3
Diagrama de Casos de Uso
Caro aluno, neste capítulo descreveremos os diagramas de casos de uso da
UML. Casos de uso são elementos classificadores que representam uma unidade
funcional coerente provida pelo sistema, subsistema, ou classe manifestada por
sequências de mensagens intercambiáveis entre os sistemas e um ou mais usuários. Os
casos de uso podem possuir narrativas em texto, descrevendo a unidade funcional, e
são amplamente utilizados para descobrir e registrar requisitos de sistemas.
3.1. Análise de Requisitos e Diagramas de Casos de Uso

A criação dos diagramas de Casos de Uso acontece comumente na fase de Análise
de Requisitos. Conforme estudamos na disciplina Engenharia de Software e de Requisitos,
é a fase responsável por manter a concordância entre os clientes e stakeholders sobre o
que o sistema deverá fazer, além de possibilitar que a equipe de desenvolvimento
compreenda os requisitos elencados e delimite o sistema e suas fronteiras. O profissional
responsável por identificar os requisitos junto ao cliente, modelar casos de uso,e delimitar
o sistema, expondo suas funcionalidades, é o Analista de Requisitos.
A Análise de Requisitos consiste em determinar os serviços que o usuário espera do
sistema e as condições (restrições) sob as quais o sistema que será desenvolvido deva
operar. As necessidades do usuário podem ser muito variadas e o analista deve ser capaz
de extrair os requisitos funcionais e não-funcionais destas necessidades:
Os requisitos funcionais expressam o comportamento de um software. As
informações de entrada, o processamento e a saída emitida por uma
funcionalidade são informações necessárias para especificar seus requisitos.
Os requisitos não funcionais mapeiam os aspectos qualitativos de um
software, por exemplo: performance (tempo de resposta); segurança (restrições
de acesso, privilégios); perspectiva do usuário (padrão das cores, disposição dos
objetivos na tela); comunicabilidade (e-mail, VoIP, browser); usabilidade e
portabilidade (a aplicação deve rodar em vários tipos de aplicativos: móveis,
desktop, note).
29
Os Casos de Uso
so representam funcionalidades completas para o usuário e não
funcionalidades internas do sistema.
sistema O diagrama de casos de uso é um artefato de
comunicação entre cliente, usuários e desenvolvedores. Por ser extremamente simples e,
consequentemente, de fácil compreensão, incentiva a participação do cliente e usuários no
processo de desenvolvimento. Também serve como um contrato entre
entre a equipe/empresa
desenvolvedora e o cliente.
3.2. Componentes de um Diagrama de Casos de Uso

O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os
analistas e o cliente. Um diagrama de Caso de Uso descreve um cenário que mostra as
funcionalidades do sistema do ponto de vista do usuário. Assim, o cliente deve ver no
diagrama de
e Casos de Uso as principais funcionalidades de seu sistema.
3.2.1. Atores e Casos de uso

O diagrama de Caso de Uso é representado por:
atores
casos de uso
relacionamentos
onamentos entre estes elementos
Os casos de uso podem,

podem opcionalmente, estar envolvidos por um retângulo que
representa os limites do sistema. No que se segue, estes elementos são apresentados em
detalhes.
• Atores
Um ator é representado por um boneco e um rótulo com o

nome do ator. Um ator é um usuário do sistema, que pode
ser um usuário humano ou um outro sistema computacional.
30
• Caso de uso
Um caso de uso é representado por uma elipse e um rótulo

com o nome do caso de uso. Um caso de uso define uma
grande função do sistema. A implicação é que uma função
pode ser estruturada em outras funções e, portanto, um caso
de uso pode ser estruturado.
3.2.2. Relacionamentos
Os relacionamentos nos diagramas de caso de uso podem ser:
associações
ões entre atores e casos de uso
generalizações entre os atores
generalizações, extends e includes entre os casos de uso.
• Associação (entre
ntre um ator e um caso de uso)
uso
Define uma funcionalidade do

sistema do ponto de vista do
usuário.
• Generalização (entre
ntre atores)
atores
Os casos de uso do Ator A são também

casos de uso do Ator B.
O ator B tem seus próprios casos de uso.
uso
• Include (entre
ntre casos de uso)
uso
Um relacionamento include de um caso de uso A para

um caso de uso B indica que B é essencial para o
comportamento de A. Pode ser dito também que B
é_parte_de A.
31
• Extend (entre casos de uso)
Um relacionamento extend de um caso de uso B

para um caso de uso A indica que o caso de uso B
pode ser acrescentado para descrever o
comportamento de A (não é essencial). A extensão
é inserida em um ponto de extensão do caso de uso
A.
Ponto de extensão em um caso de uso é uma indicação de que outros casos de uso
poderão ser adicionados a ele. Quando o caso de uso for invocado, ele verificará se
suas extensões devem ou não serem invocadas.
Você entendeu?! Provavelmente, não. O extend é considerado
considera um conceito
obscuro. Vamos a novas explicações. Quando se especifica B extends A, a semântica
é:
Dois casos de uso são definidos: A e A extended by B;
B é uma variação de A: contém
contém eventos adicionais, para certas condições;
Tem que ser especificado onde B é inserido em A.
• Generalização ou Especialização (é_um)
Um caso de uso B é um tipo específico do caso de

uso A (A é uma generalização de B, ou B é uma
especialização de A).
m relacionamento entre um caso de

Representa um
uso genérico para um mais específico, que herda
todas as características de seu pai.
A figura 7 mostra um exemplo

ex de um Caso de Uso.. Este diagrama se refere ao
projeto Casa Segura.
32
Figura 7 - Diagrama de Caso de Uso para o Sistema Casa Segura
3.2.2. Documentação de um Caso de Uso

O diagrama de casos de uso é apenas
um panorama visual das funcionalidades do
sistema; é necessária uma descrição textual
para detalhar os casos de uso. Vejamos, como
exemplo, o caso de uso “Autorizar Proprietário”
apresentado no diagrama da figura 7. Para que
este caso de uso fique mais bem esclarecido e
documentado, criamos a tabela 2. A tabela 2
ilustra a documentação para este caso de uso
contido no diagrama do sistema Casa Segura.
Figura 8 – Exemplo de uma interface para A figura 8 ilustra uma possível interface para
o sistema Casa Segura este sistema.
Fonte: http://www.sraengenharia.blogspot.com.br/
33
Tabela 2 – Documentação do Caso de Uso “Autorizar Proprietário” do
sistema Casa Segura
Caso de Uso Autorizar Proprietário
Caso de Uso Geral Realizar a autorização de um proprietário
Ator Principal Proprietário
Pré-condição Sistema estar Ligado
Fluxo Principal 1. O proprietário digita seu username
2. O proprietário digita sua senha
3. O proprietário pressiona o botão “Autorizar”
4. O sistema verifica as informações de login
5. O sistema apresenta a tela inicial da aplicação
Fluxos Alternativos 1. Numa situação de Exceção - A partir do passo 4

2. O sistema apresenta a tela de login
3. O proprietário digita seu username
4. O proprietário digita sua senha
5. O sistema verifica que a senha e/ou username estão
incorretos
6. O sistema mostra mensagem de erro
7. O proprietário re-digita o username e a senha
Pós-condição Proprietário Autorizado
Com base no que estudamos, podemos concluir que a saída da fase de análise de
requisitos deve ser composta por:
Lista de requisitos funcionais e não-funcionais;
Diagrama de casos de uso e documentações textuais dos casos.
34
1) Descreva a posição do diagramas de casos de uso no processo de

desenvolvimento incremental e iterativo.
2) Faça uma tabela que mostre que tipos de relacionamentos são possíveis entre um ator
e um caso de uso. Que tipo de relacionamento pode haver entre casos de uso? Que tipo
de relacionamento pode haver entre atores?
3) Construa um modelo de casos de uso para a seguinte situação fictícia: "Estamos

criando um serviço de entregas. Nossos clientes podem nos requisitar via portal do
sistema a entrega de volumes. Alguns volumes são considerados de maior valor por
nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o
transporte. Contratamos uma companhia de seguro para segurar volumes de valor".
35
Capítulo 4
Diagrama de Classes
Caro aluno, neste capítulo descreveremos o Diagrama de Classes que é um dos
mais importantes diagramas da UML. Este diagrama está no centro da arquitetura de
um sistema OO e é a partir dele que outros diagramas são elaborados. O diagrama de
classes é uma importante ferramenta para a documentação de um sistema ou produto
de software OO.
4.1. O Modelo Entidade-Relacionamento e o Diagrama de

Classes
Um Diagrama de Classes é uma representação da estrutura e das relações
das classes que servem de modelo para objetos de um sistema OO. O diagrama de
classes é similar ao Modelo de Entidade-Relacionamento (MER) utilizado em banco de
dados relacional, porém, ele se encontra em um nível de abstração de mais alto nível.
Além disso, possui uma importante diferença em relação ao MER, pois representa o
comportamento da classe através de suas operações ou métodos. A persistência é uma
importante característica no conceito desse diagrama, uma vez que algumas classes
podem representar, no projeto do sistema, entidades físicas que serão futuramente
implementadas no banco de dados.
Guedes (2008, p. 75) fornece um interessante relato comparando o MER com o
diagrama de classes: “em muitos casos pode ser necessário preservar de maneira
permanente os objetos de uma Classe, ou seja, esta deve ser persistente. Uma classe
persistente apresenta muitas semelhanças com uma entidade como aquelas definidas no
antigo Modelo Entidade-Relacionamento utilizado para definir as estruturas de tabelas em
bancos de dados relacionais. [...] Na verdade, o diagrama de classes foi intencionalmente
projetado para ser uma evolução do Modelo Entidade-Relacionamento e pode ser utilizado
para modelar a estrutura lógica das tabelas que irão compor um banco de dados.”
A figura 9 apresenta, a título de curiosidade, um exemplo de um MER.
No que se segue apresentaremos os principais componentes do diagrama de
classes, juntamente com um exemplo ilustrativo.
36
Figura 9 – Exemplo de um MER- Modelo Entidade-Relacionamento
Relacionamento
Fonte: http://itsolutionsproject.wordpress.com/banco-de-dados
http://itsolutionsproject.wordpress.com/banco dados-i/
4.2. Componentes de um Diagrama de Classes

Classe
Segundo Fowler
owler (2000, p. 57) “um diagrama de classes descreve os tipos de objetos
no sistema e os vários tipos de relacionamentos estáticos que existem entre eles”.
eles As
classes representam as propriedades e o comportamento de um conjunto
con de objetos em
um sistema. Como
omo essas classes não existem
existem sozinhas, é importante também representar
os seus relacionamentos.
4.2.1. Classes
As classes, no diagrama de classes, são representadas por um retângulo com,
normalmente, três divisões, a saber: o nome da classe, os atributos e as operações;
operações esses
dois últimos, com os seus tipos e respectivos escopos.
37
É importante que o nome da classe seja uma palavra única, preferencialmente, sem
caracteres especiais e acentuados, isso evitará problemas na geração do código fonte do
diagrama.
Em uma classe, os atributos representam as propriedades da classe e as
operações, representam os métodos desta classe.
4.2.2. Relacionamentos
• Associação
As associações representam as relações entre as ocorrências das classes. É um

tipo de relacionamento estrutural e estático entre as classes. As associações, em um
diagrama de classe, definem os tipos de ligações em que os objetos participam. Booch
(2005) usa o termo “associação binária” para se referir a uma associação entre duas
classes.
• Agregação
Descreve uma relação de dependência entre duas classes, é a descrição de um

relacionamento todo-parte ou “parte de”, também conhecido como um relacionamento do
tipo “tem-um”. É um caso particular de associação. Esse tipo de relacionamento traz os
conceitos de responsabilidades entre classes.
38
A agregação é um tipo de relacionamento que não força a destruição do conjunto,
ou seja, uma vez destruído o “objeto todo”, não há obrigatoriedade da destruição do
“objeto parte”, assim, na figura, mesmo se uma equipe “X” acabar, o jogador poderá fazer
parte de outra equipe.
• Composição
A composição também é a descrição de um relacionamento todo-parte ou “parte

de”, é conhecido como “tem-um”, mas neste caso o “objeto parte” pertence somente a um
“objeto todo”, ou seja, esse é um tipo de relacionamento mais forte entre duas classes ou
entidades. Esse tipo de relacionamento traz, assim como a Agregação, os conceitos de
responsabilidades entre as classes, porém de forma mais acentuada.
Segundo Sommerville (2007, p. 123), “nas agregações/composições, as partes são

normalmente criadas e destruídas pelo todo. Na classe do objeto todo, são definidas as
operações para adicionar e remover as partes”.
• Multiplicidade
Multiplicidade é a indicação de quantos objetos podem participar de um

relacionamento.
39
• Nome do Papel
É uma descrição (rótulo explicativo) inserida na ponta de uma associação.
• Generalização
A generalização é um relacionamento em que temos uma classe ancestral

(supertipo) e outras classes herdadas (subtipos). O subtipo deve incluir todos os
elementos (atributos e operações) do supertipo. Na implementação física corresponde a
um processo de herança.
Esse tipo de generalização pode ser restringido de várias maneiras. Segundo

Sommerville (2007), as restrições podem ser:
sobrepostas, para representar herança múltipla;
disjuntas, para subclasses que só poderão herdar de uma única classe;
completas, quando todas as classes herdadas possíveis foram definidas;
incompletas, quando nem todas as subclasses foram definidas.
40
4.2.3. Estereótipo
Segundo Booch (2005, p. 455) estereótipo trata-se de “uma extensão do vocabulário
da UML, que permite a criação de novos tipos de blocos de construção derivados dos já
existentes, mas que são específicos ao seu problema”. Os estereótipos são representados
por aspas francesas <<nome do estereótipo>>. São normalmente predefinidos na própria
linguagem UML mas, por outro lado, a equipe de desenvolvimento pode definir os seus
próprios estereótipos, assim esclarece Sommerville (2007). A UML também permite que o
usuário defina os estereótipos a serem utilizados em determinada situação de modelagem.
Dessa forma, podemos ter estereótipos de dois tipos: predefinidos ou definidos pela equipe
de desenvolvimento.
4.2.4. Interface
A interface define apenas a
assinatura dos métodos da classe sem
apresentar sua implementação.
Normalmente, nas linguagens de
programação orientadas a objetos, as
interfaces não apresentam atributos.
A interface implementa a
programação por contrato. A figura ao
lado apresenta duas representações de
interface e o seu relacionamento com
uma classe. No segundo exemplo note o
uso do estereótipo para evidenciar a
interface.
4.2.5. Classes de Associação

O conceito de Classe de Associação permite acrescentar atributos, operações e
outras características às associações. Esse tipo de associação traz a ideia de associação
enésima. Nesse sentido, Booch (2005) lembra que a “associação enésima” se refere a
uma associação entre três ou mais classes.
41
Na figura abaixo, observe que, se um fornecedor pode oferecer mais de um produto
e um produto pode ser oferecido por mais de um fornecedor, temos um relacionamento N
para N. Caso o cliente deseje verificar a data e o valor total de um fornecimento, isso
poderá ser resolvido facilmente por uma classe associativa de nome Fornecimento.
4.2.6. Enumeração
Enumeração é um recurso usado em várias linguagens de programação. São listas
(literais) que podem ser armazenadas como valores ou passadas como parâmetros. Para
representá-las usa-se o estereótipo <<enumerated>> ou <<enumeration>>.
4.2.7. Associação Reflexiva

A Associação Reflexiva é também conhecida como auto-associação. Sua função é
associar objetos de uma mesma classe. As associações reflexivas trazem o conceito de
“papéis assumidos por”. No exemplo ilustrativo a seguir vemos uma associação reflexiva
na classe Funcionário. Isso não significa dizer que o funcionário gerencia a si mesmo, mas
que, em um determinado momento, um determinado objeto dessa classe assume o papel
de Gerenciador (gerente) e em outro momento, outro objeto desta mesma classe, assume
o papel de gerenciado (o vendedor, por exemplo).
42
Guedes (2008) denomina as associações reflexivas como associações unárias.
Segundo esse autor, ocorre uma associação unária ou reflexiva quando “existe um
relacionamento de uma classe para consigo mesma”.
A descrição do nome da associação reflexiva no diagrama de classe é importante,
pois esclarece dúvidas sobre aquele tipo de associação, uma vez que apenas uma classe
é envolvida. Melo (2002, p. 102) afirma que “....o nome da associação é mais usado
quando pode haver dúvidas sobre o tipo de associação ou nas associações que envolvem
uma única classe”.
Nessa mesma linha de raciocínio, Sommerville (2007) relata que, para melhor
esclarecer o significado das associações no diagrama de classes, a UML fornece, além do
nome da associação, o direcionamento de leitura e o papel.
4.2.8. Escopo de Classe (visibilidade)

As propriedades, o comportamento das classes e a própria classe são definidos por
identificadores específicos para cada situação. São eles:
“+” ou público: especifica acesso dentro da classe, por elementos externos, e
em classes descendentes;
“#” ou protegido: especifica acesso dentro da classe e por classes
descendentes;
“-“ ou privado: especifica acesso somente dentro da classe que foi criada;
“~” ou pacote: especifica acesso dentro do pacote.
43
4.2.9. Classe Abstrata
É uma classe que não possui uma instância imediata. A classe abstrata fornece os
elementos para que classes descendentes possam instanciar seus próprios objetos, cada
um com suas particularidades. No Diagrama de Classes a classe abstrata é definida pelo
estereótipo <<abstract>>.
4.3. Construindo um Diagrama de Classes

Agora vamos construir um Diagrama de Classe completo, usando as informações
que aprendemos nas seções anteriores. No sistema Casa Segura, quando o proprietário
deseja selecionar uma câmera ele deve selecioná-la a partir da parede, segmento de
parede, porta ou janela em que a mesma está instalada. Para esta seleção, o proprietário
deve usar a planta baixa da casa, logo esta PlantaBaixa poderá ser modelada como
uma classe que é composta por outra classe chamada Parede, que, por conseguinte
possui associações binárias com as classes SegmentoDeParede, Porta e Janela. As
câmeras também serão modeladas por classes que deverão estar associadas à classe
PlantaBaixa. A figura 10 mostra uma proposta de solução de Diagrama de Classes para
o sistema Casa Segura.
.
Figura 10 - Diagrama de Classes para o Sistema Casa Segura
44
4.4. Estereótipos da Classe
Para dar prosseguimento à documentação de um sistema, iniciada com os casos de
uso, muitas vezes, em um projeto, existe a necessidade de representar elementos em um
diagrama de classe que descrevam os mais variados tipos de participações. Uma classe e
seus objetos normalmente participam de formas diferentes no transcorrer de um caso de
uso. Ao representar uma classe, é importante definir que tipo de estereótipo se pode usar
para qualificar esta participação. De acordo com o tutorial RUP (2001), os estereótipos de
classe podem ser definidos como:
Classes de Fronteira
Classes de Controle
Classes de Entidade
As classes de fronteira modelam as partes do sistema que dependem do ambiente.
As classes de controle e de entidade modelam as partes que são independentes de fatores
externos ao sistema.
Além de fornecer orientações mais específicas do processo para se identificar
classes, a criação de estereótipos é um modelo de objetos muito importante, pois permite
que mudanças no modelo afetem somente uma área específica. Com esta modelagem, as
mudanças na interface do usuário, por exemplo, irão afetar somente as classes de
fronteira. As mudanças no fluxo de controle irão afetar somente as classes de controle. As
mudanças em informações de longo prazo irão afetar somente as classes de entidade.
Esses estereótipos são especialmente úteis para identificar classes em análise no
projeto inicial. É muito provável que, em fases posteriores do projeto, seja necessário
utilizar um conjunto de estereótipos ligeiramente diferente para fazer uma correlação
melhor com o ambiente de implementação, com o tipo de aplicativo, e assim por diante.
No que se segue, estas três categorias de classes serão melhor explicadas e dicas
serão fornecidas para que você consiga identificá-las e modelar o seu sistema, caro aluno.
4.4. 1. Classes de Fronteira

A classe de fronteira é uma classe usada para modelar a interação entre o
ambiente do sistema e seus trabalhos internos. Essa interação envolve
transformar e converter eventos, bem como observar mudanças na apresentação do
sistema (como a interface).
45
Portanto, alterar a GUI – Graphic User Interface (Interface Gráfica com o Usuário)
ou o protocolo de comunicação significa alterar somente as classes de fronteira, e não as
classes de entidade e de controle.
As classes de fronteira também facilitam a compreensão do sistema, pois definem
suas fronteiras. Elas ajudam no projeto, fornecendo um bom ponto de partida para
identificar serviços relacionados. Por exemplo, se você identificar uma interface de
impressora logo no início do projeto, perceberá de imediato que também deve modelar a
formatação das impressões.
Algumas classes de fronteira comuns são janelas, protocolos de comunicação,
interfaces de impressora, sensores e terminais. Se você estiver usando um construtor GUI,
não será necessário modelar partes da interface de rotinas (botões, por exemplo) como
classes de fronteira separadas. Geralmente, a janela inteira é o objeto de fronteira mais
refinado. As classes de fronteira também são úteis para capturar interfaces para APIs –
Application Program Interface (Interface de Programas de Aplicação) possivelmente não
orientadas a objetos (como um código mais antigo, por exemplo).
Você deve modelar as classes de fronteira de acordo com o tipo de fronteira que
elas representam. A comunicação com outro sistema e a comunicação com um ator
humano (através de uma interface do usuário) têm objetivos diferentes. Durante a
modelagem da interface do usuário, a principal preocupação deve ser a forma como a
interface será apresentada a ele. Durante a modelagem da comunicação do sistema, a
principal preocupação deve ser o protocolo de comunicação.
Um objeto de fronteira (uma instância de uma classe de fronteira) poderá durar mais
que uma instância de caso de uso se, por exemplo, precisar ser exibido em uma tela entre
o desempenho de dois casos de uso. Os objetos de fronteira, porém, costumam ter a
mesma duração da instância de caso de uso.
• Identificação de Classes de Fronteira
Uma classe de fronteira faz a intermediação entre a interface e algo fora do sistema.
Os objetos de fronteira isolam o sistema de mudanças externas (mudanças nas interfaces
com outros sistemas, nos requisitos do usuário, etc.), impedindo que elas afetem o
restante do sistema.
Um sistema pode ter vários tipos de classes de fronteira:
46
Classes de interface do usuário - classes que intermediam a comunicação
com usuários humanos do sistema, como um painel de controle que recebe a
interação do usuário.
Classes de interface do sistema - classes que intermediam a comunicação
com outro sistema, como uma biblioteca que permite a troca de informações com
a internet.
Classes de interface de dispositivo - classes que fornecem a interface para
dispositivos (como sensores) que detectam eventos externos.
• Identificação de Classes de Interface do Usuário

Podem existir classes de fronteira que representem a interface do usuário a
partir de atividades de modelagem dessa interface. Quando apropriado, reutilize essas
classes nessa atividade. Caso a modelagem de interface de usuário não tenha sido
feita, a discussão a seguir ajudará a localizar (ou identificar) essas classes.
Existe pelo menos um objeto de fronteira para cada par de atores de caso de
uso. Esse objeto pode ser visto como tendo a responsabilidade de coordenar a
interação com o ator.
Ele também pode ter objetos secundários, aos quais delega algumas de suas
responsabilidades. Isso é verdadeiro para aplicativos GUI baseados em janela, nos
quais geralmente existe um objeto de fronteira para cada janela ou para cada
formulário.
• Identificação de Classes de Interface do Sistema

Uma classe de fronteira que se comunica com um sistema externo e é
responsável pelo gerenciamento do diálogo com esse sistema é chamada de classe de
interface do sistema. Ela fornece a interface entre o sistema externo e o sistema que
está sendo criado.
A interface com um sistema existente pode já estar bem definida. Se estiver, as
responsabilidades serão derivadas diretamente da definição da interface. Se existir uma
definição formal de interface, ela pode ser obtida por meio de engenharia reversa e isso
precisa estar formalmente definido aqui. Simplesmente anote o fato de que a interface
existente será reutilizada durante o projeto.
47
Saiba Mais sobre Engenharia Reversa lendo o artigo “O que é
Engenharia Reversa” de Oliver Hautsch publicado em 28/09/2009
Disponível em:
http://www.tecmundo.com.br/pirataria/2808-o-que-e-engenharia-
reversa-.htm
• Identificação de Classes de Interface de Dispositivo

O sistema pode conter elementos que agem como se fossem externos, ou seja,
podem ter seus valores alterados espontaneamente, sem que algum objeto do sistema
os tenha afetado, como por exemplo, um equipamento sensor. Embora seja possível
representar esse tipo de dispositivo externo usando atores, os usuários do sistema
podem ficar confusos, já que o processo tende a colocar dispositivos e atores humanos
no mesmo nível. Após a conclusão da coleta de requisitos, no entanto, precisamos
considerar a origem de todos os eventos externos e verificar se dispomos de meios
para fazer com que o sistema detecte esses eventos.
Se o dispositivo estiver representado como um ator no modelo de casos de uso,
será fácil justificar a utilização de uma classe de fronteira para intermediar a
comunicação entre o dispositivo e o sistema. Se o modelo de casos de uso não incluir
esses "atores-dispositivo", este será o momento adequado para adicioná-los,
atualizando a documentação dos Casos de Uso (mencionada no capítulo 3), quando
apropriado.
Para cada "ator-dispositivo", deve ser criada uma classe de fronteira para
capturar as responsabilidades do dispositivo ou do sensor. Se já existir uma interface
bem definida para o dispositivo, uma anotação deve ser feita para que possa ser
referenciada posteriormente durante o projeto.
4.4.2. Classes de Controle

Uma classe de controle é usada para modelar um comportamento de
controle específico de um ou alguns casos de uso. O comportamento de um
objeto de controle está estreitamente relacionado à realização de um caso de
uso específico. Em alguns cenários, é possível dizer que os objetos de controle "executam"
48
as realizações de casos de uso. Entretanto, se as tarefas de caso de uso estiverem
intrinsecamente relacionadas, alguns objetos de controle poderão participar de mais de
uma realização de casos de uso. Além disso, vários objetos de controle de diferentes
classes de controle podem participar de um único caso de uso. Nem todos os casos de uso
exigem um objeto de controle. Por exemplo, se o fluxo de eventos em um caso de uso
estiver relacionado a um objeto de entidade, um objeto de fronteira poderá realizar o caso
de uso em cooperação com o objeto de entidade. Deve-se começar identificando uma
classe de controle para cada realização de casos de uso e, em seguida, refiná-la, à medida
que se identificam mais realizações de casos de uso e o respectivo compartilhamento de
características comuns.
As classes de controle podem ajudar a entender o sistema, pois representam a
dinâmica do sistema, controlando as principais tarefas e os fluxos de controle. Quando o
sistema executar o caso de uso, um objeto de controle será criado. Os objetos de controle
geralmente desaparecem após a execução do correspondente caso de uso. Observe que
uma classe de controle não controla tudo o que é necessário em um caso de uso. Em vez
disso, ela coordena as atividades de outros objetos que implementam a funcionalidade. A
classe de controle delega trabalho aos objetos aos quais foi atribuída a responsabilidade
pela funcionalidade.
• Identificação de Classes de Controle
As classes de controle modelam o comportamento de coordenação no sistema. O

sistema pode executar alguns casos de uso sem objetos de controle (simplesmente
usando objetos de fronteira e de entidade), principalmente os casos de uso que envolvem
somente a simples manipulação de informações armazenadas. Mas, em geral, casos de
uso mais complexos exigem uma ou mais classes de controle para coordenar o
comportamento de outros objetos no sistema.
As classes de fronteira serão responsáveis por coordenar um caso de uso.
Exemplos de objetos de controle incluem programas como gerenciadores de transações,
coordenadores de recursos e identificadores de erros.
As classes de controle realmente dissociam objetos de fronteira de objetos de
entidade (e vice-versa), tornando o sistema mais tolerante a mudanças em sua fronteira.
Elas também dissociam o comportamento específico de casos de uso dos objetos de
entidade, tornando-os mais reutilizáveis.
49
As classes de controle fornecem um comportamento que:
Independe de fatores externos (o comportamento não se altera quando o
ambiente é alterado)
Define a lógica de controle (ordem entre os eventos) e as transações em um
caso de uso
É pouco alterado se a estrutura interna ou o comportamento das classes de
entidade se altera
Usa ou define o conteúdo de várias classes de entidade e, portanto, precisa
coordenar o comportamento dessas classes
Não é executado da mesma maneira toda vez que é ativado (o fluxo de eventos
apresenta vários estados).
Para se determinar se uma Classe de Controle é necessária, deve-se investigar se o

fluxo pode ser gerenciado pelas classes de fronteira e de entidade já identificadas. O fluxo
de eventos de um caso de uso define a ordem em que diferentes tarefas são executadas.
Para fluxos de eventos simples, que basicamente inserem, recuperam e exibem ou
modificam informações, normalmente não justifica ter uma classe de controle separada.
Os fluxos de eventos devem ser encapsulados em uma classe de controle separada
quando forem complexos e tiverem um comportamento dinâmico que possa ser alterado
sem levar em consideração as interfaces (classes de fronteira) ou armazenamentos de
informações (classes de entidade) do sistema. Por meio do encapsulamento dos fluxos de
eventos, a mesma classe de controle pode ser reutilizada para vários sistemas, que podem
ter diferentes interfaces e armazenamentos de informações (ou, pelo menos, as estruturas
básicas de dados).
4.4.3. Classes de Entidade

A classe de entidade é usada para modelar as informações e o seu
comportamento associado que devem ser armazenados no sistema. Os objetos
de entidade (instâncias de classes de entidade) são usados para manter e atualizar
informações sobre alguns fenômenos, como um evento, uma pessoa ou algum objeto real.
Esses objetos geralmente são persistentes, precisando de atributos e relacionamentos que
durem muito tempo, algumas vezes durante todo o ciclo de vida do sistema.
50
Um objeto de entidade geralmente não é específico para uma realização de casos
de uso. Às vezes, um objeto de entidade não é nem mesmo específico para o próprio
sistema.
Os objetos de entidade representam os conceitos-chave do sistema que está sendo
desenvolvido. Os valores de seus atributos e relacionamentos costumam ser fornecidos
por um ator. Um objeto de entidade também pode ajudar a executar tarefas internas do
sistema. Seu comportamento pode ser tão complicado quanto o de outros estereótipos de
objeto. No entanto, ao contrário de outros objetos, esse comportamento está
intrinsecamente relacionado ao fenômeno que o objeto de entidade representa. Os objetos
de entidade independem do ambiente, ou seja, independem dos atores.
Exemplos típicos de classes de entidade em um sistema bancário são Conta e
Cliente; em um sistema de gerenciamento de redes, são Nó e Link.
Se o fenômeno que se deseja modelar não for usado por outras classes, será
possível modelá-lo como um atributo de uma classe de entidade ou mesmo como um
relacionamento entre classes de entidade. Por outro lado, se o fenômeno for usado por
qualquer outra classe do modelo de projeto, será preciso modelá-lo como uma classe.
As classes de entidade fornecem um outro ponto de vista do sistema, pois mostram
a estrutura lógica dos dados, que pode ajudar a compreender o que o sistema deve
oferecer aos usuários.
• Identificação de Classes de Entidade
As classes de entidade representam os armazenamentos de informações no

sistema e geralmente são usadas para representar os conceitos-chave que o sistema
gerencia. Os objetos de entidade costumam ser passivos e persistentes. Suas principais
responsabilidades são armazenar e gerenciar informações no sistema.
51
1) Desenhe um diagrama de classes com relacionamentos, nomes de papéis e

multiplicidades para as seguintes situações:
• Uma Pessoa pode ser casada com outra Pessoa;
• Uma Disciplina é pré-requisito para outra Disciplina;
• Uma Peça pode ser composta de diversas outras Peças.
2) Considere o seguinte discurso relativo a um sistema de partidas de tênis: "Num

torneio de tênis, cada partida é jogada entre 2 jogadores. Pretende-se manter
informação sobre o nome e idade dos jogadores; data da partida e atribuição dos
jogadores às partidas. O máximo de partidas que um jogador poderá realizar é 6 e o
mínimo 1.” Desenhe o diagrama de classes correspondente a esta situação.
3) A seguir, são enumeradas diversas responsabilidades típicas de serem

encontradas em objetos de um sistema de software. Discuta qual das categorias de
objetos (fronteira, controle ou entidade) é mais adequada para cumprir com cada uma
dessas responsabilidades:
a) Criação ou destruição de um objeto.

b) Formação ou destruição de associações entre objetos de entidade.
c) Obtenção ou modificação de valores de atributos de um objeto de entidade.
d) Exibição de mensagens para o ator.
e) Realização de cálculos complexos.
52
Capítulo 5
Diagramas de Interação
Caro aluno, neste capítulo descreveremos os diagramas de interação que têm
por função representar a interação de objetos, servindo como especificações
comportamentais
omportamentais que incluem sequências
sequ de troca de mensagens
gens entre objetos dentro
de um contexto a fim de realizar um determinado propósito.
5.1. Os Diagramas de Interação

Os Diagramas de Interação são modelos que descrevem como grupos de objetos
colaboram em algum comportamento. Tipicamente, um diagrama de interação captura o
comportamento de um único
nico caso de uso. Estes diagramas mostram
m vários objetos e as
mensagens que são passadas entre estes objetos em um caso de uso.
São utilizados para fazer a modelagem dos aspectos dinâmicos do sistema e podem
aparecer sozinhos para que se possa visualizar, especificar, construir e documentar a
dinâmica
nâmica de um determinado grupo de objetos que interagem. Também podem ser
utilizados
lizados para fazer a modelagem de um determinado fluxo de controle de um caso de
uso.
Existem dois tipos de diagramas de
interação: diagramas de sequência e
diagramas de comunicação
ação. Um diagrama
de comunicação inclui relacionamentos de
objetos, enquanto um diagrama de sequência
inclui fluxos. Ambos expressam informações
idênticas;; o que muda é a forma como elas
são mostradas. Os diagramas de sequência mostram a sequência explícita de mensagens
e são melhores quando é importante visualizar a ordenação temporal das mensagens.
Mas, quando houver necessidade de se apresentar os relacionamentos
relacionamentos estruturais entre as
instâncias de uma interação, deve ser utilizado um diagrama de comunicação.
comunicação
Estes diagramas serão detalhados no que se segue.
53
5.2. Diagrama de Sequência
Na maioria dos casos, usamos um diagrama de sequência para ilustrar as
realizações de casos de uso, isto é, para mostrar como os objetos interagem para executar
o comportamento total ou parcial de um caso de uso. Um ou mais diagramas de sequência
podem ilustrar as interações de objetos que constituem um caso de uso. Uma modelagem
típica deve apresentar um diagrama de sequência para o fluxo principal de eventos e um
diagrama de sequência para cada subfluxo independente do caso de uso.
Os diagramas de sequência são muito importantes porque eles esclarecem os
papéis dos objetos em um fluxo e, portanto, fornecem a entrada básica para se determinar
responsabilidades de classe e interfaces.Podemos ter objetos e instâncias de ator em
diagramas de sequência, juntamente com mensagens que descrevem como eles
interagem. O diagrama descreve o que ocorre nos objetos participantes, em termos de
ativações, e como os objetos se comunicam enviando mensagens uns aos outros. É
possível fazer um diagrama de sequência para cada variante do fluxo de eventos de um
caso de uso.
A figura 11 apresenta, como exemplo, um diagrama de sequência que descreve
parte do fluxo de eventos do caso de uso “Criar Nota” em um Blog. Neste exemplo
podemos ver um objeto da classe de interface GUIBlog, recebendo a interação do
usuário, o objeto da classe de controle ControladorBlog, centralizando as chamadas da
interface e por fim os objetos das classes de entidade Blog e Nota, onde as ações
propriamente ditas são executadas.
Figura 11 – Exemplo de um diagrama de sequência para criar uma nota em um blog

Fonte: http://wiki.les.inf.puc-rio.br/uploads/e/ef/Aula02-diagrama_sequencia.pdf
54
5.3. Componentes de um Diagrama de Sequência
O diagrama de Sequência é representado por:
Objetos
Atores
Mensagens
Estes componentes serão apresentados em seguida.
5.3.1. Objetos
Um objeto é mostrado como uma linha tracejada vertical denominada "linha de
vida". A linha de vida representa a existência do objeto em um momento específico. No
diagrama de sequência, um símbolo de objeto é desenhado no alto da linha de vida e
mostra o nome do objeto e sua classe sublinhada, separada por “:”, como em
Nome_do_Objeto: Nome_da_Classe. Na figura 11, são exemplo de objetos GUIBlog,
ControladorBlog, Blog e Nota.
Podemos usar objetos em diagramas de sequência das seguintes formas:
Uma linha de vida pode representar um objeto ou sua classe. Portanto, a linha
de vida pode ser usada para modelar tanto o comportamento da classe quanto
do objeto. Contudo, em geral, uma linha de vida representa todos os objetos de
uma determinada classe.
Uma classe de objeto pode não estar especificada. Geralmente, primeiro é
criado um diagrama de sequência com objetos e mais tarde especifica as suas
classes.
Os objetos podem não ter nome, mas é recomendável nomeá-los caso se queira
diferenciar os diversos objetos da mesma classe.
Várias linhas de vida no mesmo diagrama podem representar objetos diferentes
da mesma classe; mas, como foi dito anteriormente, os objetos devem ser
nomeados para que se possa estabelecer a diferença entre os dois objetos.
Uma linha de vida que representa uma classe pode existir paralelamente a linhas
de vida que representam objetos daquela classe. O nome do objeto da linha de
vida que representa a classe pode ser definido com o nome da classe.
55
5.3.2. Atores
Geralmente, uma instância de ator é representada pela primeira (mais à esquerda)
linha de vida no diagrama de sequência, como o disparador da interação. Se houver várias
instâncias de atores no mesmo diagrama, é costume mantê-las na linha de vida mais à
esquerda ou na linha mais à direita. Na figura 11, o UsuarioBlog é um exemplo de ator.
5.3.3. Mensagens
Uma mensagem é uma comunicação entre objetos que leva informações na
expectativa de que seja produzida uma atividade. Nos diagramas de sequência, uma
mensagem é mostrada como uma seta sólida horizontal partindo da linha de vida de um
objeto para a linha de vida de outro objeto. No caso de uma mensagem de um objeto para
si mesmo, a seta pode iniciar e terminar na mesma linha de vida. A seta é rotulada com o
nome da mensagem e seus parâmetros. Ela também pode ser rotulada com um número
que indique a sequência da mensagem no processo geral de interação. Mas os números
sequenciais são omitidos em diagramas nos quais a localização física da seta já mostra a
sequência relativa.
Uma mensagem pode ser não-atribuída, o que significa que seu nome é uma
sequência de caracteres temporária que descreve o sentido geral da mensagem e não é o
nome de uma operação do objeto recebedor. Neste caso, mais tarde, pode-se especificar a
operação do objeto de destino da mensagem. A operação especificada substituirá, então, o
nome da mensagem.
Na figura 11, CriarNota() e ConsultarBlog() são alguns dos exemplos de
mensagens.
5.4. Distribuição de Fluxo de Controle em Diagramas de

Sequência
O fluxo de controle pode ser centralizado e descentralizado. Quando há um

controle centralizado de um fluxo de eventos ou de parte do fluxo de eventos, significa que
poucos objetos guiam o fluxo trocando mensagens com outros objetos. Esses objetos
controladores decidem a ordem em que outros objetos serão ativados no caso de uso. A
interação entre os objetos restantes é mínima ou inexistente.
56
Uma estrutura de controle é centralizada principalmente quando as diferentes fases
de sub eventos do fluxo de eventos não dependem umas das outras. A principal vantagem
desse método é que cada objeto não precisa controlar a contagem do objeto seguinte.
Para mudar a ordem das fases de sub eventos, basta fazer a mudança no objeto de
controle. Ainda é possível adicionar outra fase de sub evento se, por exemplo, for incluído
um novo tipo de item retornável. Outra vantagem dessa estrutura é que podemos reutilizar
as várias fases de sub eventos em outros casos de uso, porque a ordem de
comportamento não está embutida nos objetos.
Vamos exemplificar um caso centralizado na seguinte situação:
No Sistema da Máquina de Reciclagem, o caso de uso Imprimir Relatório
Diário controla, entre outros, o número e o tipo de objetos retornados, e escreve a
contagem em um recibo. O objeto de controle Gerador de Relatório decide a ordem
em que os totais serão extraídos e escritos.
Esta situação é mostrada na figura abaixo.
Fonte:http://www.wthreex.com/rup/process/modguide/images/ds.gif
57
O controle descentralizado surge quando os objetos participantes se comunicam
diretamente entre si, e não através de um ou mais objetos controladores.
Vamos exemplificar um caso centralizado na seguinte situação:
No caso de uso Enviar Carta, ilustrado na figura abaixo, alguém remete uma
carta para outro país através de uma agência de correio. Primeiro, a carta é enviada para o
país do destinatário. Neste país, a carta é enviada para uma cidade específica. A cidade, por
sua vez, envia a carta para a residência do destinatário. A estrutura de comportamento
deste caso de uso é descentralizada porque o comportamento do caso de uso reflete um
fluxo de eventos descentralizado. Neste exemplo, as fases de sub eventos integram o
conjunto. O remetente da carta fala em "enviar uma carta a alguém", mas não precisa nem
deseja saber os detalhes de como as cartas são enviadas em países ou cidades.
Provavelmente, se alguém remetesse uma carta de dentro do mesmo país, nem todas as
ações ocorreriam.
Fonte: http://www.wthreex.com/rup/process/modguide/images/md_seqd4.gif
O tipo de controle usado num sistema depende de sua aplicação. Geralmente

tentamos conseguir objetos independentes, isto é, buscamos delegar várias tarefas aos
objetos naturalmente mais apropriados a executá-las.
58
Um fluxo de eventos com controle centralizado terá um diagrama de sequência "em
forma de forquilha". Por outro lado, um diagrama de sequência "em forma de escada"
ilustra que a estrutura de controle foi descentralizada para os objetos participantes. A figura
12 ilustra estes dois casos.
Figura 12 – Fluxos de controle centralizado e descentralizado

Fonte: http://www.wthreex.com/rup/process/modguide/images/md_seqd5.gif
A estrutura de comportamento da realização de um caso de uso frequentemente

consiste em uma mistura de comportamento centralizado e descentralizado.
Uma estrutura descentralizada será adequada:
Se as fases de subeventos estiverem intrinsecamente acopladas, como no caso
de os objetos participantes:
o Formarem uma hierarquia de partes ou constituintes, como País - Estado -
Cidade;
o Formarem uma hierarquia de informações, como CEO - Gerente de
Divisão - Gerente de Seção;
59
o Representarem uma progressão cronológica fixa (a sequência de fases de
subeventos será sempre realizada na mesma ordem), como Anúncio -
Pedido - Fatura -Remessa - Pagamento; ou
o Formarem uma hierarquia de herança conceitual, como Animal - Mamífero
- Gato.
Se deseja-se encapsular a funcionalidade e, portanto, fazer abstrações dela. Isso
é bom para alguém que deseje utilizar sempre a funcionalidade inteira, porque a
funcionalidade pode se tornar desnecessariamente de difícil compreensão caso
a estrutura de comportamento seja centralizada.
Uma estrutura centralizada será adequada:

Se a ordem em que as fases de subeventos serão executadas puder ser
mudada.
Se espera-se inserir novas fases de subeventos.
Se deseja-se manter partes da funcionalidade reutilizáveis como peças
separadas.
5.5. Diagramas de Comunicação

Os diagramas de comunicação são usados para mostrar como os objetos interagem
para executar o comportamento de um caso de uso ou de parte de um caso de uso. Junto
com os diagramas de sequência, as colaborações são usadas para definir e esclarecer os
papéis dos objetos que executam determinado fluxo de eventos de um caso de uso. Eles
são a principal fonte de informações usada para determinar interfaces e responsabilidades
de classe.
Ao contrário de um diagrama de sequência, o diagrama de comunicação mostra os
relacionamentos entre os objetos e proporciona uma melhor compreensão dos efeitos
causados em determinado objeto. Devido ao seu formato, os diagramas de comunicação
tendem a ser mais adequados às atividades de análise. Ou seja, eles representam melhor
as interações mais simples de um número menor de objetos.
Podemos ter objetos e instâncias de ator em diagramas de comunicação, junto com
links e mensagens descrevendo como eles estão relacionados entre si e como interagem.
O diagrama descreve o que ocorre com os objetos participantes e, como eles se
60
comunicam entre si por intermédio
interm de mensagens. Podemos, igualmente,
igualmen criar um
diagrama de comunicação para cada variante de fluxo de eventos de um caso de uso.
Um diagrama de comunicação é normalmente utilizado como complemento do
diagrama de sequência, porém
m possui um enfoque diferente, concentrando-se
concentrando em como os
objetos estão vinculados através de mensagens. Pode ser gerado a partir do diagrama de
sequência por representarr os mesmos dados. Para exemplificar
car essa igualdade semântica
entre ambos os diagramas,, na figura 13
1 é mostrado o Diagrama de Comunicação para o
exemplo de Diagrama de Sequência
Sequê mostrado na figura 11 para o mesmo caso.
caso
Figura 13 – Exemplo
mplo de um diagrama de comunicação para criar uma nota em um
blog
Um outro exemplo de diagrama de comunicação relativo a uma cena de Depósito

para um sistema de Banco 24hs é mostrado na figura 14.. Neste exemplo existem os
objetos das classes de fronteira Painel de Controle, Impressora de Recibos,
Recibos
entre outros. O objeto da classe de controle Receptor de Depósito e os objetos da
classe de entidade Lista de Itens de Depósito e Tipo do Item de Depósito.
Depósito
61
Figura 14 – Diagrama de Comunicação para se realizar um Depósito num Banco 24horas
Fonte: http://www.wthreex.com/rup/process/modguide/images/collab1.gif
62
1) Defina um diagrama de sequência para as tarefas:
(1) inclusão de um veículo

(2) aluguel de um veículo por um cliente
a partir da descrição do negócio “Locadora de Veículos”:
Uma locadora de veículos possui vários veículos que podem ser alugados. Cada veículo
possui várias informações (placa, cor, modelo, ano, preço) e pode ser alugado para
somente um cliente de cada vez. O cliente, por sua vez, apresenta várias informações
(nome, cpf e cartão de crédito) e pode alugar somente 1 carro. O aluguel de um veículo
tem a quantidade de dias alugados, bem como o preço total. Utilize como base o
diagrama de classes conceituais resultante da análise. Considere que todos os objetos
estão na memória principal.
63
Capítulo 6
Diagrama de Máquina de Estados e
Diagrama de Atividades
Caro aluno, neste capítulo descreveremos os Diagramas de Estados e de
Atividades que representam estados ou situações em que um objeto pode se encontrar
no decorrer da execução de processos de um sistema. São diagramas que descrevem a
trajetória de um objeto a partir do seu estado inicial até o seu possível estado final,
por meio de transições.
6.1. Máquina de Estados e Atividades

Uma das tarefas mais importantes do desenvolvimento OO é a validação dos
estados pelos quais um objeto deve passar. Compreender a ordem temporal e a sequência
com que as transições de estados acontecem, permite uma validação mais eficiente e um
domínio mais abrangente da solução ao desenvolvedor. O diagrama de Máquina de
Estados procura acompanhar as mudanças sofridas nos estados de uma instância de uma
classe, de um Caso de Uso, de um subsistema ou mesmo de um sistema completo.
O Diagrama de Atividade se preocupa em descrever os passos a serem percorridos
para a conclusão de uma atividade específica, muitas vezes representada por um método
com um certo grau de complexidade, mas pode modelar um processo completo.
Concentra-se na representação do fluxo de controle e no fluxo de objetos de uma
atividade. Com a evolução da UML, o diagrama de atividades se tornou independente do
diagrama de estados, deixando de se basear em máquinas de estados e passando a se
basear em Redes de Petri.
Os Diagramas de Máquina de Estados e de Atividades são usados para modelar o
comportamento dinâmico de um elemento do Diagrama de Classes. Estes diagramas são
usados especificamente para se definir o comportamento de acordo com o estado ou
situação em que se encontra o elemento do modelo. Os elementos do modelo cujos
comportamentos não variam com o seu estado ou situação não precisam destes
diagramas (geralmente, esses elementos são classes passivas cuja responsabilidade
principal é gerenciar dados). Assim, os Diagramas de Máquinas de Estado devem ser
usados para modelar o comportamento de classes ativas que usam eventos de chamada e
64
de sinal para implementar suas operações (como as transições na máquina de estado da
classe).
O Diagrama de Atividades tem por objetivo representar
o fluxo de atividades em um único processo, mostrando
m como
uma atividade depende uma da outra. Este diagrama pode
representar um processo de negócios ou um processo de
software como um fluxo de trabalho por meio de uma série de
ações. Os componentes de software, pessoas ou computadores
res podem executar essas
ações. No diagrama de atividades podemos representar
representar as ações que são executadas e
podemos
odemos documentar os métodos que iremos escrever na instância de um objeto.
6.2. Diagrama de Máquina de Estados

Uma máquina
a de estado consiste em estados vinculados por transições. Um estado
é uma condição de um objeto em que ele realiza alguma atividade ou espera um evento.
Uma transição é um relacionamento entre dois estados que é disparado por algum evento,
que executa determinadas ações ou avaliações
aval e que resulta em um estado final
específico. Estes e outros elementos de uma máquina de estado estão representados na
figura 15 e serão
ão explicados na próxima seção.
seção
Figura 15
1 – Exemplo de Máquina de Estados
Fonte: http://www.wthreex.com/rup/process/modguide/images/md_state1.gif
65
6.3. Componentes de um Diagrama de Máquina de Estados
O diagrama de Máquina de Estados é representado por:
Estados
Transições
Condições de Guarda
Ações
Estes componentes são explicados a seguir.
6.3.1. Estados
Um estado é uma condição de um objeto em que ele realiza alguma atividade ou
espera um evento. Um objeto pode permanecer em um estado durante um tempo limitado.
Um estado tem várias propriedades, apresentadas na tabela 3. Na figura 15 podemos
identificar os estados: “Ocioso”, “Conectando” e “Conectado”.
Tabela 3 – Propriedades de um Estado

Fonte: baseado em http://www.wthreex.com/rup/process/modguide/
Nome Uma sequência de caracteres textuais que distingue o
estado de outros estados; um estado também pode ser
anônimo, ou seja, não ter nenhum nome.
Ações de entrada/saída Ações executadas ao entrar no estado ou sair dele.
Transições internas Transições que são manipuladas sem causar mudança de
estado.
Subestados Estrutura aninhada de um estado, envolvendo subestados
separados (ativos sequencialmente) ou simultâneos
(ativos concomitantemente).
Eventos adiados Lista de eventos que não são manipulados no estado, mas
são adiados e enfileirados para serem manipulados pelo
objeto em outro estado.
Existem dois estados especiais que podem ser definidos para a máquina de estado
de um objeto. O estado inicial indica o local inicial padrão para a máquina de estado ou o
subestado. Um estado inicial é representado como um círculo de preenchimento preto. O
estado final indica o término da execução da máquina de estado ou que o estado
confinado foi concluído.
66
Um estado final é representado como um círculo de preenchimento preto dentro de
um círculo sem preenchimento. Os estados final e inicial são, na verdade, pseudo-estados.
Nenhum dos dois pode ter as partes usuais de um estado normal, exceto o nome. Uma
transição de um estado inicial para um estado final pode ter o complemento completo de
características, incluindo uma condição de guarda e uma ação.
6.3.2. Transições
Uma transição é um relacionamento entre dois estados indicando que um objeto no
primeiro estado executará certas ações e entrará em um segundo estado quando ocorrer
um evento especificado e determinadas condições forem satisfeitas. Nessa mudança de
estado, diz-se que a transição foi “acionada”. Até que a transição seja acionada, diz-se
que o objeto está no estado “de origem”; após o seu acionamento, diz-se que o objeto está
no estado “de destino”. Uma transição tem várias propriedades apresentadas na tabela 4.
Tabela 4 – Propriedades de uma Transição

Fonte: baseado em http://www.wthreex.com/rup/process/modguide/
Estado de origem Estado afetado pela transição. Se um objeto estiver no
estado de origem, uma transição de saída poderá ser
acionada quando o objeto receber um evento trigger da
transição e quando a condição de guarda, se houver, for
satisfeita.
Trigger de evento Evento que torna a transição passível de ser acionada
(desde que sua condição de guarda seja cumprida)
quando recebido pelo objeto no estado de origem.
Condição de guarda Boolean expression (expressão lógica) que é avaliada
quando a transição é disparada pela recepção do
disparador de evento. Se o valor da expressão for
Verdadeiro, a transição poderá ser acionada; se for Falso,
a transição não será acionada. Se não houver outra
transição que possa ser disparada pelo mesmo evento, o
evento será perdido.
Ação Cálculo indivisível executável que pode agir diretamente
sobre o objeto que possui a máquina de estado e
indiretamente em outros objetos visíveis ao objeto.
Estado de destino Estado que é ativado após a conclusão da transição.
67
Uma transição pode ter várias origens (nesse caso, ela representa uma junção de
vários estados simultâneos) e vários alvos (nesse caso, ela representa uma forquilha para
vários estados simultâneos). Na figura 15 podemos identificar as transições “OnHook” e
“OffHook” como exemplos.
6.3.3. Condições de Guarda

Uma condição de guarda é avaliada após o evento trigger acionar a transição. É
possível que haja várias transições do mesmo estado de origem e com o mesmo trigger de
evento, desde que as condições de guarda não se sobreponham. Uma condição de guarda
é avaliada apenas uma vez para a transição no momento em que o evento ocorre. A figura
15 mostra como exemplo a condição de guarda “Signal OK” para a transição “Ready”.
6.3.4. Ações
Uma ação é um cálculo indivisível executável, ou seja, ela não pode ser
interrompida por um evento e, portanto, é executada até a sua conclusão. Isso contrasta
com uma atividade, que pode ser interrompida por outros eventos. As ações podem incluir
chamadas de operação (para o proprietário da máquina de estado, bem como para outros
objetos visíveis), a criação ou a destruição de outro objeto, ou o envio de um sinal para
outro objeto. No caso de envio de um sinal, o nome do sinal recebe como prefixo a
palavra-chave “send”. A figura 15 mostra como exemplo a ação “Keep Alive/Check()” para
o estado “Ocioso”.
6.4. Construindo um Diagrama de Máquina de Estado

Geralmente, as máquinas de estado são usadas para modelar o comportamento de
um objeto ao longo de sua vida útil. Elas são especialmente necessárias quando os
objetos têm comportamento dependente do estado. Os objetos que podem ter máquinas
de estado são classes, subsistemas, casos de uso e interfaces (para declarar estados que
devem ser satisfeitos por um objeto que realize a interface). A seguir, na figura 16,
apresentamos uma máquina de estados que construímos para a classe Camera do nosso
exemplo do Casa Segura mostrado na figura 10.
68
Figura 16 – Máquina de Estados para a classe Camera do sistema Casa Segura
6.5. Diagrama de Atividades

O Diagrama de atividade é essencialmente um gráfico de fluxo, mostrando os
fluxos de controle de uma atividade para outra. Comumente isso envolve a modelagem das
etapas sequenciais em um caso de uso em um sistema. Os diagramas de atividade não
são importantes somente para a modelagem de aspectos dinâmicos de um sistema, mas
também para a construção de sistemas executáveis por meio de engenharia de produção
reversa.
6.6. Componentes de um Diagrama de Atividades

Um diagrama de atividades pode conter os seguintes elementos:
Estados das atividades que representam o desempenho de uma atividade ou
uma etapa do fluxo de trabalho.
Transições que mostram o estado que a atividade aparece após passar por um
outro estado. Esse tipo de transição pode ser denominada transição de
conclusão. Ela difere de uma transição que não requer um evento explícito; é
disparada pela conclusão da atividade que o estado da atividade representa.
Decisões para as quais um conjunto de condições de guarda é definido. As
condições de guarda controlam qual transição, de um conjunto de transições
69
alternativas, ocorre após a conclusão da atividade. O ícone de decisão pode ser
usado para mostrar onde os threads são mesclados novamente. As decisões e
as condições de guarda permitem mostrar threads alternativos no fluxo de
trabalho de um caso de uso de negócios.
Barras de sincronização são usadas para mostrar subfluxos paralelos. As
barras de sincronização permitem mostrar threads simultâneos no fluxo de
trabalho de um caso de uso de negócios.
A figura 17 mostra um exemplo de diagrama de atividade. Este exemplo tem como

cenário um caso de uso “Check-In no Aeroporto” e os principais componentes do diagrama
são destacados e identificados.
Figura 17 – Exemplo de um Diagrama de Atividades

Fonte: http://www.wthreex.com/rup/process/modguide/images/md_bact.gif
70
No diagrama de atividades da figura 17, podemos identificar a atividade “Verificar
reserva” com uma atividade inicial sendo seguida da Decisão [correto] ou [incorreto], que
expressa qual foi o resultado da primeira atividade. Antes da atividade final “Entregar
documentação de viagem para o passageiro” existe uma barra de sincronização, que é
usada para deixar claro que todas as atividades anteriores devem ser encerradas antes do
início desta última.
Um diagrama de atividades pode ser particionado em raias usando linhas sólidas
verticais. Cada raia representa uma responsabilidade por uma parte do fluxo de trabalho,
contido em uma parte da organização. Eventualmente, uma raia pode ser implementada
por uma unidade organizacional ou por um conjunto de classes no modelo de objetos de
negócios. A ordem relativa de raias não tem significado semântico. Cada estado de
atividade é atribuído a uma raia, e as transições podem ser pistas cruzadas. A figura 18
ilustra o uso de raias.
Figura 18- Exemplo do uso de raias

Fonte: http://www.wthreex.com/rup/process/modguide/images/md_bact2.gif
O diagrama de atividades da figura 18 ilustra o fluxo de trabalho de um caso de uso

que representa um processo de vendas geral; nele as raias representam departamentos na
organização.
71
6.7. Construindo um Diagrama de Atividades
Agora, na figura 19, mostraremos uma proposta de solução de um diagrama de
atividades para o caso de uso “Autorizar Proprietário”, que foi mostrado na figura 10,
relativo ao sistema Casa Segura. Deve-se observar que o diagrama de atividades pode
acrescentar detalhes não diretamente mencionados, mas implícitos, no caso de uso. Por
exemplo, um usuário pode somente tentar introduzir o Username e Senha, um número
limitado de vezes. Isso é representado pelo losango de decisão abaixo de “Aviso de
Reentrada”.
Figura 19- Diagrama de Atividades para o Caso de Uso Autorizar Usuário
72
6.8. Diagramas de Atividades Aninhados
Um estado de atividade pode fazer referência a outro diagrama de atividades que
mostre a estrutura interna do estado de atividade.
atividade Neste caso podemos ter diagramas de
atividades aninhados. É possível mostrar o subgráfico dentro do estado de atividade ou
permitir que o estado de atividade faça referência a outro diagrama. A figura 20 ilustra esta
situação.
Figura 20- Um gráfico de atividades aninhado mostrado dentro de um estado de atividade

Mostrar
ostrar o subgráfico dentro de um estado de atividade é conveniente quando se
deseja ver todos os detalhes do fluxo de trabalho em um diagrama de atividades. No
entanto, se houver qualquer nível de complexidade no fluxo de trabalho apresentado, isso
pode dificultar a leitura do diagrama. Para simplificar o gráfico do fluxo de trabalho, é
possível inserir o subgráfico em um diagrama separado e permitir que o estado de
atividade detalhado no subgráfico
ubgráfico faça referência a esse diagrama.
73
Mais um exemplo de Diagrama de Atividades
“O que vem primeiro, o diagrama de atividades ou a descrição textual do fluxo de
trabalho? Isso depende um pouco de como você costuma trabalhar, e se você usa gráficos
ou não. Alguns preferem resumir visualmente a estrutura em um diagrama primeiro e
depois desenvolver os detalhes no texto. Outros preferem iniciar com uma lista com
marcadores de estados de atividade, estar de acordo com elas e depois definir a estrutura
usando um diagrama.
Outra questão válida é se você realmente precisa do diagrama e do documento
textual. A técnica de diagrama de atividades não permite escrever descrições breves de
cada estado de atividade, que deve fazer a especificação textual do fluxo de trabalho
obsoleto. Aqui é preciso estar atento ao público-alvo e ao formato no qual eles esperam a
especificação. “
Para ilustrar este processo, veja a figura abaixo que mostra um diagrama de
atividades. Este exemplo foi obtido de uma organização que vende soluções para redes
de telecomunicações, configuradas individualmente para cada cliente.
74
1) Crie o Diagrama de Estados para uma máquina que, inicialmente, aguarda moedas
para liberar seus produtos; quando o cliente coloca a moeda, a máquina fica
aguardando o mesmo puxar a alavanca para liberar o produto; após a retirada do
produto a máquina retorna ao seu estado inicial.
2) Analise o Diagrama de Casos de Uso abaixo, referente a um módulo de matrícula

e construa um Diagrama de Atividades que reproduza os detalhes do sistema.
75
Considerações Finais
Caro aluno, após completarmos juntos o estudo sobre a análise e modelagem
orientada a objetos utilizando a UML e conhecermos os detalhes de seus principais
diagramas, esperamos que você esteja pensando em aprofundar seus conhecimentos
nesta área!
A criação de uma linguagem para a comunidade de desenvolvedores em orientação
a objetos era uma necessidade antiga. A UML realmente incorporou muitos recursos que
deram à linguagem uma flexibilidade muito grande. A organização dos diagramas,
permitindo a especificação de características estáticas e dinâmicas de um sistema, tornou
a UML fácil de ser utilizada e fez com que diferentes tipos de comportamento pudessem
ser visualizados através de diagramas.
Como vimos, a UML é uma linguagem unificada e universal que pode ser aplicada
em muitas áreas de desenvolvimento de software, já que foi concebida para fornecer
mecanismos de especialização e extensão que permitem a modelagem de requisitos
específicos de diferentes sistemas. Com todas estas vantagens, a UML vem se tornando
um padrão mundialmente utilizado para a modelagem de sistemas.
Sem dúvida alguma, a UML proporciona às grandes empresas de desenvolvimento
de software uma maior comunicação e um melhor aproveitamento dos modelos
desenvolvidos pelos seus vários analistas envolvidos no processo de produção de
software. Isso porque que a linguagem utilizada por todos passou a ser a mesma,
acabando com os problemas de interpretação e entendimento de modelos criados por
diferentes desenvolvedores. Os modelos criados hoje poderão ser facilmente analisados
por futuras gerações de desenvolvedores acabando com a diversidade de tipos de
nomenclaturas e modelos, até então o grande empecilho do desenvolvimento de softwares
orientados a objetos.
Prof. João Caldas e Profa. Elisamara
76
Respostas Comentadas dos Exercícios
Capítulo 1
1) O que é um Modelo de Ciclo de Vida de um software?

A forma como se encadeiam as etapas em um processo de desenvolvimento é conhecida como modelo de processo ou
modelo de ciclo de vida. Existe, porém, o ciclo de vida do projeto de software e o ciclo de vida do produto de software.
Este último estende-se além do projeto e acompanha o produto de software da sua operação inicial, passando por
possíveis manutenções até quando o software entra em desuso. O ciclo de vida do processo, por sua vez, é temporário
e acaba ao final do projeto de desenvolvimento, porém deve ser maduro e capaz de ser repetido com o mesmo padrão
de qualidade a cada novo produto que seja desenvolvido.
2) Quais as restrições à utilização do Modelo Cascata?

O ciclo de vida Cascata, se tiver chance de ser escolhido como o processo de desnevolvimento do software, precisará
sempre passar por uma crítica muito severa, haja vista que as estatísticas de desempenho da indústria mundial de TI,
largamente divulgadas pelo Standish Group, apontam para um sucesso menor que 30% no resultado dos projetos, e,
pesquisas correlatas apontam que a utilização de um ciclo de vida que não permite uma antecipação de riscos, nem
testes de parciais do sistema em desenvolvimento, e que ignora a natureza mutável dos requisitos, está ligada a este
ciclo e a este resultado. É claro que não podemos esquecer que é possível ser bem sucedido utilizando o Cascata,
porém o mercado vem sinalizando muito forte para a utilização de modelos diferentes.
3) Categorize os relacionamentos listados a seguir.

a) Um país possui uma capital - Agregação
b) Um filósofo à mesa de jantar está usando uma faca - Associação Binária
c) Uma conta corrente pode ser Normal ou Especial – Generalização
d) Uma pessoa utiliza uma linguagem de programação em um projeto - Associação Binária
Capítulo 2
1) Assinale “F” para falso ou “V” para verdadeiro:

( F ) A UML pode ser utilizada somente para modelagem de sistemas ligados à área de Informática.
Correção: A UML pode ser usada para a modelagem de qualquer tipo de sistema, independente da área.
( V ) UML é uma linguagem para especificação, documentação, visualização e desenvolvimento de sistemas

orientados a objetos.
( F ) Ao se modelar um sistema utilizando a UML, segundo normas do grupo gestor da UML (Object Management
Group - OMG), tem-se que utilizar pelo menos quatro de seus diagramas.
Correção: A UML não fala quantos, nem quais diagramas devem ser usados, isso é responsabilidade do processo
que a utiliza
( F) A UML é um método de desenvolvimento, o que significa que ela diz o que fazer primeiro e em seguida como
desenhar seu sistema.
Correção: A UML não é um método de desenvolvimento, é apenas uma linguagem. Nela apenas noções sobre a
notação dos diagramas são dadas e não o relacionamento entre os mesmos e sua sequência de uso.
2) Faça a relação entre os conceitos e os diagramas:

(II)
(I)
(IV)
(III)
77
Capítulo 3
1) Descreva a posição do diagramas de casos de uso no processo de desenvolvimento incremental e iterativo.

Considerando que o processo de desenvolvimento incremental é utilizado, a identificação da maioria dos
atores e casos de uso é feita pelos analistas na fase de concepção. A descrição dos casos de uso considerados mais
críticos começa já nessa fase, que termina com 10% a 20% do modelo de casos de uso completo. Na fase de
elaboração, a construção do modelo continua de tal forma que, ao seu término, 80% do modelo de casos de uso esteja
construídos. Na fase de construção, casos de uso formam uma base natural através da qual podem-se realizar as
iterações do desenvolvimento. Um grupo de casos é alocado a cada iteração. Então, o desenvolvimento do sistema
segue a alocação realizada: em cada iteração, um grupo de casos de uso é detalhado (utilizando um nível de abstração
real) e desenvolvido. O processo continua até que todos os casos de uso tenham sido desenvolvidos e o sistema esteja
completamente construído. Esse tipo de desenvolvimento é também chamado de desenvolvimento dirigido a casos de
uso.
2) Faça uma tabela que mostre que tipos de relacionamentos são possíveis entre um ator e um caso de uso. Que tipo
de relacionamento pode haver entre casos de uso? Que tipo de relacionamento pode haver entre atores?
A tabela a seguir exibe as alternativas possíveis entre relacionamentos entre atores e casos de uso em um diagrama de
casos de uso. As células da tabela com um X indicam possibilidade. As células não preenchidas indicam impossibilidade.
Entre Entre casos de Entre ator e
atores uso caso de uso
Comunicação X
Inclusão X
Extensão X
Generalização X X
3) Construa um modelo de casos de uso para a seguinte situação fictícia: "Estamos criando um serviço de entregas.
Nossos clientes podem nos requisitar via portal do sistema a entrega de volumes. Alguns volumes são considerados
de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte.
Contratamos uma companhia de seguro para segurar volumes de valor".
78
Capítulo 4
1) Desenhe um diagrama de classes com relacionamentos, nomes de papéis e multiplicidades para as seguintes
situações:
• Uma Pessoa pode ser casada com outra Pessoa;
• Uma Disciplina é pré-requisito para outra Disciplina;
• Uma Peça pode ser composta de diversas outras Peças.
2) Considere o seguinte discurso relativo a um sistema de partidas de tênis: "Num torneio de tênis, cada
partida é jogada entre 2 jogadores. Pretende-se manter informação sobre o nome e idade dos jogadores; data da
partida e atribuição dos jogadores às partidas. O máximo de partidas que um jogador poderá realizar é 6 e o mínimo
1. Desenhe o diagrama de classes correspondente.
3) A seguir, são enumeradas diversas responsabilidades típicas de serem encontradas em objetos de um

sistema de software. Discuta qual das categorias de objetos (fronteira, controle ou entidade) é mais adequada para
cumprir com cada uma dessas responsabilidades:
a) Criação ou destruição de um objeto. - entidade

b) Formação ou destruição de associações entre objetos de entidade. - controle
c) Obtenção ou modificação de valores de atributos de um objeto de entidade. – controle
d) Exibição de mensagens para o ator. – fronteira
e) Realização de cálculos complexos. - controle
79
Capítulo 5
1. Defina um diagrama de sequência para cada tarefa apresentada a seguir, a partir da descrição do negócio
“Locadora de Veículos”.

(2) aluguel de um veículo por um cliente;
(2) aluguel de um veículo por um cliente;
80
Capítulo 6
1- Crie o Diagrama de estados para uma máquina que, inicialmente, aguarda moedas para liberar seus produtos;
quando o cliente coloca a moeda a máquina fica aguardando o mesmo puxar a alavanca para liberar o
produto; após a retirada do produto a máquina retorna ao seu estado inicial
2- Analise o Diagrama de Casos de Uso

abaixo, referente a um módulo de
matrícula e construa um Diagrama
de Atividades que reproduza os
detalhes do sistema.
81
Bibliografia
BEZERRA, Eduardo. Princípios de Análise e Projeto Orientados a Objetos com UML.
Rio de Janeiro: Campus, 2003.
BLAHA, Michael. Modelagem e projetos baseados em objetos com UML. Rio de
Janeiro: Elsevier, 2006.
BOEHM, Barry W. A Spiral Model of Software Development and Enhancement.
Computer, vol. 21, no. 5. May, 1988. p. 61-72.
BOOCH, G., RUMBAUGH, J., JACOBSON, I. UML – guia do usuário. Rio de Janeiro:
Editora Campus, 2006.
BLOOGS, Wendy. Mastering UML com Rational Rose 2002: A Bíblia. Rio de Janeiro:
Alta Books, 2002.
CRUZ, Márcia; GONSALES, Samuel. 2010. Disponível em
http://blogbohm.com/2010/10/18/analise-de-requisitos-como-ferramenta-de-
planejamento/. Acesso em 03 dez. 2011.
FONSECA, Ijar M. Princípios Fundamentais da Análise de Requisitos. Disponível em:
http://www2.dem.inpe.br/ijar/AnalEstr.html. Acesso em 01 dez. 2011.
GASTALDO, Denise L.; MIDORIKAWA, Edson T. Processo de Engenharia de
Requisitos Aplicado a Requisitos Não-Funcionais de Desempenho – Um
Estudo de Caso. 2002. Disponível em: http://wer.inf.puc-
rio.br/wer03/artigos/denise_gastaldo.pdf. Acesso em 30 nov. 2011.
GUEDES, Gilleanes T. A. UML 2.0 – guia prático. 2007. Disponível em:
http://novatec.com.br/livros/uml2/capitulo9788575221457.pdf. Acesso em 11 abr.
2012.
HERITAGE. Dicionário web. Disponível em:
http://www.thefreedictionary.com/information+technology. Acesso em: 13 nov. 2011.
LEITE, Jair C. Ciclo de vida de Software. 2007. Disponível em:
http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-
1.html. Acesso em: 11 nov. 2011.
PAULA FILHO, Wilson P. Engenharia de software: fundamentos, métodos e padrões.
3.ed. Rio de Janeiro: LTC, 2009.
PETERS, J. F.; PEDRYC, W. Engenharia de software: teoria e prática. Rio de Janeiro:
Campus, 2001.
82
PRESSMAN, R. S. Engenharia de Software. 7.ed. São Paulo: McGraw-Hill, 2010.
PRESSMAN, R. S. Engenharia de Software. 6.ed. São Paulo: McGraw-Hill, 2006.
RUMBAUGH, James; et al. Modelagem e Projeto baseados em objetos. Rio de Janeiro:
Campus, 2006.
SAMPAIO, M. C. Historia de UML. http://www.dsc.ufcg.edu.br/sampaio: [s.n.], 2007.
SCHACH, Stephen. Engenharia de Software: os paradigmas clássico e orientado a
objetos. São Paulo: McGrawHill, 2008.
SILVA, R. P. UML 2 em Modelagem Orientada a Objetos. Florianópolis: Visual Books,
2007.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Addison-Wesley, 2007.
Rational Software Corporation. RUP – Tutorial. 2001. Disponível em:

http://www.wthreex.com/rup/portugues/index.htm. Acesso 14 abr. 2012.
83

Pos UML

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pos UML

Enviado por

Direitos autorais:

Formatos disponíveis

Curso de Pós-Graduação Lato Sensu

Disciplina/Aula: Análise e Modelagem

João Caldas Júnior

1.1. Processo de Software e Modelos de Ciclo de Vida

A forma como se encadeiam as etapas em um processo de desenvolvimento é

1.2. Introdução à Orientação a Objetos

O paradigma de orientação a objetos favorece a aplicação de diversos conceitos

Figura 1 – Exemplo de Classe e Objeto

Como se pode observar, o agrupamento em classes não leva em conta apenas o

Diferença fundamental entre classes e objetos:

Figura 2 – Exemplo de Atributos dos Objetos

Figura 3 – Exemplo de Métodos da Classe Pessoa

Figura 4 – Exemplo de Herança

Figura 5 – Exemplo de Polimorfismo

1.3. RUP - Rational Unified Process

Caro aluno, você também já estudou sobre o Processo Unificado na disciplina

Leia mais sobre RUP – Rational Unified Process online e utilize-o!

UP significa Unified Process ou Processo Unificado e é um processo que define

http://www.wthreex.com/rup/portugues/index.htm (em português)

http://www.wthreex.com/rup/smallprojects/index.htm (em inglês)

1) O que é um Modelo de Ciclo de Vida de um software?

2) Quais as restrições à utilização do Modelo Cascata?

3) Categorize os relacionamentos listados a seguir. Atenção, podem existir

a) Um país possui uma capital

2.1. Breve Histórico da UML

2.3. Diagramas da UML

2.3.2 Diagrama de Classes

2.3.3. Diagrama de Objetos

2.3.4. Diagrama de Pacotes

2.3.5. Diagrama de Sequência

2.3.6. Diagrama de Comunicação

2.3.7. Diagrama de Atividades

2.3.8. Diagrama de Estrutura Composta

2.3.9. Diagrama de Componentes

2.3.10. Diagrama de Implantação

2.3.11. Diagrama de Tempo

2.3.12. Diagrama de Máquina de Estados

2.3.13. Diagrama de Interação Geral

( ) UML é uma linguagem para especificação, documentação, visualização e

( ) Ao se modelar um sistema utilizando a UML, segundo normas do grupo gestor da

2) Faça a relação entre os conceitos e os diagramas:

3.1. Análise de Requisitos e Diagramas de Casos de Uso

3.2. Componentes de um Diagrama de Casos de Uso

3.2.1. Atores e Casos de uso

Os casos de uso podem,

Um ator é representado por um boneco e um rótulo com o

Um caso de uso é representado por uma elipse e um rótulo

Define uma funcionalidade do

Os casos de uso do Ator A são também

Um relacionamento include de um caso de uso A para

Um relacionamento extend de um caso de uso B

• Generalização ou Especialização (é_um)

Um caso de uso B é um tipo específico do caso de

m relacionamento entre um caso de

A figura 7 mostra um exemplo

3.2.2. Documentação de um Caso de Uso

Fluxos Alternativos 1. Numa situação de Exceção - A partir do passo 4

Pós-condição Proprietário Autorizado

1) Descreva a posição do diagramas de casos de uso no processo de

3) Construa um modelo de casos de uso para a seguinte situação fictícia: "Estamos

4.1. O Modelo Entidade-Relacionamento e o Diagrama de

4.2. Componentes de um Diagrama de Classes

As associações representam as relações entre as ocorrências das classes. É um

Descreve uma relação de dependência entre duas classes, é a descrição de um