Unified Modeling Language (UML)

While most business analyst roles don't explicitly require static modeling expertise, developing a better understanding of static modeling concepts can be a measurable forward step for business analysts seeking to develop new competencies. Such skills can be useful in many aspects of the BA work, from obtaining a better understanding of stakeholders' information needs, to documenting those needs in unambiguous ways and communicating them more effectively to the technical team.

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?
 

There is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example. This article discusses various approaches for dealing with business rules and use cases.
 

Some people use them. Some people don't use them. Some people create them using sophisticated tools. Some use basic drawing programs. As part of the Unified Modeling Language, Use Case diagrams are often the starting point for many software projects. However, questions about Use Case diagrams still linger in the minds of many Business Analysts...

“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

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

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.

• Enterprise Architect – the name itself is completely misleading. EA is not only for people with the title ‘Enterprise Architect’. It’s for the entire project team, from BA’s to Testers and even for Clients.
• User Interface – for developers the user interface of EA is extremely familiar and intuitive. It looks like a lot of the tools they use already. For non-technical users more familiar with tools like Microsoft Office it is somewhat more intimidating.

So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.

UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. Class diagrams are typically used, although not all at once, to: Explore domain concepts in the form of a domain model Analyze requirements in the form of a conceptual/analysis model Depict the detailed de...

UML 2 class diagrams are the mainstay of object-oriented analysis and design. UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain ...

Structure diagrams in general Structure diagrams show the static structure of the system being modeled. focusing on the elements of a system, irrespective of time. Static structure is conveyed by showing the types and their instances in the system. Besides showing system types and their instances, structure diagrams also show at least some of the ...

In the Unified Modeling Language (UML), use cases are visually represented as ellipses. However, in spite of its popularity and size, UML has little of practical use to offer modelers beyond this simple iconic representation. Trying to capture and present requirements using just use case diagrams can often render the otherwise useful technique of u...

This article describes a common pitfall of thinking of analysis and design together as a single process, and highlights the need to treat analysis and design as two separate processes. The author, points out that much of the UML standard, as it is explained today, is described in terms of design artifacts rather than analysis artifacts. Author: Co...

Geri Schneider Winters writes about whether or not you could write alternatives to alternatives in use cases.

There is no actual standard for the formatting of a use case specification, just guidelines and best practices.  Therefore, if using alternatives to alternatives in use cases makes the use case more clear - use it, by any means.

Author: Geri Schneider Winters

When it comes to providing reliable, flexible and efficient object persistence for software systems, today's designers and architects are faced with many choices. From the technological perspective, the choice is usually between pure Object-Oriented, Object-Relational hybrids, pure Relational and custom solutions based on open or proprietary file f...

In this article, the focus shifts to a particular view in the 4+1 Architecture Views, defined by the Rational Unified Process. We will examine how to use Activity Diagrams as "roadmaps" for the Process View, to capture processing flows as a series of steps. We will also discuss several techniques for creating these diagrams and ensuring their effec...