Czym zajmuje się ustawodawca w IT

kubek zly systemNa jed­nym z blo­gów, któ­re lubię czy­tać, poja­wił się wpis z pytaniem:

Kto mi powie, jaka jest legal­na defi­ni­cja infor­ma­tycz­ne­go nośni­ka danych oraz sys­te­mu tele­in­for­ma­tycz­ne­go? No bo tak: o ile się nie mylę (a mogę, bo nie jestem praw­ni­kiem) usta­wa z dnia 4 wrze­śnia 2008 r. o zmia­nie ustaw w celu ujed­no­li­ce­nia ter­mi­no­lo­gii infor­ma­tycz­nej (Dz. U. Nr 171 z dnia 23 wrze­śnia 2008 r.) w swo­im pierw­szym arty­ku­le wpro­wa­dza do sze­re­gu ustaw czte­ry poję­cia infor­ma­tycz­ny nośnik danych”, doku­ment elek­tro­nicz­ny”, sys­tem tele­in­for­ma­tycz­ny” oraz środ­ki komu­ni­ka­cji elek­tro­nicz­nej” uży­te w art. 3 pkt 1 – 4 Ustawy z dnia 17 lute­go 2005 r. o infor­ma­ty­za­cji dzia­łal­no­ści pod­mio­tów reali­zu­ją­cych zada­nia publicz­ne (Dz. U. Nr 64, poz. 565, z 2006 r. z późn. zm.). (Notatki: Jak to jest?).

Postanowiłem przyj­rzeć się temu. Na bazie wyżej wymie­nio­nych ustaw oraz Kodeksu Postępowania Administracyjnego zro­bi­łem podej­ście” do ana­li­zy poję­cio­wej nasze­go sys­te­mu ustaw” w obsza­rze usług elek­tro­nicz­nych. I… Czytaj dalej… Czym zaj­mu­je się usta­wo­daw­ca w IT”

Nie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy

Pojęcie akto­ra, inte­gra­cji, inter­fej­sów itp. sta­le się prze­wi­ja w doku­men­tach wyma­gań, nie­jed­no­krot­nie w spo­sób błęd­ny co wpro­wa­dza zamęt w doku­men­ta­cji i zamęt w zro­zu­mie­niu pro­ble­mu do rozwiązania.

Co znaj­dzie­my w doku­men­ta­cji UML (UML 2.4.1. Superstructure 2011-08-05, rozdz. 16):

Use cases are a means for spe­ci­fy­ing requ­ired usa­ges of a sys­tem. Typically, they are used to cap­tu­re the requ­ire­ments of a sys­tem, that is, what a sys­tem is sup­po­sed to do. The key con­cepts asso­cia­ted with use cases are actors, use cases, and the sub­ject. The sub­ject is the sys­tem under con­si­de­ra­tion to which the use cases apply. The users and any other sys­tems that may inte­ract with the sub­ject are repre­sen­ted as actors. Actors always model enti­ties that are out­si­de the sys­tem. The requ­ired beha­vior of the sub­ject is spe­ci­fied by one or more use cases, which are defi­ned accor­ding to the needs of actors.

Ogólnie: Przypadek Użycia ozna­cza kon­kret­ne (w okre­ślo­nym celu) uży­cie Systemu. Standardowo Przypadków Użycia uży­wa się do opi­sa­nia wyma­gań wobec przy­szłe­go Systemu. Kluczowe poję­cia sko­ja­rzo­ne z Przypadkami Użycia to Aktor i przed­miot opi­su czy­li System. Użytkownik lub inny sys­tem może wcho­dzić w inte­rak­cje z Systemem jako Aktor. Aktor to zawsze byt zewnętrz­ny wzglę­dem Systemu (ale nie każ­dy nam zna­ny). Wymagane zacho­wa­nia (reak­cje) Systemu są spe­cy­fi­ko­wa­ne z pomo­cą jed­ne­go lub wie­lu przy­pad­ków uży­cia repre­zen­tu­ją­cych potrze­by Aktorów.

Aktorem jest więc zewnętrz­ny byt, któ­ry ma potrze­bę uży­cia Systemu w kon­kret­nym celu. Innymi sło­wy: Przypadek Użycia opi­su­je usłu­gą świad­czo­ną przez System dla jego Otoczenia. Użytkownicy tych usług to Aktorzy. Tak więc gene­ral­nie Przypadki Użycia to usłu­gi Systemu jakie świad­czy i są one ini­cjo­wa­ne przez jego Aktorów czy­li żąda­ją­cych obsłu­gi. Kluczowe tu jest stwier­dze­nie: Aktor to ten, któ­ry ini­cju­je dia­log z Systemem żąda­jąc obsługi.

Aby poka­zać gdzie są pro­ble­my poka­że to dokład­nie od koń­ca. Jak ktoś nie jest ana­li­ty­kiem może od razu przejść na koniec :).

Integracja czy­li kom­po­nen­ty i podsystemy 

Powyżej mamy dość typo­wą sytu­ację, w któ­rej mamy System pro­jek­to­wa­ny, inny Zewnętrzny System 1, któ­ry już u nas funk­cjo­nu­je. Z sys­te­mu pro­jek­to­wa­ne­go będzie korzy­stał Użytkownik oraz kolej­ny inny Zewnętrzny System 2. Zewnętrzny ozna­cza tu już ist­nie­ją­cy” (zewnętrz­ny wzglę­dem projektowanego).

Na dia­gra­mie (UML, dia­gram kom­po­nen­tów) uży­to sym­bo­li kom­po­nent i inter­fejs. Warto wie­dzieć, że inter­fej­sy mają dwa obli­cza”. Co do zasa­dy w UML (i meto­dach obiek­to­wych) wystę­pu­je poję­cie uży­cia” to zna­czy, że coś żąda reali­za­cji usłu­gi od cze­goś” albo jak kto woli coś uży­wa cze­goś do reali­za­cji swo­ich zadań”. Dlatego inter­fej­sy dzie­li­my na ofe­ro­wa­ne i wyma­ga­ne. Użytkownik uży­wa Systemu (jest on dla nie­go narzę­dziem pra­cy) do reali­za­cji swo­ich celów. Może to tak­że robić (żądać obsłu­gi) inny System.

Dwa typy interfejsów

Interfejs ofe­ro­wa­ny i wyma­ga­ny to dwa róż­ne byty”. Ogólnie, jeże­li jeden sys­tem wysy­ła żąda­nie wyko­na­nia jakiejś usłu­gi do dru­gie­go, to pierw­szy ma inter­fejs wyma­ga­ny a dru­gi ofe­ro­wa­ny (i muszą być zgod­ne ;)). Zestaw pole­ceń rozu­mia­nych” przez inter­fejs ofe­ro­wa­ny to język”, któ­ry musi znać inter­fejs wyma­ga­ny (sys­tem wywo­łu­ją­cy). W prak­ty­ce wyglą­da to tak, że inter­fejs ofe­ro­wa­ny ma doku­men­ta­cję, któ­rą powi­nien dostać pro­gra­mi­sta inter­fej­su wyma­ga­ne­go (wywo­łu­ją­ce­go zdal­ny System).

Tak więc mamy już świa­do­mość ról uży­wa­ją­cy i uży­wa­ny (w UML poka­zu­je to zwią­zek uży­cia: strzał­ka z linii kre­sko­wej z gro­tem wska­zu­ją­cym na system/obiekt wywo­ły­wa­ny, świad­czą­cy usłu­gę, patrz pierw­szy diagram).

Od środ­ka

Popatrzmy na stwo­rzo­ny sys­tem”. System już po napi­sa­niu” mógł by wyglą­dać tak (uży­to [[wzor­ców pro­jek­to­wych, w tym wzor­ca MVC]]):

Co tu mamy? Użytkownik to oso­ba korzy­sta­ją­ca z Systemu Projektowanego. Każdy przy­pa­dek uży­cia ma swo­ją dedy­ko­wa­ną kla­sę, któ­ra wie jak świad­czyć daną usłu­gę”. Model dzie­dzi­ny odwzo­ro­wu­je prze­twa­rza­ne dane (Jakaś kla­sa, agre­ga­ty itp.), są kla­sy świad­czą­ce jakieś wewnętrz­ne usłu­gi. W trak­cie ana­li­zy i pro­jek­to­wa­nia może się oka­zać, że jakaś potrzeb­na wewnątrz Systemu Projektowanego usłu­ga jest już dostęp­na w sie­ci Zamawiającego, zna­my Zewnętrzny System 1, któ­ry ją ma, spraw­dza­my czy System ten ma inter­fejs do tej usłu­gi lub czy moż­na go napi­sać. (np. mamy już sys­tem kadro­wo-pla­co­wy więc nie musi­my po raz dru­gi imple­men­to­wać listy pra­cow­ni­ków, może­my o dane pra­cow­ni­ka pro­sić ten ist­nie­ją­cy już zewnętrz­ny system).

W ramach pro­jek­tu więc nie imple­men­tu­je­my dru­gi raz takiej usług (nie dublu­je­my jej w naszej sie­ci) tyl­ko two­rzy­my inter­fejs, kla­sę któ­ra będzie wywo­ły­wa­ła Zewnętrzny System 1, za każ­dym razem gdy usłu­ga ta będzie wyma­ga­na. Nie pozwa­la­my na bez­po­śred­nie wywo­ła­nia z wnę­trza nasze­go Systemu Projektowanego, bo to uza­leż­ni całe jego wnę­trze od szcze­gó­łów obce­go Systemu. Tworzymy adap­ter” czy­li masku­je­my” obcy sys­tem (Klasa «Interfejs» to ten adap­ter). Dzięki temu jego, Zewnętrznego Systemu 1, ewen­tu­al­na wymia­na nie zaowo­cu­je prze­rób­ka­mi nasze­go Systemu Projektowanego. Gdyby trze­ba było zre­zy­gno­wać z Zewnętrznego Systemu 1, kla­sę adap­te­ra wypeł­ni­my imple­men­ta­cją potrzeb­nych funk­cji a resz­ta Systemu Projektowanego nie odczu­je zmiany.

Mamy więc już pro­jekt. A teraz wra­ca­my do począt­ku i narysujemy

Diagram przy­pad­ków użycia

któ­ry obra­zu­je powyż­szy projekt:

To jest to co zro­zu­mie Klient, naj­prost­szy dia­gram do poka­za­nia, zawie­ra zakres pro­jek­tu, gra­ni­ce sys­te­mu (naj­waż­niej­sza rzecz) i akto­rów (część różo­wa tyl­ko dla lep­sze­go zro­zu­mie­nia tre­ści arty­ku­łu). Inny System, jeże­li ini­cju­je akcję czy­li żąda usłu­gi tak­że jest akto­rem, ale System reali­zu­ją­cy na nasze zle­ce­nie jakieś usłu­gi nie jest akto­rem, jest tyl­ko wywo­ły­wa­ny, sam z sie­bie nie ini­cju­je żad­nej akcji. On reali­zu­je jakąś potrzeb­ną nam funkcję.

Może się oka­zać, że Zewnętrzny sys­tem ma zarów­no inter­fejs ofe­ro­wa­ny jak i wyma­ga­ny, wte­dy w pro­jek­cie, na dia­gra­mie przy­pad­ków uży­cia, war­to ope­ro­wać nie nazwą zewnętrz­ne­go sys­te­mu (np. ERP któ­ry może mieć dzie­siąt­ki inter­fej­sów ofe­ro­wa­nych i wyma­ga­nych) a nazwą usłu­gi (inter­fejs ofe­ro­wa­ny) lub zda­rze­nia (inter­fejs wyma­ga­ny) będą­cych przed­mio­tem takich akcji i zakre­su projektu.

Diagram przy­pad­ków uży­cia to pierw­szy test zro­zu­mie­nia tego co i po co ma powstać. Jest to bar­dzo pro­sty dia­gram i dla­te­go każ­de uprosz­cze­nie lub nie­zro­zu­mie­nie, pro­wa­dzi nie raz do poważ­nych nie­po­ro­zu­mień a bywa, że do kra­chu pro­jek­tu. To bar­dzo waż­ny dia­gram. Powie nam do cze­go Systemy Projektowany będzie uży­wa­ny, to cel spon­so­ra. Na tej pod­sta­wie moż­na wybrać goto­we opro­gra­mo­wa­nie i testu­jąc je oce­nić przy­dat­ność (nie radze wybie­rać goto­we­go opro­gra­mo­wa­nia na bazie pre­zen­ta­cji!). Ale dia­gram ten nigdy nie powie jaką logi­kę nale­ży zaim­ple­men­to­wać, dla­te­go w przy­pad­ku two­rze­nia opro­gra­mo­wa­nia koniecz­ny jest jego pro­jekt: model dzie­dzi­ny sys­te­mu, jako kolej­ny etap pro­jek­tu na opro­gra­mo­wa­nie dedy­ko­wa­ne. Przypomnę tak­że, że przy­pad­ki uży­cia w wer­sji mini­mal­nej powin­ny mieć opis:

  • cel jego uży­cia (co Aktor chce osiągnąć)
  • stan począt­ko­wy (wej­ście, dane wej­ścio­we, itp.)
  • stan koń­co­wy (wyj­ście, dane wyj­ścio­we itp.)

Tu zwra­cam uwa­gę, że powyż­sze to zara­zem testy akcep­ta­cyj­ne otrzy­ma­ne­go oprogramowania.