SE450:G10

Hello we're group 10 and we are evaluating Vitabal

Evaluation Approach

Chosen to use the cognitive dimensions framework, since we don't have access to a working system. Hence we will simply compare how well Vitabal copes in each of the dimensions specified within the cognitive dimensions framework, via a group discussion

Evaluation Dimensions

• Abstraction Gradient:

Vitabal abstracts method calls by encapsulating them into Toolies. Toolies make up fragments of the entire program/system. Data structures are maintained as ADS's which can be shared by many toolies. Program flow done by using event propagation to activate toolies/ads's.

• Closeness of mapping:

DONT KNOW WHAT TO DO HERE!!

• Consistency:

Once the concept of using Toolies to access ADS 's is clear, have to also get used to the types of listeners/event types used to control program flow, since there are 4 different types of events which can be propagated. Also need to ensure and understand that event types have to be manually specified by the developer so as the correct event types are serviced by the each toolies/ADS's port. This is done via its interface. Toolies are also re-usable, hence allowing consistent implementation of program fragments throughout the system.

• Diffuseness:

Apart from the symbols used for toolies/ ADS's etc event names, methods and arguments are shown along the edges. There are other symbols for specifying different event types(listen-before, after, request etc), concurrency. Compared to languages like Prograph, and Fabrick (see paper pg 55) which only rely on data flow, Vitabal provides a more robust representation of event and data flow, which allows one to quickly infer the program-flow and events .(TO DO: CHECK THIS-->) The symbol set used is relatively manageable so that means Vitabal has a 'high' diffuseness

• Error-Proneness

Before compile time, Vitabal performs consistency checks to see if events being propagated to various ports are intended (specified in the interfaces). Also by automatically generating snart code, VItabal helps take care of concurrency issues etc which would be quite difficult and prone to error if done manually by the programmer. By sharing information between the textual event response views and visual event propagation views, most changes made are reflected in every other place. Those changes which cannot (such as change made to event response specifications -- pg 57) are represented as change descriptions which are basically the equivalent of a "TO DO". Also toolies can be reused reducing the risk of having to repeat code and modify it every time a change is made

• Hard mental Operations:

Vitabal is quite efficient in terms of speedy development, due to the various graphical views provided which allow developers to directly specify functionality and program flow. Since this is always part of the development environment, it can also serve as a reference by keeping multiple views open. method Names, method arguments and event types being represented on the graph edges also reduce the mental load to keep track of whats being passed where. Also allows profiling of the compiled system during runtime, so programmer can easily debug it(look at ch 6).

• Hidden dependencies:

Good symbolic representations of program fragments, data and event flow. Nothing really hidden, except having to explicitly open up, views for editing/viewing event response code.

• Premature Commitment:

Developers can start specifying toolies and other program fragments without having to do any initial setup. Again the visual editors allow programmers to readily specify their intentions regarding program structure, flow etc.

• Progressive evaluation:

Partially complete programs can be compiled. Toolies are not dependent on each other. Also snooping event types allow toolies to be made pluggable. The views also allow toolie hierarchy to be represented reducing complexity. Again the visual profiler and spy points placed on toolies facilitate easy debugging.

• Role-expressiveness:

Yes,again done by the views, but again event propagation responses require code walk-through (since they are textual)

• Secondary Notation:

Programmers are restricted to using the current graphical symbol set provided, and are not allowed to essentially create their own. Hence have to rely on naming, event propagations, program flow, method calls etc to try and differentiate other toolies, program fragments etc

• Viscosity:

Small changes to make are easy to do implying low viscosity, but major changes to a system (especially when its very complex) would be hard, since Vitabal relies on event flow, hence would be a lot of changes to be made by developer within the views (although support provided by information sharing) such as shifting event propagations, port interface code change etc. This may suggest Vitabal offering a high viscosity with regards to major changes made

• Visibility:

Good visibility, since can allow multiple views to be open simultaneously. Also most views such as evetn propagation, debugging, profiling are graphical hence this provides a good outlook on the system. Can also organize toolie hierarchy to be visbile, which is vital when the code is dispersed

Presentation Link

https://www.se.auckland.ac.nz/research/projects/softeng401.2007/124/Group10_VitabalPresentation.ppt