Domain-Oriented Engineering of Elevator Control Software: A Product ...

4 downloads 8380 Views 432KB Size Report
Keywords: domain engineering, elevator control software, pr oduct line practice ..... Car Call Handling. Hall Call. Handling. Operation Mode. Handling. Hall Call.
Domain-OrientedEngineeringoElevator f Control KwanwooLee,KyoCKang, . EunmanKoh

Software:AProductLinePractice

1

Wonsuk , Chae,Bokyoung Kim,Byoung Wook Choi

Departmentof ComputerScienceandEngineering Pohang University oScience f andTechnology (POSTEC

H)

San31Pohang,Kyoungbuk 790-784,Korea E-mail:{kwlee,kck,emkoh,sein92,bogus}@postech.

ac.kr

Abstract Developmentandmaintenanceofembeddedcontrolsof manufacturingindustrybecauseofthediversityof requirements,andthequickresponseom f arketcomp competitivemarket,embeddedcontrolsoftwaremust

twarehasbeenadifficultchallengeforthe customers’needs,rapidlychangingmarket etition.Inordertoretainamarketshareina bedesignedtorespondquicklytoboththe

customerandthemarketwithhighquality software. LGIndustrialSystemsCo.Ltd.(LGIS),oneoKorea f hasalsobeenfacedwiththesamedifficultyinthe software(ECS).InordertohelpLGISimprovethep qualityofitsECS,wehaveadoptedadomain-orient

’sleadingsuppliersoelevator f controlsystems, developmentandmaintenanceoelevator f control roductivityandmaintainabilityaswellasthe edapproachforreuse,andverificationand

validationtechnology forimprovingsoftware qualit

y.

Wehavefoundthatwecanreducemaintenancecosts utilizingreusableandadaptablecomponentsthatca requirementchanges,andhaveverifiedandvalidate

drasticallyaw s heavedevelopedthesoftwareby neasilyaccommodatecontextualaswellas dECSintheearly phaseodevelopment. f

Keywords:domainengineering,elevatorcontrolsoftware,pr validationof embeddedsoftware,productivity,maintainability,r

1

DepartmentofComputer andCommunicationsEngineer POSTECH. AlsoaffiliatedwithLGIndustrialSystems 2 DevisionoMechanical f andControlEngineering,Su IndustralSystemcCo.,Ltd.

oductlinepractice,verificationand eliability.

ing,GraduateSchoolforInformationTechnology, Co., Ltd. nmoonUniversity. AlsotheworkwasdoneinLG

1

2

1 Introduction Developmentandmaintenanceoembedded f controlsof

twarehasbeendifficult a challengeforthe

manufacturingindustrybecauseofthediversityof

customers’needs,rapidlychangingmarket

requirements,andthequickresponseom f arketcomp

etition.Inordertoretainamarketshareina

competitivemarket,

va arietyoproducts f thatsatisfycustomerspecifi

marketneedsmustbeproducedasatwiftpace.Ino

nc eedsandrapidlychanging

therwords,embeddedcontrolsoftwaremustbe

developedtomeetcustomerandmarketneedsandto

respondquickly tothemwithhighquality.

LGIndustrialSystemsCo.Ltd.(LGIS),whichisone

ofKorea’sleadingsuppliersofelevator

controlsystems,hasbeenfacedwiththesamediffi

cultyinthedevelopmentandmaintenanceoits f

elevatorcontrolsoftware(ECS).Inthepast,softw

aredevelopersaLGIS t designedthesoftwarefor

asinglesystemthatsatisfiedaspecificcustomer’

sneeds.Littleattentionwaspaidtothe

developmentofaproductfamilyoftheECSdomain,

whichsatisfiesadiversityofcustomers’

needs.As result, a LGIShassufferedfromlargein

vestmentandlongproductlifecyclesevenwhen

avarietyosfimilarproductshadtobedeveloped.

Also,sinceECSinteractswithvariousexternal

devicessuchassensors,arotaryencoder,etc.,an

dthechangesofexternal

happensduetorapidlychangingmarketneeds,thes

oftwarehadtobemodifiedfrequently.

Moreover,inordertokeeptheproductdeliverysch modifiedthesoftwarein

devicesfrequently

edule,iw t asoftenthecasethatdevelopers

anunmanageableway.Thesesituationsmadethesoft

wareerror-prone;

thusresulting inincreasing maintenancecosts.

DuringthemaintenanceoECS f from1998to1999(i.

e.,afterdeliveryoelevator f controlsystems

tocustomers),engineersdiscoveredandfixed77er

rors.Wehaveanalyzedandclassifiedtheerrors

ofECS,whichfalllargely intothefollowingcateg

ories:



Behavioral errors:undesirablesequencesoexecution, f unreachables



Functional errors:incorrector incompletecomputationallogic.



Externalinterfaceerrors

i:nterfaceinconsistenciesbetweenthetargetsyst

environments,(e.g.,violationsoaf ssumptionsocr

tates,etc.

emandexternal

onstraintsbetweenthetargetsystemand

externalenvironments). 

Implementationerrors errors : madewhileintroducingimplementation tothefinalcode.

2

dependentinformation

Behavioralandexternalinterfaceerrorsledtosys

temfailure,whichmeans

unavailabilityof

service,moreoftenthanunitoperationfailure,wh

ich meansunavailability ounit f operationsuchas

failureinlightingfloor a lamp.(Seethebottoml

eftbarchartofFigure1.)Moreover,itisdifficu

todetectanddebugtheseerrors.Asshownintheb

lt

ottom-rightbarchartofFigure1the , numberof

thebehavioralandexternalinterfaceerrorsthatw

erefixedwithin

w a eekomonth r was15(83%of

allbehavioralerrors)and6(66%ofallinterface

errors),respectively.Ontheotherhand,the

numberofthefunctionalandimplementationerrors

thatwerefixedwithinweek a omonth r was8

(35%ofallfunctionalerrors)and3(11%ofallim

plementationerrors),respectively.Iitsour

observationthatbehavioralandexternalinterface

errorsfoundduringmaintenancecouldcostover

ahundredtimesthecostoffixingthemintherequ

irementphase.Therefore,theearlyverification

andvalidationo(internal f andexternal)behaviors

ofECSarerequiredforimprovingthequalityof

thesoftwareandreducing maintenancecosts. CausesofError 27

30

25 20

#ofErrors

16 12

15

7

10

7

6

2

5

0

Functional

Behavioral

0

ExternalInterface Implementatio n

Contextualchanges

16

6

7

27

Requirementaddition

7

12

2

0

EffortsofErrorCorrection

EffectsofError 25

18

20

16 14

15

12 10

12 10

#ofErrors

24

17

18

6

8

6

3

4

8

10

6

5

6

14

15

#ofErrors

0

Unitoperationfailure Systemfailure

ExternalInterface

Behavioral

0 ExternalInterface

Behavioral

Day

15

3

18

6

3

17

Week

8

14

6

2

5

12

6

10

Month

0

1

0

1

3

EmpiricaldataoECS f inLGIS

Functionalandimplementationerrorsdidnothavea

seriousinfluenceonasystem’ssafetyor

availabilityosfervicewhencomparedtobehavioral

andexternalinterfaceerrors.(Seethebottom

3

1

Implementatio n

Functional

Figure1.

Implementatio n

Functional

2

1

0

2 0

3

3

5

24

leftbarchartofFigure1.)Although10implementa stillled tosystemfailure,mostoftheerrorswer

tionerrors(37%ofallimplementationerrors) feixedwithin day. a (See thebottomrightbarcha

ofFigure1.)Iitsourobservationthatthefuncti

onalandimplementationerrorsweregenerally

madebecausethesoftwarehadbeendesignedwitha

singlesystemmentalityandwithout

consideringvariations(i.e.,algorithmicdifferenc

es,etc.)intheECSdomain.Therefore,

commonality andvariability analysisfrom daomain

perspectivemustcome aheadoengineering f of

ECSinordertoincreasereusability andadaptabili

ty oECS. f

Contextualchanges(i.e.,changesohf ardwareanda

norganization’spolicy)generallyledtomore

errors than requirement addition.(See the upper ba

chart r of Figure1.) This is mainly duettohefac

thatECS interactswithvariousexternalenvironmen

ts:contextual changesare the primary source

an ECS’smodification.Therefore,inordertoimprove

themaintainabilityofECS,contextual

changesthatpredictably occurmustbepreventedfr

Ourstrategies 

om spreading intoother partsothe f software.

for solving theaboveproblemsoECS f aresummarize

dbelow.

Behavioralspecifications,whichcontrolandcoordi

natefunctionalcomponents,areseparated

fromfunctionalcomponents,whichperformmostlyda

tatransformationsocr omputations,so

that theinternalorexternal behaviorsof ECS can

beverified andvalidated itnhe early stageof

softwaredevelopment. 

Functionalcomponentsaredesignedintoreusablean

dadaptablecomponentswithstandard

and stable interfaces so thatthey can bceommonly

used ibnehavioralspecifications of ECS.In

ordertodothis,weperformcaommonalityandvari

abilityanalysis(i.e.,featureanalysis)and

usetheresultsfor thedevelopmentofreusableand 

rt

adaptablecomponents.

Implementationtechniques(i.e.,communicationmeth drivers)areseparatedfromthefunctionalcomponen

