Prototyping model and Object oriented model

The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation
Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage.
After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation.
The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back. There is now a new generation of tools called Application Simulation Software which help quickly simulate application before their development.

Advantages of prototyping
May provide the proof of concept necessary to attract funding
Early visibility of the prototype gives users an idea of what the final system looks like
Encourages active participation among users and producer
Enables a higher output for user
Cost effective (Development costs reduced)
Increases system development speed
Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities
Helps to refine the potential risks associated with the delivery of the system being developed

Disadvantages of prototyping
User’s expectation on prototype may be above its performance
Possibility of causing systems to be left unfinished
Possibility of implementing systems before they are ready
Producer might produce a system inadequate for overall organization needs
User can get too involved where as the program can not be to a high standard
Structure of system can be damaged since many changes could be made
Producer might get too attached to it (might cause legal involvement)
Not suitable for large applications

Electronics prototyping
In electronics, prototyping means building an actual circuit to a theoretical design to verify that it works, and to provide a physical platform for debugging it if it does not.
The prototype is often constructed using techniques such as wire wrap or using Vero board or breadboard, that create an electrically correct circuit, but one that is not physically identical to the final product

mass produce custom printed circuit boards than these other kinds of prototype boards. This is for the same reasons that writing a poem is fastest by hand for one or two, but faster by printing press if you need several thousand copies.
[Edit] Rapid Electronics prototyping
The proliferation of quick-turn pub fob companies and quick-turn pub assembly houses has enabled the concepts of rapid prototyping to be applied to electronic circuit design. It is now possible, even with the smallest passive components and largest fine-pitch packages, to have boards fobbed and parts assembled in a matter of day


Strength of object oriented model.
Object-oriented models have rapidly become the model of choice for programming most new computer applications. Since most application programs need to deal with persistent data, adding persistence to objects is essential to making object-oriented applications useful in practice. There are three classes of solutions for implementing persistence in object-oriented applications: the gateway-based object persistence approach, which involves adding object-oriented programming access to persistent data stored using traditional non-object-oriented data stores, the object-relational database management system (DBMS) approach, which involves enhancing the extremely popular relational data model by adding object-oriented modeling features, and the object-oriented DBMS approach (also called the persistent programming language approach), which involves adding persistence support to objects in an object-oriented programming language. In this paper, we describe the major characteristics and requirements of object-oriented applications and how they may affect the choice of a system and method for making objects persistent in that application. We discuss the user and programming interfaces provided by various products and tools for object-oriented applications that create and manipulate persistent objects. In addition, we describe the pros and cons of choosing a particular mechanism for making objects persistent, including implementation requirements and limitations imposed by each of the three approaches to object persistence previously mentioned. Given that several object-oriented applications might need to share the same data, we describe how such applications can interoperate with each other. Finally, we describe the problems and
solutions of how object-oriented applications can coexist with non-object-oriented (legacy) applications that access the same data.


Strength and weakness of object oriented model
Benchmarks between Odom’s and RDBMS have shown that ODBMS can be clearly superior for certain kinds of tasks. The main reason for this is that many operations are performed using navigational rather than declarative interfaces, and
navigational access to data is usually implemented very efficiently by following pointers.[3]
Critics of Navigational Database-based technologies like ODBMS suggest that pointer-based techniques are optimized for very specific "search routes" or viewpoints. However, for general-purpose queries on the same information, pointer-based techniques will tend to be slower and more difficult to formulate than relational. Thus, navigation appears to simplify specific known uses at the expense of general, unforeseen, and varied future uses. (However, it may be possible to apply generic reordering and optimizations of pointer routes in some cases).
Other things that work against ODBMS seem to be the lack of interoperability with a great number of tools/features that are taken for granted in the SQL world including but not limited to industry standard connectivity, reporting tools, OLAP tools and backup and recovery standards. Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support. However, this objection is offset by the fact that some Odom’s fully support SQL in addition to navigational access, e.g. Objectivity/SQL++, Matisse, and Intersystem CACHÉ. Effective use may require compromises to keep both paradigms in sync.


In fact there is an intrinsic tension between the notion of encapsulation, which hides data and makes it available only through a published set of interface methods, and the assumption underlying much database technology, which is that data should be accessible to queries based on data content rather than predefined access paths. Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint. This is one of the many impedance mismatch issues surrounding OOP and databases.
Although some commentators have written off object database technology as a failure, the essential arguments in its favor remain valid, and attempts to integrate database
Functionality more closely into object programming languages continue in both the research and the industrial communities

Investigate the prototyping model and any object-oriented model.
Discussion, see Object-oriented analysis and design and Object-oriented programming. The description of these Objects is a Schema.
As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object. Employment is a Relationship or Association. An Employee Class (or Object for simplicity) has Attributes like Name, Birthdates, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An Employee Method may be Promote, Raise, etc.

The Model description or Schema may grow in complexity to require a Notation. Many notations has been proposed, based on different paradigms, diverged, and converged in a more popular one known as UML.

An informal description or a Schema notation is translated by the programmer or a Computer-Aided Software Engineering tool in the case of Schema notation (created using a Module specific to the CASE tool application) into a specific programming language that supports Object-Oriented Programming (or a Class Type), a Declarative Language or into a Database schema.