Presentation on theme: "Requirement Analysis. Data-flow Diagram(DFD) IEEE defines DFD (also known as bubble or work flow diagram) as, ‘a diagram that depicts data sources, data."— Presentation transcript:
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
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
DFD Symbols) Process Data Flow Data Store Source/Sink (External Entity) or
Process Work or actions performed on data (inside the system) Labels should be verb phrases Receives input data and produces output
Rule 1: Process Can have more than one outgoing data flow or more than one incoming data flow
Data Flow Represents the movement of data from its source to destination within the system Arrows depicts movement of data
Data Store Is used in a DFD to represent data that the system stores Labels should be noun phrases
Rule: Data Store Must have at least one incoming and one outgoing data flow
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
Rules for Using DFD Symbols Data Flow That Connects YESNO 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
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
…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
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
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.
Example 1: RMS Calculating Software Compute- RMS 0 User Data-items result Context Diagram
Level 2 DFD a b c Square Square Square asq bsq csq Mean msq rms Root 0.2.5
A software that pays worker Context level diagram: worker Payroll software Worker ID Pay check
Level 1 DFD for payroll system
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.
Context level diagram
Time date and destination ticket Air line reservation
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
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
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
Level 1 DFD for payroll system Weekly time sheet
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 ]
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
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.
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.
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.
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
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.
-Aggregation structure : models the whole – part relationship. An object may be composed of many objects.
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
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
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.
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.
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.
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
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 CustomerMember
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) Data Object can be
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 Attributes
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
ATTRIBUTE…. Example : Data object BOOK has the following attributes TITLE AUTHOR PRICE Operating System GalvinRs 500 Software Engg PressmanRs 800
Relationships The connection of data objects or entities with each other is known as relationship. car personcar person Basic connection between data objects owns Relationship between data objects
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
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.
E-R Diagram : Examples
Modality: the customer is required to have an order Modality: the customer can arrive without any order Cardinality: single customer Placed a given order Cardinality: customer has Many order customerorder
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.
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
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
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
3 Parts of a Decision Table 1.Condition stubs Lists condition relevant to decision 2.Action stubs Actions that result from a given set of conditions 3.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
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
Decision Table Note: for salaried employees the action stub chosen will always be the same…therefore hours worked is an indifferent condition
Reduced Decision Table Because of indifferent condition, the complete decision table can be reduced to one with fewer rules
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
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
Decision tree representation of salary decision
Alternative decision tree representation of salary decision