Shri Rawatpura Sarkar Institute Of Technology –II New Raipur(C.G.

Department of Computer Science &Engg.

Branch: Computer Science & Engineering Semester: VI
Subject: Software Engineering & Project Management Laboratory with Minor
Code:322661(22)

Sr.N Objects Remark

O
1 Phases in software development
project, overview, need, coverage of
topics
2 To assign the requirement
engineering tasks.

3 To perform the system analysis:

Requirement analysis, SRS (Allotted
Project)
4 To perform the function oriented
diagram: DFD and Structured chart

5 To perform the user’s view analysis:

Use case diagram

6 To draw the structural view diagram

: Class diagram, object diagram

7 To draw the behavioral view

diagram : Sequence diagram,
Collaboration diagram
8 To draw the behavioral view
diagram : State-chart diagram,
Activity diagram
9 To draw the implementation view
diagram: Component diagram.

10 To draw the implementation view

diagram: deployment diagram

Experiment No.1
Software Development Project: Phases

The typical software project includes the following phases:

1. Requirements Analysis and Definition. System Overview

2. Estimation
3. Functional Specification and UI Prototype
4. Software Architecture and Test Plan
5. Implementation (Coding) and Testing
6. Release. Delivery and Installation
7. Operation and Maintenance

Below you will find a brief description of these phases. Later on, we’re going to publish a separate
article on each phase.

Requirements Analysis and Definition. System Overview

This phase begins with analyzing what exactly you want to have done. The system overview helps
you see the big picture of the project and understand which steps need to be carried out. You should
determine and document the vision for the target product or system; the user profile(s); the hardware
and software environment; the most important components, functions, or features the software must
have; the security requirements, etc. To aid in the needs analysis, it is sometimes necessary to have
prototypes created – or to have them created by professionals, for that matter. All this can and often
should be done in cooperation with your vendor.

The product of this stage is the general system requirements (and sometimes, draft user manual).
This document will be modified as the project is undertaken.

Estimation

This is a phase that is usually obscure to customers. Vendors tend to supply you with an estimate
itself, and that’s it. Personally, I believe that customers may and should take more active part in the
estimation process. For example, you have to be able to select from different options discussing the
platforms, technologies, and tools that will be used for the target system. Also, make sure your
vendor does a research of the existing libraries and tools that can be used in the project. Remember
that an estimate should explicitly list what is included in the price, as well as why and how much any
additional features will cost. Never let the vendor baffle you with technical jargon and complex
details. Finally, if you are in doubt about the provided estimate, consult an expert; if the vendor
appears to try to take advantage of you, don’t bargain with such a company – just say “thank you”
and look for another OSP. Outsourcing is risky by nature, so you can’t afford to take chances with a
vendor like that.
The estimate isn’t the only document that results from this phase. The project contract (or project
bid) and rough project schedule usually come into existence at this point, too.

Functional Specification and UI Prototype

A functional specification determines what exactly the target system must do and the premises for its
implementation. All requirements should be thoroughly defined and documented. The general
system requirements and other documents created in the first phase serve as input here. Depending
on the nature of the system, creating a UI prototype in this phase may be crucially important for the
success of the project.

If your company has appropriate experience, you can have the functional specification and UI
prototype created in-house. However, I recommend ordering the development of the specification
and UI prototype from your OSP. This will help you check the vendor’s expertise; at the same time,
the vendor will have an opportunity to get a better idea of the project and get prepared for its
implementation.

Besides the functional specification and UI prototype, this phase may also result in creating an exact
project plan that contains the project schedule, milestones, and human resources.

Software Architecture and Test Plan

In this phase, it is necessary to determine the system components covering your requirements and
the way these components will work together. The software architecture design may be logically
divided into two parts: general design and detailed design. The general design consists of the
structural design, development strategy, and system design documentation. Working out the general
design, developers break the target system into high-level components and describe them in the
context of the whole system. When it comes to the detailed design, specification and documentation
on each component are developed. The general system requirements, functional specification, and
UI prototype serve as input for this phase.

Completing this phase, your vendor should produce the description of the software architecture, the
algorithmic structure of the system components and their specifications, the documentation of all
design decisions, and a thorough test plan.

Implementation (Coding) and Testing

The goal of this phase is building the target system based on the specifications developed in the
previous phases. Transferring the specification algorithms into a programming language, your
vendor creates and integrates the system components. Performing code reviews and test cases
worked out by the vendor’s QA/QC division, as well as unit, integration, and system tests are other
key activities of this phase. Comprehensive testing and correcting any errors identified ensures that
components function together properly, and that the project implementation meets the system
specification.

Outsourcing a software development project, I advise you to have a project delivered and paid for in
parts. This is one of the best ways to minimize the risk for you and your vendor. If you aren’t satisfied
with the way the project is being implemented, you can take to another vendor the specification and
the code that was previously delivered.

Release. Delivery and Installation

In the release phase, your vendor must transfer the target product or system to you. The key
activities usually include installation and configuration in the operational environment, acceptance
testing, and training of the users if necessary.

A crucial point here is formal acceptance testing which comprises a series of end-to-end tests. It is
performed to confirm that the product or system fulfills the acceptance requirements determined by
the functional specification.

After this phase is complete, the product or system is considered formally delivered and accepted. If
iterative development is used, the next iteration should be commenced.

Operation and Maintenance

The Operation and Maintenance phase begins once you have formally accepted the product or
system delivered by the vendor. The task of this phase is the proper functioning of the software. To
improve a product or system, it should be continuously maintained. Software maintenance involves
detecting and correcting errors, as well as extending and improving the software itself.

Conclusion

I’d like to conclude this article with a little advice. You shouldn’t treat the documents resulting from
phases 1, 3, and 4 as a law that can’t be amended. The system requirements, user manual,
functional specification, and even software architecture design often need to be updated and
modified throughout the course of the project implementation. Just be cautious that any changes
introduced in the documentation are consistent with your initial vision for the target product or
system. (Well, let’s face it: the initial vision may eventually change as well.)

Experiment No. 2

Requirements Engineering

• Must be adapted to the needs of a specific process, project, product, or people doing the
work.
• Begins during the software engineering communication activity and continues into the
modeling activity.
• In some cases requirements engineering may be abbreviated, but it is never abandoned.
• It is essential that the software engineering team understand the requirements of a problem
before the team tries to solve the problem.

Requirements Engineering Tasks

• Inception (software engineers use context-free questions to establish a basic understanding

of the problem, the people who want a solution, the nature of the solution, and the
effectiveness of the collaboration between customers and developers)
• Elicitation (find out from customers what the product objectives are, what is to be done, how
the product fits into business needs, and how the product is used on a day to day basis)
• Elaboration (focuses on developing a refined technical model of software function, behavior,
and information)
• Negotiation (requirements are categorized and organized into subsets, relations among
requirements identified, requirements reviewed for correctness, requirements prioritized
based on customer needs)
• Specification (written work products produced describing the function, performance, and
development constraints for a computer-based system)
• Requirements validation (formal technical reviews used to examine the specification work
products to ensure requirement quality and that all work products conform to agreed upon
standards for the process, project, and products)
• Requirements management (activities that help project team to identify, control, and track
requirements and changes as project proceeds, similar to software configuration
management (SCM) techniques

Initiating Requirements Engineering Process

• Identify stakeholders
• Recognize the existence of multiple stakeholder viewpoints
• Work toward collaboration among stakeholders
• These context-free questions focus on customer, stakeholders, overall goals, and benefits of
the system
o Who is behind the request for work?
o Who will use the solution?
o What will be the economic benefit of a successful solution?
o Is there another source for the solution needed?
• The next set of questions enable developer to better understand the problem and the
customer’s perceptions of the solution
o How would you characterize good output form a successful solution?
o What problem(s) will this solution address?
o Can you describe the business environment in which the solution will be used?
o Will special performance constraints affect the way the solution os approached?
• The final set of questions focuses on communication effectiveness
o Are you the best person to give “official” answers to these questions?
o Are my questions relevant to your problem?
o Am I asking too many questions?
 o Can anyone else provide additional information?
o Should I be asking you anything else?

Eliciting Requirements

• Goal is to identify the problem, propose solution elements, negotiate approaches, and
specify preliminary set of solutions requirements
• Collaborative requirements gathering guidelines
o Meetings attended by both developers and customers
o Rules for preparation and participation are established
o Flexible agenda is used
o Facilitator controls the meeting
o Definition mechanism (e.g. stickers, flip sheets, electronic bulletin board) used to
gauge group consensus

Quality function deployment (QFD)

• Quality management technique that translates customer needs into technical software
requirements expressed as a customer voice table
• Identifies three types of requirements (normal, expected, exciting)
• In customer meetings function deployment is used to determine value of each function
that is required for the system
• Information deployment identifies both data objects and events that the system must
consume or produce (these are linked to functions)
• Task deployment examines the system behavior in the context of its environment
• Value analysis is conducted to determine relative priority of each requirement generated by
the deployment activities

Elicitation Work Products

• Statement of need and feasibility

• Bounded statement of scope for system or product
• List of stakeholders involved in requirements elicitation
• Description of system’s technical environment
• List of requirements organized by function and applicable domain constraints
• Set of usage scenarios (use-cases) that provide use insight into operation of deployed
system
• Prototypes developed to better understand requirements

Elicitation Problems

• Scope – system boundaries ill-defined

• Understanding – customers not sure what’s needed or can’t communicate it
• Volatility – requirements changes over time
Developing Use-Cases

• Each use-case tells stylized story about how end-users interact with the system under a
specific set of circumstances
• First step is to identify actors (people or devices) that use the system in the context of the
function and behavior of the system to be described
o Who are the primary (interact with each other) or secondary (support system)
actors?
o What are the actor’s goals?
o What preconditions must exist before story begins?
o What are the main tasks or functions performed by each actor?
o What exceptions might be considered as the story is described?
o What variations in actor interactions are possible?
o What system information will the actor acquire, produce, or change?
o Will the actor need to inform the system about external environment changes?
o What information does the actor desire from the system?
o Does the actor need to be informed about unexpected changes?
• Next step is to elaborate the basic use case to provide a more detailed description needed
to populate a use-case template

Use case template

• Use Case Name

• Primary actor
• Goal in context
• Preconditions
• Trigger
• Scenario details
• Exceptions
• Priority
• When available
• Frequency of use
• Channel to actor
• Secondary actors
• Channels to secondary actors
• Open issues

Analysis Model

• Intent is to provide descriptions of required information, functional, and behavioral domains

for computer-based systems
• Analysis Model Elements
o Scenario-based elements (use cases describe system from user perspective)
o Class-based elements (relationships among objects manipulated by actors and their
attributes are depicted as classes)
 o Behavioral elements (depict system and class behavior as states and transitions
between states)
o Flow-oriented elements (shows how information flows through the system and is
transformed by the system functions)

Analysis Patterns

• Suggest solutions (a class, a function, or a behavior) that can be reused when modeling
future applications
• Can speed up the development of abstract analysis models by providing reusable analysis
models with their advantages and disadvantages
• Facilitate the transformation of the analysis model into a design model by suggesting design
patterns and reliable solutions to common patterns

Negotiating Requirements

• Intent is to develop a project plan that meets stakeholder needs and real-world constraints
(time, people, budget) placed on the software team
• Negotiation activities
o Identification of system key stakeholders
o Determination of stakeholders’ “win conditions”
o Negotiate to reconcile stakeholders’ win conditions into “win-win” result for all
stakeholders (including developers)
• Goal is to produce a win-win result before proceeding to subsequent software engineering
activities

Requirement Review (Validation)

• Is each requirement consistent with overall project or system objective?

• Are all requirements specified at the appropriate level off abstraction?
• Is each requirement essential to system objective or is it an add-on feature?
• Is each requirement bounded and unambiguous?
• Do you know the source for each requirement?
• Do requirements conflict with one another?
• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable once implemented?
• Does the requirements model reflect the information, function, and behavior of the system to
be built?
• Has the requirements model been partitioned in a way that exposes more detailed system
information progressively?
• Have all the requirements patterns been properly validated and are they consistent w with
customer requirements?

Experiment No. 3

To perform the system analysis: Requirement analysis, SRS (Allotted Project)

Procedure:

Step 1:
Introduction:
Purpose
Identify the product whose software requirements are specified in this document, including the revision or
release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS
describes only part of the system or a single subsystem .

Intended Audience and Reading Suggestions

Describe the different types of reader that the document is intended for, such as developers, project
managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS
contains and how it is organized. Suggest a sequence for reading the document, beginning with the
overview sections and proceeding through the sections that are most pertinent to each reader type.

Project Scope
Provide a short description of the software being specified and its purpose, including relevant benefits,
objectives, and goals. Relate the software to corporate goals or business strategies. If a separate vision and
scope document is available, refer to it rather than duplicating its contents here. An SRS that specifies the
next release of an evolving product should contain its own scope statement as a subset of the long-term
strategic product vision.

Step 2:

Overall Description
Product Perspective
Describe the context and origin of the product being specified in this SRS. For example, state whether this
product is a follow-on member of a product family, a replacement for certain existing systems, or a new,
self-contained product. If the SRS defines a component of a larger system, relate the requirements of the
larger system to the functionality of this software and identify interfaces between the two. A simple
diagram that shows the major components of the overall system, subsystem interconnections, and external
interfaces can be helpful.

Product Features
Summarize the major features the product contains or the significant functions that it performs or lets the
user perform. Only a high level summary is needed here. Organize the functions to make them
understandable to any reader of the SRS. A picture of the major groups of related requirements and how
they relate, such as a top level data flow diagram or a class diagram, is often effective.
User Classes and Characteristics
Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class.
Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from
those who are less important to satisfy.

Operating Environment
Describe the environment in which the software will operate, including the hardware platform, operating
system and versions, and any other software components or applications with which it must peacefully
coexist.

Design and Implementation Constraints

Describe any items or issues that will limit the options available to the developers. These might include:
corporate or regulatory policies; hardware limitations (timing requirements, memory requirements);
interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations;
language requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer‟s organization will be responsible for maintaining
the delivered software).

Step 3:

System Features
This template illustrates organizing the functional requirements for the product by system features, the
major services provided by the product. You may prefer to organize this section by use case, mode of
operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the
most logical sense for your product.

System Feature 1
Don‟t really say “System Feature 1.” State the feature name in just a few words.
1 Description and Priority
Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority.
You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each
rated on a relative scale from a low of 1 to a high of 9).

Step 4:

External Interface Requirements

User Interfaces
Describe the logical characteristics of each interface between the software product and the users. This
may include sample screen images, any GUI standards or product family style guides that are to be
followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every
screen, keyboard shortcuts, error message display standards, and so on. Define the software components
for which a user interface is needed. Details of the user interface design should be documented in a
separate user interface specification.
Hardware Interfaces
Describe the logical and physical characteristics of each interface between the software product and the
hardware components of the system. This may include the supported device types, the nature of the data
and control interactions between the software and the hardware, and communication protocols to be used.
Software Interfaces
Describe the connections between this product and other specific software components (name and
version), including databases, operating systems, tools, libraries, and integrated commercial components.
Identify the data items or messages coming into the system and going out and describe the purpose of
each. Describe the services needed and the nature of communications. Refer to documents that describe
detailed application programming interface protocols. Identify data that will be shared across software
components. If the data sharing mechanism must be implemented in a specific way (for example, use of a
global data area in a multitasking operating system), specify this as an implementation constraint.

Communications Interfaces
Describe the requirements associated with any communications functions required by this product,
including e-mail, web browser, network server communications protocols, electronic forms, and so on.
Define any pertinent message formatting. Identify any communication standards that will be used, such as
FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and
synchronization mechanisms.

