8. Framework architectures

Transkriptio

1 8. Framework architectures 8.1 Introduction 8.2 Framework types 8.3 Developing frameworks 8.4 Frameworks and design patterns 8.5 Example: A simulator framework 8.6 Benefits and potential problems 8.7 Discussion 1

2 8.1 Introduction Motivation Product-line architecture: architecture for a software system family (similar systems sharing structure and functionality) Central aim: software reuse Prerequisite: the system family has sufficiently common features Framework = OO implementation technology for product-line platforms (architecture and basic common functionality) 2

3 What is a framework? Framework A collection of classes implementing the basic architecture for a family of software systems, to be specialized into an application using interface implementation inheritance creation and composition of objects instantiation of generic structures reflection 3

4 Cost benefits of frameworks: example A real videogame framework Trad. 1. game 2. game 3. game personhours Framework Developing framework + training 1. game 2. game 3. game Performance: time +70% space +200% 4

5 Framework is specialized into an application Framework Applicationspecific part control Specialization interface 5

6 Framework is specialized into an application Framework Applicationspecific part control Specialization interface 6

7 Application framework vs. library Subclasses, components, Application specific code Application Reusable code Application framework Classes, modules Hollywood principle: don t call us, we call you 7

8 8.2 Framework types Application framework: specialization = application Framelet: specialization = component White-box framework: specialization using inheritance Black-box framework: specialization using composition Component framework: specialization using interfaces & components Abstract framework: consists of interfaces Layered framework: consists of stepwise specialized layers 8

9 White-box frameworks A B 9

10 Black-box frameworks A B <<create>> 10

11 Component frameworks 11

12 Example framework: simulating creature populations 12

13 <<framework>> SimulationFW White-box framework <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() * World getsize(): int add(creature) remove(creature) show() simulate(int, CreatureFactory) <<interface>> CreatureFactory 1 createcreature(): Creature DefaultCreature <<create>> DefaultCreatureFactory xcoord ycoord age setmyworld(world)... die() <<create>> createcreature(): Creature EatingCreature energy interact(creature) SimulationApp main() <<create>> <<create>> EatingCreatureFactory createcreature(): Creature 13

14 <<framework>> SimulationFW Black-box framework <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() * World getsize(): int add(creature) remove(creature) show() simulate(int,creaturefactory) <<create>> <<interface>> CreatureFactory 1 createcreature(): Creature DefaultCreatureFactory DefaultCreature xcoord ycoord age setmyworld(world)... die() EatingCreature energy interact(creature) <<create>> <<create>> createcreature(): Creature EatingCreatureFactory createcreature(): Creature SimulationApp <<create>> main() 14

15 <<framework>> SimulationFW Abstract framework <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() * <<interface>> World getsize(): int add(creature) remove(creature) show() simulate(int,creaturefactory) <<interface>> CreatureFactory 1 createcreature(): Creature MyCreature World MyCreatureFactory xcoord ycoord clock size createcreature(): Creature setmyworld(world)... die() getsize(): int simulate(int,creaturefactory) <<create>> SimulationApp <<create>> <<create>> main() 15

16 <<framework>> SimFrame Framelet Component framework <<framework>> FighterSimFrame <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() * <<interface>> World getsize(): int add(creature) remove(creature) show() simulate(int) <<interface>> Fighter take(weapon) FighterCreature <<interface>> Weapon aim(creature) SpecFighterWorld getsize(): int add(creature) remove(creature) show() simulate(int) Sword <<create>> <<create>> <<create>> Manager main() 16

17 Monolithic frameworks vs. framelets Application Framework Specialization Component Component Monolithic framework Specialization Framelet Specialization Framelet 17

18 Layered and hierarchical frameworks 18

19 Layered and hierarchical frameworks 19

20 Layered framework Ant simulation product Ant simulation framework Insect simulation framework Default implementations Abstract simulation framework 20

21 Layered framework Network management applications Network management framework Swing AWT 21

22 Hierarchical framework Simulation products Ant simulation framework Spider simulation framework Insect simulation framework Rodent simulation framework Whale simulation framework Mammal simulation framework Default implementations Abstract simulation framework 22

23 8.3 Developing frameworks Variability requirements Specialization patterns Specialization guide Domain analysis Architecture design Detailed design Implementation Testing Design pattern catalogs 23

24 Flexibility requirement: Creature variation Structure DefaultCreature move show getx gety interact die growold Specialization pattern NewCreature move show getx gety interact die growold Explanations DefaultCreature: Default implementation for creatures NewCreature: Application dependent creature type move: Single movement behavior show: Displays creature on screen interact: Interaction between two creatures die: dying of a creature growold: aging of a creature Constraints move: must call "show" die: must remove the creature from the world growold: must increase age Example class NewCreature extends DefaultCreature { int energy; public NewCreature(int x, int y, int e) { super(x, y); energy = e; } public void move() { xcoord = (xcoord+1)%myworld.getsize(); show(); } public void show() {...} } public void interact(abstractcreature c) { if (c!= this && c instanceof NewCreature) { if (((NewCreature)c).energy < energy) { c.die(); } } } 24

25 Role-based specialization patterns Tool Application setup... instantiate RectangleTool... RectangleTool <<create>> Concept Client Instantiation Code ConcreteImpl instantiate 25

26 Role-based specialization patterns Tool Concept Client Instantiation Code ConcreteImpl instantiate 26

27 Tool support: JavaFrames Architecture-sensitive Java editor Current binding situation (containment tree) Adaptive tasks & instructions See 27

28 8.4 Frameworks and design patterns AbsFactory createbutton(): Button createmenu(): Menu Framework (fixed part) GUI WinFactory Button Menu <<create>> WinButton WinMenu Application (variable part) 28

29 Typical design patterns supporting variation in a framework Template Method Strategy Chain of Responsibility Decorator Factories (e.g. Abstract Factory, Factory Method) Observer... 29

30 Template Method design pattern Problem: How to make static variations of a method? 30

31 Strategy design pattern Problem: How to change the implementation of a method at run-time during the lifetime of the host object? 31

32 Chain of Responsibility design pattern Problem: How to give more than one object (component) a chance to handle a service request, without making the sender of the request dependant of the receivers. 32

33 Decorator design pattern Problem: How to attach additional responsibilities to an object dynamically. 33

34 Observer Problem: How to let a set of objects respond to state changes of another object, without making the latter object dependent on the former ones. 34

35 Abstract Factory design pattern Problem: How to allow the creation of a members of a consistent family of entities, withouyt knowing the concrete entity classes? 35

36 8.5 Example: Simulation framework CoreRoot DefaultRoot EatingRoot dependency direction Logical dimension CoreGui DefaultGui EatingGui CoreManager DefaultManager EatingManager CoreFactories DefaultFactories EatingFactories CoreView DefaultView EatingView CoreModel DefaultModel EatingModel Specialization dimension 36

37 Layer analysis: logical dimension row depends on col Root Gui Manager Factories View Model Root X X X Gui X Manager X X X Factories X X View X Model 37

38 Layer analysis: specialization dimension row depends on column Eating Default Core Eating X X Default X Core 38

39 Class/interface categories Base Implementation which is assumed to be reused by all applications (final methods) Appears in the Core packages together with interfaces (no naming conventions for interfaces) Default Implementation which is assumed to be reused by many applications Appears in the Default packages Eating Implementation needed only for specialization X Appears in the Eating packages 39

40 Hints for Java framework development (1) General be careful about the law of gravity: is this functionality really something that all applications must have? default implementation should give a typical minimal application (never absolutely necessary implementation) make likely variations easy to implement, unlikely variations can be more difficult to implement threading is one way to combine frameworks divide long method bodies into calls of protected methods, to support fine-grained functional variability (defines order of actions, but not the contents) use final methods for non-variable behavior 40

41 Hints for Java framework development (2) Initializations only absolutely fixed things in straight constructor code, everything else in calls of separate protected methods default value settings into separate protected methods don't initialize in field declarations reusing objects is possible if public initialization is separated from constructor 41

42 8.6 BenefitsB and potential problems Benefits of frameworks as implementation technology for product-lines: lots of experience (e.g., GUI frameworks) straightforward OO technology allows both coarse and fine-grained specialization supports open-ended specialization process supports layered & hierarchical approaches 42

43 Potential problems of frameworks Designing a (good) framework is hard, often iterative Combining frameworks may be hard Frameworks may become monolithic and difficult to manage Non-functional variance difficult to implement Business-critical architects (reduces truck factor) Debugging of applications difficult without framework source 43

44 8.7 Discussion Application or application framework? Good OO application is often a specialization of an (implicit) framework 44

45 Do not apply the framework approach if you don't have thorough understanding of the domain for which you are going to build a framework; you have not built several applications already in the application domain; you don't have long experience in using OO methods, OO languages and design patterns; you cannot split the domain into manageable pieces, so that you would end up with a huge, monolithic framework instead of a number of small frameworks; the management is not committed to a long, possibly unpredictable framework development project. 45

46 Summary Framework technology is adopted by more and more enterprises, reported experiences mostly positive Product-line architecture can be implemented as a framework A framework may be a significant strategic advantage for an enterprise The development of a framework is much more difficult than that of a normal application To reduce the risk, do not make very large white-box frameworks 46