COMP3211 Software Engineering Fall 2022
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
COMP3211 Software Engineering
Fall 2022
Course Project Description
In this project, each group needs to apply the knowledge learned in the course to develop a command-line-based game called Jungle. Appendix B gives more information about the game.
Group Forming: Form your groups of 3 to 4 students on Blackboard before or on Sept. 30, 2022. Afterward, students with no group will be randomly grouped, and requests for group change are only approved if written agreements from all members of the involved groups are provided before or on Oct. 12, 2022. No group change will be allowed after Oct. 12, 2022. It is okay for students from different class sessions to team up.
Object-oriented vs. Procedural-oriented: You are suggested to design and implement the game in an object-oriented way because it makes certain desirable code properties, e.g., high cohesion and low coupling, easier to achieve. That, however, doesn't mean your grade will be lower if you choose the other way. We will consider the limitations of each design and programming paradigm when grading, so if you feel more comfortable with the procedure-oriented paradigm or if you don't have enough time to learn the OO techniques for this project, feel free to adopt the procedure- oriented way. You may program the game in either Java or Python. If you want to use another programming language, consult your instructor first.
Deliverables: Each group needs to produce the following deliverables. While different deliverables have different deadlines, make sure you first read the whole description carefully to get an overview of what you need to do in the project.
1. A software requirements specification for the game. (8 points)
You may decide on the specifics regarding how users play the game, but all the rules given in Appendix B should be respected, and the requirements should be valid, consistent, precise, complete, and verifiable.
a. Document structure: See slides “The Structure of A Requirements Specification (1) &
(2)” from “Lecture 04 Requirements Engineering” for the overall structure of a requirements specification; Note that chapters “System models” and “System evolution” are not needed in your requirements specification.
b. Contents: All the important requirements, both functional and non-functional, should be included.
• See slides “Natural Language Specification” and “Example Natural Language Specifications” from the same lecture for guidelines on, and examples of, writing natural language requirements.
• To facilitate unit testing (see Deliverable 3), you are strongly recommended to adopt the Model-View-Controller (MVC) pattern a) for your game. Since MVC is a generic pattern, you need to explain how you would apply that generic pattern in the context of the game. Particularly, in the System Architecture chapter, you need to describe the overall structure of the game, the reasons for choosing that structure, the major components in that structure, and how those components interact with each other. (“Architectural Design” will be discussed in Week 6.)
• The rules in Appendix B reflect some, but not all, important requirements of the system, and they are not written in the form of software requirements.
• You are not recommended to add obviously additional features, e.g., a GUI or support for playing online, to the game. Your efforts to design and implement the additional features will not get you any extra points.
c. Deadline: Oct. 12, 2022.
2. An API design document of the game. (7 points)
The deliverable should contain 1) a collection of code components like class and method declarations, 2) diagrams to demonstrate the relation and collaboration among the code components, and 3) a brief description of the important design decisions. It is okay to prepare the code components in the form of source code files, while the diagrams and
a) https://en.wikipedia.org/wiki/Model-view-controller
description should be put into a single Word/PDF file. Compress all the files into a ZIP archive and submit the ZIP archive.
a. Code components: If you adopt object-oriented techniques, the classes in your source files should contain major fields and public/protected methods; If you adopt procedural-oriented techniques, your source files should include user-defined data types and functions. Each method/function should contain a return type, the method/function name, argument names and types, possible exception declarations, and an empty body. Note that you don’t need to implement the methods/functions yet.
Since Python is dynamically typed, you cannot include return and argument types in Python method declarations. In that case, you could annotate your Python method declarations with type hints (https://docs.python.org/3/library/typing.html).
b. Diagrams: The diagrams should demonstrate the relations and the collaborations among the code components. The relations between components can be modeled using class diagrams, while the collaborations can be modeled using activity and/or sequence diagrams. Note that the classes in a class diagram represent realistic or conceptual things in software systems, so class diagrams are also useful even if you plan to develop your game in a procedure-oriented way.
c. Important design decisions: Any decision you make when designing your game is a design decision, and these decisions eventually determined the details in your design. Here you can decide by yourself which aspects of your design are important. Such aspects may be, e.g., parts that you think were difficult to design, parts where you spent the most time to come up with the design, parts where you think your design was smart and worth mentioning, or parts that are critical for the game.
d. Deadline: Oct. 21, 2022.
3. A suite of unit tests for the game model based on the API design. (7 points)
Writing unit tests based on the API design is an effective way to check whether the APIs defined are consistent and sufficient for implementing the requirements. Each test should clearly state what functionalities they exercise (e.g., in comments), how the functionality is exercised step by step, and what the expected results are (e.g., using assertions).
a. Unit testing framework: Since all the unit tests should be automatically executable, you are strongly recommended to prepare the tests using unit testing frameworks. Here are two example unit tests, in JUnit for Java and unittest for Python, respectively, for your reference.
|
# unittest for Python import unittest class Testing(unittest.TestCase): def test_string(self): a = 'some' b = 'some' self.assertEqual(a, b) if __name__ == '__main__ ': unittest.main() |
You may also use other unit testing frameworks, but it is important that your unit tests, once combined with the implementation of your game, should be executable. Please refer to the JUnit and unittest documentations/tutorials for more information about writing unit tests based on those frameworks.
b. APIs to test: As stated above, you only need to write unit tests for APIs defined in the model, but not the view or controller, of the game.
c. Revisions to the API design: If you need to revise your API design when preparing the tests, you should also include in the deliverable a separate document to explain the revisions you made and the reasons for the revisions.
d. Deadline: Nov. 4, 2022.
4. An implementation of the game. (9 points)
The deliverable should include 1) the complete source code for the game, 2) the final suite of unit tests and its coverage of the source code lines in the game model, 3) a short developer manual explaining how to compile the code and build the project, 4) a short user manual describing how to play the game, and 5) a short video (no more than 4 minutes) of the game in play. The implementation should support all the requirements listed in the requirements specification and make a playable game.
a. Source code and unit test suite: If you need to revise your API design or tests during the implementation, you should include in the deliverable a separate document to explain the revisions and the reasons for them and discuss what you could have done differently to avoid such revisions. Add a separate TXT file for the test coverage results and place the file together with your test files.
b. Developer manual: Here, you may assume the readers know how to properly set up a Java/Python development environment, and you don’t have to explain that in the manual. You only need to prepare the manual for one platform, e.g., Windows, macOS, or Ubuntu. You need to explain which version of JDK/Python was used for the development, which IDE should be used to open your project, which commands should be used to compile/build your project, and/or how the game can be started in the debugging mode. Besides, if you utilize extra libraries and/or tools in your development, you should also describe those libraries and/or tools and explain how they were used in the developer manual.
c. User manual: In the user manual, you could refer to the game rules for the effect of most regular game operations. Meanwhile, you also need to explain other things that are not covered by the game rules. For example, you need to explain which input commands are supported, what their formats are, how users should input the commands, what happens if an input command is invalid, how to read the game board printed by the game, and how to interpret error messages. Essentially, everything that users need to know to be able to play the game, except for the game rules listed in Appendix B, should be included in the user manual.
d. Video: Given the limited length of the video, you only need to demonstrate the most important features of your game. A feature can be important for the user because it is a basic operation or it greatly influences the user's playing experience, and it can be important for you, as the developer, because, e.g., you are proud of the design behind the feature. You don't need to verbally explain everything in the video since most interactions between the game and its players should be straightforward, but feel free to add narratives and/or texts to the video to describe the things that are less obvious and/or worth extra attention.
e. Deadline: Nov. 18, 2022.
5. A presentation of the group work (4 points)
Each group will also need to present its work before the whole class in the last week of the semester. Details about the requirements for the slides and the organization of the presentations will be announced later.
The presentation slides should be submitted before or on Nov. 21, 2022.
2022-10-21