Soft Eng 1 - Chapter No 4-2

Chapter No 1
DATA MINING
DATA MINING
By: Saifullah shakir
For: Nisar Ahmad saqib
Department of computer science

DATA MINING
 1 UNDERSTANDING DATA MINING
 2 NEED OF DATA MINING
 3 ABOUT DATA MINING

DATA MINING
 WHAT IS DATA MINING?
 IT IS THE PROCESS OF MINING KNOWLEDGE FROM LARGER
AMOUNT OF DATA
BIG DATA -----DATA MINING TECHNIQUES---------- USEFUL

DATAA
DATA MINING
 WHY WE DO THIS?
1 : COMPANIES AND ORGANIZATION GET HUGE AMOUNT OF DATA

FROM DIFFERENT SOURCES AND FLATFORMS.
2: AS SIZE OF DATABASE INCREASING AND IT IS VERY DIFFICULT TO

MANUALLY SEARCH FOR USEFUL INFORMATION IN IT
3: THE USE DATA MINING TECHNIQUES WHICH INCLUDES AI AND

MATHEMATICAL COMPLEX ALGORITHMS FOR GETTING SPECIFIC
AND USEFUL DATA.
DATA MINING
 WHY WE DO THIS?
4: THIS SPECIFIC DATA HELPS THEM FOR TAKING DATA-

DRIVEN DECISIONS.
01: WE ALSO GET TRENDS , PATTERNS, INSIGHT OF

COLLECTED DATA
02: DATA MINING IS ALSO CALLED AS ‘KNOWLEDGE

DISCOVERY IN DATABASE (KDD)’
DATA MINING
 DATA MINING TECHNIQUES INCLUDES.
 STATISTICS
A) CLUSTER TECHNIQUES ,
B) REGRESSIONS
C) STANDARD DEVIATION
DATA MINING
 AI
A) DIFFERENT AI ALGO’S
DATA MINING
ML
A) KNN ALGO’S
B) APRIORO ALGO
C) K MEAN ALGO
D) NATIVE BAYES ALGO

DATA MINING
 DATA MINING CONTENTS:
A) DATA MINING
B) APPLICATIONS
C) DATA PRE PROCESSING
D) MINING METHODS
E) CLASSIFICATIONS
F) BELIEF NETWORK
G) CLUSTERING
DATA MINING
 DATA MINING CONTENTS:
A) DEF
B) PROCESS OF EXTRACTION OF USEFUL INFORMATION

FROM BULK OF DATA
KDD ( KNOWLEDGE DATA DISCOVERY )
DATA CLEANING - INTEGRATE-- EVALUATE --- REPRESENT

REQUIREMENTS ANALYSIS
 Requirements analysis results in the specification of software’s
operational characteristics, indicates software’s interface with other
system elements, and establishes constraints that software must meet.
 Requirements analysis allows you (regardless of whether you’re called
a software engineer, an analyst, or a modeler) to elaborate on basic
requirements established during the inception, elicitation, and
negotiation tasks that are part of requirements engineering.

REQUIREMENTS ANALYSIS : Continue
 The requirements modeling action results in one or more of the
following types of models:

1. Scenario-based models of requirements from the point of view of
various system “actors”
2. Data models that depict the information domain for the problem
3. Class-oriented models that represent object-oriented classes
(attributes and operations) and the manner in which classes
collaborate to achieve system requirements
4. Flow-oriented models that represent the functional elements of the
system and how they transform data as it moves through the system
5. Behavioral models that depict how the software behaves as a
consequence of external “events”
REQUIREMENTS ANALYSIS :
Continue
 Throughout requirements modeling, your primary focus is on
what, not how.
 What user interaction occurs in a particular circumstance,
what objects does the system manipulate, what functions
must the system perform, what behaviors does the system
exhibit, what interfaces are defined.

Continue
 The requirements model must achieve three primary objectives:
 (1) to describe what the customer requires.
 (2) to establish a basis for the creation of a software de-sign.
 (3) to define a set of requirements that can be validated once the

software is built.
 The analysis model bridges the gap between a system-level
description that describes overall system or business functionality
and a software design that describes the software’s application
architecture, user interface, and component-level structure.
Continue
Requirements Modeling Approaches
Requirements Modeling Approaches :
Continue
 Each element of the requirements model presents the problem from a
different point of view.
1. Scenario-based elements depict how the user interacts with the system
and the specific sequence of activities that occur as the software is

used.
2. Class-based elements model the objects that the system will

manipulate, the operations that will be applied to the objects to effect
the manipulation, relationships (some hierarchical) between the
objects.
Requirements Modeling Approaches :
Continue
3. Behavioral elements depict how external events change the
state of the system or the classes that reside within it.
4. flow-oriented elements represent the system as an
information transform, depicting how data objects are
transformed as they flow through various system functions.

SCENARIO - BASED MODELING
 Although the success of a computer-based system or product is
measured in many ways, user satisfaction resides at the top of the
list.
 If you understand how end users (and other actors) want to
interact with a system, your software team will be better able to
properly characterize requirements and build meaningful analysis
and design.
SCENARIO - BASED MODELING :
Continue
 “[Use-cases] are simply an aid to defining what exists outside
the system (actors) and what should be performed by the

system (use-cases).” Ivar Jacobson
 (1) What should we write about?
 (2) How much should we write about it?
 (3) How detailed should we make our description?
 (4) How should we organize the description?

Continue
 What should we write about?
 Inception and elicitation—provide you with the information you’ll need
to begin writing use cases.
 Requirements gathering meetings, and other requirements engineering
mechanisms are used to
 identify stakeholders
 define the scope of the problem
 specify overall operational goals
 establish priorities
 outline all known functional requirements, and
 describe the things (objects) that will be manipulated by the system.
 To begin developing a set of use cases, list the functions or activities
performed by a specific actor.
Continue
 Example: The “SafeHome home surveillance” function
(subsystem) identifies the following functions (an abbreviated
list) that are performed by the homeowner actor:
1. Select camera to view.
2. Request thumbnails from all cameras.
3. Display camera views in a PC window.
4. Control pan and zoom for a specific camera.
5. Selectively record camera output.
6. Replay camera output.
7. Access camera surveillance via the Internet.
Continue
 A variation of a narrative use case presents the interaction as an ordered
sequence of user actions.

 Actor: homeowner
1. The homeowner logs onto the SafeHome Products website.

2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame per second.
UML MODELS THAT SUPPLEMENT THE USE
CASE
 There are many requirements modeling situations in which a
text-based model— even one as simple as a use case—may
not convey information in a clear and concise manner.
 In such cases, you can choose from a broad array of UML
graphical models.
UML MODELS THAT SUPPLEMENT THE USE
CASE
Swimlane Diagrams
 The UML swimlane diagram is a useful variation of the activity
diagram and allows you to represent the flow of activities described
by the use case and at the same time indicate which actor (if there
are multiple actors involved in a specific use case) or analysis class
has responsibility for the action described by an activity rectangle.
 Responsibilities are represented as parallel segments that divide the
diagram vertically, like the lanes in a swimming pool.

Swimlane Diagrams
What is a Data Object?
 a representation of almost any composite information that must
be understood by software.
 composite information—something that has a number of different
properties or attributes
 can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display), an
occurrence (e.g., a telephone call) or event (e.g., an alarm), a
role (e.g., salesperson), an organizational unit (e.g., accounting
department), a place (e.g., a warehouse), or a structure (e.g., a
file).
 The description of the data object incorporates the data object
and all of its attributes.
 A data object encapsulates data only—there is no reference
within a data object to operations that act on the data.
Data Objects and Attributes
 A data object contains a set of attributes that act as an aspect,
quality, characteristic, or descriptor of the object

What is a Relationship?
 Data objects are connected to one another in different ways.
 A connection is established between person and car because the two objects are
related.
 A person owns a car
 A person is insured to drive a car
 The relationships owns and insured to drive define the relevant

connections between person and car.
 Several instances of a relationship can exist
 Objects can be related in many different ways
CRC Cards
 CRC: Class-Responsibility-Collaborator
 CRC cards provide the means to validate the class model with
the use case model
 Responsibilities are a way to state the foundation of the
system design CRC cards support responsibility-based
modelling
 CRC cards allow a useful early check that the expected uses of
the system can be supported by the proposed classes. They
support a brainstorming technique that works with scenario
walkthroughs to stress-test a design.
 Responsibility-based modelling is appropriate for designing
software classes as well as for partitioning a system into
subsystems. The underlying assumptions are:
CRC Cards : Continue
 People can naturally make meaningful value judgements about the
allocation of responsibilities
 The central issues surrounding how a system is partitioned can be
captured by asking what the responsibility of each part has toward
the whole - Is it really the responsibility of this object to handle this
request? Is it its responsibility to keep track of all that information?

CRC Cards Structure
 CRC Cards explicitly represent multiple objects simultaneously
1. The Name of the class it refers to

2. The Responsibilities of the class
 These should be high level, not at the level of individual methods
3. The Collaborators that help discharge a responsibility

Design by Responsibilities
 Responsibility-based Modelling allows
 Defining of the components from which the system is
constructed { The allocation of responsibilities to system
components
 Defining of the services (or functionalities) provided by them
 The assessment how components satisfy the requirements as
stated by the use cases
 Types of Responsibilities
 { To do something (active responsibilities)
 { To provide information (acting as a contact point)
A Library System : Continue
 Requirements
1. The library system must keep track of when books are
borrowed and returned
2. The system must support librarian work
3. The library is open to university staff and students
4. University staff can borrow up to 25 different books
5. Students can borrow up to 15 different books

 Use Cases
 Class Diagram
 CRC Cards
 A CRC Game
CRC Cards and Quality
 CRC Cards – provide a good, early, measure of the quality of the system (design)
– solving problems now is better that later .
 are flexible - use them to record changes during validation
 Too many responsibilities – This indicates low cohesion in the system – Each class
should have at most three or four responsibilities – Classes with more
responsibilities should be split if possible
 Too many collaborators – This indicates high coupling – It may be the division of
the responsibilities amongst the classes is wrong

Soft Eng 1 - Chapter No 4-2

Uploaded by

Copyright:

Available Formats

Soft Eng 1 - Chapter No 4-2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Soft Eng 1 - Chapter No 4-2

Uploaded by

Copyright:

Available Formats

Chapter No 1

Department of computer science

 1 UNDERSTANDING DATA MINING

 2 NEED OF DATA MINING

 3 ABOUT DATA MINING

 WHAT IS DATA MINING?

 IT IS THE PROCESS OF MINING KNOWLEDGE FROM LARGER

BIG DATA -----DATA MINING TECHNIQUES---------- USEFUL

1 : COMPANIES AND ORGANIZATION GET HUGE AMOUNT OF DATA

2: AS SIZE OF DATABASE INCREASING AND IT IS VERY DIFFICULT TO

3: THE USE DATA MINING TECHNIQUES WHICH INCLUDES AI AND

4: THIS SPECIFIC DATA HELPS THEM FOR TAKING DATA-

01: WE ALSO GET TRENDS , PATTERNS, INSIGHT OF

02: DATA MINING IS ALSO CALLED AS ‘KNOWLEDGE

 DATA MINING TECHNIQUES INCLUDES.

 DATA MINING TECHNIQUES INCLUDES.

 DATA MINING TECHNIQUES INCLUDES.

D) NATIVE BAYES ALGO

 DATA MINING CONTENTS:

C) DATA PRE PROCESSING

 DATA MINING CONTENTS:

B) PROCESS OF EXTRACTION OF USEFUL INFORMATION

KDD ( KNOWLEDGE DATA DISCOVERY )

DATA CLEANING - INTEGRATE-- EVALUATE --- REPRESENT

 Requirements analysis results in the specification of software’s

operational characteristics, indicates software’s interface with other

system elements, and establishes constraints that software must meet.

 Requirements analysis allows you (regardless of whether you’re called

a software engineer, an analyst, or a modeler) to elaborate on basic

requirements established during the inception, elicitation, and

negotiation tasks that are part of requirements engineering.

 The requirements modeling action results in one or more of the

following types of models:

what, not how.

 What user interaction occurs in a particular circumstance,

what objects does the system manipulate, what functions

must the system perform, what behaviors does the system

exhibit, what interfaces are defined.

 (1) to describe what the customer requires.

 (2) to establish a basis for the creation of a software de-sign.

 (3) to define a set of requirements that can be validated once the

different point of view.

and the specific sequence of activities that occur as the software is

2. Class-based elements model the objects that the system will

state of the system or the classes that reside within it.

4. flow-oriented elements represent the system as an

information transform, depicting how data objects are

transformed as they flow through various system functions.

 Although the success of a computer-based system or product is

measured in many ways, user satisfaction resides at the top of the

 If you understand how end users (and other actors) want to

interact with a system, your software team will be better able to

properly characterize requirements and build meaningful analysis

the system (actors) and what should be performed by the

 (1) What should we write about?

 (2) How much should we write about it?

 (3) How detailed should we make our description?

 (4) How should we organize the description?

 A variation of a narrative use case presents the interaction as an ordered

sequence of user actions.