CHAPTER 5 MODELING ENGINEERING SYSTEMS

Transcription

1 CHAPTER 5 MODELING ENGINEERING SYSTEMS 5.1 ENGINEERING INFORMATION DYNAMICS AND DATA MODELS Providing an insight into the complex process of engineering information technology to achieve and maintain a description of a rapidly evolving product or process requires an array of information technology tools. A particularly critical technology issue is the interplay between data modeling methods and the rapidly evolving product or process definition. Figure 5.1 identifies some of the application needs that information technology must support such as modeling the evolving design/manufacturing data, tracking and controlling the evolution of the production process definition and providing timely characterization of constraints. Figure 5.1 also identifies some of the requirements data modeling tools must satisfy such as effective tools, implementation independent front ends, schema evolutions, data type extensibility and a variety of part definition abstractions. The facilities to support engineering information dynamics is limited and much of the basic technology is still evolving. Figure 5.2 outlines one view of the status of current information modeling tools. Such tools have many capabilities but are limited to static models of information and to relational database management software. Object technology is just beginning to emerge but is still immature. Only a few baseline approaches for integrating engineering applications data are available as examples and test beds. The slowness with which these tools are evolving is caused by many factors. Current modeling tools were originally targeted to a much more narrow set of applications and an understanding of information dynamics is still rather primitive. Data management software and modeling products represent a major investment by user organization as well as by vendors and it is difficult to evolve to newer concepts. The generic capabilities needed for engineering are unclear and the applicability of these capabilities to a broader set of fields such as construction, services, and business is not apparent. Basically it is a hard problem with limited underlying theory and yet a area of EDM 5-1

2 critical importance to engineering information management. Thus it is a fertile area for research. The following sections discuss specific areas for future research. 5.2 EVALUATION OF DATA MODELS The evaluation of a data model with respect to a given problem domain, e.g., manufacturing, design, business, etc., must consider how that model will be utilized. If the model does not capture the necessary information, or if the model cannot be implemented efficiently, then the model is not useful, Thus a major issue in model evaluation is the definition of metrics. It is unclear what the criteria is for judging the "goodness" of a model. Currently, no good metrics exist, and it is unclear whether such metrics should be qualitative or quantitative. Furthermore it is unclear what benchmarks should be used in evaluations. Relational data models or database systems have some benchmarks in the area of business applications; however, these benchmarks typically deal with performance issues, such as response time or throughput. While performance is important in engineering databases, business application benchmarks are inadequate for engineering applications. For example, an engineering design transaction may span days while a business transaction typically takes only a few seconds. Metrics are also needed to measure modeling power. Little has been done for the relational model since it was developed. This is due in part to the fact that the relational model does not offer a rich semantic modeling capability. The development of metrics for measuring modeling power are critically needed. Recommended research on method for evaluating of data models include: Test Suites for Data Models. Develop a set of test applications which can be used to test the modeling capability and completeness of languages and development environments. Such tests should cover a representative set of modeling requirements for design and manufacturing data. Performance Benchmarks for Engineering Application Development Systems/Data Bases. The performance requirements of engineering databases are radically different from the performance requirements of business databases. The research should lead to benchmarks appropriate for evaluating engineering databases and for comparison and evaluation of database products. Evaluate Existing Object Systems and Object Databases for Engineering EDM 5-2

