aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Legacy to Web Migration - The OO approach Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Legacy to Web Migration - The OO approach" Watch "Legacy to Web Migration - The OO approach" New topic
Author

Legacy to Web Migration - The OO approach

Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi,
Looks like this forum has gone to a passive state.
Here is something to discuss about - Legacy to Web migration the OO way
Can someone explain how should one proceed for migrating Legacy(Mainframe,AS/400,etc.) systems to Web?
Just to start the discussion, I believe the first relevant UML artifact is Activity diagram.Reason:we need to understand the application flow as well as find out parallel logic.
What do we do next (assuming that I am correct!) or what do you do first(assuming that I am wrong!)
-- Sandeep
[This message has been edited by Desai Sandeep (edited July 05, 2001).]


<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
Farouk Mohamed
Greenhorn

Joined: Jul 23, 2001
Posts: 3
Hi Sandeep
1. The first step according to me is to define use cases and their scenarious and try to refine a suitable application interface as the legacy application might have many use cases and we need to refine only some.
Regards
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Farouk,
I am interested to find a definitive procedure to appoarch "Legacy to web" migration.I had worked on a Credit card application on IBM Mainframes which had about 8 million lines of COBOL (and CICS) structured code.Apart from this, it also had some customized code added to it.Documentation was not kept up with the additions.
The application has various functional modules.Each module had many batch and online programs.The CICS online program unlike the MV seperation pattern had logic incorporated in it.
Given this situation, what is the best way to make this application OO?
You mentioned about the use case approach.Could you please elaborate on how one should go about locating use cases in a structured application like the above.I understand the way to find use cases when you are building a new system (one described in Larman for POS device), but finding use cases from a structured code seems awkward to me.Also, will it be the first step?Is there any article which suggests as to how one should approach this problem?
Thank you for your views,
Sandeep
[This message has been edited by Desai Sandeep (edited July 23, 2001).]
Daniel Dunleavy
Ranch Hand

Joined: Mar 13, 2001
Posts: 276
I think one of the first things is to do the cases since the original system might be performing functions no longer needed and is not performing currently needed functionality. You also have to consider that the original system might have been working with different contraints than the ones that exist now.
Of course you may not be able to include any new functionality if there is a considerable amount. But you can reduce/streamline the old system flow. And then propose another phase for any of the new functionality.
Dan
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Dan,
We had taken lots of pains to understand this structured COBOL code.But can we say our studies good enough?Have we really understood the application?
The client's so-called "Domain Experts" have either resigned or they cannot provide us with sufficient information.We also have specialists on this application, but the information is not adequate.
One of the reasons why we are stuck is because this system has been modified by a number of contractors(consulting companies) before it came to us.The documentation is off track.We find many broken links in the information we have gathered so far!
These are some of the suggestions that has cropped up at the moment :

  1. Consider the original Vanila(Vendor) code as the base for which we have DFD's and draw Activity diagrams to find out which are the parallel processes.
  2. Once we have streamlined the functions, then we can think in terms of usecases and requirement study for those functions.
  3. Add the new functionality (which may overlapp some of the homegrown structured code) as per client's request.

  4. It is very difficult to convince the clients that all the home-grown code would be scrapped; after all this code has been added over a period of 10-12 years time!!So what do we suggest in this case?
    There is also a suggestion to convert the online CICS screens to HTML.By this we will be able to show some output to our client.But the question is without doing a proper analysis of the application is it wise to convert 1000 odd screens to web format?

    Ideally, the client would want us to understand the system on "as-is" basis and web-enable it.How does on proceed in such a case?Are there any case studies/patterns been done on this in the past?What is/was the procedure followed?

    Looking forward for your response,
    Sandeep
    [This message has been edited by Desai Sandeep (edited July 23, 2001).]
Farouk Mohamed
Greenhorn

Joined: Jul 23, 2001
Posts: 3
Hi Desai,
There are different ways you can approach this problem depending
on what you are trying to do with the legacy Application.
If you are trying to E-enable the entire legacy application.
then you have to go for a down to top (Legacy to web) approach where in first trying to under stand what the legacy system does?
I have done a implementation of a project on this type where we had no Domain Experts to say what the system does and it was very difficult for understand the business.
1.In this case our assumption is the CICS inteface is out basic interface and we dont worry too much about the internals of CICS/COBOL progaramming. Remember you are not planing to change the system from Mainframe to Web u r trying to just E-enable them.
2. In that instance what we did is first document the use cases of the legacy system by going through the process of transaction screen sitting with end users of the CICS/COBAL application.By this analysis we where first able to understand the use cases of the Mainframe application.
3. Because CICS screens has associated transactions which is what we are finally intrested.Following this approach we then documented the various transansactions associated with the use Cases.
4. We did analysis of the main transations so that we can understand the transations requirement from the external system (Parameters).
6. So we created message definitions based on transation requirements.(CopyBooks)
5. Then evolved our own web Interface and the api for our java based web system.
If you are trying to E-enable the only specific use cases of the entire legacy application then I would approach top down methodology (Web to legacy).
I have done a implementation of a project on this type where we had Domain Experts to say what the system does and it was very difficult for understand the business.
1.In this case our assumption was that we dint care about how mainframe works works. What we were intrested is how we send the proper message
to mainframe transaction.
In this case we concentrated more on the web inteface and how to reach the legacy transaction.
2. We created the Use case diagram did is first document the use cases of the proposed web application.
3. And the usually modelling approach using different UML Techniques and followed it till implementation

I dint have time to elaborate the second approach
Please tell me if it is helpful
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouk,
It is great to talk to a person who has experience on working on such a project.
I will take your approaches one by one.
Infact,I will split the first approach you mentioned to discuss only the issue of identifying the use case in this post.I see this thread getting really long
The first approach as you said was down to top (Legacy to web) approach.You also mentioned that this approach was e-enabling the legacy system.
Again as you didn't have domain experts in this project, I assume you went ahead and analyzed the whole system yourself.As per your note, I get an impression that you have restricted your analysis only to the CICS programs(and transactions); i.e. you didnot touch the batch programs.It makes sense as you donot want to migrate the whole system to web.
While doing this, you said that you came out with use cases.How did you identify the use cases?
In the OO terminology, we say anything that gives value to the user/actor is a use case.Now since we are restricting our problem domain to CICS screens, I guess the user may say every CICS screen would add value to him.So following this approach every CICS screen (in our terminology - transaction) becomes a use case!This is from the user point of view.
As a Developer, we know that each CICS screen initiates a transaction.Each such transaction would invoke various online programs.One can find this out using CEDF (Executive Diagnostic Facility) of CICS.
So, in your system did all the online programs associated with the screen come in one use case? Could you give an example of identifying a use case in such a project?
Also, a sample use case/online resources would be helpful.
Looking forward for your reply,
Sandeep
SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)
[This message has been edited by Desai Sandeep (edited July 25, 2001).]
Farouk Mohamed
Greenhorn

Joined: Jul 23, 2001
Posts: 3
Hello Sandeep,
Sorry that I was not very elobarate on the findings of the different approach because of time constraints. Good you have decide about the approach.
Legacy to Web:
System Overview:
Our system was a insurance system. Any legacy system will have a set of functionalities. The project was to e-enable the
legacy applicaition.

1. First what i did was to find out the overall functionalities involved in the system. Going thro the menu CICS screens of the application.
Quoting, Processing quotes, Delevering policies
2.These sub functionalities are big systems itself. So we finally recognised Quoting is the system towards which business
would like to go forward. Then started to investigate the quoting system in depth as Quote is going to be our Online application.
3.Again using cics screen investigate the online transaction which starts the quoting system.
There are two ways you can use these CICS screens,
1. Find out all transactions involved.
Not addressed unless you need more information on this type.
2. Find out the transation which satisfies our requirement.
We used this way as by collecting all the information after passing through all the online web screens, and finally send it to a mainframe transaction which does the calculate and retruns the results.
The advantage of this approach is that we dont send a message thro MQSeries to mainframe system aftereach and every page as this process will be very slow an expensive to the mainframe point of view.
The disadvantage of this approach was that we had to duplicate validation from mainframe applciation to the midtier java objects. This needed more involement from the user community to sit and understand the various business requirements and validation for different products.
In some cases if the information to be collected to fill up the mainframe interface (CopyBook) to invoke the transaction which calculates we can use the existing validation mechanism of mainframe system whereby duplication of validating effort is reduced.
4.Next thing is going through the CICS applciation and identifying use cases for our web system based on different things a user can do on the mainframe appliaction.
IMPORTANT: Everything a user does on mainframe may invoke a transaction but if and only if that screen is used for processing something we dont need the transaction.
There are two types of transations (careful to select only those u require)
1. Allows user to collect formation - Not required
2. Allows user to process collected information -- Requried.
After you have got the transaction, what you have to analyse using a CICS developer is the copybooks these transactions use so that we can satisfy these transations by providing the required information.
5. Then we create a mapping class in a our system to map our collected information to the Legacy Interface(CopyBook)
and sent a message to a Messaging middleware such as MQSeries, which enters cics system and invokes a calculating mainframe final transaction which return you a result.
I would have to tell you that a lof of business knowledge is required when you do the mapping from web constants to legacy mainframe copybooks

