predictive patterns software inc some observations on layering and representation in the design and...
TRANSCRIPT
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.
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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?
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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...
Predictive Patterns Software Inc
Software Organization II
Users Product Manager
Dev Lead
Dev1 Dev2
Predictive Patterns Software Inc
Forces That Produce BBM
● Runtime Performance/Scalability● Rigid Architecture● Time-to-Market/Cost/Scheduling● Maintenance Coding● Reusability/Framework Incompatibility● Changing Requirements
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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.
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
Solutions
● Layering– Structural limitation
● Representation– Conceptual limitation
=> Developers write code doubleplusgoodwise.
Predictive Patterns Software Inc
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.
Predictive Patterns Software Inc
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)
Predictive Patterns Software Inc
Alternatives
Excessively strict layering impedes moving functionalitybetween layers.
Predictive Patterns Software Inc
Unlayered M/V Architecture
View Component 1(slider)
Model Component 1(numeric value)
View Component 2(text box)
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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.
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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);}
}
Predictive Patterns Software Inc
Callbacks and Updates
void ViewObject::uiEventHandler(event *pEvent)
{
m_pModelObject->doSomethingTimeConsuming();}
● Foreground processing (progress dialog)● Background processing (notification on
completion)
Predictive Patterns Software Inc
Alternative I: Sliced Processingvoid ViewObject::uiEventHandler(event *pEvent)
{
m_nProcessState = knDoSomethingTimeConsuming;}
void ViewObject::onPollingCall(ModelObject* pModelObject)
{
if (m_nProcessState == knDoSomethingTimeConsuming){
pModelObject->doSingleStepOfTimeConsumingTask();}this->updateUI();
}
Predictive Patterns Software Inc
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);...
}}
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
Alternative III: Publish/Subscribe
● Generalization of Callback allowing any number of caller objects
● “Observer” in Design Patterns (Gamma, Helm, Johnson, Vlissides)
Predictive Patterns Software Inc
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;};
Predictive Patterns Software Inc
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);...
}}
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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.
Predictive Patterns Software Inc
Exceptions
Function call
Function callException
Handle/Rethrow/Translate
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
Layered Algorithms
● Common “OO” approach to algorithms:
myAlgorithmObject->justDoIt();
● Layered approach:Manager
Translator
Worker
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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)
Predictive Patterns Software Inc
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
Predictive Patterns Software Inc
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