SATURN 2014 Promoting Quality Attributes: Lessons Learned from the Trenches Session (notes)

Notes by Ziyad Alsaeed, edited by Tamara Marshall-Keim

Can You Hear Me Now? The Art of Applying Communication Protocols When Architecting Real-Time Control Systems
Todd Farley, BAE Systems, Inc.

BAE Systems deals with architecting real-time control systems. These systems are usually complicated and distributed. Also, the lifetimes of projects are usually very long. So BAE must always answer this question: Which process should they adapt? The problems they face tend to fall into three categories:

  • motion control systems (~robots)
  • computation-intensive algorithms
  • user interfaces

Because they deal with real-time systems, motion control systems usually present the hardest problems to solve. For example, to solve the approximate issue with such systems, they need to determine the multitude of processors that they will need and then solve the communication between those processors. Their systems generate a lot of traffic through their Ethernet connections. They usually prototype similar systems that generate similar traffic to test the connectivity efficiency. Such prototyping activity helps the team make technical and architectural decisions to improve the systems’ performance. For example, they are using UDP connections instead of TCP. Also, instead of using the publish-subscribe technique, they are using the multi-cast technique to reduce complexity. There are other issues to deal with in their environment, like the enormous amount of documentation they need to maintain and how to keep it up-to-date and accurate.

Sink or Swim: Enhancing Pipe-and-Filter Diagrams
Ivan Gevirtz, Google

Ivan shared an architectural style that he founded. It is based on the pipe-and-filter style. He is using the same idea to create notation that will help developers reason about complicated architectural decisions. Sink or Swim, the name of Ivan’s style, was developed based on Ivan’s needs when he was working on a video streaming system. His style helped him avoid consuming a lot of computer resources (e.g., memory or processor). His style is being formalized at Acme Studio.

Sink or Swim focuses attention on the push-or-pull nature of the filter coupling. This is accomplished by creating two connector subtypes (push and pull) and elaborating the filters with synchronous (active) or asynchronous (passive) ports. It is then possible to name and characterize eight subtypes of filters, one for each combination of {sync/async, input/output, middle/terminal}. This style has several advantages over the regular pipe-and-filter style:

  • It makes problems easy to spot through a graphical notation that enables and encourages visual reasoning.
  • It makes anti-patterns visible by highlighting resource implications of given usage patterns.
  • A small catalog of rewrite rules guides developers to refactor designs at the style level to avoid performance (and other) problems.

The style has been successfully applied to yield orders-of-magnitude performance improvements to existing systems. To understand the Sink or Swim style more in detail, you can visit Ivan’s blog.

Presentation link:

Approaching Security from an “Architecture First” Perspective
Rick Kazman, University of Hawaii
Jungwoo Ryoo, Pennsylvania State University
Humberto Cervantes, Universidad Autonoma Metropolitana–Itzapalapa

Rick presented early results of taking an architectural approach to software security as compared to coding, policies, or design. We all know that most of the effort today goes into coding, Rick stated. However, secure code is not enough or efficient. Security is a quality that you cannot compromise on. If your system is 99% secure, then your system simply isn’t secure. Moreover, security coding is expensive. So what could be the solution?

Rick and his team studied systems that have tackled security issues from an architectural approach. This is achievable by using security frameworks as a layer that will ensure the system security. They wanted to look into the problem from different aspects such as quality and development efficiency. Rick showed three case studies. One of them adopted a security framework later in the life cycle, during the system operation. Another system adopted a security framework at the beginning of development. The last case hadn’t adopted any security framework. They examined the three systems through questions that they asked the development leads for each case and through scanning the systems based on their standard of how secure the system is.

Their results show a significant security improvement in the first case, in which the system adopted a security framework later (during system operation). As expected in the second case, in which the system adopted a security framework from the beginning, the system was highly secure and the cost was noticeably lower. Finally, and also as expected, the case in which no security framework was adopted was the least secure system, and the effort to achieve what they had was significantly high compared to the other two cases.

In conclusion, Rick and his team think that not all developers are security experts. And even if they were, they shouldn’t write their own security controls. Security frameworks, in Rick’s opinion, increase the likelihood of security control. Therefore, it’s better to always take an architecture-first approach to security.

Presentation link:



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s