4 Introduction to the Unified Software Development Process and OO Analysis

In this chapter we extend the software process discussed earlier to take account of more of the tasks that are necessary in the software development. The extended process is call the Unified Process and expressed in Unified Modeling Language (UML). We also point out the limitations of this process for embedded systems setting the stage for a later enhanced approach based on systems methodology. Finally, we outline a procedure for OO analysis that is a combination of approaches in the literature.

The Unified Software Development Process

UML is rapidly establishing itself as a standard for analysis and design of object oriented software. It defines a rich set of modeling formalisms for describing object oriented software and systems [2]. And it defines the Unified Process as a standard software development process [11]. The Unified Process [11] is a software development process which has been defined in continuation of the definition of Unified Modeling Language [2] as a standard for modeling object oriented software. It is supposed to be a generic framework for developing software in many different domains. It has grown out of the Objectory use case driven design process initially defined by Jacobson [10]. The most distinctive characteristic of the Unified Process is that it is requirement-driven. The use case model is supposed to define the requirements posed on the system and is intended to drive the whole development process (Figure 1). In particular, the functional requirements for the system being
1 By H. Praehofer, Kepler University, Linz, Austria. This is replicated from Chapter 17 of Discrete Event Modeling and Simulation Technologies: A Tapestry of Systems and AI-Based Theories and Methodologies by Hessam S. Sarjoughian (Editor), Francois E. Cellier

112

Herbert Praehofer

developed are stated in the form of use cases, which define interactions of users with the system in fulfillment of a particular task. The use case model forms the basis for the further development process as shown in Figure.1. The analysis model is specified as an initial object structure in the form of UML class and object diagrams which is able to realize the behavior specified in the use cases. The design model is the software blueprint of the system developed from the analysis model to fulfill the use case requirements. It defines in detail the class and object structures as well as their interactions and dynamic behavior to realize the use cases. It also has to consider all the non-functional requirements posed on the system. The implementation model is the realization of the system in form of program code. The deployment model represents the architecture of the execution environment to run the software. The test model consists of the test cases to verify that the system fulfills all the requirements. The test cases can directly be derived from the use case descriptions.

s p e c i f i e d

b y rd e a l i z e b y d ib s tt rd ie u b y

U s e C a s e M o d e l

ile m p e m n t e d

b y

A n a l y s i s M o d e l

v e r i f i e b d y

D e s i g n M o d e l D e p le o y m n t M o d e l Im m po le e n t a t i n M o d e l
X O K X O K X O K

T e s t M o d e l

Figure 1: Unified Process (from [11])

Towards a Systems Methodology for Object-Oriented Software Analysis

113

Besides use cases, architectures play a dominant role in the Unified Process. An architecture embodies the most significant static and dynamic aspects of a the system [11]. Architecture gives the system an initial and overall structure. Architectures represent an important design knowledge orthogonal to use cases. While use cases cast the functions of the system, the architecture gives the system form. Both are essential for a the final product. The use cases must be realized within the architecture and the architecture has to provide room for their realization. The Unified Process is also component-based. The software system is built up of components which have well defined interfaces. Reusable building blocks should be identified during the design process. Ideally, the building blocks then do not have to be further elaborated but can be reused as is.

Use case model

The use case model is supposed to capture all the requirements posed on the system from a users/customer perspective. It consists of the definition of the actors, i.e., all the components which are outside the system but interact with it in some form, the system boundary through which the actors communicate with the system, and the use cases that describe the interaction of the actors with the system in fulfillment of a particular task. They do this by adopting a Black Box view, in that the inputs to and responses from the system are defined, but the interior of the system is concealed. In the Unified Process the input/output behavior captured in the use cases is event-based (Figure 2).

S y s t e m
A c t o r 1 iu n p t 1 o u t p u t 1 iu n p t 2 o u t p u t 2 A c t o r 2

. . .

. . .

Figure 2: Use case as input/output description between actors and the system

114

Herbert Praehofer

Analysis model
Setting up an analysis model is the first step in the development of the system. The analysis model is intended to define a first structure of the system to be designed in the form of a class and/or an object diagram. The analysis model, therefore, represents an important step in the development process because it gives the system its initial structure which is subject to further refinement in later development steps. According to the Unified Process, the development of the analysis model has to occur on the basis of the use case specifications. The analysis model has to be capable to fulfill the functional requirements stated in the use case descriptions. The Unified Process gives several guidelines for discovering objects and classes for the analysis model. Domain representation or conceptual modeling [13] is derived from the idea that objects in reality can also be found in the software system. A textual analysis of the problem specification can be used to filter out objects together with relevant attributes, associations, and operations. Furthermore, the Unified Process suggests distinguishing three types of objects: Interface objects mediate the communication with the actors. They directly correspond to the actor/system interfaces. Entity objects: are objects to hold information. They often correspond to the objects in reality and can be found by conceptual domain modeling as discussed above. Control objects: are those objects which coordinate and allocate work between the different objects in fulfillment of a particular use case.

Limitations of the Unified Process

Although the Unified Process represents a step into the right direction, in everyday practice and also in teaching it has several deficiencies in relation to embedded systems that are of most interest to engineering applications: How to find use cases: The Unified Process does not give useful guidelines how to find relevant use cases. It recommends that user sessions are use cases. This however is not practical for embedded systems where actors continually interact with the system. How to find the objects: Conceptual modeling inappropriate for complex system analysis and design. First of all, textual problem specifications for complex domains are either not available at all

Towards a Systems Methodology for Object-Oriented Software Analysis

115

