Slide 1

Ch4: Software Architecture and Design Slide 2 1 Object-oriented paradigm Object-oriented decomposition: Agents comprised of two parts: Hidden implementation: Public interface: An Agent can only be modified by operations defined in either the hidden implementation or public interface. Slide 3 2 Core object oriented concepts Class Information: Method Object Message Slide 4 3 Class class name attributes: operations: external entities things occurrences roles organizational units places structures A class is a generalized description of a collection of similar objects. Object is an instance of a class. Class exports: -Operations used to manipulate instances -May export attributes. Slide 5 4 Two representations of a class Slide 6 5 Operations (or methods or services) An executable procedure that is a part of a class and operates on the data attributes defined as part of the class. A method operates on all instances of a class A method is invoked via message passing. Slide 7 6 Messages Messages - the means by which objects invoke each others methods. Slide 8 7 An example Employee class Class Employee { } //Hidden Implementation Private: //Instance Vars char[30] name; float salary; //Public Interface Public: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s); Main() { //Declare Objects Employee emp1(A,100.0); Employee emp2(B,120.0); //Pass Messages //Invoke Methods emp1.print_name(); emp1.print_salary(); emp2.update_salary(10); emp2.print_name(); emp2.print_salary(); } Whats Output of Main()? A 100.0 B 130.0 Conclusion: Each Object (emp1,emp2) has Own Independent State that is Accessible via Shared Public Interface of Class Slide 9 8 Classes vs. ADTs Classes extend ADTs as follows: Message passing: Inheritance: Polymorphism: ADT/OO benefits: Slide 10 9 How to choose objects and classes The first and most often raised concern for newcomers to OO concepts Typical answers: Better answer: Slide 11 10 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. Slide 12 11 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. Slide 13 12 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. Slide 14 13 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: Slide 15 14 How to choose classes and objects (contd..) Redundancy: Discard nouns outside the system domain Vagueness: Attributes: Slide 16 15 How to choose classes and objects (contd..) Operations: Slide 17 16 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. Slide 18 17 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. Slide 19 18 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 Slide 20 19 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 Slide 21 20 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 Slide 22 21 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. Slide 23 22 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. Slide 24 23 Item class in HTSS Item class Attributes: Operations: