last but not least, I’d like to present “PathView” as a single-source, round-trip engineering, and model-based code editor. It presents UML-like views of classes, methods, and their relationships that are always an up-to-date view on the source code. Each editing in model or source code will change the other representation automatically in background. For that reason, it does not matter if developers favorite code or models for programming.
Our PathView allows developers to create editable mid-level abstractions of a system under observation in form of UML-like diagrams. It ensures a synchronization mechanism between the created abstraction and the underlying source code. As soon as something changes, other entities are also updated immediately. Developers create such diagrams in an interactive and semi-automatic manner. Starting from a static (selected classes in source code) or dynamic (test cases that cover methods of specific concerns) perspective, they refine their views of classes and methods step by step. In doing so, static analysis techniques and our Type Harvester provide the necessary information for generating and syncing these diagrams automatically. Finally, these diagrams are helpful in many software engineering and maintenance activities. They provide an always up-to-date documentation in form of class diagrams; they help in program comprehension by selecting and presenting methods and classes for a specific concern at once; they allow developers to discuss about architectural decisions; and they have been shown very useful in our lectures when students have to present an overview of their implemented systems. Besides these read-only use-cases, our PathView also allows the development and refactoring of entire systems in such diagrams.
> Hi all,
>
> the next tool of our Path tools framework is “PathFinder” a lightweight back-in-time debugger for (reproducible) test cases. Compared to PathMap where we analyzed multiple test cases at once, PathFinder allows developers to focus on one specific test case and to explore its details.
>
> A test case executes one specific path through the system which can be recorded with all its behavior and state to understand the complete execution history. However, traditional approaches for analyzing a program’s run-time are time-consuming and expensive. They capture comprehensive information about the entire execution up-front, which is in large parts not required at all. We solve this problem with the reproducible and deterministic properties of test cases. We assume that a test case always takes the same path through the system so that each execution comprises the same behavior and state information. With this insight, we are able to split the expensive analysis of a program’s run-time over multiple test runs. Based on developers’ decisions, we divide the analysis into multiple steps: A high-level analysis followed by on-demand refinements. Thus, we incrementally collect only the data developers are interested in and so reduce the analysis overhead to a minimum while preserving instantaneous access to detailed execution histories.
>
> Based on this analysis technique, PathFinder implements a lightweight back-in-time debugger for introspecting specific test case executions that supports the characteristics of immediacy. Moreover, this tool reuses PathMap's anomalies in order to classify traces with suspicious behavior and state. So, developers can follow infection chains back to their root causes without much effort.
>
> More documentation can be found here:
>
http://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/path%3ApathFinder>
http://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/path%3Atutorial%3Abackintime>
http://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/path%3Atutorial%3Atdfn>
> Best regards,
> Michael
>
>> On 03.03.2014, at 10:30, Michael Perscheid <
[hidden email]> wrote:
>>
>>> Hi all,
>>>
>>> as promised, I’d like to further present parts of our Path tools framework. In this mail, I introduce the "PathMap test runner".
>>>
>>> Test cases possess a valuable source of information as they implicitly define expected and unexpected behavior all over the system. During the execution of their exemplary assertions, they do not merely cover directly-tested methods but rather large call sequences with corresponding states through internal parts of the system. Based on this idea, we can inductively derive from the specific run-time values of executed test cases more generalized and helpful program properties. By making this hidden test knowledge available, developers have additional information for debugging, testing, and understanding their programs.
>>>
>>> PathMap is our extended test runner that reveals the hidden knowledge of test cases and presents it to developers. It provides a low overhead analysis framework that computes coverage data, likely invariants, and static metrics and displays the results in form of a scalable tree map visualization representing the system under observation.
>>>
>>> <pathMap.png>
>>>
>>> To start a specific analysis of your system under test, select your tests, choose a flap from the right side (large icons, description see below), and press the button “run selected”.
>>>
>>> PathMap Analyses Modes (Flaps from top to bottom):
>>>
>>> * The test quality flap analyzes the (method) coverage of test cases (effectivity) and relates it to different static metrics. This allows developers to answer questions such as which methods require more tests and which author is responsible for missing tests.
>>>
>>> * The profiling flap measures the run-time characteristics of test cases (efficiency) and their relation to the methods of the system under observations. Performance bottlenecks, memory leaks, and massively called methods can be revealed with this analysis.
>>>
>>> * The fault localization flap reveals spectrum-based anomalies (methods) that have a high probability to include failure causes. By comparing the coverage of all failed and passed test cases, we offer several starting points for debugging failing test cases and creating initial failure cause hypotheses.
>>>
>>> * The induction flap derives likely invariants from passing test cases. We expect that every state (parameter, receiver, return value) of a passing test is also a valid data point. Based on this assumption, we generalize concrete run-time values all over the system into assertions. Such likely invariants can help in program comprehension as well as debugging if they are compared to failing test cases. (Analysis can take some time)
>>>
>>> * The traceability flap connects arbitrary concerns and software artifacts with test cases in order to analyze their relationship with the code base. For example, requirements can be related to their acceptance tests and we compute methods that overlap or are completely specific to requirements.
>>>
>>> More documentation can be found here:
>>>
http://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/path%3ApathMap>>>
http://www.michaelperscheid.de/projects/index.html>>>
>>> Best regards,
>>> Michael
>>>
>>> On 22.02.2014, at 18:19, Michael Perscheid <
[hidden email]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I’m pleased to announce the release of our Path Tools Framework that has been developed
>>>> during the last five years as part of my dissertation.
>>>>
>>>>
https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/pathToolsFramework>>>>
>>>> The Path Tools Framework comprises several development tools for supporting typical software
>>>> maintenance tasks such as debugging, testing, and program comprehension. It realizes among
>>>> others our test-driven fault navigation (a systematic debugging approach that leads developers
>>>> from the observable failure back to root causes), test quality feedback (improve software quality
>>>> by analyzing test cases), and model-based source code editing (single source development
>>>> method that joins model-driven development and standard source code editing).
>>>>
>>>> As there are several tools and use cases, we will provide more detailed information in following
>>>> announcements. Nevertheless, all tools are already available and can be tested. Furthermore,
>>>> there is also a bunch of documentation, screencasts, and published papers.
>>>>
>>>>
http://www.michaelperscheid.de/projects/index.html>>>>
>>>> Have fun :-)
>>>>
>>>> Best regards,
>>>> Michael
>>>>
>>>> ---
>>>> Dr.-Ing. Michael Perscheid
>>>>
[hidden email]
>>>>
>>>>
http://www.michaelperscheid.de/>>>>
>>>
>>> ---
>>> Dr.-Ing. Michael Perscheid
>>>
[hidden email]
>>>
>>>
http://www.michaelperscheid.de/>>>
>>
>> ---
>> Dr.-Ing. Michael Perscheid
>>
[hidden email]
>>
>>
http://www.michaelperscheid.de/>>
>
> ---
> Dr.-Ing. Michael Perscheid
>
[hidden email]
>
>
http://www.michaelperscheid.de/>
Dr.-Ing. Michael Perscheid
Locked
