comp2110 software design in 2004 chris...
TRANSCRIPT
DE?!GNsoftware
COMP2110 Software Design in 2004
Chris Johnson
1. Software Requirements and Software Design in a framework for Software Engineering
2. The Software Engineering ideas and conceptsin comp2110
3. Organisation of the course comp2110 in 2004It's similar to 2003 but
the time schedule is different
Industrial Design?Ph
ilipp
e St
arck
ww
w.p
hilip
pes
tarc
k.co
m
DE?!GN
Engineering design?
Software Design
Part of a Software Engineering process:● analyse● design● implement● test● maintain
The Waterfall Software Process
time
Requirements Analysis
Design
Milestone(s)
Phases (activities)
Implementation
Testing
Maintenance
Release product X
Two phases may occur at the same time for a short period
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
The Framework: main phases of the Software Process
1. Requirements Analysis (answers “ WHAT?” ) Specifying what the application must do
2. Design (answers “ HOW?” ) Specifying what the parts will be, and how they will fit together
3. Implementation (alias “ CODING”) Writing the code
4. Testing (a type of VERIFICATION) Executing the application with test data for input
5. Maintenance (REPAIR or ENHANCEMENT) Repairing defects and adding capability
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Software Process Phases: Personal
Finance Example
❏ Requirements Analysis: Text producede.g., “ … The application shall display the balance in the user’ s bank account. … ”
❏ Design: Diagrams and text e.g., “ … The design will consist of the classes CheckingAccount,
SavingsAccount, … ”❏ Implementation: Source and object code
e.g., … class CheckingAccount{ double balance; … } …❏ 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.”
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
The Waterfall Software Process
time
Requirements Analysis
Design
Implementation
Testing
Maintenance
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
1. We don’ t know up front everything wanted and needed Usually hard to visualize every detail in advance
2. We can only estimate the costs of implementing requirements (and the feasibility of the project)
1. To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones
2. We will probably need to modify requirements as a result3. We often need to execute intermediate builds of programs
1. Stakeholders (clients, managers) need to gain confidence2. Designers and developers need confirmation they're building
what’ s needed and wanted(use frequent incremental building and testing)
4. Team members are not idle while others do requirements Typically put people to work on several phases at once
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
See also: in comp2110 eBrick. Parnas and Clements,A Rational Design Process, How and Why to Fake It
Another way(1): Spiral development process
completetargeted
requirements
Step n:Analyzerequirements
Step n+3: Test
Step n+2: Implement
Step n+1:Design
Product:classmodels +
Product: requirementsspecifications
Product: code + Product: test results +Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Spiral Process
time
1 R eq u irem en tsan aly s is
D es ig n
C o d in g
T es tin g
1Itera tio n #
1
1
2
2
2
3
3
3
Product released X
M I L E S T O N E S
2 3
2 3 1
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Intermediate version(prototype) X
Intermediate version(2nd prototype) X
Another way(2): overlapping phases
Elaboration
Unified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.iterations
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
… .. … ..
Design
Implementation
Test
..
Adapted from Software Engineering: An ObjectOriented 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,OO Software Engineering a Case Driven Approach AddisonWesley 1994Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Process(the manner in which it is done)
Elaboration
Unified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.iterations
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
… .. …..
Design
Implementation
Test
..
The Four “ P’ s” of Software Engineering
People
(by whom it is done)
Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Project
(the doing of it)
The Four “ P’ s” of Software Engineering
People
(by whom it is done)
Process(the manner in which it is done)
Elaboration
Unified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.iterations
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
… .. …..
Design
Implementation
Test
..
Adapted from Software Engineering: An ObjectOriented 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)
Elaboration
Unified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.iterations
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
… .. …..
Design
Implementation
Test
..*
Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Product
(the application artifacts)
Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Software Engineering Product – the artifacts
Design model
a document in UML, for example
Source code programand object code
Software requirements specification
a document in legalistic English, and UML, for example
Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Product
(the application artifacts)
c2110 concerns
What's in the course? comp2110 components
● core content– specifications of requirements for software– methods for designing software for a given purpose– technical "design ideas" to use
● at high level● at detailed level
● supporting concepts– notational methods for describing software design– notations for specification of requirements– software lifecycle framework– "quality" – what makes it a good design (or not)
What's in the course? comp2110 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 Organisation
● people● lectures● tutorials and laboratories● textbook● assignments● exam● assessment scheme
COMP2110 course organisation (1)● People
– Lecturer and tutor: Chris Johnson– Tutors: Tamiru Jarso and (tbc)
● Lectures see web courseplan– 3 per week: total 26
Mon, Tues, Fri (week 5 M only, week 13 M&T)– no lectures in weeks 6 & 8 (before the break) – week 7: no lectures, group work presentations in labs
● Tutorials & laboratories see web courseplan– weeks 26, 812 learning by practising
● TextbookEric Braude, Software Design the green book
COMP2110 course organisation (2)
● assignments no programming
1) criticise and create requirements
2) in small groups (3 or 4):create requirements, criticise existing design, start creating project designGroups will make 1 presentation and submit 1 report.
3) individual:detailed design and modified requirements for project
● final exam yes: sit down; written; open book● assessment scheme details: Friday 23 July