Professional Documents
Culture Documents
For example, if you want to implement a medical records system, you can buy
a package that is already used in hospitals. It can be cheaper and faster.
Purpose of Design
§ Design is where customer requirements, business
needs, and technical considerations all come
together in the formulation of a product or
system
§ The design model provides detail about the
software data structures, architecture,
interfaces, and components
6
How to Design?
§ The design model can be assessed for quality and be
improved before code is generated and tests are
conducted
§ A designer must practice diversification and
convergence
§ Find as much alternatives as possible, then choose the
suitable one
§ Software design is an iterative process through which
requirements are translated into a blueprint for
constructing the software
§ Begin from high-level design to detailed-level design
Purpose of Design (continued)
§ Software design is an iterative process through
which requirements are translated into a
blueprint for constructing the software
§ Design begins at a high level of abstraction that can be
directly traced back to the data, functional, and
behavioral requirements
§ As design iteration occurs, subsequent refinement leads
to design representations at much lower levels of
abstraction
Purpose of Design (continued)
§ The design model can be assessed for quality and be improved
before code is generated and tests are conducted
§ Does the design contain errors, inconsistencies, or omissions?
§ Are there better design alternatives?
§ Can the design be implemented within the constraints, schedule, and
cost that have been established?
§ A designer must practice diversification and convergence
§ The designer selects from design components, component solutions,
and knowledge available through catalogs, textbooks, and experience
§ The designer then chooses the elements from this collection that meet
the requirements defined by requirements engineering and analysis
modeling
§ Convergence occurs as alternatives are considered and rejected until
one particular configuration of components is chosen
Purpose of Design (continued)
§ Software design is an iterative process through
which requirements are translated into a
blueprint for constructing the software
§ Design begins at a high level of abstraction that can be
directly traced back to the data, functional, and
behavioral requirements
§ As design iteration occurs, subsequent refinement leads
to design representations at much lower levels of
abstraction
From Analysis Model to
Design Model
§ The data/class design transforms analysis classes into design
classes along with the data structures required to implement
the software
§ The architectural design defines the relationship between
major structural elements of the software; architectural styles
and design patterns help achieve the requirements defined for
the system
§ The interface design describes how the software
communicates with systems that interoperate with it and with
humans that use it
§ The component-level design transforms structural elements
of the software architecture into a procedural description of
software components
From Analysis Model to
Design Model
Component-level Design
(Class-based model,
Flow-oriented model, Behavioral model)
Interface Design
(Scenario-based model,
Flow-oriented model, Behavioral model) Deployment-level
Design
Architectural Design
(Class-based model, Flow-oriented model)
Data/Class Design
(Class-based model, Behavioral model)
Design Elements
§ Data/class design
§ Creates a model of data and objects at a high level of abstraction
§ Architectural design
§ Depicts the overall layout of the software
§ Interface design
§ Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the
architecture
§ Includes the user interface, external interfaces, and internal interfaces
§ Coding patterns
§ Describe language-specific patterns that implement an algorithmic
or data structure element of a component, a specific interface
protocol, or a mechanism for communication among components
Design Quality Guidelines
§ A design should exhibit an architecture that
§ Has been created using recognizable architectural styles or patterns
§ Is composed of components that exhibit good design characteristics
§ Can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing
§ A design should be modular; that is, the software should be
logically partitioned into elements or subsystems
§ A design should contain distinct representations of data,
architecture, interfaces, and components
§ A design should lead to data structures that are appropriate for
the classes to be implemented and are drawn from
recognizable data patterns
Quality Guidelines (continued)
§ A design should lead to components that exhibit
independent functional characteristics
§ A design should lead to interfaces that reduce the
complexity of connections between components and
with the external environment
§ A design should be derived using a repeatable
method that is driven by information obtained during
software requirements analysis
§ A design should be represented using a notation that
effectively communicates its meaning
Design
Methodologies
Well-known Software
Development Methodologies
§Structured
§ Based on process approach
§Object-Oriented
§ Based on object/data approach
Structured
Structured Methodologies
§ SDLC,
§ gives a measure of control, but little help in improving
the productivity and quality of analysis and design.
§ 1970’s: structured methodologies developed
§ to promote more effective analysis and more
§ stable /maintainable designs.
§ more largely process-oriented:
§ minor on modeling of entities and data
Tools for Structured
Methodologies
§ Dataflow diagram(DFD): Process/flow of data
§ Data Dictionary: definition, ”encyclopedias”
§ Entity relationship diagram(ERD):
§ Hierarchy diagram: simple top-down connection
§ Software-spec: English specification of logic, process
§ State-transition diagram: possible states
§ Structure chart: architecture of system
Example: DFD
Example: Data Dictionary
Example: ER Diagram
Example: Hierarchy Diagram
Example: State Transition
Diagram
Object-Oriented
Object-Oriented Methodology
§ Objects are abstractions of real-world or system
entities and manage themselves
§ Objects are independent and encapsulate (have)
state and representation information.
§ System functionality is expressed in terms of object
services
§ Shared data areas are eliminated, Objects
communicate by message passing
§ Objects may be distributed and may execute
sequentially or in parallel
Advantages of OOD
§ Easier maintenance. Objects may be
understood as stand-alone entities
§ Objects are appropriate reusable components
§ For some systems, there may be an obvious
mapping from real world entities to system
objects
Object-oriented development
§ Object-oriented analysis, design and
programming are related but distinct
§ OOA is concerned with developing an object
model of the application domain
§ OOD is concerned with developing an object-
oriented system model to implement
requirements
§ OOP is concerned with realising an OOD using an
OO programming language such as Java or C++
Objects and object classes
§ Objects are entities in a software system which
represent instances of real-world and system
entities
§ Object classes are templates for objects. They
may be used to create objects
§ Object classes may inherit attributes and services
from other object classes
Objects and Classes
§ An object is an entity which has a state and a defined set
of operations which operate on that state. The state is
represented as a set of object attributes. The operations
associated with the object provide services to other
objects (clients) which request these services when some
computation is required.
§ Objects are created according to some object class
definition. An object class definition serves as a template
for objects. It includes declarations of all the attributes
and services which should be associated with an object of
that class.
Object-Oriented Concepts
§ Object and Class
§ Messages
§ Generalization and Inheritance
§ Abstract Class
§ Interface
§ Polymorphism
The Unified Modeling
Language
§ Several different notations for describing object-
oriented designs were proposed in the 1980s and
1990s
§ The Unified Modeling Language is an integration
of these notations
§ It describes notations for a number of different
models that may be produced during OO analysis
and design
§ It is now a de facto standard for OO modelling
An object-oriented design
process
§ Define the context and modes of use of the system
§ Use Case Diagram, Use Case Description and Specification