Modelagem de Sistemas Com UML

Desenvolvimento de Software com UML 2006 1

Modelagem de Sistemas de Informação com

UML


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, ...


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


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


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

UML/pacotes.ppt


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


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


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


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


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



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


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


evolução da facturação ao longo

do tempo


distribuição das vendas por

nacionalidade


clientes com maior

facturação

diagramas de casos de uso

(com pacotes de 2º nível)



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


generalização de casos de uso

generalização de atores


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



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


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”


Atores

Nome e breve descrição de cada ator

Casos de Uso

Descrição mais ou menos detalhada de cada caso de uso



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


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)



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



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



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


UML/sequencia.ppt

UML/actividade.ppt


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


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"


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)



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


UML/estados.ppt


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):


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)


ww.uml.org

ww.uml.org


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)


ww.uml.org

ww.uml.org


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)



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



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)


Modelo de domínio – Forma1

Visão geral

Diagrama de classes

Descrição textual que passa superficialmente pelas classes mais importantes


nome

endereço

telefone

categoria

e-mail

/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

e-mail

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.


generalização

classe-associação (para indicar atributos)

agregação

classe com atributos

nota

diagrama de classes

associação


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


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


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


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

http://www.uml.org/

Modelagem de Sistemas Com UML

Documents

Transcript of Modelagem de Sistemas Com UML