O documento apresenta uma introdução à linguagem UML (Unified Modeling Language), descrevendo sua evolução, visão de modelos e principais características. Explica que a UML surgiu da compilação de melhores práticas de engenharia de software e da união de conceitos de Booch, OMT e OOSE. Apresenta alguns dos principais diagramas como casos de uso, classes, atividades e sequência.

1. Msc. Antonio Lobato
alobato@gmail.com
Modelagem de Sistemas
Linguagem Uml

2. Conteúdo Programático
Introdução a UML
Evolução da UML
Visão dos modelos

3. Unified Modelling Language
Linguagem de modelagem que irá se associar ao
processo para formar método (meio de obter
o conhecimento).
Representação desenvolvida a partir da aplicação
de técnicas com características próprias para
atender a natureza da aplicação em estudo.
UML

4. Unified Modelling Language
Técnicas possuem uma comunicação direta e se
completam.
Para utilizar a UML deve-se quebrar paradigmas e
ter uma visão sistêmica e funcional
abrangente.
UML

5. A UML tem origem na compilação das "melhores
práticas de engenharia" que provaram ter sucesso
na modelagem de sistemas grandes e complexos.
Sucedeu aos conceitos de Booch (Grady Booch), OMT
(James Rumbaugh) e OOSE (Ivar Jacobson) fundindo-
os numa única linguagem de modelagem comum e
largamente utilizada.
A UML pretende ser a linguagem de modelagem padrão
para modelar sistemas concorrentes e distribuídos.
Histórico
OMT - Object Modeling Technique, OOSE - Object Oriented Software Engineering

6. Os esforços para a criação da UML tiveram início em outubro
de 1994, quando Rumbaugh se juntou a Booch na Rational.
Com o objetivo de unificar os métodos Booch e OMT, decorrido
um ano de trabalho, foi lançado, em outubro de 1995, o
esboço da versão 0.8 do Unified Process - Processo
Unificado (como era conhecido).
Nesta mesma época, Jacobson se associou à Rational e o
escopo do projeto da UML foi expandido para incorporar o
método OOSE.
Nasceu então, em junho de 1996, a versão 0.9 da UML.
Histórico

7. Finalmente em 1997, a UML foi aprovada
como padrão pelo OMG (Object
Management Group), um consórcio
internacional de empresas que define e
ratifica padrões na área de Orientação a
Objetos.
Atualmente encontra-se na versão 2.5.1 de
2017.
Histórico

8. Aplicação
A UML foi definida para ser utilizada na Metodologia Orientada a
Objetos, o que significa que ela possui recursos para
representação dos conceitos propostos pela metodologia.
É possível utilizar em outras metodologias!!!!
Objetivo
Ser independente da linguagem de programação e processo de
desenvolvimento.
UML

9. Modelos
Diagrama de
Componente
Diagrama de
Sequência
Diagrama de
Implantação
Diagrama de Classe de
Projeto
Diagrama de
Estado
Diagrama de
Atividade
Análise de
Viabilidade
Diagrama de
Classe
Diagrama de
Colaboração
Caso de Uso
LANÇAMENTO
DE NOTAS
ALUNOS
PROFESSORES
TURMAS Placa
Cor
Modelo
CLIENTE
Código
Nome
e-mail
VEÍCULOS
LER()
LER()
GARÇON COZINHA
ANOTA
PEDIDO
ELABORAR
COMIDA
GERENTE
DE
TRANSAÇ
ÃO
:FORM
2: LER
1:
INFORMA
DATA
VALIDAD
E
:CARDÁPI
O
3:
INCLUIR 4: OBTER
(CARDAP
IO)
O NEGÓCIO
UML

11. Não se utiliza obrigatoriamente
todos os modelos em todos os projetos.
Deve-se utilizar o que melhor
representar o contexto do negócio.
UML

12. Modelo aplicado para representar os
requisitos de sistema.
O que são requisitos?
São as necessidades dos usuários, as funcionalidades
necessárias para realizar o negócio.
Quais são os tipos?
Funcionais: Ligados a produção da aplicação.
Não-funcionais: Necessidades de ambiente e estrutura
operacional (operacionalidade, ambiente operacional,
Diagrama de Casos de Uso

13. CASO DE USO é a representação
dos requisitos de sistema.
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

14. CASO DE USO é a representação
dos requisitos de sistema.
Deve:
• ser identificado por verbo, pois
tem a conotação de ação;
• ter o significado claro
traduzindo facilmente a
necessidade;
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

15. CASO DE USO é a representação
dos requisitos de sistema.
Exemplo
Vender
Produt
o
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

16. CASO DE USO é a representação
dos requisitos de sistema.
ATOR é a representação do
responsável por realizar o caso de
uso.
Nome
ator
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

17. CASO DE USO é a representação
dos requisitos de sistema.
ATOR é a representação do
responsável por realizar o caso de
uso.
Nome
ator
Podem ser:
• Pessoas, Setores, órgãos
governamentais, e etc.
• Outros Sistemas.
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

18. CASO DE USO é a representação
dos requisitos de sistema.
ATOR é a representação do
responsável por realizar o caso de
uso.
Nome
ator
Exemplo
Vendedor
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

19. CASO DE USO é a representação
dos requisitos de sistema.
ATOR é a representação do
responsável por realizar o caso de
uso.
INTERAÇÃO CASO DE USO-ATOR
representa a realização.
Nome ator
Nome caso de
uso
Nome
ator
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

20. INTERAÇÃO CASO DE USO-ATOR
representa a realização.
CASO DE USO é a representação
dos requisitos de sistema.
ATOR é a representação do
responsável por realizar o caso de
uso.
Nome
ator
Vendedor
Vender
Produto
Nome caso de
uso
• Simbologia
Diagrama de Casos de Uso

21. • Simbologia – Interação de Casos de Uso
<<include>> Estabelece a ligação obrigatória entre os
casos de uso. SEMPRE o caso de uso será executado.
Diagrama de Casos de Uso

22. Vendedor
Vender
Produto <<include>>
Emitir Nota
Fiscal
• Simbologia – Interação de Casos de Uso
<<include>> Estabelece a ligação obrigatória entre os
casos de uso. SEMPRE o caso de uso será executado.
Diagrama de Casos de Uso

23. Vendedor
Vender
Produto <<include>>
Emitir Nota
Fiscal
• Simbologia – Interação de Casos de Uso
<<include>> Estabelece a ligação obrigatória entre os
casos de uso. SEMPRE o caso de uso será executado.
<<extend>> estabelece a ligação opcional entre os
casos de uso. O caso de uso será executado em
atendimento a uma regra de negócio.
Diagrama de Casos de Uso

24. <<include>> Estabelece a ligação obrigatória entre os
casos de uso. SEMPRE o caso de uso será executado.
<<extend>> estabelece a ligação opcional entre os
casos de uso. O caso de uso será executado em
atendimento a uma regra de negócio.
Cadastrar
Cliente
<<extend>>
Vendedor
Vender
Produto <<include>>
Emitir Nota
Fiscal
• Simbologia – Interação de Casos de Uso
Diagrama de Casos de Uso

25. Representa a classificação de um determinado ator.
Deve ser usada quando:
Temos mais de um ator realizando a mesma tarefa
e, algumas tarefas diferenciadas.
• Simbologia – Generalização de Ator
Funcionário
Vendedor Gerente
Diagrama de Casos de Uso

26. Representa a classificação de um determinado ator.
Deve ser usada quando:
Temos mais de um ator realizando a mesma tarefa
e, algumas tarefas diferenciadas.
Funcionário
Vendedor Gerente
Vender Produto
<<include>>
Emitir Nota
Fiscal
Cadastrar
Cliente
<<extend>> Autorizar
pagamento
comissão
• Simbologia – Generalização de Ator
Diagrama de Casos de Uso

27. • Concentra em um caso de uso um conjunto de
procedimentos que serão utilizados por vários outros
casos de uso que possuem outras particularidades.
Atendente
Graduação
Cadastrar
Alunos
Graduação
Atendente
Mestrado
Registrar
Alunos
Cadastrar
Alunos
Mestrado
Simbologia – Generalização de Caso de
Uso
Diagrama de Casos de Uso

28. Passos para construção:
1.Leia atentamente o estudo de caso e identifique os
requisitos e os responsáveis por realizar os requisitos;
2.Crie uma lista de atores e requisitos;
3.Inicie a construção do modelo verificando quem é o
responsável por realizá-lo: ator ou outro caso de uso.
4.Sendo o ator: represente o modelo.
5.Sendo outro caso de uso verifique se essa interação é
de <<include>> ou <<extend>>.
6.Verifique se existe generalização.
Aplicação Prática
• Vamos lá!

29. Estacionamento “Praça da Nassau”
Diariamente o estacionamento “Praça da Nassau” recebe vários clientes para
aluguel de suas vagas e possui uma rotina destinada ao bom atendimento.
O gerente do estacionamento cadastra todas as vagas com sua devida
localização e situação. No caso de algum impedimento, goteira e obra, por
exemplo, as vagas são interditadas para uso.
O veículo é identificado (Placa, Cor e modelo) na entrada e registrado pelo
atendente, que emite um comprovante e cadastra o cliente que for recebido
pela 1ª vez. A locação da vaga registra data e hora de entrada, identifica o
manobrista e atendente e, bloqueia a vaga.
Estudo de Caso

30. Estacionamento “Praça da Nassau”
A liberação é efetivada a partir da solicitação do cliente,
que entrega ao atendente o seu comprovante de
locação, realiza o pagamento e recebe uma
autorização de saída. São registradas data e hora de
saída e a vaga é liberada para um próximo cliente.
O manobrista retira o carro da vaga e entrega-o ao
cliente.
Estudo de Caso

31. Próxima aula
Será apresentada a ferramenta astah* para criação
dos modelos e desenvolvido o exercício a partir do
estudo de caso “Sistema de Gestão de Hotel
Nassau”.
Não deixem de fazer até lá para que possam
acompanhar!!!
UML