powerpoint presentation for dennis, wixom & tegarden systems analysis and design copyright 2001...

PowerPoint Presentation for Dennis, Wixom & Tegarden Systems Analysis and Design

Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.Slide 1

Systems Analysis and Systems Analysis and DesignDesign

Alan Dennis, Barbara Wixom, and David Tegarden

John Wiley & Sons, Inc.

Slides by Fred Niederman



Copyright © 2001 John Wiley & Sons, Inc.

All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express written permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for redistribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein.



Class and Method Design

Chapter 14



Key Concepts

Low-level or detailed design is critical despite libraries and componentsPre-existing classes need to be understood and organizedSome, if not all code, is generally still needed to instantiate new classes



Identify Opportunities for Reuse

PatternsUseful group of collaborating classes the provide a solution to a commonly occurring problem

FrameworkClasses used for application implementation

Class librariesSet of implemented classes designed for reuse

ComponentsSelf-contained encapsulated pieces of code that provide a certain functionality



REVISITING THE BASIC CHARACTERISTICS OF OBJECT-ORIENTATION



ElementsClassesObjects – instance of a classAttributes – describes dataStates – describes object at specific point in time via an attributeMethods – processes to be performedMessages – used to get an object to perform a method



Encapsulation

Hiding the content of the object from outside viewCommunication only through object’s methods (via messages)Key to reusability



Example Unencapsulated

Desired Temp

Actual Temp

Occupancy

Heat FlowRegulator

temp ()

temp ()

occupied()



Example Encapsulated

Heat FlowRegulator

Room

Desired_TempActual_TempOccupancy

Monitor_Temp

need_heat()

Room contains the knowledge of when it needs heat



Polymorphism

Same message triggers different methods in different objectsDynamic binding means specific method is selected at run timeImplementation of dynamic binding is language specific



What does it mean?

polymorphism refers to a programming language's ability to process objects differently depending on their data type or classit is the ability to redefine methods for derived classes



Example

Given a base class shape, polymorphism enables the programmer to define different circumference methods for any number of derived classes, such as circles, rectangles and triangles. No matter what shape an object is, applying the circumference method to it will return the correct results



More examples

Good exampleSend message ‘print document’ to laser printer or inkjet printerThe printer performs its own print operation

Bad exampleSend message ‘create order’Start the sales process or straighten up the living room?



Polymorphism Challenges

Need to be very careful about run time errors

Send message to an object that doesn’t understand itMake a decision for which there is no code

Need to ensure semantic consistencySame name for a method in 2 classes – does it mean the same thing?



Inheritance

Single inheritance -- one parent classMultiple inheritance -- multiple parent classesRedefinition and inheritance conflict

Attribute/method with same name

Most inheritance conflicts are due to poor classification



Additional Inheritance Conflicts

Two inherited attributes or methods have same name and semanticsTwo inherited attributes or methods have different name, but same semanticsTwo inherited attributes or methods have same name and different semantics



DESIGN CRITERIA



Good Design – Bad Design

Good design balances trade-offs to minimize total cost of a system over its lifetime (Coad and Yourdon)Criteria for assessing good design:

CouplingCohesionConnascence



Coupling

Interdependency among modules

More interdependency the more likely changes in one part will require changes in others



Two Types of Coupling

Interaction coupling through message passing

Minimize number of objects that can receive messages

Inheritance coupling of superclass and sub classes

Tighter coupling is preferred – supports a-kind-of



Law of Demeter – Interaction Coupling

Messages should be sent only by an object

to itself

to an object contained in an attribute of itself or a superclass

to an object that is passed as a parameter to the method

to an object that is created by the method

to an object that is stored in a global variable



Types of Interactive Coupling

Level Type

Good No Direct Coupling – no callsData – passes variable uses allStamp – passes object uses someControl – passes control variableCommon or Global – outside object

Bad Content or Pathological – method of one object refers to inside method of another (often illegal)



Good Interaction Coupling

Pass value of a variable along with the message

Object invoice could send to calculate tax the taxable amount



Bad Coupling

Global data area exists outside the object

Table of user preferences – global dataCan be changed by a number of objectsIe values might be changed between the end of one ‘run’ and the beginning of the next ‘run’



Bad Coupling continued

Sales tax percent stored in separate tableCalculate sales tax at 6% for one itemAnother object changes Sales tax percentNext items is calculated with 7% sales tax



Cohesion

“Single-mindedness of a module”Object should just represent one thing – a method should solve only one task

Types of cohesion:Method cohesionClass cohesionGeneralization/specialization cohesion



Types of Method CohesionLevel Type

Good Functional –single functionSequential –2 functions – output from

one is input to other Communicational – 2 functions that use

the same attributesProcedural – multiple functionsTemporal or Classical – multiple related

functions in timeLogical – multiple functions with choice

by control variableBad Coincidental – purpose not well defined



Method Cohesion Example

Good Method CohesionObject ‘calculate totals’ by keeping a running total

Bad Method CohesionUnrelated activities in the same method

Method that updates customer records, calculates loan payments,prints exception reports…



Types of Class Cohesion

Level Type

Good Ideal

Mixed-role

Mixed-domain

Worse Mixed-instance



Class Cohesion

IdealMethods and attributes all relate to the same entity (employee, student, etc.)

Mixed-RoleOne or more attributes relate to other objects on same layer

Student class contains instance of courses student is taking



Class Cohesion

Mixed-domainOne or more attributes relating to objects on a different layer

Data layer refers to objects on presentation layer

Mixed-instanceClass represents 2 different types of objects

Student and class enrollment (should be 2 separate classes)



Connascence

Generalizes the ideas of cohesion and coupling

Two modules (classes or methods) so intertwined that a change in one will likely require a change in the other



Types of Connascence

Type

Name

Type or Class

Convention

Algorithm

Position



Name Connascence

Refers to the situation where a method references an attribute“get product number” refers to attribute in ‘product’ classIf ‘product class’ changes the attribute name, the method must change



Type or Class Connascence

Refers to relationship between attribute and data typeFor instance, if date is chosen as the data type and that is changed, class must be changed



Convention Connascence

Values of attributes are assigned semantic meaning

Ie used as a code

Should the range of acceptable values of attribute change, methods must also be changed



Position Connascence

Refers to the order of code in the method or the order of arguments

Record must be found before being modified

Subtle differences can ariseCreating averages from subtotals versus the entire data set



Algorithm Connascence

Refers to dependency on an algorithmIf algorithm changes, methods must change

Change a hashing algorithm for finding recordsInsert record and find record must be changed



Class Constraints

A set of constraints and guaranteesWritten in natural language, structured English, pseudocode, or formal language – can be modeled in UML with OCL (Object Constraint Language)



Define constraints

Pre-conditionsMust be met for method to execute (ie invalid attributes)

Post conditionsMust be met after the method is executed (no invalid attributes)

InvariantsMust be true for all instances of a class (valid values of an attribute)



Constraints - TomorrowPreconditions

Valid value for today’s date

InvariantsDay, month, year positive numbersMonth must be between 1 and 12Day must be between 1 and 31Leap year anomalies must be correct

PostconditionsValid date for tomorrow



Constraint OCL Example

Date :: Tomorrow() pre: year < 9999 or (year = 9999 and month < 12) or (year = 9999 and month = 12 and day <31) post: if day@pre < 31 then day = day@pre + 1 else if month@pre < 12 then month = month@pre + 1 day = 1 else year = year@pre + 1 month = 1 day = 1 end if end if



Contract

Documents message passes that takes place between objectsCan be written for:

Each message sentEach message received



Contract Continued

DeclarativeSo programmer understands what the method is to do

Not proceduralDon’t spell out how the method is to work



Simple Contract Format

Method Name: Class Name: ID:

Clients (Consumers):

Associated Use Cases:

Description of Responsibilities:

Arguments Received:

Type of Value Returned:

Pre-Conditions:

Post-Conditions:



What to Remember

Class EncapsulationPolymorphismInheritance

CouplingCohesionConnascenceWhat is a good candidate for reuse

powerpoint presentation for dennis, wixom & tegarden systems analysis and design copyright 2001...

Documents

design copyright

powerpoint presentation

reusability slide

orientation slide

david tegarden john

design alan dennis

fred niederman slide

certain functionality