Object-Oriented Modeling and Design

Nick Laudato and Richard P. Oravetz

WCA MODEL

Participants

Information

Technology

Business Processes

Customers

Products

Definitions

• Model:
  • A model is an abstraction of something for the purpose of understanding it before building it. A model omits nonessential details, so it is easier to manipulate.
  • A representation of real life

• Object-oriented modeling and design:
  • A new way of thinking about problems using models around real-world concepts.
  • The fundamental construct is the object, which combines both data structure and behavior in a single entity.

• Object-oriented programming:
  • Software organized as a collection of discrete objects incorporating both data structure and behavior, in direct contrast to conventional programming where structure and behavior are loosely connected.

Object-oriented modeling and design

• Characteristics of an object-oriented approach include four aspects:
  • Identity - means that data can be quantized into discrete, distinguishable entities called objects.
  • Classification - objects with the same data structure (attributes) and behavior (operations) are grouped into a class.
  • Polymorphism - the same operation may behave differently on different classes
  • Inheritance - is the sharing of attributes and operations among classes based on a hierarchical relationship

Object Modeling Technique (OMT)

• Object Modeling Technique (OMT) – has the following stages:
  • Analysis: building a model of the real-world situation showing its important properties.
  • System Design: in this stage the system designer decides what performance characteristics to optimize, choose a strategy for attacking the problem, and make tentative resource allocations.
  • Object Design: The object designer builds a design model based on the analysis model but containing implementation details.
  • Implementation: The object classes and relationships developed during object design are finally translated into a particular programming language, database or hardware implementation.

Analysis Stage

• Write a problem statement.

• Build an Object Model:
  • Object Model = object model diagram + data dictionary

• Develop a Dynamic Model:
  • Dynamic Model = state diagrams + global event flow diagram

• Construct a Functional Model:
  • Functional Model = data flow diagrams + constraints

• Verify, iterate, and refine the three models:
  • Analysis Document = Problem statement + Object Model + Dynamic Model + Functional Model.

System Design Stage

• The first state of design, during which high-level decisions are made about the overall structure of the system, it’s architecture, etc.
  • Organize the system into subsystems
  • Identify concurrency inherent in the problem
  • Allocate subsystems to processors and tasks
  • Choose the basic strategy for implementing data stores in terms of data structures, files, and databases
  • Identify global resources and determine mechanisms for controlling access to them
  • Choose an approach to implementing software control: use the location within the program to hold state, or directly implement a state machine, or use concurrent tasks
  • Consider boundary conditions

Object Design Stage

• In this stage, we shift away from the real-world orientation of the analysis model towards the computer orientation required for a practical implementation.

• Design Document = Detailed Object Model + Detailed Dynamic Model + Detailed Functional Model

• Obtain operation for the object model from other models
  • find an operation for each process in the functional model
  • define an operation for each event in the dynamic model

Object Design Stage (continued)

• Design algorithms to implement operations:
  • Choose algorithms that minimize the cost of implementing operations
  • Define new internal classes and operations as necessary
  • Assign responsibility for operations that are not clearly associated with a single class.

• Optimize access paths to data:
  • Add redundant associations to minimize access cost and maximize convenience.
  • Rearrange the computation for greater efficiency.
  • Save derived values to avoid recomputation of complicate expressions.

• Implement software control by fleshing out the approach chosen during system design.

Object Design Stage (continued)

• Adjust class structure:
  • Rearrange and adjust classes and operations to increase inheritance.
  • Abstract common behavior out of groups of classes.
  • Use delegation to share behavior where inheritance is semantically invalid.

• Design implementation of associations:
  • Analyze the traversal of associations.
  • Implement each association as a distinct object by adding object-values attributes to one or both classes in the association.

• Determine the exact representation of object attributes

• Package classes and association into modules

Models

• OMT methodology use three kinds of models to describe a system:
  • Object model - describing the objects in the system and their relationships. The object model represents the static, structural, “data” aspects of a system.
  • Dynamic model - describing the interaction among objects in the system. The dynamic model represents the temporal, behavioral, “control” aspects of the system.
  • Functional model – describing the data transformation of the system. The functional model represents the transformational, “function” aspects of a system.

The Purpose of Models

• Models serve several purposes:
  • Testing a physical entity before building it – The simulation of physical structures without having to build physical structures without having to build physical models.
  • Communication with customers – It is important to involve the customer. This is very important for their buy-in into the system.
  • Visualization – Its show how ideas flow within the context.
  • Reduction of complexity – It allows for developers to deal with systems that are too complex to understand directly. Human mind can on focus on a limited amount of information

Object Models

• The object model describes the structure of objects in a system; this includes: their identity, their relationships to other objects, their attributes, and their operations.
• The goal in constructing an object model is to capture those concepts from the real world that are important to an application.
• The object model is represented graphically with object diagrams containing object classes.
• Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes.
• Classes define the attribute values carried by each object instance and the operations which each object performs or undergoes.

The Dynamic Model

• The Dynamic Model describes those aspect of a system concerned with time and the sequencing of operations
  • Events that mark changes,
  • Sequences of events,
  • States that define the context for events, and the organization of events and states.

• The Dynamic Model captures control, that aspect of a system that describes the sequences of operations that occur, without regard for what the operations do, what they operate on, or how they are implemented.

• Represented by state diagrams.

The Functional Model

• The Functional Model describes those aspects of a system concerned with transformations of values:
  • Functions,
  • Mappings,
  • Constraints,
  • Functional dependencies.

• The Functional Model captures what a system does, without regard how or when it is done.

Object Modeling

• An object model captures the static structure of a system by showing the objects in the system, relationships between the objects, and the attributes and operations that characterize each class of objects
  • The most important of the three models
  • Represent more closely to the real world
  • More resilient with respect to change

• Examples of objects:
  • Joe Programmer
  • Microsoft company
  • Lassie
  • Process number 2543

Object Modeling (continued)

• An object is defined as a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand.

• An object is simply something that makes sense in an application context.

• An object serves two purposes:
  • Promotes understanding of the real world
  • Provides a practical basis for computer implementation.

Object Modeling Terminology

• Identity – means that objects are distinguished by their inherent existence and not by descriptive properties that they may have.

• Object instance – when talking in precision it refers to exactly one thing.

• Object Class - describes a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics. Person, company, animal, process, and window are all object classes.

Object Modeling Terminology (continued)

• Object diagrams – provide a formal graphic notation for modeling objects, classes, and their relationships to one another.

• Class diagrams – a schema, pattern, or template for describing many possible instances of data. A class diagram describes object classes.

• Instance diagrams – describes how a particular set of objects relate to each other. An instance diagram describes object instances.

• Attribute – is a data value held by the objects in a class. Name, age, and weight are attributes of Person Objects. Color, weight, and model-year are attributes of Car objects.

Object Modeling Terminology (continued)

• An operation – is a function or transformation that may be applied to or by objects in a class. i.e., Hire, fire, and pay-dividend are operation on class Company. Open, close, hide, and redisplay are operations on class Window.

• Polymorphic – the same operation takes on different forms in different classes.

• Method – the implementation of an operation for a class, e.g., Class File and operation Print

Object Modeling Terminology (continued)

• Link – a physical or conceptual connection between object instances. i.e. Joe Smith Work-for Simplex company

• An association describes a group of links with common structure and common semantics.

• Ternary association - an association between three classes.
  • For example, persons who are programmers use computer languages on projects. This ternary association is an atomic unit and cannot be subdivided into binary associations without losing information. A programmer may know a language and work on a project but might know the language on the project.

• Multiplicity – specifies how many instances of one class may relate to a single instance of an associated class.

Dynamic Modeling

• Those aspects of a system that are concerned with time and changes are the dynamic model, in contrast with the static, or object model