ods)orenvironments(i.e.,device tsbecausetheimplementationtechniques

orenvironmentscanchangeforthesamefunctions.

Inthispaper,wefocusonengineeringtheECSofL

GISforthepurposeofimprovingthe

productivity,maintainability,andqualityofthes

oftware.Forthispurpose,wehaveintegrateda

domain-orientedmethod(i.e.,FORM[6])andreal-ti

mespecificationanalysistechniques(i.e.,

ASADAL/SIM[8]andASADAL/PROVER[9])intoaCASEe describedintheSection2We . showhowtocreated

nvironment,whichisbriefly

omainmodelsof ECSforfuturereuseandhow

4

t of

toapplythedomainmodelstnew oa productdevelop

mentintheSection3and4respectively. , The

Section5presentsthequantitativeevidencethats

howstheeffectivenessoour f method.Finally,we

concludethispaper with discussion a olessons f le

arnedfrom our experience.

2MethodOverview Productivity,maintainability,andqualityosfoftw

areareessentialpropertiesforagoodsoftware

engineeringmethod.Inthissection,weshowhowto

incorporatethosepropertiesintoengineering

ECS.Thefollowing arekey featuresoour f method: 

Domain analysis



Separationobehavior, f function,andimplementatio



Architecturebasedsoftwarecompositionandgenerat OperationalModel

noenvironment r ion MSD Pre-condition

Post-condition

Statechart

DFD

High-level behavior

ComponentModel

Domain Analysis (i.e.,feature analysis)

Component compName implements feature “envFeature” Computational optional env1Feature functions optional env2Feature ...... { $Environment env =new$Environment ...... }

Architecture BBased Architecture ased Composition & Composition & Generation Generation

ObjectModel Implementation orenvironment

Environment

env1

env2

env3

Figure2Method . framework Domainanalysis[3,

4, 5, 13, 14],whichexploitscommonalityandvariabilityin

requirementforaproductlineorganization.Thedo

da omain,iskey a

mainanalysismethodappliedinthispaperis

5

feature-orientedanalysis[5, productfeatures(i.e.,

6],whichattemptstoanalyzecommonalityandvaria

capability, operatingenvironment , domaintechnology and ,

techniquefeatures).IntheECSdomainwefoundthat levelbehaviorsotfhesoftwareand inthedomain.Also,

bilityintermsof implementation

capabilityfeaturesusuallyrepresenthigh-

domaintechnology featuresrepresentcomputationalfunctions

implementationtechnique or

implementationorenvironmentspecificinformation

operatingenvironmentfeatures

represents

thatisusedfordefiningcomputational

functionsinthedomain.

Inourmethod,high-levelbehaviorsarerepresented

asoperationalmodels.AsshowninFigure2,

externalbehaviorsosf oftwarearespecifiedbyusi

ngmessagesequencediagrams(MSD),while

internalbehaviorsaremodeledaSs tatechartsandd

ataflowdiagrams(DFDs).Inordertoimprove

thequalityothe f softwareandtoreducemaintenan

cecosts,ourmethodsupportsbothverification

andvalidationoftheoperationalmodels.ASADAL/SI analyzerforvalidationoreal-time f software,and

M[8]isadiscreteeventsimulatorand ASADAL/PROVER[9]istemporal a logicbased

proofsystemforverificationofcriticalsystemsp

ropertiessuchassafety,liveness,and

responsiveness.

Computationalfunctions,as howninFigure2,are

modeledascomponents,whichareusedto

definefunctionalspecificationsinDFDs.Component

smustbedesignedsothateachcomponent

canbeasilyreusedinavarietyocontexts. f Ino

rdertoaccomplishthis,domainanalysismustbe

aheadocomponent f design.Inourmethod,thefeatu

re-orientedanalysismethodius sedtoanalyze

commonalityandvariabilityofproductsinthedoma

in.Applyingtheresultsoftheanalysis,

reusableandadaptablecomponentsaredesigned.Det

ailsofthismethodcanbfeoundin[7].

IntheECSdomain,implementationtechniquesorenv

ironmentsare

moreapttobechanged

comparedtocomputationalfunctions.Therefore,the

ymustbeseparatedfromfunctional

componentsandmodeledarseusableobjectsthatenc

apsulatetheirspecificinformation(i.e.,ADT,

communicationmethods,devicedrivers,etc.)sotha

theirchangesarenotpropagatedintoother

partsotfhesoftware.Here,thefeature-basedobje

ct-orientedengineeringmethod[10]ius sedfor

thedevelopmentofreusableobjectsthatarecommon

ly usedinthedomain.

6

Softwarearchitectures[2,

11,12,

15]play central a roleinthesuccessfuldevelopme

line.Mostorganizationswithproductlineexperien

ntof paroduct

cehavetheirownsoftwarearchitectures,which

serveasframeworksforcomposingandadaptingdoma

incomponents.Inourmethod,multiple

softwarearchitecturescanbedevelopedthroughthe

activitiesofdividinghigh-levelsoftware

specificationsandallocatingthedividedspecifica

tionsintodifferentarchitecturalcomponents(i.e.

subsystemcomponentsortaskcomponents)basedonp

erformanceissuesoranorganization’s

policy.Basedonthesoftwarearchitectures,domain

componentsdevelopedbydomainengineering

activitiesarecomposedandadaptedforanorganiza

tion’sproductlines.Finally,platform(i.e.,

implementationlanguagesooperating r systems)depe onthe

,

ndentcodesareproducedautomaticallybased

selectedsoftwarearchitecture. Application Engineering User’s Requirements

Feature & Component Selection

Model Validation

Architecture Architecture Selection & Selection & Adaptation Adaptation

Code Generation

Application Software Context Context Analysis Analysis

Feature Modeling

Operational Modeling

Domain Knowledge

Architecture Modeling

Component Modeling Object Component Development

Candidate Object Identification

Legend

Reusable Component Development

Process Flow

Domain Engineering

Figure3Engineering . process

3DomainEngineeringoElevator f Software Thepurposeodf omainengineeringitsodevelopdom

ainmodelsthatmaybeusedindeveloping

productsforagivendomain.As howninFigure3,

therearefivephasesinASADALdomain

engineering:contextanalysis,featuremodeling,op

erationalmodeling,componentmodeling,and

architecturemodeling.Duringcontextanalysis,we

firstidentifytheexactscopeothe f domainand

theintendeduseotfhedomainproducts,variousex

ternalconditions,aswellastrytoanticipate

interactionswiththeexternalworld.Then,during

thefeaturemodelingphase,commonalityand

variabilityamongproductsinadomainareanalyzed

intermsoproduct f features,andrepresented

7

asa

“featuremodel.”Basedonthefeaturemodel,high-l

eveloperationalaspectsothe f domainare

modeledfromtheperspectiveobehavior f andfuncti

onitnheoperationalmodelingphase.The low-

levelcomputationalaspectsotfhedomainareengin

eeredintoreusableandadaptablecomponent

specifications,whichcaneasily accommodatevariat

ions(i.e.,environmentalvariations,algorithmic

variations,etc.)inthegivendomain.Finally,arc

hitecturemodelingdefinesfeasiblearchitectures

wherethereusablesoftwarecomponentsandtheirco

nfigurationsareconstructed.Althoughthe

contextanalysisisanimportantpartofdomaineng

ineering,wefocusonfeaturemodeling,

operationalmodeling,componentmodeling,andarchi

tecturemodeling inthispaper.

3.1FeatureModeling Thepurposeofeaturemodelingistoanalyzecommo

nalitiesanddifferencesamongafamilyof

productsintermsoproduct f features,andthento

organizetheanalysisresultsintofeature a model,

whichisusedtodevelopdomainmodels(i.e.,opera

tionalmodels,componentmodels,and

architecturemodels).

Productfeaturesfalllargelyintocapability featu

res(i.e.,servicesofunctions r providedbsyoftwa

products),operatingenvironmentfeatures,domaint techniquefeatures.

echnologyfeatures,andimplementation

Variousrelationshipsexistamongthesefeatures,s

aggregation,utilization,andmutualdependency.Fe specifiedotherwise),

re

uchasgeneralization,

aturesthemselvesmaybemandatory(unless

“optional”(denotedwith circle), a or

“alternative”(denotedwithanarc).

Featuremodeling consists ofactivitiesfor identif

yingproductfeatures,classifyingthem,organizing

them as saetof coherent models and validating the

models.Detailsof each activity andexamples of

otherdomainscanbfeoundin[6] and[7].

Figure4showsasimplifiedfeaturemodelofECSin relatedfeatures(e.g.,

LGIS.Capabilityfeaturesconsistofservice

ManagementService and

ControlService ),operationfeatures(e.g.,

Handling, IndicationHandling , DoorHandling , MotorHandling,

etc.),andnon-functionalfeatures

(e.g., Speed, Regulations, Purpose,etc.).Operating environmentfeatures include har relatedfeatures(e.g.,

CPU, WeightSensor , PositionSensor,

dware platform

etc.)andsoftwarerelatedones(e.g.,

OSand Communication Interface ). Domain technology features represent the waysof servicesor operations.For example,

implementing

Driving Control isan operationocontrolling f themovementof

8

Call

anelevatorcage.Thisoperationiismplementedby Methodsand

VelocityProfileMethods

twodomaintechnologies(e.g., ).Comparedtodomaintechnologyfeatures,implemen

techniquefeaturesaremoregeneric,andmaybeuse SpeedDecelerationProfile

usesthe

tation

dinotherdomains.Forexample,the

ComputeQuadraticEquation,

Formal Profile The . HighSpeed Deceleration Profile theelevatordomain,butthe

DrivingControl

High

ComputeCubicEquation,

may notbeuseful in other domainsexceptfor

ComputeQuadraticEquation,

ComputeCubicEquation,

and

Profilearegenerally applicableinother domains. Capability

E/LControl System

ManagementService

OperationMode Handling

Control Service

Call Handling

IndicationHandling

Speed

Door Handling

Hall Call Registration

Start Control

Regulations

Safety Check

Motor Handling

Virtual Call Handling

Hall Call Handling

Car CallHandling

Driving Control

Cage Capacity

Freight Elevator

Purpose

Passenger Elevator

Stop Control

Hall Call Cancellation

Operating Environment

Weight Sensor

CPU

32bit MPU

Digital Weight Sensor

16bit MPU

Position Sensor

Analog Weight Sensor

Communication Interface

Absolute Position

SlowDown Switch

Limit Switch

OS

Nuclues

VxWorks

Hall Interface

Maintenance Tool

Tornado

Driving Control Methods

ExpressDriving Control

Stop Control Methods

Group Controller . Interface

HighSpeed Deceleration Profile

Monitoring Interface

Motor Interface

Direction Determination Method

Deceleration Profile Calculation

Acceleration Profile Calculation

LowSpeed DrivingControl

Car Interface

Velocity Profile Methods

DomainTechnology Starting Control Methods

Leveling Profile Calculation

Automatic Direction Determination

Forced Direction Determination

LowSpeed Deceleration Profile

Legend

Implementation Technique Compute Quadratic Equation Event Handling Method

Table Look-up Method

Compute Cubic Equation

Formal Profile

Bit Manipulation Method

Exponential Profile

Mandatory Feature

Optional Feature

Search Method Alternative Feature ComposedOf

SharedMemory Communication Method

Priority Determination Method

and

Sequential Search Method

Binary Search Method

DepthFirst Search Method

Figure4Feature . modelofelevatorcontrolsoftwar

9

Generalization/ Specialization ImplemetedBy

e

Formal

Therealfeaturemodeliscomposedo490 f features domaintechnology,

(157capability,22operatingenvironment,291

and20implementationtechniquefeatures).Forabou

experts,2methodologistsand1moderatorwereinvo

lvedinthemodelingactivity.Itisour

experiencethatclarifyingthedomainboundariesan beforefeaturemodeling

3tmonths,8domain

dstandardizingdomainterminology mustcome

asdifferentperceptionsofdomainboundary anddom

leadtowastefuldiscussionsbetweenmodelersandm

ainterminology often

ayproducecomplicated a featuremodelwith

redundantinformation.

3.2OperationalModeling Thefeaturemodelcapturesonlythestaticaspects

ofagivendomain,i.e.,itcodifiesthestructural

andcompositionalaspectsofeaturesinthedomain

Since . theelevatorcontrolsoftwarerequires

muchcontrollogicforitsoperation,thedynamicc

haracteristics mustbemodeledinanexecutable

formforthepurposeoanalysis, f whichids iscusse

dinsection5.2.Inourmethod,MSD(message-

sequencediagram),Statechart,andDFD(dataflowd

iagram)areusedtomodelthedynamic

characteristicsinthedomain.Thenotationsandse

manticsothese f operationalmodelsarereferred

toin[8].

Figure5showstheguidelinesfordevelopingtheop isouropinionthatthehigh-levelfeaturesinthe

erationalmodelsbasedonthefeaturemodel.It featurehierarchyaremainlyrelatedtothecontrol

behaviorsofproductswhilethelow-levelfeatures

arerelatedtothecomputationsordata

transformationsopf roducts.Therefore,capability themainsources

andhigh-leveldomaintechnologyfeaturesare

fordevelopingtheoperationalmodels,whiledomain

technique,andoperatingenvironmentfeaturesarem

technology,implementation

ainlyusedtodevelopcomponentmodels,

whichidiscussed s inthenextsection.

Aserviceisauservisiblesystemfunctionthatis

metbyasequenceoof perationsprovidedby

systems.AsshowninFigure5service , featurescan

beexpressedinmessagesequencediagrams,

whichshowthemessageinteractionsamongthesyste

mandexternalentities.Ontheotherhand,

operationalfeaturesandhigh-leveldomaintechnolo

gyfeaturescanbeusedtospecifyandrefine

DFDsandStatecharts.Thatis,mandatoryfeaturess

erveatshebasisfordefininganabstractDFD

andStatechart.Alternative andoptionalfeatures a

reembedded intothe models during refinementof

theabstractmodels.

10

OperationalModels

FeatureModel Capability feature

MSDforSF ServiceFeature

1

Servicefeatures Pre-condition

SF1

SF2

SF3

SF4

Operation Feature OF1

OF2 OF5

OF3

Post-condition

refinements

OF4

Statechart

DFD

OF6 Mandatory features

Domain technology feature Refinement by DF21 DF1

DF3

DF2

Refinement by DF22

DF4 Alternative/optional features

DF21

DF41

DF22

DF42

Figure5Relationships . betweenthefeaturemodela

ndoperationalmodels

Statecharts CarStatus / Braking, MotorPowerOff CarStop

tm(en(BrakeOn), 600) / MotorPowerOff Stopping

EmergencyStop / Braking, MotorPowerOff, Run=false

[Run==true] / MotorPowerOn

[HighMode==true & Dist < & 5Speed< 2] / Run=false,Braking

CarRun tmd(VelocityProfileInitialization) RunReady

En(BrakeOff)

RunStart

HighSpeedMode

Running

[SlowMode==true & Run==false] / Braking

VelocityProfileGeneration

Running

Running

Domain Technology Layer

LowSpeed Mode

Driving Control Methods

VelocityProfileGeneration

tmd(StepGen3) [!in(DecelerationPointDetect)] /Step=4 Acceleration

RatedVelocity

tmd(StepGen3) [in(DecelerationPoint)] Step / =4 Deceleration

DecelerationPoint / Step=5

ExponentialAcceleration tmd(StepGen2) Step / = 3 UniformVelocity

StopZoneDetect

Express Driving Control

Leveling

Low Speed DrivingControl

RunningStatus [AdvancedFloor == CallFloor] StandBy

DecelerationPrepare

[AdvancedPosition> ServicePosition] / DecelerationPoint StopZone

DecelerationPointDetect

[OpenArea==true & / StopZoneDetect

CurrentFloor==AdvancedFloor]

Figure6Alternative . refinementofanabstractSta

11

techart

Forexample,Figure6showshowanabstractStatech

artcanbreefinedintwodifferentways.ECS

controlsthemovementofanelevatorcage.TheStat

echart(i.e.,

CageStatusinFigure6shows ) the

abstractbehaviorofcontrollingacage’smovement.

Thestate(i.e.,

berefinedintwodifferentways,dependingonthe

typesodecisions f (i.e.,

or LowSpeedDrivingControl

Running)intheStatechartcan ExpressDrivingControl

).Inaddition,theselectionopafarticularState

featureselectionintheapplicationengineeringph

chartresultsfromthe

ase.Thatis,inthecasewherethe

DrivingControl featureiselected,theright-handsideothe f St

Express

atechartinFigure6isselected.

3.3ComponentModeling Oneofthemostimportantelementsforsuccessfulr adaptablecomponents.Here,theterm

euseisthedevelopmentofreusableand

“component”referstoanyunitsofreuseorintegra

includingcomputationalcomponents,interfacecompo

nents,communicationcomponents,and

implementationpackagecomponents.

Thepurposeofcomponentmodelingistoproducecom

ponentsthatcanbeeasilyreusedand

adaptedinvariety a ocontexts. f Componentdevelop

mentstartswithidentifyingobjectspotentially

usefulfortheimplementationofreusableandadapt

ablecomponents.Inourmethod,thefeature

modelisusedtoderiveobjectsthatencapsulatesp

ecifictypesodf ecisions(i.e.,designdecisions,

implementationdecisions,environmentalconstraints development.Detailsofeature-basedobject-orient

,etc.)thataremadeduringproduct edengineeringcanbefoundin[10].Thenext

stepistodevelopreusableandadaptablecomponent

sbyutilizingtheobjectsdevelopedinthe

previousstep.Inourmethod,objectsareconsidere

dabsasicunitsformakingcomponents.Closely

relatedobjectsmaybepackagedintoacomponentor

changeableobjectsmaybeseparately

engineeredinto component a thatencapsulatesanda

ccommodatesvariableaspects.

Componentsdevelopedinthisphaseareusedtospec

ifycomputationalfunctions(i.e.,functionsin

DFDs)oftheoperationalmodels.Inthespecificati

onlevel,functionalspecificationsaredefinedby

usingcomponentinterfaces.Manydecisionsmadedur

ingthedesignandimplementationofa

softwaresystemarepostponeduntilcomponentinteg

rationtime.Thatis,thecontentsof

componentsthatareboundwithparticulardecisions

suchasdesigndecisions,implementation

algorithms,environmentalconstraints,etc.areins

tantiatedfromthecomponentspecificationsand

integratedwiththecomponentinterfacesusedinth

oeperationalmodels.

12

tion,

DataFlowDiagram

Step

DomainTechnology Layer

Operation_Mode

Generate Velocity Profile

ControlCarRun

Run

Velocity_Cmd ProfileStatus

Velocity Profile Methods

RunStatus

Step

CarController

Acceleration Profile Calculation

Run Advanced_Floor, Advanced_Position

Current_Position

Compute Advanced Floor

Deceleration Profile Calculation

Leveling Profile Calculation

PositionStatus

HighSpeed DecelerationProfile

LowSpeed Deceleration Profile

ProcessSpecification Compute Quadratic Equation

Process GenerateVelocityProfile() { ... generate= new ProfileHandler(Step); ... generate.DecelerationProfile(); ... }

Compute Cubic Equation

Formal Profile

Exponential Profile

Implementation Technique

ComponentModel ObjectClass Diagram

component ProfileHandler implementsfeature “VelocityProfileMethods”, “DecelerationProfileCalculation”, optional “HighSpeedDecelerationProfile”, optional “LowSpeedDecelerationProfile” ... { … public$ProfileHandler(int step) }.{..

Equation

Root cubic quadratic

public DecelerationProfile(){ $IF (;:$HighSpeedDecelerationProfile”){ profile= new Formal(); profile.deceleration(…); … root= new Root(); root.cubic(…); } $IF (;:$LowSpeedDecelerationProfile”){ profile= new Exponentail(); profile.deceleration(…); ... } } }

Formal

Exponential

acceleration deceleration

acceleration deceleration

GenerateVelocityProfile

definedaus singtheinterfacesothe f component(e

are

i)nthedataflowdiagramis

.g., ProfileHandler).Notethattheobjects(e.g.,

Root, Formal, Exponential,etc.,showninthebottom-rightboxofFigure7) featuremodelareusedtoimplementthecomponent. processingfacilitysimilarto[1]isusedtoparam

