A system not simple enough to understand can't work

In the 1960s, a programmer could translate requirements more or less directly into code that could be reviewed, verified, and approved in a desk check by a colleague knowledgeable in the field. As Trygve Reenskaug (inventor of Model-View-Controller) notes, we lost this ability in the 1980s. Why? Because of object-oriented programming. Objects have many advantages as discussed in Module 2, but they lose the ability to reason about what the system does by looking at the code. This means that desk checks have less value today than they did in the FORTRAN days and that we have resorted to testing for quality assurance. Yet testing cannot reason about the absence of bugs in code; it can detect only their presence. We need to do better.

Further, Agile has taken us away from requirements to User Stories that are a promise for a future discussion between a programmer and a customer. The tester never isn't mentioned in this perspective, and the fact that we now rely so heavily on testing for quality should be reason to worry. The fact that most Agile techniques put test writing in the hands of developers is even more reason to worry, and numerous formal studies have shown that TDD does not and cannot live up to its claims of supporting the architectural desiderata of decoupled and cohesive objects. 

In this course, we look at the process constructs for managing requirements in the software design and coding phase. Given that you have a base architecture or any base platform of pre-existing code, where do user scenarios fit? They are not objects; yet, in a good OO world, they are not functions. And they must be managed in a way that sustains a good interface, going beyond the Agile value of "working software" to "usable software." Lightweight Use Cases as advocated by Alistair Cockburn, co-signer of the Agile Manifesto, come to bear as a major enabler in customer collaboration and as a way to deal with change and to raise the chances of delivering working software. Again, minimizing the number of methodological artifacts and maximizing the expression of design concerns directly in code, these techniques contribute to high feature velocity. Using techniques developed by Trygve Reenskaug and popularized by the course's instructor, this course shows how to retain the structure of requirements directly in object-oriented code. The approach depends on a four-pronged approach to design that uses not only classes and objects, but also roles (and their implementation as interfaces), as well as context definitions that map roles onto objects at the beginning of every Use Case.

Target audience:

• Designers;
• Programmers;
• System and software architects;
• White-box /clear-box testers;
• Line managers;
• User experience folks (there is an important and surprising relationship between HCI and architecture in an Agile system);
• Domain experts;
• System Engineers;
• To a lesser degree, ScrumMasters and Product Owners (wouldn't it be nice to know where architectural PBIs come from and where they go?)

Prerequisites:

• Familiarity with Agile vocabulary;
• At least two years of professional experience in some domain;
• Competence in a modern mainstream programming language (Java, C#, or C++)
• A helpful (but not absolutely necessary) prerequisite is the Lean Domain Architecture course.
  

You'll learn:

• Trygve Reenskaug's new framework for capturing requirements in code: Data, Context and Interaction (DCI)
• Why User Stories are not enough, and what you need to understand the important relationships between requirements
• When stories and use cases are the wrong tool
  
• Why there are two different kinds of architecture for two different kinds of end user interaction: atomic interactions, and sequences of tasks in context
• How to implement those architectures 
• How to reduce documentation needs by increasing code intentionality
  
• How to package Use Case requirements into code that is as readable as the Use Case, instead of being spread across system classes

Outline

1. Introduction
2.  The MVC-U Four-Layer Architecture
1. Business Objects and Domain Modeling
2. Business Objects as Tools
3. Tools and MVC
   
3. Architecture in Process
1.  Incremental Architectural Slices
2. How much architecture, and when?
   
4. Capturing functionality in Code: Trygve Reenskaug's DCI architecture
1. Code intentionality
2. A model from the perspective of Aspects
3. Class and object definitions of weavers
4. Role definitions
5. Capturing Use Cases
6. Methodful roles
7. Tieing it all together 
5. Summary and Wrapup