受到某些培训机构影响，架构师考试的专业英语的5分，不少人都是放弃，碰运气。笔者英语过了六级，在500强外企也混过，对于这一块还是有一些信心的。但是几年真题刷下来，笔者发现专业英语考的是对于教材的熟悉程度，对于英语本身要求并不高。

在Google Books的帮助下，笔者发现很多题目是出于有限的几本英文教材。下面简单列一下这些教材和题目（最后还有一道案例题中的英语）。

System Analysis & Design 5e 2013           Dennis

2019综合 71-75

P246

Normalization, the process whereby a series of rules is applied to the logical data model to determine how well formed it is, is described in the Chapter 6 Appendix. A logical data model is in first normal form (1NF) if it does not contain repeating attributes, which are attributes that capture multiple values for a single instance. Second normal form (2NF) requires that all entities are in 1NF and contain only attributes whose values are dependent on the whole identifier (i.e., no partial dependency). Third normal form (3NF) occurs when a model is in both 1NF and 2NF and none of the resulting attributes is dependent on nonidentifier attributes (i.e., no transitive dependency). With each violation, additional entities should be created to remove the repeating attributes or improper dependencies from the existing entities. Finally, ERDs should be balanced with the data flow diagrams (DFDs)—which were presented in Chapter 5—by making sure that data model entities and attributes correspond to data stores and data flows on the process model. The CRUD matrix is a valuable tool to use when balancing process and data models.

2018综合 71-75

P406-412

DATA STORAGE FORMATS

There are two main types of data storage formats: files and databases. Files are electronic lists of data that have been optimized to perform a particular transaction. For example, Figure 11-1 shows a patient appointment file with information about patient’s appointments, in the form in which it is used, so that the information can be accessed and processed quickly by the system.

……

Master files store core information that is important to the business and, more specifically, to the application, such as order information or customer mailing information. They usually are kept for long periods, and new records are appended to the end of the file as new orders or new customers are captured by the system. If changes need to be made to existing records, programs must be written to update the old information.

Look-up files contain static values, such as a list of valid codes or the names of the U.S. states. Typically, the list is used for validation. For example, if a customer’s mailing address is entered into a master file, the state name is validated against a look-up file that contains U.S. states to make sure that the value was entered correctly.

A transaction file holds information that can be used to update a master file. The transaction file can be destroyed after changes are added, or the file may be saved in case the transactions need to be accessed again in the future. Customer address changes, for one, would be stored in a transaction file until a program is run that updates the customer address master file with the new information.

For control purposes, a company might need to store information about how data changes over time. For example, as human resources clerks change employee salaries in a human resources system, the system should record the person who made the changes to the salary amount, the date, and the actual change that was made. An audit file records “before” and “after” images of data as the data are altered, so that an audit can be performed if the integrity of the data is questioned.

The name legacy database is given to those databases which are based on older, sometimes outdated technology that is seldom used to develop new applications; however, you may come across them when maintaining or migrating from systems that already exist within your organization. Two examples of legacy databases include hierarchical databases and network databases. Hierarchical databases (e.g., IDMS) use hierarchies, or inverted trees, to represent relationships (similar to the one-to-many [1:M] relationships described in Chapter 6). Hierarchical databases are known for rapid search capabilities and were used in the early systems in the airline industry.

Hierarchical databases cannot efficiently represent many-to-many (M:N) relationships or nonhierarchical associations—a major drawback—so network databases were developed to address this limitation (and others) of hierarchical technology. Network databases (e.g., IDMS/R, DBMS 10) are collections of records that are related to each other through pointers. Basically, a record is a member in one or more sets, and the pointers link the members in a set together (Figure 11-4).

Most relational database management systems (RDBMSs) support referential integrity, or the idea of ensuring that values linking the tables together through the primary and foreign keys are valid and correctly synchronized.

2017综合 71-75

P290-299

The architecture design specifies the overall architecture and the placement of software and hardware that will be used. Architecture design is very complex process that is often left to experienced architecture designers and consultants, but we will give a sense of the process here.

……

Creating an architecture design begins with the nonfunctional requirements. The first step is to refine the nonfunctional requirements into more detailed requirements that are then employed to help select the architecture to be used (server-based, client-based, or client–server) and the software components to be placed on each device. In a client–server architecture, one also has to decide whether to use a two-tier, three-tier, or n-tier architecture. Then the nonfunctional requirements and the architecture design are used to develop the hardware and software specification.

There are four primary types of nonfunctional requirements that can be important in designing the architecture:

• Operational requirements specify the operating environment(s) in which the system must perform and how those may change over time.

• Performance requirements focus on performance issues such as response time, capacity, and reliability.

• Security requirements - Security is the ability to protect the information system from disruption and data loss, whether caused by an intentional act (e.g., a hacker or a terrorist attack) or a random event (e.g., disk failure, tornado).

• Cultural and political requirements are specific to the countries in which the system will be used.

2015, 2016综合(题目相同) 71-75

P283

ELEMENTS OF AN ARCHITECTURE DESIGN

The objective of architecture design is to determine how the software components of the information system will be assigned to the hardware devices of the system. In this section, we first discuss the major functions of the software to understand how the software can be divided into different parts. Then we briefly discuss the major types of hardware onto which the software can be placed. Although there are numerous ways in which the software components can be placed on the hardware components, the most common architecture is the client–server architecture, so we focus on it here.

Architectural Components

The major architectural components of any system are the software and the hardware. The major software components of the system being developed have to be identified and then allocated to the various  hardware components on which the system will operate. Each of these components can be combined in a variety of different ways.

All software systems can be divided into four basic functions. The first is data storage. Most information systems require data to be stored and retrieved, whether a small file, such as a list of lawn chemicals that are no longer authorized for residential applications, or a large database that stores an organization’s human resources records. These are the data entities documented in ERDs. The second function is the data access logic: the processing required to access data, often meaning database queries in Structured Query Language (SQL). The third function is the application logic: the logic documented in the DFDs, use cases, and functional requirements. The fourth function is the presentation logic: the display of information to the user and the acceptance of the user’s commands (the user interface). These four functions (data storage, data access logic, application logic, and presentation logic) are the basic building blocks of any information system.

The three primary hardware components of a system are client computers, servers, and the network that connects them. Client computers are the input–output devices employed by the user and are usually desktop or laptop computers, but can also be handheld devices, smartphones, special-purpose terminals, and so on. Servers typically are larger multi-user computers used to store software and data that can be accessed by anyone who has permission. The network that connects the computers can vary in speed from slow cell phones or modem connections that must be dialed, to medium-speed always-on frame relay networks, to fast always-on broadband connections such as cable modem, DSL, or T1 circuits, to high-speed always-on Ethernet, T3, or ATM circuits.

Software Architecture in Practice 3e 2013      Len Bass

2014综合 71-75

Second Edition

P234

Information Extraction

Information extraction involves analyzing a system's existing design and implementation artifacts to construct a model of it. The result is a set of information placed in a database,which is used in the view fusion activity to construct a view of the system.

P236

Database Construction

The extracted information is converted into a standard format for storage in a database during database construction.

When the data is entered into the database, two additional tables are generated: elements and relationships. These list the extracted elements and relationships, respectively.

P239

View Fusion

View fusion involves defining and manipulating extracted information (now stored in a database) to reconcile,augment,and establish connections between the elements. Different forms of extraction should provide complementary information. Fusion is illustrated using the examples given in the following sections.

P241

Reconstruction

At this point, the view information has been extracted, stored, and refined or augmented to improve its quality.The reconstruction operates on views to reveal broad,coarse-grained insights into the architecture. Reconstruction consists of two primary activities: visualization and interaction and pattern definition and recognition. Each is discussed next.

Visualization and interaction provides a mechanism by which the user may interactively visualize, explore, and manipulate views. In Dali,views are presented to the user as a hierarchically decomposed graph of elements and relations,using the Rigi tool.An example of an architectural view is shown in Figure 10.6.

Pattern definition and recognition provides facilities for architectural reconstruction: the definition and recognition of the code manifestation of architectural patterns.Dali's reconstruction facilities,for example, allow a user to construct

2013综合 71-75

Third Edition p28

System architecture

A system’s architecture is a representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and a concern for the human interaction with these components. That is, system architecture is concerned with a total system, including hardware, software, and humans.

P31

Three Kinds of Structures

As we saw in the previous section, architectural structures can be divided into three major categories, depending on the broad nature of the elements they show. These correspond to the three broad kinds of decisions that architectural design involves:

1. Module structures embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed or procured. In any module structure, the elements are modules of some kind (perhaps classes, or layers, or merely divisions of functionality, all of which are units of implementation). Modules represent a static way of considering the system. Modules are assigned areas of functional responsibility; there is less emphasis in these structures on how the resulting software manifests itself at runtime.

2. Component-and-connector structures embody decisions as to how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors). In these structures, the elements are runtime components (which are the principal units of computation and could be services, peers, clients, servers, filters, or many other types of runtime elements) and connectors (which are the communication vehicles among components, such as call-return, process synchronization operators, pipes, or others).

3. Allocation structures embody decisions as to how the system will relate to nonsoftware structures in its environment (such as CPUs, file systems, networks, development teams, etc.). These structures show the relationship between the software elements and elements in one or more external environments in which the software is created and executed.

Systems analysis and design methods      By Jeffrey Whitten, Lonnie D. Bentley · 2007

2012综合 71-75

P495

Examples of distributed RDBMSs include Oracle Corporation's Oracle, IBM's DB2 Universal Database family, Microsoft's SQL Server; and Sybase Corporation's Sybase. Most RDBMSs support two types of distributed data:

• Data partitioning truly distributes rows and columns to specific database servers with little or no duplication between servers.Different columns can be assigned to different database servers (vertical partitioning) or different rows in a table can be allocated to different database servers (borizontal partitioning).

• Data replication duplicates some or all tables (rows and columns) on more than one database server.Entire tables can be duplicated on some database servers,while subsets of rows in a table can be duplicated to other database servers.The RDBMS with replication technology not only controls access to and management of each database server database but also propagates updates on one database server to any other database server where the data is duplicated.

P505

The Network Architecture

The first physical DFD to be drawn is the network architecture DFD. A network arcbitecture DFDis a physical data flow diagrm that allocates processors (clients and servers) and devices (e.g., machines and robots) to a network and establishes (1) the connectivity between the clients and the servers and (2) where users will interact with the processors (usually only the clients).

2011 71-75

P453

Systems Design for In-House Development一The "Build" Solution

Let's begin by placing systems design for in-house development projects into context relative to the system life cycle. As is illustrated in Figure 12-5, an approved system proposal from the decision analysis phase triggers the design phase….

Task 5.1—Design the Application Architecture

The purpose of this first design task is to specify an application architecture. An application architecture defines the technologies to be used by (and used to build) one, more, or all information systems in terms of their data, processes, interfaces, and network components.

Task 5.2—Design the System Database(s)

Typically the next system design task is to develop the corresponding database design specifications. The design of data goes far beyond the simple layout of records. Databases are a shared resource. Many programs will typically use them. Future programs may use databases in ways not originally envisioned. Consequently, the designer must be especially attentive to designing databases that are adaptable to future requirements and expansion.

Task 5.3—Design the System Interface

Once the database has been designed and possibly a prototype built, the systems designer can work closely with system users to develop input, output, and dialogue specifications…

Transaction outputs will frequently be designed as preprinted forms onto which transaction details will be printed. Reports and other outputs are usually printed directly onto paper or displayed on a terminal screen. The precise format and layout of the outputs must be specified. Finally, internal controls must be specified to ensure that the outputs are not lost, misrouted, misused, or incomplete.

Task 5.4—Package Design Specifications

This final design task involves packaging all the specifications from the previous design tasks into a set of specifications that will guide the computer programmer's activities during the construction phase of the systems development methodology.

Task 5.5—Update the Project Plan

Now that we're approaching the completion of the design phase, we should reevaluate project feasibility and update tbe project plan accordingly. The project manager in conjunction with SYSTEM OWNERS and the entire project team, facilitates this task. The SYSTEMS ANALYSTS and SYSTEM OWNERS are the key individuals in this task. The analysts and owners should consider the possibility that, based on the completed design work, the overall project schedule, cost estimates, and other estimates may need to be adjusted.

Large-Scale Software Architecture   A Practical Guide Using UML By Jeff Garland, Richard Anthony · 2003

2010综合 71-75

P7-10

Architectural Patterns - define a general set of element types and their interactions. Examples of Architectural Patterns include Pipes and Filters, Model-View-Controller,and Reflection.

Architcctural Style - As the term coined by Garlan and Shaw, it is an idiomatic pattern of system organization.For example, a client-server system is an architectural style. Many of the original architectural styles have been reformulated as patterns.

Build Systems - Development teams typically employ a set of tools that facilitate the translation of a large source code base into a set of libraries and executables in an orderly manner. This usually involves interacting with configuration management tools as well as tools such as the'Make'utility that utilizes software dependencies to perform incremental builds.

Commercial Off-the-Shelf (COTS) Products - These include software components that are purchased from software vendors or obtained from open source. Some authors use the term 'common'in place of the term commercial to prevent confusion with using the term "commercial’for open source software.

Component - A construct that groups implementation constructs and provides/consumes a set of interfaces. A component is a modular and easily replaceable implementation construct. The UML definition includes executable processes, applets, EJB, and code libraries as part of the component definition. Some authors further categorize components to include conceptual or logical components.However,we define views only in terms of the runtime aspects of components.

Domain - A domain is an area_of concern. For example, the "problem domain’defines the 'what'aspect of the system under design. The ‘solution domain' is the ‘how’ aspect. A large complex problem is often broken into sub-domains that address only one aspect of the larger problem.

Model - A representation used to understand or document one or more aspects of a problem or solution.With the UML, the model is often kept in a tool that will support the creation of multiple views.In this casc, the tool can provide the ability to keep a series of partial views of a complex model consistent.

Top-Level Software Architecture Description -The set of views of the system that encompass the highest-level perspective of the software. This perspective tends to focus on subsystems and components as documented in the top-level software design document.

Subsystem - A collection of classes and components that are grouped to form a development package. These subsystems need to be defined in such a way as to facilitate having them assigned to different, possibly geographically diverse, development teams.

Other types of architectures

Architecture is used in conjunction with many adjunct terms such as technical architecture,business architecture,enterprise architecture,reference architecture, product line architecture,and information architecture. To some extent, all these "architectures" have confused and obscured the definition of software architecture. The following list will briefly describe some of these in order to clarify how they relate to software architecture:

Enterprise Architecture is generally defined in terms of its constituent architectures. These include the business architecture, application architecture, technology architecture, software infrastructure architecture, and information architecture. The enterprise architecture provides the vision and consistent

principles that cross all the constituent architecture types and addresses objectives such as security, flexibility, make versus buy decisions, and reuse.

The Business Architecture defines the key business strategies, organization,  goals, and related business processes. The software architecture should be complementary with the business architecture. We must remember that the final goal of most software is to make the business successful, not simply to

produce an elegant software design.

At the enterprise level,the Application Architecture may be more of a set of guidelines on how the various software architectures should be constructed consistently across the enterprisc. For a specific product, the application architecture is the software architecture for that product.

The Technology/lnfrastructure Architecture refers to the network connectivity, hardware upon which the software runs, network routers, operating systems, and other technologies that facilitate the communication among the distributed software components and support the execution environment of the software.

The Data Architecture, sometimes referred to as the Information Architecture, refers to how the data is structured, stored, and handled either in the enterprise or for a particular project. The definition of the data architecture involves the specification of the number and type of databases, the logical and physical database design, the allocation of data to servers, the strategy for data replication and archival, as well as the strategy and design of a data warehouse.

The U.S. Army's Joint Technical Architecture - Army (JTA-Army) provides the following definition:

A Tecbnical Architecture is the mivimal set of rules governig the arrangement, interaction, and interdependence of the parts or elemerts that together may be used to formm an information system. Its purpose is to ensure that a conformant system satisfies a specified set of requirements. It is the build code for the Systems Architecture being constructed to satisfy Operational Architecture requirements.

A Product-line Architecture is used to define a set of products that are developed by a company or organization within the company. The similarities within that set of products allow for sharing of design and implementation information among the various teams developing the products.In this way, the products can be more consistent in the way they are designed, developed, tested, supported, and in their appearance to the end user. In addition, these products can be developed in a more cost-effective manner, due to the design and implementation reuse potential.

The term Reference Architecture refers to the definition of an architecture for a particular application domain. An example domain might be satellite ground control systems or telecommunications switch network management.

Software Design Methodology From Principles to Architectural Styles         By Hong Zhu · 2005

2009综合 71-75

P103

An architectural style defines a family of systems in terms of a pattern of structural orgartisations. Morespecifically, an architecturals vocabulary of components and connector types, and a set of constraints on how they can be combined. For many styles, there may also exist one or more semantic models that specify how to determine a system's overall properties from the properties of its parts.

Perspectives in Conceptual Modeling     ER 2005 Workshop AOIS, BP-UML, CoMoGIS, ECOMO, and QoIS, Klagenfurt, Austria, October 24-28, 2005, Proceedings    By Michela Bertolotto, Manuel Kolp, Christian Kop, Willem-Jan v.d. Heuvel, Heinrich C. Mayr · 2005

2018 案例二

P46-47

3.2 Business Use Cases vs. System Use Cases

Business use cases differ from system use cases. Business level use cases may include both manual and system operations. Most business use cases include a mix of manual and system processes. Pure system use cases, in contrast, only describe direct interaction with a system. According to Cockburn, “Business process people write business use cases to describe operations of their business, while a hardware or software development team writes system use cases for their requirements[6](p.7).

Business level use cases are more relevant to business process reengineering than to software system analysis and design. System use cases are derived from information collected in the business use cases, but they describe the functionality that the system delivers to actors in the business use case. Distinguishing business level use cases from system level use cases is helpful in establishing the system boundary. We

limit our classification schemes to system use cases.

Essential Use Cases vs. Real Use Cases

An essential use case expresses a high level view while remaining free of implementation details. A real use case "concretely describes the process in terms of its real current design, committed to specific input and output technologies,and so on”[11] (p.58). Essential use cases are closer to the “what” than the “how." “Use cases are requirements analysis and modeling tools that should describe what a system does (or should do), rather than how the system works(or should work).”[8](p.30)

Larman acknowledges that there is not a clear line between essential and real use cases. There are advantages to using both essential and real use cases. Essential use cases are reusable with successive implementations of the same system on newer technological platforms,whereas real use cases are tied to platform-specific designs. On the other hand,real use cases can inform programmers about what is needed with a higher level of detail.

Assessing where a use case falls on the essential vs. real scale can be accomplished by answering this question: Will this use case still be accurate and useful if the technological cnvironment and constraints change significantly?