Object oriented model of parallel programsHenryk Krawczyk, Bogdan WiszniewskiFaculty of Electronics, Technical University of Gdansk, ul.Narutowicza 11/12, 80-952 Gdansk, PolandAbstract In this paper the object oriented model of control ow in parallel systems is pre-sented. It builds upon strong intuitive understanding of traditional control ow graphs ofsequential programs. The model is object oriented, what makes it suitable for a variety ofapplications including re-engineering of the existing code, simulation and modelling, parallelprogram design, testing and quality assessment. It also enables integration of several methodsand techniques from di�erent areas of computer science with special emphasis on the �nalsoftware product quality. In it's current form, the model has been adopted for the testingtool being developed for the Copernicus Software Engineering for Parallel Processing (SEPP)European programme.Keywords: object-oriented modeling, reverse engineering, parallel programming1. IntroductionImplementing a parallel application program is not more di�cult today than implementing asequential application program in Pascal about twenty years ago. The evolution that broughtthe world of parallel processing to a simple programmer has been made possible by introducingthe inherent parallelism of modern programming languages, use of computer networks and wideacceptance of modular programming standards. When it comes to the development of largerand more complex programs, however, developers are confronted with the complexity barrierof an unprecedented scale. It has been characterized by Winter and Kacsuk as the problemspace consisting of three dimensions: software design, hardware topology and program map-ping, while sequential software design is just a one dimensional problem space [23].The aim of this paper is to investigate an object oriented model of parallel programs in adistributed memory environment that is aimed at reducing complexity in dealing with parallelsoftware. The presented model enables integration of well-known methods and concepts fromseveral areas of computer science in order to better understand a structure of existing parallelsystems, and then provide a framework for improving their quality by re-engineering the code:� Parallel programming languages and environments . Analysis of arbitrary complex communi-cation structures of parallel systems has been made e�ective by distinguishing a few common,well de�ned interprocess communication patterns. These patterns are common to all classesof parallel programming languages [1], but using them in our model requires a modular pro-gram design.� Static program analysis . Analysis performed on the model can determine points of possiblesynchronization, identify actions occurring in parallel, detect inherent synchronization er-rors, analyze paths and evaluate conditions controlling their executions. Algorithms one may1
apply to the model include static concurrency analysis [22], path �nding [21], and symbolicinterpretation [9].� Finite state machines . Ordering of actions in the model is described by simple automatain a quite standard way, based on the classic notion of a global system state [13]. We haveeliminated the problem of state explosion by utilizing the concept of sum machines andby encapsulating interprocess communication in objects that model communications events.Techniques that can be applied to these objects deal with test case design for parallel pro-grams [18] and their reproducible execution [20].� Object oriented analysis and modeling . Information extracted from a rich and complex par-allel system code is transformed within the model into well-de�ned objects, attributes andrelationships in order to assess quality, verify and possibly modify the formalized systemrepresentation to improve a target system quality.� Reverse engineering . Although any parallel program written using the model of interprocesscommunication of one language can be transformed into a program using a mechanism of an-other language [8], some program fragments that are easy to describe using the mechanism ofone can be di�cult to describe using the mechanism of another. The model enables programsource code transformations from one language to another. It is also possible to simulateand experiment with alternative program structures that may be better for another language.� Quality metrics . The model enables application of various metrics developed for sequentialprograms [5, 14], because it builds on the intuitive view on a sequential program structureinvolving its control ow graph, nodes, arcs, operators, operands, etc.Figure 1 shows the main idea of the re-engineering process. Based on the source code weattempt to build the abstract program model in order to use it for generating a new, higherquality source code. Throughout the rest of the paper we present the model of a parallelsystem, characterize attributes and relationships of its objects, illustrate possible model im-plementations in C++, and introduce the concept of encapsulated communication events. Wewill demonstrate them with an example PVM program. With the model being developed inthis report we will be able to address a wide range of quality issues related to parallel systems.These issues involve two basic problems. One is a systematic selection, execution and eval-uation of test cases. Another is quality assesment in software manufacturing. We deal withtesting of parallel programs in [10], while in Section 5 of this paper we present some basic soft-ware quality measures and show the evaluation procedure to illustrate the model's suitabilityfor quality assesment.The open problem not addressed in this paper is how to re-design parallel programs to im-prove their complexity. Simple substitution of one construction objects by other constructionobjects may be just one step towards a better program design. Finding the better layout ofobjects in the �nal program structure is the another step towards that goal. In our view thissecond step will have to involve simulation on the underlying model in order to allow a user toget better understanding of alternative program structures. By adopting the object orientedapproach for our model we provide a framework for such a simulation.2
Abstract
Program
Model
old
source
code
library of
construction
objects
new
source
code
reverse engineering program re-design
Figure 1: Object-oriented re-engineering2. Objects in parallel systemsA control ow graph [6] has been in use by programmers as a structural model of a programsince the advance of procedural programming languages. By drawing a control ow graphfor a given program one can get insight into the control ow and data ow issues avoidingthe unnecessary detail of the underlying programming language syntax. Flowgraphs provide aconvenient abstraction for evaluating program quality and for generating tests.A control owgraph uses two basic kinds of objects: processing nodes , representing a se-quence of assignment statements, and decision nodes , representing points in a program atwhich the control ow can diverge. Program executions are represented in this model as pathsgoing through nodes of the corresponding control owgraph. Normally, control owgraphs areintended to model individual sequential programs.In the case of parallel systems consisting of component sequential programs, a set of ow-graphs has to be considered. This representation, however, is more di�cult to grasp by aprogrammer, since many paths may be followed in a system in parallel. Moreover, some spe-ci�c nodes of component owgraphs may correspond to communication statements that dependon one another. In order to capture that it is required to extend the notion of a owgraph.One possible extension is the Petri net model [16], with a number of tokens representingcontrol ow of component processes as they progress through the system [13]. Unfortunately,analysis of a Petri net seems to be more abstract to programmers than the intuitively simpler owgraph, and requires a great deal of formalism.Another extension is the model based on �nite state machines [12]. A single owgraph maybe viewed as a �nite state machine (FSM) with states corresponding to this owgraph's nodes.A parallel system can be represented then by a product machine with a set of states beinga Cartesian product of sets of states of all component machines. Although FSMs seem to beintuitively close to owgraphs with respect to the ability of representing serial executions ofprogram statements, the usual problem of state explosion makes the realistic analysis of prod-uct machines impossible. 3
class Node {
int K; // no of exits
label exit[];};
public: int N; // no of entries
label entry[];
N
K
...
... Figure 2: Multiple-entry multiple-exit graph nodeIn our model we aim at retaining the intuitive simplicity of owgraphs, but also want tocapture the ability of Petri nets to represent multiple ows of control, as well as provide anFSM-like mechanism for ordering program statements related to state transitions.A owgraph with multiple ows of control requires graph nodes which form a special class ofobjects allowing paths of many programs to go through selected nodes in parallel. Any objectof such a class has in general multiple entries and multiple exits, as shown in Figure 2, alongwith its speci�cation in C++.Nodes may be connected to one another. i.e., each exit of any node may be connected tosome entry of another node; we mark this in our model by labeling each exit with a label of theentry this exit is connected to. Labels of entries are unique, i.e., there are no two entries withthe same label at any node. In general there is no precedence of connected nodes, as one nodemay be connected to many nodes by the respective entries (exits). Entries of a single node maybe associated with di�erent ows of control, therefore each node may be entered in parallel bymore than one program. After leaving that node many nodes may be visited in parallel sinceexits of a single node may also correspond to di�erent ows of control.Visiting of nodes by ows of control in sequential programs is intended normally to representexecution of program statements (processing nodes) or evaluating predicates (decision nodes).These statements are either assignment statements or conditional statements . Nodes in ourmodel re ect that fact by associating two types of expressions with node exits. One is a'conditional-statement', and another is an 'assignment-expression' written accordingly to theunderlying programming language syntax. Both classes of nodes are shown in Figure 3.Objects from the assignment and conditional classes of nodes allow for multiple ows ofcontrol to enter and/or exit them in parallel. At each entry of a single node from either class ows of control cause the evaluation of the respective expression. Note, that an entry in somenode not connected to any preceding exit of some other node represents a start point in arelated sequential program control ow (process creation point). Similarly, an exit in somenode not connected to any following entry of some other node represents an end point in arelated sequential program control ow (process termination point). Exits of nodes from eitherclass that correspond to termination points of respective processes may also have assignmentor, respectively, conditional expressions to be evaluated there.If assignment or conditional nodes do not require multiple ows of control, then they corre-spond to ordinary nodes of sequential control ow graphs, as shown in Figure 4.Multiple ows of control constitute just one feature of nodes in parallel program owgraphs.4
};
class Assignment: public Node { public: string expression[]; // ’assignment-expression’
};
public:class Conditional: public Node {
string predicate[]; // ’conditional-expression’
...
...
...
...
Figure 3: Nodes with annotated exits};
class Expression: public Assignment { public: const int N, K; // initialized by constructor to 1
};
public:class Decision: public Conditional {
const int N; // initialized by constructor to 1Figure 4: Nodes with single ow5
class FSM;
public Assignment { private: FSM set[]; // internal protocol machines};
class CommunicationEvent: public Conditional,FSMFSM ...
...
... Figure 5: A node encapsulating communication events...
class Thread { private: Node *nodes[]; // points to Nodes visited by Thread}; Figure 6: A single control owAnother feature is the interaction of ows at selected points of component programs, what isdue to communication statements. Owing to this feature, a node allowing for many ows toenter in parallel its entries may provide some internal "processing" of ows in order to determinewhat particular ows can exit this node. Therefore such a class of nodes has properties of theconditional node. It also has properties of the assignment node, since interaction of ows mayresult in some data objects (values) being transferred in between ows. This class of nodes isshown in Figure 5.Internal processing of control ows is performed by �nite state protocol machines, determin-ing a speci�c order of executing communication actions involved in the corresponding event.This encapsulation of interprocess communication in the form of communication events hasbeen made possible by the modular design of parallel programs, when processes can communi-cate with one another only through a well-de�ned set of interface points. We will address thisissue in the next Section.Based on the classi�cation of nodes developed so far one can view a set of sequential pro-grams running in parallel as a set of interconnected instantiations of the node class objects. Itwill be useful, however, to group all ows of control through such a system of nodes into threadsrepresenting individual processes; a single thread object collects information on all nodes it'scorresponding process can go through, as shown in Figure 6.Finally, a set of threads models a parallel system, as shown in Figure 7.There is yet another class of nodes related to the multiple ow of control, limited however,to some "local" extent; we model them as block objects, as shown in Figure 8.Classes of objects characterized in this Section require further de�nitions, in particular con-structors, as well as some application functions, e.g., virtual int *step(int *), representingthe abstract node execution by indicating for the pointed node object entries which of it's exitsto follow next. Since the base node class cannot provide su�cient information on the node6
.
...
.
.. . .
...class MultiThread { private:
}; Thread system[]; // componentsFigure 7: A system of multiple control ows
public:
private:
};
Node *split[]; // points first Nodes
class Block: public Expression {
Node *join[]; // points last Nodes
Block(MultiThread&); // convert into BlockFigure 8: A block of multiple control owsdetails except that what entries and exits of each node are connected to entries and exits ofother nodes, it is assumed to be an abstract base class and no constructor is needed at thisabstraction level. For the same reason function step() has to be declared in the base nodeclass as a pure virtual function. At lower levels of the hierarchy of nodes respective versions ofthe step() function will have to be rede�ned with regard to internal details of each particularnode class.This is a template solution to a variety of problems one may want to investigate with ourmodel. The step() function may simulate the execution of each node, while respective con-structors and destructors may handle dynamic creation and killing of processes [11]. In thispaper we focus only on this model's application to re-engineering existing source code. In ourapplication problem related to the PVM platform [23] we use the standard Taylor's algorithmfor static concurrency analysis [22]; it uses tokens to represent control ows in each compo-nent process. Tokens advance through analyzed programs and are used to identify matchingcommunication statements. These statements are grouped, their respective protocol machinesidenti�ed in the supporting library of objects, and communication event node objects �nallycreated. Statements for process creation (termination) in PVM are modelled by the assignmentclass objects with respective node entries (exits) not connected. Other statements correspondto simple decision or expression class objects. We create these objects and connect node entriesand exits using a simple parser generated by YACC; it labels all respective statements in eachanalyzed component program and then builds component control ow graphs by connectingrespective entries and exits of all created node objects.In order to apply this approach to re-engineering of existing code a virtual step() functionhas to be implemented to be able to interpret (in various languages) the expressions annotatingindividual exits of the hierarchy of node class objects. While interpretation of conditional andassignment expressions in procedural languages is a rather simple task, the analysis of com-7
munication events in general is not. Owing, however, to the object oriented approach outlinedin Figure 1 and the encapsulation of communication events this problem may be realisticallyhandled by a programmer. We address this issue in the next Section.3. Encapsulation of communication eventsParallel systems are usually viewed as sets of event-driven activities associated with individ-ual programs called processes . Processes de�ne basic interconnected components of a systemand are viewed as independent units that communicate through a set of well de�ned interface"access points". Interface between parallel system components involves synchronization andexchange of data. Rules for communicating processes are established by protocols , which con-trol ordering of selected events. Implementation is aimed at expressing speci�ed system units(processes) and their interface in terms of a selected programming language and the language'sunderlying interprocess communication model.The important fact about modern parallel programming environments is that they stronglysupport modularization. Access to data objects of cooperating processes is possible only byusing standard operations on the respective interface points, and these operations are providedby the supporting environment speci�cally for that purpose. Using of such operations is usuallyunder strong control of the environment. One example is Ada, where a small set of interprocesscommunication primitives is a part of the language and is totally controlled by the compiler.Another example are Unix based C programs, where communication of cooperating processesis not supported by the language compiler, but the operating system remains in full control ofany communication event. This aspect of modularization has important rami�cations for ourmodel.Based on the assumption that processes are independent modules communicating throughservice access points, and physically distributed, one may distinguish nodes in a system con-trol ow graph that are associated with "internal actions" of individual processes from nodesassociated with "external actions" dealing with interprocess communication. Relative orderingof nodes associated with internal actions belonging to di�erent threads of control is thereforeirrelevant, as these objects are truly independent.On the other hand, external actions dealing with interprocess communication involve rela-tively small subset of system threads. Moreover, for any single external action (access point) inany process there is just one speci�c protocol associated with this action; any such action canalways be associated through the corresponding protocol with a speci�c set of external actions(access points) of other system processes. We call a set of such actions a communication eventand model it by node objects de�ned in Figure 5.Actions associated with the same communication event node object, forming a group or-dered by the corresponding protocol have to assure that the transfer of data objects in betweenprocesses conforms to semantic rules of the corresponding communication statements. Ac-tions from di�erent events are independent, since they manipulate di�erent data objects whichare associated with separate access points in component processes. Therefore, communicationevent node objects cannot in uence each other's ordering of actions. The same applies to inter-leaving internal actions with external ones; internal actions are able to a�ect relevant control ows to visit particular entries of communication event node objects (for example actions en-capsulated by decision node objects) thus select a particular FSM upon each entry, but cannota�ect ordering of actions within individual protocol machines. Owing to this, numerous combi-nations of interleaving external actions that belong to di�erent events, as well as combinations8
of interleaving external and internal actions is in most cases irrelevant for analysis.This encapsulation of protocol machines eliminates the problem of combinatorial explosionif the parallel system is viewed as a collection of automata, since it constitutes in our approacha sum of protocol machines of all communication event node objects and respective FSMsrepresenting component processes. A sum machine is much simpler to analyze and understandthan a product machine mentioned before, and it's set of states is of smaller cardinality, i.e.,as of the union of component processes' states rather then the Cartesian product of such sets.The key point in modelling interprocess communication with communication event nodeobjects is to assure, that no single communication action of any component process may beassociated with more than one entry of any node object. This requires correct speci�cation of�nite state protocol machines that govern the ordering of actions in the related communicationevent node object. Consider the following de�nition of the class of protocol machines:class FSM fpublic:FSM(label *event, int protocol no);private:struct transition fint *from;label action;int *to;g;int *Q; // current statetransition P[]; // possible transitionsg;A protocol machine has exactly one initial state, de�ned as a vector of node entries, andexactly one �nal state, de�ned as a vector of node exits. Internal states (transitions) have tobe de�ned with respect to the semantics of communication statements from the supportingimplementation environment. This is why this class constructor has two arguments. The �rstone, event, indicates the list of actions labeling relevant entries (while entries' numbers refer tothe initial state), of which the particular FSM has to be constructed. The second argument ofthe FSM constructor, protocol no, identi�es the FSM template in the library of constructionobjects (as shown in Figure 1) that has to be used for construction from the indicated actionlabels.Careful analysis of application protocols in various parallel programming environments in-dicates that the number of such template machine is reasonably low. For example, typicalnetwork oriented application platforms based on message passing, like TCP/IP [3] or PVM [4]distinguish two types of communication statements for sending: one is point-to-point, when asingle process sends a single message to some other process, and another is broadcast, whena single process sends a single message to a group of processes. Communication statementsfor sending may be either blocking or non-blocking. The blocking send forces the sender towait until receiver is ready to read a message being sent, while the non-blocking send puts themessage to some bu�er regardless of the state of the receiver. TCP/IP provides both types ofthe send communication statement, while PVM just the non-blocking one.There are also two types of communication statements in TCP/IP and PVM for receiving: in9
a blocking and non-blocking modes. In either mode, a receiver may want to receive a messagefrom a speci�c sender or just any sender.This de�nes three basic classes of application protocols: one-to-one, many-to-one, one-to-many. If we distinguish blocking and non-blocking send statements, as well as blocking andnon-blocking receive statements there are twelve kinds of protocol machines in total.Note, that the number of internal states in any machine of one of the kinds characterizedabove is usually one per each respective pair of "matching" communication statements. Eachsuch internal state may be simply labeled as "communication engaged", and for which thereis only one preceding state and one successor state, being respectively initial and �nal states.The set of internal states of all protocol machines in a given communication event node ob-ject determines all possible sequences of communication actions constituting the correspondingevent.These sequences are important for planning and executing reproducible tests [20], if ourmodel is to be used for simulation; they also guide the user willing to substitute one protocolby another protocol in some communication event node object. This information is essential ifone is doing reverse engineering involving parallel programming languages with di�erent com-munication models and di�erent protocols.4. A big exampleConsider the following example of a parallel program consisting of three processes: a refereeand two players, who play a game similar to black jack. Players are sending bids to the refereeby selecting an arbitrary number from 1 to 9. The referee waits for bids from each player, andupon receiving the bid is added to the score. The score is initially set to zero. The �rst playerinitiates the game by sending it's �rst bid to the referee. The referee updates a score and sendsit to the second player. Bids are being sent until the score reaches 100. The referee noti�es thewinner, kills both players and terminates.#include <stdio.h>#include "pvm3.h"/* process REFEREE *//* #=0 */ /* REFEREE starts here *//* #.1: #.2 */ main()fint mytid;const int nproc = 2; /* no of players */int tids[2];int s msgtype, r msgtype;int numt;int player;int score, bid;mytid = pvm mytid();s msgtype = 200;r msgtype = 201;/* start players *//* #.2: #.3 */ numt = pvm spawn("player",(char **)0,0,"",nproc,tids);/* #.3: #.4 #.5 */ if (numt < 2) 10
/* #.4: */ fprintf("...cannot start players");pvm exit();exit(1);g/* REFEREE code *//* #.5: #.6 */ score = 0;/* send PLAYER 1 it's no */player = 1;/* #.6: #.7 */ pvm initsend(PvmDataRaw);pvm pkint(&player,1,1);pvm send(tids[0],s msgtype);/* send PLAYER 2 it's no *//* #.7: #.8 */ player = 2 ;/* #.8: #.9 */ pvm initsend(PvmDataRaw);pvm pkint (&player,1,1);pvm send(tids[1],s msgtype);/* #.9: #.10 */ printf("...starting the game.");/* #.10: #.11 #.21 */ while(score < 100)/* receive bid from PLAYER 1 *//* #.11: #.12 */ fpvm recv(tids[0],r msgtype);pvm upkint(&bid,1,1);pvm upkint(&player,1,1);/* check new score *//* #.12: #.13 */ score += bid;/* #.13: #.14 #.15 */ if (score >= 100)/* #.14: #.21 */ printf ("...and the winner is %d !",player);/* send score to PLAYER 2 *//* #.15: #.16 */ else fpvm initsend(PvmDataRaw);pvm pkint(&score,1,1);pvm send(tids[1],s msgtype);/* receive bid from PLAYER 2 *//* #.16: #.17 */ pvm recv(tids[1],r msgtype);pvm upkint(&bid,1,1);pvm upkint(&player,1,1);/* #.17: #.18 */ printf("...referee has %d from player %d.",bid,player);/* check new score again */score += bid;printf("...score is now %d",score);/* #.18: #.19 #.20 */ if (score >= 100)/* #.19: #.21 */ printf ("...and the winner is %d !",player);/* send score to PLAYER 1 *//* #.20: #.10 */ else fpvm initsend(PvmDataRaw);pvm pkint(&score,1,1);pvm send(tids[0],s msgtype);gg 11
g/* terminate players *//* #.21: */ pvm kill(tids[0]);pvm kill(tids[1]);/* stop REFEREE */pvm exit();return(0);g#include <stdio.h>#include "pvm3.h"#define CONSOLE "dev/tty1"#define s msgtype 201#define r msgtype 200/* process PLAYER #. *//* #=1,2 */ /* start PLAYER #. */main()f/* #.1: #.2 */ FILE *in, *out;int referee, player no;int mytid;int score, bid;mytid = pvm mytid();/* know the REFEREE */referee = pvm parent();/* #.2: #.3 */ pvm recv(referee,r msgtype);pvm upkint(&player no,1,1);/* PLAYER 1 starts the game *//* #.3: #.4 #.9 */ if (player no == 1)/* #.4: #.5 */ fout = fopen(CONSOLE,"w");in = fopen (CONSOLE,"r");bid = 0;/* get bid *//* #.5: #.6 #.7 */ while(!((bid > 0) && (bid < 10)))/* #.6: #.5 */ ffprintf(out,"...initial bid from PLAYER 1 ?");fscanf (in,"%d",&bid);g/* #.7: #.8 */ fclose(out);fclose(in);/* send bid to REFEREE *//* #.8: #.9 */ pvm initsend(PvmDataRaw);pvm pkint(&bid,1,1);pvm pkint(&player no,1,1);pvm send(referee,s msgtype);g/* infinite loop */12
/* #.9: #.10 */ while(1)/* current score from REFEREE *//* #.10: #.11 */ fpvm recv(referee,r msgtype);pvm upkint(&score,1,1);/* #.11: #.12 */ out = fopen(CONSOLE,"w");in = fopen(CONSOLE,"r");fprintf(out,"...score is %d;",score);bid = 0;/* get bid *//* #.12: #.13 #.14*/ while(!((bid > 0) && (bid < 10)))/* #.13: #.12 */ ffprintf (out,"...bid from PLAYER %d ?",player no);fscanf (in,"%d",&bid);g/* #.14: #.15 */ fclose(out);fclose(in);/* send bid to REFEREE *//* #.15: #.9 */ pvm initsend(PvmDataRaw);pvm pkint(&bid,1,1);pvm pkint(&player no,1,1);pvm send(referee,s msgtype);ggLines of this example source code are aligned to correspond to the individual owgraphsof component programs. The left column of the text consists of comments corresponding tothe adjacency matrix of each respective owgraph. Note, that assigment statements have beenaggregated to minimize the size of presented graphs.A multithread object corresponding to this example parallel program is presented in Figure9. It consists of three threads, with the middle one representing the referee. Note, that nodeobjects not involved in creating processes nor in any inteprocess communication belong to justone thread; such objects in one thread are independent from their counterparts in other threads,and they are connected as ordinary owgraph nodes. There is one node object involved in cre-ating two players by the referee (entries 0.2, 1.1, and 2.1), and six communication event nodeobjects involved in communication between the referee and a single player; these nodes arethe access points to the related processes. No other interaction between processes is possibleexcept these access points.5. Quality re-engineeringSoftware quality can be evaluated throughout the entire software life-cycle even after the soft-ware has been released to the user. The metrics that a�ect software quality can be categorizedin three broad groups [17]. The �rst group addresses product transition and can be directlymeasured and expressed by portability, reusability and interoperability. The second grouprefers to product operations, that is measured indirectly but can be described by correctness,reliability, e�ciency, integrity and reusability. The third group focuses on the product revisionand can be determined by maintainability, exibility and testability. It is di�cult to developdirect measures of all quality factors, but we assume, that the software quality factor Q can13
1.13
1.121.15
1.14
1.131.12
1.14
1.12
1.11
<1>1.111.10
0.E
0.21
0.19
0.4
0.11
0.210.100.20
0.190.200.18
0.110.12
1.51.4
0.18
1.1
1.2
1.2
1.3<1>
0.1
0.2
0.3
0.2
0.30.4 0.5
1.6
0.E0.5
0.6
2.2
2.1
2.32.2<1>
0.6
0.7
0.8
0.7
0.80.9
1.31.9 1.4
2.32.4 2.9
2.42.5
2.62.5
2.7
0.90.10
0.101.8
<1>
2.6
<2>
0.21
<1>
2.52.72.8
1.71.5
1.61.5
1.7
2.9
1.8
1.9
1.15
1.9
1.101.9
0.13
0.12
0.130.14 0.15
2.11
2.100.14
2.112.12
0.17
2.92.10
2.8
2.12
0.21 0.16
0.15
0.160.17
<1>
2.14
2.12
2.92.15
2.13
2.13
2.152.14
Figure 9: A multithread of players14
be described by the following expression of various metrics:Q = aXi=1wi �mi = aXi=1 biXj=1wij � fij (1)wheremi means the i -th metric which can a�ect the quality factor Q with weight wi,a is the number of quality metrics,fij means the j -th factor which can a�ect the i -th metric with weight wij.In practice each metric can be expressed by various other factors. Let bi means the numberof factors describing the i -th metrics, and wij means coe�cients connected with this metricfactors. Then Q can be described by a new formula shown as the right part of expression (1).To evaluate factor Q we should know the relationships between quality metrics and qualityfactors and the grading scheme for all factors. There is no precise method how we can do this.Moreover, the existing methods are product dependent (program, packet, tool), its applications(real-time, long life etc.), even its function. Therefore it is very important to identify only thekey factors. It can be done individually by a suitable decision maker or by averaging varioussurvey responses collected from designers and/or users [2].Existing standards can also play important role here [7]. However, the degree to which formalstandards and procedures are applied to the software engineering process varies from companyto company. Therefore we concentrate below only on the limited set of metrics, strictly con-nected to reusability, productivity, testability and maintenance, quite important in reverse andre-engineering processes. We will attempt to show their relations to other quality factors.Reusability metrics inspect on such factors as generality (the breath of potential applicationof program components), hardware independence (the degree to which the software is de-completed from hardware on which it operates), modularity (the functional independence ofprogram components), selfdocumentation (the degree to which the source code provide mean-ingful documentation), and software independence (the degree to which the program is inde-pendent of nonstandard programming language, operating systems characteristics and otherenvironmental constraints).Productivity is a power of being productive. It means an increase of e�ciency and the rateat which software is produced. In other words productivity improvement leads to reduction ofsoftware development time, costs and risks. It is correlated with software complexity (or thedi�culty to design) and software maturity (or the readiness of a software product).Testability means e�ort required to test program to ensure that it performs it's intendedfunctions. This is strictly connected with test bed and test case design. The test bed is anenvironment containing the hardware, instrumentation, simulators, software tools and othersupporting elements needed for tests. The test case is a set of test input, execution conditionsand expected results developed for a particular objective such as to exercise a particular pro-gram path or to verify compliance with a speci�c requirement.Maintainability means the ease with which a software system or component can be modi�edto correct fault, improve performance or other attributes, or adopt to a changed environment.It is strictly connected with extendibility (the ease with which a system or component can bemodi�ed to increase its storage or functional capacity), and exibility (the ease of modi�cationfor use in applications or environments other than those for which it was originally designed).15
The intuitive de�nitions of the above described metrics are independent of the type of soft-ware being considered. However, to introduce the factors corresponding to them we shouldprecise what kind of software we deal with. In the case of parallel software we have to givenew de�nitions because majority of well-known metrics [19] addresses only sequential software.Again we restrict our consideration to just one metric. As an example we will analyze com-plexity factors which are strongly related to the metrics presented above. We will start ouranalysis from classic de�nition and then adopt it to parallel software. The object of this anal-ysis is a source code (C with PVM or TCP/IP) or the abstract model presented so far. Weassume then a concrete source program to be presented by our "object-oriented" owgraphG(jOj,jEj), where O is the set of objects from our hierarchy of node classes, where each nodeobject represents sequential groups of instructions of a source code, and E represents a set ofarcs showing data and control ows (arcs) between the corresponding pair of nodes. Based onthis we may evaluate a few complexity measures of parallel programs.One complexity measure in simply the related program length L, expressed by KLOC (noof thousands of code lines). Most of controversy swirls around the use of lines of code as acomplexity measure. Proponents claim that it can be easily counted or predicted. Opponentsclaim that it is language-dependent and is not suitable for non-procedural languages. Someestimations of program length were given by Halstead [5], in the following way:L = N1 +N2 � n1log(n1) + n2log(n2) � log2((n1)!) + log2((n2)!) (2)whereN 1(n1) is the number of occurrences of (distinct) operations in a program,N 2(n2) is the total number of occurrences of (distinct) operands in a program.In the case of the C programming language operands and operators are well de�ned andcan be easily calculated by our parser. In the case of our model the operators are representsby nodes, but operands are not visible from outside the node objects. Operands may be thenrepresented by node entries and node exits.Based on our object oriented graph we can de�ne also another complexity measure for parallelprograms based on the concept well known for sequential programs, which is the McCabe factor[14]; it is normally calculated as C =j E j + j O j +1 (3)wherejEj is the number of edges in a program graph, andjOj is the number of nodes in a program graph.If maximum strongly connected subgraphs are represented by single nodes, measure C isequivalent to the graph cyclomatic number, and it is called cyclomatic complexity [7]. For atypical sequential module it is assumed that C=10 represents a maximum ideal complexity.For a complex system the cyclomatic number may be larger. If it is too large, modularization ofcode is required. For parallel program a number of abstraction levels should be considered. Forexample, one may calculate �rst the complexity of each existing object node, and then based onthe graph of interconnected node objects, the complexity of the entire system of programs maybe determined as the longest (weighted) path in the graph of interest, where weights represent16
the complexity of distinct nodes belonging to this path.A more adequate approach seems to be using a generalized static complexity. It is a measureof software as represented by a network of modules and resources, used storage, processors,and input/output devices. Resources are acquired or released when a program runs by goingfrom one node to another. It is desirable to measure the complexity associated with such anallocation of resources in addition to the basic complexity evaluated; we obtain:C = jEjXi=1(ci + jRjXk=1 dk � rki) (4)wherejRj is the number of resources (for example number of processors),ci represents complexity for program invocation and return along each edge ei as determinedby the user,rki is the element of resource status array A(jRj,jEj) set to 1 if the k -th resource is requiredfor the i -th edge, or to 0 otherwise, anddk is the weight describing the complexity of allocating the k -th resource. In this way onecan combine the complexity assessment with the mapping problem.Dynamic complexity is a measure of a parallel program represented by its graph during exe-cution, rather then at rest, as in the case of static measures. A change in the number of edgescan result from module interruption owing to invocations and returns. An average dynamicnetwork complexity can be divided over a given period of time to account for the execution ofthreads at di�erent frequencies and also for module interruption during execution. Dynamiccomplexity is calculated using the formula for static complexity at various points of time. Wecan determine the mean value for such period of time. This measure is generally higher thanstatic complexity. Ideally it should be as close to the static complexity as possible. If the dy-namic complexity is large, one should consider reducing it by optimizing the dynamic creationand detection of threads or by minimizing task interruptions by timing adjustments, or both.In such case the special monitoring tool is necessary.6. ConclusionsWe have presented a new object oriented model of parallel software, where the program isdescribed as a modi�ed owgraph. Speci�c nodes represent fragments of sequential compu-tations. Important feature of this model is the encapsulation of interprocess communicationinto node objects. Owing to this, the internal program computations and control ow is moreunderstandable and visible for a user; this is very important from the designing (re-designing)point of view.Classes of nodes speci�ed here can be implemented in any object oriented language to pro-vide a design database. The entire program design process can be then visualized by graphdrawing using prede�ned objects. During program design the related quality issues can behandled by a programmer towards improving quality factors by re-designing program structurerepresented by the model.In the paper we indicate that quality factors for parallel programs cannot be determined bytraditional formulas used for sequential programs. We have suggested some modi�cations forcomplexity factors, being aware that this is just the �rst step towards more systematic quality17
assessment of parallel programs.Tools supporting quality assessment based on our model are currently being developed withinthe SEPP framework [23]. Their application to the existing commercial parallel software willprovide us with important evidence what are the required modi�cations to the existing qualityfactors. It will also be interesting to see how this object oriented approach to re-engineeringcomplex commercial systems can realistically contribute to improve their quality.References[1] Andrews, G.R., Schneider, F.B.: Concepts and notations for concurrent programming.Computing Surveys 15, 3-43 (1983).[2] Beck, L.L, Perkings, T.E.: A survey of software engineering practice: tools, methods, andresults. IEEE Trans. on Software Eng., SE-9, 541-561 (1983)[3] Comer, D.: Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture,2nd ed., Prentice-Hall, New Jersey, 1991.[4] Geist, A., et al.: PVM 3 users's guide and reference manual. Oak Ridge National Lab,Oak Ridge, Tennessee, 1994.[5] Halstead, M.H.: Elements of Software Science. New York: Elsevier North-Holland, 1977.[6] Hecht, M.S.: Flow Analysis of Computer Programs. North-Holland, 1977.[7] IEEE Standard Dictionary of Measures to Produce Reliable Software. Std. 982.1.1988.[8] Kasai, T., Miller, M.: Homomorphism between models of parallel computations.J.Comp.Syst.Sci., 25, 285-331 (1982).[9] Khanna, S.: Logic programming for software veri�cation and testing. The Computer J.34, 350-357 (1991)[10] Krawczyk, H., Wiszniewski, B.: Systematic testing of parallel programs. Tech. Rep. 3/95,Faculty of Electronics, Technical University of Gdansk, Gdansk, Poland[11] Krawczyk, H., Wiszniewski, B.: Design for testability of parallel programs. Accepted forthe Software Quality Conference SQC95, 4-5 July, 1995, Dundee, U.K.[12] Lynch, N.A., Fischer, M.J.: On describing the behavior and implementation of distributedsystems. Theoretical Computer Science 13, 17-43 (1981).[13] Mazurkiewicz, A.: Concurrent program schemes and their interpretations. DAIMI Rep.PB-78, Aarhus University, 1977.[14] McCabe, T.J.: A complexity measure. IEEE Trans. Software Eng., SE-2, 308-320 (1976).[15] Perry, W.E.: Quality Assurance for Information Systems. Methods, Tools and Techniques.QED Tech. Publishing Group, 1991 18
[16] Peterson, J.: Petri Net Theory and the Modelling of Systems. Prentice-Hall, EnglewoodCli�s, N.J., 1981.[17] Pressman, R.S.: Software Engineering: A Practitioner's Approach, McGraw-Hill Interna-tional Editions, 1992.[18] Sarikaya, B., Bochmann, G., Cerny E.: A test design methodology for protocol testing.IEEE Trans. Software Eng., SE-13, 518-531 (1987).[19] Symons, Ch.R.: Software Sizing and Estimating. John Wiley & Sons, 1993.[20] Tai, K.C.: Reproducible testing of concurrent Ada programs. Proc. 2nd Conf. on SoftwareDevelopment Tools, Techniques and Alternatives, San Francisco, U.S.A., 114-121 (1985).[21] Tarjan, R.E.: A uni�ed approach to path problems. Journal ACM 28, 577-593 (1981).[22] Taylor, R.N.: A general purpose algorithm for analyzing concurrent programs. Comm.ACM 26, 362-376 (1983).[23] Winter, S., Kacsuk, P.: Software engineering for parallel processing. Proc. 8th Symp.on Microcomputer and Microprocessor Applications, 12-14 October, Budapest, Hungary,285-293 (1994).
19