Hope this will convince u a little, I dont wanna make it too long,Please reply u specific queries if u have anymore

Regards
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Farouk,
You asked me to reply with queries.I will not disappoint you ! I have maked them with ===> !!
I believe you system is more complicated than what I was working on.Since I have worked on that system for more than a year now, I know most of the online copybooks, although I would be reluctant to say that I have acquired lot of business knowledge.But I certainly aspired for it.

Coming back to problem in hand, let me address it point-wise :

Originally posted by Farouk Mohamed:
1. First what i did was to find out the overall functionalities involved in the system. Going thro the menu CICS screens of the application.
Quoting, Processing quotes, Delevering policies
2.These sub functionalities are big systems itself. So we finally recognised Quoting is the system towards which business would like to go forward. Then started to investigate the quoting system in depth as Quote is going to be our Online application.

In my case, I had modules like Credit Decision Management, Credit Management System, Financial Authorization System, Collection Tracking System, Account Service Management ,TRIAD - Behaviour Tracking System and Security System.
As you mentioned, these smaller modules are big systems by itself.As you picked up Quoting in your case, for the sake of discussion, I pick up Credit Decision Management (CDM) sub-system.
I had an advantage of customizing, analysing the screens of CDM, as I had worked on this module for more than 6 months.I know the screens, the transactions, the online programs that are involved in CDM.


Originally posted by Farouk Mohamed:
3.Again using cics screen investigate the online transaction which starts the quoting system.
There are two ways you can use these CICS screens,
1. Find out all transactions involved.
Not addressed unless you need more information on this type.
2. Find out the transation which satisfies our requirement.
We used this way as by collecting all the information after passing through all the online web screens, and finally send it to a mainframe transaction which does the calculate and retruns the results.
The advantage of this approach is that we dont send a message thro MQSeries to mainframe system after each and every page as this process will be very slow an expensive to the mainframe point of view.
The disadvantage of this approach was that we had to duplicate validation from mainframe applciation to the midtier java objects. This needed more involement from the user community to sit and understand the various business requirements and validation for different products.
In some cases if the information to be collected to fill up the mainframe interface (CopyBook) to invoke the transaction which calculates we can use the existing validation mechanism of mainframe system whereby duplication of validating effort is reduced.

I believe, I would require more information in this regard.
We have a development region for CDM where we had spent sometime in understanding how those screens operate.We know the VSAM files that get affected, the way the transactions are called.Also have created lots of test data to understand how the data gets impacted.I have played with the screens in the development region to do model whatever is happening in production.
You mentioned about the "online web screens" where you had passed information which in turn calls the Mainframe CICS transactions and returns the results.
===>What are these "online web screens"?How did you create them, and why did you require them at this point of time?Are they some HTML test screens you created using some development tools?
===> Did you require "online web screens" for understanding how the transactions operate and to create test data?

I believe what you are stressing on the above point is to understand how the CDM systems operates and what are the transactions involved in the process.
The next step as you mentioned is to find out which transaction forms a part of the requirement and which doesn't!

Originally posted by Farouk Mohamed:
4.Next thing is going through the CICS applciation and identifying use cases for our web system based on different things a user can do on the mainframe appliaction.
IMPORTANT: Everything a user does on mainframe may invoke a transaction but if and only if that screen is used for processing
something we dont need the transaction.
There are two types of transations (careful to select only those u require)
1. Allows user to collect formation - Not required
2. Allows user to process collected information -- Requried.
After you have got the transaction, what you have to analyse using a CICS developer is the copybooks these transactions use so
that we can satisfy these transations by providing the required information.

This is the biggest problem that I have?
===> You mentioned about the use cases in the above point?What do they refer to at this level?
There are two types of transactions (which are nothing but online programs) that I know of.Some of them are linked with online validations (like checking fields are a must-entry field, or numeric data entered) and others process the data and finally write to the underlying VSAM files.
Also, I know the copybooks that these transactions use, as well as the files these transactions impact!
===> I believe both the types of transactions form a part of requirement.Correct me if I am wrong!
===> What type of transactions can be excluded from the requirement?You mentioned about those transactions which allow user to collect information.Could you elaborate on this in terms of CICS screens?


