In Java, what is OOA? What is Ood? What is OOP?

Ooa

Object-oriented Analysis: An object-oriented analytical approach

is to analyze the problem according to the object-oriented thought after conducting the system business investigation in a system development process. There is a big difference between OOA and structural analysis. OOA emphasizes the analysis and collation of the material for the OO method based on the systematic investigation data, rather than the analysis of the management business status and methods.

The OOA (object-oriented analysis) model consists of 5 levels (subject layer, object class layer, structure layer, attribute layer, and service layer) and 5 activities (identifying object classes, identifying structures, defining topics, defining attributes, and defining services). In this method, we define the structure between two kinds of object classes, which is called the classification structure, which is called the assembly structure. The classification structure is the so-called general and special relationship. The assembly structure reflects the relationship between the whole and the part of the object.

Ooa to identify the instance connection while defining the attribute. An instance connection is a mapping between an instance and another instance.

OOA to identify the message connection while defining the service. When an object needs to send a message to another object, there is a message connection between them.

The 5 levels and 5 activities in the OOA continue throughout the Ood (drawing to object design) process. The Ood model consists of 4 parts. They are the design problem domain part, design the human-computer interaction part, the design task management part and the design data management part.

First, the main principle of OOA.

(1) Abstraction: Discarding individual, non-essential features from many things, extracting common, essential features, called abstraction. Abstraction is the necessary means of forming a concept.

The abstract principle has two meanings: first, although things in the problem domain are complex, analysts do not need to understand and describe everything about them, only to analyze the things that are related to system goals and their essential characteristics. Second, by abandoning individual things in the details of the differences, extracting their common characteristics and get a group of things abstract concept.

Abstraction is the most widely used principle in object-oriented methods. Abstract principles include two aspects of process abstraction and data abstraction.

Process abstraction means that any sequence of operations that completes a deterministic function can be viewed by the user as a single entity, although it may actually be done by a series of lower-level operations.

Data abstraction defines data types based on actions applied to the data, and limits the value of the data to be modified and observed only by these operations. Data abstraction is the core principle of OOA. It emphasizes the combination of data (attributes) and operations (services) into an irreducible system unit (that is, an object), and the outside of the object simply needs to know what it does without knowing what it does.

(2) Encapsulation is the combination of the object's properties and services into an irreducible system unit, and as far as possible to conceal the internal details of the object.

(3) Inheritance: The object of a particular class possesses all the properties and services of its general class, called the inheritance of a special class to a generic class.

The application of the principle of inheritance in OOA is that in each general-special structure formed by a general class and a special class, an object instance of the general class and an object instance of all special classes are collectively provided with properties and services that are explicitly defined in the general class at once. In a special class no longer repeats the definition of what is defined in a generic class, but semantically, the special class automatically and implicitly owns all of the properties and services defined in its generic class (and all the higher-level generic classes). The advantage of the inheritance principle is that the system model is more concise and clearer.

(4) Classification: is to classify objects with the same attributes and services into a class, using classes as an abstract description of these objects. The classification principle is actually a form of representation when an abstract principle is applied to an object description.

(5) Aggregation: Also known as Assembly, the principle is that a complex thing as a number of relatively simple assembly of things, thus simplifying the description of complex things.

(6) Association: It is the method of thinking that people often use when they think about a problem: associating it with something else. The reason that people can be associative is that there is indeed some connection between things.

(7) Message communication: This principle requires that objects communicate with each other only through messages, and not directly outside the object to access properties inside the object. Communication through messages is caused by the encapsulation principle. In OOA, a message connection is required to represent a dynamic relationship between objects.

(8) Granular control: In general, people in the face of a complex problem domain, can not be at the same time to look at the overall situation, but also insight autumn hair. Therefore, it is necessary to control its own field of view: When considering the overall situation, pay attention to its large components, temporarily unknown to each part of the specific details, consider a part of the details of the rest of the temporary aside. This is the principle of granularity control.

(9) Behavioral analysis: The behavior of things in the real world is complex. The various behaviors in the problem domain consist of a large number of things, which are often interdependent and interwoven with each other.

Two, object-oriented analysis to produce three kinds of analysis model

1. Object Model: Analyze the use case model, decompose the system into collaborative analysis class, describe the relationship between object/object by class Diagram/object graph, is the static model of the system.

2, dynamic Model: Describe the dynamic behavior of the system, through the time series diagram/collaboration diagram to describe the interaction of objects, to reveal how objects collaborate to complete each specific use case, the individual object state change/dynamic behavior can be expressed through the state diagram

3. function model (i.e., use case model à as input).

Third, the main advantages of OOA

(1) Improved understanding of the problem domain and system responsibilities;

(2) Improve the communication between the various types of personnel involved in the analysis;

(3) have a strong adaptability to the change of demand;

(4) Support for software reuse.

(5) Consistent throughout the whole process of software life cycle.

(6) Practicality;

(7) Facilitate user participation.

Iv. Basic steps of the Ooa method

When using OOA to specifically analyze a thing, the following five basic steps are generally followed:

The first step is to determine the objects and classes. The object here is an abstraction of the data and how it is handled, reflecting the ability of the system to preserve and process information about certain things in the real world. A class is a description of a common set of properties and methods for multiple objects, including a description of how to create a new object in a class.

The second step is to determine the structure (structure). Structure refers to the complexity of the problem domain and the connection relationship. The class member structure reflects the generalization-specialization relationship, and the whole-part structure reflects the relationship between the whole and the local.

The third step is to determine the subject (subject). The topic refers to the general picture of things and the overall analysis model.

Fourth step, determine the attribute (attribute). A property is a data element that can be used to describe an instance of an object or classification structure, given in the diagram, and specified in the object's storage.

The fifth step is to determine the method. Methods are some of the processing methods that must be made after a message is received: The method is defined in the diagram and specified in the object's storage. For each object and structure, the ones used to add, modify, delete, and select a method are inherently implicit (although they are defined in the object's storage, but not on the diagram), while others are displayed.

Ood

The object-oriented design (object-oriented Design,ood) method is an intermediate transition in the Oo method. Its main role is to further standardize the results of OOA analysis so that it can be directly accepted by OOP.

Object-oriented design (OOD) is a kind of software design method and an engineering norm. There is no doubt about it. According to Bjarne Stroustrup, the object-oriented programming paradigm (Paradigm) is [Stroustrup, 97]:

L decide the class you want;

L provide a complete set of operations for each class;

L explicitly use inheritance to express common ground.

By this definition, we can see that Ood is "deciding on the requirements of the class, the operation of the class, and the process associated with the class."

The goal of Ood is to manage the interdependence of parts within the program. In order to achieve this goal, Ood requires that the program be partitioned into chunks, each of which should be small to manageable, and then hide each block behind the interface (interface), allowing them to communicate with each other only through interfaces. For example, if you use Ood method to design a server-client (client-server) application, then the server and the client should not have a direct dependency, but should make the interface of the server and the interface of the client depend on each other.

The transformation of this dependency makes the parts of the system reusable. In the example above, the client does not have to rely on a particular server, so it can be reused in other environments. If you want to reuse a block, just implement the necessary interface.

Ood is a design paradigm for solving software problems (paradigm), an abstract paradigm. Using the design paradigm of ood, we can use objects (object) to represent the entities of the problem domain (problem domain), each with corresponding states and behaviors. We have just said that Ood is an abstract paradigm. Abstractions can be divided into layers, from very generalized to very special, and objects may be at any level of abstraction. In addition, objects that are different but interrelated can form an abstraction: As long as there is similarity between these objects, they can be treated as objects of the same class.

First, Ood background knowledge

Computer hardware technology is developing rapidly. From a mysterious behemoth decades ago to a mobile chip that is now portable, from thousands of operations per second to times operations per second. When software developers are still looking for a "silver bullet" [Brooks, 95] that can improve the productivity of software development, the productivity of hardware development has already been raised hundreds of thousands of times.

Hardware engineers can be so efficient because they are lazy. They always adhere to the "Don't reinvent the wheel" adage. Grady Booch called these black boxes a class category, and now we often call them "components (component)".

A genus is made up of entities called classes (class) that are combined between classes and classes by association (relationship). A class can hide a large amount of detail, exposing only a simple interface, which is just in line with the psychology of people's liking for abstraction. So, this is a very great concept, because it gives us the basics of encapsulation and reuse, so that we can look at the problem from the point of view of the problem, not from the perspective of the machine.

The reuse of software begins with the library and the class library, both of which are in fact white-box multiplexing. By the 90 's, people began to develop and sell real black box software modules: Framework (framework) and controls (control). Frameworks and controls are often limited by platform and language, and now the new trend of software technology is to use soap as a web Service for transmission media, which can make software modules out of the constraints of platform and language, and achieve a higher degree of reuse. But think about it, the Web service is also object-oriented, but the association between classes and classes is described in XML [Li, 02].

In the past more than 10 years, object-oriented technology has played a great role in the software industry. In the foreseeable future, it will still be the main technology of software design-at least I can't see what technology can replace it.

Second, where did Ood come from?

A lot of people think that Ood is an extension of the structured design (structured DESIGN,SD), which is actually wrong. Ood's software design concept is completely different from SD. SD focuses on the process of data structure and data processing. In Ood, processes and data structures are hidden by objects, and they are almost unrelated. However, Ood and SD have a very deep origin.

Around 1967, the concepts of Ood and SD were almost at the same time, and they presented data structures and algorithms in different ways. At that time, around the two concepts, many scientists wrote a large number of papers. Among them, some of the papers written by Dijkstra and Hoare on the topic of "proper program control structure", claiming that the goto statement is harmful and that the three controlling structures, sequential, cyclic and branching, should be used to form the entire program flow. These conceptual developments constitute a structured programming approach, while other papers written by Ole-johan Dahl mainly discuss unit division in programming languages, one of which is the class, which already has the main features of object-oriented programming.

These two concepts were immediately parted. The history of the structure is familiar to everyone: the NATO conference adopted Dijkstra's ideas, and the entire software industry agreed that the Goto statement was indeed harmful, and that the structured approach, the waterfall model, began in the 70 's. At the same time, countless scientists and software engineers have helped to develop a structured approach, many of which are today enough to make our amazing publication names, such as Constantine, Yourdon, DeMarco and Dijkstra. For a long time, the whole world believed that a structured approach was the "silver bullet" that saved the software industry. Of course, time finally proves everything.

At this point, object-oriented research and education in the field of slow development. Structured programming can be applied to almost any programming language, while object-oriented programming requires language support [1], which also hinders the development of object-oriented technology. In fact, in the late 60, the language that supported object-oriented features was only Simula-67. By the 70 's, Alan key, of the Xerox PARC Research Center (PARC), had invented another language based on the object-oriented approach, the famous Smalltalk. However, Smalltalk and several other object-oriented languages remained in the lab until the middle of the 80 's.

By the 90 's, Ood suddenly swept the entire software industry, which is absolutely a revolution in the history of software development. However, ascend to the telescope, new things always stand on the basis of the old things. The design methods of the 70 's and 80 's have revealed many valuable concepts, and neither can nor dare ignore them, ood.

Iii. What is the difference between ood and traditional methods?

Do you remember the structured design method? The program is divided into many modules, which are organized into a tree-like structure. The root of this tree is the main module, the leaf is the tool module and the lowest level function module. At the same time, this tree also represents the invocation structure: Each module calls its own direct sub-module and is called by its own direct ancestor module.

So, which module is responsible for collecting the most important policies of the application? Of course it's the top ones. At the bottom of those modules to achieve the smallest detail, the top module cares about the biggest problem. Therefore, the higher the level of abstraction in this architecture, the higher the abstract hierarchy of the concept, the closer the problem domain is, and the lower the position of the architecture, the closer the concept to the details, the less the relationship with the problem domain, and the more relationships with the solution domain.

However, because the modules above need to call the modules below, the above modules depend on the details below. In other words, the abstraction associated with the problem domain relies on details unrelated to the problem domain! This means that when the implementation details change, the abstraction is also affected. And, if we want to reuse an abstraction, we have to drag the details that it relies on.

In Ood, we want to reverse this dependency: The abstraction we create doesn't depend on any detail, and the detail is highly dependent on the abstraction above. The reversal of this dependency is the fundamental difference between ood and traditional technology, and it is the essence of Ood thought.

Iv. Steps of Ood

Refine the Reorganization class

Refine and implement inter-class relationships to clarify their visibility

Add property, specify the type and visibility of the property

Assign responsibilities, define how each responsibility is performed

For message-driven systems, clear message delivery methods

Partial Design using design pattern

Draw a detailed class diagram and a sequence diagram

V. Major work to be carried out during the design of Ood

(i) The refinement process of the object definition specification

For Ooa abstract object-&-class and the collection of analytical documents, Ood need to have a design according to the requirements of the process and refinement, so that it can be more consistent with the needs of OOP. This finishing and refinement process has two main aspects: first, according to the concept of object-oriented

The model organizes and analyzes the object structure, properties, methods and so on, corrects the wrong contents, and deletes unnecessary and repetitive contents. The second is to classify, so that the next step of database design and program processing module design needs. The main method of collation is to

class, which classifies the class one and the objects, properties, methods, and structures, and topics.

(ii) Data model and database design

The design of the data model needs to determine the content of the class-&-object properties, how the message is connected, the system access, the method of the data model, and so on. Finally, the data for each object instance must be implemented into the object-oriented library structure model.

(iii) Optimization

The optimal design process of ood is to summarize the analysis results and process business processes from another angle, and optimize the optimization, abstraction and integration of objects and structures.

The modular representation of objects and structures Ood provides a paradigm that supports modularity of classes and structures. This module conforms to all the characteristics required by the general modularization, such as good concealment of information, strong internal polymerization degree and weak coupling degree between modules.

Integration allows a single component to be organically combined to support each other.

Vi. characteristics and problems faced by OO methods

Based on the object, the Oo method uses specific software tools to directly accomplish the transformation from object description to software structure. This is the most important feature and achievement of the OO approach. The application of Oo method solves the objective World Description tool in traditional structured development method and the soft

The inconsistency of the structure, shortens the development cycle, solves the complicated process of multiple conversion mapping from analysis and design to software module structure, and is a very promising system development method.

However, as with the prototype method, the Oo method needs certain Software foundation support can be applied, in addition, in large-scale mis development, if not by the top-down overall division, but at the beginning of the use of the bottom-up of the OO method of development system, the same will cause the system structure is unreasonable, the relationship between the parts of the problem. Therefore, OO methods and structured methods are still two interdependent and irreplaceable methods in the field of system development.

Seven, what can Ood bring to me?

People who ask this question are usually thinking, "Ood can solve all the design problems?" "No silver bullets." Ood is not about solving all design problems, avoiding software crises, defending world peace ... of silver bullets. Ood is just a technique. However, it is an excellent technology that solves most of the current software design problems-and, of course, requires the designer to be able to do so.

Ood may give you a headache, because it is difficult to learn it, to master it, and Ood even to disappoint you because it is immature and imperfect. Ood will also bring you joy, it allows you to focus on the design without worrying about the details, and Ood will make you a better designer, providing you with a great tool to develop stronger, more maintainable, and more reusable software.

Oop

Object-oriented programming (object Oriented Programming,oop, OO programming) is a computer programming architecture. One of the basic tenets of OOP is that a computer program is composed of a single unit or object that can act as a subroutine. OOP achieves the three main goals of software engineering: reusability, flexibility, and extensibility. To achieve the overall operation, each object can receive information, process data, and send information to other objects. OOP mainly has the following concepts and components:

Components-data and functions in a running computer program formed in a unit, the component in the OOP computer program is a modular and structured basis.

Abstraction-The program has the ability to ignore certain aspects of the information being processed, namely the ability to focus on the main aspects of the information.

Encapsulation-also known as information encapsulation: Ensure that components do not change the internal state of other components in an unpredictable way, and that only those components that provide an internal state change method can access their internal state. Each type of component provides an interface that is associated with other components and specifies the method by which other components are called.

Polymorphism-component references and class sets involve many other components of different types, and the result of referencing a component depends on the type of actual invocation.

Inheritance-Allows child class components to be created on the basis of existing components, which unifies and enhances polymorphism and encapsulation. Typically, a class is used to group components, and it is possible to define a new class as an extension of an existing class, so that the class can be organized into a tree or mesh structure, which embodies the versatility of the action.

Component-based programming has become particularly popular in scripting languages due to the reasons for abstraction, encapsulation, reusability, and ease of use. Python and Ruby are recent languages that have been developed with the idea of OOP, and the popular Perl scripting language has slowly joined new object-oriented functional components starting with version 5. The use of components instead of "real" entities becomes a popular reason for JavaScript (ECMAScript), and there are arguments that the appropriate combination of components can replace the HTML and XML Document Object Model (DOM) on the Internet.

Design patterns, techniques, and intuition pose a daunting challenge. This must be recognized before choosing a programming language, although the design features of different languages may promote or hinder this transformation.

An important part of the growth in network applications is the explosive growth of small mobile devices and special internet devices. Each of these devices has its own operating system, or a common operating system in a particular device domain. We can now also list these devices-home access devices, cellular phones, electronic newspapers, PDAs, automatic network equipment and so on. But the number and depth of these equipment areas will quickly become incalculable. We all know that this market is surprisingly big, the rise of PC is a piece of cake compared with it. So in the application market for these devices, competition will be pretty brutal. One of the important means of winning is to enter the market as soon as possible. Developers need great tools to write and debug their software quickly and efficiently. Platform independence is one of the keys to winning, allowing programmers to develop software that supports a variety of device platforms.

Another change I expected is that our ability to develop code (JAVA) and data (XML)-based collaborative applications will continue to improve. This synergy is one of the core goals of developing powerful applications. We have seen this trend in the evolution of XML's rapid popularity and ebXML specifications. ebXML is an open XML-based infrastructure for e-commerce and international trade, developed jointly by the United Nations Centre for Trade Facilitation and e-commerce (un/cefact) and the Structural Information Standards Promotion Organization (OASIS).

Can we expect a true component-oriented (component-oriented) language? Who will be the creator of it?

Stroustrup: I suspect that the lack of results in this field is precisely because people--mostly non-programmers--have too much hope for the vague meaning of "components". These people dream that one day the component will somehow drive the programmer out of the historical stage. In the future, the competent "designers" simply use pre-adjusted components, drag and drop the mouse and put the system together. For software tool makers, the idea has another layer of meaning, and they believe that only then will they retain the necessary technology to be able to write such a component.

This idea has one of the most fundamental fallacies: it's hard to get a wide welcome. A single component or framework (framework) that satisfies most of the requirements of an application or industry is a cost-effective product for its maker, and it is not technically difficult. But a few competitors in the industry will soon find that if all of these components are used, then the products between them will become world-wide, no difference, they will be reduced to simple clerks, the main profits will be drilled into those components/framework suppliers in the pocket!

Small "components" are useful, but do not produce the desired leverage effect. Medium-sized, more general-purpose components are useful, but they require extraordinary elasticity when constructed.

In C + +,

In Java, what is OOA? What is Ood? What is OOP?