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

Modelação

Aula T05Engenharia 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

Modelação 2

ProgramaT01-T03 – Módulo 1

– Introdução à Modelação de SistemasT04-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


1. O Processo de Eng.ª de Requisitos

2. Levantamento de Requisitos

3. Análise de Requisitos

4. 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 email 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...Exemplos:– 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

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

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

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ção1.1 Propósito do documento 1.2 Contexto do produto1.3 Definições, acrónimos e abreviaturas1.4 Referências1.5 Visão geral do documento

2. Descrição geral2.1 Perspectiva do produto2.2 Funções do produto2.3 Características dos utilizadores2.4 Restrições gerais2.5 Assunções e dependências

3. Requisitos específicosEste 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í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.

Níveis de Maturidade do processo de Engenharia de Requisitos numa organização

Modelação 14






Modelação 15



(“elicitation”)







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

– 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

• 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

• 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

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

http://blog.nicholas.eti.br/2006/06/23/jad-joint-application-design/

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

Modelação 25

Prototipagem em papel,,,

Modelação 26

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

Casos de Uso (ver continuação adiante...)

Modelação 27






Modelação 28



(“elicitation”)







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

Requirement R1 R2 R3 R4 R5 R6R1 0 0 1000 0 1 1R2 0 0 0 0 0 0R3 1000 0 0 1000 0 1000R4 0 0 1000 0 1 1R5 1 0 0 1 0 0R6 1 0 1000 1 0 0

• Técnica para determinar as interacções entre requisitos, evidenciando conflitos e sobreposições:– 0 => Requisitos independentes– 1 => Requisitos em conflito (contraditórios)– 1000 => Requisitos sobrepostos (dizem a mesma

coisa, total ou parcialmente)

Modelação 32






Modelação 33



(“elicitation”)







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

Modelação 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.0Comportamento e Estrutura

(http://www.omg.org/)

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

http://www.omgsysml.org/)

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

ClassesUma classe representa um conceito ou categoria de objectos que partilham:– atributos (que determinam o estado dos objectos)– operações (que definem o comportamento)

Pessoa

Nome

atribuirNome()

retornarNome()

Nome da classe

Atributo da classe

Operações da classe

Estereótipo de representação de uma classe

em UML

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

Pessoa

Nome

atribuirNome()

retornarNome()

Carro

Modelo

VelocidadeMax()

ConsumoMedio()

Relação

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

originmove()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”.

Rectanglecorner: Point

Circleradius: Float

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

1

0..* ou apenas *

1..*

0..1

2..4

2, 4..6

Não especificada

Apenas uma

Zero ou mais

Uma ou mais

Zero ou uma

Intervalo especificado

Valores e intervalos múltiplos

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

... uma Pessoa pode existir sem uma Empresa...

Modelação 52


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…»

Perna

1

Mesa

Ordem

2..6Perna

1

Mesa

4

Tampo

1

1Tampo

1

1

Modelação 54


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

Pessoa Empresa1..* *

empregado empregador

Tarefa

descriçãodataIníciosalário

classe associação

Modelação 55

Relações - Associações Reflexivas

Quando uma classe tem uma associação consigo própria...

• “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”

*1professor

assistenteDocente

“um departamento universitário pode conter outros departamentos”

*

1sub-departamento

Departamento

Modelação 56



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

• 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

Organização de Casos de Uso - 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

Cliente VIP

generalização de actores

Cliente Anónimo

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 lugarAtribui 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

Agente do Fornecedor

Comprar Bebida

Repor Bebidas

Retirar dinheiro

Colector

Dono

Modelação 68

Diagramas de Caso de Uso – Exemplo com Inclusão


Cliente


Comprar Bebida

Repor bebidas

Retirar dinheiroColector

Dono

Abrir a Máquina

Fechar a Máquina

«include»

«include»

«include»

«include»

Modelação 69

Diagramas de Caso de Uso – Exemplo com Extensão


Repor Bebidas Dono

Abrir a Máquina

Fechar a Máquina

«include»

«include»


Extension Pointencher prateleiras

Repor Bebidassegundo as vendas

«extend»(encher prateleiras)

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

Documents

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