Este documento apresenta os fundamentos da Linguagem de Modelação Unificada (UML). Discute os elementos da UML como diagramas, casos de uso, atores e relacionamentos. Também descreve como os diagramas de casos de uso podem ser usados para modelar requisitos, incluindo cenários e relacionamentos.
2. FUNDAMENTOS DE UML
A Linguagem de Modelagem Unificada (Unified
Modelling Language - UML) é uma linguagem de
representação diagramática ou notação para
especificar, visualizar e documentar modelos de
sistemas de software Orientados à Objecto.
A UML não é um método de desenvolvimento, o que
significa que ela não diz para você o que fazer primeiro
e em seguida ou como desenhar seu sistema, mas ele
lhe auxilia a visualizar seu desenho e a comunicação
entre objectos.
A UML é controlada pelo Grupo de Gestão de Objecto
(Object Management Group - OMG) e é um padrão da
UML indústria para descrever graficamente software.
3. FUNDAMENTOS DE UML
A UML é voltada para o desenho de software Orientado à
Objecto e tem um uso limitado para outros paradigmas de
programação.
A UML é composta por muitos elementos de modelo que
representam as diferentes partes de um sistema de
software.
Os elementos UML são usados para criar diagramas, que
representam um determinada parte, ou um ponto de vista
do sistema.
Os seguintes tipos de diagramas são suportados:
Diagrama de Caso de Uso mostra actores (pessoas ou outros
usuários do sistema), casos de uso (os cenários onde eles usam o
sistema), e seus relacionamentos;
UML
Diagrama de Classe mostra classes e os relacionamentos entre elas;
4. FUNDAMENTOS DE UML
Diagrama de Sequência mostra objectos e uma sequência das
chamadas do método feitas para outros objectos;
Diagrama de Colaboração mostra objectos e seus relacionamentos,
colocando ênfase nos objectos que participam na troca de mensagens;
Diagrama de Estado mostra estados, mudanças de estado e eventos
num objecto ou uma parte do sistema;
Diagrama de Actividade mostra actividades e as mudanças de uma
actividade para outra com os eventos ocorridos em alguma parte do
sistema;
Diagrama de Componente mostra os componentes de programação
de alto nível (como KParts ou Java Beans);
UML Diagrama de Distribuição mostra as instâncias dos componentes e
seus relacionamentos.
6. Use Cases
• Os Uses Cases ou ”casos de utilização”
constituem em UML uma técnica para
representar o levantamento de requisitos do
sistema (Nunes, 2001)
• Desde sempre que o correcto levantamento de
requisitos no desenvolvimento de sistemas de
informação tenta garantir que o sistema será
útil para o utilizador final, estando de acordo
UML com as suas necessidades (Nunes, 2001:13)
7. Requisito
• O requisito num sistema é uma
funcionalidade ou característica
considerada relevante na óptica do
utilizador (Nunes, 2001).
UML
8. Requisitos
• Os requisitos podem ser classificados
em 3 categorias, de acordo com
Bennet (2003):
– Funcionais
– Não funcionais
– Facilidades de Utilização (Usability)
UML
9. Requisitos Funcionais
• Descrevem o que o sistema faz ou é
esperado que faça.
• Estes são os requisitos que inicialmente
serão levantados, abrangendo a
descrição de processamentos a efectuar
pelo sistema, entradas e saídas de
informação em papel ou em écran que
derivam da interacção com pessoas e
outros sistemas.
UML
10. Requisitos Não Funcionais
• Relacionados com as características qualitativas
do sistema, descrevendo a qualidade com que
o sistema deverá fornecer os requisitos
funcionais.
• Abrange medidas de desempenho como por
exemplo, tempos de resposta, volume de dados
ou considerações de segurança.
UML
11. Requisitos de Facilidade de
Utilização (Usability)
• Garantem que existirá uma boa ligação
entre o sistema desenvolvido,
utilizadores do sistema e também as
tarefas que desempenham utilizando o
sistema
UML
12. Diagrama de Use Case
• Os diagramas de Use Case são utilizados para
a apresentação de requisitos e para assegurar
que tanto o utilizador final como o
analista/desenvolvedor possuam um
entendimento comum dos requisitos.
• O seu objectivo é mostrar o que um sistema
deve efectuar e não como o vai fazer.
UML
13. Diagramas de Use Cases
• São usados para modelar o contexto de um
sistema, subsistema ou classe
• São uma das maneiras mais comuns de
documentar os requisitos do sistema
– Delimitam o Sistema
– Definem a funcionalidade do sistema
UML
14. Diagrama de Use Case
• Estes diagramas utilizam as seguintes
abstracções de modelação:
– Use Cases
– Actores
– Relações
• Uses
• Extends
• Generalização
UML
15. Use Case
• Um Use Case deve definir o uso de uma
parte da funcionalidade de um sistema,
sem relevar a estrutura e o
comportamento interno desse sistema
UML
16. Use Case
• Contém sequências de acções,
interagindo com os actores que usam a
aplicação
• Inclui variantes, rotinas de erro, etc. que
o sistema executa para produzir um
resultado observável para um actor
UML
17. Use Case: Representação
Gráfica
• A colecção dos use cases deverá especificar
todas as formas existentes de uso do sistema
Solicitar Verificar
Matricular estudante
histórico pré-requisitos
UML
18. Actores
• O sistema será descrito através de vários use
cases que são executados por um número de
actores.
• Um actor representa uma entidade externa
ao sistema que interage de alguma forma com
um Use case.
• Estes podem ser pessoas ou outros
subsistemas que interagem com o sistema em
UML desenvolvimento
19. Actores - Notação
Sistema de controle
de pre-requisitos
UML
Docente Secretária Estudante
20. Actores: Especialização
• É possível definir tipos gerais de actores e
especializá-los usando o relacionamento de
especialização
Cl ient e
UML
C li enteE s pec ial
21. Comunicação Actor – Use Case
• A representação da comunicação entre um
actor e os use cases pode ser uma simples
linha recta ou recta cujas pontas indicam a
direcção da comunicação:
• Linha Recta Simples
• Seta Unidireccional
É normal usarmos tanto a primeira como a segunda
alternativa. A primeira usa-se para casos mais simples,
UML
enquanto que a segunda para mais complexos.
22. Diagrama de Use Case
Gerar Relatório
Retornar Item
Cliente
Mudar Item Operador
UML
23. Organizando Use Cases
• Generalização
• Inclusão - <<uses>> ou
<<includes>>
• Extensão - <<extends>>
UML
24. Relação de <<uses>>
• Os use cases podem estar relacionados
entre si.
• <<Uses>> significa que um
determinado use case utiliza a
funcionalidade disponibilizada num outro
use case.
• Alguns autores utilizam a relação
<<includes>> em vez de <<uses>>
UML
25. Relação de <<extends>>
• A relação <<extends>> ocorre
quando existe um comportamento
opcional que deve ser incluído num
use case. Este comportamento é
definido num segundo use case e
invocado pelo use case base, através
de um mecanismo de pontos de
extensão.
UML
26. Generalização
• A relação de generalização é utilizada
quando existe um use case particular de
um outro use case.
• A generalização usufrui das mesmas
propriedades que uma relação pai/filho,
onde o use case “filho” herda ou
substitui por completo o comportamento
do use case “pai”
UML
27. Estruturação Use Case
Fazer Pedido
Pontos de extensão Fazer Pedido Urgente
set prioridade <<extends>>
<<include>> Verificar
é-um senha
Validar
usuário é-um
Teste de
retina
Use Case Fazer Pedido
Fluxo principal de eventos: inclui (Validar usuário). Receber do usuário os
UML itens do pedido. (set prioridade). Submeter o pedido para processamento
28. Comparação entre Relacionamentos
• A vantagem comum dos relacionamentos de
inclusão, extensão e generalização é que eles
possibilitam manter a descrição dos use cases
o mais simples possível.
• Porém, não se recomenda o uso em excesso
destes relacionamentos, sob o risco de se
obter um modelo de use case com vários
relacionamentos e de difícil entendimento.
UML
29. Comparação entre Relacionamentos
• Uma dúvida comum é saber que tipo de
relacionamento utilizar numa dada
situação. Na verdade, não existem regras
para saber quando utilizar um ou outro
relacionamento; existem somente
heurísticas:
– Use inclusão quando o mesmo
comportamento se repete em mais de um
use case. Esse comportamento deve ser
definido num novo use case, o chamado
include use case.
UML
30. Comparação entre Relacionamentos
– Use extensão quando o comportamento opcional
de um caso de uso tiver de ser descrito. Note que
alguns cenários estendidos podem não usar esse
comportamento opcional. O extensor faz referência
ao estendido; o estendido não sabe que o extensor
existe.
– Use herança quando quiser identificar 2 casos de
uso com comportamento semelhante e um deles
for uma forma especial do outro. O caso de uso
mais específico herda todo comportamento e
relacionamento mais genérico, porém pode
adicionar mais comportamento e ter seus próprios
relacionamentos. O específico faz referência ao
UML
geral e o geral não sabe que ele existe.
31. Diagramas de Use Cases
Solicitar <<extends>> Solicitar histórico do
histórico semestre atual
<<extends>>
Solicitar histórico de
todos os semestres
Estudante
Sistema de controle Matricular
<<includes>>
de pré-requisitos aluno
Verificar
dependências
Secretária
UML
32. Cenários
• Cada use case identificado deve ser detalhado
em termos de cenários de utilização.
• Estes cenários são os possíveis caminhos
seguidos dentro do use case, de forma a
fornecer ao actor uma resposta (Sheneider e
Winters, 1999)
UML
33. Cenários
• Um Cenário é uma execução específica de um use
case; pode ser visto como uma instância de um use
case.
• Para cada use case podem existir diversos cenários
• Estes cenários podem estar representados de 2 formas:
• Forma Descritiva – descrição dos cenários usando um
texto livre
• Forma Estruturada – conjunto de passos numerados.
Não existe uma estrutura padrão para esta forma,
encontrando-se diversas formas diferentes de acordo
com cada autor.
• Esta descrição deve incluir todos os detalhes
encontrados na análise (actores, dados, processo) de
UML forma a aumentar a informação disponível
34. Descrição Estruturada
Use case:
Actor:
Pré-
Condição:
Descrição:
Variações:
Pós-
Condição:
UML Descrição Estruturada de acordo com Larman (2001)
35. Exemplo de Descrição Estruturada
Use case: Registar Inscrição
Actor: Estudante, Secretaria
Pré-Condição: Estudante está identificado pelo sistema
Estudante requer inscrição
Descrição: 1 – Estudante/secretaria solicita a realização da
inscrição
2 – o sistema apresenta as disciplinas disponiveis
para o semestre corrente
3 – o estudante/secretaria selecciona as disciplinas
pretendidas e as submte-as para a inscrição
4 – O sistema valida a informação
5 – O sistema envia os dados do estudante para o
sistema de facturação e envia mensagem de
sucesso
Variações: 4.1 – Informação Correcta
4.2 – Informação Incorrecta
4.3 – Informação Incompleta
UML
Pós-Condição: Estudante inscrito ou Mensagem de Erro
36. Exercicios
• Considerando o sistema de registo académico do Ustm,
descreva de forma estruturada o use case responsável pela
inscrição de um estudante e o que regista um estudante no
sistema e faca o diagrama de use case correspondente.
• Suponha que existe um caso de uso Pagar Pedido num
sistema, que é realizado por um actor Cliente. Neste caso de
uso, o cliente realiza o pagamento de um pedido em algum
momento do passado. Considerando este caso de uso,
poderá pensar em algum outro caso de uso para este
sistema?
UML
37. Bibliografia
• Bennett, S. et all (2002) object-oriented systems
analysis and design using uml, U.S., Mc Graw-Hill
Education
• Bezerra, E. (2003), Princípios de Análise e Projecto de
Sistemas com UML, Rio de Janeiro, Editora Campus Ltda
• Neto, A.C. (2001), Análise e Projeto de Sistemas I,
http://www.dcce.ufs.br
• Nunes, M. e O´Neill (2001), Fundamental de UML,
Lisboa, FCA - Editora de Informática
• Larman, C. (2001); Applying UML and Patterns: An
Introduction to Object-Oriented Analysis and Design and
the Unified Process, USA, Prentice Hall PTR – 2ª Edição
• Shneider, G. e winters, J. P. (1999), Applying Use Cases
– A pratical guide, Addison Wesley
UML