Comprehensive Guide to the Problem Domain Component in Object-Oriented Design

1. The OOD Process - I The Problem Domain Component (PDC) [Coad/Yourdon]

2. Object-Oriented Design“Steps” of the Process: PDC OOA Model OOD Process OOD Model OOA

3. The OO Co-DesignProcessThe Problem Domain Component extend HIC TMC PDC DMC high-level Design Miniworld refine & map detailed Design

4. PDC - What is it? • OOA results fit right in • “domain oriented design” • further elaboration of OOA results • work out details of analysis • refine and map OOA results to infrastructure • algorithms • data structures • refine and design structural links • manage keys • etc.

5. PDC - What is it? • do NOT adapt OOA to fit your design • changes must be checked by the customer • however, check also into cost and feasibility • adapt your design to fit OOA (the domain) • choose the right architecture • utilize a compatible infrastructure • OOA results guide this selection process

6. PDC tasks • group PDC classes together • establish common protocols • reuse design and programming classes • accommodate supported level of inheritance • support the data management component • add lower-level components/objects • fine-tune your design

7. PDC tasks - group and establish protocols • keep OOA results together • group your mini-world • establish a root for the PDC • establish common protocols • similar behavior that is used by (all) PDC objects • e.g. copy, save, specialized creates, ... • additional class or into the PDC root • depends on the level of inheritance in your infrastructure

8. PDC tasks - reuse design and programming classes • map to your infrastructure • fit into the predefined class hierarchy • find classes that fit your needs • specialize them if necessary • adapt your PDC objects • move attributes and services as necessary • revise structures (move?) • no change in semantics of OOA results

9. PDC tasks - accommodate supported level of inheritance • map to your infrastructure • multiple, single, no inheritance • heuristics how to cope • adapt your PDC objects • revise the structures • flatten out (no inheritance) • add “role” objects (single and no inheritance) • no change in semantics of OOA results

10. Person Person 1,N Role 1,1 Owner- Person Clerk- Person Clerk- Role Owner Role multiple to single inheritance Owner- Clerk- Person

11. Person multiple to no inheritance Owner- Person Clerk- Person Owner- Clerk- Person Owner- Person Clerk- Person Owner- Clerk- Person

12. PDC tasks - support the data mgmt component • map to your data management design • how do you “save” an object • each by itself • by a (set of) data manager objects • adapt your PDC objects • add an attribute to identify the object class • add a service that saves the object • no change in semantics of OOA results • design according to your supported level of inheritance

13. PDC tasks - add lower level components • “factoring” of the OOA results • fit into the predefined class hierarchy (reuse) • accomodate intermediate results • encapsulate problem areas • adapt your PDC objects • move attributes and services as necessary • revise structures (move?) • no change in semantics of OOA results

14. PDC tasks - fine-tune your design • combine classes (as necessary) • strong dependence • high traffic • grouping of objects which are mostly used as sets • add derived attributes (as necessary) • see DBMS disscusion on this topic • simplify scenarios • internal simplification • check with customer

15. Do not modify to reflect team assignments. • Check against your OOA results.