Freek van den Berg/2008-9/RenD3/Scriptie

Freek van den Berg s0517593 Bachelor Thesis February 7th, 2009

Managing a system formally using a formalization of the kitchen metaphor taxonomy

Contents

Abstract Foreword Introduction Current literature Ashby Resource based versus product based Hanno's model Business rules System dynamics Kitchen metaphor Problem statement Creating model Iterative creation Missing concepts (stocks, backlog of orders) Constraints Design decision and alternatives Composition and decomposition //Conversion to relational model Mathematical explanation Conceptual meanings of the kitchen metaphor terms Applying model Current literature Defining business rules Assumptions before applying the model (domain expert is there to name concepts...) Identification issues Proofing your company matching certain strategies Certain percentage of orders can be fullfilled Order fluctuations can be dealt with Orders can be fullfilled in certain time Average time Maximum order time Median order time Low stocks (just in time) Resources are optimally used Current resources are sufficient

Linking the model to the real system System dynamics approach (quantitatively) Verifying model System dynamics Future work and improvements Conclusion References Appendix

Foreword

I am Freek van den Berg from The Netherlands. This bachelor thesis has been written for my Bachelor study Information Science at the Radboud University Nijmegen, The Netherlands. I've started my study at 2005 and am currently already following master courses. However, in order to completely finish my bachelor this thesis is the final milestone to achieve. During this thesis Hanno Wupper has guided me and provided me with the required literature.

The

Current literature

In order to figure out how the viability of systems are described, the current literature on this has been examined. Different scientist have proposed different views, models and approaches to describe this and the challenge here is to find a common property amongst all of them. In order to achieve this a short summary of several theories is given, combined with linking the view to the viability of a system. Six different theories have been selected.

First Ashby's system theory, which has been used for years in both science and society. The first main point Ashby makes is that in designing and setting up a viable system, three stages can be distinguished which he refers to as control, design and regulation. The first stage named control is about detecting the essential variables of a system and the norms they should have. If one takes the system human for example, body temperature can be a very important property for survival and the norm would likely be something like between 36 and 40 degrees Celcius. This is just one variable and using Ashby's theory one can define as many variables as wanted. One thing Ashby doesn't define is how to obtain the variables that are essential. The point he makes about this is that domain experts should be able to know what's important and what the corresponding norms are. This could be seen as a difficulty, but on the other hand it leaves things open for other theories to define what concretely needs to be done here, which will be shown later in the paragraph. The second stage in Ashby's model named design, deals with making sure that the essential variables for the system stay within the needed norms. The environment of the system offers treats to the system now and then, which are described by Ashby as disturbances. In the concrete example of the previously mentioned human a very bad flu could make the body temperature go up very much and therefore threaten the viability of the system. Ashby proposes that one should design actions to counter these effects called regulations. A regulation for the human case would be to take a lot of rest, drink a lot of water and take the appropriate medicines. An important thing to note about the design phase is that every single disturbance possible should be detected. Once again Ashby doesn't give an answer about how to achieve this, but also in this case asking a domain expert is a straightforward thing to do. Finally the third phase, regulation. This phase is about making all the just mentioned happen in practice. This includes creating the right infrastructure to detect disturbances and to execute the right regulation actions. What can be seen from Ashby's theory is that finding the right essential variables and norms is the important thing to do.

[ERROR: JUISTE LITERATUUR EN AUTEURS OPZOEKEN VAN VOLGENDE THEORIE] In management one often thinks of viable organizations in terms of how successful they are in making money. Normally this money is made by selling products or offering services to the market or environment. There's two views on this concept, namely the I/O model op superior returns and the Resource based model. The former focuses on doing research on the market first, figuring out what the market needs, then improve capabilities to offer what the market needs and finally offer that what the market needs. On the contrary the latter focuses on the resources first, then see what resources can provide for the market and then offer this to the market. Applying this to Ashby's theory two major essential variables can be defined. One is the demand for products a company produces while the other variable is how quickly the company can satisfy this demand. In other words, the average time between and order being placed and an order being processed successfully. Of course one needs to do both things in an efficient way so that eventually there's a profit left after the products are sold, but that's not the main focus right now. In terms of disturbances two things can go wrong. For some reason the market isn't interested in your product anymore and for some reason you can't offer the products needed quickly enough or perhaps not at all. The first problem can be regulated by making sure you have the right capabilities to offer what the market wants. The mentioned I/O model addresses this after the market has been investigated. This is done by upgrading resources qualitatively (buying new machines, hiring new highly qualified humans, training the current humans etc.), which can be seen as a regulating action. The second problem about offering products in time is done by either using your resources more efficiently (machines should be running as much as possible, humans should do the most intelligent work they can do instead of wasting time on bureaucracy) or by upgrading resources quantitatively (buying more of the same kind machines, hiring more humans with the same qualities already being there. All the just mentioned can be translated to a diagram in the following way: EV \ Disturbance Product demand dropping Order time increasing

Product demand Upgrade resources qualitatively

Order time

Upgrade resources quantitatively, Use resources more efficiently

[ERROR:ASHBY MODEL ERBIJ PAKKEN EN VERTALEN NAAR JUISTE DIAGRAM]

Third the paper 'The construction of Verification Model for embedded systems' of A. Mader, H. Wupper and M. Boon is used. The paper links real systems with abstract formal models. When one makes a model of the real system, one needs to have confidence that the model is expressive enough to describe what's going on in the system and that no matter what the system's behavior will comply with the model. When this is the case, the model could be used for verifying if what one wants to achieve can be achieved in the real system by measuring properties in the real system and use them as input for the model. The framework used for this is expressed in the following square diagram: Blue print, verification model Proof Formal properties Modelling

Formalising Embedded system, artefact Confidence Behaviour, requirements In the framework proposed in this thesis, the model should have both a requirements element as well as an element to model the behavior (read: measurements from the real system). Combining this with the resources and products mentioned in the previous paragraph this results into four categories that need to be managed. First there's the formal entities product and instrument (read: resource) that need to interact with each other and be compatible with each other. In terms of the person having flu and high fever, an example of this case would be that a certain treatment has proven to be effective before (theoretical instrument) to create a healthy person again (theoretical product). This is merely a theoretical fact, normally based on empirical evidence in history. On the other hand there's the true treatment performed by a specific doctor at a certain time and a person being sick at that time in real world. The doctor measures a fever before his treatment and rechecks the body temperature after the treatment again. This is the practical half of the model including a specific doctor (practical instrument) and a specific patient (practical product) engaging in interactions at a certain point in time. Note that the theoretical part of the model doesn't involve time, since what's going on there is considered an objective fact always being true, independent of any time.

[ERROR: WIE HEEFT DE KITCHEN METAPHOR BEDACHT https://lab.cs.ru.nl/algemeen/Taxonomy/2._Methodology/4._Workflow op electronische werkplaats] Finally to make everything just mentioned easily understandable in a metaphorical way, the kitchen metaphor is introduced. The kitchen metaphor describes a production plant in terms of actions that happen in a kitchen. This is useful for two reasons. First of all most if not all people are familiar with what's going on in a kitchen. Second the main purpose of a kitchen is producing a product (namely food) using raw materials (ingredients) which matches a production plant's philosophy very well. [ERROR: HIER KOMEN BEGRIPPEN VAN DE KITCHEN METAPHOR IN NATUURLIJKE TAAL ] Term World Description in natural language product object Reality Substances, information, people, or money that are objects of processing instrument Reality A thing that is used for production production step activity Reality A procedure that takes some products as ingredients (precondition), performs some operation, thereby using some instrments for a certain time, and produces some products (postcondition) batch Reality A quantity of products moving from production step to production step resulting in one end product service Reality The iterative execution of a production step with the same instrument for different batches scenario Reality All production steps that actually happen in a period of time recipe Description The specification of a class of batches that result in a certain product functionality Description The specification of a service order Description A bag of pairs (product, due date)

[ERROR: Hier komt een stukje over business rules en hoe constraints kunnen bijdragen tot het model]

[ERROR: Hier komt een stukje over system dynamics (qualitatieve analyse, simulation]

[ERROR: stukje over Supporting Planned and Ad-Hoc Changes of Business.pdf ACCEPT REQUEST etc..]

Problem statement

[ERROR: verplaatsen voor de literature study] Nowadays there are many different frameworks and theories available on how to manage a system or company. The problem with these theories is that they are often either very abstract or very informal. Another point they normally lacking at is that they don't connect well to the language of the domain experts, normally being people with limited formal knowledge. The framework should thus offer a description of a system or company in terms that are understandable for as many people as possible.

In addition to that, every business and system seems to have their own taxonomy, which makes it hard to communicate outside the boundaries of the business or system. For example, people of different companies talking with each other or different systems communicating to each other through a certain protocol. A taxonomy in which general underlying concepts are shared and defined formally is very wanted here.

The aim of this thesis is to offer a general framework to manage a system with corresponding, common taxonomy. In order to achieve this, different theories have been examined and their key points have been highlighted. From system theory the concept of essential variables is taken, which has been made concrete with knowledge management theory, resulting in both producing something that's useful for the environment as being able to fulfill the wishes of the environment in time being essential variables. A. Mader et al's model makes the distinction between a concrete and abstract system, which will later be used. In order to describe the concepts of a system in a general way that any person can understand, the kitchen metaphor taxonomy has been introduced. All the components of the system will be linked to this system. Business rules can offer guidance in what constraints the system should have to be successful, while system dynamics makes it possible to run simulations with the system in order to find out where the bottlenecks and areas of attention of the system are.

The two problems as mentioned in the first two paragraphs, combined with the theoretical background in the third, lead to an approach in which formalization and usage of the kitchen metaphor terms are the two main factors for managing a system. This leads to the following research question:

How can a system be managed formally using a formalization of the kitchen metaphor taxonomy?

Creating model

This chapter deals with creating a model satisfying the two criteria as mentioned previously, namely the model being formal and the model being expressed in understandable concepts and terms (in this case the kitchen metaphor). A way to do this, is to look at a fictional situation of what could happen in a kitchen. By distinguishing different steps that are taken in the kitchen while a meal is being prepared and linking these steps to the concepts of the kitchen metaphor, one can iteratively built a model that's expressed in the wanted language. For the formalization part one has several choices of which ORM has been chosen here because of its strengths in dealing with concepts and relationships between them. No that the intention here isn't not the describe perfectly how a meal is prepared and therefore details have sometimes been omitted due to conceptual irrelevance. For example, not the full list of ingredients is given, but just a few to give an impression of what concepts play a role.

The fictional situation described here, starts with John who wants to surprise his girlfriend with an own made meal for Valentine's day. The scope of this system is the kitchen of John in which resources are available to produce things, which receives ingredients from the environment (for example doing groceries in the supermarket) and which hands a meal back to the environment again (for example John putting a nicely cooked meal in the living room).

The intention John has by making a meal can be seen as an order, because John wants to contribute something to the environment. However, although the environment doesn't explicitly ask for the order it's still considered external contrary to orders of which the product is reused by the system. This introduces the following concepts: Order (John's Valentine's dinner meal) ExternalOrder (John's Valentine's dinner meal)

Note that the creation of the model doesn't deal with what a Valentine's dinner meal actually is and how it can be measured in the real time world. This step and all future steps in the model creation will just name the concepts as we know them intuitively and in order to make them concrete one needs to link them to the real world somehow. In ORM this is normally done by using labels. Later however, there will follow a conceptual view on the taxonomy being created in natural language. Also synonyms for certain terms will be given, since the system or company view are normally approached differently by people.

Now John needs to decide what meal he's going to make. In order words, he needs to make requirements for what needs to be achieved to make the order successful. In order to make an order successful a product has to be delivered, but since the concrete product isn't produced yet, it only makes sense to talk about the product requirements now. John decides to make a Scottish Kale oven dish. This leads to: ProductRequirements(Scottish Kale oven dish)

The story continues. John has decided that 18:00 would be a nice time to have the meal, and therefore there's a requirement to have the meal done by this time. This is when the definition of an order is being made. An order is a demand/wish for a certain product with ProductRequirements to be delivered by the company or system to a certain person (or in case of an internal order to the system itself) at a certain time. Despite John's meal being requested by himself, an external entity outside the system is supposed to benefit from it, namely John's girlfriend. This introduces the following concepts: Costumer(John's girlfriend) OrderCostumer(John's girlfriend) OrderDuetime(18:00 at Valentine's day 2009)

Note that OrderCustomer is connected to the ExternalOrder, while OrderDuetime is connected to order. This is so because only external orders have a costumer, while a due time can be assigned to all orders, including internal orders which will be introduced later. The population of the fact types connecting the concepts are omitted, because by knowing the population of the different concepts one can see straightforwardly what can be connected using the story of John mentioned here. In addition to this the order needs to be connected to the ProductRequirements, which is done in the following way:

Since John isn't the greatest cook around, he decided to look for a recipe which describes how the meal needs to be prepared. After browsing around on the Internet the following (Dutch) website is found: http://www.receptenweb.nl/SiteNL/servlet/ctl/jsp/RecipeSearch/Recipe.jsp?index=1&word=boerenkool&scope=4&isSMSSearch=false Thinking more carefully one can say a recipe describes a production step. The term production step description is introduced here. It turns out that a recipe (or production step description) contains several parts, namely: An ingredient list A required resources list A description of several steps that need to be taken using the ingredients and resources A final product that's promised

Firstly the ingredient list and the promised output product. Ingredients can be seen as input products for the execution of the recipe to receive a wanted result. The only way the recipe can promise a certain quality of the final product (read: the final product having certain product requirements), is when a precondition stating that the ingredients used have certain product requirements. This means that a recipe (or more general a production step description) is connected twice to ProductRequirements. Once to indicate the input and once to indicate the output. In diagram form this is expressed as follows: Recipe (How to make Scottish Kale oven dish) ProductRequirements(500 grams of Scottish Kale) ProductRequirements(One piece of smoked saucage) ProductRequirements(Scottish Kale oven dish)

The slash indicates that both terms can be used interchangeably. Note that not the whole population of ProductRequirements is given here. Just a sample population to get an impression. The 500 grams of Scottish Kale and the saucage are linked to the input role of the recipe, since they are ingredients, while the Scottish Kale oven dish is linked to the output, being the final result when the recipe is executed.

Secondly the required resources list. This list contains all the resources that are needed to create the meal. Some examples in this case are a pan, a oven dish, some spoons and a oven. But this list doesn't include the most important resource, which isn't mentioned in the recipe, but still implicitly assumed to be there. Namely a person to prepare the meal. Therefore this person will also be part of the population of resources. Since a recipe is only an abstract something and still no concrete actions have been taken, we're talking about the requirements which some concrete resources should have. In a similar way as ProductRequirements, ResourceRequirements is therefore introduced: ResourceRequirements(A human to prepare) ResourceRequirements(oven dish) ResourceRequirements(a pan)

Thirdly and finally the description of the several steps. Every step in the recipe requires a certain input (ProductRequirements and ResourceRequirements) and promises a certain output (ProductRequirements). In addition to this (although not always mentioned in the recipe) an estimated time of this step can be added. This turns out to be vital for planning later. Note that every step of the recipe is a ProductionStepDescription and therefore a new recipe itself. This can be explained by a recipe being a composition of smaller recipes. Above what's been mentioned about a recipe already, therefore only ResourcesRequirements and EstimatedTime need to be added: EstimatedTime(1 hour)

So far John has not done any physical action in preparing the meal. Therefore it's fair to state the everything of the model being generated until now is about the abstract world. Next John doing concrete actions is analyzed. The assumption here is that John intuitively knows what to do to get the meal done at the right time, but after his sequence of actions has been described a reflection is made, describing how the abstract and concrete world could've been compared.

First of all John goes to the store to buy the ingredients he needs. In principle it doesn't matter what John buys as long as the products he buys fulfill the product requirements that are needed for the order. This introduces new products that satisfy the requirements that are mentioned before leading to the following addition: Product ( 500 gr. AH Boerenkool the first one on the shelf ) Product ( 1000 gr Mashed patatoes of brand X ) Product ( 1 piece of Unox saucage )

Note that the concept of the output of the meal has already been added, although John hasn't cooked anything yet. When John has prepared the meal, the above products can be removed from the population and the result of the cooking can be added. Also the link to productRequirements will then change by having the products above removed through the input fact and (hopefully if the cooking is successful) having the newly made product added through the output fact.

Just like product requirements are satisfied by entities in the real world, the resource requirements need to. It's fair enough to consider John a human to prepare. In addition to that two other items that just have been mentioned are being made concrete. This leads to: Resource ( 2 pans that John got for his 43rd birthday ) Resource ( an oven dish John bought at Walmart ) Resource ( 5 spoons John borrowed from his neighbour ) Resource ( John's advanced oven ) Executer ( John himself )

At first glance John himself is a resource as well, but because this definition isn't always considered ethical or because one can think of cases in which a distinction between resources and humans is wanted a new term executer is introduced. The executer becomes a subtype of a resource, making it a special kind of resource.

Now that everything is settled for preparing the meal, John starts doing it at a planned time, in this case 16:45 at Valentine's day to give him 15 minutes of slack with the 18:00 deadline. This results into a production step that is supposed to satisfy the previously mentioned production step description, also labeled execution (note the similarity with executer). The production step is where everything that's planned and thought of in the abstract world comes alive. The resources and products are linked to it and are all occupied for a certain amount of time. The time span is conceptualized here using a beginning and ending time, but other solutions are possible such as a set of the smallest time span possible in the system. In this case it takes John 1 hour (as estimated) to complete the meal. The following conceptualization occurs: ProductionStep( John spending time in the kitchen at valentine's day) Timestamp ( 16:45 at Valentine's day) Timestamp ( 17:45 at Valentine's day)

[ERROR: Planning is set van productionstep description met timespan ] [ERROR: Control vergelijk Planning, Orders en scenario ] [ERROR: Scenario is verzameling Production step met bepaalde eisen ] Every step taken in this paragraph has contributed to the model iteratively. Combining the contributions of every step, while taken into account the overlap in concepts, lead to the final model as below:

Iterative creation Complex Constraints Design decision and alternatives Composition and decomposition [ERROR: hier komt een stukje over de chinese box principle voor compositie/decompositie] Conversion to relational model

Applying model Current literature Concrete example of operationalization

Future work and improvements

Conclusion

References

Appendix