Laura Brown Ė principal consultant
1112 Riverbend Club Drive - Atlanta, GA 30339
PHONE: 770-953-0534 FAX: 770-952-7863
Developing UML Architecture for EAI Products
The EAI marketplace offers an attractive opportunity for software vendors bringing together the best features from data integration, middleware and application integration approaches. From screen-scraping to dynamic database calls, todayís products are converging into the fast-paced Internet market, with EAI and Internet technologies providing the much-needed unified interface to legacy systems.
Benefits of UML Architecture
To help customers understand how their software really works, EAI product vendors can utilize the Unified Modeling Language (UML). Designing technical architecture for EAI products in UML delivers the following benefits:
- Clarifies product architecture so customers understand how your products are configured and how they will be installed in the customerís organization. This approach can allay customer concerns about allowing EAI products to interface directly with sensitive legacy systems.
- Provides system context for all project participants. Context-oriented models support integration efforts and help to avoid problems with local optimization of system substructures resulting in suboptimal conditions for the whole system.
- Supports sales and service by including user-friendly UML use case and collaboration diagrams in sales collateral and customer training materials.
- Enables tailoring of a dynamic model for presentation to multiple groups that participate in the contract and development process (client project managers, vendor technical team, management of both vendor and client).
- Captures specific, detailed information for RFP/RFI and purchasing contract negotiations.
- The ability to visualize solutions provides a key step toward achieving CMM and other quality certifications for both the vendor and the purchasing company. (CMM certification results from establishing an environment for quality, and is recognized by passing an evaluation based on the Carnegie Mellon Software Engineering Institute's Capability Maturity Model.)
- Supports allocation of work resources. UML architecture modeling helps partition both the technical functionality and the development resource for building system components.
Process for building an architecture
The following process has been developed over the course of several EAI projects. The model seen in Figure 1 provides a step-by-step guide to the overall process of developing architecture for EAI products.
The process model for Developing EAI Architecture shows the steps of the overall process that are followed to build a set of architecture models for EAI products.
The steps of the process are listed below, and detailed instructions for performing each step follow:
1. Define your goals and priorities
2. Identify participants and roles
3. Determine architecture requirements (components)
4. Gather project/system information (interviews, doc, etc.)
5. Develop 1st iteration architecture models
6. Review & improve (adding sufficient detail)
7. Present final deliverables (may be ongoing)
1. Define your goals and priorities
Defining your goals and priorities for the architecture development will provide a road map for the project to follow. Your goals may include one or all of the benefits listed above in the
"Benefits of UML Architecture" section of this article, or other goals specific to your situation. Getting clear about which goals you are pursuing and the order of their importance is very important to building a project that your organization can support.
2. Identify participants and roles
Determine which areas of your company are affected by the product in question, and which customers and suppliers might also have a role in architecture definition. Affected areas may include some or all of the following:
- Sales and marketing
- Research and development
- Engineering and design services
- Customer service and support
- Customer focus group or specific client
- Fulfillment and installation groups
- Contract groups and legal advisors
- Standards bodies both internal and external (customer)
- Customer review boards that will evaluate results
After determining whoís involved, you need to define what role individuals will play in the project. Contributor, leader, subject matter expert, reviewer and coordinator are some of the roles required.
3. Determine architecture requirements
Set initial goals for the types of models that should be included in your product architecture. This list should be revisited occasionally and updated as the project proceeds. Some typical deliverables for product architecture include the following:
- Use cases
- State charts
- Use case activity diagram
- User interface overview
- System class relationship diagram
- System blueprint diagram
- Component responsibility model
- Deployment model
- Use case sequence diagram
- Technology inventory
- Risk assessment
4. Gather project and system information
Interview your companyís subject matter experts and conduct research and interviews with outside experts to gather relevant project and system information. Business processes and information should be documented and evaluated for reengineering requirements. Existing documentation and requirements statements can provide a starting point for modeling efforts. Training and user documentation often provide clear descriptions which can be converted to use case documentation. Depending on the goals of your architecture, client interviews may fill in the blanks on requirements modeling.
5. Develop 1st iteration architecture models
Using the materials gathered in step 4, develop a first draft of the most significant architecture models, including use cases, both graphic and narrative, collaboration diagrams illustrating the most important use cases, and high-level class diagrams for data architecture. Components can be identified in class diagrams, and employed in collaboration diagrams. Depending on reengineering requirements, business models may be elaborated for this step. Component responsibility, deployment models and technology inventory will be detailed as the required information becomes available.
6. Review & improve
First iteration models should be reviewed with the parties identified in step 2 above, including any members of reviewing boards that must sign off on the project results. Reviewers should be apprised of project plans early in the process to reduce the risk of expensive surprises at project conclusion. As participant buy-in is achieved, models are carried to sufficient levels of detail to deliver the identified goals of the architecture.
7. Present final deliverables
Architecture development will typically include a milestone or milestones for reporting of results achieved by the project. Architecture components are often delivered in the automated tool in which the models were developed, so that they can be extracted and embedded into various types of development and project documents. This process may be ongoing, as in the case of multiple releases of products that are delivered in response to dynamic requirements definition.
Addressing Architecture Issues Specific to EAI Products
Different types of vendor software products present their own kinds of challenges to the software designer and architect. Some products require excellent representation of the business processes they automate, others concentrate on data analysis of the business information required. EAI products touch on both these issues, but have specific concerns in the following areas:
- Layers of code add to complexity
EAI products execute in between other systems. They introduce layers of complexity by handling retrieval, clean-up and conversion tasks on data, functionality and metadata stored in legacy systems. Therefore, these systems experience a high need for encapsulation of error-handling procedures and tasks performed, so that the integrity of existing systems environments is maintained, and problems are resolved quickly.
- Need for non-linear modeling techniques
Not specifically process-oriented, EAI products are often self-referential, and therefore can be difficult to model. Just as data warehousing employs its own style of modeling that addresses non-linear functionality in programs, the middleware-style EAI product set requires special modeling techniques. EAI modeling techniques must enable integration of data, compartmentalization of function and accurate handling of events.
- Interfaces and metadata
EAI systems often generate no distinct or original data at all, providing instead the ability to manipulate data from legacy systems by providing a unified interface to those systems. UML architecture models can introduce the use of specialized classes to model these front ends.
- Customized reuse of product components
Performing the same function for divergent systems, EAI products lend themselves to reuse through customization of product components. Modeling architectures must supply the ability to develop and manipulate reusable components to accomplish specific tasks.
Example Solutions to EAI Issues
Synergistic Solutions, Inc. (SSI) is a vendor of EAI software for telecommunications companies. Their products focus on customer provisioning of high-capacity services such as DS1 and DS3, developing systems that provide a unified, GUI interface to legacy applications (Operational Support Systems, mostly). Their systems pull together information from many legacy systems and present it to design engineers so those engineers donít have to deal with multiple systems, because there is a huge learning curve on those legacy systems.
SSI called upon System Innovations when their products had been accepted by a major telecommunications company, with the one provision that those products would be designed and documented in UML, with particular emphasis on the product architecture. The purchasing company told SSI they would require a stringent review of SSIís product architecture, as delivered in the Unified Modeling Language.
The examples that follow include some of the models that were developed for SSIís product suite. They were originally published with permission in Lauraís book Integration Models: Templates for Business Transformation (SAMS, 2000).
Layers of code add to complexity
NetFlow is a product SSI makes that helps correct problems in the administration of hardwired elements in the Operational Support Systems (OSS) that are commonly used to administer them. These OSS systems are not designed to handle certain configurations of network elements that actually occur in the field, with the result that there are interruptions to the flow of the process of managing those disallowed configurations. The NetFlow product helps design engineers by identifying those configurations,
"fixing" their entries in a special database, and informing the OSS of their existence.
The model shown in Figure 2 was developed to capture the use cases that describe the desired functionality of the NetFlow product. It uses the Tree structure to depict the possible branches in functionality, ending in more detailed possibilities on the right side of the diagram.
The NetFlow Use Case Tree defines the desired functionality for a middleware product.
The highest level of function for this product is the administration of hardwired elements. That function is composed of the following sub-functions:
- Build and maintain the hardwired database
- Poll and manage the work list that conveys the information from and to the legacy systems
- Find hardwired elements
Under the "build and maintain the hardwired database" function, the
"build database" function is composed of the following:
- One time automatic build
- Manual build
The "maintain database" function includes
- Update based on Cable Pairs job
- Update as found in the field
Finding hardwired elements consists of finding and posting the service order so that it flows properly through the process for the variety of possible configurations (F1 Cable Pairs hardwired to Object Repeater Bay to Multiplexer, Object Repeater Bay to Multiplexer, and so forth).
The Use Case Tree provides encapsulation of functionality at a high level. A similar Use Case Tree is developed to capture all requirements for error-handling and error message processing. Use Cases are subsequently resolved into collaboration diagrams, which depict one scenario for each significant use case. Scenarios model the objects that collaborate to deliver those use cases. To show how NetFlow works, the team develops a generic model of the core middleware that controls processing of NetFlow, which is a product called the Business Process Server (BPS).
Need for non-linear modeling techniques
The BPS is a generic support process, which accesses a common database, developed in Oracle, to configure its rules, queues, and external interfaces based on the start-up command line. When running, the BPS spawns the pre-determined number of remote system interface processes, which can interface with remote systems with a number of protocols including EHALAPI, sockets, and ODBC. The BPS loads and executes the pre-determined business rules for its start up defined role.
Class diagrams and collaboration diagrams are used to specify the components of the BPS and show how they collaborate. Then those components are reused in the collaboration diagrams that depict the scenarios for another SSI product, the NetLocate system, seen in Figure 3.
The NetLocate collaboration diagram shows how this EAI product accesses remote data sources through pre-defined BPS components.
The non-linear and self-referential nature of the BPS is modeled and captured in class diagrams so that components can be reused in collaboration diagrams.
Interfaces and metadata
As is the case for many EAI products, NetLocate and NetFlow provide interfaces to legacy systems that maintain intricate rules (or metadata) for accessing data and functions inherent to the legacy systems. EAI products providing access to legacy data can be modeled with the introduction of a UML metadata class type, which stores the rules for data access.
Other EAI features provide a unified front-end to the functionality of legacy systems. UML architecture models can utilize the Facade class to model these front ends, introduced by Gamma et al in the book Design Patterns: Elements of Reusable Object-Oriented Software. Similar to the more familiar concept of database views, the Facade class can be used to depict a window upon functionality resident in legacy applications.
Customized reuse of product components
SSI uses a layered UML model to depict the system blueprint diagram for its NetLocate product. The model in Figure 4 helps the client purchasing this system to understand the intended architecture and what will be required to deploy the product in a particular environment. It also helps SSI reuse the components of existing products to formulate customized new products for clients.
Synergistic Solutionís NetLocate product models the systemís component architecture in UML.
The NetLocate system blueprint diagram organizes the components of the system into layers, including:
- Application specific
Oracle-stored procedures that are used to access the Oracle database and the database belonging to certain remote systems from which NetLocate retrieves data
- Application general
Web browser and HTML coding used to provide user access to the retrieved data
Components specific to the NetLocate product such as application and Web servers and program DLLs and executables required to provide system functionality
- System software
Operating system and Oracle database management system
The layered model shows the required components from the architecture viewpoint. Subsequent models, such as the component responsibility model, reorganize the components according to their interaction and the functionality they collaborate to deliver.
As can be seen from the example solutions, there are many ways that UML can support the definition of architecture for EAI products. It provides a flexible language for developing component-based solutions and creating accessible models of function, data and the required collaboration of components. Combined with a workable method for designing product architecture, the UML can help EAI vendors make their products more understandable, attractive and accessible to customers.
(Reprint of an article by Laura Brown, first published on InformIT's guest expert
page. For further information contact: firstname.lastname@example.org.
All rights reserved.)