Many, many moons ago when I took my first training class in an OO methodology I got the worst advice of my technical career. The context was a Domain Chart (the equivalent of a UML Package Diagram where subsystems are identified). Someone in the class asked how much time one should spend on developing the diagram. The instructor's answer was, "Half a day would be too much."
Today I believe that for a large application the Package Diagram is the single most important diagram in UML. If you screw it up you will pay for it in major ways over and over during the entire life of the application. The Package Diagram defines the most basic structure of the application and it is essential that structure be stable throughout the application life. That structure defines boundaries for requirements allocation, communications, parallel development scope, subject matter cohesion, levels of abstraction, distributed processing, and "firewall" decoupling.
Clear definitions for partition subject matters and precisely defined interfaces are absolutely crucial to parallel development. Years ago the Group VP gave a presentation on a joint project between my division and another one three thousand miles away. The VP was originally from our division and he dropped by to say Hello after the presentation. My greeting was, "Hi, Joe! You do realize you haven't got a prayer in hell of carrying this off, don't you?" There main reason I felt that way was that we had tried the same thing a couple of years earlier with the same division and it had been a disaster because of huge cultural and technical differences.
A year later the product was delivered. It took three days to integrate our piece (~ 250 KNCLOC device driver) into the system on the West Coast and no one from our shop was even there are the time. In other words, it essentially Just Worked. The irony here is that what made it work was good application partitioning. The VP pushed back on us that exactly the sort of partitioning we were currently preaching (we had only recently converted to OO development) was the solution that would allow the different divisions to work largely independently. We defined the subsystems and their interfaces and then went merrily off to build them in an autonomous fashion.
[The real irony here is that the VP was a Hardware Guy, not a Software Guy. He was just a good listener when we extolled the virtues of good application partitioning. He then hoisted us on our own petard and made us practice what we were preaching. (He was also a very smart guy, which is why he went from Rookie Hardware Engineer to Group VP in about fifteen years.)]
Good applicartion partitioning is based on four simple concepts: cohesive subject matters, consistent level of abstraction, client/service relationships, and interfaces. The key lies in getting them to play together properly. Subject matter defines the semantics of the partition. A well defined level of abstraction ensures that objects implementing the subsystem have the same level of logical indivisibility so that peer-to-peer messaging can eliminate heirarchical spaghetti dependencies. Client/Service relationships provide a consistent base for allocating requirements to subsystems. Intefaces provide the same sort of logical encapsulation of subsystem implementations as they do at the class level. One view of an subsystem is that it is a Class on steroids.
These concepts sound good, but putting them into practice is a whole other thing. Subsequent posts to this blog will address each of the Big Four concepts and will offer some practical insights on how to do application partitioning properly.