DOCSLIB.ORG

Object- Oriented Software Composition

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Object- Oriented Software Composition Oscar Nierstrasz and Dennis Tsichritzis, Object-Oriented Software Composition, Prentice Hall, 1995. Reproduced with the permission of the Publisher, Prentice Hall (a Pearson Education company). This work is protected by copyright and may not be reproduced other than when downloaded and viewed on a single Central Processor Unit (CPU) for private use only. It is not otherwise to be reproduced or transmitted or made available on a network without prior written permission of Prentice Hall. All other rights reserved. Object- Oriented Software Composition EDITED BY Oscar Nierstrasz UNIVERSITY OF BERNE AND Dennis Tsichritzis UNIVERSITY OF GENEVA First published 1995 by Prentice Hall International (UK) Ltd Campus 400, Maylands Avenue Hemel Hempstead Hertfordshire, HP2 7EZ A division of Simon & Schuster International Group © Prentice Hall 1995 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording or otherwise, without prior permission, in writing, from the publisher. For permission within the United States of America contact Prentice Hall Inc., Englewood Cliffs, NJ 07632 Printed and bound in Great Britain by T.J. Press (Padstow) Ltd, Padstow, Cornwall. Library of Congress Cataloging-in-Publication Data Object-oriented software composition / edited by Oscar Nierstrasz and Dennis Tsichritzis. p. cm.—(The Object-oriented series) Includes bibliographical references and index. ISBN 0-13-220674-9 1. Object-oriented programming (Computer science) I. Nierstrasz Oscar Marius, 1957- . II. Tsichritzis, Dionysios C. III. Series: Prentice-Hall object-oriented series. QA76.64.0277 1995 005.1'1—dc20 95-7616 CIP British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library ISBN: 0-13-220674-9 Contents Contributors ix Foreword xi Akinori Yonezawa Preface xiii Oscar Nierstrasz and Dennis Tsichritzis PART I Introduction 1 1 Component-Oriented Software Technology 3 Oscar Nierstrasz and Laurent Dami 1.1 Introduction 3 1.2 Objects vs. Components 7 1.3 Technical Support for Components 9 1.4 Component Engineering 20 1.5 Conclusions 24 PART II Concurrency and Distribution 29 2 Concurrency in Object-Oriented Programming Languages 31 Michael Papathomas 2.1Introduction 31 2.2 Design Space 33 2.3 Criteria for Evaluating Language Design Choices 43 2.4 Exploring the Language Design Space 49 2.5 Conclusion 63 vi Contents 3 Interoperation of Object-Oriented Applications 69 Dimitri Konstantas 3.1Reusing Objects from Different Environments 69 3.2 Procedure-Oriented Interoperability 71 3.3 Object-Oriented Interoperability 73 3.4 Comparison of Interoperability Support Approaches 75 3.5 Interface Bridging — Object-Oriented Interoperability 76 3.6 Interface Adaption 81 3.7 Object Mapping 87 3.8 Conclusions and Research Directions 90 PART III Specification and Composition 97 4 Regular Types for Active Objects 99 Oscar Nierstrasz 4.1Introduction 99 4.2 Types, Substitutability and Active Objects 101 4.3 Intersecting Service Types 103 4.4 Request Substitutability 105 4.5 Viewing Objects as Regular Processes 108 4.6 Subtyping Regular Types 110 4.7 Request Satisfiability 113 4.8 Open Problems 117 4.9 Concluding Remarks 119 5 A Temporal Perspective of Composite Objects 123 Constantin Arapis 5.1Introduction 123 5.2 Propositional Temporal Logic 126 5.3 The Specification of Temporal Properties 132 5.4 Verification 144 5.5 Concluding Remarks 150 vii 6 Functions, Records and Compatibility in the λN Calculus 153 Laurent Dami 6.1Introduction 153 6.2 A Lambda Calculus with Named Parameters 156 6.3 The Calculus at Work 162 6.4 Compatibility Relationship 167 6.5 Conclusion 172 PART IV Software Information Management 175 7 Component Classification in the Software Information Base 177 Panos Constantopoulos and Martin Dörr 7.1Introduction 177 7.2 The Software Information Base 179 7.3 Information Retrieval and User Interface 183 7.4 The Classification Scheme 186 7.5 Streamlining the Classification Process 191 7.6 Experiences 192 7.7 Conclusion 197 8 Managing Class Evolution in Object-Oriented Systems 201 Eduardo Casais 8.1Object Design and Redesign 201 8.2 Class Tailoring 203 8.3 Class Surgery 206 8.4 Class Versioning 212 8.5 Class Reorganization 218 8.6 Change Avoidance 230 8.7 Conversion 233 8.8 Filtering 236 8.9 Conclusion 240 9 The Affinity Browser 245 Xavier Pintado 9.1Introduction 245 9.2 Browsing Requirements 251 9.3 The Affinity Browser 252 9.4 The Affinity Browser by Example 259 9.5 Conclusion 270 viii Contents PART V Frameworks and Applications 273 10 Visual Composition of Software Applications 275 Vicki de Mey 10.1 Introduction 275 10.2 Related Work 276 10.3 A Framework for Visual Composition 278 10.4 Vista — A Prototype Visual Composition Tool 287 10.5 Sample Applications 290 10.6 Discussion 297 10.7 Conclusion 300 11 Multimedia Component Frameworks 305 Simon Gibbs 11.1 Digital Media and Multimedia 305 11.2 Multimedia Systems and Multimedia Programming 306 11.3 Multimedia Frameworks 308 11.4 A Multimedia Framework Example — Components 309 11.5 Video Widgets — A Programming Example 313 11.6 Summary 317 12 Gluons and the Cooperation between Software Components 321 Xavier Pintado 12.1 Introduction 321 12.2 An Overview of Cooperation Patterns 324 12.3 Requirements for a Financial Framework 333 12.4 Gluons 338 12.5 Gluons and the Financial Framework 341 12.6 Conclusion 347 Index 351 Contributors* Dr. Costas Arapis, GMD, Abtl. VMSD, Schloß Birlinghoven, D-53757 Sankt Augustin, GERMANY. E-mail: [email protected] Dr. Eduardo Casais, Forschungszentrum Informatik (FZI), Haid-und-Neu-Straße 10-14, D-76131 Karlsruhe, GERMANY. E-mail: [email protected] Prof. Panos Constantopoulos, Institute of Computer Science, Foundation for Research and Technology — Hellas, Science and Technology Park of Crete, Vassilika Vouton, P.O. Box 1385, GR-71110 Heraklion, Crete, GREECE. E-mail: panos@ ics.forth.gr Dr. Laurent Dami, Centre Universitaire d’Informatique, Université de Genève, 24, rue Général-Dufour, CH-1211 Genève 4, SWITZERLAND. E-mail: [email protected] Dr. Vicki de Mey, Apple Computer, Inc., One Infinite Loop, MS 301-4I, Cupertino, CA 95014, UNITED STATES. E-mail: [email protected] Dr. Martin Dörr, Institute of Computer Science, Foundation for Research and Technology — Hellas, Science and Technology Park of Crete, Vassilika Vouton, P.O. Box 1385, GR-71110 Heraklion, Crete, GREECE. E-mail: doerr@ ics.forth.gr Dr. Simon Gibbs, GMD, Schloß Birlinghoven, D-53757 Sankt Augustin, GERMANY. E-mail: [email protected] Dr. Dimitri Konstantas, Centre Universitaire d’Informatique, Université de Genève, 24, rue Général-Dufour, CH-1211 Genève 4, SWITZERLAND. E-mail: [email protected] Prof. Oscar Nierstrasz, Institut für Informatik (IAM), Universität Bern, Neubrückstrasse 10, CH- 3012 Bern, SWITZERLAND. E-mail: [email protected] Dr. Michael Papathomas, Lancaster University, Computing Department, Lancaster LA1 4YR, UNITED KINGDOM. E-mail: [email protected] Dr. Xavier Pintado, Centre Universitaire d’Informatique, Université de Genève, 24, rue Général-Dufour, CH-1211 Genève 4, SWITZERLAND. E-mail: [email protected] Prof. Dennis Tsichritzis, GMD, Schloß Birlinghoven, D-53757 Sankt Augustin, GERMANY. E-mail: [email protected] Up-to-date information concerning the authors is also available on the World Wide Web at: http://www.iam.unibe.ch/~oscar/OOSC/ *. Many of these coordinates have long become obsolete. Please contact [email protected] if you require help in contacting any of the authors. x Contributors Foreword Perhaps, “Going Beyond Objects” should be the subtitle of this volume, as a large portion of the contents departs from the early and popularly perceived image of “Objects.” The object-oriented programming paradigm has now been firmly accepted in the soft- ware community as offering the most powerful and promising technology for software de- velopment currently available, and its expressiveness and modelling power have been much appreciated. But, one of the greatest promises it made in its early stage was a dra- matic improvement in the ease of software composition and reuse, which is yet to be achieved. (People are sometimes entangled with webs of class hierarchies.) And the re- search continues. About ten years ago, Dennis and Oscar, moving from Toronto, founded the Object Sys- tems Group at the University of Geneva, and started a number of research projects to ex- tend the object-oriented paradigm in various ways. It did not take more than a couple of years for the group to become the most active and visible research centre of object-orient- ed technology in Europe. In the mean time, part of the group became involved in a large ESPRIT project called ITHACA which aimed at producing an application development environment based object-oriented technology. This volume presents, in a written form, the fruits of the group’s ten-year research and development, as directed by Dennis’ clear philosophy on research and innovation. The group attacked real problems and problems firmly based on reality. Dennis’ early career as a recursive function theorist, taught by Alonzo Church in Princeton, also encouraged foundational work in the group, and some chapters in this volume represent it. “Beyond Objects” was the title of the panel discussion at the European Conference on Object-Oriented Programming (ECOOP’91), which was organized by Oscar Nierstrasz and Dennis Tsichritzis in Geneva in July, 1991. They already had clear visions of where we/they should go from the “Objects” that only partially fulfil the early promise. One of their visions was the “Component-Based” approach for software construction. Future software construction for flexible open application should be performed by composition and configuration of plug-compatible software components that generalize objects, agents and functions. Oscar and Laurent explain this approach in the first chapter of this volume.
Load more

