OOA/ood/OOP

1. OOA (object-oriented analysis): Object-Oriented Analysis Method

OOA refers to the analysis of problems based on the object-oriented thinking after the system business investigation is conducted during system development. There is a big difference between OOA and structured analysis. OOA emphasizes the classification analysis and arrangement of materials required by the OO method based on the system survey data, rather than the analysis of the management business status and methods.

The OOA (Object-Oriented Analysis) model consists of five layers (topic layer, object class layer, structural layer, attribute layer, and service layer) and five activities (identification object class, identification structure, definition topic, definition attribute, and definition service. This method defines the structure between two object classes. One is called a classification structure and the other is called an assembly structure. The classification structure is the so-called general and special relationship. The assembly structure reflects the relationship between objects and parts.

When defining attributes, OOA must identify instance connections. Instance connection is the ing between an instance and another instance.

OOA must identify message connections while defining services. When an object needs to send messages to another object, there is a message connection between them.

The five layers and five activities in OOA continue throughout the OOD (painting Object Design) process. The Ood model consists of four parts. They are the design question domain part, the design man-machine interaction part, the design task management part, and the design data management part.

I. Main Principles of OOA.

(1) Abstraction: dropping individual and non-essential features from many things and extracting common and essential features is called abstraction. Abstraction is an essential means to form concepts.

Abstract principles have two meanings: first, although things in the problem domain are complex, analysts do not need to understand and describe everything about them, you only need to analyze and study the things related to the system goals and their essential features. Second, abstract concepts of a batch of things are obtained by extracting the common features of individual things from their differences in details.

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

Process abstraction refers to a sequence of operations that complete a specific function. Users can regard it as a single entity, although it may actually be completed by a series of lower-level operations.

Data abstraction defines data types based on operations applied to data, and limits data values to be modified and observed only by these operations. Data abstraction is the core principle of OOA. It combines data (attributes) and Operations (services) into an inseparable System Unit (that is, an object). You only need to know what the object is doing, you don't have to know how to do it.

(2) encapsulation is to combine object attributes and services into an inseparable System Unit and conceal the internal details of objects as much as possible.

(3) Inheritance: All attributes and Services of general classes owned by objects of special classes are called inheritance of general classes by special classes.

In OOA, the principle of inheritance is applied to every general-special structure formed by general classes and special classes, the attributes and services shared by the object instances of the general class and the object instances of all special classes are explicitly defined in the general class at one time. In special classes, the defined items in general classes are no longer repeatedly defined, but in semantics, A special class automatically and implicitly owns all the attributes and services defined in its general class (and all upper-level general classes. The advantage of the inheritance principle is that the system model is concise and clear.

(4) classification: divides objects with the same attributes and services into one class, and uses classes as abstract descriptions of these objects. The classification principle is actually a manifestation of the abstract principle applied to object description.

(5) aggregation: it is also called Assembly. Its principle is to regard a complex thing as an assembly body of some simple things, so as to simplify the description of complex things.

(6) Association: It is the thought method that humans often use when thinking about problems: think of another thing through one thing. The reason for association is that there are some relationships between things.

(7) Message Communication: This principle requires objects to communicate only through messages, rather than directly accessing the internal properties of objects outside the objects. Message-based communication is caused by encapsulation principles. In OOA, a message connection is required to indicate the dynamic relationship between objects.

(8) Granularity Control: Generally, when faced with a complex problem domain, it is impossible for a person to view the whole situation at the same time, and to take a long time. Therefore, you need to control your own field of view: Pay attention to its major components when considering the global situation, and do not take details of each part for the time being; when considering the details of a part, the rest of the part is temporarily removed. This is the granularity control principle.

(9) behavior analysis: the behavior of things in the real world is complex. Various behaviors in the problem domain composed of a large number of things are often mutually dependent and intertwined.

2. object-oriented analysis generates three analysis models

1. Object Model: analyze the use case model, break down the system into collaborative analysis classes, and describe the relationship between properties and objects of objects through class charts/object graphs, is the static model of the system.

2. Dynamic Model: describes the dynamic behavior of the system, and describes the interaction of objects through a time sequence diagram/collaboration diagram to reveal how objects collaborate to complete each specific use case, the status change/dynamic behavior of a single object can be expressed through a state chart.

3. Function Model (Use Case model ).

3. Main advantages of OOA

(1) enhanced understanding of problem domains and system responsibilities;

(2) improve communication between various personnel involved in analysis;

(3) strong adaptability to changes in demand;

(4) software reuse is supported.

(5) consistency throughout the entire software lifecycle.

(6) practicality;

(7) conducive to user participation.

Iv. basic steps of OOA Method

When using OOA to analyze a thing, follow the following five basic steps:

Step 1: Determine the object and class. The object mentioned here is the abstraction of data and its processing methods. It reflects the ability of the system to store and process information of certain things in the real world. A class is a description of the common attributes and methods of multiple objects. It includes the description of how to create a new object in a class.

Step 2: determine the structure ). Structure refers to the complexity and connection relationship of the problem domain. The class member structure reflects the general-special relationship, and the overall-part structure reflects the relationship between the whole and the local.

Step 3: determine the subject ). Topic refers to the overall overview and overall analysis model of things.

Step 4: Determine attributes ). An attribute is a data element. It can be used to describe an object or an instance of a classification structure. It can be shown in the figure and specified in the object storage.

Step 5: determine the method ). The method is some of the processing methods that must be performed after the message is received: The method must be defined in the graph and specified in the object storage. For each object and structure, the methods used to add, modify, delete, and select a method are inherently implicit (although they need to be defined in the object storage, but not shown in the figure), while some are displayed.

2. object-oriented design (OOD) Object-oriented Design

The OOD method is an intermediate Transitional Link in the OO method. Its main function is to further standardize the OOA analysis results so that they can be directly accepted by OOP.

Object-Oriented Design (OOD) is a software design method and an engineering specification. There is no doubt. According to Bjarne stroustrup, the Object-Oriented Programming Paradigm (paradigm) is [stroustrup, 97]:

L decide the class you want;

L provides a complete set of operations for each class;

L explicitly use inheritance to express commonalities.

From this definition, we can see that Ood is "determining the operation of the required classes and classes as needed and the process of association between classes ".

The goal of OOD is to manage the interdependence of various components within the program. To achieve this goal, Ood requires that the program be divided into blocks. The size of each block should be smaller than the manageable level, and then each block is hidden behind the interface, allow them to communicate with each other only through interfaces. For example, if you use Ood to design a server-client (client-server) application, there should be no direct dependency between the server and the client, instead, the server interface and the client interface should be mutually dependent.

This dependency conversion makes all parts of the system reusable. In the above example, the client does not have to rely on a specific server, so it can be reused in other environments. To reuse a program block, you only need to implement the required interface.

Ood is an abstract design paradigm that solves software problems. With the Ood design paradigm, we can use objects to express the objects of the problem domain. Each object has a corresponding state and behavior. We just mentioned that Ood is an abstract paradigm. Abstract can be divided into many levels, from very general to very special, and objects may be at any abstraction level. In addition, different but correlated objects can form an Abstract: As long as these objects have similarities, they can be processed as the same class objects.

1. background knowledge of OOD

Computer hardware technology is developing rapidly. From the mysterious giant thing decades ago to the mobile chip that we carry with us today, from thousands of operations per second to tens of billions of operations per second. When software developers are still looking for "Silver Bullet" [Brooks, 95] that can increase the productivity of software development by an order of magnitude, the productivity of hardware development has already increased by times.

Hardware engineers are so efficient that they are very lazy. They always stick to the old saying "don't re-invent the wheel. Grady booch calls these black boxes class category. Now we usually call them "components )".

A class is composed of entities called classes. Classes and classes are combined by relationship. A class can hide a large number of details and only expose a simple interface, which is in line with the abstract psychology. Therefore, this is a very great concept, because it provides us with the basis for encapsulation and reuse, so that we can look at the problem from the perspective of the problem, rather than from the perspective of the machine.

Software reuse started with function libraries and class libraries. The two reuse forms are actually white box reuse. By 1990s, some people began to develop and sell real Black Box software modules: Frameworks and controls ). Frameworks and controls are often restricted by platforms and languages. Currently, the new trend of software technology is the Web service that uses soap as the transmission medium. It can free software modules from the constraints of platforms and languages, to achieve a higher degree of reuse. But think about it. In fact, Web Service is also object-oriented, but it only describes the association between classes in XML [Li, 02].

Over the past decade, object-oriented technology has played a significant role in promoting the software industry. In the foreseeable future, it will still be the main technology of software design-at least I don't see any technology that can replace it.

2. Where did Ood come from?

