Modelação Aula T05 Engenharia de Requisitos

Apresentação em tema: "Modelação Aula T05 Engenharia de Requisitos"— Transcrição da apresentação:

1 Modelação Aula T05 Engenharia de Requisitos
Modelos Estrutural e Dinâmico Referências: Conceptual Modeling of Information Systems (Capítulos 1.4, 2 e 3) UML, Metodologias e Ferramentas CASE (Capítulos 4 e 5) José Borbinha

2 Programa T01-T03 – Módulo 1 Introdução à Modelação de Sistemas T04-T07 – Módulo 2 Modelação Conceptual de Sistemas T05 Engenharia de Requisitos Modelo Estrutural Modelo de Domínio (introdução) Modelo de Dinâmica Casos de Uso T08-T11 – Módulo 3 Ontologias T12-T15 – Módulo 4 Modelação de Sistemas: Dinâmica T16-T18 – Módulo 5 Modelação de Sistemas: Arquitectura T19-T25 – Módulo 6 Temas avançados "Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte". (Pascal - 16ª Provinciale) ...Escrevi esta carta longa porque não tive tempo de a escrever mais curta... Mas o que é que isto tem a ver com a matéria de hoje? Modelação

3 Engenharia de Requisitos
Modelação

4 Engenharia de Requisitos
O Processo de Eng.ª de Requisitos Levantamento de Requisitos Análise de Requisitos Negociação de Requisitos Modelação

5 Sobre Requisitos Um requisito é uma condição ou restrição sobre um serviço ou sistema. Um requisito errado significa, mais tarde ou mais cedo, problemas no projecto (erros, atrasos, ...). Engenharia de requisitos é o processo (conjunto estruturado de actividades) que envolve um levantamento de requisitos Não há processos ideias, mas há técnicas já provadas que se podem usar em algumas situações típicas (a ver adiante...) O custo de um processo de levantamento de requisitos depende da natureza do problema e da metodologia usada, mas pode ser bastante substancial e nunca deve ser desprezado!!! O resultado de um processo de levantamento de requisitos é geralmente um “Documento de Requisitos” (a ver adiante...) Modelação

6 Principais tipos de requisitos
Requisitos funcionais (RF) dizem o que é que o sistema deve fazer... Exemplos: Deve ser possível obter os nomes de todos os clientes numa lista ordenada alfabeticamente. Sempre que é emitida uma factura deve ser enviado um para o responsável financeiro da organização Deve ser mantido um registo para todas as operações de alterações de dados dos últimos 30 dias. Requisitos não funcionais (RNF) dizem como é que o sistema deve ser feito e deve funcionar... A apresentação da lista ordenada dos nomes de todos os clientes não deve demorar mais do que 1 segundo. Todas as interfaces de utilizador devem ser apresentadas em Português e em Inglês O sistema de gestão de base de dados deve ser o MySQL Todo o sistema deve ser programado em Java, para ambiente Linux ou Windows Modelação

7 Processo Geral de Engenharia de Requisitos
Objectivos de negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre os sistemas existentes Normas, leis e regulamentos a cumprir .., Identificação de requisitos (“elicitation”) Análise de Requisitos e Negociação Documentação dos Requisitos Validação dos Requisitos Documento de Requisitos Especificação do Sistema... Modelação

8 Utilizadores do Documento de Requisitos
Clientes do sistema Especificam ou validam os requisitos Gestores de projecto Planeamento de custos e prazos para o processo de desenvolvimento Engenheiros de sistemas e desenvolvimento Entendimento do sistema a desenhar e desenvolver Equipas de teste do sistema Usam os requisitos para desenvolver teste de validação Equipas de manutenção do sistema Usam os requisitos para o melhor compreender Modelação

9 O standard IEEE/ANSI 830-1993 propõe uma estrutura para documentos de requisitos de software
1. Introdução 1.1 Propósito do documento 1.2 Contexto do produto 1.3 Definições, acrónimos e abreviaturas 1.4 Referências 1.5 Visão geral do documento 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos utilizadores 2.4 Restrições gerais 2.5 Assunções e dependências 3. Requisitos específicos Este ponto aparece tipicamente estruturado em requisitos funcionais e em requisitos não funcionais... 4. Apêndices Modelação

10 Classificação de Requisitos Não Funcionais segundo o IEEE-Std 830 – 1993
Requisitos de desempenho Requisitos de interface Requisitos operacionais Requisitos de recursos Requisitos de verificação Requisitos de aceitação Requisitos de documentação Requisitos de segurança Requisitos de portabilidade Requisitos de qualidade Requisitos de fiabilidade Requisitos de manutenção Em cada projecto concreto devem ser usadas as classes que se considerem relevantes... Modelação

11 Mais exemplos de Requisitos Funcionais (do livro “Systems analysis and design with UML”)
Modelação

12 Mais exemplos de Requisitos Não Funcionais (do livro “Systems analysis and design with UML”)
Modelação

13 Níveis de Maturidade do processo de Engenharia de Requisitos numa organização
Nível inicial (Initial level) Não se reconhece o problema ou pensa-se que o mesmo não se aplica. Não existe processo. Risco de problemas de volatilidade de requisitos e custos elevados de alterações. O sucesso da actividade é muito dependente da capacidade e experiência individual das pessoas. Nível Repetitivo (Repeatable level) Reconhecimento do problema e vontade de lidar devidamente com ele. São definidas normas para os documentos de requisitos e para os procedimentos de gestão de requisitos, geralmente copiando ou adaptando modelos exteriores. Nível Definido (Defined level) O processo está definido com base em boas práticas, existindo uma preocupação na melhoria activa do processo. O processo é visto como uma vantagem competitiva da organização. Modelação

14 Engenharia de Requisitos
O Processo de Eng.ª de Requisitos Levantamento de Requisitos Análise de Requisitos Negociação de Requisitos Modelação

15 Processo Geral de Engenharia de Requisitos
Objectivos de negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre os sistemas existentes Normas, leis e regulamentos a cumprir .., Identificação de requisitos (“elicitation”) Análise de Requisitos e Negociação Documentação dos Requisitos Validação dos Requisitos Documento de Requisitos Especificação do Sistema... Modelação

16 Técnicas de levantamento de requisitos
Questionários Análise de documentos Entrevistas JAD - Joint Application Design Etnografia Prototipagem Casos de Uso (de novo...) Modelação

17 Questionários Relevante num cenário Processo
Com muitos utilizadores conhecedores profundos do negócio e já com processos de negócio estabelecidos (mesmo que não formalizados), Em que há uma percepção da necessidade do sistema, mas há ainda pouco conhecimento consolidado sobre os seus requisitos, especialmente funcionais. Processo Seleccionar participantes (representativos dos stakeholders) Definir questionário (selecção cuidada das questões) Administrar o questionário (definir estratégias para obter respostas em bom número e de qualidade) Follow-up do questionário (enviar os resultados do questionário aos participantes, para validação, ainda que implícita, e reconhecimento pelo papel dos mesmos) Modelação

18 Análise de Documentos Relevante num cenário em que já há processos de negócio bem estabelecidos ou mesmo já sistemas instalados (cenário “as-is”) que se pretendem substituir (cenário “to-be”) Documentos típicos: Formulários Relatórios Manuais de procedimento Procurar documentos e práticas de uso dos mesmos menos usuais (formulários, procedimentos locais, ...) Modelação

19 Entrevistas Relevante quando os requisitos dependem de um número relativamente pequeno e bem identificado de utilizadores ou decisores bastante especializados mas ao mesmo tempo com perspectivas diferenciadas. Adequada a cenários com orgânicas rígidas Planeamento Documentar-se e ler material de suporte Estabelecer claramente os objectivos da entrevista Decidir quem entrevistar (cuidado com as hierarquias) Avisar antecipadamente o entrevistado (dando-lhe a possibilidade de se preparar devidamente) Decidir cuidadosamente os tipos de questões e a sua estrutura Modelação

20 Joint Application Design (JAD)
Técnica relevante quando se pretende algo de novo mas os requisitos dependem de um conjunto alargado de classes de utilizadores ou decisores Adequada a cenários de organizações horizontais ou em que a cultura organizacional suporta a resolução de problemas em grupo Processo: Organizar entre 2 a 3 sessões de um dia fora do local do trabalho para minimizar interferências. Planear ambiente funcional, com comida e bebidas Só realizar as reuniões se todos os participantes podem estar presentes. Um dos participantes deve registar o conteúdo da sessão Participantes: Pelo menos 1 analista e 1 ou 2 técnicos especializados, que devem ter papéis passivos (contribuição reservada para a análise) 1 moderador, escolhido com base no seu poder de comunicação, não devendo ser o analista. O supervisor directo do moderador deve pertencer ao grupo 8 a 12 utilizadores Um executivo de topo de aparecer como patrocinador, introduzindo concluindo a sessão Modelação

21 Análise comparativa da JAD
Riscos Exige que os vários participantes tenham tempo disponível para todas as sessões Exige grande esforço de preparação (ou a sessão pode não ter sucesso) Se o relatório de uma sessão estiver incompleto pode por em risco a próxima sessão Cultura organizacional pode não ser na realidade compatível com a JAD Vantagens Menos 15% do tempo em comparação com as entrevistas individuais Permite desenho criativo e desenvolvimento rápido Os utilizadores sentem-se integrados no desenvolvimento do sistema Permite ao analista efectuar o levantamento de requisitos com os utilizadores Modelação

22 Já agora, a galeria das “figurinhas” difíceis: Esta relação pode ser apresentada no início da primeira reunião JAD, após as apresentações, a fim de inibir tais procedimentos... O Atrasadinho - Sempre chega atrasado. Dá seu “show” na chegada. O que sai mais cedo - Abala a energia e a moral do grupo. O Ampulheta - “Joga areia” em todas as ideias. - Sempre esfriando o entusiasmo do grupo, dizendo algo como “isso nunca vai funcionar”. O desinteressado - Senta afastado da mesa ou no fundo da sala. - Pode cochilar, ler alguma coisa, ficar rabiscando papéis. O disco quebrado - Traz de volta sempre o mesmo ponto. - Dificulta o avanço do grupo para novos itens. O cochichador - Vive cochichando durante as reuniões, mantendo conversas paralelas. O Rei da Voz - Fala muito e excessivamente alto. Domina a discussão. - Parece impossível fazê-lo calar. O Intérprete - Sempre fala por outra pessoa, normalmente sem ser solicitado. - Recoloca ideias alheias distorcendo-as durante sua explanação. O Móveis e Utensílios - Usa credencias como idade e tempo de casa para fazer prevalecer suas ideias. O Ocupado - Sempre entrando e saindo das reuniões com papéis debaixo do braço. - Permite que seja chamado frequentemente por secretárias e subordinados. - Tenta dar a impressão de muito ocupado e portanto, muito importante. Modelação

23 Etnografia Técnica desenvolvida na área das ciências sociais. Relevante quando já existem processos em prática mas é difícil descrever como que se realizam. A solução é observar como as tarefas são realizadas e tentar depois fazer o “reverse engineering” dos processos. Permite detectar divergências entre os métodos de trabalho usados e a sua definição formal Processo: Procurar métodos de trabalho pouco usuais Estabelecer uma relação de confiança com os utilizadores Manter notas detalhadas sobre os métodos de trabalho. Combinar observação com entrevistas abertas Organizar sessões regulares de esclarecimento Só por si esta técnica é insuficiente, pelo que se devem usar sempre outras técnicas como complemento Modelação

24 Prototipagem Protótipos são versões iniciais de um sistema para experimentação que devem estar disponíveis durante o levantamento de requisitos. Técnica relevante quando é necessário testar provas de conceito (especialmente em cenários de grande inovação), especialmente quando o resultado final depende bastante de pormenores de interface. Processos Protótipos “throw-away”: ajudam ao levantamento e desenvolvimento dos requisitos difíceis de perceber Protótipos Evolutivos: desenvolvimento rápido de uma versão inicial do sistema, especialmente quando já há requisitos bem definidos e aceites Os protótipos podem ser feitos na mesma tecnologia do sistema final (protótipos evolutivos), ou noutra tecnologia mais adequada a fins de curto prazo (especialmente para protótipos “throw-away”) - A prototype is an initial version of a system which may be used for experimentation - Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses They have something concrete to criticise - Rapid development of prototypes is essential so that they are available early in the elicitation process Modelação

25 Prototipagem em papel,,, Modelação

26 Casos de Uso (ver continuação adiante...)
A técnica de casos de uso ajuda a capturar os requisitos de um sistema através do detalhe de todos os cenários de interacção do sistema com o seu exterior. O resultado de um processo de desenho de casos de uso deve ser um conjunto de diagramas (tipicamente em UML, representando-se mais que um caso em cada diagrama) e um conjunto de descrições textuais (uma para cada caso) Um caso de uso deve ser representado num modo impessoal, por uma frase na voz activa, com um verbo no infinitivo (“Registar Cliente”, “Emitir Factura”, “Efectuar Compra”, ...) Os casos podem ser usados como técnica de levantamento de requisitos, e depois mais tarde também para fazer a ponte entre os requisitos e a modelação do comportamento de um sistema (tipicamente o desenho do modelo da dinâmica de um sistema começa com a análise dos seus casos de uso) Por ser mais genérica, a descrição dos casos de uso pode aparecer na documentação de requisitos, antes da enunciação dos mesmos (na descrição geral do sistema), para ajudar ao entendimento do contexto. Modelação

27 Engenharia de Requisitos
O Processo de Eng.ª de Requisitos Levantamento de Requisitos Análise de Requisitos Negociação de Requisitos Modelação

28 Processo Geral de Engenharia de Requisitos
Objectivos de negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre os sistemas existentes Normas, leis e regulamentos a cumprir .., Identificação de requisitos (“elicitation”) Análise de Requisitos e Negociação Documentação dos Requisitos Validação dos Requisitos Documento de Requisitos Especificação do Sistema... Modelação

29 Análise de Requisitos O objectivo é encontrar problemas, falhas e inconsistências A análise deve ser intercalada com o levantamento de requisitos e suportada por uma lista de verificação de problemas Modelação

30 Lista típica de verificação de requisitos
Para cada requisito concreto aplicar verificação: Desenho prematuro: Verificar se inclui informação prematura sobre o design ou a implementação Detalhe: Verificar é um único requisito ou se o mesmo deve ser dividido em diferentes requisitos Necessidade: Verificar se é apenas uma adição “cosmética” ao sistema. Tecnologia não normalizada: Detectar se o requisito obriga ao uso de hardware ou outra tecnologia não “standard”. Conformidade com os objectivos de negócio: Verificar se é consistente com os objectivos definidos na introdução do documento de requisitos Ambiguidades: Verificar se o requisito pode ser lido de forma diferentes por diferentes pessoas e quais as interpretações possíveis? Realismo: Verificar se o requisito é realista, especialmente tendo em conta o custo e a tecnologia a ser usada para implementar o sistema Teste: Verificar se é possível derivar um teste a partir da descrição do requisito que mostre que o sistema satisfaz esse requisito Modelação

31 Matrizes de Interacção
Técnica para determinar as interacções entre requisitos, evidenciando conflitos e sobreposições: => Requisitos independentes => Requisitos em conflito (contraditórios) 1000 => Requisitos sobrepostos (dizem a mesma coisa, total ou parcialmente) R e q u i r m n t 1 2 3 4 5 6 Modelação

32 Engenharia de Requisitos
O Processo de Eng.ª de Requisitos Levantamento de Requisitos Análise de Requisitos Negociação de Requisitos Modelação

33 Processo Geral de Engenharia de Requisitos
Objectivos de negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre os sistemas existentes Normas, leis e regulamentos a cumprir .., Identificação de requisitos (“elicitation”) Análise de Requisitos e Negociação Documentação dos Requisitos Validação dos Requisitos Documento de Requisitos Especificação do Sistema... Modelação

34 Negociação de requisitos
A negociação de requisitos tenta encontrar soluções de concordância. Pode ser um processo demorado, pois obriga a consensos Fases do Processo: Informação: Explicar os problemas associados com os requisitos a negociar Discussão: “Stakeholders” devem ter oportunidade de comentar os requisitos que lhes dizem respeito. Usar esta fase para atribuir prioridades aos requisitos Resolução: Eliminar, alterar ou refinar o requisito Modelação

35 Sobre Linguagens de Modelação Perspectiva Geral

36 Relembrando da aula T04... O modelo de um domínio, do sistema, ou base de informação*, são as entidades e relações desse domínio *Termo usado em “Conceptual Modeling of Information Systems” A descrição do modelo de domínio de um sistema é o esquema estrutural desse sistema. O esquema de comportamento especifica as acções válidas e as mudanças no estado do domínio que o sistema pode executar Ao conjunto formado pelo esquema estrutural e pelo esquema de comportamento de um sistema dá-se o nome de esquema conceptual. Modelação

