ppc_234x172budgen3 9/18/07 12:24 PM Page 1

Software Engineering second second edition edition

Software design is a multi-disciplinary Since the first edition, much progress activity that develops tools through effective has been made in the area of software SOFTWARE DESIGN

David Budgen communication of ideas and the use of design, with the major changes to the engineering practices. This text provides an new edition being: overview and perspective of software design within the context of software • A much stronger recognition of the development and also of more general role played by the concept of thinking about design issues. It examines architectural style in helping to the nature of design activities, as well as structure ideas about design. This is their applications within software used to provide an underpinning development, providing the reader with: framework throughout the second edition. • a non-proprietary view of design issues • The inclusion of new forms of • an overview of design representation software and of new approaches to forms design, ranging from agile methods • a concise review of design practices and design patterns through to the based on the more widely used component concept and the use of the design methods Unified Modeling Language (UML). • a strong architectural framework • An improved formalism to support the analysis of the processes A particular feature is the strong embodied in design methods. evidence-based approach used in the analysis and assessment of these issues. SOFTWARE DESIGN

Software Design provides a balanced view of the many and varied software design David Budgen strategies most widely used by practitioners. By being aware of the strengths and limitations of each one, a student is better able to judge which to adopt when working in the field. The book is also valuable for software engineers and project managers who need an objective guide to the state of the art in this area.

David Budgen is Professor of Software Engineering at Keele University, UK. A long- term student of software design, he has worked closely with the Software Engineering Institute in Pittsburgh to develop tutorial modules, as well as publishing many research papers on software design topics. Budgen SOFTWARE DESIGN SOFTWARE

second edition www.pearsoneduc.com SDA01 9/18/07 10:32 AM Page i

Software Design SDA01 9/18/07 10:32 AM Page ii

INTERNATIONAL COMPUTER SCIENCE SERIES

Consulting Editor A D McGettrick University of Strathclyde

SELECTED TITLES IN THE SERIES

Operating Systems J Bacon and T Harris Programming Language Essentials H E Bal and D Grune Programming in Ada 95 (2nd edn) J G P Barnes Java Gently (3rd edn) J Bishop Concurrent Programming A Burns and G Davies Real-Time Systems and Programming Languages: Ada 95, Real-Time Java and Real- Time POSIX (3rd edn) A Burns and A Wellings Comparative Programming Languages (3rd edn) L B Wilson and R G Clark, updated by R G Clark Database Systems (3rd edn) T M Connolly and C Begg Distributed Systems: Concepts and Design (3rd edn) G Coulouris, J Dollimore and T Kindberg Principles of Object-Oriented Software Development (2nd edn) A Eliëns Fortran 90 Programming T M R Ellis, I R Philips and T M Lahey Program Verification N Francez Introduction to Programming using SML M Hansen and H Rischel Functional C P Hartel and H Muller Algorithms and Data Structures: Design, Correctness, Analysis (2nd edn) J Kingston Introductory Logic and Sets for Computer Scientists N Nissanke Human–Computer Interaction J Preece et al. Algorithms: A Functional Programming Approach F Rabhi and G Lapalme Ada 95 From the Beginning (3rd edn) J Skansholm Java From the Beginning J Skansholm Software Engineering (6th edn) I Sommerville Object-Oriented Programming in Eiffel (2nd edn) P Thomas and R Weedon Miranda: The Craft of Functional Programming S Thompson Haskell: The Craft of Functional Programming (2nd edn) S Thompson Discrete Mathematics for Computer Scientists (2nd edn) J K Truss Compiler Design R Wilhelm and D Maurer Discover Delphi: Programming Principles Explained S Williams and S Walmsley Software Engineering with B J B Wordsworth SDA01 9/18/07 10:32 AM Page iii

Software Design

David Budgen SDA01 9/18/07 10:32 AM Page iv

Pearson Education Limited Edinburgh Gate Harlow Essex CM20 2JE England

and Associated Companies throughout the world

Visit us on the World Wide Web at: www.pearsoned.co.uk

First published 1993 Second edition 2003

© Addison-Wesley Publishers Limited 1993 © Pearson Education Limited 2003

The right of David Budgen to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988.

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 either the prior written permission of the publisher or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP.

The programs in this book have been included for their instructional value. They have been tested with care but are not guaranteed for any particular purpose. The publisher does not offer any warranties or representations nor does it accept any liabilities with respect to the programs.

All trademarks used herein are the property of their respective owners. The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners.

ISBN 0 201 72219 4

British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library

Library of Congress Cataloging-in-Publication Data Budgen, D. (David) Software design / David Budgen.—2nd ed. p. cm. Includes bibliographical references and index. ISBN 0–201–72219–4 (alk. paper) 1. Computer software—Development. I. Title.

QA76.76.D47B83 2003 005.1′2—dc21 2003041859

10987654321 08 07 06 05 04 03

Typeset in 10/12pt Sabon by 35 Printed and bound in Great Britain by Biddles Ltd., Guildford and King’s Lynn

The publisher’s policy is to use paper manufactured from sustainable forests. SDA01 9/18/07 10:32 AM Page v

v

Contents

Preface to the Second Edition ix Preface to the First Edition xii Publisher’s Acknowledgements xvi

Part 1 The Role of Software Design 1

Chapter 1 The Nature of the Design Process 3 1.1 What is design? 4 1.2 The role of the design activity 14 1.3 Design as a problem-solving process 18 1.4 Design as a ‘wicked’ problem 19

Chapter 2 The Software Design Process 25 2.1 What is software? 26 2.2 Building models 27 2.3 Transferring design knowledge 32 2.4 Constraints upon the design process and product 37 2.5 Recording design decisions 38 2.6 Designing with others 40

Chapter 3 Design in the Software Development Process 45 3.1 A context for design 46 3.2 Linear development processes 50 3.3 Incremental development processes 51 3.4 Economic factors 55 3.5 The longer term 57 ale for Method 175 8.38.4 Why methods don’t work miracles Problem domains and their influence9.19.2 The role of strategy in methods9.3 Describing the design process – the D-Matrix9.4 Design by top-down decomposition9.5 Design by composition Organizational influences upon design 185 187 200 194 205 209 207 6.5 A unified interpretation?7.17.2 A problem of selection7.3 Black box notations7.4 White box notations Developing a diagram8.18.2 What is a software design method? The support that design methods provide 122 128 180 129 176 158 168 5.15.2 abstract ideas Representing 5.3viewpoints for software Design of notation Forms 6.16.2 The need to share knowledge6.3 The architecture concept6.4 Design methods Design patterns 94 90 106 98 109 118 120 4.14.2 quality concept The 4.3 quality design Assessing 4.4 of the design product attributes Quality process the design Assessing 75 65 64 82 Part 2 Knowledge Design Transferring 87 Chapter 9Chapter Strategies and Design Processes Design 193 Chapter 8Chapter The Ration Chapter 7Chapter Representations Some Design 127 Chapter 6Chapter Knowledge Design Transferring 105 Chapter 5Chapter Solution Design a Describing 89 Chapter 4 Chapter Qualities Design 63

vi Contents SDA01 9/18/07 10:32 AM Page vi 10:32 AM 9/18/07 SDA01 vii Contents Design 257 14.214.3 JSP representation forms14.4 The JSP process Some JSP heuristics15.115.2 The JSD model15.3 JSD representation forms15.4 The JSD process JSD heuristics 291 301 293 318 316 322 336 13.113.2 Origins, development and philosophy13.3 Representation forms for SSA/SD13.4 The SSA/SD process13.5 The role of heuristics in SSA/SD13.6 Extended forms of SSA/SD SSA/SD: an outline example14.1 Some background to JSP 258 259 273 275 263 275 290 11.111.2 role of stepwise refinement The historical 11.3 consequences Architectural and weaknesses of the stepwise strategy Strengths 12.112.2 Black box to white box in stages12.3 Prototyping 237 An example – DSDM 234 235 242 247 245 10.110.2 and design reuse Design by template 10.3 The design pattern10.4 patterns Designing with wider design context Patterns in the 214 227 225 216 Part 3 Practices Design 231 Chapter 15Chapter (JSD) Development System Jackson 315 Chapter 14Chapter (JSP) Programming Structured Jackson 289 Chapter 13Chapter and Structured Analysis Systems Structured Chapter 12Chapter Design Incremental 241 Chapter 11Chapter Refinement Stepwise 233 Chapter 10Chapter Patterns Design 213 SDA01 9/18/07 10:32 AM Page vii 10:32 AM 9/18/07 SDA01 461 19.119.2 What is software now?19.3 Codifying design knowledge Improving knowledge transfer 444 447 442 17.117.2 concept The component 17.3 with components Designing 17.4 components Designing extremity – COTS At the 18.118.2 The case for rigour18.3 Model-based strategies Property-based strategies 408 402 414 415 425 432 420 16.116.2 The ‘object concept’16.3 paradigm for the object-oriented Design practices 16.4 frameworks Object-Oriented 16.5 Object-based design design Object-Oriented 356 367 342 379 371 Chapter 19Chapter Design? Whither Software 441 Chapter 18Chapter to DesignApproach A Formal 419 Chapter 17Chapter Design Component-Based 401 Chapter 16Chapter Objects with Designing 341 BibliographyIndex 451

Contents viii SDA01 9/18/07 10:32 AM Page viii 10:32 AM 9/18/07 SDA01 SDA01 9/18/07 10:32 AM Page ix

ix

Preface to the Second Edition

‘Science is built up of facts as a house is built of stones, but an accumulation of facts is no more a science than a heap of stones is a house.’ Jules Henri Poincaré (1854–1912)

At times, it is hard not to feel that our knowledge about designing software is rather too close to being a heap of stones. Indeed, a large element in the motivation for the first edition of this book was the desire to gather, classify, categorize, and interpret that knowledge, in the hope of providing a structure that would be of assistance to others. While the end result was certainly far from being a ‘house’, it did perhaps resemble a low wall or two! Indeed, the production of this second edition (which I hope builds the walls a little higher at least), was motivated by the way that the first edition of this book has been generally well received by both teachers and students (a situation which is gratifying to any author!). In terms of its wider role, one of the more external signs of the recogni- tion of its ‘foundational’ status is the extent to which it was cited in the Trial Version of the IEEE’s SWEBOK (Software Engineering Body of Knowledge). However, technology and design thinking march on, albeit not always at the same rate and, in preparing this second edition, the material from the first edition has been extensively revised and rewritten to reflect the many changes that have occurred since it was published. So what are the major changes? In brief, these are as follows.

n A much stronger recognition of the role played by the concept of architectural style in helping to structure our ideas about software design. This is used to provide an underpinning framework throughout this second edition. n The inclusion of new forms of ‘software’ and of new approaches to design, ranging from agile methods and design patterns through to the component concept and the use of the Unified Modeling Language. n An improved formalism to support the analysis of the processes embodied in design methods.

It would be nice if this list could also include the use of a suitably extensive body of empirical evidence about the effectiveness and limitations of the design approaches changed is what may be considered as the unique strength of this be considered as the unique strength changed is what may not However, I hope that the result is not a dry and dusty tome. Software design is a However, I hope that the result is not of source material, concerns the citation of One last point, returning to the issue What has Obviously there has also had to be a degree of restructuring and reorganization reorganization of restructuring and to be a degree there has also had Obviously ability to suspend too-evident disbelief at yet another claim of ‘nearly completed’. Acknowledgements So I should The production of this second edition has been a rather lengthy process. especially rightly begin by thanking my family and the staff of Pearson Education, degree of Keith Mansfield, for their patience and tolerance, as well as a collective websites, a vexed question for any author! During the development of this revised edi- websites, a vexed question for any author! some of which ‘disappeared’ during the process, tion, I consulted a range of websites, Also, of course, few websites contain while others ceased to be actively maintained. a peer process. So, where possible, I have material that has been reviewed through to be relatively stable and which can also be cited only those sites which I consider sense. regarded as authoritative in a technical topic that readily begets enthusiasm among practitioners and students, not least topic that readily begets enthusiasm forms of activity possible in any technical sphere. because it is one of the most creative opportunities to both the practitioner and the It is certainly one that offers exciting pages that follow. researcher, as should be evident in the cacy so often replacing systematic evaluation, this role seems a particularly important cacy so often replacing systematic evaluation, authors of the design chapter of the SWEBOK (I one, as was indeed recognized by the in which I had no part!). Returning for a should add here that this was a production aim for this book was at least to construct the moment to the opening quotation, my permit a more objective and systematic study of foundational walls that would in time not been fully met in all aspects, at least the software design. Even if that goal has heaps! stones have been sorted into appropriate material in a form readily accessible to the student, such as journals and textbooks, readily accessible to the student, such material in a form forms such as conference where possible to less widely available has been preferred proceedings. design in a scholarly and non- to describe the domain of software book, in that it seeks apt to be inundated with hype, and with advo- partisan manner. In an area that is so emphasis placed upon procedural methods by practitioners. The chapter on design procedural methods by practitioners. emphasis placed upon to include some new forms of been restructured and also extended representations has the book from a two-part overall grouping of chapters has changed notation. And the also been extensively updated, three parts. The bibliography has structure to one of material in order to pro- I have quoted from original source and, wherever possible, might be made. Again, source evidence for any assertions that vide the supporting described. Indeed, where any such evidence is available, I have sought to give it due to give have sought I is available, evidence any such where Indeed, described. remains one that is field of research this particular though, Unfortunately prominence. in such research. the difficulties implicit least because of cultivated, not only sparsely a future editionMaybe in . . . number of design the new. The order to accommodate material in of the existing the reduction in reflecting a more general slightly reduced, described has been methods

x Preface to the second edition SDA01 9/18/07 10:32 AM Page x AM Page 10:32 9/18/07 SDA01 xi Preface to the second edition David Budgen November 2002 , and eventually resulting in the first , and eventually resulting curriculum modules : especially Pearl Brereton, Keith Bennett and Paul Layzell. I should Paul Layzell. I Keith Bennett and Pearl Brereton, : especially And as before, of course, any errors of fact and any omissions are entirely my own! any errors of fact and any omissions And as before, of course, I should also express my thanks to those who patiently answered my queries about my thanks to those who patiently I should also express Thanks again to my many friends and colleagues for their support and encour- support for their and colleagues friends to my many again Thanks Shaw for discussion about pedagogical issues as well as checking my explanations of about pedagogical issues as well as Shaw for discussion 12 could not have been com- architectures. Also, Chapter the concepts of software Consortium, and indeed from help that I received from the DSDM pleted without the the wider DSDM community. ment of one of the SEI’s first ment of one of the edition of this book. the help from Fred Brooks I would like to acknowledge specific issues. In particular, to Manny Lehman for helping ideas about ‘shells of knowledge’; Jnr in explaining his E-type software; and to Mary references to his ideas about me to pin down elusive agement. In addition to those listed in the original preface, many of whom have con- whom have many of preface, original in the those listed to In addition agement. the of my colleagues in the support I should recognise provide help and ideas, tinued to Pennine Group Gibbs when Director by the late Norm contribution made here the also acknowledge to with my attempts me to persist Norm encouraged Education Program. of the SEI’s with my develop- design, starting about software and classify knowledge categorize SDA01 9/18/07 10:32 AM Page xi 10:32 AM 9/18/07 SDA01 SDA01 9/18/07 10:32 AM Page xii

xii

Preface to the First Edition

Why you might benefit from reading this book

Why should software need to be designed at all? Well, you would not expect any other engineered artifacts such as bridges, cars or television sets to be built without someone first designing them and producing plans for their construction. And you certainly would not expect to modify them significantly without having some detailed documentation available either. Software is no different: throwing a few dozen pro- grammers at a problem without having detailed plans is hardly likely to result in well-engineered software that actually works. So, where does the design process fit in? It occurs somewhere between the optimistic phase where we decide what we would like our system to do (often termed ‘Requirements Capture’) and the increasingly pessimistic phase where we build it (‘Implementation’), although it may appear in many different guises. Design is the highly creative stage in software development where someone (the designer) plans how the system or program should meet the customer’s needs, be easy to implement, ‘efficient’ and easily extended to meet new needs. If it’s so creative a task, how will this book help? Mainly because any form of creativity is likely to be more effective when there are ways of learning from the exper- iences of others (‘rules of form’, design methods) and when there are well-developed notations that can be used for communicating the designer’s ideas and plans to those whose task it is to implement them. These are just the sort of issues that this book addresses: how to develop our ideas about a design, the criteria we might use to assess our ideas and the ways in which we might convey these ideas to programmers. This is a book about software design. It pro- vides an analysis of a number of the currently-used approaches to the task of design, rather than being dedicated to describing just one representation or method. OK, so who will benefit from reading it? Well, every author would like their work to be a best-seller that appears on every airport and railway station bookstall – but this one is perhaps a bit too specialist for that! It contains information and ideas that are relevant to anyone who is in the business of developing software (except, of course, those whom Tom De Marco has described as the ‘Mugwump School, people who believe that design is for sissies’). However, it does assume a basic acquaintance with imperative programming languages (although it is certainly not language-specific) Preface to the first edition xiii xiii . Page

AM So the 1970s also saw the development of design representation forms, and the So the 1970s also saw the development of design representation forms, Abstraction has played a central role in the development of better programming Abstraction has played a central role During the 1970s a number of advances in software technology were designed to a number of advances in software technology During the 1970s 10:32 10:32

abstraction tion forms at the same time. While the benefits arising from these improved techniques tion forms at the same time. While the of programming activities, there was also grow- were at first identified mainly in terms better practices for programming-in-the-large, ing realization of the need to develop development of ‘systems’ as a whole. which is concerned with the design and techniques, allowing the designer of a program to reason about its structure and techniques, allowing the designer of the detailed issues of determining implementa- behaviour without needing to address (Throughout this book the term design method has been used in preference to the (Throughout this book the term design method has been used in preference According much-abused design methodology when describing specific design techniques. designers much more isolated from their actual creation, compounded by the likeli- designers much more isolated from their actual creation, compounded means that hood that the task of implementation will be allocated to others. This manner. designers also need to communicate their ideas to others in an unambiguous designers, emergence of design methods intended to capture the experiences of other their task. and so to help designers describe their ideas and to control and structure Programming-in-the-large significant problems, the design of large systems While the design of programs offers complexity. The increased levels of abstraction provides a vastly increased degree of make it more difficult for the designer to visual- required for designing a large system eventual system. The greatly increased time inter- ize and ‘model’ the behaviour of the of an idea and its actual realization leaves val that can occur between the origination ages, more efficient compilers, structured programming practices and symbolic debug- ages, more efficient compilers, structured programmers with developing, controlling and ging facilities. All of these have assisted mainly through increased use of the concept visualizing their ideas about a program, of correctness of its dynamic behaviour still needs to be confirmed. Indeed, it is this need behaviour still needs to be confirmed. correctness of its dynamic continually in mind when form and eventual dynamic behaviour to keep both static challenge that programming that forms a significant part of the developing a solution provides. programs: higher-level programming langu- improve the task of developing computer Writing a computer program is a challenging and creative experience, motivated by the program is a challenging and creative Writing a computer small computer program is not The task of developing even a desire to solve problems. keep their attention focused are continually required to an easy one. Programmers Even when the static aspects of both problems and solutions. upon many different ‘compiles’ successfully), the is complete (that is, the program structure of a program and with concepts such as abstract data types. It is suitable as a text for advanced as a is suitable types. It data as abstract such with concepts and engineering. or software design in software courses or postgraduate undergraduate should benefit from project managers programmers and Systems analysts/designers, methods. spectrum of design of a broad the comparison important is design Why software 9/18/07 9/18/07

SDA01 SDA01 is the methodology design, or even necessarily about is ‘a procedure for doing things’, while things’, for doing procedure is ‘a does not teach a student method methods design. The would-be designer needs to study widely and to gain a thorough design. The would-be designer needs do The analogy should not be pushed too far (few symphonies have been produced The analogy should not be pushed too A field which provides a good (and partly comforting) analogy is that of the A field which provides a good (and As software plays a central role in the operation of many systems, as varied as a central role in the operation of many As software plays based systems (whether we that the study of software It is increasingly accepted the teaching of design knowledge and suggested ways in which these might be intro- the teaching of design knowledge and suggested ways in which these might duced to the student, supported by a bibliographical survey. I was fortunate enough to spend some time at Carnegie-Mellon’s Software Engineering I was fortunate enough to spend some time at Carnegie-Mellon’s Software design was Institute (SEI) during 1986, during which an initial curriculum in software revised in developed for the Graduate Curriculum Project. This was then extensively work was 1988, taking on board subsequent thinking and experience. The aim of this issues in to develop a ‘road-map’ for use by instructors which identified the principal teaching design how to influence the design process before taking on the understanding of the many issues that not this involes the use of specific design methods. role of a system designer, whether or about book came How this ficient in reading and interpreting musical scores, before ever attempting to master the ficient in reading and interpreting musical software design the novice needs to learn to pro- rules of composition. In the case of the manipulation of various forms of abstrac- gram effectively, and to be familiar with of any size or complexity. tion, before proceeding to design a system project managers), but we do need to realize that by ‘composition teams’, organized by develop a significant item of software from the abstract design to its final implementa- develop a significant item of software students to gain real feedback from carrying their tion usually makes it impractical for designs through to fruition. is another highly creative task and, like software study of music. Musical composition complex static notation to describe the eventual designers, composers need to use a music. The student of music must become pro- dynamic performance of a piece of even information technology) needs to involve some basic knowledge about the roles needs to involve some basic even information technology) students of design are software development process. However, of design within the the high level of abstrac- of the same problems as the designer: confronted with many ‘distance’ from the eventual descriptive forms, and the resulting tion required in the necessary degree of ‘feeling’ it difficult to provide them with the solution, can make As a further complication, the time required to for all the issues that are involved. banking transactions, spreadsheet calculations, or aircraft control systems (‘fly by spreadsheet calculations, or aircraft banking transactions, should be designed as well increasingly important that such systems wire’), it becomes even be life-threatening. design can lead to disaster and can as possible. Faulty systems engineering, or computer science, information call it software engineering, to the dictionary, dictionary, to the involves as it is methodological, in this book be doing we will What of method’. ‘study design methods have and many process has continued, of methods!) This the study far beyond their gradually evolved en route, and have been re-designed themselves the describing and new viewpoints about design quality New ideas original forms. into both in turn been incorporated emerged, and have of software have properties existing design methods. new and

xiv Preface to the first edition SDA01 9/18/07 10:32 AM Page xiv 10:32 AM 9/18/07 SDA01 xv Preface to the first edition design, do David Budgen November 1993 software systems design. There are relatively There design. systems software about . While these books cater for a very important set of skill a very important books cater for . While these is Last (but certainly not least) grateful thanks to my family, who have put up with Last (but certainly not least) grateful thanks to my family, who have put I should also like to acknowledge the contribution of my various student classes, I should also like to acknowledge the One of the aims of this book is therefore to redress the balance by providing a book this book is therefore to redress the balance One of the aims of In compiling the curriculum, one of the major problems that emerged was the lack was the emerged that problems of the major one curriculum, the In compiling unfortunate lot to provide some of the testing ground for the frameworks that have unfortunate lot to provide some of the testing ground for the frameworks been used in this book, and their feedback has been invaluable for this. for his ‘not another book’ for so long; and to Simon Plumtree of Addison-Wesley encouragement, and amazing patience in waiting for the final manuscript! present colleagues at the University of Keele, including Mike Brough and my other present colleagues at the University Andrew Reeves and Grant Friel, who have research collaborators, Mustafa Marashi, ideas. All of them have had to labour long and put in so much work on some of my to further my education on the subject of soft- hard to correct my misconceptions and are all my own. ware design. The mistakes that remain Keele, as well as in industry. It has been their in the Universities of Stirling and of and sustained my efforts on this book from its original inception to the final product. and sustained my efforts on this book at the SEI, especially Jim Tomayko, Mary These include: my friends and mentors of the Education Program; my friends and Shaw, Carol Sledge and the other members Ken Jackson, Hugo Simpson, Ray Foulkes collaborators in industry, Mike Looney, at the University of Stirling, with special and Alastair O’Brien; my former colleagues Naftalin for the many exchanges of ideas; and my thanks to Chic Rattray and Maurice Design in any sphere can be a pleasurable and creative act for those involved in it, Design in any sphere can be a pleasurable sand-castles on the beach, engineering a complex whether it involves building simple or writing a fugue. Writing books is a creative structure such as the Thames Barrier, (at times), especially so once the task is com- act, and can also give the writer pleasure also depends upon the help, advice and encour- pleted! Like so many creative tasks it like to thank the many people who have helped agement of many others, and I would those books that teach specific design methods in detail, but rather to provide a broad specific design methods in detail, those books that teach precede any detailed study of of understanding that might usefully intermediate level to be used in a project. or the selection of a design method one or more methods, Acknowledgements some degree of proselytizing! design, and survey the roles to the issues of software systems that can act as a ‘road-map’ about design (with particular play in this. This book is therefore that design methods although in the process and its needs), rather than about method, attention to software other. It is not meant to replace we necessarily have to discuss the of describing the one, of textbooks suitable for teaching teaching for suitable of textbooks in terms of software), general (not just subject of design in that address the few books one the use of are centred on describing software design all textbooks about and nearly how to being books about be considered as method. These can particular what design rather than all authors to avoid difficult for almost does make it one approach needs, teaching SDA01 9/18/07 10:32 AM Page xv AM Page 10:32 9/18/07 SDA01 SDA01 9/18/07 10:32 AM Page xvi

xvi

Publisher’s Acknowledgements

We are grateful to the following for permission to reproduce copyright material:

Figure 2.6 from A field study of the software design process for large systems, Comm. ACM, 31(11), (Curtis et al., 1988); Figures 3.2 and 3.4 from A spiral model of soft- ware development and enhancement, IEEE Computer, 21(5), (Boehm, B.W. 1988), Figure 3.3 from Open source software development: an overview, IEEE Computer, 34(6), (Wu, M.-W. and Lin, Y.-D. 2001), Figure 9.4 from A generic model for repre- senting design methods. In Proceedings of the 11th International Conference on Software Engineering, (Potts, C. 1989) and Figure 17.5 from What do you mean by COTS? Finally a useful answer, IEEE Software, 17(2) (Carney, D. and Long, F. 2000) all with permission from the IEEE. SDC01 9/18/07 10:34 AM Page 1

part 1 The Role of Software Design

Chapter 1 The Nature of the Design Process 3

Chapter 2 The Software Design Process 25

Chapter 3 Design in the Software Development Process 45

Chapter 4 Design Qualities 63 SDC01 9/18/07 10:34 AM Page 2 SDC01 9/18/07 10:34 AM Page 3

chapter 1 3 The Nature of the Design Process

1.1 What is design? 1.3 Design as a problem-solving 1.2 The role of the design activity process 1.4 Design as a ‘wicked’ problem

This opening chapter is concerned with examining the role that design plays in a wide range of spheres. It looks at the ideas of design theorists and examines these in the light of some simple examples of design activity. In particular, it contrasts the use of design as a problem-solving technique with that of scientific method, and shows how these differ in a number of highly significant ways. . Tools are tools . Translating a ‘design’ activity, whether or not this is activity, whether or discipline also occurs when the design communication engineering to an craft ideas is a major element in the development of design expertise, and an import- ideas is a major element in the development Obviously design is not the only factor that matters in the production of artifacts. Obviously design is not the only factor that matters in the production of Our perception of the importance of the roles that design may play in producing Our perception of the importance of All of these are core concepts that underpin the ideas presented in this book, and All of these are core concepts that underpin Communication also plays another, rather different, role in design activities. This plays another, rather different, role Communication also A second distinguishing characteristic of human beings that provides an under- characteristic of human beings A second distinguishing design from faulty fabrication if shoes leak in the rain, or if the door falls off a car design from faulty fabrication if shoes leak in the rain, or if the door falls fabrication, when it is opened. However, while good design may be marred by poor usually no amount of constructional skill can disguise poor design. range of less safety-critical objects – such as a domestic refrigerator: we do not want to range of less safety-critical objects – such as a domestic refrigerator: we do the door. have to de-ice it continually, nor to replace bottles that fall out when we open not find our- Similarly, we also want to have well-designed footwear so that we do selves suffering from foot complaints. faulty The fabrication process matters too, and a customer is unlikely to distinguish machine works reliably) or a poor one (the flat roof of a house leaks, or the chair col- machine works reliably) or a poor one legs). lapses when the user leans back on two it may not always be correct. No-one is these different artifacts will vary, although well-proven design practices for the design of likely to deny the importance of using not least because of the safety issues con- motorway bridges, aeroplanes and buildings, Yet equally, good design is important for a wide cerned with the use of such objects. process extensively influence our lives. We ride in cars, trains, aeroplanes; we live in process extensively influence our lives. appliances such as washing-machines, tele- houses or flats; we use everyday domestic on chairs, lie on beds, walk around in shoes; we vision sets, vacuum cleaners; we sit are artifacts because they have been devised play games, listen to music. All of these of them in some way are the products of some and created by human beings, and all a good one (shoes are comfortable, a washing- form of design process – whether to ‘novice’, as well as shared amongst a community of experts. Indeed, the ability to to ‘novice’, as well as shared amongst reuse ant part of the transition from a the process of fabrication. scope of reuse is extended to include at the first of them rather more closely. Indeed, so it is appropriate to begin by looking of many different applications of the design various artifacts that are the outcome development team, whether it be for the purpose of building a megalithic barrow, or whether it be for the purpose of building development team, of design therefore requires due banking system. Any discussion for creating an on-line their ideas and convey them to means by which designers record consideration of the result. responsible for fabricating the final those who will be and expertise are transferred from ‘expert’ is to act as the vehicle by which experience tool in question is a stone axe or a compiler – and producing any form of artifact is an a stone axe or a compiler – and producing tool in question is incorporates some element of act that implicitly at the time. explicitly appreciated of design activity is that of pinning for any form the designer’s ideas to the always involves communicating into a ‘product’ almost 1.1 design? is What how we can make with exploring this book is concerned subject matter of While the a of barely half which has a history of a technology effective application the most distinctive of human in one of the most are rooted the ideas that it presents century – of, of, and the use is the making This characteristic characteristics. the artifacts, whether to create further are then in turn used artifacts, which themselves

4 The nature of the design process SDC01 9/18/07 10:34 AM Page 4 AM Page 10:34 9/18/07 SDC01 5 What is design? (Jones, 1970). , with observation are , 1989). Yet all too rarely et al. Design Methods: Seeds of Human Futures Design Methods: Seeds of Human Futures has been concerned with studying things as they science So what is design exactly, what sort of activities does it involve, and what can we So what is design exactly, what sort Although this book is focused largely on the application of design ideas and Although this book is focused largely Despite extensive exposure to the products of the design process in general (with exposure to the products of the design Despite extensive Design is just as important with software systems also. Most people will readily people also. Most systems software with as important is just Design assumed effect upon the world to the beginning of a chain of events that will bring assumed effect upon the world to the beginning of a chain of events that the effect about.’ ‘The fundamental problem is that designers are obliged to use current information ‘The fundamental problem is that designers come about unless their predictions are cor- to predict a future state that will not has to be assumed before the means of achiev- rect. The final outcome of designing have to work backwards in time from an ing it can be explored: the designers between mankind and the surrounding ‘world’ has historically taken two paths. The between mankind and the surrounding ‘world’ has historically taken two path of approach and experimentation as its key activities. In its ‘classical’ form, the scientific This concise description of the design process is more than sufficient to show that its This concise description of the design process is more than sufficient to which form is very different from that of the scientific approach to problem-solving interaction will perhaps be more familiar to many readers. As shown in Figure 1.1, the sider the words of one of the pioneering design methodologists, J. Christopher Jones, sider the words of one of the pioneering taken from his classic work, methods to the production of software, the task of design involves the use of many methods to the production of software, more widely. To help reinforce this point, the ideas and concepts that can be applied chapters will be drawn from a wide range of examples used in these introductory software development. fields, and not just from the field of process? Perhaps a good starting point is to con- observe about the products of that do we have a clear idea of the nature and purpose of the design process, and our ideas do we have a clear idea of the nature in with notions derived from the more specific about design are all too often muddled first chapter aims to explore some ideas about the practices of design methods. So this to provide a basic framework for an under- design process and its nature, in order be used to explore the ideas and concepts intro- standing of design issues that can then duced in the subsequent chapters. an associated awareness that good design practices cannot always ensure success in that good design practices cannot an associated awareness is carried out is often rather people’s awareness of how design terms of design quality), science and software engin- In the domain of computing unstructured and piecemeal. technique, to be ranked along- is a major problem-solving eering, designing software (Denning side the concepts of theory and of abstraction graph occurring at apparently random points in a document. It may not be appropri- apparently random points in a document. graph occurring at designing a word processor as to employ the same techniques for ate or cost-effective for a well-designed product avionics systems, but the need for designing safety-critical of major road-bridges and the parallel might apply to the design is still there. The same complexities are very dif- the dentist’s waiting room: the structural design of seating in enough to meet our needs. them are expected to function well ferent, but both of accept that the software used in an aeroplane needs to be well designed and rigorously designed to be well needs an aeroplane used in software that the accept one on that aircraft as passengers might find themselves least because they tested, not still since the user smaller systems too, desirable for good design is equally day. Yet suffers from a simi- reliability (which only be defined) and (if it can requires efficiency not processor may manner). A word to define in a precise of being difficult lar problem occasional lost para- to appreciate the its user is unlikely item, but be a safety-critical SDC01 9/18/07 10:34 AM Page 5 AM Page 10:34 9/18/07 SDC01 Evaluation Construction Path of engineering Making of ‘new’ things (pyramids, ships, cars, telephones, etc.) (pyramids, ships, cars, has been much more concerned with creating has been much more concerned with Better tools measurement, etc. Human endeavours/ interaction with the world interaction engineering Better understanding of materials, Better understanding of Observation Measurement Path of science Experimentation The complementary nature of scientific and engineering activities. The complementary nature of scientific and Study of things as they are Study of things as they things, with the key activities involved being those of construction and evaluation. things, with the key activities involved (astronomy, biology, chemistry, etc.) chemistry, biology, (astronomy, The descriptions of both of these processes provided in Figures 1.2 and 1.3 are of The descriptions of both of these processes provided in Figures 1.2 and 1.3 The terms ‘black box’ and ‘white box’ used in Figure 1.3 merit a brief description Of course, these two paths are not isolated from one another. Indeed, the interplay Of course, these two paths are not isolated here, and will be discussed more fully in Chapter 5. Briefly, a ‘black box’ model is here, and will be discussed more fully in Chapter 5. Briefly, a ‘black box’ as a whole, one that describes the external functionality and behaviour of a system box’ model is without any reference to how this is to be achieved. In contrast, a ‘white eering processes. of the gen- course relatively simplified. A rather more detailed and ‘formal’ description eral design process is provided by the FBS framework (Function–Behaviour–Structure) described in Gero (1990). between them has always provided an important element for both. The products of between them has always provided tools for advancing scientific knowledge (from ‘engineering’ have formed important and measurements of science have pro- clocks to cyclotrons), while the observations materials that engineers need in order to use vided the understanding of their basic While the practices of both involve building them in new ways and to most effect. used for very different purposes, as is shown in ‘models’ of a problem, these are then and contrast the forms of the scientific and engin- Figures 1.2 and 1.3, which summarize we can generally refer to as new directed much more towards achieving a goal (or As Jones observes, these activities are hence they begin by assuming an end result ‘effect’) than conducting an investigation; this about. and then go on to seek ways of bringing Figure 1.1 of observing the characteristics of some phe- to problem-solving typically consists these, building a theory to explain them (and nomenon, making measurements of and then seeking to verify these pre- preferably to predict additional characteristics), and measurements. In contrast, the path of what dictions through further observation

6 The nature of the design process SDC01 9/18/07 10:34 AM Page 6 AM Page 10:34 9/18/07 SDC01 7 What is design? observations More systematic observations Experimental New predictions Predictions from theory observations Experimental Initial observations The nature of scientific analysis. So if we examine the quotation from Jones a little more closely, and rephrase it a So if we examine the quotation from Jones a little more closely, and rephrase Since software can be considered a prime example of an artifact, we can see why Since software can be considered a prime of design differs somewhat from the case of scientific investigation, since for the latter of design differs somewhat from the case of scientific investigation, since This set it is unusual for there to be more than one equivalent solution to a problem.) of actions can be summarized as: more complex, not least because design and implementation may be less distinctly sep- more complex, not least because design and implementation may be less distinctly arated, but it does not alter its essential nature. a designer in little, we can identify the set of actions that need to be performed by be more than deriving and specifying a solution to a problem. (There may, of course, the process one possible solution; indeed, this is generally so, and this is again where parent’ would in many ways be better ones, but ‘black box’ and ‘white box’ are the parent’ would in many ways be better ones most widely employed.) of design are so important in its production. an understanding of the techniques disciplines in general, in that they are Indeed, this is true of the craft and engineering of artifacts, whether these be bridges, buildings, usually concerned with the production of software may make this design process statues, cars or space probes. The nature Figure 1.2 are described. (The terms ‘opaque’ and ‘trans- one in which the workings of the system SDC01 9/18/07 10:34 AM Page 7 AM Page 10:34 9/18/07 SDC01 4 2 Design plan of prototypes) (including use Functional Validate solution Validate specification problem box’ model of Analyse needs and build ‘black specification Requirements 5 form of List of mismatches software Functional Implementation using a suitable specification of the design plan 1 Clarify nature of White box model requirements 3 design solution ‘white box’ Postulate a External A model of the design process. requirements postulate a solution; build a model of the solution; evaluate the model against the original requirement; elaborate the model to produce a detailed specification of the solution. We will be using this very general ‘process model’ again at various points, and will make We will be using this very general ‘process model’ again at various points, and for software use of it to build up our own models of the various design processes used n n n n Figure 1.3

8 The nature of the design process SDC01 9/18/07 10:34 AM Page 8 AM Page 10:34 9/18/07 SDC01 9 What is design? Moving house Moving . a small single- Figure 1.4 shows an example of such an outline plan for Outline plan of a single-storey house. One practice widely recommended to the new owner is to begin by measuring the One practice widely recommended to At this point it may be useful to look at an example of a design process, and to be useful to look at an example At this point it may culties or suggests better objectives, the pattern of the original problem may change better objectives, the pattern of the original culties or suggests one.’ the designers are thrown back to square so drastically that ‘If, as is likely, the act of tracing out the intermediate steps exposes unforeseen diffi- steps exposes out the intermediate the act of tracing ‘If, as is likely, CASE STUDY 1 Figure 1.4 next step is to measure the dimensions of various items of furniture and to cut out next step is to measure the dimensions on the chosen scale. Together these form a repres- cardboard shapes to represent these contents that can be considered as forming the entation of the new house and its future initial model storey house. Moving to a new house is widely regarded as one of the major traumas in our lives. Moving to a new house is widely regarded lies a very good illustration of what designing However, hidden within this operation we briefly examine some of the actions that can involve, and so for our case study into a new house. might be involved when planning a move house, to obtain some squared paper and to use dimensions of the various rooms in the all the rooms, doors, windows and so on. The this for drawing up a scale plan showing use this to demonstrate how the practices of design may differ from those of scientific how the practices of design may use this to demonstrate analysis. In other words, the act of elaborating the original model might reveal its inadequacies or act of elaborating the original model In other words, the of design essentially unstable. so making the whole process even its total unsuitability, development. However, it should also be recognized that while there is an order to these an order there is that while also be recognized it should However, development. neces- It is usually precise sequence. a single, in performed by no means they are actions, as the design process, different stages of between the many iterations sary to perform of design choices. for the revision that may be needed backtracking well as extensive be even worse, since: the position may has recognized, Jones (1970) himself Indeed, as SDC01 9/18/07 10:34 AM Page 9 AM Page 10:34 9/18/07 SDC01 outlet that can be adopted: for example, strategies that apply to the various possible solutions will be more that apply to the various possible solutions constraints Expanded plan of a single-storey house. Expanded plan of a single-storey for use by the removal team on the removal day. Indeed, not only will it deter- for use by the removal team on the removal day. Indeed, not only will The decisions that result from this process can then be regarded as providing a The decisions that result from this process can then be regarded as providing Some of the as described above is somewhat incom- The representation provided by the model The design process itself then involves trying to identify the ‘best’ positions for the The design process itself then involves plan removal van mine just where in the house the various items are to be placed when the since arrives, but it may also affect the way that the removal process is to be organized, to make the the removers might choose to pack their van in a particular way in order unloading process easier. plete, since it is only two-dimensional. On occasion it will be necessary to consider the plete, since it is only two-dimensional. blocking windows with tall furniture, or to vertical dimension too, in order to avoid accessible through the legs of an item of furni- ensure that a power outlet will still be some trade-offs between what is desirable and ture. Again, it may be necessary to make how the model used in Figure 1.4 can be what is practicable. Figure 1.5 shows extended to describe these factors. significant than others. Most people would not wish to place kitchen equipment in the significant than others. Most people be prepared to position surplus fireside chairs in living-room, for example, but might constrain the choice could be colour matches, a bedroom. Other factors that might to obstruct power outlets – a point that leads style and so on. Equally, it is undesirable on to our next issue. be used to do this, since it is usually necessary to trade off different factors in making be used to do this, since it is usually the choices. However, there are various priority, and then seek to find ways of pro- determine which rooms will take greatest for those rooms. This strategy may lead to ducing a well-matched set of furniture rooms than would occur if the owner tried for an greater mismatches in the remaining overall best match. Figure 1.5 house. There is really no analytical form that can pieces of card on the plan of the new

10 The nature of the design process SDC01 9/18/07 10:34 AM Page 10 AM Page 10:34 9/18/07 SDC01 11 What is design? . reuse The garden shed The garden Apart from the cost of the timber, the main cost to consider in developing a new Apart from the cost of the timber, the The manager of the shed production unit therefore needs to produce a set of The manager of the shed production Before going any further, it may be useful to take a brief look at another example it may be useful to take a brief Before going any further, However, in some senses the problem that is presented in this case study provides senses the problem that is presented However, in some A shed should be assembled from a set of prefabricated panels for the sides and A shed should be assembled from a set of prefabricated panels for the roof. be of Assuming that the boarding on the sides runs horizontally, each panel should a height that allows it to be constructed from a whole number of boards. CASE STUDY 2 therefore led to the following set of design constraints. n n direct, but this time there are some constraints upon the form of the end result that are direct, but this time there are some constraints problem. These do not constrain the form rather different from those of the previous influence it indirectly in terms of their effect of the design process directly, but they upon the design product. Since sawing timber is very time-consuming, shed is the cost of fabricating the parts. to a minimum. Consideration of this factor has the amount of sawing needs to be kept producing various standard sizes of timber. As a sideline, they are developing a new producing various standard sizes of to construct a small range of garden sheds. production unit that will use the timber by using a set of prefabricated panels, so These sheds will all need to be constructed home with relative ease. that they can be assembled at the customer’s Much of the process for doing this is relatively designs for a number of different sheds. ware development, but this problem possesses a set of constraints that some readers ware development, but this problem In particular, it introduces the concept of will probably be more familiar with. concerned with operating sawmills and with The Lotsalogs timber company is chiefly Similarly, the ‘designer’ is able to manipulate well-defined ‘objects’, in that each item is able to manipulate well-defined Similarly, the ‘designer’ is, its dimensions) are fixed, exists and its relevant properties (that of furniture already for software objects will gener- The equivalent properties and can easily be measured. quantifiable or even identifiable. ally not be so easily from a more traditional field than that of soft- of a design problem. Again, it is taken a much simpler environment than is often available to the software designer. The form than is often available to the a much simpler environment related to that of the final used to describe the problem is directly of the initial model drawings of the building. So the solution, in that both are scale plan used to describe used to describe the prob- ‘transform’ between the representation there is no need to the case for software design. to describe the solution, as is generally lem and that used From this relatively simple case study, we should be able to see some of the ways in of the to see some be able should study, we case simple this relatively From being than Rather method. that of scientific from differs of design the process which and the variables allows us to separate system that a ‘right’ coordinate able to identify model, and then make complex have to build a relatively each separately, we solve for many possible ‘solu- There may be to produce a solution. to this in order adjustments in be used to help us criteria that can no very strong we may well have tions’, and the better ones. from a number of choosing SDC01 9/18/07 10:34 AM Page 11 AM Page 10:34 9/18/07 SDC01 Assembling sheds from standard units. Figure 1.6

12 The nature of the design process SDC01 9/18/07 10:34 AM Page 12 AM Page 10:34 9/18/07 SDC01 13 What is design? quality and the way that it can be used in such a system. Modularity is an and the way that it can be used in The next section seeks to establish a clearer picture of the designer’s goals, and to The next section seeks to establish a clearer picture of the designer’s goals, In one case the end product is an organizational plan for the removal men, in the In one case the end product is an organizational For both of the case studies introduced here, we can see how the concepts of design For both of the case studies introduced Given the original requirements that were identified by the company, and the con- requirements that were identified by Given the original As we observed for the previous case study on moving house, there is no evident the previous case study on moving As we observed for Where possible, the panels used in one shed should be of a size that allows them to allows them size that be of a should in one shed used the panels possible, Where used also be shed could a small panel for the side example, for in another: be used model. panel for a larger as the back the height of each and again be of standard dimensions, and doors should Windows the time needed in order to reduce number of boards, to a whole should correspond out special shapes. for cutting modularity clarify how these can be described for software systems. sheds. For both cases there are constraints operating upon the process, although these sheds. For both cases there are constraints operating upon the process, although of have very different forms, and in both cases the designer has some concept and colour to help with making choices. In the one case this may be the balance of style shed that has for the furniture in a room, in the other it will be a matter of producing a concept, the ‘right’ proportions and which is easily fabricated. Quality is an elusive although an important one, and it is one that we will be returning to later. although the nature of the two problems is very different. In both cases the designer although the nature of the two problems or she wants to achieve – an organized house or proceeds to build a model of what he the model until satisfied that it can meet the a balanced range of products; modifies it in order to specify clearly what needs to particular constraints; and then elaborates be done to turn the model into reality. that will be used by the joiners who produce the other it is a set of plans and drawings important tool in construction, and it is as important for constructing software as important tool in construction, and blocks and the like. However, it is not always for constructing garden sheds, tower form it should take when we are designing quite so easy to see the most effective software. to the processes involved in producing a solution, as described by Jones can be related the panels can be assembled to create different sheds, as shown in Figure 1.6. the panels can be assembled to create further to provide more insight into the Obviously this problem could be explored can begin to see the importance of the basic idea design process, but for the moment we of automatically meet all of the criteria, as well as being visually pleasing and practical to all of the criteria, as well as being visually automatically meet be more direct than for of the problem, the process will certainly use. Given the nature and iteration of ideas. but it will still involve some feedback the previous case study, for reuse of components, the the nature of the material and the need straints created by drawings showing the dimensions of each panel, outcome of the process will be a set of from the basic units of timber, and the ways that the way that it should be assembled These effectively form constraints upon the design process too, and the designer will constraints upon the design process These effectively form size and shape of the range of a number of practical issues about also need to consider products. for garden sheds that will be used to produce a set of designs prescription that can n n SDC01 9/18/07 10:34 AM Page 13 AM Page 10:34 9/18/07 SDC01 this is to be organized. this is to how in its broadest sense as the most probable in its broadest sense . One consequence of the industrial revolution reuse architecture of sailing ships, it certainly simplified their fitting out and reduced its cost (Rolt, 1970). design The designers of pyramids and cathedrals will almost certainly have exchanged The designers of pyramids and cathedrals The recognition of design as a distinct and identifiable task then introduces the design as a distinct and identifiable The recognition of Just when this concept of the design task having a distinct role in the production a distinct role design task having this concept of the Just when extends a designer’s repertoire – on the one hand offering speedier development of extends a designer’s repertoire – on the one hand offering speedier development intro- an idea (‘improved time-to-market’) with potentially lower costs, but also ducing new constraints and trade-offs into the design process. knowledge in helping to create new structures. A good example is that of bridge knowledge in helping to create new engineers such as I K Brunel were able to building in the nineteenth century, when different from their predecessors, while also create structures that were radically proving to be remarkably durable. The existence of such components was the idea of ‘standardizing’ components.* erties of materials became better understood, and the means of predicting their erties of materials became better understood, dependable, so the designer could employ this behaviour became more refined and production of the blocks that formed a major element in the rigging of a sailing vessel. While this might not have production of the blocks that formed a major element in the rigging of a sailing vessel. While this influenced the installed in the Portsmouth dockyard in the early 1800s. The intention here was to improve and standardize the installed in the Portsmouth dockyard in the early 1800s. The intention here was to improve and * block-making machinery, One of the very earliest examples of standardization of components was Sir Marc Brunel’s 2. The second was the concept of there significant new inputs to the designer’s learning processes. Two of these are there significant new inputs to the of their longer-term implications for software worth noting here, not least because design. 1. research. As the prop- The first of these was the knowledge gained from scientific might also note that great engineering designers have also maintained ‘sketchbooks’ might also note that great engineering ‘commonplace book’ (Isambard Kingdom (Leonardo da Vinci) or the engineer’s and to provide a form of ‘pattern book’ for con- Brunel) both to aid their own thinking veying these ideas to others. However, each of the resulting artifacts was ideas with, and learned from, their peers. the emergence of engineering practices were a single unique creation, and only with question of how is a designer to learn their trade? For many centuries this was prob- a designer to learn their trade? For question of how is whether formal or through some form of ‘apprenticeship’, ably achieved primarily in many creative disciplines. there is still a strong element of this otherwise, and today is considered by some to be a very valuable Indeed, the concept of the ‘design studio’ software design too (Tomayko, 1996). We and effective route for teaching about of an artifact first began to emerge is likely to remain largely a matter for conjecture. began to emerge is likely to remain of an artifact first times, such as the pyramids, any of the major creations of ancient It is unlikely that of ‘design planning’, and so it without a significant degree could have been achieved to identify seems reasonable of design and construc- separation from the craft-level entwining domain where this begun. tion is likely to have 1.2 activity the design of role The the is to specify task for the designer section, the principal in the previous As we saw of and produce a description to a problem best solution of implementors be used by the eventual a ‘plan’ that can then forms This description the system.

14 The nature of the design process SDC01 9/18/07 10:34 AM Page 14 AM Page 10:34 9/18/07 SDC01 15 The role of the design activity with those responsible for domains – and has some important has some – and domains all communication Here we begin to discern one of the more distinctive features of software design. Here we begin to discern one of the more distinctive features of software From this, we can rightly conclude that From this, we can rightly conclude that to the design process and may address a This specification is an important input In addition, the plans produced by the designer may need to indicate some In addition, the plans produced by Returning briefly to the two case studies that were introduced above, we can see were introduced case studies that briefly to the two Returning a plan that informs the removal men where each major item of furniture is to be the removal men where each major a plan that informs positioned; of the panels and how the the joiner about the dimensions a set of plans that inform and so on. panels are to be jointed range of projects – for engineers such as I K Brunel, the designing of bridges, railways, range of projects – for engineers such as I K Brunel, the designing of bridges, opted for station buildings and ships were all part of their portfolio. Later ages have what distinguishes all of the examples used so far is that we can assume that the what distinguishes all of the examples used so far is that we can assume example, we designer is familiar with the context of the problem. Indeed, in this last as part of the would not expect that the purpose of a table would need to be explained specification. tackle a wide In the nineteenth century, the great Victorian engineers were prepared to wide range of factors. At the one extreme it may consist of a rather imprecise and gen- wide range of factors. At the one extreme the ‘customer’ trusts entirely to the designer eral requirement for a solution in which baron requires the craftsman to design a beech- to find the ‘best’ form (the medieval enough for 20 guests at a major feast). At the wood table for their great hall, large many constraining factors (a design for a table other it may provide details of very village halls, needing to be cheap to fabricate, which is to be produced for use in light enough to be readily moved). However, durable, easily cleaned, stackable, and fabricating the eventual solution is likely to be an important part of the designer’s role, fabricating the eventual solution is likely However, an equally important channel of especially for larger-scale developments. the ‘requirements’ specification that a designer is communication is with the source of this may take and however it may be obtained. being asked to address, whatever form information about the sequencing of operations in the eventual construction process. information about the sequencing of may need to be positioned before or after In the first example, some items of furniture to move items past them; and in the sec- others, perhaps because it will be difficult may indicate any significant ordering that ond example, the directions for assembly expect to erect all of the walls before beginning may be necessary. (We would generally to place the roof in position.) The first of these is largely approximate (the extent to which this is true is, of course, largely approximate (the extent to The first of these is repositioning a piano). The a chair is a less daunting task than variable: repositioning of tolerance that is accept- degree of precision, and the degree second requires a greater part of the plan. So the form of may well need to be specified as a able in the product not only upon the nature of the from the design process depends the output produced its eventual implementation. problem, but also upon the nature of n n It might well be argued that while the first of these has had its most important impact important its most has had of these the first that while argued well be It might has affected the second design’, in ‘engineering a topic in its own right return to this as too. We will for software design consequences 16 and 17. in Chapters as can be described in form. They are somewhat different for these that the objectives produce respectively: aiming to SDC01 9/18/07 10:34 AM Page 15 AM Page 10:34 9/18/07 SDC01 to hesit- Plans for realization of the design ought Domain knowledge The designer’s channels of communication. specification Requirements To continue with the needs of software development: it is clear from the above the needs of software development: To continue with One of the problems that this introduces, therefore, is that a software designer that this introduces, therefore, One of the problems Constraints production to proceed. The form and extent of the plans will be determined by the production to proceed. The form and chosen, as well as by the size of the design practices and means of implementation the software designer may need to be responsive to many channels of communi- may need to be responsive to the software designer in Chapter 3, while some of the that will be addressed further cation. This is an aspect examined more fully in later the domain knowledge will also be ways of transferring chapters. is to produce the plans necessary for software that the main task of the design phase types of application. as a routine part of the input some degree of ‘domain knowledge’ may need to acquire of this may be obtained from any particular design task. Some needed for undertaking but by no means all of the may well run to hundreds of pages), the specification (which So, as shown in Figure 1.7, is likely to be available in this way. necessary knowledge greater degrees of specialization, however, and we are unlikely to find an aeronautical to find are unlikely and we however, of specialization, degrees greater is less of specialization This degree tanker! a new oil design for the producing engineer back to the more in some ways harks development, which in software marked though is in across what – whilst being applied in an earlier era practices witnessed generalist in (say) database Admittedly a specialist of domains. a much wider range many ways least, system (or at a real-time control hesitate to design design might to design both the necessary expertise could possess in principle, one person ate) but, Figure 1.7

16 The nature of the design process SDC01 9/18/07 10:34 AM Page 16 AM Page 10:34 9/18/07 SDC01 17 The role of the design activity functions ; and so it becomes neces- process as well as its structure, and also the on the form of a design, as shown in Figure 1.8. behaviour viewpoint We will return later to consider more fully the ways in which the dynamic nature We will return later to consider more fully the ways in which the dynamic For software systems, however, a further degree of complexity has to be consid- For software systems, however, a further usually make use of a number of different To meet these needs, the designer will As in many more ‘classical’ forms of engineering, software designers produce plans As in many more ‘classical’ forms of Typically, such plans will be concerned with describing: concerned with such plans will be Typically, programming language); these should take, and the components, including the form interactions between links. nature of any causal any data objects to be used in the system; any data objects to used; the algorithms to be are grouped in compi- system, in terms of how components the packaging of the a conventional imperative that implementation will use lation units (assuming the static structure of the system, including any subprograms to be used and their subprograms to including any structure of the system, the static hierarchy; moment we will continue to focus our attention upon the nature of the design process moment we will continue to focus our attention upon the nature of the design in general. tation providing a different understand The more complex the system, the more we need a full set of viewpoints to for it to be its behaviour, and to provide a specification that is sufficiently complete used as an aid in the construction of the system. for the of a software system influences (and complicates) the process of design; that it will perform. So the designer’s model will ideally include descriptions that also that it will perform. So the designer’s system. encompass these aspects of the eventual with constructing the model, each represen- forms of design representation to help ered. For designing software consists of designing a ered. For designing software consists sary to model and describe its This usually requires the use of a variety of forms of representation, since each of these This usually requires the use of a variety In a way, the use of these multiple views corres- provides a different ‘view’ of a system. end views in technical drawing, as well as to ponds to the use of plan, elevation and assembly details. (The concept of tolerance the cross-sectional forms used to indicate components generally have to ‘fit’ rather is perhaps lacking though, since software precisely.) oriented plans too, concerned with such matters as the preferred order of development oriented plans too, concerned with such and the strategy for their eventual integration for subprograms/modules and so on, rather like the assembly directions that are needed into the complete system. (These are However, for the moment we will chiefly concern for construction of the garden shed.) product. ourselves with the needs of the design to be assembled in terms of the items listed above. that specify how the final product is n design product itself. But as with specifying the form of the These are all concerned task may also involve producing process- was observed above, the overall design n n n system being developed. Clearly, in a large project employing many programmers programmers many employing project in a large Clearly, developed. being system needed will be factors than range of wider a much to capture will need plans the design too. may well be the programmer the designer project, where by the one-person n SDC01 9/18/07 10:34 AM Page 17 AM Page 10:34 9/18/07 SDC01 can also help Representations plays a very important part, since to abstraction can provide strategies that will help to determine which can provide strategies that will help patterns and Examples of design viewpoints. methods The concept of abstraction is enormously important for all branches of engineer- The concept of abstraction is enormously important for all branches of The designer has a number of tools to help with the task of problem-solving. The designer has a number of tools Throughout all of this, the designer needs to keep in mind that the ultimate Throughout all of this, the designer The purpose of design is simply to produce a solution to a problem. The problem The purpose of design is simply to produce ing. Essentially, abstraction is concerned with the removal of detail from a description ing. Essentially, abstraction is concerned with the removal of detail from In our first of a problem, while still retaining the essential properties of its structure. behaviour. In combination with these, abstracting build manageable models of large and complex systems we need ways of the designer their critical features for use in forming our models. Abstraction enables into to concentrate effort on building a logical model of a system, which is translated a physical model at a relatively late stage in the design process. but simply that they are subordinate to the need to produce a system that does the but simply that they are subordinate elegant or efficient a system may be, it will be required job. However well structured, its purpose. assessed ultimately on how well it achieves Design a given situation. choice may be most appropriate in of the intended system and with evaluating its with the process of building models complex and may involve trade-offs between factors such as size, speed and ease of complex and may involve trade-offs factors. adaptation, as well as other problem-specific However elegant or efficient the final solu- requirement is one of fitness for purpose. work and that it should do the required job tion, the basic two needs are that it should that other factors and qualities are not important, as well as possible. This is not to say and reminding ourselves of the ultimate purpose of design. and reminding ourselves of the ultimate of some form of requirements specification, and will typically be summarized by means description of how that requirement is to be met. it is the designer’s task to provide a task, and the examples given show Design is therefore essentially a problem-solving process of design involves the designer in evalu- that it is not an analytical process. The choices using decision criteria that may be ating different options, and in making 1.3 process problem-solving a as Design having examined its role and the nature of the design process, and Having considered it is worth stepping back for a moment objectives in terms of software development, Figure 1.8

18 The nature of the design process SDC01 9/18/07 10:34 AM Page 18 AM Page 10:34 9/18/07 SDC01 19 Design as a ‘wicked’ problem Social planning has many examples of such ‘wicked’ problems. One of the better- Social planning has many examples of such ‘wicked’ problems. One of the A ‘wicked’ problem demonstrates some interesting properties. It can be charac- A ‘wicked’ problem demonstrates some Abstraction therefore plays a key role in this book, corresponding to its central Abstraction therefore plays a key role This concept of abstraction is a very important one, and it is one that novice soft- is a very important one, and This concept of abstraction people who previously lived in substandard housing may have improved living condi- people who previously lived in substandard housing may have improved In some tions, but at the cost of destroying communities and other social frameworks. terized as a problem whose form is such that a solution for one of its aspects simply terized as a problem whose form is such that a solution for one of its aspects and arose changes the problem. The term was coined by Rittel and Webber (1984), design issues from their analysis of the nature of social planning problems and of the that were involved in these. blocks of known is evident in many large cities in the UK, where rehousing in tower lytical form, with one important consequence being that there may well be a number lytical form, with one important consequence Because of this, the process of design will of acceptable solutions to any given problem. being able to direct the designer towards a single rarely be ‘convergent’, in the sense of of the ‘wicked’ (as opposed to ‘benign’) prob- preferred solution. Indeed, the notion a process such as that of design, suggests that lem, which is sometimes used to describe it is potentially unstable. 1.4 problem a ‘wicked’ as Design of the nature of the design process, we should Before concluding this general review that the issues discussed in the previous sections briefly consider some of the effects to draw is that the design process lacks any ana- have upon it. The major conclusion role in design. In considering the forms of design representation that can be used for role in design. In considering the forms at ways of modelling a system using different different purposes, we will be looking methods, we will be seeing how the practices abstract viewpoints. In looking at design the designer to think about a system in an that they involve are intended to encourage is a key skill that any designer needs to abstract way. The effective use of abstraction learn and practise. gramming language structures when thinking about design. The designer needs to structures when thinking about gramming language of events, entities, objects, a system in an abstract way – in terms learn to think about questions of detail, such as key items are appropriate – and to leave or whatever other algorithm, until a relat- of loop construct to be used in a particular the specific forms design process. ively late stage in the this would be a very incomplete description of the whole structure, but it would retain incomplete description of the whole this would be a very purpose. that was essential for the particular the basic information (Adelson and Soloway, apt to find difficult to employ effectively ware designers are a wonderfully pliable medium, are accustomed to working with 1985). Programmers detailed features of pro- easy to be over-influenced by relatively and so it is all too case study, the outline plan on squared paper provided an abstraction of the idea of a of the abstraction an provided paper plan on squared outline study, the case the for solving needed that were of information those forms only It retained house. information about areas – together with two-dimensional problem – namely particular a house is a highly and so on. Clearly power outlets of doors, windows, positioning is abstraction that is the particular plan object, and the two-dimensional complex a quite different of rewiring the house, For the task this specific occasion. needed on diagram. Again, of some form of circuit based on the use would be needed, abstraction SDC01 9/18/07 10:34 AM Page 19 AM Page 10:34 9/18/07 SDC01 solution to a prob- the Rittel and Webber identified ten distinguishing properties of wicked problems, properties of ten distinguishing Webber identified Rittel and the conclusions there (that better project management is the answer) are simplistic, the conclusions there (that better project management is the answer) are ones! and, indeed, reflect a failure to really understand that the problems are wicked particularly true for large-scale software systems such as those dealing with major particularly true for large-scale software systems such as those dealing with resources national activities, for example paying pensions, collecting taxes, etc. The pos- needed to explore different options are simply not available, and it is rarely sible to ‘unpick’ changes to operational practices once these have been implemented of in order to meet the needs of such systems. Some good examples of the problems although creating and installing large public systems are illustrated in PAC (1999), simple exercise such as a comparison of the features of (say) a number of web simple exercise such as a comparison way in which their features need to be browsers can demonstrate the multi-faceted of any one criterion that can be used to estab- classified and compared, and the lack lish which one is ‘best’ in any sense. is a ‘one-shot operation’, because there is no Every solution to a wicked problem every attempt counts significantly. This is opportunity to learn by trial-and-error, there are usually no right or wrong solutions or structures. (This point will be there are usually no right or wrong cause to mark a set of student programming evident to anyone who has ever had assignments.) test of a solution to a wicked problem. The There is no immediate and no ultimate system evaluation process adequately demon- difficulties inherent in any form of of software. Indeed, even an apparently strate that this is very much a characteristic lem has been found, such that any further work will not be able to improve upon lem has been found, such that any further by our lack of any quality measures that can it. For software, this is demonstrated design is the ‘best’ one possible. be used to establish that any one system true or false, but good or bad. For many sci- Solutions to wicked problems are not we may be able to identify whether a entific and classical engineering problems, usually come in ‘shades of grey’, in that solution is correct or false. Software designs also make the point that the specification and understanding of such a problem is that the specification and understanding also make the point it – which is why the sim- ideas that we may have about solving bound up with the followed neatly by that of in which the task of specification is ple life-cycle model description of actual practices. design is rarely a realistic Essentially this property implies that there Wicked problems have no stopping rule. to establish when is a lack of any criteria that can be used There is no definitive formulation of a wicked problem. The difficulties of specify- formulation of a wicked problem. There is no definitive known, and the tasks of software-based systems are well ing the needs of clearly. Rittel and Webber are often difficult to separate specification and design n n n n most of which can be seen as applying equally well to software design (Peters and be seen as applying equally well most of which can list, are particularly relevant. following properties, taken from their Tripp, 1976). The n cases, the living conditions may also be little better or even worse, owing to architec- to worse, owing or even better also be little may conditions the living cases, untried materials. with relatively blocks the tower construct to design decisions tural less ones that are even or created new has revealed the original problem So removing of software systems; maintenance a similar effect during There is sometimes tractable. of massive redesign require feature may subsequently relatively innocuous adding one subprograms. reorganization of structures and internal data

20 The nature of the design process SDC01 9/18/07 10:34 AM Page 20 AM Page 10:34 9/18/07 SDC01 21 Design as a ‘wicked’ problem which assist with exploiting similarities which assist with exploiting design patterns by the designer in order to apply them to a given problem, which, order to apply them to a given problem, by the designer in interpretation Unfortunately the process of producing a design is not like that at all. In working Unfortunately the process of producing These ideas are somewhat at variance with the ideas that are generally encoun- These ideas are somewhat at variance Every wicked problem can be considered to be a symptom of another problem. can be considered to be a symptom Every wicked problem pose another problem in or inconsistency in a design may Resolving a discrepancy of data structure that helps a computer program, a choice its turn. Again, in writing of an entirely new difficulty problem may in turn be the source with resolving one later. Every wicked problem is essentially unique. Of course, there are similarities is essentially unique. Of course, Every wicked problem at ideas about reuse and systems, and in later chapters we look between software such as about mechanisms require some degree experience. However, all such techniques to aid reuse of design of why design activities cannot be automated. of course, is precisely Wicked problems do not have an enumerable (or an exhaustively describable) set describable) an exhaustively (or enumerable have an do not problems Wicked for software. true this as being readily recognize We can solutions. of potential may implement programmers design plan, different there is an agreed Even where the characteristics this is one of structures. Indeed, quite widely differing this using solutions to ‘sci- solutions and the between ‘design’ differentiates that strongly entific’ problems. need to handle one event adequately might lead to the occasional exclusion of know- need to handle one event adequately might lead to the occasional exclusion ledge about some other event that can occur independently. adequate. An example of just such a ‘wicked’ problem feature is often encountered in adequate. An example of just such a ‘wicked’ problem feature is often encountered so that it can designing real-time systems. It may be possible to organize the system the way that produce a response to one type of event within some required interval, but that it will this is achieved may place such constraints upon the operation of the system (since the then be unable to meet some other demand in an adequate time. Worse still the new problem might well be overcome by increasing the computer power available), this fails to work, we can always try another criterion for separation, such as using a this fails to work, we can always try try adopting polar coordinates rather than different coordinate system (we might cartesian coordinates). makes various choices, and the consequences back from the initial model, the designer such as to make further choices much more com- of any of these choices may well be the overall design itself may be shown to be in- plicated to resolve. In the extreme, expect that some form of convergence will occur, leading us to a single solution to a expect that some form of convergence typically aims to reduce a problem in such a problem. The use of ‘scientific’ methods developing a solution leads to a set of simpler way that each step in the process of the description of the motion of a system into problems. As an example, separating coordinates may result in the formulation of descriptions of motion in each of three be solved independently, or nearly so. And if three separate equations that can then A slightly different but related view of design problems is that of Herbert Simon A slightly different but related view of well-structured and ill-structured problems (1984). He has introduced the idea here to elaborate further on these ideas but, as (WSPs and ISPs). There is no space design emerges as having the properties of one might expect, the task of software an ISP. approach to problem-solving, where we might tered in the ‘classical’ or ‘scientific’ n n n SDC01 9/18/07 10:34 AM Page 21 AM Page 10:34 9/18/07 SDC01 physical and logical Wiley International Wiley a requirement is to be met by the design a requirement is to be how Design Methods: Seeds of Human Futures. Design Methods: Seeds of Human Futures. forms provide means of modelling ideas about a design, and also of of modelling ideas about a design, and forms provide means Developments in Design Methodology. Butterworth is used in problem-solving, and is used to help separate the is used in problem-solving, and is used to representation Problems like these can be hard to resolve, since concentrating upon solving one solving upon concentrating since to resolve, be hard these can like Problems Airline A is cheap, but involves flying to Chicago, waiting there for three hours and then flying Airline A is cheap, but involves flying to Chicago, waiting there for three hours and aspects of the design process; one and this imposes constraints upon the way in the software design problem is a ‘wicked’ and managed. which the process of design can be organized the design process is concerned with describing the design process is product; design presenting the design plans to the programmer; abstraction Exercises Further reading Summary This journal of the Design Research Society provides an insight into design issues affecting a This journal of the Design Research Society provides an insight into design issues wide range of fields of application for design techniques. 1.1 to plan a journey by air from Manchester in England to Pittsburgh in the USA. You are asked Cross N. (ed.) (1984). contains some significant contributions from authors This collected set of articles and papers is a strong and valuable input from a number of such as Horst Rittel and Herb Simon. There science to the study of design and designing. authors who bring the ideas of cognitive Design Studies. Jones J. Christopher (1970). an excellent degree of insight into the nature of the The opening chapters of this book provide directly relevant to the issues of software design. design process. The later chapters are less n n n n This chapter has sought to examine the nature of the design process in fairly general terms. It has to examine the nature of the design process This chapter has sought later, and will be described in of concepts, many of which will reappear introduced a number ideas presented in this chapter are: Some particularly important greater detail where appropriate. aspect in isolation (such as handling the single event) may eventually result in an result eventually event) may single the as handling (such in isolation aspect our problem becomes all. In such cases for the second at produce a solution inability to a them out is not needs, since separating to the combined a solution one of producing valid option.

22 The nature of the design process SDC01 9/18/07 10:34 AM Page 22 AM Page 10:34 9/18/07 SDC01 23 Exercises storage. lem criteria? The need is for a portable timepiece, to be carried in a pocket, or even (if possible) worn timepiece, to be carried in a pocket, The need is for a portable equal-sized portions, num- have a circular dial, divided into twelve on one’s wrist. It will centre of the dial: one (the will be fixed to a spindle in the bered 1 to 12. Two pointers pointer will rotate once once per hour, while the second (shorter) longer one) will rotate of running unattended for at least 24 hours every 12 hours. The device should be capable position in order to work correctly. and should not need to be kept in a fixed in planning a new garden that is to have a lawn, patio, path and vegetable plot. Draw a dia- in planning a new garden that is to have a lawn, patio, path and vegetable plot. Draw gram showing the different abstractions used as the plan develops. detailed plans to help someone make this item? detailed plans to help someone make this of instructions for making tea with a teapot and actions. Sketch out a design for a set that might arise (no water in the kettle, burst teabags. Try to consider the major problems you organize the instructions for these exceptional teabag, no kettle and so on). How would original design? situations so that they do not obscure the (b) a wooden storage rack for audio cassettes (c) height and taken apart for carrying and a metal music stand that can be adjusted for design, and what changes you made to it as your Then think about how you reached your do you think might occur if you had to produce thinking developed. What further changes This problem is a good demonstration of why the simplistic approach sometimes advocated This problem is a good demonstration of requirements specification as a means of pro- in favour of stepwise refinement of a formal for most real systems. ducing a design is unrealistic and impractical (a) a rocking chair (to be made from timber) are sundials and large pendulum clocks. Given the following requirements specification, pendulum clocks. Given the following are sundials and large it by creating a suitable design begin exploring the ways of meeting suggest how you might solution: on to Pittsburgh. Airline B is the most expensive, but offers a direct flight. Airline C has a Airline C flight. a direct but offers expensive, is the most Airline B Pittsburgh. on to from Manchester to which involves flying of airline A, but is cheaper than that package that airport in the USA. via yet another then on to Pittsburgh near London, and Gatwick Airport (a) your choice of airline? price might affect What factors besides (b) prob- meet the ‘wicked’ and route to choose about which airline How does the decision 1.5 new garden is an example of design. Think about the abstractions that might arise Planning a 1.4 we are designing for a sequence of Designing software is made more complex because 1.3 Sketch out a design for one or more of the following: 1.2 the time of day in which the only available means for telling Imagine that you live in a world SDC01 9/18/07 10:34 AM Page 23 AM Page 10:34 9/18/07 SDC01 SDC01 9/18/07 10:34 AM Page 24 SDC02 9/18/07 10:36 AM Page 25

chapter 2 25 The Software Design Process

2.1 What is software? 2.4 Constraints upon the design 2.2 Building models process and product 2.3 Transferring design knowledge 2.5 Recording design decisions 2.6 Designing with others

This chapter begins by reviewing some ideas about what might constitute ‘software’ and then takes the ideas about design that were introduced in Chapter 1 and considers how they can be interpreted for the problem of designing software. It examines some of the conclusions that have been drawn from observation of software designers at work, and uses these to identify the forms of support that are required to help with transferring design experience and knowledge. Some of the other factors influencing software design are surveyed, and their influence upon the evolution of software design practices is considered. software have helped with classifying architectural style The one factor that these developments have particularly highlighted, and the one The one factor that these developments have particularly highlighted, and In some ways, the effect of these developments upon design thinking has probably In some ways, the effect of these developments This process of variation in the forms of implementation has continued apace, This process of variation in the forms By the 1970s the idea that computing tasks could be distributed across multiple By the 1970s the idea that computing When people first began to develop computer-based applications that were recog- began to develop computer-based applications When people first that existing design practices (including many described in this book) have been least that existing design practices (including many described in this book) have While successful in addressing, is the continuing demand for faster delivery of systems. been less than might be expected (and arguably, somewhat less than might be desir- been less than might be expected (and arguably, somewhat less than might able). At one level, such concepts as a matter of the wealth of implementation forms. However, in some ways this is more process having the question of implementation form considered earlier in the design rather than being a radical change in the nature of the design process itself. parameters. Ideas about distribution have further extended the potential for employ- parameters. Ideas about distribution final structure of a system, as well as extending ing run-time binding to determine the as ‘client–server’ are now widespread, if not par- ideas about distribution (terms such time, the addition of ‘scripting’ forms to static ticularly well-defined). At the same and XML has further extended our ideas about description notations such as HTML the forms that ‘software’ might take. one, the designers now had to incorporate additional factors into their decision- one, the designers now had to incorporate data were to be partitioned or shared between making, such as how functionality and mechanisms to employ, and the likely perform- machines, the form of communication ance effects of these choices. of the Internet has added many new and in the 1990s in particular, the development resulting binary code, the close link between these generally rendered the distinction resulting binary code, the close link unimportant. further possibility of changing the links between computers had been added, with the could largely be considered to be a variation these at run-time. While this development of course influence the thinking of the designers in the details of implementation, it did system was to be implemented as a distributed of such systems. Where the eventual table binary code’ that was intended for execution on a single machine. Indeed, this that was intended for execution on table binary code’ about software design. The implicit in all early thinking assumption was effectively was compiled (which can be was largely fixed when the code structure of such systems of the designer(s) were directed binding’) and so the ideas described as ‘compile-time code. Indeed, while the term a single monolithic unit of binary towards producing times to describe both ‘source code’ and the ‘software’ might be used at different begun the previous chapter by asking the question ‘what is design?’, it is appropriate chapter by asking the question ‘what begun the previous is software?’. by considering the question ‘what to begin this chapter this question was one that enough to merit an explicit design phase, nized as being large at least, software was been asked by anyone. Until the mid-1970s was unlikely to have with generating ‘execu- all of the forms that were concerned considered to encompass 2.1software? is What and process of design of the general the characteristics chapter we examined In the first this a creative task. In it as being design that characterize those features of identified the design of the ways in which with examining will be concerned chapter we the task of designing any ways in which and identifying general pattern, fits into this of artifact. So having any other forms that of designing might differ from software

26 The software design process SDC02 9/18/07 10:36 AM Page 26 AM Page 10:36 9/18/07 SDC02 27 Building models , et al. they are to do they are how do, than develop solutions that describe develop solutions do, than . This is seen as being an essential property of software, in which no . Software, being ‘pliable’, is expected to conform to the standards should However, since the main theme of this book is one of ‘software design’, for much However, since the main theme of this One way of achieving faster delivery of systems to their users is to employ a higher faster delivery of systems to their One way of achieving imposed by other components, such as hardware, or by external bodies, or by exist- imposed by other components, such as hardware, or by external bodies, or ing software. Complexity execution. two parts are alike and a system may possess very many states during than This complexity is also arbitrary, being dependent upon the designer rather the problem. Conformity n n and size, software development techniques seem to have inched along in a series of rel- and size, software development techniques are cited for this, and in his widely acclaimed atively small steps. Various reasons accidents of software engineering’, Fred Brooks paper ‘No silver bullet: Essence and causes of this relatively slow progress (Brooks, has pointed out some of the principal following properties of software as major factors 1987). In particular, Brooks cites the affecting its development. 2.2 models Building systems have long been recognized. The difficulties involved in creating software-based such as hardware design and production has While apparently-related technology in performance, and similarly reducing price raced along gaining orders of magnitude of the time we take a very general and abstract view of what might constitute ‘soft- of the time we take a very general and to the effects of choosing specific forms of imple- ware’, although we do pay attention affect design decisions. Indeed, our thesis here mentation where this may significantly argued that whatever the form(s) of software that is one of unification, in that it can be design should still reflect a set of consistent con- are used to implement a system, its cepts and principles. to writing them in ‘high-order languages’. This freed them from dependence on one ‘high-order languages’. This freed to writing them in faster production of code. An type of computer and also enabled particular make and design stage is to place greater the potential for a similar step at the approach offering rather than designing existing ‘objects’ and ‘components’ emphasis on manipulating chapters. be discussing these ideas in our later new ones. We will is unlikely to be achieved without expenditure of considerable effort. Whether this will without expenditure of considerable is unlikely to be achieved open question (Brereton many ‘web-based’ systems is an prove achievable for 1998). In the 1970s such a step in terms of what we think of as ‘software’. level of abstraction assembler code from writing programs using machine-specific was achieved by moving this has always been a problem, the concept of ‘internet time’ is one which probably which is one time’ of ‘internet the concept problem, been a always this has To a considerable process. design a reflective need for with the strongly most conflicts our ideas about adapt and extend can much more quickly arises because we extent this what systems a its structure, due care to preserve design is that, given of good it. One characteristic as characteristics harming such other modified without be extended and system can that is one However, this characteristic and consistency. time, dependability response SDC02 9/18/07 10:36 AM Page 27 AM Page 10:36 9/18/07 SDC02 . In later chapters we will scale link that can provide an easily link that of a system within a given context or of the designer’s intentions. Models of of the designer’s intentions. Models visual behaviour (reduced to only the properties of direct interest), (reduced to only the properties of direct representation abstract . Software suffers constant need for change, partly because of the because partly for change, need constant suffers . Software . Because software is ‘invisible’, any forms of representation that are of representation any forms software is ‘invisible’, . Because (Larousse) Constructing a model for a proposed solution allows the designer to explore the Constructing a model for a proposed solution allows the designer to explore In developing software, we need models that are often less precise than the math- In developing software, we need models The idea of using some form of ‘model’ to help with exploring design ideas is some form of ‘model’ to help with The idea of using This not only constrains our ability to conceptualize the characteristics of software, our ability to conceptualize the This not only constrains its development. among those involved with it also hinders communication Changeability costing them). for techniques poor (and relatively changes of making ease apparent Invisibility any form of it will lack used to describe for example, and the system – unlike, the representation between grasped relationship of the building. the visible features be easily linked to plan which can a building ‘A three-dimensional representation, usually in miniature, of a thing to be con- ‘A three-dimensional representation, structed.’ the process of software design. In this section we will try to identify some of the main the process of software design. In this section we will try to identify some features and characteristics of the models that are used in software design. be examining some of the forms that such a model can take. structure. potential limitations of the solution as well as to assess its behaviour and required the However, the examples used in the first two case studies (Chapter 1) the ‘solution designer to construct only relatively simple models in order to explore assist with space’. Simple, that is, as compared with the models that are needed to designer. more abstract than those used by the ship-builder, ematician’s models, while also being in the physical sense! However, their role and that are certainly not three-dimensional is still to provide some form of software will usually be of how we handle which also helps to address the issues may be concerned with more than just construction. An example of such an abstract may be concerned with more than just which may be employed for such tasks as pre- form is that of the mathematical model, of a metal bridge; describing the life expectancies dicting the stress in the components traffic flow at road junctions. Models of this of insurance policyholders; and describing type can also be used to predict the much more closely to the needs of the software scenario, a role which corresponds reads something like the following: and models may well be more abstract and However, this is a rather physical view, ter by considering the key design factor of model-building, used by a designer to posit the key design factor of model-building, ter by considering a solution. magnificent scale models shipbuilders constructed hardly new. The seventeenth-century also (equally important) as a as an aid to their own planning and of sailing ships, both shipyard workers who were to be tasked with means of conveying those plans to the is a model? A typical dictionary definition constructing the vessel. So what exactly For these reasons (and especially the last one), while the act of designing software (and especially the last one), while For these reasons design activity in Chapter 1, it general characteristics identified for usually shares the We therefore begin this chap- additional problems for the designer. incorporates many n n

28 The software design process SDC02 9/18/07 10:36 AM Page 28 AM Page 10:36 9/18/07 SDC02 29 Building models A general model of the software design process. A general model of the In practice, and especially when developing larger systems, the process of design is In practice, and especially when developing Figure 2.1 shows a (very general) ‘model’ of the software design process itself. The Figure 2.1 shows a (very general) ‘model’ strongly influenced by the eventual form that will be adopted for its solution. strongly influenced by the eventual form units (the ‘detailed’ or ‘phys- first phase are mapped on to technologically-based box into a white box. Where design and ical’ design), hence turning the black it is the output from this phase that implementation are separate responsibilities, provides the specifications for the programmers. ‘architectural’ or ‘logical’ design) in which only the external properties of the ‘architectural’ or ‘logical’ design) in black-box partitioning of the problem is model elements are included. This initial nature and form of the problem itself, and less therefore largely concerned with the Figure 2.1 design, rather than upon the exact forms that the models and transformations will take design, rather than upon the exact forms that the models and transformations for specific design strategies. Again, this is a rather idealistic description, but conceptually useful, even where it is Again, this is a rather idealistic description, but conceptually useful, even when not practical to keep the activities of the two phases separate (as, for example, we come to seeking to reuse existing components). So it is one that we will use when for the review different approaches to software design in the later chapters. However, during moment we will concentrate chiefly upon the general role of model-building 2. that were identified in the In the second phase, the abstract ‘chunks’ of the problem apt to be divided into two distinct phases, as illustrated in Figure 2.2. apt to be divided into two distinct phases, 1. model of a solution (the In the first phase, the designer develops a highly abstract input to this process is provided by the Requirements Specification documents, while input to this process is provided by consist of a set of detailed specifications that the outputs produced from it should components. (Of course, we know from our describe the form of the eventual program wicked problems that this is a highly idealized discussion of the characteristics of account!) SDC02 9/18/07 10:36 AM Page 29 AM Page 10:36 9/18/07 SDC02 The major phases of the software design process. The major phases of the software design The initial ‘architectural model’ that is used to describe the intended form that a The initial ‘architectural model’ that The use of abstract ‘mental models’ by the designer to simulate the dynamic The use of abstract ‘mental models’ by the designer to simulate the behaviour of the eventual system that will be derived from the design. a familiar problem; but taken from a familiar domain; and a problem that was unfamiliar in detail, senses. a problem that was unfamiliar in all n The study was limited in scope, in that they looked at only a small number of subjects, The study was limited in scope, in that they looked at only a small number for prac- and concentrated their study to a single specialized problem domain. Also, their tical reasons, the problems themselves were relatively small in scale. However, process. findings do seem to reflect more general experience with the software design Some key observations that were produced from this research included: posed: n n n system will take is generally highly abstract in its nature. The way that this is devel- system will take is generally highly was examined in an interesting study of the ways oped during the process of designing by Adelson and Soloway (1985). In their experi- that software designers work, made both experienced and inexperienced designers ments, they studied the ways in which models when they were faced with a range of set about the task of forming their were based upon situations where a designer was different problems. The experiments Figure 2.2

30 The software design process SDC02 9/18/07 10:36 AM Page 30 AM Page 10:36 9/18/07 SDC02 31 Building models , programming , rather than on design , 1988; Visser and Hoc, 1990). While this work con- , 1988; Visser and Hoc, 1990). While et al. The models formed during the early stages of design are mainly concerned with The models formed during the early stages of design are mainly concerned Returning to the large-scale issues of design (such as arise for the type of problem Returning to the large-scale issues of There have been relatively few empirical studies of software designers conducted There have been relatively few empirical by using a previously developed design object or structure. Where this occurs, developed design object or structure. by using a previously describing it in detail at a ‘label’ to identify the plan, rather than designers may use that point. aid to systematic expansion future (detailed) intentions, as an Making notes about of a design. Expanding the detail of a model in a systematic manner by keeping all elements of all elements keeping by manner in a systematic a model detail of the Expanding task aids the This then are developed. as they level of detail same at the the design of simulation. as possible when design as explicit affecting the to make any constraints The need an unfamiliar problem. handling can be solved part of a problem This arises when previous design plans. Reuse of that was given on page 5, based upon the quotation from the work of J. Christopher that was given on page 5, based upon the quotation from the work of J. with the idea Jones, we can see that this use of an initial abstract model corresponds system for different scenarios. In addition, the models can be used to aid a systematic system for different scenarios. In addition, the models can be used to aid of a detailed expansion of the initial ideas of the designer towards the production design description. since they assisting either the analysis or the specification of the problem (or with both, process are often entwined). If we return briefly to the more general view of the design that we term ‘programming in the large’), we will see when we come to examine dif- that we term ‘programming in the large’), many of these provide quite extensive forms of ferent software design methods that abstract models in order to explore ideas. The support for a designer in building initial as in the case of ‘systematic’ methods, or forms used for the models may be graphical, the more ‘formal’ methods. In each case, the use mathematically-based, in the case of the designer to predict the likely behaviour of a of an abstract model generally allows small’. For instance, many programmers probably perform simulations by executing small’. For instance, many programmers when coding conditional loop structures: mental models for sections of their programs that occur when the loop is first executed, and modelling the entry/exit conditions terminate in the intended manner. In that sense, checking to ensure that the loop will one, and it is clearly rather important at all the idea of simulation is a fairly familiar levels of abstraction. within a controlled experimental environment that have examined the activities within a controlled experimental viewpoint of the actions of the designer. How- involved in software design from the studies of design activity in more ‘normal’ ever, others have conducted some similar working situations (Curtis software centrated on studying the process of some of the observed techniques are also used many programmers will recognize that that they undertake when ‘programming in the for the more detailed design tasks The last point is less directly concerned with the manner in which a model is developed directly concerned with the manner The last point is less designer avoids the pitfall of the way in which an experienced and used, but it reflects the details of one aspect of a design in too much detail. (Fixing following one thread later constrain the early a stage may severely, and inappropriately, of a design at too for the other aspects.) designer’s choices n n n n SDC02 9/18/07 10:36 AM Page 31 AM Page 10:36 9/18/07 SDC02 , 1988). et al. , enabling them to map between problem design knowledge design , (1988), the exceptional designers were observed to possess three , (1988), the exceptional designers were et al. The characteristics of an exceptional designer. In Curtis Experimental study of software designers and their practices suggests that, as Experimental study of software designers So in many ways, the various approaches to supporting and structuring the soft- supporting and structuring approaches to ways, the various So in many Familiarity with the application domain ease. (A domain in this sense may be one structures and solution structures with systems, and so on.) such as data processing, real-time, telecommunication 1. might be expected, some people are better designers than others (Curtis might be expected, some people are great designers is very small, we need to seek However, since the number of truly skills to a wider group in as effective a manner ways of providing appropriate design as possible. in Figure 2.3, these are: significant characteristics. As illustrated Chapter 1 examined the nature of the general design process and showed that it is quite the nature of the general design process Chapter 1 examined act of designing is not based approach to problem-solving. The unlike the ‘scientific’ true solution to a problem, as aimed at identifying the one upon an analytic strategy, process, and certainly very laws. Instead, it is a highly creative determined by physical to any given problem. the identification of a single solution unlikely to lead to examine this issue of knowledge transfer more fully and identify some of the other of knowledge transfer more fully examine this issue involved in it. factors that may be 2.3 Transferring that a designer needs to ‘predict a future state’ and so needs to assume the outcome of the outcome to assume so needs state’ and a future ‘predict needs to a designer that process. that to begin in order process the design the concerned with this book are largely will examine in process that we ware design models. Indeed, and elaborating describing, constructing practices used for different as can be considered assess such models to develop and that is needed the knowledge we section, therefore, In the next designer’s portfolio. element in the an important Figure 2.3

32 The software design process SDC02 9/18/07 10:36 AM Page 32 AM Page 10:36 9/18/07 SDC02 33 Transferring design knowledge . This was . This is one that has offered a design pattern , to the extent that they could be found that they could , to the extent experienced, and have extensive domain know- experienced, and have extensive domain are of further developments in the design. . The idea of design methods emerged in the 1970s in order to a decision, if the information required is not yet available at this design a decision, if the information required anticipation design methods postpone Design methods are not the only means of formalizing the transfer of domain Design methods are not the only means of formalizing the transfer of Domain knowledge can be acquired partly through experience, and also, to some Domain knowledge can be acquired Even if rigorous procedures for performing the transformations between the stages Even if rigorous procedures for performing When we look at how successful designers work, there are other factors to con- how successful designers work, there When we look at Others too have identified the importance of the domain knowledge of the identified the importance of the domain Others too have Skill in communicating technical vision to other project members project to other vision technical in communicating Skill often was work of the design much factor that a so significant to be observed with others. while interacting accomplished performance with project Identification progress. for ensuring technical responsibilities significant management taking on to level; or to hand, and which can be used for defining to process information that is readily modules in knowledge, and more recently the idea of the key characteristics of the domain. One way of learning such practices is through the key characteristics of the domain. One way of learning such practices is use of use do seem meet this need for knowledge transfer, and in some ways their forms and regard to be something that is peculiar to software development. We can, therefore, that will the purpose of a software design method as being to provide the framework enable a designer to develop and elaborate a design in a systematic manner. design strategies in some way. Experienced designers can make use of opportunistic design strategies in some way. Experienced techniques precisely because they such techniques are clearly inadequate where ledge to guide their actions. However, the question of how are they to be acquired? these characteristics are lacking, leaving practices that may be related to a particular degree, through learning a set of design upon making decisions that are based upon the domain. Such practices place emphasis Such opportunistic design activity is not unstructured; instead, it is more likely to Such opportunistic design activity is domain knowledge. One important consequence reflect the designer’s experience and support tools should not give them an inter- is that the developers of software design on the part of the designer. face form that impedes this behaviour there may still be benefits in seeking to codify of a designer’s model cannot be devised, n n accelerated and improved. section. Visser and Hoc those that were outlined in the previous sider, apart from of software design term ‘opportunistic’ to describe observations (1990) have used the such as ‘top-down’ (systematic- designers aim to follow a strategy activity. Even where into ever smaller actions), they may deviate ally refining the description of the solution from this plan, either: Interestingly, though, the exceptional designers studied often did not possess particu- the exceptional designers studied Interestingly, though, skills. larly good programming Soloway, 1985), and clearly successful designs (Adelson and designer for producing in a particular problem come from the accumulation of experience this aspect can only such knowledge can be be, though, that the process of acquiring domain. It may well 2. 3. SDC02 9/18/07 10:36 AM Page 33 AM Page 10:36 9/18/07 SDC02 , 1995). However, since the use of , 1995). However, et al. provides a set of descriptive forms that the designer can provides a set of descriptive forms that that can be used to provide guidelines on the ways in which the that can be used to provide guidelines is concerned with describing how the necessary transformations is concerned with describing how the heuristics The two major components of a software design method. The two major components representation part process part So representation forms generally reflect the properties of the objects in the design. So representation forms generally reflect the properties of the objects in the The representation part of a design method will usually include forms that can be The representation part of a design method For our purposes, a software design method can be considered as providing a a software design method can be For our purposes, ideas for its solution, and for describing the structural features of the solution to ideas for its solution, and for describing the eventual implementors. to be organized, as well as with any elabor- between the representation forms are ation of their detail that might be required. use for building both black box and white box models of the problem and their use for building both black box and A set of can be organized for specific classes of prob- activities defined in the process part experience of past use of the method within a lem. These are generally based upon form of structure. particular domain or for a particular properties such as the calling hierarchy, complex data structures, number of parameters properties such as the calling hierarchy, complex data structures, number will be and so on. On the other hand, the forms that are used for problem modelling which showed how key joints were to be assembled. In describing software, one will which showed how key joints were to be assembled. In describing software, sub- typically use detailed design forms that describe the structures of the program that units, the relationships that these have with one another, and the relationships they have with the other entities in the system. concrete Those forms that describe the detailed design may be concerned with fairly While these do not necessarily provide the domain knowledge that a designer needs, While these do not necessarily provide knowledge. they may well aid in developing this as forms that reflect the significant structures used for modelling the problem, as well example of the latter form: in describing a garden of the implementation media. As an described its plan, elevation and end view, and shed, one would use drawings that A further component is provided in most design methods: A further component is provided in n 2. The returning to the concept of the pattern at a later point. returning to the concept (shown schematically in that consists of two major components supportive framework Figure 2.4). 1. The less ‘procedural’ mechanism for this (Gamma less ‘procedural’ mechanism domain and hence in thinking deeply engrained in the software design methods is role in knowledge transfer, we will focus here upon their about software design, Figure 2.4

34 The software design process SDC02 9/18/07 10:36 AM Page 34 AM Page 10:36 9/18/07 SDC02 35 Transferring design knowledge , we will design pattern about how such problems are best step, in which a change of viewpoint that is used to step, in which a change of viewpoint , sometimes termed the ‘Aha!’ response. This is a skill in which , sometimes termed the ‘Aha!’ response. development of procedural knowledge problem restructuring recognition step Akin (1990) has suggested that there are three ‘classic’ conditions that are Akin (1990) has suggested that there The process part of design is rather more difficult to quantify and classify. Its to quantify is rather more difficult part of design The process (Again, Akin notes that there are many fields of human endeavour where this can (Again, Akin notes that there are many fields of human endeavour where be seen to apply.) example, in solving a given problem, the designer may decide to store the data in example, in solving a given problem, the designer may decide to store the an array. This choice may subsequently require a highly complex set of algorithms, array will and the designer may later realize that using a linked list in place of the result in much simpler algorithms. domain. solved, allowing the designer to perform many creative acts within a the designer recognizes a solution that has been there all along. (This form of cre- the designer recognizes a solution that scientific progress than of design progress ative act is perhaps more typical of the concept of the although when we later come to study depend upon a form of recognition step.) see that effective use of patterns does to a major breakthrough in solving it. As an describe or model a problem leads identification of particular constraints to be considered; identification of particular constraints verification/validation operations. identification of the design actions to be performed; identification of the forms; use of the representation transformations between representations; procedures for making quality measures to aid in making choices; 3. The 2. The designer to identify the choices available, and to evaluate these in terms of their likely designer to identify the choices available, consequences. These are: observed in creative acts such as design. 1. The n n guidance for the designer, rather than detailed Most design methods provide strategic this is driven by the problem-oriented nature of solutions to issues. To a large extent has to make: the role of the method is to help the many of the choices that a designer n n n n heuristics (‘it worked well when we did it this way before’). Most likely, it will reflect well when we did it this way before’). heuristics (‘it worked theoretical underpinnings these. In general there is a lack of strong a mix of all three of principles may themselves be methods, and even the underlying for existing design some of the expectations in nature. However, we can still identify relatively empirical which will include providing the process part of a design method, that we have from for the following tasks: some degree of guidance concerned with more abstract properties of the problem objects and any relationships and objects of the problem properties more abstract with concerned abstract relatively upon be based will usually model these. This between may exist that pro- comes closest to flow, and as such, and information such as operations concepts by placing emphasis by a designer element needed ‘domain knowledge’ viding the significance. to be of the greatest are considered domain features that upon the ‘principles’, or from from specific fairly general theory, may be derived from structure SDC02 9/18/07 10:36 AM Page 35 AM Page 10:36 9/18/07 SDC02 , 1984; Friel and Budgen, 1997). et al. , which may involve a change of representation ) of structures, in which the input and output forms ) of structures, in which the input and elaboration that, again, can have any of these forms; that may be described by using a suitable ‘representation’ (which that may be described by using a suitable (or through which the designer adds information to the model. through which the designer adds information Transformation model of design activity. Transformation model transformation of viewpoint refinement input model output model The view of design as being a series of transformations is one that has been The view of design as being a series of transformations is one that If we explore further the transformation steps themselves, we find that for each If we explore further the transformation of the model are the same, but extra detail is added; of the model are the same, but extra the of the representation form. form or introduce a different interpretation design inputs the an may be graphical, textual or mathematical); an As a general model it provides a useful summary of design method structuring, and it As a general model it provides a useful summary of design method structuring, methods. will be used for this purpose in the chapters that describe specific design add both decisions and a change of the structure of the design model. In the former add both decisions and a change of the structure of the design model. space’ by case, the designer is chiefly concerned with reducing the eventual ‘solution be adding making additional choices and decisions; whereas in the latter he or she may information about new relationships between design objects. explored and used in a number of ways (Lehman n involve refinement are apt to preserve the repres- In general, the transformations that while those that involve a change of viewpoint entation form while adding more detail; n forms of design transformation, which In addition, we can identify two principal respectively involve: n step we can identify a general structure of the form shown in Figure 2.5. Each trans- step we can identify a general structure formation involves: n n A major component of the process part of a design method is the structuring of the of the process part of a design method A major component in the ‘process diagram’ used The sequence that is expressed design transformations. omits any detail about the iter- course, still a fairly abstract one, and in Figure 2.2 is, of evaluates the design options. occur as a designer explores and ations that will normally since the nature of these is too of the heuristics is also omitted, Any ‘formal’ inclusion strongly method-specific. Figure 2.5

36 The software design process SDC02 9/18/07 10:36 AM Page 36 AM Page 10:36 9/18/07 SDC02 37 Constraints upon the design process and product that particle-wave design pattern (Shaw and Garlan, 1996) (Shaw and Garlan, software architecture , 1995) has focused upon categorizing solution , 1995) has focused et al. exhibited by light, in which it can have the characteristics of one form or the other in any given situation, Similarly, for the case of software design, we can readily identify many of the con- Similarly, for the case of software design, We will return to look at both of these approaches in later chapters. In many We will return to look at both of Of course, as always occurs when considering design issues, there are trade-offs occurs when considering design Of course, as always As indicated earlier, design methods have formed part of the software designer’s software part of the formed have methods design earlier, As indicated reasons, two as well as for other this problem, the need to address Partly through duality but not both. senses, their key contribution to the task of transferring design and domain knowledge senses, their key contribution to the task are complementary to those employed in design is through providing strategies that so often occurs in software development, finding methods. Unfortunately though, as approaches is apt to prove elusive.* ways to combine the strengths of different involved in their application. While both of these approaches offer much better scope While both of these approaches involved in their application. design methods do, the lack of ideas than ‘traditional’ software for reusing successful to the novice and, in the can make them less readily accessible a procedural element well the concept will scale up there are questions about how case of design patterns, in a given context?). are likely to be both useful and accessible (how many patterns was mentioned earlier (Gamma was mentioned earlier be reused for different problems. structures that can straints imposed upon the form of the product. Some may be determined by the even- straints imposed upon the form of the product. Some may be determined of the user tual run-time environment (organization of file structures; the ‘look and feel’ required interface), while others may relate to the need to conform to the conventions between by a chosen architectural style (JavaBeans; forms of remote access; choice * that resemble the physicists’ dilemma with the Software often seems to possess characteristics were concerned both with functional issues (blocking power outlets or windows) and were concerned both with functional colour, or putting a bed in the dining room etc.). with aesthetic ones (clashes of style or the form of the solution (or product in These considerations largely act to constrain garden sheds, the main constraints were again this case). For the example of designing driven by the need to provide a way of con- on the form of the product, and were units. structing sheds from easily prefabricated In practice, there are very few opportunities to design a system with a totally free hand, In practice, there are very few opportunities a particular context, and this will provide since each design task takes place within of the design itself and possibly on the way that particular constraints upon the form this in the case studies of developing designs for it is produced. We have already seen In the example of moving house, the constraints moving house and for a garden shed. 2.4 and product process upon the design Constraints developed in the 1990s. The concept of developed in the 1990s. procedural approach to think- as taking a more structural and less can be considered idea of the can be developed. Similarly, the ing about how a design support base since the 1970s. However, in providing this support, their form and their form support, this in providing However, 1970s. since the base support 1999) and there creativity (Budgen, influence upon also be a constraining nature can to support, that they are ill-equipped design behaviour of ‘conventional’ are aspects used successfully. have previously been that the reuse of part-solutions most notably knowledge were of design and domain with the transfer to assisting other approaches SDC02 9/18/07 10:36 AM Page 37 AM Page 10:36 9/18/07 SDC02 , which can design reviews appear here), although this will not necessarily be true for those that appear here), although this will not necessarily , Modula-2, Java and scripting languages such as Javascript etc.) have and scripting languages such as Javascript , Modula-2, Java should ++ , 1995) as well as upon the task of allocating functionality between components. functionality between task of allocating well as upon the , 1995) as Many constraints will be identified in the initial specification documents (or at Many constraints will be identified Constraints on the process of design are more difficult to identify. They may be Constraints on the process of design can be considered as forming a set of bounds Whatever form they take, constraints The imperative forms of programming language (COBOL, ALGOL, FORTRAN, of programming language (COBOL, The imperative forms Perhaps one of the most important constraints on the design task and the form task and the form on the design constraints of the most important Perhaps one The need to record the decisions of the designer (or, for larger projects, of the design The need to record the decisions of the designer (or, for larger projects, more so from team) is important, from the viewpoint of the design task itself, and even identify and track constraints is through the use of regular be given the role of ensuring that an audit trail is maintained. 2.5 decisions design Recording limit the overall solution space by limiting the range of choices available to the limit the overall solution space by course, that inconsistencies in specification may designer. (There is also the risk, of solution!) Some constraints are problem-specific actually make it impossible to find a should be assumed for a new application), while (such as the level of user skills that as architectural style). While problem-specific others are more solution-specific (such into any formal design process (such as a constraints cannot readily be incorporated need to be considered at every step. One way to design method), their influence does upon the ‘solution space’. Even if the process of design will not necessarily converge upon the ‘solution space’. Even if the the effects of the constraints may be to limit upon one solution for a given problem, will be acceptable in particular circumstances. the amount of possible divergence that least, they Whatever their source, constraints effectively are related to any expectations of reuse. concerned with designer skills and knowledge (experience with a particular method), concerned with designer skills and knowledge ‘architectural style’ of design, in order to aid or with a need to conform to a particular constraint upon the product leads to a constraint future maintenance. In some cases, a form needs to be consistent with that gener- upon the process – where, say, the output strategy. ally produced from a particular design Ada, C, C the use of imperative lan- tool in software production. Indeed, remained the dominant currently available, and so implicit in almost all design methods guage constructs is use of imperative forms is not this book. However, the will be assumed throughout studied here are certainly process, and the principles of design essential to the design alone. not restricted to the imperative paradigm hardware and select the major software facilities (operating system, programming the major software facilities (operating hardware and select While enlightenment may be beginning on the design task itself. language) before even language is still more likely to the choice of the programming (very slowly) dawning, skills and knowledge than by external factors such as programmer be determined by problem itself. the features of the processes or objects; etc.). Where it is also intended that the eventual system will be con- will system that the eventual intended it is also Where etc.). or objects; processes constraints lead to further this may components, software existing by reusing structed may possess (Garlan the components styles that ‘acceptable’ architectural upon the et al. For many years of implementation. of the eventual form itself is that of the design the been to purchase projects has software development used by most the approach

38 The software design process SDC02 9/18/07 10:36 AM Page 38 AM Page 10:36 9/18/07 SDC02 39 Recording design decisions . Such an audit may . Such an design audit , 1987). Possessing some record of , 1987). Possessing et al. The principal benefits of such an approach are that new members of a design team The principal benefits of such an approach are that new members of a design An important issue in terms of recording decisions about a design has been raised An important issue in terms of recording The way in which design decisions are recorded is obviously somewhat dependent The way in which design decisions are So a major motivation for recording the reasoning behind any design decisions is one So a major motivation for recording the methods generally provide good forms of Unfortunately, while software design There is an even stronger need on the part of the system maintenance task (which need on the part of the system There is an even stronger Beginning with the original task of design, the recording of rationale is likely to be recording of rationale task of design, the with the original Beginning the eventual task of maintaining the system will also be made easier. Parnas and the eventual task of maintaining the system will also be made easier. proof, the Clements observe that even for a scientific document such as a mathematical documentation should be written as though the ‘ideal’ design process was the one that documentation should be written as though the ‘ideal’ design process was process (as was followed. Indeed, they argue that since design will never be a rational documen- we have been observing throughout this and the preceding chapter), any tation produced will always need to ‘fake’ this appearance of rationality. and also that should be able to absorb knowledge about the project much more easily, modelling this process of design deliberation – the ‘Potts and Bruns model’ (Potts and modelling this process of design deliberation been demonstrated for the JSD method. As yet, Bruns, 1988; Lee, 1991) – and it has support that can be used for this task. though, there is little or no general tool have observed that, even if the design process by Parnas and Clements (1986). They not a rational one, the documentation that is actually used to produce a design is appear as though it were. In other words, the finally produced should still make it other notation, they are generally weaker on process matters, such as recording the other notation, they are generally weaker of decisions and their reasons can fairly reasons for the decision. While the recording it is relatively hard to enforce it unless there is easily be made a part of design practice, a strong quality control system in operation. work has been performed to look at ways of upon the design process adopted. Some complete history of the system design. stage and also much later, during maintenance. of quality control, both at the design we hope to fully understand a design, and this Only if we have a complete picture can good, reliable design. is an essential factor in producing a product issues, usually through diagrams or support for recording decisions about the reasons for the existing structure can help both with recreating this model and with existing structure can help both with the reasons for the for the change need to be of any changes. In turn, the reasons evaluating the effects in order to maintain a consistent and added to the records kept by the maintainers, ture the original models that were used by the designers of a system. Only when they that were used by the designers ture the original models decide how to implement their complete model can they reliably have a reasonably effective manner (Littman changes in the most consist of peer review of the designer’s ideas, or may be something more formal that is of the designer’s ideas, or may be consist of peer review if audits are held, they will be manager. Whatever the form, conducted by the project for decisions are recorded. and usefully performed if the reasons more systematically and designer effort). In around 50–80 per cent of programmer is thought to involve need to be able to recap- extend a design, the maintenance designers order to modify or the viewpoint of the maintenance team who may later need to extend and modify the and modify to extend later need may team who of the maintenance the viewpoint it is decisions, the actual record diligently may while designers Unfortunately, design. choice. (Experience the basis for the final that forms to record the rationale much rarer it engineering alone: to software that is confined this is not a problem suggests that practice too.) branches of engineering occur in many other seems to form of includes any if the design process encouraged SDC02 9/18/07 10:36 AM Page 39 AM Page 10:36 9/18/07 SDC02 operating system is prob- operating system is Linux . Such software is made freely available and is usu- . Such software is open source software Many of the very successful and ‘exciting’ software systems have been the work Many of the very successful and ‘exciting’ designing a system through the use of a team In the absence of any great designers, We will return to the issue of design documentation in later chapters. It is certainly We will return to the issue of design documentation Before concluding this section, we should also briefly refer to one of the more briefly refer to we should also this section, Before concluding how to integrate the individual contributions to the design, which may well involve how to integrate the individual contributions to the design, which may well a process of negotiation between the members of the team. how to split the design task among the team, and to determine the interfaces how to split the design task among the team, and to determine the between the parts; n brings two major additional issues that need to be handled within the chosen design brings two major additional issues that need to be handled within the chosen strategy. These are: n modules should be equal to the number of members of the design team!) modules should be equal to the number (1987) contrasts the ‘excitement’ of Unix, of one or a few ‘great designers’. Brooks systems with the ‘blandness’ of COBOL, PL/1, Pascal, Modula, SmallTalk and similar that support this point. (A more recent contrast MVS/370 and MS-DOS as examples might be Linux versus Windows XX!) of any scale, it is essential for any form of programming in the large, where a project of any scale, it is essential for any form than a single designer. Given the nature of the is likely to involve a design team rather that designing as a team adds further compli- design process, it is hardly surprising added constraints upon the process, and hence cations, many of them in the form of medium-sized systems it sometimes appears as upon the form of the product. (For of design that specified that the number of design though there were an invariant ‘law’ one where software’s characteristic of ‘invisibility’, and the complexity of its nature, one where software’s characteristic are made very evident! 2.6 others with Designing is important for software development tasks While the development of a sound design both version control and documentation are essential elements in managing the efforts and documentation are essential elements both version control at time of writing, there (Wu and Lin, 2001). Curiously though, of so many volunteers that are involved in developing study into how the processes has been little academic the more ‘traditional’ forms of differ from those employed in open source software in the preceding paragraphs. development described emergence of basis. While there are developers, contributed on a voluntary ally the work of many this type of software product, the many examples of for preparing this revised (and has been used as the platform ably the best known of such software is be returning to look at how the development edition). We will section we should note that chapter, but in the context of this organized in the next form published is rarely the form of the initial derivation, since, as understanding since, derivation, initial of the the form is rarely published form they proof, since simpler need the Readers be found. usually can simplifications grows, discovery. In the same the process of its the theorem, not in the truth of are interested member or the main- to the new team design that matters the structure of a way, it is developed. not the way it was tainer, and the 1990s, namely of the 1980s and developments social and technical interesting

40 The software design process SDC02 9/18/07 10:36 AM Page 40 AM Page 10:36 9/18/07 SDC02 41 Designing with others The Psychology ., 1988) et al ., 1988; Curtis and Walz, (Curtis et al (Weinberg, 1971). In this he observed the effects of differ- (Weinberg, 1971). Researchers have also sought to understand and model the psychological factors Researchers have also sought to understand In practice, few design teams seem to act along such lines, perhaps because there In practice, few design teams seem to The more hierarchical approach was at one time advocated by the exponents of approach was at one time advocated The more hierarchical Some of the original research studying how programming (and hence designing) is research studying how programming Some of the original Bringing the elements of a design together, along with the accompanying negoti- with the accompanying design together, along the elements of a Bringing the large impact that may be exerted by a small subset of the members of the team the large impact that may be exerted knowledge; who possess superior application domain within a company (and particularly the need the influence of organizational issues and the customer). to maintain a bridge between the developers the size of a team (there seem to be pointers that a size of 10–12the size of a team (there seem to be pointers members is prob- ably an upper limit for productive working); ‘Designers needed operational scenarios of system use to understand the appli- ‘Designers needed operational scenarios of system use to understand were too cation’s behaviour and its environment. Unfortunately, these scenarios generated seldom passed from the customer to the developer. Customers often them and many such scenarios in determining their requirements, but did not record abstracted them out of the requirements document.’ n n in that: This last point raises an important issue that influence team behaviour in designing (Curtis that influence team behaviour in designing references include: 1990). The factors discussed in these n support his or her activity. The parallel usually drawn has been with the surgical team support his or her activity. The parallel the very different purpose of the latter. Members – which rather begs the question of themselves, such as librarian, administrator or of the team might have specialized roles back-up who acts as the technical deputy to the documentation expert, and there is a chief programmer. on the very exacting central role it demands. are few great designers who can take of peers (in which different members of the group might take the lead for specific different members of the group might of peers (in which had a highly hierarchical form. tasks), to those that Set in the design context, school (Baker, 1972; Brooks, 1975). the ‘chief programmer’ in a highly centralized role, functions as a chief designer, acting the chief programmer performing functions that are solely intended to with the other members of the team ation may be right and necessary, it should not be allowed to reduce the integrity of and necessary, it should not be allowed ation may be right the overall design. classic book was described in Gerald Weinberg’s performed by teams of Computer Programming that worked as an ‘egoless’ set organization, ranging from groups ent forms of group The first of these problems is at least partly aided by the increasing trend towards towards trend increasing by the aided least partly is at problems first of these The it is the moment, For a later point. at be examined that will an issue designs, modular the of subdividing with the problem strategy does help to note that this sufficient ensure a fair balance is still necessary to team, although it among a design operations where appropriate. of effort, a process of negoti- issues. While and managerial again a mix of technical ations, is This point is an interesting one, for it is relevant not only to the use of design teams, This point is an interesting one, for it is relevant not only to the use of the full set but addresses a much wider organizational issue in itself. (Figure 2.6 shows SDC02 9/18/07 10:36 AM Page 41 AM Page 10:36 9/18/07 SDC02 , 1988.) We will return later to examine more recent , 1988.) We will return later to examine et al. ., (1988) ) Factors influencing the software design process. Factors influencing the et al For the present, however, the key issues of design team operation seem to lie more For the present, however, the key issues the need for domain knowledge on the part of the designer; the widening interpretation of what consists ‘software’; to con- the complexity of the model-building processes for software systems, with their need sider static forms as well as the dynamic behaviour of the eventual system; the influence of the invisible nature of software upon any attempts to describe it; ‘Programming in the large is, in part, a learning, negotiation, and communication ‘Programming in the large is, in part, process.’ Summary n n n n This chapter has enlarged upon the issues that were raised in Chapter 1 by considering how they This chapter has enlarged upon the issues design. Major points from this chapter are: apply to the particular domain of software (1990): has gone into technical research than into invest- Unfortunately, to date far more effort igating team and organizational factors. thinking about the roles of scenarios and ‘use cases’ in software development. thinking about the roles of scenarios in that of design technology. Certainly few, if in the domain of group psychology than methods offer any significant guidance on how any, of the more widely used design team as opposed to an individual, and it would they should be adapted for use by a avoid doing so. To quote from Curtis and Walz seem that they are probably correct to Figure 2.6 (After Curtis of factors identified in Curtis

42 The software design process SDC02 9/18/07 10:36 AM Page 42 AM Page 10:36 9/18/07 SDC02 43 Exercises IEEE . Springer Practitioner Series ISBN (11), 1268–87 31 , Software Design – Cognitive Aspects , 10–19 Comm. ACM (b) real-time process control for chemical plants (c) writing compilers for imperative programming languages. oped it, are you aware of any way in which you might have reused experience from previous oped it, are you aware of any way in which you might have reused experience from programs in deciding upon particular structures or algorithms? of domains. Consider what particular forms of experience might be useful in the domains (a) processing financial transactions how to go about recording the results of the design process, presenting an ideal view of the results of the design process, how to go about recording by ‘faking’ an ideal development process; design development and how this differs from indi- affect the operation of design teams, some of the factors that vidual design practices. how the observed practices of software designers relate to the model of the general design of the to the model relate designers of software practices observed how the design practices by use of opportunistic in particular, the was presented, and process that designers; the representation major components: and its three form of a design method, the general heuristics; part, and the part, the process 1-85233-253-0 systems. Computer Exercises Further reading 2.2of domain knowledge is clearly a feature that will take different forms in particular The reuse oriented view of software design issues. 2.1 written. Thinking about how you devel- Consider a recent item of software that you may have large projects. A particular feature is the consideration of the influence of various factors within large projects. A particular feature is the the organization. Détienne F. (2002). view of software design, reviewing both the- A very scholarly text which takes a psychological Useful reading for anyone wanting a more cognitively- oretical ideas and also empirical studies. by a number of emerging technologies. A good summary of the issues that make progress with by a number of emerging technologies. A software development so difficult. A field study of the software design process for large Curtis B., Krasner H. and Iscoe N. (1988). on data gathered by interviewing personnel from 17 This paper describes an analysis performed Brooks F.P. Jr (1987). No silver bullet: Essence and accidents of software engineering. No silver bullet: Essence and accidents Brooks F.P. Jr (1987). of experience gained by Professor Brooks, and com- This paper brings together the many years the development processes for software that are offered ments upon the prospects for improving n n n n SDC02 9/18/07 10:36 AM Page 43 AM Page 10:36 9/18/07 SDC02 Write down a list of the information about the development of a system that would be useful of a system about the development a list of the information Write down features. in order to add new a major revision of it had to undertake to you if you a collective exercise, a ‘design’ as that successfully produced of a committee last a member this possible. the factors that made and identify 2.3 of a system. structure the final merely details all, often available at if documentation, Design 2.4 you were Think back to when some circumstances. of design team in Committees are a form

44 The software design process SDC02 9/18/07 10:36 AM Page 44 AM Page 10:36 9/18/07 SDC02 SDC03 9/18/07 10:38 AM Page 45

chapter 3 45 Design in the Software Development Process

3.1 A context for design 3.4 Economic factors 3.2 Linear development processes 3.5 The longer term 3.3 Incremental development processes

The development of any large computer-based system (sometimes referred to as ‘programming in the large’) is one that involves many activities – of which software design is but one – even if a very central one. In this chapter we examine some of the ways in which systems are developed, and consider how the organization of the development process can influence the design task. We conclude by considering a longer-term view of systems and their evolution and maintenance, and consider what effect this might have upon design choices. creativity rather than to Open source software of all kinds is generally developed in this way, as are many websites. Typical domains Many ‘made to measure’ systems are developed in this way. This approach is one that has been used very widely and is still appropriate for systems that need to demonstrate any form of high integrity. Widely used for ‘shrink wrap’ software of all sorts, such as office packages, games, operating systems. Also, where there is a need to interact closely with the end-users during development. constrain , 1988). It is also important to recognize that one of the , 1988). It is also important to recognize which emerged as a description of how the necessary which emerged as a description of how et al. Where there may be a need to demonstrate feasibility of an idea; establish a market position rapidly; or explore whether a market might exist. Providing a rapid time to market is often an important factor for adopting such an approach. Where evolution of a system is largely in response to what the developers perceive as being needed. Reasons for adoption Where the needs are reasonably well determined and a ‘longer’ delivery time is acceptable. software life-cycle Some examples of software development processes Ideas about how the software development process might be best organized have Ideas about how the software development For many years, almost all systems were of course ‘made to measure’, and the con- all systems were of course ‘made For many years, almost There are many ways in which a ‘large software system’ can be developed to meet in which a ‘large software system’ There are many ways Reactive Linear (e.g. ‘waterfall’) Incremental Development process have evolved. (A good overview of this evolution of thinking about life-cycle models is have evolved. (A good overview of this valuable – provided we accept that it encompasses many forms and variations (Royce, valuable – provided we accept that it 1970; Boehm 1988; Davis concept is that its very usefulness might result risks involved in employing such a useful then used to in it becoming institutionalized, and 1982; Gladden, 1982). support it (McCracken and Jackson, is similar to the way in which ideas about design undergone a process of evolution that brief overview of some of the forms of development that are commonly adopted, the of the forms of development that brief overview of some examples of the domains form might be used, and some reasons why a particular be most appropriate. where its use might cept of the organized has been widely recognized to be very development activities were usually place in isolation, and in this chapter we examine some of the other factors that can other factors that some of the chapter we examine and in this place in isolation, the overall task of software process, by virtue of its context within influence the design development. generally involves perform- perceived markets. While each of these particular needs or upon each one, and the ways in set of activities, the emphasis put ing largely the same different. Table 3.1 provides a and interwoven, will be very which they are ordered 3.1 design for context A much for the purpose has been very two chapters of the preceding The discussion of the book, in terms subject matter constitutes the our views of what of clarifying the is influenced by ways in which this in general, and the design process of both the something that takes of design is not However, the task of software. characteristics Table 3.1

46 Design in the software development process SDC03 9/18/07 10:38 AM Page 46 AM Page 10:38 9/18/07 SDC03 47 A context for design (Royce, 1970), a maintenance Operation and testing Integration Unit waterfall model testing Coding design Detailed design Architectural analysis elicitation and Requirements study The waterfall model of the software life-cycle. Feasibility However formulated, most development processes tend to be couched in terms of However formulated, most development processes tend to be couched in Boehm (1988) has pointed out that a software process model of this form Boehm (1988) has pointed out that Figure 3.1 in some way, regardless of their sequencing. The specific processes described in in some way, regardless of their sequencing. The specific processes rest of this Table 3.1 are discussed more fully in the following two sections, and in the However, as we will see with the case of design methods in later chapters, its role is However, as we will see with the case of design methods in later chapters, asked than much more concerned with identifying where these questions should be with answering them! 3.1, and one the phases identified in the original waterfall structure shown in Figure be addressed might well argue that these encompass a set of tasks that always need to addresses the following software project questions. addresses the following software project 1. What should we do next? 2. How long should we continue to do it? given in Boehm (1988).) Royce’s formulation of the given in Boehm (1988).) Royce’s formulation 3.1, was a particularly influential refinement of version of which is shown in Figure the presence of ‘feedback loops’ between the earlier thinking that explicitly recognized ways, this corresponds to recognizing that the various stages of development. (In many of a ‘wicked problem’.) task of development is yet another example SDC03 9/18/07 10:38 AM Page 47 AM Page 10:38 9/18/07 SDC03 prob- . Operation can sometimes resemble an extended test- . Essentially these phases involve validating the imple- . This may involve devising data and communication . This may involve devising data and . Here the objective is to identify what ‘end-user’ needs is to identify what ‘end-user’ needs . Here the objective . Concerned with the overall form of solution to be adopted . Concerned with the overall form of . The role of such a study (where performed) is essentially to a study (where performed) is essentially . The role of such . Developing descriptions of the elements identified in the previous . Developing descriptions of the elements . Traditionally this is usually seen as a more formal modelling of the . Traditionally this is usually seen as (that is, of the needs identified in the documents produced from the require- (that is, of the needs identified in the As with processes, so it is with tasks. While the terminology used in different so it is with tasks. While the terminology As with processes, different issue – it may involve repeating all the tasks of the preceding phases and, different issue – it may involve repeating all the tasks of the preceding phases of its indeed, preserving the integrity of the system (in other words, the consistency Unit and integration testing from mented system against the original requirements, the specification produced the Analysis phase, and the design itself. Operation and maintenance is a rather ing phase, providing feedback from users in many ways. Maintenance tion is to meet the requirements. Coding (implementation) of code or, increasingly, involve writing ‘glue’ structures and writing large amounts Effectively, though, it involves ‘trans- code to join existing components together. some form of realised system and therefore lating’ the abstract design plans into takes its inputs from the design phase. Architectural design system, what the major elements will be (for example, whether to use a distributed and how they will interact). Detailed design with this. There are also clear feedback phase, and obviously involving interaction are to ensure that the behaviour of their solu- loops to earlier phases if the designers the reuse of existing software is encouraged. Analysis lem forms a major input to the design process, ments elicitation stage). Obviously this solution-based assumptions. and can very easily drift into making the architectural level (what form of solution might be most practical). (what form of solution might be the architectural level Requirements elicitation suggested that an ideal is required to meet. It is sometimes the intended system of any considerations is for it to be completely independent approach to this task However, this is increasingly less appro- of eventual design and implementation. need to interact with others, and also where priate, especially where one system will Feasibility study set of constraints. So such solution is attainable within the given explore whether a design issues, even if only at give some preliminary thought to a study will at least n n n n n n n sources may differ a little, the following are a practical set for our purposes: a little, the following are a practical sources may differ n section we briefly review the roles of the different development phases. In keeping with In keeping phases. development of the different the roles review we briefly section of how in terms be mainly will discussion our however, main theme, of our the spirit and process models fuller discussion of phases; for a relate to the design these tasks on Software Engin- a more general text should consult tasks the reader development (2001) and Van Vliet Sommerville Pressman (2000), as Pfleeger (2001), eering such the all discuss between these sources, differs slightly terminology (2000). Although approach. and the prototyping waterfall model forms, namely the main two

48 Design in the software development process SDC03 9/18/07 10:38 AM Page 48 AM Page 10:38 9/18/07 SDC03 49 A context for design -oriented, while that from ana- user will be concerned with identifying the needs of the library will be concerned with -oriented. Indeed, the role of analysis is an important one, since it forms will create a model of how the library works and hence produce a list of will create a model of how the library solution , 1996). The task classified in the study as ‘detailed design’ was particularly stable, design’ was particularly the study as ‘detailed task classified in , 1996). The So the output from requirements elicitation is The specification for this system may also need to describe the way in which the The specification for this system may Analysis Requirements elicitation As might be expected, regardless of how these tasks are organized, the design task regardless of how these tasks are As might be expected, design plan) could well be an important constraint upon the task of maintenance. task of upon the constraint be an important well plan) could design very long. also be phases can last two for these timescale The lysis is form their tasks will be strongly affected by the ease with which they can interact with form their tasks will be strongly affected by the ease with which they can own the information presented to them. (In some ways, this relates to the designer’s with a struc- use of ‘mental models’, since the interface should provide the librarians involved. We ture that matches their own mental models of the processes that are objects’ might reasonably also expect that this will be expressed in terms of ‘library rather than ‘computing objects’.) ling paper-based records. One of the roles of the analysis task should, therefore, be to ling paper-based records. One of the appropriate.) identify where such changes might be are to be organized (the ‘look and feel’ users’ interactions with the final system interfaces is still a relatively specialized and aspects). The design of human–computer flavour. In this example it will be a very difficult art, with a strong multi-disciplinary with which the librarians will be able to per- important element, since the efficiency number of books that a borrower has on loan or requested is exceeded – and even what number of books that a borrower has has the book being requested! (One prob- is to happen when the borrower already appropriate to ‘freeze’ particular organizational lem for analysis is that it may not be the likely effects of introducing the new system. models of practice without considering library might be better advised also to change It may well be that in our example the originally formulated for the purpose of hand- some of the practices or rules that were lists, so that the library staff can consider whether to order additional copies. Such an lists, so that the library staff can consider interactions and organizational relationships analysis will usually also consider the of the users of the system. that may exist between the various needs to provide, and the behaviour it should exhibit functions that the system will need given conditions. As an example, the book when performing these functions under effects of adding a request when the maximum reservation function should specify the little more, therefore, we shall examine the simple example of a computer system that we shall examine the simple example little more, therefore, CDs and videos for a local issue, reservation and recall of books, is to support the briefly, these are as follows. library branch. Very An example of such a need terms of the purposes of the library. staff and users, in books that have particularly long reservation might be the facility for identifying those taking around 20 per cent of total effort and 20 per cent of total time. Interestingly, per cent of total effort and 20 per cent taking around 20 were classified as being regardless of whether the organizations this seemed to be true of over 25 per cent during the in development speed ‘fast’ (showing improvements or less). or ‘slow’ (improvement of 25 per cent previous five years) list. To clarify their roles a to the tasks that precede it in the above is strongly linked The proportion of effort allocated to these tasks is one that depends upon many factors. is one that depends to these tasks of effort allocated The proportion set upon a global developers that drew of software a study of the practices However, expected (Blackburn great as might be are not as that the variations of data suggests et al. SDC03 9/18/07 10:38 AM Page 49 AM Page 10:38 9/18/07 SDC03 to be done. is (and hence the form) of the software design process (and hence the form) of the software design organization While process models are an important element in Software Engineering as a While process models are an important element in Software Engineering Such a form is, therefore, also attractive to the purchasers of such systems, since it Such a form is, therefore, also attractive the main effect of production models of any One thing we can conclude is that One of the attractions in such a form (and, indeed, one of the motivations for One of the attractions in such a form This last point is particularly true where there is no established ‘market’ for a new true where there is no established This last point is particularly As the discussion of the following sections will show, the processes involved are show, the processes sections will of the following As the discussion been done than for assisting in the planning of what been done than for assisting in the planning to look at other, non-linear, forms of model, we should very briefly mention one other to look at other, non-linear, forms of model, we should very briefly mention linear form. itself. Since linear forms usually provide a stronger framework for management, it will itself. Since linear forms usually provide a stronger framework for management, that these not, therefore, be surprising when we come to look at design methods to find particular. largely assume the use of a linear life-cycle, and of the waterfall model in our only whole, it is inappropriate to pursue the topic too deeply in this book, since moving on real concern here is how they affect the process of design. However, before allows for long-term budgetary planning, as well as providing the basis for legal con- allows for long-term budgetary planning, inappropriate for a creative process may tracts. The fact that this is almost certainly of software by government agencies has well explain why the history of procurement catalogue! tended to form something of a dismal form is to influence the planning developments as well as for monitoring and controlling them. Within such a planning developments as well as for that can be used to record progress against form, the planning can identify ‘milestones’ as already observed, such an approach can some general plan of production. However, a straitjacket (Gladden, 1982; McCracken easily result in the framework becoming employed for providing a description of what and Jackson, 1982), and it is far better has 3.2 processes development Linear process is that based upon the waterfall The most familiar form of linear development in Table 3.1, this has traditionally been the model shown in Figure 3.1. As indicated to measure’ systems. development process used to create ‘made it provides a strong management framework for developing life-cycle models) is that develop its potential. One of the characteristics of developing software artifacts One of the characteristics of develop its potential. may well devise new and ima- forms of artifact too), is that users (indeed, many other different from those that the for an item of software that are very ginative applications had envisaged! original developers ing the ‘real’ needs of the user may involve some development of prototypes in order of the user may involve some development ing the ‘real’ needs work to take advantage of and better ways of organizing their to help them see new system can do for them. what a computer-based needs to be demonstrated at case, the usefulness of the application application. In that well be essential for it to fully and user feedback may an early stage of development, the ‘watershed’ at which thinking moves from stating the problem or need, to begin- or need, problem the from stating moves thinking at which the ‘watershed’ met. it can be about how to think ning paragraphs. Even in the preceding have been implied sequential as might rarely as and revision some backtracking development is pursued, process of where a sequential or some inconsistency each time phases will be needed from earlier to the outputs will see later, elicit- tasks. Also, as we the later is revealed while performing omission

50 Design in the software development process SDC03 9/18/07 10:38 AM Page 50 AM Page 10:38 9/18/07 SDC03 51 Incremental development processes , 1984). The goal, there- , 1984). The et al. the product in due course, and there is the product in due course, and there be which can be used to investigate both problem and which can be used to investigate both of a prototype might be different for the case of soft- of a prototype might be different for form is one that periodically attracts attention. In many ways, the In many attracts attention. that periodically is one for building prototypes remain much the same as in other for building prototypes remain much prototype . This is the form that is closest to the idea of the ‘incremental develop- reasons transform model transform One benefit of this strategy is that it may be possible to issue a release of the One benefit of this strategy is that it may be possible to issue a release of A useful categorization of the different roles that prototyping can play in software A useful categorization of the different In the case of software, where manufacturing the end product is simply a matter In the case of software, where manufacturing In other engineering domains, such a situation is often resolved by the construc- domains, such a situation is often In other engineering The product while it is still technically incomplete, although usable. (Of course, many product while it is still technically incomplete, although usable. (Of course, never software products such as word processors, operating systems, etc. are really Evolutionary changing ment’ of a solution. The software for a system is adapted gradually, by the the requirements step by step as these become clearer with use, and changing and the system to fit these. In this form, prototyping is used to develop a product prototype gradually evolves into the end product. 1. forms of engineering: prototypes are constructed in order to explore an idea more forms of engineering: prototypes are other means. completely than would be possible by Floyd (1984). Her analysis recognizes three prin- development has been produced by cipal roles for software prototypes. ware, the basic really no concept equivalent to that of the scale model. (In that sense, there are really really no concept equivalent to that although sometimes more abstract toolkits can no short-cuts to writing software, help.) However, while the of making copies, these analogies do not really apply. In software production it is quite of making copies, these analogies do possible that the prototype will actually solution. However, where software is concerned, the concept of the ‘prototype’ is a solution. However, where software For more traditional forms of engineering, a bit harder to define with any exactitude. a ‘first of its kind’, or some form of model that prototype is generally regarded as being with the idea of a prototype of a new model is produced to scale. We are all familiar or ships. (On a somewhat larger scale, the of a car, and with scale models of buildings Barrage down-river from London built a scale civil engineers constructing the Thames model of it in the nearby marshes.) what is required of the eventual system has to be addressed right from the start. In the eventual system has to be addressed what is required of many more where, despite con- impractical, and there are some cases this is effectively requirements, there may in techniques for determining the eventual siderable advances and possible omissions. be many uncertainties tion of some form of 3.3 processes development Incremental the need to identify exactly of a linear development process is that A major limitation aim is to extend the idea of the compiler (which automatically generates machine- generates automatically (which compiler of the the idea is to extend aim (Lehman of abstraction to a higher level specific code) scope for progress (Friel and Budgen, 1997). scope for progress fore, is to achieve automatic conversion of a formal specification of a system into a of a system into formal specification conversion of a achieve automatic fore, is to this has been made in practical progress Little that satisfies that specification. program why good reasons chapters suggest some the preceding two the arguments of area, and do seem to offer more of the model more limited versions be so. However, this might SDC03 9/18/07 10:38 AM Page 51 AM Page 10:38 9/18/07 SDC03 require- are listed and explored; , while in many ways a rather ‘visionary’ one when pub- , while in many ways a rather ‘visionary’ to a problem, by developing it in advance of large-scale imple- it in advance of large-scale to a problem, by developing constraints of the stage are identified; . This role is distinguished by the use of the prototype for evaluating by the use of the prototype . This role is distinguished . In this role a prototype is used to help with clarifying user is used to help with clarifying . In this role a prototype and solution spiral model involved in choosing between options are evaluated; and possibly with identifying how the introduction of the system might lead identifying how the introduction of the and possibly with for how to proceed to the next stage is determined, which may require the for how to proceed to the next stage is determined, which may require Used in this role, the prototype provides something in the nature of a feasibil- Used in this role, the prototype provides objectives options risks plan Boehm’s the data collected to help with making a final evaluation. the data collected to help with making likely to be a ‘throw-away’ item, and it can be considered as enhancing the informa- likely to be a ‘throw-away’ item, and analysis and the functional specification tion that is provided from the requirements activities. ity be incomplete, since the purpose may be focused on study. Much of it may functionality. Some form of monitoring resolving only limited aspects of system in this kind of prototype, its aim being to use facility is likely to be a useful feature mented in a form quite different to that which will be used for the final system itself. different to that which will be used mented in a form quite Exploratory ments organization. One purpose the wider work practices of an to the need to modify analysis of users’ needs by providing a set of might be to help with developing an Essentially this form of prototype is also possible models for them to use and assess. Experimental a possible including the assessment for doing this may be manifold, mentation. The reasons effectiveness of a particular resource needs, evaluation of the of performance and so on. This form of proto- assessment of an algorithm and form of user interface, and might well be imple- intended to be a ‘throw-away’ item, type is essentially complete, since their roles are effectively unbounded.) Later releases can then pro- can then releases Later unbounded.) are effectively their roles since complete, this While functionality. in product increase gradual with a the users vide it does have for all purposes, not be appropriate to development may approach also where it is of ‘pioneering’, and involve a degree in areas that some attractions (Cusumano and the marketplace of a system into to get an early release important Selby, 1997). development of a prototype, or may more closely approximate to a traditional waterfall step, according to the conclusions of the risk analysis. the the the a n n n n lished, is probably the most effective approach to combining experience in using the lished, is probably the most effective of how software projects have actually been waterfall model with greater knowledge it explicitly assumes the use of prototyping developed (Boehm, 1988). As such, purpose). An outline of this is shown in Figure (although not of a particular form or following activities should occur: 3.2, and at each stage of the spiral the Of course, any actual use of a prototyping approach may span these forms, since there Of course, any actual use of a prototyping a prototype. However, going back to the may be many different reasons for developing purpose, the processes of prototyping are (not theme of this chapter, regardless of within a process model. surprisingly) relatively difficult to describe 3. 2.

52 Design in the software development process SDC03 9/18/07 10:38 AM Page 52 AM Page 10:38 9/18/07 SDC03 53 Incremental development processes , is reactive software is prob- open source , since this links back to the very (http://www.fsf.org/fsf/fsf.html) and the risk evaluation Free Software Foundation The spiral model of the software life-cycle. While the roots of the open source movement lie back in the pioneering work of While the roots of the open source movement lie back in the pioneering The third form of development cycle that was identified in Table 3.1, the The third form of development cycle Figure 3.2 (After Boehm (1981) © 1981 IEEE) of the concept did not emerge until the 1990s, when the Linux operating system kernel of the concept did not emerge until the 1990s, when the Linux operating for PCs. came together with GNU to provide a widely distributed free operating system ably the best-known example of this approach, we will discuss it largely in this context. ably the best-known example of this approach, we will discuss it largely in Richard Stallman’s awareness GNU project (a recursive definition of GNU is ‘GNU’s Not Unix’!), wider one that it is also appropriate to consider in this section, since it can be seen as a variation one that it is also appropriate to consider in this section, since it can be seen upon the incremental approach. Since the development of Within the context of a prototyping strategy, perhaps the most important element Within the context of a prototyping to highlight from this list is that of need to be adopted. In particular, given that one reasons why such an approach might itself is that the sense of ‘direction’ may of the risks implicit in the use of prototyping a particularly valuable means of monitoring and become lost, the spiral model offers controlling the development process. SDC03 9/18/07 10:38 AM Page 53 AM Page 10:38 9/18/07 SDC03 Join that project Vote for a license model Vote Do little document writing CVS version control Release official version in the foreseeable future No Yes Accept patches and modifications (vote or dictatorship) A personal itch A Initiate a project Decide a license model Use mailing list for announcement and bug tracking: use OpenPGP Use mailing list for announcement Look for any similar projects Look for any Write documents and manuals Write The general open source system development cycle. The general open source system development The open source movement provides an interesting (and increasingly important) In many ways the development life-cycle of open source software is totally differ- In many ways the development life-cycle Figure 3.3 (Taken from Wu and Lin (2001) © 2001 IEEE) context for design activity. However, in terms of the subject matter of this book, it context for design activity. However, in terms of the subject matter of can largely does not actually introduce many new issues of a technical nature, and so be regarded as an example of a particular form of prototyping. ordinators drawing together the ideas of many participants. Figure 3.3 shows a model ordinators drawing together the ideas of many participants. Figure 3.3 shows is not wholly of this process, taken from Wu and Lin (2001). However, even this model and it is consistent. Many projects have begun with a single developer (as did Linux), return to this the extension and evolution that is then influenced by the many. (We will issue of evolution in Section 3.5.) ent to those considered so far, even though it is incremental in form (Wu and Lin, ent to those considered so far, even organization, rather than in the steps themselves. 2001). The key difference lies in its number of decision-makers (designers) directing Instead of the ideas from a small source model involves a small number of co- the efforts of many developers, the open

54 Design in the software development process SDC03 9/18/07 10:38 AM Page 54 AM Page 10:38 9/18/07 SDC03 55 Economic factors is struggling to emerge in order is struggling Web Engineering Web Engineering in any sense, and that it involves navigating through in any sense, and that analytic Inconsistency between the design and the specification is more likely to be detected Inconsistency between the design and the specification is more likely to be A consequence of this is that, with so large and ill-defined a solution space, the A consequence of this is that, with Again, from the viewpoint of this book, while interesting in itself, this domain of this book, while interesting Again, from the viewpoint The second example of reactive development is that of the ‘website’. Respons- ‘website’. that of the is development reactive of second example The while the design is being implemented (transformed into programming structures); logical while the implementation of the system is being tested, since this may reveal inconsistencies in its behaviour. when the design is being refined, perhaps arising from structural inconsistencies when the design is being refined, perhaps that is obtained from different view- that emerge when comparing information seeking out such errors is that of the design points – a widely used technique for Weiss, 1987); review (Yourdon, 1979; Parnas and the design is not self-consistent, so that it cannot be successfully or efficiently imple- the design is not self-consistent, so that mented as it stands; consistent; the design and the specification are not not consistent. the design and the requirements are lar form and type of error. it may well during testing (although if prototypes are constructed during development, n n the particu- The degree to which the design will need to be changed depends solely on Inconsistency in the form of the design itself may be revealed at various stages in its Inconsistency in the form of the design development. It may appear: n n n n 3.4 factors Economic in Chapter 1, a key point that the design process was examined When the nature of is not emerged was that it ibility for the development and maintenance of the elements of these is often widely is often of these elements of the maintenance and development for the ibility much more concerned manager’ being with the ‘site within an organization, devolved of The growing use of content. than with management of style with co-ordination ‘active’ comes development increasingly also means that site such as scripts, site elements, a co-ordinated form. not necessarily of although evolutionary prototyping, to resemble of of this, a discipline In recognition of the abstract nature of software, which makes it difficult to identify and specify all of the abstract nature of software, which makes it possible to identify many solutions to a needs, and also because the medium given problem. design that contains ‘errors’. These might be of design process can easily lead to a ones are: many kinds, but some particularly significant a ‘solution space’ that may be very – indeed, extremely – large. This is partly because a ‘solution space’ that may be very – to address the challenges presented by both the rapid rate of technological change and presented by both the rapid rate to address the challenges of development. also the devolved nature technology for us to study, any particular example of design does not (so far) provide needs. this may be one of its most urgent although arguably, SDC03 9/18/07 10:38 AM Page 55 AM Page 10:38 9/18/07 SDC03 : are we building the product right? : are we building the right product? The cost of fixing ‘bugs’ at each stage of development. The cost of fixing ‘bugs’ at each stage of Unfortunately, since the main error-detecting tasks are performed later on in the Unfortunately, since the main error-detecting tasks are performed later Boehm has provided a very useful way to distinguish clearly between the actions Boehm has provided a very useful way Inconsistency between the design and the actual needs of the user (the require- Inconsistency between the design and Verification Validation life-cycle, errors in specification and design can prove costly to fix when compared life-cycle, errors in specification and design can prove costly to fix when designs with errors in coding. Ideally, therefore, we need to find ways of evaluating results of a study by Boehm, shown in Figure 3.4, suggest that the cost of error detec- results of a study by Boehm, shown in Figure 3.4, suggest that the cost of development tion and correction goes up by an order of magnitude at each stage in error in the (Boehm, 1981), a ratio still widely considered to be the case. That is, an as it would design costs ten times as much to fix if it is detected during the testing phase if it were detected during the implementation phase. Any inconsistencies in a design, whatever their form, need to be detected and identified Any inconsistencies in a design, whatever a decision can be made about what to do. The at as early a stage as possible, so that the larger a task it willlater in development they are detected, them right. The be to put ments) is a much more difficult issue, although again it may be assisted by the use of ments) is a much more difficult issue, for such inconsistencies is normally termed prototypes. The procedure of checking ‘validation’. combined together and referred to as ‘V & V’ – of verification and validation (often the distinction!): possibly to duck the question of making Figure 3.4 (After Boehm (1981) © 1981 IEEE) is usually used for this task of checking a be detected earlier). The term ‘verification’ system. design against the specification for the

56 Design in the software development process SDC03 9/18/07 10:38 AM Page 56 AM Page 10:38 9/18/07 SDC03 57 The longer term changes proceeding to implement them. Prototyping offers one such offers Prototyping them. implement to proceeding before before maintenance is performed to fix any ‘bugs’ that may be detected in the to fix any ‘bugs’ that may be maintenance is performed maintenance is concerned with extending and improving a system once it with extending and improving maintenance is concerned maintenance is performed in order to meet needs for change that are in order to meet needs for maintenance is performed Of course, this concept is familiar enough when applied to manufactured items Of course, this concept is familiar enough when applied to manufactured This reinforces the earlier point that the structure of a system should allow it to be This reinforces the earlier point that Another economic issue that needs to be considered is the cost of making is the cost of needs to be considered issue that Another economic imposed from outside (examples of these might be changes in legislation affecting (examples of these might be changes imposed from outside similar type of change that change of operating systems, or any a financial package, factors). arises from external Corrective operational system. Perfective requested by users. by providing new forms of functionality is operational, typically Adaptive current version of a given model may be very different to those of the same model current version of a given model may be very different to those of the when it was first launched on to the market. ated, the form of the product may itself then need to evolve and change over time. ated, the form of the product may itself then need to evolve and change car, the gen- such as motor cars, washing-machines, cameras, etc. For a given model of manufacturer eral characteristics might not change greatly from year to year, but the As these will almost certainly introduce annual changes to styling, features, choices. form of the accumulate over a number of years, the result is that the appearance and 3.5 term The longer centred upon the notion that the design process Most of our discussion so far has been form of plan that can be used for developing a is completed once it has delivered some sections of this chapter have indicated, once cre- product. However, as the preceding and finding errors errors and finding ponents undergoing frequent revision can often be found in the design of cars and elec- ponents undergoing frequent revision practices may create constraints that limit the tronic goods.) As already observed, such so increasing the initial cost while decreasing ‘solution space’ available to the designer, way in which most organizations budget for the long-term cost. Unfortunately, the for such practices to be adopted as effectively as software production is too short term might be desired. In practice, the first of these is generally dominant, and it has been estimated that In practice, the first of these is generally work falls into this category. around 65 per cent of all maintenance adapted to cope with likely changes (or, at least, modified fairly easily, so that it can be it would be difficult to make much useful with perfective and adaptive changes; This is a principle that has been common in allowance for likely corrective changes!). for a long time. (Examples of the design of com- many other branches of engineering 3. maintenance activity that occur in practice, and identified three main forms. that occur in practice, and identified maintenance activity 1. 2. approach, although there are some possible side-effects to this approach that can to this approach side-effects possible are some there although approach, cost-effectiveness. reduce its enhancements with time, undergoing systems evolve Most software-based to a system. per- and faults in environment alters, the users alter, the as the needs of and changes the types of software (1980) studied and Swanson are identified. Lientz formance SDC03 9/18/07 10:38 AM Page 57 AM Page 10:38 9/18/07 SDC03 utility E-type cp it is essentially it is essentially usually exhibits perfective mainten- perfective releases evolution program or system is one which is only required to program or system is one which is only S-type that was described in the last section (Lientz and Swanson, 1980). While strictly, 1980). While and Swanson, (Lientz last section in the was described that If we continue to concentrate on E-type systems, then for our purposes this If we continue to concentrate on E-type systems, then for our purposes The evolution of E-type systems through a series of The evolution of E-type systems through A useful distinction between systems that do evolve and those that are essentially A useful distinction between systems There are of course many reasons why designers might fail to anticipate the future many reasons why designers might There are of course For software, the equivalent to this process is the concept of concept is the this process to the equivalent For software, needs for change, anticipate future or been unable to have failed When designers development process needs to be modified to describe its effects, while the second is development process needs to be modified to describe its effects, while how is the design process itself affected? certain characteristics when viewed over a period of time, requiring both anticipation certain characteristics when viewed over a period of time, requiring both that and planning for change. The nature of this process of evolution is not something review of we have space to discuss here but, for those interested, a very comprehensive the issues involved is provided in Lehman and Ramil (2002). the overall concept of system evolution introduces two questions. The first is how meet a ‘formal’ specification. One example of such a program might be the meet a ‘formal’ specification. One example systems. The specification for this is simply that used in the Unix and Linux operating and hence the program, is something it should make a copy of a file. This specification, and such changes as might occur, such as (say) which does not really change over time, are ones that will not change its basic extending it to handle distributed filestores, functionality. system is one that is used to ‘mechanise a human or societal activity’, and so it must system is one that is used to ‘mechanise in order to remain satisfactory. There are many evolve and change with its context systems need to support new activities and to examples of such systems: operating need to support new tasks or new ways of make use of new devices; office packages need to incorporate legislative changes, and so doing business; pay-roll packages may on. In contrast to this, an changes. Another is that designers themselves may also lack vision about the future, changes. Another is that designers themselves deep knowledge about the domain in which the especially where they lack any very may find themselves with inadequate or system is to operate. Similarly, maintainers hard to ensure that their changes are consistent inaccurate documentation, making it with the original plans. and Ramil, 2002). Very simply, an ‘static’ has been made by Lehman (Lehman system may well not have lasted so long; however, the failure lay in not anticipating have lasted so long; however, the system may well not from the original one. at least in part, in systems that evolved that it would survive, of regarding system develop- common one arises from the practice adequately. A very budget headings, which can as coming under quite different ment and maintenance have no incentive to consider future easily lead to a situation where developers scope for problems to arise within this process of evolution. Probably the best known to arise within this process of evolution. scope for problems revise many systems at the start the need that arose to extensively example of this was to handle dates that began with Y2K problem) in order to be able of the year 2000 (the because the original developers ‘1’. In many cases, this was simply a ‘2’ rather than a such a long period of time. that their software would be used for had not expected expectation, in that the original this was probably a reasonable Indeed, in many cases ance in physical product be used with a as the term would ‘maintenance’ this is not a process of engineering, as such as motor car a domain identical. there is ample design structures, have failed to preserve maintenance teams and when

58 Design in the software development process SDC03 9/18/07 10:38 AM Page 58 AM Page 10:38 9/18/07 SDC03 59 Summary without to be used in a , 1995) is much more if ‘it can be used, et al. easily changed general (Gamma ‘if it is flexible design pattern forms tend to be unsuited to encouraging reuse, other than in a forms tend to be unsuited to encouraging procedural , in a variety of situations’, and , in a variety of situations’, Following from the discussion of the two preceding chapters, this should perhaps Following from the discussion of the Planning for reuse in this way has not generally been one of the more effective Planning for reuse in this way has In contrast, the concept of the Software development technology has been extensively influenced by this and by technology has been extensively Software development The effect upon the design process is less readily characterized. The need to design process is less readily characterized. The effect upon the At its most simple, the effect upon the life-cycle is to extend it to recognize the recognize it to is to extend the life-cycle effect upon the most simple, At its design in the context of particular life-cycle models, most notably the linear (waterfall) and design in the context of particular life-cycle models, most notably the linear (waterfall) incremental models; Summary come as no surprise. If the act of designing is essentially a process of postulating solu- come as no surprise. If the act of designing for postulating how the problem itself might tions to a problem, then adding the need simplify that process! However, it is a very real change over time is hardly likely to later. need, and one that we will return to readily related to the ideas about generality and flexibility that Parnas put forward, readily related to the ideas about generality However, the pattern concept is more largely because the idea of reuse is encouraged. instances of such ideas, or identifying how they strongly oriented towards recording ways to create the opportunity. In that sense, might be organized, than to finding the basic problem remains. although they extend the ideas of Parnas, seek opportunities to reuse design ideas or structures. seek opportunities to reuse design ideas which have generally been formulated on the elements of software design methods, as a new and unique one. Indeed, as we will see basis of treating each design problem later, their fairly general way. change variety of situations’. are more readily achievable Parnas, and in some ways these goals other ideas of David they may be technically re- he first stated them. However, while than they were when the design process to encourage the designer to alizable, achieving this still requires n An understanding of software design requires an appreciation of its role in the software develop- An understanding of software design requires an appreciation of its role in the software approach ment process, since the context that this provides influences the form of design needed. In this chapter we have examined: address this problem of evolution was recognized by David Parnas in 1979 (Parnas, of evolution was recognized by address this problem and identified the need that ‘flexibility cannot be an afterthought’ 1979), who argued for a system. Parnas also when formulating the requirements to plan for extensions and flexibility, where conscious design decisions about generality argued for making could be considered as being the design of software process of evolution right through to the eventual ‘retirement’ of a system (Rajlich and (Rajlich of a system ‘retirement’ eventual to the through right of evolution process that more closely development forms more evolutionary 2000). Indeed for Bennett, least from a technical natural step, at this is a fairly Boehm’s spiral model, resemble pro- totally different maintenance as development and Rather than seeing viewpoint. in the evolutionary the initial step the former is simply view argues that cesses, this on this basis. planned and financed that it should be process and SDC03 9/18/07 10:38 AM Page 59 AM Page 10:38 9/18/07 SDC03 IEEE Com- (1), 15–44 can play in supporting aspects of the design process; supporting aspects can play in 11 phase, and upon the design of E-type systems in particular. phase, and upon the , prototyping maintenance : are we building the product right? : are we building : are we building the right product? : are we building the Annals of Software Eng. (5), 61–72 21 , verification validation (a) an interactive word processor; (b) a web-based e-commerce site dedicated to selling sheet music of all types; (c) a bank auto-teller network for dispensing cash and providing receipts. that In each case, which group of people would be involved with reviewing any prototypes were produced, and what forms might a prototype usefully take? (a) verification (b) validation purposes? and how might they be improved for these of the following software systems: the cost of fixing errors in design at a later stage of development; the cost of fixing errors the influence of the the associated role of requirements elicitation in setting the context for the various design for the the context in setting elicitation role of requirements the associated activities; software the roles that of: needs, and the roles meets the users’ of how well a design the question agement. puter Exercises Further reading 3.2 could perform (if any) in the development Consider the roles that different forms of prototype 3.1 conform to the objectives of How do your techniques for testing an item of software adopted for the spiral model. and tools for software evolution planning and man- Lehman M.M. and Ramil J.F. (2002). Rules evolution that considers the ways in which soft- A comprehensive review of the laws of software time. Includes a useful discussion of the characteristics ware elements and systems evolve over of E-type systems. Boehm B.W. (1988). A spiral model of software development and enhancement. A spiral model of software development Boehm B.W. (1988). and roles of software life-cycle models from the pen This is a very clear exposition of the forms introduction and then the rationale for the form of the guru himself. It provides a historical n n n n n

60 Design in the software development process SDC03 9/18/07 10:38 AM Page 60 AM Page 10:38 9/18/07 SDC03 61 Exercises system that is used to manage the airspace for a number of busy airports. manage the airspace for a number of busy system that is used to as such, whether they might be classified as being E-type or S-type. Identify the relevant form or S-type. Identify classified as being E-type they might be as such, whether for each case: likely to be employed of maintenance (a) supports multiple languages; processor that used with a word a spell-checking program (b) in an operating system; directory (folder) used list the contents of a a program used to (c) in an air traffic control information about the position of aircraft a system used to display 3.3 and, future in the ‘maintenance’ may require systems following each of the why List reasons SDC03 9/18/07 10:38 AM Page 61 AM Page 10:38 9/18/07 SDC03 SDC03 9/18/07 10:38 AM Page 62 SDC04 9/18/07 10:43 AM Page 63

chapter 4 63 Design Qualities

4.1 The quality concept 4.3 Quality attributes of the 4.2 Assessing design quality design product 4.4 Assessing the design process

Since one of the objectives of the software design process is to produce as ‘good’ a design as possible, this chapter is concerned with examining some of the ideas about what exactly constitutes a ‘good’ software design. It begins by examining some ideas about the properties asso- ciated with good quality in software, and then proceeds to consider how it is possible to make measurements at the design stage that might identify these properties and how the design process can be involved in meeting quality objectives. better the one is than the other. better the one is than , one needs to seek high standards of quality in , one needs to seek how much products . process We also encounter once again the dual nature of software in thinking about how We also encounter once again the dual nature of software in thinking about For software, as for other artifacts, it is also difficult to separate ideas about design For software, as for other artifacts, it Since software is such an abstract product, it is perhaps less apt to be influenced Since software is such an abstract product, When it comes to assessing design, rather than construction, the problem is, if assessing design, rather than construction, When it comes to Unfortunately, quality is a concept that can rarely be related to any absolutes, and is a concept that can rarely be related Unfortunately, quality any set of measures that we can develop should seek to assess both of these, and should any set of measures that we can develop should seek to assess both of these, the specified recognize the potential for conflict between them. (A program may meet that it real-time needs very well, but its internal structure may be so poorly organized amount of good craftsmanship applied to its construction will be able to disguise its amount of good craftsmanship applied to its construction will be able to if it is posi- fundamental failings. (The door may be well made and may close well, but still find it tioned so that we graze our knuckles each time it is opened, then we will inconvenient to use.) and so we can identify its quality. Software has both static and dynamic attributes, quality from one’s thinking about implementation quality. To return for a moment to quality from one’s thinking about implementation introduced in Chapter 1: no matter how good the example of the garden shed that was efficient use of materials and ease of construc- the design is, in terms of proportions, its quality will still be very largely influenced by tion and modification, our ideas about assembled, then, regardless of how good its design the actual construction. If it is badly of good quality. Equally, if the design is poor, no may be, we will not consider it to be by fashion (a debatable point, perhaps, especially in relation to user interface design), by fashion (a debatable point, perhaps, of quality is equally difficult to define for but it is hardly surprising that the concept be quantified in any way, and those measures that software. Few quality attributes can the idea of quality as applied to soft- we do possess are of uneven value. Furthermore, in nature, so it is certainly not guaranteed by the ware is at least partly problem-related process. use of some particular form for the design we appraise the quality of typefaces, furniture and clothes. We associate elegance with we appraise the quality of typefaces, our thinking and, even worse, is likely good design, yet it offers no help in quantifying strongly influenced by our ideas about fashion – to have ephemeral aspects: it may be an example, a 1930s radio set might look quite so creating a context for quality. (As in 1930s style, but would be most unsuited to a in place in a room that is furnished of the 1980s.) room that was furnished in the style on any absolute scale. The best that we can usually do is to rank items on an ordinal The best that we can usually do on any absolute scale. this coffee table is better than that we believe the construction of scale, as when we say it exhibits. However, terms of materials used and the workmanship that of another, in of defining we lack any means often associated with visual properties, as when anything, worse. Quality in design is rather than of design, yet quality in construction depends upon good design: to achieve yet quality in construction depends rather than of design, and in order to achieve high high standards are needed in both, a high-quality product in design standards of quality the design cannot be usefully measured items ideas about quality usually even for manufactured 4.1 concept The quality it with proper- we tend to associate familar one, although of quality is a The concept of design. Asked rather than with those of construction from the tasks ties that arise as such examples are likely to identify many people of ‘good’ quality, for examples on an expensive of the paintwork of furniture, the quality joints on an item well-made of construction are examples of quality fabric. All these texture of a woven car, or the

64 Design qualities SDC04 9/18/07 10:43 AM Page 64 AM Page 10:43 9/18/07 SDC04 65 Assessing design quality scales physical ratio , be capable of perform- product must since the end fitness for purpose fitness for The next section begins by looking at a framework that enables us to identify some The next section begins by looking at This concept is related to the ideas of verification and validation that were intro- This concept is related to the ideas of This acts as a reminder that we should not seek to achieve elegance of form at the that we should not seek to achieve This acts as a reminder While our ideas of quality measures are perhaps essentially determined by the essentially determined measures are perhaps ideas of quality While our ‘When you can measure what you are speaking about, and express it in numbers, ‘When you can measure what you are you cannot measure it, when you cannot you know something about it, but when is of a meagre and unsatisfactory kind.’ express it in numbers, your knowledge (Lord Kelvin.) (they possess well-defined intervals and a zero point), so we can be sure that when (they possess well-defined intervals and a zero point), so we can be sure has a length measuring the property of length in units of centimetres, something which value of 8 will be twice as long as something with a length value of 4. 4.2.1 for assessment A framework within While Lord Kelvin’s dictum is widely quoted, it is easy to overlook the context a com- which it was made. Ideas about measurement originally emerged largely within munity of scientists and engineers who were seeking to capture ideas about could be properties such as mass, length, velocity, etc., where measurement scales more readily developed and shared. The scales used for such properties are ines some of the system attributes that relate to these properties, and briefly considers ines some of the system attributes that the influence of the design process itself in help- how these might be assessed. Finally, is considered. ing to produce the desired design properties 4.2 quality design Assessing duced in the last chapter, since comparisons are being made with expectations as duced in the last chapter, since comparisons As a measure for practical use, however, expressed in the requirements specification. So it may be better to consider fitness for it can be assessed only by indirect means. look for ways of assessing it by finding a set of purpose as an ultimate goal, and to system attributes that provide measures of these. associated properties and then some general ideas about quality. Section 4.3 exam- of the system properties that reflect our expense of function. So for software systems, we can reasonably expect to find that the So for software systems, we can reasonably expense of function. in all the required situations. system works, and works correctly final implemented manner, and within the perform the required tasks in the specified That is, it should can only measure the ultimate specified resources. (Once again, we constraints of the through its implementation.) success of a design ing the task assigned to it. As an example, however elegant the design of a chair may to it. As an example, however elegant ing the task assigned be able to sit on it, and the basic requirement that we should be, it must still meet used for assessing this will be Therefore the quality factors to be preferably in comfort. of the system that is being by considering the role (purpose) selected and weighted designed. is virtually impossible to modify it in any way. Equally, the structure of a program may of a program structure the way. Equally, it in any modify to impossible is virtually is awful!) performance run-time while its good, be very very general measures to find some itself, it is still possible the design object nature of of software. In terms can be applied to and which that are fairly universal, of quality quality should norm- measure of any system the ultimate for these, for the objectives of ally be that SDC04 9/18/07 10:43 AM Page 65 AM Page 10:43 9/18/07 SDC04 ). ’, so at this point it is useful to identify ’, so at this point it metric attributes of entities scale (where elements can be ranked, but where the sizes of the ranked, but where elements can be scale (where provide a set of measurable (or at least, identifiable) character- provide a set of measurable (or at least, are the abstract ideas that we have about what constitutes ‘good’ that we have about what constitutes are the abstract ideas ordinal are concerned with realizing the design attributes, and so involve identify- are concerned with realizing the design Mapping quality concepts to measurements. Fenton and Pfleeger (1997) have observed that ‘measurement is concerned with (1997) have observed that ‘measurement Fenton and Pfleeger an initial set ofFigure 4.1 shows these that can be constructed to link mappings Once we move away from this context, while the idea of measurement is still a valu- of measurement the idea while this context, away from we move Once istics of the design entities and so provide mappings between the abstract idea of a istics of the design entities and so provide of an actual design (and therefore effectively property and the countable features a correspond to the general concept of Counts that will need to be counted in order to ing the lexical features of a representation obtain some form of values for the metrics. Quality concepts be assessed by the designer of a system, and which will need to and ‘bad’ properties choices. when making decisions about design Design attributes Figure 4.1 As an example of a widely used metric that fits into this framework, the quality of As an example of a widely used metric to be related to its structural complexity. One program code is often considered n ideas. The key terms used in the figure can be interpreted as follows. used in the figure can be interpreted ideas. The key terms n n quality, we will need to treat them with care. The act of assigning a numerical value to to treat them with care. The act of quality, we will need using a ratio scale.) necessarily mean that it has been measured a property does not about capturing information to ideas about measurement. our ideas about quality can be tied more carefully how able one, we often have to accept a more limited type of knowledge than that which Lord type of knowledge a more limited we often have to accept able one, likely to be ‘meas- to us are more the properties of interest to. Many of Kelvin aspired an ured’ using particularly true when and this is cannot be specified), between the elements intervals design qualities. (Even an assessment of of making to consider the problem we come to ideas about design that relate values for properties do obtain numerical when we

66 Design qualities SDC04 9/18/07 10:43 AM Page 66 AM Page 10:43 9/18/07 SDC04 67 Assessing design quality (This point tends interpretation. A fuller mapping from concepts of quality to countable attributes of a design/ The mapping from a measurable characteristic to a set of good and unambiguous to a set of good characteristic from a measurable The mapping Figure 4.2 implementation. of transformation. However, the mapping from a quality concept to a set of measur- However, the mapping from a quality of transformation. is much more a case of making an able characteristics measurable characteristic that can be used to assess this complexity is the number of is the number this complexity to assess be used that can characteristic measurable by McCabe’s as measured unit, a program within that exist paths control possible by counting lexical This is derived (McCabe, 1976). Complexity measure Cyclomatic of tokens used being code, with the set in the source as IF and WHILE tokens such language. a particular implementation specific to one is essentially language a particular implementation rules to be used with counting three.) To help with this interpretation, we need a fuller model to help identify the this interpretation, we need a fuller three.) To help with provided in Figure 4.1 is An expanded form of the framework mappings required. has been expanded into three here the idea of a quality concept shown in Figure 4.2: further levels in which: to be glossed over in much of the literature on code metrics! McCabe’s metric is also a in much of the literature on code metrics! to be glossed over value does not necessarily the point made above that a numerical good illustration of an item with a Cyclomatic Few would be likely to argue that imply a ratio scale. of an item with a value of of six was exactly twice the complexity Complexity value SDC04 9/18/07 10:43 AM Page 67 AM Page 10:43 9/18/07 SDC04 relate the requirements-oriented properties of the intended system properties of requirements-oriented relate the determine the quality concepts that are associated with the purpose that are associated the quality concepts determine , 1986; Fenton and Pfleeger, 1997). For design description forms, the , 1986; Fenton and Pfleeger, 1997). et al. identifies the purpose of making measurements (and hence strongly differen- strongly hence (and measurements of making purpose the identifies So the automatic processing of design notations in order to extract measure- So the automatic processing of design Even for program code, which at least possesses well-defined syntax and semantics, Even for program code, which at least When we come to make use of these ideas, we find that the needs of the designer When we come to make use of these In the previous section it was observed that any assessment incorporating the ulti- it was observed that any assessment In the previous section An example of the mappings M1 and M2 from Figure 4.2 is shown in Figure 4.3, mappings M1 and M2 from Figure An example of the (the ‘ilities’) to the solution-oriented properties of the design itself, and these are solution-oriented properties of the (the ‘ilities’) to the a chosen set of metrics. then mapped onto use dynamic measuring design and of a properties static measuring between tiates qualities); behavioural quality factors to as the ‘ilities’); are often referred (these items quality criteria needing careful interpretation of any textual components, remain problems for most needing careful interpretation of any textual components, remain problems notations. ments of particular attributes has not made a very significant impact to date, although ments of particular attributes has not made a very significant impact to date, from sys- a number of experiments have been conducted to extract various counts Budgen tematic design notations (Troy and Zweben, 1981; Hall and Preiser, 1984; tools and Marashi, 1988). The use of CASE (Computer-Aided Software Engineering) code gener- as an aid to documenting designs and, in some cases, assisting with semantics, ation, offers a useful means for gathering such data, but weak syntax and ficult exercise requiring the careful specification of any counting rules to be used ficult exercise requiring the careful (Conte poor syntax of most abstract design nota- problem is compounded by the relatively that are unambiguous, and almost all tions. (There are very few design notations the free-text component to make their purpose graphical forms require careful use of clear.) reasoning at any given stage in the design process, and will avoid descending into detail reasoning at any given stage in the design of this reasoning. However, it is difficult to at too early a stage in the development analysis schemes seek to have available to them measure abstractions, and so metrics as much detail as possible about a design. making measurements of these can be a dif- the process of defining attributes and its domain. For example, efficiency may be of greater importance for an embedded its domain. For example, efficiency for an aircraft autopilot reliability might reason- control system than usability, while factor. ably be regarded as by far the most important unfortunately tend to create forces and the needs of any system of measurement observed in Chapter 2, experienced designers that pull in opposing directions. As was consistent level of abstraction in their will frequently seek to maintain a reasonably and is based on an example of the needs identified as being significant for a real-time example of the needs identified as and is based on an as significant for a compiler. those that are considered system, and, for comparison, and its to recognize the nature of the problem goal of fitness for purpose needed mate we give to the uses, and hence is reflected in the weightings that domain. This balance is strongly related to both the problem itself and the choice of weightings for the ‘ilities’ While this does not reduce the degree of interpretation involved, it does provide a reduce the degree of interpretation While this does not and the forms used. the need for quality assessments clearer path between n n n

68 Design qualities SDC04 9/18/07 10:43 AM Page 68 AM Page 10:43 9/18/07 SDC04 69 Assessing design quality Mapping quality factors to quality criteria. Unfortunately, as Figure 4.3 demonstrates, the factors that the designer considers Unfortunately, as Figure 4.3 demonstrates, the factors that the designer A further problem with metrics analysis procedures is that they have so far been A further problem with metrics analysis to be particularly important may well relate most closely to dynamic attributes, and so to be particularly important may well relate most closely to dynamic attributes, almost entirely concerned with assessing static attributes of a design, since these can almost entirely concerned with assessing static attributes of a design, since form of pro- at least be directly extracted from any forms of notation through some require perty counting. Attempts to extract information about the dynamic attributes (Friel making some behavioural interpretations from the static information provided character- and Budgen, 1997), as well as making assumptions about the performance istics of any eventual implementation. Figure 4.3 SDC04 9/18/07 10:43 AM Page 69 AM Page 10:43 9/18/07 SDC04 Example of musical score notation. The section of a musical score in Figure 4.4 shows that it should be possible to The section of a musical score in Figure section is limited to the group that can be considered as being the most widely applic- section is limited to the group that can be considered as being the most widely able, namely: likely to ‘play’ the score in his or her head in order to assess its qualities!) 4.2.2 The ‘ilities’ making The ‘ilities’ form a group of quality factors that need to be considered when in this any attempt to assess design quality. Since there are many ilities, our discussion specify some form of analysis rules for checking basic properties such as the number of specify some form of analysis rules for rules to check chords and sequences, to identify beats in a bar. We might also devise hence to check for particular dissonances. Given the intervals between the notes and then tell us quite a lot about the piece of music enough musical knowledge, this might test is to hear it played. Only then can we it represents – but of course, the ultimate whether it will be suitable for some particular be sure whether or not we like it, and here, too, as anyone with sufficient knowledge is purpose. (The ‘mental’ model applies with musical notation. Music has some similar properties to software, in that a static with musical notation. Music has some that needs to be ‘executed’, and which therefore notation is used to describe something dynamic attributes. (Again, it is relatively easy to possesses a similar mix of static and and poor quality in music, but very hard to make a broad distinction between good quantify that distinction.) Figure 4.4 when seeking to assess the ultimate criteria assessing the static attributes is insufficient why this is so by using an analogy of fitness for purpose. We can demonstrate

70 Design qualities SDC04 9/18/07 10:43 AM Page 70 AM Page 10:43 9/18/07 SDC04 71 Assessing design quality , in that its behaviour will be as expected, and will be repeatable, regard- , in that its behaviour will be as expected, , in the sense of being able to handle all combinations of events and system able to handle all combinations of , in the sense of being when faced with component failure or some similar conflict (for example, if when faced with component failure or In the early days of computers, when programs were small and computer time was In the early days of computers, when programs were small and computer For safety-critical systems, where this factor is paramount, various techniques For safety-critical systems, where this less of the overall system loading at any time; less of the overall system loading at robust chemical process-control plant fails for some the printer used for logging data in a the whole system, but should be handled reason, this should not be able to ‘hang’ up in the term ‘graceful degradation’). according to the philosophy summed complete states; consistent reliability efficiency maintainability usability relatively expensive, efficiency was considered a prime criterion, and was measured relatively expensive, efficiency was considered a prime criterion, and was implemented chiefly in terms of memory use and processor use. So systems that were The efficiency of a system can be measured through its use of resources such as The efficiency of a system can be measured through its use of resources so on. It is a processor time, memory, network access, system facilities, disk space and more efficient relative and multi-variate concept, in that one system can be identified as is no single than another in terms of some parameter such as processor use, but there scale on which to specify an optimum efficiency. the implementation will be by means of multiple computers, each programmed by a the implementation will be by means independently. Any operational request to the separate development team and tested by all the computers, and only if they con- control system is then processed in parallel cur will the requested operation be performed. Efficiency As systems get larger and more complex, so the problems of ensuring reliability will As systems get larger and more complex, also escalate. limitations in design and implementation tech- have been developed to help overcome in a ‘fly-by-wire’ aircraft, in which the con- niques. For example, in a system used links rather than direct hydraulic controls, trol surfaces are managed by computer n In particular, for the purpose of design we are concerned with ways of determining purpose of design we are concerned In particular, for the system will be: whether the eventual n n (The other ilities, such as testability, portability, reusability and so on are rather more reusability and portability, ilities, such as testability, (The other specialized in purpose.) Reliability characteristics of the eventual concerned with the dynamic This factor is essentially about behavioural issues. the designer in making predictions system, and so involves n n n n SDC04 9/18/07 10:43 AM Page 71 AM Page 10:43 9/18/07 SDC04 framework Cognitive Dimensions (2002) provides a good introduction to the (2002) provides a good introduction , 1987). Some of the factors that affect this in , 1987). Some of the factors that affect et al. et al. A useful review of the issues that need to be considered in designing for ‘ease of A useful review of the issues that need Many of the factors that affect maintainability are related to implementation that affect maintainability are Many of the factors As a design factor, efficiency is a difficult property to handle, since it involves since it involves to handle, is a difficult property factor, efficiency As a design sort of thing that is needed for evaluating quality concepts which are themselves often sort of thing that is needed for evaluating quality concepts which are themselves ill-formed and imprecise. The ‘ilities’ are by no means the only framework that we can employ for thinking The ‘ilities’ are by no means the only framework that we can employ that origin- about system properties within a quality context. A useful set of concepts ated in the field of HCI is provided by Green’s repre- (Green, 1989; Green and Petre, 1996). The focus of this is upon ‘information and the sentation’ (which can of course include the description of a design solution), is just the purpose of the dimensions is to provide a set of ‘discussion tools’, which for the designer to provide the user with a consistent ‘mental model’ of system for the designer to provide the user design choices are fairly specialized and largely behaviour. The techniques affecting the outside the scope of this book. Preece wider aspects of this field of design. 4.2.3 dimensions Cognitive important component, and will influence other design decisions about such features as important component, and will influence module boundaries and data structures. (1984), where the authors observe that the use’ is provided in Branscomb and Thomas since ‘people communicate via, not with, use of the term HCI is perhaps misleading, cognitive element involved in this task, and a need computer systems’. There is a strong ginal ‘mental models’ (Littman in the next section. terms of design structure will be discussed Usability usability, but for many systems the design of the There are many issues that can affect Interaction, or HCI) will form an user interface (usually termed the Human–Computer development and evolution discussed in Chapter 3. development and evolution of these are the choice to very detailed design issues. Examples factors or, at least, standards. How- structuring practices, and documentation of identifiers, comment separation of concerns, the an important factor since, by careful ever, design is also to gain a clear understanding of their ori- designers can help the future maintainers Maintainability this by ensuring a long life- and more costly, the need to offset As systems get larger this, designs must allow for in parallel. To help to achieve time in service increases back to the idea of incremental To some extent, this also relates future modification. in machine code or assembler were generally considered to be highly efficient, but of efficient, be highly to considered generally were or assembler code in machine portability. and maintainability low on rank very would course of choices upon to estimate the effects design in order from the making projections of in terms of considerable importance as these are needs. However, eventual resource to make at least crude is often necessary system, it of the eventual the implementation of needs. predictions

72 Design qualities SDC04 9/18/07 10:43 AM Page 72 AM Page 10:43 9/18/07 SDC04 73 Assessing design quality , process , although obviously the consequences are likely to be product The cognitive dimensions The cognitive Although intended as a ‘measure’ that can be applied to HCI designs, for our Although intended as a ‘measure’ that can be applied to HCI designs, Table 4.1 summarizes the cognitive dimensions and their meanings. (For a fuller Table 4.1 summarizes the cognitive rather different insight into the issue of how As concepts, many of these provide a While the ideas concerned have been couched largely in the terminology of HCI have been couched largely While the ideas concerned ProvisionalityRole-expressiveness a component is readily inferred The purpose of Degree of commitment to actions or marks ViscosityVisibilityCloseness of mappingConsistencyDiffusenessError-pronenessHard mental operationsProgressive evaluation Closeness of representation to domain Resistance to change High demand on cognitive resources easily to view components Ability Similar semantics are expressed in similar syntactic forms time Work-to-date can be checked at any Notation invites mistakes Verbosity of language DimensionAbstractionHidden dependenciesPremature commitmentSecondary notation not visible Important links between entities are on the order of doing things Constraints Interpretation Types and availability of abstraction mechanisms provided via means other than formal syntax Extra information help, as will a design process which recognizes the need to make several iterations help, as will a design process which recognizes the need to make several through the decision-making steps. acteristic. Each set of choices is presented in turn and the user must make a decision acteristic. Each set of choices is presented in turn and the user must make while lacking a full knowledge of what other choices will be available later.) purposes, this concept can provide a ‘measure’ of the quality of the design rather than of the design revisited may exhibited in the latter. A life-cycle which allows design decisions to be This arises when an early design decision which was made before proper information This arises when an early design decision later ones. It may be unavoidable (informa- was available has the effect of constraining timescale), but it may also arise through tion may not be available within a practical such as design methods that encourage a parti- the use of procedural design practices process. (As a simple example, a spoken telephone cular ordering in the decision-making hierarchy of menus, tends to encourage this char- menu system, especially one using a we might think about and assess a design, although clearly not all are directly relevant we might think about and assess a design, how these might help with thinking about design to the current discussion. To explain to consider some small examples that illustrate quality and attributes, it may be useful some of the more relevant dimensions. lookahead) Premature commitment (and enforced offer to the more general process of design. In this section, therefore, we briefly review offer to the more general process of design. and suggest where they may be able to some of the more directly relevant dimensions offer some particularly useful insight. readers should consult the above references and discussion of the complete framework, also the website at http://www.cl.cam.ac.uk/~afb21/CognitiveDimensions/.) and of the more visual aspects of systems, they have nevertheless something useful to and of the more visual aspects of systems, Table 4.1 Table SDC04 9/18/07 10:43 AM Page 73 AM Page 10:43 9/18/07 SDC04 (1987). (This (1999), which et al. et al. ; at the start of the program, is only too typical an illustration of this ; at the start of the program, is only too 17.5 = at various points in the code, rather than declaring a constant value such as at various points in the code, rather Viscosity is a readily recognizable property at many levels of abstraction, even if Viscosity is a readily recognizable property at many levels of abstraction, process. (An interesting illustration of this is provided in Bowman operating analyses the ‘architectural structure’ of the software making up the Linux for the constant. Even worse, since 17.5 might occur within a program for other reasons for the constant. Even worse, since 17.5 might occur within a program for (for example, within 217.53), some values may even get changed in error!) represent it is not one that is easily quantified in design terms. For a design it may exist between the extent to which modules are interdependent, and the differences that the design the ‘conceptual’ form of a solution and the one that actually emerges from cially at the more detailed levels of implementation. (As an example of this dimension cially at the more detailed levels of implementation. we can consider the practice of using embedded within the context of program code, symbolic forms. Using the specific value numerical constants rather than declaring 17.5 VatRate later to adjust the value of the VAT rate, then each practice. When it becomes necessary rather than simply changing the value defined instance has to be located and modified, Viscosity to change’. During design development, this This describes the concept of ‘resistance commitment, and during maintenance it may well arise as a consequence of premature resulting design ‘quality’. Both conventional soft- may be a significant reflection of the that can easily result in high viscosity, espe- ware and websites have many mechanisms in the following chapters but, in brief, a good example of this problem is where desig- in the following chapters but, in brief, when using particular design notations. ners make use of local layout conventions of the design, they may not be so evid- While these may be familiar to the originators to those who later need to maintain the resulting ent to others who join the team, or system. trated particularly effectively in the study reported in Littman effectively in the study reported in trated particularly and their maintenance.) that is particularly relevant for websites dimension is also one Secondary notation information that is conveyed by means other than This dimension describes additional on it briefly here, as we will return to this issue the ‘official syntax’. We will only touch encies that exist between them (A and B share knowledge about certain data types them (A and B share knowledge encies that exist between the designer will need to in thinking about their solution, and structures). However, becomes potentially much relationships. Indeed, the problem consider all of these maintenance: changing a a design is being modified during more significant when has only a part of the neces- be much more difficult if the designer design is likely to to them, a point that is illus- dependencies directly available sary knowledge about Hidden dependencies Hidden is such that while one two components, between describes a relationship This concept From a design stand- not fully visible. the relationship is upon the other dependent addressing later when that we will be of the problems touches upon one point, this (for of dependency capture one type Notations often design notations. examining about other depend- B) but say nothing invokes component that component A example,

74 Design qualities SDC04 9/18/07 10:43 AM Page 74 AM Page 10:43 9/18/07 SDC04 75 Quality attributes of the design product to be able to assess in making their deci- to assess in making to be able like . A number of these, which measure different complexity While simplicity cannot easily be assessed, one can at least seek measures for its While simplicity cannot easily be assessed, one can at least seek measures The often-quoted saying ‘a solution should be as simple as possible, but no The often-quoted saying ‘a solution The cognitive dimensions offer some interesting ideas to employ in thinking about ideas to employ some interesting dimensions offer The cognitive forms of design document. to identify a set of design attributes that are related to these properties; design attributes that are related to to identify a set of about these attributes from the available to find ways of extracting information converse characteristic of forms of complexity, have been developed for use with software, including: seem at first. This is the opposite of the argument against unnecessary embellishment: that will it argues against attempting to oversimplify, since the result will be a product abstraction, not be able to do its job. One important aid to achieving simplification is if it is to but it is necessary to use an abstraction that preserves the relevant attributes be of any help in solving the problem. dual-purpose artifacts fail to achieve either of their objectives clearly and well. One dual-purpose artifacts fail to achieve that expanded to become a tent, but was example that comes to mind is a rucksack convenient to have a good rucksack and a unsuccessful because it was much more us can probably think of similar examples of mis- good tent as separate items. Most of placed ingenuity.) to Albert Einstein, is more profound than it might simpler’, which is usually attributed 4.3.1 attributes Some design Simplicity in whatever sphere of activity they are Characteristic of almost all good designs, design meets its objectives and has no addi- produced, is a basic simplicity. A good its main purpose. (Perhaps this is why so many tional embellishments that detract from In the first part of this section some of the attributes and criteria that are widely used In the first part of this section some and this is followed by a brief discussion of one of for design assessment are described, the ways in which these might be extracted. Now that a number of ideas about design quality concepts have been examined, it is of ideas about design quality concepts Now that a number for measurement are: principal problems that they present clear that the two n n to us at the design stage. We can then consider how well these are able to provide help stage. We can then consider how well to us at the design that have been described extent to which a design meets the factors with assessing the above. 4.3 product design Quality attributes of the system. The results of this study undoubtedly provide illustrations of several of the of the of several illustrations provide undoubtedly this study of The results system. dimensions!) cognitive later to make We will be returning mean for software. and what it can design quality of examined some However, having that they embody. of some of the ideas further use would factors that designers the quality have available of quality we actually what measures now go on to consider sions, we SDC04 9/18/07 10:43 AM Page 75 AM Page 10:43 9/18/07 SDC04 , 1990; Shepperd and Ince, 1993); and Ince, , 1990; Shepperd . Simply defining interfaces is not enough: a designer . Simply defining interfaces is not enough: et al. , 2000). et al. separation of concerns (1999) for an illustration of this). (1999) for an illustration Viewed generally, and also from a software perspective, finding a suitable scheme Viewed generally, and also from a software perspective, finding a suitable To make good use of a modular structure, one needs to adopt a design practice To make good use of a modular structure, This is generally only possible where a well-defined set of interface standards is in This is generally only possible where In terms of the design quality concepts, simplicity is clearly related to maintain- In terms of the design quality concepts, and operators (Halstead, 1977); and operators system elements (prim- in terms of relationships between complexity of structure in Chidamber and Kemerer forms), with the measures proposed arily object-oriented means the only candidates widely cited, although by no (1994) being particularly (Briand complexity of control flow (McCabe, 1976), concerned with the number of pos- of the number with concerned 1976), flow (McCabe, control of complexity unit; a program of execution control during paths of sible system (Henry and flow around the of information of structure in terms complexity Kitchenham Kafura, 1984; different identifiers the number of as measured by of comprehension, complexity benefits: needs to group functions within modules in such a way that their interdependence is needs to group functions within modules in such a way that their interdependence in the minimized. Such a grouping results in a less complex interface to the module: for soft- case of hardware, it may simply be that fewer interconnections are required; ware, we need to find other criteria in order to measure this factor. following of modularity to apply in solving a given problem provides at least the ‘backplane’ providing a data highway, together with the necessary signal lines. While ‘backplane’ providing a data highway, possible with software (as is evident from the this form of module connectivity is also the standardization of the interfaces involved is existence of libraries of subprograms), the concept of the software component is much more limited. Despite this, however, this more fully in Chapter 17. an important one, and we will review based on a lished in other forms of engineering. In electronics in particular, the idea of replacing lished in other forms of engineering. one and plugging in the other has made one unit with another simply by unplugging and electronic equipment into a relatively the maintenance and upgrading of electrical straightforward task. this is generally achieved with some form of existence. For electronic components Modularity structuring makes it possible for a given The use of an appropriate form of modular a set of smaller components. Once again, modu- problem to be considered in terms of to software: this principle has long been estab- larity is not a concept that relates only Unfortunately only the last of these readily scales up for use in design, although all the last of these readily scales up Unfortunately only forms. There are no ready to detailed design documentation could possibly be applied architectural complexity of currently be used to help assess the measures that can tools can help – see Bowman for object-oriented forms (although a design other than et al. and possibly efficiency. ability and testability as well as reliability n n n n

76 Design qualities SDC04 9/18/07 10:43 AM Page 76 AM Page 10:43 9/18/07 SDC04 77 Quality attributes of the design product Desirability High Moderate Necessary Undesirable Undesirable , 1974; Yourdon and Constantine, , 1974; Yourdon and et al. as by means of a procedure call A passes a parameter to B that is used in B to ‘flag’) determine the actions of B (typically a boolean A and B contain references to some shared data area that incorporate knowledge about its structure and organization. Any change to the format of the block requires that all of the modules using it must also be modified Features or Modules A and B communicate by parameters data items that have no control element data Modules A and B make use of some common type (although they might perform very different functions and have no other connections) such A transfers control to B in a structured manner is a measure of intermodule connectivity, and is concerned with identi- connectivity, and is concerned is a measure of intermodule Forms of module coupling. In general, the forms of coupling listed are somewhat biased towards modules In general, the forms of coupling listed Coupling Two useful quality measures that have long been used for the purpose of assessing measures that have long been used Two useful quality : The forms of coupling that can exist between modules A and B have been ranked in decreasing modules are easy to replace; are easy modules (and so aiding comprehension feature of a problem, captures one each module as a team; for designing as providing a framework as well hence maintenance), for another problem. easily be reused module can a well-structured Common-environment coupling Control coupling (i) Activating (ii) Coordinating Form Data coupling Stamp coupling connections. Table 4.2 summarizes the principal forms of coupling that are generally connections. Table 4.2 summarizes of design features. regarded as being significant in terms rather than on such forms as the class. The based on the procedure, or subprogram, to the different ways of invoking procedures, measures of coupling are generally related and were used to identify the complexity of a system in terms of the form and inter- identify the complexity of a system and were used to the basic unit of modular- component modules. In the original work, dependence of the are still valid for such be the subprogram unit, but the concepts ity was assumed to and the Java ‘class’. the Ada ‘package’, the Modula-2 ‘module’ modular forms as between modules and the ‘strength’ of these fying the forms of connection that exist 1979), based upon observations of the problems arising when developing large systems, observations of the problems arising 1979), based upon order of desirability. Note Table 4.2 larity should be related to such quality concepts as maintainability, testability and to such quality concepts as larity should be related and reliability too. (possibly) to usability and ‘cohesion’. These structuring in software are ‘coupling’ the extent of modular in the early 1970s (Stevens terms were defined n n n use of modu- are seeking, the successful that we of the design properties So in terms SDC04 9/18/07 10:43 AM Page 77 AM Page 10:43 9/18/07 SDC04 is rarely extent ., 1974) and was added later in Yourdon and , rather than procedural ones, such as the sub- et al class during design, and determining their during design, and presence is the basis of modular structuring, an example of functional is the basis of modular structuring, , is that our ideas about the ranking order of the more desirable class , turn, provides a measure of the extent to which the components in its method Table 4.3 lists the main forms of cohesion (sometimes termed ‘associations’) that Table 4.3 lists the main forms of cohesion Cohesion This form of coupling is therefore likely to arise from a failure to perform the This form of coupling is therefore This form typically arises when one of the parameters of a procedure is used to arises when one of the parameters This form typically As an example of the point about the extent of coupling being less critical in design point about the extent of coupling As an example of the A problem with the basic concepts involved in coupling and cohesion is the in coupling and concepts involved with the basic A problem forms may then need some revision. (The overall distinction between desirable and forms may then need some revision. (The overall distinction between now consider undesirable is unaltered though.) The main issue is whether we should to this is procedural association, which is very much concerned with sequencing of to this is procedural association, which is very much concerned with sequencing form was not operations, and hence fits less easily with the packaging concept. (This included in the original list (Stevens within a con- Constantine (1979).) However, one consequence of re-interpreting these text of packaging units such as the program or relatedness might be a stack class that contains only a set of public methods for access- relatedness might be a stack class that structure for the stack itself. Such a class can be ing the stack, together with the data cohesion, since all its components are present considered as exhibiting functional stack facility. solely for the purpose of providing a cohesion is quite easily related to packaging are generally recognized. As can be seen, to procedural units. Perhaps the main exception forms of modular structure, as well as therefore to identify its presence. Any notion of its ‘extent’ is harder to determine, and therefore to identify its presence. Any of doubtful value if achieved. ‘functionally related’. The ideal module is one in of a module can be considered to be as being solely present for one purpose. which all the components can be considered Where the Java ing routine to indicate which variant of the task needs to be performed. In other words, ing routine to indicate which variant classic example of a situation in which this may it acts as a ‘fix’ for a design error! (A program, such as an assembler, compiler or occur is in writing any form of multi-pass of fairly low-level tasks that need to be repeated, link-editor. These all have a number differ slightly on each pass.) but which on inspection are seen to any form of design assessment the need is detailed design tasks adequately. In making ordinating control coupling, sometimes termed ‘switch coupling’. coupling, sometimes termed ‘switch ordinating control task. This in turn may arise that the procedure is to perform its determine the way sections of a program, and is invoked from a number of different where a procedure task it performs may differ late stage, it may be realized that the where, at a fairly parameter is then added to enable the invok- slightly according to section. The ‘switch’ scope to identify their scope to identify their of performing such oper- coupling, there is at least the possibility practicable. With exchanged and so on, but even links, using sizes of data structures ations as counting such measures is somewhat limited. then the value of any can consider the case of co- presence of particular forms, we assessment than the and to the use of different parameter-passing mechanisms. However, the concept can the concept However, mechanisms. parameter-passing of different the use and to of the packaging with concerned 1979), (Parnas, hierarchy to the ‘uses’ be applied also of at a number making design decisions used as a guide in and so can be information, levels of abstraction. different this is less of an issue However, measures systematically. of quantifying these difficulty there is only really structures, since for assessing program process than for the design

78 Design qualities SDC04 9/18/07 10:43 AM Page 78 AM Page 10:43 9/18/07 SDC04 79 Quality attributes of the design product Definitely not Desirability High Quite high Fairly Not very Not very Definitely not association since it sequential mechanism. The point is relatively minor, class The elements of the module are related by the order in which The elements of the module their operations must occur that are related by the time at The elements involve operations being linked to some event such as which they occur, usually ‘system initialization’ that are logically similar, but The elements perform operations actions internally which involve very different by any conceptual link (such The elements are not linked coding tasks) modules may be created to avoid having to repeat Features of a single problem- contribute to the execution All the elements related task to module form the inputs from one element of the The outputs another element with operations that use the same All elements are concerned input or output data association to be ranked higher than association to be ranked higher than The principal forms of cohesion. forms The principal Where this principle is applied, knowledge about the detailed form of any data Where this principle is applied, knowledge about the detailed form of While almost any general textbook on software engineering will contain a discus- While almost any general textbook on Cohesion is probably even more difficult to quantify than coupling; however, it Cohesion is probably even more difficult Logical Coincidental Communicational Procedural Temporal Form Functional Sequential communicational Table 4.3 Table structures within a module is kept concealed from any other software components that structures within a module is kept concealed from any other software components be provided may use the module. In many cases, a number of ‘access procedures’ may designer to keep information about the detailed forms of such objects as data struc- designer to keep information about the detailed forms of such objects as informa- tures and device interfaces local to a module, or unit, and to ensure that such like the tion should not be made ‘visible’ outside that unit (Parnas, 1972). Again, (Parnas, preceding concepts, it was first recognized through a process of observation 1999). ‘structured design’ school of textbooks. Probably two of the most thorough ones are ‘structured design’ school of textbooks. (1979) and Page-Jones (1988). those provided in Yourdon and Constantine Information-hiding modularity, but it also incorporates additional This concept is related to that of in a system. The basic concept encourages the notions about managing information does provide a measure that can be used to help the designer with assessing the relat- does provide a measure that can be of finding ways of measuring its presence ive merits of possible options. The challenge therefore been one of considerable interest to in an acceptably objective way has 1998). metrics researchers (Bieman and Kang, detailed discussions are usually to be found in the sion of coupling and cohesion, more more fully exploits the facilities of the more fully exploits the facilities of the about quality may change with the evolution of but it does illustrate how our ideas implementational forms. SDC04 9/18/07 10:43 AM Page 79 AM Page 10:43 9/18/07 SDC04 ‘Scope wall’ prevents ‘Scope wall’ any direct references to the being made the data elements in contains structure that the stack. 10 55 101 stack integer pop():integer); push(x:integer); Example of information-hiding used with a module that provides an integer stack. used with a module that provides Example of information-hiding The detailed forms in which these attributes manifest themselves in software sys- The detailed forms in which these attributes manifest themselves in software Powerful though the concept is, it is difficult to make use of it in any procedural Powerful though the concept is, it is This interface then conceals the detailed design decisions about how the stack is to This interface then conceals the detailed As an example, this principle might be used in designing a module to provide an As an example, this principle might push an integer onto the stack pop an integer from the stack test for an empty stack Procedures (methods) provide the means of using the stack, but convey no details about how it is organized. expected to make it difficult to read and understand the designer’s intentions and to expected to make it difficult to read and understand the designer’s intentions make the resulting system difficult to modify. tems are somewhat elusive, although the concepts involved are generally quite tract- tems are somewhat elusive, although the concepts involved are generally is to examine able. A useful aid to considering the extent of their presence in a design This it for signs of those features that indicate that a design may lack these qualities. that are the involves identifying a suitable set of features corresponding to attributes can be inverse of those mentioned above. The presence of any of these features stack. to devise a set of tests to identify its use. In practices for design, and equally difficult clearly related to both reliability and maintain- terms of system quality factors it is memory use, it is apt to conflict with ideas of ability. In terms of processor time and of a hierarchy of access procedures may lead to efficiency on occasion, since the use reduced run-time performance. as is shown schematically in Figure 4.5. its integrity by preventing ‘short-cut’ access be implemented, which helps to ensure also makes it possible to change the detailed form directly from other program units. It changes in any of the units that make use of this of implementation without requiring integer stack facility to support a set of reverse Polish calculations using integers. Using integer stack facility to support a set one would seek to conceal the form adopted for the principle of information-hiding, a set of procedures for accessing it, such as: implementing the stack, and provide to give controlled forms of access to the ‘clients’ of the module. The effect is to provide of access to the ‘clients’ of the to give controlled forms to it. information, preventing direct access a ‘scope wall’ around Figure 4.5

80 Design qualities SDC04 9/18/07 10:43 AM Page 80 AM Page 10:43 9/18/07 SDC04 81 Quality attributes of the design product , which is concerned with issues such as project , which is concerned with issues such , which is concerned with assessing the quality of a , which is concerned with assessing the technical review management review While a design review cannot provide any well-quantified measures of ‘quality’ (if While a design review cannot provide any well-quantified measures of ‘quality’ Technical reviews can include the use of forms of ‘mental execution’ of the design Technical reviews can include the use Identifying attributes that are the direct inverses of those described above is a above described of those inverses direct are the that attributes Identifying well focused in terms of their purpose, and may well be parametrized for use on dif- well focused in terms of their purpose, ferent tasks. ules where the designer has chosen unsuitable interfaces and data structures. has chosen unsuitable interfaces ules where the designer in module interfaces: of information. This can also be reflected Needless replication a parameter, when only one may pass a complete record as for example, procedures is relevant to their operation. field of the record strength’. Program units of this type are not Using modules that lack ‘functional Using interfaces that are too complex. In programming terms these are usually are too complex. In programming Using interfaces that some of which may that have too many parameters, characterized by procedures likely to be identified by the In design terms, they are more not even be necessary. flow associated with them. degree of information may indicate design mod- complex control structures. This The use of excessively Having many copies of ‘state’ information spread around the system. This com- around the information spread copies of ‘state’ Having many in system lead to inconsistencies and may updating of information, plicates the behaviour. been assembled from experience (Yourdon, 1979; Weinberg and Freedman, 1984; been assembled from experience (Yourdon, a technique, though, it is essential to distin- Parnas and Weiss, 1987). In using such guish between the design, and the 4.3.2 quality design Assessing useful in assessing design structure and likely A technique that has proved itself (also sometimes termed an inspection). The behaviour is the review, or walkthrough well established, and a set of basic rules has use of reviews for this purpose is quite These characteristics have been expressed largely in terms of implementation features, These characteristics have been expressed are more readily quantified. However, they can since these are more familiar and although extracting the information is equally well be assessed for design descriptions, of automatic analysis (Rising and Callis, 1994). less easily achieved through any form n n n n significant problem. However, the following undesirable characteristics of a design can of a design characteristics undesirable following the However, problem. significant inverse properties. the presence of the to stem from be considered n such a thing is even possible), it can help to identify weaknesses in a design, or poten- such a thing is even possible), it can help to identify weaknesses in a design, a means tial weaknesses that might arise as details are elaborated. It therefore provides model, and so can help with assessing dynamic attributes as well as static ones. The model, and so can help with assessing dynamic attributes as well as static need to references cited above provide some valuable guidelines on how such reviews that are be conducted in order to meet their aims and not to become diverted to issues that the re- more properly the province of the management review. It is also essential design itself. view does not become an assessment of the design team, rather than of the deadlines and schedule. This section and the next are concerned only with the role per- deadlines and schedule. This section review. formed by the first of these forms of SDC04 9/18/07 10:43 AM Page 81 AM Page 10:43 9/18/07 SDC04 reviews is design inspections does not necessarily support inspections does not code This section ends with a summary of those properties of a design that Parnas and a summary of those properties This section ends with for a good design are that it should be: The eight requirements that they identify Reviews and inspections have undoubtedly proved to be a successful mechanism, have undoubtedly proved to Reviews and inspections standardized: using well-defined and familiar notation for any documentation. standardized: using well-defined and flexible: able to accommodate likely changes in the requirements, however these flexible: able to accommodate likely might arise; the required facilities, neither more nor practical: module interfaces should provide less; software and hardware technology; implementable: using current and available well structured: consistent with chosen properties such as information-hiding; well structured: consistent with chosen as possible, but no simpler’; simple: to the extent of being ‘as simple be computed using the available resources; efficient: providing functions that can adequate: meeting the stated requirements; design process is obviously an important factor that needs to be considered when seek- design process is obviously an important factor that needs to be considered ing to understand design quality issues. 4.4 process the design Assessing struc- Any design product emerges as a result of some form of design process, however process can tured or unstructured this might be. So while no degree of quality in the of the actually ensure some particular degree of quality in the product, the quality n significance in the context of a review, since the The last point obviously has special comprehend the ‘mental models’ developed by reviewers must be able to capture and this much harder if the notation used is unfamil- the designers. They are likely to find iar and itself undocumented. n n n n n n n unclear, but certainly the size of these is an issue to consider with care. the size of these is an issue to consider unclear, but certainly hence should be studied in a should be the designer’s goals and Weiss (1987) believe we have met already in this Most of them are properties that technical design review. repeating at this point. book, but they bear although as Glass (1999) paraphrases rather neatly: ‘inspection is a very bad form of (1999) paraphrases rather neatly: ‘inspection although as Glass However, as Glass has also all the others are much worse’. error removal – but of research on observed, an examination of meetings with more than review meetings, and certainly not the use of ‘traditional’ apply to Whether the same conditions two or three participants. of answering the second question posed at the start of this section: ‘How can informa- can ‘How of this section: the start posed at question second the of answering state the present In documents?’ design from be extracted attributes about these tion of both extract- offers the best means review probably the technical design of the art, In particular, if care- quality of a design. relating to the information ing and assessing have both the domain those people who it brings together and organized, fully planned realistic projections is needed to make knowledge that and the technical knowledge available design information. from the

82 Design qualities SDC04 9/18/07 10:43 AM Page 82 AM Page 10:43 9/18/07 SDC04 83 Assessing the design process Managing the , and occasionally even , and occasionally ad hoc (Humphrey, 1991), Watts Humphrey has drawn together a valuable Watts Humphrey has drawn together (Humphrey, 1991), . Continuous process improvement is enabled by quantitative feedback . Continuous process improvement is . Basic project management processes are established and used to track . Basic project management processes . Detailed measures of the software process and product quality are col- . Detailed measures of the software . The software process for both management and engineering activities . The software process for both management . The software process is characterized as . The software process To improve the quality of the design process it is particularly necessary to find To improve the quality of the design process it is particularly necessary The material of the preceding sections and chapters will have made it clear why The material of the preceding sections Experience seems to suggest that this is so, and that even for the more quantifi- to suggest that this is so, and that even Experience seems Our study of the nature of the design process so far has shown that it typically that far has shown so design process of the the nature study of Our experience from similar projects, wherever available. domain knowledge about the type of problem involved, and about important domain knowledge about the type of problem involved, and about aspects of any implementation features; used; method knowledge that helps with understanding any design techniques being Managed the products are quantitatively understood lected. Both the software process and and controlled using detailed measures. Optimizing ideas and technologies. from the process and from testing innovative cost, schedule and functionality. The necessary process discipline is in place to cost, schedule and functionality. The similar applications. repeat earlier successes on projects with Defined into an organization-wide software is documented, standardized and integrated and approved version of the organization’s process. All projects use a documented software. process for developing and maintaining Initial depends upon individ- are defined, and success in a project chaotic. Few processes ual effort. Repeatable n ways of including input to design activities that can provide: n n the design solution developed for a system will be much more strongly problem- the design solution developed for that might be adopted for coding, or the oriented than (say) the structuring practices This is most certainly not an argument against testing strategies that might be used. the design process, but it does indicate why, seeking to find quality measures for by the overall development process, it is regardless of the levels that may be achieved the point of being repeatable. hard to get the design phase even to n n n occur in the processes that an organization uses for producing software systems. that an organization uses for producing occur in the processes n n able tasks involved in software development, such as coding and testing, the existing in software development, such as able tasks involved In his book and of quality are rather limited. measures of productivity Software Process processes. In particular, issues applied to software development survey of quality five levels of maturity that Process Maturity Model’, he identifies within his ‘Software involves the designer in building a ‘model’ of the end system, and then exploring ways exploring and then system, of the end a ‘model’ building in the designer involves opportunistic design also seen that 1970). We have that model (Jones, of realizing even where struc- and Hoc, 1990), for these tasks (Visser are widely used techniques that the creative reasonably expect in use. So we might practices are also tured design not readily lend itself development does of software this phase in the process nature of quality. measures of to any rigorous SDC04 9/18/07 10:43 AM Page 83 AM Page 10:43 9/18/07 SDC04 the means of gaining both domain knowledge and some both domain knowledge and the means of gaining are primarily concerned with developing and refining estim- are primarily concerned quality in either the design product or the design process, it quality in either the design product were outlined in the previous section; their use allows the design section; their use in the previous were outlined ensure Once again the quality of design documentation (and in larger projects the quality Once again the quality of design documentation for design, and of specific forms of design While the use of standard notations Of these three, it is the management review that is most likely to involve making Of these three, it is the management Prototyping provides context, prototyping may about a particular problem. (In this forms of experience ‘exploratory’ or ‘experi- what Floyd (1984) has termed the be considered to play therefore be possible to suitable prototypes, it may mental’ role.) By constructing available to both management and the supplement the knowledge and experience design team. might be applicable to a particular problem. might be applicable Management reviews with gathering any data for the project as a whole, and ates of effort and deadlines is one that draws for such estimates. The task of estimation that might be needed since it requires the use of domain knowledge and experience, heavily upon both projections needed. these to make the Technical reviews Technical from any of others, and particularly the experiences knowledge from team to gain this form of input possess. While that they might method knowledge domain and have a significant it can also the design product, aimed at improving is largely or notations that useful techniques by identifying the design process impact upon While the use of abstraction is an important tool for the designer, it makes it difficult to make While the use of abstraction is an important tool for the designer, it makes it difficult any direct product measurements during the design process. Software quality concepts are concerned with assessing both the static structure and the Software quality concepts are concerned with assessing both the static structure dynamic behaviour of the eventual system. for deter- The ultimate goal of quality must be that of fitness for purpose, although the criteria mining whether this is achieved will be both problem-dependent and domain-dependent. Summary n n n the more technical issues affecting software design. the more technical issues affecting software the following points are particularly significant. In examining ideas about ‘good’ design, of any configuration and control procedures used for organizing this documentation) of any configuration and control procedures a high-quality process by reusing experience. plays an important role in establishing practice, cannot is likely to be highly influential. We are therefore should be clear by now that their use to begin examining their roles in terms of now in a good position, in the next chapter, some form of assessment of the way that a design is being developed, and which may some form of assessment of the way two forms. The use of reporting and tracking provide a framework for using the other role in monitoring quality issues, and with ensur- mechanisms will play an important during a review. ing that these issues are actually addressed 3. 2. There are three widely adopted ways of providing these inputs to the design process. design to the these inputs ways of providing adopted widely are three There 1.

84 Design qualities SDC04 9/18/07 10:43 AM Page 84 AM Page 10:43 9/18/07 SDC04 85 Exercises in terms J. Systems efficiency consider how you Addison-Wesley reliability, usability, maintainability, reusability, reliability, usability, maintainability, reusability, Managing the Software Process. Managing the Software , 259–65 7 , sells electrical goods. preted and applied. Do they help with identifying any changes that would be desirable? and system facilities (such as windows). Consider how you would measure and system facilities (such as windows). Consider two programs that you have written most recently. of these and identify your priorities for the that might help to ensure that these are met. organization and suggest some basic rules would rank them in order of importance for each of the following systems: would rank them in order of importance for (a) a process control system for a chemical plant that produces toxic insecticides; (b) accounts; a bank autoteller network used to issue cash and short statements describing (c) at each branch of a chain of stores that an interactive database used for stock control Technical design reviews can provide a valuable means of obtaining and using domain know- domain and using obtaining means of a valuable can provide reviews design Technical to aid with well as method knowledge design product as with assessing the ledge to aid the design process. assessing tutorial. Posted at www.cl.cam.ac.uk/~afb21/CognitiveDimensions & Software Exercises Further reading 4.4 simple) website, consider how the ideas in Table 4.2 would need to be inter- For a (relatively 4.3 planning a design review in your own List the criteria that you would expect to be used in 4.2 processor time, memory, devices A computer program uses a number of resources, including dimensions, supported by some illuminating illustrations. dimensions, supported by some illuminating 4.1 Given the four ‘ilities’ One of the very few books to examine the context within which software is produced, and to books to examine the context within which One of the very few development process. study the nature of the of Information Artefacts: a A.F. (1998). Cognitive Dimensions Green T.R.G. and Blackwell survey of the concepts involved in cognitive A tutorial document that provides a comprehensive Parnas D.L. and Weiss D.M. (1987). Active design reviews: Principles and practices. D.M. (1987). Active design reviews: Parnas D.L. and Weiss process and identifies (from experi- on the use of reviews in the design A short paper that focuses as possible. with making design reviews as effective ence) some rules to assist Humphrey W.S. (1989). n SDC04 9/18/07 10:43 AM Page 85 AM Page 10:43 9/18/07 SDC04 SDC04 9/18/07 10:43 AM Page 86 SDC05 9/18/07 10:45 AM Page 87

part 2 Transferring Design Knowledge

Chapter 5 Describing a Design Solution 89

Chapter 6 Transferring Design Knowledge 105

Chapter 7 Some Design Representations 127

Chapter 8 The Rationale for Method 175

Chapter 9 Design Processes and Design Strategies 193

Chapter 10 Design Patterns 213 SDC05 9/18/07 10:45 AM Page 88 SDC05 9/18/07 10:45 AM Page 89

chapter 5 89 Describing a Design Solution

5.1 Representing abstract ideas 5.3 Forms of notation 5.2 Design viewpoints for software

Much of the discussion of the book has so far concentrated on examining the actions that are involved in the process of design, and the con- straints that affect these. The preceding chapter began to consider the attributes possessed by the particular design medium of software; now this chapter starts to examine some of the ways in which these different attributes can be described and modelled by the designer. notations to provide visual box and line is used to provide a particular abstraction of the characteristics is used to provide representation Software designers similarly use a range of levels of abstraction, although the Software designers similarly use a Representations can also be employed across a wide range of levels of abstraction. Representations can also be employed A explaining the designer’s ideas to others (such as customers, fellow designers, ideas to others (such as customers, explaining the designer’s implementors, managers); and completeness in a solution. checking for consistency capturing the designer’s ideas for a solution; capturing the designer’s chapters. * by the use of abstract notations, as we will see in later Of course, the design process can itself be represented between representation and implementation. We will examine this further in Section between representation and implementation. We will examine this further tend to 5.3. For the moment, we should simply note that software design techniques make extensive use of various forms of descriptions that are intended to represent the various properties of software. ‘white box’ description, it is still an abstraction from the final physical realization of ‘white box’ description, it is still an will be used in the circuits. the cables, switches and sockets which a particular problem in terms of how to describe invisible nature of software provides representation used in Figure 5.1 is fairly self- the properties involved. Whereas the 5.2 has a fairly distinct link to the physical explanatory, and even that used in Figure for software does create a conceptual gap realization, the lack of any ‘visual’ properties For example, in Figure 5.1 we provide a ‘sketch’ of a building, which might be con- For example, in Figure 5.1 we provide a ‘black box’ description, providing only a (par- sidered to provide a good example of of the building. Figure 5.2 provides a very tial) description of the external appearance property of the same building, in the form of a different representation of a specific electrical circuitry. While this is clearly a description of a small part of the internal attention upon the issue that is most important to them at any particular stage of attention upon the issue that is most aids the designer by providing a mechanism for the design process.* In particular, it overload’. Indeed, as Vessey and Conger (1994) reducing the problem of ‘information resort to various ways of effectively increasing have observed: ‘human problem-solvers as well as using external memory devices and/or the capacity of short-term memory In this context, therefore, a representation techniques to support working memory’. an ‘external memory device’. can also be considered as providing n n can help the designer to concentrate his or her A representation, whatever its form, the various relationships that will exist between these. While this is a general design these. While this will exist between relationships that the various nature of software adds specific to software design, the ‘invisible’ requirement, and not its own. some problems of as: typically needed for such purposes of a system, and is n 5.1 ideas abstract Representing allowing the designer design process, by role in the performs an essential Abstraction are the most import- or its solution that of a problem on those features to concentrate the designer of the design. Therefore in the development particular stage ant at any objects, and about problem and design ideas about to represent abstract needs ways

90 Describing a design solution SDC05 9/18/07 10:45 AM Page 90 AM Page 10:45 9/18/07 SDC05 91 Representing abstract ideas Example of a ‘physical’ description of a building. Example of a ‘physical’ Example of a part-description of the electrical distribution for the building. Example of a part-description of the electrical However, this should not constrain one’s thinking about how design represen- However, this should not constrain one’s thinking about how design Historically, a major use for representations has been to provide support for par- Historically, a major use for representations Figure 5.1 to describe their ideas. Representations can be associated with problem models and to describe their ideas. Representations can be associated with problem process. solution (program) forms, quite independently of any particular form of design representations to form the inputs and outputs for the various transformations it uses. representations to form the inputs and outputs for the various transformations can any form tations should be used. Although design methods use representations, so not. Indeed, of design activity, whether it be graced with the name of a ‘method’ or defined it is likely that most software is designed without the use of a particular ‘method’, but that is not to imply that designers do not use any form of representation Figure 5.2 design method makes use of a particular set of ticular steps in a design method: each SDC05 9/18/07 10:45 AM Page 91 AM Page 10:45 9/18/07 SDC05 . Many of us are familiar with the type of . Many of us are familiar viewpoint The four principal viewpoints as projections from the design model. We should note here that the use of the term ‘viewpoint’ in this book does differ We should note here that the use of The notion of a viewpoint puts a particular emphasis upon the role of a repre- The notion of a viewpoint puts a particular Because representations provide particular abstractions of a system, they are provide particular abstractions Because representations Nor should the association between methods and representations be regarded as regarded be representations and methods between association should the Nor Figure 5.3 1992). (There may, of course, be more than one representation that can be used to 1992). (There may, of course, be more to a particular viewpoint, a point that will be describe the properties corresponding examined further later in this chapter.) to be used in requirements engineering, where the somewhat from the way that it is apt sentation. A representation is the means that we use to capture certain properties of a sentation. A representation is the means as being the design itself. This concept of the design, and it should not be regarded model is illustrated in Figure 5.3. When using this viewpoint as a projection of a design the different viewpoints as encompassing parti- conceptual framework, we can regard model, and the representations are then the means cular sets of properties of the design attributes or characteristics (Brough, that are used to describe the corresponding drawing can be considered as describing the ‘physical’ appearance of the object. as describing the ‘physical’ drawing can be considered will also provide an abstract in Figure 5.2, the wiring plan However, as demonstrated different from the physical building, although it may look very representation of the ways, they need to be kept con- are very different in many plan. While these viewpoints through references to common attributes of sistent at the points where they ‘intersect’ design objects. reason the discussions of representations and methods have been separated in this of representations and methods reason the discussions representations can be power of abstraction provided by different book, so that the than that of a particular method. seen in a wider context concept of a closely linked to the other physical objects. Such a is used for describing buildings and plan drawing that particularly rigid, so that the adoption of a method precludes in some way the use of some way the use precludes in adoption of a method rigid, so that the particularly is to of design with it. The objective normally associated that is not any representation this (To some extent in its use of a form! correct’ not to be ‘politically solve problems, of consequence is a natural enough representation forms of method with association considering particu- the designer into the method guides method, since using a design that these.) For notations to support so into using specific in sequence, and lar issues

92 Describing a design solution SDC05 9/18/07 10:45 AM Page 92 AM Page 10:45 9/18/07 SDC05 93 Representing abstract ideas , 1992). So, , 1992). et al. of the model. Conceptually the two are not very different, in the two are not Conceptually of the model. of the properties of the model outwards to the users, its use in outwards to the of the model of the properties Examples of representations as realizations of viewpoints. perceptions projections The next section examines more closely the ways in which these concepts can be The next section examines more closely Of course, these projections need to be kept consistent with one another, in order Of course, these projections need to Returning for a moment to the description of a building that was used in the earl- to the description of a building Returning for a moment a wiring diagram captures the attributes that are concerned with the logical organ- the attributes that are concerned a wiring diagram captures of electrical power and its control. ization of the distribution ‘plan’ diagrams capture the attributes that are concerned with spatial dimensions, the attributes that are concerned ‘plan’ diagrams capture like; accessibility, and the can only check for consistency between forms, and so cannot use the model itself to can only check for consistency between in any absolute sense. check that the representations are ‘correct’ In particular, it considers the principal features used in the domain of software design. to maintain a consistent design model. Since each representation describes a set of to maintain a consistent design model. some intersection between the different sets of design properties, there is frequently of checking for consistency between the corres- properties, and hence some means 5.5 shows this concept in a symbolic manner. ponding forms of representation. Figure is captured only through the representations, we Unfortunately, since the design model n (mental) design model for particular projections of the architect’s However, both are means that the architect can such representations are the only real the building. Indeed, to others. Even so, the representations are not the use to convey ideas about the design from it, as is illustrated in Figure 5.4. design model, they are only projections n term is used to describe ‘stakeholder’ views of the model (Finkelstein model (Finkelstein of the views ‘stakeholder’ describe is used to term ier example, we can now see that: ier example, we can whereas its use in this book is much more focused upon the model-centred idea of idea of the model-centred upon focused much more book is in this its use whereas providing with the users’ being concerned much more inward-facing, context is the requirements particular but and the model, between the user the interface are concerned with that both begins from the user. model, the other begins from the whereas one Figure 5.4 SDC05 9/18/07 10:45 AM Page 93 AM Page 10:45 9/18/07 SDC05 design needs, which are often con- properties, the designer usually needs forms properties, the designer usually needs solution-oriented system-oriented Intersecting attributes for different representations. The nature of software and the many paradigms that exist for developing software The nature of software and the many paradigms that exist for developing In order to describe design representations (Webster, 1988; Harel, 1992; Wieringa, 1998). These can be design representations (Webster, 1988; Harel, 1992; Wieringa, 1998). broadly classified as follows: operations. For more detailed hierarchy, cerned with describing ‘constructional’ issues such as packaging, procedure attributes. and data organization, the chosen forms will generally focus on static design This change of emphasis during design is illustrated in Figure 5.6. number of systems, based on different structuring criteria, has led to the use of a large only an abstraction (which adds to the complications of describing it with abstract only an abstraction (which adds to process. So in order to formulate and explore the forms), it is also the description of a use a set of description forms that are able to design model, a designer needs to properties of a system. describe both the static and the dynamic of the system. Such forms tend to emphasize fea- that describe the dynamic behaviour around a system, or the sequencing of tures such as the flow of data or information used to describe the characteristics that reflect these features. used to describe the characteristics that 5.2 for software viewpoints Design of software is its dynamic nature. Software is not Perhaps the most distinctive property Figure 5.5 the ways in which design representations can be that distinguish software systems, and

94 Describing a design solution SDC05 9/18/07 10:45 AM Page 94 AM Page 10:45 9/18/07 SDC05 95 Design viewpoints for software Changes of viewpoint with evolution of the overall design model. Changes of viewpoint These representations can all be classified as ‘direct’ viewpoints, in that they are These representations can all be classified data-modelling forms, concerned with the data objects used within the system, and data-modelling forms, concerned with the relationships between these. constructional* forms, in which the viewpoint is concerned with essentially static constructional* forms, in which the aspects of the system; that seek to describe the causal links behavioural forms, a set of viewpoints during execution; between events and system responses to describe what the system does in terms of functional forms, viewpoints that seek its tasks; can themselves be ‘structured’. Hence for this edition we have preferred the use of ‘constructional’ to make the can themselves be ‘structured’. Hence for this edition we have preferred the use of ‘constructional’ emphasis clear. a solution. However, this unintentionally introduced a note of ambiguity, in that all of the viewpoint descriptions a solution. However, this unintentionally introduced a note of ambiguity, in that all of the viewpoint * for these forms, on the basis that they described the structure of In the first edition we used the term ‘structural’ Figure 5.6 some form of interpreter in order to ‘execute’ a design (Harel, 1992; Friel and Budgen, some form of interpreter in order to ‘execute’ a design (Harel, 1992; Friel in terms 1997); here the output from the interpreter forms the derived viewpoint based on the of some sequence of states or diagrams. (This particular example is ties that a designer needs to consider. further class of viewpoints can be described as created directly by the designer. A 1992), shown in Figure 5.7; in these some ‘derived’ viewpoints (Budgen and Friel, model in order to generate a ‘new’ represen- transformation is applied to the design derived viewpoint is that produced by the use of tation form. An example of such a n are a number of forms in general use, partly Within each of these broad classes, there require different sets of attributes for their because the many possible relationships ever quite captures all of the proper- description, and partly because no representation n n n SDC05 9/18/07 10:45 AM Page 95 AM Page 10:45 9/18/07 SDC05 header file), and data in the form .h scenarios). While it is less general-purpose ’, provides an object-oriented classification ’, provides an object-oriented classification + 1 View ++ 4 , which may include files of data, files containing information Examples of the use of derived viewpoints within the viewpoints model. Examples of the use of derived viewpoints The rest of this section looks briefly at some of the characteristics of the four The rest of this section looks briefly While the above classification of viewpoints is a useful and practical one, it is While the above classification of viewpoints data specification about the organization of a program (such as a n As the name implies, these are primarily concerned with describing how the various As the name implies, these are primarily concerned with describing how languages, software-structuring forms provided in programming languages, mark-up is there- etc. are to be used in the final system. A characteristic role for this viewpoint Some fore that of describing the outcome of using a design practice such as a method. of the constructional forms described by this viewpoint include: tion that attributes are not necessarily uniquely confined to one viewpoint. tion that attributes are not necessarily section then considers how these can best classes of direct viewpoints. The following diagrams and mathematical forms. be described in terms of the use of text, 5.2.1 forms Constructional further in this book. can classify software design descriptions. As an by no means the only way that we example, Kruchten’s (1994) ‘ (logical, process, development, physical some similarities, including the shared recogni- than the form adopted here, there are observed behaviour of designers in ‘mentally executing’ a design in order to assess its observed behaviour of designers in ‘mentally 1985).) While observation suggests that behavioural aspects (Adelson and Soloway, such viewpoints in an informal way, they do not designers make use of a number of design practices and they will not be explored form part of any currently formalized Figure 5.7

96 Describing a design solution SDC05 9/18/07 10:45 AM Page 96 AM Page 10:45 9/18/07 SDC05 97 Design viewpoints for software , being , where such con- , where such package finite-state machines or the Ada or the Ada class , such as the Java , such as , usually in the form of sub-program organization, but also organization, in the form of sub-program , usually , describing the dependencies that exist between classes (Parnas, 1979). that exist between classes (Parnas, , describing the dependencies , describing how the ‘flow of control’ is managed between program the ‘flow of control’ is managed between , describing how , concerning the sources and forms of data; , concerning the sources Most of these forms can be considered as examples of We should also note that, partly because this form describes the designer’s ideas at We should also note that, partly because While this viewpoint is largely used to describe the outcomes of the design process, While this viewpoint is largely used to Generally, this viewpoint is concerned with modelling static structures rather than Generally, this viewpoint is concerned An important part of the description involves specifying the relationships and of the description involves specifying An important part data flow invocation elements; uses hierarchy system, or to create inheritance hierarchies. system, or to create of mark-up languages such as HTML (HyperText Markup Language) and XML and Language) Markup (HyperText such as HTML languages of mark-up Language); Markup (Extended execution threads of of execution; parallel threads constructs for handling including constructs packaging sections of the ‘scope wall’ around some form of be used to construct structs may system. 5.2.2 forms Behavioural causal issues, connecting an ‘event’ to a ‘response’ These are essentially concerned with tend to be far more abstract than the previous via any necessary conditions. These forms compilable entities that have definite syntax class, which are usually concerned with forms are more likely to be concerned with and semantics. In contrast, behavioural across a number of the physical elements in a operations that may actually be spread tioning major elements of functionality rather than being constructional in nature. tioning major elements of functionality detailed notations used are usually very depend- relatively low levels of abstraction, the the eventual system. We will discuss this point in ent upon the ‘architectural’ form of rather more detail in Chapter 6. with any form of run-time behaviour. (An attempt was made to combine construc- with any form of run-time behaviour. features in a development of the Structure Chart tional information and behavioural and Constantine (1979), but this does not notation that was proposed in Yourdon degree.) appear to have been used to any significant level when considering major units that might be it can also be used at a more abstract this role is more likely to be one of parti- used in some overall design plan. However, n n n dependencies that will exist between the elements of the system. Typically, these are will exist between the elements of the dependencies that such forms as: n n ability to represent the varied influences of time is rather uneven, as the examples of Chapter 7 will show, and can be summarized thus: concerned with the transitions that occur between different states of (waiting, a system to make processing, output and so on), and the conditions (events) that are required forms are them occur. Being concerned with dynamic relationships (causality), these required to handle some of Our the design properties that are concerned with time. SDC05 9/18/07 10:45 AM Page 97 AM Page 10:45 9/18/07 SDC05 (in terms of structures such than design, for this very reason. sequence analysis . form descriptions are also fairly tractable, although their use is mainly tractable, although are also fairly descriptions (both in compounding types to create new ones, and in such mechan- (both in compounding types to create aspects can be described fairly well; described can be aspects effects are very difficult to capture and describe using existing forms of using existing forms capture and describe very difficult to effects are type For some classes of problem, the choice of data structures is a central one, and can- For some classes of problem, the choice themselves may well be imposed by external Modelling of data structures, which At the detailed design level such forms are generally needed to describe the run- At the detailed design level such forms Behavioural descriptions can be used for both black box modelling roles (con- can be used for both black Behavioural descriptions sequencing sequencing fixed-interval of real-time systems; to particular features restricted constraint description. This section examines how the different forms of notation for constructing represen- This section examines how the different forms of notation for constructing are: tations are used. The three basic components that can be used in a representation Whatever the role, the data-modelling notations do tend to be used primarily in white Whatever the role, the data-modelling notations do tend to be used primarily box roles, due to the relatively detailed nature of the information involved. 5.3 of notation Forms not easily be divorced from the functional issues. Because the viewpoints describing not easily be divorced from the functional nature, and hence more easily handled, there are data structures are essentially static in that are widely used for modelling these a number of well-established representations forms. task for factors, is often seen as being more a While the description of data structures need not be a very significant issue in archi- While the description of data structures aspect of a detailed design. Again, there are tectural design terms, it is often a critical need to be captured. These include such depend- a number of relationships that may encies as: ‘classes’); isms as inheritance, used to create new as trees and lists); and of the initial problem specification, and the algorithmic aspects in particular may be of the initial problem specification, better specified than other features. time behaviour of program elements such as subprograms. 5.2.4 forms Data-modelling 5.2.3 forms Functional exactly what it is that a system tasks for the designer is to describe One of the hardest is difficult to describe in any a problem-driven issue and hence does. This is essentially this may well be one of the better-defined aspects general form. However, in exchange, sidering how the system as a whole will respond to specific events) and white box system as a whole will respond to sidering how the interact in terms of ‘chains’ of how the system elements will modelling (describing has probably become much Overall, their importance and use events and actions). as constructional forms such systems have become larger and also more pervasive as use. have come into more widespread as classes and objects n n n

98 Describing a design solution SDC05 9/18/07 10:45 AM Page 98 AM Page 10:45 9/18/07 SDC05 99 Forms of notation fonts (when available) can help to italic or bold diagram and see what sense it makes!). Their use during the sense it makes!). Their use during diagram and see what any So textual forms are rarely used as the sole means of providing information about So textual forms are rarely used as the The main problems with using text alone are that: The main problems in a form that maps easily onto lists and tables. Indentation can help with pro- in a form that maps easily onto lists limited, owing to the difficulty of recognizing viding structure, but its usefulness is alignments over long blocks of text; ambiguity, and resolving this can lead to the natural-language forms are prone to text. use of long and complex sequences of any structure that is implicit in the information can easily be obscured, unless it is any structure that is implicit in the information text diagrams expressions mathematical brain (Miller, 1957); but it may be somewhat misused here, since it referred to hand- brain (Miller, 1957); but it may be somewhat misused here, since it referred ling ‘events’ rather than abstractions.) Diagrams have been extensively used in the first four chapters of this book to illustrate Diagrams have been extensively used in the first four chapters of this book of relation- concepts about hierarchy, position, flow of information and other forms simplicity of ship between abstract objects. As with text, diagrams also benefit from that form, and there is probably a ‘natural limit’ to the number of items of information 7 plus or can be easily assimilated when reading a diagram. (Miller’s ‘magic number’, the human minus 2, is much quoted in this context of handling information within 5.3.2 forms description Diagrammatical This shows that text is often most effective in conveying information when it is used This shows that text is often most effective in small blocks or tables. The use of n In particular, ‘structured’ forms such as ordered lists and tables provide a ready means forms such as ordered lists and In particular, ‘structured’ lists and numbered lists appear – many examples of ‘bullet’ of referring to information such mechanisms are therefore a summary is a form of abstraction, in this book. Since too. useful to the designer n all of the text from all of the text from need not be mutually exclusive. design process also 5.3.1 forms description Textual not just for design. used as a means of summarizing information, Text is very widely n n n neither of the latter any sense: indeed, exclusive in these are not mutually Of course, (try removing a textual component very much use without is likely to be of two forms this role is the use of standard ‘pro-formas’ in the SSADM method (Longworth, 1992) this role is the use of standard ‘pro-formas’ certain design decisions. The use of a standard in order to capture information about overcome the problems of producing and read- form provides the structure needed to ing free text. highlight items, but the effect of this is rapidly lost if used to excess. (In handwritten highlight items, but the effect of this substitute.) material, underlining acts as an adequate a supplementary role. A good example of text in design ideas, although they can play SDC05 9/18/07 10:45 AM Page 99 AM Page 10:45 9/18/07 SDC05 The traditional flowchart notations: (a) Some of the symbols used; Historically, the earliest form of diagram associated with software design is form of diagram associated Historically, the earliest Diagrammatical notations are very widely used in software design, as in many design, in software used widely are very notations Diagrammatical already referred to what we have all of them are also pragmatic reasons, For largely Figure 5.8 (b) A simple example of a flowchart. as representative as any other visual form might be. Curiously, given their long history any other visual form might be. Curiously, as representative as little research into the cognitive of form, there appears to have been of use and variety notations to describe software properties. aspects of using such main symbols that are used in Figure 5.8 shows some of the probably the flowchart. of the form. As sometimes together with a very simple example drawing flowcharts, forms of design activity. Indeed, most of the forms that will be discussed in this book in this be discussed that will the forms most of Indeed, activity. of design forms this very briefly at be discussed only their properties will and so are diagrammatical, point. a pencil, or sketched produced with diagrams are easily line’ forms. Such as ‘box and are of software, they characteristics absence of any visible and, in the on a whiteboard

Describing a design solution 100 SDC05 9/18/07 10:45 AM Page 100 AM Page 10:45 9/18/07 SDC05 Forms of notation 101 hierarchical organ- . This occurs where one or more forms of ‘diagram element’ can themselves be . This occurs where one or more forms of ‘diagram element’ can themselves As a footnote to this discussion: the use of colour is probably best restricted to pre- As a footnote to this discussion: the use of colour is probably best restricted A further useful property of many forms of diagram is that of A further useful property of many forms As mentioned earlier, a desirable quality in any diagrammatical form of represen- As mentioned earlier, a desirable quality For most users, diagrams are usually the most effective way of providing a clear For most users, diagrams are usually It is interesting to look at the number of symbols that are used in the more suc- look at the number of symbols that It is interesting to The use of flowcharts for general software development is certainly not recom- for general software development The use of flowcharts A major criticism of the flowchart is that it chiefly describes a solution in terms of describes a solution is that it chiefly of the flowchart A major criticism then, do remember that a substantial percentage of the average audience may have then, do remember that a substantial percentage of the average audience problems in distinguishing between many of the colours that you use. ization advantage described using a diagram of that form. Hierarchical organization offers the and com- that diagrams can then be ‘layered’ into levels of abstraction, avoiding large plex diagrams and so aiding comprehension. even sentations, where it can be used to highlight features of a diagram. However, municating those ideas to others. Such conventions as the use of thick and thin lines to municating those ideas to others. Such out by this criterion, as are the use of complex distinguish between attributes are ruled object-oriented design forms fail this test, and icons or symbols. (Unfortunately some available powerful diagramming tools on when they are combined with the widely the effect of binding a designer into the use of work-stations, their adoption can have design tasks.) these tools even for early architectural text. Like text, diagrams have both a syntax (‘how we say it’) and a semantics (‘what it text. Like text, diagrams have both a to ensure that the diagram meets its purpose. means’), and these need to be used correctly using only a pencil and paper (or pen and tation is that it should be easily produced essential criterion to meet if diagrams are to be whiteboard, and so on). This is an of exploring ideas about a design and com- easily and rapidly sketched out as a means is a measure of the degree of abstraction involved in their use. As a general rule, the is a measure of the degree of abstraction tend to be at lower levels of abstraction (the forms with the larger numbers of symbols problem with their use is that of remembering flowchart is a good example), and one all the nuances of the notation. However, this is not guaranteed, and summary of abstract concepts and relationships. than a heap of unstructured and ungrammatical a poor diagram is no more helpful mended, and they are now rarely taught or used except for specialist purposes. However, now rarely taught or used except for mended, and they are design, with properties of diagram are now used in software very many other forms in the design process. the forms of abstraction required that more closely reflect those that continue to be used forms. (By ‘successful’ is meant cessful diagrammatical more than four or five symbols, which in itself over a period.) Many of them have no describes structural forms that are not much more abstract than the final program forms that are not much more abstract describes structural we experimented in a small way little benefit. (Some years ago now, code, and so offers both flowcharts and pseudo- the development of a system by using with documenting as we found that our months, we decided to drop the flowcharts code. After a few extracted from the pseudocode.) information was always happens with pioneering ideas, it has not stood the test of time very well and is now well and time very test of stood the it has not ideas, pioneering with happens purposes. specialist only for used its of the problem and than in terms machine, rather of the underlying the operations forms for sequencing emphasis upon it also places great As a part of this, structures. more explicit by mod- now made much design that is a feature of detailed operations, is that the flowchart significant reason Perhaps the most structures. ern programming SDC05 9/18/07 10:45 AM Page 101 AM Page 10:45 9/18/07 SDC05 ., 1994), and we will look ., 1994), (1), 8–20 et al 25 , IEEE Computer (4), 459–527 30 , ACM Computing Surveys Mathematical forms have particular strengths in describing system behaviour, and have particular strengths in describing Mathematical forms Since computers are discrete machines, with finite word size and many states, the discrete machines, with finite word Since computers are the use of text, diagrams, and mathematical expressions as the three basic forms in con- the use of text, diagrams, and mathematical structing design representations. the roles of representations in capturing, explaining, and checking design information; the roles of representations in capturing, model, as a means of capturing a particular set of the concept of a viewpoint of a design the use of a representation; design properties, and as projected through – the constructional, behavioural, functional, the principal classes of direct design viewpoint and data-modelling forms; niques. Further reading Summary This paper was written in answer to an earlier paper by Fred Brooks Jr (Brooks, 1987). It is This paper was written in answer to an earlier paper by Fred Brooks Jr (Brooks, the use of what mainly concerned with the problems of describing reactive systems and discusses Wieringa R. (1998). A survey of structured and object-oriented specification methods and tech- Wieringa R. (1998). A survey of structured and object-oriented specification methods of their A comprehensive analysis of a wide range of design methods, together with an analysis use of notations, which is of particular relevance here. Harel D. (1992). Biting the silver bullet. n n n n This chapter has examined the issues involved in providing descriptions of a designer’s ideas. This chapter has examined the issues involved in this were: Some key points and terms that were identified gerated, since the concepts involved are frequently familiar enough to programmers. involved are frequently familiar gerated, since the concepts limitations include the com- the issues of time dependency. Major in handling some of symbols (together with in terms of using a range of unfamiliar plexity of the notation and difficulties with handling standards for these on occasion) a certain lack of descriptions of large-scale systems. form of mathematics most appropriate for the needs of software design is that which most appropriate for the needs of form of mathematics is still less likely to structures. Unfortunately, discrete mathematics describes discrete forms, and so one of the dis- armoury than more classical be part of the engineer’s additional staff training and mathematical forms is the need for advantages of using problem should not be exag- quite advanced levels. However, this education, often at 5.3.3 notations Mathematical pro- forms to in using mathematical an increased interest years there has been In recent (Fraser software designs descriptions of vide abstract the stems from Much of this interest this in Chapter 18. some examples of briefly at combine abstraction in being able to forms have that mathematical great advantage of ambiguity. with a lack

Describing a design solution 102 SDC05 9/18/07 10:45 AM Page 102 AM Page 10:45 9/18/07 SDC05 Exercises 103 of standardizing any particular form of design description; of standardizing any standardizing the same form of description. standardizing the same against in favour (a) the hierarchy of pages in a website; (b)make use of a particular data type in a program. the program units (procedures) that (b) a list of reasons it provide? viewpoint on the design model does capture, and hence what diagram; a mathematical form: points that might be needed in order to provide a full design description, and the represen- needed in order to provide a full design points that might be used for these. tations that could be (a) a list of reasons Exercises 5.3 does it of the flowchart. What design attributes Consider the (much-maligned) example 5.4 using in turn: text on its own; a Suggest how you might represent the following viewpoints 5.1 any other view- that was used in this chapter, suggest For the example of building design 5.2 Write down: I have termed ‘derived viewpoints’ for design model execution as well as representation forms in as representation as well model execution design for viewpoints’ termed ‘derived I have general. SDC05 9/18/07 10:45 AM Page 103 AM Page 10:45 9/18/07 SDC05 SDC05 9/18/07 10:45 AM Page 104 SDC06 9/18/07 10:50 AM Page 105

chapter 6 105 Transferring Design Knowledge

6.1 The need to share knowledge 6.4 Design patterns 6.2 The architecture concept 6.5 A unified interpretation? 6.3 Design methods

Codifying and exchanging experiences about both the processes involved in designing and the resulting design features that have proved effect- ive, are essential activities (indeed, they form the core theme of this book!). One role for these activities is the promulgation of new know- ledge to existing practitioners. A second is to provide the means of con- veying the ‘body of knowledge’ about software design issues to new or would-be designers. In this pivotal chapter, we examine the forms that are most widely employed for these purposes, and conclude by pro- viding a simple framework that shows how their roles can be related to each other. , so that the accumulated experiences of the practitioner , so that the accumulated , so that new knowledge can be promulgated throughout the can be promulgated throughout , so that new knowledge they know how to do something, while manifestly being able to demonstrate their they know how to do something, while manifestly being able to demonstrate The last point is significant. An expert practitioner may well be unable to explain The last point is significant. An expert practitioner may well be unable to The type of knowledge that needs to be transferred will obviously vary. For scient- The type of knowledge that needs to peer to peer exchange body of practitioners; teacher to pupil instruction to join the group. to new members or to those aspiring group can be conveyed have no rationalized explanation as to why this is so. Such ‘heuristics’ or ‘rules of have no rationalized explanation as to why this is so. Such ‘heuristics’ based upon thumb’ are no less valid for the lack of an explanation. Indeed, they may be the ‘knowledge’ involved may also include experience of when particular forms of the ‘knowledge’ involved may also include experience of when particular solution may work well or otherwise and, if possible, the reasons for this. why which knowledge in practice. For example, an expert in graphic design may ‘know’ but may typefaces are most effectively used together for particular styles of document, studies, and of the results from particularly significant experiments. Between peers, studies, and of the results from particularly may be transferred by means of personal knowledge of new work and new results the web and conferences. For their pupils, links, as well as through books, papers, ‘classical’ experiments, models and practices, there is the need to learn about the study. Within those domains that are largely through various forms of classroom including both craft and engineering dis- centred around more ‘creative’ activities, to transfer knowledge may not be very different, ciplines, while the mechanisms used (CPD), and employ mechanisms such as the ‘pattern book’ (in a very general sense) (CPD), and employ mechanisms such basic purposes behind their use are largely the and interactive on-line instruction, the same as they were for the craft guilds. models of how their particular aspect of the ists, the relevant knowledge may include to be suitable for conducting experimental world works, of the techniques considered The craft guilds of the Middle Ages provided classical examples of a structure organized The craft guilds of the Middle Ages provided and exchange (and, possibly, protect) the know- for this purpose, acting to preserve together with an apprentice–master structure ledge of how to pursue a given craft, A more modern example is the way in which used to add new members to the group. to acquire and be tested on ‘The Knowledge’ aspiring London cab-drivers are required to be licensed. In the context of more creative about routes around the city in order such as ‘Continual Professional Development’ activities, while we might now use terms n n 6.1.1 share? Why knowledge, it is custom- practitioners need to employ specialized Wherever a body of between them become ways in which that knowledge is transferred ary to find that the for: forms, in order to provide codified in some appropriate 6.1 knowledge share need to The convey ‘knowledge’ forms employed to is the various theme of this chapter Since the section examines both this opening process and product), design (both about software to that are apt and the factors transferring knowledge the motivations for some of impede this.

Transferring design knowledge 106 SDC06 9/18/07 10:50 AM Page 106 AM Page 10:50 9/18/07 SDC06 The need to share knowledge 107 , which are generalizations that are ‘signed’ by the author, but , which are generalizations that are , which report on actual phenomena, and for which the value is , which report on actual phenomena, , or well-established scientific truths, with their value being measured in scientific truths, with their value , or well-established Our ability to transfer knowledge about how to design software is also con- Our ability to transfer knowledge about how to design software is also Both of the reasons for transferring knowledge that were identified at the begin- Both of the reasons for transferring Not only is the transferability of knowledge a problem, the quality of that know- of knowledge a problem, Not only is the transferability determined by the degree of ‘interestingness’ that they possess for us. determined by the degree of ‘interestingness’ Rules of thumb by data, and where the value is determined by which are not necessarily supported their usefulness. Findings been established. to the rigour with which they have forms that correspond Observations and transfer knowledge. The remaining sections then examine the nature of these and transfer knowledge. The remaining sections then examine the nature mechanisms in rather more detail. real-time systems, databases, games, etc., the designer is still likely to be expected to real-time systems, databases, games, etc., the designer is still likely to be tackle all aspects of software development that might arise. been men- strained and limited by a number of factors, some of which have already ourselves tioned in the preceding chapters. In the rest of this section we briefly remind to codify of some of these, and then review some of the mechanisms by which we seek cannot be expected to possess the knowledge needed to produce creative solutions cannot be expected to possess the domains and solution forms that we encounter. across the wide range of problem through specialization: a specialist in ear, Other disciplines may address this problem normally attempt to remove an appendix; nor nose and throat surgery would not to attempt to enter the luxury car market. How- would a shipbuilding firm be likely in software systems are less clear-cut. Even ever, the distinctions and specializations to some degree, such as in the development of where software producers do specialize design issues are concerned, much of our knowledge is likely to be of the second and design issues are concerned, much of problems in terms of codifying it. third kinds, with correspondingly greater software design as for any other form of design. ning of this section are as relevant for is necessary in any domain and so needs Indeed, the instruction of pupils (novices) In addition, even expert software designers little further discussion at this point. 3. not always recognized! Certainly though, where Unfortunately these distinctions are ferentiate between the following three kinds of results (‘shells of knowledge’) when the following three kinds of results ferentiate between issues (Brooks, 1988). considering computing 1. 2. and it may be difficult to apply it outside of a limited set of problems. In a domain to apply it outside of a limited and it may be difficult many crafts), this are relatively repetitive (which characterizes where the problems (and hence software an issue. However, software development may not be too critical is true. not constitute a domain where that design) certainly does that it is useful to dif- rather mixed. Indeed, Brooks has suggested ledge may also be such deep and complex cognitive issues that any explanation will be of limited general of limited will be any explanation issues that cognitive complex deep and such con- point when this very make the authors (1994), Conger Vessey and (In usefulness. can be quite difficult, problem solving expert design: ‘examining sidering software are at which they processes to the point problem-solving automate their since experts though, without some Unfortunately what they are doing’.) able to articulate no longer that helps to distin- – one of the issues solutions work of ‘why’ particular knowledge limited in its scope, a heuristic may be from a craft – engineering discipline guish an SDC06 9/18/07 10:50 AM Page 107 AM Page 10:50 9/18/07 SDC06 , pro- indirect in nature: direct . Our assessment of the degree of success or failure of . Our assessment of . One major consequence of this was discussed in the pre- . One major consequence . The act of designing involves employing knowledge about . The act of designing involves employing . Design solutions are inextricably interwoven with domain know- . Design solutions are inextricably interwoven (reusable elements, materials used in implementation, etc.) and about (reusable elements, materials used in (how to go about solving a particular type of problem). Transferring know- (how to go about solving a particular design knowledge design problem, they also have quite significant limitations. This issue is one that is problem, they also have quite significant limitations. This issue is one explored more fully in the next sub-section. ledge about products is usually well understood as a problem, and a mechanism when we such as the ‘catalogue’ is generally employed. However, as we will see such come to consider reuse in Chapter 17, because software is really a process, a creative tried and tested forms are less effective. Transferring knowledge about studies process such as designing is more problematical. Mechanisms such as case of the and stylized design processes both have useful roles to play but, by the nature nificant factor in failed solutions. A good example of this issue is provided by the nificant factor in failed solutions. A automated baggage handling system, which experiences of the Denver Airport the mid 1990s (Swartz, 1996). achieved some degree of notoriety in Process versus product products cesses for example, a real-time solution is highly likely to require the designer to make for example, a real-time solution is of that solution, to ensure that the key decisions about priorities for the elements response time. It may also be more elements are able to meet the required the properties that can be considered when perhaps involving knowledge about domain, and how these can be prioritized. making design trade-offs in a particular of the domain context may be a sig- Failure to fully understand the implications significant when assessing any other form of artifact, the distinction is much more significant when assessing any other element is so directly linked to the blurred for software, where the ‘construction’ phase exists. design element and no separate manufacturing Domain factors is to ‘bound’ the set of acceptable solutions ledge. One role for domain knowledge involved in this role may be to a given problem. The knowledge present. Influence of implementation success or failure of their is apt to be entangled with the particular design solutions poor programming or is particularly true of failure, where implementation. This nullify any good qualities of the design the lack of computing power can completely influence of implementation issues is equally itself. While it can be argued that the Invisibility of the medium line’ representations to both the difficulty of linking ‘box and vious chapter, namely in any consistent manner. and to their eventual implementation abstract concepts our own version of the of notations available is apt to create Indeed, the variety communicate design ideas. we are faced with the need to ‘Tower of Babel’ when conceptual barrier is still of notation is helpful, the While some standardization n n n n 6.1.2 of and transfer codification constrain that Factors the that arise from are a mix of those we encounter design the constraints For software of our knowledge from the limitations and those that arise the medium itself nature of wider issues of design. about the

Transferring design knowledge 108 SDC06 9/18/07 10:50 AM Page 108 AM Page 10:50 9/18/07 SDC06 The architecture concept 109 to solu- , 1995). forms et al. provide a frame- which the designer sign knowledge sign strategy is a more established approach. is a more established architectural style transferring de transferring and of processes came into accepted usage in the 1970s, and came into accepted (Perry and Wolf, 1992; Shaw and Garlan, 1996) (Perry and Wolf, architecture has provided an alternative form for use both in codifying and has provided an alternative form for software design method software architecture design pattern for ‘representative’ problems has sometimes been provided through the use of problems has sometimes been provided for ‘representative’ The following sections examine each of these concepts in rather more detail, while The following sections examine each More recently (and within the context of a particular architectural form), the idea More recently (and within the context Transferring knowledge about design Transferring knowledge Codifying and transferring knowledge about the form of detailed design knowledge about the form Codifying and transferring here.) We begin by identifying what we mean by a software architecture; look at how here.) We begin by identifying what we mean by a software architecture; and different architectural styles can be described; examine three simple examples; 6.2 concept The architecture the Since this concept provides some important ideas that we will be using throughout other two rest of this book, we provide quite a detailed description in this section. (The treatment topics are addressed more extensively at a later point and so get a briefer is one which seeks to classify the more abstract features of a design solution. So this to classify the more abstract features is one which seeks describing solution basic vocabulary that can assist with concept provides a others. The early forms of to elaborate further upon how these roles are performed. to elaborate further tions been devised that can be recently has a more general framework case studies, but only form of design solutions. The codify ideas about the higher-level used to record and concept of a From the above, we can see that transferring knowledge about a creative process such process a creative about knowledge transferring see that we can the above, From automated. is easily one that task, or a simple no means is by as design 6.1.3 and codifying for Mechanisms of with the design which experience of the ways in briefly review three Here we on sections then go The following and transferred. systems is codified software-based classes of problem. The form of knowledge employed is largely about the sequences of classes of problem. The form of knowledge form of solution (methods tend to implicitly decisions that can lead to a particular style). assume a particular form of architectural of the design might be structured (Gamma transferring knowledge about how a provided a procedural form of guidance on how to develop solutions for specific provided a procedural form of guidance still focusing on their roles as mechanisms for knowledge codification and transfer. still focusing on their roles as mechanisms However, since the concepts of and since we will be discussing the roles of work for much of the rest of the book, most of the emphasis has been placed upon methods and patterns in later chapters, architectural issues. they describe particular solutions to commonly occurring problems. However, this is they describe particular solutions to in that it is not a solution template within which to misunderstand the role of a pattern, but rather a solution the user has only to ‘plug’ some code, So patterns are really much more about the can then adopt for a particular problem. sense, therefore, their role is closer to that of the ‘how’ of design development. In that with transferring knowledge than codifying it. design method, being more concerned Superficially, patterns would appear to codify knowledge about design products, since Superficially, patterns would appear SDC06 9/18/07 10:50 AM Page 109 AM Page 10:50 9/18/07 SDC06 , ! While it ., 1996). architecture designing choose to do so, et al may , when what they really mean is architecting has long been one that is associated with a quite specific has long been one has been used for many years within the software development within the software used for many years has been architect architecture Perhaps a little inconsistently though, an architect does not design an Perhaps a little inconsistently though, Closer to our own domain, we also have the concept of the ‘computer architect’ Closer to our own domain, we also The role of the might be possible to ‘verb any noun’, this one is particularly inappropriate. *of A personal bête noire here is those who speak provide a framework for that design task, by identifying a general set of characteristics on (the style) that relate to the problem and which have been employed successfully reflection of similar problems. As such, the ‘physical’ concept of architecture is more a common patterns than something that is itself designed (Buschmann to software. However, Perry and Wolf (1992) have rightly cautioned against drawing to software. However, Perry and Wolf a hardware architecture makes use of a the analogy too far. As they have observed, with scale being achieved by replication of relatively small number of design elements, neural networks), this is rarely true for software, these. With a few exceptions (such as involves adding further distinct design elements. where any increase of scale generally need.* The role of architectural style is to but rather a solution to address a particular puters with a generally consistent form (typically described using such terms as RISC, puters with a generally consistent form providing a (largely) consistent platform for pipeline, etc.) became the norm. By up great opportunities, both in terms of the executing software elements, this opened for software to evolve and migrate, rather marketplace, and also by making it possible new generation of computers. Indeed, it is this than needing to be rewritten for each the motivation for seeking to adapt this concept very success that has provided part of of these cases, we associate the term very much with those people whose role is to of these cases, we associate the term tasks, rather than managing the details of the undertake the more abstract design actual implementation. of a computer, usually referred to as its ‘architec- who designs the top-level structures more important concepts in the development of ture’. Indeed, this has been one of the 360/370 range, the idea of a ‘family’ of com- computing. Beginning with the IBM ibility, in that no-one expects the architect involved with developing a new building expects the architect involved with ibility, in that no-one architect in managing its construction. The to actually take part is used in other domains too, not expected of him or her. The term but in general, it is of ‘naval architects’ as being analogy. For example, we may speak although usually by so); and also of ‘land- ships (usually warships, but not necessarily people who design is that of gardens, estates, etc. Again, in both scape architects’ whose domain of design has also been used by different people to mean rather different things. So before going by different people to mean rather different has also been used by the work of a number in which this has been drawn together on to look at the way and David Garlan, it is use- by Dewayne Perry, Mary Shaw of people, and especially sense. we mean by the term in a more general ful to consider what a very clear design respons- namely buildings. This is also a role with domain of design, then briefly consider how the concept provides aid for our theme of transferring our theme aid for provides concept the how briefly consider then design. about knowledge 6.2.1 architecture? is What The term it descriptive terms, as with so many Unfortunately, a very informal manner. world in

Transferring design knowledge 110 SDC06 9/18/07 10:50 AM Page 110 AM Page 10:50 9/18/07 SDC06 The architecture concept 111 and, for style can perhaps best be viewed as something can perhaps best be is often the most useful one to employ, and most useful one is often the architectural style architectural style architectural , 1995). Thirdly, it tells us something about the type of construc- , 1995). Thirdly, it tells us something et al. ? In practice, most authors seem to consider this to be an abstract top- be an abstract this to to consider seem most authors ? In practice, of a particular design solution, it may also tell us something about the design pro- of a particular design solution, it may also tell us something about the design In addition, although the concept is primarily concerned with categorizing the In addition, although the concept is primarily concerned with categorizing archi- One of the clearest discussions about the roles of software architecture and So what roles can the idea of architectural style provide when applied to software So what roles can the idea of architectural So the notion of an So the notion of an So that begs the question of whether we can usefully speak of a system as having of a system speak can usefully we of whether question begs the So that architecture tectural style is provided in a short paper by Garlan and Perry (1995). Writing as an tectural style is provided in a short paper by Garlan and Perry (1995). Writing many of introduction to a collection of papers on software architecture, they capture form methods cesses involved. Indeed, a rarely recognized characteristic of software design style upon is that the use of any method implicitly imposes a particular architectural next section. the designs that are produced. This is a point that we will return to in the server’ and ‘pipeline’ are widely employed, although not necessarily well-defined. One server’ and ‘pipeline’ are widely employed, on the form and structure of a family of view of this role is that it ‘defines constraints Perry, 1995). Secondly, as mentioned above, the architectural instances’ (Garlan and where there is potential for some degree of ‘mis- concept may assist with identifying the elements used to construct a software-based match’ to occur between the forms of system (Garlan useful for describing a particular solution. tional notations that are likely to be systems? Firstly, the role of providing a very abstract description of the overall form is systems? Firstly, the role of providing is more likely to be expressed in terms of con- still an appropriate one, although this we may also refer to buildings in this way, structional forms than epochs. (Of course, concrete’, where such a description provides some as in ‘wattle and daub’ or ‘glass and will be.) Descriptive terms such as ‘client– idea of what the likely form of the building quences of mixing items of software that have different architectural styles. (Returning quences of mixing items of software we can easily see that adding a 1960s-style flat briefly to the analogy with buildings, built in the Tudor period is unlikely to be visu- roofed extension to a cottage that was to ‘bond’ well physically! Both may well be quite ally harmonious, nor are they likely constructed in a style that is appropriate for the functional in their own way, and be but as these are so very different, some degree materials employed in their fabrication, of ‘mismatch’ is almost guaranteed.) that provides a very abstract description of a particular set of general characteristics of abstract description of a particular that provides a very will then know something of provided with such a description, we a solution. When there may still be great vari- a particular solution, but within that the general form of we will return to later, such a specifically, and this is a point that ation in detail. More a fairly broad assessment of the likely conse- description may also enable us to make describing buildings we often seem to use temporal classification of styles, perhaps we often seem to use temporal describing buildings architects have developed par- materials have come along, so because, as new building of ships, role is more likely them. In contrast, in the domain ticular ways of employing describe a ship as an ‘aircraft classifying architectural style. If we to be the basis for as a flat ‘through deck’ that it is likely to have such characteristics carrier’, then we know for its superstructure, etc.) land and take off, and a small ‘island’ to allow aircraft to an and their general of its major elements expressed in terms of a design, level description of its a description this is also apt to provide way we express form. The the term our purposes, speaking about build- example, when in this book. For will use extensively one that we a ‘1960s’ style. (When ‘Elizabethan’ or building is in an say that a given ings we might SDC06 9/18/07 10:50 AM Page 111 AM Page 10:50 9/18/07 SDC06 that elements , which we will be examin- , which we component was then described as a set of ‘weighted properties and {Elements, Form, Rationale} = Form . This stems from the way that architectural concepts provide an concepts provide that architectural from the way . This stems . The arguments here are largely concerned with the role of architec- are largely concerned with the role . The arguments here . Garlan and Perry argue that ‘software architecture can expose the argue that ‘software architecture . Garlan and Perry . Here an architectural style offers a framework that can provide the basis style offers a framework that can . Here an architectural . This partly relates to the idea of the relates to the idea . This partly In Perry and Wolf (1992), the authors proposed an initial classification scheme in In Perry and Wolf (1992), the authors Various authors have suggested some ways in which we might classify architec- Various authors have suggested some processing elements data elements connecting elements Analysis conformance to the style!). features of a design (including its for checking various Management for change. and, in particular, of planning ture as an aid to planning Reuse ing in Chapter 17. Evolution As such, therefore, it pro- which a system is expected to evolve’. dimensions along for use by those entrusted ideas and aims of the originators, vides a guide to the and change. with its later maintenance Understanding design. a system’s high-level understanding of that aids abstract vocabulary Software Architecture of connecting elements include such mechanisms as procedure calls, messages, shared of connecting elements include such mechanisms as procedure calls, messages, data repositories, etc.). can be used. relationships’, which constrains the choice of elements and how they n n n (Examples where the connecting elements could also be processing or data elements. the form of: a style) could be considered as being defined through which an architecture (and hence a particular form. The particular by a set of (design) elements that have they identified were: For the concept of an architectural style to be of use to us, we need to be able to pro- For the concept of an architectural style in some way. Not unreasonably, since a style vide a specification of its characteristics might also expect that the notation we use to describes ‘a family of instances’, we individual systems should also be suitable for describe the architectural form of of an architectural style too. describing the more general concept chapters, and all of them are issues that we will return to in later ones. chapters, and all of them are issues that to describe software systems. We now go on to tural styles so that these can be used some of the points made in this sub-section. review some of these, in order to illustrate 6.2.2 styles architectural Classifying n n already encountered in the discussions of earlier Some of these are issues that we have n n the key issues very elegantly and in a concise manner. The authors also argue that the argue authors also The manner. in a concise and very elegantly issues the key of five aspects following at least the upon an impact can have of architecture concept development. software n

Transferring design knowledge 112 SDC06 9/18/07 10:50 AM Page 112 AM Page 10:50 9/18/07 SDC06 The architecture concept 113 Client–Server Blackboard architectural description language. UniCon . In contrast though, the scheme adopted in Shaw and adopted in though, the scheme . In contrast content control’ by the recipientthread of control Pipe-and-filter concurrent processes ‘Classical’ Objects components Distributed Objects Lightweight threads was intended to capture the motivation for particular choices for particular the motivation to capture intended was connectors and rationale Major categories of software architectural style Various efforts have also been made to codify such descriptions of architectural Various efforts have also been made Subsequent authors have often tended to adopt simpler schemes of classification. simpler schemes tended to adopt authors have often Subsequent how data is communicated through the system; how data is communicated interact; how data and control style. reasoning that is compatible with the the type of (design) the kinds of components and connectors that are used in the style; and connectors that are used the kinds of components and transferred among control (of execution) is shared, allocated the ways in which the components; Data-sharing Direct sharing of data among Hypertext Call-and-returnInteracting processes Order of computation with a single Communication among independent, Data-centred repository Communicating processes Main program/subprograms Complex central data store Transactional databases Table 6.1 CategoryData-flow Characteristics Motion of data, with no ‘upstream Batch sequential Examples of Styles authors categorize architectural styles in terms of the following major features: architectural styles in terms of the following authors categorize (although, as we have observed previously, this information is too rarely recorded). is too rarely this information previously, we have observed as (although, based only upon a basic framework (1996) employ Shaw and Garlan For example, components also returns to some (and in some ways, more elaborate (1997) is somewhat Clements the way). Here organized in a different Wolf, although used by Perry and of the ideas and there is also a discussion of their own and there is also a discussion of their to debate, since there is the inevitable conflict Whether this is a realistic goal is open and those of the detail needed for speci- between the needs of abstract description more fully in the next chapter). However, for the fication (a conflict that we examine concerned with the concepts and with their cat- purposes of this book we will only be egorization in general terms, as above. section, we employ it to briefly examine and categorize some examples of different section, we employ it to briefly examine the styles identified by Shaw and Clements. architectural styles. Table 6.1 summarizes to aid with analysis, although also to provide style using a more formal basis, largely In Shaw and Garlan (1996) examples are pro- a more formal basis for these concepts. using the Z formal description language, vided of specifications that are represented n n n benefit of making explicit many of the issues that For our purposes, this scheme has the of this and later chapters. So, in the next sub- we should be considering in the context n n Finally, the Finally, SDC06 9/18/07 10:50 AM Page 113 AM Page 10:50 9/18/07 SDC06 pr Print out the selected files in suitable format Files grep that meet the ‘Select’ those required pattern e architectural styles e architectural Pipe that occurs within some form of network. Indeed, that occurs within some form of network. 1s Filter dataflow List the files in sorted order in the directory 1; + The pipe-and-filter style: Unix processes. count = In a pipe and filter architectural style, the components are typically processes that In a pipe and filter architectural style, The descriptions provided in the rest of this section are of necessity brief ones, and in the rest of this section are The descriptions provided count stream chronous manner. A widely-cited example is the ‘classical’ approach to compiler design, chronous manner. A widely-cited example to gradually transform the source code into in which a series of operations are performed such as a lexer or parser, acts as a filter, trans- some form of binary code. Each element, the form required by the next stage. For exam- forming a stream of input tokens into and splits this into the ‘lexemes’ or groups ple, the lexer inputs a stream of characters context of the program. So the input expression of characters that have meaning in the although the Unix variant is essentially linear, many non-linear topological forms although the Unix variant is essentially described in Simpson and Jackson (1979). exist, such as the MASCOT approach 6.1 and 6.2. Examples of these are shown in Figures an output stream (the ‘filters’), connected together transform an input data stream into which may occur in a synchronous or asyn- by some form of dataflow mechanism, involved, we will look at three examples of widely encountered architectural styles. at three examples of widely encountered involved, we will look 1. filter Pipe and within the architecture the 1970s onwards has been embodied This style (which from one based upon the transformations that of the Unix operating system) is essentially are centred around the sarily be consistent with the original style – which should not be taken to imply that with the original style – which should sarily be consistent presence of ‘hybrids’ does not a mismatch.) As with buildings, the there is necessarily of classification any less useful. render the basic idea a specialized source such of these issues the reader should consult for fuller discussion To illustrate the concepts (1996) or Shaw and Clements (1997). as Shaw and Garlan 6.2.3 softwar of some Examples (and which is firmly right at the outset need to be made that does One qualification in necessarily ‘pure’ systems are not (1997) is that real and Clements made in Shaw than of more possess the characteristics style, and so may their architectural terms of may Buildings we see in other domains. with what (This is not inconsistent one style. may not neces- of time, and the changes with the passage and extended well be altered Figure 6.1 Input data

Transferring design knowledge 114 SDC06 9/18/07 10:50 AM Page 114 AM Page 10:50 9/18/07 SDC06 The architecture concept 115 due to the emphasis function ’, ‘1’, ‘;’ regardless of the + ’, ‘count’, ‘ = input to a process. Upstream processes have no control of this. input to a process. Upstream processes have through the transfer of data. method such as JSP placed upon the filters (components). A design (Chapter 14) may generate this style of solution. The pipe-and-filter style: MASCOT diagram. The pipe-and-filter architectural style Table 6.2 provides a brief summary of this style using the general classification More complex forms of this style (such as that used in the MASCOT system cited More complex forms of this style (such Data communicationControl/data interaction share the same topology and control is achieved Control and data generally Data is generally passed with control. Design reasoning Tends to employ a ‘bottom-up’ approach using FeatureComponentsConnectorsControl of executiontransferred by the arrival of data at the Typically asynchronous, control is Data transformation processes. Instantiation in pipe and filter mechanisms (e.g. Unix pipes, files, etc.). Data transfer ment to another underpins this style. Unlike the more data-driven ‘pipe-and-filter’ style, ment to another underpins this style. Unlike the more data-driven ‘pipe-and-filter’ of other which is essentially non-hierarchical (filters have no control over the actions scheme adopted in Shaw and Clements (1997) described in the preceding sub-section. scheme adopted in Shaw and Clements (1997) described in the preceding 2. Call and return ele- The concept of an ordered and hierarchical transfer of control from one processing will be output as the stream of lexemes: ‘count’, ‘ will be output as the stream of lexemes: or tab characters. presence or absence of intervening space dataflow control, including allowing for the earlier) may incorporate more complex and, where appropriate, having mechanisms to retention of data, its synchronization it is time-expired and not yet processed. allow data to be over-written where Table 6.2 Figure 6.2 SDC06 9/18/07 10:50 AM Page 115 AM Page 10:50 9/18/07 SDC06 object- . A design function output results main process data architectural forms, and some of these will be discussed in algorithms in the components. access). within the ‘calling stack’. Design will method such as the ‘traditional’ Structured Analysis/Structured 13). produce solutions that employ this style (Chapter input data event-driven The call-and-return style: subprogram invocation. style: subprogram The call-and-return The call-and-return architectural style The call-and-return architectural and There are obviously many other styles, of which good examples include There are obviously many other styles, of which good examples include In the case of a database system, the central mechanism is generally concerned Control of executionData communication (in detail) the through the calling hierarchy and Sequencing is controlled Control/data interaction directly (global Data is passed via parameters and can also be accessed beyond the linking of parameters and return inform This is relatively limited, Design reasoning Encourages use of a ‘top-down’ strategy, based upon FeatureComponentsConnectors Subprogram units. in call and return Instantiation invocation (calling). Subprogram summary of this architectural style. oriented vides an illustration of the general form of a client–server system. of data. with providing some form of indexed access to a (potentially) large volume this, with the Blackboard systems can be regarded as rather more ‘freestyle’ variants on control and data now being representative of some form of ‘knowledge’ and with the provides a sequencing of any updates being much less tightly controlled. Table 6.4 This style describes systems in which the key element is some central mechanism used This style describes systems in which which can then be manipulated independently for the persistent storage of information units. Examples that embody such a style are by some arbitrary number of processing systems. Shaw and Clements (1997) also database systems and blackboard expert into this general category, on the basis that the argue that client–server forms come often incorporates a database. Figure 6.4 pro- server acts as a repository and, indeed, illustrated in Figure 6.3. The main program (which itself is really a top-level subpro- illustrated in Figure 6.3. The main program system) may well perform no role other than gram when viewed from the operating subprograms that perform the actual processing that of controlling and sequencing the features of this style. tasks. Table 6.3 summarizes the main 3. Data-centred repository filters), the call-and-return style places much greater emphasis upon control aspects filters), the call-and-return style places A call-and-return style is therefore closely linked rather than upon data transfer issues. form of ‘main program’ and ‘subprograms’ as to the traditional program structuring Table 6.3 Figure 6.3

Transferring design knowledge 116 SDC06 9/18/07 10:50 AM Page 116 AM Page 10:50 9/18/07 SDC06 The architecture concept 117 Database Server software Application concept in knowledge transfer in knowledge concept

Network viewpoint is obviously relevant for database and data modelling highly synchronized, whereas in the case of a blackboard there may be little highly synchronized, whereas in the case of a or no interaction. that occurs in this style client–server systems. The wider variation of detail procedural design approaches. tends to preclude the widespread use of more The data-centred repository style: simple client–server system. The data-centred repository style: simple The data-centred repository architectural style ‘Thin’ client Browser Design reasoning A ComponentsConnectorsControl of executionData communicationControl/data interaction and may also occur in parallel. Operations are usually asynchronous Storage mechanisms and processing units. a database or a client–server system, these may be Varies quite widely. For mechanism. Data is usually passed via some form of parameter queries, direct access (blackboard). Transactions, Feature Instantiation in data-centred repositories Figure 6.4 by Garlan and Perry (1995) and were reviewed in Section 6.2.1. Taking a slightly nar- by Garlan and Perry (1995) and were reviewed in Section 6.2.1. Taking a this book, we rower focus, in terms of the issues that are more directly the concern of can identify the following key roles. illustrate the basic concepts. 6.2.4 of the architectural The role in terms of At this stage, the obvious question is: ‘what role do these ideas perform suggested the task of designing software?’ A number of answers to this question were later chapters on design practices. However, the above three offer good examples that later chapters on design practices. However, Table 6.4 SDC06 9/18/07 10:50 AM Page 117 AM Page 10:50 9/18/07 SDC06 form of how to . An important . An procedural description . One of the consequences of choosing . One of the consequences to generate design solutions. We will not be describ- . An important element in successfully updating an . An important element how A design method can be regarded as providing a (what Perry and Garlan refer to as ‘evolution’). Changes that preserve the overall (what Perry and Garlan refer to as ‘evolution’). to be more successful and to leave scope for architectural integrity are likely both many design tasks occur within a larger oper- further changes in the future. Since a valuable aid to identifying such constraints ational context, these concepts provide of a system. and hence to preserving the structure example, choosing a call-and-return style would suggest that we might begin by a call-and-return style would suggest example, choosing to use a transaction- of the overall system, or choosing considering the functionality about the data forms suggest that we should begin by thinking centred form may involved. changes Assisting with later ideas and intentions of the original designer(s) existing system is to understand the Determining the choice of design strategy Determining the choice need to find some way of for a solution is that we then an architectural form described in the rest of this whether it is by using the forms achieving that solution, both the strategy and ‘formal’ means. Choice of a style affects chapter, or by less the eventual solution. For used to support it and describe the choice of notations Providing a framework and vocabulary for top-level design ideas design for top-level and vocabulary a framework Providing a sys- of (architecture) form the overall what to determine is in designing element a as a pipeline; processes connected to use a set of be. Is the best choice tem is to Sometimes a centralized database? elements; or of distributed processing network always the case. but this is not by context, is more or less pre-determined this choice the overall form of for deciding on both a framework therefore provide These ideas for discussion. to others and hence for describing it and a vocabulary a solution, method describes the tasks that the designer is to perform and the order in which they method describes the tasks that the designer is to perform and the order cannot should be performed. However, since design is a creative process, a method codifying knowledge about in the rest ing design methods in any real detail, since we have much fuller descriptions knowledge, of this book. Our only real concern here is with their role in transferring or rather with the detailed forms used to do this. That is, a set about the task of producing a design solution for a given problem. previous subsections. 6.3 methods Design a means of codifying knowledge about the The preceding section has described discuss the role of design methods in terms of of a design solution. In this section we chapters. Like so many of the elements that make up the software design context, the chapters. Like so many of the elements style lies in this ability to describe the broad major value of the concept of architectural on detailed classification may risk being picture, and placing too much emphasis of this concept will therefore be for describing counter-productive. Most of our use design forms, although occasionally we may need high-level characteristics of different detailed characteristics that were described in the to be specific about some of the more This section has introduced some important ideas that will be employed in the later This section has introduced some important n n n

Transferring design knowledge 118 SDC06 9/18/07 10:50 AM Page 118 AM Page 10:50 9/18/07 SDC06 Design methods 119 know- transferring . (In fairness, software product is not one that is confined to software, as demon- that is confined to is not one methods , 1995). This suggests that once some degree of knowledge about of software (Brooks, 1987) has made it necessary to create artificial of software (Brooks, 1987) has made et al. will ensure the production of a sound design will ensure the production of a sound invisibility Studies of experienced designers have tended to suggest that they are only likely to Studies of experienced designers have While the idea of design While the methods. The design notations) and the design method frameworks for its description (including framework, providing both an explanation of has become an integral part of that and deployed and also a vocabulary for how these abstract forms can be developed doing so. coped with this, and the design method has provided one of the ways in which the design method has provided coped with this, and of people with design could be conveyed to large numbers design knowledge responsibilities. meant that some means of in software technology have also Rapid developments has also been needed if practitioners are providing peer-to-peer knowledge transfer role has been partly filled by the use of design to be kept informed, and again this The rapid development of the computing industry since the 1960s has led to a drast- of the computing industry since The rapid development over the past 30 years. for design and development skills ically escalating need knowledge could not have mechanisms for transferring Traditional master/pupil valuable, supporting the view that methods are more a means of (say) a transaction processing system for a bank and hence might employ a design (say) a transaction processing system for a bank and hence might employ compiler. method for this, when they would certainly not do so in developing a new given method Similarly, studies of method use also suggest that few designers follow a in varying completely, and that they tend to use experience to adapt the procedures degrees (Hardy becomes less how to design has been acquired, the framework offered by a method design method developers do not necessarily make this claim, but of course it is implic- design method developers do not necessarily to adopt a method that was thought to result itly assumed. No-one would be expected in poor design solutions!) they do not feel confident about their ‘domain follow design method practices where 1985; Guindon, 1990; Visser 1987). In other knowledge’ (Adelson and Soloway, might feel less confident when asked to design words, an expert in designing compilers ledge than of generating specific solutions. Through its procedures and notations, a design method implicitly produces a design Through its procedures and notations, architectural style. This leads to one other obser- solution that embodies a particular design methods play in the software domain. vation about the rather unique role that same expectation that following a given design In no other domain is there quite the process n n cess than is commonly adopted with software.) Why this should be so must remain adopted with software.) Why cess than is commonly of reasons. conjecture, but we can suggest a number partly a matter for n provide actual guidance about exactly how each task should be performed for any be performed task should each exactly how about guidance actual provide problem. specific and more detailed are generally much design methods Jones (1970), software strated in pro- example of this is (Another arise in other domains. than those which prescriptive a (1996), which takes by Pahl and Beitz design text the ‘classical’ engineering vided by pro- about the design to teaching prescriptive approach and much less quite different SDC06 9/18/07 10:50 AM Page 119 AM Page 10:50 9/18/07 SDC06 . While design patterns are not design pattern , 1977), who describes it in the following words: et al. of producing a design solution, but also retain a strong element of product of producing a design solution, but The concept of the design pattern is very much associated with the object-oriented The concept of the design pattern is very in the work of the architect Christopher The concept of the design pattern is rooted Having looked at how knowledge about design is transferred through the concepts Having looked at how knowledge about While the above arguments should not be seen as a claim that ‘design methods are should not be seen as a claim While the above arguments One other question is why the development of new design methods enjoyed methods new design of development why the is other question One ‘Each pattern describes a problem which occurs over and over again in our envir- ‘Each pattern describes a problem which occurs over and over again in a way onment, and then describes the core of the solution to that problem, in such the same that you can use this solution a million times over, without ever doing it way twice.’ Alexander (Alexander architectural style, although in principle there are no reasons why patterns could not architectural style, although in principle extent, this reinforces the arguments of the be employed with other styles. To some architectural style is one that has necessitated preceding section: the object-oriented hence less accessible) design methods, leading to the use of much more complex (and such designs. a search to find alternative ways of developing 6.4 patterns Design design patterns is a topic that we will be address- The detailed form and application of So, as with design methods in the preceding sec- ing much more fully in Chapter 10. to consider design patterns in the context of their tion, our main concern here will be transfer. role as a mechanism for knowledge of architectural styles and the practices of design methods, we now look at one of the of architectural styles and the practices other developments of the 1990s, the of methods in that they are concerned with the procedural, they share some of the role processes modelling. design knowledge and, indeed, in reading the later chapters of this book, we need to and, indeed, in reading the later chapters design knowledge at the beginning of this chap- In terms of the roles that we identified keep this in mind. to play a useful role in transfer- while design methods continue ter, it is probable that, terms of peer-to-peer exchange the novice designer, their value in ring knowledge to has been reduced. of the procedural steps is likely to require greater maturity of design thinking. In other is likely to require greater maturity of the procedural steps are those who probably able to use such methods effectively words, the only people procedures, or whose need is expertise not to need the detailed already have sufficient expertise to a new architectural style. mainly to adapt their of usefulness in transferring that there are limits to their degree dead!’, they do suggest greater popularity and importance during the 1970s and 1980s, whereas, since the 1980s, whereas, and the 1970s during importance and popularity greater the software engineer- role, at least in a less prominent they have played early 1990s, one possible reason for conjecture, but partly a matter Again, this is ing literature. is the increasing in the community) of design expertise a growing maturity (apart from to that this also leads argued elsewhere We have of software structures. complexity each 1999), in which 1995; Budgen, methods (Budgen, complexity of design increasing

Transferring design knowledge 120 SDC06 9/18/07 10:50 AM Page 120 AM Page 10:50 9/18/07 SDC06 Design patterns 121 , (1995), et al. has been explored (Coplien, 1997) and, at idiom , 2001). While not conclusive (few et al. architectural design pattern as architectural patterns and, as such, they also extend the (1996). The latter authors look upon many of the architectural (1995). et al. pipe and filter et al. The design pattern concept is not restricted to use in ‘detailed design’ activities. At The design pattern concept is not restricted to use in ‘detailed design’ activities. As with design methods, one question that we need to ask is whether the use of As with design methods, one question Patterns are of course no more of a panacea than any other approach that we Patterns are of course no more of a In some ways, the idea of the pattern comes much closer to embodying the tradi- idea of the pattern comes much closer In some ways, the Essentially, a pattern is a generic solution to a problem, which itself is likely a problem, which generic solution to a pattern is a Essentially, pattern concept beyond a purely object-oriented context. the programming level it is generally referred to as an the architectural level, the concept of an in Buschmann styles such as patterns will lead to ‘good’ solutions. While the process of pattern use does not seem patterns will lead to ‘good’ solutions. experimental findings regarding how maintain- to have been studied, there are some (Prechelt able the end product is likely to be certainly indicate that design patterns can be empirical studies ever are!), these findings a consistent style, especially in terms of enabling used to produce solutions that have future change. bering the relevant bits of knowledge. (We might note that in Gamma bering the relevant bits of knowledge. of 23 design patterns. In other words, they keep the authors concentrate on a catalogue which is perhaps one good reason for its wide their vocabulary to a manageable limit, few design problems present features that are acceptance.) That said, of course, very such, the pattern concept does recognize and entirely new and original and so, as knowledge. embody a useful level of reuse of design ‘label’ a sub-problem that they knew how to solve, leaving them free to concentrate on ‘label’ a sub-problem that they knew the less familiar aspects of a problem. the transfer of design knowledge. Indeed, the might choose to adopt for organizing limitations: to be successful, patterns need to very mechanism itself effectively imposes which in turn suggests that too large a set of be readily accessible and recognizable, presenting problems for indexing and remem- patterns is likely to be unmanageable, important part of learning about design, if generally much more difficult to achieve! learning about design, if generally much important part of exchange of design have a role in terms of providing peer-to-peer Patterns can also through the use of methods. smaller ‘chunks’ than can be achieved knowledge in much of designers. One of the matches some of the observed practices The pattern idea also in Adelson and Soloway design behaviour that was observed characteristics of expert for plans’, where a designer would recognize and (1985) was the employment of ‘labels about the possible consequences that might need to be considered when performing consequences that might need to be about the possible design trade-off decisions). and expertise than design model for transferring knowledge tional master/apprentice on ‘teaching’ about solutions, achieve. Methods also concentrate methods can possibly of these is an equally about problems too, and the recognition while patterns educate This concept has been taken up for software (or, more specifically, for object-oriented for specifically, (or, more for software taken up been concept has This the book being the topic work on the core with community’, ‘pattern by the software) by Gamma transfer, there- In terms of knowledge of a bigger problem. to be a part (almost certain) a designer might problem that about a particular information fore, it conveys (as well as some notes that problem for addressing together with a strategy encounter, SDC06 9/18/07 10:50 AM Page 121 AM Page 10:50 9/18/07 SDC06 interpretation, based largely upon experience. interpretation, based personal A simple model contrasting expert and novice design contexts. (1988) that expert designers are not necessarily good programmers, we are left to designers are not necessarily good programmers, (1988) that expert This model is not inconsistent with some of the other observations made by This model is not inconsistent with Our starting point is some of the earliest studies of how people actually design is some of the earliest studies of how Our starting point the inexperienced designer lacks this intermediate level of thinking, and can easily the inexperienced designer lacks this an undue degree of detail about implementation. become entangled in consideration of Figure 6.5 shows this schematically. Concepts such as ‘labels for plans’ can Adelson and Soloway and by other researchers. knowledge’ that a designer brings to be considered as being part of this ‘underpinning methods (and, to some degree, of design patterns a task. So one of the roles of design how well a design would meet its purposes. If to this we add the observation in Curtis would meet its purposes. If to this we how well a design et al. designer is the ability to of the characteristics of the experienced conclude that one In other words, the experi- intermediate level of ‘mental model’. form and use some of their design elements without needing to enced designer uses a set of abstractions In contrast (as many teachers will know), think about how these will be implemented. personal interpretation of how these ideas complement each other. While the interpre- each other. these ideas complement interpretation of how personal number of academic studies, it upon the observations from a tation provided draws study, hence the emphasis subjected to either analysis or empirical has not itself been on it being a Soloway (1985) was that ex- observation of Adelson and software. One particular to explore their ideas about would ‘execute’ their designs in order perienced designers 6.5 interpretation? A unified a terms of providing material in some very important has introduced This chapter are design practices in which software of the ways for our understanding framework wood for the trees’ difficult to ‘see the it can become However, as always, organized. to provide a rather section is intended This short with so many concepts. when faced Figure 6.5

Transferring design knowledge 122 SDC06 9/18/07 10:50 AM Page 122 AM Page 10:50 9/18/07 SDC06 A unified interpretation? 123 An extended model describing an expert’s design context. An extended model describing an expert’s The detailed form of any particular intermediate model is almost certainly a very The detailed form of any particular how the ‘underpinning knowledge’ is devel- One question that this leaves is just If we pursue this further, we can note that where designers tackle unfamiliar tasks, If we pursue this further, we can note Figure 6.6 to some degree. Such questions are, of course, almost impossible to answer. Certainly most of us would Such questions are, of course, almost impossible to answer. Certainly most of its general accept that the task of designing software does require an understanding it. The properties, of what is possible, and of what are the ‘good’ ways of deploying knowledge is observations of Curtis and his co-workers also suggest that, while such This necessary, a high degree of programming expertise may actually be a distraction. at least underpinning knowledge will also be linked to particular architectural styles, personal one, and this is not itself the object of our attention in the rest of this book. personal one, and this is not itself the in which a designer develops the ability to form Rather, our concern is with the ways and, where appropriate, to express their ideas and employ such intermediate models using particular notations. a designer need to know about implementation? oped. In other words, how much does a method). So this suggests that there are likely to be potentially many forms of inter- a method). So this suggests that there corresponds to a particular architectural mediate model, where each form loosely in using the object-oriented paradigm might feel style. A designer who is an expert for a transaction-based architectural style less confident about developing a solution model. Figure 6.6 extends the original concept because of this lack of an intermediate this possibility. as described in Figure 6.5 to include too) is to help the inexperienced designer develop such intermediate models of their too) is to help the inexperienced designer ideas. such a model (and hence may revert to using they may well have problems in building SDC06 9/18/07 10:50 AM Page 123 AM Page 10:50 9/18/07 SDC06 (1), 43–52 14 can be recognised in many domains. Identify some examples , Software Architecture: Perspectives on an Emerging Discipline. Software Architecture: Perspectives on an IEEE Software architectural style A specific feature of this book is that, for just such reasons, no code-based exam- no code-based reasons, just such that, for book is of this feature A specific (c) publications; of architectural styles and their principal characteristics, for the following domains: (a) ships; (b) motor vehicles; the rationale for using design patterns and their ability to describe the core features of the rationale for using design patterns reusable design solutions. behind such knowledge; and a vocabulary for of architectural style in providing a framework the role of the concept strategy; and for assisting with the choice of design top-level design ideas, practices and strategies; the use of design methods to codify design the reasons for transferring design knowledge, and (where known) for codifying the rationale design knowledge, and (where known) the reasons for transferring Prentice-Hall terns, and objects. Exercises Further reading Summary 6.1 The concept of This is the definitive reference text for the subject of software architecture. Although in terms of This is the definitive reference text for the fragmented, it contains a wide set of examples and developing the theme its structure is rather illustrates all of the key ideas. Monroe R.T., Kompanek A., Melton R. and Garlan D. (1997). Architectural styles, design pat- Monroe R.T., Kompanek A., Melton R. many of the concepts discussed in this chapter and A very readable paper that draws together as their strengths and limitations, with some simple explores their capabilities and roles, as well examples for illustration. Shaw M. and Garlan D. (1996). n n n This chapter has examined some of the principal ways in which software design knowledge and some of the principal ways in which This chapter has examined here have included: and transferred. Particular issues addressed expertise can be codified n ples have been used to illustrate points. The assumption throughout has been, and will has been, throughout assumption points. The illustrate used to been ples have that and of the basics of programming, understanding reader has a basic be, that the to of how developing an understanding help further with this book is to the role of models’. employ these ‘intermediate form and

Transferring design knowledge 124 SDC06 9/18/07 10:50 AM Page 124 AM Page 10:50 9/18/07 SDC06 Exercises 125 particular printer. hockey, cricket, etc.). hockey, cricket, based upon analogies with the practices of any other disciplines that also involve significant with the practices of any other disciplines based upon analogies elements of design activity. the architectural styles that are likely to be most appropriate: the architectural styles (a)auto-teller machine; a bank (b) used to analyse static files of text; a spell-checker (c) employed by a ‘raw text’ into the page description language a program that reformats (d) (tennis, as a sport a topic such about information pages of static containing websites and Garlan (1996) of this in Shaw good illustration of a problem usually features ), there are constraints. For the absence of any other style in the the choice of a particular that encourage features and identify to be their major what you consider of system, identify following types 6.3 for software, might be used to codify design knowledge Identify any other mechanisms that 6.2 is a styles (there using a range of architectural be implemented While many systems can SDC06 9/18/07 10:50 AM Page 125 AM Page 10:50 9/18/07 SDC06 SDC06 9/18/07 10:50 AM Page 126 SDC07 9/18/07 10:53 AM Page 127

chapter 7 127 Some Design Representations

7.1 A problem of selection 7.3 White box notations 7.2 Black box notations 7.4 Developing a diagram

The abstract nature of software means that it lacks any readily visualis- able images. This chapter reviews and describes a selection of the forms that are adopted for describing the properties of software. We begin by reviewing the choice of examples and then go on to discuss each one: identifying its form, and the role(s) that it generally plays in the design process. For convenience, these example forms have been loosely grouped into two sets: the ‘black box’ forms that are used to describe what a system does, and the ‘white box’ forms that are concerned with describing how it is to do it. Finally, we briefly examine some of the ways of checking and developing diagrams. , in terms of the ideas described in Chapter 5, where we considered con- described in Chapter 5, where we , in terms of the ideas , including textual and diagrammatical forms of notation; , including textual , in terms of the form’s role during the phases of design, the type of problem We should also note that some of these notations may well be known under more We should also note that some of these notations may well be known under These are not the only forms of representation that will be met in this book, since These are not the only forms of representation Descriptive forms, such as those reviewed in this chapter, are not particularly Descriptive forms, such as those reviewed The selection is not exhaustive, nor is it likely to meet with universal agreement. The selection is not exhaustive, nor Chapter 5 provided a framework for describing the roles and forms of represen- a framework for describing the roles Chapter 5 provided form viewpoint viewpoints; functional and data-modelling structional, behavioural, use and the extent to which it is used. domain in which it might be appropriate, of this, with different names for each role and method.) Where possible, the most of this, with different names for each role and method.) Where possible, generic or widely adopted name has been employed here. enough significance to be introduced in advance of the description of the techniques enough significance to be introduced in advance of the description of the on the design for their use. Tables 7.1 and 7.2 provide a summary of the viewpoints of the design model that each of these forms can provide, and list the characteristics that can be captured through its use. example than one name. (Michael Jackson’s Structure Diagram is a particularly good the aid of pencil and paper alone. In Chapter 5, we identified this as an important the aid of pencil and paper alone. In should meet, and hence it has been used as one criterion that any diagrammatical form of the selection criteria for this chapter. when specific methods are reviewed. (In particu- further examples will be encountered have been deferred until they can be shown lar, the examples of mathematical forms discussed in this chapter are considered to be of in a fuller context.) However, the ones amenable to being neatly classified and categorized, not least because some forms play amenable to being neatly classified and However, the idea of ‘black box’ and ‘white box’ multiple roles in the design process. to ‘what’ and ‘how’ respectively), has been descriptions (roughly corresponding of the roles that a given notation can per- adopted here as providing a useful indication are ones that can be easily produced with form. In addition, all of the forms described (Remember too that some notations used for software design may well have originated (Remember too that some notations cases, even before the invention of computers!) with quite different purposes – in some the activity of design is a creative process, and As emphasized throughout this book, subject to personal preference when it comes hence the forms that go with it are also to a question of use. n n n as wide a spectrum as possible. as wide a For this chapter, which looks general classifications for these. tations, and gave some been made so as to range across the selection from these forms has at specific examples, the spectrum of: 7.1selection of A problem that forms many design representation from the examines a selection This chapter representation forms, very many such methods. There are software design are used in a than producing forms, and rather of the more popular variants on some as well as give chosen to a fairly small sample, focuses upon list’ of these, this chapter ‘laundry

Some design representations 128 SDC07 9/18/07 10:53 AM Page 128 AM Page 10:53 9/18/07 SDC07 Black box notations 129 notation is one that is it is to do it. We can also how black box relationships between elements, interfaces activities Design characteristics on flow, dependency of operations Information stores relation with data other operations, entities between design Static relationships an entity State-machine model of including parallelism System-wide state model, and abstraction (orthogonality), hierarchy (operations, data, Form of sequencing adopted actions) and objects Interactions between classes system and other ‘actors’ Interactions between a of system Synchronization and coordination Design characteristics Invocation hierarchy between subprograms, decomposition into subprogram units Uses and dependencies Message-passing sequences, interaction protocols Algorithm form properties of the elements of a design model. That is, it is Functional and constructional Constructional Behavioural Functional Viewpoints Functional, data modelling, behavioural Constructional Behavioural and functional Behavioural and functional Viewpoints Functional Data modelling Behavioural Behavioural an element will do, rather than external what The selection of white box design representations The selection of black box design representations box design of black The selection Our choice of forms is a mixed one, in terms both of historical and technological A final point that follows on the one that was made in the previous paragraph: the A final point that follows on the one Sequence Diagrams Pseudocode Representation form Structure Chart Class and Object Diagrams UML: Use Case Diagram UML: Activity Diagram State Transition Diagram Statechart Structure Diagram (Jackson) UML: Class Diagram Representation form Representation Data-Flow Diagram Diagram Entity–Relationship To remind ourselves of the discussion in Chapter 2: a level of detail provided in the descriptions of the following sections is not intended to level of detail provided in the descriptions that will be used in the later chapters be consistent. In particular, those notations described in such complete detail as others, since on design methods are not normally provided in the relevant chapters. further examples of their use will be 7.2 notations box Black Table 7.2 Table 7.1 Table factors. We begin with the Data-Flow Diagram (DFD), a form which is generally factors. We begin with the Data-Flow Diagram (DFD), a form which concerned with the used to describe used to help consider such forms as performing the role of ‘external memory devices’, 1994). increase the limited capacity of human working memory (Vessey and Conger, SDC07 9/18/07 10:53 AM Page 129 AM Page 10:53 9/18/07 SDC07 Structured . In the same spirit, the simple flow , 1999). process et al. , he gives an example of an informal flow diagram , he gives an example of an informal The DFD has been widely used for software design purposes over many years, and The DFD has been widely used for software design purposes over many years, Even this simple example is sufficient to show one of the strengths of the DFD Even this simple example is sufficient The general nature of the DFD concept has been shown very effectively through The general nature of the DFD concept The use of some form of DFD for describing the operation of complex systems of DFD for describing the operation The use of some form tion and performs a somewhat different role in the design process, is that used by the tion and performs a somewhat different role in the design process, is that 1992). Structured Systems Analysis and Design Method (SSADM) (Longworth, much greater complexity than this simple example. DFDs are a number of variations in the exact forms of the symbols used for drawing the form that to be found in the literature. This chapter will concentrate on describing since Chapter has been popularized through the work of De Marco (1978) and others, nota- 13 will be making use of this. Another example form, which uses a more ‘formal’ when used to describe a sequence of operations, namely that one can readily see the when used to describe a sequence of glance. For example, if we take operation 5, ‘fit prerequisites for any operation at a dependent upon having the completed results of door to walls’, we can see that it is can see why. Sequential lists of actions may be operations 3 and 4 available, and we but the dependency aspect, which is so easily able to convey the same information, is generally less clear in such forms. The benefits visualized through the use of a DFD, more important for operations that involve of this ready visualization become even flow’ in this case is physical (consisting of subassemblies), the principle is the same as flow’ in this case is physical (consisting an excellent demonstration of the effectiveness for software, and the example provides a of such a form when it is used to describe form can be used to describe the assembly of a diagram in Figure 7.1 shows how this garden shed. it is likely to have originated in a number of places and times, all quite independently. it is likely to have originated in a number (although admittedly this one is largely folklore) The earliest reference that he can find dates from the 1920s. (1978). In the introduction to his book an example used by Tom De Marco Analysis and System Specification for a kayak. While obviously the ‘data being used to clarify the assembly instructions The DFD is mainly used for describing a very problem-oriented view of the workings used for describing a very problem-oriented The DFD is mainly the flow of information a description based on modelling of a system. It provides making use of or modi- of operational elements, with each element around a network flowing into that element. fying the information era, and Page-Jones (1988) has suggested that almost certainly predates the computer less explicitly related to any one viewpoint. Finally, we examine the recent develop- to any one viewpoint. Finally, we less explicitly related examine some representative Modeling Language (UML), and ment of the Unified this (Rumbaugh black box forms from 7.2.1 Diagram The Data-Flow considered to have been employed for system modelling well before the computer era the computer before well modelling for system employed have been to considered The style. architectural important to an related course, strongly is, of and which began architectural related to an important (ERD) is again Diagram Entity–Relationship two then consider forms). We one (transaction-based a very different style, albeit with Statechart, each (STD) and the Transition Diagram forms, the State behavioural offers a quite Structure Diagram limitations. The Jackson strengths and its particular ‘structure’ and hence concerned with notation: being more example of such a different

Some design representations 130 SDC07 9/18/07 10:53 AM Page 130 AM Page 10:53 9/18/07 SDC07 Black box notations 131 A flow diagram providing instructions for the assembly of a simple garden shed. A flow diagram providing instructions for Figure 7.2 shows an example of the use of a DFD to describe the operation of a bank Figure 7.2 shows an example of the use of a DFD to describe the operation autoteller (cashpoint) system. The four basic elements that are used in the diagram are: autoteller (cashpoint) system. The four basic elements that are used in the The form of the DFD symbols. The DFD is a graphical representation, and it makes use of only four basic it is Because of its highly abstract nature, in terms of the level of description provided, – at a time chiefly used during the early design stages that are often termed ‘analysis’ when the designer is likely to be making major architectural design decisions. Figure 7.1 SDC07 9/18/07 10:53 AM Page 131 AM Page 10:53 9/18/07 SDC07 domain problem , and as such it identifies the solution A top-level DFD describing the operations performed by a bank autoteller machine. A top-level DFD describing the operations So essentially this DFD provides a top-level ‘model’ of how the designer intends So essentially this DFD provides a top-level ‘model’ of how the designer To take an example from the operations described in Figure 7.2; the validation To take an example from the operations the parallel bars, used to denote a data store or file; the parallel bars, used to denote a data of information between the other three the arc, used to denote the flow components. the circle (or, as it is popularly termed, the bubble), which is used to denote an the circle (or, as it is popularly termed, description of the operation; operation, and is labelled with a brief source or sink of information; the box, used to denote an external (customer, PIN, transaction), rather than of the main architectural tasks for the autoteller system. (proceeding to the selection of the required transaction by the customer) or rejection (proceeding to the selection of the required transaction by the customer) given to pro- (which may involve returning or retaining the card). Even if permission is involved to ceed further with the transaction, there will be a further validation process ensure that the option selected is permitted for this customer. the autoteller to operate. It is expressed in terms that are part of the include denoting it by the use of a single bar or by an open-ended box.) include denoting it by the use of a single card, from the customer (in the form of operation requires inputs from the customer’s PIN) and from an internal directory. The first the personal identification number or the customer’s identity, while the third ensures two of these are used to authenticate a different financial institution) is acceptable to that the card (which may be issued by are then concerned with either acceptance the machine. The outputs from this process n n seems to vary in practice; other conventions (The form used to describe a data store Figure 7.2 n n

Some design representations 132 SDC07 9/18/07 10:53 AM Page 132 AM Page 10:53 9/18/07 SDC07 Black box notations 133 flow that is asso- control An expansion of one of the ‘bubbles’ from the top-level DFD for the bank autoteller An expansion of one of the ‘bubbles’ from In this example, the designer has elaborated on his or her ideas for the oper- In this example, the designer has elaborated on his or her ideas for An important characteristic of the DFD is that it can be expanded in a hierarch- An important characteristic of the DFD Figure 7.3 machine. of a bubble, its position within an expanded description of the system. by ation ‘Validate customer access’. Note particularly that in the operation represented bubble 1.3, there is no attempt to show the structure of the ical fashion, with the operation of any bubble being described by means of a further ical fashion, with the operation of any shows an expansion of bubble 1 of Figure 7.2, DFD. As an example of this, Figure 7.3 emphasizes the significance of the numbering using the same symbols. This also since the identity number indicates the ‘level’ scheme used for identifying the bubbles, forming this operation, and its details will need to be elaborated later, using other forming this operation, and its details will need to be elaborated later, forms for its description. ciated with the possible iteration required to permit the customer three attempts at ciated with the possible iteration required to permit the customer three in per- entering the PIN. The DFD is not concerned with the control logic involved SDC07 9/18/07 10:53 AM Page 133 AM Page 10:53 9/18/07 SDC07 rather than a computer-oriented solution. De rather than a computer-oriented solution. , in that they identify the operations that need to be , in that they identify problem functions DFD is used to model a system in terms of the physical entities con- DFD is used to model a system in terms physical Figure 7.5 shows the equivalent logical DFD, in which the bubbles are now Figure 7.5 shows the equivalent logical DFD, in which the bubbles The In this role, one of its benefits is that it can fairly easily be understood by the user, In this role, one of its benefits is that The point about abstraction is an important one when it comes to the conventions is an important one when The point about abstraction While expansion is valuable in allowing for the gradual refinement of a design, of a design, gradual refinement for the allowing in is valuable expansion While initial modelling tasks and with communication with the customer, while the logical initial modelling tasks and with communication with the customer, while model DFD is necessary when the designer begins to build up the architectural any detail. (For example, Roger clearly handles all arrangements concerning rail travel, any detail. (For example, Roger clearly handles all arrangements concerning although we can only conclude this by examining the data-flow arcs.) it. This is a labelled to show what is being done to the data, rather than who is doing 7.4, but is more abstract and more structured view of the system described in Figure helps with clearly derived from it. Both of these forms are important: the physical DFD since it is used to model the ‘logical’ and ‘physical’ DFDs, which it is Marco makes a distinction here between useful to consider. example, Figure 7.4 shows a physical DFD that cerned, rather than their functions. For booking system in a travel office. The labels on is used to model the workings of the who does a job, rather than describing the job in the bubbles in this diagram indicate Because of its abstract nature and ability to describe function, the DFD is widely used Because of its abstract nature and ability termed ‘analysis’). It is a major component for the initial modelling of systems (often Systems Analysis and Structured Design) of the widely used SSA/SD (Structured 13, and it is also used in the various derivat- approach, which is described in Chapter ives of this method. ment about whether the operations are to be performed sequentially or in parallel. The ment about whether the operations are operations (see Chapter 13), but the DFD convention is usually to assume sequential operations. Indeed, some design methods make can equally be used to describe parallel use of it in this way. Using the DFD to be performed, as well as that which is generated by them. well as that which is generated by to be performed, as 7.3 has already raised this when drawing such diagrams. Figure that should be used user is permitted when enter- describes the number of tries that the point: bubble 1.3 directly in any way. On this diagram does not show the iteration ing the PIN, but the the form of the diagram makes no state- same point about sequencing information, The DFD viewpoint the architecture of a are primarily concerned with describing Data-Flow Diagrams its system in terms of description. The data-flow ele- using an abstract level for the performed by the system, for the appropriate operations the information that is needed ment is used to identify it can also lead to problems of inconsistency: changes may be made to a lower-level be made may changes inconsistency: of to problems also lead it can flow arcs in the parent the information and/or form of alter the number diagram that of numbering (as well as automatic of such changes Consistency checking diagram. that are quite widely drawing tools by the specialist is generally provided bubbles) production of DFDs. to assist with the available

Some design representations 134 SDC07 9/18/07 10:53 AM Page 134 AM Page 10:53 9/18/07 SDC07 Black box notations 135 A ‘logical’ DFD describing a travel agency booking system. A ‘physical’ DFD describing a travel agency booking system. A ‘physical’ DFD describing a travel agency Figure 7.5 Figure 7.4 SDC07 9/18/07 10:53 AM Page 135 AM Page 10:53 9/18/07 SDC07 Entity– , 1992; Stevens, et al. has provided an essential foundation for the development of the foundation for the development has provided an essential is a class of elementary facts relating two or more entities; is a class of elementary facts relating are real-world objects with common properties; are real-world objects with common The basic Entity–Relationship notation. relationship Figure 7.6 shows the three principal symbols that are used in these diagrams, Figure 7.6 shows the three principal However, ERDs can play other roles apart from their use in database design. For play other roles apart from their However, ERDs can As mentioned earlier, other forms of DFD are used to help with more detailed used to help with forms of DFD are earlier, other As mentioned entities a to differ in detail.) These basic elements are defined as follows: to differ in detail.) These basic elements n n widely used forms seem to have been derived from the notation devised by Peter Chen widely used forms seem to have been on the more ‘generic’ elements of the (1976). This section will seek to concentrate detailed nuances of the form. notation, and will not explore the more symbols for entities and relationships are fairly together with their meanings. (The of attributes and other qualities are apt standard, but beyond that the representations system (Page-Jones, 1988; Stevens, 1991), while on a larger scale they can be used to system (Page-Jones, 1988; Stevens, 1991), more complex and abstract design ‘objects’ model the relationships that occur between (Booch, 1991). The Entity–Relationship notation exhibit ‘local’ variations, but most of the In their detailed form, many ERD notations static data objects in a problem model or a design model. In particular, the in a problem model or a design model. static data objects Relationship Model (Batini are used in many database systems relational models that 1991). model the detailed form of the data stored in a example, they are sometimes used to intuitive appeal to the DFD: it can be understood relatively easily, and can often be the DFD: it can be understood relatively intuitive appeal to description. than could many other forms of developed more easily 7.2.2 Diagram Entity–Relationship The relationships that exist between is principally used to capture the This form of diagram required in order to build the system. (In this case, the system will presumably be some will presumably the system this case, (In the system. to build in order required system.) reservation of automated sort This of this tool. the general usefulness that emphasizes of a design, a point modelling is terms of actions (as easy to think in it is often relatively the fact that in turn reflects place on providing languages that older programming by the emphasis demonstrated is therefore a strong structures). There rather than data describe actions forms that Figure 7.6

Some design representations 136 SDC07 9/18/07 10:53 AM Page 136 AM Page 10:53 9/18/07 SDC07 Black box notations 137 might later be ) and ‘many to n position might be connected by the might be connected teacher -ary’ properties. Binary relationships -ary’ properties. Binary and n .) , while the attribute , while the attribute ) student height m examines -ary property is to set bounds upon the cardinality of -ary property is to set bounds upon the , and n and ) held in library (of order 1) ) held in library (of n bearing , range ). Examples of these are: ). Examples of these ) having written books ( are classes of values that represent atomic properties of either entities or entities of either properties atomic represent values that of are classes attends-class-of n n An ERD showing a simple relationship between two classes of entity. to m The development of an ERD typically involves performing an analysis of speci- The development of an ERD typically Relationships are also classified by their ‘ Relationships are books (entity of order books (entity of order authors ( attributes attributes as can be seen more recognizable, entities are often the (attributes of relationships examples). from the Figure 7.7 shows an example of the ERD form being used for describing information about some shows an example of the ERD form the data structures that might be used in fairly recognizable entities, and so describes some form of indexing system. (In the latter case, an author may have written many books, and a book may have mul- (In the latter case, an author may have tiple authors.) The effect of the relationship. the values that are permitted by the the terms in these as entities, relationships fication or design documents, classifying the basis for developing an ERD. Figure 7.7 or attributes. The resulting list provides n n may be composite, with higher-level attributes being decomposed into lower-level with higher-level attributes being may be composite, the attributes attributes. (For example, relationships decomposed into n and involved, the level of abstraction of course, vary with of an entity will, The nature relationships between the nature of the of its attributes and will the form so, therefore, and attributes one type of relationship, by more than may be connected them. Entities ‘husband’ and ‘wife’. Relationships may also be ‘one to many’ (1 to Relationships may also be ‘one ‘husband’ and ‘wife’. link two entities, such as the relationship ‘married to’ occurring between the entities as the relationship ‘married to’ link two entities, such many’ ( SDC07 9/18/07 10:53 AM Page 137 AM Page 10:53 9/18/07 SDC07 An ERD relating some of the major entities in an air traffic control system. An ERD relating some of the major entities In contrast to this, Figure 7.8 offers an example of a more system- and design- In contrast to this, Figure 7.8 offers an example of a more system- and made earlier, concerning the possible existence of multiple relationships between two made earlier, concerning the possible existence of multiple relationships entities. Figure 7.8 in a basic air related use of the ERD form to model the entities that might be involved that was traffic control system. This figure also provides a simple illustration of a point

Some design representations 138 SDC07 9/18/07 10:53 AM Page 138 AM Page 10:53 9/18/07 SDC07 Black box notations 139 (pronounced ‘vee eye’) has two vi editor, in which the bubbles represent the states vi , in which keystrokes are interpreted as commands to the editor to , in which keystrokes are interpreted , in which any keystrokes are interpreted as data to be stored in the , 1992). This is a rather specialized area of system design, and as such has specialized area of system design, , 1992). This is a rather et al. As an example, the popular Unix screen editor As an example, the popular Unix screen A process executing in a computer fits this model quite well. Its ‘state’ at any point A process executing in a computer fits The data-modelling viewpoint is also used as a subsidiary viewpoint in a number viewpoint is also used as a subsidiary The data-modelling insert mode editor’s buffer. command mode a file, moving the position of the screen cursor, perform such operations as opening or beginning to insert text at some point; ition (namely, pressing the Escape key). Figure 7.9 shows a simple diagrammatical description of this model of the n com- Transitions occur between these modes according to certain forms of ‘escape’ between mand. There are many commands that can be used to make the transition reverse trans- command mode and insert mode, but only one that can be used for the basic states of operation, which are termed its current ‘modes’. These are: basic states of operation, which are n between the states. of the contents of its variables and the values of in time can be described fully in terms notably the program counter register, whose any associated registers in the CPU, most will be executed next. While we might not wish contents determine which instruction a process in terms of all its possible states, there to model the complete behaviour of can be considered. might be some useful supersets that 7.2.3 Diagram Transition The State can usefully be described by considering them Some classes of problem (and solution) can be considered as existing in a finite set of as ‘finite-state automata’. Such a system being the triggers that can lead to transitions possible ‘states’, with external events of design methods. One example in which it occupies such a role is the SSA/SD One example in which it occupies of design methods. described in Chapter 13: Analysis and Structured Design) method (Structured Systems SSADM, which uses a variant the ‘object’ forms of Chapter 15 and other examples are plays a relatively minor role in in this section. However, it of the notation described when compared with its central role in database the procedures of all these methods, design and development. ERDs are widely used for developing the schema used in relational database modelling for developing the schema used in ERDs are widely used (Batini probably fits somewhere in this book. (The design of databases not been addressed for producing compilers, and form of design that is widely used between the ‘template’ in this book.) systematic forms described later the more general-purpose The ERD viewpoint The of viewpoint a data-modelling concerned with providing purely and simply ERDs are the the analysis of be used both during they can As with many notations, a system. (design). of the solution and during the development problem ERD Use of the SDC07 9/18/07 10:53 AM Page 139 AM Page 10:53 9/18/07 SDC07 above text editor. vi has a rich set of commands for this vi can be considered as a substate of command mode. can be considered as a substate of command identifies the condition that will cause the transition to describes the actions that arise as a result of the transition is described by an arrow, and identifies a ‘legal’ change of state that is described by an arrow, and identifies represents an externally observable mode of behaviour, and is represented represents an externally observable mode A simple state-transitional description of the Unix A simple state-transitional Line command mode transition condition transition action transition state The form of this is a little more structured than that which was used in our first The form of this is a little more structured Figure 7.9 is a simple example of a form of STD (several conventions for these are Figure 7.9 is a simple example of a form The a specific (there may be several, and they might occur simultaneously, or in can occur within the system. The not con- occur – usually in terms of the event that causes the transition – but is cerned with the actual mechanism. It is written next to the transition arrow, a horizontal line. The its behaviour. by a box, with a text label that describes The n n example. There are four principal components to this representation of an STD. example. There are four principal components n n In Chapter 13, when we come to consider the extensions to SSA/SD, the Structured In Chapter 13, when we come to consider Method, we will encounter a number of Systems Analysis and Structured Design real-time systems. In the extension devised by extended methods that are aimed at a form of STD that will now be considered Ward and Mellor (1985), they introduced in a little more detail. in use), and it provides a convenient means for modelling many other systems too. in use), and it provides a convenient (or ‘reactive’) systems can often be usefully mod- Indeed, the general class of real-time nature leads readily to the use of such a form. elled in this way, since their event-driven The form of the STD (modes), and the arcs correspond to the transitions, labelled by the events (commands) correspond to the transitions, labelled (modes), and the arcs cause the editor to enter insert occur. (Not all the commands that that cause these to clarity, as mode are shown, in order to maintain purpose.) Figure 7.9

Some design representations 140 SDC07 9/18/07 10:53 AM Page 140 AM Page 10:53 9/18/07 SDC07 Black box notations 141 (which has initial state text editor can be modelled vi the horizontal line and the details of the trans- the horizontal line and the details of text editor using an STD (Ward and Mellor). text editor using an STD vi below (which will have transitions into it, but none out from it). (which will have transitions into it, but A description of the Unix A description of the Unix final state Figure 7.11 shows a rather more complicated system modelled in this way (com- Figure 7.11 shows a rather more complicated Figure 7.10 shows how the earlier example of the Figure 7.10 shows how the earlier example sequence). These are written ition conditions. Figure 7.10 an arrow pointing in to it, with no source state attached), and may (possibly) need to an arrow pointing in to it, with no source identify a possibility that particular transitions will occur, with no indication as to how these will possibility that particular transitions will occur, with no indication as to how be sequenced. The STD viewpoint behavioural The STD is our first example of a representation that is used to capture a of the viewpoint of a system, and so it is concerned with modelling dynamic attributes identifies the system in terms of entities such as states, events and conditions. It only plicated in the sense of having many more states). In this case, the system described is plicated in the sense of having many as a component of an air traffic control sys- the behaviour of an aeroplane modelled state to be entered is the primary radar detecting tem. The event that causes the initial The complexity of the transitions involved in this the aircraft as it enters the airspace. number of actions that the aircraft might take, example arises because of the sheer to being stacked before landing, and of com- from simply flying through the airspace, binations of such events. using this form of STD. Note that multiple transitions are still permitted between a using this form of STD. Note that multiple all possible transitions are shown, in order to given pair of states. (Once again, not action has been identified to determine when the avoid too complex a diagram.) An has been identified as the initial state when the editor terminates, and command mode editor begins operation. To complete the diagram, we also need to identify a default To complete the diagram, we also need SDC07 9/18/07 10:53 AM Page 141 AM Page 10:53 9/18/07 SDC07 editor has shown, if there are a lot of transitions vi An STD describing the behaviour of an aircraft in an air traffic control zone. An STD describing the behaviour of an aircraft The STD is a useful modelling tool, but as with all diagrammatical forms, it has The STD is a useful modelling tool, limitations. As the example of the Similarly, between a small number of states, the diagram can become very tangled. does not large and complex systems result in large and complex diagrams, as the form section we lead directly to any form of hierarchical layering of diagrams. In the next problem of describe another state-oriented form of description that overcomes the layering by adding a hierarchy to the states themselves. Use of the STD problem entities: although it can have a role A major role for the STD is in modelling is less significant. It is also particularly useful in in building models of solutions, this of a system, hence its popularity in real-time modelling some of the real-time needs variants of design methods. Figure 7.11

Some design representations 142 SDC07 9/18/07 10:54 AM Page 142 AM Page 10:54 9/18/07 SDC07 Black box notations 143 The elaboration of the description of a state is similar to the form used in the The elaboration of the description of a state is similar to the form used Figure 7.12 shows an example of the use of this notation, to describe the operation Figure 7.12 shows an example of the The Statechart shares a generality of role with the STD too. Both of these forms a generality of role with the STD The Statechart shares and their powers of description is provided By far the best tutorial on Statecharts The Statechart was devised by David Harel (1987; 1988) and he has observed that devised by David Harel (1987; 1988) The Statechart was Jackson Structure Diagram, described in the next section, in that the state ‘display’ is Jackson Structure Diagram, described in the next section, in that the state ‘display’ an abstraction of the three states ‘picture’, ‘text’ and ‘mixed’, so that selecting above ‘picture’ shows that this will be the default state, which will be entered when the above ‘picture’ shows that this will be the default state, which will be entered be used to set is switched to ‘display’ (an extension of this particular convention can remembers indicate when selection is made by means of some ‘history’ mechanism that be entered the previous use of these states). Note also that the state ‘mixed’ can only from ‘text’. of a Teletext television set. Figure 7.12(a) shows that the set has two states, ‘standby’ of a Teletext television set. Figure 7.12(a) ‘display’ and ‘standby’ occurs in response to the and ‘display’. The transition between the remote control. The reverse transition will operation of the ‘standby’ button on is pressed. In Figure 7.12(b) the description of occur when any button on the control and it is now elaborated into the three encap- the state ‘display’ is expanded further, ‘picture’, ‘text’ and ‘mixed’. The small arrow sulated states, which are labelled as In this notation, a state is denoted by a box with rounded corners, labelled in the upper In this notation, a state is denoted by by encapsulation, and directed arcs are used to left corner. Hierarchy is represented The arcs are also labelled with a description denote a transformation between states. parenthesized condition. (Conditions are quite of the event and, optionally, with a it might not be possible to engage a cruise con- common in real systems. For example, accelerating or braking.) trol mechanism in a car while either in Harel (1987), where the author uses the functions of the Citizen Quartz Multi- in Harel (1987), where the author examples. The examples below are rather less Alarm III watch as the basis for his some basic ideas about the scope of this particu- inspired, but should at least provide lar form of description. The form of the Statechart designer to describe transitions that are ‘orthogonal’ in that they are completely inde- transitions that are ‘orthogonal’ in designer to describe to occur in parallel. – so making it possible for the transitions pendent of each other as well as the functioning of a the structure of a problem, can be used for describing generally come from the former.) solution. (However, the better examples it is based on the more general concept of the ‘higraph’, which in turn has a range of general concept of the ‘higraph’, it is based on the more ‘this rather mundane name should perhaps discount his claim that applications. (We unused combination of “flow” of a better one, simply as the one was chosen, for lack rather more abstract form of or “chart”.’) It provides a or “state” with “diagram” state-oriented viewpoint the STD, and in particular it adds to the description than the as well as permitting the of abstraction in the description, ability to create a hierarchy 7.2.4 The Statechart is concerned section, the Statechart in the preceding that was described Like the STD automaton, or finite- form of finite-state of a system as a the behaviour with describing in well suited for use is particularly it is a form that Like the STD, state machine. response to particular functions arise in in which the main reactive systems, describing events. SDC07 9/18/07 10:54 AM Page 143 AM Page 10:54 9/18/07 SDC07 A Statechart describing a Teletext television set. (a) The two main states A Statechart describing a Teletext television Figure 7.12(c) shows the first diagram expanded in a bottom-up rather than Figure 7.12(c) shows the first diagram a system. However, there are some significant differences between them in terms of the a system. However, there are some significant differences between them in attributes that they each capture. single diagram and be readily comprehended. Of course, the diagrams themselves can single diagram and be readily comprehended. Of course, the diagrams themselves also be layered in a hierarchical fashion.) The Statechart viewpoint of Like the STD, the Statechart is concerned with providing a behavioural description denote any transitions that apply equally to all the encapsulated states, by showing denote any transitions that apply equally in, for example, ‘standby’ in Figure 7.12(b). them as applied to the outer box as states are now shown to be within a superstate top-down fashion. The two initial about how many levels of a hierarchy can be ‘powered’. (There are no specific limits are practical issues of notational complexity shown in a diagram, but obviously there levels seem to be as many as can fit easily on a that limit this. About two or three must result in selecting one of these three states. In the Jackson Structure Diagram must result in selecting one of these of a tree, while in the Statechart it is denoted by abstraction is denoted by the levels form is that it makes it relatively simple to encapsulation. One benefit of this latter (c) A more abstract description of (a). Figure 7.12 of the states shown in (a). of the television set. (b) An expanded description

Some design representations 144 SDC07 9/18/07 10:54 AM Page 144 AM Page 10:54 9/18/07 SDC07 Black box notations 145 . Figure 7.14 shows an example of a state A that can be described as a Describing orthogonality in the Statechart notation. Describing orthogonality in the Statechart Statechart describing the actions of an aircraft in an air traffic control system. the actions of an aircraft in an air traffic Statechart describing The remaining major feature of the Statechart that ought to be described here is The remaining major feature of the Statechart that ought to be described When comparing this with the STD form used in Figure 7.11, we can see that When comparing this with the STD Watches and television sets have the advantage that the events that cause state Watches and television sets have the of further states, but these are essentially independent groupings. Events may be com- of further states, but these are essentially independent groupings. Events event a. Also, mon, as can be seen from the description of the transformations due to systems through a hierarchy of diagrams and states. In that sense they are largely com- systems through a hierarchy of diagrams and states. In that sense they are and the plementary, with the STD perhaps being more suited to modelling problems, Statechart being better suited for modelling detailed solutions. orthogonality in terms superstate of two orthogonal states B and C. B and C can in turn be described description of an aircraft in an air traffic control system, this time using the Statechart. description of an aircraft in an air traffic and transition are common to both, the STD while the descriptions of state, event in terms of the actions that occur, while the provides a more detailed description for describing abstraction, defaults, history, Statechart has more refined mechanisms of hierarchy also limits it largely to describing the and, of course, scale. The STD’s lack whereas the Statechart can describe whole behaviour of individual design elements, Figure 7.14 terms of button presses, and hence are readily changes are directly identifiable in of Figure 7.11 into this form, and shows a described. Figure 7.13 reworks the example Figure 7.13 SDC07 9/18/07 10:54 AM Page 145 AM Page 10:54 9/18/07 SDC07 , et al. A Statechart describing the architecture of a computer. A Statechart describing the architecture of Figure 7.15 shows this concept in terms of the basic architecture of a computer. Figure 7.15 shows this concept in terms Orthogonality is important in reactive systems, where we expect to observe a suit- Orthogonality is important in reactive system uses two other viewpoints of a system, in addition to this form (Harel system uses two other viewpoints of a system, in addition to this form 1990).) Use of the Statechart an import- The Statechart is clearly a powerful and useful tool, and like the STD it has other ant role in modelling reactive systems. Both forms are generally used to support design viewpoints such as data flow. (To reinforce this point: Harel’s ‘STATEMATE’ The state of the computer is shown as a compound of the state of the CPU and the state The state of the computer is shown as something of a simplification). The two have of the main memory (this is obviously events that are common to both. When the com- various substates, and there are some a default state that is expressed in terms of puter is first powered up, they each assume is communication via some memory bus, and their internal operations. While there might also be accessed by device controllers hence some synchronization, the memory suitably separated from those of the CPU. or the like, and so its operations are cause its cruise-control system to change its setting, for example, and lowering the cause its cruise-control system to change not affect the settings of the wing surfaces. In undercarriage of an aircraft should well be changed by the pilot when lowering the latter case, the wing surfaces may routine for landing, but the two should not the undercarriage, as a part of the general be linked automatically in any way.) in describing A, note that we need to identify the default entry to states B and C, shown in describing A, note that we need to F. here as being the inner states D and groups of parallel functions, although all might able separation of concerns between (Switching on the lights of a car should not be working towards the same objective. Figure 7.15

Some design representations 146 SDC07 9/18/07 10:54 AM Page 146 AM Page 10:54 9/18/07 SDC07 Black box notations 147 The basic notation is very simple, and is based upon three forms of box: The basic notation is very simple, and Since this notation will be used extensively in the later chapters of this book (albeit Since this notation will be used extensively so in Figure 7.16(b) the previous description of tea-making is extended to include so in Figure 7.16(b) the previous description of tea-making is extended to the possibility of using either China tea or Indian tea. that Figure 7.16(c) the description is further extended by including the possibility we might put more than one spoonful of tea into the pot. of making tea is described as a series of actions. of making tea is described as a series sequence selection iteration There are a number of rules used in constructing these diagrams, but the most There are a number of rules used in constructing these diagrams, but shows that important is: ‘forms cannot be mixed within a sequence’. Applying this rule 3. A box with an asterisk in the upper right corner denotes an iteration, and so in abstractions of the lower boxes.) 1.so in Figure 7.16(a) the action A simple box denotes a component of a sequence – 2. selection from an option, and A box with a circle in the upper right corner denotes The form of the Structure Diagram of a ‘tree’, constructed from a set of boxes and The Structure Diagram takes the form an elaboration of the description contained in arcs. Each set of ‘child’ boxes provides of a complete sequence is described by the parent box, and hence the full description (In that sense, the parent boxes are themselves the lowest boxes on each branch. entity. (Arguably, the one exception to the above statement is the ERD. Although this entity. (Arguably, the one exception many ‘class and object’ notations are loosely might be true for the original notation, based upon its form.) will concentrate on the basic ‘rules of form’ under a variety of names), this section of its use until later. involved, leaving the main examples entity whose form is being described. Indeed, it can be used to describe the form of is being described. Indeed, it can be entity whose form of program actions (func- modelling viewpoint); the sequencing a data structure (data might occur for some form of or the sequencing of ‘states’ that tional viewpoint); certainly unique to this nota- viewpoint). This feature is almost ‘object’ (behavioural describe in this book are effectively linked to a tion; all of the other notations that we are also linked to a particular form of design particular viewpoint, and generally n n n it purely describes sequen- is an especially abstract notation, since In many ways this assumed about the type of no particular interpretation being tial structuring, with 7.2.5 Diagram Structure Jackson The in that is described Chart notation to the Structure similar in appearance Although and set of attributes, a very different Diagram describes the Structure Section 7.3.1, with concerned 1988a). It is basically of roles (Cameron, a very different set performs forms: three ‘classical’ structuring in terms of the sequential structure, describing SDC07 9/18/07 10:54 AM Page 147 AM Page 10:54 9/18/07 SDC07 and functional data modelling A Jackson Structure Diagram describing the operation of making tea. (a) A simple A Jackson Structure Diagram describing the viewpoint, when used to describe the sequential structuring of data objects. They can viewpoint, when used to describe the sequential structuring of data objects. also be used for describing a viewpoint that has elements of both abstraction of ‘carriages’ above the iteration box, as shown in Figure 7.17(b), in order abstraction of ‘carriages’ above the iteration box, as shown in Figure 7.17(b), to keep the first level of abstraction as a pure sequence. The viewpoints provided by Structure Diagrams As already indicated, Structure Diagrams can be used to provide a Figure 7.16 (c) Adding iteration and choice. sequence of actions. (b) Adding a choice. it, it may be necessary to add an additional Figure 7.17(a) is incorrect. To correct

Some design representations 148 SDC07 9/18/07 10:54 AM Page 148 AM Page 10:54 9/18/07 SDC07 Black box notations 149 viewpoints, when they are used to describe the actions of a program or an viewpoints, when they are used to describe An example of an incorrect Structure Diagram. (a) The sequence and iteration An example of an incorrect Structure Diagram. Since this form will occur so often later in the book, these roles will not be out- Since this form will occur so often later in the book, these roles will not In Figure 7.20 an example of this form is used to describe the dynamic form of a In Figure 7.20 an example of this form Figure 7.18 shows an example of a data structure described in this manner. In this Figure 7.18 shows an example of a data lined any further at this point, and fuller descriptions will be left to the appropriate lined any further at this point, and fuller descriptions will be left to the chapters. As already indicated, this form is ubiquitous. In examining the JSP design method As already indicated, this form is ubiquitous. In examining the JSP design input and (described in Chapter 14), it will be used to describe the structures of the 1992) output data streams. In both the JSD (Chapter 15) and SSADM (Longworth, The title of design methods it is used to describe the ‘evolution’ of entities over time. the form might vary, but the basic notation does not. program. In this example, the task of the program is to print out a page of a monthly program. In this example, the task of related to the appearance of the statement on the bank statement. Clearly this is closely page. Uses for the Structure Diagram tion than can normally be provided through pseudocode (see Section 7.3.4). tion than can normally be provided a physical one, as the diagram is used to describe case, the data structure happens to be one. A more conventional programming data the structure of a textbook such as this a simple file of text is described using this structure is shown in Figure 7.19, where form. forms are wrongly mixed on a single level. (b) How this can be resolved by adding a further level forms are wrongly mixed on a single level. of abstraction in the description. behavioural much more abstract form of sequencing descrip- entity. In particular, they provide a Figure 7.17 SDC07 9/18/07 10:54 AM Page 149 AM Page 10:54 9/18/07 SDC07 can be misleading as it refers to the unification of their can be misleading as it refers to the unified A Jackson Structure Diagram describing a static object (the structure of a A Jackson Structure Diagram describing a This section differs from the others in this chapter in that it describes several nota- This section differs from the others in this chapter in that it describes several tions. What is perhaps most striking to the reader is that these are much less distinctive tions. What is perhaps most striking to the reader is that these are much less to this obser- than any of the other notations that we have discussed. (One exception Indeed, one criticism that can be made of the UML is that this process has resulted in Indeed, one criticism that can be made of the UML is that this process has design prac- an excessive number of notations, especially when compared with other been vested tices. Since 1996, the responsibility for the development of the UML has standard in the Object Management Group (OMG), and it was adopted as an OMG the relevant in 1997, although work continues to develop and extend it further as technologies themselves progress. 7.2.6 Forms UML Modelling made to bring together the ideas of three of the The UML emerged from the efforts Booch, Ivar Jacobson and James Rumbaugh. ‘gurus’ of the ‘object community’: Grady As such, the term the notations making up the modelling language. methodological ideas, rather than of Figure 7.18 textbook).

Some design representations 150 SDC07 9/18/07 10:54 AM Page 150 AM Page 10:54 9/18/07 SDC07 Black box notations 151 do also contain some discussion (1999) although, as often occurs with ‘ref- (1999) although, as often occurs with Unified Process et al. , which is described separately in Section 7.3.3.) To , which is described separately in Section sequence diagram A Jackson Structure Diagram describing a simple file containing text. A Jackson Structure Diagram describing a Since the rest of this section draws upon ‘object model’ concepts, the reader who Since the rest of this section draws upon ‘object model’ concepts, the reader The UML has already generated quite an extensive literature of its own. The The UML has already generated quite UML and its application. 16 first. is unfamiliar with these might want to read the opening section of Chapter of the UML and examples of its use. At the time of writing there is no single text that of the UML and examples of its use. At the time of writing there is no single of the is widely recognized as offering a particularly clear and authoritative exposition the UML. The text by Stevens and Pooley (2000) provides a rather more user-focused the UML. The text by Stevens and Pooley (2000) provides a rather more rather lack- introduction, although the examples provided in this could be regarded as most ing in depth for anyone wanting to make serious use of the UML. In addition, textbooks that describe the associated development processes for the object-oriented architectural style, and hence this development processes for the object-oriented notations adopted. As a further consequence, in influences the nature and form of the wider conceptual issues relating to software a book such as this, which addresses UML are also of less interest. design, the more ‘fussy’ aspects of the definitive reference text is Rumbaugh a reader with the most accessible introduction to erence’ works, this does not provide Figure 7.19 vation is the ‘unification’ processes involved. It also (partially) some extent this probably reflects the itself. When we come to examine this later reflects the nature of the object paradigm constructional detail is characteristic of the we will see that an early emphasis upon SDC07 9/18/07 10:54 AM Page 151 AM Page 10:54 9/18/07 SDC07 and use case functional , (structural); the constructional (1999) into: class diagram (dynamic). A further dynamic form, the et al. activity diagram (concerned with the organization of the model itself).(concerned with the organization of (relating elements of a system); that is essentially equivalent to that described in Section 7.2.4, (concerned with describing system behaviour); is covered separately in Section 7.3.3 and UML also makes use of a . viewpoints that were introduced in Chapter 5. We will examine three viewpoints that were introduced in A Jackson Structure Diagram describing the actions of a program (printing a bank A Jackson Structure Diagram describing the statechart (structural); and the <> In terms of conventions, it is useful to note that the UML makes extensive use of In terms of conventions, it is useful to note that the UML makes extensive dynamic forms model management structural forms heads to distinguish between different forms of relationship. By convention, where the heads to distinguish between different forms of relationship. By convention, arrows, form of relationship needs to be made explicit, this is placed between double as in diagram sequence diagram form of although some of the notational details differ slightly. and arrow- ‘box and line’ forms and, in particular, often employs variations of line n n to the The first two can be recognized as corresponding behavioural the of the nine UML notations in this section: UML Forms The UML forms are classified in Rumbaugh n Figure 7.20 statement).

Some design representations 152 SDC07 9/18/07 10:54 AM Page 152 AM Page 10:54 9/18/07 SDC07 Black box notations 153 Bank- CurrentAccount and ). Figure 7.21 illustrates of system use is one that . scenario inheritance DepositAccount that are created from these (where these that are created from BankAccount objects , 1992; 1999). From this has emerged the more et al. . Indeed, we can draw an analogy between the use While the concept of the (where a class roughly performs the role of a ‘template’ that performs the role of a ‘template’ (where a class roughly use case A core concept of the object model is centred upon the relation- the object model is centred upon the A core concept of viewpoints, being concerned with relationships that exist between viewpoints, being concerned with relationships classes The UML class notation. forms the basis for creating subclasses relationship (Parnas, 1979) and the concept of relationship (Parnas, 1979) and the concept Classes can be related in a number of ways. The UML recognizes six forms of Classes can be related in a number The UML class diagram therefore provides a means of describing both the classes The UML class diagram therefore provides constructional employed in the ERD described earlier). Figures 7.22 and 7.23 show simple examples employed in the ERD described earlier). a very simple association relationship indicating of two of these. Figure 7.22 shows associated with any number of accounts (for sim- that any customer of a bank may be to being held between only two customers). plicity, we have limited joint accounts are only represented by name, as further details Note too that in this figure, the classes this particular relationship. Figure 7.23 are not considered necessary when describing through inheritance. The general class shows an example of generalization terms of the viewpoints model used in this book, it is therefore largely an element used terms of the viewpoints model used in for albeit at a very high level of abstraction. (potential) implementation elements, flow, generalization, realization and usage) relationship (association, dependency, notation (which draws quite extensively on that with appropriate distinctions in the themselves, and also the interactions between these (particularly those based upon the themselves, and also the interactions uses described in the UML, and this form can be used an example of a simple class as it is of a design. For early design stages, the details of at different stages in the development be omitted or curtailed to the bare minimum attributes and operations might well logical concept embodied in a particular class. At required to represent the appropriate made, so the description can be elaborated. In later stages, as design decisions are are specific instances of a given class, possessing an individual state and identity). of a given class, possessing an are specific instances primary activities in object- for classes is one of the Identification of candidates at the ways of describ- We will return to look more generally oriented design practices. in Section 7.3.2. ing classes and objects be used, the work of Ivar Jacobson has formalized both the concept and also its role be used, the work of Ivar Jacobson has formalized both the concept and in the design process (Jacobson general concept of the Account the basic which, although having different modes of operation, will still possess attributes and operations of the parent class The Use Case Diagram a system is to has been employed informally over many years when determining how describes a general concept) and any describes a general The Class Diagram ships that involve Figure 7.21 SDC07 9/18/07 10:54 AM Page 153 AM Page 10:54 9/18/07 SDC07 aspect. However, they are CurrentAccount behavioural BankAccount in terms of our viewpoints model does offer rather in terms of our viewpoints model does (which can be hardware, people or other systems), (which can be hardware, people or other expresses this idea at a fairly high level of abstraction. expresses this idea at a fairly high level actors DepositAccount use case diagram , 1999). Actors are (rather confusingly and not very elegantly) rep- , 1999). Actors are (rather confusingly describes a particular sequence of these interactions. describes a particular sequence of these use case diagram et al. An example of class generalization via inheritance (UML). An example of class generalization via inheritance An example class association (UML). An example class association categorization to them too. There is nothing inconsistent about doing so. scenario Figure 7.25 shows an example use case diagram, together with a textual example Figure 7.25 shows an example use case diagram, together with a textual Classifying the The UML of one of the component use cases. We should perhaps note that the notations of one of the component use cases. We should perhaps note that the also concerned with the tasks that a system performs, and so we can also ascribe a also concerned with the tasks that a system performs, and so we can also functional boundaries While the viewpoints framework is a useful classification mechanism, the although are not firm, and many notations have elements of more than one viewpoint, case diagram usually in a major/minor balance. What perhaps does distinguish the use is that the balance of these viewpoints is rather more even than is usual. (Rumbaugh four kinds of relationship shown, although two resented by stick figures, and there are form and hence need to be labelled using the of these share a single representational occurs elsewhere in UML). form indicated previously (this ‘overloading’ with the interactions that occur between more of a challenge! Use cases are concerned have a a system and its environment, and hence ticular instantiation of these, so a use case describes a set of possible interactions ticular instantiation of these, so a between a system and other and a of a use case diagram. The use case itself is shown Figure 7.24 shows the basic elements description of a slice of system functionality’ as an oval, and represents ‘a logical Figure 7.23 program and execution thread. In the way that case/scenario relationship and that of possible actions, and an execution thread is a par- a program describes a general set of Figure 7.22

Some design representations 154 SDC07 9/18/07 10:54 AM Page 154 AM Page 10:54 9/18/07 SDC07 Black box notations 155 between actor and use case between actor and use relationships between use cases relationships between their identity using their PIN. the amount required. not exceed the customer’s credit limit. machine, system directs the machine to deliver the cash and debits customer’s account, else request is refused. User is a customer of the bank 1. User enters card in machine and establishes 2. User enters a request for funds and specifies 3. The system checks to ensure that this will 4. If request is valid, and cash is available in the 5. System directs machine to return card. User’s account is debited by the amount withdrawn that links the varieties of a use case with the that links the varieties USE CASE: Withdraw funds Customer ACTORS: PRE-CONDITIONS: BODY: POST-CONDITIONS: <> or <> Bank Indicates employed between these two elements) (only form of link that is <> more general form of these <> cases, labelled to where one use case makes use of other use has indicate the form that a particular relationship Use case (title indicates the activity covered by this use case) covered by this use indicates the activity Use case (title case a role in a use a human) describing Actor (not necessarily funds funds Check Deposit balance Withdraw Simple example of use case modelling (UML). Elements of a use case diagram (UML). <