Introduction to Software engineering Concepts which includes Software Process Model, SRS documents, Requirement Engineering Process, Architectural Modeling, software Products, Risk Management Process, SDLC Model, Professional & Ethical Responsibilities, System & its Environment, System Procurement (COTS & Contractor Method), System Engineering Process, System Reliability Engineering, Human factors, Functional & Non-Functional Requirements

1. SOFTWARE ENGINEERING
By
YAMUNA P
Assistant Professor
Dept of Computer Applications
Acharya Institute of Graduate studies

2. Why software Engineering is Required?
There is a growing need for talented software developers across every industry.
 As technology advances, the ability to build quality software while considering design,
development, security, and maintenance for all kinds of companies, from finance and banking to
healthcare and national security.
 Software Engineering applies the knowledge and theoretical understanding gained through
computer science to building high-quality software products.
 As a maturing discipline, software is becoming more and more important in our everyday lives

3. • Software in its most general sense, is a set of instructions or
programs instructing a computer to do specific tasks. Software is a
generic term used to describe computer programs. Scripts,
applications, programs and a set of instructions are all terms often
used to describe software
• Software engineering is an engineering branch associated with
development of software product using well-defined scientific
principles, methods and procedures. The outcome of software
engineering should an efficient and reliable software product.
• A software engineer/developer: takes the software needs of end
users into account and consequently develops or designs new
applications. Furthermore, software engineering may involve the
process of analyzing existing software and modifying it to meet
current application needs.

4.  Types of Software Product:
 software products can be of the following two types

5.  1) Generic Software Products: Software products which were developed with the target to sell them to
customer eligible to buy with no customization for any specific customer are called generic software
products.
 These software products are stand-alone, can be up-gradable to new versions or updates while the
updates are prepared by the software company or vendor who developed the product
 2) Customized Software Products: Software products which are developed based on the requirements
of a specific customer. Customized software products means a piece of software customized in case of
features, workflow, design, language etc..
 Customized software can be developed from scratch such as gathering all the requirements from the
customer, analyzing and developing using various software development process models

6.  Software Process:
 Software process can be defined as “set of activities and associated results that help to produce
software products.
 Software process comprises of four fundamental activities such as:
 1. Software specification. In this activity the functionality of the software and constraints on its
operation must be defined.
 2. Software design and implementation. Software design is a creative activity in which you
identify software components and their relationships, based on a customer's requirements. –
Implementation is the process of realizing the design as a program.
 3. Software validation. The software must be validated to ensure that it has all the functionalities
what the customer needs.
 4. Software evolution. The software must evolve to meet changing customer needs

7.  SDLC: Software development Life cycle
 It is a process followed for a software project, within a software organization. It consists of a detailed
plan describing how to develop, maintain, replace and alter or enhance specific software. The life
cycle defines a methodology for improving the quality of software and the overall development
process.

8.  Software Process Models:
 These models can be used to explain different approaches to software development. They can be
considered as process frameworks that may be extended and adapted to create more specific
software engineering processes.
 1. The waterfall model.
 2. Evolutionary development
 3. Spiral development.

9.  WATERFALL MODEL:

10. 1. WATERFALL MODEL:
 The waterfall model was the first software process model to be introduced. It is also referred to as a
linear-sequential life cycle model. The principal stages of the model represent the fundamental
development activities:
 1. Requirements analysis and definition. Software requirements specification establishes the basis for
agreement between customers and contractors or suppliers on what the software product is to do.
Software requirements specification permits a rigorous assessment of requirements before design can
begin. It should also provide basis for estimating product costs, risks, and schedules.
 2. System and software design. Design activity results in the overall software architecture. Software design
involves identifying and describing the fundamental software system components and their relationships.
The systems design process partitions the requirements to either hardware or software components.
 3. Coding and Implementation. During this phase, the software design is realized as a set of software
components. Each Components will be coded by ensuring each component meets its specification.
 4. Integration and system testing. The program units or components are integrated and tested as a
complete system to ensure that the software requirements have been met. After successful testing, the
software system is delivered to the customer.
 5. Operation and maintenance. The system is delivered and deployed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle,
