Design Quality SGI PS Day 1

Design Quality
Restricted © Siemens AG 2021 Siemens Technology

Design Quality - Training
• During the proposed engagement for Design coaching, the emphasis will be on improvement and maturity of design
practices within the team.
• Mentors – Elroy, Girish, (Support: Himanshu/Shrinath)
Topics (9:00 to 12:00)
Day 1 Technical Debt, Design quality, Design principles
Day 2 Design smells and Refactoring

Day 3 Refactoring (contd.)
Day 4 API Design
Day 5 Design for Testability
Restricted © Siemens AG 2021
Page 2 T RDA SSI RSE-IN
Capers Jones on design errors in industrial software
Industry Data on Defect Origins

120
100
Percentage Contribution
80
Adminstrative Errors
Documentation Errors
60
Bad Fixes
Coding Errors
40 Design Errors
Requirements Errors
20
0
IBM SPR TRW MITRE Nippon Electric
Corportation Corporation Corporation Corporation Corp
(MVS) (Client Studies)
* http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf Up to 64% of software

defects can be traced back to
Restricted © Siemens AG 2021 errors in software design in
enterprise software!
Why care about design quality?
Software Technical
Quality Debt
Poor software quality The debt that accrues when

costs more than $150 you knowingly or
billion per year in U.S. and
Design unknowingly make wrong or
greater than $500 billion Quality non-optimal design decisions
per year worldwide
Design Quality means

changeability, extensibility,
understandability, reusability,
Restricted © Siemens AG 2021 ...
Quality attributes impacted by poor design quality
Quality
Definition
Attribute
Understandability The ease with which the design fragment can be comprehended.
The ease with which a design fragment can be modified (without causing ripple
Changeability
effects) when an existing functionality is changed.
The ease with which a design fragment can be enhanced or extended (without
Extensibility
ripple effects) for supporting new functionality.
The ease with which a design fragment can be used in a problem context other
Reusability
than the one for which the design fragment was originally developed.
The ease with which a design fragment supports the detection of defects within
Testability
it via testing.
The extent to which the design fragment supports the correct realization of the
Reliability
functionality and helps guard against the introduction of runtime problems.
Page 5 Slide 5 T RDA SSI RSE-IN
Why care about technical debt?

Technical Bankruptcy!!

Organizing the Technical Debt landscape
Defects
Invisible to user Low External

Quality
Code Design New
Debt Debt Features
Architecture Test Additional

Debt Debt Functionality Software
User
Documentation
Software Debt
Developer
Technical Debt
What constitutes technical debt?
Documentatio
Code debt Design debt Test debt
n debt
No
Static analysis Lack of tests documentation
…
Design smells
tool violations for important
concerns
Inconsistent Violations of Inadequate Outdated

coding style design rules test coverage documentation

Typical evolution of codebase

What causes Technical Debt?
A MAJOR CAUSE IS VIOLATIONS OF

• PRINCIPLES
• BEST PRACTICES
• PROCESSES

Most common cause of technical debt

Most common cause of technical debt

Another common cause

Not adhering to processes

Unable to adapt

Over-engineering

One-time Violation --> Long-term Habit

Basic Principles

Design Principles
Design principles are universally applicable concrete design rules to guide a

developer, designer, or architect during design conceptualization or
maintenance phases.
High-level design principles, e.g.
Separation of Concerns
Anticipation of Change
4 pillars of Object Orientation (next slide)
Concrete design principles (SOLID, DRY, CPP, etc.)

The principle of abstraction
• Simplify entities via

Abstraction • Reduction of unnecessary details
• Generalization of common and important aspects

The principle of encapsulation
• Separation of concerns and information hiding via

Encapsulation • Hiding implementation details
• Hiding variations

The principle of Modularization
• Cohesive and loosely-coupled abstractions via

Modularization • Localization
• Decomposition
The principle of Hierarchy
• Hierarchical organization of abstractions via

Hierarchy • Generalization and factoring
• Classification and ordering
Basic Principles
• Simplify entities via

Abstraction • Reduction of unnecessary details
• Generalization of common and important aspects
• Separation of concerns and information hiding via

Encapsulation • Hiding implementation details
• Hiding variations
• Cohesive and loosely-coupled abstractions via

Modularization • Localization
• Decomposition
• Hierarchical organization of abstractions via

Hierarchy • Classification and ordering
• Generalization and factoring

SOLID
Single Responsibility Principle

Open-closed Principle
Liskov’s Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Example - 1
interface Modem {
public void dial(String pno);
public void hangup();
public void send(char c);
public char recv();
}
Seems like good set of modem functions – but is it one or two sets of
responsibilities?
• Connection management (dial and hangup)
• Data communication (send and recv)
Separate if connection functions are changing
Don’t separate if no changes expected
There should never be more than one reason for a class to change
Every class should have a single purpose
Concentrate on a single aspect in an abstraction
A responsibility is a “reason for change”


Example - 2
Let’s say we have to build an application that calculates the sum of area of
rectangles

Example
Let’s say, now, the customer wants us to extend this to include area of circles as well

Example
Let’s say, now, the customer asks “Can you extend this to calculate area of triangles?”
Though this may not be very hard, but we will need to modify our code again.
In real-world projects, requirements change frequently and modifying the class and
redeploying the binaries every time the requirements change is effort intensive and not
cost effective.

Open-Closed Principle
Software entities should be open for extension and closed for modification
Open for extension – extend with new behaviors
Closed for modification – extending behavior does not result in changes to source
code or binary code of module. .exe, DLL, .jar remain untouched!
Define interface, extend implementation

Applying OCP
Shape
double area()
Rectangle Circle Triangle

double width, height double radius double base, height
double area() double area() double area()
We have moved the responsibility of computing the area away from

AreaCalculator to the shapes that actually know how to compute the area

Open-Closed Principle

Clients that use references (or pointers) to base abstractions must be able to use their
derived abstractions without knowing it
A is base class. B is derived type.
B bType = new B();
A aType = bType;
aType.print();
A subclass must be replaceable where its super class is referenced
Everything that is true of the base type should be true of the subtype
Applying LSP
Vehicle
void startEngine()
void accelerate()
Car Electric Bus

void startEngine() void accelerate()
void engageIgnition() void increaseVoltage()

Is a Square a Rectangle?
Rectangle
Square
Issues:
•Square doesn’t need both itsWidth and itsHeight
•Having both SetWidth and SetHeight inappropriate
LSP Violation - example
void area(Rectangle rectangle)

{
rectangle.SetWidth(5);
rectangle.SetHeight(4);
assert(rectangle.Area() == 20);
}
The author of area() assumed that changing the height of a rectangle would not change its width – a
reasonable assumption for a rectangle!
Function area() shows that there are functions that take references to Rectangle objects that do not
operate properly on Square objects. So Square is NOT a valid substitute for a Rectangle. Making it a child
violates the LSP principle!
An inheritance hierarchy cannot be evaluated abstractly. In the abstract sense, a square is a
rectangle. But when we look at the behavior (as expressed in code), we see the issue.
Let’s fix the LSP violation
void area(Rectangle rectangle)

{
rectangle.SetWidth(5);
rectangle.SetHeight(4);
if (rectangle isInstanceOf Rectangle)
else if (rectangle isInstanceOf Square)
}
But, what is the problem here?

OCP is violated. What if you have to support a new shape tomorrow?


Example
A development team’s task is to create a basic

email object
Client Team A, responsible for creating an

application that sends an email reminder as a
part of their process, creates a client that
consumes the server and everything works
Restricted © Siemens AG 2021 From: http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html

Example
Development team now receives a

request from Client Team B which
wants to support sending a text
message
Since it is almost the same as sending

an email message, they decide to use
polymorphism
Both Clients are happy!

But already LSP is violated

Team now receives a request from Client Team A that they want to enhance
the system to support the email to be sent to a list of addresses as a blind
copy

Example
Client Team A gets the new server and things are great
But Client Team B is now broken and must recompile and go through a round of regression testing
because a feature was added for another team
Interfaces may contain groups of methods, where each group serves a different set of
clients. Best to separate them.

Clients should not be forced to depend upon interfaces that they do not need
When a client A depends on a class that contains methods that it does not use, but
which other clients use, client A will be affected by changes those other clients
force upon the class
Don’t pollute interfaces
Avoid fat interfaces
Interfaces here do not mean Java Interfaces. They mean the public methods that are
exposed by a class

ISP in Action
Now Client Team B has a specific interface

