Send your good work in the knowledge base is simple. 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. Domain analysis

1.1 Statement of the problem

1.2 Algorithmic representation of the rules of the game

1.3 Requirements specification

1.4 Use case model

1.4.1 Building a use case diagram

1.5 Overview of development tools

1.6 Analysis of analogues

1.7 Chapter Conclusions

2. Game design

2.1 Design model

2.1.1 Game architecture

2.2 Development of a graphical user interface.

2.2.1 Interface structure

2.2.2 Main menu

2.2.3 Game screen

2.3 Implementing an interface in the Unity environment

2.3.1 Main menu

2.3.2 Game screen

2.6 Chapter Conclusions

3. Development

3.1 Moving cards

3.2 Player's playing field

3.3 Implementation of the computer behavior algorithm.

3.4 Chapter Conclusions

Conclusion

Bibliographic list

APPENDIX A. Properties of the basic version of the game "Evolution".

APPENDIX B. Algorithmic description of the rules of the game.

APPENDIX C. The source code of the computer behavior algorithm.

Introduction

Over the past 20 years, there have been rapid trends in the development of the video game market. Starting its way from slot machines, this area has gradually covered almost all digital devices that each of us uses every day: computers, tablets and mobile phones. Apart from this, there is also a market for board games that has a significant number of fans and interesting projects. Studies in this area have shown that about 62% of people who are fond of games prefer to play on a computer, mobile phone or tablet, about 14% like to play board games with friends, the remaining 24% prefer both. This difference in indicators indicates a loss of interest in board games, which in turn is due to the following factors:

· Most people cannot play a board game due to lack of time, space or necessary company, as almost all board games are designed to be played by 2 to 4 people;

There is no opportunity to practice alone and find new winning strategies for yourself;

· The board game box can take up a lot of space, and some cards or chips may get damaged or lost.

Compared to board games, PC games are more adaptable and user-friendly. You can access your favorite game at any time and on any device. There is also the ability to play offline against a computer or via the Internet, finding new opponents and improving your skills. And another important factor is that computer games are easier to store and take up only a few megabytes of hard drive space.

As part of the final qualification work, the board game "Evolution" is considered - this is a simulator of the development of life on Earth, based on the Darwinian principle of natural selection. Each player develops his own population of living creatures, endowing them with various properties - adaptations to environmental conditions.

This game is presented only in the desktop version, which means that it has the previously considered set of factors that determine the main problem of the study. To solve this problem, it is necessary to develop a computer version of the game, which in turn determines the relevance of the research topic.

Currently, there are a large number of different tools for developing computer or mobile games. Each of them has its own characteristics, its pros and cons. The Unity engine turned out to be the most preferable for the implementation of the Evolution game, due to its free distribution, huge community and the ability to create cross-platform games in the high-level C # programming language.

The object of this study is the board game "Evolution", the subject of the study is the development of a computer version of this game using the Unity game engine.

The aim of the work is to develop a computer version of the board game "Evolution" on the Unity game engine.

To achieve this goal, the following tasks must be completed:

1. Study the rules of the board game "Evolution" and, based on them, determine the functional requirements and describe the use case.

2. Design the architecture of the game being developed.

3. Design game objects and graphical user interface.

4. Implement a computer version of the game based on the designed models using the Unity environment.

At the analysis stage, research methods such as abstraction and decomposition are used to represent an object as a system. Object-oriented analysis and design are used to describe the interaction of all elements of the system.

1. Domain analysis

1.1 Statement of the problem

"Evolution" is a board game for a company of 2 to 4 people, where each player develops his own population of living creatures, endowing them with various properties necessary for survival. Properties help animals in the struggle for food resources, the stocks of which are limited. Creatures that do not get food die, and survivors allow even more animals and properties to be introduced into the game. The winner is the opponent whose population will be the most developed and numerous by the end of the game.

Animals and their properties are represented in the game in the form of cards. Where, on the one hand, the symbol of the animal is depicted - a lizard, and on the other, various properties, such as: "Predator", "Waterfowl", "Symbiosis", "Nornoe", etc. In total, there are 19 different properties in the basic version of the game (see Appendix 1). Each card lying on the player's field with the animal symbol up is one of his creatures. Properties are placed under the animal in such a way that other players can see what properties it has. On some cards, two properties are indicated at once: in this case, the player must choose which one he wants to give his creature. When an animal dies of starvation or is eaten by another animal with the Predator trait, it is sent to the player's discard pile along with all of its traits.

Beginning of the game. The deck of cards is shuffled. Each participant is given six cards. The game lasts several rounds until the cards in the deck run out. Each round consists of four stages:

? development phase;

? phase of determining the food base;

? power phase;

? phase of extinction and getting new cards.

At the beginning of the game, the player who will go first is randomly determined. In each subsequent round, this privilege is transferred clockwise to another player. During the development phase and during the feeding phase, the players take turns. A player who passes or for some reason cannot move in this phase skips his turn until the end of the phase. The stage ends when all players can no longer make a move.

Power phase. During this phase, players take turns taking one food token from the food base and use it on any of their creatures that has not yet been fed. Normal animals require one red food token to be considered fed, but some traits increase this requirement. Also, food tokens can be obtained by applying properties such as "Predator" or "Piracy" in this case, the additional food token will be blue. A fed animal cannot receive new food tokens, except when the "Fat Reserve" property is applied on it, when this property is applied, a red food token is converted to a yellow token. If all of the player's animals are fed and their "Fat" is full, the player can no longer take food tokens from the food supply or gain food tokens from abilities. However, if there are food tokens left in the food depot and the player still has unfed animals or animals with an unfilled "Fat Reserve", he must take tokens from the forage depot. When all the animals are fed and their "Fat supply" is full, or the food supply is over and the players have played all the properties that they wanted to use in this phase of the turn, the feeding phase ends.

Rice. 1.1. Game process algorithm.

This scheme includes the following sub-processes:

1. Initialization. Contains algorithms for determining the right of the first move and issuing the initial number of cards to all players.

2. Development phase. Contains an algorithm for placing cards on the table, in the form of animals and their properties.

3. The phase of determining the food base. Contains an algorithm for determining the number of food chips that will be available to players in the "feeding phase".

4. Power phase. Contains algorithms for feeding and applying animal properties.

5. The phase of extinction and getting new cards. Contains algorithms for moving unfed animals to the discard pile, determining the number and issuing new cards.

6. Completion of the game. This scheme contains an algorithm for scoring and determining the winner.

Detailed schemes of subprocesses are in Appendix B. Algorithmic description of the rules of the game.

1.3 Requirements specification

The game being developed is a complete analogue of the board game Evolution, therefore, first of all, the entire gameplay must comply with and follow the rules of the original (board) game.

Business requirements:

? game against the computer;

? choice of the number of players.

Functional requirements:

Requirements for the system, in terms of the rules of the game:

? issue cards;

? store up-to-date information about the current cards in the hands of players and their animals with all the properties lying on the playing field;

? calculate the sequence of moves;

? determine and transfer the right to the first move;

? calculate the interaction between different properties;

? determine the food base based on the number of players;

? put cards in the discard pile;

? store information about the cards in the player's discard pile;

? count the final points and determine the winner;

Requirements for the system, from the point of view of the player:

? start a new game;

? put a card in the form of an animal;

? put a card as a property;

? skip a move

? take a food token from the food base;

? put a food chip on your animal;

? activate \ apply property;

? finish the game.

1.4 Use case model

1.4.1 Building a use case diagram

Requirements visualization is implemented using use-case diagrams (see figure 1.2.).

Rice. 1.2. Case diagram.

1.4.2 Documenting use cases

The documentation of the use cases is presented in the tables below (see. tables 1.1. - 1.15).

table 1.1. Use case "Create a new game".

Table 1.2. "Set Parameters" use case.

Short description	The use case allows the user to set the parameters of the game being created and start the gameplay.
Performers
Preconditions	The user clicked the "New Game" button
main stream	1. The player chooses a set of cards to use: Standard set (84 cards) - by default. Supplement "Time to fly" (+42 cards). 2. The player chooses the number of players: 2 players - by default. 3 players. 4 players. 3. The player presses the "Create Game" button. 4. Bots (computer controlled players) are added to the created game in the amount specified in the settings.
Alternative streams
Postconditions	The parameters are set.

table 1.3.Precedent "Save the game".

Short description
Executor
Preconditions
main stream	2. The system displays a window in which the player is given the opportunity to choose the location where to save the file in txt format. 3. The player selects the path, file name and confirms the save. 4. The system saves the game to disk and gives the player a message. 5. The system offers to continue the game.
Alternative streams	A1. Not enough disk space. a. The system displays a message that there is not enough disk space for recording.
Postconditions	The configuration and the current state of the game are saved to a file on the hard drive

Table 1.4. Use case "Continue the game."

Short description	Use case allows you to continue a previously saved game.
Executor
Preconditions	The presence on the disk of a file with a saved game configuration.
main stream	1. The player starts the system. 2. The player clicks on the "Continue game" button. 3. The system displays a window in which the player is given the opportunity to select a saved game file. 4. The player selects a file and confirms the opening. A1. File with incorrect structure. 5. The system restores the configuration, state and number of players from the file and loads the playing field.
Alternative streams	A1. File with incorrect structure. a. The system displays a message that the file is corrupted. b. The system returns to the 3rd point.
Postconditions	The game configuration has been restored.

Table 1.5. "Finish the game" use case.

Short description	A use case allows you to log out of the system or end the game.
Executor
Preconditions
main stream	From the main menu: 1. The player presses the "Exit" button. 2. The system asks for confirmation of the exit "Yes \ No" 3. The system completes its execution and exits to the desktop. While in game: 1. The player presses the "Exit to menu" button. 2. The system asks you to confirm the exit "Yes\No". 3. The system exits to the main menu.
Alternative streams
Postconditions	The game is over.

Table 1.6. Play case.

Short description	A use case is a game process.
Executor
Preconditions	The "Create a new game" use case has been executed.
main stream	Beginning of the game: 1. The system determines the order of the move (Performs a draw based on the RNG). 2. The system transfers the right of the first move to the player selected as a result of the draw. 3. The "Get Cards" use case for the new game is executed. Development phase: A2. The player has already skipped a turn. 5. The player makes a move. A3. The player decides to leave. A4. The player has no cards in his hand. 6. The system transfers the queue to another player. The phase of determining the forage base: 7. The system uses a RNG to determine the number of food tokens that will be available during the feeding phase. 8. Food chips appear on the playing field. Power phase: A7. The player has already skipped a turn. 9. The player makes a move. A9. The player decides to leave. A5. The player presses the "Skip Turn" button. 10. The system moves the queue to the next player. Extinction phase: 11. Run the Get Cards use case in the extinction phase. End of the game: 12. The system calculates the points scored by the players. 13. The system displays the total result of all players. 14. The "Create a new game" \ "Exit to the menu" buttons appear.
Alternative streams	A1. All players received cards. a. The game moves to step 3. A2. The player has already skipped a turn. A3. The player has no cards in his hand. A4. The player decides to leave. a. Executes the "Make a Move" use case in the development phase. A5. The player presses the "Skip Turn" button. a. The "Skip Turn" use case is executed. A6. All players skipped a turn in the development phase. a. The game moves to step 5. A7. The player has already skipped a turn. a. The use case goes to step 8. A8. The player has no cards on the table. a. The "Skip Turn" use case is executed. A9. The player decides to leave. a. Executes the "Make a Move" use case in the power phase. A10. All players skipped a turn in the Feed phase. a. The game moves to step 9. A11. The "Get Cards" use case in the extinction phase is over. A11.1. None of the players received new cards. a. The right of the first move passes to the next player. b. The game returns to step 3. A11.1. None of the players received new cards during the extinction phase. a. The game moves to step 10. A12. The player scored the most points. a. The "Win" use case is executed. A13. The player, together with another player, scored the same number of points, but more than the rest of the players. a. The system additionally calculates points for animals in the players' discard pile. b. If the player scored more points than the opponent, the "Win" precedent is executed. c. If the player scored less points than the opponent, the Lose precedent is executed. A14. The player scored less points than the other player. A15. The player clicked the "Create a new game" button. a. The "Create game" use case is executed. A16. The player pressed the "Exit to menu" button. a. The "End Game" use case is executed.
Extension point	· “Win” case. · Lose case.
Postconditions	Game played.

Table 1.7. Use case "Get cards".

Short description	The use case allows the player to get new cards from the deck.
Preconditions	The "Create a new game" use case has been executed.
main stream	For a new game: 1. The system gives the player 6 cards from the common deck. In the extinction phase: A1. All players received the required number of cards, or the cards in the deck ran out. A2. The player's unfed animals are placed in the discard pile and the number of cards needed to be dealt is determined. 1. The system places unfed animals in the player's discard pile. 2. The system determines the number of cards required for the issue, equal to the number of surviving player animals + 1. 3. The system gives the player one card from the required number. 4. The system moves the queue to the next player. 5. Run the Get Cards use case in the extinction phase.
Alternative streams	A1. All players received the required number of cards, or the cards in the deck ran out. a. The precedent ends. A2. The player's unfed animals are placed in the discard pile and the number of surviving animals is determined. a. The use case goes to step 3. A3. The player has no surviving animals and no cards in his hand. A3.1. There are no cards in the deck. a. The system determines the number of cards required for issuance, equal to 6. A3.1. There are no cards in the deck. a. The Lose use case is executed. b. The use case goes to step 4. A4. The player is given all the required number of cards. a. The use case goes to step 4.
Postconditions	The player has received new cards.

Table 1.8. "Win" precedent.

table 1.9. Lose case.

Table 1.10

Short description	The use case skips the player's turn.
Preconditions	The player has the right to move.
main stream	1. The system ends the player's turn. In the current phase, the player will no longer receive the right to move.
Alternative streams	A1. The game is in the feeding phase, there are tokens in the food supply and the player has unfed animals or animals with unfilled fat reserves. a. The system displays a message stating that the player cannot skip a move, because. must take a food token. b. The precedent ends.
Postconditions	The player skips a turn and can no longer move in the current phase.

table 1.11. "Make a move" precedent.

Short description	A precedent allows a player to make a move.
Preconditions	The player has the right to move.
main stream	Development phase: Power phase: A5. The player applies the property.
Alternative streams	A1. The player puts down a card in the form of an animal. a. The "Put card as an animal" use case is executed. A2. The player puts down a card as a property. a. The "Put card as a feature" use case is executed. b. The "Make a move" use case ends. A3. There are no food tokens left in the food base. The player has no properties that can be applied. a. The "Skip Turn" use case is executed. A4. The player takes a food token from the forage base. a. The "Take food token" use case is executed. A5. The player applies the property. a. The "Apply property" use case is executed. A5.1. The player has no properties that can be applied. a. The "Make a move" use case ends.
Postconditions	The player makes a move in the current phase.

Table 1.12

Short description	Use case allows the player to create a new animal.
Preconditions	The player has the right to move.
main stream	A1. The player released the card. 2. The player drags the card to an empty space on his playing field. 3. The system allocates space and informs the player that the card will be placed in the form of the player's animal. A2. The card is located above another card of its playing field or the opponent's field. 4. The player releases the card. 5. The card is placed on the player's playing field with the image of the animal up.
Alternative streams	A1. The player released the card. A2. The player released the card over another card of his playing field or the opponent's field. a. Executes the "Put card as a property" use case from step 3. A3. The player released the card over the opponent's playing field.
Postconditions	An animal card has appeared on the playing field of the current player.

Table 1.13. Use case "Put a card as a property."

Short description	Use case allows the player to imbue the selected animal with a property.
Preconditions	The player has the right to move.
main stream	1. The player clicks on the selected card and holds it. A1. The player released the card. 2. The player drags the card onto the animal on his playing field. 3. The system highlights an animal card and informs the player that the card will be placed as a property of that animal. 4. The player releases the card. 5. The name and attributes of the property appear above the selected animal.
Alternative streams	A1. The player released the card. a. The card does not change position and remains in the "hands" of the player. A2. The player released the card to an empty place on his playing field. a. Executes the "Put card as an animal" use case from step 3. A3. The player released the card to an empty space on the opponent's playing field. a. The card is returned to the player's "hands". A4. The player released the card over the opponent's animal. a. If the ability can be applied to other players' animals, then the use case goes to step 5. b. If the property cannot be applied to the animals of other players, then the system informs the player that this property can only be applied to his animals, the card is returned back to the player's "hands". A5. The property on the map is a pair property. a. The system applies the property to the selected animal and prompts you to specify the player's second animal. b. The player specifies the 2nd animal. c. The system arranges the specified cards next to each other. d. The name of the property and a connecting line between these properties appear above the selected animals. A5.1. The player has only 1 animal. a. The system informs the player that the paired property cannot be placed because the player does not have enough animal cards. b. The card is returned to the player's "hands". A6. The map has 2 properties to choose from. a. The system displays a modal window with property options. b. The player clicks on the selected property. c. The use case goes to step 5. A7. The ability cannot be applied twice on the same animal card. a. The system informs the player that the ability cannot be placed twice on the same animal.
Postconditions	On the player's playing field, the name and attributes of the property that it possesses are added to the card of the animal.

Table 1.14. Take a food token.

Short description	The use case allows the player to feed one of his animals.
Preconditions	The player has the right to move.
main stream	1. The player presses and holds a food token in the feed depot. A1. The player released the chip. 2. The player drags the food token onto the animal on his game board. 3. The system highlights an animal card and informs the player that the animal will receive +1 food. 4. The player releases the food token. 5. The selected animal is marked with a food chip, the food supply is replenished by +1 unit.
Alternative streams	A1. The player released the chip. a. The chip does not change position and remains in the food base. A2. The player's animal has already been fed. a. The system allocates an animal card and informs the player that the animal cannot get a new food token, because is fully fed. b. If the player releases the food token, the token is returned to the food base. A3. The player released the food chip outside his playing field. A4. The player released the chip outside the animal card on his playing field. a. The chip is returned to the feed base.
Postconditions	The player's current animal replenishes food by 1 unit.

Table 1.15 Apply property use case.

Short description	Use case allows the player to activate the property of their animal.
Preconditions	The player has the right to move.
main stream	1. The system highlights animal properties that can be activated. 2. The player clicks on an available property. 3. The system processes the selected property and displays the result of the application on the playing field, or reports it to the player.
Alternative streams	A1. The "Predator" property has been used. a. The system highlights animals that can be attacked. b. The player chooses the animal that is going to attack. c. The system checks the protective properties of this animal. d. If there is a protective property, then the system transfers the move to the player whose animal is attacked, after choosing the property, the move is returned back to the attacking player and the precedent goes to step 3. e. If there are no properties or it did not work, the animal is considered eaten and disappears from the field. The animal of the attacking player receives 2 units of food. A2. The property can be used once per round. a. The system marks the property as used, such a property can no longer be used this round.
Postconditions	The property of an animal owned by the player is activated.

1.5 Overview of development tools

The Unity game engine was chosen as the development environment for the computer game "Evolution". Unity is a multiplatform tool for developing 2D/3D games and interactive content. To date, version 5 of the engine is available, which implements all the latest 3D and 2D technologies. One such technology is the UI System, which contains classes that make working with 2D elements much easier. . This technology is most suitable for creating a playing space and an interactive interface for the Evolution computer game. The basic set of UI elements and their purpose are presented in Table 1.16.

Table 1.16. Basic set of UI elements in Unity.

Name of the UI element	Purpose	Display
	Represents an abstract space in which the UI is configured and rendered. All UI elements must be children of canvas.
	Area for grouping elements. May contain a background image or color.
	Represents a graphical object loaded onto the stage, which can be used for level decoration, as a 2D game object, icon, etc.
	The Text component, also known as a Label, has an area for entering text to be displayed. It is possible to set the font, its style and size. There are options for setting alignment parameters; horizontal and vertical overflow settings that control the behavior of text when it does not fit in the width or height of the rectangle allocated to it.
	The button consists of an image and text, as well as a special button script. The text is located as a separate element inside the button. You can set the button to display in different states: normal state, hover state, click state, and button block state. Contains the button click event.
	This object allows the user to select one option from a list of options.
	This object allows the user to scroll an image or other area that is too large to fit within the specified frame.
	Uses to select numeric values ​​from a specified range.
	A complex component that includes an area for displaying content, a vertical and horizontal scrollbar for scrolling content within this area.
	Represents a switch that allows the user to enable or disable an option. It is also possible to combine several radio buttons into a group, in cases where only one of the options needs to be selected.
	Allows the user to enter text. Contains 2 events: text change and end of text change.

One of the main features of the Unity game engine is a convenient and fully customizable interface that combines the editor of scenes, game objects, scripts, animations, and also provides the ability to instantly launch and debug the application or game being developed. Figure 1.3. a screenshot of the editor window is shown. All resources and objects can be moved using Drag-and-Drop methods.

Rice. 1.3. Unity editor window.

The tabs used in the editor window are described in more detail below:

1 Scene view. In this window, you can move around the game world, move and rotate scene objects, and change their scale.

2.Game View. Represents an image of the game world drawn from the installed camera. Here you can see how the game will look like for the player. You can also launch and test the game.

3. Project Window. In this window, you can work with all project resources: images, fonts, scripts, saved objects, scenes, etc. Unity supports a huge number of different media formats.

4. Hierarchy Window. Represents a hierarchy of game objects located on the current scene.

5. Inspector Window. Allows you to view, modify and delete the properties\scripts of the currently selected object. And also add new properties/scripts to the object.

6.Toolbar. Contains tools for transforming game objects in the Scene View window, Application start and stop buttons in the Game View window, Layout drop-down menu which is responsible for the layout of windows in the editor.

7.Console Window. Provides output to the log messages, warnings and errors.

Unity also has the following benefits:

1. Openness of documentation. Unity comes with complete documentation and examples for every feature of the engine, which you can refer to at any time.

2. Community of developers. Unity has an active online community ready to help new users. Also, Unity Technology developers often listen to users and add new features to the game engine at their request. In addition, there are many official and unofficial video courses that help you understand the aspects of game development on this game engine.

3. Cross-platform. The same code written on the Unity engine can be transferred to various platforms (PC, Mac, Android, iOS, Web, game consoles) with minimal changes. This is a huge plus, which reduces the time for game development by several times.

4. Asset Store. Unity has its own store, where you can find a huge number of different plugins and resources for creating a game. Of course, some of them are free, some are paid, but they are all collected in one place with a convenient search and the ability to download, integrate and get working functionality right away.

The Visual Studio 2015 environment was chosen as a tool for writing program code. In this work, Visual Studio is used as the best alternative to MonoDevelop, which is present in the Unity game engine by default.

The high-level programming language C# was chosen as the programming language.

1.6 Analysis of analogues

During the study of the subject area, the only currently working analogue of the computer implementation of the board game "Evolution" was found. The interface of this analogue is shown in Figure 1.4.

Rice. 1.4. The user interface of the analog game.

This analogue has the following advantages:

? game mode is available against 1 computer at 3 difficulty levels. In this variant, the complexity manifests itself in giving a “handicap” to the computer (the computer plays one round without the participation of the player, after which the player joins);

? 1 vs 1 network mode available;

? Design mode is available, where you can check the interaction of various properties;

? clear and intuitive user interface based on point-and-click;

? there is an entry in the gameplay log, all the moves of the player and his opponent;

? the ability to view the code (an array containing the parameters of the current game: the number of cards in the deck, the order of the move and the list of cards in the hands of the players);

? it is possible to see the cards in the player's discard pile.

This analogue has the following disadvantages:

? the game is located on the VKontakte social network, which makes it impossible to play without an Internet connection;

? the presented game, in addition to the usual set of cards, contains cards from the "time to fly" add-on, which causes dissatisfaction among the players, since there is no choice of a set of cards.

Let's highlight the main criteria for comparing the analogue and the game we are developing (see table 1.17.):

1. Is it possible to run the game in offline mode against the computer?

2. Is it possible to play online via the Internet?

3. Do the rules of the game match the original game?

4. Is there an option to select the number of players?

5. Is it possible to change the difficulty level of the computer?

Table 1. 17. Comparison of the criteria for the game of the analogue and the game being developed.

Based on the results, we can conclude that the game being developed will be improved in the sense that it will allow you to play without an Internet connection. And there will be an opportunity to choose the number of players, from 2 to 4x. Thus, this analysis helps to identify the advantages and disadvantages of the analogue game and evaluate the competitive advantage of the game being developed.

1.7 Chapter Conclusions

As a result of the analysis of the rules of the board game "evolution", an algorithm was presented in the form of block diagrams, which describes in detail the stages of the gameplay. Functional requirements were developed for the system in terms of the rules of the game. A diagram of use cases is constructed and the main and alternative order of actions of the system is described when the player initializes the use case. A brief overview of the features and benefits of the Unity game engine was made. The pros and cons of the found analogue are considered and the advantages of the developed game are determined.

2. Game design

2.1 Design model

In the course of object-oriented analysis, classes responsible for the functionality presented in the precedent were put in accordance with each precedent. Table 2.1. shows the correspondence of use cases with the classes of the game, as well as a brief description of these classes.

algorithm interface file user

Table 2.1. Correspondence of precedents and classes of the game.

Precedent	class name	Class Description
Create a new game		Responsible for displaying UI elements on the screen and user interaction with them.
		Responsible for loading screens.
Set Options		Static class for storing game settings.
		The main class of the game, implements the game logic and manages all processes and elements in the game, and also allows you to save and load the game.
Continue game
Finish the game
	PlayerController	Responsible for initializing players. Controls the turn order.
		Responsible for the transition between phases of the game.
Get cards		Stores information about a player's type, his cards in hand, on the board, and in the discard pile.
		Responsible for storing and displaying the cards "in hand" of the player.
		Represents a deck of cards.
		Responsible for storing and displaying cards in the player's discard pile.
		It is a map with two properties on it.
		Stores information about a property displayed on a map. The name, description, and image of this property.
win
lose
Skip a turn
Make a move
Put the card in the form of an animal
		Represents a card on the player's table, placed in the form of an animal.
Put a card like a property
		Responsible for storing and displaying cards that are "on the table" of the player.
		It is a property of the card located on the player's table, as a sign of a particular animal.
Take a food token
		Responsible for generating, storing and displaying food tokens during the feeding phase.
		It is a food chip of a certain color (Red, Blue, Yellow), which is used when feeding the player's animal.
Apply property
		Responsible for processing the selected property and displaying the result on the playing field.

2.1.1 Game architecture

Game logic visualization is implemented using class diagrams. This diagram consists of two parts: the first part is the classes that describe the display of game objects, the second part of the classes describes the game logic. These classes are connected using the EvolutionGame class, which is responsible for the gameplay and intercepts events from other classes of the system. The class diagram representing the architecture of the game is shown in figures 2.1. - 2.3.

Rice. 2.1. Class diagram. Part 1.

Rice. 2.2. Class diagram. Part 2.

Rice. 2.3. Class diagram. Part 3

2.2 Development of a graphical user interface

2.2.1 Interface structure

