K. Stirewalt CSE 335: Software Design Software architecture and larger system design issues Lecture 1: Simulating concurrency Topics: –High-level software

CSE 335: Software Design K. Stirewalt

Software architecture and larger system design issues

Lecture 1: Simulating concurrency

Topics:– High-level software architecture and its impact on

the design of classes, roles, and collaborations– Focus: Concurrency


Outline of course topics

Foundational OO concepts

Synthetic concepts:– Program families, program fragments, and abstract classes

– Separation of concepts• Separating/encapsulating cross-cutting operations [Visitors]• Mixin classes• Reusable strategies and object-oriented frameworks

– Reusable collaborations

Software architecture and larger design issues

Software process issues


Outline of course topics

Foundational OO concepts

Synthetic concepts

Software architecture and larger design issues:– Strategic design decisions that influence a host of smaller, more tactical

design decisions• E.g., policy for persistence of data in long-running system• E.g., allocating functionality to a single, centralized system vs. distributing

functionality among a collection of communicating hosts

– Often involve a major capital investment– Source of both risk and opportunity– Require lots of a priori modeling and analysis– Focus: Design issues related to concurrent and distributed systems

Software process issues


Strategic design decisions

Defn: High-level design decisions that influence the form of much of the final code– Have dramatic impact on performance, extensiblity,

reusability, and/or maintainablity of the final system– Should be made very deliberately

Analogy:– Good design yields software assets– Strategic design decisions are major capital

investments


System design

Defn: High-level strategy for solving an information flow problem and building a solution [Blaha & Rumbaugh]

– Includes decisions about organization of functionality– Allocation of functions to hardware, software, and

people– Other major policy decisions that are prior to technical

design

Assumes and builds upon a thorough requirements analysis


Example system-design decisions

Choose system performance constraints

Organize system into subsystems

Identify concurrency and choose a strategy for implementing concurrent control

Choose a policy/mechanisms for managing persistent data

Make a reuse plan

Etc…


Example system-design decisions

Choose system performance constraints

Organize system into subsystems

Identify concurrency and choose a strategy for implementing concurrent control

Choose a policy/mechanisms for managing persistent data

Make a reuse plan

Etc…


Example concern: Concurrency

Many modern desktop applications perform multiple tasks concurrently

Lots of different ways to implement concurrency in an application

Each approach comes with its own set of costs and benefits

More important: Each approach can have a dramatic impact on how one designs every class in the system


Recall design of document browser

vp : …sb : … vpm : … dm : …

announceNewValue(X)

update()

retrieve(0, ...) getLine(X, …)

retrieve(n, ...) getLine(X+n, …)

…

userEvent()

ann

ounc

eNew

Val

ue(X

)

sd design3


Exercise

Suppose we want to replace the DocManager with a StreamManager, which continuously reads lines to display from a service over the network. This manager must notify scrollbar and viewport when a new line is read from network.

Task: Draw a sequence diagram that depicts what happens when the stream manager reads a new line from the network.


<<< Break to show the app >>>


Solution sketch

vp : …sb : … vpm : … sm : …

announceNewValue(X)

update()

retrieve(0, ...) getLine(X, …)

retrieve(n, ...) getLine(X+n, …)

…

ann

ounc

eNew

Val

ue(X

)

sd stream

serviceNetwork()

???


Question

Who generates this call to serviceNetwork?

Where would we place it in our application code?


Design of function main()

int main (void){ … StreamManager* sm = new StreamManager(…); MyScrollBar* sb = new MyScrollBar(…); MyViewPort* vp = new MyViewPort(…); MyViewPortModel* vpm = newMyViewPortModel(…); … sb->registerListener(vpm); sb->registerListener(vp); vp->setModel(vpm); vpm->setModel(sm); sm->registerListener(sb); … return Fl::run();}

Question: Will this cause serviceNetwork() to be invoked periodically? By whom?


At end of “configuration phase”

Event Queue

Operating system

Mouse

main

sb : ... dm : ...

Application

listener model...


Entering “collaboration phase”

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


Step 1.1: App checks event queue

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


Step 1.2: App blocks on empty queue

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


User then moves scrollbar handle

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


Step 1.3: application “wakes” when event arrives

Event Queue

Operating system

FL::run()

Mouse

left

Pre

ss

main

sb : ... dm : ...

Application

listener model...


Step 1.4: app “pulls” event off queue

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


Step 2.1: app “dispatches” event to sb

Event Queue

Operating system

FL::run()

Mouse

p.pressEvent()

main

sb : ... dm : ...

Application

listener model...


Step 2.2: sb notifies its listener(s)

Event Queue

Operating system

FL::run()

Mouse

p.pressEvent()

main

sb : ... dm : ...

Application

listener model...


Step 2.k: dm is queried for last time

Event Queue

Operating system

FL::run()

Mouse

p.pressEvent()

main

sb : ... dm : ...

Application

listener model...


Step 2.k+1: dm query returns

Event Queue

Operating system

FL::run()

Mouse

p.pressEvent()

main

sb : ... dm : ...

Application

listener model...


Step 2.k+j: listener.announceNewValue returns

Event Queue

Operating system

FL::run()

Mouse

p.pressEvent()

main

sb : ... dm : ...

Application

listener model...


Step 3.1: App checks event queue

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


Step 3.2: App blocks on empty queue

Event Queue

Operating system

FL::run()

Mouse

main

sb : ... dm : ...

Application

listener model...


Observations

Locus of control :– Resides in object that is activated throughout interaction.– Thus far, our designs have involved single locus of control

Stream-manager sequence diagram involves two loci of control:– One for the “the GUI”– One for the stream manager– As yet, we know of no way to build applications with multiple

loci of control

Question: How could we modify our design to simulate multiple loci of control?


Modifications to main()

int main (void){ … StreamManager* sm = new StreamManager(…); … // New event loop while (Fl::check()) { Fl::wait(interval); sm->serviceNetwork(); } return 0;}

Note: Replaces call to Fl::run()


Strategy

Application simulates concurrency by having a “master loop” which periodically cedes control to “concurrent” activities

Each activity:– must be designed to be performed via multiple

invocations, each of which performs only a small part of the overall task

– must never invoke an operation that could block for any perceivable amount of time


Question

How would we have to modify our program to simulate additional loci of control?


Software control and active objects


Software controlStyles of control in a program

1. Procedural: Control resides in “application code”– Requests for resources block until resource available

2. Event-driven: Control resides in a central dispatcher– Application code does not explicitly requests resources

– Rather, application methods are “called back” to handle external events

– E.g., mouse clicks, key presses, network traffic, etc.

3. Concurrent: Multiple simultaneous threads of control– New problems to contend with: synchronization

– Active vs. passive objects

Major design decision that affects the design of lots of individual classes in a system


New concept: Active objects

StreamManager: example of an active object:– Appears to be running in its own locus of control,

distinct from that of the “main application”.– Often needed to monitor asynchronous events :

• E.g., user input, mouse motion, network traffic

Note: Design complexity increases when application involves multiple active objects.– E.g., need to explicitly design dispatcher


Exercise

Develop a class called GUIManager that simplifies extending the dispatch loop to cede control to active objects– Invent an interface class that all active objects

must implement– Active objects register with the Dispatcher (an

instance of GUIManager) to request periodic control


ActiveObjectInterface

class ActiveObjectInterface {

public:

virtual int activate() =0;

};

The activate operation is invoked to cede a “small quantum” of control to the object that implements this interface

Return value (integer) allows active object to return an error code to the dispatcher


Class GUIManager

class GUIManager { public: GUIManager();

void setTimeoutInterval( float interval ); void registerActiveObject( ActiveObjectInterface* ); int run();

private: float timeoutInterval; vector<ActiveObjectInterface*> listeners;};


Application of new collaboration

class MyStreamManager : public ActiveObjectInterface, public StreamManager { public: ... int activate() { return StreamManager::serviceNetwork(); } ...};

int main(void){ GUIManager Dispatcher; MyStreamManager sm; ... Dispatcher.registerActiveObject(&sm); return Dispatcher.run();}


Questions

What happens if the user clicks on scrollbar during the serviceNetwork transaction?

What happens to the responsiveness of the user interface if the call to activate() blocks for some perceivable amount of time?

How might we fix this?


Control implementation strategies

Event-driven sequential: Central dispatcher invokes registered objects to service asynchronous events

Time-sliced multiplexing:– Scheduler activates each active object in sequence and

periodically preempts one actor to schedule another– Generally requires operating-system support – Thread: “Lightweight process”; essentially a unit of time-

sliced multiplexing within a sequential process

Multi-process: Active objects associated with operating-system processes

Documents

K. Stirewalt CSE 335: Software Design Software architecture and larger system design issues Lecture 1: Simulating concurrency Topics: –High-level software