Caterpillar's Fate: A Pattern Language for the Transformation from Analysis to Design


By: N.L. Kerth
Published in: PLoPD1
Pages: 297-320

Transformation from analysis to a design in a concurrent processing environment.

Category: Concurrent Systems

Summary: Transformation from analysis to a design in a concurrent processing environment.

Url: http://c2.com/ppr/catsfate.html

Pattern: Concurrent Threads of Execution

Pages: 295-296

When a system contains processes that run simultaneously or pseudo-simultaneously, identify threads of execution that can exist independently. Then use Collaborative Work Packets and Synchronization of Concurrent Threads. If there's only one concurrent thread, use Shape of Program

Pattern: Synchronization of Concurrent Threads

Pages: 296-297

You've used Concurrent Threads of Execution. Review each thread throughout its life cycle and identify those points where a signal is sent to or received from another thread. Name the signal for the situation it represents, identifying the sender and the receiver.

Pattern: Collaborative Work Packets

Pages: 297-298

You're using Concurrent Threads of Execution. Review the life cycle of each thread in a pair of concurrent threads, and identify work initiated by one and continued by the other. Name the work packet for the information and work unit it manages or hides. For each work packet, identify possible producer and consumer concurrent threads.

Pattern: Work Packet Contents

Pages: 298-299

You're using Collaborative Work Packets. For each work packet, document all information necessary for the work to be done. Then use Work Packet Completion Report, Work Packet Priority, Work Packet Security and Work Packet Status Report

Pattern: Work Packet Status Report

Pages: 299-301

You're using Collaborative Work Packets and Work Packet Contents. Now decide whether to generate a report for the producer on the work packet's status. Keep this part of the design as simple as possible. Your system needs to produce status reports, but that's not its primary goal.

Pattern: Work Packet Completion Report

Pages: 301-302

You're using Synchronization of Concurrent Threads, Collaborative Work Packets, and Work Packet Contents. When a work packet completes its processing in the consumer's concurrent thread of execution, keep the completion report simple. Ensure Shape of Program addresses the receipt of every completion report identified.

Pattern: Work Packet Priority

Pages: 302-303

You're using Collaborative Work Packets, and transforming the general Shape of Program to a specific one. Determine a policy for selecting waiting work packets. "First come, first served" might be sufficient, but there may be hidden requirements.

Pattern: Work Packet Security

Pages: 303-304

You're using Work Packet Contents and looking at work packet security issues. If security is crucial, stop all design activities, return to analysis, and develop effective security models.

Pattern: Shape of Program

Pages: 305-307

You're using Synchronization of Concurrent Threads, and Collaborative Work Packets. You're ready to apply a specific form to the general shape of your program. A tiered structure is a good starting point. Objects on each tier can request services from components on the same or lower tiers but not on higher tiers. When the tiered shape begins to fail, use Small Family Systems and Work Accomplished Through Dialogs

Category: Architectural, Concurrent Systems

Pattern: System Citizen's Role

Pages: 307-308

You're using Concurrent Threads of Execution, and the Shape of Program is moving from general to specific. Most programs reside on platforms where several applications are running concurrently. Design a single object with the protocol that applications must follow to be good citizens in a community of applications. Use Event Acquisition and Event Routing

Pattern: Decision Maker's Role

Pages: 308-309

When the Shape of Program begins to move from the general to the specific, and the system citizen's role becomes defined, create an object responsible for decision-making activities. Separate policy-making activities from those that carry out policy. Then connect objects defined in Human Interface Role Is a Special Interface Role, Interface's Role, and Workers' Role

Pattern: Workers' Role

Pages: 309

When the Shape of Program begins to move from the general to the specific, you're ready to design objects to move the application closer to its goal. Build objects to carry out policy- and decision-making responsibilities.

Pattern: Interface's Role

Pages: 309-310

When the Shape of Program begins to move from the general to the specific, you're ready to design objects that hide the behavior of external entities. Hide the behavior of these entities in an object that provides high-level abstract services to the system.

Category: Concurrent Systems, Design Process

Pattern: Informational Role

Pages: 310-311

When the Shape of Program begins to move from the general to the specific, you're ready to design objects that move through the system, visiting interface objects. Create objects to deliver specific information without exposing the structure of the information. These objects are found by noting how information flows on an event-partitioned data-flow diagram.

Category: Concurrent Systems, Design Process

Pattern: Small Family Systems

Pages: 311-312

When the Shape of Program begins to move from the general to the specific and the tiered system is awkward, don't discard the program shape; just augment it with another "mini" shape for the portions of the system you're considering.

Pattern: Work Accomplished Through Dialogs

Pages: 312-313

When the Shape of Program is moving from the general to the specific and you see two objects that need to call each other's operations. Allow the two objects to carry on a dialog with each other. Avoid controlling dialogs or dialogs that involve more than one object.

Category: Concurrent Systems, Design Process

Pattern: Critical Region Protection

Pages: 313-314

You're using Concurrent Threads of Execution and the Shape of Program for each thread has moved from general to specific. Look for potential critical region problems. For each concurrent thread, identify the shared objects. For each shared object, if needed, develop a protection mechanism that ensures safe use.

Pattern: Event Acquisition

Pages: 314-315

When the Shape of Program begins to move from the general to the specific and the system citizen's role is being considered, choose the event-acquisition capabilities that make sense for your application and refine the shape of the program. Return to Shape of Program to transform the general shape into a specific one.

Category: Event-Driven Systems, Reactive and Real-Time Systems

Pattern: Event Routing

Pages: 315

When the Shape of Program begins to move from the general to the specific, and the system citizen's role is being considered, use this pattern and Event Acquisition to resolve design issues. Return to Shape of Program and continue to transform the general shape into a specific one.

Category: Event-Driven Systems, Reactive and Real-Time Systems

Pattern: Human Interface Role Is a Special Interface Role

Pages: 316-317

When the Shape of Program begins to move from the general to the specific, you will see how decision-making objects get direction from humans. Create an interface object that hides human interface-specific design decisions.

Category: Concurrent Systems, GUI Development

Pattern: Data Knows Its Roots

Pages: 317-318

Once you've identified collaborative work packets, informational role-oriented objects, or any other entity that contains information, determine if their history should be known. Design the entity so it records all relevant information.