• Control is the aspect of a system that describes the sequences of operations that occur in response to external stimuli, without consideration of what operations do, what they operate on, or how they are implemented.

• The major dynamic modeling concepts are events, which represent external stimuli and states, which represent which represent values of objects. The state diagram is a standard computer science concept (a graphical representation of finite state machines) that has been handled in different ways in literature, depending on its use.

Dynamic Modeling (continued)

• The attribute values and links held by an object are called its state. Over time, the objects stimulate each other, resulting in a series of changes to their states. An individual stimulus from one object to another is an event.

• An event is something that happens at a point in time, such as a user depresses a left button or Flight 123 departs from Chicago.

• Two events that are casually unrelated are said to be concurrent; they have no effect on each other. Flight 123 departs from Chicago while Flight 256 lands in San Francisco.

Dynamic Modeling (continued)

• A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behavior of the object. E.g., the state of a bank is either solvent of insolvent, depending on whether its assets exceed is liabilities.

• A state diagram relates events and states. When an event is received, the next state depends on the current state as well as the event; a change of state caused by an event is called transition.

• The dynamic model is a collection of state diagrams that interact with each other via shared events. An object model represents the static structure of a system, while a dynamic model represents the control of a system.

Dynamic Modeling (continued)

• A condition is a Boolean function of object values, such as “the temperature is below freezing.” A condition is valid over an interval of time.

• An activity is an operation that takes time to complete. An activity is associated with a state. Activities include continuous operations, such as displaying a picture on a television screen, as well as sequential operations that terminate by themselves after an interval of time, such as closing a value or performing a computation.

• Aggregation Currency – An aggregation of the state of a car component states: the Ignition, Transmission, Accelerator, and Brake. Each component state also has substates.

Dynamic Modeling (continued)

• There are three sources of concurrency within the object model.
  • The first is aggregation of objects: each component of an aggregation has its own independent state, so the assembly can be considered to have a state that is the composite of the states of all its parts.
  • The second source is aggregation within an object: the attributes and links of an object are its parts, and groups of them taken together define concurrent substates of the composite object state.
  • The third source is concurrent behavior

Functional Modeling

• The functional model describes computations within a system.

• The functional model specifies what happens, the dynamic model specifies when it happens, and the object model specifies what it happens to.

• The functional model consists of multiple data flow diagrams which show the flow of values from external inputs, through operations and internal data stores, to external outputs.

• The functional model also includes constraints among values within an object model.

Functional Modeling (continued)

• The functional model specifies the results of a computation without specifying how or when they are computed.

• The functional model specifies the meaning of the operation in the object model and the actions in the dynamic model as well as the constraints in the object model.

• A spreadsheet is a kind of functional model.

Data Flow Diagrams

• The functional model consists of multiple data flow diagrams which specify the meaning of operations and constraints.

• A data flow diagram (DFD) show the functional relationships of the values computed by a system, including input values, output values, and internal data stores.

• A data flow diagram is a graph showing the flow of data values from their sources in objects through processes that transform them to their destinations in other objects.

• A data flow diagram does not show control information, such as the time at which processes are executed or decisions among alternate data paths; this information belongs to the dynamic model.

Functional Modeling (continued)

• A data flow diagram contains processes that transform data, data flows that move data, actor objects that produce and consume data, and data store objects that store data.

• A process transforms data values. Typical functions include the sum of two numbers, the finance charge on a set of credit card transactions

• The functional model does not uniquely specify he results of a process with side effects. The functional model only indicates the possible functional paths; it does not show which path will actually occur.

• A data flow connects the output of an object or process to the input of another object or process.

Functional Modeling (continued)

• It represents an intermediate data value within a computation. The value is not changed by the data flow.

• An actor is an active object that drive the data flow graph by producing or consuming values. Actors are attached to the inputs and outputs of a data flow graph.

• A data store is a passive object within a data flow diagram that stores data for later access.

• The data store does not generate any operations on its own but merely responds to requests to store and access data. A data store allows values to be accessed in a different order than they are generated.

Functional Modeling (continued)

• Access operations – are operations that read or write attributes or links of an object.

• Nontrivial operations can be divided into three categories:

• A query is an operation that has no side effects on the externally visible state of any object; it is pure function

• An action is a transformation that has side effects on the target object or other objects in the system reachable from the target object. An action has no duration in time; it is logically instantaneous (although any actual implementation will take some time). E.g., the action of scaling a window on a workstation involves scaling the window boundary and all of the contents of the window by a fixed factor.

Functional Modeling (continued)

• An activity is an operation to or by an object that has duration in time, as opposed to queries and actions, which are considered as instantaneous. An operating system demon, such as an output spooler, is considered an actor because it has an active role in controlling the flow of information.

Summary

• The functional model shows what “has to be done” by the system. The leaf processes are the operations on objects.

• The object model shows the “doers” – the objects.

• The dynamic model shows the sequences in which the operations are performed. Each sequence is implemented as a sequence, loop, or alternation of statements within some method. The three come together in the implementation of methods. The functional model is a guide to the methods.

Methodology Concepts

• Software engineering methodology: a process for the organized production of software, using a collection of predefined techniques and notational conventions.

• The OMT methodology consists of several phases:
  • Analysis
  • System Design
  • Object Design

• Impact of an Object-Oriented Approach
  • Shifting of development effort into analysis
  • Emphasis on data structure before function
  • Seamless development process
  • Iterative rather than sequential

Steps in the OMT Methodology

• Analysis
  • Concerned with devising a precise, concise, understandable, and correct model of the real-world
  • Purpose is to model the real-world system so you can it can fully understood

• Problem Statement
  • Problem scope
  • What is needed
  • Application context
  • Assumptions
  • Performance needs

Steps in the OMT Methodology (continued)

• Design and Implementation:
  • General approach
  • Algorithms
  • Data structure
  • Architecture
  • Optimizations

Constructing an Object Model

• The following steps are performed in constructing an object model:
  • Identify objects and classes
  • Prepare a data dictionary
  • Identify associations between objects (including aggregations)
  • Identify attributes of object links
  • Organize and simplify object classes using inheritance
  • Verify that access paths exist for likely queries
  • Iterate and refine the model
  • Group classes into modules

Classes

• Keeping the Right Classes:
  • Redundant classes
  • Irrelevant classes
  • Vague classes
  • Attributes
  • Operations
  • Roles
  • Implementation constructs

Associations

• Keeping the Right Associations
  • Eliminate unnecessary and incorrect associations:
  • Associations between eliminated classes
  • Irrelevant or implementation associations
  • Actions
  • Ternary associations
  • Derived associations
  • Misnamed associations
  • Role names
  • Qualified associations
  • Multiplicity
  • Missing associations

Attributes

• Keeping the Right Attributes
  • Eliminate unnecessary and incorrect attributes:
  • Objects
  • Qualifiers
  • Names
  • Identifiers
  • Link attributes
  • Internal values
  • Fine detail
  • Discordant attributes

Iterating Object Modeling

• Signs of missing objects:
  • Asymmetries in associations and generalizations
  • Disparate attributes and operations on a class
  • Difficulty in generalizing cleanly
  • An operation with no good target class
  • Duplicate associations with the same name and purpose
  • A role substantially shapes the semantics of a class

• Signs of missing associations:
  • Missing access paths for operations

• Signs of unnecessary associations:
  • Redundant information in associations
  • Lack of operations that transverse an association

Iterating Object Modeling (continued)

• Signs of incorrect placement of associations:
  • Role names that are too broad or too narrow for their classes

• Signs of incorrect placement of attributes :
  • Need to access and object by one of its attribute values

Object Model

• The object model describes the structure of objects in a system; this includes: their identity, their relationships to other objects, their attributes, and their operations.
  • The goal in constructing an object model is to capture those concepts from the real world that are important to an application.
  • The object model is represented graphically with object diagrams containing object classes.
  • Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes.
  • Classes define the attribute values carried by each object instance and the operations which each object performs or undergoes.

Dynamic Model

• The Dynamic model describes those aspect of a system concerned with time and the sequencing of operations; events that mark changes, sequences of events, states that define the context for events, and the organization of events and states. The dynamic model captures control, that aspect of a system that describes the sequences of operations that occur, without regard for what the operations do, what they operate on, or how they are implemented. Represented by state diagrams.

• The dynamic model shows the time-dependent behavior of the system and the objects in it.

• Begin analysis by looking for events - externally-visible stimuli and responses.

Dynamic Model

• Perform the following steps when constructing a dynamic model:
  • Prepare scenarios of typical interaction sequences
  • Identify events between objects
  • Prepare an event trace for each scenario
  • Build a state diagram
  • Match events between objects to verify consistency

Functional Model

• The Functional model describes those aspects of a system concerned with transformations of values: functions, mappings, constraints, and functional dependencies. The functional model captures what a system does, without regard how or when it is done.

• The functional Model shows how values are computed, without regard for sequencing, decisions, or object structure

• The functional Model shows which values depend on which other values and the functions that relate them.

Functional Model (continued)

• The following steps are performed in constructing a functional model:
  • Identify input and output values
  • Build data flow diagrams showing functional dependencies
  • Describe functions
  • Identify constraints
  • Specify optimization criteria

System Design

• System design
  • is the high-level strategy for solving the problem
  • building solutions
  • includes decisions about the organization of the system into subsystems
  • the allocation of subsystems to hardware and software components
  • and major conceptual and policy decisions

• System architecture - is the overall organization of a system, and divided into components called subsystems
  • partitions the problem into subsystems so that further work can be done by several designers working independently (or in parallel) on different subsystems.

System Design

• Analysis Stage: the focus is on “what” needs to be done

• System Design Stage: Decisions are made about “how” the problem will be solved
  • Is the first design stage in which the basic approach to solving the problem
  • The overall structure and style are decided

The System Designer

• The system designer must make the following decisions:
  • Organize the system into subsystems
  • Identify concurrency inherent in the problem
  • Allocate subsystems to processors and tasks
  • Choose an approach for management of data stores
  • Handle access to global resources
  • Choose the implementation of control in software
  • Handle boundary conditions
  • Set trade-off priorities

Subsystems

• Breaking a system in subsystems
  • Each major component of a system is called a subsystem.
  • A subsystem is usually identified by the services it provides

• The lowest level subsystems are called modules
  • Client-supplier
  • Peer-to-peer

• Decomposition of systems:
  • Horizontal Layers
  • Vertical partitions

System Topology

• Identifying concurrency:
  • Identifying Inherent Concurrency
  • Defining Concurrent Tasks

• Allocating Subsystems into Processors and Tasks:
  • Estimate performance needs and the resources needed to satisfy them
  • Decision on hardware/software implementation
  • Allocate Tasks to processors
  • Determine Physical Connectivity

Management of Data Stores

• Advantages of Using a Database
  • Many infrastructure features
  • Common interface for all applications
  • Standard access language (SQL)

• Disadvantages of Using a Database
  • Performance overhead
  • Insufficient functionality for advanced applications
  • Awkward interface with programming languages

Handling of Global Resources

• Physical Units:
  • processors,
  • tape drives,
  • telecommunications

• Space Requirements:
  • disk space,
  • space on a screen display,
  • buttons on a mouse

• Logical names:
  • object Ids, filenames, class names

• access to shared data:
  • databases

System Design Considerations

• Choosing Software Control Implementation
  • Procedure-driven Systems
  • Event-driven Systems
  • Concurrent Systems
  • Internal Control

• Handling Boundary Conditions
  • Initialization
  • Termination
  • Failure

• Setting Trade-off Priorities:
  • making a system faster by using extra memory
  • rapid prototyping
  • develop a guide to making trade-off decisions

Object Design

• Steps of Object Design
  • Combine the three models to obtain operations in class
  • Design algorithms to implement operations
  • Optimize access paths to data
  • Implement control for external interactions
  • Adjust class structure to increase inheritance
  • Design associations
  • Determine object representation
  • Package classes and associations into modules

Steps of Object Design

• Combine the three models to obtain operations in class
  • the object model is the main framework around which design is constructed
  • The designer must convert actions and activities of the dynamic model and an the processes of the functional model into operations attached to classes in the object model.
  • Begin the process of mapping the logical structure of the analysis model into a physical organization of a program

• Design algorithms to implement operations
  • Choose algorithms that minimize the cost of implementing operations
  • Select data structures appropriate to the algorithms
  • Define new internal classes and operations as necessary
  • Assign responsibility for operations to appropriate classes

Steps of Object Design (continued)

• Considerations in choosing among alternative algorithms include:
  • Computational complexity
  • Ease of implementation and understandability
  • Flexibility
  • Fine tuning the object model

• Choosing Data Structures
  • When choosing algorithms involves choosing the data structures they work on
  • Data structures do not add information to the analysis model, but they organize it in a form for the algorithms that use it
  • Data structures include: arrays, lists, queues, stacks, sets, dictionaries, associations, trees, priority queues and binary trees

Steps of Object Design (continued)

• Defining Internal Classes and Operations
  • New, low-level operations may be invented during the decomposition of high-level operations
  • A complex operation can be defined in terms of lower-level operations on simpler objects

• Optimize access paths to data
  • Add redundant associations to minimize access cost and maximize convenience
  • Rearrange the computation for greater efficiency
  • Save derived attributes to avoid recomputation and of complicated expressions

Steps of Object Design (continued)

• Design Optimization
  • Add redundant associations to minimize access cost and maximize convenience
  • During analysis, it is undesirable to redundancy
  • During design it may be desirable to add redundancy
  • The associations that were useful during the analysis may not form the most efficient network when the access patterns and relative frequencies of different kinds of access are considered
  • Saving derived Attributes to Avoid Recomputation
  • Data that is redundant can be “cached” or stored in its computed form
  • Explicit Update
  • Periodic recomputation
  • Active values

Steps of Object Design (continued)

• Implement control for external interactions
  • Using the location within the program to hold state (procedure-driven system)
  • Direct implementation of a state machine mechanism (event-driven system)
  • Using concurrent tasks

• One technique of converting a state diagram to code:
  • Identify the main control path
  • Identify alternate paths that branch off the main path and rejoin it later
  • Identify backward paths that branch off the main loop and rejoin it earlier
  • The states and transitions that remain correspond to exception conditions

Steps of Object Design (continued)

• Adjustment of Inheritance
  • Adjust class structure to increase inheritance
  • Rearrange and adjust classes and operations to increase inheritance
  • Abstract common behavior out of groups of classes
  • Use delegation to share behavior when inheritance is semantically invalid
  • Rearranging Classes and Operations
  • Some operations may have fewer arguments than others
  • Some operations may have fewer arguments because they are special cases of more general arguments
  • Similar attributes in different classes may have different names
  • An operation may be defined on several different classes in a group but be undefined on the other classes

Steps of Object Design (continued)

• Design associations
  • Analyzing Association Traversal
  • One-way Associations
  • Two-way Associations
  • Link Attributes

• Package classes and associations into modules Design algorithms to implement operations

• Physical Packaging:
  • Hiding internal information from outside view
  • Coherence of entities
  • Constructing physical modules

From Design to Implementation

• Most executable languages are capable of expressing the three aspects if software specification:
  • data structure
  • dynamic flow of control
  • functional transformation

• Data structure: is expressed in a declarative (nonprocedural) subset of a language

• Dynamic flow of control: may be expressed either procedurally or nonprocedurally.
  • Procedurally : conditionals, loops, and calls
  • Nonprodedurally: rules, constraints, tables, and state machines

