The first article of this set provided an end-to-end view of the Unified Scenario-Based Design (USBD) methodology, explaining the steps that need to be performed to correctly model the business and link it to the systems that support it. This article focuses more on explaining the artifacts that need to be created to model the "Customer" by capturing all the details -- what does the Customer do and how does it do it -- that are required to correctly model the systems that support the business that it runs. Figure 1 shows the overall set of artifacts you will produce while using the USBD methodology.
Figure 1: Summary of the Unified Scenario-Based Design methodology
This article is going to focus more on the top and bottom left parts of this figure, providing more details on the artifacts shown there.
The main actor in this phase is the Interaction Designer in the role of the Business Analyst, and hereafter are the steps performed during this phase. It is worth noting that the steps described next should not be considered strictly sequential in nature. In reality, it is usual while modeling to perform several activities in parallel, each of which helps refine the overall model.
During the first step five main elements are identified and captured in the Business Model:
- Business Process Maps
- Business Processes
- Business Actors
- Customer Stakeholders
- Business Goals
As anticipated in the first article of this series, experience suggests that the same logical business process is implemented in different forms at various Customers. For example, some may implement the full process, where others may only implement a subset of it. Furthermore, different Customers may have alternative implementations of parts of a process. In addressing these variability points, you may ask if there is any other field besides business modeling where the same problem of modeling variability has already been solved. One answer comes from the system modeling space, and specifically the Software Product Lines methodology. The solution adopted in that space was to identify in the whole system the subset that is common among all exploiters. This becomes the kernel of the system. Parts that are only used by some exploiters become optional, while parts that two exploiters address differently become alternative. The same pattern can therefore be used within business modeling. Specifically, you can identify the common part of the business process: that is, the activities that are always performed by any Customer. These become the kernel business process. In a similar fashion optional and alternative activities can be identified and modeled appropriately.
Business Process Maps are represented as UML activity diagrams. They show in a compact way all of the identified business processes, and the relations among them. The processes pertaining to each organizational (business) unit are grouped in the diagram into a corresponding swim-lane. It should be noted that business processes produce and consume business entities. Starting from the map, the business processes of interest are then further detailed. Figure 2 shows the map of all the processes pertaining to Scheduling Workload Management, from the original Business Unit Batch and Schedule Development, down to the Operations Center that put the actual scheduling into production.
Figure 2: Business Process Map
Business Processes are also represented as UML activity diagrams. Figure 3 details the Batch and Schedule Development business process (highlighted by a red arrow in Figure 2). Such a detailed business process diagram describes how Business Actors collaborate with one another. This is represented by using a UML activity diagram that shows all of the activities identified in the specific business process.
Figure 3: Batch and Schedule Development Business Process Fragment
The actions are organized into groups. Such groups are a kind of packaging mechanism for organizing the responsibility for activities within a specific context. They correspond to roles within an organization and are represented in the business process as swim-lanes (borrowing a formalism used in the corresponding diagrams in the analysis of a system). Artifacts exchanged during the process are represented by Business Entities, and are associated to the activities that produce and consume them. As noted previously, the Software Product Line approach is advocated to address the kernel, optional, or alternative activities at a business level. This is achieved by adding a corresponding stereotype in the activity itself to represent how the Customers are actually adopting different parts of the process.
Each group represents activities performed by the same role within the scheduling workload management space; each one of those roles corresponds to a business actor defined in the business use case model (refer to Step 2 below), while each activity corresponds to a Business Use Case by means of the Business Use Case realization. Using this technique, it is possible to transpose the Business Processes into a Business Model and create formal traces between the two.
Figure 4 shows the correspondence between the business process' swim-lanes and the business model actors, as well as the correspondence between the activities and the related business use cases, by overlaying the two corresponding entities. Please note that this is done here visually only for explanation purposes; it is not possible in the normal implementation of this methodology.
Figure 4: Batch and Schedule Development Business Process transposition
As far as the business domain is concerned, other best practices suggest using IBM® WebSphere® for Business Integration (WBI) to model the business processes. For example, the Run Production Schedule process shown in Figure 2 may be described using the WBI tool. The excerpt in Figure 5 shows what it would look like. One option is still to continue modeling the processes using WBI and then to translate them into UML activity diagrams using the available transformation tools.
Figure 5: Run Production Schedule Business Process modeled using WebSphere for Business Integration
Customer Stakeholders are kind of special Business Actors. They represent the role of who has the responsibility to set the Business Goals. The importance of understanding and modeling these actors and their goals lies in the fact that they are typically involved in the process of purchasing the software products. The diagram in Figure 6 provides an example for the Operations Manager, who sets the goal of ensuring that all transactions are completed within the agreements. This goal, like any other goals set by the stakeholders, has to be measurable. The measures are very important to the stakeholders, and may become key information into system reports dedicated to them. The stakeholders may not participate directly to the business process, but they are nonetheless interested in how the business process behaves.
Figure 6: Operations Manager Customer Stakeholder and related Business Goals
Business Actors are represented, together with their static relationships with their siblings, in a specific diagram using the classic Business Actor modeling elements. An explicit modeling of the static relationships among the Business Actors captures important characteristics that help identify hierarchies and, by means of formal tracing, how they collectively co-operate to support business goals.
Business Goals can be expressed with UML classes stereotyped with <<business goal>> and trace back to the business use case supporting them. The new stereotype and its iconic representation is available, among others, in the USBD profile that will be further shown in the fourth article of this series, and which can be installed on the IBM® Rational® Software Architect tool.
As anticipated earlier, the activities described in a business process are very high-level. In reality, each activity may be performed under the responsibility of the identified Business Actor by several other actors, called Business Workers. In order to provide a greater level of detail, the best-practice here suggests relating each activity in the process to a different Business Use Case, and vice versa. The realizations of such business use cases will detail how each activity is performed and by which actors.
Specifically, during the second step the Business Model is completed by means of the following:
- A use case diagram showing all of the identified Business Use Cases
- A freeform diagram that traces the relationships among the Customer Stakeholders, the Business Goals they set, and the Business Use Cases that support those goals
Formal traces between activities in a process and the corresponding Business Use Case Realizations are achieved by modeling such activities as Call behavior elements that link to the corresponding realizations.
Figure 7 shows the Business Model fragment that results from the transposition explained in Step 1 of the Business Process shown in Figure 4.
Figure 7: Business Model fragment
As was done with activities in the Business Process, Business Use Cases can also be identified as being kernel, optional, or alternative within the business model. Also during this phase, the links between the business use cases and the business goals are defined and formally expressed in UML; this tracing activity helps guarantee that every business goal is covered by one or more business use cases. Figure 8 shows an example of this relationship. The red arrow shows that the Developing Schedule Definition business use case from Figure 7 supports the business goal that is set by the Operations Manager.
Figure 8: Customer Stakeholders, Business Goals, and supporting Business Use Cases
Part of this second step is the formal definition of the trace between a specific business process activity and the corresponding identified business use case. This is done through the business use case realization, which then becomes the means to create a link between the process, the business use cases and, indirectly, also the business goals. This approach allows the validation of the business process coverage in terms of business use cases and business goals and vice versa. Figure 9 shows how a specific Developing Schedule Definition business use case is linked to the Develop Schedule Definition business activity.
Figure 9: Business Use Case linked to a Business Activity through realization
Once this part of the model has been defined, it is important to perform a round of validation, involving stakeholders coming from as many different environments as possible. The input from actual or potential Customers will be invaluable in this phase to refine the business model.
During the third step, a Business Analysis Model is developed wherein each business use case realization is formalized in terms of two major UML artifacts:
- A UML class diagram representing the static view of the business use case participants -- including business workers and business actors -- together with their relationships
- One or more UML sequence diagrams (each one representing a different business use case scenario or sub-process) representing the interactions existing among the Business Workers to realize the business use case
Figure 10 shows how the Developing Schedule Definition business use case is realized in terms of three business workers. Business workers are the entities that actually perform the activities shown in the process map, while the business actors are the ones that initiate the actions (and are possibly responsible for their completion).
Figure 10: Developing Schedule Definition Business Use Case Realization Participants
A business worker may be a person, or it may be an automated system. It is worth noting that whenever there is, inside a realization, the interaction between a business actor and a business worker that is automated, this actually introduces the interaction between a User and a System, and so typically results in one or more System Use Cases. Likewise, whenever there is an interaction between two automated business workers, a system-to-system interaction needs to happen. Figure 11 shows how the business workers of the Developing Schedule Definition Business Use Case Realization cooperate to implement the activity.
Figure 11: Developing Schedule Definition Business Use Case Realization Flow
This step selects the business worker(s) to be automated among the ones identified during the previous step. Determining which business worker to automate is outside the scope of this article but is crucial. Many different methodologies may be used for such identification. For example, one could be to understand what is going to be the forecasted savings in automating one worker instead of another. It is worth reminding that if at least one business worker is automated and at least one is not, what is actually being defined is a System and its User. If, for example, it is decided that the Scheduler worker has to be automated, the sequence diagram shown in Figure 11 provides useful information to create the Scheduler System Use Case model. In fact, every message that enters into the worker can be thought to become the realization of a System Use Case implementing the worker's functionality. Figure 12 shows how this transposition is done conceptually, which is quite similar to the one done in the business domain to create the business use case model from the business processes.
Figure 12: Scheduler Business Worker transposition
The example here shows how the Scheduler business worker is automated. The resulting System Use Case model is shown in Figure 13, and includes all the use cases identified.
Figure 13: Scheduler Use Case Model
This step creates the traces between the business modeling and the system modeling artifacts. The best practice here is to link each method provided by the to-be-automated business worker to the corresponding System Use Case realization in the system analysis model by means of references in the sequence diagram. This greatly enhances the model navigation. Moreover the business workers that initiate those methods are to be traced to corresponding system actors (User Roles) living in the System Use Case model. Figure 14 shows how the Create Job Template Use Case is linked to the corresponding message.
Figure 14: Use Case link to Activity
Additionally, since the automated system has to provide a Graphical User Interface (GUI) to allow the Schedule Developer worker (user) to interact with it, a similar link is created to trace the same method to a use case storyboard, which is a different type of realization of the same Create Job Template System Use Case. To be precise, the USBD suggests that each use case in the use case model -- that has a relationship with an actor -- is realized by a use case realization in the design model, and by a use case storyboard in the user experience model. In general, it is not necessary to define a System Use Case realization with the same name of the method to create the link; the names can differ in the two models (business and system) because the link is formally defined by a UML trace dependency. The next section introduces User modeling, which is an important step once the decision to automate one or more Business Workers is made.
This category comprises the activities that are currently considered the primary ones for the Interaction Design (IaD) team, namely creating the User Personas and understanding the User goals. The Interaction Design methodology for user modeling captures archetype Users into User Personas, along with their goals and skills. As far as the goals are concerned, typically each goal can be related to the role that the Persona interprets in a given context. Within the method, the Personas are documented in a textual form, which is a very effective way to communicate with the largest range of stakeholders. Unfortunately, this makes it difficult to trace such "user models" to the System Actors in the System model. To achieve this, a formal UML representation of the Personas is desirable, and is described below.
These Personas are reflected, together with their goals and skills, into a class diagram where each Persona is associated with the System Actors (that is, the user roles) it typically covers. Additionally, the same class diagram also describes the relationship between each User Goal identified during the IaD activity and the corresponding System Actor.
This step creates the Personas, which are User archetypes that encapsulate all the knowledge gathered by interviewing numerous concrete current or potential Users of the product(s). For each User that is identified as needing a specific Interface to the product, a different Persona is created that details the typical User's goals, tasks, and skills. Personas are currently described in textual documents. Figure 15 shows an extract of such a document.
Figure 15: Personas document
The use of a descriptive language to capture information gathered in interviews has some negative impacts on the formal definition of the needs and interfaces for the system(s) and product(s). Therefore, a new formal representation of a Persona's goals, skills, and duties is introduced using the following UML artifacts.
- A UML class diagram representing system requirements initiated by the User Roles, modeled as
Userprototyped system actors named after the roles. This diagram has already been shown in Figure 13, and represents the System Use Case Model. - A UML class diagram representing the User Goals as
UserGoalprototyped classes, each having a set ofMeasureprototyped measure attributes. The measures describe ways to measure how each goal is met. How each UserGoal is related to each User is also captured in the diagram. The relations are dependencies between a User and each UserGoal.Figure 16shows one such UML class diagram.
Figure 16: Users, User Goals, and Personas
Also in this diagram, each Persona is shown as a class having a set of skill prototyped skill attributes. Each Persona is associated to all the users (User Roles) it covers, and is flagged with the stereotypes of primary persona, secondary persona, supplemental persona, negative persona, and so on. This is useful to make a linkage and validate the relations between the Personas and the actual system actors that are determined (or possibly reverse-engineered) during the analysis phase. The Persona class also has attributes that capture information collected through the interviews. Besides skills, this may includes age and type of working environment. Additionally, as with other diagrams, the concept of kernel, optional, and alternative apply to the user role as well, to represent how fundamental each
User Role is to the functionality of the system(s) being designed. This is useful during the prioritization of the systems' features (Use Cases).
A UML diagram also captures which System Use Cases support which user goal. This diagram can also comprise the relations between User Goals and Business Goals, particularly which User Goals support each Business Goal. It is important to understand that this relationship must not be invented; instead it must be derived from the traces between the business model and the system model, with a reverse approach. In particular, the relationship between a specific business goal and a user goal comes out of the traces between the business use case realizations that support the business goal, and the corresponding System Use Cases that support the user goal. Figure 17 shows one such UML class diagram.
Figure 17: Relationship between Use Cases, User Goals, and Business Goals
All the figures shown in this article come from a real world example to study improvements to its operational GUI. In the next article, the conceptual design of a system will be developed. Such a design will leverage the findings modeled here, and will continue to trace the business requirements down to the UI and the system designs.
Learn
-
Unified Scenario-Based Design, Part 1: Methodological principles The first part in this set of four articles on the Unified Scenario-Based Design methodology.
-
Unified Scenario-Based Design, Part 3: Conceptual design The third article describes the last set of artifacts that USBD uses to detail the design of the automated system and its user interfaces.
-
Designing Software Product Lines with UML, Hassaan Gomaa - Addison-Wesley, 2004
-
RUP Plug-In for WBI Modeler: Updates the Business Modeling discipline in RUP.
-
Business services modeling: Business services modeling helps bridge the semantic gap between business requirements and the architecture of IT solutions that are intended to meet them.
-
Business Driven Development: Represents an approach to developing business applications that focuses on establishing a clear understanding of the business goals and objectives that are to be achieved, and the roles, activities, and work products involved in analyzing processes, services, and deployed applications necessary to achieve them. BDD rounds out the solution by monitoring applications to collect data on key performance indicators to verify that IT solutions meet their intended business goals and objectives, and to provide a concrete foundation for evolving the business to reduce costs and provide increased value.
-
WebSphere Business Modeler: Enables business
analysts to easily create, simulate, and vary business process models to ensure business goals and objectives are met.
-
IBM Rational Software Architect product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Software Architect.
Get products and technologies
-
IBM Rational Software Architect: Download a trial version from developerWorks. Provides the tools needed to view the Business Contract Model and develop service realization models that can be used to generate implementation code for different architectural styles.
Discuss
-
Rational Software Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.
Alex Donatelli is a Senior Technical Staff Member at IBM. He is the Chief Architect of the Tivoli Laboratory in Rome, Italy and the Manager of the Rome Central Architectural Team. He has been working with both his staff and the overall technical community in Rome and in Tivoli to improve the quality of the products. The Unified Scenario-Based Design work is one example of such efforts.
Roberto Longobardi is an Interaction Solution Designer at IBM. He has been working in several Tivoli development projects, in the areas of performance and availability and of workload management. Recently challenged to provide a redesign hypothesis for the IBM Tivoli Workload Scheduler user interface, he sought to greatly enhance the consumability of the solution by getting it nearer to its business and operational contexts. Unified Scenario-Based Design is the result of this joint experience with the Rome Central Architectural Team.
Rosario is a Senior Software Engineer in the Tivoli Laboratory in Rome, Italy. He is the lead Architect for IBM Tivoli Configuration Manager, with 15 years experience in software development as a software engineer, market manager, and people manager. In his various roles he has been architecting, designing, sponsoring, and driving implementation of complex enterprise applications. He works with partners and customers and has lengthy experience translating business needs into product and solution requirements. He received his master's degree in Physics from the Universita' di Messina.
Claudio is currently a Senior Software Engineer and the chief designer for IBM Tivoli Configuration Manager, with 14 years of experience in developing and designing enterprise applications in the system management arena. He is considered a key expert in the RUP and J2EE, and his current focus is in software engineering best practices and Model-Driven Architecture.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
