JEPPIAARNAGAR, CHENNAI – 600119

STATE PRIVATE UNIVERSITY UNDER TAMILNADU STATE PRIVATE UNIVERSITY ACT 2019

CSE 128 – OBJECT ORIENTED SOFTWARE ENGINEERING

 MODULE 1

SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering - Software Process Models - Specialized Process Models - Introduction to Agility-

Agile Processes- Extreme Programming (XP)- XP Process and Case Study-Requirement Analysis and Specification -

Software Requirement Specification (SRS) - Formal System Specification-Finite State Machines and Petrinets-Object

Modeling Using UML - Use Case Modeling- Structural and Behavioral Modeling- Functional and Data Flow Modeling.

Introduction to Software Engineering

Software definition:
Definition1: Software is instructions (computer programs) that are intended to provide desired
Features, function, and performance;
Definition2: Software is a data structure that enables the programs to adequately manipulate information.

Characteristics of software are

1. Software is developed or engineered; it is not manufactured in the classical sense.
In both activities, high quality is achieved through good design, but the manufacturing phase
for hardware can introduce quality problems that are nonexistent for software
2. Software doesn’t “wear out.”
The failure rate curve for software should take the form of the “idealized curve” shown in
Figure. Undiscovered defects will cause high failure rates early in the life of a program. However, these
are corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual
failure models for software. However, the implication is clear—software doesn’t wear out.
 3. Although the industry is moving toward component-based construction, most software continues
to be custom built

Software Application Domains

Seven broad categories of computer software

1) System software—a collection of programs written to service other programs. Some system
software are compilers, editors, and assembler. The purpose of the sysem software is to establisha
communication with the hardware.
2) Applicationsoftware—stand-aloneprogramsthatsolveaspecificbusinessneed.
3) Engineering/scientificsoftware—hasbeencharacterizedby“numbercrunching”algorithms.
4) Embedded software—resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself.
5) Product-linesoftware—designedtoprovideaspecificcapabilityforusebymanydifferent customers.
6) Webapplications—called“WebApps,”thisnetwork-centricsoftwarecategoryspansawide array of
applications.
7) Artificialintelligencesoftware—makesuseofnonnumericalalgorithmstosolvecomplex problems
that are not amenable to computation or straightforward analysis
Legacy software systems:
Legacy software systems were developed decades ago and have been continually modified to meet
changes in business requirements and computing platforms.
A few simple realities to build software that is ready to meet the challenges of the twenty-first century
are:
1. Aconcertedeffortshouldbemadetounderstandtheproblembeforeasoftwaresolutionis developed.
2. Design becomes a pivotal activity
3. Software should exhibit high quality
4. Software should be maintainable
Softwareinallofitsformsandacrossallofitsapplicationdomainsshouldbe engineered.
Software engineering:
A definition proposed by Fritz Bauer is
[Software engineering is] the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.
The IEEE definition is:
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to
software. .
Software engineering is a layered technology.

1) Quality focus
A disciplined quality management is a backbone of software engineering technology.
2) Process layer:
The foundation for software engineering is the process layer. Process defines a framework that
must be established for effective delivery of software engineering technology.
3) Methods:
Software engineering methods provide the technical how-to’s for building software. Methods encompass
a broad array of tasks that include communication, requirements analysis, design modeling, program
construction, testing, and support.
4) Tools:
Software engineering tools provide automated or semi automated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another, a system for the
support of software development, called computer-aided software engineering, is established.

SOFTWAREPROCESS:

• A process is a collection of activities, actions, and tasks that are performed when some work
product is to be created.
• An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is
applied regardless of the application domain, size of the project, complexity of the effort, or degree
of rigor with which software engineering is to be applied.
• An action (e.g., architectural design) encompasses a set of tasks that produce a major work product
(e.g., an architectural design model).
 • A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a
tangible outcome.
• In the context of software engineering, a process is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach that enables the people doing the work(the
software team) to pick and choose the appropriate set of work actions and tasks. The intent is always
to deliver software in a timely manner and with sufficient quality to satisfy those who have
sponsored its creation and those who will use it.
A process framework establishes the foundation for a complete software engineering process by
identifying a small number of framework activities that are applicable to all software projects, regardless
of their size or complexity.
A generic process framework for software engineering encompasses five activities:
1) Communication:
Before any technical work can commence, it is critically important to communicate and collaborate with
the customer. The intent is to understand stakeholders’ objectives for the project and to gather requirements
that help define software features and functions.
2) Planning:
software project plan—defines the software engineering work by describing the technical tasks to be
conducted, the risks that are likely, the resources that will be required, the work products to be produced,
and a work schedule.
3) Modeling:
Software engineers will create models to better understand software requirements and the design that will
achieve those requirements.
4) Construction:
This activity combines code generation and the testing that is required uncovering errors in the code.
5) Deployment:
The software is delivered to the customer who evaluates the delivered product and provides feedback based
on the evaluation.
These five generic framework activities can be used during the development of small, simple programs, the
creation of large Web applications, and for the engineering of large, complex computer-based systems.
Umbrella activities:
Umbrella activities are applied throughout a software project and help a software team manage and control
progress, quality, change, and risk.
Typical umbrella activities include:
1) Software project tracking and control—allows the software team to assess progress against the
project plan and take any necessary action to maintain the schedule.
2) Risk management—assesses risks that may affect the outcome of the projector the quality of the
 product.
3) Softwarequalityassurance—definesandconductstheactivitiesrequiredtoensuresoftware quality.
4) A technical review—assesses software engineering work products in an effort to uncover and remove
errors before they are propagated to the next activity.
5) Measurement—defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders’ needs.
6) Software configuration management—manages the effects of change throughout the software
process.
7) Reusability management—defines criteria for work product reuse (including software components)
and establishes mechanisms to achieve reusable components.

8) Work product preparation and production—encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.
 PRESCRIPTIVE PROCESS MODELS (OR) LIFE CYCLE MODELS:

The process model can be defined as the abstract representation of process. The appropriate process
model can be chosen based on abstract representation of process. These process models will follow some
rules for correct usage.
It is called “prescriptive” model because they prescribe a set of process elements—framework
activities, software engineering actions, tasks, work products, quality assurance, and change control
mechanisms for each project. Each process model also prescribes a process flow (also called a work flow)
—that is the manner in which the process elements are interrelated to one another.

The Waterfall Model:

• The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential
approach to software development that begins with customer specification of requirements and
progresses through planning, modeling, construction, and deployment, culminating in ongoing
support of the completed software.
• The waterfall model is the oldest paradigm for software engineering.
• Inrequirementgatheringandanalysisphasethebasicrequirementsofthesystemmustbe understood by
software engineer, who is called analyst.
• Thedesignisanintermediatestepbetweenrequirementsanalysisandcoding.
Design focuses on:
1) Data Structure
2) Software architecture
3) Interface representation
4) Algorithm details
• Coding is a step in which design is translated into machine readable form.
• Testing begins when coding is done. The purpose of testing is to uncover errors, fix the bugs and
meet the customer requirements.
• Maintenance is the longest life cycle phase. The purpose of maintenance is when the system is
installed and put in practical use then error may get introduced, correcting such errors and putting it
in use.
Advantages:
1) The waterfall model is simple to implement
2) For implementation of small systems it is use full.
Problems in waterfall model:
1. Real projects rarely follow the sequential flow that the model proposes. Changes can cause
confusion as the project team proceeds.
2. It is difficult for the customer to state all requirements explicitly. The waterfall model requires
this and has difficulty accommodating the natural uncertainty that exists at the beginning of manyprojects.
3. The customer must have patience. A working version of the program(s) will not be available
until late in the project time span. A major blunder, if undetected until the working program is reviewed,
can be disastrous.

• V-Model: In each phase, testing will be done.

A variation in the representation of the water fall model is called the V-model.
• The V-model depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities. As a software team moves down the
left side of the V, basic problem requirements are refined into progressively more detailed and
technical representations of the problem and its solution.
 • Once code has been generated, the team moves up the right side of the V, essentially performing a
series of tests (quality assurance actions) that validate each of the models created as the team moved
down the left side.
• In reality, there is no fundamental difference between the classic life cycle and the V-model. The
V-model provides a way of visualizing how verification and validation actions are applied to earlier
engineering work.
Incremental Process Models
• The incremental model combines elements of linear and parallel process flows.
• The incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.
• The incremental model combines elements of linear and parallel process flows. The incremental
model applies linear sequences in a staggered fashion as calendar time progresses.
• Eachlinearsequenceproducesdeliverable“increments”ofthesoftwareinamannerthatis similar to the
increments produced by an evolutionary process flow.
When we can choose incremental:
1) When initials of software requirements are reasonably well defined
2) When the overall scope of the development effort precludes purely linear process.
3) When limited set of software functionality needed quickly.
 • The incremental model applies linear sequences in a staggered fashion as calendar time
progresses.
• For example, word-processing software developed using the incremental paradigm might deliver
basic file management, editing, and document production functions in the first increment; more
sophisticated editing and document production capabilities in the second increment; Spelling and
grammar checkinginthethirdincrement;andadvancedpagelayoutcapabilityinthe fourth increment. It
should be noted that the process flow for any increment can incorporate the prototyping paradigm.
• The first increment is often a core product. That is, basic requirements are addressed but many
supplementary features remain undelivered.
• The core product is used by the customer. As a result of use, a plan is developed for the next
increment. The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality. This process is repeated
following the delivery of each increment, until the complete product is produced.
• Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early increments
can be implemented with fewer people.
• If the core product is well received, then additional staff (if required) can be added to implement
the next increment. In addition, increments can be planned to manage technical risks.
Advantages:
1) Generatesworkingsoftwarequicklyandearlyduringthesoftwarelifecycle.

2) This model is more flexible–less costly to changes cope and requirements.

3) It is easier to test and debug during a small reiteration

4) In this model customer can respond to each built.

5) Lowers initial delivery cost.

6) Easier to manage risk because risky pieces are identified and handled during it’s iteration.

Disadvantages:
1) Needs good planning and design.

2) Needs a clear and complete definition of the whole system before it can be broken down and
built incrementally.
3) Total cost is higher than waterfall.
4)
 Evolutionary Process Models:
• Business and product requirements often change as development proceeds, making a straight line
path to an end product unrealistic; In such case, the iterative approach needs to be adopted. Evolutionary
process model is also called as iterative process model
• Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
Prototyping
• Software prototyping, refers to the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. It is an activity that can occur in software
development and is comparable to prototyping as known from other fields, such as mechanical engineering
or manufacturing.
• When we can choose Prototype:

o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o Thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofan operating
system
o When requirements are fuzzy.
o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o Thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofan operating
system
o When requirements are fuzzy
 o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o Thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofan operating
system
o When requirements are fuzzy
• The prototyping assists you and other stakeholders to better understand what is to be built when
requirements are fuzzy.
• The prototyping paradigm begins with communication. You meet with other stakeholders to define
the overall objectives for the software, identify whatever requirements are known, and outline areas where
further definition is mandatory.
• A prototyping iteration is planned quickly, and modeling (in the form of a “quick design” )occurs.
A quick design focuses on a representation of those aspects of the software that will be visible to end users
(e.g., human interface layout or output display formats).
• [Link] by
stakeholders, who provide feedback that is used to further refine requirements.

• Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the
same time enabling you to better understand what needs to be done
• Ideally, the prototype serves as a mechanism for identifying software requirements. If a working
prototype is to be built, you can make use of existing program fragments or apply tools (e.g., report
generators and window managers) that enable working programs to be generated quickly.
• In most projects, the first system built is barely usable. It may be too slow, too big, akward in use
or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version
in which these problems are solved.
• The prototype can serve as “the first system.” The one that Brooks recommends you throw away.
But this may be an idealized view. Although some prototypes are built as “throwaways,” others are
evolutionary in the sense that the prototype slowly evolves into the actual system.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the
actual system, and developers get to build something immediately.
Advantages:
1) Users are actively involved in the development

2) Sinceinthismethodologyaworkingmodelofthesystemisprovided,theusersgetabetter understanding
of the system being developed.
3) Errors can be detected much earlier.

4) Quicker user feedback is available leading to better solutions.

5) Missing functionality can be identified easily

 6) Confusing or difficult functions can be identified Requirements validation, Quick implementation
of, incomplete, but functional, application.

Disadvantages:
1) Stakeholders see what appears to be a working version of the software, unaware that the prototype
is held together has hazard, unaware that in the rush to get it working you haven’t considered
overall software quality or long-term maintainability.
2) Software engineer make implementation compromises in order to get a prototype working quickly.
3) An inappropriate operating system or programming language may be used simply because it is
available and known; an inefficient algorithm may be implemented simply to demonstrate
capability.
Usage of prototyping:
• Although problems can occur, prototyping can be an effective paradigm for software
Engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders should
agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at
least in part), and the actual software is engineered with an eye toward quality.

The Spiral Model.

• The spiral model is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the water fall model. It provides the potential for
rapid development of increasingly more complete versions of the software.
• The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
It has two main distinguishing features.
(1) One is a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.

(2) The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
 • A spiral model is divided into a set of framework activities defined by the software engineering
team. Each of the framework activities represents one segment of the spiral path.
• The spiral model is a realistic approach to the development of large-scale systems and software.
Because software evolves as the process progresses, the developer and customer better understand
and react to risks at each evolutionary level.
• The spiral model uses prototyping as a risk reduction mechanism but enables you to apply the
prototyping approach at any stage in the evolution of the product. It maintains the systematic
stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework
that more realistically reflects the real world.
• The spiral model demands a direct consideration of technical risks at all stages of the project and,
if properly applied, should reduce risks before they become problematic.

The functions of these four quadrants are discussed below-

• Objectives determination and identify alternative solutions (Concept development

projects): Requirements are gathered from the customers and the objectives are identified,
[Link] phase
are proposed in this quadrant.
 • Identify and resolve Risks (New product development projects): During this cond quadrant
all the possible solutions are evaluated to select the best possible solution. Then the risks
associated with that solution is identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, Prototype is built for the best possible solution.
• Develop next version of the Product (Product Enhancement projects): During the third
quadrant, the identified features are developed and verified through testing. At the end of the
third quadrant, the next version of the software is available.
• Review and plan for the next Phase (product Maintenance projects):In the fourth quadrant,
[Link],planningforthe next
phase is started.
Advantages:
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added a talaterdate.
• Software is produced early in the software lifecycle.
Disadvantages:
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.
Concurrent development Models
• The concurrent development model, sometimes called concurrent engineering, allows a software
team to represent iterative and concurrent elements of any of the process models.
• For example, the modeling activity defined for the spiral model is accomplished by invoking one
or more of the following software engineering actions: prototyping, analysis, and design.
• Figure provides a schematic representation of one software engineering activity within the
modeling activity using a concurrent modeling approach. The activity—modeling—may be in any one of
the states noted at any given time.
• Similarly, other activities, actions, or tasks (e.g., communication or construction) can be
represented in an analogous manner. All software engineering activities exist concurrently but reside in
different states.
• For example, early in a project the communication activity has completed its first iteration and exists
in the awaiting changes state. The modeling activity (which existed in the inactive state while initial
communication was completed, now makes a transition into the under development state.
• If the customer indicates that changes in requirements must be made, the modeling activity moves
from the under development state into the awaiting changes state.
• Concurrent modeling defines a series of events that will trigger transitions from state to state for
each of the software engineering activities, actions, or tasks.
• For example, during early stages of design (a major software engineering action that occurs during
the modeling activity), an inconsistency in the requirements model is uncovered. This generates
the event analysis model correction, which will trigger the requirements analysis action from the
done state into the awaiting changes state.
• Concurrent modeling is applicable to all types of software development and provides an accurate
picture of the current state of a project. Rather than confining software engineering activities,
actions, and tasks to a sequence of events, it defines a process network.
• Each activity, action, or task on the network exists simultaneously with other activities, actions, or
tasks. Events generated at one point in the process network trigger transitions among the states.
Advantages:
1) The concurrent development model, sometimes called concurrent engineering. It’s can be
represented schematically as a series of frame work activities, software engineering actions,
software engineering task and their associated states.
2) The concurrent process model defines a series of events that will trigger transition from state to
state for each of the software engineering activities and action or task.
3) The concurrent process model is applicable to all types of software development and provides an
accurate picture of the current state of a project.
 [Link]

Disadvantages:
1) The SRS must be continually updated to reflect changes.
2) It requires discipline to avoid adding too many new features too late in the project.

SPECIALIZED PROCESS MODELS

• Specialized process models take on many of the characteristics of one or more of the traditional
models. However, these models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen.
Component-Based Development
• Commercial off-the-shelf (COTS) software components, developed by vendors who offer the mas
products, provide targeted functionality with well-defined interfaces that enable the component to be
integrated into the software that is to be built.
• The component-based development model incorporates many of the characteristics of the spiral
model. It is evolutionary in nature, demanding an iterative approach to the creation of software.
 • However, the component-based development model constructs applications from prepackaged
software components.
• Modeling and construction activities begin with the identification of candidate components. These
components can be designed as either conventional software modules or object-oriented classes or
packages16 of classes.
• Regardless of the technology that is used to create the components, the component-based
development model incorporates the following steps (implemented using an evolutionary approach):
1) Available component-based products are researched and evaluated for the application domain in
question.
2) Component integration issues are considered.
3) Software architecture is designed to accommodate the components.

4) Components are integrated into the architecture.

5) Comprehensive testing is conducted to ensure proper functionality.
• The component-based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits. Your software engineering team can achieve a
reduction in development cycle time as well as a reduction in project cost if component reuse becomes part
of your culture.
Advantages:
• The component based development model leads to software re-used and re-usability provides a
number of tangible benefits.
• It leads to reduction in development cycle time.
• It leads to significant reduction in project cost.
• It leads to significant increase in productivity.
Disadvantages:
1) Customization
2) Problem to adapt a component
3) The integration of are usable component tint new component is also a major problem
4) Security is another major concern for the developers
5) Efficiency of the Software applications developed using CBD is also debatable.

The Formal Methods Model

• The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify, develop, and verify a computer-
based system by applying a rigorous, mathematical notation. A variation on this approach,
called clean room software engineering is currently applied by some software development organizations.
• When formal methods are used during development, they provide a mechanism for eliminating
many of the problems that are difficult to overcome using other software engineering paradigms.
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily—not
through ad hoc review, but through the application of mathematical analysis. When formal methods are
used during design, they serve as a basis for program verification and therefore enable you to discover and
correct errors that might otherwise go undetected.
Advantage:
• Although not a mainstream approach, the formal methods model offers the promise of defect-free
software.
Disadvantages:
1) Thedevelopmentofformalmodelsiscurrentlyquitetimeconsumingandexpensive.
2) Becausefewsoftwaredevelopershavethenecessarybackgroundtoapplyformalmethods, extensive
training is required.
3) It is difficult to use the models as a communication mechanism for technically un sophisticated
customers.

Aspect-Oriented Software Development

• Regardless of the software process that is chosen, the builders of complex software invariably
implement a set of localized features, functions, and information content. These localized software
characteristics are modeled as components (e.g., object oriented classes) and then constructed within the
context of a system architecture.
• As modern computer-based systems become more sophisticated (and complex), certain concerns
—customer required properties or areas of technical interest—span the entire architecture.

• Some concerns are high-level properties of a system (e.g., security, fault tolerance). Other concerns
affect functions (e.g., the application of business rules), while others are systemic (e.g., task synchronization
or memory management).
• When concerns cut across multiple system functions, features, and information, they are often
referred to as crosscutting concerns. Aspectual requirements define those crosscutting concerns that have
an impact across the software architecture.
• Aspect-oriented software development (AOSD), often referred to as aspect-oriented programming
(AOP), is a relatively new software engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects— “mechanisms beyond subroutines
and inheritance for localizing the expression of a crosscutting concern”
• A distinct aspect-oriented process has not yet matured. However, it is likely that such a process
willadoptcharacteristicsofbothevolutionaryandconcurrentprocessmodels.
 Technology in this current era is progressing faster than ever, enforcing the global software
[Link] ever-
changing environment, it is impossible to gather a complete and exhaustive set of software
requirements. Without these requirements, it becomes practically hard for any conventional software
model to work.
Agilewasspeciallydesignedtomeetstheneedsoftherapidlychangingenvironmentby embracing the
idea of incremental development and develop the actual final product.

Introduction to Agile Process:

• In1980’stheheavy weight, plan based software development approach was used to develop any
software product.

Agile Methodology:
When incremental delivery is coupled with other agile practices such as continuous unit testing and
pair programming then the cost of changes can be controlled.
The following graph represents the how the software development approach has astrong influence on
the development cost due to changes suggested.

• Inthisapproachtoomanythingsaredonewhichwerenotdirectlyrelatedtosoftwareproduct being
produced.
• If requirements get changed, then rework was essential. Hence new methods were proposed in
1990’s which are known as agile process.
• Theagileprocessislight-weightmethodswhicharepeople-basedratherthanplan-based methods.
• The agile process forces the development team to focus on software itself rather than design and
documentation.
• The agile process believes in iterative method.
• The aim of agile process is to deliver the working model of software quickly to the customer.
Conventional software Development Methodology:
• The conventional wisdom in software development is that the cost of change increases nonlinearly
as a project progresses.
• It is relatively easy to accommodate a change when a software team is gathering requirements. A
usage scenario might have to be modified, a list of functions may be extended, or a written
specification can be edited.
• As the progresses and if the customer suggest the changes during the testing phase of the SDLC
then to accommodate these changes the architectural design needs to be modified and ultimately
these changes will affect other phases of SDLC. These changes are actually costly to execute.
 Principles:
There are famous 12 principles used as agile principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shortest timescale.
4. Business people and developers must work together throughout the project.
5. [Link] need, and
trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote constant development. The sponsors, developers, and users should be
able to maintain a constant.
9. Continuousattentiontotechnicalexcellenceandgooddesignenhancesagility.
10. Simplicity the art of maximizing the amount of work not done is essential.
11. The team must be self–organizing teams for getting best architectures ,requirements ,and designs
emerge from
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly
Extreme programming:
Extreme programming (XP) is one of the best known agile processes.
XP values:
The set of five values that serve as a basis for all work performed as part of XP—communication,
simplicity, feedback, courage, and respect. Each of these values is used as a driver for specific XP activities,
actions, and tasks.
1. Communication:
To achieve effective communication between software engineers in order to covey
important concepts and to get continuous feedback.

2. Simplicity:
XP focuses on the current needs instead of future needs to incorporate in the design.
Hence the XP believes that the Software design should be simple.
3. Feedback:
 The feedback for the software product can be obtained from the developers of the software,
customers and other software team members.
4. Courage:
The strict adherence to certain XP practices require courage. The agile XP team must be
disciplined to design the system today, recognize the future requirements and make the
changes dramatically as per demand.
5. Respect:
By following the above states XP values the agile team can win the respect of the
stakeholders.
XP Process:
The extreme programming process is explained as follows-
• Customer specifies and priorities the system requirements. Customer becomes or of the important
members of development team. The developer and customer together prepare a story- card in
which customer needs are mentioned.

• The developer team then aims to implement the scenarios in the story-card.

• After developing the story-card the development team breaks down the total work in small tasks.
The efforts and the estimated resources required for these tasks are estimated.

• The customer priorities the stories for implementation. If the requirement changes then
sometimes unimplemented stories have to be discarded. Then release the complete software in
small and frequent releases.

• For accommodating new changes, new story-card must be developed.

• Evaluate the system a long with the customer.
 XP Principle Description

User story-cards Instead of creating a large requirement document user stories are
Written by the customer in which what they need is mentioned.
Release planning A release plan for overall project is
Prepared from which the iteration plan can be prepared for individual
iteration
Small releases The developer breaks down the user
Stories into small releases and a plan for releasing the small
Planning functionalities is prepared.

Iterative process Divide the development work into small iterations. Keep the iteration
of nearly constant length. Iterative development helps in quick or
agile development.
Standup The stand up meetings must be, conducted for the current out comes of
meetings the project.
Simple design Simple design always takes less time than the complex design. It is always
Good to keep the things simple to meet the current requirements
Spike solution For answering the tough technical
Problems create the spike solutions. The goal of these solutions should
Designing be to reduce the technical risks.
Refactoring Refactoring means reductions in the redundancy, elimination of
unused functionalities, redesign the obsolete designs. This will
Improve the quality of the project.
Customer The most essential requirement of the XP is availability of the
Coding availability Customer. In Extreme programming the customer not only helps
the developer team but it should be the part of the project.

Paired All the code to be included in the project must be coded by groups of
programming two people working at the same computer. This will increase the
quality of coding
Collective code By having collective code ownership approach the everyone
ownership contributes new ideas and not any single person becomes the
bottleneck of the project. Anyone can change any line of code to fix a
bug or to re factor.
Unit testing The test framework that contains automated test cases unit is used to
detdhbey cSohd
anemllk utm
haer cKo(kduemmau1stdboen@uignagil. unmt testing before its release.
 Applications of Extreme Programming (XP): Some of the projects that are suitable to
develop using XP model are given below:
• Small projects: XP model is very useful in small projects consisting of small teams as
face to face meeting is easier to achieve.
• Projects involving new technology or Research projects: This type of projects face
changing of requirements rapidly and technical problems. So XP model is used to
complete this type of projects.

Industrial XP:
The industrial XP (IXP) is an organic evolution of XP. It is customer- centric. It has expanded role for
customers, and its advanced technical practices.
Various new practices that are appended to XP to create IXP are as follows:
1. Readiness Assessment:
Prior to the initiation of an IXP project, the organization should conduct a readiness assessment.
(1) An appropriate development environment exists to support IXP
(2) The team should contain appropriate and skilled stakeholders
(3) The organization has a distinct quality program and supports continuous improvement
(4) The organizational culture will support the new values of an agile team.
(5) The broader project community will be populated appropriately.
2. Project Community:
Skilled and efficient people must be chosen as the agile team members for the success of the
project. The team is referred as the community when extreme programming approach is
considered. The project community consists of technologies, customers, and other stakeholder
who play the vital role for the success of the project. The role of the community members must be
explicitly defined.

3. Project charting:
[Link] means,
the IXP team assess whether the project satisfies the goals and objectives of the organization.
4. Test driven management:
For assessing the state of the project and its progress the industrial XP needs some measurable
[Link].
5. Retrospectives:
After delivering the software increment, the specialized review is conducted which is called as
retrospective. The intention of retrospective is to improve the industrial XP process.
 SOFTWARE REQUIREMENTS
The process of establishing the services that the customer requires from a system and the constraints under
which it operates and is developed Requirements may be functional or non-functional
➢ Functional requirements describe system services or functions
➢ Non-functional requirements are a constraint on the system or on the development process.
Types of requirements
1. User requirements
Statements in natural language (NL) plus diagrams of the services the system provides and its operational
constraints. Written for customers
2. System requirements
A structured document setting out detailed descriptions of the system services. Written as a contract between client
and contractor
3. Software specification
A detailed software description which can serve as a basis for a design or implementation. Written for developers

FUNCTIONAL AND NON-FUNCTIONAL COMPONENTS:

a) Functional requirements:
Functionality or services that the system is expected to provide.
Functional requirements may also explicitly state what the system shouldn‘t do. Functional requirements
specification should be:
➢ Complete: All services required by the user should be defined
➢ Consistent: should not have contradictory definition (also avoid ambiguity don‘t leave room for
different interpretations)
b) Examples:
The LIBSYS system
A library system that provides a single interface to a number of databases of articles in different libraries.
Users can search for, download and print these articles for personal study.
c) Non-Functional requirements
Requirements that are not directly concerned with the specific functions delivered by the system typically relate
to the system as a whole rather than the individual system features
Often could be deciding factor on the survival of the system (e.g. reliability, cost, response time)
d) Product requirements
e) Organizational requirements
k) Examples of process requirements
 Requirement Analysis and Specification
Definition:
➢ The process of defining user expectations to build a new software product or to modify an existing
one is known as requirement analysis.
➢ Sometimes known as requirement engineering requirements gathering, or requirements capture in
software engineering.
➢ The tasks that go into determining the needs or conditions to meet for a new or altered product, taking
into account the potentially conflicting requirements of the various stakeholders, and analyzing,
documenting, validating, and managing software or system requirements are all included in
requirements analysis.
➢ This exercise goes over all of the requirements and may provide a graphical representation of the
entire system. As a result, the project's understandability is predicted to improve significantly after
the study is completed.
➢ We may also leverage the contact with the customer to clear up any confusion and determine which
requirements are more crucial than others.

1. Requirements Gathering and Analysis

Requirements engineering (RE) refers to the process of defining, documenting, and maintaining requirements in
the engineering design process. Requirement engineering provides the appropriate mechanism to understand
what the customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable solution,
specifying the solution clearly, validating the specifications and managing the requirements as they are
transformed into a working [Link], requirement engineering is the disciplined application of proven
principles, methods, tools, and notation to describe a proposed system's intended behavior and its associated
constraints.

Requirement Engineering Process

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
 2.1 Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with the help of customers
and existing systems processes, if available.
Definition:
It is all about obtaining information from stakeholders. In other words, once the business analysis has
communicated with stakeholders for understanding their requirements, it can be described as elicitation. It can
also be described as a requirement gathering.
Requirement gathering can be done by communicating with stakeholders directly or by doing some research,
experiments. The activities can be planned, unplanned, or both.
➢ Planned activities include workshops, experiments.
➢ Unplanned activities happen randomly. Prior notice is not required for such activities.
➢ For example, you directly go to the client site and start discussing the requirements however there
was no specific agenda published in advance.

Following tasks are the part of elicitation:

➢ Prepare for Elicitation: The purpose here is to understand the elicitation activity scope, select the
right techniques, and plan for appropriate resources.
➢ Conduct Elicitation: The purpose here is to explore and identify information related to change.
➢ Confirm Elicitation Results: In this step, the information gathered in the elicitation session is
checked for accuracy.
We hope, you have got an idea about requirement elicitation by now. Let’s move on to the
requirements elicitation techniques.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also
resolve conflicts if any.

Problems of Requirements Gathering and Analysis

• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.
 2. Software Requirement Specification
Software requirement specification is a kind of document which is created by a software analyst after the
requirements collected from the various sources - the requirement received by the customer written in
ordinary language. It is the job of the analyst to write the requirement in technical language so that they can
be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition
diagrams (FDDs), data dictionaries, etc.

Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows
the flow of data through a system. The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of the preceding. The DFD is also known
as a data flow graph or bubble chart.
Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirements stage, the data dictionary should at least define customer data items, to ensure that
the customer and developers use the same definition and terminologies.
Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram,
often called an "E-R diagram." It is a detailed logical representation of the data for the organization and uses
three main constructs i.e. data entities, relationships, and their associated attributes.

2.1 Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are validated. The user
might demand illegal, impossible solution or experts may misinterpret the needs. Requirements can be the
check against the following conditions -
• If they can practically implement
• If they are correct and as per the functionality and specially of software
• If there are any ambiguities
• If they are full
• If they can describe

2.2 Requirements Validation Techniques

Requirements reviews/inspections: systematic manual analysis of the requirements.
Prototyping: Using an executable model of the system to check requirements.
Test-case generation: Developing tests for requirements to check testability.
Automated consistency analysis: checking for the consistency of structured requirements
descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the requirements engineering
process and system development.
New requirements emerge during the process as business needs a change, and a better understanding of the
system is developed.
The priority of requirements from different viewpoints changes during development process. The business and
technical environment of the system changes during the development.
 Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development project. Hence they should be
clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:
Functional Requirements: Functional requirements define a function that a system or system
element must be qualified to perform and must be documented in different forms. The
functional requirements are describing the behavior of the system as it correlates to the
system's functionality.
Non-functional Requirements: This can be the necessities that specify the criteria that can be
used to decide the operation instead of specific behaviors of the system. Non- functional
requirements are divided into two main categories:
Execution qualities like security and usability, which are observable at run time.
Evolution qualities like testability, maintainability, extensibility and scalability that embodied
in the static structure of the software system.

2.3 Requirements Gathering Techniques

There are several techniques available for elicitation, however, the commonly used techniques are explained
below:
1)Stakeholder Analysis
Stakeholders can include team members, customers, any individual who is impacted by the project or it can be a
supplier. Stakeholder analysis is done to identify the stakeholders who will be impacted by the system.
2)Brainstorming
This technique is used to generate new ideas and find a solution for a specific issue. The members included for
brainstorming can be domain experts, subject matter experts. Multiple ideas and information give you a
repository of knowledge and you can choose from different ideas.
This session is generally conducted around the table discussion. All participants should be given an equal amount
of time to express their ideas.
 Brainstorming technique is used to answer the below questions:
• What is the expectation of a system?
• What are the risk factors that affect the proposed system development and what to do to avoid that?
• What are the business and organization rules required to follow?
• What are the options available to resolve the current issues?
• What should we do so that this particular issue does not happen in the future?
Brainstorming can be described in the following phases:
There are some basic rules for this technique which should be followed to make it
a success:
• The time limit for the session should be predefined.
• Identify the participants in advance. One should include 6-8 members for the session.
• The agenda should be clear enough for all the participants.
• Clear expectations should be set with the participants.
• Once you get all the information, combine the ideas, and remove the duplicate ideas.
• Once the final list is ready, distribute it among other parties.
Benefits:
• Creative thinking is the result of the brainstorming session.
• Plenty of ideas in a short time.
• Promotes equal participation.
Drawbacks:
• Participants can be involved in debating ideas.
• There can be multiple duplicate ideas.
3)Interview
This is the most common technique used for requirement elicitation. Interview techniques should be used for
building strong relationships between business analysts and stakeholders. In this technique, the interviewer
directs the question to stakeholders to obtain information. One to one interview is the most commonly used
technique.
If the interviewer has a predefined set of questions then it’s called a structured interview.
If the interviewer is not having any particular format or any specific questions then it’s called an unstructured
interview.
For an effective interview, you can consider the 5 Why technique. When you get an answer to all your Whys then
you are done with your interview process. Open-ended questions are used to provide detailed information. In
this interviewee cannot say Yes or No only.
Closed questions can be answered in Yes or No form and also for areas used to get confirmation on answers.

