For local review only: Submit one copy of this form with one capy of document '

(DO NOT submit original manuscript)

For NAVSEA review: Submit one copy of this form with two copies of docunent
For more information: See DIRCINST5605.1

EE[!| (checkone) fl 1. nbstract of paper lo. Brochure #,

El 2. Paper, Paper Discussion, or Speech (lnclude viewgraphs/slides) lt L
n 3. New Report (lnclude number) _ Ee.
fl4. Formerly Limited Document []s. :1]ti.x:'ffi",ffs*o=
' 'pr
fl 5. World Wide Web Page(s) (Use Form 5605/14)
ritre *rrw6 tpg€DtF.FcT(vFf Date Initiated Date Required

PReWeussy DCU€ uo|E 6t#fqt€r'L 0 | | tu6 }s?.f

asittEr,rlEPF'cE ( 6AE) Phone
2e2 -tz t z
Author(s) sEAP's and Mentor's NAME: g Ft t+l,l S e fiw nw'. ( cut t Lf nea R t€,#frWi&) / hgtrpta
Purpose (lf technical paper or speech, include wnen, wn@
SEAP PROGRAM at NSWCCD (West Bethesda site)

informal comments do not constitute official release NSWCCD release is determined by Code
-
It is the opinion of the author that the mateial to be released h1s no military application requiing
classification, does nol
contain controlled technology according to the Military Citicat Technologies List, and does' not iisclose
privileged information. AII referenced mateial is unclassified and ctearddforpublic release
triii i..i.,iii"
"i
Code Date ln Date Out Remarks

4rq
P tll'u'6 nLfu&+u urEl/ro P)

I have made the determinations required under

DOD 5500.7R (See Reverse)

0117

,
35.to
NAVSEA REVIEW n vrs fl No Date Fonararded: Date Retarrned:
Determination:

Relations Branch. Code 3810

Adding ProbE Directives to a Previously Developed
Graphical User Interface (GUI)

Brian Schwartz
Winston Churchill High School

August 11, 2005

Mentor
William M. Richardson
Naval Surface Warfare Center. Carderock Division
 CONTENTS

Section Page #
Abstract
Introduction....
Main Problem . .
The Goal
Program Design
Introduction....
Human Interface Guidelines
lmplementation of Basic Program Functionality . ' ' 6
Start Up 6
Automated Point Directive Creation 7
Automated Assembly Directive Creation 9
Creation of Plate Directives 1l
Creation of Stiffener Directives . . . . 11

Creation of Shape Directives I4

Other Program Functionality . . . I6
File Menu r6
File Save Operations I6
File Open Operations l6
File Quit Operations T7

Directive Menu 18
Selecting Points and Assemblies . 18
Modifying Directives 20
Option Menu 2l
Previous Viewing Area Operation . ' 2l
Restore Original Viewing Area Operation . . 2l
ProbEinput Optimizations . 22
ProbEinput Eror-Proofing . . . . . z3
Conclusion 24
Acknowledsments 24
Bibliography. . . 24
 FIGURES

Figure # Figure Description Page #

I ProbEinput Menus 3

2 Start Up Screen 6
3 Before Clicking the "accept point" Button 1
4 After Clicking the "accept point" Button 8

5 Before Clicking the "accept assembly" Button 9

6 After Clicking the "accept assembly" Button 10
7 Example Plate Directive Before Creation 1l
8 List of Existing Assembly Directives . . . t2
9 Assembly Name Automatically Filled In . ' . t2
10 Example of a Shape Directive Defining a T. . . 14
11 Assembly With a Stiffener. 15
t2 Finding Local Coordinates for T-Shape . . . . 15
13 Opened ProbE Input File ExamPle t6
T4 Quit Dialog Box . .
U
15 Selecting a Point Directive 18
16 Selecting an Assembly Directive . . . . t9
I7 Modifying an Assembly (Highlighting Assembly In List) . . 20
18 Modifying an Assembly (Referencing "Connected Points"
Field to an Undefined Point)
 ABSTRACT

ProbE is a computer program that estimates the probability of

seaway loads exceeding the structural resistance over the lifetime of a
ship. Both loads and structural resistance are treated as random variables.
ProbEinput is designed to speed up prepalation of ProbE input file
directivei by supplying a graphical user interface (GUI) to allow for quick
creation, modification, and verification of ship geometry, as well as
inputting information on material properties, operational conditions, and
statistical distributions. The scope of this report pertains to the
development of an interface that seamlessly integrates ProbEinput's
graphing capabilities with the ability to create, modify, and verify ProbE
input files textually as well as graphically in an intuitive and efhcient
manner.

INTRODUCTION

"ProbE computes the probability of exceedance of a ship cross section's strength

under seaway loading by analyzing the components that make it up. These structural
components are specified by geometry and material directives that are input into ProbE
from a user-supplied input file. For a station, geometry and material directives describe
the location and properties of a cross section's assemblies, plates, points, shapes, and
stiffeners. Additional directive types describe the environment in which the ship operates
as well as statistical distributions" fSchwartz,20041.

The fundamental unit making up a cross section is a subsection consisting of an

assembly, plate, and stiffeners. To make use of a fundamental unit requires material and
shape directives.

The following is an example of an assembly directive:

assembly 0 XYZ 3.5. sta-68 symmps 1.0 87.0 length-rv

In words:
The assembly named " xYZ" starts at point "3.sta_68" and ends at point
"5.sta_68". It is symmetrical about the transverse plane (port and starboard symmetry).
It is fully effective longitudinally. The stiffeners associated with this assembly have a
fore and aft span of 87 inches. The variability in the 87 inch dimension is described by a
statistical distribution named " length-rv".
 The following are two examples of point directives:

point 0 3.sta_!7 5.0 0.0 none none

point 0 5.sta_27 48.0 0.0
First example in words:
The point named "3.sta 27" lies on the 5.0 inch waterline and has a half breadth
of 0.0 inches. There is no statistical variability associated with either dimension ('none').

Second example in words:

The point named "5.sta_2J" lies on the 48.0 inch waterline and has a half breadth
of 0.0 inches. The statistical variability associated with either dimension is not stated, so
ProbE will set the associated statistical distribution names to be 'not defined'.

Main Problem
"Creating a ProbE input file for a single cross section can sometimes take
upwards to two weeks. This is not surprising since a ProbE input file for a large ship
cross section can average 300 point directives and about half as many assembly directives
alone. Unfortunately, much of the time creating the text file is not consumed in the
typing in of directives, but rather in error-checking for missing and repeated directives as
well as for incorrect information in the directives" fSchwartz,2004l.

"The problem resides in the fundamental nature of assembly and point directives.
On the one hand, assembly directives can easily be typed into the input file by locating
them one by one on a cross section diagram as they appear and then finding the
corresponding values associated to them on the cross section's table of offsets (assuming
it is available). On the other hand, point directives are much trickier to input because
there is no apparent order in which they should appear due to the fact that a single point
can be assigned to multiple assemblies. Therefore, a great deal of time ends up being
exhausted just in the process of proof reading the input file" [Schwartz, 2004).

