Reduce complexity with model-driven development, Part 1: Use the IBM Software Development Platform to develop end-to-end solutions

Document options Document options requiring JavaScript are not displayed Learn and share! Exchange know-how with your peers -- try our new Pass It Along beta app Rate this page Help us improve this content

Level: Intermediate

Milena Litoiu (mlitoiu@ca.ibm.com), Technical Designer, IBM

01 Sep 2004

In this series of articles, you learn how to use the IBM® Software Development Platform to develop an end-to-end solution -- from business process modeling and requirements definition to designing, constructing, testing, and deploying. Discover key integration points between the tools that comprise the IBM Software Development Platform. In this introductory article, you learn about the various roles involved in creating an end-to-end development cycle. You also get an overview of the tasks each role needs to perform and the tools they use.

Introduction

You face increasing complexity in the systems you build and maintain. The IBM Software Development Platform can ease your development challenges with a complete set of offerings to help you build, integrate, modernize, extend, and deploy software and software-based systems. This platform uses a business-driven development paradigm, which includes modeling business processes.

Modeling techniques can help developers more easily understand complex technical environments such as a business domain or the architecture of a proposed solution. They enhance communication among stakeholders with different technical backgrounds and among disparate teams within an organization or across multiple organizations. Model Driven Developement (MDD) places models in the center of the development process. In this series, you'll learn how to use the Model Driven Development approach to develop a business scenario.

Scenarios help to facilitate communication between those who request a system and analysts, architects, developers, and testers. Scenarios establish a common basis of understanding and identify use cases within that system. In this series, we'll analyze the current tooling support, suggest ways to improve customer experience through better tooling integration, and address specific tooling issues, such as end-to-end traceability.

Back to top

Use model-driven architecture

Object Management Group (OMG), a not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications, adopted an approach of using models in software development known as Model Driven Architecture (MDA). MDA addresses the development life cycle from within a framework of a standards-based, model-driven development approach. Standards used by MDA include Unified Modeling Language (UML), Meta-Object Facility (MOF), the XML Metadata Interchange (XMI), and the Common Warehouse Meta-model (CWM).

MDA uses modeling as the foundation for developing and maintaining applications. The role of the model becomes paramount, superceding the role of programming languages because MDA uses modeling languages as programming languages rather than as just design languages. With this approach, the model becomes the implementation. And as technology evolves, MDA provides you with a higher level of reuse and abstraction.

The MDA approach uses the following models:

• Computation-independent model (CIM)
• Platform-independent model (PIM)
• Platform-specific model (PSM)

A CIM does not show any system details and is often called the domain model because it is defined by business requirements. The CIM plays an important role in bridging the gap between requirements experts and design experts. The requirements experts focus on the business domain, whereas the design experts must connect new technology with artifacts to meet domain requirements that result in a PIM. Once the PIM is defined, the PSM (including the analysis and implementation models) can be generated using a transformation process based on the chosen implementation platform, as shown in Figure 1.

With MDA, you don't need to repeat the process of modeling a system's functions and behavior each time a new technology comes along. While preserving the intellectual property as platform-independent models, you can use automatic generators -- taking advantage of best practices and patterns in the industry as you transform platform-independent models to platform-specific ones. (For more information about MDA, see Resources.)

In this context, traceability between models becomes especially important because it allows you to:

• Ensure all requirements are met.
• Ensure that developers aren't "gold plating" (adding features beyond the requirements).
• Understand the impact of making changes.

In this series, we'll discuss the level of traceability in our current tooling story. We will also identify other traceability aspects to include in a future wish list and show the necessary steps to enhance our future tooling integration story.

Back to top

Understand the scenario

We use one of the IT tasks in the IBM developerWorks "Merging disparate IT systems" sample IT project to demonstrate model-driven development. The project is based on the merger of two hypothetical insurance companies:

• Lord General Insurance is a large enterprise with more than five million policy holders, looking to boost its auto insurance business and requiring a quick entry to the e-business direct insurance market. Lord General Insurance has a large legacy IT infrastructure based on IBM S/390® and IBM CICS® systems.
• DirectCar.com is a modern auto insurance company that sells insurance through the Internet and has less than one million policy holders. This enterprise has an e-business-focused infrastructure based on IBM WebSphere Application Server, Oracle databases, and IBM TXSeries®.

The scenario focuses on the merger of these two companies and has the following requirements:

