 Graphical User Interfaces (GUIs): (partial) depiction of the GUI that will be eventually shown to users,

obtained with mockups and sketches (e.g., Balsamiq).

Figure 21 - GUI sketch

 Procedural Interfaces: documented and ordered set of methods and procedures of the system,
described with PDL (Program Design Language).

Figure 22 - PDL Interface Description

 Data Exchanged: the interaction is described only by the data that is given as input or output to the
system and actors. XML and Json can be used to describe the exchanged data in a standardized way.

Figure 23 - Description of Data Exchanged, with XML

Context diagrams are typically represented with the UML Use Case Diagram (UCD) technique. In the context
diagram, the central entity represents the system, which is connected to a set of actors interacting with it.
The context diagram must always be coupled with the definition of the interfaces, as in the following
example.

Figure 24 - UML UCD for a POS System

Physical Interface Logical Interface

Cashier Screen, keyboard GUI (to be described)
Product Laser beam (bar code reader) Bar code
Credit Card system Internet connection Web services (functions to be
described, data exchanged, soap
+ XML)
Inventory and catalogue Internet connection Web services (functions to be
system described, data exchanged)

Table 10 - Interfaces for the POS System

3.3 Requirement Types

Requirements can be subdivided between Functional and Non functional requirements, with the addition of
Domain requirements that are taken from the related domain, and not proper of the system under
development.

3.3.1 Functional Requirements

Functional requirements are the ones that specify the behaviour that the system should have. Functional
requirements can be related to hardware, software or both, to calculations, technical details, how data will
be processed. They also include the description of services, from a high level point of view.

Functional requirements can be related to the application (something that the software should do) or to the
domain (requirements that are related to the domain of the application, e.g. for law or regulamentations
related to a specific category of systems). To make the requirements clearer, it is common to use a glossary,
with the words that are used to describe the functions.

3.3.2 Domain Requirements

Domain requirements are derived from the application domain, and describe system characteristics and
features that reflect the domain. As said, these can be functional requirements, but also constraints on
existing requirements or definition of specific computations. If some domain requirements are not satisfied,
the system may be not workable.

For instance, the following is a Domain Requirement for an healthcare system, that must be compliant to the
regulamentation that exists in its domain:

The system safety shall be assured according to standard IEC 60601-1: Medical Electrical Equipment
– Part 1: General Requirements for Basic Safety and Essential Performance.

Another example of a Domain Requirement may be a description of how to carry out some computations,
using domain-specific terminology. The following requirement is about the computation of the deceleration
in a train control system:

The deceleration of the train shall be computed as: D_train = D_control + D_gradient
Where D_gradient is 9.81ms2 * compensated gradient/alpha and the values of 9.81ms2/alpha are
known for different types of train.

Domain requirements have often problems of understandability and implicitness, since they are typically
expressed in the language of the application domain and may not be understood by software engineeres:
the use of a glossary may help solving this issue. Also, domain specialists understand the area so well that
they may not think about making the domain requirements explicit.

3.3.3 Non Functional Requirements

Non Functional (NF) requirements are those that specify constraints on the system/service. Non Functional
requirements are very general (they may pertain many different aspects of the system) but they are of
mandatory importance.

According to ISO 9126 / ISO 25010, five categories of Non Functional requirements can be identified (the
Functional requirements are considered under a sixth category of requirements, called Functionality
requirements). In general, it is possible to identify a higher number of categories of Non Functional
requirements, with a prior distinction between Product, Organisational and External requirements.

Figure 25 - Non Functional Requirements Taxonomy

  Product requirements: requirements that specify that the delivered product must behave in a
particular way:
o Usability: satisfaction obtained by the user while interacting with a system, and training time
needed for a user to learn to use the software.
Example: non trained user must be able to use the functionalities of the application in half an
hour.
o Efficiency: performance of the software, space and time needed for performing its
functionalities.
Example: waiting times of the application must be < 1 second (according to a theory of
perception of waiting times, while delays shorter than 0.1 seconds are not perceived, users
are annoyed by response time that are longer than 1 second).
o Reliability: security of the software, availability (capacity of being working in almost all
situations), accuracy of the offered behaviour.
Example: system should work 99.9% of the time.
o Maintainability: how much is easy and cheap to maintain the system, changing hardware
and software components when it is needed (e.g. for new requests from clients, or for bug
fixes).
o Portability: how much is easy to make the software work on different platforms, domains or
environments.
 Organisational Requirements: Requirements that are a consequence of organisational policies and
procedures of the company.
o Delivery: Constraints on the delivery of the final system, and characteristics that it should
have.
o Implementation: Constraints on the components, languages and practices that must be used
in the development of the system.
o Standards: Policies and standards that must be adopted mandatorily in any project of the
company.
 External Requirements: Requirements that arise from factors that are external to the system and its
development process.
o Interoperability: Capability of the system to work in conjunction with other specified system.
o Ethical: Possibility of the system to raise ethical issues.
o Legislative: requirements about the possibility that the system or software may create harm
to people or things, and regulamentations about the privacy of the users.
Example: user name and password of the user must not be disclosed outside the software.

Non Functional Requirements can be formulated in a way that is measurable or not:

 Not Measurable: a general rule, for which no specific parameters are specified.
The system should be easy to use by experienced controllers, and should be organised in such a way
that errors are minimized.
 Measurable: it is specified a metric and a way to measure it on the system, with parameters
(numbers) that tell whether the system satisfies the requirements or not.
Experienced controllers shall be able to use all the system functions after a total of two hours training.
After this training, the average number of errors made by experienced users shall not exceed two per
day.
Since Non Functional requirements must be evaluated and verified on the working system, they should
always be measurable.

Property Measure
Speed Processed Transactions / second
User / Event response time
Screen Refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Table 11 - Measures for NF Requirements

Often the Non Functional requirements are more critical than the functional ones; if they are not met, the
system may be useless. For instance, a real time system must be very fast to report changes, and it is useless
if its latency is higher than 1 second.

In complex systems, it is also frequent the presence of conflicts between different Non Functional
requirements. These conflicting situationsmust be handled, and in general a prioritization of the
requirements must be adopted, in order to identify the most important ones that should always be satisfied.
As an example, consider a spacecraft system:

o To minimize weight, the number of separate chips in the system should be minimized;
o To minimize power consumption, lower power chips should be used;
o Using low power chips may mean that more chips have to be used: which is the most critical
requirement?

3.3.4 Writing Requirements

Requirements are written in the Requirements section of the Requirements Document. Usually, all
requirements are assigned an ID, useful for a fast identification. The ID indicates the type of the requirement
(F, NF, Domain) and a progressive, unambiguous number.

Also, requirements can be nested: this means that there may be a main function (e.g., F1 – manage sensors)
and, under it, a set of sub-functions composing the main one (e.g., F1.1 – setup sensor, F1.2 – insert sensr in
sensor list, F1.3 – get sensor information).

Requirement ID Description
F1 Handle sale transaction
F2 Start sale transaction
F3 End sale transaction
F4 Log in
 F5 Log out
F6 Read bar code
NF1 (efficiency) Function F1.1 less than 1msec
NF2 (efficiency) Each function lessthan 0.25sec
Domain1 Currency is Euro – VAT computed as…
Table 12 - Functional Requirements for the POS System

3.4 Glossary
The Glossary gives, in a readable way, an explanation for all the terms used in the rest of the requirements
document. It is useful to help developers and software engineers in understanding the domain language.

Sale = Commercial transaction between customer and retailer, where customer buys a number of
products from the retailer.

The glossary can be refined and accompanied by an UML Class Diagram. Class Diagrams can also be used to
describe the application model and the system design.

In the UML Class Diagram, elements of the system to be described in the glossary are represented as Classes.
Classes are described by a sets of attributes, with the relative description, rather than by their behaviour. As
in object-oriented programming, classes are used to generate instances of objects, all with varying attributes
but with the same structure.

The Glossary well represents only static relationships and associations between objects (classes). To
represent dynamic associations between parts of the system, it is better to use scenarios (or use case
diagrams) or sequence diagrams). Also, the Glossary is not made to design classes of the software (this is a
design task) but to clarify the elements of the system and their relationships.

Figure 26 - Glossary (Class Diagram) for the POS System

Classes may represent different types of elements of the system:

 Physical objects: a physical element / person that is part of the system or interacts with it (e.g., Pilot,
Airplane, Airline, Airport);
 Legal / Organizational entities: an organization which has a role interacting with the considered
system (e.g. Company, Airline, University, Department);
  Descriptors: a standardized attribute for another class, that can assume one of a given set of values
(e.g., Aircraft type, Pilot Qualification);
 Time (Events): date and timestamps of occurrence of events of importance in the system (e.g.,
Departure of an aircraft);
 Time (Intervals): classes representing periods of time of situations of importane for the system, that
last a certain amount of time; they usually have a start date and an end date (e.g., Flight Internship);
 Commercial Transactions: record of the execution of a money exchange between other elements of
the system, themselves represented by classes (e.g., insurance payment).

3.5 Scenarios and Use Cases

3.5.1 Scenarios

A scenario is a sequence of steps that describe a typical interaction with the system. It is made to show how
things change over time, not to give a static depiction of the system: hence, it is complementary to the
sequence diagrams and use case diagrams.

A scenario is often represented as a table having two columns: step number and description. Each row in
the scenario represent a step of the interaction with the system. In a requirements document, there may
be many scenarios, even hundreds. Scenarios do not require a high level of detail in their definition, since
they should abstract the function of the system that must then understended and developed by the
developers. Low level details in scenarios would create unuseful noise.

Step Description
1 Start sales transaction
2 Read bar code
3 Retrieve name and price, given barcode
Repeat 2-3 for all products
4 Compute total
5 Manage Payment with cash
6 Deduce amount of product from stock
7 Print receipt
8 Close transaction
Table 13 - scenario for a transaction

3.5.2 Use Cases

