The Lost Art of Object-Oriented Analysis and Design

Yesterday, we concluded the first run of our fully-revised course on Object-Oriented Analysis and Design, with UML and GRASP Patterns. This was the product of two weeks of research and writing by O&B's VP, Lorenzo Dee. The target audience is business analysts, with minimal or no programming background, though we believe the material is also pretty useful as an introductory training course for new Computer Science grads, as a way to bridge their programming knowledge with the needs of the real world.

Besides writing from his and the company's collective experiences, he also referenced "Applying UML and Patterns" by Craig Larman, "Analysis Patterns" by Martin Fowler, "The Data Model Resource Book" by Len Silverston, and "Data Model Patterns" by David Hay, with Larman's book being the main reference.

Let me tell you how this course came about:  We felt that while Object-Oriented Programming was fairly discussed in school, and that while our developers received good training on Object-Oriented Design, we felt that the part in the middle - the Analysis, was missing. Throughout the industry, business analysts are often reduced to just documenters of requirements, and then they just hand over their documents to developers with very little input on design. Developers then take the requirements and then implement them however they wished, often with little regard to properly modeling the business domain that the system is supposed to automate.

Why does this matter? Initially, when codebases are small, it's not noticeable - the code that the developers write is not immediately traceable to the business domain, but that's ok because there's not much yet. When a business user talks about a bug or a change, the developers can still figure out where in the code the change has to be done because there's not much code to look through.

However, as the codebase grows to the size of any normal business system, the translation from business domain to implementation domain (the code), gets harder and harder and longer and longer. The developers have more code to read through, and it's not obvious which code implements which business operation. When a business users says something like, "there's a problem with the 'fund transfer' operation", or "we would like to change the 'seat booking process'", the developers have to read through thousands of lines of code figure out which parts of the code actually do that logic. So as a system grows, you will notice that bugs are taking longer and longer to fix, and new requirements are taking longer and longer to implement, to the point that the whole pace of change crawls to a near-standstill. Not to mention the cost of implementing changes skyrockets! And, it's so hard to bring onboard new developers to the team!

The solution here is to have developers build a rich "Domain Model" in their code, so that the code is a reflection of the real-world business domain. This means that the development team needs to have a strong analysis practice, as much as a strong programming practice. I'm not saying that these have to be separate people - many good developers are also good business analysts - but in order to make sure that developers maintain the discipline of implementing a rich, descriptive domain model (it's not easy to do), a dedicated, disciplined and well-trained business analyst is a good addition to the team; not just someone who can document requirements, but someone who can assert himself/herself in making sure that the business domain is properly modeled in the code.

With this in mind, the course that Lorenzo put together starts with breaking down of Use Cases into various UML representations. We also pointed to various references on established industry data models, so that the analysts would not be reinventing the wheel with each project. As much as half of a domain model can be adopted from existing, well-established data models. One of the best references here is  "The Data Model Resource Book" by Len Silverston.

A little caution here - we did not recommend creating full-blown class-diagrams and sequence diagrams right away. Rather, as Craig Larman recommends, we took them through various evolutions of modeling the business domain, with more and more detail with each evolution, and then only later on starting on the act of design, which meant for us the assignment of various behaviors to various parts of the system, using the GRASP patterns as a guide.

Emphasis was made to note that while we went through the full rigor of multiple steps from analysis to design, we needed to take this discipline within the context of Agile Software Development. As Larman would recommend, analysis and design are not big, upfront activities, but rather small activities of analysis and design are done throughout each iteration. Also, while the full rigor of the practice is discussed in the course, it is emphasized that with experience, the business analysts (and developers) will be able to do most of this rigor in their heads, and the time it takes to do analysis-to-design would be hours instead of days or months.

This first run opened up a lot of very insightful discussions with the attendees, most of which were seasoned business analysts, project managers and developers. Looking forward to more runs of this class and having more of these engaging and thought-provoking discussions!