Introdução à UML com Casos de Uso

1

Introdução à Introdução à UML com Casos de UsoUML com Casos de Uso

Prof. Rodrigo Gomes

2

Apresentação

• Formação:– Certificação IBM RMUC – Requirements Management with Use Cases– Especialista em Design Instrucional para EaD Virtual (UNIFEI)– Especialista em Docência do Ensino Superior (FINOM)– Bacharel em Sistemas de Informação (UEMG)– Técnico em Processamento de Dados (CETEV)

• Atualmente:– Analista de Requisitos na IBM do Brasil - SP– Professor Universitário – UNIS-MG

• Atuações Anteriores– Professor Universitário – FACECA– Professor Universitário – UNINCOR– Professor Universitário – FIPV– Analista de Sistemas – Sindicato Rural da Campanha– Gerente de TI – Santa Casa de Misericórdia da Campanha

Rodrigo Gomes da Silva

Contatos:[email protected]

[email protected]

[email protected] Redes Sociaishttp://www.linkedin.com/pub/rodrigo-gomes-da-silva/37/568/716https://twitter.com/rodrigogomes3https://www.facebook.com/rodrigo.gomesdasilva.92

http://www.linkedin.com/pub/rodrigo-gomes-da-silva/37/568/716

https://twitter.com/rodrigogomes3

https://www.facebook.com/rodrigo.gomesdasilva.92

3

Apresentação

• Quem é você?– Nome

– Período

– Contatos com UML e levantamento de requisitos

– Atuação na área de TI

4

• O que é UML?– Uma linguagem ou notação de diagramas para

especificar, visualizar e documentar modelos de software

– Não é um método de desenvolvimento

– Não indica o que fazer primeiro

– Ajuda a visualizar o produto e a comunicação

– É formada por elementos que são usados para criar diagramas, que representam uma determinada parte do sistema, ou um ponto de vista do sistema

UML

5

• Para que usar UML?– Pensar antes de codificar– Apresentar nossas ideias ao grupo– Aumentar a participação e envolvimento do time– Documentar as ideias quando já consolidadas– Atender aos requisitos– Reduzir esforço de manutenção– Facilitar a alteração do software– Reduzir re-trabalho: reparos ocorrem a nível de projeto– Gestão do conhecimento: consolidar o projeto na empresa

e não nas pessoas

UML

6

• Importância do Projeto de Software

Ponte Rio – Niterói:• Comprimento: 13,29 Km• Tráfego: 140 mil veículos / dia• Construção: 01/1969 – 03/74

UML

7

• Linha de Produção

Assim como as pontes, o software não pode ser feito por meio de linhas de produção

Após a implementação eu posso copiá-lo e distribuí-lo

UML

8

• Falta de Alinhamento entre cliente, analista e time

UML

9

UML

10

• A culpa não é minha!

Processo de desenvolvimento de software

Caos

Frustração

Retrabalho

Desperdício de tempo e recursos

UML

11

• Aprovação do Cliente

Processo de desenvolvimento de software

Investigação

Aprovação

Comunicação

ContratosO que é preciso?

UML

12

• Modelagem

UML

13

• Complexidade

Para dominarmos uma realidade com a abordagem sistêmica, precisamos de modelos, o que favorece a possibilidade de fazermos simulações, facilitando assim a definição de soluções para os problemas existentes na realidade em questão.

UML

14

• Motivação

Necessidade de uma Modelagem Visual

Da mesma forma que, para construir uma casa é preciso desenhar sua planta, para construir um software, é preciso desenhar sua arquitetura.

É preciso ter uma representação visual do seu sistema, antes que ele entre na etapa de implementação.

UML

15

• Motivação


É preciso estabelecer uma padronização para facilitar a comunicação entre os analistas e o time de desenvolvimento.

E facilitar a comunicação entre os analistas e o cliente.

UML

16

• Motivação


Um sistema tem geralmente muitas classes. Dependendo do nível hierárquico da pessoa envolvida, formas diferentes de apresentar as classes devem ser geradas.

• O cliente precisa compreender apenas alguns conceitos;

• O gerente de projetos não precisa de detalhes do modelo;

• O time de desenvolvimento precisa de todos os detalhes possíveis.

UML

17

• Motivação


Um modelo deve ser criado independente de sua implementação. A qualquer momento uma implementação pode ser trocada por outra, sem afetar o modelo.

UML

18

• Motivação

UML

•UML é uma ferramenta que nos auxilia na modelagem de sistemas;•Mantida pela OMG•Proporciona um padrão para o projeto de arquitetura de sistemas• Composta por 13 diagramas

UML

19

• Alguns Diagramas da UML?– Estrutura Estática:

• Diagrama de Classes• Diagrama de Objetos• Diagrama de Componentes• Diagrama de Implantação

– Estrutura Dinâmica• Diagrama de Casos de Uso• Siagrama de Sequencia• Diagrama de Atividades• Diagrama de Estados• Diagrama de Colaboração

UML

20

• Alguns Diagramas da UML?– Estrutura Estática

• Diagrama de Classes• Diagrama de Objetos• Diagrama de Componentes• Diagrama de Implantação

– Estrutura Dinâmica• Diagrama de Casos de Uso• Siagrama de Sequencia• Diagrama de Atividades• Diagrama de Estados• Diagrama de Colaboração

Foco deste treinamento

UML

21

• Diagramas da UML

•Qual eu devo utilizar primeiro?• Não existe ordem pré-definida• Não existe a necessidade de utilização de todos os diagramas

UML

22

• Características da UML

•Independente da linguagem de desenvolvimento•Alguns diagramas podem modelar software orientados a objetos ou não•Define uma linguagem formal para a modelagem e não para a implementação

UML

23

• O que é o Modelo de Caso de Uso?– Um link entre necessidades dos stakeholders e

requisitos do software– Define o limite do sistema– Captura e comunica comportamento do sistema– Identifica quem ou o quê interage com o sistema– Valida e verifica requisitos

O Modelo de Caso de Uso

24

• O que é o Modelo de Caso de Uso?– É representado por um modelo gráfico, o

Diagrama de Casos de Uso– É especificado em um modelo textual, o

Documento de Especificação de Caso de Uso Processo iterativo envolvendo discussões

entre técnicos, clientes e usuários finais para o levantamento e detalhamento dos requisitos funcionais.


25

• O que é o Modelo de Caso de Uso?• Um Modelo de Caso de Uso descreve os requisitos

funcionais de um Sistema.

• Um Modelo de Caso de Uso associa as necessidades dos stakeholders aos requisitos de software do sistema.

• Por ser um instrumento de planejamento muito forte, o Modelo de Casos de Uso é geralmente utilizado em todas as Fases do Ciclo de Desenvolvimento por todos os membros da equipe.

funcionais.


26

• Diagrama de Caso de Uso?– Auxilia a comunicação entre os

analistas e os clientes.– Descreve um cenário que mostra as

funcionalidades do sistema, do ponto de vista do usuário.

– O cliente deve ver no diagrama de Caso de Uso as principais funcionalidades do sistema.


27

• Diagrama de Caso de Uso?• Descreve o sistema, seu ambiente e a

relação entre os dois. • Os casos de uso são usados para obter os

requisitos do sistema a partir da perspectiva do usuário.


28

Antes de detalharmos o diagrama de Caso de Uso vamos falar um

pouco sobre requisitos


29


30

Needs: Necessidades (dos stakeholders / do negócio)

Qual é a necessidade do negócio?

Qual é a necessidade dos Stakeholders

Features: Características do Sistema

Serviços que o sistema irá oferecer que permitirão atender as necessidades do negócio e as necessidades dos stakeholders

Requisitos

Uma capacidade de software que deve ser atendida ou possuída por um sistema ou componentes do sistema para satisfazer um contrato, padrão, especificação, ou outros documentos formalmente impostos


31


Needs(necessidades)

Features(serviços / características)

Requisitos

Requisitos Funcionais Requisitos Não Funcionais

32


• Requisitos Funcionais:

São requisitos diretamente ligados à funcionalidade do software, descrevem as funções que o software deve executar.

– [RF001] O sistema deve permitir o cadastro de clientes– [RF002] O sistema deve permitir a geração de relatório

de vendas por período

33


• Requisitos Não Funcionais:

Descrevem condições que o software deve atender ou qualidade específicas que o software deve ter.

– [RNF001] O software deve suportar o navegador IE 5.0 ou superior

– [RNF002] O software deve utilizar o banco de dados DB2

34


• Needs x Features x Requisitos:

– Needs descrevem o que o negócio precisa

– Features descrevem quais os serviços necessários para atender as Needs

– Requisitos descrevem como as Features serão atendidas

35


• Mapeamento

Ver planilha de mapeamento– Descrição do problema– Desejo dos Stakeholders– Needs– Needs x Features– Mapeamento Needs x Features x Requisitos

36

• Notação do Caso de Uso?

O diagrama de Caso de Uso é representado por:• Atores• Casos de uso• Relacionamentos

Os relacionamentos podem ser:• Associações• Generalizações• Extensões ou Inclusões


37

• Elementos do Caso de USO– Ator

• Um elemento que está fora do sistema

• De alguma forma e em algum momento ele interage com o sistema

• Pode ser um usuário, um equipamento ou outro sistema, desde que tenha interação com o sistema que está sendo modelado


38


• O ator não deve ser identificado pelo nome, por exemplo João, mas sim pelo papél que ele desempenha na aplicação:

• Ex de nomes de atores:– Gerente, Secretária, Professor,

Funcionário, Balconista, etc…


39


• O Ator não é parte do sistema• Ele age no ambiene do sistema• Interage ativamente com o sistema• Representa um ser humano, uma

máquina ou outro sistema


40

• Papél• Podemos definir um papel

considerando, por exemplo, o caso de múltiplos personagens representados por um ator numa peça de teatro.

• Neste caso, você como Ator poderia representar o papel de bandido ou de policial. O Ator representa um papel e não um usuário individual.


41

• Como identificar um Ator?• Onde, na organização, o Sistema é usado?

• Quem se beneficiará do uso do sistema?

• Quem fornecerá informações ao Sistema, usará essas informações e as removerá?

• Quem suportará e manterá o Sistema?

• O Sistema usa um recurso externo?

• Uma pessoa representa diversos papéis?

• Várias pessoas representam o mesmo papel?

• O Sistema interage com um Sistema Legado?


42


• Mapeamento

Ver planilha de mapeamento• Atores

43

• Elementos do Caso de USO– Caso de Uso

• Representado pela figura de uma elípse, identifica uma funcionalidade do sistema que gera valor para o Ator.

• O nome do caso de uso deve começar por um verbo de ação (fazer, realizar, registrar, etc…)

• Indica uma ação que o Ator pode realizar ao interagir com o sistema


44

• Elementos do Caso de USO– Caso de Uso

• Descrevem ações que entregam valor para o Ator

• Mostra as funcionalidades do sistema sendo utilizadas pelo Ator

• Modela um diálogo entre Ator e Sistema

• Representa o sistema em uma perspectiva do Ator.


45

• Como Identificar – Caso de Uso

• O que o ator necessita fazer?

• O Ator precisa ler, criar, excluir, modificar ou armazenar algum tipo de informação no Sistema?

• O trabalho diário do ator pode ser simplificado ou tornado mais eficiente através de novas funções no Sistema?

• O ator tem de ser notificado sobre os eventos no Sistema ou ainda notificar o sistema em si?

• Quais são as macros funções que o ator necessita do Sistema?


46


• Mapeamento

Ver planilha de mapeamento• Casos de Uso Identificados• Mapeamento UC x RF• Mapeamento UC x RF x AT

47


• Rastreabilidade

– Permite uma compreensão dos relacionamentos entre requisitos e seus artefatos

48


• Mapeamento

Ver planilha de mapeamento– Rastreabilidade Needs x Features– Rastreabilidade Features x Requisitos– Rastreabilidade RF x UC– Rastreabilidade Completa

49

• Relacionamentos

Relacionamentos entre Atores e Casos de Uso , entre Casos de Uso e Casos de Uso, e entre Atores e Atores.

Os principais relacionamentos são:• Associação; • Generalização;• <<Inclui>>• <<estende>>


50

• Relacionamentos

Associação entre Ator e Caso de Uso

Representamos uma associação entre um ator e um caso de uso por uma ligação simples.

Em determinado momento o ator “Cliente” poderá acionar a funcionalidade “Fazer Pedido”

Em determinado momento o ator “Cliente” poderá acionar a funcionalidade “Fazer Pedido”


Caso de Uso ConcretoSua execução é iniciada

através da chamada de um Ator

51

• Relacionamentos

Relacionamento <<include>> entre Casos de Uso

Um relacionamento de inclusão mostra a dependência entre dois casos de uso, o que significa que um caso de uso incorpora o comportamento de outro caso de uso.


Caso de Uso Abstrato

Sua execução é iniciada através da chamada de ouro

caso de uso

52

• Relacionamentos

Relacionamento <<extend>> entre Casos de Uso

Um relacionamento de extensão significa que um caso de pode ou não ser incorporado em outro caso de uso, mas a incorporação não é obrigatória.


53

• Relacionamentos

Relacionamento <<extend>> <<include>>


54

• Relacionamentos

Generalização entre Atores

Representa uma relação de herança entre atores.


55

• Relacionamentos

Generalização entre Atores


56


• Mapeamento

Ver planilha de mapeamento• Diagrama UC

57


• Tipos de Relacionamentos

Relacionamento Associação Inclusão Extensão Generalização

Ator X Ator XAtor X Caso de Uso XCaso de Uso X Caso de Uso X X X

58


• Prática– Divisão em 3 grupos– Cada grupo deverá montar a planilha contendo

• Needs • Features• Requisitos Funcionais• Atores• Casos de Uso

– Montar o Diagrama de Casos de Uso

– Cada grupo deverá escolher um dos sistemas abaixo:• Consulta online de exames laboratoriais• Venda online de passagens aéreas• Venda online de ingressos de shows

– Cada grupo deverá apresentar sua solução

59

• Para estudo


Glossário UML - UFMGhttp://homepages.dcc.ufmg.br/~amendes/GlossarioUML/

OMGhttp://omg.org/

UML Guia do UsuárioGrady Booch

UML 2 – Uma abordagem práticaGilleanes T A Guedes

Fundamentos do Desenho Orientado a ObjetoMeillir Page Jones

http://homepages.dcc.ufmg.br/~amendes/GlossarioUML/

http://omg.org/

http://omg.org/

Introdução à UML com Casos de Uso

Technology

Transcript of Introdução à UML com Casos de Uso