Ĉ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. 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 (OMG) kaj estas la industria normo por grafike priskribi softvaron. &UML; estas konceptita por objekt-orientata softvar-desegno kaj nur limigite alpikiĝas al aliaj programadaj paradigmoj. &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;: Uzkazdiagramoj montras aktorojn (homojn aŭ aliajn uzantojn de la sistemo), uzokazojn (la scenaroj kiam aktoroj uzas la sistemon), kaj iliajn interrilatojn Klasdiagramoj montras klasojn kaj ties interrilatojn Sinsekvodiagramoj montras objektojn kaj sinsekvon de metod-alvokoj kiujn ili faras ĉe aliaj objektoj. Kunlabordiagramoj montras objektojn kaj ties interrilaton, emfazante la objektojn kiuj partoprenas en la interŝanĝo de mesaĝoj Statodiagramoj montras statojn, statoŝanĝojn kaj eventojn en objekto aŭ en parto de la sistemo Aktivecdiagramoj montras aktivecojn kaj la ŝanĝoj de unu aktiveco al alia kune kun la eventoj okazantaj en iu parto de la sistemo Komponentaj Diagramoj montras la altnivelajn programkomponantojn (kiel ekz. KParts aŭ Java Beans). Sterndiagramoj montras la instancojn de la komponantoj kaj iliajn interrilatojn. Uzokazaj diagramoj priskribas la rilatojn kaj dependojn inter grupo da Uzkazoj kaj la Aktoroj partoprenantaj en la procedo. 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 kion la sistemo faru sed ne kiel tio estu atingata. Ekzempla UzKazDiagramo. &umbrello; montranta uzkazdiagramon &umbrello; montranta uzkazdiagramon Uzokazo priskribas — de la vidpunkto de la aktoroj — grupon da aktivecoj en sistemo kiu produktas konkretan, palpeblan rezulton. 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). Traktante uzkazojn, gravas memori kelkajn simplajn regulojn: Ĉiu uzkazo rilatas al almenaŭ unu aktoro Ĉiu uzkazo havas iniciatinton (tio estas aktoro) Ĉiu uzkazo kaŭzas rilatan rezulton (rezulton kun komerca valoro) Uzkazoj ankaŭ povas havi interrilatojn kun aliaj uzkazoj. La tri plej tipaj specoj de interrilatoj inter uzkazoj estas: <<include>> kiu specifigas, ke uzkazo okazas ene de alia uzkazo <<extends>> kiu specifigas ke en iuj situacioj, aŭ je iu punkto (nomita etendadpunkto) uzkazo estos etendita per alia. Generalization specifigas uzkazo heredas la karakterizaĵoj de la Super-uzkazo kaj povas superregi iujn aŭ aldoni novajn en simila maniero kiel la heredado inter klasoj. 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. 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 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. 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. An example of a Class Diagram &umbrello; showing a Class Diagram &umbrello; showing a Class Diagram 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. 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. A Class in &UML; Visual representation of a Class in &UML; Visual representation of a Class in &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: + Stands for public attributes # Stands for protected attributes - Stands for private attributes 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 # Stands for protected operations - Stands for private operations 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. Classes can relate (be associated with) to each other in different ways: Inheritance is one of the fundamental concepts of Object Orientated 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 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. Generalisation Visual representation of a generalisation in &UML; Visual representation of a generalisation in &UML; 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; Association Visual representation of an Association in &UML; Visual representation of an Association in &UML; Aggregations are a special type of associations in which the two participating classes don'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. Aggregation Visual representation of an Aggregation relationship in &UML; Visual representation of an Aggregation relationship in &UML; 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. Composition Visual representation of a Composition relationship in &UML; 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 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 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 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. Sequence Diagram &umbrello; showing a Sequence Diagram &umbrello; showing a Sequence Diagram 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 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; showing a Collaboration Diagram 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 State Diagram &umbrello; showing a State Diagram &umbrello; showing a State Diagram 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 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; showing an Activity Diagram 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) 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. 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 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. 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 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. Components can have interfaces (&ie; abstract classes with operations) that allow associations between components. 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).