2.1.1 Model of information streams in information (telecommunication) system and its description
StarUML is a free, Windows-based UML tool used for creating diagrams related to application design. There are many different kinds of diagrams that UML support, but our focus here will be on Class Diagrams. Class diagrams represent the structure of a collection of classes by showing both how they're defined (inheritance hierarchy) and how they relate to one another (associations).
By creating a class diagram before you even begin writing a single line of code, you can place focus on one of the more important aspects of an application, it's interface and design. Once you have that defined, implementation becomes a lot simpler and smoother to incorporate. Additionally, UML can be used to create class skeleton files for you. Most UML tools, including StarUML, support an export to a programming language's source code.
StarUML can export to a number of different programming languages out of the box but does not support ActionScript natively. Instead, a custom export script is required to supply that functionality. This tutorial will cover the use of StarUML to export UML class diagrams to ActionScript 3.0 source code using a custom export script [21].
2.1.2 General provisions (function tree and dialogue scenario)
Develop of the flash game, consisting of the following sections:
Design
Program code
My game consists of 11 levels, made with hypertext markup, animated graphics and audio files (каз.swf, registration.swf and КзХан.swf):
The introduction
Registration
Button history
Map
Preloader
Game
Congratulations
The introduction (see figure 2.1):
Figure 2.1 - Introduction
Registration (see figure 2.2):
Figure 2.2 – Registration
Button history (see figure 2.3, figure 2.4, figure 2.5, figure 2.6, figure 2.7, figure 2.8, figure 2.9, figure 2.10, figure 2.11):
Figure 2.3 – Zhanibek, Kerei
Figure 2.4 – Koterui
Figure 2.5 – Hans
Figure 2.6 – Buryndyk
Figure 2.7 – Prezident
Figure 2.8 – Tomiris
Figure 2.9 – Handygy
Figure 2.10 – Khanate
Figure 2.11 – Otrar
Map (see figure 2.12, figure 2.13):
Figure 2.12 – map
Figure 2.13 – Animated map
Preloader (see figure 2.14):
Figure 2.14 – Preloader
Game (see figure 2.15, figure 2.16, figure 2.17, figure 2.18, figure 2.19):
Figure 2.15 – Play
Figure 2.16 – Wave1
Figure 2.17 – Wave2
Figure 2.18 – Wave3
Figure 2.19 – Wave5
Congratulations (see figure 2.20):
Figure 2.20 - Win
2.1.3 Physical scheme of interaction between different parts of the designed information (telecommunication) system
Use Case Diagrams describe the relationships and dependencies between a group of Use Cases and the Actors participating in the process.
It is important to notice that Use Case Diagrams are not suited to represent the design, and cannot describe the internals of a system. Use Case Diagrams are meant to facilitate the communication with the future users of the system, and with the customer, and are specially helpful to determine the required features the system is to have. Use Case Diagrams tell, what the system should do but do not — and cannot — specify how this is to be achieved.
A Use Case describes — from the point of view of the actors — a group of activities in a system that produces a concrete, tangible result.
Use Cases are descriptions of the typical interactions between the users of a system and the system itself. They represent the external interface of the system and specify a form of requirements of what the system has to do (remember, only what, not how).
When working with Use Cases, it is important to remember some simple rules:
Each Use Case is related to at least one actor
Each Use Case has an initiator (i.e. an actor)
Each Use Case leads to a relevant result (a result with “business value”)
Use Cases can also have relationships with other Use Cases. The three most typical types of relationships between Use Cases are:
<<include>> which specifies that a Use Case takes place inside another Use Case
<<extends>> which specifies that in certain situations, or at some point (called an extension point) a Use Case will be extended by another.
Generalization specifies that a Use Case inherits the characteristics of the “Super”-Use Case, and can override some of them or add new ones in a similar way as the inheritance between classes.
An actor is an external entity (outside of the system) that interacts with the system by participating (and often initiating) a Use Case. Actors can be in real life people (for example users of the system), other computer systems or external events [22] (see figure 2.21).