Recommended publications
  • The Essence Initiative
    The Essence Initiative Ivar Jacobson Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words Being in the software development business Everyone of us knows how to develop our software, but as a community we have no widely accepted common ground A CASE FOR ACTION STATEMENT • Software engineering is gravely hampered today by immature practices. Specific problems include: – The prevalence of fads more typical of fashion industry than of an engineering discipline. – The lack of a sound, widely accepted theoretical basis. – The huge number of methods and method variants, with differences little understood and artificially magnified. – The lack of credible experimental evaluation and validation. – The split between industry practice and academic research. Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words The SEMAT initiative Software Engineering Method and Theory www.semat.org Founded by the Troika in September 2009: Ivar Jacobson – Bertrand Meyer – Richard Soley What are we going to do about it? The Grand Vision We support a process to refound software engineering based on a solid theory, proven principles and best practices The Next Steps Defining A Kernel of a solid widely agreed theoretical basis elements There are probably more than 100,000 methods Desired solution: Method Architectureincl. for instance SADT, Booch, OMT, RUP, CMMI, XP, Scrum, Lean, Kanban There are around 250 The Kernel includes identified practices incl such elements as for instance use cases, Requirement, use stories, features, Software system, components, Work, Team, Way-of- working, etc.
    [Show full text]
  • Formal Specification Methods What Are Formal Methods? Objectives Of
    ICS 221 Winter 2001 Formal Specification Methods What Are Formal Methods? ! Use of formal notations … Formal Specification Methods ! first-order logic, state machines, etc. ! … in software system descriptions … ! system models, constraints, specifications, designs, etc. David S. Rosenblum ! … for a broad range of effects … ICS 221 ! correctness, reliability, safety, security, etc. Winter 2001 ! … and varying levels of use ! guidance, documentation, rigor, mechanisms Formal method = specification language + formal reasoning Objectives of Formal Methods Why Use Formal Methods? ! Verification ! Formal methods have the potential to ! “Are we building the system right?” improve both software quality and development productivity ! Formal consistency between specificand (the thing being specified) and specification ! Circumvent problems in traditional practices ! Promote insight and understanding ! Validation ! Enhance early error detection ! “Are we building the right system?” ! Develop safe, reliable, secure software-intensive ! Testing for satisfaction of ultimate customer intent systems ! Documentation ! Facilitate verifiability of implementation ! Enable powerful analyses ! Communication among stakeholders ! simulation, animation, proof, execution, transformation ! Gain competitive advantage Why Choose Not to Use Desirable Properties of Formal Formal Methods? Specifications ! Emerging technology with unclear payoff ! Unambiguous ! Lack of experience and evidence of success ! Exactly one specificand (set) satisfies it ! Lack of automated
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Making Sense of Agile Methods Bertrand Meyer Politecnico Di
    Making sense of agile methods Bertrand Meyer Politecnico di Milano and Innopolis University Some ten years ago, I realized that I had been missing something big in software engineering. I had heard about Extreme Programming early thanks to a talk by Pete McBreen at a summer school in 1999 and another by Kent Beck himself at TOOLS USA in 2000. But I had not paid much attention to Scrum and, when I took a look, noticed two striking discrepancies in the state of agile methods. The first discrepancy was between university software engineering courses, which back then (things have changed) often did not cover agility, and the buzz in industry, which was only about agility. As I started going through the agile literature, the second discrepancy emerged: an amazing combination of the best and the worst ideas, plus much in-between. In many cases, faced with a new methodological approach, one can quickly deploy what in avionics is called Identification Friend or Foe: will it help or hurt? With agile, IFF fails. It did not help that the tone of most published discussions on agile methods (with a few exceptions, notably [1]) was adulatory. Sharing your passion for a novel approach is commendable, but not a reason to throw away your analytical skills. A precedent comes to mind: people including me who championed object-oriented programming a decade or so earlier may at times have let their enthusiasm show, but we did not fail to discuss cons along with pros. The natural reaction was to apply a rule that often helps: when curious, teach a class; when bewildered, write a book.
    [Show full text]
  • The Power of Interoperability: Why Objects Are Inevitable
    The Power of Interoperability: Why Objects Are Inevitable Jonathan Aldrich Carnegie Mellon University Pittsburgh, PA, USA [email protected] Abstract 1. Introduction Three years ago in this venue, Cook argued that in Object-oriented programming has been highly suc- their essence, objects are what Reynolds called proce- cessful in practice, and has arguably become the dom- dural data structures. His observation raises a natural inant programming paradigm for writing applications question: if procedural data structures are the essence software in industry. This success can be documented of objects, has this contributed to the empirical success in many ways. For example, of the top ten program- of objects, and if so, how? ming languages at the LangPop.com index, six are pri- This essay attempts to answer that question. After marily object-oriented, and an additional two (PHP reviewing Cook’s definition, I propose the term ser- and Perl) have object-oriented features.1 The equiva- vice abstractions to capture the essential nature of ob- lent numbers for the top ten languages in the TIOBE in- jects. This terminology emphasizes, following Kay, that dex are six and three.2 SourceForge’s most popular lan- objects are not primarily about representing and ma- guages are Java and C++;3 GitHub’s are JavaScript and nipulating data, but are more about providing ser- Ruby.4 Furthermore, objects’ influence is not limited vices in support of higher-level goals. Using examples to object-oriented languages; Cook [8] argues that Mi- taken from object-oriented frameworks, I illustrate the crosoft’s Component Object Model (COM), which has unique design leverage that service abstractions pro- a C language interface, is “one of the most pure object- vide: the ability to define abstractions that can be ex- oriented programming models yet defined.” Academ- tended, and whose extensions are interoperable in a ically, object-oriented programming is a primary focus first-class way.
    [Show full text]
  • The Principles of Object-Oriented Javascript Zakas
    TAKETAKE CONTROLCONTROL OFOF Foreword by Cody Lindley, Best-selling Author and Principal Frontend Architect JAVASCRIPT THE PRINCIPLES OF OBJECT-ORIENTED JAVASCRIPT JAVASCRIPT THE PRINCIPLES OF OBJECT-ORIENTED JAVASCRIPT THETHE PRINCIPLESPRINCIPLES OFOF OBJECTSOBJECTS at TandemSeven OBJECT-ORIENTEDOBJECT-ORIENTED If you’ve used a more traditional object-oriented • How to define your own constructors JAVASCRIPTJAVASCRIPT language, such as C++ or Java, JavaScript probably • How to work with and understand prototypes doesn’t seem object-oriented at all. It has no concept of classes, and you don’t even need to define any • Inheritance patterns for types and objects objects in order to write code. But don’t be fooled — The Principles of Object-Oriented JavaScript will leave NICHOLAS C. ZAKAS JavaScript is an incredibly powerful and expressive even experienced developers with a deeper understand- object-oriented language that puts many design ing of JavaScript. Unlock the secrets behind how objects decisions right into your hands. work in JavaScript so you can write clearer, more In The Principles of Object-Oriented JavaScript, flexible, and more efficient code. Nicholas C. Zakas thoroughly explores JavaScript’s object-oriented nature, revealing the language’s A B O U T T H E A U T H O R unique implementation of inheritance and other key characteristics. You’ll learn: Nicholas C. Zakas is a software engineer at Box and is known for writing on and speaking about the latest • The difference between primitive and reference in JavaScript best practices. He honed his experience values during his five years at Yahoo!, where he was principal • What makes JavaScript functions so unique frontend engineer for the Yahoo! home page.
    [Show full text]
  • Evolution and Composition of Object-Oriented Frameworks
    Evolution and Composition of Object-Oriented Frameworks Michael Mattsson University of Karlskrona/Ronneby Department of Software Engineering and Computer Science ISBN 91-628-3856-3 © Michael Mattsson, 2000 Cover background: Digital imagery® copyright 1999 PhotoDisc, Inc. Printed in Sweden Kaserntryckeriet AB Karlskrona, 2000 To Nisse, my father-in-law - who never had the opportunity to study as much as he would have liked to This thesis is submitted to the Faculty of Technology, University of Karlskrona/Ronneby, in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Engineering. Contact Information: Michael Mattsson Department of Software Engineering and Computer Science University of Karlskrona/Ronneby Soft Center SE-372 25 RONNEBY SWEDEN Tel.: +46 457 38 50 00 Fax.: +46 457 27 125 Email: [email protected] URL: http://www.ipd.hk-r.se/rise Abstract This thesis comprises studies of evolution and composition of object-oriented frameworks, a certain kind of reusable asset. An object-oriented framework is a set of classes that embodies an abstract design for solutions to a family of related prob- lems. The work presented is based on and has its origin in industrial contexts where object-oriented frameworks have been developed, used, evolved and managed. Thus, the results are based on empirical observations. Both qualitative and quanti- tative approaches have been used in the studies performed which cover both tech- nical and managerial aspects of object-oriented framework technology. Historically, object-oriented frameworks are large monolithic assets which require several design iterations and are therefore costly to develop. With the requirement of building larger applications, software engineers have started to compose multiple frameworks, thereby encountering a number of problems.
    [Show full text]
  • Obstacl: a Language with Objects, Subtyping, and Classes
    OBSTACL: A LANGUAGE WITH OBJECTS, SUBTYPING, AND CLASSES A DISSERTATION SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY By Amit Jayant Patel December 2001 c Copyright 2002 by Amit Jayant Patel All Rights Reserved ii I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. John Mitchell (Principal Adviser) I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Kathleen Fisher I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. David Dill Approved for the University Committee on Graduate Studies: iii Abstract Widely used object-oriented programming languages such as C++ and Java support soft- ware engineering practices but do not have a clean theoretical foundation. On the other hand, most research languages with well-developed foundations are not designed to support software engineering practices. This thesis bridges the gap by presenting OBSTACL, an object-oriented extension of ML with a sound theoretical basis and features that lend themselves to efficient implementation. OBSTACL supports modular programming techniques with objects, classes, structural subtyping, and a modular object construction system. OBSTACL's parameterized inheritance mechanism can be used to express both single inheritance and most common uses of multiple inheritance.
    [Show full text]
  • Object-Oriented Software Construction
    Quotes from∗ Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental in building \production" software of higher quality than is the norm today. Object-oriented design is, in its simplest form, based on a seemingly elementary idea. Computing systems perform certain actions on certain objects; to obtain flexible and reusable systems, it is better to base the structure of software on the objects than on the actions. Once you have said this, you have not really provided a definition, but rather posed a set of problems: What precisely is an object? How do you find and describe the objects? How should programs manipulate objects? What are the possible relations between objects? How does one explore the commonalities that may exist between various kinds of objects? How do these ideas relate to classical software engineering concerns such as correct- ness, ease of use, efficiency? Answers to these issues rely on an impressive array of techniques for efficiently producing reusable, extendible and reliable software: inheritance, both in its linear (single) and multiple forms; dynamic binding and poly- morphism; a new view of types and type checking; genericity; information hiding; use of assertions; programming by contract; safe exception handling. Efficient implementation techniques have been developed to allow practical application of these ideas. [T]he book relies on the object-oriented language Eiffel. 4.1 Process and Data (p. 41) A software system is a set of mechanisms for performing certain actions on certain data.
    [Show full text]
  • Title of Presentation
    Essence Kernel Kristian Sandahl Essence/Kristian Sandahl 2021-01-18 2 Software Engineering Method And Theory • A common ground for software engineering • Moving away from SE methods “fashion” industry. • Founded in 2009 by: – Ivar Jacobson – Bertrand Meyer – Richard Soley • OMG Standard under the name Essence • The SEMAT Kernel – manifestation of the common ground Essence/Kristian Sandahl 2021-01-18 3 The Kernel • comprises the central elements for all SE methods; • provides a common language for comparing, applying, and improving methods; • supports progress monitoring; • works in small- and large-scale projects; • works for well documented and less documented projects; • comes with a language and tool for developing practices. • Uptake in China, Russia, South Africa, Japan, Silicon Valley, Florida, Mexico, Germany Essence/Kristian Sandahl 2021-01-18 4 What’s in it for us? • It is highly probable that this will be used much more in the future. • By focusing on the Essentials, the project groups have more freedom and responsibility. • Our students will not become “methodists”. • Taught in TDDE46 Software quality. Essence/Kristian Sandahl 2021-01-18 5 Areas of concern Use and exploitation of the system Specification and development The team and approach of work Essence/Kristian Sandahl 2021-01-18 6 What is an ALPHA? • Alpha is an acronym for an Abstract-Level Progress Health Attribute. • A critical indicator of things that are most important to monitor and progress. Essence/Kristian Sandahl 2021-01-18 7 The Kernel ALPHAs Source of picture: Ivar Jacobson International Essence/Kristian Sandahl 2021-01-18 8 Brief explanation Source of picture: Ivar Jacobson International Essence/Kristian Sandahl 2021-01-18 9 The structure of an ALPHA Source of picture: Ivar Jacobson International Essence/Kristian Sandahl 2021-01-18 10 Requirements– one of the alphas What the software system must do to address the opportunity and satisfy the stakeholders.
    [Show full text]
  • Practice to Perfect: the Quality First Model
    Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] It’s the spiral model. Barry Boehm’s great contribution (“A Spiral Model of Practice Software Development and Enhance- ment,” Computer, May 1988) was to emphasize the need to handle risk in soft- Object Technology ware project management. But Quality To Perfect: First does not use spiral’s idea of repeated analysis-design-implementation cycles. It builds the software, cluster by cluster, using a seamless, reversible process, The Quality as described by Kim Walden in this column (“Reversibility in Software Engineering,” Sept. 1996). First Model It’s just.... Probably not. Few basic ideas are completely new in software; to a certain extent, all had been said in 1974 Bertrand Meyer, EiffelSoft by Edsger Dijkstra, Tony Hoare, Knuth, Harlan Mills, Niklaus Wirth, and a few Ich bin der Geist, der stets verneint, I’ve always worked that way. If that’s others. What counts is how you put the und das mit Recht Mephistopheles really true, congratulations. But I’d like to basic ideas together: what you do, and – Goethe’s Faust, part I (for the trans- see it before I believe it, because some as- also what you don’t do. lation, read on) pects of this process go directly against con- ventional ideas of software development. It’s a personal software process and will not work for large developments. Large aving recently completed a mul- It’s just literate programming. Donald developments are aggregates of personal tiyear writing project, I now Knuth’s literate programming is a great processes, as described by Watts have time to program again.
    [Show full text]
  • Approaches to Composition and Refinement in Object-Oriented Design
    Approaches to Composition and Refinement in Object-Oriented Design Marcel Weiher Matrikelnummer 127367 Diplomarbeit Fachbereich Informatik Technische Unversitat¨ Berlin Advisor: Professor Bernd Mahr August 21, 1997 Contents 1 Introduction 4 1.1 Object Orientation 4 1.2 Composition and Refinement 5 2 State of the Art 7 2.1 Frameworks 7 2.1.1 Framework Construction 8 2.1.2 Reusing Frameworks 9 2.2 Design Patterns 10 2.2.1 Reusing Patterns 10 2.2.2 Communicating Patterns 12 2.3 Commentary 13 3 Enhanced Interfaces 14 3.1 Interface Typing 14 3.2 The Refinement Interface 15 3.2.1 Protocol Dependencies 15 3.2.2 Reuse Contracts 18 3.3 Interaction Interfaces 21 3.3.1 Interaction Protocols 21 3.3.2 Protocol Specification and Matching 22 3.4 Commentary 23 4 Orthogonalization 24 4.1 Delegation 24 4.1.1 Prototypes Languages 25 4.1.2 Composition Filters 25 4.2 Mixins 27 4.2.1 Mixins and Multiple Inheritance 28 4.2.2 Nested Dynamic Mixins 28 4.3 Extension Hierarchies 29 4.3.1 Extension Operators 29 4.3.2 Conflicts: Detection, Resolution, Avoidance 30 4.4 Canonic Components 31 4.4.1 Components 31 4.4.2 Views 32 4.5 Commentary 33 1 5 Software Architecture 34 5.1 Architectural Styles 34 5.1.1 Pipes and Filters 35 5.1.2 Call and Return 36 5.1.3 Implicit Invocation 36 5.1.4 Using Styles 37 5.2 Architecture Description Languages 38 5.2.1 UniCon 38 5.2.2 RAPIDE 39 5.2.3 Wright 40 5.2.4 ACME 43 5.3 Commentary 43 6 Non-linear Refinement 45 6.1 Domain Specific Software Generators 45 6.1.1 A Domain Independent Model 46 6.1.2 Implementation 47 6.2 Subject Oriented
    [Show full text]