M.Sc OODP– Lecture 6

M.Sc OODP– Lecture 6 Eli Katsiri Department of Computer Science and Information Systems Birkbeck College, University of London Email: eli@dcs.bbk.ac.uk Web Page:http://www.dcs.bbk.ac.uk/~eli

First iteration in Elaboration Traditional RUP Modern RUP Use Cases Use Cases Domain model Use Case Interactive Domain model Design Model - CDC Design Model –interactive Design Model - CDC Design Model –interactive Implementation Model Implementation Model

Implementation model • Interaction diagrams and DCDs: input to code generation • The Implementation Model includes: • source code for classes • database schema • XML/HTML pages • etc. • Writing code in an OO programming language (like Java) is not considered part of OOA/D • Most of the creative work took place during OOA/D. Transition to implementation is mostly mechanical • Expect deviations from the design during programming

Code changes and the iterative model Iterative Cycles of Development Requirements Analysis Requirements Analysis Design Design Implementation Implementation Time

Creating class definitions from DCDs • Straightforward mapping of attribute definitions and method signatures. Don’t forget to add constructors. ProductSpec description:Text price:Money itemID:ItemID … SalesLineItem quantity:Integer getSubtotal():Money Described-by 1 * public class SalesLineItem { private int quantity; public SalesLineItem(ProductSpec spec, int qty) { … } public Money getSubtotal() { … } }

Reference attributes • A reference attribute is an attribute that refers to another object, not to a primitive type such as String, Number and so on. ProductSpec description:Text price:Money itemID:ItemID … SalesLineItem quantity:Integer getSubtotal():Money Described-by 1 * productSpec public class SalesLineItem { private int quantity; private ProductSpec productSpec; public SalesLineItem(ProductSpec spec, int qty) { … } public Money getSubtotal() { … } }

Creating methods from interaction dgrms • An interaction diagram shows messages sent in response to a method invocation. These are translated to code in this method. 2:makeLineItem(spec,qty)‏ enterItem(id,qty)‏ :Register :Sale 1:spec:=getSpecification(id)‏ :Product Catalog public void enterItem (ItemID id, int qty)‏ { ProductSpec spec = catalog.getSpecification(id); sale.makeLineItem (spec, qty); }

Collection attributes • Visibility to a group of objects in DCDs is often translated to a collection attribute in the Implementation Model. Sale … … SalesLineItem … … Contains 1..* 1 public class Sale { … private ArrayList lineItems ; … }

Order of class implementation • The order of implementing classes depends on their dependencies. One possible order for the example below is: Sale SalesLineItem Register … … Contains Captures 5 4 3 1 1..* 1 1 1 * Looks-in Described-by 1 1 ProductSpec … … ProductCatalog … … Contains 2 1 1..* 1

Overview of lecture 6 • More types of relationships • Aggregation • Composition • Polymorphism • The GOF patterns • Creational Design Patterns

Aggregation • Aggregation is a type of Association that implies that one objects owns or is responsible for another objects. • Aggregation implies an object being part of or subordinate to another object. • An arrowhead line with a diamond at its base, denotes aggregation. Department Company 1 * 1 Department Aggregator/Aggregate Aggregatee / part

Aggregation vs Association • Association implies acquaintance, i.e. an object merely “knows of” another. • Associated objects are not responsible for each other. • Acquaintance is weaker than aggregation and it suggests much looser coupling between objects.

Composition • Composition is a type of association that represents whole-part relationships and is a form of aggregation. • A composition relationship specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier. 1 * Student Schedule Schedule 1

Polymorphism • Problem: How to handle alternative behaviors based on type? How to create pluggable software components? • Solution: When related alternatives or behaviors vary by type (class), don’t use conditional logic, but assign the same name to methods in different classes. • The different classes usually implement a common interfaceor are related to an implementation hierarchy with a common superclass (this is language-dependent)‏ • Program to an interface, not an implementation!

Polymorphism: example <<interface>> ITaxCalculator getTaxes(Sale):List of TaxLineItems TaxMaster getTaxes(Sale):List of TaxLineItems GoodAsGoldTaxPro getTaxes(Sale):List of TaxLineItems Adding a new tax calculator class with its own polymorphic getTaxes method will have minor impact on the existing design.

Polymorphism example • When related alternatives or behaviors vary by type (class), … assign the same name to services (methods) in different classes. The different classes usually implement a common interface or have a common superclass. • Example: • Consider a bank application with two types of accounts: CheckingAccount and SavingsAccount. • Suppose that you want to evaluate for each account the interest accumulated over a period. • The implementation of evaluating interest is different for each account type. It uses a different set of interest rates.

Polymorphism example (cont.)‏ • Solution 1: Class SavingsAccount with method getSavAccInterest(startDate, endDate), and class CheckingAccount with method getChAccInterest(startDate, endDate). • First go through objects of class SavingsAccount and invoke their method getSavAccInterest(…)‏ • Then go through objects of class CheckingAccount and invoke their method getChAccInterest(…)‏ • Solution 2: Same as Solution 1, but SavingsAccount and CheckingAccount have the same superclass Account. • Go through all objects of class Account. If an object is of subclass SavingsAccount, invoke getSavAccInterest(…), else invoke getChAccInterest(…)‏

Polymorphism example (cont.)‏ • Solution 3: Class SavingsAccount with method getInterest(startDate, endDate), and class CheckingAccount with method getInterest(startDate, endDate) inherit from a common superclass with method getInterest(startDate, endDate). • Go through all objects of class Account. Invoke their method getInterest(…)‏ • What are the advantages of solution 3 over the previous two solutions? • In terms of code … • In terms of maintenance …

Overview of lecture 6 • More types of relationships • Aggregation • Composition • Polymorphism • Design Patterns • Creational Design Patterns

Bridges • A bridge is a structure which is used for traversing a chasm. • In its basic form it consists of a beam constructed from a rigid material. • The two ends of the beam are fixed at opposite edges of the chasm

Rigidity • The bridge will fulfil its function if the rigidity of the beam can support the loads that go over it. • Heavier loads may tax the rigidity of the bridge. • The rigidity depends on both the length and the material that the beam is made of.

Modifying the design If the bridge might fail: • heaviness of the load • size of span • material of construction Then modify bridge design • increase the rigidity • decrease the span

Increase the rigidity/decrease span

Civil engineering design patterns • These are ALL the design patterns of bridge design. • Civil engineers only build bridges following one of the designs shown. • The idea of design patterns comes from architects who also follow a fixed number of designs. • Why should software design be different from design in other engineering disciplines?

What is a pattern? • “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice.” • A pattern in CE guarantees a safe solution. • In SE we are not creating physical objects (like a bridge). So what is the analogy for safety?

Design Principles • Modularity • GRASP patterns • Flexibility • Separation of concerns (Impact of change) • Reusability • Inheritance • Composition • Delegation • Correctness • Robustness • Formal verification

Flexibility • Flexible design implies a design that can easily accommodate changes • Aspects of flexibility: • Adding more of the same kind of functionality Example : handle more kinds of graphical views without having to change the existing design or code. • Adding different functionality Example: add controllers to provide additional ways for the user to interact with existing functionality, e.g. add pop-up windows along with command line interface. • Changing functionality Example: Substitute command line commands with pop-up windows.

Example: Model-View-Controller (MVC) Model-View-Controller group of classes used to build interfaces (originally in Smalltalk, Java Swing, EPOC uses MVC). • Model - application object, • View - presentation on screen, • Controller - how user input controls the interface

MVC • Model must notify views of change. • Views must keep themselves up to date. • Several controllers e.g. command keys, pop-up menus can be used. Usually controllers organised in a class hierarchy -> sub-classing

Two views of the data

MVC Advantages • MVC decouples the model management (data) from the representation (views) and the reaction to user input (controllers). Increased flexibility. • Allows to have multiple (synchronized views) on the same data. • Allows to associate different controllers with each of the views if needed. Change the way in which the interface reacts without changing the interface. • Views can be easily composed.

Example: e-Shop (CDs) • Web Appication Development Nomenclature • Servlet • Browser • Java Bean • http request • JSP

View All datastructures in “View” are held within a “Session” object.

Controller • Every time the user adds an item within EShop.jsp, the request (httpServletRequest) is posted to the controller servlet. The servlet in turn determines the appropriate action, and then processes the request parameters for the item to be added. It then instantiates a new CD bean representing the selection, and goes about updating the shopping cart object before placing it back within the session.

Controller -> View • The controller servlet also processes actions triggered from within Cart.jsp, such as the user deleting items from the shopping cart, or proceeding to the checkout counter. Observe that the controller always has complete control over which resources should be invoked in response to specific actions. For example, changes made to the state of the shopping cart, such as additions or deletions, cause the controller servlet to forward the request after processing to the Eshop.jsp page. This in turn causes the page to redisplay the main view, along with the updated contents of the shopping cart. If the user decides to check out, the request is forwarded after processing to the Checkout.jsp page

checkout.jsp (View) checkout.jsp simply extracts the shopping cart from the session and the total Amount for the request and then displays the selected items and the total cost.

Reusability • Class/Interface inheritance • Object composition/Delegation • Parameterised types/generics

Nomenclature • Abstract class: is one whose main purpose is to define a common interface for its subclasses. An abstract class will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but does not implement are called abstract operations. • Concrete class: Classes that are not abstract are concrete.

Nomenclature • Every operation defined by an object specifies the operation’s name, the objects it takes as parameters and the operation’s return value. This is known as the operation’s signature. • The set of all signatures defined by an object’s operations is called the interface to the object. An object’s interface characterises the complete set of requests that can be sent to the object. Any request that matches a signature in the object’s interface may be sent to the object.

types • A type is a name used to denote a particular interface. An object has the type “Window” if it accepts all requests for the operations defined in interface named “Window” • We say a type is a subtypeof another, if its interface contains the interface of its supertype. We say that an interface inherits the interface of its supertype.

Inheritance • Class inheritance lets you define the implementation of one class in terms of another. It is a mechanism for code and representation sharing. Re-use by subclassing is often referred to as white-box re-use. White-box refers to visibility. The internals of parent classes are often visible to subclasses. • Interface inheritance (or subtyping) describes when an object can be used in place of another (objects share a template, in terms of the set of requests which the can respond).

Polymorphism • All classes derived from an abstract class will share its interface. This implies that a subclass merely adds or overrides operations and does not hide operations from the parent class. • Clients remain unaware of the specific types of objects they use, as long as these types adhere to the interface that the clients expect.

Programming to an interface • Programming to an interface, not to an implementation! • Don’t declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. • You have to instantiate concrete classes (specify an implementation) at some point in your system, and the creational patterns let you do just that.

Creational patterns • By abstracting the process of object creation, these patterns give you different ways to associate an interface with its implementation transparently at instantiation.

Class inheritance • Class inheritance is defined statically at compile-time. It makes it easier to modify the implementation being re-used. • BUT..Inheritance breaks encapsulation. The implementation of a subclass becomes so bound up with the implementation of the parent class that any change in the parent implementation will force the subclass to change.

Object composition • Object composition is an alternative to class inheritance. New functionality is obtained by assembling or composing objects to get more complex functionality. The objects composed have well-defined interfaces. This style of re-use is called black-box re-use because no internal details are visible. • Composition is defined dynamically at run-time through objects acquiring references to other objects. Objects need to respect each other’s interfaces.

Delegation • It is a way of making composition as powerful for re-use as inheritance. Two objects are involved in handling a request: a receiving object delegates operations to its delegate. This is analogous to subclasses deferring requests to superclasses.

Parameterized types • Parameterized types or generics let you define a type without specifying all the other types it uses. The unspecified types are suppplied as parameters at the point of use. For example a List class can be parameterised by the type of elements it contains. To declare a list of integers, you supply the type “integer” as a parameter to the List parameterised type. The language of implementation will create a customised version of the List class template for each type of element.

Nomenclature (OOP) • Making something “abstract” (english) or “generic” (english) does not mean creating an abstract class (OO ) or interface (OO) and certainly not a parameterised type (OO). It means to “hide” some detail that was there before, even if the class remain concrete (OO).

Classification (GOF) • Creational Patterns • Abstract object instantiation • Structural Patterns • Compose and organise objects into larger structures • Behavioural Patterns • Algorithms, interactions and control flow between objects.

M.Sc OODP– Lecture 6