共计 5266 个字符，预计需要花费 14 分钟才能阅读完成。
COMP5911M Advanced Software Engineering
Coursework 2
These tasks are concerned with computing software metrics. There are a total of 40 marks available. This
coursework is worth 15% of your overall grade.
Preparation
Task 1 of assignment uses the Car Rental example from the lectures and exercises. You will need to analyze
the initial, unrefactored version of the code, as provided for Exercise 2. You will then do the same analysis
for the code after you have applied all of the refactorings from Exercise 4.
Hence it is important that you complete Exercise 4 before attempting this assignment!
Tasks
Task 1 (24 marks)
- Compute the following metrics for the original, unrefactored version of the Car Rental code (i.e., the
code provided as part of Exercise 2):
Number of classes in the package
Total SLOC (Source Lines of Code) in the package
Average number of methods per class (computed across all classes in package)
Average & maximum method complexity for Car, Rental and Customer separately
Instability for Car, Rental and Customer separately
Abstractness of the package
A total of 10 marks are available for these calculations. - Compute the same metrics for the Car Rental code after the refactoring of Exercise 4 has been
completed. Again, these calculations are worth 10 marks. - Compare the values of the metrics before and after refactoring. Relate this to what has been achieved
by the refactoring. Do the metrics tell us anything useful about how the software has changed? Are
they misleading in any way? [4 marks]
PLEASE NOTE:
Unless otherwise stated, metrics should be computed by hand, not using a tool. If you actually have
to calculate anything, rather than simply counting, make sure that you show your working, as there
are marks awarded for this as well as the final result.
SLOC is defined as the number of non-blank, non-comment lines. You can compute this manually or
using a tool such as David Wheeler’s sloccount (https://dwheeler.com/sloccount/)
Use McConnell’s simplified approach to compute complexity.
Do not include unit testing code in your calculations.
Do not use more than two decimal places when quoting non-integer results.
If the metrics you compute for the refactored code differ from our values, you’ll still receive the marks
provided it is clear that you’ve done the calculation correctly for your code. For us to check this, we
will need to see your refactored code in your repository on gitlab.com.
If we are unable to check your calculation of a metric because the code isn’t visible in GitLab,
you won’t get any marks for that calculation.
1
Task 2 (16 marks)
Develop a software tool that can calculate one of the following metrics:
SLOC (source lines of code) for each individual class in a given package1, and a total for all classes
in that package [6 marks]
Average & maximum McConnell complexity for each class in a given package [10 marks]
Abstractness and instability for a given package of classes, within a collection of packages making up
a larger software application [16 marks]
You can develop your tool in any sensible modern programming language. If you are unsure whether your
choice would be suitable, please speak to Nick. Development should be managed in your GitLab repository,
under a directory named cwk2.
Your tool can analyze code written in any sensible modern programming language. Note: this does not need
to be the same as the language used to implement the tool! For example, you could write a tool in Python
that analyzes code written in Java if you wanted . . .
Your submission should include a README file giving instructions on how to compile and run your tool.
We would prefer it if these tasks can be carried out via the command line. We will attempt to follow your
instructions when we mark your work.
If, for some reason, it is not practical for us to do this, we may require you to submit a short video
showing the tool being compiled and executed, so please be ready to produce such a video if asked.
A maximum of 16 marks are available for this task. The mark awarded will depend on the level of challenge
posed by the chosen metric (see above), the sophistication of the approach you have used, the quality of your
implementation, and evidence provided of a development process (via commits in your repository).
Think carefully about an approach that would be effective in solving the problem. You might find that
regular expressions are a useful tool. Most modern languages provide good support for using them.
More sophisticated approaches might make use of the reflection capabilities of your chosen implementation
language. Java, for example, has a powerful reflection API allowing a Java program to analyze the
characteristics of other Java code. C# and Python have similar capabilities.
Another possibility, if you are feeling ambitious enough, would be to use a dedicated parser for the language
that your tool analyzes. If following this approach, note that you would definitely NOT be expected to
implement such a parser from scratch; instead, we would expect to see you using a parser generator tool
such as ANTLR to produce the parser code.
If you have questions about any of this, please ask them in Microsoft Teams. (Use the Coursework channel
of the‘COMP5911M Adv Software Engineering’Team.)
Submitting Your Work
Use Gradescope to answer the questions for Task 1. You can access the relevant Gradescope assignment via
the Gradescope Dashboard link in the Submit My Work folder in Minerva.
For Task 2, we expect to see code in your GitLab respository, with a history of commits providing evidence
that you have developed the code yourself. Please make sure that all of your commits have been pushed to
gitlab.com by the submission deadline.
Your code for Task 2 should also be provided in a Zip archive named cwk2.zip, which you should submit
via the link provided for this purpose in Minerva.
Note: we will penalise you if you don’t provide your code via both of these methods.
The deadline for submission is 10.00 on 2 December 2021. Late submissions will suffer the standard
university penalty of 5% of the available marks per day unless an extension is approved by the SSO due to
mitigating circumstances.
1We use package in the same sense as Java package here. You might also see this described as a‘module’or a‘namespace’.
正文完
