Software engineering principles (marcello thiry)

marcello.thiry@gmail.comSoftware Engineering Principles

marcello.thiry@gmail.com http://ideas.scup.com/pt/files/2013/06/conte%C3%BAdo.jpg
1. Principles, Methods, Techniques, Methodologies and Tools
2. Rigor and Formality
3. Separation of concerns
4. Modularity
5. Abstraction
6. Anticipation of change
7. Generality
8. Incrementality
Contents.

marcello.thiry@gmail.com
http://www.ppp.uiuc.edu/newppp_2001/reso
urses/plant/graphics/slidejpgs/tap_root.jpg
A basic truth, law
or assumption
basis for prediction
and action behavior
(Ghezzi, Jazayeri & Mandrioli, 2003)

Principles form the basis of
methods and techniques
A systematic way of doing
something
https://upload.wikimedia.org/wikipedia/c
ommons/thumb/8/8f/PSM_V10_D029_A
ncient_fire_making_methods.jpg/800px-
PSM_V10_D029_Ancient_fire_making_
methods.jpg

methods and techniques*
* For the purpose of this course
these terms will be used
interchangeably
How to plan...
How to test...
How to design...
How to code...
How to elicit requirements
How to estimate...
...
Observation, interviews, workshops, surveys...

A body of practices, procedures, and rules
System of methods and principles used
in a particular discipline

Support the application of methods,
techniques, and methodologies

CASE Tools
Computer-Aided Software Engineering
Used in different phases of software development

List of Unified Modeling Language tools
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
List of diagramming tools
http://www.diagramming.org/
Data Modeling Tools
http://toolsfordatabases.com/data-modeling-tools.html
Comparison of data modeling tools
https://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools
Test management tools
https://en.wikipedia.org/wiki/Test_management_tools
List of GUI testing tools
https://en.wikipedia.org/wiki/List_of_GUI_testing_tools
List of web testing tools
https://en.wikipedia.org/wiki/List_of_web_testing_tools
Comparison of project management software
https://en.wikipedia.org/wiki/Comparison_of_project_management_software
List of build automation software
Configuration, Build, Integration, ...
https://en.wikipedia.org/wiki/List_of_build_automation_software
Application lifecycle management (ALM)
https://en.wikipedia.org/wiki/Application_lifecycle_management
Try on...
…

Rigor and formality
Separation of concerns
Modularity
Abstraction
Anticipation of change
Generality
Incrementality
Key Principles

Software development
is a creative design
activity, don't you
agree?
But…

You know the
guy who painted
this, right?
http://totallyhistory.com/wp-content/uploads/2012/03/Mona_Lisa_by_Leonardo_da_Vinci.jpg

Leonardo da Vinci
(1452-1519)
“…Leonardo da Vinci employed a
variety of techniques ...”
“One of his most well-known paintings,
the Mona Lisa, displays some of the
techniques used by da Vinci in its
grandeur.”
http://www.davincilife.com

Software engineering must be practiced
systematically
Rigor is a necessary complement to
creativity which increases confidence
in the results of the development
Precision, exactness

Rigor
enables repeatability and allows teams
to avoid problems experienced in past
projects
What level of discipline set of rules we
need to…
… produce products with higher reliability, greater
quality while controlling costs and meeting
expectations?

So, rigor varies in degree!
We need to use the appropriate amount
http://mcx.sourceforge.net/upload/matlab_mmclab.pnghttp://www.mathworks.com/products/matlab/
http://4.bp.blogspot.com/-
IyHsfT1sB1A/UhTQdRV8opI/AAAAAAAABiI/H2R3X1OmAUg/s1600/V
NLIVES.NE-Simple-calculator-01.png

Formality is rigor at the highest
degree
Allows automation tools
A formal practice is where software systems
can be verified by mathematical laws
Formal methods petri nets, z, …
The source code is written in a formal
language

“Divide and conquer"
(divide et impera)
Identifying different
aspects of a problem we
can concentrate on each
one individually

