About UML Edit
UML is a modelling standard primarily for software development, but can also be used for other conceptual models such as describing job roles, business processes and organisation functions.
It was developed in the early to mid-nineties by staff from several large software firms including IBM and Hewlett Packard. The standards are managed by the OMG. UML is an ISO specification.
UML was developed as an industry-wide standard so that there was an agreed language for documenting business requirements that could be understood across companies. Imagine the problems vendors face when dealing with a company that defines its requirements in an unfamiliar language.
For business analysts these days UML usually means being able to represent requirements with Use Cases, Class Diagrams, or State Diagrams, but is more than just a way of drawing a process, function or relationship. It’s also conventions around the whole of a document, from common labels such as font type to standards for embedding one diagram into another.
Reading the standards can be heavy going, but is recommended. In practice the BA doesn’t need to know everything in the standards, but reading them helps you know what you need to know.
For a business analyst, the most important part of understanding the UML is in understanding the diagram tools, and when and how to best use them. The diagrams are listed below (and should eventually become links to information pages.) They are broken into categories.
- Activity diagram
- State Machine diagram
- Use case diagram[[File:Media:Example.jpgInsert non-formatted text here]]
- Communication diagram
- Interaction overview diagram
- Sequence diagram
- UML Timing Diagram
- Class diagram
- Component diagram
- Composite structure diagram
- Deployment diagram
- Object diagram
- Package diagram
The important thing to remember when applying your UML skills is that you are writing for multiple audiences, some of which will be familiar with UML and some who aren’t.
Additionally, even though the UML standards are reasonably stable they are still not wholly unambiguous. Any communication relies on a certain level of assumptions and skills, and you are best served by remembering that few of the people you deal with at work are working from the same world view, assumptions and level of understanding of these standards as you.
The best solutions are to not rely only upon written documents and to have regular feedback loops built into any handover of requirements to designers and developers.
OMG maintains a homepage for UML here; www.uml.org