Software Design

Dasar Pengembangan Sistem Informasi

§ Aryo Pinandito, ST, M.MT

Team Teaching DPSI
Topics covered
§ Software Design
§ Design Quality
§ Structured Design
§ Object-Oriented Design
Software Engineering Process
Activities

Design and Testing and

Specification Evolution
Implementation Validation
Design and implementation
§ Software design and implementation is the stage
in the software engineering process at which an
executable software system is developed.
§ Software design and implementation activities
are invariably interleaved.
§ Software design is a creative activity in which you
identify software components and their relationships,
based on a customer’s requirements.
§ Implementation is the process of realizing the design
as a program.
Build or Buy?
§ In a wide range of domains, it is now possible to
buy off-the-shelf systems (COTS) that can be
adapted and tailored to the users’ requirements.
§ When you develop an application in this way, the
design process becomes concerned with how to
use the configuration features of that system to
deliver the system requirements.

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

§ Component-level design elements

§ Describes the internal detail of software components by way of data
structure definitions, algorithms, and interface specifications
§ Deployment-level design elements
§ Indicates how software functionality and subsystems will be allocated
within the physical computing environment that will support the
software
Task Set for Software Design
Design Data Select
Partition system
Structures as Architectural Style
into subsystem
Domain Model and Patterns

Design interface Create design

Design the UI with external classes or
system components

Design Develop physical

component level deployment
design model
Task Set for Software Design
§ Examine the information domain model and design
appropriate data structures for data objects and their
attributes
§ Using the analysis model, select an architectural style
(and design patterns) that are appropriate for the
software
§ Partition the analysis model into design subsystems
and allocate these subsystems within the
architecture
§ Design the subsystem interfaces
§ Allocate analysis classes or functions to each subsystem
Task Set for
Software Design (2)
§ Create a set of design classes or components
§ Translate each analysis class description into a design class
§ Check each design class against design criteria; consider
inheritance issues
§ Define methods associated with each design class
§ Evaluate and select design patterns for a design class or
subsystem
§ Design any interface required with external systems
or devices
§ Design the user interface
Task Set for
Software Design (3)
§ Conduct component-level design
§ Specify all algorithms at a relatively low level of abstraction
§ Refine the interface of each component
§ Define component-level data structures
§ Review each component and correct all errors uncovered

§ Develop a deployment model

§ Show a physical layout of the system, revealing which
components will be located where in the physical computing
environment
Design Quality
Quality's Role
§ The importance of design is quality
§ Design is the place where quality is fostered
§ Provides representations of software that can be
assessed for quality
§ Accurately translates a customer's requirements into a
finished software product or system
§ Serves as the foundation for all software engineering
activities that follow
Quality's Role
§ Without design, we risk building an unstable
system that:
§ Will fail when small changes are made
§ May be difficult to test
§ Cannot be assessed for quality later in the software
process when time is short and most of the budget has
been spent
§ The quality of the design is assessed through a
series of formal technical reviews or design
walkthroughs
Goals of a Good Design
§ The design must implement all of the explicit
requirements contained in the analysis model
§ It must also accommodate all of the implicit requirements
desired by the customer
§ The design must be a readable and understandable
guide for those who generate code, and for those
who test and support the software
§ The design should provide a complete picture of the
software, addressing the data, functional, and
behavioral domains from an implementation
perspective
21
Pattern-based Software Design
§ Architectural patterns
§ Define the overall structure of software
§ Indicate the relationships among subsystems and software
components
§ Define the rules for specifying relationships among software
elements
§ Design patterns
§ Address a specific element of the design such as an aggregation of
components or solve some design problem, relationships among
components, or the mechanisms for effecting inter-component
communication
§ Consist of creational, structural, and behavioral patterns

§ 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

§ Design the system architecture

§ Component Diagram, Package Diagram

§ Identify the principal system objects

§ Class Diagram

§ Develop design models

§ Class Diagram and Relationships, Sequence Diagram, State Chart
Diagram
§ Specify object interfaces
§ Interface diagram, UI/UX and Layout Design
Example: Use Case Diagram
Example: Sequence Diagram
Example: Class Diagram
Example:
Package
Diagram
Example: Component Diagram
Key points
§ OOD is an approach to design so that design
components have their own private state and
operations
§ Objects should have constructor and inspection
operations. They provide services to other objects
§ Objects may be implemented sequentially or
concurrently
§ The Unified Modeling Language provides different
notations for defining different object models
Key points
§ A range of different models may be produced
during an object-oriented design process. These
include static and dynamic system models
§ Object interfaces should be defined precisely
using e.g. a programming language like Java
§ Object-oriented design simplifies system
evolution
Key points
§ Software design and implementation are inter-
leaved activities. The level of detail in the design
depends on the type of system and whether you
are using a plan-driven or agile approach.
§ The process of object-oriented design includes
activities to design the system architecture,
identify objects in the system, describe the design
using different object models and document the
component interfaces.
Key points
§ A range of different models may be produced during
an object-oriented design process. These include
static models (class models, generalization models,
association models) and dynamic models (sequence
models, state machine models).
§ Component interfaces must be defined precisely so
that other objects can use them. A UML interface
stereotype may be used to define interfaces.
Key points
§ When developing software, you should always consider the
possibility of reusing existing software, either as components,
services or complete systems.
§ Configuration management is the process of managing
changes to an evolving software system. It is essential when a
team of people are cooperating to develop software.
§ Most software development is host-target development. You
use an IDE on a host machine to develop the software, which is
transferred to a target machine for execution.
§ Open source development involves making the source code of
a system publicly available. This means that many people can
propose changes and improvements to the software.
Questions?