Software Engineering

Design

© 2024 Dr. Omar Janeh

University of Technology | Computer Engineering Department
What is Software Design?
● Software design is the process of defining software methods, functions, objects, and
the overall structure and interaction of your code so that the resulting functionality will
satisfy your users requirements.
● Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation.
● Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill
the requirements mentioned in SRS.
● Software design is the act of defining how the requirements defined during analysis
will be implemented in a specific hardware/software environment.
● Software Design is the process of applying various techniques and principles for the
purpose of defining a device, a process, or a system in sufficient detail to permit its
physical realization.
Software Design Levels
● High-Level Design is the general system design means it refers to the overall system
design. It describes the overall description/architecture of the application. It includes
the description of system architecture, database design, brief description on systems,
services, platforms and relationship among modules. It is also known as macro
level/system design. It is created by solution architect. It converts the Business/client
requirement into High Level Solution. It is created first means before Low Level Design.
● Low Level Design describes detailed description of each, and every module means it
includes actual logic for every system component and it goes deep into each modules
specification. It is also known as micro level/detailed design. It is created by designers
and developers. It converts the High-Level Solution into Detailed solution. It is created
second means after High Level Design.

● High‐level design focuses on what. Low‐level design begins to focus on how

Architecture (1/3)
● Architecture is the highest level of design within a system. It is the link
between idea and reality. It takes our idea for the system and creates a plan
for it. We focus on only the largest areas of the system here. We want to
break it down from idea, into concrete areas to build.
● In software, bad architecture is something that CAN'T be fixed with good
programming. It is a critical step within the development process. Once we
decide on an architecture, we must understand that it can't be changed.

● Example: This is the same in the real world. Imagine trying to change the
foundation of the skyscraper once it's built. Same could be said about a
bridge. Imagine trying to switch it from a suspension to a drawbridge after
it's built. These changes would be impossible. The only way to implement
them would be to destroy the product and start over.
Architecture (2/3)
● Software architecture is all about breaking up larger systems and ideas, into smaller
focused systems. Our first step is to take the requirements and build an initial
architecture. We take this broad set of ideas and guidelines and must organize it into
functioning areas.
● Each of these areas are then put through the same process to break them up into
smaller and smaller pieces. Eventually we will have a blueprint for the entire system
designed.
● Good architecture is hard. It takes a lot of resources to develop correctly. However, this
upfront cost is almost always recovered from how maintainable the software is. This
will reduce the number of bugs, and the time to fix those bugs.
● Good architecture also helps for faster development and better resource utilization. If
we break up the project into small pieces, we will understand how to have multiple
developers work at the same time on it.
Architecture (3/3)
● Example: Another benefit of breaking the project up is the idea of buy vs
build. If we have for example 4 development teams. Through architecture
design we have broke the project up into 5 different large projects. We go
through each of these projects and learn that 1 of them has already been
solved before and is for sale on the market. We can then allocate the 4
teams to the other ones, and just purchase the already created software,
saving us time and money.
Architectural Patterns
● An architectural pattern is a proven structural organization schema for
software systems
● A pattern is a description of a set of predefined subsystems and their
responsibilities. In a system structured according to the Client-Server
pattern, for instance, two subsystems are distinguished: the client (which
can have many instances) and the server (which is unique). The
responsibility of the client may be to show a user-interface to the user;
the responsibility of the server may be to process many questions and to
guard data that are of interest to the client.
Why are Patterns Helpful?
● By writing a pattern, it becomes easier to reuse the solution.
● Patterns provide a common vocabulary and understanding of design
solutions.
● Pattern names become part of a widespread design language.
● They remove the need to use a lengthy description to explain a solution to
a particular problem.
● Patterns are therefore a means for documenting software architectures.
● They help maintain the original vision when the architecture is extended
and modified, or when the code is modified (but they cannot guarantee
it).
Examples of Architectural Patterns
● Layered Pattern
● Client-Server Pattern
● Master-Slave Pattern
● Pipe-Filter Pattern
● Broker Pattern
● Peer-to-Peer Pattern
● Event-Bus Pattern
● Model View Controller Pattern
● Blackboard Pattern
● Interpreter Pattern
Layered Pattern
● This pattern can be used to structure programs that can be decomposed
into groups of subtasks, each of which is at a particular level of
abstraction. Each layer provides services to the next higher layer
● Usage:
○ General desktop applications
○ E-commerce web applications
Client-Server Pattern
● This pattern consists of two parties; a server and multiple clients. The
server component will provide services to multiple client components.
Clients request services from the server and the server provides relevant
services to those clients. Furthermore, the server continues to listen to
client requests
● Usage:
○ Online applications such as email, document sharing and banking
https://apptraitsolutions.com/different-software-architectural-patterns-and-how-to-choose-the-right-one-for-your-app/
client applications request services from a database server
Master-Slave Pattern
● This pattern consists of two parties; master and slaves. The master
component distributes the work among identical slave components and
computes a final result from the results which the slaves return.
● Usage:
○ In database replication, the master database is regarded as the authoritative source, and
the slave databases are synchronized to it.
○ Peripherals connected to a bus in a computer system (master and slave drives).
https://apptraitsolutions.com/different-software-architectural-patterns-and-how-to-choose-the-right-one-for-your-app/
sequence diagram for the master-slave pattern
Pipe-Filter Pattern
● This pattern can be used to structure systems which produce and process
a stream of data. Each processing step is enclosed within a filter
component. Data to be processed is passed through pipes. These pipes
can be used for buffering or for synchronization purposes.
● Usage:
○ Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis, and
code generation
○ Workflows in bioinformatics
www.alpharithms.com
Broker Pattern
● This pattern is used to structure distributed systems with decoupled
components. These components can interact with each other by remote
service invocations. A broker component is responsible for the
coordination of communication among components.
● Servers publish their capabilities (services and characteristics) to a broker.
Clients request a service from the broker, and the broker then redirects
the client to a suitable service from its registry.
● Usage:
○ Message broker software such as Apache ActiveMQ, Apache Kafka,
○ RabbitMQ and JBoss Messaging
https://apptraitsolutions.com/different-software-architectural-patterns-and-how-to-choose-the-right-one-for-your-app/
Peer-to-Peer Pattern
● In this pattern, individual components are known as peers. Peers may
function both as a client, requesting services from other peers, and as a
server, providing services to other peers. A peer may act as a client or as a
server or as both, and it can change its role dynamically with time.
● Usage:
○ File-sharing networks such as Gnutella and G2)
○ Multimedia protocols such as P2PTV and PDTP.
○ Cryptocurrency-based products such as Bitcoin and Blockchain
Event-Bus Pattern
● This pattern primarily deals with events and has 4 major components;
event source, event listener, channel and event bus. Sources publish
messages to particular channels on an event bus. Listeners subscribe to
particular channels. Listeners are notified of messages that are published
to a channel to which they have subscribed before.
● Usage:
○ Android development
○ Notification services
Model View Controller Pattern
● This pattern, also known as MVC pattern, divides an interactive
application in to 3 parts as,
● Model: contains the core functionality and data
● View: displays the information to the user (more than one view may be
defined)
● Controller: handles the input from the user
● Usage:
○ Architecture for World Wide Web applications in major programming languages.
○ Web frameworks such as Django and Rails
https://apptraitsolutions.com/different-software-architectural-patterns-and-how-to-choose-the-right-one-for-your-app/
Blackboard Pattern
● This pattern is useful for problems for which no deterministic solution
strategies are known. The blackboard pattern consists of 3 main
components.
● Blackboard: a structured global memory containing objects from the
solution space
● knowledge source: specialized modules with their own representation
● Control component: selects, configures and executes modules.
● Usage:
○ Speech recognition, Vehicle identification and tracking, Protein structure identification,
Sonar signals interpretation: selects, configures and executes modules.
Interpreter Pattern
● Abstract Expression (Expression): Declares an interpret() operation that all nodes
(terminal and nonterminal) in the Abstract Syntax (AST) overrides.
● Terminal Expression (NumberExpression): Implements the interpret() operation for
terminal expressions.
● Nonterminal Expression (Addition Expression, Subtraction Expression, and
Multiplication Expression): Implement operations the interpret() operation for all
nonterminal expressions.
● Context (String): Contains information that is global to the interpreter. It is this String
expression with the Postfix notation that has to be interpreted and parsed.
● Client (ExpressionParser): Builds (or is provided) the AST assembled from Terminal
Expression and NonTerminal Expression. The Client invokes the interpret() operation.
● Usage:
○ Database query languages such as SQL.
○ Languages used to describe communication protocols.

https://springframework.guru/gang-of-four-design-patterns/interpreter-pattern/
Low-Level Design
● The high‐level design should have identified the major types of classes that the application will
use. Now it’s time to refine that design to identify the specific classes that program will need.
The new classes should include definitions of the properties, methods, and events they will
provide for the application to use.
● As an analogy, if you were building a highway system, high‐level design would determine what
cities (and perhaps what parts of those cities) would be connected by highways. The low‐level
design would indicate exactly where the highways would be placed, where the ramps would be,
and what elementary schools would be surrounded by four‐lane traffic circles.
● The border between high‐level and low‐level design is often rather fuzzy. Typically, after a
piece of the system is added to the high‐level design, team members continue working on that
piece to develop its low‐level design. Particularly on a large project, some people will be
working on high-level designs while others work on low‐level designs. Developers may even
start implementing parts of the system that have been adequately defined.
Object Orientation
● Knowing and object-oriented language (such as Java) is a necessary but
insufficient step to create object systems.
● Unified Modeling Language (UML) is just a diagramming tool; it’s full use
isn’t realized without object-oriented design.
UML (1/2)
● It is an industry-standard graphical language for specifying, visualizing,
constructing, and documenting the artifacts of software systems
● The UML uses mostly graphical notations to express the OO analysis and
design of software projects.
● Simplifies the complex process of software design
● Use graphical notation to communicate more clearly than natural
language (imprecise) and code(too detailed).
● Help acquire an overall view of a system.
● UML is not dependent on any one language or technology.
● UML moves us from fragmentation to standardization.
UML (2/2)
● Structure diagrams
○ Class Diagram
○ Component Diagram
○ Deployment Diagram
○ Object Diagram
○ Package Diagram
○ Composite Structure Diagram
○ Profile Diagram
● Behavior diagrams
○ Use Case Diagram
○ Activity Diagram
○ State Machine Diagram
○ Sequence Diagram
○ Communication Diagram
○ Interaction Overview Diagram
○ Timing Diagram
Analysis and Design Activities
More Analysis Oriented More Design Oriented
Object-Oriented Analysis
● Object-Oriented Analysis (OOA) is the first technical activity performed as
part of object-oriented software engineering. OOA introduces new
concepts to investigate a problem. It is based on a set of basic principles,
which are as follows:
○ The information domain is modeled.
○ Behavior is represented.
○ The function is described.
○ Data, functional, and behavioral models are divided to uncover greater detail.
○ Early models represent the essence of the problem, while later ones provide
implementation details.
Object-Oriented Design
● An analysis model created using object-oriented analysis is transformed by
object-oriented design into a design model that works as a plan for software creation.
● OOD results in a design having several different levels of modularity i.e., The major
system components are partitioned into subsystems (a system-level “modular”), and data
manipulation operations are encapsulated into objects (a modular form that is the
building block of an OO system.).
● In addition, OOD must specify some data organization of attributes and a procedural
description of each operation.
● Shows a design pyramid for object-oriented systems. It is having the following four layers:
○ The Subsystem Layer : It represents the subsystem that enables software to achieve user requirements
and implement technical frameworks that meet user needs.
○ The Class and Object Layer : It represents the class hierarchies that enable the system to develop using
generalization and specialization. This layer also represents each object.
○ The Message Layer : It represents the design details that enable each object to communicate with its
partners. It establishes internal and external interfaces for the system.
○ The Responsibilities Layer : It represents the data structure and algorithmic design for all the attributes
and operations for each object.
Object-Oriented Programming Concepts
● Attributes: a collection of data values that describe a class.
● Class: encapsulates the data and procedural abstractions required to describe
the content and behavior of some real-world entity. In other words, A class is a
generalized description that describes the collection of similar objects.
● Objects: instances of a specific class. Objects inherit a class’s attributes and
operations.
● Operations: also called methods and services, provide a representation of one
of the behaviors of the class.
● Subclass: specialization of the superclass. A subclass can inherit both attributes
and operations from a superclass.
● Superclass: also called a base class, is a generalization of a set of classes that
are related to it.
Design Conclusion
● High‐level design sets the stage for later software development. It deals with the
grand decisions such as:
○ What hardware platform will you use?
○ What type of database will you use?
○ What other systems will interact with this one?
○ What reports can you make the users define so you don’t have to do all the work?
● Low‐level design fills in some of the gaps left by high‐level design to provide extra
guidance to developers before they start writing code. It provides the level of detail
necessary for programmers to start writing code, or at least for them to start building
classes and to finish defining interfaces. Low‐level design moves the high‐level focus
from what to a lower-level focus on how .
● Object‐oriented design determines what classes the application uses. Database
design determines what tables the database contains and how they are related.
Object‐oriented design and database design aren’t all you need to do to ensure
success, but poor designs almost always lead to failure.