1. Introduction to Design (and Zen) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom jasonoh@cs.clemson.edu Authorship Disclaimer. These slides are intended to serve as teaching instruments for an undergraduate course in Software Engineering. While the slides were formatted by Dr. Hallstrom, the content is compiled from other sources, including the readings listed on the course website, Dr. Pressman’s Software Engineering textbook, and various internet materials. In almost every case, the ideas belong to someone other than Dr. Hallstrom. Indeed, text is often quoted verbatim without an explicit citation (to improve the readability of the slides). The original authors retain all copyrights. If you are interested in citing any of the material in these slides, please contact Dr. Hallstrom for the original source(s). DO NOT CITE THIS PRESENTATION. THE CONTENT SHOULD NOT BE ATTRIBUTED TO DR. HALLSTROM. SEE DR. HALLSTROM IF YOU HAVE ANY QUESTIONS.

2. CpSc 372 What is Design? Requirements Engineering Requirements Engineering Analysi s Model Analysi s Model Design Engineering Design Engineering Design Model Design Model A blueprint for constructing software The most creative part of the development process.

3. CpSc 372 Where are We Going? Many “levels” of design: Design Model Architectural Design Subsystem Design Subsystem Design Class/Component Design Class/Component Design Method Design Method Design … … GUI Design GUI Design Data Format Design Data Format Design … … Our focus

4. CpSc 372 A Note on Quality “Quality isn’t something you lay on top of subjects and objects like tinsel on a Christmas tree.” – Robert Pirsig Design work is about making decisions. Each decision influences the quality of the final product. Design tools help us make the decisions that foster quality.

5. CpSc 372 Your Moment of Zen “This oneness, or the lack of it, is the fundamental quality for anything. Whether it is in a poem, or a man, or a building full of people, or in a forest, or a city, everything that matters stems from it. It embodies everything.” – Christopher Alexander The Quality Without a Name:

6. Design Concepts CpSc 372: Introduction to Software Engineering Jason O. Hallstrom jasonoh@cs.clemson.edu

7. CpSc 372 Software Concerns Our analysis model describes a set of concerns associated with the software to be developed. Every concern describes an independent concept, goal, task, or purpose. Data concerns Feature concerns Security concerns Performance concerns etc. A concern is any aspect of the system that can be understood in isolation.

8. CpSc 372 Levels of Detail Refinement refers to the process of revealing progressively more detail about a particular thing. Software development is a refinement process. Analysis Model Analysis Model Design Model Design Model More Detail As we refine the design model, additional concerns will be revealed.

9. CpSc 372 Separation of Concerns Separation of concerns refers to our ability to identify and manipulate design concerns independently. Separation of concerns is one of our most important design desiderata. Improved comprehensibility Increased traceability Increased reusability Reduced maintenance effort Results:

10. CpSc 372 Examples? In our online book store case study, what are some example concerns that should be treated independently?

11. CpSc 372 Modularity A module is a programming language entity that packages a set of code elements into a reusable unit. In object-oriented languages, the class is the primary unit of modularization. Modules allow us to decompose a complex system into more intellectually manageable pieces. But how should this decomposition be performed?

12. CpSc 372 Information Hiding Each module should modularize the code associated with a single concern. All design decisions associated with that concern should be hidden from the other modules in the system. This is commonly referred to as information hiding. Information hiding is one of the most important design techniques when designing for change.

13. CpSc 372 Information Hiding Example Consider the implementation of a basic Stack module. Push element Pop element Access top element Check length Client operations:

14. CpSc 372 Information Hiding Example (cont’d) Consider the implementation of an abstract data type. An abstract data type defines: A set of abstract values Operations for manipulating those values public interface Stack { void push(Object obj); Object pop(); Object getTop(); int getLength(); } public class StackImpl implements Stack { … }

15. CpSc 372 Information Hiding Example (cont’d) Now suppose that StackImpl exposes its representation by making its top member public. data top data null Clients of StackImpl can now perform operations on the linked list directly.

16. CpSc 372 Design for Change? There are at least two major problems with this design decision. What are they?

17. CpSc 372 Abstraction An abstraction is a cover story that hides details irrelevant to a particular task or concept. mathematical set { 1, 0, 2, 10 } mathematical set { 1, 0, 2, 10 } 1011… class Set { … } +.5v, -.5v, +.5v, +.5v, … “abstracts” “Abstraction is one of the fundamental ways that we as humans cope with complexity.” – Grady Booch

18. CpSc 372 Modes of Abstraction Procedural abstraction  Focusing on the logical properties of an action  Ignoring the details of the action’s implementation Data abstraction  Focusing on the logical properties of data  Ignoring the details of the data’s representation Class Abstraction  Procedural abstraction + data abstraction Software engineers focus on three primary modes of abstraction.

19. CpSc 372 Encapsulation Encapsulation and information hiding are often used interchangeably. Encapsulation suggests the existence of a boundary that hides information contained within the boundary. When you encapsulate a design decision, you hide that design decision within a shell.

20. CpSc 372 Encapsulation and Abstraction Abstractions allow us to think of objects in terms of their logical properties. Encapsulation protects us from irrelevant details, and protects the abstraction represented by each class.

21. CpSc 372 Breaking Encapsulation Public classes should encapsulate their representations and implementations. Representation = member variables Implementation = method implementations Violating encapsulation has important consequences for objects and their clients.