24. 1。从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。
2。找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》有关文章以帮助确定用例的粒度。建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。而且在以参与者为中心的视图不要漏掉某个业务用例的参与者。
3。利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作 为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。
4。绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。使用的是activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是 否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。业务建模一般步骤和方法
25. 业务建模一般步骤和方法5。从3 或 4 中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。
7。根据业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范 围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。这一步并非很关键的，可将协作图，象活动图，类交互图等直接在 business usecase下说明。25
45. I E E E软件工程标准词汇表（ 1 9 9 7年）中定义需求为：
（1）用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。
业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（ use case）文档或方案脚本（ s c e n a r i o）说明中予以说明。
功能需求(functional requirement)定义了开发人员必须实现的软件功能也包括非功能需求，使得用户能完成他们的任务，从而满足了业务需求。所谓特性( f e a t u r e )是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求的定义和层次45
91. 91The Architecture Business Cycle** See last attached slides
92. 92What Is Software Architecture?An architectural
pattern is a description
of element and relation
types together with a
set of constraints on
how they may be used.
A pattern can be
thought of as a set of constraints on an architecture—on the element types and their patterns of interaction—and these constraints define a set or family of architectures that satisfy them.
Client-server is a common architectural pattern. Client and server are two element types, and their coordination is described in terms of the protocol that the server uses to communicate with each of its clients.
One of the most useful aspects of patterns is that they exhibit known quality attributes. This is why the architect chooses a particular pattern and not one at random. Some patterns represent known solutions to performance problems, others lend themselves well to high-security systems, still others have been used successfully in high-availability systems. Choosing an architectural pattern is often the architect's first major design choice.
93. 93A reference model is a division of functionality together with data flow between the pieces. A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. Arising from experience, reference models are a characteristic of mature domains. Can you name the standard parts of a compiler or a database management system? Can you explain in broad terms how the parts work together to accomplish their collective purpose? If so, it is because you have been taught a reference model of these applications.
A reference architecture is a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them. Whereas a reference model divides the functionality, a reference architecture is the mapping of that functionality onto a system decomposition. The mapping may be, but by no means necessarily is, one to one. A software element may implement part of a function or several functions.
Reference models, architectural patterns, and reference architectures are not architectures; they are useful concepts that capture elements of an architure. Each is the outcome of early design decisions. What Is Software Architecture?
94. 94Software StructuresThese three structures
correspond to the three
types of decision that
How is the system to be
structured as a set of code
How is the system to be
structured as a set of
elements that have runtime behavior (components) and interactions (connectors)?
How is the system to relate to nonsoftware structures in its environment (i.e., CPUs, file systems, networks, development teams, etc.)?
95. 95Architectural Structures and ViewsArchitectural structures can by and large be divided into three groups, depending on the broad nature of the elements they show.
Module structures. Here the elements are modules, which are units of implementation. Modules represent a code-based way of considering the system. They are assigned areas of functional responsibility. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?
Component-and-connector structures. Here the elements are runtime components (which are the principal units of computation) and connectors (which are the communication vehicles among components). Component-and-connector structures help answer questions such as What are the major executing components and how do they interact? What are the major shared data stores? Which parts of the system are replicated? How does data progress through the system? What parts of the system can run in parallel? How can the system's structure change as it executes?
Allocation structures. Allocation structures show the relationship between the software elements and the elements in one or more external environments in which the software is created and executed. They answer questions such as What processor does each software element execute on? In what files is each element stored during development, testing, and system building? What is the assignment of software elements to development teams?
96. 96Architectural Structures of a SystemSoftware StructureRelationsUseful forDecompositionIs a submodule of; shares secret withResource allocation and project structuring and planning; information hiding, encapsulation; configuration controlUsesRequires the correct presence ofEngineering subsets; engineering extensionsLayeredRequires the correct presence of; uses the services of; provides abstraction toIncremental development; implementing systems on top of "virtual machines" portabilityClassIs an instance of; shares access methods ofIn object-oriented design systems, producing rapid almost-alike implementations from a common templateClient-ServerCommunicates with; depends onDistributed operation; separation of concerns; performance analysis; load balancing
97. 97Architectural Structures of a SystemSoftware StructureRelationsUseful forProcessRuns concurrently with; may run concurrently with; excludes; precedes; etc.Scheduling analysis; performance analysisConcurrencyRuns on the same logical threadIdentifying locations where resource contention exists, where threads may fork, join, be created or be killedShared DataProduces data; consumes dataPerformance; data integrity; modifiabilityDeploymentAllocated to; migrates toPerformance, availability, security analysisImplementationStored inConfiguration control, integration, test activitiesWork AssignmentAssigned toProject management, best use of expertise, management of commonality
98. 98Creating an Architecture
99. 99Architecture and Quality AttributesArchitecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural level.
Architecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the details.
Qualities of the system. We will focus on availability, modifiability, performance, security, testability, and usability.
Business qualities (such as time to market) that are affected by the architecture.
Qualities, such as conceptual integrity, that are about the architecture itself although they indirectly affect other qualities, such as modifiability.
100. 100Availability general scenarios (generation) Portion of ScenarioPossible ValuesSourceInternal to the system; external to the systemStimulusFault: omission, crash, timing, responseArtifactSystem's processors, communication channels, persistent storage, processes
101. 101Portion of ScenarioPossible ValuesEnvironmentNormal operation;
degraded mode (i.e., fewer features, a fall back solution)ResponseSystem should detect event and do one or more of the following:
notify appropriate parties, including the user and other systems
disable sources of events that cause fault or failure according to defined rules
be unavailable for a prespecified interval, where interval depends on criticality of system
continue to operate in normal or degraded modeResponse MeasureTime interval when the system must be available
Time interval in which system can be in degraded mode
Repair timeAvailability general scenarios generation
102. 102(Sample) modifiability scenario (generation)Portion of ScenarioPossible ValuesSourceEnd user, developer, system administratorStimulusWishes to add/delete/modify/vary functionality, quality attribute, capacityArtifactSystem user interface, platform, environment; system that interoperates with target systemEnvironmentAt runtime, compile time, build time, design timeResponseLocates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modificationResponse MeasureCost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes
103. 103(Sample) performance scenario (generation)Portion of ScenarioPossible ValuesSourceOne of a number of independent sources, possibly from within systemStimulusPeriodic events arrive; sporadic events arrive; stochastic events arriveArtifactSystemEnvironmentNormal mode; overload mode ResponseProcesses stimuli; changes level of serviceResponse MeasureLatency, deadline, throughput, jitter, miss rate, data loss
104. 104(Sample) security scenario (generation)Portion of ScenarioPossible ValuesSourceIndividual or system that is
correctly identified, identified incorrectly, of unknown identity
internal/external, authorized/not authorized
with access to
limited resources, vast resources
105. 105Security scenario generationPortion of ScenarioPossible ValuesStimulusTries to
display data, change/delete data, access system services, reduce availability to system servicesArtifactSystem services; data within systemEnvironmentEither
online or offline, connected or disconnected, firewalled or openResponseAuthenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of servicesResponse MeasureTime/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied
106. 106Sample testability scenario
107. 107Testability General Scenario GenerationPortion of ScenarioPossible ValuesSourceUnit developer
Client acceptance tester
System userStimulusAnalysis, architecture, design, class, subsystem integration completed; system deliveredArtifactPiece of design, piece of code, complete applicationEnvironmentAt design time, at development time, at compile time, at deployment time ResponseProvides access to state values; provides computed values; prepares test environmentResponse MeasurePercent executable statements executed
Probability of failure if fault exists
Time to perform tests
Length of longest dependency chain in a test
Length of time to prepare test environment
108. 108Sample usability scenario
109. 109Usability General Scenario GenerationPortion of ScenarioPossible ValuesSourceEnd userStimulusWants to
learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortableArtifactSystemEnvironmentAt runtime or configure timeResponseSystem provides one or more of the following responses:
to support "learn system features"
help system is sensitive to context; interface is familiar to user; interface is usable in an unfamiliar context
to support "use system efficiently":
aggregation of data and/or commands; re-use of already entered data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities
to "minimize impact of errors":
undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources
to "adapt system":
to "feel comfortable":
display system state; work at the user's pace
110. 110Quality Attribute StimuliQuality AttributeStimulusAvailabilityUnexpected event, nonoccurrence of expected eventModifiabilityRequest to add/delete/change/vary functionality, platform, quality attribute, or capacityPerformancePeriodic, stochastic, or sporadicSecurityTries to
display, modify, change/delete information, access, or reduce availability to system servicesTestabilityCompletion of phase of system developmentUsabilityWants to
learn system features, use a system efficiently, minimize the impact of errors, adapt the system, feel comfortable
111. 111Business QualitiesTime to market. Time to market is often reduced by using prebuilt elements such as commercial off-the-shelf (COTS) products or elements re-used from previous projects. The ability to insert or deploy a subset of the system depends on the decomposition of the system into elements.
Cost and benefit. Different architectures will yield different development costs. An architecture that is highly flexible will typically be more costly to build than one that is rigid (although it will be less costly to maintain and modify).
Projected lifetime of the system. If the system is intended to have a long lifetime, modifiability, scalability, and portability become important. A modifiable, extensible product is more likely to survive longer in the marketplace, extending its lifetime.
Targeted market. Portability and functionality are key to market share. Other qualities, such as performance, reliability, and usability also play a role. To attack a large market with a collection of related products, a product line approach should be considered in which a core of the system is common (frequently including provisions for portability) and around which layers of software of increasing specificity are constructed.
Rollout schedule. If a product is to be introduced as base functionality with many features released later, the flexibility and customizability of the architecture are important. Particularly, the system must be constructed with ease of expansion and contraction in mind.
Integration with legacy systems. If the new system has to integrate with existing systems, care must be taken to define appropriate integration mechanisms. This property is clearly of marketing importance but has substantial architectural implications. The architectural constraints implied by this integration must be analyzed.
112. 112Availability tactics
113. 113Modifiability tactics
114. 114Performance tactics
115. 115Tactics for security
116. 116Testability tactics
117. 117Runtime usability tactics
118. 118Design The Architecture
119. 119Evolutionary Delivery Life Cycle
120. 120Attribute-driven design (ADD)Sample Input
1 Choose the Module to Decompose
2.a Choose the Architectural Drivers
2.b Choose an Architectural Pattern
2.c Instantiate Modules and Allocate Functionality Using Multiple Views
Represent the architecture with views
2.d Define Interfaces of the Child Modules
2.e Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules
121. 121 The input to ADD is a set of requirements.
ADD assumes functional requirements (typically expressed as use cases) and constraints as input, as do other design methods. However, in ADD, we differ from those methods in our treatment of quality requirements.
ADD mandates that quality requirements be expressed as a set of system-specific quality scenarios.
The general scenarios discussed in here act as input to the requirements process and provide a checklist to be used in developing the system-specific scenarios.
System-specific scenarios should be defined to the detail necessary for the application. Sample Input
122. 1221. Choose the module to decompose. The module to start with is usually the whole system. All required inputs for this module should be available (constraints, functional requirements, quality requirements).
2. Refine the module according to these steps:
a. Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this decomposition.
b. Choose an architectural pattern that satisfies the architectural drivers. Create (or select) the pattern based on the tactics that can be used to achieve the drivers. Identify child modules required to implement the tactics.
c. Instantiate modules and allocate functionality from the use cases and represent using multiple views.
d. Define interfaces of the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in the interface document for each module.
e. Verify and refine use cases and quality scenarios and make them constraints for the child modules. This step verifies that nothing important was forgotten and prepares the child modules for further decomposition or implementation.
3. Repeat the steps above for every module that needs further decomposition.ADD Steps
123. 123The following are all modules: system, subsystem, and submodule.
The decomposition typically starts with the system, which is then decomposed into subsystems, which are further decomposed into submodules.1a. Choose the Module to Decompose
124. 124Architectural drivers are the combination of functional and quality requirements that “shape” the architecture or the particular module under consideration. The drivers will be found among the top-priority requirements for the module.
The determination of architectural drivers is not always a top-down process. Sometimes detailed investigation is required to understand the ramifications of particular requirements. For example, to determine if performance is an issue for a particular system configuration, a prototypical implementation of a piece of the system may be required.
We will base our decomposition of a module on the architectural drivers. Other requirements apply to that module, but, by choosing the drivers, we are reducing the problem to satisfying the most important ones.
We do not treat all of the requirements as equal; the less important requirements are satisfied within the constraints of the most important. This is a significant difference between ADD and other architecture design methods.2.a Choose the Architectural Drivers
125. 125The goal of step 2b is to establish an overall architectural pattern consisting of module types. The pattern satisfies the architectural drivers and is constructed by composing selected tactics. Two main factors guide tactic selection. The first is the drivers themselves. The second is the side effects that a pattern implementing a tactic has on other qualities.
If we choose one example of each: "increase computational efficiency" and "choose scheduling policy." then this yields the following tactics:
Semantic coherence and information hiding. Separate responsibilities dealing with the user interface, communication, and sensors into their own modules. We call these modules virtual machines and we expect all three to vary because of the differing products that will be derived from the architecture. Separate the responsibilities associated with diagnosis as well.
Increase computational efficiency. The performance-critical computations should be made as efficient as possible.
Schedule wisely. The performance-critical computations should be scheduled to ensure the achievement of the timing deadline.2.b Choose an Architectural Pattern
126. 126In the preceding section, we discussed how the quality architectural drivers determine the decomposition structure of a module via the use of tactics. As a matter of fact, in that step we defined the module types of the decomposition step. We now show how those module types will be instantiated.
We identified a non-performance-critical computation running on top of a virtual machine that manages communication and sensor interactions. The software running on top of the virtual machine is typically an application. In a concrete system we will normally have more than one module. There will be one for each "group" of functionality; these will be instances of the types shown in the pattern. Our criterion for allocating functionality is similar to that used in functionality-based design methods, such as most object-oriented design methods.2.c Instantiate Modules and Allocate Functionality Using Multiple Views
127. 127 Applying use cases that pertain to the parent module helps the architect gain a more detailed understanding of the distribution of functionality. This also may lead to adding or removing child modules to fulfill all the functionality required. At the end, every use case of the parent module must be representable by a sequence of responsibilities within the child modules.
Assigning responsibilities to the children in a decomposition also leads to the discovery of necessary information exchange. This creates a producer/consumer relationship between those modules, which needs to be recorded. At this point in the design, it is not important to define how the information is exchanged. Is the information pushed or pulled? Is it passed as a message or a call parameter? These are all questions that need to be answered later in the design process. At this point only the information itself and the producer and consumer roles are of interest. This is an example of the type of information left unresolved by ADD and resolved during detailed design.
Some tactics introduce specific patterns of interaction between module types. A tactic using an intermediary of type publish-subscribe, for example, will introduce a pattern, "Publish" for one of the modules and a pattern "Subscribe" for the other. These patterns of interaction should be recorded since they translate into responsibilities for the affected modules.
These steps should be sufficient to gain confidence that the system can deliver the desired functionality. To check if the required qualities can be met, we need more than just the responsibilities so far allocated. Dynamic and runtime deployment information is also required to analyze the achievement of qualities such as performance, security, and reliability. Therefore, we examine additional views along with the module decomposition view.Allocate functionality
128. 128ADD uses these three common views.
Module decomposition view. Our discussion above shows how the module decomposition view provides containers for holding responsibilities as they are discovered. Major data flow relationships among the modules are also identified through this view.
Concurrency view. In the concurrency view dynamic aspects of a system such as parallel activities and synchronization can be modeled. This modeling helps to identify resource contention problems, possible deadlock situations, data consistency issues, and so forth. Modeling the concurrency in a system likely leads to discovery of new responsibilities of the modules, which are recorded in the module view. It can also lead to discovery of new modules, such as a resource manager, in order to solve issues of concurrent access to a scarce resource and the like.
The concurrency view is one of the component-and-connector views. The components are instances of the modules in the module decomposition view, and the connectors are the carriers of virtual threads. A "virtual thread" describes an execution path through the system or parts of it. This should not be confused with operating system threads (or processes), which implies other properties like memory/processor allocation. Those properties are not of interest on the level at which we are designing. Nevertheless, after the decisions on an operating system and on the deployment of modules to processing units are made, virtual threads have to be mapped onto operating system threads. This is done during detailed design.
The connectors in a concurrency view are those that deal with threads such as "synchronizes with," "starts," "cancels," and "communicates with." A concurrency view shows instances of the modules in the module decomposition view as a means of understanding the mapping between those two views. It is important to know that a synchronization point is located in a specific module so that this responsibility can be assigned at the right place.Represent the architecture with views
129. 129- Two users doing similar things at the same time. This helps in recognizing resource contention or data integrity problems.
- One user performing multiple activities simultaneously. This helps to uncover data exchange and activity control problems.
- Starting up the system. This gives a good overview of permanent running activities in the system and how to initialize them. It also helps in deciding on an initialization strategy, such as everything in parallel or everything in sequence or any other model.
- Shutting down the system. This helps to uncover issues of cleaning up, such as achieving and saving a consistent system state.understand the concurrency in a system
130. 130 If multiple processors or specialized hardware is used in a system, additional responsibilities may arise from deployment to the hardware. Using a deployment view helps to determine and design a deployment that supports achieving the desired qualities.
The deployment view results in the virtual threads of the concurrency view being decomposed into virtual threads within a particular processor and messages that travel between processors to initiate the next entry in the sequence of actions. Thus, it is the basis for analyzing the network traffic and for determining potential congestion.
The deployment view also helps in deciding if multiple instances of some modules are needed. For example, a reliability requirement may force us to duplicate critical functionality on different processors. A deployment view also supports reasoning about the use of special-purpose hardware.
The derivation of the deployment view is not arbitrary. As with the module decomposition and concurrency views, the architecture drivers help determine the allocation of components to hardware. Tactics such as replication offer a means to achieve high performance or reliability by deploying replicas on different processors. Other tactics such as a real-time scheduling mechanism actually prohibit deployment on different processors.
Functional considerations usually guide the deployment of the parts that are not predetermined by the selected tactics.
The crossing of a virtual thread from one processor to another generates responsibilities for different modules. It indicates a communication requirement between the processors. Some module must be responsible for managing the communication; this responsibility must be recorded in the module decomposition view.Deployment view
131. 131The following information should be available in the modules' interface documentation:
The module view documents
producers/consumers of information.
patterns of interaction that require modules to provide services and to use them.
The concurrency view documents
interactions among threads that lead to the interface of a module providing or using a service.
the information that a component is active—for example, has its own thread running.
the information that a component synchronizes, sequentializes, and perhaps blocks calls.
The deployment view documents
the hardware requirements, such as special-purpose hardware.
some timing requirements, such as that the computation speed of a processor has to be at least 10 MIPS.
communication requirements, such as that information should not be updated more than once every second.2.d Define Interfaces of the Child Modules
132. 1322.e Verify and Refine Use Cases and Quality Scenarios as Constraints for the Child Modules Functional requirements
133. 133User interface. Recognize user requests and translate them into the form expected by the raising/lowering door module.
Raising/lowering door module. Control actuators to raise or lower the door. Stop the door when it reaches either fully open or fully closed.
Obstacle detection. Recognize when an obstacle is detected and either stop the descent of the door or reverse it.
Communication virtual machine. Manage all communication with the home information system.
Sensor/actuator virtual machine. Manage all interactions with the sensors and actuators.
Scheduler. Guarantee that the obstacle detector will meet its deadlines.
Diagnosis. Manage the interactions with the home information system devoted to diagnosis.Functional requirements
134. 134ConstraintsConstraints of the parent module can be satisfied in one of the following ways:
The decomposition satisfies the constraint. For example, the constraint of using a certain operating system can be satisfied by defining the operating system as a child module. The constraint has been satisfied and nothing more needs to be done.
The constraint is satisfied by a single child module. For example, the constraint of using a special protocol can be satisfied by defining an encapsulation child module for the protocol. The constraint has been designated a child. Whether it is satisfied or not depends on what happens with the decomposition of the child.
The constraint is satisfied by multiple child modules. For example, using the Web requires two modules (client and server) to implement the necessary protocols. Whether the constraint is satisfied depends on the decomposition and coordination of the children to which the constraint has been assigned.
135. 135Quality scenariosQuality scenarios also have to be refined and assigned to the child modules.
A quality scenario may be completely satisfied by the decomposition without any additional impact. It can then be marked as satisfied.
A quality scenario may be satisfied by the current decomposition with constraints on child modules. For example, using layers might satisfy a specific modifiability scenario, which in turn will constrain the usage pattern of the children.
The decomposition may be neutral with respect to a quality scenario. For example, a usability scenario pertains to portions of the user interface that are not yet a portion of the decomposition. This scenario should be assigned to one of the child modules.
A quality scenario may not be satisfiable with the current decomposition. If it is an important one, then the decomposition should be reconsidered. Otherwise, the rationale for the decomposition not supporting this scenario must be recorded. This is usually the result of a tradeoff with other, perhaps higher-priority scenarios.
136. 136Creating a Skeletal System Once an architecture is sufficiently designed and teams are in place to begin building to it, a skeletal system can be constructed. The idea at this stage is to provide an underlying capability to implement a system's functionality in an order advantageous to the project.
Classical software engineering practice recommends "stubbing out" sections of code so that portions of the system can be added separately and tested independently. However, which portions should be stubbed? By using the architecture as a guide, a sequence of implementation becomes clear.
First, implement the software that deals with the execution and interaction of architectural components. This may require producing a scheduler in a real-time system, implementing the rule engine (with a prototype set of rules) to control rule firing in a rule-based system, implementing process synchronization mechanisms in a multi-process system, or implementing client-server coordination in a client-server system. Often, the basic interaction mechanism is provided by third-party middleware, in which case the job becomes ones of installation instead of implementation. On top of this communication or interaction infrastructure, you may wish to install the simplest of functions, one that does little more than instigate some rote behavior. At this point, you will have a running system that essentially sits there and hums to itself—but a running system nevertheless. This is the foundation onto which useful functionality can be added.
You can now choose which of the elements providing functionality should be added to the system. The choice may be based on lowering risk by addressing the most problematic areas first, or it may be based on the levels and type of staffing available, or it may be based on getting something useful to market as quickly as possible.
Once the elements providing the next increment of functionality have been chosen, you can employ the uses structure to tell you what additional software should be running correctly in the system (as opposed to just being there in the form of a stub) to support that functionality.
137. 137 This process continues, growing larger and larger increments of the system, until it is all in place. At no point is the integration and testing task overwhelming; at every increment it is easy to find the source of newly introduced faults. Budgets and schedules are more predictable with smaller increments, which also provide management and marketing with more delivery options.
Even the stubbed-out parts help pave the way for completion. These stubs adhere to the same interfaces that the final version of the system requires, so they can help with understanding and testing the interactions among components even in the absence of high-fidelity functionality. These stub components can exercise this interaction in two ways, either producing hardcoded canned output or reading the output from a file. They can also generate a synthetic load on the system to approximate the amount of time the actual processing will take in the completed working version. This aids in early understanding of system performance requirements, including performance interactions and bottlenecks.
According to Cusumano and Selby, the Evolutionary Delivery Life Cycle is the basis for the strategy that Microsoft uses. In Microsoft's version of this approach, a "complete" skeletal system is created early in a product's life cycle and a "working," but low-fidelity, version is rebuilt at frequent periods—often nightly. This results in a working system for which the features can, at any time, be judged sufficient and the product rolled out. One problem to guard against, however, is that the first development team to complete a portion of the system gets to define the interface to which all subsequent subsystems must conform. This effectively penalizes the complex portions of the system, because they will require more analysis and hence will be less likely to have their interfaces defined first. The effect is to make the complex subsystems even more complex. Our recommendation is first to negotiate the interfaces in the skeletal subsystem and then to use a process that rewards development efficiency.Creating a Skeletal System
138. 138Documenting Software Architectures
139. 139Stakeholders and the Architecture Documentation
They Might Find Most UsefulModule ViewsC&C ViewsAllocation ViewsStakeholderDecompositionUsesClassLayerVariousDeploymentImplementationProject Managerss s d Member of Development TeamdddddssTesters and Integrators dd sssMaintainersdddddssProduct Line Application Builder dsosssCustomer so End User ss Analystddsdsd Infrastructure Supportss s sdNew StakeholderxxxxxxxCurrent and Future ArchitectddddddsKey: d = detailed information, s = some details, o = overview information, x = anything
140. 140Three-step procedure for choosing the views Produce a candidate view list. Begin by building a stakeholder/view table, like Table 9.2, for your project. Your stakeholder list is likely to be different from the one in the table, but be as comprehensive as you can. For the columns, enumerate the views that apply to your system. Some views (such as decomposition or uses) apply to every system, while others (the layered view, most component-and-connector views such as client-server or shared data) only apply to systems designed that way. Once you have the rows and columns defined, fill in each cell to describe how much information the stakeholder requires from the view: none, overview only, moderate detail, or high detail.
Combine views. The candidate view list from step 1 is likely to yield an impractically large number of views. To reduce the list to a manageable size, first look for views in the table that require only overview depth or that serve very few stakeholders. See if the stakeholders could be equally well served by another view having a stronger constituency. Next, look for views that are good candidates to be combined—that is, a view that gives information from two or more views at once. For small and medium projects, the implementation view is often easily overlaid with the module decomposition view. The module decomposition view also pairs well with uses or layered views. Finally, the deployment view usually combines well with whatever component-and-connector view shows the components that are allocated to hardware elements—the process view, for example.
Prioritize. After step 2 you should have an appropriate set of views to serve your stakeholder community. At this point you need to decide what to do first. How you decide depends on the details specific to your project, but remember that you don't have to complete one view before starting another. People can make progress with overview-level information, so a breadth-first approach is often the best. Also, some stakeholders' interests supersede others. A project manager or the management of a company with which yours is partnering demands attention and information early and often.
141. 141The seven parts of a documented view
142. 142DOCUMENTING BEHAVIOR
Views present structural information about the system. However, structural information is not sufficient to allow reasoning about some system properties. Reasoning about deadlock, for example, depends on understanding the sequence of interactions among the elements, and structural information alone does not present this sequencing information. Behavior descriptions add information that reveals the ordering of interactions among the elements, opportunities for concurrency, and time dependencies of interactions (at a specific time or after a period of time).
Behavior can be documented either about an element or about an ensemble of elements working in concert. Exactly what to model will depend on the type of system being designed. For example, if it is a real-time embedded system, you will need to say a lot about timing properties and the time of events. In a banking system, the sequence of events (e.g., atomic transactions and rollback procedures) is more important than the actual time of events being considered. Different modeling techniques and notations are used depending on the type of analysis to be performed. In UML, sequence diagrams and statecharts are examples of behavioral descriptions. These notations are widely used.
Statecharts are a formalism developed in the 1980s for describing reactive systems. They add a number of useful extensions to traditional state diagrams such as nesting of state and "and" states, which provide the expressive power to model abstraction and concurrency. Statecharts allow reasoning about the totality of the system. All of the states are assumed to be represented and the analysis techniques are general with respect to the system. That is, it is possible to answer a question such as Will the response time to this stimulus always be less than 0.5 seconds?
A sequence diagram documents a sequence of stimuli exchanges. It presents a collaboration in terms of component instances and their interactions and shows the interaction arranged in time sequence. The vertical dimension represents time and the horizontal dimension represents different components. Sequence diagrams allow reasoning based on a particular usage scenario. They show how the system reacts to a particular stimulus and represent a choice of paths through the system. They make it possible to answer a question such as What parallel activities occur when the system is responding to these specific stimuli under these specific conditions?
143. 143 An interface is a boundary across which two independent entities meet and interact or communicate with each other. Our definition of software architecture in Chapter 2 made it clear that elements' interfaces—carriers of the properties externally visible to other elements—are architectural. Since you cannot perform analyses or system building without them, documenting interfaces is an important part of documenting architecture.
Documenting an interface consists of naming and identifying it and documenting its syntactic and semantic information. The first two parts constitute an interface's "signature." When an interface's resources are invokable programs, the signature names the programs and defines their parameters. Parameters are defined by their order, data type, and (sometimes) whether or not their value is changed by the program. A signature is the information that you would find about the program, for instance, in an element's C or C++ header file or in a Java interface.
Signatures are useful (for example, they can enable automatic build checking), but are only part of the story. Signature matching will guarantee that a system will compile and/or link successfully. However, it guarantees nothing about whether the system will operate successfully, which is after all the ultimate goal. That information is bound up in the semantics to the interface, or what happens when resources are brought into play.
144. 144 An interface is documented with an interface specification, which is a statement of element properties the architect chooses to make known. The architect should expose only what is needed to interact with the interface. Put another way, the architect chooses what information is permissible and appropriate for people to assume about the element, and what is unlikely to change. Documenting an interface is a matter of striking a balance between disclosing too little information and disclosing too much. Too little information will prevent developers from successfully interacting with the element. Too much will make future changes to the system more difficult and widespread and make the interface too complicated for people to understand. A rule of thumb is to focus on how elements interact with their operational environments, not on how they are implemented. Restrict the documentation to phenomena that are externally visible.
Elements that occur as modules often correspond directly to one or more elements in a component-and-connector view. The module and component-and-connector elements are likely to have similar, if not identical, interfaces and documenting them in both places would produce needless duplication. To avoid that, the interface specification in the component-and-connector view can point to the interface specification in the module view, and only contain the information specific to its view. Similarly, a module may appear in more than one module view—such as the module decomposition or uses view. Again, choose one view to hold the interface specification and refer to it in the others.DOCUMENTING INTERFACES
145. 145The nine parts of interface documentation
146. 146cross-view documentation
147. 147We have concentrated on the kind of information that should be included in architecture documentation. Architecture in some sense expresses what is essential about a software system, and that essence is independent of languages and notations to capture it. Nevertheless, today the Unified Modeling Language (UML) has emerged as the de facto standard notation for documenting a software architecture. However, it must be said that UML makes its main contribution in a view's primary presentation, and its secondary contribution in the behavior of an element or group of elements. It is up to the architect to augment the UML pictures with the necessary supporting documentation (the element catalog, the rationale, and so forth) that a responsible job requires. UML provides no direct support for components, connectors, layers, interface semantics, or many other aspects of a system that are supremely architectural.
Still, in most cases we can use the constructs that UML does offer to achieve satisfactory effects, at least in crafting the primary presentations of architectural views. We begin by discussing module views.Unified Modeling Language
148. 148Examples of module notations in UML
149. 149Examples of relation notations in UML. Module B is part of module A, module D depends on module C, and module F is a type of module E.
150. 150Decomposition in UML with nesting. The aggregate module
is shown as a package (left); decomposition in UML with arcs (right).
151. 151Documenting generalization in UML with two line styles
152. 152The most architecturally significant manifestation of dependency is found in layers. Sadly, UML has no built-in primitive corresponding to a layer. However, it can represent simple layers using packages. These are general-purpose mechanisms for organizing elements into groups. UML has predefined packages for systems and subsystems. We can introduce an additional package for layers by defining it as a package stereotype. A layer can be shown as a UML package with the constraints that it groups modules together and that the dependency between packages is "allowed to use." We can designate a layer using the package notation with the stereotype name <> preceding the layer name, or introduce a new visual form, such as a shaded rectangle.
A simple representation of layers in UMLDependency
153. 153There is no single preferred strategy to document component-and-connector (C&C) views in UML, but a number of alternatives. Each alternative has its advantages and disadvantages. One natural candidate for representing component-and-connector types begins with the UML class concept.
The following illustrates the general idea using a simple pipe-and-filter system. Here, the filter architectural type is represented as the UML class Filter. Instances of filters, such as Splitter, are represented as
corresponding objects in an
object instance diagram.
To provide a namespace boundary,
we enclose the descriptions
packages. The representation
of MergeAndSort, denoted
Details, would be shown as
package elsewhere.COMPONENT-AND-CONNECTOR VIEWSTypes as classes, and
as objects, exemplified
with a simple pipe and
The type/instance relationship in architectural descriptions is a close match to the class/object relationship in a UML model. UML classes, like component types in architectural descriptions, are first-class entities and are rich structures for capturing software abstractions. The full set of UML descriptive mechanisms is available to describe the structure, properties, and behavior of a class, making this a good choice for depicting detail and using UML-based analysis tools. Properties of architectural components can be represented as class attributes or with associations; behavior can be described using UML behavioral models; and generalization can be used to relate a set of component types. The semantics of an instance or type can also be elaborated by attaching one of the standard stereotypes; for example, the «process» stereotype can be attached to a component to indicate that it runs as a separate process. Note that the relationship between MergeAndSort and its substructure is indicated using a dependency relation.
155. 155Five ways to represent interfaces to components (ports)
There are three reasonable options for representing connectors. Again, the choice is between expressiveness and semantic match on the one hand and complexity on the other.
Option 1: Connector types as associations and connector instances as links. Option 2: Connector types as association classes.
Option 3: Connector types as classes and connector instances as objects.
In addition to representing individual components and connectors and their types, we also need to encapsulate graphs of components and connectors: systems. Three options are available.
Option 1: Systems as UML subsystems.
Option 2: Systems as contained objects.
Option 3: Systems as collaborations.
157. 157Systems as collaborations
158. 158ALLOCATION VIEWS
In UML, a deployment diagram is a graph of nodes connected by communication associations. The following provides an example. Nodes may contain component instances, which indicates that the component lives or runs on the node. Components may contain objects, which indicates that the object is part of the component. Components are connected to other components by dashed-arrow dependencies (possibly through interfaces). This indicates that one component uses the services of another; a stereotype may be used to indicate the precise dependency if needed. The deployment type diagram may also be used to show which components may run on which nodes, by using dashed arrows with the stereotype «supports».
159. 159Analyzing Architectures
160. 160ATAM evaluation team rolesRoleResponsibilitiesDesirable characteristicsTeam LeaderSets up the evaluation; coordinates with client, making sure client's needs are met; establishes evaluation contract; forms evaluation team; sees that final report is produced and delivered (although the writing may be delegated)Well-organized, with managerial skills; good at interacting with client; able to meet deadlinesEvaluation LeaderRuns evaluation; facilitates elicitation
of scenarios; administers scenario selection/prioritization process; facilitates evaluation of scenarios against architecture; facilitates onsite analysisComfortable in front of audience; excellent facilitation skills; good understanding of architectural issues; practiced in architecture evaluations; able to tell when protracted discussion is leading to a valuable discovery or when it is pointless and should be re-directedScenario ScribeWrites scenarios on flipchart or whiteboard during scenario elicitation; captures agreed-on wording of each scenario, halting discussion until
exact wording is capturedGood handwriting; stickler about not moving on before an idea (scenario) is captured; can absorb and distill the essence of technical discussionsATAM - Architecture Tradeoff Analysis Method
161. 161Proceedings ScribeCaptures proceedings in electronic form on laptop or workstation, raw scenarios, issue(s) that motivate each scenario (often lost in the wording of the scenario itself), and resolution
of each scenario when applied to
architecture(s); also generates a printed list
of adopted scenarios for handout to all participantsGood, fast typist; well organized for rapid recall of information; good understanding of architectural issues; able to assimilate technical issues quickly; unafraid to interrupt the flow of discussion (at opportune times) to test understanding of an issue so that appropriate information is capturedTimekeeperHelps evaluation leader stay on schedule;
helps control amount of time devoted to each scenario during the evaluation phaseWilling to interrupt discussion to call timeRoleResponsibilitiesDesirable characteristicsATAM evaluation team roles
162. 162ATAM evaluation team rolesProcess ObserverKeeps notes on how evaluation process could be improved or
deviated from; usually keeps silent
but may make discreet
process-based suggestions to the evaluation leader during the
evaluation; after evaluation, reports
on how the process went and
lessons learned for future improvement; also responsible for reporting experience to architecture evaluation team at largeThoughtful observer; knowledgeable in the evaluation process; should have previous experience in the architecture evaluation methodProcess EnforcerHelps evaluation leader remember
and carry out the steps of the evaluation methodFluent in the steps of the method, and willing and able to provide discreet guidance to the evaluation leaderQuestionerRaise issues of architectural
interest that stakeholders may
not have thought ofGood architectural insights; good insights into needs of stakeholders; experience with systems in similar domains; unafraid to bring up contentious issues and pursue them; familiar with attributes of concernRoleResponsibilitiesDesirable characteristics
163. 163A concise presentation of the architecture. Architecture documentation is often thought to consist of the object model, a list of interfaces and their signatures, or some other voluminous list. But one of the requirements of the ATAM is that the architecture be presented in one hour, which leads to an architectural presentation that is both concise and, usually, understandable.
Articulation of the business goals. Frequently, the business goals presented in the ATAM are being seen by some of the development team for the first time.
Quality requirements in terms of a collection of scenarios. Business goals lead to quality requirements. Some of the important quality requirements are captured in the form of scenarios.
Mapping of architectural decisions to quality requirements. Architectural decisions can be interpreted in terms of the qualities that they support or hinder. For each quality scenario examined during an ATAM, those architectural decisions that help to achieve it are determined.
A set of identified sensitivity and tradeoff points. These are architectural decisions that have a marked effect on one or more quality attributes. Adopting a backup database is clearly an architectural decision as it affects reliability, and so it is a sensitivity point with respect to reliability. Keeping the backup current consumes system resources and so affects performance negatively. Hence, it is a tradeoff point between reliability and performance. Whether this decision is a risk or a nonrisk depends on whether its performance cost is excessive in the context of the quality attribute requirements of the architecture.
A set of risks and nonrisks. A risk is defined in the ATAM as an architectural decision that may lead to undesirable consequences in light of stated quality attribute requirements. Similarly, a nonrisk is an architectural decision that, upon analysis, is deemed safe. The identified risks can form the basis for an architectural risk mitigation plan.
A set of risk themes. When the analysis is complete, the evaluation team will examine the full set of discovered risks to look for over-arching themes that identify systemic weaknesses in the architecture or even in the architecture process and team. If left untreated, these risk themes will threaten the project's business goals.Outputs of the ATAM
164. 164PhaseActivityParticipantsTypical Duration0Partnership and preparationEvaluation team leadership and key project decision makersProceeds informally as required, perhaps over a few weeks1EvaluationEvaluation team and project decision makers1 day followed by a hiatus of 2 to 3 weeks2Evaluation (continued)Evaluation team, project decision makers, and stakeholders2 days3Follow-upEvaluation team and evaluation client1 weekATAM Phases and Their Characteristics
165. 165Steps and ATAM Outputs, CorrelatedATAM OutputsStepsPrioritized Statement of Quality Attribute RequirementsCatalog of Architectural Approaches UsedApproach- and Quality Attribute-Specific Analysis QuestionsMapping of Architectural Approaches to Quality AttributesRisks and Non-risksSensitivity and Tradeoff Points1. Present ATAM 2. Present business drivers*[a] *[b] 3. Present architecture ** *[c]*[d]4. Identify architectural approaches **** *[e]*[f]5. Generate quality attribute utility tree** 6. Analyze architectural approaches *[g]********7. Brainstorm and prioritize scenarios** 8. Analyze architectural approaches *********9. Present results A "**" means that the step is a primary contributor to the output; a "*" means that it is a secondary contributor.
166. 166[a] The business drivers include the first, coarse description of the quality attributes.
[b] The business drivers presentation might disclose an already identified or long- standing risk that should be captured.
[c] The architect may identify a risk in his or her presentation.
[d] The architect may identify a sensitivity of tradeoff point in his or her presentation.
[e] Many architectural approaches have standard associated risks.
[f] Many architectural approaches have associated standard sensitivities and attribute tradeoffs.
[g] The analysis steps might reveal one or more architectural approaches not identified in step 4, which will then produce new approach-specific questions.Steps and ATAM Outputs, Correlated
167. Context for the CBAM (Cost Benefit Analysis Method)Artifacts documented on completion from ATAM:
A description of the business goals that are crucial to the success of the system
A set of architectural views that document the existing or proposed architecture
A utility tree that represents a decomposition of the stakeholders' goals for the architecture, starting with high-level statements of quality attributes and ending with specific scenarios
A set of risks that have been identified
A set of sensitivity points (architectural decisions that affect some quality attribute measure of concern)
A set of tradeoff points (architectural decisions that affect more than one quality attribute measure, some positively and some negatively)
168. 168The Basis for the CBAMUTILITY
Variations of Scenarios
Priorities of Scenarios
Determining benefit and normalization
169. 169Sample utility-response curves
170. 170Determining benefit and normalizationWe calculate the overall utility of an architectural strategy across scenarios from the utility-response curves by summing the utility associated with each one (weighted by the importance of the scenario). For each architectural strategy, i, we calculate a benefit, Bi as follows:
where bi,j is the benefit accrued to strategy i due to its effect on scenario j and Wj is the weight of scenario j. Referring to Figure 12.2, each bi,j is calculated as the change in utility brought about by the architectural strategy with respect to this scenario: bi,j = Uexpected – Ucurrent; that is, the utility of the expected value of the architectural strategy minus the utility of the current system relative to this scenario. The effect of multiplying the weight, Wj, is to normalize this utility value by the relative importance of the various scenarios, as already described.
171. 171Calculating ROIThe ROI value for each architectural strategy is the ratio of the total benefit, Bi, to the Cost, Ci, of implementing it. The cost is calculated using a model appropriate for the system and the environment being developed.
Using this ROI score, the architectural strategies can be rank-ordered; this rank ordering can then be used to determine the optimal order for implementation of the various strategies.
Consider curves (a) and (b) in Sample utility-response curves. Curve (a) "flattens out" as the quality attribute response improves. In this case, it is likely that a point is reached past which ROI decreases as the quality attribute response improves. In other words, spending more money will not yield a significant increase in utility. On the other hand, consider curve (b), for which a small improvement in quality attribute response can yield a very significant increase in utility. There an architectural strategy whose ROI is too low might rank significantly higher with a modest improvement in its quality attribute response.
172. 172Implementing the CBAM - Process flow diagram
173. 173Software Architecture in the FuturePrediction is very difficult, especially about the future.
—Niels BohrGrowth in the types of abstraction available over time
219. Multi-tier Internet Architecture with Java, UML and OOA & DThe SOAS is based on a n-tier architecture design with client (SPOT), application server (SOAS), and data (DBMS) tiers, see UML Deployment Diagram in Figure 1. The SOAS is comprised of the WebLogic Application Server, Java 2 Enterprise EditionSDK and the Solaris operating system. All software runs on Sun hardware. The communications protocol between client and server is HTTP. Use of this protocol allows any Java or browser client with Internet access to communicate with the SOAS. Back end services (Data and Visibility) may select the most appropriate protocol suitable for integration with the SOAS.219
220. Design & Analysis
Applying OOA&D techniques on the high-level architecture reveals the set of SOAS components shown in Figure 1.
SOASAPI - The interface to the clients of the SOAS (SPOT and web browsers),
SODB - Science Operations Database object abstraction layer,
SODB SQL - Structured Query Language persistence layer to the RDBMS for SODB,
Request Handler - Interface definition for SOSAPI services,
AIRE Handler - Implementation of the Request Handler interface for AIRE services,
Coordinate Conversion Handler - Implementation of the Request Handler interface for Coordinate Conversion services,
Visibility Handler - Implementation of the Request Handler interface for visibility window calculations. Implementation
The implementation of the SOASAPI is based on the Java Servlet API. The SOASAPI servlet is hosted by the WebLogic Application Server. All clients communicate with the SOASAPI using a Uniform Resource Locator (URL) that corresponds to the requested service. There is a one-to-one mapping between URLs and SOASAPI services. The AIRE Visibility, SODB SQL components are implemented using the Java Enterprise Java Beans (EJB) API. The EJB components are hosted by the WebLogic Application server. Clients access the EJB components through the SOASAPI.
Services：Based on the URL the SOASAPI invokes the Request Handler to process that service. At initialization the available services are registered with the SOASAPI. The invocation of a particular service is encoded in the URL. Once the service has been determined the execution of the service is delegated to the appropriate Request Handler implementation.220
SODB Data Beans: The SODB data beans encapsulate the database schema and SPOT ASCII file format. These data beans are also used to transfer data to/from the Java clients via Java object serialization. The SODB data beans support multiple version of the database schema through overrides of the default object serialization mechanism. This has been done to support backwards capability for the client ASCII file format. The SODB also contains a framework for intelligent of storage and retrieval of the data beans across the Internet. A partial SODB class hierarchy is shown in Figure at next slide.
System Monitoring & Control: Another set of services the SOASAPI provides are for system monitoring and control. A standard web browser is used to access these services. These services include：
Ping - check system availability,
Display Configuration - display the system configuration,
Reload Configuration - reconfigure the API dynamically.
Also provided by the WebLogic Application server is a system monitoring application.
Software Deployment: Initial deployment of the SPOT application is accomplished by the download and installation at the client workstation. From this point updates are processed using two methods. The first is a download of the complete updated application as mentioned. The alternative is to contact the SOAS for software updates. 221
223. Multi Tier Architectures for Database ConnectivityThe 3 Tier approach which employs a deep separation between the application and the broker. (Stand-Alone Broker).3 TierComplexMonolithicBrokerSingle PointfailureRigid/DifficultLoad Balancing2 TierSimpleDistributedBrokerFault TolerantFlexibleLoad Balancing3 Tier Architecture2 Tier ArchitectureThe 2 Tier approach which integrates the broker into the application components. (Integrated Broker).223
224. Advantages of the 2 Tier ArchitectureSimplicity: By taking advantage of the ability to run internal broker threads, the 2 Tier approach avoids the complexity involved in designing and implementing a stand-alone broker. Implementing a broker thread is as simple as creating a new instance of a class.
Distributed Broker:The 2 Tier approach benefits from the ability to easily distribute the brokering task between as well as within application components.
Fault tolerance:A distributed broker design is fault tolerant -- a failure in a single application component affects only its own database connection pool.
Flexible Load Balancing:The 2 Tier architecture allows for a large degree of flexibility in the load balancing largely due to its distributed nature.
Customized Housekeeping:Because broker threads can be scaled and distributed freely, the designer of an application has enormous flexibility in shaping the system to handle new and complex situations.224
The JBoss Microkernel is a set of MBeans that runs on top of JBossMX.
It has been designed to be totally modular from the ground up.
Support classes exists to extend the notion of an MBean into a Service or Deployer
Small memory footprint
Classloading Management - everything except the kernel is HotDeployable
Pluggable Deployers - you can deploy anything from your own custom config
Fully Configurable - the bootstrap process is both configurable and replaceable
NetBoot - ability to bootstrap from a tiny resident loader
Lifecycle and dependency management - full two phase lifecycle
Component configuration - using JMX and PropertyEditors
Management - it is based JMX on a Bus (the MBeanServer)What is the JBoss Microkernel?226
Overview - a brief overview of the architecture
Source Tree - a brief overview of the source tree
Bootstrap - a quick walkthrough of the bootstrap
Parameters - parameters passed to the JBoss startup scripts
Properties - properties used by the JBoss Microkernel
boot.log - logging during the bootstrap
Service - how to write services
Deployer - how to write a deployer
Requirements for the new POJO microkernel with its own forumWhat is the JBoss Microkernel?227
228. The microkernel has three main components:
- this is the bootstrap/controlling service
- the jmx implementation
- additional services and support classes
The server is responsible for the bootstrap. It instantiates the jmx MBeanServer,
registers itself, and a couple of other MBeans for basic management.
Finally it adds the deployers.
The JMX implementation provides the BUS onto which all services are registered.
It also provides the classloading implementation that enables HotDeployment.
The JBoss Microkernel is made up of three distinct components:Jboss Microkernel Overview228
229. Service Management
- instantiates Services
- configures Services
- manages Service lifecyle and dependencies
MBean abstractions for the components that make up a server Services
an abstract service with support for lifecycle management
- an extension to a service that is capable of deploying other services.
- for monitoring and redeploying changed configuration
- a common meta data object for deploymentsDeployers
The deployers are responsible for creating other services from configuration.
The three core deployers are:
- a registry of deployers that knows about all deployers
- for deploying jar and zip archives
- for deploying service archives The System Components229
230. 230GOF的23种设计模式 ADAPTER（适配器模式）：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
CHAIN OF RESPONSIBLEITY（责任链模式）：在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
242. 上面的图从应用程序角度展示了企业级 SOA 所包含的元素。业务流程由用户界面应用程序和服务应用程序进行部分和完全支持。业务流程中的一个步骤或者通过人工执行，或者得到用户界面应用程序的支持。用户界面应用程序实现了许多宏工作流，而且 它们还使用实现业务功能的服务。 在服务编排层，组合服务是通过编排语言（例如业务流程执行语言（Business Process Execution Language，BPEL））定义的。组合服务的编排通过基本服务定义其流程和组成。编排层应由支持图形规范的编排工具提供支持，基本服务（由服务编排层使用，也由用户界面应用程序使用）通过服务应用程序实现。而服务实现又可以调用其他服务，这些服务通常来自另 外的服务应用程序。
2）业务敏捷是基本的业务需 求。提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统以上的整个架构都必须满足业务敏捷 的需求，因为，在 SOA 中任何的瓶颈都会影响到整个 IT 环境的灵活性。
3）成功的 SOA 总在变化之中：SOA 工作的场景，是一个活的生物体而不是像传统所说的“盖一栋房子”。IT 环境惟一不变的就是变化，因此面向服务架设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求有崭新的思维方式。SOA应用程序242
244. 1、可扩展的标记语言（XML）。 一种跨企业的、
2、Web服务（Web Service）。 一种基于 XML
3、面向服务的架构（SOA）。 一套用于实现应用间的互操作，以及重用 IT 资产的方法，具有以下特征：对架构方面（治理、过程、建模、工具）的强烈关注、具有恰当的抽象层次，有利于促进业务需求与技术能力的配合与协调，以及致力于创建可重用、粗粒度的业务功能、是一种适于快速、方便的构建新应用部署的基 础设施、 一个用于常见业务与 IT 功能的可重用复用库。
4、业务流程管理（Business Process Management - BPM）。 用于自动化业务操作的方法和技术，包括：清晰地描述业务流程，以便于理解、改进和优化、易于针对业务需求的变更，快速修改业务流程、把原来由人工完成的业务流程自动化，并实施相应的业务规则、为决策者提供有关业务流程的实时信息与分析。 这些技术都已经对业务计算的一个或者多个方面产生了深远影响，现在要做的就是把它们融合起来，就可以提供一个综合平台，这个平台有助于获得面向服务的优 点，并且在 IT系统的发展进程中走向下一个阶段。面向服务的企业244
2 ）效率：通过组合现有服务，以快速创建新的服务和业务应用的能力，可以集中精力于 数据共享，而不是底层实现的能力；
3 ）与技术的松耦合：独立于服务的执行环境进行服务建模的能力，关注 以服务能够收发 的消息，而不需要考虑具体的技术实现。
5）构建企业级的 SOA 系统架构的时候，需要特别注意的是对于服务粒度的控制。由于服 务的访问通常是远程的，推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于 企业系统架构的内部。
6）应用服务来设计、开发和部署应用，需要把 IT部门的职责划分为：1）创建服务：处理 服务所涉及的复杂的下层技术，确保 Web 服务的描述与服务消费者的需要相一致，而 且双方共享着应该有的数据。2）使用服务：组装新的合成应用（Composite Applications）和业务流程流（Business Process Flows），确保共享数据 以及业务流程流能够准确反映业务的运营和战略需求。
6）在项目层次上，可重用的服务层把业务操作与下层软件平台的实现差异相隔离。这样， 就有可能具备把可重用的服务快速组合成更大服务的能力，组织就具备了使过程自动 化和快速适应环境的优点。245
263. SOA 的业务效益1、增强业务的机动性。
目前对许多机构而言，对新业务需求与快速响应的业务机动性，是比开发效率还要重要的。业务机动性两个关键要素是速率 和灵活性。速率指的是沿着既定的路线快速前进，更快的产品或者服务的上市速度。 SOA显著降低了利用现有服务和 IT 资产组装新业务应用所需的时间，因而提高了速率。灵活性是根据需要适应 IT 系统的能力。由于不断变化是业务和软件所必须面对的现实，而且也是开销的主要源头，因此，在 IT 可以迅速修改现有系统的情况下，业务可以快速适应新的机遇与竞争威胁。
当所有的业务都为共同的目标和结果提供支持的话，就称之为配合（alignment）。我们可以而且应该把 IT 系统通过SOA提供的服务定义为直接支持组织向顾客、客户、公民与合作伙伴等提供的服务。用面向服务的架构做到业务与 IT 的相互配合，可以改善业务的设计与开发，这是通过业务用户与 IT 技术的要求沟通更加流畅做到的，这也有助于把交流提升到业务层面。
许多机构都致力于建立一种在不同的服务渠道（面对面、Web自助服务、移动用户、呼叫中心、ATM等）一致的用户体验，如果客户从不同的渠道获得自相矛盾的信息，客户满意度就会下降。以客户为中心的 SOA 致力于确保一致的用户体验，通过创建与任何具体技术和最终设备无关的服务来实现，将更加容易重用于各种服务渠道。263
传统的 IT 系统中，对厂商技术的依赖发生于各个层面上： 1）应用平台（如J2EE、.NET框架、Oracle、CICS）；2） 套装应用软件（如 SAP、PeopleSoft等）；3）中间件技术（如 WebSphere MQ）；4）特定产品功能（如存储过 程、群集缓存）。 应该注意到，如果中断与套装应用软件、开发平台、中间件系统的长期关系，是需要付出很大代价的。 SOA为机构提供了发展空间以适应未来的发展，并显著降低了对厂商技术的依赖。因为以 SOA为中心的机构是基于服务契约来构建下层 IT 架构的，该服务契约与业务服务层是一致的，并且技术中立、与应用无关和不了解中间件的。这种层次结构更容易替换应用程序、技术和中间件。
6、提高现有的 IT 资产投资回报率
因为架构的 IT 资产被重用为服务，确定现有系统的关键业务能力，然后把它们作为构建新服务的基础，这样，SOA有助于最大化现有 IT 投入的价值，并降低风险。但是要注意到不是所有的 IT 资产都能够被重用，所以需要一个评估和筛选的过程，这个过程必须特别注意抽象接口的定义，这样的接口应该能够既体现业务功能的本质，又封装了技术细节。SOA 的业务效益264
266. 1）可靠性 SOA还没有完全为事务的最高可靠性包括不可否认性(nonrepudiation)、消息一 定会被传送且仅传送一次（once-and-only-once delivery）以及事务撤回（rollback） 等做好准备，不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。
2）安全性 在SOA 环境中，由于一个应用软件的组件很容易去与属于不同域的其他组件 进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。
3）编排 (Orchestration) 建立在 SOA 上面的应用软件被设计成可以按需要拆散、重新组装 的服务。作为目前业务流程管理（BPM）解决方案的核心，编排功能使 IT 管理人 员能够通过已经部署的套装或自己开发的应用软件的功能，把新的元应用软件 （meta-application）连接起来。最大的难题不是建立模块化的应用软件，而是改变这 些系统表示所处理数据的方法。
4）遗留系统处理（Legacy support） SOA 中提供集成遗留系统的适配器，遗留应用适配器 屏蔽了许多专用性 API 的复杂性和晦涩性。一个设计良好的适配器的作用好比是一 个设计良好的 SOA 服务：它提供了一个抽象层，把应用基础设施的其余部分与各 种棘手问题隔离开来。一些厂商就专门把遗留应用软件“语义集成”到基于XML的集 成构架中，但是集成遗留系统的工作始终是一种挑战。
5）语义（Semantics）定义事务和数据的业务含义，语义关系是设计良好 SOA架构的核心 要素。 采用XML技术也许是一个不错的主意。 会计行业已提议用可扩展业务报告 语言（XBRL） 来描述及审查总账类型的记录。重要的是学会如何以服务来表示基本 的业务流程。改变开发方式需要文化变迁。SOA 需要解决的问题266
267. 6）性 能（performance）：批评 SOA 的人士经常会提到性能是阻碍其采用的一个障碍，但 技术的标准化总需要在速度方面有一些牺牲：SOA的分布性质和 Web服务协议的开销。 所以，在应用 SOA架构之前，必须搞清楚它的适用范围。
7）松耦合和敏捷性要求之间的权衡难题：服务松耦合设计其实是一把双刃剑，在带来应变 敏捷性的同时，也给业务建模和服务划分带来难题。这就是在SOA讨论中业务建模的争 论总是最多的原因。
8）跨系统集成难题： 面向服务的架构设计将跨越计算机系统，并且还可能跨越企业边界。 我们不得不考虑在使用 Internet 时安全性功能和需求，以及如何链接伙伴的安全域。 Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计的，但是我们需要 确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。
9）SOA 与网格计算（Grid Computing） 的关系： 网格计算（Grid Computing）是利用互 联网技术，把分散在不同地理位置的计算机组成一台虚拟超级计算机。每一台参与的计 算机就是其中的一个“节点”，所有的计算机就组成了一张节点网--网格。网格计算基于因 特网，提供了资源整合和共享的平台，十分适合作为 SOA 架构的实施平台，网格为 SOC 计算的有效性、快速性、灵活性、伸缩性和计算环境的管理提供便利。SOA 需要解决的问题267
面向服务的架构可以基于现有的系统投资来发展，而不需要彻底重新创建系统。通过使用适当的 SOA 框架并使其用于整个企业，可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内部细节以及在组成服务的组件之间传送 的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、 用不同的编程语言开发的组件来创建服务。遗留系统可以通过 Web 服务接口来封装和访问。
服务是位置透明的，服务不必与特定的系统和特定的网络相连接。服务是协议独立的，服务间的通信框架使得服务重用成为可 能。对于业务需求变化，SOA能够方便组合松耦合的服务，以提供更为优质和快速的响应，允许服务使用者自动发现和连接可用的服务。松耦合系统架构使得服务 更容易被应用所集成，或组成其他服务，同时提供了良好的应用开发、运行时服务部属和服务管理能力。提供对服务使用者的验证 （authenticatio）、授权（authorization），来加强安全性保障，这一点也优于其他紧耦合架构。 SOA 带给企业什么？ 268
269. SOA 带给企业什么？ 3） 统一了业务架构，可扩展性增强
在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合 并在一个定义良好的 SOA 框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑，增强了可扩展性。又由于面向服 务的敏捷设计，在应对业务变更时，有了更强的“容变性”。
组织的 Web 服务库将成为采用 SOA 框架的组织的核心资产。使用这些 Web 服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。 SOA 减少了开发成本，提高了开发人员的工作效率。 市场和制度的不断变化，要求组织具有相当的灵活性，软件架构师提供一种通用的、基于服务的解决方案，将有助于实现组织的灵活性，也更容易实现生产力的提 高。尤其在为业务流程管理（BPM）奠定了 SOA 架构基础以后，企业就可以把思想集中于更高层次的问题，比如设计更好的业务流程，而不是考虑实现业务流程的技术细节。269
270. 270What Makes a “Good” Architecture?（插在slide91的后面）Process recommendations:
The architecture should be the product of a single architect or a small group of architects with an identified leader.
The architect (or architecture team) should have the functional requirements for the system and an articulated, prioritized list of quality attributes (such as security or modifiability) that the architecture is expected to satisfy.
The architecture should be well documented, with at least one static view and one dynamic view, using an agreed-on notation that all stakeholders can understand with a minimum of effort.
The architecture should be circulated to the system's stakeholders, who should be actively involved in its review.
The architecture should be analyzed for applicable quantitative measures (such as maximum throughput) and formally evaluated for quality attributes before it is too late to make changes to it.
The architecture should lend itself to incremental implementation via the creation of a "skeletal" system in which the communication paths are exercised but which at first has minimal functionality. This skeletal system can then be used to "grow" the system incrementally, easing the integration and testing efforts.
The architecture should result in a specific (and small) set of resource contention areas, the resolution of which is clearly specified, circulated, and maintained. For example, if network utilization is an area of concern, the architect should produce (and enforce) for each development team guidelines that will result in a minimum of network traffic. If performance is a concern, the architects should produce (and enforce) time budgets for the major threads.
271. 271Product (or structural) recommendations：
The architecture should feature well-defined modules whose functional responsibilities are allocated on the
principles of information hiding and separation of concerns. The information-hiding modules should include
those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the bulk of the software
from change should the infrastructure change.
Each module should have a well-defined interface that encapsulates or "hides" changeable aspects (such
as implementation strategies and data structure choices) from other software that uses its facilities. These interfaces should allow their respective development teams to work largely independently of each other.
Quality attributes should be achieved using well-known architectural tactics specific to each attribute.
The architecture should never depend on a particular version of a commercial product or tool. If it depends upon a particular commercial product, it should be structured such that changing to a different product is straightforward and inexpensive.
Modules that produce data should be separate from modules that consume data. This tends to increase
modifiability because changes are often confined to either the production or the consumption side of data. If new data is added, both sides will have to change, but the separation allows for a staged (incremental) upgrade.
For parallel-processing systems, the architecture should feature well-defined processes or tasks that do not necessarily mirror the module decomposition structure. That is, processes may thread through more than one module; a module may include procedures that are invoked as part of more than one process is an example of employing this principle.
Every task or process should be written so that its assignment to a specific processor can be easily changed, perhaps even at runtime.
The architecture should feature a small number of simple interaction patterns.That is, the system should do the same things in the same way throughout. This will aid in understandability, reduce development time, increase reliability, and enhance modifiability. It will also show conceptual integrity in the architecture, which, while not measurable, leads to smooth development.What Makes a “Good” Architecture?