Title of Document



Carnegie Mellon University CMU-MSIT-SE-SAD1.0

School of Computer Science Fall 2003

Master of Software Engineering

MSIT-SE Practicum

Software Architecture Description (SAD)

Version 0.4

Railroad Configuration Rule Checker

October 16, 2003

Yong Hoon Choi

Revision History

|Date |Revision |Description |Author |

|10/13/2003 |0.1 |Documentation Creation |Yong Hoon Choi |

|10/14/2003 |0.2 |Background & Utility Tree |Yong Hoon Choi |

|10/15/2003 |0.3 |Baseline Architecture |Yong Hoon Choi |

|10/16/2003 |0.4 |Alternative Architecture |Yong Hoon Choi |

|10/23/2003 |1.0 |Future Extension |Yong Hoon Choi |

Table of Contents

1 Acronyms 4

2 Introduction 4

3 Project Description 4

3.1 Background 4

3.2 Client 4

3.3 Objective 5

3.4 Major Functional Requirements 5

3.5 Driving Architectural Requirements 5

3.6 Potential Extensions 5

4 Utility Tree 6

5 Overall Architecture 7

5.1 Executable Software Components 8

5.1.1 Tabling File Reader 8

5.1.2 Rule File Reader 8

5.1.3 Rule Checking Engine 8

5.1.4 Display 10

5.1.5 Log Recorder 10

6 Architectural Alternatives 11

6.1 Overall Architecture: Batch-Sequential Style 11

6.2 Rule Checking Engine Component: Blackboard Style 12

7 Future Extension 14

7.1 Background 14

7.2 Description of Architectures for Future Extension 14

7.2.1 Architectural Changes for IDE (Integrated Development Environment) 14

7.2.2 Architectural Changes for Distributed System 16

Acronyms

|ATAM |Architecture Tradeoff Analysis MethodSM |

|RC2 |Railroad Configuration Rule Checker |

|GUI |Graphic User Interface |

|IDE |Integrated Development Environment |

|EOF |End of File |

|MSE |Master of Software Engineering |

|MSIT-SE |Master Science in Information Technology – Software Engineering |

|SAT |Satisfiability Problem |

|ADL |Architectural Description Language |

|I/O |Input/Output |

Introduction

This document is intended to illustrate an overview of the project, elicited requirements, a utility tree, architectural descriptions, and analysis for the Railroad Configuration Rule Checker (RC2) system. Also, it will propose future extensions for this system.

Project Description

1 Background

Infrastructure components of a railroad consist of various types of devices that are used to facilitate the movement of trains, and the configuration of a railroad is very dynamic, i.e., the layout and positioning of the devise is constantly changing. This required the CAD software to be designed so that the configuration changes could be imported without having to make changes to the logic whenever a component was updated. The procedural method for updating the configuration is for a technician to manually edit the tabling files, making changes to the component parameters based on information supplied from the railroad. There are possibly a variety of different rules that the technician must understand and adhere to in order to deliver tabling that is free of defects. A violated rule, however, will still allow the software to be compiled and linked without error as long as the macro is syntactically correct, so the build process allows no ability to detect tabling defects. The railroad configuration rule checker would examine the updated tabling file in order to ensure that the tabling updates comply with all the rules, and to inform the user when an error is detected.

2 Client

Union Switch & Signal, Inc.

3 Objective

The ultimate goal of the RC2 project is to develop a reliable railroad configuration rule checker system whose inputs are the railroad configuration information and its rules. The current goal is to provide this service in a form of command-line/text-based application. Future and growth goals are discussed at length in this document.

4 Major Functional Requirements

The RC2 system shall:

• Perform the syntactical checking in the tabling file, which contains the updated railroad configuration information, and the rule file, which includes the configuration rules to be preserved in the tabling file.

• Display the syntax checking result on the screen

• Record the syntax checking log in the log file

• Perform the semantic checking with configuration rules in the updated tabling file

• Display the semantic checking result, which includes the violated rules and the relevant VAX macros on the screen

• Record the semantic checking log in the log file

• Display the checking progress on the screen

5 Driving Architectural Requirements

• Reliability

Since the system itself is a verifier, it should be reliable. For the purpose, the formal methods for describing the configuration rules are highly expected.

• Usability

Simple and intuitive interaction between the user and the device with a fast learning curve are required because this system is a supporting tool for facilitating the current railroad configuration update process which is human-intensive.

• Extensibility

The potential extensions such as GUI (graphic user interface) and IDE (Integrated Development Environment) would be easily added to the system

• Performance

Although there is no strong requirement of the client for the execution time, the worst case execution time is expected to be bounded in 1000 seconds.

6 Potential Extensions

• Rule checker with GUI (Graphic User Interface) that enables display the violated rules pointing to the relevant VAX macros on the source of the tabling file

• Rule checker with IDE (Integrated Development Environment) that enables editing the input files, checking them, and display the checking result on the one site

• Remote railroad configuration rule checker

Utility Tree

The utility tree has been developed to translate the business drivers of a system into concrete quality attribute scenarios. The architectural decision will be made based on the utility tree. The utility tree for the RC2 system is shown in Figure 7.

Overall Architecture

The system will read the tabling file and the configuration rule file and provide the checking result. The Tabling File Reader component will open the tabling file, read/pass the configuration information from it to the Rule Checking Engine component. Then, the Rule File Reader component will also open the rule file and read/pass configuration rules one-by-one to the Rule Checking Engine component. The Rule Checking Engine will get the configuration/rule information and examine the correctness of the tabling file. The checking result will be immediately delivered to the Display/Log Recorder components for screen/file reports respectively.

From the top level, the system is composed of five components: the Tabling File Reader, the Rule File Reader, the Rule Checking Engine, the Display, and the Log Recorder components. Below (Figure 2) is the architectural diagram of the RC2 system generated by Acme Studio.

The overall architecture follows the dataflow systems style, dominated by motion of data through the system with no upstream content control. In the RC2 system, data flows from the Tabling File Reader and the Rule File Reader, to the Rule Checking Engine, and then to the Display and Log Recorder components. The Tabling File and the Rule File are data sources while the Log file is a data sink.

The system has characteristics of a pipe-and-filter architecture by the following reasons:

1) Each filter performs data transformation. For instance, the Rule File Reader changes text file to logical data, the Rule Checking Engine change logical data to text, and the Display/Log Recorder transform text to screen image/text file, respectively.

2) The filters in the system are independent from each other, and they do not share states.

3) Individual components do not know the identity of the other components connected to it.

4) Each filter processes its data incrementally. For instance, the Rule File Reader read a rule

However, the system deviates from a pure pipe-and-filter architecture by the following reasons:

1) The data flows through components following a specific sequence as mentioned previously. For instance, the Rule Checking Engine component requires the Tabling File Reader component as its precedence.

2) A part of the overall architecture, denoted by the ( area in Figure 2, is completely a batch sequential architecture. Each component takes the whole input and process it so that there is no incremental process as in the pipe-and-filter architecture. The Tabling File Reader will read the whole tabling information from the Tabling File and process it. Before completing its process, the Tabling File Reader component will never pass the result into the Rule Checking Engine.

1 Executable Software Components

I propose five components to handle the major functionality of the system. In this section we will discuss the high level function of each of these components in terms of input, output, and methods involved.

1 Tabling File Reader

The Tabling File Reader component accepts the updated railroad configuration information as its input through a text file system. This component is characterized by a batch process so that it will never produce any output before the completion of the processing of all inputs. This component is tasked with opening/closing the tabling file. Another task is to analyze lexical elements and syntactical structures in the tabling file. Through this task, syntax errors would be detected if they exist. If the syntax analysis is finished successfully, the Tabling File Reader component will produce a set of objects, each of which represents a VAX macro command, i.e., a configuration component such as switch, control point, and signal. Otherwise, it will output syntax error information.

2 Rule File Reader

The Rule File Reader component gets the configuration rule information as its input through a text file system. The component will open/close the rule file, and perform a syntactical analysis of the rule file. If any syntax error is detected, it will provide a syntax error report. Otherwise, not like the Tabling File Reader component, it will output rule information one by one since it follows the pipe-and-filter architectural style.

3 Rule Checking Engine

The Rule Checking Engine component has two inputs, which are railroad configuration and rule information. Once the component gets the configuration information from the Tabling File Reader component, it will accept only rule information one by one from the Rule File Reader component. Then, it will check if each input rule is satisfied in the tabling file information. During the checking process, there will be no change in the tabling file information. After completing the verification, it will outputs the checking result for screen display and log file.

If there is any syntax error passed by the Tabling File Reader and/or the Rule File Reader component, the Rule Checking Engine component will not perform any semantic checking and just deliver the syntax error messages from the previous components to the next components.

1 Low-Level Architecture of Rule Checking Engine

The Rule Checking Engine component is more complex since it has more functionalities than others and its functionalities are more important. The system inside the Rule Checking Engine component has three components: the Configuration Information, the Rule Repository, the Rule Dispatcher components as shown in Figure 3.

This sub-system of the Rule Checking Engine component can be viewed as the tier architecture for the following reasons:

1) Tiers are organized hierarchically, each tier providing service to the tier below it and serving as a client the tier above. For instance, the Configuration Information component serves appropriate configuration information for a specific configuration rule to the Rule Repository. The Rule Repository component will provide an actual body of the rule requested by the Rule Dispatcher component.

2) All tiers except the adjacent tiers are hidden. There is no inter-component communication between non-adjacent components. The Rule Dispatcher communicates only with the Rule Repository.

3) Each tier can be independently distributed in different machines. There is no shared information between any two components except communication via the connector (method invocation). Therefore, it is possible to place each tier independently in a different physical machine.

Each component will contain its own functionality as follows:

Configuration Information

This component accepts the configuration information, which are actually a set of all objects represented in the tabling file. It will provide the configuration information relevant to a specific rule requested by the Rule Repository component.

Rule Repository

This component accepts rule information from the Rule Dispatcher component. It realizes the actual body of the configuration rules.

Rule Dispatcher

This component accepts rule information from the Rule File Reader. Then, it identifies the rule and requests a semantic checking with it to the Rule Repository component. When it gets the checking result of the rule, it will send the same textual form of the result into the Display component for screen display and the Log Recorder component for log file.

5 Display

The Display component receives the checking result in a string format. Then, it will immediately display the result in a user-friendly form on the screen. Under the assumption that file access is a slower I/O operation than screen display, the Display component will not affect the termination of the whole system.

6 Log Recorder

The Log Recorder component will open a file for logging the checking result and receive the checking result in a string format. It will write textual representations of the checking result onto the log file. When it gets an EOF (end-of-file) signal of the rule file from the Rule Checking Engine component, it will close the log file and the whole process of system will be finished.

Architectural Alternatives

1 Overall Architecture: Batch-Sequential Style

The current overall architecture (Figure 2) is a combination of batch-sequential and pipe-and-filter styles. One alternative approach is to make the whole system a batch sequential architecture as shown in Figure 4. All the functionalities of each component will be same except the incremental process property, which characterizes a pipe-and-filter architectural style.

By introducing the alternative architecture, I have identified advantages and disadvantages relative to the current architecture.

Positive Quality Attributes for the Alternative Architecture

• Reusability

Both the Tabling File Reader and the Rule File Reader contain file access operations. In the current architecture, since the Tabling File Reader is a batch process and the Rule File Reader is a filter, they are inherently different forms of computation. In the alternative architecture, since they are the same types of computation, it is easier to reuse the shared part of components.

Negative Quality Attributes for the Alternative Architecture

• Performance

Since there is no concurrent or incremental process, every data connection between batch processes will play as a bottleneck. It will negatively affect the performance of the system since data flow in data-centric architectures, such as a batch-sequential system, is a major criminal in performance.

• Modularity

While each filter deals with one rule at a time in the current architecture, each batch process deals with all configuration rules at a time in the alternative architecture. This change may increase the complexity of one component.

Since there are only five components and the reusable parts are relatively minor, the advantage in reusability over the current architecture would be trivial. Even if the client’s requirements for performance and modularity are not strong, they are still more significant than reusability.

2 Rule Checking Engine Component: Blackboard Style

This is an alternative approach that could replace the tiered architecture used for the sub-system of the Rule Checking Engine component. The blackboard architecture consists of three kinds of components, which are blackboard, knowledge source, and control process as shown in Figure 5.

Each component has the following behaviors:

• Rule Checking Blackboard

This component will accept the configuration information and variables, each of which represents the result of a configuration rule. The result variables will be changed only by the configuration rule N (knowledge source). When the Rule Checking Controller decides to finish the whole checking process, the final checking result will be passed to the Display component and to the Log Recorder component through the Rule Checking Controller.

• Configuration Rule N

This contains the body of each configuration rule. The time to apply the configuration rules to the Rule Checking Blackboard component depends on the status of the blackboard.

• Rule Checking Controller

This component will receive a configuration rule from the Rule File Reader component and send a control data to the appropriate Configuration Rule N component. When it gets the EOF (end-of-file) of the rule file, it will deliver the final state of the Rule Checking Blackboard, which is the checking result, to the Display and Log Recorder components.

By introducing the alternative architecture, I have identified advantages and disadvantages relative to the current architecture.

Positive Quality Attributes for the Alternative Architecture

• Extensibility

Adding a new configuration rule could be relatively easy since it requires only a minor change in the Rule Checking Controller. This is one of the typical advantages of blackboard architectures.

Negative Quality Attributes for the Alternative Architecture

• Testability

The alternative architecture newly introduces concurrency issues when more than one knowledge sources are ready to apply. Single data flow in the tiered architecture is much easier to test than in the blackboard style architecture.

• Performance

The behaviors of knowledge sources are not deterministic, and there are so many implicit data flows. It is harder to guarantee the bounded execution time in the blackboard style than in the call-and-return style such as a tiered architecture, which has explicit data flows and its behaviors are deterministic.

• Development Cost

To develop sophisticated knowledge sources, configuration rules are expected to be divided into more fine-grained chunks of rules.

Future Extensions

In this section, we’re going to examine how the RC2 can be extended to support future growth. Some of the most extended growth scenarios were discovered after proposing a possible distributed system and an integrated development environment for this rule checking.

1 Background

The current system is a text-based/command-line application, which is one of the most traditional and primitive types of software systems. There are a lot of possible extensions from this primitive feature.

The first possible extension is an integrate development environment (IDE) for this rule checking service. In the current process of updating railroad configuration information, editing and checking information are totally separate in spite of their interactions in nature. If we integrate those two separate processes into one environment, the efficiency of the whole process would be expected to be significantly improved.

The second extension is a distributed system for this rule checking service. In today’s world, since there are many available computer resources combined with networks in a distributed environment, there are strong requests for changing legacy systems into distributed ones. Also, the current system allows only one person to work on the configuration information at a time. It would be a better way for railroad technicians to divide tabling update workload into several pieces and to process them concurrently in a distributed computing environment.

2 Description of Architectures for Future Extension

We have two future extensions of the current system from the background considerations.

1 Architectural Changes for IDE (Integrated Development Environment)

As shown in Figure 6, this dominant software architecture of the IDE system is a publisher-subscriber style, where subscribers register their interest for published data and publishers announce data that they wish to share with their subscribers. The key component is an event-bus, which manage communications among the individual components. Publishers send message to the event bus and then the event bus invokes subscribers when messages arrive.

There are the following issues in making the current system an IDE system:

• Reusability (+)

this is a well-known benefit of implicit invocation. This paradigm decouples component implementation from knowing each other’s information. Any component can be introduced into the system by registering it for the events of the system.

• Modifiability (+)

For the similar reason, implicit invocation eases system evolution. Components may be replaced by other components without affecting the interfaces of other components in the system.

• Performance (-)

There is no direct data path. Event systems must rely on a shared repository for interaction. Since data flows and event flows are completely separate, more message passing are needed to complete services than in the current system. In addition, timing constraints (deadline) for the system cannot be guaranteed because of implicit invocations.

• Reliability (-)

The primary disadvantage of implicit invocation is that components relinquish control over the computation performed by the system. When a publisher announces an event, it cannot assume other components will respond to it. Moreover, even if it does know what subscribers are interested in the events it announces, it cannot rely on the order in which they are invoked. This property may degrade the level of reliability in the computation of the system.

3 Architectural Changes for Distributed System

As shown in Figure 7, this system consists of four tiers: the User Interface tier, the Checking Engine tier, the File Manipulation tier, and the Data Source tier. All the components in the original architecture are remotely distributed in different tiers based on their functionalities. Although there are some dependencies between the File Manipulation tier and the Data Source tier, other tiers are independent one and another so that this system may take advantages of the tiered architecture system that will be discussed below.

There are the following issues in making the current system an IDE system:

• Scalability & Reusability (+)

Horizontal scalability increases because adding additional components at each tier does not cause many changes in the whole system. It also allow different implementations pf the same tier to be used interchangeably, provided they support the same interfaces to their adjacent tiers.

• Modulability & Development Cost (+)

The tiered architecture increases the level of abstraction. This allows implementers to partition a complex problem into a sequence of incremental steps. Once the modularization is done, developments of each component can be performed in a concurrent manner.

• Maintainability (-)

As the number of components are their connectors (remote procedure call) increase, the topological complexity will increase steeply. It will harm the maintainability of the system since the control/data flows might become more complex and possibly unmanageable.

• Performance & Security (-)

Performance decrease since remote procedure calls require many operations that are not needed in local procedure calls such as networking, naming service, serialization of data and synchronization. In addition, security would become worse because the raw data of objects are transferred via network and the railroad configuration data is confidential.

[pic]

-----------------------

Figure 2. Overall Architecture Diagram of the RC2 System

pipe

Figure 3. Architectural Diagram of the Rule Checking Engine Component

reader

data

sink

source

Filter

Rank Description

• Left Factor: the degree of importance to the success of the system

• Right Factor: the degree of perceived risk posed by the achievement)

• Degree: H (High), M (Medium), L (Low)

Extensibility

IDE

Procedure Call

provider

user

Remote Procedure Call

(M, H)

provider

14. Extend system into IDE (Integrated Development Environment)

can be perform within 3 person-months

Figure 1. Utility Tree for the RC2 System

12. System can read the whole tabling file within 5 seconds

(L, L)

11. System terminates operation in < 1000 second

(L, L)

Resource

(M, M)

13. System is operational with memory capacity >= 256 MB

Rank

Scenarios

Attribute Concern

Quality Attribute

Operability

(L, L)

Legend

6. Cancellation of the checking operation can be done

at any stage of process

Usability

Learnability

(H, M)

5. Users’ manual enables the user to learn the fundamental

operations in < 10 minutes

Reliability

Accuracy

(H, H)

14. System returns translated speech with accuracy > 99%

Change Rule

(H, L)

3. Adding new configuration rule using the specification language

already developed can be performed within 1 person-hour

(M, H)

2. Adding new configuration rule can be performed

within 1 person-week

Modifiability

Change

Component

(L, H)

4. The rule checking engine can be replaced by a public SAT

(Satisfiability problem) solver within 1 person-month

Change

Configuration

(H, L)

1. System can be modified to recognize new configuration components

in the tabling file in less than 1 person-week

1.

System Response

10. System can check one configuration rule within 500 mil seconds

Configuration Rule N

Rule Checking Controller

…

Configuration Rule 2

Configuration Rule 1

Rule Checking

Blackboard

Figure 5. Blackboard Architecture for the Rule Checking Engine Component

sender

receiver

translation data

Control Process

Knowledge Source

Blackboardd

knowledge

source

control data

controller

knowledge

provider

user

Legend

user

Data Access

provider

user

File

Process

Legend

Service Adapter

Data Source

Tier

File Manipulation

Tier

Checking

Engine

Tier

User Interface

Tier

User Interface 3

Event Bus

subscriber

publisher

Editor

(M, M)

Performance

Shared Data

Shared Data

File Stream

reader

writer

Utility

writer

Batch Process

Tier

Method Invocation

User Interface 2

User Interface 1

Rule_Checking_Engine2

Log_Recorder

Tabling_File_Reader

Component

Figure 7. Overall Architecture Diagram of the RC2 System

Log

File

Rule_Checking_Engin1

Rule_File_Reader

Rule

File

Tabling

File

Display

Rule_Checking_Engine

Log

File

Rule_File_Reader

Tabling_File_Reader

Rule

File

Tabling

File

File

provider

user

Legend

Rule Dispatcher

Rule Repository

Log Recorder

File

Legend

Figure 6. Overall Architecture Diagram of the IDE RC2 System

Display

Log

File

Data Access

user

provider

Rule_Checking_Engine

Rule_File_Reader

Tabling_File_Reader

Rule

File

Tabling

File

Log Recorder

Batch Process

Configuration Information

(

File

data

sink

source

Legend

Figure 4. Batch-Sequential Style Architecture of the RC2 System

Display

Log

File

Rule_Checking_Engine

Rule_File_Reader

Tabling_File_Reader

Rule

File

Tabling

File

Log Recorder

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download