Collaborative Systems Developing Collaborative Systems with a Reuse Driven Process

CS-Domain Definition Collaborative Systems are multi-user software systems used to exchange information among those users, primarily by conversations in the form of text messages and associated files. The purpose is to allow multiple users to discuss issues, and capture decisions made about those issues in the conversation and associated files. Examples of Collaborative Systems are chat programs and electronic bulletin boards. Individual users are on individual computer systems connected by local and/or wide area networks.

Commonality & Variability in the Collaborative Systems Domain Every reuse driven domain specific process must capture the commonality and variability among members of the product family which can be produced by using that reuse driven process. The commonality is best captured by the Domain Definition and the generic Architectural Design. The variability is best captured by the DSL.

CS Commonality- CS Generic Architectural Design (1 of 3) The Common Architectural Design is made up of three required components, and several additional optional components. Required Components: CS-Client  Accepts instructions from the end user, presents them to the system, and returns results. CS-Server  Coordinates actions among all users, and manages the actions of all other components. CS-DataStore  Under the direction of the CS-Server, persistently stores both data and meta-data in the system.

CS Commonality – CS Generic Architectural Design (2 of 3) Optional Components: Application Specific Protocol Bridges  Designed to be used at the point of integration of CS components, when the component are not using the same integration protocol, it translates from one protocol to the other. Integration and Execution Strategy Messages begin at a CS-Client, and pass to a CS-Server. The CS-Server manages the re-distribution of these messages to all other CS-Clients in the system, as well as archiving appropriate system data to the CS-DataStore.

CS Commonality – CS Architectural Design (3 of 3) CS-Client CS-Server CS-DataStore CS-Client CS-Bridge

CS Commonality – CS Component Design The basic required interface of the CS components, are a reflection of the commonality of the CS Domain. The optional interface features of the CS components, are a reflection of the variability of the CS Domain. Most Components are Patterns, implemented as a set of sub-components

CS Commonality – CS-Client Component Design (1 of 2) – Composition Communication/ Integration Module: This is the module that supplies the connection from this client to the Server by any available protocol/middleware such as COM, CORBA, ASP, SOAP Base/Logic Module: Business logic supplied to MRM instance, this is where application specific logic which is outside of the User Interface itself is implemented UI: Main process control and basic framework of executable MRM instance.

CS Commonality – CS-Client Component Design (2 of 2) – Interface Interface: UI: Exposes login, input/output interface to user. API: not applicable Dependency Interface Requires integration thru message protocol to either CS- Server or CS-Bridge. DPI Methods (supplied by CS-Server or CS-Bridge API):  long SendMessage( in string UserName, in string Password, in string Message )  Long Login( in string UserName, in string Password )  StringSequence GetMsssages( in string UserName, in long LastUpdatedTo, out long NumberOfMessages )  Long Logout( in string UserName, in string Password )

CS Commonality – CS-Server Component Design (1 of 3) – Composition Chat Services Module: Supplies the logic of the document viewing/sharing services themselves Chat Core Module: Supplies basic architecture of Chat Server Chat Communication/Integration Module: Supplies The ability to integrate with and communicate other Executable modules in a Collaborative System application.

CS Commonality – CS-Server Component Design (2 of 3) – Interface Interface: UI: not applicable API:  long SendMessage( in string UserName, in string Password, in string Message )  Long Login( in string UserName, in string Password )  StringSequence GetMsssages( in string UserName, in long LastUpdatedTo, out long NumberOfMessages )  Long Logout( in string UserName, in string Password )

CS Commonality – CS-Server Component Design (3 of 3) – Interface (continued) Dependency Interface Requires integration thru message protocol to either CS-Server or CS-Bridge. DPI Methods (must be supplied by CS-DataStore API):  long StoreMessage( in string DelimitedRecord, out string RecordMetaData )  string GetMessage( in string RecordMetaData )  string GetMetaData( in string MetaDataPattern )

CS Variability – Mixin Implementation Packaging Each Component is a pattern, implemented by multiple sub- components. Variability will not affect required interfaces, though can add optional methods.

CS Variability-Domain Specific Language Variability in the Collaborative Systems DSL Variation Points: VP1: Synchronicity {Synchronous, Asynchronous} VP2: Integration Protocol {COM, CORBA, SOAP} VP3: Persistence Technology {flat-file, OLE-DB, none}

CS Software Assets CS Requirements Assets CS Design Assets Already covered CS Implementation Assets CS Test Assets

CS Requirements Asset: Multiple Choice Form Q1:Will messages be sent in (a) real time (immediate) or (b) left to be picked up at user’s convenience? Q2: Will the client software be on (a) Windows or (b) UNIX based systems? Q3: Will the server software be on (a) Windows or (b) UNIX based systems? Q4: Will the software be maintained by (a) internal staff, or the (b) CS system developers?

CS Requirements Asset: Multiple Choice Form Q4a: If the answer to Q4 was (a), is the internal staff familiar with (a) Visual Basic, (b) C++ and/or (c) Java programming? Q5: Will the use of the CS system need to (a) archived, or (b) will the content of each collaborative session be discarded each time the server is reinitialized? Q5a: If the answer to Q5 was (a), what COTS product should be used to store the archives: (a) SQL Server, (b) Access, or (c) none?

CS-Processes Requirement Analysis: Comparing new system requirements to existing assets. Design: Tracing requirement specs to design assets to implementation assets. Capturing from a recently completed system development effort new reusable assets, and opportunities for new reusable assets.

Requirements Analysis Process Mechanism: Multiple Choice Form 1. Conduct interview with customer/end user of new system. Multiple choice form 2. Convert interview results to requirements document, explicitly identifying which requirements can be satisfied with reusable assets. 3. Submit requirements document to application engineering team 4. Submit unsatisfied requirements to domain engineering team.

Design Mechanism: Generic Architectural Design as Component System 1. Using requirements document, retrieve design assets of identified reusable assets. 2. Search repository for design assets missed in requirements analysis, as well as those similar to unsatisfied requirements, that might be reengineered to fit. 3. Instantiate generic architecture with decisions from (1) above. 4. Complete architectural design using(1), (2) and (3) above, adding additional design features to complete application design.

Implementation Mechanism: Tailoring and Specialization. 1. Using completed application design, retrieve implementation assets of identified assets. 2. Search repository for implementation assets that match new custom features in application design, as well as those similar to them, that might be reengineered to fit. 1. If found, tech management decides which to use. 3. Implement design features for which reusable assets are not identified. 4. Integrate reusable assets and new development into new application

Class Exercise: Test

Capturing Reusable Assets Mechanism: Base classes (commonality) and derived classes (variability)