CSE870: ChengCSE870: Advanced Software Engineering(Cheng) 1CSE870: Advanced Software Engineering: Frameworks (Cheng) 1RRRFrameworksA Brief IntroductionCSE870: Advanced Software Engineering: Frameworks (Cheng) 2RRRAssigned Reading• Designing Reusable Classes: Johnsonand Foote (JOOP88)– Original Frameworks paper– Gives guidelines for creating frameworks– Motivates frameworks• See Handouts and Links web pageCSE870: Advanced Software Engineering: Frameworks (Cheng) 3RRRFramework• Support reuse of detailed designs• An integrated set of components:– Collaborate to provide reusablearchitecture for– Family of related applicationsCSE870: ChengCSE870: Advanced Software Engineering(Cheng) 2CSE870: Advanced Software Engineering: Frameworks (Cheng) 4RRRFrameworks1. Frameworks are semi-complete applications• Complete applications are developed byinheriting from, and•Instantiating parameterized frameworkcomponents2. Frameworks provide domain-specificfunctionality• Ex.: business, telecommunication, dbases,distributed, OS kernels3. Frameworks exhibit inversion of control atrun-time• Framework determines which objects andmethods to invoke in response to eventsCSE870: Advanced Software Engineering: Frameworks (Cheng) 5RRRClass Libraries vs Frameworks vsPatterns• Definition:– Class Libraries:• Self-contained,• Pluggable ADTs– Frameworks:• Reusable, semi-complete applications– Patterns:• Problem, solution,contextApplicationSpecificLogicNetworkingMathDbaseADTsUIEventLoopInvokesClass Library ArchitectureApplicationSpecific LogicMathADTsEventLoopUINetworkingDbaseInvokesCall BacksFramework ArchitectureCSE870: Advanced Software Engineering: Frameworks (Cheng) 6RRRComponent Integration inFrameworks• Framework components are loosely coupledvia “callbacks”• Callbacks allow independently developedsoftware to be connected together• Callbacks provide a connection-point– Generic framework objects communicate withapplication objects– Framework provides common template methods– Application provides the variant hook methodsCSE870: ChengCSE870: Advanced Software Engineering(Cheng) 3CSE870: Advanced Software Engineering: Frameworks (Cheng) 7RRRPatterns vs Frameworks• Patterns and frameworks playcomplementary, cooperative roles• Patterns are more abstract descriptions offrameworks– Frameworks are implemented in specific language• Complex frameworks may involve dozens ofpatterns• Patterns may document frameworksCSE870: Advanced Software Engineering: Frameworks (Cheng) 8RRRGUI Framework• Model/View/Controller (MVC):– Smalltalk-80 UI framework• UI: 3 types of components:– models, views, controllers– view and controller objects interacting with model• Model: application object, UI-independent• View: manages region of display– Keeps it consistent with state of model– Can be nested to form complex UIs• Controller: converts user events (e.g., mouse movementsand key presses) into operations on its model and view– Implement scrolling and menusCSE870: Advanced Software Engineering: Frameworks (Cheng) 9RRRExample MVC• Model: FileBrowser• Views:– Top subview: String that is Pattern that matchesset of files (e.g., *.h)– Middle subview: displays list of files that matchpattern (e.g., Node.h, Int_node.h, etc.)– Bottom Subview: displays selected file– TextView (Top and Bottom subviews)– SelectionInListView: (Middle subview)• Controller:– Controller for each view– Mouse move from subview, activating differentviewsCSE870: ChengCSE870: Advanced Software Engineering(Cheng) 4CSE870: Advanced Software Engineering: Frameworks (Cheng) 10RRRVariations of MVC Framework• MacApp (Macintosh applications)• Andrew Toolkit (CMU 88)• InterViews (Stanford 89)• Commercial:– zApp (OS-independent)– OpenStep (part of much bigger, comprehensivesystem)– Microsoft Foundation ClassesCSE870: Advanced Software Engineering: Frameworks (Cheng) 11RRRKey PrinciplesHow to develop successful patterns and frameworks1. Separate interface from implementation2. Determine what is• Common interface and (common -> stable)• Variable implementation3. Allow substitutions for variable implementationsvia a common interfaceDividing commonality from variability should be goaloriented rather than exhaustiveCSE870: Advanced Software Engineering: Frameworks (Cheng) 12RRROpen/Closed Principle• Determining common vs variable components isimportant– Insufficient variation makes it hard for users to customizeframework components– Insufficient commonality makes it hard for users tounderstand and depend upon framework’s behavior• Generally, dependency should always be in thedirection of stability– Component should not depend on any component lessstable than itself• Open/Closed Principle:– Allows most stable components to be extensibleCSE870: ChengCSE870: Advanced Software Engineering(Cheng) 5CSE870: Advanced Software Engineering: Frameworks (Cheng) 13RRROpen/Closed Principle• Components should be:– Open for extension– Closed for modification• Implications:– Abstraction is good– Inheritance and polymorphism are good– Public data members and global data are bad– Run-time type identification can be badCSE870: Advanced Software Engineering: Frameworks (Cheng) 14RRRViolating Open/Closed PrincipleStruct Shape {/* . . . */};Class Square : public Shape { /* . . . */}Class Circle : public Shape { /* . . . */}void draw_square {const Square &);void draw_circle {const Circle &);void draw_shape (const Shape &shape) {switch (shape.shapeType) {case SQUARE:draw Square ((const Square &) shape);break;case CIRCLE:draw Circle ((const Square &) shape);break;// etc.CSE870: Advanced Software Engineering: Frameworks (Cheng) 15RRRApplying Open/Closed Principleclass Shape {public:virtual void draw () const = 0;};void draw all (const Shape &shape){shape.draw ();}CSE870: ChengCSE870: Advanced Software Engineering(Cheng) 6CSE870: Advanced Software Engineering: Frameworks (Cheng) 16RRRObservations of Frameworks• Benefits of frameworks:– Enable direct reuse of code– Enable larger amounts of reuse than standalonefunctions or individual classes• Drawbacks:– High initial learning curve• Many classes, many levels of abstraction– Flow of control for reactive dispatching is non-intuitive– Verification/validation of generic components
View Full Document
Unlocking...