Relax. You've made it through the hard part (pun intended :-) Let's step back from all this low level coding and get the big picture. First, we examine how parts work together in general.
A picture is worth a thousand words. A diagram is worth even more! :-) In the above diagram we have four parts linked up and working together. Note how UHR reduces the abstraction of a part to DK, Services and Links. This is a wonderful simplification and improvement on typical objects, which have only services in the form of methods.
Reflect on the usefulness of thinking in DK, Services and Needs. You're designing a part. What Servcies does it publish? What Needs does it need to accomplish those services? How can it be made maximally reusable by shifting as much policy as possible into DK?
Some parts have no Services, only Needs. For example our PartA has only Needs but still accomplishes useful work. Another example would be a GUI part that emitted user gesture events by calling Services.
Some parts have no Needs, only Services. For example a database part could have Services for adding, updateing, removing and reading. It would be the only part talking to the actual database.
A part's Needs can go unsatisfied and the part can still do just fine. These Needs would have their IsOptionalNeed property set to true, so that any link integrigy checks don't unpset about an unsatisfied need.
Isn't it fun to think in terms of DK, Services and Needs? :-)
Here's how an empty system is created from scratch:
- You add parts to it with Container DK.
- You specify leaf part policy with Leaf DK.
- The system is started by starting the root container.
- Each part in the root is created.
- Then, if the part implements ParamDriven, its ParamDrivenAide is initialized.
- Then, if the part implemtns ServiceClient, its needs are automatically satisfied. This creates Links.
- Then the container's start commands are run in order.
- The system now runs on its own.
The huge advantage of DK is we can treat a part as a black box, and without changing the code inside it, get it's behavior to vary in each reuse case. Think about it. We can reuse a part in thousands of cases, and get it to behave differently in each one. This is the same as having thousands of different parts!!! Better yet, we can use different parts for the same DK, opening the door to easier system version upgrades or various maintenance. This is possible because we have separated policy from procedure.
In the short run an enterprise or industry's biggest investment will be parts. But in the long run it will be DK.
The advantage of Services and Needs is multifold:
1. All part input and output is published, unlike standard classes which publish only input. This makes parts far, far more understandable, and allows their relationships to be handled by something outside of the part.
As we see it, a major shortcoming of OO languages like Java is the failure of a class to publish it's discrete output. Without realizing it, that is the cause of many inefficiencies. It's an incompletely specified contract. You really have only partial knowledge of dependencies. With classes, output cannot be specified or analyzed except at the gross level of imports, without delving into what should remain a black box.
2. Anonymous Collaboration becomes possible, because part relationships can be established outside of parts. If parts set their own relationships, the tendency is for tight coupling. The other half of Anonymous Collaboration is the Service interface, which is relatively easy to make a domain neutral Uniface or Multiface.
3. Automatic hookup becomes possible. Since we have Services and Needs as distinct encapsulated objects, we can in most cases automatically match the desired Service with a Need. This takes a 500 pound weight off the shoulders of whoever is assembling a system. It's like every time you use a part, there's 1ots of lines of code you don't have to write because you don't have to specify relationships.
4. Optimized hookup becomes possible. Not only is it possible to satisfy a Need automatically, we can optimize the satisfaction by searching for the best Service available. It becomes easy to design framework layers that perform such wonders as relinking if a better Service is added to a system. It becomes easy to use a matching algorithm that rates Services based on ratings per Need attribute. Etc, etc.
5. A system design can be automatically analyzed for relationship integrity. It becomes easy to write a tool that walks a System Tree and check for needs that cannot be satisfied.
6. New parts can be designed on the basis of Services and Needs. As a system is being assembled, if a necessary part cannot be found in the Part Inventory, a "Stub Part" can be defined with DK to fake the Services and Needs the part slot must have. The incomplete system can be analyzed for relationship integrity using the Stub Part. The Stub Part can be given to the Part Shop as an order for a new part.
7. The emergent property of Links becomes possible. Links can be traversed, animated, analyzed, re-routed, etc. The designer's pallet suddenly becomes so rich with color that entirely new things become possible.
Go to the next lesson.