Subject: Choosing subsystems and analysis classes

> I am having some difficulty in choosing the level of
> granularity for identifying subsystems. In your
> analysis of potential actors in the requirements
> document, you mentioned the GPS unit, the track and
> detect sensors, as well as the identify sensors as
> three distinct breeds of sensors. These are not
> included as actors in your use case diagrams and
> scenarios. I therefore conclude, 
> that they should be considered part of the IDVTCS 
> we are to design. Since they are different, I could
> conceive of each one having its own subsystem;
> alternatively, I could think of a single subsystem
> and the three types of sensor interfaces being
> generalizations of a common parent. Are there 
> heuristics that I could use to choose between them?

Actually, they are specializations of a common parent.  The parent is the
generalization.  We will be discussing design patterns and heuristics for these
design choices in later classes.  In this case, the requirements do not
distinguish them in sufficient detail for them to merit separate subsystems.

> In trying to identify the objects that need to be shown 
> on the sequence diagrams, I think I need to do some
> preliminary analysis. The other alternative would be
> to identify these entities as instances of the 
> subsystems we've identified. Am I missing something?

Subsystems are not classes, and they do not have instances.
You need to identify analysis classes separately from subsystems.

> I made an attempt at identifying boundary objects.
> The IDVTCS is a little different from the examples
> in the book in that the "border" is really a software
> interface and all actions by the actor will be 
> "messages" or API method calls. Is this a valid line 
> of reasoning?

Yes.