Object-oriented modeling of information systems. Object-oriented approach to system modeling. Creating a Class Diagram

· Procedural languages, which represent a sequence of statements to be executed. If we consider the state of a PC as the state of memory cells, then a procedural language is a sequence of operators that change the value of one or more cells. Procedural languages ​​include FORTRAN, C, Ada, Pascal, Smalltalk and some others. Procedural languages ​​are sometimes also called imperative languages. The program code in a procedural language can be written as follows:

operator1; operator2; operator3;

· Applicative languages, which are based on functional approach. The language is considered from the point of view of finding the function necessary to transfer the PC memory from one state to another. A program is a set of functions applied to initial data to obtain the desired result. LISP is an applicative language. The program code in applicative language can be written as follows:

function1(function2(

· function3(beginning_date)));

· Rule system languages, also called logic programming languages, are based on defining a set of rules that, when followed, make it possible to perform certain actions. Rules can be specified in the form of statements and in the form of decision tables. Logic programming languages ​​include Prolog.

The program code in the language of the rules system can be written as follows:

if condition1 then operator1;

if condition2 then operator2;

if condition3 then operator3;

· Object-oriented languages, based on the construction of objects as a set of data and operations on them. Object-oriented languages ​​combine and extend the capabilities of procedural and applicative languages. Object-oriented languages ​​include C++, Object Pascal, Java.

Currently, languages ​​based on the object-oriented model are most widespread. They, implementing the procedural model of language construction, support the applicative nature of constructions, making it possible to represent the block diagram of the execution of a structured program as a certain set of applicative functions.

Software is a set of application programs with the help of which specific tasks are performed: production, creative, entertainment, etc.

Classification of PP funds

Text editors- their main functions are entering and editing text data.

Graphic editor- an extensive class of programs designed for creating and processing graphic images.

Modelvisual, if it allows you to visualize the relationships and connections of the modeled system, especially in dynamics .

Modelfull-scale, if it is a material copy of the original .

Modelgeometric, if it can be represented by geometric images and the relationships between them.

Modelimitation, if it is built for testing or studying, playing possible ways development and behavior of an object by varying some or all parameters of the model .

There are other types of models.

Examples of models

Algorithmic model calculating the sum of an infinite decreasing series of numbers can be used as a calculation algorithm final amount series to some given degree of accuracy.

Spelling rules - linguistic, structural model. Globe is a full-scale geographical model of the globe. A house model is a full-scale geometric model of a house under construction. A polygon inscribed in a circle gives a visual geometric model of the circle on a computer screen.

The type of model depends on the connections and relationships of its subsystems and elements, environment, and not on its physical nature.

Basic properties of any model:

· focus;

limb;

· simplification;

· approximate;

· adequacy;

· information content;

· completeness;

· isolation, etc.

Modern modeling of complex processes and phenomena is impossible without a computer, without computer modeling.

Computer modelling- the basis for the representation of knowledge both in a computer and with the help of a computer and using any information that can be processed using a computer.

A type of computer modeling is a computational experiment carried out by an experimenter on the system or process under study using an experimental instrument - a computer, computer technology. A computational experiment allows you to find new patterns, test hypotheses, visualize events, etc.

Computer modeling from beginning to completion goes through the following stages.

1. Statement of the problem.

2. Pre-model analysis.

3. Analysis of the task.

4. Study of the model.

5. Programming, program design.

6. Testing and debugging.

7. Simulation evaluation.

8. Documentation.

9. Escort.

10. Use (application) of the model.

When modeling software systems, there are two approaches: structural modeling and object-oriented modeling. Each of these approaches uses its own methods and means. The modeling language should include: model elements, i.e. functional modeling concepts and their semantics, notation, i.e. visual representation of modeling elements and instructions for use. Modeling tools are widely used, calledCase-by means.Case-a tool is a technology for using and operating software systems. Case-a tool is a software tool that supports processes life cycle BY. The life cycle of any software is the period of time from making a decision about the need to create software until the software is removed from service. All software life cycle processes are divided into three groups: main (5), auxiliary (8), organizational (4). The standard (ISO/IEC 12207) is used to develop life cycle models. The software creation stage is a part of the software creation process, limited by a time frame and ending with the release of a specific product (model, program or documentation). The software lifecycle includes stages:

1. Formation of software requirements

2. Design

3. Implementation

4. Testing

5. Commissioning

6. Operation and maintenance

7. Decommissioning.

The essence of the structural approach to software development lies in its decomposition into automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions, those into tasks, etc. to specific procedures. All components of the automated system are interconnected. The structural approach uses two groups of tools that describe the functional structure of the system and the relationships between data. Each group of funds corresponds to certain types of models, the most common among them:

DFD – Data Flow Diagram– the main means of modeling functional requirements for the system being designed. System requirements are presented as a hierarchy of functional components (processes) connected by data flows. the main objective Such a representation is to show how each process transforms its inputs into outputs, as well as to identify the relationships between these processes. The main components of a data flow diagram are external entities, systems and subsystems, processes, data stores and data flows.

SADT – structural analysis and design method– a set of rules and procedures designed to build a functional model of an object in a particular subject area. The SADT functional model displays functional structure object, i.e. the actions performed by the object and the connections between them.

ERD – Entity – Relationship Diagrams. This is the most common means of modeling data that will be mapped to a database during the design and implementation process. Basic concepts of this modeling tool are: entity, relationship and attribute.

The fundamental difference between the structural and object-oriented approaches when modeling software systems lies in the method of decomposition of the system. The object-oriented approach uses object decomposition. In this case, the static structure of the system is described using objects and connections between them , and the behavior of system objects is described messages , which objects exchange with each other. Basis object-oriented approach is object model . The elements (properties) of this model are:, abstraction, encapsulation, modularity, hierarchy

typing, parallelism, stability. Abstraction

is the process of identifying the basic characteristics of an entity that distinguish it from other entities. Encapsulation is the process of separating from each other the individual elements of an object that determine the structure and behavior of the object. Encapsulation serves to isolate the interface of an object that reflects external behavior

object from its internal implementation. Modularity

is a property of a system associated with the possibility of its decomposition into a number of internally coherent, but weakly interconnected modules. Hierarchy

is the ranking or ordering of a system of abstractions. Types of hierarchical structures are class structure and object structure. Typing – this is a restriction that is imposed on a class of objects; it prevents interchangeability.

various classes Parallelism

– this is the property of objects to be in an active or passive state and to distinguish active and passive objects from each other. Sustainability

– the property of an object to exist in time and/or space. Basic Concepts , used in object-oriented modeling:.

object and class An object is an object or phenomenon that has a clearly defined behavior. Class is a set of objects that have general structure and behavior. An object is an instance of a class. Important concepts in object-oriented modeling are. polymorphism and inheritance Polymorphism is the ability of a class to belong to more than one type.- this is the construction of new classes based on existing ones, while you can add or redefine data and methods.

Modeling languages

A visual modeling language is a formal language that has a graphical notation, a language designed for visual modeling and specification of software and hardware.

VRML – a formal language for creating 3D images . In 1994, the VRML language was created to organize virtual three-dimensional interfaces on the Internet. It allows you to describe in text form various three-dimensional scenes, lighting and shadows, textures (coatings of objects), create your own worlds, travel through them, “fly around” from all sides, rotate in any direction, scale, adjust

Unified Modeling Language UML is a formal visual modeling language that is intended for designing and building models of complex software systems.

Object-oriented programming

One of the alternatives to directive (imperative) programming is object-oriented programming, which really helps to cope with the nonlinearly growing complexity of programs as their volume increases.

Basic OOP Concepts

(the basic ideas of object-oriented design and object-oriented programming are the same, since the developed project is implemented in one of the object-oriented programming languages)

Object-oriented programming or OOP is a programming methodology based on representing a program as a collection of objects, each of which is an implementation of a certain type, using a message passing mechanism and classes organized in an inheritance hierarchy.

The central element of OOP is abstraction. Data using abstraction are transformed into objects, and the sequence of processing this data turns into a set of messages transmitted between these objects. Each of the objects has its own unique behavior. Objects can be treated as concrete entities that respond to messages commanding them to perform some action.

OOP is characterized by the following principles (according to Alan Kay):

· everything is an object;

· calculations are carried out through interaction (data exchange) between objects, in which one object requires another object to perform some action; objects interact by sending and receiving messages; a message is a request to perform an action, supplemented by a set of arguments that may be needed when performing the action;

Each object has an independent memory, which consists of other objects;

· each object is a representative of a class that expresses the general properties of objects of a given type;

· in class it is set functionality(object behavior); thus, all objects that are instances of the same class can perform the same actions;

· classes are organized into a single tree structure with a common root, called an inheritance hierarchy; the memory and behavior associated with instances of a particular class are automatically available to any class lower in the hierarchical tree.

Abstraction(abstraction) - a method of solving a problem in which objects of various kinds are united by a common concept (concept), and then the grouped entities are considered as elements of a single category.

Abstraction allows you to separate the logical meaning of a program fragment from the problem of its implementation, dividing external description(interface) of an object and its internal organization (implementation).

is the process of identifying the basic characteristics of an entity that distinguish it from other entities.(encapsulation) is a technique in which information that is unimportant from the point of view of the object’s interface is hidden inside it.

is the ability of a class to belong to more than one type.(inheritance) - a property of objects through which instances of a class gain access to the data and methods of ancestor classes without redefining them.

Inheritance allows different data types to share the same code, resulting in smaller code and greater functionality.

polymorphism and inheritance(polymorphism) - a property that allows you to use the same interface for different actions; a polymorphic variable, for example, can correspond to several different methods.

Polymorphism rearranges the general code that implements an interface to suit the specific characteristics of individual data types.

is an object or phenomenon that has a clearly defined behavior.(class) - a set of objects related by common structure and behavior; an abstract description of data and behavior (methods) for a collection of similar objects, the representatives of which are called instances of a class.

object and class(object) is a concrete implementation of a class that has state, behavior, and personality characteristics, synonymous with instance.

In an object-oriented approach, a program is a description of objects, their properties (or attributes), collections (or classes), relationships between them, ways of their interaction and operations on objects (or methods). The main concepts that characterize object-oriented programming are inheritance (preservation of the properties of base objects by derived objects) and encapsulation (isolation of object definitions from methods for managing them), as well as the already mentioned concept of polymorphism

Basics of Graphical Data Presentation

Types of computer graphics

There is a special field of computer science that studies methods and means of creating and processing images using software and hardware computing systems - computer graphics . It covers all types and forms of representation of images accessible to human perception either on a monitor screen or in the form of a copy on external media(paper, film, fabric, etc.). Types of computer graphics: printing, 2D graphics, 3D graphics and animation, CAD and business graphics, Web design, multimedia, video editing.

Depending on the method of image formation, 2D computer graphics are usually divided into raster, vector and fractal.

A separate item is considered three-dimensional (3D) graphics, studying techniques and methods for constructing three-dimensional models of objects in virtual space. As a rule, it combines vector and raster methods of image generation.

Features of the color gamut characterize the following concepts: both black and white and color graphics. The titles of some sections indicate specialization in individual areas: engineering graphics, scientific graphics, Web graphics, computer printing and others.

At the intersection of computer, television and film technologies, a comparatively new area computer graphics and animation.

Although computer graphics serves only as a tool, its structure and methods are based on the advanced achievements of fundamental and applied sciences: mathematics, physics, chemistry, biology, statistics, programming and many others. This remark is true for both software and hardware for creating and processing images on a computer. Therefore, computer graphics is one of the most rapidly developing branches of computer science and in many cases acts as a “locomotive” pulling the entire computer industry along with it.

Raster graphics	Vector graphics
3D graphics	Engineering graphics

Raster graphics

For raster images consisting of dots, the concept is of particular importance permissions, expressing the number of points per unit length. It is necessary to distinguish between:

Original resolution;

Screen resolution;

Resolution of the printed image.

Original resolution. Original resolution is measured in dpi (dots per inch - dpi) and depends on the requirements for image quality and file size, the digitization method or the method of creating the original illustration, chosen format file and other parameters. In general, the rule applies: the higher the quality requirements, the higher the resolution of the original should be.

Screen resolution. For screen copies of an image, the elementary raster point is usually called pixel. Pixel size varies depending on the selected screen resolution(from the range of standard values), original resolution and display scale.

Monitors for processing images with a diagonal of 20-21 inches (professional class), as a rule, provide standard screen resolutions 640x480, 800x600, 1024x768, 1280x1024, 1600x1200, 1600x1280, 1920x1200, 1920x1600 points. The distance between adjacent phosphor points on a high-quality monitor is 0.22-0.25 mm.

A resolution of 72 dpi is sufficient for a screen copy, 150-200 dpi for printing on a color or laser printer, and 200-300 dpi for output on a photo exposure device. A rule of thumb has been established that when printing, the resolution of the original should be 1.5 times greater than raster lineature output devices. In case the hard copy will be enlarged compared to the original, these values ​​should be multiplied by the scaling factor.

Permission printed image and the concept of lineature. The dot size of a raster image both on a hard copy (paper, film, etc.) and on the screen depends on the method and parameters used rasterization original. When rasterizing, a grid of lines is superimposed on the original, the cells of which form raster element. The raster grid frequency is measured by the number lines per inch(lines per inch - Ipi) and is called lineature.

The raster dot size is calculated for each element and depends on the tone intensity in a given cell. The higher the intensity, the denser the raster element is filled. That is, if the cell contains absolutely black color, the size of the raster point will coincide with the size of the raster element. In this case, they talk about 100% occupancy. For absolutely white the occupancy value will be 0%. In practice, element occupancy on a print usually ranges from 3 to 98%. In this case, all raster points have the same optical density, ideally approaching absolute black. The illusion of a darker tone is created by increasing the size of the dots and, as a result, reducing the white space between them with the same distance between the centers of the raster elements (Fig. 1). This method is called rasterization amplitude modulation (AM).

Printing equipment" href="/text/category/poligraficheskoe_oborudovanie/" rel="bookmark">printing equipment; it is used mainly for artistic work, when printing with more than four colors.

Fig.2. Example of using a stochastic raster

The relationship between image parameters and file size. It is customary to use raster graphics to illustrate works that require high precision in the reproduction of colors and halftones. However, raster illustration file sizes grow rapidly as resolution increases. A photograph intended for home viewing (standard size 10x15 cm, digitized with a resolution of 200-300 dpi, color resolution 24 bits), takes up TIFF format with compression mode enabled, about 4 MB. Digitized from high resolution the slide takes 45-50 MB. A separated color image in A4 format occupies 120-150 MB.

Scaling raster images. One of the disadvantages of raster graphics is the so-called pixelation images when enlarged (unless special measures are taken). Since the original contains a certain number of dots, then with a larger scale their size increases and raster elements become noticeable, which distorts the illustration itself (Figure 3). To counteract pixelation, it is customary to digitize the original in advance with a resolution sufficient for high-quality visualization when scaling. Another technique is to use a stochastic raster to reduce the pixelation effect within certain limits. Finally, when scaling, the interpolation method is used, when the size of the illustration increases not by scaling the points, but by adding the required number of intermediate points. When scaling raster graphics, there may be loss in the image.

Fig.3. Pixelation effect when scaling a bitmap

Vector graphics

If in raster graphics basic element image is a point, then in vector graphics - line. A line is described mathematically as a single object, and therefore the amount of data to display an object using vector graphics is significantly less than in raster graphics.

Line - elementary an object vector graphics. Like any object, a line has properties: shape (straight, curve), thickness, color, style (solid, dotted). Closed lines acquire the property filling. The space they cover can be filled with other objects ( textures, maps) or the selected color.

The simplest open line is bounded by two points called nodes. Nodes also have properties whose parameters affect the shape of the end of the line and the nature of its connection to other objects.

All other vector graphics objects are made up of lines. For example, a cube can be composed of six connected rectangles, each of which, in turn, is formed by four connected lines. It is also possible to imagine a cube as twelve connected lines forming edges.

Rice. 4. Vector graphics objects

Mathematical foundations of vector graphics

Let's take a closer look at the presentation methods various objects in vector graphics.

Dot. This object on the plane is represented by two numbers (x, y), indicating its position relative to the origin.

Straight line. It corresponds to the equation y = kx + b. By specifying the parameters k and b, you can always display an infinite straight line in a known coordinate system, that is, two parameters are enough to specify a straight line.

Straight segment. It differs in that it requires two more parameters for description - for example, coordinates x1 and x2 of the beginning and end of the segment.

Second order curve. This class of curves includes parabolas, hyperbolas, ellipses, circles, that is, all lines whose equations contain degrees no higher than two. A second order curve has no inflection points. Straight lines are just a special case of second-order curves. Second order curve formula in general view might look like this, for example:

x2+a1y2+a2xy+a3x+a4y+a5 = 0.

Thus, to describe an infinite second-order curve, five is sufficient; parameters. If you want to plot a curve segment, you will need two more parameters.

Third order curve. The difference between these curves and second-order curves is the possible presence of an inflection point. For example, the graph of the function y = x3 has an inflection point at the origin (Fig. 15.5). It is this feature that makes it possible to make third-order curves the basis for displaying natural objects in vector graphics. For example, the bending lines of the human body are very close to third-order curves. All second-order curves, like straight lines, are special cases of third-order curves.

In general, the equation of a third-order curve can be written as follows:

x3 + a1y3 + a2x2y + a3xy2 + a4x2 + a5y2 + a6xy + a7x + a8y + a9 = 0

Thus, a third-order curve is described by nine parameters. The description of its segment will require two more parameters.

Fig.5. Third order curve (left) and Bezier curve (right)

Bezier curves. This is a special, simplified form of third-order curves (see Fig. 5). Method for constructing a Bezier curve ( Bezier) is based on the use of a pair of tangents drawn to a line segment at its ends. Bezier curve segments are described by eight parameters, so it is more convenient to work with them. The shape of the line is affected by the angle of the tangent and the length of its segment. Thus, the tangents play the role of virtual “levers” with which the curve is controlled.

You can use Bezier curve segments to approximate an arbitrarily complex contour. Along with the line, another basic element of vector graphics is the node (anchor point). Lines and nodes are used to create outlines. Each circuit has several nodes. The shape of the contours in vector editors changes by manipulating nodes. This can be done by one of following methods: moving nodes, changing node properties, adding or removing nodes. All procedures related to editing contours are based on working with nodes. When you select a node point of a curved segment, it will have one or two control points connected to the node point by tangent lines. Control points are depicted as black filled dots. The placement of tangent lines and control points determines the length and shape of the curved segment, and moving them changes the shape of the path.

The concept of an object-oriented approach (OOP) OOP OOP is an approach that uses object decomposition In OOP, the static structure of a system is described in terms of objects and relationships between them Dynamic structure object is described in terms of message exchange between objects. What distinguishes OOP from the structural approach is the method of system decomposition

Object An object is a tangible reality that has clearly defined behavior. An object has a state, behavior, and personality. The structure and behavior of similar objects determine their common class => Object = class instance Object = instance of a class"> Object = instance of a class"> Object = instance of a class" title="Object An object is a tangible reality that has a clearly defined behavior. An object has a state, behavior, individuality. The structure and behavior of similar objects determine the common them class => Object = class instance"> title="Object An object is a tangible reality that has clearly defined behavior. An object has a state, behavior, and personality. The structure and behavior of similar objects determine their common class => Object = class instance"> !}

Properties of an object State of an object - a list of all possible (static) properties of an object and the current (dynamic) values ​​of each of these properties Behavior - the impact of an object on another object and vice versa, as well as the relative change in the states of these objects and the transmission of messages between them Individuality is a property of an object , distinguishing it from other objects

Difference between a class and an object A set of objects with similar properties (state, behavior, personality) = CLASS => Each object = an instance of a class Every object = an instance of a class"> Every object = an instance of a class"> Every object = an instance of a class" title="Difference between a class and an object A set of objects with similar properties (state, behavior, personality) = CLASS => Every object = class instance"> title="Difference between a class and an object A set of objects with similar properties (state, behavior, personality) = CLASS => Each object = an instance of a class"> !}

Class hierarchy: Parent class has fi" title="Principles of OOP. Inheritance Inheritance is the principle according to which knowledge about a more general category is allowed to be applied to a more specific category Inheritance class hierarchy Inheritance -> class hierarchy: The parent class has fi" class="link_thumb"> 7 !} OOP principles. Inheritance Inheritance is the principle according to which knowledge about a more general category is allowed to be applied to a more specific category Inheritance class hierarchy Inheritance -> class hierarchy: The parent class has a fixed set of properties => the class derived from it contains the same set of properties + additional properties that characterize its uniqueness class hierarchy: The parent class has phi"> class hierarchy: The parent class has a fixed set of properties => the class derived from it contains the same set of properties + additional properties that characterize its uniqueness"> class hierarchy: The parent class has phi" title="( !LANG: Principles of OOP Inheritance Inheritance is the principle according to which knowledge about a more general category is allowed to be applied to a more specific category Inheritance class hierarchy Inheritance -> class hierarchy: The parent class has fi"> title="OOP principles. Inheritance Inheritance is the principle according to which knowledge about a more general category is allowed to be applied to a more specific category Inheritance class hierarchy Inheritance -> class hierarchy: The parent class has fi"> !}

OOP principles. Encapsulation Encapsulation is the hiding of individual parts internal structure classes from objects or users external to it. Encapsulation originates from the division of modules into 2 parts: interface and implementation.

OOP principles. Polymorphism Polymorphism (Greek poly - many, morfos - form) is the property of some objects to take on different external forms depending on circumstances. The actions performed by methods of the same name may differ depending on which class a particular method belongs to.

Other principles of OOP Typing are restrictions imposed on a class of objects that prevent the interchangeability of different classes (or greatly reduce this possibility). Parallelism is the property of objects to be in an active or passive state and to distinguish active or passive states from each other. Stability is the property of an object to exist in time (regardless of the process that gave rise to this object) and/or space (when moving an object from the space in which it was created).

Universal language UML modeling. Background In the early 90s. 20th century - the creation of new object-oriented programming languages ​​(Smalltalk, C++, Java) A huge number of object-oriented software design methods have been developed. The result is the development of UML, with the aim of combining the advantages of various approaches into one manufacturer-independent modeling language.

Universal Modeling Language UML UML – Unified Modeling Language – is a unified modeling language that is designed for visualization and documentation of object-oriented systems and business processes with a focus on their subsequent implementation in the form of software.

Universal Modeling Language UML Authors: G. Booch, Jim Rumbaugh, Ivar Jacobson. The first version of the language appeared in 1996. Currently, all issues of further development of UML are concentrated within the OMG consortium. In 2004 – UML 2.0.

