Use case diagram - System as an Actor that collect customer information

Question

I understand that a system can be an actor and it is usually drawn on the right side of the system boundary.

I saw a sample system use case Actor as Product Database System which the use case is to Update Product Database.

I have a full question which I am stuck on a paragraph stated that "The system should also collect customer information such as their personal information, their buying preferences eg price range etc.

I'm not sure if I can create an Actor that point to a use case Collect Customer Information?

Please advise as I could not find much examples that mentioned on System Actors.

Answer 1

Is not usually to have the system like an actor (unless is an external system).

Referring to that sentence... Depending on the source of that information:

• If "the personal information" will be recollected directly from the Costumer, that's the actor.
• If that action is launched as a result of other action, you have to use an <<include>> or <<extension>> point.
• If the action happens eventually, you can create the "Time" actor.

Answer 2

From UML 2.5 standard:

An Actor specifies a role played by a user or any other system that interacts with the subject.

So, of course, a system can be an actor. But it seems, this your actor is a part of the subject? So, show it as a subsystem.

An Actor can only have Associations to UseCases, Components, and Classes. Furthermore these Associations must be binary.

Association is that line you meant when you want system to point to something. Only beware, associations to Use Cases have no arrows - they would be excessive, navigation is ALWAYS from Actor to Use Case. So, it is not pointing to use case, but is connected to it.

As you say,

The system should also collect customer information such as their personal information, their buying preferences eg price range etc.

All those things are use cases, that MUST be connected to the actor "Customer".

Your subsystem, if it works with some of these use cases, should appear as a large rectangle, containing these use cases, or a small rectangle, connected with these use cases by the connection "containment"- with crossed circle at the container side.

Internal systems and subsystems do not associate with use cases, they contain them graphically. You are creating the system that fulfills these requirements = use cases. It is shown as containment. System IS DEFINED by the set of use cases. In some sense it IS that set.

If you would show the deployment on this level, then a server or a client comp could have associations with use cases, for a PC is NOT a set of Use Cases. (But mostly it is better to show deployment on deployment diagram)

Decidedly, Product Database System contains the use case Update Product Database. It is not an actor.

Answer 3

Use Cases are so simple...But many people confuse-miss use them...

"I saw a sample system use case Actor as Product Database System which the use case is to Update Product Database"

The use case decribed above use case is wrong:

Use Case speaks in terms of Customer Language not Programming Jargon. It gives WHAT should system do Not HOW system will do it.

And

It should have an primary actor which get benefits or achive a goal by executing the use case. No database has get any benefit from anything.

Use cases are very high level functional requirements. They answer the questions :

For whom we do this system? What those guys can do with this system?

Let's return your question: You have a requirement

The system should also collect customer information such as their personal information, their buying preferences eg price range etc

This type of requirements are called Supplementary Requirements . They do not fit into Use Case Definition. But they may have connection with Use Cases.

Many requirements will not be expressed in use-case form. DO NOT WORRY...NOTHING WRONG WITH IT.Just record them in other formats.

And Use Case Diagrams are more popular then use cases. Unfortuanely.

Infact your supplementary requirement introduce another actor to us. Since who will take customer collected data ...

And suppose that your customer decide to use very sophisticated data mining tool and you application just provide data to that tool [ integrate to that tool ]. Since third party software is out of your scope and you will just use it, then another system can be your secondary actor.

Or Even : Suppose that you will also develop Customer Information Analyzer system, you may subdivide your system as Online Shop Module and Customer Info Analyzer Module -two parts- and the at each submodel behave other module as secondary or primary actor.

UML Standard and Actor Types [ Again those boring standards :-) ]

Many guys just use Use Case Diagrams. So their vocabulary is just based on UML Use Case Diagrams. There are mainly two types of actor in use cases :

• Primary actor
• Supporting actor

Primary actor has user goals fulfilled through using services of the SuD.[system under discussion ] .Why identify? To find user goals, which drive the use cases.

Supporting actor provides a service (for example, information) to the SuD.Often a computer system, but could be an organization or person. Why identify? To clarify external interfaces and protocols.

[ From Craig Larman, Applying UML and appaterns] [ Actually he identify three kinds of external actors - 3rd one Offstage actor -, but for me 2 types are good ]

This is a terminology from RUP [ Rational Unified Proccess ] not from IBM tools. And generalization between actors is as different thing than actor types. To get more info just check the free chapter from Larman's book Use Case Primer