Ch4: Software Architecture and Design

1 How to choose objects and classes  The first and most often raised concern for newcomers to OO concepts  Typical answers:  Better answer:

2 How to choose objects and classes (contd..)  Employee class  Private data:  Public interface:  Based on an information perspective, focusing on the idea that to track Employees a set of standard data and operations are needed.

3 How to choose objects and classes (contd..)  ATM_log class:  Private data:  Public interface:  Embodies the functions that take place to authenticate an individual to an ATM session.  Even with a functional view, information is needed to capture user input for verifying status.

4 How to choose objects and classes (contd..)  ATM_User:  Private data:  Public interface:  User interface by capturing the different interactions between the ATM and the user.

5 How to choose objects and classes (contd..) An appointments system that will allow telephone callers to book an appointment with a doctor. The caller will specify the day and the time when he wishes to be seen by a doctor.  Tentative classes could be:

6 How to choose classes and objects (contd..)  Redundancy:  Discard nouns outside the system domain  Vagueness:  Attributes:

7 How to choose classes and objects (contd..)  Operations:

8 How to choose objects and classes (contd..)  Attributes are properties of individual objects  Can be  Nouns followed by “of the” (E.g. day “of the” appointment)  Adjectives - color, number, state (on/off)  May not be fully described  Guidelines for identifying attributes:  Attributes that are directly relevant to the problem. Something can be an attribute in one context and an object in another e.g city.  Give them meaningful names.  Avoid attributes that are purely involved in implementation e.g an id number that is generated by the machine and has meaning only within the application.  Avoid attributes that can be derived from existing information e.g. age can be derived from date of birth  Different and unrelated attributes in a class may suggest that the class is a composite of a number of classes. Useful to divide such a class into a number of separate classes.

9 How to choose objects and classes (contd..)  Identifying operations:  Attributes:  Events in the scenarios:  A scenario consists of interactions (events exchanged) that have to take place among the objects to achieve the functionality.  Identify common and rare scenarios.  Events passed to and from the objects implies operation on the object or message from it.

10 How to choose objects and data (contd..)  Real world can also suggest the operations needed to support a class :  Operations should not overlap each other:  Number of operations that have access to the data should be reduced to a minimum.  Operations may refer to verbs in the problem description

11 High-Tech Supermarket System (HTSS)  Automate the functions and actions:  Cashiers and inventory updates  User friendly grocery item locator  Fast-track deli orderer  Inventory control  User system interfaces  Cash register/UPC scanner  GUI for inventory control  Shopper interfaces locator and orderer  Deli interface for deli workers

12 HTSS (contd..) IC IC CR CR CR CR IL IL IL SDO SDOEDO EDO Order Payment Item ItemDBLocalServer Non-Local Client Int. InventoryControl ItemDBGlobalServerOrderDB SupplierDB CreditCardDB ATM-BanKDB IL: Item Locator CR: Cash Register IC: Invent. Control DO: Deli Orderer for Shopper/Employee Shopper/Employee

13 Classes in the HTSS  Nouns:  Noun extraction:  Do we need classes for customers/shoppers?  Nouns such as aisle, shelf, UPC, etc. do not have any independent existence, in fact, they represent attributes of item.

14 Classes in HTSS  A class based on knowledge of the problem domain:  Receipt  There are other kinds of classes, mostly in the solution domain (do not represent any physical entity or a concept in the problem domain), that noun extraction does not reveal.  Classes to represent GUIs.  Collection classes such as linked lists, queues, stacks  Attributes based on domain knowledge:  Retail cost, whole sale cost, etc.

15 Item class in HTSS  Item class  Attributes:  Operations:

16 Categories of classes Data Managers: class Item { private: // Private Data int UPC; char* Name; int InStock, OnShelf, ROLimit; float RetailCost; public: // Public Methods Item(int code, char* str, int st1, int st2, int st3, float cost); void CreateNewItem(); int GetUPC(); char* GetName(); int GetQuantity(); int CheckReorderStatus(); void PrintItem(); void UpdatePrice(float new_value); };

17 Categories of classes (contd..) class ItemDB {private: int Num_Items; int Curr_Item; Item* AllItems[Max_Items]; int FindFirstItem(); int FindNextItem(); int FindItemUPC(int code); int FindItemName(char* name); public: ItemDB(); // Constructor void InsertNewItem(Item* new_one); void DeleteExistingItem(int code); void FindDisplayItemUPC(int code); void FindDisplayItemName(char* name); void PrintAllItems(); }; Data sinks/data sources:

18 Categories of classes (contd..) I1 “milk” I2 “peas” I3 “soda” ItemDB Data Manager class Data Source/Sink class Data Source/Sink class is added for implementation.

19 Categories of classes (contd..) View/Observer: Provide an interface for user - class InvControlGUI { private: int Curr_Option; // Current menu option public: InvControl(); // Constructor void PrintMenuSetOption(); void ActivateController(); void EnterNewItem(); void RemoveExistingItem(); void FindItem(); void InvSearchQuantity(); void InvSearchReorder(); void GenerateAnOrder(); };

20 Categories of classes (contd..)  Facilitator/Helper – Used to support complex tasks  For HTSS, Facilitator/Helpers are as follows: