Integrating UML and SOFL for Object-Oriented Design

Transcription

1 Integrating UML and SOFL for Object-Oriented Design Shaoying Liu Department of Computer Science Hosei University, Tokyo, Japan Abstract This paper presents a decompositional approach to object-oriented design of software systems using a notation resulting from combination of UML (Unified Modeling Language) and SOFL (Structured Objectoriented Formal Language). We demonstrate, by examples and a case study, that the top-down principle used in conventional Structured Design can be effectively utilized to carry out object-oriented design that is usually seen as a way to suit bottom-up analysis and design. Furthermore, we also exhibit a way to combine UML and SOFL for the improvement of the preciseness and understandability of design documentations. 1 Introduction Object-Oriented Design (OOD) is an approach to designing software systems by defining individual objects and their relations [3]. Conventionally this approach is recognized as an effective way to support bottom-up design rather than top-down design, since OOD does not formalize and elaborate object decomposition. A well-known weakness of OOD is the lack of an effective way to identify necessary objects, including their attributes and s. On the other hand, the top-down approach is intuitive in communication with customers and users, and effective in limiting and reducing the complexity of systems for the designer to deal with them easily. However, compared with OOD, the top-down approach is unlikely to lead to a better structure and quality of code for This work is supported by the Ministry of Education, Culture, Sports, Science, and Technology of Japan under Grantin-Aid for Scientific Research on Priority Areas (No ) and Grant-in-Aid for Scientific Research B (No ) and C (No ). system maintenance, because it usually ends up with a structure that contains global variables and has poor reusability. Through our several projects on the integration of structured s, object-oriented s, and formal s to develop the formal engineering SOFL (Structured Object-oriented Formal Language) over last 10 years [6][7], we have found that object-oriented s do not necessarily need conducting in a bottom-up manner. Instead, a decompositional, top-down approach may be effective in helping identify necessary objects and achieving good quality of ultimate programs. And it may also reduce the weakness of object-oriented approach being less intuitive in requirements analysis and design. The key point is how to perceive the building of a software system as a process to achieve a collection of objects in a decompositional manner. In this paper, we propose a specific approach to combine UML and SOFL to support OOD in a decompositional manner. The essential idea of the decompositional objectoriented design approach lies in the way of understanding objects for building systems. A system is built by a giant object, the top level object, which is supposed to provide required functionality of the system, each offering a service. In order to complete its tasks, the top-level object may organize several other objects, as its parts, in a way that they all cooperate with each other to complete the allocated tasks. Each object of these objects may again organize other necessary objects to fulfill its tasks. This process goes on until the bottom-level objects are well designed. Such a way allows the designer to take care of the structure of objects and to think in a decompositional fashion. The reminder of this paper is organized as follows. Section 2 describes the essential idea of the object-oriented design in a top-down manner, while section 3 explains the approach to combining UML

2 Object_2 Object_5 Task_2 Task_5 Task_1 Task_3 Task_6 Object_1 O bject_3 Task_4 Object_6 Object_4 Figure 1. An illustration of the top-down approach to Object-Oriented Design and SOFL and the resulting notation for representing top-down object-oriented designs. Section 4 presents a small case study of using the principle and notation to model a real system. In section 5 we describe the related work, and finally in section 6 we give conclusions and outline the future research. The underlying idea of our approach is to treat an object as an entity to perform a single or set of functions (or tasks or operations). An OOD starts with the design of the top level object that fulfills the top level functions of the system under construction. In order to provide the top level functions, the top level object decomposes the functions into several sub-functions, and organize component objects to take care of those sub-functions. If necessary, some of the component objects again decompose their functions into the next lower level sub-functions for the lower level component objects. This process goes on until there is no need for further decomposition of functions. The important point of the top-down process is that the creation of the levels of the design is driven by functional decomposition, in parallel with object decomposition. That is, when decomposing a function into sub-functions, the object performing the function also needs to be decomposed into component objects to perform the sub-functions. This process is depicted in Figure 1. To represent the design created by taking such a decompositional approach, we need a proper graphical notation that allows to describe individual objects, their decompositions, and their interactions. We also need a textual formal notation to define attributes and s of objects precisely. Such an integrated notation can be achieved by combining UML and SOFL. The advantage of the integrated notation consists in the use of graphical notation for overall structure of the design while the detailed definitions of attributes and s of objects can be given precisely and concisely in association with the graphical notation. Furthermore, since interactions between objects are represented with data flows rather than message exchanges, the design documentation is easy to understand, probably by both the client and the user, and will provide freedom for efficient coding. While UML has been rather well-known, SOFL may be unfamiliar to many people, especially to those who are not working in the area of formal engineering s for software development. However, for the sake of space, we cannot give an introduction to SOFL. The details of SOFL can be found in our previous publications [6][6][7]. 3 Integrating UML and SOFL 2 The Underlying Idea for Integration For our purpose in this paper there is no need to use the whole UML notation and the entire SOFL notation; we only focus on the integration of the class diagram and composition diagram of UML and CDFD and the class structure of SOFL. Note that the reader is not expected to understand the integrated notation in either the context of UML or SOFL, because any integration of two different notations would more or less change the meaning or use of the notations. 3.1 Fundamental Idea The fundamental idea of combining UML and SOFL is described as follows. Each process in a CDFD is replaced by an object of a class, because an object is supposed to provide a set of functional services. Data flows between objects represent communications between them. Objects occurring in the same CDFD can be instances of the same classes or different classes. The decomposition of an object shows all the component objects related with each other using data flows. Since data stores are represented by state variables, they are only attached to the lowest level objects. To provide detailed, precise definitions of objects, each class of objects is defined using the same textual notation as used in SOFL. Note that CDFD in the integrated notation plays the same role as that of the collaboration diagram in UML, but they are different in the way of their

3 x_1 x_2 x_1 x_2 x A1: CA1 q_2 A: CA q_1 (a) s_2 m_2 (b) s_1 m_1 A3: CA3 y_1 y_2 A2: CA2 B1: CB1 q_1 B2: CB2 s_3 d_2 s_4 m_3 m_5 m_4 (c) Figure 2. An illustration of integrating UML and SOFL connections: the connections of objects in a CDFD are represented by data flows rather than message sending and receiving used in the collaboration diagrams, although eventually they will be implemented by message sending and receiving in the lowest level objects. Figure2showstheideaofintegrationofUMLand SOFL. The top level CDFD contains only one object A whose class is CA. The object takes input x and generates output y_1 and/or y_2. Whether the relationship between the two outputs y_1 and y_2 is and or or is undecided until the corresponding s of object A is defined in its corresponding class CA, if the definition is required, or one of its component classes (this point will be explained in detail a little later). Object A is then decomposed into three component objects: A1, A2, and A3, for the sake of functional decomposition, where the corresponding classes of these objects are CA1, CA2, and CA3, respectively. Since the functionality that needs to be provided by object A must be provided by its component objects, the input of object A must be used as input of some component objects, and likewise for its outputs. However, we also allow a data flow of a high level object to be decomposed into concrete data flows of its component objects, in order to support data abstraction and decomposition during object decomposition. For example, input data flow x of A is decomposed into the two data flows: x_1 and x_2, both being the input data flows of object A1. While the output data flows y_1 and y_2 of A are used without change by component objects A2 and y_2 y_1 q_2 A3, respectively. Since object A is decomposed into component objects, it exists only as a conception during the design process rather than being expected to be an object in the final program. For this reason, there is no need to define attributes and s in the corresponding class of the object. However, this way is only based on syntactical consideration. Semantically, those attributes and s may be necessary in order to deal with input x and produce outputs y_1 and y_2, but since object A will be replaced, functionally, by its component objects, all of those attributes and s will be allocated to its component objects properly ( not necessarily concentrated on a single component object; maybe they are shared, in terms of their definitions, by several component objects). The component objects of A may be decomposed again into their component objects communicating with each other using data flows. For example, the component object A1 of A is decomposed into objects B1 and B2, which are connected by data flows to form a CDFD at the next lower level. All objects with no component objects in a hierarchical CDFDs are known as the lowest level objects. For example, objects A2, A3, B1, and B2 in the hierarchical CDFD of Figure 2 are all the lowest level objects. In fact, the hierarchy of CDFDs is equivalent to a flat CDFD that contains only all the lowest level objects; such a CDFD is derived by replacing all the composite objects with their CDFDs. For instance, we take a bottom-up approach to flatten the hierarchyofcdfdsgiveninfigure2byreplacingobject A1 with CDFD (c) and then object A with CDFD (b) (in fact, with the CDFD resulting from substituting CDFD (c) for object A1 in CDFD (b)). As a result, the CDFD given in Figure 3 is derived. Note that although this CDFD looks different from the one in Figure 2, semantically they provide the same functionality. These two diagrams play complementary role in design: while the hierarchical CDFDs assist well the design process itself, the flat CDFD derived from the hierarchy serves as a guideline for defining classes of the objects involved with the formal notation of SOFL. Now the problem of how to write precise definitions of attributes and s of each lowest level object still remains unaddressed. Without well-presented definitions, the entire specification represented by the diagram may not be accurately and precisely understood. To deal with this problem, we have adopted the SOFL class structure to define the corresponding class of each lowest level object occurring in the flat

4 x_1 s_3 x_2 m_3 m_4 q_1 B1: CB1 B2: CB2 d_2 s_4 m_5 (b) s_1 m_1 q_2 A2: CA2 y_1 A3: CA3 s_2 m_2 Figure 3. An equivalent CDFD containing only the lowest level objects CDFD of the hierarchical CDFDs. Taking the CDFD in Figure 3 as an example, we define the classes CA2, CA3, CB1, and CB2 of the objects A2, A3, B1, and B2, respectively. For brevity, we only show two classes CA2 and CB1, exhibiting the most important features of the approach, and present the definition of class CA2 in detail while leave CB1 abstract. class CA2; var s_1: int; /* a variable of integer */ Init() pre true post s_1 = 0 end_; ext pre post end_ end_class; y_2 m_1(q_1: int) y_1:int wr s_1 true s_1 = ~s_1 + q_1 and 2*s_1=y_1 class CB1; var indicates that Student is a class name.*/ post end_ ext explicit end_;... end_ end_class Init() s_3 = new Student and A2 = new CA2 and B2 = new CB2 m_3(x_1: Type_2) q_1: Type_3 wr s_3 wr A2 wr B2 begin s_3.setname(x_1); q_1:= s_3.getage; end m_4(x_2: Type_4) d_2: Type_5 This example exposes several important issues in defining the classes. Firstly, each class has only one constructor, named Init. It needs to be defined in the class, although it is not listed in the graphical symbolinthecdfd.infact,thegraphicalsymbolof an object is designed only to symbolize the object by showing its name and the corresponding class name, as well as the most featured components (attributes and/or s). Secondly, if a does not deal with invocation of other objects, like m_1 in class CA2, it can be defined by pre and postconditions, because pre and postconditions are suitable for defining concisely one-step change of the state variable like s_1, which suits variables of basic types, such as naturals, integers, and real numbers. However, if a has to involve invocations in its definition, like m_3 in class CB1, anexplicit specification must be used for its definition, for it allows descriptions of a series changes of the state. For example, the explicit specification of m_3 is composed of a block statement: begin... end, which contains a sequence of the two statements: s_3.setname(x_1) and q_1:= s_3.getage. The first statement invokes the setname of object s_3,

