SE450:G9

From Marks Wiki
Revision as of 19:52, 15 February 2008 by Mark (talk | contribs) (New page: = 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 Specifi...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

PRESENTATION SLIDES

Download here: http://studwww.cs.auckland.ac.nz/~ezur001/SOFTENG_450.ppt -Danushka and Eddie

Objectives

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>