Jan Koichi Dayanan BSCS SOFTWEN Assignment Data flow diagrams are used to describe how the system

transforms information. They define how information is processed and stored and identify how the information flows through the processes. When building a data flow diagram, the following items should be considered: where does the data that passes through the system come from and where does it go, what happens to the data once it enters the system (i.e., the inputs) and before it leaves the system (i.e., the outputs), what delays occur between the inputs and outputs (i.e., identifying the need for data stores). Software process modeling tries to capture the main characteristics of the set of activities performed to obtain a software product, and a variety of models have been created for this purpose. A process model can be used to define a recommended software process. This paper deals with the prescriptive software process modeling and the most relevant results of this approach is presented Symbols used in DFD:

A context diagram defines the scope of the system by identifying the system boundary contains: a. one process (which represents the entire system) b. all sources/sinks (external entities) c. data flows linking the process to the sources and sinks (external entities)

Level 0 is a DFD which consists of the following: a. describes the overall processing of the system b. show one process for each major processing step or functional requirement c. data flows from the context appear on system diagram also (level balancing) d. can show a single data store to represent all data in aggregate at this level e. can draw duplicate sources, sinks and data stores to increase legibility Level 1 is a DFD which consists of the following: explode the processes shown on the level-0 diagram each process is represented by its own DFD balance data data flows on upper level appear on lower level, or data flows on upper level are broken into component pieces with components shown on lower level each lower level shows greater and greater detail follow numbering convention Entity Relationship Diagram (ERD) is a snapshot of data structures. ERDs show entities in a database and relationships between tables within that database. It is essential to have one of these if you want to create a good database design. The patterns help focus on how the database actually works with all of the interactions and data flows, although another useful tool is a Data Flow Diagram (DFD) which more directly describes this. Modality refers to the minimum number of times an instance in one entity can be associated with an instance in the related entity. In data modeling, the cardinality of one data table with respect to another data table is a critical aspect of database design. Relationships between data tables define cardinality when explaining how each table links to another. In the relational model, tables can be related as any of: many-tomany, many-to-one (rev. one-to-many), or one-to-one. This is said to be the cardinality of a given table in relation to another. For example, consider a database designed to keep track of hospital records. Such a database could have many tables like: a Doctor table full of doctor information a Patient table with patient information and a Department table with an entry for each department of the hospital. In the model used above: a. There is a many-to-many relationship between the records in the doctor table and records in the patient table (Doctors have many patients, and a patient could have several doctors);

b. a one-to-many relation between the department table and the doctor table (each doctor works for one department, but one department could have many doctors). c. one-to-one relationship is mostly used to split a table in two in order to optimize access or limit the visibility of some information. In the hospital example, such a relationship could be used to keep apart doctor's personal or administrative information.

Symbols used in ERD