I am often asked about UML or Unified Modeling Language. A lot of young developers don't seem to be using UML or any kind of modeling language when doing development.
I think this is a big mistake.
When we go back to the roots of Agile, which I consider to be extreme programming, we see the issue of quality elevated to the highest level of importance. Quality is very important and low quality can affect new feature development, team morale, and drown an organization in bug triage, reporting, fixing, regressing, documenting and forward fixing.
We know that unit testing and even better, test driven development, can drive the quality higher. But what does that have to do with UML?
The best way to have much better software is to have better design. Having a better design is the product of communication with your other team members about design choices. A great language for that communication is UML.
Text or just word-based communication about design is slow and subject to interpretation errors. Most folks find communication about patterns, which are really just examples of good designs for common problems, much easier with UML. (This is why we use UML in my Emergent Design Class.)
When I talk about UML, I do not mean UML models that are so specified that code can be
generated directly from them. I mean 'blackboard UML'. Usually this is the class diagram, the sequence diagram and the interaction diagram - just three of the possible diagrams in UML. Other diagrams can be used in specific situations. State and component diagrams are seen as well. I would say that if you only use class diagrams, you have achieved a significant percentage of the value. For a simple introduction to the class diagram go here. The book on UML I like best is UML Distilled by Martin Fowler.
High performing Agile teams tend to have visual things around their work areas or on their wikis. In particular I see UML on white boards or on wiki pages to show high-level designs of areas of their work. People have good discussions around these. And make changes as the project unfolds. Product Owners use UML to capture Domain Models.
I believe that every person (or at least every developer) on an agile team should be able to use simple (blackboard) UML to talk about their work. And everyone should be able to diagram the high level abstractions in the team’s code - the architecture as it were. What do you think?
the focus is on the development of business application software not other types such as embedded software or system software. Yes, many of the artifacts could and should be applied in these other domains but the chart reflects a methodology geared for the development of modern-day business software.The principles Multiple Models indicates that you potentially need a wide range of models available to you, Know Your Models advises that you need to understand the strengths and weaknesses of each technique to apply them appropriately, and Content is More Important Than Representation implies that many artifacts have alternates that may be applicable for your situation.
Posted by: 128gb usb drive | 12/15/2009 at 02:07 AM
I think You do a great job. Thanks
http://www.pdfspirit.com/tabela-irs-2010
Posted by: Ioannis | 07/12/2010 at 05:55 AM