General Modeling Principles: Building Blocks of Analysis Patterns
PA116 – L2
(c) Zdenko Staníček, Sept 2010
OPVK_MU_EN_stred_2.jpg

2
Content
•Data Polymorphism
•Special Constructs (Analytic patterns)
•Analytic Pattern Accountability
According to:
Lubor Sesera: presentations
papers (“google it, please”)
books (Application Architectures
of SW Systems – in Slovak)

3
Data Polymorphism - topics
•What is data polymorphism?
•What are reasons for using data polymorphism?
•Solving data polymorphism by using “glasses”
•Solving data polymorphism by using  attribute as isolated entity
• (see Special Constructs or Building Blocks in DM)

4
What is data polymorphism?
•Type of data processed by a program is not known in compilation time, but only in the time of
program running.
•Function represented by program is computed in the same way for different types of its arguments
•Typical example is function “Sum”
•… along with this the data processing lies in
–permanent storage in DB,
–searching, actualizing, ...

5
Reasons for utilization of data polymorphism
•Example: Component “Technical Equipment Register and Maintenance” in Power distribution plant
–What Item is worth to be filed as self-reliant entity
–Would we like to see “Transformer” and “Electrical Distributor”, (“insulator”) or only
–“Device”
•Complexity of application when data polymorphism is not used
•Dependence of application on current state of users’ thinking about their business needs
•Sliding on the Identity-axe (what has to be distinguished and what hasn’t)

6
Supertype--Subtype, Identity of types
Device
Transformer
Electrical
distributor
Pillar
Lightning
arrester
Bulk power
substation
Switchboard
Cable
Approx. 180 – 220

7
Connections between Subtypes
Device
Transformer
Electrical
distributor
Pillar
Lightning
arrester
Bulk power
substation
Switchboard
Cable
Cca 180 – 220

8
Connections between Supertypes
Device
Cca 180 – 220
Transformer
Electrical
distributor
Pillar
Lightning
arrester
Bulk power
substation
Switchboard
Cable

9
Solving Data Polymorphism  using “glasses”
•Non-interpreted storage place in Device records
•Each Device instance is of exactly one type from Device Type
•Within the run-time the current “type” of the “non-interpreted storage” of a given Device instance
is interpreted according to assigned “device type”

10
Using glases
Device
Device Type
Glasses
1,1
0,M
1,1
0,M
DEVICE
xxxxx *xxx * xxxxxxxxxxxx *xx * xxxxxxxxx * x *

11
Solving Data Polymorphism  using “glasses” -- discussion
•Used in several real-life examples (case study “Building Data Model”, IS “White Butterfly”, …)
•Discussion:
–What are the advantages?
–What kind of problems this solution brings?
–Is it easy to maintain?
–Computational complexity?
–What about the fact that SW company has its product at 100 (at 1000, ...) customers?

12
Solving Data Polymorphism by using attribute as isolated entity
•Who will find out how to do it?
•It is one of the basic analytic patterns

13
Using attribute as isolated entity
Device
Device Type
Attribute
1,1
0,M
1,1
0,M
Value
p
p
(1,M)
(Value) of given (#Attribute) for given (#Device) / 0,1:0,M

14
Attribute as isolated entity
•Discussion:
–What are advantages?
–What kind of problems this solution brings?
–Is it easy to maintain?
–Computational complexity?
–Comparison with Glases

15
Special Constructions (Analytical patterns)
•Are there any other general solutions except the Data Polymorphism?
•Lubor Šešera: paper at DATASEM
•... and the book Data Modeling in Examples
•… and now: Application Architectures of SW Systems
•M. Fowler: Analysis Patterns: Reusable Object Models.

16
Reasons for usage
•Example: Component “Technical Equipment Register and Maintenance”
•Complexity of application when special constructs are not used
•Dependence of application on current state of users’ thinking about their business needs
•Higher solidity of the construction when proven prefabricated elements are used

17
Conceptual modeling using patterns - principles
•Principles of normalization
•Principles of abstraction
•Principles of flexibility
•
•See Šešera: Data Modeling in Examples
• Following examples and figures are used from authors speach  (with author's kind permition)  L.
Šešera: General Data Modeling Principles: Building Blocks of Analysis Patterns. DATASEM 1999, which
preceded cited book

18
Principles of normalization
•Uniqueness of occurrence of data item
–from not normalized entity towards to construction of normalized entities
•Multiplicity
–reduce a multiplicity of objects in relation only to:
•zero
•one
•infinity

19
Every fact only in one place
Þ
Person
name
surname
village
street
number
*
{
or}
{
or}
1
*
1
*
0
..1
*
0
..1
Person
Number
Street
Village
name
surname

20
Actual cardinalities transform to general ones
ß
1
0
..50
Person
Address-house
number
1
*
Person
Address-house
number

21
Principles of abstraction
•Abstraction in itself
–Generalization
–Constructing types
–Substitution
•Aggregation
•Categorization

22
Generalization
relation of inheritance, some inherited characteristics could be overridden in subtype
Man
Woman
Person
Locality
Number
Village
Street

23
Constructing types
type as a standalone entity

Gender
Person
*
1
Man
Woman
Person

24
Constructing types (2)
type as a standalone entity
Type of
Locality
Locality
*
1

Gender
Person
*
1
According to this pattern:
… we create the following
construction:

25
Substitution
special entity is set instead of general entity - opposite of generalization
Þ
Person
name
surname
Woman
name
surname

26
Aggregation
grouping parts into wholes; it supports constructing more levels of abstraction

Family
Person
1
..*
1
Village
Street
1
*

27
Categorization
grouping instances into sets; it does not subscribe attributes to grouped instances (contrary to
constructing types)
Nationality
Person
*
1
Size of
Village
Village
*
1

28
Abstraction (Generalization) vs. Aggregation
Person
Man
Woman
Head
Body
1
1
1
1

29
Abstraction (Generalization) vs Categorization
Locality
Village
Size of
Village
*
1

30
Principles of Flexibility
•Recursion
–direct
–indirect
•Abstraction of relationship
•Abstraction of attributes

31
Direct recursion
semantic relationship and special relationship    (aggregation)
parent
child
Person
1
*
Locality
1
*

32
Indirect recursion (1)
Person
Parent
Childless
child
*
1

33
Indirect recursion (2)
Locality
Composed
Locality
Number
Person
adress
1
*
*
1

34
Abstraction of relationships
ß
marriage
Woman
Man
date
maiden name
name
surname
1
*
*
1
Person
Family
relationship
Type of
family
relationship
*
1
*
1
*
1

35
Abstraction of attributes (1)
Device
Device Type
Attribute
1,1
0,M
1,1
0,M
Value
p
p
(1,M)
(Value) of given (#Attribute) for given (#Device) / 0,1:0,M

36
Abstraction of attributes (2)
not only by using types, but using aggregations
Gender
Patient
Attribute
of patient
Value
1
*
1
*
1
*
1
*

37
Pattern Accountability
as an example of complex patterns
•taken from L. Šesera's lecture at DATASEM 1999
•by M. Fowler
•Organizational structure of big organization
•Problem of changing the model when the organization structure changes
•Problem of more existing hierarchies at the same time
•Abstractions: OrgUnit → Participant;
OrgRelationship→ (any) Accountability
•Separation of general knowledge from operational level; implementation of general scope of
accountability and allowing multiple inheritance

38
Organizational structure of big organization
Regional Centre
Subsidiary
Headquarters
Store
1
*
1
*
1
*

39
Solving Problem of changing the model when changing the org. structure
Subsidiary
Headquarters
Store
Regional
Centre
Org Unit
Rule:
no superordinate
Rule:
superordinate is
Headquarters
Rule:
superordinate is
Regional
Centre
Rule:
superordinate is
Subsidiary
superordinate
subordinate
0..1
*

40
Solving  Problem of more existing hierarchies at the same time
Type
Organization
relationship
Time interval
Subsidiary
Headquarters
Store
Regional
Centre
Org
Unit
superordinate
subordinate
*
1
*
1
*
1
1
*
Organization
relationship

41
Abstraction: OrgUnit → Participant
OrgRelationship→ (any) Accountability
Type of
Accountability
Time interval
Participant
Accountability
 to whom
Person
Post
Organization
 who
1
*
*
1
*
1
*
1

42
Generalization up to analytic pattern Accountability
•Separate general knowledge of the world from operational level on which we keep track of
particular states-of-the-world
•Implement general scope of accountability
•Allow multiple inheritance (we inherit from  mother and also from father; subtype can have more
supertypes)
•Subtypes of relational entity Scope and explanation what is the scope for (subtype entities of the
Scope)

43
Analytic pattern Accountability
by Lubor Šešera, DATASEM'99
Region of
sales
Product type
Resource type
Quantity
Type of
health
care
1..*
Person
Post
Organization
Operational level
Knowledge level
supertype
subtype
to whom 1+

Participant
Accountability
type
types
who 1+
Scope
{abstract}
Place
Scope of
health
care
Scope of
resources
 to whom
Type of
Accountability
Period
 who
Type of
Participant
type
*
1
0..1
*
1
*
1
*
1
*
1
*
*
1
*
*
1
*
*
*
*
*
1
*
1
1
*
*
*

44
Discussion
•Fear of special constructs
•Quo vadis  SW development?
•Will we implement solutions after domain and situation analysis in the future? Or will we teach a
Service System what to do?
•What customers want today?
•What will they want tomorrow?
•… and what they really need?