Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03

CEN 4010 Class /032 Other Design Patterns Bridge – decouples the interface of a class from its implementation. Adapter – encapsulates a piece of legacy code that was not designed to work with the system. Strategy – decouples an algorithm from its implementation(s). Abstract Factory – encapsulates the creation of families of related objects. Shields the client from the creation process and prevents the use of objects from different (incompatible) families.

CEN 4010 Class /033 Other Design Patterns cont Command – decouples the objects responsible from command processing from commands themselves. Protects these objects from changes due to new functionality. Composite – encapsulates hierarchies by providing a common superclass for aggregate and leaf nodes. New types of leaves can be added without modifying existing code.

CEN 4010 Class /034 Other Design Patterns cont Identifying the correct design pattern for a given problem is not easy unless you already have some experience in using design patterns. Terms associated with design patterns: –Framework –Class library –Component Framework – a set of classes providing a general solution that can be refined to provide an application or a subsystem.

CEN 4010 Class /035 Other Design Patterns cont Frameworks focus on reuse of concrete designs, algorithms, and implementations in a particular programming language. Frameworks focus on a particular application domain. Class libraries are less domain specific and provide a smaller scope of reuse. Class libraries are typically passive i.e., they do not implement or constrain the control flow.

CEN 4010 Class /036 Object Design Concepts Types signatures and visibility –During object design the system model is refined by adding types and visibility. –Type? –Signature? –Visibility? –What are the 3 levels of visibility? –How is visibility done in Eiffel? (Meyer)

CEN 4010 Class /037 Concepts cont Contracts: Invariants, Preconditions, Postconditions: –Contracts are constraints on a class that enable caller and callee to share the same assumptions about the class (Meyer ’97). –A contract specifies constraints that the caller must meet before using the class as well as constraints that are ensured by the callee when used.

CEN 4010 Class /038 Concepts cont –Design by contract – views the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations (Meyer ’97). –Defensive programming ? –An invariant is a predicate that is always true for all the instances of a class. Invariants are constraints associated with classes or interfaces. Invariants are used to specify consistency constraints among class attributes.

CEN 4010 Class /039 Concepts cont –A precondition is a predicate that must be true before an operation is invoked. Preconditions are associated with a specific operation. Preconditions are used to specify constraints that a caller must meet before calling an operation. E.g., put may not be called if the stack representation is full. A correct system will never execute a call in a state that does not satisfy the precondition of a called routine????

CEN 4010 Class /0310 Concepts cont –A postcondition is a predicate that must be true after an operation is invoked. Postconditions are associated with a specific operation. Postconditions are used to specify constraints that the object must ensure after the invocation of the operation. E.g., After a put, the stack may not be empty, its top is the element just pushed, and its number of elements bas been increased by one.

CEN 4010 Class /0311 Concepts cont Note: –The precondition is an obligation for the client (caller) and a benefit for the supplier (callee). –The postcondition is a benefit for the client and an obligation for the supplier. –The invariants of all the parents of a class apply to the class itself. –An operation re-declaration (in a derived class) may only replace the original precondition by one equal or weaker, and the original postcondition by one equal or stronger.

CEN 4010 Class /0312 Object Constraint Language (OCL) OCL is a language that allows constraints to be formally specified on single model elements (e.g., attributes, operations, classes) or groups of model elements (e.g., associations and participating classes). See text P. 355 – 364. Note for the project we will write invariants, preconditions and postconditions in OCL.

CEN 4010 Class /0313 OCL cont Example: Context Tournament inv: self.getMaxNumPlayers() > 0 The context keyword indicates the entity to which the expression applies. inv, pre, post correspond to invariant, precondition, and postcondition respectively. Then comes the OCL expression, syntax is similar to OO PLs. Note OCL cannot denote control flow.

CEN 4010 Class /0314 OCL cont Examples: Context Tournament::acceptPlayer(p) pre: !isPlayerAccepted(p) Context Tournament::acceptPlayer(p) post: isPlayerAccepted(p) Context Tournament::acceptPlayer(p) post: getNumPlayers() + denotes the value returned by pre.getNumPlayers() before invoking denotes value before.

CEN 4010 Class /0315 Concepts cont For the project state the invariants, pre and post conditions for the classes you will be implementing using OCL. Note these assertions should be traceable to the use cases. Use “notes” to show constraints in your class diagrams. DO NOT CLUTTER you class diagrams. Use the example in Fig 9.5 as a guide when writing the assertions for your project.

CEN 4010 Class /0316 Object Design: Specifying Interfaces Interface specification activities of object design include: Identifying missing attributes and operations Specifying type signatures and visibility Specifying invariants Specifying preconditions and postconditions

CEN 4010 Class /0317 Overview Specifying Interfaces Identifying missing attributes and operations. –Missing operations can be identified and added to the class diagram during construction of the sequence diagram in Rational Rose. –At this stage the attributes not evident in the analysis or system design should become evident. –All attributes should be private or protected (inheritance). Specifying type signatures and visibility. –All attributes and operations should be assigned a visibility specifier. Note UML uses the Ada/Pascal approach to specify the signatures of operations.

CEN 4010 Class /0318 Overview Specifying Interfaces cont Specifying constraints –Constraints include invariants, pre and post conditions. Specifying exceptions –Exception conditions are usually associated with the violation of preconditions. You should also check the class invariant after any operation that can change its value.

CEN 4010 Class /0319 Exam 2 Review Topics 1.Definitions: software architecture, patterns, component, subsystem, cohesion, coupling, contracts, defensive programming, invariant, precondition, postcondition. 2.System Design : –areas to address during system design – h/w and s/w mapping, data management, access control, control flow, boundary conditions,

CEN 4010 Class /0320 Exam 2 Review Topics 2.System Design cont: –design goals – know dependability criteria and maintenance criteria, –types of patterns: architectural, design, idioms, –be familiar with the following architectural patterns: client/server, three-tier, four-tier, repository, pipe and filter. 3.Object Design: activities –service specification –component selection –restructuring

CEN 4010 Class /0321 Exam 2 Review Topics 3.Object Design: activities cont –optimization –design patterns: should be able to write Java code for the command and singleton patterns. 4.Be familiar with models used in system and object design e.g. class diagrams and sequence diagrams... 5.Know how to apply parts (2) – (5) above to a real example.