Towards a Software Architecture Specification Language based on UML and OCL Andreas Rausch Technische Universität München Institut für Informatik Arcisstrasse 21 80290 Munich, Germany +49 89 289 28362
[email protected] ABSTRACT The development of a system’s software architecture is a very complex and important issue. Existing description and modeling techniques do not fit the requirements of architecture centric system development. In this paper we are proposing the basic concepts and notions of software architectures. Furthermore, we provide a proposal for a new description and modeling technique for software architectures based on UML and OCL. Keywords Software Architecture, Unified Modeling Language, Object Constraint Language, Modeling Techniques. 1 INTRODUCTION Since many years, software designers have the strong feeling that software architecture is an important concept. But this concept is not very well exploited, due to the lack of a suitable overall methodology with respect to the development and evolution of a system’s software architecture. Such a methodology should at least incorporate the following parts: • A common system model provides a well-defined conceptual framework for the basic notions and concepts of systems and their software architectures. • Based on the system model a set of proper description and modeling techniques to represent an architecture are needed. • System and architecture development should be organized according to a software development process. This includes guidelines for the usage of the description techniques as well as reasonable architectural blueprints. • To minimize the costs of software development, systems should be based on standardized architectural blueprints. Such architectures contain a common basic infrastructure for software architectures, like DCOM, CORBA, or Java Enterprise Beans. But even more important are business standard architectures, that are well suited for the customers needs.
• Finally, all former aspects should be supported by tools. In this paper we discuss two of these issues, namely the system model and the description and modeling techniques. The paper is structured as follows. Section 2 provides the basic definitions and notions of software architectures. In the next section, Section 3, we present a small application example to illustrate the presented concepts of software architectures. In Section 4 this application sample serves for the presentation of our new description and modeling techniques for software architectures based on UML and OCL. A short conclusion ends the paper. 2 BASIC CONCEPTS OF ARCHITECTURES Although some models for software architectures exist, we need to improve them for a complete model. Formal models, like for instance Focus or temporal logic, are strongly connected with refinement concepts. Furthermore, these methods do not contain well elaborated description techniques, that are needed to discuss the issues of a software architecture. Moreover, in practice formal methods are not applicable, since formal models are too abstract and do not provide a realistic view on today's software architectures. Architectural description languages, like MILs, Rapide, Aesop, UniCon, are other, less formal approaches. They introduce the concepts of components and communication between them via connectors, but do not consider all behavior-related aspects of an architecture. In an architecture behavior is not limited to the communication between pairs of components, but also includes changes to the overall connection structure, the creation and destruction of instances, and even the introduction of new types at runtime. Other approaches, like pre/post specifications cannot specify mandatory external calls that components must make. This restriction also applies to Meyer's design by contract and the Java Modeling Language (JML), although they are especially targeted to model the software architecture of a system.
For that reason, we elaborated a novel, more realistic model for software architectures (cf. [1]). In this model, the basic building blocks of a system’s software architecture are: • Components • Interfaces provided by components • Connections between interfaces • Attributes at interfaces • Values assigned to the attributes • Messages send to interfaces These instances represent the individual operational units of the software architecture of a certain system. Thus, we have to specify the behavior of those units. Thereby, we separate the behavior of systems into the following three essential parts:
Figure 1: System Vision On the left side of the tool the teacher cards are displayed. They can be placed on the cells of the break plan to the right via drag & drop. Whenever a teacher card is taken from the stack, the status line shows the breaks that can not be supervised by the teacher. It is nevertheless possible to place a card on such a break. Conflicts have to be highlighted in red color. Already placed cards may be replaced via drag & drop. Assignments on the plan that are to be removed must first be selected and are then removed by pressing the `Remove' button. The actual break plan can be printed by pressing the `Print' button. The button `New Plan' clears the complete actual break plan. The second status line shows the supervision duties and the number of already assigned breaks for the actual teacher card.
• Structural behavior captures the changes in the system structure, including the creation or deletion of instances and changes in the connection as well as aggregation structure. • Variable valuations represent the local and global data space of the system. This enables us to model a shared global state. • Component communication describes message-based asynchronous interaction between components. Thus, we can specify mandatory call-backs without problems. We claim, that this model is powerful enough to handle the most difficult aspects of software architectures. For a detailed discussion of this three concepts and a complete formal model we refer to [1].
However, a proper architecture of a break planner system could consist out of the following components, StaffEditor, BreakPlanStatisticView, BreakPlanEditor, StaffOrganizer, BreakPlanOrganizer, as shown in Figure 2.
3 APPLICATION SAMPLE: BREAK PLANNER According to the customer specification, the application scenario is as follows: Teachers have to supervise pupils in the various parts of a school building during the breaks. The assignment of teachers to breaks is specified in the break plan of the respective building part. Each break must be supervised by a teacher, and teachers are assigned to breaks depending on the time they spend for teaching – a full-time teacher has to supervise more breaks than a teacher with only a couple of lessons per week. Teachers can provide the school with time periods during which they can not be assigned to breaks because of other duties.
Staff Manager
«component» StaffEditor «interface» Observer
The intended system supports the persons responsible for maintaining the break plans and the teaching staff data. It allows the user for example to create and to delete break plans, to assign teachers to breaks, and to manage a list of the school's teachers. Additionally, the tool computes some statistical values for plan editors, for example the number of breaks a teacher still needs to be assigned to.
Break Plan Manager
«component» BreakPlanStatisticView «interface» Observer
«component» BreakPlanEditor «interface» Observer
Observer Pattern
«interface» Observable «component» StaffOrganizer
Figure 1 shows a picture of the intended user interface of the break planner application.
«interface» Observable «component» BreakPlanOrganizer
Figure 2: Components of the Break Planner 2
Finally, the last snapshot shows the system at time point t3. The component StaffOrganizer has processed the message. A new subcomponent with the corresponding interface has been created. Via new connection the component is connected to the StaffOrganizer.
Now, assuming the break planner is new installed at a school. Before you can edit the break plans, the staff and the empty break plans have to be created. Herr Maier is responsible for the management of the staff. The management of the break plans is done by Herr Huber. Both start the break planner application at their local computer. Herr Maier uses the StaffEditor to create the staff. Herr Huber explores the functionality of the component BreakPlanStatisticView. Figure 3 shows a possible sequence of snapshots of the break planner application, while Herr Maier and Herr Huber are using the system.
The value of the attribute numberOfFullJobs of the component StaffOrganizer has changed from 0 to 0.5, as the staff contains now a teacher with a half position. Moreover, following the observer pattern, the StaffOrganizer has sent to all other components the update message. Hence these components can show the new value in the next execution step.
The first snapshot shows the two users connected with an interface of the component they are currently using. At time point t1 at the interface of the component StaffEditor the message addTeacherAsNew with the corresponding parameters is added. Herr Maier has send this message to the component via the user interface he is connected with to create a new teacher.
This sample illustrates our understanding of a system’s software architecture. During execution the system consists out of a set of components. These components have interfaces. Via connections interfaces of components are connected to each other. Interfaces contain attributes and understand messages. Attributes have values and interfaces can send via connections messages to other interfaces. 4
A UML AND OCL BASED DESCRIPTION TECHNIQUES Now, the remaining question is, how can we describe and model those software architectures in a proper way. Therefore we propose a new, sophisticated description and modeling technique based on UML and OCL.
transition from t1 to t2 Herr Maier : Staff Manager Herr Huber : Break Plan Manager «message» addTeacherAsNew( newName : String "Herr Sepp", newJobFactor : Real = 0.5) «component» : StaffEditor
«component» : BreakPlanStatisticView
«component» : StaffOrganizer
Herr Maier : Staff Manager
Herr Huber : Break Plan Manager
«component» : StaffEditor
«component» : BreakPlanStatisticView
We use UML stereotypes to describe the basic modeling elements of software architectures, as shown in Figure 4: components, interfaces, connections, attributes, and messages. Additionally, one may specify invariants. Those invariants are similar to messages, with an additional condition. If the condition is true, the invariant has to be executed similar to the execution of a message.
numberOfFullTimeJobs : Real = 0
However, specifying the structure of a system is not enough for a complete model of the architecture. Therefore, we must have to possibility to specify the behavior of the components. As described in Section 2 we have three kinds of behavior to describe. We want to use OCL to specify all of these behavioral aspects. Albeit, OCL is not powerful enough. It lacks the ability to specify the creation and deletion of new instances (components, interfaces and connections) as well as the possibility to specify sending messages to other interfaces. We propose to enhance OCL in a proper way to support these features and add it to the modeling elements to specify the behavior of the calculation of attributes, the behavior of messages, and the behavior of invariants as shown in Figure 5.
«message» addTeacherAsNew( newName : String "Herr Sepp", newJobFactor : Real = 0.5)
Herr Maier : Staff Manager
«component» : StaffOrganizer
Herr Huber : Break Plan Manager
numberOfFullTimeJobs : Real = 0
«component» : StaffEditor
«component» : BreakPlanStatisticView
transition from t2 to t3 «message» update()
«message» update()
«component» : StaffOrganizer numberOfFullTimeJobs : Real = 0.5
«component» Herr Sepp : Teacher
Figure 3: Snapshots of the Break Planner Application In the next snapshot the component StaffEditor has processed this message. Via their connection to the component StaffOrganizer a new message has been created an assigned to the interface of the component StaffOrganizer. 3
«component» StaffOrganizer
«assured»
«assured»
[1,1]
[0,*]
«interface» StaffManager
«interface» Teacher
«message» addNewTeacher(newName : String, newJobFactor : Real)
«attribute» name : String «attribute» JobFactor : Real «attribute» numberNeededDuties : Real «attribute» numberCurrentDuties : Real
«invariant» observableBehavior()
«invariant» observableBehavior()
«attribute» school : String «attribute» numberFullTimeJobs : Real
[1,1] theStaffManager
[1,1]
[0,*]
theStaffManager «connection» teachersOfStaffManager
teachers
«connection» breakPlanManagerOfStaffManager
«connection» supervisedBreaks
theBreakPlanManager [1,1]
duties [0,*]
«interface» BreakPlanManager
«interface» Break
«attribute» numberBreaks : Integer [1,1]
[0,*]
«assured»
«assured»
«component» BreakPlanOrganizer
Figure 4: UML and OCL based Description Technique
«interface» StaffManager «attribute» school : String «attribute» numberFullTimeJobs : Real «calculated by» result := self.teachers.iterate(t : Teacher; sum : Real := 0 | sum := sum + t.jobFactor); «message» addNewTeacher(newName : String, newJobFactor : Real) «behavior description» newTeacher : Teacher := NEW Teacher ASSIGNED TO self.assignedComponent; newTeachersOfStaffManager : teachersOfStaffManager := NEW teachersOfStaffManager BETWEEN newTeacher AND self; newTeacher.name := newName; newTeacher.jobFactor := newJobFactor;
«invariant» observableBehavior() «invariant condition» self.numberFullTimeJobs
[email protected] «behavior description» self.observers.forAll(observer : Observer | observer.update());
Figure 5: Enhance OCL to Describe Behavior 4
5 CONCLUSION AND FUTURE WORK In this paper we have shown a first, simple system model to provide a clear understanding of software architectures. A proposal for a new description and modeling techniques based on UML and OCL has been provided. The system model as well as the description technique are powerful enough to model the basic aspects of a system’s software architecture. A number of additional issues remain items of future work: We have to enhance the model to and the description technique to enable the user to specify hierarchical systems. Thus, once the architecture of a system is modeled, the system itself can be reused as a component in the architecture of a larger system. Additionally, we have to provide a complete development example from practice. Finally, we have to develop tool support for modeling software architectures based on these description techniques and generate first, complete prototypes out of the software architecture model. REFERENCES 1. Rausch, A. Software Evolution in Componentware Using Requirements/Assurances Contracts. In Proceedings of the 22th International Conference on Software Engineering. 2000.
5
6
