This document provides an outline for a lecture on software design and architecture. It discusses key concepts like classes and objects, visibility, class diagrams, sequence diagrams, and design patterns. The document also includes disclaimers about the source of the material and its intended educational use.

1. Ms. Memoona Sami
Memoona.sami@faculty.muet.edu.pk
SOFTWARE DESIGN AND ARCHITECTURE
LECTURE 22,23
Disclaimer: The contents of this
presentation have been taken from
multiple sources, i.e. Books,
Research articles, Thesis
publications, and websites.

2. The material used in this presentation i.e., pictures/graphs/text, etc. is solely
intended for educational/teaching purpose, offered free of cost to the students for
use under special circumstances of Online Education due to COVID-19 Lockdown
situation and may include copyrighted material - the use of which may not have
been specifically authorised by Copyright Owners. It’s application constitutes Fair
Use of any such copyrighted material as provided in globally accepted law of many
countries. The contents of presentations are intended only for the attendees of the
class being conducted by the presenter.
Fair Use Notice

3. Outlines
Classes and Objects
Visibility
Class Diagram
Sequence Diagram
Design Pattern
Essential Elements Of A Design Pattern
Template
Types Of Design Patterns

4. Classes And Objects
Class
A class is a user defined blueprint or prototype from
which objects are created.
It represents the set of properties or methods that are
common to all objects of one type.
Constructors are used for initializing new objects.
Fields are variables that provides the state of the class and
its objects.
Methods are used to implement the behaviour of the
class and its objects.

5. Classes And Objects
Object
It is a basic unit of Object Oriented Programming and represents the real life entities.
Objects interact by invoking methods.
An object consists of :
State : It is represented by attributes of an object. It also reflects the properties of an object.
Behaviour : It is represented by methods of an object. It also reflects the response of an object with other objects.
Identity : It gives a unique name to an object and enables one object to interact with other objects.
All the instances share the attributes and the behaviour of the class, but the values of those attributes,
i.e. the state, are unique for each object.

6. Visibility
Classes can also be extended by adding a second class, called a subclass, which adds to and
modifies the rules of the parent class.
This is very important for understanding why and how visibility works
A subclass can override a property or method.
Visibility allows you to control where your class members can be accessed from
for instance, to prevent a certain variable to be modified from outside the class.

7. Visibility
There are three visibility levels for properties and methods of a class
public,
protected, and
private.

8. Visibility
Public
This level has no restrictions
It can be called in any scope.
A public property of an object can be both, retrieved and modified, from anywhere in a program
 in the class, a subclass, or from outside of the class
Protected
Protected properties and methods can be accessed from inside the class they are declared, or in any class that
extends them.
They can’t be accessed from outside the class or subclass.
Private
More restrictive.
A private property or method can’t be accessed by a subclass of the class it is defined in.
 If you have a class with a protected property and a private property and then extend that class in the subclass, you can access the protected
property, but not the private property.

9. Class Diagram
It represents the static view of an application.
 Class diagram is not only used for visualizing, describing and documenting different aspects of
a system but also for constructing executable code of the software application.
The class diagrams can be mapped directly with object oriented languages. (used at the time of
construction)
A class diagram is an illustration of the relationships and source code dependencies among
classes in the Unified Modeling Language (UML).
In this context, a class defines the methods and variables in an object, which is a specific entity
in a program or the unit of code representing that entity.

10. Purpose
Analysis and design of the static view of an application.
Show the collaboration among the elements of the static view.
Describe the functionalities performed by the system.
Construction of software applications using object oriented languages.
Forward and reverse engineering.

11. Notation
Classes are portrayed as boxes, each box having three rectangles inside.
The top rectangle contains the name of the class; the middle rectangle contains the attributes
of the class; the lower rectangle contains the methods, also called operations, of the class.
Lines, which may have arrows at one or both ends, connect the boxes. These lines define the
relationships, also called associations, between the classes.

12. Guidelines
The name of the class diagram should be meaningful to describe the aspect of the system.
Relationships should be identified
Responsibility (attributes and methods) of each class should be clearly identified.
Use notes when ever required to describe some aspect of the diagram. Because at the end of
the drawing it should be understandable to the developer/coder.

13. Relationships In Class Diagrams
Association: is a broad term that encompasses just about
any logical connection or relationship between classes.
Inheritance/Generalization
Realization: denotes the implementation of the
functionality defined in one class by another class

14. Relationships In Class Diagrams
Aggregation: refers to the formation of a particular class as
a result of one class being aggregated or built as a collection.
For example, the class “library” is made up of one or more
books, among other materials. In aggregation, the contained
classes are not strongly dependent on the life cycle of the
container. In the same example, books will remain so even
when the library is dissolved.

15. Relationships In Class Diagrams
Composition: Composition is very similar to the aggregation
relationship, with the only difference being its key purpose of
emphasizing the dependence of the contained class to the
life cycle of the container class

16. Multiplicity
It is the active logical association when the cardinality of a class in relation to another is being
depicted. For example, one fleet may include multiple airplanes, while one commercial airplane
may contain zero to many passengers. The notation 0..*

17. Sample Class Diagram

18. Sequence Diagram
The Sequence Diagram models the collaboration of objects based on a time sequence.
It depicts the objects and classes involved in the scenario and the sequence of messages
exchanged between the objects needed to carry out the functionality of the scenario.
Sequence diagrams are typically associated with use case realizations in the Logical View of the
system under development.
Sequence Diagrams are interaction diagrams that detail how operations are carried out.

19. Notation
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.

20. Sequence Diagram

21. Purpose
To capture dynamic behavior of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.

22. Sequence diagram

23. What Is A Design Pattern?
In software engineering, a design pattern is a general reusable solution to a commonly
occurring problem in software design.
A design pattern is not a finished design that can be transformed directly into code.
It is a description or template for how to solve a problem that can be used in many different
situations.
Design patterns can speed up the development process by providing tested, proven
development paradigms.
People only understand how to apply certain software design techniques to certain problems.

24. The idea was introduced by the architect Christopher Alexander in the field of architecture but
has been adapted for other disciplines.
“Each pattern describes a problem which occurs over and over again in our environment, and
then describes the core of the solution to that problem, in such a way that you can use this
solution a million times over, without ever doing it the same way twice”.
What Is A Design Pattern?

25. Essential Elements Of A Pattern
NAME: The pattern name is a handle we can use to describe a design problem, its solutions,
and consequences in a word or two.
PROBLEM: The problem describes when to apply the pattern. It explains the problem and its
context.
SOLUTION: The solution describes the elements that make up the design, their relationships,
responsibilities, and collaborations.

26. Describing Design Patterns
We will learn and describe design patterns according to a template.
The template lends a uniform structure to the information, making design patterns easier to
learn, compare, and use.

27. Template
Pattern name and classification: The pattern's name conveys the essence of the pattern. A
good name is vital, because it will become part of your design vocabulary.
Intent: A short statement that answers the following questions: What does the design pattern
do? What is its intent? What particular design issue or problem does it address?
Also Known As: Other well-known names for the pattern, if any.

28. Motivation: A scenario that illustrates a design problem and how the class and object
structures in the pattern solve the problem. The scenario will help you understand the more
abstract description of the pattern that follows.
Applicability: What are the situations in which the design pattern can be applied? What are
examples of poor designs that the pattern can address? How can you recognize these situations?
Structure: A graphical representation of the classes in the pattern using a notation based on
the Object Modeling Technique (OMT)
Template

29. Participants: The classes and/or objects participating in the design pattern and their
responsibilities.
Collaborations: How the participants collaborate to carry out their responsibilities.
Consequences: How does the pattern support its objectives? What are the trade-offs and
results of using the pattern?
Implementation: What pitfalls, hints, or techniques should you be aware of when
implementing the pattern? Are there language-specific issues.
Template

30. Types Of Design Patterns
Design patterns can be (roughly) grouped into three categories:
Creational patterns (For constructing objects)
Creational patterns are used to create objects of the right class for a problem, generally when instances
of several different classes are available. They are particularly useful when you are taking advantage
of polymorphism and need to choose between different classes at runtime rather than compile time.
Structural patterns
Controlling the structure of a class
Structural patterns form larger structures from individual parts, generally of different classes. Structural
patterns vary a great deal depending on what sort of structure is being created for what purpose.

31. Types Of Design Patterns
Behavioral patterns
Deal with how the object behaves
Behavioral patterns describe interactions between objects and describe division of responsibility.
They focus on how objects communicate with each other. They can reduce complex flow charts to mere
interconnections between objects of various classes. You will learn how to use behavioral patterns to
reduce complicated flow control.

32. 32
Creational Design Patterns
Abstract Factory
Builder
Factory Method
Prototype
Singleton

33. 33
Structural Patterns
Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy

34. 34
Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor