1 model driven development with orm 2 and norma © 2007 t. halpin & neumont university terry...

68
1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University [email protected] www.orm.net

Upload: darren-norman

Post on 27-Dec-2015

222 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

1

Model Driven Developmentwith ORM 2 and NORMA

© 2007 T. Halpin & Neumont University

Terry HalpinNeumont University

[email protected]

Page 2: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

2

• ORM Features, History, and Tool Support

• The Data Modeling Process

• ORM’s Graphical Language

• Comparison with ER and UML

• Case Study

• Relational Mapping and Tool Demos

Page 3: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

3

• ORM Features, History, and Tool Support• The Data Modeling Process

• ORM’s Graphical Language

• Comparison with ER and UML

• Case Study

• Relational Mapping and Tool Demos

• Temporal aspects of Data Modeling

Page 4: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

4

• A conceptual approach for modeling, querying, and transforming data

• Fact-oriented (attribute-free).

All facts are modeled as relationships (unary, binary, ternary …)1

• Semantic stability

(no remodeling or requerying to talk about an attribute)

• Facilitates validation by verbalization & population

• Richly expressive graphical constraint language

(compared with industrial ER, or UML class diagrams).

Object-Role Modeling (ORM)

1 The OMG’s SBVR approach is also fact-oriented.

Page 5: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

5

Modeling Approach = Modeling Procedure(s) + Modeling Language(s)

ORM includes procedures for conceptual modelingand for mapping (transforming) ORM models and queries to attribute-based models(e.g. Relational, OO, ER, UML, XSD, OWL).

ORM includes graphical and textual modeling languagesand a textual query language.

Page 6: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

ORM History and Tool Support

• Originated in 1970s in Europe

• Various flavors (NIAM2007, ORM 2, FCO-IM etc.)

• First ORM tools developed at Control Data labs in Brussels (IAST, RIDL*)

• USA tools: InfoDesigner, InfoModeler, ActiveQuery, ORM Source Model solution in Microsoft Visio for Enterprise Architects

• Current European tools: CaseTalk, Infagon, CogNIAM

• ORM 2 tool under development: NORMA

(open source plug-in to Visual Studio .NET)

This presentation focuses on ORM 2 (2nd generation ORM)

6

Page 7: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

7

• ORM Features, History, and Tool Support

• The Data Modeling Process• ORM’s Graphical Language

• Comparison with ER and UML

• Case Study

• Relational Mapping and Tool Demos

• Temporal aspects of Data Modeling

Page 8: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Going from a Going from a process use process use

casecaseto a data to a data model model

Client(.nr)

uses

Account(.nr)

AccountType(.code)

has

holdsMoneyAmount

(USD)

Transaction(.nr)

is oninvolves

is of

TransactionType(.code)

ATM

Deposit

Withdraw

Transfer betweenaccounts

Get Balance

Client

8

Page 9: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

• For data modeling, we need DATA use cases

(cases of data being used), e.g.– Sample reports– Sample input forms– Sample queries

• How to go from a data use case to a data model?– Have the domain expert verbalize the data– Rephrase this as unambiguous, elementary facts– Add and validate the business rules constraining the data

Data Use Cases

9

Page 10: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

• The domain expert bestunderstands the business domain

• The modeler elicits andformalizes this understanding

• The modeler assists the domain expert to identify the business rules related to the data (constraints or derivation rules)

• The modeler validates the model with the client by– Verbalizing the model in natural language– Populating the model with positive/negative examples

Analysis is a Joint Activity

10

Page 11: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

11

Patient# Temperature

571 100

Data (uninterpreted syntax)

The Patient with Patient# ‘571’has a Temperature of 100 oF

Fact (proposition taken to be true)

Information = data + semantics

571

Page 12: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

12

An elementary fact is an assertion that

an object has a property *

or

one or more objects

participate in a relationship **

where the fact cannot be split

into simpler facts with the same objects (without info-

loss)

* plays a role by itself

** play different roles in the same association

Elementary Facts

Person

smokes

drivesCar

Page 13: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

13

The Person named ‘Jack Smith’ smokes.

A unary fact

A binary factThe Executive named ‘William Portals’ climbedthe Mountain named ‘Mt Rainier’.

Facts may also be of higher arity(4 or more roles).

A ternary fact

The Person named ‘Don Bradman’ played the Sport named ‘Cricket’for the Country named ‘Australia’.

Page 14: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

An Old but Fun Example

