…and the Oscar Goes To – Primary and Supporting Actors

Alex continues with his series of posts on use cases and looks at the Colin Firth's and the Geoffrey Rush's of the use case world...

Previously we discussed the identification of actors that will interact with the system under development. The next activity to be performed in the development of a use case model is to categorise those actors. Actors are usually divided into what we refer to as primary and supporting actors.

A primary actor is a user who will use the system to achieve a goal.  The needs of the primary actors drive the behaviour or functionality represented in the use case.  If the primary actor roles or needs change, then it is likely that significant modification to the system will be required.

The primary actor is often, but not always, the actor who triggers the use case.  Usually, the use case starts because the primary actor sends a message to the system, pushes a button or in some way triggers the story.  There are two common situations in which the initiator is not the primary actor:

• The initiator starts the use case on behalf of another actor
• The use case is triggered by time

 For an individual use case, any actor that is not primary will become what is known as a supporting actor.

Supporting actors provide a service in the use case and would not exist if there were no primary actors.  Supporting actors typically participate in the use case to support creating value and achieving a goal for the benefit of the primary actors.

Supporting actors are used to identify external interfaces the system will use and the protocols that cross the interfaces.  This feeds the other requirements, such as data formats and external interface descriptions.

Remember that an actor may be primary in one use case but supporting for another so it is not possible to universally classify the actor as its role may differ between use cases.

The identification of primary and supporting actors is a key step to discovering what our use cases will be as the use cases represent goals that the primary actors wish to use the system to achieve.

Nokia's Smart Move

 Following the announcement of the Nokia - Microsoft alliance, Fiona looks at what makes a technology company successful in a competitive marketplace...

On January 15^th Nokia announced it was closing its factory in Bochum, Germany. The announcement was closely followed by a leaked “burning platform” memo which depicted a grim picture of long term business prospects for Nokia. The memo was a wakeup call to suggest Nokia was about to reinvent its approach to current technologies. It was no surprise then when the statement came that Microsoft and Nokia were to form a strategic alliance, with Nokia replacing their existing Symbian phone platform with Windows Phone 7 platform. But the burning question is whether this is too little, too late to recapture the market share of smartphones, which has been lost to a new generation of technology pioneered by the Apple iPhone, Rims Blackberry and Google’s Android platform.

The smartphone market is complex and challenging predominantly because we are in unchartered waters, the rules have not yet been established…in fact there are no rules. Google understood and embraced this with the “android market” an online store where apps are downloaded. Developers writing in Java are able to utilise Java libraries created by Google. However, Google went further than this and published the Android code through an Apache license. Within one and a half years Android had captured a third of the smartphone market share.

Apple also understood that to be ahead in the smartphone market it wasn’t necessary to break the rules but to think beyond the rules completely, which it did with the introduction of the iPhone. The iPhone became a complete solution for moving data around so easily in some cases it was preferable to a laptop. The iPhone permitted unique levels of communication and internet access. All this whilst being portable enough to fit in your pocket and look appealing and chic to potential users. Just as the iPod revolutionised the way we listen to music, the iPhone changed the way we entertain ourselves. 

Here in the Objektum office we understand the importance of developing new ideas. By encouraging an energetic and vibrant workplace we are able to produce innovative software design solutions to keep ahead of the game. Most recently, we have produced the Lecacy Bridge which has the capacity to transform and modernise the traditional and arduous methods of code generation. 

 

The question remains will Nokia and Microsoft be able to clasp this level of creative and dynamic thinking. Or is it in fact a culture of rigid, conventional thought which has allowed the two companies to merge together successfully? Whatever the outcome the smartphone world just got interesting.

UML Survey: How is UML used?

Our friend across the pond, Bob Maksimchuk is a Principal Consultant at Project Pragmatics conducted a simple survey into how UML was being used. We found it fascinating and it generated some interesting discussion. Have a read and let us know your thoughts!

  

The UML Survey Results Are In

In April, I invited one and all to participate in a simple survey to see how they are actually using the UML on projects.  Is it really mainstreamed?  Is it still in the adoption phase?  Or is it in decline?  The survey is now closed.  Thanks to those who participated.  Here are the results.

The first question asked how UML was used on projects.  (See results in Figure 1.)

 

Figure 1

The results indicate that the use of UML is very strong in the early part of the project lifecycle.  But once design is elaborated enough, it seems that’s it…on to code.

Second, I asked what diagrams were typically used.  (See results in Figure 2.)

 

Figure 2

These results seem to support the results of the first question, with use case and class diagrams being heavily used, followed by activity diagrams.  I find it interesting that sequence diagrams are used only slightly more than state machine diagrams!  State machine diagrams were used lightly in the past, specifically by those who build things that are time / state critical (medical devices, aerospace, etc.).  Maybe their increasing popularity is tied to the renewed interest in system engineering that I am seeing in the marketplace.

Last but not least, I asked people to rank their organization’s UML expertise.  (See results in Figure 3).   

                    

Figure 3

I find it very interesting that after all these years, with over 3000 UML books having been written, all the webinars, conferences, and so forth, that nearly half of the people still know little or are still learning about the UML. 

So what do you conclude from these results?

  

Our Technical Director Derek took 5 minutes out of his day to give us his opinion on this survey:

 

This is an interesting survey and I agree that your conclusion about adoption of UML in the early phase of the lifecycle seems accurate.    Given the result, I am surprised that class diagrams are one of the most commonly used notations, I can only assume the results show class diagrams being used during the analysis phase.  Maybe the survey should be repeated with an additional question about where in the lifecycle the elements of UML are being employed.

It would appear that UML is not being fully adopted during the detailed design and implementation phase.  I wonder why? 

At Objektum we find significant benefit in terms of time and cost, when adopting UML to drive our code generation.  In fact all our development uses UML and code generation techniques which improve our productivity, quality and overall maintainability.  I wonder if the reason that others are not adopting a similar strategy is owing to a lack of training in code engineering as well as misconceptions about the maturity of modern UML tools.

I am confident that if other developers adopted an approach similar to our own, we would see a significant shift in the survey result.  I would be interested in hearing from others on the use of code generation, particularly those who have not had a positive experience.

 What do you make of the survey? 

Bob Maksimchuk is a Principal Consultant at Project Pragmatics, LLC.,  specializing in helping software development teams GET WORK DONE by introducing: PRACTICAL techniques, STREAMLINED process, and FOCUSED training and mentoring, all specific to your team's needs.  Visit now at http://www.ProjectPragmatics.com.  All rights reserved © 2009-20011 Project Pragmatics, LLC.

.

Not All Actors Live in Hollywood – Refining the System Boundary

It's the awards season and we're looking forward to seeing what happens at the BAFTAs on Sunday. But in this post we're not talking about Mr. Firth or Miss. Portman, we're talking about use case actors as Alex continues with his interesting series on use cases...

Before building a new system it is essential to clearly define its boundary.  This means understanding what sits within the systems, that we must develop, and what sits outside, that we must interface with.

Given any requirement specification, it is usually easier to identify what sits outside the system boundary and use that to determine how the system responds when it is stimulated from its environment, or how the system is going to be used.

When an event occurs, that causes an interaction between the system and its environment; entities within that environment are involved.  Some of the entities initiate the event; others interact with the system as a result of the event.  In use case modelling, these entities are known as actors.

An actor is an entity that interacts with the system for the purpose of achieving a goal or completing an event.  Actors are not necessarily human users of the system; they can be other systems or even external forces that act upon the system (although the latter is unlikely to be a consideration when modelling software).

When looking for actors, review the following sources of information for potential actors of the system:

•       Existing context diagrams and other models that describe the boundary of the system with its environment.  Look for external entities that have interaction with the system

•       Written specifications and other project documentation, such as records about meetings with users, these help identify users who may be potential actors

•       Training guides and user manuals.  These manuals are normally directed at roles representing users and therefore potential actors.

Each actor needs a descriptive name that indicates the role it plays and a brief description that is one or two sentences long.

The description should include:

•       What the actor represents

•       Information about the actor’s capability, functionality or skills

•       Why the actor is needed

•       What interest the actor has in the system

Many use case modellers forgo the description of actors and merely give them names which, in the case of systems, is often just the name of the system itself. Remember, when you document your use cases you will detail specific interactions with the actors and have little chance of getting it right if you don’t fully understand the actor to begin with.

Actors are a means of identifying and documenting the users of the system so that the users’ needs can be modelled, validated and implemented.  The goal is to ensure that the system ultimately meet their needs.

Alex

Social Network for Model Driven Software Development

Cat is pretty clued up about what is happening on the World Wide Web and often points us in the direction of interesting blogs and online networks so we thought we would share what she tells us with you...

The Model Driven Software Network

Created on Ning (a site which lets you create your own social networks), The Model Driven Software Network is a vibrant community of those interested in, yes you’ve guessed it, Model Driven Software Development and we were amazed by the number people who were using it. Social networks can sink or swim as it is dependent on the users’ contributions. This one seems to be flying. 

As creator Mark Dalgarno puts on the site:

The Model Driven Software Network is for anyone who's interested in Model Driven Software Development (MDSD).

You could be a practitioner, a researcher or just plain curious about what MDSD is about and how to get started.

The topics you'll find discussed here relate to the process, practice, technology or people issues involved in developing with models. This could include:

• Domain-Specific Languages
• Domain-Specific Modelling
• Model-Driven Architecture
• Executable UML
• Eclipse Modelling Tools
• Code Generation and Model Interpretation

Sign up and explore it for yourself if it sounds like something you’d be interested in and don’t forget, you get out what you put in. Our readership is growing everyday (way above what we ever expected!) so comment on this post and let us know what you have found online that might be of interest to other software and systems engineers…