Analysis

Analysis
Prev	Chapter 2. Requirements engineering	Next

After collecting the overall requirements, an analysis phase takes place. During that part, not only the identified requirements will be elaborated but this is the stage when some preliminary modeling also takes place. The goal of the analysis activities is to establish a deep(er) understanding of the problem domain. It includes finding the details of the outline requirements and developing some system models that descibe the system's context, structure, behavior and interactions. These models develop in parallel as newer and newer parts of the system are understood.

Now, let us return to the role of the BA and translate the former outline into a real system requirements specification that will be an important phase in system development before system modeling and designing the architecture. Documents describing the requirements and design are not text-only documents but the natural language description of the system is supplemented by some figures. In the context of our case study, UML diagrams will predominantly be used for system descriptions.

As it has been discussed above, use case diagram of the UML can portray different types of system users and the ways that they interact with the system. This type of diagram is typically used in conjunction with the textual use case and will often be accompanied by other types of diagrams as well. It covers functional requirements against the system almost entirely. Previously, we have identified three main user types: customer, administrator, and manager. They will emerge as actors in the use case diagram. We can also define relationships between actors. In most of the cases, these are generalization/specialization relationships. In our example, the most general actor is the user whose descendants are the customer and the administrator. Since the manager owns all attributes like an administrator but also additional ones, the manager actor specializes the administrator (i.e., the manager is descendant of the administrator).

After creating the specification, stakeholders should be consulted again in order to validate its contents. In our case, we make a revision of the diagram(s) ourselves. If it is finished, we obtain an overview of the structure of the system. Now, we know what the system should do for its users.

The following table shows a generic structure of documenting a single use case. This is what is called a structured natural language description of scenarios. We will use it as a template for documenting use cases in Sections the section called “Customer use cases”—the section called “Manager use cases”.

Use case ID	Enter a unique numeric identifier for the Use Case. e.g. UC-1.2.1
Use case name	Enter a short name for the Use Case using an active verb phrase. e.g. Withdraw Cash
Actors	[An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor that will be initiating this use case (primary) and any other actors who will participate in completing the use case (secondary).]
Description	[Provide a brief description of the reason for and outcome of this use case.]
Trigger	[Identify the event that initiates the use case. This could be an external business event or system event that causes the use case to begin, or it could be the first step in the normal flow.]
Precondition	[List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each pre-condition. e.g. Customer has active deposit account with ATM privileges Customer has an activated ATM card.]
Postcondition	[Describe the state of the system at the conclusion of the use case execution. Should include both minimal guarantees (what must happen even if the actor’s goal is not achieved) and the success guarantees (what happens when the actor’s goal is achieved. Number each post-condition. e.g. Customer receives cash Customer account balance is reduced by the amount of the withdrawal and transaction fees]
Normal flow	[Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description Customer inserts ATM card Customer enters PIN System prompts customer to enter language performance English or Spanish System validates if customer is in the bank network System prompts user to select transaction type Customer selects Withdrawal From Checking System prompts user to enter withdrawal amount ... System ejects ATM card]
Alternative flows	[Document legitimate branches from the main flow to handle special conditions (also known as extensions). For each alternative flow reference the branching step number of the normal flow and the condition which must be true in order for this extension to be executed. e.g. Alternative flows in the Withdraw Cash transaction: 4a. In step 4 of the normal flow, if the customer is not in the bank network System will prompt customer to accept network fee Customer accepts Use Case resumes on step 5 4b. In step 4 of the normal flow, if the customer is not in the bank network System will prompt customer to accept network fee Customer declines Transaction is terminated Use Case resumes on step 9 of normal flow Note: Insert a new row for each distinctive alternative flow. ]
Exceptions	[Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. e.g. Exceptions to the Withdraw Case transaction 2a. In step 2 of the normal flow, if the customer enters and invalid PIN Transaction is disapproved Message to customer to re-enter PIN Customer enters correct PIN Use Case resumes on step 3 of normal flow]
Includes	[List any other use cases that are included (“called") by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality. e.g. steps 1-4 in the normal flow would be required for all types of ATM transactions- a Use Case could be written for these steps and “included" in all ATM Use Cases.]
Frequency of use	[How often will this Use Case be executed. This information is primarily useful for designers. e.g. enter values such as 50 per hour, 200 per day, once a week, once a year, on demand etc.]
Special requirements	[Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.]
Assumptions	[List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description. e.g. For the Withdraw Cash Use Case, an assumption could be: The Bank Customer understands either English or Spanish language.]
Notes and issues	[List any additional comments about this use case or any remaining open issues or TBDs (To Be Determined) that must be resolved. e.g. What is the maximum size of the PIN that a use can have?]

Use cases are separated into three packages based on the primary actors. Packagas are used to group related elements together. The contents of each package will be detailed later.

Figure 2.13. Overview of use case packages.

A "big picture" of all use cases are shown in Figure 2.14, “All identified use cases on a single diagram.”. However, due to the relatively high number of scenarios this is a bit hard to capture therefore it is very common to have them separated on several smaller diagrams that show only a few use cases at a time.

Figure 2.14. All identified use cases on a single diagram.

The detailed description of the use cases with their tabular representation are given in the following 3 subsections that are followed by a short description of the non-functional requirements of the system.

Customer use cases

Figure 2.15. Overview of customer use cases.

Browse/search

Figure 2.16. Use case UC001

Use case ID	UC001
Use case name	Browse/Search
Actors	Customer
Description	Browse and/or search among products (books, DVDs).
Trigger	The customer wants to browse among products or the customer would like to search for certain products.
Precondition	The customer opens a browser on his/her machine.
Postcondition	The system presents a result list of products (which meets with the given search conditions in case of searching) to the customer.
Normal flow	The customer opens a browser on his/her machine. The customer types a keyword in the search field and presses the "OK" button. The system finds products which meets with the search conditions and presents the result to the customer.
Alternative flows	Perform Advanced Search Steps 2 is replaced with: The customer performs an advanced search operation. (S)He fills the input fields belonging to different attributes of products, then presses the "OK" button. Refine Search Result The following steps are added: The customer refines the result by typing new keywords into the search fields. The system executes a new search operation on the previous result list and presents a new result list to the customer. View Product Details Steps 2-4 are replaced with the following: The customer selects a product from the presented list. The customer presses the "Details" button. A new popup window opens containing some more information about the selected product.
Exceptions	The format or number of the search keywords is incorrect. The system cannot load products (the database is not available).
Includes	None
Notes and issues	If none of the products meets the given search conditions, the system returns an empty list.

Manage bookshelf

Figure 2.17. Use case UC002

Use case ID	UC002
Use case name	Manage bookshelf
Actors	Customer
Description	Handling content of a customer’s bookshelf.
Trigger	The customer wants to save some products for a future order.
Precondition	The customer executes a browsing or a searching operation. The customer must be logged in.
Postcondition	The system saves products chosen by the customer to his/her bookshelf.
Normal flow	The customer selects one or more products from the list. The customer moves the selected product(s) to the bookshelf.
Alternative flows	The customer creates item group(s) or, with another expression, own categories inside the bookshelf which categories can be also hierarchical. The customer selects one or more products from the list. Product(s) will be added to or removed from the own categories by the customer. Each item on the shelf belongs to a certain category which items can be managed together this way.
Exceptions	The system is not able to save the items due to a database failure.
Includes	Browse/Search Manage Item Groups (Own Categories)
Notes and issues	In case of deleting a category, all included items will also be deleted.

Move items to cart

Figure 2.18. Use case UC003

Use case ID	UC003
Use case name	Move items to cart
Actors	Customer
Description	Move certain items from the bookshelf to the customer’s shopping cart.
Trigger	The customer decides to move selected items to the shopping cart.
Precondition	The customer’s bookshelf contains at least one item. The customer must be logged in.
Postcondition	Selected items are removed from the bookshelf. The customer’s shopping cart will contain these items from now on.
Normal flow	The customer selects one or more items from the bookshelf. The customer moves the selected item(s) to the shopping cart.
Alternative flows	None
Exceptions	The system cannot delete the selected items from the bookshelf due to a database failure.
Includes	Browse/Search Manage Item Groups (Own Categories)
Notes and issues	In case of moving a complete category to the shopping cart, the bookshelf will not contain this category from now on. The items moved into the shopping cart will lose their category-marker attribute.

Manage Shopping Cart

Figure 2.19. Use case UC004

Use case ID	UC004
Use case name	Manage Shopping Cart
Actors	Customer
Description	Preparation to an ordering process with adding items to or removing items from the shopping cart.
Trigger	The customer wants to perform an order and therefore chooses items for it.
Precondition	The customer executes a browsing or a searching operation. The customer must be logged in.
Postcondition	None
Normal flow	The customer picks up one or more products from the list. The customer clicks the "Show Shopping Cart" button. The customer adds products to or removes products from the shopping cart.
Alternative flows	The customer changes the amount of the products. The system re-calculates the total price in this case.
Exceptions	None
Includes	Browse/Search
Notes and issues	The contents of the shopping cart are not saved. There is no possibility to permanently store the customer's shopping cart (but he/she can use the bookshelf in order to permanently store items).

Move items to shelf

Figure 2.20. Use case UC005

Use case ID	UC005
Use case name	Move items to shelf
Actors	Customer
Description	Move certain items from the shopping cart to the customer’s bookshelf.
Trigger	The customer decides to move selected items to the bookshelf.
Precondition	The customer’s shopping cart contains at least one item. The customer must be logged in.
Postcondition	Selected items are removed from the shopping cart. The customer’s bookshelf will contain these items from now on.
Normal flow	The customer selects one or more items from the shopping cart. The customer moves the selected item(s) to the bookshelf.
Alternative flows	None
Exceptions	The system cannot insert the selected items to the bookshelf due to a database failure.
Includes	Browse/Search
Notes and issues	The items that are moved onto the bookshelf will own a default category-marker attribute from now on.

Place Order

Figure 2.21. Use case UC006

Use case ID	UC006
Use case name	Place Order
Actors	Customer
Description	The customer creates an order to purchase certain products from the shop.
Trigger	The customer wants to order certain products from the shop.
Precondition	The customer must be logged in. The customer’s shopping cart contains at least one item.
Postcondition	The system saves the new order and performs further processing on it. (Obtaining items from the inventory; packing them together; handing the package over to an external delivery system.)
Normal flow	The customer selects one or more items from the shopping cart. The customer clicks the "Buy" button. The customer fills in the required personal data (name, phone number, email, shipping address, billing address, etc.) on the "Order" dialog. The customer chooses the payment method. The customer confirms the order.
Alternative flows	None
Exceptions	The system cannot save the order due to a database failure. The customer can cancel the order at any time before confirming it.
Includes	Manage Shopping Cart
Notes and issues	The customer is unable to move items back into the shopping cart. If the order is cancelled, its items will also be lost. The system calculates and re-calculates the total price for the order according to the amount changes. This price includes not only the value of the price attribute of each item but also the discounts for certain products and for special customers.

Feed Back

Figure 2.22. Use case UC007

Use case ID	UC007
Use case name	Feed Back
Actors	Customer
Description	The customer sends a feedback about products or the ordering process.
Trigger	The customer wants to provide feedback about products or processes.
Precondition	The customer must be logged in. The customer must own at least one order for which he/she wants to provide a feedback.
Postcondition	The system saves and forwards feedback for further processing.
Normal flow	The customer types in a message on the "Feedback" dialog. The customer sends the feedback.
Alternative flows	Instead of sending, it can be cancelled.
Exceptions	The system cannot save the feedback due to a database failure.
Includes	Place Order
Notes and issues	The feedback will not be available by the customer, only by the administrator.

Visit forums

Figure 2.23. Use case UC008

Use case ID	UC008
Use case name	Visit forums
Actors	Customer
Description	The customer visits forums to share his/her opinion about the products or the system.
Trigger	The customer wants to get a line on the products and share his/her opinion or experiences.
Precondition	None
Postcondition	The system saves the newly created comments.
Normal flow	The customer visits the forum site. The customer reads or writes comments about products.
Alternative flows	1a. The customer can create a new topic.
Exceptions	The system cannot save comments due to a database failure.
Includes	None
Notes and issues	A new comment will not automatically be visible to other users, only after moderation.

Administrator use cases

Figure 2.24. Overview of administrator use cases.

Manage Products

Figure 2.25. Use case UC009

Use case ID	UC009
Use case name	Manage Products
Actors	Administrator
Description	Adding new products to the system, modifying attributes of products, and removing products from the system.
Trigger	The use case is activated when there is a need for adding, modifying, or removing some products in the system.
Precondition	The administrator must be logged in. There must be some products present either in external files (in case of addition) or in the system (in case of modification or deletion).
Postcondition	Product changes will be saved in the system.
Normal flow	The administrator opens the "Manage Products" dialog. The administrator clicks the "Import Products from File" button. He/she chooses one or more files on the dialog. The "Open" button is pressed. The system imports products from the selected files and present them in a list to the administrator. The administrator selects one or more products from the list. The administrator clicks the "Save" button. The system saves the selected products in the database. [[adds new products to the system. He fills in a form with attributes of new products. ]] The administrator selects one product from the list. The "Modify" button is clicked. A dialog window opens. Administrator edits the details of the selected product. Upon pressing the "Save" button, changes will be saved into the database. Administrator selects one or more products from the list. He/she clicks the "Delete" button. The system will remove the selected products from the database.
Alternative flows	Steps 1—4 might be replaced with: Administrator opens the "Manage Products" dialog. Administrator clicks the "Record New Product" button. A dialog window opens. Administrator fills in the attributes of the new product on the form. He/she presses the "Save" button. The system saves the newly created product in the database.
Exceptions	The changes cannot be saved permanently due to a database failure.
Includes	None
Notes and issues	Adding, deleting and updating operations cannot be undone.

Update Order Status

Figure 2.26. Use case UC011

Use case ID	UC011
Use case name	Update Order Status
Actors	Administrator
Description	The administrator updates the status of pending orders.
Trigger	The status of an order needs manual intervention.
Precondition	The administrator must be logged in. There must be orders recorded in the system.
Postcondition	New order status will be saved in the system.
Normal flow	Administrator opens the "Update Order Status" dialog. He/she selects the order which needs to be updated from the list. The new status to be set is chosen. Administrator saves the changes to make them permanent.
Alternative flows	None
Exceptions	The system cannot save the new states due to a database failure.
Includes	None
Notes and issues	Changes after saving cannot be made undone.

Process Feedback

Figure 2.27. Use case UC012

Use case ID	UC012
Use case name	Process Feedback
Actors	Administrator
Description	The administrator processes incoming feedbacks from customers.
Trigger	Administrator wants to evaluate the feedbacks given by the customers.
Precondition	Administrator must be logged in.
Postcondition	None
Normal flow	The administrator opens the "Process Feedbacks" dialog. He/she reads the feedbacks.
Alternative flows	None
Exceptions	None
Includes	None
Notes and issues	None

Compose/Send Newsletter

Figure 2.28. Use case UC013

Use case ID	UC013
Use case name	Compose/Send Newsletter
Actors	Administrator
Description	The administrator composes and sends newsletters to customers signed up for newsletters.
Trigger	There is a new action offer created by the management.
Precondition	Administrator must be logged in. Action offers must be set in the system by the manager.
Postcondition	The newsletter is sent to the customers.
Normal flow	The administrator obtains descriptions of the newest action offers. He/she composes a newsletter holding information about action offers mentioned previously. The newsletter is sent to the customers signed up.
Alternative flows	None
Exceptions	The mailing system is not available.
Includes	Set Action Offers
Notes and issues	None

Moderate Forums

Figure 2.29. Use case UC014

Use case ID	UC014
Use case name	Moderate Forums
Actors	Administrator
Description	Administrator moderates comments before they become available to other customers.
Trigger	Administrator wants to moderate comments arrived since the last review.
Precondition	Administrator must be logged in. There is a comment to be moderated.
Postcondition	The moderated comment will be saved and presented to the other customers.
Normal flow	The administrator opens the "Moderating Comments" dialog. He/she reads a new comment. A decision is made by the administrator whether the comment is acceptable. If it is acceptable then the message will be updated with this information so it will become readable by anyone else. Otherwise, the comment will be rejected.
Alternative flows	None
Exceptions	None
Includes	None
Notes and issues	None

Manager use cases

Figure 2.30. Overview of manager use cases.

Set Action Offers

Figure 2.31. Use case UC015

Use case ID	UC015
Use case name	Set Action Offers
Actors	Manager
Description	The manager sets action offers in the system.
Trigger	A management decision about a new action is made.
Precondition	Manager must be logged in
Postcondition	The newly created action offers and rules are saved.
Normal flow	The manager sets rules on the form for certain products. During the order process, these rules will be applied together with the customer discounts at calculating the total price for a given order. The manager saves the rules. He/she creates descriptions about the new action offers for the administration.
Alternative flows	None
Exceptions	The rules cannot be saved in the system due to a database failure.
Includes	None
Notes and issues	The manager must be familiar with the syntax and functionality of special rules.

Set Customer Discounts

Figure 2.32. Use case UC016

Use case ID	UC016
Use case name	Set Customer Discounts
Actors	Manager
Description	The manager sets rules for special customer discounts.
Trigger	Management decision is made about customer discounts.
Precondition	Manager must be logged in
Postcondition	The newly created rules are saved.
Normal flow	The manager sets certain rules on the form for each customer category about discounts. The manager saves the rules.
Alternative flows	None
Exceptions	The rules cannot be saved in the system due to a database failure.
Includes	None
Frequency of use
Special requirements
Assumptions
Notes and issues	The manager must be familiar with the syntax and functionality of special rules. Customers belong to different categories based on the amount of purchased products so far. During the ordering process, these rules will be applied together with action offers for products at calculating total price for a given order.

View/Check Reports/Statistics

Figure 2.33. Use case UC017

Use case ID	UC017
Use case name	View/Check Reports/Statistics
Actors	Manager
Description	The manager can check different reports and/or statistics about the sales.
Trigger	Manager wants to some reports or statistics.
Precondition	The manager must be logged in.
Postcondition	Generated reports are presented to the manager.
Normal flow	The manager opens the "Reports and Statistics" dialog. The appropriate report type is selected plus values for required parameters (like time window for the report) are provided.
Alternative flows	None
Exceptions	None
Includes	None
Notes and issues	None

In many processes, the detailed description of the use cases are developed in line with some preliminary models of the system. This side by side development means that we often perform some iterations and as we develop deeper and deeper understanding of the problem, more and more accurate system models that capture the problem space are established. Examples of such models that can be developed at this stage are context models, detailed interaction and behavioral models (described by sequence and activity diagrams and statecharts) and domain models that make use of class diagrams in order to capture the main concepts of the particular domain. (More examples will be shown in Chapter 3, System modeling soon.)

Based on the detailed description of use cases, activity and/or sequence diagrams might be created in order to show how the control flows when a use case is executed. However, it is uncommon to provide such interaction diagrams for each use case: some of the use cases can be so simple that it does not need further elaboration. For complex scenarios it might be reasonable to provide an activity or sequence diagram as it helps the reader to understand easier.

Figure 2.34. Activity diagram for use cases Browse/Search and Purchase Order

UML 2 Activity diagrams

In UML, an activity diagram is used to display the sequence of activities. Activity diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity. They may be used to detail situations where parallel processing may occur in the execution of some activities. Activity diagrams are useful for business modelling where they are used for detailing the processes involved in business activities.

A sample activity diagram that uses lots of the possible features are shown below.

Figure 2.35. Activity diagram sample with lot of features ([SPARXSYSTEMS.COM])

The following elements can occur on an activity diagram:

Activity: An activity is the specification of a parameterized sequence of behaviour. An activity is shown as a round-cornered rectangle enclosing all the actions, control flows and other elements that make up the activity. In this example, Process Order is an example of an activity.
Activity parameter: activities can have parameters which are displayed on the border. Requested order (on the left border of the activity) is an example for such a parameter.
Action: Action is a named element which represents a single atomic step within activity, i.e. that is not further decomposed within the activity. Activity represents a behavior that is composed of individual elements that are actions.
Control flow (or activity edge): A control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead. (Each arrow is an example.)
Initial node: a filled circle, this is where the execution of the activity starts.
Final node: there are two types of final nodes, activity final (denotes the end of all control flows in the activity) and flow final (used for showing the end of a single control flow). The first is shown in the sample diagram with a dot inside the circle; the second is denoted by a cross inside the circle.
Decision and merge nodes: both denoted by a diamond. They can both be named. The control flows coming away from a decision node will have guard conditions which will allow control to flow if the guard condition is met. The following diagram shows use of a decision node and a merge node. In the example, the left diamond is a decision one while the right one depicts a merge node.
Fork and join nodes: denoted by either a horizontal or a vertical bar (the orientation is dependent on whether the control flow is running left to right or top to bottom). They indicate the start and end of concurrent threads of control. In the example diagram, the left side of the two bars is a fork (concurent execution of actions start here) while the right side is a join (there is a synchronization).
Accept event action: it is an action that waits for a specific event to occur, notated as a concave pentagon. This action handles asynchronous messages, including asynchronous calls. It cannot be used with synchronous calls (except accept call action). Check shopping cart and Proceed to checkout are both examples for it.
Send signal action: notated as convex pentagon, it creates a signal from its inputs.

This activity diagram shows how a customer will perform the most important scenario of the system, namely, purchasing an order. This process has multiple entries: normally, it starts with either browsing or searching for a product, however, it is also possible to check the actual contents of the shopping cart, or, one can directly proceed to checkout phase in case he or she has a non-empty cart. Note the guards on the outgoing edges of decisions. The [new search] guard should include a refined search, as well, since the normal execution flow of searching requested the possibility of refining search criteria.

The described process still stands on a relatively high level of abstraction: it shows how some of the use cases work together to provide system functionalities but the underlying objects that will interact each other are not revealed. To illustrate how various objects will communicate with each other in run-time, we can create sequence diagrams for some activities. Again, there is no need to assign a separate sequence diagram to each activities as some of the activities work in a very simple way: for example, Browse items only visits Products, there is no further processing. On the other hand, some activities capture more difficult logic that worth depicting on a separate diagram as seen on the following figure.

Figure 2.36. Sequence diagram of the activity Checkout

Of course, this is the Customer actor, who initiates the checkout process. When the actual contents of the shopping cart needs to checked out, the customer will click on the Checkout button which then will result in the invocation of the shopping cart domain object which has the responsibility of the price calculation. It will first ask the customer domain object whether the given customer has some customer-based discounts to calculate with. After retrieving this information, a loop will iterate over each products put into the shopping cart and their individual prices along with their quantities accessed from the associated ProductSelection object will be retrieved. Based on that information, the shopping cart will send itself a self-message (invoke its own method) to calculate the price.

Note

This diagram still omits a couple of details. Of course, it is not the Customer actor itself who will send the checkout message to the shopping cart domain object but there should be a GUI object (a class with the boundary stereotype). According to the Model—View—Controller pattern, an intermediary controller object is also needed since the views are required to notify the controllers about GUI events but these objects and the delagations performed by them are not shown in the figure in order to keep the example small.

Important

Technically, there are two customer lifelines on this diagram, an actor and an object. The former is not an object of the system but a human being using the application and cause variuos scenarios to be executed while the latter is an object of the system which can therefore receive messages. So this is not an error but a preferred way of how you should model situations when an actor initiates some activities that involve sending messages to the "digital representation" of the actor.

UML 2 Sequence diagram

Sequence diagram is the most common kind of interaction diagram, which focuses on the message interchange between a number of lifelines. Sequence diagram describes an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding occurrence specifications on the lifelines. The following nodes and edges are typically drawn in a UML sequence diagram (this is not an exhaustive list):

lifeline. Lifeline is a named element which represents an individual participant in the interaction. While parts and structural features may have multiplicity greater than 1, lifelines represent only one interacting entity.
If the referenced connectable element is multivalued (i.e, has a multiplicity > 1), then the lifeline may have an expression (selector) that specifies which particular part is represented by this lifeline. If the selector is omitted, this means that an arbitrary representative of the multivalued connectable element is chosen.
A lifeline is shown using a symbol that consists of a rectangle forming its "head" followed by a vertical line (which may be dashed) that represents the lifetime of the participant.
execution specification. Execution (full name: execution specification, informally called activation) is an interaction fragment which represents a period in the participant's lifetime when it is
- executing a unit of behavior or action within the lifeline,
- sending a signal to another participant,
- waiting for a reply message from another participant.
Note, that the execution specification includes the cases when behavior is not active, but just waiting for reply. The duration of an execution is represented by two execution occurrences—the start occurrence and the finish occurrence.
Execution specifications can overlap. They are represented by overlapping rectangles on the same lifeline then.
message. Message is a named element that defines one specific kind of communication between lifelines of an interaction. The message specifies not only the kind of communication, but also the sender and the receiver. Sender and receiver are normally two occurrence specifications (points at the ends of messages).
Syntax for the message is:
```
message ::= [ attribute '=' ] signal-or-operation-name [ arguments ] [ ':' return-value ] | '*'
arguments ::= '(' [argument [ ',' argument]* ')'
argument ::= [ parameter-name '='] argument-value | attribute '=' out-parameter-name [ ':' argument-value ] | ' -'
```
Arguments of a message could only be:
- attributes of the sending lifeline,
- constants,
- symbolic values (which are wildcard values representing any legal value),
- explicit parameters of the enclosing interaction,
- attributes of the class owning the interaction.
A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message.
A message could be one of the following:
- synchronous call. Synchronous call typically represents operation call—send message and suspend execution while waiting for response. Synchronous call messages are shown with filled arrow head.
- asynchronous call. Asynchronous call—send message and proceed immediately without waiting for return value. Asynchronous messages have an open arrow head.
- asynchronous signal. Asynchronous signal message sends a signal.
- create. Create message is sent to a lifeline to create itself. It is shown as a dashed line with open arrowhead (looks the same as reply message), and pointing to the created lifeline's head.
- delete. Delete message (called stop in previous versions of UML) is sent to terminate another lifeline. The lifeline usually ends with a cross in the form of an X at the bottom denoting destruction occurrence. The notation that should be used is a filled arrow head (like in case of synchronous call) with the stereotype «destroy».
- reply. Reply message to an operation call is shown as a dashed line with open arrow head (looks similar to creation message).
combined fragment. Combined fragment is an interaction fragment which defines a combination (expression) of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. Through the use of combined fragments the user will be able to describe a number of traces in a compact and concise manner.
Combined fragment may have interaction constraints also called guards. These are boolean expressions shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event, in the containing interaction or interaction operand.
Some examples of the interaction operator could be:
- alt - alternatives. It represents a choice or alternatives of behavior.
  Figure 2.37. Call accept() if balance > 0, call reject() otherwise [UML-DIAGRAMS.ORG]
- opt - option. Optional execution (either the operand happens or nothing).
  Figure 2.38. Post comments if there were no errors [UML-DIAGRAMS.ORG]
- loop - iteration. The loop operand will be repeated a number of times.
  Figure 2.39. Potentially infinite loop [UML-DIAGRAMS.ORG]
  
  Number of executions can be controlled by putting a number into parenthesis right after the keyword loop.
interaction use. Interaction use is an interaction fragment which allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with interaction uses. It is also common reusing some interaction between several other interactions.
Figure 2.40. Web customer and Bookshop use (reference) interaction Checkout [UML-DIAGRAMS.ORG]

Communication digrams provide almost an alternative notation for sequence diagrams. A communication diagram also shows the messages that are passed between objects but the lifelines are depicted as objects (rectangles) and the order of messages are described by numbering the arrows that represent messsages.

Figure 2.41. Communication diagram of the online bookstore's find book and checkout activities

UML 2 Communication diagram

Communication diagram (called collaboration diagram in UML 1.x) is a kind of UML interaction diagram which shows interactions between objects and/or parts using sequenced messages in a free-form arrangement. Communication diagram corresponds (i.e. could be converted to/from or replaced by) to a simple sequence diagram without structuring mechanisms such as interaction uses and combined fragments. It is also assumed that message overtaking (i.e., the order of the receptions are different from the order of sending of a given set of messages) will not take place or is irrelevant.

On communication diagrams, objects are shown with association connectors between them. Messages are added to the associations and show as short arrows pointing in the direction of the message flow. The sequence of messages is shown through a numbering scheme.

Non-functional requirements

Besides functional requirements, it is important to gather and document non-functional requirements. Such requirements might be product, organizational or external requirements that need to be worded in a verifiable manner. Examples of non-functional requirements (with their categories denoted in parenthesis) for the bookstore are shown in Example 2.1, “Non-functional requirements for the case study.”.

Example 2.1. Non-functional requirements for the case study.

NF01: At peak periods, the online store is expected to receive 50 search requests per second. (Product)

NF02: The system should respond within 2 seconds to 95% of the requests but all valid requests needs to be answered in no more than 4 seconds. (Product)

NF03: The application has to be multi-platform. Supported operating systems are: Windows XP or higher and Linux. (Organizational)

NF04: During the operation of the system, the operative Act of Accounting of the country of operation must be observed. (External)

Non-functional requirements are in many cases more important that functional ones, especially from the architectural design point of view since non-functional requirements can heavily affect architectural design decisions.

Prev	Up	Next
Gathering the requirements of the case study	Home	Chapter 3. System modeling