UML Diagrams UML includes 8 types of diagrams: 1) use case diagrams; 2) class diagrams; 3) state diagrams; 4) activity diagrams; 5) cooperation diagrams; 6) sequence diagrams; 7) component diagrams; 8) deployment diagrams. Interaction diagrams Implementation diagrams

Some software products (UML tools) IBM Rational Software Architect (IBM) IBM Rational Rose(IBM) ARIS UML Designer (IDS Sheer) Enterprise Architect (SPARX Software) Altova Umodel KUml, Dia, PowerDesigner Etc. More details:

Assignment Independently study the article “UML basics: An introduction to the Unified Modeling Language”: /library/769.html?S_TACT=105AGX15&S_ CMP=EDU

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/

Test

" Object-oriented modeling based on UML"

Student: Filatov R.D.

Lipetsk 2015

Introduction

In this test work An object-oriented model of an information subsystem has been developed for accounting for currency transactions with deposits of individuals. This model was developed using the Rational Rose 2000 software product using the UML language.

Rational Rose 2000 has a fairly simple and intuitive clear interface user, allowing you to create models of complex software products using the unified programming language UML

The Unified Modeling Language (UML) is a language for defining, representing, designing, and documenting software systems information systems, organizational and economic systems, technical systems and other systems of various natures.

The development of the UML language had several different goals. First of all, UML was created as a general modeling language. UML is not proprietary, it is based on the agreement of the majority of experts in computer field. It has included core concepts from the most well-known methodologies so that it can be used in conjunction with them. UML was designed to support valuable design concepts such as encapsulation, entity separation, and the distillation of model design. UML meets the requirements modern development software, including large scale, parallelism, distribution, sample use, and team friendliness.

Creating a Use Case Diagram

A use case diagram is a diagram that shows a collection of use cases and actors, and the relationships (dependencies, generalizations, and associations) between them. Use case diagrams are used to model the view of a system in terms of use cases (or use cases). Most often, this involves modeling the context of a system, subsystem, or class, or modeling the requirements for the behavior of specified elements. This type of diagram allows you to create a list of operations that the system performs. This type of diagram represents important information- this is one of the main advantages of its use. By looking at the use cases, you can understand what functionality will be built into the system. By considering the characters, you can find out who exactly will interact with her. By examining the full range of use cases and actors, the scope of the system (what it will do) will be determined. It also helps to know what she won't do and make adjustments. The diagram of our object-oriented model (Figure A.1) shows two actors (actors): a bank employee and a client, as well as seven main actions performed by the simulated system: open a deposit, close a deposit, make a currency purchase operation, refuse a purchasing currency, performing an operation to sell currency, accruing interest, cash desk.

Creating a Sequence Diagram

The interaction of objects in the system occurs through the reception and transmission of messages by client objects and the processing of these messages by server objects. At the same time, in different situations the same objects can act as both clients and servers. This type diagram allows you to reflect the sequence of message transmission between objects, focusing on the temporal ordering of messages. Sequence diagrams depict the flow of events that occur within a use case. For example, the "Open deposit" use case provides several possible sequences, such as maintaining a deposit option or maintaining an incorrect deposit option. Data entry for opening a deposit is presented in this sequence diagram. A scenario is a specific instance of a flow of events. This sequence diagram shows the flow of events within the Open Contribution use case (Figure A.2). Having analyzed the components of the system, it is clearly seen that the most important task of a bank employee is entering data on deposits. Having received all the necessary information, we create a description of the scenarios: A bank employee creates a new deposit. A bank employee enters data into a database. A bank employee enters data into a database, but an error occurs while saving it in the database. The character in the diagram is a Bank employee. Because All interaction in object-oriented systems is carried out using messages between objects, then classes must allow sending or receiving messages. In messaging, some classes are clients and receive messages, while others are servers and send messages. information precedent software

Creating a Collaboration Diagram

Collaboration diagrams - the second type of interaction diagrams - Collaboration Diagram - G. Buch calls an object diagram. This diagram does not focus on the sequence of message transmission, it reflects the presence of relationships in general, that is, this diagram reflects the presence of messages from clients to servers. The diagram shows the interaction between objects, not classes, that is, it is a snapshot of system objects in some state. After all, objects, unlike classes created at the design stage, are created and destroyed throughout the operation of the program. And at each moment there is a specific group of objects with which work is carried out. In this regard, such concepts as lifetime and scope of objects appear, which will be discussed further.

Creating a Class Diagram

Class diagram allows you to create a logical representation of the system, on the basis of which you can create source described classes. Class diagrams display some of the classes and packages of the system. These are static pictures of system fragments and connections between them. You can combine classes in any way you like, but there are several common approaches.

First, you can group classes by stereotype. In this case, you end up with one package with entity classes, one with boundary classes, one with control classes, and so on. This approach can be useful in terms of placement of the finished system, since everything located on client machines border classes already end up in the same package.

The second approach is to group classes based on their functionality. For example, the Security package will contain all the classes responsible for the security of the application. The advantage of this method is that it can reuse packages. If you carefully approach the grouping of classes, you can get packages that are practically independent of each other. For example, the Security package can be used in other applications.

Finally, a combination of these two approaches is used. For further organization of classes, it is allowed to nest packages within each other. On high level abstractions, you can group classes by functionality by creating a Security package. You can create other packages within it, grouping the classes responsible for security by functionality or stereotype. Having familiarized ourselves with the classes of the model, we will combine these classes into packages according to the stereotype. The following packages were created: Entities, Boundaries and Control. The classes that advised them were placed in these packages (Figure A.4).

Entity classes reflect the basic concepts (abstractions) of the subject area and, as a rule, contain stored information. IN Current Package the Deposit and DepositCurrency classes were added.

Control classes are responsible for coordinating the actions of other classes. Typically, each use case has one control class that controls the sequence of events for that use case. The control class is responsible for coordination, but does not itself carry any functionality - the other classes do not send it large quantity messages. Instead, he sends many messages himself. A manager class simply delegates responsibility to other classes, which is why it is often called a manager class. In this project, this function is performed by the Control class.

