jordanraphael / l1-software-data-evolution Goto Github PK

REMEMBER:
() work on a COPY of the src
() at this stage, we refactor to UNDERSTAND, and NOT to improve
() don't get fond of the refactored src; by default it's a throw-away, be ready to sacrifice
() cannot really refactor without tests =>
(*) hand in hand with Write Tests to Understand (next lecture

DL for joint deliverable 1 & 2: april 10 (via email)

DLV#2 gives a list of architecture, design and src style problems.
(a) @ architecture level (i.e., if there are problems at the package level -- e.g., in your case there is a lack of a back-end "server" package that hosts the business logic)
(b) @ design level (problems detected by inspecting classes @ the class diagram level, e.g., God Classes, long methods, ... -- in your case, God Gui class is an example)
(c) @ code and style level (e.g., style violations, spagetti code, code clones, ...),
(d) a preliminary plan of actions towards re-engineering the legacy code (expected to be detailed in DLV #3).

1. Test for constructTree() method.

Fundamentally, what a back-end server class needs is
(a) to export the functionality of these use cases via a public API
(b) to hold the state of the system (probably via an auxilliary class -- could be (a variant of) the dataHolder)
(c) [probably] to persistenly write the state of the system, s.t., we can apply tests, whenever a new call is made to the back-end server

How to proceed:

• start off-loading work from the GUI class to the back-end server, one use case at a time.
  As you do this, define the API between front-end and back-end with a new call for the use case that we investigate
• use the dataHolder as the state holder class, s.t., GUI can work without crashing
• refactor API and implementation as much as needed, as you proceed with new use cases
• [IF TIME] once done, consider breaking the God Class, or transforming it to a Facade...

The most fundamental use cases are: load project, show PLD, (re)cluster time/tables, zoom-in cluster (of time/tables).
Furthermore, you have use cases like: new project, zoom-out, ...
To test the use cases in a black-box manner, you need to know the state of the system = [at least]

• basic PLD
• current set of clusters for tables and phases
• current zoomed out subset of the PLD
• several TableModels ...
• ...

• Email with the git's URL, all code, data, explanations there + a report in PDF

• How architecture was before and how it is now

• Steps we followed to refactor the code.

• All the work we ve done to improve the code quality.

• Class diagrams package diagrams.

• Small description for each new class we introduced.

• Just the report; if you want to do a presentation / video / ... it is not boligatory

• Refactoring patterns used.

Avoid:
o.getSubPart100().getSubpart12().getsubpart17().doSth();

Do: make class subPart100 to export a facade method

• dosthWithSupart12And17();

s.t. the clients DO NOT depent on
(a) subPart100
(b) subPart12
(c) subPart17
(d) result of doSth()

/* iteratively, the subPart classes can do also a facade method for the work of their components */

Demeter: a class should depend only on its attributes + IMMEDIATE collaborators

In both examples, we have moved the business logic from the client(s) to the data class, which starts to acquire responsibilities. =>

• we have much simpler clients, /*understanbale, evolvable */
• we do not have dupicate code,
• we are reducing the essential coupling of classes (clients use only a small part of the public API of the service provider)
  =>
  we can evolve with more ease and we can test better

CAUTION: When you move methods from the client classes to the Data Container, you will need to introduce parameters to make the moved method to work

Data is plain old data (output of a parser, data from a database, ...)
See also
https://blogs.oracle.com/javamagazine/records-come-to-java
https://projectlombok.org/features/Data

Contract = what a class/subclass promises to deliver to its clients
=> Assuming you observe a class, detect which classes call which method of the class and how
Involves:
(a) doStuff methods of the public API of the class
(b) constructor calls (remember: doStuff() and new() are 2 different kinds of things + mind the patterns)
(c) how children classes are affected if mama changes (methods overriden from sub-classes, super calls)
(d) ...

@EnD:
() first understanding of boundaries of subsystems
() first understanding of how classes are used => what will break if you blindly refactor server classes

We need a set of slides which will contain the following:

1. One slide with the list of tests we have implemented
2. One or two slides with important class diagrams
3. One or two slides to describe how functionality is taken from the Gui and why the Gui is loosing logic.
   (Bonus) Patterns used for refactoring.

TESTING MATERIAL

My slides for testing at the ugrad course
http://www.cs.uoi.gr/~pvassil/courses/sw_dev/notes/07-Testing.pptx
and generally, with material: http://www.cs.uoi.gr/~pvassil/courses/sw_dev/readings.html

Eclise tutorial got junit
http://www.vogella.com/tutorials/JUnit/article.html

The goal is NOT to test everything!
The goal is to cover the most important points of risk in your code!
We organize our test suite to be expanded incrementally, in a way that it is easy to expand the test suite one-test-at-a-time & run the tests fast!

DO NOT LET THE FACT THAT YOU CANNOT TEST EVERYTHING INTIMIDATE YOU FROM COVERING AS MANY REQUIREMENT VIOLATONS AS POSSIBLE!!!!

List of issues observed:

1. On the right side Plutarch Parallel Lives Label does not appear
2. Help button does not appear next to Project button at main toolbar.
3. When we click on a column it selects the +5 column to the right.
4. We collect all listeners regarding GeneralTable to the class GeneralTableHandler
   and the listeners belonging to ZoomTable to the class ZoomTableHandler

1. Renamed the BuisnessLogic class to GuiController and updated all its references.

2. Broke the cycles at the package diagram level between the DataKeeper and TableConstruction packages.

3. Split DataKeeper to 6 classes, 4 classes that stores data, 1 class that handles the processing of the data and 1 GlobalDataManager.

4. Removed cycles at Gui class diagram level.

Next Steps:

• Trace back call hierarchy and populate classes with logic methods at datakeeper because now they are simply Data Containers.
• If time, create interface at DataKeeper and Factory so that clients use interface( good bonus).

Deliverable 3: For 28/4 try to have tests and a 1st refactoring of a simple use case (eg Load Project); if time, incrementally add tests and refactorings for other use cases.
Report list of test cases and refactorings in terms of UML diagrams (before/after change).

28/4 [Pvassil]
Try sth like 1st refactoring of "LOAD project" + its tests(not everything);
[if time] incrementally add use cases + tests;
Report list of tests; {before, after} pairs at the design level

### a) Architecture Level
-- There is a lack of back-end "server" package that hosts the business logic and as a result the (1) package has dependencies to all other packages which the GUI depends on and increases the coupling. The back-end "server" package would play the role of an intermediary between the DataKeeper and the GUI populated with "load" methods, which are currently in the GUI package.

-- In the GUI there are methods that do some useful processing on data and we need to move the logic to the DataKeeper i.e. "Move behavior close to data" pattern. This will result in converting the Data class to something like a "service provider". The DataKeeper will become a "God" class that way. So as a next step we will divide that class into smaller subsystems that deligates work to other classes "Facade" pattern.

Packages where problematic behavior has been observed.
(1) gui.MainEngine
(2) tablelustering.clusterExtractor.common
(3) data.dataPPL.pplSQLSChema
(4) data.dataKeeper

### b) Design Level
-- Problems detected by inspecting at the class diagram level.

(1) Data package: GlobalDataKeeper and Worker classes have too many responsibilities and act like "God" classes and contain also methods with similar behavior

(2)Gui package: Gui class acts as a "God" class, it has many dependencies inside the Gui package and also outside of it, contains very long methods and contains too many attributes.
PldConstruction classs "JORDAN YOU NEED TO SEE AGAIN" this one

(3)Phase package: The Phase class except for being a data holder does also some processing on the data so maybe it has too many responsibilities.

(4)TableClustering package: The Cluster class may have too many responsibilities because it does also some processing on the data, and ClusterInfoKeeper has the same issue and the proceesing related methods need to be moved to some other class.

### c) Code & Style Level
(1) CheckStyle Pie
(2) CheckStyleViolation Summary

### d) Preliminary plan of actions towards re-engineering the legacy code.

1. Develop tests for the existing systems.
2. Add a Business logic package intermediary to the GUI and the Data packages.
3. Move methods that process data to the DataKeeper.
4. Divide the DataKeeper into smaller subsystems that handle the logic.
5. Apply general refactoring patterns on the code e.g. extract methods, duplicate code, clean dead code, spaghetti code...
6. If needed, add more tests to verify the functionality of the final system.

In 15 days, we spend sth like 15'-20' per team, where each team presents the current state of affairs, what has been done, tests, ... src architecture, etc publicly for (a) prof's to comment and (b) everyone else as food for thought. TUE 12/05.

1. Rename BusinessLogic class e.g. GuiController
2. Break the cycle in the package or/and class diagram generated last time.
3. Split up the DataKeeper class or/and package.

Next steps:

1. Fix existing bugs and finish Factory class. (edimoulis)
   i. Some right clicks on table squares throw exceptions.
   ii. Implement the interface at ZoomTableHandler

2. Develop more tests regarding the Data package.
   The Use Cases we want to test are:
   i. Show PLD --> showGeneralLifetimeIDUAction
   ii. Show Phases PLD --> showGeneralLifetimePhasesPLDAction
   iii. Show Phases with Clusters PLD --> showGeneralLifetimePhasesWithClustersPLDAction
   iv. Show Full Detailed LifeTime Table --> showLifetimeTableAction

3. Move logic related from data processing to the DataKeeper.
   i. Moved InfoAction() from BusinessLogic to GlobalDataKeeper
   ii. Moves Gui.elements.tableConstructors moved to data hyper-packagae as data.tableConstructors
   iii. Moved data population methods from BusinessLogic to Datakeeper

Tips For refactoring the GlobalDataKeeper see:

1. PPLSchemaManager
2. PPLTransitionManager
3. DataKeeper has about only get and set methods but the clients of this class have similar methods that are almost duplicate.

Note In the next report we need to mention that we moved an entire package, the gui.treeElements, to the "Data" hyper-package naming it to data.treeElements.

• Last presentation before the final deliverable where final comments about changes and possible developments will be discussed.

• The last deadline will probably be at 14/06.

• Possible Refactoring:

1. Rename BusinessLogic to something like e.g., GuiController [done]
2. Break the cycles at the class diagram or package diagram
3. Split up DataKeeper into subsystems
   i) TableManager
   ii) ClusterManager
   iii) ProjectManager