© Colin Potts C4-1

Information-oriented approaches

Colin Potts

Georgia Tech

© Colin Potts C4-2

Information modeling in the enterprise

Philosophy» Systems are what they are about, not what

they do» Therefore, model the system’s subject

matter– Process and computation is secondary

» Information structure is more stable in the enterprise than functions & processes

© Colin Potts C4-3

Information modeling & requirements

Many organizations are developing enterprise data models / schemas» Requirements for new applications must be

described in the terminology of the model

Enterprise-wide

model

Applications

© Colin Potts C4-4

Entity-relationship (ER) modeling

Subject matter is described in terms of» Entities» Relationships» Attributes» Constraints

ER-modeling is not restricted to database design» Though most relevant for

DB-intensive ISs

Patron

Book

borrows

Title

Author

copy of

attribute

relationship

entity

© Colin Potts C4-5

Entities & relationships

Entities are things» but not necessarily tangible (books), also

abstract concepts (title) Relationships hold in states

» System exists in discrete states» e.g. “Fred has borrowed War and Peace”

patronbook

entity

© Colin Potts C4-6

Attributes & cardinality

Attributes are properties of entities» Though sometimes, an apparent attribute

gets “promoted” to a relationship Cardinality constraints say how many

entities of each type can participate» Minimum and maximum at each end of

relationship

© Colin Potts C4-7

Cardinality (cont.)

Min 0» entity may enter into

relationship Min 1

» entity must enter into relationship

Max 1» entity enters into

relationship with at most one other entities

Max n » entity may enter into

relationship with others

entity 1

entity 2

relationship

© Colin Potts C4-8

Translating a model into English

N

M N

M N

M N

M An M verbs Ns

An M verbs an N

An M may verb an N

An M may verb Ns

© Colin Potts C4-9

Transactions & updates

Transactions are operations that affect the state of the model» e.g. use cases in a BPR

model» effects may be

– create

– retrieve

– update

– delete

of an entity, its attributes or relationships

“CRUD matrix”Patron Book Title

Borrow book U U

Return book U U

Buy book C C/U

Lose book D U

Join C

Leave D

© Colin Potts C4-10

Team exercise: Information modeling

As a class» Think about problem domain that underpins the

example requirements» Identify candidate entities, attributes, relationships

from domain

In teams of 2-3» Sketch E-R model fragment

As a class» Discuss the insights so gained about the reqts.

© Colin Potts C4-11

Information modeling: how to find out more

There are many books on information modeling» but most are about DB design

Two good general introductions are» Shlaer & Mellor (Don’t be deceived by the

“OO” title)» Barker: CASE Method

© Colin Potts C4-12

Object-oriented analysis: introduction

OOA evolved from Information Modeling» Very similar in outline

OOA is analysis and specification phase preceding OOD/OOP

Relevance to requirements» As with information modeling, derive

requirements using terminology of stable object model

© Colin Potts C4-13

Objects and entities

OOA and information modeling have same basic concepts» Classes = Entity classes» Objects = Instances» Objects have operations » Objects have life cycles» Some classes specialize

others from which they inherit attributes and operations

Titleauthor

Loaner has copy(1,1) (1,n)

Patron

nameborrows

(0,1)

(0,n)

acqn#

Book

© Colin Potts C4-14

Two families of OOA/OOD methods

OOA associations can be purely static relationships» cf. information modeling; conditions that hold

Or can be dynamic connections» cf. modules using other modules

Two families of methods» IM-based: ERA plus inheritance & ops.» Dynamic: Based on scenarios.

© Colin Potts C4-15

Objects and scenarios of use

OMT (Rumbaugh et al)» Heuristics for identifying

classes» Dynamic model

– Build scenarios describing how system will be used

– Draw event traces for the scenarios showing objects interacting

– Develop lifecycle models (state machines for classes

Patron Book

borrow

return

Patron

shelved

onloan

borrow

return

© Colin Potts C4-16

Objects and operations

OMT object model» Operations are

treated like a special type of attribute

» Operations may be performed or suffered

» Operations change the value of an attribute or relation

– Here "borrowed"

Similar treatment in other OOA methods

acqn#

Book

Patron

name

borrowreturn

borrowed(0,1)

(0,n)

© Colin Potts C4-17

OOA: how to find out more

There are lots of methods and books about them

OOA as extended information modeling» Rumbaugh et al book

OOA as scenario-based analysis method» Jacobson book

– Different from the BPR book

© Colin Potts C4-18

Conclusions: Information-oriented approaches

Goal» Understand requirements through constructing

information model

Techniques» ER modeling & OOA

Evaluation» ER is mature, but unnecessarily restricted to DB

design» OOA is new