Building an object model. Objects are characterized by attributes

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

1. BASIC THEORETICAL PROVISIONS OF OBJECT-ORIENTED METHODOLOGY

1.1 Basic concepts of the object-oriented approach

subject language programming model

Programming has long used a structured, procedure-oriented model. The selection of project goals is carried out using one of two approaches, called “top-down” and, accordingly, “bottom-up”

1. The “top-down” approach implies that the task is divided into subtasks, which in turn are divided into subtasks of the next level, etc. This process, called decomposition, continues until the simplification of subtasks is reduced to elementary functions that can be formalized.

2. The “bottom-up” approach implies that procedures are written to solve simple problems, then they are successively combined into more complex procedures until the desired effect is achieved.

Important programming concepts are procedure-oriented programming and object-oriented programming.

Procedural-oriented programming is programming in an imperative language, in which sequentially executed statements can be assembled into subroutines, that is, larger integral units of code, using the mechanisms of the language itself.

Object-oriented programming (OOP) is a programming style that captures real-world behavior in a way that hides its implementation details.

An object is a separate entity that stands out among other entities due to its properties, behavior, and interaction with other application objects.

The use of this technology makes it possible to represent the structure of a program in the form of a set of objects interacting with each other. As a result of such interaction, carried out by passing messages between objects, the specified functions of the program are implemented. After receiving a message, an object can perform a specific action, called a method.

There are two important differences between OOP and procedure-oriented programming:

1. In OOP, the programmer first selects classes from the description of the subject area, then builds an object model for solving the problem, and only after that proceeds to analyze their methods and properties.

2. Methods and properties are associated with a class intended to perform the corresponding operations.

If we analyze how a person solves various practical problems in the world around him, then we can understand that this world is also object-oriented. For example, to get to work, a person usually interacts with an object such as a vehicle. The vehicle, in turn, consists of objects that, interacting with each other, set it in motion, thanks to which a person realizes his task - getting to the desired point. At the same time, neither the driver nor the passenger is required to know how the objects that make up the vehicle interact.

In object-oriented programming, as in the real world, users of programs are isolated from the logic needed to complete tasks. For example, to print a page in a word processor, the user calls a certain function by clicking a button on the toolbar, but does not see the internal processes occurring. When printing a page while the program is running, a complex interaction of objects occurs, which, in turn, interact with the printer.

When creating an object-oriented program, the subject area is represented as a collection of objects that are combined into classes. Program execution consists of objects exchanging messages (interacting with each other). When representing a real object belonging to a domain using a program class, it is necessary to highlight its essential features in a real object and ignore many other properties, limiting ourselves to only those that are needed to solve a practical problem. This technique is called abstraction.

Abstraction is the identification of essential characteristics of an object that distinguish it from other objects. Moreover, the list of essential properties depends on the purposes of modeling, and can be completely different for different tasks. For example, the object “rat” from the point of view of a migration biologist, a veterinarian, or a chef will have completely different characteristics.

A class is a collection of objects that have common properties and behavior. Thus, a class can be defined as a certain community of specific objects, as a description of what they should be and what they should do. If objects actually exist in applications, then a class is an abstraction that combines objects into one group according to their properties and behavior in the environment in which they exist and interact. For example, Button1 on a form, with all its specific properties and action, is an object of the Button class.

Behavior is a characteristic of how one object affects other objects or changes itself under their influence. Behavior affects the way an object's states change.

Object-oriented programming technology is based on “three pillars”: encapsulation, inheritance and polymorphism.

Encapsulation is the property of combining state and behavior within one structure, and hiding the internal structure of an object and implementation details (from the word “capsule”). An important property of any object is its isolation. Object implementation details, i.e. internal data structures and algorithms for processing them are hidden from the user of the object and are inaccessible to unintentional changes. The object is used through an interface - a set of access rules. For example, in order to switch a television program, we just need to dial its number on the remote control, which will launch a complex mechanism that will ultimately lead to the desired result. We don't necessarily need to know what's going on in the remote control and the TV, we just need to know that the TV has this capability (method) and how it can be activated. Encapsulation, or implementation hiding, is a fundamental property of OOP. It allows you to create custom objects that have the required methods and then operate with them without going into the structure of these objects. Thus, encapsulation is a mechanism that combines data and methods for processing (manipulating) this data and protects both from external interference or misuse. Encapsulation of code within a class ensures that the code cannot be “broken” by any change in the implementation details of individual classes. Therefore, you can use an object in another environment, and be sure that it will not corrupt areas of memory that do not belong to it. If you still need to change or add something in the class, then the mechanisms of inheritance and polymorphism are used.

Inheritance is the hierarchy-based ability of classes to incorporate the properties and behavior of ancestor classes, and to add their own behavior and properties to them. Every year many programs are written in the world and it is important to use already written code. The advantage of object-oriented programming is that it is possible to define descendants for an object that correct or complement its behavior. In this case, there is no need not only to repeat the source code of the parent object, but even to have access to it. This makes it easier to modify a program and create new programs based on an existing one. Only through inheritance can you use objects whose source code is not available, but to which you need to make changes. Thus, when inheriting, you can not only add new functionality, but also change existing ones. And this is largely achieved thanks to polymorphism.

Polymorphism (“many forms”) - the ability to use the same expressions to denote different operations, the ability of descendant classes to implement the method described for the ancestor class in different ways, i.e. the ability to perform different actions or access objects of different types using the same name during program execution. Polymorphism is implemented through method overriding in descendant classes (the method has the same name and the same parameters, but works differently) - this is the mechanism of virtual methods through dynamic binding. Polymorphism is also implemented as “overloading” of methods (a method has the same name and different parameters) - for example, using the + sign to indicate addition in a real or integer class and a string class: similar messages give completely different results. Polymorphism provides the ability to abstract common properties.

Modularity 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 isolation of classes and objects in a project and the organization of a modular structure are 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.

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 is a property that distinguishes active objects from passive ones.

Persistence is 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.

The basic concepts of OOP have been transferred to programming from other areas of knowledge, such as philosophy, logic, mathematics and semiotics, without undergoing any special changes, at least as far as the essence of these concepts is concerned. The object method of decomposition (representation) is natural and has been used for many centuries. Therefore, it is not surprising that in the process of evolution of programming technology it has taken its rightful place.

Thus, in the process of developing object-oriented programs it is necessary:

1. determine the set of object classes that form it (decomposition);

2. for each class of objects, specify a set of necessary data (fields);

3. for each class of objects, specify a set of actions (methods) performed by the objects;

4. for each class of objects, specify the events to which the objects will react, and write the corresponding handler procedures.

The source code must contain class descriptions for all software objects. In addition, variables must be described whose types are the names of the corresponding classes. Instances of classes (objects) are created during program execution.

After its creation, an instance of a class must receive values for all its fields. Different instances of the same class can have different field values, but have the same methods. Class fields are not available for direct access, including assignment. This is done to increase the reliability of programs. Instead of directly assigning a value to an object field, a call must be made to a special method of the corresponding class, which performs such an assignment and monitors the correctness of the entered value. Similarly, special class methods can also be used to read the value of a field. To connect fields with methods for reading/writing their values, class members called properties are used. The user, when entering data to record them in the fields of an object or reading the values of fields, deals with the properties that represent these fields. Therefore, the term "property values" is usually used instead of the term "field values".

Members of the class can be:

1. fields used to store data;

2. properties as a means of accessing private fields;

3. methods that define the functionality of objects;

4. events and their handlers as means of program management.

Automation of solving problems of managing the activities of World of Computers LLC

Construction of a conceptual model of the information system of the municipal unitary enterprise "RPKHB"

The Rational Rose package is capable of solving almost any problem in the design of information systems: from business process analysis to code generation in a specific programming language. Allows you to develop both high-level...

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

Programming mathematical processes in Delphi

Project of a system for recording orders for cargo transportation of the motor transport company "TransAuto"

The main channel of communication in the company is written messages in the form of reports, newsletters, composed in the traditional (paper) way, which significantly reduces the speed of work. Most of the work is done manually...

Design of information systems using BPwin

Development of an information system for automating a librarian’s workplace

Development of an object-oriented model of an information subsystem for the dean’s office of a university (accounting for student progress)

Effective student database management is impossible without an automation system. The "Dean's Office" information system is designed for managing personal affairs of students and can work separately or as part of the "Electronic Gazette" IS...

Development of an object-oriented model of an educational library information system

Development trends of modern information technologies lead to a constant increase in the complexity of information systems (IS) created in various fields of human activity...

OOMD development consists of developing a data model using an object-oriented approach to modeling...

Development of a database schema for the task "Library Fund Accounting" for the Kharkov College of Textiles and Design

When choosing a DBMS to implement a particular system, it is necessary to take into account all the features of currently available technologies. So, given that the OO and ER models can be considered the most developed...

Submitting your good work to the knowledge base is easy. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

INTRODUCTION

1.1 Basic theoretical principles of object-oriented programming technology; Basic concepts of the object-oriented approach

1.2 Concept object

2. construction of an object model of the subject area “organization of sports club processes” using the UML modeling language

2.1 Characteristics of the UML modeling language

2.1.1 Brief history of UML

2.1.2 UML language

2.1.3 UML vocabulary

2.1.4 Model control view.

3.1 Description of the application structure

CONCLUSION

LIST OF SOURCES

Appendix A

INTRODUCTION

The sports club carries out comprehensive activities to develop physical culture and sports among young people and members of their families. More and more sports clubs are appearing, including many sports sections. The process of registering young people involved in these sections takes a lot of time and is a complex process. Therefore, the question of automating this process is becoming increasingly relevant.

When using a computer, this process becomes much more accurate and faster, devoid of many complications that arise when organizing it manually.

Features of the organization of sports club processes are identified using an object model of the subject area. Such models are especially useful for organizing the process of accounting for young people involved in sports club sections, since modeling this subject area makes it possible to examine the object from all sides and, thanks to this, foresee all possible problems. For example, when drawing up a schedule, the object model of organizing the educational process allows you to avoid overlaps that arise when distributing hours for sections, since this point will be provided for during development.

An object model of a domain can be built using the visual object modeling language UML or as a software product in some programming language that supports object programming technology, an example of which is the Object Pascal language.

The purpose of this research is to study object-oriented methodology and programming technology using the example of the Object Pascal language, methods and tools for constructing object models of subject areas, and applying the acquired knowledge to build an object model of the subject area “Organization of the work of a sports club.”

To achieve the goal of this study, the following tasks were set:

· Study the basic theoretical principles of object-oriented methodology;

· Consider the UML language and build an object model of the subject area using this language;

· Develop an application that uses a set of classes to represent information about athletes.

The object of study of this course work is object-oriented design methodology.

The subject of this study is the object model of the subject area “Organization of the work of a sports club” and its main properties.

The research hypothesis is that the implementation of an object model in the Delphi visual development environment, using the basic principles of object-oriented methodology, will simplify the process of collecting, storing and processing information about the participants of a sports club.

At the stage of analyzing the subject area and designing the application structure, it is necessary to build a UML class diagram.

In the process of writing the course project, the following research methods were used:

· The descriptive method is used to present the theoretical aspects of the problem and briefly characterize the object of study;

· Method of comparison and analysis. Allows you to compare different views on the topic under consideration and diagnose the object of study;

· Systematic approach. It was used to summarize the results obtained and identify their logical relationship.

1. BASIC THEORETICAL PROVISIONS OF OBJECT-ORIENTED METHODOLOGY

1.1 Basic concepts of the object-oriented approach

subject language programming model

Programming has long used a structured, procedure-oriented model. The selection of project goals is carried out using one of two approaches, called “top-down” and, accordingly, “bottom-up”

1. The “top-down” approach implies that the task is divided into subtasks, which in turn are divided into subtasks of the next level, etc. This process, called decomposition, continues until the simplification of subtasks is reduced to elementary functions that can be formalized.

2. The “bottom-up” approach implies that procedures are written to solve simple problems, then they are successively combined into more complex procedures until the desired effect is achieved.

Important programming concepts are procedure-oriented programming and object-oriented programming.

Procedural-oriented programming is programming in an imperative language, in which sequentially executed statements can be assembled into subroutines, that is, larger integral units of code, using the mechanisms of the language itself.

Object-oriented programming (OOP) is a programming style that captures real-world behavior in a way that hides its implementation details.

An object is a separate entity that stands out among other entities due to its properties, behavior, and interaction with other application objects.

The use of this technology makes it possible to represent the structure of a program in the form of a set of objects interacting with each other. As a result of such interaction, carried out by passing messages between objects, the specified functions of the program are implemented. After receiving a message, an object can perform a specific action, called a method.

There are two important differences between OOP and procedure-oriented programming:

1. In OOP, the programmer first selects classes from the description of the subject area, then builds an object model for solving the problem, and only after that proceeds to analyze their methods and properties.

2. Methods and properties are associated with a class intended to perform the corresponding operations.

Behavior is a characteristic of how one object affects other objects or changes itself under their influence. Behavior affects the way an object's states change.

Object-oriented programming technology is based on “three pillars”: encapsulation, inheritance and polymorphism.

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 is a property that distinguishes active objects from passive ones.

Persistence is 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.

Thus, in the process of developing object-oriented programs it is necessary:

1. determine the set of object classes that form it (decomposition);

2. for each class of objects, specify a set of necessary data (fields);

3. for each class of objects, specify a set of actions (methods) performed by the objects;

4. for each class of objects, specify the events to which the objects will react, and write the corresponding handler procedures.

Members of the class can be:

1. fields used to store data;

2. properties as a means of accessing private fields;

3. methods that define the functionality of objects;

4. events and their handlers as means of program management.

1.2 Concept object

The object-oriented approach to programming proposes that everything that is part of the application be considered objects that interact with each other and with the user in accordance with the properties and behavior specified in the program, performing the necessary functions of the application. Thus, any application with this approach is a set of interconnected objects that implement the necessary functional requirements for the application.

An object is always concrete and actually exists in a form or application, while possessing only its own properties and behavior. The characteristics of objects that distinguish them from each other are their properties and behavior. In the real world, each object or process has a set of static and dynamic characteristics (properties and behavior). The behavior of an object depends on its state and external influences. For example, an object “car” will not go anywhere if there is no gasoline in the tank, and if you turn the steering wheel, the position of the wheels will change. Thus, an object is represented as a set of data characterizing its state and methods (procedures and functions) for processing them, modeling its behavior. Calling a procedure or function for execution is often called sending a message to an object (for example, calling the “turn the steering wheel” procedure is often interpreted as sending the message “car, turn the steering wheel!”). Thus, each object is characterized by the following basic concepts:

1. a method is a function or procedure that implements possible actions with an object;

2. an event is a means of interaction of objects with each other. Objects generate specified events and perform actions in response to specified events. Events are analogous to messages that objects receive and send;

3. state - each object is always in a certain state, which is characterized by a set of properties of the object. Under the influence of events, an object goes into other states. In this case, the object itself can generate events when transitioning to another state;

4. property - a sign, some separate quality (parameter) of an object.

For example, properties can be the dimensions of an object, its title, its name. The set of properties of an object determines its state. Typically, properties are a set of variables and constants that store values that define the parameters of an object.

It is necessary to note that along with physical ones, abstract objects can also exist, typical representatives of which are numbers. Thus, an object is any physical or abstract clearly identifiable entity of a domain.

Objects are characterized by attributes. So, for example, the attributes of a car are maximum speed, engine power, body color, etc. The attributes of an amplifier are frequency range, output power, harmonic distortion, noise level, etc.

In addition to attributes, objects have some functionality, which in OOP is called operations, functions or methods. So, a car can drive, a ship can sail, a computer can perform calculations.

In this way, an object encapsulates attributes and methods, hiding its implementation from other objects that interact with it and use its functionality.

The object-oriented approach is based on the systematic use of models for language-independent development of a software system, based on its pragmatics.

The last term needs clarification. Pragmatics is determined by the purpose of developing a software system: for servicing bank clients, for managing the operation of an airport, for servicing the World Cup, etc. The formulation of the goal involves objects and concepts of the real world that are relevant to the software system being developed (see Figure 1.2.1).

With an object-oriented approach, these objects and concepts are replaced by their models, i.e. certain formal structures that represent them in a software system.

Fig.1.2.1 Semantics.

The model does not contain all the features and properties of the object (concept) it represents, but only those that are essential for the software system being developed. Thus, the model is “poorer” and, therefore, simpler than the object (concept) it represents. But the main thing is not even this, but that the model is a formal construction: the formal nature of models allows us to determine the formal dependencies between them and formal operations on them. This simplifies both the development and study (analysis) of models and their implementation on a computer. In particular, the formal nature of the models allows us to obtain a formal model of the software system being developed as a composition of formal models of its components.

Thus, the object-oriented approach helps to cope with complex problems such as

· reducing software complexity;

· increasing software reliability;

· providing the ability to modify individual software components without changing its remaining components;

· ensuring the possibility of reusing individual software components.

The systematic application of an object-oriented approach allows us to develop well-structured, reliable, and fairly easily modified software systems. This explains the interest of programmers in the object-oriented approach and object-oriented programming languages. The object-oriented approach is one of the most rapidly developing areas of theoretical and applied programming.

1.3 Tools for implementing object-oriented programming technology

In OOP technology, the relationship between data and algorithm is more regular: firstly, a class (the basic concept of this technology) combines data (structured variable) and methods (functions). Secondly, the pattern of interaction between functions and data is fundamentally different. A method (function) called on one object usually does not call another function directly. First, he must have access to another object (create, get a pointer, use an internal object in the current one, etc.), after which he can already call one of the known methods on it. Thus, the structure of the program is determined by the interaction of objects of different classes with each other. As a rule, there is a hierarchy of classes, and OOP technology can otherwise be called “class-to-class” programming.

Any programming is carried out according to one of four principles:

principle of modularity

principle “from general to specific”

· principle of step-by-step

· structuring principle

Modular programming. The principle of modularity is formulated as a requirement to develop a program in the form of a set of modules (functions). In this case, the division into modules should not be mechanical in nature, but based on the logic of the program:

1. module size must be limited;

2. the module must perform a logically integral and complete action;

3. the module must be universal, that is, whenever possible, parameterized: all changeable characteristics of the action being performed must be transmitted through parameters;

4. It is advisable to pass the input parameters and the result of the module not through global variables, but through formal parameters and the result of the function.

Another, but already physical unit of the program is a text file containing a number of functions and definitions of data types and variables. File-level modular programming is the ability to split the complete text of a program into multiple files. The principle of modularity applies not only to programs, but also to data: any set of parameters characterizing a logical or physical object must be represented in the program in the form of a single data structure (structured variable).

The embodiment of the modularity principle is the library of standard functions. It typically provides a full set of parameterized actions using common data structures. Libraries are similar programs, independently translated and placed in the library catalog.

Top-down programming. Top-down program design is that development proceeds from a general informal formulation of some program action in natural language, “from general to specific”: to replacing it with one of three formal programming language constructs:

· simple sequence of actions;

· selection constructs or if statements;

· repetition or cycle constructions.

In the algorithm's notation, this corresponds to a movement from an external (encompassing) structure to an internal (nested) one. These designs may also contain informal descriptions of actions in their parts, that is, top-down design is step-by-step in nature. Let us note the main properties of this approach:

· initially the program is formulated in the form of some informal action in natural language;

· the input parameters and the result of the action are initially determined;

· the next step of detailing does not change the structure of the program obtained in the previous steps;

· if during the design process identical actions are obtained in different branches, then this means it is necessary to design this action as a separate function;

· the necessary data structures are designed simultaneously with the detailing of the program.

Step-by-step programming. Top-down design is incremental in nature, because it involves replacing one verbal formulation each time with a single language construct. But in the process of developing a program, there may be other steps related to the specification of the verbal formulation itself into more detailed ones.

The fact that this principle is highlighted separately indicates the need to prevent the temptation to detail the program immediately from beginning to end and to develop the ability to highlight and focus attention on the main, rather than minor, details of the algorithm.

In general, top-down step-by-step program design does not guarantee a “correct” program, but it does allow you to return to one of the upper steps of detail when a deadlock is detected.

Structured programming. With top-down step-by-step program refinement, the data structures and variables necessary for operation appear as we move from informal definitions to language constructs, that is, the processes of detailing the algorithm and data proceed in parallel. However, this applies primarily to individual local variables and internal parameters. From the most general point of view, the object (in our case, data) is always primary in relation to the actions performed with it (in our case, the algorithm). Therefore, in fact, the way a program organizes data has a more significant impact on its algorithm structure than anything else, and the process of designing data structures should precede the process of designing an algorithm for processing them.

Structured programming is modular, top-down, step-by-step design of algorithm and data structures.

The object-oriented approach to programming includes 3 main components:

· object-oriented analysis (OOA),

· object-oriented design (OOD),

· object-oriented programming (OOP).

In any engineering discipline, design usually refers to a unified approach through which we look for ways to solve a specific problem, ensuring that the task is accomplished. In the context of engineering design, the design goal is defined as creating a system that

· satisfies given (possibly informal) functional specifications;

· consistent with the limitations imposed by the equipment;

· satisfies explicit and implicit requirements for performance and resource consumption;

· satisfies explicit and implicit product design criteria;

· satisfies the requirements for the development process itself, such as duration and cost, as well as the use of additional tools.

Design involves taking into account conflicting requirements. Its products are models that allow us to understand the structure of the future system, balance the requirements and outline an implementation scheme.

The program is a numerical model of the system being designed (Fig. 1.3.1.)

Rice. 1.3.1. Program structure.

The importance of building a model. Modeling is widespread across 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.

Elements of software design. It is clear that there is no universal method that would guide a software engineer from the requirements of a complex software system to their implementation. Designing a complex software system is not about blindly following a set of recipes. Rather, it is a gradual and iterative process. And yet, the use of a design methodology brings a certain organization to the development process. Software engineers have developed dozens of different methods, which we can classify into three categories. Despite their differences, these methods have something in common. In particular, they are united by the following:

· symbols - language for describing each model;

· process - rules for designing a model;

· tools - tools that speed up the process of creating models, and in which the laws of functioning of models are already embodied. Tools help identify errors during the development process.

A good design method is based on a solid theoretical foundation while allowing the programmer a certain degree of freedom of expression.

Object-oriented models. It is most useful to create models that focus on the objects found in the domain itself, forming what is called an object-oriented decomposition.

Object-oriented analysis and design is a method that logically leads to object-oriented decomposition. Using object-oriented design, programs are created that are flexible and written in a cost-effective manner. By dividing the state space wisely, we gain greater confidence in the correctness of our program. As a result, we reduce risk when developing complex software systems.

Since the construction of models is extremely important when designing complex systems, object-oriented design offers a rich selection of models (shown in Fig. 1.3.2) Object-oriented design models reflect the hierarchy of both classes and system objects. These models cover the full range of critical design decisions that must be considered when designing a complex system, and thus inspire us to create designs that exhibit all five attributes of well-designed complex systems.

Rice. 1.3.2 Object-oriented models.

OOP is a programming ideology based on combining data and procedures that can work with this data collectively, called classes.

The essence of OOP is the use of an object model familiar in everyday life. Each object has its own properties and you can perform actions specific to it. A class is an object type. The class describes and implements those same properties and actions. An object, in our understanding, will be a variable, the type of which will be some kind of class. We will call the fields of a class its properties, and its methods the actions that can be performed with an instance of this class (object).

As an example of a class implementation, let's look at the implementation of the concept of a book using a class to define a representation of the book TBook and a set of functions for working with variables of this type:

PagesCount: integer;

function CompareWithBook(OtherBook: TBook): integer;

procedure ShowTitle;

constructor Create(NewTitle, New

Human cognitive abilities are limited; we can push their boundaries using decomposition, abstraction, and hierarchies.

Complex systems can be studied by focusing on either objects or processes; There are good reasons to use object-oriented decomposition, in which the world is viewed as an ordered collection of objects that, in the process of interacting with each other, determine the behavior of the system.

Object-oriented analysis and design is a method that uses object decomposition; The object-oriented approach has its own notation and offers a rich set of logical and physical models with which we can get an idea of various aspects of the system under consideration.

2. CONSTRUCTION OF AN OBJECT MODEL OF THE SUBJECT DOMAIN “ORGANIZATION OF SPORTS CLUB PROCESSES” USING THE UML MODELING LANGUAGE

2.1 Concept of UML language

UML (Unified Modeling Language) is a unified graphical modeling language for describing, visualizing, designing and documenting object-oriented systems. UML is designed to support the process of modeling software based on an object-oriented approach, organize the relationship of conceptual and software concepts, and reflect the problems of scaling complex systems. UML models are used at all stages of the software life cycle, from business analysis to system maintenance. Different organizations may use UML as they see fit, depending on their problem areas and the technologies they use.

2.1.1 Brief history of UML

By the mid-90s, various authors had proposed several dozen object-oriented modeling methods, each of which used its own graphical notation. At the same time, any of these methods had its strengths, but did not allow building a sufficiently complete model of software, showing it “from all sides,” that is, all the necessary projections. In addition, the lack of a standard for object-oriented modeling made it difficult for developers to choose the most appropriate method, which prevented the widespread adoption of the object-oriented approach to software development.

At the request of the Object Management Group (OMG), the organization responsible for adopting standards in the field of object technologies and databases, the urgent problem of unification and standardization was solved by the authors of the three most popular object-oriented methods - G. Butch, D. Rambo and A. Jacobson, who collaborated to create UML 1.1, which was adopted as a standard by the OMG in 1997.

In the wake of growing interest in UML, companies such as Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software joined the development of new versions of the language within the UML Partners consortium. , Texas Instruments and Unisys. The result of the joint work was the UML 1.0 specification, released in January 1997. It was followed in November of the same year by version 1.1, which contained improvements to the notation as well as some semantic extensions. UML 1.4.2 has been adopted as an international standard by ISO/IEC 19501:2005.

The formal specification for the latest version of UML 2.0 was published in August 2005. The semantics of the language have been significantly refined and expanded to support the Model Driven Development - MDD methodology. The latest version of UML 2.4.1 was published in August 2011. UML 2.4.1 has been adopted as an international standard by ISO/IEC 19505-1, 19505-2.

2.1.2 UML language

Any language consists of a vocabulary and rules for combining words to create meaningful constructions. This is, in particular, how programming languages are structured, such as UML. Its distinctive feature is that the vocabulary of the language is formed by graphic elements. Each graphic symbol has a specific semantics associated with it, so a model created by one developer can be clearly understood by another, as well as by a software tool that interprets UML. From here, in particular, it follows that a software model presented in UML can be automatically translated into an OO programming language (such as Java, C++, VisualBasic), that is, if there is a good visual modeling tool that supports UML, having built the model , we will also receive a sample program code corresponding to this model.

It should be emphasized that UML is a language, not a method. It explains what elements to create models from and how to read them, but says nothing about which models should be developed and in what cases. To create a method based on UML, it is necessary to supplement it with a description of the software development process. An example of such a process is the Rational Unified Process, which will be discussed in subsequent articles.

2.1.3 UML Dictionary

The model is represented in the form of entities and relationships between them, which are shown in diagrams.

Entities are abstractions that are the basic elements of models. There are four types of entities - structural (class, interface, component, use case, collaboration, node), behavioral (interaction, state), grouping (packages) and annotation (comments). Each type of entity has its own graphical representation. Entities will be discussed in detail when studying the diagrams.

Relationships show the various connections between entities. UML defines the following relationship types:

· Dependency shows such a connection between two entities when a change in one of them - independent - can affect the semantics of the other - dependent. Dependency is represented by a dotted arrow directed from the dependent entity to the independent one.

· Association is a structural relationship showing that objects of one entity are associated with objects of another. Graphically, an association is shown as a line connecting the associated entities. Associations serve to navigate between objects. For example, the association between the classes “Order” and “Product” can be used to find all products specified in a specific order, on the one hand, or to find all orders that contain this product, on the other. It is clear that the corresponding programs must implement a mechanism that provides such navigation. If navigation in only one direction is required, it is indicated by an arrow at the end of the association. A special case of association is aggregation - a relationship of the form “whole” - “part”. Graphically, it is highlighted with a diamond at the end near the essence-whole.

· A generalization is a relationship between a parent entity and a child entity. Essentially, this relationship reflects the property of inheritance for classes and objects. The generalization is shown as a line ending in a triangle directed towards the parent entity. The child inherits the structure (attributes) and behavior (methods) of the parent, but at the same time it can have new structure elements and new methods. UML allows multiple inheritance, where an entity is related to more than one parent entity.

· Implementation - the relationship between an entity that defines a specification of behavior (interface) with an entity that defines the implementation of this behavior (class, component). This relationship is commonly used when modeling components and will be described in more detail in subsequent articles.

Diagrams. UML provides the following diagrams:

· Diagrams describing the behavior of the system:

State diagrams

· Activity diagrams,

· Object diagrams,

Sequence diagrams

· Collaboration diagrams;

· Diagrams describing the physical implementation of the system:

· Component diagrams;

· Deployment diagrams.

2.1.4 Model management structure

In order for a model to be well understood by humans, it is necessary to organize it hierarchically, leaving a small number of entities at each level of the hierarchy. UML includes a means of organizing a hierarchical representation of a model - packages. Any model consists of a set of packages that may contain classes, use cases, and other entities and diagrams. A package can contain other packages, allowing the creation of hierarchies. UML does not provide separate package diagrams, but they may appear in other diagrams. The package is depicted as a rectangle with a bookmark.

UML provides.

· hierarchical description of a complex system by highlighting packages;

· formalization of functional requirements for the system using the apparatus of use cases;

· detailing system requirements by constructing activity diagrams and scenarios;

· identifying data classes and constructing a conceptual data model in the form of class diagrams;

· identifying classes that describe the user interface and creating a screen navigation scheme;

· description of the processes of interaction of objects when performing system functions;

· description of the behavior of objects in the form of activity and state diagrams;

· description of software components and their interaction through interfaces;

· description of the physical architecture of the system.

UML would be difficult to use in actual software modeling without visual modeling tools. Such tools allow you to quickly present diagrams on the display screen, document them, generate program code templates in various object-oriented programming languages, and create database diagrams. Most of them include the ability to reengineer program codes - restore certain projections of a software model by automatically analyzing source codes of programs, which is very important to ensure consistency between the model and codes and when designing systems that inherit the functionality of predecessor systems.

2.2 Description of the functioning of the subject area “Organization of the work of a sports club”

Depending on the nature of the connections between the divisions of the enterprise, the following types of organizational structures are distinguished: linear, functional, linear-functional and matrix.

The work of this sports club uses a linear management structure.

The sports club solves the following problems:

· involvement of young people and members of their families in systematic physical education and sports;

· education of physical and moral-volitional qualities, strengthening health and reducing morbidity, increasing the level of professional readiness and social activity of young people;

· organizing and conducting mass recreational, physical education and sports events;

· creation of amateur sports associations, clubs, sections and teams in sports;

· promotion of physical culture and sports, a healthy lifestyle, organization of meaningful leisure, involvement of the broad masses of young people in mass socio-political events

The sports club performs the following functions:

· implements physical culture and sports in the activities of young people, their life and recreation; promotes a healthy lifestyle, fights to overcome bad habits;

· creates the necessary organizational and methodological conditions for practicing various forms and types of physical culture and sports in accordance with established traditions in the country;

· introduces new forms and methods of physical education, advanced experience and scientific achievements; uses material resources rationally and efficiently;

· develops social principles in every possible way in mass physical education, health and sports work;

· provides assistance to secondary schools and colleges in organizing mass recreational, physical education and sports activities;

· organizes the educational and training process in sports sections (national teams);

· develops and implements calendar plans for mass recreational, physical education and sports events, ensures the safety of their implementation;

· provides control over the educational and training process in sections of the sports club for the preparation of athletes of the highest sports qualifications, contributes to the creation of the necessary conditions for the growth of their sports skills;

· organizes, together with health authorities, medical control over the health status of those involved in physical culture and sports in sections (national teams);

· draws up current and long-term plans for the development of mass physical education, health, educational and sports activities, and cost estimates for the club.

· within the limits of its competence, selects and places physical education personnel;

· may have a flag, emblem, sports uniform, stamp, letterhead;

· conducts mass competitions, sports days (universiade), educational and training camps;

· in accordance with the approved procedure, sends teams and individual athletes to competitions;

· issues appropriate certificates (badges) to members of university teams;

2.3 Construction of a class diagram for the subject area “Organization of sports club processes”

The sports club has four sections based on the club:

· Basketball

· Volleyball

· Tennis.

When candidate-athletes apply to a sports club to enroll in any section, registration is carried out, which involves the following actions:

· Data about athletes is entered into a table indicating 5 fields: Last name, First name, Age, Phone, Section.

· Athletes are divided into sections to which the application was submitted.

· Parents of athletes are provided with a schedule of sports club sections.

To organize the correct work of the club, coordinate the work of sections, and the employment of coaches, the administrator of the sports club fills out the schedule.

When joining a club, an athlete is entered into a table indicating the section. All athletes involved in the club must be entered into the main table indicating the section.

To visually represent the work processes of the sports club, a UML diagram was built (Fig. 2.3.1).

Rice. 2.3.1 Object-oriented model of a sports club.

3. CONSTRUCTION OF AN OBJECT MODEL OF THE SUBJECT DOMAIN “ORGANIZATION OF WORK OF A SPORTS CLUB” USING THE VISUAL PROGRAMMING ENVIRONMENT DELPHI

3.1 Description of the application structure

This application is part of the Sport package. It consists of a class: class TPeople.

The “TPeople” class allows you to create and accumulate information about children involved in this sports club, which is called “Ogonyok”. It has five fields: The name is specified by the string “Name”; The last name is specified by the string “Famil”; Age is stored in the numeric variable (int) "Age"; the telephone number is specified by the string “Tel”; The section in which the athlete trains is specified by the string “Sekc”.

TPeople = class

Name: String;

Famil: String;

Age: Integer;

tel: String;

sekc: String;

constructor Create(AName: String);

end;

In this case, fields are entered in two ways:

Loading a value from a saved file with the LST extension. (Figure 3.1.1.)

The method is organized using the OpenDlg function, with each line of the class read as a separate value.

var F: TextFile;

i: Integer;

begin

try

with OpenDlg, PersonsList.Items do

begin

if Not Execute then Exit;

LoadFromFile(FileName);

AssignFile(F, Copy(FileName,1,Length(FileName)-4)+".lso");

Reset(F);

i:= 0;

while Not EOF(F) do

begin

Objects[i] := TPeople.Create("");

Readln(F, (Objects[i] as TPeople).Name);

Readln(F, (Objects[i] as TPeople).Famil);

Readln(F, (Objects[i] as TPeople).Age);

Readln(F, (Objects[i] as TPeople).tel);

Readln(F, (Objects[i] as TPeople).sekc);

Inc(i);

end;

CloseFile(F);

end;

except

on E: EFOpenError do ShowMessage("Error opening file");

end;end;

Rice. 3.1.1 Uploading a file.

The second method of filling the table is input using the Edit components. (Fig. 3.1.2.)

Rice. 3.1.2 Filling the table using the Edit component.

Moreover, the value of the “Section” field is selected from the values of the Combobox component and assigned to the “Sekc” line. (Fig.3.1.3)

Rice. 3.1.3 Combobox component.

The entered values can be adjusted by selecting the desired value and clicking the “Change” button (Fig. 3.1.4)

Rice. 3.1.4 Changing values.

The program provides for deleting a value by deleting one entry (Fig. 3.1.5) and deleting all entries (Fig. 3.1.6).

Deleting one record is done by selecting a value and clicking the “Delete” button.

Rice. 3.1.5 Deleting one entry.

In order to clear all records, click the “Clear” button.

Rice. 3.1.6 “Clear” button.

Both removal methods are carried out using the following methods:

procedure TMainForm.ToolButton4Click(Sender: TObject);

begin

with PersonsList do Items.Delete(ItemIndex);

end;

procedure TMainForm.ToolButton5Click(Sender: TObject);

begin

PersonsList.Items.Clear;

end;

After filling out the table of athletes, it becomes necessary to save it for future use. This is done by clicking the “Save” button (Fig. 3.1.7). After clicking this button, a dialog box opens, where the file storage folder and its name are indicated. (Fig. 3.1.8).

Similar documents

Brief description of the subject area. The relevance of developing an object-oriented information system model for an educational library. Create Use Case Diagram, Sequence Diagram, Collaboration Diagram, Class Diagram.

course work, added 06/01/2009

Development of an object-oriented warehouse accounting subsystem for the company "KavkazYugAvto". Brief description of the subject area. Drawing diagrams of placement, use cases, sequence, components and classes. Generating C++ code.

course work, added 06/26/2011

Basic elements of the object model. The essence and advantages of the object-oriented approach, the concept of object and class. Unified Modeling Language UML. Class and interaction diagrams: purpose, construction and examples of use.

abstract, added 06/09/2009

Description of the subject area "Store selling computer components." Building ER and relational data, entity and relationship models. Creation of ER and relational data model, queries, views, stored procedures for the subject area.

course work, added 06/15/2014

Relevance and practical significance of computer club software systems. Domain analysis. Class diagram, physical model of the system. Development of a visual IS project using the UML2.0 language and the Microsoft Visio modeling environment.

course work, added 06/21/2014

Analysis of the subject area "Poets Competition" based on an object-oriented approach. Development of a window application and description of the information model of the subject area. Description of the developed C++ procedures and application testing results.

course work, added 06/18/2013

Functional modeling IDEF0. Description of all work processes of the technical support department. Decomposition of the context diagram and core processes. Building a model of domain processes in the IDEF1X standard. Interface of the traffic control program.

practice report, added 11/22/2014

Construction of an informationological model of a subject area using the ER diagram method. Creating database relationships using SQL language. Filling the database. Creating queries to the computer club database. Create a report using Microsoft Word and Microsoft Excel.

course work, added 02/26/2009

Brief description of the subject area. Create Use Case, Sequence, Collaboration, Class, Placement, Component Diagrams. Adding details to operation descriptions and defining CLASS attributes. Generating C++ code.

course work, added 06/29/2011

General characteristics of a warehouse as an object of economic activity. Create a use case and sequence diagram. Building a corporate collaboration diagram. Purpose of class and component diagrams. Generating C++ code.

INTRODUCTION

The most important characteristics of any system are its structure and process of functioning. The structure of a system is understood as a time-stable set of relationships between its elements or components. It is the structure that binds all the elements together and prevents the system from disintegrating into separate components. The structure of a system can reflect a variety of relationships, including the nesting of elements of one system into another. In this case, it is customary to call the smaller or nested system a subsystem. The process of system functioning is closely related to changes in its properties or behavior over time. In this case, an important characteristic of the system is its state, which is understood as a set of properties or characteristics that at each moment of time reflect the most significant features of the system’s behavior. A common property of all models is their similarity to the original system. The importance of building models lies in the possibility of using them to obtain information about the properties or behavior of the original system. In this case, the process of constructing and subsequent application of models to obtain information about the original system is called modeling. The general system model contains some important information about the functional features of a given system, which provide insight into its future behavior.

The study of the modeling process is the object of study in this course work. The construction of a specific object model and the study of its behavior will be considered the subject of research. To achieve this goal, the following methods are used: study of the necessary literature, comparison, examples from life experience. Since the construction of an object model will be carried out using the example of a car service, it is necessary to study the operating principle of this organization. To do this, it is enough to visit the official websites of various car services. But to study the principles of constructing an object model, I studied scientific domestic and foreign literature. It turned out to be a very exciting activity.

As a result, the goal of my course work was to build an object model of the Autoservice information system, study the principle of constructing an object model, describe the construction process, prove the importance of possessing this knowledge and the ability to apply it in practice.

The structure of the course work is as follows: first, the theory of constructing an objective model is studied, then the implementation of the theory is tested using a practical example.

Basic concepts of the object-oriented approach

The object-oriented approach is based on the systematic use of models. The formulation of the goal involves objects and concepts of the real world that are relevant to the software system being developed. With an object-oriented approach, these objects and concepts are replaced by their models, i.e. certain formal structures that represent them in a software system.

The model does not contain all the features and properties of the object or concept it represents, but only those that are essential for the software system being developed. Thus, the model is simpler than the object (concept) it represents. This simplifies both the development and study (analysis) of models and their implementation on a computer. In particular, the formal nature of the models allows us to obtain a formal model of the software system being developed as a composition of formal models of its components.

Thus, the object-oriented approach helps to cope with complex problems such as reducing software complexity; increasing software reliability; ensuring the ability to modify individual software components without changing its remaining components; ensuring the possibility of reusing individual software components.

The systematic application of an object-oriented approach allows us to develop well-structured, reliable, and fairly easily modified software systems. This explains the interest of programmers in the object-oriented approach. The object-oriented approach is one of the most rapidly developing areas of theoretical and applied programming.

Object-oriented software development involves the use of object-oriented models in the development of software systems and their components.

Object-oriented development can begin at the very first stage of the life cycle; it is not related to the programming language in which the software system being developed is supposed to be implemented: this language may not be object-oriented. At the development stage, objects are some formal structures (for example, rectangles with rounded corners, with the help of which they are depicted on diagrams), which are not yet connected in any way with their future implementation in one of the programming languages.

Object-oriented software development involves the use of object-oriented methodologies (technologies). Typically, these object-oriented methodologies are supported by software tools, but even without such tools they are useful, since they allow a good understanding of the various aspects and properties of the software system being developed, which subsequently significantly facilitates its implementation, testing, maintenance, development of new versions and more significant modification.

The design of an application software system begins with an analysis of the requirements that it will have to satisfy. Such an analysis is carried out in order to understand the purpose and operating conditions of the system enough to be able to draw up its preliminary design.

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 the system, which 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 to check the performance of the system under development at the early stages of its development, communicate with the customer of the system, clarifying its requirements for the system, and make (if necessary) changes to the system design (both at the beginning of its design and at other phases of its life cycle).

Models developed and debugged in the first phase of the system life cycle continue to be used in all subsequent phases, facilitating system programming, debugging and testing, maintenance and further modification.

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 primarily reflects 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.

Let's consider the basic concepts used in constructing an object model.

An object is an abstraction or any thing with clearly defined boundaries that makes sense in the context of the application problem being considered. The introduction of objects has two goals: understanding the applied task (problem) and introducing the basis for implementation on a computer.

The purpose of developing an object model is to describe the objects that collectively make up the designed system, as well as to identify and indicate various dependencies between objects.

A class is a descriptor for a set of objects that have the same properties. A class describes the properties of a number of objects. Each object is an instance of only one class.

All objects of the same class are characterized by the same sets of attributes. However, the grouping of objects into classes is determined not by sets of attributes, but by semantics. So, for example, the objects stable and horse can have the same attributes: price and age. Moreover, they can belong to the same class, if they are considered in the problem simply as a product, or to different classes, which is more natural.

Combining objects into classes allows you to introduce abstraction into the problem and consider it in a more general formulation. A class has a name (such as horse) that applies to all objects of that class. In addition, the class contains the names of the attributes that are defined for objects. In this sense, the description of a class is similar to the description of a structure (record) type; Moreover, each object has the same meaning as an instance of the structure (variable or constant of the corresponding type).

An object attribute is a value that characterizes an object in its class. Examples of attributes: make, year of manufacture, color (attributes of objects of the car class), etc.

An operation is a function (or transformation) that can be applied to objects of a given class. Examples of operations: check, remove, install (for objects of the spare parts class).

All objects of a given class use the same instance of each operation (that is, increasing the number of objects of a certain class does not lead to an increase in the amount of loaded program code). The object from which the operation is called is passed to it as its implicit argument (parameter).

The same operation can be applied to objects of different classes: such an operation is called polymorphic because it can have different forms for different classes.

Dependencies between classes are two-way: all classes in the dependency have equal rights. This is true even in cases where the name of the dependency seems to introduce direction into the dependency. Dependencies between classes correspond to dependencies between objects of these classes. Dependencies, like classes, can have attributes.

A discriminator is an attribute of the "enumeration" type that shows which of the properties of objects a given generalization is made of.

The role defines one side of the dependency. In a binary dependency, two roles are defined. The role name uniquely identifies one side of the dependency. Roles make it possible to view a binary dependency as a relationship between an object and a set of dependent objects: each role is a designation of an object or set of objects connected by a dependency to an object at the other end of the dependency. A role name can be thought of as a derived attribute whose value set is the set of objects associated with that role. In a binary dependency, a pair of role names can be used to identify that dependency.

Role names must be specified in cases where a dependency is established between objects of the same class. Role names must be unique because they are used to distinguish the objects involved in the dependency.

A qualifier is an attribute that allows you to reduce the effective multiplicity of a dependency. Qualifiers are used in one-to-many or many-to-many dependencies.

Aggregation is a dependency between a class of composite objects and the classes representing the components of these objects (the “whole”-“part” relationship).

Generalization and inheritance make it possible to identify analogies between different classes of objects and determine the multi-level classification of objects. Thus, in graphic systems there may be classes that determine the depiction of various geometric shapes: points, lines (straight lines, circular arcs and curves defined by splines), polygons, circles, etc.

A discriminator is an attribute of the "enumeration" type that shows which of the properties of objects a given generalization is made of.

It should be noted that extensive multi-level classifications should be avoided because the behavior of subclasses of the lower levels of a multi-level classification can be difficult to understand: most (and often all) of the attributes and operations of such classes are defined in their superclasses of various levels. If the number of classification levels has become prohibitively large, you need to slightly change the structuring of the system.

Generalization and inheritance are widely used not only in the analysis of requirements for software systems and their preliminary design, but also in their implementation.

Sometimes it is necessary for a subclass to override an operation defined in one of its superclasses. To achieve this, an operation that can be derived from the superclass as a result of inheritance is also defined in the subclass; this redefinition "overshadows" its definition in the superclass, so that the operation overridden in the subclass, not the inherited one, is applied. Recall that each operation is defined by its signature; therefore, the signature of an operation override must match the signature of the operation in the superclass that is overridden by the operation.

An override can serve one of the following purposes:

extension: the new operation extends the inherited operation, taking into account the influence of the subclass attributes;

limitation: the new operation is limited to performing only part of the actions of the inherited operation, using the specifics of the objects of the subclass;

optimization: using the specifics of subclass objects allows you to simplify and speed up the corresponding method;

convenience.

It is advisable to adhere to the following semantic rules of inheritance:

all query operations (operations that use attribute values but do not change them) must be inherited by all subclasses;

all operations that change attribute values must be inherited in all their extensions;

all operations that change the values of restricted attributes or attributes that define dependencies must block in all their extensions;

operations should not be fundamentally redefined; all methods implementing the same operation must perform similar attribute conversion;

Inherited operations can be refined by adding additional actions.

By following these rules, which, unfortunately, are rarely supported by object-oriented programming languages, you can make the program you are developing more understandable, easier to modify, and less susceptible to various errors and oversights.

An abstract class cannot have objects because it does not define operations on objects; objects must belong to concrete subclasses of the abstract class. Abstract classes are used to specify interfaces for operations (methods that implement these operations are subsequently defined in subclasses of the abstract class). Abstract classes are convenient during the phase of analyzing system requirements, since they allow us to identify analogies in seemingly different operations defined in the system being analyzed.

Multiple inheritance allows a class to have more than one superclass, inheriting the properties (attributes and operations) of all its superclasses. A class that has multiple superclasses is called a union class. Properties of an ancestor class that appears more than once in the inheritance graph are inherited in only one copy. Conflicts between parallel definitions create ambiguities that must be resolved during implementation. In practice, such ambiguities or poor understanding should be avoided even when the particular programming language chosen to implement the system provides the ability to resolve them using priorities or some other means.

In object-oriented design, we deal with sets of interconnected objects. Each object can be treated as a variable or constant of a structure type (in this way, the methods described in the object are treated as addresses of functions that are allowed to be applied to this object). Therefore, a set of objects is a set of interconnected data, i.e. something very similar to a database. Therefore, the application of database concepts is often useful in object-oriented analysis and object-oriented design of application software systems.

Metadata is data that describes other data. For example, the definition of a class is metadata, since the class describes other data - objects of this class. Models are metadata because they describe the objects being modeled. Another example of metadata is an abstract class.

Actors are roles played by entities that directly interact with the system.

An actor defines the role that some external entity plays when interacting directly with a given system. It may represent a user role or a role performed by another system or piece of hardware that touches system boundaries.

I really liked the description of the concept of “actor” in the work “UML 2 and the Unified Process” by Jim Arlow and Isle Neustadt: “To understand actors, it is important to understand the concept of roles. A role can be thought of as a hat that is worn in a certain situation." (page 92).

When the basic concepts are known, we can consider building the model itself

Building an object model

Defining classes

Analysis of external requirements for the designed application system allows us to determine objects and classes of objects associated with the application problem that this system must solve. You need to start by identifying possible classes from the written statement of the applied problem (technical specifications and other documentation provided by the customer). 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 name of a possible class, it is assessed how necessary it is in the future system (it is often very difficult to assess this); irrelevant classes are excluded;

vaguely defined (from the point of view of the problem under consideration) classes;

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 are more likely to be operation names than classes (for example, telephone_call is unlikely to mean any class);

roles: some nouns define role names 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 constructs: names more associated with programming and computer hardware should not be compared to classes at this stage, since they do not reflect the features of the designed application system; 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.

Preparing the Data Dictionary

Individual words have too many interpretations. Therefore, it is necessary at the very beginning of the design to prepare a 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.

2.3. Defining 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).

Just as 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 the verbs or verb phrases found in the specified document. This is how they usually describe: physical position (follows_after, is_part, is_contained), directed action (leads_to_movement), communication (talks_to), belonging (has, is_part), etc.

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

dependencies between excluded classes must be eliminated, or reformulated in terms of the remaining classes;

Irrelevant and implementation-related dependencies should be eliminated;

actions: the dependency should describe the structural properties of the application domain, and not unimportant events;

trenary dependencies: most dependencies between three or more classes can be decomposed into several binary dependencies, using qualifiers if necessary; in some (very 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; 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.

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

Incorrectly named dependencies: they should be renamed so that their meaning becomes clear;

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;

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.4. Attribute refinement

At the next stage, the attribute system is clarified: class attributes are adjusted, and 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.

Along with the attributes of objects, 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 meaning of an attribute depends on a specific context, it should be made a qualifier.

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

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

Attributes of connections. If some property characterizes not the object itself, but its relationship with another object (objects), then this is an attribute of the connection, and not an attribute of the object.

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.5. Isolation of subsystems

An application system 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 application systems, it is convenient to assume that all object attributes are private (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, you must 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.

etc.............

Building an object model of a problem using the UML modeling language.

WORK IS DONE IN StarUML

Lead time:

2 – 3 lessons

To defend your work, you must provide a project created in the Rational Rose package, including three types of diagrams: use cases, classes (interface, data) and sequences for each function.

EXAMPLE TASK:

It is necessary to ensure that the following information is stored in the database:

- student information

o Full name,

o address,

o passport details,

o record number,

o date of birth,

o group);

- information about specialties

o name of specialty,

o cipher;

- information about groups

o speciality,

o year of admission,

o group number.

Ensure the issuance of a “Group List” document containing the following fields:

· serial number,

· Full name,

· record number.

Work order

The construction of the object model is carried out in the Rational Rose package. To do this, let's create an empty project. You should start your work with a use case diagram. It is built in the Main area of the Use Case View section, as shown in Fig. 9.

Before starting to build a diagram, it is necessary to define the roles of system users (actors) and their functions (use cases). In our case, two actors work with the system: “Employee of the educational department” and “Employee of the dean’s office.” The functions of an employee of the educational department include maintaining a list of specialties (under maintaining a list we will understand adding records, adjusting them and deleting them). The functions of the dean's office employee include maintaining a list of students and maintaining a list of groups.

The constructed diagram is shown in Fig. 10.

Next, in the Logical View section, you should create two class diagrams. To do this, you can create two packages. The first diagram should contain the interface classes of the application being designed (see Figure 11). In this figure, in the “List of Groups” and “List of Students” classes, the operations of adding, changing and deleting are omitted to avoid cluttering the figure. The group list (lower class) is the output document (it is preceded by the “Group Selection” class, since it is necessary to obtain a list of students in a certain group). The second diagram is database entities (see Fig. 12).

The constructed class diagram displays all forms of the future application and their relationships.

You should enter key fields and establish a connection (from the arrow context menu - Multiplicity).

The next stage of building an object model is creating sequence diagrams. Sequence diagrams are created for each use case in the use case diagram. To add a sequence diagram to a use case, you need to select it in the tree and call the context menu on it (NewàSequence Diagram) as shown in Fig. 13.

An example of a sequence diagram for the “Maintaining a list of specialties” precedent is shown in Fig. 14.

It should be noted that when constructing this type of diagram for the output document “Group List”, in our case, you should first select the group on the “Group Selection” form (this, in turn, should receive data from the “Group” entity), and then display the output form document, to which data comes from the “Student” entity.

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.

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.

Building an object model. Objects are characterized by attributes

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

1. BASIC THEORETICAL PROVISIONS OF OBJECT-ORIENTED METHODOLOGY

Submitting your good work to the knowledge base is easy. Use the form below

INTRODUCTION

When using a computer, this process becomes much more accurate and faster, devoid of many complications that arise when organizing it manually.

An object model of a domain can be built using the visual object modeling language UML or as a software product in some programming language that supports object programming technology, an example of which is the Object Pascal language.

To achieve the goal of this study, the following tasks were set:

· Study the basic theoretical principles of object-oriented methodology;

· Consider the UML language and build an object model of the subject area using this language;

· Develop an application that uses a set of classes to represent information about athletes.

The object of study of this course work is object-oriented design methodology.

The subject of this study is the object model of the subject area “Organization of the work of a sports club” and its main properties.

The research hypothesis is that the implementation of an object model in the Delphi visual development environment, using the basic principles of object-oriented methodology, will simplify the process of collecting, storing and processing information about the participants of a sports club.

At the stage of analyzing the subject area and designing the application structure, it is necessary to build a UML class diagram.

In the process of writing the course project, the following research methods were used:

· The descriptive method is used to present the theoretical aspects of the problem and briefly characterize the object of study;

· Method of comparison and analysis. Allows you to compare different views on the topic under consideration and diagnose the object of study;

· Systematic approach. It was used to summarize the results obtained and identify their logical relationship.

1. BASIC THEORETICAL PROVISIONS OF OBJECT-ORIENTED METHODOLOGY

1.1 Basic concepts of the object-oriented approach

subject language programming model

Programming has long used a structured, procedure-oriented model. The selection of project goals is carried out using one of two approaches, called “top-down” and, accordingly, “bottom-up”

1. The “top-down” approach implies that the task is divided into subtasks, which in turn are divided into subtasks of the next level, etc. This process, called decomposition, continues until the simplification of subtasks is reduced to elementary functions that can be formalized.

2. The “bottom-up” approach implies that procedures are written to solve simple problems, then they are successively combined into more complex procedures until the desired effect is achieved.

Important programming concepts are procedure-oriented programming and object-oriented programming.

Procedural-oriented programming is programming in an imperative language, in which sequentially executed statements can be assembled into subroutines, that is, larger integral units of code, using the mechanisms of the language itself.

Object-oriented programming (OOP) is a programming style that captures real-world behavior in a way that hides its implementation details.

An object is a separate entity that stands out among other entities due to its properties, behavior, and interaction with other application objects.

There are two important differences between OOP and procedure-oriented programming:

1. In OOP, the programmer first selects classes from the description of the subject area, then builds an object model for solving the problem, and only after that proceeds to analyze their methods and properties.

2. Methods and properties are associated with a class intended to perform the corresponding operations.

Behavior is a characteristic of how one object affects other objects or changes itself under their influence. Behavior affects the way an object's states change.

Object-oriented programming technology is based on “three pillars”: encapsulation, inheritance and polymorphism.

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 is a property that distinguishes active objects from passive ones.

Persistence is 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.

1.2 Concept object

1. a method is a function or procedure that implements possible actions with an object;

2. an event is a means of interaction of objects with each other. Objects generate specified events and perform actions in response to specified events. Events are analogous to messages that objects receive and send;

3. state - each object is always in a certain state, which is characterized by a set of properties of the object. Under the influence of events, an object goes into other states. In this case, the object itself can generate events when transitioning to another state;

4. property - a sign, some separate quality (parameter) of an object.

For example, properties can be the dimensions of an object, its title, its name. The set of properties of an object determines its state. Typically, properties are a set of variables and constants that store values ​​that define the parameters of an object.

It is necessary to note that along with physical ones, abstract objects can also exist, typical representatives of which are numbers. Thus, an object is any physical or abstract clearly identifiable entity of a domain.

Objects are characterized by attributes. So, for example, the attributes of a car are maximum speed, engine power, body color, etc. The attributes of an amplifier are frequency range, output power, harmonic distortion, noise level, etc.

In addition to attributes, objects have some functionality, which in OOP is called operations, functions or methods. So, a car can drive, a ship can sail, a computer can perform calculations.

In this way, an object encapsulates attributes and methods, hiding its implementation from other objects that interact with it and use its functionality.

The object-oriented approach is based on the systematic use of models for language-independent development of a software system, based on its pragmatics.

With an object-oriented approach, these objects and concepts are replaced by their models, i.e. certain formal structures that represent them in a software system.

Fig.1.2.1 Semantics.

Thus, the object-oriented approach helps to cope with complex problems such as

· reducing software complexity;

· increasing software reliability;

· providing the ability to modify individual software components without changing its remaining components;

· ensuring the possibility of reusing individual software components.

1.3 Tools for implementing object-oriented programming technology

Any programming is carried out according to one of four principles:

2. CONSTRUCTION OF AN OBJECT MODEL OF THE SUBJECT DOMAIN “ORGANIZATION OF SPORTS CLUB PROCESSES” USING THE UML MODELING LANGUAGE

2.1 Concept of UML language

2.1.1 Brief history of UML

2.1.2 UML language

2.1.3 UML Dictionary

The model is represented in the form of entities and relationships between them, which are shown in diagrams.

Relationships show the various connections between entities. UML defines the following relationship types:

· Dependency shows such a connection between two entities when a change in one of them - independent - can affect the semantics of the other - dependent. Dependency is represented by a dotted arrow directed from the dependent entity to the independent one.

Diagrams. UML provides the following diagrams:

2.1.4 Model management structure

UML provides.

· hierarchical description of a complex system by highlighting packages;

· formalization of functional requirements for the system using the apparatus of use cases;

· detailing system requirements by constructing activity diagrams and scenarios;

· identifying data classes and constructing a conceptual data model in the form of class diagrams;

· identifying classes that describe the user interface and creating a screen navigation scheme;

· description of the processes of interaction of objects when performing system functions;

· description of the behavior of objects in the form of activity and state diagrams;

· description of software components and their interaction through interfaces;

· description of the physical architecture of the system.

2.2 Description of the functioning of the subject area “Organization of the work of a sports club”

Depending on the nature of the connections between the divisions of the enterprise, the following types of organizational structures are distinguished: linear, functional, linear-functional and matrix.

The work of this sports club uses a linear management structure.

For example, properties can be the dimensions of an object, its title, its name. The set of properties of an object determines its state. Typically, properties are a set of variables and constants that store values that define the parameters of an object.