Candidate Architecture 3

9/17/99 - Jack Harich - Go Back

---

Discussion

This architecture uses the "Core Variations" idea and rationale discussed in Business Considerations. For reference, here are the variations:

The goal is to offer the developer different cores so they can pick the one that suits them best. A challenge is to design these cores for seamless conceptual integrity, because they are upwardly compatabile and share some of the same core parts. We expect addtional core variations.

---

Minimal Core

Note the three partitions and the clear responsibilities. Each interface does one thing and does it well. This allows greater reuse and extendibility. It also makes the whole thing just plain simple.

Note the use of "part" to signify the class instance in a Node that provides the functionality for that node. This is an improvement over candidates 1 and 2, reflecting the way users talk.

Actual methods will vary considerably from this first quick pass.

The CellReader needs a way to filter parts, to avoid exposing core parts to domain parts. One way to do this is some filter properties.

No prototype of this has been done. It would be straightforward, building on the first prototype. It's more beneficial to design the other variations first. By then we may be into synthesis with Steve's work....