The first image of the Calculate Pace Window

This GUI was a long time in coming and it was very painful. I had to reteach myself about different GUI outlays in Java other than the traditional ones that I am most familiar: like the Grid Layout, the Border Layout, etc. I used the GridBag Layout for this, and it was long and tedious re-familiarizing myself with it. I almost just switched to using eclipse. I even downloaded the application, but decided the amount of time learning the IDE would not be worth it at this moment. So, on my spare time (what ever that is). I intend on learning the "new fangled and free IDE"!! (ha-ha).

Well anyway, here is the latest image of the Calculate Pace GUI. Now it's time to get it working--implementing the Use Cases from the design.

The buttons and menu items are set up

I have the initial functionality of the first GUI working. All the buttons and Menu Items are registered. The only item that that is actually working is the Quit button and the Quit menu item. Nothing else is currently working. That is the next step in the development process. Once that is all done, I can then start implementing the Use Cases.

First Image for the first GUI

Here is the initial image for the Application: nothing works yet, but that will change. Also, more GUIs will be added as the Application evolves.

Time for development

Onward to development. I will keep everybody posted as the system comes to fruition. I will even post my concerns and (possible) system redesigns as the development cycle continues. I do have a tendency to take the "screw it, just make the thing work approach" when I find the design did not encompass enough of the development issues. Hopefully, those issues have been worked out by experience and time and proper thought. But, that is to be determined. I probably will add some more designs to "aid in implementation" as development progresses. But, that is just part of the "black art of development".

I have decided to implement this design in Java.

This is the most appropriate choice for me.
This is because:

1. Java is free
2. Java integrates a built in GUI set that is easy to implement and provides implementation support that makes implementing the Model-View-Controller architecture intuitive and free from "language" distractions (my words, I don't know of another way to put it).

So, regardless, this application will be developed in Java.

Onward to development

The designs are as complete as I think they should be for a system of this size. I am content with the amount of design detail in this design. It is now onto development. From this point on, the postings will be related to the development of the Pace Calculator Application.

Component Diagrams

Remember I talked about Component Diagrams yesterday during the "Marathon Blog Session" used to catch up? Well, after more investigation, I found out some things about Component Diagrams. I was almost ashamed that I never used Component Diagrams, and I thought this was an inadequacy of my skills. So, I went to the UML source (IBM Rational) and got out a couple of books related to design. After reading up on the subject, I found out why I had never implemented a Component Diagram. It turns out none of the Systems I have developed were not large enough to merit such a diagram. It turns out that Component Diagrams are used for the Design phase, but it is almost as if they abstract out the objects and group the system into components (duh). These components describe system parts that are interchangeable and replaceable. Thus, really the only part of this system that I could "componentize" (think of making components) would be the View, or Controller (both of which are now designated as packages, but could be thought of as components).

Static Class Diagrams

Current Static Class Diagrams:

Static Class Diagram 1

Static Class Diagram 2

Static Class Diagram 3 (not much to it)

Static Class Diagram 4

Static Class Diagram 5

Static Class Diagram 6

Static Class Diagram 7

Should Always Follow

I should always follow the KISS principle

Keep
It
Simple
Stupid

Latest Design Issues

Need to come up with an idea of justifying the TimeDistanceSettings class. I think I have all the classes that are needed defined in a static as well as sequence diagramming form. There are some other classes that need further defining, but since those are sub-classed from already preexisting classes, most of their defining structure is already done. So, for those classes, much of the functionality can (and will be determined during implementation). I don't see that as a problem. I flirted with many ideas related to the Time and Distance objects about how to set up the units for the Distance class and the time format for the Time class. I considered defining a class that held enumerated types for both sets of data. Finally, I concluded the easiest thing to do would be to just set up booleans for the time formats and static integer values for the distance units. Although it is not as elegant as other solutions, I have a problem trying to figure out enumerated types in Java. They seen far too complex for my taste. So, I settled on to me is the simplest idea.

What a week it's been

In terms of design, this has been one of the wildest weeks on record. With trying to get my taxes completed, and figuring out the little intricacies (albeit overly complex) of this design. Well, today on my day off, I ironed out all of the details. And, be that for good or for worse, that is what I am using for application development. Because I believe in "Living documents", some of this might change as needed. But, for now, I have most of the design completed. It is now onto reading and implementing (possibly) component diagrams as needed and publishing the Static Class Diagrams.

Uploaded all the Sequence Diagrams

I have uploaded all the Sequence Diagrams in one entry. They are now ready to be accessed relatively easy and in one location.

Will need to look up how to save data in the current language. For the design, I will "generisize" it as much as I can, but since I am now getting into saving file, I need to understand the language specifics of saving off data. Serialization is a big part of this. The Writer/Reader object that is created will need to handle this idea. Clearly, again, this is starting to get into language specifics.

Use Case 5 was a very large Sequence Diagram and it took a long time to figure out. There are still some issues related to it: like figuring out how and what format to save the data->this should be handled via object serialization. For now, I want to keep this as simple as possible. Once I get the basics of the application running, I can come back and look for other improvements: like saving the data to a database, and the intricacies of implementing that. I also, want to go ahead and print out this latest Sequence Diagram. Also, I need to go ahead and improve the development blog, and save off the diagrams here and on that blog.

I now have the Sequence Diagrams complete.

The next step is to improve the Static Class Diagrams. This can be accomplished via the Sequence Diagrams mapping out the Use Cases. There are some other responsibilities required in each class that is not documented in the Sequence Diagrams, that will need discernment as the design progresses.

Sequence Diagrams

System Sequence Diagram for Use Case 1: Enter Run Data

Sequence Diagram for Use Case 2: Calculate Pace

Sequence Diagram for Use Case 3: Calculate Run Time

Sequence Diagram for Use Case 4: Calculate Distance Ran

Sequence Diagram for Use Case 5: Save Run Data

I have a lot to upload today

I have made a lot of changes, and I need to upload those changes here. There are some other issues that I will be resolving as the design continues.