Software Engineering II WE1 Cheatsheet

Alloy

In a nutshell alloy is first-order relational logic applied to system bahaviour modeling. It is a formal notation for specifying models of systems and software. In RE Alloy can be used to describe the domain and its properties, or operations that the machine has to provide. In order to simulate that enviroment, in the exam we are given a brief description of a system, which we have to implement using Alloy.

Basics

The most important keyword in Alloy is sig, which is used to define signatures, which are entities, like classes in programming languages. They are used to define types and relationship between different entities of the model.

Notation

Meaning

sig Book { ... }

Class definition

sig Dictionary Extends Book

Class Inheritance

abstract sig Component

Abstract class declaration

sig Book { author: Author }

Class fields declaration

b.author

Field access

pred name { formulas }

Predicate declaration

fact name { formulas }

Fact declaration

assert name { formulas }

Assertion declaration

The key to understand Alloy is making good use of multiplicity in relation declaration, and using correctly predicates, facts, assertions and functions. The basic building blocks of alloy, apart from entities (signatures) are formulas, which are logical constraint which allows us to model correctly the behaviour of our group of entities, are the following:

Facts: It is a constraint that always holds and is used to define properties of the model. Code example:
```
fact {
 no p: Person | p in p.^(mother+father)
}

fact {
 all m: Man, w: Woman | m.wife = w iff
 w.husband = m
}
```
The code above is modeling a constraint which avoids that a person can be an ancestor of himself with no p: Person | p in p.^(mother+father), and then we also impose that if X is the husband of Y, then Y must be the wife of X.
Predicates: A predicate is a template for a constraint that can be instantiated in different contexts, they differ from facts since they are reusable expressions, In this sense they are more similar to functions than facts. One would use predicates, for example, to check that one constraint implies another. They take arguments and are either true or false. Note that w.r.t. facts, predicates have to be invoked, while facts must hold globally for any atom and relation in the model. Example:
```
// pred usage to model an operation which adds an item
// to a relation field, in this case we're adding a name -> address
// relation to the addr field of the Book relation
sig Name, Addr {}
sig Book {
 addr: Name -> lone Addr
}

pred add [b, b’: Book, n: Name, a: Addr] {
       b’.addr = b.addr + n -> a
}
```
Predicates usually are meant to execute dynamic analysis, which means that they can modify some signature (for example by adding something to a field) or by checking that something holds true in the domain (for example by using logical operators to model a FOL like statement).
Functions: Alloy functions have the same structure as predicates but also return a value. Unlike functions in programming languages, they are always executed within an execution run, so their results are available in the visualization and the evaluator even if you haven’t called them directly. Example:
```
// Can we get the addresses in the book corresponding 
// to a certain name?
fun lookup [b: Book, n: Name] : set Addr {
 n.(b.addr)
}
```
Assertions: assertions are properties that we want to check. Unlike predicates, assertions don't bind arguments. It is a constraint that is intended to follow from the facts of a model; it is thus an intentional redundancy. The key difference from predicates is that a predicate is run to find a world that satisfies it, while an assertion is checked to find a counterexample. Example:
```
// Check if there is no man who is also his father:
assert NoSelfFather {
 no m: Man | m = m.father
}
check NoSelfFather
```

Attributes, arity, relations

Arity keywords

Keyword

Meaning

set

any number

one

exactly one (default)

lone

zero or one

some

one or more

Basically we can use the two points to specify a unidirectional multiplicity relationship, and the arrow symbol to specify a cartesian product between two signatures.

x: m e, where m is the multiplicity constraint.
Arity of the field declaration
RecentlyUsed: set Name , subset of the set Name
senderAddress: Addr , singleton subset of Addr
senderName: lone Name, senderName is either empty or a singleton subset of Name
receiverAddresses: some Addr, receiverAddresses is a nonempty subset of Addr

r: A m -> n B, instead work like a cartesian product ( $m \times n$ ). Examples:

// the someField field only contains pairs in which
// the first component is of type Person, while the 
// second component is of type String
sig SomeSignature {
  someField: Person -> String
}

Name = {(N0), (N1)}
Addr = {(A0), (A1)}
Book = {(B0)}

Name->Addr = {(N0, A0), (N0, A1),
              (N1, A0), (N1, A1)}

Book->Name->Addr =
  {(B0, N0, A0), (B0, N0, A1),
   (B0, N1, A0), (B0, N1, A1)}

Signatures

