UNIT– I

Introduction to UML: Importance of modelling, principles of modelling, object-oriented modelling,

conceptual model of the UML, Architecture, Software Development Life Cycle.

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.
Artifacts:
Artifacts are the tangible byproducts produced during the software development lifecycle. They
represent various forms of documentation, code, or other deliverables that are created and used
throughout the process.
These artifacts help in understanding, building, maintaining, and updating software systems.
Types of Software Artifacts:

Code:

Source code, compiled executables, libraries, and other code-related artifacts.

Documentation:

Requirements specifications, design documents, user manuals, API documentation, and other forms of
written or visual documentation.
Configuration Files:

Files that store settings and parameters that affect the behavior of the software.
Build Artifacts:

Artifacts produced by the build process, such as compiled code, libraries, and executables.
Test Artifacts:

Artifacts related to testing, such as test cases, test plans, and test results.
Project Management Artifacts:
Documents like project plans, risk assessments, and other project-related materials.

1
ACEM–CSE DEPARTMENT OOAD
Purpose of Artifacts:
Communication:

Artifacts facilitate communication and collaboration among developers, testers, stakeholders, and other
project participants.
Traceability:

They provide a clear record of the software development process, allowing for easier tracking of
changes, dependencies, and decisions.
Reusability:

Artifacts can be reused in different contexts or for future projects.

Maintenance and Evolution:

They serve as a reference for understanding the software's structure, functionality, and behaviour,
aiding in maintenance, updates, and bug fixes.
Knowledge Transfer:
Artifacts help transfer knowledge about the software to new team members or future maintainers.
Artifacts in Different Phases:
Planning Phase: Requirements documents, project plans, use case diagrams, etc.

Design Phase: Architecture diagrams, class diagrams, database schemas, etc.

Implementation Phase: Source code, build scripts, configuration files, etc.

Testing Phase: Test cases, test plans, test results, etc.

Deployment Phase: Installation scripts, deployment packages, etc.

Model

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.

Why do we need model

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.

2
ACEM–CSE DEPARTMENT OOAD
 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.

Importance of Modelling in UML

Modelling is crucial in Object-Oriented Analysis and Design (OOAD) because it simplifies
understanding, facilitates communication, and helps in building robust and maintainable systems.
Models allow developers to visualize the system, specify its structure, behavior, and document design
decisions.

[Link] Understanding and Communication:

a. Visualization:
Models, especially diagrams like UML diagrams, provide a visual representation of the system, making
it easier to grasp its complexity.

b. Abstraction:
Models can represent the system at different levels of abstraction, allowing developers to focus on
specific aspects without being overwhelmed by details.

c. Communication:
Models serve as a common language for communication between developers, stakeholders, and users,
bridging the gap between the technical design and the real-world problem.

2. Improved Design and Development:

a. Early Problem Detection:

Modeling allows for the identification of potential problems and inconsistencies in the design early in
the development process, reducing the risk of costly errors later on.

b. Template for Construction:

Models act as templates, guiding the construction of the system and ensuring consistency and
adherence to the design.

3
ACEM–CSE DEPARTMENT OOAD
 c. Reduced Development Time:
By providing a clear blueprint, models can streamline the development process and reduce the time
required to build the system.

d. Code Reusability:
Well-designed models can facilitate the creation of reusable components, leading to more efficient
development.

3. Increased Maintainability:

a. Well-Defined Structure:

Object-oriented modeling, with its focus on objects and their relationships, results in a more modular
and maintainable system.

b. Clear Documentation:
Models serve as living documentation of the system, making it easier to understand, modify, and
extend the system in the future.

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 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+.

4
ACEM–CSE DEPARTMENT OOAD
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
 Specifying
 Constructing
 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

To understand the UML, you need to form a conceptual model of the language, and this requires
learning three major elements:
1. Things
2. Relationships
3. Diagrams

5
ACEM–CSE DEPARTMENT OOAD
Things in the UML
There are four kinds of things in the UML:
Structural things
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
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes
Class: 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.

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

Collaboration: 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,

6
ACEM–CSE DEPARTMENT OOAD
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

Usecase :
 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

Active class :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

Component: 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

Node: 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

Behavioral Things 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

7
ACEM–CSE DEPARTMENT OOAD
 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

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
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

Grouping Things:-
Grouping things are the organizational parts of UML models. These are the boxes into which a model
can be decomposed
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

Annotational things: are the explanatory parts of UML models. These are the comments you may
apply to describe about any element in a model.

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

8
ACEM–CSE DEPARTMENT OOAD
Relationships in the UML: There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
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

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

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

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

Diagrams in the UML

9
ACEM–CSE DEPARTMENT OOAD
 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:
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Statechart 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

10
ACEM–CSE DEPARTMENT OOAD
Statechart diagram
 A statechart diagram shows a state machine, consisting of states, transitions, events, and
activities
 Statechart 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 statechart 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
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

Models built during the development of a software-intensive system tend to evolve and may be viewed
by many stakeholders in different ways and at different times. For this reason, it is common for the
development team to not only build models that are well-formed, but also to build models that are

1. Elided Certain elements are hidden to simplify the view

11
ACEM–CSE DEPARTMENT OOAD
 2. Incomplete Certain elements may be missing
3. Inconsistent The integrity of the model is not guaranteed

Common Mechanisms in the UML

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 that provides a textual statement of the syntax and semantics of that building block. The
UML's specifications provide a semantic backplane that contains all the parts of all the models of a
system, each part related to one another in a consistent fashion

Adornments Most elements in the UML have a unique and direct graphical notation that provides a
visual representation of the most important aspects of the element. A class's specification may include
other details, such as whether it is abstract or the visibility of its attributes and operations. Many of
these details can be rendered as graphical or textual adornments to the class's basic rectangular notation.

Extensibility Mechanisms
The UML's extensibility mechanisms include
1. Stereotypes
2. Tagged values
3. Constraints
Stereotype
 Stereotype extends the vocabulary of the UML, allowing you to create new kinds of building blocks
that are derived from existing ones but that are specific to your problem
 A tagged value extends the properties of a UML building block, allowing you to create new
information in that element's specification
 A constraint extends the semantics of a UML building block, allowing you to add new rules or
modify existing ones

12
ACEM–CSE DEPARTMENT OOAD
Architecture
A system's architecture is 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
1. The organization of a software system
2. The selection of the structural elements and their interfaces by which the system is composed
3. Their behavior, as specified in the collaborations among those elements
4. The composition of these structural and behavioral elements into progressively larger subsystems
5. 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.

Vocabulary System Assembly

Functionality Configuration Mgmt

Design View Implementation

View

Use case
Behavior view

Process View Deployment view

Performance System topology

Scalability distribution delivery
Throughput installation

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

13
ACEM–CSE DEPARTMENT OOAD
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.
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.
Conceptual Model of UML:

14
ACEM–CSE DEPARTMENT OOAD
 Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC) is a structured process used in software engineering
to design, develop, test, and maintain software systems. It plays a crucial role in ensuring the
success and quality of software projects.

The various Phases of software development life cycle is

The Software Development Life Cycle (SDLC) consists of several well-defined phases, each
focusing on a specific aspect of software creation. These phases help in the systematic development and
maintenance of high-quality software.

15
ACEM–CSE DEPARTMENT OOAD
✅ [Link] :

Requirement Gathering and Analysis

 Objective: Understand what the client needs.

 Activities: Meetings with stakeholders, gathering functional and non-functional requirements.
 Output: Software Requirement Specification (SRS) document.

✅ [Link] :

The Planning phase is the first and most critical stage in the SDLC. It lays the foundation for the
entire project by defining its scope, objectives, resources, and timeline.

Objective To ensure that the project is feasible, well-defined, and has a clear roadmap for successful
execution.

Output :

1. Project Plan Document

2. Feasibility Report
3. Budget and Schedule
4. Risk Management Plan
5. Initial Requirement Outline

✅ 3. Modelling :

System Design

 Objective: Convert requirements into a blueprint for building the system.

 Activities: Architectural design, UI design, database design, module design.
 Output: Design Documents (High-Level and Low-Level Design – HLD & LLD).

Implementation / Coding

 Objective: Actual development of the software based on design.

 Activities: Writing code using appropriate programming languages and tools.
 Output: Working software modules (source code).

16
ACEM–CSE DEPARTMENT OOAD
✅ 4. Testing:

 Objective: Ensure the software is error-free and meets the requirements.

 Activities: Unit testing, integration testing, system testing, user acceptance testing (UAT).
 Output: Test Reports, Bug Reports, and Verified Software.

✅ 5. Deployment:

 Objective: Make the software available for use.

 Activities: Releasing software into the production environment, configuration settings.
 Output: Deployed Software (Live System).

 Objective: Fix issues and update the software post-deployment.

 Activities: Bug fixing, adding new features, updating libraries, performance tuning.
 Output: Updated and stable software.

Importance of Software Development Life Cycle (SDLC) in UML

1. Structured Development Approach

 SDLC provides a systematic process for software development.

 Helps manage complexity by dividing the project into manageable phases (requirements,
design, coding, testing, deployment).

2. UML Integration at Every Phase

 UML diagrams support each SDLC phase with visual modeling.

o Use Case Diagrams – for requirements.
o Class and Component Diagrams – for design.
o Sequence and Activity Diagrams – for behavior and testing.

3. Improves Communication

 UML acts as a common visual language for developers, designers, testers, and stakeholders.
 Reduces misunderstandings and aligns team efforts across the SDLC.

4. Enhances Documentation

 SDLC ensures that UML diagrams are created and maintained systematically.

17
ACEM–CSE DEPARTMENT OOAD
  These diagrams serve as reliable documentation throughout the software’s lifecycle.

5. Supports Better Planning and Estimation

 SDLC phases help in setting clear goals and timelines.

 UML models help estimate resources, time, and cost more accurately.

6. Encourages Early Error Detection

 UML diagrams like sequence, activity, and state diagrams help simulate system behavior
early.
 Allows detection and correction of errors before implementation.

7. Ensures Quality and Maintenance

 Following SDLC with UML results in high-quality software.

 Visual models ease troubleshooting and future enhancements.

18
ACEM–CSE DEPARTMENT OOAD