Use fields specified in a CU into another CU

Question

I have a CU that extends another CU, let's say: Add inventory extends Add product, so in one product interface I need to use fields from inventory CU, how I can described this in a CU?

Answer 1

"Extends" means that during the "execution" of the extended UC, execution of the extending UC has been voluntarily invoked by an actor. Each UC is described by several scenarios. Scenario is decribed as an ordered sequence of "steps".

You have to specify so called extension points - steps in the scenario(s) of the extended use case, in which the Actor can invoke the extending UC's execution. It can be a single step or a range...

You can think of the extension point as of a method with parameters, tmplemented in the extending UC and invoked by the extended UC. These parameters could be these fields, you need to "pass" to another interface.

In my projects I always "back up" the my case model with the domain model (class diagram) and use elements of it in the specification of the UCs (preconditions, postconditions, scenarios, extension points).

UPDATE (after the comment)

UML does not define the concrete format of the use case specification, it only defines the concepts and their semantic meaning. A UC can have so called Behavior, can extend another one (or be extended), has Extension points.

The way you define Behavior and Extension points are your own choice.

So, in my example:

• Behavior of both UC is defined as a textual sequence of steps, as performed by System or User (alternative is a state machine, activity diagram, even user interface prototype)
• Extension Point is defined as a step in the sequence and additionally described by this "method" signature, to illustrate the exchanged information

Remember that UCs show INTERACTIONS beetween the System and the outside world. For them is the System kind of black box. Conceptual model I've used here is therefore NOT a DB or system design, but rather a conceptual, implementation-agnostic view on the entities used by the app. They can even be mapped on 2 different systems on the implementation level! Relationships between the UCs similarly exist purely on the user-system interaction level of abstraction, and DO NOT BY ANY MEANS reflect some internal system dependencies! (note added after Gangnus's comment)

(Scenarios and concepts are fully invented for the example sake)

Answer 2

UML standard 2.5, p.680, definition:

An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase.

Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in a UseCase.

I wouldn't call what you are describing an extension. Inventory instance is a container that has Product instances as items. So, Add Inventory is a behaviour that depends on existent products, but not on ways of their adding. So, if you use correct OOP strategy, Add Inventory is absolutely independent on Add Product behaviour. They are both independent behaviours.

Yes, they work on structures, that are dependent and associated, but structures mostly are described in other diagrams. So, normally, these two behaviours are two different independent UCs.

On the other hand, according to standard, you can mix elements of different diagrams, and if you MUST show that intermediate dependency on UC diagram, you can draw there appropriate classes(Product and Inventory), connected by an association. Your use cases will be connected to these classes by arrow "dependency" - - - - - - >

Notice, that Use Case "add Product" and method "addProduct" in some class are absolutely different things. The first is behaviour, described in manual, with participation of user, and the second is a piece of code. The first is the task and the test for the second - that is a realization. So, beware, put classes into Use Cases only if you understand what you are doing VERY WELL, it is not the way for starters. Minimally, reread the Use Cases chapter of the UML standard before. Personally, I would show classes in separate classes diagram here. It is much more easy way.