floor ceil Profile

Figure7Component . modelofelevatorcontrolsoftw

AsshowninFigure7the , function(e.g.,

Remainder

derivedfromthe

Inthecomponentspecification,amacro eterizethecontentofthecomponentaccordingto

featureselection.Thatis,thecomponentisinstan

tiatedinadifferentwaydependingonwhich

13

featureiselectedbetweenthe

HighsSpeedDecelarationProfileand

LowSpeedDecelerationProfile

intheupper-rightbox oFigure f 7.

3.4ArchitectureModeling Architecturemodelsrepresentthephysicalconfigur

ationothe f problemdomainwhileoperational

modelsrepresentthelogicalstructure.Inourmeth

od,thearchitectureidsefined through sequence a

ofrefinements:subsystemarchitectureandprocess

architecture.Subsystemarchitectureshowsthe

allocationofunctionality f toseparate a machinea

ndprocessarchitectureshowsconcurrentunitsof

execution,calledprocessesotasks, r andtheirint Rotary_encoder_input Position Controller

Motor_control_data

eractions.

Time Controller

Safety Controller

Command_input

Position_sensor_input,Door_sensor_input Relay_input, Car_call_input Operation_Switch_input,Hall_call_input Car_manage_data,Car_control_data

Display_control_output MMI Controller

Elevator Status Manager

Legend Process

IO Controller Relay_control Car_status_data Car_monitoring_data Brake_control_output Motor_power_control_output

Information HidingModule

Car Controller

Display Controller

Message Queue Message and reply

< Centralized IOControl System > Command_input

Rotary_encoder_input Motor_control_data

Time Controller

Position Controller

DataAccess

Safety Controller

Display_control_output MMI Controller

System Monitoring Controller

Position_sensor_input Door_sensor_input Relay_input

Brake_control_output Relay_control_output Motor_power_control_output

Car_monitoring_data Car_control_data Car_status_data

IO Controller

Elevator Status Manager

Car Controller Car_status_data

Operation_switch_input Car_call_input Display_output Car Network Controller

Group Network Controller

Display Controller

Car_status_data Hall_call_input Car_manage_data

Display_status_data

< Distributed IOControlSystem >

Figure8Two . alternativearchitecturemodelsofel

Themajoractivityoarchitecture f modelingitsos

evatorcontrolsoftware

eparatethefunctionalityspecifiedinoperational

14

modelsandtothenallocateito tphysicalarchitec

turecomponents(i.e.,subsystemsopr rocesses)

withtheconsiderationsofnon-functionalrequireme

ntssuchasperformanceissues,an

organization’spolicy,etc.

Forexample,Figure8showsthetwoalternativearc

hitecturemodelsoftheelevatorcontrol

software.TheupperprocessmodelofFigure8isde

velopedforincreasingtheperformanceof

communicationbetweenthetargetsystemandexterna

lenvironments.Ontheotherhand,the

bottomprocessmodelisdevelopedwiththegoalof cost.Whichmodelisselecteddependsonwhich

reducingmaintenanceaw s ellaisnstallation characteristicsaremoreimportantforaproduct

line.

4ApplicationEngineeringoElevator f Software Applicationengineeringisaprocesstoobtainane

xecutablesourcecodewhileutilizingmodels

developedinthedomainengineeringphase.Asshown withfeatureselection.Basedonthefeatureselect

inFigure3application , engineeringbegins ion,correspondinghigh-levelspecificationsand

low-levelcomputationalcomponentsareselectedand

instantiated.

modelsareconsideredasrequirementmodelswhichs

atisfythespecificusers’requirements(i.e.,

theselectedfeatures).Thenextstepistovalidat

eandverifytherequirementmodelsusing

ASADALmodelcheckingfacilities.Oncetherequirem

entmodelsarevalidatedandverified,a

softwarearchitecturemustbeselected and adapted issues.Basedontheselectedarchitecture,thefin

Inourmethod,theinstantiated

basedonvariousdesignissues,e.g.performance alsoftwareiproduced s automatically.

4.1Feature/ComponentSelection Applicationengineeringbeginswithusers’requirem

entelicitation.Inourmethod,therequirement

elicitationipserformedthroughthefeatureselect

ionbasedontheusers’needs.Thatis,thisids on

byfirstanalyzingusers’requirementsforthetarg

etproduct,andfindingmatching a setoffeatures

fromthefeaturemodel.

Inourmethod,theselectedfeaturesareusedtopa

rameterizedomainrequirementmodels(i.e.,

domainoperationalmodelsanddomaincomponentmode

ls).Inotherwords,basedonthefeature

selection,operationalmodels (i.e.,Statechartsan

dataflowdiagrams) anddomaincomponentsthat

aretiedtotheselectedfeaturesetareautomatica

lly selectedandadapted.

15

e

4.2ModelChecking Oncearequirementmodel

(i.e.,high-levelspecificationsandlow-levelreus

instantiatedbasedonthefeatureselection,themo

delshouldbceheckedtodetermineiitsatisfies f

bothusers’expectationsandthesystem’scritical

properties(i.e.,safety).Toaccomplishthis,

ASADALprovidestwomechanisms(i.e.,ASADAL/SIM[8 modelcheckingoreal-time f software.Withtheaid

]andASADAL/PROVER[9])for ofASADAL/SIM,wecanincreasethelevelof

confidenceaboutthespecifications;however,weca specifications.Inordertoguaranteethecritical

ablecomponents)is

nnotguaranteethecorrectnessofthe propertiesothe f system(i.e.,safety,liveness,r

eal-

timeresponse),ASADAL/PROVERcanbuesed.

Figure9.

Anillustrationomodel f checkingusingASADAL/SIM

Figure9showsascreenshotoA f SADAL/SIM,whichis

usedtovalidateusers’expectationsof

ECS’sbehaviorbymeansoef xecutingthespecificat data/conditionvaluesduring

ionsandvisualizingchangesotfhestatesor

thespecificationexecution.Whileworkingwiththi

environment,wecanfindbehaviorerrorsotfheele

vatorcontrolsoftwareeasilyandthenrepair

themintheearly phaseosoftware f development.

16

sCASE

4.3ArchitectureSelection Architecturemodelsrepresentthephysicalconfigur

ationsotafargetapplication,whilerequirement

modelsshowthelogicalgroupingothe f functionali

tyotafargetapplication.Multiplearchitecture

modelsmay existinanorganization’sproductlines

Selecting . anappropriate

aspecificapplicationdependsonvariousnon-funct

architecturemodelfor

ionalissuessuchasperformance,an

organization’spolicy,marketneeds,etc.

Onceanarchitecturemodelforanapplicationdevel

opmentis elected,ASADALproducesthe

targetsoftwarebycomposingthedomaincomponents

thatweredevelopedinthedomain

engineering phasebasedontheunderlyingarchitect

ure.

Figure10.Codegenerationandvisualization

4.4CodeGeneration Automaticcodegenerationianecessary s condition

forimprovingtheproductivityandportability

ofsoftware.AnASADALcodegeneratorproducesata

rgetsourcecodeautomaticallyfrom

ASADALspecifications.Theoutstandingfeatureotf

heASADALcodegeneratoristhatwecan

producedifferentformsofsourcecodesdependingo

nthechoiceofthetargetimplementation

17

environments(e.g.,implementationlanguagesandop

eratingenvironments).Withthisautomation

environment,wecanproducecorrectandefficients

oftwarefromthesoftwaremodels.Currently,

theASADALcodegeneratorcangenerateJava,C++,o

C rcodesrunningonUnixorWindows

95/98operatingsystems.Also,weareextendingthe

ASADALcodegeneratorinordertoproduce

softwarethatcanrunoreal-time na operatingsyst

Visualizingthebehaviorsof wayof

testingthe

em (i.e.,VxWorks).

the environmentsthatinteractwith

generatedcodesfrom

isanexcellent

the ASADALCASEtool.AsshowninFigure10,the

ASADALCASEtoolgeneratestwoJavasourcecodes.T relatedtoprogramlogicwhilethe

the targetsoftware

he “Code.java”filecontainsallclasses

“Code_data.java”containsallclassesrelatedtoda

tausedinthe

programlogic.After thecompilationothe f source

codes,executablecodesiobtained s andcanthen

betestedbyinspectingthebehaviorsoECS f intera

ctingwithenvironments.Inordertodothis,we

havemodeledtheenvironmentsofECSwithJava3Dc

omponents.

5Maintenanceexperience Quantitativeevidenceins ecessarytosubstantiate weshowhow

theeffectivenessoof urmethod.Inthissection,

farwecanreducemaintenancecostswhenwe

mustchangeseveralhardwaredevices

andcommunicationprotocols.Inthepast,thecore

partoE f CSinLGISwascomposedof51

moduleswith603functions.Unfortunately,several

partsofthesoftwareweredevelopedwith

redundancyduetoanurgentproductdeliveryschedu

le.Inaddition,severalpartsotfhesoftware

(i.e.,deviceinterfacemodules)hadbeenfrequentl

ymodifiedaccordingtoselectedmarketneedsor

acostreductionpolicy.Thesesituationsresulted

inincreasingmaintenancecosts.Afterapplying

theASADALmethodtothecorepartoE f CS,wehave

reducedthesizeandcomplexityofthe

softwareto48modules(i.e.,components)with295

functions(i.e.,methodsotfhecomponents).

Moreover,whenwehadtomodifysomepartsothe fs

oftwareduetochangesohardware f devices

orcommunicationprotocols,wewereabletoreduce

themaintenancecostsaswehaddesigned

modulesthatminimizethepropagationosuch f chang

estotheotherpartsothe f software.Theleft-

handsideandright-handside,respectively,ofFig

ure 11show thenumber offunctionsthatmustbe

modifiedoadded r whenspecifichardwaredevicesan

dcommunicationprotocolswerechanged.As

youcansee,thenumberocf hangedfunctionswas

drasticallyreducedafterapplyingASADAL.

Thisimprovementresultsfromseparationothe f env

ironmentalspecificinformation(e.g.,typesof

devicesorcommunicationprotocols)fromfunctional

18

componentsaswellasbehavioral

specifications. Device Changes

  

 

 

30

Communication Protocol Changes

   

29

12

25 20

17

11 9

8

15

# ofunctions f

14

10

8

9

7

5 0

   

10

20 o #functions f

  

11 2

6 4

6

1 0

Modificatio n

Addition

Modificatio n

Addition

Modificatio n

Addition

Before Applying ASADAL

20

29

7

1

17

14

After Applying ASADAL

8

9

2

0

11

6

2

2

3

3

2

2 0

Modification

Addition

Modification

Addition

Before applying ASADAL

11

2

9

3

After applying ASADAL

2

2

3

2

Figure11.Comparisonsosoftware f changes

6Conclusion ECSinLGISdiscussedinthispaperhasevolvedove

trhepasttwodecades,accommodatingthe

diversityofcustomers’needsandchangingmarketn

eeds.Wheneverhardwaredevicesmustbe

changedinstepwithchanging

customerandmarketneeds,theadaptivemaintenance

ofECShad

beenamajorundertaking.Toaddressthisproblem,

wehaveincorporatedthefollowingfeatures

into CASE a environmentandreengineered core a par

of tECSusingtheCASEenvironment.



Domain-orientedreusableandadaptablecomponentde



Early verificationandvalidationosoftware f



Architecture-basedsoftwarecompositionandgenerat

sign

ion

Duringthepastyear,wehaveappliedASADALsucces

sfullytothecorepartoE f CSwithour

industrypartner,LGIS.Inourexperience,thefeat

ure-orienteddomainanalysismethodiesffective

in identifying commonality and variability,and in

modeling reusable and adaptable components in a

productline.Developingfeature a dictionaryfora

productlineiasn

buildafeaturemodel.Weoftenfoundthatengineer agreeonwhatspecificfeaturesmeant.Itwouldbe

sworkingonthesameproductlinedidnot difficulttodevelop feature a modelfor paroduct

linewithoutcaommonunderstandingandanagreemen learned thatthe early validation andverification

effectiveandefficientwayto

of tthesemanticsofeatures. f Wehavealso of ECScanreducemaintenancecostsdrastically as

thebehaviorerrorsfoundduringmaintenancecanco

stoverha undredtimesmorethanfixingthem

intherequirementphase.Withthesepromisingresu

lts,weareapplyingASADALtoredesignthe

19

2

entireelevator software.

AnASADALCASEtoolsupportingallfeaturesmention runsonanyPCorworkstationin

edinthispaperhasbeencompleted.It

whichJDKsoftwareiisnstalledforitsrun-timeen

isavailableuponrequestvia

[email protected] ,

vironmentand

http://selab.postech.ac.kr/ASADAL.

8Acknowledgement Wewould

also liketothanktheMinistryoEducation f oKorea f fo

ElectricalandComputer Engineering DivisionaPOS t

its rfinancialsupporttowardthe TECHthroughitsBK21program.

7 References 1.

P.G.Bassett,

FramingSoftwareReuse:LessonsFromThe

RealWorld P , renticeHall,

YourdonPress,1997. 2.

D.Batory,L.Coglianese,M.Goodwin,andSSha . ExamplefromAvionics,

fer,CreatingReferenceArchitectures:An

ACM-SIGSOFTSymposiumonSoftwareReusability

,Seattle,

Washington,1995. 3.

J.Coplien,D.Hoffman,andD.Weiss,Commonalit

yandVariabilityinSoftware

Engineering, IEEESoftware Vol. , 15,No.6,pp.37-45,November/December1998 4.

W.Frakes,R.Prieto-Diaz,andCFox, . DARE-COTS Proceedingsothe f 17

.

ADomainAnalysisSupportTool,In

th

InternationalConferenceothe f ChileanComputerS

ociety,pp.73-

77,Valparaiso,Chile,November1997. 5.

K.C.Kang,S.G.Cohen,J.A.Hess,andWE. .N

ovak,and AS. .Peterson,Feature-Oriented

DomainAnalysis(FODA)FeasibilityStudy, Pittsburgh,Pa.,SoftwareEngineering Institute,Ca 6.

TechnicalReport

CMU/SEI-90-TR-21,

rnegieMellonUniversity,1990.

K.C.Kang,S.Kim,J.Lee,K.Kim,G.J.Kim,a

ndEShin, . FORM:AFeature-Oriented

ReuseMethodwithDomain-SpecificReferenceArchite

ctures, AnnalsofSoftware

Engineering, Vol. 5,pp.143-168,1998. 7.

K.C.Kang,S.Kim,J.Lee,andKLee, . FeatureAdaptabilityandReusability,

OrientedEngineeringoPBX f Softwarefor Software-PracticeandExperience

, Vol.29,Issue10,pp.875-

896,August1999. 8.

K.CK . ang,KL . ee,JL . ee,andG.JK . im,ASADA

L/SIM:AnIncrementalMulti-level

Simulationand AnalysisToolfor Real-TimeSoftware

20

Specifications,

Software-Practiceand

Experience,Vol.28,Issue4pp. , 445-462,April1998. 9.

K. Ko and KC. .Kang,ASADAL/PROVER:A Toolset f

or Verifying TemporalProperties of

Real-TimeSystemSpecificationsinStatechart,

IEICETransactionsonInformationand

Systems,Vol.E82-D,No.2,pp.398-411,February 1999. 10. K.Lee,KC. . Kang,WChae, . andB.Choi,

Feature-BasedApproachtoObject-Oriented

Engineering oApplications f for Reuse,submittedfo

publication. r

11. E.MettalaandM.H.Graham,TheDomain-Specifi TechnicalReportCMU/SEI-92-SR-9

cSoftwareArchitectureProgram,

,Pittsburgh,PA,SoftwareEngineeringInstitute,

CarnegieMellonUniversity,June1992. 12. D.EP . erryandA.LW . olf,Foundationsforthe SIGSOFTSoftwareEngineeringNotes

StudyofSoftwareArchitecture, , Vol. 17,No.

13. R.Prieto-Diaz,DomainAnalysisforReusability

IEEEComputerSociety, Washington,D.C.,October19 14. M.

4, pp. 40-52, 1992.

I, n

EleventhAnnualInternationalComputerSoftwareand

Simosetal,Software Technology forAdaptable Reli

DomainModeling(ODM)GuidebookVersion2.0,

ACM

ProceedingsoC f OMPSAC87:The ApplicationsConference

pp. , 23-29,

87. ableSystems(STARS)Organization STARS-VC-A025/001/00,Manassas,VA,

LockheedMartin TacticalDefenseSystems,1996. 15. M.ShawandD.Garlan,

SoftwareArchitecture:PerspectivesonanEmerging

PrenticeHall,1996.

21

Discipline,