Swim

525 views
471 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
525
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Swim

  1. 1. 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
  2. 2. 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  3. 3. Requirements Analisys and Specifications Part I Requirements Analisys and Specification phase Antonio Troina [708267], Federico Villa [720492] SWIM
  4. 4. 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  5. 5. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Notification: 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  6. 6. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  7. 7. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy RASD Intro State charts: Figure: Request state chart Figure: User state chart Antonio Troina [708267], Federico Villa [720492] SWIM
  8. 8. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  9. 9. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  10. 10. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy Use Case Diagram: Antonio Troina [708267], Federico Villa [720492] SWIM
  11. 11. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy Examples Scenario: Registration to the System Involved use cases: Register Create Profile Antonio Troina [708267], Federico Villa [720492] SWIM
  12. 12. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  13. 13. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  14. 14. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy Activity Diagram Antonio Troina [708267], Federico Villa [720492] SWIM
  15. 15. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy Sequence Diagram Antonio Troina [708267], Federico Villa [720492] SWIM
  16. 16. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  17. 17. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy Alloy - Metamodel Antonio Troina [708267], Federico Villa [720492] SWIM
  18. 18. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  19. 19. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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) Antonio Troina [708267], Federico Villa [720492] SWIM
  20. 20. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios 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)) Antonio Troina [708267], Federico Villa [720492] SWIM
  21. 21. RASD Intro Requirements Analisys and Specifications Use Cases and Scenarios Alloy Alloy - run Antonio Troina [708267], Federico Villa [720492] SWIM
  22. 22. Design Part II Design phase Antonio Troina [708267], Federico Villa [720492] SWIM
  23. 23. 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 first 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  24. 24. User eXperience Design Boundary - Control - Entity Design System Architecture Component View Database Design User eXperience Design Antonio Troina [708267], Federico Villa [720492] SWIM
  25. 25. User eXperience Design Boundary - Control - Entity Design System Architecture Component View Database Design Boundary - Control - Entity Antonio Troina [708267], Federico Villa [720492] SWIM
  26. 26. User eXperience Design Boundary - Control - Entity Design System Architecture Component View Database Design System Architecture Antonio Troina [708267], Federico Villa [720492] SWIM
  27. 27. User eXperience Design Boundary - Control - Entity Design System Architecture Component View Database Design Component View Antonio Troina [708267], Federico Villa [720492] SWIM
  28. 28. User eXperience Design Boundary - Control - Entity Design System Architecture Component View Database Design Database Design - ER Antonio Troina [708267], Federico Villa [720492] SWIM
  29. 29. User eXperience Design Boundary - Control - Entity Design System Architecture Component View Database Design Database Design Completly useless. DB Schema is autogenerated by Jboss Antonio Troina [708267], Federico Villa [720492] SWIM
  30. 30. Implementation introduction Code Organization Coherence with Documentation Extra Documentation Part III Implementation phase Antonio Troina [708267], Federico Villa [720492] SWIM
  31. 31. Implementation introduction Code Organization What we used Coherence with Documentation Extra Documentation Implementation Complete in feautures Partial in security and session handling Antonio Troina [708267], Federico Villa [720492] SWIM
  32. 32. Implementation introduction Code Organization What we used Coherence with Documentation Extra Documentation What we used Eclipse JBoss Hypersonic DataBase, embedded in JBoss Antonio Troina [708267], Federico Villa [720492] SWIM
  33. 33. Implementation introduction Code Organization Coherence with Documentation Extra Documentation Code Organization Two different Project, Swim3 and Swim3Web Swim3: contains session beans, entity beans and exceptions Swim3Web: contains servlets and JSP Antonio Troina [708267], Federico Villa [720492] SWIM
  34. 34. Implementation introduction Code Organization Coherence with Documentation Extra Documentation Packages of Swim3 Antonio Troina [708267], Federico Villa [720492] SWIM
  35. 35. Implementation introduction Code Organization Coherence with Documentation Extra Documentation Packages of Swim3Web Antonio Troina [708267], Federico Villa [720492] SWIM
  36. 36. Implementation introduction Code Organization Coherence with Documentation 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  37. 37. Implementation introduction Code Organization Coherence with Documentation Extra Documentation Coherence with Component Fully Coherent in structure: Not fully coherent in method names Antonio Troina [708267], Federico Villa [720492] SWIM
  38. 38. Implementation introduction Code Organization Coherence with Documentation Extra Documentation Extra documentation A manual has been produced, containing: User Manual Installation Guide Antonio Troina [708267], Federico Villa [720492] SWIM
  39. 39. Testing Documentation evaluation Part IV Testing phase Antonio Troina [708267], Federico Villa [720492] SWIM
  40. 40. Testing List compatible helpers Documentation evaluation 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  41. 41. Testing List compatible helpers Documentation evaluation List compatible helpers 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 find 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  42. 42. Testing List compatible helpers Documentation evaluation 1 the system performs the search also with empty fields, 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 Antonio Troina [708267], Federico Villa [720492] SWIM
  43. 43. RASD Testing DD Documentation evaluation 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  44. 44. RASD Testing DD Documentation evaluation 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. Antonio Troina [708267], Federico Villa [720492] SWIM
  45. 45. RASD Testing DD Documentation evaluation Implementation Documentation evaluation - Implementation No user manual is provided. Antonio Troina [708267], Federico Villa [720492] SWIM

×