Nonfunctional Requirements
Performance Requirements
If there are performance requirements for the product under various circumstances, state them here and
explain their rationale, to help the developers understand the intent and make suitable design choices.
Specify the timing relationships for real time systems. Make such requirements as specific as possible.
You may need to state performance requirements for individual functional requirements or features.

Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or harm that could result from
the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be
prevented. Refer to any external policies or regulations that state safety issues that affect the product ‟s
design or use. Define any safety certifications that must be satisfied.

Security Requirements
Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect the
product. Define any security or privacy certifications that must be satisfied.

Software Quality Attributes

Specify any additional quality characteristics for the product that will be important to either the customers
or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability,
maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be
specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for
various attributes, such as ease of use over ease of learning.

Other Requirements
Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the project, and
so on. Add any new sections that are pertinent to the project.
 Experiment No. 4

To perform the function oriented diagram: DFD and Structured chart

OVERALL DESCRIPTION :

Data analysis attempts to answer four specific questions:

 What processes make up a system?
 What data are used in each process?
 What data are stored?
 What data enter and leave the system?
Data drive business activities and can trigger events (e.g. new sales order data) or be processed to provide
information about the activity. Data flow analysis, as the name suggests, follows the flow of data through
business processes and determines how organisation objectives are accomplished. In the course of
handling transactions and completing tasks, data are input, processed, stored, retrieved, used, changed and
output. Data flow analysis studies the use of data in each activity and documents the findings in data flow
diagrams, graphically showing the relation between processes and data.

Physical and Logical DFDs

There are two types of data flow diagrams, namely physical data flow diagrams and logical data flow
diagrams and it is important to distinguish clearly between the two:

Physical Data Flow Diagrams

An implementation-dependent view of the current system, showing what tasks are carried out and how
they are performed. Physical characteristics can include:
Names of people
Form and document names or numbers
Names of departments
Master and transaction files
Equipment and devices used

Logical Data Flow Diagrams

An implementation-independent view of the a system, focusing on the flow of data between processes
without regard for the specific devices, storage locations or people in the system. The physical
characteristics listed above for physical data flow diagrams will not be specified.
Data Flow Diagram (DFD)
The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the different
processing activities or functions that the system performs and the data interchange among these functions. Each
function is considered as a processing station (or process) that consumes some input data and produces some output
data. The system is represented in terms of the input data to the system, various processing carried out on these data,
and the output data generated by the system. A DFD model uses a very limited number of primitive symbols [as
shown in fig. 5.1(a)] to represent the functions performed by a system and the data flow among these functions.
 Experiment No.5

To perform the user’s view analysis: Use case diagram

Objective :
To understand the users view of a project using Use case Diagram

Software Required :-
Visual Paradigm for UML 8.2

Procedure :-
You can draw use case diagrams in VP-UML as well as to document the event flows of use cases using
the flow-of-events editor of UML 8.2 .The steps are as follows.
Step 1:
Right click Use Case Diagram on Diagram Navigator and select New Use Case Diagram from the pop-up
menu.
Step 2:-
Enter name for the newly created use case diagram in the text field of pop-up box on the top left corner.

Step 3:
Drawing a system
To create a system, select System on the diagram toolbar and then click it on the diagram pane. Finally,
name the newly created system when it is created .
Step 4:
Drawing an actor
To draw an actor, select Actor on the diagram toolbar and then click it on the diagram pane. Finally,
name the newly created actor when it is created.

Step 5 :- Drawing a use case

Besides creating a use case through diagram toolbar, you can also create it through resource icon.
Move the mouse over a shape and press a resource icon that can create use case. Drag it and then release
the mouse button until it reaches to your preferred place. The source shape and the newly created use case
are connected. Finally, name the newly created use case.

Step 6:- Create a use case through resource icon

Line wrapping use case name
If a use case is too wide, for a better outlook, you may resize it by dragging the filled selectors. As a
result, the name of use case will be line-wrapped automatically.

Step 7:
Resize a use
case
To create an extend relationship, move the mouse over a use case and press its resource iconExtend ->
Use Case. Drag it to your preferred place and then release the mouse button. The use case with
extension points and a newly created use case are connected. After you name the newly created use
case, a pop- up dialog box will ask whether you want the extension point to follow the name of use
case. Click Yes if you want it to do so; click NO if you want to enter another name for extension point.

Step 8: Create an extend relationship

Drawing <<Include>> relationship
To create an include relationship, mouse over a use case and press its resource icon Include -> Use Case.
Drag it to your preferred place and then release the mouse button. A new use case together with an
include relationship is created. Finally, name the newly created use case.

Step 9:
Include relationship is created
Structuring use cases with package
You can organize use cases with package when there are many of them on the diagram.
Select Package on the diagram toolbar (under Common category).

Step 10:

Step 11: Surround use cases with package

Step 12 Name the package

Assigning IDs to actors/Use cases
You may assign IDs to actors and use cases. By default, IDs are assigned with the order of object
creation, starting from one onwards. However, you can define the format or even enter an ID manually.
Defining the format of ID
To define the format of ID, select Tools > Options from the main menu to unfold the Options dialog box.
Select Diagramming from the list on the left hand side and select the Use Case Diagram tab on the right
hand side. You can adjust the format of IDs under Use Case Diagram tab. The format of ID consists of
prefix, number of digits and suffix.

Step 13: Use Case

Diagram tab
Showing ID on diagram
By default, ID is just a text property. It usually doesn't appear on diagram. However, you can make it
shown within a use case.
Right click on the diagram background, select Presentation Options and the specific model element
display option from the pop-up menu.
Step 14 : Show ID on diagram

Experiment No. 6

To draw the structural view diagram : Class diagram, object diagram

Objective:-
To show diagrammatically the objects required and the relationships between them while developing
a software product.
Software Required :-
Visual Paradigm for UML 8.2
Procedure :-
Step 1:-
Right click Class Diagram on Diagram Navigator and select New Class Diagram from the pop-up menu
to create a class diagram
Step 2:-
Creating class
To create class, click Class on the diagram toolbar and then click on the diagram.

A class will be created.

Creating association
To create association from class, click the Association -> Class resource beside it and drag.

Drag to empty space of the diagram to create a new class, or drag to an existing class to connect to it.
Release the mouse button to create the association.
To create aggregation, use the Aggregation -> Class resource instead.

Step 3:-
To edit multiplicity of an association end, right-click near the association end, select Multiplicityfrom the
popup menu and then select a multiplicity.

To show the direction of an association, right click on it and select Presentation Options > Show
Direction from the pop-up menu.
Step 4:-
The direction arrow is shown beside the association.

Creating generalization
To create generalization from class, click the Generalization -> Class resource beside it and drag.

Drag to empty space of the diagram to create a new class, or drag to an existing class to connect to it.
Release the mouse button to create the generalization.
Creating attribute
To create attribute, right click the class and select Add > Attribute from the pop-up menu.

An attribute is created.

An attribute is created.

Creating attribute with enter key

After creating an attribute, press the Enter key, another attribute will be created. This method lets you
create multiple attributes quickly and easily.
Creating operation
To create operation, right click the class and select Add > Operation from the pop-up menu.

An operation is created.

Similar to creating attribute, you can press the Enter key to create multiple operations continuously.
Drag-and-Drop reordering, copying and moving of class members
To reorder a class member, select it and drag within the compartment, you will see a thick black line
appears indicating where the class member will be placed.

Release the mouse button, the class member will be reordered.

To copy a class member, select it and drag to the target class while keep pressing the Ctrl key, you will
see a thick black line appears indicating where the class member will be placed. A plus sign is shown
beside the mouse cursor indicating this is a copy action.

Release the mouse button, the class member will be copied.

To move a class member, select it and drag to the target class, you will see a thick black line appears
indicating where the class member will be placed. Unlike copy, do not press the Ctrl key when drag, the
mouse cursor without the plus sign indicates this is a move action.

Release the mouse button, the class member will be moved.

Model name completion for class

The model name completion feature enables quick creation of multiple views for the same class model.

When create or rename class, the list of cla sses is shown.

Type text to filter classes in the list.

Press up or down key to select class in the list, press Enter to confirm. Upon selecting an existing class,
all class members and relationships are shown immediately.

Step 5:-
Continue to complete the diagram.
Generalization set
A generalization set defines a particular set of generalization relationships that describe the way in
which a general classifier (or superclass) may be divided using specific subtypes. To define a
generalization set, select the generalizations to include, right click and select Generalization set > Create
Generalization Set... from the popup menu.

Step 6:-
Name the set in the Manage Generalization Sets dialog box, and confirm by pressing OK.
The selected generalizations are grouped. Adjust the connector to make the diagram tidy .

Repeat the steps for other generalizations.

 Experiment No.7

To draw the behavioral view diagram : Sequence diagram, Collaboration diagram

Software Required :-
Visual Paradigm for UML 8.2
Procedure :-
A sequence diagram is used primarily to show the interactions between objects that are represented
as lifelines in a sequential order.
Step 1:-
Right click Sequence diagram on Diagram Navigator and select New Sequence Diagram from the pop-
up menu to create a sequence diagram.

Step 2:-
Enter name for the newly created sequence diagram in the text field of pop-up box on the top left corner.
Creating actor
To create actor, click Actor on the diagram toolbar and then click on the diagram .

Creating lifeline
To create lifeline, you can click LifeLine on the diagram toolbar and then click on the diagram.
Alternatively, a much quicker and more efficient way is to use the resource-centric interface. Click on
the Message -> LifeLine resource beside an actor/lifeline and drag.
Step 3:-
Move the mouse to empty space of the diagram and then release the mouse button. A new lifeline will
be created and connected to the actor/lifeline with a message.

Auto extending activation

When create message between lifelines/actors, activation will be automatically extended.

Step 4:-
Using sweeper and magnet to manage sequence diagram
Sweeper helps you to move shapes aside to make room for new shapes or connectors. To use sweeper,
click Sweeper on the diagram toolbar (under the Tools category).
The picture below shows the message specify visit time is being swept downwards, thus new room is
made for new messages.

Step 5:-
You can also use magnet to pull shapes together. To use magnet, click Magnet on the
diagram toolbar (under the Tools category).

Magnet
Click on empty space of the diagram and drag towards top, right, bottom or left. Shapes affected will be
pulled to the direction you dragged.
The picture below shows when drag the magnet upwards, shapes below dragged position are pulled
upwards.

Step 6:-
Creating combined fragment for messages
To create combined fragment to cover messages, select the messages, right-click on the selection and
select Create Combined Fragment, and then select a combined fragment type (e.g. loop) from the
popup menu.

Step 7:-
A combined fragment of selected type will be created to cover the messages .

Step 8:-
Adding/removing covered lifelines
After you've created a combined fragment on the messages, you can add or remove the covered lifelines.
1. Move the mouse over the combined fragment and select Add/Remove Covered Lifeline... from the
pop-up menu.
In the Add/Remove Covered Lifelines dialog box, check the lifeline(s) you want to cover or uncheck the
lifeline(s) you don't want to cover. Click OK button.

3. As a result, the area of covered lifelines is extended or narrowed down according to your selection.

Managing Operands
After you've created a combined fragment on the messages, you can also add or remove operand(s).
1. Move the mouse over the combined fragment and select Operand > Manage Operands... from the
pop-up menu.

Step 9:-
1. To remove an operand, select the target operand from Operands and click Remove button. ClickOK
button.

2. Otherwise, click Add button to add a new operand and then name it. Click OK button.
Developing sequence diagram with quick editor or keyboard shortcuts
In sequence diagram, an editor appears at the bottom of diagram by default, which enables you to
construct sequence diagram with the buttons there. The shortcut keys assigned to the buttons provide a
 way to construct diagram through keyboard. Besides constructing diagram, you can also access diagram
elements listing in the editor.

There are two panes, Lifelines and Messages. The Lifelines pane enables you to create different kinds of
actors and lifelines.

Button Shortcut Description

Alt-Shift-A To create an actor
Alt-Shift-L To create a general lifeline
Alt-Shift-E To create an <<entity>> lifeline
Alt-Shift-C To create a <<control>> lifeline
Alt-Shift-B To create a <<boundary>> lifeline
Alt-Shift-O To open the specification of the element chosen in quick
editor
 Ctrl-Del To delete the element chosen in quick editor
Ctrl-L To link with the diagram, which cause the diagram
element to be selected when selecting an element in
editor, and vice versa
Step 10:- Buttons in Lifelines pane

Messages pane in quick editor

Button Shortcut Description
Alt-Shift-M To create a message that connects actors/lifelines in diagram
Alt-Shift-D To create a duration message that connects actors/lifelines in
diagram
Alt-Shift-C To create a create message that connects actors/lifelines in diagram
Alt-Shift-S To create a self message on an actor/lifeline in diagram
Alt-Shift-R To create a recursive message on an actor/lifeline in diagram
Alt-Shift-F To create a found message that connects to an actor/lifeline
Alt-Shift-L To create a lost message from an actor/lifeline
Alt-Shift-E To create a reentrant message that connects actors/lifelines in
diagram
Ctrl-Shift-Up To swap the chosen message with the one above
Ctrl-Shift-Down To swap the chosen message with the one below
Ctrl-R To revert the direction of chosen message
Alt-Shift-O To open the specification of the message chosen in quick editor
Ctrl-Del To delete the message chosen in quick editor
Ctrl-L To link with the diagram, which cause the message to be selected
when selecting a message in editor, and vice versa

Collapse the quick editor

Setting different ways of numbering sequence messages
You are able to set the way of numbering sequence messages either on diagram base or frame base.
Diagram-based sequence message
Right click on the diagram's background, select Sequence Number and then either Single Levelor Nested
Level from the pop-up menu.
Step 11:-
If you choose Single Level, all sequence messages will be ordered with integers on diagram base. On the
other hand, if you choose Nested Level, all sequence messages will be ordered with decimal place on
diagram base.

Right click on the diagram's background, select Sequence Number and then either Frame-based Single
Level or Frame-based Nested Level from the pop-up menu.
When you set the way of numbering sequence messages on frame base, the sequence messages in
frame will restart numbering sequence message since they are independent and ignore the way of
numbering sequence message outside the frame.