Get documents about "Slides da Aula T05
Document Sample
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
Programa
T01-T03 – Módulo 1
– Introdução à Modelação de Sistemas "Je n'ai fait celle-ci plus
T04-T07 – Módulo 2
longue que parce que je
– Modelação Conceptual de Sistemas n'ai pas eu le loisir de la
• T05 faire plus courte".
– Engenharia de Requisitos (Pascal - 16ª Provinciale)
– Modelo Estrutural
» Modelo de Domínio (introdução)
– Modelo de Dinâmica
» Casos de Uso
...Escrevi esta carta longa
porque não tive tempo de
T08-T11 – Módulo 3
– Ontologias
a escrever mais curta...
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
Mas o que é que isto tem a
– Temas avançados ver com a matéria de hoje?
Modelação 2
Engenharia de
Requisitos
Modelação 3
Engenharia de Requisitos
1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos
Modelação 4
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 5
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 6
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 Análise de Documentação Validação dos
requisitos Requisitos e dos Requisitos Requisitos
(“elicitation”) Negociação
Documento de
Requisitos
Especificação do
Sistema...
Modelação 7
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 8
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 9
Classificação de Requisitos Não Funcionais
segundo o IEEE-Std 830 – 1993
• Requisitos de desempenho
• Requisitos de interface Em cada projecto
• Requisitos operacionais
• Requisitos de recursos
concreto devem
• Requisitos de verificação ser usadas as
• Requisitos de aceitação classes que se
• Requisitos de documentação considerem
• Requisitos de segurança
• Requisitos de portabilidade relevantes...
• Requisitos de qualidade
• Requisitos de fiabilidade
• Requisitos de manutenção
Modelação 10
Mais exemplos de Requisitos Funcionais
(do livro “Systems analysis and design with UML”)
Modelação 11
Mais exemplos de Requisitos Não Funcionais
(do livro “Systems analysis and design with UML”)
Modelação 12
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 13
Engenharia de Requisitos
1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos
Modelação 14
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 Análise de Documentação Validação dos
requisitos Requisitos e dos Requisitos Requisitos
(“elicitation”) Negociação
Documento de
Requisitos
Especificação do
Sistema...
Modelação 15
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 16
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 17
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 18
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 19
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 20
Análise comparativa da JAD
• Riscos
• Vantagens
– Exige que os vários
– Menos 15% do tempo em participantes tenham tempo
comparação com as disponível para todas as
entrevistas individuais sessões
– Permite desenho criativo e – Exige grande esforço de
desenvolvimento rápido preparação (ou a sessão pode
– Os utilizadores sentem-se não ter sucesso)
integrados no – Se o relatório de uma sessão
desenvolvimento do sistema estiver incompleto pode por em
– Permite ao analista efectuar o risco a próxima sessão
levantamento de requisitos – Cultura organizacional pode
com os utilizadores não ser na realidade
compatível com a JAD
Modelação 21
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 22
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 23
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 24
Prototipagem em papel,,,
Modelação 25
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 26
Engenharia de Requisitos
1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos
Modelação 27
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 Análise de Documentação Validação dos
requisitos Requisitos e dos Requisitos Requisitos
(“elicitation”) Negociação
Documento de
Requisitos
Especificação do
Sistema...
Modelação 28
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 29
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 30
Matrizes de Interacção
• 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)
Requirement R1 R2 R3 R4 R5 R6
R1 0 0 1000 0 1 1
R2 0 0 0 0 0 0
R3 1000 0 0 1000 0 1000
R4 0 0 1000 0 1 1
R5 1 0 0 1 0 0
R6 1 0 1000 1 0 0
Modelação 31
Engenharia de Requisitos
1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos
Modelação 32
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 Análise de Documentação Validação dos
requisitos Requisitos e dos Requisitos Requisitos
(“elicitation”) Negociação
Documento de
Requisitos
Especificação do
Sistema...
Modelação 33
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 34
Sobre Linguagens
de Modelação
Perspectiva Geral
Modelação 35
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 36
Diagrama de Classes dos diagramas da linguagem UML 2.0
Comportamento e Estrutura
(http://www.omg.org/) Modelação 37
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 38
http://www.omgsysml.org/)
Diagrama de Classes dos diagramas da linguagem SysML
Modelação 39
Modelo Estrutural
Modelo de Domínio
Modelação 40
• 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 41
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 42
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
Estereótipo de
representação Nome Atributo da classe
de uma classe atribuirNome()
em UML
retornarNome() Operações da classe
Modelação 43
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 44
Modelação da Estrutura
• Uma visão pragmática:
– Classes
– Relações
– Diagramas de Classes
Modelação 45
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 Carro
Nome Modelo
atribuirNome() VelocidadeMax()
retornarNome() ConsumoMedio()
Modelação 46
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 47
Relações - Generalização
Shape
Uma generalização é uma relação origin
entre um elemento geral move()
(superclasse) e um tipo mais resize()
display()
específico desse elemento
(subclasse).
Rectangle Circle Polygn
Geralmente conhecida como uma corner: Point radius: Float points: List
relação “is-a” ou “is-a-kind-of”.
Square
No contexto de classes usam-se generalizações para ilustrar
relações de herança.
Modelação 48
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 49
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 1
Zero ou mais 0..* ou apenas *
Uma ou mais 1..*
Zero ou uma 0..1
Intervalo especificado 2..4
Valores e intervalos múltiplos 2, 4..6
Modelação 50
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 51
Relações - Associação
Modelação 52
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
1 Ordem
1 1
1 1
1 4
Tampo 2..6
Tampo Perna
Perna
Modelação 53
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 empregador
Empresa
empregado
Tarefa
descrição
dataInício classe associação
salário
Modelação 54
Relações - Associações Reflexivas
Quando uma classe tem uma associação consigo própria...
*
Departamento professor 1
sub-departamento
1 Docente *
assistente
“um departamento • “um docente, enquanto
universitário pode professor, pode ser responsável
conter outros por outros docentes, designados
departamentos” por assistentes”
• “um docente, enquanto
assistente, está dependente de
um outro docente, designado por
professor”
Modelação 55
Modelação da Estrutura
• Uma visão pragmática:
– Classes
– Relações
– Diagramas de Classes
Modelação 56
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 57
Modelação 58
Modelação 59
Modelo de
Dinâmica
Casos de Uso
Modelação 60
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 61
Casos de Uso - Generalização de Actores
generalização
de actores
Cliente
Cliente Anónimo Cliente VIP
Modelação 62
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 63
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 «extend»
Atribui lugar
à janela
Modelação 64
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 65
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.
Use Case
A
Actor
Use Case
A
Use Case Actor
A
Actor
Modelação 66
Diagramas de Caso de Uso - Exemplo
A Máquina de Bebidas
Comprar Bebida
Cliente
Repor Bebidas
Agente do
Fornecedor Dono
Retirar dinheiro
Colector
Modelação 67
Diagramas de Caso de Uso – Exemplo com Inclusão
A Máquina de Bebidas
Comprar Bebida
Cliente
Repor bebidas
Agente do
«include» Dono
Fornecedor
Abrir a «include»
Máquina
«include»
Retirar dinheiro
Colector
Fechar a
«include»
Máquina
Modelação 68
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
«include» Abrir a
Máquina
Repor Bebidas
Agente do Extension Point Dono
Fornecedor encher prateleiras
«include»
«extend» Fechar a
(encher prateleiras)
Máquina
Repor Bebidas
segundo as vendas
Modelação 69
