Unified Modelling Language-Software Engineering-Lecture 18 Slides-Computer Science, Slides of Software Engineering

Download Unified Modelling Language-Software Engineering-Lecture 18 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity!

LECTURE 18: UML

Software Engineering

1 What is UML?

• In the mid 1980s, a number of techniques began to emerge for object-oriented-analysis and design.
• Examples: - Coad & Yourdon; - Booch; - Rumbaugh (the OMT technique); - Coleman (FUSION).
• All used similar techniques, but differed on details of notation, etc.
• Mid 1990s: a move towards standardisation, driven by the Object Management Group (OMG):

The Unified Modelling Language (UML).

• UML is essentially a notation, and not a technique. Notation can be used in many different ways: we show one.

3 Use Cases

• Use cases are a narrative + graphical document that describes the sequence of events of an actor using a system to achieve some particular goal.
• Use cases document system behaviour from the actor’s point of view.
• By “actor” we mean either person interacting with system, or some other system.
• Use cases are useful in requirements capture and validation.

3.1 Schema for Use Cases

• Use case:

[name of use case]

• Actors:

[list of actors that can participate, naming the initiator, and indicating key player]

• Purpose:

[one-line summary of purpose of the activity]

• Overview:

[short summary of the use case]

• Type:

[primary or secondary, essential or optional]

• Cross references:

[references to requirements document]

• Course of events:

[narrative summary of use case]

• Course of events:

1. Customer arrives at checkout with items.
2. Cashier records identifier of each item.
3. As each item is recorded, system responds with running total of cost of items.
4. Cashier indicates to system that there are no more items.
5. System responds with overall total cost of items.
6. Cashier takes cash payment from customer for total cost, and indicates this to system.
7. System prints receipt for amount tendered.

• We use use case diagrams to document the participants in use cases:

• Identifying use cases: - identify the actors involved in a system or organisation; - for each actor, identify the processes they initiate or act in; - refine processes into use cases;
• Common mistakes with use cases: - making them too small; - identifying parts of activities, rather then entire activities.

4 Conceptual Models

• The next stage in UML development involves identifying the key concepts in the system, and documenting the relationships between these concepts. The resulting conceptual model will evolve into the object model.
• A conceptual model documents: - the concepts in a system; - relationships between concepts; - attributes of concepts.
• Conceptual models are not design models.

So avoid such concepts as:

- “database”; - “GUI” or “window”;

• Key distinguishing feature of OO development:

Understanding system in terms of concepts rather than functions.

- other systems

e.g., www site

- abstract noun concepts

e.g., hunger

- organisations

e.g., sales department

- events

e.g., robbery, death

- processes (sometimes)

e.g., deposit

- rules and policies

e.g., refund policy

- catalogues

e.g., parts catalogues

- contracts & legal documents

4.1 Relationships

• In addition to recording the concepts, we must record the relationships between concepts.
• For example, the concepts student and course may be related by is registered on, i.e., a student is registered on a course.
• Generalisation is a special type of relationships where one class is a subclass of another.

• is a member of

e.g., pilot-airline

• is an organisational subunit of

e.g., department-store

• uses or manages

e.g., pilot-plane

• communicates with

e.g., customer-cashier

• is related to a transaction

e.g., passenger-ticket

• is owned by

e.g., plane-airline

4.2 Concept Diagrams

• Concepts and the relationships between them are documented in a concept diagram.
• Basic notation for concepts:

Name of concept Attribute 1 · · · Attribute n

4.3 Annotating Concepts

• We can annotate concepts to make relationships more precise.
• Involves stating multiplicities.
• Thus: - many students are registered on one course; - one course has many modules.

• Possible annotations:

1 one

n exactly n

m..n between m and n

∗ zero or more

m, n either m or n

• Note that identifying concepts is much more important than relationships or multiplicities;