A Use Case is a set of scenarios with common user goal (e.g.: All types of subscription with different payment
system that can be successful or not) and is useful to give a picture of what the system offers. It is a summary
of a high level functionality that the system offers. The use case wraps up nominal scenarios (the basic ones,
which clarify the goals of the Use Case) and exceptions scenarios.

Use Case: Handle sales

scenario 1: sell n products;
scenario 2: sell n products, abort sale because customer has no money;
scenario 3: sell n products, customer changes one of the products.
Often a Use Case describes a set of similar scenarios relative to the interaction of an actor with the system.
The three key pints of a Use Case are:

 The Actor: the individual entity (it can be a machine or a stakeholder) that interacts with the system.
An actor can be primary, if it starts the interaction with the system, or secondary if the interaction is
started by the system (hence, the actor is passive). It is essential that the actor is external to the
system.
 The system: the system under specification, that in this case is viewed as a black box;
 The Functional Goal: what the actor achieves by using the system.

Use case can have three scopes:

 Enterprise: business processes use case, set of activities where people and maybe also other systems
are involved. It is the highest level category of use cases;
 Software System: describes an actor and his interaction with the system, to achieve a goal;
 Software Component: interaction with a single software component; not to be considered in the
requirements specification phase but in the design phase, being at a lower level.

Use Cases are usually described with a UML Use Case Diagram (UCD). Each use case is reported in the diagram
and represents a value that the system offers to some actors. It is important to write down for each use case
its goal and its description. This information cannot be embedded in the program. Moreover it could be useful
to write down what actors are involved, for each use case.

It is important to underline in the Use Case diagram the complex peration to be performed in a certain
scenario, to let the developer have a detailed view of what should be done, and what are the key points of
the system.

Figure 27 - Use Case Diagram for the POS system

In the example given in Figure 27, three different use cases can be seen. The first one is Handle sales
(identified also by the functional requirement F1), that includes two complex operations, Retrieve Name and
Price and Handle Payment. The Include relationship is used to highlight, in the Use Case Diagram, the fact
that an interaction makes sense only if it is part of a higher level use case. Other two use cases are defined:
Manage Coupons, and Manage Users. The arrows point from the actor to the use case if the actor is active,
from the use case to the actor if the actor is passive.

It is worth highlighting that the Use Case Diagram is very similar (but more detailed) to the Context Diagram.

3.6 System Design

The system design is the definition of the elements of a system, like its architecture, components, and all
subsystems –software and not software- that compose the system.

It is an useful tool to have an overall vision of the system, to understand how the system is composed and
what are its key elements. System design can be described using an UML Class Diagram, in which –for each
element- it is important to show what are the main attributes, and the functions provided.

Figure 28 - System design for the POS System

IV OBJECT ORIENTED APPROACH AND UML
The object oriented approach has been the more influential, both in research and practice, in software
systems development in almost the last 20 years.

Unified Modeling Language (UML) is the dominant notation based on the object-oriented approach. It is
standardized by OMG (Object Management Group). There are many UML diagram templates, each one useful
in doing different tasks. For instance, the UML Class Diagram (UML CD) models structures, entities and
concepts: it is useful to design software but also to represent the system design and glossary requirements.
The UML Use Case Diagram (UML UCD), instead, is useful to represent functions, i.e. what the system can
do: in fact, it is used to represent the Use Cases and the Context of the system. Time, dynamics and temporal
constraints of a system can be modeled using UML sequence (collaboration) diagrams, statechart diagrams,
Activity diagrams.

4.1 Approaches to Modularity

Several principles exist in software engineering, about the creation of a modular structure of a system:

 P1: Low coupling and high cohesion, i.e. high intra-module correlation, low inter-module correlation;
 P2: Information hiding, i.e. interfaces representing the boundaries of each module;
 P3: Conway’s Law, i.e. the design of the system should match the structure of the company.

Those principles encourage a Divide and Conquer approach to software engineering. Given them, there may
be two approaches to implement the software: a Procedural approach, and an Object-Oriented approach.

4.1.1 Procedural Approach

In the procedural approach, the basic concept is the procedure call (or routine call, or function call), which is
a set of computational steps that must be performed.

Using a procedural approach, the techniques of structured analysis and structured design come in handy for
the performance of analysis and design of the product. Several procedural languages exist for coding: C,
Pascal, Fortran, and so on.

Procedural approach defines two different kinds of modules: the procedures, and the data on which the
procedures must work. Two different relations are defined: the call relation between procedures (with or
without parameter passing back and forth) and the read / write between procedure and data. While the call
relation creates low coupling between the involved procedures, read and write relations present higher
coupling (highest for the write relation).

The use of global declarations, in procedural approach, makes possible for read and write relations to happen
between data and any other function, without explicit declaration (in the form of parameter passing). This is
permitted and likely happens, especially in the first phases of coding and during maintenance and evolution
of the project. The presence of variables in global scopes also increases the coupling of code.

In general, the root problem of the procedural approach is the lack of an explicit link between the structured
data, and the procedures working on it.
In figure 29 and 30, respectively, an excerpt of code working on a vector and its representation in the form
of modulesand relations are given.

Figure 29 - Procedural approach - Code example

Figure 30 - Modules in the procedural approach

In the example, even though in the code excerpt the reads and writes are confined only in the functions that
receive the vector as parameter (init, and sort), they can actually happen anywhere.

The functions init(), sort() and the data element vector[20] are not linked. However, they should, as they
work in symbiosis: the parameter passing should be avoided, and the read and write relationship should be
confined only within the functions. These two principles lead to the concept of object, that is the basis of the
Object-Oriented Approach.

4.1.2 Object-Oriented Approach

The Object oriented approach identifies, as its basic module, the class. It is given support in analysis and
design by UML, and several programming languages follow the object-oriented approach: C++, Java,
smalltalk, C#, and so on.

In the OO Approach, classes describe structured (in terms of attributes) data, and procedures that can read
and write them. Objects are instances of a class, in the sense that they are described by the set of attributes
of the class, and the operations described by the procedures defined in the class can be operated on them.
No read and write operations are performed outside the class.
 Figure 31 - Classes and Objects

The OO approach introduces the message passing relation between objects, which is similar to a procedure
call with parameter passing, and hence creates low coupling. The message passing, with respect to a
procedure call, hides read and write relationships, creating lower coupling between objects. The lower
amount of relationships among objects, and the high level of abstraction of classes, allow to build more
complex systems than the ones that can be built with a procedural approach.

Information hiding is guaranteed in the OO approach by Interfaces, i.e. the only set of messages that an
object can answer to, and that are exposed to other objects.

Figure 32 - Interface exposed by an object

The translation of the vector example introduced before to the OO approach is shown in Figure 33. A class is
defined, with the declaration of data owned by each vector object, and operations that can be performed on
it: the vector() constructor, and the sort() function.

Figure 33 - OO Approach - Code example

In conclusion, objects and classes are a better modularization elements, and by construction message passing
has much lower coupling than procedure call and read/writes. The designer has the duty of deciding which
are the “right” classes to implement the system in the correct way, and to guarantee information hiding.
 Figure 34 - OO Approach and the software process

4.2 UML Class Diagrams

Class Diagrams are a notation that can be used in different documents, with different goals: User
Requirements, Developer Requirements, Model of concepts (glossary), Model of hardware + software system
(system design), Model of software classes (software) design, and so on. They allow to create a conceptual
model of the system, as a set of few domain level classes with relevant attributes and relationships. With the
support of Object-Oriented programming languages, source code can be reverse-engineered from Class
Diagrams.

4.2.1 Objects

The key concept to underline for the UML Class Diagrams is the Object: it is a model of an entity, and it is
characterized by its identity, its attributes, its behavior and the messages that can receive.

In the UML CD, an object is represented by a rectangle divided in three sections, from top to bottom:

 Identity: the name of the object;

 Attributes: properties and parameters that characterize the object;
 Behaviors: methods/functions that the object can perform.

An object diagram models the objects of interest in a specific case.

Figure 35 - Objects in the UML CD

4.2.2 Classes

A class is a descriptor of objects with similar properties. Classes can represent physical objects (e.g., Cars),
organizational entities (e.g., Companies), descriptors of objects (e.g., Product Type), time intervals (e.g.,
Flight Duration), Time Events (e.g., Departure Time), geographical entities (e.g., Region), reports (e.g.,
Report of a sensor), transactions (e.g., Product sold).

The properties that are defined in a class can be subdivided in two types:

 Attributes: the name and type of an attribute is the same for all objects and can be described in the
class; the value of an attribute may be different on each object, and cannot be described in the
class (e.g., a student object has its proper name, surname and ID, which differ from other students’
ones).
 Operations: operations are the same for all objects and can be described in the class; the operation
will be applied to different objects, possibly with different results that are based on the object’s
own attribute values (e.g., students can take an exam, and follow a course; the function is the same
for all students, but has different results based on who is the one performing it).

Objects are instances of a class. A Class Diagram models the classes of interest in a specific case.

Figure 36 - A class in the UML CD

4.2.3 Relationships

In an Object Diagram, the objects that are part of a specific case of interest may be connected by links. A link
models the association between objects.

Figure 37 - Links in an Object Diagram

Classes may be interrelated to others, in different ways. Relationships provide a mean of describing logical
connections between classes in a Class Diagram.

As objects are instances of classes, that provide for them a high level description, Relationships are
descriptors of links that apply to classes. On the other hand, links are individual instances of relationships
between classes.
 Figure 38 - Relationships in a class diagram

The existence of a relationship between two classes does not mean that all objects belonging to them have
to be linked together.

Figure 39 - Relationship and Links

Each relationship can be assigned a name, which specifies what is the kind of logical connection between
classes. The two classes involved in the relationship can be assigned a role, which specifies what are the
duties of objects of such class that form links described by the relationship.

Several types of relationships are contemplated by UML Class Diagrams, and are detailed in the following
paragraphs.

4.2.4 Multiplicity

A multiplicity is a logical association, that depicts the cardinality of a class in the relationship with another
one. Each relationship connecting two classes must specify the multiplicity of each end, that acts as a
constraints on the maximum number of links that can exit or enter an object of that class, for that specific
relationship. Different multiplicities that can be expressed in Class Diagrams are shown in figure 41. In
general, when no multiplicity is expressed on one end of a relationship, the standard multiplicity (0…*) is
assumed.

Figure 40 - Multiplicities in Class Diagrams

In the example in figure 38, we can see that the student class has a relationship with Exam, with 0 to *
multiplicity: that means that each student can take from 0 to infinite exams. Instead, Exam is connected to
student with a 1,1 multiplicity: it means that each Exam, in the system, must be taken by exactly one student.
Also, each Exam belongs to one and only one course (1,1 multiplicity), while for any Course there may be 0
to infinite (0…* multiplicity) Exams.

4.2.5 Dependency

A dependency is the least formal among all the types of relationships. It represents that one class has a form
of shallow dependency or connection on the one pointed by the arrowhead. Dependencies are represented
with dashed lines, even though there is no inclusion or direct cooperation between the classes.

Dependencies can be used when changes in one of the classes would require changes in others (that are,
hence, dependant classes).

Figure 41 - Examples of Dependencies

4.2.6 Association

Associations are the most common relationships in UML class diagrams. They define dependency, but in a
stronger way than a plain dependency relationship.

An association can be directed, if a clear active role can be identified for one of the classes at its ends, with
the other having a passive role in the logical association. Typically, a directed association is represented with
an arrow. If no clear active and passive roles are identified in the association, it is defined as bidirectional,
and arrowtips on both ends can be (optionally) used to represent it. The name of an association, and the
roles of the connected classes, reflect the fact that an association is directed or bidirectional: in general,
directed associations have a verb phrase as a name.

Figure 42 - Directed and bidirectional relationships

Associations can also aid in uncoupling the properties of objects from the object themselves: this may be
useful especially when, for one or more of its attributes, an object may assume a value that belongs to a
predefined set, or when one attribute would have, as a value, an array of a certain type of elements.

Figure 43 - Properties as attributes or relationships

4.2.7 Aggregation

An aggregation defines a class as a result of a collection of objects of another class (e.g., a Library can be
made up of one or more Books). The aggregated classes are not so strongly dependent on the container, i.e.
they can be instanced and have a lifecycle of their own even if a container does not exist. In the Class Diagram,
an aggregation relationship identifies the parent (container) class with a diamond shape.

If B is part of A, it means that the objects described by class B can be attributes of objects described by A.

Figure 44 – Aggregation Example

4.2.8 Generalization

Also called specialization, or “is-a”. One of the class of the relationship is a specific type of the parent class.
A specializes B means that the inheritance mechanism exists between A and B: objects described by A have
at least the same properties (attributes, operations) of objects described by B, and those properties do not
need to be repeated in the definition of A; objects described by A can have additional properties. It can be
said that the properties in common between A and B are inherited by A.

The specialized class can be called subclass; the parent class can be called superclass. For instance, a Human
is a subclass of Animal, that in turn is a subclass of Living Being; Human inherits the moving ability from
Animal and the living ability from Living Being, but also has some class specific abilities (e.g., thinking).

Figure 45 - Generalization Example

4.2.9 Notes

Notes can be attached to any element of the class diagram, either classes or any kind of relationship between
classes. They can be used to give additional details about the attributes or the relationships in which the
objects of a given class are involved, that are not easy to desume from the names or roles of the objects.

Figure 46 - Notes in Class Diagrams

4.2.10 DONTs for Class Diagrams

The following practices should be avoided in the definition of Class Diagrams, and of the attributes and
relationships described inside them:

 Use plurals for class names (e.g., Classrooms instead of Classroom);

 Depict transient (dynamic) relationships: they are modeled in scenarios and sequence diagrams;
 Create loops (cycles);
 Overlook multiplicities;
 Forget to define a proper goal for the diagram, confounding system/software design or glossary;
 Use classes as attributes;
 Use attributes that represent many objects (arrays);
 Repeat a relationship starting from a class as one of its attributes.
4.3 Use Case Diagrams
Use Cases are a semi-formal notation that are used in the study of the application domain of a given system.
They aid in identifying the boundaries between the system and the environment in which it is deployed, and
in highlighting the interactions between the system and actors of the external world (that can be human
stakeholders, or other systems).

Use Cases are useful to:

 Oblige the analysts to state well-defined boundaries between the system and the external world;
 Organize the functions of the system into individual elements, namely the use cases, on which the
attention is focused;
 Supply a first basis for the specification of the system structure, from the user perspective.

The UML Use Case Diagram provides readability to all stakeholders involved in a given system, even
customers / users and not only analysts and developes. Usually, Use Case Diagrams are defined before the
Class Diagrams, to provide a first functional view of a software system.

UML Use Case Diagrams are composed by three main elements: actors, use cases and relationships.

4.3.1 Actors

An actor is any person, organization, or external system, that plays a role in one or more interaction with the
system. An actor can either:

 Exchange information with the system;

 Supply input to the system;
 Receive output from the system.

Actors are typically represented as stick figures in UML Use Case Diagrams. They can be classified as primary
or secondary actors:

 Primary Actors are actors using the system to achieve a goal.

 Secondary Actors are actors that the system needs assistance from to achieve the primary actor(s).

In the Class Diagram of the system, an Actor typically becomes a class.

Figure 47 – An Actor in UML UCD

4.3.2 Use Cases

A Use Case is based on the scenarios (i.e., sequences of steps describing interactions between a user and a
system) of the system, being a set of scenarios tied by a common goal. In practice, a use case is a functional
unit (functionality) of the system, in the form of a set of steps representing an interaction between the system
and the actors.
Use cases are loosely mapped to functional requirements of the system. Each functional requirement can be
linked to a complete use case, or to an individual scenario described by a use case, or to a step in a scenario
(the mapping is not 1:1). In general, there is a subtle differences in the aims of requirements and use cases:
the purpose of requirements is to support traceability of the system, and are finer grained than use cases;
use cases are more high level, and their primary purpose is to understand how the system works.

In UML use cases are depicted as horizontal ellipses; by naming conventions, the use case names should
always begin with a strong verb, and use domain technology. Primary use cases (or use cases that come first
according to timing considerations) should be placed in the top-left corner of the complete Use Case
Diagrams.

In the Class Diagram of the system, any use case must become one operation on a class, but can also generate
several operations on multiple classes.

Figure 48 - An Use Case in UML UCD

4.3.3 Relationships

Several types of relationships are available in a Use Case Diagram, between one actor and one use case, two
actors, or two use cases.

 Associations between an actor and a use case define the participation of the former in the latter.
They can be represented with a simple straight line, but some adornments are allowed: multiplicities
can define how many actors can participate in a given use cases, or how many instances of the same
use case may be participated by the same actor; arrowheads indicate if the use case is triggered by
the actor (i.e., the actor is primary) or vice-versa (i.e., the actor is secondary).

Figure 49 - Associations in UML UCD

 Include relationships, between two Use Cases, model that the functionality A is used in the context
of the functionality B, being one of its phases. Typically, include relationships are used to extract
fragments of use cases that are duplicated in multiple use cases. If a use case includes multiple
others, they are both required in the including use case. The include relationship is represented as
an oriented arrow, directed towards the included use case, with the <<include>> keyword. It can be
also indicated as uses (e.g., in the following example, both password check and fingerprint scan are
phases of the identity verification).
 Figure 50 - Include relationship in UML UCD

 Generalization relationships, between two Use cases, model that the functionality B is a
specialization of functionality A (for instance, a special case). Typically, generalization relationships
are used to model a special case of an existing use case. The generalization relationship is
represented with a directed arrow towards the generalized use case, without the addition of any
keyword. Use cases that generalize others can stand on their own (e.g., in the following example,
either password check or fingerprint scan can be performed, on their own, as a for of identity
verification).

Figure 51 - Generalization between Use Cases in UML UCD

 Generalization relationships, between two Actors, model that an instance of the actor B can
communicate with the same kinds of use-cases of an existing actor A, plus some use cases that are
not available to B (e.g., in the case of an ATM system, a system administrator may be considered an
extension of a normal user, since he is able to perform the normal withdrawal operations plus some
additional specialized use cases).

Figure 52 - Generalization between actors in UML UCD

 Extension relationships, between two Use Cases, model that an instance of the use case B may be
augmented by the behaviour specialized by the use case A, in some particular conditions (e.g.
errors). The behavior described by B is optional, and the location where the behavior must be
executed is defined by an extension point referenced by the extend relationship.
 Figure 53 - Extend relationship in UML UCD

4.3.4 Example: student management

A student management system should provide the following functions:

 Students select courses;

 Professors update the list of available courses;
 Professors plan exams for each courses;
 Professors can access the list of students enrolled in a course;
 Professors perform exams, then record the issue of the exam for each student (pass/not pass,
grade);
 All users should be authenticated.

Figure 54 - UML UCD example: student management

In the solution shown in figure 54, three actors are considered as interacting with the system: students,
professors, and the Administrative Office. The Administrative Office acts as a passive actor, since it does not
initiate any use cases, and it is only involved in the selection of course initiated by the student. All the use
cases (the ones initiated by students, and those initiated by professors) include a procedure of
authentication, that is therefore described by a dedicated use case included by all others.
V ARCHITECTURE AND DESIGN
5.1 The Design Process

Figure 55 - Architecture and Design in the software process

While requirements specify what the system should do, Architecture and Design is the part of the software
process involved in specifying how the system will be implemented. This phase is very important, because it
aims at reducing errors in the coding part, and to avoid most logical bugs that may hamper the system: those
errors must be found early in the development process. It is essential to define, analyze and evaluate design
choices, making them explicit through the use of documents, in order to avoid errors that otherwise would
be discovered only at coding time, when making design changes becomes difficult.

