Shreyas Devalapurkar's Personal Website

Article Analysis: Safety-Critical Software Engineering and Fault Tree Analysis

The article I chose to analyze is titled, “Fault tree analysis for composite structural damages” published by the Journal of Aerospace Engineering in 2013. The purpose of this article is to “introduce a fault tree methodology to synthesize various damage modes of composite structures by identifying possible damage causes [1].” Fault tree analysis (FTA) was introduced by Bell Laboratories, and is a “method in system reliability, maintainability, and safety analysis [2].” FTA is a deductive process wherein combinations of failures that could cause undesired events are tested using a tree structure. The top node of the tree is the undesired (or top) event, and the children are damage causes that can contribute/lead to the occurrence of the top event. As stated by Bill Vesely of Nasa, “Deductive models backwardly resolve the causes for an event [3].” This article applies the FTA method to the problem of reducing damage to composite airframes.

“In the past decade, the usage of composite materials in commercial aircraft has grown significantly [1].” The authors of the article state that these types of structures are “susceptible to impact damage caused by bird strike, hail and tools impact [1].” They go on to mention that the breakdown of such structures occurs due to multiple damage modes and their interactions. “FTA can model root causes and identity weak links of a large system [1].” In this study, the authors apply FTA to a variety of damage causes using a tree structure, and analyze the results on a macroscopic level [1].” The majority of the article discusses this analysis, for a carbon fiber reinforced plastic (CFRP) composite structure.

The two types of analysis performed in this study are qualitative and quantitative; however, for FTA the focus is qualitative data. The important aspects of this analysis are structure importance, probability importance, and relative probability importance analysis. Structure importance analysis “is to analyze the degree of importance of every basic event influencing the top event, regardless of its probability of occurrence [1].” Next is probability importance. According to Zeng et al., “probability importance reflects the influence of the unreliability of the basic event to that of the top event [4].” Finally, relative probability importance is introduced to “measure the variation of top event probability from the basic event itself [1].” In this study, the authors use these techniques to determine the importance ranking of various damage causes to the CFRP composite structure.

My stance on the topic of Fault Tree Analysis is that it is an extremely useful and beneficial technique in resolving the causes of any system failure. “It provides a framework for thorough evaluation of a root event [3]” that needs to be prevented from occurring. I believe that it is a valuable tactic in safety engineering as it can provide useful information about how certain aspects of a system can contribute to the damage of the overall system. This information is crucial as it can be used to identify “main damage contributors so that actions and resources can be prioritized [1].” The concept of FTA relates to software architecture because just like software architecture, FTA is a tool that gives engineers the ability to purposely design excellent and elegant systems. Knowing how a system can potentially fail, will allow engineers to preplan and develop systems that avoid or combat such failures. Software architecture focuses on system design, analysis, and validation; and since FTA provides a means for maintaining the system once it has been created, they both go hand-in-hand.

References

[1] X. Chen, H. Ren, C. Bil. (2013, May.). “Fault tree analysis for composite structural damages.” Journal of Aerospace Engineering. [On-line]. 228(9), pp. 1466-1474. Available: https://www.researchgate.net/publication/270620520_Fault_tree_analysis_for_composite_structural_damages [Jul. 16, 2016].

[2] S. Pilot. “What is a Fault Tree Analysis?” Internet: http://asq.org/quality-progress/2002/03/problem-solving/what-is-a-fault-tree-analysis.html, Mar. 2002 [Jul. 17, 2016].

[3] B. Vesely. “Fault Tree Analysis (FTA): Concepts and Applications.” Internet: https://www.hq.nasa.gov/office/codeq/risk/docs/ftacourse.pdf, [Jul. 17, 2016].

[4] S. Zeng, T. Zhao, J. Zhang. “Design and Analysis of System Reliability.” Beijing University of Aeronautics and Astronautics Press (2001).

Software Engineering Radio Podcast: LMAX Architecture

The Software Engineering Radio podcast I chose to analyze is titled, “Mike Barker on the LMAX Architecture” published by the IEEE Computer Society in 2016. Barker is a Research and Development programmer at the London Multi-asset Exchange (LMAX). In this podcast, Barker speaks about the LMAX Exchange system. He highlights the architecture, focusing on how the system works, the important non-functional requirements, and the components of the system. Although most of the podcast was new knowledge to me, I agree with with the authors’ statements about mechanical sympathy and improving system performance. My stance on this topic is that performance of a system and mechanical sympathy are extremely important for developers to keep in mind in order to create exceptional software systems.

Barker begins the podcast by explaining how the LMAX exchange started up. “Initially, there was BetFair, a peer-to-peer sports bidding platform where you could bet on horses and such. However, a faster exchange system with 100 times the speed was needed [1].” He explains that this gave birth to TradeFair, and ideas from this project lead to the creation of the LMAX exchange. Barker explains that the typical business case for LMAX deals with the “goal of building a contract for difference (CFD) in order to trade any asset [1].” He goes on to talk about how the exchange system actually works. “There are four main concepts in the system: instructions, orders, trades, and executions. An instruction is when someone wants to place or cancel an order. Executions occur when instructions arrive at the vendor and are executed. Orders are the entities living within the exchange, and they have a quantity and price. Finally, a trade is when two parties exchange something [1].” He states that the exchange is responsible for ordering orders based on time of arrival, and price placed. “For orders to sell, highest price offered comes first. For orders to buy, lowest price offered comes first. This way, you’re always looking at the best price on the market [1].”

The next big topic Barker discusses is the important non-functional requirements for the LMAX system. He states that response time is the most crucial as it deals with the issue of risk. “If someone places an item for sale, the faster they get confirmation that the item has been placed, the less risk they face [1].” Along with this, the latency is also kept as low as possible. He states that “initially the response time for the system was about 1 millisecond; however, chasing lower and lower latencies lead to a response time of 100 microseconds [1].” He states that “having data all the way over in one place, and logic all the way over in another place is like trying to eat your dinner with a pair of top-sticks through a litre-box [1].” He claims that bringing data up closer to the logic will help increase performance. Also, he states that “knowing about how a cache architecture works, and when to use temporal and spatial locality can help improve throughput [1].” I agree with these claims made by Barker as I believe that optimizing the performance of a system is crucial in any application or domain. I acknowledge that having constantly referenced resources, and recently referenced resources close to the CPU is beneficial and can save time. Even Rick Bunt from the University of Saskatchewan states that locality “has great returned value, and can help create productive applications across a wide range of domains [2].” Another non-functional requirement Barker addresses is the availability of the system, and its ability to handle failover. He states its importance, but doesn’t go into much detail.

The final topics that Barker discusses are the components of the LMAX system and the concept of mechanical sympathy. He states that the system has two main parts: the broker and the exchange. “The exchange is responsible for receiving instructions, managing orders, and matching orders to create trades. The broker is responsible for managing risk. If you buy $1000 worth of carrots, and the prices of carrots go up/down, the broker determines and tracks whether you’re in a profit/loss [1].” As for mechanical sympathy, Barker explains that the term comes from Formula 1 racing. “The idea is not that a driver or developer needs to know everything about building and assembling a car. They just need to have a degree of sympathy or knowledge about how it works [1].” I agree with this idea because I feel that having this knowledge allows engineers to intentionally develop effective software systems. It is not required that everyone knows exactly how something has been developed, but it is important that everyone knows how it works and how to fix problems as they arise.

