Summary: long transaction (Software AG, 1999) 1
Do we need the intermediate design stage? Why not just XP or RAD in an Agile way? One-of-a-kind project or multiple similar products/projects? Ready made, tested templates and components Multiple interconnections Technical conformity ICT stdsetc Functional conformity I/O, sequence of processes, delays/lead times Procedural conformity Abstraction Quality stds and procedures, information sharing and disclosure 2
The Antropomorphic Question? In the context of using components: Should I name the components as used or as part of design? What is the difference, then, between: Architecture? Process? Service? Pattern? Component? Probably, the processes are the ones to be described from different view points Probably, a joint subset of processes can be created as service components Probably, the architecture should be a superset of all potential processes using architecture 3
MDA (Oya, 2002) 4
MDA (c.f. Oya, 2002) 5
An example (Oya, 2002) 6
An example (Oya, 2002) 7
An example (Oya, 2002) 8
An example (Oya, 2002) 9
MDA (Oya, 2002) 10
MDA (Oya, 2002) 11
MDA (Oya, 2002) 12
MDA (Oya, 2002) 13
MDA (Oya, 2002) 14
DSM: What is domain-specific modelling (based on Tolvanen, 2003) Captures domain knowledge (as opposed to code) Uses domain abstractions Applies domain concepts and rules as modeling constructs Allows developers to design products with domain terms Apply familiar terminology Solve the RIGHT problems! Solve problems only ONCE! It provides one way of avoiding the complexity and antropomorhism trap by automating the patterns (e.g. code generation from description) 15
Example (Tolvanen, 2003): JustInsurances.com Domain Idea Solve problem in domain terms Map to code, implement Map to code, implement Map to UML Damage! Risk factor! Liability! Bonus! Generate, Add bodies UML Model Use case Activity Stereotype Class Attribute Java Assembler inner class? Session Bean? static final? integer? Finished Product 16
DSM vs. MDA (Iseger, 2005) 17
Modelling Asynchronous Processes Asynchronous = must be controlled and coordinated at some point! Try Petri nets with production rules 18
Use Cases: Utilizing the structure Tähän päähän n tullee segmentoinnin seurauksena hienosyisempiä asiakasryhmiä -eli enemmän Use-caseja Transfer between accounts Deposit Entity Boundary Control 19
Use Case: Collaboration diagram (Booch et al., 1998) 20
Use-caseista analyysiin Asiakkaan kieli Ulkoinen, hyödyntävä Use-cases Käyttäjän ja kehittäjän välinen sopimus, mitä järjestelmä tekee ja mitä ei Redundantti ja inkonsistentti Suunnittelijan kieli Sisäinen, konstruoiva Olioluokat, komponentit Ymmärryksen luominen Konsistentti Rakenteen ja toiminnan yhdistäminen Use-case toteutuksin 21
Sama lentovarauksesta 1/2 (Daum & Scheller, 2000) 22
Sama lentovarauksesta 2/2 (Daum & Scheller, 2000) 23
Asynkroniset samanaikaiset prosessit (Zisman, 1978) Kontrollirakenteen tarve koordinaatiota varten: esimerkkinä tieteellisen artikkelin referointi toimijat/roolit: päätoimittaja, toimittaja, arvioija, kirjoittaja, sihteeri (sihteeri kontrolloi :-) use case -ongelma: liian monia vaiheita ja alisysteemejä? Peruskäsitteet: Solmu (node): paikka (place: O) tai siirtymä (transition: ) Paikoissa tokenit (token: ) Paikka voi olla syötepaikka (input p.) tai tulospaikka (output p.) Jos kaikissa syötepaikoissa on token, siirtymä on aktiivinen Aktiivinen siirtymä voi kytkeä (fire) Kytkeytyminen siirtää syötepaikkojen tokenit tulospaikkoihin yksi token voi kytkeä vain yhden siirtymän 24
Asynkroniset samanaikaiset prosessit: esim. Systeemin tilat, sihteeri koordinaattorina: 1) odottaa artikkelin saapumista ack kirjoittajalle, toimittajalle pyyntö arvioijista 2) odottaa toimittajan nimittävän arvioijat +2vko; muistuta. Lähetä suostumuspyynnöt arvioijille 3) odottaa arvioijan suostumusta +2vko; muistuta. Lähetä artikkeli tai pyydä uutta arvioijaa 4) odottaa arvioijan raporttia +1kk; muistuta. Ack toimittajalle yksittäisestä raportista 5) odottaa kaikkien raporttien saapumista Lähetä toimittajalle ja pyydä päätös 6) odottaa toimittajan päätöstä +2vko; muistuta. Ack kirjoittajaa ja päätoimittajaa päätöksestä 25
Esim. jatkuu: Kaksi alisysteemiä - toimittaja T1 T2 T3 T4 Toimintojen verkko T6 T5 T7 T7: - - => - - Tuotantosäännöt T1: Artikkeli saapuu => ack kirjoittajalle, toimittajalta arvioijat T2: Arvioijalista => käynnistä arviointiprosessi (T8) T3: Kaikki arvioijaraportit => pyydä toimittajan päätös T4: Toimittajan päätös => dokumentit kirjoittajalle, päätoim. T5: Kirjoittaja vetäytyy => lopetusdokumentointi T6: +2vko => muistuta toimittajaa 26
T15 T14 T13 Esim. jatkuu: Kaksi alisysteemiä: arvioija T8 T9 T10 T12 T11 T8: Käynnistyy arviojien nimityksen jälkeen => arv.pyyntö 2vkoa T9: Arvioijan suostumus => 1kk aikaa T10: Arviointiraportti saapuu => kiitä arvioinnista T11: +1kk => muistuta arvioijaa T12: +2vkoa => kysy uudelleen T13: Arvioija ei suostu => pyydä toimittajalta toinen arvioija T14: +2vko => muistuta toimittajaa uudesta arvioijasta T15: Toimittajalta uusi arvioija => arv.pyyntö 2vkoa 27