If the design is not defined, but the code is developed immediately based on the requirements, design choices
are made implicitly, leading to a late evaluation of the design. The use of design docuents allows to make
explicit design choices, that can be evaluated before coding.

The fundamental difference between Architecture and Design is that, while at the very end they have the
same objectives, Architecture is higher level: defining the Architecture of a system means deciding which are
its main components, how they will be controlled and which is the communication framework defined
between them. Design, on the other hand, is lower level, and has the objecting of defining the internals of
each component of the system. The design part is often performed using UML Class Diagrams, where each
class is represented by a Class Entity in the diagrams.

Given one set of requirements, different designs (design choices) are available:

Example: for a mid sized car in price range between 10 to 20 thousand Euros, there may be hundreds
of different design choices (i.e., models in the market); not all designs are equal.

The translation of requirements into design is a creative process that cannot be completely formalized and
that is strongly driven by individual skill and experience. Semiformal guidelines, based on previous
experience, can be given about both architectural and design patterns.
5.1.1 Phases of the Requirements Process

A first characterization of the design activities can be made between the system design and software design
side:

 System Design: decisions about the structure of the system (in terms of hardware and computing
nodes, and their direct or indirect interconnections). According to the type of system being
developed (e.g., for embedded systems) the system design must include decisions about component
and connections in other technologies (electrical, electronic, mechanical).
 Software Design: upon a given system design, the software design activity defines all the software
components that will ultimately be developed, their goals, and the logical interconnections and
interfaces they provide each other.

The design process is basically made of three different parts: analysis, formalization, verification. This process
can be abstracted, as a black box that takes in input the requirements document (with all functional and non
functional requirements) and produces as output the design document (all the components and connections
between them capable of satisfying the requirements extracted from the requirements document).

Architecture Architectural Patterns

High Level Design Design Patterns
Low Level Design Classes implementation details
Formalization Text, diagrams (UML)
Verification Inspections
Table 14 - Phases of the Design Process

In more detail, the Analysis stage can be subdivided in three different phases:

 Architecture (about the whole system): definition of high level components and their interactions;
selection of communication and coordination model about eleents; selection of architectural styles
and patterns.
 High Level Design (about many classes): it is about the overall architecture of the entire system, the
definition of all the modules that will be developed, the understanding of the flow of the systems.
The outcome of the high level design is the definition of the class diagram for design, mapping classes
with attributes and methods, defining bonds between classes as simple relationships (without
defining how the relationship is implemented).
Classes can be derived from the glossary, considering a class for each key entity, and from the context
diagram (considering a class for each actor, either a physical device or subsystem, and defining the
way each actor can interact with the system).
In this phase of the design, design patterns are selected.
 Low Level Design (about single classes): the system overall view is broken down into modules, and
the internal logic design is defined for each element, according to requirement specifications. A Low
Level Design document allows the developers to code the software easily. As opposed to the High
Level Design, the Low Level Design is usually used to specify how to implement the relationships
between classes, going deeper in the design of each class.
For each class that must be developed, the low level design also defines: type and privacy of each
attribute; return type, parameters and privacy of each method; needed setters and getters.
For each object, persistency (e.g., serialization to files or network, or insertion in databases) is
defined.
In the Formalization stage, each part of the design is translated in a document, using either formal (UML) or
semi-formal methodologies and languages.

In the Verification stage, techniques for the validation of the architecture and design are executed, to
understand how the proposed design fits with the functional and non functional requirements taken from
the requirements document.

Internship Management Heating Control system

Technical Domain Web application Embedded system
Architectural Choices Client server Single computer
Layered (database, application Layered (sensor, application logic,
logic, presentation) presentation)
Repository
High Level Design (packages, Manyreused from glossary, Many rused from glossary, added
classes, relationships) choices added some (app logic level and some (app logic layer and
presentation layer) presentation layer)
Low Level Design (attributes, Common choices for Common choices for
methods, relationships) choices implementing relationships implementing relationships
Table 15 - Examples of architecture and design choices

5.1.2 Design and Non Functional Properties

A can be characterized according to its functional and non functional properties:

 Functional properties: does the design support the functional requirements, as defined in the
requirement documents?
 Non Functional Properties: does the design support the non functional requirements, as defined in
the requirement documents?

There are some guidelines that can be followed in the design phase to support the non-functional
requirements elicited in the requirements engineering phase:

 Performance: to enhance the performance of the system, the design phase should minimise the
communications between different modules, and localize critical operations, using large rather than
fine-grained components;
 Security: to enhance the security of the system, adopting a layered architecture allows to place the
critical elements of the system in the inner layers;
 Safety: to enhance the safety of the system, safety-critical features should be localized in a small
number of subsystems. As for security, a layered architecture helps in enhancing the safety of a
system;
 Availability: to enhance the availability of the system, redundant components (i.e., different
components with same functions, that can work one in place of another that stops functioning) and
fault tolerance mechanism should be adopted by design;
 Maintainability: to enhance the maintainability of the system, components should be kept as small
(fine-grained) as possible, and should provide highly replaceability.

It is evident that design choices cannot provide support to all non functional requirements at once: using
large-grained components improves performance, but removes maintainability; introducing redundant
components improve availability, but may make security assurance more difficult; at the same time, security-
related features require high amounts of communication between components, so they lead to a
degradation of performance.

It is part of the design process to decide trade offs about which non functional properties have to be enforced.
Possibly, trade offs can be decided at requirement time, and it is duty of the design phase to select the
structure of the system accordingly.

Some non-functional properties are more specific to the design phase, like the following examples:

 Testability: support to testing provided by the system. Testability is strictly linked to the availability
and complexity of the designed system. It contains the properties of Observability and Controllability.
 Monitorability: possibility of setting up activities capable of monitoring the system, its performance
and its users. It is close to the Controllability property.
 Interoperability: a property of the interfaces provided by the system. Is it easy to change a
component? Is it easy to let the system talk with other systems?
 Scalability: capability of the system to handle a growing amount of work (e.g., in terms of users to
be served), and degree of incrementation of performance when resources are added to the system.
 Deployability: how easily and reliably the software can be deployed, from the development into the
production environment (e.g., installation and upgrades of desktop software).

5.2 Notations for Formalization of Architecture

Different ways are available for formalizing the architecture of a software system, from informal ones, to
semiformal (e.g., UML diagrams, providing both structural and dynamic views), to formal Architecture
Description Languages (ADLs).

5.2.1 Box and Line Diagrams.

A box-and-line diagram depicts the components of the architectures as boxes, connected with lines. The
notation is completely informal: there are no rules governing the diagrams. Each box corresponds to a
physical component or a set of functions (subsystem). By nature, box-and-line diagrams are also very
abstract, because the nature of the relationships between components (and the nature of the components
themselves) is not clearly identified. Neither interfaces or externally-exposed properties of the sub-systems
are shown.

Figure 56 - Box-and-line diagram for a packing robot system

However, box-and-line diagrams may be a mean of communication with the stakeholders of a project, and
may prove useful during project planning.

5.2.2 UML structural diagrams

UML provides means for presenting the structure of a system in a hierarchical, organized way: starting from
the organization of packages in the system, then of classes in the packages, finally of attributes and methods
in individual classes.

The UML Package Diagram provides a high level, structural view of the systems, depicting all the
dependencies between the different packages in which the system is organized. A package is a collection of
UML elements that are logically related; they are depicted as file folders, while dotted arrows represent
dependencies between them. One package depends on another if changes in the other could cause changes
in it.

Figure 57 - Example of a UML Package Diagram

Then, in the context of the description of the architecture of the system, Class Diagrams can be used to
describe the internal structure of each package, and a Class Description (i.e., the specification of each
attribute and method of the class) can be provided for each class.

5.3 Architectural Patterns

Patterns are defined as reusable solutions, to recurring problems, in a defined context. The concept of
pattern was originally proposed by Christophe Alexander, in the context of architecture (of buldings):

The pattern is, in short, at the sime time a thing, which happens in the world, and the rule which tells
us how to create that thing and when we create it. It is both a process and a thing.

In a nutshell, patterns are known, working ways of solving a problem. A distinction, in software engineering,
may be made between Architectural Patterns (or styles), which are ways of building system-wide structures,
and Design Patters, which leverage higher level mechanisms in describing the system.

Usually, a real system is not based on a single architectural pattern/style, but is influenced by many of them.
5.3.1 Layered model (Abstract Machine)

The idea of this pattern is to separate the software into layers or abstract machines, each one providing
specific services. The constraint posed on layers is that only functions of adjacent ones can be used. An
example of a layered architecture is the ISO/OSI model for network architecture, organized in seven different
layers, from Physical (pertaining wires and cables) to Application (web processes and applications).

Figure 58 - The ISO/OSI model

From the architectural point of view, it forces the separation of concerns, since each layer is dedicated to
solve one problem; moreover, the layered structure guarantees easy modifiability, since when a layer
interface changes, only the adjacent layers are affected.

New implementations can be added, after having designed the system, by changing one layer only (e.g., a
Bluetooth Module can be added after the design, without changing other layers).

Most of the times, software is organized in three layers: presentation (GUI or other ways of presenting the
application to the users); application logic (logic that handles the business of an application); data (where the
data of the application is collected, and the way to retrieve it, both for sensors, drivers and databases).

Figure 59 - 3-tier Architecture

5.3.2 Pipes and Filters

The situation in which the Pipes and Filters architecture is used, is when data streams have to be processed,
in several different steps (commands) to perform in order to do a specific action. The output of the first step
must be passed to the second, that takes it as its input, and so on: this is the only possible interaction between
commands in the system.

In this scenario, it must be possible to recombine steps (i.e., change the order in which they are executed),
and the information is confined to the individual steps (i.e., adjacent steps do not share info). The user storing
data after each step of the pipes and filter architecture may result into errors and garbage.

In the Pipes and Filters architecture, four main elements can be identified:

 Data sources, in charge of providing inputs to other functions;

 Filters, in charge of executing manipulations over data;