简体   繁体   中英

How to identify the correct primary actor from the use case diagram?

I have created a use case diagram based on a scenario, I identified 5 actors in total.

However, I am trying to identify the correct primary actor.

I am undecided between Team Leader and Maintenance Engineer as primary actor as they work pretty closely.

Here is the se case diagram that I have created: 在此处输入图片说明

Scenario:

A combined cycle gas turbine power station requires a webbased system to manage the storage and installation of spare parts and the acquisition of new parts from the Central Storage Warehouse (the CSW). The power station maintains an inventory of all the parts it owns comprising: part name, description and specification. There are many copies of some parts – each part has a unique ID, known as an asset tag number. The asset tag number is used when there damage to particular parts. The power station also keeps a catalogue of all the possible spare parts types used. Only registered maintenance engineers and team leaders are allowed to install and repair parts on the plant. Maintenance engineers and team leaders can use the parts catalogue to search for part types and can also search the parts inventory. Maintenance engineers work in teams, currently: electrical, mechanical and environmental. Each team has its own team lead. However, the system needs to be flexible enough to allow creation of new teams in the future. Maintenance engineers are allowed to take spare parts from the CSW, up to a value of £50,000. Higher value items need authorisation from a team leader. Spare parts are issued from the CSW by a Store Manager. Occasionally a maintenance engineer needs to sign parts back into the CSW. Such “returns” maybe because time has run out on the shift to install the part or because the part is no longer required.School of Computing, Science & Engineering Assignment Assessment Criteria and Marking Scheme. Note that this is only a guide to marking and credit will be given where appropriate. Page 4 of 7 Whenever a new part is installed in the power station an old part is removed. The old part must either be returned to the CSW for refurbishment or disposed of as scrap. After store managers receive requisitions from team leaders, they produce purchase orders to purchase spare parts from suppliers. The purchase orders contain part names and descriptions and are sent suppliers. Suppliers then send the spare parts along with an invoice to the CSW. The store managers then reconcile the invoices against the purchase orders to authorise payments for suppliers. The store managers also handle spare parts returned to suppliers for refurbishment. When a spare part is returned to the CSW, the store managers produce a purchase order. Again, suppliers send refurbished goods (spare parts) to the CSW, where the store managers then reconcile invoices and authorise payments. After the store managers authorise payments for suppliers, the payment transactions are actually implemented by the power station financial management system (FMS). A message passing interface is used to payment transactions. Each payment transaction must include: supplier name, address, phone number, email address, invoice number, order number, authorising store manager name and payment amount (in GBP).

A primary actor is always the one that triggers the use case. Being external to the system under consideration he is the one to gain added value from using the system. There might well be multiple primary actors for a single use case. For the Install UC it would be both Leader and Engineer .

A so-called secondary actor in contrast is only involved in a way that its interaction is needed somewhere in the course of actions triggered by the primary actor.

Sometimes it makes sense to create an actor from which all primary actors inherit. You would give that actor the role name he plays. Just like in a theater. So in your case for the two "main" actors you can simply draw a generalization from Leader towards Engineeer . That means the Leader inherits from Engineer and thus has access to the Install use case. So bascially the Leader acts as Engineer (which pretty much makes sense).

There are two levels at stake here.

For a whole system or a whole use case diagram there may often be several primary actors:

The primary actors are the ones for whom the system is built; they are the ones to whom the system provides sufficient economic value to warrant its construction.
- Bittner & Spence in Use Case Modeling

At the level of a single use-case , there may often be one primary actor:

The primary actor of a use case is the stakeholder that calls on the system to deliver one of its services. (...) The primary actor is oten, but not always the actor who triggers the use case.
- Cockburn in Writing effective use cases

In your case, it's even more ambiguous since you seem to have 13 use-cases split between 3 different systems (and some floating in-between): at which level are you looking for a primary actor?

Hints, not related to your question**

  1. reread the narrative carefully, and make the difference between the location where the users are assigned, and the software system they are using (I suspect there's only one system at play);
  2. keep in mind that the use-case is not a user task outside the system but a goal that the user want to achieve with the system (eg does "Return parts" correspond to an activity in the system?)
  3. keep in mind that some actors may correspond to other systems that shall interact with the system you are design (eg is FMS really in your scope or is it a supporting actor?)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM