Introduction to Computer Science

1
(No Transcript)
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.

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

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

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.

6
Object-Oriented Event-Driven Program flow
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.

8

• Design Class
  for Student Class
• Design Class Diagrams document and describe the
  Programming Classes

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.

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.

11
Design Models with their
respective Input Models
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 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.

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.

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.

15
Standard Stereotypes found in Design
Models
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 Class is specifically designed to live
  on the Systems 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 )

17
Internal Symbols used to define a Design Class
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)

19
Student Class examples for the Domain Diagram and
the Design Class Diagram
20
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.

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.

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.

23
Customer and Order - coupling
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.

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

26

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.

28
Interaction DiagramsRealizing 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
  Designers 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.

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.

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.

31
Object-Oriented Event-Driven Program flow
32
Example of a Single Use Case
Controller for a single Use Case (Look Up Item
Availability Use Case)
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 theBlack 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

34
SSD for the Look Up Item
Availability Use Case
35
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.

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

37
First-cut Sequence Diagram for
the Look Up Item Availability Use Case
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
• (CatalogId ProdId and Size)
• The Single Use Case Controller (AvailabilityHandl
  er) 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.

39
(No Transcript)
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.

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

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

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.
  aCCatalog and the Data Access Classes have
  Suffix of (DA). e.g. aCCatalog ,
  aPProduct 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.

44
Completed Three-Layer Design for Look
up Item Availability
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. anOrdOrder,. 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.

46
SSD for the Telephone Order
Scenario of the Create new order Use Case
47
Sequence Diagram for Telephone Order Scenario of
Create New Order Use Case
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 aCCustomer
• Add items to an Order with a repeating Message
• Save Order and OrderItem to the Database
• Update Database inventory
• Complete transaction

49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
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.

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

54
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)

55
The symbols of a Communication Diagram
56
A Communication Diagram for
Create new Order
57
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.

58
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 MethodsSince 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

59
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).

60
(No Transcript)
61
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

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

63
Partial Design for a Three-Layer
Package Diagram for RMO
64
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

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

66
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