pratt adamski chapter 9 some extra material l.
Skip this Video
Loading SlideShow in 5 Seconds..
Pratt & Adamski chapter 9 & Some extra material PowerPoint Presentation
Download Presentation
Pratt & Adamski chapter 9 & Some extra material

Loading in 2 Seconds...

play fullscreen
1 / 39

Pratt & Adamski chapter 9 & Some extra material - PowerPoint PPT Presentation

  • Uploaded on

Pratt & Adamski chapter 9 & Some extra material. The Object-Oriented approach Object-Oriented DBMSs Semantic Object Models Spring 2012. Overview. Object-Oriented Systems Class Diagrams Unified Modeling Language (UML) Object-Oriented DBMS Semantic Object Models (SOM).

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Pratt & Adamski chapter 9 & Some extra material' - lynne

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
pratt adamski chapter 9 some extra material

Pratt & Adamski chapter 9&Some extra material

The Object-Oriented approach

Object-Oriented DBMSs

Semantic Object Models

Spring 2012

  • Object-Oriented Systems
  • Class Diagrams
  • Unified Modeling Language (UML)
  • Object-Oriented DBMS
  • Semantic Object Models (SOM)

Object-Oriented Systems

  • View the world in terms of objects ("things")
  • • Easier to think of systems as objects (customer, shipping clerk,,)
  • • main driver: reusability
  • Object-orientation appears as:
  • • Object-oriented user interfaces (90% of new projects)
  • • Object-oriented programming (80% of new projects)
  • • Object-oriented databases (5% or less)
  • • OO analysis and design (30 to 40%)

Objects: Key Concepts

  • Definition: Objects are data guarded by a protective layer of code. OO Software components consist of variables and methods
  • Key concepts of the object-oriented paradigm:
    • object
    • attributes of objects
    • methods of object show behavior (what it can provide )
    • class : template of objects
      • inheritance (lower level objects can inherit from higher level)

Objects: Key Concepts

  • Key Concepts (continued):
    • -Modularity (reduce complex systems into highly cohesive but loosely coupled modules)
    • -Encapsulation (Information hiding in implementation)
  • Message
  • Objects communicate via message passing. A message consists of an object (the recipient), a method, and optional parameters.

Object Examples

  • Example: items in a department store.
  • TV is an object.
    • The attributes of this object are model, year, cost, etc.The methods, for store are, purchase, repair
  • Radio is another object, so is a dishwasher
    • many of these objects have similar properties (attributes, methods)
    • can define a hierarchy .


Smith: Customer



Account No

Balance Due


-1109 Main St.











Object Examples



A Customer object is customer data and customer methods

The attributes of customer object are Name, Address, Account No, Balance Due

The methods on the customer object are Send-Invoice, Add-Customer, etc.



Manage Resources

Project Manager

Resource Manager



Manage Projects

Unified Modeling Language (UML)

  • Unified Modeling Language (UML)
    • Original version released in 1996
    • Became an International Standard in 1997 with the formation of UML Partners (HP, IBM, Microsoft, Oracle, Rational Software)
    • A graphical language for Object-Oriented Analysis and Design (OOAD)

Class Diagram

Use Case Diagram

Sequence Diagram


Unified Modeling Language (UML)

  • Unified Modeling Language (UML)
    • 1. Use Case Diagram
    • 2. Class Diagrams
    • 3. Object Diagrams
    • 4. Sequence Diagrams
    • 5. Collaboration Diagrams
    • 6. Statechart Diagrams
    • 7. Activity Diagrams
    • 8. Component Diagrams
    • 9. Deployment Diagrams
use cases
  • Use cases describe the functionality of the system from the user point of view.
  • Each use case provides one or more scenarios of how the system should interact with the users called actors
  • Use cases are written in non-technical language, understood by users
  • Use cases are written as a part of requirement analysis.
  • Use cases are separate and distinct from use case diagrams, which allow one to abstractly work with groups of use cases.
  • Use case diagrams are created after the use case descriptions are written.

Source: Dr. Sidorova, UNT

use cases diagrams
Use Cases Diagrams

Depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users



Source: Dr. Sidorova, UNT


Class: Key Concepts

  • Class
  • A template or prototype that defines the composition and the behavior of all objects of certain kinds. These objects are called instances of the class
  • Inheritance
  • A mechanism to organize classes by commonalities.
  • subclasses, specialization
  • superclass, generalization
  • Example:
        • Student
        • GradStudent
        • MSStudent
        • PhDStudent
        • UGStudent


Class name





p1: Point

p2: Point

x = 0

y = 0

x = 10

y = 10

Class diagrams

  • A class: point
  • An object: p1
    • Attributes or fields:

int x, y;

    • A method:

point move(int dx, int dy)

    • A message:

p2 = p1.move(10, 10)

Fields (attributes)

class diagram details
Class Diagram details
  • Name of class
  • Attributes
  • Data types
  • Methods (operations)
  • Association (relationship)
  • Multiplicity (cardinality)
class diagram details16
Class Diagram details
  • Associations are shown as lines joining classes and represent relationships. Multiplicity indicates the number of objects at the end of the relationship. Example: 1..1, 0..n, 1..n.
  • The visibility symbol indicates whether other classes can view or update attribute values:
    • Public visibility (+), any other class can view/update
    • Protected visibility (#), class itself or its subclasses can view/update
    • Private visibility (-), only class itself can view/update

Class Diagram with a

Generalization and a Constraint

Figure 9.26

object oriented dbms oodbms
Object-Oriented DBMS (OODBMS)
  • System in which data and the methods operating on that data are encapsulated into objects
  • Store graphics, drawings, video, sound, and other complex objects called binary large objects (BLOBs)
  • General concepts
    • Objects and classes
    • Methods and messages
    • Inheritance
rules for oodbmss what they should support
Rules for OODBMSs: what they should support
  • Complex Objects
  • Object Identity
  • Encapsulation
  • Information Hiding
  • Types (classes)
  • Inheritance
  • Late Binding (polymorphism)
  • Computational Completeness
  • Extensibility
  • Persistence
  • Performance
  • Concurrent Update support
  • Recovery support
  • Query facilities
s o model characteristics
  • S-O Model More Bottom-Up-Oriented than the E-R Model
  • Both Are a Type of "Pseudo-Code“ or "Flowchart" Tool For DB Design
  • David Kroenke primary developer of the SO Model (1994).
    • The Model Is Robust But Lacks Standards.
    • NOT Widely Used Yet in CASE Tools.
s o model definitions
  • * Semantic Object
  • * Object Identifier (primary key)
  • * Object Properties or Attributes
  • * Semantic Object Links
  • * Formulas
s o model definitions25
  • * Semantic Objects -- Represented by a Rectangle (See Fig B.2.a)
    • A named collection of Properties that sufficiently describes a distinct entity (Things, Objects (Nouns) Of Importance To The Users' Data Model)
    • E.g., Employee, Customer, Inventory, Order, Etc.
  • Instance Of A Semantic Object (Fig B.3)
    • Professor “Nick Evangelopoulos”
  • Semantic Object Classes --
    • Collections Of Same Types Of Objects
s o model definitions28
  • * Semantic Objects are Distinct Entities --
    • There are NO “weak” semantic objects!
    • Consider the relational DB design of an ordering system: Line_Item would be property of ORDER, not a distinct entity.
    • Semantic Objects are ALWAYS independent!!
    • Names in CAPITAL letters
  • Semantic Objects:
      • Must Exist In The Minds Of The Users--
      • This is Why They Are Called Semantic Objects
s o model definitions29
  • Object Identifier:
    • Identifies A Unique Object Instance (Key)
    • May Be a Group or Composite (concatenated) Key (OrderNum, LineNum), (Cust_Name, Cust_Addr)
    • ID NameMixedCase
    • ID UniqueId when underlined
s o model definitions30
  • * Properties (Or Attributes) -- Fig B.2 Characteristics Of Semantic Objects:
    • Simple Data Values (S)
    • Multi-Valued (MV or 1.N)
    • Composite or Group Attributes (G)
    • Object attributes or Semantic Object Links(SOLs);
      • (see below)
      • Paired attributes: If an object contains another object, the second object will contain the first [SOLs are reciprocal]
    • USE Mixed Case for Naming Convention: DeptId
s o model definitions32
  • * Semantic Object Link (SOL)
    • Special Type of Property
    • Recursiveness
    • Represented by a rectangle inside of the SO
  • * Formulas (F)
    • Formula Functions: SUM, COUNT, MIN, MAX, AVG
    • Formula Expressions: e.g., Salary / 12
s o model definitions misc
  • Property Domains
    • Set Of All Possible Values Of A Property
  • Semantic Object Views (Fig. B.4)
    • Subset Of Properties Of S-O Required By A Particular Application Or User. Synthesis Of Multiple Objects
    • Views Required To Build Complete Object Diagram.
s o diagrams guidelines
S-O DIAGRAMS Guidelines
  • Picture Of User’s Defined Objects
    • Non-Standard notation
  • Rectangles for Objects; NAMES in Capital letters inside rectangle
  • Object Properties written in MixedCase
  • SOLinks -- Written in Capital letters inside their own rectangles within the SO
  • Groups (Composites) properties are bracketed or braced on Right-hand side
s o diagrams guidelines continued
S-O DIAGRAMS Guidelines (continued)
  • Multi-valued property Cardinalities are shown as Subscripts:
    • 1.1, 1.N, 0.1, 0.N, etc. (also, MV)
    • Actually Minimum and Maximum Cardinality for each property (ID, S, G, or SOL)
      • Min.Max The minimum and maximum allowable occurrences for each property.
      • 0.1 means that the property may have no instances, but at most 1.
      • 1.N means that the property must have at least one instance, and could have many instances.
  • Object-Oriented Systems
  • Class Diagrams
  • Unified Modeling Language (UML)
  • Object-Oriented DBMS
  • Semantic Object Models (SOM)