Design Issues

1. Design Issues Practice: A generic View Design Principles

2. Reference • “Software Engineering, A Practitioner’s Approach, by Roger Pressman, sixth edition, 2005, ISBN: 0-07-285318-2. • An excellent reference type textbook for Software Engineering. • Used for approximately one-half the CS351 – Software Engineering Courses. • Design is the place where quality is fostered in Software Engineering.

3. The Essence Of Problem Solving • Understand the problem (communication and analysis) • Plan a solution (modeling and software design) • Carry out the plan (code generation) • Examine the results for accuracy (testing and quality assurance) • The main steps above were in a book by George Polya, published in 1945 !

4. Understand the Problem • Who has a stake in the solution of the problem? • What are the unknowns? • Can the problem be compartmentalized? • Can the problem be represented graphically? • Can an analysis model be created?

5. Plan the Solution • Have you seen similar problems before? • Has a similar problem been solved? • Can subproblems be defined? • Can you represent a solution in a manner that leads to effective implementation?

6. Carry Out the Plan • Does the solution conform to the plan? • Is each component part of the solution probably correct?

7. Examine the Result • Is it possible to test each component part of the solution? • Does the solution produce results that conform to the data, functions, features, and behavior that are required?

8. Core Principles • The reason it All exists. • Keep It Simple Stupid. • Maintain the Vision. • What you produce, others will consume. • Be Open to the Future. • Plan Ahead for Reuse. • Think!

9. The Reason It All Exists • A software system exists for one reason: to provide value to its users. • Make all decisions with this in mind. • Before adding something, ask yourself: “Does this add real value to the system?” • If the answer is NO!, DON’T DO IT!

10. KISS : Keep It Simple Stupid • All designs should be as simple as possible, but no simpler! • Simple DOES NOT mean Quick and Dirty. • Simplicity in design makes software that: • Is easier to understand. • Is easier to maintain. • Is less error-prone. • It often takes a lot of thought and work over multiple iterations to simplify.

11. Maintain the Vision • A clear vision is essential to the success of a software project. • Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws…

12. What You Produce, Others Will Consume • In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system. • Always specify, design, and implement knowing someone else will have to understand what you are doing. • This audience is potentially large.

13. Be Open To the Future • Systems with a long lifetime have more value. • True “industrial strength” software systems must endure. • They must be ready to adapt to the changing environments. • Never design yourself into a corner. • Always ask “What if?” • Prepare for all possible anwers.

14. Plan Ahead For Reuse • Reuse saves time and money. • This can be a hard goal to achieve. • To reap the benefits of reuse, requires forethought and planning. • Using modern practices helps. • Communicating opportunities for reuse to others in the organization is important. • Reuse reduces costs and increases value!

15. Think! • Placing clear, complete thought before action almost always produces better results. • Design itself may be new to students since they have often only worked on “toy problems” and “toy programs”. • Example: • The web server is down. • Tried to ssh to my computer and had trouble. • Stopped for 5 minutes to think about it. • Remembered I had downloaded slides.

16. Design Modeling Principles • A software design model is the equivalent of an architect’s plans for a house. • Many systems of design have been used: • Data driven design. • Data structure driven design. • Pattern Driven design. • Object Oriented design.

17. Design Principles • Design should be traceable to the analysis model. • Always consider the architecture of the system to be built. • Design of data is as important as design of processing functions. (13 file story, dates) • Interfaces (both internal and external) must be designed with care. • User interface design should be tuned to the needs of the end-user.

18. Design Principles (cont.) • Component-level design should be functionally independent. • Components should be loosely coupled to one another and to the external environment. • Design representations (models) should be easily understandable. • The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity.

19. Design Model Component Level Design Interface Design Architectural Design Data/Class Design

20. Design Model (cont.) • Data/Class Design transforms analysis-class models into design class realizations and data structures. • Architectural Design defines the relationship between major structural elements of the software. • Interface design describes how the software communicates with systems that interoperate with it, and with the humans who use it. • Component Level design transforms structural elements of the software architecture into a procedural description of software components.

21. Evaluation Of A Good Design • The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. • The design must be a readable, understandable guide for those who generate code, and for those who test and subsequently support the software.

22. Evaluation Of A Good Design (cont.) • The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

23. Design Quality Guidelines • The design architecture • Should be created using recognizable styles or patterns. • Should be composed of components that exhibit good design characteristics (more later). • Should be implemented in an evolutionary fashion facilitating implementation and testing.

24. Design Quality Guidelines (cont.) • A design should be modular. • A design should contain distinct representations of data, architecture, interfaces, and components. • A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. • A design should lead to components that exhibit independent functional characteristics.

25. Design Quality Guidelines (cont.) • A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. • A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. • A design should be represented using a notation that effectively communicates its meaning.

26. Good Design Attributes • Functionality • Feature set • Generality of functions • Security of overall system • Usability • Reliability • Performance • Supportability

27. Design Concepts • Abstraction • Abstraction is one of the fundamental ways humans deal with complexity. • Procedural abstraction (OPEN for open the door) • Data abstraction (DOOR for all the parts of a door)

28. Design Concepts (cont.) • Architecture • Overall structure • Represented using one or more models • Structural models • Framework models • Dynamic models • Process models • Functional models

29. Design Concepts (cont.) • Patterns • Here’s where the Design Patterns that Michael has covered fit.

30. Design Concepts (cont.) • Modularity Total Software Cost Cost or Effort Region of Minimum Cost Cost To Integrate M Cost / Module Number of Modules We can’t predict an accurate M!

31. Design Concepts (cont.) • Information Hiding • Characterized by design decisions that (each) hides from all others.

32. Design Concepts (cont.) • Functional Independence • Single minded • Aversion to excessive interaction • Cohesion (We want HIGH cohesion!) • Coupling (We want LOW coupling!)

33. Design Concepts (cont.) • Refinement • Standard top-down strategy. • Originally proposed by Wirth in 1971!

34. Design Concepts (cont.) • Refactoring • Reorganizing and simplifying the design (or code) of a component without changing its function or behavior. • It is assumed that this change will improve the internal structure.

35. Design Concepts (cont.) • Design Classes • User Interface Classes • Business Domain Classes • Process Classes • Persistent Classes • System Classes • A well-formed design class is complete and sufficient, primitive, high cohesion, and low coupling.