Στο πλαίσιο της διοργάνωσης των σεμιναρίων του τμήματος, θα πραγματοποιηθεί την Παρασκευή 04/03/2016 και ώρα 12:00 στην αίθουσα Σεμιναρίων του Τμήματος Μηχανικών Η/Υ και Πληροφορικής, ομιλία με τίτλο "Navigating through the Archipelago of Refactorings". Ομιλητής θα είναι ο κ. Ζάρρας Απόστολος, Επίκουρος Καθηγητής του Τμήματος Μηχανικών Η/Υ & Πληροφορικής, Πανεπιστημίου Ιωαννίνων.ΠΕΡΙΛΗΨΗ
Refactoring is the process of changing the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. The essence of refactoring is to improve software quality via the systematic combination of primitive refactorings. To this end, Martin Fowler (with contributions by Beck, Brand, Opdyke and Roberts) introduced a well known catalog of 68 refactorings. Yet, there are way too many refactorings. Choosing which refactorings to use, how to combine them and how to integrate them in more complex evolution tasks is hard. To address the complexity of the refactorings space, Fowler already grouped the 68 refactorings in six groups. Even so, exactly due to the inherent interconnection of these refactorings, the space of options before, during and after a refactoring is still large. Specifically, in Fowler s catalog, the documentation of each refactoring includes discussions that reflect relations with other refactorings. The "hidden" relations, refer to refactorings that could be performed before, or after the target refactoring. The "hidden" relations also concern alternative refactorings that could be performed instead of the target refactoring, or constituent refactorings that can be used to realize the target refactoring.
Our vision is to provide the developer with a "trip advisor" for the archipelago of refactorings. The core idea of our approach is the map of the archipelago of refactorings, which identifies the basic relations that guide the systematic and effective combination of refactorings. Based on the map, the trip advisor makes suggestions that allow the developer to decide how to start, assess the possible alternatives, have a clear picture of what has to be done before, during and after the refactorings and assess the possible implications.