Many, Many Ideas

I have so many ideas. Yet, I don't know how to get them started. There is so much out there, so much to learn. I often wonder how this whole development idea got away from me. It seemed just yesterday, I felt on top of the development community: that I knew all the appropriate languages and development techniques. Now, there are so many things to learn, so many directions to go. Everything has grown so rapidly, that I often wonder, when and where was I left behind. Take Java, when I first learned it, Java 2 hadn't even come out. Now, there is talk about Java 1.7! I just downloaded Java 1.6, and to me, they should have stopped at Java 1.4.3!! There are so many packages, so many classes, that I honestly have no clue what all they do. It used to be Java could be summed up in the Java in a Nutshell book. Now, that does not do the trick. Several years ago, they introduced Swing, now you need more than Nutshell book, as well as the Core Java books. And, they don't even cover everything.

This past semester, I took a Visual Basic class as part of trying to come "up to speed", with a language that is simple, yet important to use (for future use mainly). It seems like a pretty "self-taught" style language, but it would still be good to learn. So, I have a book, took a class, and have some projects that I did.

Yet, at the end of the day, I still have all these ideas rattleling in my head. Yet, often I don't know how to express them. Many people have told me that I should give up on these projects--that I should just use my skills for work. If that were the case, I often think I would just live a life of even more quiet desparation. For me, I feel that I need to express my ideas in some form or another. Yet, I often don't know how. This development blog has been perfect for me. This is a place to at least put down my thougts in a journal type form. Actually, I should just update the wikis and blogs related to the projects I have released. Often, when I start these projects, I think of the things that I need to do as part of the project. Often, these "things start to build up" and it makes the taks seem unsurmountable. I often should think of these things as part of the project itself. That would make it as part of the project's allure and chalenge.

One of the ideas I have is making a weather station from a 1-wire device. As part of my running, I discovered something to add to my Pace Calculator application. It seems for my Garmin, the max pace is not given, but the max speed is. This is a possible improvement that could be added to the Pace Calculator--to take run speed and translate into a pace.

I often wonder if I am just waisting my time with all this. I often wonder if I should just give up on all this. There are household and family projects that I often put on the "back burner" as an attempt to do all of this. Not to mention this is less time that I spend with my family. So often, things get overlooked when I start these projects: not to mention the fact that I might consider going to grad-school. Grad-School, how do you shuffle that into the mix? For the working individual, time is a valuable commodity. For me, I have so much vaction time that I need to use this year, that perhaps, I will get do completing all the things I want to accomplish (this would be a great year to go to grad-school because of that).

I would also like to place a lot of the code from the many projects that I have done on a "web reprository" (at least on a web page local to the home network). That way, I know where they are. This old code has so many good examples. Not only that, but I can put my .bashrc from Linux on there as a way of remembering how and what to set up (as well as the .vimrc). Plus, any thing else I would like to remember, but forgot--like setting up an executable JAR file. This is something I have NEVER documented!!! I can't believe that! How stupid am I?

Well, I just need the disciplie to "Just Do It" (as Nike would put it). In the end, writting this out did help. Well, it is now time to start taking action. That is what all this comes down to: stop talking and start doing.

Placed the code/documentation on the code.google.com site

After some much debate, I went to code.google.com and set up a new project. This is the place where the code will reside. It will serve two purposes:

1. A code repository: I will no longer have to back things up locally. I forget where I put the code, I make multiple backups and I always loose track of which version on which backup is the latest. Yes, it is true, I could just look at the file date, but I am too lazy and this is much easier.
2. Publishing the code/application publicly. As stated earlier, the code is registered in the GNU Public License Version 3, so there is no concern of piracy: it is for everybody, regardless.

The code is registered at my Google code site that essentially came as part of my account. My apologies to Google if I just chopped up this concept of service Google has so generously offered.

Regardless, the application and source code is now published and available for all who want or need it. I am sure there will not be many downloads, BUT that is OK: no one ever reads this blog anyway. Ah, the great thing of being in the world of cyberspace (ha, ha).

(Goofy) Mission Statement

Now that the application is complete, this blog is essentially finished. But, I would like to share my personal mission statement related to software development. I am not worried about getting mocked for this, since no one will read this blog anyway.