IMessage that it can use
Similarly, Client Team A has a specific interface
IEmailMessage that it can use
ISP allows IEmailMessage to be changed without
Restricted © Siemens AG 2021 impacting Client Team B

Example
Button object has Poll method to determine whether or not user has “pressed” it.
The Button could be represented as an icon on GUI, home security system, physical
button, etc. The Poll method helps detect if the button is activated or deactivated.
public class Button {

Button Lamp private Lamp itsLamp;
+ Poll() + TurnOn() public boolean poll() {
+ TurnOff() return (itsLamp.turnOn());
Naïve Model
}
Button can’t be reused (for e.g. for a fan) …
Changes to Lamp might affect Button. }

Abstractions should not depend upon implementation details. Details should be dependent upon
abstractions.
High-level abstractions should not depend on low-level abstractions.
Clients should depend on interfaces not implementation (loose coupling)

Applying the DIP
<<interface>>
Button
SwitchableDevice
+ Poll()
+ turnOn()
+ turnOff()
Lamp
Now Button can control any device that implements SwitchableDevice

Notice that SwitchableDevice does NOT depend on Button


Some Other Commonly Used Principles
Don’t Repeat Yourself Principle (DRY) - “Every piece of knowledge must have a single,
unambiguous, authoritative representation within a system” [HT99].
Keep it simple Silly (KISS) – Avoid unnecessary complexity. Keep things simple since it helps
improve understandability and helps detect deficiencies easily.
Composition Preference Principle (CPP) - Shorter name for the principle “favor object
composition over class inheritance” [EGV94].
Variation Encapsulation Principle (VEP) – Information hiding wherein the concept that is
varying is encapsulated within a class or a hierarchy.
Acyclic Dependencies Principle – Dependencies between packages or classes must not form
cycles.
Thank you!
A
Q

Dr. Girish Suryanarayana
Senior Key Expert
CT RDA SSI SDT-IN
girish.suryanarayana@siemens.com
Thank you!

How to improve design quality in practice?

Refactoring process model

Tools
Comprehension tools
Imagix 4D, Structure 101
Critique, code-clone detectors, and metric tools
Infusion, Designite, Ndepend
Simian, CPD
Understand, Source-monitor, Designite
Technical debt quantification and visualization tools
Sonar Qube
Refactoring tools
Refactoring inferencing tools – SCOUT, Jdeoderant
Refactoring performing tools – Eclipse, Resharper

Suggested Reading


Design Quality SGI PS Day 1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Quality SGI PS Day 1

Uploaded by

Copyright:

Available Formats

Design Quality

Restricted © Siemens AG 2021 Siemens Technology

Topics (9:00 to 12:00)

Day 1 Technical Debt, Design quality, Design principles

Day 2 Design smells and Refactoring

Industry Data on Defect Origins

* http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf Up to 64% of software

Poor software quality The debt that accrues when

Design Quality means

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Invisible to user Low External

Architecture Test Additional

Inconsistent Violations of Inadequate Outdated

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

A MAJOR CAUSE IS VIOLATIONS OF

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Design principles are universally applicable concrete design rules to guide a

High-level design principles, e.g.

4 pillars of Object Orientation (next slide)

Concrete design principles (SOLID, DRY, CPP, etc.)

Restricted © Siemens AG 2021

• Simplify entities via

Restricted © Siemens AG 2021

• Separation of concerns and information hiding via

Restricted © Siemens AG 2021

• Cohesive and loosely-coupled abstractions via

• Hierarchical organization of abstractions via

• Simplify entities via

• Separation of concerns and information hiding via

• Cohesive and loosely-coupled abstractions via

• Hierarchical organization of abstractions via

Restricted © Siemens AG 2021

Single Responsibility Principle

Restricted © Siemens AG 2021

Every class should have a single purpose

Concentrate on a single aspect in an abstraction

A responsibility is a “reason for change”

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Define interface, extend implementation

Restricted © Siemens AG 2021

Rectangle Circle Triangle

double area() double area() double area()

We have moved the responsibility of computing the area away from

Restricted © Siemens AG 2021

Restricted © Siemens AG 2021

Car Electric Bus

Restricted © Siemens AG 2021

void area(Rectangle rectangle)

void area(Rectangle rectangle)