Modelação de Sistemas de Informação com UML

Apresentação em tema: "Modelação de Sistemas de Informação com UML"— Transcrição da apresentação:

1 Modelação de Sistemas de Informação com UML
João Pascoal Faria Análise de Sistemas de Informação (Mestrado em Gestão de Informação)

2 Introdução Modelos permitem descrever os requisitos de um sistema de informação de forma conveniente para utilizadores e implementadores Modelos do negócio – a cargo de um analista de negócio Modelo de casos de utilização do 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 actividades Também é possível modelar: objectivos do negócio, regras do negócio, estrutura organizacional, ...

3 Introdução Modelos do sistema – a cargo de um analista de sistemas
Modelo da arquitectura 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 utilização – funcionalidades do sistema, requisitos funcionais Modelo de domínio – informação manipulada pelo sistema (entidades informacionais, atributos e relações), requisitos de informação

4 Introdução Complementar modelos com Requisitos suplementares
lista de requisitos que não são descritos adequadamente pelos casos de utilização normalmente são requisitos não funcionais requisitos de qualidade: desempenho, segurança no sentido de security, usabilidade e acessibilidade, disponibilidade e fiabilidade, segurança no safety), etc. requisitos impostos pelo ambiente operacional etc. Glossário – vocabulário do domínio fundamental evitar equívocos

