Objectives

2. Objectives • The Primary focus of this chapter is on how to develop detailed Object-oriented Design Models, which programmers then use to code the System. • The two most important Models that must be developed are: - - Design Class Diagrams - Interaction Diagrams (Sequence Diagrams , Communication Diagrams) • Develop Class Diagrams for each of the “Three Layer Design” - View Layer, - Domain Layer - Data Access Layer. • Design Class Diagrams extends the Domain Class Diagram Model that was developed during Requirements Activities. Object-Oriented Analysis and Design and the Unified Process

3. Objectives (continued) • Interaction Diagrams • Extend System Sequence Diagrams • Develop detailed Sequence Diagrams as the core process in systems design • Develop Communication Diagrams as part of Systems Design • Document the Architecture Design using Package Diagrams • Package Diagrams • Show relationships and dependencies among Classes Object-Oriented Analysis and Design and the Unified Process

4. What is Object-Oriented Design? • Object-Oriented Design is the process by which a set of detailed Design Models is built which the Programmer will later use to write Program codes and test the System. • System Design is A ‘Bridge’ between a User’s Requirements and Programming for the new System. • A Systems Developer would never try to develop a large System without a set of Design Models. • An Adaptive approach to development including (UP) necessitates • Requirements and design are done incrementally within an iteration • A complete set of Designs Models may not be developed at one time. • The Requirements for a particular Use Case may be developed and then Design Documents developed for the Use Case. • Immediately following the Design of the solution, the Programming can be done. Usually there is no need to generate a formal set of Documents since their purpose is simply to direct Programming. Object-Oriented Analysis and Design and the Unified Process

5. Overview of Object-Oriented Programs • Object-oriented Programs consist of a set of ‘Computing Objects’ that cooperate to accomplish a result. • Each Object has Program Logic and Data encapsulated within it; • Each Object works by sending each other Messages to collaborate to support the functions at the main Program. • Most Object-oriented Programs are ‘Event-driven’ . Program execution is initiated by an Actor waiting to carry out a Use Case that is Business event. • A Use Case is executed by a set of collaborating and interacting Objects. • An Object-Oriented System consists of a set of Computing Objects. Each Object has Program Logic and Data encapsulated within it. Analyst define the structure of the Program Logic and Data fields by a Class. • Class Definition describe the structure or template of what an ‘Executing Object’ looks like. • The Executing Object itself does not come into existence until the Program begins to execute. This is called ‘Instantiation of a Class’ or making an instance (Object) based on the template provided by the Class Definition. Object-Oriented Analysis and Design and the Unified Process

6. Object-Oriented Event-Driven Program flow Object-Oriented Analysis and Design and the Unified Process

7. Object-Oriented Design Models • The Objective of O-O Design is to Identify all Objects that must work together to carry out a Use Case. • Additional Objects to perform specific services such as Logon and Authentication may also be required. • Divide Objects into different groups for that purpose is called ‘Multilayer Design’. • Object groups:- User Interface Objects Problem Domain Objects Database Objects • The most important diagrams in Design is a ‘System Sequence Diagram’ - or its first cousin a Communication Diagrams. These diagrams describe the ‘Messages’ that are sent between Objects. • Analyst extends the System Sequence Diagram by modifying the single :System Object to include all of the interacting ‘User-Interface’, ‘Problem Domain’ and ‘Database Access’ Objects. • The other major Design Model is ‘Design Class Diagram’. The purpose is to document and describe the ‘Programming Classes’ that will be built for the new System. • Design Class Diagrams are the end result of the Design process. They describe the set of Classes needed for Programming Navigation between Classes, Attribute Names and Properties. Thus, Design Class Diagram is a summary of he final Design that was developed using the Detailed Sequence Diagrams. Object-Oriented Analysis and Design and the Unified Process

8. Design Class for Student Class • Design Class Diagrams document and describe the Programming Classes Object-Oriented Analysis and Design and the Unified Process

9. Object-Oriented Design Models • As a Designer you will need to provide enough detail so that a Programmer can write initial Class Definition and then add considerable detail to the Code. e.g. A Design Class Specification helps define the ‘Attributes’ and the ‘Methods’. A Class Definition example of a JAVA Programming Language Notice that the Class Name ,the Attributes and the Method Names are derived from the Design Class Notation. Object-Oriented Analysis and Design and the Unified Process

10. Object-Oriented Design Models • Another important Design Model we use in design is Detailed Statechart Diagram. • Statechart Diagram is useful to describes the Life Cycle of an Object. It captures information about the valid ‘States’ and ‘Transitions’ of an Object. • Statecart Diagrams are an effective tool, but in Designing Business Systems, they are only used for special situations. • A final model that is used to document Subsystems is called ‘Package Diagram’. It denotes which Classes work together as a Subsystem. Object-Oriented Analysis and Design and the Unified Process

11. Design Models with their respective Input Models Object-Oriented Analysis and Design and the Unified Process

12. Object-Oriented Design Process • Object-oriented Design is Use Case Driven meaning that we develop a Design with a Sequence Diagram Use Case by Use Case one at a time. • The Process of Designing requires several steps or iterations. • First step is to create a preliminary version or ‘First-cut Model of the ‘Design Class Diagram’. • The second step in designing is to develop Iteration Diagram resulting in Detailed Sequence Diagram for each Use Case or Scenario. • Designing a Sequence Diagram is the heart of Object-Oriented Systems Design. • The third step is to return the Design Class Diagram and develop Method Names, Attributes, and Navigation Visibilitybased on information developed during the Design of the Iteration Diagrams. • Final Step is to partition the Design Class Diagram into related functions using Package Diagrams • Package Diagram provides an Architectural High-level view of the final System. Object-Oriented Analysis and Design and the Unified Process

13. Design Classes and Design Class Diagrams • First iteration of Design Class Diagram is extensions of Domain Class Model Diagrams: • Elaborate on Attribute details • Define Parameters and Return Values of Methods • Define the internal Logic of Methods • A first-cut Design Class Diagram is based on the Domain Model and engineering Design principles • The Preliminary Design Class Diagram is then used to help develop Interaction Diagrams. • As Design decisions are made during development of the Interaction Diagrams, the results are used to refine the Design Class Diagram • Analyst must specify: • The Class Attributes by its ‘Type’ such as character, numeric etc., | • Methods with Parameters and Returns ?Values that are passed as well as Visibility of Attributes and Methods. • Design Class Diagram is more detailed version of the Domain Model Class Diagram. We complete the Design Class Diagram by integrating information from Interaction Diagrams and other Models. Object-Oriented Analysis and Design and the Unified Process

14. Design Class Symbols • Since many different types of Design Classes will be identified during the Design Process UML has a special notation called ‘Stereotype’ that allows Designer to designate a special type of Class • Stereotype is simply way to categorize a model element as a certain type • Two types of Stereotype Notation • Full Notation with guillemets («») • Shorthand Notation with ‘Circular Icons’ • Four types of Design Class are considered to be Standard :- • Entity Class, • Control Class, • Boundary Class, • Data Access Class. Object-Oriented Analysis and Design and the Unified Process

15. Standard Stereotypes found in Design Models Object-Oriented Analysis and Design and the Unified Process

16. Design Class Symbols • An Entity Class comes from Domain Class, (it is the Design Identifier for a Problem Domain Class). These Classes are normally passive in that they wait for some Business Events to occur before they do anything. They are also ‘Persistent Classes’ • Persistent Class is one that exists after the program quits (i.e. System is shut down.) • A Boundary Classis specifically designed to live on the System’s Automation Boundary. i.e. Windows Classes and all other Classes associated with the User Interface in a Desktop based System.. • A Control Class mediates between the Boundary Classes and the Entity Classes. (It catches the messages from the Boundary Class Objects and send them to the correct Entity Class Objects.) • Control Class acts as a Switchboard between the ‘View Layer’ and ‘Domain Layer’. • A Data Access Classis used to access Database to retrieve data from and send data to a Database. • (i.e. A separate Layer of Classes to access the Database is included in the Design rather than inserting SQL Statements into the Entity Class Methods ) Object-Oriented Analysis and Design and the Unified Process

