Object-Oriented architectural support for developing ... - CiteSeerX

Agarwal, Bruno, Torchiano – Object-Oriented architectural support for developing complex systems

Object-Oriented architectural support for developing complex systems 1 Rakesh Agarwal Infosys Technologies Ltd., Near Planetarium, N.H.5, Bhubaneswar - 751013, India, Email: [email protected]

Giorgio Bruno, Marco Torchiano Dip. Automatica e Informatica, Politecnico di Torino, I-10129 Torino, Italy Email: bruno/[email protected] functional representations. In general, a model is an abstract, rigorous representation of a system, which enables the user to reason about its properties. If attention is focused on software development, models are used during analysis to specify the functions and the behavior of the system being considered and during design to define the architecture of the implementation. Growing interest is being shown in operational models[1], i.e. models that can be executed using a suitable support environment. Most operational models are graphical and can be considered as high-level programs, which are developed using high-level modeling languages. An operational model can be modified and tuned until the behavioral traces it generates match those expected. In this way, the model is a reference point for the development of the system and, what is more, the purchaser feels confident that the system, being developed according to the model, will behave properly. This approach provides important benefits, such as: • minimizing the risk of finding out that information is missing or inconsistent at the time the system is brought into operation; • maximizing the reuse of software modules (this is because their corresponding models are reused and reusing models is much easier than reusing programs); • improving productivity, because the final code can be generated from the model automatically. Graphical models have been used for a long time for specification and design purposes: dataflows[2][3], extended data-flows for real-time systems[4][5], and Entity-Relationship [6] are well-known formalisms. Dataflows are used to describe the functions that the system being considered must perform. They are not operational, thus several developers of CASE tools have tried to overcome the limitations of traditional dataflows by enabling analysts to specify functions using an

Abstract Object-oriented software evolve over time and it would be ideal if we could capture persistent parts of the software early on and then derive the transient versions of the software from the persistent part. Capturing the persistent parts of a software allows us to better maintain the integrity of the program during evolution. This is the goal of software architecture. In this paper we emphasize an approach called O3ML, to model complex software system using a sound software architecture, which is centered upon the creation of a system prototype with an integrated design requirements and simulation framework. This methodology supports the prototyping of complex computer based systems by providing: (a) a multi-domain approach to capture architectural complexity of real-world systems; and (b) a mechanism for simulation of the conceptual, functional and implementation features of the design and requirements.

1. Introduction Software architecture serves as a framework for understanding system components and their interrelationships, especially those attributes that are consistent across time and implementations. This understanding is necessary for the analysis of existing systems and the synthesis of future systems. In support of analysis, architectures capture domain knowledge and community consensus; facilitate evaluation of design and implementation of components; and ease simulation and prototyping. In support of synthesis, architectures provide a basis for establishing product lines and using domain knowledge to construct and maintain modules, subsystems, and systems in a predictable manner. Using models to study the properties of complex systems is common to all disciplines. Models can be scaled physical systems, mathematical equations or 1

Appeared in Proceedings of the 23rd Annual International Computer Software and Applications Conference (COMPSAC’99), Phoenix, AZ, USA, October 27-29, 1999.

-1-


executable language and by introducing rules for scheduling the execution of functions. A significant number of object-oriented methods (UML[21], Rumbaugh[7], Booch[8], etc.) have been introduced during the past several years. These methods claim that object-oriented approach creates highly reusable and robust software; although based on sound semantics, they are not operational. On the other hand, classical control models, such as those based on finite-state automata, statecharts[9] and Petri nets[10], are, by their very nature, operational models. In fact, such modeling languages have intrinsic execution mechanisms, but they can only be used to represent the control aspects of a system; further, they do not cope with complex architectural issues. It was to overcome the limitations of the abovementioned approaches and provide advanced software architectural features that O3ML was devised for. Combining the concepts of operational models and object orientation, we developed a modeling language, which will be referred to as O3ML (Operational Object-Oriented Modeling Language). Further details on the approach and on the language can be found in [11][12]. O3ML offers the following major benefits. • It clearly separates the structure (made up of classes and relationships) of a system from its architecture (made up of instances, simple or composite). • It supports the top-down partitioning of a complex system into manageable pieces as well as bottom-up composition of reusable building blocks. • It is mainly a graphical language. A textual language, C++, extended with specific simulation primitives, is used for the implementation of methods and actions. • It provides an integrated collection of modeling abstractions. • It provides a number of mechanisms through which objects can interact with each other: functional interaction, token-driven interaction and navigation. • It yields models that can be simulated and animated at all levels of abstraction, thus allowing early detection of requirements or design flaws. • It is amenable to different kinds of execution. The possibility of using O3ML as both a system modeling language and a software development tool is one of the major goals of our work. Next sections describe the major features of O3ML: the difference between structure and architecture, tokendriven behavior, token-driven interaction, inheritance, functional interaction and navigation.