• Traditional languages are purely procedural.

From Design to Implementation (continued)

• Database: is used when access to data is more important rather than operations on the data.

• The main focus of a database is the structure and constraints on the data

• Database operations are much less procedural than conventional programming statements, although they are more procedural than a rule-based system

• Databases provide concurrent operations on data by different users as part of their fundamental structure

From Design to Implementation (continued)

• Most RDBMS provide separate languages for data declarations and operations,.
  • The data definition language used to declare the structure of data
  • Query language may be provided which allows the expression of functional transformations (record locking and update) and flow of control

• Often the design of a computer application involves an implementation that will consist of a mixture of software and some other structure

• Typical domains include:
  • design of hardware
  • design of a knowledge base
  • modeling business enterprises

Programming Style

• Programmers follow principles to make readable programs that live beyond the immediate need:
  • general design principles
  • programming idioms (“how to do common tasks with the tools at hand”)
  • rules-of-thumb
  • tricks of the trade
  • cautionary advice

• Object-oriented style guidelines:
  • Reusability
  • Extensibility
  • Robustness
  • Programming-in-the-large

Programming Style (continued)

• Reusability : reusable software reduces design, coding, and testing cost by amortizing effort over several systems
  • sharing of newly-written code within a project
  • reuse of previously-written code on new projects

• Style Rules for Reusability:
  • Keep methods coherent
  • Keep methods small
  • Keep methods consistent
  • Separate policy and implementation
  • Provide uniform coverage
  • Broaden the method as much as possible
  • Avoid global information
  • Avoid modes

Programming Style (continued)

• Using Inheritance:
  • Subroutines
  • Factoring
  • Delegation
  • Encapsulate external code

• Extensibility:
  • Encapsulate classes
  • Hide data structures
  • Avoid traversing multiple links or methods
  • Avoid case statements on object type
  • Distinguish public and private operations

Programming Style (continued)

• Robustness:
  • Protect against errors
  • Optimize after the program runs
  • Validate arguments
  • Avoid predefined limits
  • Instrument the program for debugging and performance monitoring

Programming Style (continued)

• Programming-in-the-Large:
  • Do not prematurely begin programming
  • Keep methods understandable
  • Make methods readable
  • Use exactly the same names as in the object model
  • Choose names carefully
  • Use programming guidelines
  • Package into modules
  • Document classes and methods
  • Publish the specification

Object-Oriented Languages

• Object-oriented languages:
  • C++
  • Eiffel
  • Smalltalk

• Considerations to apply when implementing an object-oriented design in an object-oriented language:
  • Class definitions
  • Creating objects
  • Calling operations
  • Using inheritance
  • Implementing associations

Object-Oriented Languages (continued)

• Class Definitions:
  • the first step in implementing an object-oriented design is to declare object classes
  • attributes and operations declared in a class
  • assign datatypes to attributes
  • declare attributes and operations as either public or private

• Creating Objects
  • Different languages have different ways to create new objects
  • the language must allocate storage for its attribute values
  • must assign an unique object ID
  • You can also deleted unneeded objects

Object-Oriented Languages (continued)

• Calling Operations:
  • Target object
  • addition arguments for operations are optional
  • some languages support read-only values

• Using Inheritance - Three ways for classifying inheritance mechanisms:
  • static or dynamic
  • implicit or explicit
  • per object or per group

• Implementing Associations - Two general approaches:
  • buried pointers
  • distinct association objects

Object-Oriented Language Features

• Multiple Inheritance
• Class Library
• Efficiency
• Strong Typing vs. Weak Typing
• Memory Management
• Encapsulation
• Packaging
• Development Environment
• Metadata
• Parameterized Classes
• Assertions and Constraints
• Data Persistence

Survey of Object-Oriented Languages

• Smalltalk:
  • was the first popular object-oriented language
  • is not only language but also a development environment
  • it offers the best features of both a language and environment

