Copyright © 2011, Essential Strategies, Inc. 1/99 1 Yes, You Can Create An Architectural Data Model In UML The Handbook DAMA Midwest Chapters October,

Copyright © 2011, Essential Strategies, Inc.1/991

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 [email protected]


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

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


An inextricable tangle of…nomenclature…

Data Modelers

For example, data modeling and UML

UML Modelers


An inextricable tangle of…nomenclature…

For that matter,within data modeling . . .

Database Designers

Conceptual Data Modelers


Some history . . .

Pre 1960 Card decks, magnetic tape

Mid 1960s 1st DBMS

1970 Ted Codd - Relational theory

1976 Peter Chen – Data models

1978 Data flow diagrams

1978 Relational Databases

1981 Information Engineering, Barker/Ellis

1987 Zachman Framework

1990s Data Management

1990s Business Rules

1995 Data Model Patterns

Pre 1960 Fortran / COBOL

1967 Simula 67

1970 Structured Design

1980 The Personal Computer

1980 Small Talk / C++

1988 Object-oriented Analysis

1991 Object Modeling

1992 Use Cases

1995 Java

1995 Design Patterns

1997 UML


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.

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)

Today .we only care about these.


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.


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”…).


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.

Classifier Fieldelement ownership 0..*

1..1


So . . .

Does UML supersede data modeling?

Some would say no…

Since it is about object oriented design…

… it is not suitable for business analysis.


Problem: UML is. . .

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?

HERE


It’s easy . . .

Just build your entity / relationship models in

UML!

So I did . . .


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 . . .


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.


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


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML


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

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


Hidden agenda:Not so

Present the characteristics of a high quality architectural data

model…

…no matter what notation is used.


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

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.


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!


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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…


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)


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

ExternalSchema 2

ExternalSchema 3

External Schema

ConceptualSchema

Internal Schema

Internal Schema

Logical Schema(Relnl.)

Logical

Schema

(XML)

PhysicalSchema Physical

Schema

Four . . .


The Architecture Framework . . .

Objectives/ Scope

Business Owner’s View

Architect’s View

Designer’s View

Builder’s View

Functioning System

List of Important

Things

Terms, Definitions

Entity/ Relationship

Diagram

Tables, Classes

Data, physical storage design

List of Processes

Business Process Model

Essential Functions

System Design

Detailed Program Design

Business Locations

Operationsby Business

Location

Data Links, Processing Locations

Network Architecture

(h/w, s/w types)

Network Construction

Organi- zational Units

Org. Chart, Roles

Roles+Data (Use Cases)

User Interface, Security

Screens, Security Design

Business Events, Cycles

Master Business Schedule

State/ transactions,

ELH

“Control Flow” diagrams

Timing Definitions

Business Vision and Mission

Business Policies and Rules

Business Rule Model

Rule Design

Rule Specification

Working System

Network(Where)

Data(What)

Activities(How)

People(Who)

Timing(When)

Motiva-tion (Why)


The Architecture Framework . . .

Executive’s View

Business Owner’s View

Architect’s View

Designer’s View

Builder’s View

Functioning System

List of Important

Things

Terms, Definitions

Entity types, Relationships

Tables, OO Classes

XML tags

Physical Storage,

Programs

List of Processes

Business Processes

Essential Functions

System Design

Detailed Program Design

Business Locations

Operationsby Business

Location

Data Links, Processing Locations

Network Architecture

(h/w, s/w types)

Network Construction

Organizational Units

Org. Chart, Roles

Roles+Data (Use Cases)

User Interface, Security

Screens, Security Design

Business Events, Cycles

Master Business Schedule

State/ transactions,

ELH

“Control Flow” diagrams

Timing Definitions

Business Vision and Mission

Business Policies and Rules

Business Rule Definitions

Rule Design

Rule Implementations

Working System

Network(Where)

Data(What)

Activities(How)

People(Who)

Timing(When)

Motiva-tion (Why)


PhysicalSchema Physical

Schema

In terms of the Architecture Framework . . .

ExternalSchema 1

ExternalSchema 2

External Schema 3

ConceptualSchema

LogicalSchema(Relnl.)

Semantic Model(Row 2)

Architectural Model (Row 3)

LogicalSchema(XML)

Logical Model (Row 4)

Physical Model(Row 5)


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


Business Owners’ Views

(Semantics)

Terms, concepts.definitions

Semantic Data Model,

(E/R, SBVR, OWL)

Designer’s View(Technology)

Tables, columns, keysClasses, attributes, associationsTags

Architect’s View(Integration of

Business Owners’ Views)

Entity types, attributes, relationships

Architectural Data Model

Object-oriented Classes

RELATIONAL DATA BASES

XML Schemas

Architectural Entity/Relationship Model

Object-oriented Design Model (UML)

Database Design Model

“Conceptual” Data Model


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



UML was originally designed to support object-oriented

design…

…not architectural business modeling.

But do I have a deal for you . . .


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.

We can use UML for a data model?


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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


E/R Notation (Information Engineering) . . .

Line ItemLine NumberOrder Number (FK)

QuantityPrice(Extended Value)Delivery Date

OrderOrder Number

Order Date

part of

composed of

Minimum Cardinality

Maximum Cardinality

Attribute

Role Name

entity type Identifiers

Order_1Order Number

Order Date

Line Item_1Line Number

Order Number (FK)QuantityPrice(Extended Value)Delivery Date

composed of

part of

Relationship


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.


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

entity type Relationship

Role Names

Attributes Maximum Cardinality

Minimum Cardinality

Identifiers


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.

Copyright © 2011, Essential Strategies, Inc.39/9939/

UML Notation . . .

..1

Minimum Cardinality

Class

Attributes

Role NamesRelationship

(Association)

Maximum Cardinality

Identifiers

(None)


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.


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.


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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

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

Note: No constraints as to what kinds of objects or classes were of interest.


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.


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).


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”).

About language in the model . . .

* … or assertions in any other natural language, such as Polish, French, Chinese, or what have you.

*


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.


Again, because the model will be presented publically, spaces between

words are required.


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”

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”)

Naming Attributes . . .

4, Barker, op. cit., p. 5-6.

4

*

* This is something UML has over E/R notations.


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.

Cardinality of attributes . . .


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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.

*


For example (E/R notation) . . .

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.

Party

Party ID

Order

Order Number

customer in

from

to

vender in

These are assertions about the nature of the enterprise.


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.


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”.


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”.)


About reading the role names . . .

Each

Book <entity class 1>

1.. must be

..1 one and only one

Topic <entity class 2>

primarily about <role name>

..* one or more(or)

0.. may be

(or)

Book Topicabout

1..1

0..*

of

primarily

primarily Each Book must be about one and only one Topic.

Each Topic may be of one or more Books.

For example . . .

Many books are about more than one topic.

1..*

one or more

But is this true?


Following correct rules of modeling helps lead

to the truth.

Determining the truth of the model is a different

exercise.


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

Role names are important . . .


“Ravenous Bugblatter Beasts often make a very good meal of visiting tourists”

This should have read . . .

Douglas Adams. 1982. The Restaurant at the End of the Universe. New York: Pocket Books, pp. 37–38.


A word about conversion . . .

“Conversion”, not simply “more detail”.

- John Z.


For example, conversion to a Database Design . . .

Order

Order_NumberCustomer (FK)Vendor (FK)

Party

Party_ID

from

to


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”.


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


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

About Domains

Unique Identifiers

Unnecessary in UML



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. Barker, op. cit. p. G1-3.

5


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.


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.


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.


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.


Today’s Program

Objectives


Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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.


Today’s Program

Objectives


Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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


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.


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: A “+” sign for universally visible” A “-” sign for restricted visibility. A “#” sign for protected visibility. A “~” for visibility within a package.

This is not part of an Entity/Relationship diagram.


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”.

Composition . . .


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”).


Today’s Program

Objectives


Introduction to UML

Notations

About Classes

About Relationships

Unique Identifiers

Unnecessary in UML



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


How to be Effective – Language . . .

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

Business terms for entity types.

Business assertions for relationships.

Good aestheticsSub-type boxes inside super-type boxes

No more than 10-12 boxes per page.

Straight lines.

“Dead crows” positioning. (OK, “starry skies”…)

Effective presentationA succession of diagrams

Each adding 2-4 entity types.


How to be Effective – Principles of Aesthetics . . .

The first objective of a data model is presentation to a non-technical audience. This requires: Effective use of language 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”…)

Effective presentation


These principles are independent of notation

OK, some are harder to carry out,

given tool limitations.


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


The Barker-Ellis approach . . .

PARTY

ORDER# ORDER NUMBER* ORDER DATE

PERSON# PERSON ID* FIRST NAMEo MIDDLE INITIAL* SURNAME

ORGANIZATION# ORGANIZATION NAME

INTERNALORGANIZATION* INTERNAL ORG TYPE

GOVERNMENT

COMPANY

GOVERNMENTAGENCY

POLITICALORGANIZATION

HOUSEHOLD

from

the source of

to

the destination of

More compact. Makes it clear that

attributes and relationships of super-type also apply to the sub-type. “Each Company may

be the source of one or more Orders.”

“Each Household may be the source of one or more Orders.”


The E/R UML Approach . . .


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


Before . . .


With Straight Lines . . .


After . . .


How to be Effective - Presentation . . .

The first objective of a data model is presentation to a non-technical audience. This requires: Effective use of language Good aesthetics Effective 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.


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.


Samples . . .


Photo to generate interest . . .


Tests . . .


Observations . . .


Display of test results . . .


Expected Observations . . .


Remember this . . . ?


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


Questions . . . ?

And now for a bigger example . . .

Documents

Copyright © 2011, Essential Strategies, Inc. 1/99 1 Yes, You Can Create An Architectural Data Model In UML The Handbook DAMA Midwest Chapters October,