Mikä on helpoin ratkaisu ohjelmistoarkkitehtuurikaavioiden luomiseen?


Paras vastaus

Jos aiot käyttää UML: ää (yleisimmin käytetyt kaaviot) luomiseen ohjelmistoarkkitehtuurisi, Visual Paradigm Community Edition on täysin ilmainen ratkaisu (henkilökohtaisille ja muille -Commercial).

Tuki UML 2.5 -kaavioille (tässä on MVC-kehysohjelmistoarkkitehtuuri, joka käyttää jaksokaaviota)

Malli – näkymä – ohjain ( MVC ) on yksi yleisimmin käytetyistä ohjelmointiarkkitehtuurikehyksistä käyttöliittymien kehittämiseksi, joka jakaa sovelluksen kolmeen toisiinsa yhdistettyyn osaan (malli / näkymä ja ohjain). Tämä tehdään tiedon sisäisten esitysten erottamiseksi tavoista, joilla tieto esitetään ja hyväksytään käyttäjältä.

MVC-arkkitehtuuri irrottaa nämä pääkomponentit, mikä mahdollistaa koodin tehokkaan uudelleenkäytön ja rinnakkaisen kehityksen käsitteen avulla. sekä Web- että työpöytäsovelluksiin soveltuvien huolenaiheiden erottaminen.

Esimerkiksi: JHispter on MVC-kehys (yhdessä REST-sovellusliittymän kanssa) Verkkosovellukset, vaikka suosituin kehysjousi kuuluvat myös MVC: hen kaikenlaisissa sovelluksissa.

UML: ssä voit käyttää sekvenssiä kaavio edustaa MVC-ohjelmistoarkkitehtuuriasi. (Lähde: Visual Paradigm MVC Framework – Visual Paradigm Community Circle )

  • Entiteetit ovat järjestelmätiedot edustavia objekteja: Asiakas, Tuote, Tapahtuma, Ostoskori jne.
  • Rajat ovat objekteja, jotka ovat vuorovaikutuksessa järjestelmän toimijoiden kanssa: UserInterface, DataBaseGateway, ServerProxy jne.
  • Ohjaimet ovat objekteja, jotka välittävät rajojen ja entiteettien välillä.

Ne järjestävät komentojen suorittamisen tulevat rajalta olemalla vuorovaikutuksessa entiteetin ja rajaobjektien kanssa. Ohjaimet vastaavat usein käyttötapausten skenaariota ja ne on usein esitetty sekvenssikaaviona.

Voit käyttää stereotyyppejä MVC-jaksokaaviossa tehdä visuaalisesti selväksi minkä tyyppisiä objekteja käytät MVC: ssä

MVC-sekvenssikaavion luominen ilmaisella UML-työkalulla

Ymmärrä lisää UML-kaavioista

Lisätietoja jaksokaavioista

Vastaa

Korkean tason lähestymistapa, jota yleensä noudatan arkkitehtuureja (tai vielä yksityiskohtaisempia, alemman tason suunnitelmia) dokumentoitaessa, on:

  1. Tunnista suunnittelun sidosryhmät. Suunnittelu- / kehitystiimi on yksi sidosryhmistä. Testaus- / laadunvarmistusryhmäsi, IT-infrastruktuuritiimisi, projektinhallinta ja ehkä tukihenkilöstö voivat myös olla järjestelmän sidosryhmiä ja kiinnostuneita suunnittelun eri näkökohdista.
  2. Tunnista järjestelmän huolenaiheet. Jos järjestelmässäsi on tietokanta, yksi näkökulma on tietokannan rakenne. Jos sinulla on hajautettu järjestelmä, järjestelmänvalvojat tai asiakaspalveluhenkilöstö saattavat olla kiinnostuneita siitä, mihin komponentit asennetaan. Jos sinulla on julkinen käyttöliittymä, ulkoiset kehittäjät ovat kiinnostuneita siitä, mikä kyseinen käyttöliittymä on – tiedostomuodot, datamuodot jne. Jos sinulla on monia monimutkaisia ​​algoritmeja, algoritmisuunnittelijat / ylläpitäjät ovat kiinnostuneita työnkulkuista ja algoritmivaiheista. Jokainen tunnistamasi näkökulma on erityinen huolenaihe.
  3. Valitse jokaiselle näkökulmallesi sopiva esitys. Tietokannan näkökulmasta ehkä hyödyllisiä ovat entiteettisuhdekaaviot ja datasanakirja. Julkisten rajapintojen yhteydessä XML-skeemadokumentit tai API-dokumentaatio voidaan sisällyttää dokumentaatioosi. Harkitse monimutkaisia ​​algoritmeja UML-toiminnan tai vuorovaikutuksen yleiskaavioiden avulla. Kun valitset merkinnän, pidän parempana tunnetuista ja hyvin määritellyistä merkinnöistä, joten minun ei tarvitse selittää merkintääni jollekulle muulle ja voin vain osoittaa heidät olemassa olevaan viitemateriaaliin, jos he eivät tiedä käytettyjä symboleja. / li>
  4. Lisää kaavioiden ympärille tekstikuvaus ja rationaalisuus. Selitä paitsi tekemäsi arkkitehtoniset päätökset, mutta myös se, mikä sai sinut tekemään näitä päätöksiä.

Arkkitehtoniset puitteet, kuten Zachman Framework, The Open Group Architectural Framework, Department of Puolustusarkkitehtuurikehys ja muut arkkitehtuurikehykset auttavat määrittelemällä olennaiset näkökulmat ja yleisesti sovellettavat näkymät.

”Paras” dokumentaatio on viime kädessä sidosryhmien tarpeiden mukainen.Ensimmäinen vaihe on tunnistaa, kuka tarvitsee tietoja ja mitä he tarvitsevat.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *