描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787302491873
Chapter 1 Introduction 1
1.1 Motivation:middlewareformobilesystems ………. 1
1.2 Problemswitharchitecture-centricapproaches……… 4
1.3 Objectivesofthebook…………………. 7
1.4 Ourapproach……………………… 10
1.5 Structureofthebook …………………. 13
Chapter 2 The Problem Domain 15
2.1 Overview ……………………….. 15
2.2 Middle
2.3 Middle
2.3.1
2.3.2
2.3.3
2.3.4
2.4 Middle
2.4.1
2.4.2
2.4.3
2.4.4
warefordistributedsystems…………… 16
wareformobilesystems …………….. 22
Mobilesystems…………………. 23
Mobileapplications……………….. 24
Problemswithmobileapplicationdevelopment …. 26
Middlewareformobilesystems …………. 27
wareformobilesystems:examples ……….. 32
Event-based(orpublish/subscribe)middleware … 32
Tuplespace-basedmiddleware …………. 36
Objectandcomponentmiddleware……….. 39
Generalizationofcommonalities ………… 42
2.5 Aspectstobemodeled…………………. 44
2.5.1 Modelingmobility ……………….. 44
2.5.2 Modelingotheraspects …………….. 46
Chapter 3 Related Work 49
3.1 Overview ……………………….. 49
3.2 Requirements……………………… 50
3.2.1 Requirementsforstylespeci.cation……….. 50
3.2.2 Requirementsforthemodelinglanguage…….. 53
3.3 Surveyofrelatedwork…………………. 55
3.3.1 Surveyofarchitecturalstyles ………….. 55
3.3.2 Surveyofmodelinglanguages………….. 64
Chapter 4 An Overview of the Approach 68
4.1 Overview ……………………….. 68
4.2 Thearchitecturalstyleforthemiddleware……….. 70
4.2.1 Middleware-inducedstyle ……………. 70
4.2.2 Layeredstructureofthestyle………….. 71
4.3 Themodelingandsimulationframework………… 73
4.3.1 Style-basedmodeling………………. 73
4.3.2 Thestyleforthemiddleware ………….. 78
4.3.3 Re.nement …………………… 79
4.3.4 Simulation …………………… 82
Chapter 5 Architectural Style-based Modeling 86
5.1 Overview ……………………….. 86
5.2 BackgroundoftheTGTS ……………….. 87
5.2.1 Graphsandgraphmorphism ………….. 87
5.2.2 Graphsandobject-orientedmodeling………. 88
5.2.3 Rulesandgraphtransformation ………… 89
5.2.4 Metamodeling …………………. 91
5.2.5 Typedgraphtransformationsystemandstylespeci.ca-tion ………………………. 92
5.3 Speci.cationofthestyle………………… 94
5.3.1 Structuralpart …………………. 95
5.3.2 Behavioralpart…………………. 97
5.3.3 Syntaxandsemanticsofthemodelinglanguage…. 101
Contents vii
Chapter 6 Style Examples 104
6.1 Overview ……………………….. 104
6.2 Themiddlewarefornomadicnetworks …………. 106
6.2.1 Architecturalcommonalities…………… 106
6.2.2 Theconcretemiddleware:WirelessCORBA…… 110
6.3 Conceptualstyle ……………………. 117
6.3.1 Structuralpart …………………. 118
6.3.2 Behavioralpart…………………. 120
6.4 Platform-independentconcretestyle ………….. 123
6.4.1 Structuralpart …………………. 123
6.4.2 Behavioralpart…………………. 125
6.5 Platform-specificconcretestyle:WirelessCORBA ……… 133
6.5.1 Structuralpart …………………. 133
6.5.2 Behavioralpart…………………. 137
6.5.3 IDLsemanticsspeci.cation …………… 147
Chapter 7 Style Re.nement 149
7.1 Overview ……………………….. 149
7.2 Requirementsforthere.nement ……………. 150
7.3 Existingapproachesandopenproblems ………… 156
7.4 Rulemapping-basedstylere.nement …………. 158
7.4.1 Structuralre.nement ……………… 159
7.4.2 Behavioralre.nement ……………… 162
7.4.3 Re.nementoftheTGTS-basedstyle ……… 183
7.5 Evaluationandcomparison ………………. 184
Chapter 8 Style Simulation and Tools 187
8.1 Overview ……………………….. 187
8.2 Graphtransformationsimulationtools…………. 189
8.2.1 Requirementsforthetool ……………. 189
8.2.2 AGG………………………. 191
8.2.3 PROGRES …………………… 192
8.2.4 Fujaba……………………… 194
8.2.5 Evaluationandcomparison …………… 195
8.3 Style-basedsimulation …………………. 198
8.3.1 Stylespeci.cationandsimulation………… 198
8.3.2 E.cientvalidation……………….. 204
8.3.3 Re.nementconsistencycheck………….. 207
8.3.4 Behavioralconsistencycheck ………….. 208
8.3.5 Style-basedengineering …………….. 216
Chapter 9 Conclusion 219
9.1 Evaluation……………………….. 219
9.1.1 Evaluatingthestylespeci.cation………… 220
9.1.2 Evaluatingthemodelinglanguage ……….. 221
9.2 Relevancetopractice………………….. 224
9.2.1 Styleanddesign ………………… 224
9.2.2 Theconceptualstyleanddesign ………… 225
9.2.3 Theplatform-independentconcretestyleanddesign . 227
9.2.4 Theplatform-speci.cconcretestyleanddesign …. 229
9.3 Contributions……………………… 230
9.4 Futurework………………………. 234
9.4.1 Industryprojectexperience …………… 234
9.4.2 Automationandtoolsupport………….. 235
9.4.3 Developmentofotherarchitecturalstyles ……. 236
9.4.4 Modelbasedtesting ………………. 237
Appendix OMG Wireless CORBA IDL 239
Bibliography 249
List of Figures 265
List of Tables 270
Acknowledgements
Along the way, I have got a lot of guidance, support, encouragement and companionship from many people, to whom I am full of gratitude. Above all, I am very grateful to Prof. Dr. Gregor Engels (at University of Paderborn), for all the dedication and support he has given at every stage of the book. He has signi.cantly contributed to the book with his comprehensive knowledge, penetrating perspectives, and consistent patience. Thanks to his uncountable suggestions, I have the possibility to make the book such a one that I am satis.ed with. Prof. Dr. Reiko Heckel (at University of Leicester) also deserves a great deal of thanks. He has guided me into the research area of software modeling and graph transformation systems, starting from basics and going in deep. I have bene.ted a lot from his generosity and collaboration. He has given me many good ideas and suggestions. Especially, the main modeling and simulation framework proposed in the book is based on his original idea. I have also got many useful suggestions and hints from other people. Thanks to Jaakko Kangasharju (University of Helsinki), the designer and developer of Wireless CORBA, for the discussions and suggestions. I would also like to thank the Fujaba team for the support and help. Especially thanks to Leif Geiger for the guides to Dobs, and to Lothar Wendehals for the guides to Fujaba. I would also like to thank all my friends and neighbors in PHW2A for their companionship. Especially thanks to Elina Hotman, ChengYee Low, Madhura Purnaprajna, Su Zhao and Andreas Ziermann for proofreading of Acknowledgements this manuscript. I deeply thank my family for their support and understanding. My grandfather has taught me to be optimistic even in the darkest and hardest time, to be appreciative to every experience in my life even to tortures and di.culties. My parents have always encouraged me to try new things that I dream of. Ping Guo Kunming, November 2016
provides service Middleware
Middleware Figure 1.1 Middleware and applications 1.1 Motivation: middleware for mobile systems by mobility, and enhance dependability and usability of developed mobile applications. The criticality and pervasiveness of middleware for mobile systems is continually growing. However, the design and development of the middleware is a di.cult task, and it is not easy to ensure the quality of a developed middleware. Middleware designers and developers (Fig. 1.1) have some serious problems to cope with. The middleware is becoming increasingly complex with the fast development of wireless technologies and the increase of mobile application requirements. The managed components are increasing in scale and in scope. The requirements for the middleware are becoming more and more complex. Increasing system complexity typically brings the following problems: . longer design and development time;
. more complex assembly due to number of components and number of people involved;
. increased cost and time for testing;
. increased maintenance costs.
Overall, this results in an increased time to market for the developed system. And development and maintenance costs are also increased in order to ensure the quality of the system. However, the current research area of middleware for mobile systems has concentrated on developing new types and patterns of middleware, and there is nearly no work on the design and development process of the middleware. At the same time, to build large complex systems you must have pre-dictability. We can not a.ord to be ad-hoc in design. However, there is no common agreement or understanding of the middleware for mobile systems. The middleware platforms present a great diversity: . they have distinct functionalities and provide various services to applic-ations;
. they use very di.erent design concepts and strategies;
. the aimed wireless network could be di.erent (e.g. nomadic network or ad-hoc network);
. they exist because of mobility or in spite of mobility or both;
. the moving units can be logical or physical mobile or both;
. the de.nition of context and the level of context-awareness can be very di.erent.
On one side, designers have to manage the huge diversity of design techniques, concepts, implementation technologies of the middleware. On another side, it is very di.cult for the designers to reuse the already established design knowledge or successful experience when building new systems. This makes the design process quite ine.cient and unpredictable, and thereforey risking the project.
1.2 Problems with architecture-centric approaches Engineering [18] is the systematic application of scienti.c knowledge in creating and building cost-e.ective solutions to practical problems in the service of mankind. Software engineering [18, 140, 137] is that form of engineering that applies the principles of computer science and mathematics to achieving cost-e.ective solutions to software problems. Generally speaking, software engineering researchers seek better ways to develop and evaluate software [135]. They are motivated by practical problems, and key objectives of the research are often quality, cost, and timeliness of software products. “One man’s magic is another man’s engineering” (Robert Heinlein). Engineering design is much more routine than innovative [134, 137]. It depends upon the existence of a mature discipline, such as standard notation for recording and communicating designs, established procedures, published processes, design standards, small number of unit operations, widely disseminated handbooks, etc [137, 88, 116]. Software architecture has grown in importance to be a key discipline within software engineering [137, 115, 16]. Architecture-centric development directs on developing large, complex systems in a manner that facilitates robustness of products, economy of the development process and rapid time to market. It focuses on the construction of more abstract architectural elements, or, models, but not the program source code. A model is a reduced representation of the system, from a given viewpoint [23]. This enables designers to abstract away unnecessary details and concentrate on the main concerns and problems 1.2 Problems with architecture-centric approaches of the system. The model is coarse-grained enough so that the design of complex systems can be represented in an easier understandable form than the actual system. Besides helping understanding complex problems and solutions, the model communicates understanding between designers and developers. It can be also used as a guide to implementation. One of the key issues in software development, like in all other engineering areas, is to ensure that the product delivered meets its requirements. Another key purpose of models is to allow the reasoning about important properties of the software before actually building it. Developers can manipulate the models in signi.cantly more sophisticated ways than they can code. Model-based analysis such as model checking and simulation takes place at the early stage within the process of software construction, thus ensuring the quality of the system already at the modeling level. Besides, testing is often used in software engineering for validating properties. To support architecture-based development, software architecture model-ing languages [92, 36] and their accompanying toolsets have been proposed to provide notations for specifying and analyzing the architectural models of software systems. Modeling languages (Fig. 1.2) provide abstractions that are adequate for modeling or specifying a large system, while ensuring su.cient detail for establishing properties of interest. Platform Independent Level Platform Specific Level
<> Modeling
Language
<>
Figure 1.2 The architecture-centric approach Re.nements (Fig. 1.2) are the basic steps in the architecture centric software development process. Starting from an abstract description of the system, stepwise re.nements yield more and more concrete speci.cations that should .nally be directly implementable on a machine. For example, an abstract or a conceptual architecture is generated from user requirements, which mainly covers core functionality components. Later, a more concrete architecture is created that integrates non-functional requirements like security concepts and design speci.c aspects. In general, a conceptual architecture is smaller and easier to understand, while a concrete architecture re.ects more design or implementation concerns. “Architecture is design, but not all design is architecture.” [36]Thatis, many design decisions are left unbound by the architecture and are happily left to the discretion and good judgement of downstream designers and imple-menters. The architecture establishes constraints on downstream activities, and those activities must produce artifacts – .ner grained design and code, that are compliant with the architecture, but architecture does not de.ne an implementation. Architectural style (Fig. 1.2) is an important concept in the software architecture area. A critical challenge for software engineering is to capture system designs and reuse established design knowledge when building new systems. One way to do this is to de.ne an architectural style for a col-lection of related systems. Indeed, the use of patterns [100] and styles of design is pervasive in many engineering disciplines. An established shared understanding of the common forms of design is one of the hallmarks of a mature engineering .eld [137]. The architectural style of software engineering determines a coherent vocabulary of system design elements and rules for their composition. Styles are often developed systematically to solve di.cult architectural problems at the conceptual level. Most styles originate when novel classes of software systems are being designed or existing systems are being adapted to unforeseen circumstances and/or environments. They are formulated and evolved to consistently repeat successes and avoid failures from previous projects. New architectures can be de.ned as instances of speci.c styles. By structuring the design space for a family of related systems a style can, in principle, drastically simplify the process of building a system, reduce costs of implementation through reusable infrastructure, and improve system integrity through style-speci.c analysis and checks. Both software architectures and middleware technologies focus on helping the development of large-scale, component-based system, but they address
1.3 Objectives of the book di.erent stages of the development lifecycle. Software architecture is an abstract model of a system that highlights the system’s critical conceptual properties, while middleware enables the system’s realization and ensures the proper composition and interaction of the implemented components. Some researchers are trying to coupling architecture modeling and analysis approaches with middleware technologies [94, 90, 44]. For example, some architectural styles such as client-server and event publish-subscribe style can be used as a reference on the abstract layer for middleware development, therefore a middleware is a realization of an architecture style. However, mobility has created additional complexity for computation and coordination. This makes the current architectural approaches and techniques hard to use [10]. The current architectural approaches have been designed for traditional distributed systems without consideration of mobility. They o.er only a logical view of change; they do not take into account the properties of the “physical” distribution topology of locations and communications. It relies on the assumption that the computation performed by individual components is irrelative to location of the component, and that coordination mechanisms through connectors can be always transmitted successfully by the underlying communication network. In order to support mobility, the architectural and modeling approach needs to be adjusted.
1.3 Objectives of the book The overall objective of the book is to develop an approach to help the design and development of middleware for mobile systems. Following the basic idea of the architecture centric development (Fig. 1.3), we will propose an approach that supports style-based modeling, re.nement, and formal analysis (Fig. 1.4). The modeling language In order to help to understand complex problems and solutions, the modeling language (Fig. 1.4) should capture the main aspects of the middleware. It should consider and model mobility explicitly, which includes two aspects: the architectural elements related to mobility, and how computation and coordination are in.uenced by mobility. The models should be represented in an easy understandable form, at the same time be clear and unambiguous, in order to truly help to understand
Platform Independent Level Platform Specific Level Conceptual
Architectural Style <>
<> Modeling Language
Concrete <> Architectural Style
the middleware, and enable easy and unambiguous communication about the middleware among di.erent designers, developers and other stakeholders. The architectural style The approach should support the modeling of architectural styles (Fig. 1.4) for the middleware, in order to solve the problems brought by diversity and unpredictability in the middleware area, enhance reusability and quality of the software, and simplify the development process. We will explore the speci.cation of architectural styles, to see how we can build a common form of design, how to capture the already established design knowledge or successful experience for a class of related middleware.
1.3 Objectives of the book When building new middleware, the designers and developers can de.ne the middleware design as instances of a speci.c style, or they can use the style as a reference model for further improvement and development. This will make the design process quite e.cient and predictable. Model-based analysis The approach should support model-based ana-lysis. The approach is intended to model large, complex software system-middleware for mobile systems. The ability to evaluate and analyze the properties of such systems upstream, at an architectural level, can ensure the quality of the developed system in the speci.cation process, and hence sub-stantially lessening the cost of errors. Especially, automation and tool support of the analysis can help a lot since the speci.cation is often complicatedly constructed and thus di.cult to be checked manually. Re.nement The approach should support a stepwise re.nement, which is generally required by a complex system in order to decrease complexity. The designers can start from a simpler, easier design, come to a more and more concrete, complete design through re.nements. In the re.nement process, it is di.cult to ensure that the concrete speci.cation is a correct re.nement of the more abstract one. Especially, the correctness of the newly added architectural elements is di.cult to be checked since it is not easy to directly map them to the abstract ones. Therefore, re.nement correctness criteria should be provided to guarantee the correctness of a re.ned concrete speci.cation. Besides, it is very helpful to have tool support and automation of the re.nement process, since it is normally a complex task. Consistency check One important issue of a model-based approach is to correctly bridge the gap between abstract models and concrete models, or even implementations. However, to validate whether a concrete model or an implementation is a correct re.nement of an abstract model is usually di.cult and complicated. The approach should provide a method to support the validation process between di.erent abstraction layers. This is also important to prevent architectural decay, which is usually gradual divergence between an abstract model and a concrete model, or an implementation. Again, tool support and automation of the validation process are important.
1.4 Our approach Correspondingly, we develop an approach based on UML-like meta models and graph transformation techniques to support sound methodological principles, powerful modeling, formal analysis and re.nement. In detail, we can divide the approach into .ve main parts: Requirements analysis The very .rst step of an architecture-centric approach is to characterize the problem domain, conclude the main charac-teristics and aspects to be modeled. Understanding the problem domains and their properties is a key to better understanding the needs of software architectures, architecture-based development, and architectural description. We develop a conceptual framework for understanding and comparing the di.erent approaches, which is abstracted from speci.c implementation details and summarizes the main characteristics of the middleware. The generaliza-tion enables us to compare di.erent approaches from a same point of view, and observe similarities and common aspects from the great diversities of the middleware. This builds a basis for constructing the architectural style of the middleware, which should originate from the results that practitioners have achieved in the area. The modeling language The modeling language is based on the Graph Transformation Systems (GTSs) and UML-like metamodeling technique. We exploit the GTS for specifying the architectural style of the middleware for mobile systems, which includes the speci.cation of mobility related elements. Visual representation and formal semantics are the main advantages of the modeling language. It has not only a graphic, easy understandable syntax, but also an operational semantics. It supports rich modeling techniques, such as separation of concerns, re.nement, adaptability, extensibility, etc. It can describe complex structures and systems, and model concepts and ideas in a direct and intuitive way. At the same time, the formal semantics allows execution, analysis, transformation, automation and tool support. The architectural style The great diversity of the middleware for mobile systems makes it quite di.cult to build architectural styles for the middleware. It is di.cult to explore commonalities across the middleware families. We observe that the middleware presents some commonalities
评论
还没有评论。