SDL-LAB-MANUAL-CS606-common-for-all-the-faculties.pdf

SHRI RAM INSTITUTE OF
TECHNOLOGY, JABALPUR
LAB MANUAL
Skill Development Lab CS 606
6th
Sem
Batch 2021-2022
Shri Ram Institute of Technology, Jabalpur (M.P.)
Near ITI, Madhotal , Jabalpur, M.P., 482001

INDEX
S.NO TOPIC Page No.
1. Vision & Mission of the Institute 1
2. Vision & Mission of the Department 2
3. Program Outcomes (PO) 3
4. Program Specific Outcome (PSO) 4
5. Program Educational Objectives (PEOs) 5
6. Scheme 6
7. List of Experiments 7
8. Course Outcome 8
9. Mapping 9
10. Experiments 10-37

1
VISION & MISSION OF THE INSTITUTE
VISION
To provide quality education and to inculcate professional skills in students so that they hold
competitive edge in the healthy environment and excel in their profession with sound ethical basis for
betterment of the society.
MISSION
To progressively develop an efficiently functioning engineering/technological institution that will
produce world class engineering graduates and post graduates committed to the spirit of integrity,
equity, professional ethics and social harmony.

2
VISION & MISSION OF THE DEPARTMENT
VISION
Creating ethical leaders in the field of computational sciences by quality vocational education with an
emphasis on comprehensive learning and excellence.
MISSION
M1. To provide qualitative education and generate new knowledge through effective teaching
learning methodologies, resulting in careers as computer and IT professionals in the widely diversified
fields of business, government and academia.
M2. To transform lives of the students by imparting ethical values, sustainable skills, creativity, and
uniqueness in them, allowing them to become entrepreneurs and start businesses.
M3. To encourage students to learn about emerging technologies in order to continue higher education
and lifelong learning.

3
PROGRAM OUTCOMES
PO1 Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex engineering
problems.
PO2 Problem analysis: Identify, formulate review research literature and analyze complex
engineering problems reaching substantiated conclusions using first principle of
mathematics, natural science and engineering science.
PO3 Design/development of solutions: Design solutions for complex engineering problems and
design system components or processes that meet the specified needs with appropriate
consideration for the public health and safety, and the cultural, societal, and environmental
considerations.
PO4 Conduct investigations of complex problems: Use research-based knowledge and research
methods including design of experiments, analysis and interpretation of data, and synthesis
of the information to provide valid conclusions.
PO5 Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern
engineering and IT tools including prediction and modeling to complex engineering
activities with an understanding of the limitations.
PO6 The engineer and society: Apply reasoning informed by the contextual knowledge to assess
societal, health, safety, legal and cultural issues and the consequent responsibilities relevant
to the professional engineering practice.
PO7 Environment and sustainability: Understand the impact of the professional engineering
solutions in societal and environmental contexts, and demonstrate the knowledge of, and
need for sustainable development.
PO8 Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
PO9 Individual and team work: Function effectively as an individual, and as a member or leader
in diverse teams, and in multidisciplinary settings.
PO10 Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give and
receive clear instructions.
PO11 Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one's own work, as a member
and leader in a team, to manage projects and in multidisciplinary environments.
PO12 Life-long learning: Recognize the need for, and have the preparation and ability to engage in
independent and life-long learning in the broadest context of technological change.

4
PROGRAM SPECIFIC OUTCOMES
PSO1 Professional Skills: Acquire practical knowledge of emerging trends, programming
languages, and development-tools.
PSO2 Successful Career and Entrepreneurship: Gain expertise in a variety of fields of
computer science and experience an environment that fosters the development of
abilities for a successful profession, entrepreneurship, and higher learning.

5
PROGRAMME EDUCATIONAL OBJECTIVES (PEOs)
PEO 1 To impart fundamental theoretical and practical knowledge in computer science and
engineering in order to pursue a successful career in industry, higher
education, or entrepreneurial endeavors.
PEO 2
Build the ability to think logically, evaluate, and make decisions ethically in order to
provide a techno-commercially viable and socially acceptable solution to real-world
computing challenges
PEO 3
Participate in continuous learning to promote sustainable growth in the area of modern
computer technological domains.

6
SCHEME

7
LIST OF EXPERIMENT
S.No. List of Experiments CO PO PSO
1. Software Product as Life Cycle :
SDLC (Software Development Life Cycle) Phases,
SDLC models, Agile Model, Agile Vs Traditional SDLC
Models
1 1,2,3,5,10, 12 1,2
2. Software Products development standards :
Software quality management, Quality assurance, planning,
management, Process and product quality, ISO Standard,
Product metrics
2 1,2,3,5,10, 12 1,2
3. Design Pattern -1 :
To perform the user‘s view analysis for the suggested system:
Use case diagram.
1, 3 1,2,3,4,5,10,12 1
4. Do requirement analysis and develop Software Requirement
Specification Sheet (SRS).
2 1,2,3,5,10,12 1,2
5. To perform the function oriented diagram:
Data Flow Diagram (DFD) and Structured chart.
3 1,2,3,5 1
6. To study and perform analysis on Functional and Non
Function Requirement.
3 1,2,3,4,5, 1
7. Design Pattern -2 :
To draw the structural view diagram for the system: Class
diagram, object diagram.
3 1,2,3,4,5 1
8. To perform the implementation Activity diagram for the
system.
3 1,2,3,4,5 1
9. Case Study:
To perform various testing using the testing tool unit testing,
integration testing for a sample code of the suggested system.
2, 4 1,2,3,4,5,12 1
10. To prepare the Business Model of your project. 4 1,2,3,4,5 1, 2
ADDITIONAL LIST OF EXPERIMENT
11. Draw use case diagram along with use case description. 2,4 1,2,3,4,5,12 1
12. Develop UML use case model for a problem. 4 1,2,3,4,5 1,2

8
COURSE OUTCOME (CO)
CS606.1 Understand the basics of software as a product.
CS606.2 Understand the current requirements of industries.
CS606.3 Implement the software as a product using different design patterns.
CS606.4 Apply the software development techniques in real life applications.

9
MAPPING
Mapping of Course Outcomes and Program Outcomes:
*H= High (3) *M= Medium (2) *L=Low (1)
COs PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12
CS606[P].1 1 3 2 1 2 0 0 0 2 2 0 2
CS606[P].2 2 3 3 2 3 0 0 0 2 2 2 2
CS606[P].3 3 3 3 2 3 0 0 0 2 2 1 1
CS606[P].4 2 3 3 2 3 0 0 0 2 2 1 1
Mapping of Program Specific Outcomes and Course Outcomes:
Program Specific Outcomes
Course Outcomes
1 2 3 4 5
1 2 1 2 2 2
2 1 1 1 2 2

10
EXPERIMENT No.-1
Aim: S/w Product as Life Cycle: (Software Development Life Cycle) Phases,
SDLC models, Agile Model, Agile Vs Traditional SDLC Models
Theory: Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high-quality software that meets or exceeds
customer expectations, reaches completion within times and cost estimates.
The SDLC process includes planning, designing, developing, testing and deploying with ongoing maintenance
to create and manage applications efficiently.
There are 7 stages of Software Development Life Cycle.
1. Planning and Requirement Analysis
2. Defining Requirements
3. Designing the Product Architecture
4. Building or Developing the Product
5. Testing the Product
6. Deployment in the Market
7. Maintenance

11

12
Waterfall SDLC Model
Waterfall is a cascade SDLC model, in which development process looks like the flow, moving step by
step through the phases of analysis, projecting, realization, testing, implementation, and support. This
SDLC model includes gradual execution of every stage completely. This process is strictly documented
and predefined with features expected to every phase of this software development life cycle model.
The Waterfall SDLC Model
Advantages of waterfall model
 Simple to use and understand

13
 Management simplicity thanks to its rigidity. Every phase has a defined result and process
review.
 Development stages go one by one.
 Perfect for the small or mid-sized projects where requirements are clear and not equivocal.
 Easy to determine the key points in the development cycle.
Disadvantages of waterfall model
 The software is ready only after the last stage is over.
 High risks and uncertainty.
 Not the best choice for complex and object-oriented projects.
 Inappropriate for the long-term projects.
 The progress of the stage is hard to measure while it is still in the development.
Agile Model
The meaning of Agile is swift or versatile."Agile process model" refers to a
software development approach based on iterative development. Agile methods
break tasks into smaller iterations, or parts do not directly involve long term
planning. The project scope and requirements are laid down at the beginning of
the development process. Plans regarding the number of iterations.
Phases of Agile Model:
Following are the phases in the agile model are as follows:
1. Requirements gathering
2. Design the requirements

14
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
Feedback ope of each iteration are clearly defined in advance.
Phases of Agile Model:
Following are the phases in the agile model are as follows:
6. Requirements gathering
7. Design the requirements
8. Construction/ iteration
9. Testing/ Quality assurance
10. Deployment
11. Feedback
1. Requirements gathering: In this phase, you must define the requirements. You should explain
business opportunities and plan the time and effort needed to build the project. Based on this
information, you can evaluate technical and economic feasible.

15
2. Design the requirements: When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML diagram to show the work of
new features and show how it will apply to your existing system.
3. Construction/ iteration: When the team defines the requirements, the work begins. Designers and
developers start working on their project, which aims to deploy a working product. The product will
undergo various stages of improvement, so it includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks for
the bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback
about the product and works through the feedback.
Agile Testing Methods:
o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

16
EXPERIMENT NO. 02
Aim: Software Products development standards:
Software quality management, Quality assurance, planning, management, Process and product quality,
ISO Standard, Product metrics
Theory: - Software product development is a repetitive logical process that aims to builds a
programmed software product to mark a unique personal or business goal, process, or objective.
It is mostly a planned strategy that comprises various stages or steps that result in the creation of an
operational software product.
Software product development basically implies the deployment of a set of features in a software
product tailored to meet certain needs of a market. Software product development is a repetitive logical
process that aims to builds a programmed software product to mark a unique personal or business goal,
process, or objective. It is mostly a planned strategy that comprises various stages or steps that result in
the creation of an operational software product.
4 Basic Type of Software Products as per our Business Needs
1. System Software Products
Systems software programs manage the resources of the computer system that help simplify
application programming. They include software such as the operating system, database
management systems, networking software, translators, and software utilities.
2. Programming Software Products
Programming software also knows as development tools such as compilers, text editors, debuggers,
linker are programs or set of programs which help software developers in creating, debugging, and
maintaining other programs and apps.
3. Application Software Products:
Application Software is an application or product that can be used to perform tasks. Famous examples
of application software are data management software, Office productivity suites, media players, etc.
4. Embedded Software Products:
Embedded System Software products are used to control machines and devices through
telecommunications networks, industrial robots, cars, and more.

17
EXPERIMENT NO. 03
Aim: Design Pattern -1: To perform the user‘s view analysis for the suggested system:
Use case diagram.
Theory: Use case diagram is a behavioral UML diagram type and frequently used to
analyze various systems. They enable you to visualize the different types of roles
in a system and how those roles interact with the system. This use case
diagram tutorial will cover the following topics and help you create use cases better.
Importance of Use Case Diagrams
As mentioned before use case diagrams are used to gather a usage requirement of
a system. Depending on your requirement you can use that data in different ways.
Below are few ways to use them.
 To identify functions and how roles interact with them – The primary
purpose of use case diagrams.
 For a high-level view of the system – Especially useful when presenting to
managers or stakeholders. You can highlight the roles that interact with the
system and the functionality provided by the system without going deep into
inner workings of the system.
 To identify internal and external factors – This might sound simple but in
large complex projects a system can be identified as an external role in
another use case.
Use Case Diagram objects
Use case diagrams consist of 4 objects.
 Actor
 Use case
 System
 Package

18

19
EXPERIMENT NO.4
Aim: Do requirement analysis and develop Software Requirement Specification Sheet (SRS).
Theory: Typically a SRS is written by a technical writer, a systems architect, or a software
programmer.
An SRS can be simply summarized into four Ds:
1. Define your product's purpose.
2. Describe what you're building
3. Detail the requirements.
4. Deliver it for approval.
An SRS gives us a complete picture of our entire project. It provides a single source of truth that every
team involved in development will follow. It is our plan of action and keeps all our teams — from
development to maintenance.

20
EXPERIMENT NO. 05
Aim: To perform the function oriented diagram: Data Flow Diagram (DFD) and Structured chart.
Theory:
Function Oriented Design Strategies:
Function Oriented Design Strategies are as follows:
1. Data Flow Diagram (DFD):
A data flow diagram (DFD) maps out the flow of information for any process or system. It uses
defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.
2. Data Dictionaries:
Data dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirement stage, data dictionaries contains data items. Data dictionaries include
Name of the item, Aliases (Other names for items), Description / purpose, Related data items,
Range of values, Data structure definition / form.
3. Structure Charts:
It is the hierarchical representation of system which partitions the system into black boxes
(functionality is known to users but inner details are unknown). Components are read from top to
bottom and left to right. When a module calls another, it views the called module as black box,
passing required parameters and receiving results.
Function Oriented Design is an approach to software design where the design is decomposed into a
set of interacting units where each unit has a clearly defined function.
a. Generic Procedure:
Start with a high level description of what the software / program does. Refine each part of the
description one by one by specifying in greater details the functionality of each part. These
points lead to Top-Down Structure.

21
b. Problem in Top-Down design method:
Mostly each module is used by at most one other module and that module is called its Parent
module.
Solution to the problem:
Designing of reusable module. It means modules use several modules to do their required
functions.

22
EXPERIMENT NO. 06
Aim: To study and perform analysis on Functional and Non Function Requirement.
Theory: Functional Requirements: These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system
as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation
performed and the output expected. They are basically the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.
Non-functional requirements: These are basically the quality constraints that the system must satisfy according to
the project contract. The priority or extent to which these factors are implemented varies from one project to other.
They are also called non-behavioral requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility

23
EXPERIMENT NO. 07
Aim:- Design Pattern -2: To draw the structural view diagram for the system: Class diagram, object diagram.
Theory: Design patterns are typical solutions to commonly occurring problems in software design. They are like
pre-made blueprints that you can customize to solve a recurring design problem in your code. You can't just find a
pattern and copy it into your program, the way you can with off-the-shelf functions or libraries.
Three Types of Design Patterns (Behavioral, Creational, Structural) Distinguish between
Behavioral, Creational, and Structural Design Patterns.
A design pattern is a general reusable solution to a commonly occurring problem within a given context. What does
that mean?
Programmers often encounter the same problem repeatedly. Rather than have everyone come up with their own
solution to common programming issues, we use a best practice type solution that has been documented and proven to

24
work.
The word general is important. We cannot just copy and paste a design pattern into our code. A design pattern
represents an idea, and we should write an implementation for that pattern and implement that in our code.
Advantages of Design Patterns
Using a design pattern has a few advantages. We get to use a solution that is known to work. The tradeoffs, if any, are
well documented, so we do not stumble over problems that have already been solved. In addition, design patterns also
serve as communication aids. Your project manager can say, "We will use a singleton,"" and that one word is enough
to tell you what is expected.
When books or web pages document patterns, they do so using a consistent format. We pay homage to this universal
format by including sections for the
1. Problem,
2. Solution, and
3. Benefits of the singleton pattern.

25
EXPERIMENT NO. 08
Aim: To perform the implementation Activity diagram for the system.
Theory: - To Draw an Activity Diagram
1. Step 1: Figure out the action steps from the use case. Here you need to identify the various activities and
actions your business process or system is made up of.
2. Step 2: Identify the actors who are involved. ...
3. Step 3: Find a flow among the activities. ...
4. Step 4: Add swimlanes.
The purpose of an activity diagram can be described as −
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

26
Before drawing an activity diagram, we must have a clear understanding about the elements used in activity diagram.
The main element of an activity diagram is the activity itself. An activity is a function performed by the system. After
identifying the activities, we need to understand how they are associated with constraints and conditions.
Before drawing an activity diagram, we should identify the following elements −
 Activities
 Association
 Conditions
 Constraints

27
EXPERIMENT NO. 09
Aim: - Case Study: - To perform various testing using the testing tool unit testing, integration testing for a sample
code of the suggested system.
Theory: - Unit testing is a kind of white box testing, whereas Integration Testing is a kind of black-box testing.
For Unit Testing, accessibility of code is required, as it tests the written code, while for Integration Testing, access to
code is not required, since it tests the interactions and interfaces between modules.
Unit Testing is a type of software testing where individual units or components of a software are tested. The purpose
is to validate that each unit of the software code performs as expected. Unit Testing is done during the development
(coding phase) of an application by the developers. Unit Tests isolate a section of code and verify its correctness. A
unit may be an individual function, method, procedure, module, or object.
Unit Testing is of two types
 Manual
 Automated
Unit testing is commonly automated but may still be performed manually. Software Engineering does not favor one
over the other but automation is preferred. A manual approach to unit testing may employ a step-by-step instructional
document.

28
EXPERIMENT NO. 10
Aim: - To prepare the Business Model of the project.
Case Study: - The term business model refers to a company's plan for making a profit. It identifies the products or
services the business plans to sell, its identified target market, and any anticipated expenses. Business models are
important for both new and established businesses. They help new; developing companies attract investment, recruit
talent, and motivate management and staff.
KEY TAKEAWAYS
 A business model is a company's core strategy for profitably doing business.
 Models generally include information like products or services the business plans to sell, target markets, and
any anticipated expenses.
 There are dozens of types of business models including retailers, manufacturers, fee-for-service, or freemium
providers.
 The two levers of a business model are pricing and costs.
 When evaluating a business model as an investor, consider whether the product being offer matches a true
need in the market.
Evaluating Successful Business Models
A common mistake many companies make when they create their business models is to underestimate the costs of
funding the business until it becomes profitable. Counting costs to the introduction of a product is not enough. A
company has to keep the business running until its revenues exceed its expenses.
Types of Business Models
There are as many types of business models as there are types of business. For instance, direct sales, franchising,
advertising-based, and brick-and-mortar stores are all examples of traditional business models. There are hybrid
models as well, such as businesses that combine internet retail with brick-and-mortar stores or with sporting
organizations like the NBA.
Retailer, Manufacturer, Fee-for-Service,Subscription, Freemium, Bundling, Marketplace

29
EXPERIMENT NO. 11
Aim: - Draw use case diagram along with use case description.
Case Study:- Use case diagram is a behavioral UML diagram type and frequently used to analyze various
systems. They enable you to visualize the different types of roles in a system and how those roles interact with the
system. This use case diagram tutorial will cover the following topics and help you create use cases better.
 Importance of use case diagrams
 Use case diagram objects
 Use case diagram guidelines
 Relationships in use case diagrams
o Identifying actors
o Identifying use cases
o When to use “Include”
o How to use generalization
o When to use “Extend”
Importance of Use Case Diagrams
As mentioned before use case diagrams are used to gather a usage requirement of a system. Depending on your
requirement you can use that data in different ways. Below are few ways to use them.
 To identify functions and how roles interact with them – The primary purpose of use case diagrams.
 For a high-level view of the system – Especially useful when presenting to managers or stakeholders. You
can highlight the roles that interact with the system and the functionality provided by the system without going
deep into inner workings of the system.
 To identify internal and external factors – This might sound simple but in large complex projects a system
can be identified as an external role in another use case.
Use Case Diagram objects
Use case diagrams consist of 4 objects.
 Actor
 Use case
 System
 Package

30
EXPERIMENT NO. 12
Aim: - Develop UML use case model for a problem.
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-eventseditor 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.

31
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 newlycreated 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 createdactor when it is created.

32
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 usecase will be line-wrapped automatically.

33
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 caseare connected. After you name the newly created use case, a pop-up dialog box will ask
whether you want the extension

34
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).

35
Step 10:
Create a package
Drag the mouse to create a package surrounding those use cases.
Step 11:
Surround use cases with
package finally, name the
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.

36
Step 13:
Use Case Diagram tab
The description of options for ID generator format is shown below.
Option
Description
Prefix The prefix you enter in Prefix text field will be inserted before the number.
Num of digits The number of digits for the number. For example, when digit is 3, ID "1" will
become "001".
Suffix The suffix you enter in Suffix text field will be inserted behind the number.
Options for formatting ID
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 usecase.
Step 14 :
Show ID on diagram
As a result, the use case is displayed with ID.
A use case with ID displayed
NOTE: The feature of showing ID does only support for use case, but not for
actor.
ID assignment
There are several ways that you can assign an ID to a model element, including:
 Through the specification dialog box (Right click on the selected model element and select Open
Specification... from thepop-up menu)
 Through the Property Panel.
Drawing business use case
1. Right click on a use case and select Model Element Properties > Business Model from the pop-up menu.

37
Step 15:
Click Business Model
After selected, an extra slash will be shown on the left edge of the use case.
Business model
And Finally the Use case Diagram is ready.

38

SDL-LAB-MANUAL-CS606-common-for-all-the-faculties.pdf

More Related Content

What's hot

Similar to SDL-LAB-MANUAL-CS606-common-for-all-the-faculties.pdf

Recently uploaded

SDL-LAB-MANUAL-CS606-common-for-all-the-faculties.pdf