INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN, ICED’07 28 - 31 AUGUST 2007, CITE DES SCIENCES ET DE L'INDUSTRIE, PARIS, FRANCE
DESIGN PROCESS VISUALIZING AND REVIEW SYSTEM WITH ARCHITECTURAL CONCEPT DESIGN ONTOLOGY
Sung Ah Kim and Yong Se Kim Creative Design & Intelligent Tutoring Systems (CREDITS) Research Center, Sungkyunkwan University, Korea
ABSTRACT DesignScape, a prototype design process visualization and review system, is being developed. Its purpose is to visualize the design process in more intuitive manner so that one can get an insight to the complicated aspects of the design process. By providing a tangible utility to the design process performed by the expert designers or guided by the system, novice designers will be greatly helped to learn how to approach a certain class of design. Not only as an analysis tool to represent the characteristics of the design process, the system will be useful also for learning design process. A design ontology is being developed as a critical part of the system, to represent designer’s activities associated with various design information during the conceptual design process, and then to be utilized for a computer environment for design analysis and guidance. To develop the design ontology, a conceptual framework of design activity model is proposed, and then the model has been tested and elaborated through investigating the early phase of architectural design. A design process representation model is conceptualized based on the ontology, and reflected into the development of the system.
Keywords: Design Process, Design Research, Design Ontology, Design Activity, Architectural Design
1 INTRODUCTION Design is an evolving process interwoven with numerous intermediate representations and various design information. Producing and utilizing them, designers develop the design by conducting various cognitive and physical activities. Although there have been various tools to give a better understanding of the design process, both designers and researchers still desire an environment where the design process is better represented and more insightful so that one can have better understanding of design processes. We need better knowledge of design processes, to better manage complexity, to improve collaboration among the specialists in design teams, to improve the tool support for design, and to improve design education (Eastman 1999). This research started from the necessity to visualize the design process in more intuitive manner so that one can get an insight to the complicated aspects of the design process, being able to examine the dynamic relations among design activities and associated information. By providing such a utility to represent the characteristics of the design process carried out by experienced designers, or formalized according to certain design guidelines, we believe that novice designers will be greatly assisted in learning how to deal with certain classes of design.
2 NATURE OF DESIGN PROCESS
2.1 Design Activities & Visual Representations It is generally known that the design process, at the cognitive level, consists of a series of design activities. They are described as analysis-synthesis-evaluation (Lawson 1990), seeing-moving-seeing
ICED’07/295 1 (Schön & Wiggins 1992), or imaging-presenting-testing (Zeisel 1981). Concepts are synthesized, and goals and objectives are generated through the analysis. Generated concepts and goals are evaluated, and they go through more evaluation and synthesis. Rather than following a sequential order, these activities take place in an iterative manner. Design is an iterative process where schemes are recognized, explored, revised and enhanced until a solution is identified (Sanders 1996). This iterative or cyclic process takes place more vividly during the conceptual design. It is the period having richness of ideas, problems, and creativity. Protocol analysis has been widely used as a method to analyze the activities and find meaningful patterns from verbal protocol data. The verbal protocol, in many cases, is not sufficient to explain what is going on during the design. Designers during the protocol collection, for example, often fail to express what’s in their mind, and even trying to do so, they perceive design problems and generate solutions in such an automatic manner that it’s just impossible to explain every moments. The best method to complement the verbal protocol is to rely on the visual representation, sketches. Many studies carried out to examine what information architects think of and read off from their own sketches as an essential medium in designer's dialectic process (Schön and Wiggins 1992; Suwa and Tversky 1997). Sketching is the essential part for producing and storing the solutions, and also for identifying conflicts and possibilities for the architects (Akin 1978). As Lawson argued, “architects (designers) find it hard to think without a pencil in their hand” (Lawson 1994). Even though sketching itself can be also conducted automatically as most of designers are trained to do so, thus, what is drawn on the sketch may not exactly reflect what’s in their mind, it is evident that sketches (visual or physical externalization, in more general terms) provide important clue to understand the designer’s thinking along with the evolution of a design process. Thus, it seems also clear that by combining the trails of design activities and external presentations, we can have the more insightful method to show and understand the design process.
2.2 Conceptual Design Stage
2.2.1 Design phases This research focuses on the early stages of design. In case of architectural design, the process is relatively well defined in practice against its inherent complexity compared with other domains. According to the definitions by AIA (American Institute of Architecture), the typical building design process for the architectural office is divided into several distinct phases (Table 1 shows the early phases among them). It is just a guideline, however. Many offices, for example, do not separate the site analysis from the pre-design, or in case of commercial building design, divide the pre-design into more steps like feasibility study, programming, and then preliminary-design (Kim & Sohn 2002). Table 1. Design phases of architectural design (AIA 1993) Phases Expected Tasks (partial) - design objectives - limitations and criteria - site requirements pre-design - space relations - initial approximate facility areas and space requirements - flexibility and expandability, etc. site - site analysis and selection, conceptual analysis - site development planning, design - on-site utility studies, - zoning processing, etc. schematic - space layout or space schematics design - conceptual site and building plans, - preliminary sections and elevations, - preliminary selection of building systems and materials, - approximate dimensions, areas and volumes, perspective sketches, study models
ICED’07/295 2 Pre-design phase is often referred to as ‘programming’. According to Duerk (1993), architectural programming is “the systematic process of gathering and analyzing information about a building or other setting, and then using that information to create guidelines for the performance of that setting.” Programming is also defined as “consultation to establish and document the following detailed requirements for a project” (AIA 1993). In general, pre-design is a problem-seeking stage. Site analysis is treated as distinct phase probably because it involves on-site activity in real projects. In contrast to the pre-design stage, schematic design phase is a problem solving stage in this phase. What is called ‘creative part’ usually refers to the schematic design phase where main concepts of form and space are generated.
2.2.2 Design tasks during conceptual design stage Any case of large architectural design project may easily require total design effort of 100 man-years to complete design. Considering the amount of time required for protocol analysis, it is clear that we will never collect even one large-scale design protocol (Eastman, Potts and Hsi, 1998). No method is available to record and analyze the protocols of whole design process. For this reason, design protocol analysis has been usually confined within a conceptual design of small-scale buildings like house or single-function spaces like bathroom. Such design projects needs to be conducted on a conceptual level in a limited amount of time (like in a few hours). Thus, this type of conceptual design tends to become a mixture of pre-design, site analysis and schematic design. For example, due to the cyclic nature of conceptual design, schematic design often has to deal with programming issues and site analysis in an iterative manner. As shown in Table 1, each design phase requires specific design tasks. As the distinction between design phases is critical only for the management of large-scale real world design projects, however, we cannot expect that the tasks will be carried out in a regular order when time is seriously limited.
2.3 Analysis and Learning of Conceptual Design Process During the experiment within the limited amount of time, architect needs to understand given design brief and formulate general idea about the design task, understand the general site condition, and imagine the preliminary plans together. As the design tasks are dealt with in an irregular order, the task conducting pattern will be different from designer to designer. There are tasks and information supposed to be carried out and dealt with within specific design phases. Some designers may follow the standard order in an organized manner, but some may not. Both design tasks and design activities take place in an iterative way as described above, so the analysis of such pattern may show the difference of designer’s characteristics. On the other hand, design information and representations are always to be associated with these activities. They provide the trail of the design development, and important clue to the reasons behind decision-makings. Our assumption is that a design process visualization and review environment integrating the representation of design activity and associated design representations should not only be useful as a reviewing tool but to be helpful for the novice designers to learn from others.
3 REREPSENTATION OF DESIGN PROCESS
3.1 Issue-Solution Cycle
3.1.1 Preliminary design process model A preliminary design process model was framed to represent the conceptual architectural design where most of creative design decisions are made at the schematic level. In this model, design is seen as a process composed of successive design activities to solve the identified problems. Design is to be completed when all the problems are solved to an acceptable degree. Design is also seen as an iterative process where design issues are evoked from analyzing design facts, and the conceived issues are addressed by developing design solutions. This process is cyclic as the conceived issue may evoke another issue, and a solution also generates more issues to address. In addition to the design tasks, design activities, and visual representations, the notion of design issue-solution is included into the representation model at this point.
ICED’07/295 3 3.1.2 Design issue An issue means any means, concern, question, topic, proposition, or situation that demands a design response in order for a building project to be successful for its clients and users (Duerk 1993). Issues are general categories for sorting design information into manageable chunks to support efficient decision making. For example, “vitalizing community” is often considered as a major issue of a housing design. As the designer should provide a solution to a certain degree, this property is considered as a design issue. Whether this issue is given as a design requirement, or intended by the designer, it requires the designer to analyze it, and synthesize proper design solution to respond to the issue.
3.1.3 Solution Solution generation often takes place very automatically. The coupling of “vitalizing community” and “courtyard’ is established as design knowledge built through designer’s education and experience. So the more experience the designer has the more automatic and faster the solution generation should be. Each design issue will not evoke only one specific solution. Multiple design solutions are to be generated and one of them will eventually be chosen for the skeleton of final solution. Sometimes many solutions can survive for a long time competing each other, and sometimes the competition ceases early. The adopted solution is then to gain the concrete specification through the refinement process. But even the adopted solution can be abandoned in the long run failing to be finalized as a concrete form and space after the refinement process. When designer generates a solution, it’s often a typological concept or from a previous case, something from his/her experience and analogy. The “courtyard” or “alley” is a typical concept to accommodate the functionality of an issue like “vitalizing community”. They are prototypical schemes associated with the function “vitalizing community” to the designer’s memory. Such process was well described by Issue-Concept-Form model (Oxman 1998, 2001). Applying the ICF model, we can elaborate the solution part into concept and form. The concept is a more abstract, typological, or skeletal idea while the form refers to the specific form and space embodied from the concept.
3.1.4 Observing the issue-solution cycle This type of concept generation is relatively well captured in verbal protocol or diagrammatic sketch. For example, in the sketch of Figure 1, the designer tried to generate a concept for the issue, “a unique space for the client who is a photographer”. He came up with a concept, “gallery”, a prototypical functional space. The designer refines the concept into “Plan with Gallery” without particular verbal explanation. At this moment he might have recalled some specific case from his memory, or generated more abstract and functional concept. When a designer expresses the verbal protocol, we can define the content of the issue developed into the solution form with ease. However, when a form is revised into several alternative forms as in Figure 1, we can just assume that there should be an issue that is not explicitly expressed. However, it is highly probable that, even if not explicitly described, there’s an issue involved between concept and form, or between evolving representations. The graph in Figure 1 represents the evolution of the concept to the form, and branching into other alternative forms. Each alternative has involved an issue (represented as rectangle shape with the letter ‘I’) that is not explicitly declared by the designer. In this case, the reviewer analyzed the verbal protocol, and named a possible issue for each alternative design solutions.
Figure 1. Design issue and solutions captured in protocol analysis
ICED’07/295 4 3.2 Design Sessions The concept of ‘design session’ is introduced in order to represent the issue-solution cycle. A design process consists of multiple threads of design sessions. The design session couples the design issue and corresponding solution. A design session is a series of design activities for the designer to raise a design issue, and generate design solution to address the issue, which is materialized into form and space. Such design sessions sometimes takes a few minutes to several hours to complete. Some design sessions end without finding the final solution. There can be multiple design sessions evolving in parallel as the designer focuses on other design issues while the current design session is not completed (Figure 2). Even if it is possible for multiple sessions to be evolved in parallel, the designer cannot actually engage in more than one session at a specific point. In fact, after the designer raises a design issue, the issue can successively evoke another issue and again another before the designer synthesizes a design solution to the issue. The notion of multiple sessions is then introduced as designer’s characteristic behaviour of managing design process. Whether the creative design has something to do with the number of the co-evolving design sessions is beyond the scope of this research. It is assumed that designers manage multiple threads of design sessions until the design is done, and incessantly shift the design focus. Figure 2 provides a schematic view of the co-evolving design sessions. Timeline is in horizontal direction and bar-shaped strips represent design sessions. The uppermost session spans relatively a long period, overlapping three other sessions. Gray areas represent the repose period. This period happens when the designer shifts his design focus to other issue or sub-issue without coming up with the solution to the current issue at hand. Sub-issues can entail more sub-issues as shown with the smallest session strip in the figure. Once the designer generates a solution to the sub-issue he/she may come back to the unfinished session. It is often observed that the designer may focus on different issues not directly related to the current issue. The lowermost session strip in Figure 2 represents this type of focus shifting.
Figure 2. Design Sessions
3.3 Representation Model of Conceptual Design Process Any design session is a series of successive design activities. An ideal pattern of a design session may start with
ICED’07/295 5 new session starts to evolve in parallel. Figure 3 elaborate the Figure 2. A design issue can evoke another issue, which constitutes a sub-session. On the other hand, the designer may just shift the design focus to other remote issues, which spawns a parallel design session.
Figure 3. Representation of multiple design sessions with design activities
3.4 Timeline-based Representation A series of design protocol analyses have been conducted. Its purpose of was not to propose a new protocol analysis method, but to verify the usability of the representation model. That is, whether the design issues and corresponding solutions can be easily captured and represented either by designer or by the reviewer. Also, another concern was whether the design activities can be well identified. Modest scale house design tasks were assigned to the student designers and expert designers (Figure 4). Rather than analyzing the protocol data from the scratch, we focused on the possible design issues and development of design solutions from the collected data.
Figure 4. Examples of design tasks and outputs for the protocol analysis As shown on the Figure 1 and 4, we illustrated manually the trails of generated issues and solutions over the scanned images of drawing papers. Types of design activities were categorized by applying various coding schemes on the protocol data. Sketches (either on drawing paper or pen-based graphic application) were main specimen to examine what had happened during the design. Comparing with the protocol data, design issues and facts, solutions (concepts) were identified, and marked on the sketches. Corresponding sketches were extracted from the drawing paper manually, and matched with the protocol data. Design activities were categorized and represented as color bars along the timeline, and corresponding sketches were displayed in parallel (Figure 5). This method was proved to be effective to understand the flow of design thinking, yet a better method was desired. Accordingly, we wanted to have a more visual and interactive environment to show the evolution of design process, in which design activities and design sketches, along with design issues and solutions are systematically presented on the timeline-based display in an interactive environment.
ICED’07/295 6
Figure 5. An initial idea of timeline-based representation of design activities, sketches, and design issue/solutions
4 CONCEPTUAL DESIGN ONTOLOGY
4.1 Ontology Design In order to elaborate the representation model to be used with timeline-based representation, the relationships among the elements of the representation model needed to be more formalized. Thus we have developed a concept design ontology encompassing addressed elements of process representation. First of all, the relationships among design information, (fact – issue – solution), and design activities are needed to be defined. As in a typical ontology construction, terms and properties of building design process are integrated into the model. By analyzing various housing design cases (e.g. Dept. of Housing 2004), and through the application of existing design guidelines and procedures, a design ontology focusing on housing design is being implemented.
4.2 Ontology Modeling
4.2.1 Design stages and tasks Tasks required for each design phase need to be associated with design information layer to be used as a design guide. Typical design tasks have been collected from the sources like housing design guidelines. In this model, each design phase is a subclass of a class Design Stage. Any instance of Design Stage (Table 2, Figure 6) is related to the next following stage (precede relation). Then, each design stage should have tasks as defined in design process guidelines. Issues and facts are also related with design tasks (e.g. Space Zoning, Site Zoning, etc). Some facts tend to be considered in specific phases of design, yet not strictly limited. The task should somehow utilize the fact, define the issue, or generate the concept (solution) (Figure 6). Table 2. Major concepts of the ontology Concept SubConcept (Instance) - Pre-Design - Site Analysis Design Stage - Schematic Design - Space Zoning - Site Zoning Design Task - Set Design Objectives, etc. - Analysis - Synthesis Design Activity - Evaluation
ICED’07/295 7
Figure 6. Design ontology representation centered around the design stage (not exhaustive and some elements are hidden)
4.2.2 Fact, Issue, Solution How the design issue is then conceived? It requires designer’s knowledge to understand the fact and derive issues out of the fact. Duerk (1993) categorized sets of facts in architectural design as the objective information to be interpreted by the designer. As the properties of facts are relatively objective, they refer to the physical or visual state of the given site, information about user or client, and given design requirement and clear constraints. Fact is modeled as a super class of product- related, context-related facts, and user-related facts in this ontology (Figure 7).
Figure 7. Adding design information to the ontology (not exhaustive and some elements are hidden)
ICED’07/295 8 4.2.3 Design activity The activity concept is associated with this ontology. At this point, the activity class is specialized into analysis, synthesis, and evaluation (represented as ActivityGeneric, AnalysisG, SynthesisG, and EvaluationG respectively in Figure 8). Each subtype has subtypes again, and will be expanded as the ontology is more elaborated. Evaluation is linked to solution with the input relation. It means that the target of evaluation is an instance of solution. Evaluation will generate issue (see the output relation). In the same manner synthesis uses issue as input, and generates solution. Analysis will use fact as input and generate issue. These definitions are still schematic level. As the model develops, this part will grow to integrate other design models.
Figure 8. Adding design activity to the ontology (not exhaustive and some elements are hidden)
5 DESIGNSCAPE
5.1 Design The purpose of the DesignScape is to have a design process analysis and learning environment. The user should be able to quickly grasp the activity patterns of design process using DesignScape. The user also gets an easy access to the design information and understands the relationships of the design information. It should be also possible to review the design history, and understand the involved issues and representations. With the aid of such environment novice designers are able to learn design process from the repertoire of accumulated design projects carried out by expert designers. Designers can self-record and critically review his/her own design process, and compare it with other designer’s processes. This will help the reviewers and tutors analyze student’s process and utilize them for the design education. In the future, a collaborative design learning environment will be possible by featuring communication and sharing facilities. Another purpose of the DesginScape development is to reflect and test the design ontology and then revise the ontology through the iterative test with the design experiments. It is still being redesigned and implemented reflecting the findings from the ontology construction.
5.2 Implementation
5.2.1 Dual system The initial version of DesignScape was implemented as a dual system of design capture tool and process visualization tool. DesignScape allows a designer to review his/her design process while self- recording conducted design activities based on the given coding scheme. The system basically captures the state of design representation, primarily sketches on the screen, associated with the activities. The system also provides the reviewer with an interactive visual environment in which one
ICED’07/295 9 can get an overview to the examinee’s design process, inspect each design activity with its associated information.
5.2.2 Design process capturing The capture tool resides on the screen while the user draws sketches using a graphic application. The graphic application is used for writing as well as drawing ideas as conducted on actual drawing paper. Whenever a period of distinct design activity is finished, the designer can click the corresponding activity type button of the capture tool. Available set of buttons reflects the currently chosen coding scheme. Multiple coding schemes can be maintained so that the user can edit and choose a proper coding scheme for the experiment. The coding scheme is customizable. Activity recording usually happens when the user finishes a portion of sketch or diagram, or a group of text description of information. Then, the designer is requested to define the name of activity so far since the last definition of activity. The system basically captures anything on the screen, actions such as referencing other documents, or what appears on the web browser while searching for design material. These are also captured into the system with associated information. The user can also add text comment through the annotation tool. The system keeps track of all these information, and store them into a form of XML file.
5.2.3 Design process visualization The visualization part was implemented as a Flash application. When the capture tool is terminated by the user’s request, the viewer tool gets ready to display the design process. The design activities are represented as a successive chain of color rectangle nodes along the timeline. As the node chain shows the duration of activity by its length, type of activity by its color, the whole chain of nodes gives a quick view of activity pattern (Figure 9).
Figure 9. Sequence of drawings and corresponding activities represented in DesignScape As moving the cursor over the activity node, preview of the captured representation pops-up instantly so the user can quickly review the lineage of representation development by scrolling over the array of nodes. On the additional channel, referenced documents are represented as icon objects so that one can quickly grasp the kinds of information. Each object responds to the mouse cursor to show detailed information like activity nodes (Figure10).
ICED’07/295 10
Figure 10. Inspecting the associated information of the design activity node in DesignScape
By being able to switch to different coding schemes, it is easy to examine the design process from different activity models. At this point the system represents the design activities with sketch result on the timeline. Reviewers can grasp an overview of design process pattern as the system uses color schemes in linked nodes. Also, the system allows inspecting associated design representation and annotations, on-offline information resources that the designer referenced during the design just by clicking over the icon objects.
5.3 Design Guidance
5.3.1 Managing design alternatives DesignScape is being developed to encompass more functions to be used as a design guidance tool based on the design ontology. One of them is the representation of co-evolving design alternatives. While developing the design, when terminating the development of the current design, or hold the idea for a while and go back to a previous design idea and develop it to other direction, the user activates the viewer and directly selects the corresponding activity node. The selected node is used as a starting point of the alternative design development, becoming a common ancestor of multiple design alternatives. Figure 11 shows the snapshot of the second version of DesignScape, enabling the representation and management of alternative design stream.
Figure 11. Representation of design alternatives using branched activity nodes
ICED’07/295 11 Edges between nodes represent the lineage of design refinement, so the nodes linked to a common representation with arc edge means that they are alternatives to each other. It is being implemented in Java and C# to allow the representation of such complicated network of design stream, and to allow high-level interaction with the activity nodes. For example duplicate the design process into another window and apply different coding scheme (Figure 11).
5.3.2 Integrating issue-solution browser DesignScape will be equipped with an issue-solution browser. By triggering the browser either by designer’s request or by system’s judgment, the browser pops-up. The browser gives a guide in determining what kind of issues should be considered given the design facts, and what kind of solutions are considerable to address the issue. This browser will be based on the ontology that we are developing. Thus, the designer can self-record the categories of design issues and solutions by selecting from the browser. The network of issue- solution is added into the timeline-based display as a result (Figure 12).
Figure 12. DesignScape allowing the representation of design sessions
6 CONCLUSION This research started from the necessity of an interactive system which externalizes the elements of design process in visual or tangible manner. Verbal protocol analyses have been conducted to formalize the hypothetical design process model. The model will be further refined through the implementation of rich representation model and then used for the development of design process externalization system in the successive research. The representation model was conceptualized, combining the design activity and design information as the component of design process. The concept of design session was introduced to effectively represent the dual layer model. Building design ontology requires more input form various sources. More design models and guidelines will be integrated in the future research. The DesignScape is being developed into a next version in order to reflect the concept of multiple design sessions, and to be more flexible in terms of design process representation. New features include design alternative representation, and data export, association with various referenced information during the design. Eventually, this will be used as a powerful design analysis and guidance tool.
ACKNOWLEDGEMENT This research was supported by Ministry of Science & Technology (MOST), Korean government, through its National Creative Research Initiative Program.
REFERENCES [1] Akin, Ö. (1978). How do architects design? in J.C. Latombe (ed.), Artificial Intelligence and Pattern Recognition in Computer Aided Design, North Holland, New York.
ICED’07/295 12 [2] The American Institute of Architects (1993). The American Institute of Architects' Document B163 - Standard Form of Agreement Between Owner and Architect for Designated Services, AIA [3] Department of Housing (2004). Smart Housing: The Research House Design Decision Making Process, Queensland Government [4] Dorst, K. and Dijkhuis, J. (1995). Comparing paradigms for describing design activity, Design Studies vol.16, pp261-274 [5] Duerk, D.P. (1993). Architectural Programming: Information Management of Design, Wiley [6] Eastman, C.M. (1999). Representation of Design Process, Invited keynote Speech in Conf. on Design Thinking, MIT, Cambridge, Apr. 23-25, 1999 [7] Gero, J.S. and McNeil, T. (1998). An Approach to the Analysis of Design Protocols, Design Studies, vol.19, no.1, pp21-41 [8] Eastman, C.M., Hsi, I., and Potts, C. (1998) "A Study of a Large Shanghai Architectural Project", GVU Report, College of Computing, Georgia Institute of Technology, Atlanta [9] Kim, H.Y. & Sohn, M.G. (2002) An Approach to a Systematic Building Design Works, Review of Architecture and Building Science, Sep. 2002, Architectural Institute of Korea [10] Lawson, B. (1997). How Designer Think, Architectural Press [11] Oxman, R. (1998). Computational Support for Visual Thinking in Design Ideation, Information Visualization Conference (IV'98) IEEE, Computer Society Press, London [12] Oxman, R. (2001). The Mind in Design, in Eastman et al. (eds.), Design Knowing and Learning: Cognition in Design Education, Elsevier [13] Sanders, K. (1996) The digital architect: a commonsense: guide to using computer technology in design practice, 1st.ed. Wiley [14] Schön, D.A. & Wiggins, G. (1992). Kinds of seeing and their functions in designing, Design Studies, vol.13, no.2, pp135 -156. [15] Suwa, M. & Tversky, B. (1997). What do architects and students perceive in their design sketches? A protocol analysis, Design Studies, 18 (4), pp.385–403. [16] Zeisel, J. (1981). Inquiry by Design: Tools for Environment-Behavior Research, Cambridge University Press
Contact: Y. S. Kim CREDITS Research Center / Sungkyunkwan University 300 Chunchun, Jangan Suwon Korea Phone: +82 31-290-6581 Fax: +82 31-290-6582 e-mail: [email protected] URL: http://credits.skku.edu
ICED’07/295 13