Chapter 4.

From the system specification to the layers’ specification

1. Consider the functionality NewEnrollment in a registration system at the FIB-UPC.

Students enroll in all the courses at once, according to their enrollment potential set. The
number of ECTS of each course and the price per ECTS are known. The essential use case
is:
actors Student, Secretary
precondition The Student has not enrolled in any course
main flow
1. The Student goes to the FIB secretary for enrolling
2. The Student communicates its identity card Lumber (dni) to the
Secretary
3. The Secretary introduces the dni in the System
4. The Student indicates to the Secretary the name of a course in which
she wants to enrol in
5. The Secretary introduces the name in the System
6. The System shows the accumulated price of the enrol
Steps 4 to 6 are repeated until the student has enrolled in all the
courses she is interested in
7. The System shows the position of the student in a ranking of
8. The Secretary communicates the total price of the enrol to the
Student
9. The Student goes home happy as a clam
extensions
dni-not-exists: There is not a Student with the given dni (3)
1. The System warns the Secretary that there is not a student with
that dni
2. The use case ends
course-not-exists: There is not a course with the given name (5)
1. The System warns the Secretary that there is not a course with that
name
2. Go to step 4 in the main flow
course-not-valid: The course does not belong to the enrolment potential
set of the Student (5)
1. The System warns the Secretary that the Student cannot register in
that course
2. Go to step 4 in the main flow
course-already-enrolled: The Student is already enrolled in that course (5)
1. The System warns the Secretary that the Student cannot register in
that course
2. Go to step 4 in the main flow

The conceptual model is:

And the behavioural model:

-1-
context getStudent(dni: String): Student
pre 1.1: exists some student with dni
pre 1.2: the student is not yet enrolled in any course
post 2.1: result = instance of Student with that dni

context newRegistration(al: Student, nameA: String): Float

pre 1.1: exists some course with nameA
pre 1.2: the student al is not enrolled in the course nameA yet
post 2.1: nameA is part of the enrollment of the student al
post 2.2: result = accumulated price of the enrol

context endEnrollment(al: Student)

post 2.1: result = position of al in a price ranking

Finally, the team of graphical designers has designed the GUI shown in the figure below.
We may notice that the student is identified by its fiel dni in a field text (named dni, (A)).
There is a combo box that contains the enrolment potential set (named Potencial, (B)),
from which the courses are selected one by one (by clicking on the arrow) and then
translated into the list of courses already registered (named Matrícula, (C)). The
accumulated price is shown in a numeric field (named preu, (D)). The ranking is shown in
a numeric field (named rànquing, (F)) once the buttong <<OK>> is pressed. There is a
message area (E). The operation can always be cancelled by pressing <<CANCEL>>.

dni 12345678A Potencial Matrícula

ER TC

preu DSBW VIG

150,40
PESBD Bridge
PXC
rànquing 4 IA

OK Cancel

<<Zona de missatges d’error>>

-2-
Last, let’s assume that the courses that are being enrolled become persistent (i.e., they are
stored in the data base) as soon as the student selects them. We ask for (1) write the
concrete use case; (2) if necessary, modify the behavioural model according to these
changes; (3) justify the assignment of responsibilities to layers according to the
predominant pattern Domain Model; (4) write the contracts of the Presentation Layer; (5)
write the contracts of the Domain Layer; (6) apply the normalization process to the
Domain Layer; (7) write the contracts of the Data Layer; (8) complete the sequence
diagrams for the relevant presentation events.

2. ...

3. This exercise refers to the case “Registration” of exercise 1:

(a) Assume that when assigning responsibilities to layers, we decide to assign to the
presentation layer a new responsibility: to keep the accumulated price of the
registration. Analyse the impact of this decision in the solution.
(b) Assume that we take the decision of making the registration persistent at once
altogether at the end of the use case. Analyse the impact of this decision in the
solution.
(c) Repeat the previous point assuming also that when assigning responsibilities to
layers, we decide that the operation that treats the presentation event of clicking the
right arrow icon, must be under complete control of the presentation layer, without
communicating with the lower layers.
(d) …
(e) …
(f) We want to design a use case for consulting the registration of a student. Here you
have the essential use case and the behavioural model. Also, an external design is
proposed. Repeat the typical process of responsibility assignment assuming now
Transaction Script as dominant pattern.
Use case model
use case Consult Registration
actors Teacher
main flow of events
1. The Teacher accesses to a terminal
2. The Teacher introduces the dni of the student in the System
3. The System shows the subjects registered by the student and the total of registered credits
4. The Teacher leaves for a coffee break
extensions
student-does-not-exist: There is no student with this dni (2)
1. The System warns the Teacher that he has mistaken when introducing the dni.
2. The use case ends.
not-registered:The student is not registered (2)
3. The System warns the Teacher that the student is not registered.
4. The use case ends.
Behavioural model
Sequence diagrams and constracts of the use case Consults Registration

-3-
 :Teacher :System

consultsRegistration(dni): lSubj + nbCredits

context consultsRegistration(dni: String): Set(String) + Integer

pre: exists a Student with dni
post: result.lSubj = name of the student with dni
post: result.nbCredits = total number of credits of the student
External design
The dnis of all the students are shown in a combo box <<A>>. The teacher selects one and
presses <<OK>>. The system shows the list of registered courses in <<B>> and the total
number of credits in <<C>>. Error messages are shown in <<D>>. The operation can be
cancelled with <<KO>>.

dni 456666221Q Subjects Enrolled

432499052G ER
346578745H DSB
865875698T W
PESBD
454875837F PXC
credits 18 IA

OK KO

<<Message area>>

(g) Repeat the same use case considering that the students, in addition to the dni, have
a name that is NOT an identifier. Then, assume that the system shows in <<A>>
not dnis but names of students and, in case there is more than one student with the
same name, if this name is selected, an auxiliary combo box will appear with one
entry for each student with that name, together with the dni, and then the teacher
selects again.

4. ...

5. Let’s consider the specification below for a news agency:

use case Read News
actors Reader
main flow:
1. The use case starts when the Reader wants to access some news from the agency
2. The Reader communicates to the System her name
3. The System shows a combo box of news headlines belonging to the categories in which the Reader
is interested
4. The Lector selects one headline from the combo box
5. The System show the news’ body
extensions:
reader-not-exists: There is not a lector with the given name (1)

-4-
 1. The System indicates this situation
2. The use case ends
not-interested-in: The reader is not interested in any category (3)
1. The System indicates this situation
2. The use case ends
no-news-are-good-news: There is not any headline in the categories the reader is interested in (3)
1. The System indicates this situation
2. The use case ends

News Category Reader

* Belongs-to * * Interested-in *
headline name name
body

Integrity constraints: name is key of Reader, name is key of Category, headline is key of News

:Reader :System
getHeadlines(nameR): Stit + reader

getNews(reader, headl): bodyN

context getHeadlines(nameReader: String): Set(String) + Reader

pre: 1.1 exists the reader nameReader
post: 2.1 result.reader = reader of name nameReader
post: 2.2 result.Stit = headlines of the news belonging to the categories in which the reader is interested
context getNews(reader: Reader, headl: String): String
-- Obté les dades d’una notícia
pre: 1.1 headl is the header of some news belonging to the categories in which the reader is interested
post: 2.1 result = body of the news headl

Let’s suppose that the external design of the GUI works as follows: (1) the reader enters
her name in a text field and presses OK; (2) the system creates a combo box with all the
headlines of the news belonging to the categories in which the reader is interested; (3) the
reader selects one; (4) the system shows in two text fields the headlines and the body of
the selected news. You may use an error area for messages. Design the use case Read
News using Domain Model as dominant pattern.

6. Let’s consider the following specification:

use case New Vehicle

actors Administrator
precondition ---
main flow
1. The Administrator indicates to the System that, today, a person has used a vehicle, for some reason
2. The System shows the accumulated total number of uses of that vehicle
extensions
name-not-exists: There is not a person with the given name (1)
1. The System warns the Administrator that there is not a person with that name
2. The use case ends

-5-
vehicle-not-exists: There is not a vehicle with the given plaque (1)
1. The System avisa a l’Administrador that there is not a vehicle with that plaque
2. The use case ends
already-said: The System already knows that someone had used that vehicle in that date (1)
1. The System warns the Administrador that someone had used that vehicle in that date
2. The use case ends

use case What has been done with my vehicle

actors User
precondition ---
main flow
1. The User inputs her name in the System
2. The System shows the vehicles that are owned by the User
3. The User inputs a vehicle and a date
4. The System shows the people that has used the vehicle in that date and the reasons why they have been
used
Steps 3 and 4 are iterated whilst the user wants to query more uses of vehicles
5. The User goes away happy as a clam (or not)
extensions
name-not-exists: There is not a person with the given name (1)
1. The System warns the User that there is not a person with the given name
2. The use case ends
vehicle-not-exists: There is not a vehicle with the given name (3)
1. The System warns the User that there is not a vehicle with the given plaque
2. Go back to step 3 of the main flow
future-date: The date is greater than today (3)
1. The System warns the User that the date is greater than today
2. Go back to step 3 of the main flow
no-owner: The vehicle is not owned by the User (4)
1. The System warns the User that she is not the owner of this vehicle
2. Go back to step 3 of the main flow
1 *
* Person owner Vehicle
name: String * 0.. 1 plaque: String
oficial: Bool
0.. 5 uses
autorises
* Date
Uses
date: Date
reason: String

Integrity constraints:
- Keys: (Person, name); (Vehicle, plaque); (Date, date)
- The user of a vehicle must be its owner or must have his/her authorization
- A person cannot authorise him/herself

Sequence diagram of New Vehicle

:Administrator :System

newVehicleUsage(nam, plaq, why): nbUses

context newVehicleUsage(nam: String, plaq: String, why: String): Integer

-- records that the person nam has used today the vehicle plaq for the reason why
-- returns the number of uses of the vehicle plaq

-6-
 pre: exists a person nam
pre: exists a vehicle plaq
post: records an usage of the vehicle plaq by the person nam in the date today()
post: result = number of accumulated uses of the vehicle plat

Sequence diagram of What has been done with my vehicle

:User :System

allMyVehicles(nam): pers+Splaq

loop whoUsedIt(pers, plaq, date): Set(name+why)

context allMyVehicles(nam: String): Person+Set(String)

pre: exists a person nam
post: result.pers = the person with that nam
post: result.Smatr = set of plaques of the vehicles owned by nam

context whoUsedIt(pers: Persona, plaq: String, date: Date): Set(String+String)

pre: plaq is owned by pers
pre: date >= today()
post: result = set of names and reasons of the people that used the vehicle plaq
a) Make the design of the New Vehicle use case with the external design:

Plaque Reason

Users
Total

OK Cancel

Error area

i) The administrator enters the plaque of the vehicle and then the combo box
<<B>> is filled with the name of the users authorised by the including in first place (and
selected by default) the owner him/herself. The administrator selects the user and gives a
reason, and finally confirms or cancels.
ii) Now assume that the system, first of all, presents a combo box <<F>> with the
list of all the official vehicles since it has been observed that they are the most used. The
administrator has the option of selecting a vehicle from <<F>> or else to input the plaque
in <<A>> as before. Analyse the impact of this alternative over the solution (i) above.
iii) The same as before, but now the system shows in that combo box but the 10
most used until the moment.
b) Do the same for the second use case.

-7-
 i) Assume the external design below, where the information flows corresponds
basically to the one in the essential use case:

Name User Reason

Vehicles Date

OK Cancel

Error areas

ii) Discuss and analyse other possible external designs.

7. ...

8. …

9. ...

10. ...

-8-
11. (Examen final ES2 Juny 07) ...Done at the classroom.

