Writing in the current issue of ABB’s Review (www.oilit.com/links/1111_20), Aldo Dagnino, Pia Stoll and Roland Weiss describe the software architectural principles that guide its developers in what is described as a ‘fantastically complex chain of technological wonders [that] transport an oil molecule from subsea reservoir to the local gas station.’ ABB’s developers have been working for several years with researchers from the Carnegie-Mellon’s software engineering and human-computer interaction institute on software architectural principles. These broadly divide into two areas, ‘functional’ i.e. describing the essential actions or services provided by the software, or ‘non-functional’ i.e. aspects such as quality, usability and performance.
The authors also stress the importance of ‘sustainability’ in software development. For ABB, sustainability is not (just) a metaphor. Sustainability can be evaluated in terms of technological longevity, organizational and social impact, finance and the environment. Technical sustainability means that systems support both immediate use case and provide a platform for future maintainability and evolution. This includes issues such as developers’ skills and compatibility with other company’s products. Financial sustainability means assuring a decent return on investment from the developed software while minimizing re-work and avoiding the cost of poor quality. Software architectures can contribute to the environmental sustainability by, for example, limiting energy consumption of both the product and the processes it is controlling. Social sustainability is achieved by ‘simplifying the developers’ work, stimulating and motivating them.’
ABB distinguished four typical scenarios for software development requiring different approaches. The first scenario involves software revamp, starting with the evaluation of existing legacy tools using the Carnegie-Mellon ‘architecture tradeoff analysis method’ (ATAM—www.oilit.com/links/1111_21). ATAM looks at how different facets of software and the business case interact. In one trial, ATAM was used to evaluate a code-generating tool. It was not immediately clear whether the tool was optimizing for performance or code portability. ATAM demonstrated the tool was producing more performant code at the cost of reduced portability. Trade-off analysis determined that this was acceptable in view of the customer’s business case.
A different approach, ‘usability-supporting architecture patterns’ (USAP—www.oilit.com/links/1111_22) is used to develop new software tools. USAP stems from work done at Carnegie-Mellon along with NASA and the US Department of Defense. Like ATAM, USAP is all about trade-offs. A software system can have multiple conflicting aspects, for instance security and usability may pull in different directions. ABB has developed a web-based USAP delivery tool to visualize a software package’s components as they interact. The tool acts as an ‘experience factory’ holding reusable architectural knowledge for different system/environment interaction scenarios. Six hours use of the tool saved five weeks effort on one project by clarifying usability priorities early on.
ABB is carrying the torch for architectural principles by participating in an EU-funded research project Q-ImPrESS (www.oilit.com/links/1111_23). The project has developed a Java/Eclipse-based integrated development environment for design-time quality impact prediction.
© Oil IT Journal - all rights reserved.