SE Lab Manual

7/30/2019 SE Lab Manual

1/26

MGMs College of Engineering Nanded -431605

Department of Computer science & engineering.

Lab Manual

For the subject Software Engineering

(Based on BE (CSE) course)

Ms. Jyoti S. Kale

Ms. Sneha V. Bhat

Subject In-charge

This manual is prepared as per the instruction provided by Swami Ramanand Teerth

Marathawada University Nanded-431605


2/26

Lab Instructions

1. All Students should reach at lab on time.

2. Students should sit on the same computer during whole semester.3. Student should use their logins to store all his/her program in it.

4. Student could take the backup of his/her program with the instructor permission.

Record Instructions:

1. Record file should be updated.

2. Record File should be checked on each turn.


3/26

Marking Scheme

Total marks: 50

Marks Distribution

Evaluation Term Work Practical Minimum Passing Marks

Scheme25 Marks 25 Marks 40%

NOTE:-

25 Marks of Term Work are divided as follows:

Theory Practical Journal & Performance Viva

Attendance Attendance Assignment

5 Marks 5 Marks 5 Marks 5 Marks 5 Marks


4/26

Practical No. 1

Aim: Study and overview of different phases in software development life cycle.

Theory:

Software for business applications, whether it is intended to perform a single task or it

is intended for use as a company-wide, integrated system, should be tailored to fit the

companys unique needs and goals. In the simplest terms, the software should be capable of

performing all the functions necessary to perform a task efficiently. While the software

should be inclusive, it should not be unduly cumbersome. Careful attention is required to

develop software that is both functional and efficient. Once the software is in use, it must be

maintained.

Software Development Life Cycle:

The term software development life cycle model is a way of describing the planning,

designing, coding, and testing of a software system, as well as the method in which these

steps are implemented. A variety of life cycle models exist, but they all include the same

constituent parts. All life cycle models take a project through several primary phases: a

requirements-gathering phase, a design phase, a construction or implementation phase, and a

testing phase.

Each phase produces feedback that affects the next phase. For instance, the

requirements gathered during the requirements phase influence the design, which is translated

into working software code during the implementation phase. The software code is verified

against the requirements during the testing phase.

Requirement Gathering:

During the requirements-gathering phase, the needs of the company are outlined.

Managers and users (and in some cases, clients) make their wish-lists about what they

would like the software to do. Analysts ask questions about the intended use of the software,

what type of data will be processed, how the software should handle the data, and how the

data can be accessed once in the system.

Following the requirements phase, the software development team should have a

detailed list of functions that the system will perform. Emphasis is on the system's goals,

rather than the way in which the system will achieve those goals.


5/26

Design:

In the design phase, the results of the requirements-gathering phase are translated into

software design plan. Focus shifts from the system's results to the way in which those results

will be achieved and how the ideas of the requirements-gathering phase are accomplished.

Designers consider many different criteria, from the hardware and operating system platform

that hosting the software to the way subsystems will communicate with each other.

In essence, during the design phase, the designers attempt to turn the dreams of the

managers and users into reality. Emphasis during this phase is on making a practical, working

design for what has been outlined in the requirements-gathering phase.

Implementation

In the implementation phase, the results of the design phase are translated into

program code. Software that does not meet the needs of the company is wasteful. During this

phase the programmers should make it their central goal to fulfill the requirements of the

company and to meet the design outlined in the design phase.

The classes and class interactions developed in the design phase are very explicit.

They translate directly into the code generated in the implementation phase.

Testing

In the testing phase, the results of the implementation phase are run through a series

of tests to verify that it functions and that it meets goals of the requirements phase. A testing

plan is created to describe the unit tests and system tests that will be performed. Unit testing

is performed on individual software components. The process of integration brings together

all the software components to create a complete system. System testing is performed on the

software system as a whole.

Conclusion:


6/26

Practical No. 2

Aim: Study and Overview of UML Environment

Theory:

1. Outline Visual modeling. Introduction to UML. Introduction to visual modeling with UML. Use case diagrams: discovering actors and use cases.

2. BackgroundVisual Modeling is a way of thinking about problems using models organized around real-

world ideas. Models are useful for understanding problems, communicating with everyone

involved with the project (customers, domain experts, analysts, designers, etc.), modeling

enterprises, preparing documentation, and designing programs and databases

2.1Visual Modeling

Capture the structure and behavior of architectures and components. Show how the elements of the system fit together. Hide or expose details appropriate for the task. Maintain consistency between a design and its implementation. Promote unambiguous communication.