I don't know who first said it, but it has become my mantra: Software should benefit mankind, not bankrupt it. I don't make large software applications. In fact, this is just a hobby to keep my skills sharp. Regardless of what people may think, I have published my development strategy here in this blog. It is for the entire world to see for better or worse.

I would encourage all people to use their talents for the pursuit of the benefit of mankind. Part of that means helping those in need. Since my software that I develop is free, I would encourage people who use it to donate some of their time and/or money to their favorite charitable organization as an expression of gratitude for all the gifts they have received in their lives (if nothing else, my free software). If any of you do not have a favorite charity, here are a few of mine:

• Society of St. Vincent de Paul
• Catholic Relief Services
• The American Red Cross
• The Red Crescent
• The American Cancer Society
• Caridad de Porres
• Big Brothers Big Sisters
• Urban Promise
• America's Second Harvest
• Mother Teresa of Calcutta Center

Not to even see myself as an equal, but to paraphrase John Lennon (or brutally slaughter it): If I'm going to (put something out there for the rest of the world to see and use), it might as well be with the (message to benefit mankind) on it. You might not agree with this statement, and you don't need to use the software (or you do, it's yours to keep).

If you have any comments about the software, code or the (albeit minor) mission statement, please feel free to email me.

Lou Rosas

Final thoughts

This application was not for practical use. This application was for my own self interest. Unfortunately, that might mean a waste of bandwidth on this blog site, but if the readers don't like it, they don't have to read it. This was for me to chronicle an application (albeit simple) from inception to analysis design and implementation. Finally, for release. This code is registered under the GNU General Public License, so it is by default free. I have no intention of making any money on it. To be honest, I doubt anyone will download it anyway.

But, it was worth it from my point of view, since I have chronicled the steps I normally take when developing an application (at least a small one). This will be very valuable to me: since I can almost guarantee I will reference this site often in my development endeavors.

It looks like everything is complete

As stated earlier, I will post on this blog when the software and source code are uploaded to sourceforge.net.

As for this blog, it looks like the application is complete. It is four months overdue! What should have been done in a week (or even a day for that matter), took far too long. From a practical standpoint, this application should not have even been started--a simple spreadsheet can perform what this application does (and it probably performs it better).

I can't just upload jar files.

It appears I just can not upload jar files! So, I neither will be posting the code nor the executable jar file here. I have placed a request into sourceforge, so when that comes through, I will store the code there, put a link on this blog to both the source and executable. I doubt I will have many downloads, since this was a personal project that took way too long to complete.

Here is the Calculate Distance Window

Here is what the Calculate Distance Window looks like. It is extremely similar to the Calculate Run Time and Calculate Pace Windows. In the end, I should have just created on Generic Calculate Run Stuff class and instantiated three objects from it (or possibly inherited from it).

It is very aggravating when you find a better way of implementation when you are done. Well, that is what experience is for and it is part of "playing the game".

Use Case 5 is complete

Use case 5 was completed sometime ago. This was the use case related to saving run data to a file. It was a learning experience as was (as I predicted) the hardest of all the use cases to set up. But, it is now implemented and appears to be working fine. For this first release, I have no intentions of saving the data to a database. So, for now, the data is saved to a file, and the file is saved in ASCII format so the file can be opened by any typical text editor. I tried to get it to open with a spreadsheet and it does, but the headings at the top of the page are off and it does require the user to manually change the headings to fit on top of the columns where the data is. The data does show up in the correct columns and is columned just fine.

Lots to put in today

I have a lot to put into today. I have not kept up with the blog. Instead, most of my "blog" notes have been kept by hand by my computer. There is a lot to write and I need to get started on it today. Not only will I chronicle the success of the application development, but will put down what I have (re)discovered in making this an executable--since this was written in Java.

The point is, the application is complete. It has been tested (by me). I have requested space on sourceforge.net.

The First Four Use Cases are Complete

After three months, countless questioning and a conviction that I was an idiot for overdesigning this, the first four Use Cases are complete! That's right, a user can NOW enter in data to either determine their pace, run time OR distance ran!

Like I said earlier, it is THREE months past due. What should have been completed over a weekend took this long to complete. I over designed EVERYTHING. From the actual design to the data entry views to the modeling concepts. This whole thing could actually be done in Microsoft Excel with no problem! But I decided to be stuborn and make it more than I probably should. But, in the end, I did learn a lot! To me, as stated earlier in this blog, that was the most important part of the whole thing. That, and the fact that I wanted to blog my development process, if for no ther reason than for archiving a design. I think I will publish this design for myself. I found websites that will aid me in that effort.

Now, it is time to finish the application and complete the Use Cases by developing the last Use Case: the "Save RunData" use case. I fear that use case will be the hardest to develop. I need to learn/refamiliarize myself with Serialization. I also need to determine if I am going to go ahead and set up a database to save the data--or just put the data in a format that can be used by Microsoft Excel (or some other spreadsheet). Also, I do need to go ahead and start the work in the ACTUAL class that I am taking: A Visual Basic Class. So, I will try to split my time more evenly between this project and my class.

Got the Calculate Runtime window to display

I got the Calculate Runtime window displayed!! It took less than half the time the Calculate Pace window took! It looks extremely similar to the Calculate Pace window and that is by design. They essentially do the same thing. Keep in mind, I need to add the functionality to make it work, but at least I got it displayed.

Use Case2 is complete! Now need to focus on Use Case 3. As usual (and sometimes unfortunate) there were changes that were performed that deviated from the design. Those changes need incorporation into the design as part of the design update process. I created a Calculate Pace Window. Every button and Menu Item and Radio button works on it EXCEPT the save button. That is part of Use Case 5. That is the last thing that will need accomplishment and testing: since I honestly believe it will be the hardest thing to accomplish. As part of the Use Case realization, I got rid of the String formatting that is part of Java 6. I put in a "self invented rounding" process that is pretty obvious to anyone that has ever used Java. This was done to make as backwards compatible as possible with Java 1.4.

Now, it is onto Use Case 3. I will start with the GUI and publish online in the current blog.

Pace Calculation Almost Complete

Got the RunData object set up. It even prints out the data (albeit not completely formated). That is the next step. Need to figure out how to format strings in Java.

• Got the PaceCalculator RunData infused into the CalculatePaceWindow: I created the method: displayRunData()
• Now need to test
  • This is what I will do next time!!!

Run Distance and Exceptions created and working

I got the RunDistance object and the RunDistanceException object completed. The calculatePace(...) method in the PaceCalculator object is calculating the pace and storing the answer off in a RunTime object. Using a simple calculation, it appears the Pace Calculation is correct. Now it's time to set up the RunData object. This is going to be a little more complex. This is what the View Package is to interact. I need to determine how to interact with the Date. I am sure there is something online that will set me in the right direction in relation to this subject.

Major part of the Use Case 1 realized

In the first part of getting the Calculate Pace Use Case completed. The RunTime class is complete. This was the first part of the Use Case, and is needed for realization of this Use Case. There are many design issues that changed as a result of completing this class. From the original design, a some of the methodology has changed. This is indicative of starting any implementation on any project. It is best to anticipate any and all problems through adequate and thought out design-following a specific methodology. I have documented my methodology here for the purpose of example and critique: to see where improvements are needed in the development methodology and implementing that methodology. As part of the design, I will need to go back and submit the changes to the Static Class Diagram, as well as the Sequence Diagram. It would be a good idea to post the code, as well: as a contrast between the design and the implementation.

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.

Sequence Diagram for Use Case 1

Here is the Sequence Diagram for Use Case 1. There is not much to it. It would have just as well been served with a collaboration diagram. But, it appears that Community Edition of Magicdraw does not have such a diagram. So this will have to do, unless I want to spend the money to see if the Standard Edition comes with the collaboration diagram.

In reality, this did not need to be published, since it does not show more than the System Sequence Diagram.

Newly updated Static Class Diagram

This is the NEWLY updated Static Class Diagram (at least the first in a series of two). The second Static Class Diagram is just fine, so it will be left alone for future reference. But, since I removed the Runner class and all its associations, I needed to update this Static Class Diagram.

New Design Class Diagram

This is the NEW Design Class Diagram for the Pace Calculator Application.

Changes to the Design Diagrams

After looking at the first interaction diagram, I don't think I need the Runner class! Yes, the original intent of the person class was to identify real world objects, but I think I went overboard with that, since the Runner is the actor!!! That was my mistake. I am going to go ahead and take it out of the Design Class Diagrams and start the interaction diagrams from there. I will update these diagrams, as well as what is on the web.

Thus, I have taken out the Runner and Person classes and updated the design to reflect those changes. I am going to publish the newly updated diagrams when I am done with this blog entry.

Another Static Class Diagram

I have uploaded both Static Class Diagram images. To me, this is a vital first step in the design, since it shows thought on responsibility assignment.

Set up the static diagrams

What is the rational behind the Time Class?

The Time Class needs to allow the input of time in the following formats: HH:MM:SS.ss, MM:SS.ss, HH.hh or MM.mm. Thus, I think it would be best to include methods that can handle such formats. I also think the Class would need to know as much about the time format as possible. This means keeping a decimal format data type stored to indicate how the data was entered: either in HH.hh or MM.mm format. This should also determine how to display the time data in a particular decimal format. Thus, I also think that it would be a good idea to also store a decimal boolean. This would indicate whether or not data should be displayed in as a decimal or in the traditional form.

I think I also should include arithmetic methodologies with the class: the ability to add and subtract different time objects and return a value from that arithmetic operation. I believe these will help to define the type of class the Time class intent.

Design Class Diagram

Here are the classes that I have so far discerned. This is the design class diagram:


Now it's time to write up the methods and attributes related to these classes.

What to do with the Person Class?

What do I want to do with the Person class? That's a good question. Do I want to make it an interface, or do I want to keep an abstract class or, do I just want to keep a regular class? What benefit will it have in the long run? That's another good question. Since everybody emulated in software is-a person, I think it would be best to think of it as an abstract class (at most), a regular class on average. I don't think there is any benefit to making the class an interface. What will a runner bring that a person will not to the design?

Analysis Done, now Design?

What is the next step?

What is the next step of this project development? I think the analysis is complete. It is now onto the design. This means that I need to figure out the of the Software Entities. This is the transition from Analysis to Design. This means that I need to transition from the Domain Class Diagrams to Design Class Diagrams. I have gone through the checklist of Analysis Models, and I have done all the modeling: the analysis is very complete. In fact, it is a little too complete. This is almost a waterfall development cycle, not an iterative development cycle. I don't consider that a problem, sys this project is so small, it would take just a day to complete: in fact, this project really does not need any development documentation. But, since this is a "pet project", it really is just (literally) an academic exercise. Regardless, I will continue.

Onward to design

I intend to use the stereotypes appropriately. From reading the everything that I have, I don't think that should be a problem.

Domain Model Class Diagram

Domain Model Class Diagram

Possible Classes (Real World Objects)

Now from the nouns, try to determine the the classes (Real World Objects), not software entities. From looking at the nouns, I have determined the (possible) objects related to the system. These objects will make up the Class Diagram, which will eventually be used in the design phase of the application development.

From the noun analysis of the Use Case Documentation, I have determined the classes (Real World Objects) to be:

• Pace Calculator
• Runner
• Run Data
• Run Data File (To be saved to a disk)

For notation purposes only, noted attributes are included in the following classes:

• Run Data
  • Time
  • Pace
  • Distance
  • Runner's Name

• Run Data File
  • Run Data
  • File Location
  • Name

Getting the Nouns from the Use Cases (Detailed Description)

From looking at the Use Case Documentation, first look at the nouns. In other words, what are the nouns in the Use Cases? Look at all the Nouns in the Use Cases.
Nouns

1. Runner
2. System
3. Pace
4. Data
5. Time
6. Distance
7. Run
8. Application
9. User (Runner)
10. Computer
11. Calculation
12. File
13. Format
14. Name
15. Location (File)

Now need to figure what's the next step

What will be the next step? This is always the sticky part in OOAD (at least for me). What do I next? What is the next step? Do I take the use cases and try to figure out what the classes (real world objects are?) This is done most easily by determining the nouns from the Use Cases-the Detailed Descriptions. I guess the next step would be to print out the Use Cases and identify the nouns.

This is what I am currently doing now, from there, I will figure out what the are the objects (real world objects, not software entities).

System Sequence Diagram for Use Case 5

System Sequence Diagram for Use Case 5

Using a new UML Diagramming tool

You will notice that I changed diagramming looks. That is because I changed different UML diagramming programs. The new version is MagicDraw community edition. Unfortunately, it is not as "open" as StarUML, but it offers a little more in terms of Sequence Diagram notation (like being able to indicate a return message). It makes diagramming more like what I learned in the UML notation. In other words, MagicDraw is more robust in their diagramming features than StarUML. The current MagicDraw application that I am using is the Community Edition. This is more of an "investigation version", meant to whet your appetite (my opinion) to the application so that you would buy it. The single version is $149.00 a copy. It is duly noted the Community Edition of MagicDraw is not meant for Commercial Use. Since this application is not for profit, rather freeware for anyone to use and download (I will eventually register this with the GPL) I don't think there are any legal issues with using this version of MagicDraw. The only thing I am concerned about is releasing the design diagrams to my blog-over the web. Will I ever buy MagicDraw, that is a good question. The MagicDraw website does not seem too user friendly in terms of trying to buy a Single Version. If I like it, I will eventually buy a version. But, that is a not the current priority, just getting the diagrams out is the current priority.

System Sequence Diagram form Use Case 4

Use Case 4 System Sequence Diagram

Use Case 3 System Activity Diagram

For Use Case 3, I decided to try making an Activity Diagram as opposed to a System Sequence Diagram. From What I have read, and come to understand, this diagram is another means to display the interaction between the Actor and the System at the System level.

Use Case 2 System Sequnce Diagram

Use Case 2 System Sequence Diagram

Use Case 1 System Sequence Diagram

Use Case 1 System Sequence Diagram

The Use Case Diagram

This the the Use Case Diagram for the Pace Calculator Application.

Need to move onto the System Sequence diagrams

With the Use Case Detailed descriptions completed, published and posted, it is now time to move onto the System Sequence Diagrams. This will be done for each Use Case (this may be redundant, since three of the Use Cases are similar, but it needs to be done). The move onto the Class diagram (Analysis Phase). Then figure out what to do from here (possibly the System Activity Diagrams).

Save Run Data Use Case Detailed Description

Use Case Name	Save Run Data
Scenario	N/A
Triggering Event	Runner requests run data is saved.
Brief Description	The runner elects to save the calculated and/or input data. The system saves the data in the requested file..
Actors	Runner
Related Use Cases	Enter Run Data
Stakeholders	N/A
Preconditions	The Application is running, data must be entered. Pace must be entered in MM:SS.ss or MM.mm format. Time of run must be entered in HH:MM:SS.ss or HH.hh format. Distance must be entered in Meters, kilometers or Miles.
Postconditions	Data must be saved in the appropriate file, in the appropriate file format (i.e. a database or spreadsheet).
Flow of Events	Actor	System
	1. Runner enters the appropriate data for saving.
	2. Runner requests the system to save the data.	2. Requests the file name and location for saving the data (or shows the location of the current file where last saved data resides).
	3. Enters the file name and location.	3. Saves the data.
	3.1 Informs the user the data was saved.
Exception Conditions	1. If the runner does not enter any data for saving, then the System informs the user that data is needed for saving: either a) The Time of Run, b) The Runner's Pace or c) The Run Distance.
	2. If the runner enters the time in the wrong format or mis-enters the time, then the System informs the user of the proper format for time entry.
	2. If the runner enters the pace in the wrong format or mis-enters the pace, then the System informs the user of the proper format for pace entry.
	2. If the runner enters the distance in the wrong format, then the System informs the user of the proper format for distance entry.
	3. If the System cannot save the data, then the System informs the user the data could not be saved.

Calculate Distance Ran Use Case Detailed Description

Use Case Name	Calculate Distance Ran
Scenario	N/A
Triggering Event	Runner requests the run distance calculation.
Brief Description	The: 1) Pace in MM:SS.ss or MM.mm format 2) Time of run in HH:MM:SS.ss or HH.hh format is entered into the System.	The System takes the Time, divides it by the pace and returns the distance ran.
Actors	Runner
Related Use Cases	Enter Run Data
Stakeholders	N/A
Preconditions	The Application is running, pace must be entered in MM:SS.ss or MM.mm format. Time of run must be entered in HH:MM:SS.ss or HH.hh format.
Postconditions	Run Distance data must be calculated. Distance is presented in Meters, kilometers or Miles format.
Flow of Events	Actor	System
	1. Runner enters the Run Time and the Pace.
	2. Runner requests the Run Distance	2. Calculates the Run Distance by taking the Run Time and dividing it by the Run Pace.
		2.1 Presents the calculated Run Distance in Meters, kilometers or Miles format.
Exception Conditions	2. If the runner does not enter enough data for the calculation, then the System informs the user more data is needed: either a) The Time of Run or b) The Runner's Pace.
	2. If the runner enters the time in the wrong format or mis-enters the time, then the System informs the user of the proper format for time entry.
	2. If the runner enters the pace in the wrong format or mis-enters the pace, the the System informs the user of the proper format for pace entry.

Calculate Run Time Use Case Detailed Description

Use Case Name	Calculate Run Time
Scenario	N/A
Triggering Event	Runner enters the appropriate data for run time calculation.
Brief Description	The: 1) Distance Ran 2) Pace in MM:SS.ss or MM.mm format is entered into the computer.	The System takes the Pace, multiplies it by the distance and returns the run time of the runner in HH:MM:SS.ss or HH.hh format.
Actors	Runner
Related Use Cases	Enter Run Data
Stakeholders	N/A
Preconditions	The Application is running, pace must be entered in MM:SS.ss or MM.mm format. Run Distance must be entered in Meters, kilometers or miles format.
Postconditions	The Run Time data must be calculated. Run Time is presented in MM:SS.ss or MM.mm format.
Flow of Events	Actor	System
	1. Runner enters the Run Distance and the Pace.
	2. Runner requests the Run Time	2. Calculates the Run Time by taking the Run Distance and multiplying it by the Run Pace.
		2.1 Presents the calculated Run Time in HH:MM:SS.ss or HH.hh format.
Exception Conditions	2. If the runner does not enter enough data for the calculation, then the System informs the user more data is needed: either a) The Distance Ran or b) The Runner's Pace.
	2. If the runner enters the time in the wrong format, then the System informs the user of the proper format for time entry.
	2. If the runner enters the distance in the wrong format, then the System informs the user of the proper distance format (this should be pretty explanatory).

Calculate Pace Use Case Detailed Description

Use Case Name	Calculate Pace
Scenario	N/A
Triggering Event	Runner enters the appropriate data for pace calculation.
Brief Description	The: 1) Distance Ran 2) Time of run HH:MM:SS.ss format or HH.hh format are entered into the System. The System takes the time, divides by the distance and returns the pace of the runner in MM:SS.ss format or MM.mm format.
Actors	Runner
Related Use Cases	Enter Run Data
Stakeholders	N/A
Preconditions	The Application is running, time of run must be entered in HH:MM:SS.ss or HH.hh format
Postconditions	The Pace data must be calculated. Pace is presented in MM:SS.ss or MM.mm format.
Flow of Events	Actor	System
	1. Runner enters the a) Distance Run b) Time of Run
	2. Runner requests the pace to be calculated	2. Calculates the pace by taking the time and divding it by the distance.
		2.1 Presents the calculated Pace
Exception Conditions	2. If the runner enters only one of the two needed data points, the System informs the user more data is needed: either the a) Run Distance or b) The Time of Run.
	2. If the runner enters the time in the wrong format, then the System informs the user of the proper format for time entry.

Enter Run Data Use Case Detailed Discription

Use Case Name: Enter run data

Scenario: N/A

Brief Description: When the application is running, the runner inputs the following data:
1) Distance Ran
2) Time of run
3) Pace

