Sie sind auf Seite 1von 27
Up2UML Learn the Unified Modeling Language V2 ® within distinct Software Devel- opment Processes 1

Up2UML

Learn the Unified Modeling Language

V2® within distinct Software Devel- opment Processes

1

Up2UML

Alpha-Release

2007

Copyright © 2007 Fraunhofer IESE, Kaiserslautern

2007 Copyright © 2007 Fraunhofer IESE, Kaiserslautern Fraunhofer [ http://www.iese.fraunhofer.de ] Institut
] Institut Experimentelles Software Engineering (IESE) Institut National Polytechnique de
] Institut Experimentelles Software Engineering (IESE) Institut National Polytechnique de
de Toulouse (INPT) [ http://www.inp-toulouse.fr ] National College of Ireland (NCI) [ http://www.ncirl.ie ]
National College of Ireland (NCI) [ http://www.ncirl.ie ] SOFTWIN [ http://www.intuitext.com/ ] New Bulgarian
] SOFTWIN [ http://www.intuitext.com/ ] New Bulgarian University, Нов Български

The Up2UML project is co-funded by the European Vocational Training programme "LEONARDO DA VINCI"; co-operation partners come from Germany, France, Ireland, Romania and Bulgaria.

2

Up2UML

Abstract

Up2UML Abstract The purpose of this course is to help you learn the Unified Modeling Language

The purpose of this course is to help you learn the Unified Modeling Language V2® . It is being developed by the Up2uml Consortium.

Responsible for the content in accordance with §6 TDG:

Up2UML Consortium c/o Fraunhofer Institute Experimental Software Engineering Fraunhofer-Platz 1 67663 Kaiserslautern E-Mail: sonja.trapp@iese.fraunhofer.de Tel.: +49 (631) 6800-2182 Web: http://www.up2uml.org/

All published contents (layout, texts, images, graphics etc) are subject to copyright.

3

Up2UML

Table of Contents

Up2UML Table of Contents 1. Lesson: Theory of the UML Use Case Diagram 4 1.1. Objectives:

1. Lesson: Theory of the UML Use Case Diagram

4

1.1. Objectives: UML Use Case Diagram

5

1.2. Definition: UML Use Case Diagram

5

1.3. Range of use

6

1.4. Example: UML Use Case Diagram

6

1.5. Elements of the UML Use Case Diagram

7

1.6. Definition: Actor

7

1.7. Definition: Use Case

7

1.8. Relationship between Actor and Use Case

8

1.9. The "system boundary"

8

1.10. Dependencies between Use cases

9

1.11. The «include» dependency

9

1.12. The «extend» dependency

10

1.13. Generalisation in the UML Use Case Diagram

11

1.14. Further Dependencies in UML Use Case Diagrams

12

1.15. Overview of elements used in the UML Use Case Diagram

12

1.16. Exercise: Define the term "use case"

13

1.17. Exercise: List elements of a UML Use Case Diagram (Actors, Use

cases)

?

1.18. Exercise: Identify relationships in a UML Use Case Diagram

14

1.19. Exercise: Explain a UML Use Case Diagram

15

1.20. Summary: UML Use Case Diagram

15

A. Case Studies

17

A.1. Hospital Information System

17

A.1.1. Requirements of a Hospital Information System

17

Index

18

Glossary

19

4

Up2UML

Up2UML 1. Lesson: Theory of the UML Use Case Diagram [id: UML-UCD ] In this section

1. Lesson: Theory of the UML Use Case Diagram

[id: UML-UCD ]

1. Lesson: Theory of the UML Use Case Diagram [id: UML-UCD ] In this section you
1. Lesson: Theory of the UML Use Case Diagram [id: UML-UCD ] In this section you

In this section you will learn

what UML Use Case Diagrams are,

what UML Use Case Diagrams are used for and who designs them,

which elements UML Use Case Diagrams are composed of and how these are graphically represented and

what kind of relationships exist between the elements of UML Use Case Diagrams.

1.1.

Objectives: UML Use Case Diagram

[id: UML-UCD-objectives ]

You should be able

Case Diagram [id: UML-UCD-objectives ] You should be able • to define the terms "use case",

to define the terms "use case", "use case diagram", and "actor".

to identify and list actors, use cases and their relationships and heritage in a use case diagram.

to explain use cases and use case diagrams as well as the relationships within a use case diagram.

1.2.

Definition: UML Use Case Diagram

[id: o-20061127122342790 ]

Use cases are a technique for capturing the functional requirements of a system. By describing the typical interactions between the users of a system and the system itself, they provide a narrative of how the system is used.

A use case describes usages and behaviours of a system from the viewpoint of a user or connected (interacting) systems.

5

Up2UML

Up2UML Use cases are usually written down in a document which describes the details of the

Use cases are usually written down in a document which describes the details of the

use case in a table (use case model). However, within the UML2, the structure of this document is not defined. Hence, we do not present such a document in this unit.

Hence, we do not present such a document in this unit. 1.3. Range of use [id:

1.3. Range of use

[id: o-20061127123102330 ]

A use case diagram is used

• to gather the requirements for a system,

• to integrate and delimit a system in its environment

• to accompany the system implementation

• to generate test cases and

• to validate the system architecture.

Use case diagrams are normally designed by analysts and domain experts at the beginning of the development of a system.

experts at the beginning of the development of a system. 1.4. Example: UML Use Case Diagram

1.4. Example: UML Use Case Diagram

[id: o-20061127125301830 ]

Example: UML Use Case Diagram [id: o-20061127125301830 ] Example 1. UML Use Case Diagram Example 1,

Example 1. UML Use Case Diagram

Example 1, “UML Use Case Diagram” shows a simple UML Use Case Diagram. It consists of an actor, two associated use cases and a system boundary.

6

Up2UML

Up2UML 1.5. Elements of the UML Use Case Diagram [id: o-20061127134327520 ] A UML Use Case

1.5. Elements of the UML Use Case Diagram

[id: o-20061127134327520 ]

of the UML Use Case Diagram [id: o-20061127134327520 ] A UML Use Case Diagram mainly consists

A UML Use Case Diagram mainly consists of the elements "Actor" and "Use Case".

The use case diagram shows the actors, the use cases, and the relationships between them. The relationships between the use cases can be specified more closely.

between the use cases can be specified more closely. 1.6. Definition: Actor [id: o-20061127150710310 ] The

1.6. Definition: Actor

[id: o-20061127150710310 ]

The element "actor" is a person, an organisation or an external system outside of the

system, that has to be modelled. The actor directly interacts with the system by way

of the use cases. Different users of the system are represented by different actors.

users of the system are represented by different actors. Example 2. Actors displayed using various symbols

Example 2. Actors displayed using various symbols

Notation. An actor is represented by a "stick-man" icon with the name of the actor

in the vicinity (usually above or below). An actor may also be shown as a class rect-

angle with the keyword "actor", with the usual notation for all compartments. By defining further stereotypes it is possible e.g., to use a computer icon as actor symbol.

it is possible e.g., to use a computer icon as actor symbol. 1.7. Definition: Use Case

1.7. Definition: Use Case

[id: o-20061128125656330 ]

Use cases describe typical scenarios of users interacting with a system. A scenario

is a sequence of steps describing an interaction between a user and a system. The

scenarios are defined depending on the goals the user wants to achieve by means of the system. A single use case stands for a set of behaviours with observable results performed by the system.

7

Up2UML

Up2UML Example 3. Use Case Notation. of the use case or with the name of the
Up2UML Example 3. Use Case Notation. of the use case or with the name of the
Up2UML Example 3. Use Case Notation. of the use case or with the name of the

Example 3. Use Case

Notation.

of the use case or with the name of the use case placed below the ellipse.

A use case is shown as an horizontal ellipse, either containing the name

1.8. Relationship between Actor and Use Case

[id: o-20061129110610820 ]

An association (actor relationship) is a relationship between an actor and a use case.

Hence, by way of the associations, every user is assigned a different scenario within the system.

user is assigned a different scenario within the system. Example 4. Relationship between an actor and

Example 4. Relationship between an actor and a use case

Example 4. Relationship between an actor and a use case Notation. Associations are represented by a

Notation.

Associations are represented by a simple solid line.

1.9. The "system boundary"

[id: o-20061129120157650 ]

The system boundary indicates which actions and functions (use cases) of a system

belong to a specific system and which are outside the system (e.g., actors, other

systems).

8

Up2UML

Up2UML Example 5. System boundary Notation. The system boundary is represented by a rectangle around the

Example 5. System boundary

Up2UML Example 5. System boundary Notation. The system boundary is represented by a rectangle around the

Notation.

The system boundary is represented by a rectangle around the relevant

use cases.

by a rectangle around the relevant use cases. 1.10. Dependencies between Use cases [id:

1.10. Dependencies between Use cases

[id: o-20061129133525850 ]

The element "dependency" represents a directed relationship between two use cases.

The UML2 has many varieties of dependency, each with particular semantics and keywords. Such dependencies are indicated by Stereotypes which are defined within

the UML2.

by Stereotypes which are defined within the UML2 . Example 6. Dependencies between use cases Notation.
by Stereotypes which are defined within the UML2 . Example 6. Dependencies between use cases Notation.

Example 6. Dependencies between use cases

Notation.

Dependencies are modelled as a dashed line with an open arrowhead.

1.11. The «include» dependency

[id: o-20061129142802370 ]

The «include»-construct is used for use cases that can be subdivided into several steps. It is also used for use cases that are included in several superior use cases.

9

Up2UML

Up2UML This means that the execution of one use case always includes the execution of the

This means that the execution of one use case always includes the execution of the other use case.

case always includes the execution of the other use case. Example 7. «include» dependency Notation. arrowhead.

Example 7. «include» dependency

Notation.

arrowhead. The arrow of the «include» relationships points to the use case that should

be included.

The «include» dependency is represented by a dashed line with an open

dependency is represented by a dashed line with an open Clearly separable functions within a use
dependency is represented by a dashed line with an open Clearly separable functions within a use

Clearly separable functions within a use case should always be represented as separate use cases. The «include»-dependency then integrates the functions into the main use case. If the level of abstraction is very high, this might not be necessary.

1.12. The «extend» dependency

[id: o-20061129144204240 ]

The «extend»-dependency ( ) shows that the behaviour of a use case ( ) can be extended by another use case ( ) under a certain condition ( ). The use case is ex- tended, once the condition is true. In this case, the first use case is extended by the behaviours of the extending use cases.

is extended by the behaviours of the extending use cases. An «extend»-dependency is used to conditionally
is extended by the behaviours of the extending use cases. An «extend»-dependency is used to conditionally
is extended by the behaviours of the extending use cases. An «extend»-dependency is used to conditionally

An «extend»-dependency is used to conditionally include the behaviour of secondary use cases at a given point in the execution of the initial use case. This point is called "extension point" ( ).

cases at a given point in the execution of the initial use case. This point is

10

Up2UML

Up2UML Example 8. «extend»-dependency The «extend» dependency is represented by a dashed line with an open
Up2UML Example 8. «extend»-dependency The «extend» dependency is represented by a dashed line with an open

Example 8. «extend»-dependency

The «extend» dependency is represented by a dashed line with an open

arrowhead. The arrow of the extend relationships points from the extending use case to the use case that should be extended.

Notation.

use case to the use case that should be extended. Notation. 1.13. Generalisation in the UML

1.13. Generalisation in the UML Use Case Diagram

[id: o-20061130103936810 ]

A generalisation is used for use cases describing a scenario similar to that of another use case, which is possibly extended or slightly changed. This behaviour corresponds

to inheritance in object orientation.

corresponds to inheritance in object orientation . Example 9. Generalisation in the UML Use Case Diagram

Example 9. Generalisation in the UML Use Case Diagram

Notation.

The generalisation is represented by a solid line with an unfilled arrowhead.

11

Up2UML

Up2UML 1.14. Further Dependencies in UML Use Case Diagrams [id: o-20061130105935240 ] Dependencies between use cases

1.14. Further Dependencies in UML Use Case Diagrams

[id: o-20061130105935240 ]

in UML Use Case Diagrams [id: o-20061130105935240 ] Dependencies between use cases can also be denoted

Dependencies between use cases can also be denoted by other predefined stereo- types, for example «use». The «use»-dependency indicates that a service from another use case in the system or of another system is used without being included within an «include»-dependency.

12

Up2UML

Up2UML 1.15. Overview of elements used in the UML Use Case Diagram [id: o-20061130110541530 ] The
Up2UML 1.15. Overview of elements used in the UML Use Case Diagram [id: o-20061130110541530 ] The

1.15. Overview of elements used in the UML Use Case Diagram

[id: o-20061130110541530 ]

The actor is a role outside of the system to be modelled. The actor directly interacts with the system by way of the use cases. The use case represents a typical activity carried out by a user using the system. Associations between actors and use cases assign different scenarios to the users of the system.

Relationships between use cases have the following meanings:

«include» means that a use case is subdivided into several steps or that it is included in several subordinated use cases.

«extend» shows that the behaviour of a use case can be extended by another use case.

• A generalisation is used for a use case describing a scenario similar to that of an- other use case which is possibly extended or slightly changed.

«use» as a predefined stereotype indicates that a use case is using services from another use case in the system or from another system.

Use cases are enclosed by the system border which delimits them from actors outside of the system.

which delimits them from actors outside of the system. 1.16. Exercise: Define the term "use case"

1.16. Exercise: Define the term "use case"

[id: o-20061205110730110 ]

Select from the list those words that define best the concept of use cases:

13

Up2UML

Up2UML (1) Actors (2) Requirements (3) Classes (4) Dependency (5) Stereotype (6)

(1)

Actors(1)

(2)

Requirements(2)

(3)

Classes(3)

(4)

Dependency(4)

(5)

Stereotype(5)

(6)

Timing(6)

(5)(4)(2)(1)

(5) Stereotype (6) Timing (5)(4)(2)(1) 1.18. Exercise: Identify relationships in a UML Use Case

1.18. Exercise: Identify relationships in a UML Use Case Diagram

[id: o-20061207111810270 ]

(6) Timing (5)(4)(2)(1) 1.18. Exercise: Identify relationships in a UML Use Case Diagram [id: o-20061207111810270 ]

14

Up2UML

Up2UML 1.19. Exercise: Explain a UML Use Case Diagram [id: o-20061207100509890 ] Have a look at

1.19. Exercise: Explain a UML Use Case Diagram

[id: o-20061207100509890 ]

Explain a UML Use Case Diagram [id: o-20061207100509890 ] Have a look at the diagram and

Have

a

look

at

the

diagram

and

select

the

correct

statement(s)!

a look at the diagram and select the correct statement(s)! (1) A foreign customer wants to

(1)

(1) A foreign customer wants to transfer money at an ATM. The account man-

A

foreign customer wants to transfer money at an ATM. The account man-

 

agement system checks whether the user entered the right PIN and then proceeds to the money transfer.

(2)

(2) A customer wants to withdraw money from an ATM. First he has to identify

A

customer wants to withdraw money from an ATM. First he has to identify

 

himself by entering a personal PIN. After successful authentication, the cus- tomer withdraws money from the ATM.

(3)

(3) A bank customer wants to transfer money. He successfully enters the PIN

A

bank customer wants to transfer money. He successfully enters the PIN

 

and the amount of money he wants to transfer. The account management system checks the balance of his account and then transfers the money.

(3)(2)

15

Up2UML

Up2UML 1.20. Summary: UML Use Case Diagram [id: o-20061205120038910 ] The UML Use Case Diagram describes

1.20. Summary: UML Use Case Diagram

[id: o-20061205120038910 ]

Summary: UML Use Case Diagram [id: o-20061205120038910 ] The UML Use Case Diagram describes services and

The UML Use Case Diagram describes services and functions of a system from the user's point of view or from the perspective of further connected (interactive) systems.

The purpose of a UML Use Case Diagram is

• to gather the requirements of a system;

• to integrate and delimit a system in its environment;

• to accompany the implementation of the system and to generate test cases, and

• to validate the system architecture.

The main elements of the UML Use Case Diagram are

• actor

• use case

association

• dependency and

• system boundary.

16

Up2UML

A. Case Studies

Up2UML A. Case Studies

A.1. Hospital Information System

[id: casestudy_hospital ]

A.1.1. Requirements of a Hospital Information System

[id: casestudy_hospital_requirements ]

The City Hospital is planning to introduce an information system, in order to process medical and administrative data. The hospital information system is supposed to make the hospital more efficient and to improve a number of administrative functions.

These functions include:

• Administration of patient data and collection of disease data

• Planning and collection of medical services

• Payment transactions with health insurance companies and paying patients

• Archiving of reports and support for the documentation of surgery, care and the or- dering of material

• Administration and provision of laboratory data and data from radiological examin- ation (e.g., X-rays)

The first version of the system should deal mainly with the treatment of a patient in the emergency unit and includes a set of system specifications corresponding to the items named above. These are further described by the following scenario:

A patient with minor injuries enters the emergency unit. The reception officer first takes

up all personal data including identification of the payment details of the patient. The patient reports that he had a sports accident and is experiencing a lot of pain in his

knee. Accordingly, the reception officer arranges for a physical examination. This in- cludes finding an available and suitably qualified physician and, if necessary, finding available medical equipment/special rooms that are required in order to conduct the examination. Furthermore, the patient may have to be transferred to the corresponding ward.

The emergency physician on duty conducts the first examination. He has a list of up- coming appointments provided by the information system which include the appointment for the examination of the newly arrived patient. After the examination he formulates

a diagnosis, orders medicine and/or prescribes a therapy and enters these data into

the hospital information system. If further examinations are needed to better circum- stantiate the diagnosis, he may instruct a nurse to arrange for some extra examinations.

17

Up2UML

Up2UML This may involve a check of certain laboratory values or X-rays in order to see

This may involve a check of certain laboratory values or X-rays in order to see if the patient has some fractures.

In this case, X-rays of the knee have to be made. The arrangement of the extra exam- ination includes checking whether an X-ray machine and a radiologist are available. The patient is then sent to the radiology ward for an X-ray. To transfer the patient, the nurse enters the transfer into the system and then brings him to the radiology ward where the radiologist conducts his examination. After the examination, the radiologist enters his diagnosis into the system and the nurse transfers the patient back to the emergency physician.

Depending on the results of the special examination, which are available in the system, the emergency physician decides whether the patient must stay in hospital or if he can go home. If the patient can go home, he is transferred to the reception where the reception officer takes care of the hospital discharge. This includes the creation of an invoice and the handing-out of a prescription.

18

Up2UML

A

actor, 7

association, 8

D

dependency

extend, 10

include, 9

use, 12

G

generalisation, 11

Index

U

UML Use Case Diagram, 5, 6, 13, 15, 16 association, 8 system boundary, 8 use case, 7 dependency, 9 generalisation, 11 use case diagram, 5

5, 6, 13, 15, 16 association, 8 system boundary, 8 use case, 7 dependency, 9 generalisation,

19

Up2UML

Glossary

Up2UML Glossary activity diagram The activity diagram depicts all the process elements within the scope of

activity diagram The activity diagram depicts all the process elements within the scope of an activity. It is used to visualise the execution of a use case, an operation or of a complete business process. Concurrencies, alternative decision paths etc. can be modelled and retraced.

actor

Someone or something, outside the system that interacts with the system.

analysis

The aim of the analysis is to describe what the system should be able to perform.

analysis class Analysis classes are part of the analysis model. They map in a clear and unambiguous way to real-world business concepts. Analysis classes model important aspects of the problem domain and present only a very high-level set of attributes and operations. Normally, analysis classes will evolve directly into elements in the Design Model: some become design classes, others become design subsystems.

analysis packages

API

architectural foundation

artifact

Analysis packages are collections of semantically related analysis classes.

Application programming interface

The baseline at the end of the elaboration phase, at which time the foundation structure and behaviour of the system is stabilized.

A piece of information that is produced, modified, or used by a process.

association An association represents a structural relationship that connects two classifiers, like, e.g., classes or use cases.

behaviour

The observable effects of an operation or event, includ- ing its results.

black-box testing Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional.

20

Up2UML

Up2UML The test designer selects valid and invalid input and determines the correct output. There is

The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure. (Source: Wikipedia)

business activities A description of system behaviour, in terms of se- quences of actions. A business activity should yield an observable result of value to a business role.

class

A description of objects that share the same attributes, operations, methods, relationships and semantics. It is

a template for creating objects and models the data and

behaviour an object will have. Classes can be domain (or analysis) classes, design classes, or implementation classes.

class diagram A class diagram shows a collection of static model ele- ments, such as classes, types, and their contents and relationships.

cohesion

Cohesion is a measure of how strongly-related and fo- cused the responsibilities of a systems are.

communication diagram Formerly named collaboration diagram, a communication diagram describes a pattern of interaction among ob- jects; it shows the objects participating in the interaction by their links to each other and the messages they send to each other.

component

A non-trivial, nearly independent, and replaceable part

of a system that fulfils a clear function in the context of

a well-defined architecture.

component diagram The component diagram depicts the software compon- ents that compose an application, system or enterprise. Their components, their interrelationships, interactions, and their public interfaces are depicted.

concurrency

The occurrence of two or more activities during the same time interval. Concurrency can be achieved by interleav- ing or simultaneously executing two or more threads.

construction phase The third phase of the UP® in which the software is brought from an executable architectural baseline to the point at which it is ready to be transitioned to the user community.

control flow

Control flow is the order in which the individual elements are executed or evaluated.

21

Up2UML

Up2UML coupling Coupling is a measure for the degree to which each part of a system

coupling Coupling is a measure for the degree to which each part of a system relies on each one of the others. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.

CRC

Class - Responsibility - Collaborator

deployment diagram The deployment diagram shows the configuration of run-time processing nodes and the components, pro- cesses, and objects that live on them. It depicts the hardware, software and middleware configuration of a system.

design

In the software domain design is a process of problem- solving and planning for a solution.

design class

Classes whose specifications have been completed to such a degree that they can be implemented.

design

model An object model describing the realisation of use cases; serves as an abstraction of the implementation model and its source code.

design package A collection of classes, relationships, use-case realisa- tions, diagrams, and other packages. It is used to structure the design model by dividing it into smaller parts.

design subsystem

elaboration phase

A model element that represents a part of a system. The design subsystem encapsulates behaviour by packaging other model elements (classes or other design subsystems) that provide its behaviour.

The second phase of the process where the product vision and its architecture are defined.

extend relationship The extend-relationship shows that the behaviour of a use case can be extended by another use case. It is used in cases where a new use case is integrated into an existing use case.

functional requirement Functional requirements capture the intended behaviour of the system. This behaviour may be expressed as services, tasks or functions the system is required to perform.

generalization

inheritance

GUI

Graphical User Interface

22

Up2UML

Up2UML IBM Industrial Business Machines implementation A discipline in the software engineering process, the

IBM

Industrial Business Machines

implementation

A discipline in the software engineering process, the purpose of which is to implement software components that meet an appropriate standard of quality.

implementation model The implementation model is a collection of components, and the implementation subsystems that contain them.

inception phase The first phase of the Unified Process® , in which the business context, success factors, and financial forecast is established.

include relationship

The include-relationship is used for use cases that can be subdivided into several steps. It is also used for use cases that are included in several superior use cases.

inheritance

inheritance

integration test

Phase of software testing in which individual software modules are combined and tested as a group.

interface

Defines the communication boundary between two en- tities, such as a piece of software, a hardware device, or a user.

iterations

Repetition of a sequence of instructions. A fundamental part of many algorithms.

JDBC

Java Database Connectivity

lifecycle

A lifecycle is one complete pass through the four phases, i.e. the span of time between the beginning of the inception phase and the end of the transition phase.

lifeline

A lifeline is a part of the sequence diagram. Messages are drawn between lifelines. Activation bars are drawn on top of lifelines to represent that processes are being performed in response to the message.

message flow

Order of messages

Multiplicities

Multiplicities specify the number of objects that can participate in a relationship at any point in time.

non-functional requirement Non-functional requirements are requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviours. Typical

23

Up2UML

Up2UML non-functional requirements are reliability, efficiency, scalability, and cost. object diagram An object diagram

non-functional requirements are reliability, efficiency, scalability, and cost.

object diagram An object diagram encompasses objects in a system and their relationships at a point in time. It shows in- stances of classes, components, nodes, links (instances

of association) and values of attributes (slots). An object

diagram is often called an instance diagram.

object orientation A programming approach based on the concepts of data abstraction and inheritance. Unlike procedural program- ming techniques, object-oriented programming concen- trates on those data objects that constitute the problem and how they are manipulated, not on how something

object-oriented analysis

is accomplished.

Object-oriented analysis is an approach that models a system as a group of interacting objects. It applies ob- ject-modeling techniques to analyse the functional re- quirements for a system. (Source: Wikipedia)

object-oriented design Object-oriented design is part of the object-oriented methodology. The main concept behind all design de- cisions is the "object" which provides data and proced- ures (methods).

object-oriented modelling

A paradigm for modelling systems according to object

orientation.

object-oriented

program-

Object-oriented is a programming technique that uses

ming

"objects" and their interactions to design systems. It is based on several techniques, including inheritance, modularity, polymorphism, and encapsulation. (Source:

Wikipedia)

quality attribute Software quality attributes are the benchmarks that de- scribe the system's intended behaviour within the envir- onment for which it was built. They provide the means for measuring the fitness and suitability of a product.

Rational Unified Process The Rational Unified Process is a software development process framework which claims to provide a disciplined approach to assigning tasks and responsibilities within

a development organisation. Its goal is the production

of high quality software that meets user needs within a predictable time schedule and budget.

requirements

The first stage of software development which defines what the potential users want the system to do.

24

Up2UML

requirements workflow

Up2UML requirements workflow In this workflow, the requirements of the system that has to be developed

In this workflow, the requirements of the system that has to be developed are identified and documented. This means that

• a list of potential requirements is drawn

• the system context is defined, and

• the functional

• and non-functional requirements are identified.

role

A role is a definition of the behaviour and responsibilities of an individual, or a set of individuals working together as a team, within the context of a business organisation.

RUP

Rational Unified Process

scenario A specific sequence of actions that illustrates beha- viours. A scenario may be used to illustrate an interac- tion or the execution of one or more use-case instances.

sequence diagram A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects parti- cipating in the interaction and the sequence of messages exchanged.

singleton pattern

SQL

A pattern used for the design of software systems. It helps to ensure that exactly one instance of an object exists.

Simple Query Language

stakeholder Stakeholders are an integral part of a project.They are the end-users or clients, the people from whom require- ments will be drawn, the people who will influence the design and, ultimately, the people who will reap the be- nefits of your completed project.

state machine diagram A state machine diagram describes the states an object may be in, as well as transitions between states. (Formerly referred to as a "state diagram" or "state- transition diagram"). A state machine specifies the be- haviours of a model element, defining its response to events and the life cycles of the object.

stereotype

Represents a variation of an existing model element with the same form but with a modified intent. With ste-

25

Up2UML

Up2UML reotypes, you can introduce new modeling elements based on existing elements. subsystem A model element

reotypes, you can introduce new modeling elements based on existing elements.

subsystem A model element which has the semantics of a package, such that it can contain other model elements, and a class, such that it has behaviour. The behaviour of the subsystem is provided by classes or other subsystems

system architecture

system border

it contains.

The design or set of relations between the parts of a system.

Marks the border between the use cases and the actors.

system test

Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified re- quirements.

transition phase

The fourth phase of the process in which the software

is

turned over to the user community.

UML-AD

UML Activity Diagram

UML-CD

UML Class Diagram

UML-CompD

UML Component Diagram

UML-ComuD

UML Communication Diagram

UML-DD

UML Deployment Diagram

UML-OD

UML Object Diagram

UML-PD

UML Package Diagram

UML-SD

UML Sequence Diagram

UML-SMD

UML State Machine Diagram

UML-UCD

UML Use Case Diagram

UML2

Unified Modeling Language V2®

Unified

Modeling

Lan-

A

language for visualising, specifying, constructing, and

guage

documenting the artifacts of a software-intensive system.

Unified Process

 

The Unified Process (UP) is a software development process framework .

UP

Unified Process

26

Up2UML

use case

Up2UML use case A description of system behaviour, in terms of se- quences of actions. A

A description of system behaviour, in terms of se- quences of actions. A use case should yield an observ- able result of value to an actor.

use case diagram A use case diagram describes users, use cases, and their interrelationships, thus showing the external beha- viour of a system from the users' perspective. A user can be a person or a neighbouring system.

use case model The use case model describes a system's functional requirements in terms of use cases. It also defines the actors of the system and helps to mark the system bor- der.

use case realisations Describes how a particular use case is realised within the design model. The goal of the use-case realisation is to produce a well-structured object-oriented design for implementation of the behaviour defined in a use case.

use-case realisation Describes how a particular use case is realised within the design model. The goal of the use-case realisation is to produce a well-structured object-oriented design for implementation of the behaviour defined in a use case.

validate

Finding or testing the truth of something.

validation

The stage in the software lifecycle at the end of the de- velopment process where software is evaluated to en- sure that it complies with the requirements.

white-box testing White box testing uses an internal perspective of the system to design test cases based on internal structure.

It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. Since the tests are based on the actual implementation, if the implementation changes, the tests probably will need to also. While white box testing is applicable at the unit, integration and system

levels of the software testing process, it's typically ap- plied to the unit. So while it normally tests paths within

a unit, it can also test paths between units during integ- ration, and between subsystems during a system level test. (Source: Wikipedia)

27