Basic Rules:
• The overall purpose of performing the interviews should be clear.
• Identify the interviewees in advance.
• Interview goals should be communicated to the interviewee.
• Interview questions should be prepared before the interview.
• The location of the interview should be predefined.
The time limit should be described.
The interviewer should organize the information and confirm the results with the interviewees as soon as
possible after the interview.
Benefits:
• Interactive discussion with stakeholders.
• The immediate follow-up to ensure the interviewer’s understanding.
• Encourage participation and build relationships by establishing rapport with the stakeholder.
Drawbacks:
• Time is required to plan and conduct interviews.
• Commitment is required from all the participants.
• Sometimes training is required to conduct effective interviews.
4) Document Analysis/Review
This technique is used to gather business information by reviewing/examining the available materials that describe
the business environment. This analysis is helpful to validate the implementation of current solutions and is also
helpful in understanding the business need.
Document analysis includes reviewing the business plans, technical documents, problem reports, existing
requirement documents, etc. This is useful when the plan is to update an existing system. This technique is useful
for migration projects.
This technique is important in identifying the gaps in the system i.e. to compare the AS-IS process with the TO-
BE process. This analysis also helps when the person who has prepared the existing documentation is no longer
present in the system.
Benefits:
• Existing documents can be used to compare current and future processes.
• Existing documents can be used as a base for future analysis.
Drawbacks:
• Existing documents might not be updated.
• Existing documents might be completely outdated.
• Resources worked on the existing documents might not be available to provide information.
• This process is time-consuming.
5) Focus Group
By using a focus group, you can get information about a product, service from a group. The Focus group includes
subject matter experts. The objective of this group is to discuss the topic and provide information. A moderator
manages this session.
The moderator should work with business analysts to analyze the results and provide findings to the stakeholders.
If a product is under development and the discussion is required on that product then the result will be to update
the existing requirement or you might get new requirements. If a product is ready to ship then the discussion will
be on releasing the product.
How Focus groups are different than group interviews?
A Focus group is not an interview session conducted as a group; rather it is a discussion during which feedback
is collected on a specific subject. The session results are usually analyzed and reported. A focus group typically
consists of 6 to 12 members. If you want more participants then create more than one focus group.
Benefits:
You can get information in a single session rather than conducting one to one interview.
Active discussion with the participants creates a healthy environment.
One can learn from other’s experiences.
Drawbacks:
It might be difficult to gather the group on the same date and time.
If you are doing this using the online method then the participant’s interaction will be limited.
A Skilled Moderator is required to manage focus group discussions.

6) Interface Analysis
 Interface analysis is used to review the system, people, and processes. This analysis is used to identify how the
information is exchanged between the components. An Interface can be described as a connection between two
components. This is described in the below image: The interface analysis focus on the below questions:
Who will be using the interface?
What kind of data will be exchanged?
When will the data be exchanged?
How to implement the interface?
Why we need the interface? Can’t the task be completed without using the interface?
Benefits:
• Provide missed requirements.
• Determine regulations or interface standards.
• Uncover areas where it could be a risk for the project.
Drawbacks:
• The analysis is difficult if internal components are not available.
• It cannot be used as a standalone elicitation activity.
7) Observation
The main objective of the observation session is to understand the activity, task, tools used, and events performed
by others.
The plan for observation ensures that all stakeholders are aware of the purpose of the observation session, they
agree on the expected outcomes, and that the session meets their expectations. You need to inform the participants
that their performance is not judged.
During the session, the observer should record all the activities and the time taken to perform the work by others
so that he/she can simulate the same. After the session, the BA will review the results and will follow up with the
participants. Observation can be either active or passive.
Active observation is to ask questions and try to attempt the work that other persons are doing.
Passive observation is silent observation i.e. you sit with others and just observe how they are doing their work
without interpreting them.
Benefits:
• The observer will get a practical insight into the work.
• Improvement areas can be easily identified.
Drawbacks:
• Participants might get disturbed.
• Participants might change their way of working during observation and the observer might not
get a clear picture.
• Knowledge-based activities cannot be observed.
8)Prototyping
Prototyping is used to identify missing or unspecified requirements. In this technique, frequent demos are given
to the client by creating the prototypes so that client can get an idea of how the product will look like. Prototypes
can be used to create a mock-up of sites, and describe the process using diagrams. Benefits:
• Gives a visual representation of the product.
• Stakeholders can provide feedback early.
Drawbacks:
• If the system or process is highly complex, the prototyping process may become time-
consuming.
• Stakeholders may focus on the design specifications of the solution rather than the
requirements that any solution must address.
9)Joint Application Development (JAD)/ Requirement Workshops
This technique is more process-oriented and formal as compared to other techniques. These are
 structured meetings involving end-users, PMs, SMEs. This is used to define, clarify, and complete requirements.
This technique can be divided into the following categories:
Formal Workshops: These workshops are highly structured and are usually conducted with the selected group
of stakeholders. The main focus of this workshop is to define, create, refine, and reach closure on business
requirements.
Business Process Improvement Workshops: These are less formal as compared to the above one.
Here, existing business processes are analyzed and process improvements are identified.
Benefits:
• Documentation is completed within hours and is provided quickly back to participants for
review.
• You can get on the spot confirmation on requirements.
• Successfully gathered requirements from a large group in a short period.
• Consensus can be achieved as issues and questions are asked in the presence of all the
stakeholders.
Drawbacks:
• Stakeholder’s availability might ruin the session.
• The success rate depends on the expertise of the facilitator.
• A workshop motive cannot be achieved if there are too many participants.
10) Survey/Questionnaire
For Survey/Questionnaire, a set of questions is given to stakeholders to quantify their thoughts. After collecting
the responses from stakeholders, data is analyzed to identify the area of interest of stakeholders.
Questions should be based on high priority risks. Questions should be direct and unambiguous. Once the survey
is ready, notify the participants and remind them to participate.
Two types of questions can be used here:
Open-Ended: Respondent is given the freedom to provide answers in their own words rather than selecting from
predefined responses. This is useful but at the same time, this is time- consuming as interpreting the responses is
difficult.
Close Ended: It includes a predefined set of answers for all the questions and the respondent has to choose from
those answers. Questions can be multiple choice or can be ranked from not important to very important.

Benefits:
• Easy to get data from a large audience.
• Less time is required for the participants to respond.
• You can get more accurate information as compared to interviews.
Drawback:
• All the Stakeholders might not participate in the surveys.
• Questions may not be clear to all the participants.
• Open-ended questions require more analysis.
• Follow up surveys might be required based on the responses provided by participants.

A Software requirements specification document describes the intended purpose, requirements and nature
of a software to be developed. It also includes the yield and cost of the software.

3. Formal system specification

Need for Formal Specification:
Ambiguity: Natural language descriptions of software can be ambiguous, leading to
misunderstandings.
Completeness: Informal descriptions may not capture all requirements or behaviors.
Verification: Formal specifications can be used to verify properties of the software, such as
 correctness and consistency.

Types of Formal Specifications:

Model-based: Use of mathematical models (e.g., state machines, Petri nets) to describe the system's behavior.
Logic-based: Use of logical expressions (e.g., predicate logic, temporal logic) to specify properties and
constraints.

Benefits of Formal Specifications:

Clarity: Provides a precise and clear description of the system's requirements and behavior.
Consistency: Helps identify inconsistencies and ambiguities early in the development process.
Verification: Facilitates formal verification techniques to ensure that the software meets its requirements.
Documentation: Serves as comprehensive documentation for the software system.

Challenges of Formal Specifications:

Complexity: Formal specifications can be complex and require expertise to develop and understand.
Tool Support: Limited tool support for creating, analyzing, and maintaining formal specifications.
Cost: Developing formal specifications can be time-consuming and expensive compared to informal methods.

Examples of Formal Specification Languages:

• Z: A formal specification language based on set theory and first-order logic. VDM (Vienna
Development Method): A formal method for the specification and development of software systems.
• B: A method for specifying software systems using formal refinement techniques.
• TLA+ (Temporal Logic of Actions): A formal specification language for describing
concurrent and distributed systems.

Process of Formal Specification:

Requirements Elicitation: Gather and analyze requirements from stakeholders.
Specification Development: Develop formal specifications using appropriate languages and
techniques.
Specification Review: Review the formal specifications for correctness, completeness, and consistency.
Verification: Use formal methods to verify that the specifications meet the requirements. Maintenance: Update
the specifications as the software system evolves.

Application of Formal Specifications:

Critical Systems: Used in the development of safety-critical and mission-critical systems where
correctness is paramount.
Concurrency: Useful for specifying and verifying concurrent and distributed systems.
Security: Helps in specifying and analyzing security properties of software systems.
 4. Finite State Machines
Introduction to Finite State Machines (FSMs):
FSMs are mathematical models used to represent and control the behavior of systems with a finite number of
states. They are widely used in modeling software, hardware, and other systems with discrete behavior.

4.1 Types of Finite State Machines:

Deterministic Finite Automata (DFA): A type of FSM where each state has exactly one transition
for each possible input symbol.
Nondeterministic Finite Automata (NFA): A type of FSM where a state can have multiple
transitions for the same input symbol.

Components of FSMs:
States: Represent different configurations or conditions of the system. Transitions:
Define the rules for moving from one state to another based on input. Input Alphabet: Set
of symbols that can be used as inputs to the FSM.
Output Function: Specifies the output produced by the FSM in each state.

4.2 Applications of FSMs:

Software Modeling: Used to model the behavior of software systems, such as parsers, protocol implementations,
and user interfaces.
Hardware Design: Used in digital circuit design for control logic and sequential circuits.
Natural Language Processing: Used in language processing tasks like parsing and tokenization.
4.3 Finite State Machine Design:

State Diagram: Graphical representation of an FSM, showing states, transitions, and inputs.
State Table: Tabular representation of an FSM, showing transitions for each state and input combination.
State Minimization: Technique to reduce the number of states in an FSM without changing its behavior.

4.4 Practical Considerations:

State Explosion: Problem arising when the number of states in an FSM becomes too large, making it difficult
to manage.
Testing and Validation: Important steps in the design process to ensure that the FSM behaves as expected.
Implementation: FSMs can be implemented using programming languages or specialized tools.
Advanced Topics:
Hierarchical FSMs: FSMs that can be decomposed into smaller, more manageable FSMs.
Mealy and Moore Machines: Variants of FSMs where the output depends on the current state (Moore)
or the current state and input (Mealy).
 5. Petrinets
Petri nets — Formal technique for describing concurrent interrelated activities . Invented by
Carl Adam Petri, 1962

Consists of four parts

• A set of places
• A set of transitions
• An input function
• An output function
Originally of interest to automata theorists
Found wide applicability in computer science
➢ Performance Evaluation
➢ Operating ystems
➢ Software Engineering
The Classical Petri Net Model:
A Petri net is a network composed of places (O) and transitions (∏)

Connections are directed and between a place and a transition, or a transition and a place (e.g. Between “p1 and
t1” or “t1 and p2” above)Tokens(.) are the dynamic objects. Another (equivalent) notation is to use a solid bar
for the transitions:

We may use either notation since they are equivalent, sometimes one makes the diagram easier to read than the
other.
The state of a Petri net is determined by the distribution of tokens over the places (we could represent the above
state as (1, 2, 1, 1) for (p1, p2, p3, p4))
Transition t1 has three input places (p1, p2 and p3) and two output places (p3 and p4). Place p3 is both an input
and an output place of t1.

Enabling Condition:
➢ Transitions are the active components and places and tokens are passive components.
➢ A transition is enabled if each of the input places contains tokens.

Transition t1 is not enabled, transition t2 is enabled.

Firing:
An enabled transition may fire.
Firing corresponds to consuming tokens from the input places and producing tokens for the output places.

Firing is atomic (only one transition fires at a time, even if more than one is enabled)

6. Object Modelling using UML

The Unified Modelling Language, or UML, is a set of diagrammatic techniques, which are specifically tailored
for object-oriented development, and which have become an industry standard for modelling object-oriented
systems.
The UML grew out of the work of James Rumbaugh, Orady Booch and Ivor Jacobson, and has been approved
as a development standard by the Object Management Group.

Software Developers use specialized diagrams to model the system that they are working on throughout the
development process. Each model produced represents part of the system or some aspect of it, such as the
structure of the stored data, or the way that operations are carried out. Each model provides a view of the
system.

The principal UML diagrams with brief descriptions

Model View of the system

Use case How the system interacts with its users.

The data elements in the system and the relationships between them.
Class
Interaction (sequence How the objects interact to achieve the functionality of a use case.
and collaboration)

How the different objects of a single class behave through all the
State
use cases in which the class is involved.
Activity The sequence of activities that make up a process.
The different software components of the system and the
Component
dependencies between them
 The software and hardware elements of the system and the
Deployment
physical relationships between them.

7. Use Cases:

Introduction

Once you have developed an initial set of functional requirements during the Requirements
Gathering phase you will have a good understanding of the intended behavior of the system.
This includes what functionality is desired, what constraints are imposed, and what business
objectives will be satisfied. However, one shortcoming of a traditional 'laundry-list' of
requirements is that they are static and don't adapt to the different business processes that need
to be supported by one feature.

For example, in a fictitious online library system, the functionality for managing returns would
need to handle the separate situations where a borrower returns a book early and when they
return it late. Although the same functionality is involved, they are different situations and the
system would need to handle the separate conditions in each use case.
Definition:
A use case diagram of a software system describes the functionalities to be implemented by the software system.
It is at a relatively higher level of abstraction compared to the other UML diagrams and will not include
implementation details. Hence, it could be considered as a schematic view of the requirements for the software
system. Together with the narratives for the use cases, the use case view provides a complete set of requirements
for the system.
What is a Use Case?
A use case is a definition of a specific business objective that the system needs to accomplish. They do this by
describing the various external actors (or entities) that exist outside of the system, together with the specific
interactions they have with the system to accomplish the business objective.
Why Are They Important?
The major benefits that come with the creation of use cases are in the planning stage of development. Factors such
as requirements gathering, defining scope, and roadmap creation are all improved through these use cases. They
also allow the team to determine the best possible outcome scenario, accurately depicting the intended design and
use of the system. When it comes to less-than-ideal use cases, the brainstorming of these alternative possible
outcomes helps developers identify potential problems before they happen.
How to Write a Use Case
Thankfully, writing a use case can be broken down into three basic steps or questions that need to be answered:

Who is going to use the product?

What will it be used for?

How are they going to use it?

These questions form the basis of any successful use case, and should be used as a starting guide when writing
your own. Beyond that, use cases can be as high-level or detailed as they need to be for the audience and system.
The key to an effective and helpful use case is to carefully consider the flow of events for a typical user, and use
those to form the use case.
What to Include in a Use Case
As you’re writing your use case, there are several components that should typically be included. These range from
the identifier of the use case to who are involved and alternative solutions:
Use case number - assigning a number to each use case helps organize your records and can be sorted in
chronological order or by other criteria depending on how the developers decide to label them.
Use case name, description, and goal - giving a clear and concise name, description, and goal to each use case
also helps organize documentation while preventing scope creep.
Actor - this is someone or something that performs a behavior or action (can be a person or an object). If we take
an e-commerce site as an example, actors might include buyers, credit card companies, shipping companies, and
more.

Stakeholders - anyone with interests in the functionality and success of the system are called stakeholders, and
are often indirectly involved (not users but those that benefit from how the system functions).

Primary actor - this is someone or something whose goals are fulfilled by the system in question, and while they
don’t always start the use case, it’s fairly common for them to do so.
Pre-conditions - the statements about what needs to happen before the use case starts.
Triggers - used to start a use case, triggers are events that initiate the steps of a scenario.

Post-conditions - the statements about the possible states that the system can be in after the use case ends.

Basic flow - also called the main success scenario, this is a use case path that works perfectly and as intended
with no exceptions (this is often used as a base to create alternative paths).
Alternative path (or flow) -a variation of the main success scenario, these usually show what happens when
there’s an error or unexpected event in a use case.
Types of Use Case
Use cases can be described either at an abstract level (known as a business use-case) or at an implementation-
specific level (known as a system use case). Each of these is described in more detail below:

Business Use Case - also known as an "Abstract-Level Use Case", these use cases are written in a technology-
agnostic manner, simply referring to the high-level business process being described (e.g. "book return")
and the various external actors that take part in the process (e.g. "borrower", "librarian", etc.). The business use
case will define the sequence of actions that the business needs to perform to give a meaningful, observable result
to the external entity.

System Use Case - also known as an "Implementation Use Case", these use cases are written at a more granular
level of detail than the business use case and refer to specific processes that will be carried out by different parts
of the system. For example, a system use case might be "return book when overdue". It would
then describe the interactions of the various actors (borrower, librarian, etc.) with the system in carrying out the
end-to-end process.
Symbols in Use Case diagram : Actor:
An actor represents an external entity that interacts with a system. Since it is external to the system, the actor
itself is not fully modelled by the system.
User of a system is a typical example of an actor. Other types of actors include software systems that are being
integrated with the current system (e.g., a network protocol, a database system, a file system), external hardware
such as a sensor and so on.

Actors are classified into primary actors (also called active actors) and secondary actors (also called passive actors)
 5 relationship types in a use case diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

Use Case:
A use case represents a functionality (typically a requirement) that is expected to be implemented by the
system. The details of a use case, other than its unique name, are not represented visually in the diagram; such
details are given in use case narratives. Depending on the application domain and the choice made by the
designer, a use case may be broken down into several use cases which are connected through <<include>> or
<<extend>> relationships (described later in this document).
Generalization:
This represents a relationship between actors or between use cases. If two actors are related through this
relationship, then the actor (or use case) at the tail end of the arrow (connected to the base of the triangle) is a
specialized version of the actor (or use case) at the other end.

Association:
This represents a two-way communication between an actor and a use case and hence is a binary relation. Since it
is a two-way communication, for every use case initiated by a primary actor, the actor must get a response back
from the use case.

Extend relationship: The use case is optional and comes after the base use case. It is represented by a dashed
arrow in the direction of the base use case with the notation
<<extend>> .
Include relationship: The use case is mandatory and part of the base use case.

• error or unexpected event in a use case.

Example: ATM SYSTEM

Unified Modeling Language, Tools

UML

Unified Modeling Language (UML) is a general purpose modelling language. The main aim of UML is to define
a standard way to visualize the way a system has been designed. It is quite similar to blueprints used in other
fields of engineering.

