UML and Data Modeling - A Reconciliation

Yes, You Can Create
An Architectural Data Model In UML
The Handbook
DAMA Midwest Chapters
October, 2012
David C. Hay

Essential Strategies, Inc.
13 Hilshire Grove Lane, Houston, TX 77055
(713) 464-8316
dch@essentialstrategies.com
1
www.essentialstrategies.com
Copyright © 2011, Essential Strategies, Inc.
1/99

Today’s theme . . .
A man may be a topologist or an acoustician or a coleopterist. He will be filled
with the jargon of his field, and will know all its literature and all its
ramifications. . .
. . .but, more frequently than not, he will regard the next subject as something
belonging to his colleague three doors down the corridor, and will consider any
interest in it on his own part as an unwarrantable breach of privacy.
These specialized fields are continually growing and invading new territory.
The result is like what occurred when the Oregon country was being invaded
simultaneously by the United States settlers, the British, the Mexicans, and the
Russians—an inextricable tangle of exploration, nomenclature, and laws.
Norbert Wiener, Cybernetics; 1948.1

1 Norbert Wiener. 1948, 1961. Cybernetics: of Control and Communication in the Animal and the
Machine, second edition. (Cambridge, MA, The MIT Press). 2.

2/99

An inextricable tangle of…nomenclature…

For example,
data modeling and UML

 Data Modelers  UML Modelers

3/99

An inextricable tangle of…nomenclature…

For that matter,
within data modeling . . .

 Database  Conceptual Data
Designers Modelers

4
4/99

Some history . . .

Pre 1960 Card decks, magnetic tape Pre 1960 Fortran / COBOL
Mid 1960s 1st DBMS 1967 Simula 67
1970 Ted Codd - Relational theory 1970 Structured Design
1976 Peter Chen – Data models
1978 Data flow diagrams
1978 Relational Databases
1981 Information 1980 The Personal Computer
Engineering, Barker/Ellis
1980 Small Talk / C++
1987 Zachman Framework
1988 Object-oriented Analysis
1990s Data Management
1991 Object Modeling
1990s Business Rules
1992 Use Cases
1995 Data Model Patterns
1995 Java
1995 Design Patterns
1997 UML
5/99

About the Unified Modeling Language (UML)
 Created in 1997, UML is an array of notations for modeling
 Classes,
 Activities,
 State Machines
 Use Cases
 Interactions
 It is intended to support object-oriented program design.
Today .we only care
about these.
 Note that by the late 1990s, outside the object-oriented community, modeling to support requirements analysis was already well established :
 Entity/relationship models (classes)
 Data flow diagrams (activities)
 State/transition diagrams (state machines)
 Entity life histories (entity type behavior)

6/99

About Data Modeling . . .
As stated, There are two groups of data modelers:

 Group one creates logical data models to support database design.
 Group two creates architectural data models to represent the structure
of the business, independent of database technology.

7/99

Group one (DB designers) finds UML annoying because . . .

The orientation is different:
 Database administrators: data as an asset, to be protected
 UML (OO) Designers: data as a support to programs.
Relational structures deal badly with inheritance
 (and OO people have “attitudes”…).

8/99

Group two (business modelers) find UML annoying because . . .

UML is not constrained in defining what is a “class”.

UML (as practiced) has a very peculiar way of naming
relationships.

UML notation and practices are not conducive to
presenting models to the business.

element ownership 0..*
Classifier Field
1..1

9/99

So . . .

Does UML supersede
data modeling?

Some would say no…

Since it is about object
oriented design…

… it is not suitable for
business analysis.

10/99

Problem: UML is. . .

HERE
 Despite its flaws, The Unified Modeling Language has been
recognized as a standard in many quarters.
 Clients and hiring managers keep asking if you have
experience with UML.

!!!
How should we
entity/relationship
dudes deal with
this?
11/99

It’s easy . . .

Just build your entity /
relationship models in
UML!

