Feedback to Strategy/Builder/Composite proposals

• Basic|Optional|PeriodicAnalysis: Many teams tried to introduce them as sub-classes of an Analysis class. It could make sense if these sub-types have fixed metrics, e.g., the basic analysis consists of the number of lines of code, while periodic analysis always includes the function point metric. But it's not true. The system description clearly states, for instance, that "Analyses marked as basic for a given project...". It means that they can differ across projects. The difference between basic, periodic, and optional analysis is only in their usage (role played by the Analysis class in the Project association).

A common assignment for all teams

• A Project has a ProjectStructure, which consists of directories, configuration files, source files, header files (for C/C++), and other files/directories. The project structure is always a tree => we want to decompose it using the Composite pattern.
• The quality of the project is measured by applying a set of code quality metrics (and issues, which are understood as special metrics). Therefore, we introduce a QosAnalyzer class, which links metrics/issues that will be measured during the analysis of the project's structure. We want to achieve the following features by applying  the Builder pattern:
  • The QosAnalyzer object is constructed on demand, typically just before the QoS analysis.
  • The metrics/issues used for the analysis of a project are read from JSON files due to flexibility and the possibility of defining them externally. The support for XML or other formats will be implemented later.
• The QosAnalyzer will be responsible for conducting QoS analysis on a single source file from the ProjectStructure. Results are collected in the AnalysisResults object. 
• The Project class 
• We can conduct three types of QoS analysis: basic, optional, and periodic. They differ only in how or by whom they are used. Moreover, additional types could be introduced in the future. Therefore, we want to associate QosAnalyzer with the Project dynamically. The linked QosAnalyzer can be considered a strategy for code quality measurement at a given time, regardless of whether it is part of a basic, optional, periodic, or another analysis. Therefore, we aim to spread the responsibility of analyzing a signal source file between the Project and QosAnalyzer classes using the Strategy pattern.
• The traversal of the project structure, the quality evaluation of individual source files, and the generation of the AnalysisResults are driven by the Project, which has to cooperate with the ProjectStructure (decomposed by the Composite pattern) and the QosAnalyzer. You may or may not use an auto-propagating method for the project tree traversal.

Required output

• Draw and submit a class diagram (one per team) using the patterns. Use/update your existing class diagram (do not create a new one).
• The model will be at the necessary level of detail (methods, attributes, etc.)
• Assign stereotypes to classes reflecting their roles in used patterns: <<composite>>, <<leaf>>, <<strategy-context>>, etc.
• Submit results to the "09 - Design patterns modelling".