requirements analysis 9. 1 oo concepts - 2005b509.ppt © copyright de montfort university 2000 all...

Requirements Analysis 9. 1 OO Concepts - 2005b509.ppt

© Copyright De Montfort University 2000All Rights Reserved

INFO2005Requirements Analysis

Object Oriented Concepts

Department of Information Systems



Learning Objectives

Why OO? Classes & Objects Review the UML notation Some important concepts in

OO



Why OO?

Easier maintenance & extensibility of software

Supports reuse of existing software Handles complexity well Natural modelling (i.e.

descriptions) of problem domain Requirements traceability



ObjectsAn object is “a concept, abstraction or thing with

crisp boundaries and meaning for the problem at hand.” Rumbaugh et al., 1991

An object reflects “the capabilities of a system to keep information [or] to interact”

Coad and Yourdon, 1991

An object has “state, behaviour and identity” Booch, 1993

An object “represents a particular instance of a class. It has identity and attribute values” UML Spec V1.1



Object State Static and dynamic attributes State is reflected by attribute values A car object….

make model mileage dateRegistered dateTaxed dateTested

may have states:



Object Behaviour

We associate valid behaviour (operations) with each object

For the car object– register– tax– changeColour?

Each valid operation is invoked by a request from another object



Object Identity

Object identity is intrinsic, not necessarily reflected by attribute values

Referenced by an object-id Cars have different registrations

but the registration is not the object id



Classes

Class describes “a group of objects with

– Rumbaugh et al., 1991

Class is “a descriptor for a set of objects with similar structure & behaviour”

UML V1.1



Classification Grouping objects with the same

behaviour and data. Modifying or Extending the object

Example



Class

Window

Window{abstract,author=Ray,status=tested}

+size:Area = (50,50)

#visibility:Boolean=invisible

+default-size:Rectange

#maximum-size:Rectangle-xptr:XWindow*

+display()

+create()

-attachXWindow(xwin:XWindow*)

Window

size:Area

visibility:Boolean

display()

ImplementationDetail

Suppressed

Analysis Level



Message Passing

Objects collaborate to achieve the functional requirements

Objects communicate by passing messages– request– calls– may include parameters – some messages have



Message Passing

Borrower

addressnamestatus

Book

statustitleborrow



Encapsulation

The representationof an object’s datais hidden inside.

An object’s data can only beaccessed by its own operations.

An object’s operations can only be called by amessage with a valid operation signature.

Other objects send messages requesting services.



Encapsulation

An object has data and behaviour Behaviour = Data should be accessed only by

object’s own operations Operation signature specifies

number and type of attributes passed to it



Effect of Encapsulation

Object implementation hidden from other objects

Other objects see only operation protocols

Internal details may change significantly— no effect on rest of system

As long as operation purpose and protocol stay the same, changes don’t “ripple”



But we want to distinguish academic and admin staff

E.g. admin staff can’t be assigned to teaching

We specialise the StaffMember base class

StaffMember

nameaddressphonenextOfKincalcHolidayschangeGradepay

Generalisation-Specialisation

Say we have a general Staff class:



Generalisation-Specialisation

StaffMember

- name- address- phoneNumber- nextOfKin

+ calcHolidays()+ pay()

(f rom Use-Case Model)

AdminStaff- grade

+ calcHolidays()+ changeGrade()+ pay()

Module- moduleTitle- moduleNumber

AcademicStaff- specialism

+ assignModule()+ pay()

1* 1*

manages

*

*

*

*teaches



Generalisation-Specialisation Instances of AdminStaff and

AcademicStaff all have name, address, phone, nextOfKin attributes

(from generalised StaffMember class) AcademicStaff also has specialised

associations with Module



Inheritance

An example of inheritance Gives opportunities for reuse Minimises duplication of effort Derived classes inherit base class

reliability Don’t violate base class encapsulation



Inheritance Subclasses redefine the operation pay (signature stays the same) Sender of message need not know

class of receiving object Inheritance allows reuse of existing

class definitions Just add extra attributes or modify

behaviour as required



Polymorphism

Redefinition of pay operation is example of polymorphism

Same pay message can be sent to many StaffMember objects

Each uses its own pay method depending upon class:



Summary

4 important characteristics of OO:– message passing– encapsulation– inheritance– polymorphism



References

Bennett, S., McRobb, S. & Farmer, R. Object-Oriented Systems Analysis and Design using UML McGraw-Hill 2002

Jacobson, I., Booch, G. and Rumbaugh, J. (1999), The Unified Software Development Process, Addison-Wesley, Reading Mass.

Rational Unified Process 2000

requirements analysis 9. 1 oo concepts - 2005b509.ppt © copyright de montfort university 2000 all...

Documents

object v example

oo concepts

oo slide

montfort university

objectid v cars

classes objects v

car object

attribute values v