Geeks With Blogs

News Ashraful Alam Joy

Create Your Badge

Ashraful Alam is a Software Architect, who has 8 years of professional experience in Software Development industry. This Bangladeshi national is involved with project management and development of several US based software projects from his country. Already he has managed and developed several software projects, which are being used by several users of different countries, such as USA, Canada, Australia, and Bangladesh. While developing and managing a team, he contains and maintains a set of well defined engineering practices developed by him and other online developer communities.

Due to his willingness to give effort to improve and share better software development practices, Ashraf has been awarded as “Most Valuable Professional” (MVP) in ASP.NET category by Microsoft since year 2007 multiple times, which is a rare honor and prestigious reorganization among the developers around the world.

Check his portfolio to know more about him and his works.


.NETTER Characters... Every part of your life is best, if you can know yourself and thus create your life like an artist!

While developing use cases, the designer often faces a confusing situation to name the use case, while this is associated by multiple actors. For instance, a salesman sells a concert ticket to the customer. In this case there are two actors salesman, customer and one use case. What will be the use case name??? “Sell a ticket” ? or “Buy a ticket”? Since both actors are associated, how we can recognize specifically which actor is buying or selling the ticket? Well from my point of view there are couple of solutions, based on the situation:

1. Initiator: the use case name should be given according to the initiator actor. For instance, in the ticket sells use case, if the sells man is the initiator, then the use case name should be “Sell a ticket”.
However there may be another new use case that can be associate with <<include>>/<<exclude>> relationship with this use case. In this case to show the association of the corresponding actor with the new use case, we need to explicitly mention this association. For example if there is a new use case is included “attend the concert” with the “Sell a ticket” use case, we don’t EXACTLY know who is attending the concert. Well putting a simple association with “Customer” actor and “attend the concert” use case says the customer will going to attend the concert.

2. Split the use case: if we want to show the responsibilities among the actors specifically, in that case we have to divide the functionality into two use cases. In our example: we can split the “ticket sells” functionality into two use cases: one is “sell a ticket”, which is associated with the “Salesman” actor and the other one is “buy a ticket” which is associated with the “Customer” actor. However to express the total functionality we have to associate these two use cases.
Any following use case from any of two use cases can automatically reflect the association of the corresponding actor of the first use case, with the current following use case. For example: If the “buy a ticket” use case follows or includes a new use case “attend the concert”, it automatically says or associates the “customer” actor, as it is associated with “buy a ticket”. However we can still associate “customer” with the “attend the concert” use case if we wish, which is semantically correct.

Notes:

Initiator: In a use case diagram, there are the common situations, where actor begins a use case and then the use case interacts with other use cases. However in this case we need to specify the initialization process. This can be done in two ways, either by using the <<initiates>> stereotype in the corresponding association line, or we can use a arrow head line, rather using simple association notation among the actor and the use case.

Use case generalization: As it is possible to generalize a use case with another use case, we should consider all the actors and use case related to the inheriting use case will be implemented to the inherited use case.

Posted on Friday, July 14, 2006 8:37 AM Project Management , UML , Architecture , Software Development | Back to top


Comments on this post: Removing Confusion While Creating Use Cases, Regarding Actor Responsibilities/Association

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Ashraf Alam | Powered by: GeeksWithBlogs.net