INDEX

S.No Program Name Pg.No:

1. Phases in software development project, overview, need, coverage

of topics.
2. To assign the requirement engineering tasks.
3. To perform Analysis: Requirement analysis ,SRS
4. To perform the function oriented Diagrams: DFD and structured
chart.
5. To perform the users view analysis: Use case Diagram
6. To draw structural view diagram: Class Diagram, Object Diagram
7. To draw Behavioral view diagram: Sequence Diagram,
collaboration Diagram
8. To draw Behavioral view diagram: state -chart Diagram, Activity
Diagram
9. To draw implementation view Diagram : Component diagram
10. To draw the environmental view diagram: Deployment diagram
11. To perform various testing using the testing tool unit testing ,
integration testing
12. ATM Application
13. Railway Reservation System
14. E- Commerce
15. Banking System
16. Library management System

2
UML-Diagrams

The UML diagrams are categorized into structural diagrams, behavioral diagrams, and also
interaction overview diagrams. The diagrams are hierarchically classified in the following figure:

3
1. Structural Diagrams

Structural diagrams depict a static view or structure of a system. It is widely used in the documentation of
software architecture. It embraces class diagrams, composite structure diagrams, component diagrams,
deployment diagrams, object diagrams, and package diagrams. It presents an outline for the system. It
stresses the elements to be present that are to be modeled.

o Class Diagram: Class diagrams are one of the most widely used diagrams. It is the backbone of
all the object-oriented software systems. It depicts the static structure of the system. It displays the
system's class, attributes, and methods. It is helpful in recognizing the relation between different
objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show parts within the class. It
displays the relationship between the parts and their configuration that ascertain the behavior of the
class. It makes full use of ports, parts, and connectors to portray the internal structure of a structured
classifier. It is similar to class diagrams, just the fact it represents individual parts in a detailed
manner when compared with class diagrams.
o Object Diagram: It describes the static structure of a system at a particular point in time. It can be
used to test the accuracy of class diagrams. It represents distinct instances of classes and the
relationship between them at a time.
o Component Diagram: It portrays the organization of the physical components within the system.
It is used for modeling execution details. It determines whether the desired functional requirements
have been considered by the planned development or not, as it depicts the structural relationships
between the elements of a software system.
o Deployment Diagram: It presents the system's software and its hardware by telling what the
existing physical components are and what software components are running on them. It produces
information about system software. It is incorporated whenever software is used, distributed, or
deployed across multiple machines with dissimilar configurations.
o Package Diagram: It is used to illustrate how the packages and their elements are organized. It
shows the dependencies between distinct packages. It manages UML diagrams by making it easily
understandable. It is used for organizing the class and use case diagrams.

2. Behavioral Diagrams:

Behavioral diagrams portray a dynamic view of a system or the behavior of a system, which describes the
functioning of the system. It includes use case diagrams, state diagrams, and activity diagrams. It defines
the interaction within the system.

o State Machine Diagram: It is a behavioral diagram. it portrays the system's behavior utilizing
finite state transitions. It is also known as the State-charts diagram. It models the dynamic behavior
of a class in response to external stimuli.
o Activity Diagram: It models the flow of control from one activity to the other. With the help of an
activity diagram, we can model sequential and concurrent activities. It visually depicts the
workflow as well as what causes an event to occur.

4
 o Use Case Diagram: It represents the functionality of a system by utilizing actors and use cases. It
encapsulates the functional requirement of a system and its association with actors. It portrays the
use case view of a system.

3. Interaction Diagrams

Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object interactions and
also depicts the flow between various use case elements of a system. In simple words, it shows how objects
interact with each other and how the data flows within them. It consists of communication, interaction
overview, sequence, and timing diagrams.

⮚ UML-Relationship

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

Dependency

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

a dependency is displayed in the diagram editor as a dashed line with an open arrow that points from the
client to the supplier.

Association

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

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

A single teacher has multiple students.

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

A car cannot move without a wheel. But the wheel can be independently used with the bike, scooter, cycle,
or any other vehicle. The wheel object can exist without the car object, which proves to be an aggregation
relationship.

Generalization

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

Realization

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

Realization relationship is represented by a dashed line with a hollow arrowhead, which points from the
classifier to the given interface.

6
1. Phases in software development project, overview, need, coverage of topics
What is SDLC?
SDLC is a systematic process for building software that ensures the quality and correctness of the
software built. SDLC process aims to produce high-quality software that meets customer expectations.
The system development should be complete in the pre-defined time frame and cost. SDLC consists of a
detailed plan which explains how to plan, build, and maintain specific software. Every phase of the SDLC
life Cycle has its own process and deliverables that feed into the next phase. SDLC stands for Software
Development Life Cycle

SDLC Phases
The entire SDLC process divided into the following SDLC steps:

SDLC Phases

● Phase 1: Requirement collection and analysis

● Phase 2: Feasibility study
● Phase 3: Design
● Phase 4: Coding
● Phase 5: Testing
● Phase 6: Installation/Deployment
● Phase 7: Maintenance

Phase 1: Requirement collection and analysis

The requirement is the first stage in the SDLC process. It is conducted by the senior team members with
inputs from all the stakeholders and domain experts in the industry. Planning for the quality
assurance requirements and reorganization of the risks involved is also done at this stage.

This stage gives a clearer picture of the scope of the entire project and the anticipated issues,
opportunities, and directives which triggered the project.

Requirements Gathering stage need teams to get detailed and precise requirements. This helps companies
to finalize the necessary timeline to finish the work of that system.

Phase 2: Feasibility study

Once the requirement analysis phase is completed the next sdlc step is to define and document software
needs. This process conducted with the help of ‘Software Requirement Specification’ document also
known as ‘SRS’ document. It includes everything which should be designed and developed during the
project life cycle.

7
Phase 3: Design
In this third phase, the system and software design documents are prepared as per the requirement
specification document. This helps define overall system architecture.

This design phase serves as input for the next phase of the model.

Phase 4: Coding
Once the system design phase is over, the next phase is coding. In this phase, developers start build the
entire system by writing code using the chosen programming language. In the coding phase, tasks are
divided into units or modules and assigned to the various developers. It is the longest phase of the
Software Development Life Cycle process.

In this phase, Developer needs to follow certain predefined coding guidelines. They also need to
use programming tools like compiler, interpreters, debugger to generate and implement the code.

Phase 5: Testing
Once the software is complete, and it is deployed in the testing environment. The testing team starts
testing the functionality of the entire system. This is done to verify that the entire application works
according to the customer requirement.

Phase 6: Installation/Deployment
Once the software testing phase is over and no bugs or errors left in the system then the final deployment
process starts. Based on the feedback given by the project manager, the final software is released and
checked for deployment issues if any.

Phase 7: Maintenance
Once the system is deployed, and customers start using the developed system, following 3 activities occur

● Bug fixing – bugs are reported because of some scenarios which are not tested at all
● Upgrade – Upgrading the application to the newer versions of the Software
● Enhancement – Adding some new features into the existing software

8
2. To assign the requirement Engineering tasks

Requirements Engineering Tasks

• Seven distinct tasks

– Inception: During inception, the requirements engineer asks a set of questions to establish… –
A basic understanding of the problem – The people who want a solution – The nature of the
solution that is desired – The effectiveness of preliminary communication and collaboration
between the customer and the developer

– Elicitation : Problems of scope in identifying the boundaries of the system or specifying too
much technical detail rather than overall system objectives – Problems of understanding what is
wanted, what the problem domain is, and what the computing environment can handle
(Information that is believed to be "obvious" is often omitted) – Problems of volatility because
the requirements change over time

– Elaboration: During elaboration, the software engineer takes the information obtained during
inception and elicitation and begins to expand and refine it. Elaboration focuses on developing a
refined technical model of software functions, features, and constraints

– Negotiation: During negotiation, the software engineer reconciles the conflicts between what
the customer wants and what can be achieved given limited business resources. Requirements are
ranked (i.e., prioritized) by the customers, users, and other stakeholders

