Eindhoven Universityof Technology The Netherlands.

Slides:



Advertisements
Similar presentations
MDI 2010, Oslo, Norway Behavioural Interoperability to Support Model-Driven Systems Integration Alek Radjenovic, Richard Paige The University of York,
Advertisements

Eindhoven Technische Universiteit An Experimental Design System for the Very Early Design Stage B. de Vries A.J. Jessurun.
Eindhoven Technische Universiteit What offers VR to the Designer Bauke de Vries Henri Achten.
1212 Sharing Design Knowledge in the Building and Construction Industry Dr.ir. Jos van Leeuwen Associate Professor Design Systems Group Department of Building.
Software Reuse SEII-Lecture 28
Challenges to model solving software in the internet era Adrie J.M. Beulens Huub Scholten (Wageningen University, Information Technology Group)
0 General information Rate of acceptance 37% Papers from 15 Countries and 5 Geographical Areas –North America 5 –South America 2 –Europe 20 –Asia 2 –Australia.
SSP Re-hosting System Development: CLBM Overview and Module Recognition SSP Team Department of ECE Stevens Institute of Technology Presented by Hongbing.
1 Software Architecture: a Roadmap David Garlen Roshanak Roshandel Yulong Liu.
Unified Modeling (Part I) Overview of UML & Modeling
L ECTURE 2 S OFTWARE P ROCESSES 1. O BJECTIVES To describe outline process models for requirements engineering, software development, testing and evolution.
1212 Management and Communication of Distributed Conceptual Design Knowledge in the Building and Construction Industry Dr.ir. Jos van Leeuwen Eindhoven.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Engineering Systems of.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
A Generic Software Framework for building Hybrid Ontology-Backed Models for Driving Applications Colin Puleston, James Cunningham, Alan Rector Bio-Health.
An Introduction to Software Architecture
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
What is MOF? The Meta Object Facility (MOF) specification provides a set of CORBA interfaces that can be used to define and manipulate a set of interoperable.
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
Information System Development Courses Figure: ISD Course Structure.
Approaching a Problem Where do we start? How do we proceed?
Modeling and simulation of systems Model building Slovak University of Technology Faculty of Material Science and Technology in Trnava.
95-843: Service Oriented Architecture 1 Master of Information System Management Service Oriented Architecture Lecture 3: SOA Reference Model OASIS 2006.
Chapter 7 System models.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
1 CIM OSA CIMOSA Computer Integrated Manufacturing Open System Architecture 1 David CHEN IMS-LAPS, University Bordeaux 1.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
A Context Model based on Ontological Languages: a Proposal for Information Visualization School of Informatics Castilla-La Mancha University Ramón Hervás.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
ICCS WSES BOF Discussion. Possible Topics Scientific workflows and Grid infrastructure Utilization of computing resources in scientific workflows; Virtual.
APPLY FUNCTIONAL MODELING TO CONSEQUENCE ANALYSIS IN SUPERVISION SYSTEMS Present by Xinxin Zhang 1 Morten Lind 1, Giulio Gola 2,
© TRESETarget Industry TRESE Group Department of Computer Science University of Twente P.O. Box AE Enschede, The Netherlands
3.2 Semantics. 2 Semantics Attribute Grammars The Meanings of Programs: Semantics Sebesta Chapter 3.
User Profiling using Semantic Web Group members: Ashwin Somaiah Asha Stephen Charlie Sudharshan Reddy.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Eurostat SDMX and Global Standardisation Marco Pellegrino Eurostat, Statistical Office of the European Union Bangkok,
Issues in Ontology-based Information integration By Zhan Cui, Dean Jones and Paul O’Brien.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Developing Product Line Components Jan Bosch Professor of Software Engineering University of Groningen, Netherlands
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
© Drexel University Software Engineering Research Group (SERG) 1 The OASIS SOA Reference Model Brian Mitchell.
Lecture 21: Component-Based Software Engineering
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Class Diagrams. Terms and Concepts A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships.
Nigel Baker UWE & CERN/EP-CMA Design Patterns for Integrating Product and Process Models The C.R.I.S.T.A.L. Project ( C ooperative R epositories & I nformation.
1 SWE Introduction to Software Engineering Lecture 14 – System Modeling.
2000 Research Overview Dr. Kim Mens Programming Technology Lab Vrije Universiteit Brussel.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
1 SOA Seminar Seminar on Service Oriented Architecture SOA Reference Model OASIS 2006.
1 Process activities. 2 Software specification Software design and implementation Software validation Software evolution.
Software Design Process. What is software? mid-1970s executable binary code ‘source code’ and the resulting binary code 1990s development of the Internet.
Classification, Identification and BIM
1 CASE Computer Aided Software Engineering. 2 What is CASE ? A good workshop for any craftsperson has three primary characteristics 1.A collection of.
Definition CASE tools are software systems that are intended to provide automated support for routine activities in the software process such as editing.
Architecture Components
Component Based Software Engineering
Methontology: From Ontological art to Ontological Engineering
An Introduction to Software Architecture
Presentation transcript:

Eindhoven Universityof Technology The Netherlands

of Technology Eindhoven University AID ’98 3 Jos van Leeuwen Eindhoven University of Technology Harry Wagter P2-Managers, The Netherlands Robert Oxman Technion, Israel A Features Framework for Architectural Information

of Technology Eindhoven University AID ’98 4 Content of the presentation Dynamic Nature of Design Evolution of Information models Feature-Based Modelling Features Framework Conclusion & Current work: Design Systems development

of Technology Eindhoven University AID ’98 5  design as problem solving  design as rational decision making  design as information process  design as pattern recognition Yet another (un-)satisfactory paradigm for design thinking?  design as a dynamic process [Cross1998]

of Technology Eindhoven University AID ’98 6 Design is dynamic because of: ill- defined problems, creative processes in design, Dynamic Nature of Design (1) development of designers, and development of B&C industry.

of Technology Eindhoven University AID ’98 7 Design = problem solving concurrent activities of generating, manipulating, interpreting, and evaluating information. Dynamic Nature of Design (2)

of Technology Eindhoven University AID ’98 8 Information is not treated as static data: content and structure are constantly changing. Information models for design support must allow (re-)defining and (re-)structuring information Dynamic Nature of Design (3) Evolution of Information Models

of Technology Eindhoven University AID ’98 9 Extensibility of Information Models The conceptual model allows for definition of new entities: to evolve with a designer’s style, for specific building projects, for new techniques, methods, materials, or products e.g. industrial construction systems.

of Technology Eindhoven University AID ’98 10 Flexibility of Information Models Flexibility is also required in the instantiated models. Flexibility is required by extensibility and modifications to the conceptual model. Bricks Wood Segment2 Bricks Segment1 Bricks Wall

of Technology Eindhoven University AID ’98 11 Content of the presentation Dynamic Nature of Design Evolution of Information models Feature-Based Modelling Features Framework for Architecture Conclusion & Current work: Design Systems development

of Technology Eindhoven University AID ’98 12 Feature-Based Modelling (1) Developed in mechanical engineering: group technology codes, manufacturing process plans, numerical control programming, … high level entities of information with a semantic meaning for engineering.

of Technology Eindhoven University AID ’98 13 Feature-Based Modelling (2) Main purpose is to describe the shape of product-parts in Form Features, but classifications also include: Precision Features, Material Features, Assembly Features, Pattern Features,...

of Technology Eindhoven University AID ’98 14 Form Features Examples of typical Form Features in mechanical engineering ribs depression pattern Feature compound Feature: blind hole + through hole

of Technology Eindhoven University AID ’98 15 Feature-Based Modelling (2) Main purpose is to describe the shape of product-parts in Form Features, but classifications also include: Precision Features, Material Features, Assembly Features, Pattern Features,...

of Technology Eindhoven University AID ’98 16 Feature-Based Modelling (3) Feature Libraries are not limited sets, but new types of Features can be defined. The structure of Feature Models is not predefined: relationships are determined during design.

of Technology Eindhoven University AID ’98 17 Feature-Based Modelling (4) In Architecture, a more extensive approach is necessary, including: physical building parts non-physical concepts different levels of abstraction

of Technology Eindhoven University AID ’98 18 A Features Framework Information infrastructure for: evolution of information models along with design formalisation of design knowledge by definition of modelling entities flexible relationships within the structure of information models

of Technology Eindhoven University AID ’98 19 definition of the term ‘Feature’ A Features Framework A Feature is an autonomous, coherent collection of information, with semantic meaning to a designer and possibly emerging during design, that is defined to formalise a design concept at any level of abstraction, either physical or non-physical, as part of a building model. A Feature is an autonomous, coherent collection of information, with semantic meaning to a designer and possibly emerging during design, that is defined to formalise a design concept at any level of abstraction, either physical or non-physical, as part of a building model.

of Technology Eindhoven University AID ’98 20 Conceptual model of Feature Types three layered model A Features Framework Meta Layer: classes of Feature Types & classes of Feature Instances Feature Model, describing a particular design in Feature Instances Generic Feature Types defines format of Specific Feature Types specialisation instantiated into complex Room(Space) { Assoc Wall enclosedBy [0:?]; Spec Function function[1:?]; }

of Technology Eindhoven University AID ’98 21 standardisation of Generic Feature Types A Features Framework qForm Features qPhysical Features qContext Features qProcedural Features qLife-Cycle Features l Morphological Features l Topological Features l Geometrical Features l Compositional Features l Material Features l Composition performance Features l Design conceptual relation Features l Interface Features l Performance dependency Features l Planning Features l Preparation Features l Integration Features l Functionality Features l Operation Features l Maintenance Features l Security Features

of Technology Eindhoven University AID ’98 22 activities in FBM A Features Framework domain knowledge design project knowledge Feature Type 1 Feature Type Library 2 Feature Model 4 Feature instance 3 3 3Instantiation 1Formalisation 2Classification 4Modelling

of Technology Eindhoven University AID ’98 23 three layered model A Features Framework Meta Layer: classes of Feature Types & classes of Feature Instances Feature Model, describing a particular design in Feature Instances Generic Feature Types defines format of Specific Feature Types specialisation instantiated into complex Room(Space) { Assoc Wall enclosedBy [0:?]; Spec Function function[1:?]; }

of Technology Eindhoven University AID ’98 24 classes of Feature Types & classes of Feature Instances A Features Framework definition of the class FeatureType

of Technology Eindhoven University AID ’98 25 Subclasses of FeatureType subclasses of the class FeatureType

of Technology Eindhoven University AID ’98 26 relationships A Features Framework specialisation decomposition association specification can be defined at the conceptual level only may be defined at both conceptual and instance level All relationships are references for reasons of flexibility.

of Technology Eindhoven University AID ’98 27 relationships A Features Framework Example of ‘shared’ Features.

of Technology Eindhoven University AID ’98 28 instance level relationships A Features Framework

of Technology Eindhoven University AID ’98 29 Issues being / to be addressed  approaches to support knowledge formalisation:  recognition  searching  matching  consistency management  various ways of reasoning (e.g. decision support, evaluation, inference)  version management and mapping  constraint testing & solving  ownership & responsibility  data exchange  standardisation

of Technology Eindhoven University AID ’98 30 Design & Decision Support Systems in Architecture & Urban Planning Design Systems development imulations nteractive V R D I S irtual eality nformation ystem istributed esign nformation ystem esign imulations nteractive istributed

of Technology Eindhoven University AID ’98 31 Design Systems development Interactive Design System Design support for the total life-cycle of a building Consult design knowledge Check against standards/rules Simulate product behaviour Simulate user behaviour designer design system ANSYS structural analysis

of Technology Eindhoven University AID ’98 32 Design Systems development Distributed Interdisciplinary Design System Design system for a distributed environment Design system for a inter- disciplinary design process Consistent information handling Design management research designer A design system designer B design system designer C design system

of Technology Eindhoven University AID ’98 33 Design Systems development VR environment to register the behaviour of users (building/urban environment) Evaluate behaviour and information handling Technical infrastructure development Tool development designer A design system user X design system user Y design system Interactive Distributed Interdisciplinary Design System

of Technology Eindhoven University AID ’98 34 Design Systems development design system 1 VR Interface for design 2 Feature-based modelling 3 Design Studio of the Future 1Virtual Reality hardware & software 2Information modelling techniques 3Development and testing in education

of Technology Eindhoven University AID ’98 35 Vacancies Chair at Design Systems group 5 PhD Student positions in VR and construction technique building physics urban planning geometric modelling validation of VR methods for behaviour measurement  