Software model. Object Model: why is it needed and how to describe it

Now we have everything necessary concepts to describe the process of building an object model. This process includes the following steps:

· definition of objects and classes;

· preparation of a data dictionary;

· determination of dependencies between objects;

· determination of object attributes and connections;

· organization and simplification of classes when using inheritance;

· further research and improvement of the model.

2.2.1. Definition of classes. Analysis external requirements to the designed PS allows you to define objects and classes of objects associated with the applied problem that this system must solve. All classes must be meaningful in the application domain in question; classes associated with computer implementation, such as list, stack, etc. should not be administered at this stage.

You need to start by identifying possible classes from the written statement applied problem (terms of reference and other documentation provided by the customer). It should be borne in mind that this is a very difficult and responsible stage of development, since the future fate of the project largely depends on it.

When identifying possible classes, you should try to identify as many classes as possible, writing down the name of each class that comes to mind. In particular, each noun appearing in the preliminary statement of the problem can have a corresponding class. Therefore, when identifying possible classes, each such noun is usually associated with a possible class.

· redundant classes: if two or more classes express the same information, only one of them should be retained;

· irrelevant(not directly related to the problem) classes: For each possible class name, it is evaluated how necessary it is in future system(this is often very difficult to assess); irrelevant classes are excluded;

· ill-defined(from the problem point of view) classes(see clause 2.3.1);

· attributes: some nouns correspond more to attributes than to classes; such nouns, as a rule, describe the properties of objects (for example, name, age, weight, address, etc.);

· operations: some nouns correspond more to operation names than to classes (for example, telephone_call is unlikely to denote any class);

· roles: Some nouns define the names of roles in the object model (for example, owner, driver, boss, employee; all of these names are associated with roles in various object dependencies of the person class);

· implementation structures: Names more related to programming and computer hardware should not be on at this stage compare classes, since they do not reflect the features of the designed substation; examples of such names: subroutine, process, algorithm, interrupt, etc.

After eliminating the names of all unnecessary (superfluous) possible classes, a preliminary list of classes that make up the designed system will be obtained.

2.2.2. Preparing the data dictionary. Individual words have too many interpretations. Therefore, it is necessary to prepare at the very beginning of design data dictionary, containing clear and unambiguous definitions of all objects (classes), attributes, operations, roles and other entities considered in the project. Without such a dictionary, discussing the project with fellow developers and system customers is meaningless, since everyone can interpret the terms discussed in their own way. For an example of a dictionary, see paragraph 2.3.2.

2.2.3. Definition of dependencies. At the next stage of building an object model, dependencies between classes are determined. First of all, attributes that are explicit links to other classes are excluded from classes; such attributes are replaced by dependencies. The point of this replacement is that dependencies represent an abstraction at the same level as classes, and therefore do not have a direct impact on future implementation (a reference to a class is just one way to implement dependencies).

In the same way that the names of possible classes were obtained from the nouns found in the preliminary statement of the application problem, the names of possible dependencies can be obtained from verbs or verb phrases appearing in the specified document. This is how they usually describe: physical position (follows_behind, is_part, is_contained), directed action (leads_to_movement), communication (talks_to), belonging (has, is_part), etc. An example of isolating explicit and implicit verb phrases from a preliminary formulation of a specific applied problem is discussed in section 2.3.3.

You should then remove unnecessary or incorrect dependencies using the following criteria:

· dependencies between excluded classes must be excluded or reformulated in terms of the remaining classes (see clause 2.3.3);

· irrelevant dependencies and implementation dependencies must be excluded (see clause 2.3.3);

· actions: the dependency should describe the structural properties of the application domain, and not unimportant events (see clause 2.3.3);

· training dependencies: most of the dependencies between three or more classes can be decomposed into several binary dependencies, using qualifiers if necessary (see section 2.3.3); in some (rare) cases such decomposition cannot be carried out; for example, the trenary dependence “The professor is teaching a course in room 628” cannot be decomposed into binary ones without loss of information;

· derived dependencies: it is necessary to exclude dependencies that can be expressed through other dependencies, since they are redundant (see section 2.3.3); when excluding redundant (derived) dependencies, you need to be especially careful, since not all duplicating dependencies between classes are redundant; in some cases, other dependencies allow us to establish only the existence of another derived dependence, but do not allow us to establish the multiplicity of this dependence; for example, in the case shown in Fig. 2.36, the company has many employees and owns many computers; each employee is provided with personal use several computers, in addition there are computers common use; the dependency multiplicity provided_for_use cannot be inferred from the dependencies serves and owns; although derived dependencies do not add new information, they are often convenient; in these cases they can be indicated on the diagram by marking them with a slash.

Rice. 2.36. Non-redundant dependencies

