RECENT ASSIGNMENT

CITS4401 Software Requirements and Design
Software Design Assignment Worth 30% of total assessment Due: Friday, May 3rd, 2017 @4pm
Aim: The aim of this assignment is to test your ability to design a medium sized software system and to demonstrate your ability to manage and present clearly a design document. This assignment is designed for students working in groups of 2 or 3. You are allowed to work alone but improved group work is an aim of this unit and so is encouraged. All group members are required to contribute equal effort to the assignment. See the Unit Coordinator as soon as possible (well before the deadline) if you believe this is not the case. Please feel free to post to help4401 (the discussion forum) if you need to find other group members. If you choose to work on your own, the workload will be very high. The same marking criteria will be used whether the assignment is done collaboratively or individually.
Task: Your task for this assignment is to develop a system design for a computer system that facilitates electronic interaction between students and teachers during lectures, using mobile devices. The system will be called the Electronic Lecture Interaction (ELI). The requirements definition for this system is given in the ELI Requirements Definition reproduced below. As well as the analysis for the software design, you should document the rationale for the design decisions you make and also keep a log (listing date, task, people involved, time taken) for all work undertaken on this project.
Registration: Whether working in a group or by yourself, you must register on the following website: http://teaching.csse.uwa.edu.au/units/CITS4401/OGRES/public_html/index.php Please note down the group number generated by OGRES. On the first page of your design document, you should clearly show your group number, student number(s), family and given names of member(s) in the group.
Project Planning: You are expected to spend 40 to 50 hours on this assignment, including background reading. The work you submit for this assignment must be your own (either the designated group or the individual). In accordance with the School of CSSE Plagiarism policy “Any contribution from others … must be acknowledged as part of the submitted work. Students must inform the Unit Coordinator if their work is done jointly or borrows heavily from others. Failure to do so is plagiarism.” This includes the use of templates, textbook examples and all information from the web. For the full policy see http://www.governance.uwa.edu.au/regulations/student-conduct
Submission: Please ensure that you keep a backup copy of your system design document for yourself before submission. If your diagrams are hand-drawn, then you can scan all the pages of your assignment into a PDF file using any photocopier in a UWA library. Please ensure that your diagrams and handwriting are neat and legible. You can also investigate software tools that support drawing of UML diagrams. Your diagrams and descriptions can be put together as a Word document; however, you must convert the document into PDF for submission
Your document should be in PDF and should be submitted to the cssubmit website: https://secure.csse.uwa.edu.au/run/cssubmit If you work in a group, only one student should log onto cssubmit to do the submission. Please discuss among yourselves who should handle the submission and ensure that the right version of the document is submitted. All late submissions will be penalized in accordance with the University policy, i.e., a penalty of 5 per cent of the total mark allocated for the assignment is deducted per day for the first 7 days (including weekends and public holidays), after which the submitted work is not accepted. For the full policy, see http://ipoint.uwa.edu.au/app/answers/detail/a_id/2711/kw/late%20assignments
Your system design document (80%): Your design document for ELI should comprise the parts described below. For parts a to g, you should supply rationale for your design decisions; however, you do not need to structure your arguments in rhetorical steps (such as issues, proposals, criteria,…, as given in lecture 13). There is no minimum or maximum page limit on your design document. You should cover all of the parts below and adopt a common document format (font: Times, size: 12, margins: 2.5-3cm).
a. Functional modelling. Provide a use case diagram containing appropriate choice of actors and use cases which covers all the functionality of the given requirements definition but does not invent any new functionality. In the diagram, you should use the client’s language and not new or ambiguous terms. Boundary between this system and external systems should be clearly identified and justified. For each use case in your diagram, you should provide a table that describes the use case (see the lecture notes for the template).
b. Object modelling. Provide a class diagram to show the significant relationships between objects identified in ELI. You do not need to include boundary and control objects in this diagram. Reasonable roles and multiplicities should be given. For each class in your class diagram, supply the attributes (including the types) and major operations. Again, use the client’s language and do not invent new or ambiguous terms. Names of attributes and operations should be explained. To avoid putting too much information into a single diagram, it is recommended that your main class diagram for the DBMS should contain only the names of all the classes. For each class in the main class diagram, you can then draw a separate class diagram showing the attributes and operations.
C .Dynamic modelling part a. Each member of the group should provide 1 sequence diagram, chosen from any of the use cases in your use case diagram above. Clearly identify which student created each sequence diagram as marks will be allocated on an individual basis for this part. Identify in each sequence diagram, the participating actors and objects. Explain the type (entity, boundary, or control) of each object. Clearly label the messages sent between the participating objects. Your sequence diagram should be consistent with your class diagrams.
Design constraints. List 5 design constraints for ELI and prioritize them. Give sufficient explanation for each design constraint and its priority.
e. Subsystem decomposition. Describe in detail how you would decompose ELI into subsystems. Describe the services provided by each subsystem. Justification of your subsystem decomposition (such as coupling and cohesion) should be given. Are there other ways to decompose the system? Include diagrams alongside your description
Dynamic modelling part b. Each member of the group should supply 1 statechart diagram to describe the dynamic behaviour of the overall DBMS or an object with significant state variation in ELI. Clearly identify which student created each statechart diagram as marks will be allocated on an individual basis for this part. Give a detailed description for each diagram. Choose meaningful names for the states and transitions. Again, use the client's terminology.
Design patterns. Each member of the group should list 1 design pattern that would be appropriate to be used in the system. Describe which part of the system that each pattern is suitable for and justify why you chose the pattern. Identify the student author for each, as marks will be allocated on an individual basis for this part
System design rationale. Now think about implementing ELI. Your aim is to develop a working system that is efficient, reliable, and secure. Although you would, hypothetically, be free to use any programming language (you are not required to write any code in this assignment), one constraint is that ELI must work over a wireless network connection. Before beginning any coding, you would need to consider about hardware and software components that would fit together and work with your design. In your system design document, identify 3 issues that may have two or more possible solutions and that require you to resolve for the best solution for each issue. Follow the structured steps (issues, proposals, criteria, …) for the design rationale as shown in lecture 13 to address these issues and your decision rationale
Log. Attach at the end of your system design document a log, which should list the date, task, people involved, time taken, for all the work undertaken on this project. You can supply your log in a table form.
Seminar presentation (20%): You must give a short presentation to explain your design for ELI. If you work in a group, all group members must be present and participate in the talk. There is no need to create fancy Powerpoint slides. However, diagrams/text shown on the slides should be clear and legible. In the seminar, you should focus on the important aspects of your design, as there may not be sufficient time to go through all the fine details of your design. Further details about the presentation and timetable will be given on the cshelp forum and an announcement will be made in the class.
ELI: Electronic Lecture Interaction (Requirement Definition Document)
1. General Goals
1.1Purpose of the system
Student-teacher interaction increases the efficiency of learning and promotes a high value learning environment. However due to low staff-student ratios, universities rely more on traditional lecture environments where interaction is not encouraged and may not be feasible. However, as smartphones, tablet computers and laptops become more prevalent, we have the option to use mobile devices for large scale student-teacher interaction in lectures. The system should allow students to connect their mobile device at the start of a lecture, access electronic resources (readings, media files), complete electronic assessments, or respond (anonymously) to polls or questions set by the lecturer. The responses from polls and tests should be able to be automatically aggregated and displayed to students to give real time feedback in a lecture setting.
1.2.Scope of the system
ELI is designed to be used in a lecture environment, to allow the lecturer’s laptop computer to use a wireless router to communicate with students' mobile devices (smartphones, tablets and laptops). At the students' end, the system should provide a simple interface for downloading learning materials, responding to questions set by the lecturer and completing multiple choice tests. At the lecturer’s end, the system should allow students to be added to a class, learning materials to be made available, polls to be taken, electronic assessments to be set and results from polls and tests to be aggregated and displayed. For generality, we will assume no fixed format for the electronic assessment, and suppose that the lecturer will supply a module that allows ELI to automatically mark the assessment. It is intended that ELI will complement a conventional lecture system that displays and records lecture slides to the students (we will refer to this as the lecture presentation system).
1.3.Objectives and success criteria of the system
1.3.1. Develop a system that allows teachers and students to interact during lectures using mobile devices.
1.3.2. Provide a student interface that allows students to access teaching materials and complete electronic assessments and participate in polls.
1.3.3. Provide a teacher interface that allows teaching materials to be made available, polls and assessments to be set and real time feedback to be given to students.
1.3.4. A generic system that does not require students to purchase specific hardware, and a reliable system that allows medium classes (100+ students) to interact with minimal lag in data transfer.
2 Proposed System
ELI provides a system that allows students to interact with the lecturer using their own mobile devices. They should be able to download and access teaching materials, complete electronic assessments and participate in polls, and receive feedback in realtime. The lecturer should be able to set assessment and polls, display feedback to the students and release teaching materials throughout the lecture.
2.1 Functional Requirements
2.1.1 Student Registers
ELI shall provide a lightweight application to manage the students interface. On entering the lecture venue, a student will start the ELI app. The app will create a connection with the ELI system running on the lecturer's computer and prompt the student for login details. If the student's login details are correct, a session is created and the student is then
• able to access resources as they are released. Otherwise, the student is prompted to re-enter their details. The student’s session is recorded in a log for future reference.
2.1.2 Set up class
ELI provides an application to allow the lecturer to interact with students. Prior to• the start of a lecture, the lecturer starts the application and then sets up the class by selecting the list of students expected to attend, the teaching materials required (readings, media files, etc) and the electronic assessments and marking scripts. At the start of the lecture, the lecturer opens the ELI to students, who are then able
• to register with the ELI.
2.1.3 Access learning material
When the lecturer decides to releases some teaching material to the students, the• lecturer selects the file and the option -release-. The students are then notified (either verbally or electronically) that the material• is available. Through their interface, they can select the newly available resource and download it to their device. We assume that the format of the teaching material is sufficiently generic (pdf, avi, jpg, http) that the students' devices will have the necessary functionality to allow the students to access the resource.
2.1.4 Set poll
The lecturer is able to use ELI to set one or more poll questions.
This will• typically involve a question and a set of responses. The lecturer will select the question(s) and the option -poll-. The students are then notified of the poll question(s). The students will use their mobile device to access a response form from the• lecturer’s computer. They will select their response(s) and submit the form. As the responses are submitted, they are recorded on the lecturer’s computer. The• results are aggregated and the data is presented in common formats (e.g. pie graphs and histograms). The lecturer may then elect to share the results with students, either through the ELI system or the lecture presentation system
2.1.5 Set assessment
The lecturer is able to use ELI to set an assessment. This will typically be a• multiple choice test, but could potentially also involve short answer questions or writing computer code. The lecturer will select the assessment and the option -assess-. The students are then notified of the assessment(s). The students will use their mobile device to access the assessment from the• lecturer’s computer. They will be given time to complete the assessment and submit their answer to the ELI system. As the responses are submitted, the marking module is run within ELI to assess• the submission and the results are recorded on the lecturer’s computer. The results are aggregated and the data is presented in common formats (e.g. histograms with mean and standard deviation). The individual's results are then made available to each mobile device so students• may (privately) view their mark. The lecturer may then elect to share the results with students, either through the ELI system, or the lecture presentation system
2.2 Example scenario
Tim is lecturing CITS4401. Prior to the lecture he sets up the class list with all CITS4401 students, he prepares the lecture overview, a reading and a multiple choice test. At the start of the lecture he starts the application on his machine and immediately makes the lecture overview available to all students. Jack is an CITS4401 student. He arrives at the lecture and takes out his mobile device (an iPad). He starts the ELI app which creates a connection to Tim's computer and prompts Jack for his user name and password. Jack enters these correctly and then downloads the lecture outline to his iPad. Twenty minutes into the lecture, Tim announces there is a short reading following by a 5 question multiple choice test on the reading. Jack uses the ELI app to download both the reading (pdf) and test (html form). He completes the reading and the test and then presses submit. Tim receives submissions from all the students and displays the number of people who got each question right. Jack’s individual mark is displayed on his device. He got 4/5 and, like most people, he got question (4) wrong. Tim realizes that he has not adequately explained the relevant concept so he goes over it again in more detail.
3 Quality Requirements
The following section will aim to highlight the non-functional requirements of the ELI system.
3.1 Performance Characteristics
3.1.1 Student Device Performance The student’s mobile device would ideally be a tablet computer, but may also be a smartphone. As mobile devices have limited power and processing capabilities this system must not use an excessive amount of power or require processor intensive operations
. 3.1.2 Lecturer Computer Performance The lecturer’s computer (possibly augmented with a wireless router) will be required to act as a server for more than 100 devices. It should be able to do this with little noticeable lag. It will also be required to mark multiple assessments, collate, record and display the results in real time.
3.2 Quality Issues
3.2.1 Reliability Reliability of the system is an important requirement for the ELI system. Lecture time is valuable, so it is important that, during lectures, the downtime of the lecturers systems is less than 1%. All student devices should be able to reliably connect and reconnect to the system as required. Downtime for student devices should be less than 5% during lectures. The results from assessments should be recorded securely and backed-up as soon as possible to prevent loss of data.
3.2.2 Portability System must be portable amongst different mobile devices. Total coverage may not be possible, but the systems should be available to a large range of mobile devices, such as the Android platform or the iOS (iPad) platform. The ELI system should be able to run adequately off a laptop with a wireless router.
3.2.3 Usability The ELI system must have a simple and intuitive interface for students and lecturers to use, as there will only be limited training resources available. Someone familiar with the mobile device should be able to adequately use ELI after no more than 5 minutes training. 3.3 System Modifications
3.3.1 Maintainability As the mobile device market is rapidly evolving, it is important that the system is designed to be able to adapt to new devices, and to allow extra functionality and device features to be incorporated in future versions.
3.3.2 Scalability The current specification is for medium lectures of between 100 and 200 students. However the system will be most valuable for large classes (600+ students) so it is important that it is designed to allow for future version to cater for larger classes.
3.4 Security Issues Security is particularly important in the context of assessments taken through ELI. As the primary purpose of mobile devices is communication, it is difficult to prevent students communicating during tests. This risk may be mitigated by providing individual assessments to students (e.g. reordering questions etc). Students must provide a username and password to access the system. Students must be enrolled in a unit to interact using ELI.