CSSE 477 – Intro to Modifiability

1. CSSE 477 – Intro to Modifiability Steve Chenoweth Friday, 9/23/2011 Week 3, Day 4 Right - A modified VW beetle, from http://www.classiccar.com/garage/blog/index.php?/categories/6-Classic-Car-Pictures/P2.html.

2. Today • If perchance your team didn’t turn in Project 2 last night, please do this by tonight! • Please also do the team member peer evaluation on Angel • How to do Project 3… • Work with a team of “implementers” about “what to modify.” • If we run out of time, we’ll do this Monday • Software modifiability – this  • Bass’s Ch 4 (pp 80 - 82) and Ch 5 (pp 105 - 111). • For a whole lot more, see the last term’s OO Design book (Larman)! • You had lots of discussion also in CSSE 375. • Here we take an architectural view! • Great reference – Bachman, Bass & Nord’s article, “Modifiability Tactics” (2007) - http://www.sei.cmu.edu/pub/documents/07.reports/07tr002.pdf.

3. We next pick modifiability from Bass’s QA list… • Bass’s list of six, from the inside back cover of his book: • Availability • Modifiability • Performance • Security • Testability • Usability

4. And here’s the project about it: • On the project where you were designers, • Determine the modifiability of your current project system – actually, of something specific about it, and try to improve on that modifiability. • Implement a tactic to improve this by a designated amount! • We’re also going to study how to document the arch, so: • An added feature of this project – start a draft of that, for your sys. And a first step to take today: • Brainstorm with your assigned “implementers” about what new features you might add. Perhaps something you or they haven’t ever considered… • These will be a “target” for making changes efficiently. • Divide into two “equal” sets of changes, so that these appear to be of about equal difficulty. • Try to make each group “not homogenous,” in terms of what’s changed. It is especially good if each set includes changes to the same areas as the other set. • Turn those in, in your “team journal” by 11:55 PM. Next steps – By Tuesday, do the first set, timing how long it takes. And, decide how to make your system “more modifiable.”

5. Let’s do some basics… Brad being optimistic Brad Appleton’s take: • The Modifiability of a software system is related to how minimal is the cost/effort to develop and deploy changes to the software. • This relates to well known concepts and principles of coupling, cohesion, maintainability, etc. and is the basis for many of the elements of object-oriented, component-based, and aspect-oriented design ("reuse" is a close cousin for all these as well). From http://bradapp.blogspot.com/2008/03/software-modifiability-tactics.html.

6. More basics… Alistair Cockburn’s take: • “Software development is a cooperative game – using props and markers to remind and incite, to reach the next move. • The endpoint of the game is a delivered system. • The next game is to alter or replace the system.” Alistair showing ‘tude From http://alistair.cockburn.us/Software+development+as+a+cooperative+game

7. More basics… Steve’s take: • There are tradeoffs – foresight and planning versus time to market for R 1.0. • Getting developers and testers familiar with the domain, and the OO domain model, is a big win. • It’s theoretically impossibleto foresee all the areas of future change. Spooky crystal ball gazer from www.e-tarocchi.com/crystalball/index.php .

8. What’s Bass say about this QA? • Scenarios – What’s in “The Notes” at the end of the supplementary spec template? • What is Modifiability “about” – Ch 4? • What are some good tactics – Ch 5?

9. Bass’s modifiability scenarios • Source: End user, developer, system administrator • Stimulus: Wishes to add/delete/modify/vary functionality, quality attribute, capacity • Artifact: System user interface, platform, environment, system that interoperates with target system • Environment: At runtime, compile time, build time, design time • Response: Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification • Response Measure: Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes

10. Example scenario • Source: Developer • Stimulus: Wishes to change the UI • Artifact: Code • Environment: At design time • Response: Modification is made with no side effects • Response Measure: In 3 hours

11. Modifiability situations 1. Change can occur to almost any aspect of the system: • What it computes • The platform it runs on • “Portability” • How big / fast this is • The environment it operates within • Like other systems it talks to, or • The protocols used Ch 4

12. Modifiability situations, cntd 2. Software changes typically are made to source code: • A developer makes it, and it’s tested and deployed (somewhere!) • So, a part of efficiency lies in things like “how to make each change just once” • Some changes are made on site, by others: • DB changes • Parameter changes • Script language changes

13. Syntax of Data (format) Service (signature) Semantics of Data (meaning) Service (how used) Sequence of Data (order sent) Control (steps) Identity of an interface of A (may have > 1) Location of A (runtime) Quality of service / data provided by A (accuracy, etc.) Resource behavior of A (how much used) Coupling = Ripple effects What kinds of dependencies module A can have with B? Ch 5

14. Additional considerations – different kinds of modifications • Corrective Change – changes to fix errors in requirements, design, logic, coding, documentation • Adaptive Change – changes for use in a new environment – most common, your component vendors require moving to a new version • Perfective Change – changes to meet new or different customer needs – most common, additional features • Preventative Change (special case of corrective) – change to fix errors before they occur (this term is not universally used) – e.g., you know some customers will move to Vista, fix your app so it will work there Things in CSSE 375…

15. Overall cost… • Maintenance = 50% to 95% of total system cost. • I.e., the initial development is < ½ of it • Logically, systems should be designed for ease of maintenance • Not for getting Rel 1 out the door fast • If you’re working on a system that already exists, you need to stop and “refactor” it for modifiability. • This is what we’ll do in the middle of Project 3!

16. A typical improvement… • We have DB accesses to get the data out of the same table, written all over the system. • With new changes we plan, there will be even more of these! • None of them have good error handling. So, • Create a new class that does the all the DB accessing from this table, with validity checks and other error handling.

17. Localize Changes (increase cohesion) Maintain Semantic Coherence Anticipate Expected [types of] Changes Generalize the Module Limit Possible Options Abstract Common Services Defer Binding-time (defer decision-making) Run-time Registration Configuration Files Polymorphism/Delegation Component Replacement Adhere to Defined Protocols Prevent Ripple Effects (reduce coupling) Hide Information Maintain Existing Interfaces Restrict Communication Paths Use an Intermediary (Proxy, etc.) Tactics to achieve modifiability See Bass, Ch 5

18. Project 3 – Modifiability Overall theme – • Do the first set of changes, and time how long they take. (Without improving modifiability.) • Implement a strategy for making changes more efficient (e.g., refactor the code) • Do the second set of changes, and time how long they take. • Report on how this “experiment” went. • See Project 3 for the details!