Unified Modeling Language (UML)

So how do you handle CRUD in your use cases? Please don’t confuse CRUD with CRAP in your use cases. That’s a lot harder to deal with and requires a conversation with your subject matter experts (SMEs). CRUD is an acronym for Create, Read, Update and Delete. It describes the lifecycle in the maintenance of system data, whether that data is stored in a database or is file based data stored in a document management system like SharePoint.

In the world of software development Use Cases are one of many very powerful techniques often used these days.  Use cases describe how a person or a system interacts with the solution being modeled/built to achieve a goal. Basically, it’s a step by step explanation of what a user can do and how the solution must respond.

As any other business analysis technique, use cases have their advantages and disadvantages. One of the main disadvantages of use cases is that this technique is not graphical – a use case diagram is but use case descriptions are not, and use case descriptions really lack of visualization especially if there are multiple alternative flows and exception flows that branch out and then loop back into the main one.

Visual analysis models provide a powerful set of tools that let business analysts depict system information at various levels of abstraction. These models serve as an aid to understanding, as well as an aid to communicating. Alas, I fear that modeling is somewhat of a neglected practice. I believe modeling is an essential skill every BA should master. Here’s why.

Several years ago I was looking for examples using the generalization / specialization technique with use cases. They are not easier to find. And they are typically limited to a use case diagram like the two below. This article provides examples of both the diagrams and the scenarios for a future gas station business.

Strategists, architects, process experts, software developers, data managers and other professionals involved in changing the enterprise often put substantial effort in creating all kinds of useful models of their designs. In many cases, such business models, enterprise architecture models, business process models, software models, or data models are only used to specify some design, i.e. to describe what should be built. 
But there is much more value to be had from these models, by using powerful analysis techniques to elicit new insights. In the following pages I will cover 7 of these analyses, discussing the business outcomes you can achieve with their help.

State Models include two RML Data models (State Tables and State Diagrams) that show the transition of an object through various states or statuses, including which transitions are valid and what triggers an object to transition state. A state is a short-form description of a stage in a data object’s life that influences the behavior of the system.

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 UML Component Diagram along with the complementary UML Deployment Diagram shows how a software solution will be delivered and deployed in the form of interconnected components that interoperate via well-defined interfaces. You can think of this as analogous to how electronic components are wired together, and in this context you should consider that any one component may be replaced by a different but compatible component with no adverse effect.

The UML State Diagram, sometimes known as the Statechart Diagram or Static Transition Diagram, defines the entire lifecycle of a business entity or object in terms of the messages it receives and the responses it makes from the moment of creation until the moment of destruction.

A UML Use Case is an atomic system function with a well-defined and standardized specification, which is performed by or o behalf of a system user or ‘actor’. This article describes how a UML Use Case Specification should be written.

A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing textual information to a specification which a developer can use?

This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels.

The UML Class Diagram, sometimes known as the Static Structure Diagram, shows the dependencies and persistent associations between object classes.

A UML Sequence Diagram is used most commonly to show the realization of a use case in terms of interactions between business entities or software objects. This diagram therefore helps with the transition from non-object oriented activity diagrams and use case diagrams to the object-oriented paradigm of modern software development.