Having removed redundant dependencies, you need to clarify the semantics of the remaining dependencies as follows:

· misnamed dependencies: they should be renamed so that their meaning becomes clear (see clause 2.3.3);

· role names: you need to add role names where necessary; the role name describes the role played by the corresponding class in a given dependency from the point of view of another class participating in that dependency; if the role name is clear from the class name, it can be omitted (see section 2.3.3);

· qualifiers: By adding qualifiers where necessary, we introduce elements of context, which allows us to achieve unambiguous identification of objects; qualifiers also make it possible to simplify some dependencies by reducing their multiplicity;

· multiplicity: it is necessary to add designations for the multiplicity of dependencies; It should be remembered that the multiplicity of dependencies may change in the process of further analysis of system requirements;

· unaccounted dependencies must be identified and added to the model.

2.2.4. Attribute clarification. At the next stage, the attribute system is clarified: class attributes are adjusted, new attributes are introduced, if necessary. Attributes express the properties of objects of the class in question, or determine their current state.

Attributes usually correspond to nouns; for example, car_color (object property), cursor_position (object state). Attributes, as a rule, have little effect on the structure of the object model.

You should not try to define as many attributes as possible: a large number of attributes complicates the model and makes it difficult to understand the problem. It is necessary to enter only those attributes that are relevant to the designed application system, omitting random, unimportant and derived attributes.

Along with object attributes, it is also necessary to enter attributes of dependencies between classes (relationships between objects).

When specifying attributes, they are guided by the following criteria:

· Replacing attributes with objects. If the presence of some entity is more important than its value, then it is an object; if the value is more important, then it is an attribute: for example, a boss is an object (it doesn’t matter who the boss is, the main thing is that someone is), salary is an attribute ( its significance is very significant); city is always an object, although in some cases it may seem that it is an attribute (for example, city as part of a company address); in cases where you want city to be an attribute, you should define a dependency (say, located) between the classes firm and city.

· Qualifiers. If the value of an attribute depends on a specific context, it should be made a qualifier (see section 2.3.4).

· Names. Names are usually better matched by qualifiers than by object attributes; in all cases when a name allows one to select from objects of a certain set, it should be made a qualifier (see section 2.3.4).

· Identifiers. Object identifiers are associated with their implementation. In the early stages of design they should not be considered as attributes.

· Link Attributes. If some property characterizes not the object itself, but its connection with another object (objects), then this is a connection attribute, not an object attribute.

· Internal values. Attributes that define only the internal state of an object, invisible outside the object, should be excluded from consideration.

· Unimportant details. It is recommended to omit attributes that do not affect the execution of most operations.

2.2.5. Organizing a class system using inheritance. Next, you need to try to find superclasses for the introduced classes. This is useful because it clarifies the structure of the model and makes subsequent implementation easier. The example is discussed in paragraph 2.3.5.

2.2.6. Further research and improvement of the model. Only in very rare cases does the constructed object model immediately turn out to be correct. The model must be researched and debugged. Some errors can be found when examining a model without a computer, others - when interpreting it together with dynamic and functional models on a computer (these models are built after the object model has already been built).

Here we will look at techniques for computer-free search and correction of errors in the object model. They are based on external signs that can be used to find errors in the model; these signs can be combined into the following groups.

Signs of a missing object (class):

· asymmetry of connections and generalizations (inheritance); to fix the error you need to add the missing classes;

· mismatch between attributes and operations of a class; to correct the error, it is necessary to split the class into several other classes, so that the attributes and operations of the new classes correspond to each other;

· an operation has been detected that does not have a satisfactory target class; To fix the error, you need to add the missing target class;

· several dependencies were found with same names and purpose; To fix the error, you need to generalize and add the missing superclass.

Signs of an unnecessary (superfluous) class:

· lack of attributes, operations and dependencies of a certain class; To correct the error, you need to consider whether such a class should be excluded.

Signs of missing dependencies:

· there are no access paths to operations; To fix the error, you need to add new dependencies that provide the ability to service the corresponding requests.

Signs of unnecessary (superfluous) dependencies:

· redundant information in dependencies; to correct the error, it is necessary to exclude dependencies that do not add new information, or mark them as derived dependencies;

· there are not enough operations crossing the dependency; To correct the error, you need to consider whether such a dependency should be excluded.

Signs of improper dependency placement:

· role names are too broad or too narrow for their classes; To fix the error, you must move the dependency up or down the class hierarchy.

Signs of incorrect attribute placement:

· there is no need to access an object by the values of one of its attributes; To fix the error, you need to consider whether you need to introduce a qualified dependency.

Examples practical application For the described symptoms, see paragraph 2.3.6.

Example object model

Let's consider the process of building an object model for the system banking services during the requirements analysis and preliminary design of this system. To build an object model of the system under consideration, we need to complete all the steps listed in paragraph 2.2.

2.3.1. Definition of objects and classes. In clause 1.3, the task is formulated and a diagram of the banking service network is shown (Fig. 1.3). By analyzing this statement of the problem, it is possible to identify possible classes by matching them with the nouns mentioned in its preliminary formulation; you will get the following list of possible class names (in alphabetical order):

We examine this list, excluding class names from it in accordance with the recommendations of paragraph 2.2.1:

· redundant classes: It is clear that client and user mean the same concept; for the banking system it is more natural to leave the client class;

· irrelevant classes: such a class is the price class (it is not directly related to the operation of the banking network);

· ill-defined classes: such classes are record_keeping_service and security check (these services are part of the posting), system (in our case it is not clear what this is), banking_network (the entire PS will serve the banking network);

· attributes: transaction data, account data, money (meaning real money given to the client by a cashier or ATM, or accepted by the cashier), receipt (issued to the client along with the money) is more natural to have as attributes;

· implementation structures express names such as software_and access; they should also be excluded from the list of possible class names.

After eliminating all unnecessary names of possible classes, we obtain the following list of classes that make up the designed banking system (these classes are presented in Fig. 2.5):

2.3.2. Preparing the data dictionary. Here is a part of the data dictionary containing definitions of the classes used in the project.

ATM (ATM) is a terminal that allows the client to make his own transactions using his card for identification. ATM (ATM) interacts with the customer to receive necessary information for posting, sends posting information to the central_computer so that it checks it and subsequently uses it when performing posting and issues money and a receipt to the client. It is assumed that the ATM (automated teller machine) does not need to operate independently of the network.

A bank is a financial organization that holds accounts for its customers and issues cards authorizing access to accounts through an ATM (automated teller machine) network.

Card - a plastic card issued by a bank to its client, which authorizes access to accounts through the ATM (ATM) network. Each card contains a bank code and card number, encoded in accordance with national standards for bank cards. The bank_code uniquely identifies the bank within the consortium. The card_number determines the accounts to which the card has access. The card does not necessarily provide access to all customer accounts. Each card can only be owned by one customer, but multiple copies may exist, so consideration should be given to the possibility of using the same card from different ATMs (automated teller machines) at the same time.

A cashier is a bank employee who has the right to make transactions from cash terminals, as well as accept and issue money and checks to customers. Transactions, money and checks that each cashier works with must be recorded and correctly accounted for.

Cash_terminal - the terminal from which the cashier makes transactions for clients. When the cashier accepts and issues money and checks, the POS terminal prints receipts. The POS terminal interacts with the bank_computer to verify and post transactions.

Client is the holder of one or more bank accounts. The client may consist of one or more individuals or organizations. The same person holding an account in another bank is treated as a different client.

Bank_computer is a computer owned by a bank that interacts with the ATM (ATM) network and the bank's own cash_terminals. The bank may have its own internal computer network to process invoices, but here we are only considering the bank_computer that communicates with the ATM network.

The consortium is an association of banks that ensures the operation of the ATM (ATM) network. The network transmits bank transactions to the consortium.

Posting is a single integrated request to perform a certain sequence of operations on the accounts of one client. It has been assumed that ATMs (automated teller machines) only dispense money, but they should not exclude the possibility of printing checks or accepting money and checks. We would also like to ensure the flexibility of the system, which in the future will provide the ability to simultaneously process accounts from different clients, although this is not required yet. Various operations must be properly balanced.

Account - a single bank account over which postings are made. Accounts may be various types; a client can have several accounts.

Central_computer - a computer owned by a consortium that distributes transactions and their results between ATMs (ATMs) and bank_computers. The central_computer checks bank codes but does not post.

2.3.3. Definition of dependencies. Following the recommendations of paragraph 2.2.3, we distinguish explicit and implicit verb phrases from the preliminary statement of the problem and consider them as names of possible dependencies. From the formulation of the problem of the banking network (see section 1.3), the following expressions can be extracted:

Verb phrases (explicit and implicit):

Banking network includes cashiers and ATMs

Consortium distributes results of transactions via ATM

Bank owns bank computer

Bank computer supports accounts

Bank owns cash terminals

Cash terminal interacts with bank computer

Cashier enters posting to the invoice

ATM's interact with the central computer during wiring

Central computer interacts with bank computer

ATM accepts card

ATM communicates with user

ATM issues cash

ATM prints receipts

System regulates shared access

Bank provides software

Consortium comprises banks

Consortium owns central computer

System provides logging

System provides safety

Clients have cards

Card provides access to the account

In the bank serve cashiers

Then we exclude unnecessary or incorrect dependencies using the criteria formulated in paragraph 2.2.3:

