CSCI 5010- Software EngineeringProject 3

Yuguang Qiu Student ID # 103087490

METOC (Mission Essential Meteorological and Oceanographic Center) Anchor Desk Systems

Software Architecture Views and Documentation

1. Introduction

METOC facilities, reach back centers, and on-scene METOC personnel interpret, fuse, and eval-uate collected data and information to develop forecasts and recommendations in support of op-erational requirements and decisions. Needless to say, Software Architecture Documentation is critical to this system because it tells users the attributes of the architecture design, also provid-ing a better way for the user to understand it correctly. Without a good technical software docu-mentation, all project efforts includes even the best architecture design, engineering resources, time, system analysis and evaluation will have been ruined and abused. In addition, Architecture Documentation also provide the main communication tunnel for non-technical people, such as stakeholders, operation teams in and other related people in an IT company. People without tech-nical background can easily understand what is going on based on the Software Architecture Documents. It is known that documentation is also the fundamental of system design and analy-sis. Indeed, software architecture documentation can be summarized as a matter of documenting the relevant views and adding other documentations that apply to more than one view.

Views play a significant role and is regarded as the principle of architecture documentation, they are critical to Software Architecture Documentation for several reasons. First of all, it allow people to divide a giant and complicated software architecture system into small pieces, for example, manageable and organized sub-systems or components. Therefore, good views definitely improve the efficiency and accuracy of the whole system.

From a technical and system structure aspect, this project identify the Software Architecture views based on my previous Quality Attributes and ASR statements for the Meteorological (METOC) Anchor Desk Systems. It is unlikely that such system’s Software Architecture can be totally addressed with only one view. Therefore, I will present four general views of the system from different angles in section two.

First of all, this paper will explore the Module view and its related set of software unit responsibility. Afterward, it will talk about the Component & Connector Module View, Components are principal units of runtime interaction and data stores while Connectors are interaction mechanisms. Besides, we know that Allocation view is important for allocating environment elements to software elements, thus such topic will be covered as well. This paper also talk about the Quality Attribute views based on my second project paper. Meanwhile. Finally, I generate a Software Architecture Document Template for future work in section 3.

2. Views

2.1 Overview

Above all, views represent the system structure and can lead to a big diversity since different views may support different design goals and use cases. Generally speaking, Software Architec-ture is an integrated concept and a whole picture, thus either a particular view or big collections of views would make the system better.

The main purpose of Documenting views is to manage complexity by separating concerns into smaller sections. On the other hand, every coin has two sides and each view have both costs and benefits. A good view should balance the whole system structure quality and performance.

A view usually consists of five sections, Primary Presentation, Element Catalog, Context Dia-gram, variability guide and Rationale. The first section is the primary content and these remain-ing ones are supporting documents.

According to the design of METOC Anchor Desk System, requests for support can occur in ei-ther of two forms: Person – Person, Which usually includes three different types, either in per-son, by telephone, by video conference or by other collaborative planning.

Figure.1. Template for a view

2.2 Scenario View (Enterprise View)

The METOC Anchor Desk System is used by the U.S military services for crisis situations, such as military and civilian crises. A practical application of METOC Anchor Desk System can be used as a weather browser, which overlays environmental condition (e.g., real time temperature, atmospheric pressure, cloud cover, sea conditions, ice thickness) on a map and can, under user-

control, show how those weather conditions affect military operations, civilian operations (e.g., missiles launch and natural disaster relief).

2.3 Modulation Views (Information View)

Modulation views Show how the system is structured and how the elements of the software are mapped into modules and subsystems.  It also shows how the system will be partitioned into sep-arate run-time components.

In this project, I analyze the module views from four perspective: Decomposition view, Uses View, Layered View and Generalization View to address these following questions:

1. How is the product mapped to the software platform?

Software platform of the METOC Anchor Desk System involves Software components and code implementation.

The code that was written for the system included Web authoring code which uses scripts to gen-erate, high-level auto running scripts, adaptation code that can be used to modify components to fit its purposes, and conventional software which provided weather objects to other servers. In addition, since these code need to work on a variety of different operating systems and comput-ers, it should be compatible and capable of migration.

From the system architecture perspective, The METOC architecture suggests a loose connection between the conductors. In fact, this architecture is more like a client-server one whereas clients are not “slaves” and manipulated by servers. In simple word, there are more insulation and flexi-bility between the client and server. In Figure 2, Director and Choreographer objects work as clients and all other objects running as servers are on the bottom. Clients are servers are con-nected through a bridge - Object Request Broker, which is the substrate or mechanism used for interfacing the client and server.

Figure.2. METOC Anchor Desk System architecture

2. What system support and services does it use?

Speaking of the system support devices, there are three kinds of machines in the user environ-ment: UNIX workstations, Macintoshes, and PCs. Based on the current design, the architecture can accommodate this mix of computing equipment. Furthermore, according to my Architec-turally Significant Requirements (ASRs) statement, mobile equipment, data base center are dom-inating the system platform now days, this system has to capable of working perfectly on these devices to suit these requirements.

The services listed in the design table include storage and retrieval of the raw environmental data, data gathering, data analysis, data visualization, and mapping. It is part of the system archi-tecture design and well-organized.

3. How can testing be supported?

Analysis and system test products provide coherent, integrated depictions of the past and current state of the natural environment over specific regions. Analysis transforms raw environmental data into useful METOC information and enables production of accurate forecasts of the envi-ronment. It enables identification of significant METOC features and conditions.

4. How can dependencies between modules be minimized?

The METOC Anchor Desk System is a globally decentralized system consists of many distrib-uted systems. Each distributed system have the capability to run independently, which means even another inter-connected system crash unexpectedly, the whole system will NOT be out of order and still available and functional. In this case, modules are running relatively independent, thus dependencies are minimized.

2.4 Evolutionary Design Views (Function View)

One major function of the METOC Anchor Desk System is the Evolutionary architecture of sys-tem development, which represents a fine grained feedback from the system to the developing organization.

Evolutionary system support is the key to success in military and crisis operations. Obviously, user requirements of these operations keep changing from time to time, it’s mandatory to design architectures that be created through assembly of tailorable large-grained hardware and software components According to this paper, the METOC Anchor Desk System architectures should be based on Assembly and Integration by providing an architectural infrastructure to separate object technology and client server based architectures.

2.5 C&C views (Physical View)

C&C views show how the system is structured as a set of elements with runtime behaviors and interactions.

Components contains Principal processing units and data stores. A component has a set of ports through which it interacts with other components. Connectors have a set of interfaces that indi-cate how components may use a connector in interactions to communicate with each other. Basi-cally, C&C is used for reasoning about runtime system quality attributes such as performance, security, and reliability while showing people how the system works. Figure 3 shows C&C view of the METOC architecture.

Components in UML could represent logical components and physical components, along with the artifacts that implement them and the nodes on which they are deployed and executed. It is anticipated that profiles based around components will be developed for specific component technologies and associated hardware and software environments.

Figure.3. METOC Anchor Desk System C&C view

This C&C module view represents a typical implementation that one might find in C under UNIX. A main module is used to start things off, invoking the facilities of four modules：To-up-per, To-lower, Split, and Merge that do the main work.

Components:

Components in UML consists of Logical components and Physical components.

Basically, Logical components includes customer EJB, User Service, Weather Service, Authenti-cation and inventory. Weather Service is the main component in the METOC Anchor Desk Sys-tem, it should be an internal structure located at sub-system (Weather data). User Service is not equal to the customer service. In this case, this component provides interfaces between weather service and inventory (Database). Customer component is an independent subsystem.

Figure.4. METOC Anchor Desk System C&C components

In my opinion, the METOC Anchor Desk System should have been focused on physical / hard-ware components as following： Computers—UNIX workstations and PCs, including laptops Networks Video-conferencing software Emulators Web browsers Collaboration software Utility software Message software Data base Mobile devices and Tablets

Processing units included workstations and personal computers. Both categories are in wide-spread use in the METOC community and are accommodated in the system architecture. How-ever, Mobile devices and Tablets MUST be supported by the system due to new ASR and QA re-quirement. Based on my previous projects, The METOC Anchor Desk System also requires two new components: Database and Message software.

Database is used to store critical data and big data, thus the system should have a large-scale in -quiry Database that contains previous or analyzed and refined data. We know that raw data can make it difficult and low efficient for decision makers to respond to real-time situations. Thus we need an “erudite” system (Database) to help decision makers. This is not an innovative approach, in the world of Computer Networking, cookies (Web Browser cache) and proxy server use Data-base to reduce the network traffic via providing data that frequently requested by users. Simi-larly, the METOC’s Anchor Desk System should “learn” from all cases it dealt with, then build-ing its own large scale Database to provide quick response in future actions. Simultaneously, such data ought to be complex in structure and well maintained to prevent data leakage. Ideally, this requires a professional team to create a confidential data encryption algorithm that differ from current International Data Encryption Algorithms (IDEA). Besides, the system must have disaster recovery data centers, high performance load balance systems and backup systems. These would ensure that these data are fully protected.

Message software is used to improve the communication within the structure between the Crisis Planning Team and Crisis Action Team. According to the current design of the METOC Anchor Desk System, requests for support can occur in either of two forms: Person – Person, Which usu-

ally includes three different types, either in person, by telephone, by video conference or by other collaborative planning tools. However, there is no way to leave a message to the other team. Messages could come up with something sweetly concise or indicate the problem in detail. Therefore, it should be a component in the system.

Connectors:

In the world of UML, Logical Connector specifies a link that enables communication between two or more components. Connectors could be either delegation connector, or assembly con-nector.

A delegation connector is used to model the decomposition of behavior, where services provided by a component may be realized. In a word, a delegation connector represents the forwarding of events. In this case, it links the external contract of a component to the realization – from the cus-tomer component to the weather component. An assembly connector is a connector between two or more parts or ports on parts that defines that one or more parts provide the services that other parts use.

In contexts where components are used to extend a system by offering existing ser-vices, but also adding new functionality, connectors can be used to link in the new component definition. Figure shows an example that I-customers connector linking two components.

Figure.5. Assembly connector between ports of Authentication and Customers components

2.6 Telecommunication view

The METOC Anchor Desk System physical connector is based on network, which has a four-tiered structure as showed in Figure 6. The weather center has a 10-Mbit/second “high- band-width” local area network (LAN). Operations center and wide area networks are connected by a fiber-optic bridge that also with a 10-Mbit/second bandwidth.

Obviously, such low bandwidth/speed LAN and fiber optic bridge technologies have been out-dated for more than 10 years. Based on my project two statement, the METOC Anchor Desk System need to upgrade its hardware and network design to suit current requirements. Although weather data is not very big whereas such a low bandwidth network is even slower than normal

residence network. In addition, the system should also introduce some new techniques such as Wireless LAN, Bluetooth and IP set top box.

Figure.6. METOC Anchor Desk System Network Connector Architecture

2.7 Allocation views (Engineering View)

Allocation views show how the system relates to non-software structures in its environment. It describes the allocation of functional objects to engineered physical and computational compo-nents within the system. Allocation view focuses on how the different software units are allo-cated to resources like the hardware, file systems, and people.

In this project, the METOC Anchor Desk System allocation view should address the following concerns and specifies the relationship between software elements and elements of the environ-ments in which the software system is executed. They expose structural properties like which processes run on which processor, and how the system files are organized on a file system.

1. Reasoning about performance, availability, security, and safety

Designers must make sure the system, subsystem or equipment is in the proportion of time in a functioning condition. The system and its system must be available all the time. Moreover, avail-ability of a system is typically measured as a factor of its reliability - as reliability increases, so does availability. It is quite straightforward that the more reliable the system is, the more avail-able it is.

Availability of a system should also be increased by the strategy of focusing on increasing testability and maintainability and not on reliability. Improving maintainability is generally easier than reliability due to its uncertain facts. Besides, because the uncertainties in the reliability estimates are in most cases very large, it is likely to dominate the availability problem, even while maintainability levels are very high. Therefore, we need to

From the tradition of hazard analysis and system safety engineering perspective, the METOC Anchor Desk System should be safe and unbreakable in most cases. For example, system main

hardware, for instance, servers, switches, routers, CPEs and other devices should be physically located in a safe place and unreachable to unauthorized users. Data Base of the system should be fully protected and have backup methodologies.

The METOC Anchor Desk System MUST prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of critical information. According to the current design, requests for support can occur in different forms - either in person, by telephone, by video conference or by other collaborative planning tools (GPS phone, remote access point, VPN technologies). Needless to say, apparent limitations and potential security concerns are notice-able based on this design. For example, it’s very easy to hack a phone or video conference call via using modern technologies. As is known to all, confidential Phone Call for crucial informa-tion exchange is usually based on circuit switches, which implementing a telecommunications network in which two network nodes establish a dedicated communications channel (circuit) through the network before the nodes may communicate. This methodology guarantees a full bandwidth and good quality of phone call, however, since the routing path between circuits and clients are physically fixed (nodes are physically connected); also difficult to change, hackers can break into either the network edge or core to capture frames for analysis its content.

Security concern also applies to video conference call. The METOC system applications are aimed to respond to emergent situations, such as making a decision of launching the BGM-109 Cruise missile to battlefield, according to METOC’s design, the most efficient way is: Crisis action team will have to video call the Crisis planning team through the METOC’s Anchor Desk System. Both teams need to exchange real time information like Local Observation (Enemy actions), Climatology information (battle field visibility), and Forecasting information (Electromagnetic Interference) before making the final decision of the launch time. During this period, strong/ advanced enemies have plenty of time to either crash/interrupt the call, or capture/steal useful information to destroy the whole mission.

According to the paper, The METOC system is based on the World Wide Web (WWW), either through the use of forms or routine access to environmental product Web pages. Actually, this approach is even worse, there are many types of network attacks can break this form, for in-stance, dynamic denial of service (DDoS), IP flooding, ID fraud, and SYNC flood. All of these traditional but effective types of attack can crash the Web server, thus leading to unavailability of the METOC system. In addition, advanced packet capture and port detection tools can make a network-based communication transparent to the world. Imagine that exposing an International drug enforcement mission details (Location, military deployment, &.etc.) to drug criminals may lead to a total mission failure. Keep in mind- This is not an extreme example but general.

2. Reasoning about distributed development

The METOC Anchor Desk System is a globally decentralized system consists of many distrib-uted systems. In general speaking, system dependability is a measure of a system's availability, reliability, and its maintainability.  Each distributed system should have the capability to run in-dependently, which means even another inter-connected system crash unexpectedly, the whole system will NOT be out of order and still available and functional.

3. Reasoning about concurrent access to software versions

Generally speaking, computer Compatibility involves two different aspects: hardware compatibility and software compatibility. Software compatibility refer to the Compatibility that a particular software has running on an Operating System. For example, some specific applications & video games can only run on Windows OS whereas MAC OS do not support. In this case, I don’t suggest the METOC Anchor Desk System to have a corresponding OS Compatibility due to security concerns, especially for the Linux OS because it is an open source OS, thus the security mechanism contains many potential and known flaws/ drawbacks. In simple words, such system that used by either military organizations or government institutions should be based on a unified, inter-communicated, confidentially designed OS.

From the hardware Compatibility perspective, some applications can only run on the particular CPU architecture - hardware that was designed for one operating system may not work for another, if device or kernel drivers are unavailable. For example, much of the hardware for Mac OS X is proprietary hardware with drivers unavailable for use in operating systems such as Linux. In this case, the METOC Anchor Desk System should have a great hardware Compatibility for future system upgrades and migrations.

4. Reasoning about the form and mechanisms of system installation

The system should be capable of indicating what customers will need to do to install and set up the new software successfully. The testing process may involve full, partial or upgrades install/uninstall processes. A system with good install ability must support different kinds of installation approaches, especially in distributed and parallel systems. In addition, with the fast development of cloud computing, Big Data and large scale Data Base, Install ability must cover installation requirements for these systems.

2.8 Quality Attributes views (Technology View)

A quality attribute view can be tailored for specific stakeholders or to address specific concerns. A quality views is formed by extracting the relevant pieces of structural views and packaging them together.

In this case,

Reliability View

- The METOC Anchor Desk System must NOT crash during working time, which means it need to maintain a high- level performance under demanding and extreme conditions across a long period of time.

- The METOC Anchor Desk System MUST have advanced disaster recovery and backup methodologies.

- Design a realistic and affordable test program that provides empirical evidence that the system meets its reliability requirements. For example, design a test with explicit criteria for the number of hours and number of failures until the requirement is met or failed.

- The METOC Anchor Desk System must run on a very reliable platform to ensure its output.

Serviceability View

- The METOC Anchor Desk System must provide different kinds of services and applications to users.

- Serviceability refers to the ability of technical personnel to install, configure, and monitor the system, then identify exceptions or faults, debug or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit of solving a problem and restoring the product into service.

- The METOC Anchor Desk System requires a good support engineering team not only significantly enhance the system quality, efficiency, also facilitate users to maximize the system performance while reduce the maintenance costs.

- Support team consists of technical support engineers, field application engineers and production manager.

Usability View

- Usability is associated with the functionalities of the system.

- For the METOC Anchor Desk System, a core network entity lacking powerful processors for data processing could be considered unusable according to the system design and use case.

- From the software aspect, a routing algorithm which introduces extra latency and huge header processing time could be considered as unusable.

Maintainability & scalability View

- The METOC Anchor Desk System and network should be able to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth.

- The METOC system should be easily maintained with low costs.

- With the fast development of big data and cloud computing, crisis involves complex situations and fast- reaction have become very tricky and difficult to handle.

- Core value as of an evolutionary system

- Limited capability of upgrading and extension.

Accuracy View

- Data must be accurate or the METOC Anchor Desk System may lead to a disaster.

- The METOC Anchor Desk System requires data accuracy even more than other systems.

3. Template

1. Introduction[The introduction of the Software Architecture Document provides an overview of the entire Software Ar-chitecture Document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Software Architecture Document.]

1.1 Scope and Overview[A brief description of what the Software Architecture Document applies to; what is affected or influenced by this document. This section contains and explains how the Software Architecture Document is orga-nized. This subsection also describes what the rest of the Software Architecture Document]

1.2 Definitions, Acronyms, and Abbreviations[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly in -terpret the Software Architecture Document.]

1.3 References[This subsection provides a complete list of all documents referenced elsewhere in the Software Architec-ture Document. Identify each document by title, report number (if applicable), date, and publishing orga-nization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

2. Advanced Architectural Requirement [This section describes what software architecture is for the current system, and how it is represented. Of the Use-Case, Logical, Process, Deployment, and Implementation Views, it enumerates the views that are necessary, and for each view, explains what types of model elements it contains.]

3. Architectural Goals and Constraints [This section describes the software requirements and objectives that have some significant impact on the architecture; for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution, and reuse. It also captures the special constraints that may apply: design and implementation strategy, de-velopment tools, team structure, schedule, legacy code, and so on.]

4. Use-Case View [This section lists use cases or scenarios from the use-case model if they represent some significant, cen -tral functionality of the final system, or if they have a large architectural coverage—they exercise many ar-chitectural elements or if they stress or illustrate a specific, delicate point of the architecture.]

4.1 Use-Case Realizations[This section illustrates how the software actually works by giving a few selected use-case (or scenario) re -alizations, and explains how the various design model elements contribute to their functionality.]

5. Views [This section describes the architecturally significant parts of the design model, such as its decomposition into subsystems and packages. And for each significant package, its decomposition into classes and class utilities. You should introduce architecturally significant classes and describe their responsibilities, as well as a few very important relationships, operations, and attributes.]

5.1 Scenarios View [This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers.]

5.2 Architecturally Modulation View[For each significant package, include a subsection with its name, its brief description, and a diagram with all significant classes and packages contained within the package.

For each significant class in the package, include its name, brief description, and, optionally, a description of some of its major responsibilities, operations, and attributes.]

5.3 C&C View [This section describes the system's decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organize the section by groups of pro-cesses that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous.]

5.4 Allocation View [This section describes one or more physical network (hardware) configurations on which the software is deployed and run. It is a view of the Deployment Model. At a minimum for each configuration it should in-dicate the physical nodes (computers, CPUs) that execute the software and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the physical nodes.]

6. Size and Performance [A description of the major dimensioning characteristics of the software that impact the architecture, as well as the target performance constraints.]

7. Quality Attribute View [A description of how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics have special signifi-cance, such as safety, security or privacy implications, they must be clearly delineated.]