Based data obtained as a result of analysis and design, a structure of the graphical user interface was developed, which contains links between the main screens of the game and the modal windows called on these screens. Also, this diagram contains the names of events that initialize the call of these windows. The structure of the interface is shown in Figure 2.4.

Rice. 2.4. Interface structure.

2.2.2 Main menu

Main menu ( see fig. 2.5.) of the game consists of the name of the game, a background image and 3 buttons: "New game", "Continue game" and "Exit". When you click on the "New Game" button, a modal window for setting the game parameters opens (see Fig. 2.6.), which contains switches for selecting a set of cards (the base set is installed by default and is not available for selection), selecting the number of players, as well as the button "Start the game", when clicked, the playing field will be loaded.

Rice. 2.5. Main menu

Rice. 2.6. Game parameters window.

2.2.3 Game screen

Screen The game consists of 2 areas: the frontal area and the playing field. The frontal area (see Fig. 2.7.) contains the top menu with buttons: "Show\hide game log", "Save game", "Exit to menu". Also in the upper part of the frontal area is a window with a game log, notification text and information about the current phase in which the game is located. At the bottom of the frontal area is a panel with the cards that are "in the hands" of the player. This panel can be collapsed and expanded with a mouse click. By double clicking on any card of an animal, it is scaled in the center of the screen (see Fig. 2.8.).

Rice. 2.7. front area.

Rice. 2.8. Detailed view of the map.

The gaming table (see Fig. 2.9.) is located in 3D space and contains 2 areas: the player and the opponent. These areas are used for the location of cards of animals and their properties. Between these areas is a food base with food tokens. Also on the gaming table are buttons for selecting players, a deck indicating the remaining number of cards, and a "Reset" button, when clicked, a modal window opens containing cards of animals that died as a result of the extinction phase.

Rice. 2.9. Game screen. Game table.

2.3 Implementing an interface in the Unity environment

To implement game levels and the main menu, Unity uses the scene engine. The scene in the context of Unity is a kind of container that can accommodate various game objects, sounds, lighting, as well as user interface elements.

Based on the designed graphical interface in Unity, 2 scenes were created:

· "Menu" - represents the main menu of the game.

· "Game" - is a game space, where the whole game process takes place directly.

All scenes, like any other resource, are saved to the project's Assets folder and can be opened in the editor window. Figure 2.10. the saved scenes of the project are shown.

Rice. 2.10. Project resources - game scenes.

Cameras are used to capture and display objects in the game space. The camera can be set in two modes: orthographic and perspective. When using an orthographic camera, the image of objects does not decrease with increasing distance. This mode is used to create two-dimensional and isometric worlds, in all other cases a perspective camera is used (see Fig. 2.11.).

Rice. 2.11. Camera settings in the Unity editor.

To create the game, it was customary to use the UI system of the Unity game engine. All UI elements are located on the canvas (Canvas), which determines the placement of 2D objects in the game space. The Render Mode property is responsible for this, which contains the following values:

Screen Space - Overlay. In this mode, the canvas scales to fit the screen and is drawn without connection to the scene or camera (the UI will be drawn even if there is no camera on the scene). If the window is resized, the canvas will be stretched to fit the screen. The canvas will be drawn on top of all other graphic elements.

Screen Space - Camera. In this mode, the canvas is drawn on a plane perpendicular to the camera view, at some distance from the viewpoint. The size of the canvas does not change with distance, it always scales to fill the camera frustrum view. The interface will be obscured by any 3D elements that are in front of the interface plane.

world space. In this mode, the canvas is located in world coordinates and is a flat 3D object.

2.3.1 Main menu

On the image 2.12. shows the main menu scene and the hierarchy of objects located on this scene. The canvas on which the UI elements are located has the RenderMode property set to Screen Space - Overlay. Elements such as: ParamsWindow, ExitConfirm, ContinueGame are modal windows and are inactive by default.

Rice. 2.12. Main Menu Scene and Game Object Hierarchy

MenuManager - an empty GameObject containing a class to manage the menu.

Settings - an empty GameObject containing a class with game settings. This object is passed when the game scene is loaded in order to have information about the selected settings.

2.3.2 Game screen

On the image 2.13. the scene "Playing field" and the hierarchy of objects in this scene are shown. The elements of the frontal area are placed on the canvas with the Render Mode property equal to Screen Space - Overlay, which means that the display of these elements does not depend on the camera. The playing field is a canvas located in 3D space and rotated at an angle of 30 degrees relative to the camera. A perspective camera is used to display this scene.

Rice. 2.13. Scene "Playing field" and the hierarchy of scene objects.

A general representation of the game scene, how it looks to the player, is shown in Figure 2.14.

Rice. 2.14. Debugging the "Playing Field" scene.

2.4 Game save file structure

The save file must be in a readable format for the program and contain information about all the current states of the game:

Current game settings

the current phase of the game;

current right to move;

The cards in the hands of the players;

Animal cards on the players' table;

Animal cards that are in the player's discard pile;

properties and relationships between animals;

information about the properties used;

information about fed animals;

the number of food chips in the feed base;

The cards in the deck.

JSON is the most appropriate format for describing this information. JSON (JavaScript Object Notation) is a simple data interchange format that is easy to read and write by both humans and computers. The approximate content of the file is shown in Figure 2.15.

Rice. 2.15. Game save file structure.

2.5 Designing computer behavior

To create an algorithm for the behavior of a computer-controlled player (hereinafter referred to as a bot), a mechanism based on a random number generator was designed. Each action of the bot is determined based on input conditions, such as: the current phase of the game, the number of cards in hand, the number of animals on the table and their properties, as well as the value obtained as a result of applying the random number generator.

All actions have a certain probability, this is done so that the bot, for example, does not miss the game without having time to lay out several cards on the table and thereby simplify the task for the player.

Similar Documents

Development of the computer game "Evolution" using the Unit game engine. Comparison of criteria for an analogue game and the game being developed. Development of a graphical user interface. Camera settings in the Unity editor. Game save file structure.

thesis, added 02/11/2017


Study of the basic concepts of programming applications for the Windows operating system. Studying the history of the creation of the universal programming language C. Development of a graphical user interface. Overview of the rules of the game and the algorithm of work.

term paper, added 11/09/2012


The concept and evolution of games, analysis of their various genres and existing analogues. The choice of software tools for the implementation of the game, writing the plot and the choice of the game development environment. Algorithms for making the learning game flexible. Description of program modules.

thesis, added 10/27/2017


The history of the development of the Java programming language. The history of Tetris - a cult computer game invented in the USSR. Rules of the game, features of scoring. Creation of the program interface, its implementation in the Java environment, coding, testing.

term paper, added 09/27/2013


Features of creating a number of gaming applications, logical games. The software of the simplest calculator, function generator. Development of interface elements for a simple graphic editor, electronic notebook, text editor.

training manual, added 10/24/2012


Description of the computer progress algorithm in the "user-computer" mode in the game "Sea Battle". Description of the set of classes, their fields and methods. Development of the interface and user manual for the game. Listing of a program written in Java.

term paper, added 03/26/2014


Substantiation of the need to develop a program for the game "Tetris". Mathematical and graphical parts of the algorithm. Choice of programming language and environment. Program text debugging, user interface development. Testing, user manual.

term paper, added 01/17/2011


A study of the general rules of the game of checkers, user and programmer instructions. Description of the main algorithms that perform tasks of the Life Widget class. Evaluation of computer and human moves. Building a search tree for the best move based on the evaluation of functions.

test, added 12/20/2012


Features of programming arcade games in the Python environment. Brief description of the Python programming language, its features and syntax. Description of the computer game "Tanks" - the rules of the game, an explanation of the key lines of code. Demonstration of the program.

term paper, added 12/03/2014


Study of the specification of the logic game "Minesweeper". System and functional design of the application. Development of software modules. An overview of the classes needed to create the interface for this application. Tools for the implementation of the logic game.

Lecture 6:

Use case diagrams close up

A few words about requirements

So let's talk about requirements. What it is, we, in general, understand - when a customer describes to us what exactly he wants, we always hear phrases like "I would like updates to be checked automatically, like in antiviruses", "I want a big green button in the center of the window , which starts the process", " program should allow you to view and print reports", "and so that everything is beautiful, with translucencies, like in Vista", "a confirmation should be displayed when exiting", etc. etc. Of course, as real developers, we understand that that the customer never knows what exactly he needs, and if he understands, he cannot explain. on essentially the same! They describe how the customer imagines the system, what the customer wants from the system, the functionality that he expects from it, the requirements that he places on it.

If we turn to the classics, for example, to the same "gang of three" (Jacobson, Butch, Rambo), we find out that a requirement is a desired functionality, feature, or behavior of a system. It is with the collection of requirements that the development process begins. ON. If you depict the development process ON as " black box" (we are sure the reader knows what it is, if not, Wikipedia is at your service), at the output of which we get software, then on entrance this "black box" will be submitted exactly the set of requirements for the software product ( rice. 6.1)!

Rice. 6.1.

By the way, what diagram does this picture resemble? Right, activity diagram. And the choice of this diagram here is absolutely justified - remember, we said that activity diagrams often used to describe business processes? The only caveat: usually the development process does not end with the release of a software product - a new one is coming iteration, new, clarified requirements, new version, etc.

