Object-Oriented Databases & Data Modeling

Object-OrientedDatabases & Data Modeling Chapters 14, 15 & 4

Object Orientation • Object orientation is a modeling and development methodology based on object-oriented (OO) concepts. • Definition of Object Orientation: • A set of design and development principles based on conceptually autonomous computer structures known as OBJECTs. Each object represents a real-world entity with the ability to interact with itself and with other objects.

The Evolution of OO Concepts • From traditional to object-oriented programming (OOP) • Before OOP, data and procedures were isolated from each other. • DATA were treated as the PASSIVE component, while PROCESSES & PROCEDURES manipulate the data as the ACTIVE component. • Procedural languages (e.g., COBOL) encouraged the rigid distinction between data and procedure. • OO concepts first appeared in some programming languages and set the stagefor more refined OO concepts

The Evolution of OO Concepts • Main Objectives of Object-Oriented Programming Languages (OOPL) • To provide an easy-to-use software development environment. • To provide a powerful software modeling tool for applications prototyping. • To decrease development time by reducing the amount of code and to improve programmer productivity by making that code reusable.

The Evolution of OO Concepts • Important Attributes of OO Environment • The data set is no longer passive. • Data and procedures are bound together, creating an object. • Each object has a unique identity • The object has an innate ability to act on itself. • Objects can be reused

Object • Object: An entity that has state, behavior, and identity. • Tangible: Person, place or thing. • Concept or Event: Department, performance, marriage, registration. • Artifact of the Design Process: User interface, controller, scheduler.

State, Behavior, Identity • State: Attribute types and values. • Behavior: How an object acts and reacts. • Behavior is expressed through operations that can be performed on it. • Behavior is sometimes referred to as a method or service. • Identity: Every object has a unique identity.

Objects and Operations • Object Class: Set of objects that share a common structure and a common behavior. • Class Diagram: Fig. 14-2a. • Object or Instance Diagram: Fig. 14-2b. • Encapsulation

Class diagram shows the static structure of an object-oriented model: object classes, internal structure, relationships.

Object diagram shows instances that are compatible with a given class diagram.

Encapsulation • Encapsulation is the packaging of several items together into one unit. • Applied to objects, both attributes (data) and behavior (processes) of the object are packaged together. • The only way to access or change an object’s attributes is through that object’s specified behavior.

Generalization/Specialization • Generalization/specialization is a technique wherein the attributes and behaviors that are common to several types of object classes are grouped into their own class, called a supertype. • The attributes and methods of the supertype object class are then inherited by those object classes.

Inheritance • We can also recognize subclasses of objects • When levels of classes are identified, the concept of inheritance is applied • Inheritance means that methods and/or attributes defined in an object class can be inherited or reused by another object class.

Class Supertype & Subtype • A class SUPERTYPE is an object whose instances store attributes that are common to one or more class subtypes of the object. • A class SUBTYPE is an object class whose instances inherit some common attributes from a class supertype and then add other attributes that are unique to an instance of the subtype. • In object-oriented systems development, objects are categorized according to classes and subclasses. • Program maintenance is easier as modifications need to be made in one place.

Examples of generalization, inheritance: Employee superclass with three subclasses

Associations • Association: Relationship among object classes

Message • Objects/classes interact or “communicate” with one another by passing messages. • A message is passed when one object invokes one or more of another object’s methods (behaviors) to request information or some action.

Polymorphism • Polymorphism means “many forms”. • Applied to object-oriented techniques, it means that the same named behavior may be completed differently for different objects/classes.

Process of Object Modeling • OOA requires that we identify • the objects • their data attributes • associated behavior • relationships that support the required business system requirements

Process of Object Modeling • Object models document • the identified objects • the data and behavior (processes and procedures) they encapsulate • their relationships with other objects

Process of Object Modeling • There are two general activities when performing OOA: • finding and identifying the business objects • organizing the objects and identifying their relationships

OO vs. ERD ERD Object Oriented Class Entity type Object Entity instance Association Relationship Inheritance of attributes Inheritance of attributes Inheritance of behavior No representation of behavior Object-oriented modeling is frequently accomplished using the Unified Modeling Language (UML)

UML • Most popular choice for modeling object-oriented systems and applications. • “Unifies” the design principles of several methodologies to provide a “standard” modeling tool. • UML does not have any dependencies with respect to any technologies or languages.

UML • The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction. • For database professionals UML can be used for database design. Using UML for database design allows the business and application teams who are already using UML for their designs to share a common language and to communicate with the database team.

UML Diagrams • The underlying premise of UML is that no one diagram can capture the different elements of a system in its entirety. Hence, UML is made up of the following nine diagrams that can be used to model a system at different points of time in the software life cycle of a system: • Use case diagram • Class diagram • Object diagram • State diagram • Activity diagram • Sequence diagram • Collaboration diagram • Component diagram • Deployment diagram

Use Case Diagram • A use case diagram captures the functional aspects of a system. • Specifically, it captures the business processes carried out in the system. • Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system. • Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great communication tool for user meetings.

Use Case Diagram • The Use case diagram is used to identify the primary elements and processes that form the system. • The primary elements are termed as "actors" and the processes are called "use cases.“ • The Use case diagram shows which actors interact with each use case.

Elements of a Use Case Diagram • Actors • Use Cases • System Boundary

Actors • An actor portrays any entity (or entities) that performs certain roles in a given system. • The different roles the actor represents are the actual business roles of users in a given system. • An actor in a use case diagram interacts with a use case. • For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. • It is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor.

Use Case • A use case in a use case diagram is a visual representation of a distinct business functionality in a system. • To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. • As the first step in identifying use cases, you should list the discrete business functions in your problem statement. • Each of these business functions can be classified as a potential use case. • Remember that identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident.

System Boundary • A system boundary defines the scope of what a system will be. • A system cannot have infinite functionality. • So, it follows that use cases also need to have definitive limits defined. • A system boundary of a use case diagram defines the limits of the system. • The system boundary is shown as a rectangle spanning all the use cases in the system.

Use Case Specifications • A Use Case Diagram is a visual tool. • Use cases are used as an input to the other project phases such as design, development, and testing implying that the visual depiction of the business requirements need to be translated into clear and well-defined requirements in the form of use case specifications. • Elaborate use case specifications are used as an input for design and development and for writing test cases.

Use Case Specifications • A use case specification document should enable us to easily document the business flow. • Information that you document in a use case specification includes what actors are involved, the steps that the use case performs, business rules, and so forth. • A use case specification document should cover the following areas: • Actors: List the actors that interact and participate in this use case. • Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform. • Post-conditions: Define the different states in which you expect the system to be in, after the use case executes.

Use Case Specifications • Basic Flow: List the basic events that will occur when this use case is executed. • Alternative flows: Any subsidiary events that can occur in the use case should be listed separately. • Special Requirements: Business rules for the basic and alternative flows should be listed as special requirements in the use case narration. These business rules will also be used for writing test cases. Both success and failure scenarios should be described here. • Use case relationships: For complex systems, it is recommended that you document the relationships between use cases.

Object-Oriented Databases & Data Modeling