regi.tankonyvtar.hu€¦ · Web viewComponent-Based Software Development. Szendrei, Rudolf. Component-Based Software Development. írta Szendrei, Rudolf. Publication date 2015

Component-Based Software Development

Szendrei, Rudolf

Created by XMLmind XSL-FO Converter.

Component-Based Software Developmentírta Szendrei, Rudolf

Publication date 2015Szerzői jog © 2015 Szendrei Rudolf


TartalomComponent-Based Software Development .......................................................................................... 1

1. 1 Introduction ......................................................................................................................... 11.1. Introduction ................................................................................................................ 11.2. Introduction ................................................................................................................ 11.3. Introduction ................................................................................................................ 11.4. Introduction ................................................................................................................ 11.5. 1.1 Software development ......................................................................................... 2

1.5.1. Software development ................................................................................... 21.5.2. Software development ................................................................................... 21.5.3. Software development ................................................................................... 21.5.4. 1.1.1 Component-based Software Development ........................................... 31.5.5. Component-based Software Development .................................................... 31.5.6. Component-based Software development ..................................................... 31.5.7. 1.1.2 Concepts of component ........................................................................ 31.5.8. Concepts of component ................................................................................. 31.5.9. Composition .................................................................................................. 41.5.10. Composition - UML diagram ...................................................................... 41.5.11. Interface ....................................................................................................... 41.5.12. Client-Server connection ............................................................................. 41.5.13. UML representation of the required and provided interfaces of the component .................................................................................................................................. 5

2. 2 UML, IDL ............................................................................................................................ 52.1. 2.1 UML ..................................................................................................................... 52.2. 2.2 Modeling in UML ................................................................................................ 52.3. 2.3 Structural diagrams .............................................................................................. 5

2.3.1. Structural diagrams ....................................................................................... 52.3.2. 2.3.1 Package diagram .................................................................................. 62.3.3. Package diagram ........................................................................................... 62.3.4. 2.3.2 Class diagram ....................................................................................... 62.3.5. Class diagram ................................................................................................ 62.3.6. Class diagram ................................................................................................ 72.3.7. 2.3.3 Object diagram ..................................................................................... 72.3.8. Object diagram .............................................................................................. 72.3.9. 2.3.4 Composite structural diagram .............................................................. 72.3.10. Composite structural diagram ..................................................................... 72.3.11. Composite structural diagram ..................................................................... 82.3.12. Composite structural diagram ..................................................................... 82.3.13. Composite structural diagram ..................................................................... 82.3.14. Composite structural diagram ..................................................................... 92.3.15. Composite structural diagram ..................................................................... 92.3.16. Composite structural diagram ..................................................................... 92.3.17. Composite structural diagram ..................................................................... 92.3.18. Composite structural diagram ................................................................... 102.3.19. 2.3.5 Component diagram ......................................................................... 102.3.20. Component diagram .................................................................................. 102.3.21. Component diagram .................................................................................. 102.3.22. Component diagram .................................................................................. 10



2.3.23. 2.3.6 Deployment diagram ........................................................................ 112.3.24. Deployment diagram ................................................................................. 112.3.25. 2.3.7 Artifact, Installation association ....................................................... 112.3.26. Artifact, Installation association ................................................................ 11

2.4. 2.4 Behavioral diagrams .......................................................................................... 112.4.1. Behavioral diagram ..................................................................................... 112.4.2. 2.4.1 Use case diagram ............................................................................... 122.4.3. Use case diagram ........................................................................................ 122.4.4. 2.4.2 Activity diagram ................................................................................. 122.4.5. Activity diagram .......................................................................................... 122.4.6. Activity diagram - example ......................................................................... 132.4.7. 2.4.3 State-machine diagram ....................................................................... 132.4.8. State-machine diagram ................................................................................ 132.4.9. State-machine diagram ................................................................................ 132.4.10. 2.4.4 Communication diagram .................................................................. 142.4.11. Communication diagram ........................................................................... 142.4.12. 2.4.5 Sequence diagram ............................................................................ 142.4.13. Sequence diagram ..................................................................................... 142.4.14. 2.4.6 Timing diagram ................................................................................ 152.4.15. Timing diagram ......................................................................................... 152.4.16. 2.4.7 Interaction overview diagram .......................................................... 152.4.17. Interaction overview diagram ................................................................... 15

2.5. 2.5 IDL ..................................................................................................................... 152.5.1. Interface Definition Language .................................................................... 152.5.2. Interface Definition Language .................................................................... 162.5.3. Interface Definition Language .................................................................... 162.5.4. Interface Definition Language .................................................................... 172.5.5. Interface Definition Language .................................................................... 172.5.6. Interface Definition Language .................................................................... 172.5.7. Interface Definition Language - Example ................................................... 17

3. 3 Software architectures ....................................................................................................... 183.1. Software architecture ............................................................................................... 183.2. Software architecture ............................................................................................... 183.3. Software architecture - Analysis of the definition ................................................... 183.4. Software architecture - Analysis of the definition ................................................... 183.5. Software architecture ............................................................................................... 193.6. Relations of architecture schemas, reference models, reference architectures and software architectures .................................................................................................................... 193.7. 3.0.1 Architecture schema ....................................................................................... 193.8. Software architecture ............................................................................................... 193.9. 3.0.2 Reference models ........................................................................................... 193.10. Software architecture ............................................................................................. 193.11. 3.0.3 Reference architecture .................................................................................. 193.12. Software architecture ............................................................................................. 203.13. 3.0.4 Software architecture .................................................................................... 203.14. Software architecture ............................................................................................. 203.15. 3.0.5 Common software architecture structures .................................................... 203.16. Common software architecture structures ............................................................. 203.17. 3.0.6 Model based structure ................................................................................... 203.18. The model based structure ..................................................................................... 203.19. The model based structure ..................................................................................... 213.20. 3.0.7 Component-and-connector structure ............................................................ 21



3.21. Component-and-connector structure ..................................................................... 213.22. Component-and-connector structure ..................................................................... 213.23. Component-and-connector structure ..................................................................... 223.24. 3.0.8 Allocation structure ....................................................................................... 223.25. Allocation structure ................................................................................................ 223.26. Allocation structure ................................................................................................ 223.27. Software architecture ............................................................................................. 223.28. 3.1 Component models .......................................................................................... 22

3.28.1. Component models ................................................................................... 223.28.2. 3.1.1 Middleware ...................................................................................... 233.28.3. Component models ................................................................................... 233.28.4. Component models ................................................................................... 233.28.5. Component models ................................................................................... 233.28.6. Component models ................................................................................... 23

3.29. 3.2 CORBA ........................................................................................................... 243.29.1. CORBA ..................................................................................................... 243.29.2. 3.2.1 Object Request Broker ..................................................................... 243.29.3. CORBA ..................................................................................................... 243.29.4. CORBA - ORB .......................................................................................... 243.29.5. CORBA - ORB .......................................................................................... 253.29.6. CORBA - ORB .......................................................................................... 253.29.7. 3.2.2 Object Adapter ................................................................................. 253.29.8. CORBA ..................................................................................................... 253.29.9. 3.2.3 Implementation Repository, ORB interface ..................................... 253.29.10. CORBA ................................................................................................... 263.29.11. 3.2.4 IDL ................................................................................................. 263.29.12. CORBA - IDL ......................................................................................... 263.29.13. CORBA - IDL ......................................................................................... 263.29.14. CORBA - IDL ......................................................................................... 263.29.15. Generated code execution within the CORBA infrastructure ................. 27

3.30. 3.3 COM/DCOM ................................................................................................... 273.30.1. COM/DOM ............................................................................................... 27

4. 4 JavaBeans .......................................................................................................................... 284.1. 4.1 Introduction ....................................................................................................... 28

4.1.1. Introduction ................................................................................................. 284.2. 4.2 JavaBeans .......................................................................................................... 28

4.2.1. JavaBeans .................................................................................................... 284.2.2. JavaBeans .................................................................................................... 284.2.3. 4.2.1 Enterprise Java Bean .......................................................................... 294.2.4. JavaBeans - EJB .......................................................................................... 294.2.5. 4.2.2 J2EE overview ................................................................................... 294.2.6. Java2EE ....................................................................................................... 294.2.7. Quality requirements of web-application .................................................... 294.2.8. ..................................................................................................................... 304.2.9. 4.2.3 J2EE - EJB overview ......................................................................... 304.2.10. J2EE - EJB ................................................................................................ 304.2.11. J2EE - Tasks of EJB .................................................................................. 304.2.12. Properties of J2EE ..................................................................................... 304.2.13. 4.2.4 J2EE - architecture ........................................................................... 314.2.14. Architecture of J2EE ................................................................................. 314.2.15. J2EE - Client layer .................................................................................... 31



4.2.16. J2EE - Web layer ....................................................................................... 314.2.17. J2EE - Business component layer ............................................................. 324.2.18. J2EE - Enterprise information systems tier ............................................... 324.2.19. 4.2.5 J2EE - EJB architecture ................................................................... 324.2.20. J2EE - EJB architecture ............................................................................ 324.2.21. J2EE - EJB architecture ............................................................................ 324.2.22. J2EE - EJB container ................................................................................ 334.2.23. J2EE - Component model ......................................................................... 334.2.24. J2EE - EJB Component types ................................................................... 334.2.25. 4.2.6 J2EE - EJB component types ........................................................... 344.2.26. J2EE - EJB Component types ................................................................... 344.2.27. J2EE - EJB Component types - Entity beans ............................................ 344.2.28. J2EE - EJB Component types - Entity beans ............................................ 344.2.29. J2EE - Example for J2EE/EJB-compliant implementation ...................... 344.2.30. 4.2.7 J2EE - EJB programming ................................................................ 354.2.31. J2EE - EJB programming ......................................................................... 354.2.32. J2EE - Creating a server side bean ............................................................ 354.2.33. J2EE - EJB program units ......................................................................... 354.2.34. J2EE Example - The realizer class ............................................................ 364.2.35. 4.2.8 Deployment descriptors ................................................................... 384.2.36. J2EE - Deployment descriptors ................................................................. 384.2.37. 4.2.9 Summary .......................................................................................... 394.2.38. Summary ................................................................................................... 39

5. 5 KobrA program-development model ................................................................................ 395.1. KobrA ...................................................................................................................... 395.2. KobrA ...................................................................................................................... 405.3. KobrA ...................................................................................................................... 405.4. 5.0.1 Development process ...................................................................................... 405.5. KobrA ...................................................................................................................... 405.6. KobrA ...................................................................................................................... 415.7. KobrA ...................................................................................................................... 415.8. KobrA ...................................................................................................................... 415.9. 5.0.2 Decomposition ................................................................................................ 425.10. KobrA .................................................................................................................... 425.11. KobrA .................................................................................................................... 425.12. KobrA - Vending-machine problem decomposition .............................................. 425.13. KobrA .................................................................................................................... 425.14. 5.0.3 Embodiment .................................................................................................. 435.15. KobrA .................................................................................................................... 435.16. KobrA .................................................................................................................... 435.17. 5.0.4 Composition .................................................................................................. 435.18. KobrA .................................................................................................................... 435.19. 5.0.5 Validation ...................................................................................................... 435.20. KobrA .................................................................................................................... 435.21. 5.0.6 Spiral model .................................................................................................. 445.22. KobrA .................................................................................................................... 445.23. 5.0.7 Waterfall model ............................................................................................. 445.24. KobrA .................................................................................................................... 445.25. 5.0.8 Example ........................................................................................................ 445.26. KobrA - Vending machine UML diagram ............................................................. 445.27. KobrA .................................................................................................................... 45



5.28. 5.1 Environmental map .......................................................................................... 455.28.1. ................................................................................................................... 455.28.2. KobrA - Environmental map ..................................................................... 455.28.3. KobrA - Environmental map - Example ................................................... 455.28.4. KobrA - Environmental map ..................................................................... 465.28.5. KobrA - Environmental map ..................................................................... 465.28.6. KobrA - Environmental map elements ...................................................... 465.28.7. KobrA - Environmental map ..................................................................... 475.28.8. 5.1.1 Usage model ..................................................................................... 475.28.9. KobrA - Environmental map ..................................................................... 475.28.10. KobrA - Usage model - Vending machine's use case diagram ................ 475.28.11. KobrA - Environmental map ................................................................... 485.28.12. KobrA - Environmental map - Use case template ................................... 485.28.13. KobrA - Vending machine - Purchase item use case ............................... 485.28.14. 5.1.2 Business and enterprise processes model ....................................... 495.28.15. KobrA - Environmental map ................................................................... 495.28.16. KobrA - Environmental map ................................................................... 495.28.17. 5.1.3 Structural model ............................................................................. 505.28.18. KobrA - Environmental map ................................................................... 505.28.19. KobrA - Structural model of a variant inside the environmental map .... 505.28.20. KobrA - Environmental map ................................................................... 505.28.21. 5.1.4 Activity and interaction model ....................................................... 515.28.22. KobrA - Environmental map ................................................................... 515.28.23. KobrA - Activity diagram - Vending machine - Purchase Item .............. 515.28.24. KobrA - Environmental map ................................................................... 515.28.25. 5.1.5 Summary ........................................................................................ 525.28.26. KobrA - Environmental map ................................................................... 525.28.27. KobrA - Activities of a customer of the Vending machine ..................... 525.28.28. KobrA - Environmental map ................................................................... 525.28.29. KobrA - Component meta-model diagram .............................................. 525.28.30. KobrA - Environmental map ................................................................... 53

6. 6 KobrA - Component specification and implementation .................................................... 536.1. 6.1 Component specification ................................................................................... 53

6.1.1. 6.1.1 Component specification .................................................................... 536.1.2. Component specification ............................................................................. 536.1.3. Component specification ............................................................................. 536.1.4. Component specification ............................................................................. 546.1.5. 6.1.2 Structural specification ...................................................................... 546.1.6. Component specification ............................................................................. 556.1.7. Component specification ............................................................................. 556.1.8. Component specification ............................................................................. 566.1.9. 6.1.3 Operation specification ...................................................................... 566.1.10. Component specification ........................................................................... 566.1.11. Operation specification template according to the KobrA method and Fusion ................................................................................................................................ 566.1.12. Operation specification of the Vending machine ...................................... 576.1.13. 6.1.4 Behavioral specification ................................................................... 576.1.14. Component specification ........................................................................... 576.1.15. Component specification ........................................................................... 586.1.16. Component specification ........................................................................... 586.1.17. Behavioral specification of the Vending machine in the form of a state transition table ....................................................................................................................... 59



6.2. 6.2 Component realization ....................................................................................... 596.2.1. 6.2.1 Component realization ....................................................................... 596.2.2. Component realization ................................................................................ 596.2.3. Component realization ................................................................................ 606.2.4. 6.2.2 Structural specification ...................................................................... 606.2.5. Component realization ................................................................................ 606.2.6. Component realization ................................................................................ 616.2.7. Component realization ................................................................................ 616.2.8. Component realization ................................................................................ 626.2.9. 6.2.3 Realization algorithms ....................................................................... 626.2.10. Component realization .............................................................................. 626.2.11. 6.2.4 Structural specification ..................................................................... 636.2.12. Component realization .............................................................................. 636.2.13. Component realization .............................................................................. 636.2.14. 6.2.5 Specification of realization interaction ............................................ 646.2.15. Component realization .............................................................................. 64

6.3. 6.3 Summary ............................................................................................................ 646.3.1. Summary ..................................................................................................... 64

7. 7 KobrA - Component embodiment, Normal Object Form ................................................. 657.1. 7.1 Component embodiment .................................................................................... 65

7.1.1. Component embodiment ............................................................................. 657.1.2. Component embodiment ............................................................................. 657.1.3. Component embodiment ............................................................................. 667.1.4. Refinement and translation (Manual Translation) in a single step .............. 667.1.5. Component embodiment ............................................................................. 667.1.6. Component embodiment ............................................................................. 677.1.7. Component embodiment - SORT technique ............................................... 677.1.8. Component embodiment - SORT technique ............................................... 677.1.9. Refinement and translation in two separated steps ..................................... 677.1.10. Component embodiment ........................................................................... 68

7.2. 7.2 Normal Object Form .......................................................................................... 687.2.1. Normal Object Form ................................................................................... 687.2.2. Normal Object Form ................................................................................... 687.2.3. Normal Object Formt .................................................................................. 697.2.4. SORT ........................................................................................................... 697.2.5. SORT ........................................................................................................... 697.2.6. Component embodiment ............................................................................. 697.2.7. Component embodiment - Component reusage .......................................... 707.2.8. Component embodiment ............................................................................. 707.2.9. Component embodiment ............................................................................. 707.2.10. Component embodiment ........................................................................... 707.2.11. Containment hierarchy for the CashUnit .................................................. 717.2.12. Component Of The Shelf .......................................................................... 717.2.13. Custom-designed vs. third-party component integration .......................... 717.2.14. Component Of The Shelf .......................................................................... 717.2.15. Component Of The Shelf .......................................................................... 72

8. 8 System development from "Off the shelf" components .................................................... 728.1. 8.1 Components of the Shelf ................................................................................... 72

8.1.1. Components of the Shelf ............................................................................. 728.1.2. Components of the Shelf ............................................................................. 728.1.3. Components of the Shelf ............................................................................. 73



8.1.4. Components of the Shelf ............................................................................. 738.1.5. 8.1.1 Example ............................................................................................. 738.1.6. Components of the Shelf ............................................................................. 738.1.7. Components of the Shelf ............................................................................. 738.1.8. Components of the Shelf ............................................................................. 738.1.9. Components of the Shelf ............................................................................. 748.1.10. 8.1.2 Effects of the components ................................................................ 748.1.11. Components of the Shelf ........................................................................... 748.1.12. Components of the Shelf ........................................................................... 748.1.13. Components of the Shelf ........................................................................... 748.1.14. Components of the Shelf ........................................................................... 748.1.15. 8.1.3 Architectural differences .................................................................. 748.1.16. Components of the Shelf ........................................................................... 758.1.17. Components of the Shelf ........................................................................... 758.1.18. Components of the Shelf ........................................................................... 758.1.19. Components of the Shelf - Architectural difference ................................. 758.1.20. Components of the Shelf ........................................................................... 758.1.21. Components of the Shelf ........................................................................... 768.1.22. Components of the Shelf ........................................................................... 768.1.23. Components of the Shelf - Architectural difference ................................. 768.1.24. Components of the Shelf ........................................................................... 768.1.25. 8.1.4 Designing as browsing components ................................................. 778.1.26. Components of the Shelf ........................................................................... 778.1.27. Components of the Shelf ........................................................................... 778.1.28. Components of the Shelf ........................................................................... 778.1.29. 8.1.5 Session of Model problem in 6 steps ............................................... 778.1.30. Components of the Shelf ........................................................................... 778.1.31. Components of the Shelf - The session of the model problem ................. 788.1.32. 8.1.6 Example - ASEILM ......................................................................... 788.1.33. Components of the Shelf ........................................................................... 788.1.34. Components of the Shelf ........................................................................... 788.1.35. ASEILM - Quality Attribute Requirements .............................................. 798.1.36. 8.1.7 ASEILM - Miva Empressa ............................................................... 798.1.37. Components of the Shelf ........................................................................... 798.1.38. Components of the Shelf - Miva Empressa ensemble .............................. 808.1.39. 8.1.8 Miva Empressa - System Model ...................................................... 808.1.40. Components of the Shelf ........................................................................... 808.1.41. Components of the Shelf ........................................................................... 808.1.42. Components of the Shelf ........................................................................... 808.1.43. Components of the Shelf - Introduction of Proxy server .......................... 818.1.44. Components of the Shelf ........................................................................... 818.1.45. Components of the Shelf ........................................................................... 818.1.46. Components of the Shelf ........................................................................... 818.1.47. Components of the Shelf - JavaServer Pages ensemble ........................... 828.1.48. Components of the Shelf ........................................................................... 828.1.49. Components of the Shelf - Layers of custom component ......................... 82

8.2. 8.2 Summary ............................................................................................................ 828.2.1. Summary ..................................................................................................... 82

9. 9 SYNTHESIS Tool ............................................................................................................. 839.1. 9.1 SYNTHESIS Tool ............................................................................................. 83

9.1.1. SYNTHESIS A Tool to assembly automatically a correct, distributed component-based system ......................................................................................................... 83



9.1.2. SYNTHESIS ............................................................................................... 839.1.3. 9.1.1 COM/DCOM ..................................................................................... 839.1.4. SYNTHESIS ............................................................................................... 839.1.5. SYNTHESIS ............................................................................................... 849.1.6. SYNTHESIS ............................................................................................... 849.1.7. SYNTHESIS ............................................................................................... 849.1.8. SYNTHESIS ............................................................................................... 859.1.9. 9.1.2 Applied architecture ........................................................................... 859.1.10. SYNTHESIS ............................................................................................. 859.1.11. SYNTHESIS ............................................................................................. 859.1.12. SYNTHESIS ............................................................................................. 869.1.13. 9.1.3 Formalization of configuration ........................................................ 869.1.14. Formalization of the configuration ........................................................... 869.1.15. Formalization of the configuration ........................................................... 869.1.16. Formalization of the configuration ........................................................... 879.1.17. Formalization of the configuration ........................................................... 879.1.18. Formalization of the configuration ........................................................... 879.1.19. Formalization of the configuration ........................................................... 879.1.20. Formalization of the configuration ........................................................... 889.1.21. Formalization of the configuration ........................................................... 889.1.22. Formalization of the configuration ........................................................... 889.1.23. Formalization of the configuration ........................................................... 899.1.24. Formalization of the configuration ........................................................... 899.1.25. Formalization of the configuration ........................................................... 899.1.26. 9.1.4 SYNTHESIS method ....................................................................... 909.1.27. SYNTHESIS method ................................................................................ 909.1.28. SYNTHESIS method ................................................................................ 909.1.29. SYNTHESIS method ................................................................................ 909.1.30. 9.1.5 SYNTHESIS's architecture .............................................................. 919.1.31. SYNTHESIS - Architecture ...................................................................... 919.1.32. SYNTHESIS - Architecture ...................................................................... 91

9.2. 9.2 1st Phase ............................................................................................................ 919.2.1. SYNTHESIS - Architecture ........................................................................ 919.2.2. SYNTHESIS - Architecture ........................................................................ 919.2.3. 9.2.1 Architecture - Module A .................................................................... 929.2.4. SYNTHESIS - Architecture ........................................................................ 929.2.5. 9.2.2 Architecture - Module B .................................................................... 929.2.6. SYNTHESIS - Architecture ........................................................................ 929.2.7. SYNTHESIS - Architecture ........................................................................ 929.2.8. SYNTHESIS - Architecture ........................................................................ 939.2.9. SYNTHESIS - Architecture ........................................................................ 939.2.10. SYNTHESIS - Architecture ...................................................................... 939.2.11. 9.2.3 Architecture - Module C ................................................................... 949.2.12. SYNTHESIS - Architecture ...................................................................... 949.2.13. SYNTHESIS - Architecture ...................................................................... 949.2.14. SYNTHESIS - Architecture ...................................................................... 949.2.15. SYNTHESIS - Architecture ...................................................................... 959.2.16. SYNTHESIS - Architecture ...................................................................... 959.2.17. SYNTHESIS - Architecture ...................................................................... 959.2.18. 9.2.4 Architecture - Module D .................................................................. 969.2.19. SYNTHESIS - Architecture ...................................................................... 96



10. 10 Object lifecycle, Temporal logic ................................................................................... 9610.1. 10.1 Object's lifycycle ........................................................................................... 96

10.1.1. 10.1.1 Introduction .................................................................................... 9610.1.2. Object's lifecycle ....................................................................................... 9610.1.3. Object's lifecycle ....................................................................................... 9710.1.4. Object's lifecycle ....................................................................................... 9710.1.5. 10.1.2 Technology characteristics ............................................................. 9710.1.6. Object's lifecycle ....................................................................................... 9710.1.7. 10.1.3 Proposition Temporal Logic (PTL) ................................................ 9810.1.8. Object's lifecycle ....................................................................................... 9810.1.9. Object's lifecycle ....................................................................................... 9810.1.10. Object's lifecycle ..................................................................................... 9810.1.11. Object's lifecycle ..................................................................................... 9910.1.12. Object's lifecycle ..................................................................................... 9910.1.13. Object's lifecycle ..................................................................................... 9910.1.14. 10.1.4 Model ......................................................................................... 10010.1.15. Object's lifecycle ................................................................................... 10010.1.16. Object's lifecycle ................................................................................... 10010.1.17. Object's lifecycle ................................................................................... 10010.1.18. Object's lifecycle ................................................................................... 10010.1.19. Object's lifecycle ................................................................................... 10110.1.20. Figure 2. The AIRPLANE role specification ........................................ 10110.1.21. Object's lifecycle ................................................................................... 10210.1.22. Object's lifecycle ................................................................................... 10210.1.23. Object's lifecycle ................................................................................... 10310.1.24. Object's lifecycle ................................................................................... 10310.1.25. Object's lifecycle ................................................................................... 10310.1.26. Object's lifecycle ................................................................................... 10410.1.27. Figure 4. Lifecycle context of Airplane ................................................ 10410.1.28. Figure 4. Lifecycle context of Airplane - continued ............................. 10410.1.29. Figure 5. Constraints relative to the context PLANE_LIFE ................. 10510.1.30. Object's lifecycle ................................................................................... 10510.1.31. 10.1.5 Examples .................................................................................... 10510.1.32. Object's lifecycle ................................................................................... 10510.1.33. Object's lifecycle ................................................................................... 10610.1.34. Object's lifecycle ................................................................................... 10610.1.35. Object's lifecycle ................................................................................... 10610.1.36. Object's lifecycle ................................................................................... 10710.1.37. Figure 7. Example of a constraint relating a message and the playing of a role. ............................................................................................................................. 10710.1.38. Figure 8. Example of a constraint relating two messages of distinct role. 10710.1.39. 10.1.6 Satisfiability algorithm .............................................................. 10810.1.40. Object's lifecycle ................................................................................... 10810.1.41. Object's lifecycle ................................................................................... 10810.1.42. Object's lifecycle ................................................................................... 10810.1.43. Object's lifecycle ................................................................................... 10910.1.44. Object's lifecycle ................................................................................... 10910.1.45. Object's lifecycle ................................................................................... 10910.1.46. 10.1.7 Literature .................................................................................... 10910.1.47. Object's lifecycle ................................................................................... 109

11. 11 Verification, validation ................................................................................................ 11011.1. 11.1 verification and validation ........................................................................... 110



11.1.1. 11.1.1 Notions ......................................................................................... 11011.1.2. Verification and validation of component-based systems ....................... 11011.1.3. Verification and validation of component-based systems ....................... 11011.1.4. 11.1.2 Historical overview ...................................................................... 11011.1.5. Verification and validation of component-based systems ....................... 11011.1.6. Verification and validation of component-based systems ....................... 11111.1.7. Verification and validation of component-based systems ....................... 11111.1.8. 11.1.3 Correctness proof methods ........................................................... 11111.1.9. Verification and validation of component-based systems ....................... 11111.1.10. 11.1.4 Testing ........................................................................................ 11211.1.11. Verification and validation of component-based systems ..................... 11211.1.12. Verification and validation of component-based systems ..................... 11211.1.13. Verification and validation of component-based systems ..................... 11211.1.14. Verification and validation of component-based systems ..................... 11311.1.15. 11.1.5 Test environment ........................................................................ 11311.1.16. Verification and validation of component-based systems ..................... 11311.1.17. Verification and validation of component-based systems ..................... 11311.1.18. 11.1.6 Model based testing ................................................................... 11411.1.19. Verification and validation of component-based systems ..................... 11411.1.20. Verification and validation of component-based systems ..................... 11411.1.21. Verification and validation of component-based systems ..................... 11511.1.22. Verification and validation of component-based systems ..................... 11511.1.23. Verification and validation of component-based systems ..................... 11511.1.24. 11.1.7 Testing techniques ...................................................................... 11511.1.25. Verification and validation of component-based systems ..................... 11511.1.26. Verification and validation of component-based systems ..................... 11611.1.27. Verification and validation of component-based systems ..................... 11611.1.28. Verification and validation of component-based systems ..................... 11611.1.29. 11.1.8 Model based testing ................................................................... 11711.1.30. Verification and validation of component-based systems ..................... 11711.1.31. Verification and validation of component-based systems ..................... 11711.1.32. Verification and validation of component-based systems ..................... 11711.1.33. Verification and validation of component-based systems ..................... 11811.1.34. Verification and validation of component-based systems ..................... 11811.1.35. Verification and validation of component-based systems ..................... 11811.1.36. Verification and validation of component-based systems ..................... 11911.1.37. Verification and validation of component-based systems ..................... 11911.1.38. Verification and validation of component-based systems ..................... 11911.1.39. Verification and validation of component-based systems ..................... 11911.1.40. Verification and validation of component-based systems ..................... 12011.1.41. Verification and validation of component-based systems ..................... 12011.1.42. Verification and validation of component-based systems ..................... 12011.1.43. Verification and validation of component-based systems ..................... 12011.1.44. Verification and validation of component-based systems ..................... 12111.1.45. Verification and validation of component-based systems ..................... 12111.1.46. Verification and validation of component-based systems ..................... 12211.1.47. Verification and validation of component-based systems ..................... 12211.1.48. Verification and validation of component-based systems ..................... 12211.1.49. Verification and validation of component-based systems ..................... 12311.1.50. Verification and validation of component-based systems ..................... 12311.1.51. Verification and validation of component-based systems ..................... 123



11.1.52. Verification and validation of component-based systems ..................... 12411.1.53. Verification and validation of component-based systems ..................... 12411.1.54. Verification and validation of component-based systems ..................... 12511.1.55. Verification and validation of component-based systems ..................... 12511.1.56. Verification and validation of component-based systems ..................... 12511.1.57. Verification and validation of component-based systems ..................... 12511.1.58. Verification and validation of component-based systems ..................... 12511.1.59. Verification and validation of component-based systems ..................... 12611.1.60. Verification and validation of component-based systems ..................... 12611.1.61. Verification and validation of component-based systems ..................... 12611.1.62. Verification and validation of component-based systems ..................... 12711.1.63. Verification and validation of component-based systems ..................... 12711.1.64. Verification and validation of component-based systems ..................... 12811.1.65. Verification and validation of component-based systems ..................... 12811.1.66. Verification and validation of component-based systems ..................... 12811.1.67. Verification and validation of component-based systems ..................... 12911.1.68. Verification and validation of component-based systems ..................... 12911.1.69. Verification and validation of component-based systems ..................... 12911.1.70. Verification and validation of component-based systems ..................... 13011.1.71. Verification and validation of component-based systems ..................... 13011.1.72. Verification and validation of component-based systems ..................... 13011.1.73. Verification and validation of component-based systems ..................... 13011.1.74. Verification and validation of component-based systems ..................... 13111.1.75. Verification and validation of component-based systems ..................... 13111.1.76. Verification and validation of component-based systems ..................... 13111.1.77. Verification and validation of component-based systems ..................... 13211.1.78. Verification and validation of component-based systems ..................... 13211.1.79. Verification and validation of component-based systems ..................... 13211.1.80. Verification and validation of component-based systems ..................... 13211.1.81. Verification and validation of component-based systems ..................... 13311.1.82. Verification and validation of component-based systems ..................... 13311.1.83. Verification and validation of component-based systems ..................... 13311.1.84. 11.1.9 Test infrastructure ....................................................................... 13411.1.85. Verification and validation of component-based systems ..................... 13411.1.86. 11.1.10 Aspects of testing ..................................................................... 13411.1.87. Verification and validation of component-based systems ..................... 13411.1.88. Verification and validation of component-based systems ..................... 13411.1.89. Verification and validation of component-based systems ..................... 13511.1.90. Verification and validation of component-based systems ..................... 13511.1.91. Verification and validation of component-based systems ..................... 13611.1.92. Verification and validation of component-based systems ..................... 136

12. 12 Verification Problems .................................................................................................. 13612.1. 12.1 Verification of CBSD .................................................................................. 136

12.1.1. 12.1.1 Component-Based software development ................................... 13612.1.2. Component-Based software development .............................................. 13612.1.3. 12.1.2 Important properties for software components ............................ 13712.1.4. Component-Based software development .............................................. 13712.1.5. Component-Based software development .............................................. 13712.1.6. Component-Based software development .............................................. 13712.1.7. 12.1.3 Verification problems of CBSD ................................................... 13812.1.8. Component-Based software development .............................................. 138



12.1.9. Component-Based software development .............................................. 13812.1.10. 12.1.4 Model checking .......................................................................... 13812.1.11. Component-Based software development ............................................ 13812.1.12. 12.1.5 Usage model .............................................................................. 13912.1.13. Component-Based software development ............................................ 13912.1.14. 12.1.6 Verification of the usage model ................................................. 13912.1.15. Component-Based software development ............................................ 13912.1.16. Component-Based software development ............................................ 13912.1.17. The model and the specification in NuSMV ........................................ 13912.1.18. Component-Based software development ............................................ 14012.1.19. Component-Based software development ............................................ 14012.1.20. Corresponding parts of Use Case description and NuSMV specification 14112.1.21. Fair and violating behaviour (1) ........................................................... 14112.1.22. Fair and violating behaviour (2) ........................................................... 14212.1.23. 12.1.7 Conclusions ................................................................................ 14212.1.24. Component-Based software development ............................................ 14212.1.25. 12.1.8 References .................................................................................. 14212.1.26. Component-Based software development ............................................ 14212.1.27. Component-Based software development ............................................ 143

12.2. 12.2 Example - A railway problem ...................................................................... 14312.2.1. Counter-example ..................................................................................... 14412.2.2. Counter-example ..................................................................................... 14512.2.3. Counter-example ..................................................................................... 14612.2.4. Counter-example ..................................................................................... 14612.2.5. Counter-example ..................................................................................... 14612.2.6. Counter-example ..................................................................................... 14712.2.7. Counter-example ..................................................................................... 14712.2.8. Counter-example ..................................................................................... 14712.2.9. Counter-example ..................................................................................... 14712.2.10. Counter-example ................................................................................... 14712.2.11. Counter-example ................................................................................... 14812.2.12. Counter-example ................................................................................... 14812.2.13. Counter-example ................................................................................... 14812.2.14. Counter-example ................................................................................... 14812.2.15. Counter-example ................................................................................... 14912.2.16. Counter-example ................................................................................... 149

13. 13 Model checkers ........................................................................................................... 14913.1. 13.1 Model checkers ............................................................................................ 149

13.1.1. 13.1.1 Component-based software technology ....................................... 14913.1.2. Model checkers ....................................................................................... 14913.1.3. 13.1.2 Component-based software development .................................... 15013.1.4. Model checkers ....................................................................................... 15013.1.5. 13.1.3 Contracts ...................................................................................... 15013.1.6. Model checkers ....................................................................................... 15013.1.7. Model checkers ....................................................................................... 15013.1.8. Model checkers ....................................................................................... 15013.1.9. Model checkers ....................................................................................... 15113.1.10. 13.1.4 Verified components .................................................................. 15113.1.11. Verified components ............................................................................. 15113.1.12. A component, that realizes mutual exclusion ........................................ 15113.1.13. 13.1.5 Peterson's method ...................................................................... 152



13.1.14. Peterson's method (1981) - First process .............................................. 15213.1.15. Peterson's method - Second process ..................................................... 15213.1.16. 13.1.6 Correctness ................................................................................. 15213.1.17. Model checking ..................................................................................... 15213.1.18. Model checking ..................................................................................... 15213.1.19. Model checking ..................................................................................... 15313.1.20. 13.1.7 Symbolic Model Verifier ........................................................... 15313.1.21. Model checking ..................................................................................... 15313.1.22. Model checking ..................................................................................... 15413.1.23. MODULE prc(state0, state1, turn, turn0) ............................................. 15413.1.24. MODULE prc - cont. ............................................................................ 15413.1.25. Model checking ..................................................................................... 15413.1.26. 13.1.8 A model of parallel computation ................................................ 15413.1.27. Model checking ..................................................................................... 15413.1.28. Model checking ..................................................................................... 15513.1.29. Model checking ..................................................................................... 15513.1.30. Model checking ..................................................................................... 15513.1.31. Model checking ..................................................................................... 15613.1.32. Model checking ..................................................................................... 15613.1.33. Model checking ..................................................................................... 15613.1.34. Model checking ..................................................................................... 15613.1.35. Model checking ..................................................................................... 15713.1.36. 13.1.9 Combination of model checkers and testing .............................. 15713.1.37. Model checking ..................................................................................... 15713.1.38. 13.1.10 Example ................................................................................... 15713.1.39. Component-Based software development ............................................ 15713.1.40. Component-Based software development ............................................ 15813.1.41. The model and the specification in NuSMV ........................................ 15813.1.42. Model checking ..................................................................................... 15913.1.43. Fair and violating behaviour (1) ........................................................... 15913.1.44. Model checking ..................................................................................... 16013.1.45. Fair and violating behaviour (2) ........................................................... 16013.1.46. Model checking ..................................................................................... 16013.1.47. 13.1.11 References ................................................................................ 16113.1.48. CBSD - Model checkers ....................................................................... 16113.1.49. CBSD - Model checkers ....................................................................... 161

14. 14 Common Component Modeling .................................................................................. 16114.1. 14.1 Common Component Modelling ................................................................. 161

14.1.1. 14.1.1 Modelling of a trading system ..................................................... 16114.1.2. Common Component Modelling ............................................................ 16114.1.3. Common Component Modelling ............................................................ 16214.1.4. Common Component Modelling ............................................................ 16214.1.5. Common Component Modelling ............................................................ 16214.1.6. Common Component Modelling ............................................................ 16314.1.7. Common Component Modelling ............................................................ 16314.1.8. Common Component Modelling ............................................................ 16314.1.9. Common Component Modelling ............................................................ 16414.1.10. Common Component Modelling .......................................................... 16414.1.11. Common Component Modelling .......................................................... 16414.1.12. Common Component Modelling .......................................................... 16414.1.13. Common Component Modelling .......................................................... 164



14.1.14. Common Component Modelling .......................................................... 16514.1.15. Common Component Modelling .......................................................... 16514.1.16. Common Component Modelling .......................................................... 16614.1.17. Common Component Modelling .......................................................... 16614.1.18. Common Component Modelling .......................................................... 16714.1.19. Common Component Modelling .......................................................... 16714.1.20. Common Component Modelling .......................................................... 16714.1.21. Common Component Modelling .......................................................... 16714.1.22. Common Component Modelling .......................................................... 16814.1.23. Common Component Modelling .......................................................... 16814.1.24. Common Component Modelling .......................................................... 16914.1.25. Common Component Modelling .......................................................... 16914.1.26. Common Component Modelling .......................................................... 16914.1.27. Common Component Modelling .......................................................... 17014.1.28. Common Component Modelling .......................................................... 17014.1.29. Common Component Modelling .......................................................... 17014.1.30. Common Component Modelling .......................................................... 17114.1.31. Common Component Modelling .......................................................... 17114.1.32. Common Component Modelling .......................................................... 17114.1.33. Common Component Modelling .......................................................... 17214.1.34. Common Component Modelling .......................................................... 17214.1.35. Common Component Modelling .......................................................... 17214.1.36. Common Component Modelling .......................................................... 17314.1.37. Common Component Modelling .......................................................... 17314.1.38. Common Component Modelling .......................................................... 17414.1.39. Common Component Modelling .......................................................... 17414.1.40. Common Component Modelling .......................................................... 17414.1.41. Common Component Modelling .......................................................... 17414.1.42. Common Component Modelling .......................................................... 17514.1.43. Common Component Modelling .......................................................... 17514.1.44. Common Component Modelling .......................................................... 17514.1.45. Common Component Modelling .......................................................... 17614.1.46. Common Component Modelling .......................................................... 17614.1.47. Common Component Modelling .......................................................... 17714.1.48. Common Component Modelling .......................................................... 17714.1.49. Common Component Modelling .......................................................... 17714.1.50. Common Component Modelling .......................................................... 17714.1.51. Common Component Modelling .......................................................... 17814.1.52. Common Component Modelling .......................................................... 17814.1.53. Common Component Modelling .......................................................... 17914.1.54. Common Component Modelling .......................................................... 17914.1.55. Common Component Modelling .......................................................... 18014.1.56. Common Component Modelling .......................................................... 18014.1.57. Common Component Modelling .......................................................... 18114.1.58. 14.1.2 Literatures .................................................................................. 18114.1.59. Common Component Modelling .......................................................... 18214.1.60. Common Component Modelling .......................................................... 182


Component-Based Software Development1. 1 Introduction

1.1. Introduction

Software development method

• Regular (non-component-based) development method: generally top-down, using problem decomposition methods.

• Component-based development method: bottom-up approach, building complex systems from new and ready to use (off the shelf) components.

1.2. Introduction

Top-down approach

• We decompose the system recursively to obtain small enough subsystems to implement.

• Do the following steps on each subsystem:

• Create specification

• Plan

• Implement

• Assemble system (integration).

• Although, subsystems fit to our project, but not to other projects (reusage difficulty).

1.3. Introduction

Component-based development

• Use off-the-shelf software components to assemble the system.

• These components should be

• general enough

• formerly made

• to the current project, or

• a part of other software system

• Bottom-up approach is typical.

1.4. Introduction



Mixing different approaches

• At regular software development, we are using libraries and system calls, and they act like components.

• If we simply put together the components, we will probably not get the result we expected. We also need a part of the top-down technics (to correctly define the components).

1.5. 1.1 Software development

1.5.1. Software development

Usual software development practice in nowdays

• Decompose the software system into smaller parts.

• If it is possible, substitute the parts with already existing components.

• If the required component does not exist, continue the decomposition of the system.

• Finally, reuse the software components associated to the subsystems and implement the not-existing components.


Software development model

• Every software development project should be based on a model.

• A good model defines the processes how to do the next tasks

• Analysis

• Design

• Implementation (programming)

• Verification

• Documentation

• etc.


Concept of software development model

• Collection of procedures and recommendations

• Support the whole software development during its life-cycle

• It tells what to do, and how to do.

• In one word: a prescription to create programs.

• Software development models



• Waterfall model

• Spiral model

• Component-based

• etc.

• This course will discuss the KobrA software development model in details.

1.5.4. 1.1.1 Component-based Software Development

1.5.5. Component-based Software Development

Component-based Software Development (CBSD)

• CBSD an assembly/integration of the software components into a system. Question: How to do this in practice?

• Problem: the environments are different, where the program is written and where the program will be used Integration check is needed. Question: What are the basic concepts of code reuse.

• During software development, a kind of technology and tools are used. Question: What kind of tools are available to component-based software development?

• We want to answer these questions at this course.

1.5.6. Component-based Software development

Components in focus

• The main notion of component-based systems is the component.

• Most important properties of the component:

• Well-defined user interface

• Quality attributes

• Reusability

• Evolution

• Reliability

1.5.7. 1.1.2 Concepts of component

1.5.8. Concepts of component

Hans-Gerhard Gross: The component is a reusable element of the composition, which has a well-defined interface, and it has quality attributes about its client side (which needs services) and server side (which provides services). The interface is given by abstraction, and they can be combined without modification.

C. Szyperski: The component is a reusable element of the composition, which has a well-defined interface, and it has environmental dependecies, those can be used independently from each other by a third party too.



J. Hopkins: A software component has a well-defined public interface, and this component is a physical package of an executable software.

1.5.9. Composition

Purpose of composition

• The component is the reusable unit of composition.

• Components should be functional in different environments.

• Recursive composition is permitted.

1.5.10. Composition - UML diagram

1.5.11. Interface

Interface

• Provided interface

• Collection of services and behaviours provided to the clients by the component.

• Entry point of execution of the component.

• Required interface

• Collection of services and behaviours required by the component from the environment.

• Without a correct environment and support, it is not guaranteed that the component is able to provide the functionality described in its interface to the clients.

1.5.12. Client-Server connection

Client-Server connection

• At the viewpoint of the provided interface, the component acts like a server.

• At the viewpoint of the required interface, the component acts like a client.



• The collaboration between the provided and required interfaces is guaranteed with contracts.

1.5.13. UML representation of the required and provided interfaces of the component

2. 2 UML, IDL

2.1. 2.1 UML

Short overview

• Unified Modeling Language: a set of graphic notation techniques to create visual models of object-oriented systems,

• In 1990s at Rational Software: Grady Booch, Ivar Jacobson and James Rumbaugh,

• In 1997 it was adopted by the Object Management Group (OMG),

• In 2000, UML was accepted by ISO.

2.2. 2.2 Modeling in UML

Modeling in UML

• UML is graphical modeling language, where

• the specification can be defined at abstract level,

• methods and tools exist to implement the specified system,

• it is a solution to create the documentation.

• UML2 is an extension of UML with 13 basic diagram types, organized into two large groups.

• Structural modeling diagrams

• Behavioral diagrams

2.3. 2.3 Structural diagrams

2.3.1. Structural diagrams

Structural modeling diagrams

• The static architecture of a model can be defined with structural diagrams.

• Basic elements of a model are

• classes, objects, interfaces and component.

• The structural models define the relations and dependencies among the elements of the model.

• Six different diagrams can be used to create the structural diagram



• Package diagram

• Class diagram

• Object diagram

• Composite diagram

• Component diagram

• Deployment diagram

2.3.2. 2.3.1 Package diagram

2.3.3. Package diagram

Package diagram

• It describes how to organize packages and its elements. The namespace is same for elements in the same package.

• Connectors can be defined among the packages

• Package merge is an implicit generalization between two package. Element definitions of the source package can be extended with the element definitions of the target package.

• Package import means that elements of the target package use the unqualified version of the source package names.

• Nesting connectors signs that the source package is contained in the target package.

2.3.4. 2.3.2 Class diagram

2.3.5. Class diagram

Class diagram

• The static structure of the system can be defined with class diagrams.

• It describes the relations among the classes and interfaces.

• A relation type can be one the next types

• generalization

• aggregation

• association

• inheritance



• composition

• Class diagram describes the structure of the solution in the problem space. It can be viewed as a simple connected graph, where the nodes are classes and the edges are relations.

• http://uml.org/#UML2.0

2.3.6. Class diagram

2.3.7. 2.3.3 Object diagram

2.3.8. Object diagram

Object diagram

• A special case of the class diagram.

• Object diagram focuses on the connections among class instances at a given time slice.

• The following example shows the difference between the class and object diagrams.

• A class consists of name, attributes, methods.

• Only the name is given for an object, and the class, the object instantiated from.

2.3.9. 2.3.4 Composite structural diagram

2.3.10. Composite structural diagram

Composite structural diagram

• The composite diagram defines the inner structure of the class, and those points, where they connect to the system.

• Figure shows a general schema to define a class.




Part

• A part is an element of a class, which represents one or more instances, whiches are owned by the instance of the given class.

• An example can be seen on right.


Port

• A port is an element with a given type. It represents a part of a class instance, which can be viewed from outside.

• A port can specify all the services, whiches are provided and required by the class.


Interface

• Similar to the class, but

• All interfaces are public and abstract and they do not have default implementations.

• An attribute of an interface is a constant.

• If a class inherits only from one super-class, then it can implement multiple interfaces.

• The interface can be represented as on the upper figure, while the representation of the provided and required interfaces can be seen on the lower figure.




Delegate

• Delegate is a connector, which defines the inner function of the outer ports and interfaces of the component.


Collaboration

• A collaboration defines a set of cooperation roles. They are used to illustrate a specific functionality.

• A collaboration often realizes a pattern.

• It shows only those roles and attributes, whiches are required to provide the required functionality.

• It is represented by an ellipse.


Role binding

• A connector, which connects a collaboration and a class or a part of a class. The given role is realized by the class.


Representation



• Representation is a special connector, which makes connection between a collaboration and a class, where collaboration is used inside the class.


Occurence

• A connector, which makes connection between a collaboration and a class, where collabaration represents the class.

2.3.19. 2.3.5 Component diagram

2.3.20. Component diagram

Component diagram

• A component diagram represents a part of the software and the system is built from these components.

• The component diagram has a higher abstraction level than the class diagram. A component is realized often by more than one class at runtime.

• A component diagram may represent many components and their relations.


Short explanation of the previous figure

• Product and Customer components provide the interfaces for the Order component.

• Between the Account and Order component, a dependency relation can be seen.

• The dependency relation projects the Account details of the Customer to required interface of the Order, identified by Payment.

Assembly connector on the previous figure




Component with ports

• A component specification can be extended by ports, and then the provided and required services can be also specified.

• The ports OrderEntry, Tracking on the figure represent the provided interface, while payment gives the required interface to OrderProcess component, which has a port OnlineService.

2.3.23. 2.3.6 Deployment diagram

2.3.24. Deployment diagram

Deployment diagram

• It is modeling the architecture of a system at runtime.

• The diagram shows the configuration of hardware elements (nodes) and it also shows the projection of software elements onto the hardware.

• A node represents a hardware or software element as a 3D box. The figure above represents a node and a node instance.

• Stereotypes can be: <server>, <storage>, <cdrom>, <computer>, <pc>, <unix server>, <pc server>, <pc client>, etc.

2.3.25. 2.3.7 Artifact, Installation association

2.3.26. Artifact, Installation association

Artifact

• A product is a result of a software development process, which contains

• models (use-case models, design models, etc.),

• test results, prototypes and user guides, source files, executables, etc.

Installation association

• Associations represent the communication paths among the nodes in the case of deployment diagrams.

2.4. 2.4 Behavioral diagrams

2.4.1. Behavioral diagram



Behavioral diagram

• Use case diagram

• Activity diagram

• State machine diagram

• Communication diagram

• Sequence diagram

• Timing diagram

• Interaction overview diagram

2.4.2. 2.4.1 Use case diagram

2.4.3. Use case diagram

Use case diagram

• The use case model contains the requirements at the highest abstraction level to the system.

• The elements of the model

• actors, whose are able to generalize other actors,

• use cases, describing the behaviors of the system at the highest level,

• use case definition

• name and description

• requirements

• scenario

• scenario diagrams

• other information...

• Including use cases

• Extending use cases

• Extension points

• System boundary

2.4.4. 2.4.2 Activity diagram

2.4.5. Activity diagram

Activity diagram

• It shows the sequence of activities of a process from the beginning to the end.



• Diagram can show different decision paths or parallel execution at the same diagram.

• This diagram is often used to model business processes, while the state machine diagrams are able to model a behaviour of only one object.

• Elements of the activity diagram

• activity, actions, action constraints,

• initial node, final node, decision and merge nodes, fork and join nodes

• control flow, objects and object flows,

• expansion region, interruptible activity region,

• exception handlers,

• partition.

2.4.6. Activity diagram - example

2.4.7. 2.4.3 State-machine diagram

2.4.8. State-machine diagram

State-machine diagram

• It models a behavior of one object.

• It specifies the event sequence, which occurs when a response is generated to a query.

2.4.9. State-machine diagram

Elements of the state-machine diagram

• States,

• initial and final states,

• transitions,



• state actions,

• self-transition,

• compound states,

• entry point,

• higher entry point,

• exit point,

• choice pseudo-state,

• junction pseudo-state,

• history state,

• concurrent regions.

2.4.10. 2.4.4 Communication diagram

2.4.11. Communication diagram

Communication diagram

• Formerly called as interaction diagram.

• It gives information similar to the sequence diagram.

• It focuses on the relations, connections of the objects.

2.4.12. 2.4.5 Sequence diagram

2.4.13. Sequence diagram

Elements of the sequence diagram

• Lifelines,

• messages,

• self messages,

• lost and found messages,

• lifeline start and end,

• duration and time constraints,



• combined fragments,

• gate,

• part decomposition,

• state invariant / continuations.

2.4.14. 2.4.6 Timing diagram

2.4.15. Timing diagram

Timing diagram

• Elements of the timing diagram

• state lifeline,

• value lifeline,

• putting it all together.

• Figure above shows two examples to state lifeline at the top, and a value lifeline at the bottom, while the whole figure gives an example to a combined timing diagram.

2.4.16. 2.4.7 Interaction overview diagram

2.4.17. Interaction overview diagram

Interaction overview diagram

• Elements of the interaction diagram

• interaction occurence,

• interaction elements,

• putting it all together.

2.5. 2.5 IDL

2.5.1. Interface Definition Language



IDL - Overview

• Language independence

• Defines object (called modules in CORBA terminology) interfaces

• Hides the implementation

• An IDL compiler is needed to create stubs and skeletons to the described components. Stubs and skeletons are code chunks, providing connection between the components.

• IDL compilers available to a wide range of programming languages: C, C++, Java, Cobol, Smalltalk, Ada

• Elements of the language: tokens, comments, identifiers, keywords and literals


Tokens

• Tokens can be: identifiers, keywords, literals, operators, other separators.

• A token is taken to be the longest string of characters that could possibly constitute a token.

Comments

• Follows the C, C++, etc. standard

• Comment start/end: /* and */

• Comment till the end of the line: //

• Comment start does not take effect in the line of the // characters after them.

• // characters does not take effect in a /* */ block.


module M{ typedef int MyInt; const int i = 1; interface i { // error: reuse of identifier void run( in MyInt myint // error: MyInt and myint collide ); readonly attribute long Attribute; // error: Attribute collides with keyword attribute attribute boolean abstract; // error: abstract collides with keyword abstract attribute boolean _abstract; // OK! now it is an identifier };};

Identifiers

• An identifier is an arbitrarily long sequence of ASCII alphabetic, digit, and underscore _ characters. The first character must be an ASCII alphabetic character.

• Upper- and lower-case letters are treated same.



• In OMG IDL: there is only one namespace for identifiers in each scope.

• Identifier names can be escaped with _


module M { typedef Long my_num; // Error: keyword is long, not Long typedef boolean BOOLEAN; // Error: BOOLEAN collides with the keyword boolean};

Keywords

• Keywords are case-sensitive!

• Keywords e.g.: abstract, exception, interface, module, etc.

• Punctuation characters:

• Preprocessor tokens:


Literals

• Integer literals: Decimal, if 0 or sequence of digits, begins with non zero. If starts with 0, then it is an octal integer. A sequence of digits preceded by 0x or 0X is taken to be a hexadecimal integer.

• Character literals: Character literals have type char. Non-graphic character must be represented using escape sequence, e.g.: newline n, horizontal tab t, etc.

• Floating-point literals: consist of an integer part, a decimal point, a fraction part, an e or E, and an optionally signed integer exponent. The integer and fraction parts both consist of a sequence of decimal (base ten) digits. Either the integer part or the fraction part (but not both) may be missing; either the decimal point or the letter e (or E) and the exponent (but not both) may be missing.


Literals

• String literals: a sequence of characters with the exception of the character with numeric value 0, surrounded by double quotes, e.g.: "HELLO".

• Fixed-point literals: Consists of an integer part, a decimal point, a fraction part and a d or D. The integer and fraction parts both consist of a sequence of decimal digits. Either the integer part or the fraction part (but not both) may be missing; the decimal point (but not the letter d (or D)) may be missing.

2.5.7. Interface Definition Language - Example

// Defines a container (namespace)module <identifier>

// Defines a CORBA object interface <identifier> [:inheritance] { <type declarations>;



<constant declarations>; <exception declarations>; <attribute declarations>;

// Defines a method [<op_type>] <identifier>(<parameters>)[raises exception][context]; }}

IDL - CORBA Details of IDL will be discussed later as a part of CORBA.

3. 3 Software architectures

3.1. Software architecture

Concept of software architecture

• Software architecture is a relatively young discipline. Its concept is not yet complete.

• Some definitions:

• Software architecture is not else, than a high level software designing;

• It is not else, than a structure of a complete system;

• The architecture is a set of components and connectors.


Our software architecture definition

• A software architecture of a program or a computer system is the structure(s) of the program or computer system, which structure contains the software elements, their visible properties (from outside), and their relationships.

3.3. Software architecture - Analysis of the definition

Architecture and abstraction

• The architecture defines the software elements and their connections, omitting those information, which is irrelevant to the interactions between the elements.

• The architecture is a kind of abstraction of a system. It omits information of elements, which does not define the usage, connections and interactions of the components.

3.4. Software architecture - Analysis of the definition

Relation of the system and the structure

• A system may contain several structures, and none of them can say unquestionnable, so it is the architecture.

• The architecture is the set of the structures.

• Software systems using softwares necessary have software architecture.



• The behaviours of the system elements should be parts of the architecture.

• Definition of architecture is indifferent in the meaning of the architecture is correct for the system or not.


Most important components of the software architecture

• Architecture schemas

• Reference models

• Reference architecture

• Relations of components can be seen on the next figure

• Directed arrows show that a given concept contains more than one elements.

3.6. Relations of architecture schemas, reference models, reference architectures and software architectures

3.7. 3.0.1 Architecture schema


Architecture schema

• An architecture schema is a description of elements and relation types, which also contain the set of constraints of their usages.

• Example: the client-server architecture is a well-known schema.

3.9. 3.0.2 Reference models


Reference models

• A reference model is a partitioning of the functionalities, which also contains the dataflows among the elements.

• The reference model is a standard decomposition of a well-known problem into such parts, whiches are cooperating to solve the original problem.

3.11. 3.0.3 Reference architecture




Reference architecture

• The reference architecture is a reference model, which is projected to the software elements and their connections.

• The reference models, reference schemas and reference architectures can not be considered itself as an architecture. These important definitions only help us to define the corresponding elements of the architecture.

3.13. 3.0.4 Software architecture


Why is the software architecture important?

• Important from the view of the communication among the components

• The software architecture represents that common abstraction of a system, which is used by all the components and it can be a starting point to the mutual understanding, the consensus and the communication.

• Important at the early designing decisions.

• Important as a kind of abstraction of the system, because it gives help to the reusability.

3.15. 3.0.5 Common software architecture structures

3.16. Common software architecture structures

3.17. 3.0.6 Model based structure

3.18. The model based structure

Elements of the model based structure

• Decomposition

• A unit of the decomposition is the module.



• Modules can be joined by the is a submodule of relation.

• A module can be decomposed recursively, until it becomes easy to understand and implement.

• Uses

• These units can be also modules, but they can be procedures or resources described in the module interface too. The uses relation stands between the units.

3.19. The model based structure

Elements of the model based structure - cont.

• Layered

• A special case of the uses relation, in a strictly layered structure.

• The n-th layer uses only the services of the (n-1)th layer.

• Class or generalization

• In this structure, modules are called classes.

• The relation in this case can be inherits-from or an-instance-of.

3.20. 3.0.7 Component-and-connector structure

3.21. Component-and-connector structure

Elements of the structure

• Processes, or communicating processes

• Like every component-and-connector structure, this is also orthogonal to the model based structure.

• Units are processes or threads, where communication is the synchronization - including the mutual exclusion.

• The relation between units is the attachment, which shows that how the components and connectors are connecting to each other.


Elements of the structure - cont.

• Concurrency

• This structure gives the opportunity to the system designers to introduce the parallel execution.

• Units are components, and connectors ara logical threads.

• Shared data, or repository

• This structure contains components and connectors. These are creating, storing and retrieving data.

• It shows that, how data is created and used by runtime software elements.




Elements of the structure - cont.

• Client-server

• System is built from a set of cooperating clients and servers.

• Components can be clients or servers, while the connectors are communication protocols.

3.24. 3.0.8 Allocation structure

3.25. Allocation structure

Elements of the allocation structure

• Deployment

• It defines, how the software is assigned to the hardware processing and to the communication elements.

• Its elements are the software (usually a process from a component-connector structure), the hardware (processes) entities, and the communication paths.

3.26. Allocation structure

Elements of the allocation structure - cont.

• Implementation

• This structure defines, how the software elements are projected to the file structures.

• Work assignment

• This structure assigns the implementation and integration of each module to a corresponding developer team.


Which structure should we use?

• Some useful architecture structure are introduced in outlines, but many others exist too. It can be asked, which one should be used to concrete task? It is hard to answer, because a system may contain several structures. The advice is that the quality attributes of the system should be analysed thoroughly first, then select those structures, whiches guarantee best the required quality.

3.28. 3.1 Component models

3.28.1. Component models

Goal of component models

• Support to build software systems from different functional and logic components, those can be located in



different network nodes.

• Both the software and the hardware sides of component-based software development has to be supported.

• Middleware is the most important part for basic softwares.

3.28.2. 3.1.1 Middleware


Middleware

• Its place is between the operating system and the application.

• It serves similar services as the operating system.


Middleware - services

• Framework to run component-based programs,

• Typical operating system functionalities,

• Connection between the operating system and programming language,

• Support one operating system and one programming language,

• Generate the executable code by a code generator,

• The manual component creation is less important, components can be independently developed.


Middleware

• Components can be either in the same or in different network nodes.

• Components located far away from each other can collaborate via Remote Procedure Call (RPC).

• A kind of RPC service can be found todays in any component platform.

• The object models are built upon the middleware.




Middleware systems

• Object Management Group (OMG)

• CORBA

• Microsoft

• COM/DCOM

• Sun Microsystems

• EJB

3.29. 3.2 CORBA

3.29.1. CORBA

CORBA

• CORBA - Common Object Request Broker Architecture

• The first experiment to define an object model

• OMG 1991

• Main parts:

• Object Request Broker (ORB)

• The heart of CORBA, responsible for the communication among components, and for the creation and persistency of them.

• Interface description in Interface Definition Language (IDL)

• Portable, independent from the programming languages and operating systems.

• IDL - compilers to programming languages

3.29.2. 3.2.1 Object Request Broker

3.29.3. CORBA

Object Request Broker (ORB)

• Hide the communication among different address ranges (e.g. memory mapping)

• Components under the ORB supervision can create connections to each other, as if they are in the same memory space.

• ORB consists of several components on the client and server side.

3.29.4. CORBA - ORB



ORB - Client side

• Client IDL Stubs provide the static interfaces on the client side for CORBA component connections

• A proxy for remote procedure call, which transmit the calls to the remote server.

• Forward parameters to the server by the marshalling technique.

• ORB interface provides some useful local services to CORBA users:

• E.g. Convert component-references to character sequences (sequencialization) etc.

3.29.5. CORBA - ORB

ORB - Client side

• Dynamic Invocation Interface - DII helps to create dynamic components, whiches are able to explore and call methods of the server-side components in runtime.

• DII provides better flexibility at runtime, but static stubs support type checking at compilation.

• Interface Repository API provides the runtime access to the interface-repository, which contains the preprocessed IDL definitions.

• In CORBA 2.0, it also contains ORB global identifiers (Repository ID). Repository IDs are uniq identifiers of components and their interfaces.

3.29.6. CORBA - ORB

ORB - Server side

• Server IDL Stub defines static services of the server side components. Its skeleton also generated by the IDL compiler.

• Dynamic Skeleton Interface (DSI) is the pair of the Dynamic Invocation Interface (DII). It provides information in runtime about those server side components, those do not have IDL defined static stubs. DSI determines the corresponding component and its service (method), by the parameteres of the incoming message.

3.29.7. 3.2.2 Object Adapter

3.29.8. CORBA

Object Adapter

• Required to the implementation of DSI, DII, but can be used independently also.

• Runtime environment manages the

• Object references,

• Implementation Repository

• All ORB support at least one adapter

• Basic Object Adapter (BOA)

3.29.9. 3.2.3 Implementation Repository, ORB interface



3.29.10. CORBA

Implementation Repository, ORB interface

• Implementation Repository

• Container of descriptions of the implemented server side classes.

• Keeps track the instantiated objects and how to identify them.

• ORB interface is the pair of the server side IR on the client side.

3.29.11. 3.2.4 IDL

3.29.12. CORBA - IDL

Interface Definition Language (IDL)

• CORBA is strictly an object based system

• Server components can be defined as classes. Their properties are

• Inheritance,

• Exception handling,

• Encapsulation.

• IDL is used to define the classes

• Portable

• Programming language and operating system independent declarative language. It does not contain procedural elements, but supports

• Types,

• Contansts,

• Data elements,

• Methods,

• Exception declaration.


Interface Definition Language (IDL)

• Interfaces given in IDL language are compiled by the IDL compiler to a concrete language (e.g. Java). Their methods should be implementated in the same programming language.

• The structure of IDL can be found in the Java 2 Útikalauz programozóknak book (editor: Nyékiné Gaizler Judit, ELTE TTK Hallgatói Alapítvány, Budapest, 1999.)




IDL compilers

• IDL - Java compiler

• Input: Interface description in IDL langauge

• Output: Java program code

• Usage of the compiler described in the book (section 22.3.)

• A simple, but useful example can be found about the usage of CORBA in the section 22.4 of the book.

• In the example, a group of objects are created on several servers.

• In the example above, the client and the server are using the CORBA Naming Service to localize each others.

3.29.15. Generated code execution within the CORBA infrastructure

3.30. 3.3 COM/DCOM

3.30.1. COM/DOM

COM/DCOM

• Component Object Model - COM

• The first component model of Microsoft (1993)

• COM+

• An expansion of COM: transactions, asynchronous messaging, with the tools of clustering.

• Distributed COM - DCOM

• An extension to COM to handle distributes systems

• A DCOM component is able to communicate with a DCOM server - by client proxies and server stubs.

• The services of CORBA and DCOM are getting closer, but not their tools!



4. 4 JavaBeans

4.1. 4.1 Introduction

4.1.1. Introduction

Sun Microsystems's Java 2 Enterprise Edition (J2EE)

• Describes how to design and develop Java programs, and how the objects communicate.

• Describes several business services: naming, transactions, lifecycle handling.

• Elements created in the standardized way are platform independent.

• The J2EE architecture was developed at the late '90s.

Enterprise JavaBeans (EJB) It defines the server side components.

4.2. 4.2 JavaBeans

4.2.1. JavaBeans

JavaBeans

• The simplest component model of Java.

• At the first sight, JavaBean is a reusable software component, which can be visually manipulated in the developer environment.

• In the JavaBeans component model

• a component may have several independent implementation.

• More instances can be created from a given component, customizing to the applications.

• Components can elements of containers.

• A component can be a container and also able to contain other components.

• Connections and communications among components are done by event handlers and method calls.

4.2.2. JavaBeans

JavaBeans

• The JavaBeans component model supports the hierarchic software development, where complex components can be created by containers from simpler components.

• Services of visual developer tools can be used.

• Development of beans is simplified by the Sun's BeanBox development environment.

• The JavaBeans model supports the customization of the beans by property lists. These lists can be displayed for easier manipulations.



4.2.3. 4.2.1 Enterprise Java Bean

4.2.4. JavaBeans - EJB

EJB - Enterprise Java Bean

• Server side distributed component model

• Types based on functionalities:

• Session Bean

• Enterprise Bean

• MessageDriven Bean

• An application server is requiered to run the components (an EJB container is required).

• Contracts between the EJB and the container

• set of interfaces,

• deployment descriptors.

4.2.5. 4.2.2 J2EE overview

4.2.6. Java2EE

Java2EE

• An architecture for a component-based, multi-layered enterprise application development.

• J2EE architecture:

4.2.7. Quality requirements of web-application

Quality requirements of web-application

• Scalability - System should be functional without human interaction, if load increases. The number of servers may change.

• Availability - System should be reachable 24 hours a day, and it should provide a short download time.



• Security - Provide possibility to register new accounts, and do right management (each person can get only that data for right is granted).

• Usability - Different users should be able to get different contents in different formats at the same time.

• Performance - Short response time is required.

4.2.8.

Additional requirements to J2EE

• Portability - Should be implemented easily on several platforms

• Ability to build - Developers can manage generally used services, like transactions, name services and security services

• Balanced specifications - Detailed specifications for manufacturers, developers and integrators, and sufficiently general specification for business and optimailty properties.

• Implementation, transparency - clear implementation; clients should not depend on details of implementations

• Cooperation - Components of different manufacturers should be able to communicate. Bridges should exist to different technologies (e.g. CORBA, .Net)

• Developmnet - Opportunity for developers to adopt different technologies.

• Expansibility - Possibility to integrate important and new technologies.

4.2.9. 4.2.3 J2EE - EJB overview

4.2.10. J2EE - EJB

Goals of EJB

• Support component-based software development by the reusability of the Java components.

• A tool is needed with server side applications can be developed as easy as e.g. GUI applications in Visual Basic.

• The standard framework has to be easy to use.

4.2.11. J2EE - Tasks of EJB

Tasks of EJB

• Support the lifecycle of a business application, including its deployment, and its runtime supervision.

• Define contracts, which provide the communcication ability to the components of different manufacturers.

• Cooperate with other Java APIs.

• Offer a cooperation between the Enterprise Beans and non Java application.

• Cooperate with CORBA.

4.2.12. Properties of J2EE



Main properties of J2EE

• Multilayered distributed application model

• Client layer

• Web layer

• Business component layer

• Enterprise information system tier

• Server side component model

• Built in transaction handling

4.2.13. 4.2.4 J2EE - architecture

4.2.14. Architecture of J2EE

4.2.14.1. 4.2.4.1 Client layer

4.2.15. J2EE - Client layer

Client Layer

• For a web application, it contains only a web browser. It sends HTTP requests to the Web server and download HTML pages from there.

• In applications, those are not using browser, Java clients ot applets can be used. These have direct connections to the Business component layer.

4.2.15.1. 4.2.4.2 Web layer

4.2.16. J2EE - Web layer

Web layer

• A Web server is running in the Web layer, which answers to the requests coming from the client layer, using servlets or JPS (Java Server Pages). Servlets are called by the server depending on the type of user requests.

• Servlets are gathering the required information from the business component layer. JPSs are HTML pages,



containing small server side codes. These codes are processed by the JPS mechanism.

4.2.16.1. 4.2.4.3 Business component layer

4.2.17. J2EE - Business component layer

Business component layer

• This layer contains business logic, which is realized by the EJB component. EJBs are receiving requests from the Web layer, and answers after successfully retrieved the required information from the databases (they are located in the Enterprise information systems tier). EJBs are located in a common container, which offers the following services to the EJBs:

• Life-cycle management

• State management

• Security

• Multi-threading

• Resource pooling

• EJB simply determines a behavioural pattern required from the container, and let the container do the rest of the task. By this, EJB code contains only the business logic, so it is clear and not mixed with other system or environment dependent codes.

4.2.17.1. 4.2.4.4 Enterprise information systems tier

4.2.18. J2EE - Enterprise information systems tier

Enterprise information systems tier (EIS)

• It contains some databases and some background applications (they are used by the EJBs). The connections are usually realized through JDBC drivers. Databases are usually Relation Database Management Systems (RDBMS).

4.2.19. 4.2.5 J2EE - EJB architecture

4.2.20. J2EE - EJB architecture

J2EE - EJB architecture

• EJB architecture supports the creation of the distributed server-side object-oriented Java applications.

• An existing EJB can be used anywhere. Task of the programmer is often to bulk them.

• Portability of EJBs is mainly guaranteed by the JVM. EJBs may need services, those are not provided by the JVM. These services are provided by a manufacturer independent interface set.

4.2.21. J2EE - EJB architecture

J2EE - EJB architecture Figure shows the relations of an application server, a container and the services.



4.2.22. J2EE - EJB container

EJB container

• Manage the execution of application components.

• Provide a process of the operating system, which is a host of one or more EJB components.

• When a client calls a server component, the container automatically allocates a thread, and calls the instance of the server component.

• Container does resource pooling for server components, and provides connection to the outer environment.

4.2.23. J2EE - Component model

Component model

• Define the basic architecture to the EJB components.

• Specify the interface-structure of the EJB components, and the mechanism with an EJB component can communicate with its container and other components.

• The model also contains a prescription how to develop components, which will be able to interact and be a part of a larger system.

4.2.24. J2EE - EJB Component types

EJB Component types - Session bean

• Session beans represent the business logic and provide services to clients. They can be:

• Stateless session bean or

• It does not have information about the state of the client, the client does not have a reference to the beans, and does not preserve them.

• The EJB container delegates the calls of clients to the session bean. They do not preserve the information that who called them. Client gets a reference to the bean, but if client wants to use the reference again, EJB does not guarantee that client will get the same bean instance. It is only guaranteed that a bean will called, which is able to perform the request.

• Stateful session bean



• The container generates a dedicated session bean to each client, which creates a bean instance.

• Client preserves the reference, and all the later calls go to the same bean instance.

• If the bean is not used for a long period, container saves the states of the bean to the storage device and automatically loads back when the client calls it.

4.2.25. 4.2.6 J2EE - EJB component types

4.2.26. J2EE - EJB Component types

EJB Component types - Entity beans

• Used to represent typical business data objects.

• An entity bean can be reached through a session bean.

• Entity beans can be

• Container managed persistence entity beans

• Bean-managed persistence entity beans

4.2.27. J2EE - EJB Component types - Entity beans

Container managed persistence entity beans

• This beans have direct connections to the database through the container.

• Container guarantees that at the beginning of a transaction the corresponding data should be written into the bean instance, and after transaction, container writes back the data to the data storage.

• The advantage is that the programmer does not have to deal with problems related to the data management, which simplifies the code.

4.2.28. J2EE - EJB Component types - Entity beans

Bean-managed persistence entity beans

• Only the bean consider how to represent and manage data. Usually JDBC calls are used to this.

• Advantage: in some cases, queries can be written more efficiently compared to the case, when container does it itself. We can manage datasources, those are not supported by the container.

• Disadvantage: programmers work more, but data operations can be optimized.

4.2.29. J2EE - Example for J2EE/EJB-compliant implementation



4.2.30. 4.2.7 J2EE - EJB programming

4.2.31. J2EE - EJB programming

EJB programming

• EJBs have connections only through the containers. If an EJB wants to reach a JDBC connection or an other bean, then it can be done throught the container.

• Beans can interact with a container

• with Callback methods, or

• through an EJBContext interface, or

• using Java Naming and Directory Interface (JNDI).

4.2.31.1. 4.2.7.1 Server side

4.2.32. J2EE - Creating a server side bean

Creating a server side bean

• Two interfaces should be defined, when the business methods are defined:

• Home - Instanciated from EJBHome. Contains methods to handle life-cycle: constructor, destructor, finding a bean-instance.

• Remote - Contains the business methods. If a client wants to call a method of these, a reference to the bean should be retrieved first through the Home interface. Client interacts with the bean always through the interface of remote. These methods are application specific.

• A bean class has to be written. It loads only, when it is needed. Functions contained in the interfaces are implemented here.

4.2.33. J2EE - EJB program units



[fragile]J2EE Example - A simple home interface

Creating a Broker type EJB

public interface BrokerHome extends EJBHome{ /* * This methid creates the EJB object. * * @return The newly created EJB object. */ Broker create() throws RemoteException, CreateException;}

[fragile]J2EE Example - Part of the Broker remote interface

public interface Broker extends EJBObject{ // Return the newly created account number public int newAccount(String sub_name, String sub_address, int sub_credit) throws RemoteException, SQLException; ... public void updateAccount(int sub_accno, int start_stock_id) throws RemoteException, SQLException; ... public Vector getHoldingStatement(int sub_accno, int start_stock_id) throws RemoteException, SQLException;}

Part of the Broker remote interface Interface contains methods, used by the container, when that manages the creation and the life-cycle of an EJB. Programmer can provide a bean specific behaviour to the EJB, or it can inherit a default behaviour. After that, client can use the public interface of the EJB to create, manipulate or destroy beans.

4.2.34. J2EE Example - The realizer class

Realizer class

• The realizer class, which is known as bean class, instanciated at runtime, and can be reached as a distributed object. The next figure shows a simple client code.

• An EJB client can be a standard application, servlets, applets or an other EJB. Each client uses the home interface of a server bean in order to get a reference to an instance of the server bean. Then, client connects to the server bean via the remote interface, when uses its methods.

• In this example the Broker bean is a stateless session bean, which processes the requests of the client.



4.2.34.1. 4.2.7.2 Client side

[fragile]J2EE Example - A code of a simple client

Broker broker = null;

// Find home interfaceObject _h = ctx.lookup("EntityStock.BrokerHome");BrokerHome home = (BrokerHome)javax.rmi.PortableRemoteObject.narrow(_h, BrokerHome.class);

// Use the home interface to create the Broker EJB Objectbroker = home.create();

// Execute requests at the broker EJBbroker.updateAccount(accountNo, 200000);broker.buyStock(accountNo, stockID, 5000);

// We are finished...broker.remove();

4.2.34.2. 4.2.7.3 Entity and Broker bean functions

[fragile]J2EE Example - An Entity bean, and a Broker bean function

public void updateAccount(int sub_accno, int sub_credit) throws RemoteException{ try { Account account = accountHome.findByPrimaraKey(new AccountPK(sub_accno)); account.update(sub_credit); } catch(Exception e) { throw new RemoteException(e.toString()); }}

Entity bean of the broker example

• The updateAccount method uses an entity bean called Account, which contains all the important functions of the application.

• The code of updateAccount uses a findByPrimaryKey method, which was defined in the home interface of the Account bean.

4.2.34.3. 4.2.7.4 Account bean, Home/Remote interface

[fragile]J2EE Example - Account bean - Home/Remote interface

public interface AccountHome extends EJBHome{ /* This method creates the EJB Object * @param sub_name The name of the subscriber * @param sub_address The address of the subscriber * @param sub_credit The initial credit of the subscriber * @return The newly created EJB Object */ public Account create(String sub_name, String sub_address,int sub_credit) throws CreateException, RemoteException;



// Finds an account by its primary Key (Account ID) public Account findByPrimaryKey(AccountPK key) throws FinderException, RemoteException;}

public interface Account extends EJBObject{ public void update( int amount) throws RemoteException; public void deposit( int amount) throws RemoteException; public int withdraw(int amount) throws RemoteException, AccountException; // Getter/setter methods on Entity Bean fields public int getCredit() throws RemoteException; public String getSubName() throws RemoteException; public void setSubName(String name) throws RemoteException;}

[fragile]J2EE Example - Account bean - update method

public class AccountBean implements EntityBean{ // Container-managed state fields public int sub_accno; public String sub_name; public String sub_address; public int sub_credit;

// lots missing public void update(int amount) { sub_credit = amount; }}

4.2.35. 4.2.8 Deployment descriptors

4.2.36. J2EE - Deployment descriptors

Deployment descriptors

• The greatest attraction of EJB model is that the business logic and the technical parts of programming can be separated.

• Technical details are often solved by the container. To achieve this, beans should define, what they require from the container. These requirements are described in the deployment descriptors, which are contained in an XML file.

• Requirements are defined in a declarative way.

• Advantage: several descriptors can be given for the same bean, to change its functionality.

[fragile]J2EE Example - Broker bean - Deployment descriptors

<ejb-jar> <enterprise-beans> <session> <ejb-name>EntityStock.BrokerHome</ejb-name> <home>j2ee.entitystock.BrokerHome</home>



<remote>j2ee.entitystock.Broker</remote> <ejb-class>j2ee.entitystock.BrokerBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>EntityStock.BrokerHome</ejb-name> <method-intf>Remote</method-intf> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor></ejb-jar>

4.2.37. 4.2.9 Summary

4.2.38. Summary

Summary

• The EJB component model can be used efficiently after a few practicing, to create client/server applications.

• The EJB model gives the chance to apply different architecture schemas in the same application. It is hard to decide, which schema is the best to the given application.

• The interaction between the beans and the container is very complicated, which effects the performance of the application.

• Efficient and scalable EJB applications can be written only after a lot of practice.

5. 5 KobrA program-development model

Based on the book of Hans-Gerhard Gross: Component-Based Software Testing with UML. Springer-Verlag Berlin-Heidelberg 2005.

5.1. KobrA

Introduction

• Developed by Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany.

• A synthesis of more currenty existing component-based program-development model:

• OMT

• Fusion

• ROOM

• HOOD

• OORAM

• etc.



5.2. KobrA

Introduction

• Goal: combine the strongnesses of the available methods and avoid their weaknesses.

• KobrA gives help to the activities (analysis, designing, programming, verification, documentation).

• The tool of the analysis and designing is the UML

• UML is a good choice, because modeling can be done without implementation or system specific considerations.

5.3. KobrA

Introduction

• The main goal is to create the abstract form of the basic structure of the system. Because of this, several implementation technology can be used.

• Principles:

• Separate problems

• Model based development

• Use of components

• Use of object oriented technology

• The figure shows that three dimensional model, which is suggested by the creators of KobrA.

5.4. 5.0.1 Development process

5.5. KobrA



5.6. KobrA

Development process

• KobrA divides the development process into two basic dimensions.

• All activities are rated in these two dimensions and analysed from this viewpoint.

• It defines four directions for the development:

• Composition / Decomposition

• Abstraction / Concretization

5.7. KobrA

Development process

• Composition / Decomposition

• Decomposition: Apply the Divide and conquer approach. It breaks up the system into flexible, independently managable parts.

• Composition: Assemble the system from the implemented parts.

• Abstraction / Concretization

• It goes from the model (which can be understood by the users) to the program (that can be executed on the computer).

5.8. KobrA

Development process

• One more dimension...



• Generalization / Specialization

• The job in this dimension plays role, when a complete product family is developed.

• The exact function of some components defines that which product (version) is discussed.

• This dimension is not discussed here to keep our model simple.

5.9. 5.0.2 Decomposition

5.10. KobrA

Decomposition - Vending-machine example

• Structure

• Vending machine

• Coin checker

• Button panel

• Dispenser / Change dispenser

5.11. KobrA

Decomposition - Vending-machine example

• In this case, the composition/decomposition is followed downward.

• During decomposition, we try to identify units, those are already implemented and reusable (or, if there is no chance to find those kind of units, we define them so that they will be reusable after implementation).

• The following figure shows the result of decomposition of the vending-machine problem.

5.12. KobrA - Vending-machine problem decomposition

5.13. KobrA



Decomposition

• The success of decomposition depends on the understanding of the problem.

• The goal is always to get reusable components during the decomposition.

• If it falls out of our sight, then each components should be reimplemented always, which gives nothing more, than a top-down method.

5.14. 5.0.3 Embodiment

5.15. KobrA

Embodiment

• During decomposition, each subsystem is identified and specified.

• The specification and implementation are handled separately.

• The specification contains the provided services, required by the user. It is described in a very abstract level.

• At the implementation level, the concrete implementation is given to the services specified in the user interface.

• The executable solution can be reached by starting from the UML model and going through the concrete representations. This process is called embodiment.

5.16. KobrA

Embodiment

• In the case of the vending machine, the process of embodiment is not only a coding (our machine can be seen as an embedded system). Embodiment here is also the decision of which parts should be realized by hardware and which ones by software.

5.17. 5.0.4 Composition

5.18. KobrA

Composition

• Some parts are implemented...

• ...others are reused.

• Now subsystems can be integrated into a complete system.

• This is an upward movement in the composition/decomposition dimension.

5.19. 5.0.5 Validation

5.20. KobrA



Validation

• Validation compares the implemented parts with the abstract model. This movement is realized in the abstraction/concretization dimension.

• It is not always the last task:

• It is not required to completely decompose a system to implement parts.

• An implemented unit can be validated immediately.

• If a unit depends on an other unit, e.g.: on a hardware, which does not exist yet, then it should be simulated.

5.21. 5.0.6 Spiral model

5.22. KobrA

Spiral model

• All the program development steps can be put into one of the dimensions. Activities are not always in the same order as suggested by the direction defined by the dimension.

• E.g.: decomposing a system, new elements can be identified. In this situation we face with an embodiment, a decomposition, a composition and a validation step.

• At least the embodiment can be made. The steps of composition and validation can be done at abstract level, in the UML model level.

• It means that the steps above are repeated in different levels - this is the key of the spiral program development model.

5.23. 5.0.7 Waterfall model

5.24. KobrA

Waterfall model

• Activites are done in a strict order.

• Spiral model fits better to the component-based software development.

• Waterfall model are useful for the traditional program development.

• The next figure shows the UML diagram of the vending machine. Each UML package symbol defines a set of model elements.

5.25. 5.0.8 Example

5.26. KobrA - Vending machine UML diagram



5.27. KobrA

Notations

• "Component" - a KobrA component

• "Variant" - it notes the fact that the component is a part of a product family

• Each "Variant" component may have a different implementation, depending on what kind of product should be made.

5.28. 5.1 Environmental map

5.28.1.

Environmental map

5.28.2. KobrA - Environmental map

Environmental map

• The starting point of the software development is the specification of the system or application.

• The specification is inherited and decomposed from the requirements. User-level requirements collected from prospective users by use case diagrams are also decomposed later.

• Descriptor data are collected by gathering information about the environment.

• The system or application specification should reflect to the requirements of the environment.

• The collection of the environment descriptor elements is called environmental map.

• KobrA method handles the environmental map the same as the components, while it is an independent component with its own rules.

5.28.3. KobrA - Environmental map - Example



Vending machine - Environmental map A part of the environmental map of the vending machine. "Mechatronics" stereotypia denotes that the system is a combination of electronical and mechanical parts and a software.


Note

• The KobrA style contain relation on the previous figure is an extension of a KobrA method, which is basically developed for embedded systems.

• This method is called as Marmot.

• The exact definition of the environment is always the first step in a development project.


Environmental map

• The definition of the environment is the first step in a development project, where the following questions should be answered:

• What kind of activities are supported by the system?

• What is the input of the system?

• Who/what will be in relation with the system?

• What kind of objects are required from the system in order to perform other activities in the environment?

• This first step is well represented by the use case diagrams.

• The environmental map can be also created by other models: model of business or enterprise processes, structural and interaction models.

• Next figure shows the elements, those are creating an environmental map.

5.28.6. KobrA - Environmental map elements




Environmental map

• As a result of the environmental map definition, the required interfaces of the whole system can be determined.

• If an existing component is found, which has a specification that satisfies the actual context, then it can be reused (so it is not required to reimplement it).

5.28.8. 5.1.1 Usage model


Usage model

• It specifies the high-level relation of the system and the user.

• This model is a collection of use case diagrams.

• Usage models can be used to define the system modules at a very abstract level.

• Use cases are concentrating mainly on the interactions of the system components, and on the connections between the system and its boundaries.

• Use case diagrams introduces the actors of the system and the use cases, and the existing relations among them.

• Each use case represents an abstract activity, which is performed by the user of the system.

5.28.10. KobrA - Usage model - Vending machine's use case diagram




Usage model

• Use case diagrams contain few information itself, so they have to be completed with use case descriptors. It can be done by using use case templates.

5.28.12. KobrA - Environmental map - Use case template

5.28.13. KobrA - Vending machine - Purchase item use case



5.28.14. 5.1.2 Business and enterprise processes model


Business and enterprise processes model

• Describe the business environment of our system.

• Sometimes it is not so important, e.g. in case of embedded systems (vending machine).

• Sometimes it is important (bank systems).

• In the case of bank systems, the enterprise model represents those notions, those are relevant to the world of banks.

• In this case, business and enterprise models are focusing on how these existing notions affect the computer system.


An enterprise model of a bank software

• Relevant notions of a bank software

• Bank account



• Account

• Exchange rates

• Form filled by customers

•

• It should be defined for a business and enterprise model

• that how these notions affect the software system, which will be created and

• what kind of changes should take effect in the organization structure of the bank after the system is installed.

5.28.17. 5.1.3 Structural model


Structural model

• The structural model lies inside the environmental map, which defines the structures of those entities, those are out of the system's scope, but they effect the system. It contains the system's

• inputs and

• output (which will be postprocessed somehow).

• In our example, the simplest case does not contain such outer structure, which has to be considered. (If a creditcard or hotelcard payment method exist, then these should be included in the structural model.)

5.28.19. KobrA - Structural model of a variant inside the environmental map


Notations

• The user of the vending machine can pay in two different ways:

• together with the hotel receipt, or



• with creditcard.

• It is noticed with the following variants:

• "variant" RoomBilling association in the diagram, and

• "variant" CCBilling association in the diagram.

5.28.21. 5.1.4 Activity and interaction model


Activity and interaction model

• The activity model inside the environmental map describes the activities of the system actors, those affect the system boundaries.

• The UML activity diagram is very similar to the traditional control flow graph, although diagrams are used on a higher abstraction level.

5.28.23. KobrA - Activity diagram - Vending machine - Purchase Item


Explanation

• At the entry point of the diagram, we can choose from two alternatives

• select an item or

• drop coins into the machine and the select an item.

• The main path in the activity diagram is to dispense the selected item and the change.

• These two activities can run concurrently, as it can be seen on the model.

• An other possible path in the diagram is the abort.



5.28.25. 5.1.5 Summary


Summary of the environmental map

• Usage model

• is useful to discuss with the customer, whether we understood correctly the problem,

• and to transform the models into diagrams.

• Activity model

• based diagrams are going one step closer to the technical abstraction. These small steps are important, because the development is made recursively until we reach an implementable version.

• Interaction model

• is very useful to show the user activities.

5.28.27. KobrA - Activities of a customer of the Vending machine


Summary of the environmental map - cont.

• When the environmental map is made, then the next step is to specify the top level component.

• Component/system: it depends on the viewpoint and it is difficult to define the place where they should be split.

• Components can be defined by the tools of the meta-model (as can be seen on the next figure).

5.28.29. KobrA - Component meta-model diagram




KobrA method

• KobrA method consists of two important parts:

• the component specification and

• the component implementation.

• Next time, these topics will be discussed.

6. 6 KobrA - Component specification and implementation

6.1. 6.1 Component specification

6.1.1. 6.1.1 Component specification

6.1.2. Component specification

Component specification

• The component specification is a collection of such descriptive documents, those define the functionality of the component.

• Each document analyze an aspect of the component functionality and concentrate only on what the component does.


Component specification tools



• Tools of component specification

• Description in a natural language

• Graphical tool (UML)

• Formal tools

• like Object Constraint Language (OCL), which is defined in the UML, or

• QoS Modeling Language to specify the Quality of Service criterias.

• It does not matter, how it happens, the essence is to give a specification, which is complete as it can be, to be able to understand the behavior of the component in order to use that.

• Goal: describe the required and provided interfaces.


Component specification tools

• The component specification contains all the information can be known about the component.

• The structural model gives an overview of the component structure and about the related components.

• The functional model describes the component functionality. Here should be defined the required and provided interfaces.

• The behavioral model defines the behaviour of the component. Here should be the pre- and postconditions given.

• The next figure shows a framework of a component specification. The framework contains further elements.

• Quality assurance plan

• A complete documentation of the component

• Decision model, which describes the built in variants of the component. These kind of variants are supported by the configuration interface (this will not discussed in details).

6.1.5. 6.1.2 Structural specification




Structural specification of the component

• Defines the methods and attributes of the component, the relations to the other components (clients and servers), and finally, the constraints of the component connections.

• Formerly, software projects did not use usually the structural specification. It became useful, when the model controlled development is introduced.

• A useful tool to show the interactions of the component with its environment.

• It has great difference compared to the structural model, which was introduced at the topic of the environmental map. It focuses on the system, instead of the environment.

• The next figure shows the structural model of the vending machine component.

• A good structural specification gives tips about the decomposition possibilities.


Example: Structural specification of the vending machine component

• Remember the structural model of the environmental map of the vending machine.

• Compare the two structural models.

• The abort method in the environmental structural model was defined alone. In the structural model of the component, abort is defined as a part of the SelectItem method.




Comparing the structural models through examples

• The main difference is how the methods of the vending machine are defined. In the structural model of the component, the realization of the methods are explained more detailed.

• The abort method in the structural model of the environmental map is realized as an input parameter of the SelectItem method specified in the structural model of the component.

• To keep consistent the two structural models, we can go back to the structural model of the environmental map, and register the changes, or a comment can be left at the corresponding place.

• We can go back to an earlier model at any time to register the newer designing decisions.

6.1.9. 6.1.3 Operation specification


Operation specification of the component

• The role of the operation specification is to define the effects of provided methods of the component, those can be seen from outside.

• The next table shows that template, which is offered by the KobrA method to this procedure (KobrA took this procedure from the Fusion procedure).

• The most important elements of the table are the Assumes and Result clauses, those are representing the pre- and postconditions of the methods. These are basically important at the validation of the methods.

• The pre- and postconditions are described in a declarative way, which means that it defines what the method does, while the question: how the method does that? is not answered here.

6.1.11. Operation specification template according to the KobrA method and Fusion



6.1.12. Operation specification of the Vending machine

6.1.13. 6.1.4 Behavioral specification




Behavioral specification of the component

• Object-oriented (OO) paradigm: as a first approach, data and functionality encapsulation.

• The object has states and state-transitions, those can be reached during the object life-cycle.

• The component paradigm encloses the principles of the object oriented technology, so it is based on these principles.

• Components may have states, or if it does not have any, then we can speak about a functional component, that does not have externally visible states and state-transitions.


Behavioral specification of the component

• The behavioral specification shows, how the component reacts to the external influences.

• It is made as UML state diagrams.

• It concentrates on the Assumes and Result clauses, those are given in the operation specification.

• If a component does not have any states (a functional component), then the behavioral model is not needed.

• The behavioral specification describes the behaviors of the component by its externally visible states and an external event caused state-transitions.

• A component may react to an external event in several ways based on its state.

• A transition or a state-transition is caused by an event, which is mostly a message arrived to the component. A transition may have a guard, which should be true, if a transition is executable.


Behavioral specification of the Vending machine

• The next figure shows the specification of the vending machine on an UML state-diagram.

• The table following the figure lists the corresponding states.

• The diagram and the table has more or less the same information. The diagram can be understood more easily, while the table can be easier processed automacally.



6.1.17. Behavioral specification of the Vending machine in the form of a state transition table

6.2. 6.2 Component realization

Component realization

6.2.1. 6.2.1 Component realization

6.2.2. Component realization

Component realization



• The component realization is a set of documents, those describe how to realize the component.

• It contains everything that is needed to do the specification based implementation.

• The higher level components can be realized using lower level components. These lower level components act like servers to the higher level components.

• The realization contains

• the subcomponent specifications, the required interfaces and

• its realization, which is the externally non-visible (private) part of the implementation.


Contents of documents of Component realization

• UML class and object diagrams, describing the structural model of the internal structure of the component.

• Specification of the algorithms of the component, as UML activity diagrams.

• UML sequence diagrams, describing the interactions of the component with the other components.

• The next figure shows an UML description of a component realization.



Structural specification of realization

• The structural specification of realization describes

• that kind of class types and their relations (UML diagrams), from the component is built, and

• the internal architecture of the component.

• The component we focus on in the class diagram, is labeled with "subject".

• The next figures show the realization of the VendingMachince component as an UML class diagram.



• The UML diagram represents the internal structure of the component.

• The structural model of realization is tipically a refinement of the structural model of the specification.



• At the level of realization some new elements are shown, those could not be seen at the level of specification, because they did not have meaning there.

• On the previous figure, some classes can be seen, those are

• not components, but classes representing the objects of the real world (e.g.: Timer) and

• subordinated objects, labeled as "Component".

• We may need the list of the sold items, and the list of the items can be sold. Because we want to represent the reality, it is an important part of the embedded system. The length of the list depends on the size of the dispenser, so a dependency relation is introduced on the diagram, pointing to the dispenser.



• We may also need a list of the possible coins, those can be accepted by the CashUnit.



• It can depend on the type of the CashUnit.

• The CashUnit comes from an external service.

• We can start to define the interface of some subcomponents, but it is a strongly iterative procedure, and it heavily depends on the third-party's component implementations.

• If we know the selected and implemented component, we can change the required interface of our component respectively.

• Some interactions among the components are discussed in details, while the others are not so specific.



• The definitions of the formerly shown figure can be refined in the following iterative way, depending on that the sight will be clearer according to the realization.

6.2.9. 6.2.3 Realization algorithms


Specification of the algorithms of realization

• The methods of the component are specified in details.

• Activity diagrams are created, with algorithms can be described. With the help of these diagrams the specified methods can be implemented.

• The next two figures show the UML activity diagrams of the insertCoin and selectItem methods.






• Compare the activity diagrams of the defined SelectItem and PurchaseItem methods.

• The SelectItem method introduces in a different and more detailed way, how the user select the item.

• The PurchaseItem provides more information for the user (about what happens), while the model of the SelectItem algorithm also defines the internal parts of the method, and also discusses how happens that.



• Some activities will be refined later, depending on how the collaborating components are concretized.

• E.g.: we are waiting for a sign, but the form of the sign is not defined.



• These are handled in private functions and are embedded into further models, e.g.: into the model of the structural realization and they are defined there similarly.

• How can we give a realization of the components in e.g. Java? This kind of modeling is early at this level, because later we may find some components, those are implemented in a different language. This case will limit the component reusability then.

6.2.14. 6.2.5 Specification of realization interaction


Specification of realization interaction

• The models of the realization specification introduce the progress of the control, from the view of some components.

• The interaction diagrams describe, how the groups of the component instances are collaborating in order to realize a function or a part of it.

• The next two figures show the UML collaboration diagram of the VendingMachine.insertCoin and VendingMachine.selectItem activities.

• For a low-level activity, it is not necessary to create all the activity and interaction diagrams.

6.3. 6.3 Summary

6.3.1. Summary



Summary

• We created the models of the top-level.

• We have concrete ideas about some subsystem, while we have less concrete ideas about the other subsystems.

• In the next steps

• we will searching for existing components, those are fulfilling our requirements, and then

• integrate them into our system.

• It fits to the embodiment step.

7. 7 KobrA - Component embodiment, Normal Object Form

7.1. 7.1 Component embodiment

Component embodiment

7.1.1. Component embodiment


• Component embodiment is the name of those activities, which lead from an abstract specification to a more concrete component, e.g. an executable or an installable component.

• At the top abstraction level, KobrA method handles the system as a single component.

• This top level component is decomposed into sublevel components, following the decomposition and concretization dimensions.

• Finally, the executable binary code is created.

• The next figure shows how this procedure works.






• The steps of the procedure can be automatized, e.g. a source code given in a high level programming language can be transformed into a binary code automatically by the compiler.

• The activity of transformation of a model into a program source code tipically requires a human, manual activity. The reason is that there is a big gap between the semantic descriptions of the model and the program source code (notations and their semantics are changing).

• The transformation

• input: UML diagrams

• output: program lines.

• This transformation is presented on the next figure.

7.1.4. Refinement and translation (Manual Translation) in a single step





• This information gap can be bridged so that the notions of the model are transformed to the notions of the selected programming language.

• It is easier for the object oriented programming languages, because these are supporting most of the UML notions.

• This gap can be bridged more difficult using traditional procedural languages.



• Doing manual transformation, such decision should be made often, those lead to a state, where the created software differs from the model.

• This fact undermine the legitimacy of the model based approach. The reason is that the design procudere is made on the top level, which is a draft of the system and the implementation decisions are made based on this draft.

• This situation is getting worse by the decisions, those are usually not documented in the higher level models.

• In the following a solution is shown, which fill this gap.

7.1.7. Component embodiment - SORT technique

SORT technique

• Users of the KobrA method mainly use the Systematic Object-Oriented Refinement and Translation (SORT) technique at this phase of the embodiment.

• SORT technique is based on two basic principles:

• the refinement and compilation should be strictly separated and distinguished.

• use the Normal Object Form (NOF) implementation profile to minimize the information gap between the object-oriented models and the given object-oriented being created program.

7.1.8. Component embodiment - SORT technique

Refinement and compilation

• The refinement is a relation between two different description of the same thing. More exactly, the refinement is a more detailed description of the same thing on a different level.

• The compilation is a relation between two different description at the same level.

• Mixing these two approaches in the software development project lead to an over-complicated representation of the system. In worst case, the final system does not fit to the model.

• The refinement and the compilation should be handled separately, like unique activities, as shown on the next figure.

7.1.9. Refinement and translation in two separated steps





• Phylosophy: in the first step, refine the models into models in a previously defined level, and in the second step transform these models into source codes.

• A potential problem may occur. How to define that level of detail, which is fine enough to start the transformation and get the source code?

• This problem can be solved using implementation patterns.

• Such implementation pattern is the Normal Object Form (NOF).

7.2. 7.2 Normal Object Form

Normal Object Form

7.2.1. Normal Object Form

Normal Object Form

• UML profiles can be defined upon several motivations.

• Testing profiles

• Implementation profiles

• E.g. the Java implementation profile describes the standard language elements of Java in UML.

•

• NOF is an implementation profile, which projects the UML to the basic (core) notions of the Object Oriented languages. Later, this core-description can be refined to each programming language, like Eiffel.

7.2.2. Normal Object Form

Elements of NOF

• A subset of UML, which can model the elements of the implementation level.

• Such new modeling elements, those are based on UML stereotypes.



• Constraints on the existing and new modeling elements.

• NOF models are valid UML models. The difference is that UML models are only close to the Object Oriented concepts, while NOF also supports the model based designing of the written Object Oriented programs.

7.2.3. Normal Object Formt

Usage of NOF

• NOF models give a graphic representation of the OO programs. These representations are close to the form of the source codes, so they can be automatically transformed to the given programming language.

• NOF supports well the model controlled, architecture based software development concept of the Object Management Group.

• Literature

• C. Bunse and C. Atkinson. The normal object form: Bridging the gap from models to code. In 2nd International Conference on the UML, Fort Collins, USA, 1999.

7.2.4. SORT

The advantages of SORT

• The Systematic Object-Oriented Refinement and Translation (SORT) technique greatly improve the process of embodiment, when followings are satisfied:

• Do only small steps

• A sequence of smaller steps can be understood more, than a big, complex step.

• The SORT technique makes possible to split the implementation of the graphic model into a sequence of refinement and traslation steps.

7.2.5. SORT

The advantages of SORT - cont.

• Separate the problems

• developers should concentrate on only one task

• doing so, the refinement steps preceding the translation, can be found easier.

• Identify and use the similarities

•

• SORT supports the creation of different implementations.

• Creating a new implementation is usually a difficult task. SORT reduces greatly this difficulty, because developers only need to retranslate the previously created model (in NOF form) of the component.


Component reusage

• Component reusage represents activities close to the composition/decomposition and



abstraction/concretization dimensions.

• A reused component usually not exactly fit to the specification.

7.2.7. Component embodiment - Component reusage

Possible solutions to component reusage

• Change the model to eliminate the differences

• It is not intended, while its concept is the opposite of the component based software development concept.

• Rewrite/modify the reused component

• Not a good idea, because it is too complex and sometimes impossible.

• Introduce an adapter component, which projects the interfaces onto each other

• Usage of wrappers

• Several component techniques have services, called syntactic projections.


Semantic projections

• The real solution is the semantic projection between the entities, those are in relationships.

• Semantic projections translate the thinks of a component to a form, that can be understood by the other component.

• The name of this kind of wrapper component is glue code, which usually encloses a server component into a unit.


Creation of a new component

• If the corresponding component could not found, then it should be made by us.

• In this case, further decomposition steps are needed to find the fitting implementations.

• After this, we can step back again to the integration step to integrate the newly implemented components.


Example - CashUnit

• Assume, that we did not find a corresponding component on the market for our vending machine, which can fulfill the requirements and play the role of a properly working CashUnit.

• In this case examine, whether we can find such components on the market from we can build our CashUnit component.

• Assume, that we found four components on the market, from those the CashUnit can be built (see next figure).

• The next figure shows only those parts of the vending machine, those are involved at this design refinement



step.

• To develop the CashUnit component, the same development steps should be made, those are also performed to the VendingMachine component.

7.2.11. Containment hierarchy for the CashUnit

7.2.12. Component Of The Shelf

COTS component integration

• An existing component can be reused easiest, when the specifications are equivalent, so the specifications of the required component and selected components for usage are equivalent.

• The left side of the next figure shows that general case, when user does the development using these considerations.

• Opposite to the left side of the figure, the right side shows that case, when there is a syntactic and semantic difference between the required and provided interfaces.

7.2.13. Custom-designed vs. third-party component integration


Conformance map

• The conformance map helps the integration of the components, which



• describes the visible properties of a COTS component by a projection, which defines the relation between the notations used at the COTS component development and the notations used by us.

• This projection can only be applied, if the information is correct and total in about the structure, behavioral and functionality in the documentation of the component, that is being reused.

• These information usually exist for a component, but the information can be split in a distributed system, so it is often hard to collect it and define the projection.

• It can be deciced, whether a component fits to our needs only, when the conformance map can be assembled and the interfaces are comparable.


Semantic map

• If we decide to reuse a component after the conformance map is assembled, then the next step is to create the semantic map.

• The semantic map concentrate on the similarities and differences of the two components (the designed one and the reusable one) and try to model the projection between the two different interfaces.

• In practice, it is a specification of a wrapper component, which encapsulates the COTS component.

• In general case, this component is called adapter and it can be defined using the development principles of KobrA.

8. 8 System development from "Off the shelf" components

evelopment

8.1. 8.1 Components of the Shelf

8.1.1. Components of the Shelf

Motto "The food is organized so great that somebody must have touched all of it".

(Julia Child, The modern kitchen art)


Components of the Shelf

• Nowdays, the "of the shelf components" are getting into foreground when complex systems are being developed.

• Main reasons:

• Economy The final product costs less time and manpower, so less money.

• Lack of expertise The specialization is so high at each scientific scope that it is difficult and expensive to employ the corresponding experts.




Concept

• COTS means a software bundle, which has large functionalities and it is easily accessable.

• The interior parts remain invisible, only its functions and its interfaces are public.

• We have to keep in mind that the components are probably created not to our problem.


Consequences

• COTS components are changing not only the process of software development, but also embodies architectural (and quality) constraints.

• The "architect" should be sure that the constraints are acceptable and they not lead to incompatibilities.

• In this lecture we will inspect how the ready to use components are affecting the architecture of the designed system.

8.1.5. 8.1.1 Example


Example

• Quack.com is a company, that is specialized to provide content and business services through telephones.

• The example illustrates the usabilities and limits of the "of the shelf" components.

• There were already other companies developing the same services (with better financial background), so Quack.com had the only chance that they release their product first.


Example - cont.

• They browsed among the existing (relevant) "off the shelf" components and they saved a lot of time. In some cases, more than one company offered components to a given function.

• The strategy worked, they released the product first and the AOL bought it. To deal with the increasing load (influenced by the increasing amount of customers), they have rewritten some components on the fly, where it was necessary.

• The flexibility of the architecture made it possible to replace components easily, but it was questionable how components are reacting.


Example - cont.

• One of the developers said:



• When a function was not significant, we used COTS.

• When we found that our system should follow a standard, then we also used COTS there (because the solution on the market should exist).

• When we were uncertain about the reliability or the quality of a component, then we created it.


Disadvantages

• COTS does not allow for developers to fully control the whole system.

• The "contract" concept of Bertrand Meyer eliminate this disadvantage.

8.1.10. 8.1.2 Effects of the components


Effects of the components on the architecture Assume that we have to create a software which checks the processes of a chemical firm. The states of the chemical processes are interpreted by sensors and the information are transmitted to a special display of the operator. One of the software functionality is to draw the models of the methods onto the display. A software company offers a component, which implements this drawing functionality. We buy this product, but later becomes clear that the modul exists only in VisualBasic language.


Effects of the decisions on the architecture

• We may need to reimplement the complete system in VisualBasic, because the component uses VisualBasic specific functions to control the drawing. An other possibility to detach the complete operator part from the other parts of the system.

• It is a basic structural decision, which is caused by a small selected component.


Disregardness

• Even a simplest component has a kind of architecture inside, and it can be disregarded really difficult.

• E.g. an HTTP server assumes a client-server architecture with well-defined interfaces and in the background some functions.


Consequences

• The interactions of the components are really important to understand them, before the architecture becomes fixed.

8.1.15. 8.1.3 Architectural differences




Architectural difference - 1.

• Not all the components can cooperate, even if they are commercial products and the manufacturer stands that they are compatible. Components are usually almost compatible, which means, they are not compatibles.

• Incompatibilities may come from really small bugs, like timing in a parallel system or bad assumptions about the sequentiality.



• Garlan, Allen and Ockerbloom called this problem as architectural difference, which can be taken as a difference of the assumptions, those are realized in the components. This case usually becomes problematic at the integration phase or sometimes even later.

• What are these assumptions?



• Assumptions can be:

• The provides assumptions describe the set of services provided to users and customers.

• The requires assumptions explain the details of services, those are necessary to the correct functionality of the component.

8.1.19. Components of the Shelf - Architectural difference

Custom-designed component integration vs. third-party component integration.


What to do, when differences exist?



• The problem in yesterday now is a built-in property of the system. (Like it is not bug, it is a feature!) It is often a possible solution.

• Try to avoid differences by selecting carefully the components with specification check.

• Notice the unavoidable cases by selecting carefully the components.

• Fix the noticed cases by the adaption of the components.


Techniques to resolve differences of interfaces

• Wrapper Using a wrapper is a kind of encapsulation, where the component is hidden behind an alternative abstraction.

• Bridge Bridge transforms the requires assumptions of a component to the provides assumptions of an other component. The difference of the wrapper and bridge is that the bridge is independent from the given component.

• Broker Broker applies the method of the bridge in runtime.


Example - Difference between bridge and broker

• Assume that a component generates data in D form, while an other can consume data in D form.

• Assume that no direct D D bridge is existing, but we have D D and D D bridges and they can be linked.

• The broker creates a D D transformation from the bridges above.

8.1.23. Components of the Shelf - Architectural difference

Third-party component integration with adapter.


Techniques to explore differences of interfaces

• Creating a conformance map



• Describes the visible properties of a COTS component using a projection. It gives the connection between the notations used during the development and the notations used by us.

• Creating the semantic map

• If we decide positively about a component reusage after the conformance map is created, then we have to create the semantic map.

• Semantic map focuses on the differences and similarities in the specifications of two components (the designed and the reusable) and try to model the projection between the different interfaces.

8.1.25. 8.1.4 Designing as browsing components


Component-based designing as searching - 1.

• Now, we can determine that component-based development is a searching process, where we want to find the elements of our system.

• The system architect should make decisions at each components considering the system requirements, whether the component can be integrated into the system architecture.



• Each element is added to the path being adventured. This adventure mainly focuses on the non-adaptable architectural differences, but also consider the effects of the fixes and disregards.

• Iterating several paths at the same time is expensive, so the iteration in practice it is limited to a primary and some secondary paths.



• We apply a model problem to the evaluation and quality guarantees of the components. Model problem is a description of the implementation constraints (e.g. the Web based interface should be able to be used either by Netscape and Explorer).

• The prototype which fits to the design pattern is called modell solution.

8.1.29. 8.1.5 Session of Model problem in 6 steps


The session of the model problem in 6 steps

• The architect and the engineers identify the design suggestion we have to start from.

• The architect and the engineers define the starting evaluation criterias. It describes, what is a good and what is a wrong solution.

• The architect and the engineers also define the constraints of the implementation.



• Engineers create a problem solution.

• Engineers identify the ending evaluation criterias (the starting and the newly introduced ones).

• The architect evaluates the model solution, whether it satisfies the ending criterias or not.

8.1.31. Components of the Shelf - The session of the model problem

8.1.32. 8.1.6 Example - ASEILM


Example - ASEILM

• The example is a Web based information system, which was developed by a Software Engineering Institute (SEI) to automatize the administrative communications between the institute and its partners. This system was called ASEILM (Automated SEI License Management).

• Tasks of the ASEILM system

• Support the distribution of the SEI's products.

• Collect statistical information.

• Create charts about

• the income,

• the number of visitors of the website,

• other information related to the SEI's products.

• Trace the attendance of the SEI courses and the licence fees.


Functions of ASEILM

• Provide several rights to the different users.



• Functions:

• For organizers of the courses

• Lists of the participants,

• Maintain contacts with the participants,

• Download course related documents.

• For leading evaluators

• Help evaluation with input data, and with the downloading the evaluation forms.

• For SEI administrators

• Maintain the list of the leading evaluators and authorised course managers.

• Support the system maintenance with all possible tools.

8.1.35. ASEILM - Quality Attribute Requirements

8.1.36. 8.1.7 ASEILM - Miva Empressa


Miva Empressa

• The developer team had some preliminary knowledge about the Microsoft IIS extension.

• The Miva Script application are running under the Miva Empressa control.

• The next figure shows a composition with the Miva Empressa, which was used in the ASEILM project.

• The composition also contain some additional off the shelf components.

• Microsoft Access - database functionality

• Visual Mining's Charts Works - diagram drawing functionality

• Microsoft IIS - HTTP server

• Windows NT 4.0 - operating system on the server.



• Clients can use any browser on any platform. The initial composition contains:

• Netscape browser

• Windows operating system

8.1.38. Components of the Shelf - Miva Empressa ensemble

8.1.39. 8.1.8 Miva Empressa - System Model


Creating the system model

• 1. step Identify a Design Question

• The system (composition, component) related hypotheses are introduced as use cases.

• 1. hypothesis. The component provides Web based access to do data maintenances in the Access database. It displays user requested data as charts.

• 2. hypothesis. The communication is secured between the browser and the HTTP server using the HTTPS protocol.



• 1. step Define Starting Evaluation Criteria. The model evaluation should be made based on the previously introduced hypotheses.

• 1. Criteria. The model really displays the data stored in the Access database.

• 2. Criteria. The Web browser gets truly secured data through the HTTPS connection.





• 3. step Identify Implementation Constraints. These constraints contain the strict constraints from the view of development.

• We do not have such constraints in our case.

• 4. step Produce Model Solution. After the problem is completely defined, the development team began to create the model. Meanwhile, two additional problem are introduced. Data should be transmitted to the ChartWorks component in order to display the charts. How to do this in a safe way?

• How to connect the data and the charts.

• How to keep alive the secure connection between two components.

• The last problem is solved using a perl proxy server (see next figure).

8.1.43. Components of the Shelf - Introduction of Proxy server



• 5. step Identify Ending Evaluation Criteria.

• 3. Criteria. The maintenance of the presentation logic should be made through a well defined interface, that is independent from the business logic and the database logic in the background.

• 4. Criteria. Database should be stored behind a firewall, in a safe place.

• 5. step Evaluate the Model Solution. After the model solution is implemented and the newer criterias are defined, the architect can do the evaluation of the solution against the criterias.


Miva Empressa

• The result of the evaluation was not a surprise for those, who had known the Miva Empressa composition: the composition was inappropriate to create a component which solves the problem, because it will not be able to satisfy the newly introduced two criterias.




Miva Empressa The correct solution is created using a JAVA Servlet. The next figure shows this composition.

8.1.47. Components of the Shelf - JavaServer Pages ensemble


Miva Empressa The success needed a new custom component layer (see next figure).

8.1.49. Components of the Shelf - Layers of custom component

8.2. 8.2 Summary

8.2.1. Summary

Summary

• As an edification of this lecture we can determine that creating a system based on existing components needs



some other practices in front of creating our own components.

• The interfaces of the existing components and the relations among them strongly influence the architecture of the system being created.

• If we do not have sufficient practice to create systems like these, we may face with the problem relatively late (even if we were careful) that system can not satisfy the criterias.

9. 9 SYNTHESIS Tool

9.1. 9.1 SYNTHESIS Tool

9.1.1. SYNTHESIS A Tool to assembly automatically a correct, distributed component-based system

Introduction

• Composing a system from "Off the shelf" components may raise several problems. These problems are related to the communications and compatibilities of the components.

• Interactions of components are often not compatible, so we need to extend the behaviour of our system with the more exact interactions of the components. It may involve additional functionalities and more dependencies.

• SYNTHESIS tries to manage these problems.

9.1.2. SYNTHESIS

Introduction

• By using the SYNTHESIS tool

• incompatible component interactions can be avoided

• communication protocols can be improved by creating a corresponding coordinator.

• This coordinator is a glue code.

• SYNTHESIS tool deduct the corresponding glue code to the set of the system components, from the specification of the system. This deduction is made in two steps. At first, an initial glue code is created and then a restricted version of it.

• The restricted glue code realizes a software coordinator, with we can exclude the incompatible interactions. It also serves as an improvement of the composed system from the view of the protocols.

• The restricted coordinator is a composition of the new coordinators and the new components. A new component is a wrapper component.

9.1.3. 9.1.1 COM/DCOM

9.1.4. SYNTHESIS

COM/DCOM



• The SYNTHESIS tool can be used to

• deduct a platform dependent code of the current coordinator or to

• derive the behavioral model (state machine).

• The first version of the SYNTHESIS tool supported the Microsoft COM/DCOM platform, while the next version is already supporting the EJB platform.

9.1.5. SYNTHESIS

COM/DCOM

• A COM/DCOM application is based on a client/server architecture.

• A COM server is basically a type library

• A type library is a container of the objects defined by the server component, while the objects are instances of a COM class.

• Client can reach the services of the server via a COM class defined interface.

• A COM/DCOM server may have several interfaces via a COM class. In other words, COM/DCOM can serve different interfaces to a component.

9.1.6. SYNTHESIS

COM/DCOM

• The interface is a binary structure in an address space of a component. The structure of it is described with a table, which contains pointers to functions.

• A client can reference to an interface pointer.

• All the interfaces of the callable functions are defined this way. Interfaces may have own types and those can be inherited.

• All the interface types can be organized into one inheritance hierarchy.

• The type of the root is IUnknown.

9.1.7. SYNTHESIS

COM/DCOM

• In COM/DCOM interface types are notated by the MIDL, which is a Microsoft extension of the standard DCE/IDL.

• A client can call a method of the server using the information contained in the Type Library.

• A Type Library specification is defined by the MIDL code. A Type Library is a binary version of a MIDL file, which stores the interface of a component in a binary form.

• COM uses two approaches related to the component reusage:

• Containment/delegation

• Aggregation.



• Aggregation is not a generally used composition mechanism, so we discuss only the containment/delegation mechanism.

• To identify the server, COM/DCOM links a Globally Unique IDentifier (GUID) to each component interface.

9.1.8. SYNTHESIS

Windows Registry

• All the necessary information are stored in the Windows Registry, that are needed for COM/DCOM to identify a component.

• The Windows Registry contains the following information about a component:

• place

• type library

• interface

• execution and access grants.

• The Windows Registry is a hierarchic tree structure. Its root is identified as Windows Registry, while the subtrees are called hives.

• A hive contains several keys, while a key can contain one more subkeys, and so on.

9.1.9. 9.1.2 Applied architecture

9.1.10. SYNTHESIS

Type of the applied architecture

• We use a special architecture, where a component can request services from the underlying components and also can notify components lying above.

• We assume that each component has a top and a bottom interface.

• A top (bottom) interface of a component is a set of its top (bottom) ports.

• The connectors between the components are synchronous channels, and a channel is defined with a top and a bottom port together.

• Components can communicate by sending messages:

• Request (down)

• Notification (up).

9.1.11. SYNTHESIS

Type of the applied architecture

• Two kinds of components can be differentiated:

• Functional component

• Realizes the functionality of the system.



• Coordinators

• Path messages.

• Inside of the aboves, we differentiate two architectures

• Coordinator-Free Architecture (CFA),

• Coordinator-Based Architecture (CBA).

• The next figure shows the two architecture types.

9.1.12. SYNTHESIS

Figure 1. A sample of a CFA and the corresponding CBA

9.1.13. 9.1.3 Formalization of configuration

9.1.14. Formalization of the configuration

Formalization of the configuration

• A specification of a system can be given in two ways

• High-level Message Sequence Charts (HMSCs)

• basic Message Sequence Charts (bMSCs)

• We inherit from the specification to each component a Labeled Transition System (LTS).

• A composition of components can be defined by LTS descriptions lying in parallel, hiding those activities, those are enforcing the synchronization.

• It defines a coordinator-free architecture of a set of the components.

• A coordinator-based architecture can be derived simply from the coordinator-free architecture by inserting a no-op coordinator between each communicating component pair.

• The no-op coordinator does not do anything yet.

• Later, it will have functionality based upon corresponding information that it will control the interactions of the components.


Message Sequence Charts (MSC)



• It can describe the typical and special messages of the different entities (components) in a standard way.

• Using MSC charts, system communications can be described with message sequences.

• SDL language like standard.

• MSC and SDL descriptions can be taken as complementer views of the system.

• With SDL, we can describe the behaviour of custom communicating entities, without describing the communication between them.

• With MSC, we can describe the happenings of a system with message sequences. MSC is a really simple, but very efficient notation to describe protocols.


basic Message Sequence Chart (bMSC)

• A Basic Message Sequence Chart (bMSC) contains a description of the asynchronous communication between instances. Additionally local actions can be specified on instances.

• An instance is an abstract entity of which one can observe (part of) the interaction with other instances or with the environment.


Figure 2. bMSC specification


High Level Message Sequence Chart (HMSC)

• The most simple HMSC is a BMSC, as in Figure 2. The purpose of the compound HMSCs is to describe the relations between the MSCs contained in a graphically attractive way.

• A compound HMSC consists of a collection of components, enclosed by a frame.

• The components are thought of as complex MSCs that operate in parallel. Every component consists of a number of nodes and a number of arrows that imply an order on the nodes.




High Level Message Sequence Chart (HMSC)

• We make a distinction between three kinds of nodes.

• Every component has exactly one start node, indicated by an upside-down triangle.

• Further, it may contain a number of end nodes, indicated by a downside-up triangle, and several HMSC references.

• An HMSC reference consists of a frame with rounded corners enclosing the name of the referenced HMSC.

• We require that within a component every node (including the end nodes) is reachable from the start node. Figure 3. shows an HMSC.


Figure 3. HMSC's specification of the CFA system


Description of the method

• SYNTHESIS consists of the phases

• In the first phase, the specification of the system is restricted so that it should be deadlock-free.

• We synthesize a so called initial coordinator.

• In the second phase, we introduce smarter interactions between the components.

• A restricted coordinator is created from the initial coordinator.


1st phase: creating an initial coordinator

• The specification of the system should be given with bMSC and HMSC charts.

• Figure 4. shows the main steps of the first phase of SYNTHESIS method

• 1. step: synthesize a no-op coordinator starting from a given CFA architecture. The result is a TLS, that



models the global behaviour of the no-op coordinator.

• This step consists of several basic steps, those are not discussed here.

• 2. step: The result of the 1. step is a CBA (an LTS), that should be analyzed against deadlock cases. It is performed by running deadlock detector and an anti-deadlock procedure. The result of this step is a deadlock-free coordinator.

• 3. step: the creation of an initial coordinator from the deadlock-free coordinator.


Figure 4. First phase method


SYNTHESIS method - 2nd phase

• The result of the first phase is a V, deadlock-free CBA system, which satisfies only the required behaviour P.

• E denotes a set of constraints of the coordinator protocol in bMSC and HMSC form.

• This system V is the input of the second phase, which provides the system V' after two additional steps. V' satisfies the enhanced protocol, which is deadlock-free and it also satisfies the required behaviour P.

• The second phase consists of two steps (see Figure 5.).




Figure 5. Second phase method

9.1.26. 9.1.4 SYNTHESIS method

9.1.27. SYNTHESIS method

SYNTHESIS method

• In the second phase, SYNTHESIS executes as first step the protocol constrains declared in E, considering P and V (see Fig. 5).

• This is an insertion of a wrapper component W between the initial coordinator and, that part of the V, which part is involved in the protocol enhancement (C2, C3 and the K subcordinator).

• Wrapper W catches the messages transmitted between K and C2 and C3. It also embodies the constraints declared in E as it follows the behavioral interactions executed on channel 2 and 3. (K coordinator is split.)

• The two behavioral models of the wrapper W can be automatically deducted from the bMSC and HMSC specifications of E. The result consists of two AC graphs. These graphs are denoted W.1 and W.2 in Figure 5.


SYNTHESIS method

• Cont.

• W.1 represents the behaviour of W, which is related to those interactions of the component, those are affected by the constraints.

• W.2 is the behaviour of W, which belongs to the interactions related to K.

• Finally, we can automatically deduct the new coordinators K.1 and K.2.

• K.1 is the coordinator between the component and W.1.

• K.2 is the coordinator between K (SubK) and W.2.




SYNTHESIS method

• In the second step of the second phase we deduct the realization of the synthesized glue code. In practice, the codes of K.1 and K.2 are created.

• In the figure, K represents the constrained coordinator, which is a parallel composition of K, K.1, K.2 and W.

• The above description is an outline of the SYNTHESIS method. In the following, the SYNTHESIS tool will be introduced.

9.1.30. 9.1.5 SYNTHESIS's architecture

9.1.31. SYNTHESIS - Architecture

Architecture of SYNTHESIS

• Next figure shows the architecture of the SYNTHESIS tool and its main software modules and their relations.

• Similarly to the previous chapter, the architecture will be described with two main phases.


Figure 6. SYNTHESIS architecture

9.2. 9.2 1st Phase


Architecture of SYNTHESIS - 1st phase

• Figure 7. shows the input/output data of the SYNTHESIS in the first phase.

• Capital signs in brackets show the relation between the previous two figures.

• The next example will show how SYNTHESIS modules realizes the previously introduced method.




Figure 7. Input and output data performed by SYNTHESIS within the first phase

9.2.3. 9.2.1 Architecture - Module A


Module A - Component interface analyzer

• This module contains a superclass, which is identified as IDLParser in the figure, that shows the SYNTHESIS architecture.

• It analyzes the input IDL file.

• This superclass can be specialized according to several platforms

• MIDLParser for the COM/DCOM platform.

• IDLParser analyzers of other platforms.

• We note that the next version of the tool also contain a JavaIDLParser for the EJB platform

9.2.5. 9.2.2 Architecture - Module B


Module B - Specification of the CFA and HSMC

• This module is used to create the specification of the CFA system being composed, using bMSC and HMSC charts.

• It contains an ad-hoc library to help the creation, validation and manipulation of the bMSC and HMSC charts given in XML.

• An XML file validity is checked also by an ad-hoc XML schema.


Example

• Take a CFA system T, which consists of three components:

• Client1



• Perform a request (req) and wait for a succeeded (ok) or an error (err) response.

• Client2

• Perform a request (req) and never handles the error.

• Server

• Accept the requests, and replies with ok or err message.

• The next figure is a screenshot of SYNTHESIS, where a bMSC specification of the CFA system T can be seen.

• Vertical lines represent instances of the component, while horizontal lines represent a request or a response.


Figure 8. bMSC specification


Example

• Figure 9. is also a screenshot of SYNTHESIS about the HMSC specification of T.

• Each HMSC chart describes a possible continuation of a scenario.

• An HMSC is a graph, that has a start and maybe an end node. All the other nodes are representing a scenario or an embedded HMSC chart.




Figure 9. HMSC's specification of the CFA system

9.2.11. 9.2.3 Architecture - Module C


Module C - Component condition generation

• The input of this module is the specification described in module B.

• This module generates the component AC-Graphs in XML as a result from the specification of the example (see Figure 8. and 9.).

• Figure 10. is a screenshot of SYNTHESIS, that shows the AC-Graphs of Client1, Client2 and Server.

• Each node is a state of the component instance.

• Each labeled edge is a transition to the direction of the arrow. The label can note an output activity with ! or an input activity with ?.


Figure 10. SYNTHESIS's screen-shots of Server, Client1 and Client2 AC-Graphs




Module C - Component condition generation

• AS- and EX-graphs related to the component are also produced by this module.

• These graphs are illustrated in Figure 11. and 12.

• AS-graphs are the symmetric correspondents of the AC-graphs and they model that environment, how components are assuming it.

• EX-graphs are refinements of the AS-graphs and they represent the behaviour, which is required by the component from the initial coordinator.

• The coordinator performs strictly sequential input/output methods. If it takes an input from a component, then it sends it to the target component and vice versa, so if a coordinator sent a message, then it should got it as an input directly before.


Figure 11. SYNTHESIS's screen-shots of Server, Client1 and Client2 AS-Graphs


Note

• If a label of a transition is ? in the AS-graph, then two strictly sequential transition appears with labels ? _i and ! _# in the corresponding EX-graph.

• If a label of a transition is ! in the AS-graph, then two strictly sequential transition appears with labels ? _# and ! _i in the corresponding EX-graph, where i is a reference to the C component.




Figure 12. SYNTHESIS's screen-shots of Server, Client1 and Client2 EX-Graphs

9.2.18. 9.2.4 Architecture - Module D


Module D - Specification of the coordination policy given with B

10. 10 Object lifecycle, Temporal logic

Object's lifecycle Based on the work of Constantin Arapis A specification method

10.1. 10.1 Object's lifycycle

10.1.1. 10.1.1 Introduction

10.1.2. Object's lifecycle

Introduction

• A specification methodology is introduced, which is

• sufficiently abstract and

• providing a tool for designers to express both the

• static and

• dynamic properties.

• Our goal is to support the relation database based applications.

• The CAD, CASE and AI extensions of the applications of databases caused the appearance of new data models.

• These data models supported the modeling of entity descriptions with complex data structures and

• the description of the relations between the entities.




Introduction

• Main properties

• apply data abstraction

• describe the behavioral abstraction

• Example

• System TAXIS was the first model, that had both the above properties.

• The appearance of object oriented approach in the database applications lead to the development of the temporal logic based models.

• We show a model, which is based on propositional temporal logic (PTL).

• PTL formulas are used to specify the life cycle of the objects.


Motivation

• Object oriented approach is a bottom-up software development at first sight. The key of this technology is the following:

• Define the required objects.

• Find the corresponding software base and build the missing objects from the given base.

• Finally, specify how the objects are cooperating to do the task.

10.1.5. 10.1.2 Technology characteristics


Characteristics of the technology The software base should built up from object classes.

• Support the design decisions

• Contain the special information of the given application

• It is difficult to create such technology supporting information system, because the structures of the stored information are heterogenous, so it is hard to store or query them.

• Other important problem is the description of the behaviour of objects, because a good descriptor tool can greatly improve the reusage of the objects.

• Such descriptor tool should provide tools to

• specify the behaviours of objects

• describe the interactions of the objects

• express the interactions of the objects and their environment



• coordinate the objects, in other words, to express the dynamic properties of the objects.

10.1.7. 10.1.3 Proposition Temporal Logic (PTL)

10.1.7.1. 10.1.3.1 Past operators


Proposition Temporal Logic with past operators


Proposition Temporal Logic with past operators

10.1.9.1. 10.1.3.2 PTL syntax


PTL syntax Given:

1. P = the set of atomic propositions



2. non-temporal operators:

3. temporal operators: , S

Formulas are formed as follows:

1. An atomic proposition is a formula.

2. If f and f are formulas then (f ), f , f f , f f , f f, f f are formulas, and f , f , f , f f ,

f , f , f , f , f f are formulas.

3. Every formula is obtained by application of the above two rules.

10.1.10.1. 10.1.3.3 PTL semantic


PTL semantic Let be an infinite sequence of worlds, and : P an assignment function, assigning to each atomic proposition a subset of W, where W, and W is the set of all worlds for the set of atomic propositions P. The satisfiability of a formula f in a world W of a sequence is denoted by f and can deduced by the following rules


PTL semantic

A formula f is initially satisfied or simply satisfied by a sequence if and only if f. A formula f is satisfiable if and only if there exists a sequence satisfying f. Such a sequence is a model of f. A formula is valid if and only if it is satisfiable by all possible sequences.


Figure 1. Examples of PTL well-formed formulas. (p q)

(p q)

(p (r q))

(p ( q r) r)



10.1.14. 10.1.4 Model


The model

• Elements

• Objects

• Represent the entities of a given problemset. Each object has custom properties, which differs the object from the others. The object identity is noted as oid.

• Messages

• Objects are communicating by sending messages. Each message has a sender and a receiver.

• A message means that the sender would like make the receiver to do an activity.

• An object may have several states, that is invisible to outside.

10.1.15.1. 10.1.4.1 Roles and contexts


The model - Roles and contexts

• A role indicates a special behaviour of the object during a specified time interval. An object can play several roles in its life.

• A context is a set of roles an object can play in its life.

10.1.16.1. 10.1.4.2 Activities and environments


The model - Activities and environments

• Activities are dynamic entities we can create or destroy following predefined rules. The participating objects of an activity are called agents.

• Example for an activity: TAKING_OFF

• Agents of the TAKING_OFF activity

• Airplane

• Control-tower

• When an object O becomes agent G in an activity A, then we say that object O represents agent G in activity A.




The model - The environment

• Environment describes the connections, relations between activities, and the connections between the activities and the objects inside of them.

• An environment is

• a set of activities and

• a set of constraints.

• Constraints belonging to an environment define

• the expected condition when an object can become a part of an activity

• the sequence of the execution of the activities and

• the flow of objects between the executions of each two activities.

10.1.18.1. 10.1.4.3 Roles


The model - Roles A role consists of four part

• Public messages: contain the names of messages can be sent to any object.

• Abstract states of the role

• E.g. the abstract states of a car

• Moving_fast

• Moving_slowly

• Stopped.

• Set of PTL formulas, that describes the constraints belonging to the abstract states and public messages.

• The fourth part contains instance variables and the concrete code, which realizes the public and hidden messages.

10.1.20. Figure 2. The AIRPLANE role specification



10.1.20.1. 10.1.4.4 Representation of roles


The model - Representation of roles We can represent roles as tuples of the form

[role_name, {msg , msg , ...}, {state , state , ...}, {cstr , cstr , ...}]

where the msg are public messages of the role, the state are abstract states, the cstr are temporary constraints and is the set containing all roles. We assumer that no two tuples belonging to

have the same role-name. In each world of a sequence of state and public messages we require only one atomic proposition to be satisfied and all others unsatisfied. In other words only one message at a time can be sent to an object. This is expressed in PTL as follows:

m m m




Figure 3. Examples of legal and illegal state sequences

Examples of legal and illegal state sequences In figure 3 some sequences of public and state messages relative to the role AIRPLANE are depicted. The first two are legal sequences satisfying the temporal constraints in figure 2, the last one is illegal since after enter_In_air the message lock_doors is sent.

10.1.22.1. 10.1.4.5 Contexts


Contexts A distinctive feature of our model is the ability of an object to play several roles during its lifetime. We represent an object playing a set of roles as a tuple of the form

[oid, {r , r , ...}] and r

where oid is the object identifier, r are roles played by the object at a given instant and is the set containing all objects. The extension of an object is the set of roles played by the object at a given instant.


Contexts An object cannot play any role at will. At instantiation a particular context should be specified within which the object will evolve and thus be constrained to play roles belonging to that context. A context consists of two parts. One part is a set of roles. The other part is a set of temporal constraints. A context's temporal constraints include constraints on:

1. legal sequences of role playing,

2. temporal relationships between messages and role playing,

3. legal sequences of messages belonging to different roles within the same context.

10.1.24.1. 10.1.4.6 Role playing


Role playing Messages and constraints of a particulat role can be sent, and respectively verified by an object, what that role is currently played by the object. Role playing is modelled by two predefined messages for each role. These are "start_" and "stop_", suffixed with the name of the role. They can appear within context constraints but not within role constraints. Let E be the extension of the object before the message is sent and E' its extension the instant after. Then sending these messages has the following effect:

1. if start_role is sent: E' = E {role}

2. if stop_role is sent: E' = E {role}

In other words message stop_role and start_role modify the extension of an object and therefore modify the set of messages to which it can respond as well as the set of constraints which should be verified for the object. Figure 4 shows the context PLANE_LIFE grouping roles PLANE, ON_GROUND, FLYING, AUTOMATIC,



MANUAL, and MAINTENANCE relative to the life of an aircraft. Constraints associated to that context are shown in figure 5.


Role playing - continued

That a particular role is currently played by an object can be expressed with the following formula of PTL:

stop_role start_role start_role

The above formula says that the message stop_role should not have been sent since message start_role has been sent and message start_role should have been sent sometime in the past. In what follows,

whenever the name of a role is found within a temporal constraint is intended as a shorthand of the above formula, that is:

role stop_role start_role start_role )

10.1.26.1. 10.1.4.7 Example - Airplane

10.1.27. Figure 4. Lifecycle context of Airplane

10.1.28. Figure 4. Lifecycle context of Airplane - continued



10.1.29. Figure 5. Constraints relative to the context PLANE_LIFE

10.1.29.1. 10.1.4.8 Notations


Notations

• Denote:

1. in_role msg msg if role, {msg , msg , ...}, {cstr , ...}

• The next formula expresses that a role belongs to an extension of an object:

((stop_role in_role role )

10.1.31. 10.1.5 Examples




Examples The next formulas say that temporal constraints of a particular role must be verified whenever this role is currently played by an object. Furthermore message start_role can be sent if role is not currently played by the object. That is, the same role cannot played simultaneously several times by the same object.

Here constraint_role is the conjunction of all constraints of role and create_context is the message which creates a new object in context . For each context there is exactly one pair of messages create_context and delete_context. Message delete_context deletes the object to which it is sent.


Examples Since we made the hypothesis that we consider time to be infinite in the future we make the assumption that objects, after accepting a delete_context message will then only be able to accept further delete_context messages. This message can be sent to an object if no role is currently played by the object. In other words we introduce the following formula in our specifications

(delete_context delete_context role ))

As was the case with sequences of messages within a role, only one message, start_role or stop_role, can be sent to an object at a time. We express this with the following formula in PTL:

m m m ))

where L is the number of roles within a context, each m is either stop_role or start_role , k L and n = 2 * L.


Examples Whenever a role is initiated, the next message could be a stop_role. If this is an undesirable situation and we would like to enforce that at least one message of a particular role should be exchanged after it has been started we can introduce the following constraint:

(start_role in_role )

Also for each role within a context we have introduced formulas to ensure that start_role and stop_role messages must alternate. However, nothing guarantees that whenever a role is started it stops sometime in the future. If this is a desirable property of a role we must introduce within context constraints the following formula:

(start_role stop_role)


Examples Finally, if one wants to express that an object cannot be deleted, one must specify the following costraint:

delete_context

Some sequences of role playing relative to context PLANE_TRIP are given in figure 6. The first two sequences are legal while the last one is not since a start_FLYING is sent without stop_ON_GROUND being sent.




Figure 6. Sequences of role playing relative to the context PLANE_LIFE.

10.1.37. Figure 7. Example of a constraint relating a message and the playing of a role.

10.1.38. Figure 8. Example of a constraint relating two messages of distinct role.



10.1.39. 10.1.6 Satisfiability algorithm


Satisfiability algorithm

• An algorithm exists, which decides whether a formula is satisfiable or not.

• The input of the algorithm is a formula, which can containt past operators.

• The output of the algorithm is a graph, which is created if and only if the formula is satisfiable.

• Each graph edge represents a state of a state sequence.

• A node of the graph is labeled with that formula, which is satisfied by that set of states, those are going from the node.

• Each finite path in the graph going from the initial node, describes a finite state sequence, which satisfies the input formula belonging to the initial node.

• Our formulas in their form cannot be analyzed. Because of they are in roles only, the following modifications are needed for the formulas:

10.1.40.1. 10.1.6.1 Modification of formulas within roles


Modification of formulas within roles First, when we specified formulas within a role we did not take into account that there is an instant when the role starts and an instant when the role stops. Therefore the following modifications are needed of formulas found within roles: replace replace replace replace f f

f f by f stop_role by f start_role by f stop_role) by f start_role)




Modification of formulas within roles - cont. replace f f replace f f by (f stop_role) (f f f stop_role)) by (f start_role) (f

f f start_role))

Second, we have not taken into account that several roles can be played simultaneously. To take into account this fact the following modifications are needed for formulas found within roles only.

replace p replace f replace f by in_role p where p is an atomic proposition by in_role (in_role f) by in_role (in_role f)

10.1.42.1. 10.1.6.2 Main steps


Main steps of the satisfiability algorithm The satisfiability algorithm is based on the following principle: given a formula and the assumption that a particular atomic proposition is satisfied in the current world, we can find out the formula which must be satisfied in the next world. This principle derives from the following identities of temporal operators where each temporal operator is decomposed in two parts: the current part and the next-time part.


Main steps of the satisfiability algorithm The following symmetric identities hold for past operators. An additional formula is needed because of a finite past and "termination" of the past operators. (There is no such symmetric identity for future operators since we considered time to be infinite for the future.) f f

f f f f f f f (f (f f)) f f


Main steps of the satisfiability algorithm The algorithm is decomposed into four parts:

• node identification procedure,

• decomposition procedure,

• graph construction procedure,

• elimination procedure.

The node identification and decomposition procedures are used by the graph construction procedure. The elimination procedure is applied at the end of the graph construction procedure.

10.1.46. 10.1.7 Literature


Literature The details of the satisfiability algorithm and its examples can be found in the article:



Constantin Arapis - Specifying Object Life-Cycles

