Extended Enterprise Modeling Language: Difference between revisions

Revision as of 17:57, 22 May 2010

Revision as of 07:47, 23 May 2010

Line 17:

==EEML Topics==

===Modeling domains===

The EEML-language is divided into 4 sub-languages, with well-defined links across these languages<ref name="Kro06"> [[John Krogstie]] (2006). [http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-337/paper9.pdf " Using EEML for Combined Goal and Process Oriented Modeling: A Case Study"].</ref>:

* [[Process modeling]]

* [[Data modeling]]

Line 49:

===Goal modelling principles===

Within [[Requirements analysis|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 <ref>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</ref>. 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. <ref>

E. Yu, “Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering”, 1997 IEEE</ref>

* 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”.<ref name="cs.toronto.edu">E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html</ref> Goals can also be useful when modelling contexts. <ref>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.</ref>

* Clarifies requirements : Specifying goals leads to asking “why”, “how” and “how else”. <ref>E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.name="cs.toronto.edu"/pub/eric/REFSQ98.html</ref> 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. <ref>E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.name="cs.toronto.edu"/pub/eric/REFSQ98.html</ref>

* 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.)

Line 63:

==Goal and process oriented modeling==

We can describe process model as models that comprise a set of activities and an activity can be decomposed into sub-activities<ref name=eeml1>

Yun Lin and Arne Sølvberg Goal Annotation of Process Models for Semantic Enrichment of Process Knowledge </ref>. These activities have relationship amongst themselves. A goal describes the expected state of operation in a business enterprise and it can be linked to whole process model or to a process model fragment with each level activity in a process model can be considered as a goal <ref name =eeml1 />.

Goals are related in a hierarchical format where you find some goals are dependent on other sub goals for them to be complete which means all the sub goals must be achieved for the main goal to be achieved. There is other goals where only one of the goals need to be fulfilled for the main goal to be achieved. In goal modeling, there is use of deontic operator which falls in between the context and achieved state<ref name=emml2>J. Krogstie (2005) EEML2005: EXTENDED ENTERPRISE MODELING LANGUAGE </ref>. Goals apply to tasks, milestones, resource roles and resources as well and can be considered as action rule for at task. EEML rules were also possible to although the goal modeling requires much more consultation in finding the connections between rules on the different levels<ref name=eeml3>John Krogstie (2008) Using EEML for Combined Goal and Process Oriented Modeling: A Case Study. IDI, NTNU,Trondheim, Norway. Proceedings of EMMSAD 2008.</ref>. Goal-oriented analysis focuses on the description and evaluation of alternatives and their relationship to the organizational objectives <ref name=eeml4> Mylopoulos, Chung, and Yu (1999) : “From Object-oriented to Goal-oriented Requirements Analysis”. Communications of the ACM, January</ref>.

==Resource modeling==

Line 96:

- Process knowledge management: Integrate the different business processes levels of abstraction.

- Motivation: creates enthusiasm and commitment among members of an organization to follow up on the various actions that are necessary to restructure the enterprise.

EEML can help organisations meet these challenges by modeling all the manufacturing and logistics processes in the extended enterprise. This model allows capturing a rich set of relationships between the organization, people, processes and resources of the virtual enterprise<ref name=eeml5>H.D. Jørgensen (2004) Interactive Process Models. Department of Computer and Information Science Faculty of Information Technology, Mathematics and Electrical Engineering, Norwegian University of Science and Technology. Trondheim, Norway</ref>. It also aims at making people understand, communicate, develop and cultivate solutions to business problems<ref name=eeml6>R. Matulevičius and P. Heymans (2007) Visually Effective Goal Models Using KAOS. PReCISE Research Center, Computer Science Department, University of Namur, rue Grandgagnage 21,5000 Namur, Belgium.</ref>

Line 131 ⟶ 130:

* [http://www.idi.ntnu.no/emner/tdt4250/pensum/EEML2005-autumn2005.doc Description of EEML]

* [http://www.cs.toronto.edu/km/GRL/ GRL web site] University of Toronto,

* [http://www.businessrulesgroup.org/bmm.shtml "The Business Motivation Model] Business Governance in a Volatile World", RelaseRelease 1.3, Business Rules Group, 2007.

[[Category:Business process]]