natgillin/translations-raw huggingface dataset:
A Class defines the attributes and the methods of a set of objects. All objects of this class (instances of this class) share the same behavior, and have the same set of attributes (each object has its own set). The term Type is sometimes used instead of Class, but it is important to mention that these two are not the same, and Type is a more general term.
Клас визначає атрибути і методи набору об’ єктів. Всі об’ єкти цього класу (екземпляри цього класу) мають спільну поведінку і однаковий набір атрибутів (кожен з об’ єктів має свій власний набір значень). Іноді замість назви « клас » використовують назву тип, але, слід зауважити, що ці назви описують різні речі: тип є загальнішим визначенням.
In & UML;, Classes are represented by rectangles, with the name of the class, and can also show the attributes and operations of the class in two other compartments inside the rectangle.
У & UML; класи позначаються прямокутниками з назвою класу, у цих прямокутниках у вигляді двох відсіків може бути показано атрибути і операції класу.
A Class in & UML;
Клас у & UML;
Visual representation of a Class in & UML;
Наочне представлення класу у & UML;
In & UML;, Attributes are shown with at least their name, and can also show their type, initial value and other properties. Attributes can also be displayed with their visibility:
У & UML; атрибути показуються щонайменше назвою, також може бути показано їх тип, початкове значення і інші властивості. Крім того, атрибути може бути показано з областю видимості атрибута:
+ Stands for public attributes
+ відповідає публічним (public) атрибутам
# Stands for protected attributes
# відповідає захищеним (protected) атрибутам
- Stands for private attributes
- відповідає приватним (private) атрибутам
Operations (methods) are also displayed with at least their name, and can also show their parameters and return types. Operations can, just as Attributes, display their visibility:
Операції (методи) також показуються принаймні назвою, крім того, може бути показано їх параметри і типи значень, які буде повернуто. Операції, як і атрибути, може бути показано з областю видимості:
+ Stands for public operations
+ відповідає публічним (public) операціям
# Stands for protected operations
# відповідає захищеним (protected) операціям
- Stands for private operations
- відповідає приватним (private) операціям
Classes can have templates, a value which is used for an unspecified class or type. The template type is specified when a class is initiated (ie; an object is created). Templates exist in modern C++ and will be introduced in Java 1.5 where they will be called Generics.
Серед класів можуть бути шаблони, значення, які використовуються для невизначеного класу або типу. Тип шаблону визначається під час ініціалізації класу (тобто, під час створення об’ єкта). Шаблони існують у сучасній мові програмування C++, їх буде введено у Java 1. 5, де вони матимуть назву Generic.
Class Associations
Асоціації класів
Classes can relate (be associated with) to each other in different ways:
Класи можна співвіднести (пов’ язати) один з одним у декілька способів:
Generalization
Узагальнення
Inheritance is one of the fundamental concepts of Object Oriented programming, in which a class gains all of the attributes and operations of the class it inherits from, and can override/ modify some of them, as well as add more attributes and operations of its own.
Наслідування є однією з фундаментальних основ об’ єктно- орієнтованого програмування, у якому клас отримує всі атрибути і операції класу, нащадком якого він є, і може перевизначати або змінювати деякі з них, а також додавати власні атрибути і операції.
In & UML;, a Generalization association between two classes puts them in a hierarchy representing the concept of inheritance of a derived class from a base class. In & UML;, Generalizations are represented by a line connecting the two classes, with an arrow on the side of the base class.
У & UML; пов’ язування Узагальнення між двома класами розташовує їх у вузлах ієрархії, яка відповідає концепції успадкування класу- нащадка від базового класу. У & UML; узагальнення буде показано у вигляді лінії, яка поєднує два класи, зі стрілкою, яку спрямовано від базового класу.
Visual representation of a generalization in & UML;
Наочний показ узагальнення у & UML;
Associations
Асоціації
An association represents a relationship between classes, and gives the common semantics and structure for many types of connections between objects.
Асоціація означає взаємозв’ язок між класами, вона є базовим семантичним елементом і структурою для багатьох типів з’ єднань між об’ єктами.
Associations are the mechanism that allows objects to communicate to each other. It describes the connection between different classes (the connection between the actual objects is called object connection, or link.
Асоціації є тим механізмом, який надає об’ єктам змогу обмінюватися даними між собою. Асоціація описує з’ єднання між різними класами (з’ єднання між дійсними об’ єктами називається об’ єктним з’ єднанням, або зв’ язком).
Associations can have a role that specifies the purpose of the association and can be uni- or bidirectional (indicates if the two objects participating in the relationship can send messages to the other, of if only one of them knows about the other). Each end of the association also has a multiplicity value, which dictates how many objects on this side of the association can relate to one object on the other side.
Асоціації можуть виконувати роль, яка визначає призначення асоціації і може бути одно - чи двосторонньою (другий варіант означає, що у межах зв’ язку кожен з об’ єктів може надсилати повідомлення іншому, перший же — варіанту, коли лише один з об’ єктів знає про існування іншого). Крім того, кожен з кінців асоціації має значення численності, яке визначає кількість об’ єктів на відповідному кінці асоціації, які можуть мати зв’ язок з одним з об’ єктів на іншому кінці асоціації.
In & UML;, associations are represented as lines connecting the classes participating in the relationship, and can also show the role and the multiplicity of each of the participants. Multiplicity is displayed as a range [min.. max] of non-negative values, with a star (*) on the maximum side representing infinite.
У & UML; асоціації позначаються лініями, що з’ єднують класи, які беруть участь у зв’ язку, крім того, може бути показано роль і численність кожного з учасників зв’ язку. Численність буде показано у вигляді діапазону [мін.. макс] невід’ ємних чисел, зірочка (*) на боці максимального значення позначає нескінченність.
& UML; Association
Асоціація & UML;
Visual representation of an Association in & UML;
Наочний показ асоціації у & UML;
Aggregations are a special type of associations in which the two participating classes do n't have an equal status, but make a whole-part relationship. An Aggregation describes how the class that takes the role of the whole, is composed (has) of other classes, which take the role of the parts. For Aggregations, the class acting as the whole always has a multiplicity of one.
Агрегації є особливим типом асоціацій, за якого два класи, які беруть участь у зв’ язку не є рівнозначними, вони мають зв’ язок типу ціле- частина. За допомогою агрегації можна описати, яким чином клас, який грає роль цілого, складається з інших класів, які грають роль частин. У агрегаціях клас, який грає роль цілого, завжди має численність рівну одиниці.
In & UML;, Aggregations are represented by an association that shows a rhomb on the side of the whole.
У & UML; агрегації буде показано асоціаціями, у яких з боку цілої частини буде намальовано ромб.
Visual representation of an Aggregation relationship in & UML;
Наочний показ зв’ язку агрегації у & UML;
Composition
Композиція
Compositions are associations that represent very strong aggregations. This means, Compositions form whole-part relationships as well, but the relationship is so strong that the parts cannot exist on its own. They exist only inside the whole, and if the whole is destroyed the parts die too.
Композиції — це асоціації, які відповідають дуже сильній агрегації. Це означає, що у композиціях ми також маємо справу з співвідношеннями ціле- частина, але тут зв’ язок є настільки сильним, що частини не можуть існувати без цілого. Вони існують лише у межах цілого, після знищення цілого буде знищено і його частини.
In & UML;, Compositions are represented by a solid rhomb on the side of the whole.
У & UML; композиції буде показано як асоціації з зафарбованим ромбом з боку цілого.
Visual representation of a Composition relationship in & UML;
Наочний показ зв’ язку композиції у & UML;
Other Class Diagram Items
Інші елементи діаграми класів
Class diagrams can contain several other items besides classes.
Окрім класів на діаграмах класів можуть міститися і деякі інші елементи.
Interfaces are abstract classes which means instances can not be directly created of them. They can contain operations but no attributes. Classes can inherit from interfaces (through a realisation association) and instances can then be made of these diagrams.
Інтерфейси — це абстрактні класи, тобто з них не можна напряму створювати екземпляри. У інтерфейсах можуть міститися операції, але не атрибути. Класи можуть бути нащадками інтерфейсів (за допомогою асоціації реалізації), а з цих діаграм можна потім створювати сутності.
Datatypes
Типи даних
Datatypes are primitives which are typically built into a programming language. Common examples include integers and booleans. They can not have relationships to classes but classes can have relationships to them.
Типи даних — це базові елементи, з яких типово будується мова програмування. Типовими прикладами є цілі числа і булеві значення. Вони не можуть мати зв’ язків з класами, але класи можуть мати зв’ язки з ними.
Enums
Переліки
Enums are a simple list of values. A typical example is an enum for days of the week. The options of an enum are called Enum Literals. Like datatypes they can not have relationships to classes but classes can have relationships to them.
Переліки є простими списками значень. Типовим прикладом є перелік днів тижня. Пункти переліків називаються літералами переліків. Подібно до типів даних, переліки не можуть мати зв’ язків з класами, але класи можуть мати зв’ язки з переліками.
Packages represent a namespace in a programming language. In a diagram they are used to represent parts of a system which contain more than one class, maybe hundereds of classes.
Пакункам відповідають простори назв у мовах програмування. На діаграмі пакунки використовуються для позначення частин системи, у яких міститься декілька класів, може навіть сотні класів.
Sequence Diagrams
Діаграми послідовностей
Sequence Diagrams show the message exchange (ie; method call) between several Objects in a specific time-delimited situation. Objects are instances of classes. Sequence Diagrams put special emphasis in the order and the times in which the messages to the objects are sent.
На діаграмах послідовностей буде показано обмін повідомленнями (тобто виклик методів) між декількома об’ єктами у окремій обмеженій часом ситуації. Об’ єкти є екземплярами класів. Основний наголос на діаграмах послідовностей робиться на порядок і моментах часу, у які повідомлення надсилаються об’ єктам.
In Sequence Diagrams objects are represented through vertical dashed lines, with the name of the Object on the top. The time axis is also vertical, increasing downwards, so that messages are sent from one Object to another in the form of arrows with the operation and parameters name.
На діаграмах послідовностей об’ єкти буде показано вертикальними штриховими лініями з назвою об’ єкта над ними. Вісь часу також має вертикальний напрямок, її спрямовано вниз, повідомлення, які надсилаються від одного об’ єкта до іншого, буде позначено стрілками з назвами операції і параметрів.
umbrello; showing a Sequence Diagram
Показ діаграми послідовностей у & umbrello;
Messages can be either synchronous, the normal type of message call where control is passed to the called object until that method has finished running, or asynchronous where control is passed back directly to the calling object. Synchronous messages have a vertical box on the side of the called object to show the flow of program control.
Повідомлення можуть бути або синхронними, звичайного типу повідомленнями, за виклику яких керування передається викликаному об’ єкту до завершення виконання методу, або асинхронними, за виклику яких керування передається назад напряму об’ єкту, який здійснював виклик. За використання синхронного повідомлення збоку від викликаного об’ єкта буде показано вертикальний блок, який показуватиме перебіг виконання програми.
Collaboration Diagrams
Діаграми співпраці
Collaboration Diagrams show the interactions occurring between the objects participating in a specific situation. This is more or less the same information shown by Sequence Diagrams but there the emphasis is put on how the interactions occur in time while the Collaboration Diagrams put the relationships between the objects and their topology in the foreground.
На діаграмах співпраці показується взаємодія між об’ єктами, які беруть участь у певній події. Ця інформація більшою чи меншою мірою подібна до інформації, показаної на діаграмі послідовностей, але там наголос робиться на часовій характеристиці взаємодії, а на діаграмах співпраці основний наголос робиться на взаємодії між об’ єктами та її топології на передньому плані.
In Collaboration Diagrams messages sent from one object to another are represented by arrows, showing the message name, parameters, and the sequence of the message. Collaboration Diagrams are specially well suited to showing a specific program flow or situation and are one of the best diagram types to quickly demonstrate or explain one process in the program logic.
На діаграмах співпраці повідомлення надіслані від одного з об’ єктів до іншого позначаються стрілочками, поряд з якими показано назву повідомлення, параметри і послідовність повідомлення. Діаграми співпраці найкраще пасують для показу специфічного перебігу виконання або ситуацій у програмі. Такі діаграми є найкращим засобом для швидкого показу і пояснення окремого процесу у програмній логіці.
Collaboration
Співпраця
umbrello; showing a Collaboration Diagram
Показ діаграми співпраці у & umbrello;
State Diagrams show the different states of an Object during its life and the stimuli that cause the Object to change its state.
На діаграмах станів зображають різні стани об’ єкта під час його існування і стимули, які призводять до переходу об’ єкта з одного стану у інший.
State Diagrams view Objects as state machines or finite automates that can be in one of a set of finite states and that can change its state via one of a finite set of stimuli. For example an Object of type NetServer can be in one of following states during its life:
На діаграмах стану об’ єкти розглядаються як машини станів або скінченні автомати, які можуть перебувати у одному зі станів скінченного набору станів, і які можуть змінювати цей стан через вплив одного зі стимулів зі скінченного набору стимулів. Наприклад, об’ єкт типу Сервер мережі може перебувати у одному з таких станів протягом існування:
Ready
Готовність
Listening
Очікування
Working
Робота
Stopped
Зупинка
and the events that can cause the Object to change states are
а подіями, які можуть спричинити зміну стану об’ єкта можуть бути
Object is created
Створення об’ єкта
Object receives message listen
Об’ єкт отримує повідомлення « очікувати »
A Client requests a connection over the network
Клієнт надсилає запит на з’ єднання мережею
A Client terminates a request
Клієнт перериває запит
The request is executed and terminated
Запит виконано і перервано
Object receives message stop
Об’ єкт отримує повідомлення « зупинка »
etc
тощо
umbrello; showing a State Diagram
Показ діаграми станів у & umbrello;
States are the building block of State Diagrams. A State belongs to exactly one class and represents a summary of the values the attributes of a class can take. A & UML; State describes the internal state of an object of one particular class
Будівельними цеглинками діаграм станів є стани. Стан належить лише одному класу і відповідає переліку значень атрибутів, які може приймати клас. У & UML; стан описує внутрішній стан об’ єкта одного з окремих класів
Note that not every change in one of the attributes of an object should be represented by a State but only those changes that can significantly affect the workings of the object
Зауважте, що не кожну зміну одного з атрибутів об’ єкта має бути показано станом, станам відповідають лише ті зміни, які значно впливають на виконання об’ єктом завдань.
There are two special types of States: Start and End. They are special in that there is no event that can cause an Object to return to its Start state, in the same way as there is no event that can possible take an Object out of its End state once it has reached it.
Існує два особливих типи станів: початок і кінець. Їх особливість полягає у тому, що не існує жодної події, яка може спричинити повернення об’ єкта до його початкового стану, так само, не існує жодної події, яка б могла повернути об’ єкт зі стану кінця, тільки- но він його досягне.
Activity Diagrams describe the sequence of activities in a system with the help of Activities. Activity Diagrams are a special form of State Diagrams, that only (or mostly) contains Activities.
На діаграмі діяльності буде показано послідовність актів дій системи на основі Діяльностей. Діаграми діяльності є особливою формою діаграм стану, на яких містяться лише (або головним чином) діяльності.
An example Activity Diagram.
Приклад діаграми діяльності.
umbrello; showing an Activity Diagram
Показ діаграми діяльності у & umbrello;
Activity Diagrams are similar to procedural Flux Diagrams, with the difference that all Activities are clearly attached to Objects.
Діаграми діяльності подібні до процедурних діаграм потоку, але відрізняються від них тим, що діяльності точно прив’ язано до об’ єктів.
Activity Diagrams are always associated to a Class, an Operation or a Use Case.
Діаграми діяльності завжди пов’ язано з класом, операцією або випадком використання.
Activity Diagrams support sequential as well as parallel Activities. Parallel execution is represented via Fork/ Wait icons, and for the Activities running in parallel, it is not important the order in which they are carried out (they can be executed at the same time or one after the other)
На діаграмах діяльності може бути показано як послідовні, так і паралельні діяльності. Паралельне виконання буде показано за допомогою піктограм Розділити/ Чекати, для діяльностей, які виконуються паралельно, неважливим є порядок їх обробки (їх може бути виконано одночасно або одну за одною).
Activity
Діяльність
An Activity is a single step in a process. One Activity is one state in the system with internal activity and, at least, one outgoing transition. Activities can also have more than one outgoing transition if they have different conditions.
Діяльність є окремим кроком у процесі. Одній діяльності відповідає окремий стан у системі з внутрішньою діяльністю і, принаймні, одна вихідна транзакція. Крім того, діяльності можуть мати декілька вихідних транзакцій, якщо умови цих транзакцій є різними.
Activities can form hierarchies, this means that an Activity can be composed of several detail Activities, in which case the incoming and outgoing transitions should match the incoming and outgoing transitions of the detail diagram.
Діяльності можуть формувати ієрархічні структури, це означає, що діяльність може бути складено з декількох менших діяльностей, у цьому випадку вхідні і вихідні транзакції мають відповідати вхідним і вихідним транзакціям докладної діаграми.
Helper Elements
Допоміжні елементи
There are a few elements in & UML; that have no real semantic value for the model, but help to clarify parts of the diagram. These elements are
У & UML; є декілька елементів, які не мають реального семантичного змісту для моделі, але допомагають прояснити частини діаграми. Цими елементами є
Text lines
Рядки тексту
Text Notes and anchors
Текстові нотатки і якорі
Boxes
Блоки
Text lines are useful to add short text information to a diagram. It is free-standing text and has no meaning to the Model itself.
Рядки тексту можуть знадобитися, якщо до діаграми слід додати коротку текстову інформацію. Вони є довільно розташованим тестом і не мають значення для самої моделі.
Notes are useful to add more detailed information about an object or a specific situation. They have the great advantage that notes can be anchored to & UML; Elements to show that the note belongs to a specific object or situation.
Нотатками можна скористатися для додавання докладніших відомостей щодо об’ єкта або певної ситуації. У них є велика перевага у тому, що нотатки можна пов’ язати з елементами & UML;, щоб було видно, що нотатка стосується певного об’ єкта або ситуації.
Boxes are free-standing rectangles which can be used to group items together to make diagrams more readable. They have no logical meaning in the model.
Блоки є довільно розташованими прямокутниками, які можна використовувати для групування об’ єктів діаграми, яке зробить діаграму зрозумілішою. Вони не мають логічного навантаження у межах моделі.
Component Diagrams
Діаграми компонентів
Component Diagrams show the software components (either component technologies such as KParts, CORBA components or Java Beans or just sections of the system which are clearly distinguishable) and the artifacts they are made out of such as source code files, programming libraries or relational database tables.
На діаграмах компонентів буде показано компоненти програмного забезпечення (або технології компонентів, такі як KParts, компоненти CORBA або Java Beans, або просто розділи системи, які чітко відрізняються один від одного), а також елементи, з яких вони складаються, такі як файли з початковими кодами, програмні бібліотеки або таблиці реляційних баз даних.
Components can have interfaces (ie; abstract classes with operations) that allow associations between components.
Компоненти можуть мати інтерфейси (тобто абстрактні класи з операціями), які надають змогу створювати асоціації між компонентами.
Deployment Diagrams
Діаграми впровадження
Deployment diagrams show the runtime component instances and their associations. They include Nodes which are physical resources, typically a single computer. They also show interfaces and objects (class instances).
На діаграмах впровадження буде показано екземпляри компонентів та їх асоціації. На них буде показано вузли, які є фізичними ресурсами, типово, окремими комп’ ютерами. Крім того, на них показують інтерфейси і об’ єкти (екземпляри класів).
Entity Relationship Diagrams
Діаграми взаємозв’ язків сутностей
Entity Relationship Diagrams (ER Diagrams) show the conceptual design of database applications. They depict the various entities (concepts) in the information system and the existing relationships and constraints between them. An extension of Entity Relationship Diagrams named'Extended Entity Relationship Diagrams' or'Enhanced Entity Relationship Diagrams' (EER), are used to incorporate Object Oriented design techniques in ER Diagrams.
На діаграмах взаємозв’ язку сутностей (діаграмах ВС (ER)) показують концептуальний дизайн програм для роботи з базами даних. На них показують різноманітні сутності (концепти) у інформаційній системі і існуючі взаємозв’ язки і обмеження між ними. Розширення діаграм взаємозв’ язку сутностей називають « Розширеними діаграмами взаємозв’ язку сутностей » або « Покращеними діаграмами взаємозв’ язку сутностей » (EER), їх використовують для інтеграції методик компонування орієнтованих на об’ єкти у діаграми ВС.
An example Entity Relationship diagram.
Приклад діаграми взаємозв’ язків сутностей
Umbrello showing an Entity Relationship Diagram
Показ діаграми взаємозв’ язків сутностей у & umbrello;
Entity
Сутність