So I did . . .

12/99

Which meant that . . .
 My data modeling colleagues were convinced that I had
completely sold out and gone over to the dark side . . .
 . . . and my UML/object modeling colleagues accused me of
bastardizing their sacred notation.

So, I wrote another
book in response . . .

13/99

A companion volume . . .

 Two audiences:
 Data modelers convinced that UML has
nothing to do with them.
 UML modelers who don’t realize that
architectural data modeling really is
different …
 … and the differences are important.

 This is a handbook on how to use the
UML class notation to produce an
Architectural Entity / Relationship
diagram.

14/99

Today’s Program
 Objectives
 Kinds of Models (and what we call them)
 Introduction to UML
 Notations
 About Classes
 About Relationships
 Unique Identifiers
 Unnecessary in UML
 Aesthetics and Presentation

15/99

Today’s Program
Objectives
 Notations
 About Classes

16/99

Ok, let’s be honest . . .

Data modelers themselves are sometimes a bit free-wheeling about
what constitutes a class.

Data modelers are often not as disciplined in making business
structures presentable as they might be.

Data modelers can be very casual in naming relationships

17/72 Copyright © 2011, Essential Strategies, Inc.
17/99

Not so Hidden agenda:

Present the characteristics of a
high quality architectural data
model…

…no matter what notation is
used.

18/99

Specifically, This Presentation . . .

Will show the business-oriented modelers how to accomplish
their objectives in UML.
Will show the database designers how to do business-oriented
modeling in UML.
Will show UML object modelers how to bring business-oriented
modeling into UML.

(UML as a database
design notation is for
another presentation.)

19/99

After the book was published, I learned that . . .
 My version of UML is something the OMG calls a “domain
specific language” for entity/relationship modeling.
 It even gets an acronym: “DSL”.
 I knew I was tinkering with the language,
 …but I didn’t realize it was something!

20/99

Today’s Program
 Objectives
Kinds of Models (and what we call them)
 Notations
 About Classes

21/99

Kinds of data models . . .
 We modeling types are quick to criticize our clients for getting
their vocabularies confused.
 But what about us? What do we mean by . . .
 “Conceptual” data model?
 “Logical” data model?
 “Physical” data model?
 “Semantic” data model?
 And now you’re adding “Architectural” data model?
 For purpose of this presentation, here are the definitions:
After all, it is my presentation…

Please hear me out…
22/99

Kinds of Models . . .
Corporate Overview: Context for executive management, strategies.
(Planner’s View)
(Not “Conceptual”)
Conceptual: Business-oriented, but in detail; technologically neutral.
Two flavors:
 Semantic: In language of business owner; divergent.
(Business Owner’s View)
 Architectural: Abstract, encompassing multiple groups: convergent
(Architect’s View)
(Not “Logical”)
Logical: In terms of data management technology. (Designer’s View)
(Not “Physical”)
Physical: In terms of physical storage devices— table spaces, partitions,
etc. (Builder’s View)
23/99

Context: ANSI’s Three ways to look at data.(1975) . . .
Four ..

External
Schema Logical
Internal
Schema
Schema
(Relnl.)

Conceptual Logical
Schema Internal
Schema
External
Schema
(XML)
Schema 2

External
Schema 3

Physical
Schema Physical
Schema

24/99

The Architecture Framework . . .

Data Activities Network People Timing Motiva-
(What) (How) (Where) (Who) (When) tion (Why)
List of Organi- Business
Objectives/ Scope Important
List of Business
zational Units Events,
Business Vision
Processes Locations and Mission
Things Cycles

Business Operations Org. Chart, Master Business Policies
Business Owner’s Terms,
Process by Business Roles Business and Rules
View Definitions
Model Location Schedule

Entity/ Data Links, Roles+Data State/
Essential Business Rule
Architect’s View Relationship
Functions
Processing (Use Cases) transactions,
Model
Diagram Locations ELH

Network User Interface, “Control Flow”
Designer’s Tables, System
Architecture Security diagrams Rule Design
View Classes Design
(h/w, s/w types)

Data, physical
Detailed Screens,
storage design Network Timing Rule Specification
Builder’s View Program
Construction
Security
Definitions
Design Design

Functioning Working System

System

25/99

The Architecture Framework . . .

Data Activities Network People Timing Motiva-
(What) (How) (Where) (Who) (When) tion (Why)
List of Business
List of Business Organizational Business Vision
Executive’s View Important
Processes Locations Units
Events,
and Mission
Things Cycles

Business Owner’s Operations Master
Terms, Business Org. Chart, Business Policies
by Business Business
View Definitions Processes Roles and Rules
Location Schedule

Data Links, State/
Entity types, Essential Roles+Data Business Rule
Architect’s View Relationships Functions
Processing
(Use Cases)
transactions,
Definitions
Locations ELH

Tables, Network
System User Interface, “Control Flow”
Designer’s OO Classes
Design
Architecture
Security diagrams
Rule Design
XML tags (h/w, s/w types)
View
Physical Detailed Screens,
Network Timing Rule
Builder’s View Storage, Program
Construction
Security
Definitions Implementations
Programs Design Design

Functioning Working System

System

26/99

In terms of the Architecture Framework . . .
Logical Model
Architectural
(Row 4)
Model (Row 3)

External
Schema 1 Logical
Schema
(Relnl.)

Conceptual Logical
External Schema Schema
Schema 2 (XML)

External
Schema 3

Physical
Physical
Physical Model Schema
Schema
Semantic Model (Row 5)
(Row 2)
27/99

Ok, let’s look into the data
column more deeply…

28/99

Business Owners’ Semantic Data Terms, concepts.
Views Model, definitions
(Semantics) (E/R, SBVR, OWL)

Architectural
“Conceptual” Entity/Relationship
Data Model Model

Architect’s View
Entity types,
(Integration of Architectural
attributes,
Business Owners’ Data Model
relationships
Views)
Database Object-oriented Design
Design Model Model (UML)

Tables, columns,
Object-oriented XML keys
Designer’s View RELATIONAL
DATA BASES Classes Schemas Classes, attributes,
(Technology)
associations

Tags
29/99

Today’s Program
 Objectives
Introduction to UML
 Notations
 About Classes

30/99

UML was originally designed to
support object-oriented
design…

…not architectural business
modeling.

But do I have a deal for you . . .

31/99

We can use UML for a data model?
 Yes…but with restrictions:
 Restrict the definition of entity type.
 Use a subset of the notation.
 Recognize that E/R relationships are not the same as OO
associations.
 Pay attention to Layout aesthetics.
 Add unique identifiers.

32/99

Today’s Program
 Objectives
Notations
 About Classes

33/99

Kinds of Notations . . .
 Of interest to us . . .
 Information Engineering – Most commonly used among data modelers.
 Barker / Ellis – Most technologically independent
 UML – The subject of today’s talk
 Not of interest to us . . .
 IDEF1X – Buried in relational design
 Object Role Modeling – Different approach
 OWL – Future presentations

34/99

E/R Notation (Information Engineering) . . .
Maximum
Cardinality
Attribute
Minimum
Cardinality
Line Item Order
Line Number part of Order Number
Order Number (FK) composed of Order Date
Quantity
Price
(Extended Value)
Delivery Date

Role Name

entity type Identifiers
Relationship

Line Item_1 Order_1
Line Number part of Order Number
Order Number (FK) Order Date
composed of
Quantity
Price
(Extended Value)
Delivery Date

35/99

E/R Notation (Information Engineering) . . .
 Shows cardinality as graphics. Observer sees it.
 Shows identifying attributes and relationships.
 Identifying attributes in separate section of entity type box.
 Identifying relationship through combination of symbols:.
 NOTE: Each relationship direction is structural, representing an
