1. Class Specifications 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 Coping With Complexity Abstractions allow us to hide complexity that would otherwise overwhelm our intellectual abilities. Software systems are some of the most complex manmade artifacts in existence. In object-oriented systems, classes are the basic units of modularization and abstraction. How do we describe these abstractions?

3. CpSc 372 Class Specifications A class specification consists of four primary elements. A description of the abstract data model 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 A class specification is a tool for describing the abstraction implemented by a class.

4. CpSc 372 Design by Contract Design 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.

5. CpSc 372 A Sample Interface Specification public interface Stack { /* modeled by: String of Object initial value: <> */ void push(Object obj); /* … */ Object pop() /* requires: (|self| != 0) ensures: there exists a: String of Object, b: Object (#self = * a) and (self = a) and (pop() = b) */ … } Abstract model (may include constraints) Initial value Precondition Postcondition Contracts aren’t always this formal.

6. CpSc 372 Specification Exercise #1 How would we specify getLength(), getTop(), and push() ?

7. CpSc 372 Specifying Classes is Hard Work! Although it is considered a best practice to specify every class/interface in detail, almost nobody does it in practice. Developing class/interface specifications for a real system can be a challenging task. Time- and cost-to-market requirements make some best practices economically infeasible.

8. CpSc 372 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

9. CpSc 372 Specification Exercise #1 How would you specify the Queue interface? public interface Queue { void clear(); void enqueue(Object x); Object dequeue(); Object getFront(); int getLength(); }