Syllabus

Unit1: Introduction: The meaning of Object Orientation, object identity, Encapsulation, information hiding,
polymorphism, generosity, importance of modelling, principles of modelling, object-oriented modelling,
Introduction to UML, conceptual model of the UML, Architecture.
Unit2: Basic Structural Modelling: Classes, Relationships, common Mechanisms, and diagrams. Class
&Object Diagrams: Terms, concepts, modelling techniques for Class & Object Diagrams.
Collaboration Diagrams: Terms, Concepts, depicting a message, polymorphism in collaboration Diagrams,
iterated messages, use of self in messages. Sequence Diagrams: Terms, concepts, depicting asynchronous
messages with/without priority, call-back mechanism, broadcast messages.
Basic Behavioural Modelling: Use cases, Use case Diagrams, Activity Diagrams, State Machine, Process and
thread, Event and signals, Time diagram, interaction diagram, Package diagram.
Architectural Modelling: Component, Deployment, Component diagrams and Deployment diagrams

UNIT1

1. The Meaning of Object Orientation

Object Orientation (OO) is a programming paradigm based on the concept of "objects", which can contain data
and code. The primary characteristics of Object Orientation include:

• Objects: Represent entities with attributes (data) and behaviors (methods).

• Classes: Blueprints for creating objects, defining their structure and behavior.
• Inheritance: Mechanism to create new classes from existing ones.
• Polymorphism: Ability to process objects differently depending on their class.
• Encapsulation: Hiding the internal state of objects and requiring all interactions to be performed
through an object's methods.

2. Object Identity

Object Identity refers to the concept that each object has a unique identity that distinguishes it from other
objects, regardless of its state. Even if two objects have the same values for their attributes, they are still
different if they have different identities.

3. Encapsulation

Encapsulation is one of the fundamental principles of Object-Oriented Programming (OOP). It is the bundling
of data (attributes) and methods (behaviors) that operate on the data into a single unit or class. The internal
representation of an object is hidden from the outside world.

• Advantages:
o Protects object integrity by preventing outside interference.
o Simplifies the interface with which objects interact.
o Encourages modularity and maintenance.
• Example: A class Person may encapsulate data like name and age, along with methods like getName()
and setName() that control access to these variables.

4. Information Hiding

Information Hiding is closely related to encapsulation. It involves restricting access to certain parts of an
object to control how other objects interact with it. By hiding the internal details and only exposing what is
necessary, we increase security, reduce complexity, and ensure flexibility for future changes.

• Access Modifiers:
o Private: Accessible only within the class.
 o Protected: Accessible within the class and by derived classes.
o Public: Accessible by any other class.

5. Polymorphism

Polymorphism allows objects of different classes to be treated as objects of a common superclass. It’s the
ability to process objects differently depending on their class or data type.

• Types of Polymorphism:
o Compile-time Polymorphism: Achieved through method overloading or operator overloading.
o Run-time Polymorphism: Achieved through method overriding (inherited methods are
redefined in the subclass).
• Example: A Shape class with a method draw(). Different subclasses like Circle and Rectangle
implement draw() differently.

6. Generosity

Generosity, or Generalization, refers to the concept of designing more general and abstract classes that can
serve as templates for more specific subclasses. Generalization enables inheritance, where a subclass inherits
properties and behavior from a superclass.

• Example: A class Animal could be generalized from specific classes like Dog and Cat.

7. Importance of Modelling

Modelling in software engineering refers to creating abstract representations of real-world systems to better
understand and design them. It helps visualize complex systems and communicate the design to stakeholders.
Modeling has rich history in all the engineering disciplines. That experience suggests four basic principles of
modeling.

• Why Modelling is Important:

o Helps manage complexity.
o Enhances communication between developers and stakeholders.
o Provides a blueprint for system construction.
o Ensures that the system’s requirements are accurately captured and reflected in the design.

8. Principles of Modelling
Four principles of modelling:
o The choice of what models to create has a profound influence on how a problem is attacked & how a
solution is shaped.
 o Every model may be expressed at different levels of precision.
o The best models are connected to reality
o No single model is sufficient. Every non-trivial system is best approached through a small set of nearly
independent models.

There are several principles to guide the process of modelling:

• Abstraction: Simplifying a complex reality by modeling only relevant aspects.

• Accuracy: The model must reflect the real-world system or problem accurately.
• Consistency: The model should not contain contradictory elements.
• Clarity: The model should be easy to understand by all stakeholders.
• Flexibility: The model should be adaptable to changes in requirements or technology.

9. Object-Oriented Modelling

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. 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 Modelling (OOM) is the process of using object-oriented concepts to model a system. It uses
objects, classes, and their relationships to represent real-world entities and interactions within a system.

• Components of OOM:
o Objects: Represent real-world entities.
o Classes: Define the structure and behavior of objects.
o Inheritance: Allows new classes to reuse and extend existing classes.
o Associations: Define relationships between different objects.

10. Introduction to UML (Unified Modeling Language)

UML (Unified Modeling Language) is a standardized visual language for creating object-oriented models of
software systems. It is used for specifying, visualizing, constructing, and documenting the artifacts of a system.

• Common UML Diagrams:

o Class Diagram: Shows classes and relationships.
o Sequence Diagram: Depicts interactions between objects over time.
o Use Case Diagram: Describes the functionality provided by a system.
o Activity Diagram: Models workflows and processes.
o State Diagram: Shows states and transitions for an object.

11. Conceptual Model of the UML

The Conceptual Model of UML provides a framework for understanding the key elements involved in object-
oriented software development.
 • Key Elements:
o Things: Objects, classes, interfaces, components, and nodes.
o Relationships: Associations, dependencies, generalizations, and realizations.
o Diagrams: Visual representations like class diagrams, sequence diagrams, and use case
diagrams.

12. UML Architecture

The UML Architecture is based on the 4+1 View Model of software architecture, which organizes a software
system’s architecture into five different views:

1. Design view: 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. With the UML, the static aspects of
this view are captured in class diagrams and object diagrams; the dynamic aspects of this view are
captured in interaction diagrams, state diagrams, and activity diagrams. The internal structure diagram
of a class is particularly useful.
2. Implementation view: Focuses on the organization of the software into modules and components
assemble and release the physical system. This view primarily addresses the configuration management
of the system’s releases, made up of somewhat independent files that can be assembled in various ways
to produce a running system. It is also concerned with the mapping from logical classes and components
to physical artifacts. With the UML, the static aspects of this view are captured in artifact diagrams; the
dynamic aspects of this view are captured in interaction diagrams, state diagrams, and activity
diagrams.
3. Interaction view: Depicts the dynamic aspects, Shows the flow of control among its various parts,
including possible concurrency and synchronization mechanisms. This view primarily addresses the
performance, scalability, and throughput of the system. With the UML, the static and dynamic aspects
of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the
active classes that control the system and the messages that flow between them.
 4. Deployment view: 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. With the UML, the static aspects of this view are captured in
deployment diagrams; the dynamic aspects of this view are captured in interaction diagrams, state
diagrams, and activity diagrams.
5. Scenarios (Use Cases): Encompasses the use cases that describe the behavior of the system as seen by
its end users, analysts, and testers. This view doesn't really specify the organization of a software
system. Rather, it exists to specify the forces that shape the system's architecture. 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 diagrams, and activity diagrams.

UNIT2

Basic Structural Modelling

1. Classes

Classes are blueprints for creating objects. They define the properties (attributes) and behaviors (methods) that
an object created from the class will have.

• Terms:
o Attributes: Data fields (variables) of a class.
o Methods: Functions defined within a class that operate on the class's data.
o Visibility: Defines who can access certain attributes or methods (public, private, protected).

Modelling Techniques for Classes:

• A class is typically represented as a rectangle divided into three compartments:

1. Class Name: At the top.
2. Attributes: In the middle section.
3. Methods: In the bottom section.

Example:
 Person
Name: String

Age: int
Walk()

Talk()

2. Relationships

Relationships describe how classes and objects interact with each other.

• Types of Relationships:
1. Association: A general connection between classes, usually represented by a line.
2. Aggregation: A "whole-part" relationship, represented by a hollow diamond on the side of the
whole.
3. Composition: A stronger form of aggregation where the part cannot exist without the whole. It’s
represented by a filled diamond.
4. Inheritance (Generalization): Represents "is-a" relationships, shown by a line with a hollow
triangle pointing to the superclass.
5. Dependency: A weaker relationship indicating that one class uses another. It's represented by a
dashed line with an arrow.

Association: two-way associations, one-way associations, self-association , and multiple-number associations .

