Scibed notes for SE 464 - May 4, 2011

Recap

What questions will we be answering in this course?

• What is design?• How do we represent design?• How do we know our design is good?

There is no single canonical answer to any of these questions. We will be striving towards a better under-standing of the questions.

What are some definitions for design?

Student definitions

• The act of building something on paper as opposed to physically to meet the constraints of:

– Customer

– Environment

– Mathematical reality (See side note 1)

– Existing Components (See side note 2)

• Design is the output of the act of designing (See side note 3)

Literature definitions

• Garlan and Perry [1995]: The structure of the components of a program/system, their interrelation-ships, and principles and guidelines governing their design and evolution over time.

• ANSI/IEEE 1471 IEEE [2000] : The fundamental organization of a system, embodied in its compo-nents, their relationships to each other and the environment, and the principles governing its designand evolution.

• Bass et al. [2003]: The software architecture of a program or computing system is the structure orstructures of the system, which comprise software elements, the externally visible properties of thoseelements, and the relationships among them.

• Charles Eames Moggridge [2007]: A plan for arranging elements in such a way as to best accomplisha particular purpose.

• Taylor et al. [2009]: A software system’s architecture is the set of principal design decisions madeabout the system.

• Conway [1968]: organizations which design systems ... are constrained to produce designs which arecopies of the communication structures of these organizations

• Kruchten [1999]: An architecture is the set of significant decisions about the organization of a softwaresystem, the selection of the structural elements and their interfaces by which the system is composed,together with their behavior as specified in the collaborations among those elements, the compositionof these structural and behavioral elements into progressively larger subsystems, and the architecturalstyle that guides this organization—these elements and their interfaces, their collaborations, and theircomposition

What is Design?

Design can be many things we have seen it as a verb and will look at it as a noun and a discipline specificactivity.

1

Design as a Verb

The act of designing. See lecture 1 for more information.

• The Waterfall Design Process - Software specific• The Spiral Design Process - Software specific• The Funnel Design Process - Commonly used outside of software. In this design process we explore

many alternatives and use this design process to narrow them down. - See Design Process fromlecture 1.

Design as a Noun

What the design of a (software) system is. This design can be:

• Structure-oriented

– Components and connectors (boxes and arrows)

– Makes sense for a physical design because the artefact exists in the 3D world (eg: physicalplacement of gates in chip-making)

– The spatial metaphor sometimes breaks down for software, which has no physical form.

– Most of the cited definitions above talk about design/architecture using this metaphor of physicalstructure.

• Decision-oriented

– This idea is gaining prominence in systems engineering (see paper by Mike Griffin Griffin [2010]in SVN repository).

– A decision based model is generative and various structures can be generated from a singledecision-based design. (J)

– The definition from the Taylor texbook is Descision-oriented.

• Communication-oriented

– See Conways Law for an example of a communication-oriented definition.

– This course does not focus on social reality so we will not look closely at these.

Design as Discipline Specific

Not covered today.

2

Normal and Radical Design

• Existing components = Normal• New (invented) components = Radical• Standard configurations = Normal• New configurations = Radical

The idea of Normal and Radical has a history in architecture and aeronautics. It is now being appliedto software engineering.

Aeronautical engineer and historian Walter Vincenti [1993], following Edward Constant [1980], distin-guishes between normal design and radical design.

Michael A. Jackson [2008] argues that we in software would do well to incorporate this division into ourthinking about software design.

The Taylor et al. [2009] textbook uses the term unprecedented instead of radical.

Where does SE2 Fit?

We can now understand how this course relates to all the other courses we have taken.

• Components - most of the other courses we take are either basic skills or teach us how to buildcomponents from the few we know how to make well (OS, database, compiler, text editor etc.).

• Composition - SE2 is about normal modes of composition and the accumulated wisdom of how wearrange things in software.

What is the Role of Designers?

• Take radical problems and turn them into normal problems• Reduce to one dimension of radicality

– Take existing components and put them together in a new way

– Take new components and put them together in a known way

3

• Why make things more normal?

– Cheaper

– Faster development

– Reduced risk

– Easier to talk about without introducing new terminology

– Problems are understood

– Easier to extend fitness for future

There are two ways of constructing a software design. One way is to make it so simple that thereare obviously no deficiencies. And the other way is to make it so complicated that there are noobvious deficiencies. — Hoare [1981]

Summary Questions

1. Come up with 2 more definitions for design using your own experience with designing in the past.2. Give examples of designs at the four corners of the Normal-Radical plane.3. List advantages and disadvantages of both structural and decision oriented design.

Side Notes

1. Mathematical Platonism - belief that numbers are real - http://en.wikipedia.org/wiki/Philosophy_of_mathematics#Platonism

2. Sometimes we need to invent new components as we may not have the science and mathematics needed.

• Steam engines required thermodynamics which was not known yet - (Watt Steam Engine vsNewcomen Steam Engine)

• Heaviside needed to develope techniques for differential equations.

3. Matlab is what Matlab does - never specified for legal reasons (eg: someone uses Matlab to modelsomething and the model fails)

• Software doesn’t have warranty

• There are some exceptions: Praxis warranties their software against a specification written informal logic (first they train the customer to understand logic, and then the customer signs offon the spec)

4. Intentionality

• Need to know what other people have done/do in your area of design in order to make it intentional,you cannot invent something we already know.

Administration Notes

Historically with this course, we end up with a lot of ’hot air’, which is a waste of time and effort foreveryone. For labs this year we’re going to try to crack down on ’unnecessary hot air’ to attempt to increasethe technical content and value of the lab submissions.

When checking out code from the SVN repository, use your ECE Linux password. Using your WatIAMpassword takes much, much longer. Recommended Clients: TortoiseSVN for Windows; svnX for Mac;Subclipse and Subversive for Eclipse; the normal subversion command line tools.

4

Bibliography

Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley, Reading,Mass., 2 edition, 2003.

Edward W. Constant. The Origins of the Turbojet Revolution. The Johns Hopkins University Press, 1980.

Melvin E. Conway. How do committees invent? Datamation, 14(5):28–31, April 1968. URL http://www.

melconway.com/research/committees.html.

David Garlan and Dewayne E. Perry. Introduction to the special issue on software architecture. IEEETransactions on Software Engineering, 2(1), April 1995.

Michael D. Griffin. How do we fix system engineering? In 61st International Astronautical Conference,September 2010.

C. A. R. Hoare. The emperor’s old clothes. Communications of the ACM, 24(2):75–83, February 1981.Acceptance speech for 1980 Turing Award.

IEEE. Recommended practice for architecture description of software-intensive systems. Technical ReportANSI/IEEE 1471-2000, 2000. URL http://www.iso-architecture.org/ieee-1471/.

Michael A. Jackson. The Name and Nature of Software Engineering. In Egon Borger and Antonio Cisternino,editors, Advances in Software Engineering: Revised Lectures of Lipari Summer School 2007, volume 5316of Lecture Notes in Computer Science, pages 1–38. Springer-Verlag, 2008.

Philippe Kruchten. The Rational Unified Process. Addison-Wesley, Reading, Mass., 1999.

Bill Moggridge. Designing Interactions. The MIT Press, Cambridge, Mass., 2007.

Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. Software Architecture: Foundations, Theoryand Practice. 2009.

Walter G. Vincenti. What Engineers Know and How They Know It: Analytical Studies from AeronauticalHistory. The Johns Hopkins University Press, 1993.

5