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
4 / 24
 Intro: Incremental Development Model

Evolutionary Prototyping by Incremental Development

5 / 24
 Intro: General Model of Design Process

6 / 24
 OO 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 (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 (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.

7 / 24
 OO Concepts: Objects & Classes 2/2

• An object groups both data & procedures that operate on the data
o The procedures are usually called operations or methods.
o 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
o An object has one or more operations.
o The operations manipulate the values of the attributes maintained by the object.
o Operations may have input and output parameters.
o All objects in the same class have the same operations.

8 / 24
 OO Concepts: 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.

9 / 24
 OO Concepts: Information Hiding 2/2

Stack class with a set of operations is defined to manipulate the data structure
(array or linked list)

10 / 24
 Intro: 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.

11 / 24
 Intro: 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
state charts
12 / 24
 Agenda

• General Introduction

• Analysis Modeling
• Context Modelling
• Software Architecture • Static Modelling of Entity Classes
• Object & Class Structuring Categories
• Object Oriented Design • Dynamic Modelling: Comm Diagrams

13 / 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

14 / 24
 Analysis Modeling: Context Modelling 2/5

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)
System Context
Diagram

15 / 24
 Analysis Modeling: Context Modelling 3/5

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 receives output from the
system – for example, an ATM card reader

16 / 24
 Analysis Modeling: Context Modelling 4/5

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
17 / 24
 Analysis Modeling: Context Modelling 5/5

Banking System software context class diagram with stereotypes

18 / 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

19 / 24
 Analysis Modeling: Static Modeling of Entity Classes 2/3

• 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
20 / 24
 Analysis Modeling: Static Modeling of Entity Classes 3/3

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

21 / 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, state-dependent control objects,
or timer objects

22 / 24
23 / 24
 Analysis Modeling: Object & Class Structuring Categories 2/3

• User Interaction Classes

o A user interaction object communicates directly with the human user, receiving input from
the user & providing output to the user via standard I/O devices such as the keyboard,
visual display, and mouse.
o Depending on the UI technology, the UI could be very simple (such as a command line
interface) or more complex (such as a 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:
o An external input device class provides input to an input class.
o An external output device class receives output from an output class.
o 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.

24 / 24
 Analysis Modeling: Object & Class Structuring Categories 3/3

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: usually business logic objects
• For real-time, scientific, or engineering applications: usually algorithm objects.
• For service-oriented architectures and applications: service objects, which provide
services for client objects

25 / 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 & 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)
26 / 24
27 / 24
 Agenda

• General Introduction

• Analysis Modeling

• Software Architecture
• MVC Pattern
• Object Oriented Design • Layered Architecture
• Client-Server Architecture
• Package Diagrams

28 / 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.

29 / 24
 Software Architecture: 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?

30 / 24
 Software Architecture: 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.
31 / 24
 Software Architecture: The MVC Pattern 2/3

The organization of the Model-View-Controller

32 / 24
 Software Architecture: The MVC Pattern 3/3

Web application architecture using the MVC pattern

33 / 24
 Software Architecture: 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.

34 / 24
 Software Architecture: The Layered Architecture 2/3

Name Layered architecture

Organizes the system into layers with related functionality associated with each layer. A
Description 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.)

Used when building new facilities on top of existing systems; when the development is
When used spread across several teams with each team responsibility for a layer of functionality; when
there is a requirement for multi-level security.
Allows replacement of entire layers so long as the interface is maintained. Redundant
Advantages facilities (e.g., authentication) can be provided in each layer to increase the dependability of
the system.
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
Disadvantages
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.

35 / 24
 Software Architecture: The Layered Architecture 3/3

Web application architecture using the Layered architecture

36 / 24
 Software Architecture: The Client-Server Architecture 1/3

• Distributed system model which shows how data and processing is distributed
across a range of components.
oCan 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

37 / 24
 Software Architecture: The Client-Server Architecture 2/3

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.

38 / 24
 Software Architecture: The Client-Server Architecture 3/3

Web application architecture using the Client-Server architecture

39 / 24
 Software Architecture: Package Diagrams

40 / 24
 Agenda

• General Introduction

• Analysis Modeling

• Software Architecture
• MVC Pattern
• Object Oriented Design • Layered Architecture
• Client-Server Architecture
• Dynamic Modelling: Comm Diagrams

41 / 24
 Object Oriented Design

• Object-oriented design refers to software systems that are designed

using the concepts of
o Information hiding: encapsulate different kinds of information (details of a data
structure, state machine,..)
o Classes: the design of class interfaces and the operations provided by each class
o 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
o Are also referred to as methods
o The specification and the implementation of a function performed by an object

42 / 24
Object Oriented Design: 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 algorithm classes.

43 / 24
 Object Oriented Design : 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.
44 / 24
 Object Oriented Design : Data Abstraction Classes 2/2

45 / 24
 Object Oriented Design
Graphical User Interaction Classes

• A 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.

46 / 24
 Object Oriented Design
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.
A business logic object accesses various entity objects during its execution.

47 / 24
 Object Oriented Design: 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)
48 / 24
 Object Oriented Design
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

49 / 24
 Object Oriented Design: 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

50 / 24
 Object Oriented Design: Information Hiding Classes Design 2/4

Detailed Design of Checking Account

Subclass

51 / 24
 Object Oriented Design: Information Hiding Classes Design 3/4

Detailed Design of Savings Account

Subclass 1/2

52 / 24
 Object Oriented Design: Information Hiding Classes Design 4/4

Detailed Design of Savings Account Subclass 2/2

53 / 24
 Object Oriented Design: 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

o Associations
o Composition / Aggregation
o Generalization / Specialization
54 / 24
 Object Oriented Design: Class Relationships 2/3

A sample of class diagram for a UC in MVC-Pattern architecture system (static

view)

55 / 24
 Object Oriented Design: Class Relationships 3/3

A sample of class diagram for a UC in MVC-Pattern architecture system (dynamic

view)

56 / 24
 Object Oriented Design: 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
o Super class or Base class
o Subclass or derived class
o Specialization: parent -> child
o Generalization: child -> parent
57 / 24
 Object Oriented Design: 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.
58 / 24
 Object Oriented Design: 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.

59 / 24
 Object Oriented Design: Polymorphism & Dynamic Binding 2/2

Example of Polymorphism and Dynamic Binding

60 / 24
61 / 24