9 IMPLEMENTATION MODEL  13/11/97

9 Implementation model

UML defines two models which describe how your system is implemented. The component model shows the dependencies between parts of the code, and the deployment model shows the structure of the run-time system: which bits run on which processors.

9.1 Component model

Component diagrams

show dependencies between software components.

A component may be

• source code (some sensible implementation unit of it, e.g. the code for a given class, or perhaps a start-up shell script)

• binary code (e.g. a class library)

• an executable (e.g. a bought-in spreadsheet).

We’ll only consider compilation dependencies (so nothing will depend on an executable, unless it’s a compiler!).

Slide 65

9 IMPLEMENTATION MODEL  13/11/97  9.2 Deployment model

A component diagram

Slide 66

Note This is one of the less stable (or at least, most recently stabilised) areas of UML. You’ll get 3 different views if you read Fowler’s book, the UML1.1 documentation, and the Rose on-line help. I’ve tried to stick to the common core! The main question is whether a package is the same as a component (more or less Fowler’s view) or a more general thing that can contain components (UML1.1 and Rose). Here I take the latter view, and then don’t talk about packages, but only about components!

Fowler’s book doesn’t describe component diagrams as such. He uses package diagrams (a special case of a class model, using the fact – which we didn’t cover in the course – that you can group classes into packages and show dependencies between them) to show dependencies between subsystems.

9.2 Deployment model

Deployment diagram

The deployment diagram shows the relationships between physical machines and processes, e.g. what runs where. Dark boxes represent machines with processing power, light ones represent devices with no processing power. (Grey areas: Xterms?) Lines between boxes represent physical connections between machines. UML’s view and Rose’s are somewhat different – UML allows more detail about what’s where than just processes, but doesn’t distinguish devices from processors.

Slide 67

A Rose-style deployment diagram

Slide 68

Summary of elements of UML

• Use case diagram

• Class diagram

• Behaviour diagrams:

– Interaction diagrams: ∗ sequence diagram

∗ collaboration diagram – state diagram

– activity diagram

• Implementation diagrams:

– component diagram

– deployment diagram

Slide 69

What was it all for?

UML provides a language in which to talk about designs. It doesn’t say anything about how to get the designs. (Compare English: it doesn’t tell you what to say, but you do know whether a sentence is English or not, with some tolerance.) We’ve also talked a little about the development process, which is concerned with how we get designs and programs:

• example Methodology: Objectory

• CRC cards

• design patterns

• module dependencies The rest of the course is about aspects of the development process.

Slide 70