Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

DSDP/MTJ/See Options to Handle Fragmentation

< DSDP‎ | MTJ

Back to main DSDP-MTJ Use Cases


Short description:

A Java developer is creating an application to support several devices. The system knows the differences between the target devices and can offer this information to help the developer to create the code. The system offers options from which the developer can choose which best fits to tackle a certain problem.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here
Identified|Described|Outlined|Detailed

Community Review: review_date_here


Use Case Specification: See options to handle fragmentation


1. Brief Description

A Java developer is creating an application to support several devices. The system knows the differences between the target devices and can offer this information to help the developer to create the code. The system offers options from which the developer can choose which best fits to tackle a certain problem. The system creates the full solution based on the device database, helps out to create the preprocessing code or leaves it to the user to create the solution.


2. Flow of events

2.1 Basic Flow

B1: The user chooses to see how one of the method calls where there are differences between target devices or device groups can be tackled.
B2: The system shows the available options
(1) The system offers to handle the method call by taking the values for the call from the device database during preprocessing in compilation. This is offered for the methods with suitable values. The system shows how many different versions would come out.
(2) The system offers to generate automatically preprocessing code.
(3) The user can create a solution without preprocessing.
B3: The system shows info regarding the method call and the target phones from the device database.
B4: The user chooses to handle the method
(1) By taking the values from the device database during preprocessing.
a. The system adds code which defines that the values for the method will be taken from the device database during preprocessing.
(2) By adding preprocessing code.
a. The system opens up options to add preprocessing parameters and individually defining identification for device groups and individual devices. The offered device groups are the ones in which the targeted devices belong to and individual devices are of course the target devices.
b. The user chooses preprocessing parameters he wants to add as well as the device groups or devices he wants to refer to.
c. The system checks that there are no contradictions within a preprocessing section. Several source code options do not refer to a same individual device. This is possible if device groups are use.
(3) The user can create a solution without preprocessing.
a. The user defines that the method call has been handled in relation to the differing supports between target phones.
B5: The system removes the marking that a method call has not been handled in relation to the differences between the target phones.
B6: The user chooses to close the info regarding the method call and the target phones from the device database.
B7: The system closes the info regarding the method call and the target phones from the device database.

2.2 Alternative flows

Alternative flow 1: The user adds new target devices.


3. Special Requirements


4. Preconditions

4.1 Target devices exits in the device database
The user can set as the target devices only devices existing in the device database. In case a target device is missing from the device database, the user needs to add it into the database.

4.2 Target devices have been defined
The user has defined the target devices for the project. All the target devices of the project are used as the default target phones.

4.3 The followed features have been defined
The user has defined which features such as APIs he is interested to see information about. In this way the system does not need to show information about all the differences between the target devices but only the most important information.


5. Post Conditions

5.1 Differences between target devices are known
The system has shown the differing support of the method call between the target devices.

5.2 Preferred way to handle the differences are chosen
The user has chosen based on the shown information his preferred way to handle the differences between the target devices.

5.3 Marking about differences is removed
The system has removed the marking about the differences of the target devices concerning a certain method call.


6. Extension Points



Comments:


Back to main DSDP-MTJ Use Cases

Back to the top