User:David Thomson

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m
Line 32: Line 32:
 
* Coupling is less: StudentModels don't know about problems, subdomains, or domains, and vica versa.
 
* Coupling is less: StudentModels don't know about problems, subdomains, or domains, and vica versa.
 
* Admin and TutorInterface have the same API as these are used externally to access the system. All others classes will have significant changes.
 
* Admin and TutorInterface have the same API as these are used externally to access the system. All others classes will have significant changes.
 +
* A significant number of methods break the [[Command query separation]] in the current design. In my redesign I will try to follow this principle as closely as possible.
  
 
I think this will prove too loosely coupled, and I imagine I will have to introduce a few more dependencies as I implement the changes. For example, selecting the next problem will involve the Student, StudentModel, Subdomain, Problem, and ProblemSelectionAlgorithm classes in some way.
 
I think this will prove too loosely coupled, and I imagine I will have to introduce a few more dependencies as I implement the changes. For example, selecting the next problem will involve the Student, StudentModel, Subdomain, Problem, and ProblemSelectionAlgorithm classes in some way.
  
 
[[Image:JITAS redesign.png]]
 
[[Image:JITAS redesign.png]]

Revision as of 00:34, 21 August 2008

Davids home page

David.jpg

Contents

Design Study

For my design study I am going to re-design the WETAS base classes (aka JITAS), which we developed in COSC314 in 2007. I think the design is not very good, and in particular has very high coupling between classes. Here is the original UML diagram.

JITAS original.png

The Plan

  • Set up original JITAS project in Eclipse - DONE
  • Ensure all unit tests work as expected - DONE
  • Redesign and Refactor Code
  • Ensure all unit tests (still) work as expected

The existing unit tests should help a lot, and it fits very well into the refactoring process. If the unit tests work after my redesign, I can be sure that I haven't changed the logic - only the design. The Tutor interface should not change (so the tests will still run), but the internal details of the other classes (and the external details of the internal classes) will. The main objective of this refactoring is to decrease the coupling between classes, therefor making extending and maintaining the system theoretically easier.

I am only going to re-design the jitas.core package (ie the UML diagram above), and leave the other packages the way they are. The other packages are quite small and trivial and therefor do not seem like useful candidates for refactoring. Due to this I wont be running the tests on those packages, as I wont change them. They will still be used by my redesigned core package though.

Why I chose this project

I chose this project because I am familiar with it; I was the chief architect for our COSC314 group. Although the above design has some merits, it isn't great, mainly due to time constraints, and the fact that we were learning OO design as we developed the system, not before developing the system. With significantly more OO wisdom, and the benefit of spending a year working on the current system, I think I can come up with a significantly better design. Unit tests already in place make my job easier, and I can focus on good design and not on writing new code. As such I will not attempt to add any new functionality to the system.

Redesign

Here is a UML diagram showing an attempt to redesign JITAS. (not sure if my UML is correct...) Some notes:

  • Subdomain has a Factory method to make the correct Feedback Object
  • Subdomain uses a Strategy design pattern for the ProblemSelectionAlgorithm
  • DomainManager and StudentModelManager have been removed - they didn't sound like very good OO classes.
  • Some relationships now make more sense eg StudentModel is part of Student, Problems are part of Subdomains etc.
  • Coupling is less: StudentModels don't know about problems, subdomains, or domains, and vica versa.
  • Admin and TutorInterface have the same API as these are used externally to access the system. All others classes will have significant changes.
  • A significant number of methods break the Command query separation in the current design. In my redesign I will try to follow this principle as closely as possible.

I think this will prove too loosely coupled, and I imagine I will have to introduce a few more dependencies as I implement the changes. For example, selecting the next problem will involve the Student, StudentModel, Subdomain, Problem, and ProblemSelectionAlgorithm classes in some way.

JITAS redesign.png

Personal tools