https://en.wikipedia.org/wiki/
Edsger_W._Dijkstra
“The term separation of concerns
was probably coined by Dijkstra in
his 1974 paper On the role of
scientific thought”
Edsger Wybe Dijkstra
(1930-2002)
A pioneer in the fields of computer
science and computational physics.
Among many contributions, he coined
the phrase "structured programming"
and discovered the algorithm for the
shortest path in a graph, which now
bears his name.
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
Paper "On the role of scientific thought" transcribed by Richard Walker:
https://en.wikipedia.org/wiki/Separation_of_concerns

The only way to master the complexity of
a project is to separate the different
concerns
Time
Qualities
Views
Parts
Skills
http://www.crochetville.com/community/uploads/monthly_06_2013/post-48806-0-42116700-1370920781.jpg

Time
Qualities
Views
Parts
Phases, iterations, activities…,
Structural x Behavioral, Layer separation ex: MVC
Functional, Efficiency, Usability, reliability, …
modularity
Responsibilities and Skills
Project manager, Systems Analyst, Software Designer, …

A complex system can be partitioned in
smaller and simpler units or parts
MODULES
http://www.brickshop.co.uk/bricks-16-c.asp http://www.lego.com/ http://constructionweekonline.com//pictures/LEGO_Sungnyemun.jpg

HIGHER
Level of abstraction
LOWER
System Sub-system Modules

Modular system
Deal with a module at a time,
ignoring details from the others
Modularity
Application of separation of concerns
Composed by modules

But be careful…
(Pressman, 2015)

Decomposability
System level
Topmost functional
abstraction

Decomposability
System level
Subsystem
level
Topmost functional
abstraction

Decomposability
Top-down
hierarchy
+ abstract
- abstract
System level
Subsystem
level
Module
level
Topmost functional
abstraction

Niklaus_Wirth
In 1971, Niklaus Wirth, wrote the
influential paper Program Development
by Stepwise Refinement. Today, we refer
to this approach as top-down design (or
top-down decomposition).
Niklaus Emil Wirth
(1934-)
A Swiss computer scientist, best known for
designing several programming languages (Algol
W, Pascal, Modula, Modula-2, Oberon, Oberon-
2, Oberon-7) and for pioneering several classic
topics in software engineering. In 1984 he won
the Turing Award for developing a sequence of
innovative computer languages. He designed
the simple programming language PL/0 to
illustrate compiler design. It has formed the
basis for many university compiler design
classes.
http://oberoncore.ru/_media/library/wirth_program_development_by_stepwise_refinement2.pdf
“Program Development by Stepwise Refinement” (1971)

TOP-DOWN Considerations
+ -
Logical, well-organized
thought discipline
Allows to split large teams
into groups and assign them
to different subsystems
Works very well for small
projects
Focus on functional
requirements
Thinking of a system as
just one function top
Premature decisions, less
prepared for changes
Reuse is more difficult
Defers coding and testing
Increases chance of having
unwanted dependencies

Composability
lower functional
abstraction
Module
level

Composability
lower functional
abstraction
Subsystem
level
Module
level

Composability
Bottom-up
hierarchy
+ abstract
- abstract
System level
Subsystem
level
Module
level

BOTTOM-UP Considerations
+ -
Allows earlier coding and
testing
Potentializes reuse, simpler
to incorporate and test pre-
existing modules
Better prepared for changes
Without some forethought,
modules can be difficult to
link together
Focus is not on specific
requirements results may
not fulfill a given need
Hard to do a entire system
from bottom-up
Better suited to small
groups

TOP-DOWN
or
BOTTOM-UP?
http://ruccs.rutgers.edu/faculty/pylyshyn/cogscitalk/fish2.gif

In practice, large systems design is never truly top-down
TOP-DOWN X BOTTOM-UP
Some branches are designed before others
Designers reuse experience and modules
Both allow us to understand the relations
between high and low-level views of a system
(Sommerville, 1995)
Hybrid design
Combine both to potentialize understanding, information hiding
and reuse

Module ACME
Data
+
Structures
+
Procedures
+
Functions
Operation_1 …
Operation_2 …
Operation_3 …
Operation_4 …
Operation_5 …
Operation_N …

David_Parnas
The concept of information hiding was
first described by Parnas in his paper On
the Criteria to be Used in Decomposing
Software into Modules (1972)
David Lorge Parnas
(1941-)
Canadian early pioneer of software engineering,
who was one of the first to recognize the
importance of software structure. He developed
the concept of information hiding in modular
programming, which is an important element
of object-oriented programming today. He is
also noted for his advocacy of precise
documentation.
https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
“On the Criteria to be Used in Decomposing Software into Modules” (1972)

Account
getNumber : int
deposit float
withdraw float
getBalance : float
Encapsulation + Information hiding
IMPLEMENTATIONINTERFACE
http://thumbs.dreamstime.com/t/manikin-keep-distance-
orange-cartoon-character-red-text-30647683.jpg
Client modules depend only on the interface
Continuity: small changes have localized effects
Increases reusability and substitutability
Protection: fault isolation
(Meyer, 1988-1997)

Account
getNumber : int
deposit float
withdraw float
getBalance : float
All the elements of a module
must belong together
Cohesion: internal measure
GOAL: HIGH COHESION
All the elements share the same
purpose
Understandability of a module
in isolation

The single responsibility principle
Martin*, 1995
*Robert Martin is commonly known as Uncle Bob
http://wordlesstech.com/wp-content/uploads/2010/12/swiss-army-knife-giant-elite1.jpg
https://lostechies.com/gabrielschenker/2009/01/21/real-
swiss-don-t-need-srp-do-they/
By Gabriel Schenker

Reason to change
SINGLE PART of all functionality
Encapsulation cohesion
Anticipate how the class could evolve
A class should have only one
reason to change
RESPONSIBILITY

Responsibility 1
Human Resources
Responsibility 2
Payroll Department
Responsibility 3
DBA team

But be careful...

Every module communicates with as few
other modules as possible
Coupling: external measure
modules interdependency
GOAL: LOW COUPLING
Reducing coupling
+ Understanding
Meyer, 1988-1997
+ Testability
+ Modifiability
+ Reusability

The open-closed principle
Meyer, 1988-1997
OPEN = available for extension
CLOSED = available for use by
other modules
Modules should be both open and
closed

Add new behaviors to satisfy the
changes
Open for extension
But without changing the source code
of the existing modules
Closed for modification

The cool part…
Modules that depend on the
extended modules are not
affected by the extension

But how?
Abstractions
Inheritance
Interfaces
Overriding
Polymorphism

https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle
https://sklivvz.com/posts/say-no-to-the-openclosed-pattern
http://blogs.msmvps.com/jonskeet/2013/03/15/the-open-closed-principle-in-review/
http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html
http://codecourse.sourceforge.net/materials/The-Importance-of-Being-Closed.pdf
Interesting reading…

HIGH COUPLING
Non-hierarchical
organization
Hierarchical
organization
LOW COUPLING
dependency
uses, call

HIGH COUPLING
Non-hierarchical
organization
Hierarchical
organization
LOW COUPLING
dependency
uses, call And about cohesion?

HIGH COUPLING
Non-hierarchical
organization
Hierarchical
organization
LOW COUPLING
dependency
uses, call Got it?

dependency
uses, call
So…

Dependency inversion principle
Depend upon abstractions rather
than upon concretions
Martin*, 1995

Module as a package...
Provides unique namespace
Encapsulates classes, interfaces and
resources
Access rules: package visibility

Module as a library...
Contains one or more packages
Piece of code with no internal state and
a public API
In Java, the boundaries of a JAR are not
clear once deployed on the class path

Module as a class...
Can be instantiated multiple times
Can implement different interfaces
Classes and single responsibility
Granularity?

http://www.promo-wholesale.com/Upfiles/Prod_q/Solar-
Powered-Desk-Calculator_20090641609.jpg
identify the
essential aspects
of a particular context, ignoring
less important or accidental
characteristics
To abstract
is to…

But be careful…
You must ignore only
those details which
can be really ignored
What to
do here???
http://www.convio.com/common-ground/assets/crazy_sm.jpg

Abstraction
Special case of separation of concerns
Technique to master complexity
Important aspects x Less important details
What we abstract away and consider as a detail that
may be ignored depends on the observer and on the
problem been observed
Modeling, diagramming, prototyping, defining
equations, …

https://design2014level2.files.wordpress.com
/2014/04/ceiling-fan-70914.gif
Smart Home
System
Online Shopping
System
What is the
problem?

How to estimate?
Which aspects or factors should we consider?
Complexity
Quantity
Team experience
Technology used
Product type
...
Which of them
are essential?

Software
changes all
the time
New features Improvements
in existing
features
Correction
of defects
Performance
improvements
Adaptation due to changes
in law, regulations,
environment ex: DBMS, OS

Software
Maintenance
Software
Evolution
Corrective
ADAPTATIVE
PERFECTIVE
Preventive

How to anticipate
potential future changes?
CAREFUL! That is not about try to
implement what users will MAYBE need
in the future
That is about to be
prepared to change!

How to improve
Maintainability?
Degree of effectiveness and
efficiency with which the
software can be modified
(ISO/IEC 25010, 2011)

How to support maintainability?
Configuration Management tools
Version control
Change management
Integration
Repositories
Reusable components
Documentation

Integration
tools
http://buildbot.net
http://jenkins-ci.org/
http://git-scm.com/
Version control
tools
https://travis-ci.org/
http://subversion.tigris.org/
https://github.com/
Change
Management
tools
https://www.mantisbt.org/
http://www.accurev.com/
…… …
http://www.redmine.org/

If you think you have already
discovered a solution, think again!
But with a more
open mind!
While solving a problem...

Try to discover if it is an instance of a
MORE GENERAL PROBLEM
While solving a problem...
Sometimes a general problem is easier to solve
than a special case
Maybe, the solution can be reused in
other cases
You need to balance generality
against performance and cost
But...

Liskov substitution principle
Liskov, 1987
*Keynote address: data abstraction and hierarchy, OOPSLA '87
http://dl.acm.org/citation.cfm?id=62141
If an object X of type T has a method P
that behaves in a defined way
The object Y of type S, where S is a
subtype of T, should have the same method
P behaving the same way

Liskov substitution principle
Liskov, 1987
*Keynote address: data abstraction and hierarchy, OOPSLA '87
http://dl.acm.org/citation.cfm?id=62141
You should depend on the interfaces
rather than class types
It is all about semantics!

Grow, Don't Build
http://cdn.shopify.com/s/files/1/0070/7032/files/The_10_Strategy.jpg?754

Deliver subsets of a system early to get early feedback from expected
users, then add new features incrementally
Deliver a first prototype and then incrementally add effort to turn
prototype into product
Process proceeds in a stepwise fashion increments
user
FeedbackDelivery
user
Feedback
user
Delivery Delivery
Examples process
Development
user
Inc #1 Inc #2 Inc #N
Development Development

References.
 (Ghezzi, Jazayeri & Mandrioli, 2003). Fundamentals of Software Engineering. 2nd ed. Pearson Education.
 (ISO/IEC 25010, 2011). Systems and software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE) — System and software quality models.
 (Martin, 1995). https://groups.google.com/forum/?hl=en#!topic/comp.object/WICPDcXAMG8.
 (Meyer, 1997). Object-Oriented Software Construction. 2nd ed. Prentice Hall.
 (Sommerville, 2015). Software Engineering. 10th ed. Pearson.

Software engineering principles (marcello thiry)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Software engineering principles (marcello thiry)

Similaire à Software engineering principles (marcello thiry) (20)

Plus de Marcello Thiry

Plus de Marcello Thiry (12)

Dernier

Dernier (20)

Software engineering principles (marcello thiry)