Requirements Iteration 3
Introduction:
This project is about the modification of the Modify the arcstudio selector component in such a way that it support parallel processing of selection so that if a lot of users come in the website they don't have to wait to get the service.
Use Cases: (Under the Use Case section)
Non- Functional Requirements:
- Do the implementation in java.
- Use the ArcStudio 3.0 for the architecture design.
- Use the Xadl architecture descriptive language
- Study bulk querry
- The main function of a selector is to pick an product line architecture in terms of Boolean guard and if its false then the selector won't output that particular architecture or otherwise it will.
- We want multithread processing of the selector.
- Modify the arcstudio selector component in such a way that it support parallel processing of selection so that if a lot of users come in the website they don't have to wait to get the service. They should get the service at the same time. You can save time to response:
Functional Requirements (Feature List):
This section will thoroughly define what the developed solution will be able to perform at the end of the development phase
Processing of sequential request through the selector
Parallel Processing of simultaneous requests
Fetching valid architecture descriptions from the repository
Filtering request constraints to abide with legislative requirement
F-01: Sequential Processing of input request
Priority: |
Essential |
Effort: |
Weeks |
Risk: |
Safe |
Functional area(s): |
Back end functionality |
Use case(s): |
UC-01 |
Description: |
Newly developed solution should maintain the ability to process input requests that come in at different times and to be processed sequentially. public or private by default |
Notes and Questions: |
Note that this feature is an existing function of the current system and performance enhancement must be the goal of the new solution to be developed. |
F-02: Parallel Processing of simultaneous requests
Priority: |
Essential |
Effort: |
Days |
Risk: |
2-Risks |
Functional area(s): |
Back end functionality |
Use case(s): |
UC-01 |
Description: |
The selector will support parallel processing of simultaneous requests. When requests come in, the selector selects the requests which are true only. In parallel processing, the selector accepts multiple user requests at the same time and then proceeds further |
Notes and Questions: |
There might be a loss of data or user requests with parallel processing of simultaneous requests. |
F-03: Filtering request constraints to abide with legislative requirement
Priority: |
Essential |
Effort: |
Weeks |
Risk: |
Safe |
Functional area(s): |
Back end functionality |
Use case(s): |
UC-01, UC-02 |
Description: |
The filtering takes into consideration countries laws, personal preference of privacy, and other factors concerning the privacy constraints Filtering process drops the Boolean guards |
Notes and Questions: |
What happens if the Boolean guards gets all selected and no privacy method is allowed to be processed |
F-04: Fetching an architecture from a repository
Priority: |
Essential |
Effort: |
Weeks |
Risk: |
Safe |
Functional area(s): |
Back end functionality |
Use case(s): |
UC-01, UC-02 |
Description: |
A set of true Boolean guards is send to the repository. A new architecture contains a set of newly-created components generated from the true Boolean guards. Then the architecture is send to the output. Precise Details:
The selector must not send any false Boolean guard to the repository. |
Notes and Questions: |
How will the repository be updated if there is a change in privacy laws? |
Design Guidelines:
- 3 Approach to take to address the efficiency issue:
- - Bottleneck Removal : The current sequential process constraints a bottleneck process in between the selector and repository component. There exist several communication processes that are unnecessary and unbeneficial to perform this particular project. Thus, its removal should fasten the speed of input processing and requesting data from the repository.
- - Parallel Processing: the process will be able to process request concurrently instead of processing each request one-by-one, based on a first-come-first-serve basis. Thus the system will allow multiple users to go through the privacy selection process simultaneously. This approach is subdivided into 2 groups of solution:
- 1. Fixed Pool: The maximum number of request that can be concurrently processed is pre-defined by a fixed number. If the number of request exceeds the fixed pool limit, the request will have to wait until there is room to process the request in the pool.
-
2. Dynamic Pool: The maximum numbers of request that can be concurrently processed is undefined and adjust the size of pool dynamically according to the need of the time. Thus, the system will be able to take any amount of request to be processed.
- - Cache: the system learns the behavior of previous request and if there happens to be an identical request that has been previously made, instead of making a brand new process altogether, the system can use the previously created process and thus saves time of creation and will make the system run in a faster mode.
- A testing GUI that will be able to show the measured result of the newly developed application compared to the sequential process
Implementation Requirements
- The main function of a selector is to select a particular architecture instance from a product line architecture that includes several optional/variant components guarded by a set of Boolean guards.
- We want multithread processing of the selector
- Master xADL & ArchStudio 3.0 & bulk querry
- The most important requirement is to present a report that tells the customer which approach under what condition is the best among other options in terms of selection performance (in time).