Главная » Периодические издания » Resource rule patterns
2 3 4 ... 28
resource rule patterns
To identify the proper requirements on the software systems is not the only reason to do business modeling. Business modeling creates an abstraction of a complex business and establishes a common understanding that can be communicated to the businesss stakeholders (e.g., owners, management, employees, and customers). A better understanding of how the business functions facilitates improvements to the business, and helps to identify new business opportunities (i.e., business improvement or innovation).
Although UML in its first years has been used mainly for modeling software systems, it is also a very suitable language for business modeling. It has the ability to describe both the structural aspects of a business (such as the organization, goal hierarchies, or the structures of the resources), the behavioral aspects of a business (such as the processes), and the business rules that affect both structure and behavior. Many developers are already familiar with UML since they have used it to model software. Using the same modeling language for both business and software modeling ensures that the documentation is consistent and facilitates communication between business modelers and software modelers. In addition, a large amount of tools become available for use in business modeling when you use UML.
This book shows how to use UML for business modeling, and how to use the business models to identify the correct requirements for the software that supports the business. We use standard extension mechanisms, such as stereotypes, to define new model elements suited for business modeling. This book also presents guidelines for how to produce a business model and what it should contain. It introduces you to how to define business rules using the Object Constraint Language (OCL).
To help you get started with business modeling using UML, 26 business patterns are provided. These patterns are working, reusable, and illustrative examples of how different aspects of a business can be modeled. In addition, youll learn how the information and knowledge in a business model can be used to identify the proper requirements on software systems that support the business, as well as how the information can be reused in the software models.
Finally, youll find an example business model. The model applies the concepts, steps, and patterns described through out the book to an example mail order firm that has to migrate into the new world of e-business and network economy. This example is based on our experience modeling these types of projects. The company is fictitious, but the business structure is based on existing businesses.
What the Book Is and Is Not
This book provides valuable information that will help you to effectively use UML to model your business. Youll learn:
A combination of techniques that melts knowledge and experience in the
business modeling field together with object-oriented modeling.
An approach that shows how to use the well-established UML language for
business modeling. UML has so far been used mostly for modeling software systems.
A set of business extensions, the Eriksson-Penker Business Extensions to UML,
that extend UML with adapted model elements for business modeling. The extensions are defined using the standard extension mechanisms in UML.
New techniques, such as the Assembly-Line diagram, that integrate the
business processes in a business model with the use-cases to define functional requirements on a software system.
Common business modeling experience and knowledge packaged in the form of
reusable patterns (Resource and Rule Patterns, Goal Patterns, and Process Patterns).
An approach to designing support systems that are in harmony with the business
they are supposed to support.
Many powerful examples of business models and illustrations of non-trivial
features of the UML language, such as powertypes and stereotypes.
A practical and pragmatic approach to doing business modeling with UML, an
approach that can be used together with other techniques or methods. This book is not:
A new method for either business modeling or software modeling. Most of the
ideas presented are acknowledged techniques for modeling, but have not been used with UML before.
A book describing the UML language in detail. There are other books for this,
such as our previous book UML Toolkit [Eriksson 98][-]
A programming book. The models in this book do not model programs and
should not be translated into code. The models, however, can be the basis for other UML models that model the software in an information system.
A book about object-oriented technology. Knowledge of the basic concepts of
object-oriented technology are required for reading this book.
A substitute for doing bad analysis. A very important factor for succeeding with
business modeling is staffing the project with knowledgeable, experienced, and dedicated people. There is no silver bullet in business modeling either.
A book showing statistical proof of the success rate of these techniques. The
techniques presented are based on well-established theories and have been used in practice for many years (though not necessarily using UML as the modeling language). There is a vast world of literature related to business modeling that provides further proof of the success of these techniques.
-[Eriksson 98] Eriksson, Hans-Erik and Magnus Penker. UML Toolkit. John Wiley & Sons, Inc., 1996.
Who Should Read This Book
This book is for you if:
You want to understand the concept of business modeling for creating
abstractions of your business that in turn can be used to communicate, improve, or innovate the business.
You want insight into how UML can be used to describe the complexities of a
business instead of just software systems.
You are a software manager or developer who is looking for an answer to
questions such as But what should I do before I start producing the software system? and How do I know if I have identified the proper requirements (e.g., use cases)?
You are an analyst or a modeler who is looking for working and reusable
patterns that demonstrate how the processes, resources, rules, and goals of a business can be modeled.
You are an experienced business modeler who wants to understand how UML
can be used in a business context, and how business modeling can be integrated with software development.
You are a CASE Tool vendor who would like to integrate business modeling
features with software engineering features in your tool.
You should have a basic knowledge of object-oriented concepts and of UML.
How this Book Is Organized
Chapter , Business Modeling, presents the concept of business modeling and the purposes for modeling a business. It also provides arguments for why UML is suitable for business modeling and what elements are required in UML to do business modeling. Chapter , UML Primer, is an overview of the UML language. If you are proficient in UML, feel free to skip this chapter. There are, however, some important sections on activity diagrams, powertypes, and UML extensions that highlight some areas of UML that are relevant to business modeling and the rest of the book.
Chapter , Modeling the Business Architecture, defines the major concepts used in business modeling: processes, goals, resources, and rules. It also introduces the Eriksson-Penker Business Extensions that are defined using the standard extension mechanisms in UML to facilitate business modeling.
Chapter , Business Views, describes the different views of a business model. It defines the techniques and diagrams used to capture a specific aspect of a business, and provides examples to illustrate their use.
Chapter , Business Rules, describes how to define business rules using the Object Constraint Language (OCL), part of standard UML. Examples show you how to use different categories of rules in all of the views in order to regulate how to run and structure the business. We also introduce Fuzzy Business Rules, a technique for defining rules without ordinary binary logic.
Chapter , Business Patterns, introduces the 26 business patterns, common solutions to business modeling problems, that are covered in chapters 7 through 9. The chapter defines a pattern, its structure and characteristics, and how patterns are represented in the UML language.
Chapter , Resource and Rule Patterns, describe patterns that can be used to resolve typical problem situations that can arise when modeling the structures and relationships (including rules) between resources.
Chapter , Goal Patterns, describes patterns for defining the goals of a business. Goals are what the business and their corresponding models strive for, and form the basis for designing the processes, finding the right resources, and tuning the business rules. Chapter , Process Patterns, defines high quality, well-proven, and easy-to-use patterns that are used to model business processes. The chapter defines the different categories of process patterns, and covers important areas such as layering, decomposition, interaction, process type and instance, and workflow. Chapter 10, From a Business Architecture to a Software Architecture, discusses how the business model is used to produce the businesss supporting information system. The business model identifies the requirements on the information systems (the use cases of the system), and can also be used to define the architecture of the information system. Using the same business model for several information systems also helps to create systems that are more easily integrated with the business they support. Chapter 11, A Business Model Example, demonstrates how the techniques and notation defined through out the book can be used to model a practical example of an ebusiness. The business views, business extensions, business rules, and business patterns are demonstrated in this case study.
Weve also included additional resources, a visual glossary of the Eriksson-Penker Business Extensions, a table summary of the Business Patterns, and a glossary. Also visit the Web site at www.opentraining.com/bm/ for further articles, information, and links on subjects related to the book, as well as our recommendations for tools that support business modeling. You can also contact us through our email addresses firstname.lastname@example.org and email@example.com.
Chapter 1: Business Modeling
Running a business today is more competitive than ever. The globalization of world markets, brought about by technology in general and the Internet in particular requires businesspeople to acquire and adapt to new business logic. Anyone who doesnt continuously strive to improve the operation, products, and services of their business will find it difficult to succeed in this challenging environment.
To keep up and remain competitive, companies and enterprises must assess the quality of their products and the efficiency of their services. In doing so, they must consider the world around them: their competitors, their subcontractors, their suppliers, the ever-changing laws and regulations, and, above all, their customers. They must also
objectively examine their products or services, asking such questions as: Is my internal operation working smoothly? Can I improve my product or service in any way? Is production running as efficiently as possible? Can I expand my product or service portfolios to reach new markets and customers?
Todays businesspeople must also evaluate their information systems: Do they effectively support their way of working? Do the systems adapt easily to change? Is information used as an important strategic resource in the business? Is the information adequate and correct? All businesses will benefit by gaining a deeper understanding of how their business interacts with its environment, which comes from honestly answering these questions.
In todays marketplaces, information systems no longer merely support businesses. Increasingly, they are an integral part of them. All businesses make some use of information technology, and it is important that their systems be designed to support them. The business is, after all, what defines the requirements of the information systems.
To answer these questions, it is essential to make a model of the business, a simplified view of a complex reality (Figure 1. ). It is a means of creating abstraction; it enables you to eliminate irrelevant details and focus on one or more important aspects at a time. Effective models also facilitate discussions among different stakeholders in the business, helping them to reach agreement on the key fundamentals and to work toward common goals. Finally, a business model can be the basis for other models, for different information systems that support the business, for example. Modeling is an accepted and established means of analyzing and designing software. To create appropriate software, the businesses in which the software systems operate must also be modeled, understood, and improved as required.
Figure 1.1: A business model is a simplified view of a business. A business model is an abstraction of how a business functions. Its details differ according to the perspective of the person creating the model, each of whom will naturally have a slightly different viewpoint of the goals and visions of the business, including its efficiency and the various elements that are acting in concert within the business. This is normal, and the business model will not completely resolve these differences. What the business model will do is provide a simplified view of the business structure that will act as the basis for communication, improvements, or innovations, and define the information systems requirements that are necessary to support the business. It isnt necessary for a business model to capture an absolute picture of the business or to describe every business detail.
The business model is the focal point around which business is conducted or around which business operations are improved. The evolving models also help the developers structure and focus their thinking. Working with the models increases their understanding of the business and, hopefully, their awareness of new opportunities for improving business.
The word business in this context is used as a broad term. The businesses that can be modeled with the techniques presented in this book do not have to be profit making (e.g., a relief organization for the homeless or for war victims is also a business that needs to be organized as effectively as possible). Any type of ongoing operation that has or uses resources and has one or more goals can be referred to as a business. The owner of the business sets the goals and allocates resources to make the business run. The business modeler then creates the structure, designs the processes, and allocates the resources in order to achieve the goals. The system developer then adapts, designs, or develops appropriate information systems that support the running of the business.
This chapter explores the role of models in general, and how businesses can benefit from using them, and, more specifically, where the Unified Modeling Language (UML) fits in.
The Role of Models
Anyone who has played chess knows that you need a strategy or plan, and that even a bad plan is better than no plans at all. During the game, not everything happens as planned, but the plan nevertheless points in a direction, making the decision-making easier and faster. A more skilled player will change the plan, in part or in whole, during the game and think ahead about alternative moves he or she will take as a result of possible moves by the opponent.
The business model functions as the plan for conducting a business. It acts as the basis for decision-making and affects decisions about prioritizing goals, obtaining the right resources, or negotiating with subcontractors. It also serves as an up-to-date description of how the business is performed, and allows for changes and improvements in the process, such as cutting costs, improving quality, or shortening time-to-market. The model can anticipate and forecast changes that are necessary to maintain an edge on the competition. The model cant provide all the answers, but as for the chess player, it is a basic strategy or plan to follow. An advantage of modeling in a language such as UML is that it visually depicts functions and relationships that are usually difficult to visualize clearly.
Ideally, a business model would consist of a single diagram that included all the important aspects of a business. That is, however, never possible, since a business is so complex and has so many aspects that a single diagram cant capture all that information. Instead, a business model is composed of the following: Views. A business model is illustrated with a number of different views, each of which captures information about one or more specific aspects of the business. A view is an abstraction from a specific viewpoint, omitting details that are irrelevant to that viewpoint. Multiple views are necessary to separate purposes and perspectives in a controlled way, without losing important information about the business.
Diagrams. Each view consists of a number of diagrams, each of which shows a specific part of the business structure or a specific business situation. Several diagrams are necessary to visualize a single view of the business model, since each type of diagram has a different purpose and expresses one important aspect or mechanism within the business model view. A diagram can show a structure (e.g., the organization of the business) or some dynamic collaboration (a number of objects and their interaction to demonstrate a specific process). The diagrams contain and express the objects, processes, rules, goals, and visions defined in the business situation. Objects and Processes. Concepts are related in the diagrams through the use of different objects and processes. The objects are the things in the business; they may be physical, such as people, machines, products, and material, or more abstract, such as debts, instructions, and services. Objects can also represent other objects by containing information about other things in the business. Processes are the functions in the business that consume, refine, or use objects to affect or produce other objects.
A model is motivated by objectives. For example, the purpose of modeling a building might be to construct it or, later, to sell apartments in it. The purpose of modeling a business might be to understand or to improve its functionality. It is important to distinguish models used as an exploration tool from models used as a specification tool (modeling can be used for both). To build a supporting information system, such as a sales system, the surrounding business is modeled in order to understand it, and from that understanding the appropriate information system can be designed. Models facilitate understanding and communicating about systems, but only when the objective of the model is kept in mind. If the objective is to understand a business well enough to specify a supporting system, it is not necessary to model the entire business in detail; producing such a detailed model is simply too time-consuming and too expensive for that purpose.
However, if the goal of a serious business process innovation project is to redefine how the entire business is run and to find new and improved ways of conducting business, a more elaborate effort might be necessary. In any case, it is important not to overwork the models; if you keep the objective of the model in mind at all times, you will profit from business modeling.
Since its introduction in November 1997, the Unified Modeling Language has quickly become the standard modeling language for software development. Many users of other methods (Booch, OMT, Fusion, etc.) have adopted UML; a number of books have been written about UML; and most modeling tools have implemented support for the language. All predictions for the future of UML indicate that it will become even more dominant and important, and that the tool support for producing and exchanging UML models will become more advanced.
The UML consists of nine different diagram types, and each diagram shows a specific static or dynamic aspect of a system. The basics of UML are easy to learn, and very powerful constructs, such as stereotypes or powertypes, are available for the more advanced modeler. Chapter 2, UML Primer, includes an overview of UML and some of the advanced concepts used later in this book.
The UML standardizes notation for describing a process, but it doesnt standardize a process for producing those descriptions (a well-defined order of activities, a set of artifacts produced, and ways to monitor or control the work). UML, in fact, can be used by many different developmental processes, more or less formally specified. This is not an oversight by the developers of UML; a development process for a project involving three persons is very different from a project involving a thousand people who work in different countries. The process is also affected by other factors, such as the type of system or the experience of the developers. Attempts at defini  de facto standards fo development processes, such as the Rational Unified Process1 or Select Perspective2, are often configurable, meaning that they can be adapted or modified to suit the project at hand. It is important to understand that UML doesnt prescribe a specific way of how it should be used in a project; there is no one specific or correct way of using it. Several development processes that use UML advocate that the system development should start with use-case modeling to define the functional requirements on the system. A use case describes a specific usage of the system by one or more actors. An actor is a role that a user or another system plays. The objective of use-case modeling is to identify and describe all the use cases that the actors require from the system. The use-case descriptions then are used to analyze and design a robust system architecture that realizes the use cases (this is what is referred to as use-case driven development).
But how do you know that all of the use cases, or even the correct use cases that best support the business in which the system operates, are identified? To answer such questions, you need to model and understand the systems surroundings.
Modeling business surroundings involves answering questions such as:
How do the different actors interact?
What activities are part of their work?
What are the ultimate goals of their work?
What other people, systems, or resources are involved that do not show up as
actors to this specific system?
What rules govern their activities and structures?
Are there ways actors could perform more efficiently?
The answers to these questions come from tackling the entire business and looking beyond the functions of the information system currently being built (and using
techniques other than use-case modeling). The ultimate objective of all software systems is to give correct and extensive support to the business of which it is a part. However, when modeling the surroundings of the information system, you are no longer modeling software. Enter the world of business process modeling.
[-][Kruchten 98] Kruchten, Philippe. The Rational Unified Process. Reading, MA: Addison-Wesley, 1998.
[Allen 98] Allen, Paul and Stuart Frost. Component-Based Development for Enterprise Systems: Applying the Select Perspective. New York: Cambridge University Press, 1998.
Business Process Modeling
A business is a complex system, consisting of a hierarchical organization of departments and their functions. Some of these functions, however, are not restricted to one department; they cross horizontally across several departments. The traditional method for documenting a business is to draw an organization chart, which divides the business into a number of departments or sections (e.g., research and development, marketing, sales, manufacturing, etc.), represented vertically. This documentation method is limited to how the business is built and organized. It does not document the business processes that flow through horizontally and affect all the vertical departments (e.g., the development of a new product will affect all divisions).
Other structures in the business, such as business processes, resources that participate in or are used in the process, rules that govern the execution of the business, the goals, and problems that hinder the achievement of those goals, cannot be captured in the traditional organizational view. A good business model contains all of this information. Capturing and documenting this information in itself can be the basis for making better decisions that result in a business that runs more smoothly, and better documentation for specifying the requirements of the information system.
In the process modeling field, many different theories strive to explain and improve how to structure and run a business. Very few standards, or even methods, exist in this area, and most of the literature concentrates on how to describe a business rather than on the well-defined techniques for actually running a business. The central concept used for process modeling is the business process, which describes activities within the business and how they relate to and interact with the resources in the business to achieve a goal for the process.
A business model can never be totally accurate or complete, simply because no two observers of a business will have an identical perception of the business or agree on an accurate model. As noted earlier, the business model cannot and should not contain all the details of the business. A model that attempts to do so risks becoming just as complex and as hard to comprehend as the business. Not every detail can be captured due to restrictions in the modeling language or the concepts used to build the model. Thus, the model should focus on the core business tasks and its key mechanisms. Pinpointing the core business tasks and determining what to depict in the model is the responsibility of the modeler.
Likewise, a business model of a future view of the business cannot be expected to ever be completely realized as planned. Changes in the real world can affect the basis on which the model was created, rendering the model as no longer completely valid. In addition, during implementation, the model may meet with active or passive resistance by either the business management or the employees.
Even with these limitations, however, the following arguments for producing business models are still very strong:
To better understand the key mechanisms of an existing business. By providing a clear picture of their roles and tasks in the overall organization, the models can be used
to train people. (They may be used in both a hierarchical or a process-oriented organization.)
To act as the basis for creating suitable information systems that support the business. Descriptions of the business are used to identify necessary information systems support. The models are also used as a basis for specifying the key requirements of those systems. Ideally, large sections of the business model can be mapped directly onto software objects. As more infrastructure software systems are added, potentially the systems being developed may become more business-driven, and the developers can concentrate more on functionality that supports the business rather than on solving technical incompatibilities or problems.
To act as the basis for improving the current business structure and operation.
The models identify changes in the current business that are necessary to implement the improved business model.
To show the structure of an innovated business. The model becomes the basis for the action plan. Innovation suggests that radical change, rather than incremental changes, have been made to the business processes.
To experiment with a new business concept or to copy or study a concept used by a competitive company (e.g., benchmarking on the model level). The developed model becomes a sketch of a possible development for the business. The model can be a new idea, inspired by modeling other businesses, or can take advantage of new technologies, such as the Internet.
To identify outsourcing opportunities. Elements of the business not considered the part of the core are delegated to outside suppliers. The models are used as the specification for the suppliers.
Lets take a detailed look at each of these motives for business modeling and see how they differ.
Understanding the Business
One of the primary motives for developing any model is to increase the understanding of the business and facilitate communication about the business. A visual model is easier to comprehend and discuss than a textual description or no description at all (which is often the case). The model is a current snapshot of how modelers currently view the business. The model will change and evolve either as modelers better understand the business or as the business changes. Once the models are fairly stable, because they give a clear picture of the roles and tasks in the overall organization, they can be used to train people.
Information System Support
Today, most businesses use some type of information system. In fact, it may be said that information technology is an integral part of the daily operation of many, if not most, companies. This trend continues to gain momentum with the recognition that the effective use of computer systems will enhance almost any business. In some domains, computer systems are obligatory to handle the massive amounts of information and to respond to the need for fast and reliable communication with other companies and customers. With the Internet as a technical infrastructure for communication and financial transactions, a wealth of new business opportunities is emerging. Existing business models need to be adapted with the new possibilities that the Internet provides.
As widespread as this trend is, however, many companies are dissatisfied with the quality of their information systems, citing they offer insufficient or ineffective business support, they are awkward to use, are not reliable, and are not integrated with other systems. In many cases, this is due to the fact that the systems havent been developed with a correct understanding of the business it supports. Developing the actual software for computer systems is still a job for qualified computer experts who are familiar with all the intricate details of programming languages, operating systems, and databases. Because of this, software systems development is often technology-driven, rather than business-driven.
The common approach to solving this problem is to have representatives of the business write a requirement specification for the systems that are to be developed. Frequently, though, this requirement specification is often inadequate and incomplete because it is usually written specifically with the information system in mind, but concentrates on describing the appearance of the user interface rather than on the relationships and interactions between the objects used in the business.
Often, the authors of the specifications are also technicians who make design decisions. Without a full understanding of the business and its needs, they prematurely make important decisions about how the information should be constructed. Sometimes these choices are in direct conflict with the functions and characteristics the business really requires from the system.
The solution is to create a model of the overall business that can be used to decide which information systems are required, how those information systems should be developed, and what functionality the systems should contain (see Figure 1.2). If the requirement specification is based on a good business model, there is a much greater chance that the information system will support the business adequately. There are several advantages to basing all the information systems on the same basic business model:
The information systems become an integrated part of the overall business, supporting the business and enhancing the work and the results.
The systems integrate easily with each other and can share or exchange information.
The systems are easier to update and modify as dictated by changes in the business model, which result from changes in the surrounding environment, goals of the business, or improvements or innovations to the business model. This in turn reduces the cost of maintaining the information systems and of continuously updating the business processes.
Business logic can be reused in several systems.
Figure 1.2: A business model can be used as the basis for defining the requirements on information systems.
Ideally, the objects presented in the business models translate or map to objects in the information system. Normally, this is not a one-to-one mapping. One object or process in the business model cannot always be translated into one object in the information system, since there are objects in the information system that are not present at all in the business model, and vice versa. This makes a direct mapping between the real world as described by the business model and the software system impossible. Nevertheless, even if a one-to-one mapping between the business model and the analysis model of the information system is not possible, the way the business operates and the functionality and design of the information system used to support it are more tightly integrated. Why? Because an information system that is built to support the requirements of a process will offer the appropriate services. Using object-oriented techniques, the modeling concepts and the structures used in the business model can be the same as those used in the
2 3 4 ... 28
© 2003 GARUN.RU.
Копирование материалов запрещено.