SYSTEM AND METHOD FOR COORDINATION-CENTRIC DESIGN OF SOFTWARE SYSTEMS

Abstract: Coordination-centric design methodology facilitates the design and the debugging of software systems. Software systems comprise the following elements: components, coordinators and coordination interface. Components are function blocks. Coordinators manage all control and dataflow interactions between components based on a predetermined protocol. Coordination interfaces connect components to coordinators and allow control and dataflow information to be passed between components and coordinators.

Description: SYSTEM AND METHOD FOR COORDINATION-CENTRIC DESIGN OF SOFTWARE SYSTEMS Related Applications This application claims priority from U.S. Provisional Application No. 60/213,496 filed June 23, 2000, incorporated herein by reference. Technical Field The present invention relates to a system and method for designing software systems using reusable software elements and communication protocols. Background of the Invention A system design and programming methodology is most effective when it is closely integrated and coheres tightly with its corresponding debugging techniques. In distributed and embedded system methodologies, the relationship between debugging approaches and design methodologies has traditionally been one-sided in favor of the design and programming methodologies. Design and programming methodologies are typically developed without any consideration for the debugging techniques that will later be applied to software systems designed using that design and programming methodology. While these typical debugging approaches attempt to exploit features provided by the design and programming methodologies, the debugging techniques will normally have little or no impact on what the design and programming features are in the first place. This lack of input from debugging approaches to design and programming methodologies serves to maintain the role of debugging as an afterthought, even though in a typical system design, debugging consumes a majority of the design time. The need remains for a design and programming methodology that reflects input from, and consideration of, potential debugging approaches in order to enhance the design and reduce the implementation time of software systems. 1. Packaging of Software Elements Packaging refers to the set of interfaces a software element presents to other elements in a system. Software packaging has many forms in modern methodologies. Some examples are programming language procedure call interfaces (as with libraries), TCP/IP socket interfaces with scripting languages (as with mail and Web servers), and file formats. Several typical prior art packaging styles are described below, beginning with packaging techniques used in object-oriented programming languages and continuing with a description of more generalized approaches to packaging. A. Object-Oriented Approaches to Packaging One common packaging style is based on object-oriented programming languages and provides procedure-based (method-based) packaging for software elements (objects within this framework). These procedure-based packages allow polymorphism (in which several types of objects can have identical interfaces) through subtyping, and code sharing through inheritance (deriving a new class of objects from an already existing class of objects). In a typical object-oriented programming language, an object's interface is defined by the object's methods. Object-oriented approaches are useful in designing concurrent systems (systems with task level parallelism and multiple processing resources?) because of the availability of active objects (objects with a thread of control). Some common, concurrent object-oriented approaches are shown in actor languages and in concurrent Eiffel. Early object-oriented approaches featured anonymity of objects through dynamic typechecking. This anonymity of objects meant that a first object did not need to know anything about a second object in order to send a message to the second object. One unfortunate result of this anonymity of objects was that the second object could unexpectedly respond to the first object that the sent message was not understood, resulting in a lack of predictability, due to this disruption of system executions, for systems designed with this object-oriented approach. Most modern object-oriented approaches opt to sacrifice the benefits flowing from anonymity of objects in order to facilitate stronger static typing (checking to ensure that objects will properly communicate with one another before actually executing the software system). The main result of stronger static typing is improved system predictability. However, an unfortunate result of sacrificing the anonymity of objects is a tighter coupling between those objects, whereby each object must explicitly classify, and include knowledge about, other objects to which it sends messages. In modern object-oriented approaches the package (interface) has become indistinguishable from the object and the system in which the object is a part. The need remains for a design and programming methodology that combines the benefits of anonymity for the software elements with the benefits derived from strong static typing of system designs. B. Other Approaches to Packaging Other packaging approaches provide higher degrees of separation between software elements and their respective packages than does the packaging in object-oriented systems. For example, the packages in event-based frameworks are interfaces with ports for transmitting and receiving events. These provide loose coupling for interelement communication. However, in an event-based framework, a software designer must explicitly implement interelement state coherence between software elements as communication between those software elements. This means that a programmer must perform the error-prone task of designing, optimizing, implementing, and debugging a specialized communication protocol for each state coherence requirement in a particular software system. The common object request broker architecture (CORBA) provides an interface description language (IDL) for building packages around software elements written in a variety of languages. These packages are remote procedure call (RPC) based and provide no support for coordinating state between elements. With flexible packaging, an element's package is implemented as a set of co-routines that can be adapted for use with applications through use of adapters with interfaces complementary to the interface for the software element. These adapters can be application-specific— used only when the elements are composed into a system. The use of co-routines lets a designer specify transactions or sequences of events as part of an interface, rather than just as atomic events. Unfortunately, co-routines must be executed in lock-step, meaning a transition in one routine corresponds to a transition in the other co-routine. If there is an error in one or if an expected event is lost, the interface will fail because its context will be incorrect to recover from the lost event and the co-routines will be out of sync. The need remains for a design and programming methodology that provides software packaging that supports the implementation of state coherence in distributed concurrent systems without packaging or interface failure when an error or an unexpected event occurs. 2. Approaches to Coordination Coordination, within the context of this application, means the predetermined ways through which software components interact. In a broader sense, coordination refers to a methodology for composing concurrent components into a complete system. This use of the term coordination differs slightly from the use of the term in the parallelizing compiler literature, in which coordination refers to a technique for maintaining programwide semantics for a sequential program decomposed into parallel subprograms. A. Coordination Languages Coordination languages are usually a class of tuple-space programming languages, such as Linda. A tuple is a data object containing two or more types of data that are identified by their tags and parameter lists. In tuple-space languages, coordination occurs through the use of tuple spaces, which are global multisets of tagged tuples stored in shared memory. Tuple-space languages extend existing programming languages by adding six operators: out, in, read, eval, inp, and readp. The out, in, and read operators place, fetch and remove, and fetch without removing tuples from tuple space. Each of these three operators blocks until its operation is complete. The out operator creates tuples containing a tag and several arguments. Procedure calls can be included in the arguments, but since out blocks, the calls must be performed and the results stored in the tuple before the operator can return. The operators eval, inp, and readp are nonblocking versions of out, in, and read, respectively. They increase the expressive power of tuple-space languages. Consider the case of eval, the nonblocking version of out. Instead of evaluating all arguments of the tuple before returning, it spawns a thread to evaluate them, creating, in effect, an active tuple (whereas tuples created by out are passive). As with out, when the computation is finished, the results are stored in a passive tuple and left in tuple space. Unlike out, however, the eval call returns immediately, so that several active tuples can be left outstanding. Tuple-space coordination can be used in concise implementations of many common interaction protocols. Unfortunately, tuple-space languages do not separate coordination issues from programming issues. Consider the annotated Linda implementation of RPC in Listing 1. Listing 1: Linda used to emulate RPC: rpcCall (args) { /* C */ out ("RPCToServer", "Client", args...);, in ("Client, "ReturnFromServer" , &returnValue) ; return returnValue; /* C */ } /* C */ Server: while (true) { /* c */ in ( "RPCToServer" , &returnAddress , args ... ) ; returnValue = functionCall (args) ; /* C */ out (returnAddress, "ReturnFromServer" , returnValue); } /* C */ Although the implementation depicted in Listing 1 is a compact representation of an RPC protocol, the implementation still depends heavily on an accompanying programming language (in this case, C). This dependency prevents designers from creating a new Linda RPC operator for arbitrary applications of RPC. Therefore, every time a designer uses Linda for RPC, they must copy the source code for RPC or make a C-macro. This causes tight coupling, because the client must know the name of the RPC server. If the server name is passed in as a parameter, flexibility increases; however, this requires a binding phase in which the name is obtained and applied outside of the Linda framework. The need remains for a design and programming methodology that allows implementation of communication protocols without tight coupling between the protocol implementation and the software elements with which the protocol implementation works. A tuple space can require large quantities of dynamically allocated memory. However, most systems, and especially embedded systems, must operate within predictable and sometimes small memory requirements. Tuple-space systems are usually not suitable for coordination in systems that must operate within small predictable memory requirements because once a tuple has been generated, it remains in tuple space until it is explicitly removed or the software element that created it terminates. Maintaining a global tuple space can be very expensive in terms of overall system performance. Although much work has gone into improving the efficiency of tuple-space languages, system performance remains worse with tuple- space languages than with message-passing techniques. The need remains for a design and programming methodology that can effectively coordinate between software elements while respecting performance and predictable memory requirements. B. Fixed Coordination Models In tuple-space languages, much of the complexity of coordination remains entangled with the functionality of computational elements. An encapsulating coordination formalism decouples intercomponent interactions from the computational elements. This type of formalism can be provided by fixed coordination models in which the coordination style is embodied in an entity and separated from computational concerns. Synchronous coordination models coordinate activity through relative schedules. Typically, these approaches require the coordination protocol to be manually constructed in advance. In addition, computational elements must be tailored to the coordination style used for a particular system (which may require intrusive modification of the software elements). The need remains for a design and programming methodology that allows for coordination between software elements without tailoring the software elements to the specific coordination style used in a particular software system. Summary of the Invention The present invention provides a coordination-centric design and programming methodology to facilitate both the design and the debugging of software systems. This approach includes an encapsulating formalism for coordination. In accordance with the present invention, coordination protocols are embodied in coordinators. Coordinators serve to expose the workings of a coordination protocol and organize relevant system information in a meaningful manner. This facilitates coordination- based debugging by letting designers focus on coordination as an entity separate from computation and by showing designers what is happening internally within a software system. In accordance with the present invention, functional blocks, or software elements, are represented as components. Components contain modes that define behaviors, actions that perform these behaviors, and coordination interfaces that connect components to other components through coordinators. Packaging software elements in this fashion provides more modularity for the components than prior art design and programming methodologies. Coordination interfaces make both the data and control aspects of intercomponent interactions explicit, so that the control and data interactions can be adapted to a variety of interaction protocols without needing internal modifications to the components. The same coordination interface type can be used by a variety of components. Any component in a software system can be replaced by a new component having completely different functionality without any other components within the system needing to know that a change has been made, as long as the new component has a coordination interface appropriate for the coordinator in the software system. Both components and coordinators can be composed hierarchically to form higher-order functionality and interaction protocols. This facilitates design complexity management. All pieces of the coordination-centric design methodology work together to provide both the software designers and the debugging tools with information about the software system's behavior and the behavior of the software system's components. This information serves to simplify software system design and software system debugging. The coordination interfaces expose control state and message traffic to scrutiny by software designers and debugging tools. Meanwhile, coordinators expose interaction protocols to scrutiny by software designers and debugging tools. In accordance with the present invention, the coordination-centric design methodology treats design and debugging as interrelated issues and, as a result, makes complex embedded software more debuggable and more easily designable. Debugging in fact dominates embedded system software development time, and the debugging approach of the present invention facilitates the debugging of complex embedded systems and makes other aspects of the design flow, such as managing

Claims: design complexity and reusing software, easier than in prior art design and programming methodologies. Additional aspects and advantages of this invention will be apparent from the following detailed description of preferred embodiments thereof, which proceeds with reference to the accompanying drawings. Brief Description of the Drawings Fig. 1 is a component in accordance with the present invention. Fig. 2 is the component of Fig. 1 further having a set of coordination interfaces. Fig. 3 A is a prior art round-robin resource allocation protocol with a centralized controller. Fig. 3B is a prior art round-robin resource allocation protocol implementing a token passing scheme. Fig. 4 A is a detailed view of a component and a coordination interface connected to the component for use in round-robin resource allocation in accordance with the present invention. Fig. 4B depicts a round-robin coordinator in accordance with the present invention. Fig. 5 shows several typical ports for use in a coordination interface in accordance with the present invention. Fig. 6 A is a unidirectional data transfer coordinator in accordance with the present invention. Fig. 6B is a bidirectional data transfer coordinator in accordance with the present invention. Fig. 6C is a state unification coordinator in accordance with the present invention.

Inventors: HINES KENNETH J, HINES, KENNETH, J.
Applicants: CONSYSTANT DESIGN TECHNOLOGIES, HINES KENNETH J, CONSYSTANT DESIGN TECHNOLOGIES, INC., HINES, KENNETH, J.
Application year: 2001
Main classification: G06F9
IPC codes: G06F9, G06F11