• Nie Znaleziono Wyników

Model driven construction and costumization of modeling and simulation web applications

N/A
N/A
Protected

Academic year: 2021

Share "Model driven construction and costumization of modeling and simulation web applications"

Copied!
159
0
0

Pełen tekst

(1)

TU Delft Library

Prometheusplein 1

2628 ZC Delft

M o d e l Driven C o n s t r u c t i o n a n d C u s t o m i z a t i o n of

Modeling & Simulation W e b Applications

P r o e f s c h r i f t

t(u- verkrijging van dv graad van doctor aan do Technische Univc-rsitint D(>lft.

op gezag van de Rector Magnificus prof.ch.ir. .I.T. Fokkenia. voorzitter van het Coücge voor Promoties,

in het ojjenbaar te verdedigen

op nr.' aandag 19 januari 2009 om 12.30 uur

door

Aruh-iy LEVYTSKYY

informatica ingenieur, Yuriy Fedkovych dun-nivtsi geboren te Chernivtsi. Ockraine

(2)

Prof. <lr. H. KopjK'laar Samenstelling promoticx-ounnissie: Rector Magniiicus. Prof. dr. H. Koppidaar. dr. L..I.M. Rothkrantz. C M . Jonker. H. Vaiiglieluwe. ing. Habil. W. Hackl ir. .l.L.G. Dietz ir. H..I. Sips

Prof. Prof. Prof. Prof. Prof. Prof. drs dr. dr. dr.

(Ir.

dr. voorzitter

Technische Universiteit Delft, promotor Nederlandse D(>fensie Acadtunie Technische Universiteit Delft McGill University, Montreal. Canada Technische Universiteit Delft T(K-lmische Universiteit D(-lft Technische Universiteit D(4ft,

Keywords:

Modeling and Simulation (M&S); Web-ba.sed environment: Conceptual framework: Efficient customization: Model-Driven Engineering (MDE)

Copyright (c) 2008 by A. Levytskyy

All rights reserved. No part of this publication may be reproduced or utilizcxl in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage n-trieval system, without written permission from the author. ISBN ü78-90-889f-08f-4

(3)

This thesis is result of a long research journey. While th(^ joimuw is the author's own, tlune haye also been many companions that i)layed their role in making this work come to its conclusion.

To start with, I would like to thank my supervisor Prof. Eugene Kerckhoffs for giving me an o])portunity to join the NanoComp project, his guidance and allowing me to p(>rform the n^s(>arcli described in this thesis. T h e TU Delft sponsored NanoComp jiroject is acknowledged for providing an interesting and challenging research context.

Sp(X-ial gratitude goes to Prof. Hans Vangheluwe for lumping to form the general direction of this research. His assistance in the middle and late stages of the project, as well as inviting me as visiting researcher to the Modeling. Simulation and Design Lab (MSDL) of the School of Com]nit(-r Science of McGill University in Montreal. Canada is much ai)pr(X'iat(Hl. Fellow MSDL stud(Mits have to be thanked for a fricnidly and informal enviromnent that jjrovided a very fruitful and creative^ research atmospluu'c. Among them, Ernesto Posse and .Jean-Sébastien Bolduc, for allowing to reuse parts of their work on generation of DEVS Modeling and Simulation (nivironments. I also would like to thank .luan de Lara of Universidad Autónonia di- Madrid. Spain, for his work on AToM-\

I (^speciall\- would like to thank my i)romoter Prof. Henk Koppelaar and Prof. Leon Rothkrant/. who remained coimnitted to this project desi)itc the delays and provided much needed encouragements in the final stage of the i)roject. Andr(>a Cilio, a great friend, whose generous su[)port and constructive connnents both improved the quality of and sped up completion of the thesis. Stej^an Voevidko. thank you for your tir(4ess support during all these years.

I owe many thanks to my family and esijecially my mom, who. while being far away, motivated and supported UK^ from the first day of the project. Without her this work would iievcn- have started and never have been finished. A big thank you to my littl(> daughter Melody, who strongly motivated me to finish this book a.s soon as possible. Finally, my wife Marjan(>li, who was directly affected by this project more then anybody else. She went together with me through ups and downs of writing the dissertation. For that I thank you.

An<lri\' Levytskyy

(4)

Summary

Of the thesis:

Model Driven Construction and Customization of

Modeling & Simulation Web Applications

by Aiichiy Levytskyy

The emergence of the W W W and its l)ig pcjpularity in the simulation coimnunity gav(^ birth to the concept of Web-Bas("d Modeling & Simulation. The inii)lication of this I)lienomenon is that traditional single- u.s(;r M&S tools will have tt) b(> r(>placed or suj)-pleracnited with more powerful tools supporting collaborative practices of us(n-s. As com-plexity of engineer(>d systtnus continuously increases, the use of M&S in development and demand for powerful Web-Based M&S environm<nits are expected to grow in the future. The need for new web enabled M&S tools was answered by rest-arch connnimities. These first results often were ad hoc solutions based on merging M&S with Web tech-nologies. A typical application would consist of cementing its ingredients: a modeling paradigm, simulators and collaborative aspects with particular Web technologies. If any of these ingredients would be different in a new application, such hard coded paradigms, collaboration asjjects and sinmlators could not be easily changed or customized mainly due to low efficiency associated with the traditional code-oriented developmcnit. More-over, a key approach in many contributions was the role that web-enabling technologies, such as Java language, played both for specification and implementation of the model. This doubles role of the web technology invoked a number of disadvantages: First, mod-eling languages wert' reijlactxl by a relatively low-kwel, general purpose progrannning languag(\ which resulted in decreased productivity of modellers and increased semantic gap between possibly multipk- modeling paradigms and the web-(niabling technology used for modeling. Furthermon-, int in'twining of specification and implementation made .sepa-ration of a nicxk-l from its siumlator harder, thereby nnlucing portability and reusability of models.

This thesis presents a model-driven approach to construction of web-ba.sed environ-ments t h a t could be efficiently customized to mofleling and sinuilation needs of an arbi-trary number of M&S aj)plication domains. To achieve broad applicability, our approach is based on general concepts in fields of Modeling and Sinuilation, Distributed Systems, and Collaborative Software. Such stable concepts constitute the eoUalxjrative Modeling and online Simulation (cMoS) framework. cMoS jjrovides a general basis for a fam-ily of Web-Based M&S applications. Specific M&S applications are sujiported through

(5)

customization of the variation points in cMoS during the operation phase of the en-viromn(>nt. To enable efficicnit customization, tlu; variation points arc not implicitly hardc()d(xl as traditionally, but are exprcs.sed as models. The u.se of the resulting models is still limited due to a high barrier of their imijlemcntation. This barric^r is amended by IModel-Drivcni Engineering (MDE): models of the variation points are computerized and their implementation is automatically generated. The end result is a model-driven and mostly programming free Web-Based environment adaptable» to new M&S applications through abstract modeling of the cMoS variation points.

(6)

Contents

A b b r e v i a t i o n s xi 1 I n t r o d u c t i o n 1 1.1 R(>searfh problem 2 1.2 Aijproaeh 4 1.3 Definitions 4 1.4 Delimitations .5 1..5 Contrilmtions 5 1.6 ()utlin(M)f this thesis 6 2 P r o b l e m d o n i a i n 9

2.1 Modeling and Simulation 9 2.2 Distribnted systems 10 2.2.1 Key charaeteristics 11 2.2.2 The Internet 13 2.3 CoUaborativt- software 15 2.4 Summary 16 3 M o d e l - D r i v e n E n g i n e e r i n g 17 3.1 What is AIDE? 17 3.1.1 Software development process 17

3.1.2 Problems of software development 20

3.1.3 Definitions of MDE 21 3.1.4 Essence of MDE 22

3.2 Basic concepts 23 3.2.1 System. Model and M(>ta-step 23

3.2.2 Language as System 26 3.2.3 IVansformation 28 3.3 MDE approaches 31

3.3.1 Model Driven Architecture 32 3.3.1.1 Modeling space and process 32

3.3.1.2 Transformation 33 3.3.1.3 The 1/2 floor of the MDA building 34

3.3.1.4 The MDA framework 35 3.3.1.5 OMG stanriards and technologies 36

3.3.1.6 Profihng 38

(7)

3.3.1.7 MDA tools 38 3.3.2 Domain Specific Modeling 38

3.3.2.1 Modeling space and process 39 3.3.2.2 The DSM framework 40 3.3.2.3 DSM tools 41 3.4 Summary 41 4 M D E a t W o r k 4 3 4.1 Data 43 4.2 Data F k w Diagrams (DFD) 44 4.2.1 DFD metamodel 45 4.2.2 POKer code generation 46 4.3 Discrete Event System Specification (DEVS) 49

4.3.1 Metamodel of DEVS with ])orts 49 4.3.2 PythonDEVS code generation 53

4.4 Process Interaction (PI) 54 4.4.1 PI metamodel 54 4.4.2 PI operational semantics 58

4.4.2.1 Example rule 58 4.4.2.2 Event execution 58 4.5 Dynamic Traffic Routing (DTP) 61

4.5.1 Metamodel of a traffic language 61

4.5.2 ABC Code Generation 62

4.6 Sunnnary 64 5 F r o m M o d e l s t o I m p l e m e n t a t i o n 65

5.1 From an impk'mentation to models 65 5.1.1 The NCSE prototype 66 5.1.2 Shift to models 67 5.2 A framework for Collaborative ModeUng and Online Simulation 69

5.2.1 Sei)aration-relate(l issues 71 5.2.2 User 72 5.2.3 User-Simulator relationship 73 5.2.4 Scenario 73 5.2.5 Controller 73 5.2.6 Tool 74 5.2.7 Model 74

5.2.7.1 Modeling formalism and languages 74

5.2.7.2 Simulator ind<>p(ni(l(-nce 74 5.2.7.3 Storage indeiiendence 76

5.2.8 Repository 77 5.2.9 Simulator and Solver 77

5.2.10 Simulation and Experiment 77 5.3 AcMoS application meta-architecture 77 5.4 Model-driven engineering processes 80

(8)

5.4.2 DSL interpretation 81 5.5 Transformation definitions are models too 82

5.6 Snniniary 83 6 D e v e l o p m e n t I n f r a s t r u c t u r e 85 6.1 Selected technologi(>s 85 6.1.1 Gencn'al prooramming 85 6.1.2 Connnunication infrastructure 85 6.1.3 Web development 86 6.1.4 MDE technologies 86 6.1.4.1 Modeling 86 6.1.4.2 Meta-modeling 86 6.1.4.3 Model transformation 87

6.2 Software development process 88 6.2.1 Simplified Cla.ss Diagrams (SCD) 89

6.2.2 Python SCD Ü0 6.2.2.1 Python code generation 90

6.2.3 ZCase - Zopc Product framework 91 6.2.3.1 ZProduct modeling language 91

6.2.3.2 Product validation 93 6.2.3.3 Product PSM generation 95 6.2.3.4 Product distribution generation 95 6.2.3.5 A T O A P nietatype to Zope product 95

6.3 DSL interpretation 95

6.4 Sunmiary 96 7 c M o S I n s t a n c e 97

7.1 AcMoS components 97 7.2 Selected off-the-shelf parts 100

7.2.1 Groupware 100 7.2.2 Client 100 7.2.3 Model repository 100 7.2.4 File repository 100 7.2.5 Simulator 100 7.2.6 Tool 101 7.3 Model', context-in 101 7.3.1 Atomic 101 7.3.2 Compound 101 7.4 Model, context-out 103 7.4.1 Multigraph 103 7.4.2 Node 103 7.4.3 Arc 103 7.4.4 Export 107 7.5 Data model 107 7.6 Solver 107 7.7 Solver' 107

(9)

7.8 Scenario 107 7.9 Experiment data 109 7.10 Experiment 109 7.11 Controller I l l 7.11.1 Domain mock^l I l l 7.11.2 ()j)erational semantics 113 7.11.3 Server 114 7.11.4 Controller" 115 7.12 Tool 115 7.12.1 Export functionality 115 7.12.1.1 Locations metamodc^ 115 7.12.1.2 Export transformation 115 7.12.1.3 Multi-formalism modeling 110

7.12.2 Code gcnieration gviidc^ines 116

7.13 Suramary 117 8 A c M o S A p p l i c a t i o n s 119

8.1 A[)plication domain customization 119 8.1.1 Application domain definition 119 8.1.2 Model repository update 120 8.1.3 Sinnilator wrapper 122

8.1.4 Scenario 122 8.2 Modeling 122 8.3 Collaboration 122 8.4 Onlin(> simulation 124 8.5 Management of sinuilation resources 125

8.5.1 The Weighbridge ben(4nnark 126 8.5.2 Simulated vs. actual op(>ration 129

8.6 Sunnnary 130 9 C o n c l u s i o n s 1 3 1

9.1 Smnmary 131 9.2 Contributions 132 9.3 Limitations 133 9.4 Possible directions for further resfvireh 134

B i b l i o g r a p h y 135 C u r r i c u l u m V i t a e 145

(10)

Abbreviations

AeMoS AToM'^ eMoS DEVS DFD DSL DS.\I DSME DTR LHS MDA MDE MOP MRA MRD M&S OMG P I PIM PSM RHS SCD ZCase

An instanee oi tlK> eMoS framework (a cMoS)

9

A Tool for Multi-formalism and Meta-Modeliug

the Collaborative Modeling and Online Sinnilation framework Diserete Evcnit System Speeilieation

Data Flow Diagrams Domain Speeifie Language Domain Speeifie Modeling

Domain Sj)eeifie Modeling Environment Dynamie Traffic Routing

Left Hand Side

Model Driven Areliiteeture Model Drivcni Engineering Meta-Objeet Faeility

Metadata for Resource Access Metadata for Resource Discovery Modeling and Simulation Object Managenunit Group Process Interaction

Platform IndependfMit Model Platform Specific Model Right Hand Sid<>

Simplified Class Diagrams

Zope Comi)uter-Aided Software Engineering

(11)
(12)

Chapter 1

Introduction

The emergence of the World-Wide Web (WWW) and its jjoijularity in the simulati(in community gave birth to the concept of Web-Based Mod(4ing & Simulation [28]. In [85], Sarjoughian and Zeigler attributed the popularity of this phenomenon to proliferation of organizations t h a t required Modeling and Simulation (M&S) environments in support of their development activities and to the fact t h a t modeling of development artefacts required involvement of many individuals. The implication of the latter is that traditional siïigk^ user Nf&S ttjols will have to be rei)laced or sujipleniented with more powerful tools sup[)orting collaborative practices of users.

In [29]. Healy observed that traditional M&S tools were often difficult to modify or extend for the web context, thereby stimulating research and development of new tools. This iwcd was answered by research ('(jmniunities. To witness the amount and scope of tlu^ produc(>d work, one only nc^eds to browse proceedings of many M&S conferences devoted to the subject, for example [30]. In [75], Page classifi(>d the wide range of research and development efforts into five areas: simulation as hyjw'rmedia, simulation research methodology, simulation of tli(> W'WW, web-basixl access to simulation programs and distributed modeling and simulation. The application domain of the work presented in this thesis belongs to the last two areas and concerns remote execution of existing simulations, as well as frameworks, tools and (niviromnents to support the distributed, collaborative development of simulation models.

Prior to the start of this research, the applicatif)n domain already comited numer-ous contributions as documented in [24, 42. 61, 87. 3, 20, 85, 90]. A key ajjproach in many contributions was the role that web-enabling technologic^s. such as Java language, playcxl both for specification and imi)lementation of the model. The powerful featvu'e set of the .lava language allowed to implement special purpose simulation modeling fea-tures directly in the .lava languages so that modeling and programming language became the same. However, this web-based approach invoked a number of disadvantages: First, modeling languages were replaced by a relatively low-level, general purpose prograimning language. This neglected the decades long evolution of modeling practices from using general purpose languages to special purpose simulation languages, to higher level model specification languages. The result is decreased i)ro(luctivity of modellers and increased semantic gap between possibly multiple modeling paradigms and the web-enabling tech-nology used for modeling. Furtheruior(\ intertwining of specification and implementation made separation of a model from its simulator harder, thereby nxlucing portability of

(13)

models [100, page 30]. The implication was that such models could only be reused with t)tlier .lava models and executed on one simulator, the Java platform.

The goal of this work is a web-based collaborative environmeirt that could be easily tailored to inod(;ling and simulation needs of an arbitrary ninnber of M&S application domains. The work was started due to inflexibility of available solutions and their weak supi)ort for model specification languages required in the NanoComp project [70] t h a t invc^stigated the feasibility of future (-lec'tronics based on quantum devices. Researcii and devek)pment of comjjlex systcnns often recjuii'es a specific combination of problem solving paradigms. The proposed approach and our original ai)pli(>ation of Model-Driven Engine(>ring (MDE) enables collaborative» users to work with an arbitrary lunnber of pretern-d modeling paradigms, share models and automatically gen(Tat(> mod(4 imple-mentations for sinuilation on-line or off-line. Direct supi)ort for modeling paradigms used by end users results in effective and productive mod(-ling. Perhaps more important than availability of j)roi)er paradigms is possibility of combining those- paradigms into multi-paradigm solutions. At last, but not least, separation of models from simulators gives users fr(H>dom of executing mod(!ls with simulators of thc-ir choic(\ As complexity of engimvred systems continuously increases, the use of M&S in developimnit of sueli systems and demand for powerfvU and coUaliorative M&S (niviromnents such as in the focus of this work, are expected to grow.

1.1 Research p r o b l e m

The problem addressed in this researcii is:

H o w t o a c h i e v e b r o a d a p p l i c a b i l i t y of a W e b B a s e d M o d e l i n g & S i m -u l a t i o n e n v i r o i n n e n t a n d efficiently c -u s t o m i z e s -u c h e n v i r o n m e n t t o a p o s s i b l y a r b i t r a r y n u m b e r of M & S a p p l i c a t i o n d o m a i n s ?

Essentially, we argue that liroad applicability can be achieved by basing the environ-ment on a general framework that includes fimdaenviron-mental concepts from contributing fields of Modeling & Sinuilation. Distributed Systems and Collaborative Software. To (niable efficient tailoring to specific aijplications during the operation phase of the environin(>nt's life-cycle, we identity variation points in the framework's concepts. Customization of the identified points is still Ihnited diu» to a high barri(>r of their implenK-ntation. R(>cent advances in model-based developmc^nt provide a promising approach to this coinpl(ixit\' problem by lifting the abstraction level of system specifications and enabling automation of development activities. Therefore tlies<^ ])oints are not implicitly hardcoded as tradi-tionally, but are explicitly expressed as computerized models and their impleiii(>iitation is automatically generated. The end result is a model-driven and mostly programming free cMoS system adaptabk' to new M&S api)licatioiis through abstract mo(k'ling of the variation points.

The research iiroblein is important for convergence of the fi(»lds of Modeling & Simu-lation and World Wide Wei) ( W W W ) . The emergence of W W W has stirred academical, governmental and industrial interest in connecting computer modeling and simulation methodology and applications with the Web. Numerous projects have been initiated and contributed tow.ird first results in the W'eb-Bas<\l Mo(U4ing and Simulation. These

(14)

results howevfU' were ad hoc solutions based on merging M&S with Web technologies. A typical application would consist of cementing its ingredients: a modeling paradigm, simulators and collaborative aspects with particular Web technologies. Should have any of these ingredients be different in a new application, such hard coded paradigms, col-laboration aspects and simulators could not be easily changefl or customized. Given th(^ multitude of modeling paradigms, plethora of modeling languages and simulators, it is neither feasible nor desirable to manually program web-based collaborative enviromnents per each possible M&S application domain or combination thereof. An alternative is a general environment that can be customized to new M&S domains. Such a generally applicable solution needs to be framed around general and stable concepts from related bodies of theories: Modeling & Simulation, Distributed Systems and Collaborative Soft-ware. Tlunx-fore the first ri'search issue of this thesis is:

What air. the. frarnewnrks and geneml concepts in contributing fields of Web-Based Modeling and Simulati.on?

Information to answer the above question will be gathered in Chapter 2.

Gen(?ral frameworks and concepts from related fields are necessary, but not sufficient for a m(nmingful use in numerous M&S domains that exist. To give an example, a general concejit of model refers to a rejjresentation of a system under study. Such a system can be represented under different modeling paradigms. Each paradigm having its own conc(>pts, rules, modeling languages, tools and established base of users. Therefore the second research issue; is:

How can a general Web-Based M&S environment be customized to a partic-ular M&S domain?

This research issue is (ieveloped in section 5,.'3.

Finally, the environment needs to be developed and repeatedly customized. Modern software systems are characterised by high complexity, while software engineering m(>tli-ods by low productivity, thus letiding to high development costs. Moreover, development of environments such as in the focus of this thesis, suffers from additional c:omplexity as-sociated with tli(- web platforms. For the i)roposed solution to be effective, it would ncxxl to be easily develojjed and especially customized. Model-Driven Engineering (MDE) is a general term that reefers to emerging model-based approaches to engineering. MDE is widely discusstxl and is currently considered as a promising solution to complexity and productivity problems in engineering disciplines. However, entering MDE is not easy as the subject literature is full of weak deffnitions, biased statements, conflicting <>xi)eri(nices and simply connnercial hy])e. Naturally. qu<\stions arise:

What is the essence of Model Driven Engineering (MDE) ?

How MDE can be used to develop a solution to tfie research problem?

(15)

1.2 A p p r o a c h

To achieve broad applicability of our solution to the research problem, we study general concepts and taxonomi(-s in fields of Modeling and Simulation, Distributed Systems, and Collaborative Software to identity fundamental coucc^pts. Basefl on the identified and selected findings, this thesis yields an adaptation of the classic Modeling and Simulation (M&S) framework to the web and collaborative context. This framework, called cMoS (collaborative MotUding and online Sinuilation) is a conc<>j)tual model of the domain of Web-Based M&S applications. Models such as this framework, provide software engi-neers with a proper focus on the problem domain so that resulting software would fit harmoniously with the domain it is being developed for [25]. To deal with complexity of (iev(doping a ncjn-trivial web system such as software incarnations of cMoS ar(\ we emi)loy the emerging approac:h of model-driven engineering.

Specific M&S applications are sufjported through customization of th(> variation points in cMoS concc^pts during the operation phase of the environment. To enable efficient tailoring, the variation j)oints are not implicitly hardcoded as traditionally, but are identified and explicitly expressed as models. To achicive this, we base the generic cMoS system (AcMoS) on the; classical four lay(>r metadata architecture [38]. The uieta-architccture formulates modeling artefacts and customization activities, which are (^s.sential to api)lieation domain custonnzation and AcMtjS operation. Application of model-driven enginein'iug to this meta-architecture enables efficient and programming-free adaptation of cMoS .systems to nc-w Web-Based M&S ai)plications.

To r(xluc(^ complicity and increase efficiency of developing and eustonnzing a. non-trivial web syst(>m such as softwar(> incarnations of cMoS are. w(^ employ th(> emerging a])proach of using mockds as primary engineering artefacts. We study the general field of fvIodel-Driven Engin(>ering (MDE) to establish the fundamental principles and concepts and then proceed into weU established and ÜXCHI ap])roaehes that r<>alize the MDE ideas. These fundamental definitions are used to unitbrndy evaluate mainstream apj)roaclies in order to select existing or pro[)ose new model-driven development jjrocesses.

In order to demonstrate the proposed solution to the research problem, we create ap-propriate MDE assets for the proposed development and customization process(;s. Conse-quc>ntly, the development infrastructure and model-driven [processes are used to develop a software instance of cMoS. Finally we validate om' approach in practic-e: Application do-main customization is demonstrated for a number of Modeling and Simulation dodo-mains: Data Flow Diagrams (DFD), Discrete Event System Specification (DEVS). Process In-teraction (PI) and Dynamic Traffic Routing (DTR). Generic cMoS functionality, such as modeling, c-ollaborative sharing of model specifications and impleiiKnitations, online simulation and management of sharc^d simulation resources is demonstrated as well.

1.3 Definitions

Definitions adopted by researchers are often not uniform, .so key and controversial terms are definiYl to establish positit)ns taken in this PhD research.

(16)

M o d e l - D r i v e n E n g i n e e r i n g refers to systematic use of models as primary engineering artefac;ts throughout the engineering life cycle [98]. MDE is defined by Kent [44] a« generalization of MDA [45] that includes the notion of software develoi)ment [jrocess. MDE is an open approach that (ïinbraccs various technological (kjraains in uniform way. In our view, other model-oriented initiatives, e.g. Model Driven Architectun; (MDA), Domain Specific Modeling (DSM). Model Integrated Computing (MIC). Model Driven Software Development (MDSD) and Model Driven Development (MDD), are instances of MDE.

M e t a n i o d e l c-an be defined as conceptual model of a modeling technique [!)]. This defi-nition encompasses two types of metamodels [93, page 99]: i) meta-data models describe syst(!m dev(!lopm(>nt representations as in [45, 94, 72] and ii) meta-process models t h a t describe system development processes of a technique as in [f]. This research primarily d(»als with th(> m(>ta-data type of metamodels.

1.4 Delimitations

In this thesis. fi(4ds of Distributed Systems and Collaborative Software c'onstitute sec-ondary i^arcnit fields and are not in the focus of this research. We do not seek to con-tribute to these fields, but study them to identify establish(><l concepts and taxononnes. We study the field of distributed .systems, to identify k(\v characteristics of such systems. This knowledg(> is applied when designing and impleuKniting a solution to the research problem. In the field of collaborative systems we ar<> interested in classifications of typ-ical busin(>ss lu^eds that such syst(!nis address. When demonstrating practtyp-ical results of this research, existing tools and systems from the secondary fields are used.

Another delinntation concerns rcnise of models. While model reuse is a part of the distributed, coUaborative modeling, the thesis aims to achieve portability of models in a heterogeneous environment and does not make provisions to (>nsure that shared models are reusable.

1.5 Contributions

Answering the research issues from section 1.1 yielded contributions, which will he i)re-.sented in Section 5.2. In sunnnary. from this th(>sis n^search came the following primary contributions.

Firstly, an adaptation of the claMic modeling and sim.ulation (M&S) framework to the

domain of wcb-bascd collaborative applications is proposed [57]. In Chapter 5, a

frame-work is proposed that combines general concepts and taxonomies from fields of M&S, Distributed Systems and Collaborative Software. This framework explicitly describes fundanunital concepts that are invariant for the broad fannly of wt>b-based modeling and sinnilation aj^plications. The framework providers software engin(>ers with a proper focus on the problem domain so that resulting software would fit liarmoniously with the domain it is being developed for.

(17)

Secondly, a model-driven meta-aTchitcc.tare is proposed [57]. which enai;)les (>fiicient customization of application domain independent cMoS instances. Section 5.3 identifies points of variation in the cMoS framework. Through customization of these points, cMoS instances are tailored to new M&S applic'ations. To achieve flexibility and ease of customization, we bfuse organization of such points on the four level ni(;ta-architecture. Hence, the essential variation points together with affected cMoS concepts and modeling levels constitute the AcMoS meta-architectnre (refer to section 5.3). Application domain customization is demonstrated in cliajjter 8.

Thirdly, two model-driven development proceases are pro[)os(<d and demonstratefl [57]. These processes together with MDE reduce difficulty of developing and more importantly, cu.stomizing cMoS instances. Chapter 6 makes possibk> teclmok)gy choici^s and illustrates how a custom MDE development infrastructm'c is created to support these processes. In Chapter 7. both the infrastructure and processes are ajiplied to create a cMoS instanc(\ Customization of the instance is illustrated in section 8.1.

Fourthly, MDE was fiuecessfully applied to model languages for a number of M&S

formalisms and implementation teehnologies [54, 55, 57, 53]. These contributions are

described in Chapter 4 and section ().2 r(^spectively. Tin' produced metainodels ^uld transformation definitions are released in public domain inider open source licenses.

Fifthlv, control of access to shared simulators was explicitly modelled as abstract, formal and executable transformation definition in the DSL interpretation approach [57]. Hereby, system development and modification occurs at the highest possible level of abstraction, without resorting to software develoi:)nient. Furthermore, applying such transformation to a model, visualizes the behaviour by mainpulating and animating model elements. Modeling of behaviour is demonstrated in section 7.11.

In this research, experience showed that MDE tools can ix' extenek'd with new func-tionality by means of multi-formalism modeling, meta-morleling and model transforma-tion: meta-modeling allows to create user interface (UI) elements for a new func-tionality. These elements enable users to provide^ input parameters if necessary. Multi-formalism modeling alknvs to nnx custom UI ck'ineiits with a source model in a difterent formalism. Finally, transformations can be used to specify th(> behaviour of the new functionality. For example, section 7.12.1 describes how a functionality missing in the cMoS context was added to tool AToNk'.

1.6 Outline of this thesis

This thesis is presented following the structure and style guidehncs from [77]. There are five parts, each containing one or more chapters. The parts, c:hai)ters and relations among them are illustrated hi Figure 1.1.

(18)

1 Part 1: Introduction

Chapterl

• « i » i M

Chapters

Part 2: Related Fields

Chapter2 Chapters illustrates- Chapter4

used in

i

Part 3: Method Chapters Part 5: Conclusion Chapter9 applied in used in

Part 4: Practical Results

used in Chapter? demonstrated in Chapters

Figure^ l . l : Outline of this thesis

Part 1 lays th(> foundations for tlie thesis: Chapter 1 introduces the research problem, research (inestions and hypotheses. Then the research is justified, the approach is briefly described, definitions and delimitations are given and the thesis is outlined. On th(\se foundations, the thesis can jjroceed with a detaileci description of the research.

This research is about engineering web-based modeling and simulation applications with help of models. Cons(Hiueiitly. there arc- two major topics in Part 2: the problem do-main of the M&S applications and model-driven engineering. Chapter 2 describes general concepts in th(> primary parent field of Modeling and Simulation and the secondary fields of Distributed Systems and Collaborative Software. Chapter 3 introduces the emerging field of Mt)del-Driven Engineering (MDE). Two most used and mature MDE approaches (MDA and DSM) are described in a uniform way t h a t allows to identity their advantages and disadvantages. Conc(>pts and franunvorks from the related fields are organised into cla.ssifications that will support discussions in further chapters.

Chapter 4 defines a number of Modelling and Simulation languages i)y means of meta-models and transformation definitions. These practical results are presented so {>arly due to the nniltiple roles they play in this thesis: Firstly, they serve as practical illustration of the MDE conceijts introduced in Chapter 3. Secondly, one of the illustratively defined languages (the Process Interaction language) is used as basis for controlling access to shared sinmlators as described in Chapter 7. Finally, the presented metamodels and

(19)

transformation dermitions ])lay role in a])plication domain definition, which is described in Chapter 8.

Part 3 describ(>s the approach of this thesis. Chapt(>r 5 documents how the focus of this research shifted from code-driven to model-driven development. This chapter estab-lishes a framework for collaborative Modeling and online Simulation (cMoS) apjjhcations. Another subject is a model-driven meta-arclhtecture that expresses application domain ciistoiiiization via essential variation points of the cMoS framework. Two model-driv(-n development processes are proposed to reduce complexity and increas(> productivity of d(!veloping and customizing cMoS instances. These processes arc- ijased on the funda-mentals of t h e Model-Driven Engineering and best practises of the outstanding MDE approach(>s.

The methodological p;ith from the abstract cMoS franunvork to a devek)ped environ-ment is illustrativ(-ly (>xeinplified in Part 4: In Chapter 6, a developenviron-ment infrastructure to sujjport the mod(4-driv(ni (k>velopnient jH'ocesses is created. Chapter 7 demonstrates how a software instance' of the cMoS framework (see section 5.2) is produced with the model driven developnuMit processes. Api)licatioii (k)main customization of a given cMoS instance and general cMoS functionality lik(^ modeling, model sharing, online simulation and management of simulation n^stjurces are demou.strated in Chapter 8.

Finally, Chapter 9 of Part 5 concludes the dt'scribcd r(>searcli. discusses contributions and outlines ])ossible directions for further research.

(20)

Chapter 2

Problem domain

The i)rol)leui (k)uiain in focus of this r(>searc-h encompasses the primary parent field of Modeling and Simulation and the six-ouflary fields of Distributed Systems and Col-laborative Software. This (;hapter introdue(-s i)arent fi(>lds, describes related concepts, frameworks and organises this knowledge into classilications that will support discussions in further chapters. The chai)ter starts with an overview of th(> multi-disciplinary Held of Modeling & Simulatu)n in section 2.1. Next, the secondary fields are presented in sections 2.2 and 2.3 resi)ectively.

2.1 Modeling a n d Simulation

Modeling and simulation (M&S) strives to solve the problem of mukn'standing and pre-dicting behavioiu' of systems. Disciphnes like mathematics, computer science, cognitive sciences and a variety of application domains have been developing their own spt>cific t(\lmiques to solve this problem. In 1976, Zeigler [99] attempted to unify these frag-nu>nted research results into a general tlu^ory. It provided a framework t h a t isolatecl and abstractefl common concepts in a form applicable to all disciplines and domains. Nowadays, M&S is recoginsed as a s(>parate inter-disciplinary research ar(>a.

This section considers M&S from the viewpoint of the general theory by Zeigler [100]. The basic modeling and simulation concei)ts and connections between them are presented in Figure 2.1.

Model

Modeling Simulation

System Simulator

(21)

S y s t e m is a part of the real or virtual environment that is target of modeling. Typically

the system is defined under specific conditions in order to m(>et obj(;ctives of a modeling and simulation project. This specification of conditions reflects objectives of the experimenter and is known as experimental frame (not shown in Figure 2.1).

M o d e l is an abstract representation or spec-ifieation of the system at different levels of

knowle;dge. In tli(> M&S context, a model is typically a higher level specufication that includes knowledge about b(^haviour and internal structure. An important feature of a niode^l is that it is a simplified representation, which allows the modeller to understand and reason about complex systems.

S i m u l a t o r is a coinputation system capable of executing model instructions to

gen-erate mo(k'l behaviour. Possible examples are an algorithm, the human mind, a c-omi)uter. Expervmentation (not shown in the framework) concerns setup and ex(>cution of a model with a. solver. Forms of simulation experimentation:

Interactive experimentation involvc-s running a simulation and making changes to the model to observe the efïec:t. Batch exi)erim(nit involves s(^tting the ex{)erim(nital factors and letting a simulation to run without interacting with the model. Batch experiment can run for a predefincnl run-length or until a specific event and for a set number of replications.

Modehng and simulation are the primary n^lations among entities of the M&S framework:

M o d e l i n g is tli(> act of making a model. Other important relationships are validation

and verification. Validation is a basic modeling relationshijj which answers the question if a mod(>l accurately represents its system counterpart in the exp)erimen-tal frame of Intercast [100]. Verifi.eation concerns the correctness of transforming an abstract representatif)n of a model (the conceptual model) into an executable repres(nitation (the simulation model).

S i m u l a t i o n is tin- process of exec-uting a model. Robinson [80] defines simulation in its

most gcnc-ral sense as imitation of the working a systtun. The execution produces dyiuunic output behaviour according to a (simulation) model. Simulation iwimarily deals with dynamic models.

Models can take a number of forms: A eonr.eptual model is a non-software specific spec-ification of a .system. Robin.son [80] considers a conceptual model to be equal to the concept of lumjied model in [99]. A simulation model is a niod<>l implemented in the software in which sinuilati(jn is to be developed. For a single conceptual model, many simulation models can be created. This allows to select the most ai)propriat(> simulation software on basis of understanding the conceptual mod(;l and allows to separate \\\c in-tellectual property of models from technology-specific cod(\ thus fostering portability of models. Some of tlu; model classifications are described in section 5.2.7.

2.2 Distributed systems

A distributed system, is a collection of autonomous intcncoimected computers or devices integratcxl by software to produce a conii)nting facility.

(22)

PC

PC

n n

^ •

--

„/

Data

p

E

»

File server

1

n W '—' It

f

^

Printer

n

^ T = ^ orkstatio

\

1

Print server ^ Optical drive

)

— — n ^ B i

Tape drive

( H_

Printer

Figure 2.2: E.xample of a distributed system

An example of a distributed system is given in Figure 2.2. The illustrated distributed system provides users with resources.- printt-rs. storage media, files, databases. In gen-eral, resource is hardware, software or d a t a component of a computer system with limited availability. This definition is deliberately kopt abstract, as it has to encompass the nml-titude of possible things that can be shared in a distril^uted system. Another commodity is service, an abstract entity t h a t may be provitled by one or more processes rmming on separate computers and cooperating via a network. T(>riu process is used in the sense of operating systems and means a running [jrogram. From the object oriented view, resources, processes and even entities in processes can be referred to as objects. Objects are given names or identifiers. The difference between these is t h a t the fornuu- can be interpreted by users or programs, while tfie latter are used by programs only.

Usefulness of distributed systems is often characterised with six key qualities de-scribed in section 2.2.1. These often form generic design requirements. The Internet, a particular example of a distributed system is introduced in section 2.2.2.

2.2.1 Key characteristics

One inherent i)r(jj)erty that follows from the definition of distributed systems is separa-tion of objects. This property miderpins key characteristics commonly associated with distributed systems. Coulouris [171 id(mtifi(>s six characteristics:

R e s o u r c e s h a r i n g allows to make a more efficient use of available resources. Sharing resources raises need for resource management. Resource manager is a term that refers to a piece of software that is responsibl(> for management of resource's of a cer-tain type. Common management responsibilities include rnai)ping resoiu-ce names to connrumication addresses and access synchronization to (;nsure consistency of

(23)

states of shar(xl resources. Moreover, each type of ressources may reriuire additional management methods.

C o n c u r r e n c y occurs when N proce.ss(>s exist at th(> same tini(\ In a system with 1 processor, concurrency is aclhevcYl by inteiifatnng execution of portions of the co-existing processes. In a systcnn with M processors, A^ mutually independent pro-cesses can be executed in parallel if M ^ A^. This presents an A''—fold performance incr(>as(> in computation. Distributed systems, by their nature, have potential to achieve^ benefits of parallel execution of concurrent processes. Opportunities arise from user separation, independence of resources and de-(.:entralized service provi-sion. Concurrency further increases the need for n^sourcx' managfnnent.

Fault t o l e r a n c e characterises caijability to detect system faults and recover from th<nn.

There are two major approaches: hardware redundancy and software recovery. Dis-tributed systems allow to reduce the cost of hardware redundancy due to resoiu'ce sharing.

O p e n n e s s characterises capability of a computer system to be extended. This char-acteristic can be applied to both the hardware; and software levels. Under tli(> context of distributed systems, openness is defined by the degree of disruption to or duplication of (existing services when new resource-sharing services art! added. Documentation and publishing of key interfaces, standardization in system inte-gration, availability of general interprocess communication increase openness of systems.

Scalability charac-terises whether a system or application software needs to change as

the scale grows. The scale of distributcxl systems can range from as few as two computers to thousands computers in internetworks. Evtuy aspect of a distributed system - shared memory, proc(!ssors, etc.. - may affect scalability. Therc^fore an effective scalable system should be designc^d with assumption that every such aspect can be ext(!nded. The challengers of such design increase; as the size and complexity of nc>tworks grows.

T r a n s p a r e n c y is a |)n)p<>rty of hiding from application us(>rs or devekjjiers separated components of a distributed system as one whole. The Refercnice Model for Open Distributed Processing (RM-ODP) [79] distinguishes eight forms of distributk)n transparenicy:

• Access transparericy hides the diffennice bc-tweeni accessing local and remote objects.

• Failure transparency hides faults from users and applications, thus allowing them to complete their tasks.

• Location transparency allows to access objects without knowing their k)cation. • Migration transparency allows moving servic(> providers from one location to

another without affecting the provision of the servk-e.

(24)

Application Transport Internet Link Physical Application Presentation Session Transport Network Data Link Physical

(a) Internet (b) OSI

Figure 2.3: Tho Internet and OSI structures

• Rtlocntion transparency hides the relocation of a, scTvice from (-lieuts using it. • Replication transparency liid(^s existence of nniltiple copies of a service from

users of the service.

• Transaction transparency hides the (ïffects of overlapped or c(mcurrent execu-tion, maintaining consistency among the involved objects.

Access and location transparencies, combined known as network transparency, most strongly affect usage of distril)uted resourc(>s and are the most im])ortant forms of transparcnic-y.

The primary ü characteristics are not given, but ratli(;r gained througli propcT design. These characteristics form generic design reciuirements for distributed systems.

2.2.2 T h e Internet

The Internet is a distributed system of interconnected com]Mit<>r networks that use the Internet protocol suite to form a global infrastructure to deliver information and services. The Internet itself stands on three cornerstone infrastructures: physical, contractual and

cornmunicational. The first two are responsible for physical interconnections of existing

networks and for agreements that regulate exchange of data traffic among the networks. The latter is a s(>t of protocols that transfers data between computers and applications. The Internc-t is a j^artic-ular (example of a wide area internetwork. Tlu^ ideas t h a t l(>ad to the Internet originated from the research and development of national computer networks in th(> lü70s. Tlu^ Internet in particular, takes its origin from ARPANET [83], the first large scale computer n(>twork dcweloped by ARPA of the U.S. Department of Defense.

The Internet is desigiKxl around a layered ar<hitectur(\ which theoretically allows a technology within a layer to be replaced without affecting the other laycn's. Figure 2.3 illustrates how the Internet architecture compares to the Open Systems Interconnection (OSI) Reference Model, a guideline proposed by the International Organization for Stan-dardization (ISO) to design network systems that are open for conmunncation with other systems. The bottom four layers in the figure provide thc> basic intc^rnetworking conmui-nications service - this is the domain of n(>tworking enginecns. Devi-lopers of distributed

(25)

L A Y E R Application Transport Network Link P R O T O C O L S http, ftp. pop3. smtp. ssh, iinap, ... TCP. UDP. DCCP. SCTP, ... IP, ICMP. IGMP, ARP, ... ATM, Ethernet, P P P S L I P ... Table 2.1: Internet protocol suite

Resource Sharing Opemiess Concurrency Scalability Fault Tolerance IVaiisparency DNS

V

V

T C P / I P

V

V

URL J

V

Tabk- 2.2: TIK^ Internet and key characteristics of distributed systems

systems are primary concerned with the layers above wli(>re connnunication reciuirements of specific application.s ar(> implemented.

Table 2.1 illustrates th{^ Internet protocol suite and their relation to the layers of the Internet architecture. An important part of the suite is the combined set of T C P (Transmission Control Protocol) and IP (Internet Protocol) protocols. The Internet in'otocol suite was designed to be independent of the underlying [)hysical medium, which allowed the Intimiet traffic to be carriinl across any coimiuniication networks and lead to wide adoption of the suit.

With the advent of broadband telecoHununication networks, the Internet is used as basis for distributed services, applications and systems. Table 2.2 illustrates contribu-tions of the Internet towards usefulness C'liaracterlstics of distributed systems that are built atop. The same table includes Domain Name System (DNS), a naming solution for the Internet devised by Mockapetris [83, page 171]. DNS is a crucial service that is ns(xl across the Internet by applications and services.

Many apj)hcations and servic<>s exist that are built on top of the Intern(^t transport layer. The two best-known Internet scTvices are electronic mail (e-mail) and the World Wide Web ( W W W ) . Other popular services include file sharing, Usenet ncnvsgroujis. Instant Messenger, Gojjher, IRC, to name a few. Moreover, new services can be built ui:)on existing services.

W W W , also known as the Web, is worth a special mentioning because it is so ubiqui-tous to a ca,sual us(>r that the Web became synonymous with the Internet itself. W W W is a global hyperni(>dia information system. It is a colkntion of documents/pages stored as files on computers distributed around the Internet. Web servers serve th(>se (k)cuments to users browsing this si)ac(^ with help of web clients known as fnvwscr. The browser u.ses th(> HTTP application-level protocol to access and transf(>r a w(^b page over a T C P coimection with a web st>rver. Such i)ages are rich doc-mnents writt(>n in HTML and can

(26)

contain multimedia. HTML defines contents, structure and re])r(>sentation of documents and allows to embed links to oth<>r pag(>s stored c>lsewher(> on the W(>b. Each such linking, known as hyperlink, contains a full totality of information (protocol, symbolic Internet name of the server machine;, pathname and filename) needed by browser to access the contents of the linked page over the Internet. DNS is used to translate the symbolic Internet name into the address of tlie server inaclnn(>.

Today (2006) the Internet includes thousands of smaller connnercial. academic, do-mestic, and government networks and counts over 1 billion of users. It stimulated de-velopment of new areas of human activities and had serious impact on how people work and recreate. For an up to date overview of the Internet, wc> refer tlu; reader to out; of the many available guides [14, 40].

2.3 Collaborative software

Collaborative software or groupware is application software that integrates

activities of multiple concurrent users within a project.

Research in collaboration has resulted in a large number of tools and (uivironments [97]. A number of classification frameworks exists that help to organize these contributions. Perhaps the most known groupware typology is based on space and time cat(>gorization and was proposed by Grudin [39]. In [81], basic distrihution arehitectures and possible subtyi)es are distinguished to helj) choosing the best groupware platform for a given collaboration scenario. Malone [60] classified collaborative tools according to their co-ordinati(jn capabilities that can be used to manage the most connnon depetidencies in collaboration activities.

Th(^ above mentioned classifications focus on the approaclu^s in groupware develop-ment or mechanics of collaboration. In the context of this research a more user-oriented cla.ssification based on business needs of clients was called for. Sarina [86] developed a hi-erarchy of collaboration needs according to which c-xisting or to-be-developed groupware can be categorized. In a more abstract framework, Butk>r and Coleman [10] suggestcxl five empirically derived models of collaboration needs ba.s(>d on int(n'activity and group size. Th{> latter classification matches better the goals of this r(>search with respect to collaboration (see section 1.4).

Butler and Coleman suggested that the majority of collaborative environments sup-])ort one or more of the five prmuiry collaboratioii models:

L i b r a r y is a common mod(4 that is characterised by long-lasting content, many readers and few vvritiH's, weak relation between readers and writers, content management. S o l i c i t a t i o n concerns interactions between a small set of recjuesters and potentially

multiple» respondents.

T e a m supports activities of interdependent, c(jntrolled, relatively small group of reduiers and writers.

C o m m u n i t y is a relatively large;, loose and moderated group tliat pre-feu's reading over writing.

(27)

Library

©

- • • level of Interaction

Team

Figur(> 2.4: Five primary collaboration needs (adapted from [10])

P r o c e s s S u p p o r t concerns automation of j)rocesses and workflows through us(> of tech-nology.

Figm'e 2.4 illustrates how these models are rcdated to each other in the typology space. The.se five collaboration modelH, JMU'C or combined, provide developers with a frame-work to uncover how new systems designs and available solutions can contribute to collaborative needs of a client.

2.4 Summary

Tliis chapter introduced litdds related to the probknn domain of the res(>arch. The basic Modeling and Sinuilation concepts were introduced. The key cliaract(Tistics of distributed systems provide; developcu's with a framework to see how chosen solutions and designs contribute to [jropertics of the expect(Kl system. Finally, a collaboration classification useful for the goals of th(^ n^search was identified.

(28)

Chapter 3

Model-Driven Engineering

This chapter is a guide into the field of Model-Driven Engineering, Befor(> MDE can be introduced, we have to understand its context. Section 3.1,1 briefly tlescribes the software development process and typical i)rol:)lems occurring in software develoijment. Next section number 3,1 studies definitions of MDE available in the literature and identifies the fundamental ideas behind MDE, The following sections discuss coucc^pts that are crucial to realization of the MDE ideas: the niodehng architecture, modeling languages as system and transformations, A number of approaches exist t h a t put the MDE ideas into practice. Two most pronnncnit, nrature and often contrasted approaches are described in sec'tion 3,3,

3.1 What is MDE?

To answer th(- tiuestion, we n(>ed to understand the engineering process MDE applies to. This thesis primarily deals with tlic discipline of software engineering, therefore software engineering proc(-ss is discussed below. Given the perspective» on the process, we can outline th(» types of i)roi)k>ms that software projects deal witii. Understanding these problems helps to identify potential b(-nefits of and justify the corncTstone ideas behind MDE, Next, we provide a numiier of definitions of MDE found in the literature. These are analysed and esscMitial ideas arc distilled into an answ(>r to the ciuestion posed in the title of this section,

3.1.1 Software development process

There are several models of development process in (existence [32, chapter 2], Instead of describing (>acli individual model, we propose a model of concepts essential to models of software development processes. To avoid a possible confusion with the MDE concept of metamodel, we refer to the proposed model as megamodel. This model is a simplified, yet sufficiently accurate rejirc^sentatiou of the software development process t h a t captures concepts essential to building a software system. The proposed megamodel i) assumes t h a t th(> iterative/waterfall dichotomy is the most important division among all software development processes and ii) nxluces the .scope of the mod(-I by excluding activities

(29)

step, phase, component {ordered}

Activity

produces

doc, code V l..n breakdown 1..n

iteration

l i

breal<down

1

single iteration for complete set of

functionality

orientation —

Project structures

1..n {ordered} System [— provides —>\ Functionality

T

runs on 1..n

i

developes solution domain orientation -1..n problem domain

I Platforni | | Developer — feedback — j Stakeholder \

multiple iteration per subset of

functionality

Figure 3.1: Meganiod(>l of the software development process

tliat do not directly produce» system artefacts, e.g. initial plamiing, testing, deployment. Figure 3.1 presents the megamodel as UML class diagram.

In the focus of the megamodel is (;oncept Process. Process structmes a software development Project. Project is a planned activity that delivers one or more increasingly detailed software artefacts that specify Sy.stem imder development. Code is the typical target of a project as it can be executed, thus instantiating a system and providing a set of Functionalities requested by Stakeholders. System is implemented for a particular

Platform,, a general framework, either in hardware» or software, which allows system to

ojjerate. Notice the cardinality of the relationship b(»tween System antl Platform: in general, .software projects have to implement software for multiple platforms. Strongly related to engineeu'ing is notion of domain. Analysis of definitions of domain in [18] reveals t h a t domain is "a body of knowledge organized around some focus..", further identifying that such focus li(»s in a real world urea of exp(U'tise and in expertise of building software systems (or parts thereof) for that area. In line with this view, syst(-m is a software solution to a problem in a so-called problem domain, e.g. virtual environments, insurance systems, M&S. System itself consists of parts which correspond to solutions

domains such fus database systems or numerical librarii's.

Furthermore, to reduce compk^xity and to bettin- track development progress, [)roj(H't breaks up the task of software develoi)ment into smaller chunks. Tlier(> are two major approaches to how one breaks up a project. These are known as the Waterfall and

Itera.tive process models. The waterfall approach breaks down a project based on activity.

(30)

)

r?" /

/ /

V

/require-\ / merits ^ specification code complexity Analysis

\

\

'

requirements

1^ ^ ^

Design

\

\

^^-J

specification [n] Coding

^

code 1 Testing 1

Figure 3.2: Abstraction pyramid of din-elopment activities

functionality. Note that to implement a subset of functionality a complete production activity is always reeiuired. This is reflected in the cardinality of the activity-project relationship. Given a constant activity, breakdown is achieved by decomposing jjroject into a number of smaller projects or iterations. The resulting seciuence is ordercnl by priorities of functionalities. Examples of the iterative process model are R U P (Rational Unified Process) and Agile prcx^esses. It follows that an itcn'ative project with only one iteration is a waterfall project. Both models go through the same activities in order to build a system. Combination of both models is also possible a« in the staged delivery process.

Next, we turn to the breakdown of the activity that produces system artefacts. The result of th(" breakrlown is a sefiuencs^ of sub-activities t h a t are called steps, stages, phases or components depending on the development method. The steps are ordered along the abstraction flimension: each step produces an artefact, which is a refinement of th<> system specification receiv(>d from the previous step. Figure 3.2 illustrates how a secjuence of common sub-activities relates to different levels of abstraction (the higher, the more abstract). The abstraction pyramid is a metaphor for reduction of complexity with increase of abstrac'tion (upwarfl). Due to the simplification of this megamodel, the illustrated breakdown of concept activity int;ludes only tasks that directly produce system artefacts: Analysis involves activities to transform initial business requirements from tlK^ problem domain intcj formal rcHjuirenKnits for software systems. Design is a task of prec;isely specifying the software to meet the rec|;inrements. Coding stei) involves translating software; specifications into executable code. In ck'sign or coding, a choice of the platform is made and technological and (nigineering details tliat are irrelevant to the fundamental fiuictionality of a software are added to make the system executable.

Finally, each development activity carries costs. Notice how in Figure 3.2 complexity and conseciuently cost of development are increasing a« tli(> system approaches its

(31)

com-1000 r 500

1

a

1

§

TO 200 100 50 20 10 5 2 • ^ , ' ' 1 I I I I 1 I ,. Requirements Design Code Development Acceptance Operation

test test

Step In which error corrected

Figure 3.3: R(>lative cost to hx an «>rror over life-cycle (adaptcxl from [6]) pleteness, A further insight can he found in economics of correcting errors during system dev(!lopment. In [6] Barry Boehm {)roduced some compelling evidence showing that the cost of correcting an error increases dramatically the later in the system developnunit it is d(>tected and corrected. Figure 3.3 plots the relative cost of fixing an error in re-quirements as function of the development step. This evidence illustrates that making (;hanges early in the development process is cheaf), but becomes extrem<4y exp(nisi\'e in the later stages.

3.1.2 Problems of software development

Section 3.1.1 described the structure of the software development proc(-ss, activities and associated levels of complexity and costs. The following is a description of the most typical liroblems faced in software developm(>nt.

S e m a n t i c g a p . Characterizes the difference- betwecni two d(\scriptions of an object by different linguistic re])resentations. For exami)le, the gap occtirs wlienever ordinary human ac-tivities, ot)servations. autl tasks are transferrrxl into a computational repre-sentation. Mapping from nvd world applications into computer applications eamiot be automated and requires technical background kn()wledg(\ An example of semantic gap manifestation is the difficulty in miderstanding the recinirennents for a software syst(>in [32]. Consequences of this problem can be seen in Figure 3.3.

C o m p l e x i t y . Compk-xity of systems grows faster then abstraction levels provided by developminit means of engineers, such as platforms and programniing languages.

(32)

P r o d u c t i v i t y p r o b l e m . Software development is focused on low-level design and cod-ing: \yriting code is percT.ived as productive and writing (high-level) documentation is not [45].

D o c u n i e n t a t i o n a n d m a i n t e n a n c e , fjow- and (>si)eeially high-level documentation is separate from code. As w<> have seen in the productivity problem, writing code is being productive and writing documentation is not. Moreover, maintaining documentation in sync; with code is a costly and manual jjrocess. Consecjuently. the lac-k of incx-ntive and r(X[uired significant effort are the reasons why docunientation is often of [joor (juality and outdated. The documentation problem makes mainteii;uice and change of systems dilficult.

P o r t a b i l i t y . Software industry is characterized by rapidly changing technologies: new technologies and n(!W versions of technologies app(>ar every year [45]. Companies are forced to chase these changes eyen if solutions do not ncH'd to change. To illustrate tins point, note the cardinality of the input and outi)ut of the ciesign step in Figure 3.2. Migration of existing solutions to new technologies is extremely costly due to the documentation aufl complexity {)roblems. Moreov(!r, investments in obsokïte teclmologieïs and systems based on those technologies loose yalue.

I n t e i ' o p e r a b i l i t y . Software .systems are often not nujuolitlhc: a .system may need to interact with other sy.stems, a system may span multiple technologies or be assembled by reusing already existing eonifjonents. In such cases, (sub-) systems based on different technologi<>s may ne(>d to interact with envh other, thereby creating need for interoper-ability.

3.1.3 Definitions of M D E

MDE and model driv(>n a,pi)roaches, standards and technologies have gathered a lot of attention, numerous articles, books and thousands of {)ages of documentation. Despite the growing amount of information, Fayrc; [2G] observes that the tru(> essence of MDE is not described there and MDE core concepts are not defined i)recis(>ly. In the following we provide a number of definitions of MDE found in the litin-ature.

The VVikipedia defines MDE as "systcnnatic use of niodcds as jjrimary engineering artefacts throughout the engineering life cycle" [98]. This definition stresses the central role of models, which is in contrast to the traditional d(>velopinent wher(> models are second class artefacts.

Kent [44] defines MDE on the basis of Mod(4 Driven Architecture (MDA) concepts by adding notion of software^ developuunit [)roc(^ss and extending model space beyond the abstraction dimension of the PIM-PSM classification of MDA. In [44. page 10], Kent summarises that "a model driven engineering approach must specify the modeling languages, models, translations between models and languages, and the proc{>ss used to coordinate th(^ cionstruction and evolution of the models". Moreover, powerful tool support is required if the burden of maintaining models in lin(> with code were not to outweigh the benefits of models.

(33)

MDE definition would be incomplete without delining MDA. MDA is a partirular approach by t h e Object Management Group (OMG) to using models in software dcv(>l-opment. In [15], Steve Cook refers to MDA as standardized approach that is based on abstraction of similarities in technological and engineering [jlatforms and relics on the OMG's mofleling technologies, most notably the Unified Modeling Language (UML) and the Meta-Objc-ct Facility (MOF). To dev(;lop a system, first a model of the syst(>ni is built that is abstract from technological details. Such model can be ported to multiple technological platforms. Then this model is transformed into one or more models specific to the chosen platforms. In turn, these models are again transformed into the Hnal code. In MDA. transformations are perforiiicd by a human or an automated algorithm [74], though the latten' is preferred.

.I(>an-Marie Favre [26] obsery(>s that the true essence of MDE concepts is ritli(>r poorly descriijed in literature or is obscured by the bias towards the particular technological orientation of OMG. The autlior's view is that MDE is a nior(> broad and open approach than MDA and acconnnodates many technological spaces in a uniform way. In this vision. MDA is just a particular incarnaticjn of MDE implemented in the set of technologies defined by OMG.

Noteworthy is the vision Ijy prominent MDA contributors from IBM: Grady Booch. Alan Brown, Sridliar Iyengar, .lim Rumbaugh and Bran Selic. In their MDA Manifesto [8], the authors outline thrc^c^ complementary ideas t h a t form the essence of MDA: direct representation, automation and oi)en standards. The first idea recognizes t h a t in order to lessen the semantic gap, tlu^ focus of software dcv<dopment lia.s to be elevated from tec:lmology domains towards c;oncepts of th(> problem doniaiu. Automation refers to nux'hanization of those dcveloi)ment tasks that do not rc>quire human intelligence. The most important goal is tf) bridge the gaj5 that exists b(>tw(H'n al)stract models and c;ode as cons(;quence of the direct representation idea. The final ick^a relates to OMG's missicjii to solve tool integration probknns through open vendor-neutral interoperability standards. In yet another jjublication on MDE. Schmidt [88] sees the subject as aj^proach to solv-ing the semantic gap and platform (•omi:)l(^xit3' problems by means of modelsolv-ing languages that can effcx'tively express tlomain concepts. Fiuiher more, the author stresses that in order to ensure consistency betwf^en nicxk^s and api)lication imijknnentations, tools are needed that can analyse models and .synthesize various types of artefacts, including models themselves.

3.1.4 Essence of M D E

We have? seesn a number of definitifins of what Model-Dri\'en Engineering is. Analysis of the definitions reveals a set of essential commonalitit^s.

M o d e l s a r e p r i m a r y e n g i n e e r i n g a r t e f a c t s : All defiiutions agree that models should bf^ first class artefacts in model driv(ni approaches to engineering. Models can help de-velopers to deal with complexity (refer to page 20) and serve as documentation. Being a primary artefact, places additional requirement on MDE models: model must be a

computerized representation. In such a model, each element that can be interpreted by

a computer, corresponds to a concept in the modeling domain [15]. This requirement is crucial for distinguishing niod(>ls t h a t can be primary art(>facts from thos(^ that cannot.

Cytaty

Powiązane dokumenty

Posłużywszy się takim obrazem Chryzostom podkreśla że w wychowaniu dziec­ ka szczególnie ważną sprawą jest ustanowienie odpowiednich praw, które mają za­ bezpieczyć

Otóż namalowanie ikon miestnych na miedzi oraz obrazu Hodegetrii Supraskiej (a zapewne również wspomnianej ikony Zbawi- ciela w ołtarzu bocznym przy filarze) można

Jeżeli mimo zgłoszenia zastrzeżenia do protokołu rozprawy sąd nadal toleruje udział radcy prawnego w charakterze pełnomocnika osoby fizycznej, to postępowa­ nie

Under steady state conditions and following the stress shadowing effect, the develop- ment of networks with closely spaced orthogonal fractures must occur under subcrit- ical

specimen B (figure '40b) which shows much weld-undercut in the longitudinal. Figure '41b shows crack Al of specimen B at the side of the 6,5 mm weld, looking, from bulkhead

KOPERNIKA Profesor Jerzy Vetulani był wybitną po- stacią, Jego życie było niezwykle intensyw- ne, a angażował się w tak wiele dziedzin, że Jego życiorysem

Właściwie dobrane materiały, ciekawe zestawienia kolorystyczne, odpowiednio dobrane elementy małej architektury i oświetlenie są zarówno dla domu, jak i jego

Dodatkowo lista uczestników katechez zdaje się potwierdzać tendencję cha- rakterystyczną dla innych duszpasterstw, że wśród nich przeważały kobiety (np. w roku akademickim