Design

1. Design Lecture 4 – Practical Issues in Design CIS 6101 – Software Processes and Metrics

2. Introduction • Design is very important. • Well designed software is • apparent to the users and programmers alike • Users: usability; learnability; architectue • Is useful, easy to use, maintain, extend, and understand. • In order to establish sustainable software, software must be designed to support and enhance changeability. • Agility is possible only with the ability to modify and easily extend the software.

3. Introduction – (2 of 2) • Design clearly has a central / essential role in software development regardless of methodology. • Design: most difficult component of SE due to factors such as • schedule, • people on the project and • constant change. • Designs cross a spectrum of being overdesigned and under-designed with an unfortunate number of projects at either end.

4. Over-designed Projects • May be the result of over-zealous application of engineering approach to software development. • This is the most widely taught approach to software development, which is topdown. • Top Down advocates thorough design before testing; assumes thoroughunderstanding of the requirements. • Unfortunately, when TDD is applied to software, result is • often overdesign and • high cost of change.. • Also, this approach is usually accompanied with stacks of documents and no code to support the elaborate design!

5. Under-designed Projects • aka “code-then-fix” development. Also called ‘fly by the seat of your pants.’ Just as bad. • Here, there’s little or no design. • Change is VERY difficult due to • tangled mess of code or • hard to comprehend. • Painful to work with, but may be a great form of job security. <Discuss>

6. The Middle Ground • For sustainable development, we need a middle ground. • Capture the good points of both • over-zealous design and • woefully inadequate design. • The rub: Need to have the discipline and ability to think about gooddesign while proceeding as rapidlyaspossible.

7. Extreme Programming (XP) (Beck 2004) • Outlines evolutionary or emergentdesign. • Method relies on simpledesign – • Design what you need, • Refactor (disciplined code changes) and • Test-first development (to ensure the behavior stays as originally intended. • Idea: get software into hands of users asap; • Evolve the design as requirements change. • Opponents cite that evolutionarydesign can lead to unintended oscillation, where the same code is repeatedly changed due to insufficient thought not put into the design. (There are many other issues too – Later)

8. Sustainable Development • Need balance the good aspects of front-end design w/various design techniques w/evolutionarydesign while avoiding the pitfalls of each. • Avoid overdesigning a solution by erring on the side of simple design while avoiding the documentation trap by focusing on producing software not documents. • Avoidunder-designing and code oscillation by thinking ahead and having a design vision and guiding principles.

9. How to Merge Good Up-Front Design w/Good Evolutionary Design One way: is a throughunderstanding of good, up-front design and good evolutionary design. • Practitioners of up-front design • concentrate on understanding what makes a good design • Practitioners of evolutionary design • focus on understanding good designs resulting from evolution and how they evolved. • Understanding the evolution of great software designs is more useful than studying the great designs themselves. • It is in the evolution that the real wisdom lies. • Without knowing how the design evolved into a design, you are more likely to misapply and over-engineer them.

10. But to Understand Good Design Evolution: • One must be able to recognize good design. • Design is pointless without evolution, because evolution is inevitable. • Lastly, good design doesn’t just emerge from a single individual no matter how brilliant. • Good design requires collaboration, because collaboration provides support as the team collectively works toward their goal while • balancing good design and • good design evolution.

11. Different Kinds of Design • In typical software projects there are many different kinds of design. • Software architecture (classes, hierarchies, methods) • The user interface (UI) • The web site • Marketing and sales material, (yes! Must be designed!) • User documentation (yes, documentation must be designed), • Test infrastructure, and • Database structure • Despite their differences, there are common design practices that can be applied. • We will discuss them.

12. Practice 1: Design Vision – simply an architectural overview • Iterative Design is difficult if you do not have a vision for the project even if you are only adding to an existing base. • A design vision / conceptual design is an overall picture of the pieces of your software • What they are, • what each does, • how they interoperate to solve problem at hand. • How they are dependent or provide for other components, etc… • Design vision can be as simple as a hand-drawn annotated sketch on a whiteboard or a UML diagram. • Regardless of form of vision, it should be kept up to date and must exist.

13. Practice 2: Guiding Principles • This too can be simply a short list of statements specifying overall design goals / requirements. • Helps designers make decisions consistent with design intent. • However, where the vision describes whatthe project is about, the guiding principles describe howthe project should be built.

14. Two Distinct Principles Recommended: • Engineering Guiding Principles – describe how the project is implemented in technical terms that the project team’s developers can understand. • User Experience Guiding Principles – describe attributes the user cares about. Described in a user-centric way that everyone on the team can understand.

15. Practice 3: Simple Design (1 of 2) • Means only design and code what you know you need while always striving for simplicity. • Extreme Programming – (recall) states only design what you need immediately. Recall also that this can lead to oscillation, where a body of code is continually re-factored to meet the current requirements, because there was no design or planning ahead. • If you know something is going to be required, then design it and build it, even if this means the user may only see a limited immediate benefit. But keep design simple.

16. Practice 3: Simple Design (2 of 2) • Interfaces: Add interfaces later that you don’t immediately need; • DesignPatterns: If problem is understood well enough to know its solution can be found in a designpattern, then pattern should be used. • Patterns work and are well-understood. • But patterns aren’t perfect and again, you need to always think about simplicity first.

17. Some are Uncomfortable with this Approach… • Important to accept that you’re going to get it wrong sometimes and over- or under-design in some instances. • That’s software development!! • Fix problem asap, learn from experience, and moveon. •  Teamwork, knowledge, experience, and collaboration are vital to make the right decision. • People learn from each other and the greater the collective experience and knowledge from the team, the greater the chance that the correct decision are going to be reached.

18. Practice 4: Refactoring (1 of 6) • Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. • It is a disciplinedway to clean up code tht minimizes the chances of introducing bugs. • It is NOT simply reviewing to improve code. • Considerable discipline and precision are needed! • In essence, when you re-factor you are improving the design of the code after it has been written (Fowler, 1999)

19. Practice 4: Refactoring (2 of 6) • Refactoring involves changing code in a very disciplinedway so that the • structure of the code is changed • but the code’s behavior remains unchanged. • It involves a step-by-step approach with tests inplace to catch problems as you proceed. • Rewriting is performed in a more ad-hoc delete/replace manner. • Refactoring will help keep your code clean, rewriting may not.

20. Practice 4: Refactoring (3 of 6) • It is simply not rewriting. • It is not a general cleaning up of code. • Refactoring uses terminology and patterns such as Extract Method, Extract Super-class, etc. • Refactoring requires automatedtests. • Again, Refactoring is not synonymous with rewriting!!

21. Practice 4: Refactoring (4 of 6) • Refactoring creates an image of the change that can be observed in looking at the re-factored code. • Rewriting does not guarantee better code or code easier to understand • Refactoring should lead to better design because of the steps involved with automated tests in place catch problems as the refactoring proceeds and ensure that the behavior of the resulting changes is correct.

22. Practice 4: Refactoring (5 of 6) • The quality of communication is high with refactoring (vice rewriting) • Has its own language used • “In this change I did an ‘Extract Method’ refactoring, removing largely duplicated code from methods X, Y, and Z” • The type of refactoring (extract method) immediately conveys to another developer an immediate and rough feeling of the changes that were made and the complexity of the work required without having to look at the code. • The level of confidence is higher with refactoring than with rewriting. • This is due to the discipline required.

23. Practice 4: Refactoring (6 of 6) • With refactoring, do not make multiple changes at one time. • Make small changes; safe steps that can be verified through tests. • However, when writing code, it is too easy to approach a problem with wild abandon, which often results in a worse state or no improvement.