Main Concepts of Process Modeling

Main Concepts of Process Modeling
Chapter 2 Main Concepts of Process Modeling Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Additional Recommended Literature
A good overview over MILOS can be found in B. Dellen, F. Maurer: Change impact analysis support for software development processes, International Journal of Applied Software Technology, ISSN , Vol 4, No 2/3, International Academic Publishing, Scarborough, Ontario, Canada, 1998. H.D. Rombach: Practical Benefits of Goal Oriented Measurements. Software Reliebility and Metrics. Elsevier Applied Sycience,1991 Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Prof.Dr.Michael M. Richter
PART 1 General Principles Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Motivation The main tasks for a software project are the creation of a project plan in order to deliver certain software products. This can be supported in various ways: coordination of different activities within a project following a defined development process coordinating planning and enactment (execution) providing access to multiple information related to the current project context. This information can be distributed, heterogeneous, unstable and hard to find. The support is provided by Process-centered Software Engineering Environments (PSEE). Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Socio-Technical Processes (1)
Software development processes are processes where the participating members („agents“) can be humans as well as machines. This requires a careful organization of the division of labor: What do humans? What do machines? A particular problem is the communication between humans and machines: Humans have difficulties to understand the results of machines Machines have difficulties to understand the results of humans Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Socio-Technical Processes (2)
Conflicting demands: Machines need precise instructions Humans want to use creativity. Plans and Executions: They alternate, before all requirements are present and before planning is finished execution of some actions start. Requirements may change over time Requirements are often imprecise and incomplete Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Human versus Machine Who is better, human or machine? This is the wrong question. Better: Who is better, human with machine or human without machine? The relation is not symmetric: The human has the responsibility and makes the decisions The machine is a servant and does what it is told (it is an assistant system). In extreme cases there are only humans or only machines. In relality, there will be a mix. This mix is not fixed. If a task is fully understood it can switch from a human to a machine agent. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Socio-Technical Processes are Concurrent
Concurrent, parallel: Collecting Information Planning Execution All three arrows represent again complex concurrent activities. Concurrency creates communication problems! Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Consequences Because of Incomplete information and knowledge Creativity of human agents Partially unknown behavior of machines: Planning on the level of details is often impossible Therefore: Planning is essentially organization Questions: How should that be done? What has to organized? Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Formal versus Informal Communication
Traditionally, computer scientist prefer a formal communication: They exchange formal documents. This may not always be the best choice because the two partners in the discussion can have different contexts and formal statements may have a different meaning in these contexts. Also, formal statements are often too detailed. As a consequence one can use informal expressions which the partner interprets using his/her own intelligence. Therefore a support system should allow informal entries. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Semi-Formal Documents
Semi-formal documents combine formal and informal parts. Formal parts can be programs, strict advises (e.g. deadlines) or structures for documentation (e.g. a graph structure). They can be interpreted by machines. Informal parts can be texts, annotations etc. They can only be interpreted by humans. In process modeling semi-formal documents occur frequently. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Execution (1) Planning takes place in a model. There is also an external world. In this world actions are executed; executions can never be retracted, they are done. In contrast to planning, an execution can fail. costs apply (“in reality”) additional information may be available. The external world is partially mapped into a model world but it exists independent of the model. It can be influenced by the user but not completely controlled. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Execution (2) Planning steps can withdrawn on the cost of planning steps, execution steps can never be withdrawn. There may be only other steps that reverse some activity and this is sometimes impossible: If you inform someone the information cannot be withdrawn If you delete something etc. In any case, some costs will apply. Execution needs extra agents with special skills and special knowledge is necessary. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Realizing Flexibility: The Overall View
Techniques & methods for integrated planning and execution Detailed Planning during execution Plan correction during execution Techniques & methods for dependency derivation and administration Controlling dependencies and the flow of activities and artifacts (products) Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

PART 2 Details Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