• Improve the company's profitability by reducing overall administration costs, with an immediate focus on claims administration for existing products.
• Create an automated claims system for the joint customer base that connects the existing external services.
• Satisfy service-level agreements as defined in customer requirements (performance and security guidelines, for example).

We'll look closely at the automated assessment subprocess of the new claims solution, shown in Figure 2.

For more details about the scenario, see the article Merging disparate IT systems, Part 3: Design the external assessors solution.

Back to top

Develop the solution

In this section, you'll find out about the roles and activities performed in a typical end-to-end iterative development cycle. You'll map these activities to appropriate tools, or combination of tools, employed by each user role in this iterative process.

The roles definition can vary slightly from organization to organization. Even inside the same organization, different departments can use modified interpretations of the roles (for example, solution architect compared with software architect). It's important to make sure we use the same role definitions throughout the series. To achieve that consistency, we use the roles defined by the Rational Unified Process (RUP). (For more details on RUP, see Resources.)

Understand roles, activities, and tools

RUP defines the end-to-end development cycle as an iterative process, as shown in Figure 3.

A high-level mapping of activities to the appropriate roles is shown in Figure 4. Keeping RUP central to the software development process allows you to continuously focus on achieving quality and business performance throughout the life cycle.

As we mentioned earlier, this series of articles considers the analyst, architect, and developer roles, as defined by the RUP. In certain cases, we may need to differentiate between various kinds of analysts; for example, business requirements specialist compared with business process specialist. Or system analyst compared with test analyst, and so on. This discussion could be extended to include other equally important roles, such as project manager or tester, but for now, we will focus on the roles of the analyst, architect, and developer.

Each role is defined by its expertise and responsibilities. It's important that every role respects the boundaries of all the other roles, each of which has the necessary expertise for decision making. The architect should consider the business decisions made by the analyst, and the developer should take into account the architectural decisions made by the architect. In cases where choices at the IT level conflict with architectural specifications, the developer should negotiate a solution change with the architect. The tools themselves cannot enforce previously made decisions. However, you can take steps -- such as implementing a version-control system for artifacts and granting appropriate access rights -- to help reduce conflicting situations. A clear separation of responsibilities based on role makes the iterative process more efficient.

The analyst

The terms analyst and business analyst roles are interchangeable in this article. Analyst pertains to business modeling and requirements management. The analyst must make sure he understands the business needs and satisfies the demands of stakeholders.

The analyst role will be discussed in greater detail in upcoming articles. The high-level analyst tasks are to:

• Define the business requirements (requirements gathering).
• Define the business use cases and establish traceability relationships to the requirements (use-case models).
• Model the business processes. (The analyst can also define parameters to be simulated. Once the analyst is satisfied with the business process modeling, he can then deliver the process to the architect or developer.)
• Monitor the business measures he defined in the processes (run-time process monitoring). (This task typically occurs after the development is complete and the processes are deployed to the chosen run time.)

The analyst is responsible for requirements gathering, use-case modeling, process modeling, simulation, and run-time process monitoring. The typical sequence of analyst's activities is shown in Figures 5A, 5B, and 5C.

The architect

In this series, the term architect is used in association with the software architecture, to contrast her responsibilities with other architectural disciplines, such as hardware responsibilities. The architect makes key technical decisions that constrain the overall design and implementation of the project. She defines the architectural blueprints described in the use-case, logical, process, implementation, and deployment views.

It is likely that the architect and analyst use the same modeling tools, but typically the architect extends the business model by adding architectural and design artifacts to support the analysis and requirement models. Figures 6A, 6B, 6C, and 6D depict typical activities performed by the architect.

The architect determines the patterns that best apply for the solution architecture. She architects for scalability, extensibility, availability, reliability, security, and performance, based on specific system requirements. The architect may also refine the process model defined by the analyst by making decisions concerning the target run times and where the solution components are to be deployed.

The developer

The developer transforms the architectural models into their implementation-specific representations. This can be done by importing design artifacts between tools or with an integrated development environment that helps ensure consistency between the development stages. Implementation can be accelerated using code-level patterns, templates, and model-transformation methods following a rapid application development paradigm.

In this series, you'll learn how to:

• Deploy on heterogeneous run times
• Interface existing business processes with subprocesses (and can possibly include different formats and deployment languages)

You'll discover the answers to these questions:

• How do we interface existing processes with newer processes, potentially deployed on different platforms? Should both interfaces be changed? Or is it less complicated to only change one? What kind of mapper will we need to bridge the data structures representing the business processes interfaces?

Back to top

Use IBM tools to develop the scenario

As shown in Figure 7, the sequence of activities performed by each role suggests the appropriate tools from the IBM Software Development Platform.

For example, for the requirements gathering and management stage, we'll use IBM Rational RequisitePro. We'll also use Rational XDE for modeling. For business process modeling and simulation, we use IBM WebSphere Business Integration Modeler. The developer will use the WebSphere Process Choreographer from the WebSphere Studio Application Developer Integration Edition. We will also include a partner product, Bowstreet Portlet Factory, which acts as a plug-in to WebSphere Studio Application Developer Integration Edition to develop the client components for a WebSphere Portal environment.

Table 1 lists IBM tools from the software development platform and their usage by role.

Table 1. Development roles mapped to IBM tools

This list shows one possible path that leads from the requirements to a deployed and running process. Rational ClearCase® and Rational ClearQuest® are notably absent from our list. They are extremely useful to handle versioning, management, and tracking control and can be added to the picture. (See Resources for a comprehensive list of products that are part of the IBM Software Development Platform.)

How the tools work together

Figure 8 is explained in more detail in future articles. You'll get a close look at every tool and find out about important tool interactions. We'll discuss the tools and how they are used by each role. You will also understand important integration points for tools used by each role and how different roles can use the same tools. For example, the analyst might use Rational XDE mainly to create actors and use cases. The architect can use XDE for a variety of activities and is not limited to the use-case models.

Back to top

Summary

This series of articles about model-driven development focuses on using an end-to-end tooling perspective for the external claims assessor scenario in the merger of two companies. This introductory article helps to map the development roles to the IBM Software Development Platform tools that are used for the scenario. To find out how to define and manage requirements, read Part 2 in this series now.

Upcoming articles focus on:

• Rational RequisitePro and the art of gathering and managing requirements
• Rational XDE as a central tool for modeling business and design assets, and for possible asset code generation (Find out how each of the analyst, architect, and developer roles will use the Rational XDE tool.)
• WebSphere Business Integration Modeler and business process modeling, and Business Process Execution Language (BPEL) generation
• WebSphere Studio Application Developer Integrated Edition, to add the implementation detail into the business process and editor support for the application code assets (Development and deployment are the primary focus in this discussion.)
• Bowstreet Portlet Factory, a plug-in to WebSphere Studio Application Developer, as an example of adding a portlet face to the business process

Throughout this series, we'll highlight integration issues, the exchanges between roles, and the flow of development artifacts between tools. We will also focus on end-to-end traceability and its current level of support in our proposed tooling story.

Back to top

Acknowledgements

The author would like to thank:

• Mike Starkey, STSM, the lead architect of the System House Business Scenario team -- for your continuous help
• Lori Small, Sam McHan, Dave Stokes, and Alan Chivers -- for reviewing the article and making valuable suggestions
• Philippe Kruchten -- for taking the time for a detailed and pertinent review

Resources

• "An introduction to Model Driven Architecture - Part I: MDA and today's systems" (developerWorks, January 2004) examines the importance of models and modeling, introduces four key principles of MDA, and looks at the leadership role that IBM has played in defining the approach and its supporting standards.
  
  
• OMG Model Driven Architecture describes the architecture of choice for a changing world.
  
  
• IBM Software Development Platform provides an overview and list of products.
  
  
• Tune into IBM Distinguished Engineer Alan Brown's blog that explores model-driven development.
  
  
• The whitepaper "Realizing the IBM Software Development Platform" discusses enabling business integration and transformation, managing software assests throughout the software life cycle, and adopting an effective, open technology infrastructure.
  
  
• "Discover the IBM Software Development Platform: Tools for Implementing the Rational Unified Process," (developerWorks, March 2004) explores the IBM Software Development Platform, which powers the build component of the integrated roadmap.
  
  
• "Merging disparate IT systems, Part 3: Design the external assessors solution," (developerWorks, March 2004) describes the design approach for an extension to the consolidated claims system that automates an existing manual activity in an auto claims process.
  
  
• The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Addison Wesley, 2003), by Per Kroll and Philippe Kruchten, is an excellent reference on all aspects of the Rational Unified Process.
  
  
• Browse for books on these and other technical topics.
  

About the author

		Milena Litoiu is a designer with IBM Software Group System House Business Scenarios. She is currently investigating end-to-end tooling from a Model Driven Architecture (MDA) perspective. She is involved with prototyping and collaborating with various teams to understand how tools work together. She also advises product groups on platform integration issues. You can reach Milena at mlitoiu@ca.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top