CIS 544 Advanced Software Design and Development Project Management System Oreoluwa Alebiosu
Contents 1. Requirements... 4 1.1. Use Case Diagram... 4 1.2. Use Case s and Sequence Diagrams... 5 1.2.1. Login... 5 1.2.2. Adding a new programming unit... 6 1.2.3 Editing programming unit data... 7 1.2.4 Deleting programming unit data... 8 1.2.5 Listing project data sorted by programmer name... 9 1.2.6 Listing project data sorted by primary requirement id... 10 1.2.7 Displaying all information about a selected program unit... 11 1.2.8 Statistics on the level of development for all programming units... 12 1.2.9 Quit program... 13 1.3. Domain Analysis Model... 13 2. Architecture... 14 2.1. Component Diagram... 14 2.1.1. Interfaces... 16 3. Mid-Level Design... 21 3.1. Diagram: Model... 21 3.2. Diagram: Presenter... 23 3.3. Diagram: View... 24 3.4. State Diagrams... 25 3.4.1. State diagram: UserManager User status... 25 3.4.2. State diagram: DatabaseManager Database status... 26 4. Low-Level Design... 27 4.1. Presenter... 27 4.1.1. UserManager... 28 4.1.2. SystemManager... 28 4.2. View... 31 4.2.1.1. UserInterface... 31
4.3. Model... 33 4.2.2. ModelController... 33 4.2.3. User... 35 4.2.4. ProgrammingUnit... 36 5. Translation of design to Code... 37 6. Screenshots of the System... 39 6.1. Login screen... 39 6.2. User Logged in-main Menu... 39 6.3. Manager Logged in- Main Menu... 40 7. Conclusion... 40
1. Requirements 1.1. Use Case Diagram
1.2. Use Case s and Sequence Diagrams 1.2.1. Login Name: Login Actors: User Stakeholders and Needs: User Log into the system and view the appropriate menu. Preconditions: The User has the program running and has a valid username and password. Postconditions: The User successfully logs into the system and views the main menu. Trigger: The user runs the program. Basic Flow: 1. The system requests for a username and password. 2. User enters password. 3. The system confirms validity of username and password then loads the data to the system. 4. System displays the appropriate main menu for either the user. Extensions: *a User cancels the operation: The use case ends. 1a The program fails to load the required data: 1a1. The System displays a notice of failure to load data to User. 2a User enters invalid password: 2a1. The Systems displays to the user that an invalid password was entered and asks the user to try again.
1.2.2. Adding a new programming unit Name: Adding a new programming unit Actors: Manager Stakeholders and Needs: Managers Log into the system, view the appropriate menu, and add a new programming unit to existing list of programming units. Preconditions: The Manager has successfully logged into the system and is currently viewing the main menu options. Postconditions: A new programming unit has been locally stored by the system. Trigger: The Manager selects the Add a new programming unit from the option menu. Basic Flow: 1. The system asks the Manager for: o Unit name o Unit type (package or class)
o Assigned programmer o Development status design, implementation, coding, testing o Current version o Associated requirements document o Specific requirement ID within that document 2. The system stores the data entered. 3. The system displays that the data has been successfully stored. Extensions: *a Manager cancels the operation: The use case ends. 1a The Manager enters a requirement ID that already exists in the system: 1a1. The System informs the Manager and requests for another requirement ID. 2a The Manager enters an invalid option for any of the attributes of the programming unit: 2a1. The System informs the Manager why it is invalid and requests that the data be reentered. 1.2.3 Editing programming unit data Name: Editing programming unit data Actors: Manager Stakeholders and Needs: Managers Edit a programming unit and locally store it in the system. Preconditions: The Manager has successfully logged into the system and is currently viewing the main menu options. Postconditions: A selected programming unit has been edited and locally stored by the system.
Trigger: The Manager selects the Edit a programming unit from the option menu. Basic Flow: 1. The system displays all currently existing programming units. 2. The system asks the Manager for the programming unit s requirement ID. 3. The Manager enters the programming unit s requirement ID. 4. The system ask the user to select which attribute of the programming unit that is to be edited. 5. The Manager selects the attribute and enters the data for that attribute. 6. The systems overwrites the edited programming unit attribute s data with the newly entered one. Extensions: *The Manager cancels the operation: The use case ends. 1a The Manager enters an invalid requirement ID (doesn t exist in the system): 1a1. The System informs the Manager and requests for an existing requirement ID. 2a. The Manager selects an invalid attribute: 2a1. The System informs the Manager and requests for a valid attribute to be edited. 3a The Manager enters an invalid option for any of the attributes of the programming unit: 3a1. The System informs the Manager why it is invalid and requests that the data be reentered. 1.2.4 Deleting programming unit data Name: Deleting programming unit data Actors: Manager Stakeholders and Needs:
Managers Delete a new programming unit from the system. Preconditions: The Manager has successfully logged into the system and is currently viewing the main menu options. Postconditions: A programming unit has been deleted from the system. Trigger: The Manager selects the Delete a new programming unit from the option menu. Basic Flow: 1. The system displays all currently existing programming units. 2. The system asks the Manager for the requirement ID of the programming unit to be deleted. 3. The system deletes the selected programming unit. Extensions: *The Manager cancels the operation: The use case ends. 1a The Manager enters an invalid requirement ID (doesn t exist in the system): 1a1. The System informs the Manager and requests for an existing requirement ID. 1.2.5 Listing project data sorted by programmer name Name: Listing project data sorted by programmer name Actors: User Stakeholders and Needs: Users View a list of project data sorted by programmer name. Preconditions: The User has successfully logged into the system and is currently viewing the main menu options. Postconditions: The System displays the list of project data sorted by programmer name. Trigger: The User selects the List of project data sorted by programmer name menu option.
Basic Flow: 1. The system displays all currently existing programming units sorted by programmer name. Extensions: 1a The User selects an invalid menu option: 1a1. The System informs the User and requests for valid option. 1.2.6 Listing project data sorted by primary requirement id Name: Listing project data sorted by primary requirement id Actors: User Stakeholders and Needs: Users View a list of project data sorted by primary requirement id.
Preconditions: The User has successfully logged into the system and is currently viewing the main menu options. Postconditions: The System displays the list of project data sorted by primary requirement id. Trigger: The User selects the List of project data sorted by primary requirement id menu option. Basic Flow: 1. The system displays all currently existing programming units sorted by primary requirement id. Extensions: 1a The User selects an invalid menu option: 1a1. The System informs the User and requests for valid option. 1.2.7 Displaying all information about a selected program unit Name: Displaying all information about a selected program unit Actors: User Stakeholders and Needs: Users View all information about a selected program unit. Preconditions: The User has successfully logged into the system and is currently viewing the main menu options. Postconditions: The System displays all information about a selected program unit. Trigger: The User selects the Display information on a selected program unit from the option menu. Basic Flow:
1. The User selects a program unit from the list of program unit listed. 2. The system displays all information about the selected program unit. Extensions: *The User cancels the operation: The use case ends. 1a The User enters an invalid program unit from the option: 1a1. The System informs the User and requests for valid option. 1.2.8 Statistics on the level of development for all programming units Name: Statistics on the level of development for all programming units Actors: User Stakeholders and Needs: Users View statistics on the level of development for all programming units. Preconditions: The User has successfully logged into the system and is currently viewing the main menu options. Postconditions: The System displays statistics on the level of development for all programming units. Trigger: The User selects the Display statistics for all programming units from the option menu. Basic Flow: 1. The system displays statistics for all programming units. Extensions: 1a The User enters an invalid option from the main menu: 1a1. The System informs the User and requests for valid option.
1.2.9 Quit program Name: Quit program Actors: User Stakeholders and Needs: Users Successfully saves data and exit the program. Preconditions: The User has successfully logged into the system and is currently viewing the main menu options. Postconditions: The System saves the data into a csv file then exits successfully. Trigger: The User selects Quit from the option menu. Basic Flow: 1. The system saves the data to a csv file. 2. The system quits and exits successfully. Extensions: None 1.3. Domain Analysis Model The above provides an abstracted domain model whereby the programming unit and users are independent.
2. Architecture 2.1. Component Diagram Initially, I decided to make use of the above architectural design. The component diagram was designed based on the functional attributes of the PMS. I summarized and illustrated the requirements as: 1. Loading the data at startup 2. Modifying the programming units by only the manager which included adding, deleting, or editing any unit 3. Displaying a project or programming unit by any user 4. Provide a user interface to perform any of these functions The user can interact with the programming unit data through the Modify Programming Units Data component or the Display Programming Units component. Users are able to read and write
to the data stored through the interface provided by the Datastore component. The connector between Display and Modify programming unit illustrates that we update the Programming units immediately so it can viewed by using the Display programming unit component. However, below is my choice of component diagram to use in the project: I think the most reasonable approach to design the architecture of the PMS is by using the Model-View-Presenter style. The model is an interface defining the programming unit data to be displayed or otherwise modified by the user. The model holds on to both the programming unit data and user data. The view displays data (the model) and routes user commands (events) to the presenter to act upon to both the programming unit data and user data.
The presenter acts upon the model and the view. It retrieves data from the model, and formats it for display in the view. The presenter essentially gives the user the ability to modify programming units and display them. 2.1.1. Interfaces 2.1.1.1. IModel public void savedatabase() Precondition: none, if no user data or programming unit data is in our system Postcondition: verifies the data and saves it to the file Purpose: to save the data to the file public void loaddatabase() Precondition: csv data file available for loading Postcondition: loads the data from the file and loads users from the file userfile. The data is verified. Purpose: to load data from file to system public LinkedList<ProgrammingUnit> getprogrammingunits() Precondtion: none Postcondition: returns programming units saved in memory Purpose: to access the programming units to other classes
public LinkedList<User> getusers() Precondtion: none Postcondition: returns users saved in memory Purpose: to access the users to other classes public void createprogrammingunit(string name, String type, Enum version, Enum status, String programmer, String reqdoc, String reqid) Precondition: none of the parameters above is null Postcondition: creates a new unit with a unique requirement id Purpose: to create new programming unit and possibly add it to existing list of programming units public void deleteprogrammingunit(programmingunit unit) Precondition: unit not null Postcondition: removes programming unit with id from the list of programming units Purpose: to delete programming unit from existing list of programming units public void addprogrammingunit(programmingunit unit) Precondition: unit not null Postcondition: adds the programming unit to the list of existing programming units Purpose: to add the programming unit to the list of existing programming units
2.1.1.2 IPresenter public User login(string username, String password) Precondition: input characters are not null Postcondition: if a such a user exists in memory, it returns User that has the same password and username, if not it returns null Purpose: to perform the login operation public void savedatabase() Precondition: none, if no user data or programming unit data is in our system Postcondition: verifies the data and saves it to the file Purpose: to save the data to the file public void loaddatabase() Precondition: csv data file available for loading Postcondition: loads the data from the file and loads users from the file userfile. The data is verified. Purpose: to load data from file to system public void sortbyprogrammername() Precondition: LinkedList<ProgrammingUnit> exists
Postcondition: sorts the LinkedList<ProgrammingUnit> by programmer name from each programming unit Purpose: to sort programming units by programmer name public void sortbyprimaryreq() Precondition: LinkedList<ProgrammingUnit> exists Postcondition: sorts the LinkedList<ProgrammingUnit> by primary requirements from each programming unit Purpose: to sort programming units by primary requirements public LinkedList<ProgrammingUnit> getallprogrammingunits() Precondition: none Postcondition: returns all the programming units Purpose: to obtain all programming units public ProgrammingUnit ProgrammingUnit(String id) Precondition: id not null Postcondition: returns programming unit with specified id Purpose: to obtain programming unit with specified id public String programmingunitstatistics() Precondition: none Postcondition: performs statistical analysis and returns a string containing details of the results of the analysis performed Purpose: to perform and view the statistical analysis results of all programming units public void deleteprogrammingunit(string id)
Precondition: id not null Postcondition: removes programming unit with id from the list of programming units Purpose: to delete programming unit from existing list of programming units public void editprogrammingunit(string name, String type, Enum version, Enum status, String programmer, String reqdoc, String reqid) Precondition: none of the parameters above is null Postcondition: edits and saves programming unit with id in the list of programming units Purpose: to modify or edit the programming unit data with specified id public void addprogrammingunit(string name, String type, Enum version, Enum status, String programmer, String reqdoc, String reqid) Precondition: none of the parameters above is null Postcondition: adds the programming unit to the list of existing programming units Purpose: to add the programming unit to the list of existing programming units
3. Mid-Level Design 3.1. Diagram: Model
Model controller maintains a list of users and programming units which is obtained from the database. The model controller loads and saves the database as requested. In addition, it parses through the local input file to extract information for all programming unit.
3.2. Diagram: Presenter
A simple Façade pattern is utilized above. The SystemManager has an association to the UserManager component. The UserManager helps reduce the tasks of the SystemManager by providing user management services to the SystemManager. SystemManager is, thereby, able to invoke any necessary operation in the UserManager. The SystemManager inherits from the IPresenter Interface. Before implementing any method in the IPresenter interface, the System checks to see if the user is logged in as a manager by using the Boolean attribute in the User class. The SystemManager receives and input from the view (UserInterface) and processes the input then presents the result back to the view. 3.3. Diagram: View
For the user interaction (or view), I only require the UserInterface to have a relationship with IPresenter so as to invoke the SystemManager to begin the system and load the database. In addition, when the user makes an input, the UserInterface invokes the SystemManager to process the input, through the ProcessInput function that contains the necessary logic that calls all other application logic to process each of the users input. 3.4. State Diagrams 3.4.1. State diagram: UserManager User status The user is not logged in. He provides the logging information and according to that, he becomes Logged in as Manager or Logged in as User or Not Logged in.
3.4.2. State diagram: DatabaseManager Database status First, the database is not loaded. Once a user successfully logs in, then the database is loaded. The user is able to make changes that would result to saving these changes to the database.
4. Low-Level Design 4.1. Presenter
4.1.1. UserManager The UserManager class is used to maintain the operation with users. It acts as a component that is used similarly to the SystemManager, however, its purpose is to maintain the operations with users. public User login(string username, String password) UserManager If a user with the provided parameters exists within our system, the login function updates the isuserloggedin attribute to true, and if the user that is logged in is a manager then ismanagerloggedin is set to true and currentuser is set to the user that is logged in. 4.1.2. SystemManager The SystemManager class is used to maintain the operations and application logic in the program. In addition, it maintains the UserManager. A simple Façade pattern is utilized by the SystemManager as it defines a higher level interface that allows the subsystem to be used. The SystemManager inherits IPresenter, so it acts as the major component for our presenter in our system. The view provides the SystemManager with an input and the SystemManager processes this input with its application logic then provides the view with its results. public User login(string username, String password) SystemManager The SystemManager invokes the UserManager for all user related operations. If such a user exists within the UserManager the login function updates the isuserloggedin attribute to true, and if the user that is logged in is a manager then ismanagerloggedin is set to true and currentuser is set to the user that is logged in. public static SystemManager Create() SystemManager
The SystemManager uses the Create function to return the instance of its self. A Singleton design pattern was used during this approach, therefore, I did not have to create a constructor for the SystemManager class. public void savedatabase() SystemManager The SystemManager utilizes the IModel interface for this operation. Therefore, within the IModel interface, the savedatabase operation is performed. public void loaddatabase() SystemManager The SystemManager utilizes the IModel interface for this operation. Therefore, within the IModel interface, the loaddatabase operation is performed. public void sortbyprogrammername() SystemManager SystemManager sorts programming unit data based on programmer name. public void sortbyprimaryreq() SystemManager SystemManager sorts programming unit data based on primary requirement. public void editprogrammingunit(string name, String type, Enum version, Enum status, String programmer, String reqdoc, String reqid) SystemManager
The SystemManager uses the provided information in the parameters and then edits and saves programming unit with the provided id in the list of programming units. During this process, it invokes the database to perform the edit programming unit operation. public void addprogrammingunit(string name, String type, Enum version, Enum status, String programmer, String reqdoc, String reqid) SystemManager The SystemManager uses the provided information in the parameters and creates then add a programming unit with the provided id to the list of programming units. During this process, it invokes the database to perform the add programming unit operation. public void deleteprogrammingunit(string id) SystemManager The SystemManager removes programming unit with id from the list of programming units. During this process, it invokes the database to perform the delete programming unit operation. public String programmingunitstatistics() SystemManager The SystemManager counts the occurrence of the different Enum Status and returns a string containing the information retrieved. public void ProcessInput(string input, User usr, UserInterface ui) SystemManager ProcessInput is a very logic based function that is invoked by the UserInterface. The function receives a user input and, based on this input, it performs an operation. In addition, it receives the User class to make sure the right type of users perform selected operations. During this process, the SystemManager invokes all its necessary functions to provide a result for the user.
public ProgrammingUnit FindProgrammingUnit(string id) SystemManager The SystemManager finds the programming unit with the specified id in the list of programming units. During this process, it invokes the database to perform the find programming unit operation. 4.2. View 4.2.1.1. UserInterface The UserInterface class is used to display the Login and Main Menu. It is also used to provide the SystemManager with the user s input and then display the results returned by the SystemManager public void login() UserInterface The Login function displays the login menu and uses the SystemManager to check if the user is valid.
public void DisplayMainMenu(User usr) UserInterface The DisplayMainMenu function displays a menu based on if the User is a manager or not. The DisplayMainMenu function receives an input and invokes the SystemManager to process the input. public void DisplayOutput(String output) UserInterface The DisplayOutput function simply displays the result returned by the SystemManager. public UserInterface() UserInterface The constructor is used to create an instance of the SystemManager and display the login menu.
4.3. Model 4.2.2. ModelController The ModelController is used to get the ProgrammingUnit and User data. In addition, it is used to save the list of ProgrammingUnit back to the Project Management System s programming unit file. Finally, the ModelController is invoked by the SystemManager to perform database
operations such as add, delete, and create programming units. It can also be used to find a specified programming unit. The Uppercasefirst function is a helper function used to simply make the first letter in a string uppercase. public void savedatabase() throws FileNotFound Exception, ReadingError Exception ModelController The ModelController loads the file PMSDatabase.csv and UserDatabase.csv located at the Project Management System\Project Management System\bin\Debug folder in the project. If the files are unavailable or cannot be read (or contains a wrong format), the function throws an exception. Once the function reads each data for a programming unit and user, the function adds a new programming unit and/or user to its relevant list. public void loaddatabase() throws FileNotFound Exception ModelController The ModelController loads the file PMSDatabase.csv to the Project Management System\Project Management System\bin\Debug folder in the project. If the files are unavailable, the function throws an exception. It adds every programming unit data in the list of programming units to the file in the format the file was read. public void addprogrammingunit(programmingunit unit) ModelController The ModelController uses the provided information in the parameters and then creates the programming unit to ModelController s list of programming units. public ProgrammingUnit createprogrammingunit(string name, String type, Enum version, Enum status, String programmer, String reqdoc, String reqid) ModelController
The ModelController uses the provided information in the parameters and to create a ProgrammingUnit, then returns the programming unit. public void deleteprogrammingunit(programmingunit unit) ModelController The ModelController uses the provided information in the parameters and then deletes the programming unit from the ModelController s list of programming units. public ProgrammingUnit FindProgrammingUnit(string id) ModelController The ModelController finds the programming unit with the specified id in the list of programming units, then returns the programming unit. public static ModelController Create() ModelController The ModelController uses the Create function to return the instance of its self. A Singleton design pattern was used during this approach, therefore, I did not have to create a constructor for the ModelController class. public String Uppercasefirst(string str) ModelController The ModelController uses Uppercasefirst as a helper function when parsing the data file in the loaddatabase function. The function returns a string with its first letter in uppercase form. 4.2.3. User The User class is used to represent a user. It is used by the ModelController and UserManager, by the SystemManager, to perform user related operations.
public bool VerifyUser(string password) User The User uses the VerifyUser function to confirm the password for the current user is correct. It then sets the ismanager attribute to true if the User is a Manager. public User(string username, string password) User The User constructor is used to initialize a new User with its parameters. 4.2.4. ProgrammingUnit The ProgrammingUnit class is used to represent a programming unit. It is used by the ModelController and SystemManager in different operations. public ProgrammingUnit (string username, string password) ProgrammingUnit The ProgrammingUnit constructor is used to initialize a new ProgrammingUnitwith its parameters.
5. Translation of design to Code I initially had a UserManager, ModelManager, and ProgrammingUnitManager in the IPresenter interface. After, translating to code, I noticed a lot of code duplication and ambiguity between my SystemManager and the other three (UserManager, ModelManager, and ProgrammingUnitManager). My basic idea was that the SystemManager is a major component and the other three managers is a subsystem that the SystemManager can invoke when given a selected input. I was thereby trying to utilize the façade pattern in this process. After implementing this. I noticed a lot of duplication in the operations of the SystemManager and the other three (UserManager, ModelManager, and ProgrammingUnitManager). Therefore, I removed the ModelManager and ProgrammingUnitManager from my system, although they are still available in the folder that contains files used in the project. The SystemManager now interacts directly with the IModel Interface without invoking the ModelManager and ProgrammingUnitManager. I retained the UserManager because of how distinct its operations are. Therefore, although it is invoked by the SystemManager, it is still a very distinct component within my IPresenter interface. The UserManager helps reduce the tasks of the SystemManager by providing user management services to the SystemManager. The user login process is very intuitive, as the SystemManager can invoke the UserManager to perform any necessary user operation. I, however, created and loaded the list of users by using the UserDatabase.csv file. The file contains a user s username and password, and an indication of if the user is a manager or not a manager.
I used the Visual Paradigm software to generate a backbone code for my program. I chose to use C#, as it is my most preferred programming language and I am very familiar with Visual Studio. The translations of the associations were straightforward. In addition, the multiplicities within the associations were well taken care of by Visual Paradigm, so I didn t have to make any major changes with the multiplicities in my diagram. A major difference in my diagram when compared to my code is that within my diagram I represented my data on a list using LinkedList. However, in my code I used the C# List data structure. The reason for this is because I am very familiar with C# s List data structure and it is a very effective representation of my programming units and user data. Finally, I used the Generate to Diagram tool in Visual Studio to develop a class diagram of all the attributes and operations I added. I then compared the class diagram generated to my initial diagram developed on Visual Paradigm and they were essentially the exact same diagram.
6. Screenshots of the System 6.1. Login screen 6.2. User Logged in-main Menu
6.3. Manager Logged in- Main Menu 7. Conclusion All requirements were met in the final system. I enjoyed working on the project and gained a lot of technical skills when it comes to software design and development. While designing the architecture, I used the Singleton design pattern and a very simple Façade pattern. Furthermore, I used the Model-View-Presenter architectural style. For implementation, I used C# on Visual Studio 2012 and a simple List for my data structure while running the program.