CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdf

SOFTWARE ENGINEERING
(CSE 2014)
Presidency School of Computer Science and
Engineering

Assessment Schedule
S. No Assessment type Contents
Course Outcome
Number
Duration In
Hours
Marks Weightage DATE
1 Surprise Test - 1 Module 1 CO1 30 Mins 10 5%
10.09.24 -
14.09.24
2 Assignment - 1 Module 2 CO2 1 week 10 5%
22.10.24 -
26.10.24
3 Mid Term Module 1 & 2 CO1 & CO2 90 Mins 50 25%
15.10.24 -
21.10.24
4 Surprise Test - 2 Module 3 CO3 30 Mins 10 5%
11.11.24 -
15.11.24
5 Assignment - 2 Module 4 CO4 1 week 10 5%
09.12.24 -
14.12.24
6 Presentation Module 3 & 4 CO3 & CO4 30 Mins 10 5%
16.12.24 -
20.12.24
7 End Term Module – 1 to 4
CO1, CO2,
CO3,CO4
180 Mins 100 50%
05.01.25 -
15.01.25

Module - 2
Software Requirements, Analysis and Design
Requirements Engineering: Eliciting requirements, Functional and non- Functional requirements,
Software Requirements Specification (SRS), Requirement Analysis and validation. Requirements
modelling- Introduction to Use Cases, Activity diagram and Swim Lane diagram. CASE-
Characteristics of CASE Tools, Architecture of a CASE Environment.
Design: Design concepts, Architectural design, Component based design, User interface design.

CO2: Identify the requirements, analysis and appropriate
design models for a given application

L12: Requirement Engineering: Eliciting Requirements
LO: Define Requirement Engineering

CONTENTS
Requirements Engineering:
1. Eliciting requirements
2. Functional and non- Functional requirements
3. Software Requirements Specification (SRS)
4. Requirement Analysis and validation.

Requirements Engineering
• Requirement is a capability or condition required from the system.
• Requirements engineering is the process of gathering, analyzing,
documenting, validating, and managing requirements.
• The main goal: clearly understand the customer requirements and
systematically organize these requirements in the SRS.
• Software Requirements specification (SRS) document.

It encompasses seven distinct tasks:
• Inception - The project's scope, goals, and requirements are identified and
defined.
• Elicitation - The process of gathering and discovering requirements from
stakeholders, users, and other sources.
• Elaboration - The process of refining, detailing, and expanding on the
initially gathered requirements to create a comprehensive and precise
specification.
• Negotiation - The process of resolving conflicts and reaching agreements
among stakeholders regarding the requirements of a system.

• Specification – It is a detailed, precise description of the system's
requirements, capturing the intended functions, behaviors, and constraints
of the system being developed.
• Validation - The process of ensuring that the documented requirements
accurately reflect the needs and expectations of the stakeholders.
• Management - The processes, practices, and tools used to oversee and
control the activities related to gathering, documenting, analyzing,
prioritizing, and maintaining requirements.

Eliciting Requirements
• Also called Requirements gathering.
• It combines elements of problem solving, elaboration, negotiation and
specification.
• Collaborative team oriented approach
• Stakeholders work together to identify the problem,
• propose elements of the solution,
• negotiate different approaches and
• specify a preliminary set of solution requirements.

Collaborative Requirements Gathering:
Different approaches:
• Meeting are conducted and Attended by both Software Engineers and other
Stakeholders.
• Rules for preparation and participation are established.
• An agenda is Suggested
• Formal enough – to cover all important points
• Informal Enough – To encourage the free flow of ideas.

Collaborative Requirements Gathering:
Different approaches:
• A facilitator (customer, developer or outsider) controls the meeting.
• A definition mechanism (worksheets, flipcharts, or wall stickers or an
electronic bulletin board, chat room or virtual forum ) is used.

L13: Functional and Non Functional Requirements
LO: Describe the types of requirements

Types of Requirements
1. Functional Requirements:
• Specify the functions and behaviors the software must perform.
• Examples: User login, data retrieval, transaction processing.
• A functional requirement can express a if/then relationship
• Examples: If an alarm is received from a sensor, the system will report
the alarm and halt until the alarm is acknowledged and cleared.

2. Non Functional Requirements:
• 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.

• A system can meet its functional requirements and fail to meet its
nonfunctional requirements.
• Define the software's characteristics and expected user experience (UX).
• Sub Categories:
• Performance
• Usability
• Scalability
• Security
• Portability

• Ex: The pages of this web portal must load within 0.5 seconds.

FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS
1. A functional requirement defines a system or its component.
A non-functional requirement defines the quality attribute of a
software system.
2. It specifies “What should the software system do?”
It places constraints on “How should the software system fulfill
the functional requirements?”
3. Functional requirement is specified by User.
Non-functional requirement is specified by technical peoples e.g.
Architect, Technical leaders and software developers.
4. It is mandatory. It is not mandatory.
5. It is captured in use case. It is captured as a quality attribute.
6. Defined at a component level. Applied to a system as a whole.
7. Helps you verify the functionality of the software. Helps you to verify the performance of the software.
8. Functional Testing like System, Integration, End to End, API
testing, etc are done.
Non-Functional Testing like Performance, Stress, Usability,
Security testing, etc are done.
9. Usually easy to define. Usually more difficult to define.

L14: Software Requirements Specification (SRS)
LO: Illustrate SRS with examples

SRS-Software Requirement Specification
•Formal document that provides the complete description of the proposed
software.
•i.e., what the software will do without describing how it will do so..
•It is an important document required in software development.

Need for SRS
•Customers and users rely more on and better understand a written formal
document than some technical specification.
•It provides basis for later stages of software development, viz., design, coding,
testing, standard compliances, delivery, and maintenance.
•It acts as the reference document for the validation and verification of the
work products and final software.

Need for SRS:
•It is treated as an agreement on the features incorporated in the final system
of project between customer and the supplier.
•A good quality SRS ensures high quality software product.
•A high quality SRS reduces development effort (schedule, cost, and
resources).

Characteristics of good SRS:
•Correctness: A SRS is said to be correct if it covers all the requirements that
are actually expected from the system.
•Unambiguity: A SRS is said to be unambiguous if all the requirements
stated have only 1 interpretation.
•Completeness: A complete SRS should cover every aspect of the system,
leaving no gaps or ambiguities that could lead to misunderstandings,
incomplete implementations, or missed functionalities.
•Consistency: Requirements in SRS are said to be consistent if there are no
conflicts between any set of requirements.

•Stability: Refers to the extent to which the requirements remain consistent
and unchanged throughout the software development lifecycle.
•Verifiability : A SRS is verifiable if there exists a specific technique to
quantifiably measure the extent to which every requirement is met by the
system.
•Modifiability: A SRS should be made as modifiable as possible and should
be capable of easily accepting changes to the system to some extent.

•Testability : A SRS should be written in such a way that it is easy to
generate test cases and test plans from the document.
•Traceability: One should be able to trace a requirement to design
component and then to code segment in the program.

SRS Format:
1. Introduction
•Purpose of this document
•Scope of this document
•Overview
2. General description
3. Functional Requirements
4. Interface Requirements
Dept. of CSE, SOE, Presidency University
26

SRS Format:
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
27

SRS - Introduction
•Purpose of this document:
- Main aim is to describe the purpose and necessity of the document
•Scope of this document:
- To describe the overall working, main objective of document and also a
development cost and time.
•Overview:
- It’s simply summary or overall review of product.
28

SRS – General Description
•Describe the general functions of product
•Includes
•Product Perspective
•User Classes and Characteristics
•Operating Environment
•Design and Implementation Constraints
•Assumptions and Dependencies
29

SRS – Functional Requirements
• Describing the possible outcome of software system which includes effects
due to operation of program.
• All functional requirements which may include calculations, data
processing, etc. are placed in a ranked order.
30

SRS – Interface Requirements
• Describing how software program communicates with each other or users
either in form of any language, code, or message.
• Ex: Memory, Data Streams etc.
31

SRS – Performance Requirements
• How a software system performs desired functions under specific condition
is explained.
• It also explains required time, required memory, maximum error rate, etc.
32