By the way, back to the requirements. Yes, we said that the input of our "black box" is a set of requirements. But in what form? How are they documented, these requirements? I think most readers remember what technical task- the main document, without which no project began in Soviet times. This document was large, multi-page, with a clear structure determined by GOSTs (state industry standards). And he described on in fact, nothing more than the requirements for the system being created!

Technical task - thing on- its good. But time passed, standards, notations, ways of describing requirements changed. And gradually technical task succumbed place a set of artifacts consisting of documents of two types:

· use case diagrams ;

· non-functional requirements.

Use Case Diagrams constitute precedent model(use cases, use-cases). Precedent- this is the functionality of the system that allows the user to get some meaningful, tangible and measurable result for him. Each precedent corresponds to a single service provided by the simulated system in response to inquiry user, i.e., determines how to use this system. Exactly on For this reason, use cases, or precedents, often appear in Russian terminology as use cases. Use cases are most often used to specify external requirements for a system being designed, or to specify the functional behavior of an existing system. In addition, use cases implicitly describe the typical ways in which a user interacts with the system, allowing them to work correctly with the services provided by the system.

Non-functional requirements is a description of such properties of the system as features of the environment and implementation, performance,extensibility, reliability etc. Often, non-functional requirements are not tied to a specific use case and therefore are placed in a separate list additional system requirements rice. 6.2).

Rice. 6.2.

But back to precedents (use cases). It is the responsibility of the systems analyst to identify use cases and actors. And he does this in order to:

· clearly distinguish between the system and its environment;

· determine which actors and how exactly interact with the system, what functionality (use cases) is expected from the system;

· define and describe in the domain dictionary (glossary) the general concepts that are necessary for a detailed description of the system functionality (use cases).

This type of activity is usually performed in the following sequence:

1. Definition of actors.

2. Definition of precedents.

3. Write a description of each case.

4. Description of the use case model as a whole (this stage includes the creation of a domain dictionary).

Initially, the requirements are drawn up in the form of a plain text document, which is created either by the user himself, or by the user and the developer together. Further, the requirements are drawn up in the form of a table. The precedents are placed in the left column, and the actors participating in the precedent are placed in the right column.

Consider an example. The secretary hosts on the server menu dinner meals for the week. Employees should be able to access menu and place an order by selecting dishes for each day of the next week. Office- the manager should be able to generate an invoice and pay it. The system must be written in A.S.P..NET. Such is the simple Internet Appendix to automate lunch orders in office.

We think everything is clear here. table with a description of the requirements can be, for example, this:

Precedent	Actor
place menu	Secretary
see the menu
make an order	employee, secretary, office manager
create an account	Office Manager
pay the bill	Office Manager

Nowhere does it say that the system must be written in A.S.P..NET. Why - it's clear: it's a non-functional requirement! And yet, it is obvious that the secretary and office-manager are also employees. The reader, who has carefully read the previous lectures, will suspect that in this case, creating a model of precedents, talking about actors, one could apply generalization. Really, use case diagram, built on the basis of this table, can be, for example, such ( rice. 6.3):

Rice. 6.3.

Use case diagrams and their notation

Well, we have an example chart. So, what elements do we see on it? The first thing that catches your eye is the big rectangle, inside which ellipses are placed, denoting, as we have already understood, precedents. The name of the simulated system is indicated in the upper part of the rectangle, and it is called system (system boundary, subject boundary),context or simply system. This diagram element shows the boundary between what you like analyst shown in the form of precedents (within these frames), and what you portrayed as actors (outside them). Most often, such a rectangle shows boundaries of the system being modeled. That is, inside the boundary there are precedents - the functionality that the system implements (and in this sense, precedents can be considered as representations of subsystems and classes of the model), and outside - characters: users and others external entities interacting with the simulated system.

It should be said that the framework of the system is rarely depicted on use case diagrams, since they are implicitly implied by the diagram itself. By in fact, this element does not add any additional meaningful information to the diagram, so its use is a matter of analyst's taste. The appearance of the system scope on the use case diagram is most often dictated by the peculiarities of the personal design style.

In addition to the framework of the system or its context in the diagram, we see two more types of entities associated with it - these are characters(actors) and precedents. Let's start with the actors. Quite often in Russian-language literature on UML to designate actors, you can find the term " actor". In principle, its meaning is more or less clear and it is consonant with the original English term. Moreover, there is another reason for such a translation. Which word first thing that comes to your mind when you hear word "actor"? Yes, of course - word"role"! It is about roles that we will soon talk about when we try to figure out what is hidden behind the concept of "actor". In the meantime, forgive the reader, we will still use the word "ector" - a transcription of the original term. I remember that we already wrote about our attitude to the literal translation of terminology...

So, what is the meaning of the concept of an ector? Hector is a set of roles that user in the course of interaction with some entity (system, subsystem, class). An actor can be a person, another system, a subsystem, or a class that represents something outside of the entity in question. Actors "communicate" with the system by exchanging messages. By clearly identifying the actors, you thereby clearly define the boundary between what is inside the system and what is outside - the framework of the system.

Perhaps the words "roles played by the user" in the definition of an ector do not sound very clear. Very funny this concept is explained in Zicom Mentor:

a role is not a specific user, but a kind of hat that a person puts on when interacting with an entity.

Indeed, put on a pirate hat and you are Captain Jack Sparrow, and put on a top hat and you are Jack the Ripper! Joke... "Physical" user can play the role of one or even several actors, performing their functions in the course of interaction with the system. Conversely, the role of the same actor can be performed by several users.

On the charts UML Actors are depicted as stylized men, because, as you, of course, remember, the idea was to create a notation, any symbol of which can easily be drawn by hand ( rice. 6.4):

Rice. 6.4.

Despite the "human" appearance of this designation, one should not forget that actors are not necessarily people. An actor, as we said earlier, can be an external system, subsystem, Class etc. By the way, little man ("stick person" ) is not the only ector notation used in UML. In use case diagrams, it is usually the "humanoid" form of the ector that is used, but in other diagrams, and especially in cases where the actor has attributes, which are important to show, the image of the ector as a class with a stereotype is used<> (fig. 6.5):

Rice. 6.5.

Actors, as we have already said, communicate with the system through messages, but speaking at a higher level of abstraction, in terms of the precedent model, they interact with the system through precedents. The same actor can be associated with several use cases, and vice versa, one precedent can be associated with several different actors. Associations between an actor and a precedent are always binary - that is, they represent a one-to-one relationship, the use of multiplicity is not allowed. This does not contradict what was said above: indeed, one actor can be associated with several precedents, but only with the help of separate associations - on one for each precedent. We saw this in our example. By the way, there we saw associations depicted not just as lines, but as arrows. We think the meaning of this designation is quite clear: it is directed association and the arrow (as in other diagrams) is always directed towards the entity from which something is required, whose service is used, etc.

And yet - actors cannot be connected to each other. The only allowed attitude between actors - generalization(inheritance). Again, in our example of ordering meals at office, you could see exactly this kind of relationship between actors. It doesn't mean that in real life office- the manager and the secretary (and indeed any two employees) cannot communicate: just when creating a precedent model, such communication does not fall into the area of ​​​​our interests, it is considered insignificant.

Another type of element found in use case diagrams, moreover, which gave them their name, is actually precedents, or use cases. Precedent is a description of a set of successive events (including possible variants) performed by the system that lead to the result observed by the actor. Use cases describe the services provided by the system to the actors with which it interacts. And precedent never explains "how" the service works, only describes "what" is done.

Use cases are displayed in the form of an ellipse, inside the contour of which the name (description) of the use case is placed. The name of the use case is usually much longer than the names of other model elements. Why this is so, in principle, is clear: the name of the precedent describes the interaction of the actor with the system, tells what messages they exchange with each other. In our lunch ordering example, we have seen several use cases, and the reader will surely notice that the name of the use case is rather the name of the scenario that is played during the actor's interaction with the system. And it's always a description. from an ector's point of view, a description of the services provided by the system to the user. Let us give an example of the simplest diagram illustrating what we have said about precedent notation ( rice. 6.6).

Rice. 6.6.

In this example, a passenger can buy a ticket for a certain type of transport at a service cash desk. Buying a ticket is the name of the scenario, on which the actor (passenger) can interact with the system (cash desk). Note that this no description script, namely the title - it tells us what makes an actor in the process of interaction, but does not say exactly how! And yet - precedents define disjoint behavior scenarios. The execution of one use case cannot be interrupted by another use case. In other words, the execution of one use case cannot be interrupted by events or actions caused by the execution of another use case. precedents appear as atomic transactions, whose execution cannot be interrupted.

The attentive reader may have noted how imperceptibly we have introduced word " scenario". What is scenario and how is the notion of a scenario related to the notion of a precedent? The classics answer the first question well (G. Butch):

A script is a specific sequence of actions that illustrates behavior.

Scenario- this is a narrative story about the actions performed by the actor, a story, an episode that takes place in a given time frame and a given context of interaction. Scenarios (in various forms) are widely used in the software development process. As we have just noted, writing a script is like writing a fictional story, and this explains why the use of scripts is widespread among analysts, who often have artistic or literary ability. Despite their continuous narrative nature, scenarios can be viewed as sequences of actions (do storyboard). When designing a user interface, scripts describe the interaction between a user (or a category of users, such as system administrators, end users) and the system. Such scenario consists of a sequential description of combinations of individual actions and tasks (for example, keystrokes, clicks on controls, entering data into the corresponding fields, etc.). Recall, for example, descriptions of sequences of user actions (designed to achieve certain results, solve certain tasks) that you find in the help for an unfamiliar program. The same can be said about the fashionable now "how-to videos", in which such sequences are displayed visually, with specific examples. In any case, the purpose of such reference materials is to provide a description of typical scenarios for using the system, scenarios of interaction between the user and the system.

Scenarios can also sometimes be seen in a use case diagram. Sometimes they are depicted as sheet of paper"on which is written File name, - a rectangle with a folded lower left corner. In this case, the specified file contains a description of this scenario. And sometimes scenario written in a comment. As you probably remember, comments (notes, notes) are depicted as rectangles with a curved upper right corner and are connected to the element they explain with a dotted line ( rice. 6.7).

Rice. 6.7.

As we have already mentioned, scripts can be written in various forms. It can be structured but unformalized text, formalized structured text, pseudocode, table, activity diagram, finally! Each scenario describes in narrative form a completed, concrete interaction that has a specific purpose from the user's point of view. If we consider the tabular form of the scenario presentation, then the line separating the left and right columns of the table symbolizes the border that separates the user's actions from the system's responses. The tabular form emphasizes user participation, which is a very important aspect when designing a user interface.

Here is an example of a simple (non-formalized) textual description of the scenario.

The user enters a username, password, email address and confirmation code and clicks the "Next" button. The system asks for a verification code. The user enters the code and clicks the "Next" button. The system checks that the code matches the one shown in the picture .

Isn't it a familiar procedure? Yes, this is a description of user registration on some site. True, not quite complete: cases when the login selected by the user is already taken are not considered, the address email entered incorrectly password does not meet the requirements or the code does not match the one shown in the picture. About such cases alternative scenarios- We'll talk a little later.

And here is the same scenario in tabular view:

You have certainly noticed that this scenario can be detailed - for example, before asking to enter a verification code, the system displays a picture in which this same code is shown. i.e. inquiry to enter code includes conclusion pictures with mentioned code. We will also talk about this.

In the meantime, let's try to answer the second question, namely: How are the concepts of scenario and use case related?. Use cases, as we have already said, are born from the requirements of the system. But they talk about what the system does. How the system does it, scripts say. In this way, precedent can be specified by describing the flow of actions or events in textual form - in a form understandable to an "outsider" (not involved in the direct development of the system) reader. But such a description is scenario! In this way, scenarios specify use cases. And further. Because scripts are on In essence, stories are a very effective means of extracting information from conversations with the customer and provide an excellent, layman-friendly description of the application being created. Scenarios, and indeed use case diagrams(complemented with scripts) are great means of communication between developers and the customer, and, due to the simplicity of the notation, by a means understandable to both parties. Ultimately, the relationship between requirements, use cases, and scenarios can be represented by such a "pseudo diagram" ( rice. 6.8).

Rice. 6.8.

As you can see, for each association, the diagram shows multiplicity and its meaning is quite clear, but nevertheless, the multiplicity should be discussed separately. One precedent defines several scenarios, each of which represents one of the possible variants of the flow of events defined by the precedent. Scenarios are related to use cases in the same way as instances of a class, i.e. script is an instance of a use case, how an object- class instance. The system may contain, for example, several dozen cases, each of which, in its own queue, can unfold into dozens of scenarios. Usually, precedent describes not one sequence of actions, but many, and it is usually impossible to express all the details of the precedent under consideration with the help of one sequence of actions. For almost any precedent, one can single out the main scenario, which describes the "normal" sequence of action, and auxiliary describing alternative sequences that are triggered when certain conditions occur.

Another question is whether such a refinement of the precedent model is required, whether it is justified for a given level of approximation, or "implied" alternative scripts can be omitted? For example, in the previous example with the purchase of a ticket at a service cash desk, we did not depict scenarios (and, accordingly, precedents) corresponding to the options when there are no more tickets left for the flight selected by the passenger, the passenger changed his mind and wants to take a ticket for another flight, when payment goes in cash or on credit card, etc.

"Stop beating around the bush!" - the impatient reader will exclaim. We are already finishing. We just wanted to gently lead the reader to the question of relationships between use cases. And these relationships are very diverse. Let's start with an old friend - generalization relations (inheritance, generalization). We have already spoken about generalization more than once when we considered class diagrams. However, let us recall the essence of this concept. As the classics say generalization- it attitude specialization (generalization), in which objects of a specialized element (child) can be substituted for objects of a generalized element (parent, or ancestor).

In the same way that we usually do with classes, after we have identified and described each precedent, we have to look at all of them for the presence of the same actions - to look, and if some actions are performed (used) in common by several use cases. This shared fragment is best described in a separate use case. Thus we will reduce redundancy models through the use of generalization of precedents (sometimes, however, they talk not about generalization, but about use precedents; why - now you will understand). As it is "supposed" in inheritance, instances of generalized precedents (children) retain the behavior inherent in the generalizing precedent (ancestor). In other words, the presence (use) in the use case X generic use case Y tells us that the precedent instance X includesprecedent behavior Y . Generics are used to make it easier to understand the use case model by repeatedly using "blank" use cases to create the use cases that the customer needs (remember how we discussed whether you always need to create a new one). Class, or is it better to use a ready-made solution, do you feel the analogy?). Such "complete" cases are called concrete precedents. "Blanks" of use cases, created only for repeated use in other use cases, are called abstract use cases. Abstract precedent(like abstract class) does not exist itself on itself, but an instance of a concrete use case exhibits the behavior described by the abstract use cases it (re-)uses. Precedent, which the actors observe when interacting with the system ("full" precedent, as we called it before), often referred to as " real" precedent.

As we said above, generalization (inheritance) is most commonly used between classes and interfaces. However, other elements of the model can also be related to each other in relation to inheritance - for example, packages (which we are not talking about here), actors, use cases ...

portrayed generalization, as the attentive reader, of course, remembers, a line with an "unfilled" triangular arrow at the end. Generalization- it attitude between an ancestor and a descendant, and the arrow always points to the ancestor. If we recall that the descendants inherit (use) the properties of the ancestor, then it is quite logical to recall our statement that the arrows in UML always directed towards the one from whom something is required, whose services are used ( rice. 6.9):

Rice. 6.9.

As we said earlier and saw in our first example use case diagrams, generalization can be used to create different types of actors. Descendant actors inherit basic characteristics from the ancestor and supplement them with their own specifics. Similar precedent-descendant inherits the behavior and semantics of the parent use case and complements its behavior.

The next kind of relationship between use cases is inclusion. Attitude inclusion means that at some point in the base use case contains the behavior of another use case. included precedent does not exist on its own on itself, but is only part of the enclosing precedent. So the base precedent as if it borrows the behavior of the included ones, decomposing into simpler precedents. For example, when we buy a certain item in a store, the state is updated at the moment the cashier reads the barcode. Database goods in stock - the number of cash units of the purchased goods is reduced. The same action is performed if the purchased product turned out to be defective, unusable, or we simply didn’t like it: the condition of the mentioned Database updated again - but now in the direction of increasing the number of cash units of a certain product. That is, both of these actions - both the purchase and the return - contain (include) such an action as updating the content DB.

But how is the inclusion depicted? Yes, very simple - like an addiction (dotted line with an arrow, remember?) with a stereotype<> . In this case, the arrow is directed, of course, towards the included precedent. This fact is easy to explain if we recall the statement that we have already used several times in this course: the arrow is always directed towards the element from which something is required, whose services are used. And if we assume that the embracing precedent includes, borrows (uses) the behavior of included cases, it becomes clear that the arrow can only be directed in this way. And here is diagram illustrating the above, which we borrowed from Zicom Mentor ( rice. 6.10):

enlarge image
Rice. 6.10.

As you can clearly see from this example, the use of inclusion avoids repeating the description of the same set of actions - the general behavior can simply be described as a use case included in the base ones.

Next in line - attitude extensions. To understand the meaning of expansion, imagine that we are talking about paying for some product we have bought. We can pay product cash if the amount is less than $100. Or pay by credit card if the amount is between $100 and $1000. If the amount is more than $1000, we will have to take credit. Thus we broaden our understanding operations payment for the purchased goods and in cases where other means of payment than cash are used. But these cases themselves arise only under strictly defined conditions: when the price of the product falls within certain limits.

Extension complements precedent other precedents that "work" under certain conditions - simply adds to the original precedent a sequence of actions contained in another use case. Attitude extensions of use case A to use case B means that an instance of use case B can include (under certain conditions, which can be described in the extension; how exactly described, we will say a little later) the behavior described in use case A. An example is shown in the following diagram ( rice. 6.11):

Rice. 6.11.

However, in the above example, it is not clear under what conditions a person uses each specific payment method. At the same time, when modeling using an extension, you can specify both the conditions for implementing the extended behavior and place - extension point a use case that connects actions from extending use cases. Remember unconditional jump operator, which we hope you don't use very often in your programs. Once interpreter reaches this statement, it transfers control to the line that is marked with the label specified in this statement. True, in the case of an extension, we are talking more about a conditional jump operator - when the original precedent(namely, the sequence of actions contained in it) arrives at the extension point, the extension conditions are evaluated. If the conditions are met, precedent includes the sequence of actions from the extending use case.

The extension point is described in additional section precedent, separated from its name by a horizontal line - in the same way as separate sections list the attributes of a class and its operations. Below is an example of an extension point description that we borrowed from Zicom Mentor ( rice. 6.12).

Rice. 6.12.

In this example registration flight passengers includes control security services, and under the condition (specified in the note after the service word " Condition:") that a person often flies and the cabin is crowded (pay attention to the operator AND, which speaks of the simultaneity of the fulfillment of the conditions), Class ticket can be upgraded, for example, from "economy" to "business class". Moreover, such an upgrade can occur only after the ticket is presented at the check-in counter - this is the extension point. She is described (her name is given) in additional section precedent after the service phrase " Extension points:". Anticipating the reader's question, let's say that precedent can have as many extension points as desired. And match a specific extender precedent with a specific extension point, you can read the extension conditions specified in the comments - the condition itself is written after the service word " Condition:" in curly brackets followed by a service phrase " Extension point:", followed by the name of the extension point. Look again at our example of checking in passengers at the airport and see for yourself that it's all very simple!

Some bewilderment may be caused by the fact that the arrow is always directed towards the expanded precedent. But even this can be easily explained from the point of view of our thesis that "the arrow always points to the one from whom something is demanded": after all, in order to precedent has been extended, it needs to hit the extension point and the conditions are checked, only then the actions contained in the expanding use case can be added to the sequence of actions of the original use case. So everything is correct - the extendable use case requires an extension point and a condition check, which is why the arrow points to it.

Summing up all the above, we can say that extension allows you to model optional system behavior(would be Class ticket upgraded if the passenger had not flown the required number of miles and the cabin was almost empty?). The very fact of the expansion depends on the fulfillment of the conditions - after all, the expansion may not occur! These are simply separate sequences of actions that are performed only under certain circumstances and are included at certain points in the script (usually as a result of explicit interaction with the actor).

Organizing use cases by distinguishing common behavior (inclusion) and different behaviors (extension) is an important part of the process of developing a simple, balanced, and understandable set of use cases. One could even say that the use of inclusion and extension is a sign of good style in use case modeling.

On this, the conversation about the notation of use case diagrams could be completed. I would just like to say a few more words about the relationship between the concepts of precedent and cooperation. We have already talked about cooperation earlier (remember interaction diagrams?) how about multiple roles working together to provide some system behavior. We also mentioned that use cases answer the question "what does the system do?", but do not say exactly how it does it. At the analysis stage, it is really not necessary to understand exactly how the system implements its behavior. But when moving to implementation, it would be nice to know which classes (or other elements of the model), working together, provide the desired behavior. That is, we have logically moved from talking about precedents to talking about cooperation! It is not for nothing that the designations of cooperation and precedent are very similar (the reader, of course, remembers that cooperation denoted by a dotted ellipse) ( rice. 6.13).

Rice. 6.13.

So what is the relationship precedent and cooperation? From the previous paragraph it follows logically that this attitude implementation. Each precedent implemented by one or more collaborations. This, of course, does not mean that the classes are rigidly distributed. on cooperations: classes that take part in a cooperation that implements a certain precedent will participate in other cooperations.

Modeling with Use Case Diagrams

precedent model, on In essence, it is a conceptual model of the system. As we have noted more than once, it describes in general terms only the behavior (functionality) of the system, but does not talk about implementation details - at this stage, the implementation is not important, it is much more important to collect the requirements for the system and arrange them in a clear, understandable form. both developers and customers.

So, summing up, we can formulate three reasons for using precedents. Or, rather, three ways of using precedents (it is no coincidence that in Russian translation one can often find phrase "use case"!) while working on the system:

· Use cases enable analysts, users and developers to speak the same language : using use cases, analysts (domain experts) can, based on the wishes of the customer, describe the behavior of the system from the user's point of view in such a degree of detail that developers can easily construct the "innards" of the system. At the same time, the notation of use case diagrams is so simple that even an unprepared user (customer) is able to understand their meaning and help clarify them - after all, pictures (and even more comics, which, in fact, are UML diagrams) are perceived much easier than text!

· Use cases allow developers to understand the purpose of an element : a system, subsystem or even a class can be complex formations, consisting of a large number of components and having a large number of attributes and operations. Modeling precedents allows you to better imagine the behavior of the system, to understand which elements of the model play which roles in the implementation of this behavior, which cooperations are included, and which particular precedent (system functionality) is implemented.

· Use cases are the basis for testing an element throughout development : the use case model describes the desired behavior of the system (its functionality) from the user's point of view. So, by constantly comparing the (actual) functionality provided by the element with the available use cases, you can reliably control the correctness of the implementation of the element. Here is a reliable source for regression tests. In addition, the emergence of a new use case often forces us to rethink the implementation of an element to ensure that it is sufficiently flexible, mutable, and scalable.

Use cases are useful for both forward and reverse engineering. In direct design, we on in fact, we carry out a "translation" from UML for some programming language. And test the created Appendix follows, based precisely on the flows of events described by precedents. reverse engineering involves translation from a programming language into a language UML-diagrams. These things have to be done for a number of reasons:

· In order to find errors and to make sure the design is adequate :

It's a great idea after the first translation from UML to a programming language to do a reverse translation and compare the original and restored UML models (it is desirable that these translations are performed by different teams). This will make sure that the design of the system matches the model, no information was lost during the translation, and simply catch some "bugs". This approach is called reverse semantic tracing (or RST - Reverse Semantic Traceability) and is being developed by INTSPEI ( http://www.intspei.com ) as one of the basic techniques of the INTSPEI P-Modeling Framework methodology, a summary of which you can find in the appendix to this course.

· When there is no documentation : sometimes the task is to modify an existing system, the code of which is poorly documented. In this case, translating from a programming language into a UML diagram language is a great way to understand the purpose of the system and its parts, the functionality it provides, etc.

And finally, it should be noted that, of course, use case diagrams alone, as well as the scenarios they define, are not enough to create a model of system behavior. As we've mentioned before, use cases tell what the system does, but they don't say how. The scripts say this, but in textual form, which makes them quite difficult to read. Charts come to the rescue interactions that visualize scenarios. Thus, we can now supplement our old "pseudo-diagram" and calm down on this ( rice. 6.14):

Rice. 6.14.

We conclude with a couple of examples of completed use case diagrams. The first example (whose meaning is clear without further explanation) demonstrates the inclusion, extension and inheritance precedents. Pay attention to the arrows that are directed to the actors representing the gateways. That's right - after all, the system uses their services when sending messages, while the marketer, on the contrary, uses the services of the system, and therefore the arrows are directed away from him ( rice. 6.15

Rice. 6.16.

Second diagram, also well designed, tells us that ducks really don’t like to pay for beer, preferring to drink on credit ( rice. 6.17).

Rice. 6.17.

By the way, pay attention to the chart boxes shown in this example - rectangle A that separates the chart's content area and has a dedicated section at the top for its name.

And finally, the third picture, which is not a good example use case diagrams but just funny. This is a story about behaviors that allow you to fail any exam (!) rice. 6.18):

Rice. 6.18.

conclusions

· The use case model allows you to describe the system at a conceptual level.

· Use Case Diagrams - an excellent means of communication between experts, users and developers, as well as the basis for testing the system being created.

· A use case is a description of a set of successive events (including possible variants) performed by the system that lead to the result observed by the actor.

· An actor is a set of roles that a user performs in the course of interacting with some entity.

· Precedents (like actors) can be generalized, i.e., inherit and supplement the properties of their ancestors.

· Use cases can also enter into inclusion and extension relationships with each other, which allows you to decompose use cases into simpler components and highlight optional behavior.

· Each use case is implemented by one or more collaborations.

· Scenarios specify use cases, and interaction diagrams visualize scenarios.

Control questions

· What are non-functional requirements? How do they appear in use case diagrams?

· What ways of representing actors do you know?

· What relationships can actors have with each other?

· What is the meaning of the inclusion and extension relations?

· What is an extension point?

· List the reasons you know for using precedents.

· How are use cases applied in forward and reverse engineering?

The following notes will be useful to beginning business analysts, systems analysts, and students.

What is Use Case

At an interview, you can sometimes hear the following definition: “This is such a UML diagram with men and ovals.” Let's understand what it is and look at some simple examples.

Use Case describes the interaction scenario of the participants (as a rule, the user and the system). Participants can be 2 or more. The user can be either a person or another system.

I like the definition from Coburn's book (I advise it, by the way, to all analysts): “A use case fixes an agreement between participants in a system about its behavior. A use case describes the behavior of the system as it responds to a request from one of the participants, called the main actor, under various conditions.

In my life I met such names: use cases, use case, scenario, use case, use case.

Text vs Diagram/Scheme

Which description is better: text or diagram? The choice is yours and your team's. In the first years of my work, I used diagrams or diagrams + text descriptions for them. For now, I prefer textual scripting, and I'll explain why:

• This format is more understandable to customers (and they also prefer to read and agree on use cases).
• Text is easier and faster to edit than charts and text.

Of course, if additional benefits from using diagrams are obvious in your project, you should use them.

Who and in what cases need scripts

- Developers. It is very convenient when a branching requirement is described using the main and alternate flow of events. Everything is clear and understandable: who, when and what causes, and what is the result. In my last project, the manager professed an approach: a minimum of descriptions, a maximum of communication. But for several complex scenarios, the developers themselves asked for a detailed description, and the use cases fit perfectly.

- Customers. Described in human language, the customer can confirm in a timely manner that this is exactly what he is waiting for, or correct it.

- Tester. Almost ready test case :-)

- All project team. If a scenario needs to be agreed upon, and at each meeting a couple of alternative scenarios sound different, a strictly described flow of events will help.

As well as other participants in the process.

When are they needed:

If you need a high-quality, complete specification of requirements - use cases will perfectly help with this. There are such systems for the development and support of which a requirements specification containing a data model, interface description, integration with other systems and use cases is a very good option.

To support the system. To identify the error, figure out at what step what went wrong.

If you need to describe some part of the functionality, how the user interacts with the interface, etc. in the form of a script. Then you can take the use case template as a basis and use it to describe the scenario. For example, the basis of the requirements for your mobile application is the description of the user interface. But the execution of some functions has many nuances that need to be additionally described using a sign: “action - system response”, or even combine such a sign with a script.

How to describe them

Let's look at a couple of examples, they speak for themselves.

Example 1 Unlock user account (simple short example, no alternative event flow):

Characters	User, System
Goals	User: log in to the system and start working; System: identify the user and his rights.
Success scenario: The user starts the system. The system opens a user session, prompts you to enter a username and password. The user enters a username and password. The system checks the username and password. The system creates an entry in the authorization history (user IP address, login, date, workstation). The system gives the user a message about successful authorization ( link to message).
Result	The user is successfully authorized and can work with the system.
Extensions:
*a	No access to the database. The system displays a message ( link to message). Result: User cannot login.
1a	In the security settings for this IP address there is a ban on entering the system. Result: no login form is provided, the system issues a message to the user ( link to message).
2a	The user selects: "Remind password". The "Remind password" script is called.
3a	The user with the entered login and password was not found. Result: authorization denied. The system displays a message ( link to message). Go to step 2.
3b	The number of unsuccessful login attempts has reached the maximum set in the settings. Result: User cannot login. A message is displayed: ( link to message). Login from the User's IP address is blocked for the time set in the settings.

Important Points

Obviously, if Example 1 could be painlessly described in plain text, then Example 2 is much better perceived as a script. But if you have all the functionality described in the form of use cases, then it is better to use use cases to describe even very simple scenarios, from a couple of steps. Let your specification be in the same style.

Use the minimum number of words and paragraphs necessary to unambiguously understand the script. If a user case is too long, it may be better to split it into several. It is extremely inconvenient to work with very long scripts, with a large number of extensions.

If two or more scenarios repeat the same set of steps, it makes sense to move these steps into a separate scenario and refer to them. The document will be lighter. And if something changes in these steps, it will be enough to change in one place.

List of messages that the system issues to the user, standard texts of e-mails, etc. conveniently placed in a single place in the document, and refer to the desired item from different use cases, because messages in scripts are often duplicated.

Re-read the script document before giving it to developers or customers. Better even several times. There are always moments that can be described more concisely, or some inconsistencies come to light. Or random "copy-pastes". Respect other people's time and heads.

By the way, about "copy-paste". It makes sense to “copy-paste” an empty plate to describe the use case.

As you can see from the examples above, the extension to step number 1 is indicated in the Extension section as 1a, 1b, etc. The *a extension is a general script extension, not a specific one.

Correct and useful scripts for you! Questions, examples, suggestions, comments are welcome. Thank you for your attention.

When writing this article, I used materials from Alistair Coburn's book "Modern Methods for Describing Functional Requirements for Systems".

Precedent - the possibility of a simulated system (part of its functionality), thanks to which the user can get a specific, measurable and desired result. A use case corresponds to a particular service of the system, defines one of the options for its use, and describes a typical way of user interaction with the system. Use cases are typically used to specify external requirements for a system.

Purpose

The main purpose of the diagram is to describe the functionality and behavior, allowing the customer, end user and developer to jointly discuss the designed or existing system.

When modeling a system using a use case diagram, the systems analyst aims to:

• clearly separate the system from its environment;
• determine the actors (actors), their interaction with the system and the expected functionality of the system;
• define in the glossary of the subject area the concepts related to the detailed description of the functionality of the system (i.e., use cases).

Work on the diagram can begin with a textual description obtained while working with the customer. At the same time, non-functional requirements (for example, a specific language or programming system) are omitted when compiling the precedent model (another document is compiled for them).

Elements

To reflect the use case model in the diagram, the following are used:

Relationships Between Use Cases

Some of the duplicate information in the case model can be eliminated by specifying links between cases:

• precedent generalization - an arrow with an unfilled triangle (a triangle is placed at a more general precedent),
• inclusion of precedent - dashed arrow with "include" stereotype,
• precedent expansion - dotted arrow with the "extend" stereotype (the arrow is included in an expandable use case, in the additional section of which extension point and, possibly as a comment, an expansion condition)

Rules

When working with use cases, it is important to remember a few simple rules:

• each use case refers to at least one actor;
• each use case has an initiator;
• each use case leads to a corresponding result.

Write a review on "Use Case Diagram"

Notes

Programming

This article about programming is a stub. You can help the project by adding to it.

View this template Actors Other Concepts Structure Behavior Relationship Extensibility Diagrams Structural behavior Interactions

An excerpt characterizing the Case Diagram

“Forgive my indiscretion, Your Holiness, but, in order to avoid a mistake on my part, would you kindly explain to me more precisely what you wanted to say by this?” I answered very cautiously.
Caraffa smiled softly and, taking my trembling hand in his graceful, thin fingers, said very quietly:
– You are the first woman on earth, Madonna Isidora, who, in my opinion, is worthy of true love... And you are a very interesting interlocutor. Don't you think that your place is rather on the throne than in the prison of the Inquisition?.. Think about it, Isidora. I offer you my friendship, nothing more. But my friendship is worth a lot, believe me... And I would really like to prove it to you. But everything will depend on your decision, of course ... - and, to my greatest surprise, he added: - You can stay here until the evening if you want to read something; I think you will find a lot of interesting things here. Ring the bell when you're done and your maid will show you the way back.
Caraffa was calm and restrained, which spoke of his complete confidence in his victory ... He did not even for a moment allow the thought that I could refuse such an “interesting” offer ... And especially in my hopeless situation. But this was precisely what was most frightening ... Since, of course, I was going to refuse him. I just don't have the slightest idea how to do it...
I looked around – the room was amazing!.. Starting from hand-sewn bindings of the oldest books, to papyri and manuscripts on ox skin, and to later, already printed books, this library was a storehouse of world wisdom, a real triumph of ingenious human Thought!!! It was, apparently, the most valuable library that a person has ever seen! .. I stood completely stunned, fascinated by the thousands of volumes “speaking” to me, and could not understand how this wealth could get along here with those curses that such an Inquisition so vehemently and “sincerely” poured on them?... After all, for real inquisitors, all these books should have been the purest HERESY, for which people burned at the stake, and which was categorically forbidden as the worst crime against the church! .. How, then, here, in the cellars of the Pope, all these most valuable books were preserved, which, allegedly, in the name of “redemption and purification of souls”, to the last leaf, were burned in the squares?! .. So, everything that the “fathers” said inquisitors”, everything they did was just a terrible veiled LIE! And this ruthless lie deeply and firmly sat in simple and open, naive and believing human hearts!.. Just think that I was once absolutely sure that the church was sincere in its faith!.. she did not seem strange, for me she always embodied the sincere spirit and faith of a person in something pure and high, to which, in the name of salvation, his soul aspired. I have never been a "believer" as I believed exclusively in Knowledge. But I have always respected the beliefs of others, because, in my opinion, a person had the right to choose for himself where to direct his fate, and someone else's will should not have forced him to indicate how he should have lived his life. Now I clearly saw that I was mistaken ... The Church lied, killed and raped, not taking into account such a “trifle” as a wounded and distorted human soul ...
No matter how captivated I was by what I saw, it was time to return to reality, which, unfortunately, at that moment did not represent anything comforting for me ...
The Holy Father of the Church, Giovanni Pietro Caraffa loved me!.. Oh, gods, how he must have hated me for that!!! And how much stronger his hatred will become when he soon hears my answer...
I couldn't understand this man. Although, before him, almost any human soul was an open book for me, in which I could always read freely. He was completely unpredictable, and it was impossible to catch the subtlest changes in his moods, which could lead to terrible consequences. I didn't know how much longer I could hold out, and I didn't know how long he intended to put up with me. My life was completely dependent on this fanatical and cruel Pope, but I knew only one thing - I did not intend to lie. Which meant I didn't have much life left...