标签：
http://www.infoq.com/articles/agile-software-architecture-sketches-NoUML
If you‘re working in an agile software development team at the moment, take a look around at your environment. Whether it‘s physical or virtual, there‘s likely to be a story wall or Kanban board visualising the work yet to be started, in progress and done. Visualising your software development process is a fantastic way to introduce transparency because anybody can see, at a glance, a high-level snapshot of the current progress. As an industry, we‘ve become pretty adept at visualising our software development process over the past few years although it seems we‘ve forgotten how to visualise the actual software that we‘re building. I‘m not just referring to post-project documentation, this also includes communication during the software development process. Agility is about moving fast and this requires good communication, but it‘s surprising that many teams struggle to effectively communicate the design of their software.
If you look back a few years, structured processes and formal notations provided a reference point for both the software design process and how to communicate the resulting designs. Examples include the Rational Unified Process (RUP), Structured Systems Analysis And Design Method (SSADM), the Unified Modelling Language (UML) and so on. Although the software development industry has moved on in many ways, we seem to have forgotten some of the good things that these older approaches gave us. In today‘s world of agile delivery and lean startups, some software teams have lost the ability to communicate what it is they are building and it‘s no surprise that these teams often seem to lack technical leadership, direction and consistency. If you want to ensure that everybody is contributing to the same end-goal, you need to be able to effectively communicate the vision of what it is you‘re building. And if you want agility and the ability to move fast, you need to be able to communicate that vision efficiently too.
As an industry, we do have the Unified Modelling Language (UML), which is a formal standardised notation for communicating the design of software systems. I do use UML myself, but I only tend to use it sparingly for sketching out any important low-level design aspects of a software system. I don‘t find that UML works well for describing the high-level software architecture of a software system and while it‘s possible to debate this, it‘s often irrelevant because many teams have already thrown out UML or simply don‘t know it. Such teams typically favour informal boxes and lines style sketches instead but often these diagrams don‘t make much sense unless they are accompanied by a detailed narrative, which ultimately slows the team down. Next time somebody presents a software design to you focussed around one or more informal sketches, ask yourself whether they are presenting what‘s on the sketches or whether they are presenting what‘s still in their head.
(Click on the image to enlarge it)
Abandoning UML is all very well but, in the race for agility, many software development teams have lost the ability to communicate visually too. The example NoUML software architecture sketches (above) illustrate a number of typical approaches to communicating software architecture and they suffer from the following types of problems:
Informal boxes and lines sketches can work very well, but there are many pitfalls associated with communicating software designs in this way. My approach is to use a small collection of simple diagrams that each show a different part of the same overall story. In order to do this though, you need to agree on a simple way to think about the software system that you‘re building. Assuming an object oriented programming language, the way that I like to think about a software system is as follows ... a software system is made up of a number of containers, which themselves are made up of a number of components, which in turn are implemented by one or more classes. It‘s a simple hierarchy of logical building blocks that can be used to model most of the software systems that I‘ve encountered.
By using this set of abstractions to think about a software system, we can now draw a number of simple boxes and lines sketches to summarise the static structure of that software system as follows (you can see some examples on Flickr):
(Click on the image to enlarge it)
A single diagram can quickly become cluttered and confused, but a collection of simple diagrams allows you to easily present the software from a number of different levels of abstraction. And this is an important point because it‘s not just software developers within the team that need information about the software. There are other stakeholders and consumers too; ranging from non-technical domain experts, testers and management through to technical staff in operations and support functions. For example, a diagram showing the containers is particularly useful for people like operations and support staff that want some technical information about your software system, but don‘t necessarily need to know anything about the inner workings.
This simple sketching approach works for me and many of the software teams that I work with, but it‘s about about providing some organisational ideas and guidelines rather than creating a prescriptive standard. The goal here is to help teams communicate their software designs in an effective and efficient way rather than creating another comprehensive modelling notation. It‘s worth reiterating that informal boxes and lines sketches provide flexibility at the expense of diagram consistency because you‘re creating your own notation rather than using a standard like UML. My advice here is to be conscious of colour-coding, line style, shapes, etc and let a set of consistent notations evolve naturally within your team. Including a simple key/legend on each diagram to explain the notation will help too.
There seems to be a common misconception that "architecture diagrams" must only present a high-level conceptual view of the world, so it‘s not surprising that software developers often regard them as pointless. In the same way that software architecture should be about coding, coaching and collaboration rather than ivory towers, software architecture diagrams should be grounded in reality too. Including technology choices (or options) is a usually a step in the right direction and will help prevent diagrams looking like an ivory tower architecture where a bunch of conceptual components magically collaborate to form an end-to-end software system.
As a final point, Grady Booch has a great explanation of the difference between architecture and design where he says that architecture represents the "significant decisions", where significance is measured by cost of change. The context, containers and components diagrams show what I consider to be the significant structural elements of a software system. Therefore, in addition to helping teams with effective and efficient communication, adopting this approach to diagramming can also help software teams that struggle with either doing too much or too little up front design. Starting with a blank sheet of paper, many software systems can be designed and illustrated down to high-level components in a number of hours or days rather than weeks or months. Illustrating the design of your software can be a quick and easy task that, when done well, can really help to introduce technical leadership and instil a sense of a shared technical vision that the whole team can buy into. Sketching should be a skill in every software developer‘s toolbox. It‘s a great way to visualise a solution and communicate it quickly plus it paves the way for collaborative design and collective code ownership.
Simon Brown lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of Coding the Architecture (a website about pragmatic, hands-on software architecture) and the author of Software Architecture for Developers (an e-book that is being published incrementally through Leanpub). He still writes code too. Simon can be found on Twitter at @simonbrown.
Agile software architecture design document style..( sketches and no UMLs)
标签：
原文地址：http://www.cnblogs.com/feika/p/4466293.html
