Apr 9, 2024
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.