Document Subsystem Origin
During 作業: Functional Area Analysis we identified a set of subsystems that
corresponded to the input received from a Component Business Map (see 概念: Component Business Modeling). During Process Decomposition, the identified
leaf-level activity nodes (概念: Business Process Decomposition) may be placed on the subsystems as the
operations or services that the subsystem, as a facade, will provide. The functionality of these operations will be
realized by the service component’s functional components. Also, you may choose to group these operations onto
interfaces that are offered by the subsystem. The operation non-functional requirements will be used to mine out
the technical components and services required within the subsystem.
It is important that the relationship between these identified subsystems and their original source be kept
in-place. In cases where both the business-level and service model work products are in UML, the dependency information
may easily be stored in the models; otherwise, such information should be stored in the 範本: Service Model in Word or held in an associated work product.
ISV Considerations: Services may be realized through existing subsystems such as custom applications, software
packages and/or Independent Software Vendors. As the following section explains, in some cases, identification of new
subsystems may involve physical grouping of services based on criteria such as data affinity, cost, performance etc.,
although subsystem identification is usually done top-down during Functional Area Analysis activity. The allocation of
the components to the architectural tiers, in order to satisfy architectural constraints imposed by non-functional
requirements, is explained in Service Realization.
Example
The output from the functional area analysis for an example rental agency was the following table:
Domain
|
Functional Area
|
Subsystem
|
Description
|
Marketing and Customer Management
|
Customer Service
|
Customer Service
|
Provides all automated functions for the functional area.
|
Products
|
Promotions Management
|
Promotions Management
|
Provides all automated functions for the functional area.
|
Rental Fleet Logistics
|
Fleet Management
|
Fleet Management
|
Provides all automated functions for the functional area.
|
Rentals Management
|
Rental
|
Rental
|
Provides all automated functions for the functional area.
|
Rentals Management
|
Reservations
|
Reservations
|
Provides all automated functions for the functional area.
|
Rentals Management
|
Pricing
|
Pricing
|
Provides all automated functions for the functional area.
|
The resulting UML model of the subsystems identified above would be the following, note that the subsystem dependencies
are already provided in the model shown below.
For each subsystem either the details described by the 構件: 設計子系統 should be documented, or may be
captured in the document-format service model (see 範本: Service Model in Word), in a form similar to the following.
Name
|
Reservation
|
Description
|
The Reservation subsystem is used to create and manage car rental reservations.
|
Interfaces
|
-
Reserve Vehicle
-
Modify Reservation
-
Get Options Information
-
Confirm Rental Agreement
-
Locate Reservation
-
Cancel Reservation
|
Functions
|
-
Reserve Vehicle
-
Modify Reservation
-
Get Options Information
-
Confirm Rental Agreement
-
Locate Reservation
-
Cancel Reservation
|
Dependencies
|
None
|
Non-Functional Requirements
|
None
|
|
Identify and Apply Service Component Patterns
In the 準則: Service Component Patterns we introduce not only the different kinds
of components that are commonly used to implement the subsystems identified during this task, but also a set
of patterns that allow for scalable and flexible implementations of these subsystems. The patterns, and of course
additional patterns exist - this is not a complete set - and may be specified as part of the architecture of a project.
Selection of, or customization of, a particular pattern will depend upon:
-
The Functional and Non-Functional Requirements of the solution and specific Subsystem.
-
The Capabilities and Qualities of Service provided by any middleware upon which the components will be deployed.
-
The cost/complexity and benefit trade-off between different patterns.
|
Identify Service Component
Subsystems, in and of themselves, are not IT assets and not deployable into the IT infrastructure; they provide a
bridge between the business and IT perspectives. Each subsystem is realized by one or more Service Components where
a Service Component is an enterprise-scale asset (a managed software element with guaranteed availability, load
balancing, security, performance, and versioning). The Service Component is in turn realized by multiple Functional and
Technical Components according to the diagram below.
Generally each service assigned to a Subsystem will result in a Service Component; Functional and Technical Components
may be shared between Service Components within the same subsystem.
|
Identify Functional Components
Functional components provide additional business function to a service component; in many respects, the capability
provided by a service component is dependent entirely on its functional components and any additional business logic it
implements on top of these.
Functional components are often to be found among Type Managers - components that manage a particular domain element,
for example "Vehicle", "Customer", "Schedule", and so forth. It should be made clear that these domain elements are
more frequently large-grained graphs of data rather than simple structures.
Example
Considering the Rent-a-Car example, the Reservation service component need to be able to pull together details about
the customer, the location they wish to hire from and the vehicles available for the class they specify. Also we need
to be able to determine the customer's rating such that we can provide the correct level of service in the event of
issues such as unavailable vehicles. The following diagram demonstrates the component model for Reservation.

|
Identify Technical Components
Technical, or Infrastructure, components serve to make available horizontal platform capabilities; that is the
capabilities they provide are not specific to the business domain but cut across business domains. These technical
services are frequently provided by middleware products including operating systems and are used either directly by the
service component or by the functional components on which they rely.
Example
In completing the Rent-a-Car component model (see functional component step above) we include two technical components
into the model, one for the Reservation to log the completion of a reservation request and one to denote that the
Vehicle and Location components rely on EJB Services to persist their business data.
Alternatively you can use a tabular format in expressing the required components and their relationship to the services
previously identified, as shown in the figure below.

|
將子系統行為分送到子系統元素
子系統的外部行為主要是由它所實現的介面來定義。當子系統實現介面時,它會確定支援介面所支援的每項作業。這個作業則由子系統所包含之設計元素(也就是 設計類別或 設計子系統)的作業來實現;這項作業可能需要與其他設計元素協同作業。
您應該利用顯示如何實現子系統行為的序列圖來產生子系統內模型元素之協同作業的文件。子系統所實現之介面的每項作業都應該有一或多個產生文件的序列圖。這個圖是子系統所擁有的,用來設計子系統的內部行為。
如果子系統的行為非常依賴狀態,且代表一或多個控制緒,在說明子系統的行為時,狀態機通常比較有用。這個環境的狀態機通常會結合主動類別,用來代表系統(這裡是子系統)控制緒的分解,這些狀態機是用狀態圖來說明,請參閱準則:狀態圖。在即時系統中,工作成果:封裝體的行為也是利用狀態機來說明。在子系統內,可能會有主動類別所代表的獨立執行緒。
在即時系統中,會利用工作成果:封裝體來封裝這些執行緒。
範例:
子系統執行某些系統必要行為的協同作業可以用序列圖來表示:
這個圖顯示如何利用子系統的介面來執行情境。明確地說,對於網路處理子系統而言,我們會看到子系統必須支援的特定介面(這裡是 ICoordinator)和作業。另外,我們也會看到 NetworkHandling 子系統會相依於
IBHandler 和 IAHandler 介面。
查看子系統內部,我們會看到 ICoordinator 介面的實現方式:
Coordinator 類別扮演 ICoordinator 介面的 "Proxy" 角色,它會處理介面的作業及協調介面的行為。
這個「內部」序列圖確切顯示哪些類別提供介面、內部必須發生什麼才能提供子系統的功能,以及哪些類別會從子系統中送出訊息。這個圖闡明內部的設計,對於含複雜內部設計的子系統而言,非常重要。另外,它也使子系統行為更容易被瞭解,使它成為可跨越不同環境來重複使用。
建立這些「介面實現化」圖之後,可能需要建立新的類別和子系統來執行必要的行為。這個流程類似於使用案例分析中所定義的流程,但我們是在處理介面作業,而不是使用案例。請針對每一項介面作業來識別現行子系統內必須用來執行作業的類別(在某些情況下,當所需行為很複雜時,也可能是內含的子系統)。當現有的類別/子系統無法提供必要的行為時,請建立新的類別/子系統(但要先嘗試重複使用)。
建立新的設計元素時,應該強制重新考量子系統的內容和界限。請小心避免在兩個不同的子系統中,有效使用相同的類別。這類類別的存在,隱含了子系統界限畫得不好。請定期重訪作業:識別設計元素來重新平衡子系統的責任。
建立兩個分開的內部子系統模型,將規格鎖定子系統的用戶端,將實現化鎖定實作者,有時會很有幫助。規格可包括「理想」的類別和協同作業,以便透過理想的類別和協同作業來描述子系統的行為。另一方面,實現化則更密切對應於實作,也許會發展成實作。如需設計子系統規格和實現化的相關資訊,請參閱工作成果準則:設計子系統、子系統規格和實現化。
|
產生子系統元素文件
如果要產生子系統內部結構的文件,請建立一或多個類別圖來顯示子系統所包含的元素及元素之間的關聯。一張類別圖應該已經足夠,但您可以利用更多類別圖來減少複雜度以及改進可讀性。
以下是範例類別圖:
訂單項目系統的類別圖範例。
當子系統內部的內容建模成元件時,它可以另外呈現在元件圖的元件矩形內。另外,我們也可以利用這個表示法,將這個子系統的互動點併入系統的其他部分中,也就是透過它的介面來完成這個動作。
以下是類別圖的範例,它說明訂單子系統和它的內部內容,以及其提供的介面和必要的介面。
訂單子系統的元件圖範例
由於元件是一個結構化類別,因此,您可以強迫遵循宣告的介面,通過埠來進行外部通訊,以便將元件嚴密封裝起來,從而增加它的規格和交互連接的精準度。我們可以利用這個表示法,透過連接器來「連接」組件的實例,讓這些實例在元件實作中扮演特定角色(請參閱概念:結構化類別,以取得其他資訊)。
以下是使用介面和埠之訂單子系統的組合結構圖範例。
訂單子系統的組合結構圖範例
另外,您可能需要利用狀態圖來產生子系統可能狀態的文件,請參閱技術:狀態圖。
子系統本身所包含的類別,由作業:類別設計來處理它的說明。
|
說明子系統相依性
當子系統所包含的元素使用另一個子系統所包含之元素的行為時,會在含括子系統之間建立相依性。為了增加重複使用,減少維護相依性,我們想既不透過對於子系統本身的相依性,也不透過對於子系統所包含之元素的相依性,而是透過對於子系統特定介面的相依性來表現這一點。
這有兩方面的原因:
-
只要兩個模型元素(包括子系統)提供相同的行為,我們想要能夠用一個模型元素來替代另一個模型元素。我們透過介面來指定必要的行為,因此,一個模型元素對於另一個模型元素的任何行為需求,都應該透過介面來表現。
-
我們想要讓設計者可以完全自由設計子系統的內部行為,只要能提供正確的外部行為即可。如果子系統中的模型元素參照另一個子系統中的模型元素,設計者就無法自由移除這個模型元素,也無法將這個模型元素的行為自由重新分配給其他元素。結果系統會變成更加脆弱。
在建立相依性時,請確定在子系統所包含的模型元素和其他子系統所包含的模型元素之間,沒有直接相依性或關聯。另外,也請確定在子系統和介面之間,沒有循環相依性;子系統不能既實現又依賴同一個介面。
在子系統之間的相依性,以及在子系統和套件之間的相依性,都可以直接依照下列方式來繪製。當如此顯示時,相依性會指出一個子系統(如發票管理)直接相依於另一個子系統(付款排程管理)。
使用直接相依性的子系統分層範例
當有可能用一個子系統來替代另一個子系統(它們有相同的介面)時,相依性可以畫到子系統所實現的介面,而不是畫到子系統本身。這會使任何其他模型元素(子系統或類別)能夠實現要用的相同介面。使用介面相依性可讓您利用可替換的設計元素來設計彈性的架構。
使用介面相依性的子系統分層範例
|
|