UML is not a programming language, it is rather a visual language. We use UML diagrams to portray the behavior
and structure of a system. UML helps software engineers, businessmen and system architects with modelling,
design and analysis. The Object Management Group (OMG) adopted Unified Modelling Language as a standard
in 1997. Its been managed by OMG ever since. International Organization for Standardization (ISO) published
UML as an approved standard in 2005. UML has been revised over the years and is reviewed periodically.

Do we really need UML?

Complex applications need collaboration and planning from multiple teams and hence require a clear and concise
way to communicate amongst them.
Businessmen do not understand code. So UML becomes essential to communicate with non programmers
essential requirements, functionalities and processes of the system.
A lot of time is saved down the line when teams are able to visualize processes, user interactions and
static structure of the system.
UML is linked with object oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams include:
Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams include:
Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2

Object Oriented Concepts Used in UML –

Class – A class defines the blue print i.e. structure and functions of an object.
Objects – Objects help us to decompose large systems and help us to modularize our system. Modularity
helps to divide our system into understandable components so that we can build our system piece by piece.
An object is the fundamental unit (building block) of a system which is used to depict an entity.
Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their parent classes.
Abstraction – Mechanism by which implementation details are hidden from user.
Encapsulation – Binding data together and protecting it from the outer world is referred to as encapsulation.
Polymorphism – Mechanism by which functions or entities are able to exist in different forms.
Additions in UML 2.0 –
Software development methodologies like agile have been incorporated and scope of original UML specification
has been broadened.
Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to 13. The four
diagrams that were added are : timing diagram, communication diagram, interaction overview diagram and
composite structure diagram. UML 2.x renamed statechart diagrams to state machine diagrams.
UML 2.x added the ability to decompose software system into components and sub- components.

8. Structural UML Diagrams –

Class Diagram – The most widely use UML diagram is the class diagram. It is the building block of all object
oriented software systems. We use class diagrams to depict the static structure of a system by showing system’s
classes,their methods and attributes. Class diagrams also help us identify relationship between different classes or
objects.
Composite Structure Diagram – We use composite structure diagrams to represent the internal structure of a
class and its interaction points with other parts of the system. A composite structure diagram represents
relationship between parts and their configuration which determine how the classifier (class, a component, or a
deployment node) behaves. They represent internal structure of a structured classifier making the use of parts,
ports, and connectors. We can also model collaborations using composite structure diagrams. They are similar to
class diagrams except they represent individual parts in detail as compared to the entire class.
Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects have been
instantiated, we are able to study the behaviour of the system at a particular instant. An object diagram is similar
to a class diagram except it shows the instances of classes in the system. We depict actual classifiers and their
relationships making the use of class diagrams. On the other hand, an Object Diagram represents specific
instances of classes and relationships between them at a point of time.
Component Diagram – Component diagrams are used to represent how the physical components in a system
have been organized. We use them for modelling implementation details. Component Diagrams depict the
structural relationship between software system elements and help us in understanding if functional requirements
have been covered by planned development. Component Diagrams become essential to use when we design and
build complex systems. Interfaces are used by components of the system to communicate with each other.
Deployment Diagram – Deployment Diagrams are used to represent system hardware and its [Link] tells us
what hardware components exist and what software
components run on [Link] illustrate system architecture as distribution of software artifacts over distributed
targets. An artifact is the information that is generated by system software. They are primarily used when a
software is being used, distributed or deployed over multiple machines with different configurations.
Package Diagram – We use Package Diagrams to depict how packages and their elements have been
organized. A package diagram simply shows us the dependencies between different packages and internal
composition of packages. Packages help us to organise UML diagrams into meaningful groups and make the
diagram easy to understand. They are primarily used to organise class and use case diagrams.

Behavior Diagrams –

State Machine Diagrams – A state diagram is used to represent the condition of the system or part of the
system at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions. State diagrams are also referred to as State machines and State-chart Diagrams . These terms are
often used [Link], a state diagram is used to model the dynamic behavior of a class in
response to time and changing external stimuli.
Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We can also use
an activity diagram to refer to the steps involved in the execution of a use case. We model sequential and
concurrent activities using activity diagrams. So, we basically depict workflows visually using an activity
[Link] activity diagram focuses on condition of flow and the sequence in which it happens. We describe
or depict what causes a particular event using an activity diagram.
Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a part of a system.
They are widely used to illustrate the functional requirements of the system and its interaction with external
agents(actors). A use case is basically a diagram representing different scenarios where the system can be
used. A use case diagram gives us a high level view of what the system or a part of the system does without
going into implementation details.
Sequence Diagram – A sequence diagram simply depicts interaction between objects in a sequential order
i.e. the order in which these interactions take [Link] can also use the terms event diagrams or event
scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order the objects in
a system function. These diagrams are widely used by businessmen and software developers to document
and understand requirements for new and existing systems.
Communication Diagram – A Communication Diagram(known as Collaboration Diagram in UML 1.x) is
used to show sequenced messages exchanged between objects. A communication diagram focuses primarily
on objects and their relationships. We can represent similar information using Sequence diagrams,however,
communication diagrams represent objects and links in a free form.
Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to depict the
behavior of objects over a time frame. We use them to show time and duration constraints which govern
changes in states and behavior of objects.
Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of actions and
helps us simplify complex interactions into simpler occurrences. It is a mixture of activity and sequence
diagrams.
Example: CONFERENCE MANAGEMENT SYSTEM(UML diagram)

AIM:
To implement a software for Conference management system

PROBLEM STATEMENT:
The Conference Management System is an online website in which candidate can
submit the paper and register themselves and then attend the conference. The paper will be reviewed. The details
of the conference, date and time will be made available to them through the website. After getting the confirmation
details the candidate should submit the revised and camera ready paper. Then the registration process will be
done.

SOFTWARE REQUIREMENT SPECIFICATION:

INTRODUCTION
This software specification document consist full set of features and function for online conference management
system. In this we give specification about the system requirements that are apart from the functionality of the
system to perform the candidate paper valuation. It tells the usability, reliability defined in use case specification.

PURPOSE
The purpose of the conference management system is that the system can easily
review the process. The main process in this document is the submission of paper by the candidate, reviewing
process by the reviewer and sending of acknowledgement to the candidates whose paper is selected.

SCOPE
The scope of this conference management process is to select the best candidate from the list of candidates based
on their performance in the process.

DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

CANDIDATE - The candidate can login and submit the paper to the reviewer. After getting acknowledgement
the candidate will submit the revised and camera ready paper then registration process will be carried out.
REVIEWER - Reviewer will reviews the paper and sending acknowledgement to the candidate DATABASE -
Database is used to verify login and store the details of selected candidates.
HTML - Markup Language used for creating web pages.
J2EE – Java 2 Enterprise Edition is a programming platform java platform for developing and running distributed
java applications.
HTTP - Hyper Text Transfer Protocol.
TCP/IP – Transmission Control Protocol/Internet Protocol is the communication protocol used to connect
hosts on the Internet.
REFERENCES
IEEE Software Requirement Specification format.
TECHNOLOGIES TO BE USED
HTML JSP
Java

TOOLS TO BE USED
Eclipse IDE (Integrated Development Environment) Rational
Rose tool (for developing UML Patterns)
OVERVIEW
SRS includes two sections overall description and specific requirements – Overall Description will describe
major role of the system components and inter- connections.
Specific Requirements will describe roles & functions of the actors.

OVERALL DESCRIPTION

PRODUCT PERSPECTIVE
The process of the candidates is to login the conference system and submit the paper through online. Then the
reviewer reviews the paper and sends the acknowledgement to the candidate either paper selected or rejected.

SOFTWARE INTERFACE
Front End Client - The exporter online interface is built using JSP and HTML. Web
Server – Apache Tomcat Server (Oracle Corporation)
Back End - Oracle 11g database

HARDWARE INTERFACE
The BPO system’s server is directly connected to the client systems via ftp. The client systems have access to
the database in the server.

SYSTEM FUNCTIONS
This process of on conference management system are described sequentially through following steps,
The candidate login to the conference management system. The
paper title is submitted.
The paper is been reviewed by the reviewer.
The reviewer sends acknowledgement to the candidate. Based on
the selection, the best candidate is selected.
Finally the candidate registers all details

USER CHARACTERISTICS
Candidate - Logins the conference system and submits the paper then do the registration process. Reviewer –
Review the paper, select best candidate and send acknowledgement to them.

CONSTRAINTS
Although the security is given high importance, there is always a chance of intrusion in the web world which
requires constant monitoring.
The user has to be careful while submitting the information. Much care is required.
ASSUMPTIONS AND DEPENDENCIES
The candidate and reviewer must have basic knowledge of computers and English Language. Provide
privacy and security for the documents and candidate information

USECASE DIAGRAM:
A use case is a methodology used in system analysis to identify, clarify, and
organize system requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. It is represented using ellipse.
Actor is any external entity that makes use of the system being modeled. It is represented using stick figure.
The conference management system use cases are:
Paper submission
Review the paper
Send confirmation details Send
revised paper Registration
ACTORS:
Actors are as follows:
Candidate
Reviewer

