Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Useful UML Modeling: Zeus, the First Software Analyst

By splitting compound roles your models will provide a clearer and more representative picture of who does what and when.


advertisement
According to Plato, humans were originally created with four arms, four legs, and two heads.  These were very powerful beings that eventually rebelled against the Greek gods.  The answer Zeus came up with was to split the humans in two, male and female, two arms, two legs, and one head each.  In this way, the humans would be weakened and the gods would have twice as many people to worship them. 

Consider your job title.  Is that all that you do in the course of a week?  If you are a programmer do you only write code?  Ever do any acceptance testing?  Have you talked to your customer about their needs or requirements?  Write any documentation?  Did you deliver a presentation to management?  Are you a mentor to other team members?  Have you made the coffee recently?  I’d bet you sometimes wished you did have four arms, four legs, and two heads.  You are not just what your job title says you are.  You title does not fully explain everything that you do.

[login]

When modeling, using such labels can lead to weak use case models.  Let’s say you are on a project to develop a system that automates some security activities for a manufacturing plant.  Consider a simple UML (Unified Modeling Language) use case diagram shown in Figure 1.  This figure shows an actor (Security Chief) who uses the system to perform various use cases: Manage Personnel, Approve Budget, Approve Security Credentials, and Monitor Perimeter. 



Figure 1: Use case diagram showing security chief actor.

You can see, even for this simple system, the Security Chief does things that you might not normally think are part of a Security Chief’s workload.  Here we see the Security Chief Manages Personnel and also Approves Budgets.  In your organization do you have some “Managers” who also write some code, elicit requirements, or do some testing?  If so, and if you were working on the project for the security system for your company, would you recommend that your project build entirely new, separate functionality for Managing Personnel and Approving Budgets just for the Security Chief?  Unless there were security regulations or restrictions, I certainly hope you would not choose to introduce such costly redundancy into the organization.

So how can this be approached?  First, do not create actors that are merely a reflection of some Human Resources job title.  When creating actors in the model remember that an actor represents the role a person or a system plays, interacting with system under development.  

As we have discussed, is it clear that the Security Chief position (and most of our own positions) are “compound roles”, i.e. each of us serve in many roles.  When you find such compound roles in your models, break them up into the constituent roles the actor plays.  Some of these roles will not be relevant to the system you are modeling.  In our example, suppose the Security Guard also teaches a gun safety course regularly for the rest of the security staff.  If this is out of scope for this system, you do not need to include an Instructor actor in your model.  Exclude the irrelevant roles that are outside your scope of work. 

In Figure 2, we have added two new actors: Manger and Guard.  The Security Chief manages security personnel.  Other Managers in this company also manage personnel and approve budgets.  The Security Chief is not the only person that monitors the perimeter.  The Guards do also.  We now see specifically what roles the Security Chief plays in the context of this system: the Security Chief is a Manager and also is a Guard (noted by the generalization associations with the clear arrowhead).

Figure 2: Use case diagram updated to break down the compound role of security chief.

By revealing all the roles an actor may play we may be able to avoid the redundancy problem cited earlier.  Also, by knowing all the other roles, you now may have a new set of stakeholders to satisfy.  A non-security manager may have a different set of needs regarding managing personal than the Security Chief does.  What do they do that is common functionality (that you will not have to reimplement for the Security Chief) and what is unique to the Security Chief and / or the Manager?  These are important considerations to understand when analyzing stakeholder needs.

By splitting “compound roles”, your models will provide you a clearer and more representative picture of who does what and when.  And just maybe your actors won’t need four arms, four legs, and two heads after all.



   
Bob Maksimchuk is a systems engineer, author, speaker, and 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. Twitter: @BobMaksimchuk
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap