Jump to content

Extended Enterprise Modeling Language

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Mdd (talk | contribs) at 20:06, 8 November 2009 (→Modeling domains: quotation marks + some rewrite). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Example of EEML Goal modeling and process modeling.

Extended Enterprise Modeling Language (EEML) in software engineering is a modelling language used for Enterprise modelling across a number of layers.

Overview

Extended Enterprise Modeling Language (EEML) is modelling language, which combines structural modeling, business process modeling, goal modeling with goal hierarchies, and resource modeling. It is used in practice to bridge the type of goal modeling used in common requirements engineering to other modeling approaches. According to Johannesson and Söderström (2008) "the process logic in EEML is mainly expressed through nested structures of tasks and decision points. The sequencing of tasks is expressed by the flow relation between decision points. Each task has an input port and the output port being decision points for modeling process logic".[1]

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.

History

Extended Enterprise Modeling Language (EEML) is end 1990s developed in the EU project EXTERNAL as extension of the Action Port Model (APM) by S. Carlsen (1998).[2] The EXTERNAL project [3] aimed to facilitate inter-organisational cooperation in knowledge intensive industries. It is the hypotheses of the project that interactive process models form a suitable framework for tools and methodologies for dynamically networked organisations. In the project EEML (Extended Enterprise Modelling Language) was first constructed as a common metamodel, designed to enable syntactic and semantic interoperability.[4]

It has been further developed in the EU projects Unified Enterprise Modelling Language (UEML)[5] from 2002 to 2003 and the ongoing ATHENA project.[6] The objectives of UEML Working group has been to define, to validate and to disseminate a set of core language constructs to support a Unified Language for Enterprise Modelling, named UEML, to serve as a basis for interoperability within a smart organisation or a network of enterprises.[7]

EEML Topics

Modeling domains

The EEML-language is divided into 4 sub-languages, with well-defined links across these languages[8]:

Process modeling in EEML, according to Krogstie (2006) "supports the modeling of process logic which is mainly expressed through nested structures of tasks and decision points. The sequencing of the tasks is expressed by the flow relation between decision points. Each task has minimum an input port and an output port being decision points for modeling process logic, Resource roles are used to connect resources of various kinds (persons, organizations, information, material objects, software tools and manual tools) to the tasks. In addition, data modeling (using UML class diagrams), goal modeling and competency modeling (skill requirements and skills possessed) can be integrated with the process models".[8]

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.

  • Goal modeling in EEML
    Goal modeling in EEML
  • Connecting relationships
    Connecting relationships
  • Goal modeling and process modeling
    Goal modeling and process modeling

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 modelling principles

Within requirements engineering (RE), the notion of goal has increasingly been used. Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment [9]. Goals are central in some RE frameworks, and can play a supporting role in others. Goal-oriented techniques may particularly be useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed. [10]

  • Expresses the relationships between systems and their environments : Earlier, requirements engineering focused only on what the system is supposed to do. Over the past years, there has been a more or less mutual understanding, that it is also very important to understand and characterize the interaction between the intended system and its environment. Relationships between systems and their environments are often expressed as goal-based relationships. The motivation for this is “partly today's more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”.[11] Goals can also be useful when modelling contexts. [12]
  • Clarifies requirements : Specifying goals leads to asking “why”, “how” and “how else”. [13] Requirements of the stakeholders are often revealed in this process. The stakeholders may seem to be more likely to become aware of potential alternatives for fulfilling their goals, and thereby less likely to over-specify their requirements. Requirements from clients and stakeholders may often be unclear, especially the non-functional ones. A goal-oriented approach allows the requirements to be refined and clarified through an incremental process, by analyzing requirements in terms of goal decomposition.
  • Deals with conflicts : Goals may provide a useful way of dealing with conflicts, such as tradeoffs between costs performance, flexibility, etc, and divergent interests of the stakeholders. Goals can deal with conflicts because meeting of one goal can interfere with the meeting of others. Different opinions on how to meet a goal has led to different ways of handling conflicts. [14]
  • Decides requirements completeness : Requirements can be considered complete if they fulfil explicit goals in the requirement model.
  • Connects requirements to design : Goals can be used in order to connect the requirements to the design. For some, goals are an important mechanism in this matter. (The Non-Functional Requirements (NFR) framework uses goals to guide the design process.)

Goal-oriented Requirements Language

GRL Notation

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 [15] 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 [16]. 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.)

See also

References

  1. ^ Paul Johannesson and Eva Söderström (2008) .Information Systems Engineering. p.58-61.
  2. ^ Carlsen, S. (1998). "Action port model: A mixed paradigm conceptual workflow modeling language". In: Proceedings of Third IFCIS Conference on Cooperative Information Systems (CoopIS'98), New York.
  3. ^ EXTERNAL EXTERNAL - Extended Enterprise Resources, Networks And Learning, EU Project, IST-1999-10091,
  4. ^ Håvard D. Jørgensen (2004). Interactive Process Models. Thesis Norwegian University of Science and Technology Trondheim, Norway. p.173-202.
  5. ^ François Vernadat (2002). "UEML: towards a unified enterprise modelling language". In: Int. J. Production Research, 40 (17), 4309-4321.
  6. ^ John Krogstie and T.A. Halpin, Keng Siau (2004). Information Modeling Methods and Methodologies. Idea Group Inc (IGI), p.73.
  7. ^ Unified Enterprise Modelling Language. Accessed 29 Nov 2008.
  8. ^ a b John Krogstie (2006). " Using EEML for Combined Goal and Process Oriented Modeling: A Case Study".
  9. ^ L. Liu and E. Yu, “Designing information systems in social context: a goal and scenario modelling approach”, 2003 Elsevier Ltd. http://www.cs.toronto.edu/~liu/publications/ISj03.pdf
  10. ^ E. Yu, “Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering”, 1997 IEEE
  11. ^ E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html
  12. ^ K.Pohl and P. Haumer, “Modelling Contextual Information about Scenarios”, Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ ’97, Barcelona, Catalonia, Spain, June 1997 pp. 187-204.
  13. ^ E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html
  14. ^ E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html
  15. ^ Lin Liu, Eric Yu, “Designing information systems in social context: a goal and scenario modelling approach”
  16. ^ GRL web site, University of Toronto, http://www.cs.toronto.edu/km/GRL/

Further reading

  • Bolchini, D., Paolini, P.: "Goal-Driven Requirements Analysis for Hypermedia-intensive Web Applications", Requirements Engineering Journal, Springer, RE03 Special Issue (9) 2004: 85-103.
  • Jørgensen, Håvard D.: "Process-Integrated eLearning"
  • Kramberg, V.: "Goal-oriented Business Processes with WS-BPEL", Master Thesis, University of Stuttgart, 2008.
  • John Krogstie (2005). EEML2005: Extended Enterprise Modeling Language
  • John Krogstie (2001). "A Semiotic Approach to Quality in Requirements Specifications" (Proc. IFIP 8.1) IFIP 8.1. Working Conference on Organizational Semiotics.
  • Lin Liu, Eric Yu. "Designing information systems in social context: a goal and scenario modelling approach"
Wikimedia Commons has media related to Extended Enterprise Modeling Language.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Extended_Enterprise_Modeling_Language&oldid=324701132"