Software design - Write solid software with the ideal chalk
1 like1,126 views
The document discusses various approaches to software design, including skipping design phases and starting coding immediately (the programmer's approach) versus completing all analysis and design using UML diagrams before writing any code (the architect's approach). It also discusses principles of software design like separation of concerns, information hiding, high cohesion, low coupling, and SOLID principles. The document advocates designing software using the IDEAL CHALK principles: program to interfaces, follow the DRY principle, encapsulate what varies, depend on abstractions, apply the least knowledge principle, favor composition over inheritance, follow the Hollywood principle, apply design patterns, and strive for loosely coupled systems.
![What is software design?
“[...] software design means the
conception, invention, or
contrivance of a scheme for
turning a specification for a
computer program into an
operational program.”
- Steve McConnell,
Code Complete (2004)](https://image.slidesharecdn.com/softwaredesign-writesolidsoftwarewiththeidealchalk-140107231710-phpapp02/85/Software-design-Write-solid-software-with-the-ideal-chalk-3-320.jpg)
![Some thing are better done than described
“[...] you should tend to view
requirements gathering, design
and implementation as different
facets of the same process – the
delivery of a quality system.”
- Andrew Hunt,
The pragmatic programmer (2000)](https://image.slidesharecdn.com/softwaredesign-writesolidsoftwarewiththeidealchalk-140107231710-phpapp02/85/Software-design-Write-solid-software-with-the-ideal-chalk-8-320.jpg)
![Where is the design?
“[...] the design of a
software project is
documented primarily by
its source code.”
- Robert Martin,
Agile Software Development (2002)](https://image.slidesharecdn.com/softwaredesign-writesolidsoftwarewiththeidealchalk-140107231710-phpapp02/85/Software-design-Write-solid-software-with-the-ideal-chalk-11-320.jpg)
![Low Coupling
“[...]; It is a measure of the strength of interconnection.”
- Structured Design, Edward Yourdon (1979)](https://image.slidesharecdn.com/softwaredesign-writesolidsoftwarewiththeidealchalk-140107231710-phpapp02/85/Software-design-Write-solid-software-with-the-ideal-chalk-17-320.jpg)
Software design - Write solid software with the ideal chalk
- 1. Software design Write SOLID software with the IDEAL CHALK Company LOGO Alejandro Claro Mosqueda
- 2. What is all this stuff?! K.I.S.S . Information hiding
- 3. What is software design? “[...] software design means the conception, invention, or contrivance of a scheme for turning a specification for a computer program into an operational program.” - Steve McConnell, Code Complete (2004)
- 4. Programmer's approach to software engineering Skip requirements engineering and design phases; START WRITING CODE!! ● We need to show something to the customer real quick. ● We are judged by the amount of LOC/month. ● We expect or know that the schedule is too tight. ● Design is a waste of time.
- 5. Architect's approach to software engineering Don't write a single line of code until analysis and design phases are over; I WANT TO SEE UML DIAGRAMS FIRST!! ● Implementation is a peace of cake after UML diagrams are done. ● We can not fail if complete system design is ready first.
- 6. Software development is a “wicked” problem ● It is nondeterministic (There is no definite formulation). ● There is no stopping rule. ● Solutions are not true-or-false, but good or bad. ● It is a sloppy process. ● It is a heuristic process (trial-and-error). ● It is about tradeoffs and priorities. ● It involves restrictions. ● It is emergent.
- 7. Where is the design? Technical specifications documents? UML diagrams document?
- 8. Some thing are better done than described “[...] you should tend to view requirements gathering, design and implementation as different facets of the same process – the delivery of a quality system.” - Andrew Hunt, The pragmatic programmer (2000)
- 9. Where is the design? VS .
- 10. Where is the design? “Martin’s First Law of Documentation: Produce no document unless its need is immediate and significant.” - Robert Martin, Agile Software Development (2002)
- 11. Where is the design? “[...] the design of a software project is documented primarily by its source code.” - Robert Martin, Agile Software Development (2002)
- 12. Where is the design? “The source code IS the design!” - Jack Reeves, What is software design? (1992)
- 13. Separation of Concerns “no one’s skull is really big enough to contain a modern computer program.” - Dijkstra (1972) Don't let plumbing code pollute your software.
- 14. Information hiding “Primary criteria for system modularization should concern the hiding of critical design decisions.” - David Parnas (1972)
- 15. Levels of design ● System ● Modules ● Classes ● Functions/Methods Top-down / Stepwise refinement or bottom-up design?
- 16. High Cohesion “Cohesion is a measure of the strength of association of the elements inside a module.” - Tom DeMarco (1979) What about doing just one thing and do it well?!
- 17. Low Coupling “[...]; It is a measure of the strength of interconnection.” - Structured Design, Edward Yourdon (1979)
- 19. Bad smells Do you really know when your code stinks?
- 20. Rigidity . Software difficult to change.
- 21. Fragility Tendency to break in many places when a single change is made.
- 23. Viscosity Doing thing wrong is easier than doing things right.
- 24. Needless complexity Over-design! or elements not currently useful.
- 25. Needless repetition Copy/Paste is useful text editing, but disastrous for code editing.
- 27. What is really a design smell? It is a symptom. A violation of principles.
- 28. SOLID principles (Classes/Functions) Software development is not a Jenga game!
- 29. Single responsibility principle Just because you can, doesn't mean you should
- 30. Open/Close principle Open chest surgery is not needed when putting on a coat
- 31. Liskov substitution principle If it looks like a duck, quacks like a duck, but needs batteries Probably have the wrong abstraction!
- 32. Interface segregation principle You want me to plug this in, where?
- 33. Dependency inversion principle Would you solder a lamp directly to the electrical wiring in a wall?
- 34. IDEAL CHALK Write SOLID software with the IDEAL CHALK
- 35. Program to Interface NOT Implementation Think what to do; no who does it!
- 36. DRY principle Changes shall be made only at one place!
- 37. Encapsulate what varies Don't let tomatoes spoil potatoes!
- 38. Depend on abstractions, NOT concrete classes Be generic not specific!
- 39. Least Knowledge Principle Demeter's Law – Talk to friends not strangers
- 40. Favour Composition Over Inheritance Hang the clock; don't embed in the wall.
- 41. Hollywood Principle Don't call us; We will call you!
- 42. Apply Design Pattern wherever possible Don't reinvent the wheel!
- 43. Design patterns ● Provides solution to a recurring problem. ● Documents well-prove design experience. ● Abstraction above the level of a single component. ● Provides common vocabulary and understanding. ● Are a means of documentation. ● Supports construction of software with defined properties.
- 44. Strive for Loosely Coupled System Don't get entangled!
- 45. KISS - Keep It Small and Simple If only there were an easier way!
- 46. More principles (System/Modules) Next time... Granularity (Modules Cohesion) ● REP: Reuse-Release equivalence principle. ● CCP: Common-Closure principle. ● CRP: Common-Reuse principle. Stability (Modules Coupling) ● ADP: Acyclic-Dependencies principle. ● SDP: Stable-Dependencies principle. ● SAP: Stable-Abstractions principle.
- 47. Lets Talk! “Simple things should be simple and complex things should be possible.”