improving the implementation of system units and providing new functionalities as new requirements
emerge.

11. 2) Evolutionary development
 Evolutionary development is based on the idea of developing an initial implementation, exposing this
to user comment and refining it through many versions until an adequate system has been developed
Specification, development and validation activities are interleaved with rapid feedback across
activities.

12.  There are two fundamental types of evolutionary development:
 1. Exploratory development. The objective of the process is to work with the customer in order to
explore their requirements and deliver a final system. The development starts with the parts of the
system that are well understood. The system evolves by adding new features proposed by the
customer.
 2. Throwaway prototyping. In this case the objective of the evolutionary development process is to
understand the customer’s unclear requirements, namely to validate the requirements definition for
the system. The prototype concentrates on experimenting with the customer requirements that are
poorly understood.
 An evolutionary approach to software development is often more effective than the waterfalls
approach in producing systems that meet the immediate needs of customers.

13.  3. Spiral development
 The spiral model of the software process represents the software process of activities with some
backtracking from one activity to another; the process is represented as a spiral. Each loop in
the spiral represents a phase of the software process.
 Thus, the innermost loop might be concerned with system feasibility, the next loop with
requirements definition, the next loop with system design and so on

15. When to Use Spiral model?
Spiral model is used in the following scenarios:
When the project is large.
Where the software needs continuous risk
evaluation.
Requirements are a bit complicated and require
continuous clarification.
Software requires significant changes.
Where enough time frame is their to get end user
feedback.
Where releases are required to be frequent.

16.  Each loop in the spiral is split into four sectors:
 1. Objective setting. Specific objectives for that phase of the project are defined. Constraints on the
process and the product are identified and a detailed management plan is drawn up. Project risks are
identified. Alternative strategies, depending on these risks, may be planned.
 2. Risk assessment and reduction. For each of the identified project risks, a detailed analysis is
carried out. Steps are taken to reduce the risk.
 3. Development and validation. After risk evaluation, a development model for the system is chosen.
 4. Planning. The project is reviewed and a decision made whether to continue with a further loop of
the spiral. If it is decided to continue, plans are drawn up for the next phase of the project

17.  Overview of Risk Management:
 Risk Management is seen as one of the main jobs of the project management. It involves anticipating risks
that might affect the Project schedule to the quality of the software being developed and taking actions
to avoid these risks.
 Common definition of risk is an uncertain event that if it occurs, can have a positive or negative effect
on a project’s goals.
 Risk is something you prefer not to happen, risk may threaten the project, the software that is being
developed or the organization involved in the development.
 The potential for a risk to have a positive or negative effect is an important concept because it is natural
to fall into the trap of thinking that risks have inherently negative effects.
 If you are also open to those risks that create positive opportunities, you can make your project smarter,
streamlined and more profitable
 “Accept the inevitable and turn it to your advantage.”

18. Types of Risks:
 There are 3 related categories of risks such as:
 1) Project risk
 2) Product Risk
 3) Business Risk

19. 1) Project Risk:
 Some of the project risk which affects the project schedule or resource is:
 • Programmer’s Risk: If an experienced programmer leaves a project, this can a project risk because
delivery of the system may be delayed
 • Hardware Unavailability: Hardware is very essential for the project hence the product cannot be
delivered on schedule.
 • Staff Turn Over: If the experienced staff leave the project before it is finished then date of
delivery of the software project will be delayed.
 • Management Change: Management change definitely affect project as there will be a change of
organizational management with different priorities.

20. 2) Product Risk:
 It affects the quality or performance of the software being developed, following are the product risk.
 A Product Risk may include product replacement or in experienced programmer may have produced
errors.
 Failure of a purchased component to perform as expected, results in product failure.
3) Business Risks:
 • These are that affect the organization developing or procuring the software
 • A competitor introducing a new product is a business risk
 • Technology change leads to business risk

21.  Risk Management Process:
The following diagram illustrates the
six steps of the risk management
process: identify, analyze and
prioritize, plan and schedule, track
and report, control and learn

22. Risk Management Process Steps:
 The following is a brief introduction to the six steps of the risk management
process.
 Identify - Risk identification allows individuals to identify risks so that the
operations staff becomes aware of potential problems. Not only should risk
identification be undertaken as early as possible, but it also should be
repeated frequently.
 Analyze and prioritize - Risk analysis transforms the estimates or data
about specific risks that developed during risk identification into a
consistent form that can be used to make decisions around prioritization.
Risk prioritization enables operations to commit resources to manage the
most important risks.

23.  Plan and schedule - Risk planning takes the information obtained from risk
analysis and uses it to formulate strategies, plans, change requests, and actions.
Risk scheduling ensures that these plans are approved and then incorporated into
the standard day-to-day processes and infrastructure.
 Track and report - Risk tracking monitors the status of specific risks and the
progress in their respective action plans. Risk tracking also includes monitoring the
probability, impact, exposure, and other measures of risk for changes that could
alter priority or risk plans and ultimately the availability of the service. Risk
reporting ensures that the operations staff, service manager, and other
stakeholders are aware of the status of top risks and the plans to manage them.
 Control - Risk control is the process of executing risk action plans and their
associated status reporting. Risk control also includes initiating change control
requests when changes in risk status or risk plans could affect the availability of
the service or service level agreement (SLA).
 Learn - Risk learning formalizes the lessons learned and uses tools to capture,
categorize, and index that knowledge in a reusable form that can be shared with
others.

24.  PROCESS VISIBILITY:

25.  Professional and Ethical Responsibility:
 Software engineering activities has to be carried out within legal and ethical frame-work. Software
engineers must have ethical, moral and legal responsibilities to be qualified as professionals. They must
be honesty when they are the part of organization
 Professional responsibility includes:
 • Confidentiality
 • Competence
 • Intellectual property rights
 • Computer misuse

26. 1. Confidentiality:
Software engineers must maintain confidentiality of employers or client. Singing confidentiality
agreement is formal, irrespective of it they must honor their commitment.
2. Competence (the ability to do something successfully or efficiently)
Software engineers must always accept what they can deliver and should not boost to stand in the
world of competence.
3. Intellectual property rights:
Knowledge of patent rights, local governing laws and copyright helps the Software engineers to
protect the clients and to safeguard their interest.
4. Computer misuse:
Software engineers should not change the configuration of other systems, introduce malicious virus,
alter database. They must have ethical and moral values so that they retain professional values.

27.  System and Its Environment:

28.  System Procurement:
 The term procurement refers to selecting the required system with the specifications and
architectural design. The process of system procurement is concerned with making decisions about
best suppliers of that system. The procurement process is closely related to the system engineering
process
 The system may be procured as a whole or may be bought as separate parts which are then
integrated or may be specially designed and developed.
 System Procurement Methods are classified in to two types:
 COTS Method
 Contractor Method

29.  COTS method:
 Commercial off-the-shelf (COTS) :The 'shelf' normally means the shelf of products in any store,
accessible to anyone who walks into the store.
 commercial off-the-shelf, it describes software or hardware products that are ready-made and
available for sale to the general public. For example, Microsoft Office is a COTS product that is a
packaged software solution for businesses.
 COTS products are designed to be implemented easily into existing systems without the need for
customization.
 Advantages of Using COTS
 Accessible and Easy to Use
 Customer Care Availability
 Quality at Relatively Low-Cost
 Frequent Improvements and Software Updates

30.  Contractor method:
 If the system has to be built specially or need custom software then specification of requirements
must be given to the contractor in the form of a document.
 it is therefore a legal as well as a technical document. Hire a contractor or to design and built a
system, specifying a high level specification of what that system should do.

31. System engineering process is an
interdisciplinary activity. It is a team work.
It includes teams drawn from different
backgrounds. System Engineering teams are
essential as it demands wide knowledge
required to develop complicated software
system

32.  Define Requirements:
 This is the first step in which system requirements definitions activity is intended to discover the
requirements for the system as a whole. The process involves consultations with system customers
and end user to establish a set of overall objectives which the system should meet.
 Requirement Definition is classified in to 3types:
 1. Abstract Functional Properties: Basic functions that the system must provide are defines in
abstract level.
 2. System Properties: It includes availability, performance and safety
 3. Character Properties: What characters the system should exhibit and what it should not exhibit
is highlighted.

33.  System Design:
 System design is the process of defining the elements of a system such as the architecture, modules and
components, the different interfaces of those components and the data that goes through that system. It
is meant to satisfy specific needs and requirements of a business or organization through the engineering
Process

34.  Sub System Development:
 Various sub system is identified during system design are implemented. A software process involving
requirements design and implementation may be started for each sub-system.
 System Integration:
 System integration (SI) is an IT or engineering process or phase concerned with joining different
subsystems or components as one large system. It ensures that each integrated subsystem functions as
required.
 SI is also used to add value to a system through new functionalities provided by connecting functions of
different systems

35.  System Installation:
 During system installation, the system is put into the environment in which it is intended to operate.
While this may appear to be simple process, many problems arise which mean installation of a
complex system can take months.
 Some of the Problem which occurs during installation are:
 • Operating system version mismatch problem
 • Co-existence Problem
 • Physical installation problem
 • System operation

36.  System Evolution:
 The software system should be maintained and should update to keep their functionalities along with the
environment changes such as technology changes, based on competitors launching new products and so
on.
 System Decommissioning:
 Taking a system out of service after the end of its useful operational lifetime is system decommissioning.
Recover any useful information from old system for further usage. Sometimes this is straight forward but
some systems may contain materials which are potentially damaging to the environment.

37. SYSTEM ARCHITECTURE MODELING
System Architectural Model is always represented as block diagram by
showing the major sub systems with the interconnections between the
sub systems.
As a part of system requirements and design activity the system has to
be modeled as a set of components and relationships b/w theses
components should be established

38. SENSOR
COMPONENT
ACTUATOR
COMPONENT
COMPUTATION
COMPONENT
INTERFACE
COMPONENT
CO-ORDINATION
COMPONENT
COMMUNICATION
COMPONENT
SHIP
CONTROL
SYSTEM

39. System Architectural Model is always represented as block diagram by showing the major sub
systems with the interconnections between the sub systems.
As a part of system requirements and design activity the system has to be modeled as a set of
components and relationships b/w theses components should be established
Now Ship controller system is decomposed into several sub systems, Each of the sub system is
further decomposed into functional components.
Each of the Functional components has One single function
 Sensor Component
 Actuator Component
 Computer Component
 Communication component
 Co-ordination component
 Interface Component
 Weather Mapping Component

40. HUMAN FACTORS
System are created and operated by humans for the betterment of
organization, Human factors have profound influence on the system
and their environment.
Following are the 3 important human factors that affects the system
and environment.
• Process Change
• Job Change.
• Organizational Change

41.  System Reliability Engineering:
 Reliability is the probability that a system performs correctly during a specific time duration. During
this correct operation, no repair is required or performed, and the system adequately follows the
defined performance specifications.
 In a computer based system 3 dimensions are considered for overall system reliability

43.  Requirement Engineering Process:
 Requirement Engineering is the process of defining, documenting and maintaining the
requirements. It is a process of gathering and defining service provided by the system.
Requirements Engineering Process consists of the following main activities:
 It focuses on evaluating if the system is useful to the business (feasibility study), discovering
requirements (elicitation and analysis), converting these requirements into some standard
format (specification), and checking that the requirements define the system that the customer
wants (validation).
 In practice, requirements engineering isn’t sequential process, it’s an iterative process in which
activities are interleaved.
 4 major activities are identified in requirement engineering:
 1. Feasibility study
 2. Requirements elicitation and analysis
 3. Requirement specification-System, user, Natural Language
 4. Requirement validation

44.  4 major activities are identified in requirement engineering:
 1. Feasibility study-
 2. Requirements elicitation and analysis
 3. Requirement specification-System, user, Natural Language
 4. Requirement validation
 Validity checks
 Consistency checks
 Completeness checks
 Realism checks
 Verifiability checks