4 … 10 20

QLD Pot

NSW Middy, Ten Pint

WA Shetland Pony Middy, Ten Pot

… … … … …

QLD 10 Pot NSW 10 Middy ... ... ...

State(.code)

BeerServe(fl oz:)

… calls … by ...CommonName

14

Page 15: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

15

• Feasibility study

• Requirements analysis

• Conceptual design (data, process)

• Logical design (data, process)

• External design (data, process)

• Prototyping

• Internal design and implementation

• Testing, validation, and maintenance

Large projects are often developed iteratively

Overall Procedure: Information systems life cycle

Page 16: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

16

Conceptual analysis usually involves:

• high level service (essential business process) modeling

• information modeling

For large applications:

• divide the UoD into manageable sub-sections

• prioritize the order in which sub-sections will be modeled

• apply the Conceptual Schema Design Procedure (CSDP)

to each sub-section

• integrate the subschemas into a global conceptual schema

Many applications build on existing applications:

• reverse-engineer the existing model(s) to a conceptual model

• refine the conceptual model to fit the new business needs

Page 17: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

17

Conceptual schema design procedure

1 Transform familiar examples into elementary facts

and apply quality checks

2 Draw the fact types

and apply a population check

3 Check for entity types that should be combined

and note any arithmetic derivations

4 Add uniqueness constraints

and check arity of fact types

5 Add mandatory role constraints

and check for logical derivations

6 Add value, set comparison, and subtyping constraints

7 Add other constraints and perform final checks

Page 18: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

18

• ORM Features, History, and Tool Support

• The Data Modeling Process

• ORM’s Graphical Language• Comparison with ER and UML

• Case Study

• Relational Mapping and Tool Demos

Page 19: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

ORM 2 Graphical Modeling Language

Object = Entity or Value

Entity = Object that is identified by a definite description. Entities typically change their state over time. Entities may be concrete or abstract.

e.g. The Country that has CountryCode ‘AU’.

The President named ‘Abraham Lincoln’.

The Course with course code ‘CS542’.

Entity types are depicted as named, soft rectangles.

As a configuration option, soft rectangles may bereplaced by hard rectangles or ellipses.

Country President

Country

Country President

President

19

Page 20: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Value = Lexical Constant (typically a character string or number). Values are literal and cannot change their state.

e.g. The CountryCode ‘AU’.

The PresidentName ‘Abraham Lincoln’.

The CourseCode ‘CS542’.

The RoomNumber ‘207’.

The SerialNumber 1090.

Value Types are depicted as named, dashed rectangles.Optionally, ellipses or hard rectangles may be used instead.

CountryCode

PresidentName

CourseCode

RoomNr

SerialNumber

20

Page 21: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

21

Many entities are identified by their relationship to a simple value.If this is true for all instances of their entity type,the reference (identification) scheme for their entity typemay be displayed as a reference mode in parenthesis.

The reference mode may be popular, unit-based, or general.

A popular reference mode has a corresponding value typethat is used to identify entities of one type only,and is preceded by a dot.

e.g.

The value type name appends the reference mode name to theentity type name, with a user-definable format that may includea separatore.g. CountryCode CourseCode PresidentName etc.

Country_CodeCourse_Code President_Name etc.

Country(.code)

Course(.code)

President(.name)

Product(.name)

Building(.nr)

Employee(.nr)

Page 22: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

22

A unit-based (or measurement) reference mode uses a unitbased on some unit dimension (whose display is often suppressed)1.A colon “:” is appended to the unit

e.g.

The value type name appends “Value” to the reference mode name(if the language is English) with a user-definable format e.g.

cmValue USDValuecm_Value USD_Value

If desired, the unit type may be displayedafter the colon, e.g.

Height(cm:)

Width(cm:)

Tax(USD:)

CostPrice(USD:)

MoneyAmount(USD:)

Height(cm: Length)

Tax(USD: Money)

1 Support for unit-based reference etc. is expected by end 2007

Page 23: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

23

Different units based on the same unit dimensionare permitted in the same model,e.g.

General reference modes have the same name as their value type.The value type may be used to reference multiple entity typese.g.

Tax(USD: Money)

Fee(XEU: Money)

Height(cm: Length)

Distance(km: Length)

Book(ISBN)

Website(URL)

Link(URL)

Page 24: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

24

An independent object type may have instancesthat exist in the model without participating in any other relationships.

Independent object types have a “!” placed after their namee.g.

