SOFTWARE DESIGN AND

ARCITECTURE(SDA)
LECTURE 2

ENGR.RAMSHA MASHOOD
SENIOR LECTURER
DEPARTMENT OF SOFTWARE ENGINEERING
BAHRIA UNIVERSITY KARACHI CAMPUS

July 30, 2024 1

DESIGN PRINCIPLES; OBJECT-
ORIENTED DESIGN WITH UML

July 30, 2024 2

 July 30, 2024 3

TEXT BOOK
OBJECT-ORIENTED ANALYSIS, DESIGN AND
IMPLEMENTATION, BRAHMA DATHAN, SARNATH
RAMNATH, LATEST EDITION, UNIVERSITIES PRESS
 July 30, 2024 4

REFERENCE BOOK
2. SOFTWARE ENGINEERING: A PRACTITIONER’S
APPROACH, ROGER S. PRESSMAN, BRUCE R. MAXIM,
8TH ED, MCGRAW-HILL EDUCATION, 2015. 3.

3. ESSENTIAL SOFTWARE ARCHITECTURE, GORTON I.,

LATEST EDITION, SPRINGER – VERLAG
 SOFTWARE
DESIGN PRINCIPLE
Software design principles are
concerned with providing means to
handle the complexity of the
design process effectively.
Effectively managing the
complexity will not only reduce
the effort needed for design but
can also reduce the scope of
introducing errors during design.
July 30, 2024 5
July 30, 2024 6
Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the problem
into smaller pieces so that each piece can be captured separately.
As the number of partition increases = Cost of partition and complexity
increases

Abstraction
An abstraction is a tool that enables a designer to consider a component at an abstract
level without bothering about the internal details of the implementation. Abstraction can
be used for existing element as well as the component being designed.
Here, there are two common abstraction mechanisms
1. Functional Abstraction
2. Data Abstraction

July 30, 2024 7

Modularity
Modularity specifies to the division of software into separate modules which are
differently named and addressed and are integrated later in to obtain the completely
functional software. It is the only property that allows a program to be intellectually
manageable. Single large programs are difficult to understand and read due to many
reference variables, control paths, global variables, etc.

Strategy of Design
A good system design strategy is to organize the program modules in such a method that
are easy to develop and latter too, change. Structured design methods help developers to
deal with the size and complexity of programs. To design a system, there are two
possible approaches:
1. Top-down Approach
2. Bottom-up Approach

July 30, 2024 8

 Top-down Approach: This approach starts with
the identification of the main components and
then decomposing them into their more detailed
sub-components.

Bottom-up Approach: A bottom-up

approach begins with the lower details and
moves towards up the hierarchy, as shown in
fig. This approach is suitable in case of an
existing system.

July 30, 2024 9

 SOLID Principles:
• Single Responsibility Principle (SRP): A class should have only one reason to
change, meaning it should have only one responsibility or job.

• Open/Closed Principle (OCP): Software entities (classes, modules, functions)

should be open for extension but closed for modification.

• Liskov Substitution Principle (LSP): Subtypes should be substitutable for their

base types without altering the correctness of the program.

• Interface Segregation Principle (ISP): A class should not be forced to

implement interfaces it does not use. Instead of having large, monolithic
interfaces, use smaller, specific ones.

• Dependency Inversion Principle (DIP): High-level modules should not depend

on low-level modules. Both should depend on abstractions. Abstractions should
not depend on details; details should depend on abstractions.
July 30, 2024 10
 WHAT IS MODELING?

• MODELING CONSISTS OF BUILDING AN ABSTRACTION OF

REALITY.
• ABSTRACTIONS ARE SIMPLIFICATIONS BECAUSE:
• THEY IGNORE IRRELEVANT DETAILS AND
• THEY ONLY REPRESENT THE RELEVANT DETAILS.

• WHAT IS RELEVANT OR IRRELEVANT DEPENDS ON THE

PURPOSE OF THE MODEL.
 EXAMPLE
EXAMPLE: STREET MAP
 WHY MODEL SOFTWARE?

