Cxu Vere ?? Re: [Kde-i18n-eo] Re: About esperanto version of "Umbrello UML Modeller"

Martin Ponce mjp_ttc at yahoo.com
Sat May 28 08:55:05 UTC 2005 

Jes, pri tio vidu mesagxojn de Heiko.

Saluton.

--- Oliver.Kellogg at t-online.de wrote:

> On Saturday 28 May 2005 08:03, Martin Ponce wrote:
> > Cxu Vere ???
> >
> 
> Nu, jes. Jen mi komencis traduki plian datumaron (vd. algulajhon - sed
> forjhetu tion, mi tre baldau sendos kompletan tradukon)
> 
> Vi estas la ununura de kiu mi vidis respondon, do mi simple faros tiun
> laboron - cxu kun, cxu sen kunuloj...
> 
> La nura pri kio mi malcertas estas chu DocBoook estas ankorau la ghusta
> formato. Mi vidis mesaghon ke oni shanghis al iu PO-formato? Chu?
> 
> Ghis,
> 
>   Oliver
> 
> -- chefevangelisto, Umbrello UML Modeller
> -- http://uml.sourceforge.net
> 
> > <chapter id="uml-basics">
> <title
> >&UML; Basics</title>
> <sect1 id="about-uml">
> <title
> >About &UML;</title>
> <para
> >Ĉi tiu ĉapitro volas doni rapidan resumon de la fundamentoj de &UML;.
> Memoru ke ĉi tiu ne estas ampleksa seminario pri UML sed tamen konciza
> enkonduko al UML kiu povas esti legata kiel UML kompendio. Se vi ŝatas lerni
> pli pri la Uniĝinta Modelad-Lingvo, aŭ ĝenerale pri softvar-analizo kaj
> -desegno, konsultu unu el la multaj libroj haveblaj pri la temo. Ekzistas
> ankaÅ­ multaj seminarioj en la Interreto kiujn vi povas preni kiel
> deirpunkto.
> </para>
> 
> <para
> >La Uniĝinta Modelad-Lingvo (&UML;) estas skema lingvo aŭ notacio por
> specifi, bildigi kaj dokumenti modelojn de objekt-orientitaj
> softvar-sistemojn. &UML; ne estas disvolviĝa metodo, tio signifas ke ĝi ne
> diktas kion fari unue kaj kion poste, aŭ kiel desegni vian sistemon, sed ĝi
> helpas vin bildigi vian desegnon kaj komuniki ĝin al aliaj. &UML; estas
> regata far la Objekt-Mastrumada Grupo (<acronym
> >OMG</acronym
> >) kaj estas la industria normo por grafike priskribi softvaron.
> </para>
> <para
> >&UML; estas konceptita por objekt-orientata softvar-desegno kaj nur limigite
> alpikiĝas al aliaj programadaj paradigmoj. </para>
> <para
> >&UML; konsistas el multaj model-elementoj kiuj reprezentas la diversajn
> partojn de softvarsistemo. La &UML; elementoj estas uzataj por krei
> diagramojn kiuj reprezentas certan parton aÅ­ vidpunkton de la sistemo. La
> sekvontaj specoj de diagramoj estas subtenataj per &umbrello;: </para>
> 
> <itemizedlist>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="use-case-diagram"
> >Uzkazdiagramoj</link
> ></emphasis
> > montras aktorojn (homojn aÅ­ aliajn uzantojn de la sistemo), uzokazojn (la
> scenaroj kiam aktoroj uzas la sistemon), kaj iliajn interrilatojn</para
> > </listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="class-diagram"
> >Klasdiagramoj</link
> ></emphasis
> > montras klasojn kaj ties interrilatojn</para
> > </listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="sequence-diagram"
> >Sinsekvodiagramoj</link
> ></emphasis
> > montras objektojn kaj sinsekvon de metod-alvokoj kiujn ili faras ĉe aliaj
> objektoj.</para
> > </listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="collaboration-diagram"
> >Kunlabordiagramoj</link
> ></emphasis
> > montras objektojn kaj ties interrilaton, emfazante la objektojn kiuj
> partoprenas en la interŝanĝo de mesaĝoj </para>
> </listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="state-diagram"
> >Statodiagramoj</link
> ></emphasis
> > montras statojn, statoŝanĝojn kaj eventojn en objekto aŭ en parto de la
> sistemo</para
> > </listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="activity-diagram"
> >Aktivecdiagramoj</link
> ></emphasis
> > montras aktivecojn kaj la ŝanĝoj de unu aktiveco al alia kune kun la
> eventoj okazantaj en iu parto de la sistemo</para
> ></listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="component-diagram"
> >Komponentaj Diagramoj</link
> ></emphasis
> > montras la altnivelajn programkomponantojn (kiel ekz. KParts aÅ­ Java
> Beans).</para
> ></listitem>
> 
> <listitem
> ><para
> ><emphasis
> ><link linkend="deployment-diagram"
> >Sterndiagramoj</link
> ></emphasis
> > montras la instancojn de la komponantoj kaj iliajn interrilatojn.</para
> ></listitem
> > 
> 
> </itemizedlist>
> 
> </sect1
> >   <!-- about-uml -->
> 
> <sect1 id="uml-elements"
> >  
> <title
> >&UML; Elements</title>
> <sect2 id="use-case-diagram">
> <title
> >Uzkazdiagramo</title>
> <para
> >Uzokazaj diagramoj priskribas la rilatojn kaj dependojn inter grupo da
> <emphasis
> >Uzkazoj</emphasis
> > kaj la Aktoroj partoprenantaj en la procedo.</para>
> <para
> >Gravas rimarki ke uzkazdiagramoj ne adekvatas por reprezenti la desegnon,
> kaj ne povas priskribi la internon de sistemo. Uzkazoskemoj celas faciligi la
> komunikadon kun la estontaj uzantoj de la sistemo, kaj kun la kliento, kaj
> estas specife taÅ­gaj por determini la postulatajn trajtojn kiujn la sistemo
> havu. Uzkazdiagramoj indikas <emphasis
> >kion</emphasis
> > la sistemo faru sed ne <emphasis
> >kiel</emphasis
> > tio estu atingata.</para>
> <para>
> <screenshot>
> <screeninfo
> >Ekzempla UzKazDiagramo.</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="use-case-diagram.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >&umbrello; montranta uzkazdiagramon</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >&umbrello; montranta uzkazdiagramon </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> <sect3 id="use-case">
> <title
> >Uzokazo</title>
> <para
> ><emphasis
> >Uzokazo</emphasis
> > priskribas — de la vidpunkto de la aktoroj — grupon da
> aktivecoj en sistemo kiu produktas konkretan, palpeblan rezulton.</para>
> <para
> >Uzkazoj estas priskriboj de la tipaj interagadoj inter la uzantoj de sistemo
> kaj la sistemo mem. Ili reprezentas la eksteran interfacon de la sistemo kaj
> detaligas certforme la postulojn de tio, kion la sistemo plenumu (ja memoru:
> nur kion, ne kiel). </para>
> <para
> >Traktante uzkazojn, gravas memori kelkajn simplajn regulojn: <itemizedlist>
>  <listitem
> ><para
> >Ĉiu uzkazo rilatas al almenaŭ unu aktoro</para
> ></listitem>
>  <listitem
> ><para
> >Ĉiu uzkazo havas iniciatinton (tio estas aktoro)</para
> ></listitem>
>  <listitem
> ><para
> >Ĉiu uzkazo kaŭzas rilatan rezulton (rezulton kun <quote
> >komerca valoro</quote
> >)</para>
>  </listitem>
>  </itemizedlist>
> </para>
> <para
> >Uzkazoj ankaÅ­ povas havi interrilatojn kun aliaj uzkazoj. La tri plej tipaj
> specoj de interrilatoj inter uzkazoj estas:
> </para>
> <itemizedlist>
> <listitem
> ><para
> ><emphasis
> ><<include>></emphasis
> > kiu specifigas, ke uzkazo okazas <emphasis
> >ene de</emphasis
> > alia uzkazo</para
> ></listitem>
> <listitem
> ><para
> ><emphasis
> ><<extends>></emphasis
> > kiu specifigas ke en iuj situacioj, aÅ­ je iu punkto (nomita etendadpunkto)
> uzkazo estos etendita per alia.</para
> ></listitem>
> <listitem
> ><para
> ><emphasis
> >Generalization</emphasis
> > specifigas uzkazo heredas la karakterizaĵoj de la <quote
> >Super</quote
> >-uzkazo kaj povas superregi iujn aÅ­ aldoni novajn en simila maniero kiel la
> heredado inter klasoj.  </para>
> </listitem>
> </itemizedlist>
> </sect3>
> <sect3 id="actor">
> <title
> >Aktoro</title>
> <para
> >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. </para>
> <para
> >Actors do not represent the <emphasis
> >physical</emphasis
> > people or systems, but their <emphasis
> >role</emphasis
> >. 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
> <quote
> >Support Staff</quote
> > and an actor <quote
> >Sales Representative</quote
> > </para>
> </sect3>
> <sect3 id="use-case-description">
> <title
> >Use Case Description</title>
> <para
> >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.
> </para>
> </sect3>
> </sect2
> > <!-- use-case-diagram -->
> 
> <sect2 id="class-diagram">
> <title
> >Class Diagram</title>
> <para
> >Class Diagrams show the different classes that make up a system and how they
> relate to each other. Class Diagrams are said to be <quote
> >static</quote
> > diagrams because they show the classes, along with their methods and
> attributes as well as the static relationships between them: which classes
> <quote
> >know</quote
> > about which classes or which classes <quote
> >are part</quote
> > of another class, but do not show the method calls between them. </para>
> <para>
> <screenshot>
> <screeninfo
> >An example of a Class Diagram</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="class-diagram.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >&umbrello; showing a Class Diagram</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >&umbrello; showing a Class Diagram </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> <sect3 id="class">
> <title
> >Class</title>
> <para
> >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
> <quote
> >Type</quote
> > 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. </para>
> <para
> >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
> <quote
> >compartments</quote
> > inside the rectangle. </para>
> <para>
> <screenshot>
> <screeninfo
> >A Class in &UML;</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="class.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >Visual representation of a Class in &UML;</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >Visual representation of a Class in &UML; </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> <sect4 id="attribute">
> <title
> >Attributes</title>
> <para
> >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: </para>
> <itemizedlist>
> <listitem
> ><para
> ><literal
> >+</literal
> > Stands for <emphasis
> >public</emphasis
> > attributes</para
> ></listitem>
> <listitem
> ><para
> ><literal
> >#</literal
> > Stands for <emphasis
> >protected</emphasis
> > attributes</para
> ></listitem>
> <listitem
> ><para
> ><literal
> >-</literal
> > Stands for <emphasis
> >private</emphasis
> > attributes</para
> ></listitem>
> </itemizedlist>
> </sect4>
> <sect4 id="operation">
> <title
> >Operations</title>
> <para
> >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: <itemizedlist>
> <listitem
> ><para
> ><literal
> >+</literal
> > Stands for <emphasis
> >public</emphasis
> > operations</para
> ></listitem>
> <listitem
> ><para
> ><literal
> >#</literal
> > Stands for <emphasis
> >protected</emphasis
> > operations</para
> ></listitem>
> <listitem
> ><para
> ><literal
> >-</literal
> > Stands for <emphasis
> >private</emphasis
> > operations</para
> ></listitem>
> </itemizedlist>
> </para>
> </sect4>
> 
> <sect4 id="templates">
> <title
> >Templates</title>
> <para
> >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. </para>
> </sect4>
> </sect3>
> 
> <sect3 id="class-associations">
> <title
> >Class Associations</title>
> <para
> >Classes can relate (be associated with) to each other in different
> ways:</para>
> <sect4 id="generalization">
> <title
> >Generalisation</title>
> <para
> >Inheritance is one of the fundamental concepts of Object Orientated
> programming, in which a class <quote
> >gains</quote
> > 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.</para>
> <para
> >In &UML;, a <emphasis
> >Generalisation</emphasis
> > 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. <screenshot>
> <screeninfo
> >Generalisation</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="generalization.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >Visual representation of a generalisation in &UML;</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >Visual representation of a generalisation in &UML; </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> </sect4>
> 
> <sect4 id="uml-associations">
> <title
> >Associations</title>
> <para
> >An association represents a relationship between classes, and gives the
> common semantics and structure for many types of <quote
> >connections</quote
> > between objects.</para>
> <para
> >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 <emphasis
> >link</emphasis
> >. </para>
> <para
> >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. </para>
> <para
> >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 (<literal
> >*</literal
> >) on the maximum side representing infinite. <screenshot>
> <screeninfo
> >&UML; Association</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="association.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >Visual representation of an Association in &UML;</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >Visual representation of an Association in &UML; </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> </sect4>
> 
> <sect4 id="aggregation">
> <title
> >Aggregation</title>
> <para
> >Aggregations are a special type of associations in which the two
> participating classes don't have an equal status, but make a <quote
> >whole-part</quote
> > 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. </para>
> <para
> >In &UML;, Aggregations are represented by an association that shows a rhomb
> on the side of the whole. <screenshot>
> <screeninfo
> >Aggregation</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="aggregation.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >Visual representation of an Aggregation relationship in &UML;</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >Visual representation of an Aggregation relationship in &UML; </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> </sect4>
> <sect4 id="composition">
> <title
> >Composition</title>
> <para
> >Compositions are associations that represent <emphasis
> >very strong</emphasis
> > 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.</para>
> <para
> >In &UML;, Compositions are represented by a solid rhomb on the side of the
> whole. </para>
> <para
> ><screenshot>
> <screeninfo
> >Composition</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="composition.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >Visual representation of a Composition relationship in &UML;</phrase>
> 	  </textobject>
> 	</mediaobject>
> </screenshot
> ></para>
> </sect4>
> </sect3
> > <!--class-associations-->
> 
> <sect3 id="other-class-diagram-items">
> <title
> >Other Class Diagram Items</title>
> <para
> >Class diagrams can contain several other items besides classes.</para>
> <sect4 id="interfaces">
> <title
> >Interfaces</title>
> <para
> >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.</para>
> <!-- FIXME screenshot -->
> </sect4>
> <sect4 id="datatype">
> <title
> >Datatypes</title>
> <para
> >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.</para>
> <!-- FIXME screenshot -->
> </sect4>
> <sect4 id="enum">
> <title
> >Enums</title>
> <para
> >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.</para>
> <!-- FIXME screenshot -->
> </sect4>
> <sect4 id="package">
> <title
> >Packages</title>
> <para
> >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.</para>
> <!-- FIXME screenshot -->
> </sect4>
> </sect3>
> 
> </sect2
> > <!-- class diagram -->
> 
> <sect2 id="sequence-diagram">
> <title
> >Sequence Diagrams</title>
> 
> <para
> >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.</para>
> 
> <para
> >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. </para>
> 
> <!-- FIXME update screenshot to show synchronous messages -->
> <screenshot>
> <screeninfo
> >Sequence Diagram</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="sequence-diagram.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >&umbrello; showing a Sequence Diagram</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >&umbrello; showing a Sequence Diagram </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> 
> <para
> >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.</para>
> </sect2
> > <!-- sequence diagrams -->
> 
> <sect2 id="collaboration-diagram">
> <title
> >Collaboration Diagrams</title>
> 
> <para
> >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.</para>
> 
> <para
> >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. </para>
> 
> <screenshot>
> <screeninfo
> >Collaboration</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="collaboration-diagram.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >&umbrello; showing a Collaboration Diagram</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >&umbrello; showing a Collaboration Diagram </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> 
> </sect2
> > <!-- collaboration diagrams -->
> 
> <sect2 id="state-diagram">
> <title
> >State Diagram</title>
> <para
> >State Diagrams show the different states of an Object during its life and
> the stimuli that cause the Object to change its state. </para
> >                              
> <para
> >State Diagrams view Objects as <emphasis
> >state machines</emphasis
> > 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 <emphasis
> >NetServer</emphasis
> > can be in one of following states during its life: </para>
> <itemizedlist>
> <listitem
> ><para
> >Ready</para
> ></listitem>
> <listitem
> ><para
> >Listening</para
> ></listitem>
> <listitem
> ><para
> >Working</para
> ></listitem>
> <listitem
> ><para
> >Stopped</para
> ></listitem>
> </itemizedlist>
> <para
> >and the events that can cause the Object to change states are</para>
> <itemizedlist>
> <listitem
> ><para
> >Object is created</para
> ></listitem>
> <listitem
> ><para
> >Object receives message listen</para
> ></listitem>
> <listitem
> ><para
> >A Client requests a connection over the network</para
> ></listitem>
> <listitem
> ><para
> >A Client terminates a request</para
> ></listitem>
> <listitem
> ><para
> >The request is executed and terminated</para
> ></listitem>
> <listitem
> ><para
> >Object receives message stop</para
> ></listitem>
> <listitem
> ><para
> >etc</para
> ></listitem>
> </itemizedlist>
> <para>
> <screenshot>
> <screeninfo
> >State Diagram</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="state-diagram.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >&umbrello; showing a State Diagram</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >&umbrello; showing a State Diagram </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> <sect3 id="state">
> <title
> >State</title>
> <para
> >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 </para
> >                       
> <para
> >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</para>
> <para
> >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. </para>
> </sect3>
> 
> </sect2
> > <!-- state diagrams -->
> 
> <sect2 id="activity-diagram">
> <title
> >Activity Diagram</title>
> <para
> >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. </para>
> <para>
> <screenshot>
> <screeninfo
> >An example Activity Diagram.</screeninfo>
> 	<mediaobject>
> 	  <imageobject>
> 	    <imagedata fileref="activity-diagram.png" format="PNG"/>
> 	  </imageobject>
> 	  <textobject>
> 	    <phrase
> >&umbrello; showing an Activity Diagram</phrase>
> 	  </textobject>
> 	  <caption>
> 	    <para
> >&umbrello; showing an Activity Diagram </para>
> 	  </caption>
> 	</mediaobject>
> </screenshot>
> </para>
> <para
> >Activity Diagrams are similar to procedural Flux Diagrams, with the
> difference that all Activities are clearly attached to Objects.</para>
> 
> <para
> >Activity Diagrams are always associated to a <emphasis
> >Class</emphasis
> >, an <emphasis
> >Operation</emphasis
> > or a <emphasis
> >Use Case</emphasis
> >.</para>
> 
> <para
> >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)</para>
> <sect3 id="activity">
> <title
> >Activity</title>
> <para
> >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. </para
> > 
> <para
> >Activities can form hierarchies, this means that an Activity can be composed
> of several <quote
> >detail</quote
> > Activities, in which case the incoming and outgoing transitions should
> match the incoming and outgoing transitions of the detail diagram. </para>
> 
> </sect3>
> </sect2
> > <!-- activity diagram -->
> 
> <sect2 id="helper-elements">
> <title
> >Helper Elements</title>
> <para
> >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 </para>
> <itemizedlist>
> <listitem
> ><para
> >Text lines</para
> ></listitem>
> <listitem
> ><para
> >Text Notes and anchors</para
> ></listitem>
> <listitem
> ><para
> >Boxes</para
> ></listitem>
> </itemizedlist
> >   
> <para
> >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. </para
> >           
> 
> <para
> >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 <quote
> >belongs</quote
> > to a specific object or situation. </para>
> 
> <para
> >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.</para>
> 
> <!-- FIXME, screenshot -->
> </sect2
> > <!-- helper elements -->
> 
> <sect2 id="component-diagram">
> <title
> >Component Diagrams</title>
> <para
> >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.</para>
> 
> <para
> >Components can have interfaces (&ie; abstract classes with operations) that
> allow associations between components.</para>
> </sect2>
> 
> <sect2 id="deployment-diagram">
> <title
> >Deployment Diagrams</title>
> 
> <para
> >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).</para>
> 
> </sect2>
> 
> </sect1
> > 
> </chapter>
> > _______________________________________________
> Kde-i18n-eo mailing list
> Kde-i18n-eo at kde.org
> https://mail.kde.org/mailman/listinfo/kde-i18n-eo
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

More information about the Kde-i18n-eo mailing list