Multi-View Software Architecture Design: Case Study of a Mission-Critical Defense System

,


Introduction
The "software architecture" is defined as "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."by ANSI/IEEE Standard 1471-2000 -IEEE Recommended Practice for Architectural Description of Software Intensive Systems.There are other definitions such as "Software architecture is the level of system design that defines the overall structure of the software and the ways in which that structure provides conceptual integrity for the system."(Shaw & Garlan, 1995), and "A software architecture is a specification of the global organization of software involving components and connections between them.Components and connections are associated with attributes whose nature depends on the property of interest."(Fradet, Métayer, & Périn, 1999).The software architecture may be thought as the backbone of a software intensive system.According to Kruchten (1999), the software architecture helps us to (i) understand what the system does and how the system works, (ii) think and work in the pieces of the system, (iii) reuse the parts of the system to build other ones, and (iv) extend the system.Attention to software architecture is essential for successful product developments (Borrmann & Paulisch, 1999).Today, the importance of a well-designed software architecture for large-scale system developments is established (Borrmann & Paulisch, 1999).As the technology evolves, customers and users expect capable systems that can achieve multiple goals at the same time.In addition, they expect a certain level of quality in the system.Quality attributes such as reliability, scalability, maintainability can be enhanced with a well-crafted software architecture (Kheir, Oussalah, & Naja, 2013).For example, modifiability and extendibility are among the most important quality attributes in a software system.These qualities are necessary for increased system evolution capability.The architecture of a software system forms the basis for software evolution (Breivold, Crnkovic, & Larsson, 2012).Bass and John (2003) link usability, another quality attribute, to software architecture patterns.However, while a well-designed software architecture cannot guarantee quality in a system, an inadequate architecture design leads to bad quality (Taušan et al., 2014).As the systems increase in size and complexity, software architects face with many challenges (Taušan et al., 2014).For example, today, aerospace industry relies heavily on software technology.The size in terms of source lines of code (SLOC) has doubled every four years since mid-1990s (Feiler, Hansson, De Niz, & Wrage, 2009).Aerospace Vehicle Systems Institute (AVSI) launched an international, industry-wide initiative called System Architecture Virtual Integration (SAVI).The SAVI paradigm requires "an architecture-centric, multi-aspect model repository as the single source of truth" and "an architecture-centric acquisition process throughout the system life cycle that is supported" (Feiler et al., 2009).
While architectural design decisions enable the system to achieve certain goals, the same decisions may limit certain capabilities of the system.Therefore, architects are always faced with trade-offs.The decisions regarding the architectural design have significant impacts on the resulting system (Bosch & Molin, 1999).System software architects have to consider many issues and deal with conflicting concerns during system development (Hofmeister, Nord, & Soni, 2000).As the systems increase in scale, the process becomes time-consuming and expensive.Furthermore, as the software systems get complex, the architecture development becomes critical (Shaw & Garlan, 1995;Garlan, 2000).The modifications in the software architecture in the final phases of the development or after system delivery cost dearly.The architecture development process is a multi-aspect process and it needs to be rigorous.To address different aspects, software architects have to develop multiple architectures from different viewpoints (Mattsson, Lundell, Lings, & Fitzgerald, 2009).The need to address multiple sometimes conflicting concerns with a multi-view perspective in developing system software architectures is well-supported (Roshandel, Schmerl, Medvidovic, Garlan, & Zhang, 2003;Hofmeister, et al. 2007;Bessam & Kimour, 2009).
In this article, we present a multi-view software architecture development process with a case study of a mission-critical defense system.The development approach chosen is Siemens Four Views Model (Soni, Nord, & Hofmeister, 1995;Hofmeister et al., 2000).The system subject to the case study is a "Mine Neutralization System" (MNS) for mine warfare ships.Mission-critical defense systems are complex and safety-critical systems in general (Demir, 2005;Demir, 2009a).Analysis and design of these systems pose many challenges (Drusinsky, Shing, & Demir, 2005).Most of these challenges can be addressed with a well-designed software architecture.Such challenges and strategies to resolve them are presented with the associated architectural solutions throughout the development of the MNS example.In our mission-critical defense system case study, adaptability, modifiability, maintainability, usability, testability, reliability, and safety are the quality attributes that are specifically addressed.How to achieve these quality attributes are presented with specific architectural patterns and solutions.In addition, a new architectural style, called "star-controller architectural style", is introduced.An architectural style describes the structure of a pattern that can be applied to a family of systems.Architectural styles also explain the terminology of the components and connections along with a set of rules on how they can be combined (Garlan & Shaw, 1993).How the style is applied to the architecture development is provided as well.
The article is organized as follows.Section 2 provides the related literature on the subject.Section 3 introduces the system and presents the architecture development process along with the system architecture and design diagrams.Next section is the conclusion.Finally, experiences, lessons learned, and future work are explained in section 5.

Literature Review
Software architecture research domain is rapidly evolving as the systems increase in size and complexity (Aleti, Buhnova, Grunske, Koziolek, & Meedeniya, 2013).Two main lines of research streams are observed in the literature.The first line of research deals with issues related to the development of a software architecture for a single "stovepipe" system.The second line of research began when the systems started to evolve into systems of systems.Boehm (2006) states that one of the trends in software and systems engineering processes is increasingly complex systems of systems.Enterprise architecture frameworks are developed mainly in response to overcome the challenges of architecture development of system of systems.Note that, today, the line between a single system and a system of systems cannot be easily drawn.Various approaches for architecture development process have been developed both for systems (Hofmeister, et al. 2007) and enterprise systems (Urbaczewski & Mrdalj, 2006).Among the most commonly known frameworks are Zachman Framework (Zachman, 1987), The Open Group's TOGAF, United States Department of Defense Architecture Framework (DODAF), British Ministry of Defence Architecture Framework (MODAF), NATO Architecture Framework (NAF), Object Management Group's Unified Architecture Framework (UAF), United States Federal Enterprise Architecture Framework (FEAF).Overviews of these enterprise architecture frameworks are found in (Schekkerman, 2004;Reichwein, & Paredis, 2011;Urbaczewski & Mrdalj, 2006).Even frameworks for categorizing enterprise architecture frameworks such as (Franke et al., 2009) are being developed.A notable initiative is Generalized Enterprise Reference Architecture and Methodology (GERAM) developed by IFIP-IFAC Task Force (1999).
Various approaches, processes, techniques, best practices (Bosch, 2000;Gomaa, 2000;Dikel, Kane, & Wilson, 2001;Clements et al., 2002;Garland & Anthony, 2002;Bass, Clements, & Kazman, 2003;Hofmeister et al., 2007), and international standards (IEEE Standard 1471-2000; ISO/IEC/IEEE 42010-2011) are developed for system software architecture development process.Most of these software architecture development approaches are originated from the work conducted in the industry in response to the need for developing a systematic architecture development process.Different models propose development of different views (Mattsson et al., 2009).There are many commonalities and some differences between architecture development approaches (Hofmeister et al., 2005;Hofmeister et al., 2007).There are also some attempts such as (Hofmeister et al., 2005;Hofmeister et al., 2007) to develop a general model of software architecture design.Furthermore, studies to develop techniques and methods for quality assessment of software system architectures (Kazman et al., 2001;Firesmith et al., 2006) are also conducted.
In the rest of the section, we provide a short review of some predominant models for software architecture development.Most of these models are originated from the industrial practice.

Software Engineering Institute's (SEI) Attribute Driven Design (ADD) Method
The attribute driven design approach is developed by Software Engineering Institute (SEI) in Carnegie Mellon University.In the ADD method (Bachmann & Bass, 2001;Bass et al., 2003;Wojcik et al., 2006), the main focus is to ensure that the quality attribute requirements are met with the designed software architecture.It is a systematic recursive approach.During decomposition of modules, at each stage, the architect ensures that both functional and non-functional (quality) requirements are met with an architectural solution.The architectural solution may be an architectural pattern or style.ADD version 2.0 (Wokcik et al, 2006) was also developed.Software Engineering Institute maintains a website (SEI, 2015) on the subject.The ADD Version 2.0 steps are presented in Table 1.A practical example of applying attribute driven design version 2.0 is reported by Wood (2007).
Table 1.Software architecture design steps in the Attribute Driven Design (ADD) method (Wojcik et al., 2006)

Siemens Four Views Approach (S4V)
The S4V method is developed at Siemens Corporate Research.The four views (S4V) are conceptual view, module view, code view, and execution view.The conceptual view deals with the issues relating to the application domain.One of the most important questions answered with the conceptual view is how the system fulfills its requirements.How the functionality partitioned to the conceptual components is also explained with the conceptual view.The module view explains how the conceptual components are mapped to subsystems and modules.In this view, the conceptual solution is realized with today's software platforms and technologies.The execution view describes the runtime interactions of the software application.It also deals with how subsystems and modules are mapped to the hardware platforms.The code view deals with how runtime entities are mapped to the deployment components such as executables, libraries, etc.Each view acts an input for another view and helps the software architect to analyze trade-offs.The software architecture development has feedback loops with hardware architecture and source code development.Details regarding the architecture development process with S4V method can be found in (Soni et al., 1995;Hofmeister et al., 2000).The case study in this article follows the Siemens Four Views approach.

Rational Unified Process® (RUP®)'s "4+1" View Model of Software Architecture
Rational Unified Process (RUP) (Kruchten, 2003) is a software development process developed by Rational Software, later acquired by IBM.RUP adapts the "4+1" model of software architecture introduced by Kruchten (1995).The views in the "4+1" model are logical view, development view, process view, physical view, and scenarios.The logical view is towards the end user and describes the functionality of the system.The programmers are mainly interested in the development view and this view deals with software management related issues.The process view is of particular concern to integrators.Among other issues, it mainly deals with performance and scalability related issues.System engineers are mainly concerned with the physical view.Topology and communication related issues are handled with the development of physical views.According to Kruchten (1995), creating scenarios in the architecture development process help developers to put it all together.These multiple views are developed concurrently and there is a feedback loop in the development process.In Rational Unified Process, architecture design process is iterative.In every iteration, the architecture becomes more refined.Three main group of architectural design activities are (i) defining a candidate architecture, (ii) performing an architectural synthesis, and (iii) refining the architecture (Hofmeister et al., 2007).

Business, Architecture, Process, Organization / Customer, Application, Functional, Conceptual, Realization (BAPO/CAFCR)
Philips Research played an important role in the development of BAPO/CAFCR (America, Obbink, & Rommes, 2004;van der Linden, Bosch, Kamsteries, Kansala, & Obbink, 2004).This architecture development approach is mainly geared towards the development of a product family in a business processes context.It can be said that BAPO approach takes a holistic view in system software development.Therefore, in addition to the system architecture (A), special consideration is given to the business (B), process (P), and organizational (O) context.In this approach, there are five views.These are customer (C), application (A), functional (F), conceptual (C), and realization (R) views (CAFCR).Again, the architecture development is an iterative process similar to the other approaches.In every iteration, the architect develops necessary project artifacts and various quality attributes are analyzed in the context of business, process, and organization.

Architectural Separation of Concerns
The software architects are faced with the challenge of crafting an architecture that satisfies a set of requirements spanning across a number of concerns.The architectural separation of concerns approach recognizes this reality and bases the architecture development methodology on this reality.Nokia played a significant role in the development of architectural separation of concerns or ARES system of concepts (Ran, 2000).This methodology has an architecture-centered development approach.In this methodology, it is recognized that the system goals affect architectural decisions that is represented with architecture descriptions.The architecture descriptions should be consistent with the implementation.Naturally, as the result of the system development effort, the implementation aims at achieving the system goals.In the methodology, the implementation should be validated using the architecture description that is verified by architectural decisions.In every step, software artifacts and the process is evaluated.
In architectural separation of concerns approach, the stakeholder goals are analyzed and the goals that have impact on the architecture are refined into architecturally significant requirements (ASRs).These requirements are grouped under a set of concerns.During the development, how to address each concern and the effects on the architecture are investigated.Each concern is addressed via an architectural solution.In this approach, the development is viewed as a set of transformations that software artifacts turn into other software artifacts.During transformations, the evolution of the architecture is closely controlled, verified, and validated.

The Context of the Mission-Critical Defense System
Because of the technological improvements in electronics and software systems, Navies around the world undergo major revisions in their combatant ships.Instead of designing and building ships from the scratch, it is cheaper to upgrade the combat systems to increase the ship's combat capabilities.The Mine Neutralization System (MNS) is conceptualized and designed to adapt latest technologies in mine warfare without leading to major changes in a mine hunting ship's original structure.The objective of the MNS is to detect and eliminate sea mines.The system uses a detection sonar to detect an underwater threat, possibly a sea mine.The classification sonar helps the sonar operator to classify the threat type, which may be a magnetic or a moored mine.The operators of the system eliminate the mine threats using a remotely operated underwater vehicle (ROV).MNS controls all these main and auxiliary equipment including system consoles to achieve sea mine hunting missions for navy mine warfare ships.

Mine Neutralization System (MNS) High-Level and User-Level Goals
Requirements engineering is an important success factor in software projects (Hofmann & Lehner, 2001;Demir, 2008).Furthermore, half of the software development and information systems projects are challenged in requirements management (Demir, 2009b).Therefore, requirements engineering related activities are crucial.Requirements provides the main input for the software architecture development.The software architect takes the requirements and develops a software architecture that meets both functional and nonfunctional requirements.The decisions the software architect makes at this phase determine the boundaries for system quality attributes such as extensibility, modifiability, adaptability, reliability, safety, maintainability, testability, etc.
The high-level and user-level goals of the system were identified through a series of interviews with navy officers who are the major stakeholders for such systems.Also, the analysis of business opportunities and technological improvement projections for mine warfare systems guided the most important system requirements.
The interviews with navy officers revealed important improvement opportunities in existing mine hunting systems.For example, existing systems require multiple operators.In most navy ships, there are 3 watches.Each watch is 8 hours long.If a warfare system is operated by 3 crew members in a watch, then 9 crew members are needed to operate the system continuously.If the system is replaced with a one-man operated system, then there is a savings of 6 crew members.In a mine hunting ship, the number of personnel is limited and sometimes operators need to stay on watch for long hours, which poses a threat to the mission.MNS reduces the number of personnel to only one operator.This is one of the important achievements of the system.Another accomplishment of the system is that the system is highly adaptable to the technological advances in mine warfare.This requirement is derived from the business opportunities.
After the requirements analysis phase, the high-level goals (Table 2) and the user-levels goals (Table 3) of the system are identified.

Table 2. Mine Neutralization System (MNS) high-level goals Table 3. Mine Neutralization System (MNS) user-level goals
The requirements analysis phase of the system development lead to identification of certain distinguishing features of the proposed product as presented in Table 4.

Table 4. Mine Neutralization System (MNS) features
All these goals and resulting features provide the most important input for the system software architecture development.

Mine Neutralization System Main Components
Analysis of similar mine warfare systems reveals the necessary main components for the MNS.The system is composed of five main components: Detection and Classification Sonar Suite: The sonar suite is responsible for the detection and classification of mines.Two different sonars exist in this suite.The detection sonar is a long-range wide-spectrum sonar that is used to detect the presence of underwater objects.The classification sonar is used for further analysis of underwater objects suspected to be mine threats.This sonar creates a contact for the system.A bathythermograph and an echo sounder are auxiliary devices attached to the suite to provide necessary sea condition data.
Navigation Unit: This unit provides the precise location data for the ship.The navigation unit consists of a global positioning system (GPS) device and a gyro unit.Both of these devices provide the location data and one of the devices is sufficient for the operation.The gyro unit is a redundancy measure against the GPS failure.Therefore, the failure of one device doesn't compromise the mission.
Mine Neutralization System Console: This unit is the interface between the operator and the system.Mine Neutralization Vehicle (MNV): This unit handles the elimination of sea mines.It is a remotely operated underwater vehicle (ROV) and attached to the mother ship with an umbilical cable that carries the communication and power cables.The vehicle carries many devices to achieve the mission.Some of these devices are an echo sounder to determine the depth, a TV camera to monitor the underwater, a projector to provide light, an emergency pinger used to locate the vehicle if lost, an umbilical cable to provide electrical power and the necessary comunication with the mother ship, a gyro unit to determine location, and a mine neutralization vehicle control unit.
Mine Neutralization System Controller: This unit is the heart of the system.It provides communication between components.It also synchronizes the events during the mine hunting operation.
Figure 1 shows the main components and relations between the components for the system architecture.