· dependencies between excluded classes: the following dependencies are excluded: Banking network includes cashiers and ATMs (banking_network class excluded), ATM prints receipts (receipt class excluded), ATM issues cash (class money excluded), System provides logging transactions (record_keeping_service class excluded), System provides security of account management (class security_service excluded), Banks provide software (class software_software excluded);

· irrelevant dependencies and implementation related dependencies: dependency "System" regulates shared access" is excluded as implementation related;

· actions are described by dependencies such as "ATM accepts card" and "ATM communicates with the user"; we exclude these dependencies;

· training dependencies: addiction "Cashier" enters posting on the account" is decomposed into two binary dependencies "Cashier enters wiring" and "Wiring refers to account". Dependency "ATM"s interact with the central computer during wiring" is expanded into "ATM"s interact with central computer" and "Wiring begin with ATM";

· derived dependencies: dependency "Consortium" distributes ATM's are a consequence of the Consortium dependencies owns central computer" and "ATM"s interact with a central computer."

By removing redundant dependencies, we get the following list of dependencies:

Bank owns bank computer

Bank computer supports accounts

Bank owns cash terminals

Cash terminal interacts with bank computer

Cashier enters wiring

Wiring refers to account

ATM's interact with central computer

Wiring begins with ATM

Central computer interacts with bank computer

Consortium comprises banks

Consortium owns central computer

Clients have cards

Card provides access to the account

In the bank serve cashiers

Let us clarify the semantics of the remaining dependencies as follows:

· let's rename incorrectly named dependencies so that their meaning becomes clearer; so dependency Computer_bank supports it is more convenient to replace the accounts with the Bank dependency holds accounts.

· role names may not be used, since they are clear from the names of the classes involved in the dependency, such as for the ATM dependency interact with a central computer;

· unaccounted dependencies: Wiring begins from cash_terminal, Clients have Accounts, Posting registered card should be added to the model.

After specifying the dependencies, you can create original version object diagram. For the problem under consideration, it will have the form shown in Fig. 2.37.

Rice. 2.37. First version of the object diagram for the banking network

2.3.4. Attribute clarification. Applying the criteria formulated in clause 2.2.4, we obtain:

The card contains the bank_code and card_code; they can be considered attributes of objects of the card class, but it is more convenient to use them as qualifiers, since the bank_code ensures the choice of bank, reducing the multiplicity of the consortium - bank relationship; for a similar use of card_code, you need to add the Bank dependency issues cards, the qualifier of which will be card_code.

After making the above changes, the diagram will take the form shown in Fig. 2.38.

2.3.5. Organizing a class system using inheritance. In the example under consideration, it is natural to define superclasses for objects that define various terminals: cash_terminal and ATM (ATM), and for objects that define transactions: cashier_transaction and remote_transaction (from an ATM).

Having made the appropriate changes, we obtain the object diagram shown in Fig. 2.39.

Rice. 2.38. Object diagram for a banking network after specifying attributes and adding qualifiers

Rice. 2.39. Object diagram for banking taking into account inheritance

2.3.6. Further improvement of the model. The card acts in two entities: as a registration unit in the bank (passbook), which provides the client with access to his accounts, and as a data structure with which ATM works. Therefore, it is convenient to split the card class into two classes: registration_card and card; the first of these classes provides the client with access to his bank accounts, and the second defines the data structure with which ATM works.

It is convenient to imagine the posting class as an aggregation of change classes, since posting is an agreed upon sequence of making changes to accounts and other banking documents; When working with bank documents, three types of changes are considered: withdrawal, placement and request.

It is natural to combine the bank class with the computer_bank class, and the consortium class with the central_computer class.

Rice. 2.40. Final view of the object diagram for the banking network

After making the above changes, the object diagram will take the form shown in Fig. 2.40. This completes the construction of the object model of the preliminary design stage. Further refinements of the object model will be carried out at the following phases of the system life cycle.

Isolation of subsystems

2.4.1. The concept of a subsystem. So, the PS is a set of interdependent objects. Each object is characterized by a set of attributes, the values of which determine the state of the object, and a set of operations that can be applied to this object. When developing a software system, it is convenient to assume that all attributes of objects are closed (that is, they are not accessible outside the object, and in order to find out the value of an attribute of another object in an object, or change it, it is necessary to use one of the public operations of this object, if, of course, such an operation is defined). Object operations can be either public or private.

Thus, each object has a strictly defined interface, i.e. a set of public operations that can be applied to this object. All objects of the same class have the same interface. The interface of a class (and, consequently, of each object of this class) is specified by a list of signatures of its open (public) operations (and methods that implement them); signatures of closed operations are not included in the interface of objects of the corresponding class.

The system object model specifies the set of interdependent objects that make up the system, and therefore defines the set of interfaces available within the system. All data processing capabilities within the system (i.e., in each object that is part of the system) are determined by this set of interfaces, which defines internal environment(or Wednesday) systems.

Along with the internal environment of the system, it is possible to determine its external environment. It is determined by the functions (operations) implemented as part of the system software(i.e. operating system, programming system, various editors, DBMS, etc.), as well as in other application systems and libraries used in conjunction with the system. Objects and operations that make up the external environment of the system can also be accessed within the system. To keep this in mind, we could add another object to the object model whose interface would represent the environmental capabilities used in the system (such an interface usually represents only a part of the external environment's capabilities). But this would not be entirely accurate, since the external environment is realized not by one, but by several objects. On the other hand, inside the system there is no reason to consider the structure of its external environment. The way out of this contradiction is to introduce another entity into consideration - a subsystem.

Subsystem is a set of objects and subsystems that provide some functionality and interact with each other in accordance with their interfaces. Subsystem interface represents subset combining the interfaces of all objects and subsystems that make up this subsystem. A subsystem may include one or more interdependent objects and/or subsystems.

The set of interfaces of objects (and subsystems), which together constitute a certain subsystem, constitutes internal environment this subsystem. Each subsystem must include an environment subsystem representing external environment this subsystem. The environment subsystem for the banking service system, considered as an end-to-end example, is shown in Fig. 2.41. The environment subsystem interface determines in which software environment the designed system will operate and what capabilities of this environment will be used during its operation (this is important when there is a need for modification or replacement individual components environment).

Note that the environment subsystem represents only the interface of the banking service system with its external environment. The external environment of the banking service system consists of several subsystems and libraries, and an object model can also be developed for it, which can also contain the system being developed (in this object model it will be one of the subsystems).

The object model of the banking service system and its system (external) environment can also be depicted in the form of an object diagram (however, this object diagram will not include objects, but only subsystems; each subsystem is depicted on the diagram as a rectangle with double vertical sides). The dependencies between the subsystems depicted in this object diagram (Fig. 2.42) reflect the interaction of the designed banking system and the corresponding subsystems during the operation of the system. This determines the requirements of the designed system for its system environment.

Rice. 2.41. Object diagram of the banking network, which indicates the interface with the system environment

Rice. 2.42. Object diagram of a banking network and its system environment

The introduction of the concept of a subsystem and the ability to include subsystems in the object model along with objects (classes) defines the hierarchical structure of the object model and allows the use of the OMT methodology when designing quite complex software systems containing big number various objects and classes.

2.4.2. Interfaces and environments. Objects and subsystems that make up a subsystem more high level, we will call components the last one. As already noted, for each component that is part of the subsystem object model, its interface, i.e. a set of open (public) operations that can be applied to this component (object or subsystem).

Object Interface is defined by the interface of the corresponding class and is specified by a list of signatures of its public operations (methods). Subsystem interface is defined through the interfaces of its constituent objects and subsystems as follows: an operation can be included in the interface of a subsystem if this subsystem contains an object (subsystem) whose interface contains this operation. Interfaces are described in an interface description language IDL (Interface Definition Language).

All data processing capabilities within the subsystem (i.e., in each component included in its composition) are determined by a set of interfaces of its components, which determines internal environment of the subsystem.

If for some subsystem it turns out that none of its components contains an operation that it is desirable to include in its interface, an object that implements such an operation can be added to its composition. Such an object is called interface object. Interface objects allow you to coordinate the external interface of a subsystem with its external environment, i.e. with interfaces of other objects and subsystems, which, together with the subsystem in question, constitute a higher-level subsystem.

Let us explain the introduced concepts using the example of a banking service system. In its composition, one can distinguish the bank subsystem (in fact, the system will have several copies of the bank subsystem - one for each bank included in the consortium). In this case, the object model of the system will take the form shown in Fig. 2.43.

Rice. 2.43. Object diagram of the banking network after highlighting the bank subsystem

At the same time, the external interfaces of the bank and environment subsystems, together with the interfaces of the ATM and consortium objects, form the internal environment of the banking service system. Its external environment is shown in Fig. 2.42; it consists of the external interfaces of various software systems used in the banking system (the figure shows only a part of these systems), and its own external interface.

Summary

Disadvantages of the TCP/IP model

Despite its enormous popularity, the TCP/IP model and its protocols have a number of disadvantages:

· lack of distinction between the conceptual concepts of interface, protocol and level service, which is quite clearly done in the ISO/OSI model. As a result, the TCP/IP model cannot be used when developing new networks;

· using the TCP/IP model, no other protocol stack other than TCP/IP can be described;

· the model does not distinguish between the physical and channel levels, while they are completely different and a correct model should take this into account;

· IP and TCP protocols are the most carefully thought out and developed. Many of the other protocols in the stack were developed by students (students to think about!) and freely distributed, as a result of which they are widely ingrained in practice and are now difficult to replace with anything new offered by a commercial scheme.

As a summary, the ISO/OSI model is useful for theoretical research and development of new networks, although OSI protocols are not widely used. For TCP/IP, the opposite statement can be made: the stack cannot be considered as a full-fledged model, while the protocols themselves are well-tested and extremely popular.

Considering the reference model from the point of view of the new requirements that information flows place on the transfer process in the information and communication network, two problems should be highlighted.

First, two independent transfer mechanisms are implemented at the transport and link layers. This division of the task of transporting information was at one time dictated by the need to combine multiple networks using different technologies access to the communication channel. However, the presence of two inconsistent transmission mechanisms creates a problem of ensuring quality of service when transferring information. Achieve coordinated behavior of transport and channel levels(via the network layer) is impossible, based on the principle of autonomy of layers in the ISO/OSI model. However, modern concepts for the development of networks on a multiservice basis (in particular the NGN concept) provide strategies for coordinated behavior of the transport and data link layers, bypassing the network layer, which formally violates the principle of autonomy and goes beyond the scope of the reference model.

Secondly, due to the convergence of networks and the unification of information flows various services into the general transmitted stream of heterogeneous traffic, there is a need to identify its content. In a situation where highly specialized networks transmitted information flows specific types, this problem didn't exist.

Finding a solution mentioned problems Most network equipment manufacturers do this.

Even with the most superficial glance at the functioning of the network, it becomes clear that information network is a complex complex of software and hardware components. In this case, it is the software that determines the functionality of the information network.

Modern networking software is highly structured. The core functions and entire communication architecture (protocol models) are essentially implemented in the network software.

Analysis program structure allows you to consider the hierarchy of network software. The elements of this structure are software modules in which network objects and logical modules are implemented.

The software hierarchy can be presented as follows:

· application software;

· middleware;

· basic software.

IN application software Application objects are implemented. There are two types of applications that influence the structure of the software organization - locally limited And distributed applications.

Locally Restricted Application is installed, called, managed and executed entirely within one end system and does not require the involvement of communication functions. An example is editing a document when preparing text on the user's computer (user terminal).

Distribution application consists of several components that can be executed in different end systems and, therefore, require the organization of interaction between these end systems. For example, joint editing of the text of a voluminous publication by users located in different places.

Components distributed application can be repeatedly used by other applications. In this case they become objects middleware and support services related to network intelligence.

Middleware implements service management functions and functions in the network administrative management network. Objects of both software groups, similar to components of distribution applications, interact through the communication functions of the network.

Basic software is intended to provide application software and middleware objects with the ability to execute and interact with other objects by providing an environment for interaction with network communication functions and logical user interfaces. The organization of this environment is carried out by unified software systems called network operating systems . The efficiency of not only application and middleware objects, but also the network as a whole depends on what resource management concepts form the basis of the network OS. The de facto network OS standards today have become UNIX systems And network versions Windows. Logical components of communication functions implemented in software that ensure communication between remote objects also belong to the functions of the base software.

Basic software also includes data processing and storage objects implemented in such software systems, such as DBMS (database management systems), basic transaction processing server software, etc.

The nature of the interaction between objects is determined by the type object interface, which is similar protocol And functional reference point.

Distinguish following types object interfaces (software interfaces):

· application protocol (Application Protocol, AP) – logical interface between application objects;

· interface application programs (Application Program Interface, API) - a logical interface between application objects and middleware objects that support application objects;

· middleware protocol(Managing Protocol, MP) – a logical interface between middleware objects;

· interface basic programs (Base Program Interface, BPI) – a logical interface between middleware and base software objects that support middleware objects;

· human-computer interface User-Computer Interface (UCI) is a logical interface between the user and primarily host software objects, but may also include logical interfaces with middleware objects and even application objects.

Network software is a resource involved in the organization of service delivery platforms, and therefore the compositional principles of aggregation software modules are subject to the same dynamism as the principles of construction functional model networks.

DBMS relational type best suited for implementing applications with not very complex structured data, but with very complex queries. The problems in them begin when trying to represent data structures with aggregates and generalizations.

The idea of creating an object data model can be simplified as adding persistence and transaction mechanics to an object programming language. Object DBMS allow you to work with very complexly organized data, but they still lack generally accepted query languages.

In object-relational DBMSs, the relational model is taken as a basis, which is extended by a system of object data types constructed by the user. The query language is an extension of SQL.

Somewhat exaggerating, we can say that classes are primary for the object model, and tables are primary for the object-relational model. The object model is based on classes and types, while the object-relational model is based on tables and types. There are other differences between these models related to the way they are constructed. For example, in object-based relational model all class attributes can only be public, but in an object class they can also be protected and hidden.

We will deal with the possibilities that the use of procedural class components provides in the following sections (10.2 and further).

Please note that regardless of the model on which the database is built, the user interface and data processing are currently performed on object languages. This means that in applications, data is inevitably transformed many times between several models, and among them there will certainly be object models. This explains the interest we will take in transforming data between different models.

In the initial stages of creating applications, it is very important to capture the semantics of the data. Entity-relationship diagrams used at the conceptual analysis stage are too focused on implementation in the relational model and do not allow conveying some meanings. In particular, the set of connections in them is not rich enough.

Consider the UML (Unified Modeling Language) language, which has more wide possibilities. Note that the term “unified” does not mean claims to universality. It's just that UML was created by combining at least three conceptual modeling languages.

To build relational, object and object-relational databases from the thirteen types of diagrams defined in UML-2, we only need class diagrams. These are structure diagrams that define sets of classes, their attributes, operators, and relationships between them.

Definition. A class is a named description of a collection of objects that have the same attributes, operations, relationships and semantics. The class has unique name, represented by a text string, which we will compose from nouns and adjectives connected without a break, each starting with a capital letter.

There are four options for class designation, shown in Figure 10.1.

Rice. 10.1.

Rice. 10.2.

Definition. Association links are classified according to the number of connected classes. They are indicated by solid lines. There are binary bonds (connecting two classes), ternary (three classes) and N-ary. For binary relationships, the order of the classes being connected can be specified. So, in the example in Figure 10.3, the connection reads like this: “Mom is washing the frame.”

Rice. 10.3.

The ends of an association link can be marked with the names of roles, for which the link multiplicities can be specified. Role assignments are the same as in ER diagrams (see section 2.2.6). Role multiplicities indicate how many objects with that role can participate in the association. Thus, a multiplicity of 1 indicates that the connection is mandatory, a multiplicity of 0..1 means that it is optional. Specifying a range of 1..* indicates that all objects must participate in some instance of the association and that the number of objects participating in one instance of the association is unlimited.

The example in Figure 10.4c shows that an employee necessarily works equally in one department, and a department can exist without any employees at all, but can have up to 15 people.

Rice. 10.4.

As you already understood, associations are implemented in the relational model.

Definition. A generalization relationship is a relationship between a more general class, called a parent or ancestor, and a more specialized class, called a child or subclass.

Object-oriented analysis and design with example applications in C++ Butch Gradi

Chapter 2 Object Model

Object-oriented technology is based on the so-called object model. Its main principles are: abstraction, encapsulation, modularity, hierarchy, typing, parallelism and persistence. Each of these principles in itself is not new, but in the object model they are applied together for the first time.

Object-oriented analysis and design are fundamentally different from traditional structural design approaches: here you need to imagine the decomposition process differently, and the architecture of the resulting software product in to a large extent goes beyond the concepts traditional for structured programming. The differences are due to the fact that structured design is based on structured programming, while object-oriented design is based on object-oriented programming methodology. Unfortunately, for different people The term "object-oriented programming" means different things. Wrench correctly predicted: "In the 1980s, object-oriented programming will occupy the same place as it did structured programming in the 1970s. but everyone will like it. Each company will advertise its product as being based on this technology. All programmers will write in this style, and each one will write differently. All managers will talk about it. And no one will know what it is."] These predictions continue to come true in the 1990s.

In this chapter, we'll explore what object-oriented software development is and isn't, and how this design approach differs from others based on the seven elements of the object model listed above.

From the book Homemade and office networks under Vista and XP author Vatamanyuk Alexander Ivanovich

Chapter 5 Model network interaction and basic network protocols If you have been consistent, you have already become familiar with the basic types and topologies of networks, as well as network standards. Like any other area of human life and work, all actions are

From the book ArchiCAD 11 author Dneprov Alexander G

Object Snapping Before you start looking at editing commands, pay attention to a tool that is absolutely necessary for skilled work - object snapping. Its purpose is to bind the characteristic points of the moving object to

From the ArchiCAD book. Let's start! author Orlov Andrey Alexandrovich

Object snapping Before looking at editing commands, let's pay attention to a tool absolutely necessary for skilled work - object snapping. Its purpose is to bind the characteristic points of the moving object to

From the book Database Processing in Visual Basic®.NET author McManus Geoffrey P

CHAPTER 4 ADO.NET Model: Data Providers Sometimes it seems that database application developers have not yet gotten used to new technology, How Microsoft company offered absolutely new model access to databases. This chapter focuses on the ADO.NET model,

From the book AutoCAD 2010 author Orlov Andrey Alexandrovich

Object snapping Methods for specifying point coordinates using the keyboard are not the only ones. It is usually much more convenient to specify points if you know how new objects should be located relative to existing ones. For example, if you know that the segment being created

