S3 ECns

ECn 1

Item	Scenario Description
Title/ID	New User Registration in a Customer Management System.
Event Description	When a new user registers in the customer management system, a registration request is sent to the server. This request includes information such as name, email address, and password.
System Response	The system verifies the information provided by the user, and if it is valid, it creates a user entry in the relational database. Then, it sends a registration confirmation to the user.
Possible Anti-patterns	Possible anti-patterns could include duplicate registration of the same user due to concurrency in user creation, which could lead to database integrity issues. Another possible anti-pattern would be inadequate validation of user information, which could allow registrations with incorrect or malicious data.
Storage and Retrieval Strategy	The storage strategy would involve using a relational database that allows for transaction and concurrency control to ensure data integrity. Retrieval could be based on the use of transactions and record locking to prevent conflicts and maintain consistency.
Storage Type	In this scenario, a relational database such as MySQL, PostgreSQL, or Microsoft SQL Server would be used, providing ACID (Atomicity, Consistency, Isolation, and Durability) to ensure data integrity and safe recovery in case of failures.

ECn 2

Item	Scenario Description
Title/ID	Creating a New Event
Event Description	A user creates a new event in the application.
System Response	The system confirms the creation of the event and displays a success message to the user.
Possible Anti-patterns	The network connection is unstable, and the event creation request is not sent immediately.
Storage and Retrieval Strategy	The system stores the event creation request locally on the user's device and sends it to the server when the connection is restored.
Storage Type	Local storage on the user's device.

ECn 3

Item	Scenario Description
Title/ID	articipation in an Event
Event Description	A user wishes to join an existing event by clicking on a "Participate" button.
System Response	The system processes the participation request and updates the list of participants in the event.
Possible Anti-patterns	The confirmation response for participation doesn't arrive immediately due to network issues.
Storage and Retrieval Strategy	The participation request is locally stored on the user's device and is forwarded to the server when the connection is restored.
Storage Type	Local storage on the user's device.

ECn 4

Item	Scenario Description
Title/ID	User wants to check for events when there is no Wifi connection
Event Description	The user has previusly being logged in the app, but his wifi connection goes off. Because the user is boring, it decides to check for an event to do while the wifi goes back.
System Response	The system shows the last events that were available when the wifi was turn on.
Possible Anti-patterns	The user do not sees any message that the events displayed are outdated, so the information the user is seeing can have changed and the user will not be noticed. Another Anti-pattern is that there were not events previusly loaded in the app local storage, so the user sees a view with any event, which makes him think that the app has a bug or is not working.
Storage and Retrieval Strategy	The strategy would be to save the events in local storage, in order to keep track of the events that were available when there was connection wifi. In case the wifi comes back, the events must be reloaded form the current events, and the local storage must be updated with the actual events.
Storage Type	In this scenario, the best way is using the own app memory to save the data from this events.

ECn 5

Item	Scenario Description
Title/ID	User wants to create an event, but there is not Wifi connection
Event Description	The user decided to create an event, but in the middle of filling the form the wifi goes off. The user decided to continue and click the button "create event" until the event is created, because at any time the Wifi can go back
System Response	The system must show that there is not Wifi when it goes off, and when the user clicks to create the event, the app must reply that there is not wifi and when the wifi come back, the event can be created. The information the user has already typed must be saved in the form untill wifi comes back, in order to let the user whene the wifi connection is back if it really wants to create the event with all the information previusly loaded in the form.
Possible Anti-patterns	The user click the button of submit the event and nothing happens. The user thinks this is a bug and start clicking the button many times because is confused of why the event is not created. Another anti-pattern is that the user change the view, and when he comes back all the information the user has previusly typed is gone.
Storage and Retrieval Strategy	The strategy would be to save the events in cache, in order to keep track of what the user has typed, so when the wifi comes this information can still be used by the user to create an event
Storage Type	In this scenario, the best way is using cache instead of local storage. This is a good idea because local storage is only for data that must reamin in the app always, while creating and event is more like temporary data, because this data can be changed by any time by the user, and when the event is created, this data will go to the server instead of being obly in the device.

ECn 6

Item	Scenario Description
Title/ID	The user wants to see his profile to see how much time it has used the app, or how many events it has joined, but there is not Wifi
Event Description	The user want to share with his friends the time it has spent in Hive app looking for groups, and telling them in how many events he has registered. What happens is that the user has no Wifi connection, but he still wants to check his info to share it with his friends.
System Response	The system is aware that there is not Wifi, so the system show from local storage the last information it has about the users time spend in the app, and how many events the user has joined.
Possible Anti-patterns	The user click the Profile view and nothing is shown. The user wants to see at least its name in order to log off, but nothing is shown so the user think the app has crashed and his credentials to log in, with the events the user has joined are lost forever
Storage and Retrieval Strategy	The strategy would be to save the data showed in the Profile view in local storage, in order to access at any time to this data and showing this always to the user.
Storage Type	In this scenario, the best way is using local storage in order to hace important data that do not change regularly, like the user name or the email associated to the user. Also, having in local storage the time the user has spend on the app can be really good in order to have easily this information available at any time.