(net time: 624 min)

     I did fast for the use case diagram and the domain model class diagram, but I spent way more time on use case brief description. This is partially because I found more problems in my original analysis when I try to write down a rough idea into description. Whenever I feel difficult in writing use case brief description, I may have to modify the use case diagram and the domain model class diagram. In my original analysis, the location information can be defined as a string of any combination of characters. This is easy for entry validation. However, it may cause problems when searching vehicle location information. What if a user misspells and creates two strings for the same location? Vehicles may be shown in two locations which may confuse users. Finally, I add a location class in the domain model class diagram and show existing locations which are matching user’s input in the use case brief description. I hope this can solve the misspelling issue, but I feel that more revision may be needed in the following stages.

     After I finished this assignment, I’ve learned some new tools which are useful to software analysis and design. In most of my past programming experience, I write immediately once I have an idea. Each iteration is so short that only a small function is included. Normally the function has to be tested before the next iteration begins. The program grows gradually after each iteration and may finish after dozens of iteration cycles. Although I don’t use the model and diagrams, I have adopted those ideas. I don’t draw the use case diagram, but I write down use case brief description, divide them into different sub-system and tackle with them one by one. I don’t draw the domain model class diagram, but I create classes directly with programming language and define attributes with variables. I also draw a brief activity on paper to help me communicate with business owner and build methods and program structure.