Software Plans Achieving FineGrained Separation of Concerns Design is

Software Plans: Achieving FineGrained Separation of Concerns Design is Difficult • Lots of heuristics: • • • • • Strive for high cohesion, low coupling of modules Encapsulate volatile design decisions Hide information in modules Abstract away details Separate concerns David Coppit The College of William and Mary • Design is always a compromise • The result: a dominant decomposition, with some scattering and tangling of concerns 1 2 3/11/05 Display Figure Point getX() getY() setX(int) setY(int) class Point { void setX(int x) { Logger.LogEntry(this); this.x = x; } } 2 Tangling in GNU sort * FigureElement Line getP1 setP1 setP1(Point) setP2(Point) class Line { void setP1(Point p1) { Logger.LogEntry(this); this.p1 = p1; } } static void xfclose (FILE *fp) { if (fp == stdin) { /* Allow reading stdin from tty more than once. */ if (feof (fp)) clearerr (fp); } else if (fp == stdout) { if (fflush (fp) != 0) { error (0, errno, _("flushing stdout")); cleanup (); exit (SORT_FAILURE); } } else { if (fclose (fp) != 0) { error (0, errno, _("closing file")); cleanup (); exit (SORT_FAILURE); } } } 3 4 Logging 1 Examples of Difficult Concerns Aspect-Oriented Programming • Extend the language to allow cross-cutting concerns to be modularized • [Kiczales, Tarr, Murphy, Griswold, …] • • • • • • Access control Synchronization System constraints Security Caching Logging Debugging Error-checking Platform dependence Domain-specific optimization • Alternative implementations • • • • • Aspect abstraction encapsulates scattered code • Compiler weaves aspects into classes • Joinpoints: well-defined locations in the program (field access, method call, etc.) • Pointcuts: declarative selection of joinpoints • Advice: code to insert 5 6 Example: AspectJ aspect Logging { pointcut traced(): (call(* Line.*) || call(* Point.*)); before(): traced() { Logger.log(“Entering:” + thisjoinpoint); } } class Point { void setX(int x) { this.x = x; } } class Line { void setP1(Point p1) { this.p1 = p1; } } 7 AOP Good For Scattering • Pointcuts very general • • • • • Method call/return Within some class Get/set of a field Exception handling Within call stack (cflow) • Aspects meant to be context-independent • Can hack context-dependent aspects by introducing dummy methods or refactoring to create needed join points 8 2 AOP Not Good For Tangling • “Invasive compositions” [Carver & Griswold 1999] fprintf(stderr, “%s: failed to open %s\n”, argv[0], szFilename); Problem Statement • AspectJ pointcuts poor for exposing and separating concerns [Murphy et. al 2001] int[] match( ... ) { // Multiline matching if (newline && (mymatch.offset > 0) && (input.charAt(idx - 1) == ’\n’)) return next(input,idx,eflags,mymatch); // Not BOL match if ((eflags & RE.REG_NOTBOL) > 0) return null; ... } 9 We lack the ability to separate and reason independently about tangled, context-dependent concerns 10 Learning from Other Disciplines Rethinking the Problem: Architectural Design 11 12 3 Floor Plan • Modules, interfaces • Context-dependent concerns Cross-Cutting Fasteners 13 14 Foundation Plan Roof Plan 15 16 4 Transverse to Reconcile 17 18 A New Idea: Software Plans • Multiple plans instead of one monolithic view • One concern, or a few related concerns • Necessary shared context Software Plans • Separate loosely-coupled, context-dependent concerns • Reduced size and complexity • Language independent • Accommodates variants (no more #ifdef DEBUG) • “Builder” resolves any complicated tangling 19 20 5 Example: Three Plans for GNU Sort static void xfclose (FILE *fp) { static void xfclose (FILE *fp) { if (fp == stdin) { /* Allow reading stdin from tty more than once. */ } if (feof (fp)) clearerr (fp); static void xfclosestdout)*fp) { } else if (fp == (FILE { if (fflush (fp) != 0) { error (0, errno, _("flushing stdout")); cleanup (); exit (SORT_FAILURE); } } } else { if (fclose (fp) != 0) { staticerror xfclose (FILE *fp) { file")); void (0, errno, _("closing cleanup (); exit (SORT_FAILURE); } } } } Key Research Questions • What’s a concern? • Where do they arise? • How tangled are they? • Do they cluster? • Is it technically feasible? • Need a richer model for code • Are there standard plans? Or are concerns inseparable? • Can the costs of use be reduced? • Do plans help? 21 22 Investigating Concerns [Revelle] • 2 case studies • Have two programmers identify concerns in code • Compare identified concerns, annotations Understanding Concerns • Analysis • % character overlap, % line overlap, file spread • Factors for agreement among programmers • Types of concerns • What is a concern? • How are concerns manifested in code? 23 24 6 Case Study #1: GNU sort • 2100 lines of C. Very feature-oriented • Revelle identified concerns • 50 concerns • User-level functionality, implementation details Case Study #1: Results • 23 concerns in common, with >80% average character overlap • Carver’s extra concerns related to system-specific issues such as releasing threads • Differences due to different levels of abstraction Modes • Carver data [Carver & Griswold 1999] • 83 concerns Sort Mode 25 Check Mode Merge Mode 26 Case Study #2: Minesweeper • 3000 lines of Java. Object-oriented • Revelle identified concerns • 30 concerns • User-level functionality, implementation details Case Study #2: Results • 13 concerns in common • Abstraction an issue again • Compared equivalence classes of concerns • All but 7 could be mapped • 25/39 had >80% character-level agreement Blanks • Broadbent identified concerns • 26 concerns Leading Blanks 27 Trailing Blanks 28 7 Affects of Abstraction and Spread 29 30 What We Learned • Programmers identify the same concerns when • They understand the code, language, context well if(currentCell.getState() != Cell.STATE_FLAGGED) Design Guidelines for Software Plans • • • • • Reduce or eliminate concern tagging Support fine-grained concerns Favor familiar editing operations Plans are associated with a unique set of concerns Support context code shared among plans • Minimize redundant editing of shared context code • They agree on the meaning of a concern • They work at the same level of abstraction • Relevance to Plans • Significant differences imply there is no “right way” • Need flexible definition of “concern” • Fine-grained manifestation of concerns in code • Editing a plan should not require knowledge of other plans • Editing a plan should not damage other plans • Concern code should be easy to differentiate • It should be easy to reconcile plans 31 32 8 Revising Code-As-Bytes Model to Support Software Plans 33 34 Difficulty: Editing Operations A New Model for Code [Painter] static void xfclose (FILE *fp) { if (fp == stdin) { /* Allow reading stdin from tty more than once. */ if (feof (fp)) clearerr (fp); } else if (fp == stdout) { if ( fflush (fp) != 0) { error (0, errno, _("flushing stdout")); cleanup (); exit (SORT_FAILURE); } } else { if ( fclose (fp) != 0) { error (0, errno, _("closing file")); cleanup (); exit (SORT_FAILURE); } } } 35 if(matched) { fprintf(STDERR, "DBG: Found match\n"); number_of_matches++; number_of_matches++; fprintf(STDERR, "DBG: Returning\n"); return; } Block: • Span of text • Set of related concerns 36 9 Plans: Sequences of Blocks Plan: 6 2 7 • Sequence of blocks (possibly repeated) • Set of related concerns Operations • Plan • • • • • • • • • 37 • View • ComputeView • InsertSpan • DeleteSpan AddBlock DeleteBlock SplitBlock MergeBlock AddBlockToPlan DeleteBlockFromPlan SplitBlock MergeBlock NewPlan Document: 1 2 3 4 • Set of blocks • Set of plans • Document • Clipboard • ImportBlocks • ExportBlocks 8 9 5 9 1 38 Editing Operation Example: Insert Span Editing Operation Example: New Plan 1 1 2 2 6 1×f 1 1 3 3 2 1×f2 4 1 2’’ 2’ 2 X 3 4 5 4 6 2’’ 2’ 2 7 6 7 1 39 2 Green 3 Yellow 4 White 6 Blue 6 40 10 Editor with New Code/Concern Model Demo & Conclusion 41 42 Conclusion • Tangling of cross-cutting concerns a problem • Loosely-coupled tangling can be separated • Context dependencies are important • Software plans offer a potential solution • Language-independent • Feasible: can be implemented in a natural way • Separates independent concern design from concern integration Future Work • • • • • • Global versus local edits Improved inferencing of block relationships Incremental update of merged plans Support for concern abstraction Analyze case study data w.r.t. tangling Port to Eclipse, and add features: • Automatic export to compiler • Concern annotations • Integration opportunities with AOP • Experimental evaluation (Need collaborators!) 43 44 11 Thank you http://www.cs.wm.edu/~coppit/ 45 12

Related docs
Plans for Software
Views: 5  |  Downloads: 0
design
Views: 0  |  Downloads: 0
Achieving High Software Reliability
Views: 6  |  Downloads: 2
Separation_of_duties
Views: 56  |  Downloads: 10
Other docs by X Scape