ooad using the uml - describe concurrency, v 4.0 copyright 1994-1998 rational software, all...

OOAD Using the UML - Describe Concurrency, v 4.0Copyright 1994-1998 Rational Software, all rights reserved 1 R

Thread

Thread

Process X

Thread

Process Z

Process Y

Inter-process communication

Intra-process communication

Intra-process communication

Describe Concurrency


Objectives: Describe Concurrency

Understand the purpose of Describe Concurrency and Understand the purpose of Describe Concurrency and where in the lifecycle it is performedwhere in the lifecycle it is performed

Understand what a thread of control is for a systemUnderstand what a thread of control is for a system Understand how classes and subsystems are mapped to Understand how classes and subsystems are mapped to

identified processesidentified processes Model the concurrency requirements of the system in the Model the concurrency requirements of the system in the

Process ViewProcess View


Architect

ArchitecturalAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

Review theArchitecture

DatabaseDesign

Use-CaseAnalysis

SubsystemDesign

ClassDesign

Use-CaseDesign

Review theDesign

Designer

DatabaseDesigner

DesignReviewer

ArchitectureReviewer

So Where Are We?


Describe Concurrency Overview

Process Model

DescribeConcurrency

SupplementarySpecifications


Describe Concurrency Topics

Concurrency RequirementsConcurrency Requirements Modeling ProcessesModeling Processes Mapping Processes onto the Implementation EnvironmentMapping Processes onto the Implementation Environment Distributing Model Elements Among ProcessesDistributing Model Elements Among Processes


Process View Deployment View

Logical View

Use-Case View

Implementation View

End-user Functionality Programmers

Software management

PerformanceScalabilityThroughput

System integratorsSystem topology

Delivery, installationcommunication

System engineering

Analysts/DesignersStructure

Key Concepts: The Process View


Concurrency Requirements

Concurrency requirements are driven by: Concurrency requirements are driven by: The degree to which the system must be distributed The degree to which the system is event-driven The computational intensity of key algorithms The degree of parallel execution supported by the

environment Concurrency requirements are ranked in terms of Concurrency requirements are ranked in terms of

importance to resolve conflictsimportance to resolve conflicts


Concurrency ApproachesApproach Advantages Disadvantages

Uni-process,no threads

- Simplicity- Fast intra-process

messaging

- Hard to balance workload- Swapping and context switches are

expensive- Can’t scale to multiple processors

Uni-process,multi-threaded

- Fast intra-process messages- Multi-tasking without inter-

process communication- Better multi-tasking without

the overhead of'heavyweight' processes

- Application must be 'thread-safe- Operating system must have

efficient thread-management- Shared memory issues need to be

considered

Multi-process - Scales well as processorsare added

- Relatively easy to distributeacross nodes

- Sensitive to process boundary: usinginter-process communication toomuch hurts performance

- Harder to design


Example: Concurrency Requirements

In the Course Registration System, the requirements for In the Course Registration System, the requirements for concurrency come from the requirements and the concurrency come from the requirements and the architecture: architecture: Multiple users must be able to perform their work concurrently If a course offering becomes full while a student is building a

schedule including that offering, the student must be notified. Risk-based prototypes have found that the legacy registration

system cannot meet our performance needs without some creative use of mid-tier processing power.


Key Concepts: Process and Thread

ProcessProcess Heavyweight flow of control Processes are stand-alone May be divided into individual threads

ThreadThread Lightweight flow of control Threads run in the context of an enclosing process


Process Identification Considerations

Separate threads of control may be needed to: Separate threads of control may be needed to: Take advantage of multiple CPUs and/or multiple nodesTake advantage of multiple CPUs and/or multiple nodes Increase CPU utilizationIncrease CPU utilization Prioritize activitiesPrioritize activities Support load sharing Support load sharing Separate concerns between different areas of the software Separate concerns between different areas of the software Improve system availabilityImprove system availability Support major subsystemsSupport major subsystems


<<stereotype>>Name

<<stereotype>>Component Name

<<stereotype>> can be <<process>> or <<thread>>

Process1.exe

Modeling Processes

Processes may be modeled using Processes may be modeled using Active classes (Class Diagrams) and Objects (Interaction

Diagrams)

Components (Component Diagrams)

Relationships<<stereotype>>

Name<<stereotype>>

Name


Example: Modeling Processes: Class Diagram

(stay tuned for composition)

composition<<process>>CourseCatalogSystemAccess

<<thread>>CourseCache

<<process>>CourseRegistrationProcess

<<thread>>OfferingCache

dependency

1

1

1

1

<<process>>StudentApplication


Example: Modeling Processes: Component Diagram

<<process>>CourseCatalogSystemAccess

<<thread>>OfferingCache

<<thread>>CourseCache

<<process>>CourseRegistrationProcess

dependency

<<process>>StudentApplication


Mapping Processes onto the Implementation

Conceptual processes must be mapped onto specific Conceptual processes must be mapped onto specific implementation constructsimplementation constructs Process Threads

ConsiderationsConsiderations Process coupling Performance requirements System process and thread limits Existing threads and processes IPC resource availability


Example: Mapping Processes to the Implementation

CourseCatalogSystemAccess

Remote

(from java.rmi)CourseRegistrationProcess

Runnable

(from java.lang) OfferingCache

Thread(from java.lang)

1

CourseCache

1

1

1


Design Elements-to-Processes Considerations

Based on:Based on: Performance and concurrency requirements Distribution requirements and support for parallel execution Redundancy and availability requirements

Class/subsystem characteristics to consider:Class/subsystem characteristics to consider: Autonomy Subordination Persistence Distribution


Design Elements-to-Processes Strategies

Two Strategies (used simultaneously)Two Strategies (used simultaneously) Inside-OutInside-Out

Group elements that closely cooperate, and must execute in the same thread of control

Separate elements which do not interact Repeat until minimum number of processes reached that still

provides required distribution and effective resource utilization Outside-InOutside-In

Define a separate thread of control for each external stimuli Define a separate server thread of control for each service Reduce number of threads to what can be supported


Class diagramsClass diagrams Active classes as processes

Composition relationships from processes to classes

Composition relationships from processes to subsystem interfaces

Class NameProcess Name<<process>>

<<interface>>Interface Name

Process Name<<process>>

Process Name<<process>>

Modeling the Mapping of Elements to Processes

(stay tuned for Composition)


Example: Mapping Design Elements to Processes

StudentApplication<<process>> MainStudentForm

(from Student Interface)

<<boundary>>

1 1

CourseRegistrationProcess<<process>> RegistrationController

(from Registration)

<<control>>

1 1

CourseCatalogSystemAccess<<process>> CourseCatalog

(from CourseCatalog)

<<subsystem>>1 1

CourseCache<<thread>>

1

1

Course(from University Artifacts)

<<entity>>0..*1

OfferingCache<<thread>>

1

1

CourseOffering(from University Artifacts)

<<entity>> 0..* 1

ooad using the uml - describe concurrency, v 4.0 copyright 1994-1998 rational software, all...

Documents