10/03/2011

UML
A UML (Linguagem de Modelagem Unificada) é uma
linguagem-padrão e uma ferramenta que nos auxilia
Engenharia de Software II na modelagem de sistemas de software.

UML - Unified Modeling Language Não é um processo de desenvolvimento de software:

É independente tanto de linguagem quanto de
processos.

É a forma de comunicação que um processo pode

utilizar.
FATEC – Ourinhos/SP
É uma linguagem visual utilizada para modelar
Curso ASTI – 4º. Ciclo Programação
sistemas computacionais por meio do paradigma de
Profa. Me. Viviane de F. Bartholo Potenza
orientação a objetos.

3 4

Modelos em geral UML

Modelo: Simplificação da realidade.
Permitem melhor compreensão sobre o sistema a ser
construído.
A construção da UML teve muitos contribuintes, mas os
principais desenvolvedores foram Ivar Jacobson, Grady
Booch e Jim Rumbaugh: Chamados de “os três amigos”.
são sócios da empresa Rational Software  Ferramenta
CASE Rational Rose

Em 1996 surge com o nome de UML, na versão 0.9.

Em 1999, já na versão 1.3, passou a ser mantida pela OMG

(Object Management Group): Consórcio internacional que
define e ratifica padrões na área de orientação a objetos.

Modelagem na Engenharia Civil

1
 10/03/2011

5 6

UML História de UML

2001 ? UML 2.0

Atualmente, a especificação do padrão UML está na 2000 UML 1.4

versão 2.0 (OMG, 2003). 1999 UML 1.3
Revisões menores
1998
UML 1.2
Documentação pode ser encontrada nos sites Nov ‘97 UML aprobado por el OMG

www.omg.org e www.uml.org.

7 8

UML UML
É uma linguagem: É uma linguagem para visualização:
 Vocabulário.  Uma figura diz mais que mil palavras ....
 Sintaxe.
Geradores Automáticos
Semântica. Símbolos Ausência de
Semântica =

+
Objetivos: Gráficos Ambiguidade
 Visualizar  Visualização antecipada, antes da
 Especificar
implementação.
 Visões complementares.
 Construir
 Documentar

2
 10/03/2011

9 10

UML
É uma linguagem para especificação (Descrição precisa): UML
 Análise:
 Estudo detalhado dos requisitos levantados na fase anterior.
 Validação dos modelos. É uma linguagem para construção:
 Projeto:  Os modelos da UML podem ser mapeados
 Desenho do sistema. diretamente em linguagens de programação tais
 Como o sistema funcionará para atender aos requisitos, levando em como Java, C++, etc.
conta os recursos tecnológicos existentes.  É possível a geração de código a partir de
 Descrição computacional do que o software deve fazer, coerente
modelos UML e a geração de modelos UML a
com a descrição feita na análise.
partir de códigos.
 Implementação:
 Execução direta dos modelos, simulação de
 Tradução da descrição computacional obtida na fase de projeto em
código executável. sistemas e a instrumentação de sistemas em
 Pode envolver reutilização de componentes, bibliotecas de classes, execução.
etc para agilizar a atividade.

11 12

UML Arquitetura da UML

O desenvolvimento de um sistema de software complexo demanda
que seus desenvolvedores tenham a possibilidade de examinar e
É uma linguagem para documentação: estudar o mesmo a partir de diversas perspectivas.
 Requisitos.
 Arquitetura. Os autores da UML sugerem que um sistema pode ser descrito por
cinco visões interdependentes desse sistema:
 Projeto.
 Código-fonte.
 Planos de projeto. Visão de Visão de
 Testes. projeto implementação
 Protótipos.
Visão de
 Versões.
Casos de Uso
Visão de Visão de
 Comunicação entre equipes nas diferentes fases do implantação
ciclo de vida. processo

3
 10/03/2011

13 14

Arquitetura UML Arquitetura UML

Visão de Casos de Uso: Descreve o
comportamento do sistema do ponto de vista das
interações entre este e os agentes externos ao
sistema. Essa visão é criada inicialmente e norteia o
desenvolvimento das outras visões do sistema.
Visão de projeto: Enfatiza as características do
sistema que dão suporte, tanto estrutural quanto
comportamental, às funcionalidades externamente
visíveis do sistema.
Visão de processo: Threads e os processos. Cuida de
mecanismos de concorrência e sincronismo. Foco nas
questões de desempenho e escalabilidade.
Visão de implementação: Componentes e arquivos.
Gerenciamento de versões do sistema construídas pelo
agrupamento de módulos (componentes) e
subsistemas.
Visão de implantação: Corresponde à distribuição
física do sistema em termos de seus subsistemas e à
conexão entre essas partes.

15 16

UML
UML  Diagramas Estruturais: de Implementação:
A UML 2.0 conta com 13 diagramas que  Diagrama de componentes.
Diagrama de implantação.
permitem que se construa modelos de várias 

 Diagramas Comportamentais (Dinâmicos):

perspectivas do sistema.
 Diagrama de casos de uso.
 Diagramas Estruturais (ou Estáticos):  Diagrama de transições de estados.
 Diagrama de classes.  Diagrama de atividades.
 Diagrama de objetos.  Diagramas Comportamentais (Dinâmicos): de
 Diagrama de pacotes. Interação:
 Diagrama de estrutura composta. (2.0)  Diagrama de seqüência.
 Diagrama de colaboração.
 Diagrama de visão geral da interação. (2.0)
 Diagrama de temporização. (2.0)

4
 10/03/2011

17

UML

Diagrama de Casos de Uso

19 20

Diagrama de Casos de Uso Diagrama de Casos de Uso

• MAS extremamente importante ...
• O diagrama de CASOS DE USO procura, por meio de uma
linguagem simples, possibilitar a compreensão do
comportamento externo do sistema por qualquer pessoa, através
da perspectiva do usuário ...
• Mapeamento dos REQUISITOS
• Base para os demais diagramas da UML
• Diagrama mais ABSTRATO
• Diagrama mais FLEXÍVEL
• Diagrama mais INFORMAL

5
 10/03/2011

21 22

Componentes principais
Diagrama de Casos de Uso

Objetivos – Funções

• Apresentar uma visão externa geral das funções e

serviços que o sistema deverá oferecer aos usuários

• Sem se preocupar com o COMO

• Tenta identificar os tipos de usuários que irão interagir

com o sistema,
• quais os papéis que estes usuários irão assumir e
• quais funções serão requisitas por cada usuário
específico

23 24

Atores – Representação
Atores
• Representam os papéis desempenhados pelos diversos
usuários que poderão utilizar de alguma maneira os
serviços e funções do sistema

• Normalmente PESSOAS

• Eventualmente  HARDWARE – SOFTWARE que

interajam com o sistema

6
 10/03/2011

25 26

Casos de Uso Documentação

• Referem-se aos serviços, tarefas ou funções que
podem ser utilizados pelos usuários do sistema
• Utilizados para expressar/documentar os
comportamentos pretendidos para as funções do
sistema
• Descrever, através de uma linguagem simples, a função
em linhas gerais do caso de uso, quais atores interagem
com o mesmo, quais etapas devem ser executadas pelo
ator e pelo sistema, quais parâmetros devem ser
fornecidos e quais as restrições/validações o caso de uso
deve possuir

• UML não tem formato oficial/específico

27 28

Associações
Diagrama de Casos de Uso
• Representam INTERAÇÕES/RELACIONAMENTOS
entre:
• ATORES
• ATORES e CASOS DE USO
• CASOS DE USO e CASOS DE USO

• Relacionamentos entre CASOS DE USO:

• COMUNICAÇÃO
• INCLUSÃO
• EXTENSÃO
• GENERALIZAÇÃO

7
 10/03/2011

29 30

ASSOCIAÇÕES - Comunicação
Associações – Comunicação ATOR  CASO DE USO

• ATOR  CASO DE USO

• Demonstra que o ator utiliza-se da função do sistema

representada pelo caso de uso – requisitando a
execução, recebendo o resultado produzido

31 32

Associações ESPECIALIZAÇÃO/GENERALIZAÇÃO

ESPECIALIZAÇÃO/GENERALIZAÇÃO

• Associação entre Casos de Uso com características

semelhantes

• A estrutura de um Caso de Uso generalizado é herdada

pelos Casos de Usos especializados

8
 10/03/2011

33 34

ESPECIALIZAÇÃO/GENERALIZAÇÃO ESPECIALIZAÇÃO/GENERALIZAÇÃO

• Relacionamento de generalização é relação estrutural

de um caso de uso mais geral para um caso de uso mais
específico
▫ Caso de Uso mais geral: representa o caso de uso genérico, cujo
o serviço se aplica a várias situações
▫ Caso de Uso mais específico: representa a aplicação do caso de
uso mais geral em uma situação particular

• Caso de Uso mais geral representa partes comuns de

casos de usos mais específicos.

35 36

ESPECIALIZAÇÃO/GENERALIZAÇÃO Associações

INCLUSÃO

• Usada quando existe um serviço, situação ou rotina comum

a mais de um Caso de Uso
• Notação
▫ Ligação de dois Casos de Uso através de um segmento de
reta e a colocação de um triângulo na extremidade do • Outros Casos de Uso utilizam-se de um Caso de Uso
Caso de Uso mais geral. “Chamada de Sub-Rotina”

• Generalização implica a incorporação (herança) dentro • Linha tracejada com texto “<<Include>>”
do caso de uso especializado de todo o serviço especificado
no caso de uso geral.

9
 10/03/2011

37 38

ASSOCIAÇÕES - INCLUSÃO
INCLUSÃO
• Um caso de uso insere em seu interior um outro caso de uso

• O caso de uso incluso ou sub-caso não representa um

serviço completo

• Isoladamente, um subcaso não teria sentido

• Aplicação deste tipo de relacionamento:

▫ Detalhamento do caso de uso através da decomposição
▫ Colocar em evidência partes comuns a dois ou mais casos
de uso.

39 40

INCLUSÃO
Associações
EXTENSÃO

• Descrever cenários opcionais de um Caso de Uso

