9/16/24

DA-IICT

IT313: Software Engineering

Design (Why?)

Saurabh Tiwari

“Software Systems” – Designing (Why?)

Software Systems have many components and

interactions

• External conditions can trigger unexpected changes

• The problem is beyond the control of any single individual
• Changes forces participants to look for new solutions
• Several participant need to cooperate and develop desired
solution
• We are interested in Software-Intensive Systems

Managing Complexity
&
Changeability

1
 9/16/24

W5H2

Why OO?
What is OOAD?
Who...
When...
Where...
How to do OOAD?
How much...

Object-Oriented Modeling and Design

• Is a way of thinking about the problems using models organized

around real-world concepts
• Concept: Object

2
 9/16/24

Real-World Objects

• OO means that we organize software as a collection of discrete

objects that incorporate both data structure and behavior.

Bicycle Class

Attributes
Frame size
Abstract Wheel size
into Number of gears
Material
Operations
Shift
Move
Repair

Bicycle Objects

Real-World Objects

• Have identity and are distinguishable

• Identity means that data is quantized into discrete,
distinguishable entities called Objects
• Share two characteristics – State and Behavior

3
 9/16/24

Process ...

Why Object-Oriented?

• “The "software crises" came about when people realized the major
problems in software development were … caused by
communication difficulties and the management of complexity”
[Budd]

What kind of language can alleviate difficulties with communication &

complexity?

4
 9/16/24

Why Object-Oriented? Concepts and Objects

• Study of a first grade class [Martin & Odell][Novak, 1984, Cambridge

University Press]

• When given a list of concepts (water, salt water, Oceans, Penguins,...),

• Harry constructed a concept diagram through which he understands his world and
communicates meaning

Do you understand what Harry Understands?

Why Object-Oriented? for Conceptual ... Modeling

Reasons...

• What kind of language can be used to create this concept diagram,

or Harry’s mental image?

Things, Relationships and Diagram

5
 9/16/24

Why Object-Oriented? -> for Modeling

• A model is a simplification of reality.

– Well...sort of….but not quite
• A model is our simplification of our perception of reality

What is Object-Orientation? What is object?

6
 9/16/24

What is Object-Orientation?
Classification à classes à Instantiation

What is Object-Orientated Application?

• Collection of discrete objects, interacting with each other

• Objects have property and behavior
• Interactions through message passing

O1, O2 and O3 are discrete Objects

7
 9/16/24

What is OOAD?

Analysis — understanding, finding and describing concepts in the

problem domain.

Design — understanding and defining software solution/objects

that represent the analysis concepts and will eventually be
implemented in code.

OOAD — Analysis is object-oriented and design is object-oriented.

A software development approach that emphasizes a logical
solution based on objects.

Traceability!!!

How to DO OOAD?

Notation Vs Process…

Unifying Modeling Language (UML) is a Notation

So are English, Elivish, Ku …..

8
 9/16/24

Where to use OOAD?

What is the problem with this Drawing?

9
 9/16/24

Abstraction

• Complex systems are hard to understand

• The 7 +- 2 phenomena
• Our short term memory cannot store more than 7+-2 pieces
at the same time -> limitation of the brain
• TUM Phone Number: 498928918204

• Chunking:
• Group collection of objects to reduce complexity
• State-code, city-code, TUM-code, Office-Part

TUM Phone Number

State-Code City-Code TUM-code Office-Part

Abstraction

• Abstraction allows us to ignore unessential details

• Two definitions for abstraction:

• Abstraction is a thought process where ideas are distanced from
objects
• Abstraction as activity
• Abstraction is the resulting idea of a thought process where an
idea has been distanced from an object
• Abstraction as entity

• Ideas can be expressed by models

10
 9/16/24

Abstraction

• Define levels of abstractions

• Define models at these levels

• Define transformation of models from

higher to lower levels

• Implement

We use Models to describe Software Systems

• Object model: What is the structure of the system? What

are the objects and how are they related?

• Functional model: What are the functions of the system?

How is data flowing through the system?

• Dynamic model: How does the system react to external

events? How is the event flow in the system ?

• System Model: Object model + functional model + dynamic

model

11
 9/16/24

Other models used to describe Software Development

• Task Model:
– PERT Chart: What are the dependencies between tasks?
– Schedule: How can this be done within the time limit?
– Organization Chart: What are the roles in the project?

• Issues Model:
– What are the open and closed issues?
• What blocks me from continuing?
– What constraints were imposed by the client?
– What resolutions were made?
• These lead to action items

Technique to deal with Complexity: Decomposition

• A technique used to master complexity (“divide and conquer”)

• Two major types of decomposition

– Functional decomposition
– Object-oriented decomposition

• Functional decomposition
– The system is decomposed into modules
– Each module is a major function in the application domain
– Modules can be decomposed into smaller modules.

12
 9/16/24

Decomposition (cont’d)

• Object-oriented decomposition
– The system is decomposed into classes (“objects”)
– Each class is a major entity in the application domain
– Classes can be decomposed into smaller classes

• Object-oriented vs. functional decomposition

Which decomposition is the right one?

Functional Decomposition

System
Function Top Level functions

Produce Level 1 functions

Read Input Transform Output

Produce Level 2 functions

Read Input Transform Output

Load R10 Add R1, R10 Machine instructions

13
 9/16/24

Functional Decomposition: Autoshape

Autoshape

Change Draw

Change Change Change

Rectangle Oval Circle

Draw Draw Draw

Rectangle Oval Circle

Object-Oriented View

Autoshape

Draw()
Change()

14
 9/16/24

What is This?

Cave

Ellbow Neck
Glove
Pocket
Coat
An Eskimo!

Hair

Eye
Nose
Ear
Mouth
Chin

A Face!

15
 9/16/24

Cave Hair

Neck Eye
Ellbow Nose
Glove Ear
Pocket Mouth
Coat Chin

Depending on the purpose of the system different objects might be found: A

nose is suddenly an elbow, hair is a cave, an ear turns out to be a glove.

Modularity

Highly cohesive structure

• Loosely coupled
• Interactions through clearly defined

Interfaces
• Separation of concerns
– Improved modifiability/maintainability

16
 9/16/24

Hierarchies

We got abstractions and decomposition

• This leads us to chunks (classes, objects) which we view
with object model
• This should be modular

• Another way to deal with complexity is to provide simple

relationships between the chunks

• One of the most important relationships is hierarchy

Two important hierarchies

– "Part of" hierarchy
– "Is-kind-of" hierarchy

34

17
 9/16/24

Part-Of Kind-Of

35

Principles of S/W Development

Core Principles [David Hooker 1996]

– Ensure Usability
• Produce to be consume
– Communication
– Simplicity
– Open to change
– Employ Reuse
– Feedback
– Think

36

18
 9/16/24

Principles of S/W Development

Analysis Modeling Principles

– Information domain of a problem must be understood and

represented

– Define functional and non functional requirements clearly

– Define a complete and consistent set of requirements

– Analysis should help development

37

What constitutes a good model?

• A model should
– use a standard notation
– be understandable by clients and users
– lead software engineers to have insights about the system
– provide abstraction

• Models are used:

– to help create designs
– to permit analysis and review of those designs.
– as the core documentation describing the system.

19
 9/16/24

OO Concepts

Polymorphism

20
 9/16/24

Super class vs. Sub class

io n??
lizat
Ge nera
t is
Wha

Specialization: The act of defining one class as a refinement of another.

Subclass: A class defined in terms of a specialization of a superclass using

inheritance.

Superclass: A class serving as a base for inheritance in a class hierarchy

Inheritance: Automatic duplication of superclass attribute and behavior

definitions in subclass.

Interface

le

Other concepts will ….

21
 9/16/24

Class Modeling

43

Objects

The most fundamental entity in an OO Program

“An Object is a concept, abstraction or thing with identity that has

meaning for an application”
• Defined by class data type

Consists of
• Identifier
• Values
• Behavior

44

22
 9/16/24

Software Object: Cycle

45

Classes

• A class is a pattern, a blue print, or a template for a category of

structurally identical entities
• Created entities are called objects or instances
– Class is like instance factory
– Static entity
• A class has three components
– Name
– Attributes (also termed as variables, fields, or properties)
– Methods (also termed as operations, features, behavior,
functions)

46

23
 9/16/24

Classes
Objects

47

Class

Classes are represented by rectangles, with the name of the

class, and can also show the attributes and operations of the
class in two other “compartments” inside the rectangle.

48

24
 9/16/24

Class Diagrams

A Class defines the attributes and the methods of a set of objects.

All objects of this class (instances of this class) share the same
behaviour, and have the same set of attributes (each object has its
own set).

Class diagrams provide a graphic notation for modeling classes and

their relationships thereby describing possible objects.

2013: J Paul Gibson

Class Diagrams

25
 9/16/24

Class Diagrams

Attributes
In UML, Attributes are shown with at
least their name, and can also show
their type, initial value and other
properties. Attributes can also be
displayed with their visibility:
+ public attributes

# protected attributes

- private attributes

2013: J Paul Gibson

Class Diagrams

Operations

Operations (methods) are also

displayed with at least their name,
and can also show their parameters
and return types. Operations can,
just as Attributes, display their
visibility:

+ public operations

# protected operations

- private operations

2013: J Paul Gibson

26
 9/16/24

Class and Objects

53

Class and Objects: Notations

Do not list object identifier; they are implicit in models

54

27
 9/16/24

Object Relationships

• Association
• Aggregation Part can exist without whole
• Composition Part can NOT exist without whole

• Inheritance
• Dependency

55

UML History

28
 9/16/24

Unified Modeling Language

UML is for Visual Modeling

29
 9/16/24

Three (3) basic BUILDING blocks of UML

Relationships between objects at some point

30
 9/16/24

Object Diagrams

More formally in UML

31
 9/16/24

Unified Modeling Language (UML) - Diagrams

Source: Wikipedia

UML Core Conventions

• All UML Diagrams denote graphs of nodes and edges

• Nodes are entities and drawn as rectangles or ovals

• Rectangles denote classes or instances
• Ovals denote functions

• Names of Classes are not underlined

• SimpleWatch
• Firefighter

• Names of Instances are underlined

• myWatch:SimpleWatch
• Joe:Firefighter

• An edge between two nodes denotes a relationship between the

corresponding entities

64

32
 9/16/24

UML first pass: Use case diagrams

Classifier
Use Case

Actor.

System boundary

Use case diagrams represent the functionality of the system

from user’s point of view

Historical Remark: UML 1 used packages

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

33
 9/16/24

UML first pass: Class diagrams

Association
Class

Multiplicity
SimpleWatch
1 1 1 1
2 1 2 1
PushButton Display Battery Time

Class diagrams represent the structure of the system

UML first pass: Class diagrams

Association
Class

Multiplicity Watch
1 1 1 1
2
1 2 1
PushButton
state LCDDisplay Battery Time
push() blinkIdx Load Now
release() blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
referesh() Operations
Attribute

34
 9/16/24

UML first pass: Sequence diagram

Actor Message Object Lifeline

:WatchUser :Watch :LCDDisplay :Time

pressButton1() blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButton1and2()
commitNewTime()

stopBlinking()
Activation

Sequence diagrams represent the behavior of a system

as messages (“interactions”) between different objects

UML first pass: Statechart diagrams

Event Initial state

button1&2Pressed button2Pressed
Blink Increment
Hours Hours

Transition button1Pressed

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
State

button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds

Final state

Represent behavior of a single object with interesting dynamic behavior.

35
 9/16/24

UML Basic Notation Summary

• UML provides a wide variety of notations for modeling many

aspects of software systems

• Today we concentrated on a few notations:

– Functional model: Use case diagram
– Object model: Class diagram
– Dynamic model: Sequence diagrams, state chart

Diagrams in UML

36
 9/16/24

Diagrams in UML – Actors in Use case

Diagrams in UML – Use cases in Use case diagram

37
 9/16/24

Diagrams in UML – Use case Diagram

Next Lecture:We Discuss

• Use Case Diagram

• Sequence Diagram
• Collaboration Diagram
• Statechart
• Activity Diagram
• Class Diagram
• Package Diagram
• Component/Deployment Diagram

38