1. Software Design Motivation
Methodologies
Comp 6471
Comp 6471
COMP 6471/4 NN
Steven Winikoff …with proper design, the features come
cheaply. This approach is arduous, but
smw@alcor.concordia.ca continues to succeed.
H-966-2 - Dennis Ritchie
514-848-2424, ext. 7619
Page 7
What This Course is About Software Engineering
ca. 1968: Reasons for the software crisis were determined.
Comp 6471
simple questions: Software development should be treated as an engineering
activity and not as an ad-hoc activity => software development
should be a systematical activity.
What should go into a given piece of
software? Definition provided by the IEEE:
Software Engineering is the systematic approach to
development , maintenance, organization of software
How do you put it there? systems.
Starting point of the software crisis.
...with complex answers
Acknowledgement: These slides are based on work originally created by
Dr. Juergen Rilling, CSE, Concordia
Comp6471 Software Design Methodologies
2. Page 8 Page 9
Goals of Software Engineering Software Life Cycle
The phases of a software development cycle.
Improve the productivity of the programming/development process Analysis: Software Engineering
Improve the comprehension of the developed software system Specification
Improve the maintainability of the systems 70
Improve the quality of the software system (software product)
Design 60
50
Improve the “quality” of the software system. Implementation
40 Without SE
- Reliability
Effort
Testing 30 Applying SE
- Efficiency (Speed, resource usage)
Delivery/Maintenance 20
- User-friendly (user acceptance)
10
0
General goal:
n
n
gn
g
s
io
t io
in
si
Produce software which is useful for people
si
at
st
y
ta
De
al
Te
f ic
en
An
i
ec
em
Sp
pl
Im
Software Life Cycle Phase
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 10 Page 11
Software Life Cycle Goals of Software Engineering
Products: External deliverables, internal products; software products: final
code, test drivers
Feasibility study – WHY? Cost benefit analysis (is Paper documents: external: user manual, installation guide;
it worth doing the project) Internal: requirements document, specification document,
Requirements analysis + specification: WHAT? design document, test plan
What should the software do, produce a document.
Design - How? How should the software do it.
Architectural design (overall structures + organization Processes: How the software is created, how its quality is evaluated and
of objects/modules, choice of data structures, etc. ensured
Coding/Implementation: Realize ! components. Tools: CASE tools, editors, project management tools
Code modules, prodcuts: software,
Testing: Realize ! Test individual modules, test People: Technical, social and managerial skills
whether modules work together, test system as a
whole, document test results. Principles Providing permanency, guidelines and maturity in the software
Delivery and maintenance: Evolve! development process.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
3. Page 12 Page 13
Skills of a Software Engineer Skills of a Software Engineer
Programming: Design
data structures and algorithms – be familiar with several approaches
programming languages – be flexible and open to different application domains
tools: compilers, debuggers, editors
– be able to shift between several level of abstraction
Communication: – application domain jargon
spoken, written, presentations
teamwork
– requirements and specification: declarative model
with external people (customers) – architectural design, high-level operational model
– detailed coding
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 14 Page 15
Software Lifecycle Models
A lifecycle model provides a fixed generic
framework that can be tailored to a specific project.
Project specific parameters will include:
Definition. size (person-years),
A (software/system) lifecycle model is a budget,
description of the sequence of activities carried duration.
out in a software engineering project, and the
relative order of these activities.
project plan = lifecycle model + project parameters
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
4. Page 16 Page 17
There are many different lifecycle models to choose By changing the lifecycle model, we can
from, e.g:
improve and/or trade off:
waterfall,
code-and-fix development speed (time to market)
spiral product quality
rapid prototyping
unified process (UP)
project visibility
agile methods, extreme programming (XP) administrative overhead
COTS … risk exposure
customer relations, etc, etc.
but many are minor variations on a smaller number of
basic models.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 18 Page 19
Normally, a lifecycle model covers the entire Note that we can sometimes combine
lifetime of a product. lifecycle models
e.g. waterfall inside evolutionary – onboard
From the birth of an idea to the final shuttle software
deinstallation of the last release
We can also change lifecycle model between
i.e. The three main phases: releases as a product matures,
design,
build, e.g. rapid prototyping → waterfall
maintain.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
5. Page 20 Page 21
phase
User Requirements output User Requirements Document
The Waterfall Model
Software Requirements Software Requirements
Document
• Classic lifecycle model – widely known,
understood and (commonly?) used. Architecture Design Architectural Design
Document
• In some respect, waterfall is the "common
”Swimming
sense" approach upstream”
Detailed design & Coding Detailed
Design
(Introduced by Royce 1970) & Code
The Waterfall Testing
Lifecycle Workflow
Delivery
Time
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 22 Page 23
Advantages
Disadvantages I
1. Easy to understand and implement.
2. Widely used and known (in theory!)
● Idealized, doesn’t match reality well.
3. Reinforces good habits: define-before-design, ● Doesn’t reflect iterative nature of exploratory
design-before-code development.
4. Identifies deliverables and milestones ● Unrealistic to expect accurate requirements so early
5. Document driven, URD, SRD, … etc. Published in project
documentation standards, e.g. PSS-05.
● Software is delivered late in project, delays
6. Works well on mature products and weak teams.
discovery of serious errors.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
6. Page 24 Page 25
Disadvantages II Code-and-Fix
● Difficult to integrate risk management This model starts with an informal general
● Difficult and expensive to make changes to product idea and just develops code until a
documents, ”swimming upstream”. product is ”ready” (or money or time runs out).
● Significant administrative overhead, costly for
Work is in random order.
small teams and projects.
Corresponds with no plan!
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 26 Page 27
Advantages Disadvantages
● No administrative overhead 1. Dangerous!
● Signs of progress (code) early. ● No visibility/control
● Low expertise, anyone can use it!
● No resource planning
● Useful for small “proof of concept” projects,
● No deadlines
● Mistakes hard to detect/correct
e.g. as part of risk reduction.
2. Impossible for large projects,
communication breakdown, chaos.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
7. Page 28 Page 29
This loop approach gives rise to structured
Spiral Model
iterative lifecycle models.
Since end-user requirements are hard to
obtain/define, it is natural to develop software In 1988 Boehm developed the spiral model as
in an experimental way: e.g. an iterative model which includes risk
analysis and risk management.
1. Build some software
2. See if it meets customer requirements Key idea: on each iteration identify and solve
3. If no goto 1 else stop. the sub-problems with the highest risk.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 30 Page 31
Cumulative cost
Determine objectives, Evaluate alternatives,
alternatives & constraints Identify & resolve risks
Each cycle follows a waterfall model by:
1. Determining objectives
2. Specifying constraints
Prototypes Operational
Review & Start P1 P2 P3 Prototype 3. Generating alternatives
commitment Requirements Concept
Design, 4. Identifying risks
plan Detailed design
Of Operation
Development
Validation 5. Resolving risks
& Verification
plan Requirements 6. Developing next-level product
validation Coding
Integration & 7. Planning next cycle
Test plan Unit & Integration
Testing
End Acceptance
Plan next phase Testing Develop & verify
next-level product
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
8. Page 32 Page 33
Advantages Disadvantages
1. Realism: the model accurately reflects the Needs technical expertise in risk analysis to really
iterative nature of software development on work
projects with unclear requirements Model is poorly understood by non-technical
2. Flexible: incorporates the advantages of the management, hence not so widely used
waterfall and rapid prototyping methods Complicated model, needs competent professional
management. High administrative overhead.
3. Comprehensive model decreases risk
4. Good project visibility.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 34 Page 35
Requirements Capture
Rapid Prototyping
Iterate
Quick Design
Key idea: Customers are non-technical and
usually don’t know what they want/can have.
Build Prototype
Rapid prototyping emphasises requirements
Customer Evaluation of
analysis and validation, also called: Prototype
customer oriented development,
evolutionary prototyping
The Rapid Engineer Final
Prototype Workflow Product
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
9. Page 36 Page 37
Advantages Disadvantages I
1. Reduces risk of incorrect user requirements 1. An unstable/badly implemented prototype
2. Good where requirements are often becomes the final product.
changing/uncommitted 2. Requires extensive customer collaboration
3. Regular visible progress aids management – Costs customers money
4. Supports early product marketing – Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad market
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 38 Page 39
Disadvantages II Agile (XP) Manifesto
3. Difficult to know how long project will last XP = Extreme Programming emphasizes:
4. Easy to fall back into code-and-fix without Individuals and interactions
proper requirements analysis, design, – Over processes and tools
customer evaluation and feedback. Working software
– Over documentation
Customer collaboration
– Over contract negotiation
Responding to change
– Over following a plan
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
10. Page 40 Page 41
Agile Principles (Summary) XP Practices (Summary)
Continuous delivery of software Programming in pairs
Continuous collaboration with customer Test driven development
Continuous update according to changes Continuous planning, change , delivery
Value participants and their interaction Shared project metaphors, coding standards and
Simplicity in code, satisfy the spec ownership of code
No overtime! (Yeah right!)
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 42 Page 43
Advantages Disadvantages
Lightweight methods suit small-medium size Difficult to scale up to large projects where
projects documentation is essential
Produces good team cohesion Needs experience and skill if not to degenerate
Emphasizes final product into code-and-fix
Iterative Programming pairs is costly
Test-based approach to requirements and quality Test case construction is a difficult and specialized
assurance skill.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
11. Page 44 Page 45
Advantages
COTS Fast, cheap solution
May give all the basic functionality
COTS = Commercial Off-The-Shelf software Well defined project, easy to run
Engineer together a solution from existing
commercial software packages using minimal Disadvantages
software "glue". Limited functionality
E.g. using databases, spread sheets, word Licensing problems, freeware, shareware, etc.
proccessors, graphics software, web browsers,
License fees, maintainance fees, upgrade
etc.
compatibility problems
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 47
Unified Process (UP)
Booch, Jacobson, Rumbaugh 1999.
Comp 6471
Iterative Development and the Lifetime of a software product in cycles:
Unified Process
– Birth, childhood, adulthood, old-age, death.
Product maturity stages
Each cycle has phases, culminating in a new
release (c.f. Spiral model)
Acknowledgement: These slides for the Iterative Development process were
originally created by Dr. Constantinos Constantinides, CSE, Concordia
Comp6471 Software Design Methodologies
12. Page 48 Page 49
Iterative Development Iterative Development
[iteration N]
Requirements – Analysis - Design- Implementation - Testing
The iterative lifecycle is based on the
successive enlargement and refinement of a
system though multiple iterations with
feedback and adaptation. [iteration N+1]
The system grows incrementally over time, Requirements – Analysis - Design- Implementation - Testing
iteration by iteration.
The system may not be eligible for production Feedback from iteration N leads to
refinement and adaptation of the The system grows
deployment until after many iterations. requirements and design in iteration incrementally.
N+1.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 50 Page 51
Iterative Development Embracing Change
The output of an iteration is not an Stakeholders usually have changing
experimental prototype but a production requirements.
subset of the final system. Each iteration involves choosing a small
Each iteration tackles new requirements and subset of the requirements and quickly
incrementally extends the system. design, implement and testing them.
An iteration may occasionally revisit existing This leads to rapid feedback, and an
software and improve it. opportunity to modify or adapt understanding
of the requirements or design.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
13. Page 52 Page 53
Iteration Length and Timeboxing Phases of the Unified Process
Inception Elaboration Construction Transition
time
The UP recommends short iteration lengths
to allow for rapid feedback and adaptation. A UP project organizes the work and iterations
Long iterations increase project risk. across four major phases:
Iterations are fixed in length (timeboxed).If – Inception - Define the scope of project.
meeting deadline seems to be difficult, then – Elaboration - Plan project, specify features,
remove tasks or requirements from the baseline architecture.
iteration and include them in a future iteration.
The UP recommends that an iteration should – Construction - Build the product
be between two and six weeks in duration. – Transition - Transition the product into end
user community
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 54 Page 55
Iterations and Milestones The UP Disciplines
Phases
Process Disciplines Inception Elaboration Construction Transition
Inception Elaboration Construction Transition
Business Modeling
Requirements
Preliminary Iter. #1 Iter. #2
Iteration Analysis & Design
Implementation
Milestone Release Final production Test
release
Deployment
Each phase and iteration has some risk mitigation focus, and Supporting Disciplines
concludes with a well-defined milestone. Configuration Mgmt
The milestone review provides a point in time to assess how Management
well key goals have been met and whether the project needs to
be restructured in any way to proceed. Environment
The end of each iteration is a minor release, a stable executable Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
subset of the final product.
Iterations
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
14. Page 56 Page 57
The UP Disciplines In an iteration you
walk through all The UP Disciplines Focus of this
course.
Phases disciplines. Phases
Process Disciplines Inception Elaboration Construction Transition Process Disciplines Inception Elaboration Construction Transition
Business Modeling Business Modeling
Requirements Requirements
Analysis & Design Analysis & Design
Implementation Implementation
Test Test
Deployment Deployment
Supporting Disciplines Supporting Disciplines
Configuration Mgmt Configuration Mgmt
Management Management
Environment Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations Iterations
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 58 Page 59
Advantages of an
Disciplines and Phases
Iterative Process
Although an iteration includes work in most
Reduce risks
disciplines, the relative effort and emphasis change – Risks are identified early, progress is easier to see.
over time. Get a robust architecture
– Early iterations tend to apply greater emphasis to – Architecture can be assessed and improve early.
requirements and design, and later ones less so. Handle evolving requirements
– Figure illustrations are suggestive, not literal. – Users provide feedback to operational systems.
– Responding to feedback is an incremental change.
Note that activities and artifacts are optional (except Allow for changes
code!) – System can adapt to problems
– Developers select those artifacts that address their particular
needs.
Attain early learning
– Everyone obtains an understanding of the different workflows
early on.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
15. Page 60 Page 61
Unified Process
Product UML class diagram!
Management Software Lifecycle
Use Case Model
Environment * * releases specified by
by
ed
Workflow Cycle
deployed by
lis
a
Analysis Model
re
Requirements
im
Inception
ple
4
me
Design Design Model
n te
Phase Elaboration
db
Deployment Model verified by
y
Implementation
Construction
*
Implementation Model
Assessment Iteration
Transition All models are interdepedent
but this only shown for use Test Model
Deployment *
case model
Artifact
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 62 Page 63
What artifacts may start in
Inception
inception?
A number of questions need to be explored: Vision and business case
– What is the vision and business case for this project? – Describes high-level goals and constraints.
– Is it feasible? Use Case model
– Buy and/or build? – Describes functional requirements and related non-functional
– Rough estimate of cost. requirements.
– Should we proceed or stop?
Supplementary specification
– Describes other requirements
Glossary
The intent is to establish some initial common vision – Key domain terminology
for the objectives of the project, determine if it is
feasible and decide if it is worth some serious
Risk list and Risk Management Plan
– Describes business, technical, resource and schedule risks
investigation in elaboration. and ideas for their mitigation or response.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
16. Page 64 Page 65
What artifacts may start in Requirements Engineering:
inception? An Overview
Prototypes and proof-of-concepts Basic goal: To understand the problem as
Iteration plan perceived by the user.
– Describes what to do in the first elaboration iteration
Phase Plan & Software development Plan
Activities of RE are problem oriented.
– Guess for elaboration phase duration. Tools, people, – Focus on what, not how
education and other resources. – Don’t cloud the RD with unnecessary detail
Development Case – Don’t pre-constrain design.
– Description of the customized UP steps and artifacts for this
project. After RE is done, do software design:
Artifacts will be partially completed in this phase and – solution oriented
will be refined in later iterations.
– how to implement the what
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 66 Page 67
Requirements Engineering: Requirements Engineering
An Overview
The process of determining and establishing
Key to RE is good communication between the precise expectations of the customer
customer and developers. about the proposed software system.
Work from Requirements Document as guide.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
17. Page 68 Page 69
The Two Kinds of Requirements The Purpose of RE
Raw user requirements are often:
Functional: The precise tasks or functions – vague
the system is to perform. – contradictory
– e.g., details of a flight reservation system – impractical or impossible to implement
– overly concrete
Non-functional: Usually, a constraint of – just plain wrong
some kind on the system or its construction The purpose of RE is to get a usable set of
– e.g., expected performance and memory requirements from which the system may be
requirements, process model used, designed and implemented, with minimal
implementation language and platform, surprises.
compatibility with other tools, deadlines, ...
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 70 Page 71
Requirements
Analysis
leads to The RE Process
The Requirements Document
Requirements
produces
Definition
The official statement of what is required of
System Requirements the system developers.
Models Specification
– Includes system models, requirements definition,
and requirements specification.
Requirements – Not a design document.
Software
Definition
Specification – States functional and non-functional requirements.
included in
Requirements
Specification Serves as a reference document for
maintenance.
Requirements
Software
Document
Specification
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
18. Page 72 Page 73
Requirements Document The Requirements Document
“Requirements” Should State ...
Foreseen problems:
– “won’t support Win-3.x apps”
Should be easy to change as requirements Expected evolution:
evolve. – “will port to MacOS in next version”
Must be kept up-to-date as system changes. Response to unexpected events/usage:
– “if input data in old format, will auto-convert”
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 74 Page 75
Requirements Document A Story ...
Structure
Dear Mr. Architect,
Introduction (describe need for system)
Functional Requirements Please design and build me a house. I am not quite sure of what
I need, so you should use your discretion.
Non-Functional Requirements
System Evolution (describe anticipated changes) My house should have between two and forty-five bedrooms.
Just make sure the plans are such that bedrooms can be easily
Glossary (technical and/or new jargon) added or deleted. When you bring the blueprints to me, I will
Appendices make the final decision of what I want. Also bring me the cost
breakdown for each configuration so that I can arbitrarily pick
Index one.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
19. Page 76 Page 77
A Story … (Cont’d) A Story … (Cont’d)
Please take care that modern design practices and the latest
Keep in mind that the house I ultimately choose must cost materials are used in construction of the house, as I want it to be a
less than the one I am currently living in. Make sure, showplace for the most up-to-date ideas and methods. Be alerted,
however, that you correct all the deficiencies that exist in my however, that kitchen should be designed to accommodate, among
current house (the floor of my kitchen vibrates when I walk other things, my 1952 Gibson refrigerator.
across it, and the walls don’t have nearly enough insulation in
them). To insure that you are building the correct house for our entire
family, make certain that you contact each of our children, and
As you design, also keep in mind that I want to keep yearly also our in-laws. My mother-in-law will have very strong feelings
maintenance costs as low as possible. This should mean the about how the house should be designed, since she visits us at
incorporation of extra-cost features like aluminum, vinyl, or least once a year. Make sure that you weigh all of these options
carefully and come to the right decision. I, however, retain the
composite siding. (If you choose not to specify aluminum, be right to overrule any choices that you make.
prepared to explain your decision in detail.)
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 78 Page 79
A Story … (Cont’d) A Story … (Cont’d)
While you are designing this house specifically for me, keep in mind
that sooner or later I will have to sell it to someone else. It therefore
Please don't bother me with small details right now. Your job is to should have appeal to a wide variety of potential buyers. Please
develop the overall plans for the house: get the big picture. At this make sure before you finalize the plans that there is a consensus of
time, for example, it is not appropriate to be choosing the color of the population in my area that they like the features this house has.
the carpet. However, keep in mind that my wife likes blue.
I advise you to run up and look at my neighbor's house he
Also, do not worry at this time about acquiring the resources to constructed last year. We like it a great deal. It has many features
build the house itself. Your first priority is to develop detailed that we would also like in our new home, particularly the 75-foot
plans and specifications. Once I approve these plans, however, I swimming pool. With careful engineering, I believe that you can
would expect the house to be under roof within 48 hours. design this into our new house without impacting the final cost.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
20. Page 80 Page 81
A Story … (Cont’d) A Story … (Cont’d)
Please prepare a complete set of blueprints. It is not necessary at P.S. My wife has just told me that she disagrees with many on the
this time to do the real design, since they will be used only for instructions I’ve given you in this letter. As architect it is
construction bids. Be advised, however, that you will be held your responsibility to resolve these issues. I have tried in the
accountable for any increase of construction costs as a result of past and have been unable to accomplish this. If you can’t handle
later design changes. this, I will have to find a new architect.
You must be thrilled to be working on as an interesting project as P.P.S. Perhaps what I need is not a house at all, but a travel trailer.
this! To be able to use the latest techniques and materials and to be Please advise me as soon as possible if that is the case.
given such freedom in your designs is something that can't happen
very often. Contact me as soon as possible with your complete
ideas and plans. (originally posted to the rec.humor.funny newsgroup
in January 1993 -- but some things never change!)
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 82 Page 83
RE Summary RE Summary (Cont’d)
RE focuses on determining what the The customer often doesn’t have good grasp
customer wants, and not how it will be of what he wants.
implemented. Errors made at the requirements stage are
RE is hard to get correct; it requires good very expensive to fix later.
communication skills. – You might well implement the stated requirements
Requirements may change over time. correctly, but it won’t be the system the customer
really wants.
RE requires iteration.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
21. Page 84 Page 85
Object-Oriented Analysis Back to Software Design ...
An investigation of the problem (rather than
how a solution is defined)
During OO analysis, there is an emphasis on
finding and describing the objects (or
concepts) in the problem domain.
– For example, concepts in a Library Information
System include Book and Library.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 86 Page 87
Software
architecture
Subsystem
decomposition
High-Level Top-Down vs Bottom-Up Design
(abstract)
Subsystem
dependencies design Top-down Design:
Subsystem – Start with a coarsely-grained view of system, and
interfaces
repeatedly refine components until you have
module or class concrete sub-components.
decomposition
module or class
dependencies
Bottom-up Design:
– Start with existing components and “glue” them
module or class
interfaces
Low-Level together to get what you want.
(detailed)
Data structures
design
Algorithms
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
22. Page 88 Page 89
Top-Down vs Bottom-Up Design
(Cont’d) Design Quality
Software design “quality”, as with other ideas
Top-down is the “ideal” of most design on quality, is an elusive concept: it depends
methods, but it’s rarely followed absolutely: on priorities of your company and the
– some branches of development are expanded customers:
before others are even started – fastest to implement
– doesn’t adequately account for reuse of existing – easiest to implement
components: – easiest to maintain, “evolve”, port
COTS products, libraries, previous versions of the same
system. – most efficient/reliable/robust end-product.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 90 Page 91
Discussion Object-Oriented Design
What does “quality” mean to: Emphasizes a conceptual solution that fulfils
– IBM? the requirements.
– Microsoft? Need to define software objects and how they
– Mozilla? collaborate to fulfill the requirements.
– FAA? – For example, in the Library Information System, a
Book software object may have a title attribute and
– IRS? a getChapter method.
– Intel? Designs are implemented in a programming
– ... language.
– In the example, we will have a Book class in Java.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
23. Page 92 Page 93
From Design to Implementation
Software Design
Analysis
Design Construction
Knowing an object-oriented language and having investigation
logical solution code
access to a library is necessary but not sufficient in of the problem
order to create object software.
In between a nice idea and a working software, there
is much more than programming. Book public class Book {
Analysis and design provide software “blueprints”, Book public void print();
illustrated by a modeling language, like the Unified (concept) title private String title;
Modeling Language (UML). print() }
Blueprints serve as a tool for thought and as a form of Representation in an
Domain concept Representation in
communication with others. object-oriented
analysis of concepts
programming language.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies
Page 94 Page 95
Software Design Software Design (Cont’d)
How to implement the what. Some consider software design to be a “black
Requirements Document (RD) is starting point. art”:
Software design is a highly-creative activity. – difficult to prescribe how to do it
Good designers are worth their weight in gold! – hard to measure a good design objectively
– Highly sought after, head-hunted, well-paid. – “I know a good design when I see it.”
Experience alone is not enough:
– creativity, “vision”, all-around brilliance required.
Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies