J.S. Goonetillake & G.N. Wikramanayake {jsg, gnw}@ucsc.cmb.ac.lk  University of Colombo School of Computing Management of ...
Presentation Structure <ul><li>Version Management </li></ul><ul><li>Engineering Design Constraints  </li></ul><ul><li>Cons...
1. Version Management <ul><li>Crucial due to  evolutionary  and  iterative  nature.  </li></ul><ul><li>Version -  An inter...
Version Management Derivation V1 seat_tube = 52 cm top_tube = 56 cm tube_diameter = 31.8 mm head_angle = 71 chainstay = 25...
Version Management <ul><li>Data in object  versions should adhere to  a given set of  design constraints. </li></ul><ul><l...
2. Engineering Design Constraints Design Constraints Imposed on artifact properties Imposed on artifact functionality Impo...
Engineering Design Constraints <ul><li>Physical  Constraints </li></ul><ul><li>  Range Constraints   </li></ul><ul><li>  3...
Engineering Design Constraints <ul><li>Each constraint category can in turn be divided into  hard  and  soft   constraints...
Engineering Design Constraints <ul><li>Structural  Constraints   </li></ul><ul><li>Relationship constraints   </li></ul><u...
3. Constraint Evolution  <ul><li>Problem :  constraints may change during the design process.  </li></ul><ul><li>Reasons :...
Constraint Management Issues <ul><li>Designers as End-users   </li></ul><ul><li>Creating New Design Objects  (Versions) </...
4. Existing  Constraint Management Mechanisms <ul><li>Static Approach </li></ul><ul><li>Specifying constraints in the data...
Constraint Management in Engineering Design Applications <ul><li>(i)  Each constraint in a constraint meta class. </li></u...
5. Proposed Framework <ul><li>Embedding evolving constraints in a class definition. </li></ul><ul><li>- clearly requires a...
Proposed Framework <ul><li>Our framework - based on  Constraint Version Object  (CVO). </li></ul><ul><li>CVO contains - a ...
Proposed Framework <ul><li>CVOs govern the validity of data. </li></ul><ul><li>An automatic association between an object ...
Conceptual Framework frameCVO_1 seat_tube = {42, 44, 46, 52} cm tube_diameter =  {25.4, 26.8, 27.2, 31.8} mm head_angle >6...
Conceptual Framework frameCVO_1 seat_tube = {42, 44, 46, 52} cm tube_diameter =  {25.4, 26.8, 27.2, 31.8} mm head_angle >6...
Conceptual Framework <ul><li>CVOs are affected due to: </li></ul><ul><li>(i) modification(s) to existing constraints </li>...
Conceptual Framework <ul><li>A new CVO contains only the changes to its parent CVO constraint set, and  </li></ul><ul><li>...
Conceptual Framework <ul><li>There should be means in the child CVO to   </li></ul><ul><ul><li>delegating constraints to t...
Default CVO <ul><li>May change with time as new CVOs are produced – usually  the last CVO will  become the default CVO.   ...
CVO Creation Interface
Data Validation <ul><li>Automatic data validation is performed  </li></ul><ul><ul><li>When a new object version is derived...
Reporting Data Validation
Validating Existing Versions
Constraint Retrieval
6. Conclusion <ul><li>Our framework based on CVOs facilitates </li></ul><ul><ul><li>Easy capture of design constraints  </...
Conclusion <ul><ul><li>The maintenance of constraint evolution history which enables  </li></ul></ul><ul><ul><ul><li>The r...
The End Thank You
Upcoming SlideShare
Loading in …5
×

Management of Evolving Constraints in a Computerised Engineering Design Environment 2004

669 views
539 views

Published on

Presentation by Gihan Wikramanayake on 8 July 2004 at 23rd National Information Technology Conference of the Computer Society of Sri Lanka, Colombo, Sri Lanka.
Reference:
J S Goonethillake, G N Wikramanayake (2004) Management of Evolving Constraints in a Computerised Engineering Design Environment In: 23rd National Information Technology Conference 43-54 Computer Society of Sri Lanka Colombo, Sri Lanka: CSSL Jul 8-9, ISBN: 955-9155-12-1
Article: http://www.slideshare.net/wikramanayake/management-of-evolving-constraints-in-a-computerised-engineering-design-environment

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
669
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Management of Evolving Constraints in a Computerised Engineering Design Environment 2004

  1. 1. J.S. Goonetillake & G.N. Wikramanayake {jsg, gnw}@ucsc.cmb.ac.lk University of Colombo School of Computing Management of Evolving Constraints in a Computerised Engineering Design Environment
  2. 2. Presentation Structure <ul><li>Version Management </li></ul><ul><li>Engineering Design Constraints </li></ul><ul><li>Constraint Evolution Problem and their management issues </li></ul><ul><li>Existing constraint management mechanisms </li></ul><ul><li>Proposed framework </li></ul><ul><li>Conclusion </li></ul>
  3. 3. 1. Version Management <ul><li>Crucial due to evolutionary and iterative nature. </li></ul><ul><li>Version - An intermediate stage of the design object/artifact </li></ul><ul><li>Updates do not overwrite current data with new data. </li></ul><ul><li>Versions are stored & managed by a DBMS. </li></ul>
  4. 4. Version Management Derivation V1 seat_tube = 52 cm top_tube = 56 cm tube_diameter = 31.8 mm head_angle = 71 chainstay = 25 cm material = “aluminium” --------------------- V2 seat_tube = 42 cm top_tube = 56 cm tube_diameter = 31.8 mm head_angle = 71 chainstay = 25 cm material = “ steel ” ---------------------
  5. 5. Version Management <ul><li>Data in object versions should adhere to a given set of design constraints. </li></ul><ul><li>This is a difficult task to perform manually. </li></ul><ul><li>The designer should be assisted with an automatic data validation mechanism. </li></ul>V1 seat_tube = 52 cm top_tube = 56 cm tube_diameter = 31.8 mm head_angle = 71 chainstay = 25 cm material = “aluminium” ---------------------
  6. 6. 2. Engineering Design Constraints Design Constraints Imposed on artifact properties Imposed on artifact functionality Imposed on the design process artifact Range Enumeration Relationship Hard Soft Hard Soft Hard Soft Hard Soft Composition Relationship Structural Physical Formation features
  7. 7. Engineering Design Constraints <ul><li>Physical Constraints </li></ul><ul><li> Range Constraints </li></ul><ul><li> 35 cm  frame_size  58 cm </li></ul><ul><li> Enumeration Constraints </li></ul><ul><li> material = {steel, stainless steel, </li></ul><ul><li>titanium, aluminium} </li></ul><ul><li> Relationship constraints </li></ul><ul><li>in hub artefact the relationship between its spoke angle and spoke holes is given as </li></ul><ul><li>SpokeAngle is round(720/SpokeHoles) </li></ul>Range Enumeration Relationship Physical
  8. 8. Engineering Design Constraints <ul><li>Each constraint category can in turn be divided into hard and soft constraints. </li></ul><ul><li>Hard constraints </li></ul><ul><li>restrictive and cannot be violated </li></ul><ul><ul><li>seat tube >52 cm and <68 cm </li></ul></ul><ul><li>Soft constraints </li></ul><ul><ul><li>not restrictive and can be violated if required </li></ul></ul><ul><li>material = {aluminium, steel} </li></ul>Range Hard Soft Enumeration Hard Soft
  9. 9. Engineering Design Constraints <ul><li>Structural Constraints </li></ul><ul><li>Relationship constraints </li></ul><ul><li>the formation features of the bicycle artefact with respect to frame and the wheel </li></ul><ul><li>wheel diameter > 60 cm  frame size > 40 cm </li></ul>Composition Relationship Structural Formation features
  10. 10. 3. Constraint Evolution <ul><li>Problem : constraints may change during the design process. </li></ul><ul><li>Reasons : </li></ul><ul><ul><li>changes in customer requirements/market demand </li></ul></ul><ul><ul><li>changes in the technology </li></ul></ul><ul><ul><li>improvements to the performance of the product </li></ul></ul><ul><ul><li>inclusion of unnecessary constraints or omission of important constraints </li></ul></ul>
  11. 11. Constraint Management Issues <ul><li>Designers as End-users </li></ul><ul><li>Creating New Design Objects (Versions) </li></ul><ul><li>Constraint Reusability </li></ul><ul><li>Constraint Evolution History </li></ul><ul><li>Existing Object Validation </li></ul>
  12. 12. 4. Existing Constraint Management Mechanisms <ul><li>Static Approach </li></ul><ul><li>Specifying constraints in the database schema e.g. relational DBs, deductive DBs </li></ul><ul><li>Object-Oriented Approach </li></ul><ul><li>Constraints are coded in corresponding methods of the classes due to encapsulation </li></ul><ul><li>Active Rules </li></ul><ul><li>Constraints represented as active rules </li></ul>
  13. 13. Constraint Management in Engineering Design Applications <ul><li>(i) Each constraint in a constraint meta class. </li></ul><ul><li>(ii) Constraints as database instances. </li></ul><ul><li>Drawbacks </li></ul><ul><li>requires manual association of applicable constraints with the corresponding design objects. </li></ul><ul><li>integrity validation is a difficult process. </li></ul><ul><li>(i) is extremely software oriented. </li></ul>
  14. 14. 5. Proposed Framework <ul><li>Embedding evolving constraints in a class definition. </li></ul><ul><li>- clearly requires a redefinition of that class, whenever a change occurs </li></ul><ul><li>Flexibility to incorporate constraint evolution . </li></ul><ul><li>- treat constraints separately from the class definition . </li></ul>
  15. 15. Proposed Framework <ul><li>Our framework - based on Constraint Version Object (CVO). </li></ul><ul><li>CVO contains - a set of integrity constraints (as rules). </li></ul><ul><li>A CVO may contain any combination of active constraints, of any category. </li></ul>
  16. 16. Proposed Framework <ul><li>CVOs govern the validity of data. </li></ul><ul><li>An automatic association between an object version and the corresponding CVO. </li></ul><ul><li>A naming scheme for CVOs. </li></ul><ul><li>e.g. <objectnameCVO_number> </li></ul>
  17. 17. Conceptual Framework frameCVO_1 seat_tube = {42, 44, 46, 52} cm tube_diameter = {25.4, 26.8, 27.2, 31.8} mm head_angle >65 and < 72 chainstay = {25, 26} cm material = {aluminium, steel} frameCVO_2 seat_tube >52 cm and <68 cm top_tube – ( if seat_tube < 60 then top_tube = seat_tube + 4) or ( if seat_tube between 60 and 68 then top_tube = seat_tube - 3) chainstay = {40, 41, 42, 45} cm tube_diameter - if (material = “aluminium” then tube_diameter > 27.4 and <32) or if (material = “steel” then tube diameter > 24 and <27.4) inheritance v 1 :ArtifactVersion v2:ArtifactVersion v3:ArtifactVersion artifactCVO_1 artifactCVO_2 derivation validation frameVersion1: VersionableFrame seat_tube = 52 cm top_tube = 56 cm tube_diameter = 31.8 mm head_angle = 71 chainstay = 25 cm material = “aluminium” --------------------- FrameVersion2: VersionableFrame seat_tube = 52 cm top_tube = 56 cm tube_diameter = 24.5 mm head_angle = 71 chainstay = 42 cm material = “ steel ” ---------------------
  18. 18. Conceptual Framework frameCVO_1 seat_tube = {42, 44, 46, 52} cm tube_diameter = {25.4, 26.8, 27.2, 31.8} mm head_angle >65 and < 72 chainstay = {25, 26} cm material = {aluminium, steel} frameCVO_2 seat_tube >52 cm and <68 cm top_tube – ( if seat_tube < 60 then top_tube = seat_tube + 4) or ( if seat_tube between 60 and 68 then top_tube = seat_tube - 3) chainstay = {40, 41, 42, 45} cm tube_diameter - if (material = “aluminium” then tube_diameter > 27.4 and <32) or if (material = “steel” then tube diameter > 24 and <27.4) frameVersion1: VersionableFrame seat_tube = 52 cm top_tube = 56 cm tube_diameter = 31.8 mm head_angle = 71 chainstay = 25 cm material = “aluminium” --------------------- FrameVersion2: VersionableFrame seat_tube = 52 cm top_tube = 56 cm tube_diameter = 24.5 mm head_angle = 71 chainstay = 42 cm material = “ steel ” --------------------- FrameVersion3: VersionableFrame seat_tube = 61 cm top_tube = 58 cm tube_diameter = 24.5 mm head_angle = 71 chainstay = 42 cm material = “steel” ---------------------
  19. 19. Conceptual Framework <ul><li>CVOs are affected due to: </li></ul><ul><li>(i) modification(s) to existing constraints </li></ul><ul><li>(ii) introduction of new constraints </li></ul><ul><li>(iii) omission of previously used constraints </li></ul><ul><li>(iv) Any combination of (i) - (iii) </li></ul>
  20. 20. Conceptual Framework <ul><li>A new CVO contains only the changes to its parent CVO constraint set, and </li></ul><ul><li>The means of referring to its parent for the unchanged constraints. </li></ul>frameCVO_1 seat_tube = {42, 44, 46, 52} cm tube_diameter = {25.4, 26.8, 27.2, 31.8} mm head_angle >65 and < 72 chainstay = {25, 26} cm material = {aluminium, steel} frameCVO_2 seat_tube >52 cm and <68 cm top_tube – ( if seat_tube < 60 then top_tube = seat_tube + 4) or ( if seat_tube between 60 and 68 then top_tube = seat_tube - 3) chainstay = {40, 41, 42, 45} cm tube_diameter - if (material = “aluminium” then tube_diameter > 27.4 and <32) or if (material = “steel” then tube diameter > 24 and <27.4) frameCVO_1 seat_tube = {42, 44, 46, 52} cm tube_diameter = {25.4, 26.8, 27.2, 31.8} mm head_angle >65 and < 72 chainstay = {25, 26} cm material = {aluminium, steel}
  21. 21. Conceptual Framework <ul><li>There should be means in the child CVO to </li></ul><ul><ul><li>delegating constraints to the parent </li></ul></ul><ul><ul><li>overriding constraints in the parent </li></ul></ul><ul><ul><li>omitting constraints defined in the parent </li></ul></ul><ul><li>Inheritance with overriding and differential mechanisms - to provide those features in CVOs. </li></ul><ul><li>Facilitates the maintenance of constraint evolution history. </li></ul>
  22. 22. Default CVO <ul><li>May change with time as new CVOs are produced – usually the last CVO will become the default CVO. </li></ul><ul><li>Decided by the project leader - if necessary to move back to a previous stage of constraint evolution. </li></ul><ul><li>Default design object version & default CVO. </li></ul>
  23. 23. CVO Creation Interface
  24. 24. Data Validation <ul><li>Automatic data validation is performed </li></ul><ul><ul><li>When a new object version is derived – on explicit user request </li></ul></ul><ul><ul><li>When a new CVO is produced – validation of existing versions </li></ul></ul>
  25. 25. Reporting Data Validation
  26. 26. Validating Existing Versions
  27. 27. Constraint Retrieval
  28. 28. 6. Conclusion <ul><li>Our framework based on CVOs facilitates </li></ul><ul><ul><li>Easy capture of design constraints </li></ul></ul><ul><ul><ul><li>Considering that the designer is a non-programmer Providing the re-use of unchanged constraints </li></ul></ul></ul><ul><ul><li>Automatic Integrity Validation when </li></ul></ul><ul><ul><li>Deriving a new version and </li></ul></ul><ul><ul><li>Producing a new CVO (validating existing versions) </li></ul></ul>
  29. 29. Conclusion <ul><ul><li>The maintenance of constraint evolution history which enables </li></ul></ul><ul><ul><ul><li>The retrieval of the set of constraints applicable to a particular version. </li></ul></ul></ul><ul><ul><ul><li>Moving back to Previous Stage of Constraint Evolution </li></ul></ul></ul>
  30. 30. The End Thank You

×