natgillin/translations-raw huggingface dataset:
Sequence Diagrams show objects and a sequence of method calls they make to other objects.
järgnevusskeemid kujutavad objekte ja nende poolt sooritatavate meetodite väljakutsete järgnevusi
Collaboration Diagrams show objects and their relationship, putting emphasis on the objects that participate in the message exchange
koostööskeemid kujutavad objekte ja nendevahelisi relatsioone, pannes rõhu objektidele, mis osalevad teadete vahetamises
State Diagrams show states, state changes and events in an object or a part of the system
olekuskeemid kujutavad olekuid, olekute muutusi ja sündmusi objektis või süsteemi osas
Activity Diagrams show activities and the changes from one activity to another with the events occurring in some part of the system
tegevusskeemid kujutavad tegevusi ja muutusi ühest tegevusest teise seoses mõnes süsteemi osas toimuvate sündmustega
Component Diagrams show the high level programming components (such as KParts or Java Beans).
komponentskeemid kujutavad kõrgetasemelisi programmeerimiskomponente (nt. KParts või JavaBeans)
Deployment Diagrams show the instances of the components and their relationships.
Evitusskeemid kujutavad komponentide eksemplare ja nendevahelisi relatsioone
Class Diagrams show classes and the relationships between them
Olem- seos skeemid kujutavad andmeid ning andmete vahelisi seoseid ja kitsendusi
& UML; Elements
& UML; i elemendid
Use Case Diagram
Kasutusklassiskeem
Use Case Diagrams describe the relationships and dependencies between a group of Use Cases and the Actors participating in the process.
Kasutusklassiskeemid kirjeldavad protsessis osalevate kasutusklasside ja tegijate vahelisi relatsioone ja sõltuvusi.
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 & mdash; and cannot & mdash; specify how this is to be achieved.
Tähtis on tähele panna, et kasutusklassiskeemid pole mõeldud disaini kujutamiseks ja süsteemi sisestruktuuride kirjeldamiseks. Kasutusklassiskeemid on mõeldud kergendama suhtlemist kliendi ja süsteemi tulevaste kasutajate vahel ning on eriti kasulikud süsteemi funktsionaalsuse väljaselgitamisel. Kasutusklassiskeemid peaksid ütlema, mida süsteem peab tegema, mitte aga & mdash; ja ei tohigi öelda & mdash;, kuidas tehtu saavutatakse.
An example Use Case diagram.
Kasutusklassiskeemi näidis
umbrello; showing a Use Case Diagram
Kasutusklassiskeem Umbrellos
Use Case
Kasutusklass
A Use Case describes & mdash; from the point of view of the actors & mdash; a group of activities in a system that produces a concrete, tangible result.
Kasutusklass kirjeldab tegijate vaatenurgast süsteemi tegevuste gruppi, mis tagastab konkreetse ja käegakatsutava tulemuse.
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).
Kasutusklassid on tüüpilised süsteemi kasutajate ja süsteemi enda vaheliste interaktsioonide kirjeldused. Nad esindavad süsteemi välist liidest ja määravad nõuete kogu selle kohta, mida süsteem peab tegema (ära unusta: ainult mida, mitte kuidas).
When working with Use Cases, it is important to remember some simple rules:
Kasutusklassidega töötades on tähtis meeles pidada mõned lihtsad reeglid:
Each Use Case is related to at least one actor
iga kasutusklass on seotud vähemalt ühe tegijaga
Each Use Case has an initiator (ie; an actor)
igal kasutusklassil on olemas algataja (ie; tegija)
Each Use Case leads to a relevant result (a result with business value)
Iga kasutusklass juhatab kindla tulemuseni (ärilise väärtusega tulemuseni)
Use Cases can also have relationships with other Use Cases. The three most typical types of relationships between Use Cases are:
Ka kasutusklassidel võivad teiste kasutusklassidega relatsioonid olla. Kolm tüüpilisemat kasutusklasside vaheliste relatsioonide tüüpi on:
lt; lt; includegt; gt; which specifies that a Use Case takes place inside another Use Case
lt; lt; includegt; gt; määrab, kas kasutusklass leiab aset teise kasutusklassi sees
lt; lt; extendsgt; gt; which specifies that in certain situations, or at some point (called an extension point) a Use Case will be extended by another.
lt; lt; extendsgt; gt; määrab, et kindlates situatsioonides või mingis punktis (mida kutsutakse laienduspunktiks) laiendab üks kasutusklass teist
Generalisation 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.
üldistus määrab, et kasutusklass pärib eellasest kasutusklassi omadused ja võib mõnesid omadusi üle kirjeldada või lisada uusi sarnaselt klassidevahelise pärilusega
Actor
Tegija
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.
Tegija on väline olem (süsteemiväline), mis suhtleb süsteemiga, võttes osa (ja sageli algatades) kasutusklassist. Tegijad võivad olla reaalsed inimesed (näiteks infosüsteemi kasutajad), teised arvutisüsteemid või välised sündmused.
Actors do not represent the physical people or systems, but their role. This means that when a person interacts with the system in different ways (assuming different roles) he will be represented by several actors. For example a person that gives customer support by the telephone and takes orders from the customer into the system would be represented by an actor Support Staff and an actor Sales Representative
Tegijad ei esinda mitte füüsilisi isikuid või süsteeme, vaid nende rolle. See tähendab, et kui isik suhtleb süsteemiga erinevatel viisidel (võttes endale erinevaid rolle), siis kujutatakse teda erinevate tegijatena. Näiteks isikut, kes tegeleb telefoni kaudu kasutajatoeteenuse jagamisega ja võtab klientidelt ka süsteemi kasutamiseks tellimusi, peaks kujutama tegijatena Kasutajatugi ja Müügimees.
Use Case Description
Kasutusklassi kirjeldus
Use Case Descriptions are textual narratives of the Use Case. They usually take the form of a note or a document that is somehow linked to the Use Case, and explains the processes or activities that take place in the Use Case.
Kasutusklassi kirjeldused on kasutusklassi tekstilised narratiivid. Kujutatakse tavaliselt märkustena või dokumentidena, mis on kuidagi lingitud kasutusklassi külge ja selgitavad kasutusklassis toimuvaid protsesse või tegevusi.
Class Diagram
Klassiskeem
Class Diagrams show the different classes that make up a system and how they relate to each other. Class Diagrams are said to be static diagrams because they show the classes, along with their methods and attributes as well as the static relationships between them: which classes know about which classes or which classes are part of another class, but do not show the method calls between them.
Klassiskeemid kujutavad süsteemi moodustavaid klasse ja nendevahelisi suhteid. Öeldakse, et klassiskeemid on staatilised skeemid, sest nad kujutavad klasse, nende meetodeid ja atribuute ning nendevahelisi suhteid: millised klassid teavad millistest klassidest või millised klassid on teiste klasside osadeks, kuid ei kujuta meetodite väljakutseid nende vahel.
An example of a Class Diagram
Klassiskeemi näidis
umbrello; showing a Class Diagram
Klassiskeemi kuvamine Umbrellos
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 behaviour, 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.
Klass defineerib objektide hulga atribuudid ja meetodid. Kõik klassi objektid (klassi eksemplarid) jagavad ühist käitumist ja omavad samasugust hulka atribuute (igal objektil on isiklikud atribuudid). Vahel kasutatakse klassi asemel terminit tüüp, kuid tähtis on märkida, et need kaks ei ole samad ja tüüp on üldisem termin.
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; is kujutatakse klasse nelinurkadena, millel on klassi nimi ja mis võivad sisaldada ka klassi atribuutide ja operatsioonide nimesid nelinurga kahes eraldi osas.
A Class in & UML;
Klass & UML; is
Visual representation of a Class in & UML;
Klassi visuaalne esitus & UML; is
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; is kuvatakse vähemalt atribuudi nimi ja võib- olla ka selle tüüp, algväärtus ja muud omadused. Lisaks on võimalik kuvada atribuudi nähtavust:
+ Stands for public attributes
+ tähistab public atribuuti
# Stands for protected attributes
# tähistab protected atribuuti
- Stands for private attributes
- tähistab private atribuuti
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:
Operatsioonide (meetodite) puhul kuvatakse samuti vähemalt nime ja võib- olla ka parameetreid ja tagastustüüpi. Nagu atribuutide puhulgi, saab ka operatsioonide juures näidata nende nähtavust:
+ Stands for public operations
+ tähistab public operatsiooni
# Stands for protected operations
# tähistab protected operatsiooni
- Stands for private operations
- tähistab private operatsiooni
Templates
Mallid
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.
Klassid võivad omada malle, väärtusi, mida kasutatakse määramata klasside või tüüpide asemel. Malli tüüp määratakse alles siis, kui klass algväärtustatakse (ie; luuakse objekt). Mallid on olemas kaasaegses C++' s ja need hakkavad olema ka Java 1. 5' s, kus neid kutsutakse geneerikuteks.
Class Associations
Klassi sidemed
Classes can relate (be associated with) to each other in different ways:
Klassid võivad olla omavahel seotud mitmel moel:
Generalisation
Üldistus
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.
Pärilus on üks objektorienteeritud programmeerimise baaskontseptsioone, kus klass omandab kõik atribuudid ja operatsioonid kaasa sellelt eellasklassilt, millest ta pärineb, ning tohib neid üle kirjeldada ja muuta, aga ka lisada uusi atribuute ja operatsioone.
In & UML;, a Generalisation association between two classes puts them in a hierarchy representing the concept of inheritance of a derived class from a base class. In & UML;, Generalisations are represented by a line connecting the two classes, with an arrow on the side of the base class.
& UML; is seab üldistuse tüüpi side kahe klassi vahel nad hierarhiasse, mis esindab tuletatud klassi baasklassist pärinemise kontseptsiooni. & UML; is tähistab üldistust kaht klassi ühendav sirge, millel on nool baasklassi poolses otsas.
Visual representation of a generalisation in & UML;
Üldistuse visuaalne esitus & UML; is
Associations
Sidemed
An association represents a relationship between classes, and gives the common semantics and structure for many types of connections between objects.
Side esindab klasside seoseid ning võtab endas kokku paljude objektidevahelist ühenduse tüüpide semantika ja struktuuri.
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.
Side on mehhanism, mis võimaldab objektidel üksteisega suhelda. See kirjeldab ühendust erinevate klasside vahel (ühendust tegelike objektide vahel nimetatakse objektiühenduseks ehk lingiks).
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.
Sidemel võib olla roll, mis määrab sideme eesmärgi ja võib olla ühe - või kahesuunaline (märgib, kas kaks seotud objekti võivad teineteisele teateid saata või teab ainult üks teise olemasolu). Sideme mõlemal otsal on ka oma mitmesusväärtus, mis sätestab, mitu objekti sideme antud otsas võib olla seotud ühe objektiga sideme teises otsas.
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; is tähistavad sidemeid sirged, mis ühendavad seotud klasse, need võivad ka näidata rolli ja mõlema osapoole mitmesusväärtust. Mitmesust esitatakse mittenegatiivsete väärtuste vahemikuna [min... maks], kusjuures tärn (*) maksimumväärtuse asemel tähendab lõpmatust.
& UML; Association
& UML; side
Visual representation of an Association in & UML;
Sideme visuaalne esitus & UML; is
Aggregation
Agregatsioon
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.
Agregatsioon on spetsiaalne side, milles kaks klassi pole mitte võrdväärse staatusega, vaid moodustavad tervik- osa seose. Agregatsioon kirjeldab, kuidas osa, millel on terviku roll, koosneb teistest klassidest (omab teisi klasse), millel on osade roll. Agregatsiooni korral on terviku rollis klassi mitmesus alatu üks.
In & UML;, Aggregations are represented by an association that shows a rhomb on the side of the whole.
& UML; is tähistab agregatsiooni side, millel on tervikupoolses otsas romb.
Visual representation of an Aggregation relationship in & UML;
Agregatsiooniseose visuaalne esitus & UML; is
Composition
Kompositsioon
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.
Kompositsioonid on sidemed, mis esindavad väga tugevat sidet. See tähendab, et ka kompositsioon kujutab endast tervik- osa seost, kuid see seos on nii tugev, et osad ei saagi omaette eksisteerida. Nad eksisteerivad ainult terviku koosseisus ja kui kaob tervik, kaovad ka osad.
In & UML;, Compositions are represented by a solid rhomb on the side of the whole.
& UML; is tähistab kompositsiooni täidetud romb sideme tervikupoolses otsas.
Visual representation of a Composition relationship in & UML;
Kompositsiooni visuaalne esitus & UML; is
Other Class Diagram Items
Teised klassiskeemi elemendid
Class diagrams can contain several other items besides classes.
Klassiskeemid võivad lisaks klassidele sisaldada veel mitmeid elemente.
Interfaces
Liidesed (interfaces)
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.
Liidesed on abstraktsed klassid, mis tähendab, et neist ei saa otseselt eksemplare luua. Nad võivad sisaldada operatsioone, aga mitte atribuute. Klassid võivad olla liideste järglased (realisatsioonisideme kaudu) ning neist skeemidest saab siis luua eksemplare.
Datatypes
Andmetüübid
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.
Andmetüübid on primitiivid, mis on tavaliselt lisatud juba programmeerimiskeelde. Tüüpnäiteks on täisarvud ja tõeväärtused. Neil ei saa olla seoseid klassidega, kuid klassidel võivad olla seosed nendega.
Enums
Väärtustikud (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.
Väärtustikud on lihtsad väärtuste nimekirjad. Tüüpnäide on nädalapäevade väärtustik. Väärtustiku võtmeid nimetatakse literaalideks. Nagu andmetüüpidel, ei saa ka neil olla seoseid klassidega, küll aga klassidel nendega.
Packages
Paketid (packages)
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.
Paketid esindavad nimeruumi programmeerimiskeeles. Skeemidel kasutatakse neid süsteemi osade tähistamiseks, mis sisaldavad enam kui ühe klassi (mõnikord isegi sadu klasse).
Sequence Diagrams
Järgnevusskeemid
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.
Järgnevusskeemid näitavad teadetevahetust (ie; meetodi väljakutset) mitme objekti vahel teatud ajaliselt piiratud situatsioonis. Objektid on klasside eksemplarid. Järgnevusskeemid rõhutavad erilist teadete objektidele saatmise järjekorda ja aega.
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.
Järjestusskeemidel esindavad objekte püstised punktiirjooned, mille ülemises otsas seisab objekti nimi. Ka ajatelg on vertikaalne, suurenedes allapoole, ning ühelt objektilt teisele saadetud teateid näidatakse nooltena, millele on lisatud operatsiooni ja parameetrite nimed.
Sequence Diagram
Järgnevusskeem
umbrello; showing a Sequence Diagram
umbrello; järgnevusskeemiga
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.
Teated võivad olla sünkroonsed (tavaline teatetüüp, mille korral kontroll läheb väljakutsutavale objektile, kuni meetod on töö lõpetanud) või asünkroonsed (kontroll läheb otse tagasi väljakutsuvale objektile). Sünkroonsetel teadetel on väljakutsutud otjekti poolses otsas püstkast, mis näitab programmi kontrolli kulgu.
Collaboration Diagrams
Koostööskeemid
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.
Koostööskeemid näitavad teatud situatsioonis osalevate objektide interaktsiooni. See on enam- vähem sama info, mida leiab järgnevusskeemilt, kuid viimaste korral on rõhk asetatud sellele, kuidas interaktsioon toimub, koostööskeemi korral aga objektidevahelistele seostele ja nende topoloogiale.
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.
Koostööskeemides esindavad ühelt objektilt teisele saadetavaid teateid nooled, mis näitavad teate nime, parameetreid ja teate järgnevust. Koostööskeemid sobivad eriti hästi esitama spetsiifilist programmikulgu või situatsiooni ning need on parim skeemitüüp konkreetse protsessi kiireks demonstreerimiseks või seletamiseks programmiloogikas.
umbrello; showing a Collaboration Diagram
umbrello; koostööskeemiga
State Diagram
Olekuskeem
State Diagrams show the different states of an Object during its life and the stimuli that cause the Object to change its state.
Olekuskeemid näitavad objekti erinevaid olekuid selle eluea kestel ning stiimuleid, mis põhjustavad objekti oleku muutumise.
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:
Olekuskeemid käsitlevad objekte olekumasinatena ehk lõplike automaatidena, mis võivad olla ühes lõplike olekute kogumis ning muuta oma olekut lõpliku stiimulikogumi vahendusel. Nii võib näiteks objekt tüübiga NetServer olla oma eluea kestel ühes järgmistest olekutest:
Ready
valmis
Listening
jälgimine
Stopped
peatatud
and the events that can cause the Object to change states are
ning sündmused, mis põhjustavad objekti oleku muutuse, on järgmised:
Object is created
objekt luuakse
Object receives message listen
objekt saab teate jälgida
A Client requests a connection over the network
klient soovib võrguühendust
A Client terminates a request
klient katkestab soovi
The request is executed and terminated
soov täidetakse ja lõpetatakse
Object receives message stop
objekt saab teate peatuda
umbrello; showing a State Diagram
umbrello; olekuskeemiga
State
Olek
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
Olekud on olekuskeemide ehituskivid. Olek kuulub täpselt ühte klassi ning esindab väärtuste kokkuvõtet, mida klassi atribuudid võivad omada. & UML; i olek kirjeldab konkreetse klassi objekti seesmist olekut.
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
Pane tähele, et mitte kõiki objekti mõne atribuudi muutusi ei esinda olek, vaid ainult neid muutusi, mis mõjutavad märgatavalt objekti käitumist.
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.
Kaks olekutüüpi on erilised: algus ja lõpp. Need on erilised selle poolest, et ükski sündmus ei saa põhjustada objekti tagasipöördumist algusolekusse ning mitte ükski sündmus ei saa viia objekti välja lõppolekust, kui objekt on sellesse olekusse kord juba jõudnud.
Activity Diagram
Tegevusskeem
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.
Tegevusskeemid kirjeldavad tegevuste järgnevust süsteemis tegevuste abil. Tegevusskeemid on olekuskeemide erivorm, mis sisaldavad ainult või peamiselt tegevusi.