SE450:G9
PRESENTATION SLIDES
Download here: http://studwww.cs.auckland.ac.nz/~ezur001/SOFTENG_450.ppt -Danushka and Eddie
Objectives
- To review and evaluate an article on Domain Specific Visual Language (DSVL)
- Our article can be found at https://www.se.auckland.ac.nz/courses/SOFTENG450/resources/vlpapers/OCONVL99.pdf (password protected)
Members
- Milenovic, Ivan (imil018)
- Abeysuriya, Danushka (dabe012)
- Halytskyy, Yuriy (yhal003)
- Clark, Kevin Alan (kcla048)
- Long, Ratha (rlon008)
- Zurita, Edmund (ezur001)
- Meads, Andrew (amea020)
Evaluation
Closeness of mapping
Metaphors are familiar to OOP designers (contract-based, polymorphic type systems). Petri nets formalism is used for concurency modeling and may be familiar to those working on distributed systems. At least has wikipedia page :). PN seem to have strong math. foundations but whether it is necessary to know is unclear. Conclusion - good.
Abstraction gradient
Consistency
Difusiness
Allowes modeling at different abstraction levels (from contracts to resource sceduling). So different level of verbosity possible. Separation of functional requirements from distributed behaviour - diagrams are relatively small with only necessary details. Entities can be expanded/hidden. Conclusion - terse but users may give more details if needed making diagrams larger (more verbose). So I gues - good.
Error proneness
Hard mental operations
Hidden dependencies
That is what VDSL is all about - figuring dependancies and resolving them automaticlly. So shouldn't be big problem ifOCoN is of any use.
'Contracts' define the behaviour between components (or entities) of the DSVL. The dependency among different components are made visible through such contracts - hence good :).
Premature commitment
Progressive Evaluation
Possible to run simulations of scenarios. Type checking on the fly (?). Not clear if there is progressive validation. Conclusion - average
Role expressiveness
Secondary notation
Viscosity
Modular - may be easy to replace contracts. Polymorphic type system seems to help. Diagrams similar to state machines so can become large. Rearanging elements may be time-consuming.
Visibility
Cognitive Dimension
more blah
Pros
- Concurrency did not have a visual model before this
- Concept is easy for Object Oriented Programmers to understand because of the use a polymorphic-type system
- A good separation of concerns (the protocol net
- Well known formalism for modelling concurrency
- Good metaphor for the procedural calls
- Consistency among views
Cons
- Limited to Object oriented architectures
- Not much of an improvement over something that already exists (statechart) - although that may be why there is not much wrong with it
Conclusion
- Simple improvement to include an important concept of distributed system design
- Visual notation is something we are somewhat familiar with.
Presentation
- Presenter: Danushka
- Downloadable here: <not here yet>