![This ebook is for the use of anyone anywhere in the United States
and most other parts of the world at no cost and with almost no
restrictions whatsoever. You may copy it, give it away or re-use it
under the terms of the Project Gutenberg License included with this
ebook or online at www.gutenberg.org. If you are not located in the
United States, you will have to check the laws of the country where
you are located before using this eBook.
Title: Lost Diaries
Author: Maurice Baring
Release date: April 15, 2013 [eBook #42542]
Most recently updated: October 23, 2024
Language: English
Credits: Produced by Marc D'Hooghe (Images generously made
available by the Internet Archive - University of California)
*** START OF THE PROJECT GUTENBERG EBOOK LOST DIARIES
***](https://image.slidesharecdn.com/2344352-250525214008-f5ad673b/85/Nonfunctional-Properties-In-Service-Oriented-Architecture-Requirements-Models-And-Methods-Nikola-Milanovic-60-320.jpg)
Nonfunctional Properties In Service Oriented Architecture Requirements Models And Methods Nikola Milanovic
- 1. Nonfunctional Properties In Service Oriented Architecture Requirements Models And Methods Nikola Milanovic download https://ebookbell.com/product/nonfunctional-properties-in- service-oriented-architecture-requirements-models-and-methods- nikola-milanovic-4688704 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Nonconventional Functional Block Copolymers Editors Patrick Theato1 https://ebookbell.com/product/nonconventional-functional-block- copolymers-editors-patrick-theato1-2343936 Quantum Functional Analysis Noncoordinate Approach 1st A Y Helemskii https://ebookbell.com/product/quantum-functional-analysis- noncoordinate-approach-1st-a-y-helemskii-5250824 Functional Analysis Of Long Noncoding Rnas Methods And Protocols 1st Ed Haiming Cao https://ebookbell.com/product/functional-analysis-of-long-noncoding- rnas-methods-and-protocols-1st-ed-haiming-cao-22417394 Functional Reverse Engineering Of Strategic And Nonstrategic Machine Tools Computers In Engineering Design And Manufacturing 1st Edition Wasim Ahmed Khan https://ebookbell.com/product/functional-reverse-engineering-of- strategic-and-nonstrategic-machine-tools-computers-in-engineering- design-and-manufacturing-1st-edition-wasim-ahmed-khan-32624802
- 3. Functional Foods And Nutraceuticals In Metabolic And Noncommunicable Diseases 1st Edition Ram B Singh Editor https://ebookbell.com/product/functional-foods-and-nutraceuticals-in- metabolic-and-noncommunicable-diseases-1st-edition-ram-b-singh- editor-37051958 Functional Analysis And Applied Optimization In Banach Spaces Applications To Nonconvex Variational Models 1st Edition Fabio Botelho Auth https://ebookbell.com/product/functional-analysis-and-applied- optimization-in-banach-spaces-applications-to-nonconvex-variational- models-1st-edition-fabio-botelho-auth-4930758 Advances In Nonarchimedean Analysis 11th International Conference Padic Functional Analysis July 59 2010 Universite Blaise Pascal Clermontferrand France Jesus Araujogomez https://ebookbell.com/product/advances-in-nonarchimedean- analysis-11th-international-conference-padic-functional-analysis- july-59-2010-universite-blaise-pascal-clermontferrand-france-jesus- araujogomez-4765234 Nonlinear Optical Response In Atoms Molecules And Clusters An Explicit Time Dependent Density Functional Approach 1st Edition Vladimir Goncharov Auth https://ebookbell.com/product/nonlinear-optical-response-in-atoms- molecules-and-clusters-an-explicit-time-dependent-density-functional- approach-1st-edition-vladimir-goncharov-auth-4931624 Advances In Nonarchimedean Analysis 13th International Conference Padic Functional Analysis August 1216 2014 University Of Paderborn Paderborn Germany Helge Glockner https://ebookbell.com/product/advances-in-nonarchimedean- analysis-13th-international-conference-padic-functional-analysis- august-1216-2014-university-of-paderborn-paderborn-germany-helge- glockner-6703818
- 5. Non-Functional Properties in Service Oriented Architecture: Requirements, Models and Methods Nikola Milanovic Model Labs - Berlin, Germany Hershey • New York INFORMATION SCIENCE REFERENCE
- 6. Senior Editorial Director: Kristin Klinger Director of Book Publications: Julia Mosemann Editorial Director: Lindsay Johnston Acquisitions Editor: Erika Carter Development Editor: Joel Gamon Production Coordinator: Jamie Snavely Typesetters: Keith Glazewski & Natalie Pronio Cover Design: Nick Newcomer Published in the United States of America by Information Science Reference (an imprint of IGI Global) 701 E. Chocolate Avenue Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: cust@igi-global.com Web site: http://www.igi-global.com Copyright © 2011 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or com- panies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark. Library of Congress Cataloging-in-Publication Data Non-functional properties in service oriented architecture : requirements, models, and methods / Nikola Milanovic, editor. p. cm. Includes bibliographical references and index. Summary: "This book offers a selection of chapters that cover three important aspects related to the use of non-functional properties in SOA: requirements specification with respect to non-functional properties, modeling non-functional properties and implementation of non-functional properties"-- Provided by publisher. ISBN 978-1-60566-794-2 (hardcover) -- ISBN 978-1-60566-795-9 (ebook) 1. Service-oriented architecture (Computer science) 2. Non-functional requirements (Systems engineering) I. Milanovic, Nikola. TK5105.5828.N66 2011 004.6'54--dc22 2010033600 British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher.
- 7. Editorial Advisory Board Daniel Amyot, University of Ottawa, Canada Samik Basu, Iowa State University, USA Marko Bošković, University of Oldenburg, Germany Lawrence Chung, University of Texas, USA Jörg Dörr, Fraunhofer Institute for Experimental Software Engineering, Germany Kazi Farooqui, AT&T Labs, USA Dragan Gašević, Athabasca University, Canada Aniruddha S. Gokhale, Vanderbilt University, USA Jeff Gray, University of Alabama at Birmingham, USA Fuyuki Ishikawa, National Institute of Informatics, Japan Jan Jürjens, The Open University, UK Dimitris Karagiannis, University of Vienna, Austria Nikola Milanovic, Berlin University of Technology, Germany Katsuya Oba, OGIS International, Inc., USA Michael Papazoglou, Tilburg University, The Netherlands Claudia Raibulet, University of Milan, Italy Michiaki Tatsubori, IBM Research - Tokyo Research Laboratory, Japan Marcel Tilly, European Microsoft Innovation Center, Germany Changzhou Wang, Boeing Phantom Works, USA Eric Yu, University of Toronto, Canada List of Reviewers Roberto E. Lopez-Herrejon, University of Oxford, UK Vander Alves, Fraunhofer Institute for Experimental Software Engineering, Germany Christa Schwanninger, Siemens AG, Germany Rob van Ommering, Philips Research, The Netherlands Katerina Goseva-Popstojanova, West Virginia University, USA Mei-Hwa Chen, State University of New York at Albany, USA Bratislav Milic, Humboldt University, Germany Vladimir Stantchev, Berlin University of Technology, Germany
- 8. Foreword . ............................................................................................................................................xiv Preface . ................................................................................................................................................xvi Section 1 Requirement Specification in SOA Chapter 1 Tracing the Implementation of Non-Functional Requirements .............................................................. 1 Stephan Bode, Ilmenau University of Technology, Germany Matthias Riebisch, Ilmenau University of Technology, Germany Chapter 2 Developing Non-Functional Requirements for a Service-Oriented Application Platform: A Goal and Scenario-Oriented Approach.............................................................................................. 24 Daniel Gross, University of Toronto, Canada Eric Yu, University of Toronto, Canada Xiping Song, Siemens Corporate Research, USA Chapter 3 Modeling and Analyzing Non-Functional Requirements in Service Oriented Architecture with the User Requirements Notation.................................................................................................... 48 Hanane Becha, University of Ottawa, Canada Gunter Mussbacher, University of Ottawa, Canada Daniel Amyot, University of Ottawa, Canada Chapter 4 A Security Requirements Engineering Tool for Domain Engineering in Software Product Lines. ....... 73 Jesús Rodríguez, University of Castilla – La Mancha, Spain Eduardo Fernández-Medina, University of Castilla – La Mancha, Spain Mario Piattini, University of Castilla – La Mancha, Spain Daniel Mellado, National Competition Commission, Spain Table of Contents
- 9. Section 2 Modeling Non-Functional Properties in SOA Chapter 5 A Look on Engineering Non-Functional Properties in Service Oriented Architectures........................ 94 Nicolò Perino, University of Lugano, Switzerland Marco Massarelli, Universitá degli Studi di Milano-Bicocca, Italy Daniele Cammareri, Universitá degli Studi di Milano-Bicocca, Italy Claudia Raibulet, Universitá degli Studi di Milano-Bicocca, Italy Francesca Arcelli, Universitá degli Studi di Milano-Bicocca, Italy Chapter 6 A Goal-Oriented Representation of Service-Oriented Software Design Principles............................ 120 Alireza Moayerzadeh, University of Toronto, Canada Eric Yu, University of Toronto, Canada Chapter 7 Model-Driven Engineering of Non-Functional Properties for Pervasive Service Creation................ 145 Achilleas Achilleos, University of Cyprus, Cyprus Kun Yang, University of Essex, UK Nektarios Georgalas, Centre of Information and Security Systems Research, UK Chapter 8 Relational Service Quality Modeling. .................................................................................................. 172 Vladimir A. Shekhovtsov, National Technical University “Kharkiv Polytechnic Institute”, Ukraine Roland Kaschek, Information Science Research Center, New Zealand Christian Kop, Alpen-Adria-Universität Klagenfurt, Austria Heinrich C. Mayr, Alpen-Adria-Universität Klagenfurt, Austria Chapter 9 Model-Driven Development of Non-Functional Properties in Web Services: An Aspect-Oriented Approach............................................................................................................. 194 Guadalupe Ortiz, University of Extremadura, Spain Juan Hernández, University of Extremadura, Spain Chapter 10 A Unified Deployment and Management Model for Dynamic and Distributed Software Architectures........................................................................................................................................ 217 Mohamed Nadhmi Miladi, Université de Sfax, Tunisia Mariam Lahami, Université de Sfax, Tunisia Mohamed Jmaeil, Université de Sfax, Tunisia Khalil Drira, Université de Toulouse, France
- 10. Section 3 Methods for Implementing Non-Functional Properties in SOA Chapter 11 An Aspect-Oriented Framework to Model Non-Functional Requirements in Software Product Lines of Service-Oriented Architectures................................................................................ 246 Germán Harvey Alférez Salinas, Universidad de Montemorelos, Mexico Edward Mauricio Alférez Salinas, Universidade Nova de Lisboa, Portugal Chapter 12 Model-Driven Approach for End-to-End SOA Security Configurations............................................. 268 Fumiko Satoh, IBM Research – Tokyo, Japan Yuichi Nakamura, IBM Research – Tokyo, Japan Nirmal K. Mukhi, IBM Research – Thomas J. Watson Research Center, USA Michiaki Tatsubori, IBM Research – Tokyo, Japan Kouichi Ono, IBM Research – Tokyo, Japan Chapter 13 Control Engineering for Scaling Service Oriented Architectures........................................................ 299 Yixin Diao, IBM, USA Joseph L. Hellerstein, Google, USA Sujay Parekh, IBM, USA Chapter 14 Addressing Non-Functional Properties of Services in IT Service Management................................. 324 Vladimir Stantchev, Berlin Institute of Technology & FOM Hochschule für Ökonomie und Management, Germany Gerrit Tamm, Humboldt-University at Berlin, Germany Chapter 15 Functional and QoS Semantics-Driven SOA-Based Biomedical Multimedia Processing.................. 335 Shih-Hsi Liu, California State University – Fresno, USA Yu Cao, California State University – Fresno, USA Ming Li, California State University – Fresno, USA Thell Smith, California State University – Fresno, USA John Harris, California State University – Fresno, USA Jie Bao, Rensselaer Polytechnic Institute, USA Barrett R. Bryant, University of Alabama at Birmingham, USA Jeff Gray, University of Alabama at Birmingham, USA
- 11. Compilation of References ............................................................................................................... 360 About the Contributors .................................................................................................................... 387 Index.................................................................................................................................................... 399
- 12. Foreword . ............................................................................................................................................xiv Preface . ................................................................................................................................................xvi Section 1 Requirement Specification in SOA Chapter 1 Tracing the Implementation of Non-Functional Requirements .............................................................. 1 Stephan Bode, Ilmenau University of Technology, Germany Matthias Riebisch, Ilmenau University of Technology, Germany Bode and Riebisch present a novel architectural design method supporting specification of non-func- tional requirements in the design phase and, more importantly, traceability: mapping of requirements to software solutions. In that way, not only specification, but also implementation of non-functional prop- erties is architecturally supported. The case study is presented where a manufacturing execution system has been reengineered to SOA and integrated with an ERP system using this methodology. Chapter 2 Developing Non-Functional Requirements for a Service-Oriented Application Platform: A Goal and Scenario-Oriented Approach.............................................................................................. 24 Daniel Gross, University of Toronto, Canada Eric Yu, University of Toronto, Canada Xiping Song, Siemens Corporate Research, USA Gross, Yu, and Song argue that the true challenge of modeling non-functional properties is how to support them in different platforms or application domains. For that purpose the authors present a platform and a development method supporting goal and scenario oriented modeling and analysis of non-functional properties. Special attention is given to such variations as domains specific meaning of non-functional properties, different terminologies, load and configuration settings. Detailed Table of Contents
- 13. Chapter 3 Modeling and Analyzing Non-Functional Requirements in Service Oriented Architecture with the User Requirements Notation.................................................................................................... 48 Hanane Becha, University of Ottawa, Canada Gunter Mussbacher, University of Ottawa, Canada Daniel Amyot, University of Ottawa, Canada Becha, Mussbacher, and Amyot present an aspect-oriented approach for analyzing non-functional re- quirements in SOA applications. They describe how to apply User Requirements Notation (URN) to- gether with aspect-oriented extensions for that purpose. The proposed notation enables quantitative specification of non-functional properties and thus provides the foundation for service discovery, selec- tion, and composition. In the accompanying case study, cost, response time, reliability, and availability are the non-functional properties which are explicitly illustrated. Chapter 4 A Security Requirements Engineering Tool for Domain Engineering in Software Product Lines. ....... 73 Jesús Rodríguez, University of Castilla – La Mancha, Spain Eduardo Fernández-Medina, University of Castilla – La Mancha, Spain Mario Piattini, University of Castilla – La Mancha, Spain Daniel Mellado, National Competition Commission, Spain Rodríguez et al. present a novel tool for capturing security requirements in software product lines. It facilitates management of complex security requirements by providing the possibility to specify those requirements in the early development stage, manage and visualize them, as well as enable variability and traceability in the implementation phase. Furthermore, the tool can integrate existing security stan- dards. Section 2 Modeling Non-Functional Properties in SOA Chapter 5 A Look on Engineering Non-Functional Properties in Service Oriented Architectures........................ 94 Nicolò Perino, University of Lugano, Switzerland Marco Massarelli, Universitá degli Studi di Milano-Bicocca, Italy Daniele Cammareri, Universitá degli Studi di Milano-Bicocca, Italy Claudia Raibulet, Universitá degli Studi di Milano-Bicocca, Italy Francesca Arcelli, Universitá degli Studi di Milano-Bicocca, Italy Perino et al. provide an overview of non-functional properties in SOA. The authors propose the basic set of non-functional properties (policy, security, transaction, and management), each with the corre- sponding set of attributes. The main challenges are then discussed, such as modeling, dependencies and conflicts, management through Service Level Agreements, and service compositions. Finally, future trends and promising approaches for modeling non-functional properties in SOA are presented.
- 14. Chapter 6 A Goal-Oriented Representation of Service-Oriented Software Design Principles............................ 120 Alireza Moayerzadeh, University of Toronto, Canada Eric Yu, University of Toronto, Canada Moayerzadeh and Yu argue that although widely used, basic SOA principles such as abstraction, dis- coverability, reusability, and composability are rarely collected and systematically organized. They propose a goal-graph representation of SOA principles which can be used in system design. Non-func- tional properties are automatically extracted from the text-based description (knowledge base) and then formalized. Goal-graphs thus obtained can be then used in different phases of system design. Chapter 7 Model-Driven Engineering of Non-Functional Properties for Pervasive Service Creation................ 145 Achilleas Achilleos, University of Cyprus, Cyprus Kun Yang, University of Essex, UK Nektarios Georgalas, Centre of Information and Security Systems Research, UK Achilleos, Yang and Georgalas describe a model-based framework for engineering non-functional properties in the context of pervasive service creation. High dynamicity of pervasive services requires new approaches for their specification, development, and management. The authors propose a context modeling language which can be used to generate platform independent context models describing non-functional properties. These models are then transformed into platform specific source code. The approach is illustrated with a case study showing all steps of this process, from the context model defi- nition to code generation. Chapter 8 Relational Service Quality Modeling. .................................................................................................. 172 Vladimir A. Shekhovtsov, National Technical University “Kharkiv Polytechnic Institute”, Ukraine Roland Kaschek, Information Science Research Center, New Zealand Christian Kop, Alpen-Adria-Universität Klagenfurt, Austria Heinrich C. Mayr, Alpen-Adria-Universität Klagenfurt, Austria Shekhovtsov et al. present an approach of using non-first-normal-form tables for modeling quality of service in SOA. They argue that it is very suitable for communicating application design issues to stakeholders with the business background. They show how to use such tables as an intermediate step between requirements specification and system design to define functional and quality requirements of services and business processes (service orchestrations). Chapter 9 Model-Driven Development of Non-Functional Properties in Web Services: An Aspect-Oriented Approach............................................................................................................. 194 Guadalupe Ortiz, University of Extremadura, Spain Juan Hernández, University of Extremadura, Spain
- 15. Ortiz and Hernández argue that combining model-driven and aspect-oriented methods provides a useful foundation for development of high-quality SOA systems. The authors provide a method for integrating non-functional properties into SOA model-driven development process using aspect-oriented methods, thus separating non-functional properties from the code. They demonstrate how application of this method increases modularity and reduces implementation and maintenance complexity. Chapter 10 A Unified Deployment and Management Model for Dynamic and Distributed Software Architectures........................................................................................................................................ 217 Mohamed Nadhmi Miladi, Université de Sfax, Tunisia Mariam Lahami, Université de Sfax, Tunisia Mohamed Jmaeil, Université de Sfax, Tunisia Khalil Drira, Université de Toulouse, France Miladi et al. address the problem of dynamic deployment for services that need to adapt their behavior based on the changes in requirements or context. The authors propose a generic model called unified deployment and management model of distributed software architectures. It is described how to use this model to enable dynamic deployment in both SOA and traditional component-based applications. Section 3 Methods for Implementing Non-Functional Properties in SOA Chapter 11 An Aspect-Oriented Framework to Model Non-Functional Requirements in Software Product Lines of Service-Oriented Architectures................................................................................ 246 Germán Harvey Alférez Salinas, Universidad de Montemorelos, Mexico Edward Mauricio Alférez Salinas, Universidade Nova de Lisboa, Portugal Salinas and Salinas describe non-functional properties as the major complexity factor in software prod- uct lines (SPL) of SOA, as they are difficult to manage being found in many contexts with varying concerns and crosscut multiple concerns across the entire lifecycle. Furthermore, existing variability methods concentrate on functional properties only. The authors present and apply an extended version of an aspect-oriented framework for SPLs that exploits aspect-oriented software development tech- niques in order to model variability of NFRs in SPLs of SOAs from early development stages. Chapter 12 Model-Driven Approach for End-to-End SOA Security Configurations............................................. 268 Fumiko Satoh, IBM Research – Tokyo, Japan Yuichi Nakamura, IBM Research – Tokyo, Japan Nirmal K. Mukhi, IBM Research – Thomas J. Watson Research Center, USA Michiaki Tatsubori, IBM Research – Tokyo, Japan Kouichi Ono, IBM Research – Tokyo, Japan
- 16. Satoh et al. discuss the problem of very late and missing specification of security properties in SOA de- velopment, because of which, developers in the downstream development phases must manage differ- ent security requirements and configurations ad-hoc and manually. The authors then propose a model- driven process which can be extended to multiple specification and development phases for definition of various security properties, such as business security requirements or platform security properties. Finally, a model-driven tool for security configuration, implementing the proposed methodology, is described and demonstrated. Chapter 13 Control Engineering for Scaling Service Oriented Architectures........................................................ 299 Yixin Diao, IBM, USA Joseph L. Hellerstein, Google, USA Sujay Parekh, IBM, USA Diao, Hellerstein and Parekh discuss scalability of SOA applications. They argue that scaling SOA ap- plications requires a systematic approach to resource management to achieve service level objectives (SLO). They propose a methodology for scaling SOAs based on the control engineering theory and demonstrate the benefits achieved in an industrial setting. Chapter 14 Addressing Non-Functional Properties of Services in IT Service Management................................. 324 Vladimir Stantchev, Berlin Institute of Technology & FOM Hochschule für Ökonomie und Management, Germany Gerrit Tamm, Humboldt-University at Berlin, Germany Stantchev and Tamm argue that, with massively distributed architectures becoming more prevalent, the assurance of availability and dependability for distributed applications becomes an even more chal- lenging and nontrivial task. The authors describe an approach for addressing non-functional properties in SOA based on reference models such as ITIL and the SOA life cycle model, which has been already applied in several industrial setting in the telecommunications sector. Chapter 15 Functional and QoS Semantics-Driven SOA-Based Biomedical Multimedia Processing.................. 335 Shih-Hsi Liu, California State University – Fresno, USA Yu Cao, California State University – Fresno, USA Ming Li, California State University – Fresno, USA Thell Smith, California State University – Fresno, USA John Harris, California State University – Fresno, USA Jie Bao, Rensselaer Polytechnic Institute, USA Barrett R. Bryant, University of Alabama at Birmingham, USA Jeff Gray, University of Alabama at Birmingham, USA
- 17. Liu et al. provide an illustrative case study of applying functional and QoS properties in the field of SOA-based biomedical multimedia processing applications. They adapt the concepts of requirements elicitation of Software Engineering as well as a training set of machine learning to analyze functional and QoS properties of biomedical multimedia data. Two medical education projects are introduced as case studies to illustrate the usage of functional and QoS semantics extracted to improve the perfor- mance of subsequent classification and search. Compilation of References ............................................................................................................... 360 About the Contributors .................................................................................................................... 387 Index.................................................................................................................................................... 399
- 18. xiv Foreword Computingserviceshaveevolvedfromtheirerstwhileemphasisofspecificfunctionalitieswithdedicated implementation schemas and on dedicated platforms. As computing has expanded to wide scale growth of applications, platforms and service requirements, these have entailed an increasing sophistication of operations and correspondingly increasing complexity of the (software) realization. Subsequently with current Web scale systems, the needs for adaptable and scalable services and also the progression to non-specific platforms/technologies has only added to the complexity of realizing computing services. As classical computing paradigms face limitations to handle complexity, the concepts of service oriented architectures (SOA) offer architectural approaches towards simplification of complex software designs by advocating modular building blocks for services that could be interconnected to realize the desired (complex) services. Consequently, SOA offers a fundamentally richer abstraction of specifying service functionality sans a mandated implementation. This decoupling of services from dedicated implementa- tions has helped evolve the modular and composable Web model of interactions, and also offers devel- opers diverse implementation choices of (interoperable) programming languages and implementation components. The popularity of the cloud computing model is a natural progression both building upon and supporting the SOA paradigms. While the SOAconcepts provide the essence of “service on demand” across the service providers and serviceconsumers,therealizedvalueofSOAgetsenhancedwhenthecontractedservicesalsoincorporate extra-functional properties. These include services delivered in a secure, reliable and timely manner, transparent to the occurrence of component coupling, transparent to the occurrence of perturbations, and of a granularity matching the service needs and similarly related service quality attributes. It is this group of “extra-functional” or “non-functional” SOA features that significantly determines the actual value of an SOA approach. At the same time, the provisioning of these non-functional attributes is not easy. SOA obtains its core value from an “open system” design philosophy that includes facets of modularity, evolving composition via loose coupling of functional blocks, variety of programming schema, lack of embedding of calls across modules, among other aspects. On the other hand, the provisioning of non- functional attributes such as dependability or security or timeliness attributes work best with a complete systems view, having a well structured (and controlled) operational structure and usage of specifically advocated implementation mechanisms. Unfortunately this is also often counter to the SOA approaches making the integration of non-functional aspects in SOA to be non-trivial. WhilethereexistsanabundanceofSOAdesignapproaches,thiskeyconsiderationof“non-functional” attributes is often conspicuous by its absence. It is this explicit and dedicated coverage of “non-functional aspects in SOA” that distinguishes this book. Its systematic coverage of the requirements, models and approaches help set proper foundations to addressing non-functional attributes in SOA. I applaud Nikola
- 19. xv Milanovic for his exemplary initiative in addressing this hard, but much needed SOA challenge area. I am positive that the readers will find the book to offer a high value, high impact exposition of SOA. Neeraj Suri TU Darmstadt, Germany Neeraj Suri received his PhD from the University of Massachusetts at Amherst. He currently holds the TU Darmstadt Chair Professorship in “Dependable Embedded Systems and Software” at TU Darmstadt, Germany. His earlier appointments include theSaabEndowedProfessorship,facultyatBostonUniversityandsabbaticalatMicrosoftResearch.Hisresearchinterestsfocus on design, analysis and assessment of distributed-dependable systems and software. His research emphasizes composite issues of dependability and security for SW/OS, verification/validation of protocols and especially “trusted/secure systems by design”. His group’s research activities have garnered support from the European Commission, NSF, DARPA, ONR, Microsoft, Hitachi, IBM, NASA, Boeing, Saab, Volvo, SSF, Vinnova, and Daimler Chrysler among others. He is also a recipient of the NSF CAREER award and the 2008 IBM Faculty Award. Suri serves as the associate Editor in Chief for IEEE Transactions on Dependable and Secure Computing, on the editorial boards for: IEEE Transactions for Software Engineering, ACM Computing Surveys, Journal of Security and Networks, and has been an editor for the IEEE Transactions on Parallel and Distributed Systems. He is a member of IFIP WG 10.4 on Dependability, and a member of Microsoft’s Trustworthy Computing Academic Advisory Board. More professional details are available at: http://www.deeds.informatik.tudarmstadt.de/suri/activities/activities.html.
- 20. xvi Preface Service Oriented Architecture (SOA) is the paradigm for software and system specification, design, implementation and management, that pretends to shape and dominate IT and business landscapes in the near future. SOA has departed from the initial hype phase and ceased to be a simple buzzword long time ago, while entering a relatively mature phase with numerous companies offering SOA products and services. The scientific community has kept apace and continues to explore creative and inspiring approaches at an astonishing pace that further enrich this approach. SOAinitially promised and also thereafter successfully delivered several basic functionalities:unified and standardized description, discovery, communication, and binding of autonomous and self contained software entities, called services, at an unprecedented scale. They have furthermore enabled dynamic and complex enterprise interactions, previously unthinkable or commercially unattainable, and at the global level. However, very soon it also became clear that functional interoperability offered by the first genera- tion of SOA standards and products failed to satisfy several important requirements, such as efficient discoveryandmatchingofbusinessand/ortechnicalrequirementsbetweenservicerequestorsandservice providers. The increasing number of offered services further exacerbated this problem: it was not clear how to choose adequate interaction partners (services) among many of them offering approximately “the same” functionality; how to select optimal partners according to a given criteria or their combination (e.g., price or performance); or how to be able to specify “soft” or “non-functional” requirements on the requestor side and match them with provided properties on the service side. In other words, the issues of specifying a whole range of properties orthogonal to pure functional description (what the service should do) remained generally unaddressed. Parallel to these developments, the decade-old idea of a component marketplace was brought to life once again as the service marketplace under the umbrella of emerging SOA standards. Here also, very soon it was only too clear that matching and searching for composition partners or building an application based on third party services depends heavily on many other properties beside the pure functional ones. The properties which are orthogonal to functional properties (what is the service doing) and de- scribe the nature, mechanism, or context of the service execution (how and under which conditions is the service doing), have been given different names in different disciplines and by different people, including “non-functional properties”, “extra-functional properties”, “quality of service properties” or “service level agreement properties.” In this book, the term non-functional properties will be mostly used, although other designations may also appear. Notable examples of non-functional properties are security, reliability, availability, timeliness, location, price, performance, et cetera.
- 21. xvii This book offers a selection of chapters that cover three important aspects related to the use of non- functional properties in SOA: requirements specification with respect to non-functional properties, modeling non-functional properties, and implementation of non-functional properties. Each software project begins with requirements specification phase. Hidden, unspecified require- ments present a constant source of errors, frustrations, and costly workarounds required to fix them. This problem is further exacerbated in heterogeneous and dynamic SOA environment, where frequent changes of processes and technologies dictate adaptive and tool supported requirement specification. In the first section of the book, four approaches for capturing non-functional requirements in SOA will be presented. They build a foundation for successful modeling and execution of complex SOA projects. In Chapter 1, Bode and Riebisch present a novel architectural design method supporting specification of non-functional requirements in the design phase and, more importantly, traceability: mapping of require- ments to software solutions. Gross, Yu, and Song argue in Chapter 2 that the true challenge of modeling non-functional requirements is how to support them in different platforms or application domains. For that purpose the authors present a platform and a development method supporting goal and scenario oriented modeling and analysis of non-functional requirements. In Chapter 3, Becha, Mussbacher, and Amyot present an aspect-oriented approach for analyzing non-functional requirements in SOA applica- tions. Finally in Chapter 4 Rodríguez et al. describe a novel tool for capturing security requirements in software product lines. Modeling non-functional properties is the critical step for achieving successful realization of com- plex SOA projects. Issues of reliability, availability, security, or quality of service are often subsumed under the general term of Service Level Agreements (SLA). The second section of the book discusses approaches for formal and tool supported modeling of SLAs containing non-functional properties. In Chapter 5, Perino et al. provide an overview of non-functional properties in SOA. The authors propose the basic set of non-functional properties (policy, security, transaction and management), each with the corresponding set of attributes. Moayerzadeh andYu argue in Chapter 6 that although widely used, basic SOA principles such as abstraction, discoverability, reusability, and composability are rarely collected and systematically organized. They propose a goal-graph representation of SOAprinciples which can be used in system design. In Chapter 7,Achilleos, Yang, and Georgalas describe a model-based framework for engineering non-functional properties in the context of pervasive service creation. Shekhovtsov et al. present in Chapter 8 an approach of using non-first-normal-form tables for modeling quality of service in SOA. They argue that it is very suitable for communicating application design issues to stakeholders with the business background. Ortiz and Hernández argue in Chapter 9 that the combination of model- driven and aspect-oriented methods provides useful foundation for development of high-quality SOA systems. The authors propose a method for integrating non-functional properties into SOAmodel-driven development process using aspect-oriented methods. The final, third section of the book discusses practical application of methods for implementing non-functional properties in SOA environments. Methods such as aspect oriented programming (AOP), model driven architecture (MDA) or control theory are presented and applied to diverse properties (e.g., security) in various domains (e.g., biomedicine). In Chapter 11 Salinas and Salinas present and apply an extended version of an aspect-oriented framework for software product lines that exploits aspect- oriented software development techniques in order to model variability of non-functional properties in SOA from early development stages. Satoh et al. discuss in Chapter 12 the problem of very late and missing specification of security properties in SOA development, because of which developers in the downstream development phases must manage different security requirements and configurations ad-
- 22. xviii hoc and manually. The authors then propose a model-driven process which can be extended to multiple specification and development phases for definition of various security properties, such as business se- curity requirements or platform security properties. In Chapter 13 Diao, Hellerstein and Parekh explore scalability of SOA applications. They propose a methodology for scaling SOAs based on the control engineering theory and demonstrate the benefits achieved in an industrial setting. Stantchev and Tamm argue in Chapter 14 that, with massively distributed architectures becoming more prevalent, the assur- ance of availability and dependability for distributed applications becomes an even more challenging and nontrivial task. The authors describe an approach for addressing non-functional properties in SOA based on reference models such as ITIL and the SOA life cycle. Finally, in Chapter 15 Liu et al. provide an illustrative case study of applying functional and QoS properties in the field of SOA-based biomedi- cal multimedia processing applications. The book will thus gradually guide the reader through all steps of SOA application development, starting with requirement specification, over non-functional property modeling, to their implementation. Focusing state-of-the art research results in one place, the book can serve both as a practical reference manual as well as advanced scientific source. Finally, the authors discuss open issues, and propose future exciting questions yet to be explored. Nikola Milanovic Model Labs - Berlin, Germany
- 23. Section 1 Requirement Specification in SOA Each software project begins with requirements specification phase. Hidden, unspecified requirements present a constant source of errors, frustrations and costly workarounds required to fix them. This prob- lem is further exacerbated in heterogeneous and dynamic SOA environment, where frequent changes of processes and technologies dictate adaptive and tool supported requirement specification. In this section four approaches for capturing non-functional requirements in SOA are presented. They build a foundation for successful modeling and execution of complex SOA projects.
- 25. 1 Copyright © 2011, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Chapter 1 DOI: 10.4018/978-1-60566-794-2.ch001 INTRODUCTION Motivation Performance, scalability, flexibility, security and other so-called non-functional requirements or quality properties are crucial for the success of nearly every software project. They bear even more risk than functional requirements, because they can hardly be implemented after making the majordesigndecisions.Thesoftwarearchitecture has to enable these non-functional requirements, because they constitute the decisive factors for its design. Several architectural methods emphasize Stephan Bode Ilmenau University of Technology, Germany Matthias Riebisch Ilmenau University of Technology, Germany Tracing the Implementation of Non-Functional Requirements ABSTRACT A software architecture has to enable the non-functional properties, such as flexibility, scalability, or security, because they constitute the decisive factors for its design. Unfortunately, the methodical sup- port for the implementation of non-functional requirements into software architectures is still weak; solutions are not generally established. Recently, there are only few approaches that actually deal with non-functional requirements during design; even fewer take advantage of traceability, which supports a mapping of requirements to solutions through the development process. Therefore, in this chapter the new architectural design method TraGoSoMa is presented, which supports these issues. The method uses a so-called Goal Solution Scheme, which guides the design activities, supports conflict resolution, decision-making, and the classification of solutions. For illustration purposes the chapter uses a case study from a reengineering project for a Manufacturing Execution System (MES) that is restructured according to the SOA principles and integrated with an Enterprise Resource Planning (ERP) system.
- 26. 2 Tracing the Implementation of Non-Functional Requirements theanalysisofnon-functionalrequirements(Hof- meister et al., 2000) and the design considering them (Bosch, 2000; Bass et al., 2002). Further- more, in the field of requirements engineering functional and non-functional requirements and their interdependencies are modeled using some mature and established goal-oriented approaches (Chung et al., 2000; Yu, 1995; Amyot, 2003). Therefore, some development steps of require- ments engineering and architectural design are strongly related with each other. However, bridg- ingthegapbetweenthesetworesearchareasisstill acriticalissue(Galsteretal.,2006)especiallyinthe case when non-functional requirements change. Service-oriented architectures are frequently applied for business-critical purposes. For these systems a long life expectancy constitutes an important concern, during which they have to be adjusted to a high number of changes to maintain their operation and their business value. Thus, evolvability is an important issue for this type of systems. Traceability links support changes, and therefore the evolution of software systems, by expressing relations between artifacts in differ- ent phases of software development (Letelier, 2002). They facilitate program comprehension by expressing dependencies explicitly. They relate design decisions to constraints, and they are used to trace dependencies for checking the completeness of changes. These benefits can be achieved from fine-grained traceability links on thelevelofdesignelementsanddesigndecisions. There is a considerable amount of research for managing traceability and for maintaining their accuracy during changes, which is for example discussed in (Mäder et al., 2006). However, the tracing of non-functional requirements usually requires a very high number of links, since typi- cally a high number of a system’s components depend on one such requirement. There are some critical issues that make the whole process complex: for example (a) the map- pingofhigh-levelnon-functionalrequirementsto theirlow-levelsolutionsandmechanisms,aswell as (b) detecting and solving conflicts among non- functionalrequirementsresultingintrade-offs,and further (c) the missing structuredness of existing methodologies or even their complete absence. The management of traceability links, and with them the non-functional properties, requires a high human effort, first because of the high number of links and second because of missing rules inhibiting effective tool support. In order to reduce the effort for establishing, maintaining, and validating the traceability links, our work presents contributions to facilitate tool support, and hence, traceability of non-functional require- ments, in several ways, which are described in the next sections. Challenges The proper treatment of non-functional require- ments is a very important part of architectural design. Unfortunately, the methodical support fortheimplementationofnon-functionalrequire- ments is still lacking even if this book addresses it. The absence of a consolidated set of solutions for non-functional requirements, the abstraction gap between requirements and design as well as the many influencing factors on design deci- sions reduce the applicability of detailed design instructions. Fromthepointofviewofsoftwarearchitectural design there are only few methods that lead to an improved design process by especially consider- ing non-functional requirements: for example the QASAR method (Bosch, 2000) or the Attribute- DrivenDesign(ADD)method(Bassetal.,2002). On the other hand, in requirements engineering there are adequate approaches for dealing with non-functional requirements in a goal-oriented way: for example the NFR framework (Chung et al. 2000), the i* framework (Yu, 1995), or the Goal-oriented Requirement Language (GRL) (Amyot,2003).Althougheffortsaremadetopush these goal-oriented methods towards support for
- 27. 3 Tracing the Implementation of Non-Functional Requirements architectural design, and therefore some overlap- ping in the development steps can be observed, further research has to be done to bridge the gap. Thegoal-orientedtechniquesarevaluablefordeal- ingwiththeinterdependenciesandtherefinement of functional and non-functional requirements, and to some extent are able to map high-level solutions to those goals. However, despite some research on their support for architectural design, (e.g., Grau & Franch, 2007 or Liu & Yu, 2001), on their own they are rather unsuitable and insuf- ficient for the whole architectural design process. Therefore, from our point of view, we have to adjust and integrate these techniques into the softwarearchitecturalmethodologiesandpublish this knowledge to software architects. This will help them as a means for going from the problem space to the solution space and for choosing and evaluating proper architectural solutions espe- cially for non-functional requirements. Asanotheraspect,traceabilitypromisesstrong benefits for the design and evolution of service- orientedarchitecturesandapplicationsespecially iftraceabilitylinksareavailableonafine-grained level. However, this leads to a very high number of traceability links. Thus, the complexity of the link structure and a high overhead effort for its maintenance constitute hampering factors. This holds especially for the traceability of non-func- tional properties, since usually a high number of design elements depend on each non-functional requirement, and this results in a high number of traceability links related to these requirements. The integration and application of the above- mentioned methods provides the potential for an improved traceability. However, the traceabil- ity concepts have to be integrated within these methods, and vice versa the methods have to be adapted to make use of traceability. As a next step after integration, a proper tool support for the management of the traceability links has to be built,coveringtheestablishment,themaintenance, the validation, and the exploitation of the links. Objectives and Contribution InthisworkwepresentthedesignmethodTraGo- SoMa (an acronym for Traceability-driven Goal Solution Mapping) for a proper treatment of non-functional requirements during architectural design. The method is intended to give a better support and guidance for architectural design activitieswhiledealingwithnon-functionalgoals. Itsupportstheconflictresolutionbetweencompet- ing goals and a classification of solutions to the goalstheyarederivedfrom,aswellasasystematic selection based on methodical decision-making. TraGoSoMa clearly is a software architectural designmethod,evenifitpartlyintegratesrequire- ments engineering activities and goal-oriented techniques for modeling non-functional require- ments. With its Goal Solution Scheme as a core concept the method maps non-functional goals andsubgoalstoarchitecturalprinciples,whichare essentialcriteriaforfindingtherightarchitectural design, and it maps them further to the functional and technical solutions. Therefore, it enables an accumulation of architectural know-how. Be- yond, the application of the method facilitates traceability link establishment, and thus, a better maintainability of the software. The method is illustrated in the next sections with the help of a case study. BACKGROUND In this section we briefly investigate the contribu- tionsofstate-of-the-artmethodsfornon-functional design. Therefore, we discuss Bosch’s Quality Attribute-basedSoftwareArchitectural(QASAR) method (Bosch, 2000) and the Attribute-Driven Design (ADD) method (Bass et al. 2002). We express how our approach is influenced by the goal-oriented approaches from requirements engineering,suchastheNon-FunctionalRequire- ments (NFR) framework of Chung et al. (2000) and the i* framework which was introduced by
- 28. 4 Tracing the Implementation of Non-Functional Requirements Yu (1995). Moreover, we relate our traceability framework for non-functional requirements to other works concerning traceability. The Design Method QASAR A frequently performed way of constructing a software architecture for both kinds of require- ments is described by Bosch’s QASAR method (Bosch,2000).QASARconsidersnon-functional requirementsbyarchitecturaltransformations.The method describes three phases. In the first phase, the functional requirements are implemented by functional components with the Functionality- based Architectural Design (FAD) method. FAD usescoreabstractionsoffunctionalconcepts—the so-calledarchetypes—toderivearchitecturalcom- ponents by functional decomposition. In the sec- ondphase,thedevelopedarchitectureisassessedin ordertodecidewhetherthenon-functionalrequire- mentsarefulfilledornot.Differentapproachesfor theassessmentofthenon-functionalrequirements can be used in this phase, e.g., scenario-based evaluation, simulation, mathematical modeling, or objective reasoning. Once the non-functional properties of the architecture are assessed, in the third phase the architecture is transformed to satisfy the non-functional requirements speci- fications. This transformation leads to suitable functional structures and components, which are developed for the implementation of as many as possiblenon-functionalrequirements.Allremain- ingnon-functionalrequirementsareimplemented bychangingallaffectedcomponents.Inthisphase the changes are scattered over the system. We consider QASAR as a very important method of architectural design and we will use its core concept—the fulfilling of non-functional requirements by functional solutions—in our TraGoSoMa method. The drawback of QASAR, the scattered implementation of the remaining non-functionalrequirements,resultsfromitsthird phase. The scattering is accompanied with a de- mand for a very high number of traceability links and hampers maintainability. We want to address this issue in the TraGoSoMa method by a careful consideration of the non-functional properties. Attribute-Driven Design TheADDmethodofBassetal.(2002)isastep-by- step method for designing software architectures. ADD considers non-functional requirements at least as important as functional ones and takes them as input together with other constraints.The non-functionalrequirements,orqualityattributes, have to be specified as quality attribute scenarios before. Then, with ADD the requirements are transformed into a conceptual architecture by a recursive refinement, which is applied in several design steps. First, an architectural element is chosen to be refined, beginning with the system itself. Next, thoserequirementsthatinfluencethearchitecture themosthavetobedetermined.Thesearchitectur- allysignificantrequirements—calledarchitectural drivers—arequality,business,orfunctionalgoals andcanbeidentifiedbyprioritization.Inafurther step, architectural styles and patterns are chosen that satisfy the architectural drivers. In this third step, for the one architectural element that is to be refined and its high-prioritized architectural drivers, the most appropriate solution has to be chosen. The fourth step is about the actual re- finement. The chosen style is instantiated and correspondingarchitecturalelementsarecreated. Thenewelementsareassignedwithfunctionality they are responsible for, and their interfaces are specified for information flow. In the fifth step, the refinement of the child elements is prepared by verifying and refining their requirements descriptions. Finally, all steps are repeated for further decomposition until all architectural driv- ers are fulfilled. ADD, just as QASAR, achieves the fulfill- ing of quality goals by allocating functional components. Its strength is that it concentrates on the most significant architectural drivers for
- 29. 5 Tracing the Implementation of Non-Functional Requirements choosing a proper functional solution utilizing appropriate architectural styles and patterns. We will use this concept in our TraGoSoMa method byprioritizingrequirements.However,ADDalso has its drawbacks. First, the method ends with only a conceptual architecture and no concrete components; hence, the design process has to be continued by other means. Furthermore, ADD does not exactly describe how to identify the architectural drivers. This step is apparently left for the requirements engineer. Additionally, due to its recursive nature, the capability of the ADD method to evaluate alternative solutions for the overall architecture is limited. If an architectural element is refined once and the method continues with the child elements, there is no possibility to consider an alternative for the previous decision. Besides,thereisnothingabouttraceabilitysupport with ADD, which is an important issue we want to address with our TraGoSoMa method. Goal-Oriented Approaches In the field of requirements engineering goal- oriented approaches are a popular way to elicit and model requirements. The Non-Functional Requirements (NFR) framework by Chung et al. (2000) constitutes one of these approaches for dealing with non-functional requirements. The framework uses the concept of so-called softgoals that represent non-functional require- ments. Softgoals are goals that have no clear-cut definition or criteria for their satisfaction. Devel- opment decisions often contribute only partially to or even against these goals within acceptable limits.Becausesoftgoalsareaccomplishedrather partially than completely or not at all, they are considered as fulfilled, and then called satisficed, if an adequate level of the criteria is reached. The interdependencies between softgoals can be categorizedintoseveralcontributiontypesaccord- ing to their weak or strong positive or negative influence on satisfying a softgoal. The NFR framework describes several inter- leaving and iterative activities to arrange soft- goals with their interdependencies in a Softgoal Interdependency Graph. First NFR softgoals are established and refined into subgoals by decom- position. Then, different architectural solutions are developed as so-called operationalizations for the softgoals. Furthermore, softgoals can be refinedbyso-calledargumentations,whichmodel domain characteristics and developers’expertise. Beyond, during the refinement, decisions about the criticality of different goals can be made. Performing these activities, different alternative solutions and corresponding design trade-offs are elaborated in a well-founded way. Implicit interdependencies among softgoals are detected and documented together with design rationale. Alternativesolutionsareevaluatedregardingtheir contribution to the non-functional requirements. Finally, an adequate solution is selected based on the evaluation. Another important goal-oriented method is the i* framework, which was presented by Yu (1995). Akin to the NFR framework, i* uses the notation of goals and softgoals to model system requirements. In addition, it contains further ele- ments,e.g.,tasks,resources,andactors,andituses different types of links, as for example contribu- tion, decomposition, and means-end. Therefore, it can be utilized to not only describe the system’s requirements but also the organizational context. In 2008 the User Requirements Notation (URN)(Amyot,2003)wasapprovedasaninterna- tionalstandardasITU-TRecommendationZ.151. URN consists of the Goal-oriented Requirement Language (GRL), which is based on NFR and i*, and Use Case Maps (UCM), which are used for scenario modeling. GRL as an elaborate notation can be used especially to model non-functional requirements as goals. We consider the described goal-oriented approaches as appropriate means for modeling non-functional requirements. By explicitly con- sidering non-functional requirements right from
- 30. 6 Tracing the Implementation of Non-Functional Requirements thebeginningandprovidingawell-definedevalu- ation process, they can help to design software architectures.Therefore,ourTraGoSoMamethod buildsonthemandusestheirnotationofsoftgoals for non-functional requirements and contribution links for the interdependencies. However, the approaches focus on the refine- ment of non-functional requirements and their analysisfromarequirementsengineeringpointof view. From an architectural point of view, despite someworksalsodealingwitharchitecturaldesign asforexampletheoneofGrauandFranch(2007), further design activities and notations have to be used. We argue that there are several drawbacks. For example, in the goal-oriented approaches, architectural constraints from the environment as wellasinterdependencieswithtechnicalsolutions are not considered. They cannot assure that a se- lectedsolutioncanbeimplementedwithaspecific technology. Furthermore, the goal-oriented ap- proachesdonotconsidergeneraldesignprinciples in their decomposition and refinement, although they are very important for choosing proper so- lutions during architectural design. Beyond, the comprehension of the quality goals’ background is an important issue for architectural design. That is way giving only goal models as input to software architects as a means for description is rather insufficient. Therefore, we integrate these techniques in a context of further design steps. Furthermore, in the work of Chung et al. (2000) they only concentrate on accuracy, performance, and security requirements—on the last one in a rather outdated way—and are not concerned with traceabilityissues.Wewilllaterdiscusstraceabil- ityandalsosomesecurityaspects,whendescribing our TraGoSoMa method, in more details. Traceability Traceability is a concept to relate artifacts from differentdevelopmentstages,suchasrequirements analysis, design, and implementation via links. The use of traceability links is advantageous even if additional effort is required. Traceability links facilitate system comprehension by providing informationaboutdependenciesbetweenartifacts and entities. Requirements traceability enables to trace back the origin of a requirement to its elici- tation and to document every change made to it. Important works in this field are the ones of Gotel and Finkelstein (1994), Pohl (1996), Ramesh and Jarke (2001), Letelier (2002) as well as Pinheiro (2004). Other approaches for traceability link es- tablishment consider links between requirements and test cases, for example the scenario-driven approach by Egyed (2001) and the approach by Olsson and Grundy (2002). In the scope of our work, traceability links can be used to trace design decisions during the developmentprocess.Approachesregardingtrace- ability from requirements to design and between various design artifacts have to be considered. Traceability links for design shall be established andadaptedwhilebuildingormanipulatingmod- elsorotherdevelopmentactivities.Therefore,the steps of link establishment have to be embedded into the steps of design methods. We have to state that—to the best of our knowledge—there are no approachesofthiskind.Forestablishingtraceabil- ity links regarding non-functional requirements and design artifacts there is the probability-based retrievalapproachbyClelang-Huangetal.(2005) calledGoal-CentricTraceability.Theiruserevalu- ation step to discard incorrectly retrieved links to increase precision is valuable. However, they can onlyidentifylinksthatareincidentallyincludedin the descriptions of artifacts that were elaborated regardless of traceability. They cannot identify links, if the investigated artifacts do not cover the relations. Therefore, the completeness and correctness of the links can never be optimal.The incrementalapproachofLatentSemanticIndexing by Jiang et al. (2007) aims at the identification of related elements with link recovery. It can be helpful for finding links in existing designs and maintaining their change, but it cannot provide all links.
- 31. 7 Tracing the Implementation of Non-Functional Requirements For the definition of relations between design activities and traceability links, a standardized definition of the syntax and semantics of the traceability links is necessary. Unfortunately, the definition of a standard set of traceability link types is still an unresolved issue. Due to different research goals, a high number of trace- ability link types has been defined, for example in (Pohl, 1996) or (Ramesh & Jarke, 2001). As a step towards simplification and abstraction, we will later restrict ourselves on a small set of types. For an exploitation of the traceability links, they have to be established on a detailed level, for example to generate test cases; they have to connect model elements and expressions. As a result, the number of links and the complexity of traceability information are high. The issue of maintainingandcheckingthelinksleadstoahigh effort and thus tool support is essential. An over- view of research topics, results, and open issues in the field of traceability is discussed in (Mäder et al. 2006) and (Winkler & von Pilgrim, 2010). There is already support for traceability by requirements management tools, e.g., Requisite Pro or Doors, and by goal-modeling tools, such as jUCMNav (Roy et al. 2006). However, their support for linking other artifacts than require- ments is limited. Mäder et al. (2008) present an approach that tackles the problem of automated traceability for UML-based development. Their traceMaintainer is a rule-based prototype tool for traceability link maintenance. Nonetheless, there is a need for further work, because the tool does not cover initial link establishment and tool support should not be limited to UML models as well. For an automated link establishment, the definition of proper rules is an important issue. Therefore, as a first step, in (Bode & Riebisch, 2009) we already described in detail, how trace- ability links can be established during several development steps and between different design artifacts using the example of the category-based designmethodologyQuasar(Siedersleben,2004). In the next section we illustrate our design method TraGoSoMa for tracing the implementa- tionofnon-functionalrequirements.Weestablish traceabilitylinksbetweennon-functionalrequire- ments, architectural principles, and functional solutions. Therefore, we present a set of link types and their semantics, and we explain how they are applied while performing the several design activities according to our Goal Solution Scheme. With the help of these traceability links according to the Goal Solution Scheme, espe- cially the comprehension of the transformation of non-functional requirements to solutions is supported. The design-decisions are traced and rationale for the decisions can be connected to the links. Furthermore, with the help of the links and an evaluation of the decisions, the completeness of solutions for the non-functional requirements can be checked. ARCHITECTURAL DESIGN PROCESS OF THE TRAGOSOMA METHOD In this section we present the design method TraGoSoMa, named by an acronym for Trace- ability-driven Goal Solution Mapping. We first give a short overview of the method; afterwards we introduce our case study, which illustrates the design activities, and the Goal Solution Scheme, which constitutes a core concept and drives our method. Further, traceability issues are discussed andthephasesofthedesignmethodareexplained in detail. TraGoSoMa Method Overview The method TraGoSoMa represents an architec- tural design method with focus on non-functional properties. It starts after elicitation, analysis, and specification of the requirements and consists of different phases and steps illustrated in Figure 1. First of all, a functional decomposition of the sys-
- 32. 8 Tracing the Implementation of Non-Functional Requirements tem is performed akin to QASAR’s FAD method. This could be done using different approaches, such as feature models or function trees, and re- sults in candidates for architectural components, the responsibilities of which are determined by functional requirements. We propose to perform decompositionaccordingtothefunctionalrequire- ments first, because this is for example necessary todeterminethesecurity-relevantpartsofthesys- tem; see (Bode et al. 2009) for details. However, designing for the non-functional goals is even more important, but less understood today. So, in the second phase of our method especially the designfornon-functionalrequirementsishandled. This second phase is strongly connected to the GoalSolutionScheme.Thefirststepisperformed, if not already provided from the requirements specification. The soft, imprecise, mostly vague, ambiguous, and competing non-functional re- quirements, such as flexibility, scalability, or security, are modeled as goals and refined into subgoals. This enables the resolution of conflicts between the goals by prioritizing the subgoals accordingly. In this step, we utilize the goal-ori- ented approaches discussed before, instead of pure scenario-based techniques as proposed by most architectural design methods. In a second step, these subgoals are mapped to the design principles, which support the subgoals. We intro- duce this mapping, which is not performed in the goal-orientedapproaches,becausegeneraldesign principles are very important for choosing prop- ersolutionsduringarchitecturaldesign.Addition- ally, the architect has to be involved in this modelingprocesssinceonlyprovidinggoalmod- els as input for further design is not enough. In the third step, possible functional solutions and technicalcomponents,asso-calledsolutioninstru- mentsthatsupportspecificprinciplesandsubgoals areidentified,andtraceabilitylinksareestablished accordingly. In this second and third step several architectural decisions have to be made about which principles and solutions are considered for design of the software architecture with regard to trade-offs and synergies between different sub- goals. These decisions are significant, because the effect of the relations between subgoals can bemutualenhancementorreduction.Afinalfourth step in the second phase further combines the functional decomposition of the first phase with the findings from the second. Asaresultofthesecondphase,thearchitectural components are defined according to functional andnon-functionalresponsibilities,andfunctional solutionsareelaboratedfornon-functionalrespon- sibilities.Thesolutionsandtechnicalcomponents Figure 1. Phases and steps of the TraGoSoMa method related to requirements engineering
- 33. 9 Tracing the Implementation of Non-Functional Requirements established in the second phase with the help of the Goal Solution Scheme are integrated into the software architecture. Therefore, adequate archi- tectural transformations have to be performed akin to the third phase of QASAR. The kind of these transformations, and how they are applied, is discussed in a later section.All activities in the second phase of the TraGoSoMa method have to be subject to an early assessment within an iterative design process. With the evaluation all decisions and the contributions of the solutions to the non-functional requirements are checked. We deal with this issue in an extra section. In the following sections we assume the re- quirements specification and functional decom- position to be done and concentrate on the second phase of the architectural design process dealing withthenon-functionalproperties.Wealsoexplain how this approach facilitates design traceability. Service-Oriented MES Case Study For the illustration of theTraGoSoMa method we use a case study from a reengineering project for a Manufacturing Execution System (MES) that is restructured according to the SOA principles. A MES manages the manufacturing in modern flexible plants (VDI, 2007). It is connected to Enterprise Resource Planning (ERP) systems, whichhandlemanufacturingplansandactionsand represent a business perspective, while the MES is able to manage the manufacturing actions on a morefine-grainedlevel.AnMEShasaccesstothe abilitiesandthelimitationsoftherealmanufactur- ing processes and, therefore, it is able to optimize them, and simultaneously provides an increased flexibility.TheMEScoverstasks,suchasdetailed scheduling and process control, the management of machines, material, and personnel, etc. For the case study we focus on the integration between ERP and MES. The requirements to the interface between both are defined by the ANSI standard ISA-95 (ISA, 2000).As the platform for the MES interfacetheEnterpriseServiceBus(ESB)(Chap- pell, 2004) has been chosen, in a style similar to a middleware. Figure 2 shows the integration interface and its environment. There are some non-functional properties an MES has to fulfill: a high flexibility and scal- ability, time behavior as well as security. As an example for a security requirement we mention the information flow control. In our case it is important to protect the business-critical private information of the customer 1 from an unauthor- ized access by its competitor customer 2. Even if both give manufacturing tasks to the producer, no details about the order must be disclosed to the competitor through the ESB or the MES, for exampledetailsconcerningamount,specification, andtechnologicalprocess.Flexibilityisnecessary regarding different planning algorithms, control principles, and regarding the integration with a varietyofmachinesandERPsystems.Therequire- ments for scalability arise from the need for mastering complex manufacturing tasks with a high number of variants and elements, and for the interoperationwithmultipledifferentERPsystems due to outsourcing. Goal Solution Scheme TheGoalSolutionSchemewasdevelopedtoguide thedesignertodealwithnon-functionalproperties whiledesigningthearchitecture,toeaseresolving conflicts between competing goals and design principles, and to facilitate decision-making. Figure 2. Overview of the integration interface
- 34. 10 Tracing the Implementation of Non-Functional Requirements It has some similarities with goal-graphs from requirements engineering. However, the scheme extends it by the explicit consideration of design principles and a classification of functional and technical solutions. As indicated in Figure 3, the Scheme maps non-functional requirements to their subgoals, to solution principles supporting these goals, and further to solution instruments, such as technical solutions and components, for animplementationoftheprinciples.Themapping is represented by traceability links, which are visualized in Figure 3 by the arrows. From top to bottomtheschemerepresentspossiblerefinements and decisions during the implementation of non- functional requirements. The traceability links carry the information about the design decisions. By providing guidance the scheme refines the design methods and facilitates the establishment and maintenance of traceability links related to the design activities. The scheme guides the activities within analysis and design and represents them by tran- sitions between the layers. The upper transition supports the resolution of conflicting non-func- tionalpropertiesbyarefinementtosubgoals.Such a specification and refinement of non-functional goals can also be provided by the goal-oriented approaches we discussed above, e.g., the NFR framework, i*, or GRL. However, we included this transition step because this kind of specifica- tion of non-functional goals is seldom provided tosoftwarearchitectsinpractice.Thecomprehen- sionofthistransitionisnecessaryforthesoftware architectsaswell,becausetheyhavetocontribute to the prioritization of the non-functional goals and they have to implement the goals by selecting properprinciples.Sincewedonotwanttoreinvent the wheel, we adopt the goal-oriented notation for softgoals and the contribution links, even if this leads to an overlapping with requirements engineering models. The next transition of the scheme guides the designer from non-functional goals to solution principles, which is a novelty step regarding the design progress towards a solution in comparison tothegoal-orientedrequirementsengineeringap- proaches. In the lower transition of the scheme, technical solutions and existing components are mapped as solution instruments to the principles, making decisions on how to implement the goals and principles by solutions. A similar concept is usedfortheFactor-StrategyModelsofMarinescu and Ratiu (2004) who use design rules and prin- ciples to map metrics to quality goals. As a major contribution the scheme facilitates theprioritizingfordecision-making.Furthermore, the scheme supports the resolution of conflicting non-functional requirements by an identification of potential trade-offs and synergies. It provides a fine-grainedsequenceofdesignsteps.Inthisway, the scheme represents a refinement of the design activities, which are represented by traceability links.Areductionofthetraceabilitylinkcomplex- ity is achieved, since one or a few principles and solution instruments implement one subgoal. In anad-hocdesignnon-functionalrequirementsare implemented in a scattered manner leading to a much higher number of links, for example 10 or 100 times higher. The Goal Solution Scheme constitutes the central concept for the simplification of the traceability links. It facilitates the traceability in several ways: • Significant reduction of the number of links, Figure 3. Structure of the Goal Solution Scheme
- 35. 11 Tracing the Implementation of Non-Functional Requirements • Guidance for the designer by sequences of proposed design activities, which enables tool-supported decisions and automation, • Simplification of link checks for accuracy, completeness, and consistency by a com- parison between chosen solutions and rela- tions within the Goal Solution Scheme. As a result, the scheme provides an alignment of solution principles and solution instruments, it classifies them according to their impact on non-functional properties, and it provides a stock of reusable solution instruments to the architect and the designer. The solution instruments serve as a source of proposals for design alternatives during decision-making. Theschemeisnotadesignartifactthatrequires additional maintenance and effort. It rather is a data structure on a meta-level, which indicates and guides how the architectural design steps should be performed in the TraGoSoMa method. If traceability links are established appropriately and managed in a repository, the organization of the repository reflects the Goal Solution Scheme. Beyond, a software architect can use the scheme as a knowledge base, where solution instruments are mapped to principles and goals. Traceability Links As mentioned previously, traceability links con- nect artifacts in the sequence the developer has built or accessed them. Furthermore, they carry the information about the design decisions that lead to the related solution instruments, such as components.Forthelinktracking,evaluation,and exploitation,thetypeofthetraceabilitylinkisim- portant, because it determines a link-semantics as mentionedinthebackgroundsection;thenumber of link types should be small. Additional information can be stored attached to the link, e.g., design decisions. Important ele- ments an explicit traceability link comprises are: • a unique identifier for its recognition and to avoid ambiguity, • a start element as source of the link, includ- ing type and context of this element, • an end element as destination of the link, including type and context, • the type of the link. For the decision-making, traceability links are advantageous because they make decisions explicit and comprehensible. Alternatives can be estimated.Softwarearchitecturedesigndecisions should always be documented with their design rationale (Clements et al. 2003). Therefore, they arerecentlyseenasfirstclassentities.Duenasand Capilla (2005) for example introduced a decision viewforsoftwarearchitectures.TheGoalSolution Scheme facilitates the tracing of such decision entities to their related artifacts. Therefore, a link may contain additional information: • a reference to a design rule for this specific activity, • the decision connected with the develop- ment activity, including the goal of the de- cision, alternatives, the rating of the alter- natives and the choice, • the link status concerning the certainty of correctness (e.g., after changes of the con- nected elements or during reverse engi- neering activities), • the creator of the link, • a temporary priority to control the tracking of the links. As introduced by earlier works (Mäder et al., 2007), we distinguish four different link types, whicharesufficientforthemostdesignsituations: • refine – for an activity increasing the level of detail, either by specialization or by de- composition including the AND and OR types.
- 36. 12 Tracing the Implementation of Non-Functional Requirements • realize – represents a step towards the so- lution (e.g., between a non-functional goal and a design principle or between a prin- ciple and a solution) • verify – compares the behavior and the properties of requirements and of the de- veloped solution or its parts (e.g., between a use case and a test case) and • define – relates the establishment of an identifier and its usage. Additional link types can be introduced for dependency types from utilized models as for ex- ample UMLmodels. In order to be able to handle the goal models and their contribution links we added the link type • contribution – which can express degrees of positive or negative influence between model elements. Withthehelpofthecontributionlinksanevalu- ation of alternatives can be achieved, for example in relation to the goal models. However, positive contributions can also be linked as realizations, when a solution is chosen. The realization links thenenabletracingwhichpathwastakenfromthe problem space to the solution space and how the goals are achieved by the implemented solution. Traceabilitylinkscanbetrackedinbothdirec- tions, regardless of the direction that is defined by the link type. Besides, a distinction between implicit and explicit links is necessary. Explicit traceability links are established, while a devel- oper performs a software development activity. Implicit traceability represents existing associa- tions between elements of the system model us- ing identifiers, for example between an analysis and a design artifact. These traceability links are references, but they are evaluated if traceability links are tracked during their utilization. The type of the traceability links is defined ac- cording to the TraGoSoMa design activities. The transitionsintheGoalSolutionSchemerepresent these activities. In the first transition the non- functional goals are decomposed and thus linked to the subgoals by links of the type refine. In the second and third transition the positive and nega- tive influence has to be represented. Therefore, links of the type contribution are established. In addition to the influences, these transitions rep- resent steps towards solutions. Consequently, the link type realize is used to express this aspect. A possible decomposition on each level of the Goal Solution Scheme, for example a decomposition of solutions, can also be traced by links of the type refine. Goal Refinement and Elaboration The several non-functional requirements for a productareoftencompetingandconflictingintheir interdependencies. As a solution they have to be prioritized. If this is not possible on the top-level, a resolution is attempted after a refinement. By refining the requirements vague interdependen- cies can be concretized and previously hidden dependencies can be made explicit. To determine the mutual impact of the relations and to detect conflicts and synergies, the requirements or goals canbeclassifiedindominating(fundamental)and supporting(instrumental)ones(Wohlfarth,2008). The refinement of the non-functional goals is covered by the first transition in the Goal Solu- tion Scheme. This is the first step in the second phase of our design approach. The refinement of the non-functional properties is necessary for their comprehension and makes them more specific. It can be performed according to the abovementioned goal-oriented approaches, e.g., the NFR framework. For the refinement standards can help, for example the ISO 9126 (ISO, 2001).This standard for instance provides subgoals for maintainabil- ity, namely analyzability, changeability, stabil- ity, testability, and maintainability compliance. Furthermore, the Goal Question Metrics (GQM) method can be applied to identify subgoals. This
- 37. 13 Tracing the Implementation of Non-Functional Requirements structured querying technique helps to analyze influences on a goal (Basili et al., 1994). The Factor-Strategy Model of Marinescu and Ratiu (2004)usesasimilarprincipleformappingquality goals to metrics. According to the NFR framework (see section Background) non-functionalrequirementshave a type and a topic. As an example, the requirement “Security of accounts” has the type “security”, which indicates the specific NFR, and the topic “accounts”, which targets at the subject. Non- functional requirements can be refined regarding type or topic. The refinement of maintainability mentioned above is a refinement regarding the type of the NFR. In our case study the top-level non-functional requirements are flexibility, scalability, and secu- rity.AccordingtotheADDmethodtheyconstitute architecturaldrivers.Afteraconsiderationoftheir relationships on this level we can assume that flexibilityandscalabilityareinarathersynergetic relationtoeachother,becausetheybothdealwith change, while security might be conflicting to the others, because it implies restrictions of the information flow and the data access. This guess has to be proven in the next steps. For a precise analysis and a solution for our MES project, a refinement has been performed. Figure 4 shows parts of the results. The refinement is presented using the i* notation for softgoals and links. For flexibility, there is a definition in the IEEE standard glossary of software engineering termi- nology (IEEE, 1990), although a detailed discus- sionofitssubgoalsismissing.Regardingflexibil- ity some discussion can be found in the literature (Zeng & Zhao, 2002; Nelson et al., 1997; Eden &Mens,2006;Morgan,2006).Weelaboratedthe subgoals extendability (IEEE, 1990), replace- ability (ISO, 2001), and modifiability (Bengtson et al., 2004) for our example. We focus on the latter two because of their high priority. Scalability is lacking a definition by a stan- dard; however, some works discuss this quality attribute (Hill, 1990; Bondi, 2000; Duboc et al., 2006; Duboc et al., 2007). Scalability is always concernedwithperformance,orefficiencyinterms of the ISO 9126 (2001), and how well a solu- tion to a problem will work when the size of the problemincreases.However,ifasystemperforms well it is not necessarily scalable, too. Therefore, we considered replaceability and modifiability as subcharacteristics of scalability as well. If an MES has to face changes for example due to an increasingcomplexityofthemanufacturingtasks, modifications are necessary. Moreover, it should be easy to replace parts of the whole system with more efficient ones, if this is necessary to scale up and retain a high performance. For security there are several definitions from the International Organization for Standardiza- tion (ISO), e.g., (ISO, 2001; ISO, 2005), and Chung et al. (2000) comprehensively discuss its refinement in their NFR framework. The most important subgoals are integrity, confidentiality, and availability. Before the refinement, we already mentioned our assumption for a synergetic relation between flexibility and scalability, as well as the possible conflict between scalability and security. The conflict could neither be verified nor solved on Figure 4. First transition of the goal solution scheme (cut-out from the case study)
- 38. 14 Tracing the Implementation of Non-Functional Requirements the top level, because both scalability and secu- rity are essential. However, after the refinement of the non-functional goals illustrated in Figure 4, we can try to solve the conflict and verify the synergetic interdependency between flexibility and scalability. The latter could be verified by the mutual positive influence of replaceability and modifiability on both top-level goals. Beyond, a negative interdependency between performance andsecuritywasdetected,becausesecuritymecha- nisms, as for example encryption, require extra operations, often are time consuming, and can hamper performance. This confirms the conflict; however, for a resolution a further refinement to principles is necessary. For the further design process of our case study we will concentrate on the subgoals replaceability, modifiability, as well as integrity, and confidentiality because of their high priority. The abovementioned refinements are ex- pressed using and-contribution links according to the i* notation. In the Goal Solution Scheme they are represented by traceability links of the type refine. The hurt-contribution can be traced with links of the type contribution if necessary. Decision about Solution Principles After the first step of the second phase of TraGo- SoMa, the top-level goals are refined into sub- goals and are more specific. But, they are still non-functional and still cannot be implemented directly.Inthesecondstep,thetransitionfromthe subgoals to the design principles is performed, as presented by the Goal Solution Scheme. As a step from the problem space to the solu- tion space, in this second step, design principles andguidelinesareassignedtothesubgoals.These principles and guidelines give hints or advice for the functional solutions. Of course, lots of principles exist and even more relations between non-functional goals and these principles are imaginable.Therefore,thedesignerhastoanalyze the subgoals and to decide on suitable principles. It is always the case, that there are different non- functional goals that have symbiotic relations or in contrary compete with each. In order to resolve conflicts, knowing about the interdependencies between the different subgoals is important. A goal model contains these dependencies and the trade-offs. For illustration an example for a decision is discussed here. The principle of high encapsula- tion supports changeability. On the other hand, a strong encapsulation has a negative influence on testability, because inaccessible attributes are hard to control. Because of the refinement from the first step, both changeability and testability are known to be subgoals of maintainability and contribute to it. Now, by assigning encapsulation tothesesubgoalsthetrade-offbecomesvisibleand can be considered. Frequently, multiple different principlescontributetothesamesubgoal.Inthese cases a decision can be made, which principle is applicable or how to prioritize them. Trade-offs between different non-functional subgoals and solution principles often are still not tangibleenough.Then,theyhavetobeelaborated further on the solution instruments level of the Goal Solution Scheme. This is necessary to be able to decide with clear rationale, which prin- ciple to choose to achieve the highest degree of goal fulfillment. In this case, the principles are mapped further to solution instruments and the decision-making is postponed to the next step, whenthecriteriaforadequatesolutioninstruments are more precise than those for the principles. Based on the solution instruments’ contributions to the principles and the non-functional goals, the different alternatives can be weighed and the decisions, which alternatives to choose, can be made. For the goal-oriented approaches some evaluation techniques exist, anyway, it is always reasonable to decide as soon as possible to reduce further effort. For our case study, the second transition of the Goal Solution Scheme is partly shown in Figure 5. The subgoals result from the refinement in the
- 39. 15 Tracing the Implementation of Non-Functional Requirements previous step of TraGoSoMa. Starting from the higher prioritized subgoals, appropriate solution principles are chosen. For the subgoals replace- ability and modifiability, we decide in favor of the architectural design principles encapsula- tion, modularization and loose coupling. These principles are well known to support changes. Already Parnas (1972) discussed the importance ofmodularizationforchangeabilityandflexibility, whichisoneofourmostimportantnon-functional goals. Moreover, service orientation was identi- fiedtosupportencapsulation,modularization,and loose coupling. A service-oriented architecture obviously can help in this scenario, because loose coupling is one of its core principles. It further helps encapsulation and modularization. In addi- tiontothecontributionlinksshowninFigure5,the mentioned principles are explicitly related to the subgoalsreplaceabilityandmodifiabilitybytrace- ability links of the type realize. This type of links is established, because the principles represent a step towards the solution of the non-functional goals, and to document the design decisions for choosing service orientation. The security subgoals integrity and confiden- tiality are discussed as another example. To inte- grate such requirements, security policies have to be applied, as a comprehensive set of rules that aredesignedtoachievethesystem’ssecuritygoals (Goguen & Meseguer, 1982). Security policies are applied to determine a so-called trusted com- puting base (TCB) (Lampson et al. 1992). The TCB comprises the functional parts of a system that enforce and protect the security policy. For the implementation of a security policy and a trusted computing base, there are fundamental principles that refer to the so-called reference monitor concept (Anderson, 1972). A reference monitor must be tamperproof, always invoked and small enough to be analyzable and verifiable, which is represented by the principles tamper- proofness,totalmediation,andverifiability.These reference monitor principles are further sup- ported by isolation and a minimal TCB as prin- ciples for the architectural design. Isolation of the security relevant functions in the security archi- tecture of a system is a necessary consequence to be able to realize a tamperproof reference moni- tor that cannot be bypassed (Gasser, 1988). Cor- rectnessandcompletenessareadditionalnecessary propertiesnotfurtherdiscussedhere(Department ofDefense,1985).Thesedecisionsandthecauses are again documented by traceability links of the type realize. However, in this design step, conflicting relations between the security principles and the subgoal modifiability were identified as well. They are shown as hurt-contribution links. Modifications in the software architecture can have a negative influence on the minimality of the trusted computing base and vice versa. The other security principles are affected by changes Figure 5. Cut-out of the transition from subgoals to principles for the case study
- 40. 16 Tracing the Implementation of Non-Functional Requirements as well. Tamperproofness can easily be breached if a modification is performed in a wrong way. Therefore, changes should only be made on those architectural parts that have not to be isolated due to security reasons. Theseconflictsconfirmourearlierassumption that security is in conflict with flexibility and scalability. However, at the principles level their interdependencieshavebeenclarifiedandwehave amuchbetterunderstandingoftheconflictthanon thegoalorthesubgoallevel.Anyway,theconflict between the fundamental security principles and the subgoal modifiability cannot be resolved in this transition of the Goal Solution Scheme. The conflict resolution has to be postponed to the next design step, when a related solution can be analyzed more precisely than the principles. Decision about Solution Instruments In the third design step the actual transformation of the non-functional properties to a functional solution is performed. This step is closely related to the third step of the QASAR method (Bosch, 2000).Asimilar mapping of solution instruments to goals can also be found in the NFR framework and the i* framework, where operationalizations, or tasks respectively, are assigned to decomposed softgoals. In our method solution instruments can be functional concepts or even existing technical components, which either support the realization ofnon-functionalgoalsorcompletelyfulfillsome ofthem.Inthisthirddesignstepalargenumberof solution instruments is possible. In order to find the most adequate ones, the designer weights the different alternatives, akin to the last step. The explicit linkage from goals to principles and solution instruments classifies the latter ones according to their contributions to the non-func- tional goals. The Goal Solution Scheme serves as a knowledgebase, which enables the incremental collection and the reuse of the solutions in a goal- oriented way. Ofcourse,thedecisionsarealsoinfluencedby othertechnicalororganizationalrequirementsand constraints.Forexamplethetechnicalcomponent JGoodies (2008) explicitly facilitates usability withitssubgoalusersatisfactionbyaneasyalign- ment and balancing of visual elements. However, it cannot be chosen, if the project demands for the C++ programming language, because JGoodies is based on Java and Swing. To consider such architectural constraints, a two-stage process can be applied. In a first step, all solutions that are inappropriate are ignored. In a second step, the remaining ones are ranked according to their satisfaction of the goals to find the best solution. Figure 6 shows a part of the Goal Solution Scheme for the transition from principles to so- lution instruments for our case study. To realize serviceorientation,andthustheprinciplesencap- sulation, modularization, and loose coupling, the solutioninstrumentsWebServicesandEnterprise Service Bus (ESB) for the integration of the MES andERParechosen.Thereasonforthesedecisions is that well-defined web services according to the Service-Oriented Architecture (SOA) paradigm inherently reinforce those principles (Erl, 2007). A component-based Common Object Request BrokerArchitecture(CORBA),forexample,could have been an alternative for a service-oriented ar- chitecture.However,forourcasestudyaCORBA infrastructure was not available. As an example from our case study, one real- ized service shall be mentioned. The service MachineAvailability can be used for the interac- tion of the detailed planning of an MES and the general planning of an ERP. Using this service the ERP can request status information about machines, such as their availability. When imple- mentingthewebservices,architecturalanddesign patterns, such as Service Layers (Fowler, 2003; Erl, 2008), Service Facade, or Legacy Wrapper (Erl, 2008), contribute to the realization of the principles,andhence,tothenon-functionalgoals. The application of a reference monitor solves the integration of the security aspects. The se-
- 41. 17 Tracing the Implementation of Non-Functional Requirements curity principles are integrated with the help of the ESB to gain control of the communication between the MES and ERP system and to isolate the security-relevant architectural parts.Aside, it must be considered to keep the TCB as small as possible.Adiscussion on the integration of secu- rity with web services can be found in (Fischer & Kühnhauser, 2008).With this kind of solution the conflict between the security principles and the subgoal modifiability, which was detected in the last design step, cannot be resolved completely. However, it can be implemented in a controlled way by controlling access to the security relevant functionality. Hence, the realization of a refer- ence monitor not only positively contributes to the reference monitor principles, but also helps encapsulation, and therefore, even modifiability despite the conflicts. As an alternative to the reference monitor, in anad-hocapproachoraccordingtothediscussion byChungetal.(2000),onecouldhaveconsidered only multiple single solution instruments, such as encryption mechanisms, or roles and rights, for security purposes. Of course, these solution instruments can contribute to confidentiality and maybe availability and integrity. However, as a drawback, without considering the reference monitor principles the system would be much more vulnerable. In this step of the TraGoSoMa design method again all decisions about solution instruments for the solution principles are made explicit by traceability links. As shown in Figure 6 all solu- tioninstrumentsaremappedtothecorresponding solution principles. The chosen solution instru- ments,suchasthepatternsServiceLayers,Service Facade, and Legacy Wrapper, are traced with links of the type realize. Additionally, elaborated alternatives not discussed here can also be linked with the type contribution and may be reused later. Figure 6 depicts only the mentioned solu- tion instruments. Actually, much more solution instruments are contained, and the architect can easily extend them by additional ones. Merging the Functional Solutions In the fourth step of TraGoSoMa’s second phase the solution instruments from both origins have to be merged, from functional goals and from non-functional ones. In this step a balancing between both types of requirements has to be performed (Harrison & Avgeriou, 2007). The functional requirements—the first type—have been elaborated into candidates for functional components as in phase 1 (see Figure 1) by a functionaldecomposition,forexamplefollowing the FAD method by QASAR. For non-functional goals—the second type—solution instruments in the form of components are integrated, which are developedaccordingtotheGoalSolutionScheme in the second phase. Figure 6. Cut-out of the transition from principles to solutions for the case study
- 42. 18 Tracing the Implementation of Non-Functional Requirements The merge can be performed by architectural changeoperationsofdifferenttypes.Thesimplest caseistoonlyaddthefunctionalcomponentsthat implement non-functional requirements from the secondphasetothecomponentsofthefirstphase. A second type of transformation is to replace functional components. For example, if a func- tional component from phase one is insufficient in fulfilling the non-functional requirements, it is replaced by the solution instruments elaborated in the second phase. A third type of transforma- tion is to remove a previously decomposed func- tional component to enable the realization of a non-functional goal. Baldwin and Clark (2000) mention three more elementary types of changes called modular operators: split a component into two,portacomponentforextractiontoanewone, andinversionofhierarchyformovingcomponents from a lower position in a hierarchy to a higher one. As another example, we mention the imple- mentation of security goals. To solve this task by the reference monitor concept (Anderson, 1972) a separation of security-relevant and security- irrelevant functional components is performed to achieve a minimal Trusted Computing Base applyingtheinversionofhierarchyoperation(for more details see Bode et al., 2009). In the case security-relevantandsecurity-irrelevantfunctions are covered by one component, it has to be split or partly ported. As the result of the merge a software archi- tecture has been developed. Its components are functional ones, which can be implemented di- rectly.Allresponsibilitiesthatareduetofunctional and non-functional requirements are assigned to these components. Evaluation of the Decisions Foranearlyassessmentofthearchitecturaldesign any iteration should include an evaluation. The assessment technique depends on the character- istics of the assessed products and on the criteria to be evaluated. Thereareseveralwell-establishedassessment techniques for software architectures. Two types areespeciallysuitable—questioningandmeasur- ing techniques. The techniques of the first type, forexamplestructuredscenario-basedinspections with the Architecture Tradeoff Analysis Method (ATAM) (Kazman et al., 2000), are performed by experts. Based on the assessment criteria, the scenariosareestablished,forexampleanintrusion scenario for an evaluation regarding security or an extension scenario regarding maintainability. Evaluations of this type can be performed early, evenifthearchitectureisnotcomplete.Performing the evaluation in a structured, formally defined way by external experts can reduce the disadvan- tage of the subjective nature of the result. The measuring techniques provide objective, quantitativeresults.However,theyrequireformal models and well-defined evaluation criteria. Ex- amples for this type are metrics for architectural quality,e.g.,formodularitybyrelatingthenumber of all inner dependencies of a component to the outer ones. In (Brcina & Riebisch, 2008) trace- ability links between model elements are evalu- ated for evolvability, and for example the effects of tangled or scattered components are assessed as criteria for architectural quality. FUTURE RESEARCH DIRECTIONS The consideration of non-functional properties constitutes a long-term goal for architectural development, even beyond SOA. Further work is needed to close the gap between requirements engineering and architectural design regarding integration of methods. Maybe aspect-oriented techniques can help regarding this issue as well. Moreover, there is a special need for integrating the mentioned concepts with the Model-Driven Architecture (MDA) approach. The need for a rigor specification of non- functional requirements can be fulfilled only for some categories, e.g., security. Many others, e.g.,
- 43. 19 Tracing the Implementation of Non-Functional Requirements usability, flexibility, and scalability, are specified by informal or semi-formal descriptions. Ontolo- gies can help to analyze the semantics of these descriptionsbasedonthetermsandtheirrelations. For the early evaluation of the results of ar- chitectural decisions, a prototyping is necessary in some cases, for example for requirements regarding efficiency and scalability. The genera- tion of the necessary prototypes shall be based on the architectural decisions and documents to minimize the additional effort. CONCLUSION In this paper the architectural design method TraGoSoMa has been presented, which provides improved support and guidance for the architect toconsidernon-functionalproperties.Themethod aims at the definition of components and their implementation illustrated with a SOA example. As an important element the method introduces the Goal Solution Scheme, which represents the alignment between non-functional goals, their subgoals, the applied solution principles, and the solution instruments for implementing the required properties. By using this scheme, the conflict resolution between competing goals is supported, the solution principles and the solu- tion instruments are classified according to the non-functional goals supported by them, and the systematic selection of solution instruments during architectural decisions is facilitated. Fur- thermore, the Goal Solution Scheme supports the accumulation of architectural know-how by a stepwise extension of the classification and the solutioninstruments.Theschemeexpressestrace- ability links in an explicit way, while the method facilitates their establishment, and thus, supports themaintainabilityofthesoftware.Especiallyim- portant is the traceability between non-functional goals, such as scalability, efficiency, and security, and the chosen solution instruments. Regarding state-of-the-art methods, the con- tributions of the method can be compared to the QASAR method as well as to the works of Chung etal.andYuasdiscussedinthebackgroundsection. TheQASARmethodisextendedbyenhancingits seconddesignphasebyasystematicprocedurefor non-functionalproperties,whichreducestheeffort for transformations, and by improving the third phase by reducing the scattering of the changes to the design. In comparison to the goal-oriented approaches from requirements engineering, we consider architectural constraints from the environment as well as interdependencies with technical solution instruments. Furthermore, as a novelty step, we map non-functional goals to solutionprinciplesandintegratethegoal-oriented activities in the context of an architectural design method. We use a design decision process, espe- ciallyconsideringwell-knownsolutionprinciples to find conflicts, synergies, and solution instru- ments. Beyond, we include the establishment of traceability links into our method. The method is applied for the redesign of a ManufacturingExecutionSystem(MES)inorder tointegrateitintoaservice-orientedenvironment of business systems in manufacturing. With the help of this case study, we illustrate the several design steps, and therefore, show the importance of such a methodical design and its relevance for industrial use. REFERENCES Amyot,D.(2003).Introductiontotheuserrequire- ments notation: Learning by example. Computer Networks, 42(3), 285–301. doi:10.1016/S1389- 1286(03)00244-5 Anderson,J.P.(1972).Computersecuritytechnol- ogy planning study (Tech. Rep. ESD-TR-73-51), L. G. Hanscom Field, Bedford, MA, USA: U.S. Air Force, Electronic Systems Division, Deputy for Command and Management Systems, HQ Electronic Systems Division (AFSC).
- 44. 20 Tracing the Implementation of Non-Functional Requirements Baldwin, C. Y., & Clark, K. B. (2000). Design rules: The power of modularity (Vol. 1). Cam- bridge, MA: MIT Press. Basili, V. R., Caldiera, G., & Rombach, H. D. (1994). The goal question metric approach. In Marciniak, J. (Ed.), Encyclopedia of software engineering. Wiley. Bass, L. J., Klein, M., & Bachmann, F. (2002). Qualityattributedesignprimitivesandtheattribute driven design method. In F. van der Linden (Ed.) Software product-family engineering, 4th Inter- national Workshop, PFE 2001, Revised Papers, (pp. 169-186). Berlin: Springer. Bengtsson, P., Lassing, N., Bosch, J., & van Vliet, H. (2004). Architecture-level modifiabil- ity analysis (ALMA). Journal of Systems and Software, 69(1-2), 129–147. doi:10.1016/S0164- 1212(03)00080-3 Bode,S.,Fischer,A.,Kühnhauser,W.,&Riebisch, M. (2009). Software architectural design meets security engineering. In Proceedings of the 16th Annual IEEE International Conference and WorkshopontheEngineeringofComputerBased Systems (ECBS). (pp. 109-118). USA: IEEE. Bode, S., & Riebisch, R. (2009). Tracing quality- related design decisions in a category-driven softwarearchitecture.InLiggesmeyer,P.,Engels, G., Münch, J., Dörr, J., & Riegel, N. (Eds.), Proceedings of Software Engineering 2009 (pp. 87–98). Bonn, Germany: Köllen. Bondi,A.B.(2000).Characteristicsofscalability and their impact on performance. In Proceedings of the 2nd International Workshop on Software and Performance (WOSP ‘00), (pp. 195-203). New York: ACM. Bosch, J. (2000). Design and use of software architectures. New York: Addison Wesley. Brcina,R.,&Riebisch,M.(2008).Architectingfor evolvabilitybymeansoftraceabilityandfeatures. In Proceedings of the 4th International ERCIM WorkshoponSoftwareEvolutionandEvolvability (Evol’08) at the 23rd IEEE/ACM International Conference onAutomated Software Engineering, (pp. 235-244). USA: IEEE. Chappel, D. A. (2004). Enterprise service bus. USA: O’Reilly Media. Chung, L., Nixon, B.A.,Yu, E., & Mylopoulus, J. (2000). Non-functional requirements in software engineering. Norwell, MA: Kluwer Academic Publishing. Cleland-Huang, J., Settimi, R., BenKhadra, O., Berezhanskaya, E., & Christina, S. (2005). Goal- centric traceability for managing non-functional requirements. In Proceedings 27th International Conference on Software Engineering, (pp. 362- 371). New York: ACM. Clements, P., Bachman, F., Bass, L., Garlan, D., Ivers,J.,&Little,R.(2003).Documentingsoftware architectures: Views and beyond. Amsterdam: Addison-Wesley Longman. DepartmentofDefense(1985).Trustedcomputer system evaluation criteria. DoD 5200.28-STD. Duboc, L., Rosenblum, D., & Wicks, T. (2006).A frameworkformodellingandanalysisofsoftware systems scalability. In Proceedings of the 28th International Conference on Software Engineer- ing ICSE ‘06, (pp. 949-952). New York: ACM. Duboc, L., Rosenblum, D., & Wicks, T. (2007). A framework for characterization and analysis of software system scalability. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software En- gineering ESEC-FSE ‘07, (pp. 375-384). New York: ACM.
- 45. 21 Tracing the Implementation of Non-Functional Requirements Dueñas, J. C., & Capilla, R. (2005). The decision view of software architecture. In Proceedings of the2ndEuropeanWorkshoponSoftwareArchitec- ture(LNCS3527),(pp.222-230).Berlin:Springer. Eden,A., & Mens,T. (2006). Measuring software flexibility. IEE Proceedings. Software, 153(3), 113–125. doi:10.1049/ip-sen:20050045 Egyed, A. (2001). A scenario-driven approach to traceability. In Proceedings of the 23rd Inter- national Conference on Software Engineering ICSE’01, (pp. 123-132). Washington, DC: IEEE. Erl, T. (2007). SOA: Principles of service design. Upper Saddle River, NJ: Prentice Hall. Erl,T.(2008).SOAdesignpatterns.UpperSaddle River, NJ: Prentice Hall. Fischer,A., & Kühnhauser,W. E. (2008). Integra- tion von Sicherheitsmodellen inWeb Services. In P.Horster(Ed.),D.A.CHsecurity2008.Hannover, Germany: eMedia. Folmer, E., & Bosch, J. (2003). Usability patterns insoftwarearchitecture.InProceedingsofthe10th International Conference on Human-Computer Interaction HCII2003 vol. I, (pp. 93-97). Fowler, M. (2003). Patterns of enterprise ap- plication architecture. Boston: AddisonWesley. Galster,M.,Eberlein,A.,&Moussavi,M.(2006). Transition from requirements to architecture: A reviewandfutureperspective.InProceedingsSev- enth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, andParallel/DistributedComputing(SNPD’06), (pp. 9-16). USA: IEEE. Gasser, M. (1988). Building a secure computer system. New York: Van Nostrand Reinhold Co. Goguen, J. A., & Meseguer, J. (1982). Security policiesandsecuritymodels.InProceedingsIEEE Symposium on Security and Privacy, (pp. 11-20). Washington, DC: IEEE. Gotel, O. C. Z., & Finkelstein,A. C.W. (1994).An analysis of the requirements traceability problem. In Proceedings of the First International Confer- ence on Requirements Engineering, (pp. 94-101). USA: IEEE. Grau, G., & Franch, X. (2007). A goal-oriented approachforthegenerationandevaluationofalter- nativearchitectures.InF.Oquendo(Ed.),Software architecture, Proceedings First European Confer- ence, ECSA2007. (pp. 139-155). Berlin: Springer. Harrison,N.,&Avgeriou,P.(2007).Pattern-driven architecturalpartitioning:Balancingfunctionaland non-functional requirements. In Proceedings Sec- ond International Conference on Digital Telecom- munication (ICDT’07), (pp. 21-26). USA: IEEE. Hill, M. D. (1990). What is scalability? SIGARCH Computer Architecture News, 18(4), 18–21. doi:10.1145/121973.121975 Hofmeister,C.,Nord,R.,&Soni,D.(2000).Applied softwarearchitecture.NewYork:AddisonWesley. ISA. (2000). ISA–95.00.01–2000 Enterprise- control system integration. Part 1: Models and terminology. North Carolina: ISA. ISO. (2001). ISO/IEC 9126-1 International stan- dard. Software engineering–product quality –part 1: Quality models. ISO. (2005). ISO/IEC 27001:2005 Information technology–security techniques–information se- curity management systems–requirements. JGoodies. (2008). JGoodies: Java user interface design. Retrieved October 13, 2008, from http:// www.jgoodies.com/ Jiang, H., Nguyen, T. N., Chang, C. K., & Dong, F.(2007).Traceabilitylinkevolutionmanagement withincrementalsemanticindexing.InProceedings 31stAnnual International Computer Software and Applications Conference (COMPSAC 2007), (pp. 309-316). USA: IEEE.
- 46. 22 Tracing the Implementation of Non-Functional Requirements Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for architecture evaluation. (Tech.Rep.CMU/SEI-2000-TR-004).Pittsburgh: Carnegie-Mellon University, Software Engineer- ing Institute. Lampson, B., Abadi, M., Burrows, M., & Wob- ber, E. (1992). Authentication in distributed systems: Theory and practice. ACM Transac- tions on Computer Systems, 10(4), 265–310. doi:10.1145/138873.138874 Letelier, P. (2002).Aframework for requirements traceability in UML-based projects. In 1st Int. Workshop on Traceability in Emerging Forms of SE (TEFSE’02), (pp. 32-41). Edinburgh, UK. Liu, L., & Yu, E. (2001). From requirements to architectural design–using goals and scenarios. In From Software Requirements to Architectures Workshop (STRAW 2001), (pp. 22-30). Toronto, Canada. Mäder, P., Gotel, O., & Philippow, I. (2008). Rule-based maintenance of post-requirements traceability relations. In Proceedings of the 2008 16th IEEEInternationalRequirementsEngineering Conference (RE ’08), (pp. 23-32). USA: IEEE. Mäder, P., Philippow, I., & Riebisch, M. (2007). Customizing traceability links for the unified process. In Proceedings of the Third Interna- tional Conference on the Quality of Software- Architectures (QOSA2007) (LNCS 4880). (pp. 47-64). Berlin: Springer. Mäder, P., Riebisch, M., & Philippow, I. (2006). Traceabilityformanagingevolutionarychange.In Proceedingsofthe15thInternationalConference on Software Engineering and Data Engineering (SEDE-2006), (pp. 1-8). USA: ISCA. Marinescu, R., & Ratiu, D. (2004). Quantifying the quality of object-oriented design: The factor- strategy model. In Proceedings 11th Working Conference on Reverse Engineering (WCRE 2004), (pp. 192-201). USA: IEEE. Morgan, G. (2006). Design for flexibility. Re- trieved October 13, 2008, from http://blogs. msdn.com/gabriel_morgan/archive/2006/10/03/ Design-for-Flexibility.aspx Nelson,K.,Nelson,H.,&Ghods,M.(1997).Tech- nology flexibility: Conceptualization,validation, and measurement.In Proceedings of the Thirtieth Hawaii International Conference on System Sci- ences,Vol.3,(pp.76-87).Washington,DC:IEEE. Nielsen,J.(1993).Usabilityengineering.Boston: Academic Press. Ollson,T.,&Grundy,J.(2002).Supportingtrace- ability and inconsistency management between software artifacts. In Proceedings of IASTED International Conference on Software Engineer- ing and Application. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Com- munications of the ACM, 15(12), 1053–1058. doi:10.1145/361598.361623 Pinheiro,F.A.C.(2004).Requirementstraceabil- ity. In Leite, J. C. S. P., & Doorn, J. (Eds.), Per- spectives on software requirements (pp. 91–113). Norwell, MA: Kluwer Academic Publishers. Pohl, K. (1996). PRO-ART: Enabling require- ments pre-traceability. In Proceedings of the SecondInternationalConferenceonRequirements Engineering ICRE’96, (pp. 76-84). Washington, DC: IEEE. Ramesh, B., & Jarke, M. (2001). Toward refer- ence models for requirements traceability. IEEE Transactions on Software Engineering, 27(1), 58–93. doi:10.1109/32.895989 Roy, J., Kealey, J., &Amyot, D. (2006). Towards integrated tool support for the user requirements notation.InR.Gotzhein&R.Reed(Eds.),System analysis and modeling: Language profiles. (pp. 198-215). Fifth International Workshop, SAM 2006. Berlin: Springer.
- 47. 23 Tracing the Implementation of Non-Functional Requirements Shneiderman, B. (1992). Designing the user in- terface: Strategies for effective human-computer interaction (2nd ed.). Boston: Addison-Wesley. Siedersleben, J. (2004). Moderne Software Ar- chitektur: Umsichtig planen, robust bauen mit Quasar. Heidelberg, Germany: dpunkt.verlag. StandardsCoordinatingComitteeoftheComputer Society of the IEEE. (1990). IEEE standard glos- sary of software engineering terminology. IEEE Std 610.12-1990. VDI. (2007). VDI 5600: Fertigungsmanage- mentsysteme. Manufacturing Execution Systems (MES). Berlin: Beuth. Winkler, S., & von Pilgrim, J. (2010). A survey of traceability in requirements engineering and model-driven development. In Software and Systems Modeling, 9(4), 529-565. Wohlfarth, S. (2008). Entwicklung eines ratio- nalenEntscheidungsprozessesfürArchitekturents- cheidungen. Unpublished doctoral dissertation, Ilmenau University of Technology, Germany. Yu, E. (1995). Modelling strategic relationships for process reengineering. Unpublished doctoral dissertation, Dept. of Computer Science, Univer- sity of Toronto, Ontario, Canada. Zeng, D., & Zhao, J. (2002). Achieving software flexibility via intelligent workflow techniques. In Proceedings of the 35th Annual Hawaii Inter- national Conference on System Sciences, HICSS, (pp. 606-615). Washington, DC: IEEE. KEY TERMS AND DEFINITIONS Architectural Design Method:Asystematic approach with analysis, synthesis, and evaluation activitiestocreateasoftwarearchitecturaldescrip- tion from functional as well as non-functional requirements taking organizational and techno- logical constraints into account. Enterprise Resource Planning: The com- plex task to efficiently use all resources of an enterprise, such as financial assets, production facilities, or personnel, to control and optimize business processes. Manufacturing Execution System: A soft- ware system responsible for the organization and execution of the production process in a factory withnumeralscopesofdutyasmanagementofall requiredactivitieswithintheproductionprocessor theexchangeofinformationwiththeenvironment astoERPsystems(foracomprehensivedefinition see (VDI, 2007) for a comprehensive definition). Non-Functional Requirement: Also quality requirement, quality attribute, or quality goal – a software requirement that describes not what a software system has to do, but how it should be done and under which constraints, and therefore, defines its quality (for a comprehensive discus- sion see (Chung et al., 2000) for a comprehensive discussion). SoftwareArchitecture:Thedescriptionofthe organizational structure of a software system, its architecturalelements,theirproperties,interfaces, relations, and behavior, as well as a set of deci- sions and guidelines for the design of the system. SoftwareQuality:Thetotalityofcharacteris- tics of a software product that bear on its ability tosatisfyspecifiedrequirements(cf.ISO,2001)). Traceability: The capability to track and recover in both a forwards and backwards direc- tion the development steps of a software system and the design decisions made during on-going refinement and iteration in all development phases by relating the resulting artifacts of each development step to each other (based on (Gotel & Finkelstein, 1994)).
- 48. 24 Copyright © 2011, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Chapter 2 Daniel Gross University of Toronto, Canada Eric Yu University of Toronto, Canada Xiping Song Siemens Corporate Research, USA Developing Non-Functional Requirements for a Service- Oriented Application Platform: A Goal and Scenario-Oriented Approach ABSTRACT The challenges in developing non-functional requirements (NFRs) for an application platform go much beyond those for a single application system. To derive platform NFRs from NFR specifications of differ- ent domain applications, requirements analysts must deal with much variation of domain specific NFRs, with different deployment configurations and load conditions, with different NFR related trade-offs, as well as with different terminology and metric definitions. This chapter presents a platform NFR develop- ment method that supports dealing with the aforementioned challenges. The presented method offers a goal- and scenario-oriented modeling and analysis technique that supports dealing with qualitative and quantitative NFRs during platform NFR development in an integrated way. The platform NFR develop- ment method was used to develop NFRs of a service-oriented application platform for three different application domains in an industrial setting. DOI: 10.4018/978-1-60566-794-2.ch002
- 49. 25 Developing Non-Functional Requirements for a Service-Oriented Application Platform INTRODUCTION Large software development organizations with softwareproductofferingsacrossmultiplemarkets andindustriesusuallyhavecorecompetencesthat underpin diverse product offerings. Identifying andformalizingthosecorecompetencesprovides development organizations with opportunities to create common application platforms to support theirproductsdevelopmenteffortsacrossmarkets and industries. Shared application platforms significantly increase reuse of software assets, reduce time to market and cost, and improve software quality. Service orientation offers additional benefits including enterprise-wide standardized reusable software assets, increased interoperability, and ease of extension, evolution and adoption of new services-based functionalities and features. Specifying the requirements, and in particular the non-functional requirements (NFRs) for an application platforms is however challenging. Application platforms aim to support a large number of domain specific applications in meet- ing functional and non-functional requirements. While common functionality can be identified from shared core competencies across different domain applications, the non-functional require- mentsacrossdomainscanstillvarygreatly,which makesithardtopindownwhichNFRsacommon platformshouldsupport.Inindustrialsettings,the following main challenges have been identified (Song et al., 2009): Varying domain-specific needs: Different application domains give rise to different NFRs. For example, a solution system that supports au- tomation in manufacturing, which often requires meeting tight hard real time constraints, and a solution system that provides building security in factories, where real time requirements are much less demanding, have quite distinct NFRs, even if both systems involve much of the same control functionalities. Varying deployment configurations and load conditions: Solution systems can be de- ployed and operated in different configurations and under different load conditions. For example, a common platform may need to support an ap- plication that is deployed and operated as an em- bedded standalone system responding to several hundred events per minute. The same platform may however also need to support an application deployed as an integrated multi-site system of dedicatedserversrespondingtotensofthousands events per second. What non-functional platform requirements should be specified so that once implemented the platform can be deployed on an embedded standalone system or on dedicated servers, and respond well for both types of load- ing conditions? Terminology and metrics mismatch: Dur- ing the development of NFRs for the platform, requirements analysts must deal with a wide range of concepts, terminology and metrics used in different application domains. For example, in oneindustrialdomain,aperformancerequirement could be specified in events per seconds, while in anotherinalarmsperminute.Platformdevelopers musttranslatesuchdifferencesinterminologyand metrics into common platform terminology and metrics before compatible platform requirements can be specified. Dealing with NFR trade-offs: Developing an application platform in general and adopt- ing service orientation in particular requires the implementationofspecificdesignprinciples,such as modularity, loose coupling, service stateless- ness, service autonomy, service contracting, etc. (Erl, 2007), which help achieve non-functional benefits, such as reusability, interoperability, consistency and extensibility, associated with application platforms and service orientation. However implementing such design principles comes with a price and requires developers to make trade-offs with other non-functional re- quirements such as performance and increased upfront development costs. Platform developers
- 50. 26 Developing Non-Functional Requirements for a Service-Oriented Application Platform must evaluate the importance of each NFR to the success of domain application. Such evaluation determines whether the NFRs are inconsistent withservice-orienteddesignprinciples.Ifso,they must determine what trade-offs to platform NFRs and/or to NFRs of the domain application must be made, when establishing a service-oriented application platform, and when adopting the platform for domain applications. This chapter presents a systematic analysis method to support requirements analysts in deal- ing with aforementioned challenges during the development of NFRs for application platforms in the control system domain. in earlier work, the Platform NFR Developed Method (PND) (Song et al., 2009) provided guidelines for developing platform NFRs. The method presented in this chapter include the introduction of a systematic trade-off analysis by use of a goal- and scenario- oriented modeling and analysis techniques. We thus, refer to this new method as GS-PND. Introducinggoalandscenario-orientedmodel- ing affords benefits including an integrated treat- ment of quantitative (Keller, Kahn et al. 1990) and qualitative NFRs (Mylopoulos, Chung et al. 1992; Chung 1993; Chung, Nixon et al. 2000), support for different types of automated consis- tency checking across NFRs, the ability to take intoaccountalreadyexisting,aswellasanticipate futurekeyrequirementsanddesignchoicesduring the development of NFRs, as well as systematic trade-off analysis. The background section introduces industrial control systems – the domain area in which the analysis method was developed and applied, elaboratesonplatformNFRsanddiscussesrelated work. Section three presents an overview of the analysis method, illustrates the offered modeling and analysis techniques, and how these are used to represent and model the adoption of service orientation as part of the platform architecture strategy. Section four applies the analysis method by deriving platform NFRs from three industrial control system solutions. Section five discusses future trends, while section six concludes and points to future work. BACKGROUND Industrial Control Systems The Goal and Scenario-oriented Platform NFR Development Method (GS-PND) was developed while analyzing non-functional requirements of three existing industrial control systems to de- rive non-functional requirements for a common application platform. Each control system was developed for a different application domain – automationtechnology(AT),buildingtechnology (BT), and transportation technology (TT), and each system exhibits distinct NFRs. The purpose of an industrial control system is to control systems or processes in its environ- ment (Sperling and Lutz 1997; Speck 2003). Essentially, a control system continuously reads input data from a number of input sensors, and the input data is fed into controlling algorithms tocalculateappropriatecontroldata.Controldata is then sent as output to actuators, which effects appropriate physical change to the controlled system or process, which in turn is reflected in newinputdatareadfrominputsensors(seeFigure 1).Controlsystemsalsoincludeprocessestosup- portdisplayingdatacapturedandcalculatedfrom sensors, and to support user input to configure the systems and its components. Figure 1. Context diagram of control systems
- 51. 27 Developing Non-Functional Requirements for a Service-Oriented Application Platform Industrialcontrolsystemsusuallyhavealarge number of input sensors and actuators connected, requiring them to continuously read and process a large number of input data.Akey non-function- al requirement of such systems is that inputs must be processed and outputs generated under real time constraints. A key design goal of industrial control systems is therefore to achieve sufficient processing throughput of input data. For example, in one application (TT) a key throughput requirement is that the system is ca- pable of detecting, processing and responding to 3000 changes of input value on its input sensors per second, while in another one (AT) a similar non-functional requirement is to process 30,000 changes of values per second. Apart from providing sufficient processing throughput, the commercial success of an indus- trial control system however also depends on meeting other important non-functional require- ments. Developers of industrial control systems mustaddressnon-functionalrequirementssuchas cost of ownership, usability of the operators user interface,availability,reliabilityandinteroperabil- ity of the control systems, as well as reusability, scalability and flexibility to changing controlling environments and customer needs. Industrial Control systems must also often be implemented on system hardware with limited capabilities. A key concern when addressing such afore- mentioned NFRs, such as by adopting a service- oriented platform development approach, is whether hard real time constraints can be met, if all else is kept equal, and if not, what trade-offs to make. Figure2illustratestypicalinternalsandseveral quantitativecharacterizingmeasuresofindustrial control systems, using the UCM notation (Buhr & Casselman 1996). A “wiggled line” represents a control process. In the UCM notation an “x” on a wiggled line represents computational respon- sibility. In Figure 2 each “x” represents a control process steps. Boxes represent architectural elements such as applications, Operating system processes, components and the like. Together all wiggled lines and boxes in Figure 2 define a use case map (UCM).The purpose of a UCM is not to provideacompletedescriptionofacomputational process, but to support capturing at a higher level Figure 2. Anatomy of typical control system
- 52. 28 Developing Non-Functional Requirements for a Service-Oriented Application Platform of abstract essential computational structures and responsibilities. Control systems are usually client/server sys- temswhereserversareconnectedtoinputsensors and actuators, while clients provide user inter- faces to the system’s operators (Figure 2). Clients are connected to servers via a communication system. Standalone control systems combine cli- ent and server functionality in one device. Importantparametersthatcharacterizecontrol systems include the number of input sensors, and thefrequencythesemustbereadandprocessed,the number of clients each server has connected, and so forth. Figure 2 shows a typical control process thatreadsdatafromaninputsensor,performssome processing, then outputs control data as well as status information to clients. Internally, control systems maintain a data model which stores data items such as data read, alarms identified and processed,aswellasinformationaboutconnected clients. Industrial control systems typically adopt architectural features such as modularization and layering to address non-functional requirements suchasreusability,maintainabilityandextensibil- ity (Speck, 2003). Broadly speaking, the specification of non- functional requirements for industrial control systems involves several kinds of trade-offs. The number of data points and hard real time require- ments establish baseline processing throughput needs for processing input data, such as detecting and processing 3000 changes of input values per second. To address other relevant NFRs, such as usability,scalability,andinteroperabilityrequires additional system and software processes and structures which add processing overhead to the baseline. Toachieveadditionalthroughputrequirements requiresspecifyingadditionaland/ormorepower- ful processors, and more memory which however increases the cost of ownership. To reduce cost of ownership, developers must either sacrifice some relevantNFRs,orreducesystemthroughputneeds, by reducing the number of input data processing needs – the latter can for example be achieved by positioning the product in a less demanding market niche. NFRs of Platform, Platform Application and Domain Application Application platforms offer common runtime facilities and programming interfaces to applica- tion program developers. Successful application platforms are usually developed by analyzing already existing domain applications to identify common reusable functionality and features. Platform NFR specifications should thus be de- rivedfromNFRspecificationsofalreadyexisting domain applications. To specify platform NFRs, an important distinction we make is between deployed ap- plication system and application (see Figure 3). A deployed application system, or deployed application in short, is an application deployed according to one of its predefined deployment configurations. For example, consider a building security application, which can be deployed as a small standalone embedded system, for small homes, or as a larger distributed client/server system for larger office buildings.We say that the buildingsecurityapplicationhastwodeployment configurations: an embedded configuration and a client/server configuration, and that the building security application can therefore be deployed as two types of systems: an embedded system, or a client server system. Making this distinction is important, since some NFRs such as load conditions (e.g. alarms per second that must be processed), are only meaningfully defined for deployed application systems. For example, the building security ap- plicationwhendeployedasaclient/serversystem can deal with a much greater number alarms per second, than when deployed as an embedded system. According to this distinction, developing platform NFRs includes developing two types of
- 53. 29 Developing Non-Functional Requirements for a Service-Oriented Application Platform NFRs (a) the developing of NFRs that are defined independentlyofadeploymentconfiguration,and (b) developing NFRs for the deployed platforms, where the platform is deployed according to one ormorepredefineddeploymentconfigurations.In this chapter, unless indicated otherwise, we will just say platform NFR to NFRs of either type. Figure 3 further shows that a Deployment configuration is defined by one or more Deploy- ment parameters, such as number and types of Servers, number of Clients, number of input sensors, number of configurable alarms, and so forth.Deploymentparameterswhichcharacterize deployment configurations are NFRs specified for an Application. Another important distinction we make is between Quantitative and Qualitative NFRs. Dis- tinguishingbetweenQuantitativeandQualitative NFRsenablesustousedifferenttechniquesduring the development of platform NFRs. Deployment parametersandloadconditionsarebothQuantita- tive NFRs, NFRs specified in terms of countable quantities (Keller, Kahn et al. 1990; Kazman, Klein et al. 2000). In contrast to Quantitative NFRs, Qualitative NFRs are NFRs such as us- ability, security, interoperability, which are hard or impossible to formalize or count (Mylopoulos, Chung et al. 1992; Chung 1993; Chung, Nixon et al. 2000). In a subsequent section we will further seethatinthecontextofaqualitativeNFRanalysis technique,aQuantitativeNFR,suchasprocessing throughput, can also be treated as a Quality NFR. Chung (1993) suggests analyzing qualitative NFRsintotypeandtopic.AtypesuchasScalability is applied to a topic, such as System defining the qualitative NFRs Scalability of System. In Figure 3, Topic captures the fact that Qualitative NFRs are defined over Applications or Deployed Ap- plication systems (type is not separately shown). Asubsequentsectionwillfurtherclarifythediffer- encebetweenQuantitativeandQualitativeNFRs, andelaborateonothertypeandtopicdistinctions. Figure 3 indicates that the Platform defines Services.APlatformApplicationisanapplication that uses the Platform’s services. We distinguish between two types of services: Application Ser- Figure 3. Defining NFR specifications
- 54. 30 Developing Non-Functional Requirements for a Service-Oriented Application Platform vices and Implementation Services. Application services are services that can directly be used by applications to add required functionality. Imple- mentation Services are, on the other hand, similar toprogramminglibraries,andsupportimplement- ingfunctionalityofanapplication.Finally,Figure 3 also shows that migrating DomainApplications to the Platform requires migrating functionality of Domain Applications to platform Services. The structural relationships between the dif- ferent types of Applications allow us to point out an important relationship between NFRs specifications: 1. NFRsofplatformapplicationsaredependent on NFRs of the platform, since platform applications make use of platform services. 2. When developing NFRs for the platform a key success factor is that important NFRs of domain applications should as much as possible be preserved, when selected func- tionality of domain applications is migrated to make use of platform services To develop platform NFRs such that migrated domain applications retain their important NFR properties requires trade-offs, since platforms, and in particular service-oriented platforms, have distinct architectural features. The best that can usuallybeachievedistosupportretainingsomeof the important NFRs, by sacrificing less important ones. Such trade-offs could, for example, involve the development of several Platform, each result- ing from different kind of NFR trade-offs, and offering different subsets of platform Services to platform applications. Figure 3 captures such an approach by defining an association link between the Platform NFR Specification and the Services provided by the Platform. Related Work A qualitative treatment of NFRs was first sug- gested by Mylopoulos and Chung (Chung, 1993; Mylopoulos, Borgida et al. 1997; Chung, Nixon et al. 2000) who proposed a process-oriented ap- proach that treats NFRs as goals that are achieved during a requirements and architectural design modeling and analysis process. Nixon special- ized this work to specifically dealing with the performance NFR during information system design (Nixon, 1994). Nixon does however not dealwiththroughputrequirement,orwithrelating the proposed qualitative analysis to a quantitative analysis of performance. Based on Mylopoulos and Chung’s work Cai and Yu (2002) outlined an approach for dealing with the performance NFR in conjunction with Use Case Maps (UCMs) (Buhr & Casselman, 1996). UCMs are a scenario modeling approach for representing high level system structures and behaviors.Theapproachpresentedinthischapter hassimilaritieswithCaiandYu’sapproachinthat it also makes use of scenario modeling. However Cai and Yu focus on a qualitative performance analysis of architecture choices during which Scenario modeling supports capturing the results of goal-oriented reasoning and decision making. The method presented in this chapter further uti- lizes scenario modeling to support a quantitative analysis of throughput and to linking the qualita- tive and quantitative analyses of throughput via scenario models to support an integrated analysis approach. The work most closely related to GS-PND is by Pourshahid et. al. (2007). Pourshahid et al. extend the User Requirements Notation (URN) (ITU-T 2008) a recent requirements analysis and specificationstandard,thatsupportsrepresenting, capturing and analyzing qualitative NFR and linking these to UCM scenario modeling. While Pourshahid et. al. applies and extend URN to representandevaluatebusinessprocessesinorga- nizations, the GS-PND adapts and extends URN to specifically deal the development of NFRs for a control systems’ application platform. There has been much interest in recent years related to dealing with NFRs in relation to service
- 55. Another Random Document on Scribd Without Any Related Topics
- 59. The Project Gutenberg eBook of Lost Diaries
- 60. This ebook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this ebook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. Title: Lost Diaries Author: Maurice Baring Release date: April 15, 2013 [eBook #42542] Most recently updated: October 23, 2024 Language: English Credits: Produced by Marc D'Hooghe (Images generously made available by the Internet Archive - University of California) *** START OF THE PROJECT GUTENBERG EBOOK LOST DIARIES ***
- 61. LOST DIARIES BY
- 62. MAURICE BARING LONDON DUCKWORTH & GO. 3 HENRIETTA STREET, COVENT GARDEN. W.C. 1913 These "Lost Diaries" originally appeared in the Eye Witness, the New Witness, and the Morning Post; they are here reprinted by the kind permission of the Editors of those newspapers. M.B. To E.M. CONTENTS I.FROM THE DIARY OF SMITH MINOR II.FROM THE DIARY OF ISEULT OF BRITTANY
- 63. III.FROM THE DIARY OF KING COPHETUA IV.FROM THE DIARY OF FROISSART, WAR CORRESPONDENT V.FROM THE DIARY OF GEORGE WASHINGTON VI.FROM THE DIARY OF MARCUS AURELIUS VII.FROM THE DIARY OF MRS JAMES LEE'S HUSBAND VIII.FROM THE DIARY OF SHERLOCK HOLMES IX.FROM THE DIARY OF THE EMPEROR TITUS X.FROM THE DIARY OF HARRIET SHELLEY XI.FROM THE JOURNAL INTIME OF THE EMPEROR TIBERIUS XII.FROM THE DIARY OF ŒDIPUS REX XIII.FROM THE DIARY OF WILLIAM THE CONQUEROR XIV.FROM THE DIARY OF MARY, MRS JOHN MILTON (NÉE POWELL) XV.FROM THE DIARY OF MARK ANTONY XVI.FROM THE DIARY OF IVAN THE TERRIBLE XVII.FROM THE PRIVATE LOG OF CHRISTOPHER COLUMBUS XVIII.FROM THE DIARY OF THE MAN IN THE IRON MASK XIX.FROM THE DIARY OF AN ENGLISH GOVERNESS RESIDING IN PARIS DURING THE FRENCH REVOLUTION XX.FROM THE DIARY OF HAMLET, PRINCE OF DENMARK, DURING HIS STAY AT ENGLAND, WHITHER HE WAS SENT TO STUDY AT THE UNIVERSITY AT OXFORD, UNDER THE SPECIAL CARE OF POLONIUS I. FROM THE DIARY OF SMITH MINOR ST JAMES'S SCHOOL, September, 1884.
- 64. Sunday.—Yesterday afternoon was a half-holiday we were playing prisoners base exept four boys who were gardening with Mrs Wickham. Peel hit Bell by mistake with all his force with the pic-axe on Bell's wrist. Sunday.—Last night their was a total eclipse of the moon. We all stayed up to see it, it looked very funny. There was a shadow right over the moon. We began football yesterday. At tea the Head asked if any one had eaten chesnuts in the garden. Simes major said yes at once. Then the Head said he was sure others had too. Then Wilson stood up and after a time 7 chaps stood up. Then the Head said it would be the worse for those who didn't stand up as he knew who the culprets were. I hadn't eaten any but Anderson had given me a piece off his knife so I stood up two. The Head said we should all have two hours extra work. He was very waxy he said we were unreliabel. Sunday.—Yesterday we were all photografed. Simes laughed and was sent to bed for misbehavier. Pork's people came down yesterday. We call Pork Hogg because he's dirty. He showed them over the school, and turned on the electrik light. The Head was looking through the curtain in the library and saw this. When his people went away Hogg was sent for and he is to be swished to- morrow. We told him he would get it hot and he blubbed. Sunday.—We went for the choir expedition last Thursday. It was great fun. We went to London by the 8.35 train. We missed the train!! So we went by the 8.53. We got to London at 10.15. We then went to the mint we first saw the silver melted and made into thick tablets, then we saw it rolled out into thin bits then cut stamped and weighed then we had a very good luncheon and went to the Tower. We first saw the Bloody Tower were the little Princes were murdered then we saw the jewels the warder said the Queen's crown was worth over £1,000,000 then we saw the armory and the torture's, then we went to Madame Tussaus it is quite a large building now with a large stairkes then we had tea and went home.
- 65. Sunday.—I said to Anderson that we might start an aquarium but he said Ferguson had one last term and that it would be copying, he said he hates copying. So we'll have a menagery instead with lizards. Sunday.—The lizard is very well indeed and has eat a lot of worms. White cheeked Jones ma and Mac said they must fight it out in the play-room in the hour. They fought with gloves. White gave him a bloody nose. We had a very good game of football yesterday. Williams and Pierce which left last term came from Eton to play. Pierce changed in my room. He says you don't say squit at Eton and you say Metutors not My tutors. The fireworks are in a week. Saturday.—There was no work this morning as it was "All Saints day." There was a football matsh against another scool—Reynolds'. We won by three goals and three tries. There was an awful row on Wednesday. Anderson cut off a piece of his hair. Mac nabbed it, and he said he hadn't as he was afraid of the consequenses. Then a search was made and they fond a piece of hair in his drawer. Mac told him he would find himself in Queer Street and Colly said when he was writing home on Sunday that he had better add that he was a liar. Nothing hapened till Monday and Anderson thought it was forgoten but at reading over when the 3nd Div came up the Head said: "Anderson I am astounded at you; you are a shufler and worse." He lost 50 marks and was swished. He would get 20 the head said if he did it again and he would be turned out of the choir. Sunday.—When Colly was out of the room in Set 3 this morning Mason said he wouldn't sneak about me talking if I didn't sneak about him so I talked. When Colly came back Mason sneaked, Please sir will you ask Smith not to talk. I had to stand on the stool of penitence. We are going to put Mason in Coventry because he always sneaks just after he has sworn he won't. Last night we all had to play our pieces in the Drawing Room. I played a duet with Wilson mi. Astley played best. When everybody had played their pieces we had ginger beer and biscuits and went to bed. Fish played worst (on the violin).
- 66. Sunday.—We had fireworks on the 5th romman candles rockets crackers squibs and a set piece with God Save the Queen on it. They came from Broks who makes the fireworks at the Crystal palace we burnt a man in effigee a man with collars and an axe. The Head said he wouldn't say who it was meant to be but that all true Englishmen who were not traiters could guess. Rowley said it was meant to be Mister Gladstone but he only said this to get a rise out of Pork whose paters a liberal. It was reelly Guy Fawks then Pork said Anderson's father was a liberal too and Anderson hit him in the eye. The Head hates liberals. There was another row this week; Christy said something to Broadwood at breakfast that the poridge was mighty good. That was copying Anderson who learnt it from his mater who is a Yankee. Mac asked him what he'd said. He said he'd said the porridge was good. Mac asked Is that all you've said. Christy got very red and looked as if he was going to blub and said that was all. Very well said Mac Come afterwards. Mac reported him for telling bungs. He wasn't swished as its his first term: but Mac told him he was making himself very unpopular. On Tuesday Fatty the butler came into the 3rd Div scoolroom with a message. Some one said in a wisper Hullo Fatty. Mac nabbed it and said who said that nobody answered then Mac said he knew it was Middleton mi as he had recognised his voice Middleton swore he hadn't said a word but he was reported and swished he still swears he didn't say Fatty and I believe it was Pork. The other day at French Campbell went up to Colly and asked him what was wrong with les tables it had a pencil cross on it. Colly said that when he'd corrected it there was no S there. Campbell swore their was. Colly held the paper to the window and said he saw the ink of the S was fresh, then Christy began to blub and said he had done it and Colly said it was a for jerry and wrote forjer in white chalk on his back and said he would tell the chaps in the first Div but he didn't report him to the Head which was awfully decent of him becaus Christy is a new chap.
- 67. Sunday.—Trials are nearly over. We had Latin G and Greek G paper yesterday (set by the Head). There are only two more papers geography and Latin verse. The Consert is on Saturday. Pork's sister is called Jane!! Campbell saw it on the seel of a letter he got. His people were coming for the Consert but he's written to tell them not to as we told him the Head thought liberals worse than thieves. II FROM THE DIARY OF ISEULT OF BRITTANY May 1.—Mamma sent me up a message early this morning to say that I was to put on my best white gown with my coral necklace, as guests were expected. She didn't say who. Nurse was in a fuss and pulled my hair when she did it, and made my face very sore by scrubbing it with pumice-stone. I can't think why, as there was no hurry. I came down punctually at noon. Mamma and papa were sitting in the hall, waiting. Fresh rushes were strewn on the floor. I was told to get out my harp, and to sit with my back to the light. I hadn't practised for weeks, and I can only play one song properly, "The Mallard," a Cornish song. When I told mamma that was the only song I knew, she said I was on no account to mention it, if I was asked to play; but I was only to play Breton songs. I said I didn't know any. She said that didn't matter; but that I could sing anything I knew and call it a Breton song. I said nothing, but I thought, and I still think, this was dishonest. Besides the only songs that I know are quite new. The stable people whistle them, and they come from Rome. We waited a long time. Papa and mamma were both very fidgety and mamma kept on pulling me about, and telling me that my hair was badly done and that she could see daylight between the pleats
- 68. of my frock. I nearly cried and papa said: "Leave the dear child alone; she's very good." After we'd been waiting about twenty minutes, the trumpets sounded and Morgan, the seneschal, walked in very slowly, and announced: "Sir Tristram of Lyoness." Rather an oldish man walked in, with a reddish beard, and many wrinkles. One of his front teeth was broken and the other was black. He was dressed in a coat of mail which was too tight for him. He had nice eyes and seemed rather embarrassed. Mamma and papa made a great fuss about him and brought me forward and said: "This is our daughter Iseult," and mamma whispered to me: "Show your hands." I didn't want to do this, as nurse had scrubbed them so hard that they were red. Sir Tristram bowed deeply, and seemed more and more embarrassed. After a long pause he said: "It's a very fine day, isn't it?" Before I had time to answer, mamma broke in by saying: "Iseult has been up since six with the falconers." This wasn't true and I was surprised that mamma should be so forgetful. I hadn't been out with the hawkers for weeks. Then dinner was served. It lasted for hours I thought, and the conversation flagged terribly. Kurneval, Sir Tristram's Squire, had twice of everything and drank much more cider than was good for him. After dinner, mamma told me to fetch my harp and to sing a Breton song. I was just going to say I didn't know one, when she frowned at me so severely that I didn't dare. So I sang the Provençal orchard song about waking up too early that Kerodac the groom taught me. Sir Tristram said: "Charming, charming, that's German, isn't it; how well taught she is. I do like good singing." Then he yawned, although he tried not to, and papa said he was sure Sir Tristram was tired, and that he would take him to see the stables. Sir Tristram then became quite lively and said he would be delighted. When they'd gone, mamma scolded me, and said that I had behaved like a ninny and that she didn't know what our guests
- 69. would think of me. It seemed to me we only had one guest; but I didn't say so. Then she told me to go and rest so as to be ready for dinner. I forgot to say that just as Sir Tristram was going out of the room he said to papa: "Your daughter's name is—er?" and papa said, "Yes, Iseult, after her aunt." And Sir Tristram said: "Oh! what a pretty name!" May 6.—They've been here a week now and I haven't seen much of them; because Sir Tristram has been riding with papa nearly all day, and every day. But every day after dinner mamma makes me sing the Provençal song, and every time I sing it, Sir Tristram says: "Charming, charming, that's German, isn't it?" although I've already told him twice now that it isn't. I like Sir Tristram, only he's very silent, and after dinner he becomes sleepy directly, just like papa. May 7.—I've had a most exciting day. Papa and mamma sent for me and when I came into the room they were both very solemn and said they had something particular to say to me. Then mamma cried and papa tried to soothe her and said: "It's all right, it's all right," and then he blurted out that I was to marry Sir Tristram next Wednesday. I cried, and papa cried, and mamma cried, and then they said I was a lucky girl, and mamma said that I must see about my clothes at once. May 8.—Nurse is in a fearful temper. She says we shall never be ready by Wednesday and that it's more than flesh and blood can stand to worrit folks like this. But mamma is in the best of tempers. Sir Tristram has gone away—to stay with some friends—he is coming back on Tuesday night. My wedding gown is to be made of silver with daisies worked on it. The weavers are working day and night, but most of the stuff is old. It belonged to mamma. I do think they might have given me a new gown. Blanche had a new one when she was married. May 12.—The wedding went off very well. I had four maidens and four pages. After Mass, we had a long feast. Papa made a speech
- 70. and broke down, and Tristram made a speech and got into a muddle about my name, and everybody was silent. Then he said I had beautiful hands and everybody cheered. After supper we were looking out on the sea, and just as Tristram was becoming talkative I noticed that he wore another ring besides his wedding ring, a green one, made of jasper. I said, "What a pretty ring! Who gave it you?" He said, "Oh, a friend," and changed the subject. Then he said he was very tired and went away. May 13.—It's the 13th and that's an unlucky number. Nurse said that no child of hers should marry in May, so I suppose that's what brought it about. In any case Tristram, who has been very gloomy ever since he's been here, has got to go and fight in a tournament. He says he won't be away long and that there's no danger; not any more than crossing the sea in an open boat, which I do think is dangerous. He starts to-morrow at dawn. May 14.—Nothing particular. May 15.—No news. May 16.—Kurneval arrived this evening. He says that Tristram was slightly wounded; but would be all right in a day or two. I am very anxious. May 17.—Tristram was brought back on a litter in the middle of the night. He has been wounded in the arm. The doctors here say he was bandaged wrong by the local doctor. They say he is suffering from slight local pain. Kurneval says the horrid henchman hit his arm as hard as he could with a broad sword. Papa and mamma arrive to- morrow with the doctor. Tristram insists on sleeping out of doors on the beach. The doctor says this is a patient's whim and must be humoured. I'm sure it's bad for him, as the nights are very cold. July 1.—I've been too busy to write my diary for weeks. Tristram is still just the same. The doctors say there is no fear of immediate change. August 10.—Mamma says the Queen of Cornwall (whose name is Iseult the same as mine) is coming for a few days, with her husband
- 71. and some friends. I do think it's very inconsiderate, considering how full the house is already; and what with Tristram being so ill—and insisting on sleeping on the beach—it makes it very difficult for every one. September 1.—Papa went out to shoot birds with his new cross-bow; but he came back in a bad temper as he'd only shot one, and a hen. Tristram is no better. He keeps on talking about a ship with a black sail. September 19.—To-day I was on the beach with Tristram and he asked me if I saw a ship. I said I did. He asked me if the sail was black, and as the doctor had told me to humour him, I said it was. Upon which he got much worse, and I had to call the doctors. They said he was suffering from hypertrophy of the sensory nerves. September 20.—Tristram unconscious. The Queen of Cornwall just arrived. Too busy to write. III FROM THE DIARY OF KING COPHETUA Cophetua Castle, May 3.—We had to be married in May, after all. It was a choice between that and being married on a Friday, and Jane would not hear of that, so I gave in. Poor dear Mamma relented at the end and came to the wedding. On the whole she behaved with great restraint. She could not help saying just a word about rash promises. Jane looked exceedingly beautiful. I felt very proud of her. I regret nothing. We start for Italy to-morrow. We are to visit Milan, Florence-and Rome. Jane is looking forward to the change. Dijon, May 6.—We decided to break the journey here: but we shall probably start again to-morrow, as Jane is extremely dissatisfied
- 72. with the Inn, the Lion d'Or. I, of course, chose the best. But she says she found a spider in her bedroom; she complained that the silver plates on which dinner was served were not properly cleaned; that the veal was tough, and that we had been given Graves under the guise of Barsac. All these things seem to me exceedingly trivial; but Jane is particular. In a way it is a good thing, but considering her early upbringing and her former circumstances, I confess I am astonished. Lyons, May 12.—I shall be glad when we get to Italy. Jane becomes more and more fastidious about Inns. She walked out of four running, here. I was imprudent enough to say that Mamma had a vassal who was a distant connection of the Sieur Jehan de Blois and Jane insisted on my paying him a visit and asking him to lodge us, telling him who we are, as we are travelling incognito as the Baron and Baroness of Wessex. This put me in a very awkward position, as I don't know him. I did it, however, and Jane came with me. I have seldom felt so awkward, but really he could not have made things easier. He was tact itself, and while respecting our incognito, he treated us with the utmost consideration. He was most kind. Jane made me a little uncomfortable by praising a fine crystal goblet encrusted with emeralds. Sieur Jehan was of course obliged to offer it her, and, to my vexation, she accepted it. Avignon, May 20.—Jane finds our incognito more and more irksome. I was looking forward to a real quiet holiday, where we could get away from all fuss and worry, and all the impediments of rank and riches. I wanted to pretend we were poor for a while. To send on the litters with the oxen, the horses, and the baggage, and to ride on mules—as soon as we had reached the South—but Jane would not hear of this. She said she had had enough of poverty without playing at it now. This is of course quite true, but I wish she wouldn't say such things before people. It makes one so uncomfortable. Here she has insisted on our staying with the Pope, which may put me in a very awkward position with regard to several of our allies in Italy. He has been, however, most gracious. Jane is very impulsive at times. She insisted on our making an expedition to the Bridge here, by
- 73. moonlight, and dancing on it. She kicked off her shoes and danced barefooted; I asked her not to do this, whereupon she said: "If the courtiers hadn't praised my ankles you would never have married me and what's the use of having pretty ankles, if nobody can see them!" I shall be glad when we get to Italy. I am determined to preserve a strict incognito, once we are across the frontier. Turin, June 10.—It has poured with rain every day since we crossed the frontier, and Jane won't believe that it is ever fine in Italy. It is very cold for the time of year, and the people here say that there has not been such a summer for thirty years. Every time I mention the blue sky of Italy Jane loses her temper. She spends all her time at the goldsmiths' shops and at the weavers'—I am afraid she is extravagant: and her taste in dress is not quite as restrained as I could wish. Of course it doesn't matter here, but at home it would shock people. For instance, last night she came down to supper dressed as a Turkish Sultana in pink trousers and a scimitar, and without even a veil over her face. When I remonstrated she said men did not understand these things. Milan, June 15.—It is still raining. Jane refused to look at the Cathedral and spends her whole time at the merchants' booths as usual. To-day I broached the incognito question. I suggested our walking on foot, or perhaps riding on mules, to Florence. Jane, to my great surprise, said she would be delighted to do this, and asked when we were to start. I said we had better start the day after to- morrow. I am greatly relieved. She is really very sensible, if a little impulsive at times; but considering her early life, it might be much worse. I have much to be thankful for. She is greatly admired, only I wish she would not wear such bright colours. Florence, June 20.—It has been a great disappointment. Just as we were making preparations to start entirely incognito—Jane had even begged that we should walk on foot the whole way and take no clothes with us—a messenger arrived from the Florentine Embassy here, saying that the Duke of Florence had heard of our intended visit and had put a cavalcade of six carriages, fifty mules, seven
- 74. litters, and a hundred men-at-arms at our disposal. How he could have heard of our intention I don't know! Jane was bitterly disappointed. She cried, and said she had been looking forward to this walking tour more than to anything else. But I managed to soothe her, and she eventually consented to accept the escort of the Duke. It would have been impossible to refuse. As it was, we were very comfortable. We stopped at Bologna on the way, and Jane insisted on going to the market and buying a sausage. She tried to make me taste it, but I cannot endure the taste of garlic. At Florence we were magnificently received, and taken at once to the Palace—where the rooms are very spacious. Jane complains of the draughts and the cold. It is still pouring with rain. There is a very fine collection of Greek statues to be seen here, but Jane takes no interest in these things. The first thing she did was to go to the New bridge, which is lined with goldsmiths' shops on both sides and to spend a great deal of money on perfectly useless trinkets. She says she must have some things to bring back to my sisters. This was thoughtful of her. The Duke is going to give a great banquet in our honour on Tuesday next. June 23.—The feast is to-night. The gardens have been hung with lanterns: a banquet has been prepared on a gigantic scale. Five hundred guests have been bidden. Jane was greatly looking forward to it and lo and behold! by the most evil mischance a terrible vexation has befallen us. A courier arrived this morning, bearing letters for me, and among them was one announcing the death of the Duke of Burgundy, who is my uncle by marriage. I told Jane that of course we could not possibly be present at the banquet. Jane said that I knew best, but that the Duke would be mortally offended by our absence, since he had arranged the banquet entirely for us and spent a sum of 10,000 ducats on it. It would be, she pointed out— and I am obliged to admit she is right—most impolitic to annoy the Duke. After an hour's reflection I hit on what seemed to me an excellent solution—that we should be present, but dressed in mourning. Jane said this was impossible as she had no black clothes. Then she suggested that I should keep back the news until to-
- 75. morrow, and if the news were received in other quarters, deny its authenticity, and say we had a later bulletin. This on the whole seemed to be the wisest course. As the etiquette here is very strict and the Dowager Duchess is most particular, I pray that Jane may be careful and guarded in her expressions. June 25.—My poor dear mother was right after all. I should have listened, and now it is too late. The dinner went off very well. We sat at a small table on a raised dais. Jane sat between the Duke and the Prime Minister and opposite the Dowager Duchess. There was no one at the table, except myself, under sixty years of age, and only the greatest magnates were present. Jane was silent and demure and becomingly dressed. I congratulated myself on everything. After the banquet came the dance, and Jane took part with exquisite grace in the saraband: she observed all the rules of etiquette. The Dowager Duchess seemed charmed with her. Then later came supper, which was served in a tent, and which was perhaps more solemn than everything. When the time came to lead Jane to supper she was nowhere to be found. Outside in the garden the minor nobles were dancing in masks, and some mimes were singing. We waited, and then a message came that the Queen had had a touch of ague and had retired. The supper went off gloomily. At the close an enormous pie was brought in, the sight of which caused a ripple of well-bred applause. "Viva Il Re Cophetua" was written on it in letters of pink sugar. It was truly a triumph of culinary art. The mime announced that the moment had come for it to be cut, and as the Grand Duke rose to do this the thin crust burst of itself, and out stepped Jane, with no garments beside her glorious dark hair! She tripped on to the table, and then with a peal of laughter leapt from it and ran into the garden, since when she has not been heard of! My anguish and shame are too great for words. But the Duke and the Dowager have been most sympathetic. June 26.—Jane has fled, and my jewels as well as hers are missing. It is suspected that the attaché at the Florentine Embassy at Milan is at the bottom of the conspiracy, for Jane herself had a good heart.
- 76. IV FROM THE DIARY OF FROISSART, WAR CORRESPONDENT Parys, The Feast of the Epiphanie.—The astrologers say there will be plenty-full trouble in Normandy, in the spring. June 10.—To dyner with the Cardinall of Piergourt to meet the gentyll King of Behayne and the Lorde Charles, his son. The Cardinall sayd neither the Kynge of Englande nor the Frenche Kynge desire warre, but the honour of them and of their people saved, they wolde gladly fall to any reasonable way. But the King of Behayne shook his heade and sayd: "I am feare I am a pesymyste," which is Almayne for a man who beholds the future with no gladde chere. June 20.—The great merchaunt of Araby, Montefior, says there will be no warre. He has received worde from the cytie of London, and his friends, great merchaunts all, and notably, Salmone and Glukstyn, sayd likewise that there will be no warre. June 30.—The currours have brought worde home, the Kynge of Englande was on the see with a great army, and is now a lande in Normandy. Have received faire offers for chronycles of the warre from London, Parys, and Rome; they offer three thousand crounes monthly, payeing curtesly for all my expenses. Have sayd I will gladly fall to their wish. July 1.—Trussed bagge and baggage in great hast and departed towarde Normandy, the seat of warre. July 2.—Ryde but small journeys, and do purpose, being no great horseman, every time I have to ryde a horse, to add three crounes to the expenses which my patrons curtesly pay.
- 77. Take lodgynges every day bytwene noone and thre of the clocke. Finde the contrey frutefull and reasonably suffycent of wyne. July 3, Cane.—A great and ryche town with many burgesses, crafty men. They solde wyne so deare that there were no byers save myself who bought suffycent and added to the lyste which my patrons curtesly pay. July 4, Amyense.—Left Cane and the englysshmen have taken the toune and clene robbed it. Right pensyve as to putting my lyfe in adventure. Sir Godmar de Fay is to kepe note of the chronyclers and he has ordayned them to bring him their chronycles. He has curtesly made these rules for the chronyclers. Chronyclers may only chronycle the truth. Chronyclers may not chronycle the names of places, bridges, rivers, castels where batayles happen—nor the names of any lordes, knyghtes, marshals, erles, or others who take part in the batayle: nor the names of any weapons or artillery used, nor the names or numbers of any prisoners taken in batayle. Thanks to Sir Godmar de Fay the chronycler's task has been made lyghter. July 6, Calys.—The chronyclers have been ordayned by Sir Godmar de Fay to go to Calys. There are nine chronyclers. One is an Alleymayne, who is learned in the art of warre, one is a Genowayes, and one an Englysshman, the rest are Frenche. The cytie of Calys is full of drapery and other merchauntdyse, noble ladyes and damosels. The chronyclers have good wyl to stay in the cytie. July 7.—Sir Godmar de Fay has ordayned all the chronyclers to leave the cytie of Calys and to ride to a lytell town called Nully, where there are no merchauntdyse, and no damosels, nor suffycent of wyne. The chronyclers are not so merrie as in the cytie of Calys. July 9.—Played chesse with the Genowayse and was checkmate with a bishop.
- 78. August 6.—The chronyclers are all pensyve. They are lodged in the feldes. There has fallen a great rayne that pours downe on our tents. There is no wyne nor pasties, nor suffycent of flesshe, no bookes for to rede, nor any company. Last nyghte I wrote a ballade on Warre, which ends, "But Johnnie Froissart wisheth he were dead." It is too indiscrete to publysh. I wysh I were at Calys. I wysh I were at Parys. I wysh I were anywhere but at Nully. August 23.—At the Kynge's commandment the chronyclers are to go to the fronte. August 25, Friday.—The Kynge of Englande and the French Kynge have ordayned all the business of a batayle. I shall watch it and chronycle it from a hill, which shall not be too farre away to see and not too neare to adventure my lyfe. August 26.—I rode to a windmill but mistooke the way, as a great rayne fell, then the eyre waxed clere and I saw a great many Englyssh erls and Frenche knyghtes, riding in contrarie directions, in hast. Then many Genowayse went by, and the Englysshmen began to shote feersly with their crossbowes and their arowes fell so hotly that I rode to a lytell hut, and finding shelter there I wayted till the snowe of arowes should have passed. Then I clymbed to the top of the hill but I could see lytell but dyverse men riding here and there. When I went out again, aboute evensong, I could see no one aboute, dyverse knyghtes and squyers rode by looking for their maisters, and then it was sayd the Kynge had fought a batayle, and had rode to the castell of Broye, and thence to Amyense. August 30.—The chronyclers have been ordayned to go to Calys, whereat they are well pleased save for a feare of a siege. The chronyclers have writ the chronycle of the Day of Saturday, August 26. It was a great batayle, ryght cruell, and it is named the batayle of Cressey. Some of the chronyclers say the Englysshmen discomfyted the French; others that the King discomfyted the Englysshe; but the
- 79. Englysshmen repute themselves to have the victorie; but all this shall be told in my chronycle, which I shall write when I am once more in the fayre cytie of Parys. It was a great batayle and the Frenche and the Englysshe Lordes are both well pleased at the feats of arms, and the Frenche Kynge, though the day was not as he wolde have had it, has wonne hygh renowne and is ryght pleased— likewise the Englysshe Kynge, and his son; but both Kynges have ordayned the chronyclers to make no boast of their good adventure. August 30.—The Kynge of Englande has layd siege to Calys and has sayd he will take the towne by famysshing. When worde of this was brought to the chronyclers they were displeased. It is well that I have hyd in a safe place some wyne and other thynges necessarie. Later.—All thynges to eat are solde at a great pryce. A mouse costs a croune. August 31.—All the poore and mean people were constrained by the capture of Calys to yssue out of the town, men, women, and children, and to pass through the Englysshe host, and with them the poore chronyclers. And the Kynge of Englande gave them and the chronyclers mete and drinke to dyner, and every person ii d. sterlying in alms. And the chronyclers have added to the lyst of their costs which their patrons curtesly pay: To loss of honour at receiving alms from an Englysshe Kynge, a thousand crounes. V FROM THE DIARY OF GEORGE WASHINGTON WRITTEN WHEN A SCHOOLBOY Bridges Creek, 1744, September 20.—My mother has at last
- 80. consented to let me go to school. I had repeatedly made it quite plain to her that the private tuition hitherto accorded to me was inadequate; that I would be in danger of being outstripped in the race owing to insufficient groundwork. My mother, although very shrewd in some matters, was curiously obstinate on this point. She positively declined to let me attend the day-school, saying that she thought I knew quite enough for a boy of my age, and that it would be time enough for me to go to school when I was older. I quoted to her Tacitus' powerful phrase about the insidious danger of indolence; how there is a charm in indolence—but let me taste the full pleasure of transcribing the noble original: "Subit quippe etiam ipsius inertiæ dulcedo: et invisa primo desidia postremo amatur"; but she only said that she did not understand Latin. This was scarcely an argument, as I translated it for her. I cannot help thinking that there was sometimes an element of pose in Tacitus' much-vaunted terseness. September 29.—I went to school for the first time to-day. I confess I was disappointed. We are reading, in the Fourth Division, in which I was placed at my mother's express request, Eutropius and Ovid; both very insipid writers. The boys are lamentably backward and show a deplorable lack of interest in the classics. The French master has an accent that leaves much to be desired, and he seems rather shaky about his past participles. However, all these things are but trifles. What I really resent is the gross injustice which seems to be the leading principle at this school—if school it can be called. For instance, when the master asks a question, those boys who know the answer are told to hold up their hands. During the history lesson Henry VIII. was mentioned in connection with the religious quarrels of the sixteenth century, a question which, I confess, can but have small interest for any educated person at the present day. The master asked what British poet had written a play on the subject of Henry VIII. I, of course, held up my hand, and so did a boy called Jonas Pike. I was told to answer first, and I said that the play was in the main by Fletcher, with possible later interpolations.
- 81. The usher, it is scarcely credible, said, "Go to the bottom of the form," and when Jonas Pike was asked he replied, "Shakespeare," and was told to go up one. This was, I consider, a monstrous piece of injustice. During one of the intervals, which are only too frequent, between the lessons, the boys play a foolish game called "It," in which even those who have no aptitude and still less inclination for this tedious form of horse-play, are compelled to take part. The game consists in one boy being named "it" (though why the neuter is used in this case instead of the obviously necessary masculine it is hard to see). He has to endeavour to touch one of the other boys, who in their turn do their best to evade him by running, and should he succeed in touching one of them, the boy who is touched becomes "it" ipso facto. It is all very tedious and silly. I was touched almost immediately, and when I said that I would willingly transfer the privilege of being touched to one of the other boys who were obviously eager to obtain it, one of the bigger boys (again Jonas Pike) gave me a sharp kick on the shin. I confess I was ruffled. I was perhaps to blame in what followed. I am, perhaps, inclined to forget at times that Providence has made me physically strong. I retaliated with more insistence than I intended, and in the undignified scuffle which ensued Jonas Pike twisted his ankle. He had to be supported home. When questioned as to the cause of the accident I regret to say he told a deliberate falsehood. He said he had slipped on the ladder in the gymnasium. I felt it my duty to inform the head-master of the indirect and unwilling part I had played in the matter. The head master, who is positively unable to perceive the importance of plain-speaking, said, "I suppose you mean you did it." I answered, "No, sir; I was the resisting but not the passive agent in an unwarrantable assault." The result was I was told to stay in during the afternoon and copy out the First Eclogue of Virgil. It is characteristic of the head master to choose a feeble Eclogue of Virgil instead of one of the admirable Georgics. Jonas Pike is to be flogged, as soon as his foot is well, for his untruthfulness.
- 82. This, my first experience of school life, is not very hopeful. October 10.—The routine of the life here seems to me more and more meaningless. The work is to me child's play; and indeed chiefly consists in checking the inaccuracies of the ushers. They show no gratitude to me—indeed, sometimes the reverse of gratitude. One day, in the English class, one of the ushers grossly misquoted Pope. He said, "A little knowledge is a dangerous thing." I held up my hand and asked if the line was not rather "A little learning is a dangerous thing," adding that Pope would scarcely have thought a little knowledge to be dangerous, since all knowledge is valuable. The usher tried to evade the point by a joke, which betrayed gross theological ignorance. He said: "All Popes are not infallible." One of the boys brought into school a foolish toy—a gutta-percha snake that contracts under pressure and expands when released, with a whistling screech. Jonas Pike, who is the most ignorant as well as the most ill- mannered of all the boys, suggested that the snake should be put into the French master's locker, in which he keeps the exercises for the week. The key of the locker is left in charge of the top boy of the class, who, I say it in all modesty, is myself. Presently another boy, Hudson by name, asked me for the key. I gave it to him, and he handed it to Pike, who inserted the snake in the locker. When the French master opened the locker the snake flew in his face. He asked me if I had had any hand in the matter. I answered that I had not touched the snake. He asked me if I had opened the locker; I, of course, said "No." Questioned further as to how the snake could have got there, I admitted having lent the key to Hudson, ignorant of any ulterior purpose. In spite of this I was obliged, in company with Pike and Hudson, to copy out some entirely old-fashioned and meaningless exercises in syntax. October 13.—A pretty little episode happened at home to-day. The gardener's boy asked me if he might try his new axe on the old cherry-tree, which I have often vainly urged mother to cut down. I
- 83. said, "By all means." It appears that he misunderstood me and cut down the tree. My mother was about to send him away, but I went straight to her and said I would take the entire responsibility for the loss of the tree on myself, as I had always openly advocated its removal and that the gardener's boy was well aware of my views on the subject. My mother was so much touched at my straightforwardness that she gave me some candy, a refreshment to which I am still partial. Would that the ushers at school could share her fine discrimination, her sound judgment, and her appreciation of character. VI FROM THE DIARY OF MARCUS AURELIUS Rome. The Ides of March.—It is curious that Julius Cæsar should have considered this date to be unlucky! It was on that—for him auspicious—date that he was for ever prevented from committing the egregious folly of accepting the crown of Rome. A king of Rome is an unthinkable thing! An emperor of the Roman Empire is, of course, a very different matter. April 1.—Faustina, in accordance with some ridiculous tradition, committed a grossly undignified act. She came into my study, the third hour—my busiest time, and asked me to lend her the memoirs of Remus in the Wolf's Lair. I spent a fruitless half-hour in search of the book. It then occurred to me that the whole matter was a jest— in the very worst taste, since both my secretaries were present—and I regret to say they smiled. April 6.—Went to the games, in company with Faustina and Commodus. Commodus, as usual, too exuberant in the manner of his applause. I am all in favour of his applauding. The games are not
- 84. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com