Software Design Overview
-
Upload
bnlong4155 -
Category
Documents
-
view
227 -
download
0
Transcript of Software Design Overview
-
8/3/2019 Software Design Overview
1/27
Slide 1.1Overview
OBJECT-ORIENTED
SOFTWAREDESIGN
Overview
-
8/3/2019 Software Design Overview
2/27
Slide 1.2Typical Classical Phases
Requirements phaseExplore the concept
Elicit the clients requirements
Analyze the clients requirements
Draw up the specification document
Draw up the software project management plan
What the product is supposed to do
-
8/3/2019 Software Design Overview
3/27
Slide 1.3Typical Classical Phases (contd)
Design phaseArchitectural design, followed by
Detailed design
How the product does it
Implementation phase
Coding
Unit testingIntegration
Acceptance testing
-
8/3/2019 Software Design Overview
4/27
Slide 1.4In More Detail
Objects enter here
Figure 1.9
-
8/3/2019 Software Design Overview
5/27
Slide 1.5Object-Oriented Paradigm
Modules (objects) are introduced as early as theobject-oriented analysis workflow
This ensures a smooth transition from the analysis
workflow to the design workflow
The objects are then coded during the
implementation workflow
Again, the transition is smooth
-
8/3/2019 Software Design Overview
6/27
Slide 1.6Strengths of the Object-Oriented Paradigm
With information hiding, post-delivery maintenanceis safer
The chances of a regression fault are reduced
Development is easier
Objects generally have physical counterparts
This simplifies modeling (a key aspect of the object-
oriented paradigm)
-
8/3/2019 Software Design Overview
7/27
Slide 1.7Strengths of the Object-Oriented Paradigm (contd)
Well-designed objects are independent unitsEverything that relates to the real-world object being
modeled is in the object encapsulation
Communication is by sending messages
This independence is enhanced by responsibility-drivendesign (see later)
-
8/3/2019 Software Design Overview
8/27
Slide 1.8Strengths of the Object-Oriented Paradigm (contd)
A classical product conceptually consists of asingle unit (although it is implemented as a set of
modules)
The object-oriented paradigm reduces complexity
because the product generally consists of independentunits
The object-oriented paradigm promotes reuse
Objects are independent entities
-
8/3/2019 Software Design Overview
9/27
Slide 1.9The Object-Oriented Paradigm in Perspective
The object-oriented paradigm has to be usedcorrectly
All paradigms are easy to misuse
When used correctly, the object-oriented paradigm
can solve some (but not all) of the problems of the
classical paradigm
-
8/3/2019 Software Design Overview
10/27
Slide 1.10What is software design?
Software design is the process of planning how tosolve a problem through software.
A software design contains enough information for a
development team to implement the solution. It isthe embodiment of the plan (the blueprint for the
software solution).
-
8/3/2019 Software Design Overview
11/27
Slide 1.11The Design Workflow
The aim of the design workflow is to refine theanalysis workflow until the material is in a form
that can be implemented by the programmers
Many nonfunctional requirements need to be finalized at
this time, including Choice of programming language
Reuse issues
Portability issues
Retain design decisions
For when a dead-end is reached, and
To prevent the maintenance team reinventing the wheel
-
8/3/2019 Software Design Overview
12/27
Slide 1.12Classical Design
Architectural designDecompose the product into modules
Detailed design
Design each module:
Data structures
Algorithms
-
8/3/2019 Software Design Overview
13/27
Slide 1.13Data and Actions
Two aspects of a productActions that operate on data
Data on which actions operate
The two basic ways of designing a product
Operation-oriented design
Data-oriented design
Third way
Hybrid methods
For example, object-oriented design
-
8/3/2019 Software Design Overview
14/27
Slide 1.14Object-Oriented Design (OOD)
AimDesign the product in terms of the classes extracted
during OOA
OOD consists of two steps:
Step 1. Complete the class diagram
Determine the formats of the attributes
Assign each method, either to a class or to a client that
sends a message to an object of that class
Step 2. Perform the detailed design
-
8/3/2019 Software Design Overview
15/27
Slide 1.15The Design Workflow
Summary of the design workflow:The analysis workflow artifacts are iterated and
integrated until the programmers can utilize them
Decisions to be made include:Implementation language
Reuse
Portability
-
8/3/2019 Software Design Overview
16/27
Slide 1.16The Design Workflow (contd)
The idea of decomposing a large workflow intoindependent smaller workflows (packages) is
carried forward to the design workflow
The objective is to break up the upcomingimplementation workflow into manageable pieces
Subsystems
-
8/3/2019 Software Design Overview
17/27
Slide 1.17The Design Workflow (contd)
Why the product is broken into subsystems:
It is easier to implement a number of smaller
subsystems than one large system
If the subsystems are independent, they can be
implemented by programming teams working in parallel
The software product as a whole can then be delivered sooner
-
8/3/2019 Software Design Overview
18/27
Slide 1.18The Design Workflow (contd)
The architecture of a software product includesThe various components
How they fit together
The allocation of components to subsystems
The task of designing the architecture is
specialized
It is performed by a software architect
-
8/3/2019 Software Design Overview
19/27
Slide 1.19The Design Workflow (contd)
The architect needs to make trade-offsEvery software product must satisfy its functional
requirements (the use cases)
It also must satisfy its nonfunctional requirements,
including Portability, reliability, robustness, maintainability, and security
It must do all these things within budget and time
constraints
The architect must assist the client by laying out
the trade-offs
-
8/3/2019 Software Design Overview
20/27
Slide 1.20The Design Workflow (contd)
It is usually impossible to satisfy all therequirements, functional and nonfunctional, within
the cost and time constraints
Some sort of compromises have to be made
The client has to
Relax some of the requirements;
Increase the budget; and/or
Move the delivery deadline
-
8/3/2019 Software Design Overview
21/27
Slide 1.21The Design Workflow (contd)
The architecture of a software product is criticalThe requirements workflow can be fixed during the
analysis workflow
The analysis workflow can be fixed during the design
workflowThe design workflow can be fixed during the
implementation workflow
But there is no way to recover from a suboptimalarchitecture
The architecture must immediately be redesigned
-
8/3/2019 Software Design Overview
22/27
Slide 1.22OOA & OOD Activities
1. Identify the information systems purpose2. Identify the information systems actors and features
3. Identify Use Cases and create a Use Case Diagram
4. Identify Objects and their Classes and create a Class
Diagram5. Create Interaction/Scenario Diagrams
6. Create Detail Logic for Operations
7. Repeat activities 1-6 as required to refine the blueprints
-
8/3/2019 Software Design Overview
23/27
Slide 1.23Objects
Objects have three responsibilities:1. What they know about themselves (e.g.,
Attributes)
2. What they do (e.g., Operations)
3. What they know about other objects (e.g.,
Relationships
-
8/3/2019 Software Design Overview
24/27
Slide 1.24Relationships
A RELATIONSHIP is what a class or an object knows about another class or
object.
Generalization (Class-to-Class) (Superclass/Subclass)
Inheritance
Ex: Person - FacultyPerson, StudentPerson, Staff... Ex: ModesOfTravel - Airplane, Train, Auto, Cycle, Boat...
Associations
FacultyInformation - CourseInformation
StudentInformation - CourseInformation
Aggregations & Composition (Whole-Part)
Assembly - Parts
Group - Members
Container - Contents
-
8/3/2019 Software Design Overview
25/27
Slide 1.25Composition
Composition is often used in place ofGeneralization (inheritance) to avoid tran
(adding, copying, and deleting of objects)
-
8/3/2019 Software Design Overview
26/27
Slide 1.26Identify candidate entities
For each use case, and other requirement documents- Underline each noun and noun phrase
Some will be class, some will be a class attribute
Some will have no significance
-
8/3/2019 Software Design Overview
27/27
Slide 1.27Challenge the candidate entities
1. Is this candidate inside our system boundary?2. Does this candidate have indentifiable behaviour
for our problem domain?
3. Does this candidate have indentifiable structure?
4. Does this candidate have relationship with other
candidates?