Upload
timothy-sanders
View
216
Download
0
Embed Size (px)
Citation preview
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: 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-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.