--- pl:miw:miw08_bizrulesvocabularies [2008/05/26 16:18]
miw
+++ pl:miw:miw08_bizrulesvocabularies [2019/06/27 15:50]
@@ Linia 1: / Linia 1: @@
-====== BizRulesVocabularies ======
-Tomasz, Bochen, <tomasz_bochen@o2.pl>
-:!:It is a common visual notation used in the Business_Process_Modeling that is a modeling/design problem in the Business_process_management. The BPMN is officially standarized by OMG. Some possible areas of investigation(at 1st sight):
-  * input
-     * relation between BPMN and UML, e.g. see Use of UML and Model Transformations for Workflow Process Definitions
-     * how could we use Business_Process_Execution_Language
-     * the general idea of workflow and tools such as yawl is worth digging in...
-     * SBVR
-  * output
-Extended ARD.
-====== Spotkania ======
-===== 08.03.04 =====
-  * podejścia do budowania słowników (bizrulesvocab) w uml
-===== 080318 =====
-  * przykłady w sbvr, umieszczać w wiki, próba opisu [[hekate:hekate_case_thermostat|thermostatu]] w SBVR
-  * jak SBVR mapuje się na UML?
-===== 080401 =====
-  * j.w. po ang
-  * jak zależności w SBVR maja się do ARD?
-===== 080415 =====
-  * zapis  słownika do thermostato w sbcr
-  * model thermostatu w sbeaver?
-  * wyszukanie narzędzi do SBVR w Internecie
-===== 080520 =====
-  * początek sprawozdania: co to jest sbvr, structured english, skąd dok., narzędzia obecne i przyszle, opis therm w sbvr, przejscie do uml, prpozycja algorytmu __ard<->sbvr__, obserwacje->przyszłe możliwośći rozwoju
-====== Projekt ======
-====== Sprawozdanie ======
-====== Materiały ======
-  * [[http://student.agh.edu.pl/~tbochen/SBVR.pdf|Źródło przykładu i trochę informacji na temat wykorzystania UML przy modelowaniu SBVR (słowników)]]
-  * [[http://portal.acm.org/citation.cfm?id=1342211.1342221&coll=Portal&dl=GUIDE&CFID=59641205&CFTOKEN=86539360|SBVR -> UML]]
-  * [[http://qrdn.brmsblog.com/2007/04/12/the-business-rules-development-cycle-an-introduction/|The Business Rule Development Lifecycle
-]]
-  * [[http://sbeaver.sourceforge.net/support/|SBeaver]]
-  * http://www.dulcian.com/papers/ODTUG/2001/RepresentingStructuralBusinessRules.htm
-  * http://www.omg.org/news/meetings/ThinkTank/past-events/2006/presentations/04-WS1-2_Hall.pdf
-  * http://objectriver.net/Leveraging%20Data%20Models.pdf
-  * http://www.semanticcore.org/Docs/Architecture%20of%20Business%20Modeling%2003-11-01.pdf
-  * http://bizrules.info/page/methodologies.htm
-===== Próba opisu termostatu w SBVR =====
-  * [[hekate:hekate_case_thermostat|thermostat]]
-  * [[miw08_bizrulesvocabularies_sbvr_thermostat|thermostat sbvr]]
-===== Próba opisu termostatu za pomocą UML (Activity Diagram) =====
-  *[[http://student.agh.edu.pl/~tbochen/MIW/p29-raj.pdf|Transformation of SBVR Business Design to UML Models]]
-  *[[http://student.agh.edu.pl/~tbochen/MIW/AD_themrostat.gif|Activity Diagram (thermostat)]]
-===== Model Development Tools (MDT) =====
-  *[[http://www.eclipse.org/modeling/mdt/?project=sbvr|Coming soon...]]
-====== Sprawozdanie ======
-=====1. Getting started with SBVR .. =====
-SBVR is an [[http://omg.org|OMG]] specification that details how business rules and business vocabulary can be captured and specified in unambiguous terms.
-SBVR is targeted at business rules and business vocabularies, including those
-relevant for usage in conjunction with those rules. Other aspects of business
-models also have to be developed, including business process and organization
-structure, which are being addressed by the OMG in RFPs concurrent with that for
-BSBR.
-SBVR is an integral part of the OMG’s [[http://www.omg.org/mda/faq_mda.htm|Model Driven Architecture]] (MDA). Picture below shows positioning of SBVR in Model-Driven Architecture.
-{{:pl:miw:miw08_bizrulesvocabularies:sbvrinmda.png|sbvrinmda}}
-SBVR is targeted at business rules and business vocabularies, including those
-relevant for usage in conjunction with those rules. Other aspects of business
-models also have to be developed, including business process and organization
-structure, which are being addressed by the OMG in RFPs concurrent with that for
-BSBR.
-==== 1.1. What is Semantics? ====
-‘Semantics’ is “the meaning or relationship of meanings of a sign or set of signs”
-[Merriam-Webster Collegiate Dictionary]. In SBVR the signs can be of any form:
-words, phrases, codes, numbers, icons, sounds, etc.
-SVBR includes two specialized vocabularies:
-  * the SBVR "Vocabulary for Describing Business Vocabularies", which deals with all
-kinds of terms and meanings (other than meanings of Business Rules);
-  * the SBVR "Vocabulary for Describing Business Rules", which deals with the
-specification of the meaning of business rules, and builds on the "Vocabulary for
-Describing Business Vocabularies".
-The two have been separated so that the "Vocabulary for Describing Business
-Vocabularies" could be used independently - for example, as a basis for vocabularies
-for business processes or organizational roles.
-The next two sections deal with the semantics of business vocabularies and the
-semantics of business rules.
-==== 1.2. What is a Business Vocabulary? ====
-A business vocabulary contains all the specialized terms and definitions of concepts
-that a given organization or community uses in their talking and writing in the course
-of doing business.
-Examples: process rate, order price, customer retention rate, Gold Level Support, Customer, Order, Order Item etc.
-The vocabulary does not include the special SBVR syntax or other SBVR compliant syntaxes like in Rule Speak.
-Rules are built using Vocabulary and the special SBVR syntax.
-==== 1.3. What is a Business Rule? ====
-The SBVR follows a common-sense definition of 'business rule':
-//Business Rule: rule that is under business jurisdiction//
-'Under business jurisdiction' is taken to mean that the business can enact, revise and
-discontinue business rules as it sees fit. If a rule is not under business jurisdiction in
-that sense, then it is not a business rule. For example, the 'law' of gravity is
-obviously not a business rule. Neither are the 'rules' of mathematics.
-Examining the question more closely, it is obvious that if rules are to serve as guides
-for conduct or action, they must also provide the actual criteria for judging and
-guiding that conduct or action. In other words, for the context of business rules (and
-probably in most other contexts), rules serve as criteria for making decisions. The
-SBVR’s interpretation of 'rule' therefore encompasses the sense of 'criteria' as given
-by authoritative dictionaries.
-=== 1.3.1. Rules and Formal Logic ===
-Experts in this area recommended that the
-best treatment for the SBVR’s interpretation of rules would involve obligation and
-necessity claims.
-Consequently, in SBVR, a Rule is "an element of guidance that introduces an
-obligation or a necessity". The two fundamental categories of Rule are:
-    - **Structural Rule (necessities)**: These are rules about how the business chooses to organize (i.e., 'structure') the things it deals with.
-      Structural Rules supplement definitions. For example (from EU-Rent):
-Necessity: A Customer has at least one of the following:
-    * a Rental Reservation.
-    * an in-progress Rental.
-    * a Rental completed in the past 5 years.
-  - **Operative Rules (obligations)**: These are rules that govern the conduct of
-business activity. In contrast to Structural Rules, Operative Rules are ones
-that can be directly violated by people involved in the affairs of the business.
-For example (from EU-Rent):
-Obligation: A Customer who appears intoxicated or drugged must not
-be given possession of a Rental Car.
-=== 1.3.2. Rules, Fact Types and Concepts expressed by Terms ===
-Informally, a fact type is an association ("Association" is used here in its everyday, business sense - not the narrower,
-technical sense that would apply to a UML class model.) between two or more concepts; for example
-"Rental Car is located at Branch".
-In SBVR, rules are always constructed by applying necessity or obligation to fact
-types. For example, the rule "A Rental must not have more than three Additional
-Drivers" is based on the fact type "Rental has Additional Driver".
-By this means, SBVR realizes a core principle of the Business Rules Approach at the
-business level, which is that "Business rules build on fact types, and fact types build
-on concepts as expressed by terms."
-One important consequence of the SBVR’s approach in this regard is that concepts
-(including fact types) are distinct from rules, which are in a separate Compliance
-Point. This design permits SBVR’s support for concepts (including fact types) to be
-optionally used on its own for building business vocabularies.
-==== 1.4. Notations for Business Vocabulary+Rules ====
-=== 1.4.1. SBVR Structured English ===
-It should be remembered that SBVR Structured English (presented in  {{pl:miw:miw08_mindstormscontrolc:{{:pl:miw:miw08_bizrulesvocabularies:semantics_of_business_vocabulary_and_business_rules_spec.pdf|Appendix C,D}}) is
-just one of possibly many notations that can be used to express the SBVR
-Metamodel, and, as a notation, is nonnormative in the SVBR standard.
-Two styles of SBVR Structured English are documented in this submission:
-  - Prefixed Rule Keyword Style
-  - Embedded (mixfix) Rule Keyword Style
-The Prefix Style introduces rules by prefixing a statement with keywords that convey
-a modality. Examples of some of the prefixes are shown in the table below.
-^ Operative                ^ Structural            ^
-| It is obligatory that    | It is necessary that  |
-| It is prohibited that    | It is impossible that |
-| It is permitted that     | It is possible that   |
-The Embedded Style features the use of rule keywords embedded (usually in front of
-verbs) within rules statements of appropriate kinds. The table below shows a
-sample of embedded keywords used to form rules.
-^ Operative      ^ Structural    ^
-| … must …       | … always …    |
-| … must not …   | … never …     |
-| … may …        | … sometimes … |
-=== 1.4.2. State ===
-'State' is an important notion for business vocabularies and business rules. As far as
-business people are concerned, ‘state’ is a concept they can refer to and use in
-creating definitions, facts and rules. For example, in EU-Rent a car’s states would
-include: 'available', 'allocated to rental', 'on rental', 'damaged' and so on. The
-company uses these state names in defining business rules, e.g., "The car assigned
-to a walk-in rental must be the available car with the lowest odometer reading in the requested car group." One way to express states is using unary predicates, e.g., "car is available".
-==== 1.5.  Business Modeller Editors ====
-=== 1.5.1. SBeaVeR ===
-The [[http://sbeaver.sourceforge.net|SBeaVeR]] is a tool for modeling business vocabularies and business rules. It is an Eclipse based plugin, part of the [[http://www.digital-ecosystem.org/|Digital Business Ecosystem]] project.
-==  1.5.1.1. SBeaVeR feature list ==
-SBeaVeR key features are:
-    * Business knowledge representation: SBeaVeR provides a tool for formalizing the semantics of business knowledge using the Structured English notation.
-    * Portability: SBeaVeR is written in Java for portability and could be installed on many different operating systems without code changes. SBeaVeR
-    * comes with all source code with EPL licence which can be modified or tailored to meet a user's specific needs.
-    * Integration and Extensibility: SBeaVeR is based on Eclipse platform which allows to easily extend or integrate the tool by a user through the use of a well-defined framework.
-    * Model validation: SBeaVeR includes a number of features to support the verification and validation of business models including semantic analysis of rule to determine possible inconsistencies.
-From a functional point of view, SBeaVeR provides:
-    * Presentation and user modification of SBVR Structured English business vocabularies and business rules.
-    * Standard text editing operations (cut, copy, paste, find, replace).
-    * Automatic syntax highlighting following the SBVR Structured English font styles.
-    * Content assist to allow easy and fast creation of contents (automatic completion of known statements/words, automatic text formatting, collapse/expand).
-    * Hierarchical navigation of vocabulary (multiple views).
-    * Dictionary (at present we embed WordNet dictionary) support for synonyms, hypernyms, hyponyms, meronyms, definitions.
-    * Mapping from in-memory Java representation of vocabulary and rules to logical representation.
-    * XMI XML Schema serialization (following SBVR specs) allowing interchangeability of models between software tools.
-== 1.5.1.2. Screenshots ==
-  * Business rules editor
-{{:pl:miw:miw08_bizrulesvocabularies:businessruleseditor.png|BusinessRulesEditor}}
-  * Collapse/expand
-{{:pl:miw:miw08_bizrulesvocabularies:collapse_expand.png|}}
-  * Content assistant
-{{:pl:miw:miw08_bizrulesvocabularies:contentassistant.png|contentassistant}}
-  * Vocabulary editor
-{{:pl:miw:miw08_bizrulesvocabularies:vocabularyeditor.png|vocabularyeditor}}
-  * Wordnet integration
-{{:pl:miw:miw08_bizrulesvocabularies:wordnet_integration.png|wordnet_integration}}
-  * XMI XML schema
-{{:pl:miw:miw08_bizrulesvocabularies:xmi_xml_schema.png|xmi_xml_schema}}
-=== 1.5.2. Part of Model Development Tools (MDT) ===
-[[http://www.eclipse.org/modeling/mdt/?project=sbvr|The Model Development Tools (MDT)]] project focuses on modeling within the Modeling project. Its purpose is twofold:
-     - To provide an implementation of industry standard metamodels.
-     - To provide exemplary tools for developing models based on those metamodels.
-The next release of MDT is tentatively scheduled for the end of June 2008. For the previous release, see New & Noteworthy.
-**SBVR** provides a metamodel implementation and sample tools based on the adopted Semantics of Business Vocabulary and Business Rules (SBVR) OMG specification.
-The objectives of the SBVR component are to provide:
-    * an open source "reference" implementation of the SBVR specification
-    * an EMF-based foundation on which business vocabulary and business rules modeling tools can be built
-    * a basis for integrating and interchanging artifacts between business vocabulary and business rules tools
-    * a forum for engaging the community in validation of the SBVR specification
-In addition to an implementation of the SBVR metamodel, this component will include sample tools that aid in testing and validating the metamodel implementation, and that help SBVR newcomers to better understand its use and potential.
-    * Project Explorer navigator view for business vocabularies and rules
-    * Import business vocabulary from UML domain models
-    * Code generation to Platform-Independent Model (PIM) technologies, such as UML and OCL
-For more details on SBVR, see the Wiki.
-**Downloads coming soon!**
-===== 2. Modelling 'thermostat' in SBVR =====
-This is attempt to map 'thermostat', modelled in ARD, to SBVR.
-This is the ARD model of 'thermostat':
-{{:pl:miw:miw08_bizrulesvocabularies:thermostatard.png|ARDthermostat}}
-All process of building this diagram is [[hekate:hekate_case_thermostat|here]]
-There are phrases of strucural language presented SBVR model of 'thermostat':
-== Vocabulary ==
-  * office - local, where thermostat is installed
-  * business hours (bizhrs) - time, when office is occupied
-  * (nbizhrs) - time, when office isn't occupied
-  * workday - Monday, Tuesday, Wednesday, Thursday, Friday
-  * weekend - Saturday, Sunday
-  * spring - March, April, May
-  * summer - June, July, August
-  * fall - September, October, November
-  * winter - January, February, December
-== Rules ==
-  * It is necessary, that in winter, on business hours, on workday, thermostat keep temperature 25 degrees Celsius in office.
-  * It is necessary, that in winter, beside business hours, on workday, thermostat keep temperature 18 degrees Celsius in office.
-  * It is necessary, that in winter, all weekend, thermostat keep temperature 18 degrees Celsius in office.
-  * It is necessary, that in spring, on business hours, on workday, thermostat keep temperature 20 degrees Celsius in office.
-  * It is necessary, that in spring, beside business hours, on workday, thermostat keep temperature 15 degrees Celsius in office.
-  * It is necessary, that in spring, all weekend, thermostat keep temperature 15 degrees Celsius in office.
-  * It is necessary, that in summer, on business hours thermostat keep temperature 24 degrees Celsius in office.
-  * It is necessary, that in summer, beside business hours thermostat keep temperature 27 degrees Celsius in office.
-  * It is necessary, that in summer, all weekend, thermostat keep temperature 27 degrees Celsius in office.
-  * It is necessary, that in fall, on business hours thermostat keep temperature 20 degrees Celsius in office.
-  * It is necessary, that in fall, beside business hours thermostat keep temperature 16 degrees Celsius in office.
-  * It is necessary, that in fall, all weekend, thermostat keep temperature 16 degrees Celsius in office.
-===== 3. Transformation of SBVR Business Design to UML Models =====
-==== 3.1. Introduction ====
-Here is presented a methodology for transforming business
-designs written in OMG’s standard Semantics of Business
-Vocabulary and Rules (SBVR) framework, into a set
-of UML models. It involves the transformation of business
-vocabulary and rules written in SBVR’s ”Structured English”
-into a set of UML diagrams, which includes Activity
-Diagram(AD), Sequence Diagram(SD), and Class Diagram(
-CD). This transformation works by detecting the distinction
-between rules which will participate in the construction
-of Activity Diagram and rules which do not. These
-rules are imperative in nature. The work in the paper also
-includes the detection of activities embedded implicitly in
-those rules and establishment of sequence between those activities.
-These activities incur some action. We also detect
-their owner and refer to them as the doer of the action. This
-plays a very important role in the development of Class Diagrams.
-==== 3.2. SBVR toUMLActivity Diagram Mapping Rules ====
-This section mainly deals with the mapping of SBVR components
-to UML Activity diagram components.
-=== 3.2.1. Initial Node ===
-This is the start state of the activity diagram. It doesn’t
-play a very important role but significantly shows the starting
-point of a scenario. We have given it a default name
-”start”.
-=== 3.2.2. Activity Node ===
-As we have already discussed in section 3.3, the fact types
-having transitive verbs will be assumed as the activity node.
-=== 3.2.3. Activity Edge ===
-An activity edge is a set of event, guard conditions and
-actions which allows the transition from one activity node
-to another activity node. An event is the trigger of the
-transition. Upon triggering the transition, the condition is
-checked, if the condition holds true, then the corresponding
-action occurs and brings another activity into existence. It
-is not necessary that a transition must have trigger. Transitions
-without the trigger is known as trigger less transitions.
-A typical SBVR operative rule may be written as:
-upon event,
-<code>
-if <propositional expression 2>, then
-<propositional expression 1>
-</code>
-But we are using the following format of operative business
-rules in SBVR
-<code>
-<propositional expression 1> [if <propositional expression 2>]
-</code>
-So, the mapping from these type of SBVR rules to UML
-AD will create the trigger less transitions. The propositional
-expression 2 will help to find out the guard condition and
-propositional expression 1 will help to find out the action.
-  * Guard Condition: Assume an operative business rule like given below. The propositional expression 2 in
-<code>
-it is obligatory that each atm request exactly one password if a user inserts card
-</code>
-if clause refers to the fact type ’user inserts card’. Depending
-upon the fact type, we are creating a boolean
-variable like ’inserts card’. And the guard condition
-will become ’insert card == true’ as shown in Table 1.
-Fact Type Corresponding Boolean Variable Corresponding condition
-user inserts card inserts card inserts card = true
-atm request password request password request password = true
-  * Action: These are the actions which should be invoked during the transition from one activity to another.
-For example in the above rule, if a user inserts a card in the atm, then the atm will do an action
-”request password”. What we are doing is taking the propositional expression 1 and find out the corresponding
-fact type. Merging of verb and last term of the fact type will create the name of the action like
-”request password()”
-=== 3.2.4. ForkNode/JoinNode ===
-  * ForkNode: This is a pseudo-state where one transition
-is coming and multiple parallel transitions are going
-out of it. A SBVR rule like ”’it is obligatory that
-each atm print exactly one receipt and each atm eject
-the card if bank return badAccountmessage”’ represent
-the enforcement of two activities ”’atm print receipt”’
-and ”’atm eject card”’ on the delivery of bad account
-message from the bank. This situation will generate
-the fork state. There will be an incoming transition
-having the guard condition ”’return badAccountmessage
-== true”’ and two outgoing parallel transitions
-pointing toward activities ”’atm print receipt”’ and ”’atm
-eject card”’.
-  * JoinNode: This is another pseudo-state where multiple
-parallel transitions are coming and only one transition
-is outgoing. The generation of this state will be
-same as the above except there will be multiple guard
-conditions and only one outgoing transition.
-=== 3.2.5. ActivityGroup ===
-The ActivityGroup in UML activity diagrams are generally
-known as swimlanes which basically represents who
-is doing the activity. The entity doing an activity will be
-referred as the giver of the activity. As we have already discussed
-that the representation of fact type(activity) can be
-of two type, active form and passive form. In a sentence having
-an active, transitive verb, the giver of the action of the
-verb is the subject of the sentence. In English, the ”giver”
-corresponds to the object filling the role of the first placeholder
-in the fact type form, e.g. ”customer” in ”customer
-places order.” If the fact type form is passive, e.g. ”order
-is placed by customer,” it is the reverse. These means the
-same thing. They are synonymous forms. Facts of either of
-these forms would be logically equivalent.
-=== 3.2.6. Activity Final Node ===
-This is the point in an activity diagram where all the
-activities get end up. We are creating a default end state
-with the default name ”End”.
-====3.3. Mappin ARD 'thermostat' to Activity Diagram ====
-There is attempt to map, moddeled in ARD, 'thermostat' to Activity Diagram
-{{:pl:miw:miw08_bizrulesvocabularies:ad_themrostat.gif|ad_themrostat}}
-More about mapping SBVR model to UML diagrams, You can find in {{:pl:miw:miw08_bizrulesvocabularies:sbvr2umlp29-raj.pdf|"Transformation of SBVR Business Design to UML Models"}}
-=====4. Proposition of transformation ARD model to SBVR =====

pl/miw/miw08_bizrulesvocabularies.txt · ostatnio zmienione: 2019/06/27 15:50 (edycja zewnętrzna)

Pokaż stronę Poprzednie wersje

Menadżer multimediów Do góry

AIwiki

Menu

Dla Studentów

Old specialized AI courses

SMaDA/SMaIDA/AIDA

Informatyka (EAIiIB)

Studia Dr

Inne materialy dydaktyczne

Archiwum

Dyplomanci

Geist Season of Code

HeKatE

Public

Różnice