A net method for specification of reusable software

Abstract

A method, called the N&Method. has been developed for specifying software components based on Petri nets. Using two types of nodes and three types of connectors, five primitives of the specification method have been constructed. Only these five primitives are then used as building blocks to specify software. Although the Net Method was originally designed for software components, it has been found to be particularly suited for specifying systems that have a number of parallel processes and require the synchronization of a number of activities. A graphics editor for the Net Method has been implemented and a Net simulation package is under development. l.~Hiah~pfSoftware~&u&&y 1 Reduction in the cost of software production through software reusability has been an aim of software producers for quite some time. Reusability efforts have come a long way with many different paradigms being used for the production of reusable software components [I, 6,8,10]. However, the concept of “mass produced software components” remains a long way off since, among other problems, the problem of functional specification of software components still looms large. 2.I!rQddwPfReusableSoftware This paper tackles only the problem of functional specification of functionality of reusable software components, irrespective of the model that was used for their development. However, for the sake of clarity and for ease of giving examples we would like to keep the paradigm of Ada packages and call the software components Logical Software Units (LSUs). This paper assumes that LSUs will come off-the-shelf in a standardized certified form and will have customization capability within a given functionality. 3. Development ef a &t@cation Method for Reusable Software Specification methods can be categorized under two broad headings: (a) Those that have a mathematical formalism as their base and use some type of algebraic notation. (b) Those that have a graphical notation whether they have a mathematical foundation or not Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice IS given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specdic permission. V. Shteru Metropolitan College Boston University Boston, MA 02215 We would lie to develop a specification method belonging to the second category because we wish to follow the paradigm of the Sears’ catalog in providing the user with hierarchically arranged information on the huge number of LSUs that, we hope, will be available on the market at some future date. The LSU catalog will have a pictorial functional description of the LSU at a high level of abstraction (like pictures of tires in a Sears’ catalog) followed by one or more levels of description in increasing detail just as tire specifications, other than price and size, are given removed from the picture of the tire. Existing methods of graphical specification [4, 5.9, 1 l] suffer from one or more of the following drawbacks: (a) They are geared either towards representation at the architectural level of detail or towards representing details at the coding level without the ability to specify interactions at all levels of abstraction. (h) They do not make a distinction between au active choice and a passive choice and thereby mask the identity of the activity participant that makes the decision. An “active choice” is a decision made by a participant of an activity; a “passive choice” is made by default for other participants of the activity as a result of the active choice. (c)They do not distinguish between sequential activities and those activities that are independent and can be carried out in parallel, but are often carried out sequentialty because of limitations of resources. The &t Method of specification that we have developed addresses these issues and is due largely to the work of Holt and Commoner [2,3] which in turn is based on the work of Petri [7]. 3.1 Elements oJ the SDecification M&Q.~ The elements of the specification diagrams are: entities, activities and connectors (fig. 1). Entities participate in system activities and the relationships between these two elements are shown by directed connectors. These form directed graphs in three dimensions which are system space, time and choice. 0 El Entity Activity 1 ,t /“J Lifeline co~ector Activity connector Choice connector (Along time axis) (Along space axis) (Along choice axis) Fig. 1 Elements of the Specification Method 3.2 The Five Primitiva af & Snccification Method Using the elements of the specification method, five primitives of the specification method have been developed. Only these five basic representations combined in various ways, are needed to express the functional specifications of LSUs. Although we do not offer a proof of this 01989 ACM O-89791-305l/89/0500/0137$00.75 137 sufficiency, we make this statement on the basis of our considerable experience with the Net Method. 1. Sequential Activities are joined by verticaI connectors (Fig. 2). The figure shows an entity A which is transformed by activities 1,2 and 3 and then leaves the system.