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

2. 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..

3. software
DE?!GN

4. comp2110 – information website
index.php
forum: SoftwareDesign.announce
SoftwareDesign.talk
WebCT:– for lecture audio recordings only (mp3 and RealAudio)

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

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

7. 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

8. Engineering design–abstract models of reality.1

9. Engineering design–abstract models of reality.2

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

11. 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

12. 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

13. 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.

14. 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.

15. 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

16. 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.

17. 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 $ / … the balance was $ , 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.

18. 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.

19. 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.

20. 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.

21. 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.

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

23. 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.

24. 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.

25. 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.

26. 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.

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

28. 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.

29. 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

30. 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

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

32. 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

33. 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

34. 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