Software engineering principles (marcello thiry)
90
[email protected] Software Engineering Principles
-
Upload
marcello-thiry -
Category
Education
-
view
909 -
download
12
Transcript of Software engineering principles (marcello thiry)
[email protected] Engineering Principles
[email protected] 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.
Principle?
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
(Ghezzi, Jazayeri & Mandrioli, 2003)
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
(Ghezzi, Jazayeri & Mandrioli, 2003)
Support the application of methods,
techniques, and methodologies
(Ghezzi, Jazayeri & Mandrioli, 2003)
CASE Tools
Computer-Aided Software Engineering
Used in different phases of software development
List of Unified Modeling Language toolshttps://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
List of diagramming toolshttp://www.diagramming.org/
Data Modeling Toolshttp://toolsfordatabases.com/data-modeling-tools.html
Comparison of data modeling toolshttps://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools
Test management toolshttps://en.wikipedia.org/wiki/Test_management_tools
List of GUI testing toolshttps://en.wikipedia.org/wiki/List_of_GUI_testing_tools
List of web testing toolshttps://en.wikipedia.org/wiki/List_of_web_testing_tools
Comparison of project management softwarehttps://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...
…
Returning to the
Principles
Rigor and formality
Separation of concerns
Modularity
Abstraction
Anticipation of change
Generality
Incrementality
Key Principles
(Ghezzi, Jazayeri & Mandrioli, 2003)
Rigor and
Formality
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
Separation
of Concerns
“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 computerscience and computational physics.Among many contributions, he coinedthe phrase "structured programming"and discovered the algorithm for theshortest path in a graph, which nowbears 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, …
Modularity
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
Modular system
Deal with a module at a time,
ignoring details from the others
Modularity
Application of separation of concerns
Composed by modules
Decomposability
Top-down
hierarchy
+ abstract
- abstract
System level
Subsystem
level
Module
level
Topmost functional
abstraction
https://en.wikipedia.org/wiki/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 fordesigning several programming languages (AlgolW, Pascal, Modula, Modula-2, Oberon, Oberon-2, Oberon-7) and for pioneering several classictopics in software engineering. In 1984 he wonthe Turing Award for developing a sequence ofinnovative computer languages. He designedthe simple programming language PL/0 toillustrate compiler design. It has formed thebasis for many university compiler designclasses.
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
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 …
https://en.wikipedia.org/wiki/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 theimportance of software structure. He developedthe concept of information hiding in modularprogramming, which is an important elementof object-oriented programming today. He isalso noted for his advocacy of precisedocumentation.
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
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
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 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?
Abstraction
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?
Anticipation
of Change
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/
Generality
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!
Incrementality
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.
