SOEN6461: Software Design Methodologies Yann-Gal Guhneuc A brief - - PowerPoint PPT Presentation
SOEN6461: Software Design Methodologies Yann-Gal Guhneuc A brief introduction to software engineering This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License Outline Definition
Yann-Gaël Guéhéneuc
This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License
A brief introduction to software engineering
2/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
3/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
4/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
5/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
6/110
Design, development, operation, and
maintenance of software
All activities to deliver and maintain a
software systems
– Include requirements engineering
7/110
SE is all about problem solving
8/110
SE is all about problem solving
9/110
SE is all about problem solving
Problem: Solution:
10/110
SE is also all about information hiding and
abstraction
“It’ one of those scientific simplifications: we’ll ignore the whole rest of the problem and just examine this particular aspect of it.” —Larry Wall (creator of Perl, in Masterminds of Programming) – Risk reduction vs. risk sharing/transfer
11/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
12/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
13/110
“Thoroughness and regularity” —Merriam-Webster
14/110
“Thoroughness and regularity” —Merriam-Webster
Problem: how to perform development systematically? Solution: use a well-defined, repeatable process
15/110
Reuse known architectures, designs, and
implementation
– E.g., pipeline architecture, design patterns, sort algorithms
Know the “tools of the trade”, learn new tools
16/110
Tools of the trade
– Hardware systems – Operating systems – Virtual machines – Programming languages – Algorithms and data structures – Libraries – Design patterns – Architecture types
17/110
Tools of the trade
– Hardware systems – Operating systems – Virtual machines – Programming languages – Algorithms and data structures – Libraries – Design patterns – Architecture types
18/110
Processes
– Waterfall – Spiral – Iterative and incremental – Agile – RAD – Code and fix
19/110
Processes
– Waterfall – Spiral – Iterative and incremental – Agile – RAD – Code and fix
20/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
21/110
Agile development
– Make it work
– Make it right
– Make it fast
22/110
23/110
24/110
“I am 90% done!”
—All developers (when they are late)
25/110
“I am 90% done!”
—All developers (when they are late)
Problem: how to measure success? Solution: use explicit, repeatable criteria
26/110
Agile development
– Test Driven Development (TDD)
27/110
Agile development
– Test Driven Development (TDD)
28/110
Agile development
– Test Driven Development (TDD)
29/110
Agile development
– Test Driven Development (TDD)
30/110
Agile development
– Test Driven Development (TDD)
31/110
Agile development
– Test Driven Development (TDD)
32/110
Agile development
– Test Driven Development (TDD)
33/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
34/110
Testing
– Existing data shows that more, not less, testing is needed for OO systems
account during testing
– Unit and integration testing are especially affected as they are more driven by the structure of the system under test
35/110
Testing
– Procedural programming
– Not withstanding the problem of global variables (if any)
36/110
Testing
– Object oriented programming
– Data members (state) + sets of methods
it also includes the object state
– The state is not directly accessible
37/110
class Watcher { private: ... int status; ... public: void check_pressure() { ... if (status == 1) ... else if (status ...) ... ... } ... }
38/110
Testing method check_pressure() in
isolation is meaningless
– The value produced by method check_pressure() depends on the state of class Watcher instances (variable status) – Failures due to incorrect values of variable status can be revealed only with tests that have control and visibility on that variable
39/110
Moreover, there could be a
– Wrong instance of method inherited in the presence of multiple inheritance – Wrong redefinition of an attribute / data member – Wrong instance of the method called due to dynamic binding and type errors
40/110
Testing
– Procedural programs – Object-oriented programs
Requires that
– We can build oracle and write tests to give us confidence in the built software systems
41/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
42/110
Oracle
– Classical Antiquity (e.g., Ancient Greece, above) – Shamanism (e.g., Korea, right)
43/110
Oracle
– Or more “recently” in
44/110
Oracles
– Determine the output that a software component should have for some given input (and possibly some state)
“When I call this method on that object, I expect this return value”
45/110
Oracles depend on the abstraction level of
the tests being written
Abstraction levels with procedural
programming languages
– Basic component: function (procedure) – Testing method: based on input/output relation
46/110
Creating oracles is more difficult in object-
programming
– The value produced by method check_pressure() depends on the state of class Watcher instances (variable status) – Failures due to incorrect values of variable status can be revealed only with tests that have control and visibility on that variable
47/110
New abstraction levels with object-oriented
programming languages
– Basic unit testing: testing of a single method
(Intra-method testing)
– Unit testing: testing of a class
(Intra-class testing)
– Integration testing: testing of the interactions among classes
(Inter-class testing)
48/110
public void testACAIC() { final IFirstClassEntity firstClassEntity = (IFirstClassEntity) modelForCouplingCohesion .getTopLevelEntityFromID("pom.test.rsc.G2"); Assert.assertEquals( "Computing ACAIC on G2", 7d, metrics.compute("ACAIC", firstClassEntity), 0); }
49/110
public void testACAIC() { final IFirstClassEntity firstClassEntity = (IFirstClassEntity) modelForCouplingCohesion .getTopLevelEntityFromID("pom.test.rsc.G2"); Assert.assertEquals( "Computing ACAIC on G2", 7d, metrics.compute("ACAIC", firstClassEntity), 0); }
50/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
51/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
52/110
“Divided in sub-disciplines” “Rigorous”
—WordReference.com
53/110
“Divided in sub-disciplines” “Rigorous”
—WordReference.com
Problem: how to develop quality products? Solution: use appropriate, explicit, repeatable rules
54/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
55/110
Divided in sub-disciplines
– Software requirements – Software design – Software construction – Software testing – Software maintenance – Software configuration management – Software engineering management – Software engineering process – Software quality assurance
56/110
Divided in sub-disciplines
– Software requirements – Software design – Software construction – Software testing – Software maintenance – Software configuration management – Software engineering management – Software engineering process – Software quality assurance
57/110
Rigorous
– Laws
– Principles
– Best practices
– Code conventions
58/110
Rigorous
– Laws
– Principles
– Best practices
– Code conventions
59/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
60/110
“A statement of an order or relation of phenomena that so far as is known is invariable under the given conditions” —Merriam-Webster
61/110
Meir M. « Manny » Lehman
– Died 29 December 2010 – Father of the laws of software evolution Stevens Award in 2003 – Cf. http://www.doc.ic.ac.uk/news/archive/story/ manny-lehman – Cf. http://www.ieeeghn.org/wiki/index.php/Oral- History:Meir_Lehman
Manny Lehman *1925 †2010
62/110
Context
– 1974
– Types of programs
63/110
1.
Continuing change: E-type systems must be continually adapted or they become progressively less satisfactory
2.
Increasing complexity: As an E-type system evolves its complexity increases unless work is done to maintain or reduce it
3.
Self regulation: E-type system evolution process is self regulating with distribution of product and process measures close to normal
4.
Conservation of organisational stability: The average effective global activity rate in an evolving E-type system is invariant over product lifetime
64/110
5.
Conservation of familiarity: As an E-type system evolves all must maintain mastery of its content and
6.
Continuing growth: The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime
7.
Declining quality: The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to environmental changes
8.
Feedback system: E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems; to achieve any improvement over any reasonable base
65/110
Frederick Brooks
– Born 19 April 1931 – Father of Brooks’ Law – IEEE J. von Neumann Medal in 1993 – ACM Turing Award in 1999 – Cf. http://en.wikipedia.org/wiki/Fred_Brooks
Frederick Brooks *1931
66/110
Context
– 1956–1964
Book
– The Mythical Man-Month: Essays on Software Engineering
Principle
– Adding manpower to a late software project makes it later
67/110
68/110
Rationale
– It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. New workers must first become educated about the work that has preceded them; also integrate with a team composed of multiple engineers who must educate the new worker in their area of expertise in the code base, day by day
69/110
Rationale
– Communication overheads increase as the number of people increases. The number of different communication channels increases along with the square of the number of people
70/110
Comments, solutions
– Brooks' Law applies to projects already late – The quantity, quality, and role of the people added to the project also count – Good management and development practices also help to minimize the impact of Brooks' Law – Rather than depending on heroes to carry the day with extraordinary efforts, Wiegers argues that ordinarily-skilled individuals can deliver timely results in the right work environment
71/110
Critics
“How to quadruple your productivity with an army of student interns”
https://blogs.oracle.com/ksplice/how-to-quadruple-your-productivity-with-an-army-of-student-interns
72/110
Lehman’s Laws Brooks’ Law Others…
More in the following classes
73/110
Rigorous
– Laws
– Principles
– Best practices
– Code conventions
74/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
75/110
“A rule or code of conduct” —Merriam-Webster
76/110
SOLID
Acronym coined by Michael Feathers for the principles described by Robert C. Martin – Single responsibility – Open/closed – Liskov substitution – Interface segregation – Dependency inversion
77/110
78/110
Single responsibility (SRP): “an object
should have only a single responsibility” or “a class or module should have one, and
79/110
Single responsibility (SRP): “an object
should have only a single responsibility” or “a class or module should have one, and
80/110
Single responsibility (SRP): “an object
should have only a single responsibility” or “a class or module should have one, and
81/110
Single responsibility (SRP): “an object
should have only a single responsibility” or “a class or module should have one, and
82/110
Single responsibility (SRP): “an object
should have only a single responsibility” or “a class or module should have one, and
83/110
Open/closed (OCP): “objects, classes, and
modules should be open for extension, but closed for modification”
84/110
Open/closed (OCP): “objects, classes, and
modules should be open for extension, but closed for modification”
– Typing vs. inheritance – Fragile base-class problem
85/110
Liskov substitution (LSP): “objects in a
program should be replaceable with instances of their subtypes without altering the correctness of that program”
86/110
Liskov substitution (LSP): “objects in a
program should be replaceable with instances of their subtypes without altering the correctness of that program”
– Inheritance – Polymorphism
87/110
Interface segregation (ISP): “many client-
specific interfaces are better than one general-purpose interface”
88/110
Interface segregation (ISP): “many client-
specific interfaces are better than one general-purpose interface”
– Encapsulation (information hiding) – Abstraction
89/110
Dependency inversion (DIP): “one should
depend upon abstractions, not upon implementations”
90/110
Dependency inversion (DIP): “one should
depend upon abstractions, not upon implementations”
– Typing – Factory design pattern – Iterator design pattern – Dependency injection
91/110
Bì Shēng (畢昇, 毕昇) in 1041–1048 Choi Yun-ui (최윤의) in 1234* Johannes Gutenberg circa 1450
* Not a mistake
92/110
Bì Shēng (畢昇, 毕昇) in 1041–1048 Choi Yun-ui (최윤의) in 1234* Johannes Gutenberg circa 1450
* Not a mistake 夢溪筆談／梦溪笔谈 Between 1031–1095
93/110
Bì Shēng (畢昇, 毕昇) in 1041–1048 Choi Yun-ui (최윤의) in 1234* Johannes Gutenberg circa 1450
백운화상초록불조직지심체요절 1377 * Not a mistake 夢溪筆談／梦溪笔谈 Between 1031–1095
94/110
Bì Shēng (畢昇, 毕昇) in 1041–1048 Choi Yun-ui (최윤의) in 1234* Johannes Gutenberg circa 1450
백운화상초록불조직지심체요절 1377 Gutenberg’s Bible
* Not a mistake 夢溪筆談／梦溪笔谈 Between 1031–1095
95/110
Before implementing a feature, especially a
complicated one, always look for simpler solutions
– Existing piece of code? – Existing libraries?
96/110
Yet, when reusing an existing piece of code,
beware of
– Licensing issues – Dependency issues – Ratio cost / benefit in the long term
97/110
DRY vs. WET
https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
98/110
DRY vs. WET
Don’t Repeat Yourself vs. Write Everything Twice
https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
99/110
My name is Yann-Gaël Guéhéneuc
100/110
My name is Yann-Gaël Guéhéneuc
101/110
My name is Yann-Gaël Guéhéneuc
102/110
My name is Yann-Gaël Guéhéneuc
… is my name invalid? … what about yours?
103/110
http://www.kalzumeus.com/2010/06/17/false
hoods-programmers-believe-about-names/
– People have exactly one canonical full name – People’s names do not change – People’s names are globally unique – …
104/110
Always validate assumptions with clients,
should be part of requirement engineering
– Beware of far-reaching (physically and temporally) assumptions “As for the password, the 18 characters is [a] limitation of the system, changing it to 19 would cause some other problems.” — Private e-mail communication with the developers of a major Web application
105/110
“Write code that is easy to delete, not easy to extend”
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
106/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
107/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
108/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code – Step 2: Don’t copy paste code
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
109/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code – Step 2: Don’t copy paste code – Step 3: Write more boilerplate
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
110/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code – Step 2: Don’t copy paste code – Step 3: Write more boilerplate – Step 4: Don’t write boilerplate
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
111/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code – Step 2: Don’t copy paste code – Step 3: Write more boilerplate – Step 4: Don’t write boilerplate – Step 5: Write a big lump of code
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
112/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code – Step 2: Don’t copy paste code – Step 3: Write more boilerplate – Step 4: Don’t write boilerplate – Step 5: Write a big lump of code – Step 6: Break your code into pieces
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
113/110
“Write code that is easy to delete, not easy to extend”
– Step 0: Don’t write code – Step 1: Copy-paste code – Step 2: Don’t copy paste code – Step 3: Write more boilerplate – Step 4: Don’t write boilerplate – Step 5: Write a big lump of code – Step 6: Break your code into pieces – Step 7: Keep writing code
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
114/110
Step 0: Don’t write code
– The more lines of code, the more
– But, saving one line of code is not worth the trouble… relatively speaking…
115/110
Step 1: Copy-paste code
– “Building reusable code is something that’s easier to do in hindsight with a couple of examples of use in the code base…” – “Once you make something a shared API, you make it harder to change.” – “It’s simpler to delete the code inside a function than it is to delete a function.”
116/110
Step 2: Don’t copy paste code
– “The stuff that ends up in a file called util.” – “Make a util directory and keep different utilities in different files.” – “… we are trying to keep the hard-to-delete parts as far away as possible from the easy-to-delete parts.”
117/110
Step 3: Write more boilerplate
– “Like with copy paste, we are duplicating parts of code to avoid introducing dependencies, gain flexibility, and pay for it in verbosity.” – “Minimising the dependencies or responsibilities
boilerplate to use it.”
118/110
Step 4: Don’t write boilerplate
– “Building simple-to-use APIs is about turning your boilerplate into a library.” – “… we are separating concerns: requests is about popular http adventures, urllib3 is about [choosing] your own adventure.” – “It’s often good to wrap third party libraries too…” – “Good APIs are designed […] for the programmers [..] layering is realising we can’t please everyone at once.”
119/110
Step 5: Write a big lump of code
– “… write a substantial amount of trashy code to hold the rest together.” – “… don’t write a web framework before writing an application.” – “Perlis: “Everything should be built top-down, except the first time”.” – “Becoming a professional software developer is accumulating a back-catalogue of regrets and mistakes.”
https://cpsc.yale.edu/epigrams-programming
120/110
Step 6: Break your code into pieces
– “We isolate the most frustrating parts to write, maintain, or delete away from each other.” – “A system where you can delete parts without rewriting others is often called loosely coupled, but it’s a lot easier to explain what one looks like rather than how to build it in the first place.”
121/110
Step 7: Keep writing code
– “Feature flags are one way to change your mind later.” – “The strategies I’ve talked about—layering, isolation, common interfaces, composition—are not about writing good software, but how to build software that can change over time.”
122/110
Summary
– SOLID – Do not reinvent the wheel – Beware of assumptions – Deletable code – Others…
More in the following classes
123/110
Rigorous
– Laws
– Principles
– Best practices
– Code conventions
124/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
125/110
“A best practice is a method or technique that has consistently shown results superior to those achieved with other means” —Wikipedia
126/110
Design patterns
– A reusable solution to a recurring problem within a given context in software design
Anti-patterns
– A reused solution to a recurring problem within a given context in software design, which is known unsuccessful (and the correct solution)
127/110
Design patterns Anti-patterns Others…
More in the following classes
128/110
Rigorous
– Laws
– Principles
– Best practices
– Code conventions
129/110
130/110
131/110
132/110
133/110
134/110
135/110
136/110
137/110
138/110
139/110
140/110
141/110
142/110
143/110
144/110
145/110
Definition
– Development – Operation – Maintenance – Systematic
– Disciplined
– Quantifiable
Conclusion
146/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
147/110
“Whose quantity can be determined” —WordReference.com
148/110
“Whose quantity can be determined” —WordReference.com
Problem: how to measure success? Solution: use explicit, repeatable criteria
149/110
Metrics
– A measure of some property of a piece of software or its specifications
Quality models
– A defined set of characteristics, and their relationships, which provides a framework for specifying quality requirements and evaluating quality (ISO/IEC 25010:2011)
150/110
Metrics Quality models
More in the following classes
151/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
152/110
Software engineering (SE) is the application
approach to the design, development,
SE is also the study of these approaches SE is the application of engineering to
software
153/110
“I’d recommend three things: learn how to abstract, learn how to work as part of a team, and study the code of others.” —Grady Booch in Masterminds of Programming
154/110
Remember
– Software engineering is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software – Problem solving – Information hiding – Agile – TDD – Lehman’s Laws – Brooks’ Law – SOLID – DRY, WET – Beware of assumptions – Deletable code