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

Podobne dokumenty