663ae32024e04ae2f147cb9b SystemDesign

SOFTWARE DEVELOPMENT PROJECT (SWP391)
Software Design Guides

Agenda
• General Introduction
• Analysis Modeling
• Software Architecture
• Object Oriented Design
2 / 24
General Introduction
Modelling is the designing of SW applications before coding
• Models are built and analysed prior to the implementation of the
system, and are used to direct the subsequent implementation.
• A graphical modelling language such as UML helps in developing,
understanding, and communicating the different views.
Software design vs implementation
• Software design is a creative activity in which you identify software
components and their relationships, based on a customer’s reqs.
• Implementation is the process of realizing the design as a program.
3 / 24
Incremental Development Model
Evolutionary Prototyping by Incremental Development
4 / 24
General Model of Design Process
5 / 24
Object Oriented Concepts
Objects & Classes 1/2
An object is a real-world physical or conceptual entity that provides an
understanding of the real world and, hence, forms the basis for a software
solution
• A real-world object can have physical properties (they can be seen or
touched): door, motor, lamp,..
• A conceptual object is a more abstract concept (form basis for a computer
solution): an account, a transaction,..
An object (object instance) is a single “thing”: John’s car or Mary’s account
A class (object class) is a collection of objects with the same characteristics:
Account, Employee, Car, or Customer
Object-oriented applications consist of objects.
6 / 24
Objects & Classes 2/2
• An object groups both data & procedures that operate on the data
– The procedures are usually called operations or methods.
– Some approaches, including the UML notation, refer to the operation as the
specification of a function performed by an object and the method as the
implementation of the function
• An attribute is a data value held by an object in a class (account
number, balance,…). Each object has a specific value of an attribute.
• An operation is the specification of a function performed by an object
– An object has one or more operations.
– The operations manipulate the values of the attributes maintained by the object.
– Operations may have input and output parameters.
– All objects in the same class have the same operations.
7 / 24
Information Hiding 1/2
Information hiding is used in designing the object: decide what
information should be visible, what should be hidden
• Hidden parts of an object need not be visible to other objects
• If the internals of the object change -> affect this object only
Encapsulation: the potential change to the hidden information
that could potentially change is encapsulated inside an object
• Other objects may only indirectly access the encapsulated data
structure by calling the operations of the object.
• The specification of the operations (i.e., the name and the params
of the operations) is called the interface of the object.
If the data structure changes, the only object affected is the one
containing the data structure, not the calling object. This form of
information hiding is called data abstraction.
8 / 24
Information Hiding 2/2
The above is Stack

class with a set of
operations is defined
to manipulate the
data structure (array
or linked list)
9 / 24
Object Oriented Methods 1/2
• Object-oriented methods address
fundamental issues of software
modifiability, adaptation, and evolution.
• Object-oriented methods are based on
the concepts of information hiding,
classes, and inheritance.
• The Unified Modeling Language (UML)
was developed to provide a
standardized graphical language and
notation for describing object-oriented
models. However, because UML is
methodology-independent, it needs to
be used together with an object-
oriented analysis and design method.
10 / 24
Object Oriented Methods 2/2
Modern object-oriented analysis and design methods are model-
based and use a combination of use case modeling, static modeling,
state machine modeling, and object interaction modeling.
• In use case modeling, the functional requirements of the system
are defined in terms of use cases and actors.
• Static modeling provides a structural view of the system. Classes
are defined in terms of their attributes, as well as their
relationships with other classes.
• Dynamic modeling provides a behavioral view of the system. The
use cases are realized to show the interaction among participating
objects. Object interaction diagrams are developed to show how
objects communicate with each other to realize the use case. The
state-dependent aspects of the system are defined with
statecharts
11 / 24
Analysis Modeling
Context Modelling 1/5
System Context Diagram
A diagram that explicitly shows the border between the system (hardware
and software), which is treated as a black box, and the external environment
12 / 24
Analysis Modeling
System Context Diagram
Software System Context Diagram
shows the border between the software
system, also treated as a black box, & the
external environment (which now includes
the hardware)
13 / 24
Analysis Modeling
Modeling External Classes
A human user often interacts with the software system by means of standard
I/O devices such as a keyboard/display and mouse
External input device: a device

that only provides input to the
system – for example, a sensor
External output device: a device that only receives output from the system –
for example, an actuator
External I/O device: a device that both provides input to the system and
14 / 24 receives output from the system – for example, an ATM card reader
Analysis Modeling
Modeling External Classes: Actors & External Classes
Actors are a more abstract concept than external classes. The
relationship between actors and external classes is as follows:
• An I/O device actor is equivalent to an external I/O device
class. This means the I/O device actor interfaces to the system
via an external I/O device class.
• An external system actor is equivalent to an external system
class.
• A timer actor interfaces to the system via an external timer
class, which provides timer events to the system.
• A human user actor has the most flexibility. In the simplest
case, the user actor interfaces to the system via standard user
I/O devices, such as keyboard, visual display, and mouse
15 / 24
Analysis Modeling
Banking System software context class diagram with

stereotypes
16 / 24
Analysis Modeling
Static Modeling of Entity Classes 1/3
Entity Relationship Diagram (Data Model)
Entities could represent physical items (including people) or aggregations of data that
are important to the business you’re analyzing or to the system you intend to build
17 / 24
Analysis Modeling
• Entity classes: store data and provide access to this data
• During static modeling of the problem domain, we focus on
determining the entity classes that are defined in the
problem, their attributes, and their relationships
Entity class
model for
online
shopping
system
18 / 24
Analysis Modeling
Modeling Class Attribute
Each class has several attributes that provide information that
distinguishes this class from other classes. Furthermore, each
instance of the class has specific values of these attributes to
differentiate it from other instances of the class
19 / 24
Analysis Modeling
Object & Class Structuring Categories 1/3
1. Entity object. A software object, in many cases persistent, which encapsulates

information and provides access to the information it stores. In some case, an
entity object could be accessed via a service object.
2. Boundary object. Software object that interfaces to and communicates with
the external environment. Boundary objects are further categorized as: user interaction,
proxy, and device I/O boundary objects
3. Control object. Software object that provides the overall coordination for a collection of
objects. Control objects may be coordinator objects, statedependent control objects, or
timer objects
20 / 24
Analysis Modeling
• User Interaction Classes
– A user interaction object communicates directly with the human user,
receiving input from the user and providing output to the user via
standard I/O devices such as the keyboard, visual display, and mouse.
– Depending on the user interface technology, the user interface could
be very simple (such as a command line interface) or it could be more
complex (such as a graphical user interface [GUI] object).
• An external system class interfaces to and communicates with a proxy
class.
• An external device class provides input to and/or receives output from a
device I/O boundary class. Continuing with this classification:
– An external input device class provides input to an input class.
– An external output device class receives output from an output class.
– An external I/O device class provides input to and receives output
from an I/O class.
• An external timer class signals to a software timer class.
21 / 24
Analysis Modeling
Application logic object. Software object that contains the details of
the application logic. Needed when it is desirable to hide the
application logic separately from the data being manipulated because
it is considered likely that the application logic could change
independently of the data.
• For information systems, application logic objects are usually
business logic objects
• For real-time, scientific, or engineering applications, they are
usually algorithm objects.
• Another category is service objects, which provide services for
client objects, typically in service-oriented architectures and
applications
22 / 24
Analysis Modeling
Dynamic Modeling: Communication Diagrams
Communication diagrams show the layout of the objects, particularly how the objects are connected to each
other (object interaction and sequence of messages passed among objects). The interaction sequence among
the objects needs to reflect the interaction sequence between the actor and the system, as described in the UC.
• The UC description (step 1) indicates that the customer requests to create an order => M1, M2
• In step 2 of the UC, the system retrieves the account information => M3, M4
• In step 3 of the UC, the system checks the customer’s credit card => M5, M6
• In step 4 of the UC, the system creates a delivery order => M7, M8
• Next in the UC, the system confirms the order to the user (M9, M10) and sends a confirmation email via the
email service (M9a)
23 / 24
Software Architecture
The design process for identifying the sub-systems
making up a system and the framework for sub-
system control and communication is architectural
design.
Architectural Design
• An early stage of the system design process.
• Represents the link between specification and
design processes.
• Often carried out in parallel with some
specification activities.
• It involves identifying major system components
and their communications.
24 / 24
Architectural Design Decisions
• Is there a generic application architecture that
can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the
system?
• How will the system be decomposed into
modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?
25 / 24
The MVC Pattern 1/3
Name MVC (Model-View-Controller)
Description Separates presentation and interaction from the system data. The system
is structured into three logical components that interact with each other.
• The Model component manages the system data and associated
operations on that data.
• The View component defines and manages how the data is presented
to the user.
• The Controller component manages user interaction (e.g., key
presses, mouse clicks, etc.) and passes these interactions to the View
and the Model.
Example Figure in the next slide shows the architecture of a web-based application
system organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data. Also
used when the future requirements for interaction and presentation of
data are unknown.
Advantages Allows the data to change independently of its representation and vice
versa. Supports presentation of the same data in different ways with
changes made in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model
and interactions are simple.
26 / 24
The MVC Pattern 2/3
The organization of the Model-View-Controller
27 / 24
The MVC Pattern 3/3
Web application architecture using the MVC pattern
28 / 24
The Layered Architecture 1/3
• Used to model the interfacing of sub-systems.
• Organises the system into a set of layers (or abstract
machines) each of which provide a set of services.
• Supports the incremental
development of sub-
systems in different
layers. When a layer
interface changes, only
the adjacent layer is
affected.
29 / 24
Name Layered architecture
Description Organizes the system into layers with related functionality
associated with each layer. A layer provides services to the layer
above it so the lowest-level layers represent core services that
are likely to be used throughout the system
Example A layered model of a system for a web system (an online shop, a
management system, etc.)
When used Used when building new facilities on top of existing systems;
when the development is spread across several teams with each
team responsibility for a layer of functionality; when there is a
requirement for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the
system.
Disadvantages In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately
below it. Performance can be a problem because of multiple
levels of interpretation of a service request as it is processed at
each layer.
30 / 24
Web application architecture using the Layered architecture
31 / 24
The Client-Server Architecture 1/3
• Distributed system model which shows how data and
processing is distributed across a range of components.
– Can be implemented on a single computer.
• Set of stand-alone servers which provide specific services such
as printing, data management, etc.
• Set of clients which call on these services.
• Network which allows clients to access servers.
A client–server architecture for a film library
32 / 24
Name Client-server
Description In a client–server architecture, the functionality of the system

