UML代写:INM312 BalanceBit Software

给BalanceBit Software绘制UML图,包括Use Case Diagram, Analysis Class Diagram以及Sequence Diagram.

Introduction

There is one piece of coursework for INM312 worth 30% of the total mark for the module. You are asked to analyze a scenario and then develop a set of UML models related to the specification of the system described in the scenario.

Please note that although this coursework has been released in Week 3, the coursework tests your knowledge of topics that will be taught in subsequent weeks, and you will not be able to answer all the questions until the end of Week 5, unless you read ahead in the text book on class and sequence diagrams.

You are advised to start working on the coursework as soon as possible.

Case study: BalanceBit Software

Fitness tracking devices are very popular at the moment. These are now sold in 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 software idea 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. One team will develop a variant of the wrist fitness tracking devices on the market with a touch screen (the hardware). The other team will be developing the software. You are one of the members of a NewIdeas team that will be developing the software for BalanceBit.

NewIdeas have decided to develop the work/life balance aspect first, as a proof-ofconcept. The only changes needed for the screen time variant are on labels of the user interface.

After an interview with the marketing team, the vision relating to the BalanceBit system is summarized as follows:

Some minimal functionality will be deployed on the wrist device and some functionality hosted on apps running on desktop devices1. Data (the records produced by the wrist device) will be stored on the wrist devices, desktop devices and on NewIdeas’ cloud servers.

The Wrist software

  • Each wrist device is associated with a single BalanceBit account.
  • A person wearing the wrist device will be able to select the type of day it is: working, off, or holidays. This only needs to be done once a day. The default value 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.
  • When the wearer wakes up, the wrist device will always go into leisure mode. This will only be changed by the wearer of the wrist device explicitly changing that on the device.
  • As the day goes by, a person wearing the wrist device can switch between work and leisure.
  • The wrist device will also store information on whether the person is awake or asleep. It 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 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.
  • This data will be synced with the desktop devices. In this prototype this will be achieved by the user of the wrist device explicitly as follows: he/she logs into the desktop application on a desktop device and asks it to sync; the desktop device then contacts the wrist device 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. The desktop devices will never overwrite data2.

Desktop application

  • Users of the BalanceBit desktop app can create new accounts (identified by an email address and having an associated password and wrist device), as well as login to accounts and logout of accounts.
  • The desktop device shall accept (from a user who has logged in to an account in the desktop application) requests to sync data from the wrist device associated with that account. It shall ignore sync requests for data from other wrist devices. Synchronisation with the wrist device is followed by synchronisation of the data held in the desktop application with the data held in the cloud storage.
  • 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 invitees, who must access dedicated web-pages held on the cloud storage. 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).
  • The desktop application will also provide functionality for creating reports on demand. These include:
    • 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);
    • 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
    • Providing the same summaries as above, but with respect to the whole day, while depicting sleeping hours as a category of their own.

Questions

You are expected to develop a set of models on BalanceBit software and answer the following questions.

Question 1 - Use Case Diagram

  • a) Develop a use case diagram for desktop application of BalanceBit software, showing the primary and secondary actors, the use cases and the relationships between them. Pay attention to all actors, including the secondary actors. (20 marks)
  • b) The core functionality of the desktop application is synchronising with the wrist device and the desktop application combined with syncing the data on desktop application with the data held on 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 a use case specifications of these two related use cases (synching with cloud always follows synching with the wrist device) and any other use cases that might be related to either of them (i.e. such that have <<include>>/<<extend>> or generalisation relationships with the either “SynchWithWristDevice” or “SynchWithCloudStrorage”). The specifications should cover all the options listed in the statement of requirements and should:
    • spell out the interaction between the actors and the system related to synchronisation,
    • connecting to the wrist device and connecting to the cloud storage,
    • 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 desktop application).

Make plausible simplifying assumptions if/when needed. (15 marks)

Question 2: Analysis class diagram

  • a) Develop an analysis class diagram for the desktop application of BalanceBit. Concentrate on the problem domain classes, showing 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 different actors to be able to communicate with the desktop application.
    • Relationships:
      • Use associations between classes in your class diagram and include association and/or role names, as appropriate, direction arrows, and multiplicities, but don’t worry about navigability.
      • Use generalization where appropriate.
      • Don’t bother with dependency relationships (30 marks)
  • b) Substantiate your answer using one or more of the taught techniques for identifying classes and their relationships: noun/verb analysis procedure, CRC cards, robustness analysis. You may use more than one technique in order to improve your diagram, e.g. by discovering new classes, attributes or operations, but using more than one analysis method will not necessarily get you extra marks. (10 marks)

Question 3: Use case realization (sequence diagram)

Draw a sequence diagram that realizes “SynchWithWristDevice” and all the related use cases (“SynchWithCloudStrorage” should be one of them). The diagram should cover all possible branches (extensions and alternative flows), loops that are documented in the use case specifications you develop in your answer to Q1b. Make sure that your sequence diagram is consistent with the class diagram you develop in your answer to Q2 and with the use case specifications you develop in your answer to Q1b. (25 marks)

Submission guidelines

1) Submissions can only be made electronically via Moodle, using the coursework submission area for the INM312 module.
2) The deadline for submission is 23:55 on 30th November 2018.
3) Moodle will adhere to the cut-off date/time and automatically prevent you from attempting to submit your work after the deadline.
4) I suggest that you do not even attempt to work right up to the deadline and instead recommend that you get your submission in well before the cut-off time. The last thing you need is the stress and worry of watching the clock tick and then encountering a problem that delays you. It can and does happen!

Late submission policy

In accordance with the usual policy on coursework submission, late submission will receive 0% unless there are extenuating circumstances with supporting evidence, which must be notified to Anita Grant in advance of the deadline.

Feedback

General feedback will be provided during the revision lecture in Week 11. We will aim to get coursework marked and returned to you within 3 weeks of submission. You will receive individual feedback and a provisional mark via the grade book in Moodle once the marking is completed.

Format

All UML diagrams must be created using a UML tool and exported as images for subsequent inclusion in the submission document. Diagrams drawn without a tool will be penalized by deducting 20% from the awarded mark.

Your coursework must be submitted as a single PDF file. Export your diagrams from the UML tool you have used as images, and then assemble all your answers, text and diagrams, in a single word processor file and convert to PDF. Make sure you diagrams are eligible.

If in doubt whether your diagrams are eligible, you can submit the entire project, e.g. as a Visual Paradigm file (.vpp).

UML Diagrams

UML tools are available on the PCs in the laboratories, and you can also download a copy for your personal machine (Windows, Mac, or Linux) by following the instructions provided on Moodle.

Note that you may come across variations in UML syntax on websites and within certain textbooks. This is of no consequence for the purposes of this coursework.