MILOS The terminology is taken mainly from the MILOS-System (which is a specific PSEE) but is essentially also in most other systems: The difference to other support systems is mainly notationally (e.g. Protege´). The successor of MILOS in Calgary is MASE. MILOS: Minimally Invasive Long Term Organizational Support is a support system for socio-technical processes which realizes most of the concepts and method presented in this chapter. It supports knowledge management activities. The main additions are scheduling and release planning experience support explanation aspects Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Process Modeling Languages
Systems that support planning and coordination of software development have to represent the entities used in project plans. They allow representing knowledge about software development processes. We need to define · Process, product and resource models · Project plans · Product deliverables developed within projects · Background knowledge such as guidelines, business rules, studies etc. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Overview: Basic Concepts (1)
Description process Description of a set of activities that have to be executed in order to reach a given goal containing e.g. input and output documents etc. method A method describes how a process goal can be achieved. complex method Problem solving method that refines a process into one or more subprocesses. atomic method Leaf within the process/method hierarchy. It produces or modifies a product. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Attribute of a process. process attribute A product is an information unit for example a document or a piece of code. product The description of type and structure of a class of products. product type parameter Describes a product within a process. It consists of product name and type (e.g. ClassDiagram or URL) Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

product attribute Attribute of a product. Product references stand for the type of products that are used and/or produced by a process or a method. We distinguish between products that are consumed for planning, consumed for execution, produced, and modified. product reference This parameter type stands for a product of a given type that is produced by an atomic method of a process. produce product resource Resources are used for the execution of the project. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

resource attribute Attribute of a resource. A human or machine that carries out activities within a process. agent precondition A condition that has to be valid to carry out a process. postcondition A condition that has to be valid after a process has been executed. process models Process models are generic, reusable descriptions of how to execute projects project plan A project specific model Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Plan-Processes and Methods (1)
In a project plan there are alternating Processes Methods Each process is realized by some method. The method can be atomic or complex. Often one has the choice between different methods and has to select one. Below some complex method one or more subprocesses can be created. Atomic methods cannot be refined furthermore. This gives a hierarchical organization. To each process one or more agents can be assigned. The agents are taken from an agent pool („Resources“) that has to be filled before. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Plan-Processes and Methods (2)
Methods are either complex or atomic. Complex methods refine a process into one or more subprocesses whereas the application of an atomic method results in the production of products that are the outputs of the process. Inputs of a process may either be products that are produced by other processes during project enactment or predefined background knowledge (e.g. manuals or guidelines) taken from generic process models. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Project Plan Requirements Design Process System Design Implementation Code OO Java Create class diagramm Class diagram Define operations Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example in the representation language of Milos: We see a top-down plan of a task. Each plan is realized by a method. Each complex method is subdivided into different subplans. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Partial Tree View of the Same Project Plan Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Process Description (1)
Formal definitions: Process: <process name> Goal: <process goal description> Instructions: <process instructions> Input Products: {<product name>’:’<product type>}* Output Products: {<product name>’:’<product type>}* Modify Products: {<product name>’:’<product type>}* Context Products: {<product name>’:’<product type>}* Entry/Exit Conditions: {boolean expression} Methods: {<method name>}* Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

