‫ر‬

‫الجامعة السعودية االلكتونية‬

‫ر‬
‫االلكتونية‬ ‫الجامعة السعودية‬

‫‪26/12/2021‬‬
College of Computing and Informatics

IT342
Enterprise Systems
 IT342 - Enterprise Systems
Week 7 - Enterprise and Process Modeling
Contents

1. Model and Types of Models

2. Modeling and Modeling Ontology
3. Requirements of Modeling
4. Enterprise Modeling
5. Process Modeling
6. Process Description for Storing Business Process Models
Weekly Learning Outcomes

1. Understand Enterprise Modeling and Process Modeling

2. Modeling Ontology and recognizing various requirements of
modeling
3. Process Description for Storing Business Process Models
 Required Reading
1. Chapter 6: Enterprise Modeling
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise information
systems: A pattern based approach (3rd ed.). New York: McGraw Hill
Higher Education. ISBN: 007240429 (print), 9781308469676 (e-text).
2. Enterprise Modeling
https://docs.oracle.com/search/?q=enterprise+modeling

This Presentation is mainly dependent on the textbook: Enterprise Information Systems: Contemporary Trends and Issues
Enterprise Modeling
Enterprise Modelling

• Implementing process-oriented architectures has proven to be

difficult for many companies.

• Implementing process concepts within organizations is only one step

toward achieving an enterprise-wide focus on processes.

• Process management deals with the efficient and effective execution

of business processes.
Enterprise Modelling

• It consists of the planning, implementation, enactment, and

controlling of processes and forms a life cycle that leads to continuous
process improvement.

• There is a gap between approaches for modeling business processes

and those for modeling information systems.

• There is a strong need for a methodology for creating a supporting

information system that is based on the process architecture of an
organization.
Model

• A model is a form of representing something: it is not a replication

but rather an intentional selective construction of a new thing or
system that has the purpose of representing another thing or system.

• No model is unique or exclusive, as there can be a multitude of them;

furthermore, models are generally not correct or incorrect—it is only
what it is with reference to the defining purpose of the respective
model.
Characteristics of a model
Characteristic Description
Abstraction: A model is a reduced description of the system.
For the properties of interest, a model provides a true-to-life representation of the
Accuracy:
system.
Removing details that are irrelevant for a given view or viewpoint and specifying in
Understandability: a form that is intuitive enables easier understanding of the concerned system
properties.
A model helps with correctly analyzing and reasoning about the interesting but
Reasoning: nonobvious properties of the system, either through some type of formal analysis
or experimentation (e.g., by simulating the model on a computer).
Inexpensiveness: A model is drastically cheaper to construct and analyze than the system.
Types of Models
Types of Models

• Descriptive: A descriptive model is used to describe or mimic a real-

world phenomenon or system. With a descriptive model, one can
reason about the properties or the behavior of the system.

• Prescriptive: A prescriptive model is used to define how a yet-to-be-

built system is supposed to be. Prescriptive models are adopted as
part of so-called forward engineering.
Types of Models

• Structural: A structural model is focused on the static aspects of a

system. These models are used for describing the components or
modules that are part of the system, so they serve for conceptualizing
the system architecture.

• Behavioral: A behavioral model emphasizes the dynamic, functional,

and temporal aspects of the system.
Types of Models

• Symbolic: These models are much more easily changed in comparison

with physical models. By manipulating and changing the
mathematical relationships, one can see how the model reacts and
consequently how the system would react. The creation of a symbolic
model requires:
• A set of signs (or symbols)
• A set of rules to operate on those signs

• Physical: Typically, a physical model is a smaller representation of the

original object but, sometimes, it can be larger if the original object is
too small for humans.
Modeling

• Modeling is the process of identifying adequate concepts and

selecting adequate abstractions to construct a model that reflects a
given universe of discourse appropriately.

• Modeling permits the cost-effective use of the model in place of the

real-world object or process for some purpose, such as simulation,
construction effort estimation, and so on.
Modeling Ontology

• An ontology is an explicit representation of a shared understanding of

the important concepts in some domain of interest.

• Ontologies are represented by conceptual maps that constitute a

simple and well-known form of organizational knowledge.

• This ontology considers two different separate perspectives:

• Reverse engineering
• Forward engineering
Modeling Ontology

• Reverse engineering employs descriptive models to model an existing

system. Reverse engineering is a process of analysis in which the
system is seen by means of a model.

• Forward engineering employs prescriptive models for modeling the

