natgillin/translations-raw huggingface dataset:
En beskrivelse af et brugstilfælde er en tekstbaseret beretning om brugstilfældet. Det er ofte i form af en note eller et dokument som på en eller anden måde er linket til brugstilfældet, og forklarer processerne eller aktiviteterne som finder sted i brugstilfældet.
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.
Klassediagrammer viser de forskellige klasser som opbygger et system og hvordan de relateres til hinanden. Klassediagrammer siges at være statiske diagrammer, fordi de viser klasserne, sammen med deres metoder og attributter, samt det statiske forhold mellem dem: hvilke klasser der kender til andre klasser, eller hvilke klasser der er en del af andre klasser, men viser ikke metodekald mellem dem.
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.
Et eksempel på et klassediagram
An example of a Class Diagram
umbrello; som viser et klassediagram
umbrello; showing a Class Diagram
En klasse definerer attributterne og metoderne for en mængde af objekter. Alle objekter af klassen (instanser af klassen) deler samme opførsel, og har samme mængde af attributter (hvert objekt har sin egen mængde). Udtrykket type bruges ind imellem i stedet for klasse, men det er vigtigt at nævne at de to ikke er det samme, og at type er et mere generelt udtryk.
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.
Klasser i & UML; repræsenteres af rektangler, med klassens navn, og kan også vise klassens attribut og operationer i to afdelinger inde i rektanglet.
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.
En klasse i & UML;
A Class in & UML;
Visuel repræsentation af en klasse i & UML;
Visual representation of a Class in & UML;
Attribut
Attributes
Attributter i UML vises i det mindste med deres navne, og kan også vises med type, oprindelig værdi og andre egenskaber. Attribut kan også vises med synlighed:
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:
+ Står for åbne (public) attributter
+ Stands for public attributes
# Står for beskyttede (protected) attributter
# Stands for protected attributes
- Står for private (private) attributter
- Stands for private attributes
Operationer (metoder) vises også i det mindste med deres navne, og kan også vises med parametre og returtyper. Operationer, præcis som attributter, kan vises med deres synlighed:
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:
+ Står for åbne (public) operationer
+ Stands for public operations
# Står for beskyttede (protected) operationer
# Stands for protected operations
- Står for private (private) operationer
- Stands for private operations
Klasser kan have skabeloner, en værdi som bruges for en uspecificeret klasse eller type. Skabelontypen angives når klassen initieres (dvs. et objekt laves). Skabeloner findes i moderne C++ og vil blive introduceret i Java 1. 5, hvor de kaldes Generics.
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.
Klasseassociationer
Class Associations
Klasser kan relateres til (associeres med) hinanden på forskellige måder:
Classes can relate (be associated with) to each other in different ways:
Generalisering
Generalisation
Arv er et af de grundlæggende begreber i objektorienteret programmering, hvor en klasse opnår alle attributter og operationer fra klassen den arver fra, og kan overskride/ ændre nogen af dem, samt tilføje flere egne attributter og operationer.
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.
En generalisering mellem to klasser i & UML;, placerer dem i et hierarki som repræsenterer arvebegrebet for en afledt klasse fra en basisklasse. Generaliseringer i & UML; repræsenteres med en linje som binder de to klasser sammen, med en pil på basisklassens side.
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.
Visuel repræsentation af en generalisering i & UML;
Visual representation of a generalisation in & UML;
Associationer
Associations
En association repræsenterer et forhold mellem klasser, og giver den fælles semantik og struktur for mange typer af forbindelser mellem objekter.
An association represents a relationship between classes, and gives the common semantics and structure for many types of connections between objects.
Associationer er mekanismen som tillader at objekter kommunikerer med hinanden. De beskriver forbindelsen mellem forskellige klasser (forbindelsen mellem de virkelige objekter kaldes objektforbindelser, eller link).
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.
Associationer kan have en rolle, som angiver associationens formål, og kan være ensrettede eller gensidige (indikerer om de to objekter som deltager i forholdet kan sende meddelelser til hinanden, eller om kun et af dem kender til det andet). Hver eneste af associationerne har også en multiplicitet, som bestemmer hvor mange objekter på denne side af associationen kan relateres til et objekt på den anden side.
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.
Associationer i & UML; repræsenteres som linjer som binder de klasser sammen som deltager i forholdet, og kan også vise rollen og multipliciteten for hver af deltagerne. Multiplicitet vises som et interval [minimum.. maksimum] med ikke- negative værdier, med en stjerne (*) på maksimumsiden som repræsenterer uendeligt.
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; - association
& UML; Association
Visuel repræsentation af en association i & UML;
Visual representation of an Association in & UML;
Aggregering
Aggregation
Aggregeringer er en særlig slags association, hvor de to deltagende klasser ikke har en ligeværdig status, men udgør et helhed- del forhold. En aggregering beskriver hvordan klassen som intager rollen som helhed, er sammensat af (har) andre klasser, som intager rollerne som dele. Klassen der virker som helhed har altid multiplicitet en, for aggregeringer.
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.
Aggregeringer i & UML; repræsenteres ved en association som viser en rombe på den side som hører til helheden.
In & UML;, Aggregations are represented by an association that shows a rhomb on the side of the whole.
Visuel repræsentation af en aggregeringsrelation i & UML;
Visual representation of an Aggregation relationship in & UML;
Sammensætninger er associationer som repræsenterer meget stærke aggregeringer. Det betyder at sammensætninger også former helhed- del forhold, men at forholdet er så stærkt at delene ikke kan eksistere for sig selv. De findes kun inde i helheden, og hvis helheden forstyrres, forsvinder delene også.
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.
Sammensætninger i & UML; repræsenteres af en udfyldt rombe på siden af helheden.
In & UML;, Compositions are represented by a solid rhomb on the side of the whole.
Visuel repræsentation af en sammensætningsrelation i & UML;
Visual representation of a Composition relationship in & UML;
Andre punkter i klassediagrammer
Other Class Diagram Items
Klassediagrammer kan indeholde flere andre objekter foruden klasser.
Class diagrams can contain several other items besides classes.
Grænseflade er abstrakte klasser hvilket betyder at instanser ikke direkte kan skabes fra dem. De kan indehold operationer men ingen attributter. Klasser kan arve fra grænseflader (via en realisationsassociation) og instanser kan derefter laves af disse diagrammer.
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.
Datatyper
Datatypes
Datatyper er primitiver som typisk er indbyggede i et programsprog. Almindelige eksempler omfatter heltal og en boolesk type. De kan ikke have forhold til klasser, men klasser kan have forhold til dem.
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.
Gentagelsestyper
Enums
Gentagelsestyper er enkle lister med værdier. Et typisk eksempel er en nummereringstype af ugedage. Tilvalgene for en gentagelsestype kaldes Enum Literals. Som datatyper kan de ikke have forhold til klasser, men klasser kan have forhold til dem.
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.
Pakker
Packages
Pakker repræsenterer navnerum i et programsprog. I et diagram bruges de til at repræsentere dele af et system som indeholder mere end en klasse, måske hundredvis af klasser.
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.
Sekvensdiagrammer
Sequence Diagrams
Sekvensdiagrammer viser udveksling af meddelelser (dvs. metodekald) mellem flere objekter, i en specifik, tidsbegrænset situation. Sekvensdiagrammer lægger særlig vægt på rækkefølgen og tiden når meddelelserne til objekter sendes.
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.
Objekter repræsenteres af lodrette stregede linjer i sekvensdiagrammer, med objektets navn øverst. Tidsakslen er også lodret, og vokser nedad, så meddelelser sendes fra et objekt til et andet i form af pile med operationer og parameternavn.
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; som viser et sekvensdiagram
umbrello; showing a Sequence Diagram
Meddelelser kan enten være synkrone, den normale type for meddelelseskald hvor kontrollen overgår til det kaldte objekt til metoden er kørt færdigt, eller asynkrone hvor kontrollen går direkte tilbage til det kaldende objekt. Synkrone meddelelser har et lodret felt ved siden af det kaldte objektet, for at vise programkontrollen.
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.
Samarbejdsdiagrammer
Collaboration Diagrams
Samarbejdsdiagrammer viser vekselvirkningen mellem objekter som deltager i en speciel situation. Dette er mere eller mindre samme information som vises i sekvensdiagrammer, men hvor vægten lægges på hvordan vekselvirkningen sker i tiden, mens samarbejdsdiagrammer lægger vægten på forholdet mellem objekterne og deres topologi.
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.
I samarbejdsdiagrammer repræsenteres meddelelser fra et objekt til et andet med pile, som viser meddelelsens navn, parametre og meddelelsesekvensen. Samarbejdsdiagrammer er særligt passende til at vise en særlig programflydning eller situation, og er blandt de bedste diagramtyper til hurtigt at demonstrere eller forklare en process i programmets logik.
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.
umbrello; som viser et samarbejdsdiagram
umbrello; showing a Collaboration Diagram
Tilstandsdiagrammer viser de forskellige tilstande et objekt har i sin livstid, og de stimuli som forårsager at objektet ændrer sin tilstand.
State Diagrams show the different states of an Object during its life and the stimuli that cause the Object to change its state.
Tilstandsdiagrammer ser objekter som tilstandsmaskiner eller finite automates, som kan være i en af en mængde begrænsede tilstande og som kan ændre tilstand via et af et begrænset antal stimuli. Et objekt af typen Netserver, kan for eksempel være i en af følgende tilstande i sin livstid:
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:
Lytter
Listening
Arbejder
Working
Stoppet
Stopped
og begivenhederne som kan gøre at et objekt skifter tilstand er
and the events that can cause the Object to change states are
Objektet laves
Object is created
Objektet tager imod meddelelsen at lytte
Object receives message listen
En klient beder om en forbindelse via netværket
A Client requests a connection over the network
En klient afslutter en forespørgsel
A Client terminates a request
En forespørgsel køres og afsluttes
The request is executed and terminated
Objektet tager imod meddelelsen at stoppe
Object receives message stop
osv
etc
umbrello; som viser et tilstandsdiagram
umbrello; showing a State Diagram
Tilstand er byggeblokken i tilstandsdiagrammer. En tilstand hører til nøjagtig en klasse, og repræsenterer en sammenfatning af de værdier klassens attributter kan intage. En & UML; - tilstand beskriver den interne tilstand for et objekt af en vis klasse.
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
Bemærk at ikke hver ændring af en af et objekts attributter skal repræsenteres som en tilstand, men kun de ændringer som væsentligt kan påvirke objektets arbejde.
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
Der er to specielle typer tilstand: start og slut. De er specielle på den måde at der ikke er nogen begivenhed som kan gøre at et objekt går tilbage til sin starttilstand, og på samme måde er der ingen begivenhed som gør det muligt for et objekt at forlade sin sluttilstand når den først er nået.
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.
Aktivitetsdiagrammer beskriver en følge af begivenheder i et system, ved hjælp af aktiviteter. Aktivitetsdiagrammer er en speciel form af tilstandsdiagrammer, som kun (eller hovedsagelig) indeholder aktiviteter.
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.
Et eksempel på aktivitetsdiagram
An example Activity Diagram.
umbrello; som viser et aktivitetsdiagram
umbrello; showing an Activity Diagram
Aktivitetsdiagrammer ligner procedurelle flydediagrammer, med forskellen at alle aktiviteter er klart linkede til objekter.
Activity Diagrams are similar to procedural Flux Diagrams, with the difference that all Activities are clearly attached to Objects.
Aktivitetsdiagrammer hører altid sammen med en klasse, en operation eller et brugstilfælde.
Activity Diagrams are always associated to a Class, an Operation or a Use Case.
Aktivitetsdiagrammer understøtter sekventielle - og parallelle aktiviteter. Parallel kørsel repræsenteres med ikonen Del op/ Vent, og det er ikke vigtigt for aktiviteter som kører parallelt i hvilken rækkefølge de udføres (de kan køres samtidigt eller en af gangen).
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)
En aktivitet er et enkelt skridt i en process. En aktivitet er en tilstand i systemet med intern aktivitet og i det mindste en udgående overgang. Aktiviteter kan også have mere end en udgående overgang, hvis de har forskellige betingelser.
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.
Aktiviteter kan opbygge hierarkier, hvilket betyder at en aktivitet kan bestå af flere detaljeaktiviteter, hvor indkommende og udgående overgange skal passe sammen med de indkommende og udgående overgange i detaljediagrammet.
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.
Hjælpeelementer
Helper Elements
Der er nogle få elementer i & UML; som ikke har noget virkelig semantisk værdi for modellen, men som hjælper til at klargøre dele af diagrammerne. Disse elementer er
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
Tekstlinjer
Text lines
Noter og ankre
Text Notes and anchors
Tekstlinjer er nyttige til at tilføje kort tekstinformation i et diagram. Det er fritstående tekst, og har ingen betydning i selve modellen.
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.
Noter er nyttige til at tilføje mere detaljeret information om et objekt eller en særlig situation. De har den store fordel at noter kan ankres ved & UML; - elementer for at vise at noten hører til et særligt objekt eller en særlig situation.
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.
Bokse er fritstående rektangler som kan bruges til at gruppere objekter sammen, for at gøre diagrammer mere læsbare. De har ingen logisk mening i modellen.
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.
Komponentdiagrammer
Component Diagrams
Komponentdiagrammer viser programkomponenter (enten komponentteknologier såsom Kparts, CORBA- komponenter eller Java Beans eller kun dele af systemet som er klart udskillelige) og artefakterne de består af, såsom kildekodefiler, programbiblioteker eller relationsdatabasetabeller.
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.
Komponenter kan have grænseflader (dvs. abstrakte klasser med operationer) som tillader associationer mellem komponenter.
Components can have interfaces (ie; abstract classes with operations) that allow associations between components.
Udplaceringsdiagrammer
Deployment Diagrams
Udplaceringsdiagrammer viser komponentinstanserne ved kørsel og deres associationer. De omfatter knuder, som er fysiske ressourcer, typisk en enkelt maskine. De viser også grænseflader og objekter (klasseinstanser).
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).
Arbejde med & umbrello;
Working with & umbrello;