After a little pause I´m now back at exploring the world of O/R Mapping. However, when looking back at my first steps so far I´m in doubt if I want to continue in the same way. Up to now I approached O/R Mapping in general and OpenAccess in specific in a pretty generic way. I tried to get it up and running with just any simple enough code. My approach was pretty theoretical. But when I look ahead I don´t know whether I can or even should continue to try to understand how to use O/R Mapping by keeping my theroretical glasses on. It would mean I pick some concept like polymorphism or inheritance or stateless business logic and try to find out, how O/R Mapping fits it. Just the ordinary textbook approach, isn´t it? One topic after another would be covered. But a blog is not a textbook.
So my idea is, not to try to be comprehensive with regard to O/R Mapping, but close to every day practice. Less theory, more real life. Maybe then I won´t visit each and every detail of OpenAccess during my exploration of O/R Mapping, but whatever feature I stumble upon would be more relevant to me (and hopefully to you too). Learning works best when immediately applying new knowledge to some real world scenario. That´s why I want to continue my exploration by building a real program for a sample scenario. The problem domain is not difficult to understand, but my guess is, it will provide for quite some adventures in "OpenAccess land".
The program will need to access a database and I want to experience, how to best do that using an O/R Mapper. The focus of my articles in this blog thus of course will be on those parts of the software having to do with data access or persistent objects. But other aspects of software development might also find a mentioning here or there. As stated in an earlier post, I´m very interested in learning what effect O/R Mapping has on software architecture, for example. I want to put architecture first and hope OpenAccess will fit in.
The sample scenario
As a sample scenario I´ve chosen a problem a friend of mine, Vera, approached me with recently. She got started with a psychotherapeutical training an now needs to learn a whole host of facts and definitions like "What´s the lifetime prevalance of an axiety disorder?" or "Name the first rank symptoms of schizophrenia according to Schneider" or "What does depersonalisation mean?". In order to memorize all this she wants to use a Learnbox which is a tool for space repetition learning. Here´s a picture of how such a Learnbox works:
- You write whatever you want to learn on index cards. A question on one side, the answer on the other side.
- You set up a Learnbox like depicted: It´s a box divided into 5 partitions (or compartments), each able to hold an increasing number of index cards (e.g. 20, 60, 180, 540, 1620).
- You start learning by filling partition #1 with index cards.
- Then take them out one after another and see if you know the answer to the question on the index card. If you know the answer, insert the card into partition #2. If you don´t know the answer, put it back into partition #1 after the last card.
- This way work your way through the index cards in partition #1 until none or maybe just 2 or 3 are left.
- Fill up partition #1 with new index cards and go back to step 4.
- Repeat steps 4 to 6 until partition #2 is full, then work on the index cards in partition #2.
If you replace the partition numbers in the above description with n and (n+1), then you get the general algorithm for working with a Learnbox. Try it for yourself with vocabulary on some subject you´re interested in! It works. It´s fun.
My friend is perfectly happy with this technique - but she would like to share her index cards with fellow students. Also she would like to get rid of the necessity to carry around a physical Learnbox. Rather she would like to learn online or using a desktop program. That also would make it easier to exchange index cards with her fellow students: no rewriting needed, instead she could send them a file.
I think, that´s a great idea. Of course I could point her to a number of implementations (see section "Commercial Software" here for example) - but rather I´d like to help her myself. I think this scenario is realistic, not too difficult, not too simple, and allows for some interesting features. And of course it needs a database which I can access using OpenAccess.
A first shot at the requirements - th data model
Although I´m very excited to have found some practical/useful sample scenario for my O/R Mapping exploration and would like to start VS2005 right away, I think first some thinking is in order. What are the exact requirements? What´s the datamodel, how should the persistent classes look like?
Let´s start with the tangible stuff, the data. We are talking about Learnboxes with compartments filled with index cards. So how about an object data model like this:
I imagine there to be many LearnBox objects each containing a number of Compartment objects each containing a number of IndexCard objects. Sounds reasonable, doesn´t it? Since a LearnBox and its Compartments belong together their relationship is that of an aggregation; each Compartment, though, is just associated with its IndexCard objects.
IndexCards don´t exist on their own, though. I imagine them coming in sets: a set of index cards for learning French, another for learning psychotherapeutical terms, another one for math etc. Each LearnBox thus is an "instanciation" of such a set of index cards or is associated with a set, and the index cards in the compartments all belong to this set. This leads to a slightly more elaborate object data model:
A LearnBox knows its CardSet, but the CardSet does not know all LearnBoxes it´s associated with, I´d say. Also, when a CardSet is deleted, all its IndexCards are deleted, too. Hm... should a user be allowed to delete a CardSet while it´s in use by a LearnBox? Should she be able to delete an IndexCard from a CardSet while it´s associated with a Compartment? I don´t know yet. I guess it depends on whether a LearnBox directly references IndexCards of a CardSet or contains copies of them of its own. The UML drawing does not reveal such detail yet. I´ve to think about this detail for a moment...
The data model is just one side of a software´s medal. The other side are functional requirements. What´s the software supposed to do? What does Vera expect from the software?
- I think, she wants to start with managing card sets. She needs to be able to create a new card set, list all card sets she already created, delete a card set, edit a card set. The usual CRUD functionality.
- Editing a card set means altering its properties (e.g. its name) and its content. The content of a card set are its index cards. So she needs to be able to add, delete, alter index cards and list all index cards in the card set. Again the usual CRUD functionality.
- Once she has created and filled a card set she surely wants to memorize its content. So she needs to be able to "derive" a Learnbox from a card set. If she is into studying several topics she most likely wants to be able to manage several Learnboxes at the same time. So she needs to list them, delete them, and alter them.
- When altering a Learnbox or specifying it upon creation means specifying the number and sizes of the compartments and maybe also arranging the index cards. Maybe she wants to learn them in a certain order. Hm... that would necessitate an addition to the data model, I guess (see picture below).
- Finally Vera wants to just learn. She wants to pick up a Learnbox and be presented with index cards from some compartment. How index cards move through the Learnbox is controlled by some business logik behind the scenes; Vera should not be able to (easily) interfere with this.
In order to track the position of an IndexCard within a Compartment, an IndexCard is represented by an Item within the Compartment. Items of course "go down" with their Compartment.
Ok, that´s it, I guess. Reasonable requirements for a first release of my Learnbox software. A lot of CRUD functionality seems to be the right scenario for employing an O/R Mapper - and close to many real world applications. But before I start with the implementation, I need some larger picture of the code. I need some architectural framework to locate the data model in. Stay tuned for my next article - and maybe think about how you would model such an application.