ADD
Authors:
Gilad Ivry
Mattan Margalith
Niv Saar
Alex Surguch
Table of Contents
1. Introduction
1.1 Vision
3
1.2 Problem Domain
4
1.3 Stakeholders
4
1.4 Software Context
5
1.5 System interfaces
7
2. Functional Requirments
8
3. Non Functional Requirments
10
4. Usage Scenarios
4.1 User profile
11
4.2 Use-Cases
12
4.3 Special usage considerations
18
5. Appendices
19
1. USE CASES:
Uses cases description
Use case ID: 1
Use case name: configure simulation properties
Primary actors: User
Description: The user will configure all the properties and input all the necessary
initial data that are needed in order to run the simulation.
Trigger: The user will ask to configure new simulation.
Pre-conditions: None
Post-conditions: The new system configuration has been saved in the DB and the
simulator is initialized with all the inserted data.
Flow of events:
1. The user chooses the amount of simulated entities that will participate in the
simulation.
2. The user chooses the general statistics for the simulated entities.
3. The user chooses how to arrange the simulated entities in the map.
4. The user chooses how the simulated entities will move on the map.
5. The user chooses the length of the simulation (number of ticks) and the
duration of each tick in hours.
6. The user configures the special events.
7. The user configures how to generate the requests.
8. The user chooses the algorithms that he wants the simulation to work with.
Alternative flows: User can return to the previous step in the wizard
Sequence Diagram:
Use case ID: 2
Use case name: run the simulation
Primary actors: User
Description: The user will activate the simulation
Trigger: User presses the run simulation button.
Pre-conditions: a configuration for the simulation has been loaded.
Post-conditions: all the data from the simulation is saved in the DB and displayed for
the user
Flow of events:
1. User presses the start simulation button.
Alternative flows: None.
Sequence Diagram:
Use case ID: 3
Use case name: pause/resume the simulation
Primary actors: User
Description: The user pause/resume the simulation
Trigger: User presses the pause/resume simulation button.
Pre-conditions: The simulation is running.
Post-conditions: The simulation stops/continues to run.
Flow of events:
1. User presses the pause simulation button.
Alternative flows: None.
Sequence Diagram:
Use case ID: 4
Use case name: end the simulation
Primary actors: User
Description: The user ask to end the simulation before the configured period of the
simulation ends
Trigger: User presses the end simulation button.
Pre-conditions: The simulation is running.
Post-conditions: The simulation moves to the summery page and displays all the
collected data
Flow of events:
1. User presses the end simulation button.
Alternative flows: None.
Sequence Diagram:
Use case ID: 5
Use case name: Show graph
Primary actors: User
Description: The user asks to show him a specific graph during the simulation or in
the summery stage.
Trigger: User presses on one of the tabs which represent a statistic expressed by
graphs.
Pre-conditions: The simulation is running.
Post-conditions: The system displays the requested graph.
Flow of events:
1. User chooses a display tab that contains some type of statistics.
2. User chooses one graph from the graphs available in this tab.
3. System displays the graph (meanwhile the simulation keeps running)
4. User closes the display of the graph.
Alternative flows: None.
Sequence Diagram:
Use case ID: 6
Use case name: select group of simulated entities.
Primary actors: User
Description: The user selects a group of simulated entities from the map.
Trigger: User marks the simulated entities with the mouse.
Pre-conditions: The simulation is running.
Post-conditions: The system displays statistical data on the selected group.
Flow of events:
1. User marks a group of simulated entities with the mouse.
2. System displays a panel with statistical data on the selected group
(meanwhile the simulation keeps running)
3. User closes the display of the panel.
Alternative flows: None.
Sequence Diagram:
Special usage considerations
The user should be familiar with the algorithms and have the knowledge of how to
configure and insert new ones according to the system constraints.
2. DATA MODEL
2.1 Description of Data Objects
Group – simulates a group of users, all of which have similar characteristics.
This class enables us to gather specific statistics over the class domain, this
object contains information about the number of the users in the group, and
the probability to request and respond to a request, etc. Each group has a
unique ID.
Event – The event data object defines a period of time, in which several
parameters are altered. The event has a time and a Location, and changes the
way that the users move and ask questions. The event is unified by a begintime and end-time with a consideration of the location.
Request – A request is a user-generated data object that is generated by a
RequestFactory in accordance to a unique statistical formula. The request is
handled by the system manager, which directs it to the appropriate users
(chosen by their location), with the aid of a selection algorithm. Each request
has a unique ID.
Reply – A reply is a user-generated data object that is generated by a the
system. Once a user is chosen by the selection algorithm and receives a
request, a probabilistic formula is applied to decide whether to reply. If so, a
reply is generated, and several parameters are updated accordingly. Each
reply is identified by the request idea and the replying user's ID.
Statistical Data – This data object contains dynamic data sets, which contains
all the data gathered during a simulation per user. This object contains the
initial statistical data for the users belonging to a specific group. This object is
initialized with X and Y parameters, which represents the probability to
request and reply to a request, and with satisfactory rate, and some other
client-defined parameters. The data is altered during the simulation run.
User – The main data object. Each user belongs to a specific group and has a
unique ID. During the simulation the user request, reply, move, and
manufacture that statistical data which we collect. The user's actions during a
specific time stamp, will affect the way that this user will act in the next time
stamp.
Map - This object is a large grid that represents the simulator's world domain,
over which the users act during the simulation.
2.2 Data Object Relationship
2.3 Data Bases:
2.3.1 ERD:
2.3.2 Relational Tables scheme
Simulation Configuration Tables:
1. Run Configuration: runID, numOfTicks, hoursPerTick,
numOfNotActiveUsers, selectionAlgo, incentivesAlgo, reqestType, spreadType,
moveType
2. Users Group: runID, groupID, numOfUsers, userPoicyType, maxTimeToReply
3. User Statistical Data: runID, groupID, satisfaction, probToAns (respondX),
probToSend (requestX), repliesLimit, requestDelta, replyDelta.
4. User Policy: runID, groupID, policyType, arg1 (L), arg2(alpha), arg3(beta
5. Request Modifier: runID, groupID, requestModifierType, arg1, arg2, arg3
6. Reply Modifier: runID, groupID, replyModifierType, arg1, arg2, arg3
7. Selection Algorithm: runID, selectionAlgoType, arg1, arg2, arg3
8. Incentives Algorithm: runID, incentivesAlgoType, arg1, arg2, arg3
9. Request Configuration: runID, requetType, arg1, arg2
10. Spread Configuration: runID, spreadType, arg1, arg2
11. Spread Locations: runID, locationID, numOfUsers, Coordinate
12. Movement Configuration: runID, moveType, arg1, arg2
13. Map Configuration: runID, topLeftCoordinate, downRightCoordinate
14. Events: runID, eventID, beginTime, endTime, coordinate, radios,
encourageRequest, encourageRequestLocation, encourageMovement
Simulation Run Tables:
1. User Locations : runID, stepNum, groupID, userID, oldCoordinate, newCoordinate
2. User Satisfaction: runID, stepNum, groupID, userID, oldSatisfaction,
newSatisfaction
3. User ProbToAns: runID, stepNum, groupID, userID, oldProbToAns, newProbToAns
4. User ProbToSend: runID, stepNum, groupID, userID, oldProbToSend,
newProbToSend
5. User Requests: runID, stepNum, requestID, requestUserID, Coordinate
6. User Replies: runID, stepNum, requestID, replyUserID, Coordinate
2.3.2 Relational Tables description
Run Configuration:
- runID: INT NOT NULL AUTO_INCREMENT – Unique primary key identifies the
simulation.
- numOfTicks: INT NOT NULL DEFAULT 1 – number of time stamps that the
simulation will run.
- hoursPerTick: INT NOT NULL DEFAULT 1 – the amount of hours each time
stamp represent.
- numOfUsers: INT NOT NULL DEFAULT 0 – total number of active users in the
simulation.
- numOfNotActiveUsers: INT NOT NULL DEFAULT 0 – total number of nonactive users in the simulation.
- selectionAlgo: VARCHAR(256) NOT NULL – the type of the selection
algorithm.
- incentivesAlgo: VARCHAR(256) NOT NULL – the type of the incentives
algorithm.
- reqestType: VARCHAR(256) NOT NULL – the type of the requests generator.
- spreadType: VARCHAR(256) NOT NULL – the type of the users spread
generator.
- moveType: VARCHAR(256) NOT NULL – the type of the users movement
generator.
Users Group:
- runID: INT NOT NULL – foreign key to the Run Configuration table.
- groupID: INT NOT NULL – primary key identifies the group.
- numOfUsers: INT NOT NULL DEFAULT 1 – number of users in the group.
- userPoicyType: VARCHAR(256) NOT NULL – type of user policy that the users
belonging to the group will use.
User Statistical Data:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- groupID: INT NOT NULL – foreign key to the Users Group table.
- satisfaction: DOUBLE NOT NULL – start satisfaction for the users in the group.
- probToAns: DOUBLE NOT NULL – start probability to answer a request for the
users in the group.
- probToSend: DOUBLE NOT NULL - start probability to send a request for the
users in the group.
- repliesLimit: INT NOT NULL – maximum number of replies for the users in the
group.
- requestDelta: INT NOT NULL – number of time stamps that the users
remembers the requests he sent.
- replyDelta: INT NOT NULL - number of time stamps that the users
remembers the replies he sent.
- maxTimeToReply: INT NOT NULL DEFAULT 1 – maximum time in hours that
the user has to replies a request.
User Policy:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- policyType: VARCHAR(256) NOT NULL - type of user policy that the users
belonging to the group will use.
- arg1: VARCHAR(256) – argument for the policy in use.
- arg2: VARCHAR(256) – argument for the policy in use.
- arg3: VARCHAR(256) – argument for the policy in use.
- arg4: VARCHAR(256) – argument for the policy in use.
Request Modifier:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- requestModifierType: VARCHAR(256) NOT NULL - type of user modifier for
outgoing requests that the users belonging to the group will use.
- arg1: VARCHAR(256) – argument for the modifier in use.
- arg2: VARCHAR(256) – argument for the modifier in use.
- arg3: VARCHAR(256) – argument for the modifier in use.
Reply Modifier:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- replyModifierType: VARCHAR(256) NOT NULL - type of user modifier for
incoming replies that the users belonging to the group will use.
- arg1: VARCHAR(256) – argument for the modifier in use.
- arg2: VARCHAR(256) – argument for the modifier in use.
- arg3: VARCHAR(256) – argument for the modifier in use.
Selection Algorithm:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- selectionAlgoType: VARCHAR(256) NOT NULL - type of the selection
algorithm that will be used in the simulation.
- arg1: VARCHAR(256) – argument for the algorithm in use.
- arg2: VARCHAR(256) – argument for the algorithm in use.
- arg3: VARCHAR(256) – argument for the algorithm in use.
Incentives Algorithm:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- IncentivesAlgoType: VARCHAR(256) NOT NULL - type of the incentives
algorithm that will be used in the simulation.
- arg1: VARCHAR(256) – argument for the algorithm in use.
- arg2: VARCHAR(256) – argument for the algorithm in use.
- arg3: VARCHAR(256) – argument for the algorithm in use.
Request Configuration:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- requetType: VARCHAR(256) NOT NULL - type of the users requests generator
that will be used in the simulation.
- arg1: VARCHAR(256) – argument for the generator in use.
- arg2: VARCHAR(256) – argument for the generator in use.
- arg3: VARCHAR(256) – argument for the generator in use.
Spread Configuration:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- spreadType: VARCHAR(256) NOT NULL - type of the users spread generator
that will be used in the simulation.
- arg1: VARCHAR(256) – argument for the generator in use.
- arg2: VARCHAR(256) – argument for the generator in use.
- arg3: VARCHAR(256) – argument for the generator in use.
Movement Configuration:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- moveType: VARCHAR(256) NOT NULL - type of the users movement
generator that will be used in the simulation.
- arg1: VARCHAR(256) – argument for the generator in use.
- arg2: VARCHAR(256) – argument for the generator in use.
- arg3: VARCHAR(256) – argument for the generator in use.
Map Configuration:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- downLeftCoordinate: VARCHAR(256) – down left coordinate of the map.
- topRightCoordinate: VARCHAR(256) – top right coordinate of the map.
Events:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- eventID: INT NOT NULL - primary key identifies the event.
- beginTime: INT NOT NULL – the beginning time of the event.
- endTime: INT NOT NULL – the ending time of the event.
- coordinate: VARCHAR(256) – the location of the event.
- radios: INT NOT NULL – the radios that the event will influence.
- encourageRequest: DOUBLE NOT NULL – the percent that will be added to
the probability to send a request.
- encourageRequestLocation: DOUBLE NOT NULL - the percent that will be
added to the probability to send a request to the location of the event.
- encourageMovement: DOUBLE NOT NULL - the percent that will be added to
the probability to move to the event location.
User Locations:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- stepNum: INT NOT NULL – primary key identifies the current time stamp.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- userID: INT NOT NULL – primary key identifies the user that changed
location.
- oldCoordinate: VARCHAR(256) – old location of the user.
- newCoordinate: VARCHAR(256) – new location of the user.
User Satisfaction:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- stepNum: INT NOT NULL – primary key identifies the current time stamp.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- userID: INT NOT NULL – primary key identifies the user that changed
satisfaction.
- oldSatisfaction: VARCHAR(256) – old satisfaction of the user.
- newSatisfaction: VARCHAR(256) – new satisfaction of the user.
User ProbToAns:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- stepNum: INT NOT NULL – primary key identifies the current time stamp.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- userID: INT NOT NULL – primary key identifies the user that changed
probability to answer a request.
- oldProbToAns: VARCHAR(256) – old probability to answer a request of the
user.
- newProbToAns: VARCHAR(256) – new probability to answer a request of the
user.
User ProbToSend:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- stepNum: INT NOT NULL – primary key identifies the current time stamp.
- groupID: INT NOT NULL - foreign key to the Users Group table.
- userID: INT NOT NULL – primary key identifies the user that changed
probability to send a request.
- oldProbToSend: VARCHAR(256) – old probability to send a request of the
user.
- newProbToSend: VARCHAR(256) – new probability to send a request of the
user.
User Requests:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- stepNum: INT NOT NULL - primary key identifies the current time stamp.
- requestID: INT NOT NULL - primary key identifies the request.
- requestUserID: INT NOT NULL – ID of the user that sent the request
- coordinate: VARCHAR(256) – location of the request.
User Replies:
- runID: INT NOT NULL - foreign key to the Run Configuration table.
- stepNum: INT NOT NULL - primary key identifies the current time stamp.
- requestID: INT NOT NULL - primary key identifies the request.
- replyUserID: INT NOT NULL - primary key identifies the user that replied the
request.
- requestUserID: INT NOT NULL – ID of the user that sent the request
- coordinate: VARCHAR(256) – location of the request.
2.3.4 Data Base main transaction
1. Save simulation configuration:
This transaction happens when the user chooses to initialize the simulation,
upon the initialization the system saves the main configuration into the 14
tables related to the system configuration as described in section 2.3.2.
Tables affected:
o Run Configuration: 1 row added.
o Users Group: the number of lines that are added equals to the
number of groups.
o User Statistical Data: the number of lines that are added equals to
the number of groups.
o User Policy: the number of lines that are added equals to the number
of groups.
o Request Modifier: the number of lines that are added equals to the
number of groups.
o Reply Modifier: the number of lines that are added equals to the
number of groups.
o Selection Algorithm: 1 row added.
o Incentives Algorithm: 1 row added.
o Request Configuration: 1 row added.
o Spread Configuration: 1 row added.
o Spread Locations: depends if the spread type is Locations, if so the
number of lines that are added equals to the number of locations.
o Movement Configuration: 1 row added.
o Map Configuration: 1 row added.
o Events: the number of lines that are added equals to the number of
events.
2. Save simulation step data:
This transaction happens at the end of every time stamp, the system saves all
the data it gathered on changes that happened to the users, all the requests
that were sent at this time stamp and all the replies that was sent this time
stamp. The data will be saved into the simulation run tables as described in
section 2.3.2.
Tables affected:
o User Locations: add rows depending on the number of users that
changed location in the current time stamp.
o User Satisfaction: add rows depending on the number of users that
changed satisfaction in the current time stamp.
o User ProbToAns: add rows depending on the number of users that
changed probability to answer a request in the current time stamp.
o User ProbToSend: add rows depending on the number of users that
changed probability to send a request in the current time stamp.
o User Requests: add rows depending on the number of requests
generated in the current time stamp.
o User Replies: add rows depending on the number of replies
generated in the current time stamp.
3. Behavioral Analysis
3.1 sequence diagrams:
use case 1: configure simulation properties.
use case 2: configure simulation properties.
use case 3: run/pause the simulation
use case 4: end the simulation.
use case 5: show graphs.
use case 6: select group of simulated entities.
3.2 Events
Because our software is a simulator, it's flow is defined prior to its
activation. Hence- there are no events to change the flow of the software.
No user input is received during the simulation, and no external event can
affect the run.
3.3 States
We have 3 states during the flow1. Configure the scenario- user inputs the properties of the simulation
(e.g. number of users, size of the map, configure groups behavior
etc.)
2. Run the simulation: in this state the simulation executes- data is
collected and stored.
3. When the simulation ends, the data is being analyzed and
manipulated to several graphs and reports, according to the user's
requests.
Configure scenario
Run simulation
Generate report
4. Object-Oriented Analysis
4.1 Class Diagrams
The classes: SelectionAlgorithmGenerator, IncentivesAlgorithmGenerator,
PathGenerator, SpreadGenerator, RequestGenerator are all abstract class that have
many implementation. Each abstract class is a main class in its own package and
more detailed explanation is given in section 4.3 (Packages).
The interface DBHandlerInt is part of the persistence layer and its implementation is
given in section 4.3 (Packages).
In this Diagram only the main classes are shown for the simplicity of it.
This diagram is showing the relations in the User class, all the users in the simulation
are held in 3 hash tables in the SystemManager class.
The classes: PolicyGenerator, RequestUserModifier, RepliyUserModifier are all
abstract class that have many implementation. Each abstract class is a main class in
its own package and more detailed explanation is given in section 4.3 (Packages).
In this Diagram only the main classes are shown for the simplicity of it.
4.2 Class Description
o SystemManager – This is the main class of the simulation that is
responsible to connect all the simulation's features into one. This class
is referred to as the main Engine and it process al the steps of the
simulation.
The main functions of this class are:
 createUsers() - Creates all the users in the simulation
according to the received user's groups. Each user assigned
the statistical and content information according to his group
and insert to the hash tables that hold all the users.
 nextStep() - The main function of the simulation, this function
is the Engine of the simulation and called on every new step in
order to run the simulation. When the function called it
evaluates all the users, applies the selection algorithm on all
the requests and saves all the gathered data to the DB. In the
evaluation part the function goes over all the users and for
each one of them determine if the user wants to send a
request in the current time stamp, answer requests from
previous time stamps (according to the user's reply delta),
receive replies from previous time stamps (according to the
user's request delta) and set new location for the user.
o SelectionAlgorithmGenerator - Abstract class that represents an
instance of selection Algorithm. The specific instance of the Selection
Algorithm is created dynamically by using class for name reflection.
The implementations of this class are responsible for selecting users
to whom the requests will be send to each one in its own way, all the
implementations classes must implement the select(...) method.
Implementations: NaiveSelection.
o PathGenerator - Abstract class that represents an instance of
movement type. The specific instance of the Movement type is
created dynamically by using class for name reflection. The
implementations of this class are responsible for moving the users to
new locations on the map each one in its own way, all the
implementations classes must implement the nextLocation(...)
method.
Implementations: StaticMovement, DBMovement,
StatisticalMovement, StatisticalPerHoursMovement.
o SpreadGenerator - Abstract class that represents an instance of
Spread type. The specific instance of the Spread type is created
dynamically by using class for name reflection. The implementations
of this class are responsible for the initial spread of the user on the
map each one in its own way, all the implementations classes must
implement the firstLocation(...) method.
Implementations: RandomSpread, UniformSpread, LocationsSpread.
o RequestGenerator - Abstract class that represent an instance of
specific Request type class generator. The specific instance of the
Request type is created dynamically by using class for name
reflection. The implementations of this class are responsible for
generating new requests for the users each one in its own way, all the
implementations classes must implement the getNextRequest(...)
method.
Implementations: RandomRequest.
o PolicyGenerator - Abstract class that represents an instance of User's
Policy. The specific instance of the User's Policy is created dynamically
by using class for name reflection. The Policy class holds the User's
requests modifier object and the User's replies modifier object for
modifying the users statistical data after he receive and answer
requests, each policy type has its own specific requests and replies
modifiers and they created automatically when the policy is created.
The implementations of this class are responsible for deciding
whether the user will send a request or answer and then change his
statistical data using the modifiers classes according to the action.
All the implementations classes must implement the antToRequest(...)
and wantToAnswer(...) methods.
Implementations: StaticPolicy, CurvePolicy.
ReplyUserModifier - Abstract class that represents an instance of
reply user modifier type. The specific instance of the reply user
modifier type is created dynamically by using class for name
reflection. This class is associated to a specific policy type and can be
used only with it. The implementations of this class are responsible
for changing the user's statistics for the replies that he provides, all
the implementations classes must implement the
modifyReplyUser(...) method.
Implementations: ReplyUserStaticReward, ReplyUserCurveReward
ReplyUserModifier - Abstract class that represents an instance of
request user modifier type. The specific instance of the request user
modifier type is created dynamically by using class for name
reflection. This class is associated to a specific policy type and can be
used only with it. The implementations of this class are responsible
for changing the user's statistics for the requests that he sends, all the
implementations classes must implement the modifyRequestUser(...)
method.
Implementations: RequestUserStaticReward,
RequestUserCurveReward.
4.3 Packages
The project is build using the layers model: GUI, Controller, Domain and
Persistence.
Packages in the Domain layer:
o Algorithms – under this package there are 2 sub-packages for 2
specific algorithm types:
 Selection – containing all the implementation of the selection
algorithm used by the simulation:

Incentives - containing all the implementation of the
incentives algorithm used by the simulation:
o Exceptions – package that holds all the exception that the Domain
classes throws.
o Infrastructure – package that holds all the data objects.
o Movement - containing all the implementation of the movement type
used by the simulation:
o Spread - containing all the implementation of the spread type used by
the simulation:
o Requests - containing all the implementation of the requests type
used by the simulation:
o User – under this package there are all the packages that responsible
for the user operation:
 Policy - containing all the implementation of the policy type
used by the simulation:

Behavior – under this package there are all the packages that
changes user behavior:
 Reply User - containing all the implementation of the
reply user modifier type used by the simulation:


Request User - containing all the implementation of the
request user modifier type used by the simulation:
Probability - containing all the implementation of the different
probability classes used by the user:
The packages in the Persistence layer:
o Exceptions – package that holds all the exception that the Persistence
classes throws.
o Infrastructure – package that holds all the data objects used by the
Persistence.
o SQL Queries – This package contains all the class that accesses the DB
using queries.
5. Software components:
We will use 3 machines- Dedicated DB server, A main server to hold the
backend and a client side computer (on which the UI will be displayed).
1. DB: We are using mySQL database to store and access the data collected.
The DB should be deployed on a designated machine that will provide
service to the core components.
2. JDBC: is used as a DAL in our persistence layer. This will be deployed on
the main server.
3. Core Domain components includes Movement Generator, Spread
Generator, Request Generator and different algorithms generators, which
are generic and loaded during the configuration wizard (or file). These
components are deployed on the main server.
4. UI Controller component: parse the data received from the domain and
generate a compact representation of the data to be displayed in the UI.
This component is also deployed on the main server.
5. UI components (includes the wizard, the simulation map and the data
charts) are written in Flex FWK, and are accessible through web access.
These are generated on the client's side, when the client access the
application.
6. User Interface draft:
Config wizard (on system startup) version 1.0
Menu panel
1. DB configuration
-user
-password
-
Next…
Config wizard (on system startup) version 1.0
Menu panel
2. Genearal
- num of non-active users
- num of ticks
- hours per tick
- expansion <to be inserted>
- revenue <to be inserted>
Next…
Config wizard (on system startup) version 1.0
Menu panel
3. Algorithms
-selection algorithm type.
- selection algorithm args.
- incentives algo. type
- incentives algo. args.
Next…
Config wizard (on system startup) version 1.0
Menu panel
4. General system config
- request generator type
- request generator params
- movement generator type
- movement generator params <optional- movement per hours>
- spread generator type
- spread generator params <optional- linked list of locations>
- map top-right coordinate
- map buttim- left coordinate
Next…
Config wizard (on system startup) version 1.0
Menu panel
5. Event configuration
- begin time <int- time stamp)
- end time
- location
- radius
- request encouragement<double>
- request location encoragement
- movement encouragement
Next…
Config wizard (on system startup) version 1.0
Menu panel
6. Event configuration
- begin time <int- time stamp)
- end time
- location
- radius
- request encouragement<double>
- request location encoragement
- movement encouragement
Next…
Config wizard (on system startup) version 1.0
Menu panel
7. User Group Configuration
- num of users
- policy type
-policy type args
-modify requester params <double>
-modify replier params <double>
- max time to reply
- group statistical data <dialog>
- satisfaction
- probability to answer(respond X)
- probability to send (Request X)
- replies limit
- request delta
- reply delta
Next…
Simulation view, version 1.0
Menu panel
Reports
center
Event
manager
Algorithm
loader
Button 4
- TBA
Button n
TBA
Information
pane
MAP
TimeLine
Charts view, version 1.0
Menu panel
After the simulation finished
This screen will display the statistics gathered and will generate reports
TimeLine
7. Non-functional requirements Testing:
Performance constraints:
-
Speed, Capacity & Throughput:
 The application must launch in less than 2 minutes.
o We intend to run a torture test with the highest level of detail
and data (1 million users, and a probability of 0.95 to send a
request per user each time stamp- high activity)
 Each transaction of the system (time stamp) should be processed
under 4 minutes (with the assumption that the system has no more
than 1,000,000 users), and the display of the GUI should refresh
during this period of time.
o We will test this manually.
-
Reliability:
 This system will remain online at all times. The system will be able to
recover from data crashes and restore the data of previous runs from
the DB.
o Torture tests are designed in order to bring the system to the
limit, and since data is stored every time-stamp, recovering
will be supported.
-
Safety & Security:
 The system's code will be protected by the server that it is loaded on.
o The simulator does not require any permissions or security
levels, thus it excuses us from testing that aspect.
-
Portability:
 The application will run on a Microsoft Windows operation system
and will be operable for Explorer and Firefox browsers only.
o We intend to use these browsers during the manual sanity
tests.
-
Usability:
 Extensive learning of the software use will be difficult and is suited to
expert users only (knowledge of the algorithms, probabilities and
etc.).
 For novice users, a setup wizard will be provided, which enables a
quick and simple definition of the simulation.
o We intend to ask the client to use the product first without
any tutoring, to receive feedbacks on it's usability.
-
Acceptance testing: our client will write and execute his acceptance tests
prior to the products submission.
-
Mid-process testing: so far, we embedded several tests to see that the
simulation behaves as anticipated, and the results were satisfying. (e.g.
the spread, and user's activity, satisfaction and movement, etc.)
8. Task List
1. Task ID: 1
Title: create DBRequest class.
Est Starting Date: 3/4
Actual Starting Date:
Est Finish Date: 10/4
Actual Finish Date:
Description: create implementation for the RequestGenerator that
will be able to get stored requests from the DB and generate them to
the users.
See sub-tasks:
Superceded by tasks:
2. Task ID: 2
Title: create DBMovement class.
Est Starting Date: 3/4
Actual Starting Date:
Est Finish Date: 10/4
Actual Finish Date:
Description: create implementation for the PathGenerator that will be
able to get stored locations from the DB and generate them to the
users.
See sub-tasks:
Superceded by tasks:
3. Task ID: 3
Title: MIT movement conversion
Est Starting Date: 10/4
Actual Starting Date:
Est Finish Date: 17/4
Actual Finish Date:
Description: convert the DB of movement from MIT to fit the DB of
the simulation.
See sub-tasks:
Superceded by tasks: 2
4. Task ID: 4
Title: store statistical data from GUI graphs
Est Starting Date: 1/5
Actual Starting Date:
Est Finish Date: 8/5
Actual Finish Date:
Description: create tables to store statistical data from the GUI graphs
and write functions to store it.
See sub-tasks:
Superceded by tasks: creation of the GUI
5. Task ID: 5
Title: run configuration file multiple times.
Est Starting Date: 17/4
Actual Starting Date:
Est Finish Date: 24/4
Actual Finish Date:
Description: enable the simulator to run the same configuration file
multiple times.
See sub-tasks:
Superceded by tasks:
6. Task ID: 6
Title: run batch of configuration files.
Est Starting Date: 17/4
Actual Starting Date:
Est Finish Date: 24/4
Actual Finish Date:
Description: enable the simulator to run a pre-configured batch of
configuration files multiple times.
See sub-tasks:
Superceded by tasks:
7. Task ID: 7
Title: add incomings calculations.
Est Starting Date: 24/4
Actual Starting Date:
Est Finish Date: 1/5
Actual Finish Date:
Description: add the simulator the ability to calculate profits from the
system.
See sub-tasks:
Superceded by tasks: depends if we will receive the proper
specification.
8. Task ID: 8
Title: add user's propagation.
Est Starting Date: 24/4
Actual Starting Date:
Est Finish Date: 1/5
Actual Finish Date:
Description: add the ability for users to propagate the system to other
non active users.
See sub-tasks:
Superceded by tasks: depends if we will receive the proper
specification.