Introduction to Conceptual Modeling

Introduction to Conceptual Modeling 10/14/2014

IISSI 1

1. What is conceptual modeling?

2. Basic concepts

3. UML notation (class & object diagrams)

4. Entity-Relationship Diagrams

5. Conceptual model development

© D

iseño d

e A

mador

Durá

n T

oro

, 2011

© D

iseño d

e A

mador

Durá

n T

oro

, 2011

Introduction to Conceptual Modeling

Software Engineering and Databases Group

Department of Computer Languages and Systems

University of Seville

October 2014


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Learning objectives

– Understand the need for conceptual modeling and

its place in the development process.

– Know the basic concepts of conceptual modeling.

– Know the main notations for conceptual modeling.

– Be able to develop a conceptual model for an

information system from information about the

problem domain and some requirements.

October 2014 Introduction to Software Engineering and Information Systems 1


IISSI 2


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• What is conceptual modeling?

– Conceptual modeling is a requirements analysis

and database design technique.

• As an analysis requirements technique…

– It helps to identify problems in the requirements

before development starts, avoiding unnecessary

costs.

• As a database design technique…

– It enables the abstract representation of the

relevant concepts and facts from the problem

domain and their further transformation into a

database scheme.



2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• What is the problem domain?*

– Area of expertise or application that needs to be

known in order to solve a problem.

– In the context of information systems, the problem

domain is the set of interrelated concepts which

are necessary to understand the customer

business, and therefore to understand their needs

and to propose a suitable solution.


*Source: Development framework of the Junta de Andalucía (MADEJA), requirement engineering area.


IISSI 3


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• When is the conceptual model used?

• Regardless of the life cycle, it is used during

the analysis.


Analysis

Design

Implementation

Testing

Maintenance

Requirements


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Requirements traceability

– All the elements of a conceptual model must be

traced back towards those requirements that

justifies them, usually information requirements

and business rules.


c lass Ejemplo trazabi l idad

«entidad»Usuario

nombreapellidosfechaNacimientoemail

RI-001 - El sistema deberá almacenar la información correspondiente a los usuarios del sistema. En concreto: ...

RF-004 - El sistema deberá enviar automáticamente un email a los usuarios cuando ...

«trace»

«trace»


IISSI 4


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Conceptual modeling standard

• UML (Unified Modeling Language).

• Join result of several previous approaches.

• Managed by the OMG (Object Management Group).

• Widely used in the software industry.

• Multiple available tools.

• It has 14 types of diagrams for software modeling

(version 2.4.1, August 2011).

• In conceptual modeling, the mainly used diagrams are:

– Class diagrams

– Object diagrams



2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Basic concepts of conceptual modeling

– Entity class

• Attribute

– Association

• Role

• Multiplicity

– Object (instance of a class)

– Link (instance of an association)

– Generalization/specialization

– Composition



IISSI 5


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Entity class

– It represents a concept which is important in the

problem domain and for which the system must

store information, as specified (or deduced) from

some requirements.

– Classes are named with a noun in singular form.


c lass Ejemplos de c lases

«entidad»Alumno

nombrefechaNacimiento...

«entidad»Asignatura

códigonombre...

«entidad»Matrícula

númerofechatieneBeca...


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Entity class attributes

– They represent properties of a concept which is

important in the problem domain and for which

the system must store information, as specified

(or deduced) from some requirements.

– Attributes are named with a noun in singular form.

– Attributes values must be atomic.


c lass Ejemplos de c lases

«entidad»Alumno

nombrefechaNacimiento...


códigonombre...




IISSI 6


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Association between entity classes

– Represents some kind of relation between two or

more concepts that are relevant in the problem

domain and for which the system must store

information, as specified (or deduced) from some

requirements.


c lass Ejemplos de asoc iac ión


códigonombre...



0..*

apareceEn

0..*


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Association between entity classes

– It is named using a verb in singular third person

and prepositions if needed.

– It must form a comprehensible sentence when

reading it together with the roles.




códigonombre...



0..*

apareceEn

0..*


IISSI 7


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Role of one association end

– Role played by each one of the classes in the

association.

– By default, it is its own name.

– They must be specified in associations of a class

with itself or when there exist more than one

association between the same two classes.


c lass Ejemplos de roles

Persona Vuelo Aeropuertosalida

*

saleDe origen

1

hijo0..*

esPadreDe

padre0..2

llegada

*

l legaA destino

1


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Multiplicity of one association end

– Given an object of a class, it indicates the

minimum and maximum number of objects of the

other class to which it can be associated using

association links.


c lass Ejemplos de roles

Persona Vuelo Aeropuertosalida

*

saleDe origen

1

hijo0..*

esPadreDe

padre0..2

llegada

*

l legaA destino

1



códigonombre...



0..*

apareceEn

0..*


IISSI 8


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Objects

– Every instance or occurrence of a class.

• Links

– Every instance or occurrence of an association.


c lass Equipos de fútbol

«entidad»Equipo

nombre...

«entidad»Jugador

nombre*

juegaEn

0..1


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Objects

– Every instance or occurrence of a class.

• Links

– Every instance or occurrence of an association.


object Equipos de fútbol

«entidad»

j1 :Jugador

«entidad»

j2 :Jugador

«entidad»

e1 :Equipo

«entidad»

e2 :Equipo

«entidad»

j3 :Jugador

«entidad»

j5 :Jugador

«entidad»

j4 :Jugador

juegaEn

juegaEnjuegaEn

juegaEn

juegaEn

e1 : Equipo

nombre = "Sevilla FC"

e2 : Equipo

nombre = "Xerez CD"

j1 : Jugador

nombre = "Antoñito"

j2 : Jugador

nombre = "Redondo"

j3 : Jugador

nombre = "Kanouté"

j4 : Jugador

nombre = "Negredo"

nombre = "Jesús Navas"

j5 : Jugador

nombre = "Luis Fabiano"

J6 : Jugador

juegaEn

juegaEnjuegaEn

juegaEn

juegaEn


IISSI 9


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Generalization-Specialization

– Sometimes, several concepts of the problem

domain have relations of type is-a, for example:

– This concepts usually have common properties,

that appears as attributes or common associations

in the conceptual model.


vehicle

truck

motorcycle

car

Is-a

Is-a

Is-a


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Generalization/Specialization


c lass Ejemplo de general izac ión

Persona

Automóvi l

matrículanúmeroBastidormodeloplazas

Camión

matrículanúmeroBastidormodelotonelajeejes

Motoc ic leta

matrículanúmeroBastidormodelocilindrada

Seguro

compañianúmeroPólizatipoprecio

asegurado 1

tieneSeguro

0..1

0..1

t ieneSeguro

asegurado 1

0..1

t ieneSeguro

asegurado 1

propietario

0..1

esPropietarioDe

**

esPropietarioDe

propietario

0..1

*

esPropietarioDe

propietario 0..1


IISSI 10


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Generalization/Specialization

– The most general class (the superclass), contains

all the common properties (attributes and

associations), inherited by the specific classes

(subclasses).


Sp

ecia

lizati

on

Gen

era

izati

on


Automóvi l

plazas

Camión

tonelajeejes

Persona

Motoc ic leta

cilindrada

Vehículo

matrículanúmeroBastidormodeloSeguro


0..1 tieneSeguro

asegurado

1

propietario

0..1 esPropietarioDe *

{completa, disjunta}


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Generalization-Specialization

– All instances of the subclasses are also instances

of the superclass.

– Generalization is a transitive and antisymmetric

relation.


Sp

ecia

lizati

on

Gen

era

lizati

on


Automóvi l

plazas

Camión

tonelajeejes

Persona

Motoc ic leta

cilindrada

Vehículo



0..1 tieneSeguro

asegurado

1

propietario




IISSI 11


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Composition

– Special association that represents the concept of

being-part-of:

• A part only belongs to one whole.

• A part cannot exists without being part of one whole.

• The whole elimination implies the elimination of all

its parts.

• It is a transitive and antisymmetric relation.

• It can be recursive.


c lass Ejemplo de composic ión

Fac tura L íneaDeFactura

1..*{ordered}


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for entity classes

– With the «entity» stereotype, we indicate that the

class represents and entity and not a class of an

object-oriented programming language.

– In conceptual modeling, we will assume the

«entity» stereotype by default.


Name area (compulsory)

Attributes area (optional, can be hidden if needed)

c lass Notac ión c lase

«entidad»NombreClase

atributo1: Tipo1atributo2: Tipo2...: ...atributoN: TipoN


IISSI 12


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for entity classes

– In conceptual modeling, the types of attributes are

not usually specified (except for enumerations).

– [0..1] means that it is an optional attribute, i.e.

that there will be moments in which it its value will

be unknown and therefore it will be represented

by a null value.


The value of atributo2 can be null

c lass Notac ión c lase

NombreClase

atributo1atributo2 [0..1]...atributoN


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for associations


Role name Role played by each one of the classes of the association. By default, it is the class name in lowercase.

Association name It is optional and must be a verbal form with sense when reading it with the roles. It is read from left to right and from top to bottom. If it must be read other way, direction must be indicated.

Multiplicity It indicates the minimum and maximum number of class instances that are related to a specific instance of the other class. In multiple multiplicities, order can be indicated using {ordered}.

Usual values 0..1 : optional 1..1 : compulsory 0..* : multiple optional 1..* : multiple compulsory * : same as 0..* 1 : same as 1..1

A BrolA rolB

multA multB

nombre


IISSI 13


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011

obj1 : Clase1

atrib1 = valor1atrib2 = valor2…atribn = valorn

obj2 : Clase2asociaciónA

obj3 : Clase2asociaciónA

obj4 : Clase3asociaciónB


• UML notation for objects and links


Class and name of the object Must be highlighted for not confusing them with a class.

Names and values of attributes Optional, it shows the values of the attributes of the object.

Links Identified using the name of the association, highlighted.


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for objects and links


Multiobject notation Shows multiple objects without identifying them individually.

c1 : Cliente

lf1 : LíneaDeFactura

cantidad = 3precio = 12,50 €





p1 : Producto

p3 : Producto

p2 : Producto

contieneA

contieneA

contieneA

f1 : Factura

número = 8765fechaEmisión = 01/06/2011

emitidaA

c1 : Cliente : Factura

emitidaA


IISSI 14


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for classifications

– Complete/Incomplete classification

• {complete}: instances of the superclass must be

instances of at least one subclass, superclass is

abstract.

• {incomplete}: there can be instances of the

superclass that are not instances of any subclass.


Constraints Shows if the classification is complete/incomplete and disjoint/overlapped.

c lass Notac ión c lasi f icac ión

Superc lase

atribComún1atribComún2...

Subc lase1

atribPropio1atribPropio2...

Subc laseN

atribPropioXatribPropioY...

...

{restricciones}


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011



– Disjoint/Overlapped classification

• {disjoint}: superclass instances can be instances of

only one subclass.

• {overlapped}: superclass instances can be

instances of one or more subclasses.


Constraints Shows if the classification is complete/incomplete and disjoint/overlapped.

c lass Notac ión c lasi f icac ión

Superc lase

atribComún1atribComún2...

Subc lase1

atribPropio1atribPropio2...

Subc laseN

atribPropioXatribPropioY...

...

{restricciones}


IISSI 15


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011



– {complete, disjoint} implies a partition of the set

of instances of the superclass.


Motorcycles Cars

Trucks

Vehicles


Automóvi l

plazas

Camión

tonelajeejes

Persona

Motoc ic leta

cilindrada

Vehículo



0..1 tieneSeguro

asegurado

1

propietario



Abstract class The name of abstract classes is written in italics.


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011




c lass Ejemplo comunidad universi taria

MiembroCU

Alumno Empleado

PAS PDI


{completa, solapada}


IISSI 16


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for compositions


Composite The black diamond identifies the composite. Its multiplicity is always 1, so there is no need to indicate it.

c lass Notac ión composic ión

Compuesto Componentemult

c lass Ejemplo fac tura

Fac tura

númerofechaEmisión

L íneaDeFac tura

cantidadprecio

Cl iente Produc to

*

contiene

1

*

emitidaA

1

1..*{ordered}


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for association classes

– Sometimes it is needed to add information to the

associations, turning them into classes.


c lass Ejemplo c lase asoc iac ión

Proyec to

nombrepresupuesto

Empleado

nombre *

trabajaEn

*


Proyec to

nombrepresupuesto

Empleado

nombre

Esfuerzo

horas

*

trabajaEn

*

how many hours does each

employee work on each project?


IISSI 17


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for associations classes

– Example: the hours that an employee works on a

project are neither properties of the employee nor

the project, but of the association between them.


e1 : Empleado

p1 : Proyecto

trabajaEn

e2 : Empleado

e3 : Empleado

p2 : Proyecto

f1 : Esfuerzo

horas = 20

trabajaEn

trabajaEn

trabajaEn

f2 : Esfuerzo

horas = 15

f3 : Esfuerzo

horas = 7,5

f4 : Esfuerzo

horas = 25trabajaEn

f5 : Esfuerzo

horas = 12


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• UML notation for associations classes

– It is also possible to model them as a class

component of the participating classes.

– Both models are equivalent.



Proyec to

nombrepresupuesto

Empleado

nombre

Esfuerzo

horas

*

trabajaEn

*

c lass Ejemplo c lase asoc iac ión con composic ión

Empleado

nombre

Proyec to

nombrepresupuesto

Esfuerzo

horas* *


IISSI 18


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Notation for constraints

– They allow additional information in the model

which cannot be expressed in any other way.


c lass Ejemplo de restricc ión

Fac tura

númerofechaEmisión

L íneaDeFac tura

cantidadprecio

Cl iente Produc to

{fac turas sin dupl icados:un mismo producto no debe aparecer dos veces en la misma factura.}

1..*{ordered}

*

emitidaA

1

*

contiene

1

Notation Constraints are represented by notes. The text must be between curly braces, indicating the name of the constraint and its description. Optionally, it can be linked to the affected entities.


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Notation for enumerations

– Define a type that can be used in the class

attributes.

– The attributes are the possible values.


c lass Notac ión enumerados

«enumerado»Sexo

hombremujer

«enumerado»VíaPúbl ica

calleplazaavenidacarretera

«enumerado»Categoría

infantilaventurascienciaFiccióndrama


IISSI 19


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Entity-relationship diagrams

– Published by Peter Chen en 1976.

– Previous alternative to UML for

conceptual modeling.


Entidadatributo

identificador

atributo mín:máx

mín:máxinterrelación atributo

identificador

atributo

Entidad

P. Chen, The Entity-Relationship Model - Toward a Unified View of Data.

ACM Transactions on Database Systems 1 (1): 9–36, 1976.


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Entities

– Regular

– Weak

• Relationships


Jugadornombre

idJugador

posición país

nombre

Equipo

fecha

Partido

0:N

0:2

esPadreDePersonanombre

idPersona

Padre

Hijo

0:N 0:1juegaEnJugadornombre

idJugador

posición país

nombre

Equipo


IISSI 20


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Equivalence of notations


10:NrealizadaPor

Asignaturanombre

código

Matricula

Asignatura0:N

0:N

nombre

idAlumno

AlumnoMatrícula

apareceEn

número

fecha

c lass Ejemplo matrícula

Matrícula

númerofecha

Asignatura

códigonombre

Alumno

idAlumnonombre*

real izadaPor

1*

apareceEn

*


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Conceptual model development

– Recommended steps:

1. Analyze the information about the problem domain

(glossary) and requirements.

2. Identify possible entities and attributes.

3. Identify possible associations.

4. Incrementally build the conceptual model identifying

the multiplicity of the associations.

5. Identify classifications between entities with common

properties (attributes and/or associations).

6. Identify composition between entities.

7. Add the constraints that cannot be graphically

expressed.

8. Validate with possible scenarios using object diagrams.

9. Register all semantic problems that must be discussed

with customers and users.



IISSI 21


2. Basic concepts




© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Bibliography

– C. Larman, UML y Patrones.

Ed. Prentice-Hall, 1999.

• Chapters 9 to 12

– C. Larman, UML y Patrones (2ª

edición). Ed. Prentice-Hall, 2003.

• Chapters 10 to 12

– M. Fowler, UML Distilled (3rd

edition). Ed. Addison-Wesley,

2004.

• Chapter 3


Documents

Introduction to Conceptual Modeling