Originally posted by Farouk Mohamed:
5. Then we create a mapping class in a our system to map our collected information to the Legacy Interface(CopyBook)
and sent a message to a Messaging middleware such as MQSeries, which enters cics system and invokes a calculating mainframe final transaction which return you a result.
I would have to tell you that a lof of business knowledge is required when you do the mapping from web constants to legacy mainframe copybooks

Considering that I know the transactions and the copybooks associated with the transactions that populates the VSAM files (basically the Record Layout copybooks), as you said the next step is to create Java classes which map the record structure of the VSAM file to the Java primitives and other Object types.
===> Do we blindy consider creating a Java class file for all the Record Layout copybooks?
I fully agree with you regarding the complexity of the mapping exercise, as I had been involved in mapping this system with other systems running on AS/400.On the Mainframes, requirements like sending information in some sort of format to another system is very common (and also a headache!)
===> Last question but not the least, which tools did you use to get this stuff working.I have heard IBM VAJ,EE having some support for web-enabling CICS programs.Are you using similar tools?
Thank you for your comments,
Sandeep
[This message has been edited by Desai Sandeep (edited July 25, 2001).]
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Hello Sandeep
In regard to those questions you have asked me i have to ask you further questions to answer them.
First, According to me a usecase in business level means anything which has a functionality and adds value to the user.
Any functionality is not a use case for example, I would say collecting data for a functionlity or validating, or displaying screens is not a functionality
What you should be finding out in the legacy system is what i called as use cases.
My Quoting System in mainframe has the following use cases.

1. Perform a quote
2. Reuse a quote
3. Find a quote

Are you now in you CDM System with all knowledge of of transactions,screens and files able to deduce what the system is basically doing
in points like above, if not you are still in elaboration stage of u r project and still a long way before your construction.
Out of guess looking at the system name (Credit Decision management) i would think it is a system intended to make credit decisons based on clients
So if that is the case the system may have usecases like
1. Perform credit decisions for clients
2. Update/ Maintain clients information
3. Find previous decisions

The above may not be proper but i just simulated something to discuss.
1. I would say you surely should target the mainframe system to find out these things.
2. You should then sit and you construct various scenarious looking at various validation and input CICS Screens.
I think we should discuss about this in detail to start with before going any further on this.
Regards
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouk,
I agree with your definition of a use case.
However, the approach to identify use cases is good when we talk in terms of designing a new system.But I think, this goes haywire when we talk in terms of already existing system.
For example, after I analysed the system and came to know what Credit Decision Management (CDM) module is doing (in terms of functionality,files,transactions and screens), I may come up with the following use cases you mentioned:

  1. Perform credit decisions for clients.
  2. Update/ Maintain clients information.
  3. Find previous decisions.

  4. However, I am hesistant to consider the above as my use cases, since they are aimed more towards replacing the existing system with a new Web system.They probably cover areas/functionalities more than our present requirement.For example, in terms of our present system, probably the updation of client's information may be done by the batch programs;not by online CICS programs.So will it be correct to consider this as an use case in the present context?
    I believe it becomes imperative to define a system boundary before finding out use cases in such cases.
    Again, assuming that web-enabling CICS screens is our ONLY requirement,I would put a system boundary between the functionalities being implemented by the batch programs and those implemented by the online programs.
    I wouldn't like to touch on the functionalities done by the batch programs.With this in mind, most of the use cases would now encompass the stuff that is being done by the online programs (and transactions).This again makes me believe that every CICS screen on the Mainframe represents a functionality that the end user gets value from.So if we had 10 Screens we will have more or less 10 use cases in our case.
    For example in CDM, we may have :

    1. Prevalidation (Validation of data entered related to Input Entry screen - APIA).This use case would perform validations on the data entered, check the data with the requisite online file and then may proceed to the next screen if no error is encountered.Otherwise, flash an error on the same screen, and put the record in the decline queue.
    2. CrossCheck Screen(Cross checks for area code, telephone number, using online algorithms)
    3. and so on ..

    4. But again I see a Catch 22 for this. If we are discovering use cases for every online functionality, are we trying to replace the existing CICS screens with the new web screens?Or is our requirement to pass the data from the web screens to the CICS screens?
      Also, what approach does one follow, when the requirement is not to replace the existing CICS screen, but just to provide a web interface to the end user?
      Hope my discussions makes some sense
      Thank you for your views,
      Sandeep
      SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Hello Sandeep
Now things are getting a bit clearer
Credit Decision Management (CDM)
1. Perform credit decisions for clients.
2. Update/ Maintain clients information.
3. Find previous decisions.
I agree to what you say about batch and online programs and I as was pointing in the previous replies your job next is to find out what use cases you are trying to E-Enable. According to you Update/ maintain clients information is done on a batch program so neglect as it is out of scope in you analysis.
----------------------------------------------------------------------------------------------------------------------------------------
Quoted:
So if we had 10 Screens we will have more or less 10 use cases in our case.
With this in mind, most of the use cases would now encompass the stuff that is being done by the online programs (and transactions).This again makes me believe that every CICS screen on the Mainframe represents a functionality that the end user gets value from.So if we had 10 Screens we will have more or less 10 use cases in our case.
For example in CDM, we may have :
4. Prevalidation (Validation of data entered related to Input Entry screen - APIA).This use case would perform validations on the data entered, check the data with the requisite online file and then may proceed to the next screen if no error is encountered.Otherwise, flash an error on the same screen, and put the record in the decline queue.
5. CrossCheck Screen(Cross checks for area code, telephone number, using online algorithms)
6. and so on ..

Again from my previous replies I have told these are not Use cases these are things which lead to a use case.
I would like to mention this clearly again that these are events which lead to alternate scenarios.
Validation one aspect of a Use case and it is not a use case itself. I believe you should scope down what you mean by use cases. If you try to go to a extent to say every transaction is a use case the model will become very finely grained and it will be hard to maintain. So I would prefer to start with those two online use cases and try to create scenarios using various validation and data collecting screens

Use case:
1. Perform credit decisions for clients.
Alternative scenarios
1. Pervalidation - Sucess
2. Prevalidation � Failure
3. When point 1 is ok CrossCheck process should happen.
2. Find previous decisions.
Alternative scenarios
1. Pervalidation - Sucess
2. Prevalidation � Failure
3. When point 1 is ok CrossCheck process should happen.

--------------------------------------------------------------------------------------------------------------------------------------------
Quoted:
But again I see a Catch 22 for this. If we are discovering use cases for every online functionality, are we trying to replace the existing CICS screens with the new web screens?Or is our requirement to pass the data from the web screens to the CICS screens?
--------------------------------------------------------------------------------------------------------------------------------------------
If you understand the previous aspect that every screen is not a use case and if you agree with me then there is no catch 22 situation. I reiterate the point that a set of screens make up a use case and do not attempt to go to a level of saying every screen is a use case.
If you go to that level you may say navigating between screens is a Use case because it does some thing for the user.
There are two ways to approach this problem
Again from my previous replies you have to decide now about the speed and middle ware to decide whether you would like to send a message after every web screen to mainframe for validation
Or
You want to do the validation in the mid-tier and after cross validation collect all the information and send the data only to the last transaction(say in your case to find previous decisions or perform dredit decision to the legacy system)
You can never pass data to webscreens what you can do is to invoke mainframe transactions which CICS screens use to invoke to do database/file updates and processing. In any case you are bypassing the CICS screens.

See if this makes sense
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouk,
I think we have almost resolved the issue of use cases.
When I said, Prevalidation as one of the use case, I didn't mean to confine it only to the validation of data.Infact, it covers lots of other things like checking / validating the data with the online file, accepting or declining the application, and finally writing it to an Acceptance or Decline File(queue).May be I am missing out on a few of the other functionalities, that I cannot recollect at the moment!
This by itself is going to be a lot of information.Also, for the whole Prevalidation step to occur in CDM, one has to go through 8 CICS screens of APIA transaction from Page 01 to 08.So you may say, I am putting 8 screens of the transaction (APIA) in one use case.
In my earlier mail, when I mentioned every "screen" making up for a usecase, I meant every "transaction" which by itself may contain more than 5 screens making up for a single usecase.
In short, from the discussion on the use case, I believe you are stressing on the fact (and I agree) that the usecase should represent a bigger functionality of a system, which should contain the smaller steps(tasks) to achieve that functionality.I believe, Prevalidation step is one such big functionality in CDM.
You discussion on a usecase and its alternative scenarios fits the bill here.Only thing is, as I mentioned, each of these alternative scenarios are so big by itself that they deserve to be treated as a seperate usecase.
I conclude my note on the usecase discussion as we mostly agree on this.Please continue to read my other post, where I still have some queries.
Thanks,
Sandeep
[This message has been edited by Desai Sandeep (edited July 27, 2001).]
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Farouk,
The Catch 22 situation is still not gone, according to me!Reasons:

  1. Why did we create a Prevalidation usecase in the first place?Do we want to replace the APIA functionality (8 screens)?
  2. Do we want to develop a web interface which allows us to send data to each of those 8 APIA screens?

  3. For the Second Requirement, to create a web interface which can talk to the CICS screens,perhaps Prevalidation use case is not justified.May be, it would be required to identify which transaction needs to be invoked, when "Submit" button is clicked on the HTML page, but this piece of information can be easily provided by a CICS Developer.
    Since the actual processing is being done by the CICS, the use case would merely be informative in nature, which provides information on what transactions should be invoked.
    For the First Requirement,skipping the APIA 8 screens and to invoke the next transaction based on the status of the application, would make Prevalidation use case very crucial.This use case would be able to tell us which online programs are being called and also which files are getting affected.A detailed study of how the online programs affect the files is very important in this case.We may then consider to bypass the online programs that CICS calls by writing the data directly to the concerned online files using a middle-tier(say IBM WAS and EJB technologies) and then calling the next transaction after APIA transaction.I see a performance advantage of the system, using this approach, since we are flushing the data of 8 screens together in the next transaction.
    So the question is what artifacts you would create for the above requirements?
    IMO, for the first requirement the use case is justified, but for the second requirement, a DFD of transactions (programs) should be fine!
    Looking forward for your views on this.
    Regards,
    Sandeep
    [This message has been edited by Desai Sandeep (edited July 27, 2001).]
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Hi Sandeep
I am still sticking to the same point. A use case is one which is useful for someone. Just because it is big we cannot take it as as usecase. Even one path of a alternative scenario can be big.
I would still have prevalidation as a altrnative scenario and if this prevalidation is useful for other Use cases it can be taken as a include Use case separately.
Please can you explain the question u asked again as i dint understand the second note properly.
Regards
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Farouk,
May be I was not clear with what I mentioned in my earlier mails.If you go through the documentation of CDM provided by the vendor, CDM has 6 steps for deciding whether to give credit card or not.One of the steps is Prevalidation.Others are Cross-checks, etc., etc..
The screens in CDM has been created for these functionalities.Hence, I believe if someone says he has understood CDM, he would mean he has understood those 6 steps of CDM.Thus those 6 steps could become the usecase in our case.Each of these steps will give value to the user.
An alternative scenario would be, according to me, something when a different path takes place during one of these steps.For example, if at task 2 of prevalidation, you decide that you can bypass CrossCheck process, since the person who applied for the Credit card is a VIP, then it becomes an alternative scenario for Prevalidation use case.
I think you are looking at the usecases from the Customer point of view.In that case probably the only use case would be "Perform Credit Decision".However, if you look from the client who operates the machine also called "Representative" in CDM language, the application comes in their queues, based on those 6 steps.So these 6 steps add value(affect) the Representatives.From the Representative point of view "Perform Credit Decision" would be a HUGE use case!
Are you with me now?Let us more forward once we have agreed on this.
-- Sandeep
[This message has been edited by Desai Sandeep (edited July 27, 2001).]
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Hi Sandeep
Sorry for the late reply, quite busy.
I would say use cases or not for representatives or customers.
We use customers and representatives to decide what they do and term it as a use cases and it is for only object modelling purpose and provides literally nothing to the user of the system.
So i would have a use case say Perform Credit Decisions and have those six steps as separate objects to handle each step afterall these use cases are executed finally by our objects modelled.
Tell me hwat you think
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouk,
Great to hear from you and many thanks for keeping the discussion alive!
This is how I go about discovering use cases.
This Credit card product has been bought by a Company A.The end users (employees of company A) would use this product.So I would term these end users as actors.My next question is how these actors will derive value from the system.This will give me the relevant use cases
Depending on the "System Boundary" of requirement, we can have different use cases at this level.
For example :

  1. Scenario 1 : If I consider the entire Credit card system as problem domain / requirement, then the actors would look to derive value from each subsystem of the whole application.In that aspect, "Perform Credit Decision" which relates to one of the subsystems (Credit Decision Management - CDM) of the whole system (others being Credit Management System - CMS, Financial Authorization System - FAS, etc), becomes an use case.
  2. Scenario 2 : If I consider one of the subsystem (CDM) of the entire Credit card system as a use case, then perhaps I would break CDM further down into smaller processes , keeping the value addition factor from the actor's point of view.In this case, I would consider the functionalities of the smaller part of the subsystem to decide on the use case.

  3. Note that in the second scenario, "Perform Credit Decision" as a use case would be representative of the entire problem domain rather than a use case.We need to break this problem domain further to find out relevant use cases which would ultimately link to the screens,programs and transactions of CICS.
    I am trying to emphasize that apart from the value addition factor to the actor, one also needs to look at the "System Boundary" to decide on the use cases.This means we need to ask "What is System or the problem domain into consideration?" before discovering use cases.
    This is why, I consider each functional step of CDM as a use case, which could be important from the user point of view.For example : Prevalidation use case would indicate to the actor, whether it can pass the application to the next step of validation, which in our case would be a Cross-check use case.Here, by validation I don't mean just checking the input data, but also the entire business process that accompanies it, like writing to files/DB, etc.
    Also, I can not relate these steps to objects at this moment.I would tend to leave this to the design phase.
    Does this sound OK?Comments, please
    -- Sandeep
    [This message has been edited by Desai Sandeep (edited August 02, 2001).]
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Hi Sandeep
We have been going on discusing whether we can have one main use case or many use cases under one main one.
Shall we discuss what are the advantages according to you in having many use cases instead of one main use case(Perform Credit Decision)
I feel it is like having more sub headings in a document intead of one main heading
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouk,
My reasoning on having different use cases for each of the functionality of the problem domain (CDM) stems out from the requirement under consideration.
Our requirement is to e-enable the CICS screens of CDM.These screens represents some business functionalities, which needs to be put down as use cases.
One such usecase called Prevalidation, may contain information of 10-20 screens of the actual subsystem.For the sake of discussion, let us consider Prevalidation usecase to effectively cover about 2-3 CICS transactions, and about 20 actual CICS screens.
We then try to pen down the steps covered in Prevalidation usecase.
It may be something like this :
<pre>
Use case : Prevalidation
Actor : End-user of the CDM
Purpose : To check if the application qualifies the
Prevalidation step of CDM
Type : primary and real
Typical Course of Events :
Actor Action System Response
1. The actor types in transaction The System executes an
APMU Online program APOMU01 and
displays the APMU screen
2. The user checks on APIA The program APOIA00 is
transaction and presses the called to populate PMAM
enter key file
3. The user enters the data in the The program APOEP00 is
Page 00 of the screen and presses called to populate the
the enter key PMED file.
..... .....
20. The user types transaction The program APOVP00 is
APVP executed to populate
the PMAC file for success
of this application
Alternate Courses
Line 20: APVP screen not seen, Application has been declined.
....
</pre>

In the above use case, we will have proper annexures for the RecordLayout(RL) of the files used in this use case.We will also specify the fields that is getting populated in each step.
With this use case, we now know the flow of one of business functionalities of CDM.We can now design the HTML screens (Servlets/JSP) and map the information with the CICS fields.We can also think of showing the information of 2-5 CICS screens of this use case, in one HTML page and when the user presses the SUBMIT button the required data is wrapped according to RL's of the input file and is sent to the next transaction of CICS.Care has to be taken to see that the program associated with the transaction gets the information in the required RL format.
Does this make sense?
-- Sandeep
Salvador Villavieja
Greenhorn

Joined: Aug 03, 2001
Posts: 16
"Our requirement is to e-enable the CICS screens of CDM."
Have you taken a look at products that will do just this requirement? e.g. Websphere's Webfacing tool, Seagull's Win-Ja, Jacada etc.
We've used Seagull's JWalk (AS/400 environment). A thousand screens IS a lot, but with a product like JWalk or Jacada after a few month's training you might be "e-enabling" a hundred screens a day. You might want to use a few use cases for your first iteration.
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Salvador,
Thank you for joining Farouk and myself on this topic.
There are couple of doubts which I had as to how I should actually proceed with e-nabling CICS screens.
What kind of use cases should one prepare for such a requirement?Will the use case, I posted in my earlier post serve any purpose?Could you post a sample use case?
I have heard about IBM tools like IBM Enterprise Access Builder (EAB) which could help for this.However, I am not very certain on when one should use these tools for such projects.
It would be great if you could share the methodology you used for this requirement.
Thank you.
Sandeep
Salvador Villavieja
Greenhorn

Joined: Aug 03, 2001
Posts: 16
Sandeep,
Although I am an SCJP, I'm an OOAD newbie and have not had actual experience on OOP, but I've had my share of development work on legacy applications and am currently doing some GUI rework on a legacy application. I can imagine that your CICS based application is menu driven. The initial menu shown would probably be based on user profiles or a security file.
For your pilot project or first iteration, you probably need to identify which user profile or profiles you want to track. For these user profiles, you then ask which menu options you need to "e-enable".
I guess, what I'm trying to say is that a thousand screens is a lot to do in one go. You have to identify which user requirements you need to do your first iteration for.
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Hi Sandeep
I now agree with you that we need more use case to define such a complex system.
I would say
actor -----> Perform Credit Decision ---1.Prevalidation Usecase
---2.Cross Validating
---3. sub usecase3
---4. sub usecase4
---5. sub usecase5
---6. sub usecase6
lets carry on now if u agree as well.
If you know what fields in the RL you fill in for each transaction it would be easy to get HTML files out of it. What is the next issue you have got?
Regards
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Salvador,
Thanks for the reply.
As you have mentioned the CICS screens are all menu driven.There is a seperate subsystem called Security Subsystem (SS) which takes care of the user profile aspect.
To keep the discussions in sync, let's assume that we wish to e-enable another subsystem called Credit Decision Management(CDM) instead of SS.
The Menu options that you mentioned relate to transactions in the CICS system.I had posted a Prevalidation use case which takes care of about 2-3 such transactions and about 10-20 screens in CDM.This could be our first iteration.

Do you think such a use case would be appropriate in the present context of web-enabling CICS screens?If yes, what should we do next?

Thanks in advance,
Sandeep
PS : If you have any links or online resources which describes the methodology for web-enabling CICS screens, please do let me know.
-- Sandeep
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouq,
Am glad we have agreed on the first step of web-enabling the CICS screens.
Now my query is does this use case serve any purpose at all? I have always thought use cases as a good artifact for redesigning/designing systems.
This is the Catch 22 situation that I mentioned in my earlier mail.The actual processing is still being done by CICS;we only have to pass the information from the GUI interface to the CICS.
So if we have developed a use case, then probably it was meant to be informative in nature.It provides information on files/transaction/online programs that are invoked.May be the DFD's that the CICS Developer or the Business Consultant have could serve our purpose better!

I have a serious doubt on the need of use cases.I am wondering if the tools available in the market (as Salvador mentioned!) and the DFD's provided could suffice in this case.
My contention is that use cases are only required if the DFD's are not available in the present context.
Your comments, please!
Thanks,
Sandeep
Farouk Mohamed1
Ranch Hand

Joined: Jul 26, 2001
Posts: 113
Absolutely
I believe in the same way thats why in one of the previous emails i said why are we arguing so much about use cases and i said in my mind for your problem haveing many use cases instead of one serves the same purpose of having many subheadings along with one main heading.
I believe use cases are mostly use ful in object oriented world when we start to build a system. Use cases provide a business level abstraction of the system.
In design we start with use cases in new business application projects so as to not miss any business cases or requirements. In our case since we already have a system(CICS) in place which implements all our business requirements we need to only worry on the use cases to a allowable limits (till we understand the entirety )and not to sit and do work just for the making the process visible.
I would say we have to stop with use cases and start to think about getting into next steps of design.
Sandeep, you have to telling customizing every cics screens.
Question:
1. Did you think about the amount of transaction executions if u do that way (what i mean is u send a message to Mainframe after every screen, did u imagine the time involved for a message to go to mainframe and come back, did u think about the network traffic).
In the projects I worked on we move validation from mainframe to midtier so that all the pages navigations will be faster and finanlly we send a message to mainframe to do the last decision as it is a heavy process.
Shall we start to think about it. Because this question will answer your questions slowly.
Farouk
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi Farouk,

Originally posted by Farouk Mohamed1:
[..]Sandeep, you have to telling customizing every cics screens.
Question:
1. Did you think about the amount of transaction executions if u do that way (what i mean is u send a message to Mainframe after every screen, did u imagine the time involved for a message to go to mainframe and come back, did u think about the network traffic).[..]

Farouk, I didn't mention about web-enabling every CICS screen.Infact, the requirement for web-enabling should be tightly linked with performance.I believe this would be the only incentive why clients would agree for such a project.
I was emphasizing on the fact, that we need to develop say one HTML screen for about 3-5 CICS screens (or for one transaction) so that the data can be flushed in one go to the next transaction.This should reduce the I-O and can improve performance.The HTML screen would present abridged (may be I have not used the right term ) version of the actual fields in CICS.Just read the last paragraph of my mail where I had pasted a use case.This is exactly what I wanted to convey.
I believe this work has got little to do with OO.What we require are some good tools which would aid us to do such kind of work.The tricky thing would be

  1. when should one post the data to the Mainframe
  2. what framework (middle-tier) should one use to take care of I/O from Web to Mainframe and vice-versa.

  3. I am hesitant to call this framework a model since the model usually contains business logic; however in our case, this business logic is still on the Mainframe.
    As regards the second point, I think we require connectors which is able to pass data from CICS to Web and vice-versa.
    Comments, please!
    Sandeep
    [This message has been edited by Desai Sandeep (edited August 08, 2001).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Legacy to Web Migration - The OO approach