Modelling involves system analysis of enterprise architectures that ... Various types of dependencies that specify the enterprise architecture types (www.cio.gov).
Enterprise Modelling of Component Oriented Information System Architectures Remigijus GUSTAS, Lars JAKOBSSON Department of Information Systems Karlstad University, 651 88 Karlstad, Sweden Abstract. The term of Enterprise Architecture (EA) has been used for many years within the information system engineering community. There are two basic challenges facing the enterprise engineering process: enterprise modelling and integration. Modelling involves system analysis of enterprise architectures that define strategic, organisational and technical system views. Many companies have been building information systems for many years, but just few of them have actually understood interdependencies between various architecture types. Even such de facto software industry standard as UML has many inherent weaknesses as far as semantic integrity of various diagrams is concerned. To obtain value from various documents on EA, they must be integrated. Since complexity of diagrams is high, the developers usually rely on a common repository of enterprise engineering tools. The problem is that existence of a common repository does not guarantee consistency and integrity of various enterprise representations. Traditional methods of information system analysis and design are not putting into foreground some important interdependencies that are crucial to glue the organisational and technical system descriptions. Such tradition tends to draw attention away from the semantic modelling aspects and concentrates on the implementation dependent issues. In this paper, we are using a component-oriented way for defining EA. We will demonstrate not only the benefits of component orientation, but also how UML can be empowered by the enterprise modelling.
1. Introduction Various types of dependencies that specify the enterprise architecture types (www.cio.gov) are typically analysed in isolation. This often results in wasting huge financial resources for technical system development without a significant impact. One of the main problems is a lack of a well-defined interplay among various EA artefacts. The enterprise engineering quality is essential for understanding of the organisational and technical system fitness. Nevertheless, very little is known on how the enterprise modelling quality problems are identified and resolved. The current enterprise modelling tools such as System Architect (www.popkin.org), Metis (www.computas.com), and Microsoft Visio are great visualisation software, but still it has little support in the systematic integration of enterprise architectures. Discontinuities [1] between the technical system and organisational system part cannot be identified without a complete understanding of an overall business process. A long list of failures in information system development demonstrates that in many cases a holistic view of the enterprise architecture is not available. Enterprise engineering deals with collaborative information system modelling across organisational and technical boundaries. It can be viewed as an extension and generalisation
of the system analysis and design phase. Thus, enterprise modelling and integration [2] should take place during the early, middle and late information system development life cycle. A blueprint of the enterprise infrastructure provides a basis for the organization’s information technology planning. It is referred to as enterprise architecture [1]. There is no way to study the fitness of the organizational and technical process without taking into account architecture of the existing system prior to designing a new one. The condition, under which an information system developer knows what information is needed for the user [3], is when he has a complete understanding of how an overall system is functioning. Traditional methods of information system analysis and design are based on static and dynamic conceptual views, which are represented by different types of diagrams. Although there is a great power of traditional approaches, there is also a deep fallacy in this orientation. The semantic diagrams of traditional methods usually are used to present system development static and dynamic solutions in isolation, that is, they do not take into account interdependencies among various types of diagrams. Object-oriented approaches, which are often used in the area of enterprise modelling, do not consider the strategic dependencies [4] among various organisational actors involved. That is why integration of collaboratively defined conceptual views is difficult or impossible. One of the major reasons for constant failures in the area of information system is a communication gap between the management and IT development personnel. Many software maintenance problems arise because every enterprise has to survive a systematic change when new software is introduced. If the initial software requirements are presented without taking into consideration a context of the organisation, then the requirements engineering approach can not be considered as viable, because it is not able to address various issues of software quality, for instance such as IT usage or fitness. Without complete understanding of organisational architecture, stakeholders have no criteria for determining the irrelevance or ambiguity of the enterprise information system flows. That is why users frequently are misunderstood or they are supplied with ambiguous, incomplete and inconsistent solutions. Misunderstanding between information system users and designers is a common problem. A precondition for a successful concurrent engineering process is a mutual understanding. It cannot be achieved without close cooperation of the actors involved. One of the problems in most conventional system engineering approaches is that it is impossible to bridge from the technical system specifications to the organisational system requirements. The enterprise modelling [5] and integration can be used as a possible solution to the problem. This paper is organised as follows. In the next section, the enterprise modelling idea is shortly introduced. The third section defines interplay between the basic semantic and strategic dependencies. The forth section presents object-oriented extensions for the enterprise modelling approach. The last section concludes this paper and outlines the perspective of component-oriented enterprise modelling. 2. Enterprise Architecture The term of Enterprise Architecture has been used for many years within the information system engineering community. It refers to various types of graphical representations that define how business, data, technology and software application structures [6] are perceived from different points of view. The concept of enterprise in the context of information system development sometimes denotes a limited area of activity in organization [7] that is of interest by a planner, owner, designer or builder [1]. In the Nineties, the term of architecture started to be used even by business managers, especially those involved in business process re-engineering, to refer to the graphical descriptions of organizational
business processes. Today, enterprise architecture or enterprise modelling can be used to denote a comprehensive graphical description of the semantic relationships across organizational and technical system boundaries. For instance, when managers are talking about the alignment of information technology (IT) systems and applications with respect to business processes, they define graphical enterprise models, which demonstrate how the alignment should be achieved. All US Government agencies are required by law to maintain enterprise architectures because of congressional legislation [8, 9]. There are many different modelling approaches for description of enterprise architectures. The Zachman framework [1] can be considered as a comprehensive guide of documents or blueprints that comprise the enterprise architecture. Typically, it is defined in various perspectives such as the "what", "who", "where", "when" and "how". The matrix of various types of enterprise architecture representations is shown in Table 1. Table 1. Enterprise architecture representation matrix Data (What) Planner view Owner view Designer view
Builder view Subcontractor view Functioning System
Function Network (How) (Where)
List of organizational units Entity Business Diagram Organisation relationProcess of logistic decompoship diagram network sition chart diagram with roles Logical Software Distribute Human Data Arch- applicatio d system interface itecture n architectu architecture architec- re ture Physical Deploy- Techno- Presentation/ Data ment logy Layout structure architec- architec- architure ture tecture Data Process Network Interface definition design architectu architecture re Data Compo- Network Organisation nents List of concepts
List of List of processes locations
People (Who)
Time (When) List of business events Schedule charts
Motivation (Why) List of business goals Business Strategy / Plan
Control structure
Constraints and rules
Component control structure
Rule design
Timing definitions
Rule specification Strategy
Schedule
An integrated representation of the organisational and technical system is necessary to develop a holistic understanding and to plan orderly transitional processes from the current to the target enterprise architecture. There are two basic challenges facing the overall enterprise engineering process: enterprise modelling and integration [2]. To obtain value from the graphical representations that are used in organisations by different groups of people, these documents must be integrated. The developers of enterprise engineering tools usually rely on a common repository. The key problem is that existence of a common repository does not guarantee consistency and integrity of various enterprise representations. Many companies have been building information systems for many years, but just few of them have actually understood interdependencies among various diagrams that define distinct architecture types. Quite often enterprise architects have no complete agreement on the basic relationships that should be represented in various documents. This often results in wasting huge financial resources for technical system development without
a significant impact. One of the major reasons of such failures is a communication gap between the management and IT development personnel. The traditional information system analysis and design methods are not working well enough for the achievement of that purpose. The Unified Modelling Language (UML) is intended for requirements engineering and information system modelling [10]. It provides twelve standard diagram types to analyse a technical system solution. Nevertheless, the current UML foundation has some inherent integrity problems of static and behavioural aspects. Another weakness of UML is its focus on the technical system part, not on organisational system or strategic description. The underlying modelling foundation of conventional information system modelling approaches is too weak to achieve integrity and to manage evolution of enterprise architectures. Enterprise engineering in the context of information systems is dealing with modelling and integration of various strategic, organisational and technical development aspects. At the same time, it is viewed as an extension and generalisation of the traditional system analysis and design phase. Thus, enterprise modelling and integration is taking into account the early, middle and late information system life cycle. It should be noted that enterprise modelling could be viewed as three dimensions of requirements engineering [11]. The agreement dimension based on the basic strategic decisions and enterprise evolution processes, the representation dimension is based on the essential semantic aspects of system analysis and the specification dimension – on the implementation oriented system development aspects. The most difficult part of enterprise modelling is arriving at a coherent, complete and consistent graphical description of a new organisational and technical system. The ability to describe essential system solutions in a clear and sufficiently rich way is acknowledged as crucial in many areas including software requirements engineering, conceptual modelling, database design, business process modelling, ontology integration, knowledge representation and information system engineering. Small changes in the organisational infrastructure sometimes take place so fast that software system components tend to become obsolete very quickly. One of the major problems of system engineering is that collaborative analysis methods across organisational and technical system boundaries are not available. Three layers of enterprise modelling are necessary for a systematic change management. They are helping to understand why a technical system component is useful and how it fits into the overall organisational system. The most abstract is the strategyoriented business process analysis layer, which sometimes is referred to as pragmatic description. Strategic models are necessary to provide motivation behind new business solutions. The semantic layer must have a capacity to describe the static and dynamic structures of business processes across organisational and technical system boundaries clearly [5]. The syntactic layer should define implementation-oriented details [12]. Most software methodologies are heavily centred on the implementation layer. The pragmatic layer is supposed to give a definition of the "why" - a long-term intention or a vision of the enterprise under development. A pragmatic description motivates various enterprise components at the semantic level. Sometimes, desired software components [13] can be easily described before the goals and the development process are well understood. Elaboration of the pragmatics is then done backwards, by asking for the reason for existence of the introduced components. In this paper, we will mainly concentrate on the interdependencies between the semantic and syntactic layers.
3. Semantic Dependencies in the Enterprise Modelling Approach The ability to describe information systems in a clear and sufficiently rich way is acknowledged as crucial in many areas including information system and software engineering. Typically, semantic dependencies are defining semantics in different perspectives such as the "what", "who", "where", "when" and "how" [1]. For instance, in the object oriented approach [14] the "what" perspective is defined by using the class diagram, the "how" perspective can be defined by using the activity diagrams and the "when" perspective in a large part can be described by the state – transition diagrams. The semantic models are critical for bridging a gap between various kinds of people such as information technology planners, business owners, system designers, builders, users, and programmers. Understanding the strategic dependencies [4] is essential for reaching a consensus on how the current and future situation looks like. The dependencies between various technical and organisational components involved describe the "who" perspective. A strategic dependency link between two actors (agent and recipient) indicates that one actor depends on another actor. An instance of actor can be an individual, a group of people, an organisation, a machine, a software component, an information system, etc. The dependent ). The actor actors in a diagram can be related by the actor dependency link ( dependency is usually seen as a physical, information or a decision flow between two participants of a business process. Graphical notation of the actor dependency between an agent and a recipient is presented in Fig. 1.
Fig. 1. The Flow dependency
An agent initiates a communication flow to achieve his goal. If an actor B is dependent on A on some flow, then such dependency is represented as A B. If actor B is dependent on A for a flow F, then this is called a flow dependency. This is specified by the expression: A (F) B. The flow dependency represents a communication channel for transferring of information or physical flow between agent and recipient. A typical action workflow loop [15, 16] includes two communication flows sent into opposite directions. An agent is an actor who initiates the workflow loop to achieve his goal. A recipient of a communication flow can be viewed as an agent in the next communication action. Actor dependencies in two opposite directions imply that certain contractual relationships are established. Let us take an illustration of a tiny information system that is composed of a user, a scheduler and an alarm clock. It is graphically represented in Fig. 2. Event
Scheduler
Event Time
User
Alarm Clock Displayed Event
Scheduler
Deletion Event
Fig. 2. Illustration of two action-workflow loops
The organizational system part consists of a user and the technical - consists of a scheduler and an alarm clock. The task of the technical components is to provide an eventscheduling device to a user. A user may enter several events, which are queued in the Scheduler. If the User provides the technical system part with an Event, then he is reminded with the Displayed Event later:
if User (Event) Scheduler then Scheduler (Displayed Event) User. The Scheduler is responsible of setting the Event Time in the Alarm Clock, which is obliged to trigger a Removal Event in case an Event Time hits alarm time, i.e. if Scheduler (Event Time) Alarm Clock then Alarm Clock (Deletion Event) Scheduler. Any flow dependency at the semantic level should be described in more detail using a communicative action. Therefore, the actor dependency is considered to be an action and a communication flow [17, 18]. Cohesion of action and communication flow at the semantic modelling level results in a more complex abstraction, which is referred to as a communicative action [21]. An ellipse represents actions. Fig. 3 shows graphical notations of dynamic constituents in the extended communication flow and action dependency.
Fig. 3. Graphical notation of the dynamic dependencies
State dependencies define semantic relationships between states of actions. They are normally considered as the "how" perspective. Both state transition and communication dependencies describe a very important part of knowledge about business processes. Unfortunately, many communication-based approaches often neglect some behavioural aspects of the state transition and vice versa, many software engineering approaches disregard the dependencies of communication. The static concept dependencies define the "what" perspective. These dependencies are stemming from various semantic models that are introduced in the area of information system analysis and design [14]. Graphical notations of static dependencies are represented in Fig. 4.
Fig. 4. Graphical notation of the static dependencies
It should be noted that in the enterprise modelling, alike in object-oriented methods, all kind of the static and dynamic dependency links could be inherited [17]. We shall refine the illustrated action workflow loops [15] between the three actors (user, scheduler and alarm clock) by using the presented set of semantic dependencies. A user initiates the ‘Schedule New Event’ action by entering an Event. The Scheduler will
accept the event, if the precondition “Event Time > Current Time” is met. The Event is composed of ‘Scheduled Time’ and Description (see the inheritance link in Fig. 5). Schedule New Event
Scheduler
Event Time
Event Time EventTime CurrentTime
Date
Event List
User
Time
Hour
Set New Event Time
Minute Event NOT First
First Event Time
Scheduled Time First
NOT First
Displayed Event
EventTime = CurrentTime
EventTime < > CurrentTime
Description
Display Event
Scheduler
Delete Event
Alarm Clock
Fig. 5. Graphical Description of the Semantic Dependencies
‘Scheduled Time’ consists of Date, Hour and Minute, which can be derived from the fact that ‘Scheduled Time’ inherits Time together with its structure. This means that the action ‘Schedule New Event’ is creating an Event object, which is composed of Date, Hour, Minute and Description. Since Event is a compositional part of ‘Event List’, the Event List object must be created and it will cease to exist when the last event is deleted. The ‘Event List’ must be linked to exactly one object of Scheduler. Existence of the ‘First Scheduled Time’ object is a precondition of the ‘Set New Event Time’ action in the Alarm Clock. The Scheduler can initiate this action. Fig. 5 graphically represents the overall semantic description. A scheduler is capable to send an Event Time flow to an Alarm Clock, if a previously defined precondition is met in the Scheduler’s ‘Event List’. If the action ‘Set New Alarm Time’ is successful, then the ‘First Scheduled Time’ will become an ‘Event Time’ in the Alarm Clock. Provided the ‘Event Time’ matches the Current Time, the Alarm Clock invokes a communication action ‘Delete Event’ in the Scheduler. It is supposed to delete the ‘Event Time’ together with the Alarm Clock itself (since it is composed of Event Time). The Display Event action consists at least of two parts. The first part, deletes a First Event in the Scheduler’s Event List together with its Description, Date, Minute and Hour. The second part shows a Displayed Event to the User. If there is no new ‘First Event’, i.e. the Event List contains only one event, the overall ‘Event List’ must be deleted at the same time. Since the Displayed Event flow is connected by the inheritance link to Event, it indicates that the data format represented to User is the same as the data structure that was in the input of ‘Schedule New Event’ action. Combination of the presented semantic dependencies with the specific implementation details, make it possible to describe various syntactic and semantic aspects of a system using the same diagram type. This means that it is quite easy to keep track of ambiguities and inconsistencies in the model and to analyze the potential information system problems before actually starting to implement it. Recent studies indicate that it is more confusing for the system developer as well as for the user to switch between different diagram types than keeping everything in one larger, well-organized model with the possibility to zoom in and out into the single diagram to integrate more specific and more abstract views [19].
4. Accommodating Component Based Thinking in the Enterprise Modelling Approach Although the notion of software components is not new, the use of software components in software development has not been a feasible way to improve the development process until recently, since a systematic component-based approach is needed to achieve this [20]. Various UML diagram types can be used to describe software components. Some of them, such as the use case diagram are not object-oriented, and it is useful only to describe a system on a very high level of abstraction. Designers, to describe system architecture at the implementation dependent level of abstraction extensively, use the other diagram types, such as the class, state transition, sequence and activity diagram. All of these diagrams are employing some set of graphical symbols and rules. Some of the concepts can be represented in various diagrams by using different symbols with slight semantic differences. This means that there is no complete agreement on how integrity and consistency of various diagrams can be controlled. We believe that using the enterprise modelling approach is one possible solution to this problem. In this chapter, we will examine how the semantic representations that were used in the enterprise-modelling phase can be extended by the implementation dependent details of software architecture. We will demonstrate the synergy that can be reached by combining two modelling techniques, by utilising the strengths in both worlds to reach a better understanding between stakeholders at different stages in the development process. There are of course drawbacks in any modelling technique, since a model is an abstraction, but we believe that by combining the strong parts of UML and enterprise modelling respectively we can reach a modelling technique combination which does not suffer from the shortcomings present in the modelling techniques separately [21]. The enterprise modelling approach will make it possible to use one diagram type to describe semantics of the entire system. Since UML is a de facto industry standard, the enterprise models are used in combination with corresponding UML diagrams. The class diagrams are used to describe the static parts of software components and the activity diagrams are used to resolve the dynamic granularity differences between the object oriented diagrams and enterprise models. Some of the diagram types used in UML will not be included in this paper. The reason for this is that the idea of describing the attributes and operations provided by a class using class diagrams are used to enhance the ability in enterprise modelling to cope with software components in a way understandable for designers as well as for programmers. The semantic details are provided by the enterprise modelling technique. Enterprise actors can be regarded as the organizational or technical system components. The organizational system part consists of humans and the technical system – of technical components. Communication flow dependencies among the organizational and technical components together with the actor composition or generalization links are used to define enterprise architecture at various levels of abstraction. In Fig. 6, a set of the syntactic elements of the enterprise modelling technique is shown.
Fig. 6. Few examples of the syntactic elements
Modelling primitives of the syntactic level are CASE tool dependent and therefore they are considered as the implementation perspective. For instance, the enterprise modelling approach, which was specially modified for the Lyee methodology [22, 23], is
built on a different set of syntactic elements. It means that the presented list of symbols is not exhaustive. Other symbols can be added on demand. Since the notion of software component is not used in traditional information system development approaches [10, 14, 24], it requires clarification. There is no complete agreement on what a software component is. Szyperski [25] defines a component as: “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.” Atkinson [26] provides another, similar definition of software component: “The development-time description of a unit of behavior and composition with contractually specified interfaces and context dependencies only. It therefore represents a type from which component instances can be instantiated at runtime.” In our example, there are three actors, one is a human and two other actors will be implemented as software components: the Scheduler and the Alarm Clock. The semantics of these two components are defined in Fig. 5. It should be noted that the diagram is describing just a main course of events. It is not representing contingent flow of events that tell us what will happen, if something goes wrong. The further refinement of the first half of the semantic diagram into the syntactic elements is represented in Fig. 7.
Fig. 7. Representation of Syntactic Elements together with the Semantic Dependencies
The example represents a mixture of details on the semantic and on the syntactic layer. It is quite simple, and straightforward, but still sufficient to illustrate a systematic way in which the component based information system architectures can be defined. One important syntactic difference of the presented diagram compared to pure semantic representation, is that the Scheduler software component and the Scheduler as a class are represented in a different way, because they are two completely different things from the implementation perspective (the same goes for the Alarm Clock). A human (user) initiates the action workflow loop by entering an Event, by using the Schedule New Event action, into the Event Description Form, shown in Fig. 8, (it acts as an interface to the Scheduler from the user’s point of view).
Fig. 8. Screenshot of Event Description Form
If the inherited conditions from the semantic layer are met, the Scheduler must accept an Event from the Event Description Form. If entered time is matching the specified condition, the Event will be stored in the Scheduler, as the semantic structure of Event prescribes it. At the same time, if the precondition “Event Time > Current Time” is met, then the scheduler action ‘Clear Input Screen’ is invoked that prepares the Event Description Form for scheduling of a new event by cleaning up the input boxes. In addition, if entered time is matching the specified condition, a Scheduler component sends an Event Time message to the Alarm Clock component by using the Event Time message layout. If the precondition “Event Time > Current Time” is not met, then a Scheduler will invoke the ‘Advise User’ action, which is displaying the screen layout ‘Event is Not Relevant’ to User. The documentation or the graphical specification of a software component is critical, since it is a well-known fact that undocumented software is difficult to maintain. The fact that software components ideally are supposed to be plugged in to a system with no changes made, makes it imperative to be able to analyze and to prove whether the component fits into the overall system or not, via its documentation. Since software development today is a quite complex activity, there is a need for descriptions of a system at a high level of abstraction, to enable comprehensive analysis of requirements for the entire system. It is imperative that these descriptions are useable all the way through the software development process from initial analysis to actual realization of the system. This means that the descriptions have to be understandable for all interest groups throughout the entire software development process. Adaptation of a component based thinking and motivation of its strength will be illustrated on a basis of the same scheduling system specification. It was first described using the enterprise-modelling approach, and now the same example will be defined using UML. In that way, we are going to demonstrate not only the benefits of component orientation, but also how UML can be empowered by the enterprise modelling. Class diagrams can be used to depict Interface Specification Diagrams, Component Specification Diagrams, Component Architecture Diagrams and Interface Responsibility Diagrams, all of which are used to depict each corresponding static artefact [27]. In the system described in this paper, there are two interesting components to describe using class diagrams. We will examine the class diagram for the Scheduler component. Let us look again at the functionality of the action ‘Schedule New Event’. The semantics of the diagram (see Fig.5 and Fig.7) dictates various connection events in a specific order. The action “Schedule New Event” is creating an Event object, which is composed of Date, Hour, Minute and Description. Since Event is a compositional part of ‘Event List’, a specific Event List object must be created to store an Event. Every Event List must be associated to exactly one object of the Scheduler component. The underlying class diagram of the
Scheduler that is matching the described conceptual structure in Fig. 5 and Fig. 7 is shown in Fig. 9.
Fig. 9. Class Diagram for Scheduler
The presented class diagram dictates a corresponding dynamic structure in the action ‘Schedule New Event’. Since the triggering effect resides outside the technical boundary of Scheduler (the User initiates it), the first operation in the ‘Schedule New Event’ action should be defined in the IScheduler, which is the Scheduler’s interface. As shown in Fig. 9, the operation is called scheduleEvent. The methods in the IScheduler interface are only operations in the Scheduler made visible through the interface. If we examine the attributes of the classes, we can see that they are specified using statements to determine if the attribute is used for input (in), output (out). There are no means of expressing dynamic properties of a class in the class diagram, though the methods of setting and retrieving data are represented using the public methods. The UML activity diagram is usually depicting actions and control conditions. All presented operations shown in Fig. 10 are consistent with the enterprise model actions. The consistency can be verified by matching the actions and the guard conditions with various creation or deletion events that are represented in the enterprise model. Thus, the activity diagram can easily be traced into a more abstract enterprise modelling level. This possibility is of course an advantage, since it is easier to keep track of changes in the model, if one diagram type is used throughout the entire modelling process [19]. The overall scheduling activity, which consists of Clear Input Screen, Schedule New Event and Advise User (see Fig. 7), is depicted in Fig. 10.
Fig. 10. Schedule New Event action together with Advise User and Clear Input Screen actions
The activity diagram shown in Fig. 10 to represent the implementation dependent aspects of the component-based system refines the ‘Schedule New Event’ action shown in Fig. 7. The two additional actions such as Advise User and Clear Input Screen are implemented as atomic operations in the Scheduler class. The interface operation ‘scheduleEvent’ will be overridden by the Scheduler operation with the same name. If the Event condition “EventTime > CurrentTime” is met, then the action “Add Event” will process a corresponding Event List object and ‘Create Event’ operation will create a new Event object. The created Event object is a part of the specific Event List, as shown in Fig. 7. The reason for this solution is that all class data should be encapsulated and only accessible through public access methods as shown in Fig. 9. In this example, it is easy to see how the mapping to the enterprise model can be achieved by comparing the names of the actions in the activity diagram with the names of the actions in the enterprise model shown in both Fig. 5 and Fig. 7. The control conditions such as guards can be traced by finding actions with the same condition state in the enterprise model. The current solution is to represent the static parts of software components using UML as a supplement to the enterprise modelling technique. It has been demonstrated how software component architectures can be represented by using a combination of the enterprise modelling and object oriented approach. In this way, it is possible to use the presented diagrams as a documentation of the software components interactivity [21]. The activity diagrams are used to describe semantic details on how operations are coordinated and synchronized in one software component. Actions of the enterprise modelling approach give an unambiguous description on how use cases unfold. The dependencies between different use cases can be described using communication links among actors involved. Activity diagrams can be used to describe specific operations for actions that are identified during the enterprise-modelling phase. The combination of two different techniques illustrates the strength of combining different modelling techniques to reach a more complete view on a specific activity. The UML component architecture diagram is used to define the interface dependencies between various components. This type of diagram is giving a very general view on component interconnectivity. According to our example in this paper, the corresponding component architecture diagram could be defined as it is shown in Fig. 11.
Fig. 11. Component Architecture Diagram
The interpretation of the diagram is that the Scheduler component offers the IScheduler interface, and uses the IAlarmClock interface. The Alarm Clock component offers the IAlarmClock interface and uses the IScheduler interface. The information contained in this diagram can easily be derived from dependencies contained in the presented diagrams of enterprise modelling approach. Therefore, this diagram is not giving any new knowledge in the enterprise modelling context; nevertheless, it can be viewed as a valuable addition in the context of a component based approach. 5. Concluding remarks and Future Research Change management in the technical information (software) system part is a big challenge. IT architecture should support business processes to be regarded as a value-added technology. The key issue is determination of the true IT needs and how these needs are integrated into the overall organisational system. The ability to describe information system in a clear and sufficiently rich way is acknowledged as crucial in many areas including information system and software engineering. Typically semantic dependencies are defining semantics in different perspectives such as the "what", "who", "where", "when" and "how" [1]. In this paper, we have demonstrated various static and dynamic dependencies can be integrated by using the enterprise modelling approach. Using UML to model software is a de facto industry standard, but there are several drawbacks with using UML when modelling. Firstly, the number of UML diagrams that would be necessary to model the system described in this paper are far too many, and it would be difficult to maintain model integrity in the different diagrams [19]. Secondly, the UML diagrams rapidly grow in size although they only represent small parts, or aspects, of the entire system. Thirdly, there is a possibility to use extension points to use cases to provide a more descriptive use case, but they still represent only the surface semantics [29]. The extensions suggested by Cheesman are enabling the use of software components in a UML modelling activity, but despite his extensions, the main drawbacks remain using only UML to model software components. Using the enterprise modelling approach will make it possible to use one diagram type to describe semantics of the entire system. Of course, it will also rapidly grow in size, since it would be possible, but not very comprehensible, to represent the entire system in a very fine granularity using a single diagram. Therefore, currently enterprise models are used in combination with corresponding UML diagrams (class and activity diagrams in this paper). The class diagrams are used to describe the static parts of software components. Activity diagrams are used to resolve the dynamic granularity differences between the object oriented diagrams and enterprise models. We have demonstrated how the enterprise modelling can be extended with help of the UML diagrams to represent the implementation dependent aspects of a component based software system. The current solution is to represent the static parts of software components using UML as a supplement to the enterprise modelling technique. It is also possible to
show how other software can use a software component, given that the interface requirements are met. Furthermore, it is possible to use the presented diagrams as documentation for building of component oriented information systems. Using the enterprise modelling technique, the benefit is that it is easier to verify that the zooming into diagrams that are more specific from a more general system representation towards the implementation dependent level of models is justified. This fact should also improve consistency when it comes to maintenance and modifications to the system specification. Replacement of the components in the system should also be facilitated by the use of the extended enterprise modelling technique since it is possible to ascertain that new components are compatible to the old components using the combinations of UML and enterprise modelling suggested in this paper. Future research will show how the enterprise modelling technique can be extended based on UML class diagrams. There is a need to be able to describe static dependencies in software components using a more comprehensible technique than what is present in the enterprise modelling approach today. One way to achieve this is to incorporate, for instance, UML class diagrams in the enterprise model itself. Another way of doing this could be to introduce enterprise-modelling concepts based on class diagram semantics. The implementation bias of many information system modelling techniques is a big problem. The same concepts have been applied to the design and analysis stages, without rethinking these concepts fundamentally. Modelling at the semantic level should follow the basic conceptualisation principle [29]. Enterprise modelling and integration should deal with the conceptually relevant aspects and it cannot be influenced by the possible solutions to the problem. Even though these problems were taken into consideration by the more powerful modelling techniques [10, 24], it did not help to control the integrity and consistency of specifications that are presented on different levels of abstraction. Consequently, the quality and reliability of the software development suffers significantly. A starting point of system engineering in the enterprise modelling is implementation independent. A component-based enterprise engineering approach was introduced for representation of information system architectures across technical and organisational boundaries. We are aiming at the extended enterprise modelling approach with an engineering process that is similar to what architects use when constructing buildings. The graphical models are used for visualising and reasoning about the semantic integrity and consistency of information system at the implementation dependent level of abstraction. The separation between the semantic and syntactic - implementation based aspects leads to a natural division of enterprise engineering products. It is more reasonable to conceptualise enterprise architecture and business processes before supporting software system is defined. On the other hand, it is not useful to model the real world having no functionality in mind. Hence, the syntactic layer of models contributes to the extended methodology of enterprisewide engineering technique. References [1] [2] [3] [4]
Zachman, J. A. (1996) “Enterprise Architecture: The Issue of the Century”, Database Programming and Design Magazine. François B. Vernadat, Enterprise Modeling and Integration: principles and applications, Chapman & Hall, 1996. Ackoff, R. L. (1989) "From Data to Wisdom: Presidential Address to ISGSR, June 1988", Journal of Applied System Analysis, Vol. 16, 3-9. Yu, E. & Mylopoulos, J. (1994) ”From E-R to ' A-R'- Modelling Strategic Actor Relationships for Business Process Reengineering”, 13th International Conference on the Entity - Relationship Approach, Manchester, U.K.
[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
Gustas, R., Gustiene, P., (2003) Towards the Enterprise Engineering Approach for Information System Modelling across Organisational and Technical Boundaries, 5-th International Conference on Enterprise Information Systems, Angers, France, April 23-26, 2003, vol.3, 77-88. Spewak, S H (1992), Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology, John Wiley & Sons. Bubenko, J. A. (1993) "Extending the Scope of Information Modelling", Fourth International Workshop on Deductive Approach to Information Systems and Databases, Polytechnical University of Catalonia, 73-97. Raines, F. D. (1997) Memorandum for the Heads of Executive Departments and Agencies, http://www.whitehouse.gov/omb/memoranda/m97-16.html Harmon, P., (2003) Developing an Enterprise Architecture, Business Process Trends (white paper), January, 2003 Booch, G., Rumbaugh, J. & Jacobsson, I. (1999) The Unified Modelling Language User Guide, Addison Wesley Longman, Inc., Massachusetts. Pohl, K. (1993) “The three Dimensions of Requirements Engineering”, International Conference on Advanced Information System Engineering – CAiSE’93, Springer Verlag. Davis, G. B. & Olson, M. (1985) Management Information Systems, McGraw Hill, New York. Christiansson, B., Jakobsson, L., Crnkovic, I., (2002) CBD Process, in Crnkovic, I. & Larsson, M. (eds.) Building Reliable Component-Based Software Systems, Artech House, London. Martin, J., Odell, J. J., Object-Oriented Methods: A Foundation (UML edition), Prentice-Hall, Englewood Cliffs, New Jersey, 1998. Action Technologies, (1993) Action Workflow Analysis Users Guide, Action Technologies. Winograd, T. & Flores, R (1986) Understanding Computers and Cognition: A New Foundation for Design, Ablex Norwood, N.J. Gustas, R., (1998) "Integrated Approach for Modelling of Semantic and Pragmatic Dependencies of Information Systems", Conceptual Modelling - ER' 98, Springer, pp. 121-134. Goldkuhl, G., Information as Action and Communication, in Dahlbom, B. (ed.), The Infological Equation – Essays in Honor of Börje Langefors, Göteborg University, Sweden, pp. 63-79, 1995. Turetken, O., Schuff, D. (2002) The Use of Fisheye View Visualizations in Understanding Business Process, Proceedings of ECIS2002, Gdansk, Poland. Crnkovic, I., Larsson, M., A Case Study: Demands on Component-Based Development, Proc. 22nd Int. Conf. Software Engineering, Limerick, Ireland, ACM Press, 2000. Jakobsson, L., Gustas, R., (2004) Towards a Systematic Modeling of Component Based Architectures, International SSCCII-2004, Amalfi, Italy (accepted). Jakobsson, L., (2002), “Extending Process Route Diagrams for Use with Software Components”, Frontiers in Artificial Intelligence and applications, IOS Press, Amsterdam, pp. 289-300. Gustas, R and Gustiene, P (2002), Extending Lyee Methodology using the Enterprise Modelling Approach, Frontiers in Artificial Intelligence and applications, IOS Press, Amsterdam, pp. 273-288. Yourdon, E. (1989) Modern Structured Analysis, Prentice-Hall, Englewood Cliffs, N.J. Szyperski, C., Component Software – Beyond Object-Oriented Programming, Reading, MA: AddisonWesley, 1998. Atkinson, C. et al., Component-based Product Line Engineering with UML, Addison Wesley, London, 2002. Cheesman, J., Daniels, J., UML Components: A simple Process for Specifying Component Based Software, Addison-Wesley, 2001. Stevens, P., Pooley, R., Using UML – Software Engineering with Objects and Components, Pearson Education Limited, Essex, 2000. Griethuisen, J. J. (1982) Concepts and Terminology for the Conceptual Schema and Information Base, Report ISO TC97/SC5/WG5, No 695.