assertion about the nature of the domain.
 Minimal references to technology…
 … but there is a relational design bias:
 Foreign keys implementing relationships
 Complexity of identifying relationships.

36/99

E/R Notation (Barker-Ellis) . . .

Maximum
Attributes
Cardinality

Minimum
Cardinality

Role Names
entity type Relationship
Identifiers

37/99

E/R Notation (Barker-Ellis)
 Shows cardinality as graphics. Observer sees it.
 Shows identifying attributes and relationships with simple
symbol.
 NOTE: Each relationship direction is structural, representing
an assertion about the nature of the domin.
 No references to database or any technology.

38/99

UML Notation . . .

Maximum
Cardinality

Attributes
Minimum
Cardinality

..1

Class Role
Names Relationship
(Association) Identifiers
(None)

39/99
39/

UML Notation . . .
 Systematic cardinality notation (attributes and associations).
 Cardinality textual, not graphic. Viewer must read and understand it.
 MAJOR ISSUE: In UML, an association is a navigation path, not a
structure.
 Identifier notation added in version 2.2. (Can also be added via
“stereotypes”.)
 No database connection . Full notation has object-oriented design
symbols
 …that we can ignore.

40/99

About Notations . . .
 Different notations (as implemented via different tools) make it
easier or more difficult to do certain things.
 The important dimension is good practices.
 Best to support the practices here is Barker / Ellis
 Second best is the revised version of UML.
 Information Engineering’s bias toward relational database
design is hard to thwart.

But it is the best practices,
not the notation that is most
important.

41/99

Today’s Program
 Objectives
 Notations
About Classes

42/99

According to the “Three Amigos” . . .
 An object is a “discrete entity with a well-defined boundary and
identity that encapsulates state and behavior; an instance of a
class”
 A class, in turn, is “the descriptor for a set of objects that share
the same attributes, operations, methods, relationships, and
behavior.”1
Note: No constraints as to
what kinds of objects or
classes were of interest.

1 Rumbaugh, J., Ivar Jacobson, Grady Booch. 1999. The Unified Modeling
Language Reference Manual. p. 360.

43/99

According to James Martin
and James Odell, “anything
is an object”.2

2. Martin, J., and James Odell. 1995. Object-Oriented Methods. (Englewood
Cliffs, NJ: Prentice Hall). p. 34.

44/99

An “Entity” on the other hand . . .
 … is not just any “discrete entity with a well-defined
boundary and identity”.
 … is limited to what Richard Barker calls things or objects “of
significance, whether real or imagined, about which an
organization needs information.”3
 An “entity type”, unlike other “classes”, is not concerned with
operations, methods, or behavior.
 Those belong to the world of “process modeling.”
 An entity/relationship model is only concerned with the
Structure of business data.

3. Barker, Richard. 1990. CASE*Method: Entity Relationship Modeling. (Wokingham, England: Addison-Wesley).

45/99

About language in the model . . .
 An architectural entity/relationship diagram is essentially a
graphic portrayal of English language assertions about an
organization. *
 Therefore, the only language to appear on a diagram must be in
terms relevant to the domain of interest.
 Only business terms (and conventional English) may be used as
the names of entity types, attributes, and the names of roles.
 That is, no abbreviations, computer terms, or acronyms.
 Words are not concatenated together. Spaces between words
are shown (“Line Item”, not “lineItem”).
* … or assertions in any other natural language, such as Polish, French, Chinese, or what have
you.

46/99

Entity Type names . . .
 The name of an entity type is in the singular, and refers to
an instance of that class.
 Hence, Order and Line Item are acceptable.
 The name “Project history” is not.
 An entity type called Project, on the other hand, could contain
instances over time, so it may in fact be a project “history”
 Database table names are not allowed, nor are abbreviations or
acronyms.
 Classes that are computer artifacts (“window”, “cursor”, and the
like) are not allowed.

47/99

Again, because the model will be
presented publically, spaces between
words are required.

48/99

Naming Attributes . . .
 In both E/R and UML an attribute is a characteristic of an entity type.
 It “serves to qualify, identify, classify, quantify, or express the state of an
entity” 4
 In the previous example:
 Order: “Order number” and “Order date”.
 Line Item: “Line number”, “Quantity”, “Price”, “Delivery date”, and
“/Extended value”.
 “/” means a derived attribute. *
 /Extended value = Quantity * Price
 Again, spaces are required (where appropriate). (“Delivery Date”, not
“deliveryDate”)

4, Barker, op. cit., p. 5-6.
* This is something UML has over E/R notations.

49/99

Cardinality of attributes . . .
 In UML, cardinality is represented the same way for attributes as for
roles.
 Minimum cardinality:
[1..1] – Mandatory: must be at least one value; may be no more than
one value. Usually abbreviated “[1]”.
[0..1] – Optional: may or not have a value; may have no more than
one value.

 Maximum cardinality must always be ..1. Multi-valued attributes are not
permitted.

50/99

Today’s Program
 Objectives
 Notations
 About Classes
About Relationships

51/99

Associations / Relationships . . .
 Each E/R relationship is a structure composed of two roles.
 Each role is an English language assertion * about the domain
of discourse:
 Each – (The assertion is about each instance of the first entity type.)
 Subject – (The first entity type)
 Minimum cardinality (“must be” or “may be”)
 Predicate – (The role name)
 Maximum cardinality (“one or more” or “one and only one”)
 Object – (The second entity type).

* …or Spanish or French or Polish or whatever. The point is that it must be in a natural language, not in
computer jargon.

52/99

For example (E/R notation) . . .
Order Party
Order Number Party ID
from

customer in

to

vender in

1. Each Order must be from one and only one Party.
1a. Each Party may be a customer in one or more Orders.

2. Each Order must be to one and only one Party.

2a. Each Party may be a vendor in one or more Orders.

These are assertions about
the nature of the enterprise.
53/99

UML looks at it differently . . .

 An association is a path, not a structure.
 Because 2nd class is not in 1st class’s namespace, it cannot be
part of the property of the 1st class.
 Hence roleName is simply a label for the second class (a
noun). Role name often simply copies the 2nd class name.
 (In this case, role name does distinguish two roles.)
 Role name is not part of a structural statement.
54/99

UML looks at it differently . . .

1. Each Order must be related to one and only one
thing that is labeled “customer”.
1A. Each Party may be related to one or more
things that are labeled “purchase order”.
2. Each Order must be related to one and only one
thing that is labeled “vendor”.
2a. Each Party may be related to one or more
things that are labeled “sales order”.

55/99

Changes to the “standard” UML approach . . .

 Role names are prepositions
 Preposition is the part of speech that describes relationships.
 Nouns describe things. The entity types are already the things.
 (…and they are already labeled.)
 No duplication of the entity type name in the role name.
 To duplicate the class name is a serious redundancy in UML.
 The practice comes from requirements of Java programming:
The object class is not part of the subject class’s “namespace”.)

56/99

About reading the role names . . .

For example . . .
Each
primarily
0..*
Book <entity class 1>
Book
about
Topic
of 1..1
1..*
1.. must be
(or)
Each Book must be primarily
0.. may be about one and only one Topic.
one or more
primarily about <role name> Each Topic may be of one or more
Books.
..1 one and only one
(or)
..* one or more But is this true?

Topic <entity class 2> Many books are about
more than one topic.

57/99

Following correct rules
of modeling helps lead
to the truth.

Determining the truth of
the model is a different
exercise.

58/99

Role names are important . . .

‘Ravenous Bugblatter Beasts often make a very good meal for visiting
tourists’

59/99

This should have read . . .

“Ravenous Bugblatter Beasts often make a very good meal of visiting
tourists”
Douglas Adams. 1982. The Restaurant at the End of the Universe. New York: Pocket Books, pp. 37–
38.
60/99

