Upload
gustavo-bacala
View
196
Download
0
Embed Size (px)
Citation preview
Desenvolvimento de Software com UML 2006 1
Modelagem de Sistemas de Informação com
UML
Desenvolvimento de Software com UML 2006 2
Introdução
Modelos permitem descrever os requisitos de um sistema de informação de forma conveniente para usuários e implementadores
Modelos do negócio – a cargo de um analista de negócio Modelo de casos de uso de negócio – visão externa do
negócio, contexto do negócio
Modelo de processos de negócio – visão interna do negócio, com diagramas de atividades
Também é possível modelar: objetivos do negócio, regras do negócio, estrutura organizacional, ...
Desenvolvimento de Software com UML 2006 3
Introdução
Modelos do sistema – a cargo de um analista de sistemas
Modelo da arquitetura do sistema
nível lógico: módulos funcionais, comunicação com outros sistemas
nível físico: distribuição por máquinas, redes e sítios
Modelo de casos de uso – funcionalidades do sistema, requisitos funcionais
Modelo de domínio – informação manipulada pelo sistema (entidades informacionais, atributos e relações), requisitos de informação
Desenvolvimento de Software com UML 2006 4
Introdução
Complementar modelos com
Requisitos suplementares
lista de requisitos que não são descritos adequadamente pelos casos de uso
normalmente são requisitos não funcionais
requisitos de qualidade: desempenho, segurança, usabilidade e acessibilidade, disponibilidade e falibilidade,, etc.
requisitos impostos pelo ambiente operacional
etc.
Glossário – vocabulário do domínio
fundamental para evitar equívocos
Desenvolvimento de Software com UML 2006 5
Modelo da arquitetura do sistema
Só se justifica em sistemas complexos Decomposição em sub-sistemas, com indicação de dependências
entre sub-sistemas, e dependências em relação a sistemas externos (arquitetura lógica)
Cada sub-sistema corresponde a uma área funcional (grupo de funcionalidades), cobrindo todas as camadas da implementação (interface com o usuário, base de dados, etc.)
Os sub-sistemas podem por sua vez ser decompostos da mesma forma
Em UML, representar por diagrama de pacotes, com pacotes (packages) e sub-pacotes Possibilidade de indicar estereótipos «system» e «subsystem»
Em alternativa, representar por diagrama de blocos com ligações/fluxos entre blocos
Desenvolvimento de Software com UML 2006 6
Gestão de Cuidados de Saúde
Bloco OperatórioHospital de Dia
Urgência Consultas Internamento MCDT
Cuidados Comuns
Cuidados Diferenciados Cuidados Primários
Saúde Familiar Cuidados na
Comunidade
Saúde Pública
Só contactos individualizados
estarão registados no SIIMS
Exemplo: Sistema de Gestão de Cuidados de Saúde
sistema
sub-sistema
dependência
Desenvolvimento de Software com UML 2006 7
Modelo de casos de uso
Finalidade: mostrar a utilidade ou possíveis usos do sistema
Conteúdo: atores (tipos de usuários e sistemas externos que interagem com o sistema), casos de uso (funcionalidades do sistema tal como são vistas externamente, ou tipos de interações entre atores e o sistema) e relações entre ambos
Casos de uso capturam os requisitos funcionais e alguns não funcionais
Desenvolvimento de Software com UML 2006 8
Formas de modelo de casos de uso 1
Visão geral
Diagrama de casos de uso acompanhado de descrição textual que passa superficialmente pelos casos de uso e atores mais importantes
Desenvolvimento de Software com UML 2006 9
Autor-Submissor
Presidente do comité de programa
Revisor
Submeter Artigo
Sistema de Gestão de Conferências
Configurar sistema (dados
gerais da conferência, prazos,
temas e revisores)
Atribuir revisores
a artigos
Decidir aceitação ou
rejeição de artigos
Submeter versão
final de artigo
Obter artigos para
rever
Submeter revisões
Notificar revisores
«include»
Notificar
autor-submissor
«include»
Exemplo: Sistema de Gestão de Conferências
ator
fronteira do sistema
nome do sistema
caso de utilização
diagrama de casos de uso
Desenvolvimento de Software com UML 2006 10
Visão geral (cont.)
Se existirem muitos casos de uso, apresentar primeiro um diagrama de pacotes de casos de uso e depois um diagrama de casos de uso para cada pacote
Pacotes devem corresponder a sub-sistemas no modelo da arquitetura
Formas de modelo de casos de uso 2
Desenvolvimento de Software com UML 2006 11
Exemplo: Sistema de Gestão de Hotéis (CRM4SH) 1
CRM4SH
Cliente
Recepcionista
Gerente
Público
Aplicação de
Gestão
Site Web
diagrama de pacotes de casos de uso
Desenvolvimento de Software com UML 2006 12
CRM4SH - Site Web
Cliente
Público
Área para o público
Consultar características,
serviços, preços e
disponibilidades
Registar-se como
cliente
Área para clientes registados
Alterar dados
pessoais
Efectuar uma
reserva
Consultar as
reservas pendentes
Alterar ou anular
uma reserva
Enviar mensagem
para o hotel
Receber mensagens
do hotel
Responder a
mensagem do hotel«extend»
Consultar historial de
estadias, reservas e
mensagens
Gerente
CRM4SH - Aplicação de Gestão - Administração
Registar e actualizar
características gerais da
empresa
Registar e actualizar
serviços oferecidos e
preços
Registar empregados
com acesso ao sistema
Configuração
Registar e
actualizar quartos
Estatísticas
Obter estatística de
taxa de ocupação ao longo do
tempo
Obter estatística de
evolução da facturação ao longo
do tempo
Obter estatística de
distribuição das vendas por
nacionalidade
Obter estatística de
clientes com maior
facturação
diagramas de casos de uso
(com pacotes de 2º nível)
Exemplo: Sistema de Gestão de Hotéis (CRM4SH) 2
Desenvolvimento de Software com UML 2006 13
CRM4SH - Aplicação de Gestão - Recepção (1)
Gerente
Recepcionista
Registar novo
cliente
Alterar dados de
cliente
Gerente ou Recepcionista
Registo de Clientes
Registar reserva
de cliente
Alterar ou anular
reserva
Reservas
Estadias
Registar entrada
de cliente
Registar entrada de
cliente sem reserva
Registar entrada de
cliente com reservaAlterar data de
saída prevista
Efectuar mudança
de quarto
Registar saída de
clienteEmitir factura
«include»
CRM4SH - Aplicação de Gestão - Recepção (2)
Gerente ou Recepcionista
Gerente
Recepcionista
Consulta de ocupação
Consultar mapa de
ocupação
Consulta de informação de clientes
Consultar ficha e
historial de cliente
Mensagens e Contactos
Receber mensagens
de clientes
Enviar mensagem
para cliente
Responder a
mensagem de cliente«extend»
Registar outros
contactos com clientes
Exemplo: Sistema de Gestão de Hotéis (CRM4SH) 3
generalização de casos de uso
generalização de atores
Desenvolvimento de Software com UML 2006 14
Visão geral (cont.)
Opcionalmente, modelar através de um ou mais diagramas de atividades o encadeamento de casos de uso (i.e., modelar workflows ou processos de negócio)
casos de uso aparecem como atividades no diagrama de atividades
se tiver sido construído anteriormente um modelo de processos de negócio, isto já foi feito
Formas de modelo de casos de uso 3
Desenvolvimento de Software com UML 2006 15
RevisoresPC CharirAutor-submissor
Submete Artigo
Atribui revisores a artigo
Revêm artigo
Decide aceitação ou rejeição
Sumbete versão final
[artigo aceite]
[artigo rejeitado]
a1 : Artigo r : RevisorArtigo1..*
notação não standard tipo
“assembly line diagram”
Modelação do processo de submissão de um artigo desde a submissão até à
rejeição ou submissão de versão final, por diagrama de actividades em UML
Exemplo: Sistema de Gestão de Conferências 1
fluxo de controle
passos são execuções de casos de uso!
ator objetos de classes do modelo de domínio (ver adiante)
fluxo de objetos
[submetido]
[submetido]
Modelagem do processo de submissão de um artigo desde a submissão até a rejeição ou entrega da versão final, por diagrama de atividades em UML
Comissão
Desenvolvimento de Software com UML 2006 16
Revisor nRevisor 1
...Revê artigo Revê artigo
Decomposição da actividade "Revêm artigo"
barra de sincronização (inicia ou termina execução em paralelo)
Exemplo: Sistema de Gestão de Conferências 2
Decomposição da atividade “Rever Artigo”
Desenvolvimento de Software com UML 2006 17
Atores
Nome e breve descrição de cada ator
Casos de Uso
Descrição mais ou menos detalhada de cada caso de uso
Formas de modelo de casos de uso 4
Desenvolvimento de Software com UML 2006 18
Descrição detalhada de cada caso de uso
Nome Usar normalmente um verbo, evidenciando a
finalidade/objetivo/utilidade
Descrição sumária Uma ou duas frases curtas, que ficaria bem numa tabela de resumo
dos casos de uso, tornando evidente o objetivo/utilidade
Atores Indicar os vários atores intervenientes e o seu papel, tornando
evidente quem inicia a interação
Prioridade Indicar a prioridade do caso de uso (por exemplo, essencial,
importante e desejável) Convém considerar pelo menos 3 níveis de prioridade, para ter
flexibilidade suficiente na negociação de uma solução
Desenvolvimento de Software com UML 2006 19
Fluxo de eventos
Semelhante a instruções passo a passo no manual do usuário
Por definição, um caso de uo é "uma sequência de ações"
Descrever a seqüência de funcionamento normal ponto a ponto
Descrever separadamente sequências de funcionamento alternativos, por diferenças em relação à sequência normal
Indicar tanto as ações realizados pelos atores como as ações realizadas pelo sistema
Evidenciar os dados de entrada (introduzidos pelos atores) e os dados de saída (fornecidos pelo sistema)
Evidenciar como é que se inicia o caso de uso (normalmente indica-se pela primeira ação do actor)
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 20
Fluxo de evento principal Exemplo de sequência normal de funcionamento do
caso de uso "Vender bilhetes": 1. Um cliente dirige-se à bilheteria pedindo bilhetes para um
espectáculo
2. O empregado seleciona o espetáculo no sistema
3. O sistema mostra um mapa com os lugares vagos e ocupados
4. O empregado dialoga com o cliente para determinar os lugares pretendidos
5. O empregado seleciona os lugares pretendidos no sistema
6. O sistema imprime os bilhetes e informa o preço total
7. O empregado transmite ao cliente o preço total
8. O cliente paga os bilhetes
9. O empregado entrega ao cliente os bilhetes
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 21
Fluxo de evento principal O segredo está em descrever uma sequência de
funcionamento que transmite requisitos importantes, sem entrar em detalhes de implementação!
Fluxo de evento de exceção Descreve uma seqüência de atividades alternativa em
caso de alguma anormalidade no fluxo normal
Exemplo de Fluxo de exceção - “Cliente sem dinheiro" 8.1 - Se o cliente não tiver dinheiro para pagar, o empregado
cancela a venda no sistema e inutiliza os bilhetes
Outro exemplo - “Bilhetes esgotados" 2.1 - Se os bilhetes estiverem esgotados, o espectáculo aparece
assinalado de forma especial na lista de espetáculos e o empregado informa imediatamente o cliente
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 22
Fluxo de eventos
Sempre que se justifique (isto é, sempre que os diagramas permitem mais rapidamente apreender a informação que se quer transmitir), acompanhar ou substituir a descrição textual por diagramas dinâmicos
diagramas de sequência para descrever sequências particulares
diagrama de atividades para descrever todas as sequências possíveis
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 23
Exemplo: Sistema de Gestão de Hotéis
: CRM4SH::Cliente : CRM4SH::Recepcionista
CRM4SH
Pede alojamento indicando nº de pessoas, serviço e data de saída
Introduz nº de pessoas, serviço e data de saída
Mostra lista de quartos disponíveis e preço
Informa quartos dsponíveis e preço
Confirma pedido e escolhe quarto(s)
Pede documento de identificação e cartão de crédito
Faculta documento de identificação e cartão de crédito
Regista dados de identificação do cliente
Entrega chave e cartão de estadia
Devolve documento de identificação e cartão de crédito
Imprime cartão da estadia
Selecciona quarto(s) da lista
Regista dados do cartão de crédito do cliente
Sist. Externo de Valid.
de Cartões
Valida cartão
Cartão Ok
diagrama de sequência, mostrando sequência normal de funcionamento do caso de uso "Registar entrada de cliente sem reserva"
objetos
mensagens
Desenvolvimento de Software com UML 2006 24
Exemplo: Sistema de Gestão de Hotéis Sist. Ext. de
Valid. de
Cartões
CRM4SHRecepcionistaCliente
Pede alojam. p/ nºpess. e dt.saída Introduz dados do pedido
Mostra lista de quartos disponíveis e preçoInforma quartos disponíveis e preço
Escolhe quarto(s)
Pede identificação e cartão de crédito
Selecciona quarto(s) da lista
Faculta doc. ident. e cartão crédito
Memoriza informação
Regista dados de identificação do cliente
Memoriza informação
Regista dados do cartão de crédito do cliente
Solicita validação do cartão Valida cartão
Regista estadia na base de dados
[cartão ok]
Verifica disponibilidade
[disponível]
Informa cliente[indisponível]
Cancela e informa utilizador[cartão inválido]
Informa cliente
[não aceita]
Cancela operação[aceita]
Imprime cartão da estadiaDevolve documento de identificaçãoRecolhe documento de identificação
Entrega chaveRecolhe chave
Entrega cartão da estadiaRecolhe cartão da estadia
Devolve cartão de créditoRecolhe cartão de crédito
diagrama de atividades, mostrando todas as sequências possíveis de funcionamento do caso de uso "Registar entrada de cliente sem reserva"
Desenvolvimento de Software com UML 2006 25
Interface com o usuário Apresentar esboços ou imagens de protótipos da
interface com o usuário É fundamental evidenciar qual é o grau de fidelidade dos
esboços ou protótipos da interface, isto é, qual o grau de variação permitida em relação à implementação
Em muitos casos, faz sentido desenvolver um protótipo relativamente completo da interface com o usuário
Normalmente interessa evidenciar mais os conteúdos e elementos de interação disponíveis (botões, links, ...) do que o aspecto visual (estilo e layout)
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 26
Interface com o usuário Quando o aspecto visual e usabilidade da interface são
importantes, deve-se envolver um designer de interfaces (já não é competência típica do analista)
As interfaces apresentadas devem estar consistentes com a descrição das sequências de funcionamento
Opcionalmente, descrever o significado de cada elemento de que aparece na interface (campo, botão, etc.)
Opcionalmente, mostrar diagrama de navegação (diagrama de estados com estados da interface) ou storyboard
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 27
Exemplo: Sistema de Gestão de Conferências
seleccionar opção "Atribuir revisores a artigos" Terminar
Atribuir Revisores a Artigos
artigo nº de revisores
terminar
titulo1 0
titulo 2 1
Terminar
Atribuir Revisores a Artigo
artigo
seleccionar artigo
título: autores: autor1, autor2, ... resumo: PDF
nome nº art.
revisor 1 3
revisor 2 1
excluir
excluir
excluir
revisores atribuídos
terminar
excluir
nome nº art.
revisor 3 3
revisor 4 0
atribuir
atribuir
atribuir
revisores disponíveis
atribuir Fechar
Dados de Revisor
nome: instituição: e-mail: áreas de interesse: artigos que revê: artigo1, ...
seleccionar revisor
fechar
evento (ação do usuário)
estado da interface
Diagrama de navegação do caso de uso "Atribuir Revisores a Artigos" (diagrama de estados em UML, em que estados são estados de interface):
Desenvolvimento de Software com UML 2006 28
Pré-condições (Opcional)
Uma pré-condição é uma condição nos dados de entrada e no estado inicial do sistema (com base em modelo de estado definido no modelo de domínio), que deve ser verdadeira para se poder executar o caso de uso
Exemplo na venda de bilhetes a sócios para um jogo de futebol:
o sócio está previamente registado no sistema
o jogo ainda não começou
Opcionalmente, formalizar na Object Constraint Language (OCL)
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 29
Pós-condições (Opcional) Uma pós-condição é uma condição nos dados de
entrada, estado inicial do sistema, dados de saída e estado final do sistema, que deve ser verdadeira no final da execução do caso de uso (com base em modelo de estado definido no modelo de domínio)
Traduz o efeito/resultado do caso de uso
Exemplo (na compra de bilhetes): foi impresso um bilhete
os dados do bilhete ficaram registados no sistema
Opcionalmente, formalizar na Object Constraint Language (OCL)
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 30
Requisitos especiais (Opcional)
Lista de requisitos internos ao caso de uso (features, restrições, atores, alerta, ajuda ...)
Pode ser uma forma alternativa de transmitir requisitos, em vez de descrever sequências de funcionamentos
Ex: Requisitos internos ao caso de uso "Marcar consulta": A consulta pode ser marcada pelo médico ou pela secretária
(atores)
Um médico pode marcar uma consulta para outro médico (atores)
Não se podem marcar duas consultas para a mesma data, hora e médico (restrição)
O sistema deve alertar o usuário no caso do doente ter outras consultas marcadas (alerta)
O sistema deve ajudar o usuário a encontrar vagas (ajuda)
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 31
Pressupostos (Opcional)
Classes participantes (Opcional)
Listar as classes (ou entidades informacionais) do modelo de domínio relevantes para o caso de uso ou, se a complexidade o justificar, apresentar um diagrama de classes parcial, com as classes, atributos e relações relevantes
Fontes e referências (Opcional)
Fontes de informação consideradas (entrevistas, sites, etc.).
Se forem iguais para todos os casos de uso, basta indicar no fim do documento, em vez de indicar em cada caso de uso
Descrição detalhada de cada caso de uso
Desenvolvimento de Software com UML 2006 32
Modelo de domínio - Objetivos
organizar o vocabulário do domínio do problema (utilizado na descrição dos casos de uso) organizar e relacionar termos que estão definidos num glossário ou num
dicionário de dados
classes são conceitos
capturar os requisitos de informação que informação é mantida no sistema e trocada com o ambiente
classes são entidades informacionais
especificar as transações do negócio (por operações) - opcional
três tipos de classes classes que modelam o estado interno persistente e partilhado do sistema,
como atributos de entidades (e eventos) do negócio e respectivas ligações – são as classes mais importantes
classes que modelam a estrutura de documentos trocados entre o sistema e o seu ambiente
classes que modelam tipos de dados (usados nos atributos e operações das classes anteriores)
Desenvolvimento de Software com UML 2006 33
Modelo de domínio – Forma1
Visão geral
Diagrama de classes
Descrição textual que passa superficialmente pelas classes mais importantes
Desenvolvimento de Software com UML 2006 34
nome
endereço
telefone
categoria
/capacidade
Hotel
número de cliente {I}
nome
nacionalidade
data de nascimento
morada
telefone
número do bilhete de identidade ou passaporte {I2}
data do bilhete de identidade ou passaporte
Cliente
número da reserva {I}
data da reserva
número de pessoas
data de entrada prevista
data de saída prevista
número do cartão de crédito
titular do cartão de crédito
data de expiração do cartão de crédito
estado: (activa, anulada, efectivada, cliente faltou)
Reserva
número da estadia {I}
número de pessoas
data de entrada
data de saída
número do cartão de crédito
titular do cartão de crédito
data de expiração do cartão de crédito
Estadia
0..1
0..1
1
*
1
*
número {I}
capacidade
Quarto
nome {I}
Serviço
1
*
1serviços1..*
1
quartos*clientes *
1
data de início {I}
data de fim
número de pessoas {I}
preço
Preço Serviço
serviço {I}
1
preços1..*
login {I}
password
nome
função
Empregado
1
empregados*
1
*
número {I}
data
/valor
Factura
1
0..1
1
*
/
Mensagem por e-mail
data-hora
modo de contacto
iniciativa do contacto
descrição
Contacto com Clientecontacto anterior
0..1
contacto seguinte*
0..1
*
1
*
0..1
*
0..1
*
1
data de entrada
data de saída
número de pessoas
Estadia Quarto
*
1..*
Permite manter
informação de
mudanças de
quarto e indicar
a distribuição de
pessoas pelos
quartos.
Exemplo: Sistema de Gestão de Hotéis
generalização
classe-associação (para indicar atributos)
agregação
classe com atributos
nota
diagrama de classes
associação
Desenvolvimento de Software com UML 2006 35
Modelo de domínio – Forma2
Descrição de cada classe Significado
Descrição de atributos
Definição de restrições Informalmente
Formalmente, como invariantes em OCL (opcional)
Descrição de operações (quando definidas) Sintaxe
Semântica Informalmente
Formalmente, com pré-condições e pós-condições em OCL (Opcional)
Ciclo de vida dos objetos da classe (diagrama de estados)
Estados devem corresponder a condições nos valores de atributos e ligações
Nesta fase, eventos devem corresponder a casos de uso, podendo ter parâmetros
Desenvolvimento de Software com UML 2006 36
Activa
registo de reserva
Anulada
Cliente faltou
Efectivada
eliminação da informação
anulação de reserva
registo de entrada com reserva
passagem da data de entrada prevista
Exemplo: Sistema de Gestão de Hotéis
ciclo de vida de uma reserva (diagrama de
estados) estado
estado composto
subestado
evento (corresponde a execução de caso de uso)
transição
evento temporal
Desenvolvimento de Software com UML 2006 37
Mais informação
www.uml.org – especificações e recursos sobre UML
Use Case Modeling, Kurt Bittner, Lan Spencer, Addison-Wesley, 2003
The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson, Addison-Wesley, 1998
The Unified Software Development Process, Ivar Jacobson, Grady Booch, James Rumbaugh, Addison-Wesley, 1999