45.  1) Feasibility study is an analysis that takes all of a project's relevant factors into account—including
economic, technical, legal, and scheduling considerations—to ascertain the likelihood of completing
the project successfully. Project managers use feasibility studies about the pros and cons of
undertaking a project before they invest a lot of time and money into it
 2) Requirements Elicitation: It is related to the various ways used to gain knowledge about the
project domain and requirements. The various sources of domain knowledge include customers,
business manuals, the existing software of same type, standards and other stakeholders of the
project.
 The techniques used for requirements elicitation include interviews, brainstorming, task analysis to
understand the requirement in depth

46.  3) Requirements specification:
This activity is used to produce formal software requirement models. All the requirements
including the functional as well as the non-functional requirements and the constraints
are specified by these models in totality. During specification, more knowledge about the
problem may be required which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data dictionaries, etc.
 4)Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has
been built is traceable to customer requirements.
 Validity checks
 Consistency checks
 Completeness checks
 Realism checks
 Verifiability checks

47.  FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS
 The software requirements are classified into functional requirements and non-functional
requirements.
 Functional Requirements: It covers the main functions that should be provided by the
system. When expressed as user requirement, they are usually descried in an abstract way.
However, more specific functional system requirement describe the system functions, it’s
inputs, processing; how it’s going to react to a particular input, and what’s the expected
output.
 Non-Functional Requirements: These are the constrains on the functions provided by the
system. The constrains, like
 how many process the system can handle (performance),
 what are the (security) issues the system needs to take care of database …
 The rate of failure (reliability),
 what are the languages and tools will be used (development),
 what are the rules you need to follow to ensure the system operates within the law of the
organization (legislative).

48.  Non-functional requirements are often critical than individual functional requirements.
Users can usually find ways to work around a system function that doesn’t really meet
their needs. However, failing to meet a non-functional requirement can mean that the
whole system is unusable.

49.  SRS Document[Software Requirement Specification Document]
 The software requirements document (also called software requirements specification or SRS) is
an official document of what should be implemented. It’s also used as a contract between the
system buyer/client and the software developers
 In order to understand one’s project, it is very important that they come up with a SRS listing out
their requirements, how are they going to meet it and how will they complete the project. It helps
the team to save upon their time as they are able to discuss how they are going to do the project.
Doing this also enables the team to find out about the limitations and risks early on

50.  SRS: STEP 1: Introduction: This part provide an overview of the SRS document, and it
should contain all information needed by a software engineer to design and implement the
software product described by the requirements listed in this document.
 1. Purpose: What is the purpose of this SRS and the (intended) audience for which it is
written.
 2. Scope: it should describe all relevant benefits, objectives, and goals as precisely as
possible.
 3. Definitions & Abbreviations: Provide the definitions of all terms, and abbreviations
required to properly interpret the SRS. This information may be provided by reference to
one or more appendixes in the SRS or by reference to other documents.
 4. References: This subsection should provide a complete list of all documents referenced
elsewhere in the SRS, or in a separate, specified document. Identify each document by
title, report number, and publishing organization. And specify the sources from which the
references can be obtained. This information may be provided by reference to an appendix
or to another document.
 5. Overview: Describe what the rest of the SRS contains and explain how it is organized.

51.  SRS STEP 2: Overall Description: Describe the general factors that affect the product and
its requirements. It should also be made clear that this section does not state specific
requirements; it only makes those requirements easier to understand.
 1. Product Perspective: Puts the product into perspective with other related products or
projects.
 2. Product Functions: Provide a summary of the functions that the software will perform.
 3. User Characteristics: Describe general characteristics of the eventual users of the
product that will affect the specific requirements.
 4. General Constraints: Provide a general description of any other items that will limit the
developer’s options for designing the system.
 5. Assumptions and Dependency: List each of the factors that affect the requirements
stated in the SRS. These factors are not design constraints on the software but are, rather,
any changes to them that can affect the requirements in the SRS. For example, an
assumption might be that a specific operating system will be available on the hardware
designated for the software product. If, in fact, the operating system is not available, the
SRS would then have to change accordingly.

52.  SRS STEP 3: Specific Requirements: Give the detailed requirements (D-requirements) that are used
to guide the project’s software design, implementation, and testing. Each requirement in this section
should be correct, verifiable, prioritized, complete, consistent, and uniquely identifiable.
 1. External Interface Requirements: Include user, hardware, software, and communication
