ERDModuleRequirements

Requirements for ER Module, Version 1

This document was converted by David Van Couvering from the the original provided in Word format.

Home Page

Review

This document is currently under review.

To view existing comments or to add your own, please go to the review page

NEW: Version 2 of the requirements is now available here

Authors:
Wessam Abd Rabo
Nada El-Newehy
Ibrahim Foudah
Youmna Hussein
Aisha Khairat
Maha Shawki

from the graduate program at the American University in Cairo, Computer Science Department.

Supervisors: Dr. Awad Khalil and Dr. Sherify Aly

Contents


Introduction

Aim of the Document

The Software Requirements Specification document aims and focuses to describe the main structure of the system, how its components interact with one another, and the requirements met by the system on a simple and thorough scale. Relationships between entities of the system are often modeled or illustrated in various parts of the document. In other words, the SRS should completely describe the external behavior of the application or subsystem identified. It also explain s and describes nonfunctional requirements, design constraints and other factors necessary to provide a complete, broad and comprehensive description of the requirements for the designated software.

Aim of the Project

As mentioned in our thesis proposal, NetBeans is a platform for developing applications in the Java programming language. The NetBeans Integrated Development Environment (IDE) had many points which resulted in it being the chosen IDE to which the project in hand is to be developed. Not only is it popular, easy to use and has many influential options, but is also written in pure Java and consequently can run on any machine that supports Java Virtual Machine (JVM). Another important aspect is its modular structure, increasing its extensibility (adding modules increases its functionalities).

Henceforth, the aim of our project is to provide a convenient way for NetBeans users in general and developers in specific, to have a product that will basically be a generalization of Entity Relationship (ER) Modeling. The user will have the facilities that come with the whole modeling process, which includes drawing the ER diagram from the components that will be supported by the system (using dragging and dropping), import an already existing ERD, auditing and editing the drawn diagram and finally to generating the corresponding SQL schema which will be embedded in Java code. Moreover, reverse engineering of the whole process shall be allowed; the user will be able to convert from the code to the equivalent ERD.

Intended Audience

This document is our graduation SRS document which will be presented to our supervisors Dr. Awad Khalil and Dr. Sherif Ali, and to our coordinator Dr. Amr El-Kadi. It will also be accessible to all faculty members in our Computer Science department.

Defintions, Acronyms and Abbreviations

  • ERD - Entity Relationship Diagram
  • SQL - Structured Query Language
  • DB - Database
  • FK - Foreign Key
  • PK - Primary Key
  • GUI - Graphical User Interface
  • JDBC - Java Database Connectivity

References

  • Previously presented thesis proposal
  • Sommerville, Ian. Software Engineering , 7th ed. New York. Addison Wesley.

Problem Statement

Netbeans, as powerful as it is, has no module that enables developers to design their own ERD by dragging and dropping its components, edit ERDs, generate corresponding code, import ER models designed in external design environments like Smartdraw, generate the corresponding code, and reverse engineer the whole process starting from the code to the ERD.

Methodology

The Rational Unified Process model (RUP) will be the one used to deliver the project in hand. The task will be implemented fully using Java which is a machine independent language, and should have the capability of running on different platforms.

Undertaken Tasks

  • Gathering information
  • Identify and classify the system and user requirements
  • SRS submission
  • Successfully submitting the SRS document
  • System Design
  • Design a NetBeans 5.0 module.
  • Design of code generated subsystem.
  • System Implementation
  • Implementing the different components and subsystems of the project.
  • Unit Testing
  • Testing each subsystem independently.
  • System Integration
  • Integration of different subsystems to form the whole system.
  • System Testing
  • Testing the system as a whole.
  • Uploading the module
  • Installing the Plug-in to NetBeans.
  • Submission of the Final Document
  • System Design Specification
  • Submission of the detailed design document of the system.
  • Test Specification
  • Submission a full report of the known bugs and errors in the system.
  • Final Document
  • Submit the final project document.

Overall Description

Product Perspective

Our product is basically an extension to NetBeans, where we aim at integrating a plugin into its powerful platform. The main functionality of our plugin is to enable developers to smoothly convert any Entity-Relationship Diagram (ERD) into a physically existing Database. The user will have the luxury of formulating an ERD by dragging and dropping its different components and having its corresponding DB tables generated out of it.

Product Features

The user will have the luxury of dragging the different components of an ERD and dropping them in the design view. If the user switches to the code view, he will find the code corresponding to this ERD automatically generated. In addition to that, the developed can import an existing ER design file to the project. Our plug-in can also deploy the relational database that corresponds to the designed ER diagram where the user in given the freedom to manipulate the database tables. Our plug-in can also generate the ER diagram along with the Java code from an existing relational database.

User Characteristics

Since our plug-in is for the NetBeans IDE, we assume that its users, mainly developers, do have a technical background and are already familiar with the NetBeans IDE. If this is the case, the user is not expected to face any difficulty dealing with our plug-in due to its friendly and elaborate graphical user interface.

User Requirements

1. The user should be able to create a new project

Rationale: Since the plug-in runs on the top of the NetBeans platform, the user will create a new java project which will open as an empty project and then the user can add any new type of the supported files and choose to either start by designing a new ER diagram or convert a relational database into an ER Diagram.

2. The user should be able to choose the project’s location and name

Rationale: upon creating the project, the only thing the user will be asked to identify is the new project’s name and location so that the system can use this information to save the project in the specified directory with the given name.

3. The user should be able to open an existing project

Rationale: besides creating a new project, the user can open an existing java project that he previously started to work on.

4. The user should be able to create a new ER design file

Rationale: after the project is created and uploaded by the system in the project explorer, the user can create a new deign file so that he can start designing an entity relationship diagram using the drag and drop components that are going to be loaded by the system once he creates the ER D file.

5. The user should be able to add an existing ER design file to the project

Rationale: the user can add an existing ER design file that belongs to another java project previously designed using the plug-in.

6. The user should be able to upload a relational database and convert it into an ER diagram

Rationale: to be able to use the reverse engineering functionality provided by the plug-in, the user should upload the relational database that he desires to convert into its corresponding ER diagram and get the automatically generated corresponding java code to this diagram/database.

7. The user should be able to get the SQL schema that corresponds to the ER diagram

Rationale: on designing a new ER diagram, the user can choose to get a separate file containing the SQL schema that corresponds to the design along with the generated java code. This feature is optional and the SQL code generated will not be editable, but can be edited by the user using any external text editor.

8. The user should be able to import ER models designed in external design environments

Rationale: as an additional feature provided to the user, any ER diagram designed in an external environment such as IBM rational architect, Smartdraw and MS Visio and then the user should be able to edit it using the graphical user interface provided by the package

9. The user should be able to graphically design ER models using drag and drop components

  • 9.1 The user should be able to drag and drop ER components

Rationale: the user will be provided with a design palette that contains the ER components that he need to design an ER diagram. Examples of such components are: entity, weak entity, single-value attributes, key attribute, relationship, recursive relationship, connectors, multi-value attributes.

  • 9.2 The user should be able to set properties of the added component

Rationale: the user can set the properties of the components he adds to the ER diagram. Such properties can be the name of the component, size, and alignment.

  • 9.3 The user should be able to zoom in and out

Rationale: the user can zoom in and out the designed diagram to get a better view of specific components.

  • 9.4 The user should be able to preview diagram

Rationale: the user can preview the design in a separate window to see a complete view of the diagram.

  • 9.5 The user should be able to auto align diagram components

Rationale: by clicking a certain button, the user can have the ER components in the diagram automatically aligned in a way that enhances the view of the diagram such that no components would be overlapping and the diagram would not look overcrowded.

  • 9.6 The user should be able to remove components

Rationale: the user can also delete the components he adds to the diagram. Any associated connectors or relationships to this component will be deleted as well.

  • 9.10 The user should be able to edit the diagram

Rationale: the plug-in enables the user to open a previously designed diagram in edit mode.

10. The user should be able to compile application files

Rationale: the user can compile the java code and the ERD file to get the corresponding class files prior to building and running the application.

11. The user should be able to locate the compiled errors

Rationale: By doubling clicking the error in the output panel of NetBeans the user can locate the error resulting from the compilation process.

12. The user should be able to build the application

Rationale: building the application will generate the Java archive files (JAR) that can be used to deploy the application.

13. The user should be able to run the application

Rationale: running the application will allow the user to get the desired output. This is different from deploying the database which is done using different functionality.

14. The user should be able to switch between the code and Design views

Rationale: after designing the ER diagram in the design view, the user can switch to the code view containing the generated java code that corresponds to the ER diagram. However, this generated code can not be edited by the user, thus, if the user needs to do any modification, he should switch back to the design view to edit the diagram and new code will be generated as a result of the modification.

15. The user should be able to deploy relational database form an ER diagram

Rationale: after designing an ER diagram or importing a diagram, the user will get the automatically generated JDBC code that contains SQL create statement used to generate the database tables that corresponds to the designed ER and the generated code.

16. The user should be able to manipulate the deployed database

Rationale: after deploying the database, the user can perform some operations to manipulate the resulting tables including the following functions

  • 16.1 The user should be able to view the database tables using a database explorer
  • 16.2 The user should be able to edit database tables
  • 16.3 The user should be able to add a new table in the db
  • 16.4 The user should be able to add a column in the db table
  • 16.5 The user should be able to add Indexes (primary keys)
  • 16.6 The user should be able to add relationship between tables (foreign keys)
  • 16.7 The user should be able to add table unique and check constraints

17. The user should be able to finalize the generated code

Rationale: some information about the can not be added on the design view such as the entities data types and other integrity and value constraints. Thus, the Java code that is automatically generated from the ER diagram is not complete. The user needs to be finalize this code in order for the system can generate a complete database. The user will be provided with a properties palette in the code view that enables him to add information like the columns data types and create other constraints.

  • 17.1 The user should be able to Add column data type
  • 17.2 The user should be able to Add integrity and value constraints
  • 17.3 The user should be able to Configure database

18. The user should be able to Add java code

Rationale: besides the java code that is automatically generated from on designing the ER diagram, the user can add additional code in the code view to complete his application. This added code is editable, unlike the generated java code. This code will be placed in the same file containing the automatically generated code but it should not affect the generation of the relation database.

19. The user should be able to view the files in a file explorer

Rationale: the user can view all the added files including the ER file and other opened files in the file explorer that is going to be loaded by the system once the system creates a new project or open an existing one.

20. The user should be able to Save the project

Rationale: saving the project can be done at any point in time. Also auto save will be provided by the system

System Functional Requirements

1. The system shall Add the plug-in functionality in a created project

Description: The system shall enable the user to choose to use the plug-in functionality in a project that he creates on NetBeans.
Inputs: The developer chooses the option of using the plug-in.
Source: The developer. Outputs: The plug-in functionality is added to the created project.
Destination: N/A
Action: The system shall be able to allow the user to choose using the plug-in functionality in a project that he already created. The system should load all the necessary files that are important for using the plug-in in the project’s directory.
Requires: The user creates the project to which the plug-in functionality is to be used.
Pre-Condition: There is enough disk space in the project’s directory partition in order to store the necessary files that are loaded to use the plug-in.
Post-Condition: The user can now have the option of adding new special file types to the project such as ERD files. Side Effects: N/A.

2. The system shall Load the project into the project explorer

Description: Once the project is created, the system shall load the project into the project explorer tab where the user can add the appropriate types of files to his project and view the already added files in the project. Inputs: The created project.
Source: The project directory.
Outputs: The DB project is loaded into the project explorer
Destination: The project explorer
Action: the system shall be able to load the created project into the project explorer in a tree fashion where the main project folders such as: source packages, test packages, libraries and test libraries are explored as the tree nodes. By this tree view for the project, the user can add different items and files to his project and also view the different existing items in the project. As the user chose to use the plug-in functionality, he can add new special type files such as ERD files.
Requires: The project is created in its special directory.
Pre-condition: N/A.
Post-condition: The user can start adding files to the project through the project’s explorer.
Side Effects: The project GUI is updated and the project tree view is displayed in the project explorer.

3. The system shall Load the directory files into the files explorer

Description: After the user chooses the option to use the ERD plug-in, the system shall load the files necessary for this plug-in from the project directory into the files explorer tab where all the files in the project’s directory are explored.
Inputs: Files that the system creates in the project’s directory when the plug-in is used.
Source: The project directory.
Outputs: The plug-in files in the project directory are loaded into the files explorer.
Destination: The files explorer
Action: the system shall be able to load the plug-in files created in the project’s directory into the files explorer in a tree fashion where the folders containing those files represent the tree nodes. Those folders are such as: nbproject (NetBean project), src (source, where files added by user are explored), test and other files and folders Requires: The project is created in some directory, and the system loaded the plug-in files into the project’s directory.
Pre-condition: N/A.
Post-condition: N/A.
Side Effects: The project GUI is updated and the files tree view is displayed in the files explorer.


4. The system shall Allow adding new ERD file to the project

Description: The system shall be able to add a new ERD into the project.
Inputs: ERD file name specified by user, or if the user did not specify a name, the system shall give the file a default name.
Source: The developer.
Outputs: The ERD file is created in the project’s directory, and added into the project and files explorers.
Destination: The project’s directory, project explorer and files explorer.
Action: The system shall be able to add a new ERD file into the project’s directory. The system shall give this file a default name unless the developer changed it. Also the system shall give this file some special extension so as to be distinguished as an ERD file.
Requires: The project is created in its special directory and loaded into the project’s explorer.
Pre-condition: There is enough space to add this file.
Post-condition: The ERD file can be viewed through its design view or code view. Also the components palette can be loaded.
Side Effects: The project GUI is updated and the newly created file appears in the project explorer and files explorer.

5. The system shall Allow importing an already existing ERD file:

Description: The system shall be able to import an already existing ERD file in special formats and add it to the project.
Inputs: The ERD file that is to be imported.
Source: The directory where this file is stored.
Outputs: The ERD file is imported, converted to the ERD format supported by the plug-in and the result file is added to the project.
Destination: The project directory, the project explorer and files explorer.
Action: The system shall be able to import an already existing ERD file into the project’s directory. Those files will be in special formats such as IBM rational architect, Smartdraw, MS Visio or the format of the plug-in itself. In order to import those files and deal with them in the project, the system needs to convert them to the ERD format supported by the plug-in and give them the standard extension the plug-in provides. Of course if the imported files are already in the format of the plug-in, there is no need for the conversion process.
Requires: The project is created in its special directory and loaded into the project’s explorer.
Pre-condition: The file is stored in one of the special formats that the system supports and there is enough space to add this file.
Post-condition: The ERD file can be viewed through its design view or code view and can be edited. Also the components palette can be loaded.
Side Effects: The project GUI is updated and the newly imported file appears in the project explorer and files explorer.

6. The system shall Load the components palette

Description: The system shall be able to load the palette that contains the various ERD components.
Inputs: N/A.
Source: N/A.
Outputs: The palette of ER components is displayed for the user to use.
Destination: The design subsystem.
Action: The system shall be able to load the palette that contains the various ERD components once an ERD file is added to the project. The palette should contain ERD components such as Entity types (both week and strong), relationship types and attributes.
Requires: An ERD is added to the project, and the user selects the design view of that file
Pre-condition: N/A
Post-condition: The user can drag and drop components from the palette.
Side Effects: The project GUI is updated the components palette appears in its suitable place.

7. The system shall Load the properties palette

Description: The system shall be able to load the palette that contains the various properties of the various ERD components.
Inputs: N/A.
Source: N/A.
Outputs: The palette of properties is displayed for the user to use.
Destination: The design subsystem.
Action: The system shall be able to load the palette that contains the properties of various ER components once components are added to the design area. The palette should contain properties for entity type such as the entity name, relationship types such as the cardinality and the FK in the entity type that hosts the FK and attributes such as being a PK, unique or the attribute type such as being int, varchar, text…etc. the palette should be loaded each time the user selects a component, and displays the stored properties of that component. Editing in the properties of attributes should only be reflected in the code view not the design view because some properties such as the type are not part of the specifications of the ERD. Therefore, such properties should affect the code view only in order to keep the consistency and correctness of the ERD.
Requires: A component is dragged into the design area, and the user selects that component.
Pre-condition: The component palette is loaded.
Post-condition: Properties of existing components can be edited through the components palette.
Side Effects: The project GUI is updated the properties palette appears in its suitable place.

8. The system shall Allow dragging and dropping components:

Description: The system shall be able to allow the user to drag and drop the various components from the palette into the design area.
Inputs: The component dragged from the palette.
Source: The components palette.
Outputs: The component is added into the design area.
Destination: The design area.
Action: The system shall be able to allow the developers to drag ER components from the palette into the design area and keep track of those components. The system should know where those components are placed so that when the project is reopened later every component will be loaded in its specific place.
Requires: The components palette is loaded and the design area is available for the developer.
Pre-condition: N/A.
Post-condition: the user now can edit in the properties of the dragged component.
Side Effects: The project GUI is updated and the component appears in the design area.

9. The system shall Allow Editing properties of components

Description: The system shall be able to allow the user add or edit the properties of the components in the design view.
Inputs: The value of the property.
Source: The properties palette.
Outputs: The property value is added to that component and reflected to the code view.
Destination: The design area and/or code area (based on the property type).
Action: The system shall be able to allow the developers to add more properties to the components in the design view, or edit the already existing propertiess. For example, for entity types the properties could be the name of the entity. For attributes, properties can be specifying whether it is a PK, unique or its type like int, varchar()…etc. For relationship type, the properties can be the cardinality of the relation and the FK in the entity type that hosts the foreign key. If the user edits some property, the system should track if this editing can be done or not. For example if the user is to edit a PK attribute that has a FK in another entity type, the system should make sure that both attributes (the PK and FK) will be of the same type.
Requires: The properties palette is loaded and the design area is available for the developer.
Pre-condition: N/A.
Post-condition: N/A.
Side Effects: The project code view is updated with the new values of properties, and for some properties (such as cardinalities, unique constraints and entity types names) the design view is affected as well.

10. The system shall Validate ERD

Description: The system shall be able to validate the ERD designed by the user.
Inputs: ERD file after dragging and dropping components into the design area.
Source: Validation subsystem.
Outputs: If the ERD is valid then it is marked as valid, if not it is marked as invalid and the errors are reported to the user.
Destination: Design area or the place where errors are to be displayed.
Action: The system shall be able to validate the ERD drawn in the design area. It should check that the design abides by the ERD rules. E.g. it is invalid to have a relationship without specifying it is between which two entity types. If the design is invalid errors should be reported to user.
Requires: The ERD is drawn in the design area.
Pre-condition: N/A.
Post-condition: The user can switch to the code view if the ERD is reported to be valid.
Side Effects: Errors are reported to user in case of invalid ERD, by popup messages for example.

11. The system shall Generate Code

Description: The system shall be able to generate code that corresponds to the components in design area.
Inputs: The components dragged into the design area.
Source: The design view area.
Outputs: JDBC code generated in the code view.
Destination: The code view area.
Action: The system shall be able to generate code as a response to the user’s action of dragging and dropping a component into the design area. This code is JDBC code that should represent the ERD and it interfaces the DB. The code is generated by compiling the components in the design view to get their corresponding code once the user switch into the code view. Also the edited properties of the components are to be reflected in the code. This generated code cannot be edited by the user.
Requires: The user drags and drops components into the design view, and then switch to the code view tab.
Pre-condition: The ERD is validated by the system and no errors are found.
Post-condition: The user cannot in the generated code.
Side Effects: Code view is updated with the changes in the design view or the changes in the properties.

12. The system shall Allow removing components from design view

Description: The system shall be able to allow the user to remove components from the design view, and do the appropriate modifications in the code view.
Inputs: The component removed.
Source: The design view.
Outputs: The component is deleted from the design area.
Destination: Garbage memory.
Action: The system shall be able to allow the developers to remove ER components from the design view. It should do the necessary validations before removing this component such as checking for dependencies. For example, if the user is to remove an entity type that has a FK in another entity type, the system should give an error and does not allow the deletion of the component unless the other entity type is removed. Also the code corresponding to that component is to be removed.
Requires: There is some component in the design area which the user desires to remove.
Pre-condition: There are no other components that depend on that component the user desires to remove.
Post-condition: N/A.
Side Effects: Both design and code view are updated with the deletion of the components.


13. The system shall Auto-align components

Description: The system shall be able to auto-align the ERD components upon user’s request.
Inputs: The user request to auto-align the components (e.g. shortcut keys).
Source: The developer through a keyboard shortcut.
Outputs: The alignment of the components.
Destination: The design view.
Action: The system shall be able to auto-align the ERD components once the user clicks on some keyboard shortcut or chooses that option from the view menu. The system is to find the best alignment of the components so that they will be clearer to view.
Requires: There are components in the design area and the user chooses this function on the design area.
Pre-condition: N/A.
Post-condition: N/A.
Side Effects: The project GUI is updated and the components are aligned in the design area.

14. The system shall Generate Relational DB

Description: The system shall be able to generate the relational DB that corresponds to the ERD designed.
Inputs: The ERD file saved in the format provided by the plug-in.
Source: the project directory.
Outputs: The relational DB is created and loaded in memory.
Destination: The memory.
Action: The system shall be able to generate the relational DB that corresponds to the designed ERD and the code generated for it. The entity types in the ERD generate the tables, the relationship types generate the relations between those tables and the attributes generate the columns of those tables. Also the properties that were edited and reflected in the code view are to be reflected in the relational DB. The system uses the generated code to generate the DB as it is JDBC that can interface with databases in Java environments such as NetBeans.
Requires: The ERD is developed by the user, both the code view and design view are validated and the user chooses the option of creating the DB.
Pre-condition: Memory is enough to load the DB especially for large DBs.
Post-condition: The system/user can now connect to the DB and store data into it.
Side Effects: More memory consumption with large DBs.

15. The system shall Load the relational DB into the runtime explorer

Description: The system shall be able to explore the relational DB in the runtime explorer.
Inputs: The relational DB.
Source: The memory.
Outputs: The relational DB is explored in the runtime explorer.
Destination: Runtime explorer.
Action: The system shall be able to explore the relational DB after it is loaded into memory in the runtime explorer. The DB is to be presented in a tree fashion that shows its different components such as tables, views and procedures. The system should allow the user to add or delete those different components, to modify their structure, such as modifying the table columns, or to store data in the tables.
Requires: The relational DB is loaded into the memory.
Pre-condition: N/A.
Post-condition: The user can start adding, deleting or modifying tables, views or procedures in the DB. He can also store data into the DB tables.
Side Effects: The project GUI is updated and the DB tree view is displayed in the runtime explorer.


16. The system shall Generate ERD from relational DB

Description: The system shall be able to get the ERD of an existing DB.
Inputs: The relational DB.
Source: DB subsystem.
Outputs: The ERD file is generated.
Destination: Design view and code view.
Action: The system shall be able to generate the ERD file from an existing relational DB. It should be able to translate all the tables, columns and relations into entity types, attributes and relationship types in the ERD and show it to the user in both the design view and code view.
Requires: The relational DB is loaded into the runtime explorer and the user chooses the option of generating the ERD.
Pre-condition: N/A.
Post-condition: the user can start editing in the generated ERD.
Side Effects: The project GUI is updated and the ERD is displayed in the design view.

17. The system shall Generate SQL from ERD

Description: The system shall be able to generate the SQL schema that corresponds to the designed ERD.
Inputs: The JDBC code.
Source: The code view.
Outputs: The SQL schema.
Destination: An external file.
Action: The system shall be able to generate the SQL schema that corresponds to the ERD schema. When the user chooses the option to generate the schema from the ERD, the system should use the JDBC code to generate the SQL and gives the user the option to save the ERD as .sql in some specified directory.
Requires: The user requests to save the ERD as SQL and the ERD is valid.
Pre-condition: N/A
Post-condition: N/A.
Side Effects: a .sql file is generated and stored in the directory the user specifies.

18. The system shall Save the current state of the project

Description: The system shall be able to save the project in its current state in terms of the opened files and the last alignment of the components in the design area.
Inputs: The project files.
Source: N/A.
Outputs: The state of all the project files is saved.
Destination: The project directory.
Action: The system shall be able to save the project in its current state. When the user closes the project, the system should save the current state of the project files. It should memorize what the opened files were so that when the project is reopened those files will be automatically opened. Moreover, the system should save the state of the components in the design view so that when the

user opens the design view again the components will be aligned as they were before closing the project.

Requires: The user requests to close the project.
Pre-condition: N/A
Post-condition: N/A.
Side Effects: Additional information are to be stored with the project, which is the current state of the files.


Nonfunctional Requirements

1.Product Requirements

1.1 Performance Requirements

Speed
Our product is expected to perform any action required by the user in a minimal period of time. If the time to perform the request exceeds this ceiling, a message should be displayed to the user explaining what should be done (for example, reinitiating the request).

For example:

If the User drags a component into the design view, the system is expected to respond at once. If any problem was faced, the system should issue an error message and ask the user to try again.

If the user drags a component, the code view should immediately show the corresponding code to that action.

Space
The system should allocate memory efficiently, so as not to cause degradation in the performance and speed. Memory should be freed once not needed using the famous techniques of garbage collection.

The product should consume the minimal amount of memory from the user’s computer, either for installation, or during its usage.

1.2 Reliability Requirements

According to the IEEE, reliability is defined as “the probability that software will not cause the failure of a system for a specified time under specified conditions” 1. At the design phase, the system should have backup units so as to make it more reliable. For example, if an error occurs in the system and the application hangs, there would be a backup point to which the system can rollback, so as to make the loss minimal. The reasons behind software failures are more or less the same in many software systems. Errors, ambiguities, carelessness or incompetence in writing code, inadequate testing are among the most important reasons that we are very concerned about avoiding 2. We will avoid that by designing extensive testing schemes and vigorously testing the application.

1.3 Usability Requirements

In the case of our plugin, by usability we mean that the application should be user-friendly and easy to use. The time required from a developer to acquire the know-how of our tool should be minimal. This will be accomplished through a user-friendly.

1.4 Portability

Portability is a key value proposition for Java as well as the NetBeans IDE and Platform, so for consistency reasons since our project is a plug-in for NeatBeans it has to be portable too. Our project should be capable of running on different platforms without any change. To enhance the portability of our system java will be used as the main programming language for the system, and also universally standard tools will be used.

1.5 Correctness

The system should behave as expected, user and functional requirements should be meet also. The system should support synchronization between the code view and the design view reflecting one another.

2.Organization Requirements

2.1 Implementation Requirements

Since our application is a plug-in in NetBeans, then we are constrained with an implementation language that is java compatible generally, and NetBeans compatible specifically. Therefore, our implementation will be mainly using Java. In addition to Java, we expect to use XML.

2.2 Delivery Requirements

Concerning the delivery of our application, by the SDS Demo next December, we will be delivering a .nbm (NetBeans Module) file.


External Interface Requirements

User Interfaces

The user will have the interface of NetBeans IDE along with that of our added features. The user will be provided with a design view which is made up of a design area and some panels. These panels will contain the objects that the user can drag and drop into the design area. Some buttons will also be added to the user interface which will enable him to use added features. Also there is a code view which will contain the code formed from the design the user has in his design view.

Hardware Interfaces

Our project is a plug-in for NetBeans and it will be developed in Java which is platform independent. The software is not implemented for any specific platform.

Software Interfaces

The system makes use of the several services provided by NetBeans APIs. A dedicated subsystem will be responsible to control the interaction between NetBeans and our plug-in.

System Architecture

Design Module

It is used to enable any design related functionality like drawing the dragged and dropped components and also responsible for validating the schema

Code Generator

It is responsible for generating the java code that corresponds to the existing ER diagram

Entity-Relationship Diagram (ERD) Generator

It is responsible for generating the ER diagram from the existing tables in the relational database. Our system communicates with the database through the DBMS which is a middleware used by any component that requires direct access to the relational database.

Time Plan

Phase/Milestone From To
Extended Research Jun 10, 2007 Sep 10, 2007
Extended Research: Researching NetBeans Jun 10, 2007 Aug 1, 2007
Extended Research: Researching ER & Plugin Mid-July, 2007 Sep 10, 2007
Design Phase Aug 26, 2007 Oct 15, 2007
Design Phase: Preparing for the SDS Mid-Aug 2007 Mid-Sep 2007
Design Phase: SDS Presesentation (Milestone) Sep 30, 2007 Sep 30, 2007
Implementation Phase Aug 23, 2007 Nov 5, 2007
Testing Phase Oct 1, 2007 Nov 30, 2007
Testing Phase: Unit Testing Oct 15, 2007 Nov 10, 2007
Testing Phase: Integration Testing Nov 10, 2007 Nov 25, 2007
Testing Phase: System Testing Nov 15, 2007 Nov 30, 2007
Final Presentation (Milestone) Dec 2, 2007 Dec 2, 2007


Other tools

(Added by David Van Couvering)

This section analyzes other tools in order to provide guidance and inspiration to our effort.

I also really want to do some user research to find out what features developers like most around database tooling and E/R diagramming in particular. I'll work on that and get back to the group as soon as I can - DavidVanCouvering

A nice page with a collection of tools: http://www.databaseanswers.com/modelling_tools.htm

Looking at Technorati and Google, the following tools have the most popularity:


Tool Technorati Rating Google Web hits Google Group hits Comments
ERWin 125 28 million hits 680,000 hits
MS Visio 120 16 million hits 592,000 hits Visio is not used just for E/R diagrams
ER Studio 125 7 million hits 342,000 hits
Oracle Designer 20 6 million hits 180,000 hits
Rational ER 35 2 million hits 200 hits
MS Visual Studio ER 10 1.3 million hits 26 hits
DBVisualizer 3 114,000 hits 605 hits
DBDesigner 4 352,000 hits 803 hits




Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo