CISC 323 By last name (regardless of section): Last Name Room - - PowerPoint PPT Presentation

cisc 323
SMART_READER_LITE
LIVE PREVIEW

CISC 323 By last name (regardless of section): Last Name Room - - PowerPoint PPT Presentation

Midterm Reminder The midterm is next Tuesday: March 2, 7-9 p.m. Location : Stirling Hall rooms A, B and C CISC 323 By last name (regardless of section): Last Name Room


slide-1
SLIDE 1

CISC 323, Winter 2004, OOD 1

Midterm Reminder

The midterm is next Tuesday: March 2, 7-9 p.m. Location: Stirling Hall rooms A, B and C By last name (regardless of section): Last Name Room

A-G Stirling A H-M Stirling B N-Z Stirling C

Material:

  • all material up through (and including) Friday.
  • readings for all topics on web site.

Monday: review, Q&A

CISC 323 Introduction to Software Engineering

Topic 5: Object-Oriented Design (OOD), Chapter 9

CISC 323, Winter 2004, OOD 3

From OOA To OOD

Remember main points of our high-level process:

  • 1. Analyze and model application domain and its requirements

(OOA)

  • 2. Transform this model into design of implementation (OOD)
  • 3. Then implement it in Java/C++/… (OOP)
  • 4. Iterate and refine all the time

Smooth flow from analysis to design to implementation may…

help correctness

reduce development time

ensure requirements are satisfied/addressed in implementation

CISC 323, Winter 2004, OOD 4

Subtopics

5.1: The object-oriented design process in the UA

5.2: Attributes of good designs

coupling, cohesion, information hiding

readability, modifiability, etc

5.3: Use attributes to guide design and implementation

2 examples

slide-2
SLIDE 2

CISC 323, Winter 2004, OOD 5

5.1: Object-Oriented Design Process in the Unified Approach

Continuous testing

OO Design

Check quality attributes Design classes, methods, attributes, and associations Refine UML class diagrams User satisfaction and usability test based on use cases Design view/access layers and prototype

CISC 323, Winter 2004, OOD 6

OO Design Process

  • 1. Use quality attributes to guide

design of classes, their attributes, methods, associations, and protocols 1.1. Refine and complete static UML class diagram (object model) by adding details to UML class diagram by:

1.1.1. Refine attributes 1.1.2. Design methods and protocols by utilizing a UML activity diagram to represent method's algorithm 1.1.3. Refine associations between classes 1.1.4. Refine class hierarchy and design with inheritance

1.2. Iterate and refine again

Check Quality Attributes Design classes, methods, attributes, and associations Refine UML class diagrams

CISC 323, Winter 2004, OOD 7

OO Design Process (Cont’d)

  • 2. Design the access layer

2.1. Create mirror classes: For every business class identified and created, create one access class 2.2. Define relationships among access layer classes 2.3. Simplify class relationships: Main goal is to eliminate redundant classes & structures

2.3.1. Redundant classes: Do not keep 2 classes that perform similar translate activities 2.3.2. Method classes: Revisit classes that consist of only

  • ne or two methods to see if they can be eliminated or

combined with existing classes

2.4. Iterate and refine again

Design view/access layers and prototype

CISC 323, Winter 2004, OOD 8

OO Design Process (Cont’d)

  • 3. Design the view layer classes

3.1. Design macro level user interface by identifying view layer objects 3.2. Design micro level user interface, which includes these activities:

3.2.1. Design the view layer objects by using quality attributes 3.2.2. Build a prototype of the view layer interface

3.3. Test usability and user satisfaction 3.4. Iterate and refine

  • 4. Iterate and refine preceding steps. Reapply design

axioms and, if needed, repeat preceding steps

User satisfaction and usability test based on use cases Design view/access layers and prototype

slide-3
SLIDE 3

CISC 323, Winter 2004, OOD 9

5.2: Attributes Of Good Software Design

1) Realization of requirements: Will code meet requirements?

Performance:

Execution time: Does code provide sufficiently fast response time? Throughput? …

Resource use: Does executing program fit within available memory? Disk space? Network latency, bandwidth?

Fault-tolerance: How robust to faults will the system be?

Usability: How easy will it be to use the system?

Implementation Resources: Can design be implemented within available resources?

CISC 323, Winter 2004, OOD 10

Attributes Of Good Software Design (Cont’d)

2) Readability: How easy is to

understand the design?

see where particular functionality is realized?

locate the source of a problem?

3) Modifiability: For a given change, how easy is it for a programmer to

work out where changes have to be made?

what changes have to be made?

enact these changes?

How much of the system is impacted?

CISC 323, Winter 2004, OOD 11

Attributes Of Good Software Design (Cont’d)

4) Reusability: How easy is it to reuse (parts of) the system in other contexts and for other purposes?

Is code sufficiently general to support reuse in many contexts w/o change?

Does copied code make any implicit assumptions (e.g., about input data) that old context happens to meet but not the new one?

5) Maintainability: How easy is it to perform maintenance tasks on the system?

CISC 323, Winter 2004, OOD 12

Attributes Of Good Software Design (Cont’d)

Criteria may be conflicting. Design may involve tradeoffs (e.g., reusability versus implementation time)

In order to meet certain requirements, one criterion may have to take precedence over another

Examples:

Commercial document preparation software

need: high modifiability, high reuse

don’t need: high performance

Missile control system

need: high performance, high correctness/reliability

don’t need: high reuse, high modifiability

slide-4
SLIDE 4

CISC 323, Winter 2004, OOD 13

More Fundamental Attributes Of Good Software Design

Other, more fundamental criteria exist

  • 1. Coupling
  • 2. Cohesion
  • 3. Information Hiding

CISC 323, Winter 2004, OOD 14

Fundamental Attribute 1: Coupling

Measure of how connected components are, that is, roughly,

coupling of component C = #components on which C depends

“System S has high/strong coupling”:

On average, components in S depend on many other components

“System S has low/loose coupling”:

On average, components in S depend on few other components

CISC 323, Winter 2004, OOD 15

Example Of System With High Coupling

CISC 323, Winter 2004, OOD 16

Example Of System With Low Coupling

slide-5
SLIDE 5

CISC 323, Winter 2004, OOD 17

Coupling: The Bottom Line

Systems with low coupling tend to have

high readability

To understand a component, may have to understand interfaces of all components on which component depends

high modifiability

Modification to interface of one component may impact all components which depend on modified interface

and therefore also high maintainability and reusability

Systems with high coupling are more likely to have low readibility and modifiability, and thus also low maintainability and reusability

CISC 323, Winter 2004, OOD 18

Fundamental Attribute 2: Cohesion

Measure of how clear or unique the purpose of a component is

“System S has high cohesion”:

On average, a component in S serves a single, clearly defined purpose

“System S has low cohesion”:

On average, a component in S serves several, only weakly related purposes

Example: A method doA() is more cohesive than a method doAandBandPossiblyC()

CISC 323, Winter 2004, OOD 19

Example Of High Cohesion

CISC 323, Winter 2004, OOD 20

Example Of High Cohesion (Cont’d)

Purpose of Marks Client User Interface:

Implement user interface allowing students to specify course for which they want marks, then retrieve these marks

Display information to students

Purposes of Marks Client:

Connect over network to Marks Server, obtain marks information for specific student, course

slide-6
SLIDE 6

CISC 323, Winter 2004, OOD 21

Example For Low Cohesion

Two-layered architecture for payroll system:

Data Workstation

Owner Name Title Address

  • Layer 1: for user interaction, computation, and translation
  • Layer 2: for storage

CISC 323, Winter 2004, OOD 22

Cohesion: The Bottom Line

Systems with high cohesion are more likely to

have high readability

components are easier to understand

have high modifiability

[Selby and Basili, 1991]: Routines with high cohesion can be 20 times less costly to fix than routines with low cohesion

have high reliability

[Card, Church, Agresti, 1986]: Routines with high cohesion are more than twice as likely to be fault-free

CISC 323, Winter 2004, OOD 23

Fundamental Attribute 3: Information Hiding

Component makes code that, e.g.,

embodies low-level implementation-oriented design decisions

uses very complex data or logic

is likely to change

invisible and inaccessible to the outside

CISC 323, Winter 2004, OOD 24

Information Hiding: The Bottom Line

Systems with good information hiding are more likely to

have high readability

because independencies are revealed

have low coupling

because the more information a components hides, the less information can other components access and depend upon

have high modifiability

[Korson and Vaishnavi, 1986]: Programs with information hiding are up to 4 times easier to modify than programs that don’t

because changes less likely to break other code and propagate

have high reliability

because changes to code with high modifiability are more likely to result in a correctly working system, than changes to code with low modifiability

slide-7
SLIDE 7

CISC 323, Winter 2004, OOD 25

Overview of Quality Attributes

low coupling high cohesion information hiding reusability modifiability maintainability readability reliability primary, fundamental secondary, derived

CISC 323, Winter 2004, OOD 26

Fundamental Problems in Design

Typical questions:

How to split system into components?

How many?

What’s the purpose of each component?

How to define interfaces to these components?

Which services should the component provide to others?

How should the component be interacted with?

How do design design decisions impact my requirements?

Bad news:

Usually, no single right answer

May have to guess and later undo or refine

Good news:

Can use knowledge of fundamental quality attributes as “rules of thumb”

CISC 323, Winter 2004, OOD 27

Example 1: Use Quality Attributes to Guide Interface Design in Java

Interfaces should

  • 1. be cohesive (clearly defined purpose)
  • 2. use information hiding (as appropriate)
  • 3. be readable/understandable

clear method and variable names

clear, intuitive protocols

  • 4. support reuse
  • 5. allow for an implementation that is

loosely coupled

efficient

implementable within available resources

Operations:

numElements - returns number of elements in list

inList - determines whether given course is in list

remove - removes element at index n in list (index 0 is first element)

isEmpty - tests whether list is empty

get - returns course at index n (0≤n<numElements)

first - returns first course in list

rest - returns new list with all elements following the first one

add - adds given course into list

toString - returns a string representation of contents of list

Course List Example

slide-8
SLIDE 8

CISC 323, Winter 2004, OOD 29

How Well-Designed is the CourseList Interface?

Interfaces should

  • 1. be cohesive

?

CISC 323, Winter 2004, OOD 30

How Well-Designed is the CourseList Interface?

Interfaces should

  • 1. be cohesive

Every variable and method serves a single, clearly defined purpose

CISC 323, Winter 2004, OOD 31

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 2. use information hiding (as appropriate)

?

CISC 323, Winter 2004, OOD 32

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 2. use information hiding (as appropriate)

Interface does not reveal the underlying implementation

✭ ✬

Allows different implementations and allows the implementation to be changed without impacting code that uses the interface

slide-9
SLIDE 9

CISC 323, Winter 2004, OOD 33

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 3. be readable/understandable

?

CISC 323, Winter 2004, OOD 34

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 3. be readable/understandable

Descriptive variable and method names

✯ ✮

Clear variable and method descriptions

✯ ✮

There are multiple ways of doing the same thing, e.g., can iterate through the list via get or via

first/rest

CISC 323, Winter 2004, OOD 35

How Well-Designed is the CourseList Interface? (Cont’d)

possible source of confusion

✱ ✲

possible waste of implementation effort

✱ ✲

possible source of flexibility needed for reuse

CISC 323, Winter 2004, OOD 36

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 4. support reuse

?

slide-10
SLIDE 10

CISC 323, Winter 2004, OOD 37

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 4. support reuse

Offers some flexibility which may be good for reuse

✵ ✴

Appears to be extensible to new contexts that require the linear storage of Course objects

✵ ✴

However, cannot be adapted to contexts that require linear storage for objects other than Course objects

✶ ✷

Option 1: Change list to hold Objects

very general (list can hold objects of any type; even at the same time)

✹ ✺ ✻

lots of type casts necessary when retrieving elements

✺ ✼

Option 2: Generics (Java 1.5)

type variables <T>

specify element type when container is created: new List<int>

class List<T> { List<T> add(T e); <T> first(); . . . }

CISC 323, Winter 2004, OOD 38

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 5. allow for an implementation that is

loosely coupled

efficient

implementable within available resources

?

CISC 323, Winter 2004, OOD 39

How Well-Designed is the CourseList Interface? (Cont’d)

Interfaces should

  • 5. allow for an implementation that is

loosely coupled

Clearly seems possible to develop an implementation that depends very little on other components

efficient

Easy to make a subset of the operations efficient:

array implementation makes get efficient

linked list implementation makes first/rest efficient

Hard to make them all efficient. Given implementation needs to be clear which operations are efficient, which are slow

implementable within available resources

Generality of interface increases implementation time

Implementation time depends on required performance. The fewer

  • perations need to be efficient, the shorter the implementation will be

CISC 323, Winter 2004, OOD 40

Example 2: Use Quality Attributes to Guide Design and Implementation of a Class in Java

Many applications require time to be represented. For example:

calendar application needs to represent the times of appointments

ATM needs to keep track of when transactions happened

Times might be represented in many different ways. E.g.,

A 24-hour format string (“10:00”, “22:49”)

A 12-hour format string (“10:00 AM”, “10:49 PM”)

Two integers for hours/minutes + Boolean flag for AM/PM

(<10, 0, false>, <10, 49, true>)

Integer representing number of minutes since midnight

(600, 1369)

slide-11
SLIDE 11

CISC 323, Winter 2004, OOD 41

Operations on Time Values

Many operations are possible

Convert time into format suitable for printing/viewing

convert time to string representation in 12 hour clock

convert time to string representation in 24 hour clock

Add minutes to time/subtract minutes from time

e.g., moving an appointment to 60 minutes later

Subtract two times

e.g., calculating how long an appointment is by subtracting start time from end time

Comparing times

Etc.

CISC 323, Winter 2004, OOD 42

To Implement Component We Need To…

… determine its interface:

Which operations should be supported? What should they be called?

Which arguments do they take, which values do they return?

… implement the interface:

Determine internal representation for time values

What is the class/representation invariant?

How does representation impact efficiency? Common tradeoff: Space versus time

Implement the operations. For each operation m:

How does m change the internal representation and how can the return value of m be obtained from the current internal representation?

How can this be expressed in code? Which helper methods are needed?

Do the arguments need to be checked?

CISC 323, Winter 2004, OOD 43

Component As Component Diagram in UML

Component’s interface

  • public
  • tells clients (i.e., users of the

component) how

  • time values are created
  • read
  • updated
  • compared
  • printed
  • etc
  • clients only use data and

methods in the interface

low coupling, modifiability

private int time; private static int MINUTES_PER_HOUR = 60; private static int HOURS_PER_DAY = 24; private stringToInt(String s) {…} public setTime(Sting s) {…} … setTime toString addTime addTimes

CISC 323, Winter 2004, OOD 44

Component As Component Diagram in UML (Cont’d)

Component’s implementation

  • private
  • defines internal

representation

  • provides implementations
  • f methods in the interface

in terms of internal representation

  • may (need to) be replaced

later

private int time; private static int MINUTES_PER_HOUR = 60; private static int HOURS_PER_DAY = 24; private stringToInt(String s) {…} public setTime(Sting s) {…} … setTime toString addTime addTimes

slide-12
SLIDE 12

CISC 323, Winter 2004, OOD 45

Interface name (TimeVal)

Component As Class Diagram in UML

Class name (TimeValImpl) Realization relation specifies that class TimeValImpl implements interface TimeVal Internal representation based

  • n a single integer (time)

Operations implemented by TimeValImpl (superset of

  • perations in TimeVal interface)

Operations in interface

CISC 323, Winter 2004, OOD 46

How Does Java Support Good Design?

interface

  • to define interface

class

  • to define implementation

implements

  • to link interface with

implementation

  • compiler checks for omissions

etc

public, protected, private

  • to implement information hiding

// This method assumes that // x is not null

for commenting

assert(x != null);

to check invariants at run-time

class CISC323 extends Course

to specialize existing classes

❏ ▲

reuse

import javax.swing.*

to import packages and classes from Java API

◆ ▲

reuse

CISC 323, Winter 2004, OOD 47

interface TimeVal { // Sets the time (24 hr string format) public void setTime (String t); // Returns the time in 24 hr string format public String toString (); // Adds numberOfMinutes to the time public void addTime (int numberOfMinutes); }

Component In Java

CISC 323, Winter 2004, OOD 48

class TimeValImpl implements TimeVal { private int time; private static int MINS_PER_HOUR = 60; private static int HRS_PER_DAY = 24; private int stringToInt (String s) { ... } public void setTime (String t) { ... } public String toString () { ... } public void addTime (int numberOfMinutes) { ... } .. . }

Private data and

  • perations used in

implementation – not visible outside class Implementations of public operations, as specified in interface

Component In Java (Cont’d)

slide-13
SLIDE 13

CISC 323, Winter 2004, OOD 49

class TimeValImpl implements TimeVal { // Represents time as the number of minutes since // midnight. Therefore ranges from 0 (12:00 AM) // to 1439 (11:59 PM) private int time; private static int MINS_PER_HOUR = 60; private static int HRS_PER_DAY = 24; // Converts a string representation of an integer // into an integer. This method is private - not // visible outside this class. private int stringToInt (String s) { int i=0; try { i = Integer.parseInt (s); } catch (NumberFormatException e) { System.err.println ("String not an integer"); System.exit (1); } return i; } ... }

Defined in java.lang.Integer Check API documentation

Component In Java (Cont’d)

exception handling

define all constants at beginning

readability, modifiability

CISC 323, Winter 2004, OOD 50

class TimeValImpl implements TimeVal { ... public void setTime (String t) { // Find in the string where the ":" character appears int sep = t.indexOf (':'); if (sep == -1) { System.err.println ("Attempt to set time to " + t); System.exit (1); } // Extract the part of the string for the hours and the // part for the minutes int hours = stringToInt (t.substring (0, sep)); int minutes = stringToInt (t.substring (sep+1)); // Check for errors if (hours < 0 || hours > 23 || minutes < 0 || minutes > 59) { System.err.println (t + " is an illegal time"); System.exit (1); } // Set the time in minutes since midnight time = hours*MINS_PER_HOUR + minutes; } ... }

Component In Java (Cont’d)

CISC 323, Winter 2004, OOD 51

class TimeValImpl implements TimeVal { ... public String toString () { // Converts the integer representation of the time to // string form. String hour = Integer.toString (time / MINS_PER_HOUR); String minute = Integer.toString (time % MINS_PER_HOUR); if (minute.length() == 1) { minute = "0" + minute; } return hour + ":" + minute; } public void addTime (int numberOfMinutes) { if (numberOfMinutes < 0) { System.err.println ("Parameter to addTime must be positive"); System.exit (1); } time += numberOfMinutes; // Wrap around if we've gone past midnight time = time % (HRS_PER_DAY * MINS_PER_HOUR); } }

Component In Java (Cont’d)

CISC 323, Winter 2004, OOD 52

class Client { // Create a time, add time, and print its value TimeVal t = new TimeValImpl(); t.setTime ("3:00"); t.addTime (70); // Correct output is 4:10 System.out.println ("Time = " + t); } // class Client

Using the Component

:Client t:TimeValImpl

print addTime setTime create

slide-14
SLIDE 14

CISC 323, Winter 2004, OOD 53

Why?

Using the Component (Cont’d)

:Client t:TimeValImpl

print addTime create

However, the following may be problematic:

CISC 323, Winter 2004, OOD 54

  • Because implementation does not provide an explicit

initialization and may assume that time is always set right after creation

  • Could either revise implementation, or add comment to

interface

  • In Java, uninitialized variables are either flagged by

compiler or set to 0 (so, we might be ok in this example)

Using the Component (Cont’d)

:Client t:TimeValImpl

print addTime create

However, the following may be problematic:

CISC 323, Winter 2004, OOD 55

Alternative Implementations

CISC 323, Winter 2004, OOD 56

Changing the Client

class Client { // Create a time, add time, and print its value TimeVal t = new TimeValImpl(); t.setTime ("3:00"); t.addTime (70); // Correct output is 4:10 System.out.println ("Time = " + t); } // class Client

P

All we need to do is use a different constructor:

TimeValOtherImpl();

P

That’s it! All code using t remains the same!

P

How can this be? t points to a different object now!

P

Interfaces and information hiding give you modifiability!!!

slide-15
SLIDE 15

CISC 323, Winter 2004, OOD 57

Summary OOD

In UA:

design classes, methods, attributes, associations

check quality attributes

design layered architecture

test

Quality attributes

realization of requirements, readability, modifiability, reusability, maintainability, …

cohesion, coupling, information hiding

Quality attributes can be used to

evaluate existing designs and implementations

guide the development of new designs and implementations

Java supports good design in a number of ways