– Specification: A specification is the final work product produced by the requirements engineer.
It is normally in the form of software requirements specification .It serves as the foundation for
subsequent software engineering activities

– Validation: During validation, the work products produced as a result of requirements

engineering are assessed for quality

– Requirements Management: During requirements management, the project team performs a

set of activities to identify, control, and track requirements and changes to the requirements at
any time as the project proceeds .Each requirement is assigned a unique identifier. Some of these
tasks may occur in parallel and all are adapted to the needs of the project . All strive to define
what the customer wants. All serve to establish a solid foundation for the design and construction
of the software

9
3. To perform the System Analysis,Requirement Analysis and SRS

Requirements Analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine,
and scrutinize the gathered requirements to make consistent and unambiguous
requirements. This activity reviews all requirements and may provide a graphical view of
the entire system. After the completion of the analysis, it is expected that the
understandability of the project may improve significantly. Here, we may also use the

10
interaction with the customer to clarify points of confusion and to understand which
requirements are more important than others.

The various steps of requirement analysis are shown in fig:

Software Requirement Specifications

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire
requirements are elicited and analyzed. SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a system as well
as detailed specifications of the system requirements.

Characteristics of good SRS

11
1. Correctness: User review is used to provide the accuracy of requirements stated in the
SRS. SRS is said to be perfect if it covers all the needs that are truly expected from the
system.
2. Completeness: The SRS is complete if, and only if, it includes the following elements:
(1). All essential requirements, whether relating to functionality, performance, design,
constraints, attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but in
another as textual.
(b) One condition may state that all lights shall be green while another states that all lights
shall be blue.

12
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that
particular requirement.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.
9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal
notations and symbols should be avoided too as much extent as possible. The language
should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used.
Hence, the level of abstraction modifies according to the objective of the SRS.

13
4. To perform the function Oriented Diagram : Data flow diagram

Data Flow Diagrams

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where
data is stored.

The DFD is also called as a data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box
in a DFD, suppress that urge! A diamond-shaped box is used in flow charts to
represents decision points with multiple exists paths of which the only one is taken.
This implies an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

14
Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes
in a different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or
sink of system outputs.

The Level-0 DFD, also called context diagram of the result management system is shown
in fig. As the bubbles are decomposed into less and less abstract bubbles, the corresponding
data flow may also be needed to be decomposed.

15
5. To perform User view Analysis: Use case diagram

UML Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application. It depicts the high-
level functionality of a system and also tells how the user handles a system.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase online. The
top-level uses are as follows; View Items, Make Purchase, Checkout, Client Register. The View
Items use case is utilized by the customer who searches and view products. The Client Register
use case allows the customer to register itself with the website for availing gift vouchers, coupons,
or getting a private sale invitation. It is to be noted that the Checkout is an included use case, which
is part of Making Purchase, and it is not available by itself.

16
6. To draw Structural View Diagram :Class and Object Diagram

Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects
of a system but also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object
oriented systems because they are the only UML diagrams, which can be mapped directly
with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.
The following diagram is an example of an Order System of an application. It describes a
particular aspect of the entire application.
● First of all, Order and Customer are identified as the two elements of the system. They
have a one-to-many relationship because a customer can have multiple orders.
● Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
● The two inherited classes have all the properties as the Order class. In addition, they have
additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.

17
Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts are similar for class
diagrams and object diagrams. Object diagrams also represent the static view of a system but this
static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an instance
he following diagram is an example of an object diagram. It represents the Order management
system which we have discussed in the chapter Class Diagram. The following diagram is an
instance of the system at a particular time of purchase. It has the following objects.
● Customer
● Order
● Special Order
● Normal Order
Now the customer object (C) is associated with three order objects (O1, O2, and O3). These order
objects are associated with special order and normal order objects (S1, S2, and N1). The customer
has the following three orders with different numbers (12, 32 and 40) for the particular time
considered.
The customer can increase the number of orders in future and in that scenario the object diagram
will reflect that. If order, special order, and normal order objects are observed then you will find
that they have some values.
For orders, the values are 12, 32, and 40 which implies that the objects have these values for a
particular moment (here the particular time when the purchase is made is considered as the
moment) when the instance is captured
The same is true for special order and normal order objects which have number of orders as 20,
30, and 60. If a different time of purchase is considered, then these values will change accordingly.
The following object diagram has been drawn considering all the points mentioned above

18
7. To draw the behavioral view diagram :Sequence and Collaboration diagram
Sequence Diagram

The sequence diagram represents the flow of messages in the system and is also termed as an event
diagram. It helps in envisioning several dynamic scenarios. It portrays the communication between
any two lifelines as a time-ordered sequence of events, such that these lifelines took part at the run
time. In UML, the lifeline is represented by a vertical bar, whereas the message flow is represented
by a vertical dotted line that extends across the bottom of the page. It incorporates the iterations as
well as branching.

Notations of a Sequence Diagram

Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at
the top of the diagram.

Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the scope
of the system. It represents the role, which involves human users and external hardware or subjects.
An actor may or may not represent a physical entity, but it purely depicts the role of an entity.
Several distinct roles can be played by an actor or vice versa.

Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an
operation is performed by an element, such that the top and the bottom of the rectangle is associated
with the initiation and the completion time, each respectively.

19
Messages
The messages depict the interaction between the objects and are represented by arrows. They are
in the sequential order on the lifeline. The core of the sequence diagram is formed by messages
and lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an
interaction, which represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines of interaction

that represent the flow of information from the receiver of the corresponding caller
message.

o Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of the

20
 self message as it represents the recursive calls.

o Create Message: It describes a communication, particularly between the lifelines of an

interaction describing that the target (lifeline) has been instantiated.

o Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.

o Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

Note
A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.

21
An example of a high-level sequence diagram for online bookshop is given below.
Any online customer can search for a book catalog, view a description of a particular book,
add a book to its shopping cart, and do checkout.

Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a system. Both
the sequence and the collaboration diagrams represent the same information but differently.
Instead of showing the flow of messages, it depicts the architecture of the object residing in the
system as it is based on object-oriented programming. An object consists of several features.

22
Multiple objects present in the system are connected to each other. The collaboration diagram,
which is also known as a communication diagram, is used to portray the object's architecture in
the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the use
case.
3. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to another
object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and includes
a sequence number, so that the activity may take place. It is represented by a labeled arrow,
which is placed near a link. The messages are sent from the sender to the receiver, and the
direction must be navigable in that particular direction. The receiver must understand the
message.

23
 Components of a collaboration diagram

Actor

t 1.MESSAGE

24
8. To draw the behavioral diagram :State chart and activity diagram
State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram, which shows
the order of states underwent by an object within the system. It captures the software system's
behavior. It models the behavior of a class, a subsystem, a package, and a complete system.

It tends out to be an efficient way of modeling the interactions and collaborations in the external
entities and the system. It models event-based systems to handle the state of an object. It also
defines several distinct states of a component within the syste

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:

. Initial state: It defines the initial state (beginning) of a system, and it is represented by a black
filled circle.
a. Final state: It represents the final state (end) of a system. It is denoted by a filled circle
present within a circle.
b. Decision box: It is of diamond shape that represents the decisions to be made on the basis
of an evaluated guard.
c. Transition: A change of control from one state to another due to the occurrence of some
event is termed as a transition. It is represented by an arrow labeled with an event due to
which the change has ensued.

25
 d. State box: It depicts the conditions or circumstances of a particular object of a class at a
specific point of time. A rectangle with round corners is used to represent the state box.

Types of State

The UML consist of three states:

1. Simple state: It does not constitute any substructure.

2. Composite state: It consists of nested states (substates), such that it does not contain more
than one initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite state,
but it can be reused.

Example of a State Machine Diagram

An example of a top-level state machine diagram showing Bank Automated Teller Machine
(ATM) is given below.

Initially, the ATM is turned off. After the power supply is turned on, the ATM starts performing
the startup action and enters into the Self Test state. If the test fails, the ATM will enter into
the Out Of Service state, or it will undergo a triggerless transition to the Idle state. This is the
state where the customer waits for the interaction.
Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM state
changes from Idle to Serving Customer, the entry action readCard is performed after entering
into Serving Customer state. Since the customer can cancel the transaction at any instant, so the
transition from Serving Customer state back to the Idle state could be triggered
by cancel event.

26
Activity Diagram

In UML, the activity diagram is used to demonstrate the flow of control within the system rather
than the implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It put
emphasis on the condition of flow and the order in which it occurs. The flow can be sequential,
branched, or concurrent, and to deal with such kinds of flows, the activity diagram has come up
with a fork, join, etc.
It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of
actions or operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

27
Activities

The categorization of behavior into one or more actions is termed as an activity. In other words, it
can be said that an activity is a network of nodes that are connected by edges. The edges depict the
flow of execution. It may contain action nodes, control nodes, or object nodes.

The control flow of activity is represented by control nodes and object nodes that illustrates the
objects used within an activity. The activities are initiated at the initial node and are terminated at
the final node.

Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can be either
vertical or horizontal. It used to add modularity to the activity diagram. It is not necessary to
incorporate swimlane in the activity diagram. But it is used to add more transparency to the activity
diagram.

Forks

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one
inward edge and several outward edges. It is the same as that of various decision parameters.
Whenever a data is received at an inward edge, it gets copied and split crossways various outward
edges. It split a single inward flow into multiple parallel flows.

28
Join Nodes

Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the
inward edges as it synchronizes the flow of input across one single output (outward) edge.

Initial State: It depicts the initial stage or beginning of the set of actions.
Final State: It is the stage where all the control flows and object flows end.
Decision Box: It makes sure that the control flow or object flow will follow only one path.
Action Box: It represents the set of actions that are to be performed.

Example of an Activity Diagram

29
An example of an activity diagram showing the business flow activity of order processing is given
below.
Here the input parameter is the Requested order, and once the order is accepted, all of the required
information is then filled, payment is also accepted, and then the order is shipped. It permits order
shipment before an invoice is sent or payment is completed.

30
9. To draw the implementation view diagram :Component Diagram

Component Diagram

A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system such
as executables, files, libraries, etc. that resides within the node.

It visualizes the relationships as well as the organization between the components present in the
system. It helps in forming an executable system. A component is a single unit of the system,
which is replaceable and executable. The implementation details of a component are hidden, and
it necessitates an interface to execute a function. It is like a black box whose behavior is explained
by the provided and required interfaces.

Notation of a Component Diagram

a) A component

b) A node

31
Example of a Component Diagram

A component diagram for an online shopping system is given below:

32
10. To draw the environmental view Diagram: Deployment Diagram(Web Application)

33
11. To perform various testing using the testing tool Unit and Integration Testing

Unit Testing Levels

1. Unit tests help to fix bugs early in the development cycle and save costs.
2. It helps the developers to understand the testing code base and enables them to make changes
quickly
3. Good unit tests serve as project documentation
4. Unit tests help with code re-use. Migrate both your code and your tests to your new project.
Tweak the code until the tests run again.

Integration testing

Integration testing is the second level of the software testing process comes after unit testing. In
this testing, units or individual components of the software are tested in a group. The focus of the
integration testing level is to expose defects at the time of interaction between integrated
components or units.

Unit testing uses modules for testing purpose, and these modules are combined and tested in
integration testing. The Software is developed with a number of software modules that are coded
by different coders or programmers. The goal of integration testing is to check the correctness of
communication among all the modules.

34
Once all the components or modules are working independently, then we need to check the data
flow between the dependent modules is known as integration testing.

35
12. ATM Applications

36
 Models of ATM Applications:

1. Class:

37
2. Activity:

38
3. Collaboration:
sd CommunicationDiagraml )

7: Option Entered

14: Take Cash

Terminate

[ IJ I
+-

I
8: Request Amount I
12: Dispense Cash 5: PIN OK 1
11: Transaction Successf I
13: Request to take Cash
10: Process

[ Ace: Account

39
4. Component:

40
5. Deployment:

41
6. Sequence:

42
7. State Diagram:

43
8. Use case

44
13. RAILWAY RESERVATION SYSTEM

45
 RAILWAY RESERVATION SYSTEM

USECASE DIAGRAM

46
47
Class Diagram

48
SEQUENCE DIAGRAM:

sd SequenceDiagraml

1: login

!·«·: •••••••••••••••••••.l.& ] 2 : validate

3 : return status :

: Acknowledge

49
COLLABORATION DIAGRAM:

50
STATECHART DIAGRAM:

51
ACTIVITY DIAGRAM:

52
COMPONENT DIAGRAM:

53
DEPLOYMENT DIAGRAM:

54
14. E-commerce System

55
Oosd Assignment UML diagrams for E-
commerce System
Class diagram:

56
Object diagram:

57
Component diagram:

58
Deployment diagram:

59
Use case diagram:

60
Collaboration diagram:

61
Sequence diagram:

62
Activity diagram:

63
State chat diagram:

64
15. Banking System

65
Class Diagram

66
Object Diagram

67
Use Case Diagram

68
Sequence Diagram

69
Statechart Diagram

70
Deployment Diagram

71
Activity Diagram

72
Component Diagram

73
Collaboration Diagram

74
16. Library management system

75
 start

Studentl Faculty login

userid and password

Search Book

found book

Request Book

request librarian for book

Recieve Book

return back book

Return book and pay fine(if any)

pay the fine

Profile update and Signout

stop

•
= P Type here to search 1□=3 23
l ! : : -!l /\' ■I!!'/- DI f1i zr. ENG 06-11· 2 021
:Q 6 ll

76
Book
Librarian
+name +transld
+memberld
+bookld
issues +dateOflssue
+verifyMember
+dueDate
+issueBooksO

+createiBllO
+returnBookO

MembreRecord
+memberld Bill
+type
+billNo
+dateOfMembership
+date
+noBooklssued
+maxBooklimn +memberld
pays
+name +amount
+address +billCredit()
+phoneNo +billUpgradeO
+retrieveMemberO
+increaseBooklssuedO
Magzines +decreaseBooklssuedO
+payBillO

77
/ / / /

Client tier Web Tier

User
Web interface(asp.net
browser or jsp pages)

I/ /
/ /

Application Tier

Business
Logic
/
Data
Access
Data Tier
/

Stored
Procedures
/

78
«includ;e,•••

«include»

Librarian

79
1,, UML Class D,agram.mdJ - StarUML[UNREGISTERED) - CJ X
File Edit Format Model Tools View Window Debug Help

----------------

80
 Search
Transaction

81
• Component diagram mdJ - StarUML(UNREGISTERED) - CJ X
le Edit f ormat Model Tools View Window Debug Help

sd CommunicatioDniagraml
Member Record

t
er

5 : bo

d t
Librarian

;.;_ :update book status

I;
6:

Book

82
 L: LMS

+usertype = string
-username
-password

B: BOOK
U:USER +id = 809573 A: ACCOUNT
+name = "ReddyL" ------------------------- 7 +publisher= "Sam"
+issueDate = "21-03- 2021"
+id= 345 +edition = 3.5
+returnDate = "26-03-2021"
+branch ="MCA" +title = "java"
-mobileno

+department= "MCA"
LB: Librarian
+id= 8657
s: Student +name ="Stella"

+name ="Reddy"
+id= 9163864
+branch = "MCA" LOB: Library Database
+list of books= 27

= P Type heretosearch
"
A tJ g, ENG 1 91'.2
191-1 -2021
El.
-mJ

83
 CJ X
1, • Component diagrammdJ- StarUML(UNREGISTERED)

file Edit f ormat Model Tools View Window Debug Help

Librarian Memberrecord Transaciton

: 2 : get issuedate

84