History
The product's original name was Oracle CASE and it was developed in England. Oracle CASE was based on Oracle corporations "Computer Aided Software Engineering" method (CASE Method). CASE Method was in turn developed by Oracle Consulting UK in the 1980's based on modelling techniques such as Richard Barker et al's Entity Relationship Modelling. Eventually the product would be known as Oracle Designer, with a complementary product Oracle Developer (although in practice the combination of Oracle Designer/Developer was most commonly used). Oracle became the dominant database and enterprise application vendor in the 1990's and as a consequence Oracle Designer/Developer was used by many enterprises from the mid 1990's to the mid 2000's. A product called SQL Data Dictionary (SDD) was a precursor to Oracle CASE.Context
In the 1980's relational database systems, running on unix based servers, became popular for administrative systems used by corporations and governments. Major factors were low maintenance cost and high developer productivity compared to earlier technologies. As increasingly large systems were developed, software development teams struggled to manage requirements and maintain code quality. Oracle CASE was initially used by Oracle Consulting UK's quality management team and later became the de-facto standard for Oracle Custom Development (Custom development as opposed to packaged application software). Oracle CASE Method later became known as Oracle Custom Development Method, with a similar approach for customisations of Oracle's Application Suite called Oracle Application Development Method. Oracle sold their Designer and Developer product's to enterprises and consulting groups, who in turn created thousands of systems that are still in place as of 2021. The design philosophy behind Oracle Designer and competing tools in the 80's and 90's was the Three-schema-architecture that separated an external schema, logical schema and internal schema. For Oracle's product line, the internal schema corresponded to the inner workings of their relational database, the logical schema corresponded to SQL and the external schema corresponded to screens and reports.Concepts
Oracle Designer was based on a well thought out set of concepts that suited the types of systems being developed from the 1980's to the mid 2000's. It's easiest to describe these concepts separately in terms of skills, structure and technology:Skills
In terms of skills, software designers were expected to think out database structures in entity relationship models and functional decomposition models, then transform those models into database definitions and modules (the screens and reports). Software developers were then expected to elaborate the database definitions and modules to create working code. Finally the day to day running of the system was expected to be carried out by database administrators, who had detailed knowledge of the database internals.Structure
Oracle Designer/Developer divided software development into data and applications, which were viewed at three levels of abstraction; Modelling, Design and implementation. This gives a 2x3 matrix of views which was visible throughout the product's lifecycle: # Entity Relationship Model. This is a high level abstraction of the database structure. Used primarily to generate the database design. # Database design. This is a representation of the tables, views, constraints of the database, with additional annotations. To illustrate the difference with the above; where an entity relationship model would show a relationship between two entities, the Database design would include additional columns for a foreign key, the foreign key constraint and an index over the foreign key columns. All of these could be generated from the entity relationship model, ensuring consistent naming and traceability. The names of tables and columns in many Oracle production databases in use today are due to the use of Oracle Designer. Later versions of the tool allowed specification of most of the internals of the Oracle database such as tablespaces and files. # Database Definition Language (DDL) generation from the Database design. # Function model. This is a function decomposition model, where each function contains a description and a CRUD matrix against the Entity Relationship model. # Modules. This modelled the screens, reports and other application components. Mostly used for screens, because of the availability of code generation for Oracle (Developer) Forms. It was common for # Application code. This consisted mostly of Oracle Forms, Oracle Reports, Stored procedures for the Oracle Database. Initially code was not stored in the Oracle Designer Repository, but in later versions developers were encouraged to add code to the repository, which was merged during code-generation. The client-server architecture of Oracle's Developer product was typical of the 1990's; PC computers running Oracle Forms and Reports that communicated with an Oracle Database over a network protocol called SQL*NET. This structure was simpler than the software development processes that came before and was a better fit to the available technology. It was also simpler and led to a higher level of code generation than competing methodologies of the time such as IBM's Rational Unified Process.Technology
Repository
Oracle Designer was initially based around a database that held design models, called a repository, not to be confused with a modern GIT repository ( A dictionary definition of a repository is a safe central place where things are stored). Later the Oracle Designer Repository included models and code, but always stored in an Oracle Database.Modelling and design tools
The tools that made up Oracle Designer each had their view on the repository, with which to create and edit models, generate more detailed models, generate code or inspect the quality of a model. For example specification designers were expected to indicate which data elements a function would use, so that the person designing the database structure could verify there were no unused data elements. Another example is the generation of a database definition from an entity relationship model, which eventually would be used to generate table creation scripts. Early users of Oracle Designer tended to focus on modelling and generating the database structures and often neglected the function model and modules. Initially the Oracle Designer user interface was developed using Oracle Forms and Oracle Reports. This was a character mode user interface that was typically used in terminal sessions or MS-Dos, with a GUI diagram editor that ran on Unix X-Windows terminals only. When graphical user interfaces became easily available on the Windows 3.1 and Windows 95 operating systems in the mid 1990's, a stopgap version was released in Forms 4.0 but quickly shelved and redeveloped in C++ as a Windows only program with sophisticated diagramming tools.Code repository
By the time Oracle Designer became obsolete it encompassed code generation of Oracle Forms, Oracle Reports, Database triggers, Stored Database Procedures. It would be commonplace for large portions of a systems code to be generated in this fashion, with developers working around the code generators to add custom code at predetermined lifecycle events.Reasons for moving away from Oracle Designer in the 2000's
Three trends made the Oracle Developer tools obsolete and Oracle Designer with it.The internet
Oracle Designer/Developer was aimed at development of administrative systems that were mainly used internally by enterprises. Many applications appearing in the 2000's required customers to perform some form of self-service data entry. The architecture of Oracle Developer was not well suited to the needs and technologies of the internet because it would have required users on the internet to install some kind of application and then directly connect to a database. Although later versions of Oracle Developer included an application server, it required a java based plug-in to be installed in the users-browser which placed high demands on end-users browsers. This posed a challenge for organisations with a fleet of older computers and was impractical for customer-facing applications. Eventually enterprises moved to other development tools which supported HTTP/HTML form based transactions, removing the need for the associated Oracle Designer.Integration requirements
After introducing systems for internal business processes in the 70's to the 90's, enterprises started to place more emphasis on integration between systems. Internet technologies such as HTTP, SOAP and Web-services became industry standards for data-exchange, but Oracle Developer's architecture made it hard to activate part of an application from an external source.Graphical user interfaces
From 2000 onwards, graphical user interfaces and usability became a major factor in adopting newer development stacks. Oracle Developer was intended for, and very good at administrative applications that are used for data entry by enterprise employees. New users had to be trained how to use certain key-combinations in order to user the applications. For example each screen had a query and insert mode which allowed users to find and manipulate thinly veiled database records. Screens tended to resemble a collection of spreadsheet-like tables with a menu structure. Expectations of system user-friendliness increased in the 2000s and eventually outweighed the development productivity advantages of generating these types of applications.Components
;Business Process Modelling * Process Modeller ;Systems Analysis Modelling * ER Diagrammer * Dataflow *Versions
Oracle CASE 1 Oracle CASE 2 Oracle CASE 3 Oracle CASE 4 Oracle CASE 5 - developed using SQL*Forms 3 character mode screens Oracle CASE 5.1 was a major redevelopment where the screens were redeveloped using the Oracle Forms 4.0 which provided a GUI interface The version numbers get confusing at this point because the numbers go backwards. The software was renamed and the next version released was Oracle Designer/2000 6.0 (not to be confused with Designer 6 that was released years later). The next minor release changed the numbering system to be in line with Oracle Developer, so it was named Designer 1.1 Designer 1 which supported generators for Forms 4.5 Designer 2 which supported generators for Forms 4.5 and 5 After this point the version numbers were changed to be in line with Oracle Developer Designer 6 which supported generators for Forms 4.5, 5 and 6. Designer 6i - the pre-release version number was 6.5. The production release was changed to 6i to keep in sync with the Oracle Developer version name Designer 9i Designer 10gR2 (10.1.2.6) – this was the last release of DesignerPublications
* * * * * * * {{cite book , last = Kramm , first = Mark , title = Oracle Designer , publisher = Prentice Hall PTR , location = Upper Saddle River , year = 2000 , isbn = 0-13-015343-5References
External links