envisaged system. Forward engineering is a process of synthesis
wherein the system is developed starting from a model.
Modeling Ontology

• Reverse engineering employs descriptive models to model an existing

system. Reverse engineering is a process of analysis in which the system
is seen by means of a model.

• Forward engineering employs prescriptive models for modeling the

envisaged system. Forward engineering is a process of synthesis wherein
the system is developed starting from a model.
Requirements of Modeling

• Domain Models
• A domain model constitutes a description of the common properties and
variables of the domain related to the system that is being developed.
• This model represents the things (entities or events) that exist in that domain;
that is, it is a conceptual reference of the problem domain.
• The domain model expresses enduring truths about the universe that is
relevant to the system at hand, including:
• A definition of the scope of that domain, providing examples of systems or generic rules
of inclusion
• A vocabulary of the domain (i.e., the glossary with the principal terms)
• A model of concepts that identifies and relates the concepts of that domain
Requirements of Modeling

• Use Case Models

• A use case model defines the boundaries of the system within the
environment and specifies the functionalities provided by the system.
• A use case model is related to one or more requirements: the most complex
use cases are associated with many requirements, whilst the simplest ones
are related to fewer numbers of requirements.
• Use case models are represented by use case diagrams consisting of:
• Use cases (represented by ellipses)
• Actors (represented by stylized human figures)
Requirements of Modeling

• Class Models
• Class models are an essential part of the object-oriented paradigm; class
models are necessary to indicate the existing classes and their relations.
• Each class is divided into three parts:
• The top part is used to indicate the class name
• The central part indicates the class attributes
• The bottom part lists the class operations
• The name is mandatory, but the other parts can be omitted.
• UML basically considers four types of relations between objects that can be
shown between the classes in the respective diagrams.
Requirements of Modeling

• Interaction Models
• An interaction model is used for representing an instance of a use case.
• Interaction models describe how a group of objects communicate amongst
them.
• Sequence models are used to describe the behavior of the system.
• The principal elements of sequence diagrams are:
• As indicated by the temporal axis, the diagram is read from top to bottom
• Textual annotations are located on the left side of the diagram to identify initial
conditions, actions, and activities.
• Event identifiers: Near a message
• For real-time systems that are conscious of time restrictions, timing marks can be used,
with the available options
• State marks: These can be added to the sequence diagrams
Requirements of Modeling

• State Models
• State diagrams can be used for defining the (dynamic, temporal) behavior of a
class (i.e., its instances).
• state differs from other states in the following:
• The events it accepts
• The transitions it takes as a result of the accepted events
• The actions it performs
• A transition is a response to an event that causes a state change.
• State machines are used when a transition between states occurs, mainly as
an answer to significant events.
• State machines extend the most conventional diagrams along three axes
related to hierarchy, concurrency, and communication.
Requirements of Modeling

• Activity Models
• Activity models are useful to relate the control flow among the activities of a
given business process.
• These models address behavioral aspects of the systems or entities under
consideration.
• These models are appropriate when the behavior change occurs, mainly due
to the end of the action/activity executed and not to the occurrence of
events, as is the case with state models.
Enterprise Modeling

• Enterprise modeling is the process of creating an integrated

enterprise model that captures the aspects of the enterprise required
for the modeling purpose at hand.
• Enterprise modeling can be represented by:
• Textual representation
• Spreadsheet representation
• Graphic representation without the use of a specific notation
• Graphic representation with the use of a specific notation
Enterprise Model Components

• A visual model consists of symbols in the form of geometric shapes

such as rectangles and ellipses and the lines connecting them (e.g.,
arrows).
• The symbols are referred to as model components and the
connections as relationships.
• Many modeling languages support views and levels to enable
reduction of the complexity of the representation.
Enterprise Knowledge Development

• An enterprise model consists of a number of related “submodels,”

each describing the enterprise from a particular perspective.
• Enterprise knowledge development is an example of a typical
enterprise modeling that includes an overall model composed of
inter-related submodels for integrating different views of the
organization.
• Enterprise knowledge development is composed of six integrated
submodels focusing on a different aspect of the enterprise.
Enterprise Knowledge Development
Process Modeling

• A business process model is the result of mapping a business process.

• This business process can be either a real-world business process as
perceived by a modeler or a conceptualized business process.
• Business process modeling is the human activity of creating a
business process model.
• Business process modeling involves an abstraction from the real-
world business process because it serves a certain modeling purpose.
• A business process modeling language can be specified using a
metamodel.
Semiotic Ladder

• Process models are assembled from signs and, like in the case of any
other signs, the modeling efforts are guided by the theories from
semiotics.
• The study of signs spans across the semiotic ladder, as follows:
• Social
• Pragmatic
• Semantic
• Syntactic
• Empirical
• Physical
SQUEAL framework

• The SQUEAL framework has been used for the evaluation of modeling
and modeling languages of a large number of perspectives, including
data, object, process, enterprise, and goal-oriented modeling on the
corresponding dimensions:
• Social quality
• Pragmatic quality
• Semantic quality
• Syntactic quality
• Empirical quality
• Physical quality
Process Modeling Languages

• Petri Nets
• C. A. Petri proposed Petri nets as a means of describing the operation of
discrete distributed systems.
• A Petri net takes the form of a directed bipartite graph wherein the nodes are
either transitions or places.
• The operational semantics of a Petri net are described in terms of tokens,
which signify a thread of control flowing through a process.
• It demands that a process should have:
• The option to complete
• Proper completion guaranteed
• No dead tasks that will never be executed
Process Modeling Languages

• Event-Driven Process Chains

• Event-driven process chains (EPCs) were developed by August-Wilhelm
Scheer as part of the Architecture of Integrated Information Systems
framework.
• An EPC model describes a business process in terms of a series of function-
based transformations between a set of input events and a set of output
events.
• An EPC model takes the form of a directed graph, which always starts and
ends with events.
• For the definition of complex routing rules, there are three kinds of connector
types: AND (symbol ∧), OR (symbol ∨), and XOR (symbol ×)
Process Modeling Languages

• Yet Another Workflow Language

• Yet Another Workflow Language (YAWL) can be considered a superset of both
Petri nets and EPCs in terms of modeling elements.
• The analysis of both Petri nets and EPCs revealed that these languages have
problems with representing certain behavior.
• A multiple instance task might be executed several times in parallel until a
condition is fulfilled. Such multiple instance tasks specify four parameters:
• The minimum
• The maximum number of instances
• A threshold for continuation
• Whether new instances may be created dynamically or not
Business Process Modeling Notation

• BPMN is an Extensible Markup Language-based language for defining

business processes with a formal metamodel and an associated
graphical notation.
• BPMN version 2.0.2 is designed to be utilized as:
• High-level, graphical business modeling language (with a limited range of
modelling constructs).
• Detailed graphical modeling language (with a comprehensive range of
modelling constructs).
• Executable business process language, capturing sufficient details about the
control-flow, data, and resource aspects of a business process so that it can
be directly executed by a business process engine.
Process Description for Storing Business Process Models

• Modeling of processes is a complex and time-consuming task that can

be simplified by the reuse of process models.
• A repository is, therefore, necessary to store and manage process
models.
• In the Universal Process Repository, process definitions exist at two
levels: the user level and the repository level.
• At this level, a business process is modeled by using graphical
constructs of a process modeling language such as BPMN, EPC, or
YAWL.
Process Description for Storing Business Process Models

• There are several process modeling languages (e.g., EPC, YAWL, BPMN) that
can be used for modeling business processes.
• In order to provide support for different modeling languages in the
Universal Process Repository, a common format for storing and sharing
process models is needed, wherein the common format only stores
fundamental elements of process models.
• The concrete elements are obtained by employing the following four
perspectives:
• Functional perspective
• Behavioral perspective
• Organizational perspective
• Informational perspective
Summary

• A model represents in a simplified way the reality for a given purpose,

emphasizing some elements and ignoring others.
• Models can be characterized according to three dimensions:
representativeness (e.g., prescriptive, descriptive); perspective (e.g.,
behavioral, structural); and form (e.g., symbolic, physical).
• An ontology that introduces relevant concepts related to modeling
and permits one to distinguish and associate concepts like model,
specification, description, diagram, language, and notation.
• Several frequently-used business process modeling languages
including Petri nets, EPCs, YAWL, UML activity diagrams, and BPMN.
 Main Reference
1. Chapter 6 (Enterprise Modeling by Vivek Kale)

This Presentation is mainly dependent on the textbook: Enterprise Process Management Systems by Vivek Kale
This Chapter presents the basic concepts of modeling, enterprise modeling, and
process modeling. The chapter presents several frequently used business
process modeling languages including Petri Nets, Event-driven Process Chains
(EPC), Yet Another Workflow Language, Unified Modeling Language activity
diagrams, and BPMN.
Thank You