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 modelsGive you a set of tools to decide how to create a (good) model for a problemGive 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

Logical Model (cont’)

Body Part

Torso

0..*

~

Leg Arm Head

0..2

Leg Arm Head

0..2 1

Torso

1

Leg Arm Head1 1

X 2

X 2

L0087 - 2010-09-19

10

Logical Model (cont’)

~ 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 Head1 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

Model Normalization Example (1NF)

L0087 - 2010-09-19

25

Model Normalization Example (2NF)

L0087 - 2010-09-19

26

Model Normalization Example (3NF)

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