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,
