George Fairbanks's blog

Speaking at University of Colorado (Boulder), 4 March 2010 3:30pm

I will be speaking about Design Fragments and software frameworks at the University of Colorado (Boulder) computer science colloquium on 4 March 2010 at 3:30pm.

Edit 10 March 2010: Now with video:









Presentation on Design Fragments at the University of Colorado Boulder.

Updated book chapters available

I’ve posted a couple updated book chapters here. The biggest change is a reorganization of the book. The first part now deals with risk-centric architecture and does not delve into specific ways of modeling architecture, reserving that for the second part of the book.

The two revised chapters are:

If you are new to software architecture, these provide a good introduction to what it is and how you can do “just enough” architecture (rather than wasting lots of time or painting your project into a corner).

Speaking at Boulder Java User Group, 9 February 2010

I will be presenting a lecture on Design Fragments at the Boulder Java User Group meeting on 9 February 2010 at 6pm (before the pizza break). The lecture will be based on my thesis work. You can find a preview slide presentation on the work here. More details, including the full thesis, are available here.

You can watch a video of this talk, given at CU Boulder.

Example design fragment

The following picture shows a UML static structure diagram of a design fragment. It shows the framework classes involved with creating an Eclipse context menu (right-click menu) and the classes that a developer must implement. The complete DF would also include behavioral specifications. (Apologies for the cropped text in the SVG diagram).

Talk abstract

Frameworks are a valuable way to share designs and implementations on a large scale. Client programmers, however, have difficulty using frameworks. They find it difficult to understand non-local client-framework interactions, design solutions when they do not own the architectural skeleton, gain confidence that they have engaged with the framework correctly, represent their successful engagement with the framework in a way that can be shared with others, ensure their design intent is expressed in their source code, and connect with external files.

A design fragment is a specification of how a client program can use framework resources to accomplish a goal. From the framework, it identifies the minimal set of classes, interfaces, and methods that should be employed. For the client program, it specifies the client-framework interactions that must be implemented. The structure of the client program is specified as roles, where the roles can be filled by an actual client s classes, fields, and methods. A design fragment exists separately from client programs, and can be bound to the client program via annotations in their source code. These annotations express design intent; specifically, that it is the intention of the client programs to interact with the framework as specified by the design fragment.

We can provide pragmatic help for programmers to use frameworks by providing a form of specification, called a design fragment, to describe how a client program can correctly employ a framework and by providing tools to assure conformance between the client program and the design fragments.

I built tools into the Eclipse IDE to demonstrate how design fragments could alleviate the difficulties experienced by client programmers. I performed two case studies on commercial Java frameworks, using demo client programs from the framework authors, and client programs I found on the internet. The first case study, on the Applet framework, yielded a complete catalog of twelve design fragments based on our analysis of fifty-six Applets. The second case study, on the larger Eclipse framework, yielded a partial catalog of fourteen design fragments based on our analysis of more than fifty client programs.

This work provides three primary contributions to software engineering:

  1. It provides a new technique to help programmers use frameworks.
  2. It provides a systematic way to increase code quality. Design fragments provide a means to communicate known-good designs to programmers, and, unlike simple copying of examples, a means of influencing the uses of that design so that revisions can be propagated.
  3. It provides an empirically-based understanding of how clients use frameworks, which aids researchers in choosing research directions and aids framework authors in delivery of new frameworks.

Speaking at SATURN conference, 21 May 2010, in Minneapolis

I am giving a tutorial at the SATURN software architecture conference in Minneapolis in May. The tutorial is on (you guessed it) risk-centric architecture. Here is the abstract:

Architectural design is expensive, so how can you do “just enough” architecture? Today, you must rely upon your intuition. Smaller, simpler projects often thrive with agile processes and evolutionary design. Bigger, complex projects benefit from architectural planning. Between the two is a huge hole —- but little guidance on how to choose “just enough” architecture. This tutorial provides guidance via the Risk-Centric Model, inspired by Attribute Driven Design, Global Analysis, and the Spiral model.

Risks are central in the Risk-Centric Model, so developers:
(1) prioritize the risks they face,
(2) choose appropriate architecture techniques to mitigate those risks, and
(3) re-evaluate remaining risks.

It encourages “just enough” architecture by guiding developers to a prioritized subset of architecture activities. The mappings between risks and corresponding architecture techniques are explicit. Since it is not a full software development process, it can be used inside of a process such as XP or RUP.

Rebecca Wirfs-Brock on Agile Design and Architecture

InfoQ has a nice interview with Rebecca Wirfs-Brock on agile and architecture. From the interview, it is clear she is not a 100% emergent-design proponent, yet she has helpful advice on how design/architecture can fit into agile processes.

Here are some architecture-related quotes of interest:

  • “My words of advice about people who want to think about emergent design is that it is not a replacement for design thinking at the most responsible time, so there is still places at it that you might need to take things and put them aside and think about it and try alternatives. “
  • “Well some people might say that if you are, for example, doing test first development that design happens between the keystrokes as you are planning the next test to write. That’s where it happens, right there. But I take a little bit different view in that I think that there are certain rhythms to design, when I am doing something new I may want to do some design thinking, hit the pause button on writing the test and thinking about structuring stuff that could have me explore some alternatives before I turn to the code. That code is the easy part, so I think there is a role for design and architecture and there are different rhythms for when you do it on Agile projects. “
  • “… a very simple technique of forming a team is sitting down and after they have been presented [a few hundred story cards], instead of just going into the planning game, to sit the developers of the team write where they think are the easy bits the design challenges, write for ten minutes and then share their stories amongst each other…”
  • “On projects that have significant amounts of architecture decisions in an Agile world it’s not always that architecture emerges one story card at a time. I think that the most responsible moment might be taking aside and figuring out some of the hard bits just like the user experience folks these days, user experience designers, are recognizing that there is a cycle of discovery and confirmation and then there is this more regular cycle of doing and filling out of the details once you figured it out. Some of those things need to be done in a side band from the regular beat of all the rhythms of an iterative sprint if you will.”

Nice Dilbert cartoon about training

Dilbert.com

Speaking at IASA Denver, Monday, November 16th

I will be speaking about Risk-Centric Architecture at the joint IASA Denver / Agile Denver meeting on Monday Nov 16th, at 5pm. Location: PPA Event Center (2105 Decatur St Denver, CO 80211-5125).

http://www.iasahome.org/web/denver/home

Here are the slides on risk centric software architecture.

What is a framework?

Kevin Bierhoff, Ciera Jaspan, Jonathan Aldrich, and I submitted a paper to ICSE that tries to describe what frameworks are today, since the academic literature on them is becoming a bit dated. The paper draft is here. The abstract is:

Software frameworks have changed significantly since they were described by researchers more than a decade ago. They have entered mainstream use in most domains of software development, and their structure and interaction mechanisms have evolved. This paper provides a revised definition of frameworks and surveys commonly used frameworks to extract two categorizations: a categorization of the different kinds of frameworks found in the wild and a summary of common interaction mechanisms employed by frameworks. Four popular frameworks are described in detail to illustrate these findings. The paper also discusses unique framework challenges and avenues for future research on frameworks.

Definition of software architecture

I believe there is a difference between architecture and detailed design, but it’s hard to make a clean distinction. The problem is that some small details are architectural while others are not. Unfortunately, this has led some authors to say that architects get to decide what is architecture and what is not, which is unsatisfactory. I am in the process of developing my own definition which explains more. Here’s my best shot:

Risk-centric model of software architecture

It’s been a while since I posted a blog entry because I’ve been head-down working on the book. Here’s a position paper for an OOPSLA workshop that I will be attending. The abstract is:

Developers are faced with a smorgasbord of architecture activities but few models telling them which activities to use. Alternatives include the documentation package model, which advocates a complete architectural description from many perspectives, and the evolutionary design model, which advocates no up-front architectural work. This paper introduces the risk-centric model, inspired by Attribute Driven Design (ADD) and the Spiral model. Risks are central, so developers: (1) prioritize the risks they face, (2) choose appropriate architecture techniques to mitigate those risks, and (3) re-evaluate remaining risks. It encourages “just enough” architecture by guiding developers to a prioritized subset of architecture activities. Like ADD, and unlike the Spiral model, the risk-centric model is not a full software development process and can instead be used inside a process such as XP or RUP.

Here is a draft of the paper: The Risk-Centric Model of Software Architecture

Revised 28 Sept 09: I’ve attached the final version of the longer paper and have put the short (1-page) version inline here.

Syndicate content