• C++:
  • an extension of the C language
  • more object-oriented capabilities than C
  • does not contain a standard class library as part of its environment

Survey of Object-Oriented Languages (continued)

• Eiffel:
  • a strongly type object-oriented language
  • multiple inheritance, parameterized classes, memory management, and assertions are supported
  • a class library is provided
  • Eiffel’s compiler translates source programs into C
  • good software engineering facilities for encapsulation, access control, renaming and scope
  • the best OO language in terms of its technical capabilities

Relational Databases

• A Data Base Management System is a computer program for managing a permanent, self-descriptive repository of data. This repository of data is called a database and is stored in one or more files

• Reasons to use a DBMS:
  • Crash recovery
  • Sharing between users
  • Sharing between applications
  • Security
  • Integrity
  • Extensibility
  • Data distribution

Database Application Life Cycle

• Design the application

• Devise a specific architecture for coupling the application to a database

• Select a specific DBMS to serve as a platform

• Design the database

• Provide a user interface, validate data, perform computations

• Populate the database with information

• Run the application

Relational DBMS Concepts

• A RDBMS (defined by Codd) has three parts:
  • Data that is presented as tables
  • Operators for manipulating tables
  • Integrity rules on tables

• RDBMS Logical Data Structure:
  • tables
  • columns
  • rows
  • domain

Relational DBMS Concepts (continued)

• Operators: SQL is the most popular language for RDBMS
  • Select
  • Join
  • Update
  • Insert
  • Delete
  • Create

• RDBMS Integrity
  • Entity integrity
  • Referential integrity
  • Primary key
  • Foreign key

Relational DBMS Concepts (continued)

• Normal Forms
  • are rules developed to avoid logical inconsistencies for table update operations
  • Each normal form prohibits a form of redundancy in tables
    • first normal form: each attribute value does not contain a repeating group
    • second normal form: when the table satisfies first normal form and each row has a primary key
    • third normal form: when the table satisfies second normal form and each non-primary key attribute directly depends on the primary key

• Views
  • A view is a virtual table that is dynamically computed as need
  • A view does not physically exist but is created from one or more tables
  • a conceptual table

Relational Database Design

• Extended Three Schema Architecture for Object Models

• The Use of Object Ids

• Mapping Object Classes to Tables

• Mapping Binary Associations to Tables

• Mapping Ternary Associations to Tables

• Mapping Generalizations to Tables

Associations

• The advantages of merging an association into a class are:
  • fewer tables
  • faster performance due to fewer tables to navigate

• The disadvantages of merging an association into a class are:
  • Less design rigor
  • Reduced extensibility
  • More complexity

Object Model to Table Mapping Rules

• Mapping object classes to tables:
  • Each class maps to one or more tables

• Mapping associations to tables:
  • Each many-to-many association maps to a distinct table
  • Each one-to-many association maps to a distinct table or may be buried as a foreign key in table for the many class
  • Each one-to-one association maps to a distinct table or may be buried as a foreign key in the table for either class
  • Role names are incorporated as part of the foreign name key attribute name
  • A qualified association maps to a distinct table with at least three attributes; the primary key of each related class and the qualifier
  • Aggregation follows the same rules as association

Object Model to Table Mapping Rules (continued)

• Mapping single inheritance generalizations to tables:
  • The superclass and each subclass map to a table
  • No superclass table, superclass attributes are replicated for each subclass
  • No subclass tables, bring all subclass attributes up to the superclass level

• Mapping disjoint multiple inheritance to tables:
  • The superclass and each subclass map to a table

• Mapping overlapping multiple inheritance to tables:
  • The superclass and each subclass map to a table

Advanced Relational DBMS

• Some advantages of the advanced RDBMS approach:
  • Definitely adds to existing RDBMS functionality
  • Integrates well with existing relational databases
  • Data sharing

• Some potential disadvantages are:
  • Performance
  • Functionality
  • Security