engleski

Object-oriented modelling of the design process

None of the design theories which are used today, like e.g. descriptive, prescriptive, general, and axiomatic design theories, is alone capable, to describe and to formalise the whole design process and to make possible a complete computer support of this process [Vajna, 1999.]. Keeping this in mind, the research presented is directed towards development a framework that could enable the use of different partial models in an integrated manner. We assume that the object-oriented methodologies can provide more appropriate and flexible ways of software system modelling than the other techniques. The design process is here viewed as a sequence of transitions from an initial state of data, constraints and goals to a final state, the description of the designed mechanical artefact. These transitions are allocated to individual participants or teams, and individual or integrated computational tools or models. A design process may no longer be viewed as a static institutionalised structure, but rather as a dynamic network that is constructed in real-time as design goals, needs, priorities, and resources evolve [Wallace, 1999]. In the framework of an integrated CAD environment, the designer should work with an open toolbox, enabling him to create his own classes and partial models of the design process according to his current needs. The goal is to develop a framework for modelling the design process independently of design phase and a class of design task. CONTRIBUTION OF THE PAPER In the proposed approach, every occurrence, kind of action, set of information, relation and other real-world “things” from the domain of the design process, are attempted to be modelled as objects. In the presented research phase, the considerations are limited to recognition of basic entities, their attributes and relationships, while the necessary operations are only denoted. Proposed design process model is conceived as an “open toolbox” with packages of classes and objects. In such an environment the designer should mainly use the existing classes as templates and building blocks. According to [Booch et al., 1999] the object is a concrete manifestation of an abstraction ; an entity with a well defined boundary and identity that encapsulates state and behaviour. The proposed object-oriented design process model is built upon following sets of entities: Basic structural elements: - design parameter ; - design parameter container ; - action ; - designer (as an “actor” in the process) ; - design task ; - product information object ; - product structure object (part) ; - interface to external software tool (data transfer protocols for communication with common software tools that are in use in a particular design environment). Associations between structural elements: - relations between set of objects (sets of class instances), recorded in matrix form (an implementation of design structure matrix is included) ; - design constraints ; Behavioural and control elements: - design decision rules ; - elements to support the control of design process flow ; - process description & management elements (a package of classes). Architectural elements: databases ; programming tools ; CAD packages ; computational tools. CONCLUSION The presented research phase includes the analysis of the structural and behavioural elements. The techniques of object oriented modelling and design have been intensively explored in last ten years, and it seems that they finally reached a high level of maturity The UML language and POET object database are chosen as an implementation environments for the proposed design process model. Besides that UML is going to be a standard, such a choice has some other benefits: - All members of a software development team use a common language. - Confusion over terminology and requirements is averted. - Transition between planning and programming is shortened due to a clearer understanding between designers and implementers. The proposed object structure is still a scaled prototype model. A lot of work remains to be done: - refining the proposed structure, establishing class packages and hierarchies - defining and designing attribute sets and operations in classes - defining “use cases”, defining and diagramming collaborations between objects - designing “main” system operations that have the threads of control - developing interfaces to the commercial object and relational databases The benefits of object oriented methodology and UML raises new challenges. Using UML, a distributed design community can easily collaborate in developing the design process model. Maybe that could enable initiating the process of creating a theoretical framework for integrated computer design process support that will be widely accepted in a design community.

Object-oriented Methodology ; Design process modelling ; Computer-based design support

nije evidentirano