Predictive Patterns Software Inc Some Observations on Layering and Representation in the Design and Implementation of Object- Oriented Systems Tom Radcliffe,

Predictive Patterns Software Inc

Some Observations on Layering and Representation in the Design and Implementation of Object-

Oriented Systems

Tom Radcliffe, Ph.D., P.Eng.President, Predictive Patterns Software Inc.Adjunct Professor, Dept of Pathology, Queen's University

Tom Radcliffe, Ph.D., P.Eng.


Outline● Problem Statement: where does the Big Ball of Mud come from?● Systems and Organizations: Conway's law and the software team● Layering● Distributing information within a layered system● Representation● Conclusion


Problem Statement

BIG BALL OF MUD: a casually, even haphazardly, structured system.

Brian Foote and Joseph Yoder, Chapter 29Pattern Languages of Program Design 4

edited by Neil Harrison, Brian Foote, and Hans RohnertAddison-Wesley, 2000

What forces produce the BBM?

How can layering and representation help control it?


Stability

● Software becomes “stable” when it is impossible to change

● Organizations create the most complex systems they are capable of

● The BBM is one way to achieve stability


Conway's Law● “Organizations which

design systems... are constrained to produce designs [that] are copies of the communication structures of these organizations.”

● “Any system of consequence is structured from smaller subsystems which are interconnected.”– Melvin Conway,

Datamation April, 1968


Software Organization● Marketing

● Product Manager● Development

● Development Manager–Sr. Software Eng/Designer/Architect

● Intermediate Developers● Junior Developers

–Tech Writers–QA–Installer Team

● Sales● Support● Training/Professional Services● HR...


Software Organization II

Users Product Manager

Dev Lead

Dev1 Dev2


Forces That Produce BBM

● Runtime Performance/Scalability● Rigid Architecture● Time-to-Market/Cost/Scheduling● Maintenance Coding● Reusability/Framework Incompatibility● Changing Requirements


Thesis

● The Big Ball of Mud arises from informal communication within the development organization in response to the forces acting on the development team

● Hypothesis:Restricting communications within the code while

permitting it within the development organization (ie. adding further constraints to Conway's Law) will reduce the growth rate of the BBM


Non-Solutions to BBM

● Libraries– Library Team– Application Team

● Rigid Methods– Waterfall/Up-Front Design– Over-specification– Micro-management

● Ignoring documentation or other essentials

Attempt to restrict communication or make communicationnon-actionable.


Constraints● Enforceable

– Violations can be detected automatically– Fixes can be implemented quickly and practically

● Comprehensible– Developers must be able to understand the solution

● Affordable– Must not create unacceptable overheads

● Allow unlimited communication between developers but enforceably restrict how that can be reflected in the code without making developer's job impossible


Solutions

● Layering– Structural limitation

● Representation– Conceptual limitation

=> Developers write code doubleplusgoodwise.


Layering● Enforceable restriction of functionality into

horizontal units in which lower levels are completely unaware of levels above them

● May be Model/View or MVC at application level● Many variants for algorithms etc.


Layered System

● Each layer knows only about the ones below it.● Only function calls are used for inter-layer

communication. Events, signals, messages... are not allowed to cross layer boundaries

● Every piece of information is represented exactly once in the lowest necessary layer (and no lower)


Alternatives

Excessively strict layering impedes moving functionalitybetween layers.


Unlayered M/V Architecture

View Component 1(slider)

Model Component 1(numeric value)

View Component 2(text box)


Disadvantages of Unlayered M/V

VC 2(text)

VC 3(visual)

VC 1(slider)

MC1(value)

In an unlayered architecture every view component potentially needs to know about every other view component

New developers need to graspthe entire view design beforethey can safely add anything

Alternatively, model componentsmust know about all viewcomponents that represent them


Layered M/V Architecture

View Component 1(slider)

Model Component 1(numeric value)

View Component 2(text box) Timer

Event Loop

Layered M/V or MVC architecture requires that the view poll the model regularly.


Advantages of Layering

VC 2(text)

VC 3(visual)

VC 1(slider)

MC1(value)

Component decoupling facilitated

UI update rate explicitly controlled

Every piece of information hasexactly ONE canonicalrepresentation

TimerEvent Loop


Typical Polling Implementation

void MainFrame::pollingEventHandler(Event* pEvent)

{

// ensure model is in a self-consistent statem_pTopLevelModelObject->pollingUpdate();

// sync all UI objects with modelforeach (UIObject){

pUIObject->onPollingEvent(m_pTopLevelModelObject);}

}


Callbacks and Updates

void ViewObject::uiEventHandler(event *pEvent)

{

m_pModelObject->doSomethingTimeConsuming();}

● Foreground processing (progress dialog)● Background processing (notification on

completion)


Alternative I: Sliced Processingvoid ViewObject::uiEventHandler(event *pEvent)

{

m_nProcessState = knDoSomethingTimeConsuming;}

void ViewObject::onPollingCall(ModelObject* pModelObject)

{

if (m_nProcessState == knDoSomethingTimeConsuming){

pModelObject->doSingleStepOfTimeConsumingTask();}this->updateUI();

}


Alternative II: Callbacksvoid ViewObject::uiEventHandler(event *pEvent)

{

m_pModelObject->doSomethingTimeConsuming(this->m_pCaller);}

void ModelObject::doSomethingTimeConsuming(Caller* pCaller)

{

while(m_fTime < gkfHeatDeathOfUniverse){

...if (condition) pCaller->callBack(progressIndicator);...

}}


Drawbacks of Callbacks

● Lower layer must anticipate upper layer's needs● Unlimited potential for communication unless

Caller class rich and restricted– Provide Caller class with restricted vocabulary of

notifications and responses● Notifications:

– Update– Error

● Response:– Cancel– Continue

● Exception safety● Only the caller gets notified


Alternative III: Publish/Subscribe

● Generalization of Callback allowing any number of caller objects

● “Observer” in Design Patterns (Gamma, Helm, Johnson, Vlissides)


Publish/Subscribe Implementationclass Publisher

{...

public:

void addSubscriber(Subscriber* pSub) {m_setSub.insert(pSub):}

void publish() {foreach(pSub) pSub->notify(this);}};

class Subscriber

{...

public:

void notify(Publisher* pPub) = 0;};


Publish/Subscribe in Use

// during UI construction

pModelObject->getPublisher()->addSubscriber(pUIObject->getSubscriber())

// during model processing

void ModelObject::doSomethingTimeConsuming()

{

while(m_fTime < gkfHeatDeathOfUniverse){

...if (condition) m_pPublisher->publish(m_pPublisher);...

}}


Drawbacks of Publish/Subscribe

● Very fragile if not implemented properly– Exception safety– Detaching subscribers during publication process

● Other drawbacks of CallBack● Allows generalized communication

Publish/Subscribe == perfect mechanism for creating a BBM


Alternative IV: threads and messagingvoid ModelObject::doSomethingTimeConsuming()

{

Thread* pThread = createWorkerThread(...);pThread->run();

}

● Advantages– Maintains layer integrity– Does not require framework changes

● Disadvantages– Synchronization– Deadlocking– Etc.


Exceptions

Function call

Function callException

Handle/Rethrow/Translate


Layering Verification

● Layering can be verified by simple inspection of dependencies– If lower layer contains headers from upper layers,

layering constraints are violated● Automated layer checking can be made part of

daily build● The value of routine, automated verification of

architectural integrity cannot be over-emphasized


Application Layering Summary

● Controls BBM by restricting communication between layers, not between people!

● Liveness requires some kind of callback mechanism for long processes

● Use the most restrictive callback mechanism possible

● Focus on controlled vocabularies for Caller objects to prevent generalized communications from breaking out

● Real applications have more than just two layers


Layered Algorithms

● Common “OO” approach to algorithms:

myAlgorithmObject->justDoIt();

● Layered approach:Manager

Translator

Worker


Constrained Minimization

● Problem: find a combination of x-ray beams to treat tumor while minimizing dose to surrounding tissue

● Solution:– B1 = +10– B2 = -24– B3 = +14

B1

B2B3

B1B3


Layered Minimization Algorithm

Domain Manager(beams, patient, etc.)

Minimizer(mrqmin etc.)

Translator(if (fParam < m_fK) fParam = m_fK*exp((fParam-m_fK)/m_fK))

Objective Function(minimum when normal/tumor maximized)


Representation

● Domain concepts provide common knowledge base and historical continuity

● Appropriate flexibility is maximized● Distance between specification and code is

minimized● Automated code generation is facilitated

Principle of Verisimilitude: system structure should be as isomorphic with real-world objects as possible


Conclusion● Layering

– Reduces communication channels in the code– Can be enforced without limiting who gets to touch

what code– Facilitates single representation

● Representation– use of domain concepts reduces developer ability to

violate real-world constraints

Documents

Predictive Patterns Software Inc Some Observations on Layering and Representation in the Design and Implementation of Object- Oriented Systems Tom Radcliffe,