WHY MODEL SOFTWARE?

• SOFTWARE IS GETTING INCREASINGLY MORE COMPLEX
• WINDOWS XP > 40 MIO LINES OF CODE
• A SINGLE PROGRAMMER CANNOT MANAGE THIS AMOUNT OF
CODE IN ITS ENTIRETY.

• CODE IS NOT EASILY UNDERSTANDABLE BY DEVELOPERS WHO

DID NOT WRITE IT
• WE NEED SIMPLER REPRESENTATIONS FOR COMPLEX SYSTEMS
• MODELING IS A MEAN FOR DEALING WITH COMPLEXITY
 SYSTEMS, MODELS AND VIEWS
• A MODEL IS AN ABSTRACTION DESCRIBING A SUBSET OF A SYSTEM
• A VIEW DEPICTS SELECTED ASPECTS OF A MODEL
• A NOTATION IS A SET OF GRAPHICAL OR TEXTUAL RULES FOR
DEPICTING VIEWS
• VIEWS AND MODELS OF A SINGLE SYSTEM MAY OVERLAP EACH
OTHER
EXAMPLES:
• SYSTEM: AIRCRAFT
• MODELS: FLIGHT SIMULATOR, SCALE MODEL
• VIEWS: ALL BLUEPRINTS, ELECTRICAL WIRING, FUEL SYSTEM
SYSTEMS, MODELS AND
VIEWS
Flightsimulator
Blueprints
Aircraft

Model 2
View 2
View 1
System
View 3

Model 1

Electrical
Wiring
Scale Model
 MODELS, VIEWS AND SYSTEMS
(UML)
* *
System Model View
Described by Depicted by

Airplane: System

Scale Model: Model Flight Simulator: Model

Blueprints: View Fuel System: View Electrical Wiring: View

 WHAT IS UML?
• A UML DIAGRAM IS A PARTIAL GRAPHICAL
REPRESENTATION (VIEW) OF A MODEL OF A SYSTEM UNDER
DESIGN, IMPLEMENTATION, OR ALREADY IN EXISTENCE.
UML DIAGRAM CONTAINS GRAPHICAL
ELEMENTS (SYMBOLS) - UML NODES CONNECTED WITH
EDGES (ALSO KNOWN AS PATHS OR FLOWS) - THAT
REPRESENT ELEMENTS IN THE UML MODEL OF THE
DESIGNED SYSTEM.
• THE UML MODEL OF THE SYSTEM MIGHT ALSO CONTAIN
OTHER DOCUMENTATION SUCH AS USE CASES WRITTEN AS
TEMPLATED TEXTS..
• SUPPORTED BY SEVERAL CASE TOOLS
• RATIONAL ROSE
• TOGETHERJ
GOALS OF UML
 WHY WE USE UML
Using UML (Unified Modeling Language) offers several advantages in software
development:

1. Visualization and Clarity:

UML provides a visual representation of a software system, making it easier for
stakeholders to understand and discuss complex structures, relationships, and
processes.
2. Communication and Collaboration:
UML serves as a standardized language that facilitates effective communication
among team members and stakeholders with diverse backgrounds. It promotes
collaboration by providing a common understanding of the system.
3. Analysis and Design:
UML supports both the analysis and design phases of software development. It
helps in modeling the problem domain during analysis and provides a basis for
creating detailed specifications and designs during the design phase.
 WHY WE USE UML
1. Consistency and Documentation:
UML enables the creation of consistent and comprehensive documentation for a
software system. This documentation is not only useful for developers but also
serves as a valuable resource for future maintenance and enhancements.
2. Model-Code Consistency:
UML tools often allow for code generation, ensuring consistency between the
design models and the actual implementation. This reduces the risk of
discrepancies between the intended design and the implemented code.
In summary, using UML enhances communication, promotes clarity, and provides
a standardized approach to software modeling, contributing to the overall success
of a software development project.
 TYPES OF CLASSIFICATION
• UML SPECIFICATION DEFINES TWO MAJOR KINDS OF UML DIAGRAM:

• STRUCTURE DIAGRAMS AND BEHAVIOR DIAGRAMS.

• STRUCTURE DIAGRAMS SHOW THE STATIC STRUCTURE OF THE SYSTEM AND

ITS PARTS ON DIFFERENT ABSTRACTION AND IMPLEMENTATION LEVELS AND HOW
THEY ARE RELATED TO EACH OTHER. THE ELEMENTS IN A STRUCTURE DIAGRAM
REPRESENT THE MEANINGFUL CONCEPTS OF A SYSTEM, AND MAY INCLUDE
ABSTRACT, REAL WORLD AND IMPLEMENTATION CONCEPTS.

• BEHAVIOR DIAGRAMS SHOW THE DYNAMIC BEHAVIOR OF THE OBJECTS IN A

SYSTEM, WHICH CAN BE DESCRIBED AS A SERIES OF CHANGES TO THE SYSTEM
OVER TIME.

• UML 2.5 DIAGRAMS COULD BE CATEGORIZED HIERARCHICALLY AS SHOWN BELOW.

NOTE, ITEMS SHOWN IN BLUE ARE NOT PART OF OFFICIAL UML 2.5 TAXONOMY OF
DIAGRAMS.
 STRUCTURE UML
• CLASS DIAGRAMS:
• CLASS DIAGRAMS DEPICT THE STATIC STRUCTURE OF A SYSTEM BY SHOWING
CLASSES, THEIR ATTRIBUTES, METHODS, AND RELATIONSHIPS. THEY ARE
WIDELY USED FOR VISUALIZING THE OVERALL ARCHITECTURE OF A
SOFTWARE SYSTEM.

• OBJECT DIAGRAMS:
• OBJECT DIAGRAMS REPRESENT INSTANCES OF CLASSES AND THE
RELATIONSHIPS BETWEEN THESE INSTANCES AT A SPECIFIC POINT IN TIME.
THEY PROVIDE A SNAPSHOT OF THE SYSTEM'S STRUCTURE DURING RUNTIME.

• PACKAGE DIAGRAMS:
• PACKAGE DIAGRAMS SHOW THE ORGANIZATION AND DEPENDENCIES AMONG
PACKAGES IN A SYSTEM. THEY HELP IN ORGANIZING AND MANAGING LARGE-
SCALE SYSTEMS BY GROUPING RELATED ELEMENTS INTO PACKAGES.
 STRUCTURE UML
• COMPONENT DIAGRAMS:
• COMPONENT DIAGRAMS REPRESENT THE PHYSICAL COMPONENTS (E.G.,
EXECUTABLE FILES, LIBRARIES) OF A SYSTEM AND THEIR RELATIONSHIPS.
THEY FOCUS ON THE ORGANIZATION AND DEPENDENCIES OF THESE
COMPONENTS.

• COMPOSITE STRUCTURE DIAGRAMS:

• COMPOSITE STRUCTURE DIAGRAMS ILLUSTRATE THE INTERNAL STRUCTURE
OF A CLASS OR COMPONENT, SHOWING HOW PARTS AND PORTS ARE
INTERCONNECTED. THEY PROVIDE A DETAILED VIEW OF THE
COLLABORATION WITHIN A COMPLEX STRUCTURE.

• DEPLOYMENT DIAGRAMS:
• DEPLOYMENT DIAGRAMS MODEL THE PHYSICAL DEPLOYMENT OF SOFTWARE
COMPONENTS TO HARDWARE NODES. THEY SHOW HOW SOFTWARE
ARTIFACTS ARE DISTRIBUTED ACROSS DIFFERENT NODES IN A NETWORK.
 BEHAVIORAL UML
• USE CASE DIAGRAMS:
• USE CASE DIAGRAMS DEPICT THE INTERACTIONS BETWEEN A SYSTEM AND ITS
EXTERNAL ACTORS. THEY ILLUSTRATE THE VARIOUS USE CASES AND THEIR
RELATIONSHIPS, PROVIDING A HIGH-LEVEL VIEW OF SYSTEM FUNCTIONALITY
FROM A USER'S PERSPECTIVE.

