This course shows you how to visualize and communicate architecture using pictures, which is essential in an Agile environment. It takes you through the design process, covering everything from story cards to representing complex activity flows.
You can't program effectively (or talk about your program effectively) without pictures, particularly in an Agile environment, where communication is central. This course, Picturing Architecture: UML (The Good Bits) and More, shows you how to communicate software concepts and structure using pictures or equivalent. You'll see how to represent stories and how to organize them effectively using index cards. You'll learn how to represent and organize stories and take them through the design process. You'll also learn how to represent complex activity flows, translate those flows into a messaging system, organize and represent the classes in your system, and represent the behavior of an object when that behavior changes with state. You'll learn about Story Cards, Story Maps, CRC-card walls (a system developed by the author), and a version of UML that's optimized for the whiteboard and adapted to modern Agile practice. By the end of this course, you'll be able to use pictures to communicate your program effectively within the Agile environment to others.
Allen is an internationally recognized trainer, agile-process consultant,
speaker, and author.
He specializes in Lean/Agile infusion and tuning,
software architecture, and web-application programming
using open-source toolsets.
Allen's worn every hat from grunt programmer to CTO.
He's built compilers, operating systems, massively scalable web
applications, and mobile apps.
He's written a dozen books and hundreds of magazine articles on practical
programming topics, and currently blogs for Dr. Dobb's Journal
Allen speaks regularly at conferences, worldwide, and works for
both startups and Fortune-50 companies.
Contact him at: [email protected], or on Twitter at @allenholub.
Introduction: Designing in an Agile World Hi, my name is Allen Holub and this class is called Picturing Architecture. Now the reason I put it that way is what this class really is about is communication. Unless you're working in a cave on a mountain top, you can't really program effectively unless you can talk to other people about what you're doing. And when you're doing that, talking that is, looking at the code just doesn't cut it. The code is just too complex, and the overall structure just isn't clear enough. So my goal in this class is to provide you with an effective visual tool kit that you can use to talk about the structure and the behavior of your code, about its architecture in other words. I'll talk about how to do that using pictures mostly, but I'll also talk about using index cards and other aids to visualization. UML is also going to be a big part of this discussion, but we'll look at a modern take on UML tailored to the way that we work now days. In fact, one of the biggest changes between now and when UML was conceived is that now days we do most of our design work standing at a whiteboard talking to other people, not inside a computerized design tool. So instead of talking about a version of UML that's optimized for a machine to do the drawing, we'll talk about one that's better when you're standing at a white board. Over the course of this class, I'll take you through the process of designing a small blogging system starting with stories and ending up with something very close to the code. That way, you can see how everything ties together at every stage of the design process. So, let's get started.
Representing State-based Behavior There's one more diagram that I want to talk about and that is the state diagram. Sometimes an object will do very different things depending on what you did with it in the past. For example, a database connection might treat a read request very differently if it's in the open state than it would if it was in the closed state. In our blogging system a comment behaves very differently when it's in the pending or unapproved state than it will when it finally moves to the approved state. And the behavior will change again if the comment is rejected and it's moved into the archived state. Now state-based behavior is usually represented by a so-called State Machine. In hardware, there are two kinds of state machines and it's worth thinking about them. In a Mealy machine, named after George Mealy, the output values are controlled by both the current state and the inputs. In a Moore machine, named after Edward, not Gordon Moore, the outputs are determined solely by its state. Now we can look at this as a kind of graph, each state could be represented by a circle, and a transition from one state to another can be shown with a line. In a Moore machine, there's some kind of activity associated with being in the state, no matter how you got there. In a Mealy machine, the activity is associated with the transition to the state. So you could have two transitions into a state for example, and the activities associated with those transitions could be different. If you think of this in terms of software, in a Moore machine, there will probably be a single method or a table somewhere that tells you what to do when you're in a particular state. In a Mealy machine, the received message will both decide what the next state is, and decide what action to perform when transitioning to that state. If you're familiar with the Gang of Four design patterns, this is exactly the problem that the state pattern is meant to solve. Now in hardware, we've got to pick one or the other of these, we can't have both at the same time, in software we can have both at the same time. So we need some kind of notation that will handle that problem and UML does a reasonably good job of that.