In a multiplicity relationship, you can add a number directly to the associated line to indicate the number of
objects in the corresponding class.
• 1..1: Only one
• 0..*: Zero or more
• 1..*:one or more
• 0..1: No or only one
• m..n: at least m, at most n (m<=n)

Aggregation: The relationship between the whole and part, and the whole and part can be separated.
Composition relationship: The relationship between the whole and the part, but the whole and the part cannot
be separated.

Inheritance: used to describe the relationship between parent and child classes.

Dependencies: Assume that a change in class A causes a change in class B, then say that class B depends on
class A.

Realization: Realization is a relationship between the blueprint class and the object containing its respective
implementation level details.
 Class Diagram Example: Order System

Class Diagram Example: University Management System

3. Common Mechanisms in UML

Common Mechanisms in UML provide ways to extend and structure models.

UML is made simpler by the presence of four common mechanisms that apply consistently throughout the
language.

1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms
Specification: Every UML element has a specification behind it, which defines its properties, behaviors, and
relationships. These specifications serve as a foundation for visual models, allowing consistency between the
design and the actual system.

Adornments:
These are additional symbols or decorations that provide further information about an element in UML
diagrams. For example, an arrow on an association to show navigation, or visibility markers (+, -, #) on class
attributes and methods to specify access control.

Common Divisions:
UML uses divisions like class vs. instance and type vs. role to differentiate between general templates and
specific objects. For example:
• A class represents a blueprint, while an object is an instance of that class.
• Type vs. role differentiates between the abstract nature of an entity (type) and the specific part it plays
in a particular context (role).

Extensibility Mechanisms:
(i) Stereotypes: Extend the vocabulary of UML by defining new model elements based on existing ones.
Example: In a component diagram, a stereotype «database» can indicate that a component represents a
database system.
The include relationship represents mandatory functionality that is factored out of a base use case into a
separate use case. This separate use case must be included wherever the base use case is executed.
The extend relationship is used to show optional or conditional behavior. A base use case may or may
not be extended with additional behavior depending on certain conditions.

(ii) Tagged Values: Add additional information to an element (metadata). Example: A Customer class
could have a tagged value {status="active"}.
(iii) Constraints: Impose conditions on elements, shown in curly braces {}. Example: In a class diagram, a
constraint on an Account class could specify that the balance must always be non-negative. Class:
Account {balance >= 0}

4. Diagrams in UML

Diagrams in UML are graphical representations of various aspects of the system.

• Structural Diagrams: Include class diagrams, object diagrams, component diagrams, and deployment
diagrams.
• Behavioral Diagrams: Include use case diagrams, activity diagrams, sequence diagrams, and
collaboration diagrams.
Class & Object Diagrams

1. Class Diagrams

Class Diagrams represent the static structure of the system, showing classes and relationships between them.

• Terms and Concepts:

o Classes are represented with their attributes and methods.
o Relationships between classes are depicted with lines (association, aggregation, inheritance).
• Modelling Techniques:
o Each class is represented as a box with three sections: class name, attributes, and methods.
o Association, aggregation, and composition are represented with lines, diamonds, and arrows.

Example:

Use cases of Class Diagrams

• System Design:

o During the system design phase, class diagrams are used to model the static structure of a
software system. They help in visualizing and organizing classes, their attributes, methods, and
relationships, providing a blueprint for system implementation.

• Communication and Collaboration:

o Class diagrams serve as a visual communication tool between stakeholders, including

developers, designers, project managers, and clients. They facilitate discussions about the
system’s structure and design, promoting a shared understanding among team members.

• Code Generation:

o Some software development environments and tools support code generation based on class
diagrams. Developers can generate code skeletons, reducing manual coding efforts and ensuring
consistency between the design and implementation.

• Testing and Test Planning:

o Testers use class diagrams to understand the relationships between classes and plan test cases
accordingly. The visual representation of class structures helps in identifying areas that require
thorough testing.

• Reverse Engineering:
 o Class diagrams can be used for reverse engineering, where developers analyze existing code to
create visual representations of the software structure. This is especially helpful when
documentation is scarce or outdated.

2. Object Diagrams

Object Diagrams show instances of classes (objects) and their relationships at a particular point in time. They
provide a snapshot of the system.

• Terms and Concepts:

o Objects are instances of classes, represented by rectangles with the object name and class
underlined as well as divided with a colon.
o Object attributes are Similar to classes, However, unlike classes, object attributes should have
values assigned for them.
o
• Modelling Techniques:
o Objects are named in the format objectName:ClassName.
o Relationships between objects are represented similarly to class diagrams.

Differences between Objects and Classes:

Class Diagram vs. Object Diagram:

• An object diagram is a UML structural diagram that shows the instances of the classifiers in models.
• Object diagrams use notation that is similar to that used in class diagrams.
• Class diagrams show the actual classifiers and their relationships in a system
• Object diagrams show specific instances of those classifiers and the links between those instances at a
point in time.
• You can create object diagrams by instantiating the classifiers in class, deployment, component, and
use-case diagrams.
•
Interaction Diagram are used in UML to establish communication between objects. It does not manipulate
the data associated with the communication path. Interaction diagrams mostly focus on message passing and
how these messages make up one functionality of a system. Interaction diagrams are designed to display how
the objects will realize the requirements of a system. The critical component in an interaction diagram is lifeline
and messages.
Types of Interaction diagram
Following are the different types of interaction diagrams defined in UML:
• Sequence diagram
• Collaboration diagram
• Timing diagram

Sequence Diagram: Depict the order of messages between objects over time. They emphasize the sequence
of messages rather than object relationships.

• Terms and Concepts:

o Lifeline: Represents the life of an object in the interaction.
o Activation Bar: Represents when an object is active or executing a process.
o Messages: Represented by arrows showing the flow of interaction.
• Depicting Asynchronous Messages:
o Asynchronous Messages are sent without waiting for a response, shown by a dashed arrow.
• Call-back Mechanism:
o Involves sending a message to an object, with the expectation of a response later.
• Broadcast Messages:
o A single message sent to multiple recipients simultaneously.

Messages
A message is a specific type of communication between two lifelines in an interaction. A message involves
following activities,
1. A call message which is used to call an operation.
2. A message to create an instance.
3. A message to destroy an instance.
4. For sending a signal.
When a lifeline receives a call message, it acts as a request to invoke an operation that has a similar
signature as specified in the message. When a lifeline is executing a message, it has a focus of control. As the
interaction progresses over time, the focus of control moves between various lifelines. This movement is
called a flow of control.
Following are the messages used in a System Interaction Diagram:
Message Name Meaning
Synchronous The sender of a message keeps waiting for the receiver to return control from the
message message execution.
Asynchronous The sender does not wait for a return from the receiver; instead, it continues the
message execution of a next message.
Return message The receiver of an earlier message returns the focus of control to the sender.
Object creation The sender creates an instance of a classifier.
Object destruction The sender destroys the created instance.
Found message The sender of the message is outside the scope of interaction.
Lost message The message never reaches the destination, and it is lost in the interaction.

• A sequence diagram shows an implementation of a scenario in the system. Lifelines in the system take
part during the execution of a system.
 • In a sequence diagram, a lifeline is represented by a vertical bar.
• A message flow between two or more objects is represented using a vertical dotted line which extends
across the bottom of the page.
• In a sequence diagram, different types of messages and operators are used .
• In a sequence diagram, iteration and branching are also used.

Branching
In an interaction diagram, we can represent branching by adding guard conditions to the messages. Guard
conditions are used to check if a message can be sent forward or not. A message is sent forward only when its
guard condition is true. A message can have multiple guard conditions, or multiple messages can have the same
guard condition. Branching in UML is achieved with the help of alt and opt, operators.
The ordered sequence of events in a given sequence diagram is as follows:

1. Place an order.
2. Pay money to the cash counter.
3. Order Confirmation.
4. Order preparation.
5. Order serving.

If one changes the order of the operations, then it may result in crashing the program. It can also lead to
generating incorrect or buggy results.

Sequence Diagram for cash withdrawal from an ATM

Benefits of a Sequence Diagram

• Sequence diagrams are used to explore any real application or a system.

• Sequence diagrams are used to represent message flow from one object to another object.
• Sequence diagrams are easier to maintain.
• Sequence diagrams are easier to generate.
• Sequence diagrams can be easily updated according to the changes within a system.
• Sequence diagram allows reverse as well as forward engineering.

Drawbacks of a sequence diagram

 • Sequence diagrams can become complex when too many lifelines are involved in the system.
• If the order of message sequence is changed, then incorrect results are produced.
• Each sequence needs to be represented using different message notation, which can be a little complex.
• The type of message decides the type of sequence inside the diagram.

Collaboration Diagrams:

Collaboration Diagrams are visual representations that depict interactions between objects to achieve a
particular goal in real time. They focus on object relationships and how objects send messages to one another.
These diagrams detail the roles, functionality, and behaviors of individual objects while also depicting the
overall operation of the system in a dynamic context.

• Terms and Concepts:

The four major components of a collaboration diagram include:
o Actors: These are instances that invoke the interaction in the diagram. Each actor has a name
and a role.
o Objects: Instances of classes involved in the interaction.
o Messages: Communication between objects, represented by arrows.
o Links: Lines connecting objects, showing relationships.

• Depicting Messages:
o Messages are numbered to show the order of operations.
o Arrows represent the direction of the message flow.
• Polymorphism in Collaboration Diagrams:
o Collaboration diagrams can illustrate polymorphism by showing different objects responding to
the same message in different ways.
• Iterated Messages:
o Messages can be iterated or looped, often represented with an asterisk *.
• Use of Self in Messages:
o An object can send a message to itself to perform internal operations.

Following diagram represents the sequencing over student management system:

The above collaboration diagram represents a student information management system. The flow of
communication in the above diagram is given by,
1. A student requests a login through the login system.
2. An authentication mechanism of software checks the request.
3. If a student entry exists in the database, then the access is allowed; otherwise, an error is returned.
Example: Collaboration diagram for hotel room booking

Benefits of Collaboration Diagram:

• It is also called as a communication diagram.

• It emphasizes the structural aspects of an interaction diagram – how lifeline connects.
• Its syntax is similar to that of sequence diagram except that lifeline don’t have tails.
• Messages passed over sequencing is indicated by numbering each message hierarchically.
• Compared to the sequence diagram communication diagram is semantically weak.
• Object diagrams are special case of communication diagram.
• It allows you to focus on the elements rather than focusing on the message flow as described in the
sequence diagram.
• Sequence diagrams can be easily converted into a collaboration diagram as collaboration diagrams are
not very expressive.
• While modeling collaboration diagrams w.r.t sequence diagrams, some information may be lost.

Drawbacks of a Collaboration Diagram

• Collaboration diagrams can become complex when too many objects are present within the system.
• It is hard to explore each object inside the system.
• Collaboration diagrams are time consuming.
• The object is destroyed after the termination of a program.
• The state of an object changes momentarily, which makes it difficult to keep track of every single
change the occurs within an object of a system.

Basic Behavioral Modelling

1. Use Cases

A Use Case is a description of a system’s behavior from an external user’s perspective. It focuses on the
interaction between a user (actor) and the system.

• Terms and Concepts:

o Actor: An entity that interacts with the system (e.g., a user, external system).
o Use Case: A specific functionality or process within the system.
• Use Case Diagram:
o Shows actors, use cases, and their relationships.
• Modelling Techniques:
o Use cases are depicted as ovals, and actors are represented as stick figures.

Example1:

Example2:
Example3: Railway reservation use case diagram example:

2. Activity Diagrams

Activity Diagrams model workflows and the flow of control between activities. Activity Diagrams describe
how activities are coordinated to provide a service which can be at different levels of abstraction. To show
workflow of complex use cases activity diagrams are needed

• Terms and Concepts:

o Activity: A specific task or function.
o Decision Points: Used to represent conditional branching.
o Fork/Join: Represent parallel processing.
• Modelling Techniques:
o Activities are represented by rounded rectangles.
o Decisions are shown as diamonds, with multiple outgoing paths.
o Forks and joins are shown as thick horizontal or vertical bars.
• Activity Diagram - Modeling a Word Processor
Activity diagram for ATM money withdrawal functionality with fork join construct
Activity Diagram Example - Student Enrolment:

Use case and Activity Diagram:

Use Case and Activity Diagram for the Online Shopping System

Browse Product Use Case with an Activity Diagram

Use Case Name: Browse Products

Actors: Customer

Basic Flow of Events:

1. The customer selects the “Browse Products” option from the main menu.
2. The system displays a list of all available products.
3. The customer can scroll through the list or use the search function to find specific products.
4. The customer can view product details, such as price, description, and images.
5. The customer can select a product to add it to their cart.
 Library Management System
Use case diagram

Class diagram
Sequence Diagram

Collaboration diagram

Activity diagram