Level: Intermediate Laurence England (englandl@us.ibm.com), Senior Technical Staff Member, IBM
Michael D Connor (connomon@us.ibm.com), Enterprise Tooling Market Manager, IBM
01 Aug 2007
IBM tooling helps you model and generate code for applications that run wholly or in-part on z/OS. In this article, you get an overview of modeling applications, UML, and model transformation. While model-driven development (MDD) is often associated with object-oriented programming, you see how to use MDD for mainframe applications by walking through a model-to-code transformation that generates a COBOL application.
Introduction
Creating and refining an application model can provide insight into the problem domain. This exercise can assist the development team in communicating details about the problem domain and in establishing a common vocabulary among the stakeholders. This article introduces you to the concepts of modeling applications, describes tools you can use to model applications, and introduces you to model transformations. You see one form of model transformation in which a database model construct generates a skeleton COBOL application.
You do not need to be an expert in modeling, Unified Modeling Language (UML), object oriented programming, or related areas of Model Driven Architecture (MDA) or model-driven development (MDD) . Nonetheless, some familiarity with these concepts is helpful. See the Resources section for references to materials which can help you get a deeper understanding of these topics. A rudimentary understanding of relational database concepts, such as DDL, tables, and columns is necessary, as is an understanding of COBOL on z/OS. Ultimately, you or your team will need to update generated COBOL source code.
What is a model?
Models are abstractions of a physical system. A model highlights relevant facts about the system and ignores or de-emphasizes details that are not imperative to solving a particular problem. Models enable engineers to reason, to communicate, and to discuss aspects of the system in order to solve a problem. Many engineering disciplines use a model to understand complex environments and to visualize the end-result.
A visual representation is worth 1024 words, and is less costly, and is more easily altered than building the actual entity. For example, when building a suspension bridge, multiple models are built such as the blueprints and a scale-model. The models are created prior to building the real system and are used to work through possible problems before incurring the cost of building the bridge.
You can use models to predict various characteristics of your system and to aid in understanding the behavior of the to-be system, as well as potential affects on the current systems. Designers use models to help discover patterns and trends that might not be obvious in the abstract.
Models serve as a great communication mechanism by providing something concrete to be critiqued and studied by multiple stakeholders–each of which provides critical feedback on the design. In addition to communicating structure and form, a model can introduce a consistent and common vocabulary among the constituents, interested parties, and stakeholders. Having a common vocabulary simplifies and accelerates the communication and establishes a level of understanding.
What is model transformation?
Models, however, are not an end in themselves. They are a means to an end. Having a model of the Golden Gate Bridge certainly will not help Marin County commuters cross the ocean span into San Francisco. However, having a physical, scale model of the Golden Gate Bridge did assist in shaping the visual beauty of the bridge and lead to the incorporation of a pedestrian walkway on the bridge.
In a similar fashion, having a model of your application can help you consider various aspects of your application; it will not let you execute the application.
To execute your program, you need to convert, or transform, your model into code.
A transformation is the step to convert one model, or layer of abstraction, to produce a new model in a potentially different form which contains more detailed information or newly emphasized aspects; for example, the ability to transform a blueprint into a scale model of the aforementioned bridge.
A transformation tool is used to transform an application model into another model, or into code. Additional information, used along with the model, guides the transformation from one form to another. This information, or metadata, that guides the transformation can be used to ultimately guide the transformation into executable code.
This article describes how you can transform a model of data into a skeleton COBOL application.
What is UML?
The Unified Modeling Language (UML) is OMG's (Object Management Group, see http://www.omg.org) standard modeling language for visualizing and documenting software systems.
UML is a graphical modeling language with visual representations or diagrams for use case diagrams, class diagrams, interaction diagrams, state diagrams, activity diagrams, deployment diagrams, and component diagrams.
A use case is a scenario that shows the interaction between a user (also known as an actor) and the system. These scenarios are goal driven, that is the actor wishes to accomplish a specific task. An example of a use case is a customer making an online purchase.
A class diagram describes the objects in a system and the static relationships between the objects. The relationships include containment, associations, inheritance, multiplicity, and others. You might decide that class diagrams of objects which support the online purchase use case would include OrderInfo, CustomerDetail, Payment, DeliveryMechanism, InventoryItem, and so on. You can probably see some of the obvious relationships among these various objects. Producing diagrams of these entities helps visualize the relationships. It provides the opportunity to ask questions about the relationships and to find missing relationships.
Asking probing questions about the model is sometimes known as "exercising the model". After the model is exercised to the point that any reasonable question can be answered, you can declare the model "'complete" for the specific purpose of a given use case. Having defined the class diagrams and the relationships, you can move onto the generation phase.
There are many books written about UML. One we recommend is UML Distilled – A Brief Guide to the Standard Modeling Language by Martin Fowler with Kendall Scott (Addison-Wesley, 1999). IBM provides a very good resource for information on UML at the IBM UML Resource Center.
Generating COBOL code from UML
IBM Rational Software Architect is a development tool that you use to create UML model diagrams, which can be consumed by WebSphere Developer for System z V7. Then, you can use WebSphere Developer to transform UML diagrams into code. This transformation is known as a model-to-code transformation.
You can install WebSphere Developer for System z directly on top of Rational Software Architect so that you have a single tool to accomplish the tasks of creating a UML model and transforming the model into code.
Using WebSphere Developer, you can transform the UML Class Diagram into a COBOL application which can be accessed as a CICS Web service under CICS 3.1 (or above). The COBOL application that results from the transformation has a basic structure that is a CRUD application, which can be used to act on rows in a table:
-
Create – create a row in the table
-
Read – read a row in the table
-
Update – update a row in the table
-
Delete – delete a row in the table
The UML Class Diagram is treated as a relational table and the class properties are treated as relational column definitions. The operations and the methods in the Class Diagram are ignored. In addition, the abstract classes, class relationships, and interfaces defined in the UML model are ignored. The application programmer needs to complete the detailed logic for the COBOL CRUD application.
The generated COBOL application consists of these source files:
<CRUD COBOL ProgramName>.cbl
<CRUD Web Service Converter Driver>.cbl
<CRUD COBOL ProgramName>.wsbind
<CRUD COBOL ProgramName>.wsdl
<LIST COBOL ProgramName>.cbl
<LIST Web Service Converter Driver>.cbl
<LIST COBOL ProgramName>.wsbind
<LIST COBOL ProgramName>.wsdl |
Generating COBOL code from a DB2 database table definition
You can also generate the skeleton COBOL CRUD application starting from a DB2 z/OS database. The results are similar to those you would get if you generated the COBOL CRUD application from UML. You see these steps outlined below where you use the Data Perspective in WebSphere Developer for System to view, connect to, and perform operations against relational databases.
Create a project
For this exercise, you use a project type called Database Application Project. To create it in Rational Software Architect, use the File => New => Project cascade. The wizard will prompt you for information.
Select the DB2 database
You can create a new database connection, or use those connections already defined in your workspace.
Figure 1. Database connections page in Rational Software Architect
Select tables(s)
After selecting the database, a set of tables displays from which you can select the tables necessary. (Displaying the tables list can take some time if there are a lot of tables available in the selected database.)
Figure 2. Retrieved list of tables
Run the transformation process
At this point, you see a view similar to the one in Figure 3, and you are ready to run the transformation. You simply click the Run Transformations button. Metadata found in preferences guides the transformation process. To find these preferences, select Window => Preferences, and then expand the tree node z/OS DatabaseApplication.
Figure 3. Run the transformation on your selected tables
Using the resulting CRUD files
Now your application developers can add the logic needs to the generated COBOL CRUD application. The same set of artifacts is generated using WebSphere Developer for System z whether you start with UML class diagrams or with a DB2 Database.
Conclusion
Modeling for software development is growing in use and importance, and provides high value as a design tool and as a communication vehicle. UML transformations let you transform a model into another model (more platform-specific or more detailed) or into code. The use of models is not limited to the Java programmer. Application programmers coding in COBOL can benefit from the use of models and can leverage the model-to-code transformation in the creation of CRUD applications.
Resources Learn
-
See the developerWorks WebSphere on System z zone for technical resources related to applications development and systems management involving WebSphere products running on System z.
-
See Rational Software Architect for technical resources that can help you learn to model and create applications.
-
Take the Model Service-Oriented Architectures with Rational Software Architect: Part 1. Case study, tools, and the business view tutorial to learn more about using MDD for SOA applications.
-
To get started with UML, see Object Management Group – Unified Modeling Language.
-
To learn more about UML, see the UML Resource Center.
-
See the IBM Rational Software Architect for general information about the product.
-
An Introduction to Model Driven Architecture, from the The Rational Edge, is the first part of a three-part series. It discusses models, modeling, the four key principles of MDA, and IBM's role in the development of standards related to MDA.
-
UML Basics: The class diagram, from the Rational Edge, provides an introduction to structure diagrams in UML 2.
-
UML Distilled – A Brief Guide to the Standard Modeling Language, a book by Martin Fowler with Kendall Scott. Addison-Wesley, 1999. ISBN 0321193687.
Get products and technologies
About the authors  | 
| | Laurence (Larry) England is a Senior Technical Staff Member at IBM's Silicon Valley Lab in San Jose, California. He has architectural responsibilities for application development tools on System z. When not working at IBM, he can be found running a trail in the California hills. |
| | | Mike Connor is the Product Line Manager for compilers on zOS and application development tools including WebSphere Developer for System z. Mike works in the beautiful IBM Raleigh Lab in North Carolina. |
Rate this page
| 
