Coursework: building an object model. Construction of an object model of the subject area "organization of sports club processes" using the UML modeling language

The object model of an existing business shows how and due to what precedents are implemented. This model reveals the internal structure of a business, namely: what types of resources are used to implement precedents and how they interact. The description of the object model is based on the concept of "object". Objects represent process participants and various types of entities (finished products, order, etc.).

Interface objects of the business process under study:

• 1. Customer service manager. Attributes: full name, position, salary. Responsibilities: interacts with customers, places orders, accepts payments from customers for orders.
• 2. Financially responsible storekeeper. Attributes: full name, position, salary. Responsibilities: interact with suppliers, accept materials and sign invoices.
• 3. Delivery driver. Attributes: full name, position, salary. Responsibilities: Delivery of the finished product to the client.

Control objects of the business process under study:

• 1. Designer. Attributes: full name, position, salary. Responsibilities: product design, project management, control.
• 2. Automated accounting operator. Attributes: full name, position, salary. Responsibilities: maintaining automated records, working with a database.
• 3. Furniture master (Assembler). Attributes: full name, position, salary. Responsibilities: Manufacture of the product in accordance with the project.

Entity objects of the business process under study:

• 1. Check - a document issued upon payment of the order.
• 2. Catalog - a document reflecting the range of products.
• 3. Order form - a document that includes the order number, order date, customer information, selected type, product sketch, customer wishes.
• 4. Product design - design of ordered furniture.
• 5. Application for materials - a document characterizing the necessary materials and their volumes.
• 6. Database - a program that allows you to maintain material records in a company.
• 7. Materials - necessary for the production of a custom product.
• 8. Invoice - a document signed upon shipment of materials.
• 9. The finished product is the result of production, characterized by belonging to any order.

Table 5.1 provides a description of the relationship of objects with each other.

Table 5.1 Description of how objects interact with each other

Note: If the necessary materials are in stock, then paragraphs 18, 19, 20, 21 of this table are skipped.

The dynamic model of interaction between departments and the customer in the “Selling a custom product” precedent is shown in Figure 5.1 The dynamic model of interaction between the department, employee and customer in the “Ordering” precedent is shown in Figure 5.2 The dynamic model of interaction between the department, employees and customer in the “Design” precedent " is shown in Figure 5.3. The dynamic model of employee interaction, in the "Manufacturing" precedent is shown in Figure 5.4.

Figure 5.1 Sequence diagram of the Selling a Custom Product use case

Figure 5.2 Sequence diagram of the "Place an order" use case

Figure 5.3 Design Use Case Sequence Diagram

Figure 5.4 Sequence diagram of the Manufacturing use case

Object Model

Object-oriented technology is based on the so-called object model. The main principles of its construction 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 structured design approaches: it requires a different way of thinking about the decomposition process, and the architecture of the resulting software product largely goes beyond the concepts of traditional 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.

Structural design methods help simplify the development process of complex systems by using algorithms as ready-made building blocks. Likewise, object-oriented design techniques are designed to help developers use the powerful expressive features of object-based and object-oriented programming that use classes and objects as building blocks.

. (object-oriented analysis, OOA) is aimed at creating models of reality based on an object-oriented worldview.

Object-oriented analysisis a methodology in which system requirements are perceived in terms of classes and objects identified in the subject area.

. ( object-oriented design, OOD )

Programming primarily involves the correct and effective use of the mechanisms of specific programming languages. Design, on the other hand, focuses on the correct and efficient structuring of complex systems. Let's define object-oriented design as follows:

Object-Oriented Designis a design methodology that combines the process of object decomposition and techniques for presenting logical and physical, as well as static and dynamic models of the system being designed.

There are two important parts to this definition: object-oriented design

1) is based on object-oriented decomposition;

2) uses a variety of techniques for representing models that reflect the logical (classes and objects) and physical (modules and processes) structure of the system, as well as its static and dynamic aspects.

It is object-oriented decomposition that distinguishes object-oriented design from structural design; in the first case, the logical structure of the system is reflected by abstractions in the form of classes and objects, in the second - by algorithms.

. (object-oriented programming, OOP)

