swim

Summary

SWIMSmall World HypotesIs Machine

Antonio Troina [708267], Federico Villa [720492]

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

April 23, 2008

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

http://www.polimi.it

Summary

Summary

Target: show all the design steps that led to the implementation ofAutoBots SWIM3 and describe the test made on Bodum’s project

RASD:

Use Cases and ScenariosAlloy

DD:

User Experience DesignBoundary-Controller- Entity and ArchitectureComponent ViewDatabase Design

Implementation

Coherence with RASD and DD

Bodum Test

Coherence, Quality of Documentation and Implementation


Requirements Analisys and Specifications

Part I

Requirements Analisys and Specification phase


Requirements Analisys and SpecificationsRASD IntroUse Cases and ScenariosAlloy

RASD Intro

SWIM:

allows people to find, in a network of friends, the right person fortheir needings

each user owns a set of abilities, and shares his profile with allSWIM users

everyone is able to ask for help, in a certain area of skills, within hisnetwork of friends, specifying the maximum trusted degree offriendship



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 toanother user

Notification: a message sent to an user or to an Object user tonotify 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

Disambiguation:

The registration part is made up of two steps: the first part asks foruser personal data, the second one asks for abilities

When an user creates a request, friendship or help, a notification issent by the system to the Object User. The Object User has toevaluate the request and, after it, a new notification is sent to theuser.



RASD Intro

State charts:

Figure: Request state chart

Figure: User state chart



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 Use cases

Use cases, stated simply, allow description of sequences of eventsthat, taken together, lead to a system doing something useful

Represented by a Fixed Schema:

NameActorsEntry ConditionFlowExit ConditionSpecial RequirementsExceptionException Handling



Use Case Diagram:



Examples

Scenario: Registration to the SystemInvolved use cases:

Register

Create Profile



Register Use Case

Use Case Name RegisterActors Unregistered UserEntry Conditions User is not registered to the systemFlow - 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 stepSpecial 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



Create Profile Use Case

Use Case Name Create ProfileActors Unregistered UserEntry Conditions User gave a valid email address and password at first stepFlow - 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 systemSpecial 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 fieldExceptions handling - System asks for a not blank field

Table: Create Profile use case



Activity Diagram



Sequence Diagram



Alloy - Signatures

module swim

sig String

sig Username:String,surname:String,email:String,

//Friend Listfriend: set User,

//Will helphelpedtobe: set User

abstract sig RequestObjectUser: one User,madeby: one User

sig HelpRequest extends Requestrequestedtime: String,

//related abilityrelatedability: one Ability

sig FriendshipRequest extends Request

sig Abilityname: String,amountoftime: String,owner: one User



Alloy - Metamodel



Alloy - facts

//No friendship reflexivityfact nofriendshipreflexivityno x: User | x in x.friend

//An user can’t help himselffact nohelpreflexivityno x: User | x in x.helpedtobe

//An user can’t forward a general request to himselffact norequesttomeall r: Request | r.ObjectUser not in r.madeby



Alloy - facts

//An user can ask for friendship to other users that//aren’t already friend with himfact friendshipToNotAlreadyFriendall 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 abilityfact helperHasAbilityall u: User, r: HelpRequest, a: Ability |((u in r.ObjectUser) AND (a in r.relatedability))implies (u in a.owner)



Alloy - facts

//If A is friend of B, then B is friend of Afact friendshipSimmetryall 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 helperIsNotHelpedByApplicantall u1, u2: User, r: HelpRequest |(u1 in u2.helpedtobe) <=>((u1 in r.madeby) AND (u2 in r.ObjectUser))



Alloy - run


Design

Part II

Design phase


Design

User eXperience DesignBoundary - Control - EntitySystem ArchitectureComponent ViewDatabase Design

Design

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


Design


User eXperience Design


Design


Boundary - Control - Entity


Design


System Architecture


Design


Component View


Design


Database Design - ER


Design


Database Design

Completly useless. DB Schema is autogenerated by Jboss


Implementation introductionCode Organization

Coherence with DocumentationExtra Documentation

Part III

Implementation phase




What we used

Implementation

Complete in feautures

Partial in security and session handling




What we used

What we used

Eclipse

JBoss

Hypersonic DataBase, embedded in JBoss




Code Organization

Two different Project, Swim3 and Swim3Web

Swim3: contains session beans, entity beans and exceptions

Swim3Web: contains servlets and JSP




Packages of Swim3




Packages of Swim3Web




Coherence with BCE

Coherent in structure:

4 Entities: 4 Entity beans5 Controls: 5 Session beans3 Boundaries: 3 Servlets

Not fully coherent in method names




Coherence with Component

Fully Coherent in structure:

Not fully coherent in method names




Extra documentation

A manual has been produced, containing:

User Manual

Installation Guide


TestingDocumentation evaluation

Part IV

Testing phase



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 specifications

3 Implementation testing, by comparing with previous documentations- Black Box

The bodum’s ”implementation” part didn’t contain any user manual.





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




1 the system performs the search also with empty fields, and it returnsthe 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 ofseparation.

4 the system doesnt consider friendship relations while performing thesearch. It returns a list even if there are no friendship relationslinking us to helpers.

5 the system performs the search also with 0 degree of separation



RASDDDImplementation

Documentation evaluation - RASD

Many imprecisions. Theres a bit of confusion about Use Case andScenarios: for each scenario there is only a use case.

Diagrams are complete and accurate but often the event-owcontains not-expected actions, not appropriate for the use case.

Alloy model is incomplete; it does not contain all the requiredspecications and constraints.

The constraints described in Alloy are not implementend orrespected during implementation phase.




Documentation evaluation - DD

Boundary-Control-Entity contains some questionable choices (theEntity layer is made up of Entity Elements representing all the tablesin the database, including relational join tables)

A Component View is not included

According to BCE, there must be only one servlet and only onesession bean. In J2EE view we can see 7 servlets and 5 sessionbeans. The source package is made up of 13 servlets and 8 sessionbeans.




Documentation evaluation - Implementation

No user manual is provided.


swim

Technology