Forgotten, But Not Gone: How Model-Based Development Is Still Alive and Well Today

Computer Aided Software Engineering (CASE) tools, which helped make the analysis, design, and implementation phases of software development better, faster, and cheaper, fell out of favor in the mid-'90s. Yet much of what they have to offer remains and is in active use within different Oracle tools.   Listen to Lois Houston and Nikita Abraham interview Senior Principal OCI Instructor Joe Greenwald about the origins of CASE tools and model-based development, as well as how they evolved into their current forms.   Develop Fusion Applications Using Visual Builder Studio: https://mylearn.oracle.com/ou/course/develop-fusion-applications-using-visual-builder-studio/122614/   Build Visual Applications Using Visual Builder Studio: https://mylearn.oracle.com/ou/course/build-visual-applications-using-oracle-visual-builder-studio/110035/   Oracle University Learning Community: https://education.oracle.com/ou-community   LinkedIn: https://www.linkedin.com/showcase/oracle-university/   X (formerly Twitter): https://twitter.com/Oracle_Edu   Special thanks to Arijit Ghosh, David Wright, and the OU Studio Team for helping us create this episode.   ---------------------------------------------------------   Episode Transcript:   00:00 Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative podcasts, we’ll bring you foundational training on the most popular Oracle technologies. Let’s get started. 00:26   Nikita: Hello and welcome to the Oracle University Podcast! I’m Nikita Abraham, Principal Technical Editor with Oracle University, and joining me is Lois Houston, Director of Innovation Programs.   Lois: Hi there! In our last episode, we looked at Oracle’s Redwood design system and how it helps create world-class apps and user experiences. Today, Joe Greenwald, our Senior Principal OCI Instructor, is back on our podcast. We’re going to focus on where model-based development tools came from: their start as CASE tools, how they morphed into today’s model-based development tools, and how these tools are currently used in Oracle software development to make developers’ lives better.   01:08 Nikita: That’s right. It’s funny how things that fell out of favor years ago come back and are used to support our app development efforts today. Hi Joe!   Joe: Haha! Hi Niki. Hi Lois.
 01:18 Lois: Joe, how did you get started with CASE tools?    Joe: I was first introduced to computer-aided software engineering tools, called CASE tools, in the late 1980s when I began working with them at Arthur Young consulting and then Knowledgeware corporation in Atlanta, helping customers improve and even automate their software development efforts using structured analysis and design techniques, which were popular and in high use at that time. But it was a pain to have to draw diagrams by hand, redraw them as specifications changed, and then try to maintain them to represent the changes in understanding what we were getting from our analysis and design phase work. CASE tools were used to help us draw the pictures as well as enforce rules and provide a repository so we could share what we were creating with other developers. I was immediately attracted to the idea of using diagrams and graphical images to represent requirements for computer systems.  02:08 Lois: Yeah, you’re like me. You’re a visual person. Joe: Yes, exactly. So, the idea that I could draw a picture and a computer could turn that into executable code was fascinating to me. Pictures helped us understand what the analysts told us the users wanted, and helped us communicate amongst the teams, and they also helped us validate our understanding with our users. This was a critical aspect because there was a fundamental cognitive disconnect between what the users told the analysts they needed, what the analysts told us the users needed, and what we understood was needed, and what the user actually wanted. There’s a famous cartoon, you can probably find this on the web, that shows what the users wanted, what was delivered, and then all the iterations that the different teams go through trying to represent the simple original request.   I started using entity relationship diagrams, data flow diagrams, and structure charts to support the structured analysis, design, and information engineering methods that we were using at the time for our clients. Used correctly, these were powerful tools that resulted in higher quality systems because it forced us to answer questions earlier on and not wait until later in the project life cycle, when it’s more expensive and difficult to make changes. 03:16 Nikita: So, the idea was to try to get it wrong sooner. Joe: That’s right, Niki. We wanted to get our analysis and designs in front of the customer as soon as possible to find out what was wrong with our models and then change the code as early in the life cycle as possible where it was both easier and, more importantly, cheaper to make changes before solidifying it in code.   Of course, the key words here are “used correctly,” right? I saw the tools misused many times by those who weren’t trained properly or, more typically, by those whose software development methodology, if there even was one, didn’t use the tools properly—and of course the tools took the blame. CASE tools at the time held a lot of promise, but one could say vendors were overpromising and under delivering, although I did have a number of clients who were successful with them and could get useful support for their software development life cycle from the use of the tools. Since then, I’ve been very interested in using tools to make it easier for us to build software.   04:09 Nikita: So, let me ask you Joe, what is your definition of a CASE tool?
 Joe: I’m glad you asked, Niki, because I think many people have many different definitions. I’m precise about it, and maybe even a bit pedantic with the definition. The definition I use for a CASE tool comprises four things. One, it uses graphics, graphical symbols, and diagrams to represent requirements and business rules for the application. Two, there is a repository, either private, or shared, or both, of models, definitions, objects, requirements, rules, diagrams, and other assets that can be shared, reused, and almost more importantly, tracked. Three, there’s a rule-base that prevents you from drawing things that can’t be implemented. For example, Visio was widely regarded as a CASE tool, but it really wasn’t because it had no rules behind it. You could wire together anything you wanted, but that didn’t mean it could be built.  Fourth, it generates useful code, and it should do two-way engineering, where code, typically code changed outside the model, can be reverse engineered back into the model and apply updates to the model, and to keep the model and the source code in synchronization.   05:13 Joe: I came up with a good slogan for CASE tools years ago: a good CASE tool should automate the tedious, manual portions of software development. I’d add that one also needs to be smarter than the tools they’re using. Which reminds me, interestingly enough, of clients who would pick up CASE tools, thinking that they would make their software development life cycle shorter. But if they weren’t already building models for analysis or design, then automating the building of things that they weren’t building already was not going to save them time and effort.  And some people adopted CASE tools because they were told to or worse, forced to, or they read an article on an airplane, or had a Eureka moment, and they would try to get their entire software development staff to use this new tool, overnight literally, in some cases. Absolutely sheer madness!  Tools like this need to be brought into the enterprise in a slow, measured fashion with a pilot project and build upon small successes until people start demanding to use the tools in their own projects once they see the value. And each group, each team would use the CASE tool differently and to a different degree. One size most definitely does not fit all and identifying what the teams’ needs are and how the tool can automate and support those needs is an important aspect of adopting a CASE tool. It’s funny, almost everyone would agree there’s value in creating models and, eventually, generating code from them to get better systems and it should be faster and cheaper, etc. But CASE tools never really penetrated the market more than maybe about 18 to 25%, tops.   06:39 Lois: Huh, why? Why do you think CASE tools were not widely accepted and used?   Joe: Well, I don’t think it was an issue with the tools so much as it was with a company’s software development life cycle, and the culture and politics in the company. And I imagine you’re shocked to hear that.  Ideally, switching to or adopting automated tools like CASE tools would reduce development time and costs, and improve quality. So it should increase reusability too. But increasing the reusability of code elements and software assets is difficult and requires discipline, commitment, and investment. Also, there can be a significant amount of training required to teach developers, analysts, project managers, and senior managers how to deal with these different forms of life cycles and artifacts: how they get created, how to manage them, and how to use them. When you have project managers or senior managers asking where’s the code and you try telling them, “Well, it’s gonna take a little while. We’re building models and will press the button to generate the code.” That’s tough. And that’s also another myth. It was never a matter of build all the models, press the button, generate all the code, and be done. It’s a very iterative process. 07:40 Joe: I’ve also found that developers find it very psychologically reinforcing to type code into the keyboard, see it appear on the screen, see it execute, and models were not quite as satisfying in the same way. There was kind of a disconnect. And are still not today. Coders like to code.   So using CASE tools and the discipline that went along with them often created issues for customers because it could shine a bright light on the, well let’s say, less positive aspects of their existing software development process. And what was seen often wasn’t pretty. I had several clients who stopped using CASE tools because it made their poor development process highly visible and harder to ignore. It was actually easier for them to abandon the CASE tools and the benefits of CASE tools than to change their internal processes and culture. CASE tools require discipline, planning, preparation, and thoughtful approaches, and some places just couldn’t or wouldn’t do that. Now, for those who did have discipline and good software development practices, CASE tools helped them quite a bit—by creating documentation and automating the niggly little manual tasks they were spending a lot of time on.   08:43 Nikita: You’ve mentioned in the past that CASE tools are still around today, but we don’t call them that. Have they morphed into something else? And if so, what?   Joe: Ah, so the term Computer Aided Software Engineering morphed into something more acceptable in the ‘90s as vendors overpromised and under-delivered, because many people still saw value and do today see value in creating models to help with understanding, and even automating some aspects of software code development.  The term model-based development arose with the idea that you could build small models of what you want to develop and then use that to guide and help with manual code development. And frankly just not using the word CASE was a benefit. “Oh we’re not doing CASE tools, but we’ll still build pictures and do stuff.” So, it could be automated and generate useful code as well as documentation. And this was both easy to use and easier to manage, and I think the industry and the tools themselves were maturing. 09:35 Joe: So, model-based development took off and the idea of building a model to represent your understanding of the system became popular. And it was funny because people were saying that these were not CASE tools, this was something different, oh for sure, when of course it was pretty much the same thing: rule-based graphical modeling with a repository that created and read code—just named differently. And as I go through this, it reminds me of an interesting anecdote that’s given about US President Abraham Lincoln. He once asked someone, “If you call a dog’s tail a leg, how many legs does a dog have?” Now, while you’re thinking about that, I’ll go ahead and give you the correct answer. It’s four. You can call a dog’s tail anything you want, but it still has four legs. You can call your tools whatever you want, but you still have the idea of building graphical representations of requirements based on rules, and generating code and engineering in both directions. 10:29 Did you know that Oracle University offers free courses on Oracle Cloud Infrastructure? You’ll find training on everything from cloud computing, database, and security to artificial intelligence and machine learning, all free to subscribers. So, what are you waiting for? Pick a topic, leverage the Oracle University Learning Community to ask questions, and then sit for your certification. Visit mylearn.oracle.com to get started. 10:58 Nikita: Welcome back! Joe, how did you come to Oracle and its CASE tools?   Joe: I joined Oracle in 1992 teaching the Oracle CASE tool Designer. It was focused on structured analysis and design, and could generate database Data Definition Language (DDL) for creating databases. And it was quite good at it and could reverse engineer databases as well. And it could generate Oracle Forms and Reports – character mode at first, and then GUI. But it was in the early days of the tool and there was definitely room for improvement, or as we would say opportunities for enhancement, and it could be hard to learn and work with. It didn’t do round-trip engineering of reading Oracle Forms code and updating the Designer models, though some of that came later. So now you had an issue where you could generate an application as a starting point, but then you had to go in and modify the code, and the code would get updated, but the models wouldn’t get updated and so little by little they’d go out of sync with the code, and it just became a big mess. But a lot of people saw that you could develop parts of the application and data definition in models and save time, and that led to what we call model-based development, where we use models for some aspects but not all. We use models where it makes sense and hand code where we need to code.    12:04 Lois: Right, so the two can coexist. Joe, how have model-based development tools been used at Oracle? Are they still in use?   Joe: Absolutely! And I’ll start with my favorite CASE tool at Oracle, uhm excuse me, model-based development tool. Oracle SOA Suite is my idea of a what a model-based development tool should be. We create graphical diagrams to represent the flow of messages and message processing in web services—both SOAP and REST interfaces—with logic handled by other diagrammers and models. We have models for logic, human interaction, and rules processing. All this is captured in XML metadata and displayed as nice, colored diagrams that are converted to source code once deployed to the server. The reason I like it so much is Oracle SOA Suite addressed a fundamental problem and weakness in using modeling tools that generated code. It doesn’t let the developer touch the generated code. I worked with many different CASE tools over the years, and they all suffered from a fundamental flaw. Analysts and developers would create the models, generate the code, eventually put it into production, and then, if there was a bug in the code, the developer would fix the code rather than change the model. For example, if a bug was found at 10:30 at night, people would get dragged out of bed to come down and fix things. What they should have done is update the model and then generate the new code. But late at night or in a crunch, who’s going to do that, right? They would fix the code and say they’d go back and update the model tomorrow. But as we know, tomorrow never comes, and so little by little, the model goes out of synchronization with the actual source code, and eventually people just stopped doing models. 13:33 Joe: And this just happened more and more until the use of CASE tools started diminishing—why would I build a model and have to maintain it to just maintain the code? Why do two separate things? Time is too valuable. So, the problem of creating models and generating code, and then maintaining the code and not the model was a problem in the industry. And I think it certainly hurt the adoption and progress of CASE tool adoption. This is one of the reasons why Oracle SOA Suite is my favorite CASE tool…because you never have access to the actual generated code. You are forced to change the model to get the new code deployed. Period. Problem solved. Well, SOA Suite does allow post- deployment changes, of course, and that can introduce consistency issues and while they’re easier to handle, we still have them! So even there, there’s an issue.   14:15 Nikita: How and where are modeling tools used in current Oracle software development applications?   Joe: While the use of CASE tools and even the name CASE fell out of favor in the early to mid-90s, the idea of using graphical diagrams to capture requirements and generate useful code does live on through to today. If you know what to look for, you can see elements of model-based design throughout all the Oracle tools. Oracle tools successfully use diagrams, rules, and code generation, but only in certain areas where it clearly makes sense and in well-defined boundaries. Let’s start with the software development environment that I work with most often, which is Visual Builder Studio. Its design environment uses a modeling tool to model relationships between Business Objects, which is customer data that can have parent-child relationships, and represent and store customer data in tables. It uses a form of entity relationship diagram with cardinality – meaning how many of these are related to how many of those – to model parent-child relationships, including processing requirements like deleting children if a parent is deleted.  The Business Object diagrammer displays your business objects and their relationships, and even lets you create new relationships, modify the business objects, and even create new business objects. You can do all your work in the diagram and the correct code is generated. And you can display the diagram for the code that you created by hand. And the two stay in sync. There’s also a diagramming tool to design the page and page flow navigation between the pages in the web application itself. You can work in code or you can work in the diagram (either one or both), and both are updated at the same time. Visual Builder Studio uses a lot of two-way design and engineering.   15:48 Joe: Visual Builder Studio Page Designer allows you to work in code if you want to write HTML, JavaScript, and JSON code, or work in Design mode and drag and drop components onto the page designer canvas, set properties, and both update each other. It’s very well done. Very well integrated.   Now, oddly enough, even though I am a model-based developer, I find I do most of my work in Visual Builder Studio Designer in the text-based interface because it’s so easy to use. I use the diagrammers to document and share my work, and communicate with other team members and customers. While I think it’s not being used quite so much anymore, Oracle’s JDeveloper and application development framework, ADF, includes built-in tools for doing Unified Modeling Language (UML) modeling. You can create object-oriented class models, generate Java code, reverse engineer Java code, and it updates the model for you. You can also generate the code for mapping Java objects to relational tables. And this has been the heart of data access for ADF Business Components (ADFBC), which is the data layer of Oracle Fusion Apps, for 20 years, although that is being replaced these days. 16:51 Lois: So, these are application development tools for crafting web applications. But do we have any tools like this for the database? Joe: Yes, Lois. We do. Another Oracle tool that uses model-based development functionality is the OCI automated database actions. Here you can define tables, columns, and keys. You can also REST-enable your tables, procedures, and functions.   Oracle SQL Developer for the web is included with OCI or Oracle SQL Developer on the desktop has a robust and comprehensive data modeler that allows you to do full blown entity relationship diagramming and generate code that can be implemented through execution in the database. Now that’s actually the desktop version that has the full-blown diagrammer but you also have some of that in the OCI database actions as well. But the desktop version goes further than that. You can reverse engineer the existing database, generate models from it, modify the models, and then generate the delta, the difference code, to allow you to update an existing database structure based on the change in the model. It is very powerful and highly sophisticated, and I do strongly recommend looking at it.  And Oracle’s APEX (Application Express) has SQL workshop, where you can see a graphic representation of the tables and the relationships between the tables, and even build SQL statements graphically.    18:05 Nikita: It’s time for us to wrap up today but I think it’s safe to say that model-based development tools are still with us. Any final thoughts, Joe?   Joe: Well, actually today I wonder why more people don’t model. I’ve been on multiple projects and worked with multiple clients where there’s no graphical modeling whatsoever—not even a diagram of the database design and the relationships between tables and foreign keys. And I just don’t understand that.   One thing I don’t see very much in current CASE or model-based tools is enabling impact analysis. This is another thing I don’t see a lot. I’ve learned, in many years of working with these tools, to appreciate performing impact analysis. Meaning if I make a change to this thing here, how many other places are going to be impacted? How many other changes am I going to have to make? Something like Visual Builder Studio Designer is very good at this. If you make a change to the spelling of a variable let’s say in one place, it’ll change everywhere that it is referenced and used. And you can do a Find in files to find every place something is used, but it’s still not quite going the full hundred percent and allowing me to do a cross-application impact analysis. If I want to change this one thing here, how many other things will be impacted across applications? But it’s a start. And I will say in talking to the Visual Builder Studio Architect, he understands the value of impact analysis. We’ll see where the tool goes in the future. And this is not a commitment of future direction, of course. It would appear the next step is using AI to listen to our needs and generate the necessary code from it, maybe potentially bypassing models entirely or creating models as a by-product to aid in communication and understanding. We know a picture’s worth a 1000 words and it’s as true today as it’s ever been, and I don’t see that going away anytime soon.   19:41 Lois: Thanks a lot, Joe! It’s been so nice to hear about your journey and learn about the history of CASE tools, where they started and where they are now.  Joe: Thanks Lois and Niki. Nikita: Join us next week for our final episode of this series on building the next generation of Oracle Cloud Apps with Visual Builder Studio. Until then, this is Nikita Abraham… Lois: And Lois Houston, signing off! 20:03 That’s all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We’d also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.