From Business-Process-Analysis to IT-System-Modelling

List of contents

1. Preface

2. The nature of the task
2.1 Business-Processes and IT-Application-Systems
2.2 Business-Process-Analysis and –Modelling
2.3 Increasing the creation-of-value of IT-Applications-Systems
2.4 IT-Applications-System-Modelling

3. Business-Process- Modelling (BPM) and IT-System-Modelling (ISM)
3.1 Predication to Business-Process-Management
3.2 Description of UML for Business-Analysis and IT-System-Modeling
3.2 Modelling business Use-Cases
3.3 Business Activity Diagrams
3.5 Sequence Diagrams
3.6 State Diagrams
3.7 Class Diagrams

4. Solely BPM tools without UML relationships
4.1 “hyScore ProcessClient”
4.2 “SYCAT”

5. BPM- and ISM-tools with strictly UML-compliance
5.1 Development Process and Tools from Rational
5.1.1 Overview of “Rational Unified Process” (RUP)
5.1.2 Rational’s “XDE Developer”
5.2 “Together”

6. BPM- and ISM-tools with UML-compliance and proprietary extensions
6.1 “Select Component Architect”
6.2 “Enterprise Architect”

7. BPM- and ISM-tools with UML-compliance and comprehensive abilities
7.1 “ARIS Web Designer”
7.2 “Innovator”

8. The significance of object-orientation versus function-orientation

9. The significance of Modelling with UML- and XML-Notation

10. Assessments of tested BPM- / ISM-tools
10.1 Criteria of the Assessment
10.2 Estimation of evaluation-criteria

11. Conclusion

12. Appendix
Abbreviations
Indices
List of diagrams
List of diagrams
List of screenshots
List of figures
References
Copyright

ABSTRACT

Most companies are faced with slower growth and stronger competition nowadays. Gaining and maintaining competitive advantages becomes crucial for superior performance. Resent analysis show that competitive advantages grows increasingly out of the value of IT-Solutions. CIO therefore are urged to measure the value of their IT solutions in terms of their contribution to the companies success. In monetary terms, IT value represent the amount customers (internal and external) are willing to pay for their IT Applications. Corporate-Governance is faced with the challenge to develop and implement a meaningful IT-Strategy. Which goals should be traced in the IT-Business-Unit and which context exist between IT-Application-Systems and business- processes that are more or less supported by IT-Applications. IT-decisions typically have enterprise-wide significance and Business-Process-Reengineering (BPR) is hard to imagine without IT-Application-Systems changes. The enlargement of the value of IT through innovation and integration is the corporate goal.

To improve the benefit of IT-investments, their impact on real existing business-processes must be analysed and proven. In the past, several IT-Applications were developed or implemented (purchase-software), which have not been applied for Business-Process-Reengineering but only for the support of various business-functions. By this investment pattern, the economic benefit of these IT-Applications can not be assessed. Ideally, each IT project should be embedded in a strategically business context and a holistic IT architecture. Modern object-oriented software- development is more and more driven by Model-Driven-Architecture (MDA), which is based on the Unified Modelling Language (UML). This is the key driver for software-supported Business- Process-Analyse (BPA) and –Modelling (BPM) to generate Business- and IT-System-Models in UML-notation.

The most existing Software-tools for Business-Process-Analysis (BPA) are geared towards standardized norms as quality assurance ( ISO 9000 ff) or EFQM which does not support direct the IT-development-process. In this sense there is a semantically gap between BPM and IT- System-Modelling (ISM). In this work, theoretically desirable requirements at software-tools will be discussed and exemplary, available software-products on the market separated into four groups which cover the bandwidth from complete independent UML-tools via strictly UML- centred tools to comprehensive UML based tool-suites will be assessed. Thereby will be clear that methodical assistance concerning BPA and object-orientation is absolutely necessary.

1. Preface

This Masterwork comprises the analysis and documentation of business-processes and the object-oriented modelling of IT-Application-System in view of IT-System-Development. The main point of interest of the work lies on the connection between business-processes and IT- Application-Systems. Observations shows there are most often fractures between the business- processes and their supporting IT-System-solutions. New software bundles try to bridge that gap to achieve full IT-System and business-process integration

illustration not visible in this excerpt

Figure 1: Fractures between business-processes and IT-applications

For both areas exists Software-tools which however have respectively their focus on either Business-Process-Modelling (BPM) or IT-System-Modelling (ISM). Some Software tools use the Unified Modelling Language (UML) to describe models, other are based on UML, but use proprietary extensions and again other have nothing to do with UML. Because IT-System- solution influence business-processes and vice versa, both domains have to be coupled and flexible constructed in order to react fast upon changes on the market.

UML has become important for the construction of the architecture of modern object-oriented IT-Application-Systems. The language enables Code-generation in several programming languages which is called Model-Driven-Architecture (MDA) or Model Driven Design (MDD). A rough description of the language and their relevance in view of BPM and ISM is made in chapter 3. Close integration between BPM and Component-Based-Development (CBD) based on UML-Modelling helps IT-solutions address the needs of Business-Process-Reengineering (BPR) or Business-Process-Improvement (BPI) tasks. BPM means more efficiency (doing the things right) and more effective (to do the right things). First step is the description of the nature of the task and the coherence with existing software-tools with which either business-processes or IT-Systems can be designed. In the second step real software-tools will be evaluated.

In chapter 4, two BPM-Products without UML relationships, but with other strong features are tested. There are many similar products on the market which could be selected as well. Chapter 5 comprises two major player for IT-System-Modelling with UML. Chapter 6 covers two relative new closed products which seem to be progressive and easy to use and in chapter 7, further two almost classical BPM tool-suite will be tested which propagate proprietary modelling solutions, but can also support UML conformal diagrams. All tested products have their individual strength, but in view of performance of the chosen tasks, namely to model business-processes and IT- Application-Systems with one and the same tool, there are big differences. Why this is meaningful, will be articulated in chapter 8 and 9. Subsequently all rough described Software- tools will be assed according essential criteria and the estimation will be graphically presented.

2. The nature of the task

2.1 Business-Processes and IT-Application-Systems

Business-Process-Analysis is very important for optimising the traditional function-oriented structure of business-units. Some typical problems in not effective organisation structures are:

- Unclear responsibilities
- Missing overall-view
- Missing transparency of processes
- Forecasts of handling times are not possible
- Media breaks in processes
- High variance in accountable conditions
- High Process-costs

illustration not visible in this excerpt

Department walls

Traditional sequence Process oriented view

Figure 2: Function- and Process-view

The confrontation between functional- versus process oriented structures has been often debated. If the employee has little special knowledge and there are high resources of being divided, process oriented structures are more advantageously. On the other hand, if the worker have much special knowledge and there are few resources of being divided, a function oriented organisation structure is better.

In this sense Business-Process-Analysis is a widely spread method to improve the efficiency of the business. Several standards give guidance in doing so, for instance DIN EN ISO 9001:2000 and 9004 ff or EFQM. Many IT-Products or software-tools support the analysis in documenting the flow of a activities and their environment.

The process of IT-Application-Development led to a change in paradigm towards object- orientation during the analysis, design and programming phase. OOA, OOD and OOP are the abbreviations of these new standards. The modelling of object-oriented IT-Applications has become important because of the increasingly complexity of Client-Server-Systems.

A modelling language called Unified Modelling Language (UML), defined by the Object management Group (OMG), has been established and new Software-tools support not only the definition of object-oriented Software-Systems good, but also the generation of code such that the programming of applications has become more efficiently.

But although the software-engineering-process becomes more professional, more and more IT- Application-Systems will be reviewed with respect to their impact on real business-processes and especially in viewing to the business efficiency.

Only well supported business-processes justify the investment in expensive IT-developments. Because innovation in business-processes is most often based on the application of IT-Systems, business-processes should be analyzed and designed in view of IT-System-Development.

In order to use an integrated tool-platform in which all information concerning business- processes are collected together, standard business-process-documentations-tools should be extended to support IT-System-Development, or existing IT-modelling-tools should be expanded to support well the business-analysis-process. A business-process involves the following element:

- has an owner (person)
- starts after an events which drives the process
- has a goal or reason for the process
- needs specific inputs (information)
- uses resources
- produces specific outputs
- consists of a number of activities that are performed in some order
- can affect more than one organizational unit. Have a horizontal organisational impact

illustration not visible in this excerpt

Figure 3: Interfaces of a business-process

A business-process has a well defined goal. This is the reason the organization does this work, and should be defined in terms of the benefits this process has for the organization as a whole and in satisfying the business needs. A goal is the business exculpation for performing the activity. The link to object “Goal” refers to the object which describes the goal of the process. The link from object “Event” indicates some object is passed into a business-process. It initiates the passing of control to another entity or process, with the implied passing of state or information from activity to activity.

Business-processes use information to tailor or complete their activities. Information, unlike resources, is not consumed in the process - rather it is used as part of the transformation process. The formation may come from external sources, from customers, from internal organizational units and may even be the product of other processes. The supply link from the object “Information” indicates that special information are used as part of this activity.

Business-processes need also resources as input which will, unlike information, typically be consumed during the processing. The input link from object “Resources” indicates that attached objects or resources are consumed in the processing procedure.

A business-process will typically produce one or more outputs of value to the business, either for internal use of to satisfy external requirements. An output may be a physical object (such as a report or invoice), a transformation of raw resources into a new arrangement (a daily schedule or roster) or an overall business result such as completing a customer order.

An output of one business-process may feed into another process, either as a requested item or a trigger to initiate new activities. The output link to object “Value” indicates the passing of control to another entity or process with a higher state of value.

2.2 Business-Process-Analysis and –Modelling

A business-process is a collection of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how the work is done within and organization, in contrast to a product's focus on what. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs in other words, a structure of actions with their surrounding prerequisites and boundary conditions.

Optimization of business-processes is continuous challenge. While production processes has been considerably cute down are administration processes more and more in focus. Increasing quality requires also process improvement. Basis for documenting business-processes can be the series of ISO 9000 ff documents or other standard notations.

According to ISO 9001:2000 business-processes are subdivided into leader's processes (like controlling functions), central processes (like procurement functions) and support processes (like maintenance). The intrinsic creation-of-value will be achieved within the central processes. A customer pays only for the creation-of-value. A public service enterprise for example does services in form of service-products for the general public.

In order to optimise business-processes, existing business-processes have to be identified, analysed, documented and new one have to be modelled. On principle of cause and effect new created business-process become more slender in order to achieve the goals of higher process quality, shorter processing times, reducing interfaces and consumed resources. Also fewer media breaks and higher data consistency can be aimed goals.

All activities within an organisation can be classified in one of the three categories depicted in the next figure. The attention for Business-Process-Improvement should lay on the central process because by them the creation-of-value for which the customer is willing to pay does happen.

illustration not visible in this excerpt

Figure 4: Fundamentally structure of company processes

Each process-step needs inputs (at public service enterprise often information), processes something (activity / function) and creates thereby a value increasing output which (within the creation-of-value-chain) is the input for another process-step. Processes can run parallel or be cross-linking so that one can speak of a process topographic map.

After having analysed relevant selected business-processes, they should be reflected against the strategy and goals of the levels of organization. Sometimes the analysis will bring up details about processes, which do not fit in one of the three process-categories and are not really necessary since they produce no value increment. They produce only apparent- or reactive- power (e.g. redundant clerical work).

To enable an enhancement in value of the produced services by the company in view of cost- reduction or quality-enhancement, a process with the target to reengineer business-processes (which in the outcome most often defines a reduction of necessary process-steps) has to be introduced.

Also the distinction of strategic relevant processes and other processes is helpful in order to decide about desired investments. Most often a business-process can be improved by a reductions of activity-steps, minimization of interfaces between involved business-units or by automation through IT-System-Implementation. In order to improve business-processes, process-ratios are required. These entails in most cases automated creation.

2.3 Increasing the creation-of-value of IT-Applications-Systems

Create synergistic effects by way of system-integration because in these cases 1 + 1 are 3 and therefore more than the sum of the individual solutions. Integrated IT-systems can be used as a comprehensive communications instrument. But business-alignment is absolutely necessary.

To demonstrate the business-value by naming of IT trends and their impact to the business is the task for the IT-management.

illustration not visible in this excerpt

Diagram 1: Possible positioning of IT-Services within a company

The alignment of the IT will be influenced by the place of value that their customer are willing to concede them.

Cost factor: IT delivers services to the most favourable costs

Property asset: Use of IT to reduce costs and for provision of service quality

Partner: IT will be included from customer during planning for new area of operation

Enabler: IT researches and recommends new strategies in order to achieve business- goals

In order to range the different views of processes within an IT-division and the supported business-processes as well, a structure of all essential views might be reasonable: Integration- aspects should be considered at all architecture-levels-levels.

illustration not visible in this excerpt

Figure 5: Possible Enterprise IT-architecture views

2.4 IT-Applications-System-Modelling

Conventional software development breaks down the task into distinct stages such as analysis, design and build. Each has its own methodology, software tools and skill sets. The Unified Modelling Language (UML) has been adopted as a structured way to communicate the business-model to the developers and many projects start with a top-down modelling approach.

UML is standardized by the Object Management Group (OMG) and the most-used specification to models not only application structure, behaviour and architecture, but also business-process and data structure. The process for standardization the Modelling Language is not jet finished.

A good model is essential if the resulting application components are to be maintained, understood and reused. At the next stage in the development process, the business-model has to be transformed into a system architecture leading to the creation of another set of models.

Finally, developers implement and refine the code. But a problem arises when the code is built and refined, because the business-model, application model and implemented code can easily drift apart.

Without consistent models the costs of maintenance increase, changes to the functionality are fraught with difficulty and delay, and reuse is impossible because no high level model exists that accurately describes the implemented system.

Accurate models are important at many levels. In the business-analysis phase they promote full participation of business-managers and encourage refinement of the business-models so that the implemented system brings maximum benefit to the organization. With an accurate overview of the application, reuse of business-components is made possible, which leads to further benefits of lower-cost development and accelerated delivery.

At the technical level, quality is improved by ensuring that the generated code conforms to tried and tested blueprints. Applications are easier to maintain and improve and more development resources can be targeted at new functionality; less at maintenance.

Service Oriented Architecture (SOA) is important for Enterprise-IT because it provides the framework that unites the business-model with the applications that provide the functionality required for efficient business. Without SOA, IT systems become a disjointed collection of packages, functions and screens that consume ever-increasing resources to maintain and evolve.

SOA imposes a direct correlation between business-operations and software services, making it a simple task to maintain and re-factor new systems from existing services. Web services are the parts of the SOA vision that provide easy connections across the Internet and self-describing service interfaces. This is the important enabler for business-integration and distributed commerce models.

Model-Driven-Architecture (MDA) is also contributing to the business with the strategy to adopt SOA to make IT easier and faster to achieve the goal. The model-driven approach ensures that the services on which applications are based are consistent and business focused. Governance ensures that the models and architectures are not compromised in the implementation.

MDA describes the mappings needed to transform one model to the next and also describes the refinement and reuse of components in both the PIM and PSM. MDA builds on existing XML standards; for example, UML uses the XML Metadata Interchange (XMI) standard to communicate structure of objects and interfaces and Meta Object Facility (MOF) is used to describe objects.

The Object Management Group (OMG) describes separate models; the Platform Independent Model (PIM) and the Platform Specific Model (PSM), which maps to code to create a viable application. Platform Independent Models provide formal specification of the structure and function of the system and are independent of the computing platform. This model contains the business-objects and services.

The new UML 2.0 capabilities allow analysts to specify business-objects and services. Models can also be imported or exported from UML tools.

Platform Specific Models are generated automatically from the PIM and contain components that apply to the target platform and architecture. In this model the technical architecture is now visible at the level of components, web pages, DBMS and services.

The following figure illustrates how the business-model is transformed via the application models PIM and PSM into working code:

illustration not visible in this excerpt

Figure 6: Schematic process of IT-Application-System-Development

The whole development process should become performed object oriented (oo) because:

“Object modelling produces a useful model for system developers that is also closely aligned with the organization of the business model. Business data, rules and processes are organized around conceptual objects representing the people, places, things and events involved in the business” [REF11, page 3].

Business process modelling is a process in its own right encompassing several activities (tasks) like process analysis, process design, process simulation and process optimization. To support the sharing and reuse of formally represented knowledge among all participants, it is helpful to define a common vocabulary in which shared knowledge is represented. This specification of representational vocabulary for a shared domain of discourse is called an ontology. It is the task to translate facts of the case from a very expressive language into a restricted language in order to achieve computational efficiency of implemented systems and person-independence.

3. Business-Process- Modelling (BPM) and IT-System-Modelling (ISM)

3.1 Predication to Business-Process-Management

Business-Process-Management (BPM) connects business-processes with IT. Many conferences, forums and companies are predominantly related to this subject. An earlier used name fore this matter was Enterprise-Application-Integration (EAI). Business-processes and their mapping into the IT-world of a company is the centre of management thoughts.

Thereby the integrated support of hole processes is evident important. The cycle steps are analyse, modelling, implementing, operation and again evaluating. The better a BPM-Solution supports the complete circuit (without system- and media break) the greater is their potential added value. It is much talked about Business-Process-Reengineering and Business-Process-Modelling.

There are by now many graphical tools available to model processes, which are integrated with workflow engines that automatically manage single process steps. Professional experts so called Business-Analysts shall be enabled to model business-processes. The underlying Implementation layer shall than go beyond automatically be generated and become adapted. With that vision development- and maintenance costs of business-processes could be significant reduced and the ability to adapt new requirements could be improved. In this context process- ratios (perspective of Balanced Scorecard) play a very important role.

Special significance have monitoring and query report of process executions. Until now the management could only have such reports time delayed. In the future there will be a real-time cockpit available which shows graphically production- and even office efficiency. For this there will be collected execution data in a Date Warehouse and evaluated. With BPM the following fundamental advantages are aimed:

- Higher transparency of corporate work flow
- Higher flexibility to react on market chances
- Active collaborator-ship of co-operators into achieving strategic business goals
- Direct feedback of measured process performance in order to insure continuing process improvement
- Compliance to enterprise standards and unifying of business-processes
- Simplification of decision making by definition of business-rules
- Optimal co-operator motivation
- Overall custom orientation

The main business-process related expected benefit-effects of BPM are:

- Reduction of reactive power (operations for which no internal or external customer can be found)
- Reduction of process time and thereby delivery times
- Reduction of consumed resources
- Enhancement of faithfulness to deadlines

With this background IT vendor and management consultancies are convinced that companies will invest in consulting service and software solutions.

3.2 Description of UML for Business-Analysis and IT-System-Modeling

The Object Management Group (OMG) specification states:

“ The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing and documenting the artefacts of a software-intensive system. The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas and reusable software components”.

UML is, as its name implies, a modelling language and not a method or process. UML is made up of a very specific notation and the related grammatical rules for constructing software models. UML itself does not proscribe or advise on how to use that notation in a software development process (as part of an object-oriented design methodology) or as describing business- processes.

UML supports a rich set of graphical notation elements. All diagrams can be distinguished in those which describe a static structure and those which describe the dynamic behaviour of items (things). UML describes the notation for classes, components, nodes, activities, work flow, use cases, objects, states and how to model relationships between these elements.

The UML provides significant benefits to software engineers and organisations by helping to build rigorous, traceable and maintainable models, which support the full software development lifecycle.

Modelling the business-process is the starting phase of any software development process. It allows the analyst to capture the broad outline and procedures that govern a business-process. This model provides an overview of where a proposed software system could be considered. How it could fit into the organisational structure and the daily activities.

It may also provide the justification for building a new system by capturing the current manual and automated procedures that could be migrated into a new It-System, and the associated cost benefit.

Insofar describing the business-processes with UML diagrams can not only be the basis to analyse processes in view of optimizations but also ideal for IT-System-Modelling (ISM). As an early model of business-activity, it allows the analyst to capture the significant events, inputs, resources and outputs associated with business-process.

By connecting later design elements (such as Use Cases) back to the business-process model through implementation links, it is possible to build up a fully traceable model from the broad process outlines to the functional requirements and eventually to the software artefacts actually being constructed.

As the Business-Process-Model typically has a broader and more inclusive range than just the software system being considered, it also allows the analyst to clearly map what is in the scope of the proposed system and what will be implemented in other ways (eg. a manual process). In that sense it has to be differentiated between actual state analysis and scheduled conceptions. Both can be accomplished and developed with the UML.

Using Executable UML (xUML), developers can build UML models that can not only be unambiguously interpreted by human readers, but also be tested and validated through actual execution, and ultimately translated directly and completely to target code.

This technology offers immense potential for accelerating development projects, enhancing reliability, and reducing cost. One speaks in that context also about Model-Driven-Architecture (MDA) if at least an applications architecture can be generated, ore even of Model Driven Development (MDD) if even more function oriented code can be generated. In all cases the target IT-Systems are object-oriented implemented. In the interconnection of UML-Model and the respective real Implementation synchronous ness is important.

At present UML specification version 1.5 is announced and available. Version 2 which is under review will consists of the following 13 diagram-types:

illustration not visible in this excerpt

Figure 7: All Diagram-types in UML 2.0

Diagram-types which are relevant for Business-Process-Modelling are Abbildung in dieser Leseprobe nicht enthalten coloured.

In order to generate advanced source code in the target programming language it is of course not only enough to create some diagrams instead many more detail information has to be specified. These are first all relationships between diagram-symbols which will be in regard to consistent be checked all the time. Furthermore important are detail information concerning data structures (signatures) necessary for operations, constraints for ranges of values and other properties of entities.

All possible graphical symbols within the behavioural diagrams available in UML version 2 are depicted in the following screen shot which was copied from the product “Enterprise Architect”.

illustration not visible in this excerpt

Screenshot 1: All Diagram-symbols within UML behavioural diagrams

UML supports an in built mechanism potentiality for logically extending or altering the meaning, display and syntax of a model element. This is achieved by a number of stereotypes. Different model elements have different possible stereotypes associated with them. The OMG UML specification states:

"A stereotype is, in effect, a new class of metamodel element that is introduced at modeling time. It represents a subclass of an existing metamodel element with the same form (attributes and relationships) but with a different intent. Generally a stereotype represents a usage distinction. A stereotyped element may have additional constraints on it from the base metamodel class. It may also have required tagged values that add information needed by elements with the stereotype. It is expected that code generators and other tools will treat stereotyped elements specially. Stereotypes represent one of the built-in extensibility mechanisms of UML."

By way of stereotyping model elements they will be different generated. Further, self defined stereotypes can be added to diagram elements.

3.2 Modelling business Use-Cases

The primary purpose of describing or modelling business use-cases and actors is to describe how the business is used by its customers and partners. Activities that directly concern the customer or partner, as well as supporting or managerial tasks that indirectly concern the external party can be presented. The model describes the business in terms of business use- cases, which correspond to what are generally called "processes".

A Use Case within an IT-System model represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour. Use Cases are related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.

illustration not visible in this excerpt

Diagram 2: Example Use Case Diagram of a product payment process

This diagram details the possible ways in which a system can be used, which are the Use Cases and the way in which actors in the system perform the Use Cases. They provide a basis for further analysis phase and provide a means of driving units for incremental delivery. They also provide a means for users to understand functional requirements upstream in the process and provide traceability to downstream test plans. Use Cases can therefore be used to define business-requirements in view of IT-System-Solutions.

3.3 Business Activity Diagrams

An activity diagram of a business use-case describes the ordering of tasks or activities that accomplish business-goals, and that satisfy commitments between external business-actors and internal business-workers. An activity may be a manual or automated task that completes a unit of work. In that sense activity diagrams help to archive an understanding of the introduction of application systems into the business.

The purpose of the activity diagram is to model the procedural flow of actions that are part of a larger activity. In projects in which Use Cases are present, activity diagrams can model a specific Use Case at a more detailed level. However, activity diagrams can be used independently of Use Cases for modelling a business-level function, such as buying a concert ticket or registering for a college class.

With activity diagrams objectives can be establish for system development projects to implement business transformation initiatives and justify automation investment based on detailed business-process metrics.

Because it models procedural flow, the activity diagram focuses on the action sequence of execution and the conditions that trigger or guard those actions. The activity diagram is also focused only on the activity's internal actions and not on the actions that call the activity in their process flow or that trigger the activity according to some event .

Although another diagram type by name the sequence diagrams can contain the same information as activity diagrams, the activity diagrams are more applicable for modelling business-level functions. This is because activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram typically shows only one flow of an activity.

In addition, business-managers and business-process personnel seem to prefer activity diagrams over sequence diagrams because it is less technically in appearance and therefore less intimidating to business-people. Besides, business-managers are used to seeing flow diagrams, so the "look" of an activity diagram is familiar.

An activity diagram with swim lanes and object flows focuses on how one divide responsibilities into different entities (people, things, and data) relate to each other which are later called classes, whereas the sequence diagram helps to understand how objects interact and in what sequence.

If an activity diagram uses swim lanes and the swim lanes are coupled to classes (mainly business-workers) in the business-analysis phase, one can use this diagram type to document business use-case realizations, rather than business use-cases. As an example, follows an activity diagram of the realization of the business use-case Proposal process.