03 - Introdução UML

Prévia do material em texto

Introdução ao UML
Análise e Projeto de Sistemas I
Prof. Adriano Firmo de Paiva
Introdução a UML
• Originou-se da necessidade de produzir sistemas 
orientado a objetos, pois haviam linguagem OO e todas 
as técnicas até o momento eram voltadas para a análise 
estruturada.
• Foram criadas algumas técnicas:
• Grady Booch – técnica Booch.
• James Rumbaugh – técnica OMT.
• Ivar Jacobson – técnica OOSE.
Introdução a UML
• Em 1994, Booch, Rumbaugh e Jacobson uniram forças 
para combinar suas metodologias populares – Booch, 
OMT e OOSE. 
• Em 1996 foi apresentada a UML (Linguagem de 
Modelagem Unificada).
• UML é a junção do que havia de melhor nas três 
metodologias.
• A UML acabou com esta guerra, trazendo as melhores 
idéias de cada uma destas metodologias
Introdução a UML
UML
BOOCH
OMT
OOSE
▪ Diagrama de Estados
▪ Diagrama de Objetos
(colaboração).
▪ Diagrama de Processos
(desenvolvimento).
▪ Diagrama de Módulos
(componentes).
▪ Caso de Uso.
▪ Subsistemas (package).
▪ Diagrama de Interações.
▪ Miniespecificação.
▪ Diagrama de Estados.
▪ Diagrama de Classes.
Introdução a UML
• A UML não tem as características de um método.
• A UML não representa uma sequência de passos
para a resolução de um problema, como deveria
ser no caso de um método
• Então, a UML não é um método e sim uma
linguagem
Introdução a UML
• A UML pode ser utilizada tanto no
desenvolvimento de software como representar
sistemas mecânicos sem nenhum software,
descrevendo-os em termos de diagramas
orientados a objetos
Introdução a UML
◼ A UML é uma tentativa de padronizar a
modelagem orientada a objetos de uma forma
que qualquer sistema, seja qual for o tipo, possa
ser modelado corretamente, com consistência,
fácil de se comunicar com outras aplicações,
simples de ser atualizado e compreensível
UML - Objetivos
◼ O objetivos da UML são:
 A modelagem de sistemas (não apenas de
softwares) usando os conceitos da
orientação a objetos
Estabelecer uma união fazendo com que
métodos conceituais sejam também
executáveis
Criar uma linguagem de modelagem usável
tanto pelo homem quanto pela máquina
UML –Uso da UML
◼ A UML é usada no desenvolvimento dos mais
diversos tipos de sistemas
◼ Ela abrange sempre qualquer características de
um sistema em um de seus diagramas
◼ É também aplicada em diferentes fases do
desenvolvimento de um sistema, desde a
especificação de análise de requisitos até a
finalização com a fase de testes
UML –Uso da UML
◼ Um dos objetivos da UML é descrever qualquer
tipo de sistema, em termos de diagramas
orientados a objetos
◼ O uso mais comum é para criar modelos de
software, mas também é usada para
representar sistemas mecânicos
UML –Uso da UML
◼ Tipos de Sistemas que são utilizados a UML e
suas características mais comuns:
 Sistemas de Informação: Armazenar, pesquisar, editar
e mostrar informações para usuários
 Sistemas Técnicos: Manter e controlar equipamentos
técnicos como de telecomunicações, equipamentos
militares e ou processos industriais. Eles devem
possuir interfaces especiais do equipamento e menos
programação de software
UML –Uso da UML
❑ UML é...
❑ uma linguagem visual.
❑ independente de linguagem de 
programação.
❑ independente de processo de 
desenvolvimento.
❑ UML não é...
❑ uma linguagem programação (mas possui 
versões!).
❑ uma técnica de modelagem.
UML – Fases de Desenvolvimento
◼ Existem cinco fases no desenvolvimento de
sistemas de software (devem ser executadas
nesta ordem):
 Análise de Requisitos
 Análise
 Design (projeto)
 Programação
 Testes
UML – Fases de Desenvolvimento
◼ Análise de Requisitos:
 Captura as intenções e necessidades dos usuários do
sistema a ser desenvolvido através do uso de funções
chamadas “use-cases”
 Através do desenvolvimento de use-cases, as
entidades externas ao sistema (atores externos) que
interagem e possuem interesse no sistema são
modelados entre as funções que eles requerem,
funções estas chamadas de use-cases
UML – Fases de Desenvolvimento
◼ Análise de Requisitos:
 Os atores externos e os use-cases são modelados
com relacionamentos que possuem comunicação
associativa entre eles ou são desmembrados em
hierarquia
 O diagrama de use-cases mostrará o que os atores
externos, ou seja, os usuários do futuro sistema
deverão esperar do aplicativo, conhecendo TODA a
sua funcionalidade, sem importar como será
implementada
UML – Fases de Desenvolvimento
◼ Análise:
 A fase de análise está preocupada com as primeiras
abstrações (classes e objetos) e mecanismos que
estarão presentes no domínio do problema
 As classes são modeladas e ligadas através de
relacionamentos com outras classes, e são descritas
no diagrama de Classes
UML – Fases de Desenvolvimento
◼ Análise:
 As colaborações entre classes também são mostradas
neste diagrama para desenvolver os use-cases
modelados anteriormente
 Nesta fase somente serão modeladas classes que
pertençam ao domínio principal do problema do
software, ou seja, classes técnicas que gerenciem
banco de dados, interface, comunicação, concorrência
e outros não estarão presentes neste diagrama
UML – Fases de Desenvolvimento
◼ Design (Projeto):
 Nesta fase, o resultado da análise é expandido em
soluções
 Novas classes serão adicionadas para prover uma
infra-estrutura técnica: a interface do usuário e de
periféricos, gerenciamento de banco de dados,
comunicação com outros sistemas etc
UML – Fases de Desenvolvimento
◼ Design (Projeto):
 As classes do domínio do problema modeladas na
fase de análise são mescladas nessa nova infra-
estrutura técnica tornando possível alterar tanto o
domínio do problema quanto à infra-estrutura
 Resulta no detalhamento das especificações para a
fase de programação do sistema
UML – Fases de Desenvolvimento
◼ Programação:
 Nesta fase as classes provenientes do design são
convertidas para o código da linguagem orientada a
objeto escolhida
 O grau de dificuldade depende da escolha da
linguagem
 Não é aconselhável traduzir mentalmente os modelos
de análise e design em UML no momento de sua
criação
UML – Fases de Desenvolvimento
◼ Programação:
 Os modelos criados nas fases passadas são o
significado do entendimento e da estrutura do
sistema, porém ainda podem ser alterados caso o
analista julgue necessário, o que não pode é alterar a
programação sem alterar os modelos anteriores
senão estes não estarão mais demonstrando o real
perfil do sistema
 È uma fase separada e distinta onde os modelos
criados são convertidos em código
UML – Fases de Desenvolvimento
◼ Testes – temos 3 tipos de testes:
 Unidade: são para classes individuais ou grupos de
classes e são geralmente testados pelo programador
 Integração: são aplicados já usando as classes e
componentes integrados para se confirmar se as
classes estão cooperando uma com as outras como
especificado nos modelos
 Aceitação: observam o sistema como uma “caixa
preta” e verificam se o sistema esta funcionando
como o especificado nos primeiros diagramas de
use-cases
Diagramas UML
• Diagramas são representações gráficas de um conjunto de 
elementos.
• São utilizados para modelar, especificar, construir, documentar 
artefatos de um sistema.
• Permitem a visualização de um sistema sob diferentes pontos 
de vista.
Diagramas Estruturais 
(estático)
• Diagrama de classe.
• Diagrama de objeto.
• Diagrama de componentes.
• Diagrama de implementação.
Diagramas Comportamentais 
(dinâmico)
• Diagrama caso de uso.
• Diagrama de sequência.
• Diagrama de colaboração.
• Diagrama de gráfico de estados.
• Diagrama de atividades.
Quais diagramas utilizar?
Depende da complexidade do seu sistema
Como utilizar diagramas?
• De forma incremental
• Ampliando os diagramas uma parte de cada vez.
• De forma interativa
• Repetindo o processo de projetar uma pequena parte e construí-
la.
Levantamento e especificação 
dos requisitos
• Significa buscar todas as informações possíveis sobre aquilo 
que se espera do sistema.• Informações fornecidas por:
• Usuários
• Analise de documentos
• Outros sistemas
• Observação dos usuários ao interagirem com o sistema atual.
Requisitos funcionais
• São aqueles relacionados aos serviços que o sistema deve 
fornecer. 
• Especificam o que o sistema deve fazer.
• Exemplos:
• O sistema deve realizar venda.
• O sistema deve permitir devolver filme.
• O sistema deve permitir cancelar pedido.
Requisitos não funcionais
• Referem-se às restrições sobre as funções e as operações que 
o sistema deve fornecer ou realizar.
• Eles tratam de rotinas de backup, autenticação no sistema, 
desempenho, interface etc.
• O sistema deve ter interface web.
• O sistema deve realizar backup diário.
Objetivos dos Casos de Uso
• Descrever os requisitos funcionais do sistema, mostrando que 
desenvolvedores e clientes estão de acordo sobre o que será 
desenvolvido.
• Fornecer uma visão clara sobre o que o sistema deve fazer.
• Fornecer uma base para a execução de testes que verifiquem 
se o sistema trabalha apropriadamente.
Casos de Uso
• Os casos de usos representam as interações dos atores com o 
sistema.
• Um caso de uso captura uma funcionalidade do sistema.
• Não revelam a estrutura e o comportamento interno do 
sistema. 
• Há várias formas para descrever casos de uso: 
• um texto contínuo 
• uma sequência numerada 
• a utilização de tabelas.
Texto contínuo
• O cliente chega à livraria. No terminal de consulta, o sistema 
mostra as formas de pesquisa (por título da obra, pelo nome 
do autor, pelo nome da editora). 
Sequência numerada
1. Cliente chega à livraria e dirige-se a um terminal de 
consulta.
2. O sistema exibe as formas de pesquisa (por título da obra, 
pelo nome do autor, pelo nome da editora).
3. O cliente escolhe a forma de pesquisa que lhe interessa.
4. O sistema exibe as informações sobre o produto desejado.
Tabela
Diagramas de Casos de Uso
• Representa, graficamente, todos os casos de uso de um 
sistema, utilizando a linguagem UML.
• Por meio dele é possível visualizar, em um alto nível de 
abstração, quais os elementos (atores) interagem com o 
sistema em cada funcionalidade.
Ator
Meta 1
Meta 2
Quais metas eu quero 
atingir ao utilizar o 
sistema?
Diagramas de Casos de Uso
Diagramas de Casos de Uso
• Objetivos:
• Delimitação do contexto de um sistema
• Documentação e o entendimento dos requisitos
• Descrição dos requisitos funcionais
• Principal saída da etapa de especificação de 
requisitos
• Principal entrada da etapa de análise
• Facilitam a comunicação entre os stakeholders
• São a base para a definição do cronograma
• Auxiliam na elaboração dos casos de teste
Atores
• São as entidades que interagem com o sistema.
• É sempre o ator que causa o estimulo.
• Sempre está fora do sistema.
• Atores podem ser:
• Pessoas (Empregado, cliente, gerente, aluno,
professor);
• Organizações ( Empresa Fornecedora, Administradora de 
cartões);
• Outros Sistemas ( Sistema de estoque, Sistema de
cobrança);
• Equipamentos (Leitora de cartões, Sensores, Alarmes); 
Identificando os Atores
Essa 
entidade é 
algo que eu 
possa mudar 
dentro do 
sistema?
Essa entidade 
provavelmente 
não é um ator.
Essa entidade 
provavelmente 
é um ator.
Essa 
entidade é 
uma pessoa 
que interage 
com o 
sistema?
sim
não
não
sim
entidade
Diagramas de Casos de Uso
• Conectando atores e casos de uso:
• Os atores e os casos de uso com os quais eles interagem
são ligados pela associação de comunicação.
• A seta é opcional, mas, quando usada, ela indica qual elemento
começa a interação.
• Para entender plenamente o papel definido para um ator, você
deve saber em que casos de uso o ator está envolvido.
• Para entender plenamente o alcance de um caso de uso,
você deve saber os atores com os quais ele se comunica.
Diagramas de Casos de Uso
• Exemplos:
• Cliente de banco pode usar um caixa automático para:
• Sacar dinheiro
• Transferir dinheiro
• Consultar saldo 
Diagramas de Casos de Uso
• O nome do caso de uso deve ser único.
• Deve estar na perspectiva do ator que dispara o caso de uso.
• Deve iniciar com o verbo no infinitivo.
Fazer Matrícula Consultar Notas Realizar Saque
Relações em Casos de Uso
• <<include>>: incorpora o comportamento de um caso de uso 
à outro caso de uso.
Relações em Casos de Uso
• <<include>>: Identificar usuário é uma funcionalidade que
poderia ser interna de sacar dinheiro e de depositar dinheiro
mas sendo comum a vários casos de uso, é mais interessante
modelar identificar usuário em um caso de uso que permita o
reuso do mesmo.
• Assim, todos os casos de uso que necessitem identificar
usuário de forma obrigatória é ligado ao caso de uso
Identificar usuário através do relacionamento de inclusão.
Relações em Casos de Uso
• <<include>>: Pode ser usada para:
• Representar comportamentos reutilizáveis
• Simplificar fluxos de eventos complexos
• Quando existe uma dada função dentro do sistema que
aparece em vários casos de uso, ou seja ela é utilizada por
várias funcionalidades, podemos modelar essa função em um
caso de uso uma única vez e ligá-la a todos os casos de uso
que incluem essa função comum, dizendo que essa função é
usada em diferentes partes do meu software.
Relações em Casos de Uso
• <<extend>>: indica que o comportamento estendido poderá 
ou não ser usado. O uso do comportamento estendido é 
opcional.
Relações em Casos de Uso
• <<extend>>: Nesse relacionamento de extensão estou
definindo que ao acessar a funcionalidade encerrar conta
pode ser necessário ou não sacar dinheiro (Se a conta tem
saldo positivo, vou sacar dinheiro) mas essa funcionalidade
não é obrigatória, caso a conta tem saldo igual a zero não
ocorrerá a funcionalidade de sacar dinheiro. É opcional.
Relações em Casos de Uso
• <<extend>>: Pode ser usada para:
• Simplificar fluxos de eventos complexos
• Representar comportamentos opcionais
• Lidar com exceções 
• Por exemplo, em uma descrição de um caso de uso temos
fluxos básicos e fluxos alternativos, quando um fluxo
alternativo é complexo e opcional podemos modelá-lo como
um caso de uso, ligando-o ao caso de uso de origem por um
relacionamento de extensão.
Relações em Casos de Uso
• Generalização: utilizado para criar um caso de uso específico 
baseado em um caso de uso geral.
Relações em Casos de Uso
• Generalização: Um caso de uso pode especializar outro caso
de uso:
• Adicionando o fluxo de eventos original
• Refinando o fluxo de eventos original
• Especialização permite modelar comportamento diferenciado
entre um caso de uso base e casos de uso filhos.
• Pouco utilizado.
• Pode existir entre atores também
Relações em Casos de Uso
• Generalização: Quando o usuário acessar a funcionalidade
consultar saldo, essa funcionalidade vai se dar de uma maneira
específica:
• ou consultar saldo na tela
• ou consultar saldo impresso.
Relações em Casos de Uso
Relações em Casos de Uso
• Na inclusão partimos do caso de uso base para o caso de uso que 
será incluído 
• Na extensão parte do caso de uso opcional para o caso de uso base 
Relações entre atores
• Não existe ligação entre atores.
• Atores são entidades externas do sistema, portanto a
comunicação entre eles está fora do escopo do sistema, não
devendo ser modelada no diagrama de caso de uso, um vez que
ele modela apenas as funcionalidades do sistema.
Relações entre atores
• Alguns casos de uso são
utilizados por vários atores,
para simplificar o diagrama e
diminuir o número de
associações, cria-se um ator
genérico.
• Além disso alguns casos de
uso são exclusivos de apenas
um ou alguns atores, mas
não de todos.
• Generalização pode
simplificar a representação
gráfica do sistema
Relações entre atores
• Sem generalização Com generalização
Detalhando um Caso de Uso
Fonte: Bezerra (2007)