Content deleted Content added
{{uncat}} |
m Date the maintenance tags using AWB |
||
Line 1:
{{cleanup-date|September 2005}}
A '''Functional Software Architecture''' (FSA) is an architectural model that identifies [[
When an integrated software system needs to be developed and implemented normally a number of tasks and corresponding responsibilities can be divided:
Line 7:
##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 the 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 understand by multiple actors.
Line 20 ⟶ 19:
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.
==Development of a FSA==
Line 30 ⟶ 28:
'''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;
Line 48 ⟶ 44:
**[[#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===
Line 59 ⟶ 53:
'''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.
Line 70 ⟶ 63:
**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.
<!-- Unsourced image removed: [[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.
Line 84 ⟶ 75:
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 through 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===
Line 101 ⟶ 91:
<!-- 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.
Line 116 ⟶ 104:
**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.
Line 123 ⟶ 110:
'''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.
Line 145 ⟶ 131:
#Eriksson & Penker (1998); UML Toolkit, Wiley, New York.
{{uncategorized|November 2006}}
| |||