![When good architecture goes bad Mark Dalgarno Software Acumen Email: [email_address] Blog: blog.software-acumen.com Image: www.touregypt.net/featurestories/pyramidcore2.jpg](https://image.slidesharecdn.com/markdalgarno-whengoodarchitecturegoesbadepicenter2010-100615175927-phpapp01/85/Mark-Dalgarno-When-Good-Architecture-Goes-Bad-epicenter-2010-1-320.jpg)
![Architecture decay (a.k.a. Software erosion) ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (9)
Más de IrishDev.com
Último
Último (20)
Mark Dalgarno: When Good Architecture Goes Bad - epicenter 2010
- 1. When good architecture goes bad Mark Dalgarno Software Acumen Email: [email_address] Blog: blog.software-acumen.com Image: www.touregypt.net/featurestories/pyramidcore2.jpg
- 6. Results from our recent consultancy work 11 C/C++ projects varying from 10 KLOC to 800 KLOC EROSION
- 13. The costs of software erosion Figure © Axivion GmbH 2008. Used with permission.
Notas del editor
- Introduce self, work. Interactive, ask questions. Find out a bit about audience, any drive-by-developers or drive-by-architects? Software Architecture - The fundamental organization of a system, embodied in its components, their relationship to each other and the environment, and the principles governing its design and evolution. – IEEE 1471-2000 The Meidum pyramid was built in different stages, beginning as a seven-step pyramid to which an additional step was added at a later stage.
- These don’t inevitably indicate a problem but point to places where further analysis is required. Problems in class, package, sub-system and layer relationships. Encapsulation violations. Sub-system APIs bypassed, strict layering violated . Cyclic dependencies. Linear inheritance hierarchies or very deep inheritance hierarchies. Insufficient decomposition Monolithic Classes / Packages/ Subsystem – at the extreme no subsystems. Too much decomposition Ultra small packages. Obsolescence Imported but unused packages. Inclusion of dead code. Overgeneralization System more complex than it needs to be, sunk investment. Can’t understand system with cyclic dependencies just by looking at one place. Split up where there is insufficient decomposition to separate concerns and to aid comprehension. No subsystems – Example - (1989) (200 Kb animation application written in Lisp) – single file, never mind multiple subsystems!
- Researchers compared two versions of Ant System built in three layers taskdefs, ant, utils . V1.4.1 (11 October 2001) Layers well-separated. ant layer monolithic but small. V1.6.1 (12 February 2004) ant layer dependent on taskdefs (upward dependencies). ant layer still monolithic but now very large.
- Researchers compared two versions of Ant System built in three layers taskdefs, ant, utils . V1.4.1 (11 October 2001) Layers well-separated. ant layer monolithic but small. V1.6.1 (12 February 2004) ant layer dependent on taskdefs (upward dependencies). ant layer still monolithic but now very large.
- Literature shows 20% typical Here we’re seeing 2% - 32%
- Perceived architecture differs from architecture as-is => System not understood, can’t plan accurately – effort, risk, resources for changes Hard to make changes – software brittle or requires a lot of distributed changes to make one ‘small’ change. Note - http://turingmachine.org/opensource/papers/godfrey2000.pdf – different parts of a system may decay at different rates. The software is maintained by whoever happens to be around.
- 5-10 minute exercise, gather stories on flipchart
- Environmental factors could include staff churn (knowledge / skill loss) . Insufficient value placed on architectural integrity (potential for future change, difficulty of making modifications in future, difficulty of understanding system in future)
- One can also consider whether Programming languages have the necessary mechanisms to ensure architectural integrity.
- Is the architect an advisor who offers the project team a best-practice approach but is not responsible if they don’t take his or her advice or are they setting out exactly what the team must do and he / she has the power to force them to act according to his / her architectural guidance? Question: Who doesn’t undermine architectural integrity? – QA, documentation?
- 5 – 10 minute stand-up session after exercise with each group saying what they spoke about.
- Productivity is consequently significantly reduced as erosion sets in.
- STSC - "Software Technology Support Center" (STSC), has investigated the extent to which a satisfactory or defective inner structure influences the cost of further software development. A system with 50,000 lines of code was investigated; the aim was to extend it by the addition of about 3,000 lines of code. Source Hello2Morrow.com SonarJ whitepaper.
- 5 – 10 minute stand-up session after exercise with each group saying what they spoke about.
- Sustainable: Satisfies the current needs while maintaining the option (for future generations) to satisfy future needs. Use evolution scenarios to prove architecture. Expectations: Support ongoing development with minimal additional effort. Enable future additions and extensions. Keep the system and its structures intact. Be one step ahead – but in which direction? Visualization of software structure and flow Show what the architecture as-is is really like. Compare it to the architecture as-intended . McCabe – cyclomatic (or conditional) complexity – number of independent paths through code. Metrics indicate possible problems How to interpret them? Where to set boundaries of acceptable deviation from architecture? The smelliness of an architectural smell is a subjective concept – tools must be parameterisable. Evaluating smells requires architectural experience – role of the architect. Lots of data present – identify wheat from chaff using trends. Several tools have APIs that allows test to be written to ensure that no unwanted dependencies are introduced into the system. Visualization Structure and Flow (flow analysis). Other architectural views need a corresponding visualization. Heuristics Clean-up relationships between classes, packages and sub-systems before cleaning up individual classes, packages and subsystems Chaotic internal structure can be quarantined, chaotic external structure infects the whole system. Might be problematic if different people own different entities Architecture Analysis and assessment methods Applicability to enforcing architectural integrity? Can analyse start point for maintainability, evolvability – postulate scenarios Clone Detection is another capability to think about. Studies show that on average 20% of an application consists of cloned code. Some studies show significantly higher percentages (95% NUS Jarzabek). Is Clone Detection an architectural issue -> affects maintainability. Responsibilities could be unclear where clones exist. To patterns (architectural styles, design patterns) Use Heuristics Clean-up relationships between classes, packages and sub-systems before cleaning up individual classes, packages and subsystem. Use many small refactorings? Easier to manage. System available for longer. But, architecture smells often require larger refactorings. Refactoring outcomes can be hard to predict May not be clear what the quality effects are for example, may be some doubt over outcomes. Remember to refactor your intended architecture – it may not meet current requirements. Ignorance of the techniques / tools Focus on cost of tools rather than value of tools How often to apply the techniques Continuous architecture monitoring - like having a test framework in place to check code as it’s modified you can have a framework in place to check architecture as it’s modified. Easier to modify architectural ‘tests’ than code tests as architecture is evolved? (Fewer tests?)
- Lehman - Architectural decay is inevitable unless you actively take steps to combat it.