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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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