Scenario
Nowadays fitness tracking devices are very popular. These are now sold by many retailers, developed by several different companies, with some functionality variations. Your company, NewIdeas, is always leading the way in identifying new areas to explore, building prototypes, and then selling the ideas to larger companies according to some very profitable terms.
NewIdeas is starting a new project to explore the perceived lack of balance between the hours spent at work vs enjoying life (also known as work/life balance). NewIdeas recognises that many parents have similar concerns for their children with respect to time spent playing on screens vs being involved in other kinds of fun activities. NewIdeas believe that they can develop a dual-purpose product addressing both audiences. They are calling it BalanceBit. The intention is for this product to be sold to companies that already run their fitness tracking
business, so that it can be added to their pre-existing packages.
NewIdeas will have two teams working on this new endeavour. Team H will develop a variant of the wrist fitness tracking devices on the market with a touch screen (the hardware). Team S will be developing the software. You are one of the members of Team S that will be developing the software for BalanceBit. NewIdeas have decided to develop the work/life balance aspect first, as a proof-of-concept.
After an interview with the marketing team, the vision relating to the BalanceBit system is summarised as follows:
Some minimal functionality will be deployed on the wrist device and some functionality will be implemented with a Desktop application1. Data (the records produced by the wrist device as described below) will be stored initially on the wrist devices, subsequently will be moved to files managed by the Desktop application, and eventually will be moved on the NewIdeas’ cloud servers.
The Wrist software
- Each wrist device is associated with a single BalanceBit account. The account will be created by the BalanceBit device wearer from a desktop computer using the Desktop application.
- A person wearing the wrist device will be able to select the type of day (TP) it is from the list below:
o working,
o off, or
o holidays.
This only needs to be done once a day using the wrist device. The default value for TP will always be the setting from the previous day. This value can be changed at any time of the day, the whole day is of the type that the user selected last during that day. - The wrist device will be able to detect whether the wearer is “awake” or “asleep” and will record the respective periods (start/end).
- As the day goes by, a person wearing the wrist device can switch between “work” and “leisure”.
- The wrist device shall be able to detect if it is being worn or not. When the wrist device is not being worn, the type of activity will be recorded as "unknown".
- The wrist device shall be able to detect steps and maintain a steps counter for the current day. The wrist device stores minute by minute data, depicting periods of device usage; within those periods of usage, the periods when the wearer is awake; and within those periods when they are awake, the periods dedicated to work and leisure.
- This data, held on the wrist device, will be synchronised with the Desktop application. In this prototype this synchronisation will be done “on demand”, i.e., when the user takes the steps below:
o he/she logs into the desktop application and requests synchronisation of the Desktop application with the wrist device;
o the Desktop application then connects with the wrist device (e.g., wirelessly) and obtains the records that are stored in the wrist device for all the previous days. - The wrist device can hold records for up to seven days, before it starts to overwrite them.
Desktop application
- Users of the BalanceBit Desktop application can create new accounts (identified by an email address, a wrist device ID, and a password). They can use username and password to login to the Desktop application. They shall also be able to logout from the desktop application.
The Desktop application shall be able to synchronise the data it holds with the data held in the wrist device associated with that user account as follows:
o Upon successful login to Desktop application the Desktop application shall undertake a synchronisation with the wrist device;
o Automatic and mandatory synchronisations of the wrist device with the Desktop application shall take place upon logout from the Desktop application, too.
o Synchronisation can also be requested by the user (after a successful login) at any time while the user is logged in.
Synchronisation of the Desktop application with the wrist device is followed by a synchronisation of the data held in the Desktop application with the data held in the cloud storage. Upon successful synchronisation with the cloud storage all data held in the Desktop application is removed from the files of the Desktop application.
- The Desktop application also allows users to create group(s) of friends/family to share own “achievements” with them, e.g., the daily count of steps, etc. Each user can register a new group: the user becomes the “owner” of the group, and the group is assigned a unique id. The owner of a group can invite new members to join the group using the functionality of the Desktop application to send emails via an external (SMTP) mail service. The invitations are either accepted or rejected by the respective invitees, who must access dedicated web-pages held on the web-portal of NewIdeas. Once the user accepts an invitation to join a group they are added to the group and may view the current data (“achievements”) held in the cloud server on the members of the group(s)2.
- The desktop application shall provide functionality for creating reports on demand. The data requested for the reports will be retrieved from the cloud storage as necessary. All reports can be viewed on the screen or, if the user so decides, can be printed. These reports are listed below:
o Depicting what kinds of activities occurred, and when, in a day (showing start/end times of waking hours, start/end times of working hours, start/end times of leisure hours and start/end times of unknown activities).
o Providing summaries:
▪ the percentage and the number of waking hours on a day/week/month of working days used on work, on leisure and unknown.
▪ the percentage and the number of waking hours on a day/week/month of days of holidays used on work, on leisure and unknown.
▪ the percentage and the number of waking hours on a day/week/month of days off used on work, on leisure and unknown.
▪ the percentage and the number of waking hours on a day/week/month of any combination of type of days used on work, on leisure and unknown.
o Providing the same summaries as above, but with respect to the whole day, while depicting sleeping hours as a category of their own.
Assignment
You are expected to develop a set of requirements and UML models on BalanceBit software and answer the following questions.
Question 1: User requirements
Using the Volere Template, introduced in Lecture 1, specify 1 functional and 1 non-functional requirement for the BalanceBit using the provided scenario. (5 marks)
Question 2: Use case Diagram
Draw a use case diagram for the Desktop application of BalanceBit, which covers the functionality of the Desktop application described in the scenario3. The diagram should include: - The Actors (primary and secondary) of the Desktop application. Consider the users of the Desktop application and the external systems the Desktop application relies upon;
- The use cases, which capture the main services provided by the Desktop application to the respective users.
- The generalization relationships between Actors.
- The relationships between the use cases (<>, <> and generalization). (20 marks)
Question 3: Use case Specifications
Core functionality of the Desktop application is allowing for synchronisation (i.e., retrieving the data from the wrist device and storing it on the Desktop application) with a wrist device, which in turns is followed by synchronizing the data held by the Desktop application with the cloud storage.
Let us assume that the use case synchronising the Desktop application with the wrist device is called “SynchWithWristDevice” and the use case synchronising the desktop application with the cloud storage is called “SynchWithCloudStrorage”.
Provide use case specifications of these two related use cases (synchronising with the cloud always follows synchronising with the wrist device) and any other use cases that might be related to either of them (i.e., such that would have <>/<> or generalization relationships with either “SynchWithWristDevice” or “SynchWithCloudStrorage”).
The specifications should over all the options listed in the statement of requirements and should:
• Spell out the interaction between the actors and the system (the Desktop application) related to synchronization:
o connecting to the wrist device (as part of SynchWithWristDevice), and
o connecting to the cloud storage (as part of SynchWithCloudStrorage).
Recall that despite the different points in time (upon Login, upon Logout or on demand) synchronization of Desktop application with the wrist device is always directly or indirectly triggered by the User who is using the Desktop application.
• Capture the important exceptional circumstances (alternative flows) that might occur (e.g., connection with the wrist device fails or the wrist device ID does not match the one recorded in the Desktop application, etc.). Make plausible simplifying assumptions if/when needed. (10 marks)
Question 4: Analysis class diagram
a) Develop an analysis class diagram for the Desktop application of BalanceBit. Concentrate on the problem domain classes, show their attributes and important operations and the associations between the classes.
• There is no need to include type information, get and set methods, or constructors.
• Consider a minimal set of boundary and control classes that might be needed for the realization of the use case “SyncWithWristDevice” (as required in Q5).
• Relationships:
o Use associations in your class models and label them with association or role names, as appropriate, show the association directions, and multiplicities, but don’t worry about navigability.
o Use generalization (inheritance) between classes where appropriate.
o Don't bother with dependency relationships (30 Marks)
b) Substantiate your answer by demonstrating competence with the taught techniques for identifying analysis classes and their relationships as follows:
b.1. Apply the noun/verb analysis to the following fragment from the provided
scenario:
“The desktop application also allows users to create group(s) of friends/family to share own “achievements” with them, e.g., the daily count of steps, etc. Each user can register a new group: the user becomes the “owner” of the group, and the group is assigned a unique id. The owner of a group can invite new members to join the group using the functionality of the Desktop application to send emails via an external (SMTP) mail service. The invitations are either accepted or rejected by the respective invitees, who must access dedicated web-pages held on the web-portal of NewIdeas. Once the user accepts an invitation to join a group they are added to the group and may view the current data (“achievements”) held in the cloud server on the members of the group(s) .”
b.2. Demonstrate the use of CRC cards technique on the following 3 classes from the problem domain: Account, Group, Member.
b.3. Apply Robustness analysis to the analysis class model by adding to the class diagram a sufficient number of control and boundary classes and checking if the associations between the classes in the class diagram satisfy the robustness analysis rules. (10 marks)
Question 5: Use case realisation (sequence diagram)
Draw a sequence diagram that realizes the use case “SyncWithWristDevice” for the case when synchronisation is requested by the user via the GUI4. The diagram should cover all possible inclusions (e.g., SyncWithCloudStorage), branches (extensions, alternative flows and if-else’s) and loops as defined in your answer to Q3. Make sure that your sequence diagram is consistent with the class diagram developed in Q4 and, of course, with the use case specification developed in Q3.
Hint: Note that as a result of developing the sequence diagram your analysis class diagram may change – you may need to add new operations to some of the classes or even add new classes to the class diagram.
The use case specifications may change, too: you may discover that the flows (the main and/or the alternatives) may need to be modified.
The UML models included in the submission must be consistent. The simplest way to achieve consistency is to complete all UML models, and only then take a snapshot of the class diagram, the use case model (diagram and specification) and of the sequence diagram and include these in your CW submission. (25 marks)