Colégio Pio Décimo

Guilherme
Gidalte
Patrício
Wagner Santos
Walbert

UML

Aracaju
2009
 Guilherme
Gidalte
Patrício
Wagner Santos
Walbert

UML

Trabalho Apresentado ao Colégio Pio

Décimo Como complemento para a av2,
do curso Técnico em Informática através
da matéria Análise de Sistemas,
Lecionada pelo prof. Marcus Poletti.

Aracaju
2009
 UML

Introdução

O grande problema do desenvolvimento de novos sistemas

utilizando a orientação a objetos nas fases de análise de requisitos, análise de
sistemas e design é que não existe uma notação padronizada e realmente
eficaz que abranja qualquer tipo de aplicação que se deseje. Cada simbologia
existente possui seus próprios conceitos, gráficos e terminológicos, resultando
em uma grande confusão, especialmente para aqueles que querem utilizar a
orientação a objetos, não só sabendo para que lado aponta a seta de um
relacionamento, mas, sabendo criar modelos de qualidade para ajudá-los a
construir e manter sistemas cada vez mais eficazes.
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar
Jacobson que são conhecidos como “os três amigos”. Eles possuem um
grande conhecimento na área de modelagem orientada a objetos, já que as
três mais conceituadas metodologias a respeito do assunto foram eles que
desenvolveram, sendo a UML, uma junção do que havia melhor nessas três
metodologias adicionando novos conceitos e visões de linguagem.
Com o surgimento da “Unified Modeling Language” (UML, ou ainda
Linguagem de modelagem unificada), Muitos desenvolvedores da área da
orientação a objetos ficaram entusiasmados, já que essa padronização
proposta pela UML era o tipo de força que eles sempre esperaram.
A linguagem de modelagem unificada (UML) é muito mais que a
padronização de uma notação, é uma linguagem designada para especificar,
visualizar, construir e documentar um sistema. Por isso e muitas outras razões,
o bom entendimento da UML não é apenas aprender a simbologia e o seu
significado, mas, também significa aprender a modelar orientado a objetos no
estado da arte.
Conceito

UML é uma linguagem visual para especificação (modelagem) de

sistemas orientados a objetos, ela privilegia a descrição de um sistema
seguindo três perspectivas:

1. Os diagramas de classes - (Dados estruturais);

2. Os diagramas de casos de uso (Operações funcionais);
3. Os diagramas de seqüência, atividades e transição de Estados
(Eventos temporais).

Os casos de uso de um projeto de software são descritos na

linguagem UML através de Diagramas de Casos de Uso (Use Case). Diagrama
de “Use Case” é um diagrama usado para identificar como o sistema se
comporta em várias situações que podem ocorrer durante sua operação,
descrevem o sistema, seu ambiente e a relação entre os dois, os componentes
deste diagrama são os atores, os “Use Case” e os relacionamentos.

Ator

Representa qualquer entidade que interage com o sistema durante

sua execução, essa interação se dá através de comunicações (troca de
mensagens). Um ator pode ser uma pessoa (usuário, secretaria, aluno), um
dispositivo (impressora, máquina), hardware (placa de modem, scanner),
softwares (sistema de banco de dados, aplicativos), etc.

Algumas de suas características são descritas abaixo:

• Ator não é parte do sistema, representa os papéis que o usuário do

mesmo pode desempenhar.
• Pode interagir ativamente com o sistema.
• Pode ser um receptor passivo de informação.
• Pode representar um ser humano, uma máquina ou outro sistema.
Representação

Ator Use Case

OBS: Atores representam, na verdade, papeis desempenhados por

pessoas, dispositivos ou outros quando interagem com o sistema. Um ator cujo
identificador seja ALUNO não representa um aluno, mais sim um aluno
qualquer, uma pessoa que esteja interagindo com o sistema na qualidade de
aluno.

Use Case

É uma seqüência de ações que o sistema executa produzindo um

resultado de valor para o ator. Modela o diálogo entre os atores e o sistema, é
um fluxo de eventos completos.

Algumas de suas características são descritas abaixo:

• Um “Use Case” modela o diálogo entre atores e o sistema

• É iniciado por um ator para invocar uma certa funcionalidade do sistema.
• É um fluxo de eventos completos e consistentes.
• O conjunto de todos os “Use Case” representa todas as situações
possíveis de utilização do sistema.
Relacionamento

Os relacionamentos ligam as classes/objetos entre si criando

relações lógicas entre essas entidades, podem ser dos seguintes tipos:

 Associação: É uma conexão entre classes, e também significa que é

uma conexão entre objetos daquelas classes. Em UML, uma associação é
definida com um relacionamento que descreve uma série de ligações, onde a
ligação é definida como a semântica entre as duplas de objetos ligados.

 Generalização: É um relacionamento de um elemento mais geral e outro

mais específico. O elemento mais específico pode conter apenas informações
adicionais.

Diagrama de caso de uso

Antes de entender o que é um caso de uso, é necessário entender o

conceito de cenário. Esse é uma seqüência de passos que descreve uma
interação entre um usuário e um sistema. A partir desse conceito o caso de uso
é entendido como um conjunto de cenários ligados por um objetivo comum de
um ator. Um caso de uso é uma representação de várias ações para a
realização de uma atividade. Há necessidade das ações terem uma afinidade
entre si para haver um caso de uso. Um caso de uso é utilizado para capturar
os requisitos funcionais do sistema.
Normalmente quando modelamos sistemas, definimos um caso de uso
principal e outros que serão os alternativos. O caso de uso apresenta uma
linguagem simples e de fácil compreensão para que os usuários possam ter
uma idéia geral de como o sistema irá se comportar.
Os critérios para o desenvolvimento dos casos de uso segundo Guedes
são os seguintes:
 Descrever o que o sistema faz.
 Descrever o comportamento do sistema com base na visão dos atores.
  Cada caso de uso deve produzir algo de valor para um ou mais atores.
 Cada caso de uso deve abordar um processo completo do negócio.

Exemplo de um diagrama caso de uso (sistemas bancário).

Realiza Abrir
r conta
saque

Cliente Consult Vender Gerente

ar saldo seguro

O ator cliente executará os casos de uso “realizar saque” e

“consultar saldo”, enquanto o gerente poderá interagir com os casos de uso
”abrir conta” e “vender seguro”.

Relacionamento entre casos de uso I

Os casos de uso pode se relacionar de duas formas:

 Include (Inclusão): É quando existe um serviço, situação ou rotina
comum a mais de um caso de uso.
 Extend (Extensão): É utilizado para descrever cenários opcionais
de um caso de uso, Indica que esse terá seu procedimento acrescido de outro
caso.

Relacionamento entre casos de uso II

Include- Quando um caso uso “A” inclui (include) outro caso de uso “B”. Isto
implica que ao executar o caso de uso “A” executa-se também o caso de
uso “B”.
 Exemplo:

<< INCLUDE >> Emitir

Processar
nota
pedido
fiscal

Vendedor

Extend – Quando um caso de uso “A” tem um relacionamento do

tipo extends como outro caso de uso “B”. Implica que ao executar o caso de
uso “A” não necessariamente “B” será executado.

Exemplo:

Consultar
Serasa

<<Extend>>
Proces
sar
pedido <<Extend>>
Vendedor
Solicitar
entrega
Diagrama de Classes

O diagrama de classes permite a visualização das classes que

compõe o sistema, com seus nomes, atributos e operações, bem como o
relacionamento, complementação e transmissão de informações entre si. Em
outros termos o diagrama de classes mostra a estrutura do software.
A classe em UML é representada por um retângulo, sendo composta
por três seções.
 Nome da Classe.
 Atributos.
 Operações.

Exemplo:

Classe DVD

Estrutura
Hora

Nome do Estatus
Atributo
Voltar ()
Comportame
Pausar ()
Operações nto
Adiantar ()

Stop ()

Tocar ()
Diagrama de componentes

Esse diagrama representa os componentes do sistema e sua

associação com outros componentes, por exemplo, em um sistema pode-se ter
vários arquivos com extensão .java, cada arquivo desse é considerado um
componente. Vários componentes podem forma um módulo completo, esse
módulo é também chamado de componente que pode associar com outro.

O que são componentes?

Parte não trivial, quase independente, substituível de um sistema,
que provê a realização de (uma/um conjunto de) interfaces.

Exemplos:
 Um código fonte.
 Um componente de tempo de execução.
 Um componente executável.

Notação:

UML 2.0
Exemplo de diagrama de componentes:

Cobrança.e Matrícula.e
xe Sistema de cobrança xe

Curso.dll Pessoa.dll
Curso Usuario

Diagrama de interação

Diagramas de interação representam como o sistema age