• Descrevem cenários que somente ocorrerão em uma

situação específica – se uma determinada condição for
satisfeita

• A extensão significa que o caso de uso que estende inclui

serviços especiais de um caso de uso maior

• Necessidade de especificação de uma condição

• Linha tracejada com texto “<<Extend>>”

10
 10/03/2011

41 42

Diagrama de Casos de Uso ASSOCIAÇÕES - EXTENSÃO

ASSOCIAÇÕES - EXTENSÃO

43 44

NOTAS
INCLUSÃO x EXTENSÃO
• Utilizadas para apresentar texto explicativo
• A diferença principal entre relacionamento de inclusão e
extensão é o caráter de “excepcionalidade” da extensão

• Extensões são utilizadas para modelar Casos de Usos

especiais e de exceções que ocorrem somente em certas
situações (dado pela condição).

11
 10/03/2011

45 Exercício 1 complete os Use Cases abaixo: 46

EXERCICIOS
Analisar Riscos

Avaliar o Negócio
Analista Fechar Preço
Comercial

Registrar Negócio

Negócio com
Vendedor
Limites Excedidos

Exercício 2: complete os Use Cases abaixo: 47 Resolução Exercício 1 48

Solicitar histórico do Analisar Riscos <<include>>

Solicitar semestre atual
Histórico
Avaliar o Negócio

Estudante Analista Fechar Preço

Fechar Preço <<include>>
Solicitar histórico de
Sistema todos os semestres Comercial
de Controle de
Pré-Requisitos

Registrar Negócio
Registrar Negócio
Matricular
aluno Generalização
Verificar
dependências Negócio com Vendedor
Limites Excedidos
Secretária

12
 10/03/2011

Resolução Exercício 2 49 50

Exercicio 3 - Estudo de caso

<<include>>

Solicitar histórico do
Solicitar semestre atual
Histórico
• Vídeo-locadora ROCKET-VIDEO
<<include>>
• Especializada em vídeos para treinamento
Solicitar histórico de Estudante empresarial
Sistema
de Controle de
todos os semestres • Locação, devolução e reserva de fitas
Pré-Requisitos • Funcionário atende no balcão
• Gerente recebe posição financeira diariamente
Matricular
<<include>> aluno
Verificar
dependências

Secretária

51 52

Objetivos do Sistema Locação de Fitas - Roteiro

01.Cliente informa sua Identificação ao Atendente.

02.Cliente informa Fitas a devolver ao Atendente.
• Locação 03.Atendente registra a devolução.
• Devolução 04.Cliente informa Fitas a locar ao Atendente.
05.Atendente verifica existencia de Reserva.
• Reserva 06.Atendente registra a locação.
• Emissão de relatórios gerenciais 07.Atendente informa ao Cliente o valor da locação.
08.Cliente efetua o pagamento.
09.Atendente fornece boleto ao Cliente.
10.Cliente assina o boleto.
11.Cliente sai da loja com as fitas.
12 Ao final do mês o Atendente retira um extrato da
situação do Cliente. ATORES
Atendente

13
 10/03/2011

53 54

Diagrama de Caso de Uso

Exemplo
Pesquisar Reserva
Registrar Locação • Sistema de controle acadêmico.
CASOS DE USO
• Modelagem em 4 fases:
Pesquisar Reserva
Registrar Reserva Registrar Devolução ▫ Levantamento dos atores;
Atendente
Registrar Locação ▫ Levantamento dos casos de usos principais;
Registrar Pagamento ▫ Definição dos relacionamentos;
Pesquisar Cliente
Registrar Pagamento Gerar Relatórios
▫ Detalhamento dos Casos de Uso.
ATORES
Emitir Relatório
Atendente

55

Exemplo – Sistema de Controle Acadêmico

• No sistema de controle acadêmico, chefe da secretaria, secretária e professores
desejam que o sistema ofereça os seguintes serviços:
▫ Possibilidade de cadastramento de todos os alunos matriculados no curso.
 Inclusão de novos alunos e manutenção na base de dados.
• Possibilidade de cadastramento de todos os professores que ministram
disciplina no curso.
▫ Serviço de inclusão de professores.
▫ Manutenção da base de dados.
• Possibilidade de registro das disciplinas oferecidas no curso.
▫ Registro de novas disciplinas.
▫ Manutenção na base de dados.
• Possibilidade de registro da matrícula de alunos em disciplinas a cada semestre.
• Possibilidade de emissão da confirmação de matrícula para cada aluno,
contendo a lista de disciplinas que o aluno se matriculou no semestre.
• Possibilidade de emissão do diário de classe para cada disciplina, contendo a
lista de alunos matriculados naquele semestre.
• Possibilidade de lançamento das notas obtidas pelos alunos em cada disciplina.
• Possibilidade de emissão do histórico escolar para cada aluno, contendo a lista
de disciplinas cursadas e respectivas notas.
• Utilização de um sistema de gerenciamento de banco de dados (SGDB) para
armazenamento das informações; O SGBD é um sistema computacional
independente. O sistema de controle acadêmico irá interagir com o SGBD.

14