Actors: Runner

Related Use Cases: N/A

Stakeholders: N/A

Preconditions: The application is running

Postconditions: Part of the data used for the appropriate calculation is entered. This means that two of the three data inputs are entered. Either:
a) Distance Ran and TIme of Run
b) Distance Ran and Pace
c) TIme of Run and Pace

Or the data entered for the purpose of archiving selected run data.


Flow of Events: Actor System
1. Runner enteres the
appropriate data for the
required calculation or
archiving.
2. Runner then enters the 2. System calculates the requested
appropriate action, data and presents it to the Runner.
either calculating the: Or, System archives the data and
a) Run Distance informs the Runner the data was
b) Pace archived.
c) Run Time or
archiving data of a previous
run.

Exception
Conditions: 2. If the runner does not entered enough data for calculation, then the System informs the Runner more data is needed for calculation.
2. If the System cannot archive the data, it informs the Runner of the situation, presenting a possible reason why data archiving is not possible.

Use Cases in Brief

Enter Run Data
When the application is running, the runner inputs the following data:
1) Distance Ran
2) Time of run
3) Pace

Calculate Pace
With the application running, the runner inputs:
1) Distance Ran
2) Time of run HH:MM:SS.ss format or HH.hh format
The System takes the time, divides by the distance and returns the pace of the runner in MM:SS.ss format or MM.mm format.

Calculate Run Time
With the application running, the runner inputs:
1) Distance Ran
2) Pace in MM:SS.ss or MM.mm format
The System takes the Pace, multiplies it by the distance and returns the run time of the runner in HH:MM:SS.ss or HH.hh format.

Calculate Distance Ran
With the application running, the runner inputs the following data:
1) Pace in MM:SS.ss or MM.mm format
2) Time of run in HH:MM:SS.ss or HH.hh format.
The System takes the Time, divides it by the pace and returns the distance ran.

Save Run Data
With the application running, the runner elects to save the calculated and/or input data. The system saves the data in the requested file.

The original Pace Calculator idea

The idea behind the Pace Calculator is to allow the "Tech Savvy" runner the ability to record their pace, time and distance for a given run. This is not what gives the Pace Calculator its ability, this is just one of the main options. Rather, there are three main functionalities to the Pace Calculator, all wrapped up into the main ability of the Pace Calculator. The main ability of the Pace Calculator is to calculate:
1) A runner's pace given their distance and time
2) A runner's distance given their time and pace (pretty mundane)
3) A runner's time given their pace and distance (this is an excellent tool in goal setting)

The Pace Calculator can only work well if the runner knows two of the three data points.

In addition, the Pace calculator should offer the ability to record the distance, time and pace of a given run in either a database and/or spread sheet. The runner has the option to input only one data point into the Pace Calculator for saving; no calculation would be possible via the application. If two of the three data points are entered, the pace calculator would calculate the third data point (saving the time, disatnce and pace for a given run). The Pace Calculator would also enter the date of the run entered by the runner.

New project idea

I just finished the Valley of Gold half-marathon, I did better than expected. I was surprised, shocked, emotionally overwhelmed, and very pleased to see people that I know from The rec center at work out there. They were on their bikes and cheered my on as I passed them going in the opposite direction. I don't know if they were there by coincidence, or by design, but it felt great to see them and I was very shocked and humbled that they were able to see me and cheer me on through the last quarter of the run!

My time for this run was 2:02:31 (my time, not the official time). Soon, I will see how accurate I am, but I did better than what I expected to do, so I was very pleased. During the drive home, I thought of a nifty application (for me) that could aid me in determining my pace. In truth, the pace is the only thing I am really concerned about--and it is not all that important. But, it allowed me to come up with a nifty application. I am sure other people have thought of the same thing, but I think it would be a good application to go ahead and create. Since no one reads this blog but me, it is what I would call a "pace meter". A runner would input their time and distance, and the application would calculate the pace. Or, the runner could enter the distance and pace, and the calculator would calculate the time. Or the runner could enter the pace and time (although this seems a little redundant), and the calculator would the distance. In other words, I want to know at most three things when I am running: distance, time and pace. The application I envision is if the runner inputs two of the three data points, and the application calculates the missing data. The application would give the user the option to save off the data in a spread sheet and/or database (for the OCD runners). This would be an excellent option for shoe mileage tracking. It would give me a chance to work on something in my own spare time, and to me, it would be a great application.

Well anyway, something to think about.