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