James S. O’Rourke

March 2017

Advisor: 	Neil Rowe
Second Reader:	Man-Tak Shing

Distribution authorized to U.S. Government Agencies only (Test and Evaluation) (August 30, 2016). Other requests for this document must be referred to President, Code 261, Naval Postgraduate School, Monterey, CA 93943-5000 via the Defense Technical Information Center, 8725 John J. Kingman Rd., STE 0944, Ft. Belvoir, VA 22060-6218.



Form Approved OMB
No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington, DC 20503.

1. AGENCY USE ONLY (Leave blank)


March 2017


Master’s thesis





6. AUTHOR(S)  James S. O’Rourke


Naval Postgraduate School

Monterey, CA 93943-5000





11. SUPPLEMENTARY NOTES  The views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government. IRB number ____N/A____.


Distribution authorized to U.S. Government Agencies only (Test and Evaluation) (August 30, 2016). Other requests for this document must be referred to President, Code 261, Naval Postgraduate School, Monterey, CA 93943-5000 via the Defense Technical Information Center, 8725 John J. Kingman Rd., STE 0944, Ft. Belvoir, VA 22060-6218.



13. ABSTRACT (maximum 200 words)

Current software architecture design practice does not offer sufficient integrated cross-cutting design approaches to implement nonfunctional design properties for large software systems. An initial approach, software architecture perspectives, provides some level of support but requires further development to address the full range of crossing-cutting design issues inherent to nonfunctional design properties. Additionally, current software practice recognizes shortcomings in the design understanding and application of software connectors, a key software architecture design element.

This work proposes to address these shortcomings through suggested improvements to the taxonomy and design practices of software connectors, and introduction of a software architecture perspective, to accommodate the range of cross-cutting design issues to achieve desired system performance properties.   The software architecture perspective introduced proposes activities and models to plan for, understand, and validate the resources consumed and applied in software system execution.   The means proposed support successful navigation of the shared software-hardware design space from the software architect’s perspective.[MS1] 



 lowercase all terms, except proper nouns  













NSN 7540-01-280-5500                                                                                                          Standard Form 298 (Rev. 2-89)

                                                                                                                                                    Prescribed by ANSI Std. 239-18




Distribution authorized to U.S. Government Agencies only (Test and Evaluation) (August 30, 2016). Other requests for this document must be referred to President, Code 261, Naval Postgraduate School, Monterey, CA 93943-5000 via the Defense Technical Information Center, 8725 John J. Kingman Rd., STE 0944, Ft. Belvoir, VA 22060-6218.






James S. O’Rourke


B.S., Fitchburg State, 1982



Submitted in partial fulfillment of the

requirements for the degree of





from the



March 2017






Approved by:              Neil Rowe

Thesis Advisor




Man-Tak Shing

Second Reader




Peter Denning

Chair, Department of Computer Science




Current software architecture design practice does not offer sufficient integrated cross-cutting design approaches to implement nonfunctional design properties for large software systems. An initial approach using software-architecture perspectives provides some support but it requires further development to address the full range of design issues. Additionally, current software practice has shortcomings in the design understanding and application of software connectors, a key software-architecture design element.

This work proposes to address these shortcomings through suggested improvements to the taxonomy and design practices of software connectors, and introduction of a new software architecture perspective to achieve desired system performance properties.   The perspective proposes activities and models to plan for, understand, and validate the resources consumed and applied in software execution. This aids successful navigation of the shared software-hardware design space from the software architect’s perspective. 



I.             INTRODUCTION................................................................................................. 1

A.           Motivation.......................................................................................... 1

B.           Research Questions...................................................................... 2

C.           Thesis Structure............................................................................ 2

II.           BACKGROUND................................................................................................... 4


1.            Observations about Software Connectors................................... 6

2.            Complex Software Connector Implementation........................... 6

3.            Software Connector Classification............................................... 7

4.            Complex Connector Support for Architecture Design............. 10

B.           sofTware architecture desiGn levels....................... 11

C.           Performance Management Support............................... 13



1.            Cause for Expanding the Software Connector Taxonomy...... 15

2.            Expanding the Software Connector Taxonomy....................... 17

3.            Hardware Type Complex Connectors....................................... 20

4.            Complex Connector Support of Software Architecture.......... 20

5.            Nature of Connector-Architecture Pattern Links.................... 28

B.           A Connector Computation model.................................... 32


IV.         CONNECTOR Design Examples............................................................ 34

A.           AHRS Case Study............................................................................. 34

B.           AHRS Connector Selection.................................................... 36

C.           AHRS Connector Solution Planning............................... 38

1.            AHRS Application Usage Model................................................ 39

D.           AHRS CONNECTOR Solution DESIGN..................................... 39

E.           AHRS Deployment Planning................................................... 42

F.           AHRS Connector Performance Oversight.................. 45

G.          AAAS Case Study............................................................................. 46

H.           AAAS Connector Solution Planning............................... 47

V.           Summary and Future Work............................................................... 53

A.           Future Work Opportunities................................................. 53

II.           References................................................................................................... 57




Figure 1.             Sample Software Connector Classification Based on Connector Services. 9

Figure 2.             Typical Virtualized Capability Modules. Source: (Joint C2 Architecture Core Team for the PEO-C2C)................................................................................................. 16

Figure 3.             Primary-Secondary Connector Taxonomy................................................. 18

Figure 4.             Example Hypervisor-Based Host Environment. Source: (VMWARE Inc., Copyright © 2009–2011).......................................................................................................... 19

Figure 5.             Multi-Layer Nature of Java Server Applications. Source: (Ban et al., ND) 21

