Enterprise Arcitecht įrankio nagrinėjimas
AŠ NESUPRANTU KODEL NEĮMANOMA FAILO PRIKABINTI, KAI PRIKABINI IR PASPAUDI PATVIRTINTI VISTIEK IŠMETA KAD UŽPILDYTI VISUS LAUKUS (NET PAŽYMĖJUS, KAD SUTINKU SU TAISYKLĖMIS). DABAR PAVEIKSLĖLIAI NEĮSIKĖLĖ.
Turinys
UŽDUOTIS 3
ĮVADAS 4
1. ELGSENOS DIAGRAMOS 8
1.1. Veiklos diagramos 8
1.2. Būsenų diagrama 10
1.3. Laiko diagrama 11
1.4. Komunikacijų diagrama 12
1.5. Sekos diagrama 13
1.6. Panaudojimo atvejų diagrama 14
1.6.1. Analizės diagrama 15
2. STRUKTŪRINĖS DIAGRAMOS 17
2.1. Klasių diagrama 17
2.2. Objektų diagrama 19
2.3. Sudėtinės struktūros diagramos 20
2.4. Paketų diagrama 21
2.5. Išdėstymo digrama 22
2.6. Komponentų diagrama 23
3. IŠPLĖSTOS DIAGRAMOS 25
3.1. Poreikių diagrama 25
3.2. Vartotojo sąsajos diagrama 26
4. MODELIŲ KOMPONENTAI 28
5. MODELIŲ TARPUSAVIO SĄSAJOS 33
LITERATŪRA 34UŽDUOTIS
Darbo tikslas – išnagrinėti pasirinktą CASE įrankį, bei atlikti modeliavimą pasirinktos programinės įrangos pagalba.
Darbo uždaviniai:
Trumpai apžvelgti pasirinktą programinį produktą bei jame taikomą metodą;
Sumodeliuoti įrankyje esančių diagramų pavyzdžius pagal pasirinktą veiklos sritį.
Pateikti ddiagramą, kurioje būtų matoma modelių sąsaja
Pateikti literatūros sąrašą bei reikalingus priedus.ĮVADAS
Enterprise Architect yra visapusiškas UML analizės ir dizaino įrankis, apimantis programinės įrangos plėtrą nuo poreikių surinkimo per analizės stadijas, modeliavimą, testavimą ir įgyvendinimą. Tai įrankis, kuris gali būti naudojamas ne vieno vartotojo. Enterprise Architect yra grafinis įrankis, kuris padeda sukonstruoti programinę įrangą.
EA padeda valdyti painią visumą su įrankiu, kuris yra labai lankstus, turi daug modelių. Taip pat yra galimybė kurti ataskaitas. Ši programa palaiko reinžinerijos galimybes iš kodo daugeliui populiarių kkalbų, įskaitant ++, C#, Java, Delphi, VB.Net, Visual Basic, ActionScript ir PHP.
Sistemos reikalavimai, norint dirbti su EA:
Winodows versijai:
Intel® Pentium® procesorius (ar geresnis);
Microsoft® Windows 98 SE, Windows NT® 4.0 su Service Pack 5, Windows 2000, Windows XP ar Windows 2003.
128 MB RRAM (256MB ar daugiau)
70 MB laisvos kieto disko talpos;
800*600 ekrano (1024×768 ar didesnio)
Linux versijai:
Intel® Pentium II® procesoriau (ar ekvivalentaus)
CodeWeavers’ CrossoverOffice 2.1.0 (ar vėlesnio), Microsoft Data Access Components (MDAC) 2.8, DCOM95, Internet Explorer 6
Linux operacinės sistemos (kernel 2.4 ar vėlesnės)
64 MB RAM (128 MB ar daugiau)
70 MB laisvos kieto disko talpos;
800*600 ekrano (1024×768 ar didesnio)
Su šia programa galima atlikti transformacijas į:
C#;
DDL;
EJB Entity;
EJB Session;
Java;
Junit;
Nunit;
WSDL;
XSD.
Enterprise Architect paremtas UML modeliavimu. UML – Unified Modeling Language – yra standartinė modeliavimo kalba su turtinga grafine notacija ir visapusišku diagramų bei elementų rinkiniu. UML pirmą kartą pasirodę 1990 metais, kuri turėjo išrinkti iš daugybės modeliavimo sistemų, kurios tuo metu buvo siūlomos, elementų išrinkti geriausius ir sujungti į vieną visumą. Nuo to laiko UML tapo pripažintu standartu. Enterprise AArchitect apima visas 13 UML2 diagramų.
Enterprise Architect taip pat palaiko MDA. Model Driven Architecture (MDA) yra geras būdas valdyti sudėtingą visumą, pasiekti gerų rezultatų bei sumažinti plėtojimo keblumus, kurie kyla plėtojant programinės įrangos projektus.
EA gali naudoti įvairių kvalifikacijų specialistai.
Biznio analitikai gali kurti aukšto lygio biznio procesų modelius. Tai apima biznio reikalavimus, veiklas, darbo srautus ir naudojamą sistemos elgseną. Biznio analitikas gali kurti:
Analizės diagramas, kurios yra veiklos diagramos poaibis;
reikalavimų diagramas;
Veiklos diagramas, kurios modeliuoja sistemos elgseną ir būdus, kuriais ši elgsena yyra susijusi su visu sistemos srautu;
Use Case diagramas, kurios gali padėti lengviau suprasti suprasti funkcinius reikalavimus ir sistemos elgseną.
Plėtotojas gali naudoti:
Klasių diagramas;
State Machine, Package ir veiklos diagramos, kurios gali padėti plėtotojui geriau suprasti sąveikas tarp kodo elementų bei geriau suprasti pačio kodo išdėstymą.
Projekto valdytojas gali panaudoti EA paskirstant išteklius, matuojant riziką bei matuojant projekto dydį. Taip pat gali pakeisti kontroliavimą bei elementų priežiūrą.
Naudojant EA galima atlikti testavimus testuotojams. Testuojant galima pridėti scenarijus elementams, o elementų trūkumai gali būti panaudoti problemų ataskaitose.
Programinės įrangos architektai gali naudoti EA funkcinių reikalavimų išdėstymui panaudojant:
Use case diagramas;
taip pat sąveikos diagramas,
Išdėstymo,
bei komponentų modelius
Tinklo administratoriai gali naudoti deployment diagramas, kad sudarytų tinklo išdėstymą. Deployment diagramos taip pat gali būti panaudotos darbo stočių išdėstymui.
Technologiniai plėtotojai bei DB administratoriai taip pat naudoja EA.
Su EA programinės įrangos inžinierius gali paimti use case iš programinės įrangos architekto ir sukurti klasių diagramas, kurios užpildo tikslus, apibrėžtus use case diagramose.
Šioje programoje yra visos UML2 diagramos ir keletas kitų. Diagramos yra surūšiuotos į tris dalis:
Struktūrinės diagramos:
.
Class – klasių;
Object – objektų;
Composite structure – sudėtinės;
Package – paketų;
Component – komponentų;
Deployment – išdėstymo.
Elgsenos diagramos (behaviour):
Use Case;
Communication – komunikacijų;
Sequence – sekų;
Interaction Overview – sąveikos peržiūros;
Activity – veiklos;
State – būsenų;
Timing – laikinės.
Kitos išplėstos:
Analysis (simple activity) aanalizės (paprastos veiklos);
Custom – išplėstinės:
Requirements – poreikių
User interface – vartotojo sąsajos
Toliau pateikti kiekvienos diagramos pavyzdžiai. Jie yra orientuoti į elektroninės knygų parduotuvės veiklą.1. ELGSENOS DIAGRAMOS
Elgsenos diagramos yra sekančios:
Veiklos diagrama – activity;
Panaudojimo atvejo diagrama – use case;
Būsenų diagrama – state mashine;
Sąveikos diagramos – interaction. Jomis gali būti bet kuri iš šių:
• Komunikacinė diagrama;
• Sekų diagrama – sequence;
• Laiko diagrama – timing;
• Interaction Overview – sąveikos peržiūros;
Toliau yra aprašytos visos elgsenos diagramos ir pateikti pavyzdžiai.1.1. Veiklos diagramos
Veiklos diagramos naudojamos modeliuoti sistemos elgseną ir kaip ši elgsena susijusi su visos sistemos srautais. Daugelis loginių procesų srautų remiasi sąlygomis, konkurenciniais procesais, duomenų priėjimu ir kitomis loginėmis savybėmis.
1 pav. Veiklos diagrama
Diagramoje pavaizduota kaip vartotojas internete gali nusipirkti prekę.
Toliau pateikti veiklos diagramos elementai ir sujungimai:
2 pav. Veiklos diagramos komponentai1.2. Būsenų diagrama
Ši diagrama iliustruoja kaip elementai, dažniausiai klasė gali judėti tarp būsenų ir klasifikuoja elgseną remiantis trigeriais, apsaugomis ir kitais aspektais. Ši diagrama paaiškina judėjimą ir elgseną.
3 pav. Būsenų diagrama
Diagramos elementai ir sujungimai:
4 pav. Būsenų diagramos komponentai1.3. Laiko diagrama
Laiko diagrama apibrėžia skirtingų objektų elgseną laiko skalėje. Ji parodo objektų pasikeitimo būsenas ir sąveiką laike.
Taip pat šios diagramos gali būti naudojamos apibrėžti įterptus techninės ar programinės įrangos komponentus bei gali būti naudojamos specifikuoti biznio procesus laike.
5 pav. Laiko diagrama
Diagramos elementai:
6 pav. Laiko diagramos komponentai1.4. Komunikacijų diagrama
Komunikacijų ddiagrama parodo sąveiką tarp elementų esamuoju laiku panašiai kaip sekos diagrama. Tačiau komunikacijų diagramos naudojamos atvaizduoti interobjektų ryšius, o sekos diagrama vaizduoja procesus per tam tikrą laiką.
7 pav. Komunikacijų diagrama
Komunikacijų diagramos elementai ir sujungimai:
8 pav. Komunikacijų diagramos komponentai1.5. Sekos diagrama
Sekos diagrama yra struktūrizuota elgsenos reprezentacija paeiliui einant laike. Ji naudojama atvaizduoti srautus, pranešimus ir tai, kaip elementai išdėstomi laike.
Iš komunikacijų diagramos sekos diagrama paveldi aktorių, o iš klasių paveldi gyvavimo liniją „Saskaita“, kuri atsiranda iš objekto klasių diagramoje.
9 pav. Sekos diagrama
Sekos diagramos elementai ir sujungimai:
10 pav. Sekos diagramos komponentai1.6. Panaudojimo atvejų diagrama
Use case diagrama turi panaudojimo atvejų ir aktorių sąveiką. Diagrama apibrėžia funkcinius poreikius sistemai, išorinių aktorių elgseną ir sistemos atsakomybes.
Diagrama iliustruoja panaudojimo atvejus susijusius su vartotojų valdymu. Kai kurie panaudojimo atvejai yra susiję su sekos ir komunikacijų diagramomis. Kad jas pažiūrėti, reikia paspausti du kartus.
11 pav. Use Case diagrama
Diagramos elementai ir sujungimai:
12 pav. Diagramos komponentai
Sukurti sąskaitą paspaudus atsidaro komunikacijų diagrama, o dar po jos gali būti sekos diagrama. Paspaudus ant peržiūrėti užsakymo detales atsidaro analizės diagrama, kuri turi paveldėtus elementus iš sekos diagramos.1.6.1. Analizės diagrama
Analizės diagrama yra supaprastinta veiklos diagrama, kuri apima aukšto lygio biznio procesus ir ankstyvuosius
sistemos elgsenos ir elementų modelius. Ji yra mažiau formali nei kitos diagramos, tačiau gerai išreiškia pagrindines biznio charakteristikas ir poreikius.
Analizės diagrama nepriklauso UML diagramoms ir yra EA įrankio viena iš išplėstinių diagramų. Toliau pavaizduotas diagramos pavyzdys.
13 pav. Analizės diagrama
Analizės diagrama taip pat gali būti išskaidyta į žemesnio lygio analizės diagramas. Pavyzdyje paspaudus du kartus ant „perziureti istorija“ perinama į žemesnio lygio analizės diagramą. Ši diagrama taip pat turi ryšį su sekos diagrama, kadangi paveldi kai kuriuos elementus iš jos.
Diagramos eelementai:
14 pav. Diagramos komponentai2. STRUKTŪRINĖS DIAGRAMOS
Struktūrinės diagramos yra:
Klasių diagrama – class;
Objektų diagrama – object;
Sudėtinė diagrama – composite;
Paketų diagrama – package;
Komponentų diagrama – component;
Išdėstymo diagrama – deployment.
Toliau yra aprašytos visos elgsenos diagramos ir pateikti pavyzdžiai.2.1. Klasių diagrama
Klasių diagrama apima sistemos loginę struktūrą. Tai statinis modelis, kuris vaizduoja kas egzistuoja ir kokie yra atributai bei elgsena, o ne kaip kažką galima atlikti. Ši diagrama yra geriausiai panaudojama norint atvaizduoti ryšius tarp klasių ir sąsajų.
15 pav. Klasių diagrama
Klasių diagramos elementai ir sujungimai:
16 pav. Diagramos komponentai2.2. Objektų ddiagrama
Ši diagrama paveldi iš klasių diagramos elementus.
Objektų diagrama yra glaudžiai susijusi su klasių diagrama. Ji beveik tokia kaip ir sudėtinės struktūros diagrama, kuri taip pat modeliuoja elgseną tam tikru laiku. Skirtumas tas, kad objektų diagrama iliustruoja statinę klasių diagramą, o ssudėtinės struktūros diagrama vaizduoja architektūros skirtumus nuo statinės. Objektų diagramos naudingos, kad galima būtų lengviau suprasti klasių diagramas.
17 pav. Objektų diagrama
Diagramos elementai ir sujungimai:
18 pav. Diagramos komponentai2.3. Sudėtinės struktūros diagramos
Sudėtinės struktūros diagramos atspindi vidinį klasių, sąsajų ar komponentų bendradarbiavimą tam, kad apibrėžtų funkcionalumą. Šios diagramos yra panašios į klasių diagramas, tačiau skirtumas tas, kad šios diagramos modeliuoja specifinį struktūros panaudojimą. Klasių diagramos modeliai yra statinis klasių struktūros požiūris, apimant atributus ir elgseną. Sudėtinės struktūros diagramos naudojamos pavaizduoti einamojo laikotarpio architektūrą, panaudojimą bei ryšius, kurie gali būti ir neatvaizduoti statinėse diagramose.
19 pav. Sudėtinės struktūros diagrama
Diagramos elementai ir sujungimai:
20 pav. Diagramos komponentai2.4. Paketų diagrama
Paketų diagramos naudojamos atvaizduoti organizacijos “pakuotę” ir jos elementus bei atvaizduoti jų atitinkamus vardus/vardavietes.
21 pav. Paketų diagrama
Ši diagrama gali būti automatiškai ssugeneruojama iš poreikių diagramos, kuri priklauso atskirai modelių grupei ir pavaizduota toliau..
Diagramos elementai ir sujungimai:
22 pav. Diagramos komponentai
2.5. Išdėstymo diagrama
Deployment diagrama parodo kur sistema bus išdėstyta. Fizinės mašinos ir procesoriai yra atvaizduojami kaip mazgai. Vidiniai konstruktai gali būti atvaizduoti įterpiant mazgus ar artifaktus.
23 pav. Išdėstymo diagrama
Diagramos elementai ir sujungimai:
24 pav. Diagramos komponentai2.6. Komponentų diagrama
Komponentų diagrama iliustruoja programinės įrangos dalis, įterptas kontroles, kurios įtakoja sistemą. Ši diagrama yra aukštesnio lygio nei klasių diagrama.
25 pav. Komponentų diagrama
Paveiksle yra pavaizduota komponentų diagrama su LAN komponentais.
Komponentų ddiagramos elementai ir sujungimai:
26 pav. Diagramos komponentai
Po to galima atlikti transformacijas į įvairias kalbas. Pavyzdžiui iš šios diagramos transformavus į DLL, gaunama tokia diagrama:
27 pav. DLL transformacija
Po to generuojant DLL į SQL gaunamas tekstinis failas su tokiu parašymu:
CREATE TABLE MS Exchange Serveris (
mS Exchange ServerisID Integer DEFAULT NOT NULL
)
;3. IŠPLĖSTOS DIAGRAMOS
Yra ir keletas išplėstinių diagramų, kurios nepriklauso UML modeliams.
Kitos išplėstos diagramos:
Analizės diagrama – analysis (paprastos veiklos)
Įprastos diagramos – custom, kurios skaidosi į:
• Poreikių diagrama – requirements
• Vartotojo sąsajos diagrama – user interface
Analizės diagrama jau buvo plačiau paminėta po panaudojimo atvejų diagramos. Dar galima paminėti, jog ji yra susijusi ir su veiklos diagramomis.
Custom diagramos yra išplėstos klasių diagramos, kurios naudojamos pavaizduoti poreikius/reikalavimus, vartotojo sąsają ar išplėsto dizaino modelius.
Custom diagramos elementai:
28 pav. Diagramos komponentai3.1. Poreikių diagrama
Poreikių diagrama yra custom diagrama, kuri naudojama apibrėžti sistemos reikalavimus ar savybes.
Poreikių diagrama yra naudojama panaudojimo atvejų diagramose, kur yra apibrėžiami reikalavimai. Bet to iš jos galima sugeneruoti paketų diagramą. Toliau yra pateiktas poreikių diagramos pavyzdys.
29 pav. Poreikių diagrama3.2. Vartotojo sąsajos diagrama
User Interface diagramos naudojamos vizualizuoti sistemos vartotojo sąsają naudojant formas, kontroles ir etiketes. Šios diagramos priklauso custom diagramų grupei.
30 pav. Vartotojo sąsajos diagrama
Diagramos elementai:
31 pav. Diagramos elementai4. MODELIŲ KOMPONENTAI
Šiame skyriuje pavaizduoti diagramų elementai ir sujungimai.
32 pav. Elgsenos diagramų elementai <
1 lentelė
Struktūrinių diagramų elementai
Struktūrinių diagramų elementai Elemento pavadinimas Objektų Klasių Sudėt. Strukt. Kompo-nentų Išdėsty-mo Paketų
Pakuotė + + + +
Klasė + + + +
Objektas + +
Lentelė + +
Asociacija + +
Sąsaja + + + +
Uostas +
Dalis +
Bendradarbiavimo +
Bendradarbiavimo atsiradimas +
Komponentas + +
Mazgas +
Interfeisas +
Artifaktas +
Išdėstymo specifikacija +
2 lentelė
Elgsenos diagramų sujungimai
3 lentelė
Struktūrinių diagramų sujungimai
Platesnį paaiškinimą apie elementų ir sujungimų panaudojimą galima rasti prieduose, kurie yra paaiškinti anglų kalba [žr. Priedas1 ir Priedas2].5. MODELIŲ TARPUSAVIO SĄSAJOS
Paveiksle matoma kaip modeliai yra susiję vienas su kitu.
33 pav. Modelių sąsajosLITERATŪRA
1. Dr. A.Lopatos paskaitų medžiaga. Objektinės CASE technologijos, 2007.
2. Sparks systems. 2007. [interaktyvus]. Žiūrėta 2007 03 20. Prieiga per Internetą: http://www.sparxsystems.com.au/ea.htm
3. Enterprise Architect vartotojo vadovas.
4. Enterprise Architect pavyzdiniai failai.
PRIEDAS 1
Elementų paaiškinimai
An action element describes a basic process or transformation that occurs within a system. It is the basic functional unit within an Activity diagram.
An activity organizes and specifies the participation of subordinate behaviors, such as sub-activities or actions, to reflect the control and data flow of a process.
An actor is a user of the system; „user“ can mean a human user, a machine, or even another system.
A system boundary element signifies a classifier, such as a class, component or sub-system, to which the enclosed use cases are applied.
The choice pseudo-state is used to compose complex transitional paths, where the outgoing transition path is decided by dynamic, run-time conditions.
A collaboration defines a set oof cooperating roles and their connectors.
A combined fragment reflects a piece or pieces of interaction (called interaction operands) controlled by an interaction operator, whose corresponding boolean conditions are known as interaction constraints.
A datastore is an element used to define permanently stored data.
A decision is an element of an Activity diagram that indicates a point of conditional progression: if a condition is true, then processing continues one way, if not, then another.
An endpoint is used in interaction diagrams to reflect a lost or found message in sequence.
Entry points are used to define the beginning of a state machine. An entry point exists for each region, directing the initial concurrent state configuration.
The exception handler element defines the group of operations to carry out when an exception occurs.
An expansion region surrounds a process to be imposed multiple times on the incoming data, once for every element in the input collection.
Exit points are used in submachine states and state machines to denote the point where the machine will be exited and the transition sourcing this
exit point, for submachines, will be triggered.
The final elementindicates the completion of an activity – upon reaching the final, all execution in the activity diagram is aborted.
The flow final element depicts an exit from the system as opposed to the activity final which represents the completion of the activity.
The fork/join elements have different modes of use. These are as follows:
To fork or split the flow into a number of concurrent flows.
To join the flow of a number of concurrent flows.
There aare two types of history pseudo-states – shallow and deep history. A shallow history sub-state is used to represent the most recently active sub-state of a composite state; this pseudo-state does not recurse into this sub-state’s active configuration, should one exist. A deep history sub-state, in contrast, reflects the most recent active configuration of the composite state.
The initial element is used by the Activity and State Machine diagrams. In Activity diagrams, it defines the start of a flow when an aactivity is invoked.
An interaction occurrence is a reference to an existing interaction element. Interaction occurrences are visually represented by a frame, with „ref“ in the frame’s title space.
An interruptible activity region surrounds a group of activity elements, all affected by ccertain interrupts in such a way that all tokens passing within the region are terminated should the interruption(s) be raised.
Junction pseudo-states are used to design complex transitional paths. A junction can be used to combine or merge multiple paths into a shared transition path. Alternatively, a junction can split an incoming path into multiple paths, similar to a fork pseudostate.
A lifeline is an individ.ual participant in an interaction (ie. lifelines cannot have multiplicity). A lifeline represents a distinct connectable element.
An object is an instance of a class at run time.
A package is a namespace as well as an element that can be contained in other package’s namespaces. A package can own or merge with other packages, and its elements can bbe imported into a package’s namespace.
Activity partitions are used to logically organize an Activity diagram. They do not affect the token flow of an Activity diagram, but help structure the view or parts of it.
A receive element is used to define the acceptance or receipt of a request.
The send element is used to depict the action of sending a signal.
A state represents a situation where some invariant condition holds;
A lifeline is the path an object takes across a measure oof time, as indicated by the x-axis.
A state lifeline follows discrete transitions between states, which are defined along the y-axis of the timeline.
The state/continuation symbol serves two different purposes for interaction diagrams, as state invariants and continuations.
A structured activity element is a pointer to a child Activity diagram.
A sub-machine element is a pointer to a child State Machine diagram.
A synch state is useful for indicating that concurrent paths of a state machine will be synchronized.
A system boundary element signifies a classifier, such as a class, component or sub-system, to which the enclosed use cases are applied.
The terminate pseudostate indicates that upon entry of its pseudostate, the state machine’s execution will end.
use case is a UML modeling element that describes how a user of the proposed system will interact with the system to perform a discrete unit of work.
The value lifeline shows the lifeline’s state across the diagram, within parallel lines indicating a steady state.
An artifact is any physical piece of information used or produced by a system.
A class is a representation of object(s), that reflects their structure and behavior within the system. It is a template from which actual running instances are created. A class may have attributes (data) and mmethods (operations or behavior).
A collaboration defines a set of cooperating roles and their connectors.
Use a collaboration occurrence to apply a pattern defined by a collaboration to a specific situation.
A component is a modular part of a system, whose behavior is defined by its provided and required interfaces; the internal workings of the component should be invisible and its usage environment-independent.
A deployment specification (spec) specifies parameters guiding deployment of an artifact, as is necessary with most hardware and software technologies.
An interface is a specification of behavior that implementers agree to meet.
A node is a physical piece of equipment on which the system will be deployed – for example a workgroup server or workstation.
An object is an instance of a class at run time.
A package is a namespace as well as an element that can be contained in other package’s namespaces. A package can own or merge with other packages, and its elements can be imported into a package’s namespace.
Parts are run-time instances of classes or interfaces.
Ports define the interaction between a classifier and its environment.
A qualifier is a property of an association which limits the nature of the relationship between two classifiers or objects.
PRIEDAS 2
Sujungimų paaiškinimai
An aggregation relationship shows that an eelement contains or is composed of other elements.
Assembly connector bridges a component’s required interface (Component1) with the provided interface of another component (Component2).
An association implies two model elements have a relationship – usually implemented as an instance variable in one class.
Diagonal representation can be used to graphically ease ternary or multi.ply associated elements.
An association class connection is a UML construct that allows an association connector to have attributes and operations (features). This results in a hybrid relation with the characteristics of a linkage and a class.
A communication path defines the path through which two DeploymentTargets are able to exchange signals and messages. Communication path is a specialization of Association. A DeploymentTarget is the target for a deployed Artifact and may be a Node, Property or InstanceSpecification.
A composite aggregation is used to depict an element which is made up of smaller components.
Connectors illustrate communication links between parts to fulfill the structure’s purpose. Each connector end is distinct, controlling the communication pertaining to its connecting element. These elements can define constraints specifying this behavior. Connectors can have multiplicity.
The control flow is a connector linking two nodes in an Activity diagram. Control flow connectors bridge the flow between activity nodes, by directing
the flow to the target node once the source node’s activity is completed.
A delegate connector defines the internal assembly of a component’s external ports and interfaces. Using a delegate connector wires the internal workings of the system to the outside world, by a delegation of the external interfaces’ connections.
Dependency relationships are used to model a wide range of dependent relationships between model elements – and even between models themselves.
A deployment is a type of dependency relationship that indicates the deployment oof an artifact onto a node or executable target. A deployment can be made at type and instance levels. At the type level, a deployment would be made for every instance of the node. Deployment can also be specified for an instance of a node, so that a node’s instances can have varied deployed artifacts. With composite structures modeled with nodes defined as parts, parts can also serve as targets of a deployment relationship.
The expose interface toolbox element is a ggraphical way to depict the required and supplied interfaces of a component, class, or part.
An extend connection is used to indicate an element extends the behavior of another. Extensions are used in use case models to indicate one use ccase (optionally) extends the behavior of another. An extending use case often expresses alternate flows.
A generalization is used to indicate inheritance. Drawn from the specific classifier to a general classifier, the generalize implication is that the source inherits the target’s characteristics.
An include connection indicates that the source element includes the functionality of the target element. Include connections are used in use case models to reflect that one use case includes the behavior of another. Use an include relationship to avoid having the same subset of behavior in many use cases; this is similar to delegation used in class models.
The information flow is a connector linking two nodes in an Activity diagram. The information flow represents information item(s) or classifier(s) fflowing between two elements.
The interrupt flow is a toolbox element used to define the two UML concepts of connectors for Exception Handler and Interruptible Activity Region. An interrupt flow is also known as an activity edge.
A manifest relationship indicates that the artifact source embodies the target model element.
Messages indicate a flow of information or transition of control between elements. Messages can be used by all interaction diagrams except the Interaction Overview diagram, to reflect system behavior. If between classes or cclassifier instances, the associated list of operations will be available to specify the event.
A message in a Communication diagram is equivalent in meaning to a message in a Sequence diagram. It implies that one object uses the services of another object, or sends a message. to that object.
Sequence diagrams depict work flow or activity over time using messages passed from element to element. These messages correspond in the software model to class operations and behavior. They are semantically similar to the messages passed between elements in a Communication diagram.
self-message reflects a new process or method invoked within the calling lifeline’s operation. It is a specification of a message.
A call is a type of message element that extends the level of activation from the previous message.
Messages (laiko diagramoje) are the communication links between lifelines. In the case of a timeline, a message is a connection between two timeline objects.
A message endpoint element defines the termination of a state or value lifeline in a Timing diagram.
A message label is an alternate way to denote messages between lifelines, which is useful for ‘uncluttering’ timing diagrams strewn with messages. To indicate a message between lifelines, draw a connector from the source lifeline into a mmessage label.
The nesting connector is an alternative graphical notation for expressing containment or nesting of elements within other elements. It is most appropriately used for displaying package nesting.
Object flows are used in Activity diagrams and State Machines. When used in an Activity diagram, an object flow connects two elements, with specific data passing through it.
An occurrence relationship indicates that a collaboration represents a classifier. An occurrence connector is drawn from the collaboration to the classifier.
A package import relationship is drawn from a source package to a package whose contents will be imported. Private members of a target package cannot be imported.
A package merge indicates a relationship between two packages whereby the contents of the target package are merged with those of the source package.
The source object implements or realizes the destination. Realize is used to express traceability and completeness in the model – a business process or requirement is realized by one or more use cases which are in turn realized by some classes, which in turn are realized by a component, etc.
Role binding is the mapping between a collaboration occurrence’s internal roles and the respective parts needed to implement a specific situation. The associated parts can have pproperties defined to enable the binding to occur, and the collaboration to take place.
The represents connector indicates a collaboration is used in a classifier. The representation relationship is a specialization of a dependency, linking InformationItem elements that represent the same idea across models.
The trace relationship is a specialization of a dependency, linking model elements or sets of elements that represent the same idea across models. Traces are often used to track requirements and model changes.
A transition defines the logical movement from one state to another.
A use link indicates that one element requires another to perform some interaction. The Usage relationship does not specify how the target supplier is used, other than that the source client uses it in definition or implementation. A usage relationship is a sub-typed dependency relationship.