• SEQUENCE DIAGRAMS:
• SEQUENCE DIAGRAMS SHOW THE INTERACTIONS BETWEEN DIFFERENT
OBJECTS OR COMPONENTS OVER TIME. THEY DEPICT THE ORDER IN WHICH
MESSAGES ARE EXCHANGED BETWEEN OBJECTS, HELPING TO VISUALIZE THE
DYNAMIC BEHAVIOR OF A SYSTEM DURING A SPECIFIC SCENARIO OR
OPERATION.

• COLLABORATION DIAGRAMS (COMMUNICATION DIAGRAMS):

• COLLABORATION DIAGRAMS FOCUS ON THE INTERACTIONS AND
COLLABORATIONS BETWEEN OBJECTS. THEY EMPHASIZE THE STRUCTURAL
ORGANIZATION OF OBJECTS AND THE MESSAGES EXCHANGED AMONG THEM.
 BEHAVIORAL UML
• ACTIVITY DIAGRAMS:
• ACTIVITY DIAGRAMS MODEL THE WORKFLOW OR FLOW OF ACTIVITIES WITHIN A SYSTEM. THEY
ARE USED TO REPRESENT THE DYNAMIC ASPECTS OF A SYSTEM, INCLUDING ACTIONS,
DECISIONS, AND CONCURRENCY.

• STATE MACHINE DIAGRAMS:

• STATE MACHINE DIAGRAMS DEPICT THE STATES THAT AN OBJECT OR SYSTEM CAN BE IN AND
THE TRANSITIONS BETWEEN THESE STATES. THEY ARE PARTICULARLY USEFUL FOR MODELING
THE BEHAVIOR OF OBJECTS THAT UNDERGO DIFFERENT STATES IN RESPONSE TO EVENTS.

• INTERACTION OVERVIEW DIAGRAMS:

• INTERACTION OVERVIEW DIAGRAMS PROVIDE AN OVERVIEW OF THE INTERACTIONS BETWEEN
DIFFERENT ELEMENTS IN A SYSTEM. THEY COMBINE ELEMENTS OF ACTIVITY DIAGRAMS AND
SEQUENCE DIAGRAMS TO REPRESENT THE FLOW OF CONTROL BETWEEN VARIOUS ACTIVITIES.

• TIMING DIAGRAMS:
• TIMING DIAGRAMS FOCUS ON THE TIMING CONSTRAINTS AND INTERACTIONS BETWEEN
OBJECTS IN A SYSTEM. THEY REPRESENT THE TIMING OF MESSAGES AND EVENTS OVER A
SPECIFIC PERIOD, HELPING TO VISUALIZE THE TEMPORAL ASPECTS OF A SYSTEM.
 UML FIRST PASS: USE CASE
DIAGRAMS
Package Use case
Watch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view
 UML FIRST PASS: CLASS
DIAGRAMS
Association
Class

Multiplicity Watch
1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
referesh()

Attribute
Operations
 UML FIRST PASS: SEQUENCE DIAGRAM
Actor Object

:Watch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Activation
Lifeline

Sequence diagrams represent the behavior as interactions

 UML FIRST PASS: STATECHART DIAGRAMS FOR
OBJECTS WITH INTERESTING DYNAMIC BEHAVIOR
State
Event
Initial state
[button2Pressed]
[button1&2Pressed]
BlinkHours IncrementHrs

[button1Pressed]
Transition

[button1&2Pressed] [button2Pressed]
BlinkMinutes IncrementMin.

[button1Pressed]

[button1&2Pressed] [button2Pressed]

BlinkSeconds IncrementSec.

StopBlinking
Final state

Represent behavior as states and transitions

 SOME LINKS

• HTTPS://WWW.UML-DIAGRAMS.ORG/UML-25-DIAGRAMS.HTML
• HTTPS://WWW.LUCIDCHART.COM/PAGES/WHAT-IS-UML-UNIFIED-MODELING-L
ANGUAGE/#SECTION_0
ANY THING TO ASK ??