or much too voluminous to lend themselves to textual analysis. A direct automatic derivation of objects types with data structure and behavior from textual descriptions is not practical. In what follows we suggest a procedure for identifying objects combining several approaches in the literature. What are useful architectures for analysis: Although the Unified Process stresses the importance of architectures in the development process, it does not state what useful architecture for analysis models are, nor how such can be found2

. Later we will outline ideas on how those deficiencies can be overcome. The ideas originate from the systems background [22, 20, 12] which affords a precise methodology for building models and designing systems.

Procedure for OO Analysis

(see AnalysisMethod powerpoint)

Design of a PERT Chart Tool: Example of ULM Concepts

We discussed project management tools in the last chapter and later well use them to schedule the execution of your term project. In this section we consider the design of a PERT tool to illustrate some basic ULM concepts. Heres an example of such a tool:

2 The literature on software architectures [4, 17] eonly provide initial structures to cope

with realization issues, and are often restricted to very particular application domains, e.g. classical control systems [1].

116

Herbert Praehofer

(source: http://www.criticaltools.com)

Use Cases
Information that the user will input: tasks, their durations, and their precedence relations (e.g., for each task, give its precursors). Response of the system: critical path, slack for non-critical tasks Interface: textual input, graphical output showing

Analysis
Objects: tasks with attributes: duration, start time, finish time, on-criticalpath flag, slack Classes: time line chart class to hold task objects, user specified task class, system added task classes: start task, finish.

Design
Collaborations: tasks collaborate with their successors and with their predecessors

Towards a Systems Methodology for Object-Oriented Software Analysis

117

Message exchange interactions: task sends finish time to its successors sequence is started by start task and terminated when it reaches finish task. task sends pair:(start time, identification of critical predecessor) to its predecessors sequence is started by finish task and terminated when it reaches start task task send display signal to successors sequence is started by start task and terminated when it reaches finish task. States and inputs/transitions/outputs states: wait for predecessor finish time, wait for successor start time, wait for display signal set on-critical-path flag from predecessor furnished information compute slack from own finish time and successor start time

Implementation
Use simulation environment: DEVSJava (off the shelf reuse)

Test
Test individual tasks and small PERT charts

References
[1] Albus, J. S., RCS: A Reference Model Architecture Demo III. National Institute of Standards and Technology, Gaithersburg, MD, NISTIR 5994, 1997. [2] Booch, G., Rumbaugh, J., and Jacobson, I., The Unified Modeling Language Users Guide, Addison Wesley, 1999. [3] Brooks, R. A., "Intelligence Without Representation," Artificial Intelligence Journal (47), 1991, pp. 139--159. [4] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M., A System of Patterns, Wiley, 1996. [5] FIPA Foundations for Intelligent Physical Agents, FIPA 97 Spacification, Geneva, Switzerland, October 1998. [6] Hayes-Roth, B., Pfleger, K., Lalanda, P., Morignot, P. and Balabanovic, M., A Domain-Specific Software Architecture for Adaptive Intelligent Systems. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995, pp. 288-301. [7] Jacak, W. and Rozenblit, J.W., Automatic Simulation of a Task-Oriented Robot Program for a Sequential Technological Process, Robotica, 34, 45-56, 1992.

118

Herbert Praehofer
[8] Jacak, W. and Rozenblit, J.W., CAST Tools for Intelligent Control in Manufacturing Automation. In: Lecture Notes in Computer Science No. 763, (Eds. F. Pichler and R. Moreno-Diaz), 203-219, Springer-Verlag, 1994. [9] Jacak, W., Intelligent Robotic Systems, Kluwer Academic/Plenum Publisher, 1999. [10] Jacobson, I., Christenson, M., Jonsson, P. and vergaard, G., Object Oriented Software Engineering, Addison Wesley, 1992. [11] Jacobson, I., Booch, G., and Rumbaugh, J., The Unified Software Development Process, Addison Wesley, 1999. [12] Klir, G.J., Architecture of Systems Complexity, Sauders, NewYork, 1985. [13] Larman, G., Applying UML and Patterns, Prentice Hall, 1998. [14] OHare, G.M.P. and Jennings, N.R. (Eds.), Foundations of Distributed Artificial Intelligence. Wiley Interscience, 1996. [15] Praehofer, H., Jacak, W., Jahn, G., and Haider, G.,"Supervising Manufacturing System Operation by DEVS-based Intelligent Control", AIS '94, Gainesville, FL, IEEE/CS Press, Dec. 1994, pp. 221-226. [16] Rozenblit, J.W. and Zeigler, B.P., Design and Modeling Concepts, In: International Encyclopedia of Robotics. (Ed. R. Dorf), 308-322, John Wiley and Sons, New York, 1988. [17] Shaw, M. and Garlan, D., Software Architecture - Perspectives of an Emerging Discipline, Prentice Hall, 1996. [18] Sun Microsystems: JavaBeans 1.01 API Specification. Sun Microsystems, Inc., 1997. see http://java.sun.com/Beans/spec.html [19] Zeigler, B.P., Cellier, F.E. and Rozenblit, J.W., Design of a Simulation Environment for Laboratory Management by Robot Organizations, Journal of Intelligent and Robotic Systems, 1(1), 299-309, 1988. [20] Zeigler, B.P., Object Oriented Simulation with Modular Hierarchical Models. Academic Press, 1990. [21] Zeigler, B.P, Song, H.S, Kim, T.G, and Praehofer, H. DEVS Framework for Modeling, Simulation, Analysis, Design of Hybrid Systems, Lecture Notes in Computer Science: Hybrid Systems II, pp. 529-551, Springer, 1995. [22] Zeigler, B.P., Praehofer, H., and Kim, T.G., Theory of Modeling and Simulation, 2nd Edition. Academic Press, 2000.