1 / 39

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. Overview. Object-Oriented Systems Class Diagrams Unified Modeling Language (UML) Object-Oriented DBMS Semantic Object Models (SOM).

lynne
Download Presentation

Pratt & Adamski chapter 9 & Some extra material

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pratt & Adamski chapter 9&Some extra material The Object-Oriented approach Object-Oriented DBMSs Semantic Object Models Spring 2012

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

  3. 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%)

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

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

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

  7. Customer Smith: Customer Name Address Account No Balance Due -Smith -1109 Main St. -1100987546 -$589.19 Add-Customer() Update-Customer() Get-Balance-Due() Send-Invoice() Add-Customer() Update-Customer() Get-Balance-Due() Send-Invoice() Object Examples Class Object 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.

  8. Resource Manage Resources Project Manager Resource Manager Hourly Salaried 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

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

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

  11. Use Cases Diagrams Depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users <<include>> <<extend>> Source: Dr. Sidorova, UNT

  12. Example of a use case diagram from Wikepidea Source: Dr. Sidorova, UNT

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

  14. Point Class name x y Move methods 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)

  15. Class Diagram details • Name of class • Attributes • Data types • Methods (operations) • Association (relationship) • Multiplicity (cardinality)

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

  17. Class Diagram for Premiere Products Figure 9.24

  18. Class Diagram with Constraints Figure 9.25

  19. Class Diagram with a Generalization and a Constraint Figure 9.26

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

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

  22. Semantic Object Model (SOM):a different approach

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

  24. S-O MODEL DEFINITIONS • * Semantic Object • * Object Identifier (primary key) • * Object Properties or Attributes • * Semantic Object Links • * Formulas

  25. S-O MODEL DEFINITIONS • * 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

  26. Object Diagram Fig. B.2

  27. Figure B.3Instance of a Semantic Object

  28. S-O MODEL DEFINITIONS • * 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

  29. S-O MODEL DEFINITIONS • 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

  30. S-O MODEL DEFINITIONS • * 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

  31. Figure B.2 (b)Cardinalities (Min.Max)

  32. S-O MODEL DEFINITIONS • * 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

  33. Figure B.2 (a) & (b) SOLs

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

  35. Figure B.4Semantic Object View

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

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

  38. Figure B.2 (b)Cardinalities (Min.Max)

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

More Related