models of applications and models of components. An application model represents the final system and, in conformity to the principle of hierarchical decomposition, it can contain lower-level application models. If, for the moment, we disregard hierarchical decomposition, we consider a model to be made up of interacting building blocks (or components) as exemplified in Figure 1. To be more precise, an application model contains actors and connections between actors.

Application Class CS_AP1 C1, Client

S1, Server

Request_Service Figure 1. An application model Actor is the term we use to denote a building block and, to a certain extent, it can be considered to be a synonymous of object. Actors are instances of classes and are graphically depicted as squares; an actor has two labels, i.e. its name and the name of its class. The example in Figure 1 refers to a client-server system and contains a single client, C1, which is connected to a single server, S1. The connection from C1 to S1 is called Request_Service and its exact meaning will be explained later on. The construction of a model implies that we know which classes can be used and how their instances can be inter-connected. This knowledge concerns the structure of the model and is given in terms of a Class-Relationship ([6]) diagram, which we call an actor schema. An actor schema is made up of actor classes and relationships between these classes. In O3ML an application model is bound to an actor schema, which acts as a control schema because it determines what classes and relationships may appear in the application model. In fact only instances of the classes shown in the control schema can appear in the application model and only connections derived from the relationships that appear in the control schema can be drawn between these instances. The actor schema for the client-server model is shown in Figure 2. We call architecture the contents of a model meaning that an architecture is a particular realization of a structure, which is defined in a schema. In general, in O3ML two actors may interact only if they are connected and a connection between actors can be established only if in the actor schema there is a relationship between their classes. In order to illustrate the above-mentioned concepts we discuss the example of a client-server system. In this

2. Structure and architecture Since model is a generic term we distinguish between

-2-


system there may be several clients and servers. Clients and servers are building blocks; they do not know of each other, thus a client will request services only of the server it is connected to. This model will be simulated, therefore durations are associated with activities. Durations are expressed in integer time units. The requirements of the system are as follows. A client periodically requests a service of a server and waits for the reply. The interval between the arrival of a reply and the issue of the next request is a parameter (Rdelay) of the client. The client sends an integer value (given by parameter Service_Info) to the server, which replies by adding a number (contained in its parameter N). The time for performing a service is given by parameter Sdelay.

2.

Behavior. The term behavior denotes what an actor performs in order to achieve what is implied in its interface. As for the interactions we define two kinds of behaviors: token-driven behavior and functional behavior. Token-driven behavior is expressed by means of a graphical formalism; in particular, we use high-level nets[13][10], but hierarchical state machines[14] and statecharts [15] could be used as well. Functional behavior is made up of services, those mentioned in the interface and others, which are only used internally. To be more precise, while the interface only includes the headings (or signatures) of services, i.e. their parameters and return types, functional behavior includes their bodies as well. Actors can have parameters, i.e. named values that can influence their behavior. For example, parameter Sdelay can be used to make the server slower or faster. In order to study the performance of a system, several simulation runs are usually performed with different values in critical parameters. A parameter, as such, is defined in an actor class in terms of a name and type (e.g. an integer number or a string), but its value is defined in a session, a session being a collection of values, one for each parameter of the actors making up the application. An application can have several sessions of parameters. An example of a session is shown in Figure 3.

Client_Server_AS Client

Server Request_Service,(m,n)

Figure 2 The client-server application’s schema A (sub)model can be part of a larger (composite) model and a composite model could contain a number of similar sub-models, thus a model can be given the meaning of a class. We call application class the class of an application model in order to distinguish it from that of an actor; in fact, a model is only a container and has no behavior. CS_AP1, shown in Figure 1, is then the application class related to the above-mentioned example. Connections support the interactions between actors. We define two kinds of interactions between actors: tokendriven interaction and functional interaction. Token-driven interaction takes place when an actor sends a token to another actor; we can think of a token as a message. If an actor is to generate or receive a token, its class must include a token-driven behavior as illustrated below. Functional interaction takes place when an actor calls a service of another actor. An actor class in O3ML can be described from two perspectives. 1. Interface. The interface of an actor is what the other actors need to know in order to interact with it. It consists of services (or methods) and parameters (i.e. visible attributes) as usual in the object-oriented paradigm and, further, of connectors. Connectors are the means through which interactions between actors can take place. As will be illustrated later on, a connection between actors is actually established between a connector of one actor and a connector of the other.

Session S1 of CS_AP1 C1, Client

S1,Server

Request_Service

Rdelay = 20; Service_Info = 100;

Sdelay = 5; N = 30;

Figure 3 A parameter session

3. Inheritance Inheritance, a major feature of the object-oriented paradigm, is a powerful mechanism, which allows new classes to be built as extensions of existing ones. O3ML supports single inheritance, i.e. a new class can be built on top of one existing class. While the notion of inheritance is well defined for textual languages, it requires further explanation when it is applied to a graphical modeling language, such as O 3ML. Inheritance in O3ML means that the derived class inherits the parameters, services, connectors and the behavioral view of the base class. As an example we want to slightly change the behavior of the server in order to keep track of the number of services performed.

-3-


We have to provide a new version of class Server, say, Server1 but in order to be able to use both classes we keep Server and introduce Server1 as a derived class. The new server class needs to keep track of the number of services performed, so it is necessary to add a parameter, Counter, and to modify the behavior accordingly. In addition to parameter Counter, Sim_State has been introduced. Its meaning is predefined: as the value of Sim_State will be displayed close to the actor’s icon during the execution of the model, this parameter can be used to show some useful information about the state of the actor.

The answer is by navigation, a technique that an actor can exploit in order to reach other actors without knowing their names. An actor performs a navigation when it reaches another actor by following a connection it is involved in. If actor O follows connection Observes, it will reach actor S1 without knowing in advance what is the name of the actor it will reach. Once actor O has reached S1, it can act upon it (by reading/writing its parameters or requesting a service of it) or, what is more, it can continue the navigation to reach another actor (e.g. C1). A connection between actors can convey two meanings, interaction and association; connection is a neutral term, it gives the idea of a physical link whose logical meaning is left undetermined. We think of a connection as an interaction when the actors involved send tokens to each other, as in the case of the client and the server. We, instead, think that it is an association when its purpose is to logically relate one actor to another, so if we have one we can easily get the other. In most cases the two meanings are disjoint, but it may happen that an interaction will also be navigated. If a relationship represents a logical association, it is not necessary to specify a connection type; therefore the connectors originated from the relationship will have a standard type. Navigation, as an operational mechanism, is based on connectors and is carried out by means of suitable primitives expressed in the language (C++) used to write services and behavioral actions. A connector can be used as an iterator in order to scan the associations it is involved in. When an association is established from an object A to an object B, two links are actually introduced by O3ML: one from the output connector (involved by the relationship the association belongs to) of A to B and another from the input connector (involved by the relationship) of B to A; in this way an association can be traversed in both directions. Given a connector C, the major services that can be requested of it are listed below. • MoveFirst. C.MoveFirst() makes the first association current. For each connector there is a list of associations and the iterator allows for a sequential stepping through the list. Initially the iterator points to the first association. • MoveNext. C.MoveNext() makes the next association current. • IsEOF. C.IsEOF() returns true if the iterator is positioned after the last association in the list. • operator(). C() returns a pointer (of type Actor*) to the other actor involved in the current association.

Client_Server2_AS Client

Server Request_Service, (m,n) is-a

Observer

Server1

Observes, (1,1)

Figure 4 The enhanced schema As a further example we want to add an observer class whose purpose is to collect statistical data about servers. Therefore a new class, Observer, has been added to the enhanced schema shown in Figure 4. This class is connected through relationship Observes to class Server1 from which it draws data. A sample application class, based on the above schema, is shown in Figure 5.

Application Class CS_AP2 C1, Client

S1,Server1

O, Observer Observes

Figure 5 Application class CS_AP2

4. Functional interaction and navigation The observer appearing in Figure 5 periodically reads the counter of the server. We do not want the server to be affected by the presence of the observer, therefore no token-driven interaction will be established between them. The server will directly look at the counter of the server and this is allowed since a parameter belongs to the interface of an actor. But how can the observer know that it has to interact with S1?

-4-


graphical user interface, while a back-end tool performs the actual simulation. These tools communicate with each other in a transparent way. The back-end tool is made up of two components: the translator, which produces a set of C++ classes from an intermediate representation provided by the front-end (STDL files), and the builder, which produces the simulator, i.e. the executable, using standard C++ compilers and linkers. The simulator is built from an actor schema, therefore all the applications based on the same schema will use the same simulator.

Parameters int Sampling_rate; default=1000 int Total; default=1000 Actor *S=Observes(); // gets the actor linked to connector Observes Total = S->IPar(“Counter”); // acts on the reached actor, // i.e. reads integer parameter Counter of the actor referred to by S SetDelay(Sampling_Rate);

Figure 6 Class Observer’s behavior The behavioral view of class Observer is shown in Figure 6. There is only one activity, Read_Counter, which is periodical. After obtaining a pointer (S) to the server linked to the observer, Read_Counter copies the value of parameter Counter of the server into parameter Total of the observer. Since the server is seen through a pointer to its base component (of class Actor), we cannot write S>Counter to act on parameter Counter of the server. However class Actor provides a number of services, which, given the name of an actor’s parameter, return a reference to the value of that parameter. Since C++ is strongly typed, we need as many services as the types allowed for parameters. If we restrict the attention to the mostly used, we need few services, IPar, FPar and SPar, to act on integer, float and string parameters, respectively. In case the observer is connected to several servers, it is easy to modify the behavior in order to have the observer collect the sum of the services provided so far by all the servers. The new statements are shown in Figure 7.

The simulation process can be divided into two phases: the first, off-line, is the construction of the simulator, the second, i.e. the interactive execution of the simulator (or, simply, interactive simulation), requires the user’s action. Interactive simulation is driven by the (simulation) commands issued by the user who receives replies from the simulator in the form of animations provided by the front-end. Simulation commands can be partitioned into three categories: control commands, inspection commands and interaction commands.

Interaction Simulator

Front-end

STDL

Builder

Translator

C++

Figure 8 The simulation environment Control commands allow the user to start, evolve, suspend, resume or stop simulation. Simulation can run up to a specified time or can be performed step by step. Inspection commands can be used to read the attributes of all the elements of the model. As an example, the contents of the tokens contained in a given place can be shown.

Total = 0; for(Observes.MoveFirst();!Observes.IsEOF(); Observes.MoveNext()) { Actor *S = Observes(); Total += S->IPar(“Counter”); }

Figure 7 Navigating multiple associations

5. Simulation of models Models could be validated on paper but this is affordable only for simple models; when a thorough check is required, the technique of simulation[16] is much more effective. Simulation is a kind of execution mechanism: it is based on simulated time and on the scheduling of the activities performed by the actors of the model. An O3ML model can be mapped to other execution environments; in reference [17] the generation of concurrent distributed processes from actors is discussed. There are a number of ways for organizing a simulation environment. O3ML clearly separates the phases of modeling and simulation, as shown in Figure 8: in fact a front-end tool (including a graphical editor) provides the

6. Conclusions This paper has presented a language, O3ML, intended to support the construction and execution of operational object-oriented models. O3ML provides a number of features for handling very complex models. First, the concept of schema allows us to organize classes and relationships into catalogs of building blocks the actual applications can draw on; then hierarchical containment of applications yields complex yet structured architectures, in which applications at different levels can be made up of building blocks taken from different catalogs. The kind of results produced by an operational model depends on the mechanisms associated with the modeling

