Se Lab Kcs 661
Se Lab Kcs 661
Se Lab Kcs 661
Practical File
0
PRACTICAL-1
Experiment Name: Prepare a SRS document in line with the IEEE
recommended standards.
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Project Scope 1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 Assumptions and Dependencies
3. System Features
3.1 Functional Requirements
5. Non-functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
PRACTICAL-2
Experiment Name: Draw the use case diagram and specify the role of each of the
actors Also state the precondition, post condition and function of each use case.
● Actor
● Use case
● System
● Package
1. Actor
An actor is a person, organization, or external system that plays a role in one or more interactions
with your system (actors are typically drawn as stick figures on UML Use Case diagrams).
2. Usecase
A use case describes a sequence of actions that provide a measurable value to an actor. A use case is
drawn as a horizontal ellipse on a UML use case diagram.
3. System
The system is used to define the scope of the usecase and drawn as a rectangle. This an optional
element but useful when you re v1suahzing large systems. For exam le, you can create all the use
cases and then use the system object to define the scope.
4. Packages
structural diagrams used to show the organization and arrangement of various model elements in
the form of packages.
USECASE DIAGRAM:
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 popup 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 <> 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: 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.
PRACTICAL-3
Experiment Name: Draw the activity diagram.
Activity diagram:
Activity diagrams can be used in all stages of software development and for various
purposes. And because they are a lot similar to flowcharts, they are generally more
popular than other UML diagram types.
A UML activity diagram helps to visualize a certain use case at a more detailed level. It is a
behavioural diagram that illustrates the flow of activities through a system.
A class diagram is a visual representation of the classes, their attributes, and their relationships in a
software system, providing a static view of its structure.
A description of a group of objects all with similar roles in the system, which consists of:
• Behavioural features (operations) define what objects of the class "can do".
2. Attributes: The attributes or properties of the class, listed in the middle section of the class
box, typically in the format "attributeName: attributeType".
3. Methods: The methods or operations of the class, written in the bottom section of the class
box, usually in the format "methodName(parameterList): returnType".
4. Visibility Markers: Symbols such as "+" for public, "-" for private, "#" for protected, and "~"
for package level, indicating the visibility of attributes and methods.
Analysing System Logic and Communication: Sequence diagrams help in analysing the logic
and communication flow within a system. They provide insights into the order of method
invocations, the timing of events, and the dependencies between objects, allowing for the
identification of potential issues or optimizations.
Designing and Documenting System Architecture: Sequence diagrams are useful for
designing and documenting the system architecture. They assist in defining the
responsibilities and collaborations between objects, refining the system's design, and
communicating the intended behaviour to the development team and other stakeholders.
An example of a UML 2.0 Sequence Diagram showing the sequence of events involved
in an email system.
PRACTICAL-6
Experiment Name: Draw the collaboration diagram.
•To model the reactive system. Reactive system consists of reactive objects.
Forward engineering is thus related to the term 'reverse engineering, ' where there is an effort to
build backward, from a coded set to a model, or to unravel the process of how something was put
together.
Forward engineering is the process of building from a high-level model or concept to build in
complexities and lower-level details. This type of engineering has different principles in various
software and database processes
4. Artifacts: Artifacts represent physical files or software packages that are deployed on nodes.
They are represented by rectangles with labeled names.
1. System Deployment Planning: They help in planning the deployment and distribution of
software components on different nodes or environments.
2. Infrastructure Design: They assist in designing the physical infrastructure required to support
the software deployment, such as servers, networks, and storage.
3. System Configuration: They provide guidance for configuring and setting up the
software components on the target nodes or environments.
This example shows a basic deployment diagram for Lucid chart. There is a web server, a database
server, and the machine where the user views the website. You can add more complexity by
showing the different parts of the web server and the way Javascript works on the User Client, but
this example gives you an idea of how a deployment looks in UML notation.