1) The document discusses normalization of domain modeling in enterprise software development from the perspective of internal modeling. It defines normalization forms for enterprise models from ENF1 to ENF5. 2) A key concept is the management transaction (MT), which clusters a domain into self-managed activities of management functions and processes. MTs capture functional dependencies in the domain. 3) For an enterprise model to be normalized, it must specify the internal structure of MTs as Elementary Management Cycles and eliminate any gaps or overlaps between them. Normalization helps address limitations in model-driven development by maintaining domain knowledge across stages.

1. Computer Days 2017
2017 09 22
Normalization of domain modeling
in enterprise software development
1
prof. dr. Saulius Gudas
Vilnius University, Institute of Mathematics and Informatics, Vilnius,
Lithuania
E-mail: saulius.gudas@mii.vu.lt

2. 2
*The article presents a generalized view to the normalization from the
perspective of the internal modeling paradigm.
*The internal modeling paradigm is a prerequisite for discovering
causal dependencies within the real world domain (i.e. enterprise).
*The transferring of the perceived causal dependencies,
* which are essential in the particular real world domain
*to all the subsequent SDLC stages,
* starting with enterprise/business process modeling stage,
*is the main condition of the knowledge-based development.

3. 3
Normalization has become traditional in database design theory and
practice.
Usage of concepts normalization, and functional dependency in the IS
engineering (i.e. enterprise software engineering) is limited to only one
stage of SDLC - the database design stage.
The provided research of these concepts motivate normalization of the
entire IS development life cycle (SDLC).
The description of normalized SDLC framework presented.
The main part of the paper is devoted to the normalization of the
enterprise modeling stage of SDLC.
Enterprise model normal forms ENF1 – ENF5 defined and illustrated.

4. 4
*
Understanding of normalization in distinct subject domains
(for instance, in statistics, mathematics, domain modeling, process
modeling, ontological domain modeling, automatic knowledge
representation, data modeling,… )
 are divergent, however, some generic features are observable.
Normalization process seeks to transform the initial system (an
empirical model of the subject domain) to the normal form (a
normalized model).

5. 5
*
*New normalization theories –
*the Normalization Process Theory (NPT),
*Normalized Systems Theory (NST) and
*Norm Analysis method (NA),
*have emerged in different, however co-related areas of organizational
management, organizational modeling, and requirements engineering.
*[Murray et al., 2010], [Mannaert et al., 2011], [Eessaar, 2014], [Linden et
al., 2012], [De Bruyn et al., 2012], [Tan et al., 2003], [Chong & Liu, 2000].
*One of the key features is that the normalization procedure uses the
already discovered causal dependencies inside the particular subject
domain.

6. 6
*Normalization is a formalized procedure in the database design
theory and practice.
*Normal forms of database models are based on the concept of
functional dependency [Date, 1999], [Kent, 1983].
*Recently in OLAP systems, new types of data dependencies are
discovered - Conditional Functional Dependencies (CFDs) and
Association Rules (ARs) [Allard et al., 2010].

7. 7
*However usage of concepts normalization,
and functional dependency in the IS engineering
(i.e. enterprise software engineering)
is limited to only one stage of SDLC - the database
design stage.

8. 8
*

9. 9
• We notice that normalization is applied to the real world
domain models, for instance:
• workflows [Pankratius, Stucky, 2005], [Osis, 2004];
• domain ontologies [Rector, 2003].
• Metadata
• This is relevant to applying normalization for the business
domain modeling (enterprise modeling) stage of SDLC (one
of the first stages).

10. 10
* 1. Approach to WFM normalization [Pankratius, Stucky, 2005]
* Definition 9 (1NF). We define a workflow represented as a Petri net to be in First
Normal Form (1NF), if all places or transitions are atomic, i.e. if no place or
transition is hierarchically decomposable into sub-workflows.
* The 1NF is intended to flatten out hidden sub-workflow specifications of a workflow.
This is necessary for the identification of redundant flow specifications, and to reveal
the real structure of the net.
* Definition 12 (2NF). A workflow represented as a Petri net in 1NF is in second
normal form (2NF) if there are no multiple occurrences of isomorphic sub-nets
with identically labelled places or transitions.
* Definition 12 demands that there should be no subnets with identical structure and
identical labels of a subnet N‘ at different locations in the model N.
* Definition 14 (3NF). A workflow represented as a Petri net in 2NF is in third
normal form (3NF) if there are no multiple occurrences of isomorphic sub-nets
with semantically identical labels for places or transitions.
* Places or transitions with different labels may mean the same. In our view, a workflow
designer can be provided with some semi-automatic assistance for detecting such
redundancies of places or transitions with different labels meaning the same, for
example by using synonym dictionaries and concepts developed for the Semantic Web.

11. 11
*WFM represented as Petri net.
*Example for WFM normalization:
*N‘ 1 and N‘ 2 are actually meant to be the same as N‘. In this case,
the workflow model has to be restructured to contain N‘ only once.

12. 12
*[Metadata normalization will determine that two
ontologies from separate sources are referring to the
same subject domain]
*Consider the case where two different web pages refer
to the same person but in different contexts.
*The ontologies used may be quite different and the
knowledgebase needs to be able to determine which
ontology, or combinations of ontologies are applicable.

13. 13
*
*1. Analysis of “normalization” and “functional dependency”
concepts is accomplished in the context of internal modeling
paradigm, when a subject domain (i.e. organizational system
or enterprise) is real world domain considered as a white-
box.
*The target of internal modeling is identification of a deep
structure and essential patterns of behaviour (laws) of subject
domain [Gudas, 2012], [Dietz, 2006].
Black-box
models
White-box modelsGrey-box models
Level of insight into real world domain (a complex system) -
Level of awareness
Input –
process –
output
models
Deep knowledge:
Causal
dependencies,
Laws,
Consistent
patterns,
...
Prior Knowledge:
Equations,
Business rules,
...
Internal modelling
Maximum
(knowledge
of causation)
Minimum
(external
observation)
External modelling

14. 14
*
*2. Functional dependency (FD) is a property of a real world, i.e.
the functional dependencies between elements (components,
entities, attributes, values, etc.) of models are reflextion of real
world dependencies, reveals mutual influencies, causal links
between elements in the subject domain [Wand, Weber, 1995].
*For instance, functional dependencies between attributes of entities
in data model capture the meaning of an application domain as
perceived by analyst (data base designer).
*Functional dependency could be revealed and identified, or missed
in some particular model in case of an analyst mistake or due to
objectives of modeling.

15. 15
*The first step of enterprise management modeling is identification
of management transactions MT based on the development of
Detailed Value Chain Model (see Fig. 1).
* The next step is decomposition of identified MTs. The meta
structure of management transaction MT= (Fj x Pi) is defined as the
Elementary Management Cycle (EMC) in Fig. 2 [Gudas et al.,
2005], [Gudas, 2012].
Fig.2. The deep structure of the
management transaction MT is EMC=(Fj x Pi)
– the the Elementary Management Cycle
Fig. 1 The deep structure of enterprise is a
set of MTs – the Detailed Value Chain Model

16. 16
*Clustering of subject domain into a set of self-managed
complex activities - management transactions MT=(F x P)

17. 17
*Clustering of subject domain into a set of self-managed
complex activities - management transactions MT=(F x P):
*MT1 = EVC1, MT2 = EVC2, and MT3 = EVC3.
Fig. 2. ENF2 - A set of management transactions
(EVC1, EVC2, and EVC3) is identified
Fig. 3 ENF5— All identified management transactions
(EVC1, EVC2 and EVC3) are verified and specified
as aggregated EMC’s: P1, P2 and P3.
MT1= EVC1
MT2= EVC2 MT3=EVC3
MT1 = EVC1

18. 18
*A Management functional dependency (MFD) expresses the idea of
clustering of subject domain into a set of self-managed complex activities
*- management transactions MT=(F x P) which comprise interactions
between management functions F and enterprise processes P.
*The topology of the generalized transaction is a wheel graph (fig. 1).
* In the graph theory, a wheel graph is obtained from a cycle graph Cn-1 by adding a
new vertex called a Hub that is connected to all the vertices of cycle graph Cn
[Bondy et al., 2008]:
Fig. 1

19. 19

20. 20
*
*ENF1 definition: An enterprise model (or business process model) is in
the first normal form (ENF1) if all management transactions are
identified (i.e. the pairs of management functions (F) and enterprise
processes (P) are identified).
*ENF2 definition: An enterprise model (or business process model) is in
the second normal form (ENF2) if all management transactions {(F x
P)} between enterprise processes (P) and enterprise management
functions (F) are specified, i.e. essential management functional
dependencies (MFDs) are conceptualized.

21. 21
*
*All management transactions {(F x P)} between enterprise
processes (P) and enterprise management functions (F) are
specified (a feedback loops of {(F x P)} are specified )

22. 22
*
*ENF3 definition: An enterprise model (or business process model) is in
the third normal form (ENF3) if a deep structure of all management
transactions MT is specified as the Elementary Management Cycle
(EMC).
*The internal structure of each management transaction MTji = {(Fj x
Pi), Ki, Kj} is specified as EMC
*ENF4 definition: An enterprise model (or business process model) is in
the fourth normal form (ENF4) if verification and revision of
enterprise management functions structure are performed and all
gaps or overlapping of EMCs are eliminated.

23. 23
*
*ENF3 definition: An enterprise model (or business process model) is in
the third normal form (ENF3) if a deep structure of all management
transactions MT is specified as the Elementary Management Cycle
(EMC).
*The internal structure of management transaction MT13 have been
specified as EMC13

24. 24
*
*Verification and revision of enterprise management functions
structure are performed and all gaps or overlapping of EMCs are
eliminated.
*An expert work is required

25. 25
*

26. 26

27. 27
1.Limitations of model-driven development (MDD) are
related to the model transformation gaps between SDLC
stages:
business domain modelling, requirements specification and
software design models (IS project models).
2. Normalization and Management Transaction are
considered as a key concepts for enhancement of MDD
methods and technologies towards Knowledge-based IS
engineering.

28. 28
*
*A management functional dependency (MFD) expresses
the idea of internal modeling paradigm:
*discovering knowledge about deep properties of subject
domain, and
*clustering of subject domain into a set of self-managed
complex activities - management transactions MT=(F x P)
which comprise interactions between management functions F
and enterprise processes P.

29. 29
*
*The knowledge-based software development should maintain the
transferring of the real world functional dependencies across SDLC
stages, starting with the enterprise modeling (business process modeling)
stage.
*Based on our analysis, we believe that concept transaction expresses
the essential managerial and control requirements, and restrictions
consequently are the appropriate concept for creating normalization
procedures of SDLC stages.
*Therefore, normalization, functional dependency, and transferring of
domain causal dependencies are key concepts for enhancement of
model-driven software engineering (towards the knowledge-based
software development).

30. 30