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
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
"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...
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
Modelação
Mas o que é que isto tem a
ver com a matéria de hoje?
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
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
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
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
Modelação
Em cada projecto
concreto devem
ser usadas as
classes que se
considerem
relevantes...
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
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
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
– 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
– 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
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
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
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
Modelação
R4
0
0
1000
0
1
1
R5
1
0
0
1
0
0
R6
1
0
1000
1
0
0
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
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
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...)
http://www.omgsysml.org/)
Modelação
38
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
Estereótipo de
representação
de uma classe
em UML
Pessoa
Nome
Atributo da classe
atribuirNome()
retornarNome()
Modelação
Operações da classe
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
Carro
Pessoa
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
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”.
origin
move()
resize()
display()
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
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
Modelação
2, 4..6
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
1
1
1
1
1
4
Tampo
Tampo
Ordem
2..6
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.
Pessoa
*
1..*
empregado
empregador
Empresa
Tarefa
descrição
dataInício
salário
Modelação
classe associação
54
Relações - Associações Reflexivas
Quando uma classe tem uma associação consigo própria...
Departamento
*
professor 1
sub-departamento
1
“um departamento
universitário pode
conter outros
departamentos”
Docente
*
assistente
• “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
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
à janela
«extend»
Atribui lugar
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
A
Actor
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
Fornecedor
Dono
«include»
Abrir a
Máquina
«include»
«include»
Retirar dinheiro
Colector
«include»
Modelação
Fechar a
Máquina
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»
Agente do
Fornecedor
Abrir a
Máquina
Repor Bebidas
Dono
Extension Point
encher prateleiras
«include»
Fechar a
Máquina
«extend»
(encher prateleiras)
Repor Bebidas
segundo as vendas
Modelação
69