O

ne of MASCOT’s unique features is the way it manages the transition between design, implementation, and deployment.   Unlike other methodologies that adopt

a reverse or ‘round-trip’ engineering approach, MASCOT applies a design-centric discipline to the process.

ACP diagrams assume the existance of a uniform deployment platform, the MASCOT Machine. The MASCOT methodology defines a MASCOT Machine to be an implementation independent platform that provides a small number of well defined primitives. The entities on an ACP diagram (channels, pools, activities, and devices) all have an underlying implementation. The methodology constrains the development of an entity implementation to use only the primitives defined by a MASCOT machine. The process of building an application involves designing and developing higher level structures on top of the facilities provided by a MASCOT Machine.

SET documents encapsulate all of the information in an ACP diagram. They are generated from ACP diagrams and read as configuration files by MASCOT Machines. In essence, SETs are the bridge between design and deployment and implement a direct connection between the two. SET documents are XML files and as such are easily manipulated and maintained by most revision control systems. The ‘System Element Template Details’ page presents an annotated description of the structure of a SET document.

MASCOT enhances the design process and is not intended to replace currently available tools. MASCOT itself has nothing to say about how its entities are implemented (other than the rules governing ACP diagrams and the constraints imposed by using the MASCOT Machine as a deployment platform). Channels, pools, activities, and devices will all have code attached to them and users are free to choose