jump to navigation

What is UML? What is Unified Modeling Language? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , , , , , , , ,
add a comment
A collage of UML diagrams including use case d...

A collage of UML diagrams including use case diagram, class diagram, activity diagrams, sequence diagrams, deployment diagram,component diagrams, composite structure diagram, package diagrams. (Photo credit: Wikipedia)

 

What is UML?

UML is an acronym for Unified Modeling Language. UML is widely accepted as the de facto standard description language for the specification and design of object-oriented software systems. UML is a family of “languages”, or diagram types, that attempt to bring together the “best in breed” software specification techniques for describing software systems. Users and practicioners of UML can choose which members of the family are the most suitable for their application domain.

Personally, I have become associated with UML through my years and years of specifying software products. Several of the UML diagram types that I will discuss below are among my primary tools for communicating application and system requirements and software designs to programmers.

I do not advocate, nor do I personally practice, an over-attachment to UML. Like many of these project management and requirements management techniques, there is a time and a place for the proper introduction of these types of UML artifacts into the software development process. Programmers may be unfamiliar with the UML diagram types and symbology, and so if you are a business analyst, project, program or product manager, and you are using these types of project deliverables with a new staff of engineers, be prepared to explain the UML diagram type you are using, keep the introductions down to one or two different new UML “Languages”, or diagram types, at a time.

I also recommend that if you insert UML diagrams into your functional specification documents, and I recommend that if you have invested the time to properly prepare UML diagrams that you do leverage them into your spec docs, make sure that you include an explanatory prose component into your accompanying functional specification document’s text.

There are nine different types of UML languages, or diagram types:

1. Use Case.

2. Sequence.

3. Collaboration.

4. Statechart.

5. Activity.

6. Class.

7. Object.

8. Component.

9. Deployment.

Five of these diagram types render behavioral views, the use case, sequence, collaboration, statechart and activity diagrams, while the remaining four diagram types are concerned with architectural or static aspects of the software design.

 

How does UML help in specifying a software design?

UML is a graphical language that is based on the premise that any software system can be described in terms of interacting business entities and that various aspects of these entities and their interactions, can be described visually using one or more of the above nine types of UML diagrams.

Use Case diagrams represent and document the dialog between external (to the system under discussion, as in an embedded system) actors and the system.

Sequence and collaboration diagrams describe interactions between objects.

Activity diagrams illustrate the flow of control between objects.

Statecharts represent the internal dynamics of active objects.

 

What is UML 2.0?

UML 2.0 is a revision to Unified Modeling Language that incorporates several improvements to UML. UML 2.0 is only just now beginning to supplant UML as the de facto standard.

A shorthand description of UML 2.0 is that it is designed for more rigor of specification, and it can sometimes be too much, or too much of a fine-grained distinction to bandy about when in an actual day-to-day, working software development environment. You are very likely to be working with only a subset of the UML languages, or diagram types, I outlined above at any one given point in the development project.

UML 2.0, when the diagrams are laid out in a software program such as VisualUML or others, can actually be used to generate working object code. If the business analysts have developed their proficiency enough with UML diagramming software, they can actually construct and output from these programs working java (or other programming language) object code.

In order to obtain this level of integration with application programmers, UML 2.0 had to have more access to a more robust and constrained specification language. The improvements to UML 2.0 include:

1. New base classes that provide the foundation for UML modeling constructs.

2. Object constraint language, a formal method that canbe used to better describe object interactions.

3. An improved diagram meta-model that allows users to model systems from four viewpoints:

a. Static models (e.g., class diagrams)

b. Interaction (e.g., using sequence diagrams)

c. Activity (i.e., to describe the flow of activities within a system)

d. State (i.e., to create FSMs, or Finite State Machines, using state charts)

UML has always been used to not only specify software systems for systems and application programming, but also specification for embedded systems as well. This emphasis on the notion of time and state is evident in the way that sequence diagrams are implemented in UML, and indicates the special considerations that were undertaken to support embedded systems design in the original conception of UML.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests? October 3, 2010

Posted by HubTechInsider in Agile Software Development, Definitions, Project Management.
Tags: , , , , , , , , , , , , , , , , ,
add a comment
user stories image

Image via Wikimedia

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests?

User Stories are short conversational texts that are used for initial requirements discovery and project planning. User stories are widely used in conjunction with agile software development project management methodologies for Release Planning and definition of User Acceptance Criteria for software development projects.

User Goals, stated in the form of User Stories, are more closely aligned with Business Priorities than software development Tasks and so it is the User Story format which prevails in written statements of User Acceptance Criteria.

An Agile Project Team is typically oriented to completing and delivering User-valued Features rather than on completing isolated development Tasks.These development Tasks eventually combine into a User-valued Feature).

User Goals are not the same things as software development Tasks. A User Goal is an end condition, whereas a development Task is an intermediate process needed to achieve this User Goal. To help illustrate this point, here are two example scenarios:

1. If my User Goal is to laze in my hammock reading the Sunday Boston Globe newspaper, I first have to mow the lawn. My Task is mowing; My Goal is resting. If I was able to recruit someone else to mow the lawn, I could achieve my Goal without having to do the mowing, the Task.

2. Tasks change as implementation technology or development approaches change, but Goals have the pleasant property of remaining stable on software development projects. For example, if I am a hypothetical User traveling from Boston to San Francisco, my User Goals for the trip might include Speed, Comfort and Safety. Heading for California on this proposed trip in 1850, I would have made the journey in a high technology Conestoga wagon for Speed and Comfort, and I would have brought along a Winchester rifle for Safety. However, making the same trip in 2010, with the same User Goals, I would now make the journey in a new Boeing 777 for updated Speed and Comfort and for Safety’s sake I would now leave the Winchester rifle at home.

· My User Goals remained unchanged, however the Tasks have changed so much that they are now seemingly in direct opposition. User Goals are steady, software development Tasks as stated on SOWs (Statements Of Work) are transient.

· Designing User Acceptance Criteria around software development Tasks rarely suits, but User Acceptance Criteria based on User Goals always does.

A User Story is a brief description of functionality as viewed by a User or Customer of the System. User Stories are free-form, and there is no mandatory syntax. However, it can be useful to think of a User Story as generally fitting this form:

“As a <type of User>, I want <Capability> so that <Business Value>”.

Using this template as an example, we might have a User Story like this one:

“As a Store Manager, I want to search for a Service Ticket by Store so that I can find the right Service Ticket quickly”.

User stories form the basis of User Acceptance Testing. Acceptance tests can be created to verify that the User Story has been correctly implemented.

User Story Card

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

%d bloggers like this: