Object-Oriented Analysis: some basic principles

Objects “Objects have state, behaviour and identity.” Booch (1994) State: the condition of an object at any moment, affecting how it can behave Behaviour: what an object can do, how it can respond to events and stimuli Identity: each object is unique

Examples of Objects Object A person. ‘Hussain Pervez.’ Speak, walk, read. Studying, resting, qualified. A shirt. My favourite button white denim shirt. Shrink, stain, rip. Pressed, dirty, worn. A sale. Sale no #0015, 16/06/02. Earn loyalty points.Invoiced, cancelled. IdentityBehaviourState A bottle of ketchup. This bottle of ketchup. Spill in transit.Unsold, opened, empty.

Classes and Class Diagrams Anything, can be an object More helpfully, objects are grouped into classes Class diagrams depict the nature of the objects (incl. attributes and responsibilities) and associations between them. A “superset” of E-R modelling (Rumbaugh, Booch and Jacobsen)

Types of class 1. “Entity” or “Domain” or “Business object” classes: things that are described by the application. 2. Interface classes: handle input and output. Inserted at design and implementation stage. 3. Control classes: overall control mechanism for the application.

Types of association between classes Ordinary (but cardinality is more subtle than E-R models) Inheritance: “is-a-type-of” relationship. Aggregation: “is-a-part-of” relationship Composition: strong aggregation - “is-a- part-of something that ceases to exist if one part is removed”

Classes have: Attributes - describe the objects; have data type; will become class variables in implementation. Operations - actions the class is responsible for; will become methods in implementation

Class and Instance An object is: “an instance that originates from a class, it is structured and behaves according to its class.” OMG (2001)

Class and Instance “The purpose of a class is to declare a collection of methods, operations and attributes that fully describe the structure and behaviour of objects.” OMG (2001) Structure: what an object knows, information that it holds Behaviour: what an object can do

Specialization Hierarchy Person EmployeeCustomer Supplier monthly paid weekly paid hourly paid DriverCleaner Sales assistant More general (superclasses) More specialized (subclasses)

Advantages of O-O Can save effort –Reuse of generalized components cuts work, cost and time Can improve software quality –Encapsulation increases modularity –Sub-systems less coupled to each other –Better translations between analysis and design models and working code

Issues arising from developing class diagrams Similar idea to E-R modelling, but not identical. Possible to use DFDs or Use Case diagrams to help establish domain classes. But still a matter of judgement - requires a lot of domain knowledge.

Drawing Use Case Diagrams Purpose –document the functionality of the system from the users’ perspective –document the scope of the system –document the interaction between the users and the system using supporting use case descriptions (behaviour specifications)

Notation of Use Case Diagrams Staff Contact Change a client contact System or subsystem boundary Actor Use case Communication association

Staff Contact Record completion of an advert Campaign Manager Change a client contact Assign individual staff to work on a campaign Assign team of staff to work on a campaign Assign staff to work on a campaign

Use Case Descriptions Can be a simple paragraph Assign staff to work on a campaign –The campaign manager wishes to record which staff are working on a particular campaign. This information is used to validate timesheets and to calculate staff year-end bonuses.