This is where ProbEinput comes into play. The development of ProbEinput was
commissioned in the summer of 2004 because it promises the capability of expediting
ProbE input file creation by generating an accurate ProbE input file for any cross section
drawn inside its graphing interface. Last summer provided the time needed to develop a
scalable graphing interface that allows for the simple modification and expansion of its
feature-rich capabilities such as differentiating global and local coordinate systems,
mouse tracking, hot spots, point and line manipulation, and data precision to name
several. Documentation on the development of ProbEinput's graphing capabilities can be
found in the report Development and Implementation of a Graphical User Interface
(GUD to Expedite Creation and Modification of Directives for ProbE fSchwartz, 20041.
This summer's work uses these graphing capabilities to allow the painstaking task of
directive input file creation to be done in a pleasant and user-friendly fashion.
 Most of ProbEinput's capabilities are accessed through the program's main menu
bar. In Figure 1 and the sections that follow, the various menus that can be found such as
I/O file operations, making/modifying directives, and automated graph transformations
will be fully described.
'u+t=:-::-=::_ Pro IrEnp ut EEtr ProbEinput

!l..d.r
Dcrigo
i
I $J1!":

BE PrcbEnput-ffigg

Figure 1. ProbEinput Menus

One of the big ideas stressed throughout the development of ProbEinput is the
notion of a user defined program flow. Although there is a preferred sequence of steps to
be taken when using this program, it is understood that individual users work most
efficiently when they have the freedom to work in the order they see fit. Therefore,
ProbEinput takes a freeform approach to directive creation, affording the user the ability
to create any directive type at any time deemed appropriate by the individual. For
instance, its is preferred to create a design and header directive before any other.
However, it is perfectly fine if the user wishes to create them last, just as long that they
are eventually created.

The Goul
Creating the geometry portion of ProbE input hles is very tedious due to the lack
of order in which geometry directives need to be typed in since this order is usually
different for each ship. "Even further, analyzing spatial relationships among structural
elements is much easier with the help of a diagram as opposed to its offset table. The
idea of ProbEinput is to eliminate most typing by expediting the development of ship
geometry directives and moving them into ProbE input files as the corresponding ship
cross section is drawn in its designated drafting area" fSchwartz,2004l.
 PROGRAM DESIGN

Introduction

"The design philosophy of ProbEinput may be broken into two major sections:
human interface guidelines and program capabilities. Both sections are equally impofiant
in accomplishing the overall goal because a powerful program is useless without an
equally intuitive interface and vice-versa. Therefore, neither section is given precedence
over the other so as to strike an acceptable balance between the two" [Schwartz, 2004].

Human Interface Guidelines

"From it inception, ProbEinput was designed to bring the power and versatility of
automating the creation of ProbE ship geometry directives to people fwith little computer
background]. With this infusion of power and versatility, ProbEinput hopes to supply
users of any background with an intuitive interface that requires nothing more than
experimentation to wield its powerful functions properly. ProbEinput's interface is
designed to incorporate all of the important functions of a digital drafting area without
seeming too complicated and clunky" fSchwartz, 20041.

"First, when graphing on its drafting area, deciding between selecting a point,
line, or drawing a new line altogether is all done intuitively by simply clicking the mouse
button in different manners. For instance, ProbEinput knows exactly when one means to
select a point over a line because selecting a point takes precedence of selecting the line if
the mouse click is within 3 pixels (about Il24 in) from any particular point. Moreover,
ProbEinput "knows" to distinguish between selecting and graphing by merely calculating
whether or not the mouse moved in the timeframe of being clicked and released"
fSchwartz, 2004].

"In addition, much thought went into providing the user the best feel for graphing
a line. While dragging the mouse cursor in the drafting area, the line being drawn is
repeatedly updated to reflect its new end (x,y) coordinates. Furthermore, an
I
asynchronous thread is executed, throughout the duration the mouse cursor is moved
around the drafting area, to inform the user of the current position of the mouse. This
allows one to find the exact starting coordinate for a line to be drawn before having to
click the mouse button. These features, along with the ability of finding hotspots,
seamlessly mesh together to provide the user with a forgiving graphing interface that is
easy and simple to use" [Schwartz, 20041.

"Even more, much time went into researching how to incorporate color into
ProbEinput as well. According to Apple, 11988], color is used to associate or separate
objects and information by discriminating between different areas and identifuing crucial
features. ProbEinput's graphing interface is designed with this thought in mind. First, all

I
Java specific terms are rn italics.
non-editable text fields found in the interface below ProbEinput's graphing interface are
colored gray. This tells the user that although the information is important, it is solely
there to inform. Even further, all editable text fields are colored a muted yellow.
However, as soon as the text fields are altered, they immediately turn white to signal that
the user must click and release the "Enter" button before any change is reflected in the
drafting area. Once the "Enter" button is clicked and released, the editable text fields are
repainted in a muted yellow to signify that all of the text fields correspond correctly with
the graph. Finally, the "Enter" and "sig figs" buttons are painted a muted blue and the
"del line" button a muted red to indicate to the user that they are buttons. The "del line"
button is painted red so the user understands that clicking that button will cause changes
to the drafting area that are final. On a final note, all colors used are muted so that they
do not take the user's focus away from the drafting area. The interface is merely a useful
tool and not the fundamental purpose of ProbEinput" fSchwartz,2004].

Finally, ProbEinput was created with the programmer in mind. Thus, ProbEinput
was developed from the ground up in the Java language with object-oriented
programming (OOP) because this design philosophy affords the programmer the
assumption that every basic feature should be encapsulated in its own class and be able to
be transplanted elsewhere in the program without having to duplicate code. This leads to
the idea of modularity. The different classes making up ProbEinput can be thought of as
Lego pieces. Even though the different classes can be stuck together, such as attaching an
instance of the GraphPlot class (graphing area) to an instance of the ActionPanel class
(transformation panel) to create a transformable graphing area, the classes exist on their
own and thus, can be applied to aid in tasks not originally intended. Furthermore, OOP
makes unfamiliar code much easier for a newcomer to read and make sense of.
ProbEinput alone takes up just shy of 12,000lines of code. Although that may seem like
a lot of information for one to absorb, the entire collection of class files take up more than
double that amount at nearly 30,000 lines of code. As a result, ProbEinput is split up into
37 class files, each designated with an individual task to perform, in addition to a core
ProbEinput file that actually runs the program. For instance, one of the features of
ProbEinput is to be able to graphically display the geometry of a ship cross-section.
When a new programmer wants to f,rnd out how ProbEinput draws stiffeners onto the ship
assemblies, the logical place to look would be a graphing class. Consequently, one of the
classes in ProbEinput is tasked solely with the responsibility for drawing geometry
directives. This design alleviates many of the problems associated with absorbing 30,000
lines of unfamiliar code because it creates a logical flow as to how the program runs.

The following sections, "IMPLEMENTATION OF BASIC PROGRAM

FUNCTIONALITY" and "OTHER PROGRAM FUNCTIONALITY", assumes
familiarity with Java terms and concepts. A useful reference is Horton, U999}
 IMPLEMENTATION OF BASIC PROGRAM FUNCTIONALITY

Start Up
A large emphasis is put on the organizatton of information relayed to the user at
any one time. With the ability to quickly maneuver around an input file containing
hundreds (potentially thousands) of directives, there comes the important task of
displaying the information in a coherent manner. Hence, a system of interchangeable
JMenus,JPanels, andJLists was implemented in order to ease the user into learning
where different information is displayed and collected. Upon the initial execution of the
ProbEinput executable file, an empty graph is displayed as illustrated in Figure 2. At this
point, all graph variables are at their default values.

L-n
l l :': .
ProlrEinprrt
F
trE
Sirectives
.trrf iyns

t8"n

hor i =onts I vert i cq I

5::
cross ot B.B B.ta
:
*'
locttisn --- ro**"-t;il--
feet/in ! s.e 5 .278
unit* .-. l_ _ Enter l#'fil $ u
make assembly mtke poi nt

Figure 2. Start Up Screen

6
Automated Point Directive Creation
To dynamically create a point, click and release a spot on the graph and then click
the "make point" button. When the user clicks on the button, a JPanel will appear below
the graphing interface with input boxes requesting the data needed for the point directive.
As one can see in Figure 3, the information obtained from the graph is already filled into
input boxes such as the point name and its coordinates. That these input fields are
required is designated by the [r]. The remaining input boxes ask for the probability
distributions for the water line and half breadth as well as comments and are optional,
designated by the fo]. If one wishes to quickly clear all the data fields for any reason,
click and release the "cancel" button.

il
Fi le Di rectives llptiont

| 0.5

5.S
h

fi.8
lil
g-g 5-0 tg-s t5.e ?s.s 35.s

RXtS hor i zonto I vert i co I L IHE x c

cross st E.E 5.8 5.8

