business modeling with uml business patterns at work phần 10 pdf

As shown in this example, a business can be described with a vision statement, a goal model, a conceptual model, an organization model, and a process model.. When the processes are detai

GUI and Users

There are no graphical user interfaces (GUIs) directly connected to the PDM system Instead, the systems using the PDM system have GUIs The Internet, Intranet, and Extranet Applications are all Web-based and provide the GUIs for other applications It is important to define style guidelines for the GUIs at an early stage to avoid confusing the different interfaces at the end of the project It is also a good idea to sketch the GUIs or

to prototype them using some of the end users

System Requirement Specification

System requirements specifications detail how the system is developed The content of a requirements specification for an information system such as the PDM system might include:

1 Summary Summarize the requirement specification

2 Problem and background Gives a brief introduction to the perceived

problem, and includes some background information

3 Procurement regulations Public tenders are regulated by procurement

regulations, and there might also be other situations where procurement regulations are involved The procurement regulations should be stated here

4 The business vision and goals A short description of the business goals

and vision

5 The structure of the business, the business processes, and the business rules A short description of the business processes and rules

6 Description of legacy systems A description of legacy systems affected by

the system being specified

7 Use cases Specifies functional and nonfunctional system requirements

8 Prioritization Specifies and motivates prioritization of requirements (if

there are any)

9 Requirements of commercial software and commercial hardware

Specifies demands or requirements of commercial software and hardware used in the solution, if there are any

10 IT strategies Identifies and describes anything in the IT strategies that

affects the development of the systems being specified

11 GUI sketch Illustrates the graphical user interfaces, if there are any

12 Information structure Sometimes includes the information structure in the

requirement specification, especially in PDM systems where the

information structure is rather complex

13 System collaboration, integration, and interfaces Describes the systems

dependent on the system being specified Explains how to integrate the system being specified and how to formalize the interface descriptions and the interface realizations This section also discusses database schemas; many times only one database is used and the database schemas are integrated

14 Migration of old data Itemizes old data that has to be moved into the

system being specified, as in the case with the PDM system in Bob’s Mail Order Database schemas and old data should be documented to ease the migration

15 Financial prerequisites Defines assumptions and conditions such as

budgets, etc

16 Organizational prerequisites Considers important organizational aspects

17 Delivery conditions States the conditions for the delivery of the systems

being specified

17.1 Time of delivery Specifies when to deliver

17.2 Requirements on part deliveries Specifies requirements on part

deliveries For instance, a part delivery that is a computer program that cannot be executed without getting the next part delivery should not be allowed

17.3 Requirements on staff training Requirements of training programs

Typically containing requirements on course material, online learning concepts, etc

17.4 Guarantee Covers delivery promises

18 Terminology (based on the conceptual model) A glossary explaining the

business concepts used in the requirement specification

Note that the content in the preceding sample specification comprises only suggestions; often, it is desirable to separate the technical issues (management, financial, contractual) from the nontechnical issues (e.g., guarantee, delivery) It is may also be preferable to separate factors that are, at some point, becoming stable and immutable (e.g., use cases, nonfunctional requirements) from those that remain volatile, such as financial assumptions, GUI prototypes, or training

From this point, development processes such as the Rational Unified Process (RUP) and the Select Perspective can be used to analyze, design, build, and test the systems specified In fact, much of the content shown in the suggested system requirement specification is included in the Inception phase of RUP and the Feasibility stage of Perspective

Also, remember that it is important to verify and evaluate the supporting systems built using the business model In Bob’s case, it is important to verify and evaluate the new and improved systems to determine whether the goals were reached and the vision was carried out with the new and improved systems, business processes, and organization

Summary

Bob’s Mail Order firm needed to update to compete with other mail order firms that had migrated to the Web and implemented e-commerce systems Bob’s systems were outdated, necessitating the remodeling and improving of the entire business and the support systems The goal was established to increase market share from 15 percent to

55 percent in a 24-month period To accomplish this, Bob realized it would be necessary not only to rebuild or switch the old systems, but also to change the business processes

Many years ago, Bob recognized that a lucrative way to conduct business was to market products before they existed, producing them only if the demand was there The problem was that the sales channels had moved partly to the Internet, and that the products had become increasingly complex The solution was to integrate not just the customer

purchasing process with the Internet, but also the suppliers’ delivery process, via an extranet solution This would cut the lead-times and increase the quality; then, together with marketing and motivating the sales force, Bob’s would be able to achieve its goal

As shown in this example, a business can be described with a vision statement, a goal model, a conceptual model, an organization model, and a process model When the processes are detailed, as was Bob’s delivery process, and connected to the support systems structured in the system topology, the resource model, the assembly line

diagrams, and interaction analyses become useful tools All businesses need support systems, such as Bob’s Product Data Management system, Materials Control system, and Telephone system; those are what the resource model and the assembly line diagram captures

The interaction analysis facilitates the structuring and allocating of responsibility to the processes and resources, and clarifies the connection between them, as expressed in the assembly line diagram The support systems are specified by functional and

nonfunctional requirements The functional requirements are identified via assembly line diagrams; nonfunctional requirements are identified via process properties (lead-times, cost, process owners, process actors, etc.) Use cases are a way of describing functional requirements of support systems The actors using the use cases are also process actors following the processes described The use-case actors can be specified by investigating process actors described with processes The use cases are connected to

the resources in the assembly line diagrams (resources can be information, things, etc.), and should specify how the processes (and their actors) use the assembly line diagrams (via object-to and object-from assembly lines)

Extensions

The Eriksson-Penker Business Extensions are a powerful set of concepts aimed to help you rapidly conduct high-quality business modeling The extensions comprise views, diagrams, models, constraints, tagged values, and stereotypes

Views

The Eriksson-Penker Business Extensions recommend four views for modeling

businesses These views are not diagrams or models; they are four practical and useful perspectives that facilitate the modeling process A given problem should be iterated until it is fully understood and described The four views are:

Business Vision Focuses the overall vision, the key concepts, and the goal structures,

and points to problems that need to be eliminated

Business Process Focuses the business processes that represent the activities and

value created in the business, and illustrates the process interaction and use of

resources in order to achieve the goals and the overall vision

Business Structure Focuses the resource structures, such as organizational units,

products, documents, information, knowledge, and so on

Business Behavior Focuses the individual behaviors and interactions Both resources

and processes have individual behaviors as well as interactions Interaction analysis is

an important tool when allocating responsibility to resources and processes

(theoretically, processes are resources)

Diagrams and Models

Recall that a model is the idea and that the diagrams are the blueprints The Penker Business Extensions suggest a set of models and diagrams suitable for business modeling Most models are expressed with the nine UML standard diagrams, but some

Eriksson-of the suggested models are expressed in one kind Eriksson-of diagram, while other models are expressed in a specialized version of one of the diagrams For example, the Conceptual model, the Resource model, the Information model, and the Organization model are all expressed with class diagrams The Process diagram and the Assembly Line diagram are both specializations of the Activity diagram; they are not just models expressed in the standard diagrams, they are also specialized diagrams (all according to the UML

specification) In contrast, the Vision Statement and the System Topology diagram are two new diagrams that are neither standard nor specialized diagrams According to the UML standard, new kinds of diagrams can be added, but we have tried not to add more new diagrams than necessary; instead, we have used standard diagrams and

specializations of standard diagrams The diagrams and models included in Penker Business are:

Eriksson-Vision Statement diagram States the overall vision This diagram is expressed in plan

Process diagram Shows the business processes and their collaboration It is a

specialization of the Activity diagram

Assembly Line diagram Focuses on the connection between the business processes

and the objects involved This diagram is also the point of connection between the world

of business modeling and the world of software engineering The Assembly Line diagram

is a specialization of the Activity diagram

Use -Case diagram A standard UML diagram that can be used to capture the functional

aspects of supporting systems Note that functionality can also be described in plain text

Resource model Captures the resources of a business, which can be information or

things; the things can be either abstract or concrete Concrete things include people,

machines, and items; abstract things typically are organizational units, departments, and

the like The Resource model is expressed in a class diagram

Organization model Shows the organizational structures of a business The

Organization model is a special case (specialization) of the Resource model The

Organization model is expressed in class diagrams or, in some cases, object diagrams

Information model Shows the information in a structured manner to facilitate decisions

regarding what information should be organized in which system The Information model

is a special case (specialization) to the Resource model The Information model is

normally expressed in a class diagram, but it can also be expressed in an object

Stereotypes and Constraints

The Eriksson-Penker Business Extensions provide a set of business model elements

called stereotypes that allow you to model and capture the essence of a business The

stereotypes are divided into four categories: process, resource and rules, goals, and

miscellaneous The goal category also contains a small set of constraints, necessary to

model the goal hierarchies Table A.1 itemizes the process extensions, A.2 lists the

resources and rules extensions, A.3.1, A3.2, and A3.3 contain the goal extensions, and

A.4 has the miscellaneous extensions

Table A.1: Process Extensions

an explicit goal Activity

(atomic

process)

divided into further processes If these processes are atomic, they are called activities

from-Assembly

from the Assembly Line

to a process

Table A.1: Process Extensions

Noncausal

resource

flow

shows that an object might be produced by one process and consumed by another process

Process

control

controlled by an object Goal

decision

two or more processes Fork and

Join of

processes

Fork and Join

Forks and joins processes

Receive

business

event

Signal Receipt

Shows a receive business ev ent

synchronize and supply processes in terms of objects

Table A.2: Resources and Rules Extensions

is, it is the difference between the conceptions interpreted from a received message and the knowledge before the receiving action [Falkenberg 1996]

Table A.2: Resources and Rules Extensions

or things Things can

be abstract or physical Abstract

resource

an intangible asset, for example, mathematics, concepts, and so on

specifically, human beings

Physical

resource

excluding people For example, machines, documents, and so on

Business

event

occurrence in time or space A business event is one that impacts the business Business

rule

and establish conditions of existence Business rules are used to specify state of affairs, including allowed business object states

Table A.3.1: Goal Extensions

Name Stereotype

To

Symbol Definition/Description

meaning that goals motivate actions leading to state changes in a desired direction

prevents us from meeting goals Cause, measure, and prerequisite are other stereotype notes that are useful when modeling problems A cause leads to problems; a problem can be solved if the cause is removed The cause can be removed

if a certain measure is taken and certain

Table A.3.1: Goal Extensions

Contradictory

goal

contradic tory, but must

Table A.3.3: Goal Extensions

described with a target value in a specific unit

of a measurement (a quantity)

Qualitative

goal

described in a natural language A qualitative goal involves human judgment, in the process of determining whether it has been fulfilled

Instance of

a qualitative

Qualitative goal

Both qualitative and quantitative goals can

Table A.4: Miscellaneous Extensions

Business

package

business models or parts of business models

Tagged Values

UML defines and includes many useful tagged values, but the Eriksson-Penker Business

Extensions offer a set of new tagged values for describing business processes They

are:

Goal A textual value that describes the goal of the process if a goal object is not

explicitly attached to it The goal, which is a part of the goal model, is used to control,

measure, and decide the created value of the process

Purpose A textual value that informally describes the purpose of the process; for

example, anticipated effect The purpose is typically communicated to the process actors

and to customers

Documentation A textual value that informally describes the work of the process; for

example, the activities completed and the resources involved

Process owner A textual value that defines the person in the organization who has the

overall responsibility for the process in question and who manages the changes and

plans for changes

Process actors A textual value that defines the actors needed to run the process

Typically, their skill levels are described

Priority A textual value that describes the priority of this process; for example, whether

it’s a core process, a support process, an administrative process, and so on

Risks A textual value that describes the risk of the process; for example, what can go

wrong either when executing the process in question or when implementing it to the

business

Possibilities A textual value that describes the potential of a given process; for

example, the opportunities for improving or using the process in the future

Time A numerical value that approximates the execution duration of the process

Cost A numerical value that approximates the cost of executing the process

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

guidelines for using actor and role

• Organizatio

n and

• Party Employmen

191

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

concepts, including how they should be separated and how they can be combined

t

and organizes business term definitions, then creates systems for managing them

Business Event-Result

History

Used to track significant business events and then to connect these events

to their results

Capturing the different business events, along with their results—

such as decisions, contracts, statements,

or products, will help you

to make better business decisions

The goal of this pattern

is to enable you to keep

a record of all important business events, which are

• Contract pattern

• Product Data Manageme

nt pattern

• Document pattern

207

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

typically described with attributes such as description, purpose, and result

guidelines for modeling the

important and very common concept of contracts

• Business Event - Result History pattern

• Product Data Manageme

nt pattern

• Representation pattern

Core-215

the essentials in

a problem domain with the purpose

of building well-structured and easily changeable models The core objects

of a business, such as debt, agreement, customer, product, delivery, and order, are objects that rarely change fundamentally;

conversely, the

representations of these objects often change or are

• Contract pattern

219

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

extended A modeler should take this into consideratio

n and separate the core objects from their representations This process is aided by this pattern

are used in all

businesses, and they can cause a lot

of confusion for

modelers

One common problem is when a copy

is made of a document

This raises the question:

Is the copy another document, the same document,

or a “copy document”

linked to the original document?

Also, a document might exist

in several different versions; the basic content and purpose of the document may be the same but the details

• Product Data Manageme

nt pattern

• Geographic

al Location pattern

223

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

are different

When information systems are used to handle documents, other problems can raise additional questions, such as: If I copy my Word file, does it become two documents?

If so, which

is considered the original?

What happens if I switch the names on them; which then is the original and why? This pattern provides a practical way to approach the issues inherent in the modeling

of documents, including different versions and copies of documents

is a contract between a person (employee) and an organization that

indicates factors such

• Organizatio

n and Party pattern

229

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

as assigned responsibiliti

es, contract

of employment, and start and end dates This pattern breaks down then

organizes these underlying concepts with the purpose of describing and representing that

information

to handle both present and future forms of employment

modeling of addresses

or locations using formats that may become obsolete in a short period

of time

• All patterns that require addresses locations to

be modeled

235

create flexible and qualitative organization

al charts in object-oriented models

• Product Data Manageme

nt pattern

• Employmen

• Title Item pattern

• Contract pattern

• Business Event - Result pattern

247

Resource and Rules Patterns

Pattern Name Intent Related

Patterns

Page

and structured

Capturing the structure

of the relationship between documents and products is a difficult but common problem in all

businesses

This pattern

is used for that purpose

the focus shifting that occurs during the modeling process by referring to two frequently used foci (thing focus and

-information focus) in business modeling and how they are related to each other

• All patterns that are used to structure information

or resources

257

modelers to simplify the design process for systems that involve objects that exist in multiple copies or instances It separates the

• PDM pattern

261