is organized into services, with each service delivered from a
separate server. Clients are users of these services and
access servers to make use of them.
Example Figure in the previous slide is an example of a film and
video/DVD library organized as a client–server system.
When used Used when data in a shared database has to be accessed
from a range of locations. Because servers can be replicated,
may also be used when the load on a system is variable.
Advantages The principal advantage of this model is that servers can be
distributed across a network. General functionality (e.g., a
printing service) can be available to all clients and does not
need to be implemented by all services.
Disadvantages Each service is a single point of failure so susceptible to denial
of service attacks or server failure. Performance may be
unpredictable because it depends on the network as well as
the system. May be management problems if servers are
owned by different organizations.
33 / 24
Web application architecture using the Client-Server architecture
34 / 24
Package Diagrams
35 / 24
Object Oriented Design
• Object-oriented design refers to software systems
that are designed using the concepts of
– Information hiding: encapsulate different kinds of
information (details of a data structure, state machine,..)
– Classes: the design of class interfaces and the operations
provided by each class
– Inheritance: mechanism for sharing and reusing code
between classes - a child class inherits the properties
(encapsulated data and operations) of a parent class.
• Objects are instantiated from classes & are accessed
through operations
– Are also referred to as methods
– The specification and the implementation of a function
performed by an object
36 / 24
Designing Information Hiding Classes
● In design modelling, information hiding classes are
categorized by stereotype.
● Classes determined from the analysis model are
categorized as following:
■ Entity classes from the analysis model, encapsulate data.
■ Boundary classes Communicate with and interface to the
external environment.
■ Active (concurrent) classes: device I/O classes, proxy classes
■ Passive boundary classes: graphical user interaction class
■ Control classes. Provide the overall coordination for a
collection of objects.
■ Control classes are often active (concurrent) classes
■ One of the passive control classes is the state-machine class,
which encapsulates a finite state machine.
■ Application logic classes.
■ Encapsulate application-specific logic and algorithms
■ Categorized as business logic classes, service classes, or
37 / 24
algorithm classes.
Data Abstraction Classes 1/2
● Used to encapsulate the data structure
● Hiding the internal details of how the data structure is represented
● The operations are designed as access procedures or functions whose
internals, which define how the data structure is manipulated, are
also hidden.
● Each entity class in the analysis model that encapsulates data
is designed as a data abstraction class.
● An entity class stores some data and provides operations to
access the data and to read or write to the data.
● In the data abstraction class
● The information on the attributes information should be available
from the static model of the problem domain
● The operations of the data abstraction class are determined by
considering the needs of the client objects that use the data
abstraction object in order to indirectly access the data structure.
This can be determined by analyzing how the data abstraction object
is accessed by other objects, as given in the communication model.
38 / 24
Data Abstraction Classes 2/2
39 / 24
Graphical User Interaction Classes
• A graphical user interaction (GUI) class hides from
other classes the details of the interface to the user.
• In a given application, the user interface might be a
simple command line interface or a sophisticated GUI
• A command line interface is typically handled by one
user interaction class.
40 / 24
Business Logic Classes
A business logic class defines the decision-making, business-
specific application logic for processing a client’s request.
The goal is to encapsulate business rules that could change
independently of each other into separate business logic
classes.
Usually a business logic object accesses various entity objects
during its execution.
41 / 24
Designing Class Interface & Operations 1/2
● The class interface consists of the operations
(methods) provided by each class.
● Each operation can have input parameters,
output parameters, and (if it is a function) a
return value.
● The operations of a class can be determined
typically from the dynamic model
o Interaction message: operations being invoked at the
destination object receiving the message
o Message passing between passive objects consists of
an operation in one object invoking an operation
provided by another object
● From the class diagrams of the static model:
standard operations are create, read, update,
delete (CRUD actions)
42 / 24
Designing Class Interface & Operations 2/2
Designing Class Operations from the Interaction Model
(a) Analysis model: communication diagram.

(b) Design model: communication diagram.
(c) Design model: class diagram
43 / 24
Information Hiding Classes Design 1/4
During detailed design of the information hiding classes, the
internal algorithmic design of each operation is determined. The
operation internals are documented in pseudocode.
Detailed Design of the Account
Abstract Superclass
44 / 24
Detailed Design of
Checking Account
Subclass
45 / 24
Detailed Design of
Savings Account
Subclass 1/2
46 / 24
Detailed Design of
Savings Account
Subclass 2/2
47 / 24
Class Relationships 1/3
Class diagrams are used to model and help understand
the problem domain. Each UC is modelled as a diagram
Relationships between classes

Associations
Composition / Aggregation
48 / 24
Generalization / Specialization
A sample of class diagram for a UC in MVC-Pattern
architecture system (static view)
49 / 24
A sample of class diagram for a UC in MVC-Pattern
architecture system (dynamic view)
50 / 24
Inheritance in Design
• Inheritance can be used when designing two similar, but not
identical, classes (share many, but not all, characteristics).
• A mechanism for sharing and reusing code between classes
• A child class inherits the properties (encapsulated data and
operations) of a parent class
– Super class or Base class
– Subclass or derived class
– Specialization: parent -> child
– Generalization: child -> parent
51 / 24
Inheritance in Design - Abstract Classes
• An abstract class is a class with no instances, used as a
template to create subclasses
• An abstract operation is an operation that is declared in an
abstract class but not implemented.
• In reality, some of the operations may be implemented in the
abstract class, especially in
cases in which some or all
of the subclasses need to
use the same
implementation.
52 / 24
Polymorphism & Dynamic Binding 1/2
● Polymorphism is Greek for “many forms”. In
object-oriented design, polymorphism is used to
mean that different classes may have the same
operation name. The specification of the
operation is identical for each class; however,
classes can implement the operation differently.
● Dynamic binding is used in conjunction with
polymorphism.
● Dynamic binding means that the association of a
request to an object’s operation is done at run-
time and can thus change from one invocation to
the next.
53 / 24
Polymorphism & Dynamic Binding 2/2
Example of Polymorphism and Dynamic Binding
54 / 24

663ae32024e04ae2f147cb9b SystemDesign

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

663ae32024e04ae2f147cb9b SystemDesign

Uploaded by

Copyright:

Available Formats

SOFTWARE DEVELOPMENT PROJECT (SWP391)

Software Design Guides

The above is Stack

External input device: a device

Banking System software context class diagram with

1. Entity object. A software object, in many cases persistent, which encapsulates

Description In a client–server architecture, the functionality of the system

(a) Analysis model: communication diagram.

Relationships between classes

You might also like