«Sharam Hekmat PragSoft Corporation Contents 1. INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 SOFTWARE TOOL 1.4 GLOSSARY OF TERMS 2. ...»
For example, consider an Individual Tax Return process at the Taxation Office:
This process map states that the process is kicked-off by the Individual Tax Return Received trigger. The Enter Details activity is performed by a Mail Handler. Once this activity is performed, the work is deposited into the Pending Returns queue. In the Assess Return activity, a Tax Clerk takes the work from this queue and assesses the tax return. If the return has missing information, then this information is requested from the return filer, and the activity is suspended until the filer provides the requested information (i.e., Requested Info Received trigger). The outcome of the assessment is either a fully processed return, or the initiation of a tax audit. Processed returns go into the Processed Returns queue and are then handled by the automatic Mailout Assessment activity.
Auditable returns go into the Auditable Returns queue and result in the automatic generation of an Audit Tax Return process (defined elsewhere).
3.2.3 Activity Definition As stated earlier, an activity is a process segment that is performed by one person. It is defined in
terms of these abstractions:
• Actions. These are the building blocks of the activity. Unlike an activity, an action is an atomic step. Consequently, a user can perform an activity partially (i.e., do some of its actions) and complete the rest at some later stage. This is not possible with an action, which offers no further breakdown to the user.
• Branches. These can be used to constrain the flow of control between actions. There are 3
types of branches, all of which have one-to-many or many-to-one cardinality:
• An and branch implies that all the ‘many’ actions to which it connects must be completed.
www.pragsoft.com 24 UML Process
• An or branch is similar to an ‘and’ branch, except that at least one of the ‘many’ actions to which it connects must be completed.
• An xor branch is similar to an ‘or’ branch, except that exactly one of the ‘many’ actions to which it connects must be completed.
• Conditions. These allow the flow of control to be redirected based on the outcome of certain logical conditions.
• Documents. Most processes in the service sector deal with a variety of documents (e.g., letters, bills, invoices). Documents are not only generated by processes/activities, they may also serve as input to other processes/activities.
We will use the following symbols to depict these abstractions:
As before, an arrow depicts the flow between these abstractions. The manual, automatic, and semi-auto stereotypes can be used with Action and Condition symbols. Additionally, an action may have the optional stereotype, implying that, at the user’s discretion, it may or may not be performed.
Referring back to our earlier tax return process example, each activity in that process map is refined into an activity map. For example, the Enter Details activity is refined into the following activity
This activity map states that the return documents must be scanned (Scan Return Documents action) and the user must manually check whether the TFN is specified on the return. If so, then the tax payer’s record is looked up on the system (Lookup Tax Payer Record action). Otherwise, a new tax record needs to be created on the system (Create New Tax Payer Record action). Then a new tax return record is created (Create New Return Record action), and the scanned documents are linked with this tax record (Link Return Record and Docs action). Work is then passed onto UML Process 25 Copyright © 2005 PragSoft the Pending Returns queue. Note that this matches a similar flow from the activity to the queue in the parent process map shown earlier. The use of the and branch here signifies that the scanning and the checking of TFN must both be done, but can be done in either order.
Similarly, the Assess Return activity is refined into the following activity map:
Both actions in this activity map are automatic, implying that they are performed by the system without human intervention.
3.2.4 Action Definition For the purpose of business process modelling, each action is defined informally using a narrative. It is not practical at this stage to formalise the definition of an action, because this will require the business objects on which the action operates to have been defined. These business objects are defined in the next phase (i.e., requirements analysis).
As an example of an action narrative, here is how the Create New Tax Payer Record action in our
tax example may be defined:
Action: 4. Create New Tax Payer Record Description: Allows the user to key-in the details of a taxpayer, and creates a record for the
3.3 Use-Case Modelling An alternative approach to producing a business model is to focus on the business functions rather than the business processes. This is essentially what has been popularised as the use-case approach.
Each use-case captures a way of using the system, that is, a business function. Because use-cases focus on the functionality that the system will provide rather than the business processes that it should support, the resulting system will be function centric. Consequently, this approach is suitable for developing vertical applications, whereas business process modelling is better suited to enterprise applications.
To illustrate the difference between the two approaches, if we tried to model the Individual Tax Return process described earlier using use-cases, we might come up with the following use-case model.
The key differences with the process model are:
• The activities (Enter Details and Assess Return) become use-cases that refer to lower-level use-cases (which were actions in the process model).
UML Process 27 Copyright © 2005 PragSoft
• Some of the actions (e.g., Scan Return Documents) become use-cases in their own right.
• There is no longer a clear notion of flow of control or conditions.
• If developed further, the use-case approach results in an application that does not convey or enforce a business process. The user is expected to know the process and to use the application to perform the steps that reflect his understanding of the process steps and their correct sequence.
In application modelling, we produce 3 types of models:
• Class diagrams, which depict the business objects underlying the business processes (or usecases).
• Scenarios, which illustrate how business objects exchange messages in order to support the actions (or uses-cases).
• User interface models, which illustrate how the business functionality is presented to the user.
4.1 Business Objects 1 Business processes (and business functions) involve business objects. Each business object represents a major abstraction in the business domain that is characterised by data and behaviour.
The data represents the persistent state of the object, and the behaviours represent what can be done to the object, which in turn determines how the data is manipulated.
Given a business model (expressed as process maps or use-cases), we must analyse it to identify the business objects. This is not a mechanical task and requires a good understanding of the business
domain and a bit of creativity. For each object, we must identify:
• Its attributes (these represent the persistent data that record the object state).
• Its methods (these represent the behaviour of the object, i.e., the things that you can do to the object).
• Its relationships to other objects (e.g., does this object make use of other objects?) This results in a static model (called class diagram) that provides a lot of information about the objects, without saying anything about how they work together in supporting the business processes or use-cases.
4.1.1 Class Diagrams
The UML notation is used for defining a class diagram, and includes the following symbols:
This diagram states that the tax system (TaxSys class) is an aggregation of TaxPayers. Each TaxPayer has zero or more TaxReturns, and each TaxReturn has an associated set of Documents. A Document may be a ScannedDocument or a GeneratedDocument; furthermore, a TaxStatement is an example of a GeneratedDoc. For each TaxPayer a TaxAccount is held which records the tax owed by/to the TaxPayer. This TaxAccount has TaxTransactions recorded against it. Also, TaxStatements may be generated against this account. Finally, a TaxPayer may be subjected to TaxAudits. Each such audit may have various associated Documents.
It is worth noting that not all the information captured by this class diagram comes directly from the process model. For example, additional questions need to be asked in order to identify the class attributes and their relationships. Also, TaxAccount, TaxTransaction, and TaxStatement are not even referred to by the process model, but emerge out of further analysis of the problem domain. In summary, to identify business objects, one should not be limited by the information provided by the business processes; other useful sources of information should also be considered.
4.2 Scenarios Having identified the business objects, we can now attempt to describe how each action (or usecase) is supported by these objects. These descriptions are called scenarios and can be expressed in two forms: as collaboration diagrams or as sequence diagrams.
4.2.1 Collaboration Diagrams A collaboration diagram describes a scenario as the exchange of messages between objects. For example, the CalculateTax action in our process example can be described by the following collaboration diagram.
Each message is depicted by a small arrow, emanating from the object that issues it, and directed to the object that receives it. The receiving object must support the message (i.e., the message must be one that is exposed by the receiving object). The messages are numbered to depict their logical sequence.
The above diagram, therefore, states that TaxSys issues a CalculateTax message to TaxPayer, which in turn issues a CalculateBalance message to TaxReturn. When the latter returns, TaxPayer uses the calculated tax balance to issue a CreditDebit message to TaxAccount, which in turn Creates a TaxTransaction object to record the credit/debit. Upon completion of these messages, control returns to TaxSys.
4.2.2 Sequence Diagrams A sequence diagram describes a scenario as the interaction among objects in time sequence. For example, the above collaboration diagram can be represented as the following sequence diagram.
The process layer defines the end-to-end business processes covered by the model. The activity layer specifies each of the activities that comprise the business processes in the process layer. The action layer specifies each of the actions that comprise the activities in the activity layer. When an action is performed, it affects one or more business objects (denoted by boxes in the third layer).
4.3 User Interface Models
Two things make the user interface a crucial part of any business application:
• The user interface is the means by which the user is given access to the application’s business functionality. Regardless of how sophisticated and comprehensive the underlying business functionality might be, if the user interface is poor then all this will go to waste – the user will never have the opportunity to benefit from it.