From the book Practice and Problems of Business Process Modeling author of All sorts of E I

From the book The JavaScript Reference author Team of authors

Document Object Model It should be noted that JavaScript supports so-called external classes and objects defined by other programs. The Web page that you view in a Web browser window can be described as a collection of objects. Let's say it turns on a big one

From the book HTML 5, CSS 3 and Web 2.0. Development of modern Web sites. author Dronov Vladimir

From the book HTML 5, CSS 3 and Web 2.0. Development of modern Web sites author Dronov Vladimir

Web browser objects. Document Object Model DOM The objects provided by the Web browser are divided into two groups: - objects representing a Web page and elements created using different tags(paragraph, heading, table, image, etc.); - objects,

From the book XSLT Technology author Valikov Alexey Nikolaevich

Chapter 3. Idea and model XSLT language The third chapter is devoted to the models that are used in the XSLT language. It covers the tree model of an XML document, the data model used in XSLT and XPath, variables, expressions, and a model of the transformation process itself. Can

From the book Application Development in Linux environment. Second edition author Johnson Michael K.

Chapter 3 The Idea and Model of the XSLT Language

From the book VBA for Dummies by Steve Cummings

Chapter 10 Process Model The process model is one of the "trademarks" of Unix. This is the key to understanding access rights, the relationships between open files, signals, job control, and most of the other low-level concepts covered in this book. Linux adapts more

From the book How to make money on photography on the Internet author Zyomko Olga

What is an object model As already mentioned, VBA objects exist in a hierarchical dependence on one another. In addition to having their own properties, methods, and events, objects at higher levels of the hierarchy serve as containers for one or the whole

From the book Programming in Java author Vyazovik Nikolay Alexandrovich

Chapter 8 Model and Shooting Props Once you have an idea of what equipment you will need to use during the shooting process, you can begin to consider what exactly is involved. this process should be checked. Since you are

From the book HTML, XHTML and CSS 100% author Kvint Igor

8. Lecture: Object model in Java This lecture is a slight departure from the discussion technical features Java and is mainly devoted to the study of key properties of the Java object model, such as static elements, abstract methods and classes, interfaces,

From the author's book

10.4. Document Object Model (DOM) The standard set of objects in an HTML document, their properties and how to access them are determined by the Document Object Model (Document Object Model, abbreviated as DOM). DOM allows you to manage all elements on a web page, change their properties and

"I talked about how I divide a design document into Object Model And Functional Specification. I received quite a lot of questions, including the question of why I do such a division, as well as what difference between OM and Functional Specification, why not combine these two parts? I started to answer, but in the process I realized that, in fact, I began to write a separate article. If so, then I’d better write it here.

Why do we need an Object Model (OM)

Briefly - so that the project does not have this:

Don't get me wrong. I love pasta, but only as a meal.

Usually programmers like to write and talk about pasta. But it can also be in design, and how. It is extremely difficult to work with a pasty design document and even searching by keywords doesn't always save. And even cross-references (in those rare cases when they are placed) do not always help, and sometimes get confusing.

Therefore, the Object Model does two important functions:

Directory of game entities. Any team member can view it without delving into the jungle of design documentation and long search in convenient alphabetical order;
Parameter inheritance structure. This is already for pros, who write not just a design document, but also form the architecture of a future project.

Now in more detail about each of these points.

Inheritance (pro feature)

Drawing up a design document using inheritance can make life much easier for programmers (those who use it when creating the game architecture). In addition, it brings clarity to the design documentation itself and eliminates overload with unnecessary details.

Game Entity
- Item (InventoryItem)
  - Clothes (Equipment)
    - Armor

Below is how they look in the documentation (of course, in abbreviated form, 3-4 lines from OM):

Members of the GameEntity type (this is the top, most important entity in the project architecture and how it is stored in the database)

Members of the InventoryItem type

Equipment type members

Members of the Armor type

As you can see, Armor is the last entity in the example above, and has only three parameters: ArmorType, DamageReduxF, DamageReduxP. However, it inherits from the previous entity: DurabilityMax, DurabilityCurrent, Tiemype. In turn, that entity inherits: Volume, PlayMoneyPrice, realMoneyPrice, and so on until the very top.

Thus, using inheritance in the OM structure, we get rid of unnecessary work - we do not need to re-register all its parameters for each entity. We will not miss anything important and reduce the likelihood possible errors or discrepancies.

Moreover, by adding some new parameter into the upper entity, we will influence all its subentities. This greatly simplifies the work if there are, for example, a hundred subentities.

I think it’s obvious how much easier it is for programmers to understand the structure and architecture of the game.