Prosessit mallinnetaan hallinnon, atk-keskuksen ja eri tiedekuntien näkökulmista
Prosessimalleista
Davenport, Sharp & McDermott ym. "Business process is a specfic ordering of work activities across time and place with a beginning and an end containing inputs and outputs. Business processes typically span multiple organizations both within and between enterprises."
Käytännössä prosessimallin tarkkuus ja esitystapa voi vaihdella suuresti
esim. visiolla tai vastaavalla piirto-ohjelmalla tehty vuokaavio tai "uimaratakaavio"
jotta prosessikuvaus olisi tehokkaasti analysoitavissa ja haettavissa, esityksen täytyy perustua yhtenäiseen tietomalliin
piirto-ohjelma ei käy (esim. visiolla piirrettyjen kaavioiden ylläpitäminen, jos jokin roolinimike muuttuu)
esim. QPR on mallipohjainen prosessikuvausohjelma
jotta prosessi olisi automatisoitavissa (=ajettavissa workflow enginellä tai muulla "process aware"-softalla), tarvitaan lähellä ohjelmointikielen tasoa olevaa kuvausta
BPEL (BPML-kaaviot)
ilmaisuvoiman kasvaessa myös kielen (ja mallinnuksen!) monimutkaisuus kasvaa
Graafinen käyttöliittymä tulossa, mutta teksipohjaisessa mallinnuksessa on myös etunsa
Pakottaa mallinnusvaiheessa keskittymään asiaan, ei tarvitse sohia hiirellä laatikoiden asettelua =)
Lukurajapinta Visiosta ja Excelistä toteutettu, QPR:ään työn alla
Dokumenttien ja tietojärjestelmien merkkaamisesta
Kontrollivirran "ohessa" kulkevat dokumentit merkitään aktiviteettien "väliin": aktiviteetti1 -> dokumentti -> aktiviteetti2. Tällöin voidaan päätellä, että dokumentti liittyy kumpaankin aktiviteettiin (ja rooliin)
Vain tietovirtojen päissä olevat dokumentit merkitään sen roolin uimaradalle, jolle dokumentti tulee/lähtee ja yhdistetään tietovirralla aktiviteettiin, josta dokumentti on lähtöisin/menossa
Huonona puolena oman graafisen käyttöliittymän puute. Prosessien mallinnus edellyttää koulutusta.
Oliomalli
Yleisluontoinen kuvaus vs. liian tarkka: liian tarkka kuvaus on työlästä ja kokonaisuus hämärtyy. toisaalta yleisluontoisessa kehittämismahdollisuuksien havaitseminen vaikeutuu.
Prosessi voidaan pilkkoa aliprosesseihin
ProcessManagerissa lisäksi abstraktiotasot, joiden avulla prosessi voidaan "pilkkoa" eri kerroksiin. Lisäksi rooleja voidaan kuvata organisaatio- ja virkanimiketasolla
Prosesseista pitäisi erottua "päälinja", joka kuvaa tavallisimman tai ihanteellisen prosessin kulun. Tämän jälkeen prosessia voidaan täydentää poikkeuksilla, dokumenteilla, tietovirroilla ym.
Vaatimuksia
Puoliformaalit, ymmärrettävät prosessit
Huom. ajettavuus ei vaatimuksena
Siirrettävys
Visio, Excel, QPR...
Ylläpidettävyys
Prosessien muokkaus pitää tehdä niin helpoksi, että ne pysyvät ajan tasalla
Mallitietokannassa globaalit tiedot - rooli- ja dokumenttipuut sekä tietojärjestelmälistat
Sisäisesti yksi prosessi on monitasoinen graafi, jossa alemman tason solmut voivat syrjäyttää ylemmän tason solmuja. Mistä tahansa solmusta voidaan myös viitata toiseen prosessiin (aliprosessi). Lisäksi prosessi voidaan "periä" toisesta prosessista.
Ylärakenne sisältää prosessien väliset linkit ja prosesseihin liittyvät yleiset metatiedot
Oliomalli on sisäisesti hajautustaulu, jossa mihin tahansa elementtiin voidaan viitata tekstitunnisteella
Mahdollistaa helpon siirron relaatiokantaan mallin kasvaessa
Tällä hetkellä käytössä yksinkertainen Java-serialisointi tiedostoon
ProcML-kieli
Suurin haaste: miten kuvata monitasoista graafia tekstimuodossa intuitiivisesti?
XML-työkalut (infopath) soveltuvat parhaiten tilanteeseen, jossa täytetään metatietokenttiä, mutta eivät yleensä ymmärrä eri kenttien (=solmujen) välisiä suhteita
Työkalutuen osalta tyydyttävä tekstipohjaiseen XML-editoriin (Esim. XML Spy, Eclipse, NetBeans)
Lisäongelmana ID-koodit - XML:n standardikäytäntö liian kankea procml:n tarpeisiin
XML-tiedostot luetaan ja serialisoidaan työasemalla, prosessiportaalissa sovelma lukee serialisoidun tiedon ja php-sivut kutsuvat makea niiden prosessien osalta, joille sivu tai hakutulos on generoitava uudelleen
Yhdistelmä "ajaxia", sovelmia ja staattisia sivuja
Prosessiportaalissa prosessien haku roolien, dokumenttien tai tietojärjestelmien mukaan
Auttaa löytämään prosessien ja henkilöresurssien "hot spotit"
propertyt (sekä yksinkertaiset metatietokentät että olioiden väliset suhteet), get/set-logiikat sekä muuntimet tekstistä binaarimuotoon ovat olioita
ei erillisiä get-set-metodeja
// propertymäärityksiä ProcessInstance-luokasta
public static final PropertyEnv<RefProperty,Process> PROCESSCLASS_e = new PropertyEnv("processClass"); public final RefProperty<Process> PROCESSCLASS = new RefProperty(PROCESSCLASS_e,Process.class);
public static final PropertyEnv<RefProperty,OrganizationItem> IMPLEMENTOR_e = new PropertyEnv("implementor","implementor","Toteuttajaorganisaatio"); public final RefProperty<OrganizationItem> IMPLEMENTOR = new RefProperty(IMPLEMENTOR_e,OrganizationItem.class);
public static final PropertyEnv<StringProperty,String> EXCEPTIONS_e = new PropertyEnv("exceptions","exception","Poikkeukset"); public final StringProperty EXCEPTIONS = new StringProperty(EXCEPTIONS_e);
// Esim. prosessin toteuttajaorganisaation haku ProcessInstance p; OrganizationItem o = p.IMPLEMENTOR.get()
tällä hetkellä java-serialisointi ja yksinkertainen peräkkäishaku
tuotantokäytössä pitäisi olla relaatiokanta, johon yhteys esim. hibernatella
kyselyt ja kyselyfiltterit ovat olioita
// kyselymäärityksiä ProcessInstance-luokasta
public transient SmartQuery<ProcessInstance> SEARCH_INCLUDING_PROCESSES = new BasicQuery(ProcessInstance.class,new ReferenceFilter(ProcessInstance.INCLUDED_PROCESSINSTANCE_e));
public transient SmartQuery<StepActivity> SEARCH_PARENT_STEPS = new BasicQuery(StepActivity.class,new ReferenceFilter(StepActivity.SUBPROCESS_e));
public transient ParametrizedQuery<ElementOrganizationItem,Integer> SWIMLANES_BY_ABSTRACTION_LEVEL = new OuterCompositeQuery (this.SEARCH_SWIMLANES, this.STEPS_BY_ABSTRACTION_LEVEL, new InverseRefFilter(Step.SWIMLANE_e));
// Esim. prosessiin viittaavien askelten haku ProcessInstance p; Set<StepActivity> sa = p.SEARCH_PARENT_STEPS.search();
InputAbstraction ja OutputAbstraction
helpottaa tiedostopohjaista käsittelyä - käyttäjän ei tarvitse luoda jatkuvasti stream - reader/writer -wrappereita
toisaalta abstractionia tukevien luokkien ei tarvitse toteuttaa julkisesti erillisiä metodeja tiedostoa-, streamia tai reader/writeria varten