SOFTWARE DESIGN COMP2110 Software Design COMP2510 Software Design for Software Engineers COMP6444 Software Design for eScience in 2005 lecturers: Chris Johnson, Ian Barnes, and in term 4: Tamiru Jarso (comp2110/2510) and Alistair Rendell (comp6444)

comp2110/2510/6444 in 2006 Software Requirements and Software Design in a framework for Software Engineering What are the Software Engineering ideas and concepts in COMP2110/2510/6444: What is “design” in Software Engineering? how is it done? Organisation of the course 2006 Term 3 is similar to comp2110 in 2005 Term 4 is similar to 2005 for comp2xxx; new for comp6444..

software DE?!GN

comp2110 – information website http://cs.anu.edu.au/student/comp2110 index.php forum: SoftwareDesign.announce SoftwareDesign.talk WebCT:– for lecture audio recordings only (mp3 and RealAudio)

What is Design in Software Engineering? The Big Question What is Design in Software Engineering?

DE?!GN Industrial Design? www.philippe-starck.com Philippe Starck an art form? or an applied craft? or a branch of engineering? www.philippe-starck.com Philippe Starck

Civil/Mechanical Engineering design? a long history of developing a “profession” from a craft, over 150 years; but bridges still sometimes crack and fall down

Engineering design–abstract models of reality.1

Engineering design–abstract models of reality.2

Architectural design? some of the ideas from architecture: “design patterns” are central to this course

Application software interface design? All Business Personal Fox includes this in what he calls “product design” sorry, not this kind of design: see comp3900/6390 sorry not this kind of design – human interface design is important and visible to users and other clients of software systems, , but designing the internals of software systems is also very important to getting the software built efficiently, reliably, reusably... bus time

Software Design: abstract models of computer systems Diagrammatic notations can model constructs and behaviour: UML (Unified Modelling Language) class diagrams for static structure, UML sequence diagrams, states or Petri Nets for dynamic behaviours, and mathematical logic models can prove correctness. UML Sequence diagram illustrate examples of what is meant by these terms we will expand on and use UML class and sequence diagrams at lot. State machines UML states UML Class diagram Jezequel et al. Petri net

Software Design Design is part of a Software Engineering process. It is a set of activities which create documents: operational concept (mission statement) analyse problem and elicit requirements specify requirements SRS design SAR, DDD implement (generate or write programs) test maintain (update, enhance, fix defects) (retire) these are stages or elements in the lifecycel of a software system.

The Waterfall Software Process Milestone(s) Release product X Requirements Analysis Two phases may occur at the same time for a short period Design Implementation not the only sequence – use waterfall process to illustrate as separate phases Phases (activities) Testing Maintenance time Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

The Process: Software Product Life Cycle Requirements Specification Product Design Design Engineering Design Implementation Testing from Fox fig 1-3-2 Product Redesign and Engineering Redesign Maintenance

The Framework: main phases of the Software Process Operational concept/mission statement Requirements Analysis (answers “WHAT?”) Specifying what the application must do. Design (answers “HOW?”) Specifying what the parts will be, & how they will fit together. Implementation (alias “CODING”) Writing the code Testing (a type of VERIFICATION) Executing the application to detect defects. Maintenance (REPAIR or ENHANCEMENT) Repairing defects and adding capability * note Fox’s argument that “what” and “how” are not a very good definition but read Fox’s argument for why “what” and “how” are not very good ways to describe this difference Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Software Process Phases: Personal Finance Application Example Requirements Analysis: Software Requirements Specification SRS e.g., “ … The application shall display the balance in the selected bank account. …” Design: Diagrams and text e.g., “ … The system will consist of the classes CheckingAccount, SavingsAccount, …” Implementation: Source and object code class CheckingAccount inherits Account{ double limit; … } … Testing: Test cases and test results e.g., “… With test case: deposit $44.92 / deposit $32.00 / withdraw $101.45 / … the balance was $2938.22, which is correct. …” Maintenance: Modified design, code, and text e.g., Defect repair: “Application crashes when balance is $0 and attempt is made to withdraw funds. …” e.g., Enhancement: “Allow operation with Euro currency.” Account balance Checking Account limit Savings Account Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

The Waterfall Software Process Requirements Analysis Design Implementation Testing Maintenance time Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Why a Pure Waterfall Process is Usually Not Practical We don’t know up front everything wanted and needed Usually hard to visualize every detail in advance We can only estimate the costs of implementing requirements (and the feasibility of the project) To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones We will probably need to modify requirements as a result We often need to execute intermediate builds of programs Stakeholders (clients, managers) need to gain confidence Designers and developers need confirmation they're building what’s needed and wanted (use frequent incremental building and testing) Team members are not idle while others do requirements Typically put people to work on several phases at once See also: in comp2110 eBrick. Parnas and Clements, A Rational Design Process, How and Why to Fake It Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Another way: Spiral development process Product: requirements specifications Product:class models + Step n: Analyze requirements Step n+1: Design complete targeted requirements Step n+2: Implement Step n+3: Test Product: code + Product: test results + Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Spiral Process time M I L E S T O N E S Intermediate version (prototype) X Intermediate version (2nd prototype) X Product released X Iteration # 1 2 3 Requirements analysis 1 2 3 Design 1 2 3 Coding 1 2 3 Testing 1 2 3 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Another way(2): overlapping phases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering People (by whom it is done) * * Symbology from Ivar Jacobson, O-O Software Engineering a Case Driven Approach Addison-Wesley 1994 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) Project (the doing of it) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) * Project (the doing of it) Product (the application artifacts) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Product (the application artifacts) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Software Engineering Product – the artifacts Software requirements specification SRS - a document in legalistic English, and UML, for example c2110/6444 concerns Design model SAD and DDD - document using UML, for example Product (the application artifacts) Source code program and object code Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

What's in the course? comp2110/6444 components an introduction to the nature of design in software the design process notations: specifications of requirements for software, description of architectures, description of detailed design design principles – quality in software design design heuristics – how to improve a design design knowledge – a few software architectures and patterns how? lectures, problem classes, tutorials, assignments assessment: assignments, final exam

What's in the course? comp2110/6444 components (2) core content: methods, design ideas, specification supporting concepts: notations, framework, quality not what you might have hoped for: not user interface design – a specialised topic not what you might have feared: not rigid "methodology" or recipes for cookbook design develops your skills in doing design by making descriptions and by criticising existing designs

COMP2110/6444 Organisation people lectures tutorials and laboratories textbook assignments exam assessment scheme

COMP2110/6444 course organisation (1) People Lecturer (session 3) & course manager: Chris Johnson contact: see course web page Ian Barnes lecturer (session 4): Tamiru Jarso comp2110/2510 Alistair Rendell comp6444 tutor: Alexei Khorev, Ian Wilson to be confirmed Textbook Christopher Fox, Introduction to Software Engineering Design not available until start of August, approx $95 – a new book

COMP2110/6444 course organisation (2) Lectures see web course-plan 3 per week: total approx 29 Mon, Tues, Fri lectures will be taped most Fridays: whole class problem classes in weeks 3,4,5, 9,10 week 7 (before the break): no lectures, student groups do presentations in lab sessions Tutorials & laboratories see web course-plan tuts weeks 2-6,8; labs 9,10 learning by practising REGISTER TODAY! classes start week 2

COMP2110/6444 course organisation (3) assignments no programming criticise and create requirements in writing in small groups (3 or 4): create requirements, criticise existing design, start creating project design Groups will make 1 presentation and submit 1 report. individual: (comp2110/2510) detailed design and modified requirements for project (comp64444: not yet decided final exam yes: sit down; written; open book assessment scheme details: Friday 21 July