Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Dana Rothrock BCBSA on April 16, 2013, 02:29:32 am
-
I have Enterprise Architect and have been tasked with using UML on mainframe applications.
Where are experiences with UML on the mainframe?
:-/
-
Could you be more specific? Analogously you could have asked: "Is there any experience with writing fiction novels in English language?"
q.
FWIW: I have modeled a couple of mainframe applications in preparation of migrating to web services a couple of years ago.
-
:) Good, can you offer any guidelines or hints for a mainframe dinosaur who has never seen or heard of UML?
-
Do as qwerty suggests and be more specific. I interpret your brief as: "use UML to model certain mainframe applications with a view to ..." (in qwerty's case, remodelling them for migration to a different platform/medium).
When you say 'using UML on mainframe applications' do you mean running EA on a mainframe operating system too?
Just expand on what you have been tasked to do. And Google 'UML'.
-
I've use EA and UML in a mainframe environment before too.
We were mainly doing functional analysis, so there was not much difference to modeling for another system.
There is no real reason why you couldn't use UML for a mainframe system, it just depends on what you are trying to achieve.
If you are trying to do full code generation based on your UML model then you might face a serious challenge.
Geert
-
:) Good, can you offer any guidelines or hints for a mainframe dinosaur who has never seen or heard of UML?
I guess you mean the person, not the machine. If so, they will definitely recognize a deployment diagram where the machines have ports and interfaces. Once used to that you can start detailing things. However, I can't say more to "writing novels".
q.
-
qwerty:
I guess you mean the person, not the machine
I am dinosaur, the mainframe is evolving.
We are attempting to model existing mainframe applications in UML using EA (on PC) for the purpose of documentation and analysis.
RoyC: Google 'UML'
The only references to UML on the mainframe require multiple IBM software licenses. I could not find examples of mainframe UML. :-/
-
I think there's no such thing like 'Mainframe UML', or do you mean an UML Tool that runs on the mainframe??
The latter isn't really necessary, if you have access to the source code repositories from a PC you can start out with a Reverse Engineering there (COBOL won't be supported thought I'm afraid :-/ ).
HTH
Günther
-
Hi Dana
You an use EA to model Mainframe applications.
Just start creating your Use Cases and Activity Diagrams so you can get familiar with EA and UML. And go from there to different diagrams like Deployment and maybe Components.
My 2 cents
-
The applications we are attempting to document in UML using EA are standard COBOL CICS DB2 MQ. Very complex, dynamic CALL structure, hundreds of subprograms per transaction, highly complex shared storage, data driven, dynamic processing. It is not a "Hello, World!" application.
jfzouain:Just start creating your Use Cases and Activity Diagrams so you can get familiar with EA and UML. And go from there to different diagrams like Deployment and maybe Components.
Isn't the first step in EA to Create Project? Is Project required?
-
Hi Dana,
as you are a dinosaur yourself, I can give you the following advice (I'm a dinosaur too, but somehow I got a lot of me genes to evolve human-like - just to continue the analogy).
I could start with "learn UML", then come back. But that would not be so helpful. Here's a little receipt you can use for your own start:
- Create an empty EA repository (use EAP)
- Create a view called Deployment
- Inside this view create packages for your single sites. Just name them as the location.
- Create another View at top level called Resources
- Inside Resources create packages called Machines, Operating Systems, Applications, etc. (you'll find out later what else)
- Go back to one of the sites packages
- Create a Deployment diagram
- Now start thinking: which machine types, OSes, (COBOL) Apps do I use here.
- For each one found create a node/component in the according Resources package (go there and pop back). Devices are nodes and any software is a component. You should then find there some IBM/370, IBM/360 as nodes (you see, I'm a very old dinosaur), MVS, CP/CMS a.s.o. as components for the OS, etc.
- Now Ctrl-drag the right node to your deployment diagram of the site. Create an instance of the according node. Make it larger on the diagram. Ctrl-drag the right OS and drag it over/into the machine node. That will show the machine at the site with its OS. It can of course host multiple OSes - just ctrl-drag more of them.
- You can repeat the previous steps for all your sites
- Similarly you can ctrl-drag and place the apps. Probably you should create separate diagrams for that. (You can link those later to ease navigation, but that would be to much detail for now)
- Now that you see machine/OS/app you can add ports to the nodes. Inside these you can create provided and required interfaces you can connect to the other machines as appropriate.
- Separate diagrams will allow an oversight of machines and how they interact, the used software and what you wish....
It will need quite a bit practice but in the end it will pay out.
Good luck.
q.
P.S. If you're more after documenting the COBOL transactions you should do that as follows:
- Start with a view Transactions
- Create a package for each use case
- Describe the transactions as use cases
- Create a Class for each COBOL module taking part in the transaction
- Create operations in the class that describe what a single transaction does
- Create a Collaboration
- Inside the Collaboration create sequence diagrams
- Ctrl-drag the COBOL classes onto the diagram to create instances (lifelines)
- Connect the single lines with messages derived from the class operations
This way you can create some transactional overview. In reality it's more difficult and you should have an UML consultant around that can help you drawing your thoughts the right way.
-
Qwerty, thank you! [smiley=2vrolijk_08.gif]
This is exactly the outline and cross-vocabulary I have been trying to find for months.
The UML gurus in my department don't know mainframe. They speak OOD and java. I speak JCL and COBOL. We just sit around the table scratching our heads.
I think I can wing it from here.
There is so little information available for UML on the mainframe that I believe this translation is marketable. Have you thought of that? Sure can't find anything like it in Google.
[smiley=beer.gif]
-
Good point! As for now I have plenty of time I could put together those bits in a book. Will start right tomorrow (time to go to bed now).
q.
-
Good point! As for now I have plenty of time I could put together those bits in a book. Will start right tomorrow (time to go to bed now).
q.
Dinosaurs talking ;D ...
@Dana Rothrock BCBSA:
Best bet is it's up to you to analyze the COBOL data structures (AFAIR COBOL is data structure oriented) and available operations on them and how these may interface with reasonable java classes (similar OO translation as needed for C and structs).
Sorry it's quite a long time ago I had to struggle with COBOL, academical usage only (phew ...).
-
In EA, "COBOL" is not one of the languages supported in the CLASS / Languages pull-down box. [smiley=cry.gif]
Am I missing a plug-in?
Are we pushing the envelope?
-
You can add you own programming language and the define the primitive types for you programming language.
In COBOL that's like 'X' and '9' no?
Geert
PS. Pff... I must admit I'm glad not having to deal with COBOL for the moment ;D
-
Not exactly, Dana. You can create code modules for languages that are not supported by EA, and bring them into use through an MDG Technology. This is not something you would be able to do yourself at the moment - you need more experience with EA. However, with your COBOL knowledge and a sympathetic UML/EA expert (such as have popped up all around you here on the forum!) you might be able to work something out. I can't tell, but the experts would soon advise you.
Are your UML people EA experts? If not, maybe you could persuade qwerty to take a holiday down your way... unless a rival guru locks him in a cupboard and jumps on the 'plane first! (But not Geert, it seems.)
-
I think the biggest challenge is not customizing EA, but defining your modelling method.
How are you going to structure your model, what UML element are you going to use for which type of Cobol/Mainframe artifacts.
Which information/disciplines do you need in your UML model.
Business Processes? Functional use cases? Requirements? and so on...
So you'll have to start by defining you modelling/analysis method and start building a meta model for it.
All of this work is (more or less) independent of the UML tool you use.
Only after you know your requirements (modelling method) you should start thinking about the solution (EA).
Geert
-
I agree Geert, but at least qwerty has provided some suggestions regarding how the model should be structured - often this is the hardest piece, looking at a blank piece of paper or screen.
Then of course there's the learning curve of a tool like EA, at least following qwerty's suggestions Dana can make a start, get some value out of it and then perhaps revisit customisation later. As Roy said MDG technologies are not for now in her situation.
-
Sage advice from all quarters. I probably tried to cover too many ideas in a short spurt, but as Geert implies, you need to go back to the first couple of posts in this thread and ask "What are we talking about here?" and, as Dana said and qwerty laid out "What kind of outline and cross-vocabulary can we develop?" Then, a long way down the track, you can ask "Can I tailor all this to better model these mainframe COBOL applications?" and know that there are ways to do that.
Maybe Dana should book qwerty in for a VERY long holiday!
-
I've got 6 weeks to model a highly complicated mainframe application in EA.
[smiley=thumbsup.gif]
-
Perhaps you should show this thread to your UML gurus and get them moving fast!
@qwerty - the BCBSA headquarters are in Illinois. Springtime on the Great Lakes - yes? No?
-
RoyC:
Perhaps you should show this thread to your UML gurus and get them moving fast!
I have to teach them mainframe, and they have to teach me OOD. That's two lifetimes.
EA has to work for the average mainframe COBOL programmer. We will establish standards, profiles or templates, etc. Our Agile methodology suggests access and collaboration by all parties throughout the SDLC. Maintenance of models will be a community responsibility depending upon project involvement.
@qwerty - the BCBSA headquarters are in Illinois. Springtime on the Great Lakes - yes? No?
Yes, BCBSA is on Michigan Ave, but no, I am remote in Florida where it has been Spring for 6 or 7 months. [smiley=cool.gif]