If an object type shape is duplicated in the diagram(either on the same page or on different pages)this is shown by a shadowe.g.

An external object type is defined in another model.The display notation “^” is tentativee.g.

Country !(.code)

PersonPerson StateCodeStateCode

Address^

Page 25: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

[role1][role2]R R / S S R

A

25

Predicates (relationships) have one or more roles,each played by instances of a single object type.

Predicate readings may be shown in mixfix notation1

using … as an object placeholder,

e.g. … introduced … to …

For unary and binary predicates with no leading or trailing text,the placeholder may be omitted

e.g. smokes i.e. … smokeslikes i.e. … likes …

Roles may also be named.Duplicate predicate shapes are shadowed.

1 Mixfix allows natural verbalization of predicates of any arity, and non-infix predicates (common in many foreign languages).

Page 26: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

26

Personsmokes

Personwas born in

Country

Person

reports to / manages

[manager]

Person

Sport

Country… played … for ...

Personemploys

Department[employee]

[employer]

For binary predicates, forward and inverse readings may be shown separated by “/”.Alternatively, arrow tips may be used.

Combining a predicate with its object type(s) forms an elementaryor compound fact type.

An elementary fact can’t be split into smaller factswith the same objects, without information losse.g.

Page 27: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

27

A compound fact type includes two or more fact types,and if used in a model must be declared to be derivede.g.

An existential fact (or reference)simply asserts the existence of an objecte.g.

There exists a Country that has CountryCode ‘US’.

Existential fact types are displayedeither using a reference modeor an explicit relationship, e.g.

This includes constraints (see later).

Person

Car

Country

drives is imported from

… drives … imported from … *

Country(.code) Country

has / refers toCountryCode

Page 28: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

28

e.g.

An elementary fact type may be objectified, resulting in another object type.

R“A”

Student Courseenrolled in

“Enrollment”

A fact type may be:

• asserted (base fact type)

• fully derived

• derived and stored

• semi-derived

R*

R**

R+

R

Page 29: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Uniqueness constraints require instances of their role or role sequenceto be unique in the role or role sequence population.

Internal uniqueness constraints apply to a single predicateand are depicted by bar(s) over the constrained role(s).

External uniqueness constraints apply to roles from different predicatesand are depicted by circled bars connected to the roles.

If the constraint applies to role(s) used to provide the preferredidentification scheme for an object type, a double-bar is used.

29

Page 30: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

A simple mandatory role constraint requires its roleto be played by all instances of its object type’s populationand is shown by a solid dot at either end of the role-type connector.

An inclusive-or (or disjunctive mandatory role) constraintrequires at least one of its rolesto be played by all instances of its object type’s populationand is shown by a circled, solid dot connected to the roles.

A A

30

Page 31: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

31

e.g.

Room

is inBuilding

(.nr)

hasRoomNr

Room(.nr)

HourSlot(dhCode)

Activity(.code)

… at … is booked for ...

20 Mon 9 a.m. ORC20 Tue 2 p.m. ORC33 Mon 9 a.m. XQC33 Fri 5 p.m. STP

ActivityName

has /refers to

ORC ORM class STM Staff Meeting STP Staff Party XQC XQuery class

20 Mon 9 a.m. XQC33 Mon 9 a.m. ORC

STP Staff PlanningSPY Staff Party

Consultant(.nr)

hasPassport

(.nr)

has

DriverLicense(.nr)

Language(.name)

is spoken by

Page 32: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

32

A{a1, a2, a3} A

{a1 .. an}

{a ..}

Enumeration Range

Semi-bounded discrete range

Bounded continuous range

{(a1 .. a2)}

{[a1 .. a2]}

{[a1 .. a2)}

{(a1 .. a2]}

includes both end valuesexcludes both end valuesincludes first valueincludes last value

Object Value Constraints

Role Value Constraints A

{a1, a2}

Same patterns

as above

Page 33: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

33

Subset Constraints 2

1

Simple:

Contiguous Role-pair:

1.1 1.2

2.1 2.2 Each object pair that playsthe role sequence 1.1, 1.2also playsthe role sequence 2.1, 2.2

Other cases:

Each object tuple that playsthe first role sequencealso playsthe second role sequence

ORM 2 also displays subsetconstraints over join paths

Page 34: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

34

Equality Constraints

2 role-sequences (of 1 or more roles):

2

1 1.1 1.2

2.1 2.2

Populations of role-sequencesmust be equal

