This guideline explains how to partition the system into subsystems, identify components, and assign responsibilities
based on an analysis of one or more of the following:
· Business processes
· Business entities
· Business rules
· Use cases
· Non-functional requirements
· Existing systems
A number of project artifacts usually exist when you start your work. A stakeholder may have provided them, or you may
have created them as part of an earlier phase of the project. Review these artifacts to identify any components that
they suggest.
The following sections describe the key artifacts that you may use as input to identifying components.
Business processes
Business processes typically appear on diagrams made with drawing tools or business modeling tools. For example, A UML
activity diagram (as shown in Figure 1) may capture business processes.
Figure 1. Business processes using a UML
activity diagram
Initially, assign a component to each business process, and then assign responsibilities to that component based on the
activities the business process performs. You will not expose all of these responsibilities as interfaces or functions
in the final model. However, by examining business process models, you can initially assess the required functionality
and re-factor it later on.
The business model in Figure 1 indicates the need for some kind of Order Management component with these
responsibilities:
· Receive orders
· Fulfill orders
· Establish delivery arrangements
· Send invoice
· Handle payments
· Complete orders
Logical data model
If you have a logical data model, use it to identify components by
clustering related entities together, and then assigning each cluster to a managing component. See [Guideline Managing Data with Components].
Business rules catalog
Business rules describe the operations, policies, and constraints that an organization puts in place to achieve its
goals. Rules help the organization achieve its business goals by acting as a communication mechanism between the
organization and interested third parties. This is done by allowing the organization to meet its legal and other
statutory obligations. An organization can use rules to operate more efficiently by automating and analyzing rules to
look for time and cost savings.
Types of business rules include:
· Rules that provide the conditions to govern business behavior (legislative,
cultural, and business).
· Rules that provide the criteria for successful or unsuccessful completion of
an action.
· Rules that stipulate what other actions can or cannot be performed as a result
of successful or unsuccessful completion.
· Rules that specify the response to some external event that impinges on the
enterprise.
· Rules that govern relationships that apply among various business entities.
Identify and specify business rules during the requirements gathering process. Analyze those rules, and verify that the
architecture can support them. Place rules as responsibilities on one or more components. To properly place business
rules, address these questions:
· Is the business rule likely to apply
in every situation, or is it specific to a particular usage? This dictates the software layer in which to place the
business rule. Place rules as responsibilities on components in lower layers to make them reusable in many situations.
Place them in higher layers if they have very a specific usage.
· Is the business rule likely to change
frequently, or is it fixed for a given application? The answer to this question dictates how much flexibility you
must provide for updating the business rule. A business rule that is likely to change frequently may have more than one
algorithm associated with it. For example, encapsulate a rule that calculates interest rates as a fine-grained
component with an interface that simply executes that rule. You can then switch the component with another component
that provides a different algorithm. This is an example using the Strategy pattern [GAMMA95].
· Does the user of the application need
visibility to the business rules? The need for visibility dictates how much information needs to be provided on the
execution of the business rule. For example, in a loan application, you may need to query the basis on which a loan is
given. A user may also need to have the ability to change business rules. Place such rules carefully, so that changes
to one rule do not affect another, and also provide a query and an update interface.
· Where does the data that the business
rule uses reside? Locate components that handle a business rule as close as possible to the data that they need to
read or update.
· What middleware components are
available or mandated to manage business rules? If a rules engine has already been selected as part of the system,
use it. Specialized middleware components (such as WebSphere Message Broker) provide the ability to define, manage, and
run business rules. These components mandate where and how to place such rules.
Specify a rule as one of the following:
· A relationship between components. For example, an order must have one or more
line items.
· An invariant or constraint on the data managed by a component. For example, an
order number has to be eight characters in length.
· Pre- or post-conditions on an operation signature. For example, 'order amount'
must be less than some pre-defined limit for any given order.
· An algorithm that calculate results or manipulates or checks data in some way.
For example, the rule 'Validate Credit Card Number' would apply the standard algorithms issued by credit card numbers
to validate a credit card number format.
When placing business rules on components, be sure that the business logic only exists in one place. Of course,
business logic may be distributed. For example, field level validation of data is typically performed on the client
tier, and business-processing logic that acts on that data is usually performed on the mid-tier.
Be sure to address the logical units of work that each business rule needs when accessing data. Business rules must use
one or more transactions (logical units of work) when updating a database to ensure that the database is always left in
a logically consistent state. See [BEVINGTON00] for one proposed approach.
Use case model
Use cases are a well-understood technique for capturing functional requirements [COCKBURN01]. Analysis of a Use case
model is one of the most robust ways of identifying components. Identify the architecturally significant use cases and
analyze those. Architecturally significant use cases are ones that:
· Capture essential functionality of the system
· Exercise many architectural elements
· Challenge the architecture
· Highlight issues and risks
· Exemplify stringent demands on the architecture (such as performance
requirements)
· Are likely to change
· Involve communication and synchronization with external systems
When looking for architecturally significant use cases, try to apply the "80/20 rule." Identify 20% of the use cases
that account for 80% of the user activity and are most likely to drive out new components.
Identify components as follows for each use case:
· Initially define a component with the same name as the use case. For
example, a use case called 'Check Delivery Status' would result in a component of the same name.
· For each step in the use case that requires an actor to system interaction,
define a responsibility for the component to manage that interaction. 'Check Delivery Status,' which has the steps
shown in Figure 2, would result in the single responsibility 'obtain order status'.
· Some steps imply usage of data (order, customer, and so on). Create a
component to act as a 'manager' for that data ('Order Manager, 'Customer Manager' and so on).
· Identify new components if needed, or add responsibilities to an existing
component if it makes more sense to do so. Create a new component to handle a responsibility that does not naturally
fit anywhere, rather than trying to force the responsibility into an existing component.
Figure 2. Use case 'Check Delivery
Status'
The above approach is a "first-cut" at identifying components and their responsibilities. You will refine your
components later when you structure them.
For more complex use cases where you identify a number of components, show component interactions through one or more
Component Interaction Diagrams, as shown in Figure 3.
Figure 3. Component interaction diagram for use case 'Check Stock
Availability'
The above component interaction diagram was drawn while analyzing the use case shown in Figure 4.
Figure 4. Use case 'Check Stock
Availability'
Non-functional requirements
A non-functional requirement (NFR) is a quality or constraint that some part of a system must satisfy.
Qualities define the expectations and characteristics that the system should support. Qualities are usually categorized
as runtime or non-runtime.
Runtime qualities:
· Can be empirically tested (by monitoring the system)
· Are sometimes stated as the system's service level requirements
· Are also known as the observable qualities
· Provide value to the user of the system
Non-runtime qualities:
· Cannot be measured easily and may rely on other project metrics
· Are also the non-observable or development-time qualities
· Provide value to the operator of the system
Constraints are limitations or specifications imposed upon a solution. A constraint is something that cannot be
changed during the lifetime of the project. Constraints are usually considered non-negotiable (though should sometimes
be questioned).
There is always a trade-off between the three critical constraints:
· Scope
· Time
· Resources (people and budget)
When faced with architecting a new system, take into account the system's non-functional requirements, as well as its
purely functional requirements. Address these questions:
· Can the system be built using the
preferred or mandated technologies?
Mandated technologies may include the application development environment: Platform, operating system, middleware and
networking choices, and interfaces to existing systems.
· Will the system achieve its service
level requirements?
Service level requirements are typically defined in terms of performance, availability, and security.
· Can the system be operated and
managed?
Determine if your system needs to handle problem management (unscheduled events), change management (scheduled events),
and end user support (such as help-desk access).
In addition, there are usually certain products, or packages, and other constraints (such as standards or technology
choices) to which you must cater. These non-functional requirements may need specific components to be identified and
specified. Examples of such components include:
· Error processing
· Links to systems management services
· Audit
· Management Information Systems
· Scalability and availability (ability to run things in parallel, across
machines)
· Confidentiality
· Privacy
· Non-repudiation
· Authentication and authorization
To meet a number of potentially conflicting non-functional requirements, you may need to resolve a number of opposing
forces, as shown in Figure 5. If you resolve two or more opposing forces, you have a solution to a problem. Sometimes
patterns help resolve forces. Explore how the problem was solved before.
Figure 5. Requirements as opposing
forces
Often, two or more solutions exist, each with their pros and cons in terms of cost, feasibility, and other factors.
"Ultimately, every software-intensive system has an architecture, be it intentional or accidental. Every such architecture serves to hold back the forces upon that system in a manner that is
functional, economical, and elegant" [BOOCH04].
IT environment
The existing IT environment provides an inventory of the enterprise's installed applications, data, and computing and
network infrastructure. You may feature some or all elements in the architecture of the new system. For example, you
may reuse a particular database package. Review the IT environment and decide whether any of the components have
potential for reuse in the new system.
Do not confuse logical and physical components in one model. When working with logical components, represent existing
physical components to be reused by abstracting them as logical components. Note in the component description that the
actual implementation of this component has already been decided.
For example, suppose you have already decided that IBM WebSphere Message Broker is the messaging bus. To represent this
component in a logical Component Model, abstract it to a component called 'Message Bus' and capture in the component
specification that the implementation is IBM WebSphere Message Broker.
|