12. (Examen parcial ES2 Nov. 06) Consider an Information System for managing
orders. The buying companies establishes agreements with the services delivered by
supplier companies in a given date dateA. They also may place orders in a certain date
dateO. In a given moment (dateP) the dates become planned, with a supervisor assigned
that earns some given money. When the order is closed, it may be the case that some of its
products are still missing (lack of stock, for instance). The system also registers the tax
that the EC imposes on these transactions, in a form of percentage (e.g., 17%). Here you
have the specification:

Integrity constraints:
RT1. Keys: (Company -> nif), (Product -> code), (Supervisor -> dni), (Order -> codeC)
RT2. A buying company cannot place more than one order in the same data.
RT3. The products that compose an order must be supplied by some supplier company that has an
agreement with the buying company that places the order.
...other constraints not relevant for the problem
Derived information:
ID1. /nbord = number of orders of the company
ID2. /nbClosedOrd = number of orders closed made by the company

-9-
Consider a use case New Order with the behavioural model:

: Administrator : System
createOrder(nifC, codeO, dateO): ord

loop newProduct(ord, codeP): acumPrice

endOrder(ord): totalPr

context createOrder(nifC: String, codeO: Integer, dateO: Date): Order

pre exists-company: exists the company nifC
post new-order: creates and order o with codeO as InProcess
post assoc-company: links the company nifC with the order o
context newProduct(o: Order, codeP: Integer): Integer
pre exists-product: exists the product codeP
pre prod-no-order: the product codeP does not belong to the order o
post assoc-prod: bounds the order o with the product codeP
post calc-price: result = accumulated price of the order o
context endOrder(o: Order): Integer
post calc-how-many: result = number of products of the order o

a) propose a external design for the use case according to the conditions stated below
b) modify the behavioural model according to this external design
c) provide the contracts of the operations that belong to the domain model
d) show which presentation events invoke which operations in the domain layer
e) apply the normalization process to the data conceptual model, materializing the
derived information

Conditions. Your solution should promote that the presentation layer assumes as much
responsibilities as possible. Assume that the data is made persistent as it is communicated
to the system

13. (Examen parcial ES2 Maig. 07) Done at lesson time.

14. (Examen parcial ES2 Maig. 06) Done at lesson time.

15. (Examen parcial ES2 Des. 05) An Orchestra is an aggregation of Musicians that are
specialist in some instrument:
Musician Orchestra
* 0..1
name: String name: String
instr: String belongs /nbMembers: Int

RT1. Keys: (Musician, name); (Orchestra, name)

ID1. /nbMembers = number of musicians of the orchestra
We are interested in two use cases: creating a new orchestra and obtaining the number of
orchestras that have more musicians in their staff that a given number. The sequence
diagrams are:

- 10 -
 CreateOrchestra BigOrchestras
: User : System : User : System

newOrch(nameO)
bigOrch(quant): Int
loop newMusic(nameO, nameM)

nbMusics(nameO): Int

Let’s assume that, once done the assignment of responsibilities to layers, the contracts of
the domain layer operations are:
context newOrch (nameO: String)
exc 1. There is already an orchestra with name nameO
post 2. Creates a new Orchestra with name nameO and without members
context newMusic (nameO: String, nameM: String)
pre there is some orchestra with name nameO
pre there is some musician with name nameM
pre the musician nameM is not assigned to any orchestra
post 2.1 links the orchestra nameO and the musician nameM
2.2 increments nbMembers of the orchestra
context bigOrch (quant: Int): Int
post 1. result = number of orchestras that have nbMembers > quant

L’operació nbMúsics desapareix de la capa de domini perquè queda assignada

completament a la capa de presentació.

Let’s assume that for some reason the navegability is predefined from Musician to
Orchestra. Assume also that the derived information is materialized.

- 11 -
Show a external design that matches with the domain layer specification given. Create the
sequence diagrams that correspond to the relevant presentation events, showing the three
layers. If you think that some responsibility is missing in some of the contracts given, you
may ad dit, but you cannot add new operations, just new pre/exc/post in the contracts.

16. (Acte avaluatori curs 07/08) ...

17. (Acte avaluatori 07/08 1q) Already available at the Racó

- 12 -