Static and Dynamic Structure in Design Patterns Eric

























![Related Work n Language-based approaches n n Lay. OM [Bosch, JOOP ’ 98] Metaprogramming-, Related Work n Language-based approaches n n Lay. OM [Bosch, JOOP ’ 98] Metaprogramming-,](https://slidetodoc.com/presentation_image_h2/7f8a1d4656d6fa35621375a1f02c4d39/image-26.jpg)


- Slides: 28

Static and Dynamic Structure in Design Patterns Eric Eide John Regehr Alastair Reid Jay Lepreau University of Utah, School of Computing May 22, 2002 1

OSKit Components Systems software components n Many taken from Linux, Free. BSD, … n Largely written in C; 1 M+ LOC n Remote debug Free. BSD libc Memory Mgr. Boot loader OSEnv Linux ext 2 fs Threads SCSI driver IDE driver Mini libc Registry VM Lock wrapper Console Block device Sched. Free. BSD net Locks SNMP 2

OSKit Components Want reuse, with minimal modification n Want to combine in myriad ways n Want to understand the resulting systems n Remote debug Free. BSD libc Memory Mgr. Boot loader OSEnv Linux ext 2 fs Threads SCSI driver IDE driver Mini libc Registry VM Lock wrapper Console Block device Sched. Free. BSD net Locks SNMP 3

Idea: Design Patterns Capture systems design expertise n Leverage shared knowledge base n Useful throughout software lifecycle n Client Block. Device Abstract. Factory Concrete. Factory 1 Concrete. Factory 2 IDE Device Abstract. Product. A 1 Product. A 2 Abstract. Product. B 1 Product. B 2 IDE Blk. IO IDE Info 4

Idea: Design Patterns? “Legacy” C code n No language-supported classes, objects n Conventional OO approach: too dynamic n Client Abstract. Factory Concrete. Factory 1 Abstract. Product. A 1 Product. A 2 Concrete. Factory 2 Abstract. Product. B 1 Product. B 2 ? ? Block. Device IDE Blk. IO IDE Info 5

Motivation Apply design patterns in context of CBD n Make patterns explicit/obvious at the level of components n Avoid changing the components’ code n 6

Key Ideas n Separate the static and dynamic parts of design patterns “lift” static parts to level of components n realize dynamic parts with objects n n Leverage unit component model [Flatt and Felleisen, PLDI ’ 98] n Implemented for C, Java, Scheme n 7

Contributions n n Describe our approach to realizing patterns Define a method for realizing existing patterns via our approach, applicable to: n n …imperative, functional, and OO languages …many existing (Go. F) patterns Demonstrate with examples from the OSKit Evaluate benefits and costs of our approach n n n increased opportunities for reuse verification of architectural constraints performance optimizations 8

Units n n n n Imports Exports Interfaces Connections Hierarchy Multiple instances Separate language C, Java, Scheme I_Export 1 I_Export 2 I_Export 1 Widget I_Import 1 * * I_Export 2 Gadget I_Import 2 I_Import 1 I_Import 2 9

Units n n Parts of a static assembly, not run-time values Import/export types and classes Constraints, build-time constraint checking Optimization via crosscomponent inlining I_Export 1 I_Export 2 I_Export 1 Widget I_Import 1 * * I_Export 2 Gadget I_Import 2 I_Import 1 I_Import 2 10

Expressing Patterns with Units n n n Example: protect a nonthread-safe component with a lock Solution: apply Decorator pattern OO approach: n n one or two abstract classes two derived classes run-time: create objects, links OO approach hides static properties of the system Component Non-Thread-Safe Component Decorator Thread-Safe Decorator obj = new TSDecorator( new NTSComponent(…)) res = obj->op(…) 11

Expressing Patterns with Units n Our solution: apply Decorator at the level of units n n n one interface three components build-time instantiation, connection, and encapsulation build-time constraint checking Architecture is clear, enforced, and localized at the component level I_Component Decorator I_Component res = op(…) 12

Method for Expressing Patterns n General task: identify parts of the pattern that correspond to static knowledge n “lift” that knowledge out of code n realize via unit definitions and connections n Necessarily specific to individual uses of a pattern n But, general process can be described as translation from OO description to units n 13

Method for Expressing Patterns n Example: OSKit block I/O device drivers Client Block. Device IDE SCSI Blk. IO Floppy Driver. Info IDE Blk. IO IDE Driver. Info SCSI Blk. IO Floppy Blk. IO SCSI Driver. Info Floppy Driver. Info 14

Method for Expressing Patterns 1. Identify the abstract classes/interfaces. Client Block. Device IDE SCSI Blk. IO Floppy Driver. Info IDE Blk. IO IDE Driver. Info SCSI Blk. IO Floppy Blk. IO SCSI Driver. Info Floppy Driver. Info 15

Method for Expressing Patterns 2. Identify static and dynamic participants. Client Block. Device IDE SCSI Blk. IO Floppy static Driver. Info IDE Blk. IO IDE Driver. Info SCSI Blk. IO Floppy Blk. IO SCSI Driver. Info dynamic Floppy Driver. Info 16

Method for Expressing Patterns 3. Define interfaces for static participants. Client Block. Device I_Block. Device IDE SCSI Blk. IO Floppy Driver. Info IDE Blk. IO IDE Driver. Info SCSI Blk. IO Floppy Blk. IO SCSI Driver. Info Floppy Driver. Info 17

Method for Expressing Patterns 4. Define interfaces for dynamic participants. Client Block. Device I_Block. Device IDE SCSI Blk. IO Floppy Driver. Info I_Blk. IO IDE Blk. IO I_Driver. Info IDE Driver. Info SCSI Blk. IO Floppy Blk. IO SCSI Driver. Info Floppy Driver. Info 18

Method for Expressing Patterns 5. Unit defn. for each concrete participant. Client Block. Device I_Block. Device IDE SCSI IDE Floppy I_Blk. IO I_Driver. Info IDE Blk. IO IDE Driver. Info SCSI Blk. IO Floppy Blk. IO I_Driver. Info IDE Blk. IO IDE Driver. Info SCSI Driver. Info Floppy Driver. Info 19

Method for Expressing Patterns 6. Instantiate and connect participant units. I_Block. Device Client Block. Device I_Block. Device IDE SCSI IDE Floppy I_Blk. IO I_Driver. Info IDE Blk. IO IDE Driver. Info SCSI Blk. IO Floppy Blk. IO I_Driver. Info IDE Blk. IO IDE Driver. Info SCSI Driver. Info Floppy Driver. Info 20

Method Wrap-Up n Modify as needed for other considerations n n match existing code, e. g. , static/dynamic decision remove participants in multiple patterns aggregate parts to simplify Client I_Block. Device IDE I_Blk. IO I_Driver. Info IDE Blk. IO IDE Driver. Info 21

Method Wrap-Up n n n More complicated FS example in paper Applicable to many (Go. F) pattern uses; see paper Commonly, much pattern knowledge is static ton e l g Sin tor a r co e D er t p a Ad ory t c Fa. s Ab er t p a Ad ory t c a F. s Ab ton e l g Sin tor a r co e D er t p a Ad and m m Co gy e t a Str 22

Analysis n Static pattern information is located in a single place unit-based specification of the system n “resolved” when the system is built n Unit language is designed specifically for describing components and their linkages n Pattern realization can be moved out of components’ implementations n 23

Benefits n Increased opportunities for code reuse n n n Ability to check architectural constraints n n n disentangled “pattern role” code; multiple patterns applicable when code cannot be changed (legacy) global, high-level, domain-specific checks checker need not understand the base language Enabled performance optimizations n n cross-component inlining… …enables more significant optimizations 24

Costs Only the static parts of a pattern are specified by our approach n Participants are committed to being static or dynamic n Unit descriptions can obscure the differences between patterns n To achieve full benefits, our approach requires support for the unit model n 25
![Related Work n Languagebased approaches n n Lay OM Bosch JOOP 98 Metaprogramming Related Work n Language-based approaches n n Lay. OM [Bosch, JOOP ’ 98] Metaprogramming-,](https://slidetodoc.com/presentation_image_h2/7f8a1d4656d6fa35621375a1f02c4d39/image-26.jpg)
Related Work n Language-based approaches n n Lay. OM [Bosch, JOOP ’ 98] Metaprogramming-, template-, and macrobased approaches [Marcos et al. , ’ 99] n [Alexandrescu, ’ 01] n [Krishnamurthi et al. , ESOP ’ 99] n n ADLs and MILs 26

Conclusions n n Common pattern applications contain a great deal of exploitable static knowledge Separating the static and dynamic parts of design patterns can yield significant benefits n n improved opportunities for reuse ability to check architectural constraints enabled performance optimizations Paper presents a method for obtaining these benefits via the unit model, applicable to: n n …many existing patterns …imperative, functional, and OO languages 27

Thanks! n http: //www. cs. utah. edu/flux/ 28