Toward the Application of Patterns to Systems Engineering

Department of Systems Engineering and Engineering Management, Stevens Institute of Technology

Toward the Application of Patterns to Systems Engineering Robert J. Cloutier Stevens Institute of Technology Castle Point on Hudson Hoboken, NJ 07030 [email protected]

Abstract The existence of patterns is almost universal. Patterns can be found everywhere. The human mind seems to perceive patterns without conscious thought - we notice individual’s personal habits because they form patterns. Patterns are also used in a number of engineering disciplines – software engineering, requirements engineering and mechanical engineering to name a few. Why then is pattern usage in the systems engineering discipline evident? Is it because patterns are domain specific? Or, is it because there has not been sufficient research into patterns to warrant their use? The purpose of this paper is to discuss possible motivations for using patterns, and in particular, use of patterns in systems engineering, and to provide a summary of pattern work/research that may be relevant. Finally, it will discuss the approach to future research to be performed by the author on potential application of patterns within the systems engineering discipline.

Introduction An early example of the application of patterns can be found in Henry Phillips’s The Purchaser’s Pattern. (Baer 2003) This pattern book (Figure 1), and others like it contained rules of thumb to assist the general public in

© 2005 Stevens Institute of Technology, ISBN 0-615-12843-2 PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

transacting business in seventeenth century England. “…Their observations reflected the considerable experience in buying, selling, leasing, and new building that had accumulated during the first half of the century” (1600’s).

Figure 1 - Mid seventeenth century "patterns book"

Music demonstrates repeating patterns to make it easier to learn the tune. Three childhood songs have the same tune – Twinkle, Twinkle Little Star; Baa, Baa Black Sheep and The Alphabet Song. All are from the same Mozart tune. Mathematics is full of patterns – methods to solve similar problems: sum of squares, quadratic equations, and standard integration of common functions, etc. (Solingaros 1999). The use of cul-de-sacs by civil engineers/architects in a housing development is another example of a commonly found pattern. Other examples of patterns are geometric forms – a large circle and a small circle differ only by the radius. The basic archway can be described by the height to the

shoulder, and the radius of the arch. Change the height or the radius, and one has a different archway. Alexander and Architecture Patterns. Most attribute Christopher Alexander to be the first to understand the value of patterns. Throughout the 60’s and 70’s Alexander, an architect, was striving to improve on the art of urban design by creating patterns that other architects could use. “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution…” (Alexander 1979)

He began to identify patterns for architecture, urban designing, and planning by looking at an architectural design and then abstracting that design into its basic parts which were common across other designs. Communities were viewed as systems that could be decomposed into component parts. He described the component parts and their relationship to other component parts in terms of boundaries. Alexander first published these notions in Notes on the Synthesis of Form (Alexander 1964). In this seminal work, he began what has resulted in several thousand pages of published works in which Alexander investigated the process of architecture. In 1977, Alexander developed these concepts further with another published work, A Pattern Language (Alexander 1977). From Alexander’s perspective, one could reuse a pattern “tens of thousands of times” and not have any two designs look the same. Nor did he did see the patterns as remaining stagnant. He believed patterns could always be improved upon. “We may then gradually improve these patterns which we share, by testing them against experience…” (Alexander 1979). Alexander was attempting to lower the cognitive load of design by exploring large design spaces on behalf of the architect (Coplien 1997) (Alexander 1964). Alexander

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

found that patterns helped him to express design in terms of the relationships between the parts of a house and the rules to transform those relationships (Coplien 1997). If we take the previous sentence and replace the word “house” with “system,” it easily applies to the notion of system architecture patterns. Patterns are not silver bullets. Patterns are used to help solve difficult problems by leveraging the knowledge gained by someone that went before. Patterns are models, or abstractions of reality. Today’s systems have become extremely complex. It is difficult, if not impossible, for a systems engineer to mentally juggle all of the smallest details of a system anymore. Models help in that arena. Patterns can exist at multiple levels. During the course of system design and implementation, the project team may use architecture patterns, design patterns, process patterns, implementation patterns (for software code), machine patterns (to cut metal for cabinets), test patterns, and validation patterns. At each level of the architecture, the pattern will contain the correct level of detail for the stage in which it is being used. Software Patterns. In the late ‘80’s software designers began to apply architectural concepts (patterns) to object oriented software development. In 1995, Erich Gamma, et. al. published what is still considered today to be one of the most authoritative works on software design patterns – Design Patterns: Elements of Reusable Object-Oriented Software (Gamma 1995). In the preface of Martin Fowler’s book Analysis Patterns (Fowler 1997), the author states: “… we have had difficulty in defining the term pattern. We all think we can recognize a pattern when we see it, we think most of us would agree in most cases, but we cannot come up with a single definition.” Fowler goes onto describe his own definition of a pattern: “…A pattern is an idea that has been useful in one practical context and will probably be useful in others.”

Applications of Patterns to Systems Engineering Patterns are being utilized in a number of engineering disciplines. The object oriented software engineering discipline embraced the use of patterns in the mid 90’s. Mechanical engineers use patterns in their designs. Requirements engineers have been applying patterns to their field for a number of years (Gross 2000). In 1998, IEEE conducted a halfday colloquium on “Understanding Patterns and Their Application to Systems Engineering”. And, at INCOSE 2004, Mr. Neil Harrison and Ms. Cecilia Haskins conducted a tutorial entitled “Introduction to Patterns through Writing Systems Engineering Patterns”. There appears to be a growing interest in the systems engineering community to learn more about patterns and how they may be applied in our discipline. One of the strongest arguments in favour of using patterns in systems engineering is to enable the capture of good architectural concepts and implementations and to preserve them for future projects. Requirements engineers are exploring the use of documentation patterns (templates) to facilitate common functionality and specifications across systems. Another reason for the need for patterns at the systems architecture level is the need for a common lexicon between systems architects. By possessing the ability to describe parts of a design and implementation in the context of known and understood patterns, a common understanding of the architecture may be fostered as it is in other engineering disciplines. This has been facilitated with the use of architecture frameworks such as the DoDAF (Department of Defense Architecture Framework), the FEAF (Federal Enterprise Architecture Framework). However, systems architecture patterns may enable the implementation of common design features across systems (reuse) to reduce overall

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

systems TOCs (Total Ownership Costs) by reducing the cost to design and produce a new system, as well as reducing the long term maintenance costs due to commonality. In the communities that have adopted the use of patterns, the patterns tend to become standardized as they are implemented on other programs and as they are presented at professional conferences and in professional journals. When this standardization happens within a company, it fosters reuse of designs and even code that is generated from the architecture patterns. This reuse has improved efficiency and productivity (Coplien 1997). Based on Coplien’s experience, one could argue that having documented and current patterns may reduce the documentation costs and complexity for any company that elects to pursue systems engineering patterns. Finally, as was found at Bell Laboratories, architecture patterns provide expert advice to novice architects. Going hand-in-hand with that is the fact that architectural patterns can help control the complexity of an architecture by standardizing it on a well known and practiced pattern. The work on the SysML standard may be a very useful adjunct to the use of patterns in systems engineering. With the integration of SysML and UML, there may be an evolving syntax that will be used by system architects, systems engineers and software engineers to define the problem and describe the solution using the same toolset. Pattern Hierarchy. Jay van Zyl and Professor A.J. Walker have. Some interesting work from Jay van Zyl and Professor A.J. Walker in South Africa on Using Patterns to Define an Overall Systems Architecture where they proposed a hierarchy of patterns (van Zyl 2001). This hierarchy is represented in Figure 2. In their paper, they are discussing software systems architecture. However, this author believes the systems patterns relationships

they depict may also be the same relationships that would be demonstrated by patterns at the system level.

diagram of the architecture pattern is shown in Figure 3.

cd Logical Model Trial Version EA 4.10 Unregistered Trial Version EA 4. Unregistered

System Patterns

System Trial Version EA 4.10 Unregistered Trial Version EA 4. Unregistered Requirements Analysis and Design

«realize»

Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Software

Requirements Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Analysis

Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. «realize» System Archtitecture Patterns Component Patterns «realize» Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. Design Patterns

SoftwareTrial Design Version EA 4.10 Unregistered Trial Version EA 4. Unregistered

«realize»

Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4. U

i t

dT i lV

i

EA 4 10 U

i t

dT i lV

Figure 2 – A Pattern Hierarchy

i

EA 4

System Patterns. Realizing the context of Zyl and Walker’s work was specifically software systems, further work may demonstrate that this model can be extended to the systems engineering domain. Systems patterns may be applicable when representing the highest levels of a system. When used to represent an entire system, they may also include structure and system boundaries. Based on knowledge gained by the use of patterns in other disciplines, use of patterns in systems engineering may also provide the foundation for common design and development as well as a common means of communicating about the system. System Architecture Patterns. Software architecture patterns are designs that relate to architecture. They can be hardware related, or software related, or both. An example of an identifiable architecture pattern is the ‘Layers’ architecture pattern. This pattern helps to structure applications that are decomposable into groups of subtasks in which each group of subtasks is at a particular level of abstraction (Bus96). A simple

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Figure 3: The Layers Pattern

Anyone involved in software development over the last 5 years, this is a highly identifiable pattern. It can be used for either software or hardware. One obvious use of this pattern is the Java Virtual Machine. When Java code is written and compiled, it is compiled into Java Byte code. This code is not executable in the same way that C++ is executable. It must be run in a Java Virtual Machine that is specific for a particular hardware/operating system combination. It sits on top of the operating system of a specific machine. Based on that description, Figure 4 demonstrates how the Java Virtual Machine implements the Layers Architecture pattern.

Figure 4: Layers Pattern as Applied by the Java Standard

Documenting Patterns. Patterns have been documented in many ways over the years. There is no agreed-upon standard. One of the most thorough approaches to documenting patterns is found on the website of AG Communications Systems (a subsidiary of Lucent Technologies). It was developed by Dr. Linda Rising, who is also the author of a very large undertaking - “The Pattern Almanac 2000” (Rising 2000). In this book,

Dr. Rising catalogs over 700 previously published patterns. It also contains process patterns like “writers workshop”. In this book each pattern is documented with a Pattern name, category, list of where it is used, pattern source citation, a URL if applicable, intent of the pattern, and related patterns/pattern experience (where applicable). Another expert in the topic of patterns, Martin Fowler wrote in IEEE Software: “When people write patterns, they typically write them in some standardized format—as befits a reference. However, there’s no agreement as to what sections are needed because every author has his or her own ideas. For me, there are two vital components: the how and the when. The how part is obvious— how do you implement the pattern, the when part often gets lost. One of the most useful things to I do when understanding a pattern, one I’m either writing or reading, is ask, “When would I not use this pattern?” Design is all about choices and trade-offs; consequently, there usually isn’t one design approach that’s always the right one to use. Any pattern should discuss alternatives and when to use them rather than the pattern you’re considering.” (Fowler 2003) Software engineers have been using patterns for over a decade, and there have been a number of pattern documentation approaches developed over that time frame. Based on a literature search, Table 1 (next page) represents the most common pattern documenting conventions in use today (again, most of the examples come from the software domain). The Argument Against Patterns. To this point, this paper has discussed the positive side of applying patterns and the potential advantages of applying them within the systems engineering discipline. However, one must ask are there any downsides to using PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

patterns? The list of arguments against using patterns is shorter, but there are some. The most obvious argument against using patterns is one used many times, particularly when structure is imposed on highly independent or creative individuals – it may stifle creativity and innovation. The argument goes on to say that if the guidance in all new work is to utilize a pattern library to assemble an architecture from the proven patterns, there will be no breakthroughs. There are three major reasons to not use patterns: • When addressing new or unique requirements which have not solved before • When the requirements require a unique solution, e.g. aesthetics over function • When the pace of technological change does not warrant the use of patterns However, there are system designs that are so proven and effective, there is no reason to not to define a pattern to represent those system designs and use them over and over. Innovate where it is most beneficial to the value chain, and use patterns for bread and butter work. In this manner, more effort can be used in applying creativity to the more challenging and higher risk aspects of the system. The second argument against the use of architecture patterns will be the harder to overcome because it is an organizational issue – patterns are of little use to the experts. The experts probably invented some of the patterns. Therefore, unless the expert is a visionary, and understands the importance of training up the next generation of systems engineers, there is little reason for them to perform the documentation and validation of patterns. If the experts do not contribute to the patterns library, and the junior systems engineer goes to the pattern library to find an applicable pattern, and finds nothing to help, after a while they will quit checking the library.

Pattern Template

Patterns for Effective Use Cases

Architecture Patterns

U.S. Treasury Architecture Guidance

A Pattern Language for Pattern Writing

(Ris03)

(Ado03)

(TOG02)

(TOG02)

(Mes)

Pattern Name

Pattern Name

Name

Name

Problem Statement

Problem

Problem

Pattern Name*

Aliases Problem

Aliases Metaphoric Story

Problem*

Implementation

Context

Context

Context

Structure

Context*

Forces

Forces affecting the Problem

Forces

Interactions

Forces*

Consequences

Indications (symptoms)

Solution

Solution

Solution

Solution*

Resulting Context

Resulting Context

Assumptions

Resulting Context

Rationale

Rationale

Rationale

Rationale*

Known Uses Related Patterns Sketch

Related Patterns

Related Patterns

Picture

Author(s)

Acknowledgements

Date Email References Keywords Example

Examples

Examples

Examples*

Known Uses

Code Samples * - required, italics – optional

Table 1 – Pattern Template Comparison The problem with this argument is evident in the aerospace industry – the experts are aging, or have begun to retire. The younger engineers are re-learning standard designs because the experts understanding walked out the door. The design experience that enabled senior engineers to recognize a problem and a pattern solution are no longer available and that knowledge was not documented as a pattern. Therefore, costs are higher for a new system because there is little or no reuse from one system to another.

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Conclusions What are some of the reasons to use patterns? In 1996, James Coplien was working for Bell Laboratories. In a paper published in an IEEE Journal, he recalls that they were “… mining the patterns of classic embedded systems to capture the core competencies of their business… Why? We can trace availability and fault tolerance to patterns, and we have extracted those patterns from the minds of long-standing experts.” (Coplien 1997).

Alexander began with form and context, Martin Fowler refers to patterns as useful ideas that may translate to another context, and Senge describes his archetypes (process patterns) as a method for clarifying and testing mental models of systems. Brandon Goldfedder states that “One of the key goals of patterns is to capture the solutions to reoccurring problems (and the constraints or context in which they can be used) in a manner which is easily accessible to others.” (Goldfedder 2002). Patterns have been embraced in other engineering and technical disciplines. They may be beneficial to Systems Engineers in controlling the complexity of systems, providing a common language to discuss similar aspects of systems, and capturing good architecture concepts for reuse. However, work needs to be accomplished before systems engineers can use them successfully. The goal of my research is to define a methodology and approach for enabling systems engineers to utilize patterns. Figure 5 represents the approach the author will take in pursuing this research. Figure 5 – Pattern Research Approach Evaluate Relevance of Existing Work in Patterns to SE

Define Approach For Capturing System Patterns

Develop Classification Scheme for System Patterns

Develop Guidelines for Applying System Patterns

The critical items necessary to accurately capture and document systems patterns need to be identified along with a systems engineering taxonomy for patterns. Finally, a classification schema for systems patterns to be used by systems engineers must be created. In this paper the author has provided some historical perspective to the use of patterns in engineering disciplines. It went on to discuss how patterns might be used at the more abstract systems level and discussed the need for a method to document and describe systems patterns. The paper discussed some of the common objections to the use of patterns,

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

and finally, propose needed research in the area of applying patterns to systems engineering.

References Ambler, Scott, “The Process Patterns Resource Page”. Downloaded 10/28/04. URL: http://www.ambysoft.com/processPatterns Page.html Adolph, S. Bramble, P. 2003. Patterns for Effective Use Cases. Boston: Addison Wesley. Alexander, Christopher. 1964. Notes on the Synthesis of Form. Cambridge: Harvard University Press. Alexander, Christopher. 1977. A Pattern Language. New York: Oxford University Press. Alexander, Christopher. 1979. A Timeless Way of Building. New Your: Oxford University Press. Baer, William C., 2003, How “Pattern Books” Fueled England’s First Speculative Real Estate Market. Harvard Business School Working Knowledge eZine. Downloaded 5/7/2004. URL: http://hbsworkingknowledge.hbs.edu/tools /print_item.jhtml?id=3313&t=finance. Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996) Coplien, James O. 1997. Idioms and Patterns as Architectural Literature. IEEE Software Special Issue on Objects, Patterns, and Architectures. January 1997. Fowler, Martin. Analysis Patterns. Reusable Object Models. Menlo Park, CA. AddisonWesley. 1997. Fowler, Martin. “Patterns are Nothing New”. Downloaded 5/29/2004. URL: http://www.martinfowler.com/bliki/Pattern sAreNothingNew.html.

Gamma, E., Helm, R., Johnson, J., Vlissides, J., Design Patterns: Elements of Reusable Object Oriented Software. MA: AddisonWesley. 1995. Goldfedder, Brandon. The Joy of Patterns. Boston: Addison-Wesley. 2002. Gross, D. Yu, E., From Non-Functional Requirements to Design through Patterns Requirements Engineering. SpringerVerlag. 6(2001) 1: 18-36. Meszaros, G. Doble, J. “A Pattern Language for Pattern Writing”. Downloaded 5/28/04. URL: http://webclass.cqu.edu.au/Patterns/Resour ces/writers/language/ (note: this site does not seem to be available any more) Rising, Linda, PhD. 2000. The Pattern Almanac 2000. Boston: Addison Wesley. Rising, Linda, PhD. 2003. “Pattern Template”. Downloaded 5/28/04 from AG Communications Systems (A subsidiary of Lucent Technologies). URL: http://www.agcs.com/supportv2/techpaper s/patterns/template.htm (note: this site does not seem to be available any more) Salingaros, Nikos, PhD. 1999. “Architecture, Patterns, and Mathematics”. Nexus Network Journal, Volume 1, pages 75-85. Downloaded 10/25/04. URL: http://www.math.utsa.edu/sphere/salingar/ ArchMath.html TOGAF. “Architecture Patterns”. The Open Group Architecture Framework (TOGAF) Website. Downloaded 5/27/2004. URL: http://www.opengroup.org/architecture/tog af8-doc/arch/p4/patterns/patterns.htm van Zyl, Jay & Walker, A.J., “A Pattern Architecture: Using Patterns to Define Overall Systems Architecture”. Downloaded 10/22/04. URL: http://osprey.unisa.ac.za/saicsit2001/Electr onic/paper37.pdf

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Biography Rob Cloutier is a Systems Engineering Doctoral Candidate at Stevens Institute of Technology. He is also a Principle Engineer at Lockheed-Martin Corporation in Moorestown, NJ where he is currently in a System of Systems Architecture group. He has 20 years experience in systems engineering, software engineering, and project management in both the commercial and the DoD industries. Rob holds a B.S. from the United States Naval Academy and an M.B.A. from Eastern University, where he is also an adjunct professor.