5 Modelo da arquitectura 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 (arquitectura lógica) Cada sub-sistema corresponde a uma área funcional (grupo de funcionalidades), cobrindo todas as camadas da implementação (interface com o utilizador, 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

6 Exemplo: Sistema de Gestão de Cuidados de Saúde
Cuidados Primários Cuidados Diferenciados sub-sistema dependência Cuidados Comuns

7 Modelo de casos de utilização
Finalidade: mostrar a utilidade ou usos possíveis do sistema Conteúdo: actores (tipos de utilizadores e sistemas externos que interagem com o sistema), casos de utilização (funcionalidades do sistema tal como são vistas externamente, ou tipos de interacções entre actores e o sistema) e relações entre ambos Casos de utilização capturam os requisitos funcionais e alguns requisitos não funcionais

8 Forma do modelo de casos de utilização (1)
Visão geral Diagrama de casos de utilização acompanhado de descrição textual que passa superficialmente pelos casos de utilização e actores mais importantes

9 Exemplo: Sistema de Gestão de Conferências
nome do sistema fronteira do sistema actor caso de utilização diagrama de casos de utilização

10 Forma do modelo de casos de utilização (2)
Visão geral (cont.) Se existirem muitos casos de utilização, apresentar um primeiro diagrama de pacotes de casos de utilização e depois um diagrama de casos de utilização para cada pacote Pacotes devem corresponder a sub-sistemas no modelo da arquitectura

11 Exemplo: Sistema de Gestão de Hotéis (CRM4SH) (1)
diagrama de pacotes de casos de utilização

12 Exemplo: Sistema de Gestão de Hotéis (CRM4SH) (2)
diagramas de casos de utilização (com pacotes de 2º nível)

13 Exemplo: Sistema de Gestão de Hotéis (CRM4SH) (3)
generalização

14 Forma do modelo de casos de utilização (3)
Visão geral (cont.) Opcionalmente, modelar através de um ou mais diagramas de actividades o encadeamento de casos de utilização (i.e., modelar workflows ou processos de negócio) casos de utilização aparecem como actividades no diagrama de actividades se tiver sido construído anteriormente um modelo de processos de negócio, isto já foi feito

15 Exemplo: Sistema de Gestão de Conferências (1)
actor objectos de classes do modelo de domínio (ver adiante) passos são execuções de casos de utilização! [submetido] fluxo de controlo fluxo de objectos [submetido]

16 Exemplo: Sistema de Gestão de Conferências (2)
barra de sincronização (inicia ou termina execução em paralelo)

17 Forma do modelo de casos de utilização (4)
Actores Nome e breve descrição de cada actor Casos de Utilização Descrição mais ou menos detalhada de cada caso de utilização - ver a seguir

18 Descrição detalhada de cada caso de utilização
Nome Usar normalmente um verbo, evidenciando a finalidade/objectivo/utilidade Descrição sumária Uma ou duas frases curtas, que ficaria bem numa tabela de resumo dos casos de utilização, tornando evidente o objectivo/utilidade Actores Indicar os vários actores intervenientes e o seu papel, tornando evidente quem inicia a interacção Prioridade Indicar a prioridade do caso de utilização (por exemplo, alta, média ou baixa) Convém considerar pelo menos 3 níveis de prioridade, para ter flexibilidade suficiente na negociação de uma solução

19 Descrição detalhada de cada caso de utilização
Sequência de funcionamento (ou fluxo de eventos) Semelhante a instruções passo a passo no manual do utilizador Por definição, um caso de utilização é "uma sequência de acções" Descrever a sequência de funcionamento normal ponto a ponto Descrever separadamente sequências de funcionamento excepcionais, por diferenças em relação à sequência normal Indicar tanto as acções realizados pelos actores como as acções realizadas pelo sistema Evidenciar os dados de entrada (introduzidos pelos actores) e os dados de saída (fornecidos pelo sistema) Evidenciar como é que se inicia o caso de utilização (normalmente indica-se pela primeira acção do actor)

20 Descrição detalhada de cada caso de utilização
Sequência de funcionamento (ou fluxo de eventos) Exemplo de sequência normal de funcionamento do caso de utilização "Vender bilhetes": Um cliente dirige-se ao empregado da bilheteira pedindo bilhetes para um espectáculo O empregado selecciona o espectáculo no sistema O sistema mostra um mapa com os lugares vagos e ocupados O empregado dialoga com o cliente para determinar os lugares pretendidos O empregado selecciona os lugares pretendidos no sistema O sistema imprime os bilhetes e informa o preço total O empregado transmite ao cliente o preço total O cliente paga os bilhetes O empregado entrega ao cliente os bilhetes

21 Descrição detalhada de cada caso de utilização
Sequência de funcionamento (ou fluxo de eventos) O segredo está em descrever uma sequência de funcionamento que transmite requisitos importantes, sem entrar em detalhes de implementação! Exemplo duma sequência excepcional - "cliente sem dinheiro" No passo 8, se o cliente não tiver dinheiro para pagar, o empregado cancela a venda no sistema e inutiliza os bilhetes Exemplo doutra sequência excepcional - "bilhetes esgotados" No passo 2, se os bilhetes estiverem esgotados, o espectáculo aparece assinalado de forma especial na lista de espectáculos, e o empregado informa imediatamente o cliente

22 Descrição detalhada de cada caso de utilização
Sequência de funcionamento (ou 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 actividades para descrever todas as sequências possíveis

23 Exemplo: Sistema de Gestão de Hotéis
diagrama de sequência, mostrando sequência normal de funcionamento do caso de utilização "Registar entrada de cliente sem reserva" objectos mensagens

24 Exemplo: Sistema de Gestão de Hotéis
diagrama de actividades, mostrando todas as sequências possíveis de funcionamento do caso de utilização "Registar entrada de cliente sem reserva"

25 Descrição detalhada de cada caso de utilização
Interface com o utilizador Apresentar esboços ou imagens de protótipos da interface com o utilizador É 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 utilizador Normalmente interessa evidenciar mais os conteúdos e elementos de interacção disponíveis (botões, links, ...) do que o aspecto visual (estilo e layout) 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 Fim da aula de ASI, 23 de Novembro de 2004

26 Exemplo: Sistema de Gestão de Conferências
Diagrama de navegação do caso de utilização "Atribuir Revisores a Artigos" (diagrama de estados em UML, em que estados são estados de interface): estado da interface evento (acção do utilizador) Atribuir Revisores a Artigo artigo terminar Atribuir Revisores a Artigos título: autores: autor1, autor2, ... resumo: seleccionar artigo nº de revisores artigo PDF revisores atribuídos titulo1 nome nº art. excluir titulo 2 1 seleccionar opção "Atribuir revisores a artigos" terminar revisor 1 3 excluir revisor 2 excluir Terminar 1 revisores disponíveis nome nº art. atribuir Dados de Revisor seleccionar revisor revisor 3 atribuir 3 nome: instituição: áreas de interesse: artigos que revê: artigo1, ... revisor 4 atribuir fechar Terminar Fechar atribuir excluir

27 Descrição detalhada de cada caso de utilização
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 – ver adiante), que se deve verificar para se poder executar o caso de utilização 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

28 Descrição detalhada de cada caso de utilização
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 se deve verificar no final da execução do caso de utilização (com base em modelo de estado definido no modelo de domínio – ver adiante) Traduz o efeito/resultado do caso de utilização Exemplo (na compra de bilhetes): foi impresso um bilhete os dados do bilhete ficaram registados no sistema Opcionalmente, formalizar na Object Constraint Language

29 Descrição detalhada de cada caso de utilização
Pós-condições (Opcional) Exemplo no caso de utilização "Colocar professores" (correr o processamento de colocação de professores): Um professor que tinha uma colocação assegurada anteriormente tem de ficar colocado obrigatoriamente, nem que seja na posição em que estava anteriormente colocado Para cada professor e para cada posição por ele preferida em relação àquela em que foi colocado (inclui todas as posições no caso de não ter sido colocado), essa posição tem de estar ocupada por um professor com melhor ranking ou pelo professor que aí estava anteriormente colocado

30 Descrição detalhada de cada caso de utilização
Requisitos especiais (Opcional) Lista de requisitos internos ao caso de utilização (features, restrições, ...) Pode ser uma forma alternativa de transmitir requisitos, em vez de descrever sequências de funcionamentos Exemplo de requisitos internos ao caso de utilização "Marcar consulta" (com a categoria entre parêntesis): A consulta pode ser marcada pelo médico ou pela secretária (actores) Um médico pode marcar uma consulta para outro médico (actores) Não se podem marcar duas consultas para a mesma data, hora e médico (restrição) O sistema deve alertar o utilizador no caso do doente ter outras consultas marcadas (alerta) O sistema deve ajudar o utilizador a encontrar vagas (ajuda)

31 Descrição detalhada de cada caso de utilização
Pressupostos (Opcional) Classes participantes (Opcional) Listar as classes (ou entidades informacionais) do modelo de domínio (ver adiante) relevantes para o caso de utilização 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 utilização, basta indicar no fim do documento, em vez de indicar em cada caso de utilização

32 Modelo de domínio (1) Objectivos
organizar o vocabulário do domínio do problema (utilizado na descrição dos casos de utilização) 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 transacçõ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)

33 Modelo de domínio (2) Forma Visão geral Diagrama de classes
Descrição textual que passa superficialmente pelas classes mais importantes

34 Exemplo: Sistema de Gestão de Hotéis
agregação classe com atributos associação classe-associação (para indicar atributos) diagrama de classes nota (versão corrigida para ficar consistente com OCL) generalização

35 Modelo de domínio (3) Forma (cont.) 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 Formalmente, com pré-condições e pós-condições em OCL (Opcional) Ciclo de vida dos objectos 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 utilização, podendo ter parâmetros

36 Exemplo: Sistema de Gestão de Hotéis
ciclo de vida de uma reserva (diagrama de estados) estado transição evento (corresponde a execução de caso de utilização) estado composto subestado evento temporal

37 Mais informação www.uml.org – especificações e recursos sobre UML
Use Case Modeling, Kurt Bittner, Lan Spencer, Addison-Wesley, 2003 UML – Metodologias e Ferramentas CASE, Alberto Silva, Carlos Videira, Centro Atlântico, 2001 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