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.

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)

18. Desirable characteristics

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.

22. Immobility
Hard to reuse.

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.

26. Opacity
Difficult to understand!

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.”