. Process Description (2) Process name: It is a process identifier, unique within the scope of a method. Process goal: Textual description of the intended results of a process execution. Process instructions: Textual description of special tasks and guidelines how to perform the process. Product name: It is a product identifier, unique within the scope of a method. Product type: Each product has an uniquely associated product type. For example, a TestReport can be of type TextProduct. Each possible product type is discussed in more detail in the Product Model description Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Context products: products that are already accessible at modeling time. For example guidelines, handbooks, etc. Entry/Exit conditions: determine the control flow between processes. Entry condition should be fulfilled to start the process execution. Exit Input/Output/Modify products: products that can be consumed, created or changed by a process. It is a parameter declaration. condition state the condition that should hold after the process has been finished. To control the process flow Entry/Exit conditions can reference the state of processes and products. Product state: A product attribute that indicates the development grade of a product. For this work we considered four possible states: no-existent, to- Review, toChange, complete. The state transition diagram depicts detailed relationships between these product states. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Table of Method Description
Method: <method name> Goal: <method goal> Instructions: <method instructions> Additional Input/Modify/Output Products: {<product name>’:’<product type>}* Refined Input/Modify/Output Products: {<product name>’:’<product sub-type>}* Additional Entry/Exit Conditions: {boolean expression} Parameter Mappings: {<process name>’.’<product name> ’-->’<process name>’.’<product name>}* Sub-Processes: {<process name>}* Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Process Models A project plan describes an individual process. A process model describes a set of processes, it allows to define specific processes. Therefore: A process model may contain plan processes that have more then one method, e.g. one may use Java or C++ for an implementation one may use the GUI A or the GUI B. These methods are seen as alternatives and can be seen as experiences. Therefore they are stored as experiences. For a specific plan one method is selected. In experience bases it is important to mention under which conditions some alternative is useful. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Process Models and Methods
Within process models activities and their interrelationship are described. A more general description of processes in process models defines a the process goal, a set of conditions, process attributes, the products needed to plan and to execute the process, a set of alternative methods to reach the process goal, the products to be produced and resource allocations. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Process Model for Software Development (1)
Processes, Inputs, Outputs requirements system design design process system design implementation code Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Alternative Processes Implementation Design process Atomic methods Complex methods Use Java Use C++ Use Cobol Object oriented design Procedural design Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Design process Object Oriented design Process refinement Create class diagram Define operations Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Process Model for Medical Applications
Alternative Processes Methods used Evaluation process Atomic methods Complex methods Use X-Ray Use MR Use Ultra Sound Local statistical evaluation National evaluation Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Product Models We need the specification of hierarchical, object-oriented product models. A product type defines the structure of a set of products with the same behavior. A product type is either basic or complex. Basic types are predefined and may be integer, real, string, text, date, or external references such as a www page URLs or word documents. A complex type consists of one or more typed subproducts and attributes. Complex product types can be specialized (IS-A relation). Based on a given product model, products instances (synonyms: products, deliverables) that contain general and specific project knowledge of a company can be defined. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: DICOM-Standard
DICOM (Digital Imaging and Communication in Medicine) is a standard covering medical data format for digital medical data. It is developed by the American College of Radiology and the National Electric Manufacturs Association. The standard deals with the exchange of digital information between medical image equipment. Main application areas: Network image management Structured reporting Network print management Image procedure management Offline storage media management Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Computer-Based Patient Record
A Computer-Based Patient Record (CPR) is an electronic patient health record that documents and provides access to information about the patient´s general health condition, present and past illnesses and diagnosis, the status and treatment data. A DICOM Structured Report is a structured Document which contains documentation of a patient´s examinations, diagnosis and treatment data. It may also contain embedded references to other structured reports, images, waveforms, and audio. It contains context information, such as scheduled procedures, observer, previous reports and images. It encodes only semantic information and not presentation information. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Medical Imaging Application
DICOM Application Entity OSI Upper Layer Boundary DICOM Network Transport Section DICOM Upper Layer Protocol for TCP/IP Association Control Service Element (ACSE) OSI Presentation Kernel OSI Session Kernel OSI Transport OSI Network LLC TCP DICOM Data Link DICOM Physical Conection (50 pins) IP Standard Network Physical Layer (Ethernet, FDDI, ISDN, etc.) Point-to-Point Environment Network Environment Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Parameter Mappings (1) If two processes use the same product this has to be documented. This is done by mappings between the corresponding parameters. We distinguish vertical and horizontal mappings. Example: Parameter 1 Process1 map 1 on 2 Parameter 2 Process 1.1 Process 1.2 Parameter 3 Parameter 4 Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Parameter Mappings (2) Vertical mappings connect two input or two output parameter in a process refinement. A horizontal mapping in a refinement map an output parameter of one process to an input parameter of the other process. The parameter mappings describe the flow of products in a project. An extension of this principle becomes necessary if one wants to describe the product flow between different projects. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Precedence Relations This relation says:
One process B must precede another process B The major reason for such a relation is: an output parameter of one process A is an input parameter of the other process B. This means: The flow of products determines to some degree the order of the enactment of the processes. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Agents (1) The participants in an assistant system are also called agents. Intelligent machine assistants that use software tools are often called softbots. Softbots have knowledge, methods and strategies. Agents may act on demand on their own: Pro-active Actions of agents must be triggered. The behavior of agents may be known to other agents. The behavior of softbots may not be known even to humans (e.g. search machines in the internet). Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Agents (2) „Agent“ is used as a modeling concept to describe active entities that carry out tasks. In order to make this precise the properties of an agent have to be specified precisely. Two sub-concepts of agent are defined: Actor: A human agent working on a project like a project planner or developer. An actor interacts with the system via graphical interfaces. Computer agent: A software entity that can be started on a computer and performs a task, e.g. a delegation or compilation of a program. Both, actors and computer agents have qualifications that determine the tasks they can carry out. Both can use tools. Both are not restricted to a specific location. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Agents (3) Agents occur essentially in two ways: 1) A company has agents, organized in a pool. 2) A task requires agents in order to be performed. This defines a matching problem. Because of restricted available agents this also is an optimization problem. In a project plan this match has to be performed. However, the plan does not say how this is done; for this purpose one needs extra support by scheduling tools. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Resource Models The resource pool component manages roles, agents and agent properties. It allows representing the organizational structure of a company as well as a skill ontology. An agent can have a set of skills. Resource models allow assigning roles and qualifications to project team members. These models describe knowledge needed by project managers to find appropriate people for a task. The project planner can query the resource pool for all agents with specific skills. Agents can be humans or software agents Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Project Planning Project planning is essentially an instantiation of process models. Planning a project comprises: · Selecting appropriate processes (e.g. from some experience base), and inserting them into the plan, · Selecting applicable development methods according to the characteristics of the organizations (e.g. familiarity with specific methods) and the goals of the project. · Instantiating the variables in pre- and post conditions, Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Typical Problems in Project Planning
Are concerned with the specific task Selection of processes Instantiation of general steps Obtaining missing information Decisions about details and execution Availability of resources Sequence and ordering problems Time planning, scheduling Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Project Plan Management
The project plan management component allows customizing a process model, resulting in a project plan. It includes as major elements adding/removing tasks scheduling planned start and end times of processes assigning agents to processes. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Activities in Project Planning
Planning activities Add/Delete of processes Assigning resources, temporal planning Method selection as a „macro“ for several planning steps Change of plans, replanning Replanning triggers automatic update of execution states Notification of involved agents (change management) The project plan management component allows customizing a process model, organizing the activities resulting in a project plan. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Planning as an Activity (1)
Planning has many creative aspects. A radical solution is to reduce the machine support to documentation. If this is well structured it has ist merits. There can also be additional service: Notification if something is missing or was changed Availability of a process model Providing knowledge support by connecting information needs and information sources Supporting the interleaving of planning and execution. MILOS is very close to this kind of support. The real intelligent“ work is done by the human. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Planning as an Activity (2)
The tendency is to add more machine support. Examples: Extending the process models to an experience base that gives proper recommendations. Defining specific tasks formally so that they can be performed by machines like: scheduling resource planning. It is important that this automatic support should still be considered as the work of an assistant. This agent gives only recommendations but can often do better than a human. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Because no specific agents have been defined the project manager has to do all the jobs Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Project Execution (1) In the project execution the products are created. These products are considered as dynamic project data and are stored in attributes. The different activities have to be coordinated These activities include: Access on input products has to be provided Generating and changing of output products Temporal predictions To-Do-lists for participating agents have to be generated Connection of external product editors have to provided Access to information on the project state has to be made Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Project Execution (2) The PSEE guides the execution. For this purpose the project plan has to be interpreted what is done by a workflow engine. The workflow engine provides the execution environment. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Execution Coordination
Peter System-Design Version 1 Implementation Code Version 1 See change management System-Design Version 2 Notify Peter! Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Part 3 Change Management Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Change Management Because events produce new situations the situations change continuously. An important aspect of the required flexibility is to react properly on such changes. Such reactions are actions of some agents. The systematic treatment is called change management. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

ECA-Rules The most important management concept is the
Event-Condition-Action rules Event: Something which happens Condition: Description of special circumstances Action: Any kind of action The rule is of the form IF Event AND Condition THEN Action Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Pro-Active Actions, Triggering
We distinguish two kinds of actions: Actions on demand Pro-active actions: Without explicit demand Pro-active actions should not be done at random: There, where it is necessary but not unnecessarily. Therefore a trigger is needed for starting such actions. The most important form of a trigger is represented by ECA-Rules Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Events Events are executed actions that produce a partially new situation. Therefore the result of an event is one or more knowledge units. The specific aspect of an event is its origin from an action. This action may result from A planned action From an external agent They can be Expected or surprising It may contain Expected or unexpected information Events happen at a certain time Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Reminder: Events in Java (1)
Observer: Basis of the Java Event Model Subject Observer observers F attach(Observer) detach(Observer) notify() update() for all o in observers { o.update() } ConcreteSubject ConcreteObserver subject subjectState observerState observerState = subject.getState() getState() setState() return subjectState update() Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Reminder: Events in Java (2)
The Java Event Model (1) : An object in which „something happens“ can generate an event Example: A button, if pushed, generates an ActionEvent An event is again an object; it contains information about the happened event (e.g. The generator of the event) All interested listener will get the event and can work on it, independent of the object which generated the event Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

The Java Event Model (2) We distinguish the „observer“ (event listeners) and the „observed“ (event generator) Event generator Observer 1 Observer 2 Observer 3 Events are objects (subclasses of java.util.EventObject) Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Conditions The conditions describe how and when the action has to be performed. If the action is a notification then the condition says who has to be notified. This is not necessarily the name of some agent, it is often better to describe the function of the agent: notify the persons responsible for task 4, and not: notify Bill (because at the time when the action is performed this agent may be Joan). It is difficult to formulate the condition exactly. Types of errors someone is notified unnecessarily someone who should be notified is not One has to consider which errors are more costly. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Change Rules A Change Rule references an an Action Class and a Condition The Action Class describes an executable action (e.g. a NotifyAction) This action will be executed under certain conditions (described in Condition), After a certain event has happened (implemented in a Basic Event) Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Change Operators The actual change is described by operators. These operators are defined on information units, e.g. on attributes, formulas etc.) We distinguish (as usual) three types of operators: ADD operators: Adding an information unit. REMOVE operators: Removing an information unit. MODIFY operators: Replaces some information unit by another one. This can be defined as a macro operator in terms of ADD and REMOVE. Operators are defined on a general level and can be instantiated. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Change Rule (1)
„If some agent gets by -address a task then notify the agent“ Action: „notify the agent“ ActionClass: NotifyAction Condition: „Agent has an -address“ Event: „some task is associated“ EventClass: AgentAssigned Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Change Rule (2)
ChangeRuleClass: AgentAssignment ConditionClass: AgentAssignmentTests ActionClass: NotifyAction eval() (4a) true (4b) Agent assigned (2) Data structure: PlanProcess Event: AgentAssigned addAgentAssignedListener() (1) (5) perform() eventOccurred() (3) Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example (1): Support of Planning
Rules (on an abstract level) IF <Process-1> is delayed (EVENT) AND <Process-1> is predecessor of <Process-2> (CONDITION) AND<Planner> is responsible for <Processs-2> (CONDITION)  THEN notify <Planner> ! (ACTION) Concrete situation (instances of conditions): System design is predecessor of implementation Karin is responsible for implementation Event (Instance) : System design is delayed Action: notify Karin! Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example (2): Notification Rule
Event: output type for system_design changed Cond.: component_design needs input of type OMT-Doc & planning task for component_design is assigned to agent x Action: notify agent x system_design OMT-Doc OMT-Doc component_design UML-Doc Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: A Change Rule in MILOS
Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

The Key Structure: Dependencies
Actions are not isolated but have various dependencies of a complex character. Many dependencies are „silent“ and activated by certain events. In actual situations dependencies have to be identified and put into actions. Management requires a thorough understanding of these relations in order to perform optimal activities. to structure the dependencies. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Dependency Management
Changes require notification and updates. What is involved? Sources of changes Process models: Flow of data, decomposition Domain knowledge: Product models, types of tasks User knowledge Management of change rules: Definition of change rules: Heuristics Mappings: Dependencies to change rules Propagation of change effects Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Representation of Dynamic Dependencies
Changes lead dynamically to activities All dynamic activities are governed by ECA rules: ECA rule: events: changes to the project plan/state conditions actions: e.g. notifications Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Domain specific dependencies
Types of Dependencies In principle there are two types of dependencies: · Those derived from a process. · Those specific for the application domain. User MILOS System Domain specific dependencies System interface: ECA-Rules User interface: Modeling language enacts Looks at # Modeling view: Operational view: view: Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Product Dependencies Induced by Processes
Java Test Driver Product Dependency Design Document (UML) implement in Java Product Dependency Java Implemen- tation Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Events in MILOS (1) In MILOS events are used in order to send change notifications between different system components. E.g., the project plan triggers an event if the planner has added a new process to the plan. For this event the WFE inscribes as listener. This means, the WFE will be notified if a new process is added to the plan. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Events in MILOS (2) Events can also be used for notification of users. Example: An agent obtains a new process to work on. The WFE triggers an event which is transferred to the system. übergeben wird. This generates a mail to the involved user. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Events in MILOS (3) There are 2 kinds of events in MILOS: Complex Events combine several events under a common „headline“. Example: MILOSProcessDefinitionChangedEvent Basic Events represent exactly one exactly specified event. Example: MethodAddedEvent Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Basic Events A single, special event. Listener has only to implement eventOccurred() Is used if a listener is only interested in a special kind of events. Example: Change Rules Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Part 4 Evaluation and Measurement Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

The Success of a (Support) System
The problem is that users cannot specify exactly what they ultimately want. In a specific situation they are usually able which alternative they prefer. Therefore any kind of a priori evaluation of a support system has some risks, some uncertain elements. What is desiderable is a system that ultimately can a correct prediction of the value of a support system. Because this is not directly available this points into the direction of a learning system. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

How to Evaluate a (Support) System? (1)
The (support) system is a formal object that is applied in reality. The comparison and the evaluation can therefore not be a mathematical task. Comparisons with reality need experiments in real life. Problems: Experiments are expensive Experiments are hard to control and cannot be exactly repeated. The results of experiments are hard to interpret and their conclusions are of doubtful. The influence of specific aspects can hardly be determined Traditional benchmarks are only for automated subprocesses of socio-technical processes adequate! Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

How to Evaluate a (Support) System? (2)
An alternative to experiments are simulations. Advantages: Simulations are cheap They can be controlled precisely and repeated at any time at any place. Disadvantages: Simulations can be far from reality, therefore some real experiments are still necessary. But: Simulations can be used To refute certain models For sensitivity analysis and improvements of the support system Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Why Evaluation? ? SUCCESS!? Costs Benefits OM Ask the users! OM Effort for acquisition, structuring, maintenance of knowledge Software, hardware, ... Reuse of knowledge Explicit documentation of tacit knowledge Dissemination of knowledge This applies in general, not only for support systems Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Terminology: Software Measurement (1)
Measurement is the process by which values are assigned to attributes of entities in the real world in such a way as to describe them accordingly to clearly defined rules. Empirical relational system is an ordered tupel (A, R1,..., Rn,o1 ,..., om ) with A a non-empty set of empirical entities, Ri are ki-ary relations on A and oi are binary operations on A. Formal relational system is an ordered tupel (B, S1,..., Sn,1 ,...,  m ) with AB a non-empty set of formal entities, Si are ki-ary relations on B and oi are binary operations on B. Measure  is a mapping :A B from attributes of empirical entities a  A to formal entities  (a)  B in such a way as to describe them accordingly to clearly defined rules. The triple (A,B, ) is a scale if and only if for all i,j and for all a1,..ak,b,c  A holds: Ri(a1,..ak)  Si((a1),.. (ak)) and (b oj c) = (b)  j (c) (determining the admissible transformations) Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Meaningfulness: if a statement is invariant against all admissible transformations Measurement unit determines how the attribute is measured. Measurement range defines a set of permissible values for a measure. Measurement protocol defines the measurement of a specific attribute in a way that it s repeatable and comparable. Internal attributes: can be measured based on the entity itself External attributes: can be measured only with related entities Direct measurement: does not depend on the measurement of any other attribute Indirect measurement: involves the measurement of other attribute(s) A measure is valid, if it satisfeis the Representation Condition: captures in the formal world the behavior we erceive in the empirical world. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Descriptive model Function m = f(x1,..,xn) where m is a measure based on a model integrating n other measures x1,..,xn Evaluation model Function d = f(x1,..,xn) where d {d1,..,dm} set of all possible alernatives and f is a decision function with the decision criteria x1,..,xn as inputs. Prediction model 1) Function e = f(x1,..,xn) where e is the estimate of the variable to be predicted and x1,..,xn are inputs. 2) Function p(e) = f(x1,..,xn) where p(e) is the probability of the occurence of event e. Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Application scenario : Definition of Measures
Goal: Analyse the SW prozess w.r.t. reliability from the viewpoint of the developer of the company ... Definition M1 M2 % errors M3 ... Measures? Model : #errors M1/#errors total; ... Question: How are the errors distributed over the modules of the SW system? Measure.2: # of per module Measure1: Total # of errors Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Principle of the Goal-Question-Metric Technique: Retrieval System
Business Goal Interpretation Model1 ... Model2 Model3 (Models) Success of Retrieval Utility of retrieved information GQM Goal Impact of document origin on degree of maturity? Definition ... Q1 Q4 Q2 Q3 (Questions) M1 M2 M3 M4 ... (Measures) Per retrieval attempt: for each chosen doc: doc attribute “doc origin” G Q Q M M M M Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Measurement and Evaluation in Software Development
Goal/Question/Metric (GQM) Approach: GQM 1. First study GQM 2. Definition of GQM goals GQM 5. Data collection, validation and storage GQM 3. Development of GQM plan GQM 6. Data analysis and interpretation GQM 7. Post-mortem analysis GQM 4. Development of data collection plan GQM 8. Storage of experiences Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Practical Application of the GQM Technique
Identify evaluation focus: analyze whether system is successful, or not Lessons Learned about OM evaluation 6 - Package Prepare next step Prestudy Plan Execute Evaluate Rework according to decisions made in feedback session Interviews with experts: GQM goal setting Interpret collected data and compare to goals Identify GQM goals Interviews with experts: fill out abstraction sheets Develop GQM plan Feedback session with experts Construct GQM plan 4 - Collect data 3 - Derive measurement plan Derive and implement measurement plan for CBR-PEB Usage trials with experts G Q Q M M M M Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Example: Definition of Goals
SE Glossar requirement document: A document that specifies the requirements for a system... software: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. ... GQM Goal Object Purpose Quality focus View Context SE Thesaurus implementation: programming. requirement document: specification. .... ... maintainability expandability correctability understandability quality factor reliability usability SE Entity Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Discussion The GQM approach is expensive: Reuse of measure plans can be useful: See experience factory. The GQM approach does only implicitly deal with the customers utility: Do really measure what the user wants? For systems like MILOS and others the GQM approach does not make use of The process model The detailed relations between the process steps and in the attached info needs and info sources Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter

Main Concepts of Process Modeling

Similar presentations

Presentation on theme: "Main Concepts of Process Modeling"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Main Concepts of Process Modeling

Similar presentations

Presentation on theme: "Main Concepts of Process Modeling"— Presentation transcript:

Similar presentations

About project

Feedback