Análise e Projeto de Sistemas
Prof. Ms. Ângelo Lemos Vidal de Negreiros
Boch, Jacobson, Rumbaugh; UML –
Guia do Usuário; Editora: Elsevier;
Ano: 2006
Martin Fowler; UML Essencial; Editora:
Bookman; Ano: 2004
2 Fernando Pedrosa Lopes
Linguagem de Modelagem Unificada
Linguagem
◦
Usada para expressar e comunicar idéias
◦
Não é uma metodologia!
Modelagem
◦
Descrever um sistema em um alto nível de
abstração
Unificada
◦
UML se tornou o padrão mundial para
modelagem de sistemas –
www.omg.org
3 Fernando Pedrosa Lopes
Linguagem gráfica para especificar,
visualizar, construir e documentar os
artefatos de software
Vantagens
◦
Usa notação gráfica: mais clara que a
linguagem natural (imprecisa) e código
(muito detalhado)
◦
Ajuda a obter uma visão geral do sistema
◦
Não é dependente de tecnologia
◦
Diminui a fragmentação, aumenta a
padronização
4 Fernando Pedrosa Lopes
5 Fernando Pedrosa Lopes
1997: UML 1.0, 1.1 1996: UML 0.9 & 0.91 1995: Unified Method 0.8
Outros
métodos Booch (OOAD) OMT (Rumbaugh)
Ano Versão
2011: UML 2.4 2010: UML 2.3 2009: UML 2.2 2003: UML 2.0 2001: UML 1.4 1999: UML 1.3 OOSE (Jacobson) Industrialização Padronização Unificação FragmentaçãoSão diagramas sem noção de tempo. São válidos independente do momento em que acontecem. Diagramas estruturais = diagramas estáticos * Diagramas comportamentais = Diagramas dinâmicos. * Considera a natureza
dinâmica. Coloca o software para rodar e verifica como os processos, objetos, estados trocam entre si.
* Considera o tempo.
Interação (subdivisão)
- Considera objetos e seus relacionamentos; e as
mensagens que são despachadas entre os objetos.
- Interação entre os objetos (é o que tem a mais com
relação aos comportamentais puro)
Diagramas estruturais
◦
Mostram a estrutura estática do sistema e
suas partes em diferentes níveis de
abstração e como elas se relacionam
◦
Não utilizam conceitos relacionados ao
tempo
Diagramas comportamentais
◦
Mostram a natureza dinâmica dos objetos
do sistema, que pode ser descrita como
uma série de mudanças no sistema com o
passar do tempo
7 Fernando Pedrosa Lopes
(Governo do ES - CESPE 2009)
[78] UML é um método para desenvolvimento de software que foi proposto para ser aplicado à análise e projeto de software orientados a objetos.
(EMBASA – CESPE 2009)
[94] Os diagramas em UML podem ser estáticos ou dinâmicos. O diagrama de classes é um exemplo de um diagrama dinâmico. (SERPRO – CESPE 2008)
[101] UML (universal modelling language) é uma linguagem de
modelagem proprietária que pode ser utilizada no desenvolvimento de sistemas de maneira intuitiva para visualização de objetos.
8 Fernando Pedrosa Lopes
(CGU - ESAF 2008)
[31] - A linguagem de Modelagem Unificada (UML) emergiu como notação de diagramação de padrão, de fato e de direito, para a modelagem orientada a objetos. Desta forma, a sentença que conceitua apropriadamente a UML, segundo o OMG-Object Management Group, é
a) um método para especificar e modelar os artefatos dos sistemas. b) um processo de especificação e modelagem de sistemas
orientados a objeto.
c) uma linguagem para implementar os conceitos da orientação a objetos.
d) uma linguagem visual para especificar, construir e documentar os artefatos dos sistemas.
e) um método comum para a representação da orientação a objetos.
9 Fernando Pedrosa Lopes
Modelagem UML (Linguagem de Modelagem
Unificada)
◦ Usada para expressar e comunicar ideias.
◦ Alto nível de abstração
◦ Linguagem gráfica para especificar, visualizar, construir e documentar os artefatos de software
Vantagens
◦ Usa notação gráfica: mais clara que a linguagem natural (imprecisa) e código (muito detalhado)
◦ Ajuda a obter uma visão geral do sistema
◦ Não é dependente de tecnologia
Modelagem UML
◦ Represente uma casa com:
4 quartos, sendo duas suites 1 banheiro
Sala em L
1 cozinha com área de serviço Janela tamanho grande
...
◦ Como demonstrar isso para que cliente possa visualizar melhor?
Modelagem UML
◦ https://www.youtube.com/watch?v=GiIHUMkuG-Y
(maior)
Desenvolvidos por I. Jacobson, são parte
integrante da UML
São descrições textuais das funcionalidades
do sistema a partir da perspectiva do usuário
Usados para mostrar quais funcionalidades o
sistema oferece e que usuários se comunicam
com ele
É o conjunto de sequencias de ações do
usuário no sistema que irá gerar valor ao
cliente, observável por este.
Identifica normalmente uma funcionalidade
do sistema
Visa a perspectiva externa.
Não se preocupa com detalhes internos.
O "como" não é realizado pelos casos de uso
◦ Ex. como é calculado um valor, um algoritmo, etc.
Especifica um conjunto de cenários.
◦ Sucessão de passos que pode finalizar em sucesso ou falha.
Cada possível linha de execução é chamada
Quem usa os casos de uso
◦
A
rquitetos
◦
Clientes e Usuários
◦
Analistas, Projetistas e Implementadores
◦
Testadores
◦
Gerentes
Diagramas de caso de uso
◦ Visão alto nível do sistema
◦ Visão resumida
◦ Servem para facilitar o entendimento de um sistema mostrando a sua “visão externa”
◦ São usados para modelar o contexto de um sistema ou um subsistema
◦ São uma das maneiras mais comuns de documentar requisitos do sistema
Delimitam o seu escopo
Diagramas de caso de uso
◦ Contém um conjunto de casos de uso e modela interações entre
Atores e o sistema O próprio sistema
◦ Cada caso de uso descreve um conjunto de cenários
◦ Captura os requisitos do usuário
Comportamento externo
O que fazer e não como fazer ◦ Delimita o escopo do sistema
Especificação do caso de uso
◦ Descreve o passo a passo da execução do sistema
◦ Descreve os cenários
◦ A ideia é a partir de cada elipse (um caso de uso) se descrever (ou especificar) este caso de uso. Ou seja, detalhar o seu passo a passo.
Pode conter diversos cenários de sucessos e erros.
◦ OBS. Não existe uma única forma de especificar os casos de uso.
Guias, seções e boas práticas podem existir, mas não é obrigatório seguir.
Especificação do caso de uso
◦
Nome: Fazer Pedido
◦
Descrição: Caso de uso que especifica o
fluxo de ações para o cliente fazer um
pedido no Sistema
◦
Atores: Cliente
Primário: Executa inicialmente o caso de uso
Secundário: Interage posteriormente.
◦
Pré Condição: O cliente deve estar logado
Fluxo principal de eventos
◦
P1. O caso de uso começa quando o cliente
seleciona a opção “Fazer Pedido”
◦
P2. O cliente fornece seu nome e endereço e
fornece o código do produto [EXT1]
◦
P3. O sistema fornece a descrição e o preço
do produto [INC1]
◦
P4. O cliente fornece as informações de
pagamento e escolhe a opção “confirmar”
[A1]
◦
P5. O sistema verifica as informações
fornecidas e envia os dados para o sistema de
pagamento [E1]
Observações
◦ Uso da palavra seleciona, e não da palavra clicar com mouse, ou escrever com o teclado, pois isso seria usar detalhes técnicos. E isso não é certo na descrição de caso de uso
◦ O ideal é a descrição da forma mais genérica possível, não “amarrando” detalhes de
Pontos de Extensão
◦ EXT1. O sistema estende o caso de uso “Pedido em oferta”
Pontos de Inclusão
◦ INC1. O sistema inclui o caso de uso “Dar informação do produto”
Fluxo alternativo
◦ Uso de opções para executar um passo. No caso, a opção confirmar ou poderia ser cancelar.
◦ Alternativo: pode ou não ocorrer
◦ Ex - A1. No passo P4 cliente seleciona a opção “cancelar”
A1.1 O sistema não grava o pedido e o fluxo retorna
Pontos de Extensão X Fluxo Alternativo
◦ Alternativo: a opção ocorre dentro do próprio (mesmo) caso de uso. É um comportamento opcional.
◦ Extensão: são passos que ocorrerão a partir de
outros casos de uso. Chama o uso de outro caso de uso. Também é um comportamento opcional.
Fluxo excepcional de eventos
◦
Ex. Informação errada do cartão de crédito.
◦
É um comportamento anômalo, ou seja, algo
incomum no sistema.
◦
E1. No passo P5 o sistema verifica que as
informações fornecidas estão incorretas
E1.1 O sistema pede ao cliente para corrigir as
informações e o fluxo retorna ao passo P4
Pós condições
◦
O pedido deve ter sido gravado no sistema e
marcado como confirmado
Casos de uso são executados por atores
Eles constituem as entidades externas do
ambiente do sistema
São papéis que os usuários do sistema devem
desempenhar nas interações
Uma “instância de ator” pode ser
desempenhada tanto por um indivíduo
quanto por um sistema ou mesmo por um
dispositivo
OBS. Atores representam papéis/perfis e não
Comunicação
◦ Comunicação simples e normal entre ator e caso de uso
Especialização
◦ É possível definir tipos gerais de atores e
especializá-los usando o relacionamento de especialização.
◦ Usado quando um ator (filho) é um tipo de outro autor mais genérico (pai)
Inclusão
◦ Um Caso de Uso base incorpora o comportamento de outro Caso de Uso
◦ O relacionamento é utilizado para evitar a descrição do mesmo fluxo de eventos várias vezes
Reaproveitamento (reutilização) de caso de uso Obrigatoriedade
Inclusão (DIREÇÃO DA SETA)
◦ OBS. Pesquisar pedido É INCLUÍDO em Cancelar pedido CERTO Cancelar pedido INCLUI Pesquisar pedido Direção da leitura
Inclusão (DIREÇÃO DA SETA)
◦ OBS. Cancelar pedido É INCLUÍDO em Pesquisar pedido ERRADO Pesquisar pedido INCLUI cancelar pedido Direção da leitura
Extensão
◦ Modela partes opcionais da execução de um Caso de Uso
◦ Modela fluxos que são executados somente em determinados casos, sob determinadas
circunstâncias ou que dependem de escolha de um ator
◦ Não obrigatoriedade
Ex. se o cliente estiver cadastrado, então o caso de uso “cadastrar cliente” não ocorrerá. (IF – ELSE)
Extensão
◦ OBS. Fazer pedido PODE SER ESTENDIDO
(COMPLETADO) pelo caso de uso Cadastrar cliente
CERTO Cadastrar cliente pode
estender (completar) o caso de uso Fazer
pedido
Extensão
◦ OBS. Cadastrar cliente PODE SER ESTENDIDO (COMPLETADO) pelo caso de uso Fazer pedido
ERRADO Fazer pedido pode
estender (completar) o caso de uso Cadastrar cliente Direção da leitura
Generalização de caso de uso
◦ Relaciona um Caso de Uso especializado a um mais geral
◦ O filho herda o comportamento do pai, podendo adicionar e redefinir passos em pontos arbitrários do comportamento original
◦ Tem tudo o que o pai tem e mais um pouco.
Em algum ponto pode-se redefinir um
Resumo
◦ Inclusão
Use quando o mesmo comportamento se repete em mais de
um Caso de Uso e o processo de realizar X sempre envolve realizar Y pelo menos uma vez
◦ Extensão
Use quando você quiser modelar um comportamento
opcional de um Caso de Uso
Sair de um caso de uso base e executar passos de outro caso
de uso
◦ Generalização de caso de uso
Use quando você identificar Casos de Uso semelhantes e um
deles for uma forma especial (uma especialização) do outro
◦ Generalização de atores
Use quando um ator (filho) é um tipo de outro ator mais
Possibilidade de relacionamento entre os
elementos do modelo de casos de uso
OBS. Pode existir multiplicidade no
relacionamento de caso de uso
OBS. Casos de uso tem a propriedade de
Concreto
◦ É iniciado por um ator e constitui um fluxo completo de eventos
◦ Autocontido
Abstrato: nunca é instanciado diretamente
◦ Casos de Uso abstratos
geralmente
são: Incluídos em outros Casos de Uso Estendidos de outros Casos de Uso
Generalizações de outros Casos de Uso ◦ Escritos em
itálicos
◦ Não apresentam fluxo completo
Atores “enxergam” apenas casos de uso
Casos de uso de sistema
◦ É a interação com o software em si.
Casos de uso de negócio
◦ Descreve como o negócio responde a um consumidor ou a um evento.
Caso de uso sucinto
◦ Descreve as interações sem muitos detalhes no momento da especificação
Caso de uso expandido
◦ Descreve as interações com mais detalhes
Caso de uso real
◦ Menciona a tecnologia que pode ser utilizada
Caso de uso essencial
◦ É mais genérico e abstrato e não faz menção a tecnologia a ser utilizada
1º método
◦ Identificar os atores relacionados a um sistema ou organização.
◦ Para cada ator, identificar os processos que eles iniciam ou dos quais eles participam.
2º método
◦ Identificar os eventos externos aos quais um sistema deve responder
O SUAP tem um módulo chamado EDU que
pode, por exemplo, cadastrar novas
disciplinas. O coordenador do curso é quem
poderá cadastrar a disciplina. A disciplina
terá que conter pelo menos o nome, e a
quantidade de créditos. No final do cadastro,
o sistema deve enviar um email de
Nome: Validar Usuário
Cenário Principal
◦ O caso de uso inicia-se quando o sistema apresenta uma tela que pede o cliente o seu cartão eletrônico. O cliente introduz o seu cartão magnético e, através de um pequeno teclado, a sua senha. O cliente
pode limpar a introdução da sua senha inúmeras vezes e reintroduzir um novo número antes de
pressionar o botão “Entrar”. O cliente ativa o botão “Entrar” para confirmar. O sistema lê a senha e a respectiva identificação do cartão, e verifica se é válido. Se a senha for válida o sistema aceita a entrada e o caso de uso termina.
Nome: Validar Usuário
Cenário Alternativo 1 (Cliente cancela operação)
◦ O cliente pode cancelar a transação em qualquer
momento ativando o botão “Cancelar”, implicando a re-inicialização do caso d e uso. Não é realizada qualquer alteração à conta do cliente.
Cenário Alternativo 2 (senha inválida)
◦ Se o cliente introduz uma senha inválida o cartão MB é ejetado e o caso de uso reinicializado. Se tal ocorrer 3 vezes consecutivas, o sistema aciona medidas de
segurança e “recolhe” o cartão e cancela a transação; não permitindo qualquer interação nos 2 minutos seguintes
1. Cliente chega a um Caixa com vários itens que
deseja comprar.
2. O caixa pode ou não cadastrar um novo cliente
[EX]
3. O Caixa começa a nova venda.
4.O Caixa registra o identificador de cada item. 5.Sistema registra o item vendido. Preço do item
e sua descrição são exibidos. Os passos 4 e 5 são repetidos, até que o Caixa indique o seu fim.
6.Sistema apresenta o total da venda.
7.Caixa informa Cliente do total e solicita pagamento
[I]
8.Cliente realiza o pagamento.
9.Caixa registra o valor recebido no caixa. 10.Um recibo é gerado.
Identificando os atores
◦
Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos para isto ele deve se dirigir à loja. A
loja possui um atendente cuja função é atender
os clientes durante a venda dos discos. A loja
também possui um gerente cuja função é
administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a venda dos discos.
Identificando os atores
◦
Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos para isto ele deve se dirigir à loja. A
loja possui um atendente
cuja função é atender
os clientes durante a venda dos discos. A loja
também possui um gerente
cuja função é
administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a venda dos discos.
Identificando os casos de uso
◦
Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos para isto ele deve se dirigir à loja. A
loja possui um atendente
cuja função é atender
os clientes durante a venda dos discos. A loja
também possui um gerente
cuja função é
administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a venda dos discos.
Identificando os casos de uso
◦
Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos para isto ele deve se dirigir à loja. A
loja possui um atendente
cuja função é atender
os clientes durante a
venda dos discos
. A loja
também possui um gerente
cuja função é
administrar o estoque
para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a
venda dos discos
.
Identificando os relacionamento de
associação
◦
Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos para isto ele deve se dirigir à loja. A
loja possui um atendente
cuja função é atender
os clientes durante a
venda dos discos
. A loja
também possui um gerente
cuja função é
administrar o estoque
para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a
venda dos discos
.
Identificando os relacionamento de
Identificando um caso de generalização entre
atores
◦ Nova regra de negócio
Identificando um caso de generalização entre
atores
◦ Nova regra de negócio
Identificando generalização de casos de uso
◦ Novos requisitos
As vendas podem ser tanto à vista como à prazo. Em ambos os casos, o estoque é atualizado e uma nota fiscal entregue ao consumidor.
No caso de uma venda à vista, clientes cadastrados na loja
e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.
No caso de uma venda a prazo, ela pode ser parcelada em
2 pagamentos com um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.
Identificando generalização de casos de uso
◦ OBS. Se for à prazo, pode-se pagar no cartão ou boleto.
Identificando generalização de casos de uso
◦ OBS. Se for à prazo, pode-se pagar no cartão ou boleto.
Identificando relação de dependência:
inclusão ou extensão
◦ No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro
◦ (...)Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista
◦ Onde tem a mesma informação?
Identificando relação de dependência:
inclusão ou extensão
◦ No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro
◦ (...)Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista
Identificando relação de dependência:
Identificando relação de dependência:
inclusão ou extensão
◦ Novos requisitos
Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema
Identificando relação de dependência: inclusão
ou extensão
◦ Novos requisitos
Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema
É tão importante quanto o diagrama
A UML não padroniza
Pode ser:
◦ Informal
◦ Típica
Informal
◦ Contém o nome do caso de uso e uma descrição textual de sua funcionalidade
Típica
◦ Identificação do ator que iniciou o caso de uso
◦ Pré-requisitos (se houver) do caso de uso
◦ Descrição textual do:
Fluxo normal
Detalhada
◦
Contém:
Nome Descrição sucinta Atores Pré-condições Pós-condições Fluxo básico Fluxos alternativos Fluxos de exceção Estruturas de dados Regras de negócio Observações
É um modelo completo das funções do sistema
em termos de Casos de Uso
Resultado de uma técnica de elicitação de
requisitos
A finalidade mais importante é comunicar, de
forma fácil de entender, o comportamento do
sistema ao usuário final
Agregação de artefatos de casos de uso. Contém:
◦ Casos de uso, Atores, Relacionamentos
◦ Pacotes de Caso de uso, Diagramas de Caso de Uso, Especificações, etc...
Casos de Uso são focados no usuário do
sistema, assim as reais necessidades são
tratadas logo cedo
São fáceis de entender
Facilitam o acordo entre todas as partes
interessadas
Pode ser usado no levantamento, elicitação e
validação dos requisitos, conectando todas as
etapas
◦ Elicitação: entendimento do problema.
Criar o diagrama de caso de uso e a descrição
de cada caso de uso para o sistema de blog
apresentado a seguir.
Um blog tem um título e uma data de criação
e além disso é um conjunto de conteúdos.
Estes conteúdos (mensagens) podem ser
notas ou comentários sobre as notas. Tanto
notas quanto comentários têm características
comuns como o texto e a data de sua criação.
Todo usuário possui:
◦ E-mail (deve ser único, ou seja, não há mais de um usuário com o mesmo e-mail)
Permitir a criação de blogs pelo seu dono
Permitir a utilização de blogs
◦ Qualquer usuário pode ler conteúdos
◦ Somente o dono do blog pode criar notas
◦ Qualquer usuário pode criar comentários. Para criar um comentário o usuários precisa ler as notas.
◦ Somente o dono do blog pode remover
comentários. Para remover um comentário ele precisará ler o comentário. Caso ele remova um comentário, o autor do comentário deve ser
notificado por e-mail.
◦ Somente o dono do blog pode remover qualquer conteúdo
