Software Engineering Lab (KCS-651) aS eC re Session — 2023-24 (Odd Semester) Submitted To - Submitted By - Student Name: Roll No: Section/Group: Department of Computer Science and Engineering GL Bajaj b institute of Technology and Management, Greater NoidaExperiment No: 1 AIM: Prepare a SRS document in line with the IEEE recommended standards. Outcome: Can produce the requirements in a SRS document. Objective: Prepare a SRS document in line with the IEEE recommended standards. Description: ‘An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) priorto any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. A well-designed, well-written SRS accomplishes four major goals: * It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. * It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.* It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised * It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification. ‘SRSs are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which information is gathered about what requirements are needed-and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return- on-investment (RO!) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed, ASRS document on Hospital Management System: INTRODUCTION 1.1 Purpose The purpose of this document is to describe the requirements for the hospital "Patient Info Management System 97'8MS:! The intended audience includes all stakeholders in the potential system! These include, but are not necessarily limited to, the following: Administrative Staff, patients and developers. Developers should consult this document and its revisions as the only source of requirements for the project. They should not consider any requirements statements, written or verbal as valid until they appear in this document or its revision. This is a Software Requirements Specification (SRS) for the Hospital Management System. It describes the functions, goals and tasks that the system can perform. This is used to describe the scope of the project and to plan for the system's design and implementation. The purpose is to describe all the requirements for the Hospital Management System. The following are some of the stakeholders: + administrative staff doctors nurses surgeons developers. The hospital management and its team members uses this document as the primary means to communicate confirmed requirements to the development team. The development team expects many face-to-face conversations that will undoubtedly be about requirements and ideas for requirements. However, only the requirements that appear in this document or a future revision, will be used to define the scope of the system1.2 Scope The software product is the Hospital Management System. The system will be used to allocate beds to patients on a priority basis, and to assign doctors to patients in designated wards as need arises. Doctors will also use the system to keep track of the patients assigned to them. Nurses who are in direct contact with the patients will use the system to keep track of available beds, the patients in the different wards, and the types of medication required for each patient. Doctors must make rounds to pick up patients’ treatment cards in order to know whether they have cases to treat or not. The intentions of the system are to reduce over-time pay and increase the number of patients that can be treated accurately. Requirements statements in this document are both functional and non-functional. 1.3 Definitions, Acronyms, and Abbreviations PHN: Personal Health Number on health card Report: An account of patients Database: Collection of information in a structured form Front-desk staff: Administrative staff that work at reception desk Logon ID: A user identification number to enter the system Password: A word that enables one to gain admission into the system ID: Patient Identification number GUI: Graphical User Interface SRS: Software Requirements Specification General Description 2.1 Product Perspective This Hospital Patient Management System is a self contained system that manages activities of the hospital as bed assignment, operations scheduling, personnel management and administrative issues. Various stakeholders are involved in the hospital system. 2.2 Product Functions The system functions can be described as follows: Registration: When a patient is admitted, the front-desk staff checks to see if the patient is already registered with the hospital. If he is, his/her Personal Health Number (PHN) is entered into the computer. Otherwise a new Personal Health Number is given to this patient. The patient's information such as date of birth, address and telephone number is also entered into the computer system. Consultation: The patient goes to the consultation-desk to explain his/her condition so that the consulting nurse can determine what kind of ward and bed should be assigned to him/her. There are two possible circumstances: a) If there is a bed then the patient will be sent to the bed to wait for the doctor to come. b) If there is no bed, the patient is put on a waiting list until a bed becomes available. Patient check out. If a patient checks out, the administrative staff shall delete his PHN from the system and the just evacuated bed is included in available-beds list.Report Generation: The system generates reports on the following information: patients, bed availability and staff schedules after every six hours. It prints out all the information on who has used which bed, when and the doctor that is taking care of a given patient as well as expected medical expenses. 2.3 User Characteristics The system will be used in the hospital. The administrators, doctors, nurses and front-desk ‘staff will be the main users. Given, the condition that not all the users are computer-literate. Some users may have to be trained on using the system. The system is also designed to be user-friendly. It uses a Graphical User Interface (GUI). Front-desk staff: They all have general reception and secretarial duties. Every staff has some basic computer training. They are responsible for patient's check-in or notification of appropriate people (e.g. notify administrator or nurse when an event occurs).Administrators: They all have post- secondary education relating to general business administration practices. Every administrator has basic computer training. They are responsible for all of the scheduling and updating day/night employee shifts. Administrators in the wards are responsible for assigning doctors and nurses to patients. Nurses: All nurses have post-secondary education in nursing. Some nurses are computer literate. Consulting nurses to whom patients give short descriptions of their conditions are also responsible for assigning patients to appropriate wards if the beds are available, otherwise putting patients on the waiting list. Nurses in wards will use the system to check their patient list. Doctors: All doctors have a medical degree. Some have further specialized training and are computer literate. Doctors will use the system to check their patient's list. 2.4 General Constraints The system must be delivered by deadline. The system must be user-friendly 2.5 Assumptions and Dependencies It is assumed that compatible computers will be available before the system is installed and tested. Itis assumed that the Hospital will have enough trained staff to take care of the system 3. Specific Requirements 3.1 Functional Requirements Registration Add patientsThe system shall allow front-desk staff to add new patients to the system.Assign ID The system shall allow front-desk staff to give each patient a ID and add it to the patient's record. This ID shall be used by the patient throughout his/her stay in hospital. Consultation Assign Ward The consulting nurse shall use a system to assign the patient to an appropriate ward. Assign to Waiting List The consulting nurse shall use a system to assign Patient to a waiting list if no bed is available. Medical matter management Assign Doctor The administrative staff in the ward shall use a system to assign a doctor to a given patient. Assign Nurse The administration staff in the ward shall use a system to assign a nurse to a given patient. Inform Doctors The system shall inform doctors of new patients. Inform Nurses The system shall inform nurses of new patients. Emergency Case In an emergency case, the administrative staff shall use a system to assign an emergency room, doctors and nurses to the patient immediately. Surgery case In @ surgery case, the administrative staff shall use a system to assign a surgery room, surgeon and nurses to the patient. Generate Report (normal) The system shall generate the patient's situation record every two hours for normal patients. Generate Report(Severe) The system shall generate a patient's situation record every half hour for severe patients. Record procedure The whole treatment procedure for the patient shall be recorded by the system. Inform patient: The system shall automatically inform the patients who are on the bed waiting list of available beds whenever they become available. Check Out Delete Patient ID The administrative staff in the ward shall be allowed to delete the ID of the patient from the system when the patient checks out.Add to beds-available list The administrative staff in the ward shall be allowed to put the beds just evacuated in beds- available list. Report Generation: Patient information Every six hours the system shall generate reports on patients about the following information: patient's PHN, patient's name, ward name, bed number and the doctor's name. Bed Availability Every six hours the system shall generate reports on bed availability about the following information: ward name, bed number, occupied/unoccupied Staff Schedule Every six hours the system shall generate reports on staff schedule about the following information: staff ID, staff name, staff type, duty shift. Database Patient Mandatory Information Each patient shall have the following mandatory information: first name, last name, phone number, personal health number, address, postal code, city, country, patient identification number. Update Patient Information The system shall allow the user to update any of the patient's information Search for Patient The system shall allow the user to search for patient's information by last name or PHN or patient ID. Staff Mandatory Information Each staff member in the hospital shall have the following mandatory information: identification number, first name, last name, phone number, address, postal code, city, country, employee type, duty schedule. Update Staff Information The system shall allow the user to update any of the staff's information as described in SRS023 Employee Information The system shall allow the user to search for employee information by last name, or ID number. Ward Types The ward is categorized into four types: Maternity, Surgical, Cancer and Cardiac. Ward Information Each ward in the system shall include the following mandatory information: ward name, ward number, list of rooms in ward. Room InformationEach room in the system shall include the following mandatory information: room number, list of beds in room, full/not full Bed Information Each bed in system shall include the following information: bed number, occupied/unoccupied, patient PHN. 3.2 Design Constraints Database ‘The system shall use the MySQL Database, which is open source and free. Operating System The Development environment shall be Windows 2000. Web-Based The system shall be a Web-based application. 3.3 Non-Functional Requirements Security Patient Identification The system requires the patient to identify himself /herself using PHN Logon ID ‘Any user who uses the system shall have a Logon ID and Password. Modification ‘Any modification (insert, delete, update) for the Database shall be synchronized and done only by the administrator in the ward. Front Desk staff Rights Front Desk staff shall be able to view all information in the system, add new patients to the system but shall not be able to modify any information in it. Administrators’ Rights Administrators shall be able to view and modify all information in system Nurses’ Rights Nurses shall only be able to view all information in the system. Doctors Rights Doctors shall only be able to view all information in system 3.3.2 Performance Requirements Response Time The system shall give responses in 1 second after checking the patient's information CapacityThe System must support 1000 people at a time. User-interface The user-interface screen shall respond within 5 seconds. Conformity The systems must conform to the Microsoft Accessibility guidelines 3.3.3 Maintainability Back Up The system shall provide the capability to back-up the Data Errors The system shall keep a log of all the errors. 3.3.4 Reliability Availability The system shall be available all the time.Experiment No: 2 AIM: Draw the use case diagram and specity the role of the actors. Also state the precondition, postcondition and function of the use case. Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor. Software Requirements; draw.io UML, Windows XP. ‘Outcome: Can produce the requirements in Use Case diagram. Description: According to the UML specification a use case diagram is “a diagram that shows the relationships among actors and use cases within a system.” Use case diagrams are often used to: Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model or a business model. Communicate the scope of a development project Model your analysis of your usage requirements in the form of a system use case model Use case models should be developed from the point of view of your project stakeholders and Not from the (often technical) point of view of developers Creating Use Case Diagrams We start by identifying as many actors as possible. You should ask how the actors interact with the system to identify an initial set of use cases. Then, on the diagram, you connect the actors with the use cases with which they are involved. If actor supplies information, initiates the use case, or receives any information as a result of the use case, then there should be an association between them. Conclusion: The Use case diagram was made successfully by following the steps described above.Output :Experiment No: 3 AIM: Draw the activity diagram. Outcome: Can produce the activity diagram for requirements modeling, Objective: To Draw a sample activity diagram for real project or system. Description: Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor. Software Requirements: Draw.io UML, Windows XP, Theory: Actors: Customer: Initiates the process of browsing, searching, and purchasing products. Admin: Manages the products, user accounts, and resolves issues. Use Cases: 1. Browse Products: Precondition: Customer is logged in. Postcondition: List of products is displayed Function: Allows the customer to view available products. 2. Search Products: Precondition: Customer is logged in. Postcondition: Search results are displayed. Function: Enables the customer to search for specific products. 3. Add to Cart: Precondition: Customer is logged in and has selected a product. Postcondition: Product is added to the cart. Function: Allows the customer to add products to their shopping cart. 4, Checkout: Precondition: Customer has products in the cart. Postcondition: Order is placed, and payment is processed. Function: Enables the customer to finalize the purchase. 5. Manage Products: Precondition: Admin is logged in. Postcondition: Product database is updated. Function: Allows the admin to add, edit, or remove products. 6. Manage Users: Precondition: Admin is logged in. Postcondition: User accounts are updated. Function: Allows the admin to manage customer accounts.Output:Experiment No: 4 AIM: Indentify the classes. Classify them as weak and strong classes and draw the class diagram. ‘Outcome: Class diagram helps to understand the static structure of a system. It shows relationships between classes, objects, attributes, andoperations. Objective: Identify the classes. Classify them as weak and strong classes and draw the class diagram. Description: Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard and mouse,colored monitor, Software Requirements: Draw.io UML, Windows XP Description: A class diagram models the static structure of a system. It shows relationships between classes, objects, attributes, and operations. ‘As mentioned above, and as seen in Diagram 4, classes are represented by rectangular symbols,and different arrows are used to represent the relationship between classes. Note that class diagrams don't depict any interactions between classes. Here is a detailed breakdown of the different symbols used when constructing class diagrams.Class Class Name attributes ‘operations( ) Class Name attributes operations( ) responsibility The class name is always shown in the first section, the attributes in the second, and operations in the third. Attributes are values that define a class. Classes can carry out processes known as operations. Note: there can be a fourth section(responsibility), which is an optional section for including additional information about the class.Class Name attributes + public operations - private operations # protected operations Visibility Visibility symbols are used to determine the accessibility of the informationcontained in classes. Note: The '+" represents public operations, vice-versa, °-" represents private operations .Plus, “#" is for the protected operations. ‘As mentioned above, class diagrams can represent relationships between classes. There are seven relationships that are commonly shown in class diagrams. They are association (the most common being bidirectional and unidirectional association), _ inheritance, realizatiovimplementation, dependency, aggregation, composition, and multiplicity. (Class Name Class Name atributes attributes Bidirectional Association — ‘opernions Abilateral association is represented by a straight line connecting two classes. It simply demonstrates that the classes are aware of their relationship with each other.Unilateral Association Inheritance Class Name Class Name attributes attributes loperations() operations() A unilateral association is represented by an open arrowhead connecting one class to another. It shows that one class is aware of its relationship with another class. Animal age : Int gender : String isMammal() mate() Duck + beackColor : String = "yellow" Zebra + is_wild : Boolean + swim) + quack() + rund Indicate a “child-parent” relationship between classes. The child class is a specialized, sub-class of the parent.Realization/mplementation Dependency + movet90 : void + moveDowa0 : void + moveLeAd: void + moveRiahl0 :void rmoveLfi() void moveRigh) : void veto ae a a yin 4 OF center : MoveablePoint Fea = ySpeed int }+_ MoveableCirele(x: nt: int. ery faedee ‘xSpeed int,ySpeed:int) I+ moveUpO : void > toStringO : String [+ moveDown() : void }+ moveUpO : void + moveLefi() = void + moveDownt) : void + moveRight() : void ‘One class implements the behavior specified by another class. Class Name: Class Name attributes LL — — — —Jatributes loperations() operations() ‘As the name suggests, one class depends on another. A dashed arrow shows this.Deparment [LA east attributes attibutes Aggregation loperations() lopetations0) This represents a unilateral relationship between classes. One class is part of, or subordinate to, another. In this instance, the child and parent classes can exist independently. Company Department asst areibutes > anributes, a loperatious() loperations() Composition Itis a form of aggregation where one class is dependent on another. One class is a part of the other. In this instance, the child classes and parent classes cannot exist independently. eo Sl eats Multiplicity Hie age) ——+ | Room 1 Betroom Multiplicity is used to determine how many times an attribute ‘occurs. In this example, this house has exactly one kitchen and at least one bedroom.Experiment No: 5 Aim: Draw the sequence diagram for any two scenarios. ‘Outcome: Can draw the sequence diagram Objective: Drawing the sequence diagram Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard and mouse,colored monitor. Software Requirements: DRAWIO. UML, Windows XP. Theory: UML sequence diagrams model the flow of logic within the system in a visual manner, enabling the user both to document and validate the logic, and are commonly used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which focuses on identifying the behavior within your system. Sequence diagrams, along with class diagrams and physical data models are the most important design-level models for modern application development. Sequence diagrams are typically used to model: Usage scenarios: A usage scenario is a description of a potential way the system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases. For example, a student enrolls in the university, and then immediately enrolls in three seminar The logic of methods: Sequence diagrams can be used to explore the logic of a complex operation, function, or procedure. One way to think of sequence diagrams, particularly highly detailed diagrams, is as visual object code.. The logic of services: A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. This includes we-services as well as business transactions implemented by a variety of technologies such as CICS/COBOL or COBRA-complaint object request brokers (ORBs)Output:Experiment No: 6 Ai raw collaboration diagram. ‘Outcome: Students will be able to draw the collaboration diagram Objective: Draw the collaboration diagram using draw.io UML. Description: Collaboration diagrams are relatively easy to draw. They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers. As the name suggests, they show the sequence of the messages as they are passed between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used . Output:Experiment No: 7 ‘AIM: Draw the state chart diagram Outcome: Can produce the state chart diagram for requirements modeling. Objective: To Draw a sample activity diagram for real project orsystem. Description: Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 MB RAM, Standard keyboard and mouse, colored monitor Software Requirements: Draw.io UML, Windows XP, Theory: UML primarily uses diagrams to represent systems. These diagrams can be broken down into two types: behavioral UML diagrams, and structural UML diagrams. UML is an extremely versatile and widely-recognized language. It is standard language used by many developers, as well as increasing number business professionals. It's flexibility means that it can be applied to a number of IT or business- related situations, so that you can make it applicable to the system or technology you are using. Output:Experiment No: 8 ‘Aim: Draw the component diagram. Outcome: Can draw the Component diagram. Objective: Drawing the component diagram Description: A component is something required to execute a stereotype function. Examples of stereotypes in components include executables, documents, database tables, files, and library files. Components are wired together by using an assembly connector to connect the required interface of one component with the provided interface of another component. This illustrates the service consumer - service provider relationship between the two components. An assembly connector is a "connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port.” When using a component diagram to show the internal structure of a component, the provided and required interfaces of the encompassing component can delegate to the corresponding interfaces of the contained components. A delegation connector is a "connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component's parts." The example above illustrates what a typical insurance policy administration system might look like. Each of the components depicted in the above diagram may have other component diagrams illustrating its internal structure. Component is represented by a rectangle with either the keyword "component" or a stereotype in the top right comer: a small rectangle with two even smaller rectangles jutting out on the left. The lollipop, a small circle on a stick, represents an implemented or provided interface. The socket symbol is a semicircle on a stick that can fit around the lollipop. This socket is a dependency or needed interface. The component diagram notation set now makes it one of the easiest UML diagrams to draw. Figure 1 shows a simple component diagram using the former UML 1.4 notation; the example shows a relationship between two components: an Order System component that uses the Inventory System component. As you can see, a component in UML 1.4 was drawn as a rectangle with two smaller rectangles obtruding from its left side.Output:Experiment Ni ‘Aim: Perform forward engineering in java. (Model to code conversion) Forward engineering involves translating a higher-level model or design into actual code. In the context of Java, this typically means going from a design or model (such as a UML class diagram) to Java code. I'll provide a simple example where we'll create a Java class based on a hypothetical model. Let's say we have a class diagram with a class named Person having attributes name and age. Here's, how you might forward engineer this into Java code: Model (UML Class Diagram) Forward Engineering to Java Code: I Person java public class Person { I Attributes private String name; private int age; I Constructors public Person() { 1! Default constructor } public Person(String name, int age) { this.name = name; this.age = age; } 1! Getters and Setters public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() {return age; } public void setAge(int age) { this.age = agi } 1 Other methods if needed @Override public String toString) { return "Person{" +*name="+name + \"+", age=" + age +); } } Conclusion This Java class corresponds to the Person class in out model. It has private attributes(name and age), constructors, getters, setters, and a toString method for better representation. This is a basic example, and in real-world scenarios, you might have more complex relationships, methods, or other elements in your model that need to be translated to Java code. The key is to understand the structure and behavior of your model and represent that in Java classes and methods.Experiment No: 10 Aim: Perform reverse engineering in java. (Code to Model conversion) Reverse engineering involves analyzing existing code to create a higher-level model or design representation. In the context of Java, this typically means going from Java code to model, such as UML class diagram. Here, I'll provide a simple example of reverse engineering a Java class into UML class diagram. Let's say we have the following Java class: 1 Person.java public class Person { 1/ Attributes. private String name; private int age; 1 Constructors public Person() { 1/ Default constructor } public Person(String name, int age) { this.name = name; this.age = age; } 1/ Getters and Setters public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } Public void setAge(int age) { this.age = age; } 1 Other methods public void celebrateBirthday() { age++; ‘System.out.printin("Happy Birthday, " + name +"! You are now" + age +" years old."); } @Override public String toString() {return "Person{" + "name="+name + \' +", age=" + age +"); }Now, let's represent this Java class in a simplified UML class diagram: |-name: String | |-age:int | |+Person) | |+Person(name: String, age: int) | | + getName(): String | | +setName(name: String): void | |+getAge(: int | | + setAge(age: int): void | | + celebrateBirthday(): void | | + toString(): String} Conclusion In this UML class diagram: © Attributes are represented as fields within the class. * Constructors are listed with their parameter names and types. * Methods are listed with their names, return types (if applicable), and parameter names and types. Note that this is a simplified example. In a real-world scenario, you might have more complex relationships, associations, and other UML elements. Reverse engineering tools and techniques can assist in automatically generating UML diagrams from existing codebases, providing a visual representation of the software architectureExperiment No: 11 AIM: Draw the deployment diagram. Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard and mouse, colored monitor. Software Requirements: draw.io UML, Windows XP. ‘Outcome: Can produce the requirements in Use Case diagram. Description UML Deployment Diagram describes the software system's specification and the physical hardware system required to run the software. The Deployment Diagram also determines the installation of the software on the hardware. UML Deployment Diagram maps software segments of a method to the device that is going to implement it. Deployment diagram symbols { conan} = sepnceonization sta row pacar - | (gates | SS te = Dependency FJ “aan __ stentsOutput:Experiment No: 12 ‘Aim: Draw the ER-modeling diagram. Requirements: Hardware Interfaces . Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM . Screen resolution of at last 800 x 600 required for proper and complete viewing of screens .Higher resolution would not be a problem. © CDROM Driver Software Interfaces © WordPad or Microsoft Word © Any window-based operating systemn(windows 95/98/2000/XP/NT) Theory ERD stands for Entity Relationship Diagram. It is a type of visual model that describes different elements in a specific domain. ER diagrams are widely used in software engineering and database management. People use them to study the links between separate entities to create an organized and robust database. ER diagrams look like flow charts to some extent. To draw an ER diagram, you need to identify all the entities, know the relationships between all the entities, and add attributes foreach entity. There are many to create an ER diagram online using different diagrammatic tools. One such tool to create an ER diagram online is Edraw Max Online. Edraw Max is an online graphic creator that can be used to create different types of charts, graphs, and diagrams in just a few simple steps. To learn how to make an Entity Relationship diagram in the process of a few steps, please check out our ER diagram tutorial below.Output:Experiment No: 13 ‘Aim: To prepare DATA FLOW DIAGRAM for any project. Requirements: Hardware Interfaces . Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM . Screen resolution of at last 800 x 600 required for proper and complete viewing of screens Higher resolution would not be a problem. . CD ROM Driver Software Interfaces . WordPad or Microsoft Word * Any window-based operating system(windows 95/98/2000/XP/NT) Theory Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs. Data Flow Diagram Notation You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane & Sarson.Yourden & Coad Gane & Sarson Data Store Data Flow Be cd Ss Output: