PRODUCT PLATFORM DESIGN: A GRAPH GRAMMAR APPROACH

Size: px
Start display at page:

Download "PRODUCT PLATFORM DESIGN: A GRAPH GRAMMAR APPROACH"

Transcription

1 Proceedings of DETC 99: 1999 ASME Design Engineering Technical Conferences September 12-16, 1999, Las Vegas, Nevada DETC99/DTM-8762 PRODUCT PLATFORM DESIGN: A GRAPH GRAMMAR APPROACH Zahed Siddique Graduate Research Assistant David W. Rosen Associate Professor George W. Woodruff School of Mechanical Engineering Georgia Institute of Technology Atlanta, GA david.rosen@me.gatech.edu Tel:(404) ABSTRACT The current marketplace can be characterized by the need for variety, faster time to market, and decrease in cost. To survive companies are shifting from a mass production mode to mass customization to provide the necessary variety. One of the key elements of mass customization is the product platform. In this paper we will investigate the use of graph grammars to develop common platforms for a set of similar products and to specify the product portfolio supported by the platform. To facilitate development of common platforms a formal product family architecture representation is presented which separates the core and the options to facilitate the identification of the common platform. Graphs are used to represent the core for function and structure viewpoints, and grammars to specify the relationships among the core and the options. Arguments on suitability of graph grammars in common platform development, are also presented in the paper. 1 INTRODUCTION The need for variety has many companies extending their product portfolios to target different market segments. New models are introduced in the market more frequently and the number of mass-produced models is decreasing (Schile and Goldhar 1989). If the extension of the product portfolio is not well thought, then it leads to component proliferation and introduction of new assembly and manufacturing lines. This need for a strategy has given rise to the new concept of mass customization. One of the basic elements in applying mass customization to a product line is the concept of common product platform. A product platform is defined as: A product platform is a collection of the common elements, especially the underlying core technology, implemented across a range of products, (McGrath 1995). A well defined product platform is required to provide mass customization. Focusing product strategy at the platform level simplifies the product development process because there are fewer platforms than products and major platform decisions are only made every few years. Researchers have indicated the use of different methods to develop product families, but do not give any formal structure to represent product family. This paper is an attempt to introduce formalism to product family representation. Currently, there is no well defined design process for developing family of products, but there are several widely used design processes for designing single products (Ulrich and Eppinger 1995; Pahl and Beitz 1996). Most of these processes suggest investigation of customer need and then transforming the customer needs to product requirements, which are then used to specify function structure for the product. The function structure can then be transformed to structure viewpoint using formal languages. Some of the formal languages that have been used are shape grammars, string grammars, graph grammars etc. Agarwal and Cagan (1997, 1998) demonstrated the use of shape grammars to generate a wide range of coffeemakers. Graph grammar and a formal product family architecture representation are used here to develop common platform for a product family and to specify the varieties supported by the platform. The function structures and product architectures are defined by using graphs that explicitly represent product elements in different viewpoints and relationships among these elements. The idea is to use alternate syntax rules to generate the necessary product varieties from the core at any given viewpoint. Conversions from functional viewpoint to other viewpoints are also achieved according to syntax rules. These rules constitute the grammar, which along with the core defines a discrete product design space where the members of the space represent architectures of the different variety. To add formal structure to product family design we highlight some of the characteristics of the platform commonization problem and 1 Copyright 1999 by ASME

2 introduce the concept of a Product Family Reasoning System (PFRS) being developed to design product families using platform strategy. In this paper we will demonstrate the use of graph grammars in designing family of products. Use of graph grammars to capture the different characteristics of product family design will also be discussed followed by a discussion on the use of graph grammar to specify the product family architecture and to identify common platform for several existing products. The use of graph grammars to provide the necessary product varieties is part of a PFRS to address: (1) How to design common platforms for a family of products? and (2) How to synthesize and reason about the variety that can be supported from the common platform? In the next section we will give a brief overview of some of the product family design concepts and the use of grammars in design. An introduction to the platform commonization problem followed by an brief introduction to our PFRS will be provided in Section 3. In Section 4 we will outline how different product family concepts can be represented using graph grammars. An coffeemaker product family example will be used to demonstrate the use of grammars for product family design and platform commonization in Section 5. We will present our concluding remarks and future directions for this research in the final section. 2 BACKGROUND The main focus of this paper is on product family design using graph grammar approaches. In this section we will give a brief overview on some of the research performed on product family design. Use of grammars in the product design process will also be presented along with some of the basic concepts on graphs and grammars. 2.1 Product Family Design Design for product variety is a relatively new research field, but it has received considerable attention in the management (Baker et al. 1986; Sanderson and Uzumeri 1992) and engineering (Rothwell and Gardiner 1990; Ishii et al. 1995; Ulrich and Eppinger 1995; Simpson et al. 1997) literatures. The basic concept of a family of products or multi-products approach is to obtain the biggest set of products through the most standardized set of base components and production processes (Stadzisz and Henrioud 1995). Characteristics of product family range from flexible modular designs (Chen et al. 1994) to robust and scaleable designs (Rothwell and Gardiner 1990) to standardized, flexible products (Uzumeri and Sanderson 1995). Martin and Ishii (1996) identified commonality, modularity and standardization; Rothwell and Gardiner (1990) emphasized robust design; Simpson et al. (1997) related change in form and function to highlight mutability, modularity and robustness, which they suggest are the core characteristics of product families. Some of the other characteristics that have been stressed in other literatures for designing product families are: commonality (McDermott and Stock 1994; Ishii et al. 1995), modularity (Ulrich and Tung 1991; Pimmler and Eppinger 1994; Newcomb et al. 1996), and standardization (Ulrich and Eppinger 1995). In a earlier study we investigated application of different mass customization concepts to automotive platform commonality (Siddique et al. 1998). Different approaches to providing families of products through the use of common platforms have been proposed. Wheelwright and Clark (1992) suggest designing platform projects that are capable of meeting the needs of a core group of customers but are easily modified into derivatives through addition, substitution and removal of features. McGrath (1995) also stresses the need for a well designed product platform for a family of products. Parts commonality has been viewed as a means of cost reduction (Baker et al. 1986). McDermott and Stock (1994) in their paper describe how the use of common parts can shorten the product development cycle for savings in both time and money in the manufacturing process. Having a common assembly and manufacturing process is another important aspect of developing common product platforms. MacDuffie et al. (1996) looked at how variety affected manufacturing within the automotive industry by studying empirical data. 2.2 Grammatical Approaches and Design A grammar defines the elements and syntax of language, whether the language is English, a computer programming language, a shape language or a mechanical design language. The grammar provides a framework upon which to interpret the language. The interpretations of a language are based upon syntactical information gained from grammatical analysis and lexical information inherent in the individual components (Mullins and Rinderle 1991). Grammars can be used to generate sentence forms (sentence forms could be strings, graphs or various types of shapes) or to parse sentences to check for syntax and inclusion in the language. Based on the form of rewriting rules, called productions, Chomsky (1957) categorized grammars into four types regular, context free, context sensitive and recursively enumerable. In this paper we will focus on context sensitive grammars that have productions in the form uαv uβv, where α is rewritten by β in the context provided by u and v, which can be any sentence fragments (Lewis and Papadimitriou 1981). α and β can be strings of symbols or graph fragments with the limitation α β. We will now present the formal development of graph grammar by defining terms and stating restrictions based on the development in Ehrig (1978). A graph grammar is a grammar rewriting system expressed as a quadruple: GG = ( n, a, R, S) Where: n = alphabet of node labels a = alphabet of arc labels R = set of graph productions S = start graph 2 Copyright 1999 by ASME

3 Seat Leg 1 Leg 2 Leg 2 (a) combining two legs with a seat to make chair Leg 1 Seat Leg 2 Support Leg 1 (c) graph generation Seat Support Leg 2 Leg 1 Leg # A graph is defined as: G = (N, A, M, J) Where N = a set of nodes A = a set of arcs M = (M n, M a ) = a pair of labeling mappings, M n :N n and M a :N a J = (s, t) = a pair of adjacency mappings s:a N gives source nodes for an arc and t:a N gives target nodes for an arc In Figure 1 we have shown an example application of some of the graph grammar concepts. A subgraph H = (N h, A h, M h, J h ) of a given graph G is a subset of the nodes and arcs of G, N h N g and A h A g, along with corresponding restrictions on the mappings s, t, M n and M a. This definition becomes more specific by defining an injective graph morphism. Injective means there are 1-1 maps from nodes, arcs and labeling functions of H to nodes of G. A graph grammar production is defined as p=(b 1, B 2, K, b 1, b 2 ) where B 1 and B 2 are the left and the right hand side graphs, respectively, K is the interface graph, and b 1 and b 2 are injective graph morphisms which map K into B 1 and B 2, respectively. A direct derivation of a child graph H from a parent graph G via a production p is denoted by p:g H. A derivation sequence is a sequence of direct derivations that start from the graph G and end with H denoted as G *H', where * denotes the reflexive, transitive closure of. With some of the basics of graph grammar defined we will now highlight some of the researches involving applications of formal language theory to design. Shape grammars (Stiny 1975) have been used successfully in generating architectural designs (Stiny and Mitchell 1980). More recently Agarwal and Cagan (1997; 1998) have used shape grammars to generate coffeemaker designs. Fitzhorn (1990) developed graph grammars for describing the topology of 3-D models. Variations of graph pattern matching and graph grammars have been extensively used in feature extraction from solid models - Fu and de Pennington (1991) used symmetric string grammars to recognize holes, Rosen et al. (1994) used graph grammars parsing to convert feature based design representations. Schmidt and Cagan (1995; 1996) used hierarchical ordering of Seat Seat Support Leg # (b) grammar production Σ n = {Seat, Leg 1, Leg2} Σ a = {Support} (d) node and arc alphabets Figure 1- Example Application of Graph Grammar Concepts grammar based-design generation processes for optimization and design space characterization. 3 COMMON PLATFORM DEVELOPMENT From a general perspective (in most cases) all products have platforms and a set of similar products have the potential to be produced from a common platform. Development of common product platforms, in general, has a component perspective and an assembly process perspective associated with it. The component perspective specifies the common components present and different relationships among them. The assembly process perspective specifies assembly information, which will be used to specify if all the members of the family can be produced from the same assembly line. One of the objectives of developing common platform is to use the same assembly line to provide the necessary varieties. In this paper we will only concentrate on the component perspective of the platform commonization process. In the rest of this section we will give an overview of our product family reasoning system that is under development. The work presented in this paper reflects some of our developments pertaining to common platform design and providing the necessary variety from the platform. 3.1 PFRS A Design for Product Variety Approach The primary technology development goal for this research is to develop a product family reasoning system founded on discrete mathematics which enables the production of several related products from a common base for different market segments. The focus is on the design of product platforms, within the configuration design stage - configure product and platform structures to meet design requirements, to satisfy constraints on manufacturing capabilities, and to achieve targets on manufacturing cost and lead-time. We call our design method, for enabling product variety, the Product Family Reasoning System (PFRS). Activities that will be involved in PFRS are shown in Figure 2. Two problem types are being investigated: 1. Platform Commonization (PC) Design Problem (i) determination of which components and modules are common and their common spatial and interface relationships; (ii) determination of the common assembly process for the product family; 2. Platform Supported Product Variety (PSPV) Design Problem determination of which product varieties can be supported by the common product platform. At a very high level in PC problem of PFRS a common design space for platform architectures is generated to identify the common platform architecture and assembly process associated with it. During the PSPV phase a feasible product variety space for the common platform, requirements, constraints and assembly process is generated and then product architectures that are in the feasible space can be enumerated. Product structures are primarily discrete, rather than continuous, constructs. That is, a product structure is represented by 3 Copyright 1999 by ASME

4 elements (component, modules) that have relationships with one another (fastening, spatial, exchange of physical quantities, etc.), rather than a set of variables that take real numbers as values. This reasoning system is based on set theory and combinatorics. During PC problem formulation, constraints of the product family are modeled using discrete mathematics to identify the common platform spaces for different viewpoints (components, connections among components, etc.). Different assembly attributes will also be considered to formulate other viewpoints. The reasoning system will consider multiple important viewpoints simultaneously to identify the architecture of the common platform. During later stages of the PC problem the reasoning system will also be able to specify the assembly process associated with the common platform. During the PSPV problem the PFRS will be involved in identifying the product varieties that can be supported by the common platform. Solving this problem involves modeling the flexibility of the platform components and the platform as a whole. The PSPV problem will be helpful in specifying what varieties can be supported from the common platform. As an example imagine a new car is being designed given that its requirements have been identified already, the solution to this PSPV problem can help determine which common platform (if any) will be the most suitable. In this section we presented our vision for PFRS, as stated earlier we have only investigated some parts of PFRS. In Section 5 we will demonstrate the use of graph grammars in different stages of PFRS (PC and PSPV problem) using a coffeemaker product family. 3.2 Product Family Architecture Representation To design a family of products provisions must be made for different configurations of the product to support different functions. The objective of PFRS is to determine the common platform of the product family (PC) and the product family architecture (PSPV) to provide the necessary configurations. Formal product family architectures is defined starting with a definition of a product architecture: PA (Product Architecture) = <C, M, Rc, Rm> where: C = set of components in the product, M = set of modules Rc = set of relationships among components, Rm = set of relationships among modules. The relationships represented by Rc and Rm are relationships in different viewpoints (function, structure, water flow, etc.) as well as others that are found to be relevant to product family architecture design. Each relationship will have a corresponding mathematical relation. PFA (Product Family Architecture) = <Core, Options> where: Core = <C, M, Rc, Rm>, this is the same as a product architecture and represents the common platform; Options = <C o, P, Rc o, Rm o > Platform Commonization Existing Product Architectures Requirements Constraints Relationships Platform Supported Product Variety Limitations of Assembly Tools and other factors Modeling Scheme Modeling Scheme Common Platform Design Spaces Component Viewpoint Assembly Viewpoint Modeling Scheme Feasible Product Variety Space Mathematical Tools Mathematical Tools Family of Products Common Platform Architecture Common Platform Assembly Process Figure 2 - Activities in Product Family Reasoning System where: C o = set of all optional components, P = set of optional components arranged into options = {Pi Pi = {a,b,c,...}, a,b,c C o, i is counter for number of options} Rc o, Rm o are relationships among optional components and modules. That is, P consists of sets of optional components, where one component from each set must be selected for one particular product architecture. The empty component Ø models the case where no physical component is to be included in the architecture. Thus, Rc o, Rm o represent necessary, but not sufficient, relationships; additional relationships will probably be necessary in order describe a feasible architecture. When the entire range of possible combinations of components, modules, and relationships is considered, the size of the architecture design space increases tremendously. One goal of PFRS (not presented in this paper) is to use requirements as constraints that reduce the size of the feasible design space. The challenge is to formulate mathematical expressions of the feasible space that results from applying a specific requirement. In Section 5 we will describe the Product Family Architecture representation procedure for a family of coffeemakers. 4 REPRESENTING PRODUCT FAMILY CONCEPTS USING GRAPH GRAMMARS In this section we will outline how different graph grammar concepts relate to designing product families. We first give arguments on how graph grammars can be used to represent different aspects of product architecture, followed by an outline on how some of the product family characteristics are related to graph grammar concepts. 4.1 Product Architectures and Graph Grammar Designing products involves several steps. One of the preliminary steps is the development of the function structure 4 Copyright 1999 by ASME

5 Pour Mix Pour Mix Product Family Common Structure Carry Store Carry Store Specific Structure 1. Specific Structure n Heat Heat Figure 3 - (a) Basic Structure (b) Flow of for the product. Several researchers have investigated the transformation of functions into structures using grammar productions at different levels of specificity. To represent architecture of a product, components and relationships among these components need to be specified. These components are discrete structures, making graphs well suited to represent product architectures the nodes of the graph can represent components/modules whereas the edges represent relationships among the components. Graphs can be used to represent function structures also, from Figure 3a we see that the functions are the nodes and the function flows are the edges of the graph. Different types of relationships can be represented in the graphs by using colored edges among the same nodes, in Figure 3b we show flow of water among the functions of the coffeemaker. Different relationships can be represented on the same graph using colored or labeled edges to make a more complete representation of the product. In many cases these relationships will be non-directional, but in other cases the relationships may be directional (flow relationship). In the case of directional relationships, directional edges or arrows can be used to specify the flow direction (Figure 3). In the rest of this section we will illustrate how different graph grammar concepts relate to product family development. 4.2 Graph Grammar Concepts Related to Family of Product Development Family of products is defined as a set of products that share common technology and address a related set of market applications. From this definition it is clear that products in a family will perform similar tasks, hence they will have a set of common functions that need to be performed. This set of common functions and relationships among them make the functional core of the product, whereas the optional functions will provide the variety. The common function structure can be represented using a graph, and a graph grammar can be used to specify interactions among the optional functions and the core. As different functions are added to the common function structure, a variety of function structures will emerge, which is shown at the first level of Figure 4. The function structures can be transformed using production rules to generate the architecture of the product. In Figure 5 we show a production rule that converts the carry Product variety 1 for Structure 1 Product variety n for Structure 1 Product variety 1 for Structure n Product variety n for Structure n Figure 4 -Variety Generated from one common function structure water function to tube structure. As alternate production rules are used to transform functions to structures, varieties will emerge. All these varieties constitute the product family at the physical structure level (Figure 4). Architectures of different products in the family can be traced to the common function structure by parsing the product architecture graphs (Figure 4). Parsing of a structure using a grammar can determine if the functions corresponding to the architecture can be traced back to the common function, which will determine the structure s inclusion in the language specifying a product family. The inherent characteristic of context sensitive graph grammars, to allow transformation from one viewpoint to another viewpoint and parsing to determine inclusion in the language, can be very useful in defining product family and identification of common platforms. Commonization Process: The products generated using graph grammars from a common function structure are in a product family, which is a part of the PSPV problem (Section 5.3.1). To solve the PC Design Problem commonality of the products needs to be identified at different levels of detail and different viewpoints to determine the overall common platform for the family. Imagine a scenario where a company is already producing a set of similar products. To economize, the company wants to reduce the number of platforms it uses (PC Design Problem, Section 5.3.2). The architecture of the products are known for different viewpoints and they can be represented using graphs. Using sub-graph isomorphism, sub-graphs that are common in all the platforms can be identified. s that are performed by the structures in the common sub-graph can be considered as common functions, whereas structures not in the Carry 6 Figure 5 - Conversion of to Structure 5 Copyright 1999 by ASME

6 Mix 7 Mixer Figure 6 - Hypergraphs to represent modules common set are options. Using sub-graph isomorphism the common product platform can be identified to solve the component section of the PC Design Problem. With the core and optional functions identified we can now formalize the product family architecture for the product by developing graph grammars that can be used to generate the existing product variety architectures. This formal product family architecture, using graph grammars, will help identify all the products (some of them not on production) that have the potential to be produced from the common platform, which is part of the PSPV problem. Modularity: Modularity is one of the main concepts in developing product families. Many researchers have specified the need to develop products in modules to support product varieties. A module is a set of components that work together to accomplish a higher level function. From a functional viewpoint, two or more functions are combined together into a module. Hypergraphs can be used to combine more than one function into a working module for the system. The combined function can be viewed as a single integrated function that interacts with other nodes of the graph. A hypergraph is defined to be an ordered pair H = (X, E) where X={x 1, x 2,,x n } is a set of vertices and E={e 1, e 2,..,e m } a set of hyperedges such that e i (i=1,2,,m) and m e i Support Mixer i = X; In Figure 6, the shaded line indicates a hypernode, which represents the higher level function Mix. Relationships (edges) are specified at the boundary of the hypernode representing interactions of the module with its neighbors. The relationships among the functions of the module are specified inside the hypernode, which captures the functional coupling in the module. Grammar production rules can be used on the hypergraphs to transform a graph to appropriate structures and relationships with external structures. Using hypergraphs to represent modules is useful in capturing the functional coupling in the module. The hypernodes facilitate the identification of the interactions that are required with other external functions of the product. Standardization: Standardization is the use of standard components/processes in multiple products or across a product line. Graph grammars can be used to map functions into generic structures. When refinements of a structure are made using further production rules, the generic components can be replaced by standard products or unique products according to need. In most cases productions are used to map from one stage of a product representation to a different stage of the product. These transformations usually have one or more alternate productions. The alternate production rules provide the variety, whereas the production rules (for a required function/component/module) without alternatives becomes standard. So standardization is supported at multiple levels of the grammar. A complete standardization will be accomplished when standardization is achieved at all levels. In the next section a coffeemaker product family representation will be developed by incorporating the concepts described in this section. 5 REPRESENTING A PRODUCT FAMILY The primary target in using product platforms to provide the necessary varieties is the identification of the largest set of common components/modules that do not change as different product varieties are introduced. From the product family definition it is clear that products in a family will perform similar tasks, hence they will have a set of common functions that need to be performed. This set of common functions and relationships among them make the functional core of the product, whereas the optional functions will provide the variety. From an engineering perspective tasks that are common in a product family can be realized in the same fashion, where the components and the relationships among the components are similar. If we use the modular product architecture concept, then the set of components and relationships can be combined into a module that performs a specific functions. The main focus of this paper is the development of a product family architecture that can concisely represent all the members of the product family. 5.1 Development of Product Family Representation In this section we briefly describe several steps that can facilitate the development of a product family architecture (Figure 7). Step 1: Determine the common and optional functions for the product family. Aim: The common tasks have the potential to be performed by common modules/components. Common functions that are used across the product family can be used to determine the product platform. The optional tasks provide the variety for the product family. Step 2: Specify the interactions among the core and the optional functions. Aim: To ensure that the core and the optional functions perform the desired tasks, the optional functions need to be inserted at the appropriate place in the function structure. PC Step 1 Step 2 Step 3 Step 4 Step 5 PSPV Figure 7 -Solving PC and PSPV problem 6 Copyright 1999 by ASME

7 Step 3: Transform the function structure to the structure viewpoints maintaining a correspondence between functions and modules. Aim: To determine the components and modules that will perform the functions. al modules are maintained to separate components of the core and optional modules. Step 4: Define the product family architecture. Aim: Determine the product family architecture. Step 5: Combine the core and the optional modules to specify the members of the product family. Aim: Use the product family architecture to generate the individual product architectures of the product family members that can be supported by the product platform. In the next section a coffeemaker product family example will be used to illustrate the application of different graph grammar concepts to formally represent a product family. 5.2 Using Graph Grammars to represent Product Family maker Example To illustrate some of the concepts related to using graph grammars to design family of products, a coffeemaker product family has been chosen. Agarwal and Cagan (1997; 1998) generated a set of coffeemakers using shape grammars. Most of the coffeemakers varieties were generated by changing shape grammar rules. In the coffeemaker example we will use the same function description and available options to describe a coffeemaker product family architecture. As mentioned earlier formal representation of product families do not exist, a formal representation of product family architecture was presented in Section 3.2. This formal representation combined with graph grammars will be used to formally represent product families, which is used to address different issues of the PC and PSPV design problem. Agarwal and Cagan (1997; 1998) introduced shape grammars that describe a language of coffeemakers, which can be used to generate a large class of coffee makers by changing the shapes and features. The functional breakdown of all coffeemakers is essentially the Figure 3.a): 1. water is first poured into and stored within a container 2. the water flows through a heating element, turns to steam 3. the steam rises through a tube, at the top it expands and condenses and flows into the filter 4. the hot water mixes with the coffee grounds within the filter 5. the coffee is then released into a coffee pot below 6. the coffee is kept warm on the pot which is kept warm by a heater Other information can also be represented with the function structure to develop a more complete model. As an example, flow of water (Figure 3.b) for the coffeemaker might be such information. The flow of water might indicate the need to have a tube to carry the steam to be mixed with the coffee, which is above the water heater. Some other constraints also exist that drive the configuration of the product. These constraints are also dependent on the basic functionality of the product, such as the water heater must be below the water storage unit, the filter unit must be above the heater, etc. The three main parts of the coffeemaker are: the filter unit, the water storage and the base unit. Some of the available options for these basic parts highlighted by Agarwal and Cagan (1997, 1998) are: q Number of heaters: In some coffeemakers, the same heater is used to heat the water and to keep the coffee hot. In the case of two heaters, two separate heaters are used to heat the water and to keep the coffee hot. q Flow control in filter: Fixed flow outlet or a variable flow outlet resulting in varying concentrations of coffee. q Flow control for water outlet: With or without mechanism to stop the flow of the coffee when the pot is not in place. 5.3 maker Family Representation The PFRS has two components: PC problem and PSPV problem. In the PC problem the objective is to determine the common platform for several related products. The PC problem has to be solved to develop product families for both new and existing products. The objective of the PSPV problem is to specify the architecture of the individual products that are in the product family supported by the product platform identified in the PC problem. Two possible scenarios can be imagined for developing a product family architecture. In the first scenario a new coffeemaker product family is to be developed and in the second scenario existing coffeemakers are to be commonized. In Section we will describe the steps for developing a new coffeemaker product family. The steps for developing coffeemaker product family for the second scenario will be presented in Section New coffeemaker product family A company wants to develop a new coffeemaker product family to target different sections of the consumer market. The viable coffeemaker options that will be offered to differentiate the products are known, the company wants to know what is the product family and what is the product platform for the family. One obvious option is to keep all the options same and just provide variety by modifying the coffeemaker shape, which will only target a small segment of the market because the functional options are unchanged. In this case the product platform is easy to identify because it is all the components except for the outer shell of the coffeemaker. On the other hand, functional options can be varied to cover a greater portion of the market. When the functional options of the coffeemaker are changed then the shape grammar presented in Agarwal and Cagan (1997, 1998) is not well suited to identify the product family and the common platform (PSPV and PC Design Problem). A set of coffeemakers generated from a similar set of rules and parameters will have very closely related grammar and shape, in other words they will belong to the same coffeemaker family, which will be demonstrated in this example. Step 1: Identify core and optional functions The coffeemaker product family was described in Section 5.2. From the description we can identify the common and the optional 7 Copyright 1999 by ASME

8 Strongness Control Carry Mix + Flow Control Mix + Flow Stopper Separate heating Store Carry Store Heat Control Strongness of Carry Mix Flow Stopper Store Separate + Heating 12 Carry Control Strongness of Store Heat Mix Heat transformations the functions as well as relationships among them are transferred to components and relationships among the components. In the case of coffeemaker structure the rules will specify what the components (terminal symbols) for the optional functions are and then how these components interact with other components of the coffeemaker. Addition of a second heater to the core structure is accomplished using grammar rule 13 and 14 (Figure 10). Rule 13 specifies how to add Heater 2 whereas Rule 14 specifies the structure modification on required to add the optional heater. Similar rules can be specified to add the optional functions Strongness Control and Flow Control. Step 4: Specify the product family architecture to describe the product portfolio. As described in Section 3.3, a product family architecture is composed of the core and the options. For the coffeemaker product family, both the functional core (left-most graph) and structural core (right-most graph) are shown in Figure 11. The structure of the coffeemaker is generated from the function by using grammar rules. In Figure 11 the numbers on arrows Figure 8 - Addition of Optional s functions. The common functions are: store water, heat water and coffee, carry water, mix water and coffee, and store coffee. The function structure of the core functions is shown in Figure 3.a. The optional functions for the coffeemaker family in this example are: separate heating for water and coffee, coffee flow stopper and control strongness of coffee. Step 2: Specify the interactions among the core and the optional functions. With the core functions (Figure 3.a) defined, production rules can be used to add optional functions to generate the variety. The rules (Figure 8) specify how optional functions interact with the core function structure and then generate a new function structure with specific functions for a member of the family. Step 3: Transform the function structure to the structure viewpoint maintaining a correspondence between functions and modules. The basic function structure shown in Figure 3.a can be transformed into the structure viewpoint using grammar rules. Some of these grammar rules are shown in Figure 9. Grammar rule 1 specifies transformation of store water function into intermediate symbols and relationships between them. The shaded box is a hyperedge, which treats the entrance and storage structures as a module, the external interactions with the module are specified at the boundary. In rule 2, the external interaction is specified with specific structures. Similarly, transformations of the other functions to structures are specified using grammar rules. The hyperedge is used to explicitly specify the module corresponding to the function. Applying the production rules the function structure is transformed to physical structure of the coffeemaker. In these Store Carry Mix Mixer Mixer Support Mixer 8 Support Mixer Holder Mechanism - Carry Heat Provide support for coffee 3 Provide Heat to Heater Base - Store Store 4 5 Provide support for coffee Provide Heat to Pot Base Plate Figure 9 - Grammar rules to transform coffeemaker functions to structure Heat Heat 13 9 Heater 2 Figure 10 - Rules to add optional second heater to structure 14 Base Plate 8 Copyright 1999 by ASME

9 Store Carry Mix Store Heat 1 Carry Mix Store Heat 2 9 represent the rule being applied to the graph. The relationships among the different symbols of the core also specified by the grammar are transferred when the production rules are applied. The two cores are equivalent in their viewpoints given the graph grammar that was developed in the previous steps. As we transfer the core function structure and the optional functions to coffeemaker structure the graphs that are generated are members of the language. Because the graph grammar was developed to specify product family architecture the graphs represent coffeemakers that belong to the same product family. PFA (Product Family Architecture) = <Core, Options> where: Core = <C, M, Rc, Rm>, In the function structure viewpoint, the core is the common function structure. Dividing the core function structure into its elements of <C, M, Rc, Rm>, we get C = {Store, Heat water and coffee, carry water, mix water and coffee, store coffee} M = { Ø} Rc= { Flow (Store to Heat water and ), Flow (Heat water and coffee to carry water), Flow (carry water to mix coffee and water), Flow (mix coffee and water to store coffee) Flow (heat water and coffee to store coffee)} Rm={ Ø} Where the basic functions for the coffeemaker family are specified in C and the relationships among these functions are specified in R c. Dividing the optional functions into its elements <C o, P, Rc o, Rm o > we get P={{Ø, Separate Heating},{Ø, Flow Stopper},{Ø, Control Strongness of coffee}} C o is the list of all components mentioned in P. Rm o is empty and Rc o is specified by the grammar rules {{(Ø), (12)}, {(Ø), (11)}, {(Ø), (10)}}. A similar product family architecture can be developed for the structure viewpoint. Step 5: Combine the core and the optional modules to specify the members of the product family. The focus of this step is to use the product family representation scheme and graph grammars to develop Figure 11 - Transformation of to Structure Store Holder Mechanism Pot Carry product architectures of the different members of the product family in different viewpoints. This section is related to the PSPV. The coffeemaker family representation and graph grammars will be used to develop product architectures for the coffeemaker model with all options and the basic model. The two sub-steps are: Step 5.a: Combine the optional functions with the functional core using specified grammar production rules Generation of the product family member with all options can be accomplished by applying grammar rules to add optional functions (from Step 2) to the core function structure. For this example apply rules 10, 11, and 12 to the core function, which gives: Core function Structure Structure with Strongness Control Structure with Strongness Control and Flow Control 12 Structure with Strongness Control, Flow Control and Separate Heating The right hand side of the conversion above is a function structure (Figure 12) for a coffeemaker that allows control of strongness of coffee, stops flow when the coffee pot is not in place and uses separate heaters for heating water and keeping the coffee pot warm. Step 5.b: Use grammar production rules to transform the functions into structure viewpoint for specific coffeemakers. In this step the function structure, obtained from the previous step, is transformed into structure viewpoint by applying grammar production rules. For the coffeemaker example this can be achieved by applying product rules 1 through 9 and then 13 through 16 (from Step 3), where rule 13 and 14 add the second heater, rule 15 specifies the module for controlling strongness of coffee and rule 16 adds the structure module for controlling coffee flow. The final graph representing the architecture of this specific coffeemaker is shown in Figure 12 (right hand side). In the case of the base coffeemaker model the first step can be skipped because no optional function needs to be added to the core function structure. The left hand side graph of is the core function structure. The basic coffeemaker structure can be Control Strongness of Heat Mix Flow Stopper Store Heat Strongness Controller Heater 2 Holder Mechanism Pot Base Plate Stopper Figure 12 - maker will two heaters, coffee flow stopper and coffee strongness control options 9 Copyright 1999 by ASME

10 generated after applying rule 1 through rule 9 to the core function structure. Using the graph grammar we can generate product structures for 8 different coffeemakers. The differences in the architecture comes form addition and deletion of options. Generation of the different product architectures belonging to the same product family is part of the PSPV problem Commonization of existing coffeemakers In this scenario several existing coffeemaker architectures, not previously designed as a product family, will be commonized. The company wants to identify the common platform that can be used to support all the existing product varieties and would like to know the potential product portfolio for the identified product platform. Commonization of existing products require reasoning of the product architectures. Although the general steps required for developing a product family for this scenario are the same for new platform development scenario, the graph grammar implementation changed for several steps. Three different coffeemaker architectures will be used as an illustrating example to relate different graph grammar concepts to the steps for commonization of existing products. Step 1: Determine the common and optional functions for the product family. Step 1.a:Partition the products that are being commonized into common and unique components/modules. In Figure 13, we have three different coffeemaker architectures. We are interested in identifying the common architecture for these varieties. Using subgraph isomorphism we get three subgraphs that are common to all three varieties. The set of common components are: <,,,, Holder Mechanism, Pot,, >. Components that are optional can be determined by subtracting the common from the individual architectures. Performing this task we get the optional components Heater 2, Stopper, and Strongness Controller. The relationships that are common to all varieties are also shown in the subgraphs obtained. Step 1.b:Determine the intent or function of the different components and modules. From designer's previous knowledge, the functions of the different components/modules can be identified to establish a correspondence between function and components. Step 2: Specify the interactions among the core and the optional functions. We can apply node contraction to determine the one to one correspondence between the modules/components and their functional intent. Collapse components that are used to perform same functions into a single node and label the node to reflect the functional intent. The resulting graph will specify function structure for individual products. Using these function structures and the set of optional functions identified in step 1, we can identify the relationships between the optional and the core functions. These relationships can be represented using graph grammars similar to the ones shown in Figure 8. Step 3: Transform the function structure to the structure viewpoint maintaining a correspondence between functions and modules. From the identified functional intents we can specify grammar rules, similar to the ones shown in Figure 5, with the components/modules as the right hand side and the contracted nodes, with functional intent label, as the left hand side of the productions. Step 4: Specify the product family architecture to describe the product portfolio. Product family architectures for both structure and functional viewpoints can be identified from the resulting common and optional sets of components and functions from the previous two steps. The common elements for the viewpoints specify the core, whereas the optional elements specify the available options in their respective viewpoints. Dividing the family of products into core and options specifies how modules of the product should be developed. Using combinatorics members that belong to the coffeemaker product family can be specified (PSPV Design Problem). All the graphs accepted by the grammar makes up the potential set of coffeemakers for the product family. Agarwal and Cagan (1997, 1998) varied shapes to generate different varieties. The 8 product architectures generated by the graph grammar can be used to generate many actual coffeemakers that differ both in functions and shapes. This product family was developed to specify functions and structures related to functions as such the Holder Mechanism Pot Heater 2 Variety #1 Variety #2 Common Holder Mechanism Pot Holder Mechanism Pot Optional Strongness Controller Heater 2 Stopper Strongness Controller Heater 2 Variety #3 Figure 13 - Using Subgraph Isomorphism to determine the core Holder Mechanism Stopper Pot 10 Copyright 1999 by ASME

11 variety provided is distinguished by the functions that are provided. 6 CONCLUSION In this paper we presented an approach that uses graph grammar to develop a formal representation of product family with product platform as focus. The results indicate that some of the inherent characteristics of graph grammars have close mappings to product platform and product family characteristics. Graph grammars in this paper were used to transform function structures to product structures. A product family architecture was also presented, which has two components, core and options. In the case of functional viewpoint the core is the basic functions and options represent the optional functions used to provide the variety. Grammar production rules are used to convert the function structure to structures. Graph grammars also provide a means to determine if a specific product belongs to the product family by parsing and determining the inclusion of the product in the language, which is part of the PSPV Design Problem of PFRS. Subgraph isomorphism was used to determine the product platform for several existing products through commonization (PC problem). A coffeemaker product family was used to illustrate some of the product family concepts. The product family architecture consisted of a core, which was represented by a graph with basic functions. The options represented adding another heater, stopping coffee flow to pot, and variable water flow to filter to the core to generate function structure for variety of coffeemakers. Product family architectures were first defined at the functional level and then productions were used to convert it to structure. The product family architecture defined in the example can be used to generate all 8 members of the product family. Some of the conclusions that can be drawn from the example are: q Graph grammar concepts can be applied to both PC and PSPV problem. q Graph grammars make explicit the structure of a product family, including the structure of functions and physical architectures. q Product family architecture consisting of core and options is a useful formal representation to specify the common product platform and the variety that can be provided. q Graph grammars provide a means to add optional functions and structures to the core by specifying how they interact with other components in the product. In this paper, the coffeemaker structure and function structure was at a very high level. More detailed function structure can be generated using the same approach, then a graph grammar can be developed to convert the function structure into detailed structure. One future activity is the development of graph grammars that can be used to convert the function structure to other important viewpoints and then determine the common platform for all viewpoints. In this paper we did not include the assembly viewpoint, which is one of main constituent of the development of product platforms. Inclusion of different assembly considerations in the product platform development needs to be accomplished to determine the common assembly process that is essential to determine if all the product varieties can be supported on the same assembly line. ACKNOWLEDGMENT We gratefully acknowledge the support of Ford Motor Company for partial funding of this project and the cooperation of several Ford employees. We acknowledge the support of George W. Woodruff School of Mechanical Engineering of Georgia Institute of Technology. Also, we acknowledge the National Science Foundation through grant DMI REFERENCE Agarwal, M. and J. Cagan (1997). "Shape Grammars and their Languages -- A Methodology for Product Design and Product Representation." Proceedings of the DETC 97, 1997 ASME Design Engineering Technical Conferences, Sacramento, CA DETC97/DTM Agarwal, M. and J. Cagan (1998). A blend of different tastes: the language of coffeemakers. Environment and Planning B: Planning and Design Vol 25(No. 2) pp Baker, K. R., M. J. Magazine and H. L. W. Nuttle (1986). The Effect of Commonality on Safety Stock in a Simple Inventory Model. Management Science vol. 3(8) pp Chen, W., D. Rosen, J. Allen and F. Mistree (1994). Modularity and the Independence of al Requirements in Designing Complex Systems. Concurrent Product Design vol. 74 pp Chomsky, N. (1957). Syntactic Structures. Atlantic Highlands, NJ, Humanities Press. Ehrig, H. (1978). "Introduction to the Algebraic Theory of Graph Grammars". Graph Grammars and Their Application to Computer Science, Springer-Vaerlag. Lecture Note Series in Computer Science. Fitzhorn, P. A. (1990). Formal Graph Languages of Shape. AI EDM vol. 4 No. 3. Fu, Z. and A. Pennington (1991). "Geometric Reasoning Based on Graph Grammar Parsing." ASME Design Automation Conference, Miami, Fl., September Ishii, K., C. Juengel and F. Eubanks (1995). "Design for product variety: key to product line structuring." ASME Design theory and methodology Conference, Boston, MA DE-Vol. 83 pp Lewis, H. R. and C. H. Papadimitriou (1981). Elements of the Theory f Computation. Englewood Cliffs, NJ, Prentice-Hall. MacDuffie, J. P., K. Sethuraman and M. L. Fisher (1996). Product Variety and Manufacturing Performance: Evidence from the International Automotive Assembly Plant Study. Management Science vol. 42 pp Martin, M. V. and K. Ishii (1996). "Design For Variety: A Methodology for understanding the Costs of product proliferation." 1996 ASME Design Engineering Technical Conferences, Irvine, CA 96-DETC/DTM Copyright 1999 by ASME

Software Maintenance

Software Maintenance 1 What is Software Maintenance? Software Maintenance is a very broad activity that includes error corrections, enhancements of capabilities, deletion of obsolete capabilities, and optimization. 2 Categories

More information

Syntax Parsing 1. Grammars and parsing 2. Top-down and bottom-up parsing 3. Chart parsers 4. Bottom-up chart parsing 5. The Earley Algorithm

Syntax Parsing 1. Grammars and parsing 2. Top-down and bottom-up parsing 3. Chart parsers 4. Bottom-up chart parsing 5. The Earley Algorithm Syntax Parsing 1. Grammars and parsing 2. Top-down and bottom-up parsing 3. Chart parsers 4. Bottom-up chart parsing 5. The Earley Algorithm syntax: from the Greek syntaxis, meaning setting out together

More information

Grade 2: Using a Number Line to Order and Compare Numbers Place Value Horizontal Content Strand

Grade 2: Using a Number Line to Order and Compare Numbers Place Value Horizontal Content Strand Grade 2: Using a Number Line to Order and Compare Numbers Place Value Horizontal Content Strand Texas Essential Knowledge and Skills (TEKS): (2.1) Number, operation, and quantitative reasoning. The student

More information

Implementing a tool to Support KAOS-Beta Process Model Using EPF

Implementing a tool to Support KAOS-Beta Process Model Using EPF Implementing a tool to Support KAOS-Beta Process Model Using EPF Malihe Tabatabaie Malihe.Tabatabaie@cs.york.ac.uk Department of Computer Science The University of York United Kingdom Eclipse Process Framework

More information

University of Groningen. Systemen, planning, netwerken Bosman, Aart

University of Groningen. Systemen, planning, netwerken Bosman, Aart University of Groningen Systemen, planning, netwerken Bosman, Aart IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to cite from it. Please check the document

More information

A General Class of Noncontext Free Grammars Generating Context Free Languages

A General Class of Noncontext Free Grammars Generating Context Free Languages INFORMATION AND CONTROL 43, 187-194 (1979) A General Class of Noncontext Free Grammars Generating Context Free Languages SARWAN K. AGGARWAL Boeing Wichita Company, Wichita, Kansas 67210 AND JAMES A. HEINEN

More information

A Grammar for Battle Management Language

A Grammar for Battle Management Language Bastian Haarmann 1 Dr. Ulrich Schade 1 Dr. Michael R. Hieb 2 1 Fraunhofer Institute for Communication, Information Processing and Ergonomics 2 George Mason University bastian.haarmann@fkie.fraunhofer.de

More information

The Strong Minimalist Thesis and Bounded Optimality

The Strong Minimalist Thesis and Bounded Optimality The Strong Minimalist Thesis and Bounded Optimality DRAFT-IN-PROGRESS; SEND COMMENTS TO RICKL@UMICH.EDU Richard L. Lewis Department of Psychology University of Michigan 27 March 2010 1 Purpose of this

More information

A Case-Based Approach To Imitation Learning in Robotic Agents

A Case-Based Approach To Imitation Learning in Robotic Agents A Case-Based Approach To Imitation Learning in Robotic Agents Tesca Fitzgerald, Ashok Goel School of Interactive Computing Georgia Institute of Technology, Atlanta, GA 30332, USA {tesca.fitzgerald,goel}@cc.gatech.edu

More information

Guidelines for Writing an Internship Report

Guidelines for Writing an Internship Report Guidelines for Writing an Internship Report Master of Commerce (MCOM) Program Bahauddin Zakariya University, Multan Table of Contents Table of Contents... 2 1. Introduction.... 3 2. The Required Components

More information

A GENERIC SPLIT PROCESS MODEL FOR ASSET MANAGEMENT DECISION-MAKING

A GENERIC SPLIT PROCESS MODEL FOR ASSET MANAGEMENT DECISION-MAKING A GENERIC SPLIT PROCESS MODEL FOR ASSET MANAGEMENT DECISION-MAKING Yong Sun, a * Colin Fidge b and Lin Ma a a CRC for Integrated Engineering Asset Management, School of Engineering Systems, Queensland

More information

Natural Language Processing. George Konidaris

Natural Language Processing. George Konidaris Natural Language Processing George Konidaris gdk@cs.brown.edu Fall 2017 Natural Language Processing Understanding spoken/written sentences in a natural language. Major area of research in AI. Why? Humans

More information

Seminar - Organic Computing

Seminar - Organic Computing Seminar - Organic Computing Self-Organisation of OC-Systems Markus Franke 25.01.2006 Typeset by FoilTEX Timetable 1. Overview 2. Characteristics of SO-Systems 3. Concern with Nature 4. Design-Concepts

More information

Generating Test Cases From Use Cases

Generating Test Cases From Use Cases 1 of 13 1/10/2007 10:41 AM Generating Test Cases From Use Cases by Jim Heumann Requirements Management Evangelist Rational Software pdf (155 K) In many organizations, software testing accounts for 30 to

More information

An Empirical and Computational Test of Linguistic Relativity

An Empirical and Computational Test of Linguistic Relativity An Empirical and Computational Test of Linguistic Relativity Kathleen M. Eberhard* (eberhard.1@nd.edu) Matthias Scheutz** (mscheutz@cse.nd.edu) Michael Heilman** (mheilman@nd.edu) *Department of Psychology,

More information

Field Experience Management 2011 Training Guides

Field Experience Management 2011 Training Guides Field Experience Management 2011 Training Guides Page 1 of 40 Contents Introduction... 3 Helpful Resources Available on the LiveText Conference Visitors Pass... 3 Overview... 5 Development Model for FEM...

More information

The Basics Of Heat (Core Concepts) By John O. E. Clark

The Basics Of Heat (Core Concepts) By John O. E. Clark The Basics Of Heat (Core Concepts) By John O. E. Clark Easy step by step information on how an automotive heater system works, this information pertains to most vehicles and hybrids. May 06, 2014 Jesse

More information

AQUA: An Ontology-Driven Question Answering System

AQUA: An Ontology-Driven Question Answering System AQUA: An Ontology-Driven Question Answering System Maria Vargas-Vera, Enrico Motta and John Domingue Knowledge Media Institute (KMI) The Open University, Walton Hall, Milton Keynes, MK7 6AA, United Kingdom.

More information

Developing True/False Test Sheet Generating System with Diagnosing Basic Cognitive Ability

Developing True/False Test Sheet Generating System with Diagnosing Basic Cognitive Ability Developing True/False Test Sheet Generating System with Diagnosing Basic Cognitive Ability Shih-Bin Chen Dept. of Information and Computer Engineering, Chung-Yuan Christian University Chung-Li, Taiwan

More information

Parallel Evaluation in Stratal OT * Adam Baker University of Arizona

Parallel Evaluation in Stratal OT * Adam Baker University of Arizona Parallel Evaluation in Stratal OT * Adam Baker University of Arizona tabaker@u.arizona.edu 1.0. Introduction The model of Stratal OT presented by Kiparsky (forthcoming), has not and will not prove uncontroversial

More information

A Version Space Approach to Learning Context-free Grammars

A Version Space Approach to Learning Context-free Grammars Machine Learning 2: 39~74, 1987 1987 Kluwer Academic Publishers, Boston - Manufactured in The Netherlands A Version Space Approach to Learning Context-free Grammars KURT VANLEHN (VANLEHN@A.PSY.CMU.EDU)

More information

LING 329 : MORPHOLOGY

LING 329 : MORPHOLOGY LING 329 : MORPHOLOGY TTh 10:30 11:50 AM, Physics 121 Course Syllabus Spring 2013 Matt Pearson Office: Vollum 313 Email: pearsonm@reed.edu Phone: 7618 (off campus: 503-517-7618) Office hrs: Mon 1:30 2:30,

More information

The Enterprise Knowledge Portal: The Concept

The Enterprise Knowledge Portal: The Concept The Enterprise Knowledge Portal: The Concept Executive Information Systems, Inc. www.dkms.com eisai@home.com (703) 461-8823 (o) 1 A Beginning Where is the life we have lost in living! Where is the wisdom

More information

Simulation of Multi-stage Flash (MSF) Desalination Process

Simulation of Multi-stage Flash (MSF) Desalination Process Advances in Materials Physics and Chemistry, 2012, 2, 200-205 doi:10.4236/ampc.2012.24b052 Published Online December 2012 (http://www.scirp.org/journal/ampc) Simulation of Multi-stage Flash (MSF) Desalination

More information

Radius STEM Readiness TM

Radius STEM Readiness TM Curriculum Guide Radius STEM Readiness TM While today s teens are surrounded by technology, we face a stark and imminent shortage of graduates pursuing careers in Science, Technology, Engineering, and

More information

PRODUCT COMPLEXITY: A NEW MODELLING COURSE IN THE INDUSTRIAL DESIGN PROGRAM AT THE UNIVERSITY OF TWENTE

PRODUCT COMPLEXITY: A NEW MODELLING COURSE IN THE INDUSTRIAL DESIGN PROGRAM AT THE UNIVERSITY OF TWENTE INTERNATIONAL CONFERENCE ON ENGINEERING AND PRODUCT DESIGN EDUCATION 6 & 7 SEPTEMBER 2012, ARTESIS UNIVERSITY COLLEGE, ANTWERP, BELGIUM PRODUCT COMPLEXITY: A NEW MODELLING COURSE IN THE INDUSTRIAL DESIGN

More information

Diagnostic Test. Middle School Mathematics

Diagnostic Test. Middle School Mathematics Diagnostic Test Middle School Mathematics Copyright 2010 XAMonline, Inc. All rights reserved. No part of the material protected by this copyright notice may be reproduced or utilized in any form or by

More information

Coimisiún na Scrúduithe Stáit State Examinations Commission LEAVING CERTIFICATE 2008 MARKING SCHEME GEOGRAPHY HIGHER LEVEL

Coimisiún na Scrúduithe Stáit State Examinations Commission LEAVING CERTIFICATE 2008 MARKING SCHEME GEOGRAPHY HIGHER LEVEL Coimisiún na Scrúduithe Stáit State Examinations Commission LEAVING CERTIFICATE 2008 MARKING SCHEME GEOGRAPHY HIGHER LEVEL LEAVING CERTIFICATE 2008 MARKING SCHEME GEOGRAPHY HIGHER LEVEL PART ONE: SHORT-ANSWER

More information

Multimedia Application Effective Support of Education

Multimedia Application Effective Support of Education Multimedia Application Effective Support of Education Eva Milková Faculty of Science, University od Hradec Králové, Hradec Králové, Czech Republic eva.mikova@uhk.cz Abstract Multimedia applications have

More information

Abstractions and the Brain

Abstractions and the Brain Abstractions and the Brain Brian D. Josephson Department of Physics, University of Cambridge Cavendish Lab. Madingley Road Cambridge, UK. CB3 OHE bdj10@cam.ac.uk http://www.tcm.phy.cam.ac.uk/~bdj10 ABSTRACT

More information

Erkki Mäkinen State change languages as homomorphic images of Szilard languages

Erkki Mäkinen State change languages as homomorphic images of Szilard languages Erkki Mäkinen State change languages as homomorphic images of Szilard languages UNIVERSITY OF TAMPERE SCHOOL OF INFORMATION SCIENCES REPORTS IN INFORMATION SCIENCES 48 TAMPERE 2016 UNIVERSITY OF TAMPERE

More information

A Minimalist Approach to Code-Switching. In the field of linguistics, the topic of bilingualism is a broad one. There are many

A Minimalist Approach to Code-Switching. In the field of linguistics, the topic of bilingualism is a broad one. There are many Schmidt 1 Eric Schmidt Prof. Suzanne Flynn Linguistic Study of Bilingualism December 13, 2013 A Minimalist Approach to Code-Switching In the field of linguistics, the topic of bilingualism is a broad one.

More information

Ontologies vs. classification systems

Ontologies vs. classification systems Ontologies vs. classification systems Bodil Nistrup Madsen Copenhagen Business School Copenhagen, Denmark bnm.isv@cbs.dk Hanne Erdman Thomsen Copenhagen Business School Copenhagen, Denmark het.isv@cbs.dk

More information

Unit purpose and aim. Level: 3 Sub-level: Unit 315 Credit value: 6 Guided learning hours: 50

Unit purpose and aim. Level: 3 Sub-level: Unit 315 Credit value: 6 Guided learning hours: 50 Unit Title: Game design concepts Level: 3 Sub-level: Unit 315 Credit value: 6 Guided learning hours: 50 Unit purpose and aim This unit helps learners to familiarise themselves with the more advanced aspects

More information

PRODUCT PLATFORM AND PRODUCT FAMILY DESIGN

PRODUCT PLATFORM AND PRODUCT FAMILY DESIGN PRODUCT PLATFORM AND PRODUCT FAMILY DESIGN PRODUCT PLATFORM AND PRODUCT FAMILY DESIGN Methods and Applications Edited by Timothy W. Simpson 1, Zahed Siddique 2, and Jianxin (Roger) Jiao 3 1 The Pennsylvania

More information

Notes on The Sciences of the Artificial Adapted from a shorter document written for course (Deciding What to Design) 1

Notes on The Sciences of the Artificial Adapted from a shorter document written for course (Deciding What to Design) 1 Notes on The Sciences of the Artificial Adapted from a shorter document written for course 17-652 (Deciding What to Design) 1 Ali Almossawi December 29, 2005 1 Introduction The Sciences of the Artificial

More information

QuickStroke: An Incremental On-line Chinese Handwriting Recognition System

QuickStroke: An Incremental On-line Chinese Handwriting Recognition System QuickStroke: An Incremental On-line Chinese Handwriting Recognition System Nada P. Matić John C. Platt Λ Tony Wang y Synaptics, Inc. 2381 Bering Drive San Jose, CA 95131, USA Abstract This paper presents

More information

Major Milestones, Team Activities, and Individual Deliverables

Major Milestones, Team Activities, and Individual Deliverables Major Milestones, Team Activities, and Individual Deliverables Milestone #1: Team Semester Proposal Your team should write a proposal that describes project objectives, existing relevant technology, engineering

More information

Informatics 2A: Language Complexity and the. Inf2A: Chomsky Hierarchy

Informatics 2A: Language Complexity and the. Inf2A: Chomsky Hierarchy Informatics 2A: Language Complexity and the Chomsky Hierarchy September 28, 2010 Starter 1 Is there a finite state machine that recognises all those strings s from the alphabet {a, b} where the difference

More information

Module 12. Machine Learning. Version 2 CSE IIT, Kharagpur

Module 12. Machine Learning. Version 2 CSE IIT, Kharagpur Module 12 Machine Learning 12.1 Instructional Objective The students should understand the concept of learning systems Students should learn about different aspects of a learning system Students should

More information

CONCEPT MAPS AS A DEVICE FOR LEARNING DATABASE CONCEPTS

CONCEPT MAPS AS A DEVICE FOR LEARNING DATABASE CONCEPTS CONCEPT MAPS AS A DEVICE FOR LEARNING DATABASE CONCEPTS Pirjo Moen Department of Computer Science P.O. Box 68 FI-00014 University of Helsinki pirjo.moen@cs.helsinki.fi http://www.cs.helsinki.fi/pirjo.moen

More information

New Features & Functionality in Q Release Version 3.1 January 2016

New Features & Functionality in Q Release Version 3.1 January 2016 in Q Release Version 3.1 January 2016 Contents Release Highlights 2 New Features & Functionality 3 Multiple Applications 3 Analysis 3 Student Pulse 3 Attendance 4 Class Attendance 4 Student Attendance

More information

D Road Maps 6. A Guide to Learning System Dynamics. System Dynamics in Education Project

D Road Maps 6. A Guide to Learning System Dynamics. System Dynamics in Education Project D-4506-5 1 Road Maps 6 A Guide to Learning System Dynamics System Dynamics in Education Project 2 A Guide to Learning System Dynamics D-4506-5 Road Maps 6 System Dynamics in Education Project System Dynamics

More information

Classroom Connections Examining the Intersection of the Standards for Mathematical Content and the Standards for Mathematical Practice

Classroom Connections Examining the Intersection of the Standards for Mathematical Content and the Standards for Mathematical Practice Classroom Connections Examining the Intersection of the Standards for Mathematical Content and the Standards for Mathematical Practice Title: Considering Coordinate Geometry Common Core State Standards

More information

EQuIP Review Feedback

EQuIP Review Feedback EQuIP Review Feedback Lesson/Unit Name: On the Rainy River and The Red Convertible (Module 4, Unit 1) Content Area: English language arts Grade Level: 11 Dimension I Alignment to the Depth of the CCSS

More information

How to analyze visual narratives: A tutorial in Visual Narrative Grammar

How to analyze visual narratives: A tutorial in Visual Narrative Grammar How to analyze visual narratives: A tutorial in Visual Narrative Grammar Neil Cohn 2015 neilcohn@visuallanguagelab.com www.visuallanguagelab.com Abstract Recent work has argued that narrative sequential

More information

Enduring Understandings: Students will understand that

Enduring Understandings: Students will understand that ART Pop Art and Technology: Stage 1 Desired Results Established Goals TRANSFER GOAL Students will: - create a value scale using at least 4 values of grey -explain characteristics of the Pop art movement

More information

Introduction to HPSG. Introduction. Historical Overview. The HPSG architecture. Signature. Linguistic Objects. Descriptions.

Introduction to HPSG. Introduction. Historical Overview. The HPSG architecture. Signature. Linguistic Objects. Descriptions. to as a linguistic theory to to a member of the family of linguistic frameworks that are called generative grammars a grammar which is formalized to a high degree and thus makes exact predictions about

More information

Language properties and Grammar of Parallel and Series Parallel Languages

Language properties and Grammar of Parallel and Series Parallel Languages arxiv:1711.01799v1 [cs.fl] 6 Nov 2017 Language properties and Grammar of Parallel and Series Parallel Languages Mohana.N 1, Kalyani Desikan 2 and V.Rajkumar Dare 3 1 Division of Mathematics, School of

More information

Parsing of part-of-speech tagged Assamese Texts

Parsing of part-of-speech tagged Assamese Texts IJCSI International Journal of Computer Science Issues, Vol. 6, No. 1, 2009 ISSN (Online): 1694-0784 ISSN (Print): 1694-0814 28 Parsing of part-of-speech tagged Assamese Texts Mirzanur Rahman 1, Sufal

More information

Utilizing Soft System Methodology to Increase Productivity of Shell Fabrication Sushant Sudheer Takekar 1 Dr. D.N. Raut 2

Utilizing Soft System Methodology to Increase Productivity of Shell Fabrication Sushant Sudheer Takekar 1 Dr. D.N. Raut 2 IJSRD - International Journal for Scientific Research & Development Vol. 2, Issue 04, 2014 ISSN (online): 2321-0613 Utilizing Soft System Methodology to Increase Productivity of Shell Fabrication Sushant

More information

Document number: 2013/ Programs Committee 6/2014 (July) Agenda Item 42.0 Bachelor of Engineering with Honours in Software Engineering

Document number: 2013/ Programs Committee 6/2014 (July) Agenda Item 42.0 Bachelor of Engineering with Honours in Software Engineering Document number: 2013/0006139 Programs Committee 6/2014 (July) Agenda Item 42.0 Bachelor of Engineering with Honours in Software Engineering Program Learning Outcomes Threshold Learning Outcomes for Engineering

More information

Classifying combinations: Do students distinguish between different types of combination problems?

Classifying combinations: Do students distinguish between different types of combination problems? Classifying combinations: Do students distinguish between different types of combination problems? Elise Lockwood Oregon State University Nicholas H. Wasserman Teachers College, Columbia University William

More information

Algebra 1, Quarter 3, Unit 3.1. Line of Best Fit. Overview

Algebra 1, Quarter 3, Unit 3.1. Line of Best Fit. Overview Algebra 1, Quarter 3, Unit 3.1 Line of Best Fit Overview Number of instructional days 6 (1 day assessment) (1 day = 45 minutes) Content to be learned Analyze scatter plots and construct the line of best

More information

P. Belsis, C. Sgouropoulou, K. Sfikas, G. Pantziou, C. Skourlas, J. Varnas

P. Belsis, C. Sgouropoulou, K. Sfikas, G. Pantziou, C. Skourlas, J. Varnas Exploiting Distance Learning Methods and Multimediaenhanced instructional content to support IT Curricula in Greek Technological Educational Institutes P. Belsis, C. Sgouropoulou, K. Sfikas, G. Pantziou,

More information

ECE-492 SENIOR ADVANCED DESIGN PROJECT

ECE-492 SENIOR ADVANCED DESIGN PROJECT ECE-492 SENIOR ADVANCED DESIGN PROJECT Meeting #3 1 ECE-492 Meeting#3 Q1: Who is not on a team? Q2: Which students/teams still did not select a topic? 2 ENGINEERING DESIGN You have studied a great deal

More information

Examining the Structure of a Multidisciplinary Engineering Capstone Design Program

Examining the Structure of a Multidisciplinary Engineering Capstone Design Program Paper ID #9172 Examining the Structure of a Multidisciplinary Engineering Capstone Design Program Mr. Bob Rhoads, The Ohio State University Bob Rhoads received his BS in Mechanical Engineering from The

More information

BMBF Project ROBUKOM: Robust Communication Networks

BMBF Project ROBUKOM: Robust Communication Networks BMBF Project ROBUKOM: Robust Communication Networks Arie M.C.A. Koster Christoph Helmberg Andreas Bley Martin Grötschel Thomas Bauschert supported by BMBF grant 03MS616A: ROBUKOM Robust Communication Networks,

More information

Integrating simulation into the engineering curriculum: a case study

Integrating simulation into the engineering curriculum: a case study Integrating simulation into the engineering curriculum: a case study Baidurja Ray and Rajesh Bhaskaran Sibley School of Mechanical and Aerospace Engineering, Cornell University, Ithaca, New York, USA E-mail:

More information

Some Principles of Automated Natural Language Information Extraction

Some Principles of Automated Natural Language Information Extraction Some Principles of Automated Natural Language Information Extraction Gregers Koch Department of Computer Science, Copenhagen University DIKU, Universitetsparken 1, DK-2100 Copenhagen, Denmark Abstract

More information

Speech Recognition at ICSI: Broadcast News and beyond

Speech Recognition at ICSI: Broadcast News and beyond Speech Recognition at ICSI: Broadcast News and beyond Dan Ellis International Computer Science Institute, Berkeley CA Outline 1 2 3 The DARPA Broadcast News task Aspects of ICSI

More information

Litterature review of Soft Systems Methodology

Litterature review of Soft Systems Methodology Thomas Schmidt nimrod@mip.sdu.dk October 31, 2006 The primary ressource for this reivew is Peter Checklands article Soft Systems Metodology, secondary ressources are the book Soft Systems Methodology in

More information

OCR for Arabic using SIFT Descriptors With Online Failure Prediction

OCR for Arabic using SIFT Descriptors With Online Failure Prediction OCR for Arabic using SIFT Descriptors With Online Failure Prediction Andrey Stolyarenko, Nachum Dershowitz The Blavatnik School of Computer Science Tel Aviv University Tel Aviv, Israel Email: stloyare@tau.ac.il,

More information

Digital Fabrication and Aunt Sarah: Enabling Quadratic Explorations via Technology. Michael L. Connell University of Houston - Downtown

Digital Fabrication and Aunt Sarah: Enabling Quadratic Explorations via Technology. Michael L. Connell University of Houston - Downtown Digital Fabrication and Aunt Sarah: Enabling Quadratic Explorations via Technology Michael L. Connell University of Houston - Downtown Sergei Abramovich State University of New York at Potsdam Introduction

More information

COMPUTATIONAL COMPLEXITY OF LEFT-ASSOCIATIVE GRAMMAR

COMPUTATIONAL COMPLEXITY OF LEFT-ASSOCIATIVE GRAMMAR COMPUTATIONAL COMPLEXITY OF LEFT-ASSOCIATIVE GRAMMAR ROLAND HAUSSER Institut für Deutsche Philologie Ludwig-Maximilians Universität München München, West Germany 1. CHOICE OF A PRIMITIVE OPERATION The

More information

Guidelines for Project I Delivery and Assessment Department of Industrial and Mechanical Engineering Lebanese American University

Guidelines for Project I Delivery and Assessment Department of Industrial and Mechanical Engineering Lebanese American University Guidelines for Project I Delivery and Assessment Department of Industrial and Mechanical Engineering Lebanese American University Approved: July 6, 2009 Amended: July 28, 2009 Amended: October 30, 2009

More information

An Online Handwriting Recognition System For Turkish

An Online Handwriting Recognition System For Turkish An Online Handwriting Recognition System For Turkish Esra Vural, Hakan Erdogan, Kemal Oflazer, Berrin Yanikoglu Sabanci University, Tuzla, Istanbul, Turkey 34956 ABSTRACT Despite recent developments in

More information

Introduction to Causal Inference. Problem Set 1. Required Problems

Introduction to Causal Inference. Problem Set 1. Required Problems Introduction to Causal Inference Problem Set 1 Professor: Teppei Yamamoto Due Friday, July 15 (at beginning of class) Only the required problems are due on the above date. The optional problems will not

More information

AGS THE GREAT REVIEW GAME FOR PRE-ALGEBRA (CD) CORRELATED TO CALIFORNIA CONTENT STANDARDS

AGS THE GREAT REVIEW GAME FOR PRE-ALGEBRA (CD) CORRELATED TO CALIFORNIA CONTENT STANDARDS AGS THE GREAT REVIEW GAME FOR PRE-ALGEBRA (CD) CORRELATED TO CALIFORNIA CONTENT STANDARDS 1 CALIFORNIA CONTENT STANDARDS: Chapter 1 ALGEBRA AND WHOLE NUMBERS Algebra and Functions 1.4 Students use algebraic

More information

Functional Skills Mathematics Level 2 assessment

Functional Skills Mathematics Level 2 assessment Functional Skills Mathematics Level 2 assessment www.cityandguilds.com September 2015 Version 1.0 Marking scheme ONLINE V2 Level 2 Sample Paper 4 Mark Represent Analyse Interpret Open Fixed S1Q1 3 3 0

More information

Developing a TT-MCTAG for German with an RCG-based Parser

Developing a TT-MCTAG for German with an RCG-based Parser Developing a TT-MCTAG for German with an RCG-based Parser Laura Kallmeyer, Timm Lichte, Wolfgang Maier, Yannick Parmentier, Johannes Dellert University of Tübingen, Germany CNRS-LORIA, France LREC 2008,

More information

Given a directed graph G =(N A), where N is a set of m nodes and A. destination node, implying a direction for ow to follow. Arcs have limitations

Given a directed graph G =(N A), where N is a set of m nodes and A. destination node, implying a direction for ow to follow. Arcs have limitations 4 Interior point algorithms for network ow problems Mauricio G.C. Resende AT&T Bell Laboratories, Murray Hill, NJ 07974-2070 USA Panos M. Pardalos The University of Florida, Gainesville, FL 32611-6595

More information

Reinforcement Learning by Comparing Immediate Reward

Reinforcement Learning by Comparing Immediate Reward Reinforcement Learning by Comparing Immediate Reward Punit Pandey DeepshikhaPandey Dr. Shishir Kumar Abstract This paper introduces an approach to Reinforcement Learning Algorithm by comparing their immediate

More information

Introduction to Moodle

Introduction to Moodle Center for Excellence in Teaching and Learning Mr. Philip Daoud Introduction to Moodle Beginner s guide Center for Excellence in Teaching and Learning / Teaching Resource This manual is part of a serious

More information

Guidelines for drafting the participant observation report

Guidelines for drafting the participant observation report Employment and Women on the 21st century in Europe: From Household economy to SME economy (Small and Medium enterprises) MUPYME Project Guidelines for drafting the participant observation report As agreed,

More information

1 Use complex features of a word processing application to a given brief. 2 Create a complex document. 3 Collaborate on a complex document.

1 Use complex features of a word processing application to a given brief. 2 Create a complex document. 3 Collaborate on a complex document. National Unit specification General information Unit code: HA6M 46 Superclass: CD Publication date: May 2016 Source: Scottish Qualifications Authority Version: 02 Unit purpose This Unit is designed to

More information

Honors Mathematics. Introduction and Definition of Honors Mathematics

Honors Mathematics. Introduction and Definition of Honors Mathematics Honors Mathematics Introduction and Definition of Honors Mathematics Honors Mathematics courses are intended to be more challenging than standard courses and provide multiple opportunities for students

More information

Enhancing Learning with a Poster Session in Engineering Economy

Enhancing Learning with a Poster Session in Engineering Economy 1339 Enhancing Learning with a Poster Session in Engineering Economy Karen E. Schmahl, Christine D. Noble Miami University Abstract This paper outlines the process and benefits of using a case analysis

More information

Transfer Learning Action Models by Measuring the Similarity of Different Domains

Transfer Learning Action Models by Measuring the Similarity of Different Domains Transfer Learning Action Models by Measuring the Similarity of Different Domains Hankui Zhuo 1, Qiang Yang 2, and Lei Li 1 1 Software Research Institute, Sun Yat-sen University, Guangzhou, China. zhuohank@gmail.com,lnslilei@mail.sysu.edu.cn

More information

Highlighting and Annotation Tips Foundation Lesson

Highlighting and Annotation Tips Foundation Lesson English Highlighting and Annotation Tips Foundation Lesson About this Lesson Annotating a text can be a permanent record of the reader s intellectual conversation with a text. Annotation can help a reader

More information

Lecture 1: Machine Learning Basics

Lecture 1: Machine Learning Basics 1/69 Lecture 1: Machine Learning Basics Ali Harakeh University of Waterloo WAVE Lab ali.harakeh@uwaterloo.ca May 1, 2017 2/69 Overview 1 Learning Algorithms 2 Capacity, Overfitting, and Underfitting 3

More information

Circuit Simulators: A Revolutionary E-Learning Platform

Circuit Simulators: A Revolutionary E-Learning Platform Circuit Simulators: A Revolutionary E-Learning Platform Mahi Itagi Padre Conceicao College of Engineering, Verna, Goa, India. itagimahi@gmail.com Akhil Deshpande Gogte Institute of Technology, Udyambag,

More information

Mathematics subject curriculum

Mathematics subject curriculum Mathematics subject curriculum Dette er ei omsetjing av den fastsette læreplanteksten. Læreplanen er fastsett på Nynorsk Established as a Regulation by the Ministry of Education and Research on 24 June

More information

Lecture 2: Quantifiers and Approximation

Lecture 2: Quantifiers and Approximation Lecture 2: Quantifiers and Approximation Case study: Most vs More than half Jakub Szymanik Outline Number Sense Approximate Number Sense Approximating most Superlative Meaning of most What About Counting?

More information

CEFR Overall Illustrative English Proficiency Scales

CEFR Overall Illustrative English Proficiency Scales CEFR Overall Illustrative English Proficiency s CEFR CEFR OVERALL ORAL PRODUCTION Has a good command of idiomatic expressions and colloquialisms with awareness of connotative levels of meaning. Can convey

More information

By Laurence Capron and Will Mitchell, Boston, MA: Harvard Business Review Press, 2012.

By Laurence Capron and Will Mitchell, Boston, MA: Harvard Business Review Press, 2012. Copyright Academy of Management Learning and Education Reviews Build, Borrow, or Buy: Solving the Growth Dilemma By Laurence Capron and Will Mitchell, Boston, MA: Harvard Business Review Press, 2012. 256

More information

Grammars & Parsing, Part 1:

Grammars & Parsing, Part 1: Grammars & Parsing, Part 1: Rules, representations, and transformations- oh my! Sentence VP The teacher Verb gave the lecture 2015-02-12 CS 562/662: Natural Language Processing Game plan for today: Review

More information

Statewide Framework Document for:

Statewide Framework Document for: Statewide Framework Document for: 270301 Standards may be added to this document prior to submission, but may not be removed from the framework to meet state credit equivalency requirements. Performance

More information

ISFA2008U_120 A SCHEDULING REINFORCEMENT LEARNING ALGORITHM

ISFA2008U_120 A SCHEDULING REINFORCEMENT LEARNING ALGORITHM Proceedings of 28 ISFA 28 International Symposium on Flexible Automation Atlanta, GA, USA June 23-26, 28 ISFA28U_12 A SCHEDULING REINFORCEMENT LEARNING ALGORITHM Amit Gil, Helman Stern, Yael Edan, and

More information

Carter M. Mast. Participants: Peter Mackenzie-Helnwein, Pedro Arduino, and Greg Miller. 6 th MPM Workshop Albuquerque, New Mexico August 9-10, 2010

Carter M. Mast. Participants: Peter Mackenzie-Helnwein, Pedro Arduino, and Greg Miller. 6 th MPM Workshop Albuquerque, New Mexico August 9-10, 2010 Representing Arbitrary Bounding Surfaces in the Material Point Method Carter M. Mast 6 th MPM Workshop Albuquerque, New Mexico August 9-10, 2010 Participants: Peter Mackenzie-Helnwein, Pedro Arduino, and

More information

Proof Theory for Syntacticians

Proof Theory for Syntacticians Department of Linguistics Ohio State University Syntax 2 (Linguistics 602.02) January 5, 2012 Logics for Linguistics Many different kinds of logic are directly applicable to formalizing theories in syntax

More information

Numeracy Medium term plan: Summer Term Level 2C/2B Year 2 Level 2A/3C

Numeracy Medium term plan: Summer Term Level 2C/2B Year 2 Level 2A/3C Numeracy Medium term plan: Summer Term Level 2C/2B Year 2 Level 2A/3C Using and applying mathematics objectives (Problem solving, Communicating and Reasoning) Select the maths to use in some classroom

More information

Are You Ready? Simplify Fractions

Are You Ready? Simplify Fractions SKILL 10 Simplify Fractions Teaching Skill 10 Objective Write a fraction in simplest form. Review the definition of simplest form with students. Ask: Is 3 written in simplest form? Why 7 or why not? (Yes,

More information

Word Segmentation of Off-line Handwritten Documents

Word Segmentation of Off-line Handwritten Documents Word Segmentation of Off-line Handwritten Documents Chen Huang and Sargur N. Srihari {chuang5, srihari}@cedar.buffalo.edu Center of Excellence for Document Analysis and Recognition (CEDAR), Department

More information

TIMSS ADVANCED 2015 USER GUIDE FOR THE INTERNATIONAL DATABASE. Pierre Foy

TIMSS ADVANCED 2015 USER GUIDE FOR THE INTERNATIONAL DATABASE. Pierre Foy TIMSS ADVANCED 2015 USER GUIDE FOR THE INTERNATIONAL DATABASE Pierre Foy TIMSS Advanced 2015 orks User Guide for the International Database Pierre Foy Contributors: Victoria A.S. Centurino, Kerry E. Cotter,

More information

Towards a Collaboration Framework for Selection of ICT Tools

Towards a Collaboration Framework for Selection of ICT Tools Towards a Collaboration Framework for Selection of ICT Tools Deepak Sahni, Jan Van den Bergh, and Karin Coninx Hasselt University - transnationale Universiteit Limburg Expertise Centre for Digital Media

More information

Writing Research Articles

Writing Research Articles Marek J. Druzdzel with minor additions from Peter Brusilovsky University of Pittsburgh School of Information Sciences and Intelligent Systems Program marek@sis.pitt.edu http://www.pitt.edu/~druzdzel Overview

More information

Objectives. Chapter 2: The Representation of Knowledge. Expert Systems: Principles and Programming, Fourth Edition

Objectives. Chapter 2: The Representation of Knowledge. Expert Systems: Principles and Programming, Fourth Edition Chapter 2: The Representation of Knowledge Expert Systems: Principles and Programming, Fourth Edition Objectives Introduce the study of logic Learn the difference between formal logic and informal logic

More information

On Human Computer Interaction, HCI. Dr. Saif al Zahir Electrical and Computer Engineering Department UBC

On Human Computer Interaction, HCI. Dr. Saif al Zahir Electrical and Computer Engineering Department UBC On Human Computer Interaction, HCI Dr. Saif al Zahir Electrical and Computer Engineering Department UBC Human Computer Interaction HCI HCI is the study of people, computer technology, and the ways these

More information