3 Applications. Utilize the above evaluation metrics on existing database management systems relevant to their value for engineering applications, and determine the areas where further developments are needed (both in modeling extensions and performance improvements). These research topics will require close collaboration between research organizations and industry groups, to ensure that the evaluations represent practical engineering requirements. 5.3 TOOLS AND METHODOLOGIES Extensive design methodologies exist for non-object oriented languages and databases which provide useful guidelines for both applications and systems design which can facilitate system development to achieve correctness and maintainability. Computer Aided Software Engineering (CASE) tools for non object languages are also emerging to support the design, implementation and verification of software development. Graphical fourth generation language (4GL) tools are emerging to support relational database design through simple-to-use graphical front ends. While these tools only cover a part of the system design process, they improve productivity and increased application correctness. They also make the system development processes accessible to a wider community of programmers and non-expert programmers. Most current CASE and database design tools exist for separate environments; however, they do not effectively support the development of systems which combine complex application functionality integrated together with a complex database schema. Object systems, however, offer a more natural software design environment for application developers, and tend to improve program correctness, maintainability, and extensibility. Object databases can also alleviate many of the problems of traditional database systems (such as referential integrity), and reduce the pitfalls of database design. However, there can be good object implementations based on bad object implements. An object programming language can be used to develop a system which is correct, maintainable, and extensible, but it can also produce a system which is bug-ridden, incomprehensible, and not extensible. Object languages support good applications design, but cannot enforce it. Therefore, object design guidelines support good EDM 5-3

4 concept, design but and methodology is needed which encourage "good" applications design. Similarly, an object database can resolve many of the problems of traditional database systems, but can still provide opportunities for bad database design. Thus guidelines and methodologies are needed also for object database schema design. Object languages and object database provide richer modeling capabilities than non-object systems, training and methods are needed to ensure that these capabilities are exploited. Furthermore, there are currently no methodologies or tools to support retrofitting existing applications and databases with object functionality. Research is needed on tools and methodologies which will lead to: 1. Guidelines and methodologies for object applications and database design where the design goals include correctness, maintainability, and extensibility/reusability. 2. CASE/4GL tools to support object systems design; such tools should be integrated, provide a single environment for systems design, and include application design and database design. The tools and methodologies should cover the entire design spectrum from conceptual to physical design. 3. Methodologies and tools which include transaction and concurrent control modeling; support design of multi-user applications with the close cooperation and interaction between users typical of LAN-based design environments; and allow detailed constraint specification with constraint languages. 5.4 MODELS FOR DESIGN AND MANUFACTURING The application of database technology to the design and manufacturing domain is a relatively recent phenomenon with previous applications primarily in support of business activities. Most database applications have used hierarchical, network and relational data model and associated DBMSs that do not capture engineering design data very well. Because of past investments and organizational commitments, many companies have had to force their existing DBMSs to meet design and manufacturing applications. In recent years a strong interest has emerged in object oriented models that seek to incorporate the following features: EDM 5-4

5 a. Data abstraction and encapsulation: objects are defined into classes; the behavior of a class is captured in terms of operations or methods; and object classes are organized into type hierarchies. b. Inheritance and polymorphism: by virtue of the type hierarchies, object classes inherit the attributes and methods from their super classes. Polymorphism increases reusability and maintainability, by allowing "generic coding". c. Complex objects: this provides the ability to define new composite objects from previously defined objects in a nested or hierarchical fashion. The object oriented family can be divided into models like GEMSTONE that add persistence to the object oriented language SMALLTALK so that objects created in a program can be permanently shared. Another family of object systems originates more from the database area and incorporates object orientation and the above concepts as a part of the data model. A series of such models and their implementations have come about in the recent past: e.g. ORION from MCC, the PDM (Probe Data Model) from CCA-XEROX, IRIS from H-P, FUGUE from EIS, and VBASE from ONTOLOGIC. PDM, IRIS and FUGUE use objects and functions to model data, often referred to as object/function models. The advantages of the object oriented approach are the following. The models are "natural" and allow a designer to map his or her real domain of interest directly into the database; they are highly extensible since new object types may be added or old ones deleted or modified easily; they are supposed to capture behavior in terms of methods and operations or functions. Although the object oriented models are powerful, existing implementations suffer from the following; a. No realistic large scale applications in design and manufacturing exist today that use these models. b. The current implementation are weak in that they suffer from obvious performance problems in terms of offering reasonable response times to queries or compilation of type definitions. c. The systems of today do not offer appropriate interfaces for design or manufacturing engineers. There are efforts under way such as PDES or EXPRESS to come up with a standard EDM 5-5