SRS – Design Constraints
• Constraints which simply means limitation or restriction are specified and
explained for design team.
• Ex: use of a particular algorithm, hardware and software limitations, etc.
33

SRS : Non-Functional Attributes
• Attributes that are required by software system for better performance.
• Example: Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
34

SRS – Preliminary Schedule and Budget
• Initial version and budget of project plan are explained.
• Includes overall time duration required and overall cost required for
development of project
35

SRS : Appendices
•Additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given
and explained.
36

SRS : Example
..........Usersjose2DownloadsReqView-
Example_Software_Requirements_Specification_SRS_Document (1).pdf
(sample SRS document)
37

Case Study: Create an SRS document for Hospital
Management System/Online Bookstore System

L15: Requirement Analysis and Validation
LO: Describe the process of requirements validation

Requirements Analysis and Validation
• Many projects fail:
•Because they start implementing the system without determining whether
they are building what the customer really wants.
• It is important to learn:
•Requirements analysis and specification techniques carefully.

Requirements Analysis and Validation
• Goals:
• Fully understand the user requirements.
• Remove inconsistencies, anomalies, etc. from requirements.
• Document requirements properly in an SRS document.

Requirements Analysis
Consists of two distinct activities:
• Requirements Gathering and Analysis
• Specification
• Who involved in RAS?
• System Analyst
• Collects data pertaining to the product.
• Analyzes collected data:
• To understand what exactly needs to be done.
• Writes the Software Requirements Specification (SRS)
document.

• Final output of this phase:
Software Requirements Specification (SRS) Document.
• The SRS document is reviewed by the customer.
Reviewed SRS document forms the basis of all future development
activities.

• Analyst gathers requirements through:
• Observation of existing systems,
• Studying existing procedures,
• Discussion with the customer and end-users,
• Analysis of what needs to be done, etc.

Requirements Gathering:
• Also known as Requirements Elicitation.
• If the project is to automate some existing procedures
•Analyst can immediately obtain:
• Input and output formats
• Accurate details of the operational procedures

Requirements Gathering :
• In the absence of a working system,
•Lot of imagination and creativity are required.
• Interacting with the customer to gather relevant data:
•Requires a lot of experience.
• Some desirable attributes of a good system analyst:
•Good interaction skills,
•Imagination and creativity,
•Experience.

Requirements Gathering Activities:
1. the existing documentation
2. Interview
3. Task analysis
4. Scenario analysis
5. Form analysis

Requirements Validation
•The process of checking that requirements defined for development and
define the system that the customer really wants.
•To check issues related to requirements, we perform requirements validation.
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of abstraction? That
is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
48

• Is the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
49

• 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 properly reflect the information, function and
behavior of the system to be built.
50

• Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system.
• Have requirements patterns been used to simplify the requirements model.
Have all patterns been properly validated? Are all patterns consistent with
customer requirements?
51

L16: Requirements Modelling- Introduction to Use Cases
LO: Illustrate the functional requirements with the help of use
case diagrams

Requirements Modelling
• Uses a combination of diagrams and text to depict requirements in a way
that is easier to understand.
• Through modelling we can examine the system from various perspectives.
Use case Diagram:
• It is a behavior diagram show the dynamic behavior of the objects in a
system, which can be described as a series of changes to the system
over time.
• Describes a system's functional requirements in terms of use cases.
• It is a model of the system's intended functionality (use cases) and its
environment (actors).
53

• Use Case Diagram
• UML: Unified Modelling Language
• Standard Modelling Language
• consisting of an integrated set of diagrams
• Developed to help system and software developers
• For specifying, visualizing, constructing, and documenting the artifacts of
software systems, as well as for business modeling and other non-software
systems.
• A proper use case diagram depicts a high-level overview of the relationship
between use cases, actors, and systems.
54

• Use case diagram components
• System :
• Actor
Actors are basically users of the SUD who are external entities (people or
other systems) who interact with the SUD to achieve a desired goal. Actors are
represented as stick figures.
• Types of Actors:
• Primary Actor
The Actor(s) using the system to achieve a goal.
• Secondary Actor
Actors that the system needs assistance from to achieve the primary actors
goal.
55

•Use case diagram components
•Use Case
•A use case is a collection of possible sequences of interactions between the
SUD and its Actors, relating to a particular goal.
• The collection of Use Cases should define all system behavior relevant to
the actors to assure them that their goals will be carried out properly.
•A use case is drawn as a horizontal ellipse.
56

Use Cases:
•Hold Functional Requirements in an easy to read, easy to track text format.
•Represents the goal of an interaction between an actor and the system.
•The goal represents a meaningful and measurable objective for the actor.
•Records a set of paths (scenarios) that traverse an actor from a trigger event
(start of the use case) to the goal (success scenarios).
57

•Records a set of scenarios that traverse an actor from a trigger event toward a
goal but fall short of the goal (failure scenarios).
•Are multi-level: one use case can use/extend the functionality of another.
•Use Case Names Begin With a Strong Verb
•Use Cases are named using the domain terminologies
58

Use Cases Do Not…
•Specify user interface design. They specify the intent, not the action detail
•Mock up screens/ Prototype may be included depicting the functionality
•Specify implementation detail (unless it is of particular importance to the
actor to be assured that the goal is properly met)
59

• Use case diagram components
• Use Case Relationships (Associations)
• Associations between actors and use cases are indicated in use case diagrams by
solid lines.
• An association exists whenever an actor is involved with an interaction described
by a use case.
• There are several types of relationships that may appear on a use case diagram:
• An association between an actor and a use case
• An association between two use cases
• A generalization between two actors
• A generalization between two use cases
60

•Use case diagram components - association between two use cases
•Includes Relationship
•"X includes Y" indicates that the task "X" has a subtask "Y"; that is, in the
process of completing task "X", task "Y" will be completed at least once.
•Extends Relationship
• "X extends Y" indicates that "X" is a task of the same type as "Y", but "X"
is a special, more specific case of doing "Y".
•That is, doing X is a lot like doing Y, but X has a few extra processes to it
that go above and beyond the things that must be done in order to complete
Y.
61

•Use case Diagram
62
Actor
Use Case 1
Use Case 2
Association
relationship
Use Case 3
<<include>>
Use Case 4
<<extend>>
Generalization

•Use case Diagram – Airline Reservation System
63
Reservation System
Ticket Clerk
Add Reservation
Cancel Reservation
Check-in Passenger Weigh Luggage
<<include>>
Assign Seat
<<include>>
Assign Window Seat
<<extend>>
Assign Aisle Seat
<<extend>>

EG: Different ways association relationship appears in use case diagrams

•Use case Diagram – Online Shopping System
65

• View Items use case is extended by several optional use cases -
customer may search for items, browse catalog, view items
recommended for him/her, add items to shopping cart or wish list. All
these use cases are extending use cases because they provide some
optional functions allowing customer to find item.
Customer Authentication use
case is included in View
Recommended Items and Add
to Wish List because both
require the customer to be
authenticated. At the same
time, item could be added to
the shopping cart without user
authentication.

• Checkout use case includes several required uses cases. Web
customer should be authenticated. It could be done through user
login page, user authentication cookie ("Remember me") or Single
Sign-On (SSO). Web site authentication service is used in all these
use cases, while SSO also requires participation of external
identity provider.
Checkout use case also
includes Payment use
case which could be done
either by using credit card
and external credit
payment service or with
PayPal

•Use case Diagram – Bank Transaction System
68

•Use case Diagram – ATM Transaction
69

L17: Activity Diagram
LO: Illustrate the dynamic behaviour of the system with the
help of activity diagrams

Activity Diagram
•Important Diagram in UML
•To describe the dynamic aspects of the system.
•It is basically a flowchart to represent the flow from one activity to
another activity.
•The activity can be described as an operation of the system.
•The control flow is drawn from one operation to another.
•This flow can be sequential, branched, or concurrent.
•It deals with all type of flow control by using different elements such as
fork, join, etc
71

Purpose of Activity Diagram
•It captures the dynamic behavior of the system.
•used for visualizing the dynamic nature of a system.
How to Draw:
•Activity diagrams are not exactly flowcharts as they have some additional
capabilities.
•These additional capabilities include branching, parallel flow, swimlane, etc.
72

