The problem with many Unified Modeling Language (UML) educational texts is that they present the various concepts each in isolation; so you see a use case diagram for one problem domain, a class diagram for an entirely different problem domain, and you never get to see the important traceability between the diagrams.
In this case study we aim to put it right by working through a single problem from use cases and activity diagrams, through sequence diagrams and state diagrams, to class diagrams and component diagrams. We have arranged the case study as three distinct perspectives or aspects as follows.
The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements.
Unified Modeling Language (UML) Activity Diagrams are rather like traditional flowcharts that may be used to describe the steps required to enact high level business processes or low level algorithms. From the software analyst’s perspective these diagrams are most useful for representing business processes, so this will be our focus here. Whereas activity diagrams are often relegated to the final chapters of the UML text books, I prefer to present them up-front as the logical starting point for any UML analysis and design endeavor.
An activity diagram is a type of flowchart that is part of the UML (Unified Modeling Language) standard. Its purpose is to enable analysts to present a concrete, easy-to-follow visual of the workflow of a business use case.
Almost every business analyst uses diagramming software in their arsenal of analysis tools. According to BABOK 2.0, an analyst’s traditional purpose in using diagramming tools is to “support the rapid drawing and documentation of a model, typically by providing a set of templates for a particular notation which are used to develop diagrams based on it.” Diagrams not only make requirements clearer to stakeholders through modeling, they help clarify an analyst’s thinking on a project through the process of their very creation.
As part of the Unified Modeling Language, Activity diagrams are often utilized for many software projects. However, a few questions about Activity diagrams linger in the minds of many Business Analysts, such as: Who is really using them? What kind of projects are they being used on? Why are people not using them? How are people using them? Are they providing any benefit?
“Where does UML fit?” is a common question among new (and not so new!) business analysts. We all know that the M stands for modelling but beyond this, perceptions start to differ. In its current form (V2.0) UML consists of 13 diagram types all of which provide a different view of a system.
In this article we’ll take a brief look at which of the 13 diagrams are of most relevance for us and how they fit together...
Author: Jan Kusiak
Also called abstract or business modelling, essential modelling can be an extremely valuable tool for the business analyst. Instead of modelling how things are done (the current system), or how they might be done (a proposed system), we model what is done, or what might be done. For example the purpose of a Customer Service Department is to provide customers with a level of service they expect (or the company defines). Things like call centres and customer relationship management systems are the how of customer service.
This switch in thinking is not always easy as we have to ignore the very practical matters of procedures, methods, people, technology etc. The more involved we are in the system that we are looking at, the more difficult it may be to look at things conceptually. We have to look at what business objective we are trying to achieve. The business analyst who can do this - and explain it to clients and management - becomes a most valuable asset to the business.
Author: Derrick Brown
Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?
Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.
Author: Jan Kusiak
Workflow analysis is an application of systems analysis to examine how the applications and tasks performed in an office or practice interact with each other, as well as with the staff performing them. Workflow software applies these analyses to make sure that the right staff member gets assigned the right task, along with the appropriate documents and data files.
As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems (www.sparxsystems.com) for a number of years. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. While I’ve had some success I must admit it’s been an uphill battle. I suspect this is partly because EA is often seen as a technical person’s tool. And that’s not altogether surprising.
So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.
Author: Andrew Tokeley, Development Manager, Intergen Ltd
You can read Andrew's blog at: http://andrewtokeley.net
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us