11. 11 Verification, validation

11.1. 11.1 verification and validation

11.1.1. 11.1.1 Notions

11.1.2. Verification and validation of component-based systems

Notions

• Verfication checks that software satisfies the specification.

• Validation checks that software fulfills customer requests.


Figure 1. Development dimensions

11.1.4. 11.1.2 Historical overview


Historical overview

• Program verification related researches began at 60's of the last century.

• Reasons:

• Computers began to become more widely used

• Hardware components became more cheaper, which extended the possibilities of computing. Without efficient, reliable software development models, technologies and tools the software crisis became true.

• Software crisis



• Computer hardwares were developed more rapidly and their speed increased radically, while the increase of software creation efficiency remain backward.


Historical overview

• While experts was searching for the reasons, it became clear that the poor quality of softwares came from the high complexity of problems being solved and also from the high complexity of the software systems.

• Programming methodology was introduced against the complex problems of software development. The goal is to provide such technologies and software development methods, that can guarantee the production of reliable softwares in the available time using the given budget.


Historical overview

• There are two ways to achieve the goal above.

• The analytical way is using verification tools to create correct (sequential or parallel) programs according to the given specification.

• Correctness proof methods

• Theorem proof tools

• Program synthesis methods

• Testing methods

• Model checkers

• The engineering way introduces newer and newer methods, technologies, tools and standards to support reliable system(s) creation.

• Nowadays, software development technologies combine the advantages of the two approach, extending them with the usage of automatic and visual tools.

11.1.8. 11.1.3 Correctness proof methods


Correctness proof methods

• Several methods are known to prove the correctness of sequential or parallel programs.

• Key elements of a proof method:

• A specification language

• General part - a deduction system

• Logical part - axioma schemas to help to derive a sort of axiomas from the text of the program

• Special part - a description of the program domain, e.g. Peano axiomas in case of integer numbers.

• A programming language



• Next, the notions of testing will be outlined and then the special testing problems of component based systems will be discussed.

11.1.10. 11.1.4 Testing


About testing

• Testing is a widely used and accepted software verification and validation method.

• Testing is used to decide whether a software fulfills the requirements, and the specification given in the documentation.

• Testing can be used only to show that the software is working properly for the used test cases, but it is not enough to say that the software is error-free.

• A good example is the explosion of the Ariane 5 rocket in June 4., 1996.

• An exception raised, when the software converted a 64bit floating point number to 16bit signed integer. Software did not handle this case, which lead to a computer crash, and then the rocket exploded.


Testing process

• Testing process should begin at latest after the analyzing phase of development.

• Testing requires so detailed preparation as software development.

• The testing scenario should be made, which consists of

• test cases and those

• testing steps

• These should be written so detailed that everybody can perform testing.


Performing test It is important to test the system from as much viewpoint as we can.

• The ergonomics test is performed at first.

• Displays should be viewed so as a user does that.

• Place of buttons

• Order of fields

• Amount of controls in windows etc.

• Creating testing environment

• It is a complex task and here the test environment creation of components is discussed in details.

• Functional test



• Here we checks that system functions satisfy the requirements.

• Required fields are placed to where the user asked.

• We get the required output for a given input.


Performing test

• Performance test checks that a software modification does not cause a significant change in the operation.

• When a new version is created, modifications should be tested again.

• This test is followed by the regression test, which checks that system modifications did not cause improper operation in the unmodified software parts.

• Testing can not be done in an ad hoc way. Component based software development has special properties, those affect also the testing process. We will review these and draw up recommendations.

11.1.15. 11.1.5 Test environment


Creating test environment for components

• Component based software development is such a technology today, that is a primary tool to overcome the software crisis.

• It can achieve this goal only, if the components of the final system fit together not only syntactic, but semantic too.

• Because of this, software developers should do a more detailed integration test using sometimes new methods.

• Main challenges of component based software testing

• Component test in a new environment

• The internal operations of a component are usually unknown in the case of reusage.

• What kind of test should we choose and how long should we test our component based system?

• We try to find a solution for these suggestions.


Unified Modeling Language (UML)

• UML is an industrial standard, that is created to specify and design software systems.

• UML is supported by many business and open source tools:

• Rational's Rose

• Verimag's Tau

• Sybase's Power Designer



• etc.

• Modeling and testing can be combined following two orthogonal dimensions.

• Model based testing

• Test modeling

11.1.18. 11.1.6 Model based testing


Model based testing

• Support of testing with UML models

• Defining test cases

• Checking the final implementation of the system

• For traditional testing methods, basic categories are:

• Error classification

• Test case definition

• Testing techniques

• Testing phases

• Unit test

• Integrity test

• System test

• Regression test

• etc.

• Using UML we can define our requirements and test specification with same notations.

11.1.19.1. 11.1.6.1 UML based testing


UML model based testing

• There are many similarities between the UML model based testing methods and the regular code based testing techniques.

• Source code can be taken as the representation of a concrete software system.

• It contains more details, but less information about the perspective of the system.

• UML models embody a more abstract representation of these systems.

• It contains less information, but shows more of the complete system.




Importance of UML in testing

• UML has unified notations for description and testing of the system from the top abstraction level to the most concrete description.

• During code base testing, we give scenarios for a given covering criteria.

• We can do similarly, if instead of testing the system, we test a more abstract description, the UML model of the system.

• A new criteria appears naturally at the level of models: the covering of models.

11.1.21.1. 11.1.6.2 Black box testing


Black box testing

• During the functional test, we ignore completely the internal mechanisms of the system or component, and we focus on the outputs of the system, that is responsed for the selected inputs. It is a typical black box testing method.

• At functional testing, we analyse how test cases can be derived from the functional specification.


Extending black box testing for models

• Functional test cases generating techniques are based on analysis and partitioning of the input domains.

• A domain defines a part of the input space, which is related to the tested component.

• Domains can be defined by algebraic expressions and inequalities.

• Partitions can define equivalent classes for the input space.

• This method can be extended to UML models by behavioral equivalent classes, which exist in behavioral model form.

• One kind of the UML behavioral models is the flow chart, with we can examine behavioral equivalences.

11.1.24. 11.1.7 Testing techniques


Testing techniques

• Domain Analysis and Partition Testing

• Equivalence Partitioning

• In this case, we are partitioning the input space using equivalence relations.



• Category Partitioning

• This method is traditionally used in industrial applications, when the design specification is transformed to test specification.

• State-Based Testing

• State-based testing checks the correctness of the component implementation according to the state model of the component.

• The testing scenario is based in this case on the states and state transitions.


Testing techniques 2.

• Method Sequence-Based Testing

• This method is used to check the correctness of the realization of a component based system.

• For component based systems, this is the most important test.

• The design of test cases is based on the behavioral models, which can be defined with UML flow charts.


Testing techniques 3.

• Message Sequence-Based Testing

• This testing method can be used to check the collaboration of different components.

• The design of test cases is based on UML collaboration diagrams.

• Such UML models are given as sequence or interaction diagrams.

• Hereafter, we examine the usability of each models in testing.


Model based testing We can create diagrams with UML about different views of the system, that is being made.

These views can be categorized into two groups

• User views

• Use case diagrams

• Architectural views

• Structural view

• Class and object diagrams

• Functional and behavioral views

• Sequence, collaboration and activity diagrams, flow chart

• Implementation view



• Component and deployment diagrams

• Environmental view

With UML diagrams we can specify

• what should our system do

• how should the system behave

• how can we realize the system

11.1.29. 11.1.8 Model based testing

11.1.29.1. 11.1.8.1 Use case diagrams


Use case diagram based testing

• Two kind of testing are possible

• Use case diagrams based testing

• Use case patterns based testing

• Similar to black box testing, but here testing is performed in a higher abstraction level.

• Use case diagrams based testings do not support the regular test case designing methods, the pre- and post-condition based methods, because at this level of details the solution does not exist.


Elements of use case diagrams for testing - 1.

• Important elements for testing

• An actor may exist in more use cases.

• Test should reflect here the usage of the system from the view of the actor.

• A use case may contain more actors.

• In this case, concurrency hould be examined in the system.

• A use case can be a variant of an other use case ( extends )

• Similar correctness tests should be performed here, as in the case of inheritance relations testing of the object oriented programs.


Elements of use case diagrams for testing - 2. A use case may contain use cases ( uses )

• It can be handled as the previous case.

• Use cases refer to high level components.



• Each referred object in use cases can appear as a component in the architecture of the system, so a relation can be made between the structural diagrams and the use cases of the system.

• A use case can be realized with one or more nested or interacting components.

11.1.32.1. 11.1.8.2 Requirement based testing


Requirement based testing

• In case of requirement based testing, we should try to cover all the involved components.

• It is really important in those cases, where we change the requirements.

• We have to check the architecture of the component and we may have to modify the components as well.

• A regression test should be performed to be sure about the correctness of the modifications.


Elements of use case diagrams for testing - 3.

• A component can support more use cases

• In this case the architecture of the component is not functionally coherent, the cohesion is small.

• This often

• can be taken as a bad practice or

• use case may imply a usage of a given component, so testing should be designed so, that we consider concurrency.


Use case diagrams in testing process

• Use case diagrams are mainly used to determine, identify the goal of testing and to achieve a high level of test case covering.

• In reception tests we can define the following criterias

• Testing or at least covering of

• all use cases

• all actor use cases

• all includes , extends and uses combinations.

• This corresponds to that all nodes and arrows are covered in the use case diagram.

• It is consistent with the criteria of node and arrow covering in flow charts.

• Based upon the available information we can only determine which user functionality should be tested, but we do not know how.




Example - Vending Machine For use case diagram in next slide, we define a testing component given in the table after the figure.


Figure 2. Concepts of a use case diagram, specification of the vending machine


Table 1. Identification of external tester components for the VendingMachine from the use case diagram.


Figure 3. Containment hierarchy of the test organization.

11.1.39.1. 11.1.8.3 Use case and functionality based testing




Use case and functionality specification based testing

• Use case diagrams have few information, so they are unable to give a specification of the system, which tells what functionality we require.

• Use case patterns can be used better.

• Patterns are collected in Table 2.

• KobrA specification patterns of methods in Table 3. are closely related to the patterns defined here.

• If a component is taken as a single system, then the specification of the methods and the corresponding system level use case specifications are essentially the same.


Use case and functionality specification based testing

• Examining the tables, we can determine that descriptions contain similar information at different levels.

• It is obvious that doing use case pattern based testing and the method's specification based testing is a functional or black box testing.

• Use case descriptions specify the functionality at system level, while the operation specification describes the functionality at object or component level.


Table 2. Identification of external tester components for the VendingMachine from the use case diagram.




Table 2. Identification of external tester components for the VendingMachine from the use case diagram - continued.


Table 3. Operation specification template according to the KobrA method and Fusion.


Use case descriptions of the example

• Because of use case descriptions and the specification of the methods have basically the same information on different abstraction levels, therefore functional testing methods can be based also on use case descriptions, but in a higher abstraction level.

• In vending machine example, test cases related to the first use case can be found in Table 4.

• Table 5. contains the use case definitions of PurchaseItem and based upon this, a relation can be defined between use case descriptions and derived tests.




Table 4. Abstract tests, derived from the use case description for PurchaseItem.


Table 5. Definition of the use case PurchaseItem from the vending machine usage model.


Testing techniques All of the abstract tests in Table 4. are based on deductive testing techniques

• Testing basic cases



• Testing the required sequence of events according to a use case.

• Testing special cases

• Testing unexpected events.

• Requirements testing

• Testing all traceable use case.

• Testing properties defined in user documentation.

11.1.48.1. 11.1.8.4 Structural model based testing


Structural model based testing

• Structural diagrams specify the architectural relations among the components.

• It may seem like strange to combine structural questions with testing activities, because testing is always based on a functionality or behavior, not on a structure.

• We can get the information from structural models that what should we test in a system, which is built from a lot of interacting entities.

• Structural models play similar role in testing as use cases.


Component Containment Diagrams and Testing

• Primary components of a system are typically identified at the level of requirement analysis, related to the modeling of use cases.

• After the typical components of the system are identified, we can create a draft structure of the system.

• The structure of the vending machine is shown in Figure with UML notations.

• The modified specification structural model of the vending machine is shown in Figure 5., where a newer activity of the operator is also named.

• Figure 6. shows the testing component of the vending machine, which is derived from the containment model.

• In Figure 6. we show only those test cases, which simulate the currently tested parts of the vending machine.

• If all tests were successful, then the integration of the components is successful.




Figure 4. Development-time containment tree for the vending machine.


Figure 5. VendingMachine amended specification structural model.


Figure 6. Tester components for the vending machine derived from the containment model.

11.1.53.1. 11.1.8.5 Class, Package, Component, Deployment diagrams and testing




Class, Package, Component, and Deployment Diagrams and Testing

• These UML diagrams are used to describe the implementation and deployment of components.

• Class diagrams are mainly used in component specifications and implementations, but they can be also used to describe how to split logical software components for hardware nodes.

• Classes and packages are very similar at first sight and the formerly introduced testing methods can be used to them.

• They also have custom properties

• The basic difference between classes and packages that e.g. connections among classes stay longer fixed. Components are designed to reused in different environments and they can also change, while classes are the basic building rocks of components, so they can be reused not so easy.


Class, Package and Component Diagrams and Testing

• From the view of testing these differences are not significant. The difference is the time when we test them.

• Class diagrams show the connections between the basic building rocks of a component. These connections are more or less constant in the component's lifecycle, so it is sufficient to test them only once.

• Components are building rocks of a component based system, and each time a component is used in a new application, the integration test should be performed.


Deployment Diagrams and Testing

• Deployment diagrams represent an other aspect of the same problem.

• Components are assigned to nodes in distributed environment. In this case, a problem is that some kind of nodes are untouched in the life cycle of the system, so we only need an initial test, while other nodes are always changing and the integration should should be performed after each change.


Structural diagrams

• Structural diagrams are essential in the development of the testing architecture.

• They provide information on what kind of interactions should be tested in which environments.

• They have an important role at the development of the testing architecture, e.g. we build the tests according to contracts into our system.

11.1.57.1. 11.1.8.6 Behavioral modeling




Behavioral modeling with statechart diagrams

• UML supports behavioral modeling with statechart and activity diagrams.

• Statechart diagrams are typically used to describe instance behaviors of classes and components, but they are also used to describe use cases, actors and methods.

• By contrast, activity diagrams concentrate on the description of an instance's internal behavior.


Statechart diagrams

• A statechart diagram consists of states, events, transitions, guards and activities.

• In a state a condition is satisfied, or an activity is executable, or we are waiting for an event. A state can be simple or complex (consists of sub-states). Special states: initial- and end-state.

• An event raises a state transition. It has several forms:

• A value of an expression becomes true from false

• A sign arrives from somewhere

• A method is called

• A predefined amount of time is passed, etc.

• If an event do not raise a transition, then it does not affect the behavioral model.

• A transition is a relation between states, which is raised by an event.

• Concurrent transitions may have more source states and more destination states. Transitions can have guards.

• An activity is performed in the same time as the transition.


Statechart diagram based testing

• A state based testing checks the implementation correctness of a component's state model.

• The design of test cases is based on the states and transitions among them.

• Types of tests

• Piecewise covering

• We should test each state, event, activity.

• We should test each transitions


Statechart diagram based testing - 2.

• Round-trip path covering

• At least all of those transition sequence should be tested, which have an end state same to the initial state.



• Figure 7. shows the statechart diagram of the vending machine, where Table 6. shows the derived state transitions.

• The numbers in small circles in the diagram mean transitions in the table.

• In table of transitions, pre- and postconditions appear. By these, test cases can be derived, which are collected in Table 7.


Figure 7. Component specification statechart diagram for the VendingMachine component.




Table 6. State transition table derived from the specification statechart diagram of the VendingMachine component.


Table 7. Instantiated concrete tests from the state table






Behavioral modeling with activity diagrams

• Activity diagrams are a variants of the statechart diagrams and the describe the control sequence of a procedure.

• They are very similar to the regular statechart graphs, however they provide a more flexible way for descriptions, because they can describe control sequences among multiple instances.

• Statechart diagrams provide an overview about all the activities, that was done by the component in its life. Activity diagrams describe the realization of these activities and provide information about which components were involved into the interactions.

• This is the explanation, why statechart diagrams are more useful for specification and why do we use activity diagrams at the component realization level.

• Statechart diagrams tell us what should be realized, while activity diagrams give the answer to the question: how to realize?


Activity diagrams based testing

• UML activity diagrams are typically used in structural tests.

• They have similar information as the source code or the control graphs in regular white box tests, but in this case the abstraction level is higher.


Control flow testing in a single instance

• Activity diagrams based testing raises similar problems, as statechart diagrams based testing among the regular testing methods.

• The typical codecovering criteria can be adapted naturally to the activity diagrams, because traditional statechart and activity diagrams are essentially the same.

• We assign a state chart diagram to each activity of the activity diagram.

• Test all statechart diagram with the traditional covering criteria method.


Control flow testing among instances

• Testing a system, which consists of more objects raises further problems.

• The collaboration of objects should be tested.

• Collaborations are realized through procedure calls usually.

• Client object calls the server object.

• We have to go back to the structural and behavioral models of the corresponding entities to deduct the test cases for the collaboration point.

• We give an activity diagram to the involved methods and to its involved components.




The Vending Machine

• Figure 8. shows the SelectItem method of the VendingMachine.

• The diagram describes the control sequence inside the method and those additional objects, those are participants of the activity.

• Numbers in gray circles mark the several control paths in the diagram, and they can be used to identify several test cases.

• Table 8. shows the scenario, which is derived from the activity model given above.


Figure 8. Component realization activity model for the VendingMachine component operation selectItem.



11.1.72.1. 11.1.8.7 Interaction modeling




Interaction modeling

• Interaction modeling is a kind of combination of the dynamic and structural modeling.

• It concentrates mainly on dynamic interactions between instances.

• UML offers two types of diagrams for this purpose

• sequence diagrams and

• collaboration diagrams.

• Sequence and collaboration diagrams provide basically the same information about the system, although they focus on different points, but both of them are similar to the activity diagrams.


Interaction modeling

• Sequence diagram focuses on the time sequence of method calls with their input and output parameters.

• Collaboration diagrams focus on the structure and that what relation has the structure with the dynamic interactions.

• Figure 10. shows the collaboration model the vending machine at realization level according to the activity diagram in Figure 8. and the sequence diagram in Figure 9.


Collaboration diagrams based testing

• The sequence and collaboration diagrams are typical control flow diagrams.

• As a view of testing, they are flow charts and they refer to more entities.

• All the covering criterias can be applied to them, although the abstraction level of the UML diagrams is higher than the traditional statecharts have, so test results come also at a higher level.


Sequence diagrams based testing Some problems, that can be recognized by sequence diagrams:

• Incorrect or missing input

• Missing activity in the external interface

• Missing functionality in a partner object

• Sending correct message to a wrong object

• Sending wrong message to a correct object

• Sending message to a destoyed object

• Throwing correct exception, but wrong object handles it

• Incorrect exception is being handled by correct object



• Deadlock

• Performance problem.


Sequence diagrams based testing - Example Test sequence in Table 9. is derived from the sequence diagram in Figure 9.


Figure 9. Component realization sequence model for the VendingMachine component, operation selectItem.


Table 9. Test scenarion identification from the sequence model.


Sequence diagrams based testing - Example continued We can derive the test sequence of Table 10. from the collaboration diagram of Figure 10.




Figure 10. Component realization collaboration model for the VendingMachine component, operation selectItem.


Table 10. Test scenarion identification from the collaboration model.

11.1.82.1. 11.1.8.8 Test modeling


Test modeling Development of the test environment (test software) with UML.

• The test environment is developed similarly as any other software or component.

• Types of UML diagrams

• Use case diagrams

• Visualize the idea of the user

• Structural diagrams

• Visualize the architecture of the system

• Behavioral diagrams

• Visualize the functionalities of the system or its parts.

• Implementation diagrams

• Visualize the runtime structure of the system.



11.1.84. 11.1.9 Test infrastructure


Test infrastructure

• The OMG initiated to develop the UML testing profile.

• The UML testing profile is an extension of the standard UML core, which is based on the UML meta model.

• Testing profile supports the specification and modeling of the software testing infrastructure, so it supports

• from structural view

• test components,

• test environment and

• test system interface definition;

• from behavioral view

• test procedures and

• test execution and evaluation definition.

11.1.86. 11.1.10 Aspects of testing


Structural aspects of testing

• The structural aspects of testing profile and their relations can be seen in Figure 11.

• Parts of the test architecture:

• Test context

• It represents the test cases.

• Test configuration

• It defines how to apply test cases to the system being tested (SUT).

• Test components

• Part of the test configuration,

• the arbiter is a special component, which evaluates the test results.




Figure 11. Structural concepts of the testing profile.


Behavioral aspects of testing

• Test behavior can be defined through several concepts of the test profile.

• The most important concept is the test case, which defines what will we test for what outputs in which environments.

• The result of each execution of a test case is a trace.

• Figure 12. summarizes the notions related to test cases.

• "verdict" marks that test was successful or failed.

• The behavior of a test case contains

• a test stimulus, which sends test data to the system being tested to check them;

• a test observation, which represents the reaction of the system for the data sent by the stimulus.

• test results are evaluated by the validation action unit.

• The behavioral aspects of testing are summarized in Figure 13.


Figure 12. Concepts of a test case in the testing profile.



Figure 13. Concepts of the behavior of a test case in the testing profile.


• Test data sent to, and data received from the system represent the test data of a test case and they called test parameters.

• A test parameter can be anything

• data

• argument

• coding standard, etc.

• Figure 14. summarizes the test profile related data.

• The description of the UML Testing Profile can be found on the website of OMG.


Figure 14. Test data concepts in the testing profile.

12. 12 Verification Problems

12.1. 12.1 Verification of CBSD

On the Verification Problems of the Component-Based Software Development Zs. Borsi, L. Kozma, A. Medve

12.1.1. 12.1.1 Component-Based software development

12.1.2. Component-Based software development

Component-Based software development

• The component-based software development (CBSD) is ideally not more than putting pieces (components) together but the original deployment environment of a component and its new deployment environment into which it is going to be integrated may be considerably different from each other.

• CBSD may be subdivided into two distinct development activities

• Component engineering



• It is focusing on the development of components as individual building block designed for integration in a number of different applications.

• Application engineering

• It is concerned with the assembly and integration of the building blocks into new software systems.

12.1.3. 12.1.2 Important properties for software components


Important properties for software components

• Composability, reusability, reliability

• Unique identity

• A component should be uniquely identifiable within its development and its runtime environments as well.

• Modularity and encapsulation

• They refer to the scoping property of a component

• Interaction through interface contracts

• Interfaces are the only means for accessing the services of a component.

• A component's syntax and semantics are determined through its provided and required interfaces.

• The provided interface is a set of functionality and behaviour that collectively define services that a component provides to its associated clients.

• The required interface is a set of functionality and behaviour that the component expects to get from its environment.



• Using a CBSD method the entire system is decomposed into finer-grained parts that will be mapped to existing functionally.

• Using a CBSD method with UML keeps the advantage of UML.

• It is widely used as a de-facto industry standard, but doesn't provide methodology.

• It is a good notation that can be used by human users and by computers as well.

• Using UML you can define the connections between conceptual and executable artifacts.



• The KobrA CBSD method uses the UML as main model-based notation for all analysis and design activities in a development process according to a three-dimensional model.

• Composition/decomposition: Concerning with designing a system or component.



• Abstraction/concretization: Concerning with implementation of a system or component.

• Genericity/specialization: Concerning with development of a product family.

• Kobra support to solve verification problems of the CBSD process.

12.1.7. 12.1.3 Verification problems of CBSD


Verification Problems of the Component-Based Software Development

• Verification problems may be subdivided into two activities

• Verifying that a component is correct with respect to its specifications,

• Verifying that the entire system is correct with respect to its requirements.

• Verification methods are

• Correctness proof

• Synthesis

• Testing

• Model checking


Component-Based software development

• Component-based software testing consists of two distinct activities:

• testing of the components,

• integration testing of the assembled application.

• Model-based testing activities are concerned with deriving test information out of UML models.

• Usage models

• Structural models

• Behavioral models

• Activity and interaction models

• Test modelling concentrates on how to model testing structure and test behaviour with the UML.

12.1.10. 12.1.4 Model checking


Model checking...

• Is an algorithmic way of verifying whether a desired property holds for a model of a system.



• A (software or hardware) system can usually be modeled in a special-purpose language.

• The requirements are usually specified in some temporal logic (LTL, CTL, CTL*, etc.).

• As an intermediate step, a state space is generated from the specification, in the form of a graph covering all possible behavior.

• A model checking algorithm decides whether a given property holds for a model (verified) or not (refuted). In the latter case a counterexample (or witness) is provided.

• In practice, model checking can significantly contribute to the early detection of faults and errors in the early design phases.

12.1.12. 12.1.5 Usage model


Usage model

• The use case models may be applied to define the coarsest-grained logical system modules and they can be defined by use case diagrams. But they display only very limited information and a sole use case diagram is useless for the concrete specification of what a system is supposed to do.

• Each use case in a use case diagram is additionally individually specified by a use case template.

12.1.14. 12.1.6 Verification of the usage model


Verification of the usage model

• The traditional verification methods are usually failed to apply because they are too complex or give only partial results.

• In case of temporal model checking properties can be expressed by temporal logical formulae.

• The use case descriptions can be checked with respect to its specifications expressed in linear-time temporal logic (LTL) or in a branching time logic e.g. computational temporal logic (CTL).

12.1.15.1. 12.1.6.1 Example


A verification example

• Given the use case description of PurchaseItem of VendingMachine usage model.

• We verify whether the usage model respects its specification in NuSMV symbolic model checker.

• Its specification expressed in computational temporal logic (CTL).

• Analysis of fair and violating traces, temporal logic expressions and Usage model.

12.1.17. The model and the specification in NuSMV




Use Case description (1)

• Use Case 1: Purchase Item

• Goal in Context: Main scenario for purchasing an item from the vending machine.

• Actors: User.

• Trigger: User inserts coins into slot, or selects item on button panel.

• Preconditions: Vending machine is operational.

• Postconditions on Success: Item is provided.

• Postconditions on Failure: Item is not provided.

• Description Basic Course:

1. User inserts suficient amount of money.

2. User selects item on panel.

3. Selected item and return money are dispensed.

4. User takes item and returned money, if applicable.



• Description Alternative Courses:

1. User selects item.

2. Vending machine displays price.



3. basic course

• Exceptions:

1. [insuficient amount] user inserts more cash, or aborts.

2. [selected item not available] user selects different item, or aborts.

• Non-functional Requirements:

1. Item should be dispensed not more than 3 seconds after selection.

2. After 3 sec of no user selection use case is aborted and inserted cash returned.

• Extensions: <left open>

• Concurrent Uses: <left open>

• Revisions: <left open>

12.1.20. Corresponding parts of Use Case description and NuSMV specification

Trigger: Description: Exceptions: Non-functional Requirements: Pre-post conditions: set of states, initial state, state, next state pairs set of states, state, next state pairs state, next state pairs temporal logic expressions temporal logic expressions temporal logic expressions

12.1.21. Fair and violating behaviour (1)




12.1.23. 12.1.7 Conclusions


Conclusions

• The integration of the earlier verification and validation of Use Case descriptions with model checking into incremental CBSD process, contributes significantly towards the identification of defects.

• Future questions: How to model testing structure and test behaviour from model checking automatizations.

• Future research positions: counterexample generation for test modeling and test behaviour performation with model checking of other specification artifacts (ie. interaction, behavioural and structural models).

12.1.25. 12.1.8 References


References

• Haus-Gerhard Gross. Component-Based Software Testing with UML. Springer-Verlag Berlin Heidelberg,



2005.

• E.M. Clark Jr., O. Grumberg and D.A. Peled. Model Checking. The MIT Press, Cambridge 2000.

• Antonio Bucchiarone, Henry Muccini, Patrizio Pelliccione, P. Pierini. Model-Checking Plus Testing: From Software Architecture Analysis to Code Testing. FORTE Workshops 2004: 351-365


References

• NuSMV Model Checker. http://nusmv.irst.itc.it

• Ákos Dávid, László Kozma. Educational aspects of incremental model checking. Proceedings of the 3rd International Multi-Conference on Society, Cybernetics and Informatics, Vol 2, pp. 190-194, 10-13, 2009, Orlando, Florida, USA, ISBN-10: 1-934272-73-6, ISBN-13: 978-1-934272-73-2.,

12.2. 12.2 Example - A railway problem

Specification and model of the problem

Figure 1. Example of a Verification Area


AG AG

Figure 2. OBDD for with ordering




Figure 3. OBDD for with ordering

Left: Right: Figure 4. Two ROBDDs for OBDD for with different orderings.

Table 1. Statistics for medium-sized problem

A counter-example

12.2.1. Counter-example



Table 1. A counter-example for a small interlocking.




Figure 1. A small track layout.


Table 2. A small signal control table.


Figure 2. An example of track segments for track 8B.




Table 3. Template of the interpreted output of a counter-example.


L. van den Berg et al. Electronic Notes in Theoretical Computer Science 174 (2007) 19-35

Table 4. Template of the interpreted output in which a point is set incorrectly.


Table 5. Template of the interpreted output in which a point moves while the train is in-route.


Table 6. Example of the output produced when a point is set incorrectly.


Table 7. Example of the output produced when a point moves while the train is in-route.




Table 8. Template of the interpreted output for the opplock counter-example.


Table 9. Example of the interpreted output for the opplock counter-example.


Table 10. Template of the interpreted output for the diffpath counter-example.


Table 11. Example of the interpreted output for the diffpath counter-example.




Table 12. Template of the interpreted output for the somepath counter-example.


Table 13. Example of the interpreted output for the somepath counter-example.


Table 14. Results of evaluation

13. 13 Model checkers

13.1. 13.1 Model checkers

13.1.1. 13.1.1 Component-based software technology

13.1.2. Model checkers

Component-based software technology

• Main goals:

• Reusability

• Evolution

• Reliability

• Required preconditions:



• Component-library

• Component-model

• CORBA (CCM)

• Microsoft (COM+/.NET)

• Java (EJB)

• Software-architecture

13.1.3. 13.1.2 Component-based software development


Component-based Software Development (CBSD)

• In ideal case, CBSD is not more than composing a system from components.

• The problem is that the development platform of a component is usually not the same as the platform of the system where the component will be used. We have to do an integration check on the created system.

13.1.5. 13.1.3 Contracts


Contracts

• A possible solution, if the validation information is built in the component and exists not till the end of the development, but all the time.

• Contracts are used here to fix the rights and obligations in a client-server structure.

• Component can check, whether it can work together with its new "colleagues", while the environment can also check whether it accepts or not the "newcomer".


Type of contracts

• Basic contracts, syntactic contracts.

• Behavioral contracts - describe the global functionality of a component

• Synchronization contracts

• Quantitative contracts or quality-of-service contracts

• ...


Built-in contracts



• We can build the contracts into the components so they can be turned on/activated whenever the component is reusaged.

• We test the component in the new environment with the current contracts.

• If test shows that our component works fine in the new environment then we can turn of contracts to improve the efficiency.

• If efficiency criterias let it so, then contracts may be left turned on for the whole life-cycle of the component.

• Further details of the contract's usage are beyond our topic.


Figure 1. The static model of a framework.

13.1.10. 13.1.4 Verified components

13.1.11. Verified components

Verification procedures

• Correctness proof, behavioral analysis

• Program synthesis

• Model checking

• Testing

13.1.12. A component, that realizes mutual exclusion

Let the structure of the two concurrent processes the following:



13.1.13. 13.1.5 Peterson's method

13.1.14. Peterson's method (1981) - First process

Use flag1, flag2 and turn shared variables

13.1.15. Peterson's method - Second process

13.1.16. 13.1.6 Correctness

13.1.17. Model checking

Correctness

• Doing behavioral analysis on the component, which consists of two processes and realizes the mutual exclusion, we can find that the component satisfies both safetyness and liveness properties.

• Problem: The corresponding formal methods required by the proof are missing. Because of the large amount of possible execution paths, behavioral analysis is less useful.


Model checking



• A completely automatic method to check the correctness of finite state systems.

• Using a given model checking tool, user should provide

• The specification, which describes the required properties

• with temporal logic formulas

• A higher level model of the system being designed

• in a special modeling language

• Model checker analyses all state transitions of the model for all inputs.

• It returns true, if the analysed model satisfies the required properties.

• If the answer is false, then it gives the execution sequence, which violates a required properties.


Model checking

• In some cases, non-finite state system can be checked also, but it requires several abstraction and inductive assumptions.

• Temporal logics used for specification can guarantee that we can also analyse the behaviors of concurrent systems.

• The most problematic is the "explosion" of the state space when we use model checkers, but several methods are existing to solve this problem.

• Binary decision trees (BDT)

• Symbolic model checking

• Partial ordering based reduction

• Open incremental model checking

13.1.20. 13.1.7 Symbolic Model Verifier


Symbolic Model Verifier (SMV)

• A kind of tool, that can be used to decide that a finite state system satisfies its specification given in language

• CTL (Computational Tree Logic) or

• LTL (Linear Temporal Logic)

• From now G means the Always operator and F means the Eventually operator in LTL formulas.

• Language elements used to describe and create a model of a finite state system:

• Modules

• Synchronous and overlapped compositions

• Non deterministic transitions



• Transition-relations


Global specification

13.1.23. MODULE prc(state0, state1, turn, turn0)

13.1.24. MODULE prc - cont.


Result of SMV As SMV is performed on main and prc modules, we have the result that mutual exclusion is satisfied:

SPEC G !(s0 = critical s1 = critical) is true

and the system is guaranteed starvation-free:

SPEC G ((s0 = trying) F ((s0 = critical)) is true SPEC G ((s1 = trying) F ((s1 = critical)) is true

13.1.26. 13.1.8 A model of parallel computation


A model of parallel computation

• The model of parallel computation



• A P = P || ... || P concurrent program consists of a finite number of parallel executed P ,..., P sequential processes.

• The synchronization of a P process is a state machine, which is represented by a directed graph.

• All edges of the graph are labeled with a B A synchronization statement, where B is a guard (condition) and A indicates an activity.

• Such systems can be described with temporal logic formulas.

• Computation Tree Logic* (CTL*) is a kind of it.


Computation Tree Logic*

• Computation Tree Logic* is a propositional branching-time temporal logic.

• The specification input of model checkers are often given by CTL or CTL* formulas.

• CTL* is an extension of the Computation Tree Logic (CTL).


Syntax of CTL*

• (S1) All atomic proposition is a state formula;

• (S2) if are state formulas, then , are state formulas;

• (S3) if is a path formula, then and are state formulas.

• (P1) All state formula is a path formula;

• (P2) if are path formulas, then , are path formulas;

• (P3) if are path formulas, then , are state formulas.


Modalities

• Path quantifiers

• Intuitive meaning of : a maximal path exists where is satisfied.

• Intuitive meaning of : is satisfied for all paths.

• Linear-time modalities

• G (always)

• F (sometime or eventually)

• (strong nexttime): formula is satisfied in a state on a maximal path, if executing the next atomic activity of process, is satisfied in all state, which can be reached directly from state .



• Y (weak nexttime)

• formula is satisfied on a maximal path in a state, if such state exists on the maximal path so that is satisfied in and is satisfied in all states till , but is not necessary satisfied in .


Semantic of CTL*

• Let , where

• is a finite set of states. Each state is a projection, which projects the set of atomic propositions to the set .

• is a binary relation, which defines the transitions of the sequentional process .

• Let .

• A is a sequence of states ( ), where .

• A is a maximal path. A fullpath is an infinite sequence ( ), except if an state exists, which does not have any (following) state, where .


Notations

• is a full path, is a suffix.

• means: is true in structure in state .

• means: is true in structure on fullpath .

• means: is true in structure in states.


Semantic - 1.

• if

• if and if not( )

• if such fullpath exists in structure that ; if is true for all fullpath in structure .


Semantic - 2.

• if



• if and if not( )

• if is defined and and if

exists so that and .


Notations represents that is valid, so it is true in all states of all structures.

13.1.36. 13.1.9 Combination of model checkers and testing


Combination of model checkers and testing

• It is important to check the correctness of our software as soon as possible.

• We can validate the use case models also with e.g. model checkers.

• In this case, we can construct based on the use case diagram

• the specification defines the required properties,

• Using temporal logic formulas.

• the high-level model of the system.

• In special modeling language.

• In our case, this tool is the NuSMV model checker. The specification is provided in CTL formulas, while the model of the system is given in the modeling language of NuSMV.

• In following, use case description of Purchase Item will be introduced and later the model and the specification will be defined for NuSMV.

13.1.38. 13.1.10 Example



• Use Case 1: Purchase Item

• Goal in Context: Main scenario for purchasing an item from the vending machine.

• Actors: User.

• Trigger: User inserts coins into slot, or selects item on button panel.

• Preconditions: Vending machine is operational.

• Postconditions on Success: Item is provided.

• Postconditions on Failure: Item is not provided.



• Description Basic Course:

1. User inserts suficient amount of money.

2. User selects item on panel.

3. Selected item and return money are dispensed.

4. User takes item and returned money, if applicable.



• Description Alternative Courses:

1. User selects item.

2. Vending machine displays price.

3. basic course

• Exceptions:

1. [insuficient amount] user inserts more cash, or aborts.

2. [selected item not available] user selects different item, or aborts.

• Non-functional Requirements:

1. Item should be dispensed not more than 3 seconds after selection.

2. After 3 sec of no user selection use case is aborted and inserted cash returned.

• Extensions: <left open>

• Concurrent Uses: <left open>

• Revisions: <left open>

13.1.41. The model and the specification in NuSMV




Result of model checker

• Executing the NuSMV model checker, we get the result that the model is correct to the specification, so

• system can go from idle state to insertcoin state and

• from insertcoin state, system can go in finite time to takeitem state, or into abort state. From these states system should go always to the idle state.

• In this case, system is checked on a very high abstraction level. We did not answer the question that what situation can cause that system goes into takeitem or abort state. The matter at this level is that these kind of transitions can happen according to the user requirements.





Modification of specification

• Modify the specification of the system in the following way. Prescribe that system should go everytime into takeitem state from insertcoin state.

• partial formula and as an output we also get a counter-example shown in the next figure.





Using counter-examples

• The model checkers generated counter-examples can be used to define test cases for testing and we can also obtain useful information how to generate test data.

13.1.47. 13.1.11 References

13.1.48. CBSD - Model checkers

References

• Bass, L., Clements, P., Kazmar., R. Software Architecture in Practice (Second Edition). Addison Wesley 2003.

• Clarke, E. M., Jr., Grumberg, O., Peled, D. A. Model Checking. The MIT Press, Cambridge 2000.

• Haus-Gerhard Gross. Component-Based Software Testing with UML. Springer-Verlag Berlin Heidelberg, 2005.

13.1.49. CBSD - Model checkers

References

• McMillan, K. L. Symbolic Model Checking: An Approach to the State Explosion Problem . Kluwer Academic, 1993.

• NuSMV Model Checker. http://nusmv.irst.itc.it

14. 14 Common Component Modeling

14.1. 14.1 Common Component Modelling

CoCoMe Common Component Modelling Example Sebastian Herold and co. Germany: Italy: TU Clausthal, University Karlsruhe, Technische Universitat München; Politechnico di Milano

14.1.1. 14.1.1 Modelling of a trading system

14.1.2. Common Component Modelling

Modelling of a trading system

• A supermarket chain is given, which forms a company

• More supermarkets belong to the company

• In a supermarket, customer can pay at the cash desk for the selected items

• There are more cash desks at a supermarket

• Customers can pay with cash or credit card

• Cashiers are using barcode readers



• Cash registers are connecting to the server of the supermarket and to the bank through it.


Figure 1. Overview

14.1.3.1. 14.1.1.1 Functional Requirements, Use Case Analysis

Functional Requirements and Use Case Analysis


Figure 2. Use cases


Content of the use case template

• Use case template

• Brief Description

• Involved Actors

• Precondition

• Trigger

• Postcondition



• Standard Process

• Alternative or Exceptional Processes


Use case: Sale process (UC 1)

• Brief description

• Sum the cost of products selected by the customer and then customer pays with credit card or cash.

• Involved actors

• Customer, Cashier, Bank, Printer, Card reader, Cash register, Barcode reader, Display

• Precondition

• The cash desk and the cashier are ready to process a new sale.

• Trigger

• A customer arrives to the cash desk and wants to pay for the selected items.

• Postcondition

• The customer paid, got the receipt and selling is registered in the inventory.


Standard Process (UC 1)

1. The Customer arrives at the Cash Desk with goods to purchase. [arr1]

2. The Cashier starts a new sale by pressing the button Start New Sale at the Cash Box. [t12-1]

3. The Cashier enters the item identifier. This can be done manually by using the keyboard of the Cash Box. [p13-1, t13-1] or by using the Bar Code Scanner. [p13-2, t13-2]

4. Using the item identifier the System presents the corresponding product description, price, and running total. [t14-1]

The steps 3-4 are repeated until all items are registered.


Standard Process - 2 (UC 1)

1. Denoting the end of entering items the Cashier presses the button Sale Finished at the Cash Box.

a. To initiate cash payment the Cashier presses the button Cash Payment at the Cash Box.

i. The Customer hands over the money for payment.

ii. The Cashier enters the received cash using the Cash Box and confirms this by pressing Enter.

iii.The Cash Box opens.

iv. The received money and the change amount are displayed and the Cashier hands over the change.



v. The Cashier closes the Cash Box.



1.

a. In order to initiate card payment the Cashier presses the button Card Payment at the Cash Box

i. The Cashier receives the credit card from the Customer and pulls it through the Card Reader.

ii. The customer enters his PIN using the keyboard of the card reader and waits for validation. The step 5.b.ii is repeated until a successful validation or the Cashier presses the button for cash payment.



1. Completed sales are logged by the Trading System and sale information are sent to the Inventory in order to update the stock.

2. The Printer writes the receipt and the Cashier hands it out to the Customer.

3. The customer leaves the Cash Desk with receipt and goods.


Alternative or Exceptional Process (UC 1) In step 3: Invalid item identifier if the system cannot find it in the Inventory.

1. The System signals error and rejects this entry.

2. The Cashier can respond to the error as follows:

a. It exists a human-readable item identifier:

i. The Cashier manually enters the item identifier.

ii. The System displays the description and price.

b. Otherwise the product item is rejected.


Alternative or Exceptional Process - 2 (UC 1) In step 5.b: Card validation fails.

1. The Cashier and the Customer try again and again.

2. Otherwise the Cashier requires the Customer to pay cash.

In step 6: Inventory not available.

1. The System caches each sale and writes them into the Inventory as soon as it is available again.




Additional use cases Additional use cases can be described similar to the UC1 use cases.

• UC 2 Manage Express Checkout

• If such conditions are met, then cash desk switches automatically to express mode.

• It this case each customer can purchase at most 8 items and must pay with cash.

• ...

• Note: take a look at the usage of Extending Use Cases and Extension point (UC 1 use case is extended with the services of the UC 2 use case).

• UC 3 Order Products

• UC 4 Receive Ordered Products


UC 5 Show Stock Reports

• Brief description

• Store manager may ask to create statistical report about the products in the given store.

• Involved actors

• Store Manager

• Precondition

• The report creator GUI and the Store Client are working

• Trigger

• The Store Manager wants to see the statistical information of the store.

• Postcondition

• Report was created and displayed

• Standard process

1. The Store Manager enters the identifier of the store and presses the Create Report button.

2. The full list of products in the store's inventory is shown.


Additional use cases - 2.

• UC 6 Show Delivery Reports

• The Trading System provides the opportunity to calculate the mean times a delivery from each supplier to a considered enterprise takes.

• UC 7 Change Price

• The Trading System provides the opportunity to change the sales price for a product.

• UC 8 Product Exchange (on low stock) Among Stores



• If a store runs out of a certain product, it is possible to start a query whether those products are available at other Stores of the Enterprise. After a successful query the critical product can be shipped from one to other Stores.

14.1.15.1. 14.1.1.2 Extra-Functional Properties

Extra-Functional Properties


Extra-Functional Properties

• The description of the extra-functional properties of the trading system is given by the authors in tables, defining those places in the concrete use case templates, where the given property is significant.

• These properties serve as a guideline, when our system is analysed considering several quality aspects.

• Some properties:

• Timing

• Reliability

• Usage profile related information.

• The next slide shows a part of such table according to the UC 1 use case. For the other use cases, newer and newer functional properties can be introduced.

• The authors used the language found in OMG UML Profile for Schedulability, Performance, and Time material to describe the tables.


A part of such extra-functional properties table

• UC 1 Process Sale

• arr1: Customer arrival rate per store: given value

• t12-1: Time for pressing buttom "Start New Sale": given value

• t13-1: Time for scanning an item: given by histogram

• t13-2: Time for manual entry: given value

• t14-1: Time for showing the product description, price, and running total: given value

• p13-1: Probability of using the bar code scanner per item: 0.99

• pt13-2: Probability of manual entry per item: 0.01

• ...

• The complete table contains 37 items to the UC 1 use case.

• Tables to the other use cases can be constructed similarly.

14.1.17.1. 14.1.1.3 Trading System's architecture



The architecture of the Trading System


The structure of the Trading System

• Next figure shows the TradingSystem supercomponent, which consists of the following two components:

• Inventory

• component represents the information system,

• CashDeskLine

• represents the embedded system.


Inventory Information System - with partial structure Cash Desk Line Embedded systems on a bus architecture

Figure 3. TradingSystem


The Trading System super component

• The TradingSystem supercomponent consists of one instance of each above components, and this fact is noted with number 1 in the left top corner of the components.

• Communications among the two components are handled by the following two interfaces

• CashDeskConnectorIf

• defines a method, with we can obtain information about the product by its identifier: description, price;

• SaleRegisteredEvent

• The event interface in this case registers a beginning of a new sale on an asynchronous channel.

• The CashDeskLine component is connected the bank via the BankIf interface, which's task is to handle the credit card payment mode. The component keeps the connection with the bank via a port.




Figure 4. TradingSystem Inventory component architecture


The structure of the Inventory component

• The previous figure shows the internal architecture of the Inventory component, which represents the information system of the trading system.

• The architecture is built from the following layers:

• GUI,

• Application,

• Data,

• Database.

• For each Inventory component instance, only one Database instance exists.

• The Data layer is a classic three layered architecture, and its details will be discussed later.

• The communication between the Database and Data layers managed by JDBC.

• The Data component connects via three interfaces to the Application layer (EnterpriseQueryIf, StoreQueryIf, PersistenceIf).




Figure 5. TradingSystem Inventory component architecture



• EnterpriseQueryIf interface contains queries about the company operation.

• StoreQueryIf defines methods for the supermarkets

• to change item prices,

• to manage the Inventory

• etc.

• PersistenceIf

• provides a method to query persistent relations.



• The Application component contains the application logic.

• It uses the interfaces of the Data component to send queries and modification to the Database.

• It defines the StoreIf and ReportingIf interfaces for the GUI component, so the application layer can send the database query results through them to the GUI layer.

• Between the application and GUI layers (components) data are sent using Transfer Objects (TO) instead of passing references.


Data layer

• The following figure shows the Data layer, which consists of three subcomponents:



• Enterprise,

• Persistence,

• Store.

• The task of these components is to realize the EnterpriseIf, StoreQueryIf and PersistenceIf interfaces.

• The data model of the trading system gives a detailed overview about the data model, which is extended with attributes and navigation paths.


Figure 6. Internal structure of the Inventory component's data layer.


Figure 7. Data model of the Trading System.


Application layer

• The application layer consists of three components:

• Reporting,



• Store,

• ProductDispatcher.

• The Reporting component realizes the ReportingIf interface.

• The Store component realizes the CashDeskConnectorIf and StoreIf interfaces.

• The required interfaces of the Store component are SaleRegisteredEvent and ProductDispatcherIf.

• ProductDispatcher defines a method for the Enterprise Server, which searches products in other supermarkets.

• The communication between the Data and the Application is realized so that Data passes references of persistent objects to the Application component.

• The Application layer uses Transfer Objects (TO) to pass information to GUI and CashDeskLine components.


Figure 8. Internal structure of the application layer of the Inventory component.


Figure 9. Transfer Objects realizing data exchanges between the application and GUI layers.


Application layer

• The internal structure of the GUI layer of the Inventory component is shown on the next figure.



• Reporting

• This component realizes the visualization of the reports. The data for the visualization is taken through the ReportingIf interface.

• Store

• This component provides user interface for the Store Manager, so itcan manage ordering products or changing the sale prices, etc. tasks.


Figure 10. Internal structure of the GUI layer of the Inventory component.


Structural view of the Cash Desk Line component

• This component is an embedded part of the system.

• Its task is to manage all the cash desks, including their hardwares, the collaboration of the cash desks and the connections among cash desks and connected devices.

• The main communication is realized by events sent on event channels.

• The next figure shows the structural overview of the CashDeskLine component.

• CashDeskLine component contains:

• More CashDesk instances,

• an EventBus component,

• and a Coordinator component.




Figure 11. Structural view of the Cash Desk Line component.


EventBus component This component manages the two instances of the EventChannel, those are common for all instances of CashDesk:

• cashDeskChannel

• Used by the CashDesk for the communication with the controllers of the connected devices

• CashDeskApplication, LightDisplayController, etc.

• Each controller is connected to one hardware device

• These form together a bridge between the hardware and the middleware.

• extCommChannel

• CashDeskApplication component writes the information about finished sales into the Inventory component via the extCommChannel.

• Both Coordinator (which manages express cash desk services) and CashDesk components are using this channel.


CashDesk component details

• It can be seen in the previous figure that CashDesk components also handle messages.

• In the figure, half circles mark messages, those can be handled by the component, while circles mark messages, those are sent by the component to other components.

• Example: CardReaderController

• it handles the ExpressModeEnabledEvent event and

• sends the CreditCardScannedEvent and PINEnteredEvent events.




Deployment view of the trading system It discusses, which tools can be used to realize the trading system.

• Each cash desk has an own PC and additional hardware devices connected to that PC.

• Barcode reader or credit card reader

• Controllers of devices are running on the PC and the PC communicates via an event channel with them.

• Each supermarket has a Store Server

• All the PCs in the supermarket are connected to this server

• The server component consists of four additional components: Coordinator, extCommChannel, Application and Data.


Physical placement of the components (e.g. hardware)

Figure 12. Deployment view


Behavioral model

• A more formal description of each use case by a modeling tool.

• In this case, using UML 2.0 sequence diagrams.


Behavioral view of the trading system

• In this case the behavioral view of the system is given with the sequence diagrams of the use cases.

• The following notations are used on sequence diagrams:

• Filled headed arrow marks a synchronous method call,



• Non-filled headed arrow marks an asynchronously called method.

• The collaboration of the actors and components are described with sequence diagrams.


Behavioral view of UC 1 use case The sequence diagram of use case Sale Process (UC 1) is shown in the following three figures.

• In the sequence diagram of the main process (sd UC 1: Process Sale) the followings are shown

• the cashier and additional

• software components

• CashBox

• CashBoxController

• CashDeskApplication

• PrinterController

• ScannerController

• CashDeskGUI

• Inventory

• BarCodeScanner


Figure 13. Behavioral view of Process Sale (UC 1) use case.


Main process: sd UC 1: Process Sale Activites of the main process:

• Cashier pushes the Start new sale button, and then



• the initialization of a new sale happens and

• the printer prints the header of the new sale onto the bill.

• The cashier uses the bar code reader to read the bar codes of each items, and based on this

• the Inventory component gives the proper data of the product to the CashDeskApplication and then the new item is added to invoice.

• This step is repeated until all the bought items are processed and the cashier pushes the Sale Finished button.

• Customer can pay with

• Cash

• Sd UC 1: ProcessSale:CashPayment

• Credit card

• Sd UC 1: ProcessCardPayment.


Figure 14. UC 1 pay with cash.




Figure 15. UC 1 pay with credit card.


Behavioral view of UC 5 use case

• UC 5 Show Stock reports

• The manager of the supermarket can ask information about which items are low on stock.

• A manager can use the Reporting service of the GUI component to generate the list, by providing the identifier of the supermarket and pressing the CreateReport button.

• Then the getStockReport() service of the GUI::Reporting component gets the required information from the Data::Store component and generates the list, as can be seen in the next figure.

• The result is a ReportTO object, and it sends this object to the GUI::Reporting component, where the manager can see the result.


Figure 16. UC 5 Show Stock reports.

14.1.48.1. 14.1.1.4 Implementation


Implementation

• The trading system is implemented in Java language.

• Each component corresponds to a Java package.

• From outside, only the interfaces of the embedded components are public.

• Classes implementing the interfaces can be found in the impl subpackage.




Figure 17. Implementation.

14.1.50.1. 14.1.1.5 System test


System testing

• The test framework has two tasks:

• provides more information about some aspects of the system,

• teams modelling different system parts have the opportunity to automatically test their implementations.

• To reach the goal above, the JUnit test framework was used in the project and also during the test scenarios creation.

• The created test framework contains more layers, as can be seen in the next figure.

• A common test interface is used for testing, which is realized by test drivers.

• Test scenarios are realized through these interfaces.

• It is enough to create only the corresponding test driver to run the test on a newly created system part.




Figure 18. Architecture of the testing framework.


Test scenarios

• Test scenarios are based here on the use cases of the trading system.

• Test scenarios can be given in two ways

• in formal Java classes

• testing is automatic using JUnit,

• informally described

• testing is done manually, e.g. use case 5.

• The next tables contain the use case identifiers and the corresponding test case identifier, the type of testing and a short description.

• For formalized test cases, JUnit gives the test result based on the source code, while it gives "pass" or "fail" in informal cases.




Table 1. Some more concrete test cases.









14.1.58. 14.1.2 Literatures




Recommended literatures

• Larman, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR 2004.

• OMG, Object Management Group UML Profile for Schedulability, Performance and Time. http://www.omg.org/cgi-bin/doc?formal/2005-01-02 2005.

• Sun Microsystems The Java Database Connectivity (JDBC). http://java.sun.com/javase/technologies/database/index.jsp

• JBoss (Red Hat Middleware): Hibernate http://www.hibernate.org


Recommended literatures

• Sun Microsystems Java Persistence API http://java.sun.com/javaee/technologies/persistence.jsp

• Sun Microsystems Java Message Service http://java.sun.com/products/jms/

• Apache The Apache Ant Project http://ant.apache.org

• JUnit JUnit http://www.junit.org


Documents

regi.tankonyvtar.hu€¦ · Web viewComponent-Based Software Development. Szendrei, Rudolf. Component-Based Software Development. írta Szendrei, Rudolf. Publication date 2015