Basic Components of an Activity Diagram
• Action: A step in the activity wherein the users or software perform a given task.
• The actions are symbolized with round-edged rectangles.
• Decision node: A conditional branch in the flow that is represented by a diamond.
• It includes a single input and two or more outputs.
• Control flows: Another name for the connectors that show the flow between steps in
the diagram.
• Start node: Symbolizes the beginning of the activity. The start node is represented by
a black circle.
• End node: Represents the final step in the activity. The end node is represented by an
outlined black circle.
73

Activity Diagrams: Components
74
Connector

Activity Diagrams:
75

Draw an Activity Diagram for Withdraw Amount
•Insert the ATM card
•Enter PIN
•Check if PIN is valid
•Enter amount
•Check for sufficient balance
•Withdraw amount
•Update Account balance
•Terminate transaction

Activity Diagram for
Withdraw Amount

Draw an Activity Diagram for Processing Orders
•Sales representative enters details of new order
•If special materials required that are not in stock place order
for special materials with supplier
•Add order to production list
•Inform customer

Activity Diagram
for Processing
Orders

Activity Diagrams-Order Management
System

Activity Diagram - Forks and Joins
• Forks and joins distinguish activity diagrams from
traditional flow charts.
• When a transition enters a fork, execution branches off
in two or more directions simultaneously.
• The threads exiting a fork operate concurrently.
• Threads converge at a join.
• Fork - represented by a horizontal bar, with two
concurrent threads.
• Join - represented by a horizontal bar.
Fork
Join

L18: Swimlane Diagram
LO: Illustrate the dynamic behaviour of the system with the
help of swim lane diagrams

Swimlane Diagrams
•UML has no specific Swimlane diagram.
•It is a special case under Activity diagram.
•Swimlane diagram is also graphical representation of the System.
•Swimlane diagrams are also known as the Rummler-Brache diagram or a
cross-functional diagram.
•Swimlanes are sometimes called functional bands.
•It simply describes who is responsible for the activities being performed in
the activity diagram and how they are responsible.
83

Symbols used in Swimlane Diagram :
•“Parallel Segment” is the extra symbol in swimlane diagram along with all
symbols of Activity Diagram.
•Responsibilities are represented as “Parallel Segments” that divide the
diagram vertically , like the lanes in a swimming pool hence the name
“swimlane”.
84

Swimlane Diagrams
85

Swimlane Diagrams
86

Swimlane Diagrams
87

Swimlane diagram – ATM
Management System to
withdraw amount
Showing Responsibilities
of Customer, ATM and
Bank

L19: Case- Characteristics of CASE tools
LO: Describe the characteristics of CASE tools

CASE support in Software Life Cycle
•Computer aided software engineering (CASE) is the implementation of
computer facilitated tools and methods in software development.
•CASE is used to ensure a high-quality and defect-free software.
•CASE ensures a check-pointed and disciplined approach.
•It helps designers, developers, testers, managers and others to see the project
milestones during development.
•CASE can also help as a warehouse for documents related to projects, like
business plans, requirements and design specifications.
90

CASE support in Software Life Cycle
•Major advantage of CASE is: The delivery of the final product, which is
more likely to meet real-world requirements as it ensures that customers
remain part of the process.
•CASE illustrates a wide set of labor-saving tools that are used in software
development.
•It generates a framework for organizing projects and to be helpful in
enhancing productivity
91

CASE Tools
•The essential idea of CASE tools is that in-built programs can help to
analyze developing systems in order to enhance quality and provide better
outcomes.
•CASE tool became part of the software lexicon, and big companies like IBM
were using these kinds of tools to help create software.
92

CASE tools Diagramming Tools
•Helps in diagrammatic and graphical representations of the data and
system processes.
•Represents system elements, control flow and data flow among different
software components and system structure in a pictorial form.
•For example, Flow Chart Maker tool for making state-of-the-art flowcharts
93

CASE tools Computer Display and Report Generators
•Helps in understanding the data requirements and the relationships involved.
94

CASE tools Analysis Tools
• Focuses on inconsistent, incorrect specifications involved in the diagram and
data flow
• Helps in collecting requirements, automatically check for any irregularity,
imprecision in the diagrams, data redundancies or erroneous omissions.
For example,
(i) Accept 360, Accompa, CaseComplete for requirement analysis.
(ii) Visible Analyst for total analysis.
95

CASE tools Documentation Generators
•Helps in generating user and technical documentation as per standards.
•Creates documents for technical users and end users.
•For example,
•Doxygen,
•DrExplain,
•Adobe RoboHelp.
96

CASE tools Code Generators
•Aids in the auto generation of code, including definitions, with the
help of the designs, documents and diagrams
•EG
•Altova UModel
•GeneXus
97

Advantages of the CASE approach
•As special emphasis is placed on redesign as well as testing, the servicing
cost of a product over its expected lifetime is considerably reduced.
•The overall quality of the product is improved as an organized approach
is undertaken during the process of development.
•Chances to meet real-world requirements are more likely and easier with a
computer-aided software engineering approach.
•CASE indirectly provides an organization with a competitive advantage by
helping ensure the development of high-quality products
98

Disadvantages of the CASE approach
•Cost: Using case tool is a very costly.
•Mostly firms engaged in software development on a small scale do not invest
in CASE tools because they think that the benefit of CASE are justifiable
only in the development of large systems.
•Learning Curve: In most cases, programmers productivity may fall in the
initial phase of implementation , because user need time to learn the
technology.
•Many consultants offer training and on-site services that can be important
to accelerate the learning curve and to the development and use of the
CASE tools.
99

Characteristics of CASE Tools
1) Standard Methodology :
A CASE tool should support standard software development
methodologies and modelling techniques. Presently, CASE tools use UML.
2) Flexibility :
A CASE tool must provide flexibility and options to the user for editors
and other tools.
3) Strong Integration :
CASE tools must be integrated with all stages of software development.
This means that if a change is made in a model, it must reflect in the code
documentation and all related design.
100

Characteristics of CASE Tools
4) Integration with Testing Software :
CASE tools should provide interfaces for automatic testing tools. This helps
in regression and other testing software's under changing conditions.
5) Support for Reverse Engineering :
CASE tools should be as that it can create complex models from existing
code.
6) Online Help :
CASE tools offer online tutorials.
101

L20: Architecture of CASE Environment
LO: Describe the CASE architecture

Architecture of Computer Aided Software
Engineering (CASE) Environment
• A database for storing information.
• An object management system for managing variations made to the
information.
• A tools control mechanism for coordinating the use of the CASE tools.
• A user interface for establishing a consistent pathway between the tools and
user actions.
103

104

User Interface Layer
•It is made up of an interface toolkit that is standardized.
• It implements a common protocol which is used for presentation.
•The components of the interface are
•a library which contains display objects and
•software that facilitates management of interface between human and
computer.
105

User Interface Layer
• With the help of these two components the individual CASE tools and
components can communicate with each other consistently.
• The tool access mechanism are described in the presentation tool
• use of mouse and keyboard,
• menu names,
• object names,
• icons and
• screen layout.
106

Tools Layer
• The behavior of the tools within the environment is controlled by
the Tools Management Services (TMS).
• TMS carries out multitask communication and synchronization in
case multitasking is performed by executing multiple tools at a time.
• This is done by gathering metrics on the usage of the tools,
coordinating the information flow between the repository and
management system to the tools.
107

Object Management Layer
•A mechanism that enables in tool incorporation is the essence of
the software that is present in this layer of the framework
architecture.
•Each case tool has been plugged into the object management
layer.
•The OML and the CASE repository works in unison to
provide integration services.
108

Object Management Layer
•The tools are coupled with the repository by this set of standard modules.
•Apart from all these functions, the OML also support change control, status
accounting and audits.
•Configuration management services such as the task of classifying those
configuration objects that perform version control are also executed by it.
109

Shared Repository Layer
•It is made up of those access control functions with the help of
which the object management layer interacts with the CASE
database that is present in this layer.
•Shared repository layers and object management helps in
attaining data integration.
110

CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdf

More Related Content

Similar to CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdf (20)

Recently uploaded (20)

CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE - 2 new.pdf