1. Collaborative Systems Developing Collaborative Systems with a Reuse Driven Process

2. 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.

3. 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.

4. 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.

5. 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.

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

7. 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

8. 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.

9. 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 )

10. 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.

11. 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 )

12. 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 )

13. 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.

14. 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}

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

16. 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?

17. 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?

18. 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.

19. Requirements Analysis Process Mechanism: Multiple Choice Form

20. Design Mechanism: Generic Architectural Design as Component System

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