location --- lower- [eft 6.9 B.B

feet/i n 5.8 5.8
units ---
make assembly make point
--i"i"iu"."trl :' irtinllri , trutinilri
pt.l il Eg,g .- .-
,rl.P..Di=tr [ol ii exitts i-J ntv P Distr lol {-] exi*t* {-i nev
'
hb

Gorrents [ol
ll- accept point l! canc*l
.:]

Figure 3. Before Clicking the "accept point" Button

 Finally, click and release the "accept point" button to create the directive. As one
can see in Figure 4, a point colored red is now in place where the user clicked to
represent the newly created point directive. Additionally, the input boxes are now
cleared to indicate that ProbEinput is ready to create another point directive.

II ProbEinF gH
File

1A "*

:] -t! tr

g-*
llil,
&.* x "& !# -fl '13
"& 2ff -* 25.*

ffrt5 hori=ontol verticsl LITIE x u

cross ut Line stort i J.E]

line end j:-' s.B B.E

lomtion --- lower- [eft
feet/i n flousE ?,153 2 ,84?

units --- | Enter 1i siq fiqs 11 4 ;j d+l liilc ,ll

make a*s*mbly mrke point

l1
rr .f aistr IoI_{'-} existt,i*} neu hb F tristr lol i-} exirts {]l neu
: f,orrents IsI
I

.1ir

Figure 4. After Clicking the "accept point" Button

Automated point directive creation is made possible thanks to the mouse tracking
capabilities developed last year. Whenever the mouse pointer hovers over the GraphPlot,
a mouse listener stores its coordinates in the global coordinate system of the computer
monitor. After they are processed through a conversion formula to represent the local
coordinate system of the GraphPlot along with its units and scale, the coordinates are
ready to be stored in the point directive.

A utomated As s emb ly D irectiv e C re ation

To dynamically create an assembly, drag a line across the GraphPlot and cltck
and release the "make assembly" button. If a line is already drawn on the GraphPlot,
select the line before clicking and releasing the "make assembly" button. When the user
releases the button, a JPanel will appear below the graphing interface with input boxes
requesting the data contained within an assembly directive. At this point, ProbEinput
automatically creates point directives for the start and end points of the assembly, leaving
the probability distribution and comment fields blank. The user is informed of this
because points colored red replace the start and end points of the drawn line. As one can
see in Figure 5, the information obtained from the graph is already filled into the input
boxes such as the names for its start and end points.

iFProbEinput=;53ffiHH
File Di rectives Options

m--_-_-_-_--_---_I----
I s .a r.s I s.s | 5.s 28,a zs.a
I

flXIS : horizontol verticol !,

0.8 a.B 1A.A

lower-[eft I ine end 18. B

- - location
illili"
---
"
3.U NOUSE r.a
units.--
make e*sembly make point

Hsserb lg llqre [r I Gonnected Points [r]

Sgrr Code ... t..1 Gtobol Lood Eff [rI

Long Spon {in} Irl Spon Fond Vor Distr lot ,:l] existr tJ nev

Corrents lol
il accept a*sembly 1l
cancel

Figure 5. Before Clicking the "accept assembly" Button

9
 Finally, click and release the "accept assembly" button to create the directive.
Demonstrated in Figure 6, a thick black line replaces the drawn line to represent the
newly created assembly directive. Additionally, the input boxes are now cleared to
indicate that ProbEinput is ready to create another assembly directive.

TJ
llptions

horizontsl verticsl LIIIE :

x u
,.* l ine gtnrt : 5.8 I E.E
,. --: 1 ine end : ?6.8 I B.E
.i. .:

iIOUSE l
'11 t/ 13.61

unit*
make r**embly ti make poi nt

i __*i I

$grr Gade lrl Glohol Lood Eff lrl

Vsr oistr Iol -., exists ,-1t

,t
nccept a*sembly Ii.2 crncel 1

',i

Figure 6. After Clicking the "accept assembly" Button

Automated assembly directive creation is made possible thanks to the mouse

tracking capabilities developed last year fSchwartz, 20041. Whenever the mouse pointer
is dragged over the GraphPlot, a moLtse listener stores both the coordinates of the point

10
where the mouse is first clicked as well as the coordinates of the point where the mouse
button is finally released in the global coordinate system of the computer monitor. After
they are processed through a conversion formula to represent the local coordinate system
of the GraphPlot along with its units and scale, the coordinates of both points are ready
to be stored in point directives.

Creation of Plote Directives

Every assembly directive requires a coffesponding plate directive. Therefore, a
plate directive must now be created. Upon selecting the Plate menu item from the New
Directives drop-down menu, a JPanel appears below the graphing interface containing
input boxes pertaining to the creation of a plate directive. As one can see, the first two
required input fields ask for an assembly name and a plate material name. This is
because the geometry and material of a plate is defined by a corresponding assembly and
material directive respectively. For this example, even though the "assembly name"
corresponding to the plate being created has already been defined, click and release the
"new" radio button besides the "assembly name" field and type in "as1" in the text field
below to reference this plate with the assembly created earlier. ProbEinput does not care
how the information for "assembly name" is found as long as it is defined. Second, click
and release the "new" radio button next to the "plate material name" field and type in
"materiall" in the text field below so that when the particular material directive is
eventually created, this assembly will immediately reference it. The third required field
specifies the plate's thickness in inches. After any other optional fields are filled in as
exhibited in Figure 7, click and release the "accept plate" button to create the directive.
fl l. Dir.ciiYGt OFtl6rt

?t -6

dls ho.izo.tot e..tico! Lln€ I

c""": ot I s.a llN tt@t
loc.tlon.. l@a._lert lin' ?6'0 a.
'dd '!'u
fetTin
Enii.... rnt.r ri." ;i;iiii, ,r".
-
.2..............,,........,::;,;; ,;y- ,"1
nrt...s.nbly m.tc ,oart

tur.$tg ffo. I.l. ,.xi!tr 'i tr.v Pl.t. kt..i.l b. tFl , ;c:irtt 1.- i.Y

Pr.t. bi*..6 (ln) lrl Plcte Thlcrn.ss P oirt. Iol .:i.l! . *"

zu :l th s is o. eroBFte plqte d .ect ve .cc.tt Dl.r! 1 c.rc.l

Figure 7. Example Plate Directive Before Creation

Creution of Stffiner Directives

Although a stiffener directive is not required for an assembly, most assemblies
usually have one or more associated stiffener directives. For now, one stiffener will be
created as follows. Upon selecting the Stiffener menu item from the New Directives
drop-down menu, a JPanel appears below the graphing interface containing input boxes
pertaining to the creation of a stiffener directive. As one can see, the first two required

1l
input fields ask for an assembly name and a shape name. This is because stiffeners are
assigned to specific assemblies and take on the geometry specified by a shape directive.

At this point, the user has already defined an assembly so one will click and
field. Immediately, a
release the "exists" radio button besides the "assembly name" text
list pops up to the right of the program containing every assembly created thus far as
shown in Figure 8.

Figure 8. List of Existing Assembly Directives

There is only one assembly directive created thus far, so the user will select "as1".
Upon selecting the assembly, "as1" automatically appears in the input box below the
"Assembly name" text field. This is shown in Figure 9.

Figure 9. Assembly Name Automatically Filled In

I2
 For now, no shape or material directives have been defined so the user will click
the "new" radio button besides the respective text fields and type in the name "shape1"
and "materiall" in their input boxes below.

The next step is to specify a side code. The side code specifies whether or not a
plate rotating counter-clockwise about the starting point of its associated assembly will
pass through the stiffeners on the assembly. In place of the coresponding side code input
box, "side*" denotes that the plate will pass through it's corresponding stiffener upon
counter-clockwise rotation about the assembly's start point and "side-" denotes that the
plate will not. For the purpose of this report, a side code of "sidet" will be used.

Now, the edge code needs to be specified. This determines how stiffeners are
placed at the edges of an assembly. An edge code of "edge:l" will be used for this
example and places a stiffener at the starting point of the assembly.

At last, the final required text field "From Origin (in)" determines how the
stiffeners are placed across an assembly. There are four possible ways to place the
stiffeners: "avg", "loc", "num", and "spa". First, avg:17.8 puts stiffeners as close to an
average spacing of 16.8" as possible - actual spacing will probably differ from 17.8", but
all spacing will be the same. Second, loc:35.4 puts a stiffener 35.4" from the start of the
assembly. Third, num:4 specifies that there will be 4 stiffeners on the assembly not
counting those at the edges and will get average spacing. Finally, spa:27.5 puts as many
shapes as possible with exactly 27.5" spacing - last stiffener may have non-uniform
spacing. This example will use "num:5". At the click and release of the "accept
stiffener" button. the stiffener directive will be created.

At this point, a fundamental ProbE unit has been defined. This unit consists of an
assembly, plate, and stiffener directive. However, the GraphPlot won't be able to draw
the stiffener directive onto the assembly directive "as1" until the shape directive "shape1"
is defined. This shape directive will define the geometry of the corresponding stiffener
directive.

t3
Creation of Shape Directives
Upon selecting the Shape menu item from the New Directives drop-down menu, a
JPanel appears below the graphing interface containing input boxes pertaining to the
creation of a shape directive. At this point, all user-drawing capabilities such as drawing
nev/ assemblies and displaying old ones are temporarily disabled until one selects a
different directive type from the Directives drop-down menu. This is done so that there is
no confusion as to what the shape looks like when the computer outputs it to the
GraphPlot following the clicking and releasing of the "accept shape" button. There are
four possible shape types to draw: T, I, angle, and flatbar. An example of a shape
directive defining a T, as seen in Figure 10, uses the following dimensions in inches:
"Nominal Web Height" : 8, "Nominal Web Thickness" :4, "Nominal Flange Width" :
6, and "Nominal Flange Thickness" :2.
..*r-_:;;fu ffi
-..f;:: - r r vELrrrFns -

Fi le Di rective* 0ptior$

I I T l"* tt.t 't".u 'rt.u 't

-24 _8 -t 5 _S -16 _g -5 -A
- i

ffx l5 hor i zonto I vert i cq I LlltE : x

cross ot B.B I ine stort
:.''
lower-center I ine end
,:., .

i-1ches-/i n 5.8 nousE I -t I .1 l

Enter

Shope llore [rl Shope Tgpe lrl l{ar lleb Height {in} trl
tlt---
l{or lleb Thick (in} [rl llor Flg Hidth (in] [r] t{or Flg Thick {in} lrl
j il

l:b H:isht P Distr [ol.ii exists Ct new ,ueb rh jck P Distr tlll{-;, exist* ,i,,nev

Flg Hiclth F llistr tot iJ exists {,t ney .Fts Thick P oistr [o]il-] exists t] nev

__^.^Jl_
ll accent *haoe
- ' ll|__ cancet i

Figure 10. Example of a Shape Directive Defining a T

I4
 Now that the shape directive "shapel" has been defined, the GraphPlor will be
able to draw the stiffener that was defined onto the assembly directive "as1" as seen in
Figure 1 1. Drawing the stiffener on an assembly is accomplished by determining the
coordinates of the stiffener's shape in the local coordinate system of the assembly. This
is accomplished by comparing like angles as shown in Figure 12.

Figure 1 1. Assembly With A Stiffener

6 cD

Figure 12. Finding Local Coordinates for T-Shape

15
 OTHER PROGRAM FUNCTIONALITY

File Menu

File Save Operutions

When saving an input file with the "Save" menu selection, ProbEinput checks if
the file has previously been saved or not. If the file is new, a screen pops up asking for
the name under which to save the file. Else, the program replaces the existing file.
However, if one saves with the "Save As" menu selection, ProbEinput always brings up a
screen asking for a filename under which to save the input file.

File Open Operations

When opening an input file with the "Open" menu selection, directives are
processed through ProbEinput line by line because every directive type has a unique
opening procedure. Moreover, there is no particular order these directives must be placed
in the input file '. Figure 13 depicts what a realistic ProbE input file (with a mistake)
may look like when first opened by ProbEinput.

ProtrEinputffigE

-:58S.* -tF*8.F
HXIS .: horizontol vert i co I x
B.E
B.B
'
;.;

mrke rs*embly mrke point

Figure 13. Opened ProbE Input File Example

" Except that the station directive must occur before point and assembly directives

r6
 One limitation to the curent implementation of opening a file is that the file must
be located in the same directory as ProbEinput. However, this limitation is only a factor
due to the version of Java which was available for use'

As each line is individually read, the program checks for a keyword at the
beginning of the line that denotes the type of directive being read in. If the word matches
any of the recognized keywords, the directive's opening procedures begin. Otherwise, the
line is stored in a data buffer so that it can be retrieved when it comes time to save the
fi1e.

Every directive has a unique opening procedure because each directive has a
different number of required and optional fields. The way ProbEinput finds data is by
searching the line for character strings separated by blank spaces. Each character string
represents a different field in the directive and the opening procedures must be tailored so
that it knows how manv character strings to search for.

As each line is read in, an ..fro of the line is sent to ProbEinput's output screen.
This allows for a much easier debugging experience when searching for human errors in
the desired input file. When ProbEinput runs into a directive it cannot read, the last line
printed to the output screen is the faulty line of input.

Upon completion of opening of the desired f,rle, ProbEinput automatically zooms

the graph for an optimal viewing area with the axis set at the lower-center porlion of the
graph. This is accomplished by an algorithm that compares the smallest and largest (x,y)
coordinates and adjusting the graph transformations accordingly.

File Quit Operations

If changes have not been made prior to the last save or open operation, then one
may quit out of ProbEinput by simply clicking the "Quit" menu selection from the File
menu. Otherwise, before one may quit out of ProbEinput with the "Quit" menu selection,
aJFrame pops up in the middle of the screen, like the one in Figure 14, to show exactly
how the user wishes to exit from the program.

E ,r-. Do you wantto save chdnges? -' =+ E

Figure 14. Quit Dialog Box

ll
 The user may choose one of the following choices: "Save" before quitting, "Save
As ..." before quitting, "Quit" without saving, or "Cancel" the quit operation all together.
Throughout this process, the user may not select anywhere else on the screen until one of
the four choices is selected. This is done to prevent the JFrame with the quitting options
from being accidentally unfocused and thus accidentally hidden from view.

Directive Menu

Selecting Points and Assemblies

As ProbEinput data files quickly grows larger, the ability to maneuver around the
data becomes increasingly important. Having to sift through thousands of lines of data
will easily get cumbersome unless there is a logical way to link related information
together. One such example is the ability to efficiently find corresponding point
directives for an assembly. What makes this so difficult is the fact that although an
assembly directive can only match up with two point directives, a point directive can
match up with any number of assembly directives. This problem is dealt with by giving
the user the ability to differentiate between clicking on a point versus an assembly and
displaying the appropriate name for the directive selected GraphPlot.

Whenever the user clicks on the GraphPlot, ProbEinput immediately calculates

the shortest distance (d) between the point clicked and one of the defined point directives:

d=m
If this distance is less than 8 pixels (about 1/9 inch) in length, the program
displays the name of the point clicked on so that it can be quickly retrieved as seen in
Figure 15.

FiIG 0ptitn3

3"$ 596 -n | 668 -A

pt: 27.sto-|3 {-1.9,728.9)

ma ke ssscm bly mrke poinl

Figure 15 Selecting A Point Directive

18
 On the chance that a point directive is not in range, the program then searches for
the closest assembly. It can be shown that sin(angle) between any two vectors, starting
from a common point, is equal to their normalized cross-product fSchwartz,2004]:

Axe
sm(U) = 1=1-i=1
lAl.lBl
ttll

By creating an invisible line that extends from the point clicked on by the mouse
to every point directive defined thus far, ProbEinput can find the smallest angle between
one of the invisible lines and the assembly containing the point in both the assembly as
well as the invisible line. If the angle of the assembly that refers to the smallest angle is
less than or equal to 0.2 radians (about 11o), then the program displays the name of the
assembly. In this case, the assembly selected in Figure 16 is named "Mn-dk-a-s".

ilffi=r,*:PrabEinp

Figure 16. Selecting An Assembly Directive

The location of the string describing the selected point or assembly is a function
of the number of characters contained within it'

I9
Modfying Directives
Modifying all directives, no matter the type, follow the same procedure. In this
example, an assembly will be modified. Upon selecting the Assembly menu item from
the N4odify Directives drop-down menu, both a blank JPanel with input boxes pertaining
to assembly directives and a JList wfih the name of every assembly directive thus defined
is displayed. Notice that when the user clicks on an assembly from the list, the
GrapiPtot promptly zooms into the assembly, centering it on the screen, and the JPanel
immediately displays all of the data pertaining to the clicked upon assembly directive.
However, none of the data is editable until the user explicitly clicks and releases the
select button below the list. For explanatory purposes, the example assembly presumed
selected will be the one selected in Figure 17 named "Mn-dk-a-s".

ZEetZr tstz &***,{tr}tt t2 t{ *619. t84.t

1*t* {*z}*8

hea r_strd ke _s
_bk_02-03_p
hed r_strd ke _p
7? "e I t??"8 2??,4

l_bk_01 _02_5
verticul LIHE s 5hell_01_02-5
l_b k_Mlt_d k-01 -5
s_rhell_Mr-dk_01-5
Mn_dk_a_s
lvln _dk_lr _5
tulrr_dk_a-p
make assembly

!*:::b-.ls-li:ia "!i...1...-, . -...--::--"::sd-..1:.i*:-.1:-l ,tutrr dk d u

'.-.......'......|'}.!J].='-...)i'-..
sgrr code ..- Irl Gtobol Lood Eff lrl t rr,ln Jr.-t I
ll_lrk_2_Mn_dk-s It
:

. -,::gd I .. .!..,.4=- -'.---* '1- I I

Long spon {in} lrl :sPon Bond YoF lls.tl tal .. ....1.'1': ls_shell_2-Mn_dk-s |
2Mndku ri
1

1 6S.B
,-l.r i . ^ 41.
r.L 1I.u
"r, -r--.--***j;
- :*;
Select Canc.:l
*,

Figure 17. ModifYing An AssemblY

(Highlighting AssemblY In List)

At this point. this process involved in editing an existing assembly is identical to

creating a new one. Even more, the process in editing or creating any other unspecified
directive is identical as well.

20
 Option Menu

Previous Viewing Area Operation

After investing quite some time working with a ProbEinput file, one may begin to
make careless mistakes such as inputting the wrong numbers into the ActionPanel
transformation text fields before click and releaseing the enter button to reflect the
changes. As a result, one may find themselves staring at an unknown area of the
Graphflot or nothing at all. Consequently, the "Previous Viewing Area" operation
-uk"r sure that the most previous transformation settings are stored at all times so that
the current settings can be reverted to ones that are more familiar.

Make All Assemblies Visible Operation

Following a long session of ProbEinput, one may begin to lose their bearings as to
where in the graph they are. This may be due to different assemblies looking similar
when zoomed into the center of the GraphPlot or simply because one accidentally enters
in the wrong transformation settings into the ActionPanel. Whalever may be the case, the
"Make All Assemblies Visible" operation is designed to determine the best graph
transformation settines in order to be able to fit all defined assembly directives onto the
GraphPlot.

2l
 PROBEINPUT OPTIMIZATIONS

With the ability to store thousands of directives, ProbEinput had a dangerous

potential of becoming a serious system resource hog. Unless the directives can be found
with great efficiency, the benefit from having ProbEinput quickly diminishes for speed is
the reason for commissioning ProbEinput's development in the first place. Hence, a
sound way of storing the data as well as an equally sound way of retrieving the data must
be created.

Following the initial implementation of drawing stiffeners onto assemblies within

ProbEinput, a serious hit to the program's performance was easily noticeable. The reason
for this turned out to be because of the GraphPlot's paint method. Paint methods are ran
on a system thread. This means that the programmer has no control over when the
method is called. In the particular case of the paint method, it is called continuously
throughout the duration of the program until the program is exited. What was happening
was that whenever the GraphPlot's paint method was called to paint the stiffeners onto
the screen, an (ry12 * nzl2 * ry12) search operation was taking place ': first the program
would search in each of the nr stiffeners, then it would search for any nz assemblies
referenced by each stiffener, and finally it would search for any n3 shape referenced by
thestiffenerandassemblypair. InJavaterms,thisis aforloop within aforl.oop withina
for loop.
As a workaround to this clear problem, the memory address of the assembly and
shape referred to by a particular stiffener is immediately found and stored within the
stifiener directive .rpotr itr creation and/or modification. This setup makes sure that
probEinput searches for a stiffener's corresponding assembly and shape directive only
on"" und not every time the GraphPlot's paint method is called. Analyzing the number
of iterations in the search loops having to be performed when drawing the stiffeners on
assemblies with the new method versus the old one is quite staggering. Take the test
input file for example which contains 13 stiffener directives, 136 assembly directives, and
54 shape directives. On one hand, the new method only requires an average of l3l2
iterations through a single for loop that searches through each stiffener. On the other
hand howe,r"r, ih" old Lethod requires (13*136*54)/8 or 11,934 iterations through a
three level for loop. This is a l(1-(1312)l(11,934))*l}0l% or 99.95%o reduction in time
for drawing the stiifeners and this is only for a single call to the continuously called paint
method. As a result, this method of referencing directives was adapted to the other
directive types, resulting in a significant performance gain. What was once a program
requiring ottly th" best computing power, can now be used effortlessly on less current
-uihin.s, greatly improving the program's market share diffusion.

3
On average, ll2 of a list has to be searched to find a match.

22
 PROBEINPUT ERROR-PROOFING

Along with a program as complex as ProbEinput, comes a greater possibility for

errors. These errors ian take on many forms such as a user feeding in the wrong input
type, manually creating an assembly connected to points that do not exist, and so on.
Aithough it is nearly impossible to trap for every error, much effort went into catching
the most common errors.

Foremost, directive input fields that require a number will make sure that the user
has indeed supplied a number rather than a word. Otherwise, upon clicking and releasing
the "accept fdirective]" button, the input boxes with invalid input will display the text
"invalid" and a directive will not be created until the input is corrected. This is
accomplished with try/ccttch blocks. When ProbEinput sets out to retrieve numerical data
that does not turn out to be numeric a7, a NumberFormatException is thrown and simply
prevents the execution of that particular line of code. This helps avert the complete
malfunctioning of the program by localizing the problem into a single error which can be
dynamically corrected. Furthermore, if a user decides to change the "connected points"
freld of an assembly directive and one or both of the points do not exist, ProbEinput
automatically creates new point directives for the unknown points. Even more,
ProbEinput furlher helps the user out by labeling the points in question from the point list
under the modify point directive menu item as shown in Figure 18.

{..xisti {t4 ftr}i *t f:i {"*2,"44:.

2137 t*.J.14
r"3za:rtil:[t-
| 32b.std_1 3
l47d.std_l 3
'l,lID.std_'|3
l{Ic.sta_l 3
l.l7d.sta_13
3
il-{7e.5ta_l
I l47f.std_1 3
l47g.std_l 3
I 53a.std_l 3
| 53lr.std_13
I 53c.5ta_l 3
I 53d.5td-1 3
| 53e.stn_l 3
| 53f.sta-l 3
| 530.sta_1 3
| 56d.sta_1 3

t-
l56b.std l3
I | 6gd.sta_l 3
rl (in) Irl hb (in) IrI
i I 79d,std_l 3
27d.5td_l 3

i+ 82aEd'5ta-
" undPfi ned

Figure 18. ModifYing An AssemblY

(Referencing "Connected Points" Field To An Undefined Point)

/.J
 CONCLUSION

Over the past two summers, ProbEinput was designed and implemented from
scratch. As of 8111105, ProbEinput is capable of providing a graphical interpretation of
ship geometry, real-time modification of ship geometry, and I/O file operations.
Although there is still more to be implemented such as a delete function for spurious
directives, the core functionality of ProbEinput is finally in place and can now be utilized
properly with its original intentions in mind.

ACKNOWLEDGMENTS

In completing my summer internship, I would like thank those individuals who

went out of their way to make my summer experience a worthwhile and enjoyable one.
First, I would like to thank Norman Tadlock for the time and effort he invested in
coordinating such a rewarding SEAP program. Finally, I would like to thank Mr.
Richardson for the endless guidance and direction he gave me throughout the summer.

BIBLIOGRAPHY

Apple Computer, 1988. Apple Human Interface Guidelines: The Apple Desktop
Interface. Addison-Wesley Publishing Company, Inc: New York.

Horton, Ivor, 1999. Beginning Java 2. Wrox Click and release: Birmingham, United
Kingdom.

Richardson, William M., 1997 . PROBE: A Program for Level III Estimation of Ship
Structural Reliabiliq, - User's Guide. Naval Surface Warfare Center Carderock
Division. NSWCCD-TR-65-97 l3l.

Schwartz, Brian, 2004. Development and Implementation of a Graphical User Interface

(GUI) to Expedite Creation and Modification of Directives for ProbE. Naval
Surface Warfare Center Carderock Division

24
 Previously
Graphical User Interface (GUI)

Brian Schwartz
 ':

of toads exc.-oi"*
lifetime of a ship

. ProbE input files consist of directives

Example: assembly directive (defines ship geometry):

. Adheres to Apple Human Interface Guidelines

. Platform independent code

. lVritten in Java
 SrnPhinu ttrindmw
x s.s

.Intuitive and User'Friendly Interface

.scalable Graphing Technology

s*m

.Modular Design

sturt
lucatinn menu
1\:tjtt.t)a::: .r:rr... :::::rd r,1, : :::::::. : ).: ntrl.,rl:hil;iti ::
Iurrrer- tef t
ntru$E
::

teet^f.l- I n
units mf,nu *iq fiq* I
Fi Ie Di rective* trptiun*

ProbEinput: Summer 2005

gm *m
.Speedy Ship Directive Creation and llodification

ffi-w
.I/O File Operations

.User Defined Program Flow

#*w
w*ffi t,|{ ffi t w *m $ m *ffi x# -w 3m *ffi

FXIS tror i zonts I Yert i es I g

crtrss s t I

lnuntion Lawer- Left

feet/i n - ltnusE 2.814 5 .2?S

unit* Enter *ig fig* 4

mnke fi*$Gmbly mtke pui nt

FrmhEinput
I.
;i;;i

lii:'r

liirii

lii.,'

;ii.

il,..
iiiii

iitii

iriirl

;ii;
!
E
t;
U
n
I
J
13
F
I

r+

iii,.

iliji:

:itl'i

iiiiir

lli,;

tllili

:li,''

liil:

iiii.i
ir;ii

H
ffi
il
iiljj

iilii.

illir:

iliiii
iit;ii

iitii

iil!
rT
s
'l
tr
I
IJ
n
t
-
1I
F
I
rt

iiii
iii,
liiii:

iilii:

iiiijr

iillli

liliii

ii;iii

iiii;

iliiii

H
ffi
 ioueinputffiHH
Fi le Di rectlYe* Ilptiun*

Automated Assembly
Directive Creation
sc{ s $t$ry*w sm *w :a*r * ss p5 *w$

]rsr i =srrts I rreFt i es I !J

1E.E
Ior.uer- lef t 2E.E 1E.g
1 I ..+? 1 -6

fls=erb 11g t{ure [r I

$qgrr f,nde- -,: - lrl G lubs 1 Lnqd Eff [rl

l-orrg fiporr {in} lrI f i:=tr Isl ,i-*-i exist* r"*-:' neu

---*--* !f-'-
nccepta*temhly $N *nn*el $

",ris
ill

iiii;il

,''':l

iririil

'iril
tiilii

!
-
F
tt
H
g
!
d
.!t
U
E
FT

.,
ri

iiiill

,',;

iiiiir

,',t'ift

iiiiii

iiilil

H
ffi
 ro Hl
Fi l+ Options
Fai nt
Jl*+ernhly
S SS -$*$
Hrterirl
Flate
ff,hrpc
5t i ffe ne Accessing Shape
Heade r
s *ss
Design
Station
Directive Creation
Op---f,el l-i
ffi*ffi tlp-Cel l-r
ffi *ws ffi*w $W *W$ { tr} *ffi pw *&& ;am *w

HXT5 I ]rsr i ;rrtrtr ts 1 rJer*t i cs I LIHE u

cr'f}55 0 t { B.13 I i rre =tsrt t E.g
lE:r4
$

Incation r**=-l teft I i rre etrd

fee+.f i n ft{}l-l5E 1B.S?
units _*..**:.:. "
Enter
rrrrke fis$Grnbly
fts=erb 1g l{sre Ir I Ccrrrrec ted Ps t rr t= [ r I
$$
$:l

fiqlrr f,ade lrI G laba I Losd Eff [r I

-.-j - :, neu
l-orrg Sparr { Spurr fl i =tr Irr I ,. ex i sts i:

Gcrrerrtr= [o I
ncce pt ffssemhly
.:::"!
il

!
n
F
H

E
t
J
3
tr
+

iillii

ru
ffi.
 i

fr
i
E

llriii

!.'
tr
H
EI
I
H
F
FT

iliii;

iiiiii

liiiii

ifr
L5
m
 n
iliifi

!iiiil

iiiijj

iitiii

iliil

ltilli

ii:ijj
!-
tr
EI

-F
ri

Ititii

iliii:

ltil!,

lliiii

ililIt

ililil

H
m
..:1 p;"glf EinpUt lffi,H
 Fr"il h Ei rr p ut tr.H
Di rectire* trptinn*

Selecting a
Point
Directive

*$ mwffi -w *x swffi *w -m#ffi **t ffi-ffi g:il,$[$ffi*ffi gWffiffi.W$

pt: 2?-stu-|3 {-l -sr?tE-q}
,l hnr i zuntn t rrert i cu L LlllE ,,
U

I i ne stsrt ?29.?
line end E,E
.::::

5E1E . E lIOUSE
l-.$
ii ,_ tnler
____,___.,'--_ -., - *...........-
i
l
*ig fig*
ff$$Emhly mnke point
. Ease of selecting (forgiveness)

d- (x )'
PrnhEinput
 O,

Eil
\J
A.l
F
(a
o
A
v
f-b
V)
tD
(t) l-
(?
tsr A
\t
(+
- -.:
F
7|'- -
OO
@ *,
\/ vd,'
tl
oa
tl -.
tD
x,-
tD
U):
0
),3
X \./ :

*'..'.
w
itt:
a

EUr
!l
NI
Hl
lrt l

ql

F
r-

ll;;

iiiiil

il'i

i';;i,

!.iii:

l;r;ii

ii;;

;;i
E
m
!l
EI
ml

EI

,',']

:li,,rl

;iiji

;,i'i.

.EI
ffi
 Fi le Directirres Iptiun*
ilx 6 *S $ mq Wm $ m'R $3 $ rw*t $q***
ffST $wu*ur{$

ir. t ffU.sta-t f
Mo urfied i
l4Tn.sta_l3
l47lr.sta_13
**t_
*$
Tls "|[$ l.llc.sta_l3
3S -ffi f?^ffi i str-s tr?tr -&$ l{Td.sta_l3
l4/e.gta_l3
l4If.sta_13
l4Tq.sta_l3
l53a.sta_l3
r: lln-dk-o---s l53lr.sta_l3
hor i zonts I Yert i cs 1 LITIE l53r.sta_13
l53d.sta_l3
I ine sttrrt
| 53e.sta_l3
| 53f.sta_l3
i nches/i n
| 53g.sta_l3
unit* --- | 5fia.sta_l3
mnke n**emhly mnke pui nt | Sfrlt.sta_l3
| 6$a.sta_l3
P* i
"i ttore [r I {in} [r] {in} [rl
I T$a.sta_l3
SIa.sta_l3
fitla.sta_l3
Csrrents [ul *+ undefinBd *x fllasd.sta I
lln yfiu Htr.utt tn sflTE rltdllrJf,sT

File Quit Operation

f,a nt* I
. Analyzing spatial relationships among structural
elements easier rvith diagrams as opposed to
offset tables

. Intuitive and user-friendly interface