a methodology for architectural design of concurrent and distributed software systems

The Journal of Supercomputing, 37, 227–248, 2006C© 2006 Springer Science + Business Media, LLC. Manufactured in The Netherlands.

A Methodology for Architectural Design ofConcurrent and Distributed Software Systems

HASSAN REZA [email protected]

School of Aerospace Sciences, University of North Dakota, Grand Forks, North Dakota, 58202, USA

Abstract. Concurrent and distributed software applications are complex software systems that exploit highly

parallel and distributed infrastructure to improve the quality of systems in cost-effective way. In order to assist

the development of affordable concurrent and distributed software systems, a more effective approach of

utilizing single-based architectural description languages (ADLs) is needed. In this paper, we describe an

architectural modeling framework that can be used for specifying and analyzing distributed and concurrent

software applications. Our key contribution is an architectural specification framework that integrates four

important concepts: (1) an architectural description language known as syntactic theory (ST), (2) a high

level Petri nets modeling language known as Hierarchical Predicate Transition Nets (HPrTNs), (3) a Pattern-

Based Refinement Technique (PBRT), and (4) a systematic process for deriving architectural specifications

from requirement specifications. Moreover, the method is heterogeneous modeling approach that specifies

software architecture of a distributed and concurrent system in a top-down manner. The immediate benefits

of our heterogeneous approach include: increased system analyzability, comprehensibility, reusability, and

flexibility. We describe a case study to show the applicability of our approach.

Keywords: concurrent and distributed systems, software architecture, architectural description languages

(ADLs), petri nets, design patterns, HPrTN patterns

1. Introduction

Almost all large and complex systems demand the use of highly concurrent and dis-tributed software architecture because without parallel and/or distributed software, par-allel hardware is of limited use. The required feature of concurrent and distributedsystems is that they must allow information (data and control) to be disseminated overa set of independent components serving both remote and local applications operatingon the same (or different) hardware platforms concurrently. This feature, in turn, al-lows faster and more dependable systems. Examples of distributed and concurrent soft-ware systems include: data-intensive systems, which include centralized, distributed,parallel, or federated-database systems; computationally-intensive systems, which in-clude grid computing and bioinformatics systems; and event-intensive software sys-tems using middleware, which include mobile computing and network monitoring sys-tems, and virtual environments that demands highly concurrent and distributed systems[36].

A constant issue in the engineering of the complex systems is how to mange the designcomplexity. The complexity issue is continuously tackled by enhancing the existing soft-ware models, or by shifting toward new paradigms and techniques (e.g., object orientedtechniques). In the past decade, researchers in software engineering community have

228 REZA

emphasized heavily on the importance of software architecture and its formal modelingnotations [4, 11, 24, 26, 29] because they believe that software architecture providesmultiple views of a system in which design qualities such as analyzability (performanceand behavior), security, reusability, flexibility or reliability may be investigated early onin the software lifecycle.

In the simplest form, software architecture describes a system in terms of its com-ponents (i.e., computational units), connectors (i.e., communication protocols), con-straints (i.e., rules), and configurations (i.e., overall structures). Current approaches tospecifications and verifications of software architecture utilize formal modeling lan-guages known as Architectural Description Languages (ADLs) [24]. However, the keylimitation associated with these approaches is that they are single-based modeling for-malisms. As such, they can be applied to describe only one dimension of a system.But software architecture of a complex system is a multi-dimensional entity in whicheach dimension separately models a specific aspect of a system. For example, onemodel may be used to represent the static behaviors (structure or syntax) of a sys-tem while another model may be used to represent the dynamic aspects (semantics)of the same system. Therefore, to effectively document and model all needed infor-mation and complexity linked to complex systems, a mixture of formalisms is needed[18].

Little attempt has been committed to the methods for systematically deriving architec-tural specifications from requirement specifications. More precisely, the method shouldprovide some kind of guidelines regarding which structuring principles should be em-ployed in order to help the architect at different points in the design process, whichproperties to model, and how to model those properties. Lack of systematic processand guidance is inconsistent with the objective of software architecture, which has beenrecognized to have a great positive impact on the accomplishments of non-functionalproperties such as security, performance, flexibility, extensibility, etc.

One possible approach to specifying architecture of a concurrent and distributed soft-ware system graphically and rigorously which provides a method for reusable, andextensible architecture-based specification is to integrate architectural description lan-guage proposed by Cordy and Dean [6] (syntactic theory in sequel) and a high class ofPetri nets [25] modeling notation known as Hierarchical Predicate Transition nets [14](HPrTNs in sequel) proposed by He [14].

The syntactic theory abstracts out operational details and provides a specification,which states only what something does without saying how it does it. An abstract ar-chitecture obtained by the syntactic theory is an inter-connected set of typed elements(or architectural types) such as components and connectors where the specificationof components and connectors reveal nothing about their implementation. Further-more, an abstract architecture can only be used to specify the structure (static view)of a system and cannot formally be evaluated due to the lack of underlying semantictheory.

The Petri net theory has been used for specifying and verifying the semantics ofhighly concurrent and distributed systems [25]. In addition to modeling the semanticsof a system, Petri net formalism has also been used for modeling and analyzing of thequality attributes (or non-functional requirements) of a system such as performance[33], security [34], etc. HPrTNs are modeling notations with much wider modeling

ARCHITECTURAL DESIGN OF CONCURRENT AND DISTRIBUTED SOFTWARE 229

capabilities based upon the well-established theoretical foundation of Petri nets, andrelated analysis techniques to perform simulations and verifications. The developmentof HPrTNs was motivated by the need to model specifications for large and complexsystems in Petri nets, and it is inspired by the development of modern high level pro-gramming languages and other hierarchical and graphical notations such as data flowdiagram [30] and Statecharts [12]. As such, HPrTNs can be used to model the concretearchitecture by relating the behaviors of the system to the behavior of the sub-systems(components) regardless of the style in which the architecture might be implemented.This in turn will provide a context in which architectural conformance testing can becarried out [31].