A signature represents a set of atoms and introduces a new type or subtype (extends, used in pair with abstract). A subtype signature inherits the fields of the signature it extends, along with any fields that signature inherits. A subset signature inherits the fields of its parent signatures, along with their inherited fields. Abstract signatures on the other end represents a classification of elements that is refined further by more ‘concrete’ signatures. Signature code example:

sig Topic {}
sig Event {
    regards : one Topic
}

abstract sig Component {}

sig Publisher extends Component {
    toBePublishedBuffer : set Event,
    publishableTopics : set Topic

}{
    #toBePublishedBuffer <= 10
    toBePublishedBuffer.regards in publishableTopics
}

Signature fact

Like any other fact, the signature fact is a constraint that always holds. Unlike other facts, however, a signature fact is implicitly quantified over the signature set. Given the signature declaration:

sig S {…} { F }

the signature fact F is interpreted as if one had written an explicit fact:

fact { all this: S | F’ }

Syntax

Set operators

Symbol

Meaning

union

intersection

difference

subset

equality

Examples:

// starting sets
cacheAddr = {(N0, A0), (N1, A1)}
diskAddr = {(N0, A0), (N1, A2)}

// operators usage
cacheAddr + diskAddr = {(N0, A0), (N1, A1), (N1, A2)} // set union
cacheAddr & diskAddr = {(N0, A0)} // set intersection
cacheAddr = diskAddr = false  // equality check

Boolean operators

Symbol

Pseudocode

Meaning

!

not

negation

&&

and

conjunction

or

=>

implies

implication

,

else

alternative

<=>

iff

bi-implication

Unary operators

Symbol

Meaning

transpose

transitive closure

reflexive transitive closure

next = {(N0, N1), (N1, N2), (N2, N3)} // generic list
~next = {(N1, N0), (N2, N1), (N3, N2)} // transpose operator

// ^r = r + r.r + r.r.r + ...
next = {(N0, N1), (N1, N2), (N2, N3)} 
^next = {(N0, N1), (N0, N2), (N0, N3), // transitive closure
(N1, N2), (N1, N3),
(N2, N3)}

Some constraints can be greatly simplified thanks to transitive closure, for example:

// n1 is reachable from n2
pred isReachable[n1 : Node, n2: Node] {
  n1 in n2.^linkedTo
}
// it returns true if there exists a path between the two, regardless of its length

Restriction, override

Symbol

Meaning

domain restriction

range restriction

override

Name    = {(N0), (N1), (N2)}
Alias   = {(N0), (N1)}
Addr    = {(A0)}
address = {(N0, N1), (N1, N2), (N2, A0)}

address :> Addr  = {(N2, A0)} // filtered address by Addr, which is a singleton.
Alias <: address = {(N0, N1), (N1, N2)} // removed tuple containing A0 since it's not
                                        // present in Alias.
address :> Alias = {(N0, N1)} // filter to get only tuples which contain both
                              // N0 and N1.

workAddress = {(N0, N1), (N1, A0)}
address ++ workAddress = {(N0, N1), (N1, A0), (N2, A0)}

Some other notes

disj : very important keyword that is used in facts to model specific constraints that requires uniqueness, for e.g.:
```
fact codeAreUnique { 
  all disj t1,t2: Taxi | t1.code != t2.code
}
```
all : if we want a fact to hold for all elements of a set, we can use the all keyword:
all n: Name | lone a: Address | a in n.address, which means that every name maps to at most one address.
all n: Name | no disj a, a': Address | (a + a') in n.address, no name maps to two or more distinct addresses (same as above).
Simpler example: all b:Book | has_author[b]

Inner product (. join):

Works by joining matrix by position and dropping the matching column:

rel1 = {A -> B, B -> A}
rel2 = {B -> C,
        B -> D, A -> E}

rel1.rel2 = {
        A -> C,
        A -> D, B -> E}

Cardinality: the # metacharacter is used to model the cardinality of a set. For e.g.:
```
pred show [b: Book] {
  #b.addr > 1
}
```
Means that there must be at least one relation (Name, Address) in a given Book.

Useful patterns

Booleans

abstract sig Boolean {}
one sig True extends Boolean {}
one sig False extends Boolean {}

Relation multiplicity

sig Intersection{
  connection: Semaphore -> Road // maps Semaphore to Road
}{
  #connection = 2 // there need to be at least two pairs Semaphore/Road
}

Complex relation mapping

Example: Model a TCP channel that maps TCP data to TCP servers through a routing relation. For the sake of simplicity, focus only on the destination of the routing, not on the source and make sure that the channel can route each TCPData to at most one TCPServer.

sig TCPChannel {
	routed: TCPData -> lone TCPServer
}

Access a relation field of a signature

Example from slides:

// signature declarations
sig Name, Addr {}
sig Book {
	addr: Name -> lone Addr
}

// signature sets
Name = {(N0), (N1), (N2)}
Addr = {(A0), (A1), (A2)}
Book = {(B0), (B1)}

// specific instances
myName = {(N1)}
addr = {
	(B0, N0, A0),
	(B0, N1, A1),
	(B1, N1, A2),
	(B1, N2, A2)
}

// field access: the following operation returns all addresses
// which are in a relation with names inside some book signature
myName.(Book.addr) = {(A1), (A2)}

Graphical representation of the operations above:

Another example, from an exam:

sig TCPChannel {
	routed: TCPData -> lone TCPServer
}

// important constraint I missed: if a piece of data is in routed
/// to a server by some channel, it means that it must appear in
// the received set of the server
pred TCPChannelAssumption {
    all d: TCPData, s: TCPServer | d in TCPChannel.routed.s implies d in s.received
    // alternative formulation
    all d: TCPData, s: TCPServer | d in s.(TCPChannel.routed) implies d in s.received
}

Abstract signature with attributes

abstract sig Table {
  tuples : set Tuple
}

sig Partition extends Table {
  node : Node
}

sig PartitionedTable extends Table { parts: set Partition
}{
  #parts > 1
}

// then if we want to access the abstract sig field:
fact partitionsHaveAllTuples {
  (all pt: PartitionedTable, t : Tuple | t in pt.tuples implies ...

Predicate to add/modify a set in a signature

Example: Define a predicate capturing the operation with which a subscriber subscribes to a topic. The operation takes as input a configuration, a subscriber, and a topic and updates the topics of the subscriber in the configuration.

pred(fc, fc' : FrameworkConfig, s, s' : subscriber, t : Topic) {

    // now we want to model the predicated to make it have some sense
    //preconditions
    s in fc.subscribers // the subscriber must belong to a frameworkconfig
    and t in fc.topics  // same for topics

    //postconditions
    and fc'.topics = fc.topics
    and fc'.events = fc.events
    and fc'.publishers = fc.publishers
    and s'.incomingEventsBuffer = s.incomingEventsBuffer
    and s'.subscribedTopics = s.subscribedTopics + t
    and fc'.subscribers = fc.subscribers - s + s'
}

Assertion to check relation asymmetry

Example: A user u1 can be “friends” with user u2, but the vice versa does not necessarily hold.

sig RegisteredUser extends Visitor {
  friends : set RegisteredUser
}

assert friendNotSymmetric {
  friends != ~friends
}

Facts to ensure that all signatures X are connected to all signatures Y

Example: Define constraints (for example through facts) that ensure the following properties hold:

All comments are connected to a post.
All comments and posts have been issued by a registered user.
Comments introduced in reply to other comments refer to the same post as the comment replied to.

fact EachCommentIsOnPost {
  all sn : SocialNetwork, c : Comment |
    c in sn.comments implies (one p : Post | p in sn.posts and c in p.comments)
}

fact CommentsAndPostsIssuedByRegisteredUsers {
  all sn : SocialNetwork |
    (all c : Comment | c in sn.comments implies c.creator in sn.users)
    and
    (all p : Post | p in sn.posts implies p.creator in sn.users)
}

fact RepliesOnlyToSamePost {
  all c1, c2 : Comment |
    c2 in c1.reply_to implies
      (one p : Post | c1 in p.comments and c2 in p.comments)
}

Two instances of the same signatures X must have disjoint subset of the same signature Y

Example: Two servers cannot handle the same request:

sig Server {
  requests : some Request
}

sig AvailableServers {
  servers : set Servers
}{
  all disj s1, s2 : Server | s1.requests & s2.requests = none
}

All instances of a signature X belong to a field of a specific signature Y

fact allTuplesInTables {
  all tu : Tuple | one ta : Table | tu in ta.tuples
}

Function usage

// for completeness sake
sig Module {
    author: Author,
    technology: Technology,
}

sig Device {
    location: Location,
    supported_technologies: some Technology,
    compatibility: set Module
}{
    compatibility.technology in supported_technologies
}

// point C
// Define an Alloy function that returns, given a system configuration and
// a software module, the set of 
// devices which host that module in that configuration

fun getModules [c : Configuration, m : Module] : set Device {
    let res = {d : Device | d in c.devices and m in d.compatibility}
    res
}

Predicate which returns true

// A predicate leqCoin that takes as input two coins, c1 and c2,
// and returns true if c1 is less than, 
// or equal to, c2, false otherwise.

pred leqCoin[ c1, c2 : Coin ] {
 c1 = Quarter or
 c1 = Half and not (c2 = Quarter) or
 c1 = Dollar and c2 = Dollar
}

Project Management

Types of exercises:

Earned value analysis
Function points
Gantt chart analysis

Regarding Verification, its basically the same thing as Testing, so refer to the Testing paragraph in order to learn how to do this kind of exercises.

Earned value analysis

Budget at completion (BAC): total budget for the project
Planned value (PV): budgeted cost of work planned
Earned value (EV): budgeted cost of work performed
Actual cost (AC): actual cost for the completed work
Schedule performance index (SPI)
Cost performance index (CPI)

We need to check if the project is over budget (EV < AC), and behind schedule (EV < PV). Note that to find PV for a specific time interval we can just sum the project sub-budgets up to that point in time.

We need also to calculate the budget at completion (EAC). We have three cases:

Assumption 1: continue to spend at the same/actual rate:
$EAC = \frac{BAC}{CPI}$
Assumption 2: continue to spend at the original rate:
$EAC = AC + (BAC-EV)$
Assumption 3: both CPI and SPI influence the remaining work:
$EAC = \frac{[AC+(BAC-EV)]}{(CPI*SPI)}$

Where:

$CPI= \frac{EV}{AC}$

$SPI= \frac{EV}{PV}$

Function points

Recap on function points

Basic assumption

The dimension of software can be characterized based on the functionalities that it has to offer.

Function points are based on a combination of program characteristics:

Data structures;
Inputs and outputs;
Inquiries;
External interfaces;

A weight is associated with each of these function points counts; the total is computed by multiplying each “raw” count by the weight and summing all the partial values:

$UFP = \sum{(N _{\#elements \hspace{0.3em} of \hspace{0.3em} a \hspace{0.3em} given \hspace{0.3em} type} * weight)}$

Based on the interaction of the system components internally and with external users, applications, etc they are categorized into five types:

External Inputs (EI): Elementary operation to elaborate data coming from the external environment
External Outputs (EO): Elementary operation that generates data for the external environment
External Inquiries (EQ): Elementary operation that involves input and output
Internal Logic File (ILF): homogeneous set of data used and managed by the application
External Interface File (EIF): homogeneous set of data used by the application but generated and maintained by other applications

Some notes:

To identify correctly F.P. it can be useful to think of the system as a Java class: EI, EO and EQ are methods, while ELF and ILF are attributes.
External outputs are rare, usual operations are modeled as External inquiries (such as retrieving some data or browsing posts on a social network). Some particular system may work in a opposite way, which means that they have no EQ, but only EI/EO (such as publish-subscribe framework for example)
Login/Logout are always simple external inputs
Also data deletion (delete post, delete record) are external inputs

So EIF and EO are not found often, unless the text specification says that the system we're studying is comunicating with another application.

Common question: Referring to Function Points analysis, classify function number n

N.B Often this question corresponds to a small amounts of points (1.5 pts), and is proposed as an alternative to earned value analysis (3 pts).

Graphical variant

Draw a diagram of the LocalStoreApp in terms of function points and identify the type and complexity of each function point, providing a short explanation.

Gantt Chart analysis

In this kind of exercise it will be asked to identify the critical path. It is a connected sequence of tasks that runs from the start till the end of the project. Any change to the tasks on the critical path changes the project finish date. A task is critical if it is placed between predecessor and a successor, and cannot float earlier or later.

Then it can be asked to determine which longer tasks can be crashed to reduce the project length and why. First, we consider only longer tasks (usually in exam exercises they have a duration of either one or two days) present on the critical path. Then we make the assumption that the resources allocated in crashing a task (since executing a two day job in only one day is going to need more manpower) can be reallocated to keep developing the project, otherwise they will be wasted and crashing would not be convenient. Finally we choose to crash the less expensing task among the ones we can choose from. This can be done by checking who is working at a specific task, for e.g. a PM (Project Manager) is more expensive than an Engineer.

Example (WE1 25/06/19)

A. Critical path: tasks # 2 – 3 – 5 – 6 – 7 – 9 – 12 – 13 – 14 – 16 – 17 – 18 – 19 – 20 – 26 – 27 – 28 – 35 – 36 – 37 – 39 – 40. Tasks 21 and 29 (together with their sub-tasks) are not on the critical path as they can be started independently from the others, provided that the company has enough resources.

B. Tasks that could be crashed for reducing project length are those on the critical path, so, tasks # 6 and 19. Crashing a task means allocating a new resource working in parallel with the others already allocated to the project. This also implies that we are going to have the resources free at the end of the crashed task, for the amount of time we have saved with crashing. If such free resources cannot be reallocated to a different project, crashing results in an extra cost due to the intervention of the new resource working in parallel with the others, otherwise, the cost of the project remains the same. Assuming to be in the first case, since task #19 is less expensive than task #6, as it is performed by an Engineer, we should consider crashing that task.

JEE

JEE Beans

Stateful Session Beans: in a stateful session bean, the instance represents the state of a unique client/bean session, which means that it can only be linked to one client. Each client creates a new instance of stateful bean and when the client terminates, its session bean appears to terminate and is no longer associated with the client. Usually they are linked to state changing actions, like for e.g. creating a new order in a restaurant web app.
Stateless Session Beans: a stateless session bean does not maintain a conversational state with the client. All instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client.
Singleton Session Beans: singleton session bean maintains the state of the bean per lifecycle of the application. Singleton session beans offer similar functionality to stateless session beans but differ from them in that a singleton session bean is instantiated once per application and there is only one singleton session bean per application.
JPA Entity Bean: it is a type of Enterprise JavaBean, a server-side Java EE component, that represents persistent data maintained in a database. An entity bean can manage its own persistence (Bean managed persistence) or can delegate this function to its EJB Container (Container managed persistence).

Tips

Statateful session beans are appropriate if any of the following conditions are true:

The bean's state represents the interaction between the bean and a specific client.
The bean needs to hold information about the client across method invocations.

Stateless session beans are appropriate if any of the following conditions are true:

The bean's state has no data for a specific client.
In a single method invocation, the bean performs a generic task for all client.
The bean implements a web service.

Singleton session beans are appropriate if any of the following conditions are true:

State needs to be shared across the application.
A single enterprise bean needs to be accessed by multiple threads concurrently.
The application needs an enterprise bean to perform tasks upon application start up and shutdown.

JEE Annotations

Relational database relations

JPA annotation

Definition

One to one

@OneToOne

Each entity instance is related to a single instance of another entity.

One to many

@OneToMany

An entity instance can be related to multiple instances of the other entities

Many to one

@ManyToOne

Multiple instances of an entity can be related to a single instance of the other entity.

Many to many

@ManyToMany

The entity instances can be related to multiple instances of each other

JEE Methods

As for the methods, we can specify getter/setter methods for entity beans, while for session beans we need to think about a specific task accomplished by that bean and model its signature (parameters + return variable) accordingly.

Getter/setter method example:

String getUsername()
void setUsername(String name)

Session bean method example:

public Integer updateResidenceAddress(String addr) {}

Database modeling

For every entity we find, we need to specify (apart from an id, which is present in all tables) its attributes and relationships. For example if we have a client/user entity, it will have a name/username and a password, and on top of that any collection of entities in relationship with him. As for other generic entities, its usually specified which attributes they may have.

@Many-to-One vs @One-to-Many

Bidirectional many-to-one/one-to-many is the best practice for modeling one to many relations.

Then, unidirectional Many-To-One is advised, and last preferable approach is Unidirectional One-To-Many.

Example (WE1 14/02/2020)

Alphabet is a website that allows users to choose from a list of **freelancers **for a Translation Service. Freelancers offer different types of Translation Services, including technical translation, legal, medical and financial translation in various languages. We focus on the functions offered to clients. The system allows clients to:

Register.
Log in.
View the list of available freelancers in a selected date, categorized based on the type of the Translation Service offered.
View each freelancer’s profile that displays his/her reputation (total completed Translation Services, and a rating of 1 to 10 stars given by her/his previous clients), and cost of the Translation Service per 1000 words (which is not negotiable).
Select the desired freelancer for a specific translation package offered by her/him. When a client selects a freelancer, she/he specifies also the length of the manuscript to be translated and the anticipated delivery date; this initiates a new Translation Service, which is thus created and its status is “initiated”. The freelancer then has up to three days to respond to such proposal, by either accepting or rejecting it. In the case of approval of the proposal, the status of the Translation Service is updated to “activated” and the client must send the manuscript within three days (if the client fails to send the manuscript within three days, the status of the Translation Service turns to “canceled”). After the proposal is accepted and the manuscript is delivered, the Translation Service automatically starts and the countdown to the delivery date begins. If the freelancer rejects the proposal, then the Translation Service automatically terminates, and its status is updated to “rejected”.
Cancel any proposed and ongoing Translation Services (in the latter case, any compensation of the freelancers would be paid according to Alphabet’s agreed cancellation terms and conditions).
View the list of all her/his Translation Services and their status (initiated, rejected, activated, canceled, countdown to the delivery date, completed).
Give a score to the freelancer who has completed a Translation Service.

Entities:

Client
Attributes:
- clientId, String, @Id, @GeneratedValue
- name, String, @NotNull
- password, String, @NotNull
Relationships:
- translationService, Collection/Set<TranslationService>, @OneToMany
Freelancer
Attributes:
- freelancerID, String, @Id, @GeneratedValue
- name, String, @NotNull
- rating, Integer
- Total_Completed_Translation_Service, Integer
Relationships:
- translationService, Collection/Set<TranslationService>, @OneToMany
TranslationService
Attributes:
- translationServiceID, String, @Id, @GeneratedValue
- cost, Integer
- status, Enum
- requested_delivery_date, Date
- accepted_delivery_date, Date
- final_delivery_date, Date
Relationships:
- client, Client, @OneToMany
- freelancer, Freelancer, @OneToMany

Note - all ids have @Id, @GeneratedValue annotations, while usually username and password strings have the @NotNull annotation.

Example (WE1 05/02/2021)

The Municipality of Milan wants to create a web-based system to let parents register their children in a public kindergarten in various regions of the city. The Municipality would like to have a robust architecture to manage this system. Parents use the system to enter an Enrollment Request (ER) where they specify the information about their child, including the area they live in. Kindergartens receive through the system the ER, evaluate it and contact the applicants to inform them if they are rejected/accepted and to further communicate with them. In particular, the system offers the following functions to parents:

F1 - Child registration: The parent should be able to register his/her child in the system by giving information such as name/surname, birthdate of the child, working status, phone number, and email address of the parents. As a result of the registration, parents will be able to log in to the system.
F2 - Enrollment request: When logged in, parents issue the ER by giving the following data in addition to the data in their profile: city area of interest, and if the child needs any special medical care.
F3 - Kindergarten rating: Parents can rate the kindergarten of their child.
F4 - Visualization of ER status: This can be one of the following: pending or accepted (for simplicity, we assume that there is enough availability for all children of a certain area, so no application is rejected).

Moreover, the system offers the following functions to kindergartens’ staff:

F5 - Kindergarten registration: This is performed by providing at least the following data: kindergarten name, city area, email, capacity.
F6 - Profile update: Kindergartens can update their capacity. They will stop receiving ERs whenever their capacity is full.
F7 - ER evaluation: The kindergarten’s staff can accept/reject an application. Finally, the system offers the following support functions:
F8 - Upon submission, the system sends ERs to all available kindergartens of the desired city area.

Notice that a parent cannot apply for a specific kindergarten, but only for a region. Notice that when one of the kindergartens accepts an ER, then the ER status is changed to accepted. Also, the system keeps track of who is enrolled in each kindergarten, based on the acceptance information.

A. (2 points)

Identify at least two different Components of the Web Tier, their main responsibility and, for each Component, list the requirements that it satisfies.

Component

Responsibility

Requirements

JSP

Front-end, child registration

JSP

Front-end, kindergarten registration

ChildRegistration_Servlet

forward forms data to the bean

KindergartenRegistration_Servlet

forward forms data to the bean

Note - usually the main components found in the web tier with a JEE implementation are JSPs and Servlets, which allow the user to visualize/insert data, and they forward them to the application server (in which we find session beans).

B. (3 points)

Given the entities defined in the following table, focus on the business layer part of your system, and in particular on the definition of the Beans. More precisely, identify the required Beans, specify their types and, for each Bean, list the functions it satisfies (F1-F8) and at least one method (the most important one):

Note - we have three entities, on which we need to perform various actions (registering, deletion, data manipulation, etc.). This means that probably we will have three stateless beans (one for each entity) which contains the application logic needed to accomplish those tasks.

Kindergarten_Manager, Child_Manager are stateless beans to manage the operations related to the Kindergarten and Child entities such as registration, profile updating and so on. ER management could be implemented as a stateless bean, the ER_Manager. To address F8, when a new request is generated by filing the ER form, the main task of the ER_Manager bean is to first extract the requested region in the ER, then query the database to find all the available kindergartens in that region and then send them the ER.

Bean

Type

Requirements

ChildManager

Stateless sessions bean

F1, F2, F3

KindergartenManager

Stateless sessions bean

F5, F6, F7

ERManager

Stateless sessions bean

F4, F8

Kindergarten_Manager, Child_Manager are stateless beans to manage the operations related to the Kindergarten and Child entities such as registration, profile updating and so on. ER management could be implemented as a stateless bean, the ER_Manager. To address F8, when a new request is generated by filing the ER form, the main task of the ER_Manager bean is to first extract the requested region in the ER, then query the database to find all the available kindergartens in that region and then send them the ER. Some methods of Child_Manager, Kindergarten_Manager, and ER_Manager are the following:

Child_Manager:

public Integer updatePassword(String userID, Integer rate) {}
public Integer updateResidenceAddress(String addr) {}

Kindergarten_Manager:

public void SetAvailability(Boolean availability) {}
public Integer updateRating(String userID, Integer rate) {}

ER_Manager:

public Collection findKindergartenByRegion(String RegionName){}
public void sendERs(Collection kindergartensInRegion) { for (kindergarten k : kindergartensInRegion) {  // send the ER to k } }

Note that F2 is the function that is used to create an enrollment request. I would have put into ER_manager, but the intended solution puts it in Child_manager.

Testing/Verification/Design

We are usually asked to do all or some of those tasks:

Draw the control flow graph. Very similar to textual def-use pair search. Example:

If we have some particular sequence of instruction at a specific line, for e.g. the condition of a for loop, we need to split it in different blocks. For example:

for(int i = 0; i < 4; i++) {
	// some code
}

The int i = 0 gets executed only once, while the condition and the increment are performed multiple times. Recall:

for(init; cond; inc) {
	// body
}

The order is the following:

init
cond
[body, inc]
Find def-use variable pairs: in order to do that, you need to write a list, one for each variable used in the given fragment of code, containing pairs of number representing respectively the line of the code in which the current value of that variable is defined, and the line of the code in which that value is used. If it used more than one time, there will be more than one pair with the same declaration number (unless the value of the variable is changed) and a different 'use' number. Example:
i: <x, y>, <x, z>, etc.
It is also asked to highlight problematic scenarios, for e.g. if a variable is accessed without being properly initialized.
Use symbolic execution to execute a certain program path. It can also be asked to use it just to determine whether the problems highlighted by def-use analysis can occur or not during execution of the program, which means that in this case we will have to define a path, which will not be given by the exercise text. In this exercise we will have to simulate the execution of the program by annotating for each line of code the result of variable assignment and comparison, and if necessary, to highlight possible problems in the code. Example:
```
x = X
res = 0
X >= 1 and 0 <= 1
// 	etc
```
Path Condition
It is important to keep in mind that to follow a certain execution path, there could be some path conditions to respect, for e.g.:
```
read(y, a);
x = y + 2;
if x > a
	a = a + 2;
else 
	y = x + 3;
x = x + a + y;
```
How can the symbolic executor determine if x > a is true or false? Execution is performed for a specific path, for instance:
- Execution path: <1, 2, 3, 5, 6, 7>
- Path condition: Y + 2 $\leq$ A

Note that it can also be asked to:

Describe the problem in the code or to answer more generic question related to the given code snippet (for e.g. if all code instruction are accessible trough some path).
Consider the various analysis approaches we have seen in the course. For each of them, explain if and how they could be able to discover the problem. Provide a justification also for negative answers.
In this case we have to describe those testing techniques:
- White box Used usually for unit testing, based on knowledge of structure of the system.
- Black box Used to test integration and the whole system. Used to check if expected behavior is the behavior of the software (Model-based testing).
- Capture and reply First test is manual (so it is costly) but it is recorded. Next time the test is an automatic replay of the first test, for which we know the outcome (used for example for auto-regression testing on GUI).

Example (WE1 24/06/21)

int funct(int x, int y) {
    if (x > 0 && y > 0) {
        if (y % 2 == 0)
            return -1;
    while(x*y % 2 == 0)
        x = x / 2;
    while((x+y) % 2 == 0)
        x = x - 1;
    }
    return x+y;
}

1. Symbolically execute the program covering the following paths, highlighting the path condition associated with each path:

0, 1, 2, 4, 5, 4, 5, 4, 6, 7, 6, 7, 6, 8, 9

0: x = X, y = Y

1: X > 0 and Y > 0

2:  Y odd

4: X*Y even

5: x = X/2

4: X/2*Y even

5: x = X/4

4: X/4*Y odd

6: X/4+Y even

7: x = X/4-1

6: X/4-1+Y even

7: x = X/4-2

6: X/4-2+Y odd

9: return X/4-2+Y

Path condition: X > 0, Y > 0, X even, Y odd

This path is unfeasible because both X/4+Y and X/4-1+Y should be even, but that's not possible.

0, 1, 2, 4, 6, 8, 9

0: x = X, y = Y

1: X > 0 and Y > 0

2:  Y odd

4: X*Y odd

6: X+Y odd

9: return X+Y

Path condition: X > 0, Y > 0, X odd, Y odd

Path 2 is unfeasible because if x and y are both odd, there cannot be that both their product and sum are odd.

2. Are all instructions in the code reachable through some path, even one not listed in the text, or not?

Given the following preconditions:

x > 0, y > 0, y \hspace{0.5em} odd, x \hspace{0.5em} even, x*y \hspace{0.5em} even, \frac{x}{2}+y \hspace{0.5em} even

The following path executes all instructions (except of course the return -1 at line 3):

0, 1, 2, 4, 5, 6, 7, 6, 7, 8, 9

An example of the feasibility of this path would be the case in which $x=6$ and $y=3$ .

Availability/Architecture/Design

We have a bunch of components, each with different availability. We have to maximize or to obtain a desired availability level. Since a system is composed by more than one component, they can be put in either a serial or parallel disposition. In the first case the failure of a component leads to to the system becoming inoperable. In the latter a failure leads other parts to taking over:

Availability in series - combined availability as the product of the availability of the single parts:
$A_{series} = \prod_{i=1}^{n} A_{i}$
It is also important to note that the total availability is only as high as the weakest link of the series.
Availability in parallel - Since the system is operational if at least one part is available, we have that the formula is made up by 1 - (all parts that are unavailable):
$A_{parallel} = 1 - \prod_{i=1}^{n} (1 - A_{i})$

If the requested availability is higher than the availability of the single components, in order to achieve what is asked we need to replicate them, which means putting multiple of those components in parallel.

If the exercise text is ambiguous, a rule of thumb for deciding on how to build the system availability equation is to reason about component usage: if for e.g. we have a front end in series with some equal components, and they all need to respond, this means that if one fails, the system becomes unusable: they can be considered in series from an availability point of view. On the other end, if just one of the parallel components need to respond, and in case of failure the other two can actually replace it, we can consider them in parallel from an availability point of view.

WE2

Requirements modeling

Identify World and Machine phenomena
Identify one goal, with associated domain assumptions and requirements
UML Use case / class diagram

Jackson-Zave World and machine

Machine: portion of the system to be developed

World: portion of real world affected by the machine

Phenomena can belong to either one of them or be shared among them. In the second case they have to be controlled by either one of them.

Goals, domain assumptions, requirements

Goals: prescriptive assertions formulated in terms of world phenomena. Basically what should happen w.r.t. the world.
Domain assumption: descriptive assumption assumed to hold in the world. Not an active action like for goals, but more of a passive condition that we needs to hold true in order to the machine to be able to fulfill its requirements.
Requirements: prescriptive assumptions formulated in terms of shared phenomena. Similar to goals, but require interaction between world and machine.

Example:

System description:

For every urgent call reporting an incident, an ambulance should arrive at the incident scene within 14 minutes.
For every urgent call, details about the incident are correctly encoded.
When an ambulance is mobilized, it will reach the incident location in the shortest possible time.
Accurate ambulance locations are known by GPS.
Ambulance crews correctly signal ambulance availability through mobile data terminals on board the ambulances.

Goal with related domain assumptions and requirements:

Goal: 'For every urgent call reporting an incident, an ambulance should arrive at the incident scene within 14 minutes'.
Domain assumptions:
- For every urgent call, details about the incident are correctly encoded
- When an ambulance is mobilized, it will reach the incident location in the shortest possible time
- Accurate ambulances locations are known by GPS
- Ambulance crews correctly signal ambulance availability through mobile data terminals on board of ambulances.
Requirement: When a call reporting a new incident is encoded, the Automated Dispatching Software should mobilize the nearest available ambulance according to information available from the ambulances’ GPS and mobile data terminal.

Suggestion: in order to find a good goal, it is useful to think to some important task that the application needs to fulfill and to formulate it in terms of user action. Then requirements and domain assumptions will be simpler to find. For requirements then we just need some basic constraints that are already written in the system specification, and the same goes for domain assumptions but applied to world interactions.

Last updated 3 years ago

hashtagAlloy

hashtagProject Management

hashtagJEE

hashtagTesting/Verification/Design

hashtagAvailability/Architecture/Design

hashtagWE2

hashtagRequirements modeling

Alloy

Project Management

JEE

Testing/Verification/Design

Availability/Architecture/Design

WE2

Requirements modeling