Object Oriented Modeling and Design 15CS55 Association –- Multiplicityli ity A teacher teaches 1 to 3 courses (subjects) Each course is taught by only one teacher. A student can take between 1 to 5 courses. A course can have 10 to 300 students. Teacher 1 Teaches 1..3 1..5 Students Takes 10..300 Dept. of CSE, ACE Page 20 e
Object Oriented Modeling and Design 15CS55 Use cases lead to activities. Many of these activities correspond to operations on the class model. ATM example – Consortium  verifyBankCode. – Bank  verifyPassword. – ATM  verifyCashCard Shopping-List Operations The real-world behavior of classes suggests operations. Shopping-list operations provide an opportunity to broaden a class definition. ATM example – Account.close() – Bank.createSavingsAccount(customer):account – Bank.createCheckingAccount(customer):account – Bank.createCashCardAuth(customer);cashCardAuthorization Simplifying Operations Try to broaden the definition of an operation to encompass similar operations. Use inheritance to reduce the number of distinct operations. ATM domain model Overview of System Design Dept. of CSE, ACE Page 103
Object Oriented Modeling and Design 15CS55 Problem with implementation inheritance How to the following problem? Some of the inherited operations might exhibit unwanted behavior. What happens if the user calls Remove() instead of Pop()? 1. Delegation MyStack List Client +Push() Remove() +Pop() +Top() Add() 2. Interface inheritance Stack Client +Push() Remember this +Pop() structure!! +Top() MyStack List HerStack YourStack Delegation as alternative to Implementation Inheritance Delegation is a way of making composition (for example aggregation) as powerful for reuse as inheritance In Delegation two objects are involved in handling a request – A receiving object delegates operations to its delegate. The developer can make sure that the receiving object does not allow the client to misuse the delegate object Dept. of CSE, ACE Page 127
Object Oriented Modeling and Design 15CS55 The following diagram summarizes the schema. Pattern Categories we group patterns into three categories: Architectural patterns Design patterns Idioms Each category consists of patterns having a similar range of scale or abstraction. Architectural patterns Architectural patterns are used to describe viable software architectures that are built according to some overall structuring principle. Definition: An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Eg: Model-view-controller pattern. Structure Dept. of CSE, ACE Page 136
Object Oriented Modeling and Design 15CS55 Migration of sub systems from one network node to another is only possible if the communication facility allows it. Solution: Loosen the coupling between components of a distributed system and the mechanism it uses for communication, eg: by using o Encapsulation o Location transparency We discuss two patterns that addresses these topics: The Forwarder – Receiver design pattern (provides encapsulation) The Client – Dispatcher – Server design pattern (provides location transparency) Keeping cooperating component consistent is another problem in communication. We discuss one pattern that addresses this issue: The Publisher – Subscriber pattern Forwarder-Receiver Problem Many components in a distributed system communicate in a peer to peer fashion. The communication between the peers should not depend on a particular IPC mechanism; • Performance is (always) an issue; and • Different platforms provide different IPC mechanisms. Forwarder-Receiver (1) Dept. of CSE, ACE Page 140