Software Product Name (ACRONYM) Software Architecture Document (SAD)

Written by: Marc W. George

Last revision by: Marc W. George

Latest Revision 2000 年 4 月 23 日 Company Name

Document Identification: ACRONYM -SAD-001 Draft TABLE OF CONTENTS

1 Preface...... 6 2 Overview...... 7 2.1 Historical Background...... 7 2.1.1 Introduction...... 7 2.1.2 The “Old System” [optional]...... 7 2.1.3 The System Development Effort...... 8 2.2 Supporting Documentation...... 8 3 Architectural Goals...... 9 3.1 Clarity...... 9 3.2 Simplicity...... 9 3.3 Modularity...... 9 3.4 Durability...... 10 3.5 Scalability...... 10 3.6 Extensibility...... 10 3.7 Adaptability...... 11 3.8 Maintainability...... 11 4 Architectural Constraints...... 12 4.1 System Requirements...... 12 4.1.1 Microsoft Windows Compatibility...... 12 4.1.2 Retention Of [current system abbreviation] Feature Set [optional]...... 12 4.1.3 Backward Compatibility...... 12 4.1.4 Software Compatibility...... 12 4.2 Technology...... 12 4.2.1 Architecture...... 12 4.2.1.1 Distributed Processing...... 12 4.2.1.2 Distributed Data...... 13 4.2.2 Infrastructure Versioning...... 13 4.2.2.1 Client Tier...... 13 4.2.2.2 Applications Tier...... 13 4.2.2.3 Database Tier...... 13 5 Architectural Vision...... 14 5.1 Background...... 14 5.2 The Vision...... 14 6 Architectural External Design Specification...... 16 6.1 User Interface...... 16 6.1.1 Graphical User Interface...... 16 6.1.2 Common Object Model...... 16 6.1.3 IDL...... 16 6.1.4 Type Libraries...... 16 6.2 Class Design...... 17 6.3 Data Flow...... 17 6.4 Logical Data Stores...... 19 7 Architectural Internal Design Specification...... 20 7.1 Overview...... 20 7.2 Use-Case View...... 23 7.2.1 Overview...... 23 7.2.2 Use-Case:...... 24 7.2.2.1 Description...... 24 7.2.2.2 Flow of Events...... 24 7.2.2.3 Relationships...... 24

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 2 Draft 7.2.2.4 Use Case Diagrams...... 24 7.2.2.5 Activity Diagrams...... 24 7.2.2.6 Special Requirements...... 24 7.2.2.7 User Interfaces...... 24 7.2.2.7.1 Graphical User Interface...... 24 7.2.2.7.2 Component Interface...... 24 7.2.2.7.3 API...... 24 7.3 Logical View...... 25 7.3.1 Overview...... 25 7.3.2 Architecturally Significant Design Packages...... 25 7.3.2.1 Overview...... 25 7.3.2.2 [package name] Package...... 26 7.3.2.2.1 Overview...... 26 7.3.2.2.2 [component name]...... 26 7.3.3 Use-Case Realizations...... 27 7.3.3.1 Overview...... 27 7.3.3.2 Use-Case: [use case name]...... 28 7.3.3.2.1 Description...... 28 7.3.3.2.2 Significant Flow of Events...... 28 7.3.3.2.3 Use Case Realization Diagrams...... 28 7.3.3.2.4 Derived Requirements...... 28 7.4 Process View...... 29 7.4.1 Overview...... 29 7.4.2 [process name]...... 30 7.4.2.1 Process List...... 30 7.4.2.1.1 [sub-process name]...... 30 7.5 Implementation View...... 31 7.5.1 Overview...... 31 7.5.2 [layer name] Layer...... 33 7.5.2.1 Overview...... 33 7.5.2.2 Subsystems...... 33 7.5.2.2.1 [subsystem name] Subsystem...... 33 7.6 Deployment View...... 34 7.6.1 Overview...... 34 7.6.2 Deployment Configurations...... 35 7.6.2.1 Overview...... 35 7.6.2.2 Single Computer...... 35 7.6.2.2.1 Overview...... 35 7.6.2.2.2 Deployment Diagram...... 35 7.6.2.3 Client-Server...... 35 7.6.2.3.1 Overview...... 35 7.6.2.3.2 Deployment Diagram...... 35 7.6.2.4 Three Tier Client-Server...... 35 7.6.2.4.1 Overview...... 35 7.6.2.4.2 Deployment Diagram...... 35 7.6.2.5 Distributed N-Tier...... 36 7.6.2.5.1 Overview...... 36 7.6.2.5.2 Deployment Diagram...... 36 7.6.3 Software Requirements...... 37 7.6.3.1 Workstations...... 37 7.6.3.2 Application servers...... 37 7.6.3.3 Database Servers...... 37 7.6.4 Hardware Requirements...... 38 7.6.4.1 Overview...... 38 7.6.4.2 Client...... 38

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 3 Draft 7.6.4.3 Application servers...... 38 7.6.4.4 Database Servers...... 38 7.7 Data View...... 39 7.7.1 Overview...... 39 7.7.2 Persistent Object Data...... 39 7.7.2.1 Overview...... 39 7.7.2.2 Metadata...... 39 7.7.2.3 System Data...... 39 7.7.3 Database Strategies...... 40 7.7.3.1 Overview...... 40 7.7.3.2 Implementation Languages...... 40 7.7.3.3 Data Marts...... 40 7.7.3.4 Transaction Processing...... 40 7.7.3.5 Concurrency...... 40 7.7.3.6 Fault Tolerance...... 40 7.7.3.7 Distributed Data...... 40 7.7.4 Database Implementation...... 41 7.7.4.1 Overview...... 41 7.7.4.2 Stored Procedures...... 41 7.7.4.3 Triggers...... 41 7.8 Security View...... 42 7.8.1 Overview...... 42 7.8.2 Security Administration...... 42 7.8.2.1 Overview...... 42 7.8.2.2...... 42 7.8.3 User Security Profiles...... 42 7.8.3.1 Overview...... 42 7.8.3.2...... 42 7.8.4 System Integrity...... 42 7.8.4.1 Overview...... 42 7.8.4.2...... 42 7.8.5 Data Integrity...... 43 7.8.5.1 Overview...... 43 7.8.5.2...... 43 7.9 Size and Performance...... 44 7.9.1 Overview...... 44 7.9.2 Size...... 44 7.9.2.1 Overview...... 44 7.9.2.2 Disk Space...... 44 7.9.2.3 Memory...... 44 7.9.3 Scalability...... 45 7.9.3.1 Overview...... 45 7.9.3.2 Users...... 45 7.9.3.3 Transactions...... 45 7.9.4 Performance...... 46 7.9.4.1 Overview...... 46 7.9.4.2 System Load...... 46 7.9.4.3 Use Case Load...... 46 7.9.4.4 Transaction...... 46 7.9.4.5 Use Case Terminate...... 46 7.9.4.6 System Terminate...... 46 7.10 Quality...... 47 7.10.1 Overview...... 47 7.10.1.1 Operating Performance...... 47 7.10.1.2 Quality Targets...... 47

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 4 Draft 7.10.1.3 Extensibility...... 47 7.10.1.4 Portability...... 47 7.10.1.5 Hardware...... 47 7.10.1.6 Operating System...... 47 7.10.1.7 Languages...... 47 8 Architectural Development Environment Requirements...... 48 8.1 Overview...... 48 8.2 Software Requirements...... 49 8.2.1 Analysis & Design...... 49 8.2.1.1 Workstation...... 49 8.2.2 Development...... 50 8.2.2.1 Workstation/Client...... 50 8.2.2.2 Application Server...... 50 8.2.2.3 Database Server...... 50 8.2.3 Testing...... 51 8.2.3.1 Client...... 51 8.2.3.2 Application servers...... 51 8.2.3.3 Database Server...... 51 8.3 Hardware Requirements...... 52 8.3.1 Analysis and Design...... 52 8.3.1.1 Workstation...... 52 8.3.2 Development...... 53 8.3.2.1 Workstation/Client...... 53 8.3.2.2 Application server...... 53 8.3.2.3 Database Server...... 53 8.3.3 Testing...... 54 8.3.3.1 Client...... 54 8.3.3.2 Application server...... 54 8.3.3.3 Database Server...... 54 9 Cross Reference Index...... 55 10 Glossary of Terms...... 56 11 Revision History...... 57 Appendix A: COTS Recommendations...... 58 1. [product name]...... 58

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 5 Draft 1 Preface

This document covers the software architecture for [statement]. The initial sections of this document provide a basis of understanding for architectural design of the proposed system followed by details of the chosen software architecture.

This document was been prepare from the perspective of artifacts to be generated during a project using Rational, Inc.’s Rational Unified Process object oriented project management methodology. This document and its supplements together form the logical equivalent of the traditional “Top Level Design”. It is the primary medium of communication between the project’s architect and the other members of the development team:

 Managers, for input when planning iterations.  Systems Engineers, for a reference when planning resource requirements.  Designers, for a reference when creating use-case realizations, i.e. sequence & collaboration diagrams; defining object classes and their roles, operations, and attributes; and when adjusting classes to the implementation environment.  Implementers, as input when implementing classes.  Testers, for a reference when creating test plans.  Technical Writers, for input when writing user documentation.  Support Staff, for a reference when resolving user problems.

This document has been written under the assumption that the recommendations of this writer in the [statement] will be implemented.

The reader is advised that the document becomes more technical from front to back, and may require pre-requisite knowledge from external sources. An attempt has been made to provide references for such knowledge sources in Appendix A.

This document contains hyperlink references to external documents. These links were tested prior to publication of this document but are no guarantees of validity are implied.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 6 Draft 2 Overview

The following sections provide an overview of the forces which have lead to the creation of this software architecture document. 2.1 Historical Background

2.1.1 Introduction

[statement]

2.1.2 The “Old System” [optional]

[statement]

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 7 Draft 2.1.3 The System Development Effort

[statement] 2.2 Supporting Documentation

The official project documents provide the basis for development of this software architecture document. Online versions of these documents are available at [path]

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 8 Draft 3 Architectural Goals

The primary architectural goal is to provide the framework to achieve [statement].

Other architectural goals are: 3.1 Clarity

Use an architecture that promotes clarity. Clearly define the processes and problems to be solved by the proposed system. Express these in a manner that when combined with the details of the system design, the implementers of the proposed system can easily follow the resulting systems engineering blueprints. Provide a variety of views, i.e., graphical models, illustrations, tables, textual descriptions and other information structures. 3.2 Simplicity

Use an architecture that promotes simplicity. Reduce the complexity of the proposed system to the lowest common denominators by using pattern analysis to find similarities between elements. Combine similar elements. Identify functionally dependent elements and logically independent groupings. Identify those groupings that are required for the integrity and completeness of the system. Define these as the architectural components. 3.3 Modularity

Use an architecture that promotes modularity. Define clear boundaries between the architectural components. Promote lose coupling of functionality, i.e. all data is exchanged between components and subsystems through APIs. All APIs shall implement the concept of the immutability of interfaces, i.e. existing interfaces are fixed and extension interfaces for new functionality added, so that replacement of a component or subsystem does not break the system when that they are used by component or subsystem designed to use the earlier versions of the replacement.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 9 Draft 3.4 Durability

Use an architecture that promotes durability. Integrate or design components and subsystems that are fault tolerant. Components and subsystems should:

 Record all faults to an event log.  Notify the appropriate system administrators.  Attempt to repair or bypass the fault.  Provide some degree of functionality regardless of the occurrence of a fault.  Cache result sets, completing transactions after recovery from the fault. 3.5 Scalability

Use an architecture that promotes scalability. The architecture should:

 Use distributed processing, dividing processing into tiers of activity.  Use distributed data, positioning data close to the point of logical use.

The architecture should integrate or design components and subsystems that are easily scalable and have few limitations. Components should:

 Cooperatively support multiple instances.  Support topological mobility, i.e. relocation to a different architectural tier.  Use programming techniques, which enable asynchronous multi-processing, i.e., threads and processes.  Use programming techniques, which implement dynamic monitoring, and allocation of resources, i.e. prioritized processing.  Use programming techniques, which reduce resources requirements, i.e. data compression.  Use programming elements which are unlimited or more than sufficient for the intended functionality, i.e. doubles instead of shorts. 3.6 Extensibility

Use an architecture that promotes extensibility. Use components and subsystems that provide small, distinct units of functionality, which can be easily replaced, to build an integrated framework. Use the same concepts to build the remainder of the system.

Use an architecture which promotes publishable external interfaces to all functionality and accessible data.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 10 Draft 3.7 Adaptability

Use an architecture that promotes adaptability. Separate hardware specifics from logical functionality. Separate the user interface from the business logic of the system. Use wrappers to encapsulate logical functionally. 3.8 Maintainability

Use an architecture that promotes maintainability by implementing all of the previous architectural goals and promoting the extensive use of suitable CASE and development tools.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 11 Draft 4 Architectural Constraints

The principal considerations constraining the [project abbreviation] development project are: 4.1 System Requirements

The system requirements as specified in the [statement] must be meet, especially the following:

4.1.1 Microsoft Windows Compatibility

The system must provide a client that is Microsoft Windows 98 compatible.

4.1.2 Retention Of [current system abbreviation] Feature Set [optional]

The system must implement the current feature set except as noted in the system requirements.

4.1.3 Backward Compatibility

The ability to migrate existing data sets is essential to viability of the new system. Also, initial support for existing hardware, operating systems and database servers is essential.

4.1.4 Software Compatibility

The system must support [statement] in the [statement] Tier. 4.2 Technology

4.2.1 Architecture

4.2.1.1 Distributed Processing

The system software architecture is not constrained from using distributed processing as compared to traditional client- server if deemed appropriate.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 12 Draft 4.2.1.2 Distributed Data

The system software architecture is not constrained from using distributed data as compared to centralized storage of data. However, the architecture must provide mechanisms to control versioning of data, rollback of incomplete transactions, notification of incomplete transactions, secure access, and backup.

4.2.2 Infrastructure Versioning

4.2.2.1 Client Tier

The Client Tier cannot require a version of Windows or any other product that is not in general release at the time of system release.

4.2.2.2 Applications Tier

The Applications Tier can only require release versions of readily available external products at the time of system release.

4.2.2.3 Database Tier

The system’s Database Tier is only required to support the current release of any database servers at the time of system release.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 13 Draft 5 Architectural Vision

5.1 Background

The [statement]. 5.2 The Vision

The vision for the [project abbreviation] software architecture is to provide a modern framework for [statement] into the next century. This framework should be sufficiently flexible to accommodate changes in the topography of the [company name] hardware and network infrastructures as technology advances, allow for rapid extensibility and reduce maintenance requirements.

The [project abbreviation] software architecture is based on an object oriented N-Tier model which promotes the above by reducing the [project abbreviation] system into discrete replaceable and replicable units of logical functionality and data which are deployed to enhance performance and reliability; the same basic concepts of modern component based engineering used in today’s electronics industry. The [project abbreviation] software architecture is also based on the Microsoft® Windows® Distributed interNet Applications Architecture (WinDNA®). WinDNA is a development model which uses the Windows platform and provides a specification of how to develop robust, scalable, Internet enabled, distributed systems while extending existing data and applications. Further details are available at http://www.microsoft.com/dna/.

The [project abbreviation] software architecture is designed to reduce internal requirements for development and maintenance by utilizing Common Off The Shelf (COTS) software components where appropriate, use of open specifications, and modern Computer Aided Software Engineering (CASE) and development tools.

The [project abbreviation] software architecture is also designed to reduce the learning curve impact of technology in the workplace by using standardized implementations of user interfaces while introducing incremental addition of functionality. Consideration has been given to the exponential growth in software functionality and version frequency that will occur during the [project abbreviation] lifecycle, attempting to minimize possible impacts on the system by their incorporation.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 14 Draft 6 Architectural External Design Specification

The overall intent of this section is to convey a user-oriented view of the system’s design. The section is divided into several areas. 6.1 User Interface

The system’s user interface (UI) specification is defined in a separate document, the [project abbreviation] User Interface Specification, which can be located online at [path].

6.1.1 Graphical User Interface

The system’s graphical user interface will be based on Microsoft Windows 98 design as specified in Microsoft’s The Windows Interface Guidelines for Software Design which is available online. This specification has been extended to incorporate internal requirements to produce a [project abbreviation] look and feel.

6.1.2 Common Object Model

The system shall use Microsoft’s COM+ specification as the basis of its common object model. Use of this specification will provide standardize access to the functionality of the system via COM/DCOM. Third parties wishing to interface with the system from systems utilizing the Object Management Groups CORBA common object model may use a bridge, i.e. Orbix’s Comet.

Further information about this specification can be located online at the Microsoft COM Technologies site.

6.1.3 IDL

The system shall provide Interface Definition Language (IDL) files for each COM+ component conforming to the specification that is located online at Microsoft’s Interface Definition Language Reference.

6.1.4 Type Libraries

The system shall provide type libraries for each COM+ component conforming to the specification that is located online at Microsoft’s Interface Definition Language Reference.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 15 Draft 6.2 Class Design

The object design shall provide application-programming interfaces conforming to the COM+ specification. The following design parameters shall be applied during design and implementation project phases.

1. COM+ objects shall preserve the immutability of interfaces. 2. COM+ objects shall implement dual interfaces. 3. COM+ objects shall implement standardize interfaces where appropriate. 4. COM+ objects shall implement the IUnknown interface. 5. COM+ objects that contain collections shall provide IEnum interfaces. 6. COM+ objects that aggregate other COM classes shall provide aggregate interfaces. 6.3 Data Flow

The [project abbreviation] software architecture is based on an object oriented N-Tier model that allows data flow from any point to any point based on logical structural needs.

This architecture traditionally allows external access to any point in any tier. However, for security reasons, external access will be limited to the application and client tiers. The application and client tier will limit access according to the developed business and security logic.

The system will encapsulate the Database Tier by utilizing an intermediate staging database servers as application servers that will stage data as necessary for use by the applications layer. Use of this model will allow the system to easily scale by incorporating additional application servers.

The Database Tiers will be fully protected from direct external access, even by system users. The Database Tiers will be designed for proxy access only, i.g., only the [project abbreviation] system and the database administrator has direct access to the Database Tiers, with the [project abbreviation] system accessing the database on behalf of the system user according to the developed business and security logic.

The Application Tier instantiates the appropriate data objects that access the staged datasets. Then either application business logic components or

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 16 Draft Client Tier components can access the data objects for further processing or viewing.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 17 Draft 6.4 Logical Data Stores

The [project abbreviation] software architecture is based on an object oriented N-Tier model. The system shall persistently store data in the Database Tier in relational databases. Internal requirements specify that the [statement] be supported.

The system’s objects shall map their attributes to columns of a relational table. Object instances will be represented as rows within the table. Object instances will be identified with Global Unique ID’s (GUID) with a column specifically supplied for this purpose. Object relationships will be maintained in additional tables that will map relationships between GUIDs.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 18 Draft 7 Architectural Internal Design Specification

7.1 Overview

It is often difficult to tell from a traditional object-oriented system model how a system does what it is supposed to do. This difficulty stems from the lack of a common thread which stitches the system design together. Use-Cases are that thread because they define the behavior performed by a system.

The overall intent of this section is to convey the system’s internal software architecture and design. It does so through the use of views of different architectural models.

The Architectural Internal Design Specification is presented as seven views. The sixth and seventh views are optional and can be used to further define this specification. The views are:

 Use-Case View  Logical View  Process View  Deployment View  Implementation View  Data View (optional)  Security (optional)

The following diagram illustrates the main views of this architecture.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 19 Draft Logical View Implementation View

End-user Programmers Functionality Software management

Use Case View

Process View Deployment View System integrators System engineering Performance System topology Scalability Delivery, installation Throughput Communication

The Use-Case View contains use-cases and scenarios that encompass architecturally significant behavior, classes, or technical risks. It is a subset of the use-case model.

The Logical View contains the most important design classes and their organization into packages and subsystems, and the organization of these packages and subsystems into layers. It contains also some use case realizations. It is a subset of the design model.

The Implementation View contains an overview of the implementation model and its organization in terms of modules into packages and layers. It is a subset of the implementation model.

The Process View contains the description of the tasks (process and threads) involved, their interactions and configurations, and the allocation of design objects and classes to tasks. It is a subset of the design model.

The Deployment View contains the description of the various physical nodes for the most typical platform configurations, and the allocation of tasks to the physical nodes. It is a subset of the deployment model.

The Data View contains the description of the logical and physical representation of persistent data in the system. It also includes any behavior defined in the database, such as stored procedures, triggers, constraints, etc. It is a subset of the data model.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 20 Draft The Security View contains the description of the security mechanisms which will be implemented which control access to the system and its resources.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 21 Draft 7.2 Use-Case View

7.2.1 Overview

The Use-Case view of the software architecture presents selected use- cases that represent a significant, central functionality which must be performed by the proposed system, substantial architectural coverage (that exercise many architectural elements), or that stress or illustrate a delicate point of architecture.

The complete documentation of the [project abbreviation] Use-Cases that have been chosen is located online at [path].

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 22 Draft 7.2.2 Use-Case:

7.2.2.1 Description

7.2.2.2 Flow of Events

7.2.2.3 Relationships

7.2.2.4 Use Case Diagrams

7.2.2.5 Activity Diagrams

7.2.2.6 Special Requirements

7.2.2.7 User Interfaces

7.2.2.7.1 Graphical User Interface

7.2.2.7.2 Component Interface

7.2.2.7.3 API

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 23 Draft 7.3 Logical View

7.3.1 Overview

The overall intent of this section is to convey the logical view of the system’s internal software architecture and design. It presents the architecturally significant design packages that will comprise the system and examples of the working inter-relationships between them to accomplish the functionality of the system. It also presents their decomposition into classes and class utilities highlighting architecturally significant classes, relationships, functionality and attributes. Finally, it presents the use-case realization of those use-cases selected for the previous “Use-Case View” of the proposed system.

7.3.2 Architecturally Significant Design Packages

7.3.2.1 Overview

The [project abbreviation] architecture is based on object oriented N-Tier model that divides the overall system into multiple layers of functionality. The functionality layers are presented from an external perspective of the proposed system, i.g., from what the user interacts with to the proposed functionality, then finally to the persistence of information.

Components can be distributed across multiple or grouped onto shared topological tiers, communicating using Inter-Process Communications (IPC) and Remote Process Communications (RPC) protocols. Most components may be replicated and distributed over multiple processors as needed to enable robustness and scalability.

As technology advances, the software architecture has been designed to accelerate replacement of components. Abstraction and encapsulation of functionality is stressed.

The following sections detail significant packages, subsystems components. Many of the layer components are available as COTS products and are so indicated. Their inclusion here is to provide a complete view of the software architecture. A list of recommended COTS products can be found in Appendix A.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 24 Draft 7.3.2.2 [package name] Package

7.3.2.2.1 Overview

[statement]

7.3.2.2.2 [component name]

[statement]

7.3.2.2.2.1 Overview

[statement]

7.3.2.2.2.2 Component Diagrams

7.3.2.2.2.3 Object Diagrams

7.3.2.2.2.4 Class Diagrams

7.3.2.2.2.5 Statechart Diagrams

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 25 Draft 7.3.3 Use-Case Realizations

7.3.3.1 Overview

Use-Case Realizations within the Logical View of the proposed system illustrate how the software works by giving a few selected use-case (or scenario) realizations, and explains how the various design model elements contribute to their functionality. The realizations given here are chosen because they represent some significant, central functionality of the final system; or for their architectural coverage - they exercise many architectural elements - or stress or illustrate a specific, delicate point of the architecture. The corresponding use cases and scenarios of these realizations should be found in the use-case view.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 26 Draft 7.3.3.2 Use-Case: [use case name]

7.3.3.2.1 Description

The [statement]

7.3.3.2.2 Significant Flow of Events

The significant flow of events of this use-case is:

1. User

7.3.3.2.3 Use Case Realization Diagrams

The following diagrams illustrate how the significant components previously described in this view can used to realize this use-case.

In the class diagram above, the

In the sequence diagram above, the

7.3.3.2.4 Derived Requirements

This following requirements are derived from this use-case:

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 27 Draft 7.4 Process View

7.4.1 Overview

The overall intent of this section is to convey the process view of the system’s internal software architecture and design. It presents the decomposition of the system’s processes as heavyweight processes comprised of lightweight processes with specific behavior, lifetimes and interfaces. The interactions of the processes are illustrated as collaborations.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 28 Draft 7.4.2 [process name]

7.4.2.1 Process List

The following sub-processes are present within this process:

7.4.2.1.1 [sub-process name]

7.4.2.1.1.1 Process List

The following sub-processes are present within this process:

7.4.2.1.1.2 Collaboration Diagrams

The following collaboration diagrams illustrate the sub-process interactions comprising this process.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 29 Draft 7.5 Implementation View

7.5.1 Overview

The overall intent of this section is to convey the implementation view of the system’s internal software architecture and design. It presents the decomposition of the software into layers and subsystems in the implementation model

The [project abbreviation] architecture is based on object oriented N-Tier model that divides the overall system into multiple layers of functionality. The functionality layers are presented from an external perspective of the proposed system, i.g., from what the user interacts with to the proposed functionality, then finally to the persistence of information. The layers were designed to logically position data and processing to maximize computing resources.

The [project abbreviation] architecture is comprised of the [number] layers. Layers can be distributed across multiple or grouped onto shared topological tiers. The following component diagram illustrates the relationships between these layers:

Each layer is comprised of several subsystems which may consist of multiple components. Each component may be replicated and distributed over multiple processors as needed to enable robustness and scalability.

As technology advances, the software architecture has been designed to accelerate replacement of both layers and / or components. Abstraction and encapsulation of functionality is stressed.

The following sections detail the respective layers and their associated components. Many of the layer components are available as COTS products and are so indicated. Their inclusion here is to provide a complete view of the software architecture. A list of recommended COTS products can be found in Appendix A.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 30 Draft 7.5.2 [layer name] Layer

7.5.2.1 Overview

The [layer name] Layer provides [statement] the immediate logic of the functionality of the system to the user. It is responsible for [statement].

The [layer name] Layer is composed of subsystems of components. The following component diagram illustrates the relationships and boundaries between these subsystems and the subsystems of other layers are used by these subsystem.

The following section provides overviews of the subsystems which comprise this layer.

7.5.2.2 Subsystems

7.5.2.2.1 [subsystem name] Subsystem

7.5.2.2.1.1 Overview

The [subsystem name] Subsystem provides [statement].

The following component diagram illustrates the relationships and boundaries between these components and the components in other subsystems and layers.

The following components comprise this subsystem:

 [component name]  [component name]

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 31 Draft 7.6 Deployment View

7.6.1 Overview

The overall intent of this section is to convey the deployment view of the system’s internal software architecture and design. It presents the possible hardware configurations on which the system could be implemented by mapping the process view to the physical nodes.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 32 Draft 7.6.2 Deployment Configurations

7.6.2.1 Overview

The proposed software architecture can be deployed in the following configurations:

7.6.2.2 Single Computer

7.6.2.2.1 Overview

The system will support deployment on a single computer, however this configuration is the least desirable. This deployment configuration is only recommended for system demonstration purposes. The minimum hardware requirements for this configuration are the same as that for the application server.

7.6.2.2.2 Deployment Diagram

The following deployment diagram illustrates this configuration.

7.6.2.3 Client-Server

7.6.2.3.1 Overview

The system will support deployment on in a two tier client- server configuration. The minimum requirements for the client workstation and the server are the same as that for Distributed N-Tier configuration’s workstations and application servers respectfully.

7.6.2.3.2 Deployment Diagram

The following deployment diagram illustrates this configuration.

7.6.2.4 Three Tier Client-Server

7.6.2.4.1 Overview

The system will support deployment on in a two tier client- server configuration. The minimum requirements for the client workstation, application servers, and database server are the same as that for Distributed N-Tier configuration respectfully.

7.6.2.4.2 Deployment Diagram

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 33 Draft The following deployment diagram illustrates this configuration.

7.6.2.5 Distributed N-Tier

7.6.2.5.1 Overview

The system will support deployment on in a Distributed N-Tier configuration. The Distributed N-Tier configuration is the architectural deployment of choice. This configuration is recommend for its scalability and distribution of processing and data.

The minimum requirements for this configuration are specified in the following software and hardware sections.

7.6.2.5.2 Deployment Diagram

The following deployment diagram illustrates this configuration.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 34 Draft 7.6.3 Software Requirements The following software will be required for deployment of the following topological tiers:

7.6.3.1 Workstations

1. Microsoft WinNT 4.0 Workstation SP5 2. Microsoft Data Access SDK 2.1 3. Microsoft Internet Explorer 5 4. Microsoft Office 2000

7.6.3.2 Application servers

1. Microsoft WinNT 4.0 Server Enterprise SP5 2. Microsoft Data Access SDK 2.1 3. Microsoft Internet Explorer 5

7.6.3.3 Database Servers

1. Microsoft SQL Server 7.0

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 35 Draft 7.6.4 Hardware Requirements

7.6.4.1 Overview

The hardware requirements that are specified are the minimum anticipated for deployment to the specified tier.

7.6.4.2 Client

The minimum hardware requirement for the client tier is any computer capable of adequately running the software deployment environment specified above.

7.6.4.3 Application servers

The minimum hardware requirement for the application server tier is any computer capable of adequately running the application server deployment environment specified above.

7.6.4.4 Database Servers

No specification is made for the database tier as it is assumed that the hardware supplied will be sufficient for the intended purpose.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 36 Draft 7.7 Data View

7.7.1 Overview

The overall intent of this section is to convey the data view of the system’s internal software architecture and design. It presents the mapping of persistent data of key objects; architecturally significant elements of the system which are implemented in the database components, i.e. stored procedures and triggers; and other important decisions which have data implications, such as choice of transaction strategy, distribution, concurrency, and fault tolerance.

7.7.2 Persistent Object Data

7.7.2.1 Overview

The

7.7.2.2 Metadata

The

7.7.2.3 System Data

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 37 Draft 7.7.3 Database Strategies

7.7.3.1 Overview

The

7.7.3.2 Implementation Languages

The

7.7.3.3 Data Marts

The

7.7.3.4 Transaction Processing

The

7.7.3.5 Concurrency

The

7.7.3.6 Fault Tolerance

The

7.7.3.7 Distributed Data

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 38 Draft 7.7.4 Database Implementation

7.7.4.1 Overview

The

7.7.4.2 Stored Procedures

The

7.7.4.3 Triggers

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 39 Draft 7.8 Security View

7.8.1 Overview

The overall intent of this section is to convey the security view of the system’s internal software architecture and design. It presents the architecturally significant elements of the system which implement the systems security.

7.8.2 Security Administration

7.8.2.1 Overview

The

7.8.2.2

The

7.8.3 User Security Profiles

7.8.3.1 Overview

The

7.8.3.2

The

7.8.4 System Integrity

7.8.4.1 Overview

The

7.8.4.2

The

7.8.5 Data Integrity

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 40 Draft 7.8.5.1 Overview

The

7.8.5.2

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 41 Draft 7.9 Size and Performance

7.9.1 Overview

The overall intent of this section is to convey the size and performance requirements that should be satisfied by the system’s internal software architecture and design.

7.9.2 Size

7.9.2.1 Overview

The

7.9.2.2 Disk Space

The

7.9.2.3 Memory

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 42 Draft 7.9.3 Scalability

7.9.3.1 Overview

The

7.9.3.2 Users

The

7.9.3.3 Transactions

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 43 Draft 7.9.4 Performance

7.9.4.1 Overview

The

7.9.4.2 System Load

The

7.9.4.3 Use Case Load

The

7.9.4.4 Transaction

The

7.9.4.5 Use Case Terminate

The

7.9.4.6 System Terminate

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 44 Draft 7.10 Quality

7.10.1 Overview

The overall intent of this section is to convey the quality requirements that should be expected of the system’s internal software architecture and design. It presents the quality elements of the system that shape its software architecture.

7.10.1.1 Operating Performance

The

7.10.1.2 Quality Targets

The

7.10.1.3 Extensibility

The

7.10.1.4 Portability

The

7.10.1.5 Hardware

The

7.10.1.6 Operating System

The

7.10.1.7 Languages

The

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 45 Draft 8 Architectural Development Environment Requirements

8.1 Overview

The software architecture defines the development environment requirements. The requirements are divided into the software requirements, according to the development activity, necessary to support the development of a system using this software architecture and the hardware necessary to support the software.

Based on the given software architecture under development, the following sections present the requirements that have been derived.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 46 Draft 8.2 Software Requirements

8.2.1 Analysis & Design

The following software will be required for analysis and design environment:

8.2.1.1 Workstation

1. Microsoft WinNT 4.0 Workstation SP5 2. Rational Rose Enterprise 3. Microsoft Visual Studio 6.0 Enterprise Edition 4. Microsoft Data Access SDK 2.1 5. Microsoft Office 2000 SDK 6. Microsoft Internet Explorer 5 7. Microsoft Office 2000 Professional

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 47 Draft 8.2.2 Development

The following software will be required for development environment:

8.2.2.1 Workstation/Client

1. Microsoft WinNT 4.0 Workstation SP5 2. Microsoft Visual Studio 6.0 Enterprise Edition 3. Microsoft Data Access SDK 2.1 4. Microsoft Office 2000 SDK 5. Microsoft Internet Explorer 5 6. Microsoft Office 2000 Professional

8.2.2.2 Application Server

1. Microsoft WinNT 4.0 Server Enterprise SP5 2. Microsoft Visual Studio 6.0 Enterprise Edition 3. Microsoft Data Access SDK 2.1 4. Microsoft Internet Explorer 5

8.2.2.3 Database Server

1. Microsoft SQL Server 7.0

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 48 Draft 8.2.3 Testing

The following software will be required for testing environment:

8.2.3.1 Client

1. Microsoft WinNT 4.0 Workstation SP5 2. Microsoft Data Access SDK 2.1 3. Microsoft Internet Explorer 5 4. Microsoft Office 2000

8.2.3.2 Application servers

1. Microsoft WinNT 4.0 Server Enterprise SP5 2. Microsoft Data Access SDK 2.1 3. Microsoft Internet Explorer 5

8.2.3.3 Database Server

1. Microsoft SQL Server 7.0

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 49 Draft 8.3 Hardware Requirements

8.3.1 Analysis and Design

The hardware requirements that are specified are the minimum anticipated for analysis and design.

8.3.1.1 Workstation

The minimum hardware requirement is any computer capable of adequately running the software for the workstation analysis and design environment specified above.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 50 Draft 8.3.2 Development

The hardware requirements that are specified are the minimum anticipated for development.

8.3.2.1 Workstation/Client

The minimum hardware requirement is any computer capable of adequately running the software for the workstation/client development environment specified above.

8.3.2.2 Application server

The minimum hardware requirement is any computer capable of adequately running the software for the application server development environment specified above.

8.3.2.3 Database Server

No specification is made for the database tier as it is assumed that the hardware supplied will be sufficient for the intended purpose.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 51 Draft 8.3.3 Testing

The hardware requirements that are specified are the minimum anticipated for testing.

8.3.3.1 Client

The minimum hardware requirement is any computer capable of adequately running the software for the software testing environment specified above.

8.3.3.2 Application server

The minimum hardware requirement is any computer capable of adequately running the software for the application server testing environment specified above.

8.3.3.3 Database Server

No specification is made for the database tier as it is assumed that the hardware supplied will be sufficient for the intended purpose.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 52 Draft 9 Cross Reference Index

This section contains a list of any related documents. These can be documents, books, customer documents, newspaper cartoons, or whatever. Hyperlink pointers to online documents should be used.

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 53 Draft 10 Glossary of Terms

This section contains a description of any terms of acronyms that may aid the reader in understanding this document.

Term Definition

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 54 Draft 11 Revision History

This section lists the history (authors, revisions, dates, etc.) of the document.

Revision Author Date Changes Made IR Initial Revision

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 55 Draft Appendix A: COTS Recommendations

The following applications are recommended for the implementation of the COTS components. 12 [product name]

[statement]

2000 年 4 月 23 日 Company Name -- ACRONYM -SAD-00 56 Draft