Collaborative SystemsDeveloping Collaborative Systems with a Reuse Driven Process

CS-Domain DefinitionCollaborative 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: SuppliesThe ability to integrate with and communicate other

Executable modules in a CollaborativeSystem 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 DSLVariation 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 AssetsCS 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-ProcessesRequirement 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 Form1. 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.

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

ImplementationMechanism: 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 AssetsMechanism: Base classes (commonality) and derived classes (variability)