Introduction to Computer Science - PowerPoint PPT Presentation

1 / 66
About This Presentation
Title:

Introduction to Computer Science

Description:

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. – PowerPoint PPT presentation

Number of Views:324
Avg rating:3.0/5.0
Slides: 67
Provided by: Chim156
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com