Pedagogical Pattern #24
Client-Server-Negotiation (CSN) Pattern
(Version 1.0)
Eliezer Kantorowitz
CS Dept. Technion Haifa
Kantor@csa.Technion.ac.il
Fanny-Michaela Reisin
CS Dept. Technical College Berlin
reisin@cs.tu-berlin.de
Intent:
To enable students to experience practically such advantages of oo technology like for instance conceptual adequacy, seamlessness, requirement traceability, or component reusability by taking over client/server responsibilities.
Motivation:
We relate the benefits mentioned above to two principles of oo abstraction, which we call service encapsulation and service implementation hiding. In this view each object(-class) is considered to be a service supplier, i.e. a server.
Most of the objects are also service applier, i.e. clients. Objects, which are clients only and don't "serve" at all, are excluded from this view. Any modeled server object is assumed to have at least one client, who "uses" its services and hence to be one part of a client-server-association.
In this view the service interface of every modeled object be specified in terms of a client-server-contract, i.e. of an agreement of mutual requirements and assurances between the server object and each of its client objects (Meyer 88).
Such a contract comprises the use-related abstraction of the services, which are encapsulated and implemented by the very server object as well as the conditions, which must be met, in order to guarantee the validity, consistency, and integrity of:
- the object, that encapsulates specific services as a whole
- any single service
- the given system, composed of interrelated objects or object (sub-)systems.
The conditions, which have to be assured by a client (and are thus required by the server) before the server "runs a called service" are fixed in the contract as service- related preconditions. The conditions, which have to be assured by the server (and are thus required by the client) "after having run a called service", are fixed in the contract as service-related postconditions or/and as object-related behavior invariants.
Starting out from here, we extend Bertrand Meyer's well known "design-by-contract"-metaphor to an overall modeling-by-contract-metaphor (Meyer 88). Our integrated course "Object Oriented System Development" (15 weeks), which is composed of a lecture (1.5 h per week) and a semester exercise (1.5 h tutorial per week) is triggered by the Client-Server-Negotiation-Concept, which is in fact a pedagogical pattern (Lilly 1996) for all negotiation activities between the students who represent either human software customers/users and suppliers or else the developers of client rsp. server objects.
Owing to the conceptual seamlessness of oo modeling the client-server negotiations on object contracts repeat in the different stages of the software development process whereas the pattern's "instantiations" i.e. the actually negotiating clients resp. servers and especially the subjects of their
negotiations vary all the time. Thus the CSN-Pattern turns out appropriate to teach both, the different functional roles in oosd and the different aspects of the evolving objects(-system) from the very first stage of the user requirement description throughout the stages of requirement analysis, design, and program modeling.
Applicability:
Apply the CSN-Pattern to teach and exemplify specific benefits of the object modeling process (client-server-negotiations) as well as specific properties of the resulting objects (server-interface resp. client-server-contract-specifications).
It was already mentioned above, that the CSN-Pattern is applicable to all oo modeling tasks and stages because of the conceptual seamlessness of the object development process. Since the concepts to specify constraints in terms of object and service related pre- and postconditions, which were originally introduced by Bertrand Meyer (Meyer 88) for the programming language Eiffel, are adapted by now for any stage of oo modeling (Coleman et al. 94, Rumbaugh et al. 91, Rumbaugh 95) the CSN-Pattern is particularly appropriate to focus on these benefits of object modeling throughout the sd process.
Structure:
During the various stages of the system development process the students, who
work in teams of, say 2-3 members, change functional roles according to the
predefined oo modeling tasks and client/server "instantiations" for each stage
of the predefined oosd process. The negotiation activities comprise mutual
communication and learning processes with the aim to reach a consensus and
to specify an object- resp. service-related contract. The CSN pattern structure
does not change. The following "instantiations" for selected tasks in different
stages of the oosd process may illustrate the pattern's structure:
- User Requirement Description
- Client - Customer (resp. User)
- Server - Software manufacturer (resp. software developer)
- Negotiations - Computer supported system envisioned by
the client and by the server
- Contract - Use cases - and/or other requirement descriptions.
- Requirement Analysis - Object modeling
- Client - User
- Server - Software developer
- Negotiation - The object system required by the client, i. e. the
object model, to which further models will refer
- Contract - Requirement object model specification.
- Requirement Analysis - Function modeling (Fusion, UML)
- Client - Human user / client object developer
- Server - Software developer
- Negotiation - The functionality and constraints of any single
service
- Contract - Service specification (UML: “operation specification”, Fusion: “operation schemes”), commprisinthe signature as well as the elicitated constraints (pre- and postcondition) of each required service.
- Design modeling - Object modeling
- Client - Client object designer (software developer)
- Server - Server object designer (software developer)
- Negotiation - Structural and functional integrity of the designed object
system, in order to assure the required behavior
- Contract - Design Specification (objects and object
(sub-)systems.
The oo contract negotications and specification activities during later stages
as f. e. the programming, evaluation, validation stage may be designed
accordingly. It should be pointed out that the environments of programming
language like Eiffel 3.0, Ada 95 and C++ support the evaluation and check of
object interfaces, which are specified in terms of contracts resp. service and
behavior related constraints.
Consequences:
The CSN-Pattern:
- supports learning by doing and gives students responsibilities for process and
product related tasks during sd
- enables students to experience the different perspectives and roles throughout
the process of oosd
- enables instructors to concentrate on specific features, benefits, and pitfalls of oosd
- enable the students to experience the negotiations of service interfaces contracts for oo subsystems of a larger project.
Since the student (-groups) are involved in true responsibilities and obligations
their motivation and engagement are intrinsic.
Implementation:
The CSN-Pattern requires:
- exercises and sub-exercises, that include non trivial negotiation and management tasks
- more management on the side of students and lecturers, i. e. more time for the exercise conduction
- oo methods and tools (UML, Fusion, Objectory) and oo programming environments like Eiffel, Ada 95, C++ (incl. exception handler).
Related Patterns:
None.
Example Instances:
The CSN-Pattern has been used to teach and train oosd using:
- OMT and Eiffel as PL + environment (Berlin)
- OMT and Ada 95 as PL + environment (Berlin)
- Fusion and C++ as PL + exception handling (Berlin)