1 / 35

Design Issues

This reference book explores design principles in software engineering, providing guidance on understanding problems, planning solutions, carrying out plans, and examining results. It emphasizes core principles like simplicity, vision maintenance, future readiness, and reuse planning. The book also discusses design modeling principles and provides guidelines for component-level, interface, architectural, and data/class design. Suitable for software engineering courses.

gloriathompson
Download Presentation

Design Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related