6 object model for describing parts, products, constraints, etc. These efforts are still ongoing and it is unclear whether they will be able to capture the rich semantics of design data in full detail. Another drawback in date modeling efforts in real situations is that they need additional training or education on the part of the engineers/designers. Without it engineers are not able to exploit the modeling power of models, tools and the database systems. There seems to be a growing interest in conceptual modeling in general with the increasing popularity of such methods as IDEFIX, NIAM, and ER and the evolution of commercial software tools to support their use. Today s object implementations are particularly weak for modeling complex designs, supporting multiple representations of the same design, capturing a variety of system constraints, and dealing with the dynamics of information. Recommended research in the area of models for design and manufacturing include: 1. Overall system performance of object models. Although object/function models or just object oriented models (like ORION or VBASE) have many modeling advantages and features, they will not be used by the community at large unless they provide reasonable system performance. Research is needed in modeling performance and addressing issues of strong efficiency, query optimization, transaction processing strategies, etc. No good metrics exist today for measuring the performance of such systems. 2. Execution models of object oriented databases for design applications. Design applications have peculiar requirements in terms of dealing with huge objects; they have transactions that may take place over months of time as well as transactions that are shared among many users. Research on transaction models would involve dealing with check-in/check-out, transactions in the context of reasoning, distributed transactions, long transactions, shared transactions concerning control algorithms, update propagation, etc. Execution models should include a controlled execution of methods, triggers, rules, etc. 3. Support for information modeling dynamics. Data models are needed that allow instance evolution in terms of assigning new types to instances and versioning. Schema evolution should make it possible to modify the schema by adding/modifying/deleting existing objects and/or methods and functions. In general, a robust DBMS should deal with system evolution gracefully - involving changes in EDM 5-6

7 applications, organizational structure etc. This would give a high degree of data independence. Versioning is an important engineering requirement and significant research is needed on capabilities relevant to changing designs. 4. Support for complex objects. Although the object/function models have a fairly rich set of modeling features, complex objects are currently treated as aggregation hierarchies. More work is needed to capture the full functional and structural interplay and the modeling of design requirements in engineering systems. The multiple representation, multiple inheritance problems are not solved. Behavioral specifications and constraint modeling also needs more study. 5.5 THEORETICAL ISSUES FOR OBJECT, SEMANTIC AND CONCEPTUAL MODELS The attempt to formalize complex engineering design tasks brings into focus some limitations of these most important system objects of all, the people themselves. Human conceptual capabilities, their structure and function, form the background for all of the subsequent discussion of "models" in this section. This assumption in turn implies that the disciplines of psychology, philosophy, linguistics, and mathematics are equal contributors to the creation, application, and understanding of models. Consciously held models encode knowledge that allow one to interpret, act upon, and predict interaction with the environment in a purposeful manner. From this view point, a model is a tool, no less than a hammer or a surgeon's scalpel. Along these same lines, a model can serve to tear apart or more precisely specify what was previously contemplated. An example of this from the database world are the two abstraction: aggregation and generalization. With these two abstractions, an analyst can distinguish two different kinds of object interconnections; without them it is difficult to express this distinction. Current problems and ambiguities in engineering environments involve "abstractions", "defined type ambiguity", "semantic equivalencies", "logical expressiveness and completeness", as well as the more mundane expressions such as "are we talking about the same features?" These concepts reflect an increasing awareness that linguistic, philosophic, and psychological issues are coextensive with mathematical ones. Given these perceptions, it seems helpful to approach the analysis of engineering EDM 5-7

8 models, in particular objected oriented models, from a linguistic, psychological, philosophical and mathematical perspective. Furthermore, it seems useful to characterize different classes of these object oriented models as kinds of languages. From this perspective it is appropriate to address data models from the perspective of lexicon, syntax and semantics; in short, the grammar of the language. Recommended research on theoretical issues for object, semantics and conceptual engineering data models include: 1. Engineering Oriented Modeling Language. There is a need for modeling languages that are more closely matched with the way human beings interpret their interaction with the environment. 2. Multiple Level Modeling Languages. This means that there is a need for levels of modeling languages that smoothly map from one to the other and are bounded above by natural language. In particular there is a need for a richer logic that can express more of the conceptual requirements than is provided, for example, by first order logic. 3. Formalized Information Modeling Design Theory. There is a need for a formal treatment of object/functional models from both a mathematical and linguistic viewpoint. There is no design theory to go with object oriented models and systems today. There is a need to develop and test such a theory against practical situations. 5.6 PRIORITIES FOR RESEARCH In summary, the priorities for research in engineering information dynamics and data models are: Evaluation of Data Models Tools and Methodologies Models for Design and Manufacturing Data Integration Theory It requires data modeling tools and evaluation approach, development of models specifically related to design and manufacturing and developing a new theoretical base for modeling technology. Some of the modeling methods in use today are described next. 5.7 SAMM EDM 5-8

9 SAMM (Systematic Activity Modeling Methodology) is a activity modeling technique. It uses a system of nodes and branches, each node being represented by an activity diagram. This method represents both the activity flows as well as data flows along with the amount of data being exchanged. 5.8 IDEF0 1 IDEF0 modeling methodology is part of the IDEF (ICAM Definition) method developed under the ICAM (Integrated Computer Aided Manufacturing) program of U.S. Air Force. IDEF0 is a process or activity modeling technique. IDEF0 is used to produce a function model which is a structured representation of the functions of a system, and of the information and objects which interrelate those functions. This methodology was developed from an earlier technique called SADT (Structured Analysis and Design Technique). The basic concepts of IDEF0 are : Cell Modeling Graphic Representation. The box and arrow graphics of an IDEF0 diagram show the manufacturing operation as the box, and the interfaces to/from the operation as the arrows entering/leaving the box. The interface arrows provide the constraints as to how and when the operations are triggered and controlled. Conciseness. The documentation of the system must be concise. This forms allows for concise representation of system architecture. Communication. IDEF0 provides several concepts to enhance communications : 1 Adapted from ICAM Architecture, Vol. IV - Function Modeling Manual, June EDM 5-9

10 Diagrams based on simple box and arrow graphics. Textual labels to describe meaning. Gradual exposition of detail. Rigor and Precision. The rules of IDEF0 require sufficient rigor and precision to satisfy ICAM architecture needs without overly constraining the analyst. The rules include : Detail exposition control at each level (3-6 box rule). Bounded Context ( no omissions or additional out-of-scope detail). Diagram Interface Connectivity (Box numbers, node numbers, etc). Data structure Connectivity ( ICOM codes and use of parentheses). Uniqueness of labels and titles ( no multiple names). Syntax Rules for Graphics ( boxes and arrows). Data arrow Branch Constraint ( labels for constraining data flow on branches). Input vs. Control Separation ( rule for determining role of data). Data Arrow Label Requirements (minimum labeling rules). Minimum Control of Function (all functions require at least one control). Purpose and Viewpoint ( all models have a purpose and viewpoint statement). Methodology. Step-by-step procedures for modeling, review, and integration tasks. Organization vs. Function. The separation of organization from function is included in the purpose of the model, and carried out by the selection of functions and interface names during model development IDEF0 SYMBOLS An IDEF0 model is a series of diagrams with documentation that break a complex subject into its component parts. The initial diagram shows the system in its most abstract form. This is then decomposed to show various levels of detail. One particular diagram cannot have less than three nor more than six boxes. Neither sequence nor time is explicit in IDEF0 diagrams. Boxes represent functions. These are described by an active verb phrase (tighten, attach, assemble, evaluate, adapt, solve, etc.) inside the box. Each box is numbered in its lower right corner in sequential order. EDM 5-10

11 The arrows that connect a box represent objects or information needed by or produced by the function. They are labeled by a noun phrase. Data may be information, objects, or anything that can be described by a noun phrase. The arrows are constraints that define the boxes, not sequences or flows of functions. A control describes the conditions or circumstances that govern the function. The assumption is that an arrow is a control unless it obviously serves only as an input. Every function box will have at least one control arrow. The bottom of a box is reserved to indicate a mechanism, which may be the person or device which carries out the function. The inputs and outputs show WHAT is done by the function, control shows WHY it is done, and the mechanism shows HOW it is done. Diagrams drawn without mechanisms show what functions a system must perform. A downward pointing mechanism arrow (known as a call) indicates a system that completely performs the function of the box. The input, output, control, and mechanism arrows are collectively known as the ICOMs. Node numbers are used to indicate the position of any diagram or box in the hierarchy. For example node A21 is the diagram that details box 1 on the A2 diagram. The top level diagram box is numbered A0. The unconnected arrows in a diagram represent ICOMs of the parent box. The unconnected ends therefore must match the arrows on the parent box. Tunneled arrows indicate that the data conveyed by these arrows was not relevant to a particular level of detail. Tunneling an arrow where it connects to the box indicates that the data is not necessary at the next level of decomposition. Tunneling an arrow at the unconnected end indicates that the data conveyed is not relevant to the parent diagram. Some examples will help clarify these points. 5.9 DATA FLOW DIAGRAMS 2 Data Flow Diagrams (DFDs) are used to model data flow in a system. A DFD is essentially a diagram showing flow of data in a system, showing sources/destinations of data outside the system, the processes which transform data and the places where data is stored. Some of the concepts of the DFDs are : 2 Adapted from Structured Systems Analysis, Prentice Hall, C. Gane, T. Sarson. EDM 5-11

12 External Entities (EE) are sources/destinations of flows of data in and out of the system. These are represented by rectangular boxes as shown below Data Flows are represented as arrows connecting various entities and processes. The data flows can be unidirectional or bidirectional. Processes are functions that transform data in some way. The processes are represented by rounded boxes. The box contains an identifier for the process, a verb and object description of the function, and optional physical implementation details. A description of the process is usually stored in the system data dictionary. Data Stores (DS) represent one or more tables in the database. DSs can hold information about either objects that endure over time (products) or events which occur at a point in time (sale). Search arguments (indexes) can be represented by a triangle as shown below. Check to see if single-inflow, single-outflow data stores are necessary. A process can be exploded to show the detailed process. Process 5 can be exploded to processes 5.1, 5.2, etc. More details on DFDs can be found in [Gane, Sarson]. EDM 5-12

13 5.10 EXTENDED ENTITY RELATIONSHIP MODEL (EER) 3 An EER model represents relationships between data entities. EER model is called a semantic data model due to its ability to express semantics of the data it represents. The EER model is an extension to the Entity Relationship model proposed by Chen. In this section we will describe the basic constructs of an EER model. The diagrammatic representations may vary depending on the reference. To our knowledge there is no standard set of representations. The two primary constructs of the model are the entity and the relationship. An entity is something or some object you are interested in. An entity may have several attributes that further describe that entity. Several entities could be related to each other through some relationships. The entities and the relationships are diagrammatically represented as: Attributes If an attribute's value is derivable from other attributes, then that attribute is called a derived attribute. Every entity has an attribute whose values are unique for each individual entity, such an attribute is called a key attribute. Sometimes more than one attributes is needed to uniquely identify an entity, in that case the combination of these attributes is called the key. For some entities, there may be more than one attribute that can uniquely identify the entity. In this case the entity has more than one keys. An attribute that is composed of several more basic attributes is called a composite attribute, whereas an attribute that can not be divided into pieces is called a simple attribute. Most attributes have a single value for a particular entity instance; such attributes are called single valued attributes. Sometimes an attribute can take more than one value for an entity instance; such attributes are called multivalued attributes. 3 Adapted from Fundamentals of Database Systems, Benjamin/Cummings, R.Elmasri, S.B. Navathe. EDM 5-13

14 Relationships Relationships between entities play an important role in this model. The degree of a relationship is the number of entities participating in that relationship. An entity can be related to itself through an unary relationship. A relationship between two entities is called a binary relationship. A relationship between three entities is called a ternary relationship, and so on. Most of the relationships can be represented by using up to ternary relationships. These relationships can be represented as: EDM 5-14

