Region # | Encapsulation | Data Hiding | Separation of Concerns | Tactic When Enhancing, Modifying, Fixing or Reusing |
1 | good | good | good | Best chance of success; try not to introduce global data references or call additional modules. |
2 | good | poor | poor | Pinpoint the used global data to see if the modifications affect it. Check how the called modules are affected by the prescribed changes. |
3 | poor | good | poor | Check the effects on called modules. Make sure the changes are not referencing global data. |
4 | poor | poor | good | These ‘leaf’ modules tend to be the most reused—keep it that way by not calling new modules. Be wary of the global data referenced—just pulling the module for reuse without its global data will not work. |
5 | good | poor | good | The main issue is global data—do not try to reuse without its global data environment. |
6 | poor | good | good | Good chance of success here. Not much local data used so this is probably highly computational. Also reusable since not dependent on called modules. |
7 | good | good | poor | This could be a transaction driven module calling several subordinates. Looks clean except for the substructure it calls. When reusing you may need all the modules it calls. |