Guideline: Identifying Components |
This guideline explains how to partition the system into subsystems, identify components, and assign responsibilities to components.
Relationships
Related Elements | Outline Component Model
Main Description
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 exsting 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 known as 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.
More Information
Concepts | Component
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.