Systematic 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) • Associations, aggregations, specialisations… 47/110
Systematic 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); } 48/110
That is the oracle Systematic 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
Outline Definition – Development – Disciplined • Sub-disciplines – Operation • Laws – Maintenance • Principles – Systematic • Best practices • Agile – Quantifiable • TDD Conclusion • Oracles 50/110
Definition Software engineering (SE) is the application of a systematic, disciplined , quantifiable approach to the design, development, operation, and maintenance of software SE is also the study of these approaches SE is the application of engineering to software 51/110
Disciplined “Divided in sub-disciplines” “Rigorous” —WordReference.com 52/110
Disciplined “Divided in sub-disciplines” “Rigorous” —WordReference.com Problem: how to develop quality products? Solution: use appropriate, explicit, repeatable rules 53/110
Outline Definition – Development – Disciplined • Sub-disciplines – Operation • Laws – Maintenance • Principles – Systematic • Best practices • Agile – Quantifiable • TDD Conclusion • Oracles 54/110
Disciplined 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 55/110
Disciplined 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
Disciplined Rigorous – Laws • Lehman’s Laws • Brooks’ Law – Principles • SOLID • Do not reinvent the wheel • Beware of assumptions • Deletable code – Best practices • Design patterns • Anti-patterns – Code conventions 57/110
Disciplined Rigorous – Laws • Lehman’s Laws • Brooks’ Law – Principles • SOLID • Do not reinvent the wheel • Beware of assumptions • Deletable code – Best practices • Design patterns • Anti-patterns – Code conventions 58/110
Outline Definition – Development – Disciplined • Sub-disciplines – Operation • Laws – Maintenance • Principles – Systematic • Best practices • Agile – Quantifiable • TDD Conclusion • Oracles 59/110
Laws “A statement of an order or relation of phenomena that so far as is known is invariable under the given conditions” —Merriam-Webster 60/110
Manny Lehman Meir M. « Manny » Lehman – Died 29 December 2010 Manny Lehman *1925 †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 61/110
Lehman’s Laws Context – 1974 • IBM OS/360 et OS/370 – Types of programs • S: can be formally specified • P: follow an iterative development process • E: are embedded in our environment 62/110
Lehman’s Laws Continuing change : E-type systems must be continually 1. adapted or they become progressively less satisfactory Increasing complexity : As an E-type system evolves its 2. complexity increases unless work is done to maintain or reduce it Self regulation : E-type system evolution process is self 3. regulating with distribution of product and process measures close to normal Conservation of organisational stability : The average 4. effective global activity rate in an evolving E-type system is invariant over product lifetime 63/110
Lehman’s Laws Conservation of familiarity : As an E-type system 5. evolves all must maintain mastery of its content and behaviour. The average incremental growth is invariant Continuing growth : The functional content of E-type 6. systems must be continually increased to maintain user satisfaction over their lifetime Declining quality : The quality of E-type systems will 7. appear to be declining unless they are rigorously maintained and adapted to environmental changes Feedback system : E-type evolution processes constitute 8. multi-level, multi-loop, multi-agent feedback systems; to achieve any improvement over any reasonable base 64/110
Frederick Brooks Frederick Brooks Frederick Brooks – Born 19 April 1931 *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 65/110
Brooks’ Law Context – 1956–1964 • Manager of the IBM OS/360 development project • Delays in the delivery Book – The Mythical Man-Month: Essays on Software Engineering Principle – Adding manpower to a late software project makes it later 66/110
Brooks’ Law 67/110
Brooks’ Law 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 68/110
Brooks’ Law 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 69/110
Brooks’ Law 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 70/110
Brooks’ Law Critics “How to quadruple your productivity with an army of student interns” • Tolerate a little crowding • Locate next to a deep pool of hackers • Know who the best people are and only hire them • Pay well • Divide tasks to be as loosely-coupled as possible • Design your intern projects in advance 71/110 https://blogs.oracle.com/ksplice/how-to-quadruple-your-productivity-with-an-army-of-student-interns
Laws Lehman’s Laws Brooks’ Law Others… More in the following classes 72/110
Disciplined Rigorous – Laws • Lehman’s Laws • Brooks’ Law – Principles • SOLID • Do not reinvent the wheel • Beware of assumptions • Deletable code – Best practices • Design patterns • Anti-patterns – Code conventions 73/110
Outline Definition – Development – Disciplined • Sub-disciplines – Operation • Laws – Maintenance • Principles – Systematic • Best practices • Agile – Quantifiable • TDD Conclusion • Oracles 74/110
Principles “A rule or code of conduct” —Merriam-Webster 75/110
Principles SOLID Acronym coined by Michael Feathers for the principles described by Robert C. Martin – Single responsibility – Open/closed – Liskov substitution – Interface segregation – Dependency inversion 76/110
SOLID 77/110
SOLID Single responsibility (SRP): “an object should have only a single responsibility” or “a class or module should have one, and only one, reason to change” 78/110
SOLID Single responsibility (SRP): “an object should have only a single responsibility” or “a class or module should have one, and only one, reason to change ” 79/110
SOLID Single responsibility (SRP): “an object should have only a single responsibility” or “a class or module should have one, and only one, reason to change ” Change cannot be avoided, see Lehman’s Laws 80/110
SOLID Single responsibility (SRP): “an object should have only a single responsibility” or “a class or module should have one, and only one, reason to change ” Change must be acknowledged and planned for from the beginning 81/110
SOLID Single responsibility (SRP): “an object should have only a single responsibility” or “a class or module should have one, and only one, reason to change ” Beware of not over-engineering your solution (cf. Kerievsky and agile development) 82/110
SOLID Open/closed (OCP): “objects, classes, and modules should be open for extension, but closed for modification” 83/110
SOLID Open/closed (OCP): “objects, classes, and modules should be open for extension, but closed for modification” – Typing vs. inheritance – Fragile base-class problem 84/110
SOLID Liskov substitution (LSP): “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” 85/110
SOLID Liskov substitution (LSP): “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” – Inheritance – Polymorphism 86/110
SOLID Interface segregation (ISP): “many client- specific interfaces are better than one general-purpose interface” 87/110
SOLID Interface segregation (ISP): “many client- specific interfaces are better than one general-purpose interface” – Encapsulation (information hiding) – Abstraction 88/110
SOLID Dependency inversion (DIP): “one should depend upon abstractions, not upon implementations” 89/110
SOLID Dependency inversion (DIP): “one should depend upon abstractions, not upon implementations” – Typing – Factory design pattern – Iterator design pattern – Dependency injection • Visitor design pattern • Strategy design pattern 90/110
Do Not Reinvent the Wheel Bì Shēng ( 畢昇 , 毕 昇 ) in 1041–1048 Choi Yun-ui ( 최윤의 ) in 1234 * Johannes Gutenberg circa 1450 * Not a mistake 91/110
Do Not Reinvent the Wheel 夢溪筆談／ 梦 溪 笔 谈 Between 1031–1095 Bì Shēng ( 畢昇 , 毕 昇 ) in 1041–1048 Choi Yun-ui ( 최윤의 ) in 1234 * Johannes Gutenberg circa 1450 * Not a mistake 92/110
Do Not Reinvent the Wheel 夢溪筆談／ 梦 溪 笔 谈 백운화상초록불조 직지 심체요절 Between 1031–1095 1377 Bì Shēng ( 畢昇 , 毕 昇 ) in 1041–1048 Choi Yun-ui ( 최윤의 ) in 1234 * Johannes Gutenberg circa 1450 * Not a mistake 93/110
Do Not Reinvent the Wheel 夢溪筆談／ 梦 溪 笔 谈 Gutenberg’s Bible 백운화상초록불조 직지 심체요절 Between 1031–1095 1377 c. 1450 Bì Shēng ( 畢昇 , 毕 昇 ) in 1041–1048 Choi Yun-ui ( 최윤의 ) in 1234 * Johannes Gutenberg circa 1450 * Not a mistake 94/110
Do Not Reinvent the Wheel Before implementing a feature, especially a complicated one, always look for simpler solutions – Existing piece of code? – Existing libraries? 95/110
Do Not Reinvent the Wheel Yet, when reusing an existing piece of code, beware of – Licensing issues – Dependency issues – Ratio cost / benefit in the long term 96/110
Do Not Reinvent the Wheel DRY vs. WET 97/110 https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
Do Not Reinvent the Wheel DRY vs. WET Don’t Repeat Yourself vs. Write Everything Twice 98/110 https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
Beware of Assumptions My name is Yann-Gaël Guéhéneuc 99/110
Beware of Assumptions My name is Yann-Gaël Guéhéneuc 100/110
Recommend
More recommend
