Content deleted Content added
No edit summary |
|||
Line 27:
The development of a Functional Software Architecture 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” 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.
[[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.
Line 52:
**[[#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.
Line 62 ⟶ 63:
'''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 flow 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 Nets are known tools to model manufacturing systems [
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 [
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 [
===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 [
===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 2 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:
Line 93 ⟶ 109:
'''Figure
Line 102 ⟶ 118:
==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.
**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.
[[Image:meta-FSA.PNG]]
'''Figure 5: Meta model of a FSA'''
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.
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.
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.
----
Line 108 ⟶ 142:
==References==
▲[2] Zakarian & Kusiak; Process analysis and reengineering: Departement of Industrial Engineering, University of Iowa, USA, Computers & Industrial Engineering 41, 135-150
▲[3] Beekman, (1989); European Committee for Standardization, ECN TC310 WG1, 1994
▲[4] U.S. Airforce (1981); ICAM architecture part 1, Ohio, Air Force Materials Laboratory, Wright-Patterson
▲[5] Peterson J.L. (1981); Petri net theory and the modelling of systems, Englewood Cliffs, N.J., Prentice Hall
▲[6] Marshall, C. (2000); Enterprise Modelling with UML, ISBN 0-201-43313-3, Addison-Wesley, MA
#Ortiz et al. (1999); Enterprise Integration—Business Processes Integrated Management: a proposal for a methodology to develop Enterprise Integration Programs, Departamento de Organizacion de Empresas, UniÍersidad Politecnica de Valencia, Spain, Computers in Industry 40, 155-171
▲[7] Vernadat F.B.; A vision for future work of the task force (IFAC-IFIP)
| |||