Date post: | 18-Jan-2018 |
Category: |
Documents |
Upload: | philomena-edwards |
View: | 219 times |
Download: | 0 times |
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)