discipline banner.gif (11841 bytes)



i. Architecture Teams

ii. Architectural Requirements

iii. Minimalist Architecture

Related White Papers

i. Software Architecture (.pdf)

ii. Visual Architecting Process (.pdf)

For more on Architecture Action Guides see

i. Downloads

ii. Action Guide book draft

iii. Software Architecture Workshop

For more on Architecting see

Architecting Process

Book List

Coupling and Cohesion, Modularity and More

the classics!


coupling and cohesion

wikipedia entries:

coupling and cohesion metrics

strategies and patterns to achieve loose coupling

(loose) coupling -- other kinds of systems

  • Herbert Simon, Sciences of the Artificial

  • Karl Weick, "Educational organizations as loosely coupled systems", Administrative Science Quarterly, 21 (1976), 1-9 (part).

  • "The Management of Organizational Change among Loosely Coupled Elements" (1982) by Karl Weick reprinted in his book Making Sense of the Organization (2001)

  • James Douglas Orton and Karl E. Weick, Loosely Coupled Systems: A Reconceptualization, Academy of Management Review 15 (2)

related concepts/practices/concerns


responsibility driven design

  • Wirfs-Brock and Brian Wilkerson, CRC paper, OOPSLA 1989

  • Ward Cunningham and Kent Beck, CRC paper, OOPSLA 1989

  • "Object-oriented design: a responsibility-driven approach" by Rebecca Wirfs Brock and B. Wilkerson, Conference proceedings on Object-oriented programming systems, languages and applications, 1989.
  • Object Design: Roles, Responsibilities, and Collaborations By Rebecca Wirfs-Brock, Alan McKean, Nov 8, 2002

  • articles and presentation files you can download at http://www.wirfs-brock.com/Resources.html

  • Rebecca Wirfs Brock and Alan McKean, ObjectDesign: Roles, Responsibilities and Collaborations.

  • Kent Beck, Ward Cunningham, A Laboratory For Teaching Object-Oriented Thinking

  • applicable sections of Michael Feather's Working with Legacy Code

modularity in software

modularity in product architecture

code smells


  • Refactoring: Improving the Design of Existing Code By Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, 1999
  • refactoring, c2 wiki
  • refactoring, Martin Fowler's bliki
  • Refactoring Part 1: A general introduction to refactoring. Eberhard Wolff interviewing Martin Lippert

factoring/refactoring in the large
[perhaps we should say functionality preserving, rather than behavior preserving... e.g., we're good if the refactoring allows us to scale up to the next plateau, but not if it breaks a use case/user story... or if we refactor to improve fault tolerance... etc. Alternately put, we can still do the "what" and we should have improved the "how well."]

dependency injection/inversion of control

contacts and protocol design

interfaces and roles

information hiding and encapsulation

open/closed principle

case studies and examples

technical debt

tools -- static analysis (most focus on modularity, coupling, granularity, etc. issues and have implications for making technical debt visible)

tools - performance analysis (useful in making aspects of technical debt visible, like code coverage)



Back to Top

 Reference: derives from Ruth Malan's architecture journal (July 2010).

Copyright © 2010 Bredemeyer Consulting
URL: http://www.bredemeyer.com
Page Author: Ruth Malan
Page Created: August 4, 2010
Last Modified: August 04, 2010