Swim

Summary

SWIM
Small World HypotesIs Machine

Antonio Troina [708267], Federico Villa [720492]

Software Engineering II Project - Politecnico di Milano
http://www.polimi.it

April 23, 2008

Antonio Troina [708267], Federico Villa [720492] SWIM

Summary

Summary

Target: show all the design steps that led to the implementation of
AutoBots SWIM3 and describe the test made on Bodum’s project
RASD:
Use Cases and Scenarios
Alloy
DD:
User Experience Design
Boundary-Controller- Entity and Architecture
Component View
Database Design
Implementation
Coherence with RASD and DD
Bodum Test
Coherence, Quality of Documentation and Implementation


Requirements Analisys and Speciﬁcations

Part I

Requirements Analisys and Speciﬁcation phase


RASD Intro
Requirements Analisys and Specifications Use Cases and Scenarios
Alloy

RASD Intro

SWIM:
allows people to find, in a network of friends, the right person for
their needings
each user owns a set of abilities, and shares his profile with all
SWIM users
everyone is able to ask for help, in a certain area of skills, within his
network of friends, specifying the maximum trusted degree of
friendship


RASD Intro
Alloy

RASD Intro

Actors and related Glossary:
User: the actor of the system; he can be unregistered, registered,
logged
Object User: a user who receives a request
Request: friendship request or help request made by an user to
another user
Notiﬁcation: a message sent to an user or to an Object user to
notify the change of the status of a request.
Evaluation: the act of an user to accept or decline a request,
changing request status.


RASD Intro
Alloy

RASD Intro

Disambiguation:
The registration part is made up of two steps: the first part asks for
user personal data, the second one asks for abilities
When an user creates a request, friendship or help, a notification is
sent by the system to the Object User. The Object User has to
evaluate the request and, after it, a new notification is sent to the
user.


RASD Intro
Alloy

RASD Intro

State charts:

Figure: Request state chart

Figure: User state chart


RASD Intro
Alloy

RASD Scenarios

A Scenario is made up of one or more Use Cases
UML Diagrams: Activity Diagrams and Sequence Diagrams
They show a running system interacting with actors


RASD Intro
Alloy

RASD Use cases

Use cases, stated simply, allow description of sequences of events
that, taken together, lead to a system doing something useful
Represented by a Fixed Schema:
Name
Actors
Entry Condition
Flow
Exit Condition
Special Requirements
Exception
Exception Handling


RASD Intro
Alloy

Use Case Diagram:


RASD Intro
Alloy

Examples

Scenario: Registration to the System
Involved use cases:
Register
Create Proﬁle


RASD Intro
Alloy

Register Use Case

Use Case Name Register
Actors Unregistered User
Entry Conditions User is not registered to the system
Flow - User asks for registration to the system
- A new window with simple registration form is displayed
- User fills input fields
- System checks for email consistency
Exit Conditions User passed the first step, and is sent to the second step
Special Requirements Simple registration form
- Email address
- Password
Exceptions - Email address already used
- User tries to register himself with a blank field
Exceptions handling - System asks for a new email address

Table: Register use case


RASD Intro
Alloy

Create Profile Use Case

Use Case Name Create Profile
Actors Unregistered User
Entry Conditions User gave a valid email address and password at first step
Flow - System shows a new form asking for more informations
- User fills all fields
- System stores user’s informations and redirect the user to login page
Exit Conditions User is registered to the system
Special Requirements Simple registration form
More informations
- Name
- Surname
- Abilities
- Total amount of free time for each ability
Exceptions - User tries to register himself with a blank field
Exceptions handling - System asks for a not blank field

Table: Create Profile use case


RASD Intro
Alloy

Activity Diagram


RASD Intro
Alloy

Sequence Diagram


RASD Intro
Alloy

Alloy - Signatures

abstract sig Request
module swim ObjectUser: one User,
madeby: one User
sig String
sig HelpRequest extends Request
sig User requestedtime: String,
name:String,
surname:String, //related ability
email:String, relatedability: one Ability

//Friend List sig FriendshipRequest extends Request
friend: set User,
sig Ability
//Will help name: String,
helpedtobe: set User amountoftime: String,
owner: one User

RASD Intro
Alloy

Alloy - Metamodel


RASD Intro
Alloy

Alloy - facts

//No friendship reflexivity
fact nofriendshipreflexivity
no x: User | x in x.friend

//An user can’t help himself
fact nohelpreflexivity
no x: User | x in x.helpedtobe

//An user can’t forward a general request to himself
fact norequesttome
all r: Request | r.ObjectUser not in r.madeby


RASD Intro
Alloy

Alloy - facts

//An user can ask for friendship to other users that
//aren’t already friend with him
fact friendshipToNotAlreadyFriend
all r: FriendshipRequest, u1, u2: User |
((u2 in r.ObjectUser) AND (u1 in r.madeby))
implies (u2 not in u1.friend)
//An user must own an ability
fact helperHasAbility
all u: User, r: HelpRequest, a: Ability |
((u in r.ObjectUser) AND (a in r.relatedability))
implies (u in a.owner)


RASD Intro
Alloy

Alloy - facts

//If A is friend of B, then B is friend of A
fact friendshipSimmetry
all u1, u2: User | (u1 in u2.friend) <=> (u2 in u1.friend)
//The ObjectUser of an HelpRequest can’t be
//helped by the sender in the same "request"
fact helperIsNotHelpedByApplicant
all u1, u2: User, r: HelpRequest |
(u1 in u2.helpedtobe) <=>
((u1 in r.madeby) AND (u2 in r.ObjectUser))


RASD Intro
Alloy

Alloy - run


Design

Part II

Design phase


User eXperience Design
Boundary - Control - Entity
Design System Architecture
Component View
Database Design

Design

We drove our project from the elicitation phase to the design phase
starting from the User eXperience diagram. By using this diagram we
had the ﬁrst idea of how the user could navigate the whole system. Then
we built the BCE Diagram, to choose which classes we would need, and
which methods for each class. And at the end, with component view
diagram, we did a merge of UX and BCE, producing a complete
component view of the whole system.
This has been the input for the third phase, the implementation.


Component View
Database Design



Component View
Database Design

System Architecture


Component View
Database Design

Component View


Component View
Database Design

Database Design - ER


Component View
Database Design

Database Design

Completly useless. DB Schema is autogenerated by Jboss


Implementation introduction
Code Organization
Coherence with Documentation
Extra Documentation

Part III

Implementation phase


Code Organization
What we used
Extra Documentation

Implementation

Complete in feautures
Partial in security and session handling


Code Organization
What we used
Extra Documentation

What we used

Eclipse
JBoss
Hypersonic DataBase, embedded in JBoss


Code Organization
Extra Documentation

Code Organization

Two diﬀerent Project, Swim3 and Swim3Web
Swim3: contains session beans, entity beans and exceptions
Swim3Web: contains servlets and JSP


Code Organization
Extra Documentation

Packages of Swim3


Code Organization
Extra Documentation

Packages of Swim3Web


Code Organization
Extra Documentation

Coherence with BCE

Coherent in structure:
4 Entities: 4 Entity beans
5 Controls: 5 Session beans
3 Boundaries: 3 Servlets
Not fully coherent in method names


Code Organization
Extra Documentation

Coherence with Component

Fully Coherent in structure:
Not fully coherent in method names


Code Organization
Extra Documentation

Extra documentation

A manual has been produced, containing:
User Manual
Installation Guide


Testing
Documentation evaluation

Part IV

Testing phase


Testing
List compatible helpers

Testing introduction

We tested Bodum’s project in three phases
1 RASD evaluation, coherence between requirements and use cases /
diagrams
2 DD evaluation, coherence with RASD speciﬁcations
3 Implementation testing, by comparing with previous documentations
- Black Box
The bodum’s ”implementation” part didn’t contain any user manual.


Testing


From users homepage, we select the item Search for Help. The system
asks to choose an ability (called job), from a cascade window, to
indicate the desired degree of separation, and hours needed.
We tried some searches, and the result is that the system doesnt return
the correct list. We asked to ﬁnd a plumber with separation degree 1,
and the system returned all plumbers, until degree ”n” (without
considering any degree).
Moreover the system shows also myself in the list, violating the alloy
specication.
The system performs also the search with 0 separation degree.


Testing

1 the system performs the search also with empty ﬁelds, and it returns
the list of all users with the requested ability.
2 the system shows also myself as compatible helper into the list
(violating alloy specs)
3 the system perfoms the search without liking the degree of
separation.
4 the system doesnt consider friendship relations while performing the
search. It returns a list even if there are no friendship relations
linking us to helpers.
5 the system performs the search also with 0 degree of separation


RASD
Testing
DD
Implementation

Documentation evaluation - RASD

Many imprecisions. Theres a bit of confusion about Use Case and
Scenarios: for each scenario there is only a use case.
Diagrams are complete and accurate but often the event-ow
contains not-expected actions, not appropriate for the use case.
Alloy model is incomplete; it does not contain all the required
specications and constraints.
The constraints described in Alloy are not implementend or
respected during implementation phase.


RASD
Testing
DD
Implementation

Documentation evaluation - DD

Boundary-Control-Entity contains some questionable choices (the
Entity layer is made up of Entity Elements representing all the tables
in the database, including relational join tables)
A Component View is not included
According to BCE, there must be only one servlet and only one
session bean. In J2EE view we can see 7 servlets and 5 session
beans. The source package is made up of 13 servlets and 8 session
beans.


RASD
Testing
DD
Implementation

Documentation evaluation - Implementation

No user manual is provided.


Swim

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (20)

En vedette

En vedette (20)

Swim