Mine Neutralization System Use Cases
During the requirements gathering phase, we interviewed a navy officer responsible for mine hunting operations in navy mine hunting ships.The navy officer indicated 6 main functions expected from a mine neutralization system.These functions are detecting mines, classifying mines, control of mine neutralization vehicle (MNV), control of the TV camera subsystem integrated with the MNV, mine neutralization using a cable cutter or an explosive charge, and handling emergency operations.As a result, we identified 6 high-level use cases.Figure 2 shows these use cases.Naturally, further in the process, these high-level use cases are decomposed into low-level use cases.Note that there is only one operator handling all these use cases, since one of the important features of the system is being a one-man operated system.Figure 2. High-level use cases of mine neutralization system

Mine Neutralization System Software Architecture Design
Mission-critical defense system software development is an expensive and long effort.These types of systems tend to have long life-cycles and they evolve in time.Older versions are replaced with newer versions to keep up with advancing technology.A well-designed software system architecture prolongs the system life-cycle and reduce the maintenance effort.Therefore, the architecture design phase is one of the most important phases in a software engineering project (Bass et al., 2003).
System requirements are the main inputs for the software architecture design.In the previous phases, we developed the system requirements with a rigorous effort.Now, we move into the design of system software architecture with a multi-view perspective.In this study, we follow the Siemens Four View Architecture development approach.In this model, developing the views of the system software architecture starts with a global analysis.Note that we exclude the code and execution view.Since, the final views can only be achieved at the end of the development phase.

Global Analysis
The global analysis is the process of identifying factors influencing the architectural design.The goal of the global analysis is to develop strategies for each identified factor.The factors related to the development of MNS are listed in Table 5.During MNS development, strategies are laid out for each identified factor.It is important to cover each factor with at least one strategy.Table 6 shows the factors and corresponding strategies.For example, factor 2 enforces the system to be easily modifiable.Encapsulating the features into separate components is chosen as a strategy for this specific factor.In the MNS, the navigation unit handles all the navigation tasks and the unit is only connected to the system controller.If an upgrade becomes necessary in the navigation features, the navigation unit can easily be replaced with a newer version.Such modification doesn't effect other components in the system.This is also how one of the corresponding high-level user goals is achieved.The next step in the process is the development of the conceptual view of the system.The main components of the system, presented in figure 1, are used as inputs for the development of the conceptual view.

Conceptual View
In the global analysis, use of well-known patterns is chosen as a strategy to address some of the identified factors.For the conceptual view, we decided to use the pattern known as Model-View-Controller (MVC).The suggested context for this architectural pattern is interactive applications with a flexible human-computer interface (Buschmann, Meunier, Rohnert, Sommerlad, & Stal, 1996).The model-view-controller architectural pattern divides an interactive application into three components.Models contain the core functionality and data.Views display the information to the user.The controller binds the models and the views.A change-propagation mechanism through controller ensures consistency between the view and the model.Figure 3 shows the conceptual view and how the architectural pattern is applied to the MNS.The rationales for choosing the pattern are as follows: • The prospective customers are the Navies in the world.This necessitates compliance with existing user interface standards of the different Navies.Thus, the user interface of the system have to be decoupled and features such as multi-language support and different look and feels have to be provided.• Even if the model changes, the users will require the same information from the system.This pattern enables decoupling the model from the view.For example, an upgrade in the navigation unit will not effect the interface.The navigation unit is one of the components of the model and the mine neutralization system console, which is the interface to the user, is the view in the pattern.• The product is a mission-critical defense system and it is a real-time interactive application.Abstracting the controller enables us to focus on the synchronization of events in the system in a real-time environment.
• The system is an adaptable system enabling modifications when necessary in each component of the MVC pattern.• Easy addition/modification/removal of the view and model components will ease the maintenance of the product.• The architecture of the product will form a framework for future versions and similar products.Note that the product has a long life-cycle.
Choosing the model-view-controller pattern helped us to conceptualize an adaptable and maintainable system.This is how some important nonfunctional requirements can be achieved in the conceptual view.The main purpose of the module view is to simplify the system's implementation in software.It helps us to overcome the complexity of the system.In the module view, all the application functionality, control functionality, and meditation are mapped to subsystems, modules, and connections.
For the module view, we developed an architectural style named star-controller architecture.The style resembles to a star network topology in structure.The style benefits from the well-known design decomposition principle.
The system is carefully partitioned to subsystems, which are strictly loosely coupled with each other.In this architectural style, the system is divided into two types of components: controllers and subcomponents.The controllers handle the control functionality and the subcomponents handle the application functionality in the module view.
The architectural style follows two basic rules: 1.A controller can be connected to controllers and subcomponents.
2. Subcomponents can only be connected to controllers.
Figure 4 shows the star-controller architectural style.The style helps us to reduce the development effort for interfaces and similar subcomponents.It also enables the independent development of subcomponents or easy addition of existing subsystems enforced with one of the high-level goals.This architecture helps to achieve an adaptable and maintainable system.
In this architectural style, faults can easily be identified and localized to specific portions of the system.Subsystems are tested separately and integration testing is achieved as new subsystems are added to the system.The style follows "design for testing" principle in this perspective.
The star-controller architecture has a simple structure.Synchronization and the control flow of information are handled by controllers.The information is produced by subcomponents.The controllers' solemn task is to ensure reliable communication and synchronization, which are important considerations for real-time systems.In this architecture, high cohesion is achieved by partitioning the functionality cohesively into subcomponents.
The nonfunctional requirements of MNS require the system to be safe and reliable.Ease of testing and a simple design is essential for achieving safety and reliability.
The major drawback of the style is that the failure of one controller disables all the subcomponents attached to the controller.In the MNS, we overcome this problem by using redundancy in hardware.The MNS has a system self-checking mechanism built in its design.Every controller constantly monitors the attached subcomponents and another controller.Whenever a failure is detected in a subcomponent or in a controller, the system immediately switches to the redundant hardware.Another solution to this problem may be redundancy in software.A software module having the same functionality may be designed differently and installed to the redundant hardware.However, this is a costly solution.As a result, only hardware redundancy exists in the MNS.
Figure 5 shows how star-controller architecture is applied to the mine neutralization vehicle subsystem.Note that all classes have a status attribute used to store the status of the component.The system self-checking mechanism is accomplished via querying these status attributes.• Easy elimination of synchronization problems increases the system's reliability and safety.
• Application and control functions are separated.Therefore, modifications in the application functionality does not effect the control functionality.• Easy addition/removal of modules and functionality supports quality attributes such as adaptability and modifiability.• Easy localization of errors reduces the testing effort.
• Reduced fault propagation increases the system safety and reliability.A system may have multiple software architectures addressing different concerns.Because high reliability and safety are important concerns for MNS, an additional software architecture is used to address communication and synchronization issues.A layered architectural pattern is chosen.Layered architectures help to structure applications that can be decomposed into groups of subtasks.These subtasks are at a particular abstraction.In the MNS, the system is divided into two layers.The first layer, networking layer, handles the communication between modules as well as establishing the protocols and checking messages for errors.The networking layer corresponds to the physical and data link layer in open system interconnection (OSI) model (Zimmermann, 1980).The second layer is named as system layer and it is responsible for all other application-related communications in the system.Figure 6 shows the layered architecture of the MNS. Figure 6.The layered architecture of the MNS The next phase in the process is the development of code and execution views of the system.Development of these views require lengthy discussions impractical to fit into one article.Therefore, we only provide some of the high-level software design diagrams as part of the code view.The rest is left as future work.

Mine Neutralization System High-Level Software Design
The inputs from different views of MNS architecture are used in the high-level design of the system.It is important that the design follows the architectural design decisions.A smooth transition from one activity to another activity is achieved in the MNS development by ensuring that the architectural decisions are followed in every step.Figure 7 shows the derived domain model of the MNS.Note the structural similarity of the domain model and the star-controller architectural style introduced earlier.Figure 8 and 9 show some of the high-level design diagrams.

Validation of the Mine Neutralization System throughout the Development Process
In every step of the development, we put special emphasis on the validation of the system.Therefore, various system development artifacts such as a vision document, a system domain model, conceptual diagrams, detailed use cases, system sequence diagrams, statecharts, test cases, prototypes, user interface mock-ups are developed at different stages.During the development process, we consulted a navy officer who had experience in using similar systems in mine hunting operations.These system artifacts helped us in exchanging ideas and in system design validation with a user.For example, the operation of the mine neutralization vehicle control is modeled with a high-level statechart as shown in Figure 10.This and other types of artifacts were identified to be quite useful in system validation.The user-level goals of the MNS has two distinct goals related to the system user interface.The first user-level goal is to develop a system that can be operated with only one operator.This is a quite challenging goal considering the mine neutralization operation.It is also one of the distinguishing features of the system.The third goal is to have a simple user interface.When this goal translates into a system software requirement, it is quite vague.Since we recognize the challenges behind these goals, we used the model-view-controller architectural pattern.Our goal was to decouple the view of the system from the rest.As a result, we put special emphasis on the process of the system user interface design.At this stage, we employ rapid system prototyping techniques.Rapid prototyping of systems helps to identify requirements (Demir, 2009c).We developed various user interface mock-ups and turned these mock-ups into prototypes.During this process, it was important that our user interface designs are validated by experienced users.Therefore, we consulted a navy officer to help us in user interface design.The interviews and preliminary testing of various user interface designs with the navy officer provided significant insights and helped us to finalize our requirements.

Conclusions
In this article, we presented a case study of multi-view software architecture development.The case study is a mission-critical defense system.The development of defense systems is a long and expensive effort.These types of systems are generally complex safety-critical systems.Because of these properties, achieving high quality is vital.Only, a well-designed architecture lead the way to satisfy all the necessary quality (nonfunctional) requirements.
First, we identified the high-level and user-level goals through interviews with navy officers and analysis of existing similar systems.Analysis of existing systems revealed the necessary components for the mine neutralization system.Then, we conducted a global analysis to identify factors that influence our architectural design decisions.The strategies to resolve the factors are determined.The global analysis guided the development of the conceptual and module views of the system software architecture.The widely-known patterns are used and a new architectural style is developed to meet the specific properties imposed by the identified factors.Finally, we showed how the architecture formed the basis for the high-level system design.
We introduced the star-controller architectural style using the case study.This style has the advantage of (i) being simple and easily testable (ii) achieving low-coupling and high-cohesion in the software design (iii) having increased control over synchronization and communication necessary in real-time systems.The weakness of the style is that the failure of a controller also disables the subsystems attached to it.To overcome this weakness, hardware redundancies are used.
In the system software architecture, we used the model-view-controller architectural pattern and the star-controller architectural style to achieve usability, extensibility, adaptability, modifiability, testability, maintainability, safety, and reliability.The layered architecture is used to increase maintainability, safety, and reliability.

Experiences, Lessons Learned, and Future Work
During the architecture development, it was clear that one architectural pattern would not be enough to satisfy all the nonfunctional requirements.The requirements forced us to use multiple software architectures for different nonfunctional requirement sets.Some of the lessons learned are as follows: • Paying special attention to the requirements gathering phase is a good promise of a successful software architecture development.The views of the navy officers on the system proved to be very critical at this phase.
• Partitioning the tasks into different architectural views, each addressing separate concerns, is found to be useful in meeting both functional and nonfunctional requirements.• A well-documented conceptual view ensures that the problem at hand is understood by all the stakeholders.
Communication among developers is improved this way and misunderstandings are reduced if not eliminated completely.• Conceptual view was used as a primary input for the module view.
• Development of various system software artifacts especially using Unified Modeling Language (UML) enabled easy exchange of ideas and creation of constructive feedback loops.Visual diagrams such as the domain model, the use case model, system sequence diagrams, and statecharts are found to be significantly helpful in system design.• Early prototyping of user interfaces are found to be effective in requirements elicitation.Architecture description languages (ADLs) have been the focus of software architecture community for some time (Medvidovic & Taylor, 2000).There are various languages to specify the software architecture designs formally, for example Armani (Monroe, 1998).It is possible to analyze software architectures with ADLs.As a future work, we would like to analyze the star-controller architectural style with ADLs and get an in depth understanding of the style.

Figure 1 .
Figure 1.Mine Neutralization System main components

Figure
Figure 3. Conceptual view

Figure 4 .
Figure 4.The star-controller architectural style

Figure 5 .
Figure 5.The mine neutralization vehicle subsystems

Figure 7 .
Figure 7.The domain model of the Mine Neutralization System

Figure 10 .
Figure 10.High-level statechart of Mine Neutralization Vehicle control operation

Table 5 .
Factors influencing architectural design

Table 6 .
Factors and corresponding strategies