15 Each entity participating in a relationship plays a particular role in the relationship. The role name signifies the role a participating entity plays in the relationship. Role names are not necessary in relationships where all the participating entities are distinct. However, in some cases the same entity participates in a relationship more than once in different roles. In such cases role names are essential to distinguish the meaning of each participation. Such relationships are called recursive relationships. A unary relationship is a recursive relationship. An example is a relationship MADE-OF which exists between PARTS. Here a part may play the role of an assembly or the role of an component. Relationships usually have various constraints associated with them. Two main constraints are the cardinality constraints and the participation constraints. The cardinality constraint specifies the number of relationship instances that an entity can participate in. Common cardinality constraints on a binary relationship are 1:1, 1:N, and M:N representing ONE-TO-ONE, ONE-TO-MANY, and MANY-TO-MANY respectively. A 1:1 relationship between entities A and B means that one entity instance of A can be related to only one instance of B. These are represented as shown below: From the figure each C can be related to many D's. Each E can be related to many F's while each F can be related to many E's. The participation constraint specifies whether the existence of an entity depends on its being related to another entity via the relationship. This constraint is of two types: total, and partial. Consider a relationship between a designer and his drawings. While a designer may or may not have a drawing, each drawing must have a designer, i.e., each drawing must participate in this relationship. To understand this constraint consider the figure shown below: EDM 5-15

16 Here the entity DESIGNER has a partial participation in the relationship DESIGNED_BY whereas the entity DRAWING has a total participation in the relationship. Total participation is sometimes called existence dependency. In the above figure designer and drawing represent the role names. The cardinality constraints and the participation constraints are collectively known as the structural constraints of a relationship. Sometimes these constraints are represented as a pair of integers (min., max.). This representation incorporates both the cardinality and the participation constraints at the same time. Here min represents the minimum relationship instances in which an entity must participate, and max. represents the maximum relationship instances in which an entity must participate. In this representation the above diagram would look like: A relationship can also have attributes that describe or are associated with the relationship Weak Entities An entity that does not have any key attributes of its own is called a weak entity. Such entities are identified by being related to other entity which is called an identifying owner. The relationship that relates such entities is called an identifying relationship of the weak entity. A weak entity always has a total participation in its identifying relationship. A weak entity only has a partial key that can uniquely identify the weak entity related to the owner entity. Weak entities are sometimes represented as composite, multivalued attributes. An owner entity may itself be a weak entity. In addition, a weak entity may have more than one identifying entity. A weak entity is represented as shown below: EDM 5-16

17 CATEGORY ABSTRACTIONS Introduction of these abstractions results in two additional constructs: generalization hierarchy, and subset hierarchy. A generalization hierarchy specifies strictly nonoverlapping subsets, while the subset hierarchy specifies possibly overlapping subsets. The generalization implies that the subsets are a full partition, such that the subsets are disjoint and their combination makes up the full set. The entity divided into the subsets is called the generic entity. The other entities are called the subset entities. These are represented as shown below: Generalization Hierarchy definition: An entity E is generalization of the entities E 1, E 2,..., E n if each occurrence of E is also an occurrence of one and only one of the entities E 1, E 2,..., E n. A generalization hierarchy occurs when an entity (generic) is partitioned into specific entities as determined by different values of a common attribute. A generalization is also known as a IS-A relationship. EDM 5-17

18 Subset Hierarchy definition: An entity E 1 is a subset of another entity E 2 if every occurrence of E 1 is also an occurrence of E 2. A subset hierarchy is the case in which every occurrence of the generic entity may also be an occurrence of other entities that are potentially overlapping subsets. Another abstraction useful in some situations is Aggregation. An aggregation is an abstraction that turns certain relationships between entities into an aggregate entity. It can be represented as: The aggregation is also referred to as PART-OF relationship. There are more concepts currently being developed in literature that are out of scope at this time. The examples will help clarify the concepts discussed here. NOTE: SEE APPENDIX C FOR DESCRIPTIONS OF THE IDEF1X, NIAM & EXPRESS-G METHODOLOGIES. EDM 5-18