Functional software architecture: Difference between revisions

Revision as of 07:02, 25 February 2006

Latest revision as of 09:49, 29 July 2025

(68 intermediate revisions by 37 users not shown)

Line 1:

{{Confusing|date=May 2011}}

{{cleanup-date|September 2005}}

'''Notice of Originality'''

I declare that this paper is my own work and that information derived from published or unpublished work of others has been acknowledged in the text and has been explicitly referred to in the list of references.

A '''functional software architecture''' ('''FSA''') is an architectural model that identifies [[Enterprise architecture|enterprise]] functions, interactions and corresponding [[Information technology|IT]] needs. These functions can be used as a reference by different [[___domain expert]]s to develop IT-systems as part of a co-operative information-driven enterprise. In this way, both [[software engineer]]s and enterprise architects can create an information-driven, integrated organizational environment.

Name: Niels de Vrij

Date: 27-04-2005

Place: Utrecht, The Netherlands

==IntroductionOverview==

A '''Functional Software Architecture''' (FSA) is an architectural model that identifies [[enterprise]] functions, interactions and corresponding [[Information Technology|IT]] needs, which can be used as reference by different ___domain experts to develop IT-systems as part of a co-operative information-driven enterprise. In this way both [[software engineers]] and enterprise architects are able to create an information-driven, integrated organizational environment.

When an integrated software system needs to be developed and implemented normally a number ofseveral tasks and corresponding responsibilities can normally be divided:

##Strategic management and business consultants set objectives in relation to a more efficient/ effective business process.

##Enterprise engineers come up with a design of a more efficient business process and a request for a certain information system in the form of an Enterprise Architecture.

##Software engineers come up with the design of this information system, which describes the components and structural features of the system by use of a certain Architecture Description Language (ADL).

##Computer programmers code the different modules and actually implement the system.

# Strategic management and business consultants set objectives in relation to a more efficient/effective business process.

# Enterprise engineers come up with a design of a more efficient business process and a request for a certain information system in the form of an Enterprise Architecture.

# Software engineers come up with the design of this information system, which describes the components and structural features of the system by use of a certain [[architecture description language]] (ADL).

# Computer programmers code the different modules and actually implement the system.

Off course theThe described work division is in reality much more complex and also involves more actors but it outlines the involvement of people with different backgrounds in creating a software system that enables the organization to reach business objectives. A wide variety of material produced by different actors within this system development process needs to be exchanged between, and understandunderstood by, multiple actors.

Especially in the field of software engineering muchmany tools (A4 Tool, CAME, [[ARIS Express|ARIS]]), [[computer languages|languages]] (ACME, Rapide, [[Unified Modeling Language|UML]]) and methods ([[Dynamicdynamic Systemssystems Developmentdevelopment Methodmethod|DSDM]], [[IBM Rational Unified Process|RUP]], [[ISPL]]) are developed and extensively used. Also, the transition between the software engineers (step 3) and computer programmers (step 4) is already highly formalized by, for instance, [[Object-oriented programming|object-oriented]] development and corresponding [[Java programming]].

Setting strategic objectives (step 1) and the corresponding search for [[business]] opportunities and weaknesses is a subject extensively discussed and investigated for more than hundred years. Concepts like for instance [[Business process reengineering]] (Fredrick Taylor), [[Product software market analysis]], [[Requirements analysis]] are commonly known and extensively used in this context. These strategic inputs must be used for the development of a good enterprise design (step2), which can then be used for software design and implementation respectively.

Recent studies have shown that these enterprise architectures can be developed by a number of different methods and techniques. Before these methods and techniques are discussed in detail a definition of an [[Enterprise architecture]] is given:

Setting strategic objectives (step 1) and the corresponding search for business opportunities and weaknesses is a subject extensively discussed and investigated for more than a hundred years. Concepts like [[business process reengineering]], [[product software market analysis]], and [[requirements analysis]] are commonly known and extensively used in this context. These strategic inputs must be used for the development of a good enterprise design (step 2), which can then be used for software design and implementation respectively.

''An Enterprise Architecture is a strategic information asset base, which defines the mission, the information necessary to perform the mission and the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs.''

Recent studies have shown that these enterprise architectures can be developed by several different methods and techniques. Before these methods and techniques are discussed in detail a definition of an [[enterprise architecture]] is given:

This definition emphasizes the use of the architecture as a rich strategic information source for the improvement of business processes and development of needed information systems. If defined, maintained, and implemented effectively, these institutional blueprint assist in optimizing the interdependencies and interrelationships among an organizations business operations and the underlying IT that support operations.

:''An Enterprise Architecture is a strategic information asset base, which defines the mission, the information necessary to perform the mission and the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs.''

This definition emphasizes the use of the architecture as a rich strategic information source for the improvement of business processes and development of needed information systems. If defined, maintained, and implemented effectively, these institutional blueprints assist in optimizing the interdependencies and interrelationships among an organization's business operations and the underlying IT that support operations.

Having red the definition of a Functional Software Architecture at the beginning of this entry we can see a Functional Software Architecture as a type of Enterprise Architecture that can be used as a rich reference for the development of an integrated information system. Naming it a Functional Software Architecture enforces practitioners to use it as a strategic input for a [[Technical architecture]]. A formal mapping between a Functional Software Architecture and a type of ADL is thereby needed. In this way the formal use and reuse of enterprise architectures as strategic input for software architectures can be realized.

Having read the definition of functional software architecture at the beginning of this entry we can see a functional software architecture as a type of enterprise architecture that can be used as a rich reference for the development of an integrated information system. Naming it a functional software architecture encourages practitioners to use it as a strategic input for a [[technical architecture]]. A formal mapping between functional software architecture and a type of [[Architecture description language|ADL]] is therefore needed. In this way, the formal use and reuse of enterprise architectures as strategic input for software architectures can be realized.

----

==Development of a FSA==

As the boundary of an enterprise is extended, it becomes increasingly important that a common “big"big picture”picture" of needed business, people and IT system activities is developed and shared by all the parties involved.<ref [1]name="Kim">Kim & Weston & Hodgson & Lee (2002); The complementary use of IDEF and UML. Information system engineering, Deajon University South Korea, Computers & Industrial Engineering 50, 35–56.</ref> A Functionalfunctional Softwaresoftware Architecturearchitecture does this by breaking down the organization in business functions and corresponding IT needs. In this way, the enterprise engineer provides a rich schematic reference that can be used by the software engineer in the development of these IT-systems.

The development of a Functionalfunctional Softwaresoftware Architecturearchitecture can be done by a number of (combined) methods and techniques. Figure 1 outlines the methods and techniques that will be discussed. Filling in the “gab”"gap" between the enterprise engineers and software engineers through the use of different combinations of methods and techniques will be the main objective. However, this objective can only be reached when combined methods result in clear and rich functional software architectures that are developed and used by both parties.

Optimizing the internal and external business processes through process reengineering is one of the main objectives an enterprise can have in times of high external pressure. A [[business process]] involves value-creating activities with certain inputs and outputs, which are interconnected and thereby jointly contribute to the outcome (product or service) of the process. Process reengineering covers a variety of perspectives on how to change the organization. It is concerned with the redesign of strategic, value-adding processes, systems, policies and organizational structures to optimize the processes of an organization.<ref>Zakarian & Kusiak; Process analysis and reengineering: Department of Industrial Engineering, University of Iowa, USA, Computers & Industrial Engineering 41, 135–150</ref>

[[Image:FSA-network.PNG]]

'''Figure 1: Methods and techniques for the development of FSA'''

The different methodologies, methods and techniques discussed in this entry are presented as grey boxes. Also the related tools, methods and techniques discussed in the introduction are given. The grey boxes can be connected with each other by lines, which indicate a combination of methods for the development of a FSA.

