Module-1:

LECTURE-1

Introduction:
Programmers write instructions in various programming languages to perform their computation
tasks such as:
(i) Machine level Language
(ii) Assembly level Language
(iii) High level Language

Machine level Language :

Machine code or machine language is a set of instructions executed directly by a computer's central
processing unit (CPU). Each instruction performs a very specific task, such as a load, a jump, or an
ALU operation on a unit of data in a CPU register or memory. Every program directly executed by a
CPU is made up of a series of such instructions.

Assembly level Language :

An assembly language (or assembler language) is a low-level programming language for a computer,
or other programmable device, in which there is a very strong (generally one-to-one) correspondence
between the language and the architecture's machine code instructions. Assembly language is
converted into executable machine code by a utility program referred to as an assembler; the
conversion process is referred to as assembly, or assembling the code.

High level Language :

High-level language is any programming language that enables development of a program in much
simpler programming context and is generally independent of the computer's hardware architecture.
High-level language has a higher level of abstraction from the computer, and focuses more on the
programming logic rather than the underlying hardware components such as memory addressing and
register utilization.

The first high-level programming languages were designed in the 1950s. Now there are dozens of
different languages, including Ada , Algol, BASIC, COBOL, C, C++, JAVA, FORTRAN, LISP,
Pascal, and Prolog. Such languages are considered high-level because they are closer to human
languages and farther from machine languages. In contrast, assembly languages are considered low-
level because they are very close to machine languages.

The high-level programming languages are broadly categorized in to two categories:

(iv) Procedure oriented programming(POP) language.

(v) Object oriented programming(OOP) language.

5
1 P.T.O
Procedure Oriented Programming Language

In the procedure oriented approach, the problem is viewed as sequence of things to be done such as
reading , calculation and printing.

Procedure oriented programming basically consist of writing a list of instruction or actions for the
computer to follow and organizing these instruction into groups known as functions.

Main program

Function-1 Function-2 Function-3

The disadvantage of the procedure oriented programming languages is:

1. Global data access
2. It does not model real word problem very well
3. No data hiding

Global data Global data

Function-1 Function-2 Function-3

Local data Local data Local data

Characteristics of procedure oriented programming:

1. Emphasis is on doing things(algorithm)

2. Large programs are divided into smaller programs known as functions.
3. Most of the functions share global data
4. Data move openly around the system from function to function
5. Function transforms data from one form to another.
6. Employs top-down approach in program design

6
2 P.T.O
 LECTURE-2

Object Oriented Programing

“Object oriented programming as an approach that provides a way of modularizing programs by

creating partitioned memory area for both data and functions that can be used as templates for
creating copies of such modules on demand”.

Object A Object B

Data Data

Communication

Functions Functions

Object-Oriented Programming
(OOP) is a programming paradigm Object C
that relies on the concept of
classes and objects. It is used to
structure a software program into
simple, reusable pieces of code
Functions
blueprints (usually called classes),
which are used to create individual
instances of objects.
Data

Features of the Object Oriented programming

1. Emphasis is on doing rather than procedure.

2. programs are divided into what are known as objects.
3. Data structures are designed such that they characterize the objects.
4. Functions that operate on the data of an object are tied together in the data
structure.
5. Data is hidden and can’t be accessed by external functions.
6. Objects may communicate with each other through functions.
7. New data and functions can be easily added.
8. Follows bottom-up approach in program design.

7
3 P.T.O
Element of Object Oriented Approach

The object-oriented approach revolves around organizing software design around data, or
objects, rather than functions and logic. Here are the key elements:

1.Classes: A blueprint or template for creating objects. It defines attributes (data) and methods
(functions) that the objects created from the class will have.
Example: In a class `Car`, attributes might be `color`, `model`, and `year`, while
methods might be `start()` and `drive()`.

2. Objects: Instances of a class. Once a class is defined, you can create objects from that
class. Each object can have its own state but shares the class's structure.

Example: `myCar = Car("red", "Toyota", 2020)` creates an object from the `Car` class.

3. Encapsulation: Bundling the data (attributes) and the methods that operate on the data
within a single unit (class) and restricting access to some of the object’s components. It
protects an object's internal state and only allows modification through public methods.

Example: Using private attributes (e.g., `_speed`) and public getter/setter methods (e.g.,
`get_speed()`).

4. Abstraction: Hiding the complexity of certain processes and exposing only the essential
features. It allows users to interact with the object without needing to know the internal
implementation details.

Example: A car’s `drive()` method abstracts the complex mechanics of operating a car
engine.

5. Inheritance: Mechanism by which one class (child) can inherit properties and methods from
another class (parent). This promotes code reuse and establishes a hierarchy between classes.

Example: A class `ElectricCar` can inherit from the `Car` class, adding additional attributes
like `battery_life` while reusing the attributes and methods of `Car`.

6. Polymorphism: Ability of different classes to respond to the same method call in different
ways. This can happen through method overriding (redefining a parent class's method in the
child class) or method overloading (multiple methods with the same name but different
parameters).

Example: Both `Car` and `ElectricCar` may have a `drive()` method, but they can
implement it differently.

4
Element of Object Oriented Approach

7. Composition: A design principle where one class contains an instance of another class,
allowing objects to be built from smaller, reusable parts.

Example: A `Garage` class might have a list of `Car` objects as its components.

These elements help in building scalable, maintainable, and modular software by modeling
real-world entities and interactions.

In Object-Oriented Programming (OOP), function and behavior are not considered primary
elements but are intrinsic to how objects and classes operate:

1. Functions(or methods in OOP terminology) are part of classes and objects. They define the
operations or actions that an object can perform. Methods allow objects to interact with other
objects or manipulate their own data. However, they are not considered a core "element" of
OOP in the same way as classes, objects, inheritance, etc., but they are crucial to the
functionality of those elements.

2. Behavior refers to how an object reacts to messages or function calls and interacts with other
objects. It's often described through the methods defined in a class. While behavior is a
consequence of OOP (i.e., what objects do), it is not considered a formal element like
encapsulation or inheritance.

In summary, functions (methods) are a key part of implementing OOP, and behavior is the
outcome of how objects interact and respond, but neither are core "elements" of OOP
themselves. They are more like properties or outcomes of objects and classes.

5
Features of Object-Oriented Approach

1. Encapsulation
Definition: Encapsulation involves bundling the data (attributes) and methods
(functions) that operate on that data within a class, while restricting access to some of
the object’s components.

Benefit: It protects the internal state of an object and promotes modularity.

Example: Private variables in a class that are accessed through public methods like
`getName()`.

2. Abstraction
Definition: Abstraction focuses on simplifying complex systems by modeling only
essential details, leaving out the intricate underlying implementation.

Benefit: Simplifies interactions with objects by hiding unnecessary complexity.

Example: A `Car` class could provide a `drive()` method without exposing the
complexities of the engine mechanics.

3. Inheritance
Definition: Inheritance allows one class (child or subclass) to inherit attributes and
methods from another class (parent or superclass). This promotes code reuse and
helps model hierarchical relationships.

Types of Inheritance:
Single Inheritance: A class inherits from one superclass.

Example: `Dog` class inherits from `Animal`.

Multiple Inheritance: A class inherits from more than one superclass (though not all
languages support this, such as Java).

Example: `FlyingCar` class inherits from both `Car` and `Airplane` classes.

Multilevel Inheritance: A class inherits from a class that is itself derived from another
class.

Example: `Poodle` inherits from `Dog`, which inherits from `Animal`.

6
 Hierarchical Inheritance: Multiple classes inherit from the same superclass.

Example: `Dog` and `Cat` both inherit from `Animal`.

Hybrid Inheritance: A combination of two or more types of inheritance, usually

involving multilevel and multiple inheritance.

Example: A `FlyingCar` class might inherit attributes and behaviors from both a
`Car` and an `Airplane` class, combining different inheritance styles.

Benefit: It promotes code reuse and establishes clear relationships between classes.

Example: A `Truck` class can inherit common properties like `wheels` and `engine`
from a `Vehicle` superclass.

4. Polymorphism (same as the previous definition

Definition: Polymorphism allows methods to do different things based on the object
that is invoking them. It can be implemented using method overloading or method
overriding.

Benefit: It promotes flexibility by allowing the same interface to handle different types
of objects.

Example: Both `Dog` and `Bird` can inherit from `Animal` and implement their own
`makeSound()` method, so calling `makeSound()` on each object behaves differently.

5. Modularity
Definition: Modularity refers to breaking down the program into self-contained units
(classes/objects) that can be developed and tested independently.

Benefit: It increases maintainability, as each part of the system can be worked on

separately.

Example: A `User` class can be developed independently from a `Payment` class in

a shopping system.

6. Message Passing
Definition: In OOP, objects communicate with each other through method calls or
message passing. One object sends data to another object by invoking methods, which
process the data.

Benefit: Promotes loose coupling between objects.

7
 Example: A `User` object calling a `sendMessage()` method on a `Chat` object to
send a message.

7. Dynamic Binding (Late Binding)

Definition: Dynamic binding refers to the process of determining which method to
invoke at runtime, depending on the object being referenced.

Benefit: Allows flexibility by delaying the method-binding decision until runtime.

Example: A variable of type `Animal` may refer to a `Dog` or `Cat` object, and the
correct version of `makeSound()` is determined at runtime.

8. Reusability
Definition: OOP encourages the reuse of code across different parts of a project or
even across different projects.

Benefit: Saves development time by reducing code duplication.

Example: A `Logger` class can be reused across various projects that require logging
functionality.

9. Scalability and Maintainability

Definition: OOP allows for scalable systems that can easily grow as the requirements
expand. Adding new features or updating old ones becomes simpler with OOP.

Benefit: It makes complex software easier to maintain and extend over time.

Example: Adding a new `Bicycle` class to a transportation system that already

includes `Car` and `Truck` without affecting existing functionality.

---

By incorporating these features and inheritance types, the object-oriented approach

becomes a highly flexible, modular, and scalable paradigm that promotes software
reuse and easier maintenance.

8
Object modelling technique:
Object Modelling Technique (OMT) is a method used in object-oriented software
development to model and design systems. It focuses on representing systems as a
collection of objects that interact with one another.

When discussing object-oriented modeling (OOM), three primary types of models are
commonly used to represent different aspects of a system. These models work together
to give a holistic view of how the system is structured, behaves, and interacts. The three
types are:

Three kinds of model:

1. Object Model (Static Model): Represents the static structure of the system, focusing
on the objects, their attributes, methods, and relationships.

What it Includes:

Classes: Blueprints of objects with attributes and methods.

Objects: Instances of classes with specific data.

Relationships: How objects interact or are related to each other (e.g., association,
aggregation, composition).

Class Diagrams: Used to visualize the relationships between classes and objects in a
system.

Example:

In a **Library Management System**, the object model would define classes such as
`Book`, `Member`, and `Loan`, their attributes like `title`, `name`, `dueDate`, and
their relationships like “a `Member` borrows a `Book`.”

Key Diagrams:

Class Diagrams

Object Diagrams

2. Dynamic (Interaction or Behavioral) Model: Represents the dynamic behavior of the

system over time, focusing on how objects interact with one another through events and
changes in state.

9
What it Includes:

Interactions between objects: How messages are passed between objects (methods
and functions) in response to events.

States: The conditions of an object at a specific point in time.

State Transitions: How objects change from one state to another due to events or
methods being invoked.

-Example:

In the same **Library Management System**, the dynamic model would show how a
`Member` object sends a `borrow()` message to a `Book` object, changing its state
from `available` to `borrowed`.

Key Diagrams:

Sequence Diagrams: Visualize interactions between objects in a time sequence.

Activity Diagrams: Represent workflows and the dynamic behavior of the system.

State Diagrams: Show how objects move between different states based on events.

3. Functional Model (Use-Case Model): Represents the functionality of the system,

focusing on what the system does from the perspective of its users (external actors) and
how they interact with it.

What it Includes:

Use Cases: Descriptions of the functional requirements of the system from the user's
perspective.

Actors: External entities (people or systems) that interact with the system.

Scenarios: Specific paths or processes that describe how actors use the system to
accomplish tasks.

Example:

In a **Library Management System**, a use case could be “Borrow a Book,” involving

actors like `Member` and `Librarian`, and specifying the interactions needed to
complete the borrowing process.

Key Diagrams Use Case Diagrams: Depict the system's functionality by representing
use cases, actors, and their interaction.

10
Importance of Model:
Models play a crucial role in software development and system design, offering several
key benefits. Here’s a detailed explanation of the importance of models in object-
oriented modeling and software engineering:

1. Simplifying Complex Systems

Breakdown of Complexity: Models allow complex systems to be broken down into

smaller, more manageable parts. By focusing on individual components like objects,
behaviors, and functions, designers can work on one part of the system at a time
without being overwhelmed by the entire system's complexity.

Visualization: Modeling techniques (e.g., UML diagrams) visually represent these

complex systems, making them easier to understand, communicate, and explain to
both technical and non-technical stakeholders.

2. Improved Communication

Common Language: Models provide a shared language among developers, analysts,

stakeholders, and clients. Diagrams and models like class diagrams, use case
diagrams, and sequence diagrams are universally understood and help teams
communicate clearly about system requirements and design.

Requirements Gathering: Functional models (e.g., use case diagrams) help in gathering
and confirming requirements by showing what the system will do and how it will interact
with users and other systems.

3. Better System Design

Conceptualizing System Structure: Object models help define the overall structure of
the system, including classes, objects, attributes, and relationships. This facilitates a
deeper understanding of how different parts of the system will interact.

Modularity: Models promote modular design, allowing different parts of the system to
be designed and developed independently. This increases flexibility and makes future
enhancements or changes easier.

Encapsulation and Abstraction: Models focus on encapsulation (bundling data with

methods) and abstraction (simplifying complexity), leading to better, cleaner designs.

11
4. Easier Maintenance and Scalability

Maintainability: A well-modeled system is easier to maintain because the system’s

structure, behavior, and functionality are clearly documented. When changes need to
be made, developers can easily refer to the models to understand the impact of those
changes.

Scalability: Object models often use principles like inheritance and polymorphism,
which allow systems to scale efficiently. New features can be added with minimal
impact on existing code by extending classes or objects.

5. Early Detection of Issues

Error Detection: Models help identify potential issues and design flaws early in the
development process. By visualizing the system, developers can catch problems such
as mismatched data types, missing relationships, or unhandled edge cases before
writing any code.

Risk Reduction: By testing and validating the models, potential risks or challenges can
be identified early, reducing the chances of expensive errors or rework later in the
project lifecycle.

6. Reusability

Reusable Components: Object-oriented models allow for the reuse of classes, objects,
and patterns across different parts of the system or even in different projects. This
reduces duplication of effort and speeds up development.

Libraries and Frameworks: Once modeled and developed, classes can be reused as
part of libraries or frameworks in future projects, saving time and improving
consistency.

7. Better Planning and Documentation

Roadmap for Development: Models serve as a blueprint for system development,

guiding the developers through the process of building the system. They ensure that the
system adheres to the agreed-upon design and helps track progress.

Comprehensive Documentation: Models provide detailed documentation of the

system’s structure and behavior, which is valuable for future developers, maintainers,
and stakeholders. This ensures the longevity of the system and easier onboarding of
new team members.

12
8. Support for Automation and Code Generation

Automatic Code Generation: Some development tools and integrated development

environments (IDEs) can generate boilerplate code from models (e.g., from UML class
diagrams), reducing manual coding effort and human error.

Testing and Simulation: Models can also be used in automated testing and simulation
environments to verify the behavior of the system before actual implementation.

Principle of Model:
The principles of modeling are essential guidelines that help ensure that models are
effective, useful, and well-constructed. In object-oriented modeling, these principles
serve as the foundation for creating meaningful representations of systems. Here’s a
detailed explanation of key modeling principles:

1. Abstraction

Definition: Abstraction is the process of simplifying a complex system by focusing only

on the most essential details, while ignoring irrelevant ones.

Importance: This allows modelers to manage complexity by breaking down systems into
smaller, manageable parts. Abstraction hides unnecessary implementation details and
provides a clear, high-level view of the system.

Example: In a **Library Management System**, a model might represent a `Book`

object with key attributes like title, author, and ISBN, but leave out less important
details like the cover design or weight of the book.

2. Encapsulation

Definition: Encapsulation is the principle of bundling data (attributes) and behaviors

(methods) together within an object while restricting direct access to some of the
object’s components.

Importance: Encapsulation ensures that the internal state of an object is protected

from outside interference. It allows for controlled interaction through well-defined
interfaces (methods).

13
Example: A `BankAccount` class may encapsulate its balance attribute, allowing
external entities to interact with the account only through methods like `deposit()` or
`withdraw()`, rather than accessing the balance directly.

3. Modularity

Definition: Modularity is the principle of dividing a system into distinct modules or

components that can function independently but interact with each other.

Importance: It enhances maintainability, scalability, and reusability. Each module can

be developed, tested, and modified separately, leading to more flexible and
understandable systems.

Example: In a **Shopping Cart System**, the system may be divided into modules like
`Cart`, `Product`, `Payment`, and `User`. Each module can be independently
developed and reused in other systems if needed.

4. Hierarchy

Definition: Hierarchy is the principle of organizing objects or classes into a structure

that reflects relationships such as inheritance or aggregation.

Importance: It helps manage complexity by grouping related objects and defining

parent-child relationships. Inheritance allows subclasses to inherit common properties
from parent classes, promoting reuse and reducing redundancy.

Example: A **Vehicle** superclass might have common attributes like `make` and
`model`, while specific subclasses like `Car`, `Truck`, and `Motorcycle` inherit
those properties and define their own unique attributes or behaviors.

5. Reusability

Definition: Reusability is the principle of designing models, components, or objects in a

way that they can be used in multiple contexts without modification.

Importance: This reduces development time, effort, and redundancy by leveraging

existing code or models across different systems or projects.

Example: A `UserAuthentication` class developed for a social media platform can be

reused in an e-commerce platform, as long as the logic of authenticating users remains
the same.

14
 6. Consistency

Definition: Consistency refers to ensuring that all parts of the model follow the same
rules, conventions, and logic across the system.

Importance: Consistent models are easier to understand, maintain, and debug. They
minimize confusion and ensure that the system behaves predictably.

Example: If the model uses camelCase for method names (e.g., `getUserDetails()`), it
should consistently use camelCase throughout the system to maintain uniformaly.

10. Generalization and Specialization

Definition: Generalization refers to abstracting common features from multiple classes

into a superclass, while specialization refers to creating subclasses that inherit and
extend those common features with additional properties or behaviors.

Importance: This promotes reuse and reduces duplication by creating a general

framework that can be adapted for specific needs.

Example: In a **Banking System**, a general `Account` class may define common

attributes like account number and balance, while specialized classes like
`SavingsAccount` and `CheckingAccount` add specific features like interest
calculation or overdraft protection.
Object identity in C++ refers to the concept that every object in a program has its own unique identity, which
distinguishes it from other objects, even if the objects have the same type and contain the same data.

In C++, the identity of an object is tied to its memory address. Two objects of the same class or type may have the
same state (data members with identical values), but their identities are distinct because they reside at different
memory addresses.

Here’s an example to illustrate this:

15
Unified Modeling Language (UML) is a standardized visual modeling language that is a versatile, flexible,
and user-friendly method for visualizing a system’s design. Software system artifacts can be specified,
visualized, built, and documented with the use of UML.

Unified Modelling Language:

The UML is a graphical language for visualizing, specifying, constructing, and documenting the artifacts
of a software-intensive system. The UML gives you a standard way to write a system's blueprints,
covering conceptual things, such as business processes and system functions, as well as concrete things,
such as classes written in a specific programming language, database schemas, and reusable software
components.

Importance of modeling
A model is a simplification of reality. A model provides the blueprints of a system. A
model may be structural, emphasizing the organization of the system, or it may be
behavioral, emphasizing the dynamics of the system.

Aims of modeling
We build models so that we can better understand the system we are developing.

Through modeling, we achieve four aims.

1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in

its entirety.

Principles of Modeling
There are four basic principles of model

1. The choice of what models to create has a profound influence on how a problem
is attacked and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through
a small set of nearly independent models.

Object Oriented Modeling

In software, there are several ways to approach a model. The two most common ways are
1. Algorithmic perspective
2. Object-oriented perspective
Algorithmic Perspective

• The traditional view of software development takes an algorithmic perspective.

[Type here]
16
 • In this approach, the main building block of all software is the procedure or
function.
• This view leads developers to focus on issues of control and the decomposition of
larger algorithms into smaller ones.
• As requirements change and the system grows, systems built with an algorithmic
focus turn out to be very hard to maintain.

Object-Oriented Perspective
• The contemporary view of software development takes an object-oriented
perspective.
• In this approach, the main building block of all software systems is the object or
class.
• A class is a description of a set of common objects.
• Every object has identity, state, and behavior.
• Object-oriented development provides the conceptual foundation for assembling
systems out of components using technology such as Java Beans or COM+.

An Overview of UML
• The Unified Modeling Language is a standard language for writing software
blueprints. The UML may be used to visualize, specify, construct, and document
the artifacts of a software-intensive system.
• The UML is appropriate for modeling systems ranging from enterprise
information systems to distributed Web-based applications and even to hard real
time embedded systems. It is a very expressive language, addressing all the views
needed to develop and then deploy such systems.

The UML is a language for

• Visualizing CVSD-Constructing
• Specifying Visualizing
Specifing
• Constructing Documenting
• Documenting
• Visualizing The UML is more than just a bunch of graphical symbols. Rather,
behind each symbol in the UML notation is a well-defined semantics. In this manner,
one developer can write a model in the UML, and another developer, or even another
tool, can interpret that model unambiguously
• Specifying means building models that are precise, unambiguous, and complete.
• Constructing the UML is not a visual programming language, but its models can be
directly connected to a variety of programming languages
• Documenting a healthy software organization produces all sorts of artifacts in
addition to raw executable code. These artifacts include
o Requirements
o Architecture
o Design
o Source code
o Project plans
o Tests
o Prototypes
o Releases

[Type here]
17
 Conceptual model of UML

To understand the UML, you need to form a conceptual model of the language, and
this requires learning three major elements:

RCB • Basic building blocks of the UML

• Rules
• Common Mechanisms in the UML

Basic building blocks of the UML: Vocabulary of the UML can be defined

1. Things
2. Relationships
3. Diagrams

Things in the UML

There are four kinds of things in the UML: AB cricinfo

• Structural things SG cricket bat
• Behavioral things
• Grouping things
• Annotational things

Structural things are the nouns of UML models. These are the mostly static parts of a
model, representing elements that are either conceptual or physical. In all, there are
seven kinds of structural things.

1. Classes
I CAN CC U
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes

Class
• It is a description of a set of objects that share the same attributes, operations,
relationships, and semantics.
• A class implements one or more interfaces.
• Graphically, a class is rendered as a rectangle, usually including its name,
attributes, and operations.

Fig: Class

[Type here]
18
 Interface
• Interface is a collection of operations that specify a service of a class or
component.
• An interface therefore describes the externally visible behavior of that element.
• An interface might represent the complete behavior of a class or component or
only a part of that behavior.
• An interface is rendered as a circle together with its name. An interface rarely
stands alone. Rather, it is typically attached to the class or component that
realizes the interface.

IUnkonwn

Fig: Interface

Collaboration
• It defines an interaction and is a society of roles and other elements that work
together to provide some cooperative behavior that's bigger than the sum of all
the elements.
• Therefore, collaborations have structural, as well as behavioral, dimensions.
• A given class might participate in several collaborations.
• Graphically, a collaboration is rendered as an ellipse with dashed lines, usually
including only its name.

Fig: Collaboration

Use case
• Use case is a description of set of sequence of actions that a system performs that
yields an observable result of value to a particular actor
• Use case is used to structure the behavioral things in a model.
• A use case is realized by a collaboration. Graphically, a use case is rendered as an
ellipse with solid lines, usually including only its name

Fig: Use case

Active class
• It is just like a class except that its objects represent elements whose behavior is
concurrent with other elements.
• Graphically, an active class is rendered just like a class, but with heavy lines,
usually including its name, attributes, and operations.

[Type here]
19
 Fig: Active class

Component
• It is a physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces.
• Graphically, a component is rendered as a rectangle with tabs.

Fig: Component
Node
• It is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often, processing
capability.
• Graphically, a node is rendered as a cube, usually including only its name.

Fig: Node
Behavioral Things
• They are the dynamic parts of UML models. These are the verbs of a model,
representing behavior over time and space.
• In all, there are two primary kinds of behavioral things.
Interaction
State machine
Interaction
• Interaction is a behavior that comprises a set of messages exchanged among a set
of objects within a particular context to accomplish a specific purpose
• An interaction involves a number of other elements, including messages, action
sequences and links
• Graphically a message is rendered as a directed line, almost always including the
name of its operation

Fig: Message
State Machine
• State machine is a behavior that specifies the sequences of states an object or an
interaction goes through during its lifetime in response to events, together with its
responses to those events

[Type here]
20
 • State machine involves a number of other elements, including states, transitions,
events and activities
• Graphically, a state is rendered as a rounded rectangle, usually including its name
and its substates

Fig: State machine

Grouping Things
1. These are the organizational parts of UML models. These are the boxes into
which a model can be decomposed
2. There is one primary kind of grouping thing, namely, packages.

Package
• A package is a general-purpose mechanism for organizing elements into groups.
Structural things, behavioral things, and even other grouping things may be placed in
a package
• Graphically, a package is rendered as a tabbed folder, usually including only its name
and, sometimes, its contents.

Fig: Package
Annotational things
• These are the explanatory parts of UML models. These are the comments you may
apply to describe about any element in a model.
• There is one primary kind of Annotational thing, namely, note.

Note
• A note is simply a symbol for rendering constraints and comments attached to an
element or a collection of elements.
• Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a
textual or graphical comment.

Fig: Note

Relationships in the UML: There are four kinds of relationships in the UML:

1. Dependency
2. Association
3. Generalization
4. Realization

[Type here]
21
 Dependency

• Dependency is a semantic relationship between two things in which a change to one

thing may affect the semantics of the other thing
• Graphically a dependency is rendered as a dashed line, possibly directed, and
occasionally including a label.

Fig: Dependency

Association
• Association is a structural relationship that describes a set of links, a link being a
connection among objects.
• Graphically an association is rendered as a solid line, possibly directed, occasionally
including a label, and often containing other adornments, such as multiplicity and
role names.

Fig: Association
Generalization
• Generalization is a special kind of association, representing a structural relationship
between a whole and its parts.
• Graphically, a generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent.

Fig: Generalization

Realization
• Realization is a semantic relationship between classifiers, wherein one classifier
specifies a contract that another classifier guarantees to carry out.
• Graphically a realization relationship is rendered as a cross between a generalization
and a dependency relationship.

Fig: Realization

Diagrams in the UML

• Diagram is the graphical presentation of a set of elements, most often rendered as a

connected graph of vertices (things) and arcs (relationships).
• In theory, a diagram may contain any combination of things and relationships.
• For this reason, the UML includes nine such diagrams

[Type here]
22
 • Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• State chart diagram
• Activity diagram
• Component diagram
• Deployment diagram
Class diagram
• A class diagram shows a set of classes, interfaces, and collaborations and their
relationships.
• Class diagrams that include active classes address the static process view of a system.

Object diagram
• Object diagrams represent static snapshots of instances of the things found in
class diagrams
• These diagrams address the static design view or static process view of a system
• An object diagram shows a set of objects and their relationships

Use case diagram

• A use case diagram shows a set of use cases and actors and their relationships
• Use case diagrams address the static use case view of a system.
• These diagrams are especially important in organizing and modeling the
behaviors of a system.

Interaction Diagrams
• Both sequence diagrams and collaboration diagrams are kinds of interaction
diagrams
• Interaction diagrams address the dynamic view of a system
• A sequence diagram is an interaction diagram that emphasizes the time-ordering
of messages
• A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages
• Sequence diagrams and collaboration diagrams are isomorphic, meaning that you
can take one and transform it into the other.

Statechart diagram
• A state chart diagram shows a state machine, consisting of states, transitions,
events, and activities
• State chart diagrams address the dynamic view of a system
• They are especially important in modeling the behavior of an interface, class, or
collaboration and emphasize the event-ordered behavior of an object.

Activity diagram
An activity diagram is a special kind of a state chart diagram that shows the flow
from activity to activity within a system
Activity diagrams address the dynamic view of a system
They are especially important in modeling the function of a system and
emphasize the flow of control among objects.

[Type here]
23
 Component diagram
• A component diagram shows the organizations and dependencies among a set of
components.
• Component diagrams address the static implementation view of a system
• They are related to class diagrams in that a component typically maps to one or
more classes, interfaces, or collaborations.

Deployment diagram
• A deployment diagram shows the configuration of run-time processing nodes and
the components that live on them
• Deployment diagrams address the static deployment view of an architecture

Rules of the UML

The UML has semantic rules for
1. Names What you can call things, relationships, and diagrams
2. Scope The context that gives specific meaning to a name
3. Visibility How those names can be seen and used by others
4. Integrity How things properly and consistently relate to one another
5. Execution What it means to run or simulate a dynamic model

EXAMPLE OF OBJECT IDENTITY:

#include <iostream>
using namespace std;

class Example {
public:
int value;
Example(int val) : value(val) {}
};

int main() {
Example obj1(10); // Object 1
Example obj2(10); // Object 2 with the same value

// Print the values of obj1 and obj2

cout << "Value of obj1: " << obj1.value << endl;
cout << "Value of obj2: " << obj2.value << endl;

// Compare their identities (memory addresses)

cout << "Address of obj1: " << &obj1 << endl;
cout << "Address of obj2: " << &obj2 << endl;

if (&obj1 == &obj2) {
cout << "obj1 and obj2 have the same identity (same address)." << endl;
} else {
cout << "obj1 and obj2 have different identities (different addresses)." << endl;
}

return 0;
}

[Type here]
24
from java T point

Architecture Of UML:
• A system's architecture is perhaps the most important artifact that can be used to
manage these different viewpoints and so control the iterative and incremental
development of a system throughout its life cycle.
• Architecture is the set of significant decisions about
• The organization of a software system
• The selection of the structural elements and their interfaces by which the system is
composed
• Their behavior, as specified in the collaborations among those elements
• The composition of these structural and behavioral elements into progressively larger
subsystems
• The architectural style that guides this organization: the static and dynamic elements
and their interfaces, their collaborations, and their composition.
• Software architecture is not only concerned with structure and behavior, but also with
usage, functionality, performance, resilience, reuse, comprehensibility, economic and
technology constraints and trade-offs, and aesthetic concerns.

25
 Fig: Modeling a System's Architecture

Use case view

• The use case view of a system encompasses the use cases that describe the behavior
of the system as seen by its end users, analysts, and testers.
• With the UML, the static aspects of this view are captured in use case diagrams
The dynamic aspects of this view are captured in interaction diagrams, state chart
diagrams, and activity diagrams.

Design View
• The design view of a system encompasses the classes, interfaces, and collaborations
that form the vocabulary of the problem and its solution.
• This view primarily supports the functional requirements of the system, meaning the
services that the system should provide to its end users.

Process View
• The process view of a system encompasses the threads and processes that form the
system's concurrency and synchronization mechanisms.
• This view primarily addresses the performance, scalability, and throughput of the
system.

Implementation View
• The implementation view of a system encompasses the components and files that are
used to assemble and release the physical system.
• This view primarily addresses the configuration management of the system's releases,
made up of somewhat independent components and files that can be assembled in
various ways to produce a running system.

26
Deployment View
• The deployment view of a system encompasses the nodes that form the system's
hardware topology on which the system executes.
• This view primarily addresses the distribution, delivery, and installation of the parts
that make up the physical system.

27