interfaces.
 2. Functional Requirements: Describes specific features of the software project and how it as to
work.
 3.Classes and Objects: Describe all classes by expressing its functions and attributes in the system.
 4. Non-Functional Requirements: Requirements may exist for performance, reliability, availability,
security, maintainability and portability. For example (95% of transaction shall be processed in less
than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).
 5. Design Constraints: Specify design constrains imposed by other standards, company policies,
hardware limitation, etc. that will impact this software project.
 6. Other Requirements: Catchall section for any additional requirements.

53. SRS STEP 4: Analysis Models: List all analysis models used in developing specific requirements previously
given in this SRS. Each model should include an introduction and a narrative description. Furthermore,
each model should be traceable the SRS’s requirements.
 1. Sequence Diagrams: It is a kind of interaction diagram that shows how processes operate with one
another and in what order.
 2.Data Flow Diagrams: It is a graphical representation of the "flow" of data through an information
system, modeling its process aspects. Often they are the basic step used to create an overview of the
system which can later be elaborated.

54.  SRS STEP 5: Change Management Process: Identify and describe the process that will be used to
update the SRS, as needed, when project scope or requirements change. Who can submit changes
and by what means, and how will these changes be approved.
 SRS STEP 6 Report: Provide additional (and hopefully helpful) information. If present, the SRS
should explicitly state whether the information contained within an appendix is to be considered as
a part of the SRS’s overall set of requirements. Example Appendices could include (initial)
conceptual documents for the software project, marketing materials, minutes of meetings with the
customer(s), etc

55.  7 SOCIAL ORGIZATIONAL FACTORS:
 Success of the software will always follow the social and organizational factors
 Software engineers make use of ethnographic techniques(Ethnography can help investigate very
complicated or critical design challenges. A good researcher is essential when observing and/or
interacting with target audiences in their real-life environment)
 Group of people in a team will study to understand the requirements, their importance, benefits
,cause, objective, goals and etc..,
 Software Engineers can understand the requirement in better way by communicating the
requirements to the end users.
 Some of the important Ethnographic Techniques are Listed below:

56. Direct
Meeting
Questionnair
e
Group
Discussion
with
employee
Interviewin
g
Observatio
n
Discuss
with Top
Level
Ethnographi
c Technique

57.  SYSTEM MODEL:
 It is a graphical representation that describes the problem to be solved
and the system that is to be developed, because of the graphical
representations used models are often more understandable than
detailed natural language description of the requirements.
 Types of System Models:
1.Context Model.
 Process Model
2.Behavioral Models
 Data flow model
 State Machine Model
3.Data model
4.Object Model
 Inheritance Model
 Object Behavior Model

58.  Context Models:
 It is an Architectural Model.
 It helps to identify the boundary of the system, It takes information from different stakeholder to
distinguish system and its environment.
 Here in context model Boundary of the system should be defined properly, if in case boundary on the
system is not clear it may pose technical and managerial problems.
 A context diagram of ATM machine represent the simple block diagrams where each of the sub system are
represented by a rectangle and the arrows indicates that there are associated b/w sub systems.

59. Local Branch
Accounting System
Account Database
User database
Cash withdrawal
counter
Security system
Hardware/Softwar
e & Maintenance
staff
BANK
ATM
SYSTE
M

60.  Process Model
 Process Model is a type of context model. It Specifies all the details of the system
 OS exhibits various process states,
 Different Process states are:
 Ready state
 Wait state
 Running State
 Interrupt state
 Finish state
 Terminated State

61. Ready state
Wait State
Interrupt
state
Terminate
state
Finish State
Running
State

62.  2. Behavioral Model :
 This type of model is used to describe the overall behavior of the system, which includes
2types.
1.Data Flow Model
2.State Machine Model
Data Flow Model:
 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.
 Data flowcharts can range from simple, even hand-drawn process overviews, to in-depth,
multi-level DFDs that dig progressively deeper into how the data is handled.
 They can be used to analyze an existing system or model a new one. Like all the best
diagrams and charts, a DFD can often visually “say” things that would be hard to explain in
words, and they work for both technical and nontechnical audiences, from developer to
CEO

63. Input or output
file
1. External entity: an outside system that sends or receives data, communicating with the
system being diagrammed.
2. Process: any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business rules.
3. Data store: files that hold information for later use, such as a database table or a
membership form.
4. Data flow: the route that data takes between the external entities, processes and data
stores.

64. DFD Level 0:
DFD Level 1:
Customer Online ShoppingLogin

65. ONLINE SHOPPING
 DFD Level 2:

66.  State Machine Model/Event Model:
This mode describes how the system reacts to events. Real time systems are often event driven with
minimal data process. State Machine model represent their behavior. Reacts to events. Most of the
business systems are driven data.
They are controlled by the data inputs to the system, which have external event processing
Event E1: Switch on the system
Event E2: Washing tub waits for input(cloths water surf)
Event E3: Set the timer to 15mins (depends on user Requirements)
Response (R1) :After 15minw timer is linked to whistle controller
Response (R2): Timer will set 30 seconds timer for whistle to blow
Response (R3) : If the user does not respond by switching off the system, controller automatically
switches off the systems.

67.  SMD:
Washing Machine
Timer is linked
to whistle
controller
Timer set for
30 sec whistle
blows first
time
Whistle blow
second time Whistle
controller
automatically
stops the
machine
Switch on
the system
Input the
system
Set the
timer
Events
Respons
e

68.  Data Model:
Data Models are the logical structures of the data. Data Models show system entities their attributes
(properties) and relationships between them. This is called ERA(Entity Relationship Attributes).Data model
emphasizes on what data is needed and how it should be organized instead of what operations need to be
performed on the data. Data Model is like architect's building plan which helps to build a conceptual
model and set the relationship between data items
Student-Teacher Relationship can be taken as an example to illustrate data Model.
Name
Id
Course
Address
Fees-paid
Student
Name
Id
Course
Address
Department
Designation
Teacher
Name
Id
Course
Address
Fees-paid
Name
Id
Course
Address
Department
Designation
Subject
Student
Teacher

69.  4.Object Model:
 Object Model are used for interactive systems development. It helps to design using objects.
Object models are useful for showing how entities in the system may be aggregated(form or
group into a class or cluster) and classified.
 They Reflect real world Entity
 They reflect simple interfaces comprising of object oriented design and programming.
 It Is widely used in software development.
 Some of the important terminologies are:
 1 Object: Represents system data item, it is an Executable entity
 2 Attributes: Properties of data items Like color of the car type of engine, fuel
 3. Class: Group of objects with similar attributes Like domestic car, sports car
 4. Entity: Name of the objects Like car, books, college, hospital.
 5 Function: It perform operation on object through attributes

70.  Object Model
Student id()
Issued date()
Catalogue()
Return date()
LIBRARY BOOK/Magazine
Date of issue
Author
Edition
Publication
Date
Isbn
Subject
Book
Year
Issue
Subject
Printed date
Magazine

71.  Inheritance Model:
 Inheritance object Model identifies the classes of object and organize into an inheritance hierarchy. Most
general object classes are presented at the top of the hierarchy, here objects inherits their attributes and
services.
Name
Id
Sem
Course
Library Book Users
Authorized ()
De-Authorized()
ID Any dues
Max.borrow
Reader Borrower
Name
ID
Name
ID
Name
ID
Student Staff Research scholar

72.  Object Behavior Model
Behavior of the objects can be shown by illustrating the operations of the objects.
Issuing Driving license can be taken as an example to illustrate object behavior model.
1. Candidate approaches driving class
2. Driving class enrolls the student for class
3. Issues the candidate id card with route details & commencement of class details
4. Students will be taught basic rules and regulations of driving period of 1 or 2 months.
5. Candidate approaches RTO Road transport Officer
6. RTO Conducts Theory Examination
7. RTO announce Results
8. Students clears theory will be allowed to take up practical Examination (Students does not
clear will have to re-write theory test)
9. Students clear practical exam
10. RTO Inspector issue Driving license