Ooad

  • Uploaded by: muchimp
  • 0
  • 0
  • April 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Ooad as PDF for free.

More details

  • Words: 2,028
  • Pages: 39
Object Oriented Analysis and Design

The Role of Classes and Objects in Design • Identify the classes and objects that form the vocabulary of the problem domain (key abstractions) • Invent the structures whereby sets of objects work together to provide the behaviors that satisfy the requirements of the problem (mechanisms) • This view represents the logical framework of the system

Object Oriented Analysis The intent of OOA is to define all classes, their relationships, and their behavior. A number of tasks must occur: – Static Model (Object Model) a) Identify classes b) Specify class hierarchy c) Identify object-to-object relationships d) Model the object behavior

– Dynamic Model (Scenario Diagrams)

The UML Notation for Object Modeling UML Object Model Notation

super class Association class name attribute name Class1

Class

Attribute1

0..*

Operation1a Operation1b

Operation name

Attribute: Operation:

subclass name

Multipicity of association Class2

Class3

Attribute2a Attribute2b

Attribute3a

Operation2

Operation3a

Inheritance

Class4

1+

Attribute4a Attribute4b Operation4

Aggregarion

OOA and OOD – Abbot’s Textual Analysis P a rt o f sp e e ch M o d e l co m p o n e n t

E x a m p le

p ro p e r n o u n im p r o p e r n o u n d o in g v e r b b e in g v e r b h a v in g v e r b a d je c tiv e a d je c tiv e p h r a s e

M ehdi H assan s tu d e n t, te a c h e r buy is a h o r s e , is a b o o k fa n h a s w in g s t h is b a ll is g r e e n t h e c u s t o m e r w it h c h ild r e n t h e c u s t o m e r w h o b o u g h t t h e k it e

in s t a n c e c la s s / t y p e / r o le o p e r a t io n c la s s ific a t io n c o m p o s it io n a t t r ib u t e v a lu e o r c la s s a s s o c ia t io n o p e r a t io n

Derivation of the Object Model Derived from Peter Coad

• Select Objects • Define Attributes • Show Collaborations • Define Services

- Who I am? - What I Know? - Who I know? - What I do?

Select Objects – Select actors - person, organization – Select Participants - role (agent, applicant, buyer, etc) – Select Places - airport, assembly-line, bank, city, etc

– Select Transactions - agreement, authorization,

delivery, deposit, order, payment, sale – Select Container Objects - bin, folder, shelf, etc

– Select Tangible things - account, book,

calendar, cash box, cash drawer, item, plan, procedure, product, schedule, skill, tool, etc.

Identify Structures • Identify Gen-Spec Structures (Hierarchy) • Identify Whole-Part structures (Aggregations)

Define Object Attributes • For actors consider name, address, phone. • for participants consider number, date and time, password, authorization level. • for place/location consider number, name, address (perhaps latitude, longitude, altitude). • for transaction consider number, date, time, status. • for line item consider quantity, status. • for item consider name, description, dimension, size, UPC, weight.

Show Collaborations • For an actor, include an object connect to its participants (association). • For a participant, include an object connection to its actor (already established) and its transactions (association). • For a location, include object connections to objects that it can hold (association), to its part objects (aggregation), and to the transactions that are taking place at that location (association).

Show Collaborations - contd. • For transactions, include object connections to its participants (already established), its line items (aggregation), and its immediate subsequent transaction (aggregation). • For a transaction line item, include object connections to its transaction (already established), its item (association), a companion “item description” object (association), and a subsequent line item (association).

Show Collaborations - contd. • For an item, include object connections to transaction line item (already established), a companion “item description” object (association). • For a composite object, include object connections to its “part” object (aggregation). • For all objects select connecting objects to which the object under consideration sends a message to get some information or to answer a query about objects directly related to it.

• • • • • • • • •

Define Services

Why does the system need this object any way? What useful questions can it answer? What useful action can it perform? What this object can do, based upon what it knows? What this object can do, based upon whom it knows? What calculations can it do? What ongoing monitoring could it do? What calculations across a collection could it make? What selections across a collection could it make?

Define Services - contd. • For an actor, consider: calculate for me, rate me, is , rank participants, calculate over participants. • For a participant, consider: calculate for me, rate me, is , rank transactions, calculate over transactions. • For a place, consider: calculate for me, rate me, is , rank transactions, calculate over contents, calculate over container line items.

Define Services - contd. • For a Transaction, consider: calculate for me, rate me, is , how many, how much, rank transaction line items, rank subsequent transactions, calculate over transaction line items, calculate over subsequent transactions. • For a line item, consider: calculate for me, rate me. • For an item, consider: calculate for me, rate me, is , how many, how much, rank, calculate over specific items.

CASE STUDY: A Convenience Store Point of Sale System • Requirements R1. scan items and automatically price them R2. know whether an item is on sale R3. automatically total the sale and calculate tax R4. handle purchases and returns R5. handle payments with cash, check, or charge R6. authorize checks and cards R7. calculate change when working with cash or checks R8. record all of the information about a customer transaction R9. balance the cash in the drawer with the amount recorded by the point-of-sale system.

