Unit – 2 part - 2

NATURE OF CLASS:
A class represents a collection of objects having same characteristic
properties that exhibit common behavior. It gives the blueprint or
description of the objects that can be created from it. Creation of an object
as a member of a class is called instantiation. Thus, object is an instance of
a class.

What is interface:

Interface is a collection of methods of a class or component. It specifies the

set of services that may be provided by the class or component. Notation −
Generally, an interface is drawn as a circle together with its name.

Types of user interfaces

The various types of user interfaces include:

 graphical user interface (GUI)

 command line interface (CLI)

 voice user interface (VUI)

advantages of interface?
Advantages of interfaces over abstract base classes
 Space efficiency. ...
 Compiler optimisation. ...
 Efficient multiple inheritance. ...
 Object creation efficiency. ...
 Forces a clean separation of interface and implementation. ...
 Not type intrusive. ...
 Objects can implement the same interface in different ways. ...
 Avoidance of heap allocations.

Implementation:
Implementing an object-oriented design generally involves using a standard
object oriented programming language (OOPL) or mapping object designs
to databases. In most cases, it involves both.
implementation modeling in Ooad?
The implementation model is a collection of components, and the implementation
subsystems that contain them. Components include both deliverable components, such as
executables, and components from which the deliverables are produced, such as source
code files.

Class life-Cycle: Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the
software life cycle. A life cycle model represents all the methods required to make a software product transit
through its life cycle stages. It also captures the structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a software product from its inception
to retirement. Different life cycle models may plan the necessary development activities to phases in different
ways. Thus, no element which life cycle model is followed, the essential activities are contained in all life cycle
models though the action may be carried out in distinct orders in different life cycle models. During any life cycle
stage, more than one activity may also be carried out.

Need of SDLC
The development team must determine a suitable life cycle model for a particular plan and then observe to it.

Without using an exact life cycle model, the development of a software product would not be in a systematic and
disciplined manner. When a team is developing a software product, there must be a clear understanding among
team representative about when and what to do. Otherwise, it would point to chaos and project failure. This
problem can be defined by using an example. Suppose a software development issue is divided into various parts
and the parts are assigned to the team members. From then on, suppose the team representative is allowed the
freedom to develop the roles assigned to them in whatever way they like. It is possible that one representative
might start writing the code for his part, another might choose to prepare the test documents first, and some
other engineer might begin with the design phase of the roles assigned to him. This would be one of the perfect
methods for project failure.

A software life cycle model describes entry and exit criteria for each phase. A phase can begin only if its stage-
entry criteria have been fulfilled. So without a software life cycle model, the entry and exit criteria for a stage
cannot be recognized. Without software life cycle models, it becomes tough for software project managers to
monitor the progress of the project.

SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes the following steps:

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain experts or SMEs in
the industry.

Planning for the quality assurance requirements and identifications of the risks associated with the projects is also
done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all the data like what the
customer wants to build, who will be the end user, what is the objective of the product. Before creating a product,
a core understanding or knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money transactions. In this method, the
requirement has to be precise like what kind of operations will be done, how it will be done, in which currency it
will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of the growth of a
product. In case of any ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement Specification) document is created. The
developers should thoroughly follow this document and also should be reviewed by the customer for future
reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and document the software
requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which contains all the
product requirements to be constructed and developed during the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and design of the software
project. This phase is the product of the last two, like inputs from the customer and requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The implementation of
design begins concerning writing code. Developers have to follow the coding guidelines described by their
management and programming tools like compilers, interpreters, debuggers, etc. are used to develop and
implement the code.

Stage5: Testing
After the code is generated, it is tested against the requirements to make sure that the products are solving the
needs addressed and gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with suggested enhancement in the
object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues come up and requirements to be
solved from time to time.

This procedure where the care is taken for the developed product is known as maintenance
The object-oriented life cycle model considers 'objects' as the basis of the software
engineering process. The development team starts by observing and analyzing the system
they intend to develop before defining the requirements. Once the process is over, they
focus on identifying the objects of the system. Now, an object could be anything; it can have
a physical existence like a customer, car, etc. An object also constitutes intangible elements
like a process or a project.

Advantages of Object-Oriented Life Cycle Model

Apart from enhancing the system performance, object-oriented programming offers some
advantages such as:
 Since it is data-focused and easy to work with problem domains.
 It uses encapsulation and data hiding process that allows a developer to build tamper-
proof systems.
 It enables software modularity, making it easier to manage and maintain complex
software.
  It allows developers to create new modules using existing models, saving time and
development cost of organizations.
The primary objectives of the Object-Oriented Model
 Object-oriented Analysis
 Object-oriented Design
 Object-oriented Implementation
Object-Oriented Analysis (OOA)
The object-oriented analysis consists of the process where a development team evaluates
the system and organizes the requirements as objects. Contrary to traditional structural
analysis, the OOA heavily depends on advanced data like Use Cases and Object Models.
Use case
Use Cases are written descriptions about how users will behave when they enter your
website or application. It comprises the goals of each user from the point of their entry to
exit.
Object Model
An object model allows the development team to create an architectural software or system
model before implementing or programming. It helps in defining a software/system in
objects and classes. It informs the developers about

 Interaction between different models

 Inheritance
 Encapsulation
 Other types of object-oriented interfaces
The OOA starts with analyzing the problem domain and produce a conceptual model by
thoroughly evaluating the information in the given area. There is an abundance of data
available from various sources like:

 Formal document
 Requirement statements
 Primary data collected through stakeholders
Once the analysis is complete, the development team prepares a conceptual model
describing the system's functionalities and requirements.

Object-oriented Design
It is the next development stage of the object-oriented life cycle model where the analysts
design the desired system's overall architecture. The system is divided into a set of
interacting subsystems. The analyst considers the specifications from the system analysis.
It all about evaluating what the end-users expect from the new system.
As per the object-oriented design, the system is considered a collection of objects, with
each object handling a specific state data. For example, in banking software, each account
may feature some exclusive objects with separate data and functions.
The philosophy behind an object-oriented design is to create a set of interacting objects as
seen in the real world. Instead of process-based structural programming, developers create
objects through data structures.
Each programming language comes with several data types, with each type comprising
various variables. Similarly, objects also feature certain predefined data types.
Useful definitions for Object-oriented design
Class
A class refers to a collection of similar objects. It is created as a blueprint to define variables
and methods that share certain similarities with objects.
As stated above, an object-oriented design bears resemblances with the real world. Let's
say you have purchased a smartphone. Now, your smartphone is just one of the several
'smartphones' available in the world. We can consider 'smartphones' as a class of objects,
and your smartphone object is an instance of a class of objects. Smartphones feature many
states (operating System, RAM, and motherboard) and behavior (play music, call,
messaging) in common. However, the state of each smartphone is independent and can be
different from other smartphones.
While manufacturing smartphones, manufacturers can use the exact blueprint to build many
smartphones as they share common characteristics. This allows manufacturers to create
new blueprints more efficiently.
Likewise, in object-oriented programming, developers can use many similar objects to
create blueprints. This is called a class.
Abstraction
Abstraction is the essence used by developers to build classes. Developers observe a set of
similar objects and characteristics of importance to define classes. Abstractions are divided
into two parts- global abstractions and local abstractions.
Global abstractions are static, providing one interface to users for a limited time. Meanwhile,
Local abstractions are responsible for providing a view based on user/developer's
requirements.
The abstraction of objects varies as per the application. For example, while defining a
smartphone class of users, developers might set attributes like color, features, price, etc.
However, for manufacturing firms, developers may set attributes containing such as the
manufacturing costs per smartphone, quality control, turnaround, etc.
Inheritance
The concept of inheritance in object-oriented design defines the process of reusing 'objects.'
Developers can define a new class type using a similar existing class.
For example, hatchbacks, sedans, SUVs, and 4wds are all a form of motor vehicles. So, as
per object-oriented programming, we can refer to hatchbacks, sedans, SUVs, etc., as
subclasses of the motor vehicle class. Similarly, the motor vehicle class is the superclass of
the subclasses.
Now, each subclass (sedans, hatchback, SUVs) inherits some states (speed, cadence,
etc.), methods, and behaviors (braking, changing gear) of the superclass. However, the
state and behaviors of subclasses are not limited to what has been provided to them by the
superclass. Developers can add variables and methods to subclasses as required.

Object-oriented Implementation
In this phase, developers translate the class objects and the interrelationships of classes
and code them using a programming language. This is the phase to create databases and
establish functionalities for the system.
The object-oriented methodology focuses on identifying objects in the system. Developers
closely observe each object to identify characteristics and behavioral patterns. The
developers ensure that the object recognizes and responds perfectly to an event.
Let's consider a smartphone screen as an object and the touch on a specific icon as an
event. Now, when the user touches an icon, the screen opens up an application. This
means the smartphone screen (object) responds to the event (touch) by opening an
application.
The object-oriented implementation methodology supports three basic models
Object Model − It describes the objects and their interrelationships. This model observes
objects as static and discards their dynamicity.
Dynamic Model − This model focuses on the changes in states of various objects related to
specific events.
Functional Model − This describes the changes in the flow of data throughout the system.
The object model describes the essential elements of a system. When all the models are
combined, it represents the complete function of the system.

Relationships among classes:UML-Relationship

Relationships depict a connection between several things, such as structural, behavioral, or grouping things in the
unified modeling language. Since it is termed as a link, it demonstrates how things are interrelated to each other
at the time of system execution. It constitutes four types of relationships, i.e., dependency, association,
generalization, and realization.

Dependency
Whenever there is a change in either the structure or the behavior of the class that affects the other class, such a
relationship is termed as a dependency. Or, simply, we can say a class contained in other class is known as
dependency. It is a unidirectional relationship.

Association
Association is a structural relationship that represents how two entities are linked or connected to each other
within a system. It can form several types of associations, such as one-to-one, one-to-many, many-to-
one, and many-to-many. A ternary association is one that constitutes three links. It portrays the static
relationship between the entities of two classes.

An association can be categorized into four types of associations, i.e., bi-directional, unidirectional, aggregation
(composition aggregation), and reflexive, such that an aggregation is a special form of association and
composition is a special form of aggregation. The mostly used associations are unidirectional and bi-directional.

Aggregation

An aggregation is a special form of association. It portrays a part-of relationship. It forms a binary relationship,
which means it cannot include more than two classes. It is also known as Has-a relationship. It specifies the
direction of an object contained in another object. In aggregation, a child can exist independent of the parent.

Composition

In a composition relationship, the child depends on the parent. It forms a two-way relationship. It is a special case
of aggregation. It is known as Part-of relationship.

Aggregation VS Composition relationship

Features Aggregation relationship Composition relationship
Dependency In an aggregation relationship, a child can In a composition relationship, the
exist independent of a parent. child cannot exist independent of
the parent.

Type of It constitutes a Has-a relationship. It constitutes Part-of relationship.

Relationship

Type of It forms a weak association. It forms a strong association.

Association

Examples A doctor has patients when the doctor gets A hospital and its wards. If the
transfer to another hospital, the patients do hospital is destroyed, the wards
not accompany to a new workplace. also get destroyed.

Generalization
The generalization relationship implements the object-oriented concept called inheritance or is-a relationship. It
exists between two objects (things or entities), such that one entity is a parent (superclass or base class), and the
other one is a child (subclass or derived class). These are represented in terms of inheritance. Any child can
access, update, or inherit the functionality, structure, and behavior of the parent.

Realization
It is a kind of relationship in which one thing specifies the behavior or a responsibility to be carried out, and the
other thing carries out that behavior. It can be represented on a class diagram or component diagrams. The
realization relationship is constituted between interfaces, classes, packages, and components to link a client
element to the supplier element.

Association : UML- Association

Association is the semantic relationship between classes that shows how one instance is connected or merged
with others in a system. The objects are combined either logically or physically. Since it connects the object of one
class to the object of another class, it is categorized as a structural relationship. Following are the constraints
applied to the association relationship are enlisted below:

a. {implicit}: As the name suggests, the implicit constraints define that the relationship is not visible, but it
is based on a concept.
b. {ordered}: It describes that the set of entities is in a particular way at one end in an association.
c. {changeable}: The changeable constraint ensures that the connections between several objects within a
system are added, improved, and detached, as and when required.
d. {addOnly}: It specifies that any new connection can be added from an object located at the other end in
an association.
e. {frozen}: The frozen constraint specifies that whenever a link is added between objects, it cannot be
altered by the time it is activated over the connection or given link.

Reflexive Association
In the reflexive associations, the links are between the objects of the same classes. In other words, it can be said
that the reflexive association consists of the same class at both ends. An object can also be termed as an instance.

Let's have a look at its example of a class vegetable. The vegetable class has two objects, i.e., onion and eggplant.
According to the reflexive association's definition, the link between the onion and eggplant exist, as they belong
to the same class, i.e., vegetable.

Directed Association
The directed association is concerned with the direction of flow inside association classes. The flow of association
can be shown by employing a directed association. The directed association between two classes is represented
by a line with an arrowhead, which indicates the navigation direction. The flow of association from one class to
another is always in one direction.

It can be said that there is an association between a person and the company. The person works for the company.
Here the person works for the company, and not the company works for a person.

Semantic dependencies:UML-Dependency
Dependency depicts how various things within a system are dependent on each other. In UML, a dependency
relationship is the kind of relationship in which a client (one element) is dependent on the supplier (another
element). It is used in class diagrams, component diagrams, deployment diagrams, and use-case diagrams, which
indicates that a change to the supplier necessitates a change to the client. An example is given below:

Types of Dependency Relationship

Following are the type of dependency relationships, keywords, or stereotypes given below:

o <<derive>> -It is a constraint that specifies the template can be initialized by the source at the target
location utilizing given parameters.
o <<derive>> -It represents that the source object's location can be evaluated from the target object.
o <<friend>> -It states the uniqueness of the source in the target object.
o <<instanceOf>> -It states that an instance of a target classifier is the source object.
o <<instantiate>> -It defines the capability of the source object, creating instances of a target object.
o <<refine>> -It states that the source object comprises of exceptional abstraction than that of the target
object.
 o <<use>> -When the packages are created in UML, the use of stereotype is used as it describes that the
elements of the source package can also exist in the target package. It specifies that the source package
uses some of the elements of the target package.
o <<substitute>> -The substitute stereotype state that the client can be substituted at the runtime for
the supplier.
o <<access>> -It is also called as private merging in which the source package accesses the element of
the target package.
o <<import>> -It specifies that target imports the source package's element as they are defined within
the target. It is also known as public merging.
o <<permit>> -It describes that the source element can access the supplier element or whatever visibility
is provided by the supplier.
o <<extend>> -It states that the behavior of the source element can be extended by the target.
o <<include>> -It describes the source element, which can include the behavior of another element at a
specific location, just like a function call in C/C++.
o <<become>> -It states that target is similar to the source with distinct roles and values.
o <<call>> -It specifies that the target object can be invoked by the source.
o <<copy>> -It states that the target is an independent replica of a source object.
o <<parameter>> -It describes that the supplier is a parameter of the client's actions.
o <<send>> -The client act as an operation, which sends some unspecified targets to the supplier.

Multiplicity: The number of instances of a class that can be linked by a particular

association to a single instance of the class at the other end of the association is known as
the multiplicity of the association at the end.

Types of mutiplicty: There are four types of multiplicities:

1 . one-to-one,

2 one-to-many,

3 many-to-one, and

4 many-to-many.

One-to-one: Each entity instance is related to a single instance of another entity.

Multiplicity in object oriented: defines how many objects participate in a relationship and it is the number of
instances of one class related to one instance of the other class. For each association and aggregation, there are
two multiplicity decisions to make, one for each end of the relationship.
Polymorphism: Polymorphism is originally a Greek word that means the ability to take
multiple forms. In object-oriented paradigm, polymorphism implies using operations in
different ways, depending upon the instance they are operating upon.

inheritance allows a class to inherit the attributes and methods of another class, while polymorphism allows a
class to have different behaviors depending on the context. However, these concepts also come with some
challenges, such as the diamond problem and the fragile base class problem