Overall, I found this podcast interesting and was able to learn a lot of new things from it. I agree with most of the claims made, and feel that they are very applicable. Throughout the talk, Barker mentions non-functional requirements and quality attributes such as performance and availability: crucial topics in software architecture. A minor topic that Barker discusses that I didn’t mention above has to do with testing. He mentions that automated testing helps test the usual code, allowing testers to focus on the interesting topics, and trying to find situations wherein the system doesn’t function properly. In a study done at the University of Warsaw, the authors state that unit testing is an important facet of software quality assurance, simplifying the diagnosis of software flaws [3].” Thus, this material has great relevance in the field of software architecture and design and the points made in this podcast must be noted and utilized.

References

[1] SE-Radio. “SE-Radio Episode 254: Mike Barker on the LMAX Architecture.” Internet: http://www.se-radio.net/2016/04/se-radio-episode-254-mike-barker-on-the-lmax-architecture/, Apr. 12, 2016 [Jul. 10, 2016].

[2] R. Bunt, C. Williamson. “Temporal and Spatial Locality: A Time and a Place for Everything.” Internet: www.cs.usask.ca/faculty/bunt/presentations/Locality.ppt, Dec. 6, 2003 [Jul. 10, 2016].

[3] K. Iwanicki, P. Horban, P. Glazar, K. Strzelecki. “Bringing Modern Unit Testing Techniques to Sensornets.” ACM Transactions on Sensor Networks, vol. 11, Feb. 2015.

Article Analysis: The Golden Age of Software Architecture

The article I chose to analyze is titled, “The Golden Age of Software Architecture” published by the IEEE Software Journal in 2006. The purpose of this article is to “examine software architecture’s growth in the context of a technology maturation model [1].” The authors state that in the near future, “software architecture will be an essential part of software system building, and will be taken for granted just like all truly successful technologies [1].” I agree with the authors’ statement as my stance on this topic is that software architecture is a vital component in designing efficient software systems.

In 1985, Samuel Redwine and William Riddle reviewed several software technologies and analyzed how they developed. They stated that “technology transition follows technology development within an overall process of technology maturation [2].” They also concluded that a “technology typically takes 15 to 20 years to be ready for popularization, consisting of six major phases [2].” In this article, the authors take us through each of those phases and explain how software architecture has evolved over the past 30 years or so, using references to the Redwine-Riddle maturation model. In the early 1980’s, software systems were developed and “designers described their structures with informal explanations [1].” Basic research in the field of software architecture; however, revealed the “advantages of deliberately designed, specialized software structures [1].” Engineers began to realize that software must be designed with a purpose, and not by accident. They also started to understand that “apart from producing a desired outcome, a computer’s additional software qualities are equally as important [1].”

The authors state that in the late 1990’s and early 2000’s, the relationship between architecture and software qualities of a system was firmly understood. This relationship revealed “software architecture validation as a useful risk-reduction strategy in development of systems [1].” Also, the emergence of architectural views as a working concept by David Parnas was paramount. In his research, Parnas stated that “the effectiveness of a modularization is dependent upon the criteria used in dividing the system into modules [3].” He also observed that software systems have many structures performing various tasks and thus, selecting one as distinguished was useless. This concept “flowered in influential papers, firmly establishing views in architectural practice [1].”

The authors state that in the 2000’s and till present day, architectural styles (also called patterns) have become more widespread, and are being used as design guides. UML has also become popular as it “integrated a number of design notations and developed a method for applying them systematically [1].” Finally, the authors state that the maturation model is ended by the popularization period, where software systems and knowledge about new technologies is made available to the public. This phase is “characterized by commercialized, and marketed versions of the technology, along with an expanded user community [1].”

The relationship between this article and software architecture is quite obvious. The authors describe how software architecture has evolved and conclude that “the last 15 years or so - roughly the middle four stages of the Redwine-Riddle model - truly have been software architecture’s golden age [1].” I support the claims of this article and believe that the evolution of software architecture plays a major role in allowing engineers and designers to develop efficient systems. “Software is characterized by inevitable changes and increasing complexity, which in turn may lead to huge costs unless rigorously taking into account change accomodations. For such systems, there is a need to address evolvability explicitly [4].” I believe that the authors’ prediction that in the near future, software architecture will be considered an essential part of system building, is actually already true. In the 10 years since this article was written, I believe that the importance of architecture has really been valued and appreciated. “The golden age, is a period of prosperity and excellent achievement, often marked by numerous advances that rapidly move the technology from speculative to dependable [1].”

References

[1] M. Shaw, P. Clements. “The Golden Age of Software Architecture.” IEEE Software, vol. 23, pp. 31-39, March/April. 2006.

[2] S. T. Redwine, W. E. Riddle. “Software Technology Maturation.” Proceedings, IEEE Eighth International Conference on Software Engineering, Aug. 1985, pp. 189-200.

[3] D. L. Parnas. “On the Criteria To Be Used in Decomposing Systems into Modules.” Proceedings, Research Showcase at Carnegie Mellon University, 1971.

[4] H. P. Breivold. “Software Architecture Evolution and Software Evolvability.” M.Eng. thesis, Mälardalen University, Sweden, 2009.

Design Patterns: The Builder

The design pattern I chose to analyze in this article is the “Builder” pattern within the Java language. The builder pattern is used to create an object made up of other objects. It allows users to “separate the construction of a complex object so that the same construction process can create different representations [1].” This is useful when the user wants the creation of specific parts to be independent of the main object. The pattern allows a “client object to construct a complex object by specifying only its type and content, being shielded from the details related to the object’s representation [2].” The builder pattern is a creational pattern, meaning that it “deals with object creation mechanisms, and trying to create objects in a manner suitable to the situation [1].”

Some objects require complex assembly, or sometimes an “application may need to create the elements of a complex aggregate [1].” To relieve the client of the burden of having to build their own objects, the builder pattern can “provide the mechanism for building these complex objects [2].” In order to achieve this, in Java, the builder pattern is implemented using four major participant classes. The Product class represents the final product object being built. The Builder class “specifies an abstract interface for creating parts [2]” of the final product object. The ConcreteBuilder class implements the Builder interface and “puts together parts of the product while providing an interface for saving the product [2].” Finally, the Director class “constructs the complex object” using the Builder interface. “When the client calls the main method of the application, it initiates the Builder and Director class [2].” The Director class typically receives a Builder object as a parameter from the client. Thus, it is “responsible for calling the appropriate methods of the Builder class [2].” This allows the final product object to be built in an efficient manner.

A simple example that can be used to explain how all these components work in conjunction with one another is a vehicle manufacturer. The manufacturer has a set of parts, from which he can build a car, truck, or motorcycle. In this case, the person building the vehicle will play the role of the Builder class. He “specifies the interface for building any of the vehicles, using the same set of parts and a different set of rules for every different type of vehicle [2].” For each of the objects under construction, “the ConcreteBuilders will be the builders [2].” Obviously, the vehicle built takes the role of the final product object, while the “Director is the manufacturer [2].” Since all vehicles must have certain components such as an engine, brakes, and headlights, the builder design pattern can help simplify the client’s process of creating a vehicle.

The builder pattern is extremely useful in reducing complexity of creating a product object by “parsing a complex representation, and creating one of several targets [1].” My stance on this topic is that due to its ability to reduce complexity, the builder pattern is an appropriate pattern to use in this context; however, one must make the distinction between other similar patterns. Another creational pattern very similar to the builder is the Abstract Factory pattern. For the builder, the “Builder class is instructed on how to create the object and then asked for it, but the way the class is put together is up to the Builder class [2].” In the abstract factory case, “the client uses the factory’s methods to create its own objects [2].” The abstract factory pattern is very simple. The principle difference between the two is that the abstract factory pattern “requires the entire object to be built in a single call, with all the parameters passed in on a single line [3].” Thus, the builder is beneficial when the product object cannot be produced in a single step.

I believe that the simplicity of the abstract factory pattern can be used within the builder pattern to make it even more powerful. “Sometimes creational patterns are complimentary: Builder can use one of the other patterns to implement which components get built [4].” This will allow clients to make use of both patterns and take advantage of what both of them have to offer.

References

[1] A. Shvets. (2015). Design Patterns Explained Simply. [On-line]. Available: https://sourcemaking.com/design_patterns/builder [June 18, 2016].

[2] “Builder Pattern.” Internet: http://www.oodesign.com/builder-pattern.html [June. 16, 2016].

[3] “Builder Design Pattern in Java.” Internet: https://myjavalatte.wordpress.com/tag/builder-pattern-vs-factory-pattern/, Oct. 22, 2014 [June. 18, 2016].

[4] “What is the difference between Builder Design Pattern and Factory Design Pattern?” Internet: http://stackoverflow.com/questions/757743/what-is-the-difference-between-builder-design-pattern-and-factory-design-pattern, Apr. 16, 2009 [June. 18, 2016].

Challenges in Creating Exceptional Software Systems

Software engineers around the world strive for excellence when it comes to creating software systems; however, this is not a simple task. Some of the major challenges faced in this process include requirements volatility, addressing quality attributes, and carrying out a well-established design process.

The primary challenge in creating excellent software systems is the constant change of requirements. “Software’s own nature allows itself to change to provide different or new functionality to systems [1].” Although this is a beautiful feature, it adds complexity to the project by impacting current development efforts. Along with this, it also causes responsibilities of project members to change in an unplanned fashion. Software architecture provides flexibility to such volatility. It helps to “consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this [2].” Along with this, software architecture gives engineers the ability to decompose complex systems into smaller components. “In partitioning an application, the architect assigns responsibilities to each constituent component [3].” Through these techniques, architecture plays an important role in resolving the issue of requirements volatility.

The next challenge in creating reliable software systems lies in effectively addressing the quality attributes of the system. Quality attributes “define an application’s requirements in terms of scalability, usability, and so on [3].” Software architecture can provide built-in structure within parts of the system to help address specific attributes. “Quality attribute requirements are satisfied by the various structures designed into the architecture, and the behaviours and interactions of the elements that populate those structures [4].” Satisfying these requirements helps benefit the users of the system, as it provides the necessary attributes. In this way, architecture can assist in addressing the quality attributes of a system; allowing software engineers to create reliable systems for their stakeholders.

Another challenge faced in creating software systems lies in carrying out a well-established design process. Designing a product or system has many stages, and designs can constantly change. This makes it difficult for engineers to understand and document information about a design. Software architecture and patterns within the framework are beneficial in this regard. “The power of architecture patterns stems from their utility, and ability to convey design information. When an architecture is based around patterns, it also becomes easy for team members to understand a design [3].” In this manner, software architecture provides a method for improving the design process of a given system.

In conclusion, it can be seen that software architecture plays an important role in the creation of excellent software systems. Engineers use architecture in many ways to assist them, and by doing so are able to create more effective and reliable systems.

References

[1] “Software design challenges,” IT performance improvement, 2012. [Online]. Available: http://www.ittoday.info/ITPerformanceImprovement/Articles/2012-06Otero.html. [Accessed: May. 10, 2016].

[2] “Chapter 1: What is software architecture?,” Microsoft developer network, 2003. [Online]. Available: https://msdn.microsoft.com/en-us/library/ee658098.aspx. [Accessed: May. 10, 2016].

[3] I. Gorton, Essential Software Architecture. Germany: Springer, 2006.

[4] “Understanding quality attributes in software architecture,” Pearson: informIT, Oct. 31, 2012. [Online]. Available: http://www.informit.com/articles/article.aspx?p=1959673. [Accessed: May. 9, 2016].

		Shreyas Devalapurkar
		Student, Bachelor of Software Engineering Faculty of Engineering University of Victoria