Meeting Notes
- Presentation!
- Research question
- Background: Intro to old ArchLens
- Related work
- Design constraints
- Implementation: Architecture
- Discussion
- Other prep
- Schedule for thesis + supervision meetings
- Tuesday and friday off (work/thesis)
- Monday: 9.30 - 16
- Wednesday, thursday: 8.30 - 16
- Problem statement (deadline 30/1)
- Since last time:
- Multi view with multiple packages
- Report!
- Architecture diagrams:
- Application looks empty, consider abstraction level
- Hide Utils and Enums, show core models and application classes
- Related work/tools: How much?
- Amount is fine, focus on how they implemented it. Open vs closed source
- Introduction: Add ArchLens, clear connection to the problem we are trying to solve
- Just C#, or language-agnostic? Opt-out or opt-in? Both can work
- Discussion section, what to include?
- Different import dependencies, i.e. imports within method
- Performance and caching
- Future work: Three important sections, short and sweet
- Maybe put conclusion together with future work
- Exam: How long, presentation, room and time?
- SAP will mail us room and time
- 1 hour and 20 min max
- Presentation: Summary of our work in approx. 10-15 min, same structure as report
- We send draft wednesday afternoon, get feedback on friday
- Since last time:
- Multi-view
- Today: Report
- Overview of structure and contents
- Improve Overleaf setup
- Start writing
- Overview of structure and contents
- Thesis write up - confirmed supervisor
- Multi-view, last big feature
- Report so far. Structure and naming
- Introduction: Motivation
- Background: What you need to know
- Related work: How others tried to solve it
- ArchUnit
- pyreverse
- Softwarenaut, FAMIX, multi-language, but not multi-view
- What we do: Keep it simple, multi-language, multi-view, no constraints
- Since last time:
- VSCode extension
- Config stuff and bug fixes
- Early report stuff
- Today: Focus on report
- No meeting with Mircea, we write update email at end of day
- Since last meeting
- Tests and bugfixing
- Aggregated view
- Connecting with VSCode: Using DLL
- More tests
- Report focus considerations
- Report focus:
- Developing on a dead system: Too specific
- Dont worry about theoretical focus, just write what we have been doing
- Any generel lessons learned on extending to c-sharp from python?
- Focus on design/architecture, since that has been our focus during project
- Do the design, document it, be done
- Maintainability, extensibility. Choose one focus. Extensibility is easier to argue for/answer. Maintainability is a bonus, not main idea
- Arguing extensibility in design
- Report structure/format:
- IEEE? Maybe, if we want. No preference
- V-shape, introduction, problem, solution, discussion
- Related work: Yes, but they probably dont focus on design. Try to find few existing tools with architecture/design
- Background: Yes, on Archlens. 2 pages, minimal. Expecting software engineering knowledge of reader
- Different types of dependencies? Could be interesting to discuss
- History of a project with Archlens (for thesis, not now)
- Since last meeting
- Many small fixes
- Aggregating in PlantUML and JSON
- JSON still a WIP
- Bug fixing: DateTime, Normalising paths etc.
- Feature freeze
- Start report next week, but no actual code freeze
- Next week: Longer meeting discussing report structure
- Remember: Report should support future thesis work
- Since last meeting
- Nothing :)
- Finish open issues
- Serializing and cache
- Aggregating dependencies
- Nothing much to say, focus on bug fixing and more coding
- VS code extension works now, which is nice
- Debug: 'python setup.py develop'
- .venv is a bit awkward for C# developers, but for now it is okay
- Goal: Not quantity, but quality and understanding
- We will need more time to code, but don't forget the report
- Since last meeting
- Baseline -> snapshot
- Implement both snapshot managers: Local and Git
- Update DependencyGraph
- Optimize adding of nodes to existing graph
- Add serialization of graph
- Rendering
- Fix Json render bugs
- Testing
- Continue work on change detector and snapshot managers
- Connect with VSCode extension, see if JSON works
- Extension doesn't seem to work at all??
-
Extension: Does not work for us at all
- Does it work for Mircea/original developers?
- Move focus away from it, or spend lots of energy debugging (might not have time)
- Write to original developers (Sebastian and Casper), see if they can figure it out
- Until then, focus on other things
-
Show CLI flow, missing aggregations and multi-view
-
Caching is almost there
-
Make sure to finish nicely, not start too many extra features
-
Start writing report/agree on structure on report
-
Next two-three weeks focus on code, then report
-
Don't focus on maintainability in report
-
Wine recommendation: Stilio Primitivo di Manduria Mottura (Kvickly)
- Since last meeting
- Nothing :)
- Caching, detecting changed files
- Rendering with PlantUML
- MVP done
- No meeting with Mircea, sending status e-mail instead
- Since last meeting:
- Graph to JSON converter: Basic solution exists, not tested
- Skeleton with decided architecture. C# in separate folder to completely separate C# and Python (for now at least)
- Move existing C# code around using new skeleton
- Agree on data structure for dependency graph
- Begin implementing stuff
- C# parsing with Regex
- Setup test project
- Naming of modules etc.
- "Baseline", maybe "LastVersion" or something
- Caching: Two caches, one for last local graph, and for Git master branch(?)
- Comparing to specific commit?
- Caching last render
- Confirm data flow
- Decide on architecture
- Layered architecture with strategy pattern for different inputs (Python and C#) and outputs (PUML, JSON, PNG)
- Continue on C# parsing
- Decide on how to merge Python and C#
- We propose to rewrite all the Python code to C#, since there is a lot of coupling, and it would require close to the same amount of work to refactor the existing code
- Also makes it easier to implement our proposed architecture
- Plus, avoiding having both Python and C# code in one project
- ...and we prefer to write in C#
- Proposed architecture
- CLI vs HTTPS
- C# decision
- Keep Python (maybe for now), make C# version in parallel, considering extensibility
- Next time: Agree on naming
- Focus on creating JSON for VSCode extension, maybe git later
- Problem statement, RQ's, timeline (see Wiki)
- Init work on C# parsing
- Init work on creating/updating architecture of system
- Problem statement draft
- Directions on RQ's
- Previous student reports
- Timeline
- Get to know code base
- Make issues with small code improvements to do
- Write down docs for what each folder/file does
- Setup workflow/boards
- Explore possibility of extending to other languages
- Potentially waiting with testing until thesis
- Probably C#
- Should be doable, but requires some refactoring
- Currently uses Astroid (Python file tree reader)
- Requires
__init__.pyfiles - Reads only files with
.py -
corefolder is used by both views, utils andcli_interface - C# has
SyntaxWalkerwhich could be a good alternative to Astroid
- Additionally, add research for why C#, to make more academic + argue our choice
- Language extension (+ maybe performance, usability improvements)
- How to extend? New ArchLens-C#, or same visualization but different cores
- Wait with empirical testing until thesis
- Empirical testing for Python projects difficult, too specific
- System design
- A case study of extending a single-language static analysis tool for high-level dependency view generation to a multi-lingual tool (ish, Mircea has several formulations)
- Research question: How can we extend...
- Project statement: What is the motivation, what is the problem, what is the plan (1 page max, ready for next monday)
- Next meeting remote
- A Case Study of Extending A Static Analysis Tool for High-Level Dependency View Generation From Single To Multiple Languages
- A Case Study of Extending A Static Analysis Tool for High-Level Dependency View Generation From Single To Multi-Language Support
- Extending A Static Analysis Tool for High-Level Dependency View Generation From Python To Multi-Language Support: A Case Study
Potential abbreviations
- HLDV Tool
- HiLDeViG
- How might we ...
- Challenges and opportunities
- How can we extract the language-independent parts from a project like ArchLens such that we can extend it to other languages?
- How can we extend a Static Analysis Tool for High-Level Dependency Views with support for a second languages?
- meeting weekly or bi-weekly
- how long (30 min ?)
- feedback
- @ meeting
- we present
- new work (+results?)
- challenges
- road blocks
- he provide
- critique
- suggestions
- pointers
- direction
- we will throughout the weeks provide report sections that we would like feedback on
- expectations of report (e.g. no. pages)
- use of AI
we have been thinking:
- usability tests
- testing architectural drift
- (performance, design and bug fixes of archlens before experiments)
- Emperical user experiments
- Lab test (we setup 1 or more repos with specified architecture) [20 - 30 expected participants] to be statistically significant
- Survey - should we send it out on stackoverflow and python forums?
- Analysis of results
- Who is the target user & what is the target project?
- (Python projects are often small and without a specified architecture)
- How much & what should be changed for ArchLens
- Monday afternoon - weekly, 15-15.45
- If nothing new, no meeting
- We will bring what we have worked on, get feedback
- Report: Early feedback, but not too detailed reading
- Start early, mid semester
- Honest feedback, many iterations for some parts (like the actual code)
- Make it clear for Mircea, then most people will get it
- No template, unless we need to send it to someone/somewhere
- Would take longer to make fit for conference, we can decide if something appears
- Need to be concise
- Not Word (lol)
- Overleaf
- AI: Don’t use for intellectual work, use for language stuff
- But we are responsible for everything!
- Code review, as if it was written by human
- Performance - probably in core, not extension
- Look at original thesis
- Initial refactoring
- How is the graph represented, how to update not remake
- Leave code cleaner than we found it
- If coding takes long time, that is whole project
- If more time, then usability testing
- Performance + usability improvement might be enough for RP
- Plan for AB testing or qualitative studies to actually do in thesis
- Qualitative could be enough, definitive improvements might not happen
- RQ:
- Performance, given current version
- Usability issues, given current version
- Testing with performance fixed version, applying feedback to improve usability/usefullness
- Testing on a teams own project, AB testing as backup
-
We are going with the ArchLens project & Mircea as supervisor
-
The project that we are imagining is:
- a small performance refactoring
- other small usability enhancing features for the VS code plugin
-
Emails to other considered supervisors have been sent
-
A meeting on thursday have been setup with Mircea
-
Mircea is now confirmed Supervisor on LearnIT
- An Organisation has been created on Github:
BabLoRP -
ArchLensandArchLens-VsCode-Extensionare forked as repos under theBabLoRPorg -
ArchLensandArchLens-VsCode-Extensionare running locally on both group members primary school computers - The
research-projectrepo has been moved to theBabLoRPorg & the project copied - A
Literatureview has been added to the project to add academic literature issues, for transparent work on who is reading what - ensure no double work
- An unofficial proposed timeline has been scetshed but since RQ are undefined, this is too early to note down (both members have taken an image of the whiteboard)
- Meeting Friday summary
- Specify proposals + document
- follow Lucas chart
- Other potential supervisors
(dependent on others)
- Read Elda proposals
- Prep Mircea meeting
- Open for supervision:
- research on security tools and -frameworks (optionally emperical data collection on how it is used in the industry)
- building foundation for thesis on building a tool our-selves
- no-code, literature review-ish
- not a code analysis expert (which we are okay with)
- She could aid in
- initial litereature
- general guidelines for writing a good project
- what to look for in the code analysis
- potential directions
- literature review ish
- open source analysis
- what is the most utillized coding language in open source girhub repos
- 2-1 frameworks used, -pipeline tools, -implemented security
- Visualization of code base security
- again, not expert
- more code analysis
- could aid in what security to look for in the codebases
- not as hooked as the other project
- awaiting project proposal
- remember to write an email about supervision decision
What is it :
A project that examines the current layout of tools and frameworks developed to analyse code bases security. Next to develop a tool that analyses how much these tools and frameworks are utillised in practice, by scanning open source directories on github.
Description :
- Examine what tools are available
- What security areas do they cover
- What tools are used in practice
- how do they show their findings
- how do the tools analyse the code them-selves
- what formats are the tools implemented in (pipeline, markdown files, code etc.)
- how much are they used in practice (how well - thesis ?)
- static analysis
What is it :
A project that examines the current layout of tools and frameworks developed to analyse code bases security and/or quality. Then develop a tool that a) creates a collective visualisation of analysis results from existing tools and frameworks, or b) creates a tool that visualise our own code base analysis, and/or c) studies the socio-technical aspects, examining how to engage users (how to make more devs use such tools).
Description :
- code base analysis
- different directions
- collect existing tools and create collected visualisation
- how to visualize in an enganing way (socio-technical)
- create own analysis tool
- Examine what tools are available
- What security areas do they cover
- how do they show their findings (vs how should they visualize it)
- static analysis