Figure 6.             Microsoft Server 2012 Edition Scalability & Performance Features (Source: (Microsoft, n.d.).................................................................................................................... 26

Figure 7.             Microsoft Server 2012 Edition High Availability Features (Source: (Microsoft, n.d.)          27

Figure 8.             SW-HW Design Space Connector Design Patterns.................................. 30

Figure 9.             Sample Set Explain On Output. Source: (Informix Software, 1995)........ 40

Figure 10.          AHRS Deployment Host Environment..................................................... 41

Figure 11.          Oracle Endecca Information Discovery Components. (Source:  (ORACLE Endecca, 2012)................................................................................................................... 46

Figure 12.          Single Node Endeca Architecture. Source: (ORACLE - Endecca Server Administrator Guide, 2014).......................................................................................................... 47

Figure 13.          Dgraph virtual memory vs. RAM: use cases. Adapted from Oracle Endeca Commerce MDEX Engine Performance Tuning Guide........................................................... 48

Figure 14.          Cloud Space Data Server Technologies. Source:  (The 451: the Database Landscape, 2013)................................................................................................................... 51







Table 1.               Performance Pitfalls and Mitigations. Adapted from Woods (2007)....... 12

Table 2.               Sample Connector Product Technical Profile. Sources: (Microsoft, 2016; Red Hat; Techotopia)................................................................................................................... 23

Table 3.               Symantec Storage Foundation Middleware Product-Platform Availability for Sample Primary Connectors. Source:  (Symantec Corp. Inc., 2015)................................... 24

Table 4.               Hardware-Software Component Performance Impact. Source: (Patterson & Hennessy, 2009).................................................................................................................... 28

Table 5.               Connector Based Design Process.............................................................. 35

Table 6.               ORACLE Endecca Studio Supporting Secondary Connectors (Adapted from (ORACLE, 2013).......................................................................................................... 48

Table 7.               Sample Performance Summary Table. Source: (Oracle - Endeca Performance Guide, 2013)................................................................................................................... 51




FBI                              Federal Bureau of Investigation

CIA                             Central Intelligence Agency

CONUS                      continental US

COTS                          Commercial Of-The-Shelf

DARPA                      Defense Advanced Research Program Agency

DISA                          Defense Information Systems Agency

DOD                           Department of Defense

GAO                           Government Accountability Office

OCONUS                   outside the continental US

SEI                              Software Engineering Institute

SMP                            Symmetric Multi-Processor






Acknowledgement of the author is noted for the high level of effort and assistance the thesis advisors contributed in the development of this thesis content, organization and overall formulation. 




                                                                                                                                               I.            INTRODUCTION

Mary Shaw, a major contributor to software architecture development, made the observation that “composing system from subsystems is a substantially different activity from programming the underlying algorithms and data structures” (Shaw et al., 1995, p.3). Hardware designers, Shaw suggests, face a similar problem space. Shaw describes this shared problem space as one “comprised of a number of distinct design levels each with its own design issues, models, notations, componentry, and analysis techniques”. She associates the field of software architecture with the different levels of software design with varying means of composition, design concerns, and reasoning needs.

A.          Motivation

In today’s software architecture practice, different design levels are typically associated with “views.” This term denotes the representation of structural aspects of a software system’s architecture. Software architecture views are composed of various design elements, including models. The Software Engineering Body of Knowledge (SWEBOK) describes the makeup of a software design as a “multi-faceted artifact produced by the design process and generally composed of relatively independent and orthogonal views” (IEEE Computer Society, 2004). But today there exists no standard set of views to represent the multiple structural aspects of a software system. Consequently there is no standard set of design models or practices. This is true even though different people including the Software Engineering Institute have proposed specific views and design practices. A shared design space is desirable for the software and hardware elements associated with a software system due to software’s need for hardware to operate using a specific hardware configuration.  (Taylor, Medvidovic, & Dashofy, 2010) Moreover, there is a high degree of confusion and lack of design guidance regarding software connectors, a key design element in software architecture practice. Success is dependent largely on the skills of individual software architects with inconsistent performance results.

A recent Government Accountability Office (GAO) report on Major Automated Information System (MAIS) programs reflect that 5 out of 14 MAIS programs studied, did not fully meet their performance targets (United States Government Accountability Office, 2013). Reported issues included:  

·                     Existence of many defects in the operational system.

·                     Not meeting processing time targets.

·                     An inability to demonstrate that system requirements were met.

Improvements in architecture design practices could redress these identified issues.

B.           Research Questions

1.                  What design issues most contribute to insufficient engineering the shared software-hardware design space?

2.                  What shortcomings exist in the design understanding of software connectors as design elements?

3.                  How do these shortcomings impact the engineering of the shared software-hardware design space?

4.                  What potential means can overcome these shortcomings?



C.          Thesis Structure

Chapter II presents background of related issues. Chapter III presents a set of proposed means to address these issues and pertinent design factors. Chapter IV gives a two case examples to illustrate the proposed methods. Chapter V provides a summary with recommendations of areas of potential work.




                                                                                                                                              II.            BACKGROUND

A software system depends on many things for successful operation (Taylor et al., 2010):

·                     Interfaces to other components

·                     Required files and directories

·                     Required system software like run-time environments, middleware platforms, operating systems, network protocols, and device drivers

·                     Hardware


Functionally driven design paradigms cannot sufficiently implement nonfunctional cross-cutting design properties inherent to large-scale software systems. In the design of a software-based shipboard missile defense system, it is well and good when the system in pre-deployment operational tests will carry out each required system function meeting all test requirements.  But if when deployed, this system is not available or the performance of the system wanes after so many hours of continuous use, the lack of reliable performance renders it a design failure. Functionally based design paradigms focus on products meeting their required functionality, not the non-functional ones that involve availability, performance, scalability, security, and modifiability.  Software engineering to address all forms of software requirements is by nature a cross-cutting engineering domain.

Laplante defines software engineering as one whose essence is modeling and optimization (Laplante, 2007). Modeling, in this context, is a translation action. Different design constructs in the software-engineering life cycle’s processes are translated from requirements to design to code to deployment. Errors can occur, whether the result of a person’s or software action, through each life-cycle operation. Errors introduced include those that fail to account for inter-relationships across life-cycle design constructs and those unique to a life-cycle phase. The nature of the conversion actions across different design forms is inter-relational. Hence, a cross-cutting approach is needed to address the multiple design levels the software architecture of large-scale systems involve, and cross-cutting orthogonal design issues. 

Software architecture supports software engineering through design patterns, elements, models, and activities for both design aspects that are isolated to specific software life-cycle process boundaries, and aspects that cross them. 

Software architecture design emphasizes heterogeneous design elements. The range of elements include software components and software connectors.  Software connectors provide a multitude of service types for software components. They include: enabling exchanges of control and data between components via procedure calls; allowing for and managing access to shared data through shared-data media like databases or file sharing; and means for components in different locales to communicate and interact by using middleware services. Forms of software connectors are compilers and interpreters, data servers and database management systems, and middleware like Common Object Resource Broker Adapter (CORBA) and Java Remote Message Invocation (RMI).

Architectural perspectives have been proposed to address the cross-cutting design issue in software architecture (Rozanski & Woods, 2005). An architectural perspective consists of design activities, possible design models, architectural tactics, potential pitfalls to avoid, and guidelines to ensure a software system exhibits particular quality properties. 


Shaw and Garlan (1996) proposed that a software architecture could be modeled by distinguishing elements associated with processing or computation (components) from others which are “the glue” (connectors) for interactions between components. The Software Engineering Institute (SEI) uses these terms as does the IEEE 1471 Architecture Description standard. The SEI software architecture literature uses these terms in reference to “component-and-connector” structures or views.

The Defense Advanced Research Project Agency (DARPA) and the Air Force Research Laboratory have said that “The current level of understanding for software connectors and their support for their use in software architecture is insufficient” and that “Connectors are often considered to be explicit at the level of architecture but intangible in a system’s implementation” (Mehta, Medvidovic, & Phadke, n.d., p. 1). Mehta et al. noted that in large and especially distributed software systems that software connectors hold a first-place role in design due to being “key determinants of system properties such as performance … scalability, reliability.”

1.            Observations about Software Connectors

We can make the following observations on software connectors (Shaw, 1994):

   Connectors are potentially abstract. They may be parameterizable; for instance, operating systems, databases, and other system software typically specify parameters through which their operation and configuration may be controlled and optimized. They may define classes of interactions that require additional scripting at the time of instantiation. A connector may be instantiated many times in a system. For instance, operating systems, database systems, and other system software may be instantiated across many servers.

   Connectors may require distributed-system support: The mechanism required by a connector is not always localized. For example, a message-passing system may require one server per processor.

   Connectors should operate independently of each other. But a single high-level connector might mediate relations for a dynamic set of components.

   Some information about the system is global to components. For example, in a real-time system it may be appropriate for tasks to declare their needs and for a separate scheduler to satisfy them.  Systems software often does this.

   Connectors may be quite sophisticated, using elaborate definitions and complex specifications.  Examples are systems software like operating systems and database management systems.


2.            Complex Software Connector Implementation

As an example, user of a protocol like TCP-IP wanting to gain access to a database management system must have a TCP-IP service running on their machine and on the machine hosting the database. Communications services like TCP-IP are most typically provided by an operating system. Also, both the user’s machine and the machine hosting the database must have correctly operating and suitable hardware to carry out the connection and transmission tasks that the TCP-IP protocol demands, and this requires some configuration.

We would label this as a data-access type of connector as the user’s intent is to access stored data items of interest. A linkage type connector is also involved in the TCP-IP protocol between the user taking part in this scenario and the database. This example illustrates the idea of (Mehta et al., 2000) that high-order connectors can use other connectors to enable channels for communications and coordination to carry out their connector services. The TCP-IP service is typically provided by an operating system and not a DBMS. So it illustrates at the implementation level the dependencies between two composite connectors. One connector, a database management system, depends on the services of another connector, an operating system.

Attention to connectors is important because of the problem of “architectural mismatch” (Bass, Clements, & Kazman, 2007). This term reflects the idea that though products may claim compatibility, and can appear to work together, subtle errors may still occur whereby system execution exhibits erroneous results and performance-related drawbacks. DOD acquisition policy places a high emphasis on commercial off-the-shelf (COTS) software. This can cause architectural mismatches. The nature of the sources for the associated inherent design risks in commercial off-the-shelf software systems are primarily due to the execution context of components.  Practices to verify suitability of COTS software before adoption in system development are important (Boehm, Kind, & Turner, 2002) (Bass et al., 2007).

3.            Software Connector Classification

One software connector classification scheme is based on the service or facilities that connector types provide (Figure 1) (Mehta et al., 2000). Complex connector types provide the most services or facilities. Services associated with complex connectors include communication (transmission of data); coordination (transfer of control); conversion (handling different data formats); and facilitation (mediating and streamlining component interaction). A sample complex type is the Arbitration connector which provides both Coordination and Facilitation services. The Arbitrator provides control of interacting component scheduling, load balancing, streamlining of system operations, and fault handling. The Linux operating system includes the Linux process scheduler and Linux file manager as Arbitrator types, and the Linux system-call interface as a data-access connector. 


                          Figure 1.          Sample Software Connector Classification Based on Connector Services[MS2] 

4.            Complex Connector Support for Architecture Design

Complex software connectors can reduce development efforts through direct reuse of their capabilities to exploit architectural patterns for a range of nonfunctional requirements including performance, availability, modifiability, and extensibility. Complex software connectors include operating systems, transaction-processing monitors, application servers, compilers, and real-time and non-real-time database management systems. They provide the following services (Garland & Anthony, 2003):

·                     Static and dynamic prioritized scheduling of processing requests

·                     Static and dynamic load balancing of  requests

·                     Automatic startup and stopping of processes and associated tasks

·                     Logging and process and task failure management

·                     Concurrency to process requests

·                     Transaction management

·                     Optimization of run-time execution for software components that use their services

·                     Performance management features for monitoring of processing and resource consumption


A serialization point is a design instance where multiple users attempt to use a resource that cannot be shared simultaneously, deferring others until it becomes available. A key to good performance for multi-user software is reduction of the number of serialization points (McDougall, 2005 ). This applies to both applications and system software.   An example is a shared disk resource. Often the operating system working area and the database management system share the same disk, and these two connectors can contend for the same disk. A remedy is to employ different disks for the operating system and the DBMS.


B.            sofTware architecture desiGn levels


Current software engineering practice can show insufficient design engineering at the software-implementation level. This level includes the shared software-hardware design space. Larus (2009) described how advancements in hardware performance in processor speed and capacity have impacted software development. Growth in processor performance enables the creation of larger software programs that include more features, with bigger development teams resulting in non-optimal resource usage. Larus also details additional issues in the software design such as insufficient software developer concern.

High-level language software technology has a dependency upon compilers with the drawback that “compilers are oblivious to major bottlenecks such as disks and memory systems.” (Larus, 2009, p. 67), resulting in developers just focusing on functions at the expense of the quality aspects like performance. Another point is that compilers tend to address performance bottlenecks like those concerning disks or memory contention in ways which are not necessarily correct. Compilers are in the taxonomy of software connectors. 

Compiler choices influence architecture design by providing varying support for architecture-pattern adoption.   Advanced hardware features like automated and controlled code parallelization for concurrent execution via parallel-programming models like OpenMP and MPI enable software-architecture performance patterns. However, such enablers only help when products that include such features are employed and the features rightly applied.

 Comparative studies for software connectors like Java application servers, with suitable application architecture designs, can give a 20% performance gain without any application modification (Gorton & Liu, 2003).  Performance gains are verifiable through benchmark testing. These results indicate that effective product selection and application are required as well as effective architecture design to address insufficient platform precision for successful deployment. Taylor et al (2010) argues for this role of software connectors as performance-design lynchpins that are natural points of system scaling. 

Table 1, modified from Woods’ proposed performance perspective (Woods, 2007), identifies issues known to hinder performance goals for systems, and proposed means for prevention. Avoidance options for the first, second, and fourth identified pitfalls rely on the use of effective and validated architecture models.

                                                        Table 1.  Performance Pitfalls and Mitigations. Adapted from Woods (2007).

Known Pitfalls

Means to Avoid

  • Imprecise Performance and Scalability Goals

Ř  Define clear and measurable performance & scalability goals with system stakeholders.

  • Unrealistic Performance models

Ř  Validate proposed performance models with practical tests that reflect model assumptions.

  • Inappropriate Performance Partitioning

Ř  Watch for overloading of performance responsibilities on highly connected executing elements.

  • Invalid Environment and Platform Assumptions

Ř  Identify and validate your assumptions.

  • Overuse of indirection

Ř  Critically assess use of indirection in critical performance areas.

  • Concurrency-related contention

Ř  Identify elements of your system that must deal with significant concurrent processing.

Ř  Carefully plan/assess design and implementation of these critical elements.

  • Careless allocation of resources

Ř  Avoid large amounts of dynamic resource allocation and deallocation in critical path elements.

Ř  Detail guidelines and patterns for effective resource use and management in developer implementation activities.



A key responsibility of the software architect is expression of an integrated scheme to address the cross-cutting design. A performance perspective should also provide enough details to aid implementation. This includes:

·                     Guidance to developers so the units they create, for the technologies being used, reflect the architectural patterns and tactics being used to achieve the system’s performance goals.

·                     Selection and application of suitable software connectors to package the developed implementation units and support their execution.

·                     Selection and application of suitable hardware resources to execute the system functional responsibilities using the applicable architecture practices and tactics.   

The lack of careful management and design attention to address important inter-relationships across the multiple design levels in software architecture is a source of significant design concern in software architecture practice. Sufficient non-coordination can result in architecture degradation, a condition where the architecture as designed and the implementation are not in alignment (Taylor et al. 2010). This condition can have significant impact on the performance properties of software systems, as it can indicate a lack or inappropriate implementation of architecture-design patterns in a system. The condition may also result in issues associated with architecture-design pattern use and architecture degradation.

C.          Performance Management Support

Emergent behavior in software systems is a candidate for potential errors or failures during use. Errors can take place during software execution and may not be detected, and this has been particularly a concern for enterprise-level Service Oriented Architectures or SOAs (Krafzig, Banke, & Slama, 2005). A reliable logging infrastructure is proposed as an SOA best practice to record errors when they occur, the components involved, and the particular users and requesting sources affected.

A reliable logging infrastructure can also store data for a scoped performance profile model. (Lindstrom, 2008) suggests that to be accurate in predicting a transaction will complete before deadlines, knowledge of the worst-case execution time and resource needs are required.

Most complex software connectors like operating systems, database management systems, application servers, and compilers include their own features to also monitor their operation.

COTS software, and to a lesser degree open-source software, in the software-hardware design space introduce significant risk.   The selection and application of the use of connector features is determined by design choices, and also implementation activities, also argues for connector use oversight.

Key supporting assets to plan oversight activities can be the inherent oversight support connectors offer.  Third-party products are means to augment oversight support. 



                                            III.            SOFTWARE-HARDWARE DESIGN USING CONNECTORS

A multi-level engineering approach is needed to address cross-cutting design concerns in the shared software-hardware design space. We first suggest improvements to the software-connector taxonomy and design practices. 


We often see “inconsistent treatment and a notable lack of understanding of what the fundamental building blocks of software interaction are and how they can be composed into more complex interactions.” (Mehta, Medvidovic, & Phadke, n.d.) Moreover, “Connectors are often considered to be explicit at the level of architecture but intangible in a system’s implementation.”  Such issues suggest further software-connector taxonomy development as does the growth of composite connector types.

It will help to introduce some new terms. One is the “primary connector”, a complex or composite connector that is mandatory for other complex connectors to use a hardware platform. Examples include an operating system or a real-time executive. Another term is a “secondary connector”, a complex connector, beyond that of an operating system or equivalent, used on a hardware platform to perform one or more complex connector responsibilities. Examples of secondary connectors are database management systems, application servers, transaction monitors, Web servers, and compilers.

1.                  Cause for Expanding the Software Connector Taxonomy

Composite software connectors, both primary and secondary types, enable building and executing software implementation units. They play several roles, derived from (Taylor et al., 2010 and Garland and Anthony, 2003):

1.                  Coordinating interacting software component computing resources

2.                  Optimizing software-component interaction

3.                  Coordinating computing resources

4.                  Optimizing computing resources

5.                  Coordinating   communication resources

6.                  Optimizing  communications resources


A weakness of this taxonomy is that it does not directly address virtualization. Virtualization technology now supports software products across the range of system types, from the enterprise to embedded software applications. As a result, based on standards like ARINC-653, integrated modular architectures (IMA) instead of well-established federated architecture approaches for real-time systems are being used.

            The central role of connectors in virtualization design is seen in U.S. Government software architecture and cloud technology policy.  The Army’s Common Operating Environment (COE) reference architecture established a standard for Army application design to employ server-based solutions, and mandates a deployment architecture for servers to comply with DISA’s C2 architecture (Army CIO & Assistant Secretary of the Army (Acqusition, Logistics, Technology), 2010).

The typical makeup of a DISA C2 virtualization scheme of capability modules, two or more of the CPs (“capability packages”), depicted in Figure 2, is a hypervisor-based design employing different secondary and primary connectors.   

Figure 2.          Typical Virtualized Capability Modules. Source: (Joint C2 Architecture Core Team for the PEO-C2C)



This joint C2 example has two primary connectors (two guest OSs) and two secondary connectors (an application server and the RDBMS). The implementation for each capability package is a virtual machine. The virtual machine requires a hypervisor for managing and controlling execution of the virtual machines on the host-platform hardware. Here a two-level, upper and lower, hierarchy of primary and secondary connectors is involved. The top or upper-level hierarchy consists of the hypervisor acting as a primary connector, and the virtual machines acting as secondary connectors. The lower or bottom-level primary-secondary connector hierarchy is composed of the operating systems used for each virtual machine and the application server and RDBMS. The operating systems used for the application server and RDMBS may or may not be identical. 


2.            Expanding the Software Connector Taxonomy

Figure 3 presents our own taxonomy of primary and secondary connector types to support virtual and non-virtual based software system design.



                                                                                     Figure 3.          Primary-Secondary Connector Taxonomy


This taxonomy proposes that a primary connector is the one required element of a hardware platform. Primary connector types include operating systems, hypervisors, and real-time executives. A hypervisor, an aggregate-type primary connector, may involve multiple individual type primary connectors. Figure 4 depicts a sample instance. Primary connectors used with hypervisors may vary across different vendors, i.e. Microsoft and Linux, or be limited to a single type vendor, i.e. Solaris UNIX types. Type 2 hypervisors, an example being Microsoft’s Hyper-V product, require an individual operating system such as Microsoft Server 2008 or 2012. “Bare metal” or type 1 hypervisors, VMware for instance, and type 0 hypervisors, microkernel types, do not. 


Figure 4.          Example Hypervisor-Based Host Environment. Source: (VMWARE Inc., Copyright © 2009–2011)

Various forms of secondary connectors are also reflected in the taxonomy. These are composite-type connectors supporting system functionality. Hardware platforms can host multiple secondary-connector types. Secondary connectors require some form of primary connector. Multiple secondary connectors can be used with a single primary connector or different secondary types used with a primary connector. Secondary connectors, like primary connectors, have both individual and aggregate types. 

An aggregate secondary-connector type, partition or container, is an execution environment for individual-type secondary connectors used by primary connectors that support aggregate-type execution environments. A partition for example is a managed execution environment and design element for a hypervisor. Virtual machines, used with hypervisors, are partitions. A container, differently from a partition, is a managed execution environment for use with an operating system. Oracle Solaris is an operating system that permits use of containers. Not all operating systems do.

All hypervisors employ partitions or virtual machines; however, each type of hypervisor can implement them differently. Some microkernel type hypervisors like the Pike OS also allow for native execution environments


3.             Hardware Type Complex Connectors

Computer appliances can be considered hardware connectors (Sensagent Corporation, N.D. ). A hardware sensor-array collection device based on FPGA technology is an example. Another is an application-delivery controller employed to increase the efficiency of servers and affect performance and security through offloading of tasks like SSL encryption/decryption and protocol execution.  (MacVittie, 2009) Such products serve as black-box design elements that use precast designs with highly confined user design.

The distinction between software connectors and hardware connectors is that in software connector use, specific hardware enablers must be determined. As such, this is required for software-connector use in software-architecture design.   Also, the use of the hardware elements requires software integration prior to their use.

Hardware connectors require no hardware selection. Their associated hardware elements are pre-determined by the vendor and packaged in the connectors’ physical enclosure.  Any software primary and secondary connector design activity involving selection and integration must be done by the product vendor before delivery for use.

User design involvement is limited to explicit hardware configuration settings and parameter/script user custom-configuration actions with such connector types. 


4.            Complex Connector Support of Software Architecture 

Figure 5 shows a modified graphic of a proposed Intel-Oracle design approach for implementing Java applications on Java application servers.

                                  Figure 5.          Multi-Layer Nature of Java Server Applications. Source: (Ban et al., ND)

This suggests how layers of software have specific responsibilities in executing Java application-server workloads. The approach additionally reflects the server platform and CPU support in workload execution. Among the needed tasks are several selection activities and tuning actions. The multiple selection activities suggest that selection is of some importance in support of workload performance. And not only is selection of the secondary and primary connectors expressed, but the hardware elements for the server platform and CPU responsibilities. In this example, two secondary connectors can be identified and one primary connector. The secondary connectors are a J2EE application server and Java Virtual Machine (JVM). The primary connector is an operating system. Use of these connectors is founded upon two key ideas, the interrelationships between primary and secondary connectors that form a primary-secondary connector taxonomy, and connector-architecture pattern relationships or links.

Commonly shared primary and secondary connector traits include compatible computer architectures (x86, SPARC, PowerPC, Arm, etc.), computer memory requirements,  processor speeds (minimum and recommended), application domains the product can support, protocols used, editions or versions for target operating environments, and various system-quality-related properties (performance, scalability, availability, management, etc.).  Table 2 compares the technical attributes of products across the primary and secondary connector taxonomy.

              Table 2.  Sample Connector Product Technical Profile. Sources: (Microsoft, 2016; Red Hat; Techotopia)


Connector Type








# CPUs Supported  i.e. Multi- Processor


Primary: Windows OS

Windows Server 2008 R2

o   Web

o   Standard

o   Enterprise

o   Data Center

(1) CPU: Min-1 64-bit 1.4 processor

Min:512 MB

 Max: Web - 32GB; Standard - 32GB; Enterprise - 2TB; Data Center - 2TB

Web: 4; Standard: 4;

Enterprise: 8;

Data Center: 64


Primary: Linux

Red Hat Enterprise Linux version 5

o   Advanced Server

X86; Intel X86-64; Power; System Z

Max(per CPU architecture):

X86 - 16GB;  Intel64 – 1 TB;  Power -  1 TB; System Z – 1.5 TB

No limits for multi-core support


Data Server

SQL Server 2012

o   Enterprise

o   Business Intelligence

o   Standard

o   Web


Processors: X64;AMD Opterion; Intel Xeon w/EM64T support; X86: Pentium III or faster

Min: 1GB

Recommended: 4GB or more

Web: 4; Standard: 4

Business Intelligence: 4

Enterprise:   OS limit


 Secondary connectors manifest other technical attributes among which are compatible primary connectors, specific functionality or services the connector affords for system functionality implementation, and other secondary connectors necessary to accomplish its services as well as others of an optional sort only employed to meet a specific use context. 

In software architecture design, the nature of interdependent relationships between secondary and primary connectors, and their technical capabilities drives the process. Secondary connectors require primary connectors that allow their use some primary connectors do not.  Table 3 shows examples for the online Symantec Enterprise Products and Platforms Matrix tool (Symantec Corp. Inc., 2015) of available Symantec Storage Foundation secondary-connector middleware products for various primary connectors and processor platforms.   The Symantec Application High Availability product is not supported for Oracle’s operating system products.

Table 3.  Symantec Storage Foundation Middleware Product-Platform Availability for Sample Primary Connectors.
(Symantec Corp. Inc., 2015).

Symantec Secondary Connector Product



Hardware Processor Platform

Primary Connector Type

Primary Connector Source

Primary Connectors Supported

Dynamic Multipathing for Windows





Windows Server 2008 R2

Dynamic Multipathing for Solaris





Solaris 11 (11.2 and up to, also 11.1 up to, etc.) and 10 (update 8,9,10,11) versions

Dynamic Multipathing  for VMWARE


Not Specified

Type-1 Hypervisor



Application High Availability (HA)





Windows Server 2008 R2









Red Hat (Linux)

RHEL6 Update 3, 4, 5 with VxFS, LLT, and ODM patches


Any/Not Specified

Type-1 Hypervisor





   Both primary and second-connector products can differ in their nonfunctional support capabilities.  Table 2 indicates that Redhat Linux has stronger support for concurrency than Windows Server 2008 because it does not restrict the number of multiple processors.   Figure 6 and 7 show the performance and high availability means that higher-end SQL Server 12 versions offer.  Microsoft Server 2012 Enterprise edition has more features for scalability, performance, and availability. 


  Figure 6.          Microsoft Server 2012 Edition Scalability & Performance Features (Source: (Microsoft, n.d.).


                 Figure 7.          Microsoft Server 2012 Edition High Availability Features (Source: (Microsoft, n.d.)



Connector choices result in design options for software architectures for both the functional and nonfunctional design elements.  This says that, when alternative solution elements exist, it is important to choose the best suited alternative. Such an alternative however must be one duly structured to each connector’s specific technical attributes and features, and which considers how these can best be applied for a solution.  Proven connector design patterns enable these choices.


5.            Nature of Connector-Architecture Pattern Links

The Intel-Oracle Java application study asserts that selection of the secondary and primary connectors and associated hardware elements is of considerable importance in carrying out desired Java-application responsibilities. That is because of the dependency of secondary and primary connectors on hardware, summarized in Table 4. (Patterson & Hennessy, 2009). 


                Table 4.  Hardware-Software Component Performance Impact. Source: (Patterson & Hennessy, 2009).

Hardware or Software Component

How this component affects Computer System performance

·   Programming language, compiler, and instruction architecture

Determines the number of computer instructions for each source-level statement.

·   Processor & memory system

Determines how fast instructions can be executed.

·   I/O system (hardware and operating system)

Determines how fast I/O operations may be executed.


Patterns are employed in software architecture to enable software systems to meet their functional and non-functional objectives. The common terminology for the pattern types associated with the three design abstraction levels is that of architecture, design, and idiom.  Their use in architecture design is as a means of traversal from the highest architecture pattern design level, architecture, to the mid-tier design level, tactics, to the implementation level, idiom.  Architecture level type patterns are also known as architectural styles.

  Architecture patterns are applied across an entire application for small software products, and applied to specific subsystems for larger ones.   Client-Server and the Layered types are among the most common.  Architecture styles package groups of tactics including some and omitting others. Architectural pattern use encompasses positive and negative design aspects. Architecture “tactics” can fill in gaps in architecture design when needed.  An architecture tactic is an architectural-design element of finer granularity than an architecture pattern (Scott & Kazman, 2009). They can implement quality properties (Rozanski & Woods, 2005) and modify architectural patterns for a particular problem context.

An inherent tactic of the Client-Server architectural style is use of concurrency. The style invokes use of two distinct computational resources which can concurrently perform distinct forms of processing. However, this architectural pattern does not itself address possible faults in the client or server operation. The architectural pattern needs to be augmented with a tactic like active redundancy. 

Idioms implement architecture tactics. Idiom pattern types in software design are often associated with programming languages (Stahl, 2004). Thus per Stahl’s association of idioms with languages, idioms differ from other pattern types in that their use applies to specific technologies.  We extend this to support primary and second-connector roles in the shared hardware-software design space.

The availability of idioms depends on the technical characteristics of each primary or secondary connector as well as the nature of existing inter-relationships between primary and secondary connectors. To meet this challenge requires knowledge of the applicable primary-secondary connector design relationships based on connector individual technical traits. We consider that these relationships and connector technical characteristic forge Connector-based Design Patterns that apply to the SW-HW Design Space. Figure 8 defines our patterns.



                                                                      Figure 8.          SW-HW Design Space Connector Design Patterns


The nature of these Connector Design patterns reflect three possible design pattern types to implement an idiom associated with an architecture tactic. The Software Connector SW Feature Use pattern is defined as use of the software features a connector offers to best support optimal connector performance efficiency and applicable nonfunctional demands.  Use of this pattern has no association with any associated hardware activities. It is entirely dependent on the nature and forms of software features a connector offers. 

The Hardware Connector pattern is good for designs that require minimal or zero primary and/or secondary-connector design action but still benefit from the system quality properties. Typical use of this pattern is as a supplementary design element. Such connector types fill system property needs not achievable via Software-Only and Hardware-Software patterns. They can serve as hardware acceleration elements. They can also off-load select connector services to allow other primary and secondary connectors to better use their resources on other more vital connector services that they contribute to a system’s design (MacVittie, 2009).

The Software Connector HW-Dependent Feature Use pattern entails the consideration and selection of hardware elements with exacting intent to enable inherent system quality attribute supporting features of primary and secondary connectors. To do so requires explicit design understanding and knowledge of the technical features that primary and secondary connectors possess. Use of this design pattern is found in shared hardware-software design spaces exemplified in the selection and employment of hardware elements and configurations to realize optimal connector performance and demands. Oracle’s technical guidance for the Oracle Endecca MDX server hardware requirements is an example.

Oracle details the Endecca MDX server’s hardware needs in terms of minimal and recommended hardware requirements. (ORACLE, 2014 ) The only supported primary connectors for this secondary connector are Oracle Linux 5, Redhat Enterprise Linux 5, and the Windows Server 2008 R2.   The minimal recommended hardware is an X64 processor minimum 1.8 GHZ, 3 GB of RAM, and 80 GB hard drive.  The recommended hardware is different, enabling higher performance.  Recommended hardware is a X64 processor 3.0+ GHZ processors Intel Xeon (including Nehalem) or AMD Opteron; 8 GB for RAM, either a high performance locally-attached RAID storage or high performance NAS, and gigabyte Ethernet.  In this instance, a decision was made for the recommended non-minimal hardware elements for use with an Oracle Endecca MDX server, and then the subsequent software integration actions to use this hardware reflects the pattern.

Overall, for the three different idiom patterns for the shared hardware-software design space, the Software Connector SW Feature and Software Connector HW Dependent Feature provide a wider range of possible design implementation options, with the respective user design choices of much greater influence and impact in key design attributes for successful primary and secondary connector implementation. And it is primarily through Software Connector SW-Only Feature Use and Software Connector HW Dependent Feature Use patterns as well as the primary-second-connector interrelations and primary-secondary connector nonfunctional features that architecture tactic implementation is achieved.

Primary and secondary-connector authors (vendors and developers) are the main sources for idioms that support system-quality implementation. Experienced practitioners are necessary for primary and secondary-connector selection, design, and implementation of architecture patterns.  Subject matter expertise of these sorts provide the ”key characteristics” used by the Society for Automotive Engineering’s (SAE) Aerospace AS9100 standard for quality in product design (Noyes, N.D. ). Key characteristics denote features of a material, process, or part whose variation has significant influence on product fit, performance, service life or manufacturability. Their design warrants a high level of scrutiny in their identification and use.


B.           A Connector Computation model

Connector consumption of computing resources demands explicit resource planning and close scrutiny of resource use to avoid undesirable outcomes (Taylor et al., 2010). All connectors consume computing resources and can be inefficient in doing so.

Connectors engage in two type computational tasks, those undertaken in response to requests by other connectors for their services, and those involving housekeeping operations done for management and control.  Each is characterized by repeated operations whose efficiency has a high impact on connector performance.

The interdependent nature of software connectors defined by our software connector taxonomy, and the fact each Connector has an associated Connector Computation model, establishes areas of high potential conflicts over resources between connectors that share the same hardware platform. Deployment planning for host environments for software connectors must account for this.   Proposed generic performance tactics for Resource Arbitration (Bass, Clements, & Kazman, 2007) and Minimizing Shared Resources (Rozanski & Woods, 2005) provide means. The design space solution plans must also account for design confluence of distinct non-functional requirements.



The host deployment space must be adequately provided with suitable hardware for use of applicable primary and secondary-connector features supporting design functional and nonfunctional needs.  The starting points are the technical characteristics for each design-space primary and secondary connector. These are detailed in each connector’s requirements that indicate the host platform architecture support, RAM requirements, I/O needs, etc. These though necessary are not sufficient. A second necessary source are the connector vendors’ technical performance guidance for specific hardware elements and configurations to enable optimal connector service performance.    Availability of these detail planning assets affords use of the Software Connector HW-Dependent Feature Use.  

The use and forms of Primary and Secondary connector service types and associated housekeeping operations vary.  But actions to meet deployment space resource needs must account for both type Connector Computation model tasks that may apply for all deployment space connectors.    Also, care must be exercised to avoid resource use conflicts and undesired impact between the different connector compute model tasks.  

IV.           CONNECTOR Design Examples


Two distinct case studies illustrate Chapter III’s software-connector design practices and guidelines. The first is in a full software-system life-cycle effort.  A second is in a project post-deployment performance improvement initiative. 

 In the first, the project effort had total design control over the shared hardware-software design space; in the second, the hardware aspects were controlled by the DOD hosting-facility authority.


A.          AHRS Case Study

The AHRS Superserver was a major reengineering effort of a fielded large-scale Ada-based information system. AHRS is an acronym for Army Human Resource Management System. AHRS was the active Army’s personal management system for soldiers at the Army installation level for both deployed and non-deployed Army units. After successful deployment at a large number of various size CONUS (continental US) and OCONUS (outside the continental US) Army sites as a locally hosted system, the product was reengineered as an online web application rehosted at a single CONUS-contractor leased facility.  What is recounted is not a specific chronology.  Rather, the study expresses the AHRS approach in applying software-connector practices, the resultant benefits, as well as the undesirable outcomes when not used or when the associated implementation was not true to the range of required actions.

Due to the nature of software connector relationships, connector technical design attributes, and connector design patterns employing software connectors in the hardware-software design space requires an orchestrated series of activities.  The ordered sequence of activities form a Connector Based Design Process.


                                                                                                                Table 5.  Connector Based Design Process


When Applied

Outputs Produced

Next Step

Connector Selection

Need to select primary and/or secondary connectors

Design space primary and secondary connectors

Connector Solution Planning

Connector Solution Planning


Initial build or need to revise  Connector Solution plan

Design space secondary connector design elements; design space connector nonfunctional requirement implementation support

Application Usage Model

Application Usage Model

Initial build or need to revise Application Usage model

Identification of known/projected system function design element use frequency

Connector Solution Design

Connector Solution Design

Initial build or need to revise Connector Solution Design

Plan and employ design space secondary connector design elements and nonfunctional requirement implementation features in support of system function design element use frequency

Deployment Planning

Deployment Planning

Initial or need to upgrade  shared hardware-software deployment design space

Provision deployment environment to utilize both hardware dependent and non-dependent primary & secondary connector nonfunctional features 

Connector Performance Oversight

Connector Performance Oversight

Test events and  operational environment monitoring

Oversight results indicating need or no need to modify Connector Solution plan or revise Connector Selection results

As oversight  results dictate



B.           AHRS Connector Selection

Gorton advocates (Holt, 2009) a formalized selection process for architected solutions of the software-solution design space due to the expanse of potential technologies and sources (COTS, Open source, GOTS).  Detailed features evaluation of candidate technology sets and proof-of-concept prototypes are suggested approaches.  The design of AHRS embodied these concepts in its choice of compatible secondary and primary connectors with appropriate functional and nonfunctional features for its reengineering plan. 

The original AHRS fielded system was deployed as a very large Ada-83 based system hosted on a UNIX operating system supported by the XDB DBMS product.  The fielded design was a distributed approach using groups of servers deployed at the hosting Army facilities in country and overseas.  The cause for the original distributed design was the inherent lack of scalability of the XDB DBMS product, whose use only allowed small groups of soldiers, less than 25, the concurrent use of the system at any one time. 

As the initial thrust of the reengineering initiative, a two-phased plan was put in place to carry out a technology refresh effort.  The first plan phase task determined a suitable replacement for the existing DBMS XDB COTS product.  The second phase identified candidate technology choices to web-enable the existing project Ada applications.

A group of both current developers and contractor consultants was formed for the first phase execution.  The group’s first task garnered all the solution context materials. 

Detailed questionnaire instruments were developed that identified the current standard and expected market-space features for midsize-to-large user-population relational DBMS products.  The features checklist included both the typical data management services DBMS secondary-connector types offer and the nonfunctional feature support for performance and availability system quality properties.  The AHRS DBMS secondary connector, a data access connector, provided AHRS Ada applications the means through SQL for AHRS data retrieval and persistent data management.  Specific DBMS checklist items included support for SMP hardware architectures, SQL statement caching, means for SQL statement optimization, and stored procedure capability. Each secondary-connector candidate source was tasked to identify other existing performance or availability features their product offered not included on the checklist. Another requirement was identification of existing primary connectors supporting their products’ nonfunctional requirement-enabling features.  Support for ACID-based transaction processing was among the availability specific checklist features identified. Available candidate secondary-connector DBMS sources were constrained by the project Ada application DBMS interfaces.

AHRS Ada programs employed two forms of interfaces to interact with the AHRS DBMS, dynamic SQL and static SQL.  The SQL interfaces used the SQL Ada Module Extension (SAME) and the SQL Ada Module Description Language (SAMeDL) technologies (Moore, October 1996). Use of the SAMeDL language requires a language processor to create an equivalent Ada procedure and support code for Ada programs to use the services of a DBMS secondary connector.  A large portion of the AHRS DBMS interface was based on this interface, but only a limited number of DBMS vendors supported it.   

  It was decided to do physical validation to determine a suitable choice between the two candidate DBMS vendors. A choice was made of a primary connector, SCO UNIX 5.0, compatible with both candidate DBMS choices.

With dynamic and static DBMS interfaces, candidate DBMS products had to provide adequate support for both. Judgment criteria included the computational efficiency and ease of effort to transition the current Ada application dynamic and static designs. 

 The physical validation revealed the Informix approach to be superior due to higher computational efficiency in the use of dynamic SQL. The Informix approach required fewer dynamically built Ada language constructs. The Informix SAMeDL implementation also allowed for an easier port of the existing Ada application static SQL.

In the second phase selection task, a group determined the secondary connector Tarantella (Tarantella-A-Technical Overview, 2001) to web-enable the AHRS UNIX character-based applications for Web use through a web browser. Identified project functional and nonfunctional requirements were applied. However the primary connector choice was not among the identified compatible offerings. And no form of physical validation through prototype testing was carried out prior to fielding.


C.                AHRS Connector Solution Planning


The connector tasks and the Shared Software-Hardware Connector Design Space patterns require many technical details. These included identification of the design-space primary and secondary connectors; design-space secondary-connector design elements; and design space connector nonfunctional requirement implementation support. 

The goal of a connector based-design plan is to optimize the task execution and resource use of the Connector Computational models sharing the hardware-design space while meeting their intended functional and nonfunctional responsibilities. Connector-specific idioms that support particular nonfunctional requirements may not only require actions to control and manage services, but also specific housekeeping tasks.  

The dynamic nature of the Connector Computational model for secondary connectors used is driven by system functionality frequency. This assists in identifying the key connector design elements of greatest influence to better inform architecture selection and design planning. 

Most secondary-connector performance patterns in the Connector Computation Model focus on reuse of secondary-connector assets such as user-interface elements (screens and porlets), files, reports, and code.  Another key is assessing which primary and secondary nonfunctional features require specific hardware support.  Providing the shared space with these elements is the basis of the Hardware-Software Connector Feature Integration design pattern.

AHRS had a Real Use Case comprised of a large collection of “structured English” constructs. Its model was organized into logical domains based on system functionality. The model detailed for each system function the data elements involved, the screen identifiers for the user interface screens used for processing, the logical sequence of actions of the services the function performed, data outputs the function produced, data-store interactions (reads/writes), and transactions associated with external system interfaces. Logical architecture analysis identified five distinct organization schemes for the total range of system functions:

1.                  User-interface sequences, data-store reads, and data-store posts.

2.                  User-interface sequences, data-store reads, and data report generation.

3.                  User-interface sequences, data-store reads, data-store posts, and transaction processing to external systems.

4.                  User-interface sequences, data-store reads, data-store posts, and data report generation.

5.                   User-interface sequences, data-store reads, and transaction processing to external systems.

These schemes were recorded in a system design/database reference.

1.                  AHRS Application Usage Model

The fielded AHRS Ada applications produced detailed logs that tracked the system functions each user initiated and completed during system use.  The dates and times the function was initiated and completed were recorded.   It also recorded any Ada exceptions. 

Logs were collected from each deployed AHRS site and used to create load test models that detailed for each site and in general the typical frequency of use of each AHRS system function. Knowledge of the typical frequency of each AHRS system function and the assets (screens, data stores, etc.) those functions employed enabled identification of the key AHRS-connector design elements where secondary-connector performance-enabling features should be applied.


D.                AHRS CONNECTOR Solution DESIGN

AHRS used three key secondary connectors: the Alsys Ada-83 compiler (ORACLE, 2013), the Informix Online Dynamic Server version 7 DBMS, and the Tarantella application server. Other secondary connectors like the AdaSame Intermetrix compiler were part of the AHRS reengineering effort.

 Based on the five AHRS S/DBDD logical architecture functional schemes, five standard Ada design templates were developed to build each AHRS application.   Layered design was done with a series of subsystems formed out of Ada package elements. A large share of common code was organized into a common code subsystem.  The components were all optimized using the Alsys Ada-83 compiler optimization features (Ada Information Clearing House, 1995). This is an example of the Software Connector SW Feature use pattern through use of the AHRS secondary-connector Alsys compiler performance-enhancing features for the AHRS Ada design elements.  

Replacement of the XDB database with Informix created a new opportunity in the reengineering effort for use of features previously unavailable. The XDB DBMS lacked features to support effective scalability Informix included. Among these were a configurable in-memory data cache, index-only reads, stored procedures, and Query optimizer for optimization of query performance. 

The database team was able to develop a plan of action to gain benefits from these. The scheme needed to align with the DBMS secondary-connector data-access internal architecture comprising the DBMS product, the Informix Online Dynamic Server 7, and the Connector Computation model. In this, technology-specific idioms for computationally efficient approaches apply (Schneider, 1995)(Schneider, 1995):

1.                  Query requests for data are optimally satisfied by accessing those already in the in-memory data cache. Hence, a key goal was to maximize data-cache use for read requests.

2.                   Index-Only Reads afford use of a smaller data resource footprint, an index, instead of a larger one, a data table, to fulfill data requests.

3.                  Stored procedures and use of the SQL prepared statements reduced the overhead, query parsing and execution plan building in executing SQL queries.


The plan first used the Real Use case model profiles in the S/DBDD document to rank the most commonly used system screens for the most commonly used system functions. The most commonly used AHRS user interface screens all employed one or more data access requests to the database as a basis of user interaction.  One screen Sys01 was involved in most AHRS Ada applications.

Secondly, the SQL design of these common DBMS data access requests was optimized. This occurred in stages. The first involved use of the Set Explain On command which uses the Dynamic Server Query Optimizer to provide a query execution plan. Figure 9 is a sample. The lower the estimated cost, the better the performance. Key-only notation in a query plan reflects Index-Only Read use. So for the most commonly accessed database columns, creating indexes enables optimal access.  SQL after undergoing optimization is compiled as Stored Procedures which avoid parsing and execution-plan building and allow use of the DBMS stored procedure cache. The outcome was a noticed improvement in screen response time.

                                           Figure 9.           Sample Set Explain On Output. Source: (Informix Software, 1995)


Lastly, a development standard was introduced to direct use of the SQL Prepare statement when using SQL code in loops that would result in multiple calls to the DBMS for execution of the same SQL statement. 


E.           AHRS Deployment Planning

   The AHRS deployment host environment (Figure 10) shows the AHRS deployment.


                                                                              Figure 10.        AHRS Deployment Host Environment[MS3] 


The two forms of AHRS server platforms employed vertical scaling, using larger capacity platforms for larger workloads. The larger AHRS site workload used quad SMP platforms; smaller ones, dual SMP hosts.  SMP allowed AHRS Ada applications and secondary connectors to execute concurrently through the SCO primary-connector capabilities.  This use reflects the Software Connector HW Dependent Feature pattern.

AHRS design reflected high demand for the Informix DBMS. Provisioning host AHRS servers with multiple processors enabled use of the DBMS processor affinity feature for the larger AHRS sites. This provided a means to avoid potential scheduling and resource conflicts with the host primary connector, SCO operating system, and Ada applications. 

An additional AHRS Connector Selection benefit was the design use of the common UNIX operating system raw device and associated kernel asynchronous input-output capabilities. The UNIX raw device mechanism enables a DBMS to perform input-output directly (Schneider, 1995).  Another secondary connector feature was kernel asynchronous I/O (KAIO) through SCO UNIX 5.0 (Informix Software, 1995). 


For the Tarantella secondary connector, the means for access to AHRS applications via a web browser, a physical tier hosting approach was employed.  Three distinct Tarantella Server instances enabled a higher level of physical concurrency through use of the products’ server-array horizontal scaling with load balancing (Tarantella-A-Technical Overview, 2001).  The load balancing also incorporates availability support. It has a hardware dependency realized through application of the Software Connector HW-Dependent Feature Use through provision of a dedicated subnet.


F.                 AHRS Connector Performance Oversight 


A plan to monitor performance of the key AHRS connectors was developed and made part of the AHRS S/DBDD document. The plan identified assets and procedures.  Both shared resources and connector assets were part of AHRS Connector Performance oversight.  Shared resources included the notices of operational impacts produced by the AHRS help desk staff and AHRS application logs.

A 24-hour 7-day help desk was part of the AHRS hosting operation.  When operational issues occurred, help-desk staff would record a notice in an online help system. Notices that reflected operational issues impacting or denying successful operation of system functionality were distributed to the development manager, database team, application development lead, and system administration staff for necessary corrective action.  For issues resulting in unplanned hosting outages, the AHRS hosting contractor formalized an action plan with defined checkpoints.

 AHRS Connector performance oversight proved of critical value toward achievement of the ultimate success of the AHRS Superserver reengineering project.  Cause of this assessment is the identified multiple accrued benefits.


·                     Tarantella Enterprise Server oversight resulted in the identification of an instance of COTS mismatch of such severity to result in the replacement of the original Tarantella Enterprise primary connector with the Sun Solaris Unix product. The phase 2 of AHRS selection did not account for this connector as supporting Tarantella Enterprise Server.

·                     Informix Online Dynamic Server oversight identified a critical bug associated with nested outer joins in the release for SCO UNIX.  This critical bug denied the highly used AHRS Ada Adhoc Query application until a suitable fix could be applied. The bug resulted in the immediate crash of the DBMS server when SQL using nested outer joins was presented to the server for execution.

·                     Informix Online Dynamic Server oversight identified critical improvements to AHRS Ada application standards for database transactions that were responsible for non-availability for some AHRS system functions. The original design for database maintenance transactions did not anticipate possible resource conflicts with greater numbers of concurrent AHRS users and DBMS locking resources.    The DBMS and Ada application monitoring approaches used together identified the faulty Ada application design enabling application of needed fixes.  The AHRS development standards were also updated to direct the design of database maintenance transactions to avoid unavailability of needed DBMS locking resources.


·                     Ada application oversights found some forms of architecture degradation issues in AHRS Ada application implementation. Included was an instance of failure to follow the AHRS Ada application design standard of state-machine-based navigation. The noncompliance resulted in a much higher level of application failures. The application was redesigned to align with the standards


G.                AAAS Case Study

This case describes application of connector design principles to a plan to accommodate a larger user population for a high-profile DOD big-data analytics system.  AAAS is the substitute project name.   The project produced online customized profiles and analyses for a range of DOD customer organizations.  The daily customized profiles resulted from analytic tasks against data sources populated by backend data-warehousing operations.   An array of different COTS products supported the delivered services and outputs. 


Unlike AHRS, the AAAS effort used their existing Connector resources to allow more AAAS users.  No detailed AAAS software architecture design reference was available, like the AHRS S/DBSS document that gave a design scheme and approach for use of the AAAS connector features and design elements. There were some high level AAAS architecture diagrams that indicated the major AAAS connector elements.    However these did not accurately reflect the actual AAAS host environment located at an Army enterprise data center.


H.                AAAS Connector Solution Planning


To use connector nonfunctional features, you must first know the connectors in the design space, what features those connectors provide, the associated hardware elements necessary to use them, and the Connector Computation models that influence their application.  This knowledge provides the foundation to use the SW-HW Design Space Connector Design Patterns. AAAS had no software architecture description or software design plan.  So an initial effort focused on identifying the connectors involved for the range of AAAS system functions.

  A mapping of the major AAAS secondary connectors was created.  The mapping identified two suites of ORACLE secondary-connector products to deliver AAAS system functions.  One set was used for the big analytic system functions and the other for the range of business intelligence reports.  Figure 11 shows the ORACLE Endecca Studio big-data-analytic secondary-connector suite. This is a Web-based application that runs in an application server.  Table 5 identifies the choices for secondary connectors Studio requires.



    Figure 11.        Oracle Endecca Information Discovery Components. (Source:  (ORACLE Endecca, 2012)



          Table 6.  ORACLE Endecca Studio Supporting Secondary Connectors (Adapted from (ORACLE, 2013).


Supported Versions


Application server

1.      Tomcat 6.  The Studio Tomcat bundle includes Tomcat 6.0.37

2.    Oracle WebLogic Server 11gR1 (10.3.6)



Application Server

Endecca Server  (7.6.x version)  


Java compiler

Sun Java 6, update 18 or greater.

Database system

1.      MySQL 5.1

2.      Oracle 11g


AAAS used Tomcat 6 for the Java application server and Oracle 11g for the DBMS.  Three primary connectors, VMware vSphere 5.1, Red Hat Enterprise Linux version5, and Windows Server 2008 R2, supported the AAAS secondary connectors for big-data analytic system functions.  Initially the key design elements and performance features associated with the two key ORACLE Endecca secondary connectors, Studio and Endecca server, were identified.  Figure 12 shows the connector service-request workflow between the two whereby analytic requests initiated from Endecca Studio are passed to the Endecca Server for processing.  The Dgraph diagram entity is the key Endeca Server design element.


Figure 12.        Single Node Endeca Architecture. Source: (ORACLE - Endecca Server Administrator Guide, 2014)

Dgraph is an in-memory database. The Endeca server engine is responsible for data access (read/write) for Studio applications to Endeca server Dgraphs, Endeca data domains.  An Endeca server can support one or more data domains. 

 Data domain profiles control data-domain operations and include performance-specific settings affecting Dgraph performance.  The Data domain profile settings are examples of Endeca Server software-connector features that the AAAS software-architecture design can benefit from through application of the SW-HW Design Space Connector Design Patterns. The Oracle Endeca performance guide identifies the key Oracle Endeca secondary-connector performance parameters.  One key parameter is the Num-compute-threads parameter for the server multi-threading to act concurrently to service Dgraph data query requests (Oracle - Endeca Performance Guide, 2013). The parameter however is hardware-dependent: It is only effective if used with a physical or virtual host platform with multiple processors.   Another hardware-dependent parameter is the ComputeCacheSize that defines the working size of the Dgraph memory cache. An excerpt from the Oracle Endeca Performance Guide in Figure 13 suggests the impact it can have on Dgraph performance. 

Figure 13.        Dgraph virtual memory vs. RAM: use cases. Adapted from Oracle Endeca Commerce MDEX Engine Performance Tuning Guide  

“RAM” in the Figure is the physical memory in the platform hosting the Dgraph.  “VM” is the total amount of virtual memory allocated by the operating system to the MDEX Engine process. It includes the Dgraph code, the MDEX Engine data as represented on disk, the Dgraph cache, and any temporary work space. “WSS” is the amount of memory a Dgraph process is currently using. This amount is needed to avoid paging. The numeric labels indicate three possible conditions of Dgraph Ram use.

Cases 1 and 2 indicate conditions where the Dgraph can operate at optimal performance. Case 3 shows a condition to avoid results in poor I/O performance, where WSS starts to exceed RAM.

The Endecca server offers multiple means to monitor Dgraph performance. A primary resource is the Dgraph Stats page. The Performance Summary (Table 6) shows data useful to discern areas of potential conflict with a host primary connector.  A statistic of a 40% or more total CPU consumption for total system versus user time indicates possible issues with the implementation for a primary connector’s Connector Computation model.  This is verifiable when a primary connector supports only one secondary connector. The cause may be associated instead with other secondary connectors otherwise.    

                     Table 7.  Sample Performance Summary Table. Source: (Oracle - Endeca Performance Guide, 2013)





Average, standard deviation, minimum, maximum, and total on:

    The total number of requests received

    Total CPU usage (in seconds of total user time and total system time).

    The memory resource usage.

    Resident Set Size (RSS) statistics.

Throughput (req/sec)

Five-minute, one-minute, and ten-second average throughput statistics (only for multithreaded mode). When thread becomes available, the throughput statistics is measured.





 Communications latency problems between the Endeca Studio host platform and the Endeca Server platform were suggested by the AAAS lead developer and other staff member comments.  A questionnaire was established to get specific technical details regards the AAAS deployment environment from the government hosting organization. The questions were framed to align with the VMware vSphere Connector Computation model the hosting organization used for the AAAS host deployment environment.

Ultimately, a design was communicated to the AAAS program manager to increase the number of concurrent AAAS users for AAAS data analysis.  Vertical scalability features in the AAAS Oracle Endeca secondary-connector suite through the addition of multiple Studio and Endeca server instance helped achieve this objective.  The awareness of the technical capabilities of these specialized secondary-connector products enabled this outcome.  






                                                                                                      V.            Summary and Future Work

Primary and secondary-connector technical characteristics and features that enable functionality, performance, availability, and other system properties are the essential design intelligence assets for the shared hardware-software design space.   Key architecture design life-cycle activities not founded on proven practices can cause design failure and inadequacy. Design of primary and secondary connectors in the shared hardware-software design space results in unique design models. These include Connector Computation models for each design-space connector.  Our software-connector taxonomy identifies key design relationships that design planning the primary task of software architecture must acknowledge.


Our case studies illustrate how an integrated engineering-based approach and associated design practices in software architecture through software-connector based design advance the software engineering discipline via proven best practices.


A.          Future Work Opportunities

Future work opportunities include the development of software-engineering domain-specific software-connector taxonomies based on our taxonomy approach.    The need for such taxonomies is suggested, for instance, by the extensive expanse of development technologies for the cloud computing solution space.  Figure 14 reflects the plethora of available data server technologies for the Cloud landscape.





   Figure 14.         Cloud Space Data Server Technologies. Source:  (The 451: the Database Landscape, 2013)


































SEI has a related ongoing effort to assist in Cloud-based software technologies. 

Other candidate areas of follow-on research is further development of Software Connector design patterns associated with the range of distinct primary and secondary connector types.






















II.               References

Ada Information Clearing House. (1995). AdaIC Available Ada Bindings Report-1995 Section 5: Products Available from Vendors. Retrieved from AdaIC Archive:


Army CIO & Assistant Secretary of the Army (Acqusition, Logistics, Technology). (2010, October 20). Common Operating Environment Architecture. Common Operating Environment Architecture. Washington, DC, US: U.S. Army.


Ban, K., Chow, K., Yong-Fong, L., Butera, R., Friberg, S., & Peers, E. (n.d.). Java Application Server Optimization for Multi-core. Retrieved from


Bass, L., Clements, P., & Kazman, R. (2007). Software Architecture in Practice (2nd ed.). Westford, MA: Addison-Wesley.


Boehm, B., Kind, L. G., & Turner, R. (2002, May-June). Risky Business: 7 Myths about Software Engineering That Impact Defense Acquisitions. Program Manager, pp. 74-79.


Garland, J., & Anthony, R. (2003). Large-Scale Software Architecture. Chichester, West Sussex, England: John Wiley & Sons, Ltd/ .


Gorton, I., & Liu, A. (2003). Evaluating the Performance of EJB Components. IEEE Internet Computing(May-June), pp. 18-23.


Holt, R. C. (2009). Essential Software Architecture. Retrieved from Department of Computer Science, University of Waterloo:


IEEE Computer Society. (2004). Guide to the Software Engineering Body of Knowledge SWEBOK. Los Alamitos, CA: IEEE.


Informix Software. (1995, May). INFORMIX-OnLine Dynamic Server, Database Server Performance Guide, vers 7.1. Retrieved from


Joint C2 Architecture Core Team for the PEO-C2C. (2012, May 7). Joint Command and Control (Joint C2) OBJECTIVE ARCHITECTURE: PHYSICAL VIEW. Fort Meade: Defense Information Systems Agency (DISA).

Krafzig, D., Banke, K., & Slama, D. (2005). Enterprise SOA Service-Oriented Architecture Best Practices. Upper Saddle River, NJ: Pearson Education Inc.


Laplante, P. A. (2007). What Every Engineer Should Know About Software Engineering. Boca Raton, Florida: CRC Press.


Larus, J. (2009, May). Spending Moore's Dividend. Communications of the ACM, 52(5), pp. 62-69. doi:10.1145/1506409.1506425


Lindstrom, J. (2008). Real Time Database Systems. Helsinki, Finland: Solid IBM.


MacVittie, L. (2009, June 17). What is server offload and why do I need it? Retrieved from :


McDougall, R. (2005 , September N/A). Extreme Software Scaling. ACM Queue Magazine, pp. 38-46.


Mehta, N. R., Medvidovic, N., & Phadke, S. (n.d.). Towards a Taxonomy of Software Connectors. . Retrieved September 7, 2016, from


Microsoft. (2016). Hardware and Software Requirements for Installing SQL Server 2012; Compute Capacities by Edition of SQL Server 2012. Retrieved from Technet:;


Microsoft. (n.d.). Features Supported by the Editions of SQL Server 2012. Retrieved December 3, 2016, from


Moore, J. W. (October 1996). AdaIC Available Ada Bindings Report-1996. Retrieved from


Noyes, G. (N.D. ). KEY CHARACTERISTICS. Retrieved 2014, from Defense Acquisition University Acquisition Comunity Connection .


Oracle - Endeca Performance Guide. (2013, April). Oracle Endeca Commerce Performance Guide. Retrieved from Oracle Docs:


ORACLE - Endecca Server Administrator Guide. (2014, June). Oracle Endeca Server Administrator's Guide Version 7.4.0. Retrieved from

ORACLE. (2013, May ). Oracle Endeca Information Discovery Studio Studio Installation Guide Version 3.0.0 Rev. A. Retrieved from


ORACLE. (2014 , February). Oracle Endeca Server Installation Guide Version 7.4.0 . Retrieved from


ORACLE Endecca. (2012, DEcember). BI_US_EN_WP_TechOverview. Retrieved from


Patterson, D. A., & Hennessy, J. L. (2009). Computer Organization and Design: The Hardware/Software Interface, Fourth Edition. Burlington, MA: Elsevier Science and Technology Books, Inc.


Red Hat. (n.d.). Server versions comparison chart. Retrieved from


Rozanski, N., & Woods, E. (2005). Software Systems Architecture. Upper Saddle River, NJ, : Pearson Education.


Schneider, R. D. (1995). Optmizing Informix Applications. Upper Saddle River, NJ: Prentice Hall.


Scott, J. B., & Kazman, R. S. (2009). Realizing and Refining Architectural Tactics: Availability. Pittsburgh, PA: SEI.


Sensagent Corporation. (N.D. ). definition - Computer Appliance. Retrieved from Sensagent Dictionary Web Site:


Shaw, M. (1994). Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status. . Pittsburgh, PA: SEI.

Shaw, M., & Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Disicpline. Upper Saddle River, NJ: Prentice-Hall.


Stahl, M. (2004). Patterns for Building Enterprise Solutions in .NET. ACM/IFIP/USENIX 5th Internation Middleware Conference. Toronto, Ontario.


Symantec Corp. Inc. (2015). Symantec Enterprise Products and Platforms Matrix. Retrieved October 23, 2015, from :


Tarantella-A-Technical Overview. (2001). Retrieved from Scribd: Overview

Taylor, R. N., Medvidovic, N., & Dashofy, E. N. (2010). Software Architecture Foundations, Theory, and Practice. Hoboken, NJ: Wiley & Sons, Inc.


Techotopia. (n.d.). Windows Server 2008 R2 Editions and System Requirements. Retrieved from Technotopia:


The 451: the Database Landscape. (2013, March ). Retrieved from whatsthebigdata:


United States Government Accountability Office. (2013). MAJOR AUTOMATED INFORMATION SYSTEMS Selected Defense Programs Need to Implement Key Acquisition Practices. Washington: United States Government Accountability Office. From


VMWARE Inc. (Copyright © 2009–2011). VMware vSphere Basics. Retrieved from


Woods, E. (2007, October 12). Top 10 Software Architecture Mistakes. Retrieved , , from InfoQ:



 [MS1]This text is inconsistent with the abstract on page v.

 [MS2]Please provide citation for the source of the figure.

 [MS3]Did you draw this figure. If not, please provide citation.