3 or more role-sequences: 1.1 1.2

2.1 2.2

3.1 3.2

e.g.

Page 35: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

35

Exclusion Constraints n

1 1.1 1.2

n.1 n.2

Populations of 2 or more role-sequencesmust be mutually exclusive

: : :

Exclusive-Or Constraints

Each instance in A’s population playsexactly one of the n attached roles (n > 1)

A

1

n

: or A

1

n

:

Page 36: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Subtyping

36

A

B

B is a proper subtype ofA (its primary supertype) andC (a secondary supertype)

C

A

B C

A

B C

A

B C

Exclusive Total Partition

Page 37: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Frequency Constraints

37

1

f

1

f

The frequency specification fmay be any of the following

n exactly n (a positive integer)

n at least n

n at most nn..m at least n and at most m

1

f

2

2

Each instance that playsrole 1 does so f times

Each instance pair that playsroles 1, 2 does so f times

Each instance pair that playsroles 1, 2 does so f times

Page 38: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Ring Constraints

38

Irreflexive

Asymmetric

Intransitive

Antisymmetric

Acyclic

Asymmetric + Intransitive

Acyclic + Intransitive

Symmetric

Purely Reflexive

A

Page 39: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

The previous constraints are allalethic(necessarily true for each state).

ORM 2 also supportsdeontic versionsof all these constraints

39

Uniqueness

Deontic constraints are colored bluerather than violet. Most include an “o”for “obligatory”. Deontic ring constraintsinstead use dashed lines.

Mandatory

Subset, Equality, Exclusion

Frequency f

Irreflexive Acyclic

Antisymmetric Symmetric

Intransitive Acyclic-Intrans

Asymmetric Asym-Intrans

Purely Reflexive

Page 40: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

40

Uniqueness constraint on first role

+ve form: Each Moon orbits at most one Planet.

Illustrated by a satisfying fact population.

-ve form: It is impossible that the same Moon orbits more than one Planet.

Test with a counter-example.

Phobos Mars

Deimos

Mars

Io Jupiter

Io Mars }Counter-example

Model ValidationMoon

(.name)orbits / is orbited by

Planet(.name)

Page 41: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

41

The absence of a uniqueness constraint on the second rolemay be verbalized using default form:

It is possible that the same Planet is orbited by more than one Moon.

Illustrated by a satisfying fact population.

Phobos Mars

Deimos

Mars

Io Jupiter

Moon(.name)

orbits / is orbited by

Planet(.name)

Page 42: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

42

Sample screenshotshowing automatedverbalization (+veplus some default)for some selectedaspects.

Currently about 80%of constraints areverbalized.The rest shouldbe implementedin a few months.

Page 43: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

43

Alethic:

It is possible that more than one Patient is a husband of the same Patient and that more than one Patient is a wife of the same Patient.

Each Patient, Patient combination occurs at most once in the population of Patient is a husband of Patient.

Deontic:

It is obligatory that each Patient is a husband of at most one Patient.

It is obligatory that each Patient is a wife of at most one Patient.

In ORM 2,rules may be assigneddifferent modalities

Patient(.nr)

is a husband of / is a wife of

Page 44: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

44

• ORM Features, History, and Tool Support

• The Data Modeling Process

• ORM’s Graphical Language

• Comparison with ER and UML• Case Study

• Relational Mapping and Tool Demos

Page 45: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

45

ER and UML class diagrams are attribute-based,leading to more compact diagramsthat are closer to implementation schemas.

UML also includes many other diagram types to deal withprocess modeling etc.

ORM’s attribute-free nature facilitatesvalidation by verbalization and populationand semantic stability.

ORM’s graphic language is far richer for data modelingthan that of ER and UML,and its textual languages are far easier for non-technical usersto understand than UML’s OCL.

ORM’s graphical language is also orthogonal and unambiguous(unlike UML).

Page 46: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

46

UML’s multiplicity notation is fine for binaries but not for n-ariese.g.

Room(.nr)

HourSlot(dhCode)

Activity(.code)

… at … is booked for ...

ActivityNamehas / is of

can’t express as a multiplicity

*0..1 0..1

dhCode {P}

HourSlot

nr {P}

Room

code {P}name {U1}

Activity

Booking

Each activityhas a booking

Page 47: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

47

Vehicle Company{xor}**

0..1

0..1

vehicleLeased lessor

vehicleSold seller

UML’s xor is defined between associations, not association roles,so this is ambiguous.

Vehicle

