FW: [squeak-dev] Re: [ANN] PathView (was Re: [ANN] The Path Tools Framework)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

FW: [squeak-dev] Re: [ANN] PathView (was Re: [ANN] The Path Tools Framework)

Edgar De Cleene
Creo que German habia mandado aqui algo sobre esto, pero lo que abunda no
daña y lo re envio.

Parece una herramienta interesante.

Edgar

------ Forwarded Message

> From: Michael Perscheid <[hidden email]>
> Reply-To: The general-purpose Squeak developers list
> <[hidden email]>
> Date: Tue, 18 Mar 2014 13:17:08 +0100
> To: <[hidden email]>
> Subject: [squeak-dev] Re: [ANN] PathView (was Re: [ANN] The Path Tools
> Framework)
>
> Hi all,
>
> 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.
>
> More documentation can be found here:
> *
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/pa
> th%3ApathView
> *
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/pa
> th%3Atutorial%3AmodelbasedEditor
>
> Best regards,
> Michael
>
> On 11.03.2014, at 11:39, Michael Perscheid <[hidden email]>
> wrote:
>
>> 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/pa
>> th%3ApathFinder
>> http://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/pa
>> th%3Atutorial%3Abackintime
>> http://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/pa
>> th%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/wik
>>>>> i/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
> [hidden email]
>
> http://www.michaelperscheid.de/
>
>

------ End of Forwarded Message