Microwave Oven 1

8/12/2019 Microwave Oven 1

1/46

GGEENNEETTIICCSSOOFFTTWWAARREEEENNGGIINNEEEERRIINNGGR.G. Dromey,

Software Quality Institute,

Griffith University, Nathan,

Brisbane, Qld., 4111,

AUSTRALIA

61 07 3875 [email protected]

ABSTRACT

Many software projects have large numbers of functionalrequirements and constraints. The challenge is always how touse this information systematically to create a softwaredesign that will satisfy all of its requirements. Directtranslation of individual requirements, each to acomponent/state-based behavior-tree representation, allowsus to reduce the design process to a systematic, incremental,requirements integration process. Individual requirements, inbehavior-tree form, can be grafted, one at a time, onto the

behavior tree representing the evolving design. Once thedesign behavior tree has been assembled, it can be used toderive the supporting component-based softwarearchitecture, the design for each individual component andtheir interfaces. The method provides constructive supportfor component-based development, objected-orientedimplementation, requirements traceability, and the creation ofreusable software components and systems. The methodalso provides an effective means for identifying individualrequirements defects and requirements integration defects.

"The only way to reduce costs and increase reliability is by

preserving the utmost simplicity of concept, specification,

design and implementation"C.A.R. Hoare

KEYWORDS

Software design, genetic software engineering, behavior-trees, requirements engineering, requirements integration,use-cases, systems analysis, software architecture, object-oriented design, component-based design

1. INTRODUCTION

Genetic Software Engineering addresses five fundamentalproblems in software engineering:

How to proceed in a systematic way from a set of

requirements to a design that satisfies thoserequirements.

The need to choose among and apply, a large, complexand sometimes overlapping armament of notations andconventions to support requirements engineering anddesign.

The need to reconcile the fact that use-cases andconventional functional requirements (both of which arebehaviorally based) appear to be good ways ofexpressing requirements for a system but that they arenot a good starting point for either object-oriented orcomponent-based design.

That while the object-oriented approach has been putforward as a preferred option for making softwareresilient to change, the cost of maintaining/changingsoftware remains high.

That identification and resolution of problems with therequirements of a system as early as possible in thedevelopment cycle remains a challenge.

Before introducing the main ideas that underpin geneticsoftware engineering we will first examine in slightly more

detail the five fundamental problems we have identified.

Problem 1: How to go from Requirements to Design

The following is some current advice on design:

Scan all the Use-cases looking for high-risk items, keyfunctions that are likely to have a strong effect on thedesign. The team then creates a design to fit these keyfunctions, hoping the remaining functions will notdisturb the design too much

A.Cockburn, Writing Effective Use Cases

Addison-Wesley, September, 2000

We need the process of going from a set of requirements to adesign to be a lot more systematic than this. To be fair, thereis other advice that is a lot more prescriptive. However,making the transition from requirements to design is not aswell-defined, as constructive, as designer-independent, asproblem-dependent, or as systematic as we would like it tobe. Some authors go so far as to talk about a miracle beingrequired to go from requirements to a design (see Ch. 15,[8]).

One issue that is clear about making the transition fromrequirements to a design, is that the notation we choose forrequirements and for the design produced will significantly

impact the design process.

Problem 2: Notational Complexity and Variety

At present there appears to be growing support in thesoftware engineering community for use of the UMLnotation, which specifies use-cases, and incorporates objectdiagrams, sequence diagrams, collaboration diagrams,activity diagrams and UML state-machines (an adaptationfrom state-charts), etc. Other notations employed includePetri-nets, data-flow diagrams, state-charts and state-transition diagrams. These notations support various


2/46

aspects of the design process, accommodate different kindsof design problems, and provide different views of a design.

With the work done by the OMG group, Booch-Rumbagh-Jacobson [3], Harel [15] and others[21,22], many peopleprobably feel that there has been enough exploration of, andexperimentation with, alternative notations and designprocesses to accommodate the design of todays (and

tomorrows) software systems. They could be right.However, when we stand back and look at the variety ofnotations, processes and concepts that are needed to get usfrom a set of requirements to a design we are forced to drawone of the following conclusions: (1) either, the span ofproblems that we have to deal with is such that a largearmament of notations and processes are needed to cope (2)or, we have yet to reduce the expression of requirements,designs and the design p rocess to their essence.

What grounds are there for thinking that there might be anychance of simplifying the design process and designnotations. The experience that immediately springs to mind

is the economy of expression achieved with functional andlogic programming languages over their imperative languagecounterparts. As Joseph Stoy so eloquently put it, anotation is important for what it leaves out!

Given the lessons from functional/logic programming whatgenetic software engineering does is seek both a simplernotation and a simpler, more well-defined design process.The starting point for launching this investigation has beento formulate a simpler graphical notation that can be used torepresent both individual requirements and designs. Why isthis a sensible thing to do? The most important reason isthat, if the requirements and the design can be expressed in

the same notation it should make it easier to go from a set ofrequirements to a design.

Problem 3: Requirements/Design IncompatibilityThe underlying form of requirements, whether expressed asuse-cases and scenarios or as a conventional SRS, is one ofconstrained black-box behavioral requirements that a designmust satisfy. The difficulty with these representations ofrequirements is that, if used directly as a basis for design,there is a high risk of ending up with designs that are largelybased on functional decomposition. If we accept theprevailing advice that object or component-based designsare to be preferred because of their resilience to change, etc,then we have a problem! It is somewhat like trying to build arectangle out of circles the basic building materials are notsympathetic to what our ultimate goal is. The dilemma weface is that the requirements form seems to be the mostnatural and easiest way for users and others to expressrequirements.

A possible way out of this dilemma is to accept that use-cases and conventional SRSs are good for initiallyexpressing requirements and then translate each individualrequirement to an equivalent formal form that will be more

supportive of object-oriented/component-based design.

Problem 4: Cost of Software Change - Still HighThe object-oriented approach has alleviated some of theproblems associated with the change/evolution of software.However change that involves new requirements, isbehavioral/functional in nature. The challenge that comeswith such changes is how to systematically and easily mapbehavioral change onto object-oriented or component-baseddesigns and implementations. This maintenance/evolution

problem is the same in essence as the problem of how toconstruct a design that will satisfy just two requirements (inthe evolution instance we have a design that satisfies acomposite set of requirements and a single requirement thatwe want to add). If we can find a systematic design processto satisfy two requirements in general there is a strongchance we will be able to handle the softwaremaintenance/evolution problem more easily.

Problem 5: Detecting Requirements Problems EarlyProblems with software requirements continue to addsubstantial costs to software development. It has also beenwell-established that costs are significantly reduced when

requirements problems are caught early in the developmentcycle. The challenge is how to sharpen our ability to detectsuch problems as early as possible. As a starting point intackling this problem we will probably have to accept twothings: (1) that the initial requirements for a system will bewritten in natural language (2) there is a high probability thatthere will be problems of incompleteness/ambiguity, andinconsistency in original statements of requirements. Withthese things as given, what courses of action are open to us?Two things might bear fruit. First, translating individualrequirements into a more rigorous and more structured formmight reveal some problems. Secondly, placing requirementsin their design context may reveal, another important class of

problems. The idea of using the same form to repre sent bothrequirements and designs makes this possible. Elsewhere wedescribe a stepwise process for requirements refinement [10].

2. GENETIC SOFTWARE ENGINEERING

Genetic software engineering (GSE) seeks to make tangibleprogress in tackling the five stated problems. What separatesgenetic software engineering most from conventionalsoftware engineering is the role it assigns to requirements.The goal of conventional software engineering has always

been to build systems that satisfy their sets of requirements.

Conventional Software Engineering

Set of Requirements

SYSTEM

{ R1, R2, ... , Rn }

System that

SATISFIES

{R1, R2, ... , Rn}

In contrast to conventional software engineering, genetic

software engineering is about building a software system


3/46

OUT OF its set of requirements, rather than building a

software system that satisfies its set of requirements.This isa seemingly subtle change in perspective, but it has verysignificant implications for the design process.

Genetic Software Engineering

Set of Requirements

SYSTEM

{ R1, R2, ... , Rn }

System

BUILT OUT OF

Requirements

R1

R5

R4R3

R2

..., Rn

A system built out of its set of requirements will obviouslysatisfy the weaker goal of conventional software engineering that is, such a design will satisfy its requirements.

The first question to ask is does it make sense to considerdesigning a system out of its requirements. To answer thisquestion what we need to recognize is: (1) that functionalrequirements, whether represented as use cases or otherwisedescribe constrained behavior, and (2) designs also describeconstrained behavior. Given that requirements and designsboth describe behavior it might be conceivable to build adesign out of its requirements. One can certainly build awooden house out of wooden beams and wooden boardsbecause the house and the t imber are wooden.

Once we look to build a system out of its requirements, two

questions immediately follow: what representation would individual requirements need

to assume if they were to be usable in a design, and