internamente para que um ator atinja seu objetivo na realização de um caso de
uso. Um diagrama de interação mostra:

 Mensagens entre objetos;

 Ordem em que as mensagens são enviadas;
 As quais classes as operações pertencem;
 Que informações precisam se enviadas de um objeto a outro.
As interações entre objetos acontecem por meio da troca de
mensagens. Por sua vez as mensagens são solicitações de execução de uma
operação em outro objeto, representa a requisição de um objeto remetente a
um objeto receptor para que este último execute alguma operação definida
para sua classe. Sendo assim as realizações de funcionalidade só podem
ocorrer por meio do envio de mensagens.

As mensagens podem ser do tipo:

 Simples: é utilizada quando a natureza de mensagem não

relevante.
  Síncrona: indica que o objeto remetente espera que o objeto
recebedor processe a mensagem antes de recomeçar o seu processamento,
ou seja, o objeto emissor fica bloqueado até que o receptor termine de atender
à mensagem.
 Assíncrona: é aquela na qual o objeto remetente não espera
resposta para prosseguir seu processamento.
 Reflexiva: é aquela na qual um objeto envia uma mensagem para
si própria.

Existem dois tipos de diagrama de interação:

Diagrama de sequência: enfatiza os aspectos temporais envolvido

na interação entre os objetos, em função da troca de mensagens.

Diagrama de colaboração: representa as interações entre os

objetos em funções das trocas de mensagens sem levar em consideração a
ordem temporal das mensagens.

As principais características do diagrama de colaboração são:

 Há preocupação com ordem das ações

 Cada mensagem é rotulada com; - nome; - Argumento; -
Informações de controles e condições.
 Principal objetivo: identificar quais mensagens (operações) devem
ser implementadas pelas classes dos objetos receptores.
Exemplo diagrama de sequência:

Objeto cliente objeto fornecedor

: Fornecedor
: Cliente

1: Realiza responsabilidade
Mensagem reflexiva

Mensagem

Foco de controle

Exemplo de diagrama de colaboração:

Diagramas de Transição de Estado

Os diagramas de transição de estado descrevem as seqüências de

estados que um objeto ou uma interação pode passa ao longo da sua
existência em resposta a estímulos recebidos, conjuntamente com suas
respostas e ações.
Esse diagrama é bastante útil para modelar o comportamento dos
sistemas de tempo real, pois este tipo de sistema lida com estímulos do
ambiente.

Exemplo diagrama de estado:

Este é o estado inicial, pois apresenta uma seta sem origem.

Estado
I

Ação 1 Ação 2
(condição 1) (Condição 2)

Estado X

Ação 3 Ação 4
(Condição 3) (Condição 4)

Estado Estado
F1 F2

Do estado x, o sistema poderá passar para o estado F1 ou F2, dependendo se ocorrer a

condição 3 ou a condição 4.

Há dois estados finais (pois deles não partem setas para outros estados) mas apenas um deles
será alcançado.
Diagrama de atividades

Os diagramas de atividades são um caso particular dos diagramas

de transição de estado, no qual a maioria dos estados são substituídos pelos
conceitos correspondentes a ações ou atividades, e o qual as transações são
desencadeadas devido à conclusão de ações nos estados originais.
O objetivo desse diagrama é representar os fluxos conduzidos por
processamento interno, em contraste com eventos externos representados
tipicamente nos diagramas de estado.

Exemplo de diagrama de atividades:

Diagrama de objetos

O diagrama de objeto é um complemento do diagrama de classe.

Seu objetivo é fornecer uma visão dos valores armazenados pelos objetos das
classes, em um determinado momento da execução de um processo.

Exemplo:
Diagrama de instalação

Os diagramas de instalação descrevem a configuração de elementos

de suporte de processamento, e de componentes de software, processos e
objetos existentes nesses elementos.

Exemplo:
Referencias Bibliográficas

BEZERRA, Eduardo. Princípios de Análise e projetos de sistemas com

UML: Um guia prático para modelagem de sistemas orientados a objetos
através da linguagem de Modelagem unificada. Rio de janeiro. Editora
Campus.

ROCHA, Lindimon Cristiano Martins. Metodologia de desenvolvimento de

software utilizando RUP e UML. Araguari-Mg.

Silva, Manuel Rodrigues da silva & Videira, Carlos Alberto Escaleira. UML,
Metodologias e Ferramentas CASE: Linguagem de Modelação UML,
Metodologia e Ferramentas CASE na Concepção e desenvolvimento de
software.