is leased from

was purchased from

Company

ORM correctly defines the constraint between roles and treats it as a combination of exclusion and inclusive-or.

Vehicle

is leased from

was purchased from

Company

Page 48: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

48

ORM models are immune to changes that reshape attributesas entity types or relationships.

The meaning of a query is not changed if we change a constraint or add a new fact type.

ORM queries respect this principleand hence facilitate schema evolution.

ER and OO queries do not: such changes can cause attributes to be remodeled; hence, existing queries need to be reformulated.

Semantic stability

Page 49: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

49

List titled people and their gender

Person --- has Title --- is of Gender

SSN {P}gendertitle [0..1]

Person

select SSN, genderfrom Personwhere title is not null

Person(SSN)

is of

Gender(.code)

hasTitle

Page 50: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

50

List titled people and their gender

Person --- has Title --- is of Gender

select Person.SSN, genderfrom Person join PersonTitle on Person.SSN = PersonTitle.SSN

SSN {P}gender

Person

name {P}

Title* *

has

precedes

* *

Person(SSN)

is of

Gender(.code)

hasTitle

precedes

Page 51: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

51

Have your cake and eat it too

by using ORM for conceptual analysis

and mapping it to ER or UML views as desired.

It is expected that the NORMA tool will provide

automatic, live generation of both ER and UML views

by the end of 2008.

Page 52: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

52

• ORM Features, History, and Tool Support

• The Data Modeling Process

• ORM’s Graphical Language

• Comparison with ER and UML

• Case Study• Relational Mapping and Tool Demos

Page 53: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Specify an ORM schema for this report from a book publisher.

Sales ISBN Title Published

Translation of Year Nr Total

Best Seller?

1-33456-012-3 Mizu no Kokoro

2002 2003 2004 2005

5000 6000 5000

16000

Y 2-55860-123-6 Mind Like

Water 2004 1-33456-012-3 2004

2005 3000 3000

6000

N

3-540-25432-2 Informatics 2005 2005 2000 2000 N 4-567-12345-3 Informatics 2006 5-123-45678-5 Semantics

Page 54: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Year(CE)

Year(CE)

Year(CE)

Year(CE)

Book(ISBN)

BookTitle

has

was published in

PublishedBook

is translated from

is a best seller*[copiesSoldInYear]

[totalCopiesSold]

Each PublishedBook is a Book that was published in some Year.* For each PublishedBook, totalCopiesSold= sum(copiesSoldInYear).* PublishedBook is a best seller iff PublishedBook sold total NrCopies >= 10000.

NrCopies… in … sold ...

sold total- *

Page 55: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Model this report from the same business domain.

PNr Name Title Gender Books authored 1 2 3 4 5 6 7 8 9

John Smith Don Bradchap Sue Yakamoto Yoko Ohyes Isaac Seldon Ann Gables John Smith Ann Jones Selena Moore

Mr Sir Mrs Dr Dr Ms Mr Ms Mrs

M M F F M F M F F

1-33456-012-3 2-55860-123-6 3-540-25432-2, 5-123-45678-5 4-567-12345-3 5-123-45678-5

Page 56: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Person(.nr)

PersonName

has/is of

Gender(.code)

is of

{‘M’, ‘F’}

has

PersonTitle

is restricted to

Book(ISBN)

authored

Page 57: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Model this final report from the same business domain.

Review Assignment ISBN Title PNr Name Result

1-33456-012-3 2-55860-123-6 3-540-25432-2 4-567-12345-3

Mizu no Kokoro Mind Like Water Informatics Informatics

1 4 2 5 6 1 7 1 5

John Smith Yoko Ohyes Don Bradchap Isaac Seldon Ann Gables John Smith John Smith John Smith Isaac Seldon

4 5 5 5 4 4 5

Page 58: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Book(ISBN)

is authored by /authored

Person(.nr)

is assigned for review by

“ReviewAssignment !”

resulted in

Grade(.nr)

{1..5}

2

BookTitle

has

Page 59: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

Book(ISBN)

is authored by

Person(.nr)

is assigned for review by“ReviewAssignment !”

PersonName

has/is of

Gender(.code)

is of

{‘M’, ‘F’}

has

PersonTitle

is restricted to

resulted in

Grade(.nr) {1..5}

BookTitle

has

Year(CE)

was published in

PublishedBook

is translated from

… in … sold ...

NrCopiessold total- * is a best seller*