17. Internal Symbols used to define a Design Class Object-Oriented Analysis and Design and the Unified Process

18. Design Class Notation • The First compartment shows the Class Name and Stereotype information. • The second compartment contains more detail about the Attributes such as Visibility, Type-expression, Name, Initial value, and Properties. • ‘Attribute Visibility’ denotes whether other Objects can directly access the Attribute. • Visibility (+) sign indicates Public and Visibility (-) indicates a Private Visibility . • Attribute Name and Type expression indicate name of the Attributes and whether it is ‘Character, ‘String’, ‘Integer, number, Date, cufrrency etc…. • Initial Value (Default Value or specific starting Value) • Properties are placed within curly brackets { }. • The third compartment contains more details about the Method Signature information (i.e. Information needed to call the Method • Method Visibility, ( +) Public and (-) Private Method. • Method Name, • Type-expression – (The Type of the Return Parameters from the Method) • Method Parameter List – (Incoming Arguments) Object-Oriented Analysis and Design and the Unified Process

19. Student Class examples for the Domain Diagram and the Design Class Diagram Object-Oriented Analysis and Design and the Unified Process

20. In O-O Programming Analyst use the entire Message SIGNATURE to identify a Method to distinguish between Overloaded Methods . • However some O-O Programming Languages allow multiple Methods to have the same Method Name as long as they have different ‘Parameter List’ or Return-Type. • An Overloaded Method – is a Method that occurs more than once with the same Name but with two or more different Parameter lists. • Constructor Method is the Method that makes or creates new Objects for the Class. (e.g. Constructor such as createStudent (name, address, major):Student - In many Programming languages the Constructor Method is given the same name as the Class Name. - We use a Create Statement to follow more closely the Message Names used in Interactions Diagram (i.e Sequence Diagram and Collaboration Diagram). • Class-Level Method is a Method that is associated with a Class instead of with Objects of the Class. Class Level Method is Underlined. (e.g. +findAboveHours(int hours):StudentArray • In JAVA environment Class Level Method is called a ‘Static Method’ and in (.NET) Environment it is called a ‘Shared Method’. Design Class Notation • | Object-Oriented Analysis and Design and the Unified Process

21. Some Fundamental Design Principles • Encapsulation - Is a Design principle that each Object is a self-contained unit containing both Data and program Logic • Programmers depend heavily on the benefits of Encapsulation to support the idea of ‘Object reuse’ • Object Reuse - A design Principle in which a set of standard Objects can be used over and over again within a System. (e.g. one frequent application of Object Reuse is the design of the User Interface either for desktop of Web Applications. • Information Hiding – Is a Design Principle in which Data associated with an Object are no visible to the outside world, but methods are provided to access or change the Data. • This principle is primarily a Programming concept, several important principles are based on it. Object-Oriented Analysis and Design and the Unified Process

22. Some Fundamental Design Principles • Navigation visibility– Interactions between Objects can only be accomplished with Navigation Visibility. • Designer has to ddescribe which Objects can interact with each other (Ability of one Object to view and interact with another Object) • Navigation Visibility can be either one way or two ways. (e.g A Customer Object may able to view an Order Object. • That means the Customer Object may be able to view an Order Object. In Programming terms the Customer Class has a Variable or Reference Variable (such as ‘myOrder’ variable) holds a value to refer to an Order instance. • Coupling -Measures how closely Classes in a Design Class Diagram are linked. • Coupling is derived from Navigation Visibility. • Designer must develop a feel for Coupling - to recognize when there is too much Coupling or to know when it is reasonable amount of Coupling. • Coupling is evaluated as a Design processes Use Case by Use Case. Generally if each Use Case Design has a reasonable level of Coupling the entire System will, too. • High Coupling is primarily bad because it adds unnecessary Complication to a System making it very hard to maintain . A change in one Class ripples throughout the entire system • Coupling can be simplified to reduce “Ripple Effects” on the System. Object-Oriented Analysis and Design and the Unified Process

23. Customer and Order - coupling Object-Oriented Analysis and Design and the Unified Process

24. Some Fundamental Design Principles • Cohesion– Measures the consistency of functions within a Single Class. It focuses on a single Class. • Classes can have Very low, low, medium and high Cohesion. Classes with High level of Cohesion are most Desirable. An example of a Medium Cohesion would be a Class that has closely related responsibilities , such as “Maintain Customer Information’ and another task of “Maintaining Customer Account Information”. Two Highly Cohesive Class could be defined one Class to Maintain Customer Information and the other class for Customer Account Maintenance. Classes with Low Cohesion have several negative effects 1. Hard to maintain since they do many different functions and tend to be over sensitive to changes within the system, suffering from ripple effect 2. Hard to be reused since they have many unrelated functions; thus does not make sense to re-use them. 3. It is difficult to understand the Class since their functions are intertwined and their logic is complex. • The common solution to Classes with Low Cohesion is to divide a Class into several highly Cohesive Classes, This Design concept is called “Separation of Class Responsibilities”. Object-Oriented Analysis and Design and the Unified Process

25. Developing the First-Cut Design Class Diagram • The ‘First-Cut Design Diagram” is developed by extending the Domain Model Class Diagram in two steps:- • Elaborate the Attributes with Type and Initial Value information - Attribute Types information is based on Designer’s expertise - In most instances all Attributes Visibility is kept Private unless stated. 2. Adding Navigation Visibility Arrow Based on which Classes need access to which other Classes: Some Navigation Visibility Guidelines - Navigation from Superior to /Subordinate (1: M relationship) - Navigation from Independent Class to Dependant Class (Mandatory relaxations) - Object requiring info from other Object Points to Object or its Parent - Navigation Arrows may also be bidirectional. Object-Oriented Analysis and Design and the Unified Process

26. Object-Oriented Analysis and Design and the Unified Process

27. Developing the First-Cut Design Class Diagram Despite the Navigation Visibility Guidelines, the best way to implement Navigation between Classes may not be clear. Therefore we may need to wait until additional Design is done and other Design Principles can be applied. The important points to note with regards to Navigation Visibility as Design proceeds are:-:- 1. We will need to be updated as design progresses Use Case by Use Case to ensure that Interaction Diagrams support and implement Navigation initially defined 2. Navigation arrows will need to be Updated to be consistent with Design details 3.Method Signatures will be added to each Class based on Design decisions when creating Interaction Diagrams for the Use case. Object-Oriented Analysis and Design and the Unified Process

28. Interaction Diagrams–Realizing Use Cases and Defining Methods • The Realization of a Use Case-Determine what Objects collaborate by sending messages to each other to carry out the Use Case- is done through the development of an Interaction Diagram. • Developing Interaction Diagrams is at the heart of Object-Oriented design • Two types of Interaction Diagrams are developed during Design: • Sequence Diagrams • Communication Diagrams • Design can be done using either Sequence Diagram or Communication Diagram .This is a matter of a Designer’s preference. ---------------------------------------------------------------------------------------------- • It is important to note that The Interaction Diagrams like Design Class Diagram, developed while Software Design, are not end in themselves. Instead they represent the result of Design Decisions based on well established Design Principles such as ‘Coupling’, ‘Cohesion’ and ‘Separation of Responsibilities’. • These Diagrams may be modified several times as Designers refine them to improve their qualities and correct errors. Object-Oriented Analysis and Design and the Unified Process

29. Object Responsibility One of the fundamental Principle of Object-Oriented Development is the idea of “Object Responsibility”. • Object Responsibility is a Design Principle that indicates which Objects are responsible for carrying out System Processing • One of the most important activities of a Designer is to determine Object Responsibility and build the System based on those decisions. • The Card Responsibility Collaboration Index Cards (CRC) technique is still used to assist the Design process Two MajorAareas of Object Responsibility What is an Object needs to know ? and What is an Object needs to do or initiate? • Knowing • Knowledge about its own Data and about other Classes (have Navigation Visibility), with which it must collaborate to carry out Use Cases • Doing • All the activities an Object does to assist in the execution of a Use Case. (e.g Receive and Process messages, other responsibility will be to instantiate or create new objects that may be required for completion of a Use Case. Object-Oriented Analysis and Design and the Unified Process

30. Use Case Controller To simplify the collection and Processing of all the Messages for a Use Case, Systems Designer frequently make up a new class (An artificial Class called Artifact) that can serve as a collection point for incoming messages. This Class is called a “Use Case Controller: • Use Case Controller Serves as a collection point for incoming messages. It acts as an Intermediary between the outside world and the internal systeme.g. A single Input Window object (User Interface layer) may need to send messages to several Objects in Domain Layer. In that circumstance the Coupling between the Input Window Object and the System would be very high. (as in Fig 8.1) By using a Single Use Case Controller Object to handle all the Input messages the coupling could be reduced. • There are several ways to create Use Case Controllers: • A Single Use Case could be defined for all Use Cases within the System. This would result in Low Cohesiveness, since the set of responsibilities assigned to a single Use Case Controller would be vary broad. • A Single Use Case could be defined for all Use Cases in a Subsystem with a set of responsibilities assigned to it. (remember there could be many Subsystems in a System) • One Use Case Controller for each Use Case wit a set of specific responsibilities • Creating several Use Cases Controllers would raise the Coupling between the User Interface Classes and the Internal Classes, but it would result in highly cohesive Classes with a defined set of responsibilities for each. Object-Oriented Analysis and Design and the Unified Process

31. Object-Oriented Event-Driven Program flow Object-Oriented Analysis and Design and the Unified Process

32. Example of a Single Use Case Controller for a single Use Case (Look Up Item Availability Use Case) Object-Oriented Analysis and Design and the Unified Process

33. Designing with Sequence Diagrams • Interaction Diagrams (Sequence Diagram, and Communication Diagram) form the heart of the Object-Oriented Design process. • Sequence Diagrams are used to explain Object interactions and document Design decisions. • A Systems Sequence Diagram (SSD) captures the interactions between the System and the External world represented by Actors. The System is treated like a (“Black box”) i.e. a Single Object. • The Objective of Designing Detailed Sequence Diagram is to open up the“Black Box” (The System Object) and determine the Internal Processing that must occur within the Automated System.. • A Detailed Sequence Diagram uses all of the same elements as an SSD including the Input Message Syntax:* [true / false condition] return-value:- message-name (parameter-list) except that the :System Object is replaced by all of the Internal Objects and Messages within the System Object-Oriented Analysis and Design and the Unified Process

34. SSD for the Look Up Item Availability Use Case Object-Oriented Analysis and Design and the Unified Process

35. First-Cut Sequence Diagram • Replace the :SystemObject with a Use Case Controller Objecteg. :Availability Handler) on the Sequence Diagram. • Determine which other Objects are needed to carry out the Use Case and add these Objects to Sequence Diagram • The first step is to select an Input Message from the Use Case and add it to Sequence Diagram • The next step is to Determine which other Messages must be sent, and which Objects should be the Source and Destination of each Message. • Decision about which Other Messages are required, based on Design Principles such as Coupling, Cohesion, Object Responsibilities and Controller. • Message can be directly sent from one Object to other Object providing that there is a Navigation Visibility. Otherwise, Messages will be sent indirectly via an Object(s) that has Navigation Visibility to the required Object. Object-Oriented Analysis and Design and the Unified Process

36. First-Cut Sequence Diagram (Continued) • The Use Case Controller provides the link between the Internal Objects and the External Environment . This limits the Coupling to the External Environment to that single Object • Using a Use Case Controller as the Switchboard limits the overall Coupling between the Domain Objects and the Environment. • The :Availability HandlerClass also is highly Cohesive with only two primary Responsibilities. (Receive Incoming messages from the External Environment and return the System response to the Destination) • An Object can be “Active” or “Inactive”. (An Active object resides in memory awaiting further Messages and Values of its Attributes) • We Use “Activation Lifelines” to indicate when an Object is Executinga Method. • Activation Life is represented with narrow vertical rectangles. Object-Oriented Analysis and Design and the Unified Process

37. First-cut Sequence Diagram for the Look Up Item Availability Use Case Object-Oriented Analysis and Design and the Unified Process

38. First-Cut Sequence Diagram Let us explain the First- Sequence Diagram of Look-Up Item Availability - To make an Item Inquiry Actor sends an Input Message (InquiryOnitem) containing Parameter list of (CatalogIdProdId and Size) • The Single Use Case Controller (:AvailabilityHandler) acts like switchboard, forwards the Input Messages to the relevant Superior Object which has Navigations to Subordinate Objects. • From the Design Class Diagram determine which other Objects required to process the Look-Up Item Availability Use Case. :Catalog, :CatalogProduct, :ProductItem, and :InventoryItem. • - The (:AvailabilityHandler) forwards the Input Message to the :Catalog .Object since the Catalog has a Superior / subordinate relationship (Navigation Visibility) to :CatalogProduct, and :ProductItem objects to get Description and the Price. - :Catalog then forwards the message to :ProductItem to initiate Method getDescription ) to :CatalogProduct to initiate message getPrice( ) • However:Catalog does not have direct Navigation Visibility to :InventoryItemto get“quantity”. So it sends another Message to ask help from :ProductItemin getting the Quantity from :InventoryItem since it has a direct Navigation to it.:Catalogcollects all information and returns it to the(:AvailabilityHandler which send it back to the Actor. • Note: The Activation Lifeline under :AvailabilityHandlerexe is the indication of “+InquiryOnitem “ Method execution. The Acivation Lifeline under:Catalog Indicates the Execution of “+getDescription” Method and “getPrice” Method. Object-Oriented Analysis and Design and the Unified Process

39. Object-Oriented Analysis and Design and the Unified Process

40. Guidelines for First-Cut (Preliminary) Sequence Diagram Development The following three steps will produce the Preliminary Sequence Diagram. Remember that refinement and modifications to the Preliminary Sequence Diagram may be necessary. 1.Take each Input Message and determine all of the Internal Messages that result from each Input Message. To define the Internal Messages :- - Determine the Objectives of each Message. - Determine What information is needed, Which Classes need it, the Source and Destination . • Determine what Objects are created as a result of that Input. • 2. For each Input Message, Identify the complete set of Classes that will be affected by that Message. Such Classes are those listed in the Use Case Description either in the Preconditions or Postconditions for a Use Case () . Also other Classes such as Creators of Objects for the Use Case that are updated during the Use Case. These Classes should be included in the Design. 3. Flesh out the components for each Message. Add Iteration , True / False conditions, Return Values and Passed Parameters.Note :- Passed Parameters should be based on the attributes of the Domain Class Diagram . Return Values and Passed Parameters can be attributes but they may also be objects from Classes. Object-Oriented Analysis and Design and the Unified Process

41. Developing a Multilayer Design • The First-cut Sequence Diagram focuses only on the Class in the Domain Layer. However, in Systems Design we must also Design the “User Interface Classes” and the “Data Access Classes”. • In the early days of Interactive Systems and Graphical User Interface (GUI) Tools, Software Vendors invented Languages and Tools (early version of VB, Delphi etc) that made it easy to develop Systems with GUI such as windows and buttons. • However in these Languages the Program Domain Logic was attached to the Windows and other Graphical components. So to move these Systems to other environments such as Browser-based Systems, Designers had to completely rewrite the System. • Remember too that when a Class contains both User Interface Function and Business Logic Function:’ the Class Cohesiveness becomes low!!!. • As O-O Languages become more prevalent and tools integrated both O-O Programs and GUI, it becomes easier to build Systems that could be partitioned and that allowed Class Responsibilities to be separated. Such as the User Interface Classes do not need to have Business Logic – other than Edits on the Input Data). • So, Designers Could build Multilayer Systems that were more robust and easier to maintain and conform with good Design. Tools such as JAVA and Visual Studio(.NET) provide the capability to easily build GUI as well as sophisticated Problem Domain Classes.. Object-Oriented Analysis and Design and the Unified Process

42. Developing a Multilayer Design Designing The View layer • The View Layer involves Human Computer Interaction (HCI) and requires designing the User Interface for each Use Case. • The Designer takes the step in a Use Case Description and begins to develop a Dialog Design for the Use Case , Usually defining one or more Window Forms or Web Forms that the User will use to interact with the System. • Once the Electronic Forms are designed an Object-Oriented Window Class can be defined for each Form • Each Electronic Input Form is added as Window Class <<boundary>> on to the Sequence Diagram • Since the Data are entered by the Actor via keyboard and the User Interface Window Object catches that information, formats it and transmits the Message to the Use Case Controller Object, the User Interface Object is placed between the “Actor” and the “Use Case Controller” Object. Object-Oriented Analysis and Design and the Unified Process

43. Developing a Multilayer Design Designing the Data Access Layer • The Principles of Separation of Responsibilities applies to Data Access Layer Design as well. • On Smaller Systems “Two Layer Design’’ exist, in which the SQL Statements to access a Database are embedded within the Business Logic Layer. This implies that SQL statements are included in Methods of the Problem Domain Classes. • On Large and more complex Systems , it makes sense to create Classes whose sole responsibilities is to execute Database SQL Statements, get the results of query and provide that information to the Domain Layer. • Because of a problem between Object-Oriented Programming Languages and Database Languages (i.e Mismatch between O-O Programming Languages and Database SQL Statements) , have partially driven the trend to a Multilayer Design. • Rather than mixing the Business Logic with the Data Access Logic, it is better to define separate Classes and let each Class to focus on its Primary Responsibility is an application of Good Design principles of Highly Cohesive Classes with appropriate Responsibilities. Notes:- Description of each Domain Object has a prefix of (aX) identifie, where (X) is replaced by the first character of Class. Eg. aC:Catalog and theData AccessClasses have Suffix of (DA). e.g. aC:Catalog , aP:Product and :CatalogDA. Etc The set of ‘’initxxxx’’ messages ( initCatalog , initProduct etc ) can either create a new Object if necessary or simply verify that existing Objects are in memory. Object-Oriented Analysis and Design and the Unified Process

44. Completed Three-Layer Design for Look up Item Availability Object-Oriented Analysis and Design and the Unified Process

45. A First-Cut Sequence Diagram for an RMO Telephone Order • Define a User Controller Object (:OrderHandler) • Define a “Create Message’’ for new Order Objects which will create a new Object within Order. • When a ‘Create Message’’ is sent to an Object, it is often drawn directly to the Object box and not to the Lifeline (Optional Diagramming technique). • Another way is let the Customer Object create the Order Object. Since Order Object are not allowed unless a Customer Object exist. This is one way to ensure that the Customer existence Precondition. • Note that a specific Identifier (anOrd) is given to the newly created Order Object e.g. anOrd:Order,. The (anOrd Identifier is then passed back to the Customer Object, which in turn passes it back to :OrderHandler • Define other Internal Messages along with Source and Destination as well as passed Parameters and Navigation Visibility for each Message. • addItem (), createOrdItem (), getDescription(), getPrice(), updateQty () • Working with Design Models enable the Designer to think through all the requirements to process a Use Case without having to worry about code. Object-Oriented Analysis and Design and the Unified Process

46. SSD for the Telephone Order Scenario of the Create new order Use Case Object-Oriented Analysis and Design and the Unified Process

47. Sequence Diagram for Telephone Order Scenario of Create New Order Use Case Object-Oriented Analysis and Design and the Unified Process

48. Developing a Multilayer Design for the Telephone Order Scenario • Extend one Message at a time • View Layer • There is a :MainWindow; with a Menu Item or a Buttonthat opens :OrderWindow • Data Layer • Customer Object initializes itself aC:Customer • Add items to an Order with a repeating Message • Save Order and OrderItem to the Database • Update Database inventory • Complete transaction Object-Oriented Analysis and Design and the Unified Process

49. Object-Oriented Analysis and Design and the Unified Process

50. Object-Oriented Analysis and Design and the Unified Process