JĘZYK OBIEKTOWEJ SPECYFIKACJI OSL
Transkrypt
JĘZYK OBIEKTOWEJ SPECYFIKACJI OSL
Page 1 of 11 Zygmunt Ryznar ZYK OBIEKTOWEJ SPECYFIKACJI OSL Pokusa opracowania uniwersalnego j zyka specyfikacyjnego n ci a mnie od dawna. Przez lata dok ada em kolejne s owa kluczowe i zwroty, a propozycja j zyka przybra a odpowiedni kszta t. J zyk powstawa hobbystycznie (w czasie prywatnym bez jakiegokolwiek wsparcia firmowego) wy cznie z inspiracji wewn trznej na gruncie do wiadczenia zawodowego w charakterze projektanta i programisty. Wydaje si mie charakter teoretyczny, jednak dla mnie jest pomostem pomi dzy teori i praktyk . ównym celem niniejszej publikacji jest bezinteresowne zainspirowanie kogokolwiek do dalszych prac rozwojowych i implementacyjnych Uniwersalno j zyka OSL (Object Specification Language) starano si wykaza na przyk adzie tak ró nych obiektów jak biznes bankowy, system informatyczny i istota ludzka [12]. Zosta on zaprojektowany warstwowo: istnieje uniwersalne j dro oraz specjalizowane podzbiory, w których mo na definiowa dodatkowe s owa kluczowe i ekwiwalenty skrótowe zgodne z potrzebami obszaru (“AREA”). W opisie obszaru wyró nia si warstw rodowiska zewn trznego UNIVERSE (np. w bankowo ci dla banku jest to rodowisko biznesu finansowego) oraz warstwy wewn trzne zwi zane ze specyfik bran y np. z typem banku, specjalizacj oddzia u, rodzajem klienta itp. W podzbiorze opisuj cym system informatyczny szczególn uwag zwraca si na obiekty komponentowe podlegaj ce strojeniu i monta owi. W za eniu j zyk spe nia ma zadania dokumentacyjne, technologiczne i poznawcze, reprezentuj c podej cie obiektowo-komponentowe. Jak wiadomo, obiekt jest scaleniem (enkapsulacj , hermetyzacj ) struktur danych, procedur i regu zachowania si . OSL specyfikuje struktur funkcjonaln obiektu i jego dynamik poprzez procesy, akcje, transakcje, zdarzenia. Modelowanie danych pozostawia si systemom zarz dzania bazami danych. Tak jak j zyk programowania s y do pisania programów, to OSL jest narz dziem do pisania specyfikacji. Jednak e w odró nieniu od tego pierwszego, ten j zyk mo e sta si modyfikowalnym metaj zykiem gdy do jego implementacji zostan u yte zmienne tezaurusy (s ów kluczowych, zwrotów i fraz) dopasowane do potrzeb obszaru, j zyka narodowego i rodowiska informatycznego. Notacja j zyka zawiera oprócz “klasycznych” struktur tak e konceptualne (nie graficzne) figuralne prezentacje procesu i populacji, takie jak spirale pojedyncze i wielopasmowe, rój, tunel, przestrze swobodna, czarna dziura, zwyk e figury geometryczne (trójk t, kwadrat, ko o) itp. Rodzaj wybranej figury zale y od rozk adu danych i zachowania obiektów. W trójk cie mo na np. przedstawi preferencje zatrudnienia zale ne od 3 czynników: wiek, wykszta cenie, p . Spirala od iteracji ró ni si tym, i ka dy jej zwój mo e posiada inne mechanizmy i tre . Typow ilustracj spirali s procesy ucz ce si . W postaci spirali wielopasmowej mo na przedstawi równoleg e kszta towanie si kilku wska ników globalnych firmy (np. zysku, zdolno ci konkurencyjnej, kredytowej). Rój odnosi si do jednorodnej przemieszczalnej populacji o du ej zmiennej g sto ci - mo e ilustrowa np. zachowanie firm globalnych z us ugami franczyzy. Tunel odnosi si do przestrzennej populacji z du ym nasyceniem warto ci (np. sumy ró norodnych kredytów) w okre lonym przedziale na osi czasu oraz w okre lonym przedziale wspó czynnika globalnego (np. zdolno ci kredytowej). Walec tym ró ni si od tunelu, ze nosi populacj na powierzchni, a tunel ma wype nione wn trze. „Czarna-dziura” oznacza nieodwracalne znikni cie obiektu (np. bankructwo firmy) a jej warto ci jest „si a wci gania ” (np. szybko bankructwa). Zak ada si , e figury mog by predefiniowane dla obiektów na podstawie ich przewidywanego zachowania, a potem weryfikowane danymi rzeczywistymi poprzez uczenie modeli figur, podobnie jak to ma miejsce w przypadku sieci neuronowych. zyk OSL sk ada si ze zwrotów sformalizowanych i s ów kluczowych specyfikowanych do u ywania w lokalnym obszarze biznesowym (AREA) lub globalnie w ramach tzw. wiata (UNIVERSE). S pisane zwi le w prostym j zyku angielskim (z mo liwo ci definiowania ekwiwalentów w j zyku narodowym), dlatego posiadaj walory dokumentacyjne. W notacji u ywane s znaki dost pne na zwyk ej klawiaturze, co sprzyja zastosowaniu j zyka. Opis dokonywany jest w imieniu g ównego podmiotu (SUBJECT) jakim mo e by np. instytucja 2016-10-31 Page 2 of 11 realizuj ca dzia alno biznesow czy system. UNIVERSE, AREA i SUBJECT s superklasami. Wyró nia si równie tzw. obiekty wykonawczo-operacyjne (np. pracownicy) oraz obiekty infrastruktury (np. serwery, bazy danych). Opis obiektu mo e by obszerny, lecz wyst puje skrótowa charakterystyka obiektu w postaci tzw. okienka informacyjnego (infoWindow), które mo e by pokazywane w zbiorczym indeksie obiektów. ZYK OSL V.3.1 Notacja <! komentarz> <.> <!pojemnik-container> <def nazwa obiektu> <!pocz tek sekcji definicji obiektu>, </def><!koniec definicji> <spec nazwa specyfikacji><!pocz tek spec, wyst pienia obiektu>,</spec> <!koniec specyfikacji> ::= <!przypisanie typu (np. klasy, obiektu)>, := <!przypisanie funkcyjne lub przypisanie do listy> = <!przypisanie warto ci czyli podstawienie> : <!przypisanie obiektowi atrybutu> :: <!przynale no > = = <!ekwiwalentno > {.....} <!ograniczniki sekcji>, (……) <!ograniczniki listy> ,<!ogranicznik frazy> N# <!liczba wyst pie >, (x,y,..) <! lista>,(x/y/..) <! lista roz cznych elementów> YYYYYY.UUUUU(XXXXXX) <!struktura, kwalifikowana nazwa obiektu> name/[name] <!obiekt wykonawczo-operacyjny>, XXXX/(XXXX) <!obiekt podmiotowy np.biznesowy>, <-> <!relacja dwukierunkowa 1:1, jednostkowa - unary> <=> <!relacja dwukierunkowa n:n, many to many), <=, => <!jednokierunkowa n:n>, <- <!relacja jednokierunkowa zwrotna>, -> <!relacja jednokierunkowa pierwotna> DRO J ZYKA <def OSL> <! > subsets::=(BSL,SSL,HSL) keywords:=(id <!identyfikator obiektu>,role,relation,message,data,state,status, objectTypes,infoWindow<! informacje uzewn trzniane przez obiekt>, flow, infoFlow<!przep yw informacji>,dataFlow<!przep yw danych np. w programie>, l 2016-10-31 Page 3 of 11 controlFlow<!przep yw sterowania>,infoTable<!zestaw informacji>,message, dataTable <!tablica z bazy danych,plik>,dbase,bigdata,szbd,hurtd,transFile, < x>OBJECT <!typ obiektu>,olh<!object life history>) message:=(text,picture,clip,graph),info:=(message,report), data:=(field,record,file)<! Struktury danych opisane w systemie zarz dzania baz danych>, state := (active,inactive,dormant,suspended,aborted,idle,lost), status:= (generic,real,virtual,projected), Class0::=(UNIVERSE, AREA,subAREA,SUBJECT), objectTypes::=(eOBJECT<!obiekt elementarny>,iOBJECT<!obiekt informacyjny>, mOBJECT<!obiekt materialny>,fOBJECT<!obiekt finansowy>, vOBJECT < obiekt wirtualny>,dOBJECT<! obiekt dynamiczny>) dOBJECT::= (ZD==ZDARZENIE,TRANS==TRANSAKCJA,AKCJA,PROCES)== (EVENT,TRANSACTION,ACTION,PROCESS) <! definiowanie dwuj zyczne> <! ZDARZENIE jest to elementarny fakt, czyn, dzia anie lub zaniechanie dzia ania> <!TRANSAKCJA jest to sekwencja zdarze maj ca na celu realizacj konkretnego celu > <!AKCJA jest to dzia anie kilku zdarze > <!PROCES jest to ci g akcji i zdarze posiadaj cy wspólne zadanie inicjowany przez zdarzenie inicjuj ce i ko czony przez zdarzenie ko cowe)> role:= (commander<!obiekt steruj cy procesem, odpowiedzialny>, trigger<!obiekt inicjuj cy/uruchamiaj cy>, generator<! obiekt generuj cy np. zdarzenia>, agent<! reprezentuje us ug np. agent w call-center>, integrator<! obiekt integruj cy obiekty>,sender,receiver, monitor<! ledzi wykonanie/przebieg procesu>,component maker,executor,,participant,cooperator, owner,stockholder,customer,supplier,partner,employee) relation:=(activated by/activates, activated when/if, appearence depends on,coming from,built/made(by,of,in), 2016-10-31 Page 4 of 11 assisted by, belongs to /is owned by,called by,used by/uses,using, communicates to <…..> using <…..>,sends <message>, calls <obiekt> (xxx,yyy) <!xxx elementy przekazywane., yyy elementy zwracane>, consists of <parts> , contained in/contains, controlled by/controls,derived from, driven by(date,schedule,frequency),involved in,shared by/shares, existence depends on, exists when/in/for, evaluated as (critical,mostWanted) , included in,evaluated by,linked to ...by / links,matched/matches,performed by, refers to,related by affinity,represented by/ represents) controlFlow:=(repetition :=(iteration, single spiral, multiband spiral), activated .... BY ...with <initial-value> AT <time-point> WHEN .., finished AT <> with <value> WHEN ...,process==pr action==ac event==ev ac::=(ev1,ev2,ev3, ..),pr::=(ac1,ac2,ac3,...), s(ev1,ev2,ev3, ..)<!sekwencja>,p(ev1,ev2,ev3, ..)<!równoleg y przep yw zdarze >, pr::=s(ac1,s(ev1,ev2,ev3),ac2(p(ev4,ev5,ev6),(ev7,ev8,..))<!z ony proces>), dataFlow:=(<data> from (<.>) to (<.>) using <data-transformation>)<!global flow>, infoFlow:=(<info> from <sender> to <receiver> AT (time-point,schedule,onDemand)) {body:=(Contents,Script,Metadata) contents <!zawarto cia a np. tre dokumentu, kod programu> script <! lista dzia generowanych przez obiekt> Metadata:=(layout,simulation/modeling) layout:= (freespace/swarm==rój/network/hierarchy/line/triangle/tunnel/cylinder/blackhole) simulation/modeling:=(deterministic,heuristic,stochastic,neuralNet)} </def> OSL-B (BSL) BUSINESS SPECIFICATION LANGUAGE - OSL do opisu obiektów biznesowych Jak wspomnieli my, w OSL zwraca si szczególn uwag na dynamik poprzez definiowanie zdarze , transakcji, akcji i procesów. Zdarzenie jest to elementarny niepodzielny fakt, czyn, dzia anie lub zaniechanie spodziewanego dzia ania np. niedokonanie sp aty raty kredytu w terminie zmienia status kredytu. Transakcja jest to sekwencja zdarze maj ca na celu realizacj krótkoterminowego celu, np. otwarcie lokaty i dokonanie wp aty. Akcja jest to z o one dzia anie np. uzgodnienia transakcji, ocena kategorii kredytowej i tworzenie rezerw na 2016-10-31 Page 5 of 11 trudne kredyty. Proces jest to ci g akcji i zdarze posiadaj cy wspólne zadanie inicjowany przez zdarzenie inicjuj ce i ko czony przez zdarzenie ko cowe np. proces obs ugi rachunku na koniec dnia obejmuj cy naliczenie odsetek, pobranie op at, kapitalizacj odsetek itd. Zamieszczony przyk ad dotyczy fragmentów biznesu bankowego i stanowi jedynie ilustracj metody. <def OSL-B><!BSL> ENVIRONMENT==ENV:=(REGULATIONS,INFRASTRUCTURE,KIR,ELIXIR,KNF,RPP,NBP)<! rodowisko> ENV.REGULATIONS:=(AktyPrawne,Regulaminy,Zarz dzenia) keywords:=(company,division,businessArea,objectives,decisions,board,infoRequirements) flow::=(mFlow<!materialny>,eFlow<!energetyczny>,lFlow<! labour-zatrudnieniowy>, fFlow<! finansowy>, iFlow<!informacyjny>), iOBJECT<!obiekt informacyjny np. informacje o tzw. pozycji klienta>, vOBJECT < obiekt wirtualny np. lustrzane rachunki Nostro>, dOBJECT<! obiekt dynamiczny np. transakcja>, eOBJECT<!obiekty elementarne>, dOBJECT::=(ZD,TRANS,AKCJA,PROCES)==(EVENT,TRANS,ACTION,PROCESS) relation:=(activated by.. when.. using.., driven by (transaction,product,customer,regulations,schedule,date,frequency) existence depends on/exists when/in/for <! np. istnienie konta zale y od istnienia klienta>, evaluated,linked to ...by/links to, matched/matches), attribute:=(standard,warning,critical,mostWanted) <def AREA(BANKING)> MODULE::=(RACHUNKI,LOKATY,KREDYTY,INFO_O_KLIENTACH,RYNEK_PIENI NY, AKREDYTYWA,P ATNO CI,PAPIERY_WARTOSCIOWE) OBJECT::=(BANK,ODDZIA ,PRODUKT,RACHUNEK,KLIENT,WALUTA,DELIVERY-CHANNEL) <def UNIVERSE(INTERNATIONAL_BANKING)> id :=BIC<!mi dzynarodowy identyfikator banku macierzystego>, keywords:= (IBAN<!International Bank Account Number>, ICC <!International Chamber of Commerce>,BIC<!Bank Identification Code>), 2016-10-31 Page 6 of 11 infoTable:= (LIBOR,REUTERS2000, UCP500, ICC500, URR525,SWIFTmessages, InternationalBanks,StockMarket) <def SUBJECT(MÓJ_BANK)> infoWindow:=(idBanku,Typ,kraj,WalutaBazowa,D ugo RokuFinansowego, LiczbaOddzia ów,LimityWalutowe), infoTable:=(BankiKorespondenci,Oddzia y,KalendarzDniRoboczych,PlanKont, Waluty,Produkty,Transakcje) keywords:=(NrOddz,idKlienta,NrRachunku,StopaOds,KursWym,DataKs,DataEfekt, SaldoDost pne,SaldoKsi gowe,kwota,kapita OdsetkiNal,OdsetkiSkapit, DataWygas,Limity,SaldoDebet,zdolno Kredyt,overDraft,Ryzyko,end-of), End-of(day,month,year)==(eod,eom,eoy), Ryzyko:=(ryzykoKredytu,ryzykoKlienta,ryzykoWaluty,ryzykoKraju), Limity:=(LimKraju,LimBran y,LimKlienta,LimWaluty,LimDebetu), OperObjects ::= [dysponent,kasjer,MgrRachunku,MgrKlienta,MgrProduktu] PRODUKT ::= (RACHUNEK,LOKATA,KREDYT,PAPIER_WARTO CIOWY,DERYWAT,AKREDYTYWA), RACHUNEK ::=(ROR,RK-FIRMY,KONTO_OSZCZEDNO CIOWE), eOBJECT::=(KLIENT,RACHUNEK.ROR,KONTOKS,WALUTA), iOBJECT::=(POZKLIENTA), WalutaBazowa=PLN, cashFlow:=driven by end-of(day,month,year) for WALUTA(PLN,$,Euro), KLIENT:=(prKLIENT<!OsobyPrawne>, fzKLIENT<!OsobyFizyczne>), BANK:= (krBANK <!krajowy>,zagrBANK <!zagraniczny>, korBANK<!bank korespondent>), KONTOKS:=(bilKONTOKS <!KontoBilansowe>, pozKONTOKS < ! KontoPozabilansowe>), ZD:=(zdi <! inicjuj ce>, zdk<! ko cowe>, zdz<!zawieszaj ce>, zdu<!usuwaj ce>) <def PRODUKT> infoWindow:=(TypProduktu,waluta ), <def RACHUNEK> infoWindow :=(W ciciel,Wspólnicy,Pe nomocnicy,MinSaldo,Saldo,Obroty,HistoriaRachunku), Relates to idKlienta, 2016-10-31 Page 7 of 11 TRANSAKCJE:=(OtwRku,LikwRku,Wp ata,Wyp ata,Przelew,TrBankomat), <def RACHUNEK.ROR> id:= (NrRachunku), exists for fzCUSTOMER <!tylko dla osób fizycznych>, initiated by PierwszaWp ata, infoWindow:=(LimitDebetu,ZleceniaSta e,TypWyci gu,KartaVisa,Op aty, WarunkiOdnowienia), Procedures:=(GenerKsi gowa , NaliczOds, OdsKarne), eodTRANSAKCJE:=(Sta eZlecenia,PobrOp at,NaliczOds,OdsKarne), dataTables:=(Op aty,IndeksStóp,Ksi gowania), calls NaliczOds=(30,360,90,Zmienne,IndeksStóp), calls zdiArch(30d,eod)<!zdarzenie inicj ce archiwizacj transakcji z 30 dni wykonywane na koniec dnia>, calls zduArch(5y,eoy) <!zdarzenie usuwaj ce z archiwum transakcje starsze od 5 lat wykonywane podczas zamykania roku>) </def></def></def></def><!kc definicji PRODUKT> <def KLIENT> Belongs to <segment> evaluated by dataMining(segm), RACHUNEK:<lista rachunków klienta>, RACHUNEK(KREDYT) activated when (wniosek-kredytowy,dataMining(zdolno Kredyt), POZKLIENTA driven by eom<!zawiera m.i.sumaryczne obroty wg produktów i walut>, N#(rachunek,transakcja,overDraft)<!liczba rachunkow, transakcji, sald ujemnych) </def> </def></def></def></def><!kc definicji AREA(BANKING)> <def AREA(INDUSTRY) …….(<! m.i. przep ywy materia owe, energetyczne> </def> <def AREA(TRADE) 2016-10-31 Page 8 of 11 ……. </def> <def AREA(SERVICES) ……. </def></def><!kc definicji OSL-B> OSL-S (SSL) SYSTEM SPECIFICATION LANGUAGE - OSL do opisu systemu informatycznego Zakres systemu informatycznego mo e by bardzo obszerny. Na przyk ad system banku uniwersalnego sk ada si kilku tysi cy programów dla kilkuset produktów (z których ka dy wymaga innego algorytmu) i kilku tysi cy rodzai transakcji, software’u do zarz dzania ryzykiem oraz obs ugi ró norodnych kana ów dost powych (okienko w oddziale, internet, bankomat, infolinia). W obiektowo-komponentowym uj ciu mo liwe staje si „uproszczenie” obrazu takiego systemu, gdy jednostka aplikacyjna powstaje z komponentów, które wyra aj tzw. logik aplikacji. Logika ta jest dost pna poprzez zestaw us ug, za projektant buduje aplikacj znaj c tylko us ugi, nie za sposób ich realizacji. Przyk adowo, w obiektowo zdefiniowanym systemie bankowym znaj c zachowanie si us ugi produktów bankowych mo emy projektowa aplikacj projekcji przep ywu pieni nego oraz zbada wp yw zmiany rozwarcia stóp procentowych na ryzyko p ynno ci w skali banku. W zale no ci od wyników analizy mo emy tworzy nowe obiekty (nowe produkty bankowe) z nowym zestawem parametrów (np. inny okres lokaty/kredytu, inne stopy procentowe). Podane poni ej zwroty dotycz ownie komponentów wykonawczych umo liwiaj cych strojenie (tuning) oprogramowania aplikacyjnego. <def OSL-S><!SSL> ENV.INFRASTRUCTURE== ENV.INFR, ENV.INFR:= (compCenter,mainComputer,network,operSystem,application,transDataBase,dbms, dataWarehouse,dataMart,dataMining,bigData,prgLang,prgName,prgLibrary) AREA:=(MIS,PCS,ERP)<!Management Information System, Process Control System,Enterprise Resource Planning> <def AREA(BANKING.MIS) <def SUBJECT(MÓJ_BANK.MIS)> MIS::=(SUBSYSTEM.MODULE.PROGRAM.B-BLOCK), SUBSYSTEMS::=(RETAIL,CORPORATE,MONEY&CAPITAL,RISK-MGT,CRM,CONTROLL-BUDGET, …), B-BLOCK<!building-block,generic-program/subprogram>, keywords:=(version,interface,run,runTime,integrated,standalone,accepted,notAccepted, failed,library,creatDate,updDate,tested,rejected,pCode,eCode,trace, comes from, 2016-10-31 Page 9 of 11 put,call,exit,when,callValue,trace,errorCode,inItems,outItems,execMode) state:=(inPlan,inProgress,inTest,accepted,rRun<!ready to run>), <data> from <dataMart> to <dataWarehouse> using (cleaning,compression)<!globalny przep yw>, OperObjects::=(analyst,designer,programmer,tester,operator,user), dOBJECT::=(RUN,JOB,TASK)===(PRZEBIEG,PRACA,ZADANIE), JOB<!several RUNs>,TASK<!sequence of JOBs>, trace::=(path,callValue,outValue,errorCode),process::=(trigger,action(<events>),endEvent), execMode:=(RT <!real time>,BAT<!batch>,OND <!on demand>) <def PROGRAM> infoWindow:=(prgName,version,state,author,creatDate,updDate,prgLang,operSystem) prgBody:=(interface,inputData,main,(prc1,prc2..<!lista procedur>),outputData) controlFlow:=(activated by <prg/prcName> > at <timePoint> when <condition> with <initialValue/inputData, finished at < timePoint /no-of-repetition> with <returnValue/outputData> when <condition>) <\def> <def B-BLOCK(name) objectInfo:=(name,version,author,updDate,codeSize,prgLanguage,operSystem) prcBody:=(init,main,end) resources:=(dataBuffer,eventTrace,stackHandler) <def flow> {call comes from <prg/prcName> with callValue action(verif) event(checkPassword,callVerif) exit when callVerif failed action(initial) when first call event(bufferDecl,stackDecl) action(tuning) 2016-10-31 Page 10 of 11 event(paramAnalysis,transform,generateExecutable) action(activate) event(activate) action(run) event(load,perform,releaseResources,exit) } </def> <def interface> <! Journal zawiera aktualny stan zasobów dla ka dego call> journal:=pCode,list(eCode..)<!pCode-marker procesu wywo uj cego,eCode-kod zdarzenia> call::=(<callingName>,<calledName>,<tunerName>, entryPoint>,(<parameters,modifiers >),input,output) <\def> <def main> …….<!g ówna procedura przetwarzania danych> </def> <\def> <spec MIS(MÓJ_BANK.POWSZECHNY)<!specyfikacja systemu> Refers to def (MÓJ_BANK) ……..<!opis podsystemów,modu ów, programów systemu dla Banku Powszechnego> </spec> Uwagi ko cowe W stadium obecnym OSL ma zdefiniowan notacj i podstawowe frazy, znajduje si wi c w pozycji startowej. Od startu do mety jest wiele do zrobienia. Niniejsza publikacja ilustruje mo liwo ci j zyka. Praktyczne u ycie j zyka OSL uwarunkowane jest osadzeniem w rodowisku komputerowego wspomagania m.i. poprzez procedur wyszukiwania obiektów, u ycie specjalizowanego edytora (zawieraj cego narz dzia sprawdzania poprawno ci formalnej opisu, podpowiedzi s ów kluczowych i fraz, generowania diagramów, itp.). Wersje opisu poszczególnych obiektów utrzymywane by yby w bibliotece, za specyfikacja ca ci dla g ównego obiektu SUBJECT tworzona by aby automatycznie w wyniku konsolidacji podobiektów sk adowych. ównym przeznaczeniem OSL jest opis obiektów, jednak e znaczenie przysz ciowe mie b dzie bezpo rednie powi zanie opisu z oprogramowaniem aplikacyjnym, a wi c przej cie z poziomu konceptualnego na poziom „praktyczny”. Pewne mo liwo ci w tym kierunku wykazuje podzbiór SSL 2016-10-31 Page 11 of 11 zawieraj cy procedury strojenia modyfikowalnych komponentów. Autor zdaje sobie jednak e spraw z tego, i automatyczne generowanie aplikacji na podstawie specyfikacji pozostaje na razie tylko postulatem, wymaga bowiem posiadania „monta owego” oprogramowania integruj cego i biblioteki „klocków” (building blocks). Warto przy okazji wspomnie , e próby opracowania „fabryki oprogramowania” si gaj lat 70-tych ub. stulecia [10,11], a wi c czasów kiedy nie by o jeszcze podej cia obiektowego. Ale nawet bez tego „luksusu” j zyk OSL mo e by u yty jako jednoznaczne zwi e narz dzie opisowe (konspekt) na ka dym etapie analizy i projektowania. owa kluczowe: OSL, BSL, SSL, HSL, podej cie obiektowo-komponentowe, j zyk specyfikacyjny Bibliografia 1. Ryznar Zygmunt “A conceptual model of an interfunctional data base system”. Information and Management 2/1978 s.67-74 2. Ryznar Zygmunt “S&DL - Structured Design Language”. 526-533. Angewandte Informatik-Applied Informatics 12/1981 s.526-533 3. Ryznar Zygmunt "J zyk opisu problemu COBOL-PDL w metodzie projektowania strukturalnego" Biuletyn MERA 5/77 s.22-33 4. Ryznar Zygmunt "Parametryzacja procedur w j zyku SDL w warunkach strukturalnego projektowania" Biuletyn MERA 7/77 s.32-38 5. Ryznar Zygmunt "S&DL Structured Design Language - J zyk specyfikacyjny do projektowania strukturalnego (zarys propozycji)" Informatyka 2-3 1982 6. Ryznar Zygmunt “Obiektowo-dynamiczne podej cie i jego j zyk specyfikacyjny (próba definicji na przyk adzie bankowo ci)” Informatyka 5/98 s.18-22 7. Johnson Richard A.,Kast Fremont E.,Rosenzweig James E. „The Theory and Management of Systems” New York, McGraw-Hill Inc., 1967 8. Forrester Jay W. „Industrial Dynamics” New York - London, Massachusetts Institute of Technology and John Wiley and Sons Inc., 1961 9. Hall Calvin S., Lindzey Gardner „Theories of Personality”, New York, John Wiley and Sons Inc., 1978 10. DeJong S.P. „The System Building System (SBS)”, IBM Research Div., N.Y. 1973 11. Bratman H. „The software factory”, Computer 8, 1975 s.28-37 12. Ryznar Zygmunt „Human Specification Languge” http://members.upcpoczta.pl/z.ryznar3/ipedia/HSL.pdf 2016-10-31