5.4. Object Diagrams Essential: Objektit ja niiden suhteet Objektikaavio näyttää olemassa olevat objektit ja niiden suhteet järjestelmän loogisessa suunnittelussa. Toisin sanoen objektikaavio on tilannekuva tapahtuman kulusta jossakin kokoonpanossa

5.7. Prosessikaaviot. Olennaista: Prosessorit, laitteet ja yhteydet Prosessikaavioita käytetään näyttämään prosessien jakautuminen prosessorien välillä fyysisen järjestelmän suunnittelussa. Erillinen prosessikaavio näyttää yhden kuvan prosessirakenteesta

10.4 UML-KAAVIOT 10.4.1. Visuaalisten kaavioiden tyypit UMLUML mahdollistaa useiden visuaalisten kaavioiden luomisen: käyttötapauskaaviot; sekvenssikaaviot; yhteistyökaaviot; luokkakaaviot; tilakaaviot; kaavioita

1.2.6. Kaaviokehys Kuvassa. Kuvassa 1.2.26 on tyypillinen esimerkki hajottelukaaviosta, jossa on rajauslaatikoita, joita kutsutaan kaaviokehykseksi. Riisi. 1.2.26. Esimerkki jaottelukaaviosta lankakehyksellä Rautalanka sisältää otsikon (kehyksen yläosa) ja alatunnisteen (kehyksen alaosa).

Ajoituskaaviot Saadaksesi tulo- ja lähtöjännitteiden ajoituskaaviot, sinun on muutettava hieman tulotiedostoa. Kuten edellisessä esimerkissä, käytetään sinimuotoista tulojännitettä: Vi 1 0 sin (0 0. 5V 5kHz) Transienttianalyysin ohella

Kaaviot ja kaaviot Vain asiantuntija voi erottaa merkityksen loputtomien numerorivien takana, mutta kuka tahansa voi ymmärtää (tai ainakin väittää ymmärtävänsä) histogrammin tai ympyräkaavion. VBA:ssa ei ole sisäänrakennettuja työkaluja kaavioiden luomiseen, mutta sellaisia

5.1.14. Kaaviot Kaaviot ovat graafisia esityksiä numeerisista tiedoista taulukossa. Pages tarjoaa useita kaaviotyyppejä: Pylväs, Pinottu sarake, Pylväskaavio, Pinottu pylväskaavio, Viiva, Alue, Pinottu alue

5.2.8. Kaaviot Kaavio on graafinen esitys valitun alueen tiedoista Luodaksesi kaavion, seuraa seuraavaa algoritmia1. Luo taulukko lasketuista arvoista.2. Valitse haluamasi alue (se voi koostua ei-viereisestä suorakaiteen muotoisesta

UML on lyhenne sanoista Unified Modeling Language. Itse asiassa se on yksi suosituimmista liiketoimintaprosessien mallinnustekniikoista ja kansainvälinen standardimerkintä ohjelmistokehityksen määrittelyyn, visualisointiin ja dokumentointiin. Object Management Groupin määrittämä se syntyi useiden muiden UML-merkintäjärjestelmien seurauksena, ja siitä on nyt tullut visuaalisen mallintamisen tosiasiallinen standardi. Minkä tahansa olio-ohjelmoinnin perusperiaate alkaa mallin rakentamisesta.

UML syntyi ohjelmistokehitystä ja dokumentointia ympäröivän kaaoksen seurauksena. 1990-luvulla oli olemassa useita eri tapoja ajatella ohjelmistojärjestelmiä. Tarvittiin yhtenäisempi visuaalinen UML-tapa näiden järjestelmien esittämiseen, ja sen seurauksena kolme Rational Softwaressa työskentelevää ohjelmistoinsinööriä kehittivät sen vuosina 1994-1996. Se otettiin myöhemmin käyttöön standardina vuonna 1997, ja se on edelleen voimassa vain muutamalla päivityksellä.

Pohjimmiltaan UML on yleiskäyttöinen mallinnuskieli ohjelmistokehityksen alalla. Se on kuitenkin nyt löytänyt tiensä useiden liiketoimintaprosessien tai työnkulkujen dokumentaatioon, kuten toimintakaavioihin. Tietyntyyppisiä UML-kaavioita voidaan käyttää vuokaavioiden korvikkeena. Ne tarjoavat sekä standardoidumman tavan mallintaa työnkulkuja että laajan valikoiman ominaisuuksia, jotka parantavat luettavuutta ja tehokkuutta.

Arkkitehtuuri perustuu meta-objektiin, joka määrittää perustan UML-kielen luomiselle. Se on riittävän tarkka koko sovelluksen luomiseen. Täysin suoritettava UML voidaan ottaa käyttöön useilla alustoilla eri tekniikoita käyttäen kaikissa prosesseissa koko ohjelmistokehityssyklin ajan.

UML on tarkoitettu käyttäjien kehittämäksi visuaaliseksi mallinnuskieleksi. Se tukee korkean tason kehityskonsepteja, kuten rakenteita, malleja ja yhteistyötä. UML on joukko elementtejä, kuten:

1. Ohjelmointikielen lausunnot.
2. Toimijat - kuvaavat käyttäjän roolia tai minkä tahansa muun kohteen kanssa vuorovaikutuksessa olevan järjestelmän roolia.
3. Toimenpiteet, jotka on suoritettava työsopimuksen täyttämiseksi ja jotka on esitetty kaavioissa.
4. Liiketoimintaprosessi, joka sisältää joukon tehtäviä, jotka luovat tietyn palvelun asiakkaille ja jotka visualisoidaan peräkkäisten toimintojen vuokaaviolla.
5. Loogiset ja uudelleen käytettävät ohjelmistokomponentit.

UML-kaaviot jakautuvat kahteen luokkaan. Ensimmäinen tyyppi sisältää seitsemän tyyppistä kaaviota, jotka edustavat rakenteellista tietoa, toinen - loput seitsemän, jotka edustavat yleisiä käyttäytymistyyppejä. Näitä kaavioita käytetään dokumentoimaan järjestelmien arkkitehtuuria ja ne ovat suoraan mukana järjestelmän UML-mallintamisessa.

UML-kaaviot esitetään järjestelmämallin staattisina ja dynaamisina esityksinä. Staattinen näkymä sisältää luokka- ja koostumuskaaviot, jotka korostavat staattista rakennetta. Dynaaminen näkymä edustaa objektien välistä vuorovaikutusta ja objektien sisäisten tilojen muutoksia sekvenssi-, aktiviteetti- ja tilakaavioiden avulla.

Saatavilla on laaja valikoima UML-mallinnustyökaluja mallintamisen yksinkertaistamiseksi, mukaan lukien IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner ja Dia.

UML:n käyttöä on monenlaista sekä ohjelmistokehityksen dokumentaatiossa että liiketoimintaprosesseissa:

1. Luonnos. Tässä tapauksessa UML-kaavioita käytetään välittämään järjestelmän eri näkökohtia ja ominaisuuksia. Tämä on kuitenkin vain huipputason näkymä järjestelmästä, eikä se todennäköisesti sisällä kaikkia tarvittavia yksityiskohtia projektin loppuun saattamiseen.
2. Suunnittelu eteenpäin - Luonnossuunnittelu tehdään ennen sovelluksen koodaamista. Tämä tehdään saadakseen paremman yleiskuvan järjestelmästä tai työnkulusta, jota käyttäjä yrittää luoda. Monia suunnitteluongelmia tai puutteita voidaan tunnistaa, mikä parantaa hankkeen yleistä terveyttä ja hyvinvointia.
3. Käänteinen muotoilu. Kun koodi on kirjoitettu, UML-kaaviot näytetään dokumentaatiomuotona eri toimintoja, rooleja, osallistujia ja työnkulkuja varten.
4. Suunnitelma. Tässä tapauksessa kaavio toimii täydellisenä suunnitteluna, joka vaatii vain järjestelmän tai ohjelmiston varsinaisen toteutuksen. Tämä tehdään usein käyttämällä CASE-työkaluja (Computer Aided Software Engineering Tools). CASE-työkalujen käytön suurin haitta on, että ne vaativat tietyn tason tietämystä, käyttäjien koulutusta sekä johtoa ja henkilökuntaa.

UML ei ole itsenäinen ohjelmointikieli, kuten Java, C++ tai Python, mutta oikeilla työkaluilla siitä voi tulla pseudo-ohjelmakieli UML. Tämän tavoitteen saavuttamiseksi koko järjestelmä tulee dokumentoida erilaisiin kaavioihin ja oikealla ohjelmistolla kaaviot voidaan kääntää suoraan koodiksi. Tämä menetelmä voi olla hyödyllinen vain, jos kaavioiden piirtämiseen käytetty aika vie vähemmän aikaa kuin varsinaisen koodin kirjoittaminen. Vaikka UML luotiin järjestelmien mallintamiseen, se on löytänyt useita sovelluksia liiketoiminta-alueilla.

Alla on esimerkki UML-kaaviosta liiketoiminnan mallintamista varten.

Yksi käytännöllinen ratkaisu olisi esittää visuaalisesti puhelinmyynnin prosessivirtaa toimintakaavion avulla. Siitä hetkestä, kun tilaus otetaan syötteeksi, siihen hetkeen, kun tilaus on valmis ja tietty tulos annetaan.

UML-kaavioita on useita tyyppejä, ja jokainen suorittaa oman tehtävänsä, olipa se kehitetty ennen käyttöönottoa tai sen jälkeen osana dokumentaatiota. Kaksi laajinta luokkaa, jotka kattavat kaikki muut tyypit, ovat käyttäytymiskaavio ja rakennekaavio. Kuten nimestä voi päätellä, jotkut UML-kaaviot yrittävät analysoida ja kuvata järjestelmän tai prosessin rakennetta, kun taas toiset kuvaavat järjestelmän, sen osallistujien ja komponenttien käyttäytymistä.

Eri tyypit on jaettu seuraavasti:

1. Kaikkia 14 erilaisesta UML-kaaviosta ei käytetä säännöllisesti järjestelmien ja arkkitehtuurien dokumentoinnissa.
2. Pareto-periaate pätee myös UML-kaavioiden käyttöön.
3. Kehittäjät käyttävät 20 % kaavioista 80 % ajasta.

Ohjelmistokehityksessä yleisimmin käytetyt elementit ovat:

• käyttökaaviot;
• luokkakaaviot;
• sekvenssejä.

Toimintokaaviot ovat tärkeimpiä UML-kaavioita liiketoimintaprosessimallien luomisessa. Ohjelmistokehityksessä niitä käytetään kuvaamaan eri toimintojen sujuvuutta. Ne voivat olla joko sarja- tai rinnakkaisia. Ne kuvaavat toiminnan käyttämiä, kuluttamia tai tuottamia esineitä ja eri toimintojen välisiä suhteita.

Kaikki edellä mainitut ovat tärkeitä liiketoiminnasta toiseen johtavien liiketoimintaprosessien mallintamisessa, koska niillä on selkeä alku ja loppu. Liiketoimintaympäristössä tätä kutsutaan myös liiketoimintaprosessien kartoitukseksi. Päähenkilöt ovat kirjoittaja, toimittaja ja kustantaja. Esimerkki UML:stä on seuraava. Kun arvioija katsoo luonnosta ja päättää, että joitain muutoksia on tehtävä. Tämän jälkeen kirjoittaja tarkistaa luonnosta ja palauttaa sen uudelleen analysoimaan arvostelua.

Käyttökaavio

Järjestelmän kulmakivi - käytetään järjestelmätason vaatimusten analysointiin. Nämä vaatimukset ilmaistaan ​​eri käyttötapauksissa. UML-kaavion kolme pääkomponenttia ovat:

1. Toiminnallinen - esitetään käyttötapauksina.
2. Verbi, joka kuvaa toimintaa.
3. Toimijat - vuorovaikutuksessa järjestelmän kanssa. Toimijan rooli voi olla käyttäjiä, organisaatioita tai ulkoisia sovelluksia. Osallistujien väliset suhteet on esitetty suorilla nuolilla.

Esimerkiksi varastonhallintakaaviota varten. Tässä tapauksessa on omistaja, toimittaja, johtaja, varastoasiantuntija ja varastotarkastaja. Pyöreät säiliöt edustavat toimijoiden suorittamia toimia. Mahdolliset toimenpiteet: osakkeiden osto ja maksaminen, varaston laadun tarkistaminen, varaston palautus tai jakelu.

Tämän tyyppinen kaavio sopii hyvin dynaamisen toiminnan näyttämiseen järjestelmän osallistujien välillä yksinkertaistaen sen esitystapaa heijastamatta toteutustietoja.

Väliaikainen

UML-ajoituskaavioita käytetään edustamaan objektisuhteita, joissa fokus on ajasta riippuvainen. Ei ole mielenkiintoista, miten esineet ovat vuorovaikutuksessa tai muuttavat toisiaan, mutta käyttäjä haluaa kuvitella, kuinka esineet ja subjektit toimivat lineaarista aika-akselia pitkin.

Jokainen yksittäinen osallistuja on edustettuna elämänlinjan kautta, joka on olennaisesti linja, joka muodostaa vaiheita yksittäisen osallistujan siirtyessä vaiheesta toiseen. Painopisteenä on tapahtumien kesto ja siitä riippuen tapahtuvat muutokset.

Ajoituskaavion pääkomponentit ovat:

1. Lifeline on yksittäinen jäsen.
2. Tilan aikajana – Yksi elämänpolku voi kulkea prosessin eri tilojen läpi.
3. Kestorajoitus on aikavälirajoitus, joka edustaa kestoa, joka vaaditaan rajoituksen täyttämiseen.
4. Aikaraja - rajoittaa aikaväliä, jonka aikana osallistujan on suoritettava jotain.
5. Destruction Emergence - Viestin ilmestyminen, joka tuhoaa yksittäisen osallistujan ja edustaa kyseisen osallistujan elinkaaren loppua.

Vaakakaavioita, joita kutsutaan myös tilakaavioiksi, käytetään kuvaamaan järjestelmän komponentin eri tiloja. Se hyväksyy rajallisen nimimuodon, koska kaavio on pohjimmiltaan kone, joka kuvaa objektin useita tiloja ja kuinka se muuttuu sisäisten ja ulkoisten tapahtumien perusteella.

Hyvin yksinkertainen koneen tilakaavio olisi kuin shakkipeli. Tyypillinen shakkipeli koostuu valkoisen ja mustan liikkeistä. Valkoisella on ensimmäinen siirto, joka aloittaa pelin. Pelin loppu voi tapahtua riippumatta siitä, voittaako valkoinen vai musta. Peli voi päättyä otteluun, välierään tai tasapeliin (eri koneen tilat). Tilakaavioita käytetään pääasiassa eri järjestelmien myötä- ja taaksepäin suuntautuvassa UML-suunnittelussa.

Peräkkäinen

Tämäntyyppinen kaavio on tärkein UML-kaavio paitsi tietojenkäsittelytieteen yhteisössä, myös suunnittelutason mallina yrityssovellusten kehittämiseen. Ne ovat suosittuja kuvattaessa liiketoimintaprosesseja visuaalisesti itsestäänselvyytensä vuoksi. Kuten nimestä voi päätellä, kaaviot kuvaavat viestien sarjaa ja vuorovaikutusta, joka tapahtuu subjektien ja objektien välillä. Toimijat tai objektit voivat olla aktiivisia vain silloin, kun se on tarpeen tai kun toinen kohde haluaa kommunikoida heidän kanssaan. Kaikki viestit esitetään kronologisessa järjestyksessä.

Saadaksesi täydellisempiä tietoja, voit katsoa alla olevaa esimerkki UML-sekvenssikaaviota.

Kuten esimerkki ehdottaa, rakennekaavioita käytetään esittämään järjestelmän rakenne. Tarkemmin sanottuna kieltä käytetään ohjelmistokehityksessä kuvaamaan järjestelmän arkkitehtuuria ja eri komponenttien välistä yhteyttä.

UML-luokkakaavio on ohjelmistodokumentaation yleisin kaaviotyyppi. Koska useimmat nykyään luodut ohjelmat perustuvat edelleen olio-ohjelmointiparadigmaan, luokkakaavioiden käyttäminen ohjelmistojen dokumentoimiseen on tervettä järkeä. Tämä johtuu siitä, että OOP perustuu UML-luokkiin ja niiden välisiin suhteisiin. Lyhyesti sanottuna kaaviot sisältävät luokat sekä niiden attribuutit, joita kutsutaan myös tietokentiksi, ja niiden käyttäytyminen, joita kutsutaan jäsenfunktioiksi.

Tarkemmin sanottuna jokaisessa luokassa on 3 kenttää: nimi ylhäällä, attribuutit nimen alla, toiminnot/käyttäytymiset alareunassa. Eri luokkien välinen suhde (esitetty yhdistävällä viivalla) muodostaa luokkakaavion. Yllä oleva esimerkki näyttää perusluokkakaavion.

Objektit

UML-rakennekaavioista puhuttaessa on syytä syventyä tietojenkäsittelytieteen käsitteisiin. Ohjelmistosuunnittelussa luokkia käsitellään abstrakteina tietotyyppeinä, kun taas objektit ovat ilmentymiä. Jos esimerkiksi on "Auto", joka on yleinen abstrakti tyyppi, luokan "Auto" esiintymä on "Audi".

UML-objektikaaviot auttavat ohjelmistokehittäjiä tarkistamaan, edustaako luotu abstrakti rakenne käytännössä toteutettua eli objektien ilmentymisen aikana toimivaa rakennetta. Jotkut kehittäjät pitävät tätä toissijaisena tarkkuustarkastuksen tasona. Se näyttää luokkien esiintymiä. Tarkemmin sanottuna yleisellä luokalla "Client" on nyt todellinen asiakas, esimerkiksi "James". James on yleisemmän luokan esiintymä ja sillä on kuitenkin samat attribuutit määritetyillä arvoilla. Sama tehtiin Tilit ja Säästötilit. Molemmat ovat vastaavien luokkiensa objekteja.

Käyttöönotot

Käyttöönottokaavioita käytetään visualisoimaan ohjelmiston ja laitteiston suhdetta. Tarkemmin sanottuna käyttöönottokaavioiden avulla voit rakentaa fyysisen mallin siitä, kuinka ohjelmistokomponentit (artefaktit) otetaan käyttöön solmuiksi kutsuttuihin laitteistokomponentteihin.

Tyypillinen yksinkertaistettu verkkosovelluksen käyttöönottosuunnitelma sisältää:

1. Solmut (sovelluspalvelin ja tietokantapalvelin).
2. Asiakassovelluksen ja tietokannan artefaktiskeema.

Pakettikaavio on samanlainen kuin edellä selitetty UML-käyttöönottokaavioiden makrokokoelma. Eri paketit sisältävät solmuja ja artefakteja. Ne ryhmittelevät kaavioita ja mallintavat komponentteja ryhmiin, aivan kuten nimiavaruus kapseloi erilaisia ​​nimiä, jotka liittyvät jonkin verran toisiinsa. Viime kädessä paketin voi rakentaa myös useilla muilla paketeilla edustamaan monimutkaisempia järjestelmiä ja käyttäytymistä.

Pakettikaavion päätarkoituksena on näyttää suhteet erilaisten suurten komponenttien välillä, jotka muodostavat monimutkaisen järjestelmän. Ohjelmoijat pitävät tätä abstraktioominaisuutta hyvänä hyödynä pakettikaavioiden käytössä, varsinkin kun jotkin yksityiskohdat saattavat jäädä kokonaiskuvan ulkopuolelle.

Kuten kaikki muutkin asiat elämässä, tehdäksesi jotain oikein tarvitset oikeat työkalut. Ohjelmistojen, prosessien tai järjestelmien dokumentointiin käytetään työkaluja, jotka tarjoavat UML-merkintöjä ja kaaviomalleja. On olemassa useita ohjelmistodokumentaatiotyökaluja, joiden avulla voit piirtää kaavion.

Ne jakautuvat yleensä seuraaviin pääkategorioihin:

1. Paperi ja kynä ovat helppoja. Ota paperia ja kynä, avaa UML-syntaksikoodi Internetistä ja piirrä haluamasi kaavio.
2. Online-työkalut - On olemassa useita online-sovelluksia, joiden avulla voit luoda kaavion. Useimmat niistä tarjoavat maksullisen tilauksen tai rajoitetun määrän kaavioita ilmaisella tasolla.
3. Ilmaiset verkkotyökalut ovat melkein samat kuin maksulliset. Suurin ero on, että maksulliset tarjoavat myös opetusohjelmia ja valmiita malleja tietyille kaavioille.
4. Työpöytäsovellus - Tyypillinen kaavioiden ja melkein kaikkien muiden kaavioiden työpöytäsovellus on Microsoft Visio. Se tarjoaa edistyneitä ominaisuuksia ja toimintoja. Ainoa haittapuoli on, että joudut maksamaan siitä.

Näin ollen on aivan selvää, että UML on tärkeä osa olio-ohjelmistokehitystä. Se käyttää graafista merkintää luodakseen visuaalisia malleja järjestelmäohjelmista.

UML on yhtenäinen graafinen mallinnuskieli OO-järjestelmien kuvaamiseen, visualisointiin, suunnitteluun ja dokumentointiin. UML on suunniteltu tukemaan ohjelmistojen mallinnusprosessia OO-lähestymistapaan, organisoimaan käsitteellisten ja ohjelmakonseptien suhdetta sekä heijastelemaan monimutkaisten järjestelmien skaalausongelmia. UML-malleja käytetään ohjelmiston elinkaaren kaikissa vaiheissa liiketoiminta-analyysistä järjestelmän ylläpitoon. Eri organisaatiot voivat käyttää UML:ää parhaaksi katsomallaan tavalla ongelma-alueistaan ​​ja käyttämistään teknologioista riippuen.

UML:n lyhyt historia

90-luvun puoliväliin mennessä useat kirjoittajat olivat ehdottaneet useita kymmeniä OO-mallinnusmenetelmiä, joista jokainen käytti omaa graafista merkintää. Lisäksi millä tahansa näistä menetelmistä oli vahvuutensa, mutta se ei mahdollistanut riittävän täydellisen mallin rakentamista PS:stä, jotta se voitaisiin näyttää "kaikilta puolilta", eli kaikki tarvittavat projektiot (katso artikkeli 1). Lisäksi OO-mallinnusstandardin puute vaikeutti sopivimman menetelmän valintaa kehittäjille, mikä esti OO-lähestymistavan laajan käyttöönoton ohjelmistokehityksessä.

Object Management Groupin (OMG), standardien hyväksymisestä objektiteknologioiden ja tietokantojen alalla vastaavan organisaation pyynnöstä, kolmen suosituimman OO-menetelmän kirjoittajat ratkaisivat kiireellisen yhtenäistämis- ja standardointiongelman - G. Butch, D. Rambo ja A. Jacobson, jotka yhdessä loivat version UML 1.1, jonka OMG hyväksyi vuonna 1997 standardina.

UML on kieli

Mikä tahansa kieli koostuu sanastosta ja säännöistä sanojen yhdistämiseksi merkityksellisten rakenteiden luomiseksi. Näin erityisesti ohjelmointikielet, kuten UML, rakentuvat. Sen erottuva piirre on, että kielisanakirja muodostuu graafisista elementeistä. Jokaiseen graafiseen symboliin liittyy tietty semantiikka, joten yhden kehittäjän luoma malli on selkeästi ymmärrettävissä toiselle, samoin kuin UML:ää tulkitsevalla ohjelmistotyökalulla. Tästä seuraa erityisesti, että UML:ssä esitetty ohjelmistomalli voidaan kääntää automaattisesti OO-ohjelmointikielelle (kuten Java, C++, VisualBasic), eli jos on olemassa hyvä UML:ää tukeva visuaalinen mallinnustyökalu, jolla on rakentanut mallin, saamme myös mallia vastaavan ohjelmakoodin.

On syytä korostaa, että UML on kieli, ei menetelmä. Se selittää, mistä elementeistä malleja luodaan ja miten niitä luetaan, mutta ei kerrota, mitä malleja tulisi kehittää ja missä tapauksissa. UML-pohjaisen menetelmän luomiseksi on tarpeen täydentää sitä ohjelmistokehitysprosessin kuvauksella. Esimerkki tällaisesta prosessista on Rational Unified Process, jota käsitellään seuraavissa artikkeleissa.

UML-sanakirja

Malli on esitetty entiteettien ja niiden välisten suhteiden muodossa, jotka on esitetty kaavioissa.

Entiteetit ovat abstraktioita, jotka ovat mallien pääelementtejä. Entiteettejä on neljää tyyppiä - rakenteellinen (luokka, käyttöliittymä, komponentti, käyttötapaus, yhteistyö, solmu), käyttäytymiseen (vuorovaikutus, tila), ryhmittely (paketit) ja huomautus (kommentit). Jokaisella entiteettityypillä on oma graafinen esityksensä. Kokonaisuuksia käsitellään yksityiskohtaisesti kaavioita tutkiessa.

Suhde näyttää erilaisia ​​yhteyksiä entiteettien välillä. UML määrittelee seuraavat suhdetyypit:

• Riippuvuus osoittaa tällaisen yhteyden kahden entiteetin välillä, kun muutos toisessa - riippumattomassa - voi vaikuttaa toisen - riippuvaisen - semantiikkaan. Riippuvuutta edustaa pisteviiva nuolella, joka on suunnattu riippuvaisesta entiteetistä riippumattomaan.
• yhdistys on rakenteellinen suhde, joka osoittaa, että yhden entiteetin objektit liittyvät toisen olioihin. Graafisesti assosiaatio esitetään linjana, joka yhdistää siihen liittyvät entiteetit. Assosiaatioiden tehtävänä on navigoida objektien välillä. Esimerkiksi luokkien "Tilaus" ja "Tuote" välistä yhteyttä voidaan käyttää toisaalta kaikkien tiettyyn tilaukseen määritettyjen tuotteiden tai toisaalta kaikkien tämän tuotteen sisältävien tilausten löytämiseen. On selvää, että vastaavien ohjelmien on otettava käyttöön mekanismi, joka tarjoaa tällaisen navigoinnin. Jos navigointia tarvitaan vain yhteen suuntaan, se osoitetaan nuolella liitoksen lopussa. Erityinen assosiaatiotapaus on yhdistäminen - suhde muotoa "koko" - "osa". Graafisesti se on korostettu timantilla lopussa lähellä olemuskokonaisuutta.
• Yleistys on emokokonaisuuden ja alikokonaisuuden välinen suhde. Pohjimmiltaan tämä suhde heijastaa luokkien ja objektien periytymisominaisuutta. Yleistys esitetään viivana, joka päättyy kolmioon, joka on suunnattu emokokonaisuuteen. Lapsi perii vanhemman rakenteen (attribuutit) ja käyttäytymisen (menetelmät), mutta samalla sillä voi olla uusia rakenneelementtejä ja uusia menetelmiä. UML sallii moniperinnön, kun entiteetti liittyy useampaan kuin yhteen emokokonaisuuteen.
• Toteutus– suhde käyttäytymismäärittelyn (rajapinnan) määrittävän entiteetin ja tämän käyttäytymisen toteutuksen määrittelevän entiteetin (luokka, komponentti) välillä. Tätä suhdetta käytetään yleisesti komponenttien mallintamiseen, ja sitä kuvataan yksityiskohtaisemmin seuraavissa artikkeleissa.

Kaaviot. UML tarjoaa seuraavat kaaviot:

• Kaaviot, jotka kuvaavat järjestelmän toimintaa:
• Tilakaaviot
• Toimintakaaviot,
• Objektikaaviot,
• Sekvenssikaaviot,
• Yhteistyökaaviot;
• Kaaviot, jotka kuvaavat järjestelmän fyysistä toteutusta:
• Komponenttikaaviot;
• Käyttöönottokaaviot.

Mallin ohjausnäkymä. Paketit.

Olemme jo sanoneet, että jotta ihmiset ymmärtäisivät mallin hyvin, se on järjestettävä hierarkkisesti jättäen pieni määrä entiteettejä kullekin hierarkian tasolle. UML sisältää keinon järjestää mallin hierarkkinen esitys - paketit. Mikä tahansa malli koostuu joukosta paketteja, jotka voivat sisältää luokkia, käyttötapauksia ja muita entiteettejä ja kaavioita. Paketti voi sisältää muita paketteja, mikä mahdollistaa hierarkioiden luomisen. UML ei tarjoa erillisiä pakettikaavioita, mutta ne voivat esiintyä muissa kaavioissa. Paketti on kuvattu suorakulmiona, jossa on kirjanmerkki.

Mitä UML tarjoaa.

• monimutkaisen järjestelmän hierarkkinen kuvaus paketteja tunnistamalla;
• järjestelmän toiminnallisten vaatimusten formalisointi käyttötapauslaitteiston avulla;
• järjestelmävaatimusten erittely rakentamalla toimintakaavioita ja skenaarioita;
• tietoluokkien tunnistaminen ja käsitteellisen tietomallin rakentaminen luokkakaavioiden muodossa;
• tunnistetaan käyttöliittymää kuvaavat luokat ja luodaan näytön navigointikaavio;
• kuvaus objektien välisistä vuorovaikutusprosesseista järjestelmän toimintoja suoritettaessa;
• objektin käyttäytymisen kuvaus aktiviteetti- ja tilakaavioiden muodossa;
• ohjelmistokomponenttien kuvaus ja niiden vuorovaikutus rajapintojen kautta;
• kuvaus järjestelmän fyysisestä arkkitehtuurista.

Ja viimeinen asia...

Kaikesta UML:n houkuttelevuudesta huolimatta sitä olisi vaikea käyttää todellisessa ohjelmistomallintamisessa ilman visuaalisia mallinnustyökaluja. Tällaisten työkalujen avulla voit nopeasti esittää kaavioita näytöllä, dokumentoida ne, luoda ohjelmakoodimalleja eri OO-ohjelmointikielillä ja luoda tietokantaskeemoja. Suurin osa niistä sisältää mahdollisuuden ohjelmakoodien uudelleensuunnitteluun - ohjelmistomallin tiettyjen projektioiden palauttaminen analysoimalla automaattisesti ohjelmien lähdekoodeja, mikä on erittäin tärkeää mallin ja koodien yhteensopivuuden varmistamiseksi sekä edeltäneiden järjestelmien toimivuuden perivien järjestelmien suunnittelussa.

Tällä hetkellä UML on ohjelmistojärjestelmien visuaalisen mallintamisen standardimerkintä, jonka Object Managing Group (OMG) -konsortio otti käyttöön syksyllä 1997 ja jota tukevat monet oliopohjaiset CASE-tuotteet.

UML-standardi tarjoaa seuraavat kaaviot mallintamiseen:

· käyttötapauskaavio – organisaation tai yrityksen liiketoimintaprosessien mallintamiseen ja luotavan tietojärjestelmän vaatimusten määrittämiseen;

· luokkakaavio – järjestelmäluokkien staattisen rakenteen ja niiden välisten yhteyksien mallintamiseen;

· järjestelmän käyttäytymiskaaviot;

· vuorovaikutuskaaviot;

· järjestyskaaviot – objektien välisen viestintäprosessin mallintamiseen yhden käyttötapauksen sisällä;

· yhteistyökaavio – objektien välisen viestintäprosessin mallintamiseen yhden käyttötapauksen sisällä;

· tilakaaviokaavio – järjestelmäobjektien käyttäytymisen mallintamiseen tilasta toiseen siirtymisen aikana;

· toimintakaavio – järjestelmän käyttäytymisen mallintamiseen eri käyttötapausten tai mallinnustoimintojen puitteissa;

toteutuskaaviot:

· komponenttikaaviot – tietojärjestelmän komponenttien (alijärjestelmien) hierarkian mallintamiseen;

· käyttöönottokaavio – suunnitellun tietojärjestelmän fyysisen arkkitehtuurin mallintamiseen.

Kuvassa 1.1 esittää integroidun tietojärjestelmän mallin sisältäen tärkeimmät kaaviot, joita tässä kurssiprojektissa tulisi kehittää.

Riisi. 1. Tietojärjestelmän integroitu malli UML-merkinnällä

4.2. Käyttötapauskaavio

Käyttötapaus on toimintosarja, jonka järjestelmä suorittaa vastauksena jonkin ulkoisen objektin (toimijan) käynnistämään tapahtumaan. Käyttötapaus kuvaa tyypillistä vuorovaikutusta käyttäjän ja järjestelmän välillä. Yksinkertaisimmassa tapauksessa käyttötapaus määritetään, kun keskustellaan käyttäjän kanssa toiminnoista, joita hän haluaa toteuttaa tässä tietojärjestelmässä. UML:ssä käyttötapaus on kuvattu seuraavasti:

Kuva 2. Käyttötapaus

Toimija on rooli, joka käyttäjällä on suhteessa järjestelmään. Näyttelijät edustavat rooleja, eivät tiettyjä ihmisiä tai ammattinimikkeitä. Vaikka ne on kuvattu käyttötapauskaavioissa tyyliteltyinä ihmishahmoina, toimija voi olla myös ulkopuolinen tietojärjestelmä, joka tarvitsee tietoa kyseisestä järjestelmästä. Toimijat tulisi näyttää kaaviossa vain, jos he todella tarvitsevat käyttötapauksia. UML:ssä toimijat esitetään muotoina:

Kuva 3. Hahmo (näyttelijä)

Näyttelijät jaetaan kolmeen päätyyppiin:

· käyttäjät;

· järjestelmät;

· muut tämän kanssa vuorovaikutuksessa olevat järjestelmät;

Aika muuttuu toimijaksi, jos siitä riippuu järjestelmän tapahtumien käynnistyminen.

4.2.1. Käyttötapausten ja toimijoiden väliset suhteet

UML:ssä käyttötapauskaaviot tukevat useita kaavioelementtien välisiä suhteita:

· viestintä

sisällyttäminen (sisältää),

· laajentaa (pidentää),

· yleistäminen.

viestintälinkki on käyttötapauksen ja toimijan välinen suhde. UML:ssä viestintäsuhteet esitetään yksisuuntaisen assosioinnin (yhtenäisen viivan) avulla.

Kuva 4. Esimerkki viestintälinkistä

Ota yhteys käyttöön käytetään tilanteissa, joissa jokin järjestelmän käyttäytyminen toistuu useammassa kuin yhdessä käyttötapauksessa. Näitä liitäntöjä käytetään yleensä mallintamaan uudelleen käytettävää toimintoa.

Laajennusviestintä käytetään kuvaamaan muutoksia järjestelmän normaalissa käyttäytymisessä. Sen avulla yksi käyttötapaus voi tarvittaessa käyttää toisen käyttötapauksen toimintoja.

Kuva 5. Esimerkki sisällyttämis- ja laajennussuhteesta

Yleistysyhteys osoittaa, että useilla toimijoilla tai luokilla on yhteisiä ominaisuuksia.

Kuva 6. Yleistyslinkkiesimerkki

4.3.

Vuorovaikutuskaaviot kuvaa vuorovaikutuksessa olevien esineryhmien käyttäytymistä. Tyypillisesti vuorovaikutuskaavio kattaa objektien käyttäytymisen vain yhdessä käyttötapauksessa. Tällainen kaavio näyttää useita objekteja ja viestejä, joita ne vaihtavat keskenään.

Viesti on keino, jolla lähettävä objekti pyytää vastaanottavaa objektia suorittamaan jonkin toiminnoistaan.

Tiedottava viesti on viesti, joka antaa vastaanottajaobjektille tietoja sen tilan päivittämiseksi.

Pyydä viesti (kysely) on viesti, joka pyytää vapauttamaan joitakin tietoja vastaanottajaobjektista.

Pakollinen viesti on viesti, joka pyytää vastaanottajaobjektia suorittamaan jonkin toiminnon.

Vuorovaikutuskaavioita on kahdenlaisia: sekvenssikaaviot ja yhteistyökaaviot.

4.3.1. Sekvenssikaaviot

Järjestyskaavio kuvastaa yksittäisen käyttötapauksen sisällä tapahtuvaa tapahtumavirtaa.

Kaikki toimijat (toimijat, luokat tai objektit), jotka ovat mukana tietyssä skenaariossa (käyttötapauksessa), näkyvät kaavion yläosassa. Nuolet vastaavat viestejä, jotka välitetään toimijan ja objektin välillä tai objektien välillä vaadittujen toimintojen suorittamiseksi.

Sekvenssikaaviossa kohde on kuvattu suorakulmiona, josta on vedetty pystysuora katkoviiva. Tätä linjaa kutsutaan esineen elinehto . Se edustaa fragmenttia kohteen elinkaaresta vuorovaikutusprosessissa.

Jokainen viesti on esitetty nuolena kahden objektin elämänlinjojen välissä. Viestit näkyvät siinä järjestyksessä kuin ne näkyvät sivulla ylhäältä alas. Jokainen viesti on merkitty vähintään viestin nimellä. Voit halutessasi lisätä myös argumentteja ja joitain ohjaustietoja. Voit näyttää itsedelegoinnin – viestin, jonka objekti lähettää itselleen ja viestin nuoli osoittaa samaan elämänlinjaan.

Riisi. 7. Esimerkki sekvenssikaaviosta

4.3.2. Yhteistyökaavio

Yhteistyökaaviot näyttää tapahtumien kulun tietyssä skenaariossa (käyttötapaus). Viestit on järjestetty ajan mukaan, vaikka yhteistyökaaviot keskittyvät enemmän objektien välisiin yhteyksiin. Yhteistyökaavio esittää kaiken sekvenssikaaviossa olevan tiedon, mutta yhteistyökaavio kuvaa tapahtumien kulun eri tavalla. Se helpottaa objektien välisten yhteyksien ymmärtämistä.

Yhteistyökaaviossa, kuten sekvenssikaaviossa, nuolet edustavat tietyn käyttötapauksen sisällä vaihdettuja viestejä. Niiden aikajärjestys ilmaistaan ​​numeroimalla viestit.

Riisi. 8. Esimerkki yhteistyökaaviosta

4.4. Luokkakaavio

4.4.1. Yleistä tietoa

Luokkakaavio määrittelee järjestelmän luokkien tyypit ja niiden välillä olevat erilaiset staattiset yhteydet. Luokkakaaviot kuvaavat myös luokkien attribuutteja, luokkien operaatioita ja rajoituksia, jotka asetetaan luokkien välisille suhteille.

UML-kielellä luokkakaavio on graafi, jonka solmut ovat projektin staattisen rakenteen elementtejä (luokat, rajapinnat) ja kaaret solmujen välisiä suhteita (assosiaatiot, periytyminen, riippuvuudet).

Luokkakaavio kuvaa seuraavat elementit:

· Paketti - joukko mallielementtejä, jotka liittyvät loogisesti toisiinsa;

· Luokka (luokka) - kuvaus samankaltaisten objektien ryhmän yhteisistä ominaisuuksista;

· Käyttöliittymä - abstrakti luokka, joka määrittää joukon toimintoja, jotka tiettyyn rajapintaan liittyvä mielivaltaisen luokan objekti tarjoaa muille objekteille.

4.4.2. Luokka

Luokka on ryhmä kokonaisuuksia (objekteja), joilla on samankaltaisia ​​ominaisuuksia, nimittäin dataa ja käyttäytymistä. Yksittäistä luokan edustajaa kutsutaan luokan objektiksi tai yksinkertaisesti objektiksi.

Objektin käyttäytyminen UML:ssä viittaa mihin tahansa sääntöihin objektin vuorovaikutuksesta ulkomaailman ja itse objektin tietojen kanssa.

Kaavioissa luokka on kuvattu suorakulmiona, jossa on kiinteä reuna jaettuna vaakasuorilla viivoilla kolmeen osaan:

Yläosio (nimiosio) sisältää luokan nimen ja muita yleisiä ominaisuuksia (erityisesti stereotypia).

Keskimmäinen osa sisältää luettelon määritteistä

Alareunassa on luettelo luokan toiminnoista, jotka kuvastavat sen käyttäytymistä (luokan suorittamia toimia).

Mitään määrite- ja toimintoosiota ei välttämättä näytetä (tai molempia kerralla). Puuttuvan osan kohdalla sinun ei tarvitse piirtää jakoviivaa tai millään tavalla osoittaa elementtien olemassaoloa tai puuttumista siinä.

Lisäosia, kuten poikkeuksia, voidaan lisätä tietyn toteutuksen harkinnan mukaan.

Riisi. 9. Esimerkki luokkakaaviosta

4.4.2.1.Luokkastereotypiat

Luokkastereotypiat ovat mekanismi luokkien jakamiseksi luokkiin.

UML määrittelee kolme pääluokkastereotypiaa:

Raja (raja);

Entiteetti (kokonaisuus);

Ohjaus.

4.4.2.2.Rajaluokat

Rajaluokat ovat luokkia, jotka sijaitsevat järjestelmän ja koko ympäristön rajalla. Näitä ovat näytöt, raportit, liitännät laitteistoon (kuten tulostimet tai skannerit) ja liitännät muihin järjestelmiin.

Rajaluokkien löytämiseksi sinun on tutkittava käyttötapauskaavioita. Jokainen toimijan ja käyttötapauksen välinen vuorovaikutus on liitettävä vähintään yhteen rajaluokkaan. Juuri tämä luokka antaa näyttelijälle mahdollisuuden olla vuorovaikutuksessa järjestelmän kanssa.

4.4.2.3.Entiteettiluokat

Entiteettiluokat sisältävät tallennettuja tietoja. Niillä on suurin merkitys käyttäjälle, ja siksi niiden nimet käyttävät usein aihealueen termejä. Tyypillisesti tietokantaan luodaan taulukko jokaiselle entiteettiluokalle.

4.4.2.4.Kontrolliluokat

Kontrolliluokat vastaavat muiden luokkien toiminnan koordinoinnista. Tyypillisesti jokaisessa käyttötapauksessa on yksi ohjausluokka, joka ohjaa tapahtumasarjaa kyseisessä käyttötapauksessa. Manager-luokka vastaa koordinoinnista, mutta ei tarjoa itse mitään toimintoja, koska muut luokat eivät lähetä sille paljon viestejä. Sen sijaan hän lähettää itse monia viestejä. Esimiesluokka yksinkertaisesti delegoi vastuun muille luokille, minkä vuoksi sitä kutsutaan usein esimiesluokiksi.

Järjestelmässä voi olla muita ohjausluokkia, jotka ovat yhteisiä useille käyttötapauksille. Esimerkiksi voi olla SecurityManager-luokka, joka vastaa turvallisuuteen liittyvien tapahtumien seurannasta. TransactionManager-luokka vastaa tietokantatapahtumiin liittyvien viestien koordinoinnista. Järjestelmän toiminnan muita elementtejä, kuten resurssien jakamista, hajautettua tietojenkäsittelyä tai virheiden käsittelyä, voi olla muitakin johtajia.

Edellä mainittujen stereotypioiden lisäksi voit luoda omia.

4.4.2.5.Attribuutit

Attribuutti on luokkaan liittyvä tietoelementti. Attribuutit tallentavat kapseloituja luokkatietoja.

Koska attribuutit sisältyvät luokkaan, ne ovat piilossa muilta luokilta. Tämän vuoksi saatat joutua määrittämään, millä luokilla on oikeus lukea ja muuttaa attribuutteja. Tätä ominaisuutta kutsutaan attribuutin näkyvyydeksi.

Attribuutilla voi olla neljä mahdollista arvoa tälle parametrille:

Julkinen (yleinen, avoin). Tämä näkyvyysarvo olettaa, että attribuutti näkyy kaikille muille luokille. Mikä tahansa luokka voi tarkastella tai muuttaa määritteen arvoa. UML-merkinnän mukaan yleistä attribuuttia edeltää "+"-merkki.

Yksityinen (suljettu, salainen). Vastaava attribuutti ei näy millekään muulle luokalle. Yksityinen attribuutti on merkitty "–"-merkillä UML-merkinnän mukaisesti.

Suojattu (suojattu). Tämä attribuutti on vain itse luokan ja sen jälkeläisten käytettävissä. Suojatun attribuutin UML-merkintä on "#"-merkki.

Paketti tai toteutus (paketti). Oletetaan, että attribuutti on jaettu, mutta vain sen paketin puitteissa. Tämän tyyppistä näkyvyyttä ei osoita millään erityisellä kuvakkeella.

Suljettamisen tai turvallisuuden avulla voidaan välttää tilanne, jossa attribuutin arvo muuttuu järjestelmän kaikissa luokissa. Sen sijaan attribuutin muuttamisen logiikka sisältyy samaan luokkaan kuin itse attribuutti. Asetetut näkyvyysasetukset vaikuttavat luotuun koodiin.

4.4.2.6.Toiminnot

Toiminnot toteuttavat luokkaan liittyvää käyttäytymistä. Toiminnossa on kolme osaa: nimi, parametrit ja palautustyyppi.

Parametrit ovat argumentteja, jotka toiminto vastaanottaa syötteenä. Palautustyyppi viittaa operaation tulokseen.

Luokkakaavio voi näyttää sekä operaatioiden nimet että operaatioiden nimet sekä niiden parametrit ja palautustyypin. Kaavion kuormituksen vähentämiseksi on hyödyllistä näyttää vain toimintojen nimet joissakin niistä ja niiden täydellinen allekirjoitus toisissa.

UML:ssä toiminnoilla on seuraava merkintä:

Toiminnon nimi (argumentti: argumenttitietotyyppi, argumentti2:argumentti2-tietotyyppi,...): palautustyyppi

Harkitsettavana on neljä erilaista toimintotyyppiä:

Toteutustoimet;

Hallintotoiminta;

Pääsytoiminnot;

Aputoiminnot.

Toteutustoiminnot

Toteuttajatoiminnot toteuttavat joitain liiketoimintoja. Tällaisia ​​operaatioita voi löytää tutkimalla vuorovaikutuskaavioita. Tämäntyyppinen kaavio keskittyy liiketoimintatoimintoihin, ja jokainen kaavion viesti voidaan todennäköisesti yhdistää toteutustoimintoon.

Jokaisen toteutusoperaation tulee olla helposti jäljitettävissä vastaavaan vaatimukseen. Tämä saavutetaan simulaation eri vaiheissa. Toiminta johdetaan vuorovaikutuskaavion viestistä, viestit tulevat käyttötapauksen perusteella luodusta tapahtumavirran yksityiskohtaisesta kuvauksesta ja jälkimmäinen luodaan vaatimusten perusteella. Kyky jäljittää tätä koko ketjua mahdollistaa sen, että jokainen vaatimus toteutetaan koodissa ja jokainen koodinpala toteuttaa jonkin vaatimuksen.

Ohjaustoiminnot

Esimiehen toiminnot ohjaavat objektien luomista ja tuhoamista. Luokan rakentajat ja tuhoajat kuuluvat tähän luokkaan.

Pääsytoiminnot

Attribuutit ovat yleensä yksityisiä tai suojattuja. Muiden luokkien on kuitenkin joskus tarkasteltava tai muutettava arvojaan. Tätä tarkoitusta varten on olemassa pääsytoimintoja. Tämä lähestymistapa mahdollistaa attribuuttien turvallisen kapseloinnin luokan sisällä, suojaamalla niitä muilta luokilta, mutta sallien silti valvotun pääsyn niihin. Get- ja Set-operaatioiden luominen jokaiselle luokkaattribuutille on vakio.

Aputoiminnot

Helper-operaatiot ovat luokan operaatioita, jotka ovat välttämättömiä sille tehtäviensä suorittamiseksi, mutta joista muiden luokkien ei pitäisi tietää mitään. Nämä ovat yksityisiä ja suojatun luokan toimintoja.

Voit tunnistaa tapahtumat seuraavasti:

1. Opi järjestyskaaviot ja yhteistyökaaviot. Suurin osa näiden kaavioiden viesteistä on toteutustoimintoja. Heijastavat viestit ovat aputoimintoja.

2. Harkitse ohjaustoimintoja. Saatat joutua lisäämään rakentajia ja tuhoajia.

3. Harkitse pääsytoimintoja. Jokaiselle luokkaattribuutille, jota muiden luokkien tulee työskennellä, on luotava Get and Set -toiminnot.

4.4.2.7.Liitännät

Suhde edustaa semanttista suhdetta luokkien välillä. Se antaa luokalle mahdollisuuden oppia toisen luokan attribuuteista, toiminnoista ja suhteista. Toisin sanoen, jotta yksi luokka voisi lähettää viestin toiselle sekvenssikaaviossa tai yhteistyökaaviossa, niiden välillä on oltava suhde.

Luokkien välille voidaan muodostaa neljän tyyppisiä suhteita: assosiaatiot, riippuvuudet, aggregaatiot ja yleistykset.

Viestintäyhdistys

Assosiaatio on semanttinen yhteys luokkien välillä. Ne piirretään luokkakaavioon tavallisena viivana.

Riisi. 10. Viestintäyhdistys

Assosiaatiot voivat olla kaksisuuntaisia, kuten esimerkissä, tai yksisuuntaisia. UML:ssä kaksisuuntaiset assosiaatiot piirretään yksinkertaisena viivana ilman nuolia tai nuolilla molemmille puolille. Yksisuuntaisessa assosiaatiossa on vain yksi nuoli, joka osoittaa sen suunnan.

Assosiaatiosuunta voidaan määrittää tarkastelemalla järjestyskaavioita ja yhteistyökaavioita. Jos vain yksi luokka lähettää kaikki niillä olevat viestit ja vain toinen luokka vastaanottaa ne, mutta ei päinvastoin, näiden luokkien välillä on yksisuuntainen viestintä. Jos ainakin yksi viesti lähetetään vastakkaiseen suuntaan, assosioinnin on oltava kaksisuuntainen.

Assosiaatiot voivat olla refleksiivisiä. Refleksiivinen assosiaatio sisältää yhden luokan esiintymän, joka on vuorovaikutuksessa saman luokan muiden esiintymien kanssa.

Viestintäriippuvuus

Riippuvuussuhteet heijastavat myös luokkien välisiä suhteita, mutta ne ovat aina yksisuuntaisia ​​ja osoittavat, että yksi luokka riippuu toisessa tehdyistä määritelmistä. Esimerkiksi luokka A käyttää luokan B menetelmiä. Silloin kun luokka B muuttuu, on tarpeen tehdä vastaavat muutokset luokkaan A.

Riippuvuus esitetään katkoviivalla, joka on piirretty kahden kaavioelementin väliin, ja nuolen loppuun ankkuroidun elementin sanotaan riippuvan nuolen alkuun ankkuroidusta elementistä.

Riisi. 11. Viestintäriippuvuus

Kun luot koodia näille luokille, niille ei lisätä uusia attribuutteja. Viestinnän tukemiseksi luodaan kuitenkin kielikohtaisia ​​operaattoreita.

Viestinnän yhdistäminen

Aggregaatiot ovat tiukempi yhdistymismuoto. Aggregaatio on yhteys kokonaisuuden ja sen osan välillä. Sinulla voi esimerkiksi olla luokka nimeltä Auto, samoin kuin luokat, kuten moottori, renkaat ja muita auton osia. Tämän seurauksena Auto-luokan objekti koostuu moottoriluokan objektista, neljästä rengasobjektista jne. Aggregaatiot visualisoidaan viivana, jossa on luokkaa lähellä oleva timantti, joka on kokonaisluku:

Riisi. 11. Viestinnän yhdistäminen

Yksinkertaisen aggregoinnin lisäksi UML esittelee vahvemman aggregoinnin, jota kutsutaan koostumukseksi. Koostumuksen mukaan esine-osa voi kuulua vain yhteen kokonaisuuteen, ja lisäksi osien elinkaari on pääsääntöisesti sama kuin kokonaisuuden kierto: ne elävät ja kuolevat sen mukana. Kokonaisuuden poistaminen koskee sen osia.

Tätä peräkkäistä poistoa pidetään usein osana aggregaation määritelmää, mutta se viitataan aina, kun roolikerroin on 1...1; Jos esimerkiksi asiakas on poistettava, tämän poistamisen tulee koskea myös tilauksia (ja puolestaan ​​tilausrivejä).

UML malli(UML-malli) on kokoelma äärellisiä kielirakenteita, joista tärkeimmät ovat entiteetit ja niiden väliset suhteet.

Itse mallientiteetit ja suhteet ovat esimerkkejä metamallin metaluokista.

Kun tarkastellaan UML-mallia yleisimmistä kohdista, voidaan sanoa, että se on graafi (tarkemmin ladattu multi-pseudo-hyperdigraafi), jossa kärjet ja reunat ladataan lisäinformaatiolla ja joilla voi olla monimutkainen sisäinen rakenne. . Tämän graafin huippuja kutsutaan entiteeteiksi ja reunoja relaatioiksi.. Tämän osan loppuosa tarjoaa nopean (alustavan) mutta täydellisen yleiskatsauksen käytettävissä olevista entiteettityypeistä ja suhteista. Onneksi niitä ei ole liikaa. Kirjan seuraavissa luvuissa tarkastellaan kaikkia entiteettejä ja suhteita uudelleen, yksityiskohtaisemmin ja esimerkkien avulla.

1.4.1. Entiteetit

Yleiskatsauksen helpottamiseksi UML:n entiteetit voidaan jakaa neljään ryhmään:

• rakenteellinen;
• käyttäytyminen;
• ryhmittely;
• huomautus.

Rakennekokonaisuudet, kuten arvata saattaa, on tarkoitettu kuvaamaan rakennetta. Tyypillisesti rakenteellisia kokonaisuuksia ovat seuraavat.

Esine(objekti) 1 – entiteetti, joka on ainutlaatuinen ja kapseloi tilan ja käyttäytymisen.

Luokka(luokka) 2 – kuvaus objektijoukosta, jolla on yhteiset attribuutit, jotka määrittävät tilan ja toiminnot, jotka määrittävät käyttäytymisen.

Käyttöliittymä(rajapinta) 3 - nimetty toimintosarja, joka määrittelee joukon palveluita, joita kuluttaja voi pyytää ja joita palveluntarjoaja voi tarjota.

Yhteistyö(yhteistyö) 4 - kokoelma esineitä, jotka ovat vuorovaikutuksessa jonkin tavoitteen saavuttamiseksi.

Merkki(toimija) 5 – mallinnetun järjestelmän ulkopuolella oleva ja sen kanssa suoraan vuorovaikutuksessa oleva kokonaisuus.

∇ Tällainen suhde on varmasti olemassa, mikä näkyy kuvassa. UML 1:n kaaviotyyppien hierarkia riippuvuussuhteena stereotypiaan "jalostaa".

∇∇ UML 1:ssä yhteistyökaavion ja samannimisen kokonaisuuden välille syntyi tahaton assosiaatio, joka ei ollut täysin totta ja oli joskus harhaanjohtava.

∇∇∇ UML 2:ssa tilakaavion syntaktinen ja semanttinen kuormitus on muuttunut niin paljon, että nimi ei enää heijasta sisältöä.

Alla on luettelo tässä kirjassa käytetyistä uusista kaavioista ja niiden nimistä.

• Komposiittirakennekaavio
• Pakkauskaavio
• Tilan konekaavio
• Viestintäkaavio
• Vuorovaikutuksen yleiskuvauskaavio
• Ajoituskaavio

Kuvassa UML 2:n kaaviotyyppien hierarkia (osa 1 ja 2) Mukana on luokkakaavio, joka näyttää kaavioiden välisen suhteen UML 2:ssa.

Myöhemmin tässä luvussa kuvaamme hyvin lyhyesti kaikkia kolmetoista kanonista kaaviota, jotta meillä on jonkin verran kontekstia ja sanastoa seuraavalle. Yksityiskohdat esitetään kirjan muissa luvuissa.

Mutta ennen kuin siirrymme seuraavaan osaan, tehdään pieni poikkeama siitä, kuinka standardi vaatii kaavioiden suunnittelua. Alla on yleinen kaavioesitysmalli.

Suunnittelussa on kaksi pääelementtiä: ulkokehys ja tarra, jossa on kaavion nimi. Jos kaikki on yksinkertaista kehyksen kanssa - se on suorakulmio, joka rajoittaa aluetta, jolla kaavioelementtien tulisi sijaita, kaavion nimi kirjoitetaan erityisessä muodossa, joka on esitetty kuvassa. Kaavioiden merkintä.

Kaikki työkalut eivät tue tätä monimutkaista etikettimuotoa. Tämä ei kuitenkaan ole välttämätöntä, koska semantiikka on ensisijainen ja merkintä on toissijaista. Seuraavassa käytämme suorakulmiota kaavion otsikona, eikä tämän pitäisi aiheuttaa sekaannusta.

Mahdolliset kaavioiden tunnisteet (tyypit) on esitetty seuraavassa taulukossa. Standardin ehdottamat tunnisteet kirjoitetaan toiseen sarakkeeseen. Kuten käytäntö on osoittanut, standardin ehdottamat säännöt eivät kuitenkaan aina ole käteviä ja loogisesti perusteltuja, joten taulukon kolmas sarake sisältää mielestämme järkevän vaihtoehdon.

Taulukko Kaavion tyypit ja tunnisteet