Therefore, graphical modeling notations (ST and HPrTNs) with defined syntactic andsemantics theories together with the process for deriving architectural description fromrequirements specifications can be helpful for representing precisely the fundamentalaspects of the component and communication organization of concurrent and distributedsystems that use architectural styles, mapping between different levels of abstractions,and pattern-based refinements.

2. Related work

A great number of ADLs have come from industrial and academic research. Their maingoal is to help architects with notations having precise semantics together with a set ofsupporting tools which can be used to describe and analyze either a family of relatedsoftware systems known as architectural styles or customized toward specific applicationdomain known as domain specific software architecture [13]. Aesop [4], Darwin [17],Wright [2], Rapide [20], SRI’s SADL [23], CHAM [16], and C2 [21] are among the mostclassical works with heavy emphasis on specifying and analyzing architectures basedon single modeling notations. The main problem with these works is that single-basedarchitectural description languages are not expressive enough to capture all details andcomplex information associated with complex systems. Therefore a blend of modelingnotations is needed.

Closer in spirit to our work is the research conducted by Medvidovic et al. [8]. Theyboth have discussed a heterogeneous modeling technique. Their work is based on theintegration of UML with C2 [8]; their main incentive to integrate ADLs and UMLis to take advantage of wide spread usage of UML and its supporting tools. How-ever, the approach can not be scaled up toward concurrent systems because its un-derlying ADL, C2SADEL, is based on first order predicate logic, which is not pow-erful enough to model concurrency and dynamic features associated with complexsystems.

This work has also been influenced partly by the research in, pattern based refinementproposed by Moriconi et al. [22] and middleware-independent design by Verdickt et al.[35]. In [22], their work is based on the integration of SADL with first order predicatelogic (FOPL) to define and refine software architecture of a system. In [35], they proposeda framework that can be used to model a generic middleware that can be transformed toconcrete middleware using a middleware model repository; the performance models of

230 REZA

a system, which are based on the extended UML, then can be derived from the concretemodels.

3. Hierarchical predicate transition nets (HPrTNs)

HPrTNs [14] are powerful specification methods with well-defined semantics and havebeen applied to specify and verify both the static and dynamic semantics of inherentlyconcurrent and distributed software systems at low level of abstraction [14, 15].

Definition 1 A hierarchical predicate transition net is a six-tuple HPrTN =(P, T, F, ρ, SPEC, INSC) where

(1) P is a finite set of Predicates;(2) T is a finite set of Transitions;(3) F is a finite set of flow relations such that F ⊆ (P × T ) ∪ (T × P);(4) ρ is a hierarchical mapping and is defined from P ∪ T → ℘(P ∪ T );(5) SPEC is an algebraic specification, and is defined by a tuple (S, OP, Eq) in which S

and OP is called signature; S is a set of Sorts and OP = (Ops1, . . . ,Sn , s) is a set ofsorted operations for s1, . . . , sn, s ∈ S. The S-equations in Eq define the meaningsand properties of operations in OP. Furthermore, SPEC is used to define the tokens,flow annotations, and transitions post and preconditions (constraints/contracts) ofan HPrTN;

(6) INSC is net inscription and is defined by a tuple (ϕ, L , R, M0) in which ϕ is a sortmapping that associates each p ∈ P with subsets of sorts in S; L is a label mappingthat associates each f ∈ F with a label; R is a constraint mapping that associateseach t ∈ T with a first order logic formula; and M0 is a mapping from the set ofpredicates P to the set of tokens, and is called the initial marking.

While HPrTNs have been shown to be effective methods for describing a system atspecification level, they do not fit in ADLs scheme mainly because they demand detaileddesign information that may not be available at architectural level. Additionally, theydo not support directly architectural constructs such as components, connectors, andtheir composition.

4. The diagrammatic syntactic theory (ST) and architectural styles

A formal syntactic theory proposed by Cordy and Dean [6] describes individual systemsin terms of architecturally significant elements such as components, connectors, andcompositions. It does that by supporting a set of simple graphical notations modelingarchitectural features, a set of “well-formedness” rules, and a set of operations (e, g.,interface operation).

Definition 2 A formal syntax will be used as a framework within which the semantics ofindividual elements and complete system may be founded. A system is a tuple (Elements,Types, Connection) where


(1) Elements is a tuple (N , C, M S, V ) in which N is the set of components in thesystem; C is the set of connectors in the system; MS is the set of message sites; Vis the set of variables in the system;

(2) Types is a finite set of types used to specify system elements;(3) Connection is a tuple (src, dst, has, msg) in which src ⊆ N × C is a set of binary

relations to model the source of binary connectors; dst ⊆ N × C is a set binaryrelations to model the destination of binary connectors; has ⊆ N × M S is a set ofbinary relations to associate message sites with components; and msg ⊆ M S × Cis a set of binary relations to associate message sites with message connectors.

In addition, the syntactic theory provides several abstraction rules, patterns for group-ing and matching elements, and a set of well-formedness rules. We have also extendedthe syntactic with architectural constructs such as typed interface points, and a set of ar-chitectural constraints. Figure 1 shows the architecture of a canonical compiler in ST. Inthe figure, files and memory tables (or passive components) are modeled by single-linedrectangular, and double-lined rectangular respectively. Circles are representing tasks oractive components (e.g., parser), and arrows representing various interactions amongcomponents [6].

In figure 1, broken arrows model memory access connectors, and solid arrows modelstream connectors. The sets of Read (or Write) specify the type of access betweendifferent phases of a compiler. For example, in figure 1, Lexer reads from source file usinga unidirectional connector C1 and sends its results to Parser using stream connectors

Figure 1. Architecture of a canonical compiler.

232 REZA

C2. The Src and Dst relations are used to specify the composition mechanism. In thefigure, <Source, C1> and <Lexer, C1> can be used to connect the Source Code file withthe task Lexer.

We adopted the model because it is a formal diagrammatic notation that can beintegrated easily with a graph-based semantic framework such as Petri nets and is capableto provide a solid foundation upon which the dynamic behavior of individual elementsas well as an entire system can be based. Furthermore, the model enables a softwareengineer to design software architecture of a system that can be composed of many smallcomponents structured in a hierarchy.

5. Design patterns (Elements of reusable specifications)

Software design patterns try to document those recurring problems, solutions, togetherwith the contexts in which they can be used. They provide us with terminologies torepresent and to transfer a family of proven design solutions [10]. This, in turn, willresult high quality and cost-effective systems with expected behaviors. Design patternsare also important strategies for refining the elements of software architecture becausethey represent high-level specification abstractions of practical experience, which aresmaller than architectural style and are applicable in specific context because they areindependent of the overall architectural principle.

In general, if design patterns are selected wisely, then they can tie the designer to aspecific view of a problem. In [22], they showed how a component of one pattern couldprogressively be refined by some other patterns into relatively correct lower level design.

5.1. HPrTN Patterns

HPrTN patterns are formal specification patterns similar to formalized object orienteddesign patterns in [32] and share the same objectives as informal object-oriented designpatterns do: they aim to identify, document and transfer the body of proven design andspecification knowledge in the Petri nets domain. For instance, there exists an exten-sive body of recurring problems and specification solutions based on Petri nets. Someexamples include known Petri nets synchronization problems such as Reader/Writer,Producer/Consumer, Dining Philosophers, Cigarette Smokers, or specification exam-ples and problems such as Library, Elevator, Gas station, etc.

The important implications of HPrTNs patterns are twofold: (1) they may influencethe applicability of Petri nets in an engineering community where there is a lack ofinterest in applying and thus adopting Petri nets for systems design and evaluation;(2) reuse of already tested and hence reliable software artifacts such as a segment ofcode is perceived as a key to improving the production of high quality software systemsbecause reuse offers incentive to prevent and eradicate errors earlier in the life cycles[11]. Therefore, by capturing design expertise based on Petri nets in the form of HPrTNpatterns, we are creating reusable and mathematically founded composable abstractionswhich raise the abstraction level above the abstraction facilities defined in HPrTNs andtherefore enable a designer easily to grasp concepts conveyed by patterns.


Definition 3 HPrTN patterns are a finite set of patterns, PT = {pt1, pt2, . . . , ptn}. Apattern pti ∈ PT is a 3-tuple <TEMPi , HPrTi , BDESi > where

(1) TEMPi is a pattern template and is a seven-tuple <Namei , AlsoKnowni , Examplei ,Contexti , Solutioni , KnownUsesi , Variantsi> as follows:

• Namei : Refers to a descriptive name that is used to identify a pattern uniquelysatisfying the following property: ∀pti , pt j ∈ PTi �= j → pti �= pt j ;

AlsoKnowni : Refers to other names that can be used to refer to the same pattern;

• Examplei : Sample example of a pattern;

• Contexti : Refers to the delineation of conditions under which a pattern can beused and may include some background discussions to justify the existence ofthis pattern;

• Solutioni : Refers to informal descriptions (or main idea) used to implement thepattern;

• KnownUsesi : Refers to other patterns that have been used to implement thispattern or various way to customize this pattern;

• Variantsi : Refers to enhanced and/or modified version of this pattern.

(2) HPrTi is an HPrTN specification of the pattern, and it consists of three fields:

• A finite hierarchical net structure NETi (p, T, F, ρ) to depict the structural ele-ments of a pattern;

• An algebraic specification SPECi includes a finite set of sorts, a finite set ofsorted operations together with the properties of those operations. Words suchas alpha or beta in SPEC are used to denote the undefined sorts; they can specifyuser-defined types or simple types such as integer;

• A net inscription INSCi (ϕ, L , R, M0) associates the various text strings (e.g.,Boolean expressions) to the elements of net structure such as predicates, transi-tions and flows.

(3) BDESi is a detailed informal description of pattern behaviors. The description Mayinclude the discussion regarding related patterns, other patterns used to implementthis pattern, and design consequences.

In the above pattern description, INSC and SPEC can be used to describe the structuraland behavioral properties of a pattern in more generic form.

5.2. Pattern instantiation

Pattern instantiation allows a modeler to implement a concrete element (connectorsor components) by instantiating a pattern and binding sort parameters to actual sortswithout introducing any new predicates (conditions) or transitions (events) to the existingelements of a pattern. More precisely, instantiation operates only on the generic elementsof a pattern template, namely, algebraic specifications (SPEC), which define operationsover a set of sorts and constrain the behavior of the operation by a set of axioms or facts.

234 REZA

A sort, like a type, is a finite set of values. Operations dictate how to build, alter anddistinguish values of the sort. The axioms define equivalence sets of values in the sort.

A mapping mechanism that works as theory morphism maps the generic orparameterized sorts together with sorted operations to actual sorts and operations ofthose sorts in such a way that the axioms of the HPrTNs pattern are still valid theoremsunder the instance of that pattern. More specifically, an HPrTN pattern acts very muchlike parameter theory and the instance of that pattern acts like a target theory [7],[9]. Aparameter theory (i.e., HPrTNs pattern) is then instantiated by a theory morphism (i.e.,a mapping that replaces each generic part of algebraic specification with actual value)to create the target specification corresponding to the instance of the HPrTN pattern.

Definition 4 (Pattern instantiation): Given a pattern pt ∈ PT, N is an HPrTN and isan instance of pt if and only if the following conditions satisfy

(1) ∀pi ∈ pt.HPrT.Net.P, ∀p j ∈ N.P • pi �= p j (i.e., the instantiated predicate name isunique.);

(2) ∀ti ∈ pt.HPrT.Net.T, ∀t j ∈ N.T • ti �= t j (i.e., the instantiated transition name isunique.)

(3) ∀fi ∈ pt.HPrT.Net.F, ∀f j ∈ N.F • fi �= f j (i.e., the instantiated flow name is unique.)(4) ∀vi ∈ V ∃si ∈ S •Binds (vi , si ), where V is a finite set of generic (or undefined)

sorts; S is a finite set of sorts; and Binds: S × V → Booleans is a function that bindsa specific sort to a generic sort.

Conditions 1–3 together indicate that the instance of a pattern must be different froma pattern itself. In addition, condition 4 states that all parametric (generic) sorts musteventually be defined and replaced by sorts that are more specific [27].

5.3. Pattern specialization

Pattern specialization allows a modeler to create a new pattern or to tune the existingones to meet different requirements. The specialized pattern is created by instan-tiating an HPrTN pattern according to the architectural type (i.e., components andconnectors specifications) modeled by syntactic notations. More precisely, specializa-tion allows introduction of predicates and/or transitions, and works mainly on struc-tural parts of a pattern in order to create a new pattern that handles a particularrequirement.

5.4. Pattern composition

Pattern composition allows a modeler to create a new pattern by composing the existingones. For example, two parallel patterns might be composed to form a Counterpointpattern. The great convenience of structural patterns comes from the ways that patternscan be composed to form larger structures. According to their forms, patterns can bedivided into primitive patterns (basic ones used mainly as building blocks) or composite


patterns (also known as user defined). Composite ones can be used to specify complexfunctionality or a complex protocol, so it is possible that it will be modeled by a set ofpatterns.

Pattern composition may require both pattern instantiation and/or specialization and issimilar to generic modeling techniques discussed by Ehrig et al. [9]. In general, patternscan be composed vertically and horizontally. Vertical composition composes patternsin hierarchical manner by chaining together a series of correct patterns located on thebottom of the hierarchy, providing the finale that the most concrete and hence fine-grained patterns in the hierarchy are correct with respect to the most abstract and hencecoarse-grained ones are located on the top of the hierarchy. The standard technique forreasoning about the relative correctness of two specifications, which is to show that therelative concrete pattern logically implies the abstract pattern, can be adopted towardthe relative correctness of two patterns.

Horizontal composition is used to compose instances of refined patterns (micro-patterns) to create one large composite refinement pattern (macro-pattern). The im-portant consideration when composing patterns horizontally is the correctness of acomposition or the process by which patterns are composed. Once patterns are com-posed correctly, their composition can be used repeatedly. By correctness of a com-position, we mean if a fact about a pattern is not explicitly specified or inferred inthe pattern, then this fact is not intended to be true of a pattern in the composi-tion. This is a focus of completeness assumption initially discussed by Moriconi etal. [22]. For example, in composing two patterns, say, P and Q, if P prohibits cer-tain accesses by some elements in this pattern, then this property must be true in thecomposition.

In general, the pattern composition must preserve general properties of the composingpatterns in a way that the properties of the composed pattern may be deduced from theproperties of individual patterns [27]. Petri nets may be composed: (1) transition-fusions,(2) place-fusions, (3) arcs (or flows).

As discussed in [28], the main benefit of transition-fusions is the simplicity by whichthe system can be analyzed by preserving essential properties when nets are composed.However, the common implication in composing nets using transition-fusion is thatthe nets are very strongly coupled. For example, it is not feasible to think about a netas a modeling of an independent process having its own initial marking because it isvery difficult to establish locally whether a transition is enabled or not. In addition, thecomputational agreement of the nets is very difficult to recognize because their internalbehavior is combined with their interactions with other nets, which makes it impracticalto identify explicitly which net initiates a communication.

Composition of nets via place-fusions corresponds to the nets composition by sharingof variable (predicate), which demands an additional synchronization between the nets.Lastly, composing nets via arcs (flows) provides the lowest coupling and it correspondsto a message passing communication paradigm in which an arc from a transition to aplace is called “message sending” while an arc from a place to a transition is called“message taking” [5]. This type of composition can be implemented by merging placesif they communicate in one direction, meaning that net may either send or receive tokensin these places (i.e., merged places).

236 REZA

5.5. Pattern based refinement technique (PBRT)

Pattern Based Refinement Technique (PBRT) replaces one or more elements of HPrTNspecification with pattern specialization, instantiation, or composition. PBRT progres-sively refines each super node (or refining node) of HPrTNs by a subnet that might bean instance of HPrTN pattern (or refined net). The requirements associated with suchpatterns should match the objective (or goals) under consideration (i.e., refining node).The instance of such a pattern, then, can be used directly or tuned to define (implement)an architectural type (i.e., graphical notations used as component specifications by syn-tactic theory). Furthermore, the refined nodes must adhere to the following refinementrules:

(1) The interface of a refined net must be all predicates if a refining node is superpredicate;

(2) The interface of a refined net must be all transitions if a refining node is a supertransition;

(3) There must be a one-to-one correspondence between a data flow into a refining nodeand an incoming non-terminating arc in refined node;

(4) There must be a one-to-one correspondence between a data flow out of refining nodeand an outgoing non-terminating arc in a refined node;

(5) There must be a one-to-one correspondence between the type of data carried by adata flow into a refining node, and the type of data carried by an incoming non-terminating arc in a refined node;

(6) There must be a one-to-one correspondence between the type of data carried by adata flow out of a refining node and the type of data carried by an outgoing non-terminating arc in a refined node.

Like object oriented design patterns, HPrTN patterns have the potential of being usefulin both developing new designs, and as an aid in understanding existing Petri net designs.This work attempts to document the earlier usage; the latter usage will become moreevident and imperative as time goes on.

The typical step for reuse of HPrTNs patterns assumes a repository of patterns. Thesesteps are:

(1) Retrieve a candidate set of HPrTN patterns that approximates and/or corresponds tosome needed capability;

(2) Select the pattern from the candidate set that most strongly matches the specificrequirement(s);

(3) Instantiate and/or customize the selected pattern to all aspects of the specificrequirement;

(4) Add the customized pattern to the repository as a candidate pattern for future reuse.


6. The methodology

To exploit the notations as a framework for specifying and evaluating the systemproperties, we use a simple mapping technique to translate an abstract architecture de-fined in syntactic theory to the well-established formal model represented by HPrTNs.We then use Pattern Based Refinement Technique (PBRT) to specify the internal struc-ture of architectural elementals modeled by HPrTNs. PBRT uses a set of patterns calledHPrTN patterns. To integrate the extended syntactic theory with the strengths of HPrTNs,we have developed and employed a process that first maps the element of a system mod-eled by syntactic theory to HPrTNs or vice versa as faithfully as possible. The processcan be characterized by carrying out the following steps:

Step 1: Create repository of common Petri net patterns: (1) identify Petri net patterns(pattern mining); (2) Document these patterns in HPrTNs using the format proposedby Shaw and Garlan [11], or Gamma et al. [10] (pattern codification).

Step 2: Specify abstract architecture (i.e., the structure of architecture), based on appli-cation requirements, in syntactic theory as follows:

(1) Select an architectural model (architectural style or DSSA [13]) from candidatearchitectures using system properties (such as performance, reliability, security,privacy, etc.) or design properties (such as extensibility, flexibility, etc.).

(2) Use functional requirements (or external behaviors) and the context where theSoftware might be used to identify software components and their interfaces. Forinstance, organizations units, modules, tasks, processes and physical equipmentsthat demonstrate high degree of cohesion and minimum degree of coupling arepossible candidates for subsystems. In cases where an entity has some degreeof dependency on other entities to fulfill its required functionality, it should beperceived as a component which will be combined with other components to forma subsystem.

(3) Use non-functional requirements to identify candidates for software connectorsand their interfaces.

Step 3: Validate the architectural description defined in previous steps. By that, we meanverify if architecture is well formed according to its constraints. Constraints on thesets and relations describe well formedness. Thus, a system is a well-formed systemif and only if these constraints satisfy for the model of the system. These constraintsfall into three groups [6].

Step 4: Define the behavior of an architecture which means assign semantics to theelements of architecture defined in step 2 by mapping each individual architecturalconstruct such as components and connectors to the elements of HPrTNs defined in[27].

Step 5: Refine the element of HPrTNs obtained in the previous step using Pattern BasedRefinement Techniques (PBRT).

Step 6: Review the specification to see if all application requirements have been satisfiedfor the target system. This may require going back to previous steps to include correct-ness, completeness, and consistency as well as deadlock, livelock, and safety proper-

238 REZA

ties. Consistency (no contradiction) and completeness (description contains sufficientinformation) are central themes to architectural analysis because without them, noneof the other analyses (e.g., scenario-based methods used for evaluation of softwarequality or task scenarios realized abstract quality attribute by series of refinement toconcrete attribute) possible. For instance, style inconsistency (constraints defined onthe style contradict each other or to model a system that cannot be implemented) canbe detected if we have architectural constraints such as:

(1) ∀c ∈ C • c ∈ RepAcc → c ∈ Write;(2) (2) ∃c ∈ C • c ∈ RepAcc ∧c ∈ Read

Condition (1) states that all system connectors are repository access having only “Write”attributes, and condition (2) states that there exists at least one connector with only “Read”attribute. There is a contradiction because no connector can have both read and writeattributes.

In summary, the above process allows us to specify rigorously architecture of a systemby integrating the wide variety of models supported by Cordy and Dean [6] and HPrTNs[14], alleviating the limitation of both modeling languages in the progression.

7. Case study: A repository system

In this section, we show how our architectural framework can be used to represent avariation of Blackboard architectural style known as a Repository System [11, 29]. Atypical Repository architectural style consists of a set of specialized and autonomoussystems (ASs), a central repository component and a controller connector that connectsthe repository component to the rest of the systems (i.e., ASs). Each autonomous systemis specialized in solving a particular task and normally does not maintain any signif-icant amount of information. Instead, each posts its partial solution to the repositorycomponent. The repository component is a subsystem that retains a significant amountof shared information that is accessible by all of ASs, via a controller connector. Acontroller connector is a communication unit that is driven by combination of transac-tion types, the access mechanisms, and the form and the meaning of information (e.g.,messages, signals, or data) exchanged between repository component and ASs.

In what follows, we outline a primary set of constraints (or requirements) that arepository system must satisfy:

(1) An autonomous system may be developing independently from each other;(2) An autonomous system is capable of performing a task in isolation;(3) The environment of an autonomous system refers to anything outside of a compo-

nent;(4) The autonomous systems interact with repository unit using controller connector;(5) The autonomous systems are not allowed to interact with each other directly;(6) There is no predetermined sequence for autonomous systems to invoke;(7) Any autonomous system requesting access to the repository should eventually

receive the accessing result correctly;


(8) A read access requires the autonomous system sending a request message to therepository and the repository responding with a message that contains the data;

(9) A write access requires sending a message containing the data to be written tothe repository and the repository responding with a confirmation message that thewrite request has taken place;

(10) Concurrent writing requests to the shared data maintained by Repository subsystemshould be disallowed;

(11) When there is no pending writing request to the shared data, an arbitrary numberof reading requests should be allowed.

Figure 2(a) depicts a repository architectural pattern. Figure 2(b) depicts an instanceof that pattern in syntactic theory. In that figure, autonomous systems representing the

Figure 2. Repository style and instance of a system in that style.

240 REZA

computational elements are modeled by tasks shown by circle and the SharedData isused to maintain all data needed by autonomous systems and it is modeled by memorycomponent (nested rectangles). The dashed polygon in that figure models a subsystemthat provides communications between ASs and the repository subsystem (SharedData).The procedure call connectors are employed to satisfy the request/reply requirementbecause an important property of a procedure call connector is that it would guarantee thatevery message sent by any requesting side is eventually received by the receiving side andthat the result is delivered correctly to the requesting side. The shared memory connector(SMC) is used to implement the requirement pretending to the access coordinationto the shared data. A task (LNK) is a super transition, which models an overlappingcomponent that links procedure call connectors to the shared memory access connector(SMC).

Using heterogeneous abstraction1 [6] for connectors in syntactic theory, we can thenreplace the dashed polygon shown in Figure 2(b) to obtain a composite connector con-troller shown in Figure 3. A composite connector controller works as a single connector.The repository system shown in the Figures 2 and 3 represents only the structural (orsyntactic) aspects of a system. It does this by showing the type of components andconnectors.2 As a result, it does not specify how computations and communications areimplemented.

In what follows, we describe the steps of an algorithm for syntactic-to-semantic map-ping. We will employ a Repository system, shown in Figures 2 and 3, to illustrate themapping steps as follows:

Step 1: Create abstract HPrTN specification of the system that corresponds to the abstractsyntactic architecture as follows:

Figure 3. The abstract syntactic architecture of the Repository system using heterogeneous abstraction for

connectors.


• Memory (or data storage) elements are considered active elements and henceare mapped to the transitions in HPrTNs. In a case where a memory elementrepresents a nodal subsystem,3 a super transition can be used instead;

• Task (or processing) elements are considered active elements and thus are mappedto the transitions in HPrTNs. In a case where a task represents a nodal subsystem,a super transition can be used instead;

• Connector elements are considered passive elements and thus they are mappednaturally to the predicates in HPrTNs. In a case where a connector element rep-resents a connector subsystem (i.e., composite connector), a super predicate canbe used instead;

• A set of binary relations (src, dst, has, msg) models the connections in syntacticnotations. The set of binary relations can be used to derive flows in HPrTNs. Morespecifically, for any pair of relations, say, r1 and r2, we drive two flows, namely,f1 and f2 satisfying the following condition: ∀r1 ∈ scr∀r2 ∈ dst • (∃c ∈ C • r1[2]4

= c ∧ c = r2 [2]) where scr ⊆ N × C ; dst ⊆ N × C ; C is a set of connectors;and N is a set of nodes f1 connects an HPrTN node corresponding to the task inr1 to the another HPrTN node corresponding to the connector element in r1. f 2connects an HPrTN node corresponding to the connector that is common in bothr1 and r2 to the node corresponding in dst;

• Data type attributes of the connectors specify the type of data such as messages,signals, and strings that can be passed (received) to (from) the connectors. There-fore, they can be used to derive a set of sorts S (i.e., types) in HPrTNs.

• Connect the predicates and transitions obtained in previous steps with flows.

• Annotate each flow with appropriate labels based on sorts (i.e., S) to show theproper flow of the data.

In our case, using the above steps, we can create the top level HPrTN specificationshown in Figure 4.

Step 2: Create low level (or concrete) HPrTN specification of the system using the con-crete syntactic architecture. In our example, using the concrete syntactic architecture,we further decompose the elements of a system shown in Figure 4. More specifi-cally, using this step, we decomposed the connector subsystem, controller, into itsconstituent elements such as procedure call connectors and a shared memory connec-tor together with a task LNK that enables them to exchange data and messages (seeFigure 5).

Step 3: Review the HPrTN specification obtained in previous steps for possible equivalentstructure. An equivalent HPrTN structure can be obtained by merging duplicatednodes. Appropriate tokens and/or labeled flows are used to capture the informationabout those repeated nodes [7]. Figure 6 shows the equivalent HPrTN specificationthat obtained by merging three repeated autonomous systems (AS1, AS2, and AS3),and three repeated procedure call nodes (i.e., PC1, PC2, and PC3) into one supertransition AS and one super predicate PC respectively.

Step 4: Refine elements of concrete HPrTNs specification using Pattern Based Refine-ment Techniques (PBRT). In our example, using PBRT, we progressively refine theelements of concrete HPrTN specification shown in Figure 6.

242 REZA

Figure 4. The top level HPrTNs specification.

Figure 7 shows the refinement of nodes in Figure 6 by subnets that correspond tothe instances of HPrTN patterns. Figure 7(a) shows the refinement of AS1, which is aninstance of Loop Pattern consisting of two elementary states denoted by predicates P1and P2 respectively and two elementary transition T 1 Figure 7(b) shows the refinementof LNK, which is a super transition consisting of two elementary transitions representedby transitions T 5–T 6. Figure 7(c) shows the refinement of SharedData, which is aninstance of Loop pattern consisting of two states denoted by predicates P12–P13 andtwo elementary transitions T 9 and T 10. Figure 7(d) shows the refinement of SMC, whichis an instance of Shared Memory Connector Pattern. The internal structure of SMCconsists of four states denoted by predicates P8–P11 and two elementary transitionsT 7–T 8. Figure 7(e) shows the refinement of PC based on the semantics of procedurecall using Procedure Call Connector pattern. The internal structure of PC consists of fivestates denoted by predicates P3–P7 and two elementary transitions T 3 and T 4.

Finally, in the underlying specification of the Repository system SPEC = (S, OP, Eq):

(1) S represents a set of sorts (or types). It is derived from the information represented atsyntactic level, namely, MSG, which includes a set of all messages, and Data, whichis a set of all values. At syntactic level, MSG and Data represent coarse-grained (oruninterrupted) information, which will be refined into fine-grained at concrete level.Thus, S includes elementary sorts such as Integer and structured sorts such as AID,CID, MID, TYPE, and DATA. The sort AID is derived from Integers and is usedto uniquely identify the autonomous systems. The sorts MID and CID are derivedfrom Integers, and they identify uniquely messages and the logical channels to which


Figure 5. Refinement of controller.

Figure 6. The equivalent HPrTNs specification.

these messages are belonged. The sort TYPE specifies the type of the messages; thepossible types are R REQ, W REQ, R REP, and W REP where R REQ specifies aread request and R REP specifies a read respond. Similarly, W REQ specifies a writerequest and W REP specifies a write respond. Finally, the sort DATA represents allpossible data items are accessed by the users.

(2) OP includes standard arithmetic and relational operations, and projection operationon tuples. We used the tuple notation t[i] (i.e., the ith component of tuple t) to denotethe attribute extractions.

244 REZA

Figure 7. The refinement of the nodes.

(3) Eq includes known properties of the above operations. The net inscription INSC= (ϕ, L , R, M0) can be defined straightforwardly and is omitted here due to spacelimitation.

At early stage in the life cycle of a complex system, architecture is most likely immatureand needs to go through extensive customization and/or augmentation in order to providethe level of “completeness” expected for application domain. Therefore, extensibility,which is a simple way to change the system’s capabilities in amount, but not in kind ofarchitecture, is essential to guarantee suitable accommodation of new requirements andfeatures. In general, extensibility and flexibility5 are perceived as high level changes andrelated to adaptability of a system [12]. One benefit of our model is that it is extensible:new requirements can be added by simple alterations to the SPEC. As an example ofextensibility, we incorporate the standard model of security policy proposed by Bell-LaPadula model [19] and discussed in the architecture of a secure system by [48]. Themodel presumes a set of subjects, each having an attached security clearance level aswell as a set of objects, each having an attached classification level. More specifically, themodel implements the security requirement that information does not surge downwardin security lattice by enforcing the following constraints:

(12) The Simple Security Property: A subject (i.e., an autonomous systems) is autho-rized a “read access” to an object (data) if and only if a subject’s security clearance


level is the same as or higher than the object’s classification level in the securitylattice (i.e., reading information);

(13) The*-Property: A subject is authorized a “write access” to any object as long asthe subject’s clearance level is the same as or lower than the object’s classificationlevel in the lattice (i.e., tipping information).

In our case, a subject is an autonomous system invoking a call, and an object is anyrequested data item by an AS. The above requirements can be easily incorporated intoour system without a significant change both at the architectural level and at the designlevel. The easiest way is to modify the net SPEC and INSC as follow:

(1) The net SPEC is changed as follows:

(a) S = {Integers, AID, CID, MID, TYPE, DATA, SSL, OSL} where AID, CID,MID, TYPE, and DATA are the same. The sorts SSL and OSL are derived fromintegers; they model subject security level (i.e., ASs) and object classificationlevel (i.e., data items) respectively.

(b) OP includes the lattices operations of ‘≥’ and ‘≤’ together with a set of opera-tions defined previously;

(c) Eq includes known properties of the new and old operations.

(2) The net INSC is changed as follows:

(a) Sorts of predicates: ϕ (P1) = ϕ (P2) = ℘(AID), ϕ(P3) = ϕ (P4) = ϕ(P5) =ϕ(P6) = ℘(TYPE × CID × MID × DATA × SSL),ϕ(P7) = ℘(CID × MID), ϕ

(P8)= ϕ(P11) = ℘(TYPE × CID × MID × DATA × SSL),ϕ(P10) = ϕ(P12) =ϕ(P13) = ℘(DATA × OSL).

(b) Flow definitions: No changes are required.

(c) Constraints of transitions: R(T7) = (msg[1] = R REQ ∧ x ≥ 1 ∧ msg[5]≥shd[2] ∧ shd[1] = shd’[1]), R(T8) = (msg[1] = W REQ ∧x = 3∧ msg[5] ≤shd[2] ∧ shd’[1] = msg[3]).

(d) The initial marking: No changes are required.

In the above specification secure access control is now enforced by input and outputof each component and connector that have been properly augmented by labels withsecurity and classification level together with the underlying operational semantics basedon HPrTNs that ensures secure access. For example, it is very easy to prove the securityof the augmented repository architecture as follows: Assume for a moment that AS wantsto read a data item (object) that has a classification level higher than AS.

The only way that AS can read the data item is through SMC, which in turn enforces thesecure communication by associating a constraint that explicitly compare AS‘s securityclearance level against data item’s classification level using lattice operator “≥”. As such,the transition T 7 will fail to fire, and hence will not send data with high classificationlevel to AS with a low access level.

The same scenario can be used to show the secure write access where autonomoussystems having high security clearance level attempting to write data items with lowsecurity classification levels. Given that every component properly labeled with input

246 REZA

and output and all the connections are controlled by a connector (SMC) that imposes thetwo security properties proposed by the Bell-Lapadula model, the resulting architectureis also secure.

8. Conclusion and future work

This paper discusses an integrated method to describe software architecture of concurrentsystems. The method is based on two different graphical formalisms: (1) the syntactictheory (ST) introduced by Cordy and Dean [6] and (2) the HPrTNs [14] proposed byHe [14]. The syntactic theory is based on typed nodes and set theory, which providesabstraction facilities needed for modeling software architectures of concurrent systems;the notation lacks formal semantics. The HPrTNs are graphical specifications based onPetri nets [25] that can be used to describe and hence to analyze concurrent systems atlower level design; they lack explicit abstraction facilities needed at architectural levels.The immediate benefit of our integrated approach is precision and analyzability of thearchitectural descriptions. The paper also showed how these two methods complementone another using transformation rules and pattern based refinement technique (PBRT).On the other hand, PBRT can only elaborate what is already shown by the abstractions atarchitectural levels. It will avoid a situation (e.g., expanding the scope) that will violatethe structural integrity of the system it is trying to refine such as adding a component ora connector that is not presented at the higher level of abstraction.

We believe strongly that theoretical results captured in form of patterns (or any othermeans), although valuable are not usually sufficient to motivate the research community.It is only those results that lead to the solution of problems; these problems are importantto software engineers. More specifically, issues concerning practicalities of large-scalesoftware engineering such as extensibility, modifiability, integrity, reusability, scalability,evolution, and management of complexity are considered as a central theme. Reusabilityand practicalities of HPrTN patterns, among other things, are considered as immediatebenefits of patterns because using HPrTN patterns as the starting points, a non-specializedengineer then will be able to build the model directly by composing the instance ofpatterns or with minimal modification efforts.

Currently, our framework provides a tool support that can be used for both modelingand type checking of the syntactic elements of a system according to the well-formednessaxioms in [6]. The automated transformations of ST to HPrTNs and the possible feedbackfrom HPrTNs to ST are challenging tasks, and they are currently under investigation.More specifically, we are working on incorporating the model-checker to evaluate andvalidate our design; the model checker detects possible anomalies by contradictions; thisinformation, then, is feed-backed to designer. Having suitable architectural abstractionsprovided by ST and formal theory of HPrTNs, we are also exploring the possibilityof code testing using our architectural framework in a manner similar to the work byMuccini et al. [31].

Acknowledgments

The author would like to thank anonymous referees for their constructive comments.This work was also supported in part by an ONR grant N00014-98-1-0591.


Notes

1. Heterogeneous abstraction operation for connectors is an operation that systematically transforms connector

subsystems into the minimum system that may be used in the same manner as the original system. More

specifically, the operation transforms a set of basic connectors such as procedure calls or memory access

connectors into semantically rich connectors.

2. We refer to components and connectors types as architectural types.

3. In general, syntactic theory supports two types of abstractions: (1) nodal subsystems, which play the role

of nodes and (2) connector subsystems, which satisfy the role of connectors.

4. [] is a projection notation representing the i th component of tuple t.

5. The simple way to change the system’s capabilities in kind and generally it is more difficult to accomplish.

References

1. G. Abowd, R. Allen, and D. Garlan. Using Style to give meaning to software architecture. In Proceedingof SIGSOFT 93: Foundations of Software Engineering, Software Engineering Notes, ACM, 1993.

2. R. Allen and D. Garlan. The wright architectural specification language. carnegie mellon university.

CS-96-TBD, September 1996.

3. R. Allen and D. Garlan. A formal basis for architectural connection. ACM Transactions on SoftwareEngineering and Methodology, July 1997.

4. R. Allen, D. Garlan, and J. Ockerbloom. Architectural Mismatch or Why it’s hard to build systems out of

existing parts. In Proceedings of International Conference on Software Engineering, 1995.

5. B. Baumgarten. On Internal and External characterizations of PT-net building block behavior; Advances

in Petri Nets 1988, LNCS 1988.

6. J. Cordy and T. Dean. A syntactic theory of software architecture. IEEE Transactions on Software Engi-neering, 21(4): April 1995.

7. Y. Ding and X. He. Object orientation in hierarchical predicate transition nets. Advanced in Petri Nets,LNCS, 2001.

8. A. Egyed and N. Medvidovic. A formal approach to heterogeneous software modeling. Lecture Notes inComputer Science, 1783, 2000.

9. H. Ehrig and B. Mahr. Fundamentals of algebraic specification 1: equations and initial semantics. EATCSMonographs on Theoretical Computer Science. Springer-Verleg, Berlin, 1985.

10. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: Elements of reusable object-oriented

software, Addison-Wesley, 1995.

11. D. Garlan and M. Shaw. Software architecture: Perspective on an emerging discipline. Prentice Hall, 1996.

12. D. Harel. On visual formalism. Communication of ACM, 31, 1988.

13. B. Hayes-Roth. Architecture-based acquisition and development of software: Guidelines and recommen-

dations from ARPA domain-specific software architecture (DSSA) program.

14. X. He, A formal definition of hierarchical predicate transition nets. In Proceedings of the 17th InternationalConference on the Application and the Theory of Petri Nets, Osaka, Japan, June 1996.

15. X. He and J. Lee. Integrating predicate transition nets with first order temporal logic in the specification

and verification of concurrent systems. Formal Aspects of Computing, 2, 1990.

16. P. Inverardi and A. Wolf. Formal specification and analysis of software architectures using the chemical

abstract machine model. IEEE Transactions on Software Engineering, April 1995.

17. J. Kramer and J. Magee. Dynamic structure in software architectures. In Proceeding of ACM SIGSOFT’96.The 4th Symposium on the Foundations of Software Eng., San Francisco, CA, October 1996.

18. P. Kruchten. The 4+1 View model of architecture. IEEE Software, November 1995.

19. C. Landwehr. Formal models for computer security. ACM Computing Survey, 13(3): 247–78, September

1981.

20. D. Luckham and J. Vera. An event-based architecture definition language. IEEE Transactions on SoftwareEngineering, September 1995.

21. N. Medvidovic. Architecture-based specification–time software evolution, PhD Dissertation, University

of California Irvine, January 1999.

248 REZA

22. M. Moriconi, X. Qian, and R. Riemenschneider. Correct architectural refinement. IEEE Transactions onSoftware Engineering, April 1995.

23. M. Moriconi and R. Riemenschneider. Introduction to SADL 1.0: a language for specifying software

architecture hierarchies. Technical Report, Computer Science Laboratory, SRI International, 1996.

24. N. Medvidovic and R. Taylor. A classification and comparison framework for software architecture

description languages. IEEE Transactions on Software Engineering, January 2000.

25. L. Peterson. Petri net theory and modeling of the systems. Prentice Hall, 1981.

26. D. Perry and A. Wolf. Foundations for the study of software architecture. ACM SIGSOFT. Software

Engineering Notes 17(4), 1992.

27. H. Reza. A framework to specify software architecture of a system based on petri net pattern. PhDDissertation, North Dakota State University, Fargo, ND, April 2002.

28. C. Sibertin-Blanc. A client/server protocol for the composition of petri nets. The Proceeding of the 14thInternational Conference on Application and Theory of Petri Nets, LNCS 691, Springer-Verlag, 1993.

29. M. Shaw. Patterns for software architecture, Addison-Wesley 1995.

30. E. Yourdon. Modern structural analysis, Prentice Hall 1989.

31. H. Muccini, A. Bertolino, and P. Inverardi. Using software architecture for code testing, IEEE Transactionson Software Engineering, 30(3), 2004.

32. N. Soundarajan and J. Hallstrom. Responsibilities and rewards: Specifying design patterns. In Proceedingsof the 26th International Conference on Software Engineering (ICSE’04), ST. Louis, USA, May 2004.

33. M. Marsan, C. Gianni, and B. Gianfranco. A class of generalized stochastic petri nets for the performance

evaluation of multiprocessor systems. ACM Transaction, Computer Systems, 2(2):93–122, May 1984.

34. B. Nieh and S. Tavares. Modeling and analyzing cryptographic protocols using petri nets, Lecture Notes

in Computer Science, 718, Spriner-Verlag, 1993.

35. T. Verdickt, B. Dhoedt, F. Gielen, and P. Demeester. Automatic inclusion of middleware performance at-

tributes into architectural UML software models. IEEE Transaction on Software Engineering, 31(8):2005.

36. L. Deligiannidis and R. Jacob. Improving performance of virtual reality applications through parallel

processing. The Journal of Supercomputing, Springer Science+Business Media, 33(3):2005.

a methodology for architectural design of concurrent and distributed software systems

Documents