Modelação
Aula T02 – Modelação Conceptual
Universo do Discurso e Casos de Uso
Referências:
– Conceptual Modeling of Information Systems (Capítulos 1 e 15)
– UML, Metodologias e Ferramentas CASE (Capítulos 1, 2 e 5)
José Borbinha
Programa (Aulas Teóricas)
T01-T02 (2 aulas) – Módulo 1
– Introdução à Modelação de Sistemas
T03-T06 (4 aulas) – Módulo 2
– Modelação Conceptual: Domínio
T07-T11 (5 aulas) – Módulo 3
– Modelação Conceptual: Comportamento
T12-T15 (4 aulas) – Módulo 4
– Ontologias
T16-T19 (4 aulas) – Módulo 5
– Modelação Conceptual: Arquitectura
T20-T21 (2 aulas) – Módulo 6
– Modelação Conceptual: Metodologias
T22-T23 (2 aulas) – Módulo 7
– Ontologias: Temas avançados
T24-T25 (2 aulas)
– Modelação Conceptual: revisões e exercícios
Modelação
2
...Sistema?...
• Uma definição de sistema: um conjunto entidades que
interagem entre si com o objectivo de atingir um
determinado objectivo.
• Regra geral o objectivo de um sistema é a sua sobrevivência, o que
pode ser levado à letra no caso dos sistemas biológicos, mas
também em qualquer outro contexto (um sistema solar é sistema
enquanto conseguir manter o seu equilíbrio, tal como uma
organização, uma máquina, ...)
• Um “sistema de informação” pode ser assim definido como:
– um conjunto de entidades (humanas e tecnológicas) interagindo
entre si com o objectivo de satisfazer adequadamente as
necessidades de informação de uma organização e respectivos
processos de negócio!
Modelação
3
Sobre Modelação e Eng.ª de Software
Engenharia de Software é a aplicação de um processo
sistemático, disciplinado, e quantificado ao desenvolvimento,
operação e manutenção de software; ou seja, a aplicação de
técnicas de engenharia ao software (IEEE, 93)
• As actividades da Eng.ª de Software podem ser agrupadas
em três grandes fases: concepção, implementação e
manutenção
• A concepção de um sistema é efectuada sobre os requisitos,
os quais por sua vez derivam dos objectivos de negócio. É
nesta fase que a modelação é especial importante.
• Após a concepção de um sistema procede-se então à
concepção do software (na concepção da Eng.ª de
Software)
Modelação
4
Sobre Eng.ª de SW e processo de
desenvolvimento de sistemas
• Concepção do Sistema




Especificação de Requisitos: descrição do problema na
óptica do cliente.
Análise: descrição do problema na óptica do engenheiro
de sistema
Desenho: especificação da solução em termos da
plataforma e tecnologia computacional usada.
Desenvolvimento e Manutenção do Sistema




Concretização da solução desenhada...
Testes ...
Aceitação ...
Manutenção ...
Modelação
5
Universo do
Discurso
Modelação
6
Modelação Conceptual !!!
• “Na área de sistemas de informação usamos
o termo Modelação Conceptual para a
actividade de descoberta e descrição do
conhecimento geral que um determinado
sistema de informação necessita ter”
(Conceptual Modeling of Information Systems, pag. xi)
• Nota de tradução importante
– “elicit” ≈ deduzir, descobrir, obter gradualmente
– “elicit” ≠ licitar !!!
Modelação
7
De volta à definição de sistema
Um sistema tem três funções principais:
– Memória: manter a representação do estado de
um domínio
– Informar: dar informação (ao exterior) sobre o
estado de um domínio
– Actuar: agir para mudar o estado de um domínio
(Conceptual Modeling of Information Systems, pag. 3)
Modelação
8
Domínio ???
 Um domínio é o fragmento do mundo
real sobre o qual é focada a tarefa de
modelação e construção de um
sistema.
 Exemplos de domínios:
– Sistema bancário nacional
– Sistema universitário nacional
– O futebol
– ...
• Geralmente ao domínio também se
dá o nome de universo do discurso
(UoD = “Universe of Discourse”)
Modelação
9
Domínio / UoD
 Na área de sistemas de informação assumimos
que um domínio consiste num número de
objectos e de relações entre eles, que são
classificadas em conceitos. O estado de um dado
domínio, num dado momento, consiste assim
num grupo de objectos, num grupo de relações,
e num conjunto de conceitos segundo os quais
esses objectos e relações são classificados.
(Conceptual Modeling of Information Systems, pag. 10)
 Classificação é o processo que associa um
objecto do domínio a um conceito do domínio.
Modelação
10
Conceitos
• Um conceito é algo que concebemos no
nosso entendimento através da generalização
de certas instâncias.
• Um conceito tem intenção e extensão:
– Intenção são as propriedades partilhadas
por todas as instâncias
– Extensão são todas as possíveis instâncias
desse conceito
(Conceptual Modeling of Information Systems, pag. 12)
Modelação
11
Esquemas Conceptuais
• A especificação do conjunto de
conceitos de um domínio é o
esquema conceptual desse
domínio
– Para um mesmo domínio podemos
definir mais que um esquema
conceptual, dependendo da
perspectiva e dos objectivos...
Modelação
12
Esquemas Conceptuais mais em detalhe
• O modelo de um domínio do sistema, ou base de
informação*, são as entidades e relações desse domínio
(conceito a desenvolver nas próximas aulas...)
*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 (a desenvolver mais adiante no semestre...)
• Ao conjunto formado pelo esquema estrutural e pelo
esquema de comportamento de um sistema dá-se o
nome de esquema conceptual.
Modelação
13
De volta ao Sistema
•
Para poder cumprir as suas funções Memória, Informar
e Actuar, um sistema necessita de ter conhecimento do
seu domínio e das funções que tem de executar.
• Isto é, temos de definir o estado que o
sistema deve representar e as suas regras de
consistência de representação (função
Memória) e as mudanças potenciais de
ocorrer nesse estado (função Actuar).
Finalmente, temos ainda de garantir ao
sistema capacidade de inferência sobre o seu
estado (função Informar).
Modelação
14
Modelos
• Um modelo é uma interpretação de um sistema
segundo um determinado ponto de vista,
envolvendo a sua especificação a um certo nível
de abstracção e de detalhe.
 Linguagem de Modelação



É a estruturação e especificação da estrutura de
conceitos segundo uma ou mais linguagens.
Linguagens podem ser formais ou informais,
textuais ou gráficas.
No caso de linguagens de modelação gráficas, a
notação consiste na apresentação visual dos
diferentes elementos da estrutura de conceitos
subjacente.
Modelação
15
Esquemas
• Um esquema é a especificação de um
modelo usando uma determinada
linguagem, a qual pode ser formal, informal
(e.g., linguagem natural); de texto, gráfica,
...
• Quando a representação do esquema é
gráfica designa-se usualmente por
diagrama.
Modelação
16
Casos de Uso
Modelação
17
Casos de Uso
• Relembrando:
– Ao conjunto formado pelo esquema estrutural e pelo
esquema de comportamento de um sistema dá-se o nome
de esquema conceptual
– Por outras palavras, um esquema conceptual define o
conhecimento geral que um sistema precisa para executar as
suas funções.
• Mas quais são essas funções e qual é o
conhecimento requeridos para as executar?
• Essa informação é representada, ao mais alto nível,
por casos de uso (“use cases”).
Modelação
18
Casos de Usos
• Um caso se uso representa um conjunto de acções
que um ou mais actores realizam num sistema para
obter um resultado concreto
• Um caso de uso representa uma visão externa do
sistema
– descreve o que faz um sistema (ou parte deste),
– não descreve como é que tal é realizado
Modelação
19
Casos de Uso
• Um caso de uso deve ser representado num modo
impessoal, por uma frase na voz activa, com um
verbo no infinitivo (“Gerar relatórios”, “Criar factura”,
“Calibrar roda”)
Modelação
20
Actores
• Um Actor representa uma papel (“role”) que um
utilizador pode desempenhar relativamente ao sistema a
modelar.
• Um mesmo utilizador nominal pode desempenhar
diferentes papéis, podendo, por conseguinte,
representar conceptualmente diferentes actores
(desempenhar vários “roles”).
• Um actor de um sistema pode ser um ser humano ou
outro sistema!
Cliente
Administrador
Modelação
Alarme
21
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
22
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
23
Casos de uso e Cenários
• Um cenário é uma instância de um caso de uso quando
este interactua com os actores. Representa assim uma
sequência de acções concreta que ilustra um
comportamento do sistema.
• É normal que um caso de uso possa ser descrito por
vários cenários
• Tipos de cenários:
– Principal: descreve a sequência normal de acções (“happy day
scenario”)
– Alternativo ou secundário: descreve uma sequência de acções a
considerar para além da principal, o que pode acontecer devido
a excepções ou apenas para outras acções possíveis
Modelação
24
Casos de uso e Cenários - Exemplos
Cenário principal do caso de uso “Fazer
encomenda”
• O caso inicia-se quando o cliente selecciona “Fazer
encomenda”
• O cliente introduz nome e endereço
• O cliente introduz códigos dos produtos desejados
• O sistema fornece descrição e preço dos produtos
• O cliente selecciona os produtos desejados
• O cliente fornece informação do cartão de crédito
Cenários secundários do caso
de uso “Fazer encomenda”
• Informação do cartão de
crédito incorrecta
• Pedido incompleto
• Cliente pretende pagar por
cheque
• Cliente requer atendimento
especial
• O sistema verifica a informação
• Endereço de entrega
incompleto
• Quando o pagamento é confirmado é criado e
apresentado ao cliente um código de encomenda.
Caso termina
• Produto não existe em
armazém
• O cliente submete o pedido
• Produto já não comercializado
• Produto em promoção
Modelação
25
Casos de Uso: Descrição Textual
• Pode-se especificar um caso de uso descrevendo
textualmente o fluxo de eventos, de modo a que
qualquer pessoa o possa entender.
• Tal especificação deve incluir:
–
–
–
–
Assunções
Pré-condições
Inicialização: como e quando o caso de utilização começa
Diálogo: quando é que o caso de utilização interactua com os
actores
– Conclusão: como e quando o caso de utilização termina
– Pós-condições
• Para estas descrições deve usar-se “templates”
Modelação
26
Casos de Uso: Exemplo de uma ”template”
Name
UC-8: Search
Summary
All occurrences of a search term are replaced with replacement text.
Rationale
While editing a document, many users find that there is text somewhere in the file being edited that
needs to be replaced, but searching for it manually by looking through the entire document is timeconsuming and ineffective. The search-and-replace function allows the user to find it automatically
and replace it with specified text. Sometimes this term is repeated in many places and needs to be
replaced. Other times, only the first occurrence should be replaced. The user may also wish to
simply find the location of that text without replacing it.
Users
All users
Preconditions
A document is loaded and being edited.
Basic Course of
Events
1.
2.
3.
4.
Alternative
Paths
1.
2.
3.
Postconditions
The user indicates that the software is to perform a search-and-replace in the document.
The software responds by requesting the search term and the replacement text.
The user inputs the search term and replacement text and indicates that all occurrences are to
be replaced.
The software replaces all occurrences of the search term with the replacement text.
In step 3, the user indicates that only the first occurrence is to be replaced. In this case, the
software finds the first occurrence of the search term in the document being edited and replaces
it with the replacement text. The postcondition state is identical, except only the first occurrence
is replaced, and the replacement text is highlighted.
In step 3, the user indicates that the software is only to search and not replace, and does not
specify replacement text. In this case, the software highlights the first occurrence of the search
term and the use case ends.
The user may decide to abort the search-and-replace operation at any time during steps 1, 2 or
3. In this case, the software returns to the precondition state.
All occurrences of the search termModelação
have been replaced with the replacement text.
27
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
28
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
29
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
30
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
31
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
32