A word about conversion . . .

“Conversion”, not simply
“more detail”.
- John Z.

61/99

For example, conversion to a Database Design . . .

Order Party
Order_Number Party_ID
Customer (FK)
Vendor (FK) from

to

62/99

The UML Design Version . . .
 Similarly, an architectural UML model must also be converted to
an object-oriented program model:
E/R role names are converted to OO roleNames as:
“predicate|object class name”.

63/99

Thus, conversion to an Object-oriented Design . . .

64/99

Today’s Program
 Objectives
 Notations
 About Classes
About Domains
 Aesthetics and Presentation 65/99

Domains . . .
 In E/R modeling, a domain is “A set of business validation rules,
format constraints, and other properties that apply to a group
of attributes”.
 For example:
 a list of values
 a range
 a qualified list or range
 any combination of these.
 “Note that attributes and columns in the same domain are
subject to the same validation checks.” 5

5. Barker, op. cit. p. G1-3.

66/99

Code lists . . .

 In database design, a code list is a set of valid values for a
column.
 For example, the column “STATE_ABBR” may be controled by the code
list “State abbreviations”. This would have the values “AL”, “AK”, “AZ”,
etc. This is one code list that implements the domain “State” Others
might be “State official name”, “State code”, etc.
 In database design, a validation rule may control the legal
values for a column.
 For example, the column SALARY may be constrained by the validation
rule “Positive number”. That is, the value must be greater than zero.

67/99

Data type . . .

 Each E/R domain must also in turn specify the data type of the
values for a referenced attribute.
 These include:
 String
 Number
 Date
 Boolean
 Etc.

68/99

Data Types as Domains . . .

 In addition to the standard data types that come with UML
(“number”, “string”, etc), it is possible to define new data types
to address any validation criterion desired.
 “Social security number”
 “Telephone number”
 Etc.

69/99

Enumeration in UML

 UML takes a different approach to both code lists and domains.
 A code list may be described explicitly as an enumeration.
 This looks like an “entity type”, but instead of showing the
attributes “Code” and “Definition”, it shows the list of values.

70/99

Today’s Program
 Objectives
 Notations
 About Classes
Unique Identifiers

71/99

In 2011, the OMG got the message . . .
 Originally, the object-oriented community assumed that all classes are
identified by a surrogate key, called an object identifier
 Until recently, UML has no inherent facility for representing natural unique
identifiers.
 With version 2.2, there is now a “property” called “isID?”
 It is displayed on the drawing as {id}
 This version exactly maps to the stereotypes, and is much simpler than the
Information Engineering approach.

72/99

Today’s Program
 Objectives
 Notations
 About Classes
Unnecessary in UML

73/99

Unnecessary UML features . . .

 UML was developed to support object-oriented design.
 Some of its features are not meaningful in an
entity/relationship diagram.
 Navigation
 Visibility
 Composition

74/99

Navigation
 In an Entity/Relationship diagram, a relationship describes
structure.
 By definition both ends and both roles must exist. (You cannot
build half a bridge.)
 In an object-oriented program, program code must be written to
get from one class to another.
 If the application only calls for navigating in one direction only, it
is useful (for the developer) if the designer indicates that.

This is not part of an
Entity/Relationship
diagram.

75/99

Visibility . . .
 In an object-oriented program, attributes of a class may
be “visible” only to that class, or to super-types of that
class, or to the entire application.
 This is shown by:
This is not part of an
 A “+” sign for universally visible”
Entity/Relationship
 A “-” sign for restricted visibility. diagram.
 A “#” sign for protected visibility.
 A “~” for visibility within a package.

76/99

Composition . . .
 Within object-oriented programs, composition structure is
very common and very important.
 So a symbol ( ) is equivalent to the role name “composed
of”.
 This includes the referential integrity constraint “cascade
delete”.
 Another symbol ( ) is also “composed of”, but this enforces