Object-oriented programmingis a programming methodology based on representing a program as a collection of objects, each of which is an instance of a specific class, and the classes form an inheritance hierarchy.

This definition can be divided into three parts:

1) OOP uses as basic elements objects, not algorithms;

2) each object is copy any specific class;

3) classes are organized hierarchically.

A program will be object-oriented only if all three specified requirements are met. In particular, programming that is not based on hierarchical relationships does not belong to OOP, but is called programming based on abstract data types.

There are five main types of programming styles, which are listed below along with the types of abstractions inherent in them:

It is impossible to recognize any one programming style as the best in all areas of practical application. For example, a rule-oriented style is more suitable for designing knowledge bases, while a procedure-oriented style is more suitable for computing tasks. Based on accumulated experience, the object-oriented style is the most suitable for the widest range of applications; indeed, this paradigm often serves as the architectural foundation on which other paradigms are built.

Each programming style has its own conceptual basis. Each style requires its own state of mind and way of perceiving the problem being solved. For the object-oriented style, the conceptual basis is object model. It has four main elements:

• abstraction;
• encapsulation;
• modularity;
• hierarchy.

These elements are main in the sense that without any of them the model will not be object-oriented. In addition to the main ones, there are three additional elements:

• typing;
• parallelism;
• preservation.

By calling them optional, we mean that they are useful in the object model, but not required.

Abstraction identifies the essential characteristics of some object that distinguish it from all other types of objects and thus clearly defines its conceptual boundaries from the point of view of the observer.

The abstraction is based on the concepts of client and server.

Client Any object that uses the resources of another object (called server).

We will characterize the behavior of an object by the services it provides to other objects and the operations it performs on other objects. This approach focuses attention on the external manifestations of the object and leads to the idea contract model programming, when the external manifestation of an object is considered from the point of view of its contract with other objects, its internal structure must be carried out in accordance with this (often in interaction with other objects). The contract records all obligations that the server object has to the client object. In other words, this contract defines responsibility object, that is, the behavior for which it is responsible.

Each operation covered by this contract is uniquely defined by its formal parameters and return type. The complete set of operations that a client can perform on another object, together with the correct order in which those operations are called, is called protocol. A protocol reflects all the possible ways in which an object can act or be affected. It thus completely determines the external behavior of the abstraction from a static and dynamic point of view.

Encapsulation - this is the process of separating from each other the elements of an object that determine its structure and behavior. Encapsulation serves to isolate the contractual obligations of an abstraction from their implementation.

Abstraction and encapsulation are complementary: abstraction focuses on the observable behavior of an object, while encapsulation deals with the internal structure. Most often, encapsulation is accomplished through information hiding, that is, masking all internal details that do not affect external behavior. Typically, both the internal structure of an object and the implementation of its methods are hidden. In practical terms, this means that there are two parts to a class: an interface and an implementation. Interface reflects the external behavior of an object, describing the abstraction of the behavior of all objects of a given class. Internal implementation describes the representation of this abstraction and the mechanisms for achieving the desired behavior of the object. The principle of separating the interface and implementation corresponds to the essence of things: the interface part contains everything that concerns the interaction of a given object with any other objects; the implementation hides from other objects all details that are not related to the process of interaction between objects.

Modularity - this is a property of a system that has been decomposed into internally coherent, but weakly interconnected modules.

In the process of dividing a system into modules, two rules can be useful. First, because modules serve as elementary and indivisible program blocks that can be reused throughout the system, the distribution of classes and objects among modules must take this into account. Secondly, many compilers create a separate code segment for each module. Therefore, there may be restrictions on module size. The dynamics of subroutine calls and the layout of declarations within modules can greatly affect reference locality and virtual memory page management. When procedures are poorly modularized, mutual calls between segments become more frequent, which leads to loss of cache efficiency and frequent page changes.

It is quite difficult to bring together such contradictory requirements, but the main thing is to understand that the separation of classes and objects in a project and the organization of a modular structure is independent actions. The process of isolating classes and objects is part of the logical design process of a system, and dividing into modules is a stage of physical design. Of course, sometimes it is impossible to complete the logical design of a system without completing the physical design, and vice versa. These two processes are performed iteratively.

Hierarchy - this is the ordering of abstractions, their arrangement by levels.

The main types of hierarchical structures in relation to complex systems are the class structure (the "is-a" hierarchy) and the object structure (the "part of" hierarchy).

An important element of object-oriented systems and the main type of "is-a" hierarchy is the concept of inheritance mentioned above. Inheritance means a relationship between classes (parent/child relationship) in which one class borrows a structural or functional part of one or more other classes (respectively, single And multiple inheritance). In other words, inheritance creates a hierarchy of abstractions in which subclasses inherit the structure of one or more superclasses. Often a subclass builds on or rewrites components of a higher class.

While the "is a" hierarchy defines the generalization/specialization relationship, the "part of" relationship introduces the aggregation hierarchy. In the "part of" hierarchy, a class is at a higher level of abstraction than any used to implement it.

Typing is a way to protect against the use of objects of one class instead of another, or at least to control such use.

Parallelism - this is a property that distinguishes active objects from passive ones.

Storability - the ability of an object to exist in time, surviving the process that gave birth to it, and (or) in space, moving from its original address space.

With an object-oriented approach, the analysis of system requirements comes down to the development of models of this system. A model of a system (or any other object or phenomenon) is a formal description of a system that identifies the main objects that make up the system and the relationships between these objects. Building models is a widespread way to study complex objects and phenomena. The model omits numerous details that make it difficult to understand. Modeling is widespread in both science and technology.

Models help:

Check the performance of the system being developed at the early stages of its development;

Communicate with the system customer, clarifying his requirements for the system;

Make (if necessary) changes to the system design (both at the beginning of its design and at other phases of its life cycle).

Currently, there are several technologies for object-oriented development of application software systems, which are based on the construction and interpretation of models of these systems on a computer. This project uses one of them - OMT (Object Modeling Techniques). In addition, an object model diagram was constructed in UML.

The object model describes the structure of the objects that make up the system, their attributes, operations, and relationships with other objects. The object model must reflect those concepts and objects of the real world that are important for the system being developed. The object model reflects, first of all, the pragmatics of the system being developed, which is expressed in the use of application domain terminology associated with the use of the system being developed.

Defining Object Model Classes

Analysis of external requirements for the designed system makes it possible to determine 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.

Let's start by identifying possible classes from a written statement of an applied problem. 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.

As a result, we get the following list of possible class names:

Another proxy;

Document;

Remote Web server;

Configuration;

Information about the document;

Information about the remote Web server;

Request header;

Response header.

When creating any software project, the first (and most important) stage is always design. In any engineering discipline, design usually refers to some kind of unified approach through which we look for ways to solve a specific problem, ensuring the completion of the task. Behind Stroustrup's assumption: "The purpose of design is to identify a clear and relatively simple internal structure, which is sometimes called architecture... The design is the final product of the design process." Design products are models that allow us to understand the structure of the future system, balance requirements and outline an implementation scheme.

Modeling is widespread in all engineering disciplines, in large part because it implements the principles of decomposition, abstraction, and hierarchy. Each model describes a certain part of the system under consideration, and we, in turn, build new models based on old ones, in which we are more or less confident. Models allow us to control our failures. We evaluate the behavior of each model in normal and unusual situations, and then make appropriate adjustments if we are not satisfied with something.

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 is actually not new, but in the object model they are applied together for the first time. The first four concepts are mandatory in the understanding that without each of them the model will not be object-oriented. Others are optional, meaning that they are useful in the object model, but not required.

Benefits of the Object Model

The object model is fundamentally different from the models associated with more traditional methods of structural analysis, design, and programming. This does not mean that the object model requires the abandonment of all previously found and time-tested methods and techniques. Rather, it introduces some new elements that add to the previous experience. The object approach provides a number of significant conveniences that were not provided by other models. Most importantly, the object-based approach allows you to create systems that satisfy the characteristics of well-structured complex systems. There are five other benefits that the object model provides.

1. The object model allows you to fully use the expressive capabilities of object and object-oriented programming. Stroustrup notes, "It's not always obvious how to take full advantage of a language like C++. Significant improvements in efficiency and code quality can be achieved simply by using C++ as a 'improved C' with elements of data abstraction. However, much more A significant advance is the introduction of class hierarchy into the design process. This is what is called object-oriented design, and this is where the benefits of C++ are best demonstrated." Experience has shown that when languages ​​such as Smalltalk, Object Pascal, C++, CLOS, and Ada are used outside the object model, their strongest features are either ignored or misapplied.
2. Using the object-based approach significantly increases the level of unification of development and the reusability of not only programs, but also projects, which ultimately leads to the creation of a development environment. Object-oriented systems are often more compact than their non-object-oriented equivalents. And this means not only a reduction in the volume of program code, but also a reduction in the cost of the project, due to the use of previous developments, which gives a gain in cost and time
3. The use of an object model leads to the construction of systems based on stable intermediate descriptions, which simplifies the process of making changes. This gives the system the opportunity to develop gradually and does not lead to its complete reworking even in the case of significant changes in the initial requirements.
4. The object model reduces the risk of developing complex systems, primarily because the integration process stretches over the entire development period rather than becoming a one-time event. The object approach consists of a series of well-thought-out design steps, which also reduces the degree of risk and increases confidence in the correctness of the decisions made.
5. The object model is oriented towards the human perception of the world, or, in Robson's words, "Many people who have no idea how a computer works find the object-oriented approach to systems completely natural."

The conceptual basis of the object-oriented approach is the object model. The main principles of its construction are:

· abstraction;

· encapsulation;

· modularity;

· hierarchy.

Abstraction is the selection of the most important, essential characteristics of some object, which distinguish it from all other types of objects and, thus, clearly define its conceptual boundaries from the point of view of further consideration and analysis, and ignoring less important or insignificant details.

Abstraction allows you to manage the complexity of a system by focusing on the essential properties of an object. Abstraction focuses attention on the external features of an object and allows you to separate the most significant features of its behavior from the details of their implementation. Selecting the right set of abstractions for a given problem domain is the main challenge of object-oriented design. Abstraction depends on the domain and point of view - what is important in one context may not be important in another. Objects and classes are the basic abstractions of a domain.

Encapsulation is the physical localization of properties and behavior within a single abstraction (considered a "black box"), hiding their implementation behind a public interface.

Encapsulation is the process of separating from each other the individual elements of an object that determine its structure and behavior. Encapsulation serves to isolate an object's interface, which reflects its external behavior, from the object's internal implementation. The object approach assumes that its own resources, which can only be manipulated by the operations of the object itself, are hidden from the external environment. Abstraction and encapsulation are complementary: abstraction focuses attention on the external features of an object, while encapsulation (or otherwise restricting access) prevents user objects from discerning the internal structure of the object.

Encapsulation is similar to the concept of information hiding. This is the ability to hide numerous details of an object from the outside world. An object's external world is everything outside of it, including the rest of the system. Information hiding provides the same benefit as encapsulation: flexibility.

Modularity is a property of a system associated with the possibility of its decomposition into a number of internally strongly coupled, but weakly interconnected subsystems (modules).

Modularity reduces system complexity by allowing independent development of individual modules. Encapsulation and modularity create barriers between abstractions.

Hierarchy is a ranked or ordered system of abstractions, their arrangement by levels.

The main types of hierarchical structures in relation to complex systems are the class structure (hierarchy by nomenclature) and the structure of objects (hierarchy by composition). Examples of class hierarchies are simple and multiple inheritance (one class uses a structural or functional part, respectively, of one or more other classes), and object hierarchies are aggregation.

Classes can be organized in a hierarchical structure, which in appearance resembles a classification scheme in conceptual logic. The hierarchy of concepts is constructed as follows. The most general concept or category is taken to be the concept that has the largest volume and, accordingly, the smallest content. This is the highest level of abstraction for a given hierarchy. Then this general concept is specified, that is, its volume decreases and its content increases. A less general concept appears, which in the hierarchy diagram will be located one level below the original one. This process of concretizing concepts can be continued until, at the lowest level, a concept is obtained, the further concretization of which in a given context is either impossible or impractical.