All boxes within the rectangle “Functional Software Architecture” are connected with the Enterprise Engineering box, which outlines the fact that these methods/methodologies can be used in “Enterprise Engineering”. Only the UML and Petri Net boxes are directly connected with the box containing “Software Engineering”. That is, these two are commonly used by software engineers for the design and coding of a system.

Figure 1 shows at the top-level the “Enterprise Engineering” field;

Optimizing the internal and external business processes through process reengineering is one of the main objectives an enterprise can have in times of high external pressure. A [[business process]] involves value creating activities with certain inputs and outputs, which are interconnected and thereby jointly contribute to the final outcome (product or service) of the process. Process reengineering covers a variety of perspectives of how to change the organization. It is concerned with the redesign of strategic, value adding processes, systems, policies and organizational structures to optimize the processes of an organization [2]. This paper considers process (re)engineering as part of the broader enterprise engineering field.

----

==Modeling the business==

Within the area of [[enterprise engineering]] formal methodologies, methods and techniques are designed, tested and extensively used in order to offer organizations reusable business process solutions:

*Computer-integrated manufacturing open systems architecture (CIMOSA) methodology<ref>Beekman, (1989); European Committee for Standardization, ECN TC310 WG1, 1994</ref>

**The [[#Computer Integrated Manufacturing Open Systems Architecture]] (CIMOSA) methodology[3]

*Integrated definition (IDEF) methodology<ref>U.S. Airforce (1981); ICAM architecture part 1, Ohio, Air Force Materials Laboratory, Wright-Patterson</ref>

**The [[#Integrated DEFinition]] (IDEF) methodology [4]

*Petri Nets<ref>Peterson J.L. (1981); Petri net theory and the modeling of systems, Englewood Cliffs, N.J., Prentice Hall.</ref>

**[[#Petri Nets]] [5]

*Unified modeling language (UML) or unified enterprise modeling language (UEML)<ref># Marshall, C. (2000); Enterprise Modelling with UML, {{ISBN|0-201-43313-3}}, Addison-Wesley, MA.</ref><ref>[[François Vernadat]]; A vision for future work of the task force (IFAC-IFIP).</ref>

**[[#Unified Modeling Language]] (UML) or Unified Enterprise Modeling Language (UEML) [6,7]

**[[#Enterprise Function Diagrams]] (EFD)

These methodologies/techniques and methods are all more or less suited in modeling the enterprise and its underlying processes. So, which of them are suited for the further development of information technology systems that are needed for effective and efficient (re)designed processes? More important, why using a time-consuming enterprise methodology when information and software engineers can’t or won’t use the unclear results in the development of efficiency enabling IT systems? Before we can give the answers to these questions some short descriptions of the listed methods above are given.

===Computer-integrated manufacturing open systems architecture===

These methodologies/techniques and methods are all more or less suited in modeling the enterprise and its underlying processes. So, which of them are suited for the further development of Information Technology systems that are needed for effective and efficient (re)designed processes? More important, why using a time consuming enterprise methodology when information and software engineers can’t or won’t use the unclear results in the development of efficiency enabling IT systems? Before we can give the answers to these questions some short descriptions of the listed methods above are given.

[[CIMOSA]] provides templates and interconnected modeling constructs to encode business, people and IT aspects of enterprise requirements. This is done from multiple perspectives: information view, function view, resource view, and organization view. These constructs can further be used to structure and facilitate the design and implementation of detailed IT systems.

<!--missing figure-->

The division in different views makes it a clarifying reference for enterprise and software engineers. It shows information needs for different enterprise functionalities (activities, processes, operations) and corresponding resources. In this way, it can easily be determined which IT-system will fulfill the information needs in a certain activity and process.

===Computer Integrated Manufacturing Open Systemsdefinition Architecture(IDEF)===

[[IDEF]] is a [[structured modeling]] technique, which was first developed for the modeling of manufacturing systems. It was already being used by the U.S. Airforce in 1981. Initially, it had 4 different notations to model an enterprise from a certain viewpoint. These were [[IDEF0]], [[IDEF1]], IDEF2 and [[IDEF3]] for functional, data, dynamic and process analysis respectively. In the past decades, several tools and techniques for the integration of the notations are developed incrementally.

CIMOSA provides templates and interconnected modeling constructs to encode business, people and IT aspects of enterprise requirements. This is done from multiple perspectives; Information view, Function view, Resource view and Organization view. These constructs can further be used to structure and facilitate the design and implementation of detailed IT systems. Figure 2 shows a part of the so called CIMOSA cube, which provides a consistent and adequately structured modelling framework [8]. It shows the different views and corresponding relationships between for instance activities, objects and resources. The meanings of the modelling notations, the arrow and half-circle, are given on top.

IDEF clearly shows how a business process flows through a variety of decomposed business functions with corresponding information inputs, outputs, and actors. Like CIMOSA, it also uses different enterprise views. Moreover, IDEF can be easily transformed into UML-diagrams for the further development of its systems. these positive characteristics make it a powerful method for the development of functional software architectures.

<!-- Unsourced image removed: [[Image:CIMOSA.PNG]] -->

'''Figure 2: Part of the CIMOSA constructs (without organization view)'''

The division in different views makes it a clarifying reference for enterprise and software engineers. It shows information needs for different enterprise functionalities (activities, processes, operations) and corresponding resources. In this way it can easily be determined which IT-system will fulfill the information needs in a certain activity and process.

===Integrated DEFinition===

IDEF is a structured modeling technique, which was first developed for the modeling of manufacturing systems. It was already being used by the U.S. Airforce in 1981. Initially it had 4 different notations to model an enterprise from a certain viewpoint. These were IDEF0, IDEF1, IDEF2 and IDEF3 for functional, data, dynamic and process analysis respectively. In the past decades a number of tools and techniques for the integration of the notations are developed in an incremental way. However, recent interesting attempts by Kim et. al. (2002) show it can be done; skip the IDEF2 notation and use an extended version of the IDEF1 (IDEF1x) enables the creation of an integrated IDEF/UML framework for the development of IT systems within the organization.

Figure 3 shows an IDEF0 functional diagram that is used to model the development process of educational material within a publish company:

**On top we see some meta-data about the diagram including author, project, revision-number, date and context. The context outlines the hierarchical way by which IDEF0 diagrams present business processes. In this case we see a context A0, which indicates that this is the top level diagram that can be decomposed into lower level diagrams like A1 and A2.

**The diagram shows 3 main functions within the publication process namely: “analyse market”, “plan a publication” and “develop a book”. Information inputs entering a function from the left result in information outputs at the right of the functions. Other needed resources like budget enter a function from the top. The actors for the different functions are shown at the bottom.

**A function like develop a book can be further decomposed into sub-functions and sub-sub functions until an object level is reached. This most detailed functional level can then be used for the translation into IDEF1x models, IDEF3 models and UML-diagrams respectively.

[[Image:IDEF0.PNG]]

'''Figure 3: IDEF0 functional diagram for the “publish new educational material” process'''

IDEF clearly shows how a business process flows through a variety of decomposed business functions with corresponding information inputs, outputs and actors. Like CIMOSA, it also uses different enterprise views. Moreover, IDEF can be easily transformed into UML-diagrams for the further development of IT systems. These positive characteristics make it a powerful method for the development of Functional Software Architectures.

===Petri Nets===

[[Petri Netsnet]]s are known tools to model manufacturing systems.<ref>Silva, [9]M. and Valette, R. (1989); Petri nets and flexible manufacturing. Lecture Notes on Computer Science, 424, 374–417.</ref> They are highly expressive and provide good formalisms for the modellingmodeling of [[concurrent systemssystem]]s. The most advantageous properties are that of simple representation of states, concurrent system transitions, and capabilities to model the duration of transitions.

Petri Nets therefore can be used to model certain business processes with corresponding state and transitions or activities with in and outputs. Moreover, Petri Nets can be used to model different software systems and transitions between these systems. In this way programmers use it as a schematic coding reference.

In recent years a number of attempts have shown that Petri Nets can contribute to the development of business process integration. One of these is the Model Blue methodology, which is developed by IBM Chinese Research Laboratory and outlines the importance of model driven business integration as an emerging approach for building integrated platforms [10]. A mapping between their Model Blue business view and an equivalent Petri Net is also shown, which indicates that their research closes the gab between business and IT. However, instead of Petri Nets they rather use their own Model Blue IT view, which can be derived from their business view trough a transformation engine.

So, pros and cons in using Petri Nets as a modelling tool for the implementation of integrated IT systems are present. Maybe it should be combined with other methods and techniques to deliver positive results? For instance, various classes of Petri Nets can be used in combination with IDEF or CIMOSA and even UML [11]. Mostly to exercise alternative system design. However, a major drawback of Petri Nets, the inability to provide multiple views of entire enterprise systems, remains.

===Unified Modeling Language===

[[Unified Modeling Language|UML]] is a broadly accepted modeling language for the development of software systems and applications. The, so called, “object oriented community” also tries to use UML for enterprise modeling purposes. They emphasize the use of enterprise objects or business objects from which complex enterprise systems are made. A collection of these objects and corresponding interactions between them can represent a complex business system or process. Where Petri Nets focus on the interaction and states of objects, UML focuses more on the business objects themselves. Sometimes these are called the “enterprise building blocks”, which includes resources, processes, goals, rules and metamodels [12]. Despite the fact that UML in this way can be used to model an integrated software system it has been argued that the reality of business can be modeled with a software modeling language. In reaction the object oriented community makes business extensions for UML and adapts the language. UEML is derived from UML and is proposed as a business modeling language. The question remains if this business transformation is the right thing to do. It was earlier said that UML in combination with other “pure’ business methods can be a better alternative.

===Enterprise Function Diagrams===

EFD is a used modeling technique for the representation of enterprise functions and corresponding interactions. Different business processes can be modeled in these representations through the use of “function modules” and triggers. A starting business process delivers different inputs to different functions. A process flowing through all the functions and sub-functions creates multiple outputs. Enterprise Function Diagrams hereby give a very easy-to-use and detailed representation about a business process and corresponding functions, inputs, outputs and triggers.

In this way EFD has many similarities with IDEF0 diagrams, which also represent in a hierarchical way business processes as a combination of functions and triggers. Difference is that an EFD places the business functions in an organization hierarchical perspective, which outlines the downstream of certain processes in the organization. On the contrary, IDEF0 diagrams show responsibilities of certain business functions trough the use of arrows. Also, IDEF0 has a clear representation of inputs and outputs of every (sub)function.

Figure 4 shows an EFD of a publish company producing books and cd-roms for educational purposes. It gives a clear view of a publication process within an organization:

**Different modules represent the different business function on multiple organizational levels, which is highlighted by the different colors. On strategic level (yellow) a certain publication project with corresponding products is determined. This is based on certain triggers like sales forecasts, product information.

**Once the project is started several things happen on tactical level; publication needs to be planned, freelance authors need to assigned to certain tasks, everything needs to be monitored and sales needs to give some feedback to the customer. The need for certain Information technology that improves these activities becomes realistic.

**The actual production by authors and assembly by editors happens on operational level. The first two function modules are given in detail, which outlines the potential for certain IT implementations within business functions. These detailed schemes can be drawn and used by both enterprise engineers and software engineers for the development of integrated software implications. Lower level EFD could hereby be transformed in detailed UML schemes.

<!-- Unsourced image removed: [[Image:EFDpublishing.PNG]] -->

'''Figure 4: EFD of a publish company producing books and digital material'''

So, maybe EFD could be used as a business front-end to a software modeling language like UML. The major resemblance with IDEF as a modeling tool indicates that it can be done. However, more research is needed to improve the EFD technique in such a way that formal mappings to UML can be made (see dashed line figure 1). Work of Kim et. al. [1] about the complementary use of IDEF and UML has contributed to the acceptance of IDEF as business-front end. A similar study should be done with EFD and UML.

----

==Conclusion==

Bringing the best of both worlds together and incorporate it in a clear Functional Software Architecture; this is one of the first objectives an organization has to reach when business process efficiency has to be improved. This rich schematic reference must be constructed by the right combination of methods and techniques in order to set detailed software specifications into the wider enterprise context. Figure 1 shows the methods and techniques that can be used or combined. The different descriptions and corresponding graphical examples of the modeling methods show some possibilities and drawbacks:

**Graphical notation of business process as combination of different (decomposed) functions and triggers as being done in IDEF and EFD results in clear, easy to use representation. This decomposition makes translation from IDEF to UML possible.

**Multiple enterprise views like those in CIMOSA and IDEF gives a clear overview of the information needs in different functions and activities. Major advantage of CIMOSA is that it gives the relationship between these views in one big picture, while IDEF needs multiple separate diagrams and translations between views.

**The use of colors in EFD for the representation of hierarchy within an enterprise results in clear overview of the responsibilities of actors. IDEF uses arrows, which makes it difficult to separate them from normal information-triggers.

**Meta-data, like those in IDEF, should be added to a Functional Software Architecture in order to structure and store them properly.

These findings result in a possible meta-model of a Functional Software Architecture, which can be used to develop these rich references in a variety of domains.

Petri nets, therefore, can be used to model certain business processes with corresponding state and transitions or activities within and outputs. Moreover, Petri Nets can be used to model different software systems and transitions between these systems. In this way, programmers use it as a schematic coding reference.

[[Image:meta-FSA.PNG]]

In recent years several attempts have shown that Petri nets can contribute to the development of business process integration. One of these is the Model Blue methodology, which is developed by [[IBM]] Chinese Research Laboratory and outlines the importance of model-driven business integration as an emerging approach for building integrated platforms.<ref>Zhu et al. (2004); Model-driven business process integration and management: A case study with the Bank SinoPac regional service platform, IBM Corporation, Res. & Dev. Vol. 48 No. 5/6.</ref> A mapping between their Model Blue business view and an equivalent Petri Net is also shown, which indicates that their research closes the gap between business and IT. However, instead of Petri Nets they rather use their own Model Blue IT view, which can be derived from their business view through a transformation engine.

'''Figure 5: Meta model of a FSA'''

===Unified modeling language===

[[Unified modeling language|UML]] is a broadly accepted modeling language for the development of software systems and applications. The object-oriented community also tries to use UML for enterprise modeling purposes. They emphasize the use of enterprise objects or business objects from which complex enterprise systems are made. A collection of these objects and corresponding interactions between them can represent a complex business system or process. Where Petri Nets focus on the interaction and states of objects, UML focuses more on the business objects themselves. Sometimes these are called the "enterprise building blocks", which includes resources, processes, goals, rules, and metamodels.<ref>Eriksson & Penker (1998); UML Toolkit, Wiley, New York.</ref> Although UML in this way can be used to model an integrated software system it has been argued that the reality of business can be modeled with a software modeling language. In reaction, the object-oriented community makes business extensions for UML and adapts the language. UEML is derived from UML and is proposed as a business modeling language. The question remains if this business transformation is the right thing to do. It was earlier said that UML in combination with other "pure’ business methods can be a better alternative.

===Enterprise function diagrams===

Figure 5 shows in the top the meta-data that is needed to structure the created Functional Software Architectures. The different boxes represent the different business functions that can be triggered by internal and external information inputs. Differentiation between these two makes it easier to determine if outside information, like for instance government regulations, is needed for certain business functions. That is, information inputs from outside the enterprise changes the scope of an information system in development and therefore should be included in a Functional Software Architecture.

EFD is a used modeling technique for the representation of enterprise functions and corresponding interactions. Different business processes can be modeled in these representations through the use of "function modules" and triggers. A starting business process delivers different inputs to different functions. A process flowing through all the functions and sub-functions creates multiple outputs. Enterprise function diagrams hereby give a very easy-to-use and detailed representation of a business process and corresponding functions, inputs, outputs, and triggers.

The use of different colors highlights the hierarchical division of functions and corresponding downstream of the business process. It represents the organizational pyramid with increasing functions from top to bottom in the enterprise.

In this way, EFD has many similarities with IDEF0 diagrams, which also represent in a hierarchical way business processes as a combination of functions and triggers. The difference is that an EFD places the business functions in an organization's hierarchical perspective, which outlines the downstream of certain processes in the organization. On the contrary, IDEF0 diagrams show the responsibilities of certain business functions through the use of arrows. Also, IDEF0 has a clear representation of inputs and outputs of every (sub)function.

The dotted box shows which business function is decomposed into sub-functions in order to reveal detailed information needs and come up with a software design. At this detailed level a mapping to Petri Nets or UML-diagrams should result in a rich software design. In this way a developed information system is set into a wider enterprise context. However, further research, like that of Kim et. al (2002), is needed to show this mapping can actually be done.

EFD possibly could be used as a business front-end to a software modeling language like UML. The major resemblance with IDEF as a modeling tool indicates that it can be done. However, more research is needed to improve the EFD technique in such a way that formal mappings to UML can be made.<ref name="Kim"/> about the complementary use of IDEF and UML has contributed to the acceptance of IDEF as business-front end. A similar study should be done with EFD and UML.

----

==References==

{{reflist}}

[[Category:Software architecture]]

#Kim & Weston & Hodgson & Lee (2002); The complementary use of IDEF and UML. Information system engineering, Deajon University South Korea, Computers & Industrial Engineering 50, 35&ndash;56.

[[Category:Enterprise architecture]]

#Zakarian & Kusiak; Process analysis and reengineering: Departement of Industrial Engineering, University of Iowa, USA, Computers & Industrial Engineering 41, 135&ndash;150.

#Beekman, (1989); European Committee for Standardization, ECN TC310 WG1, 1994.

#U.S. Airforce (1981); ICAM architecture part 1, Ohio, Air Force Materials Laboratory, Wright-Patterson.

#Peterson J.L. (1981); Petri net theory and the modelling of systems, Englewood Cliffs, N.J., Prentice Hall.

#Marshall, C. (2000); Enterprise Modelling with UML, ISBN 0-201-43313-3, Addison-Wesley, MA.

#Vernadat F.B.; A vision for future work of the task force (IFAC-IFIP).

#Ortiz et al. (1999); Enterprise Integration&mdash;Business Processes Integrated Management: a proposal for a methodology to develop Enterprise Integration Programs, Departamento de Organizacion de Empresas, Technical Uversity of Valencia, Spain, Computers in Industry 40, 155&ndash;171.

#Silva, M. and Valette, R. (1989); Petri nets and Flexible manufacturing. Lecture Notes on Computer Science, 424, 374&ndash;417.

#Zhu et al. (2004); Model-driven business process integration and management: A case study with the Bank SinoPac regional service platform, IBM Corporation, Res. & Dev. Vol. 48 No. 5/6.

#Aguiar, M. (1995); Executing Manufacturing Models of Open Systems, Ph.D. Thesis, Loughborough University.

#Eriksson & Penker (1998); UML Toolkit, Wiley, New York.