the the referential integrity “nullify”.

77/99

Composition . . .
 Entity / Relationship modeling addresses the semantics of the
business with language.
 Another symbol for the words “composed of” is redundant.
 Can’t do referential integrity anyway (There is no symbol for
“Restricted Delete”).

78/99

Today’s Program
 Objectives
 Notations
 About Classes
Aesthetics and Presentation

79/99

How to be Effective . . .

 The first objective of a data model is presentation to a non-
technical audience. This requires:
 Effective use of language
 Good aesthetics
 Effective presentation

80/99

How to be Effective – Language . . .
 The first objective of a data model is presentation to a non-technical
audience. This requires:
 Business terms for entity types.
 Business assertions for relationships.
 Good aesthetics
 Sub-type boxes inside super-type boxes
 No more than 10-12 boxes per page.
 Straight lines.
 “Dead crows” positioning.
(OK, “starry skies”…)
 A succession of diagrams
 Each adding 2-4 entity types.

81/99

How to be Effective – Principles of Aesthetics . . .

 Good aesthetics
Sub-type boxes inside super-type boxes
No more than 10-12 boxes per page.
Straight lines.
“Dead crows” positioning.
(OK, “starry skies”…)

82/99

These principles are
independent of notation

OK, some are harder to
carry out,
given tool limitations.

83/99

Sub-types: The UML (and IE) approach . . .

84/99

The Barker-Ellis approach . . .

PARTY
PERSON
 More compact.
ORDER from # PERSON ID
# ORDER NUMBER
* ORDER DATE the source of *
o
FIRST NAME
MIDDLE INITIAL
 Makes it clear that
* SURNAME
attributes and
to
ORGANIZATION
relationships of super-
the destination of
# ORGANIZATION NAME type also apply to the
INTERNAL sub-type.
ORGANIZATION
* INTERNAL ORG TYPE
 “Each Company may
GOVERNMENT
be the source of one or
more Orders.”
COMPANY  “Each Household may
be the source of one or
GOVERNMENT more Orders.”
AGENCY

POLITICAL
ORGANIZATION

HOUSEHOLD

85/99

The E/R UML Approach . . .

86/99

About the drawings . . .

 No bent lines.
 Orient boxes so “many” side of relationships is up or to the left.
(“Starry skies” approach)
 Each subject area must fit on one page.
 No more than 12-15 boxes
 Less than 10 is better

87/99

Before . . .

88/99

With Straight Lines . . .

89/99

After . . .

90/99

How to be Effective - Presentation . . .

 Good aesthetics
Build up presentation a few entity types at a time.
• Start with one or two entity types.
• Add one or two
• And so forth
For each slide, highlight what is new on that slide.

91/99

About the Presentation . . .
 Build up presentation a few entity types at a time.
 Start with one or two entity types.
 Add one or two
 And so forth
 For each slide, highlight what is new on that slide.

92/99

Samples . . .

93/99

Photo to generate interest . . .

94/99

Tests . . .

95/99

Observations . . .

96/99

Display of test results . . .

97/99

Expected Observations . . .

98/99

Remember this . . . ?

99/99

Conclusions . . .
 UML can be used to represent architectural entity/relationship
diagrams, with constraints:
 Orientation toward the domain of discourse (problem domain).
 Addressing only classes of significance to the business.
 Changing the syntax of role names.
 Addressing the aesthetics of the models.
 Data model quality is a function of:
 Clarity of thought
 Clarity of presentation

Data model quality is not
a function of
the notation selected

100/99

Questions . . . ?

And now for a
bigger example . . .

101/99

UML and Data Modeling - A Reconciliation

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (15)

Similaire à UML and Data Modeling - A Reconciliation

Similaire à UML and Data Modeling - A Reconciliation (20)

Plus de dmurph4

Plus de dmurph4 (11)

Dernier

Dernier (20)

UML and Data Modeling - A Reconciliation