CASE STUDY: A Convenience Store Point of Sale System • The point of sales system is needed to: • to help each cashier work more effectively during checkout, to keep good records of each sale, and to store more efficient store operations.

• That is: • to speed up checkout time • to reduce the number of pricing errors • to reduce the labour required to ticket the item with a price, originally and when prices change.

System Features • • • •

log important information conduct business analyze business results interact with other systems

Features for Logging Important Information • to maintain prices based upon UPC • to maintain tax categories (categories, rates, and effective dates) • to maintain the authorized cashiers • to maintain what items we sell in a store • to log the results of each sale in a store

Features for Conducting Business • to price each item, based upon its UPC • to subtotal, calculate tax, and total • to accept payment by cash, check, or charge

Features for Analyzing Business Results • to count how many of each item sold • to count how much we received in cash, check, or credit card sales • to assess how each cashier is performing • to assess how each store is performing

Features for Working With Interacting Systems • to obtain authorization from one or more credit (or check) authorization system

System Features •

Features for Logging Important Information F1. to maintain prices based upon UPC F2. to maintain tax categories (categories, rates, and effective dates) F3. to maintain the authorized cashiers F4. to maintain what items we sell in a store F5. to log the results of each sale in a store



Features for Conducting Business F6. to price each item, based upon its UPC F7. to subtotal, calculate tax, and total F8. to accept payment by cash, check, or charge



Features for Analyzing Business Results F9. to count how many of each item sold F10. to count how much we received in cash, check, or credit card sales F11. to assess how each cashier is performing F12. to assess how each store is performing



Features for Working With Interacting Systems F13. to obtain authorization from one or more credit (or check) authorization system

Select Objects • Select Actors person

• Select Participants cashier, head cashier, customer

• Select Places – Store, Shelf

Select Objects • Select Transactions – sale, every sale is a collection of line items, return, payments, session

• Select container classes – A store is a container class containing cashiers, registers, items.

• Select Tangible Things – item, register, tax category, price

Identify Structures • Identify Gen-Spec structures – – – –

kinds of stores kinds of sales (sale, return) kinds of payments (cash, check, and charge) kinds of prices (regular, promotional (sale))

Gen-Spec Structures Payment

Cheque

Charge

Price

Cash Payment

Promotional Price

Gen-Spec Structures Payment

Authorized Payment

Cheque

Charge

Cash Payment

Identify Whole-Part Structures • A store as a whole is made up of cashiers, registers, and items. • A sale is constituted of sale line items.

Whole-Part Structures

Stote

Register

Cashier

Sale

Item

Sales Line Item

Establishing Responsibilities Who I Know • an actor knows about its participants person knows about cashier

• a transaction knows about its participants a session knows about its register and cashier

• A transaction contains its transaction line items sale contains its sales line items

• A transaction knows its sub transactions session knows about its sales sale knows about its payments

Who I Know - contd. • A place knows about its transactions store knows about its sessions

• A place knows about its descriptive objects store knows about its tax categories

• A container knows about its contents a store knows about its cashiers, items, and registers

Who I Know - contd. Person

Store

Tax Category

Cashier

Session

Register

Payment

Sales

Object Model Diagram for the Point of Sales System Promotional Price

Price

Item

UPCs

Store

Tax Category

Session

Register

Sales Line Item

Sale

Payment

Cash Payment

Return Line Item

Cheque

Authorized Payment

Charge

Person

Cashier

Object Oriented Design Transformation of the analysis model into design model. Analysis Model

Design Model

Classes

Objects

attributes

data structures

methods

algorithms

relationships

messaging

behavior

control

Translating the analysis model into a design model during object design

Object Oriented Programming • OOP is simply implementing the OOD. • Without OOD, OOP does not mean a lot.

Implementation of OOD in C++ • • • •

Classes - C++ Classes Messages - public methods Attributes - private variables/data structures Relationships – Hierarchy – Association – Aggregation

Implementing Relationships in C++ • Hierarchy - inheritance – Polymorphism - virtual methods (public or protected)

• Association – private variables of type pointer to the associated class. – Concept of an object factory

• Aggregation – private variable (pointer or direct) of the type of the aggregated class.

• Multiplicity of the relationship - standard containers (usually a list or a map)

Bibliography •Sommerville, Ian, Software Engineering, 5th Ed., Addison-Wesley, New York, 1995. •Pressman, Roger S., Software Engineering – A Practitioner’s Approach, 4th Ed., McGraw-Hill, 1997. •Booch, Grady, Object Oriented Analysis and Design, 2nd Ed., Benjamin/Cummings, Redwood City, CA, 1994. •Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., Object Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991. •Booch, G., and Rumbaugh, J., Unified Method for Object-Oriented Development, Rational Software Corp., 1996. •Coad, P., North, D., and Mayfield, M., Object Models - Strategies, Patterns, and Applications, Yourdon Press, Englewood Cliffs, NJ, 1995 •Gamma, E. et al., Design Patterns, Addison-Wesley, 1995. •Jacobson, I., Object Oriented Software Engineering, Addison-Wesley, 1992.

Related Documents

Ooad
November 2019 23
Ooad
April 2020 15
Ooad
May 2020 10
Ooad
June 2020 9
Ooad
November 2019 26
Ooad
November 2019 19

More Documents from ""