1. Requirement Analysis

2. Data-flow Diagram(DFD)
IEEE defines DFD (also known as bubble or work flow diagram) as,
‘a diagram that depicts data sources, data sinks, data storage, and processes performed on the data as nodes, and logical flow of data as links between the nodes’
Data flow diagram (DFD) is a picture of the movement of data between external entities and the processes and data stores within a system

3. Objective of DFD
Is to provide an overview of the transformation that occurs in the input data within the system in order to produce an output

4. DFD Symbols) Process Data Flow Data Store Source/Sink
(External Entity)

5. Process Work or actions performed on data (inside the system)
Labels should be verb phrases
Receives input data and produces output

6. Rule 1: Process
Can have more than one outgoing data flow or more than one incoming data flow

7. Process: Incorrect

8. Data Flow
Represents the movement of data from its source to destination within the system
Arrows depicts movement of data

9. Data Store Is used in a DFD to represent data that the system stores
Labels should be noun phrases

10. Rule: Data Store
Must have at least one incoming and one outgoing data flow

11. Source/Sink (External Entity)
External entity that is origin or destination of data (outside the system)
Labels should be noun phrases
Source – Entity that supplies data to the system
Sink – Entity that receives data from the system

12. Rules for Using DFD Symbols
Data Flow That Connects
YES NO
A process to another process
A process to an external entity
A process to a data store
An external entity to another external entity
An external entity to a data store
A data store to another data store
A data store to an external entity

13. Directions to be followed while constructing dfd
Identify the major inputs and outputs
Starting from the inputs, work toward the outputs, identify the major transforms in the way.
Procedural information like loops and decisions not be shown in the DFD
Label each component properly
Never try to show the control logic. If we find thinking in terms of loops and decisions, it is time to stop and start again.
Each process should be numbered uniquely, but the numbering should be consistent

14. …continue
A DFD should be organized in a series of levels so that each level provides more detail than the previous level
A DFD should be refined until each process performs simple functions
The name of the process should be carried to the next level of DFD

15. Various levels of DFD Level 0 DFD (Context diagram) :
Shows an overall view of the system.
It should depict the system as a single bubble.
All external entity interacting with the system should be represented in this diagram
Level 1 DFD : This elaborates level 0 DFD and splits the process in to detailed form
Level 2 DFD : This elaborates level 1 DFD and displays the process(s) in to more detailed form

16. Example 1: RMS Calculating Software
A software system called RMS calculating software reads three integral numbers from the user in the range between and and determines the root mean square of the 3 i/p numbers and then displays it:
accept the input numbers from the user,
validate the numbers,
calculate the root mean square of the input numbers,
display the result.

17. Example 1: RMS Calculating Software
Compute- RMS 0
Data-items
User
result
Context Diagram

18. Example 1: RMS Calculating Software
Valid - data
Compute- rms 0.2
Validate- numbers 0.1
RMS
Display 0.3
Level 1 DFD

19. Example 1: RMS Calculating Software
numbers
Read- numbers 0.1
Validate- numbers 0.2
Valid - numbers
Data-items
error
Compute- rms 0.3
Display 0.4
result
RMS

20. Level 2 DFD c b csq bsq a rms msq asq Square 0.2.3 Square0.2.2
Mean 0.2.4
Root 0.2.5
Square 0.2.1
asq

21. A software that pays worker
Context level diagram:
Pay check
Payroll software
worker
Worker ID

22. Level 1 DFD for payroll system

23. A XYZ college offers many courses to the students
A XYZ college offers many courses to the students. A students submits the application specifying the name of the course, if the seats are available then the admission is granted other wise it is rejected.

24. Context level diagram

26. Air line reservation
Time date and destination
ticket

27. Air line reservation

28. Data Dictionary
It is an organized listing of all data elements that are pertinent to the system, so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and even the intermediate calculations.
It is a repository that contains descriptions of all
data objects concerned or produced by the software

29. Some terminologies related to DD are
Data Element : Data element is the smallest unit of data that has some meaning. E.g. part code.
Data Structure: is a group of data elements that describe a unit in the system. E.g. part detail.
Data Store: is a data structure for collecting data input or data output. E.g. Part register
Data Flow: is a unit of data that is in motion

30. Importance of DD It is a valuable reference for designing the system.
It is used to design and writing code during the next phases.
It helps the analyst to record the details of each element or structure
It assists in communicating meanings of different terms used

31. Level 1 DFD for payroll system
Weekly time sheet

32. Data Dictionary
Weekly_timesheet=Employee_name + Employee_Id + [Regular_hours + Overtime_hours]*
Pay_rate=[Hourly | daily | weekly] x amount
Employee_name = Last + First + Middle
Employee_Id = digit + digit + digit + digit
[+ sequence or composition
| selection
* Iteration ]

33. Most DD contains the following information
Name: The primary name of the data or control item, the data store, or an external entity
Alias: Other names used for the entry
Where used/How used: e.g. Input to the process, output to the process, as a store, or as an external entity
Supplementary information: other additional information such as values, restrictions or limitations

34. Object Oriented Modeling
In Object oriented Modeling, the system is viewed as a set of objects.
The objects interacts with each other through the services they provide.

35. Goals of modeling
Identify the object that exists in the problem domain
Define the classes by encapsulating it states and by its services
Identify the relationship that exists between objects of different classes
Over all model supports the desired user services.

36. Basic concepts and notations
Objects: The system is viewed as consisting of objects. The objects has attributes and provides services.
Attributes : add details about an object. It is a pure data value (like integer , string etc). It holds the state of an object.
Services: An object provides services or operations. These services are the only means by which the state of the object can be modified or viewed from outside.
Class: it is a type definition. Similar objects are grouped together to form a class.

37. Class Diagrams
A class is represented as a rectangle divided into 3 parts 1 Top part : contains name of the class 2 Middle part : lists the attributes of objects of that class 3 Third part : lists the services provided by objects of the class

38. To show the relationship between the classes few structures are used.
- Generalization-specialization structure : is used by a class to inherit all or some attributes and services of a general class and add more attributes and services to create a class that is a specialized version of the general class.

39. 290
Figure 8.2 Supertype and Subtype Relationships Between Object Classes
The figure above illustrates how to depict the supertype, subtype relationship between the PERSON, STUDENT, and TEACHER object classes. All the attributes and behaviors of the PERSON object are inherited by the STUDENT and TEACHER objects. Those attributes and behaviors that are uniquely apply to a STUDENT or TEACHER are recorded directly in the subtype class symbol.

40. -Aggregation structure : models the whole – part relationship
-Aggregation structure : models the whole – part relationship. An object may be composed of many objects.

41. Associations structure : helps to know the relations between the instances of a class with the instances of the other class.
An association between two classes may be
One-to-one : one instances of one class is related to exactly one instances of other class
One-to-many : one instances of one class is related to many instances of other class
Many-to-many : many instances of one class is related to many instances of other class

42. How to obtain the OO model for the system
Identifying data objects :
Make a brief summary of the problem.
Consider nouns, structures, devices, roles played, locations,organizational units etc
To be considered as an object, the system need to be remembered something about the object

43. Identifying structures: Structures represents the hierarchies that exist between the object classes.
hierarchies are defined by the concept of generalization-specialization, whole-part relationships between the objects.

44. Identifying attributes : Attributes add details about an object and store data for the object.
The attributes to be considered depends on the problem.
E.g. while modeling a hospital system,
for the class ‘Person’ the attributes are name, height, weight, date_of_birth may be needed, these may not be needed for database for a country that keeps track of populations.
So only the attributes that are relevant and required by the problem domain should be considered.

45. Identifying Associations : Associations describe the relationship between the instances of several classes. The association can be 1:1,1:M,and M:M
Identifying services: An object performs a set of predefined services. To identify the services, identify the occur services, which are needed to create, destroy, and maintain the instances of the class. other services depend on the type of services the system is providing.

46. Entity Relationship modeling
IEEE defines ER diagram as
‘ a diagram that depicts a set of real-world entities and the logical relationships among them’
It contains:
Data Objects (Entities)
Attributes
Relationships

47. Data Objects
A data object is a representation of composite information. (Composite information refers to different features or attributes of a data object.)
Has a set of attributes to describe it
Drawn as a labeled rectangle in ERD
Customer
Member

48. Data Object can be
External entity – (anything that produces or consumes information)
Thing (e.g. report or display)
Role (e.g. salesperson)
Organizational unit (e.g. accounting department)
Place (e.g. warehouse)
Structure (e.g. File)

49. Attributes
Data Attributes describe the properties of a data object. Attributes that identify entities are known as key attributes, that describes an entity are known as non-key attributes.
Data attributes are used to perform the following function
Naming the instance of the data object
Description of instance

50. ATTRIBUTE an entity has a set of attributes
attribute defines property of an entity
it is given a name
attribute has value for each entity
value may change over time

51. ATTRIBUTE…. Example : Data object BOOK has the following attributes
TITLE AUTHOR PRICE
Operating System Galvin Rs 500
Software Engg Pressman Rs 800

52. Relationships
The connection of data objects or entities with each other is known as relationship.
car
person
Basic connection between data objects
person
car
owns
Relationship between data objects

53. Cardinality
Cardinality is the specification of the number of occurrences (instances) of one object that relates to the number of instances of another object.
One-to one relationship
One-to many relationship
Many-to-many relationship

54. Modality
Modality describes the possibility that whether a relationship between the entities is required or not.
The modality of a relationship is 0 if the relationship is optional, and the modality is 1 if an occurrence of the relationship is essential.

56. E-R Diagram : Examples

57. customer order Modality: the customer is required to have an order
Modality: the customer can
arrive without any order
Modality: the customer is
required to have an order
customer
order
Cardinality: single customer
Placed a given order
Cardinality: customer has
Many order

58. PDL (Program Design Lang.)
PDL , also known as structured English or pseudo code is a language that uses the vocabulary of a natural lang(English) and the overall syntax of a programming lang.
The lang is mainly applied during the detailed design phase and is best used to describe alogs and specify interfaces between modules.

59. Benefits of PDL
It enables the progmmer to concentrate on the algo without worrying about all the syntactic details of a particular lang.
It is expressed in an easy-to-read format. Thus the design can be converted easily to executable code
Reviews become easier since easier to understand
It supports the idea of iterative refinement

60. Examples start Take two numbers
Add two numbers and store the result in the variable called sum
Divide sum by 2 and store the result in Mean
Display the result
stop

61. Modeling Logic with Decision Tables
A matrix representation of the logic of a decision
Specifies the possible conditions and the resulting actions
Best used for complicated decision logic

62. 3 Parts of a Decision Table
Condition stubs
Lists condition relevant to decision
Action stubs
Actions that result from a given set of conditions
Rules
Specify which actions are to be followed for a given set of conditions
Indifferent Condition
Condition whose value does not affect which action is taken for two or more rules

63. Procedure for Creating Decision Tables
Name the condition and values each condition can assume
Name all possible actions that can occur
List all rules
Define the actions for each rule
Simplify the table

64. Decision Table
Note: for salaried employees the action stub chosen will always be the same…therefore hours worked is an indifferent condition

65. Reduced Decision Table
Because of indifferent condition, the complete decision table can be reduced to one with fewer rules

66. Modeling Logic with Decision Trees
A graphical representation of a decision situation
Decision situation points are connected together by arcs and terminate in ovals
Main components
Decision points represented by nodes
Actions represented by ovals
Particular choices from a decision point represented by arcs

67. Modeling Logic with Decision Trees (cont.)
Read from left to right
Each node corresponds to a numbered choice on a legend
All possible actions are listed on the far right

68. Decision tree representation of salary decision

69. Alternative decision tree representation of salary decision