Table Of ContentMichał Śmiałek · Wiktor Nowakowski
From Requirements
to Java in a Snap
Model-Driven Requirements Engineering
in Practice
From Requirements to Java in a Snap
Michał Śmiałek Wiktor Nowakowski
•
From Requirements
to Java in a Snap
Model-Driven Requirements Engineering
in Practice
123
Michał Śmiałek WiktorNowakowski
Warsaw Universityof Technology Warsaw Universityof Technology
Warsaw Warsaw
Poland Poland
ISBN 978-3-319-12837-5 ISBN 978-3-319-12838-2 (eBook)
DOI 10.1007/978-3-319-12838-2
LibraryofCongressControlNumber:2014955320
SpringerChamHeidelbergNewYorkDordrechtLondon
©SpringerInternationalPublishingSwitzerland2015
Thisworkissubjecttocopyright.AllrightsarereservedbythePublisher,whetherthewholeorpart
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or
dissimilarmethodologynowknownorhereafterdeveloped.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publicationdoesnotimply,evenintheabsenceofaspecificstatement,thatsuchnamesareexempt
fromtherelevantprotectivelawsandregulationsandthereforefreeforgeneraluse.
Thepublisher,theauthorsandtheeditorsaresafetoassumethattheadviceandinformationinthis
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, express or implied, with respect to the material contained
hereinorforanyerrorsoromissionsthatmayhavebeenmade.
Printedonacid-freepaper
SpringerInternationalPublishingAGSwitzerlandispartofSpringerScience+BusinessMedia
(www.springer.com)
To Maria and Mieczysław who helped
to choose the right path, and to Grażyna,
Magda, Zosia and Wojtek who constantly
motivate to keep the right path.
—Michał Śmiałek
Tomywifeandchildrenforbeingthetruejoy
of life.
—Wiktor Nowakowski
Foreword by Juan Llorens
Dearcandidatereader,itissimple:readthisbook!AsIamnottheauthor,myduty
when writing these words is to describe the impressions I got when I read the
manuscript. And I have discovered that I have many positive impressions.
Software engineering is—slowly but steadily—converging with the rest of the
domain-specific“engineerings”(civil,industrial,aero-space,etc.).Theconvergence
is, of course, not based on the variability of the different domains, but on the
commonaltyoftheengineeringprocessesappliedtoallofthem.Evenifitseemsto
beastraightforwardassertion,informationsystemsarestartingtobeconsideredas
key elements within the other engineering disciplines. We can find large software
components in contemporary complex technical systems like aircrafts, trains, cars
or medical devices. The influence of software engineering in the development of
suchsystemsisbecomingclearerdaily.Thenewstandardsforsystemdevelopment
and management include now the fundamentals of software engineering: separate
theproblemfromthesolution,andtestthesolutionwiththeneedsdescribedbythe
problem statement.
More and more, engineering disciplines start to understand that in order to
develop a system (including information systems) it is necessary to declare and
describe what the stakeholder needs are. These needs allow to define stakeholder
requirements,whichareturnedintosystemrequirements.Andsystemrequirements
are the basis for subsystem requirements. This decomposition in the specification
process should end only when the complexity of the system is properly “tamed”.
Thus: requirements, requirements and more requirements. They have to be
fulfilled by tracing them into design artefacts and code (in case of software); they
mustsatisfyhigherlevelrequirements;theymustbeverifiedfromtheproductside;
theymustbeusedforvalidation;theymustbethemeansforcertificationpurposes;
and,ofcourse,theymustbeusedtocommunicatehumanswithhumansduringthe
software and system engineering life-cycle stages. Everything starts, and conse-
quently ends, in requirements.
On the other hand, it seems to be trendy in some sectors of the Software
Engineering community to attempt at producing software products by exclusively
applying models and model transformations. For its proponents, Model-Driven
vii
viii ForewordbyJuanLlorens
Engineering (MDE) seems to become equivalent with the whole Software Engi-
neering.Somewanttodefinethesilverbulletformodernsoftwaredevelopmentby
drawinggraphicalmodels,assumingthatsmartcomputerswillproduceexactlythe
software the customer wants. The real issue, the real problem, is to include
requirements in this trend of model-based Software Engineering. MDE offers real
benefits to increase traceability, quality control, defect reduction and explicit
automation, but still calls for requirements to properly define needs, capabilities,
operations, properties and restrictions.
This book deals with one of the real problems of today: how to apply require-
ments-basedSoftwareEngineeringwhilenotforgettingMDE.ThisiscalledModel-
DrivenRequirementsEngineering.Untilnow,requirementsengineeringhasalways
beenoutsidethekernelofapplicationforMDE;itwas,perhaps,toocomplicatedto
connectbothworlds.Butnow,thisbookreallycontributestochangethissituation,
by describing and presenting a clear methodology to tackle the problem. The
methodology includes definition of a process, concrete methods, technology and
alsotools.Thisbookhastheattributestoofferasolutiontoexistingproblemsunder
research today, particularly regarding the integration of requirements engineering
within the discipline of automated software engineering.
Long live executable requirements, and enjoy your reading!
Madrid, September 2014 Juan Llorens, Ph.D.
Professor, Universidad Carlos III de Madrid
CTO, The REUSE Company
Technical Director, NCOSE Spanish Chapter
Foreword by Audris Kalnins
Model-Driven Software Development (MDSD) is at crossroads now. In recent
years, the question asked at many major software engineering events is whether
MDSD—started in 2001 as Model-Driven Architecture (MDA)—has reached its
goals in providing a new road for industrial software development. The answer is
typically mixed—success stories are contrasted with observations that MDSD is
predominantlyignoredbypractitioners.Thisleadstotendenciestochangetheform
inwhichMDSDispracticed.TheclassicalformofMDSDisasuccessivechainof
models, mainly in standard UML, finally leading to the system code. Intermediate
modelsareimprovedmanually,whichcausesmodelsynchronisationproblemsand
is seen as a key obstacle. In many successful cases, this form has given way to
approaches that use model-based Domain Specific Languages (DSL). DSLs with
their“one-stop”approachfrominitialmodeltothesystemcodeseemtohavemore
chance to be accepted in practice.
Freshideasintheareaaresoughteagerly—howtoreallyproceedfurther.Inthat
sense,thebookproposedbyMichałŚmiałekisarealbreakthrough.Itoriginatesin
theReDSeeDSproject,wherethemaininnovativeaspectwastheintroductionofa
suitable content for the first model in the MDSD chain—the CIM model. Specif-
ically, this involves requirements specified as use case models, refined with sce-
narios written in controlled natural language and linked to the conceptual data
model of the system to be built.
Now,inthebook,thisideahasreacheditscoherentandcompleteform.Itoffers
a consistent language RSL for requirements specification, which can be applied in
classical MDSD approach, or more precisely, in the step of Model-Driven
RequirementsEngineering(MDRE).However,atthesametime,thislanguagecan
betreatedasaDSL.Thebookpresentsmethodstotransformautomaticallycodefor
the application layers from precise requirements. The language thus serves as a
broad domain-universal DSL for typical web-based systems—more precisely, for
the whole user-system interaction control aspects to be implemented in the Con-
troller layer of the MVC design pattern (or Presenter in the MVP pattern). RSL
coversalso thebasicelementsofthescreenforms (ViewinMVC)whichthencan
be extended for a specific framework. In addition, the language can easily be
ix
x ForewordbyAudrisKalnins
combined with a narrow-domain DSL for describing also the data processing
aspectsofthesystem(ModelinMVC),thusenablingcompletecodegenerationfor
the system. As a result, the book is a very promising further development of the
ReDSeeDS project, initiated by Michał Śmiałek, where me and my colleagues
participated so enthusiastically.
Another especially interesting aspect of the book is the use of MOLA model
transformationlanguagedevelopedattheIMCSUniversityofLatvia.Thelanguage
wasintensivelyusedthroughouttheReDSeeDSprojectwhichwasoneofitsmajor
usecases.Now,thebookshowshowtoapplyMOLA(andothersimilarlanguages)
to obtain even more interesting results than were achieved in ReDSeeDS: genera-
tion of Java code directly from RSL models. By presenting extensive and detailed
examples, the book can also very well play the role of a MOLA textbook. The
language is explained so clearly and precisely—all this based on M. Śmiałek’s
significant experience as an educator in the area of software development.
Riga, September 2014 Audris Kalnins, Ph.D.
Senior Researcher, IMCS University of Latvia
Preface
Back in 1988, Gerald M. Weinberg, in his seminal book “Understanding the
Professional Programmer” [180] has formulated the following statement:
“…programmingcomputersisbyfarthehardestintellectualtaskthathumanbeings
haveevertriedtodo.Ever.”Wecandiscussthisstatementandarguewithitbutwe
have to admit that software development is an extremely complex task, and this is
so for various reasons. Probably the most concise summary of these reasons was
given byFredBrooks inhis famousessay “NoSilverBullet”[26].He haspointed
outthatsoftwareiscomposedoftwotypesofcomplexity:essentialandaccidental.
Theessentialaspectisinherentfortheproblemathandandcannotbereduced.This
complexityhasto“bethere”insoftwaresothatitwouldbeabletosolvetheactual
problem. The accidental aspect is associated with the computer technology and
includes things like programming language constructs, distributed calls, middle-
ware, UI technologies and so on. This kind of complexity resides within the soft-
ware systems due to the complexity of computer technologies themselves.
The general diagnosis might be that “it has to be complex and we cannot do
anything about it”. Or maybe we can? We certainly cannot reduce the essential
complexity,becausetherealityiscomplexandweneedtosolvecomplexproblems
in our reality. However, what we can try to do is to “tame” the accidental com-
plexity, or more specifically—hide this complexity from the software developers.
How could this be done? The first step would be to define ways of specifying
preciselytheessenceofthesolutiontotheproblemathand.Thesecondstepwould
be to build programs that would transform this essence into a working software
system.Themoreweautomatethistransformation,thebetterwehidetheaccidental
complexity…
It can be noted that the essential complexity of software is closely related to
requirementsforsoftware.Requirementsdefinetheproblemtobesolvedbutoften—
at a more detailed level—they also offer essential descriptions of this problem’s
solution.Letusassumethatwehaveanotationthatcandescribethevariousaspects
oftheessentialsolutionwith“highprecision”(whateverthismeans).Withenough
precision we would have the potential to transform these detailed requirements
xi
