Docstoc

Interaction Diagram

Document Sample
Interaction Diagram Powered By Docstoc
					Interaction Diagrams

      CSCI 4320
         Interaction Diagrams
Two Types of Interaction diagrams defined in UML

• Collaboration Diagram
  – Emphasizes the structural organization of objects that
    send and receive messages via the method invocation
• Sequence Diagram
  – Emphasizes the time ordering of those messages
       Collaboration Diagram
• Shows the objects as well as the messages that
  are sent in a specific scenario
• Objects are arranged to show message passing
  with a minimum of crossed lines

• Example: Show a particular Patron object
  checking out a particular Resource object along
  with the methods that must be invoked to allow
  the checking out to occur.
   Patron Checking Out Resource




ArgoUML 0.10.1
           Sequence Diagram
• Shows the lifeline of when an object is created and
  activation box of when the object is active.
• Shows the flow of messages unambiguously
• Vertical progression from the top of a sequence
  diagram to the bottom represents the progression of
  time.

• Example: Shows the order in which methods must
  be invoked so that the Patron object can check out
  the Resource object
      Patron Checking Out Resource




ArgoUML 0.10.1
 Creating Your Sequence Diagram
• ArgoUML – Collaboration and Sequence
  features are not active in latest version
• Use the old version of ArgoUML 0.10.1
  – This implementation is however not faithful to
    UML, nor to the look and feel of the rest of
    ArgoUML
• Download Version 0.10.1 (ZIP file)
  http://argouml.tigris.org/servlets/ProjectDo
  cumentList?folderID=330
          Evaluating Design
• Reasons for modeling software before
  embarking on writing code
  – To produced well-structured, modular and
    correct code requires some planning.
  – Models allow us to evaluate the quality of the
    proposed solution without too large an
    investment of effort.
  – A sequence diagram that models a scenario
    may highlight some potential data
    inconsistencies
  Objectives of the Class Design
              Phase
• Code Reuse
• Well-designed Classes and methods
• Assurance of data integrity
                     Code Reuse

• Do any classes intuitively form an inheritance hierarchy?
   – Software, Book, Resource
   – Savings, Checking, Account
• Reuse instead of reinvent mechanisms for interaction
   – readString(length) used by readTitle() and readArtist()
• Can classes share methods through a common abstract
  base class
   – Both GalleryPainting and AuctionedPainting use getTitle(),
     getArtist(), getSubject(), getHeight(), getWidth()
   – Create abstract base class Painting
 Well-Designed Classes and Methods

• Always keep data private
• Always initialize data in a constructor
• Do not use too many related primitive types.
  – Create an aggregate class
  – Use Address class, rather than several attributes like
    street, city, zip
• Not all attributes need individual
  accessor/mutator (get/set) methods
• Name classes, methods and attributes to be
  self-documenting
                     Data Integrity
• Dirty Data: data that is inaccurate, outdated, or missing
• Potential vulnerability stems from updating interrelated
  information in separate transactions or method invocations
• Interrelated Information
   – Multiple data values that must be updated together in order to
     maintain data integrity
   – Example: When a Patron borrows a Resource both the Patron and
     the Resource object must be updated with similar information
     (DueDate)
• Data integrity is at risk by malicious or inappropriate user
  access
     Things You Should Know
• Compare and contrast collaboration and
  sequence diagrams
• What are ways to support code reuse?
• What are some rules to follow to create
  well-defined classes?
• Describe a situation in which data Integrity
  can be compromised.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:3/25/2012
language:English
pages:13