NOTACJA JĘZYKA OSL

<! komentarz>

<! w nawiasach ostrych <> podawane są tylko głowne frazy strukturalne: def, spec oraz komentarze, nazwy obiektów i predefiniowane słowa kluczowe pisane są dużymi literami, obiekty niebiznesowe pisane są małymi literami>

<def nazwa obiektu> <!początek definicji obiektu>

</def> <!koniec definicji obiektu>

<spec nazwa specyfikacji> <!początek specyfikacji>

</spec > <!koniec specyfikacji>

::= <!przypisanie typu (np. klasy, obiektu) >

:= <!przypisanie do listy>

= <!przypisanie wartości czyli podstawienie >

: <!przypisanie obiektowi atrybutu>

:: <!przynależność>

= = <!ekwiwalentność>

{.....} <!ograniczniki frazy specyfikacyjnej>

(x,y,..) <!lista>

YYYYYY.UUUUU(XXXXXX) <!kwalifikowana nazwa obiektu >

[name] <!obiekt wykonawczo-operacyjny>

(XXXX)<!obiekt podstawowy>

keywords <!kluczowe słowa specyfikacyjne, są dziedziczone przez obiekty niższego rzędu>

Można założyć hipotetycznie, iż w przypadku komputerowej implementacji języka, pisanie specyfikacji byłoby wspomagane przez specjalizowany edytor (m.i. poprzez gotowe "formatki" ze zwrotami), generacje opisu poszczególnych obiektów byłyby utrzymywane w bibliotece specyfikacji, zaś specyfikacja całości tworzona będzie automatycznie w wyniku konsolidacji zmian.

Język OSL (Object Specification Language) składa się ze zwrotów standardowych, niezależnych od rodzaju biznesu, służących do definiowania obiektów oraz słów kluczowych specyfikowanych do używania w lokalnym obszarze (AREA) lub globalnie w ramach tzw. świata (UNIVERSE). Opis dokonywany jest w imieniu głównego podmiotu (SUBJECT). UNIVERSE, AREA i SUBJECT są więc jakby superklasami. Klasy w ramach AREA mogą być definiowane swobodnie (user-defined} zgodnie z potrzebami głównego podmiotu. W OSL wyróżnia się również tzw. obiekty wykonawczo-operacyjne, którymi są pracownicy podmiotu obsługujący klasy (np. lekarz naczelny,, lekarz chorego, itp.) oraz infrastruktura techniczna (w tym serwery, bazy danych itp.) i organizacyjna.

Środowisko (ENV) w jakim działa aplikacja opisywane jest następująco:

ENV:=(REGULATIONS, INFRASTRUCTURE)

ENV.REGULATIONS:=(Akty prawne, regulaminy, zarządzenia)

ENV.INFRASTRUCTURE:=( ServeryDanych, SystemyOperacyjne, Transakcyjne BazyDanych, HurtownieDanych , SystemZarządzaniaSiecią, Struktura organizacyjna firmy)

Specyfikacja obiektu obejmuje takie elementy jak:

-id <!identyfikator obiektu>

-infoWindow <!"okno na świat " - informacje uzewnętrzniane przez obiekt>

-dataTable <!tablica danych.>

-typ obiektu ObjectTypes : (eOBJECT<!obiekt elementarny np. klient>

-rola obiektu (ROLE)

-historia życia ( OLH -Object Life History )

-relacje (RELATIONS)

-charakterystyka dynamiki(poprzez procesy, transakcje, zdarzenia; sposób ich inicjowania itp.)

-tryb wykonania (EXECUTION_MODE:= modeRT <!real time>,modeBAT<!batch> modeOND <!on demand>)

-przepływ danych (DATA_FLOW)

-przepływ sterowania (CONTROL_FLOW)

Poniżej wymienimy niektóre elementy (szczególnie te, których nie udało się użyć w przykładzie).

ROLE :=(commander <! obiekt sterujący procesem, odpowiedzialny>,

trigger <!obiekt inicjujący/uruchamiający proces, zdarzenie>,

generator <!obiekt generujący np. zdarzenia, cash flow>,

agent <!reprezentuje usługę np. agent w call-center >,

integrator <!obiekt integrujący obiekty>

monitor <!śledzi wykonanie/przebieg procesu>,

executor <! obiektwykonawczy>,

participator <!obiekt uczestniczący>,

stakeholder :=(owner, stockholder, customer, supplier; partner, employee)

component <!składnik>

performance center <!obiekt będący miejscem wykonania> )

RELATIONS:=((activated by / activates, activated when/if,

appearence depends on <! np.pojawienie się dziecka zależy od istnienia rodziców>

assisted by, belongs to /is owned by , built from ,

calls <obiekt> (xxx,yyy) <!xxx elementy przekazywane., yyy elementy zwracane>

consists of <parts> , contained in/contains, controlled by / controls,derived from,

driven by OPERATION,driven by product ,driven by banking regulations,

driven by customer, driven by date, driven by schedule,driven by frequency

existence depends on <!np. istnienie obiektu zależy od .... >

exists when/in/for, evaluated as critical/most wanted , included in ,

linked to ...by / links, matched/matches <! np. uzgodnić operacje>

refers to <!bezpośrednie odniesienie> relates to, related by affinity, represented by /

represents , involved in, shared by / shares, used by / uses)

STATE := (active,inactive,dormant,suspended,aborted,idle, lost)

STATUS := (generic, real, virtual)

dOBJECT<! obiekt dynamiczny np. operacja>

iOBJECT<!obiekt informacyjny np. informacje o chorym>

vOBJECT<! obiekt wirtualny np. symulacja rozwoju choroby>.

dOBJECT ::= ZDARZENIE,OPERACJA,AKCJA,PROCES)

== (EVENT,OPERATION,ACTION,PROCESS) <!przykład równoważnego definiowania dwujęzycznego>

<!ZDARZENIE jest to elementarny niepodzielny fakt, czyn, działanie lub zaniechanie spodziewanego działania >

<!OPERACJA jest to sekwencja zdarzeń >

<!AKCJA jest to złożone działanie , składajace się z kilku operacji>

<!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 ) >

{CONTROL_FLOW

repetition :=( iteration, single spiral, multiband spiral <!spirala znajduje zastosowanie w procesie uczącym się i od iteracji różni się tym, iż każdy jej zwój posiada inne mechanizmy i treść >)

activated .... BY ...with <initial-value> AT <time-point > WHEN ..

finished AT < > with <value> WHEN ...}

{ DATA FLOW

<.> from (<.>) <!lista danych przychodzących od...>

<.> to (<.>) <!lista danych wysyłanych do>

<> dataGeneration Method <nazwa>

<>dataEncoding Method <nazwa>

<>dataCompressing Method <nazwa>

}

{BODY ::= ( Contents, Script, Metadata)

contents <!zawartość ciała np. treść dokumentu, kod programu>

script <!lista operacji generowanych wewnątrz obiektu odpowiednio do jego zachowania się np. oczekiwanie na dostęp do danych, zawieszenie się>

metadata <! np. w XML- opis struktury ciała obiektu >}