5 a state variable, and the second is an assignment, involving the invocation: s_3.getage. Thirdly, if an object, like B1, has an output data flow going to other objects, like A2 and B2, the links to those objects need to be reflected in the class of the object (e.g., B1) by declaring the related objects (e.g., A2 and B2) as its attribute variables. Thus, their related s can be invoked in some s of object B1 to fulfill appropriate tasks. As shown in the above example, m_3 may invoke some s of objects A2 and B2 in its explicit specification. Finally, the relationship between different input data flows of an object in the diagram, like x_1 and x_2 of object B1 in Figure 3, must be precisely determined. For example, input x_1 is treated as the input of m_3 while x_2 as the input of m_4. Similarly, the relationship between the output data flows of an object also needs to be determined, but additional caution on the number of output variables of a needs to be taken: only one output variable is allowed for a. Thus, a invocation can be incorporated into expressions. For example, the output data flows q_1 and d_2 of object B1 in Figure 3 is defined as the output of the two s m_3 and m_4, respectively, in the associated class CB1. 4 A Small Case Study We have applied the approach described in the preceding section to build an Intelligent Office Control System. A simplified image of an office is depicted in Figure 4. The system automatically control the use of necessary resources, such as room light, computer, door locking, air conditioner, and so on. It is intelligent in the sense that the state of the office environment changes automatically to satisfy human s intention. For example, when a person comes in the office and it is too dark to work, the control system will automatically turn on the room light; if the temperature is below a certain degree, the control system automatically turns on the air conditioner and adjust the humidity automatically; and when he or she sit down in the chair before the computer, the computer screen will be turned into the working condition. To this end, we need three sensors, at least, to obtain the changed state of the environment, such as the door is opened and temperature has fallen below 15 degree centigrade. To design such a system, we create a top level object office-controller to provide the overall control Figure 4. A simplified image of office Office environment data office-controller: OfficeController command Figure 5. The top level CDFD Devices function of the office, as shown in Figure 5. The object receives data from the office environment, represented by a dotted rectangle, and gives command to the devices under control of the system. The object office-controller is then decomposed into two objects sensor and devices-controller, which constitute the CDFD in Figure 6. Since different devices, such as door, air conditioner, light, and computer, need different sensors to monitor, we decompose the abstract input data flow data of the object officecontroller in the top level CDFD into three concrete data flows: door-data, tem-data (temperature data), and chair-data, which are supposed to be received by different sensors. Likewise, the abstract data flow command is decomposed into the three concrete commands: com1 (to control the light of the office), com2 (to control the air conditioner), and com3 (to control the computer screen). The object Sensor is further decomposed into the three concrete sensors: door-sensor, temerature-sensor, and chair-sensor, each being treated as an object. Continuing this decomposition process eventually results in the flat CDFD in Figure 7. Based on this CDFD we define the corresponding classes of all the objects involved. Since they are written in the same principle, only is the class DoorSensor is presented in detail and all the others are omitted.

6 door-data com1 numbers including zero. tem-data sensor: Sensor y devices-controller: DevicesController com2 5 Related Work chair-data Figure 6. The decomposition of object office-controller door-open darkness tem person-in person-left person-back door-sensor: DoorSensor door-controller Check-Door-State tem-sensor: TemSensor Check-Tem chair-sensor: ChairSensor air-conditionercontroller computercontroler Check-Person-Left Check-Person-Back y2 y1 y3 door-controller: DoorController Turn-On-Light air-conditioner-controller: AirConditionerController Set-Air-Conditioner computer-controller: ComputerController Set-Off-Screen Set-Back-Screen Figure 7. The flat CDFD of the hierarchical CDFDs class DoorSensor; var Init() post door-controller = new DoorController end_; ext explicit end_ end_class; com3 com1 com2 com1 Check-Door-State (door-open: bool, darkness: nat0) wr door-controller if door-open and darkness <= 5 then door-controller.turn-on-light() /* invocation */ Where bool denotes the type of boolean values including true and false, andnat0 is the type of natural The early research on the relation between structured s and object-oriented s for system analysis and design goes back to Ward s work [9] in which Ward tried to utilize the advantages of StructuredAnalysisandDesignwhenanimplementation will be done using an Object-Oriented programming language. He acknowledges that the conventional Structured Analysis and Design does not lead itself easily to the identification of objects, and certainly not to object hierarchies, which shares partially with our finding resulting from the case study presented in section 4. Champeaux [1] views the system analysis as the activity that yields a description of what a target system is supposed to do by detailing functional, performance and resource requirements, and such an analysis can be performed in an object-oriented manner, taking three steps: developing an information model, developing a statetransition model, and developing a process model. The underlying idea of this approach is to start the analysis by focusing on the construction of objects, and then model the state transition of objects, and then attaching processes (operations) to transitions. In Rickman s work [5], after comparing Object- Oriented and Structured Methods by explaining their advantages and disadvantages, Rickman points out that Object-Oriented Methods do not provide support for identifying which objects will generate an optimal system design. He suggests a process to combineobject-orienteddesignwithstructureddesign, including the three steps: (1) build context diagram, (2) use functional decomposition to partition requirements, and (3) build an Object-Oriented model to understand data relationships. However, he does not show how the Structured Design is transformed into an Object-Oriented Design, and also there is no specific notation involved. Furthermore, while Jacobson [2] is in favor of using use case idea for Object- Oriented Analysis and Design, Meyer [4] seems to disagree,assaying Exceptwithaveryexperienced design team (having built several successful systems of several thousand classes each in a pure O-O language), do not rely on use cases as a tool for objectoriented analysis and design. In fact, UML itself has adopted many ideas from Structured Analysis and Design, such as the use of use case diagram and whole/part diagrams [8]. Although many of

7 us have realized that both Structured Methods and Object-Oriented Methods are complementary in system analysis and design, how to effectively use them together in practice has yet to be studied more carefully. 6 Conclusions We have argued that a decompositional, top-down approach is effective for object-oriented design because it tackles the problem of lacking a way of identifying objects in conventional object-oriented analysis and design. To support this claim we have presented a specific way to carry out an object-oriented design in a decompositional manner, and a notation resulting from the combination of UML and SOFL for representing the design process and documentation. The important point of the proposed approach consists not only in the effectiveness of the decompositional approach in helping identify objects, but also in the use of the formal notation of SOFL to achieve the preciseness of the class definitions. We plan to conduct more case studies in the future to improve the proposed approach. In spite of the positive aspect, the proposed approach is also facing a challenge in creating proper class inheritance hierarchies. We plan to attack this problem in our future research by conducting more complex case studies. [5] Dale M. Rickman, A Process for Combining Object Oriented and Structured Analysis and Design, The PDF file at the URL: [6] Shaoying Liu, A Jeff. Offutt, Chris Ho-Stuart, Yong Sun, Mitsuru Ohba, SOFL: A Formal Engineering Methodology for Industrial Applications, IEEE Transactions on Software Engineering, Special issue on Formal Methods, IEEE Computer Society Press, Vol. 24, No. 1, January 1998, pp [7] Shaoying Liu, Masashi Asuka, Kiyotoshi Komaya, Yasuaki Nakamura, An Approach to Specifying and Verifying Safety-Critical Systems with Practical Formal Method SOFL, Proceedings of Fourth IEEE International Conference on Engineering of Complex Computer Systems, IEEE Computer Society Press, Monterey, California, USA, August 10-14, 1998, pp [8] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual, Reading, Mass.: Addison-Wesley, [9] P.T. Ward, How to Integrate Object-Oriented with Structured Analysis and Design, in IEEE Software, 1989 March, pp References [1] Dennis de Champeaux, Object-Oriented Analysis and Top-Down Software Development, Software and Systems Laboratory, Hewlett Packard, Technical Report, HPL-91-12, February 1991, pp URL: html. [2] Ivar Jacobson, Object-Oriented Software Engineering, A Use Case Driven Approach. NewYork, Addison-Wesley, [3] Meilir Page-Jones, Fundamentals of Object- Oriented Design in UML, Dorset House Publishing, New York, [4] Bertrand Meyer, OOSC2: The Use Case Principle,