Each PublishedBook is a Book that was published in some Year.* For each PublishedBook, totalCopiesSold= sum(copiesSoldInYear).* PublishedBook is a best seller iff PublishedBook sold total NrCopies >= 10000.

[copiesSoldInYear]

[totalCopiesSold]

2

The full schema

Page 60: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

60

• ORM Features, History, and Tool Support

• The Data Modeling Process

• ORM’s Graphical Language

• Comparison with ER and UML

• Case Study

• Relational Mapping and Tool Demos

Page 61: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

61

Conceptual Schema Relational Schema

Allergy

PK,FK1 patientNrPK drugName

Patient

PK patientNr

patientNamesmokes

Rmap procedure generates 5th normal form by default.

Patient(.nr)

PatientName

has

is allergic toDrug

(.name)

smokes

[allergy]

Relational Mapping

Page 62: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

62

Patient

1025* PatientNr:

* Name:

Allergies:

Ann Jones

OK

PenicillinCodeine

Smokes

(a) (b)Patient

1056* PatientNr:

* Name:

Allergies:

John B. Smith

OK

Smokes

Patient Allergy

patientNr patientName smokes

1025

1056

Ann Jones

John B. Smith

true

false

patientNr

drugName

1025

1025

Penicillin

Codeine

External (forms) and Logical (relational) schemas provide different structures for grouping elementary (conceptual) facts.

Page 63: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

63

Tool Demos

(1) Microsoft Visio ORM Source Model Solution

(2) NORMA

Page 64: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

64

Microsoft Visio for Enterprise Architects supports:

• Entry of ORM 1 schemas

• Forward engineering of ORM schemas to relational schemas

• Forward engineering of ORM updates to relational updates

• Direct entry of relational schemas

• Multiple styles for relational schemas (pure relational, IDEF1X, …)

• Reverse engineering of relational schemas to ORM schemas

• Report generation

Page 65: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

• NORMA1 is the first tool to support ORM 2

• Coded in C#, XML and XSLT

• Open source plug-in to Microsoft Visual Studio .NET 2005, utilizing Microsoft’s Domain Specific Language (DSL) toolkit.

• Supports entry of ORM 2 models

• Automated live error checking and verbalization

• Automatic transformation to implementation artifacts

• Can import ORM models from Visio (via free Orthogonal Toolbox)

• Currently pre-beta. A usable version for industry is expected in 2008

1 Public version downloadable from http://sourceforge.net/projects/orm. A newer build will soon be provided. See NORMA Labs 1-5 to start.

NORMA (Neumont ORM Architect)

65

Page 66: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

66

• NORMA supports mappings to various implementation artifacts

SQL: 2003

IBM DB2

Oracle

PostgreSQL

MySQL

MS SQL Server

DDILDCILOIALn-aryORM

BinaryORM

WSDL PLiX

C# VB.NET PHP

OIAL ORM Intermediate Abstraction LanguageDCIL Database Conceptual Intermediate LanguageDDIL Data Definition Intermediate LanguagePLiX Programming Language in XML

OWL DSL

.NETTiers

EDM

Java

DTD

early development

XSD

mid-stage development

Page 67: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

67

Main current limitations of NORMA

• Forward engineering to new schemas only (generation of incremental schema updates is coming)

• Verbalization of only about 75% of constraints (full verbalization expected early 2008)

• No reverse engineering (we have a basic prototype. RevEng expected in a 2008 release)

• Constraint code generation only for basics (ma, unique, value) (full code generation of graphic constraints expected late 2008) (code generation for formal textual constraints expected later)

Future plans include• complete application generation (including forms)• ER, UML etc. views (editable)• multi-model support (including model component reuse)• integration with conceptual process modeling

Page 68: 1 Model Driven Development with ORM 2 and NORMA © 2007 T. Halpin & Neumont University Terry Halpin Neumont University terry@neumont.edu

68

www.orm.net -- my ORM websitewww.ORMFoundation.net -- ORM Foundation websitewww.inConcept.com -- Journal of Conceptual Modeling, …www.ORMcentral.com -- COM API details for VEA, …www.objectrolemodeling.com/ -- Orthogonal Toolbox, …www.brcommunity.com/ -- Business Rules Journal articles

Halpin, T. 2001, Information Modeling and Relational DatabaseDesign, Morgan Kaufmann.

Halpin, T. et al. 2003, Database Modeling with Microsoft Visiofor Enterprise Architects, Morgan Kaufmann.

Further resources