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

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

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

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

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

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

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

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

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

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

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 Visibility based 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

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

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

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

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 Class is 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 Class is 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

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

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

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

Design Class Notation 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’. | Object-Oriented Analysis and Design and the Unified Process

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

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

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

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

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

Object-Oriented Analysis and Design and the Unified Process

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

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

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

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 system e.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

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

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

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

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

First-Cut Sequence Diagram Replace the :System Object with a Use Case Controller Object eg. :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

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 Handler Class 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 Executing a Method. Activation Life is represented with narrow vertical rectangles. Object-Oriented Analysis and Design and the Unified Process

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

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 (CatalogId ProdId 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 :InventoryItem to get “quantity”. So it sends another Message to ask help from :ProductItem in getting the Quantity from :InventoryItem since it has a direct Navigation to it. :Catalog collects 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

Object-Oriented Analysis and Design and the Unified Process

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

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

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

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 the Data Access Classes 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

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

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

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

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

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

Object-Oriented Analysis and Design and the Unified Process

Object-Oriented Analysis and Design and the Unified Process

Object-Oriented Analysis and Design and the Unified Process

TIPS FOR SEQUENCE DIAGRAM DESIGN When developing a Sequence Diagram it is often necessary to work on several tasks at the same time . Such tasks are The Database Design and the User-Interface Prototyping might be ongoing activities that are concurrent with Detail Design. Sequence Diagrams may incorporate the Design element such as ‘’Cover Error Handling’’ or failure in the Use Case. Despite the fact that the Sequence Diagrams may get somewhat busy and complicated yet, they provide an excellent foundation for Programming the Use case. Sequence Diagram enables a The Designer to think through the complexity of each Use Case without programming complications. Object-Oriented Analysis and Design and the Unified Process

DESIGNING WITH COMMUNICATION DIAGRAMS Communication Diagrams are Interaction Diagrams like Sequence Diagrams and they capture same information. The choice of using Sequence Diagram or Communication Diagram is primarily a matter of personal preference. Many Designers prefer to develop Sequence Diagram because, Use Case Descriptions and Dialog Designs follow a Sequence of Steps. Communication Diagram are useful for Showing a different view of the Use Case that emphasizes Coupling. Object-Oriented Analysis and Design and the Unified Process

Designing with Communication Diagrams Communication Diagram Uses the same symbols as a Sequence diagram for Actors, Objects, and Messages except that the Lifeline and the Activation Lifeline symbols are not used Different Symbols used for Communication Diagram Link symbol is used to carry messages between Objects or between Actors and Objects. Numbers on the messages indicate the sequence in which messages are sent. Hierarchical dot numbering scheme is used (5. 5.1, 5.2) when messages are dependent on other messages. The Message format also differs slightly and each message is numbered sequentially. Message Descriptor Syntax [true/false condition] Sequence-no : return-value: = message-name (parameter-list) Object-Oriented Analysis and Design and the Unified Process

The symbols of a Communication Diagram Object-Oriented Analysis and Design and the Unified Process

A Communication Diagram for Create new Order Object-Oriented Analysis and Design and the Unified Process

Comparison of Sequence and Communication Diagrams Communication Diagram focuses on Object themselves. Drawing an Communication Diagram is an effective way to get a quick overview of the collaborating objects . However, You have to hunt to find the numbers to see the sequence of the Messages. Communication Diagrams are used to sketch out a solution. When to use Sequence Diagram or Communication Diagram If the Use Case is small and not too complex a simple Communication Diagram may suffice. For more complex situations, Sequence Diagram may be required to allow you visualize the flow and Message sequence. You can mix the usage of both Interaction Diagrams within the same set of specifications. Object-Oriented Analysis and Design and the Unified Process

UPDATING THE DESIGN CLASS DIAGRAM Design Class Diagram can be developed for each Layer. In the View and Data Access Layers, several new Classes must be specified. - The Domain Layer also has the new Classes added for the Use Case Controller. AFTER CREATING SEVERAL SEQUENCE DIAGRAMS : a) Method Information can be added to the Classes b) Navigation Arrows may also require updating as a result of decisions made during Sequence Diagram Development Update Classes with Method Signatures TYPES OF METHODS - Constructor Methods (creates new instance of the Object) - Data Get and Set Method (retrieves and updates Attribute value) - Use Case Specific Methods Since every Class must have Constructor, Get and Set methods it is optional to include these in the Design Class. However the Use Case Specific Methods must be included in the Design Class Diagram Object-Oriented Analysis and Design and the Unified Process

Updating the Design Class Diagram (continued) Every Message that appears in the Sequence Diagram requires a Method in the Destination Object The Process of Adding Method Signature is to go through every Message in a Sequence Diagram and find the Messages sent to that class. Remember that each ‘Message’ indicates a ‘Method’. For Every Class in the Domain Layer including the Use Case Controller Classes we identify the Messages and ‘Create Methods’. The additions to the Domain Layer are:- The Use Case Handlers; Additional Navigation Arrows (to document which Classes are visible from the Controller Class). Object-Oriented Analysis and Design and the Unified Process

Object-Oriented Analysis and Design and the Unified Process

PACKAGE DIAGRAMS Package Diagram is a high level Diagram that allows the Designer to associates Classes of related groups. A Package Diagram can group Classes by Subsystem or by Layer (View Layer, Domain Layer and Data Access Layer). To develop Package Diagram extract information from Updated Design Class Diagram and Interaction Diagram (Sequence Diagram) for each Use Case. Place the Classes inside the appropriate Packages based on the Layer or Subsystem to which they belong. Dependency Relationships (Dashed arrow line ) shows which elements affect other elements in a System. The arrow tail is connected to the Package that is dependent. And the arrow head is connected to the independent Package. Dependence Relationship may exist between Packages, or between Classes within Packages Object-Oriented Analysis and Design and the Unified Process

Package Diagrams (Continued) Dependency Relationship help designer to track the carry-through effect of changes. Package Diagrams can also be nested to show different level of Packages. Package Diagrams helps to document the Sub-systems The Benefit of using the Package Diagrams for Documentation is that different Packages can be assigned to different Programming teams to program the Classes. Dependency arrow will help Designers recognize where communication among teams must occur to ensure a totally integrated system. Object-Oriented Analysis and Design and the Unified Process

Partial Design for a Three-Layer Package Diagram for RMO Object-Oriented Analysis and Design and the Unified Process

IMPLEMENTATION ISSUES FOR THREE-LAYER DESIGN Using Design Class Diagrams, Interaction Diagrams and Package Diagrams, Programmers can begin to build (Construct) the components of a System by using Programming languages like Java or VB.Net Over the last few years powerful Integrated Development Environment Tools (IDE) have been developed to help Programmers construct the Systems. The IDE tools provide a very high level of Programming support especially in the construction of the new View Layer Classes ( Windows and Window Components of the System). Some IDE Tools for :- JAVA (Jbuilder and Eclips ) Visual Basic and C# (Visual Studio) C++ (C++ Builder) Unfortunately some of these IDE Tools propagate some bad Programming habits in the Developers since they:- Contain Database Engines, to allow the building of the entire System with only one Class. Creates Window Classes with Programming Codes automatically inserted in the Window Class Object-Oriented Analysis and Design and the Unified Process

IMPLEMENTATION ISSUES FOR THREE-LAYER DESIGN The Problem with IDE Tool approach is the difficulty of maintaining the System Codes since they scattered throughout the Graphical Use Interface (GUI) Classes, that becomes very hard to find and maintain. If a Network-based System needs to be enhanced to include Web- front end then a Programmer must rebuild nearly the entire System. If two User Interfaces are desired , then all of the Business Logic is programmed twice. However without the IDE tool that generates code, it is almost impossible to keep the System current. This problem is exacerbated by new releases of the IDE tools which may not be compatible with earlier version. Many Programmers had to rewrite the Front end of Systems because of new IDE Tool releases We recommend that the would be Analysts and Programmers should use Good Design Principles in the Development of new Systems For example given the Design Principles of Object Responsibility it is possible to define what program responsibilities belong to each System Layer. If you follow these guidelines in writing Program code, the new System will be much more easily maintained throughout its lifetime. Object-Oriented Analysis and Design and the Unified Process

IMPLEMENTATION ISSUES FOR THREE-LAYER DESIGN THE PRIMARY RESPONSIBILITIES OF EACH LAYER View Layer Classes should have Programming Logic to:- - Display Electronic Forms and reports - Capture input (such events as Clicks, rollover, key entry etc) - Display data fields - Accept input data - Edit and validate input data - Forward input data to Domain Layer Class - Start up and Shut down the System Domain Layer Classes should have following Responsibilities - Create Problem Domain (Persistent) Classes - Process all Business rules with appropriate logic - Prepare Persistent Classes for storage to the Database Data Access Layer Classes should perform the following: - Establish and maintain connections to the Database - Contain all SQL statements - Process result sets (Result of SQL execution) into appropriate Domain objects - Disconnect gracefully from Database. Object-Oriented Analysis and Design and the Unified Process