Where are we going? EEC 521: Software Engineering. A Note on Quality. What is Design? Introduction to Design. Our focus

Transcription

1 Where are we going? Many levels of design: EEC 521: Software Engineering Introduction to Our focus Method Class/Component Subsystem GUI Data Format Architectural 10/6/09 EEC 521: Software Engineering 1 10/6/09 EEC 521: Software Engineering 3 What is? A Note on Quality Requirements Engineering Analysis Engineering Quality isn t something you lay on top of subjects and objects like tinsel on a Christmas tree. Robert Pirsig work is about making decisions. Each decision influences the quality of the final product. A blueprint for constructing software The most creative part of the development process 10/6/09 EEC 521: Software Engineering 2 tools help us make the decisions that engender quality. 10/6/09 EEC 521: Software Engineering 4

2 Your Moment of Zen The Quality Without a Name: 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 Levels of Detail Refinement refers to the process of revealing progressively more detail about a particular thing Software development is a refinement process Analysis More Detail As we refine the design model, additional concerns will be revealed 10/6/09 EEC 521: Software Engineering 5 10/6/09 EEC 521: Software Engineering 7 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. 10/6/09 EEC 521: Software Engineering 6 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. Results: Improved comprehensibility Increased traceability Increased reusability Reduced maintenance effort 10/6/09 EEC 521: Software Engineering 8

3 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. Information Hiding Example Consider the implementation of a basic Stack module. Client operations: Push element Pop element Access top element Check length But how should this decomposition be performed? 10/6/09 EEC 521: Software Engineering 9 10/6/09 EEC 521: Software Engineering 11 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. Information Hiding Example Consider the implementation of an abstract data type. An abstract data type defines: A set of abstract values Operations for manipulating those values This is commonly referred to as information hiding. Information hiding is one of the most important design techniques when designing for change. public interface Stack { void push(object obj); Object pop(); Object gettop(); int getlength(); } public class StackImpl implements Stack { } 10/6/09 EEC 521: Software Engineering 10 10/6/09 EEC 521: Software Engineering 12

4 Information Hiding Example Now suppose that StackImpl exposes its representation by making its top member public. top data data data Clients of StackImpl can now perform operations on the linked list directly. null 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. 10/6/09 EEC 521: Software Engineering 13 10/6/09 EEC 521: Software Engineering 15 ing for Change? There are at least two major problems with this design decision. What are they? Coping with Complexity Software systems are some of the most complex manmade artifacts in existence. Abstractions allow us to hide complexity that would otherwise overwhelm our intellectual abilities. In object-oriented systems, classes are the basic units of modularization and abstraction. How do we describe these abstractions? 10/6/09 EEC 521: Software Engineering 14 10/6/09 EEC 521: Software Engineering 16

5 Class Specifications A class specification is a tool for describing the abstraction implemented by a class. A class specification consists of four primary elements. A Sample Interface Specification public interface Queue { /* modeled by: String of Object initial value: <> */ Abstract model (may include constraints) Initial value A description of the abstract data model void enqueue(object obj); /* */ An initial value for the data model A list of exposed methods (including signature information) A list of method contracts (in terms of the abstract model) A description of each method s preconditions A description of each method s postconditions } Object dequeue() /* requires: ( self!= 0) ensures: self = dequeue() * #self */ Precondition Postcondition 10/6/09 EEC 521: Software Engineering 17 Contracts aren t always this formal. 10/6/09 EEC 521: Software Engineering 19 by Contract by Contract is a programming methodology based on the metaphor of a binding contract. Every method is characterized by two sets of clauses. Preconditions Properties that must be satisfied before calling a method Postconditions Properties guaranteed by a method upon termination, assuming its preconditions were satisfied Method contracts bind callers and callees. 10/6/09 EEC 521: Software Engineering 18 Specifying Classes is Hard Work Developing class/interface specifications for a real system can be a challenging task. Although it is considered a best practice to specify every class/interface in detail, almost nobody does it in practice. Time- and cost-to-market requirements make some best practices economically infeasible. 10/6/09 EEC 521: Software Engineering 20

6 Specifications in Practice In industry, software engineers specify many classes/interfaces informally. Only certain classes/interfaces are specified in the detailed format we ve been examining. Core system classes/interfaces Complex system classes/interfaces Reusable classes/interfaces 10/6/09 EEC 521: Software Engineering 21 Reading Assignment Iterators Reconsidered. J. O. Hallstrom, S. M. Pike and N. Sridhar. ICSE Workshop on Component-Based Software Engineering at ICSE May Orlando FL. 10/6/09 EEC 521: Software Engineering 22