CSI3303 Component-Based Software Engineering

moodusroundoSoftware and s/w Development

Aug 15, 2012 (5 years and 1 day ago)

215 views

CSI3303
Component
-
Based
Software
Engineering







A s s i g n m e n t: 1

3/3 1/2 0 1 1

GUI ARCHITECTURE
Version 7.0

Our GUI Group is hired to build a GUI of a simulation
system. This
simulation system is a Multi
-
agent system
(MAS) with the java component libraries. Logic systems,
military strategy, artificial intelligence and gaming
simulation source of information are used to build whole
system.

P r e p a r e d B y G U I T e a m


V i p u l


A m a n d


A n i


N o v i t a


K e i t h


N o v i t a


P a g e

|
1


Modification History

Who

Change
Description

Version

When

Vipul

Background
Information

1.01

17/3/2011

Amanda

Change to gui and
collaboration

1.0

24/3/2011

Novita, Ani

Problem Statement

2.0

24/3/2011

Vipul, Amanda,
Ani, Novita, Keith,
Novita

Function
Requirement and Non
Functional
Requirement

2.01

24/3/2011

Vipul

Documents Format

2.02

24/3/2011

Vipul

Add plan Details

3.0

24/3/2011

Amanda

Change Screen shots

3.01

27/3/2011

Pradeep, Keith,
Vipul,
Amanda, Ani,
Novita

Use Case Diagram,
Class Diagram

4.01

27/3/2011

Pradeep, Keith,
Vipul, Amanda, Ani,
Novita

Add function
requirements

5.01

31/3/2011

Vipul

Compact the
all
works

6.01

31/3/2011

Amanda
, Vipul

Re
Compact the
details

6.02

31/3/2011

Vipul,

Amanda,
Ani, Novita, Novita
,

Keith

Add Learning Out
comes

6.03

31/3/2011

Vipul, Amanda, Ani,
Novita, Novita
,
Keith

Compact and Format
the Submission
Document

7.0

31/3/2011


Distribution List

Who

What (
H
ard/
S
oft)
Copy

Version

When

Amanda Roberts

Soft



Anirudh Menon

Soft



Keith Oliver Ancajas

Soft



Novita Tjiauw

Soft



Pradeep Gurung

Soft



Vipul Patel

Soft



Dr. Mike Johnstone

Soft



All Remaining
Teams

Soft





P a g e

|
2


Contents

Modification
History

................................
................................
................................
.........................

1

Distribution List

................................
................................
................................
................................

1

Introduction

................................
................................
................................
................................
......

2

Purpose

................................
................................
................................
................................
.............

3

Team Overview

................................
................................
................................
................................
.

3

Artificial Intelligence:

................................
................................
................................
....................

3

Problems

................................
................................
................................
................................
..

3

Terrain:

................................
................................
................................
................................
.........

4

Problems

................................
................................
................................
................................
..

4

Functions

................................
................................
................................
................................
..

4

GUI:

................................
................................
................................
................................
...............

4

Problems

................................
................................
................................
................................
...

4

Functions

................................
................................
................................
................................
..

4

Sensor:

................................
................................
................................
................................
..........

4

Pr
oblems

................................
................................
................................
................................
...

4

Elicited Functional Requirements

................................
................................
................................
.....

5

Functional Requirements:

................................
................................
................................
............

5

Poss
ible future requirements

................................
................................
................................
.......

5

Non Functional Requirements

................................
................................
................................
......

6

Assumptions:

................................
................................
................................
................................
....

6

Problem Analysis

................................
................................
................................
..............................

6

Requirements and Analysis Workflow

................................
................................
.............................

7

Use Case Scenario
................................
................................
................................
.........................

8

GUI Class Diagram

................................
................................
................................
........................

9

Interface design

................................
................................
................................
............................

9

Main

................................
................................
................................
................................
..........

9

Settings

................................
................................
................................
................................
...

10

WBS

................................
................................
................................
................................
................

11

Gantt chart

................................
................................
................................
................................
.....

12

Learning Out comes

................................
................................
................................
........................

13

References

................................
................................
................................
................................
......

13




Introduction

P a g e

|
3


Our GUI Group is hired to build a GUI of a simulation system. This simulation system is a Multi
-
agent system (MAS) with the java component libraries. Logic systems, military strategy, artificial
intelligence and gaming simulation source of information are

used to build whole system.

In the System there are two teams, one is Blue team and second is Red team. Blue team agents
find the specified objects and Red team agents defence them. The decisions and Memory skills is
depend on the Artificial Intelligent
part. The Terrain part covers location and its information of
objects and agents of both teams.

Purpose

This document forms part of a larger document that defines the System Architecture of the
software project. The main purpose of this document is to
define the Graphical User Interface aspect
of the System Architecture.

Our company has been asked to develop a virtual simulation by a client. This simulation will
display two
teams (
a red and blue team) trying to capture or defend an objective. In the sim
ulation
two teams called blue and red will be controlled by an artificial intelligence. The only condition set
by the client toward the development of this product is that it must be programmed in Java on a
netbeans IDE Windows platform. Of course a projec
t of this size will naturally be divided into
components in order to prevent any
confusion

on where to start and each component is named as
follows:

1.

Artificial Intelligence

2.

Terrain

3.

GUI

4.

Sensor

The project team will be divided into five teams to work on each

component of the simulation.
Of course that also means the problems relating to the simulation’s development will also be divided
amongst the components and teams and given below is an overview of the roles and possible
problems the teams will face with
each component.

Team Overview

Artificial Intelligence:

Two teams will be delegated to the Artificial Intelligence component due to the complexities
involved with the AI. This component entails creation of artificial intelligence. The artificial
intelligenc
e component is divided into two parts. These two parts are the memory skills and the
decision making skills.

Problems

How much memory will the AI hold when it comes to understanding strategic motions and
certainty factors
i.e.

what strategies will it imple
ment when placed in a scenario and will it check if
an obstacle placement or team placement on a certain tile is still true or false. What actions will it
take when it encounters a member(s) of the opposing
team?

Will there be collision detection?

Function
s


Memory skills

1.

Pre
-
set strategies for circumventing obstacles whether static or moving

2.

Tile placement of obstacles so blue team of the AI may remember an object being on a tile
from a previous simulation and may keep a log of it.

P a g e

|
4


Functions


Decision
making

skills

1.

What functions the blue team will perform if it comes across a red team member.

2.

How to adapt to changes when it comes to randomized placement of objects.


Terrain:

A team will be delegated to the terrain component. The terrain component cover
s lay of
the land or terrain
, co
-
ordinates of objects within the scenario, movement logs of the team
members and the randomized object placements.

Problems

Is there going to be a maximum number of
objects

will be put in the map. How the
surface of the terr
ain is going to be.

Functions

It provides a basic map with co
-
ordinates of objects that will be in it and will be passed
on to the GUI team for the next process. It also keeps the records of movement logs for
each team member.

GUI:

A team will be delegated

to GUI. The GUI component will be the bridge between the
user and the system by providing the setting interface where the user can input their set up
and run the system.

Problems

Problems encountered include interactions with the interface i/e. Limits on
team
members in each team, map size selection processes, new map sizes to be entered.

Functions

It covers the user interfaces which allow the user to specify number of members in each
simulation team, can also change or selects pre
-
defined map sizes, chang
e simulation speed
and other ways to customize the GUI (Change the background etc.).

Sensor:

A team will be delegated to the team member sensors. The problems
relation to the
Sensory part of the simulation is

as follows:

Problems

Will the red team and the
blue team be able to see and hear objects or themselves
when moving within the
terrain?

Will there be lag or will on collision there not being any
sound at all.


Functions

1.

Detect sound and sightings of obstacles and teams.

P a g e

|
5


2.

Updates to the team and
obstacles locations.

Elicited Functional Requirements


Based on discussions with the other teams we have also elicited the following system
requirements.

Functional Requirements:



Ability to select number of members per team



Ability to select predefine maps



Ability to create a custom N by N map with random obstacle placement



Ability to change background of simulation



Ability to manipulate simulation speed while simulation is running



Turn on/off gridlines



Agent line
-
of
-
sight visibility



Agent hearing radius



Event logging



Initial map loads once



Map key display (symbol definitions)



Run simulation button and functionality



Pause



Map display



Number input for number of collective Sims for one simulation (collecting data)[needs
minimum and maximum]



Grid size inpu
t [needs minimum and maximum]



For terrain Random object generation number of object input [needs minimum and
maximum]



Time limit input



Grid on off functionality



Logging function



User input for number of team members



Time based player movement updates



Map
load functionality at simulation initialization


Possible future requirements



Ability to select AI type for each team (still needs to be discussed with AI team)



Save current simulation to file



Load a save simulation file and continue simulation



Ability to
create and load user
-
created map (still not concrete)



Possible implementation

of map creation functionality
yet to define what of this is our task
and what is the terrain group’s)

P a g e

|
6




Browse to and upload function for user supplied map


Non Functional Requirem
ents



The system will be develop using Java



The GUI will be develop using the Java Swing GUI Components

Assumptions:



User is a regular computer user that understand basic interface for the simulation.



The setting for simulation cannot be changed during proc
ess.



Players' sensors range is 5 tiles.

Problem
Analysis

The software project in question is a Multi
-
Agent simulation depicting a military strategy in
which two teams
of AI controlled agents
will simulate
two opposing sides
each with its own course
of
action
.


The scenario
revolves around

the two teams which we will call the Red Team and the Blue Team.
It involves t
he Red Team defending a bas
e in which a very important artefact

is placed somewhere
deep within. The Blue Team’s goal is to retrieve th
e sai
d

artefact or annihilate the Red Team;
in
contrast
, the Red Team’s goal is to prevent the Blue Team from achieving their goal. Simulation
ends, when either of the Team achieved their goals.


To better understand the problem our first step was to create a c
onceptual model of the
problem domain. By doing this, not only do we eliminate ambiguity between each member’s ideas
by agreeing on a more consolidated idea
we can also identify key concepts that could be later be
modelled as objects.

Figure 1, shows a rou
gh domain model depicting the components of the
domain and how they interact with each other.

P a g e

|
7


Field
Obstacles
Agents
is composed of
Team
Objective
/
Goal
belongs to
cant traversed
Blue Team
Red Team
can be
can be
acquire
/
reach
protect
are mutual enemies
is place on

Figure
1

Conceptual
Domain Model

Clearly identifiable are

some key components like the Field, Obstacles, and Agents, which we
think will play a big role in the simulation.

This model will help us later in designing our class
diagrams.

One of the pressing questions early on was
how to represent these domain ent
it
ies into
programmable objects

that can be manipulated and analyse specially in terms of their location
relative to other objects
.
The consensus between each team was to represent the field as a grid with
each object i.e. Agents and Obstacles having XY coor
dinate representing a cell in the grid.

Requirements and Analysis

Workflow

Before we can design what exactly happens during the simulation we need to understand how the
user will interact with the system. As the team responsible for the systems’ Graphical
User Interface
(GUI), we did some research on several simulation programs on the internet and a recurring theme
is to have a window where the simulation is presented and
a separate

window that houses various
user controls that affects the simulation.

The r
eason behind the separation being that the main
simulation
window
needs to resize
itself
depending on the size of the field/map.
Coupled with the
discussions we have with the other teams, we proceed on creating a use
-
case diagram that shows
the interaction

between the user/observer and the system.

It is worth noting before we proceed
that the requirements specification presented are still in its initial stage and will change as we go to
understand more in the coming days.


P a g e

|
8


USE CASE
Observer
Run Simulation
Change Settings
Run Practice
Simulation
«includes»
Set Team Settings
Set Map Settings
Set View Settings
«extends»
«extends»
«extends»
View Log
Save Log
«extends»

Figur
e
2

Top Level
Use
-
Case Diagram

