Ch4: Software Architecture and Design

1. Ch4: Software Architecture and Design

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

3. 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.

4. 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.

5. 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.

6. 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:

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

8. How to choose classes and objects (contd..) • Operations:

9. 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.

10. 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.

11. 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

12. 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

13. HTSS (contd..) SDO EDO IL Item IL SDO EDO ItemDB Local Server IL Payment CR CR IC Order CR Non-Local Client Int. IC CR IL: Item Locator CreditCardDB CR: Cash Register Inventory Control IC: Invent. Control ATM-BanKDB DO: Deli Orderer for Shopper/Employee ItemDB Global Server OrderDB SupplierDB

14. 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.

15. 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.

16. Item class in HTSS • Item class • Attributes: • Operations:

17. 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); };

18. Categories of classes (contd..) Data sinks/data sources: 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(); };

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

20. 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(); };

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