NOTES

rThe use case diagram

[p35 - p58]

Quick intro

The use case is a fundamental concept of many OOP principles, they

express the exceptions of the customers/stakeholders. The use case
diagram is used during the entire analysis and design process. We can use
a use case diagram to answer, what is being described(The system), who
interacts with the system(the actor), what can actors do ( the use cases)

Use case
A use case describes functionality expected from the system under
development, it provides tangible benefit for one or more actors that
communicate with the use case. They are created using customer wishes,
the set of all use cases describes the functionality that a system shall
provide.

Actors
Actors interact with the system by using use cases (they initiate the
execution of the use cases), by being used by the use cases (the actors
provide functionality for the execution of the use cases).

Actors represent roles that users adopt

Actors are not a part of the system, they are outside of the system
boundaries.

Usually data is also administered within the system, this data is modeled
within the system in the form of classes and objects,

Example:
The assistant interacts with the system (lab assignment) by using it, the
class assistant describes objects representing data.

❖ Human actors
➢ E.g. student, professor
❖ Non-human actors
➢ E.g. email servers
❖ Primary actors
➢ Has the main benefit of the use case outcome
❖ Secondary actors
➢ Has no direct benefit of use case outcome
❖ Active actors
➢ Initiates the execution of the use case
 ❖ Passive actors
➢ Provides functionality for the execution of a use case

Relationships between use cases and actors

Actors are connected with use cases via solid lines, each of these actors
must communicate with at least one use case, an association is always
binary(meaning that it is always specified between one use case and one
actor.), Multiplicities may be specified.

Relationships between use cases

The behaviour of one use case (included use case) is integrated in the
behaviour of another use case (base use case)

For example:
The behaviour of one use case(extending use case) may be integrated in
the behaviour of another use case(base use case) but does not have to,
Both use cases may also be executed independently of one another.
Sort of like creating two classes and one of them extends the other class.
One is a superclass.

In summary
❖ The base use case can decide if the included use case is executed
❖ Extension points define at which point the behaviour is integrated.
❖ Conditions define under which circumstances the behaviour is
integrated.
❖ Extension points are written directly within the use case.
❖ Specification of multiple extension points is possible.

Example:
If use case A includes use case B, the behaviour of B is integrated into A. A
being the base use case and B being the included use case. For example
When A is executed B must also be executed. But B can be executed
independently of A.
A is again the base use case, and B being the extending use case. Both
use cases can be executed independently of one and other, when A is
called it is possible but not mandatory to execute B.
By using extension points you can define a point at which the behaviour of
the extending use case must be inserted into the base use case.

If a use case A generalises

a use case B, B inherits the behaviour of A, which B can either extend or
overwrite. Then, B also inherits all relationships from A. Therefore, B
adopts the basic functionality of A but decides itself what part of A is

executed or changed. If a use case is labelled {abstract}, it cannot be ex-

executed directly; only the specific use cases that inherit from the abstract

use case are executable.

Relationships between actors

Actor A inherits from actor B, A can communicate with x and y however B

can only communicate with Y(think about it, if B is connected to Y and A is
connected to X, if A inherits B it can communicate with the same use cases
and also its own ones). MULTIPLE INHERITANCE IS ALLOWED, abstract
actors are possible
 The description of a use case

Example:

For more revision - look at your lab slides and answers

 The class diagram
[p59 - p94]

We use class diagrams to model the static structure of a system, it

describes the elements of a system and the relationships between them.

In early project phases it allows you to create a conceptual view of the

system, you can even use class diagrams to generate program code
automatically. However in practice it is mainly used for documentation
purposes.

Object diagrams allow you to depict concrete objects that appear in a

system at a specific point of time.
Classes provide schemas for characterising objects and instances of
classes.
The object diagram visualises instances of classes that are modelled in a
class diagram.

Objects
A system contains many objects
The relationship between the objects are referred to as “links”.

The characteristics of an object include its structural characteristics

(attributes) and its behaviour (in the form of operations). Whilst concrete
values are assigned to the attributes in the object diagram, operations are
generally not depicted. Operations are identical for all objects of a class
and are therefore usually described exclusively for the class.

The first compartment always contains information in the form

objectName:Class, if the rectangle has a second compartment, this
compartment contains attributes of the objects and current values of these
attributes.

Classes

A class is a construction plan (As you know it as the blueprint) for a set of
similar objects that appear in the system.

Has name, attribute(structural characteristics) and operations(behaviour).

 Attributes

Going through this example above,

As we used the equals sign in password, pw123 is now the default value if
the value is not set explicitly by the user.

The property {readOnly} means that the value cannot be changed once
initialised.

The forward slash before an attribute name indicates that the value of this
attribute is derived. For example the age can be derived from the DOB

The multiplicities

Some things here may relate to the example right above.

This indicates how many values an attribute can contain. This enables you
to define arrays, just like in programming languages.
Brackets in the form [minimum, maximum] indicate the lower and upper
limits
You already know this stuff so the new things are…
[5] means the attribute can have exactly five attributes
[*] is equivalent to [0…*]
If you do not specify a multiplicity it is assumed the value of 1

If an attribute can adopt multiple values it only makes sense to put down
how they are stored:
❖ As a set(no fixed order with no duplicates)
❖ A multi set(no fixed order of elements with duplicates possible)
❖ A ordered set(fixed order with no duplicates)
❖ A list(fixed order with duplicates possible)
You specify this by putting curly braces and {unique/not unique,
ordered/unordered}

Operations
Same thing as methods in a class.
 Visibility markers

Class Variables and Class Operations

Static vs Non-Static Variables and Methods In Java - Full Simple Tutorial

Attributes referred to as instance variables or instance attributes is what

your used to, the attribute is specifically for that instance of that class
however class variables are only created once for a class and remain the
same for all instances of that class. Good to use with constant variables or
counters of instances.

Associations
Associations between classes model possible relationships, known as
links.

Binary associations
A binary association allows us to associate the instances of two classes
with one another. The arrow merely indicates in which direction the reader
of the diagram should read the association name.

Navigability: an object knows its partner objects and can therefore access
their visible attributes and operations, normally indicated by an open arrow
head. Non - navigability is indicated by a cross.
The above example all mean the same thing, many students have many
professors, however (a) is preferred. This is because as here the
relationship between the classes is visualised explicitly, it is easier to know
and visualise what is going on.

XOR constraints, To express that an object of class A is to be associated

with an object of class b or an object of c nut not both, use XOR gates.
 N-ary associations

If more than two partners are involved in a relationship, you can model this
using n-ary association. An n-ary association is represented using a hollow
diamond in the centre. The diamond connected to all the partners of the
relationship. No navigation on n-ary associations.

If you had tried to express the above model in a binary association, you
would have a model with a completely different meaning, look at the
following what is wrong with the following? Look at p75 for answers.

Association Classes

An association class is a class that is part of an association relationship between

two other classes. You can attach an association class to an association
relationship to provide additional information about the relationship
 It is represented by a class and an association connected by a dashed line.

https://stackoverflow.com/questions/62094457/i-dont-understand-association-
class-uml-class-diagram

An association can also be associated with other classes, you'll see this in the
diagram later, look at the exam and certificate.

In general, you cannot replace an association class with a “normal”

class which is itself associated with the original two associated classes,
as shown by the following example. Let us assume that we want to
model that a student enrols for at least one study program and has precisely one
enrollment for each chosen study program. In turn, any number (≥ 0) of students
can enrol for one specific study program. This
situation is shown in Figure 4.19(a).
Figure 4.19(b) shows the attempt to model this situation with only
“normal” classes. An enrollment is assigned to precisely one student and
precisely one study program, while one study program is related to
any number of enrollment objects. A student has at least one enrollment.
So far the requirements are met. However, if we examine the diagram
more closely, we see that in Figure 4.19(b), a student can have multiple

enrollments for one and the same study program, which is not the in-
tention. In contrast, in Figure 4.19(a), a student can enroll for a specific
study program only once.

This shows the fact that, when it is not specified to be {non-unique} it is {unique}
in 4.20(a) each student can only have one exam meeting for each exam
In 4.20(b) each student can have multiple exam meetings per exam.

Aggregations

An aggregation is a special form of association that is used to express

that instances of one class are parts of an instance of another class.

There are two types of aggregation, shared and composite. They are both
transitive and asymmetric associations.
Transitive meaning, If B is a part of A then C is also a part of A.
Asymmetric meaning It is not possible for B to be a part of A and A to be a
part of B.

Shared aggregations
In principle, a shared aggregation expresses a weak belong-
ing of the parts to a whole, meaning that parts also exist indepen-
dents the whole. The multiplicity at the aggregating end may be
greater than 1, meaning that an element can be part of multiple other
elements simultaneously. Shared aggregations can therefore span a di-
directed acyclic graph.

Figure 4.21 shows two examples of the use of a

shared aggregation. In Figure 4.21(a), a lab class consists of any num-
ber of students. However, a student can participate in a maximum of one
lab class. In Figure 4.21(b), a study program is made up of any (≥ 0)
number of courses. A course is assigned to at least one (≥ 1) study program.

Composite aggregation
The use of a composition expresses that a specific part can only be
contained in at most one composite object at one specific point in time.
This results in a maximum multiplicity of 1 at the aggregating end. if
the composite object is deleted or copied, its parts are also deleted or
copied when a composition is used.
Figure 4.22 shows examples of compositions. A lecture hall is part of a
building. Due to the multiplicity 1, there is an existence dependency
between elements of these two classes. The lecture hall cannot exist
without the building.
If the building no longer exists, the lecture hall also does not exist any-
more. The situation is different for a beamer which is also associated
with a lecture hall by a composition. However, the multiplicity 0..1 is
specified at the aggregating end. This means that the beamer can exist
without the lecture hall, that is, it can be removed from the lecture hall.
If the beamer is located in the lecture hall and the lecture hall ceases to
exist—for example, because the building is torn down—the beamer
also ceases to exist. However, if it was removed from the lecture hall
beforehand, it continues to exist.

The only difference between the two aggregations is that composite is a

more concrete version. Without one part the other part simply could not

exist, however with shared it just tells the user that this is a part of this,
however without one part the other can still exist.
For example a lab can exist without students attending it
However how can a lecture hall exist without a building

Generalizations

We can use a generalization relationship to highlight commonalities

between classes, meaning that we no longer have to define these com-

mon characteristics multiple times. Conversely, we can use the general-
ization to derive more specific classes from existing classes. If we want

to add a class Professor, which is a subclass of ResearchAssociate, in

Figure 4.23, we use the generalization to avoid having to copy the char-
acteristics of the class ResearchAssociate to the class Professor.
ABSTRACT
UML allows multiple inheritance, meaning that a class may have
multiple superclasses. For example, a tutor is both an employee of the
university and a student (see Fig. 4.25). Due to the transitivity of in-
heritance, single inheritance creates an inheritance hierarchy, whereas
multiple inheritance creates a (directed acyclic) inheritance graph.

With and without generalisations:

 Creating a Class Diagram

We will be using a university information system as an example:

Step 1: Identifying classes

Step 2: Identifying attributes

Step 3: Identifying relation ships

There are three kinds of relationships: Association, generalisation and

aggregation.

You straight away see you can add an employee abstract class.
There is a distinction between research and administrative personnel,
some research associates hold courses, then they are called lecturers.

“A university consists of multiple faculties which are composed of

institutes”, from this we know we have an aggregation.

“Each faculty is led by a dean, who is an employee of the university”

“Research associates are assigned to at least one institute.”, again telling
you there should be an aggregation.

As there is no existence dependency it is a shared aggregation, different to

the aggregation above, with out the institute there is no faculty.

“Furthermore, research associates can be involved in projects for a certain

number of hours.”, telling you there is an association class involved.

“Some research associates hold courses. Then they are called lecturers.”
This leaves us with the following diagram:
 Code generation

Class diagrams are often used to create code, it is also suitable for
documenting existing program code, with the advantage that relationships
and classes are represented graphically.

Example:

Many elements can be translated one-to-one, however some cannot be

written in code so we may have to simulate their behaviour.

If the multiplicity is greater than 1 we have to use an array, or generic data

types(Collections(as with these, unlike arrays, we do not need to know the
size at initialization)).

Navigation is realised via attributes

Such concepts such as association classes or N-ary associations do not
exist in common programming languages such as java. We can simulate
this concept using a hash table (
https://stackoverflow.com/questions/53269167/uml-ternary-association-
implement-java-code )

He following is an example of how the above class diagram can be

generated into code:
 The sequence diagram

This models the inter object behaviour, that is the interactions between the
objects in a system. This leads to the question, what's interaction?
An interaction specifies how messages and data are exchanged between
two interaction partners.

Interaction partners could be either human or non-human.

And example of an interaction could be between a lecturer and a student

administration system, the interaction could be the sequence of method
calls in a program.

Interaction Partners
In a sequence diagram interaction partners are depicted as lifelines.
Example of a life line:

rolename:Class, indicates the rolename and class the

same way as you did for class diagrams, however if
you want to have it shown as only the class you have
to write it like this, “:class”

In a sequence diagram, remember the use of the role concept allows more
modelling flexibility than simple instances or classes, An object that is an
instance of a class can take over many roles over its lifetime.

COME BACK TO THIS, add more if needed

 Exchanging Messages

The sequence diagram is 2 dimensional, the interaction partners involved

in the interaction are presented on the horizontal axis and should be
arranged in a clear order, the vertical axis represents the chronological
order. (IF the chronological order has not been set aside , an event further
up the vertical axis can take place before an event that is lower down does.
Search
The chronological connection between a message a and a message b. Is
represented with an arrow ->.

Lets go through this diagram

A-
Message A must always take place before message C,
B-
As A and C do not have any interaction partners in common the order of
these messages is not specified
C-
Message B forces an interaction between the two interaction partners
therefore forcing a order.

Messages

Here are all types of messages:

Synchronous message - the sender has to wait until they receive a
response until they continue.

Asynchronous - the sender can continue on with the program and can
receive a response message at any time.

In case A the student is communicating via Email, so they can continue

doing what their doing until they get the response, in B the student is
asking in person so they must wait for the response.

var=m1:value, var is the the variable the message is assigned to, m is the
name of the message and value is the actual message it self.
The following is the syntax for a message:

Creating a object with a message:

Have to put in new - it's like instantiating the class - that's the constructor its
pointing to

If an object is deleted during the corse of an interaction this is called a

destruction event:
The following is an example of a class being created and destructed:
If the sender of a message is unknown or not relevant this is called a found
message

If the recipient of the message is unknown or not relevant it is called a lost

message.

Look at this example, why might announcement be lost and spam email be
found?

Up until this point we have decided that messages are transmitted without
loss of time. Of course this is not always the case:
Full Name  Email Address  I agree to the terms & conditions, cookies,
and privacy policies.
 Combined Fragments

Branches and loops

Alt fragment represents alternative sequences, an alt operator has atleast

two operands: , each operand represents an

alternative path, similar to the switch statement
Each operand has a guard, this is a boolean expression enclosed in
square brackets.
If there is no guard, true is always assumed, if multiple guards are true
simulation this results in indeterminism , leading to uncertainty in the
behaviour of the system.

A special guard [else] which is evaluated as true if no other switch

statements are not true
Look at this diagram and try to understand what it does now.
Firstly lets understand the OPT -
Opt corresponds to the alt fragment, The opt operator thus represents an
interaction sequence whose actual execution at runtime is dependent on
the guard. (LIKE AN IF STATEMENT WITHOUT AN ELSE BRANCH)

Explanation of the diagram above:

When a student wants to register for an exam, the following cases occur:
(1) There are still places available and the student and the student can
register
(2)There is a place available on the waiting list. Then the student has to
decide whether to go on the waiting list.
(3) If there is no place available for the exam or on the waiting list for the
exam, the student receives an error message and is not registered for
the course.
(a)If there is a place available on the waiting list, when registering
for an assignment the student can decide whether to take the
place on the waiting list. If the student wants to be on the
waiting list,the student has to register for it.

You can use the loop fragment is to be executed repeatedly.

the first operand is (min,max) (if there is no upper limit use

*), the guard , which is checked after each iterationIf the underlying
condition is not fulfilled, the execution of the loop is terminated even if the
maximum number of executions has not yet been reached.

Break fragment has the same structure as the opt fragment, if the guard is
true, the interaction within the operand are executed. the remaining
operations of the surrounding fragment are omitted and the interaction
continues to the next fragment.
Understand this example:

The password must be entered at least once and at most three times, as
reflected by the arguments of loop. After the first attempt, the system
checks whether the password can be validated. If it can, that is, if the
condition Password incorrect is no longer true, execution of the interactions
within the loop ceases. The system also exits the loop if the student enters
the password incorrectly three times. This case is then handled further in
the subsequent break fragment.
means that if the password is entered incorrectly three times, the condition
of the incorrect password is true. Thus the content of the break fragment is
executed, meaning that an error message is sent to the student and the
students are not allowed to register for the assignment. The remainder of
the interaction after the end of the break fragment is skipped. After exit
ing the break operator, we are in the outermost fragment of the sequence
diagram and therefore the execution of this sequence diagram is ended.
If we were not in the outermost fragment, the sequence diagram would
continue in the fragment at the next higher level.

Concurrency and Order

These allow you to control the order of event occurrences.

Seq fragment: expresses default order, it has at least one operand and
expresses weak sequencing, meaning:

(I DO NOT UNDERSTAND THIS ONE BIT, GO OVER IT WITH

SOMEONE!!!!!!!!!!!!)

We can use seq fragments with break, if the condition of the break
becomes true, the rest of the seq fragments are skipped, and the execution
continues on the surrounding fragment.
A student wants to register for an exam, if there are no places they can try
to reserve an exam for next week(which is the break fragment), if you look
at it closely, no matter what even if the student does the exam or not they
still receive the info from the lecturer.

Figure 6.13 shows another sequence diagram together with all possible
traces.
As this diagram shows a weak order, the message c is not connected
chronologically to messages a and b and can be interleaved
with these messages.
As b is sent by interaction partner B and d is also received by B, there is a
chronological order between these two messages. In any case, this is the
last message.

❖ A is sent to B, and B is sent to A, therefore there is an order

between them A -> B always!
❖ B and D are also connected so B->D
❖ C and D is connected to D so C->D
❖ D and E is always last

Strict fragments
The order of occurrences even on different lifelines are significant, meaning
that even if two messages aren't even connected, there is only one order
and that is the chronological order.
In the example in Figure 6.14, a lecturer only prints an exam when a
student has registered for it. If the strict fragment were not specified, it
would also be possible for the lecturer to print the exam before a student
registers.

Par fragment,
▪ To set aside chronological order between messages in different operands
▪ Execution paths of different operands can be interleaved
▪ Restrictions of each operand need to be respected
▪ Order of the different operands is irrelevant
▪ Concurrency, no true parallelism
So in short, its basically the same thing as seq, but only in each operand.
So i can complete the second operand before the first so long as I use the
seq order in each operands.

At the beginning
of a course, the lecturer has to complete certain activities. The lecturer
must answer queries from students, announce exam dates, and reserve
Lecture halls. To do all of this, the lecturer has to communicate with dif-
ferent persons and systems. A par fragment is used to express that the
order in which these activities are completed is irrelevant.
What is important is that the default order between messages within an
operand is adhered to, meaning that according to this sequence diagram, a
student will never register for a course first and then send a query to the
lecturer.

Coregions:
❖ These are used to model concurrent events of a single lifeline.
❖ The order of events within the coregion is not restricted
❖ Area of the lifeline to be covered by the coregion is marked by square
brackets rotated by 90 degrees

(NOT SURE IF TRUE, DOES IT MEAN THAT YOU CAN SEND

ANNOUNCE EXAM AND RESERVE LECTURE HALL MESSAGES AT
ANY TIME???????)

Critical fragment: Make sure certain parts of an interaction are not

interrupted by unexpected events, please note that the order of seq still
applies inside of the critical fragment.
Looking at this example, once the student tries to get the exam date and
tries to register for the exam, no message shows that anyone else can take
that student's place. If there was no critical the students place could be
taken.
Think of a shopping basket, your items are reserved for 20 minutes, no
other messages can interrupt you.
Whats the difference between this and just par?

Filters and Assertions

The combined fragments from the group “filters and“assertions” define

(i) which messages may occur but are not relevant for the description of the
system
(ii) which messages must occur
(iii) which messages must not occur.

Irrelevant messages are shown with the ignore fragment which expresses
that these messages can occur at runtime but have no further significance.
Irrelevant messages in curly brackets after the keyword ignore

The consider fragment is the opposite, it specifies that those messages

shown in the curly braces are important for the interaction under
consideration. All messages shown in the fragment that are not specified in
the curly braces are automatically classified as irrelevant( therefore they
are treated as if they are arguments for an ignore fragment)

The assert fragment, the sequence specified is the sequence that you
must take, otherwise there is an error. (what must occur)

The neg fragment, lets you model an invalid interaction(what must not
occur). (remember this does not eliminate other undesirable situations).
 (a)How can you receive a confirmation email before you register for an
exam? That's right you can't. You prick.
(b) When have you ever asked a lecturer to register you for an exam?
Thas right, you havent.cunt

Further Language Elements

Interaction References
These allow you too integrate one sequence diagram into another:
❖ Allows you to reuse interactions that you already made(modelled)
❖ Allows you to break down complex interactions

Gates
Allows you to send and receive messages beyond the boundaries of the
interaction fragment

Continuation Marker
❖ Modularizes the operands of an alt fragment
❖ Breaks down complex interactions into parts and connect them to
one another with markers
❖ Start marker points to target marker
❖ No return to the start marker (in contrast to an interaction reference)

Local attributes and parameters

❖ Every sequence diagram is enclosed by a rectangular frame with a
small pentagon in the upper left corner
❖ Keyword sd, name of the sequence diagram, parameters (optional)
 Time Constraints

These specify the time of which the event occurs, or a time period between
two events.
You can have either absolute times(at 12:00, {12:00}), relative times(time it
is not + 5 minutes,{after(5min)}), or time intervals.

State Invariants
A state invariant asserts a certain condition must be fulfilled at a
certain time. It is always assigned to a specific lifeline. The evaluation
of whether the invariant is true takes place before the subsequent
event occurs. If the state invariant is not true, either the model or the
implementation is incorrect.

There are three options:

★ You can specify state invariants within curly braces on a specific
lifeline
★ You can attach it as a note
★ You can place it in a rectangle with rounded edges at the
corresponding lifeline

Notation
 The State Machine Diagram

Using a state diagram you can model the possible states for the object in
question, how state transitions occur as a consequence of occurring
events, and what behaviour the system or object exhibits in each
state.
A state is in a round rectangle with round corners, all internal activities are
executed however if internal activities must be specified it is divided into
two compartments.

Figure 5.3 shows an extension of the example from Figure 5.1. As

long as a lecture hall remains in the state free, that is, as long as the state
free is active, the activity Display as available is executed and the lecture
hall is displayed in the reservation system. If the lecture hall is occupied,
it changes from the state free to the state occupied. At the moment the
lecture hall enters this state, the activity Save user reservation is executed
and the name of the person occupying the lecture hall is saved. While the
lecture hall remains in the state occupied, the activity Display as occupied
is executed. Once the lecture hall is no longer required, it is released and
changes to the state free. When the lecture hall exits the state occupied,
the activity Delete user reservation is executed.
The change from one state to another is called a state transition, A
transition is represented with a directed edge(an arrow),

The origin of the transition is referred to as the source state and

the end of the transition is referred to as the target state.
What does this do? Go to page 98 in the book for answers.

Types of transition
 speaks for it self really

exactly one entry point, used to model alternative

transitions. The incoming edge is used to model the event that triggers the
transition, on the outgoing edges you have guards showing alternative
parts. To ensure it doesn't get Stuck guards must cover all possible
conditions.

A and B show the same thing, however C and D are different. Look closely,
in C b is always incremented by 1 but in D B is only incremented if the
guards are met.
 one transition goes into two ore more states

two ore more transitions go into one state.

No guards are needed for both.

Types of State Transitions

Why? Hmmmm go to page 93 for answers.
 Types of Events

*The signal event is used for asynchronous communi-

event name(arg1,arg2) cation. In this case, a sender sends a signal to a
receiver and does not wait for an answer.
When revising go to the lab and look at the quiz questions and answers

Composite States

A composite state, also referred to as a complex state or a nested state,

is a state that contains multiple other states as well as pseudostates. The
states contained within a composite state are referred to as its substates.
 Orthogonal States

Only one substrate can by active at one time, if you want concurrency you
use orthogonal states.
 SubMachines

If multiple state diagrams share the same behaviour it is not practical to

keep on rewriting these, thats what sub machines are for.
The name of the submachine state takes the form state:submachine state.
In addition, you can optionally annotate the submachine state with a
refinement symbol.

It is analogous to subroutines

Example:

Entry and Exit Points

These are for when you want to enter and exit the states from a point other
than initial and final states,

Figure 5.16(a)shows a modification of the example from Figure 5.13.

Instead of the transition leading directly to S1.2, an entry point is used.
In the same way, S1.1 is exited via an exit point. Figure 5.16(b) shows

the external view of S1. The entry and exit points are visible as inter-
faces to S1 but the detailed structure of S1 remains invisible for external
Transitions.

History State

History states are used when you enter a composite substrate and wish to
return to the state it was at before it entered the substrate.
It can have any number of incoming transitions but only one out going, it
must have no events or guards on its transition. Also if it entered the
substrate and there was no last active state it continues as normal.

There are two types of history states, shallow history state and deep history
state. (each composite state can have a maximum of one of each of the
history states present!), the shallow history state restores the state that is
on the same level of the composite states as the shallow state itself, the
deep history state can restore the last active substate.

the last active substate over the entire nesting depth.

Figure 5.18 illustrates the difference between the shallow and the
deep history states with an example.
 Final examples

Figure 5.19 shows the states that a student takes during a study pro-
gram. Initially, a study program is inactive. If the tuition fees have been
paid (and thus the student has registered for the study program), the

study program becomes active. Tuition fees must be paid at the begin-
ning of every semester. If this does not happen, the study program be-
comes inactive again. During the course of an active study program, the

student progresses through the levels bachelor, master, and doctorate. If

the student does not pay the tuition fees for a particular semester—for
example, because the student wants to take a break for one semester—
after this semester, it should be possible for the student to return to the
stage of the study program that was reached before the break. The deep
history states that this is possible.
WHEN REVISING TRY AGAIN, DON'T LOOK AT VALUES, IMPORTANT
THING IS TO REMEMBER THE STRUCTURE OF THE TABLE
EVENT, STATE ENTERED, VALUES, IF NEED HELP LOOK AT PAGES
115 IN THE BOOK FOR IN DEPTH EXPLNATION
 The Software Process

The waterfall model

1. Requirements analysis and definition: The systems services,

constraints and goals are created and established, found by
researching and asking system users, they are defined in detailed
and serve as a system specification.
2. System and software design: Allocates the requirements to either
hardware or software, establishing an overall system architecture.
Software design involves identifying and describing the fundamental
software system abstractions and defining their relationships.(all that
uml shit)
3. Implementation and unit testing: Translate the design into an
executable program, all that java shit. Unit testing involves testing
each part of the program, to make sure each “unit” meets
specification.
4. Integration and systems testing: The individual units put together
and tested as a whole, then given to users to test.
5. Operation and maintenance: Longest part of the life cycle! The
system is installed and put into practical use. Maintenance corrects
any errors found that were not discovered in earlier stages of the life
cycle.
In water fall before the next phase starts there needs to be a lot of
documentation done and it needs to be signed off before moving on to the
next stage - do you see the issue here - often the phases may overlap for
example you may come across an error in design whilst coding.
Remember SOMETHING ALWAYS GOES WRONG, ALWAYS!

If something needs to be changed, you need the customer to approve it,

this takes too much time.
 The prototyping model

Create code fast, show user, discard it, make changes, do it again until
user is satisfied.
Risk is severely reduced as the user is seeing what they're going t get as it
evolves, they aren't going to get one whole system in 6 months, you don't
want this(cough cough waterfall)

Extreme programming

Extreme Programming (XP) is an agile software development framework

that aims to produce higher quality software and higher quality of life
for the development team. XP is the most specific of the agile frameworks
regarding appropriate engineering practices for software development.

When do you use XP?

● Dynamically changing software requirements.
● The technology you are using allows for automated unit and
functional tests.

The five values of XP

Communication
Communication, relies on transfer of knowledge of one team member to
another, could use face to face discussions with the aid of whiteboard(or
other drawing mechanisms)
 Simplicity
“what is the simplest thing that will work?”The purpose is to avoid wasting
time on useless things, focussing on what's absolutely necessary. Keep it
as simple as possible so testing, maintaining and supporting of the program
is easier
Feedback
Through constant feedback of previous efforts, teams can identify areas
that require improvement. Using constructive criticism allows for better
code
Courage
“effective action in the face of fear”, . You need courage to raise
organisational issues that reduce your team’s effectiveness. You need
courage to stop doing something that doesn’t work and try something else.
You need courage to accept and act on feedback, even when it’s difficult to
accept.
Respect
The members of your team need to respect each other in order to
communicate with each other, provide and accept feedback that honors
your relationship, and work together to identify simple designs and
solutions.

Practices in XP
Sit Together
Communication is one of the 5 values, sitting together allows for better
communication
Whole Team
A cross-functional group of people with the necessary roles for a product
form a single team.
Informative Workspace
The code is OUR code not MY code, transparency in work, give private
time when needed.
Energised Work
Keep productive, stay healthy, don't overwork yourself(don't over work
other team members), when you work it should be productive.
 Pair Programming
Pair Programming means all production software is developed by two
people sitting at the same machine. The idea behind this practice is that
two brains and four eyes are better than one brain and two eyes. You
effectively get a continuous code review and quicker response to nagging
problems that may stop one person dead in their tracks.

Stories
Describe what the product should do in terms meaningful to customers and
users, stories should be short and concise.
Weekly Cycle
The Weekly Cycle is synonymous with an iteration. In the case of XP, the
team meets on the first day of the week to reflect on progress to date, the
customer picks the stories they would like delivered in that week, and the
team determines how they will approach those stories. The goal by the end
of the week is to have running tested features that realise the selected
stories.
Intent is that customers have something to give feedback on(one of the
values)
Quarterly Cycle
Plan what you want to achieve by the end of the cycle, give customer
details of each weekly cycle.

Slack
Low priority user stories, can be dropped if team is swamped.
Ten-Minute Build
Make sure testing and build of a system takes 10 minutes, encouraging
testing to take place more often(if its longer than 10 minutes you are not
likely to do it frequently, the more tests the merrier)

Continuous Integration
Test code as soon as it added to a larger code base, to ensure code is
robust and works well with all other code.
 Test-First Programming
Write failing automated test -> Run failing test -> develop code to make test
pass -> run test -> repeat

Test driven development (tdd), resolving issues earlier.

Incremental Design

The practice of Incremental Design suggests that you do a little bit of work
upfront to understand the proper breadth-wise perspective of the system
design, and then dive into the details of a particular aspect of that design
when you deliver specific features. This approach reduces the cost of
changes and allows you to make design decisions when necessary based
on the most current information available.

Roles in XP

The Customer
The customer makes all the business decision regarding the project
including: What should the system do? How do we know when the system
is done? What is our budget? What should we do next?
Assumed to be a single person involved and engaged in the project.
The Developer

Developers are responsible for realising the stories identified by the

customer.

The Tracker

This is often one of the developers who spend part of their time each
week filling this extra role. The main purpose of this role is to keep track
of relevant metrics that the team feels are necessary to track their progress
and to identify areas for improvement. Key metrics that your team may
track include velocity, reasons for changes to velocity, amount of overtime
worked, and passing and failing tests.
The Coach
The main value of the coach is that they have gone through it before and
can help your team avoid mistakes that most new teams make.