Lecture 3

The Unified Software Development Process

The Unified Software Development Process, in short called the unified process (UP) is
incremental in iterative process model for object oriented software development that has gained
acceptance among the practitioners and academicians. The unified process is an extensible
framework which needs to be customized for specific types of projects. The two main
characteristics of the unified process are: use case-driven and iterative. The term use case-driven
implies that use cases (customer’s view) of the system is considered to be the central and most
important view.
four distinct phases:
(1) Inception: During this phase, the scope of the project is defined and prototypes may be
developed to form a clear idea about the project.
(2) Elaboration: In this phase, the functional and the non-functional requirements are captured.
The preliminary use case and the domain models are developed during this phase.
(3) Construction: During this phase, the design and implementation activities are carried out.
Full text descriptions of use cases are written and each use case is taken up for the start of a new
iteration. System features are implemented in a series of short iterations and are tested. Each
iteration results in an executable release of the software.
(4) Transition: During this phase, the product is installed in the user’s environment and
maintained.
UP Object-Oriented Analysis and Design Process

An object-oriented analysis and design process.

Lecture 2
Persistent Objects

Persistence in object-oriented programming is the property of an object that allows it to

continue to exist and retain its state even after the program that created it has ended, by storing it
in a persistent storage medium such as a file or database.

There are many ways to save the state of an object. Some of these are as follows:

(1) Save to a flat file

(2) Save to a relational database

(3) Save to an object database

Saving the Object to a Flat File

The problem to save an object to a flat file is that an object can be thought of as an
indivisible unit that is composed of a number of parts. An object can contain other objects, for
example a Car object might contain objects like Engines and Wheels objects. When you save the
object to a flat file, you must consider saving the entire object, Car, Engines, and the like.
Java has a built-in mechanism for object persistence. Like other C#-based languages,
Java largely uses the concept of a stream to deal with I/O. To save an object to a file, Java writes
it to the file via a Stream. To write to a Stream, objects must implement either the Serializable or
Externalizable interface.
Another more portable approach is to create an XML document as the intermediate file
and decompose and reconstitute an object using open XML technologies.
We cover both approaches in this lecture. First, Java will be used to demonstrate the Java
serialization technology, and then we will use an XML strategy to implement an .NET example
in both Visual Basic and C#.
What About the Methods of a Class?

When an object is saved, only its attributes (data) are stored, not its methods. The
methods belong to the class definition, which must be available on both the saving and loading
sides. For example, in Java serialization, the class (with its methods) must exist when restoring
the object. Although methods aren’t saved in the file, they remain part of the object’s behavior
conceptually.

Using XML in the Serialization Process

Java serialization needs Java on both sides, limiting its portability across different
platforms and languages. Using XML for serialization solves this by creating a standard,
platform-independent format. The XML document represents the attributes and properties of an
object, like the Person class, in a structured way. This XML-based approach can be accessed and
used by code written in C# and VB .NET. While it adds some complexity to how the class is
defined, it offers better compatibility and flexibility across various environments.

Saving The Object to an Object-Oriented Database

Object-oriented databases (OODBMS) store objects directly, keeping their state and
structure, and support features like inheritance and polymorphism. They manage complex data
well and enable long-term object persistence. However, converting existing legacy data from
relational databases to OODBMS is costly and risky, so most companies stick with relational
databases, which remain the dominant choice despite newer technologies.

This has many drawbacks.

 First, anyone who has performed the conversion of data from one database to another knows
that this is a very painful process.

 Second, even if the data converts successfully, there is no way to know how the change of
database tools will affect the application code.

 Third, when problems occur, it‘s difficult to determine whether the problem is with the
database or the application code. It can be a nightmare.
Saving the Object to a Relational Database

Relational databases use tables, but objects don’t map easily to tables. Since most
business data is in relational databases, we need object-to-relational mapping to save and access
objects in these databases. This mapping handles how object classes, associations, and
generalizations correspond to database tables, allowing object-oriented applications to work with
legacy relational data.

Q8. An object contains attributes and behaviors or, in other words, data and methods. When the
object is saved, are the methods of the object stored? Explain why?

Answer: No — methods are not explicitly stored.

Only the state (attributes) of the object is saved.

Both saving and restoring programs must have access to the class definition so methods can be
used when the object is reconstructed.

Q10. Why are relational databases the database of choice for most businesses today?

Answer:

Most business data already exists in relational databases (legacy data).

Converting to object databases is costly and risky.

Relational databases are widely supported, stable, and compatible with existing applications
(e.g., Oracle, SQL Server, MySQL).

Q11. How do objects store in the table in object relational mapping (ORM)?

Answer:

In ORM, object classes are mapped to database tables.

Object attributes map to table columns.

Associations (one-to-one, one-to-many, many-to-many) and generalizations are mapped to

related tables using primary and foreign keys.

This allows object data to be stored in relational form while maintaining object-oriented
programming principles.
Mapping Object Classes to Tables

Object classes are mapped to tables by creating a table for each class. The class attributes
become table columns, and an object ID or primary key is added to uniquely identify each
record. Constraints such as NOT NULL and data types are assigned to columns. Methods of the
class are not stored in tables.

Mapping Associations Classes To Tables

Mapping Association Classes to Tables is the process of converting the relationships

between object-oriented classes into relational database structures. The mapping method depends
on the type of association (one-to-one, one-to-many, many-to-many, or ternary) and its
multiplicity.

Mapping One-to-One Association to Table

Mapping One-to-One Association to Tables is the process of representing a relationship

where one instance of a class is linked to exactly one instance of another class, often by using a
shared primary key or a foreign key between the two tables.

Mapping One-to-Many Association into Tables

In one-to-many association, one occurrence of a class is related to many occurrence of

the associated class. For example, the class diagram for one-to-many association between
University and Employee classes is shown in the figure. When mapping a one-to many
association to tables, there are two options;

(1) First method is to use a foreign key in the table for „many‟ class or

(2) Second method is creating a distinct table for association class.

 Object model for one-to-many Association between University and Employee classes

Mapping Many-to-Many Association into Tables

In many-to-many association, M occurrence of a class is in a relationship with N

occurrence of the associated class. A many-to-many association always maps to a distinct table.
The primary keys for both related classes and any link attributes become attributes of the
associated table.

Object model for many-to-many Association

Mapping Ternary Associations to Tables

Mapping Ternary Associations to Tables is the process of representing a relationship

among three classes by creating a separate table containing the combined primary keys of all
three classes, along with any relationship attributes.

 Create separate tables for each of the three classes.

 Create an additional table to represent the association.
 This association table contains a composite primary key made up of the primary keys of
all three classes.
 It also includes any relationship-specific attributes (e.g., start date, end date).
Mapping Generalizations Classes To Tables

A generalization is a superclass - subclass type of relationship. It is also called

inheritance relationship.
Strategy 1 - Map the superclass and each subclass to a table

Strategy 2 - Map each subclass to a table

Strategy 3 - Map the superclass to a single table

Strategy 1 - Map the Superclass and Each Subclass to a Table

A generalization is a superclass - subclass type of relationship. It is also called

inheritance relationship. The Employee superclass represents all employees, while salaried and
hourly employees are subclasses. This models the generalization where the superclass groups
common features, and subclasses represent specific types of employees.

Strategy 2 - Map Each Subclass to A Table

This method only map subclasses to tables and does not map the superclass to a table.
The attributes in the superclass are duplicated in all subclasses. This strategy creates a separate
table for each subclass, duplicating the superclass’s primary key and attributes in each subclass
table. It is mainly used when inheritance is disjoint and complete.

3.4.3 Strategy 3 - Map the Superclass To A Single Table

In this case, only the superclass is mapped to a table and does not map the subclasses to
tables. The attributes in the subclasses are brought to the superclass. This strategy maps both the
superclass and all subclass attributes into a single table, introducing nulls for attributes not
applicable to certain subclasses. It is suitable when there are few subclasses with few attributes.

Q9. Consider the following UML aggregation class diagram and maps to corresponding
tables.

The UML diagram shows a one-to-many aggregation between Order and OrderItem:

Order Table:

Columns: dateOrdered, dateFulfilled, federalTax, stateTax, localTax, subtotalBeforeTax

Primary Key: (usually orderID, though not shown in the diagram, it’s implied)

OrderItem Table:

Columns: numberOrdered

Foreign Key: References Order (to indicate which order the item belongs to)

Mapping:

Create an Order table with its attributes.

Create an OrderItem table with its attributes.

Add a foreign key in OrderItem that references the primary key of the Order table to establish the
one-to-many relationship.

Patterns versus Algorithms

Questions such as—―Are patterns and algorithms identical concepts? After all, both target to
provide reusable solutions to problems!‖

Answer: Patterns and algorithms are in some respects similar since both attempt to
provide reusable solutions. However,

• Algorithms primarily focus on solving problems with reduced space and/or time
requirements, • Patterns focus on understandability and maintainability of design and
easier development.

Pros and Cons of Design Patterns

The following are the main pros strengths of design patterns:

• Design patterns provide a common vocabulary that helps to improve communication among the
developers.

• Design patterns help to capture and disseminate expert knowledge.

• Use of design patterns help designers to produce designs that are flexible, efficient, and easily
maintainable.

• Design patterns guide developers to arrive at correct design decisions and help them to improve
the quality of their designs.

• Design patterns reduce the number of design iterations, and help improve the designer
productivity.
Important cons shortcomings of design patterns are the following:

• Design patterns do not directly lead to code reuse. Since a design pattern is tailored for a
specific circumstance of reuse, and therefore it is difficult to associate a fixed code segment with
a pattern.

• At present no methodology is available that can be used to select the right design pattern at the
right point during a design exercise.