2.2What is UML?The UML is the standard language for visualizing, specifying, constructing and documentingthe artifacts of a software-intensive system. UML can be used with all processes throughout

the development life cycle and across different implementation technologies.

2.3History of UMLThe UML is an attempt to standardize the artifacts of analysis and design: semantic models,

syntactic notation and diagrams. The first public draft (version 0.8) was introduced in

October 1995. Feedback from the public and Ivar Jacobson's input were included in the next

two versions (0.9 in July 1996 and 0.91 in October 1996). Version 1.0 was presented to the


7/26

Object Management Group (OMG) for standardization in July 1997. Additional

enhancements were incorporated into the 1.1 version of UML, which was presented to the

OMG in September 1997. In November 1997, the UML was adopted as the standard

modeling language by the OMG.

2.4Putting UML into Work: Use Case DiagramThe behaviour of the system under development (i.e. what functionality must be provided by

the system) is documented in a use case model that illustrates the system's intended functions

(use cases), its surroundings (actors), and relationships between the use cases and actors (use

case diagrams).

2.5Actors Are NOT part of the system they represent anyone or anything that must interact

with the system.

Only input information to the system. Only receive information from the system. Both input to and receive information from the system. Represented in UML as a stickman.

2.6Use Case A sequence of transactions performed by a system that yields a

measurable result of values for a particular actor

A use case typically represents a major piece of functionalitythat is complete from beginning to end. A use case must

deliver something of value to an actor.

2.7Use Case Relationships Between actor and use case. Association / Communication. Arrow can be in either or both directions; arrow indicates who initiates

communication.

Between use cases (generalization): Uses


8/26

Where multiple use cases share pieces of same functionality. Extends

Optional behavior. Behavior only runs under certain conditions (such as alarm). Several different flows run based on the users selection.

Result:


9/26

Practical No. 3

Aim: Introduction to System Modeling (ERD & DFD).

Theory:

1. OutlineSystem analysis model elements:

Data model: entity-relationship diagram (ERD) Functional model: data flow diagram (DFD)

2. BackgroundModeling consists of building an abstraction of reality. These abstractions are simplificationsbecause they ignore irrelevant details and they only represent the relevant details (what is

relevant or irrelevant depends on the purpose of the model).

2.1Why Model Software?Software is getting larger, not smaller; for example, Windows XP has more than 40 million

lines of code. A single programmer cannot manage this amount of code in its entirety. Code

is often not directly understandable by developers who did not participate in the

development; thus, we need simpler representations for complex systems (modeling is a

mean for dealing with complexity). A wide variety of models have been in use within various

engineering disciplines for a long time. In software engineering a number of modeling

methods are also available.

2.2Analysis Model Objectives To describe what the customer requires. To establish a basis for the creation of a software design. To define a set of requirements that can be validated once the software is built.

2.3The Elements of the Analysis ModelThe generic analysis model consists of:

An entity-relationship diagram (data model). A data flow diagram (functional model). A state transition diagram (behavioral model).


10/26

2.3.1 Entity Relationship DiagramAn entity relationship diagram (ERD) is one means of representing the objects and their

relationships in the data model for a software product.

Entity Relationship diagram notation:

To create an ERD you need to:

Define objects by underlining all nouns in the written statement of scope:producers/consumers of data, places where data are stored, and composite data

items.

Define operations by double underlining all active verbs: processes relevant to theapplication and data transformations.

Consider other services that will be required by the objects. Then you need to define the relationship which indicates connectedness: a "fact"

that must be "remembered" by the system and cannot be or is not computed or derived

mechanically.

2.3.2 Data Flow DiagramA data flow data diagram is one means of representing the functional model of a software

product. DFDs do not represent program logic like flowcharts do.

Data flow diagram notation:

Entity

Relationship

External entity

Process

Data flow

Control flow

Data store


11/26

To create a DFD you need to:

Review ERD to isolate data objects and grammatical parse to determine operations. Determine external entities (producers and consumers of data).

Create a level 0 DFD Context Diagram (one single process). Balance the flow to maintain data flow continuity. Develop a level 1 DFD; use a 1:5 (approx.) expansion ratio.

Data Flow Diagram Guidelines:

All icons must be labeled with meaningful names. Always show external entities at level 0.

Always label data flow arrows. Do not represent procedural logic. Each bubble is refined until it does just one thing.

Result:


12/26

Practical No. 4

Aim: To perform the users view analysis: Use case diagram.

Theory:

1. Outline

Visual modeling. Introduction to UML. Introduction to visual modeling with UML. Use case diagrams: discovering actors and use cases.

2.Background

Visual Modeling is a way of thinking about problems using models organized around real-

world ideas. Models are useful for understanding problems, communicating with everyone

involved with the project (customers, domain experts, analysts, designers, etc.), modeling

enterprises, preparing documentation, and designing programs and databases.

3. Use case diagramThe behaviour of the system under development (i.e. what functionality must be provided by

the system) is documented in a use case model that illustrates the system's intended functions

(use cases), its surroundings (actors), and relationships between the use cases and actors (use

case diagrams).

3.1Actors Are NOT part of the system they represent anyone or anything that must interact

with the system.

Only input information to the system. Only receive information from the system. Both input to and receive information from the system. Represented in UML as a stickman.

3.2Use Case A sequence of transactions performed by a system that yields a


13/26

measurable result of values for a particular actor

A use case typically represents a major piece of functionalitythat is complete from beginning to end. A use case must

deliver something of value to an actor.

4 Use Case Relationships Between actor and use case. Association / Communication. Arrow can be in either or both directions; arrow indicates who initiates

communication.

Between use cases (generalization): Uses

Where multiple use cases share pieces of same functionality. Extends

Optional behavior. Behavior only runs under certain conditions (such as alarm). Several different flows run based on the users selection.

Result:


14/26

Practical No. 5

Aim: To draw structural the view diagram: Class diagram.

Theory:

1. Outline Object-Oriented concepts Discovering classes approaches: noun phrase approach, common class patterns, use

case driven method, CRC (Class-Responsibility-Collaboration) and mixed approach.

Examples.

2. BackgroundClasses: a description of a group of objects with common properties (attributes) common

behaviour (operations), common relationships to other objects and common semantics.

2.1Object-Oriented Concepts Attribute: the basic data of the class. Method (operation): an executable procedure that is encapsulated in a class and is

designed to operate on one or more data attributes that are defined as part of the class. Object: when specific values are assigned to all the resources defined in a class, the

result is an instance of that class. Any instance of any class is called an object.

2.2Discovering ClassesDiscovering and defining classes to describe the structure of a computerized system is not an

easy task. When the problem domain is new or unfamiliar to the software developers it can be

difficult to discover classes; a cookbook for finding classes does not exist.

2.3Classes CategoriesClasses are divided into three categories:

Entity: models information and associated behavior that is long-lived, independent ofthe surrounding, application independent, and accomplishes some responsibility

Boundary: handles the communication between the system surroundings and theinside of the system, provides interface, and facilitates communication with other

systems


15/26

Control: model sequencing behavior specific to one or more use cases. Control classescoordinate the events needed to realize the behavior specified in the use case, and they are

responsible for the flow of events in the use case.

2.4Discovering Classes ApproachesMethods of discovering classes:

2.4.1 Noun Phrase Approach: Examine the requirements and underline each noun. Eachnoun is a candidate class; divide the list of candidate classes into:

Relevant classes: part of the application domain; occur frequently in requirements. Irrelevant classes: outside of application domain Fuzzy classes: unable to be declared relevant with confidence; require additional

analysis

2.4.2 Common Class Patterns: Derives candidate classes from the classification theory ofobjects; candidate classes and objects come from one of the following sources:

Tangible things: e.g. buildings, cars. Roles: e.g. teachers, students. Events: things that happen at a given date and time, or as steps in an ordered

sequence: e.g. landing, request, interrupt.

Interactions: e.g. meeting, discussion. Sources, facilities: e.g. departments. Other systems: external systems with which the application interacts. Concept class: a notion shared by a large community. Organization class: a collection or group within the domain. People class: roles people can play. Places class: a physical location relevant to the system.

2.4.3 Use Case Driven Method: The scenarios - use cases that are fundamental to thesystem operation are enumerated. Going over each scenario leads to the identification

of the objects, the responsibilities of each object, and how these objects collaborate

with other objects.


16/26

2.4.4 CRC (Class-Responsibility-Collaboration): Used primarily as a brainstorming toolfor analysis and design. CRC identifies classes by analyzing how objects collaborate

to perform business functions (use cases).

A CRC card contains: name of the class, responsibilities of the class and collaborators

of the class. Record name of class at the top; record responsibilities down the left-

hand side; record other classes (collaborators) that may be required to fulfill each

responsibility on the right-hand side.

CRC cards are effective at analyzing scenarios; they force you to be concise and clear;

they are cheap, portable and readily available.

2.4.5 Mixed Approach: A mix of these approaches can be used, one possible scenario is: Use CRC for brainstorming. Identify the initial classes by domain knowledge. Use common class patterns approach to guide the identification of the classes. Use noun phrase approach to add more classes. Use the use case approach to verify the identified classes.

2.5Class Elicitation Guidelines A class should have a single major role. A class should have defined responsibilities (use CRC cards if needed). Classes should be of a manageable size: if a class has too many attributes or

operations, consider splitting it.

A class should have a well-defined behavior, preferably by implementing a givenrequirement or an interface.

Result:


17/26

Practical No. 6

Aim: To draw the behavioural view diagram: Sequence diagram.

Theory:

1. Outline Interaction diagrams:

o Sequence diagrams

2. BackgroundInteraction diagrams describe how groups of objects collaborate in some behavior. An

interaction diagram typically captures the behavior of a single use case. Interaction diagramsdo not capture the complete behavior, only typical scenarios.

2.1Analyzing a Systems BehaviorUML offers two diagrams to model the dynamics of the system: sequence and collaboration

diagrams. These diagrams show the interactions between objects.

2.2Sequence DiagramsSequence diagrams are a graphical way to illustrate a scenario:

They are called sequence diagrams because they show the sequence of messagepassing between objects.

Another big advantage of these diagrams is that they show when the objects arecreated and when they are destructed. They also show whether messages are

synchronous or asynchronous

2.3Creating Sequence Diagrams You must know the scenario you want to model before diagramming sequence

diagrams.

After that specify the classes involved in that scenario. List the involved objects in the scenario horizontally on the top of the page. Drop a dotted line beneath every object. They are called lifelines. The scenario should start by a message pass from the first object. You must know how to place the objects so that the sequence is clear.


18/26

You may start the scenario by an actor. Timing is represented vertically downward. Arrows between life lines represents message passing.

Horizontal arrows may pass through the lifeline of another object, but must stop atsome other object.

You may add constraints to these horizontal arrows. Objects may send messages to themselves. Long, narrow rectangles can be placed over the lifeline of objects to show when the

object is active. These rectangles are called activation lines.

Result:


19/26

Practical No. 7

Aim: To draw the behavioural view diagram: Activity diagram.

Theory:

1. Outline Writing flow of events. Activity diagrams. Examples.

2. BackgroundEach use case is documented with a flow of events. The flow of events for a use case is adescription of the events needed to accomplish the required behavior of the use case. Activity

diagrams may also be created at this stage in the life cycle. These diagrams represent the

dynamics of the system. They are flow charts that are used to show the workflow of a system;

that is, they show the flow of control from one activity to another in the system,

2.1Flow of EventsA description of events required to accomplish the behavior of the use case, that:

Show WHAT the system should do, not HOW the system does it. Written in the language of the domain, not in terms of implementation. Written from an actor point of view.

A flow of events document is created for each use case:

Actors are examined to determine how they interact with the system. Break down into the most atomic actions possible.

2.2Contents of Flow of Events When and how the use case starts and ends. What interaction the use case has with the actors. What data is needed by the use case. The normal sequence of events for the use case. The description of any alternate or exceptional flows.

2.3Activity Diagrams


20/26

Activity diagrams are flow charts that are used to show the workflow of a system. They also:

Represent the dynamics of the system. Show the flow of control from activity to activity in the system.

Show what activities can be done in parallel, and any alternate paths through the flow.Activity diagrams may be created to represent the flow across use cases or they may be

created to represent the flow within a particular use case. Later in the life cycle, activity

diagrams may be created to show the workflow for an operation.

2.4Activity Diagram Notation Activities- performance of some behavior in the workflow. Transition- passing the flow of control from activity to activity. Decision- show where the flow of control branches based on a decision point:

o Guard condition is used to determine which path from the decision point istaken.

Synchronization-what activities are done concurrently? What activities must becompleted before processing may continue (join).

Result:


21/26

Practical No. 8

Aim: To draw the behavioral view diagram: State diagram.

Theory:

1. Outline UML state diagrams. UML state diagram notation UML state details Examples

2. BackgroundMainly, we use interaction diagrams to study and model the behavior of objects in our

system. Sometimes, we need to study the behavior of a specific object that shows complex

behavior to better understand its dynamics. For that sake, UML provides state transition

diagrams used to model the behavior of objects of complex behavior. In this Lab, UML state

transition diagrams will be introduced. We will study their notation and how can we model

them using Rational Rose.

2.1UML State DiagramsState diagrams show how one specific object changes state as it receives and processes

messages:

Since they are very specific, they are used for analyzing very specific situations if wecompare them with other diagrams.

A state refers to the set of values that describe an object at a specific moment in time. As messages are received, the operations associated with the objects parent class are

invoked to deal with the messages.

These messages change the values of these attributes. There is no need to prepare a state diagram for every class you have in the system.

2.2Creating State Transition Diagrams States are represented by rectangles with rounded corners with an attribute name with

a values associated with it.

The name of the state is placed within the box.


22/26

Events are shown by arrows. An event occurs when at an instant in time when a value is changed. A message is data passed from one object to another.

The name of a state usually refers to the name of the attribute and the valuesassociated to it.

Example, a student object may receive a message to change its name. The state of thatobject changes from the first name state to the new state name.

The name of the state is placed in the top compartment. State variables are placed in the next compartment. The operations associated with the state are listed in the lowest compartment of the

state box. In the operations part, we usually use one of the following reserved words:

o Entry: a specific action performed on the entry to the state.o Do: an ongoing action performed while in the state.o On: a specific action performed while in the state.o Exit: a specific action performed on exiting the state.

There are two special states added to the state transition diagram- start state and endstate.

Notation of start state is a solid black circle and for the end state a bulls eye is used.

2.3State Transition Details A state transition may have an action and/or guard condition associated with it and it

may also trigger an event.

An action is the behavior that occurs when the state transition occurs. An event is a message that is sent to another object in the system. A guard condition is a Boolean expression of attribute values that allows a state

transition only if the condition is true.

Both actions and guards are behaviors of the object and typically become operations.Also they are usually private operations (used by the object itself)

Actions that accompany all state transitions into a state may be placed as an entryaction within the state.

Actions that accompany all state transitions out of a state may be placed as exitactions within the state


23/26

A behavior that occurs within the state is called an activity. An activity starts when the state is entered and either completes or is interrupted by an

outgoing state transition.

A behavior may be an action, or it may be an event sent to another object.

This behavior is mapped to operations on the object.

State transition diagram notation:

Result:

Event causing transition

Action that occurs

New State

[entry:]

State

[entry:]


24/26

Practical No. 9

Aim: To draw the environmental view diagram: Deployment diagram.

Theory:

1. Outline Implementation diagram: deployment diagrams. Examples.

2. BackgroundImplementation diagrams capture design information. The main implementation diagrams in

UML are: component and deployment diagrams. In this Lab we will study this diagrams andits notation.

2.1UML Implementation DiagramsThe main implementation diagrams we have in UML are: component diagrams and

deployment diagrams. These diagrams are high level diagrams in comparison with old

diagrams you have already learned.

2.2Deployment DiagramsA deployment diagram shows processors, devices and connections. Each model contains a

single deployment diagram which shows the connections between its processors and devices,

and the allocation of its processes to processors.

2.4.1 Deployment Diagrams: Processor

A processor is a hardware component capable of executing programs.

A processor is given a name and you should specify the processes that will run on that

processor.

You can also specify the scheduling of these processes on that processor. Types of scheduling are:

o Pre-emptive: a higher priority process may take the process from lowerpriority one.

o Non-preemptive: a process will own the processor until it finisheso Cyclic: control passes from one process to another.


25/26

o Executive: an algorithm controls the scheduling of the processeso Manual: scheduling buy the user.

2.4.2 Deployment Diagrams: Device

A device is a hardware component with no computing power. Each device must have a name.

Device names can be generic, such as modem or terminal.

2.4.3 Deployment diagrams: Connection

A connection represents some type of hardware coupling between two entities. An entity is

either a processor or a device. The hardware coupling can be direct, such as an RS232 cable,

or indirect, such as satellite-to-ground communication. Connections are usually bi-

directional.

Result:


26/26

Practical No. 10

Aim: To perform unit testing using the testing tool.

Theory:

1. Outline Overview of software testing. Unit testing.

2. BackgroundTesting is the process of executing a program with the intent of finding errors. A good test

case is one with a high probability of finding an as-yet undiscovered error. A successful testis one that discovers an as-yet-undiscovered error.

The causes of the software defects are: specification may be wrong; specification may be a

physical impossibility; faulty program design; or the program may be incorrect.

2.1Basic Definitions A failure is an unacceptable behavior exhibited by a system.

A defect is a flaw in any aspect of the system that contributes, or may potentiallycontribute, to the occurrence of one or more failures. It might take several defects to

cause a particular failure.

An error is a slip-up or inappropriate decision by a software developer that leads tothe introduction of a defect.

2.2Good Test AttributesA good test has a high probability of finding an error, not redundant, and should not be too

simple or too complex.

2.3Unit TestingUnit testing is testing each unit separately. In unit testing interfaces tested for proper

information flow and local data are examined to ensure that integrity is maintained. Boundary

conditions and all error handling paths should also be tested.

Result:

Documents

SE Lab Manual