EKD metode (metodoloģija) Enterprise Knowledge Development Methodology

Attīstības vēsture Enterprise Modelling Methodology SISU iekšējā metode Izmantota Eiropas projektā “From Fuzzy to Formal” (F3) Nav Business Rules modeļa Enterprise Knowledge Development Methodology ELEKTRA projekts Integrated in EKP (Enterprise Knowledge Patterns) Approach HyperKnowledge projekts EKD + stratēģiskā plānošana EKD variācijas, piemēram, BMM for ISD http://www.clei.cl/cleiej/papers/v7i2p3.pdf

EKD Framework © A. Persson and J. Stirna

Varētu teikt, ka grafs, kura visas virsotnes tieši vai netieši saistītas 3 meta līmeņos: Meta-meta līmenī (augšējā bilde) Meta līmeni (katra modeļa konceptuālā shēma) Elementu līmenī

Totāli vienkāršots EKD variants ERD uses, refers_to Mērķu modelis motivates, defines, requires is_responsible_for motivates, affects, requires defined_by ERD ERD ERD Business Rules defines, uses, Model is_respon- Concepts Model refers_to sible_for Business Rules Model Actors and Resources Model triggers defines supports performs, DFD is_responsible_for uses, produces Business Process Model motivates, requires ERD refers_to Technical Components and Requirements Model

EKD Modelling session © A. Persson and J. Stirna

Goals Model © A. Persson and J. Stirna Components: goal, used for expressing goals regarding the business or state of business affairs the individual or organisation wishes to achieve. They may be expressed as a measurable set of states, or as general aims, visions or directions. Goals can be of several meanings, such as, goals, needs, requirements, desired states, etc. problem, used for expressing that the environment is, or may become, in some non-desirable state, which hinders the achievement of goals. There may be two sub-types of problems: threat and weakness. constraint, used for expressing business restrictions, rules, laws, policies from outside world affecting components and links within the Enterprise Model. opportunity, used for expressing situations that we may want to take advantage of. If so, the Opportunity should be transformed into a Goal. © A. Persson and J. Stirna

Example of a Goals Model Source: ELECTRUM Library Case © A. Persson and J. Stirna

Issues in developing the Goals Model Where should the organisation be moving? Which are the goals of the organisation? Which opportunities and strengths exist? What is the importance, criticality, and priorities of goals? How are goals related to each other (conflict, support)? Which problems (threats, weaknesses) are hindering achievement of goals? What kind of questions are we discussing when developing an objectives model? Explain that this is typically done in sessions of type “brain-storming”. © A. Persson and J. Stirna

Concepts Model Purpose: to define the "things" and "phenomena" one is talking about in the other models to more strictly define expressions in the Goals Model as well as the content of resources in the Business Processes Model The main purpose of the Information Model is to define application entities and data at the conceptual level. The Information Model must at least include components by which we can describe the contents of the different information sets and flows of the Business Process Model. Consequently, the Information Model includes components such as entities, binary relationships and information attributes. Also the ISA and PartOF relationships are included in the Information Model in order to permit generalisation as well as complex component modelling. The Information Model includes also the possibility to define different "Information Model Component Groups". A group of this type is simply a view of a part of a Information Model, and includes a subset of the Information Model's entities, relationships and attributes. A group can be a member of another group, etc. Groups may overlap each other in terms of their components. © A. Persson and J. Stirna

Concepts Model Components Concepts is something in the domain of interest and application that we want to reason about and to characterise and define using relationships to other entities. Attribute is a concept which is used only to characterise a Concept. It is a property of the type of objects referenced by the characterised Concept. © A. Persson and J. Stirna

Relationships in Concepts Model © A. Persson and J. Stirna Relationships in Concepts Model Binary relationship is a semantic relationship between two Concepts or within a Concept. ISA relationship is a specific kind of semantic relationship between Concepts. If "A" ISA "B", then "B" is the more generic concept, and A is the specific concept. Establishing this kind of relationships is also referred to as generalisation. The opposite or inverse of generalisation, is called specialisation PartOF relationship, or an aggregation, is a special form of semantic relationship, where the interrelated Concepts are "strongly and tightly coupled" to each other. The aggregate object is an assembly of parts, and the parts are components of the aggregate.

Sample of a Concepts Model © A. Persson and J. Stirna This slide show some of the main information concepts of the Library case. Discuss the model. Point out missing things

Issues in developing the Concepts Model What is the “business language” used? What concepts is the enterprise about (including their relationships to goals, activities and processes, and actors)? How are they defined? Their attributes? How are the Concepts related? Which business rules and constraints monitor these concepts?.... What questions are we discussing in developing an information model? An information model basically defines “phenomena” information about which we may later record in the database of the information system. Note also the business rule model is tightly related to the information model by linking concepts and business rules.  © A. Persson and J. Stirna

Business Rules Model Purpose: to define and maintain explicitly formulated business rules, consistent with the Goals Model. Business Rules may be seen as operationalisation or limits of goals Business Rule Model usually clarifies questions, such as: which rules affect the organisation’s goals, are there any policies stated, how is a business rule related a goal, how can goals be supported by rules. © A. Persson and J. Stirna

Business Rule Model Components (1) Nejaukt ar citiem biznesa likumu modeļiem, ko izmanto IS projektēšanā !!!! Business Rule Model Components (1) Derivation rules - expressions defining the derived components of the information structure in terms of entities that are already present in the information base of the modelled enterprise. Derivation rules are introduced as a means of capturing structural domain knowledge that need not be stored and that its value can be derived dynamically using existing or other derived information. A derivation rule is, for instance, "A bad library client is a client that does not return a loan on time for two consecutive times". Event-action rules express the conditions under which the activities must be taken, i.e., a set of triggering conditions and/or a set of preconditions that must be satisfied before their execution. For instance, "If the return of a loan is more than 4 days over-due, send a reminder". © A. Persson and J. Stirna

Business Rule Model Components (2) Constraint rules are concerned with the integrity of the information structure components, or with the enterprise activities and their permitted behaviour. A constraint is, for instance, “the salary of an employee must not decrease”. Static constraints apply to every state of the information base and are time-independent. They represent conditions that must hold at every state. A static constraint, is for example, “location of each copy of book is unique and only one”. Transition constraints define valid state transitions in the information base, thus specifying restrictions on the behaviour of the system. A transition constraint is, for instance, “A copy of book is missing, if the loan that includes it is overdue for more than 4 weeks”. © A. Persson and J. Stirna

Sample of a Business Rule Model © A. Persson and J. Stirna Sample of a Business Rule Model This slide shows that rules can be defined and given more precision. The business rule model is, of course, closely related to the objectives model. Rules can be seen as refinements of goals.

“Tīrs” biznesa likumu modelis A customer is a bad customer id he/she does not follow library rules Rule 1 There should be no priority in waiting line for paying customers Rule 2 A customer is a bad customer is he/she has overdue books twice consecutively Rule 3 A customer is bad delays books for more than 4 weeks Rule 4 Update library catalogue as soon as changes occur Rule 5 Notify all customers about all changes in library services immediately as changes occur Rule 6 catalogue after each loan transaction Rule 5.1 catalogue when new items and/or copies are acquired Rule 5.2 Update library catalogue when copy of item changes its state to "missing", or "in repair", "out of stock" Rule 5.3 Every day check for delayed books Rule 10 Check physical condition of each copy when it is returned to library Rule 9

Issues in developing the Business Rules Model Are there stated rules and policies within the company that may influence this model? By which rules goals of enterprise can be achieved? Does this rule relate to a particular goal? How can this rule be decomposed? How can the enterprise conform to the specification of the rule? How do you validate that a rule is enforced? Which process(es) triggers this rule? Can this rule be defined in an operational way? © A. Persson and J. Stirna

Business Process Model Purpose: used to define enterprise processes, the way they interact and the way they handle information as well as material. In general, the BPM is similar to what is used in traditional Data-Flow Diagram models. © A. Persson and J. Stirna

Business Process Model Components (1) Process is a collection of activities that: consumes input and produces output in terms of information and/or material, is controlled by a set of rules, indicating how to process the inputs and produce the outputs, has a relationship to the Actors and Resources Model, in terms of the performer of, or responsible for a process, and as an instance of a Business Processes Model is expected to consume, when initiated, a finite amount of resources and time. © A. Persson and J. Stirna

Business Process Model Components (2) External process is a collection of activities that are: located outside the scope of the organisational activity area, communicating with processes or activities of the problem domain area and are essential to document. External processes sometimes can be considered as sources or terminators for some information or material flows. A typical example of external process may be customer who requests for certain library service or receives the service. Information or Material set is a set of information or material sent from one Process or External Process to another. © A. Persson and J. Stirna

Sample of a Business Process Model This business process model shows a small fraction of the library case. It also show the actors related to the different processes. Note that some “actors” are of type “non-human” resources. Sample of a Business Process Model © A. Persson and J. Stirna

“Tīrs” biznesa procesu modelis Process 12.1 “Tīrs” biznesa procesu modelis Order Inf.Set 1 Customer order acknowledgment for a book Inf.Set 4 Inf.Set 3 Inf.Set 2 Library accepted Book catalogue order Rejected order Process 12.2 Ext.process1 Search library's Customer all copies Inf.Set 5 Ongoing loans Inf.Set 8 Book is borrowed by another customer Inf.Set 6 Inf.Set 7 Book is Book is not available available Process 12.3 Negotiation with Inf.Set 14 customer Queue performs Inf.Set 12 Inf.Set 13 Inf.Set 5 Process 12.4 Customer refuses Customer elects Ongoing loans Register loan wait in queue to wait in queue transaction Process 12.6 Process 12.7 Inf.Set 31 Deliver books to Process 12.5 customer Update queue State of a copy Library response to customer Inf.Set 9 Inf.Set 15 Book checked Queue Inf.Set 11 out to customer Book is not acceptance available Inf.Set 10 Book

Decomposition of Business Processes Process is not decomposed: Decomposed process: © A. Persson and J. Stirna

Issues in developing the Business Process Model Which business activities and processes are there, or should be there, in order to manage the organisation in agreement with the goals? How should the business processes, tasks, etc. be performed (work-flows, process models)? Which are their information needs? Related concepts? Which are the material flows? How are the processes related to organisational actors? What questions are we discussing in developing the business process model? (modifications might be necessary considering the widened interpretation of the “resource” concept in UMIST’s contributions (as input/output to processes). A good example is missing here) © A. Persson and J. Stirna

Actors and Resources Model Purpose: used to describe how different organisational actors and resources are related to each other, how they are related to components of the Goals Model, Business Processes Model, and Business Rules Model. © A. Persson and J. Stirna

Actors and Resources Model Components Individual denotes a person in the enterprise. Organisational unit can represent every organisational structure in the enterprise such as group, department, division, section, project, team, subsidiary, etc. Non-human resources can be types of machines, systems of different kinds, equipment, etc. Roles may be played by the Individuals and Organisational units in different contexts. An organisational unit may for instance play the roles of administrator and authoriser in the same context. It may be important to identify requirements depending on the role they have. © A. Persson and J. Stirna

Actors and Resources Model Relationships Responsibility is a relationship between actors, between actors and business processes, business rules, and goals. Responsibilities can be delegated or transferred among actors. Responsibilities can be: organisational operational Dependency is a relation among enterprise actors. An actor depends on another for something that can be either a resource or a business process. Two types of dependency can be identified: authority © A. Persson and J. Stirna

Sample of an Actors and Resources Model The Actors and Resources Model exhibits individual, organisationals as well as “technical” actors. Relationships to business processes are not shown in this figure. © A. Persson and J. Stirna

Issues in developing the Actors and Resources Model What types of actors are there? Which are their relationships, organisational structure? Which goals are actors related to? How? Who is/should be performing processes and tasks? How is the reporting and responsibility structure defined? Which dependencies exist between actors? These are some of the questions discussed when developing an Actors and Resources Model. © A. Persson and J. Stirna

Technical Components and Requirements Model Purpose: to aid in defining requirements for the development of an information system. to focus attention on the technical system that is needed in order to support the goals, processes, and actors of the enterprise. to define the overall structure and properties of the information system to support the business activities, as defined in the BPM. to structure the information system in a number of subsystems, or technical components. © A. Persson and J. Stirna

Technical Components and Requirements Model Information System Goal is used for expressing high level goals regarding the information system and/or subsystems or components. They may be expressed with measurable or non-measurable properties, aims, visions, or directions. Information System Problem is used for expressing undesirable states of the business or of the environment, or problematic facts about current situation with respect to the information system to be developed. © A. Persson and J. Stirna

Technical Components and Requirements Model Information System Requirement expresses a requirement for a particular property of the information system to be designed. Information System Functional Requirements are used to express definite requirements regarding a functional property of the information system or some of its subsystems. Functional requirements must be clearly defined with reference to the Concepts Model. Functional requirements can be directly supported by information system goals, but they are more often seen as refinements of the stated information system requirements. Information System Non-Functional Requirements are used for expressing any kind of requirements, constraints, or restrictions, other then functional, regarding the information system to be built or the process of building it. © A. Persson and J. Stirna

Sample of a Technical Components and Requirements model If application of EKD extends to development of requirements for an information system to support the business, this is what the technical components and information system requirements asks you to develop: technical components and their requirements. © A. Persson and J. Stirna

“Tīrs” tehnisko komonenšu un prasību modelis IS Goal 1 To maintain all kinds of information within supports the library IS FReq 5 Library IS should use IS Goal 5 To maintain as much existing information about the software as possible most popular and newly published books IS Goal 2 IS Goal 3 IS Goal 4 To maintain To maintain To maintain information about information about information about customer loans and requests and book resources transactions customer waiting list supports IS FReq 4 IS Req 1 IS FReq 4 Catalogue search supports To provide a 24 supports Library catalogue engine should be should be hours a day library connected to other exportable on CD catalogue search library search systems ROM supports supports IS FReq 2 IS FReq 3 Catalogue search Catalogue search engine should be engine should connected to have a WWW Internet interface

Sample of a TCRM © A. Persson and J. Stirna If application of EKD extends to development of requirements for an information system to support the business, this is what the technical components and information system requirements asks you to develop: technical components and their requirements. © A. Persson and J. Stirna

Issues in developing initial IS requirements Which general goals hold for the information system? Which IS development problems can be conceived? What requirements on the information system to be developed are generated by the business processes? Definition of functional requirements Definition of non-functional (quality) requirements Which potential has emerging information and communication technology for process improvement? ... Typical issues/questions in developing the information system requirements. © A. Persson and J. Stirna

Inter-Model Links © A. Persson and J. Stirna

Inter-Model Links are used in order to relate components of different sub-models are important to understand how the enterprise functions as whole helps improve the quality of the models drives the modelling process forward © A. Persson and J. Stirna

EKD inter-model relationships © A. Persson and J. Stirna Links between the Goals Model and the Information Model are normally used to explain a component of the Goals Model by pointing, from an Goals Model component, to one or more entities of the Information Model referred to in the description of the Goals Model component. For instance, the goal "Improve customer satisfaction" would refer to the concept "Customer" of the Information Model. Links between the Goals Model and the Business Process Model typically relates goals of the Goals Model to processes of the Business Process Model with a "motivates" relationship. Example: "Improve customer satisfaction" could initially motivate a particular, high-level process in the enterprise, e.g. "Customer Relations Monitoring". Link types between the Goals Model and the Actors and Resources Model can mean several things: it may motivate or require the introduction of particular new actors, e.g. Customer Relations Agents (motivated by the goal to improve relationships with customers), or it may describe which Actors and Resources Model component is responsible to achieve a particular goal or defines it, etc. Links between the Goals Model and the Business Rule Model typically describe how different components of the Goals Model are implemented in terms of business rules of Business Rule Model. For example, objective "To record bad customers" stated in Goals Model requires business rule in Business Rule Model, that states how exactly it should be distinguished, e.g. "Customer is reported as bad customer is he/she delays book for more than 4 weeks". Links between the Business Rule Model and the Business Process Model typically describes, how processes of Business Process Model are triggered by business rules of Business Rule Model. For instance, if there is a rule that states, "Customer is reported as bad customer is he/she delays book for more than 4 weeks", then this rules triggers process, which actually performs recording customer as Bad Customer. Links between the Business Process Model and the Information Model are typically between information sets of the Business Process Model and components of the Information Model. For instance: the information set "Expected flights" would refer to entities including attributes and relationships like Flight, Airline, Pilot, and temporal data about arrivals. Links between the Actors and Resources Model and the Business Rule Model typically describes how different components of the Actors and Resources Model are related to business rules of the Business Process Model. Examples of link names are: defines, is_responsible_for. Links between the Business Process Model and the Actors and Resources Model typically describes how different components of the Actors and Resources Model are related to or involved in processes of the Business Process Model. Examples of link names are: performs, is_responsible_for, and supports. For example, actor Library Clerk performs process Deliver book to customer. Links between the Technical Components and Requirements Model components and the other model components may be more complex than the normally binary relationships. Most typically, Business Process Model components motivate information system goals and information system requirements. We may have simple binary statements, such as, "The Library Cataloguing System must be able to handle X requests simultaneously", but we may also have more complex statements, such as, "The response time for user of type X, when performing process P, on data defined as C, must be less than Z seconds". EKD inter-model relationships

Vairāk par EKD http://www.dsv.su.se/~js/ekd_user_guide.html vai ftp://ftp.dsv.su.se/users/js/ekd_user_guide_2001.pdf

3.praktiskais darbs 4.praktiskais darbs Izveidot EKD savai sistēmai Katram apakšmodelim vismaz 7 elementi, neskaitot saites 4.praktiskais darbs Izveidot EKD citai sistēmai Darbs grupās nākamnedēļ lekcijas un praktisko darbu laikā Katra grupa ņem līdzi visu modelēšanai nepieciešamo aprīkojumu Visi vienas grupas dalībnieki saņem vienādu punktu skaitu Grupas dalībnieku skaits nav lielāks par 7 un nav mazāks par 3