Interaction between the observer and the system is rather simplistic as depicted in the use case
diagram. The diagram in itself serves two purposes; for the team to identify the some of the
functional

requirements of the observer in terms of system interaction; the second reason is to help
us model the mock
-
up UI based on the scenarios presented in the use
-
case as presented in the
succeeding pages.

Of the 3 top level use cases in Figure 2 above, the Run Simulation use case holds much of the
logic
while the rest are relatively trivial, thus, during the inception of our ideas our focus was on the
Run Simulation Use Case scenario and is depicted below.

Use Case
Scenario


Use Case: Start Simulation

Primary Actor: Observer

Precondition: None

Main Flow (Default Settings)

1.

User activates the simulation


2.

System gives the user the option to run a practice simulation and the number of times.


3.

User provides the number of times to run a practice
run
simulation.


4.

System runs and presents specified number of practice run simulation with current
settings.


5.

System signals the end of practice run simulation


6.

System
runs and presents
user with
the main

simulation
with current settings

together
with knowledge acquired during practice run simulation
.


P a g e

|
9



7.

System signals end of simulation and presents the results.


Analysing the initial use case and the mock
-
up GUI allowed us to determine the key components
o
f the GUI and the key components of the problem domain.

GUI Class Diagram

Might need to define a specialize abstract class that extends the original Sprite
class for the animated sprites like Agent
.
Since Agents may have several
unique attribute that other Sprites dont have including Animation
,
Line
-
of
-
Sight
,
etc
.
But until we know for sure how the other team implements the Agents well
just stick with Agents as being another regular Sprite
.
Responsible for creating a composite image of the map
,
the agents
,
and the
obstacles for every iteration
.
When the ViewPanel is repainted
,
it will paint the
image created with the Render
Sprite is any image representation that is displayed on the field
.
That means the Agent class
,
and the Tile Class which are both
instantiated in the simulation package needs to extend the abstract class Sprite
.
Runnable
+
Environment
(
in map
)
+
draw
(
in g
) :
void
-
map
-
spriteList
:
Sprite
Render
+
MapViewer
(
in map
:
Map
)
+
paintComponent
(
in g
) :
void
ViewPanel
+
paintComponent
(
in g
) :
void
javax
.
swing
.
JPanel
«extends»
+
getX
() :
int
+
getY
() :
int
+
getImage
() :
java
.
awt
.
Image
-
xCoord
:
int
-
yCoord
:
int
-
image
:
java
.
awt
.
Image
«abstract»
Sprite
+
run
() :
void
-
simulation
:
simulation
.
Simulation
MainGUI
ControllerGUI
«singleton»
Logger
ai
terrain
+
update
() :
void
+
getSprites
() :
Sprite
-
Sprite
:
Sprite
simulation
.
Simulation
javax
.
swing
.
JFrame
«extends»
javax
.
swing
.
JDialog
«extends»
MainGUI class instantiates new Simulation and
for every iteration of run
()
,
the simulation
is updated and all sprites are repainted to
reflect their current state
.

Figure
3

GUI Class Diagram (Still Needs To Be Develop More)

Interface design

Main

P a g e

|
10



Main interface contains
dynamically

sized map (legend and log will expand
as well

if required

Legend contains details of symbols and colour codes relating to map view

Log displays
a running

update
of current

actions displayed on
screen

Includes start/pause
functionality

button

Includes time

left countdown

Setting
s

button

to open setting window

Settings

P a g e

|
11






Map
choosing

from
pre
-
existing

maps



Custom map
options disabled

unless custom is selected in map choice



Width and
height

choice in square units for map



Implementation

of
a moving

smoke
o
bject one

instance can be turned on or off object
initializes

top left of map and moves based on user input



These options for smoke are only editable if smoke has been ticked on



Choice of
agents for

each
team in

development drop down choices will be change
d
to
military

terminology.
(4=fireteam, squad=8, platoon=24)



Number of training runs that blue team will go on to gather
Intel



Simulation speed is set by slider
and real

time duration by text box

WBS

Task Name

Duration

Start

Finish

Predecessors

Resource
Names

initiation

6 days

Thu
3/03/11

Thu
10/03/11




define group

20 mins

Thu
3/03/11

Thu
3/03/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


define scope
1 hr

Thu
Thu

Amanda
P a g e

|
12


(draft)

3/03/11

3/03/11

R,Ani,Keith,Novita,Pradeep,Victor


requirements
(draft)

1 hr

Thu
3/03/11

Thu
3/03/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


draft
documentation

0 days

Thu
10/03/11

Thu
10/03/11



planning

7 days?

Tue
22/03/11

Thu
31/03/11




uml
diagrams

20.34 hrs

Tue
22/03/11

Thu
24/03/11


Amanda R ,Keith,Pradeep


interface
prototype

2.7 hrs

Tue
22/03/11

Tue
22/03/11


Keith,

Amanda

R


problem
statement

1 day?

Tue
22/03/11

Tue
22/03/11


Ani,

Novita


uml
documentation

1.5 hrs

Tue
22/03/11

Tue
22/03/11


Novita,

Keith


grant

chart

2
hrs

Tue
22/03/11

Tue
22/03/11


Amanda R


references

2 hrs

Tue
22/03/11

Tue
22/03/11


Ani,

Pradeep


research

2 hrs

Tue
22/03/11

Tue
22/03/11


Pradeep,

Ani


problems

3 days?

Tue
22/03/11

Thu
24/03/11


Amanda
R,

Victor


requirements
document

7 hrs

Tue
22/03/11

Tue
22/03/11


Amanda
R,

Victor


collate
documentation

1 day?

Tue
22/03/11

Fri
25/03/11

7,8,10,11,12,13,1
4,15

Victor,

Amanda

R,

Novita


submission

0 days

Thu
31/03/11

Thu
31/03/11

16


Executing

35.5 days

Thu
7/04/11

Thu
26/05/11




XP coding

35.5 days

Thu
7/04/11

Thu
26/05/11




XP coding
1

4 hrs

Thu
7/04/11

Thu
7/04/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
2

4 hrs

Thu
14/04/11

Thu
14/04/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
3

4
hrs

Thu
21/04/11

Thu
21/04/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
4

4 hrs

Thu
28/04/11

Thu
28/04/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
5

4 hrs

Thu
5/05/11

Thu
5/05/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
6

4 hrs

Thu
12/05/11

Thu
12/05/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
7

4 hrs

Thu
19/05/11

Thu
19/05/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


XP coding
8

4 hrs

Thu
26/05/11

Thu
26/05/11


Amanda
R,Ani,Keith,Novita,Pradeep,Victor


Gantt

chart



P a g e

|
13







Learning Out comes


1.

Netbeans platform has more utilities available to program the component.

2.

Military composition


team members and positioning

3.

We learnt how to also accommodate other components with

ours so there are no code
collisions.

4.

Constant collaborations with other teams give us an idea of what can and can’t be
reasonably expected when it comes to coding and delivery of programs.

5.

GUI requirements must work within the boundaries set by the main
system.

6.

To compact the all details and work from the group member is quite complicated. In
addition to maintain and changing the version control also becomes very critical.

7.

We have the parameters of constructing our GUI.

References

D.P.J. Goodburn, T.R Pa
ttison and R.J. Vernik
. (2001).
Component
-
Based Engineering of
Knowledge
-
Enabled Systems: Research Vision and Strategy
.
Retrieved from
http://dspace.dsto.d
efence.gov.au/dspace/bitstream/1947/3767/1/DSTO
-
GD
-
0271%20PR.pdf

P a g e

|
14


Parker. (2003).
Multi
-

Agent Systems for the Simulation of land use and land cover change.
Retrieved from
http
://onlinelibrary.wiley.com/doi/10.1111/1467
-
8306.9302004/pdf

Sourceforge. (n.d.).
Multi


agent Capture the flag.
Retrieved from
http://ctf.sourceforge.net/ctf.html