ITU - MDD – Modeling Techniques

L0087 - 2010-09-19
Redistribution and other use of this material requires written permission from The RCP Company.
ITU - MDD – Modeling Techniques
This presentation describes different modeling techniques. It has three basic
purposes:
Give you an overview of some of the different types of models
Give you a set of tools to decide how to create a (good) model for a problem
Give you an overview of some of the different modeling techniques
This presentation is developed for MDD 2010 course at ITU, Denmark

L0087 - 2010-09-19
2
What is Data Modeling all About?
 It is primary a way to analyze and describe a problem domain in terms of the
objects and relationships that are relevant for the domain
 Often the result is also used to describe the functionality of the problem domain
in terms of who does what (UML term: interaction diagrams)
 The result is the abstract syntax for the problem domain
 Especially relevant for all problems that includes technologies like
 Object oriented languages like Java, C++ or C#
 Non-trivial data structures
 Relational databases
 … which is just about 95% of all interesting problems

L0087 - 2010-09-19
3
Agenda
 Types of Models
 Processes and Techniques
 Model Normalization
 Exercise

L0087 - 2010-09-19
4
Types of Models
 A question of abstraction!
 Information Model or Conceptual Model
 Describes the relationships between the important concepts of the model
 Data Model, Logical Model or Domain Model (DOM)
 Describes the corresponding relationships between the objects that are used
to realize the concepts
 Physical Model
 Describes the logical model in a form that can be directly implemented in the
target technology – e.g. Java or SQL
 It is often possible to automatically transform a logical model to a physical model
 Hibernate and JPA are examples of this
 The different types of models is not related to meta levels – these models exists
for M1-M3

L0087 - 2010-09-19
5
Conceptual Models
 The conceptual model
 describes the things or objects of significance to a specific problem domain

The “things” are not necessarily physical objects
 is meant to collect information, and characteristics of the objects in the
domain
 describes the most important associations between pairs of those things or
objects of significance
 is often used as the basis for the central use cases
 It can very often be a good start to write down statements about the problem
domain including the basic use cases before the model is started
 To describe the human body:

A human BODY consists of a TORSO, normally connected with two LEGS,
two ARMS, and a HEAD all called BODY PARTS
 To describe entity-relationship diagrams

An ENTITY can refer to a number of other entities via RELATIONS. An
entity can have ATTRIBUTES with DATA TYPES. REFERENCES between
ENTITIES can be bi-directional. ENTITIES can inherit RELATIONS and
ATTRIBUTES from a number of super-ENTITIES.

L0087 - 2010-09-19
6
Conceptual Model (cont’)
0..1
Attribute
Relation
Entity
Data Type
0..*
0..*
0..*
attributeType
opposite
superTypes
referenceType
0..*
0..*
Body Part
Torso
0..*
~
~
0..*

L0087 - 2010-09-19
7
Logical Model
 The logical model
 typically refines the conceptual model
 typically contains all the important data structures and classes from the
application architecture along with their relations
 is normally platform independent and can thus be implemented using all
types of technologies (e.g. Java or SQL)
 is often used as the basis for the detailed use cases
 All design choices must be made as part of the logical model!
 For large systems, the logical model exists in several layers with more detailed
models for different parts of the base model

L0087 - 2010-09-19
8
Logical Model (cont’)
 Constraints and invariants can often be implemented in the abstract syntax (the
model) as well as as dynamic constraints
 To keep the model understandable, the “plain data” for entities is often kept is
separate data dictionaries (including defined methods, etc for UML models) – this
can make it relatively difficult to normalize the model as it is difficult to get a
proper overview of the model
 You should not necessarily expect to find all the conceptual concepts in the
corresponding logical models!

L0087 - 2010-09-19
9
Torso
Body Part
Torso
0..*
~
Leg Arm Head
0..2
Leg Arm Head
0..2 1
Torso
1
Leg Arm Head
1 1
X 2
X 2

L0087 - 2010-09-19
10
~ Named Element
Model Element
0..1
Typed ElementClassifier
Structural Feature
Attribute
Reference
Class
Data Type
0..*
0..*
0..*
type
opposite
superTypes
0..*

L0087 - 2010-09-19
11
Physical Model
 The physical model
 normally closely mimics the logical model
 adapts the logical model to the technical constraints of the target platform
 adds or refines the information to be platform specific
 E.g.
 Data types are often more primitive – e.g. no enumerations or compound
types in SQL
 Bi-directional references are often resolved into multiple references
 Additional performance specific data can be added in the form of indexes and
storage specifications
B
*
A
*
RelA
*
B
*

L0087 - 2010-09-19
12
Common Terms
 Organization, Problem Domain or Universe – the area of interest, the “thing” that
most be modeled
 Entity – an object or concept from the problem domain – can also be data on
relations or associations
 Relation, Association or Reference – the connection between entities
 Aggregation, Composition or Containment – a relation that implies some sort of
ownership and shared life-cycle
 Attribute – a data item on an entity
 Key or Identifier – one or more attributes that are used to (uniquely) identify an
entity
 Structural Feature – common name for references and attributes
 Entity-Relationship Diagram (ER diagram)

L0087 - 2010-09-19
13
Model Notations
 Entity-Relationship Model or Diagram (ER
diagram)
 The overall common term for all the
notations
 Also allows data attributes on relations – can
always be converted to a simpler notation
 UML 2 Class Diagram
 OMG governed notation
 Very rich
 (I use a reduced UML notation when possible to
remove as much “noise” from the diagrams as
possible)
 ((Notations is the target of many religious
discussions – the end result is usually the same
though…))

L0087 - 2010-09-19
14
Notations

L0087 - 2010-09-19
15
Modeling Tools
 Hand written on paper or a white board!
 Eclipse Ecore Tools
 UML tools such as IBM RAD and similar IDEs

L0087 - 2010-09-19
16
The Typical Process
 “Modeling Techniques” are integrated and described in many different formal
development process
 Most processes encompass the following steps:
 Identify Entities – typically corresponding to the objects in the problem
domain
 Identify Relations – typically according to the ownership or interaction
between entities
 Introduce inheritance

to collapse common behavior

to allow to-many references
 Add attributes for all identifiers and specify constraints (especially cardinality
of relations)
 Apply generic model patterns and “normalize” the model to get the best
balance between consistency and performance
 Add all other “plain data” attributes
 Practice, practice, practice… Sorry, not easy road here

L0087 - 2010-09-19
17
Shop
Relations, References and Associations
 Two basic groups of relations:
 Aggregations, Composition and Containment
 Plain References (sometimes “Reference Relations”)
 Describes ownership and life-cycle
 UML has two concepts

Aggregation denotes a weak “has a”

Composition denotes a strong “has a”
Order
*
Customer
Order Item Shop Item
* *
*
*
*

L0087 - 2010-09-19
18
Techniques – One or More Relations
Torso
0..2
Leg Arm Head
0..2 1
Torso
1
Leg Arm Head
1 1
X 2
X 2

L0087 - 2010-09-19
19
Techniques – Inheritance
Torso
Body Part
Torso
0..*
Leg Arm Head
0..2
Leg Arm Head
0..2 1
Body Part
Torso
0..* Type := “Leg”, “Arm, “Head”

L0087 - 2010-09-19
20
Techniques – Attributes with Limited Value Set
 E.g. Colors, Fonts, Vendors, Zip codes, Employees, Flight No
 Model association as a string attribute
 Model association as an enumeration attribute
 Model association as a reference to a data entity (reference table)
 Model association as a reference to different sub-types (inheritance)
 Question: what is the meta level of the reference table?
 Question: What is the associated cost of changing the application for each
solution?
 Very much related to the notion of normal forms

L0087 - 2010-09-19
21
Techniques – Attributes with Limited Value Set
Body Part
Torso
0..* Type : String
Body Part
Torso
0..* Type := “Leg”, “Arm, “Head”
Body Part
Torso
0..*
Body Part Type0..*
1
Body Part
Torso
0..*
Leg Arm Head

L0087 - 2010-09-19
22
Model Normalization
 Model normalization is a process where certain types of redundancies are
removed from a logical model
 The primary aim is to avoid inconsistencies
 The price is typically an increased performance/execution cost – especially for
SQL based databases!
 First normal form (1NF) – An entity type is in 1NF when it contains no
repeating groups of data
 Second normal form (2NF) – An entity type is in 2NF when it is in 1NF and
when all of its non-key attributes are fully dependent on its primary key
 Third normal form (3NF) – An entity type is in 3NF when it is in 2NF and when
all of its attributes are directly dependent on the primary key

 Only one key attribute
 Very often a model will go through a number of normalization/de-normalization
cycles to find the right balance between consistency and performance

L0087 - 2010-09-19
23
Model Normalization Example (0NF)

L0087 - 2010-09-19
24

L0087 - 2010-09-19
25

L0087 - 2010-09-19
26

L0087 - 2010-09-19
27
Exercises
 We have a BOOK SHOP with a number of BOOKS on stock.
 The BOOKS are sold to CUSTOMERS. A single ORDER can include many different
BOOKS to a specific CUSTOMER.
 Exercise I: Build a conceptual model for the book shop
 What meta level does the model have (M0-M3)?
 Exercise II: Build the corresponding data model for the book shop
 What normal form does the model have? Can you make the model NF3? Is it
worth it?
 Exercise III: How must be models be changed if we need to track the price of
BOOKS over time so we can draw diagrams with PRICE versus ORDERS for specific
BOOKS

L0087 - 2010-09-19
28
Syllabus (”Pensum”)
 The reading materials for this lecture is in the form of the following three
articles:
 Wikipedia on Data Modeling - http://en.wikipedia.org/wiki/Data_modeling

Overview of the concepts behind data modeling
 “Data Modeling 101” by Scott Ambler -
http://www.agiledata.org/essays/dataModeling101.html

Good introduction to the modeling process
 “UML 2 Class Diagrams” by Scott Ambler -
http://www.agilemodeling.com/artifacts/classDiagram.htm

Good over the UML 2 Class Diagram Notation

ITU - MDD – Modeling Techniques

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to ITU - MDD – Modeling Techniques (20)

More from Tonny Madsen (20)

Recently uploaded (20)

ITU - MDD – Modeling Techniques