37 Diagrama de Classes dos diagramas da linguagem UML 2
Diagrama de Classes dos diagramas da linguagem UML 2.0 Comportamento e Estrutura ( Modelação

38 Diagrama de Classes dos diagramas da linguagem SysML (subconjunto da UML com extensões para satisfazer requisitos de engenharia de sistemas.. voltaremos a isto nos módulos 5 e 6...) Modelação

39 Diagrama de Classes dos diagramas da linguagem SysML
Modelação

40 Modelo Estrutural Modelo de Domínio
Modelação

41 Entidades e relações... o que se explicar aqui do modelo pode-se depois aproveitar para suportar o resto da conversa dos casos de uso (i.e., casos de uso são entidades e relações tal como nos diagramas de domínio...) Modelação

42 Modelação da Estrutura
Uma visão pragmática: Classes Relações Diagramas de Classes Nota: Adiante vamos apresentar uma explicação muito pragmática destes conceitos. Mais adiante no curso iremos voltar a este assunto para os formalizar melhor... Modelação

43 Estereótipo de representação de uma classe em UML
Classes Uma classe representa um conceito ou categoria de objectos que partilham: atributos (que determinam o estado dos objectos) operações (que definem o comportamento) Nome da classe Pessoa Nome atribuirNome() retornarNome() Estereótipo de representação de uma classe em UML Atributo da classe Operações da classe Modelação

44 Uma classe bem estruturada
Providencia uma abstracção definida a partir do vocabulário do domínio do sistema Agrega um conjunto restrito e bem definido de propriedades Providencia uma separação clara entre a especificação abstracta e a sua implementação É simples e facilmente entendida. Modelação

45 Modelação da Estrutura
Uma visão pragmática: Classes Relações Diagramas de Classes Modelação

46 Relações Uma relação é uma ligação entre elementos.
Numa linguagem de modelação orientada a objectos os três tipos de relações mais importantes são: Dependências Generalizações Associações Relação Pessoa Nome atribuirNome() retornarNome() Carro Modelo VelocidadeMax() ConsumoMedio() Modelação

47 Relações - Dependência
Uma dependência indica que a alteração na especificação de um elemento (por exemplo, pacote “UML 0.9”) pode afectar outro elemento que o usa (pacote “UML 1.0”) mas não necessariamente o oposto. Em UML as dependências são usadas entre normalmente com packages, componentes e notas. Modelação

48 Relações - Generalização
Shape origin move() resize() display() Uma generalização é uma relação entre um elemento geral (superclasse) e um tipo mais específico desse elemento (subclasse). Geralmente conhecida como uma relação “is-a” ou “is-a-kind-of”. Rectangle corner: Point Circle radius: Float Polygn points: List Square No contexto de classes usam-se generalizações para ilustrar relações de herança. Modelação

49 Relações - Associação Uma associação é uma relação semântica entre dois ou mais elementos de um modelo. Este exemplo lê-se: Uma pessoa pode trabalhar para várias empresas (0 ou mais). Numa empresa trabalham 1 ou mais pessoas. Modelação

50 Relações - Associação Multiplicidade de uma associação
Define quantos objectos participam na relação O número de instâncias de uma classe relacionadas com uma instância da outra classe Especificada para cada participante (classe) da associação Não especificada Apenas uma Zero ou mais Uma ou mais Zero ou uma Intervalo especificado Valores e intervalos múltiplos 1 0..* ou apenas * 1..* 0..1 2..4 2, 4..6 Modelação

51 Relações – Associação Relações entre classes do tipo “is-part-of” ou “has-a” são representadas através de agregação. ... uma Pessoa pode existir sem uma Empresa... Uma composição é uma agregação forte ( “todo” em relação à “parte”) e com tempo de vida delimitado (as “partes” não podem existir sem o “todo”). O “todo” é responsável pela criação e destruição das suas “partes”. ... um Departamento não existe sem o contexto de uma Empresa... Modelação

52 Relações - Associação Modelação

53 Relações – Associação... «Uma mesa é constituída por um tampo e por quatro pernas…» «Uma mesa é constituída por um tampo e por duas a seis pernas, as quais têm de estar ordenadas…» Mesa Mesa Tampo 1 Ordem 1 Tampo 1 1 4 Perna 2..6 Perna Modelação

54 Relações - Associação Classes-Associação
Numa associação entre classes, a associação pode também ter as suas próprias propriedades, devendo ser, por conseguinte, modelada também como uma classe. 1..* * Pessoa Empresa empregado empregador Tarefa descrição dataInício salário classe associação Modelação

55 Relações - Associações Reflexivas
Quando uma classe tem uma associação consigo própria... * 1 sub-departamento Departamento * 1 professor assistente Docente “um departamento universitário pode conter outros departamentos” “um docente, enquanto professor, pode ser responsável por outros docentes, designados por assistentes” “um docente, enquanto assistente, está dependente de um outro docente, designado por professor” Modelação

56 Modelação da Estrutura
Uma visão pragmática: Classes Relações Diagramas de Classes Modelação

57 Diagramas de classes Representam o modelo de domínio (a visão lógica) do sistema, expressa pelo conjunto de todas as suas classes e respectivas relações. Elementos UML que são representados num diagrama de classes: Classes e sua estrutura interna Relações Tipos (Associações, Agregações, Dependências, Generalização) Multiplicidade Navegabilidade Nome da relação e papel de cada interveniente .... Modelação

58 Modelação

59 Modelação

60 Modelo de Dinâmica Casos de Uso
Modelação

61 Organização de Casos de Uso - Generalização
Uma relação de generalização entre casos de utilização permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou alternativamente, permite definir casos mais abstractos a partir de casos concretos pelo mecanismo da redução ou generalização O caso de uso filho herda o comportamento e semântica do seu pai; o filho pode substituir especificações definidas no seu pai. Modelação

62 Casos de Uso - Generalização de Actores
Cliente generalização de actores Cliente Anónimo Cliente VIP Modelação

63 Casos de Uso - Inclusão A relação de inclusão entre casos de uso corresponde a uma relação típica de delegação, significando que o caso base incorpora o comportamento do outro caso relacionado. Usa-se a relação de inclusão para evitar descreverem-se os mesmos fluxos de eventos inúmeras vezes… (reutilização) Modelação

64 Casos de Uso - Extensão Numa relação de extensão o caso base incorpora implicitamente o seu comportamento num local especificado indirectamente pelo caso que o usa. Ou seja, um caso destino pode ser estendido com o comportamento de outros casos. Uma relação de extensão permite representar: A parte de um caso que um actor vê como opcional, ou como existindo várias alternativas. Um sub-fluxo de acções que é executado apenas se determinadas condições se verificarem. Vários fluxos de acções que podem ser inseridos num determinado ponto de extensão, de forma controlada, através de uma interacção explícita com um actor. O caso de uso de base é estendido num ou mais pontos, designados por “pontos de extensão”. Atribui lugar à janela «extend» Modelação

65 Diagramas de Casos de Uso
Um diagrama de casos de uso ilustra um conjunto de Casos de Uso, de Actores, e as suas Relações, com objectivos de Modelação do contexto de um sistema, com ênfase na identificação da fronteira do sistema, dos seus actores e no significado das suas funções. Modelação dos requisitos de um sistema, consistindo na identificação do que o sistema deve fazer e independentemente de como o sistema o deve realizar. Modelação

66 Diagramas de Caso de Uso
Um diagrama de Casos de Utilização é utilizado para ilustrar a interacção entre os actores e os casos de utilização pelo envio recíproco de “estímulos”. Uma associação de comunicação entre um actor e um caso de utilização implica uma interacção entre ambos. Cada função nesta associação tem uma propriedade de navegação, que indica a direcção da comunicação. Se for bidireccional, omite-se a representação da direcção. Actor Use Case A Actor Use Case A Actor Use Case A Modelação

67 Diagramas de Caso de Uso - Exemplo
A Máquina de Bebidas Cliente Comprar Bebida Agente do Fornecedor Dono Repor Bebidas Colector Retirar dinheiro Modelação

68 Diagramas de Caso de Uso – Exemplo com Inclusão
A Máquina de Bebidas Cliente Agente do Fornecedor Comprar Bebida Repor bebidas Retirar dinheiro Colector Dono Abrir a Máquina Fechar a «include» Modelação

69 Diagramas de Caso de Uso – Exemplo com Extensão
Representa-se agora a possibilidade da reposição de bebidas na máquina depender de um algoritmo considerando as marcas e número de unidades vendidas... A Máquina de Bebidas Abrir a Máquina «include» Dono Repor Bebidas Agente do Fornecedor Extension Point encher prateleiras «include» «extend» (encher prateleiras) Fechar a Máquina Repor Bebidas segundo as vendas Modelação