Extended Enterprise Modeling Language

This is an old revision of this page, as edited by Mdd (talk | contribs) at 00:08, 5 November 2008 (Added a first image + commonscat). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across a number of layers. EEML is intended to be a simple language, which makes it easy to update models. In addition to capturing the various tasks(can consist of several sub-tasks) and their interdependencies, models show which roles perform each task, and the tools, services and information they apply.

Example of EEML Goal modeling and process modeling.

EEML is the result of several years of research. Originally developed in [1] to support development and use of interactive models.

EEML Topics

Modeling domains

The modeling language currently includes four modeling domains, in addition to general modeling mechanisms and primitives provided in Metis (modelling)

  • Process modeling: Process logic is modeled through nested structures of tasks and decision points.
  • Resource modeling: Roles are used to connect resources of various kinds (people, organisations, information, and tools) to the tasks.
  • Goal modeling : The modeling of goal and rule structures in an organisation
  • Data modeling (UML Class Diagram), which uses Unified Modeling Language

EEML Layers

EEML has four layers of interest

  • Generic Task Type: This layer identifies the constituent tasks of generic, repetitive processes and the logical dependencies between these tasks.
  • Specific Task Type: In this layer process models are expanded, concretised, decomposed and specialised to facilitate business solutions.
  • Manage Task Instances: Here, more detailed decisions are taken regarding work in the actual work environment with its organisational, information, and tool resources.
  • Perform Task Instances: This layer covers the actual execution of tasks.

Goal Modelling

Goal Modelling is one of the four EEML modeling domains age. A goal expresses the wanted (or unwanted) state of affairs (either current or future) in a certain context. Example of the goal model is depicted below. It shows goals and relationships between them. It is possible to model advanced goal-relationships in EEML by using goal connectors. A goal connector is used when one need to link several goals.

In goal modeling to fulfil Goal1, one must achieve to other goals: both Goal2 and Goal3 (goal-connector with “and” as the logical relation going out). If Goal2 and Goal3 are two different ways of achieving Goal1, then it should be “xor” logical relationship. It can be an opposite situation when both Goal2 and Goal3 need to be fulfilled and to achieve them one must fulfil Goal1. In this case Goal2 and Goal3 are linked to goal connector and this goal connector has a link to Goal1 with ”and”-logical relationship.

The table indicate different types of connecting relationships in EEML goal modeling. Goal model can also be interlinked with a process model.

Goal-oriented Requirements Language

Goal-oriented Requirements Language (GRL) is a language that is designed to support goal-oriented modeling and reasoning about requirements, especially the non-functional requirements [1]. It allows to express conflict between goals and helps to make decisions that resolve conflicts. There are three main categories of concepts in GRL: intentional elements, intentional relationships and actors [2]. They are called for intentional because they are used in models that primarily concerned with answering "why" question of requirements (for ex. why certain choices for behavior or structure were made, what alternatives exist and what is the reason for choosing of certain alternative.)

File:GRL legend.GIF
GRL Notation
Intentional elements

Intentional elements are: goal, soft goal, task, belief and resource.

  • Goal is condition or situation that can be achieved or not. Goal is used to define the functional requirements of the system. In GRL notation goal is represented by a rounded rectangle with the goal name inside.
  • Task is used to represent different ways of how to accomplish goal. In GRL notation task is represented by hexagon with the task name inside.
  • Softgoal is used to define non-functional requirements. It’s usually a quality attribute of one of the intentional elements. In GRL notation softgoal is represented by irregular curvilinear shape with the softgoal name inside.
  • Resource is a physical or informational object that is available for use in the task. Resource is represented in GRL as a rectangle.
  • Belief is used to represent assumptions and relevant conditions. This construct is represented as ellipse in GRL notation.
  • Actor is an active object that carries out actions to achieve the goal. In GRL notation actor is represented as a circle with the actor name inside.
  • Agent is a concrete actor, such as a human individual or machine.
 
GRL relationships
Relationships

Intentional relationships are: means-ends, decomposition, contribution, correlation and dependency.

  • Means-ends relationship shows how the goal can be achieved. For example it can be used to connect task to a goal.
  • Decomposition relationship is used to show the sub-components of a task.
  • Contribution relationship describes how one element influence another one.
  • Correlation relationship describes side effects of existence of one element to others.
  • Dependency relationship describe interdependences between agents.

References

Further reading

  • Jørgensen, Håvard D.: "Process-Integrated eLearning"
  • John Krogstie, EEML2005: Extended Enterprise Modeling Language
  • John Krogstie, : "A Semiotic Approach to Quality in Requirements Specifications" (Proc. IFIP 8.1)
  • Lin Liu, Eric Yu, “Designing information systems in social context: a goal and scenario modelling approach”