Proj FuzzViz Paper Reading: Codoc: Codedriven Architectural View Specification Framework for Python

Abstract

目的: continuous architectural documentation system，连续的架构文档系统
方法: code-driven architectual view specification to create views，代码驱动的架构视图规范语言

PDF

https://pure.itu.dk/portal/files/86386665/21_CoDoc_VISSOFT.pdf

1. Intro

Osterweil [6] proposed that software development can be represented by software processes. He argued that software practitioners are used to define processes as code, and that the development of software, and the related practices, should be possible to represent as code too.

方法：code-driven code visualization too for Python
效果：能在架构view(arichitectual view)中指定看哪部分，用户接下来就能测试

2. Related Work

主要聚焦于code-driven可视化(尤其是Architecture Description Languages(ADLs))而非交互式可视化

1. Glamorous Toolkit-Smalltalk
2. ArchJava-Java
3. intensional view-metaprogramming + logic programming to check 某条规则是否被遵守
4. pydeps-python

3. Solution

编写并发布View文件

4. Evaluation

对四个不同的参与者进行了四个用户测试。四个测试至少相隔一周，以尽量减少由于实施细节或错误导致负面反馈的可能性，但也意味着系统在测试之间演变。访谈是通过 Zoom 进行的，以观察屏幕和参与者，并与来自不同国家的参与者进行标准化评估。所有的采访都被记录下来并在之后进行评估。在每次采访开始时，采访者都会解释 Codoc 旨在解决的核心问题，并解释说会记录会议。在参与者口头接受后，参与者将分享他们的屏幕。面试官向 codoc.org 提供了登录信息、API 密钥以及相关用户文档的链接。用户测试的时间限制为大约一小时。测试结束后，参与者被要求回答 V-B 部分中详述的一系列问题。我们使用答案以及大声思考协议来深入了解通过代码驱动接口指定架构视图时的好处、缺点和挑战。

5.

introductory view可能很大，但是提供过多不必要细节
交互、完整的dependency抽取、响应时间不能太慢、
Follow up Questions:

1. Can you express the needed views in the existing framework?
2. Which tasks & activities that you do in your daily job, do you imagine that Codoc could help with and how?
3. Would you use a tool like this?