Almost a year ago now, I released my first iOS apps QuarterMaster Yacht Inventory. Since the release I have continuously found bugs and have attempted to patch the code. Now the bugs have gotten out of hand. While the average user might not find all the bugs, they are apparent to me. The original development of the app followed an unstructured development program. I simply identified a feature I wanted to develop, so I coded it. At the time this was okay because I was new to iOS development, and it was a part of how I learned. 

Just recently, I read a book known colloquially as the Booch Book, or more formally known as Object-Oriented Analysis and Design with Applications by Grady Booch et al. You can get a copy of it here. Unfortunately, I have now had the great idea of redoing QuarterMaster. With this rearchitecture project, I am hoping to achieve a few things. First, I want to make development of an Android App easier. I also hope to fix some of the critical flaws with the current architecture. When I originally made the app, I ended up putting a lot of business logic into the UI, and I believe this is causing many of the issues I have. The rearchitecture will also give me a chance to develop unit tests and UI tests to better identify bugs and speed development by catching bugs when they happen. Finally, cleaning up the code and building better documentation will make it easier to add new paid features to the app. 

This Week

This was the first week of work. I started with creating a Mission, Vision, and Goals for the app. After that, defining the requirements was easy. Finally, I was left with the tedious tasks of developing the Use Cases. 

Mission, Vision, Goals

Every project needs a mission, vision, and goals to guide its development. For the new QuarterMaster app, I outlined the following: 

Mission: 

Providing the tools to organize a vessel’s stores.

Vision: 

To better organize the stores of my user’s pantries, stores, inventories, etcetera.

App Goals: 

1. To be the most recognized boat inventory app by the end of 2023. 
2. To create the highest quality inventory app by the end of April 2023.
3. To make collaborating on inventory easy for everyone.

Project Goals: 

1. Build a new and better QuarterMaster app experience with paid extended features to release by end of April 2023. 
2. Make development of an Android app easier

My mission and vision may not be the most well defined, however I feel this is enough to guide the architecture. For the goals I have split them into two sections, App Goals and Project Goals. I split them like this because there are goals I have for the app, and then there are goals I have for the Rearchitecture Project. The goals are purposively made to be ambitious, if for no other reason to push me. 

App Requirements

The initial development of requirements was probably the easiest part of the entire project. Because this is an improvement on existing architecture, I can start with what the app can already do. I want to focus on only improving existing functionality so the requirements are based on that. Here I start with the constraints of the design. The system requirements start defining the functionality of the app. This list is not exhaustive. As I have worked through and thought about use cases, I have also identified more requirements for the app. I expect to identify more requirements as I continue to develop the architecture. 

Constraints

• Shall operate in the native device SDKs. 
• Shall operate in all ecosystems.  
• Shall be able to connect and share data with devices of different ecosystems. 
• Should use meta programming concepts for data handling. 
• Should be architected with Object Oriented Design principles. 
• Shall work with legacy data. 
• All functions should have equivalent unit tests. 
• UX should include UI tests based on User Stories
• All data shall be stored on local device. 

System Requirements

• User can add, edit, and track items in inventory.
• User can add, edit, and track items in a grocery list.
• User can share data using local network protocols.
• Shall provide data models to track individual items.
• Shall provide means of uniquely identifying items.
• Shall track where items are stored.
• Shall track quantity of items.
• Shall track category of items.
• Shall track units used for counting items.
• Shall provide shopping list for tracking items to buy.
• Shall track when items on grocery list are purchased.
• Shall provide capability to clear purchased items from grocery list.
• Should move purchased items from grocery list to Inventory.
• Shall provide means of sharing data across devices using local networking.
• Shall support holding multiple unique profiles.
• Profiles shall be uniquely identifiable.

Use Case Development

I thought use case development would be quick and easy. However, as I began to break down all the different functionality the app provides, I have come to realize how complex it is. Below in Figure 1 is the use case diagram for the core features of the app. These are also only the use cases of the current app. Later in the development cycle, I plan to add more use cases to capture feature requests. 

The use cases have been partitioned into different packages. Partitioning the use cases this way helps me to keep them organized. Along with the diagram is 4 pages of use case specifications. I have thought about including it in the blog post, but that would be a lot of dry and repetitive reading. Each of the use case specifications follow a general format of Purpose, Optimistic Flow, and Pragmatic Flows containing different error conditions. I am still developing the use case specifications, mostly need to add more pragmatic flows. When I get the core architecture to a steady state, maybe I will create a QuarterMaster Wiki for technical or curious readers. 

Next Week Goals

I am quickly learning to appreciate the difficulty of architecting an app. To put it bluntly, I wish I learned Object Oriented Analysis and Design years ago. While I may take a lot of time planning the app, the coding should go quickly and be easier to check quality because I have also outlined the testing regime at the same time. 

Finish Core Architecture

The big goal for this week is to finish the core architecture of the app. I will be developing activity diagrams to go with each of the use cases. From those I will also develop component diagrams to find the class hierarchy and begin to define class interactions. These component diagrams will then lead into class diagrams that I can use to code the classes. I will also use the activity diagrams to design a new UI that will hopefully work better than what I have now. Towards the end of the week, I will be creating wireframes to model the view objects. I would like to give my app some more individuality with color palates and move away from the spartan Apple design I have now. 

Project Plan for Coding

The architecture will also help breakdown the coding tasks and dependencies will become apparent. In an ideal world this will make planning the coding part of the project a breeze. I am expecting trouble as I move forward. By having the architecture well planned out, I should be able to avoid a lot of the pitfalls I had when I originally built QuarterMaster.