Many people think that Ood is an extension of structured design (SD. Ood's software design concept is totally different from SD. SD focuses on the data structure and the process of processing the data structure. In Ood, the process and data structure are hidden by objects, and the two are almost unrelated. However, to trace the root cause, OOD and SD have deep roots.

Before and after 1967, the concepts of OOD and SD were born almost simultaneously. They expressed data structures and algorithms in different ways. At that time, many scientists wrote a lot of papers around these two concepts. Among them, some papers written by Dijkstra and Hoare talked about the topic of "proper program control structure", claiming that the GOTO statement is harmful, the whole program process should be constructed using three control structures: sequence, loop, and branch. These concepts constitute a structured programming method, while some papers written by Ole-Johan Dahl mainly discuss unit division in programming languages, one of which is class, it already has the main features of object-oriented programming.

The two concepts were immediately separated. Everyone on the structural side is familiar with the history: the NATO conference adopted Dijkstra's idea, and the entire software industry agreed that the GOTO statement is indeed harmful, structured methods and waterfall models have become popular since 1970s. At the same time, countless scientists and software engineers have also helped to develop and improve structured methods, many of which today are enough to give us names, such as Constantine, Yourdon, DeMarco, and Dijkstra. For a long time, the whole world believed that the structured method was the silver bullet that saved the software industry ". Of course, time proves everything.

At this time, object-oriented development is slow in the field of research and education. 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 1960s s, only the Simula-67 language that supports object-oriented features. By 1970s, Alan key and others at the Xerox paraloalto Research Center (PARC) invented another language based on object-oriented methods, the famous smalltalk. However, until the middle of 1980s, smalltalk and several other object-oriented languages remained in the lab.

By 1990s, Ood suddenly swept the whole software industry, which is definitely a revolution in the software development history. However, new things always stand on the basis of old things. The design methods in 1970s and 1980s reveal many valuable concepts that no one can ignore.

3. What is the difference between OOD and traditional methods?

Do you still remember the structured design method? Programs are divided into multiple modules, which are organized into a tree structure. The root of the tree is the main module, and the leaf is the tool module and the lowest functional module. At the same time, this tree also indicates the call structure: Each module calls its own direct subordinate module and is called by its own direct superior module.

Which module is responsible for collecting the most important policies of the application? Of course, they are the top ones. The bottom modules only implement the smallest details, and the top modules focus on the largest problems. Therefore, in this architecture, the higher the abstract level of the concept, the closer it is to the problem field. In the architecture, the lower the position, the closer the concept to details, the less the relationship with the problem field, the more the relationship with the solution field.

However, because the modules above need to call the modules below, the modules above depend on the details below. In other words, the abstraction related to the problem field depends on the details irrelevant to the problem field! This means that the abstraction will also be affected when the implementation details change. In addition, if we want to reuse an abstraction, We must drag the details on which it depends together.

In Ood, we want to reverse this dependency: The abstraction we create does not depend on any details, and the details are highly dependent on the abstraction above. The reversal of this dependency is the fundamental difference between OOD and traditional technologies, and the essence of Ood's thoughts.

4. Steps of OOD

Refined restructuring

Refine and implement inter-class relationships to clarify their visibility

Adds an attribute to specify its type and visibility.

Assign responsibilities and define how to execute each responsibility

Specify the message transmission mode for the message-driven system

Use design patterns for local design

Draw a detailed class diagram and sequence diagram

5. Main work to be carried out in the Ood Design Process

(1) Refinement of object definition specifications

For the object-&-class abstracted by OOA and the collection of analysis documents, Ood needs to have a process of arrangement and refinement according to the design requirements to better meet the needs of OOP. There are two main aspects in this process: first, we need to follow the object-oriented concept.

The model organizes and analyzes the determined object structure, attributes, methods, and other content, correct the wrong content, and delete unnecessary and repeated content. The second is to sort the data in order to facilitate the Needs of the database design and program processing module design in the next step. The sorting method is mainly for returning

Class: Class 1 and 1 objects, attributes, methods, structures, and topics are classified.

(2) Data Model and database design

To design a data model, you must determine the content of the Class-&-object attribute, the method of message connection, system access, and data model. Finally, the data of each object instance must be implemented in the object-oriented database structure model.

(3) Optimization

The Optimization Design Process of OOD is to organize and summarize the analysis results and processing business processes from another perspective, including optimization, abstraction, and integration of objects and structures.

The modularity of objects and structures represents a paradigm that supports modularity of classes and structures. This type of module meets all the features required by General modularization, such as good information concealment, strong internal polymerization degree and Weak Coupling Degree between modules.

Integration enables the combination of individual components to support each other.

Vi. features and problems of the OO Method

The OO method is based on objects and uses specific software tools to directly convert the description of objects to the software structure. This is the main feature and achievement of the OO method. The application of the OO method solves the inconsistency between the descriptive tool and the software structure in the objective world in the traditional structured development method, shortening the development cycle, it solves the complicated process from analysis and design to multiple conversion ing between software module structures, and is a promising system development method.

However, like the prototype method, the OO method can be applied only after some basic software support is required. In the case of large MIS development, instead, we used the OO method to develop the system from the beginning, which also caused problems such as unreasonable system structure and imbalance between various parts. Therefore, the OO and structured methods are still mutually dependent and irreplaceable in the field of system development.

7. What can Ood bring to me?

The person who asked this question is usually thinking, "Can Ood solve all design problems ?" No silver bullet. Good is not about solving all design problems, avoiding software crises, defending world peace ...... Silver bullet. Ood is just a technology. However, it is an excellent technology that can well solve most of the current software design problems-of course, this requires the designers to have sufficient capabilities.

Ood may be a headache for you, because it is very difficult to learn and master it. OOD may even disappoint you because it is not mature or perfect. Ood will also bring you joy, it allows you to focus on design, without worrying about those details; Ood will also make you a better designer, it can provide you with good tools, this allows you to develop more robust, maintained, and reusable software.

3. Object-Oriented Programming (OOP)

Oop is a computer programming architecture. One basic principle of OOP is that a computer program is composed of a single unit or object that can act as a subroutine. Oop has achieved three main objectives of Software Engineering: reusability, flexibility, and scalability. To achieve the overall operation, each object can receive, process, and send information to other objects. Oop has the following concepts and components:

Component-a unit formed by data and functions in a running computer program. components are the basis of modules and structures in OOP computer programs.

Abstraction-the Program has the ability to ignore some aspects of the information being processed, that is, the ability to focus on the main aspects of information.

Encapsulation-it is also called Information encapsulation: to ensure that the component does not change the internal status of other components in an unpredictable way; only in those components that provide the internal state change method, to access its internal status. Each type of component provides an interface for contacting other components and specifies the method for calling other components.

Polymorphism-the reference and class assembly of components involve many other different types of components, and the result of referencing components must be based on the actual call type.

Inheritance-allows sub-components to be created based on existing components, which unifies and enhances polymorphism and encapsulation. Typically, classes are used to group components, and new classes can be defined as extensions of existing classes, so that classes can be organized into a tree or mesh structure, this reflects the versatility of the action.

Because of abstraction, encapsulation, reusability, and ease of use, component-based programming has become particularly popular in scripting languages. Python and Ruby are recent languages that fully adopt the idea of OOP during development, the popular perl scripting language has gradually added new object-oriented functional components since version 5. Replacing "reality" entities with components has become the reason why JavaScript (ecmascript) becomes popular, it has been demonstrated that appropriate combinations of components can replace the HTML and XML Document Object Model (DOM) on the English site ).

Design Patterns, techniques, and intuition pose severe challenges. This must be recognized before you select a programming language, although the design features of different languages may promote or impede 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 only has a common operating system in a specific device field. We can also list these devices, including home access devices, cellular phones, electronic newspapers, PDAs, and automatic network devices. However, the quantity and depth of these device fields will soon become incalculable. We all know that the market is amazing, and the rise of PC is nothing more than a piece of cake. Therefore, the competition in the application market for these devices will be quite cruel. One of the important means to win is to enter the market as soon as possible. Developers need excellent tools to quickly and efficiently write and debug their software. Platform independence is also one of the secrets to success. It enables programmers to develop software that supports multiple device platforms.

Another change I expected is that our development capabilities for code (Java) and data (XML) collaborative applications will continue to improve. This collaboration is one of the core goals of developing powerful applications. We have seen this trend from the rapid prevalence of XML and the Development of ebXML specifications. EbXML is an open XML-based infrastructure for e-commerce and international trade. It is organized by the United Nations Trade Promotion and E-Commerce centre (UN/CEFACT) and structural information standard promotion organization (OASIS) develop together.

Can we expect a true component-oriented language? Who will it be created?

Stroustrup: I suspect that this field lacks results because people-primarily non-programmers-have placed too many expectations on the vague words "components. These people dream that one day, components will drive programmers out of the stage of history in some way. In the future, the competent "designers" only need to use the pre-adjusted components to drag and drop the mouse, and then combine the system. For software tool vendors, this idea has another significance. They believe that only they can retain the necessary technology and be able to write such components.

This idea has one of the most basic mistakes: this component is hard to be widely welcomed. A separate component or framework is a cost-effective product for the manufacturer if it can meet most of the requirements put forward by an application or industry, it is not technically difficult. However, several competitors in the industry will soon find that if everyone uses these components, the products between them will become the same and there is no difference, they will become simple clerks, and their major profits will all go into the pockets of those component/framework suppliers!

Small "components" are very useful, but cannot produce the expected leverage effect. Medium-sized and more general components are very useful, but they require extraordinary elasticity during construction.

In C ++,