Boundary classes allow an actor to interact with the system. Every interaction between an actor and a use case must be associated with at least one boundary class.

Boundary classes are classes that are located at the boundary of the system and environment. They include all forms, reports, interfaces with hardware (such as printers or scanners), and interfaces with other systems.

In this model, a class diagram (Figure A.4) was created for the “Open a new contribution” scenario.

When designing the Contribution class, it is clear that its behavior needs to be observed. Many requirements for a class change significantly when the state of its instance changes. To ensure that the project meets all requirements, a state diagram is created for the Contribution class. With its help, a state diagram was created in the project

Creating a State Diagram for Classes and a Component Diagram

State diagrams are designed to display the states of system objects that have a complex behavior model. State is one of possible conditions, in which an object can exist.

While in a specific state, an object can perform certain actions. For example, it can generate a report, perform some calculations, or send an event to another object. There are five types of actions that can be associated with a state: activity, input action, output action, event, and state history.

Literature

1. Boggs W., Boggs M.. UML and Rational Rose: Trans. from English - M.: Publishing House "Lori", 2009. - 581 p., ill.

2. Butch G., Rambo D., Jacobson A. UML for the user: Transl. from English - M.: DMK, 2009.- 432 e., ill. (Series "for programmers").

3. Larman K. application of UML and design patterns: Per. from English - M.: Publishing house "William", 2012. - 496 p., ill.

4. Kuraev E.A. Banking systems: Publishing house "Gloria", 2013.-225 pp., ill. (Currency transactions with deposits)

5. Rodionova V.M. Banking operations: Ed. Rodionova V.M., 2011 .- 112с, illus (Currency transactions with deposits)

Posted on Allbest.ru

...

Similar documents

Using the Rational Rose 2000 program to model the information subsystem for accounting for currency transactions with deposits of individuals. Create use case, sequence, and collaboration diagrams. The main added attributes of the "Contribution" class.

course work, added 06/23/2011


Stages of development of an object-oriented model of the admissions committee information subsystem for registering applicants. Create diagrams to model the process of messaging between objects. Generation order program code in C++ language.

course work, added 06/29/2011


Methodology for developing an object-oriented model of the information subsystem necessary for recording the progress of faculty students, which was designed using the Rational Rose 2003 software product and the unified modeling language UML.

course work, added 06/25/2011


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

course work, added 06/26/2011


Unified modeling language. Methods of object-oriented analysis and design. Create a sequence diagram and collaboration diagram. Main class diagram. Adding connections between classes. Dependencies between packages.

course work, added 06/23/2011


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

course work, added 06/23/2011


Development of an information subsystem model for recording car service customer orders using the UML language. Create use case, sequence, collaboration, and class diagrams using Rational Rose 2000 techniques. Generate C++ code.

course work, added 06/22/2011


Features of object-oriented design. Basic concepts of the object-oriented approach. Basics of the UML language, options for its use. Class and interaction diagrams. Development of a use case (use case) diagram.

course work, added 05/13/2014


Development of an object-oriented model of the information subsystem for accounting for university students during the examination session using the Rational Rose 2000 program, using the UML language. The procedure for generating program code in C++.

course work, added 06/21/2011


Constructing diagrams, adding details to descriptions of operations, defining class attributes and the procedure for generating program code in C++ for an object-oriented model of an information subsystem that automates the work of the clinic registry.

The tutorial contains: summary UML language - that part of it that can be used as the basis for a language for modeling complex dynamic systems; description and capabilities of the new modeling language proposed by the authors based on hybrid automata, which is an extension of UML; historical overview and examples of different approaches to designing modeling tools; object-oriented analysis of complex dynamic systems. The book is the second of three books united under the general title Modeling of Systems.

The need for a unified model description language.
Traditional technology for designing complex systems, which does not involve preliminary computer modeling, includes the following main stages: formulating requirements for a future system, developing design documentation based on them, creating a prototype, testing it for compliance with the requirements and maintaining the industrial design.

In an ideal case, a complete functional specification, developed by system analysts or automatically using computer technology, is already a design solution; all that remains is to build a physical model according to this specification, which will be the system being designed. Unfortunately, it is not. Creation real system, corresponding to the developed functional specifications, requires creative, non-formalized engineering solutions and manual labor.

Even the seemingly fully formalized “soft part” of modern technical systems - embedded software - is most often executed on special embedded computers or microprocessors with special exchange channels, special operating systems and other features that require “manual” fine-tuning of the developed software. Without this “manual”, poorly formalized, stage it is difficult to ensure special requirements reliable operation systems at given temperatures, vibrations, overloads, radiation levels, volume and weight restrictions. Chapter 5 discusses the conditions under which automatic generation embedded software but functional specifications, and these conditions are still very far from today's realities.

Table of contents
Table of contents
Preface
Chapter 1. Object-Oriented Approach to Modeling
The need for a unified model description language
Classes, instances and multi-component systems
Using UML at the initial design stage
Class Diagrams
Attributes
Behavior
Operations and methods
Abstract and concrete classes. Interfaces
Classes and relationships
Association
Generalization
Aggregation
Inheritance
Polymorphism
Behavior. State diagrams
Structured classifiers
Components
Events and signals
Packages
Model
Chapter 2. Object-oriented modeling of complex dynamic systems based on the hybrid automaton formalism
Active class and active dynamic object
Packages and model
Using Passive Objects
Variables
Data types
Scalar types
Real type
Integer types
Boolean type
Enum types
Character types
Regular types
Vectors
Matrices
Arrays
Lists
Combined type (record)
Explicitly defined types
Signals
Automatic type casting
System of equations
Behavior map
States
Transitions
Structural scheme
Objects
Connections
Regular structures
Class inheritance
Adding new description elements
Overriding Inherited Elements
Polymorphism
Parameterized classes
Chapter 3. Modeling of hybrid systems and object-oriented approach in various packages
Modeling of hybrid systems in tools for mainframe computers
SLAM II language
NEDIS language
Hybrid models in modern modeling tools
Modeling of hybrid systems in the Simulink package ("block modeling")
Modeling of hybrid systems in the Modelica language (" physical modeling")
Hybrid direction
Object-oriented modeling languages
Simula-67 and NEDIS
ObjectMath
Omola
Modelica
Block Modeling Tools
Analysis existing languages OOM applied to modeling complex dynamic systems
Chapter 4. Multi-object models
Chapter 5. Object-Oriented Modeling and Object-Oriented Analysis
Complex technical system
Object-oriented analysis in the development of complex technical systems
Object-oriented modeling at subsequent stages of development and maintenance of a complex technical system
System-analytical model as the basis of “end-to-end” design technology
Literature
Further reading for Chapter 1
Further reading for Chapter 2
Further reading for Chapter 3
Further reading for Chapter 4
Further reading for Chapter 5
Subject index.

Free download e-book at convenient format, watch and read:
Download the book Modeling of Systems, Object-Oriented Approach, Kolesov Yu., Senichenkov Yu., 2012 - fileskachat.com, fast and free download.

Download pdf
You can buy this book below best price at a discount with delivery throughout Russia.

Concept object-oriented modeling(OOM) is certainly related to object-oriented programming(OOP). This approach to software development, which emerged in the mid-1980s, was originally aimed at solving problems arising from the inevitable growth and complexity of programs, as well as data processing and manipulation tasks. At that time it became obvious that traditional methods procedural programming We are not able to cope with the increasing complexity of programs and their development, nor with the need to improve their reliability. At the same time, computational and computational-algorithmic tasks, especially in the field of business support, gradually began to fade into the background, and the tasks of data processing and manipulation began to occupy the first place.

The fundamental concepts of OOP are the concepts of class and object. At the same time, under class some abstraction of the totality is understood objects, which have a common set of properties and exhibit the same behavior. Each object in this case is considered as an instance of the corresponding class. Objects that do not have exactly the same properties or behavior cannot, by definition, be classified into the same class. Although the above definition of a class can be refined by taking into account other OOP concepts, it is general and sufficient for conducting OOM.

An important feature of classes is the possibility of their organization in the form of some hierarchical structure, which appearance resembles a classification scheme for concepts of formal logic. In this regard, it should be noted that each concept in logic has a scope and content. The scope of a concept refers to all other conceivable concepts for which the original concept can serve as a defining category or part. The content of a concept is the totality of all its signs and attributes that distinguish this concept from everyone else. In formal logic, the law of the inverse relationship is known: if the content of concept A is contained in the content of concept B, then the scope of concept B is contained in the scope of concept A.

The hierarchy of concepts is constructed as follows. The most general concept or category is taken to be the concept that has the largest volume and, accordingly, the smallest content. This is the highest level of abstraction for a given hierarchy. Then the general concept is specified in some way, thereby reducing its volume and increasing its content. A less general concept appears, which in the hierarchy diagram will be located one level below the original concept. This process of concretizing concepts can be continued until at the lowest level a concept is obtained, further concretization of which is impossible or impractical.

Obviously, if we take a certain model as the most abstract concept to achieve OOM goals, then the conceptual scheme of object-oriented modeling can be represented as shown in Fig. 4.5.

Currently, the language that implements object-oriented approaches (including business process modeling) is the language UML (Unified Modeling Language), is a general-purpose visual modeling language that is designed for specifying, visualizing, designing, and documenting software components, business processes, and other systems. This language can be used to build conceptual, logical and graphical models of complex systems for various purposes.

The formal description of the subject area using UML is based on the hierarchical structure of model representations (see Fig. 4.5), consisting of four levels: 1) meta-metamodel; 2) megamodels; 3) models; 4) objects.

Rice. 4.5.

The meta-metamodel level forms the initial basis for all metamodel views. Its main purpose is to define a language for specifying the metamodel. The meta-metamodel defines a formal language at the highest level of abstraction and is its most compact description. In this case, a meta-metamodel can specify several metamodels, thereby achieving the potential flexibility of including additional concepts.

A metamodel is an instance or instantiation of a meta-metamodel. the main task This level is to define the language for the specification of the model. This level more constructive than the previous one, since it has a more developed semantics of basic concepts.

A model in the context of the UML language is an instance of a metamodel in the sense that any specific model the system should use only the concepts of the metamodel, specifying them in relation to a given situation. This is a level for describing information about a specific subject area. However, if UML language concepts are used to build a model, then complete consistency of model-level concepts with metamodel-level language concepts is necessary. The concretization of model concepts occurs at the level of objects.

From the most general point of view, UML consists of two interacting parts: language semantics and notation. Semantics defined for two types of models: structural models and behavioral models. Structural models, also known as static models, describe the structure of entities or components (elements) of some system, including their attributes and relationships. Patterns of behavior, sometimes called dynamic models, describe the behavior or functioning of system objects, the interaction between them, as well as the process of changing the states of individual elements and the system as a whole. It should be noted that it was to display the behavioral aspect of systems that UML was created in the first place. Notation the same language is a graphical specification for visual representation semantics of language.

Within the UML language, all ideas about the model of a complex system are recorded in the form of special graphical structures - diagrams. Defined in UML terms the following types diagrams (Fig. 4.6):

• use case diagram ( Use Case Diagram);
• class diagram ( Class Diagram);
• behavior charts ( Behavior Diagrams);
• implementation diagrams ( Implementation Diagrams).

Rice. 4.6.

Each of these diagrams details and concretizes a different view of a complex system model in UML terms. At the same time, a use case diagram represents the most general conceptual model of a complex system, which is the starting point for constructing other diagrams. A class diagram is essentially a logical model that reflects the static aspects of the structural design of a system.

A special role is played by behavior diagrams, designed to reflect the dynamic aspects of the functioning of a complex system. This type of diagram includes:

• state diagram ( Statechart Diagram);
• activity diagram (Activity Diagram);
• interaction diagrams (Interaction Diagrams):
• - sequence diagram (Sequence Diagram);
• - cooperation diagram (Collaboration Diagram).

Finally, implementation diagrams serve to represent physical components complex system. These include:

• component diagram (Component Diagram);
• deployment diagram (Deployment Diagram).

In modern literature, all of the listed diagrams and objects of the metamodel level are considered in some detail.

From the point of view of business process modeling, visual modeling in IJML can be represented as a certain process of level-by-level descent from the most general and abstract conceptual model original system to a logical and then to a physical model of the corresponding software system. To achieve these goals, a model is first built in the form of a so-called use case diagram (Use Case Diagram), which describes the functional purpose of the system or, in other words, what the system will do during its operation. A use case diagram is the initial conceptual representation or conceptual model of a system during its design and development process.

Developing a use case diagram has the following goals:

• determine the general boundaries and context of the modeled subject area at the initial stages of system design;
• formulate General requirements to the functional behavior of the designed system;
• develop an initial conceptual model of the system for its subsequent detailing in the form of logical and physical models;
• prepare initial documentation for the interaction of system developers with its customers and users.

The essence of this diagram is as follows: the designed system is represented as a set of entities or actors interacting with the system using so-called use cases. Wherein actor or an actor is any entity that interacts with the system from the outside. This can be a person, a technical device, a program or any other system that can serve as a source of influence on the simulated system as determined by the developer himself. In its turn, use case serves to describe the services that the system provides to the actor. In other words, each use case defines a certain set of actions performed by the system during a dialogue with the actor. However, nothing is said about how the interaction of actors with the system will be implemented.

The main objects of the use case diagram are summarized in Table. 4.1.

Basic UML Use Case Diagram Objects

Table 4.1

	Designation			Purpose
Use case	f Check the status (current account ) bank client			A use case is used to specify the general behavior of a system or any other domain entity without considering the internal structure of that entity.
				An actor is any entity external to the modeled system that interacts with the system and uses its functionality to achieve certain goals or solve particular problems
Interface	Sensor Barcode reader			The interface is used to specify model parameters that are visible from the outside without specifying their internal structure
Note		Implement as a separate library of standard functions		Annotations in UML are intended to be included in a model of arbitrary text information directly related to the context of the project being developed

End of table. 4.1

	Designation	Purpose
Relationships in a Use Case Diagram
association relationship		The association specifies the semantic features of the interaction of actors and use cases in a graphical model of the system
extend relationship		An extension relationship defines the relationship between instances of a particular use case and a more general use case, the properties of which are determined based on the way these instances are combined together
Generalization relation generalization relationship		A generalization relation is used to indicate the fact that some use case A can be generalized to use case B. In this case, option A will be a specialization of option B
Inclusion relationship (include relationship)		An inclusion relationship between two use cases indicates that some specified behavior for one use case is included as a constituent component in the sequence of behaviors of the other use case.

An example of a use case diagram is shown in Fig. 4.7.

Rice. 4.7.

From a simulation modeling perspective, the use case diagrams and behavior diagrams are of greatest interest. It is these diagrams that are designed to describe the functionality (activity, movement) of the system components. In addition, the totality of these diagrams completely determines the conceptual level of description of a complex system (conceptual model). In this regard, it is necessary to consider these diagrams in more detail. As an example, let’s take the sales and marketing department of a certain company as a complex system. The main purpose of modeling this system is to automate the work of the department, i.e. in the creation and implementation of a sales management information system. It is assumed that there is no automation of production activities in the department.

Without going into a description of the semantics of the UML language (it is well covered in the relevant literature), we will only present the results of the object-oriented analysis shown in Fig. 4.8-4.12.

It is easy to see that time is like most important attribute any behavioral model is present in the above diagrams only indirectly. This means that when analyzing behavior (or changes in states), only qualitative assessments such as “not earlier than...”, “only after...”, etc. are possible. However, when analyzing, for example, a state diagram (see Fig. 4.9), the following questions naturally arise: “How often do orders arrive?”, “How long do they take to process?”, “What is the ratio of the number of automated workstations (AWS) and the number of managers ?”, “What should the server performance be?” etc. It is obvious that it is simply impossible to obtain answers to these questions from the diagrams given without the use of simulation modeling.

Rice. 4.8.

Rice. 4.9.

Rice. 4.10.

Rice. 4.11.

Rice. 4.12.

At the same time, we note that when constructing final diagrams (component diagrams and deployment diagrams), it is required to explicitly indicate specifications hardware, for example, such as the number of workstations (AWS), clock frequency processors, network transmission speed, storage capacity, etc. It is clear that inflated indicators can lead to unjustified costs, and underestimated ones can lead to a decrease in the efficiency of the entire system. Therefore, justification of the required values ​​of all technical indicators is possible only based on the results of simulation modeling.

UML diagram objects that model system behavior can be associated with objects simulation model. The most important diagrams that carry necessary information, V in this case are use case diagram and state diagram. The relationship between the objects of these diagrams and the objects of the simulation model is shown in Table. 4.2.

Table 4.2

Relationship between UML diagram objects and simulation model objects

	Statechart object	Simulation model object

Use case diagram object	Statechart object	Simulation model object

Analysis of the table 4.2 shows that, despite the sufficient expressiveness of the UML language for constructing a visual simulation model, its tools are clearly insufficient. The given abstract objects of the simulation model constitute a conceptual model of the functioning of the sales and marketing department.