Course Teacher

Assistant Professor
Engr. Mustafa Latif

CASE STUDY
CAD/CAM PROBLEM

1
CAD/CAM System
 CAD/CAM system to make drawings of sheet-metal parts. Figure 3-1
shows an example of one of these parts.

Figure 3-1 Example of a piece of sheet metal.

Task
 Write a computer tool to extract information from the CAD/CAM
System so that an expert system could use it in a particular way. The
expert system needed this information to control the manufacturing of
the part. Because the expert system was difficult to modify and would
have a longer lifespan than the current version of the CAD/CAM
system, we wanted to write the information-extracting tool in such a
way that it could easily be adapted to new revisions of the CAD/CAM
system.

2
 Understand the Vocabulary

Table 3-1 describes the types of features that may be found in a piece of sheet metal.
These are the shapes the system must address.

3
Describe the Problem

4
Problem
 We need to design a program that will allow the expert system to open
and read a model containing the geometry of a part that we want to
analyze. The expert system will then generate the commands for the
numerically controlled (NC) machine to build the piece of sheet metal.
 At a high level, we want the system to perform the following steps:
 Analyze pieces of sheet metal.
 See how they should be made, based on the features they contain.
 Generate a set of instructions that are readable by manufacturing equipment.
This set of instructions is called an NC set.
 Give these instructions to manufacturing equipment when we want to make
any of these parts

Problem
 Challenge: Allow the expert system to work with a constantly changing
CAD/CAM system

Figure 3-5 High-level view of my solution.

5
Problem
 High-level class diagram

Figure 3-6 Class diagram of my solution.

Problem
 CAD/CAM systems Version 1; is essentially a collection of subroutine
libraries. To get information from a model, a series of calls must be
made. A typical set of queries in CAD/CAM Version 1 would be as
follows:
1. Open model XYZ and return a handle to it.
2. Store this handle as H.
3. For the model referred to by H, tell me how many features are present; store
as N.
4. For each feature in the model referred to by H (from 1 to N)
1. For the model referred to by H, tell me the ID of the ith element and store as
ID.
2. For the model referred to by H, tell me the feature type of ID and store as T.

3. For the model referred to by H, tell me the X coordinate of ID and store as

X. (Use T to determine the proper routine to call, based on type.)

6
Problem
 CAD/CAM systems Version 2 is object-oriented. Therefore, in V2, we
can get a set of objects that corresponds to the features that exist in the
sheet metal.

Figure 3-7 Feature classes of V2.

A Standard Object-Oriented Solution

7
Solution
In thinking how to solve this problem, we reasoned that if we can solve
it for slots, we can use that same solution for cutouts, holes, and so on.
In thinking about slots, we saw that we could easily specialize for each
case. That is, we would have a SlotFeature class and make a derivation
from SlotFeature when we had the V1 system and another derivation
when we had a V2 system. This is shown in Figure 4-1.

Figure 4-1 The design for slots.

Solution
 We complete this solution by extending it for each of the feature types,
as shown in Figure 4-2

Figure 4-2 Original solution to the problem of extracting information.

8
Solution
 Figure 4-2 is pretty high level. Each of the V1xxx classes would communicate
with the corresponding V1 library. Each of the V2xxx classes would
communicate with the corresponding object in the V2 model.
 V1Slot would be implemented by remembering the model it belongs to and
its ID in the V1 system when it is instantiated. Then, whenever one of the
V1Slot methods is called to get information about it, the method would have
to call a sequence of subroutine calls in V1 to get that information.
 V2Slot would be implemented in a similar fashion, except that, in this case,
each V2Slot object would contain the OOGSlot object corresponding to it in
the V2 system. Then, whenever the object was asked for information, it
would simply pass this request on to the OOGSlot object and pass the
response back to the client object that originally requested it.

Solution
 Figure 4-3 is a more detailed diagram incorporating the V1 and V2
systems.

Figure 4-3 A first solution.

9
Problem
 Imagine what will happen when the third version of the CAD/CAM system
arrives. The combinatorial explosion will kill us! Look at the third row of the
class diagram in Figure 4-3:
 There are 5 types of features.
 Each type of feature has a pair of classes, one for each CAD/CAM system.
 When we get the third version, we will have groups of 3, not groups of 2.
 Instead of 10 classes, we will have 15.
 Imagine what will happen if something else varies. Right now, we are handling
two variations (what kind of feature we have, and also which system, V1 or V2,
holds its data), and so the number of classes we have is the number of features
times the number of systems. If we get another variation to handle, this whole
approach is going to quickly get out of hand.

Thinking in Patterns

10
Thinking in Patterns

Figure 13-1 High-level view of the solution.

11
 The Process of Thinking in Patterns
1. Identify the patterns. Find the patterns in the problem domain.
2. Analyze and apply the patterns. For the set of patterns to be analyzed,
perform steps 2a through 2d:
2a. Order the patterns by context creation. Order the patterns according to how they
create context for each other pattern. The idea is that one pattern will create a context
for another, not two patterns co-creating contexts for each other.
2b. Select pattern and expand design. Using your ordering, select the next pattern in
this list and use it to create a high-level conceptual design
2c. Identify additional patterns. Identify any additional patterns that might have
come up during your analysis. Add them to the set of patterns to be analyzed.
2d. Repeat. Repeat for the sets of patterns that have not yet been integrated into our
conceptual design.
3. Add detail. Add detail as needed to the design. Expand method and class
definitions.

 Thinking in Patterns: Step 1

1. Identify the patterns
Abstract Factory
Adapter
Bridge
Facade

12
 Thinking in Patterns: Step 2a
2a. See which one creates the context for the others

Figure 13-2 Different possible relationships between the patterns.

 Looking for context is an essential tool to add to your bag of analysis

and design tools. Deciding on which pattern creates the context for
which is often assisted by looking at the pattern conceptually. For
example:
 The Abstract Factory pattern creates sets of related objects (families).
 The Adapter pattern adapts an existing class A to the interface needed
by a using class B.
 The Bridge pattern allows for different implementations to be used by
a set of related using objects (concrete classes of the abstraction in the
pattern).
 The Facade pattern simplifies an existing system A for a using class B.

13
 We can reject the Abstract Factory as the topmost pattern as is use to
organization (the families) of the objects it is creating. Therefore, other
patterns must be creating its context and it will not be first on the list.
Abstract Factory will be the last pattern. (Rule: Consider what you need
to have in your system before you concern yourself with how to
create it.)
 There are three pairs of patterns left to consider:
 Adapter–Bridge
 Bridge–Facade
 Facade–Adapter

 Adapter–Bridge
 The Adapter pattern is about modifying the interface of a class into
another interface that the client is expecting. In this case, the interface
that needs adapting is OOGFeature. The Bridge pattern is about
separating multiple concrete examples of an abstraction from their
implementation. In this case, the abstraction is Feature and the
implementations are the V1 and V2 systems. It sounds like the Bridge
will need the Adapter to modify OOGFeature’s interface; that is, the
Bridge will use the Adapter.
 Thus, the Bridge pattern creates the context for the Adapter pattern. We
can eliminate the Adapter pattern as a candidate for seniormost pattern.

14
 Bridge–Facade and Facade–Adapter
 We will be using the Facade pattern to simplify the V1 system’s
interface. But what will be using the new interface we create? One of
the implementations of the Bridge pattern.
 Therefore, the Bridge pattern creates the context for the Facade. The
Bridge is the seniormost pattern.

Thinking in Patterns: Step 2b

2b. Select pattern and expand design

Figure 13-3 High-level view of system.

15
Figure 13-4 The classes to generate the NC set.

Figure 13-5 The Model design.

16
Figure 13-8 The generic structure of the Bridge pattern.

Figure 13-9 Applying the Bridge pattern to the problem.

17
 Thinking in Patterns: Step 2c
2c. Identify additional patterns
 Looking at Figure 13-9, There is only the challenge of hooking the
V1 and V2 CAD/CAM systems into the design. That is what the
Facade and Adapter patterns will do for me. So there is no
additional patterns exist.

 Thinking in Patterns: Steps 2a and 2b Repeated (Facade)

 Next we need to verify whether any of the remaining patterns create a
context for each other. In this case, Facade and Adapter now clearly
relate to different pieces of the design and are independent of each
other. Therefore, we can apply them in whatever order we choose. We
will arbitrarily pick the Facade to apply next, which results in Figure
13-10.

18
 Figure 13-10 After applying the Bridge and Facade patterns.

 Thinking in Patterns: Steps 2a and 2b Repeated (Adapter)

Figure 13-11 After applying the Bridge, Facade, and Adapter.

19
  Thinking in Patterns: Steps 2a and 2b Repeated (Abstract Factory)
This pattern is not needed. The rationale for using an Abstract Factory
was to ensure that all the implementation objects were of type V1 if we
had a V1 system or of type V2 if we had a V2 system. However, the
Model object itself will know this. There is no point implementing a
pattern if some other object can easily encapsulate the rules of creation.

 Thinking in Patterns: Step 3

3. Add detail as needed to the design. Expand method and class definitions
 The Abstraction class (Feature) and all of its derivations (SlotFeature, HoleFeature,
and so forth) contain no implementation information. Implementation information
is left to the Implementation classes. This means the Feature subclasses will have
methods such as getLocation and getLength, whereas the Implementations will
contain a way to access this required information. A V1Imp object, for example,
would need to know the ID of the Feature in the V1 system. Because each Feature
has a unique ID, this means there will be one Implementation object for each
Feature object. The methods in the V1Imp object will use this ID to ask the
V1Facade for information about the object.
 A comparable solution will exist for the V2 implementations. In this case, the
V2Imp objects will contain a reference to the OOGFeature in question.

20
Comparison with the Previous Solution

Figure 13-12 This was the first solution.

Comparison with the Previous Solution

 The diagrams visually show inheritance (the is-a relationship) and
composition (the has-a relationship).
 In the first solution, we had a model that contains Features.
Features are either slot features, hole features, cutout features,
irregular features, or special features. Slot features are either V1
slots or V2 slots. V1 slots use the V1 system, whereas the V2 slots
use OOGSlot. Hole features are either V1 hole features or V2 hole
features. V1 hole features use the V1 system, whereas the V2 hole
features use OOGHole.

21
 Comparison with the Previous Solution
 Now read the latest solution. We have a model that contains
Features. Features are either slot features, hole features, cutout
features, irregular features, or special features. All features contain
an implementation that is either a V1 implementation or a V2
implementation. V1 implementations use a V1 Facade to access the
V1 system, whereas V2 implementations adapt an OOGFeature.
 What will happen in each design when the anticipated V3 system
comes out. In the previous design, we would have to derive a new
slot, hole, and so on for the new system. In the current design, we
just create a new adapter (assuming V3 will be object oriented).

Commonality and Variability Analysis

22
Commonality and Variability Analysis
 Commonality and Variability Analysis (CVA) use to develop a high-
level application design. In Which we identify variation in our system
using CVA and then follow the lessons of design patterns (program to
interfaces, encapsulate variation using aggregation) to create designs
that are flexible and easily testable.

Commonality and Variability

Analysis
Steps
 Identify commonalities first.
 Create abstractions from these.
 Identify derivations with the variations of the commonalities.
 See how the commonalities relate to each other.

23
Solving the CAD/CAM Problem with
CVA
 When analyzing the problem domain with CVA, We want to see what
concepts are there and then try to organize these pieces as cohesively as
possible. Remembering the CAD/CAM system, there are
 Different CAD/CAM systems—V1, V2. In this situation, these are
essentially read-only, proprietary databases that will provide the
numeric control sets the expert system needs to do its work.
 Different kinds of Features—Slots, holes, cutouts, special and
irregular.
 Different kinds of Models—V1-based and V2-based.

Pick any two items in the problem domain and ask the following
questions:
 Is one of these a variation of the other?
 Are both of these a variation of something else?

24
 Table 15-1 Commonality and Variability Analysis Table

Figure 15-1 The relationship between commonality and variability analysis, perspectives, and abstract classes.

25
 The information in Table15-1 can be translated into three different class
hierarchies by following the guidelines laid out in Figure 15-1. These are
shown in Figure 15-2.

Figure 15-2 Translating CVA table into classes.

 The next step involves determining how the concepts relate to each other.
Models contain Features and Features are extracted from the CAD/CAM
system.

Figure 15-3 Our class diagram showing relationships between the classes.

26
 Do we want to have different types of models or have one type of model that
uses the different CAD/CAM systems through the CADCAM interface? In
other words, if we move the methods in V1Model and V2Model that are
peculiar to the CAD/CAM system into the CADCAM class hierarchy, we can
probably avoid having different types of Models.

Figure 15-4 Handling variations in Models by using the CADCAM classes.

 We still need to expand the design to relate the CADCAM classes to the actual
V1 and V2 implementations. Recalling what we know about the Facade and
Adapter patterns, it should be clear that V1CADCAM should simply be a
facade to the V1 system while V2CADCAM should wrap (adapt) the V2
system (OOG_Part). This is shown in Figure 15-5.

Figure 15-5 A completed design.

27