Doctor of Philosophy, Computer Science

Submitted to:

Hypothesis 15

Method of Proof 16

Study Design 17

Joint Application Development (JAD) Implications 18

Chapter 2 ---- System Development Life Cycle (SDLC) 19

Application Development Evolution --- Lessons Learned 21

Management and Control of the SDLC 23

The Elusive "Silver Bullet" 25

Component Object Models 26

Chapter 3 --- Visual Integrated Development Environments (VIDE) 29

Component Object Libraries 31

Component Object Tailoring and Modeling 33

Component Object Independence 35

Chapter 4 --- Unified Modeling Language (UML) 37

Background 37

Obvious Problems --- Need for Standards 39

Universal Acceptance of UML 40

Object Oriented Development (OOD) Base 41

Modeling Component Objects 73

Logical Architecture Model (LAM) 76

Physical Architecture Model (PAM) 78

Transition of LAM to PAM (Prototype) 80

Chapter 5 --- Model Development Life Cycle (MDLC) Process 81

Overview of the MDLC Process 81

Data Model Driven Architecture (DMDA) 84

Chapter 6 ---- Case Example 88

Case Overview 89

Data (Table) Component Container 91

Form Component Container 92

Query Component Container 94

Report Component Container 96

Major Beneficial Characteristics of Component Objects 98

Chapter 7 --- The Future 100

User/Developer Distinction 101

Logical/Physical Model Distinction 102

Acronyms 107

Glossary 111

BIBLIOGRAPHY 117

Application Architectures developed in the New Millennium rely on Visual Component Object Oriented Rapid Application Development (VCOORAD) Tools. The Object Oriented (OO) Paradigm has replaced the traditional Procedure Oriented (PO) Paradigm for the Programming/Coding or more aptly named Construction/Assembly Phase of the Systems Development Life Cycle (SDLC).

Visual Integrated Development Environments (VIDE) utilizing core OO Development Languages of Java, C++, Visual Basic (VB), and other VCOORAD Development Tools provide Libraries of Predefined Component Objects that can be tailored and assembled to construct just about any Application System that is required. Prototypes utilizing VIDE combined with VCOORAD can be assembled from Component Objects to provide a "Rapid Prototype" of the Application System.

The Problem that develops with this Scenario is that VCOORAD utilizing a Component Object Architecture (COA) Assembly Approach is used primarily at the "Back-End" of the SDLC, but ignores the "Front-End" Phases of the SDLC. As such, there is a disconnect or lack of consistency in utilizing COA throughout the SDLC.

No wonder these Physical Architecture Models (PAMs) or Prototypes do not accurately model Business Processes or scale properly to the Enterprise they target. Past experience has shown that the SDLC has always relied on Modeling Tools to produce Logical Architectural Models (LAMs), rather than utilizing Development Tools to produce PAMs from very beginning of the SDLC.

Unified Modeling Language (UML) is no exception to this past Practice. Even though UML applies standardization, consistency, and Object Oriented Technology (OOT) to modeling the SDLC, it still suffers from the inability to properly transition to the PAM of the Application System.

Computer Application System Engineering (CASE) and Modeling Tools have always lagged behind VCOORAD Tools. They also focus primarily on a "Top-Down" LAM Approach, rather than a "Bottom-Up" COA PAM Approach.

Thus the Hypothesis of this Dissertation will adapt the SDLC to utilize VCOORAD combined with COA throughout all Phases of the SDLC in a consistent manner. This Process will be called the Model Development Life Cycle (MDLC) Process. The MDLC Process will focus on transitioning a PAM or Prototype throughout the Phases of the SDLC utilizing a COA VCOORAD Driven Approach. The MDLC Process will transition through the SDLC on a "On Demand" Basis at any level within the COA.

To my wife,

Sandra Lee Kubli,

for her support and perseverance.

To my parents,

Ken and Marion Kubli,

for all their faith in me.

To my wife's parents,

Maurice and Francis Walley,

for giving me Sandy.

I greatly appreciated the guidance, encouragement, and immediate feedback at all times of my Faculty Advisor, Dr. Anthony S. Russo, Ph.D, CS. Tony's help was instrumental in bringing out the best of me to produce this Dissertation.

As always a special thanks to my Parents for all their unwavering support and love throughout the years. I always told them that I had some unfinished Business after spending my first seven years in College without achieving my Ph.D. In retrospect, I am glad I waited forty years, because it means a lot more at this juncture of my life.

Lastly, to my wife of 36 years --- Thanks for putting-up with me, but you know I will never change. We have come along way since our beginning at 48 West Cleveland Drive, Buffalo, NY.

1376 N Spend A Buck Drive

Hernando, FL 34442

352-344-8076

rfka@yahoo.com

• BS, State University of New York at Buffalo

• Andover Work Group (AWG) Core Group Member for Application Interoperability.

Mr. Kubli has taught IT courses at Bentley College, Fisher Junior College, Kennedy-Western University, Northeastern University, and various IT training organizations. He is an adjunct professor at Bentley College and Kennedy-Western University. He has designed, developed, at taught the following IT courses.

• Applied Software Project Management
• Business Through Information Technology
• Visual Basic Programming Environment
• Visual Basic Application Development
• Advanced Visual Basic (ActiveX/COM Components)
• Business Information Systems Analysis and Design
• Analysis Modeling and Design
• Data Management with SQL (Oracle)
• Rapid Application Development Technology
• Object-Oriented Technology
• Relational Databases (Oracle)
• Management of Local Area Networks
• Fundamentals of WAN and LAN
• Introduction to JAVA
• Object Oriented Design (UML)
• Relational Database Management Systems (MS Access)
• VB/Java Script
• Internet and the World Wide Web
• Introduction to Programming C++

Figure 2.1 --- The Circular SDLC 19

Figure 2.2 --- The Recurring SDLC 21

Figure 2.3 --- Application Development Trends 21

Figure 2.4 --- SDLC Directed Prototype 23

Figure 2.5 --- Component Prototype Model 26

Figure 3.1 --- Visual Basic (VB) 6.0 29

Figure 3.2 --- Predefined Component Objects 31

Figure 3.3 --- Design of a Command Button using VB 33

Figure 3.4 --- Implementation of a Command Button using VB 34

Figure 3.5 --- Design of a Command Button using Microsoft (MS) Access 35

Figure 4.1 --- Standard UML Views 43

Figure 4.2 --- Use-Case Diagram for an Insurance Business 46

Figure 4.3 --- Class Diagram for Financial Trading 47

Figure 4.4 --- Object Diagram/Class Diagram Comparison 48

Figure 4.5 --- State Diagram 48

Figure 4.6 --- Sequence Diagram 49

Figure 4.7 --- Collaboration Diagram 50

Figure 4.8 --- Activity Diagram 51

Figure 4.9 --- Component Diagram 52

Figure 4.10 --- Deployment Diagram 53

Figure 4.11 --- Common Model Elements 54

Figure 4.12 --- Relationship Model Elements 55

Figure 4.13 --- Adornments 56

Figure 4.14 --- Note containing a Comment 56

Figure 4.15 --- Modeling Tool that shows Properties for the Class Portfolio 57

Figure 4.16 --- Stereotype Extends UML 58

Figure 4.17 --- Properties/Tagged Values 59

Figure 4.18 --- Constraints 59

Figure 4.19 --- Application Model(s) 61

Figure 4.20 --- MDLC Process for Logical Architecture Model (LAM) 62

Figure 4.21 --- Modeling Tool (Rational Rose) 64

Figure 4.22 --- Enterprise Modeler Trainer 66

Figure 4.23 --- Model Repository 67

Figure 4.24 --- Modeling Tool --- Code Generation 69

Figure 4.25 --- Modeling Tools versus Development Tools 71

Figure 4.26 --- Microsoft (MS) Windows Component Object Hierarchy 73

Figure 4.27 --- Example of MS Access Application 75

Figure 4.28 --- The Enhanced SDLC 76

Figure 4.29 --- Prototype or PAM 77

Figure 4.30 --- Design of a PAM 78

Figure 5.1 --- MDLC Process for a PAM 81

Figure 5.2 --- Data Model versus Input Process Output (IPO) Architecture 84

Figure 6.1 --- PAM Case Example 88

Figure 6.2 --- Component Object Architecture (COA) PAM 89

Figure 6.3 --- COA PAM BIB Table Structure 91

Figure 6.4 --- COA PAM BIB Form Design 92

Figure 6.5 --- COA PAM BIB Form Implementation 93

Figure 6.6 --- COA PAM BIB Query Design 94

Figure 6.7 --- COA PAM BIB Query Implementation 95

Figure 6.8 --- COA PAM BIB Report Design 96

Figure 6.9 --- COA PAM BIB Report Implementation 97

VCOORAD provides for the construction/assembly of pre-defined, tested, and verified Component Objects that have already transitioned the Phases of the SDLC [Martin5]. The Re-Use Benefit afforded by Object Oriented Technology (OOT) is best realized by assembling Physical Components as opposed to Logical Components [RFK13].

To prove the Hypothesis we take the following journey.

• SDLC --- Review the SDLC's penchant to lag advances in Application Development Technology [Demarco][Yourdan-Constantine][Yourdan2].
• Unified Modeling Language (UML) --- Review UML's inadequacies in generating the PAM or Prototype [Eriksson-Penker].
• Model Development Life Cycle (MDLC) --- Transform the Traditional SDLC based Application Development Process to a MDLC Process that focuses on the PAM rather than the LAM [RFK9].
• Case Example --- Assemble a PAM using the new MDLC Process based on VCOORAD and COA [Prague-Irwin].

The empirical data to support this Hypothesis is based on the following.

• 30 Years of Application Systems Development Experience [RFK1]-[RFK29].
• 20 Years of Teaching Applications Systems Development with concentration on Component OOT coupled with advances in applying Application Development Technology to drive the Traditional SDLC.
• Review of IT Literature concerning Application Development Tools, Software Engineering Disciplines, Modeling Languages, SDLC Advances and Trends, Component OOT, and Application System Architectures.

Another factor supporting the Hypothesis is that the Distinction between Developer and User is becoming less clear. Advances in IT have led to Joint Application Development (JAD) Approaches where Users actively participate in all Phases of the Traditional SDLC [O'Brien].

JAD is a progressive Trend fueled by VCOORAD Tools that provide a Common Forum for Project Teams of Developers and Users to build PAMs or Prototypes of the Application System. The Requirements, Analysis, and Design Phases become automatically verified when JAD is built into the Application Systems Development Process. When Users actively participate in the assembly, tailoring, testing, and verification of predefined Component Objects, chances are good that the ensuing PAM satisfies their Requirements.

No longer do we need to transition through the Phases of SDLC encumbered with voluminous documentation Deliverables that logically attempt to verify that each Phase has been completed satisfactorily. A much better approach is have Users and Developers work together to develop a PAM or Prototype of the Application System that can be tailored, tested, verified, and if necessary re-transitioned through the SDLC.

Figure 2.1 --- The Circular SDLC

The Traditional System Development Life Cycle (SDLC) includes five Major Phases [Wetherbe][Shelly-Cashman][Kroenke1][Martin 7][Orr1][Orr2][Tudor].

• Analysis --- Determine Application System Requirements.
• Design --- Develop a Logical Architectural Model (LAM) of the Application System.
• Development --- Develop the Code (i.e. Programming) for the Input, Processing, and Output (IPO) Functions Common Architectural Model of all Application Systems.
• Implementation --- Install and Test the entire Code developed in the Development Phase in the target Operating Environment. Finally the Physical Architecture Model (PAM) is provided.
• Maintenance and Review --- Support and Maintain the Application System to comply with Requirements established in the Analysis Phase.

The Traditional SDLC has existed since the early days of designing, developing, and installing Host/Centered (H/C) Application Systems (i.e. UNIVAC I in 1951) [Ralston]. Major Advances in Application Development Tools have occurred since 1951, yet the same Phases of the SDLC still persist.

The five Phases are performed in order starting with the Analysis Phase. Before beginning with next Phase, a Deliverable verifying the successful completion of the prior Phase is required. The Deliverable for the in most cases (i.e. Analysis through Development Phases) were in the form of a LAM. Many times these Logical Representations of a particular Phase did not clearly represent the Phase.

This approach for verification of a particular Phase of the SDLC through a "Documentation Representation/Review Process" has been called the "Waterfall Approach". The entire Application System is transitioned through the five Phases of the SDLC until we reach the last downstream Phase (i.e. Maintenance and Review). If we want to modify the PAM we must repeat the entire Process by porting "upstream" to the original starting point (i.e. Figure 2.1 --- Start Here).

Figure 2.2 --- The Recurring SDLC

This Recurring SDLC was the only option for filtering Maintenance Modifications through the SDLC. All the Phases had be performed and the "Documentation Deliverables" supporting each Phase had to be updated. More time was spent on Documentation than on implementing the Change.

Figure 2.3 --- Application Development Trends

The SDLC Process depends heavily on advances in Application Development Technology. Significant Advances in Application Systems Development include the following.

• High Level Languages (HLL) [Martin1].
• Relational Database Management Systems (RDBMS) [Martin8][Vaughn][Kroenke2].
• Fourth Generation Languages (4GLs) [Martin2][Martin4].
• Application Packages (APs) [RFK1].
• Object Oriented Languages (OOLs) [Sun][Morrison][Davis][Deitel1][Deitel2].

The real breakthrough has been the consolidation of these advances into a single Visual Component Object Oriented Rapid Application Development (VCOORAD) Environment. VCOORAD allows the SDLC to operate on a Modular or Component Basis. We can now transition through the Phases of the SDLC on a Component Basis as opposed to an Entire Application System Basis,

Moreover, VCOORAD coupled with Joint Application Development (JAD) allows the Front-End Phases of the SDLC (i.e. Analysis, Design, and Development) to collaborate with the "Back-End Phases (i.e. Implementation and Maintenance) on interactive basis. For example a pre-defined Component can be modified, enhanced, and tested in the Integrated Development Environment (IDE) provided by the VCOORAD Tool.

Figure 2.4 --- SDLC Directed Prototype

Management and Control of the SDLC is altered dramatically by VCOORAD. Voluminous Documentation required to support a myriad of LAMs can now be supported by a Component Based PAM. Users and Developers will actively participate collaboratively in this new use of the SDLC.

Likewise the Project Management Process of the Application Development Project will be modified accordingly. This is a positive change that will focus on the Prototype as the "Work-in-Progress" Product that can be designed, developed, and tested at the Component Object Level. Users as well as Developers will be responsible for design, development, and testing Phases.

No longer will the SDLC focus on Documentation to manage and control the Application System Development Project, but shift the focus for management and control to the Prototype. The Prototype will not only lift the "Documentation Burden" but provide a "Work-in Progress" PAM that can provide Training and generate real-time Documentation.

Applying the SDLC directed Prototype to the Management and Control Process truly empowers the People Resource of the Information System (I/S). I managed a large Project to develop, design, and implement a Statewide Financial System for the State of Connecticut in late 1970s [RFK25]. I remember the Project Team's frustration with the enormous amount of time spent on the Management and Control Process at the expense of the Application Development Process. I spent the majority of my time managing the Documentation and chairing Meetings to explain and justify LAMs of the proposed Financial System. Unfortunately, I did not have the VCOORAD Tools to demonstrate a PAM or 'Work-in Process" Prototype of the Financial System. The SDLC directed Prototype would have provided a PAM to State Officials, Legislators, and Other Consultants that would have allowed the Project Team to focus primarily on the End Product (i.e. The State Financial System).

Over the years numerous Application Development Technologies were thought to provide the Panacea for improving the SDLC Process. In the 1970's Database was the "Silver Bullet". My experience is that there is no "Silver Bullet", but a series of evolutionary breakthroughs that when consolidated will have potential to improve dramatically the SDLC Process [Yourdan1][Page-Jones1][Davis2].

VCOORAD is one of those breakthroughs if applied appropriately to the SDLC can improve dramatically the SDLC Process. But the appropriate application often requires a change in perspective. The change in perspective afforded by VCOORAD is a migration from the LAM to the PAM. Re-directing our focus from a LAM to a PAM perspective will enhance, shorten, and improve the accuracy of the SDLC.

Figure 2.5 --- Component Prototype Model

Component Object Models are Physical Models which produce "Working" Prototypes. Each Component described in Figure 2.5 is a PAM that can be transitioned interactively through all Phases of the Traditional SDLC via the VCOORAD Environment. Component Objects can be transitioned through the SDLC at the Component or Component Container Level (i.e. Form Container Component Object which contains a Command Button Component Object).

Component Objects can be transitioned independently through all Phases of the SDLC and/or transitioned as part of Component Object Container. For example, I developed a Visual Basic (VB) Application with some 250 Form Component Object Containers. Each Form had an "OK" Command Button Component Object. My objective was to ensure that the "OK" Command Button Component Object was designed, developed, and implemented consistently throughout the Application System [RFK22] [Masters][Petroutsos-Hough][RFK8][RFK9][Jamsa-Klander].

VCOORAD provided an Environment to transition the "OK" Command Button Component Object through all the Phases of the SDLC. Once the JAD Team was satisfied with the Prototype of the Command Button Component Object, the Component was added to each Form Component Object Container (i.e. In this example 250 times) [Ernst][RFK15].

As such, VCOORAD provides significant advantages over older Development Environments.

• Reuse of predefined, enhanced, and SDLC verified Component Objects.
• Incorporation of SDLC verified Component Objects into Component Object Containers (i.e. Forms, Reports, Queries, etc.)
• Transition Scalability through the SDLC at any level within the Component Object Hierarchy.
• Provides a PAM at the Component Object Level that once transitioned through the SDLC can be re-used without reservation throughout the target Application System or other Application Systems.
• Provides a PAM that can be used throughout all Phases of the SDLC. No need to alternate between LAMs and PAMs as the SDLC is traversed.
• Provides a true "Bottom-Up" Component Assembly Approach that can be transitioned through all the Phases of the SDLC at any level of the Component Object Hierarchy [Swann][McGowan-Kelly].
• Provides for Developers and Users a like (JAD Team) to actively participate in all Phases of the SDLC.

As such, VCOORAD does not change the SDLC, but enhances our ability to transition through the SDLC in a timely, accurate, scalable, and collaborative manner.

Figure 3.1 --- Visual Basic (VB) 6.0

A number of Visual Integrated Development Environments (VIDE) are available. In the Windows/Intel (WIN/TEL) World, Microsoft's Visual Studio Integrated Development Environment (IDE) has led the way [RFK8].

Figure 3.1 provides an example of VB 6.0 which is a member of the Visual Studio IDE.

Visual Basic is an example of a VCOORAD Tool that allows transition through the Phases of the SDLC at the Component Object Level. VCOORAD Tools as depicted by the Visual Basic example include the following common elements.

• Work Area --- A work area to design, develop, implement, and test Component Objects (i.e. ADO and ADO Data control Form in Design Mode).
• Component Object Hierarchy --- Project Hierarchy Chart (i.e. ADO and ADO Data control form).
• Property Box --- List of Properties and Values (i.e. ADO and ADO Control Form)
• Code Window --- Visual Basic Code for Component Object (i.e. Not shown in Figure 3.1).
• Menu Bar --- Visual Basic Main Menu (i.e. Similar to other Microsoft Products).
• Tool Bar --- Visual Basic Tool Bar (i.e. Similar to other Microsoft Products).
• Tool Box --- Visual Basic Component Objects that can cam be dragged dropped into the Work Area (i.e. The Search Command Button at the bottom left hand corner of the ADO and ADO Data control Form was assembled from this predefined Component Object).

Figure 3.2 --- Predefined Component Objects

VCOORAD Tools provide a robust range of Component Objects that can be added to the Tool Box. VB 6.0, for example, contains over 50 standard predefined, tested, and executable Component Objects [MS1].

This number increases exponentially with each new release of VB. Over 3,000 Developers develop Component Objects that can be used in a number of VCOORAD Tools beside Visual Basic. Some VCOORAD Tools, including Visual Basic, allow you to develop your own new Component Objects.

A few years ago, one of my Clients who developed and marketed a Clinical Workstation System to Healthcare Providers, inquired on adding a Patient Scheduling Function to their System. Their first reaction was to purchase an established Patient Scheduling Package and integrate it into the Clinical Workstation System. My advice was to find a Component Object for Scheduling. I suggested this for the following reasons [RFK1].

• The existing Patient Scheduling Packages were based on older obsolete Development Technologies.
• Integration with the Clinical Workstation Package required custom interface, special licensing, hardware/network platform, and support/maintenance considerations.
• The Data Model of the Patient Scheduling Package would have to be modified to comply with that of the Clinical Workstation System [Sanders].

A much better approach would be to use VCOORAD to extend the Clinical Workstation System through the addition of Component Objects.

Figure 3.3 --- Design of a Command Button using VB

Figure 3.3 illustrates the tailoring of a predefined Command Button Component Object using VB. Note the Command Button in Work Area with the Caption Property = "OK". The Font Dialog Window is shown to demonstrate how the Font of the Caption was changed to T Arial, 12 pt, and Bold. The Font Dialog is the same Component Object that is used in other Microsoft (MS) Development Products (i.e. MS Access).

Figure 3.4 --- Implementation of a Command Button using VB

Figure 3.4 describes the implementation of the Command Button designed in Figure 3.3. Note this example describes how a Component Object (i.e. Command Button) is tailored and modeled as it is transitioned through the Phases of the SDLC.

The SDLC can be repeated or recycled for the Command Button until everyone on the JAD Team is satisfied. Each time a PAM of the Component is produced that can be further analyzed, designed, developed, implemented, and maintained.

Figure 3.5 --- Design of a Command Button using MS Access

Figure 3.5 describes the Design of a Command Button Component Object using MS Access as the VCOORAD Tool rather than VB that was used in Figure 3.3. Note the similarities in the Component Objects that comprise the VCOORAD Tool (i.e. Tool Box, Form Work Area, Property Box, etc.).

Note also the similarity in the Command Button Component Object. The predefined Component Objects that can be tailored, assembled, and prototyped are shared across the various VCOORAD Tools [Simpson-Robinson].

Thus Component Objects are transparent across VCOORAD Tools as well as Application Systems constructed/assembled from these Component Objects. This the epitome of "Open Systems" Application Development. I am writing this dissertation on my Server (i.e. NT 4.0) in a 2-Tier Client Server (C/S) Architecture Environment. I can even migrate my dissertation to my Client (i.e. Laptop -- WIN 98) and continue my work with out making any adjustments [RFK4][OHE].

As such, Component Objects not only traverse Application System boundaries but also Computer System Architectures. Moreover, Distributive Common Object Model (DCOM) and Common Object Request Broker Architecture (CORBA) are Distributive Component Object Architecture Technologies that distribute Component Objects across the Enterprise [RFK3][Appleman][Dickinson].

Thus Component Objects are independent of the Application System, Computer Systems Architecture, and Location.

UML is a Modeling Language that consolidates the efforts of three early Pioneers who applied OOD Methods to the Systems Development Life Cycle (SDLC). Grady Booch, James Rumbaugh, and Ivar Jacobson otherwise known as the "Three Amigos" had worked independently in the early 1990s, each on their own OOD Methods.

Grady Booch developed the Booch Method which described an Application as a "Number of Views". Each View was described in further detail by numerous "Model Diagrams". Each Diagram included numerous notations and symbols that were not very familiar or intuitive. They were also hard to draw. On the plus side, however, the Booch Method was hierarchical, iterative, and subject to "Top-Down" Decomposition [Martin6][Swann][McGowan-Kelly][RFK12].

James Rumbaugh, while at General Electric, developed the Object Modeling Technique (OMT) in 1991. OMT is based on a number of individual Models: The Object Model; The Dynamic Model; The Functional Model; and The Use-Case Model. Each of the Models work in consort to provide a complete description of the process of transforming a Requirements Specification to a Logical System Design Model.

Ivar Jacobson developed the Object Oriented System Engineering (OOSE)/Objectory Method in 1994. The OOSE/Objectory Methods focus on developing a Use-Case Model to define the Requirements Definition of an Application as viewed by an "External Actor". The Use-Case Model is then implemented throughout each Phase of the SDLC. The Objectory Method was adapted to model Business Processes and is used extensively in Business Process Re-engineering (BPR).

Two other OOD Methods were developed in the early 1990s to compliment the work of the "Three Amigos". The Fusion Method developed at Hewlett-Packard in 1994 enhanced many of their ideas, particularly interactions between Objects. Again the Fusion Method contained numerous Model Diagrams with unique notations and symbols. The second OOD Method is the Coad/Yourdan or Object Oriented Analysis (OOA)/OOD Method. This was one of the first OOD Methods and although easy to learn and use, it did not scale very well to handle complex Applications. The OOA/OOD Method is still valuable for introducing Novices to Object Oriented Technology (OOT) [Yourdan2].

As such by 1995, the mechanism was established to consolidate the early Work and develop a Standard OOD Methodology called UML. Version 1.0 of UML was released in January 1997. UML has four major goals.

• To Model Systems using OO Concepts.
• To establish explicit coupling to conceptual as well as executable Artifacts.
• To scale from simple to complex Applications.
• To create a Modeling Language useable by Humans and Machines.

• Made UML Nonproprietary, Available to All, and Open to All.
• Formed the UML Partners Consortium.
• Developed an Agreement with the Object Management Group (OMG) to adapt UML as the OMG Standard for Modeling Languages.
• Developed a Joint Agreement with Microsoft to jointly develop and market Enterprise Development Tools. This will allow Microsoft's Application Development Tools to integrate with Rational's UML Tool (i.e. Rational Rose)

UML is an Object Oriented Modeling (OOM) Language. As such, all the Components of UML are based on the OO Paradigm. Features of OOD incorporated into UML include:

• Models that specify Domains in a natural way such as a Business, Machine, or User Domain;
• Models that are constructed, changed, expanded, extended, validated, and verified in an simplistic accurate manner;
• Models that are flexible, have well defined architectures, provide re-usable components, and trace original functional requirements to executable methods in the Application;
• Models that can be implemented in software using OO Programming Languages;
• and Models that integrate the Development Process and Modeling Language with suitable Construction Techniques and Tools.

UML includes the following major Components.

• View(s) --- Show Aspects of the Object being modeled. A View is an Abstraction containing a number of Diagrams. Views also integrate the Modeling Language (i.e. UML) with OOD Methodology. A Model contains more than one View to model an Object.
• Diagram(s) --- Describe the Contents of a View. UML has 9 Standard Diagram Types.
• Model Element(s) --- Represent common OO Concepts such as: Classes; Objects; Messages; and Object Associations, Dependencies; and Generalizations. Note Model Elements are used as Content in many Diagrams but always have the same meaning and symbol. Another words, A Diagram(s) can be thought of as an Object Container containing Model Element Object(s).
• General Mechanisms --- Provide extra Comments, Information, and Annotations that further describe a Model Element(s). Extension Mechanisms are provided to extend UML to a specific OOD Methodology.

• Use-Case --- Describes Functionality of the Application as perceived by an "External Actor".
• Logical --- Describes Functional Design of the Application in terms of its Structure and Dynamic Behavior.
• Component --- Describes the Organization/Hierarchy of the Application's Object Components.
• Concurrency --- Describes the Communication and Synchronization Requirements of the Application.
• Deployment --- Describes the Physical Architecture of the Application including: Hardware; Software; Network; and People Information System (I/S) Resources.

• Association --- Connects Elements and links Object Instances.
• Generalization (i.e. Inheritance) --- One Element is a Specialization of Another.
• Dependency --- One Element depends on Another.
• Aggregation --- One Element contains other Elements.

• Diagrams (Schematics) --- Render Diagrams according to the Standards imposed by the Modeling Language.
• Repository --- Provide Common Database for the Model and all its Components.
• Navigation --- Navigate throughout the Model for the same Model Element or Component. Trace the Model through layers of Decomposition in either a "Top-Down" or "Bottom-Up" Direction.
• Multi-User/Location Support --- Support Work-Group Collaboration from multiple locations in a synchronous and asynchronous manner.
• Executable Model --- Generate Physical Model (i.e. PAM) or Prototype.
• Reverse Engineer --- Generate Logical Model (i.e. LAM) from Physical Model (i.e. PAM) or Prototype.
• Integration --- Integrate with other Modeling and/or Development Tools.
• Interchange --- Provide Import/Export Capability with other Modeling Tools and /or Development Tools (i.e. Extended Mark-up Language (XML)).

A Model Repository (Database) must be maintained to provide Work Group Collaboration capability on all Components of the Model(s). The Repository should provide the following Features, Functions ,and Capabilities.

• Inconsistency Check --- Provide Referential Integrity throughout the Model Data Model (Repository). Ensure Consistency of each Model Component throughout all Views, Diagrams, and Objects of the Model.
• Evaluation --- Evaluate Model for Incompleteness, Inaccuracy, and Inappropriateness.
• Reporting --- Provide Reporting System to provide accurate, updated, and universal real-time Documentation of Model.
• Component Model Elements --- Visual Component Object Oriented Rapid Application Development (VCOORAD) Architecture to allow re-use, generation, and tailoring of Component Model Elements.

• Development Environment --- Model a Component Object throughout all the Phases of the traditional SDLC.
• Configuration Environment --- Provide Version Control throughout all Phases of the traditional SDLC at the Component Object Level.
• Documentation Generation Environment --- Generate Documentation for each Phase of the Traditional SDLC at the Component Object Level in real-time.
• Testing Environment --- Test and Verify Component Objects and Dependencies throughout each Phase of the Traditional SDLC.
• Graphical User Interface (GUI) Construction/Assembly Environment --- Construct GUI Component Objects from Component GUI Object Library. Tailor GUI Component Objects to achieve Consistency across Forms, Queries, and Reports.
• Project Management Environment --- Integrate with MDLC Process to manage, control, and validate Modeling Process(s).

Figure 4.26 --- Microsoft (MS) Windows Component Object Hierarchy

Modeling Standard Component Objects typically found in OOD Application Systems can best be modeled using a Visual Component Object Oriented Rapid Application Development (VCOORAD) Tool such as VB, MS Office, MS Access, Delphi, and Others. Each of these Rapid Application Development (RAD) Tools allow the Developer/User to assemble/construct Component Objects from predefined Component Objects [RFK14][Martin1][Appleman].

MS Windows Development Products share throughout the Product Line Component Objects. In fact Visual Basic for Applications (VBA) provides the foundation for the MS Office Product(s). VBA that is used for the Code Component Objects Portion of Access is identical to the same Code Component Objects used in Visual Basic.

Microsoft has also taken the Component Object Development Process another step to allow increased re-use, extension, and enhancement of pre-defined Component Objects. A common Integrated Development Environment (IDE) that is neutral with regard to the Development Language used to Assemble/Construct Component Objects. Visual Studio 7.0 will allow the Developer/User to Assemble/Construct Component Objects with a variety of Program Development Languages (i.e. Visual Basic, Visual C++, Visual C# (i.e. C Sharp), Visual J++, Visual InterDev, Visual FoxPro, and Others). Moreover, Components developed in one Program Development Language can be re-used, enhanced, or extended by any of the other Program Development languages or Application Development Products. (i.e. MS Office) [Dietel1][Dietel2][RFK6].

This concept of Component Object "Re-use" is not just restricted to Microsoft Products but extends to all Products based on the Widows-Intel (WINTEL) Platform. Some 3,000 Independent Developers develop Component Objects for the WINTEL Platform.

Given this trend in developing Application System Architectures, modeling of Component OO Application Systems can best be accomplished using VCOORAD Tools rather than Modeling Tools or traditional CASE Tools. VCOORAD Tools provide a "Working Physical Model" (i.e. Prototype) that can be evaluated in a "Real World" Environment.

Figure 4.27 --- Example of MS Access Application

Figure 4.27 displays a "RFK Associates, Inc.'s Homegrown" Accounting Application System ---- General Accounting Management System (GAMS). GAMS was modeled in two hours. The Initial Model has been refined over the last three years as new requirements developed. It is based on common Component Objects that have been extended, tailored, and enhanced to meet my Requirements.

The Logical Architectural Model (LAM) is described by the Use-Case, Logical, Component, and Concurrency Views of UML. The LAM is has traditionally been used to model the Front-End Phases of the SDLC.

Figure 4.28 --- The Enhanced SDLC

The Front-End Phases (Requirements and Analysis Phases) of the SDLC are described by a LAM. The purpose of the LAM is ensure that the Front-End Phases are properly transitioned to the Back-End Phases (Development and Implementation Phases) of the SDLC. The Design Phase provides for that Transition. This is the Juncture where Modeling Tools give way to Development Tools.

Full CASE provides the seamless linkage of the Front-End and Back-End Phases. Integrated CASE incorporates a Project Management Phase to manage, control, and verify the Complete Modeling Process --- Logical Architectural Model (LAM) to the Physical Architecture Model (PAM).

The Project Management Phase provides the glue ensure the proper Transition between the LAM and the PAM.

Figure 4.29 --- Prototype or PAM

Advances in VCOORAD Tools combined with Joint Application Design (JAD) have provided opportunity to create a Prototype (i.e. A working PAM) to support the Design, Development, and Implementation Phases of the SDLC. VCOORAD allows us to construct, assemble, and enhance registered Physical Component Objects. For example, a "Command Button" Object Component has already transitioned through the Front-End Phases of the SDLC.

We do not have develop a LAM for this Component Object. We can "go directly" to the PAM by re-using Component Objects that have already been Physically Architected. Nor do we have to develop Use-Case, Logical, Component, and Concurrency Views of UML for these Registered Component Objects.

Figure 4.30 --- Design of a PAM

The PAM (Prototype) of the Command Button Component Object for the Cornucopia Switchboard Form is described in Figure 4.30. The Design Phase of the MDLC is modeled with "Property Boxes" specifying behavior of the Command Button Component Object that can be extended, tailored, and enhanced at "Design Time". Note the Macro named Sales Options extends the Command Button Component Object by launching the Sales Options Form when the Command Button responds to a "On Click" Event.

The Implementation of the PAM (Prototype) can be verified immediately by merely launching the Command Button Component Object. Thus the Component Object can be Modeled (Prototyped) through the Design, Implementation, and Testing Phases of the MDLC.

Prototyping or Modeling the PAM provides a Process for instant implementation, testing, and verification to allow Designers/Developers/Users (Joint Application Development (JAD)) to prove the Design. This would not be possible using the LAM.

Thus as VCOORAD Tools have become more robust, the MDLC has become more focused on the PAM. Furthermore, VCOORAD Tools have also become more "User Friendly". User have become empowered and work collaboratively with Developers in JAD Environments. Thus the distinction between Developer and User has faded dramatically.

As such the Requirements, Analysis, Design, Implementation, and Testing/Verification Phases of the traditional MDLC have transitioned to the complete purview of the VCOORAD tool when approached at the Component Object Level. Natural Hierarchies of Components established initially by Windows makes this a reality --- How many times will we re-architect a Command Button?

VCOORAD has made the Traditional MDLC obsolete. VCOORAD allows us to develop individual Component PAMs and then assemble the individual Components PAMs building Higher Level PAMs that comply with the Component Object's Hierarchy --- Much Like a Component Object "Bill of Materials".

Whereas LAMs were built in a "Top-Down" Decomposition Manner, PAMs are built in a "Bottom-Up" Re-composition Manner. LAMs use Logical Components --- PAMs use Physical Components.

The Process of the Traditional SDLC transitioned by a VCOORAD Tool at the Component Object Level to produce a PAM called a Prototype is referred to as the Model Development Life Cycle (MDLC) Process [RFK3][RFK4][RFK5].

Figure 5.1 --- MDLC Process for a PAM

The MDLC Process is based on the use of a VCOORAD Tool to direct the development of a Physical Architecture Model (PAM) or Prototype. This requires an Integrated Development Environment (IDE) that provides a seamless connection between all the Phases of the Traditional SDLC [Fitzgerald-Stallings].

The seamless connection allows the Developers/Users of the Joint Application Development (JAD) Team to transition a Component Object or an Assembly of Component Objects through the Phases of the Traditional SDLC to produce a PAM or Prototype. The Prototype can be tested and verified immediately to the complete satisfaction of the JAD Team.

The Unified Modeling Language (UML) Methodology standardized Object Oriented Modeling (OOM) Technology with a primary focus on the development of Logical Architectural Models (LAM)s. The MDLC Process supports many of the OOM concepts pioneered and standardized by the UML Methodology [Eriksson-Penker].

The MDLC Process, however, while extending the UML Methodology also deviates to a major extent.

• Physical Architectural Model (PAM) --- MDLC is based solely on a PAM. MDLC does not try to map the LAM to the PAM. The End Product of the MDLC Process is a Prototype that can be scaled, tested, and evaluated.

• Predefined Component Object Base --- MDLC is based on a "Bottom-Up" Predefined Component Assembly or Construction Approach which conforms to an already established Component Object Hierarchy (i.e. Window Objects Hierarchy) [MS1].
• Development Language/Modeling Language --- MDLC uses a Visual Component Object Oriented Rapid Application Development (VCOORAD) Tool to drive the MDLC Process. The UML Methodology relies principally on UML to develop the LAM, but also requires Computer Assisted System Engineering (CASE) and Other Development Tools to provide Documentation and a map to the PAM.
• Data Model/Input Process Output (IPO) Model --- MDLC and the VCOORAD Tool that drives the Process is based on Data Model focus of Application System Architecture. An Architecture where the Data Model drives the Input, Processing, and Output Functions. The Object Oriented Development (OOD) Paradigm has already predefined these IPO Functions. As such, the Data Model drives the OOD Process. UML still focuses on the older IPO Application System Architecture [MS2].
• Joint Application Development (JAD) --- MDLC using VCOORAD provides an Integrated Development Environment (IDE) conducive to Users and Developers alike. UML requires Developer Expertise to model User Requirements to LAM Views. This is unfamiliar territory for the User Community.

Figure 5.2 --- Data Model versus Input Process Output (IPO) Architecture

The IPO Architecture (IPOA) has given way to the Data Model Driven Architecture (DMDA) for the Application System. IPOA mirrored the Architecture of the General Purpose Programmable Computer envisioned by John von Neumann in 1945. IPOA was the LAM for the first Commercial Application System (i.e. UNIVAC I in 1951) [Ralston][RFK2].

IPOA persisted until the middle 1990s when VCOORAD Tools combined with Relational Database Management Systems (RDBMS) began to state their presence as viable Application Development Tools. Prior to this time, Application Systems Development took the following steps [Sanders][RFK13][RFK28].

• Design the Output.
• Design the Input required to satisfy the Output.
• Design the Processing required to process the Input into a form required by the Output.
• Ignore the Data Model.

This approach made Custom Application System Developers very happy. They had the opportunity to "re-invent the wheel" many times over for the same Application System. Application System Development Back-logs became unacceptable to Users as Developers spent most of their time maintaining the Custom Application Systems they initially created.

Finally the "Man-Machine" Interface in the form of the Graphical User Interface (GUI) surfaced. GUIs had a dramatic break-through impact on the Application Development Process. A common metaphor for Users and Developers alike was born. It's ironic that GUI's had a more dramatic impact on Development Tools than the Application Systems produced by the Development Tools [RFK7].

The use of GUIs in Development Tools turned JAD from a "Pipe-Dream" to a Reality. Finally the end for the "Document Centered" SDLC was in sight. No longer were Users and Developers pitted as Adversaries in the SDLC, but now had the motivation to collaborate as Partners [RFK6].

Another significant development was precipitated by the GUI. GUI Components such as Text Boxes, Combo-Boxes, Command Buttons, and many others were created. A common nomenclature of Physical Predefined Component Objects were created that Developers and Users alike could understand and use productively.

These GUI Component Objects became the "Building Blocks" for the Form (i.e. We no longer have Screens thanks to VB) and Report Elements of the Data Model Driven Architecture (i.e. See Figure 5.3). The Form and Report Elements or Component Object Containers replaced the Input and Output LAMs with actual PAMs that Users could Analyze, Design, Develop, Implement, and Maintain [Martin5].

In the beginning these Component Objects that formed the "Building Blocks" for the GUI were just Visual Controls (i.e. VB 3.0). However, they quickly grew to become full fledged Component Objects complete with an extensive set of Properties, Methods, and Interfaces. The same group of Component Objects that originally replaced the Input and Output Functions of the IPOA with the Form and Report Elements of the DMDA formed the essential "Building Blocks" for the Query and Table Elements of the DMDA [Neibauer].

A host of Component Developers joined the revolution created initially by VB. Some 3,000 Independent Developers develop a host of Component Objects used in a number of VCOORAD Tools. These Predefined Component Objects can be used by numerous JAD teams to construct Application Systems for a number of different Computer System Architectures [RFK2][RFK3][RFK4][RFK5].

As such everything in the DMDA is predefined, tested, and verified with the exception of the Data Model. Get the Data Model correct and you have 90% of the Application System completed. The Table Element then becomes the "Critical Success" Factor for Application System. As seen by the DMDA described in Figure 5.2, The Table Element drives the Query, Form, and Report Elements of the PAM.

Figure 6.1 ---- PAM for Case Example.

The Case Example develops a PAM or Prototype based on the DMDA described in Figure 6.1. The Case Example prototypes the Bibliography and Appendices for this Dissertation.

Figure 6.2 --- Component Object Architecture (COA) PAM.

The COA Prototype contains Tables, Forms, Queries, and Reports for the Bibliography and Appendices of this Dissertation. The COA Prototype complies with the DMDA described in Figure 6.1. Microsoft (MS) Access is used as the VCOORAD Tool.

The VCOORAD Tool allowed the Construction/Assembly of the Table, Query, Form, and Report Component Object Containers from the Component Object Libraries that were incorporated into the Tool. Moreover, I was able to transition through the Phases of the SDLC at any stage of the Prototype Development for any Component. For example I could prove and verify the Report Component at various stages of loading Data via the Form Component to the Table Component.

The COA Prototype was used to develop and maintain the following Tables.

• BIB --- Bibliography.
• ACR --- Acronyms.
• GLS --- Glossary.

The Bibliography, Acronyms, and Glossary are exported in the "Rich Text" Format and inserted into this Dissertation. This approach greatly enhanced the Dissertation Construction Process, while allowing the primary focus to remain on proving the Hypothesis.

Moreover, it provided a primary relevant working example of the application of a PAM (Prototype) to solving a real problem. A real problem of maintaining the Bibliography and Appendices for a "Work in Progress" Dissertation.

Figure 6.3 --- COA PAM BIB Table Structure

The Bibliography Table Structure is shown in Figure 6.3. A number of iterations through the Phases of the SDLC and associated Component Object Containers were cycled before the current PAM was accepted.

Figure 6.4 --- COA PAM BIB Form Design

The Form Component Object Container for the Bibliography Form is described by Figure 6.4. Note the Tool Box that contains the individual Component Objects that were used to populate the Container (i.e. Label and Text Box Components).

The Form was constructed from available Component Objects that came with the VCOORAD Tool. The Component Object's Properties were tailored at "Design Time" to customize the Form.

Figure 6.5 --- COA PAM BIB Form Implementation

The Implementation of the Bibliography Form is described in Figure 6.5. Note that the Bibliography Table includes 83 Bibliography References. Managing the 83 References as the Dissertation progressed without an Application System would have been very difficult to say the least,

The VCOORAD Tool allows the Form Component Object Container to transition through the Phases of the SDLC as References were added to the Bibliography to test, modify, and verify the Form Prototype.

Figure 6.6 --- COA PAM BIB Query Design

The Query Component Object Container for the Bibliography Query is described in Figure 6.6. Note the Query Design is segmented into two parts. The Query Source (i.e. Table(s) or Query(s)) and the Query By Example (QBE) Grid. The QBE Grid generates a Structured Query Language (SQL) Statement or the SQL Statement can be entered directly.

Figure 6.7 --- COA PAM BIB Query Implementation

The Implementation of the Bibliography Query is described in Figure 6.7. Again the Query Component Object Container can be transitioned through the Phases of the SDLC. This can be performed at any stage of Development to test, modify, and verify the Container or any of it's Component Objects.

Testing the Query PAM is important because the Query Component Object Container is the source for the Report Component Object Container in the DMDA.

Figure 6.8 --- COA PAM BIB Report Design

The Report Component Object Container for the Bibliography Report is described in Figure 6.8. Note the Toolbox containing the Component Objects that are used to Construct/Assemble the Report are the same as those that were used to Construct/Assemble the Form Component Object Container.

Figure 6.9 --- COA PAM BIB Report Implementation

The Implementation of the Bibliography Report is described in Figure 6.9. Note the Report is sorted in alphabetic order by REFERENCE. This is because the Query (i.e. See Figure 6.6) sorts the records extracted from the table by REFERENCE. The Bibliography Query is the Source for the Report.

Component Objects facilitate the MDLC Process for a number of reasons as illustrated by the above Case Example.

• Physical Model --- They represent a Physical Architectural Model (PAM) rather than a Logical Architectural Model (LAM). As such they can be transitioned through the Phases of the SDLC at any stage of their Development at the Component Object Level. This obviates the need to map a LAM to a PAM.
• Re-Use -- Component Objects from the Predefined Component Object Library of the VCOORAD Tool can be Constructed/Assembled in various combinations to build Component Object Containers that provide a wide range of Solutions.
• Joint Application Development (JAD) --- Users and Developers alike can use the VCOORAD Tool(s) to develop the PAM (Prototype).
• Speed --- The Rapid Application Development Aspect is further enhanced by the application of OOD Technology to the MDLC Process --- Especially when the LAM is bypassed in favor of moving directly to the PAM (Prototype).

• Consistency --- Component Object Containers are all derived from a common set of Predefined, Tested, and Verified Component Objects. As such, Consistency is achieved across the Application System Development Spectrum without the need to create Standards Bodies to establish artificial unenforceable Standards for LAM construction. Again providing a MDLC Process that focuses on the PAM as opposed to the LAM eliminates this inherent Problem.

• Scalability --- Physical Component Objects that can be transitioned through all the Phases of the SDLC on a Demand Basis scale to various Tiers of the Client Server (C/S) Architecture without any difficulty. A recent Y2K Project proved this point. The Project Team created an Application System to control the Project using a VCOORAD Tool. We had very little difficulty moving our PAM between the Client(s) and the Server Tier [RFK28].
• Deployment --- Some 3,000 Independent Component Developers develop Component Objects that are deployed in various VCOORAD Tools to produce a myriad of Application Systems that deploy again the same Predefined, Tested, and Verified Component Objects. Deployment of a Physical Predefined Component Object is much easier than deploying a Logical Component Object. The mapping to the Code Component (i.e. UML) is an unnecessary step, if you are working with an "executable" Component Object in the first place.

The Future looks bright for Component Object Architecture (COA). Object Oriented Technology (OOT) coupled with COA and supported by VCOORAD Tools have revolutionized Application System Development [Appleman][Ernst].

Past History has shown the SDLC to persist since the days of the first Computer Application (i.e. UNIVAC I in 1951). However, the Process of traversing the SDLC was constrained by a lack of a MDLC based on Physical Architectural Modeling using COA "Building Blocks". Without these Physical Executable 'Building Blocks" and a VCOORAD Tool to Construct/Assemble them into a PAM (Prototype), the full and potential Benefits of the SDLC remained elusive [Ralston].

As such, the Future looks bright because all the pieces have finally after 50 Years come together. The Elusive "Silver Bullet" Developers have been looking for the last 50 Years may become a little less elusive [RFK6].

Thus a major Paradigm Shift in the SDLC has occurred. LAMs are giving way to PAMs and Prototypes. The implications of this Paradigm shift on Future Application Systems Development are expected to be dramatic [RFK23][Yourdan3][RFK29][RFK18][Currid-Eggleston].

COA has empowered the User to a much greater extent than the Windows Graphical User Interface (GUI). Joint Application Design has become Joint Application Development (JAD) as I have renamed it appropriately. Users now actively participate in all phases of the SDLC.

As such, the distinction between User and Developer continues to become less distinct. This trend is expected to continue at even a greater rate than in past years. Developers do not program or code anymore. Rather they build Predefined, Tested, Verified, and Industry Accepted (Standard) Component Objects. Users Assemble the Component Objects to form the Application System. Thus Users have assumed the role traditionally performed by Developers.

The People Resource of the Information System (I/S) has always been the limiting Resource. COA impacts this limitation in a positive manner to the greatest extent. As such, COA is a "Major Breakthrough" for ensuring the continued improvement in Application Systems Development for the Future.

COA provides the means to produce the PAM immediately. The major problem from the beginning with the SDLC was that it depended primarily on Logical Representations of Phase Deliverables. As such Users and Developers failed to Communicate. The Application System Implemented failed to provide the Solution envisioned by the Analysis Phase. As such, there was a major disconnect between the LAM and PAM.

Traversing all the Phases of the SDLC in a rapid manner to produce a PAM or Prototype at any level of Decomposition provides immediate feedback of the viability of the Model. The Difficulty of evaluating a LAM representation of an Application System is eliminated. An instantaneous PAM allows all Phases of the SDLC to be verified in a timely and accurate manner.

COA has allowed the instantaneous production of the PAM. The MDLC Process based on a PAM or Prototype will continue to gain favor over the LAM Approaches such as UML. VCOORAD Tools allow Users as well as developers to practice the MDLC Process in conjunction with COA. Users will continue to have a difficult time with UML's unnecessary Abstract Nature fostered by it's focus on a LAM.

Methodologies that focus on PAMs that are intuitive, understandable, and final product oriented will continue to gain favor in the Future. The distinction between LAMs and PAMs will wane because LAMs will become extinct in favor of PAMs..

COA improves the deployment, distribution, and scalability of Component Objects. N Tier Client Server (C/S) Architectures have become a major Beneficiary of COA. Distributive Common Object Model (DCOM) and Common Object Request Broker Architecture (CORBA) are C/S Architectures that view Component Objects as ubiquitous throughout the C/S Architecture [RFK4].

Component Objects are predefined, stand-alone, and executable Objects complete with Properties, Methods, and Application Program Interfaces (APIs) that can be deployed on any Tier(s) and distributed to any Tier(s) of the C/S Network. As such, COA becomes the fuel for the C/S Architecture Machine [OHE].

Deploying Component Objects under DCOM or CORBA in a C/S Architecture provides significant opportunity for distributing Component Objects to the Client or other Server Tiers. This decreases the Total Cost of Ownership (TCO) and facilitates the Application System Deployment and Upgrade Process. Microsoft Transaction Server (MTS) is an example of a N-Tier C/S Architecture were all the Component Objects are deployed and distributed from a single Server (i.e. Component Object Server) [Vaughn].

Component Objects developed on a single source Machine will be ubiquitous in terms of their Deployment, Distribution, and Scalability. This is definite Future Trend that will fuel N-Tier C/S Architecture.

The Application System Selection Process, especially the Request for Proposal (RFP), has always relied on the "Functional Richness" of the Application System Alternative. Unfortunately, "Functionally Rich" Applications are usually "Architecturally Poor" [RFK27].

Until COA the choice was easy. Structured programming, Fourth Generation Languages (4GLs), Relational Database Management Systems (RDBMS), and others failed to shift this Perception. All these I/T Application Development Advances failed to perform as expected because they were based on Logical "Top-Down" Decomposition Models. COA on the other hand is based on a Physical "Bottom-Up" individual Component Construction/Assembly Approach [Martin3][RFK17][RFK21][RFK16].

COA along with VCOORAD Tools allows Predefined Component Objects to be assembled into Component Object Containers. The Component Object can instantaneously be Prototyped to test, verify, and evaluate the Application System Solution. Individual Component Objects do not have to be re-designed --- only tailored.

Thus the trend has shifted from Re-Working "Top-Down" through entire Application System to Re-Assembly and Replacement of Component Objects that comprise the Application System. The COA Approach has changed our Perspective for maintaining and Developing Application Systems --- LAM Perspective to a PAM Perspective.

COA views Application System Development similar to the view of Product Development. An Automobile and an Application System can be Physically Modeled (Prototyped). The Automobile as well as the Application System are Constructed/Assembled from Predefined, Engineered, and Standard Components and/or Sub-Assemblies.

PAM based on COA and the accompanying MDLC Process is similar to an Automobile Assembly Operation, without the burdens of economies of scale. Independent Component Developers provide Component Object Assemblies that are Constructed/Assembled into the Application System.

Like the Automobile Industry, Application Software Vendors will submit specifications to Independent Component Developers for Component Object Assemblies to replace Application Functions developed under the older LAM. The Application Vendor will then use COA and VCOORAD to incorporate the Component Object Assembly into the Application System.

Thus the trend for the Future will shift the emphasis from a LAM of the entire Application System to a PAM of the Component Object Sub-Assembly. This Trend would not be possible without COA, VCOORAD, and the MDLC Process.