what options are there for composing, putting together,or integrating requirements to produce a design.

Component-State Representation

Fundamental to what we propose is the idea that we caninterpret what is expressed both in requirements and designsin terms of components or relations being in states andcomponents or relations making transitions between states inresponse to other events. Here we will focus on componentsbeing in states. The idea of using states to characterize

systems behavior has had a long history [15,17,22,23]. Ourintent here is to exploit the notion of state differently bymaking explicit use of the component-state relationship andby limiting component-component composition to a tree-formrather than a directed-graph form. This yields an economicalnotation, called behavior-trees, for expressing bothrequirements and designs. As we will demonstrate, perhapsthe most important impact of this notation is thesimplification and clarity that it brings to the design process.It also makes it much easier to see how each requirement isembedded in a design and to identify problems withrequirements.

The association of states with components is aconceptualization that is widely used and understood inevery-day affairs. For example, people frequently talk aboutsuch things as a DOOR being Open, or Closed, ( Fig. 1) orabout a PLANE having Landed, or being Airborne, or abouta PRODUCT being Out-of-stock or On-order, and so on.

Figure 1: Component Door with a set of states

Using these ideas, if we want to express the behavior orrequirement that when the door is opened the light should

go on we can use a notation something like the following:DOOR

[Open]

LIGHT

[On]

What this says is that when the DOOR component realizesthe state Open it will trigger an internal mechanism within theLIGHT component to execute, causing the Light componentto realize the state On. (Note the empty tags (rectangles) inthis notation are used to manifest traceability when

requirements are integrated into a design).

Behavior Trees

Working from the Components-have-states building blockwe only need a very small number of additional notationalconventions to accommodate constraints, preconditions,decisions, data description, data-flow, control-flow, events,encapsulation and concurrency, etc. In fact, it turns out to bevery easy with this notation to achieve the full expressivepower of a Turing Machine [14]. We call this a Behavior-treenotation because the form is deliberately restricted to a tree-like structure rather than being allowed to grow into adirected graph. Additional notational detail will be dealt within the Appendix.

Using this behavior-tree notation we can translate eachindividual functional requirement, use case, constraint orsystem behavior, expressed informally in natural language,into its corresponding formal graphic behavior-treerepresentation. Behavior trees capture/express behaviors interms of state transitions and component interactions. Thereare three important advantages that flow from suchtranslations: (1) there tends to be little variability amongliteral translations made by different people of the samerequirement (2) The component-state form of behavior-trees

DOOR

States:

Open

Closed


4/46

is compatible with object-oriented and component-baseddesigns (3) Specifying component-component interactionsin a behavior-tree makes a partial contribution to thecomponent integration needed to build the system. Thefollowing figure shows the result of translating a simplefunctional requirement into its corresponding behavior treerepresentation.

Figure 2 Requirement: When a car is at the entrance,if thegate is open the car proceeds,otherwise if the gate is closed,

the driver must press the button which causes the gate to open

and the car to proceed. Alternatively if the gate is closed

the car may reverse and leave.

Parenthesising double question marks around a state??State?? indicate an event. The root node above reads asWhen and if CAR is At-Entrance. Single parenthesisingquestion marks ?State? indicate a decision. For example,GATE?Open? may be read as If the GATE is Open. Controlonly passes from the component state if the event occurs orthe state condition is true.

Design By Requirements IntegrationOnce all requirements are expressed as behavior trees we arein a much stronger position to embark on the process ofsystematically and incrementally constructing a design thatwill satisfy all its requirements. Starting with the set ofindividual requirements behavior trees (RBT) as building

blocks the design step reduces to a process of requirements

integration. Integrating two behavior trees turns out to be arelatively simple process. It most often involves locatingwhere the component/state root node of one behavior treeoccurs in the other tree and grafting the two trees together atthat point. Figure 4 below shows the effect of integrating

behavior trees for two requirements R1 and R2 (see Fig.3) bygrafting R2 onto R1 at the common component node DOORwhich is in the state Open. The resulting integratedbehavior-tree represents a design for satisfying both R1 andR2. The contributions of the individual requirements R1 andR2 are traced in the integrated or design behavior-tree by thenumbers 1 and 2 that are used to tag each of thecomponent/state nodes in the tree.

Figure 3: Two requirements R1 and R2 for integration

Requir ement- R2

When the user closes

the open door the light

goes off.

2DOOR[Closed]

2USER

??Door-Closed??

2LIGHT

[Off]

2DOOR

[Open]

Requirement-R1

When the user opens

the door the light

goes on

1DOOR

[Open]

1USER

??Door-Opened??

1LIGHT

[On]

Figure 4: Result of Integrating Requirements R1 and R2

2DOOR

[Closed]

2USER

??Door-Closed??

2LIGHT

[Off]

1,2 DOOR[Open]

1USER

??Door-Opened??

1LIGHT[On]

Using this behavior-tree grafting process, a complete designis constructed incrementally by integrating one requirementat a time into the evolving design behavior tree (DBT). Thisis the ideal for design construction that is realizable when allrequirements are consistent, and composable. Being able toconstruct a design incrementally, by integrating one

1CAR

??At-Entrance??

1GATE

?Open?1

GATE?Closed?

1CAR

[Proceeds]1

DRIVER

??Pressed-Button??

1 BUTTON[Pressed]

1GATE[Open]

1CAR

??Reverses??

1CAR

[Leaves]

1CAR

[Proceeds]


5/46

requirement at a time, very significantly reduces thecomplexity of the design process.

A design behavior-tree is the shell of a design that showsall the states and all the flows of control (and data), modelledas component-state interactions without any of thefunctionality needed to realize the various states thatindividual components may assume. It embodies within its

form the component-architecture of a system.

The design behavior-tree representation created byintegrating individual requirements provides integration atthe component-state level. In this representation, thesituation can arise where a given component will appear indifferent parts of the tree in different states (e.g the Doorcomponent may appear in the Open-state in some parts ofthe tree and in the Closed-state in other parts of the tree).What we need to do next is convert a design behavior-tree toa component-based design in which each distinct componentis represented only once.

We will see later that a simple algorithmic process may beemployed to accomplish this transformation of a tree into anetwork. Intuitively however, we can think of this asapplying an integration process that absorbs or folds each ofa components states back into the correspondingcomponent. We start at the root of the design behavior tree(e.g. with the USER component in figure 4) and move

systematically down the tree towards the leaf nodes

including each component and each component interaction

(e.g. lines/arrows) that is not already present. When this isdone systematically the tree is transformed into acomponent-based design in which each distinct componentis represented only once. We call this a Component

Dependency Network (CDN) representation. The ComponentDependency Network derived from the design behavior treein figure 4 is shown in figure 5.

Figure 5: Component Dependency Network (CDN)

The CDN forms a first approximation for the business modeland/or software architecture of a system.

Requirements integration as a tool for software designdepends on two fundamental properties of behavior trees.Our two requirements R1 and R2 in Figure 4 will allow us toexplore both of these properties. For this particular example,rather than integrate R2 into R1 via the node DOOR[Open],we could equally well have integrated R1 into R2.

When we do this we get the following different design

behavior tree to that shown in figure 4.

When this can occur the obvious theoretical question to askis what impact does having more than one choice forintegration have on the resulting design? Thankfully, whenwe transform this different integrated design behavior tree,we find that it yields the following component-dependencynetwork, which is equivalentto the one shown in figure 5.

This is a practical demonstration of a very importanttheoretical result which we call the structural invariance

theorem, that underpins the use of behavior trees in design.

Structural Invariance Theorem

Whenever two requirements behavior trees permit the

root of each tree to be grafted onto the other

requirements behavior tree to yield a design behavior

tree the two resulting component dependency networks

that may be derived from the two design behavior trees

are always equivalent in form.

What this theorem confirms is that while the order ofintegration of individual functional requirements produces

USER

DOOR

LIGHT

1 DOOR

[Open]

1 USER

??Door-Opened??

1 LIGHT

[On]

2 DOOR

[Closed]

2 USER

??Door-Closed??

2 LIGHT

[Off]

2 DOOR

[Open]

DOOR

USERLIGHT


6/46


7/46

The component-state model we propose is simpler in terms ofits basic elements. It consists of:

a set of components that can each realize a set of states

a set of transition rules for component interactions

We suggest components, states, data-flows ,control-flows, decisions and component state-transitions aresufficient for characterizing both individual functional

requirements (including constraints and preconditions) and ahigh-level design composed out of its set of functionalrequirements. Compared with the Moore Model[17,22],events and actions have been eliminated. A data-flow orcontrol-flow between two (or more) components, followed bya state transition in the component that receives the data orcontrol flow replaces events and actions. Transition rules arecharacterized by which data-flows (or control-flows) occur,to which components when the source component realizes aparticular state. For example, when, in the Microwaveexample below, the Door realizes the state OPEN, the Lightcomponent turns ON and the Button component isDISABLED.

Specifying Functionality

In the past, software systems were built by composingmodules that encapsulated functionality. With theacceptance of information hiding as a guiding designprinciple, we have now moved on to composing objects, orbetter still, components that encapsulate data, andfunctionality that operates on that data. What needs to berecognized is that functionality operating within acomponent has the end-effect of generating states for thatcomponent. More importantly, a component/staterepresentation can provide a WHAT specification orblack-box specification of the functionality exhibited by a

component. Consider the following component/statespecification of functionality

Function

the

"WHAT"

specificationLIGHT[On]

It says that, in the context given, when the LIGHTcomponent experiences a stimulus on an input channel,internal functionality within the component should betriggered and execute to establish the component-state On.How the internal functionality achieves the state On is nota concern at this time. A component may realize a defined set

of states in response to external stimuli on its various inputchannels. We characterize this sort of functionalityassociated with components as primary functionality. Acomponent realizing a state is probably the most economicalway to say WHAT. And, a component name, with anembedded state-name is a very economical way, graphically,of expressing primary functionality. We treat the component-states associated with primary functionality as axioms of aspecification/design. For example, the state [On] for a LIGHTis taken as a self-evident truth that needs no further formalexplanation in the given design context.

Specifying Behavior

In specifying the requirements of systems what we are reallyconcerned with is behavior. Behaviors are characterized ascomposite functionality. Some behaviors are realized/expressed as WHAT specifications by composingcomponents that realize states by executing primaryfunctionality. For example, we saw earlier, if we want to

express the behavior that when the door is opened the lightshould go on we can use thenotation:

Behavior

the

"WHAT"

specification

LIGHT[On]

DOOR[Open]

More formally, what this says is that when the DOORcomponent realizes the state Open it will trigger an internalmechanism within the LIGHT component to execute, causingthe LIGHT component to realize the state On. More complexbehaviors can be tree-like (behavior-trees), possibly with

recursive leaf nodes (^) that transfer control back to acomponent-state node occurring higher up in the tree. Thisprovides a means for expressing cyclic/repetitive behavior

In the discussion above we talked about behaviors that arerealized/expressed by composing components that realizestates by executing primary functionality. There are alsohigher level states which we want to model that are definedby lower level states being realized. For example, suppose weare modeling a Microwave Oven [22] and we want to talkabout the Oven being in the state OVEN[Cooking]. TheOVEN[Cooking] state might be defined in terms of:

OVEN[Cooking] ::= DOOR[Closed] & POWER_TUBE[Energized] & LIGHT[On] The definition follows directly from the correspondingbehavior tree (see below) which formally represents thefollowing natural language requirement:

Figure 8 Requirement: The Oven has a single button which if

[pushed] when the door is [closed] will [energize] the power-tube,

turn on the light and cause the oven to start cooking.


8/46

1 DOOR

[Closed.]

1 BUTTON[Pushed.]

1 POWER-TUBE

[Energized.]

1 USER

??Button-Push??

1 LIGHT

[On.]

OVEN

[Cooking]

In the Oven example, [Cooking] is a system-state of the Ovencomponent (note the double-line border signifies a systemstate). There are still higher level behaviors that we need tocharacterize that result from composing components that

exhibit system-states. For example if we were modeling aKitchen system, then the Microwave Oven would only be acomponent in that higher level system. In the Kitchen systemwe may want to use the Ovens system states, [Idle],[Cooking], [Timed-Out], etc, to model these higher levelbehaviors. Systems behavior is built and specified bycomposing component-states even if the correspondingcomponents are systems in their own right (e.g., the Oven isa system) the concept of a sub-system is unnecessary inthis modeling framework. All we require is that componentsthat are systems (we call them system-components) need toexhibit system states that correspond to their accessibleexternal behaviors. Once this is done they can be easily

integrated into higher level systems as components.

Using this behavior-tree notation we can translate eachindividual functional requirement, constraint or systembehavior, expressed informally in natural language, into itscorresponding formal graphic behavior-tree representation.Behavior trees capture/express behaviors in terms of statetransitions and component interactions. The real beauty ofsuch translations is that there tends to be little variabilityamong translations made by different people. A sharedglossary is needed to minimize aliasing and naming problems.

Our intent now is to give an overview of the main steps in

the genetic software engineering development process asapplied to a small, well-known case study. Details foradapting the method to large-scale systems [25] and forsystematically refining a set of requirements [10] are treatedseparately. Both of these treatments rely on the sameunderlying GSE development process.

5. STAGES IN DEVELOPMENT

A systematic system development process based on the useof behavior trees reduces to the following five steps. Insummary form these five steps are:

1. Develop a Statement of Requirements informal, textual,possibly written as conventional functionalrequirements or based on Use-cases and their scenarios.

2. Translate each functional requirement produced in step1 (including constraints) into its equivalentrepresentation using one or more behavior trees. In theprocess be sure to identify and integrate into eachbehavior tree system-states that specify the desired

external behavior of the system. This formalization stepidentifies problems with individual functionalrequirements that need correction/clarification oraugmentation. Correct or resolve any identifiedproblems and make sure the requirements integrationintegrity constraint (RIIC) is satisfied.

3. Integrate into the design, one at a time, the behaviortrees representing each functional requirement that wasproduced in step 2. This integration process iscommonly achieved by identifying (by matching) where,in the evolving design behavior tree, the root

(component/state) of the behavior tree of the currentfunctional requirement is located or could be locatedbased on available domain knowledge and/orpreconditions for functional requirements defined interms of component-states. The functional requirementbehavior tree can be integrated into the design behaviortree at that point. The repeated requirementsintegration step can identify and rectify integration,inconsistency and incompleteness problems with a setof functional requirements.

4. Transform the design behavior tree to construct thecomponent-based software architecture (CDN) for thesystem. Also project from the design behavior tree the

component interfaces for each of the identifiedcomponents. Refine/simplify the component interfacesthen integrate each component into the architectureusing behavior-mapping to produce the component-based design. When this step is finished a completeabstract design shell has been produced in which allcomponent interfaces have been designed along withthe control flows and data-flows that define allcomponent interactions

5. Project from the design behavior tree the behavior treesof each individual component. Use this information andthe information in step 4 to design and implement eachcomponent.

We will now examine each of the steps in the geneticsoftware engineering process in more detail and illustratetheir application using an example.

STEP 1: Develop a Statement of Requirements in natural

language.The only point we will make about this step is to say that themore care that is taken to ensure that the natural languagestatement of functional requirements is concise, accurate,unambiguous, consistent and complete, the less problemsthere will be with later steps. For large systems applications,


9/46

statements of requirements that conform to the StandardIEEE-830 are eminently suitable. A good exemplar of such astatement of requirements for a larger problem, a satellitecontrol system, can be found at the web-site:

http://source.asset.com/stars/loral/cleanroom/oo/study.htm

To illustrate the steps in the method we will consider the

simple Microwave Oven problem discussed by Shlaer andMellor[22]. We have deliberately chosen to use theirrequirements as is, rather than try to remove any defects. Forthe purposes of brevity however, we have, in places,expressed individual requirements more concisely withoutaltering their intended meaning.

They give the following requirements for the problem.

STATEMENT OF REQUIREMENTS

1 There is a single control button available for the user of

the oven. If the oven door is closed and you push thebutton, the oven will cook (that is, energize the power-tube for one minute).

2 If the button is pushed while the oven is cooking it willcause the oven to cook for an extra minute.

3 Pushing the button when the door is open has no effect.4 Whenever the oven is cooking or the door is open the

light in the oven will be on.5 Opening the door stops the cooking.6 Closing the door turns off the light. This is the normal

state, prior to cooking when the user has placed food inthe oven.

7 If the oven times-out the light and the power-tube are

turned off and then a beeper emits a sound to indicatethat the cooking is finished.

STEP 2: Translate Each Requirement into its Behavior Tree

Representation

The translation of each requirement to its correspondingbehavior tree representation involves a translation from aninformal notation to a formal notation. In conducting thistranslation what we must do first is look for potentialcomponents (often physical objects or users) and potentialstates (the results of actions being applied to components).We are interested in the components (nouns) that have

actions (verbs) done to them.

Consider the first requirement for the Microwave Ovenproblem. Below we have identified in boldcomponents thathave actions done to them. The corresponding statesrealized by each of the components are in square brackets[].

Requirement 1: There is a single control buttonavailable for the userof the oven. If the oven dooris[closed] and you[push] the button, the ovenwill [cook

(that is, [energize] the power-tube) for one minute].(Note: you equals user)

The corresponding set of component-states derived fromthis requirement are as shown below. The oven cooking forone minute represents a system-state.

Figure 6: Component-states for Requirement 1

BUTTON

[Pushed]

DOOR

[Closed]

POWER-TUBE[Energized]

OVEN[Cook-One-Min]

USER

??ButtonPushed??

The second task in translating a requirement into a behaviortree is to work out the causal, conditional and/or temporaldependencies or relationships that exist among componentsin the various states. This is an ordering process thatinvolves integration of components in states. The task hasthe purpose of capturing the behavior expressed in therequirement. For our example, there is a temporal dependencythat indicates the button should be pushed after the door isclosed. Similarly, the power-tube will energize and the ovenwill only start cooking after the button has been pushed.Ordering and connecting the component/state entitiesaccordingly we get the following behavior tree.

1DOOR

[Closed]

1BUTTON[Pushed]

1POWER-TUBE

[Energized]

1OVEN

[Cook-One-Min]

1USER

??ButtonPushed??

In this more or less literal translation of the functionalrequirement no distinction has been made between thesystem cooking state and the finished cooking state. Bothare significant system states.


10/46

Before the button is pushed the oven is really in an idlesystem-state. In terms of fully characterizing the behavior ofthe oven it is useful to recognize this OVEN[Idle] systemstate.

In designing software systems, frequently they aresupported by a user interface. We suggest that it isimportant to properly capture the user interactions in both

the requirements and the design. This is most simply donewithin the present component/state framework by treatingthe user (or users) as a component that can be in differentstates. For, example, after the user has executed the action,push-button, he/she will be in the stateUSER[ButtonPushed]. The original description of therequirement implies that when the door is closed the buttonwill get pushed. This is not the case. A user interaction isneeded to make this happen. Here we are talking about anevent that may or may not happen. We represent this asUSER??ButtonPushed?? which reads WHEN and IF theUSER has carried out the action that realizes the state,ButtonPushed. Incorporating the suggestions for system

states we end up with the behavior-tree shown in Figure 7 forrequirement 1.

An important lesson from this exercise is that it is better todo requirements translation in two steps. First we do a literaltranslation. Then we do a step that critically examines therequirement and corrects and/or augments it to remove anydefects. This includes adding any necessary or appropriateprecondition as the root of the tree and any appropriatesystem states.

Figure 7. Requirement R1: There is a single control button

available for the user of the oven. If the oven door is closed

and you push the button, the oven will cook (that is, energizethe power-tube for one minute.

1DOOR

[Closed]

1BUTTON

[Pushed]

1POWER-TUBE

[Energized]

1 USER??ButtonPushed??

1OVEN

[Idle]

1OVEN

[Cooking]

1OVEN

[CookingFinished]

To recap, design is about establishing relationships andthereby creating order among things. Requirementstranslation to a behavior tree involves two steps: first onemust identify the things to be ordered, and then one mustorder those things into one or more behavior trees. Inidentifying the things, this should include identifyingmeaningful system-states that may be used to characterize

the external behavior of the system. It is important to includetags for each requirement to ensure traceability. We haveused 1 for requirement R1 and 2 for requirement R2, etc.

We will now include the behavior tree translations for theremaining six requirements suggested by Shlaer & Mellor[22]and accompany them with any remarks on notation or on thetranslation process.

Requirement R2The only issue with requirement R2 is that we note it picksup the state OVEN[Cooking] that we had remarked on in thetranslation of the first requirement. In the tree we haveshortened cook-for-one-extra-minute to Extra-Minute. Afterthe OVEN has realized the state [Extra-Minute] it returns tothe state [Cooking]. To capture this we have added arecursive OVEN^[Cooking] state after the OVEN[Extra-Minute] state.

Figure 8. Requirement R2: If the button is pushed while the

oven is cooking, it will cause the oven to cook for one extra minute.


11/46

2USER

??ButtonPushed??

2BUTTON[Pushed]

2OVEN

[Cooking]

2OVEN

[Extra-Minute]

2OVEN^

[Cooking]

Requirement R3

Requirement R3 represents a constraint that should alwaysapply when the door is open. We mark its tag with a C toindicate this. This constraint is interesting because itexpresses something that MUST NOT happen that is, weare talking about a safety property of the system. In thiscase we have given two translations of the requirement, aliteral one and shorter one that introduces the idea of adisabled state for button. In the first translation, the brokenarrow between the USER and the BUTTON is used toindicate that, in the context of an open door there cannot bea causal flow from user to button. Encapsulation with @ isused to represent the second version. This implies that wehave used another behavior tree defined elsewhere toimplement the realization of this state. Both translations dothe job. Whenever the Door is open the oven is in thesystem state open. This has been added to the secondversion of the constraint. What is important with constraintsis that they get applied globally across the design. That is,whenever we mention the state DOOR[Open] in our designthe BUTTON@[Disabled] state needs to be realized.Figure 9. Requirement R3: Pushing the button when the door

is open has no effect

3CDOOR[Open]

3C USER??ButtonPushed??

3C BUTTON[Pushedt]

3CDOOR[Open]

3C BUTTON@[Disabled]

3C OVEN[Open]

3CDOOR[Closed]

3C BUTTON[Enabled]

It also follows with this requirement that the complementaryconstraint applies, that is, whenever the door is closed thebutton is enabled. This also needs to be factored globallyacross the design.

Requirement R4

This requirement embodies two constraints that must applywhenever the oven is cooking or the door is open. The orin the sentence gives the clue that we are considering twothings and whenever indicates we are talking about aconstraint that needs to be applied in all cases where thedoor is open, etc. Literal translation of the constraint that the

light should go on when the oven is cooking defines apeculiar situation. We have an abstract system state causinga concrete component state LIGHT[On] to be realized. Wecan either accept this literal translation or recognise thatsome other concrete state (here the button being pushed)causes the light to go on, the power-tube to energize, and theoven to realize the state cooking. Choosing physicalcomponents realizing states as causal agents usually gives amore accurate characterization of reality than having abstractsystem states (e.g. OVEN[Cooking]) as causal agents.However, there will be times when a particular system state isthe most appropriate as a causal agent. Either choice isultimately a design decision of the software engineer.

Figure 10. Requirement R4: Whenever the oven is cooking or

the door is open the light in the oven will be on.

4C LIGHT

[On]

4C DOOR

[Open]

4C LIGHT

[On]

4C OVEN[Cooking] 4C

BUTTON

[ Pressed ]

4C LIGHT

[On]

4C OVEN

[Cooking]

4C POWER-TUBE

[ Energized ]

Requirement R5

Figure 11. Requirement R5: Opening the door stops the

cooking.


12/46

5USER

??Door-Opened??

5DOOR[Open]

5OVEN

[Cooking]

5OVEN

[Cooking-Stopped]

Requirement R5 illustrates the weakness of simply doing acompletely literal translation of a requirement expressed innatural language. The requirement neglects to mention thatthe oven has to be cooking for the requirement to apply (wehave included it) and a user needs to open the door. Using

domain knowledge and commonsense is always relevant you can only stop something if it is happening in the firstplace. If incompleteness defects like this are carried throughinto the behavior-tree two things can happen: (1) they showup in the requirements integration phase and are detected or(2) you could end up integrating a requirement where it didnot apply. For example you could integrate this behavior-treein a situation where the door was open but the oven had notbeen cooking. Stopping cooking when the oven has notbeen cooking constitutes fatuous behavior . The lesson tolearn from this is that it is always wise to look at the root ofany behavior tree to see if we can precede it with any otherprecondition component/state (here we added

OVEN[Cooking]). This is just the good practice of looking forthe precondition associated with each functionalrequirement. Notice that preconditions are represented bycomponent-states or possibly behavior sub-trees. Animportant advantage of behavior trees is that preconditions(and postconditions) may be represented using acomponent-state form just like the representation offunctional requirements themselves.

Requirement R6

Requirement R6 has an implied user that has been included someone must close the door. This requirement achieves animplied system state which we have labelled as OVEN[Idle].

An obvious question here is should we include theprecondition that the door needs to be open for it to beclosed by a user? Our response to this is, that we includepreconditions only as necessary to support requirementsintegration. In this case we have included the preconditionOVEN[Open]. As we will see later the most appropriatebehavioural form for a functional requirement is that itstartsin a system state and ends in a system state. When thisdiscipline is adopted, integration problems largely disappear.

Figure 12. Requirement R6:Closing the door turns off the light.

This is the normal state, prior to cooking when the user has placed

food in the oven. (This action establishes the OVEN[Idle] system

state).

6 USER??Door-Closed??

6LIGHT

[Off]

6DOOR[Closed]

6 OVEN[Idle]

6OVEN[ Open ]

Requirement R7

In Requirement R7 we need to recognize that the Oven mustbe cooking before it can time-out. It is unclear whether theOven achieves the state [Cooking-Finished] before or afterthe beeper sounds. In the present example this issue isimmaterial. In other situations it may represent an ambiguitythat needs to be resolved. What is significant is thatconstructing the behavior tree specification throws up suchproblems early in the development cycle. As a general rulewe position system-states as leaf or root nodes in behavior

trees because they are abstract states that are realized onlyafter concrete components that actualize the behavior of thesystem realize their states. Earlier we saw that the oven onlyrealizes the cooking system-state after the power-tube isenergized and the light is on. Similarly, constraint (4C)suggested that the light would be on when the oven was inthe system state cooking. In this case we put therealization of LIGHT[On] before OVEN[Cooking] because theconcrete state forms part of the formal definition of thesystem-state. Once again we have put the system state at thebottom of the behavior tree.


13/46

Figure 13. Requirement R7: If the oven times-out the light and

the power-tube are turned off and then a beeper emits a sound to

indicate that the cooking has finished.

7 LIGHT[Off] 7

POWER-TUBE[Off]

7BEEPER

[Sounded]

7 OVEN[Cooking]

7OVEN

??Timed-Out??

7OVEN

[Cooking-Finished

In the original treatment of the problem by Shlaer & Mellor aTimer is introduced as a component to handle the timingaction. Here, because no mention of a timer component ismade in the original specification of the requirements wehave chosen to represent this as a transition between twosystem states OVEN[Cooking] and OVEN[Timed-Out]. Howthis system requirement is implemented, is left as detaileddesign decision. This would seem preferable.

All given requirements for the Microwave Oven have nowbeen converted to behavior trees . The next task is to

integrate then into the design one at a time.

STEP 3: Incrementally Integrate Individual Requirements

Behavior Trees to Create an Evolving Design Behavior

Tree.

Parnas and Clements [18] make the remark determining thedetailed requirements may well be the most difficult part ofthe design process. If this is the case, then constructing adesign to satisfy those requirements mu st be a close secondin terms of degrees of difficulty. There are several keythings, above and beyond the five problems mentionedinitially, that contribute to the difficulty of design. They are:(1) knowing where and how to start the design, given thatthere is always a risk that later considerations will invalidateor compromise earlier design decisions, (2) knowing how topartit ion up the design work in order to manage thecomplexity of the task (3) coping with the amount of detailand ensuring large numbers of constraints are properlyaccommodated.

Genetic software engineering offers a way to at least alleviateif not circumvent these three very challenging problems.Building a design out of its set of requirements immediatelygives a partitioning of the problem according to thosefunctional requirements. It also tells us where to start the

design and how to proceed. We can start with any individualrequirement and integrate other requirements into the design,one at a time, in any order. This is practical because thebehavior-tree notation, together with the structuralinvariance theorem, insulates the design from affects that areoften due to the order in which design decisions are made.

Position, defined by component states, (the RIIC)

determines where each requirement needs to be integrated

into the design, irrespective of the order in which theintegration takes place. The problem we are dealing withwhen we use behavior trees to create a design is somewhatlike assembling the pieces of a jig-saw puzzle. With suchpuzzles the order in which pieces are assembled isunimportant because the properties of each piece mean thatthere is only one place where it can be fitted in order tomeaningfully contribute to solving the puzzle. Puttingbehavior trees together is easier than putting jig -saw puzzlepieces together because matching component-stateinformation gives explicit guidance about where integrationneeds to take place. Domain information always informs thedecision (e.g., you can only open a door that is closed, or

start a car that is not running, etc). As a general rule,important preconditions for individual functionalrequirements should always be included (or added if theyhave been left out) as a component-state root node or moregenerally as a sub-tree of the functional requirement. Thescale of the integration problem at any one time is verymanageable because it only ever involves integrating justtwo behavior trees (one representing the current evolvingdesign and the other representing the requirement that iscurrently being integrated into the design). If we do notknow where to integrate one behavior tree into another, onlytwo things are possible. Either they do not integrate or wehave left out the appropriate precondition for executing one

of the functional requirements. Ensuring the RequirementsIntegration Integrity Constraint (RIIC) holds for a set ofrequirements behavior trees should avoid any problem.

The whole process of satisfying the RIIC, implementingrequirements integration, and systematically applying allconstraints, can be greatly assisted by constructing a

Requirements Integration Table (RIT) once all therequirements have been expressed as behavior trees. TheRIT contains for each root node component-state of arequirements behavior tree, the list of other requirementsbehavior trees that contain that component-state. This listindicates (potential) points for integration for the rootnode. Below we show the RIT for the eight requirementsbehavior trees for the M icrowave problem. When the currentroot-node component-state occurs as a root node in anotherrequirement this is indicated in the OCCURS-IN column inbrackets ( ). Root node component-states should inpreference be integrated at non-root node component-states .Therefore integrating the R2 root at the R1 component-stateinstead of R5 or R7 (which are root nodes themselves)should be preferred.

The original statement of requirements left out an importantrequirement R8 see later discussion.


14/46

REQ Root Cpt-State Type OCCURS-INR1 DOOR[Closed] C R3C,R6

R2 Oven[Cooking] S R1, (R5), (R7)

R3 DOOR[Open] C R4, R5, R8

R4 DOOR[Open] C R3, R5, R8

R4 BUTTON[Pushed] C R1, R2

R5 OVEN[Cooking] S R1, (R2), (R7)

R6 OVEN[Open] S R1, R3C

R7 OVEN[Cooking] S R1, (R2), (R5)

R8 OVEN[Idle] S R1

After construction of the RIT we must examine it to see ifthere is more than one component-state root node that doesNOT occur in other behavior trees. If this happens therequirements integration integrity constraint is not satisfiedby our set of behavior trees. Our job then is to addcomponent-state preconditions as root nodes until the RIICis satisfied. For our example above the RIIC is satisfied up-front, so no precondition amendments are needed.

We mentioned earlier that in conventional software design,properly accommodating the large number of constraintsassociated with any non-trivial problem is always a verychallenging problem. When we use behavior trees and aRequirements Integration Table, things are a lot easier.Constraints show up when individual requirements are beingspecified. Our obligation in each case is to recognize whethereach individual constraint just applies locally or whether itneeds to be applied across part or even the whole design. Asmall example that applies with the Microwave oven problemillustrates what needs to happen. Take the case of theconstraint that shows up in requirement R4 whenever thedoor is open the light should be on . This is clearly a global

constraint that needs to be applied to all other requirementsthat realize a state where the door is open. This information isavailable in the Requirements Integration table. At all thesepoints we simply add a node to the tree that representsLIGHT[On].

Rules for Requirements IntegrationStructurally when two requirements behavior-trees (or anevolving design behavior-tree and a requirements behavior-tree) are integrated the permissible operations correspond tothe insertion of one tree into a second tree, tempered by theextent of the match between the two behavior trees startingat the root node of one tree.1. The simplest and most often used integration process is

to find the component-state in one behavior tree RBT xthat is matched by the root node (often a system-state)of the second behavior tree RBT y . The second behaviortree is integrated into the first behavior tree at that point.We applied this integration strategy with theDOOR/LIGHT example (see figures 3 and 4 in section 2)discussed earlier. If there is no corresponding nodewhere the root node of the first behavior tree can beintegrated into the second behavior tree this is referredto as an asymmetric integration.

2. In other cases, when we seek to integrate two behaviortrees RBTx and RBTy, the root of each tree occurs in theother tree. In this case integration issymmetric, and wetherefore have a choice about how we do theintegration. We saw earlier that a fundamental propertyof behavior tree composition tells us that either choicewill yield an equivalent component-based architecturaldesign. This property follows from the fact that

integrating behavior trees does not add any behaviorthat was not already present in the behavior trees beingintegrated.

3. In some cases, there is no root-node match of onebehavio r tree in the other behavior tree. For example,with our DOOR/LIGHT example discussed earlier (seefigures 3 and 4 again), we could have inserted R1 into R2at the point where the state DOOR[Closed] applies.Note, in this case R1 does not have DOOR[Closed] as i tsroot node. This component-state is, however, anecessary precondition for applying R1. Here domainknowledge informs the process. When this situationoccurs, it points to a deficiency in our original

specification of a functional requirement or our failure toapply the RIIC. In such cases we should augment theroot node of the corresponding functional requirementaccordingly so that either rule 1 or rule 2 above applies.If we do not know the conditions under which afunctional requirement must operate our understandingof the system/problem is incomplete and it needs to berectified before proceeding. Obviously some pairs ofbehavior trees do not integrate give the behavior theydescribe.

4. In some cases , because of overlap and redundancy inthe way individual requirements are described, thisshows up in their individual behavior trees. This

happens with R1 and R6 for our Microwave Problem they share two component-states. It is best to discardthis redundancy when integration takes place. We havedone this for the R1/R6 pair in the final Design BehaviorTree for the Microwave problem (see later).

In order to illustrate what requirements integration withbehavior trees entails we will consider the incrementalintegration of the seven behavior trees for the Microwaveoven problem.

Integration of R1 and R2

To initiate this process we will first consider integrating thebehavior trees for requirements R1 and R2 to give D12. Notethat in the integrated behavior tree, the 1 and 2 tagsindicate which original requirement was the source of theparticular behavior tree fragment. This characteristic ofbehavior trees was, for obvious reasons, a key influence innaming this approach genetic software engineering.

The integration of requirements R1 and R2, follows thecomponent/state matching and grafting procedure. The rootof the R2 behavior tree OVEN[Cooking] is grafted onto theR1 behavior tree. We use the tag IP to indicate anintegration point.


15/46

Figure 14. Design12: Result of integrating requirements R1 and

R2

1DOOR

[Closed]

1BUTTON

[Pushed]

1POWER-TUBE

[Energized]

1USER

??ButtonPushed??


2BUTTON

[Pushed]

IPOVEN

[Cooking]

1 OVEN[Cooking-Finished

2OVEN

[Extra-Minute]

2 OVEN [Cooking]

1OVEN[ Idle ]

Integration of D12 and R3

Integrating R3 adds a constraint associated with the door

being closed (we show that this constraint has been added inD1234). Because the DOOR[Open] state does not appear inD12 its associated constraint does not extend the behaviortree D12 at this time. So D123 consists of two trees, theevolving design and the DOOR[Open] constraint from R3.

Integration of D123 and R4It adds only LIGHT[On] to D123. As discussed earlier thisstate is realized before the system state OVEN[Cooking].Notice also that constraints 3C and 4C get integrated but thisbehavior tree is still not integrated with D1234 because westill do not have a situation where DOOR[Open] applies. It

turns out that this situation is partly caused by anincompleteness problem with the original statement ofrequirements it should be possible to open the door onceit has been closed. In the end we will need to add this as anadditional behavioral requirement of the system.

Figure 15. Design1234:Result of integrating requirement R4 with

the evolving design D123

IPDOOR

[Closed]

IPBUTTON

[Pushed]

1POWER-TUBE

[Energized]


2USER

??ButtonPushed??

2 BUTTON[Pushed]

4CLIGHT

[On]

4CLIGHT

[On]

3CDOOR

[Open]

3CBUTTON@

[Disabled]

IPOVEN

[Cooking]

1OVEN

[Cooking-Finished]

2OVEN

[Extra-Minute]

2OVEN ^

[Cooking]

3CBUTTON[ Enabled ]

1 OVEN[ Idle ]

Integration of D1234 and R5

Integrating R5 into the design brings with it a design sub-

tree where DOOR[Open] applies. It therefore gives us anopportunity to integrate the constraints associated with thedoor being open. Also note in the integration of R5 we havenot included LIGHT[On] because it is already on when theoven is cooking. Opening the door does not change this.


16/46

Figure 16. Design-1-2-3-4-5:Result of integrating requirement R5

with the evolving design D1234

IPDOOR

[Closed]

IPBUTTON

[Pushed]

1 POWER-TUBE[Energized]

1USER

??ButtonPushed??

IPOVEN

[Cooking]

2OVEN

[Extra-Minute]


2BUTTON

[Pushed]

2OVEN

[Cooking]

5OVEN

[Cooking-Stopped]

IPDOOR[Open]

3CBUTTON@

[Disabled]

4C LIGHT[On]

5USER

??Door-Opened??

1OVEN

[CookingFinished]

1OVEN[ Idle ]

3CBUTTON[ Enabled ]

Final Integrated DesignWhen we integrate the root of R1 with R6 we see there isoverlap, and two paths from DOOR[Closed] to OVEN[Idle].This overlap has arisen because we have not expressed eachfunctional requirement as a transition between system states

(see later rewrite of R1 and R2 that corrects this problem). Insuch circumstances we have several choices (a) we can, byinspection, opt for the longer path this is what we havedone here. (b) we can ignore the redundancy on the groundsthat the subsequent transformation to derive the componentdependency network and rationalize the componentinterfaces will essentially take care of it (c) or we can

implement a sophisticated tree-pruning algorithm tosystematically remove the redundancy. A loose statement ofR1 has caused the problem. It would have been moreaccurate to refer to a user button push when the oven wasidle (e.g., door closed, light off, button enabled) rather thanjust when the door was closed.

Redundancy can occur when we fail to express functional

requirements as transitions between system states.Integrating R7 into the design behavior tree shows upanother redundancy problem. R7 results in a transitionbetween the system states cooking and cooking-finished. However R1 also included a transition between thesame two system states. As with the integration of R6 wecould either ignore or remove this redundancy as we havedone here. What it underlines is the value of writingfunctional requirements in a behavioural form where theystart in a system-state and end in a system-state.

When the integration process is complete, upon examinationof the integrated design behavior tree we discover that the

original requirements were incomplete in that no allowancewas made for the door to be opened when the oven is in anidlestate prior to cooking. Below we show a requirement R8that meets these needs and incorporates the constraintsassociated with opening the door.

6OVEN

[ Open ] IPDOOR

[Closed]

1OVEN

[Idle]

1USER

??ButtonPushed??

6USER

??Door-Closed??

6DOOR[Closed]

6 LIGHT[Off]

6OVEN

[Idle]

3CBUTTON[Enabled]


17/46

We have integrated R8 into the final design as an additionalrequirement. The origins of all the requirements are clearly

shown in the final design. Elsewhere [10] we discuss asystematic stepwise process for refining a set of originalrequirements to obtain a set of requirements that have theconsistency and completeness needed to support animplementation.

Figure 17. Design-1-2-3-4-5-6-7-8: Results of integrating

requirement R6,R7 and R8 with the evolving design D12345

2 OVEN

[Extra-Minute]

2 BUTTON

[Pushed]

2 OVEN

[Cooking]

7 OVEN??Timed-Out??2

USER??ButtonPushed??

4C LIGHT

[On]

5 USER

??Door-Opened??

7 LIGHT

[Off]7

POWER-TUBE[Off]

7 BEEPER

[Sounded]

IP

BUTTON

[Pushed]

1 POWER-TUBE

[Energized]

1 USER

??ButtonPushed??

IP OVEN

[Cooking]

6 USER

??Door-Closed??

IP DOOR

[Closed]

6 LIGHT

[Off]

8 USER

??Door-Opened??

IP

DOOR

[Open]

4C LIGHT

[On] 3C BUTTON@

[Disabled]

3C OVEN

[Open]

IP DOOR

[Open]

3C BUTTON@

[Disabled]5

OVEN

[Cooking-Stopped]

7 OVEN

[Cooking-Finished

IP OVEN

[Idle]

3C BUTTON

[Enabled]

5 POWER-TUBE

[Off]

6 OVEN

[ Open ]

STEP 4: Construct the Component-Based Software

Architecture and Individual Component Interfaces from the

Design Behavior Tree.

Ultimately, our goal is to express the architecture of asoftware system in terms of interactions among a set ofsoftware components rather than in terms of interactionsbetween component-states. The design behavior tree,created in step 3, can be used to do this. It contains all theinformation needed to construct a component-basedsoftware architecture for the system. A sequence ofstraightforward transformations on, and projections from, the

8USER

??Door-Opened??

IPDOOR[Open]

4CLIGHT

[On] 3CBUTTON@[Disabled]

3COVEN[Open]

8OVEN[ Idle ]


18/46

design behavior tree need to be applied to accomplish thetask. Three steps are required a transformation of thedesign behavior tree (DBT) to a comp onent network,projection of each components interface from the DBTfollowed by refinement of that interface, and finallyrefinement of the component-based architecture toaccommodate the simplifications made to the interfaces ofindividual components.

To understand this whole process we need to recognize theunderlying form of a component-based software architecture.In abstract terms a component-based software architecturefor a system consists of a set of components that are able tointeract via a set of channels and interfaces that supportboth control-flows and data-flows. In general, for such arepresentation of a system most, if not all, components willnormally only interact with a small subset of the othercomponents in the system. We will now examine therequired steps.

(a) Component Dependency Transformation

In constructing the software architecture the first step is towork out the complete set of component dependencies. Thisgives a first cut at establishing the software architecture forthe system. Conceptually this step is most easily understoodin terms of a set of graphic transformations that aresystematically applied as the design behavior tree istraversed level by level starting at the root.

1. To start the process the root-node component isincluded. Thereafter, on a given level, as eachcomponent-state is examined, three things are possible:

2. The component -state (X -CS) belongs to a component

(X) that has not appeared in th e alr eady-exami nedlevels of the design behavior tr ee. In this case, the

component X is inserted into the evolving component-based design by drawing an input arrow to X from thealready-included component P that connects to X. (Weuse the convention where the top of componentrectangles accept inputs and the bottom of componentrectangles emanate outputs)

3. The component -state (X -CS) belongs to a component

(X ) that has appeared in the alr eady-exami ned levels

of the design behavior tr ee. In this case, (a) if a link

already exists from P to X, ignore the following step, (b)otherwise draw an output arrow from the component P

whose component-state connects to (X-CS) to X, in theevolving component-based design. Sometimes makingthis connection involves a loop back in the evolvingcomponent-based design. It depends on the relativeorder of the levels where the components P and X wereinserted into the component-based design. In somecases there may be no direct link from P to X but theremay already exist an indirect link from P to X. Wesometimes use such an indirect link rather than

introduce a new link (we see this with our microwaveexample when we reject the direct Door-Power-tube link(indicated by R5) in favor of the indirect door-button-power-tube connection to achieve the same outcome).

The whole process is best illustrated by an example. Below isshown the evolving Component Dependency Network(CDN) after the first five levels of the design behavior tree

have been visited. What we see is that down to the fourthlevel in the tree, no component has occurred more than once,and so the component network mirrors the design behaviortree. At the fifth level, an OVEN component-state isencountered and so action 3(b) comes into effect, because

the Oven component has appeared at an earlier level in thetree.

The thicker flow-line shows how the level five componentstate is taken into account. The result of processing the sixthlevel (see below) does not have any affect as there is already

an OVEN to USER link, that is, step 3(a) applies.

Taking into account the seventh level introduces a new linkfrom the USER component to the BUTTON componentwhich is shown below as a thicker connection..

IP OVEN[Idle]

1DOOR[Closed]

3CBUTTON[Enabled]

USER

DOOR

LIGHT BUTTON

OVEN

Traversed Design Behavior Tree Evolving ComponentDependency Network

6USER

??Door-Closed??

IPDOOR

[Closed]

6 LIGHT[Off]

3C BUTTON[Enabled]

6 OVEN[ Open ]

1 USER

??ButtonPushed??

6 USER

??Door-Closed??

IP DOOR

[Closed]

6 LIGHT

[Off]

8 USER

??Door-Opened??

IP OVEN

[Idle]

3C BUTTON

[Enabled]

Traversed Design Behavior Tree Evolving Component DependencyNetwork

6 OVEN

[ Open ]

1 DOOR

[Closed]

3C BUTTON

[Enabled]

USER

DOOR

LIGHT BUTTON

OVEN


19/46

Taking into account the eighth level introduces a newcomponent, the power-tube, which is connected to the

button. There is also a link from the button to the light.

When this transformation process is completed for all levelsin the design behavior tree we end up with the IntegratedComponent Dependency Network shown below.

There is only one remark that needs to be made about thefinal representation. We find that in requirement R5 there is adirect link from Door to Power-tube to Oven when the useropens the door. However prior to that we have established alink that enables the button when the door is closed, turnson the power-tube when the button is pressed and as a resultstarts the oven cooking. Since this pathway already exists itis unnecessary to add an alternative path to stop the cooking

when the door is opened.

(b) Component Interface Projection and Design

To complete the architectural aspects of the component-based design what remains is the task of first ensuring thatthe individual component-interfaces for each component areas simple as possible and are directly compatible with thederived Component Dependency Network.

To carry out this task the first step is to project the input andoutput interfaces for each component from the designbehavior tree. We do this by simply examining the designbehavior tree and identifying all component-states that input

to the component whose input interface we wish to define.Similarly to determine the component's output interface wesimply identify all the component states the componentoutputs to.

The result of identifying all the components that input to the

2OVEN

[Extra-Minute]

2BUTTON[Pushed]

2OVEN*

[Cooking]

7OVEN

?? Timed-Out ??2

USER??ButtonPushed??

4CLIGHT[On]

5 USER??Door-Opened??

7LIGHT[Off]

7POWER-TUBE

[Off]

7BEEPER[Sounded]

1BUTTON

[Pushed]

1POWER-TUBE

[Energized]

1USER

??ButtonPushed??

1OVEN

[Cooking]

6USER

??Door-Closed??

IPDOOR[Closed]

6LIGHT

[Off]

8USER

??Door-Opened??

8DOOR

[Open]

4CLIGHT

[On] 3CBUTTON@[Disabled]

3COVEN[Open]

5DOOR

[Open]

3CBUTTON[Disabled]

5OVEN

[Cooking-Stopped]

7OVEN

[Cooking-Finished

IPOVEN[Idle]

3CBUTTON[Enabled]

5POWER-TUBE

[Off]

OVEN INPUT

OVEN OUTPUT

Legend

6OVEN[Open ]

1 BUTTON[Pushed]


6USER

??Door-Closed??

IPDOOR

[Closed]

6LIGHT[Off]

8 USER??Door-Opened??

8 DOOR[Open]

6OVEN[Idle]

3CBUTTON[Enabled]

Traversed Design Behavior Tree Evolving Component

Dependency Network6

OVEN[ Open ]

1DOOR[Closed]

3CBUTTON

[Enabled]

USER

DOOR

LIGHT BUTTON

OVEN

4CLIGHT[On]

1BUTTON[Pushed]

1POWER-TUBE

[Energized]

1USER

??ButtonPushed??

6USER

??Door-Closed??

6DOOR[Closed]

6LIGHT[Off]

6OVEN[Idle]

8USER

??Door-Opened??

8DOOR[Open]

4CLIGHT

[On]3C

BUTTON

[Disabled]

3CBUTTON[Enabled]

Traversed Design Behavior Tree Evolving ComponentDependency Network

1DOOR

[Closed]

3C BUTTON[Enabled]

USER

DOOR

LIGHT

BUTTON

OVEN

POWER-TUBE

6OVEN

[Open ]

1DOOR[Closed]

3CBUTTON

[Enabled]

USER

DOOR

LIGHT

BUTTON

OVEN

POWER-TUBE

BEEPER


20/46

Oven component and all the components that the Ovenoutputs to is shown below.

In this particular example, we can just use a single inputchannel for each of the input components and a single

output channel for each of the outputs to externalcomponents. With a more complex example, where there aredata-flows and/or more than one set of states within acomponent the design of the component interface may needto be more complex.

The following component-interface simplification rules canbe used to assist with the in terface design:

1. Control states that belong to the same state-set can behandled by a single input/output channel (e.g. Light -off/on has only one state set, while button has two statesets pushed and enabled/disabled)

2. Different data from the same component can be often behandled by a single composite data flow and I/Ochannel.

3. Different data to/from different components requireseparate inputs/outputs

4. The application of rules 1, 2 and 3 should be temperedby the need to minimize the number of inputs /output sfor a component but also to avoid sending unwantedcontrol or other data to/from components.

The interface design process we have outlined needs to berepeated for each of the components in the system. As anexample, in the Microwave Oven case study, the Lightcomponent has three inputs in the generated ComponentDependency Network (CDN). In this case we can simplify itsinterface to a single input that controls the ON/OFFfunctionality.

(c) Component Integration using Behavior Mapping

Once the refined interfaces for each component have beendesigned we can use all the information accumulated in thisstep to finalize the design at the component level togetherwith a detailed description of the system architecture. What

this finalization entails is making sure that all the behaviorexpressed in the design behavior tree (DBT) maps onto themodified component-dependency network (CDN) in whichthe original component interfaces have been replaced by therefined component interfaces.To proceed we apply a mapping process not unlike thecomponent dependency transformation we applied toconvert the design behavior tree into the componentdependency network. The difference this time is that we mustensure that each component in the revised CDN gets thenecessary control and data-flows on its inputs and outputsto accommodate all of the behavior expressed in the designbehavior tree. As with the component dependency

transformation we start at the root of the design behavior treeand work down the tree as shown below. For this mappingprocess we use a sequential numbering process to record allcomponent-state transitions.

OVEN

LIghtPowerTube Button Beeper

Light User Power-

Tube


21/46

We do this mapping using cohesive chunks of behaviorthat correspond perhaps to a use-case or an individualfunctional requirement. The mapping for the first chunk ofbehavior in the design behavior tree is shown above.Numbers corresponding to individual component-staterealizations are recorded on the flows between componentsand the corresponding numbered actions are stored in atable. This process continues until all of the component-states in the design behavior tree are mapped to thecomponent-dependency network see below.

Once this mapping process has been finalized we have

completed all the external aspects of the component-baseddesign. When this step is finished a complete design shellhas been produced in which all components have beenidentified along with their interfaces and the control flowsand data-flows that define all component interactions.Whatis important to recognize is that the component-baseddesign, which may serve as both the business model andsoftware architecture for a system has been formally derivedfrom the design behavior tree. This is an importantadvantage of genetic software engineering over other designmethods, where the software architecture tends to be arrivedat by much less clearly defined paths. That is, with GSE, the

1USER

??Door-Closed??

2DOOR[Closed]

3LIGHT[Off]

5OVEN

[Idle]

4BUTTON

[Enabled]

OVEN

0

DOOR

LIGHT BUTTON

3

1

2

4

Behavior Tree Fragment

Component-based Design Fragment

0 OVEN[ Open ]

USER

5

1DOOR

[Closed]

3CBUTTON[Enabled]

USER

DOOR

LIGHT

BUTTON

OVEN

POWER-TUBE

BEEPER

0

1

155

10

24

30

256

11

16

2

7

26

19 19

3 8

13 21

1823

29

14

28

20

22

4 9

1212

27

17

No. STATE No. STATE

0 Oven - Open 16 User - Button-Pushed

1 User - Door Closed 17 Button - Pushed

2 Door - Closed 18 Oven - Extra-Time

3 Light - Off 19 Oven - Timed-Out

4 Button - Enabled 20 Power-Tube - Off

5 Oven - Idle 21 Light - Off

6 User - Door Open 22 Beeper - Sounded

7 Door - Open 23 Oven - Cooking Finished

8 Light - On 24 Oven - Idle

9 Button - Disabled 25 User - Door Open

10 Oven - Open 26 Door - Open

11 User - Button Pushed 27 Button - Disabled

12 Button - Pushed 28 Power-Tube - Off

13 Light - On 29 Oven - Cooking Stopped

14 Power-Tube - Energized 30 Oven - Open

15 Oven - Cooking


22/46

process is repeatable by different designers and has thepotential to be automated.

The task that remains is to design the internal behavior ofeach of the components that fit within the component-baseddesign we have derived from the design behavior tree.Fortunately the design behavior tree holds the knowledge weneed to design the behavior of each individual component.

STEP 5: Projection of the Behavior of Each Individual

Component from the Design Behavior Tree.

When we examine a design behavior tree involving a numberof components we notice that the component-states for a

particular component are often widely dispersed throughoutthe tree. In designing modules/components what wetraditionally do is concentrate, localize and encapsulate allthe desired behavior of a particular component in one

place the design behavior tree has not done that for us.The fundamental question to ask is therefore how does thedispersed behavior of a component that we see in a designbehavior tree relate to the normal localized behavior we

usually associate with components? It turns out that thedispersed behavior of individual components that we see in

a design behavior tree can be concentrated into the

localized behavior we usually associate with components.To extract an individual components behavior from a designbehavior tree we simply projectit from the DBT. One way tothink of projecting a components behavior from a DBT is toimagine all other component-states to be removed from thetree, but that the skeleton of connections betweencomponent-states remains. That is, the component-states ofthe projected component remain on the design behavior treeskeleton in their same relative positions to one another, withthe same connections this gives us a components

behavior projection from the tree.

The process of constructing the behavior for a componentproceeds in two stages. In the first stage we project theraw component behavior tree from the DBT. Such rawbehavior trees are often incomplete, in that they can reachstates of behavior where the context and/or the domainsuggest that other behaviors should take place but, thedesign, as expressed in the original requirements andreflected in the DBT, does not allow for it. The two rawcomponent projections we will do below for the Microwaveexample illustrate this problem. It is therefore necessary toemploy a step that carefully examines each projected

component behavior tree and augments it to make sure that itis complete. The criterion for detecting incompletenessproblems and rectifying them is relatively straightforward.We will use several examples to illustrate these variouspoints .

(a) Project raw component behavior tree from the design

behavior tree.

In the design behavior tree above we have identified all thecomponent states for the Oven System component. Thesestates identify the behavior of the oven component asoriginally specified in the functional requirements.

The result of projecting the Oven System component fromthe design behavior tree is shown below. What we see fromthis projection is that the resulting oven system behaviortree expresses the high-level external behavior of the system,as reflected in terms of allowable transitions between systemstates. This is the behavior we would access and util ize if wewere to employ the Microwave system as a component in ahigher level system. As we mentioned earlier includingsystem states in the design of a system makes that systemeasier to understand at a high level and also easier to utilizeas a component in a larger system. The information

2OVEN

[Extra-Minute]

2BUTTON[Pushed]

2OVEN^

[Cooking]

7OVEN

?? Timed-Out ??2

USER

??Button-Push??

4CLIGHT

[On]

5USER

??Door-Opened??

7LIGHT

[Off]7

POWER-TUBE[Off]

7BEEPER[Sounded]

IPBUTTON

[Pushed]

1POWER-TUBE

[Energized]

1USER

??Button-Push??

IP OVEN[Cooking]

6USER

??Door-Closed??

IPDOOR

[Closed]

6LIGHT

[Off]

8USER

??Door-Opened??

IPDOOR

[Open]

4CLIGHT

[On]3C

BUTTON@

[Disabled]

3COVEN [Open]

IPDOOR[Open]

3CBUTTON

[Disabled]5

OVEN

[Cooking-Stopped]

7OVEN

[Cooking-Finished

IPOVEN[Idle]

3CBUTTON[Enabled]

5POWER-TUBE

[Off]

6OVEN

[ Open ]


23/46

encapsulated in a component behavior tree may be useddirectly to guide the implementation of the component.However before we can do that we need to assess thecompleteness of the components behavior.

(b) Identify and correct any completeness problems with the

components raw projected behavior tree.

When we examine a components projected behavior tree weshould normally expect that each leaf-node component-staterecurses back to a non-leaf-node, which in some cases maybe the root of the component behavior tree. If a leaf-node

does not have this property, then potentially, its behavior isinconsistent and incomplete. For our Oven Systemcomponent, only the OVEN[Cooking] leaf-node exhibitsconsistent behavior.

Above, we have added two additional recursive leaf-nodesto make the components behavior consistent with respect tothe current set of system states. Thisconsistency/completeness modification of a componentsbehavior does not guarantee completeness but it provides avery useful check on the quality of a components design. In

our experience with GSE, the behavior of components ascaptured in functional requirements very frequently fails thisconsistency check. We would therefore claim that theprocess of component and system design that we havedescribed should improve both component and also overallsystem reliability.

To further illustrate these ideas given below is the Usercomponent projected from the design behavior tree. As withthe Oven component, we find that the behavior of the Usercomponent is inconsistent.

To correct these problems we have made two of the leaf-nodes recursive and added a component-state, pertaining tothe door being closed. The results of these modifications areshown below.

What is reassuring about these and other componentprojections from the design behavior tree is that when weexamine their semantics carefully we see that they expressthe behavior we would expect. That is, the user can, forexample, push the button more than once when the door isclosed. Also the only two operations that are possible afterthe button has been pushed, is to push it again or open thedoor. This is also the behavior we would expect. Finally,when the door is open the only option the user has is toclose it. This is also as we would expect. So, we have endedup with a component that may be used to guide the

2OVEN

[Extra-Minute]

2OVEN

[Cooking]

7OVEN

?? Timed-Out ??

1OVEN

[Cooking]

6OVEN

[Idle]

3C OVEN ^[Open]

5 OVEN[Cooking-Stopped]

7 OVEN[Cooking-Finished

OVEN-SYSTEM COMPONENT - Incomplete Behavior

6 OVEN[Open]

USER COMPONENT - Incomplete Behavior

1USER

??Door-Closed??

1USER

??ButtonPushed?? 8USER

??Door-Opened??

2USER

??ButtonPushed??5

USER??Door-Opened??

USER COMPONENT - Complete Behavior

1USER

??Door-Closed??

1USER

??ButtonPushed??8

USER

??Door-Opened??

2USER ^

??ButtonPushed??5

USER ^??Door-Opened?? 1

USER ^??Door-Closed??

2OVEN

{ Extra-Minute }

2OVEN ^

[Cooking]

7OVEN

?? Timed-Out ??

1OVEN

{ Cooking }

1

OVEN

[Idle]

3COVEN ^{ Open }

5OVEN

{Cooking-Stopped]

7OVEN

[Cooking-Finished3C

OVEN ^[Open]

1OVEN

[Idle]

OVEN-SYSTEM COMPONENT - Complete Behavior

3COVEN[Open]


24/46

implementation of the behavior of the user interface. Usingthis sort of modeling is very valuable for designing userinterfaces with a complex set of interactions.We can in a similar way project out and establish thecomplete behavior for the Button component.

The button component is interesting because it throws upthe possibility that a component can have more than onepossible start -state. That is, if the door is closed it can startin an enabled state, whereas if the door is open it will need tostart in a disabled state. In other words, at start-up,depending on its environment, a component can start in morethan one state. We need to recognise and accommodatesuch possibilities in the design of the behavior ofcomponents. One way of responding to this situation is tosay that components with more than one start -state musthave more than one behavior tree. In the present case, thiswould mean we could draw a behavior tree for thecomponent with BUTTON@[Disabled] as the root of the

tree. A more practical way to proceed is to adopt the ideathat if a component has not been accessed before then it is inan uninitialized state, BUTTON[ ]. We can then structureits behavior so that on start-up it can only transition from theuninitialized state to one of its start-up states, depending onthe state of its external environment. This is shown in thefigure below.

BUTTON

[ ]

BUTTON $[Enabled]

BUTTON@ $[Disabled]

Recognizing this initialisation issue in the design of thebehavior of components, adds to their reusability and it canavoid problems with the starting up of component-basedsystems. That is, it makes it easy for a component-basedsystem to properly configure its initial state to be in harmonyrather than in conflict with its external environment. We haveused the symbol $ to identify start-states in the notation.

We will not document the projection of the behavior trees fo

Microwave Oven 1

Documents

Transcript of Microwave Oven 1