ACTORS DOCUMENTATION:
Candidate - Logins the conference system and submits the paper then do the registration process. Reviewer –
Review the paper, select best candidate and send acknowledgement to them.
Paper submission – Candidate submits the paper.
Review the paper– The paper is been reviewed by the reviewer and the paper is selected. Paper
confirmation details – The reviewer can send the confirmation details to the candidate.
Revised and camera ready paper – After the paper is selected and the camera ready paper should be submitted
to the reviewer by candidate.
Registration – After submitting the revised paper the candidate wants to register.
 13. Functional Modelling
Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of
what the system is supposed to do. It defines the function of the internal processes in the system with the aid
of Data Flow Diagrams (DFDs).
14. Data Flow Diagrams
Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a
system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as
the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects
or the system, and the external controls and objects that affect the transformation.

The four main parts of a DFD are

• Processes,
• Data Flows,
• Actors, and
• Data Stores.

The other parts of a DFD are

• Constraints, and
• Control Flows.

Processes
Processes are the computational activities that transform data values. A whole system can be visualized as a
high-level process. A process may be further divided into smaller components. The lowest-level process may
be a simple function.

Representation in DFD − A process is represented as an ellipse with its name written inside it and contains a
fixed number of input and output data values.

Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and
outputs their HCF (highest common factor) and LCM (least common multiple).

Data Flows
Data flow represents the flow of data between two processes.
Representation in DFD − A data flow is represented by a directed arc or an arrow, labelled with the name of the
data item that it carries.
The output value is sent to several places as shown in the following figure. Here, the output arrows are
unlabelled as they denote the same value.
The data flow contains an aggregate value, and each of the components is sent to different places as shown in the
following figure. Here, each of the forked components is labelled.
Actors
Actors are the active objects that interact with the system by either producing data and inputting them to the
system, or consuming data produced by the system.
Representation in DFD − An actor is represented by a rectangle. Actors are connected to the inputs and
outputs and lie on the boundary of the DFD.
Example − The following figure shows the actors, namely, Customer and Sales_Clerk in a counter sales
system.

Data Stores
Data stores are the passive objects that act as a repository of data.
Representation in DFD − A data store is represented by two parallel lines containing the name of the data
store. Each data store is connected to at least one process. Input arrows contain information to modify the
contents of the data store, while output arrows contain information retrieved from the data store. When a part of
the information is to be retrieved, the output arrow is labelled. An unlabelled arrow denotes full data retrieval.
A two-way arrow implies both retrieval and update.
Constraints

Constraints specify the conditions or restrictions that need to be satisfied over time.

Representation − A constraint is rendered as a string within braces.

Control Flows
A process may be associated with a certain Boolean value and is evaluated only if the value is true, though it is not
a direct input to the process. These Boolean values are called the control flows.
Representation in DFD − Control flows are represented by a dotted arc from the process producing the
Boolean value to the process controlled by them.

Example − The following figure represents a DFD for arithmetic division. The Divisor is tested for non-
zero. If it is not zero, the control flow OK has a value True and subsequently the Divide process computes the
Quotient and the Remainder.
 15. UML CASE TOOLS:
ARGO UML:

✓ ArgoUML is the leading open source UML modeling tool.

✓ ArgoUML needs a reasonable amount of computing resource. Any PC which is

able to run an operating system with a graphical user interface will suffice
✓ UML diagramming application written in Java and released under the open
source Eclipse Public License.
✓ By virtue of being a Java application, it is available on any platform supported
by Java SE.
✓ It includes support for all standard UML 1.4 diagrams.
✓ It runs on any Java platform and is available in ten language
✓ ArgoUML 0.26 and 0.26.2 were downloaded over 80,000 times and are in use all
over the world

✓ ArgoUML is written in 100% pure Java, it should run on any machine with Java
installed. Java version 5 or later is needed. You may have this in place, but if not the
latest version can be downloaded free from [Link]. Note that you only need
the Java Runtime Environment (JRE), there is no need to download the whole Java
Development Kit (JDK).
✓ Platform: Java Platform, Standard Edition
✓ Initial release date: April 1999
✓ License: Eclipse Public License 1.0
✓ Programming languages: Unified Modeling Language, Java
LOGO:
Pros

• Open-source
• Runs on many different platforms, including the latest version of Windows
• Supports many programming languages

Cons

• Steep learning curve

• Java isn't always stable
Main UML Tool:

StarUML − StarUML is an open source project to develop fast, flexible, extensible, featureful, and freely-
available UML/MDA platform running on Win32 platform.
ArgoUML − ArgoUML is the leading open source UML modeling tool and includes support for all standard UML
diagrams.
Umbrello UML Modeller − Umbrello UML Modeller is a Unified Modelling Language diagram programme for
KDE.
Acceleo − Acceleo is easy to use. It provides off the shelf generators (JEE, .Net, Php...) and template editors for
Eclipse.
GenMyModel − An online UML modeling tool

What is the best software for UML diagrams?

Lucidchart
[Link]
[Link]
Cacoo
Gliffy
EdrawMax
Microsoft Visio Pro

StarUML

StarUML is an open-source software modeling tool, which is provided by MKLab. It has come up with eleven
different types of modeling diagrams. It also supports UML2.0 specified diagrams.

Features:
It let you create Object, Use case, Deployment, Sequence, Collaboration, Activity, and Profile diagrams.
It is a UML 2.x standard compliant.
It offers multiplatform support (MacOS, Windows, and Linux).

Download link: [Link]

Umbrello

Umbrello is a Unified Modeling language tool, which is based on KDE technology. It supports both reverse
engineering and code generation for C++ and Java.

Features:
It implements both structural and behavioral diagrams.
It imports C++ and can export up to a wider range of languages.

Download link: [Link]

UML designer tool

The UML designer tool helps in modifying and envisioning UML2.5 models. It allows you to create all of the
UML diagrams.

Features:
It provides transparency to work on DSL as well as UML models.
With the UML designer tool, the user can reuse the provided presentations. It
implements Component, Class, and Composite structure diagrams.
To start working with DSL, you can use UML legacy models.
Download link: [Link]

Altova

Altova has provided UModel, which is another UML software modeling tool. It supports all types of 14 UML2
diagrams as well as SysML for the embedded systems. It also holds up for business process modeling for
enterprise analysts. It generates visually designed software models by incorporating Java, C++, and C #or
Visual Basic .NET.

Features:
It provides a dedicated toolbar for an individual diagram.
It offers unlimited undo/redo, which inspires to discover new ideas. In
UML diagrams, you can easily add a hyperlink to any element.
It also provides an intuitive color-coding, icons, customized alignment grid, and cascading styles for colors, fonts
line size.
Download link: [Link]

Umple

Umple is an object-oriented and modeling language that textually supports state diagrams and class diagrams. It
adapts JAVA, C++, and PHP, which results in more readable and short lines of code.

Features:
It includes Singleton pattern, keys, immutability, mixins, and aspect-oriented code injection, which makes
UML more understandable to the users.
It enforces referential integrity by supporting UML multiplicity.

Download link: [Link]

Visual Paradigm

A visual Paradigm is a tool that supports SysML, UML2, and Business Process Modeling Notation from Object
Management Group. It involves report generation as well as code generation.

Features:
It supports all of the 14 UML2 diagrams.
It supports BPMN 2.0, ERD, ORMD, SysML.

Download link: [Link]

WhitestarUML

Whitestar UML is a division of StarUML 5.0 that offers bug fixes and has improved its compatibility with the
latest operating systems, i.e., support of Unicode strings or simply being developed and tested on Windows 7 and
8.
Features:
o It offers a refreshed user interface.
o It completely handles the functioning of Unicode strings.
o It provides support on Windows 7, 8, and 10.
o On-demand upload and download of units.
o It directly integrates the ERD profile and extends to generate and parse the SQL tables.

Download link: [Link]

1. [Link]

[Link] is an open-source modeling tool to create flowcharts, process diagrams, UML, ER, and network
diagrams.

Features:
o Since it is very easy to use, it provides an intuitive interface, drag& drop functionality, a
huge amount of templates, and also, it does not need to install.
o It offers security and reliability.
o It can be used anywhere, both online and offline.
o It is compatible with every browser.

Download link: [Link]

2. GenMyModel

GenMyModel is an online modeling platform that offers Business (Archimate, BPMN, flowcharts
support) as well as IT modeling (RDS, UML2.5 class diagrams).

Features:
o It provides an online platform.
o It generates online code.
o It provides a centralized repository for easy and simultaneous model collaboration.
o You can import or export as a PDF.

Download link: [Link]

3. Latino

It is an online platform that offers UML tools for faster development of UML diagrams. It is
based on UMLet, which is an eclipse plugin or work as a standalone tool.

Features:
• It allows you to export the diagram as XML or any other image file such
as Gif, JPEG, or SVG format.
• It is an installation free web application.

Download link: [Link]

Read Any 10 tools: