BugRep Software Design Document Academic College of Tel-Aviv Yaffo Software Engineering Course Year
2006-2007
Project lead names
Shmuel Tyszberowicz, Yair Aviv
Project name
BugRep
Document
Software Project Plan
Document Version
0.1
Last update date
12/05/2007
Date First Version
12/05/2007
Team Members: Name
ID#
e-mail
Duty
Irit Lovenberg
033145558
[email protected]
Team Leader Software configuration manager, SQA manager
Yael Shemla
034279125
[email protected]
Sagy Rozman
038356036
[email protected]
Implementation manager, Design manager
Chen Levkovich
033026055
[email protected] m
Tests manager
Galit Daniel
034188334
[email protected]
Requirements manager
1
BugRep Software Design Document Revision Sheet Revision Number 0.1
Date
Brief Summary of Defects
12/05/2007
0.2
18/06/2007
Baseline draft document which includes: High Level Design. and Detail Level Design of BegRep defect management module. Detailed design section update: User Management and Domain Management. And the correspoinding update to Data Architecture and User Interface sections.
Confirmation Sheet Author
Name
Yael Shemla, Sagy Rozman, Irit Lovenberg
Software Configuration Manager
SQA manager
Team Leader
Yael Shemla
Chen Levkovich
Irit Lovenberg
Yael Shemla
Chen Levkovich
Irit Lovenberg
12/05/2007
12/05/2007
12/05/2007
Signature
Date 12/05/2007
ii
Revision Sheet
Version 1.0
BugRep Software Design Document
Date
TABLE CONTENTS 1
INTRODUCTION....................................................................................................6 1.1 PURPOSE .............................................................................................................6 1.2 SCOPE .................................................................................................................6 1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ...............................................7 1.3.1 Key Definitions ..........................................................................................7 1.3.2 Key Acronyms and Abbreviations..............................................................8 1.4 REFERENCES .......................................................................................................8
2
DESIGN OVERVIEW.............................................................................................9
3
USER CHARACTERISTICS .................................................................................9
4
SYSTEM ARCHITECTURE ...............................................................................10
5
DETAILED DESIGN ............................................................................................13 5.1 DEFECT MANAGEMENT MODULE .....................................................................13 5.1.1 Component DefectManagerBean Interface Description .........................13 5.1.2 Description for Component Defect ..........................................................14 5.2 USER MANAGEMENT MODULE .........................................................................15 5.2.1 Component UserManagerBean Interface Description ............................15 5.2.2 Component User Description ..................................................................15 5.3 DOMAIN MANAGEMENT MODULE ....................................................................16 5.3.1 Component DomainManagerBean Interface Description.......................16 5.3.2 Entity DomainInfo Description................................................................17 5.3.3 Entity DomainValue Description.............................................................17
6
DATA ARCHITECTURE.....................................................................................17 6.1 6.2 6.3 6.4
7
DEFECTS TABLE COLUMN DESCRIPTION .........................................................17 USERS TABLE COLUMN DESCRIPTION: .............................................................18 TBDOMAIN TABLE COLUMN DESCRIPTION .....................................................18 DOMAIN_VALUE TABLE COLUMN DESCRIPTION...........................................18
INTERFACE REQUIREMENTS ........................................................................19 7.1 REQUIRED INTERFACES .....................................................................................19 7.1.1 Interfacing the JSF presentation layer ....................................................19 7.1.2 Component DefectDetailsBean Description............................................19 7.1.3 Component UserBean Description ..........................................................20 7.1.4 Component DomainBean Description .....................................................21 7.1.5 Component DomainUtils Description .....................................................22 7.1.6 External system dependencies .................................................................23
8
USER INTERFACE ..............................................................................................24 8.1 8.2
GENERAL SCREEN CAPTURES ...........................................................................24 DEFECT MANAGEMENT SCREEN CAPTURES ......................................................24
Version 1.0
iii
BugRep Software Design Document 8.3 8.4 8.5
iv
USER MANAGEMENT SCREEN CAPTURES..........................................................26 DOMAIN MANAGEMENT SCREEN CAPTURES .....................................................28 ADDITIONAL SCREENS IN BUGREP TOOL ..........................................................29
Revision Sheet
Version 1.0
BugRep Software Design Document
Date
TABLE OF FIGURES FIGURE 1 - BUGREP HIGH LEVEL DESIGN .................................................... 11 FIGURE 2 – BEGREP ENTITIES DEPLOYMENT ............................................. 12 FIGURE 3 - CREATE DEFECT SCENRIO........................................................... 13 FIGURE 4 - LOGIN SCREEN ................................................................................. 24 FIGURE 5 - DEFECT LIST...................................................................................... 25 FIGURE 6 - CREATE NEW DEFECT ................................................................... 25
Version 1.0
v
BugRep Software Design Document
1
Introduction
This SDD shows how the software system of BugRep will be structured to satisfy the requirements identified in the software requirements specification [1]. It is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for implementation. In essence, this SDD becomes a detailed blueprint for the BugRep implementation activity [4].
1.1 Purpose The purpose of writing this SDD is to analyze software requirement gathered for BugRep project, in order to produce a description of the software's internal structure, which eventually serve as the basis for BugRep construction. In this document you will find a description of software architecture (how software is decomposed and organized into components), interfaces between those components. You will also encounter a description of the system components in a detailing level that enable their construction. The Intended audience for this SDD are: software engineers who will implement the model offered in this document; testers who use it to derive their test plan and reports; and off course managers and product managers who drive, control and monitor the project during all phases of its lifecycle, especially in such a crucial phase as design.
1.2 Scope This design document refers to software product named BugRep. The product will enable the automation, tracking and analysis of reporting defects in the company's software products. Users of this product will be able to report defects, track progress of defect handling, and change status of defects according to organizational needs and demands. The product will be highly adaptable and configurable and therefore its intended users are software development teams and organizations of deferent size and nature. [1] The product does not enforce or adhere to a given development methodology or organizational culture and can be equally used by agile as well as traditional styles of software projects. Artifacts beyond the scope of this product: • This product is aimed at reporting defects in the context of software products alone, rather than a general purpose defect reporting tool. • It will include basic user registration and management capabilities but is not aimed as a general purpose, organizational wide, personnel management tool. The expected benefits from using this product are: • Better tracking of defect handling and status in the organization • Standardization of the defect reporting procedure – all defects will be reported using a centralized tool, in a uniform way and kept in a single repository.
6
Version 1.0
BugRep Software Design Document • •
Date
Enabling the customers to report and track defects and their status by themselves – minimizing dependency on human factors and therefore minimizing chance of defect reports getting lost or not being reported. Cut down on manpower costs due to computerization of defect reporting procedures.
The dominant design concept which will be emphasized later in this document, is the encapsulation of the tool's state machine logic and data validity enforcement in one main entity (aka Engine). This entity cooperated with replaceable interface layers. The replacement of external mandatory interfaces shall not enforce any design or implementation change in the core entity. So for example, database type can be easily substituted by another kind according to new timing or storage requirements, and same applies to graphical user interface. This document might also include detail level design of BugRep components, hence throughout project lifecycle, related sections will be updated.
1.3 Definitions, Acronyms, and Abbreviations The following subsection shall provides the definitions of all terms, acronyms, and abbreviations required to properly interpret this SDD. 1.3.1
Key Definitions User
Any kind of user
Administrator
One who is in charge of managing a computer system
Defect
Every required change in the system. New requirements can be described also as a defect.
Defect Owner
A user that is marked as an assignee of a defect.
Project
Project is a logical group which includes several modules
Module
Module is a logical group which might includes several source files, processes etc.
Project Manager A user that is marked as a project manager of one or more projects. State machine
7
The state machine represents the lifecycle of a defect in the company
Version 1.0
BugRep Software Design Document State
The current position of a defect in the defined defect lifecycle
Action
An action represents a legal transition of a defect from one state to the other
1.3.2
Key Acronyms and Abbreviations
CRUD
Create, Read, Update and Delete actions
DB
Data Base
GUI
Graphical User Interface
SDD
Software Design Document
SRS
Software Requirements Specification
1.4 References
8
[1]
BugRep_SRS_ver_00_04.doc Software Requirement specification document of BugRep project, 18 January 2007
[2]
BugRep_SRS_RVW_ver_00_01.doc Summary of Peer Review performed on BugRep SRS, 11 January 2007
[3]
SWEBOK Guide to the Software Engineering Body of Knowledge, 2004 version
[4]
IEEE Std 1016 1998
Version 1.0
BugRep Software Design Document
2
Date
Design Overview
BugRep is a customizable and flexible defects tracking tool that offer to its different users efficient track of defect information throughout a development process. It also facilitates the development cycle by providing a common software platform for managing defects. Stakeholders of this project vary by their level in organization, and their tool usage methods. These include: software engineers, helpdesk team, quality assurance team, and even management staff [1] (see section 3-User Characteristics for details about each user's usage method.) BugRep tool design rely on interaction of users with GUI, which usually triggers database transactions behind the scenes, therefore one of this project risks is the response time reflected by GUI interactivity. By response time we mean, the time it takes to retrieve and present new information from database according the user triggered request (e.g. in case of specific report request, response time is the time span it takes to run a database query and present its results in BugRep GUI). Hence, BugRep design must ensure database transactions will not "break" it GUI interactive response time. BugRep design has several assumptions and dependencies critical to project success. Foremost it assume and rely on the existence of database for defect information storage. This DB should be accessible from a machine in which BugRep engine in executed (for details about BugRep engine see section 4-System Architecture, and about database description see section 6-Data Architecture). In addition this project also counts on feasance of email application (e.g. Microsoft Outlook service) for generation of predefined formatted email, Microsoft Excel as a way to output its reports. And eventually the tool need an access to Human Resources information center or other source that can provide user information (e.g. first and last name, email address etc.) [1]. More details about BugRep high level design will be described in section 4-System Architecture.
3
User Characteristics
Potential system users is almost all the aforementioned tools' stakeholders. Software engineers belonging to development teems, will get and update information about defects detail and status, using BugRep; helpdesk team will support and maintain BugRep tool; quality assurance team members will use BugRep as their main reporting tool in which detected defects details are stored; even management staff can BugRep as a mean of progress tracking and indicators producing [1]. The level of expertise required by this tool users divided into two domains, First belongs to computers field: mastering keyboard and mouse manipulation, and familiarity with web interfaces and windows based application, will be considered an advantage, since via same user interfaces BugRep fulfils its user requirements. Other skill needed by users belong to software domain: users should understand essence and nature of software 9
Version 1.0
BugRep Software Design Document defect (aka "bug"), this will ease user's understanding of the tools state machine, its actions scenario (for more details see section 5-Detailed Design). Interaction with the system can vary according to user privileges. BugRep is available for many users types. "read only" users will be able to view defect, generate reports and many other actions, except those who enable modification of defect information. "normal" users are ones which granted the ability to view and modify defect information. And "privileged" users, are like system administrator for BugRep support and maintenance purposes, for example such users can edit and add new users, modules and projects information into the tool database.
4
System Architecture
Encapsulation and well defined interfaces is the dominant design concept. BugRep state machine logic and data validity enforcement are all enclosed in one main entity (aka Engine). This entity cooperated with replaceable interface layers, such as graphical user interface and database. Replacement of external mandatory interfaces shall not enforce any design or implementation change in this core entity. Hence database type can be easily substituted by another kind of database according to new timing or storage requirements, and same applies to graphical user interface. BugRep design adopted server characteristics model, thus it form a program that awaits and fulfills requests from its users (i.e. requests relates to defects data manipulation, for more details see section 5-Detailed Design). Facilitation of user requests is done using friendly graphical user interface, while interfacing database as the tool's main data storage medium. BugRep server is constructed by two main entities, as depict in Figure 1, "BugRep Engine" and "BugRep GUI". We will start by explaining the last and simple one, "BugRep GUI". This entity form the tool's only graphical user interface, it shall allow users of create, read, update and delete defects. Moreover, report generation and administrative maintenance are also enabled via this entity. As mentioned before, actions are accessible per user according to its type and privileges, this is strongly expressed in this GUI entity. "BugRep Engine" is more complicated entity since it constitute the core of BugRep tool, and contain all its required logic, for example: validation of defect data manipulation, state machine handling, customization mechanism and enforcement of rules enabling user types differentiation. This entity also serve as "middleman" between users and defects database, this compel it having abilities such setup database connectivity and maintenance an interface for bidirectional data transactions (i.e. database to BegRep Engine and vise versa).
10
Version 1.0
BugRep Software Design Document
Date
Database
BugRep Server Database Interface
BugRep Engine
User Interface
Bug Rep GUI
*
*
Top Package::User
Figure 1 - BugRep High Level Design
As depict in Figure 1 relationship between BugRep server and user can be "one to many", which means that many users can access BugRep server at the same time. Moreover, tool's GUI can be implemented in several ways (e.g. Web interface, window based application), and at the same time approaching same Engine entity and produce similar information, which will be presented in different ways. In addition to entities mentioned before there is also a "family" of entities, in which each implement CRUD functionality, as described in Figure 2 . Report, User, Module, Project and Defect are entities that implement create, read, update and delete actions, but still each encapsulate entirely different component in its nature and role in the system. The following paragraph will try to clarify each of this entities main properties.
11
Version 1.0
BugRep Software Design Document Report entity is responsible for reporting management, which means allowing the different users of producing reports according to various criteria, for details refer to [1]. User entity responsible for the differentiation between user types, and the enforcement of rules which will enable each user only the actions which corresponds its privileges. Module and Project entities associate between defects to their relevant technical and business unit. Using the Project and Module Management functionalities enables the relevant user or manager to monitor the application and detect the areas that require further development and testing. Those entity functionality includes assignment of project-manager, ascribing module to project and assignment of module owner (for further description see [1] ). CRUD +Create() +Read() +Update() +Delete()
Defect
Defect GUI
Project
User
Report
Defect Engine
«utility» Database Interface +Write() +Read()
Figure 2 – BegRep Entities Deployment
Last but not least, is the Defect entity which encapsulate all defect management functionality. This means, in addition to CRUD actions, search and filter defects in BugRep defect storage, email defect details, change defect state (according to a statemachine), allocate assignee to handle a defect, clone and merge defect, customize defect details and track defect details changes (for further description see [1] ).
12
Version 1.0
BugRep Software Design Document
User
Defect GUI
Date
Defect Engine
«utility» Databse Interface
Create() Create() Write()
Figure 3 - Create Defect Scenrio
Figure 3 depict a scenario of defect creation, in which several of the previously mentioned entities are involved. In this scenario user with the appropriate privileges invoke "create-defect request" via "Defect GUI" entity. This request is then directed to "Defect Engine" entity which perform (according to it state machine based logic, and rules that must be enforced) a data manipulation and save in to defect database. Save procedure is started only if "create-defect request" action is valid (according to "BugRep Engine" indicators), and its content need will be stored. Thus validity and storage process are done by "Defect" entity.
5
Detailed Design
The following section lists the modules and classes that were implemented as part of the server-side, and are in charge of implementation of all entities and data management to the persistent storage of all the modules in the application.
5.1 Defect Management Module
5.1.1
Component DefectManagerBean Interface Description
DefectManagerBean is responsible for the lifecycle management of a Defect. 13
Version 1.0
BugRep Software Design Document Among its responsibilities are mostly CRUD operations. •
public Defect getDefect(int defectNumber) – Retrieves defect details from the persistent storage according to a given defect number, which is the unique identifier of a defect.
•
public void addNewDefect(Defect newDefect) – Adds the defect received as parameter to the persistent storage.
•
public void updateDefect(Defect newDefect) – Updates the details of the given defect parameter into the persistent storage according to what they were updated by the user.
•
Public List
filterDefects(String query, User assignee, User submitter) – Returns a list of Defects, retrieved from the persistent storage, that all matches the given criteria as specified in the input parameter of the query. Actually invokes the query and returns the result that is received.
• 5.1.2
Description for Component Defect
This class represents a Defect and contains all information relevant and required to manage the entity Defect. It is bound to the Defects database table. Every property defines methods to set and retrieve (set/get) the property’s value. The Defect class has the following properties:
14
•
title - the name of the defect
•
description – a String describing the Defect.
•
priority – The priority (currently represented as a String)
•
state – a string representing the defect’s status.
•
detectedDate – a Date which depicts the time of reporting.
•
responsibleApplication – The project in which the defect was found.
•
comment - String representing additional free text.
•
assignee – The person whom the defect is assigned to.
•
submitter – The person who detected and opened this defect.
Version 1.0
BugRep Software Design Document
Date
5.2 User Management Module 5.2.1
Component UserManagerBean Interface Description
UserManagerBean is responsible for the lifecycle management of a User. Among its responsibilities are mostly CRUD operations. •
public void createUser(String userType, UserDetails userDetails) – Creates a new user in the system and stores it into the persistent storage. The user details will be according to the given parameter that holds all required information and where the username will be the unique identifier of the User entity.
•
Public String updateUser(UserDetails userDetails) - Updates user details in the system and the persistent storage according to the input details that were retrieved from the user and passed as parameter to this method.
•
Public void createUser(String userType, UserDetails userDetails) – Creates new User details in the system according to the given user-type and user details. The user type can be a Tester or Developer which creates a different sub-class of the User class.
•
public String findAndAuthenticateUser(String username, String password) The method finds the user details according to the given username and validates that the given password is indeed the user’s password. This method is invoked through the login process and if validation fails, the user is not able to login to the system.
•
public User findUser(String username) – Method finds a given User in the system according to the unique identifier, which is the given user name.
•
public List getUserNames() – Returns all names of users defined in the system.
•
List getDevelopers() – Returns all User entity details of users of type Developer that are defined in the system. This method is invoked to retrieve the Developers drop-down list both for assigning defect to a developer and for the functionality of filtering defects according to the assigned developer.
•
List getAllUsers() – Returns details of all users defined in the system.
•
List getSubmitters() – Returns a list of all Users defined in the system except for the Admin user details. This method is invoked from the selection drop-down of the Submitters list and therefore removes the admin user from that list since this user is not a valid submitter of defects.
5.2.2
15
Component User Description
Version 1.0
BugRep Software Design Document This class represents a User in the system. It is bound to the Users database table. This is an abstract base class which contains common logic for all users of the BugRep system. The User class has the following properties: •
userName - the name by which this user is logged in
•
password – the password required for logging in
•
firstName – user’s first name
•
lastName – user’s last name
5.2.2.1 User Sub-Classes Description The BugRep application defines 2 specific sub-types of the User class: Tester and Developer. A User in the system can be either a Tester or a Developer. The user type determines the information that is stored for this object and actions that it supports. Currently, there are no specific permissions or actions available for specific users.
5.3 Domain Management Module
5.3.1
Component DomainManagerBean Interface Description
A domain in the BugRep tool is actually a new data type that is defined by a set of valid values that can be associated with it. For example, the STATUS domain is a data type that defines the valid-values ‘New’, ‘Open’, ‘Assigned’, etc. and this list of valid values is displayed to the user whenever he needs to select a Status for the defect. The DomainManagerBean class manages all actions that are required in the BugRep tool for managing the domains module, including definition of a new domain and it’s valid values and the option to delete valid values of a given domain. • public void addValueToDomain(String domainName, String domainValue) – This method is in charge of adding a new valid value to an existing domain. A new DomainValue instance is created based on the domainValue String value and it is added to the list of DomainValues of the relevant DomainInfo instance. •
16
public List getDomainValidValues(String domainName) – Method returns the list of valid values that are associated with the given Domain.
Version 1.0
BugRep Software Design Document
Date
•
public String createDomain(String domainName) – Method creates a new DomainInfo instance according to the given domainName String value. This instance is created also in the persistent storage.
•
public List getObjectDomainValues(String domainName) – Method returns a list of DomainValue instances that represent the list of valid values of the given domain (identified by the unique identifier which is the input domainName).
•
public void deleteValues(String domainName, List domainValues) – Method deletes from persistent storage the instances of DomainValue that are associated with the input domain Values.
5.3.2
Entity DomainInfo Description
The DomainInfo entity represents a single domain in the system. It is represented by a String that holds the domain name and a list of Strings that represent the list of valid values that are associated with this domain. This class is bound to the Database to table TBDOMAIN_INFO and every action performed on the instance’s attributes is automatically updated in the persistent storage. 5.3.3
Entity DomainValue Description
The DomainValue entity represents a single domain value in the system. A DomainValue consists of a single String value that holds the valid value to be displayed and used by the user.
6
Data Architecture
6.1 DEFECTS table column description
17
•
DEFECT_NUMBER – primary key for identifying defects. This field is auto generated. non-nullable.
•
TITLE – The title of the defect . non-nullable.
•
DESCRIPTION - description for the defect. non-nullable.
•
PRIORITY – defects priority . non-nullable.
•
STATUS – String representing the status of the defect non-nullable
Version 1.0
BugRep Software Design Document •
DETECTED_DATE – the date of reporting this defect.
•
COMMENT – additional description.
•
RESP_APPLICATION – The application which is responsible for this defect.
•
ASSIGNEE – the id of the defect assignee. Foreign-key for Users table.
•
SUBMITTER – the id of the defect submitter. Foreign-key for Users table.
6.2 USERS table column description: •
USERNAME - primary key for identifying users. This field is auto generated. non-nullable.
•
PASSWORD – used for user authentication.
•
FIRST_NAME – user’s first name.
•
LAST_NAME - user’s first name.
•
DTYPE – Holds the type of this user, either Developer or Tester.
•
APPLICATION – Holds the application that the user is associated with, if he is a Developer.
6.3 TBDOMAIN table column description •
DOMAIN_NAME – primary key for identifying domains. This field holds the domain name which is the unique identifier of the domains and therefore cannot be null.
6.4 DOMAIN_VALUE table column description
18
•
ID – A unique identifier, automatically generated, to this table.
•
DOMAININFO_DOMAINNAME – The association of this domain value to the domain info object. Actually this field holds the domain name that this value is associated with.
•
DOMAIN_VALUE – The actual value that this DomainValue record represents. This value will be displayed to the user when requested. Version 1.0
BugRep Software Design Document
7
Date
Interface Requirements
7.1 Required Interfaces 7.1.1
Interfacing the JSF presentation layer
The system utilizes the JSF standard for web presentation. In order to interface the web presentation layer a bean should be defined for each jsp page with relevant methods for setting / getting values to / from the beans and into the web page. For each presentable property there should be a get method which will be accessed from the jsp page. For each updateable value there should be a relevant set method accessible from the jsp page, according to java’s JSF and JavaBeans standards. The following classes are used in order to serve as the connector between the client and the server side of the BugRep application. All classes hold all the properties that are displayed to the user in the UI and stored on the relevant instances for passing on to the Server-Side methods. 7.1.2
Component DefectDetailsBean Description
The DefectDetailsBean class is responsible for the management of a Defect details in the client side: It contains all relevant properties that are displayed to the user and also stores the information that is retrieved and updated by the user. This class is a connector between the client side (that actually displays the details to the user in the UI, using JSP files) and the server side that actually handles and manages the defect details, stores or loads them to or from persistent storage (managed by DefectManagerBean class described above). This class holds attributes for all properties displayed to the user and a few management methods:
19
•
public String submit() – Submits changes to the current defect into the DB. If the defect to submit is new – a new defect is created, initialized and submitted to the database, otherwise the changed properties are merged into the defect and then submitted.
•
public String loadDefect() – reads the details corresponding to the current defect number (retrieved from the request parameters) from the database and updates this instance of DefectDetailsBean object in order for the details to be displayed to the user who requested them. Version 1.0
BugRep Software Design Document
•
7.1.3
public String resetDefect() – Resets the defect details on this instance in order to allow the user to view a clear form when he wants to create new defect details
Component FilterDefectsBean Description
The FilterDefectsBean class is responsible for the management of all filter defects actions. It captures the information regarding the filter that is required by the user and applies the relevant query on the server-side in order to retrieve the list of defects to be displayed to the user accordingly. The class defines and holds all properties that are available to the user in the UI in order for them to be stored on the relevant instance of this class and used later in the queries. The class also defines the following methods: • public List getDefects() – This is the main method of this class, that actually performs the query to the persistent storage in order to retrieve the list of defects that the user wants to see. This method builds a query in JQL (Java Query Language) that contains all the relevant conditions that were input by the user in the UI and invokes the final query to retrieve the list of defects. • public List filterDefects(String query, String assignee, String submitter) – This method performs the actual given query on the persistent storage. In addition to applying the conditions that the user selected in the UI it also adds conditions regarding the assignee and submitter of defects as object parameters to the query in order to filter the defects according to the assignee and submitter of defects, according to the user’s selection. • public String removeFilter() – Method removes the filter conditions from this instance in order for the user to view a clear form for filtering defects.
7.1.4
Component UserBean Description
The UserBean class is responsible for the management of a User details in the client side: It contains all relevant properties that are displayed to the administrator user and also stores the information that is retrieved and updated by him. This class is a connector between the client side (that actually displays the details to the user in the UI, using JSP files) and the server side that actually handles and manages the user details, stores or loads them to or from persistent storage (managed by UserManagerBean class described above). 20
Version 1.0
BugRep Software Design Document
Date
This class holds attributes for all properties displayed to the user and a few management methods: •
public String findUser() – Method looks for a specific User details according to the username that was entered by the user in the UI. The username is stored in the username attribute in this instance object.
•
public String updateUser() – Method updates the User entity with details that were input by the user in the UI. public List getUserTypes() – Method returns a list of available user Types, in order to allow the administrator user to select the type of user he wants to create. The application currently defines Tester and Developer types.
•
•
public String createUser() – This method creates new user details in the system. Actually sends all information stored on this object (input from user in UI) and invokes the relevant server method that is in charge of creation of a new User entity.
•
public String login() – Method is in charge of the login process. Sends relevant information that was input from the user to the relevant server method that are in charge of searching and validating the user details.
•
public String logout() – Method performs the logout functionality by erasing and deleting the user details that were stored in this instance and in the session objects.
•
public String clearUserInfo() – Method clears all user information that was stored in this instance in order to allow the user to view a clear form of user details when he attempts to create or update new user details
7.1.5
Component DomainBean Description
The DomainBean class handles all Domain Management operations in the client side. This class holds all relevant attributes that are input from the user through the UI in the context of Domain Management Module. It contains all relevant properties that are displayed to the administrator user and also stores the information that is retrieved and updated by him. This class is a connector between the client side (that actually displays the details to the domain in the UI, using JSP files) and the server side that actually handles and manages the domain details, stores or loads them to or from persistent storage (managed by DomainManagerBean class described above). This class holds attributes for all properties displayed to the user and a few management methods: 21
Version 1.0
BugRep Software Design Document
•
public String createDomain() – This class creates a new domain by invoking the relevant method in the server side, in the DomainManagerBean class defined above. This class passes the domain name that was stored on this instance (input by the user through UI) as parameter to the server method.
•
public List getSelectDomainValues() – This method returns a list of SelectMenu instances that represent the valid values of the selected domain in the UI. This method is used by the UI in order to display the list of valid values in a SelectManyCheckBox component.
•
public void deleteValues() – This method deletes the domain valid values that were selected by the UI by the user from persistent storage. The list of selected valid values to be removed is stored on this instance on the domainsList attribute as were selected by the user. This method invokes the server side method in DomainManagerBean as described above.
•
public String clearDomainInfo() – This method clears this instance of any data in order for the user to receive a clear Domain form when he requests to update an existing domain values.
7.1.6
Component DomainUtils Description
The DomainUtils class holds all utilities that are associated with the management of domains in the BugRep tool. This utility class is relevant for the entire application and is to be used throughout the application, in all forms and operations. Therefore, this class variables are stored in the application context, meaning they are updated a single time at the startup of the application. This class holds all methods that require retrieval of different domains information, like: •
public List getStringValidValues(String domainName) – This utility method is used to retrieve all the String valid values of a given domain.
•
public List getObjectDomainValidValues(String domainName) – This utility method is used to retrieve all the DomainValue objects that represent all valid values of a given domain.
•
public List getSelectValidValues(String domainName) – This utility method is used to retrieve all the SelectItem objects that represent all valid values of a given domain.
All methods below use the utility methods described above, but using a different domain name as a parameter. 22
Version 1.0
BugRep Software Design Document
Date
•
public List getApplications() – This method retrieves all valid values of the ‘APPLICATION’ domain and is used when ever the list of valid values of this domain are required for display.
•
public List getApplicationsForFilter() – This method retrieves all valid values of the ‘APPLICATION’ domain and adds a new empty line to this list. This method is used in the context of the Filter Defects form and therefore requires the option of having a blank values of Application domain, in order to allow the user to leave the Project filter criteria empty.
•
public List getPriorities() – This method retrieves all valid values of the ‘PRIORITY’ domain and is used when ever the list of valid values of this domain are required for display.
•
public List getPrioritiesForFilter() – This method retrieves all valid values of the ‘PRIORITY’ domain and adds a new empty line to this list. This method is used in the context of the Filter Defects form and therefore requires the option of having a blank values of Application domain, in order to allow the user to leave the Project filter criteria empty.
•
public List getAvailableStatuses () – This method retrieves all valid values of the domain ‘STATUS’ and is used in every place where this list is required.
7.1.7
External system dependencies
The system depends on a database server and an EJB3.0 compliant application server.
23
Version 1.0
BugRep Software Design Document
8
User Interface
This section will review briefly the User Interface, which in BegRep implemented as web interface. All inputs required by users are inserted via windows based inputs means (i.e. edit box, combo box etc.). In addition, user will be able to select the required action using web linked with the appropriate action labeled. Outputs will be presented generally in table format.
8.1 General Screen Captures Following you will find general screens BegRep user come upon. As for the first release, user will encounter a general screen, in which BegRep demands from its users completion of Login procedure, as depict in Figure 4.
Figure 4 - Login Screen
8.2 Defect Management Screen Captures Following you will find several screen captures relevant for BugRep defect management, this includes: listing all existing defects as depict in Figure 5. And creating / updating BugRep system with new defect details as portray in Figure 6.
24
Version 1.0
BugRep Software Design Document
Date
Figure 5 - Defect List
Defect List screen will present for each defect its relevant details (e.g. defect number, state, description).
Figure 6 - Create New Defect
Create new defect screen will enable user of updating all required defect information into BegRep database (e.g. defect submitter, owner-assignee, priority etc.) 25
Version 1.0
BugRep Software Design Document
Figure 7 – Filter Defects
Filter Defects screen allows the user to select the filter criteria in order to view a sub-set of all available defects.
8.3 User Management Screen Captures Following you will find several screen captures relevant for BugRep User Management, this includes: Create/Update a user in the system and displaying all available users in the system.
26
Version 1.0
BugRep Software Design Document
Date
Figure 8 – Create New User
Create User allows the administrator user to create a new user in the system by defining all required information..
Figure 9 – Update User Details
27
Version 1.0
BugRep Software Design Document Update User screen allows the admin user to update the details of an existing user in the system.
Figure 10 – Display Users
Display Users screen displays to the admin user all available users defined in the BugRep application.
8.4 Domain Management Screen Captures Following is the main screen that allows the administrator user to update an exiting domain in the system by adding and removing valid values of this domain.
28
Version 1.0
BugRep Software Design Document
Date
Figure 11 – Update Domain Details
8.5 Additional Screens in BugRep tool Following is the administrator page that displays all available operations that the admin user can perform in the BugRep application.
Figure 12 – Administrator Page
Note: the screen capture presented in this document are subject for change in future software releases.
29
Version 1.0
