6

Software Architecture

P E R F O R M A N C E

ERROR RECOVERY

O A & M

Feature s

PROBLEM

Functions

Software architecture is the body of instructions, written in a specific coding language that controls the structure and interactions of software modules. It embodies the structure of a system and provides the framework for the software modules to perform the functions of the system. Design of the interfaces between modules, constraints on the size and execution of the modules makes it easier or harder to integrate them into a working software system. The architecture of the system enforces the constraints on the modules and the properties of capacity, throughput, consistency and module compatibility are realized at the architectural level. Within the system are architectural modules either within the core operating system or in the middleware or custom designed that govern how the processing modules work together to do the system functions. Application calls these modules through special interfaces called Application Programming Interfaces (API). In the early days of computing these were simply the system calls made to operating system functions, like ‘dispatch a program.’ The communication architecture is code that governs the interactions of the processing modules with the data and with other systems. The data architecture is code that controls how the data files are structured, filled with data and accessed. Once the architecture is established, functions may be assigned to processing modules and the system may be built. Processing modules can vary greatly in size, scope, depending on the function each performs, and the same module may differ across installations. In every case, however, the processing architecture, communication

1

architecture and data architecture constitute the software architecture that is the system’s unique and unchanging “fingerprint.” When systems share a common architecture, they are the same, regardless of superficial differences in name or in site peculiar configurations or adjunct functions. When several sites use software systems with a common architecture, they are considered to be using the same software system even though they may do somewhat different things. No two iterations of a software system are exactly the same, despite their shared architecture. When a system is installed at two or more sites, localization is always required. Tables are populated with data to configure the software to meet the needs of specific customer sites. The customer may have special needs that require more than minor table adjustments. Customization of some modules may be required. New modules may be added. Alternatively, two systems with differing architectures can perform the same function in alternative ways. These would be different systems. Function and output do not define a system. Only its architecture can describe and identify a system. CASE Study- A Two Pronged Approach In the late 1980’s, Bell Laboratories needed to develop a system to control a very critical congestion situation. The system was called NEMOS. It used a distributed database with several unique databases schemas. Some of the data overlapped. The schemas were designed to speed processing time. Architecture reviews revealed that that this architecture was extremely complex and broke new theoretical ground. Since there was no history of similar development to provide a guideline and the need was urgent, Bell Laboratories decided to develop a second system with a different architecture in parallel to mitigate the architectural risks identified. The insurance system was also called NEMOS but instead used an integrated database architecture, which means a single database for everything. The result was two systems with the same name, performing the same function. The system with the distributed database architecture could not be scaled to handle network growth and was discarded. The architecture with the integrated database architecture was successfully deployed and demonstrated its robustness when it managed telephone calls during the famous ‘World Series Earthquake’ in California. (On October 17, 1989 at 5:04 P.M., a major earthquake struck the San Francisco Bay area. The earthquake was nicknamed the World Series Earthquake because it occurred just before a World Series baseball game was scheduled to begin in Candlestick Park. Millions of people witnessed the motion of the earthquake on television. Sixty-seven people lost their lives, and property damage was estimated at $6 billion, but the telephones worked.) ******************************************************************* One of the most common failures of architecture design for software systems is not attending to features needed by system administrators. They are responsibilities for: a. Training users b. Configuring the computer to run the software c. Defining network requirements for the network manager

2

d. Setting up the data files c. Maintaining adequate response time d. Trouble shooting Too often problems arise during system startup. Few of these problems are identified as software errors because the system administrator is intimated by the new system. For example: In he request-response model (below), a number of host computers are connected to a local area network (LAN) using Ethernet and share the transmission media. Some of the host computers are servers and many more are clients. When one server and one client are connected, the system worked fine. As the number of clients were added the system continued to operate satisfactorily until there was a sudden network hang and no messages could be transmitted between any server and client. This is an example of a conditionally stable system. A system is conditionally stable as long as any of its critical resources is not exhausted. Once it is consumed the system crashes or hangs and no messages can be sent. Frequently there are early warning symptoms of slow response time or lost messages before the system halts and other times there is no warning at all. In this case clients are added and the system performed to specifications. When the one hundred and first client was installed and sent a message the system failed. No messages could be sent. There were so many message clashes on the transmission media that the computers sent all their time resending lost messages. The system administrator had to turn off all the hosts, bring up the server and limit the number of clients until a faster transmission media could be installed. LAN Server …. Client Request-response Model With many computers sending messages the likelihood of two messages trying to use the transmission media simultaneously increases. Ethernet LANs that detect clashes and abort transmission. When this happens, the applications can timeout. Too many timeouts can lead to hangs or crashes. If n is number of clients on a LAN and p = the probability a client could be sending a message the optimal number of clients to minimize clashes is n-s = 1/p, where s is the number of servers on the LAN. For example If a client is sending 60 messages an hour or one every minute and the message contains 1500 characters then it will take 1500 characters x 8 bits/character/ 1,000,000 bits/sec =

3

12 milliseconds to send one message. Allowing ample margin for capturing the line it will take about 15 milliseconds per message. The probability of a message being on the line from one client is 0.015 so the optimum number of clients is about 60. Case Study: System Installation A naïve system administrator could not start up a system. It was successfully tested and accepted by the customer’s organization. She had two thick handbooks in her hands and could not find the command that would let her install the database. A video of this situation is on the web site. Developers believed their software was of high quality and was a great system. . They documented it fully and yet system administrator was disgusted. There such a difference of perception because naïve users were not used to being up the system. The commands to edit the configuration files are thought to be well known UNIX library commands. The system administrator was unfamiliar with these commands even though she had been trained in UNIX based applications. The folklore about the basic steps needed to load the command files was not provided in the user manuals. The commands were listed in a reference book that had no index and so thick that it was hard to handle and hard to find basic commands. The first time I had to shut down a Windows system, I was stymied because ‘everybody knows that you must click startup to shutdown.’ Software Architecture Experience Good software architecture is vital for a successful software development. To have a good architecture there must be a software architect as called for chapter 1. The architecture is the framework for all technical decisions and must be documented in a clear and concise way and communicated to everyone on the project. The process of developing the architecture begins once the prospectus is in hand as shown in figure 2. A ‘first cut’ architecture is created during the requirements process to assure that the system is feasible. Once the requirements are complete an architecture discovery review makes sure that all non feature based requirements are known. Then the architecture process begins. It is an iterative process that focuses on evaluating design alternatives and simplifying the system. Simplifications are possible when duplicate features are eliminated, when object classes match the problem domain, when existing libraries or components are used or when algorithms are simplified. An architecture review at the end of the architecture process makes sure that the system can be built and that it will solve the problem. A specific goal of the review is to simplify the system. One way to measure the degree of simplification achieved in the architecture process is to measure the function points at the end of the requirements specification process and again at the end of the architecture process. Magic Number: The goal for the architecture process is to reduce the number of function points by 40% by: a. eliminating redundancies

4

d.rational. c. See http://www.jsp for a paper describing the approach.com/products/whitepapers/350. Architectu The Architecture Process The ‘4+1 Architecture Approach’ provides a way to structure the architectural design for a software system. employing working components simplifying designs simplifying the interpretation of the requirements dropping complex features The architecture process continues through out the development life of a software system to assure that that the integrity of the architecture is preserved as new features and functions are added.b. e. Figure 4+1 Architecture Approach It encompass typical waterf (someone con 5 .

which the tools. so too. scalability. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman's plans. Software architecture is the result of assembling a certain number of elements in a structure that satisfies the functionality and performance requirements of the system. assemble. a software architect sets out the software architecture as a basis for actual system design specifications. per the requirements of the client. with style and esthetics. which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect. with decomposition and composition. see figure: • The logical view. It is best described with a model composed of multiple views or perspectives. Software architecture deals with abstraction. non-functional requirements such as reliability. or processors and environments used to compile.An Architectural Model Software architecture can be thought of as a coherent set of abstract patterns guiding the design of each aspect of a larger software system. 6 . which captures the concurrency and synchronization aspects of the design. load and change the software artifacts. as well as some other. portability. and availability. Software architecture underlies the practice of building computer software. • The physical view. which is the functions the system will perform or an object model of the design • The process view. • The development view.

The execution time and space of the component are bounded through the use of rejuvenation technology and boundary conditions are set limiting the domain of execution of the component. In some occasions. materials and processes that help to solve software problems. Data can consist of numbers. and "communicate" with other objects in the system. Other sets of views have been proposed. Each object in the system serves as a model of an abstract "actor" that can perform work. Systems engineers approach it from the Physical view. Parnas explains the need for modularity and the effectiveness of information hiding. By encapsulating software functionality the form of object. See Sha’s pioneering work on bounding software execution on the web site for this book. The key here is that the notion of subprogram is not permitted outside the boundary of the component. The component boundary is violated. or the other's. references. software configuration staff see it from the Development view. This “4+1” view model allows stakeholders understand the architecture. which is the ability for a program to ignore some aspects of the information it manipulates. which is a unique conceptual structure including both data and the methods to access it whose identity is separate from that of other objects. Interfaces are always through formal structures that normalize data definitions as defined in the Jackson Design Methodology. or scenarios based on business rules. The UNIX community calls the structure of this information ‘Man’ pages. but this one is the most useful. b. These become a fifth view. End-users. 7 . This is called encapsulation and laid the foundation for object oriented design and includes the concept of abstraction.The description of an architecture cab be organized around these four views. data or methods. although it can "communicate" with them using messages. report on and change its state. Another is a set of formal constraints on a software module. which is a computer language or simple syntax for describing the interface of a software component. literal strings. machines. An object is a unique concrete instance of an abstract data type (that is. data specialists from the Logical view. without revealing its structure. variables. It is essentially a common language for writing the "manual" on how to use a piece of software from another piece of software. a conceptual structure including both data and the methods to access it) whose identity is separate from that of other objects. He defined a software structure with minimum connections to other modules called coupling and a maximum of cohesion meaning that the subtleties of the software design and data interactions are hidden from other modules. If two programs need to communicate directly through data structures they become part of the same module. Project managers. and then illustrated by a few s use cases. although it can "communicate" with them via messages. some object can be conceived of as a sub program which can communicate with others by receiving or giving instructions based on its. Software Components A software component has more than one definition. Software Component technology builds on prior theories of a software object. then the Process view. The set of constraints define the component: a. An object is often sometimes thought of as a region of storage. One is the development and application of tools. customers. It adheres to some interface description language. in much the same fashion that a user manual describes how to use a piece of software to the user.

its domain of execution. d.COM objects. Software components provide is a common and convenient means for inter-process communication. A module can only be a component after its third release and 8-10 months of operation when the failure rate becomes constant with time (ref: Dependability paper) g. either within the same computer or over a network. System and reliability testing are performed for 10 times the rejuvenation period to reduce the likelihood of executing defect states thereby causing hangs or crashes.c. Examples are UNIX sockets. There are different forms of software components such as CORBA and . The top one is the UML diagram and the bottom is the schematic commonly used by Microsoft’s . which is the exchange of data between one process and another. These tests assure that a small input does not induce a large unbounded output. 8 . Special tests are needed to assure that the component is stable within its constrained execution domain. The "lollipops" sticking out from the components are their interfaces. f. as explained by Hatton. Figure shows two schematics for software components. its inputs and outputs including the data value bounds and any other special constraints. to the range of 100 to 1000 instructions. Microsoft Windows' DDE. A component is documented with a performance worksheet that specifies what the component does. e. It implies a protocol that guarantees a response to a request. These specifications are best placed in the preface of the source listing for the component. The module is limited in size to reduce defects. The dynamics of the component are stochastic and periodic because on a regular basis the component states are reinitialized.COM.

provides the traditional user interface for the Unix operating system and uses the pipe character ‘|’ to join programs together. mathematician. In the pipe metaphor. it most often is stored as multiple fragments of data at different places on a disk (or even multiple disks). In contrast a file in a computer system is a stream (sequence) of bits stored as a single unit. For creating this mechanism. The early development of what is believed to be one of the most influential operating systems in history was unique. . a pipeline is formed. Its goal was to demonstrate the portability of software among different hardware architectures. Errors are accumulated in stderr. One of the architectural services operating systems is to organize files in a file system. a design pattern is thought to encompass a tight interaction of a few classes and objects • The concept of software components. A sequence of commands joined together by pipes is known as a pipeline that represents the concept of splitting a job into sub processes in which the output of one sub process feeds into the next much like water flows from one pipe segment to the next). engineer and famous Bell Las programmer invented: • The pipes and filters architecture of UNIX. Typically.Douglas McIlroy. also called "the command line". By joining one tool's stdout to another tool's stdin. typically in a file system on disk or magnetic tape. speak and others. Generally a filter program will read its standard input and write to its standard output and do little else. Algorithms are not thought of as design patterns. His seminal paper is in the appendix to this chapter (or on the web site). It contained the concept of the ‘a pipe’ that signifies that the output of one program feeds directly as input to another program. graph. a file is ‘a container. It was successful and was the first demonstration of portable software implementing the operating system as a layer of software separating the application from the unique designs of a supplier’s computer. Conventionally a filter program distinguishes itself by being fairly simple and performing essentially one operation.’ A Unix shell. While a file is usually presented as a single stream. diff. sort. and stderr—the standard error file. usually some sort of simple transformation of 9 . join. Pipes and filters are software design patterns. all UNIX tools have access to three distinct special files: • • • stdin—the standard input file. A filter program a UNIX program part of a pipeline of two or more UNIX tools. stdout—the standard output file. since they solve implementation problems rather than design problems. professor of computer science. • Several widely used UNIX tools such as spell. Design patterns are standard solutions to common problems in object-oriented software design. . The pipe is one such service and provides input or holds the output.

The component needs: a. e. unlike objects. makes no such assumptions. to pass back useful error messages as appropriate. We consider component technology to have evolved from object oriented technology. grep "alice" reads its stdin as lines. but not the text "wonderland".its input data. Software component architectures. d. It takes significant effort and awareness to write a software component that is effectively reusable. ideally by end users as well as by programmers coding for those end users. more thorough testing. robust input validity checking. The basic idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. to be fully documented. can be counter-intuitive. wc -l counts the lines on its stdin. and later DCOM. Although it has been implemented on several platforms. and instead states that software should be developed by gluing prefabricated components together. by contrast. The pipeline has four parts: • • • cat * concatenates the text of all files to its stdout. Microsoft paved the way for actual deployment of component software with Object Linking and Embedding (OLE) technology. and prints a line count on its stdout. grep -v "wonderland" reads its stdin and prints on its stdout only those remaining lines which do not contain the word "wonderland" (note that -v inverts the selection). b. especially using drag and drop. It later evolved to become an architecture for software components known as the component object model (. c.COM). An example of a pipeline: cat * | grep "alice" | grep -v "wonderland" | wc -l will print out the number of lines in all files in the current directory which contain the text "alice". It is used to enable cross-software communication. This notion has led to many academic debates about the pros and cons of the two approaches. It accepts that the definitions of useful components. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modeling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways. and prints on its stdout only those lines • which contain the word "alice". as well as for managing compound documents. also known as ActiveX.COM) is a Microsoft technology for software components. to be built with awareness that it will be put to unforeseen uses Magic Number: 10 . it is primarily used with Microsoft Windows. It was initially used primarily for copying and pasting data between different applications. Component Object Model (.

To help narrow the number of operations language candidates under consideration. It was used by the Switching Control Center System (SCCS) to manage the Lucent Technologies (formerly AT&T) family of No. Vol.6 times the cost of making the original module. It shows realization of critical system interface structures within an architecture that became the standard for the telecommunications industry: A feature article published in Telephony1 states that. TIRKS®.” Telephony. an operations language is only a language syntax. digital cross-connect system (DCS). “Most telecom network elements in North America today can be managed using TL1. In early 1985. The author was the chair. this article presents the history on the origin of TL1. Program Documentation Standards (PDS) was the predominant operations language used to centrally manage the network equipment in the “Bell System”. No. the task force arrived at two operations language candidates. Specifically. 1997. The members of the task force comprised of subject matter experts in operations requirements. the task force identified a few attributes for a viable operations language3 candidate including: • • • • • • Cannot be owned by any one company except Bellcore for standardization Should be well-known Should have good documentation Can be made available to the public domain in a short time frame Can be developed by equipment vendors with little or no guidance Preferably has a good track record Guided by the above list of attributes. transmission testing. In view of the renewed interests in TL1 for the telecommunication industry. automated digital terminal system (ADTS). 1AESSs and early members of the Digital Access and Cross-connect System (DACS) family. September 1.25 protocols. administration. The first one was Bellcore’s Flexible Computer Interface Form (FCIF) that 1 2 3 Conor Dowling and Gerry Egan. “The Story of TL1 provides many lessons about the future of telecom management. Component Interfaces Fu-Tin Man wrote a Brief History of TL1. and no serious telecom management system developer can ignore it”. integrated digital loop carrier (IDLC) system. 233. maintenance and provisioning (OAM&P) functions. Therefore. Mission Prior to the 1984 divestiture. Bellcore commissioned a task force2 to quickly recommend a nonproprietary set of operations messages to be exchanged between an operations system (OS) and a network element (NE) to conduct operations. 34-36. a module needs to be used three times to payoff the investment in making it a component. 9. whereas an operations message contains both language syntax and semantics.The cost of making a module a component is 2. 11 . and X. pp.

whereas position-defined fields use fewer characters to specify parameter value but must appear in their pre-assigned positions.e. whereas those in MML could either be keyword-defined or position-defined. and were judged to be inefficient for OSto-NE communication. MML had none that the task force was aware of at the time. 12 . It was originally named the FACS Component Interface Format when it was conceived as part of the FACS architecture.” ANSI T1. since the command language dialog was a requirement for a local craft interface7. “FCIF Language Definition. was later published. Now renamed International Telecommunications Union-Telecommunication (ITU-T). FCIF was viewed even less efficient because the parameters in FCIF were keyworddefined. October 1993. telephone numbers.has been used among Bellcore-developed Operations Support Systems such as between the components of Facility Assignment and Control System (FACS)4. Issue 2. etc. but MML had several semantic definitions that help specifying semantics. • • MML was very human-readable as its parameter fields were distinctly separated. one for human and one for machine. While FCIF had a good track record and a wealth of support tools.232-1993. MML reserved the first parameter field for command code (i. Even though FCIF had been a working operations language among Bellcore-developed OSs. Both FCIF and MML offered no semantics that could be re-used to support a generic set of OAM&P functions. It is also a current American National Standard as documented in “OAM&P . was considered greater than the penalty accrued from inefficient machine-to-machine communication. However. action to be taken). it did not have the same level of documentation.6 Both FCIF and MML were character-based. Comparative Analysis Below is a highlight of the analysis that compared the pros and cons of the two operations language candidates: • MML was one of the international standard languages adopted for network management in late 1970s. Keyword-defined parameters provide flexibility for specifying parameter value. and between FACS and TIRKS®. A Bellcore special report.. • • 4 5 6 7 The previous description of the FCIF acronym was FACS Component Interface Form. It also assigned the word “REPORT” (abbreviated as REPT) for NEs to autonomously report their self-detected events and conditions. It was documented as a family of Z. It proved so robust that it was extended and used throughout the Telecommunications Industry.300 recommendations in the 1980 CCITT Red Book.G Interface Specification for Use with the Telecommunications Management Network (TMN). the cost of developing two interfaces in an NE. in its input commands. The second one was CCITT 5 Man-Machine Language (MML). For example. FCIF was comparatively less human-readable than MML because of its nesting syntax that was designed to capture customer name.” SR-STS-002603. address.

For example. The first letter in an error code is designated for an error category. However.The following table summarizes the results of a comparative analysis between FCIF and MML.:data. the parameter field following CTAG was designated as general block (GB) that is reserved for such data as scheduled entry of sequences of recent changes to a switch NE. output response.. where TID = Target identity of NE AID = Access identity of NE component CTAG = Correlation tag of input command MML International 1980 CCITT Red Book Poor Excellent Little None None FCIF Little known Little Poor Good None Excellent Abundant At a later time. calendar date (YYYY-MMDD) and 24-hour-clock time (HH:MM:SS)... The formatting task for an input command involved assigning mandatory parameter fields following the command code in an input command.. and carriage return. calendar date 13 . The formatting task for an autonomous message involved using an autonomous tag (ATAG) for all REPT messages generated by an NE. and EXXX an error in the equipage category.data. an NE can provide an explanation for an error by enclosing the latter within a pair of quotes (“ “). Examples of these are white space. As an option... the task force focused on eliminating its human-oriented features without violating the MML recommendations. and autonomous message. The formatting task for an output response involved using CTAG and normal (COMPLD) or error (DENY) response in addition to a TID... to the extent possible.. linefeed. Feature Recognition Documentation Machine communication efficiency Human communication efficiency Availability of reusable semantics Working track record Software support tools Message Formatting After selecting MML as the operations language. It also includes using four-letter error codes to help explain the reason for the error response. IXXX signifies an error in the input category. in addition to a TID. The next task involved formulating the formats for input command. a TL1 parser is not required to parse the text contained inside a pair of quotes. These parameter fields are as follows: Action-modifier-modifier:TID:AID:CTAG:data.data.

and testing functional categories that would be presented in Technical Advisories TA-TSY-00199. Issue 3.” GR-811-GORE. In addition to the Bellcore OSs. TA-TSY-00199. They have implemented many of the TL1 messages documented in TA-TSY-00200 and TA-TSY-00201. all the TL1 messages that have been published in various Technical Advisories (TAs). Many surveillance OSs and testing OSs have also adopted TL1 as their communication language with NEs.and 24-hour clock time as well as the level of severity associated with the autonomous message. a listing of. namely.. a number of other vendor OSs. a Bellcore Technology Requirements Industry Forum (TRIF) sponsored by Pacific Bell was held in San Francisco on June 1986 to present and discuss TL1 messages in the public domain. respectively8. In an attempt to unify TL1 messages used across transmission and switching equipment. modifiers). and Generic Requirements (GR) documents.TL1 Messages Index. and GR-834-CORE. TA-TSY-00200. particularly testing OSs and SONET element management systems (EMSs). Finally. Technical References (TRs). with a view of providing TL2 and subsequent versions in the future. To provide a roadmap to all of them. respectively. 14 . The very first set of TL1 messages was published in TA-TSY-00199. It also dubbed the selected operations language Transaction Language One or TL1. maintenance. Bellcore has published hundreds of TL1 messages for different operations domains and network technologies. Even a number of emerging transport NEs that support the family 8 9 The bulk of the TL messages in these three TAs have now been migrated to GR-199-CORE. August 1985. a large number of transport NE vendors have implemented TL1 messages to manage their families of DCSs. and RETRIEVE. The switch TL1 input commands generally have four key verbs.e. and TA-TSY-00201. and was specified to conduct provisioning functions in transmission NEs such as DCS and ADTS. and SONET add-drop multiplexers (ADMs). Issue 2 was published in February 1986 to also present a preliminary set of TL1 version of recent change messages for switch NEs. the remaining task was to specify actual TL1 messages (including semantics) that are used to implement OAM&P functions and publish them in the public domain. EDIT. Moreover. respectively. “OTGR: Operations Application Messages . June 1997. To-date. GR-833-CORE. Industry Support of TL1 Most of the TL1 messages in TA-TSY-00199 are currently used by provisioning OSs to remotely set cross-connections in DCSs and channel unit settings in digital loop carrier (DLC) systems as well as send recent change messages to switch NEs. Issue 1. DELETE. are using TL1 messages to manage their NEs. each of which can be applied to about a dozen of administrative views (i. ENTER. TL1 Message Formulation Once the language definition was more or less completed. and pointers to. GR-811CORE9 presents. families of DLC systems. on an ongoing basis. The task force selected provisioning.

of digital subscriber line (xDSL) and wavelength division multiplex (WDM) technologies are planning or requested to provide TL-1 interfaces. the architecture provides their "marching orders. For project managers. allocation of project resources. planning. Stakeholders include those involved in managing the project. Several switch NE vendors have implemented TL1 messages to administer their plain old telephone services (POTS). multi-vendor network. involving steps of creation and refinement. For designers of other systems with which this one must interoperate. and tracking of progress by the various teams. and ISDN services. the architecture dictates the correct black-box behavior of the pieces that must fit together. Along the same line. Unification among managed information is crucial to managing a multi-protocol. as well as "consumers" of the architecture that must write code to carry it out. The virtual TL1 MIB provides an abstraction of managed information compatible with those presented by the SNMP or CMIP MIB. For technical managers. the architecture defines the set of operations provided and required. or design systems that must be compatible with it. LLC (NPL) has developed a virtual management information base (MIB) for TL1 in conjunction with the MIBs for simple network management protocol (SNMP) and common management information protocol (CMIP). This perspective on architecture is forward-looking. multi-line hunt." The architecture establishes inviolable constraints (plus exploitable freedoms) on downstream development activities. and the protocols for their operation. architecture serves as the basis for a work breakdown structure. architecture provides the basis for forming development teams corresponding to the work assignments identified. Documenting the Architecture: Systems benefit from good architecture documentation. Network Programs. Specific uses in this category include the following: • • • • • For downstream designers and implementers. 15 . As mentioned in the earlier Telephony article. The following is borrowed from Software Architecture Documentation in Practice at the Carnegie Mellon Software Engineering Institute: Uses of Architecture Documentation This is a way to inform stakeholders of system design at every development stage. that allows the interoperation to take place. Centrex. various companies have developed object servers that provide an adaptation between TL1-based and object-oriented technologies. For testers and integrators.

as do routine maintenance activities. This process occurs in tight cycles (most architects project the effect of each of their decisions) and in large cycles (in which large groups of decisions. architecture provides the following: • • • • • • For the architect and requirements engineers who represent the customer(s). For product line managers. by how much. simulations and simulation generators. Architecture mining and recovery fall into this category. architecture is a forum for negotiating and making trade-offs among competing requirements. for assurance that implementations have in fact been faithful to the architectural prescriptions. For those wanting to develop using vendor-provided products from the commercial marketplace. the relevant decisions are re-thought. in some sense. and now the time has come to make a change to it or to extract resources from it for use elsewhere. the architecture establishes the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components. perhaps even the entire architecture. inward-looking. The first artifact used to achieve system understanding. and the process repeats. In particular. architecture is basis for conformance checking. It refers to cases in which the system has been built and deployed. the architecture determines whether a potential new member of a product family is in or out of scope.A basis for performing up-front analysis to validate (or uncover deficiencies in) architectural design decisions and refine or alter those decisions where necessary. It involves making prospective architectural decisions and then projecting the effect of those decisions on the system or systems that the architecture is driving. This perspective on architecture is. Where the effect is unacceptable. and if out. architecture serves the following roles: • For technical mangers. For those interested in the ability of the design to meet the system's quality objectives. the architecture serves as the fodder for architectural evaluation methods For performance engineers. This perspective on architecture is reverse-looking. In particular. are subjected to formal validation). architecture is a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets. theorem provers and model checking verifiers. For the architect and component designers. 16 . architecture provides the formal model that drives analytical tools such as rate monotonic schedulers.

and it describes what is true. 4. Effective bandwidth of the interface mechanism 17 . The IPC mechanism to be used for data and for control b. Starting with the ‘4+1’ Overall architecture diagrams use additional diagrams to describe all the components of the system. For re-engineers. For those inheriting the job of architect after the previous architect's untimely departure. Architecture documentation is both prescriptive and descriptive. then clearly there was a breakdown in the development process. Error recovery to prevent lost data. the architecture is usually the first artifact for familiarization with a system's design. problems with overload control. Describe and list the special data error handling flows. revealing the areas a prospective change will affect. That is. If the "build-as" documentation differs from the "as-built" documentation. Trace scenarios of how data/information flows through components. architecture is a starting point for maintenance activities. Describe the user interfaces 6. For new project members. 5.. Any expected issues with the IPC mechanism (e. Joe Maranzono provides a checklist for these reviews in table: Checklist for Architecture Reviews by Joe Maranzono email: jfm@att. 3.net 1. the architecture is the artifact that (if properly documented) preserves that architect's knowledge and rationale. List major components of the system and the functionality provided by each component. List all interfaces with other systems and for each interface describe: a.g. it prescribes what should be true. if needed e. With architecture and its documentation in hand the project is ready for a formal Architecture Reviews. architecture is the often first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at component granularities. performance degradation at some capacity level. about a system's design.• • • • For maintainers. new technology) c. 2. The same documentation can serve both purposes. Failure modes and error handling for each type of failure d.

No written requirements d.7. extensibility f. c. System availability d. Data volumes missing 18 . available support b. Administration and Maintenance approach including: a. Expected system response time in terms of its average. Error handling f. licensing costs d. Interfaces to external sources and systems c. 50% of all problems arise from incomplete requirements including: a. Examine the Operations. 8. Security h. defect records c. No acceptance criteria e.’ …the system must be reliable. Data Consistency and Accuracy Here are typical problems found in such reviews: 1. Failure avoidance and handling e. Disaster recovery g. Examine robustness of component choices. performance under load e. COTS or custom-made including: a. Review local data bases or data stores used for temporary data storage or reference data storage 10. flexibility 9. Network demands including congestion strategy 11.’ 2. variance and bounds. Examine strategies used to keep design simple and avoid unnecessary complexity. Number of simultaneous users. Database Sizes g. d. Peak arrival rates e. No traffic profiles specified b. Over night processing and calculations f. Unknown customers c. Undefined usage scenarios b. 25% from performance issues a. The average load and busy hour of the Transaction Profile b. Examine performance and capacity budgets by considering the expected traffic and background processing in terms of: a. Operational Environment b. No model of offered load available c. “Catchall statements.

Upscale architecture middleware supports building the construction of sophisticated systems by assembling a collection of modules with the help of visual tool or programmatic interfaces. 10% from Unspecified Operations. Middleware gets its name from being the software component that provides simple access to operating system functions by applications. An early 1980s example of middleware was the Tuxedo product used with distributed UNIX applications. Keeping them stable and standard makes it easy to develop some applications but limits growth to new application areas and eliminates software provider’s perceived competitive advantages. such as working with multiple operating systems. No analysis of system availability b. 5% error recovery missing 5. data communication protocols. Whenever the module needs more data to continue its operation. Conversion tools missing 4. In piped workflow a special Meta data channel that exchanges data among all modules. Architecture Middleware Middleware provides a reusable architectural component that solves the distributed application problem. In traditional middleware software component dispatch is tightly integrated Within the platform that makes it hard to extend for new. Object Management Group’s Common Object Request Broker Architecture (CORBA). applications. A video showing how it uses two-phase commit technology is on the web site accompanying this book. The Open Software Foundation’s Distributed Computing Environment (DCE). Microsoft’s Distributed Component Object Model (DCOM). Recovery system lags on-line system so that there was no possibility of database catch-up upon major outage c. Database tools inadequate d. Maintenance or Provisioning (OAM&P) a. Night or batch processing loads unspecified e. A data pool or pipes are two ways for data channels to exchange data. it has to ask for data channel. These interfaces are called Application Program Interfaces (API) and are the subject of heated arguments between vendors and customers. Administration. and it will be destroyed when the client 19 . flow control and a data channel between neighboring nodes. In an architectural hierarchy it ‘sits’ between the low level operating system and the application software. Unwarranted expectation of linear scalability 3. Enterprise Java Bean (EJB) and BEA’s Tuxedo are widely used middleware products. No resource budget f. transaction recovery across multiple applications and computers. It helps programmer easily and quickly build distributed business application by isolating them from complex design issues. Traditional middleware components are not interdependent because they exchange data. The new concept of a piped dispatch has special nodes. as yet undefined. The data pool is a public temporary storage for all variables of all modules during one processing procedure.d. 5% using immature technology 6. 5% from a lack of analysis of subsystem and module dependencies.

0 20 . The pipe is another way to exchange data for computational modules. But the complexity of distributed networks and unanticipated requirements makes the construction of middleware hard. This release is promised to be robust. A new release of the Middleware is scheduled for June. In one object class pipes share the same temporary memory. all the necessary data have to be set before the module runs. so the intermediate result can be transferred from the non adjacent modules in an orderly progression of steps. general purpose middleware platform continues.0 or 3. Reference Case Study Analysis of Middleware Dependencies. Another approach is to use dynamic dependency to manage components in an already running system. reconfiguration executing components is possible.0 July August SHIP DATE Question: Should the architecture specify use of Middleware Version 2. The pipe consists of many independent sub-pipes that interface pair wise adjacent modules. This is inefficient. The new transaction recovery scheme requires ‘minor’ changes to all the application modules. Background: You are the architect for a software team developing a Customer Resource Management application. Timeline: Mars Middleware 2. Each module has to define which data it needs from data pool and which data will be produced to data pool. Through the communication and event contracts between hooked components and their client. and result can only be put into data pool after the module finishes.processing finishes. Each sub-pipe contains a pair of interface objects that transfer data between the modules and pipes. To rely the dynamic dependencies use a component configurator responsible for storing the runtime dependencies between specific components.0 Version Application Tests Inventory retest Simple test Test all transactions April May June 3. fix the bugs and be industrial strength. In data pools. Every component may have a set of hooks to which other components can attach. Your architecture review for the Operations shows that the middleware transaction recovery component is buggy. Here is your committed schedule. Middleware masks the problem of building distributed application among heterogeneous environments. There might be some other components (called clients) that depend on server components. The search for a high performance.

Working closely with the project manager the architect decided to chose option 1 Go live with Middleware Version 2. But Goldin said he will not abandon the National Aeronautics and Space Administration's ``faster. Version 3. The architect was not attracted to technology hype such as. The project manager projects a 50% reduction in profitability and the company will go from being profitable to breakeven.0.0 and the risks.0 and slip out future releases while investing in for field conversion to Version 3. NASA Administrator Dan Goldin took the blame botched Mars missions. cheaper'' approach. This field upgrade requires special conversion software and is thought to be extremely 2. schedule and risk analysis.3 really fix the transaction recovery problem as advertised or is it ‘vaporware’ c. Will OS. complicated. This is not an easy decision. Go live with Middleware Version 3. 4.0 later. expensive spacecraft. The field conversion took six months longer than projected and delayed the next set of features. All options are risky. The architect evaluated the features of Version 2. and upgrade to version 3. needed a reliable system and trusted the architect to deliver systems in good order. Important future middleware features will be delayed impacting the supplier’s profitability. Mission managers will get enough money and people to do the job.0.0 and insist that the middleware supplier provide onsite testing support avoid project delays.0 delivery to the application team might be later than estimated. The supplier wants premium payments for the support. Go live with Middleware version 2. saying he pushed too hard. Business increased as customers learned of the care and thoughtfulness of the architect in assuring trustworthy products. cut too much and made it impossible for spacecraft managers to succeed. but there won't be a return to the days of big.Issues to Consider: a. But the customer understood the risks.0 is solid as a rock and has great features!” Risks were managed carefully and conservatively. 21 . Are the required code changes to the application modules needed to interface with the new recovery scheme as simple as advertised? If people are assigned from OS development to test cases design.0.5 weeks standard deviation with this option. Go live with version 3. will they find work that is more satisfying on other projects or in other companies? Options explored at the Architecture Review: 1. “Version 3. The software project manager has conducted a detailed schedule analysis and foresees a 6-week delivery delay with a 1. 3. This seemingly simple decision could have huge repercussions. The architectural review gave the team the opportunity of thoughtful technical. The customer participated in the decision. b. better. Your top executives will be very angry as payments will be delayed causing the company to show a profit loss for the year.

It was an architectural deadlock problem. where Mars Polar Lander and Mars Climate Orbiter were managed. Mars Climate Orbiter was lost Sept. Their combined cost was about the same as the last successful spacecraft to land on Mars -. Unfortunately NASA did not invest in the good software processes of architectural discovery after the first problem. 23 when nobody realized that Lockheed Martin Astronautics delivered navigation data in English units rather than metrics. They found mismanagement. Case study: the Mars Pathfinder The Pathfinder lands successfully.if it had been noticed.Pathfinder in 1997. The mission software engineers note that when this happens the computers reboot the software. Too many risks were taken by skipping critical tests or overlooking possible faults. a former JPL chief engineer who led one of the investigations. said John Casani. And nobody noticed or mentioned the problems until it was too late. The problem could have been easily resolved by beaming new software to the lander during its 11-month cruise -. gathers data on Mars and sends pictures back to earth. Three software tasks were involved in the problem. The $125 million craft burned up in the Martian atmosphere. But even the first Pathfinder had software problem. causing the software to stop the descent engines 130 feet above the planet's surface. One task rebooted the computer whenever it was idle for a period of time. but we're not going to let the pendulum swing all the way back. Then it occasionally stops sending images and as times goes on these stoppage occur more frequently for longer periods of time.``We're going to make sure they have adequate resources. unrealistic expectations and anemic funding were to blame as much as the mistakes that actually doomed the missions. The $165 million Mars Polar Lander was most likely doomed by a sensor that mistook a spurious signal for landing when the legs deployed. A second sent images to earth and a third took pictures on MARS. Antenna Sensors Shared Bus Computer 22 . Goldin visited the lab Wednesday. a day after two reports were released on the recent Mars fiasco. 3. All three tasks used the common shared bus for communication and the computer processor. The lander was last heard from Dec.'' he told employees of NASA's Jet Propulsion Laboratory.

Mars Explorer Resets Software Engineering Lessons 1. Send images 3.A software task dispatch conflict was the cause of the problem. 2. Build ‘fail-safe’ systems. . But because the data gathering went better tan expected there was more data to process than expected. It is similar to the deadlocks studied the database management systems or operating systems courses. that they would have found and fixed the fault before it became a failure. Sometimes you must release use the software for its intended use even though you have not been able to discover the cause of the anomaly. Send images There was a mismatch between priorities set in: • The hardware • The software • The software that controls the bus A watchdog counter rebooted the system after it had been inactive for some time. It is best to test to the breaking point. Gather data 3. The difference between the breaking point and the maximum design load is the system margin. by issuing an interrupt. 23 . The stress tests for the Mars Explorer were actually thought to be the worst case. Stress test beyond the limits established in the requirements. In these cases treat the release as ‘provisional’ and continue to work on 3. Design Defensively: The JPL team did this by leaving in the debug code and the fail safe resets. Explain all anomalies that show up during system test. Reboot 2. they were actually: 1. not a guarantee. This is why the probe was rebooting after being silent for too long. This resulted in the shared bus not being released. Case Study. Task CPU Bus Conflict 1 2 2 1 2 2 3 3 2 2 Conclusion Time This problem is a typical deadlock that can happen when access to a resource is not managed. This is a fail-safe system. Priorities should be: 1. Had testers pushed the system to its breaking point there is a good chance. Gather data But due to a faulty use of preemptive multithreading. Reboot 2.

They insist on having a plan to find and fix the fault before it becomes a failure to avoid sleepless nights. Finally there are the business functions. Boring projects are the best. Sometimes managers want to classify a problem as a ‘chance occurrence. etc. The usual real-world application of this is in financial applications or other business software. In the Mars mission.” Software Testing and Quality Management. By writing off the anomaly the NASA team shielded their management team from the risks.understanding the anomaly. Distributed computing is an emerging software architecture technology fraught with typical early technology problems. Simulate scenarios. which are responsible for client contact and client management via a range of distribution channels and media. Process scheduling algorithms need detailed analysis. communication 24 . But plans are worthless unless they change to meet newly discovered conditions. Hold architecture reviews and pay special attention to performance issues. panic and project bankruptcy. Once resets occur. Using a combination of application servers and software components is usually called distributed computing. the following types of business function can be identified: management functions such as Asset & Liability Management (ALM). Reference: Steve March. Volume 1. All shared resources must be understood and interaction must be analyzed. The Mars Explorer anomaly was thought to be a hardware problem even though there was no data supporting this belief. The hardware people were already blaming the software people for schedule delays and the software people rationalized that if there was a hardware problem it was not their job to find it. Of course. In any event NASA might choose to launch on schedule to meet the window of opportunity. The core of the bank consists of the operational functions. Issue 5. Naturally. They could call the launch ‘provisional’ because there was a known fault.com Financial Systems Architecture A computer running several software components is called an application server. and where transactions are executed. mortgages. Beware of those who thrive on the thrill of crises. Mars is close enough to Earth for the Explorer to have enough fuel to complete the trip is once a year. during system test.’ these are especially difficult times for the testers. All shared resources must be understood and interactions must be analyzed. operational management and strategic management. commercial management.) are taken out and managed. Process scheduling algorithms need detailed analysis. an alternate approach was to delay launch until the fault was found and fixed A management team will evaluate the risks and decide to ‘launch or hold’ with data about all potential problems. This philosophy moves teams from crises and to problem avoidance. September/October 1999. While the Explorer flew to Mars the JPL and NASA engineers might have worked to discover the reset problem in test labs well before it occurred on the planet. page 10 www. In a bank. even once.” Learning from Pathfinder’s Bumpy Start. developers must understand and solve them. In addition there are a number of innovating functions such as product and market development and support functions such as financial administration. So the testers faced the awesome responsibility of holding the mission for a year or explaining away an anomaly that occurred two or three times. in which financial contracts (such as those for saving. according to those contracts. The most difficult step to take in any project is to change the agreed to plan.stqemagazine.

if the bank decides to identify a 'business mortgage system' and a 'private mortgage system'. or as soon as the organization undergoes change. 25 . Dev.must be possible between all of these business functions. as two separate systems for either strategic or administrative reasons. Market Dev. Mngt. for example. auditing Cash mngt Fin. In other words. A contract system for medium-term notes (MTNs). Acquisition Distribution Mngt Client Mngt Trading Commercial Management Operational Management Service Innovation Prod. which together form a huge web. is common to both. financial administration ALM CM OM business mortgage mortgage bond/MTN private mortgage Figure: common application architecture A product-related layer in the architecture A product layer will reduce interactions by adding a level of indirection. adm. For example. countless links are required. Each banking product therefore can have its own product layer. All these systems have to be 'fed' by what goes on elsewhere in the bank. The cost may be in performance buy the benefit is in the clarity of the relations between components. namely the mortgage. despite the fact that their underlying product. Dev. must serve to keep other systems up to date about what has been laid down or changed in the contract. Figure: the usual business functions in a bank Separate systems may be developed for every component of banking business operation. Here is a view of the Business Processes for a typical bank: Strategic Management ALM Support Int. all knowledge and information relating to the nature of a single product is actually combined. This refactoring of the functions simplifies the architecture and subsequent implementation. This web immediately expands whenever a new product is added. In this product-related layer.

The components that reside in his layer reduce coupling and increase cohesion. 26 . Should they be small. Object class refactoring is an important development process that makes this possible. whereby a product will consist of a large number of small building blocks? Or should they be larger blocks such as a 'complete straight-line repayment lending construction. This knowledge resulted in the identification of at least two different components for principal amounts. The trick is to maximize the general nature of the component while minimizing the interactions with other components. The components are easiest to test if they have one entry point and one exit point. The underlying idea is that the speed for adding and altering products can be achieved by composing these products in their specification. Similarly there are two different building blocks for interest components. but in detail different constructions are required? The best size is a mixture of the two in the range of 1 to 10 function points. for principal amounts. In practice three or four iterations at the object class definitions with heavy constraints placed on the number of object classes is vital. Hatton points out hat this lowers defects and application engineers are not overwhelmed by a vast library of micro feature components. the situation may arise where the principal amount remains the same throughout the term (as is the case in an interest-only mortgage) or the principal amount becomes less throughout the term (as is the case in a linearly amortizing mortgage). entailing the risk that a large number of similar. For example. New components can be rapidly added and processes made up of these components can implement new features. A range of components are needed for principal amount and interest computation. Object classes specially defined for interface support are the most flexible.financial administration ALM CM OM Financial Product System business mortgage bond/ MTN private mortgage Figure: application architecture with a separate product layer Finding Simple Components A good architecture has clear product-related layer. Components need to be linearized in the sense that they only interface to other components through well defined structures. using such components. elementary building blocks such as a simple interest calculation (principal amount times term times percentage). Now let’s consider component size. for example an interest construction for daily-variable interest. including variable interest calculations'. or an interest construction for a rate-bounded system.

Example inventory of components term: principal amount: interest: principal amount settlement: interest settlement: interest calculation: etc. If this is impossible invest in extensive training including extra development iteration. the principal amount and the accrued interest are paid to the client. This TERMDEP: interval ** term formal specification lays out the components … of the system and their interaction. fixed end date fixed for the entire term fixed for the entire term to be carried out Architectural Process Again With a prospectus in hand the requirements phase of the project one-time. At the end of the term. Maximize the re-use of common modules within and across product lines. fixed start date. Partition the software into separate modules. On the basis of the prospectus and a colloquial language product DEPOSIT data: description a formal product requirements PA: amount ** principal amount specification is prepared. Modularize with welldefined interfaces to simplify testing and feature packaging.CASE Study Banking Components . daily method can begin. They are therefore able to determine … whether the product specification describes the intermediate data: product as precisely as they intend. 27 . Estimate performance. at a fixed. During this phase prototypes are used to understand and validate the requirements. It define TERMDEP as identifies which components are to be TERM using FIXED-TERM-BLOCK purchases or drawn from a product line library with SDTERM -> SD. Track module performance during the entire development cycle. . in arrears simple. Establish performance margins and manage to them. A first cut functional and physical architecture is synthesized to determine the feasibility of the A Component: project and understand its size. agreed interest percentage. Some guidelines for this synthesis are: • • • • Use operating system software and hardware familiar to the developers. Example problem description In a Fixed Time Deposit the client places with the bank a fixed amount (the principal amount) for a fixed term. This specification is SD: date ** start date readable by financial or other problem domain MD: date ** maturity date experts. and then measure it in the prototype. MDTERM -> MD of components and how they will work together.

and reporting system components will need to be added. Simplify the product by refactoring. but don’t even think about changing both the interfaces and the modules at the same time. They usually relate to changes in the Information Technology operating environment. strike it out. strike it out. Now the intense architecture and design phase begins. including network technology. when in doubt. changes in technological design can drive changes to the architecture. Understand and allow for levels of indirection that induce performance penalties to reduce development risk. A good architecture readily accommodates changes based on new or modified business functions. such as new database systems. when in doubt. Components are modules that are limited in size. or some of the components some of the time. Existing kernel objects or components may need to be expanded.• Minimize cross feature dependencies and create components from modules. and are bounded in time and space and interfaces that normalize data structures between components. • System and network software. An example is the supervision carried out by banking regulatory bodies or change in internal management or a more detailed method of cost allocation based on market value rather than book value. use single entry and exit points. A mantra for this approach is that: You can change some of the interfaces some of the time. The relationship between changes in reality and their impact on the system is summarized: 28 . • Storage technology in a database system or Storage Area Network • System development tools. These tools can be divided into the following categories: • Hardware. Furthermore. reusing existing components or most of all by taking Mark Twains advise on adjectives: “As to the adjective (requirement or feature). New components need to be added to the system configuration through a registration process. • • Isolate hardware and data structure dependencies from the logical functional modules. The four views of the ‘4+1’ model are synthesized and a set of independent use cases are created. A byproduct of this effort is the number of function points that comprise the project.” Twain As to adopting it to system features: As to the feature. The result is new information system requirements. have an explicit error recovery strategy.

by transferring products gradually from existing systems to the new system. When the EU-countries switched to one European currency (euro) in 1999. 29 . Case Study Implementation and advantages of Banking Architecture in practice In the 1990s banks observed that rapid developments in the financial world and within IT necessitated a review of the architecture of their software systems. The new bank adopted the new partially featured system. . One placed the emphasis on the need to correctly register the various financial products according to type of product and to prepare accurate risk and accounting reports. The concept of a system-of -systems that communicate with each other in the form of messages was implemented successfully through the new architecture.Change in reality Typical system changes p o r sy tin g co ste m m R p e on g is en tr t sy ati o co ste n m m p o n en O ve t ra ll im p ac t el o rn b je ct Frequency 0 ++ Reason external objectiv e external requirements internal management structure Information Technology K e R e 0 ++ 0 (+) 0 (+) ++ ++ ++ + (+) ++ 0 + + (+) ++ 0 = no or little change (+) = possible change + = some change ++ = major change A good architecture anticipates these changes so that the more frequently occurring changes have lower impact than those occurring less frequently. While development was underway a bank merger occurred. the banks quickly adapted contracts in pre-euro currencies to contracts in euros (whereby the customer could choose the moment of conversion for each contract separately). derivatives and bond portfolios. This considerably boosted the quality of information provision to the financial administration and the risk management departments: it was more manageable. treasury front-office systems and reporting systems were connected to the new system. which was expanded intermittently with a group of new specific applications. This showed that new applications can be quickly added and incorporated into the new architecture. Implementation was done in phases. The frequent changes in hardware and software technology led to layered architectures so that the changes can be shielded from the applications and the users. verifiable and reliable. It was linked to front-office systems and other reporting systems. In subsequent years. It contained interest-related contracts. For each application a few new methods were added to the specification and the product kernel component was recompiled and loaded.

Updates to these calculations now will take place uniformly. thanks to the consistency of the information. The emphasis was the introduction of the application components within the existing architecture. The assignment was to link up with many payment-oriented legacy systems for a wide variety of savings applications. with premiums. The initial situation here was entirely different. brackets and levels. This architecture was implemented at the savings division of a large retail bank. The flexibility 30 . but also for the savings components of mortgage constructions. Application Control interface data Management data Printing-information interface data Legacy Systems Financial Administration FA Account data End-users Client.and contract-data Account Admin Calculating & Message Component Kernels interface data interface data interface data interface data Balance-updates interface data Figure: Savings applications of large retail bank The direct benefit is that the kernels contain all rules for the application products in one place. The environment would need to be adapted further at a later stage. The system had to offer support for the flexible and rapid introduction of new savings products. the central component containing balance and interest calculations needed to be replaced by a new system. The 'account concept' remained primary: a withdrawal or deposit is first registered in the account system and then reported to applications. which included communication with the network of local branches. Messages from the applications had to maintain their existing interfaces so that the incoming and outgoing interfaces could maintain their batch character. Financial Product-related calculations were removed from the reporting systems and specified calculation rules in the kernel calculations are used for the reports.The user departments are pleased with the improvement in the quality and consistency of the information in the reporting systems. the balance and interest calculations of the current account system such as interest calculation and overdraft identification were centralized into a core kernel. the back-offices are 'relieved' of many reconciliation problems. Although front-office staffs have their own dedicated applications. Within an existing environment. In parallel.

Garlan & M. Merritt. new components may be required and their development will slow the development process. and Methods. MA. F. evaluated. By doing this. Lessons Learned The benefits offered by integrated software architecture go beyond the ‘sum of the parts. ten existing applications were upgraded and two new retail savings applications were added. Van Nostrand Reinhold. 1. Shortly after the implementation this time-consuming and errorprone procedure was replaced by an application program. (1993). Rick. Vol.” Addison-Wesley. which directly used information methods from the kernels. Witt. Baker and E. D. . T. and Kazman. “An Introduction to Software Architecture. Len. During this time the new infrastructure was designed. Careful domain analysis ensures realistic scheduling. Component may be developed or purchased for the money market and capital market business units and for retail front office offerings of credit. The architecture ensures that the prototype applications created fit into its environment immediately. ISBN 0-201-19930-0 31 . I. November 6-11. World Scientific Publishing Co. Shaw. References 1. When a new domain is entered. Paul. developed and embedded quickly. B. thus guaranteeing the same calculation rules to be applied in that front-office as in the back-office. 2. New-York (1994) 324p. at the counters of the local branches calculations of balances and accrued interest were performed manually. These demands were met The first phase lasted twenty months. Krutchen 4+1 Systems. Previously. a uniform handling of product-rules could be enabled and enforced throughout the bank. The challenge was to handle the more than one million accounts and more than 60 million payment transactions a year without degrading performance while changing the applications. using financial kernel components as building blocks. Models. “Software Architecture in Practice.’ Specifications for new or modified financial products may be specified in financial terms. it will quickly become clear which components overlap and which are reusable. . Baltimore. A formal development phase is needed because generating from a specification language of results in software so inefficient that it is not tolerated by users. W. Clements. savings and payment services. Automatic software generation is then possible for quick creation of a prototype. 2. The architecture's flexibility quickly proved useful. Bass. When products are specified within the same domain.introduced could be used in the future to provide on-line information to front office staff on the phone with the customer or to web based applications. Software Architecture and Design— Principles. This architecture let the bank introduce new financial products and product variations to the market quickly. 1994.” Proceedings of the TRI-Ada ’94 Conference. Careful domain analysis and component purchases can help prevent unnecessary delays and ensure that the scheduling is realistic.” Advances in Software Engineering and Knowledge Engineering. ACM. 1998. Applications can be specified.

Cleeland.” Harvard Business Review. and Ferguson. David. Shaw. Seattle. IEEE Comm.” Object Magazine. IEEE CS Press. B.1968 Software components (routines). 4-6. Lenzi. Simon & Schuster. Mary and Garlan. Christina. Applying Patterns to Develop Extensible ORB Middleware..D. “On the Definition of Software System Architecture. IEEE Software. May 2001 Arnold. A. no. NJ 1996.Buschmann. generality and time-space performance. software houses. Daniel C. Charles R. 1991. March-April 1993.lack the breadth of interest or coherence 32 . Existing sources of components . Wirsing (editor). Ahmed. vol.” John Wiley & Sons. Communications of the ACM.44 n.R. Clark. Frank et al. Management of Telecommunication Systems and Services. 6. Los Angeles. Morris.107. by M.. Bradford. “Conduit and Content. Calif. 86-94.” Center for Software Engineering. An Algebraic Specification of a Language for Describing Financial Products.Agha.C. November 1995. p. Proceedings of the ICSE-17 Workshop on Formal Methods Applications. Marie. New York. Schmidt and C. users’ groups and algorithm collections . England.5. Barry. and M. Inc.99. Chichester. Abd-allah. v. USA NATO SCIENCE COMMITTEE Garmisch. pp.T. ISBN 3-540-61578-4. Charles H. robustness. van Deursen. to be widely applicable to different machines and users. Germany. Software Engineering Practice. No. [7] D.. April 1995. Software Architecture: Perspectives on an Emerging Discipline. “How Architecture Wins Technology Wars. New Jersey. University of Southern California. 12. McIlroy Bell Telephone Laboratories. Sturman and Gul A. [8] Mark Astley. Customizable middleware for modular distributed software. 54–63. ISBN 0-13-182957-2. Los Alamitos. 7 to 11 October . 1999. October 1996. Vol. Magazine. 37. Hall. 1996. in M. “A System of Patterns. pp. and Boehm. 4. Res (1995). pages 6-13. should be available in families arranged according to precision. ICSE 17 Software Architecture Workshop. Entire issue devoted to architectural questions and new developments. April 1995. CA 90089-0781. pp. Jane (ed). ISBN 0-471-95869-7 Gacek. Springer.manufacturers.

I shall also argue that a components industry could be immensely useful. I intend to elaborate this outline a little. is unknown as a legitimate branch of software. but I suspect that the very name ‘software components’ has probably already conjured up for you an idea of how the industry could operate.’ my emphasis is on ‘techniques’ and not on mass production plain. Of course mass production. In the phrase ‘mass production techniques.of purpose to assemble more than one or two members of such families.systems to the exclusion of almost all other considerations. When we undertake to write a compiler. yet software production in the large would be enormously helped by the availability of spectra of high quality routines. We have enough experience to perceive the outline of such a subindustry. dignified as a hardware field. The idea of subassemblies carries over directly and is well exploited. Finally I shall raise the question of starting up a ‘pilot plant’ for software components. much less catalogues of standard parts. quite as mechanical design is abetted by the existence of families of structural shapes. The idea of machine tools has an analogue in assembly programs and compilers. screws or resistors. and would like to investigate the prospects for mass-production techniques in software. The talk will examine the kinds of variability necessary in software components.’ Not. The pinnacle of software is systems . ruggedness. But certain ideas from industrial technique I claim are relevant. I think its proper place is considerably higher. Yet this fragile analogy is belied when we seek for analogues of other tangible symbols of mass production. we begin by saying ‘What table mechanism shall we build. in the sense of limitless replication of a prototype. capacity. Software Components My thesis is that the software industry is weakly founded. and methods of instituting pilot production. The most important characteristic of a software components industry is that it will offer families of routines for any given job. types of components that are ripe for such standardization. We undoubtedly get the short end of the stick in confrontations with hardware people because they are the industrialists and we are the crofters. ways of producing useful inventories. and suggest why it hasn’t materialized. ‘What mechanism shall we use? but ‘What mechanism shall we build?' I claim we have done enough of this to start taking such things off the shelf.’ and is fitfully respected. precision or character set. and that one aspect of this weakness is the absence of a software components subindustry. The idea of interchangeable parts corresponds roughly to our term ‘modularity. One may not order parts to individual specifications of size. No user of a particular member of a family should 33 . is trivial for software. Software production today appears in the scale of industrialization somewhere below the more backward construction industries. speed. The Software Industry is Not Industrialized We undoubtedly produce software by backward techniques. There do not exist manufacturers of standard parts. Components.

the purchaser of a component from a family will choose one tailored to his exact needs. 5 ranges and 5 robustnesses.g. which is perhaps difficult to implement. He will consult a catalogue offering routines in varying degrees of precision. We have here 10 precisions. Another dimension of variability.ranging from no argument validation through signalling of complete loss of significance. In other words. In addition one might expect a complete catalogue to include a measurement-standard sine routine. and therewith consider it done. and generality./2 to /2. he should be able safely to regard components as black boxes. He will expect families of routines to be constructed on rational principles so that families fit together as building blocks. robustness. as it caters for very detailed needs is Time-space trade-off by table lookup. which would deliver (at a price) a result of any accuracy specified at run time. In short./2. This gives us a basic inventory of 300 sine routines. He will be confident that each routine in the family is of high quality .. -big to +big Robustness . adjustable in several ‘subdimensions' (a) Table size (b) Quantization of inputs (e. in size 500 x 8. the inputs are known to be integral numbers of degrees) Another possibility is (c) Taking advantage of known properties of expected input sequences. for example profiting from the occurrence of successive calls for sine and cosine of the same argument. for which perhaps ten different approximating functions might suffice Floating-vs-fixed computation Argument ranges 0. 0-2 . without incurring extreme costs. Thus the builder of an assembler will be able to say I will use a String Associates A4 symbol table.reliable and efficient. . in unwanted generality. time-space performance.to . As a bonus he may later experiment with alternatives to this choice. How many should a standard catalogue offer? Off hand one thinks of several dimensions along which we wish to have variability: Precision. to signalling of specified range violations. He will expect the routine to be intelligible. The last range option and the last robustness option are actually arbitrary parameters specifiable by the user. though not necessarily instantly compilable in any processor he has for his machine. 34 .pay a penalty. doubtless expressed in a higher level language appropriate to the purpose of the component. 2 scalings. also . A Familiar Example Consider the lowly sine routine. for the fact that he is employing a standard model routine.

Sysgen differs. Various editing and binding techniques are possible for inserting or deleting code pertinent to each degree of robustness. but rather by excision. not producing components for application to one specific system. Second. from an intentionally fat model. Sysgen is not intended to reduce object code or running time. yet that would not justify discarding the fixed point option. Fortunately the cost of offering such an ‘inventory’ need not be nearly 300 times the cost of keeping one routine. but it is more popular in theory than in the field. First. Just about the only applications of multiple binding times I can think of are sort generators and the so-called ‘Sysgen’ types of application: filling in parameters at the time routines are compiled to control table sizes. Perhaps only the floating-vs-fixed dichotomy would actually necessitate fundamentally different routines. Parameterized Families of Components One phrase contains much of the secret of making families of software components: ‘binding time. though. The best known of these.software houses have set themselves up as experts on this job. but it can’t adjust the width of list link fields in proportion to the size of the list space. A components industry on the other hand. Going back to the sine routine. and would have to provide routines whose niches in a system were less clearly delineated. for that could well throw away a large part of the business in distinct tailor-mane routines for myriads of small process-control and other real-time applications on all sorts of different hardware. The example of the sine routine reemphasizes an interesting fact about this business. 35 . It is safe to assert that almost all sines are computed in floating point these days.’ or ‘sizes’ rather than multiplicity of replicates of each. IBMs OS/360 Sysgen is indeed elaborate . would have to be flexible in more dimensions. Typically Sysgen provides for the presetting of defaults. For example it can allocate differing amounts of space to a compiler. ‘Mass production’ of software means multiplicity of what manufacturing industry would call ‘models. I can’t imagine some of their catalogue items ever being ordered. Automated techniques exist for generating approximations of different degrees of precision. even though a customer might guarantee he’d never use it were it indeed profitable to refrain. The entire run-time apparatus for interrogating and executing options is still there. The types of adjustment in Sysgen are fairly limited. in a couple of ways from what I have in mind as the way a software components industry might operate. such as whether object code listings are or are not standard output from a compiler. Thus it seems that the basic inventory would not be hard to create. this is somewhat like building a low precision routine by computing in high precision and then carefully throwing away the less significant bits.’ This is an ‘in’ phrase this year. and to some extent to control choice among several bodies of code.A company setting out to write 300 sine routines one at a time and hoping to recoup on volume sales would certainly go broke. Sysgen creates systems not by construction.

this choice must usually be decided on the basis of folklore. 36 . One might call these early-bound parameters ‘sale time’ parameters. Taken in a generalized sense precision includes things like width of characters. I hasten to add that in spirit it is almost the only way a successful components industry could operate. Call an error handler d. To purvey a rational spectrum of high quality components a fabricator would have to systemize his production. The exact tradeoff between reliability and compactness in space and time can strongly affect the performance of a system. the addressing capabilities of his hardware. Choice of Interfaces. as exemplified by those in the CACM. One could not stock 300 sine routines unless they were all in some sense instances of just a few models. For non-numerical routines. Choice of Time-space behavior. these different styles of communicating error outputs should be available: a. Routines that use several inputs and yield several outputs should come in a variety of interface styles. Signal (in the sense of PL/1) Another example of interface variability is that the dimensions of matrix parameters should be receivable in ways characteristic of several major programming languages. this choice is quite well catered for already. Choice of Generality. The degree to which parameters are left adjustable at run time. Choice of Algorithm. Different storage accessing disciplines should be supported. in which all but a few parameters were intended to be permanently bound before run time. a wide choice is perhaps even more imperative for them. In numerical routines. Choice of Accessing method. so that a customer could choose that best fitting his requirements in speed and space. This aspect of parameterization and the next will probably rank first in importance to customers. There will be at least: Choice of Precision. Choice of Robustness. highly parameterized. Error code return c. or his taste in programming style. For example. and size of address or pointer fields. As some non-numerical algorithms are often spectacularly unsuitable for particular hardware. however.Having shown that Sysgen isn’t the exact pattern for a components industry. Many of the parameters of a basic software component will be qualitatively different from the parameters of routines we know to-day. Alternate returns b.

Applications of this sort are going on a very wide class of machines. One can easily list a few dozen fundamental routines for geometry. More promising components to begin with are these: Numerical approximation routines. Despite advertisements to the effect that whole compilers are available on a ‘virtually off-the-shelf’ basis. several algorithms may be required. The basic pieces here are radix conversion routines. incidence matrix and list representations for graphs).Choice of Data structures. but they can be just as well taken from the CACM. . When radically different structures are useful for similar problems (e. The variability here. Input-output conversion. topology. Two and three dimensional geometry. The principle of variable binding times could be very fruitfully exploited here. etc. and today are usually kept proprietary. and format crackers. Among the corpus of routines in this area would be dictionary builders and lookup routines. scanners. These might be sold by a components industry for completeness’ sake. such as matrix inversion routines. this delicate matter requires careful planning so that algorithms be as insensitive to changes of data structure as possible. Text processing. are simply logical patterns for sequencing that are almost devoid of variability. for instance are still matters for research. Certain other numerical processes aren’t such good candidates. surfaces. root finders and differential equation routines.g.. 37 . and under access nodes suitable to various hardware. and output synthesizers. Already touched upon under the topic of interfaces. Depending on which aspect of geometrical figures is considered fundamental — points. on unit records. and also be insensitive to concrete structures. Still other ‘numerical’ processes. Nobody uses anybody else’s general parsers or scanners today.quite different routines will be required. especially in the matter of accuracy and robustness is substantial. not mass production. all capable of working on continuous streams. and the dimensions of variability for these routines are also quite clear. From a well-designed collection of families it should be possible to fabricate anything from a simple on-line octal package for a small laboratory computer to a Fortran IV conversion package. These are very well understood. Application Areas We have to begin by thinking small. A complete line ought to cater for different abstract structures. partly because a routine general enough to fulfil any particular individual needs probably has so much generality as to be inefficient. I don’t think we are ready to make software sub-assemblies of that size on a production basis. Considerable planning will evidently be needed to get sufficient flexibility without having too many basically different routines. some trivial scanning routines. and various linked list formats. The sticky dimension of variability here is in data structures.

and have then been written by hacks. All need assemblers and could use macro-processors. Nevertheless storage management is so important. who would be able to use tried parts for all the more commonplace parts of their systems. which have been specified by experts.Storage management. a tremendous amount of similar software must be written for each. Present Day Suppliers You may ask. Bell Laboratories is not typical of computer users. Needless to say much of this support programming is done sub-optimally. and at a severe scientific penalty of diverting the machine's owners from their central investigations. as it would become possible to expend proportionally more effort on critical parts of systems. though not necessarily compiling on the same hardware. Even though many are dedicated to special applications. As a research and development establishment. I have intended to described the market in microcosm. All need input-output conversion. At Bell Telephone Laboratories we have about 100 general purpose machines from a dozen manufacturers. and less using them than does a production computing shop. The Market Coming from one of the larger sophisticated users of machines. Many need basic numerical routines or sequence generators. The biggest customers of all would be the manufacturers. especially for text manipulation. (Were they not it would be a sure sign that the offered products weren’t good enough. some full-blown Fortran style I/O. and also to avoid the now prevalent failings of the more mundane parts of systems. one ought to do considerable comparison of known schemes working in practical environments. sometimes only single alphabetic characters and octal numbers. that it should be an early candidate. it must perforce spend more of its time sharpening its tools. about which not enough real knowledge yet exists. Most want speed at all costs. Were it possible quickly and confidently to avail our-selves of the best there is in support algorithms. But it is exactly such a systems-oriented market toward which a components industry would be directed. To construct these systems of high-class componentry we would have to surround each of some 50 machines with a permanent coterie of software specialists. I have ample opportunity to see the tragic waste of current software writing techniques. a team of soft-ware consultants would be able to guide scientists towards rapid and improved solutions to the more mundane support problems of their personal systems. Before constructing a product line for this application. a few want considerable robustness.) The ultimate consumer of systems based on components ought to see considerably improved re-liability and performance. The market would consist of specialists in system building. Dynamic storage allocation is a popular topic for publication. In describing the way Bell Laboratories might use software components. well don’t we have exactly what I’ve been calling for already in several places? What about the CACM collected algorithms? What about users groups? What 38 .

As we heard yesterday manufacturers tend to be rather pragmatic in their choice of methods. and I will spare you a harangue on their deficiencies. such as Fortran compilers. They strike largely reasonable balances between generality and specificity and seldom use absolutely inappropriate approaches in any individual software component. The manufacturers produce unbelievable amounts of software. They fit into no plan. variability can only be provided by expensive run time parameters. they achieve refereeability. So we see the software houses purveying systems. Generally. in a limited field. Our purveyor of 300 sine routines would probably go broke waiting for customers if that’s all he offered. their work must be financed. The CACM algorithms. but they suffer some strong deficiencies. as an adjunct of a learned society. perhaps come closer to being a generally available off-the-shelf product than do the commercial products. Second. linear programming packages or flowcharters. But the profit motive wherefrom springs these virtues also begets their prime hangup . Software houses generally do not have the resources to develop their own product lines. nor do I think it likely that any of them will actually evolve to fill the need. I do not expect to see any software house advertising a family of Bessel functions or symbol tabling routines in the predictable future. and large financing can usually only be obtained for large products. There is some critical size to which the industry must attain before it becomes useful. a good conservative grey. Out of these treadmills I don’t expect to see high class components of general utility appear. that doesn’t include the best routine for anything. First they are an in-gathering of personal contributions. but must perforce completely avoid algorithms for which Algol is unsuited or else use circumlocutions so abominable that the product can only be regarded as a toy. The system comes first.about software houses? And what about manufacturers’ enormous software packages? None of these sources caters exactly for the purpose I have in mind. the CACM algorithms section can not deal in large numbers of variants of the same algorithm. Third. by being effectively bound to a single compilable language. for the editor can only publish that which the authors volunteer. as this is the stuff that gets used most heavily it is all pretty reliable. User’s groups I think can be dismissed summarily.systems now. often stylistically varied. but that is better than the average progranmier is likely to make. just as an electronics firm selling circuit modules for only one purpose would 39 . A Components Factory Having shown that it is unlikely to be born among the traditional suppliers of software I turn now to the question of just how a components industry might get started. components are merely annoying incidentals. or very big programs.

but certainly without expectation of immediate payoff The industrial orientation of a pilot plant must be constantly borne in mind.have trouble in the market. but the guiding spirit of the undertaking must be production oriented. managers could estimate the clarity of the product. which is important in predicting customer acceptance. These routines should be shown to be useable as replacements in a number of radically different environments. Testing will have to be done in several ways. Distribution will be a ticklish problem. The personnel of a pilot plant should look like the personnel on many big software projects. Product test will involve transliterating the routines to fit in representative hardware. Even before founding a pilot plant. because the level of programming here will be more abstract: Much of the work will be in creating generators of routines rather than in making the routines themselves. This demonstration could be undertaken by a governmental agency. cataloguing. Very good planning. There will be perhaps more research flavor included than might be on an ordinary software project. a research contractor. and during that time money and talent will be needed. One instantly thinks of distribution by communication link. Research-calibre talent will be needed to do the job with satisfactory economy and reliability. Each member of a family will doubtless be tested against some very general model to assure that same-time binding causes no degradation over run-time binding. By monitoring the ease with which fairly junior people do product test. one would be wise to have demonstrated techniques for creating a parameterized family of routines for a couple of familiar purposes. say a sine routine and a Fortran I/O module. or by a big user. The first source of support that comes to mind is governmental. Distribution. and rational planning of the mix of product families will in the long run be more important to the success of the venture than will be the purely technical achievement. and strongly productminded supervision will be needed. It seems that the fact that government is the biggest user and owner of machines should provide sufficient incentive for such an undertaking that has promise for making an across-the-board improvement in systems development. The catalogue will be equally important. Then even very small components might be profitably marketed. The ability to produce members of a family is not enough. I think that the whole project is an improbable one for university research. with the masses of coders removed. perhaps channeled through semi-independent research corporations. Quick delivery may well be a components purveyor’s most valuable sales stimulant. A comprehensive and physically condensed document like the Sears-Roebuck catalogue is what I would like to have for my own were 40 . It will take some time to develop a useful inventory.

timespace performance. I would expect software houses to take over the industry. for example popular word sizes and character sets. I do not want the routine to be inherently inefficient due to being expressed in machine independent terms. size limits. without too much pain. with programming terms substituted for some of the more mechanically oriented terms appropriate to mass production. Quite soon one would expect a components industry to converge on a few standard types of interface. but again unless the standards encompass the bulk of software systems (as distinguished from users). provided they are loose enough not to prevent useful modes of computation. if not overdue. the components industry will die for lack of market. Ian Hugo (Scientific Secretary) . Summary I would like to see components become a dignified branch of software engineering. classified by precision. Indeed.left . for this approach. so that two similar routines should be available with similar options and two options of the same routine should be inter-changeable in situations indifferent to that option. I want the different types of routine in the catalogue that are similar in purpose to be engineered uniformly. were outside support long needed. This white paper was scanned in from hard copy provided by Ian Hugo who was one of the two Scientific Secretaries at the 1968 NATO conference. I would say the venture had failed (and try to forget I had ever proposed it). Language standards. I want to have confidence in the quality of the routines. but I do insist that transliteration be essentially direct. Experience will doubtless reveal other standards to be helpful. it would be rash to standardise before we have the models.and Peter Naur (Co-editor) working on the 1968 NATO Software Engineering Confeence report << other White Papers top of page 41 . I think there are considerable areas of software ready. will of course be helpful. I do not insist that I be able to compile a particular routine directly. Touching on Standards I don’t think a components industry can be standardized into existence. and binding time of parameters.I purchasing components. I would like to see standard catalogues of routines. Once a corpus of product lines became established and profit potential demonstrated. As is usual with standards. What I have just asked for is simply industrialism. robustness. The conference report editors were Peter Naur and Brian Randell. I would like to apply routines in the catalogue to any one of a large class of often quite different machines.

42 .

Sign up to vote on this title
UsefulNot useful