-5-


[7] J. Rumbaugh et al., Object-oriented modeling and design. Prentice-Hall, Englewood Cliffs, N.J., 1991. [8] G.Booch, Object-oriented analysis and design with applications. Benjamin/Cummings, Redwood City, CA, 1994. [9] D. Harel and E. Gery, “Executable object modeling with statecharts”. IEEE Computer (30)7, July 1997. [10] T.Murata, “Petri nets: properties, analysis and applications”. Proceedings of the IEEE, 77:541-580, April 1989. [11] G. Bruno, Model-based software engineering. Chapman & Hall, London, 1995. [12] R. Agarwal, Operational object-oriented modeling. PhD thesis, Politecnico di Torino, Dipartimento di Automatica e Informatica, Torino, Italy, February 1996. [13] J. L. Peterson. Petri net theory and the modeling of systems. Prentice-Hall, Englewood Cliffs, N.J., 1981. [14] D. Coleman, F. Hayes, and S. Bear. Introducing Objectcharts or How to use Statecharts in Object-Oriented Design. IEEE Trans. Software Engineering, 18(1):9{18, January 1992. [15] D. Harel et al.. STATEMATE: A Working Environment for the Development of Complex Reactive Systems. IEEE Trans. Software Engineering, 16:403-414, April 1990. [16] G. S. Fishman. Concepts and methods in discrete event digital simulation. John Wiley & Sons, New York, 1973. [17] G. Bruno et al., "CAB: an environment for developing concurrent applications", In Proc. 6th Int. Conf. on Application and Theory of Petri Nets 1995, Torino, Lecture Notes in Computer Science 935, Springer-Verlag, Berlin, 1995, pp.141-160. [18] G. Bruno and R. Agarwal. Architectural framework for developing concurrent applications, in the Proc. of the 19th Annual International Computer Software and Applications Conference (COMPSAC95), pages 256-261,Dallas, Texas, USA, August 1995. [19] G. Bruno, C. Reyneri and M. Torchiano. Enterprise Integration: operational models of business processes and workflow systems. In Proc. ICEIMT 97, Torino, October 1997. [20] G. Bruno and R. Agarwal. Modeling the enterprise engineering environment. IEEE Transactions on Engineering Management, 44(1):20-30, February 1997. [21] OMG. Unified Modeling Language Specification(draft) version 1.3alphaR5 march 1999.

components. Simulation mechanisms are commonly used in order to investigate the performance of a system in terms of throughput and usage of resources. In other cases we might be interested in viewing the model as a prototype of the intended system. A prototype exhibits the major functions of the intended system, including user interactions, but it is based on a simplified implementation. For example, in business process (re)engineering a prototype might be needed when a new business process is designed in order to study the impact on the organization and on the information system. When a human-based business process is concerned, such as in an engineering process (in contrast with a manufacturing process, which could be totally automatic), the mechanisms involved are those related to the workflow system as illustrated in [19] and [20]. In this case, the mechanism associated with a construct that models an activity, instead of simply producing a delay just as occurs in simulation, will generate a pending activity for a person (who is specified in the construct itself either directly or indirectly by means of a rule). Current work is being devoted to the automatic generation of distributed applications from O3ML models; in this case we adopted Java as the action-level language and RMI as the underlying interaction mechanism for distributed objects.

References [1] P. Zave, “The operational versus the conventional approach to software development”. Commun. ACM, 27:104-18, February 1984. [2] T. De Marco, Structured analysis and system specification. Prentice-Hall, Englewood Cliffs, N.J., 1979. [3] C. Gane and T. Sarson, Structured systems analysis: tools and techniques. Prentice-Hall, Englewood Cliffs, N.J., 1979. [4] D. Hatley and I. Pirbhai, Strategies for real-time system specification. Dorset House, New York, 1987. [5] P. T. Ward and S. J. Mellor, Structured development of realtime systems. Yourdon-Press, Englewood Cliffs, N.J., 1985. [6] P. Chen, “The Entity-Relationship model - toward a unified view of data”. ACM Trans. Database Syst., 1:9-36, March 1976.

-6-