Bir Yazılım Sisteminin Kullanımının S¨
ure¸
c
Madencili˘
gi Teknikleri ile Modellenmesi:
End¨
ustriyel Bir Vaka C
¸ alı¸
sması
¨
Umit ¨Ulkem Yıldırım, Beytullah Sarıca, Ethem Utku Akta¸s, and Mehmet C¸ a˘grı C¸ alpur
Softtech A.S¸., Arge Merkezi, 34947 ˙Istanbul, T¨urkiye
{umit.yildirim,beytullah.sarica,utku.aktas,cagri.calpur}@softtech.com.tr
¨
Ozet. S¨ure¸c madencili˘gi, g¨un¨um¨uz bilgi sistemlerinde yaygın olarak tu-tulan i¸slem g¨unl¨ukleri (log) kullanılarak, s¨ure¸clere ait bilginin otomatik olarak ortaya konulmasıdır. Bu yolla mevcut s¨ure¸c modelleri ke¸sfedilebildi-˘
gi gibi, s¨ure¸clerin izlenmesi ve iyile¸stirilmesi de sa˘glanmaktadır. Ek olarak, bir yazılım sistemine ili¸skin s¨ure¸clerin modeli, sistemde d¨uzenli olarak yapılan iyile¸stirmeler ve de˘gi¸siklikler nedeniyle, s¨urekli olarak de˘ gi¸smekte-dir. Dolayısıyla var olan yapının otomatik olarak ortaya konulabilmesi, sistem analistleri, mimarları ve y¨oneticileri i¸cin ¸cok de˘gerlidir. Bu ¸calı¸sma ile bankacılık alanında ticari kredi ba¸svuru yazılımı ile ilgili bir yazılım sisteminin s¨ure¸c modelini sistem log verilerini kullanarak otomatik olarak ¸
cıkarmayı hedefledik. Bu ama¸cla, end¨ustriyel vakaya ait 800.000 adet web servis ¸ca˘grısından elde edilen log verisini kullandık. ¨Oncelikle, bu servis loglarını kullanarak, s¨ure¸cleri ve aralarındaki ge¸ci¸sleri ortaya koyduk. Or-taya ¸cıkan ¸cıktı ile, yazılım uygulamasına ait s¨ure¸c modelini elde ettik. Sonu¸c olarak, servis loglarından otomatik olarak s¨ure¸c modellerinin elde edilmesini, yazılım sistem analistlerine, mimarlara ve di˘ger y¨oneticilere, s¨ure¸clerin izlenmesi ve iyile¸stirilmesi konusunda etkili bir yardımcı teknik olarak de˘gerlendiriyoruz.
Anahtar Kelimeler: Log Analizi, S¨ure¸c Madencili˘gi, Servis Sistemleri, Yazılım Modelleme.
Modelling the Use of a Software System with
Process Mining Techniques: An Industrial Case
Study
¨
Umit ¨Ulkem Yıldırım, Beytullah Sarıca, Ethem Utku Akta¸s, and Mehmet C¸ a˘grı C¸ alpur
Softtech Inc., Research and Development Center, 34947 Istanbul, Turkey {umit.yildirim,beytullah.sarica,utku.aktas,cagri.calpur}@softtech.com.tr
Abstract. Process mining is the automatic extraction of knowledge re-lated to processes by using system logs which are commonly available in information systems. As well as discovering the current process models, they can also be used to monitor and improve the processes. In addi-tion, the model of a software system may become very different from the initial, because of continuous improvements and changes in the sys-tem. Therefore, it is very valuable for system analysts, architects and managers to be able to reveal the existing structure automatically. In this study, we aim to automatically extract the process model of a soft-ware system related to commercial credit application softsoft-ware in banking domain, using system log data. For this purpose, we collected 800,000 web-service logs in our industrial case. Using these logs of web-services, we first extracted the processes and the transitions between them. Using this data, we obtained the process model of the application. As a result, we consider that automatically obtaining the process models from web-service logs is an effective auxiliary technique for the software system analysts, architects and other managers to monitor and improve their processes.
Keywords: Log Analysis, Process Mining, Service Systems, Software Modelling.
1
Giri¸
s
Yazılım sistemlerinde yapılan i¸slemler i¸cin i¸slem g¨unl¨ukleri (log) tutulmakta, bu g¨unl¨uklerle i¸slemlerin akı¸sı takip edilmekte veya hata alınması durumunda hata analizi yapılarak sorunlara hızlı bir ¸sekilde m¨udahale edilebilmektedir. Bu g¨unl¨ukler olduk¸ca de˘gerli veri i¸cermektedir, bir servise ait girdiler ve ¸cıktıların i¸ceri˘gi, i¸slemin ne zaman yapıldı˘gı, ne kadar s¨urd¨u˘g¨u ve hata alınması durumunda hata ile ilgili detay bilgilere i¸slem g¨unl¨uklerinden ula¸sılabilmektedir. B¨uy¨uk sis-temlerde her g¨un milyonlarca i¸slem g¨unl¨u˘g¨u kaydı olu¸sturulabilmekte ve olu¸san bu veri, sistemin sa˘glı˘gı, s¨ure¸c akı¸sları, sistemin modellenmesi gibi ¸ce¸sitli konu-larda otomatik olarak ¸cıkarım yapma olana˘gı sunmaktadır.
S¨ure¸c madencili˘gi, i¸slem g¨unl¨uklerinden s¨ure¸clerle ilgili bilgilerin ortaya konul-masıdır. G¨un¨um¨uzde, s¨ure¸c madencili˘gi teknikleri kullanılarak ¸ce¸sitli uygulama alanlarındaki s¨ure¸cleri ke¸sfetmek, g¨ozlemlemek ve geli¸stirmek m¨umk¨und¨ur, bu sayede yeni ara¸cların ortaya ¸cıkması sa˘glanır. ˙I¸slem g¨unl¨ukleri i¸cin ke¸sif (dis-covery), uygunluk (conformance) ve iyile¸stirme (enhancement) teknikleri kul-lanılarak s¨ure¸c madencili˘gi yapılabilir (S¸ekil 1). Ke¸sif tekni˘gi herhangi ba¸ska bir bilgiye bakılmadan, i¸slem g¨unl¨uklerini kullanarak bir model ¨uretilmesidir. Uygunluk tekni˘ginde, mevcut bir s¨ure¸c modeli aynı i¸slemin olay g¨unl¨u˘g¨uyle kar¸sıla¸stırılır. ˙Iyile¸stirme tekni˘ginde ise olay g¨unl¨uklerine kaydedilen asıl i¸slemler hakkındaki bilgiler kullanılarak mevcut bir i¸slem modeli geni¸sletilir veya iy-ile¸stirilir [1].
S¸ekil 1. S¨ure¸c madencili˘ginin ¨u¸c ana bile¸seni: ke¸sif, uygunluk ve iyile¸stirme
S¨ure¸c madencili˘gi teknikleri kullanılarak farklı alanlarda yapılan ¸calı¸smalar mevcuttur. Van der Aalst ve arkada¸sları tarafından yapılan ¸calı¸smada [2], s¨ure¸c madencili˘gi teknikleri kullanılarak, ta¸seronlar ve tedarik¸ciler tarafından g¨onderilen faturaların i¸slenmesi ¨u¸c farklı bakı¸s a¸cısıyla analiz edilmi¸stir: (1) s¨ure¸c perspek-tifi, (2) organizasyonel bakı¸s a¸cısı ve (3) vaka perspektifi. Bu ama¸cla, s¨ure¸c madencili˘ginde yaygın olarak kullanılan ProM uygulaması ile, genel olarak s¨ure¸c madencili˘ginin kendi vakalarındaki uygulanabilirli˘gini ve kullandıkları algoritma ve ara¸cları ortaya koymu¸slardır.
Poncin ve arkada¸sları tarafından yapılan di˘ger bir ¸calı¸smada [3], s¨ur¨um kon-trol sistemleri, yazılım hata kaydı sistemleri gibi yazılım depolarında tutulan veriler kullanılarak s¨ure¸c madencili˘gi tekniklerinin yazılım geli¸stirici faaliyetleri ¨
uzerine uygulanması ¨onerilmi¸stir. S¨ure¸c madencili˘ginin uygulanabilir olması i¸cin, farklı depoları e¸szamanlı olarak analiz etme ve elde edilen bilgileri birle¸stirme gibi zorunluluklar ortaya ¸cıkmı¸stır. C¸ alı¸sma ile ¸ce¸sitli vakalara ait yazılım hata kaydı ya¸sam d¨ong¨us¨u ortaya konulmu¸stur.
Gadler ve arkada¸sları tarafından yapılan ¸calı¸smada [4], bir yazılım sistemiyle etkile¸sime giren kullanıcıların i¸slemlerini g¨osteren s¨ure¸c modellerinin otomatik olarak nasıl olu¸sturulabilece˘gi incelenmi¸stir. Bu ama¸cla Saklı Markov modeli kullanılarak ba¸sarılı bir ¸sekilde s¨ure¸c modeli ortaya konmu¸stur.
C¸ alı¸smamızda se¸cilen bankacılık uygulaması ile ilgili ekranlardan yapılan her i¸slemde, arka planda ¸ca˘grılan servislere ait i¸slem g¨unl¨ukleri kullanılarak s¨ure¸c akı¸sının otomatik olarak ¸cıkarılması hedeflenmi¸stir. Bildirinin organizasyonu ¸su ¸sekildedir: B¨ol¨um 2’de End¨ustriyel vaka ve problem tanımı anlatılmı¸s, B¨ol¨um 3’te y¨ontem sunulmu¸s, B¨ol¨um 4’te ¸calı¸sma sonu¸cları de˘gerlendirilmi¸s, son olarak B¨ol¨um 5’te ¸calı¸sma ¨ozetlenmi¸s ve planlanan gelecek ¸calı¸smalar belirtilmi¸stir.
2
End¨
ustriyel Vaka ve Problem Tanımı
˙Ilgilendi˘gimiz s¨ure¸c bankacılıkta ticari kredi ba¸svurularının yapıldı˘gı ekran ve uygulamaları i¸cermektedir. Ticari kredi ba¸svurusunda bulunan m¨u¸steriler ¸sube tarafından de˘gerlendirildikten sonra uygun ¨ur¨un, limit, vade ve di˘ger ¨ozellikler se¸cilerek ekranlardan giri¸sleri yapılmaktadır. Girilen kriterlere g¨ore m¨u¸steriye bir fiyat verilmekte ve verilen fiyata g¨ore ¨odeme planı olu¸sturularak ve m¨u¸steri onayı alınarak ba¸svurusu alınmaktadır. Ba¸svuru bundan sonra tahsis mod¨ul¨une iletil-erek kredi verilip verilmeyece˘gi karar motoru vasıtasıyla sonu¸clandırılmaktadır. ˙Ilgilendi˘gimiz s¨ure¸c tahsis mod¨ul¨une iletilene kadar olan ba¸svuru s¨urecini i¸cermek-tedir.
G¨unde toplam olarak yakla¸sık 3,000 adet ba¸svuru alınmakta, ¸sube ¸ calı¸sanların-ca birbirini takip eden 3 farklı ekrandan giri¸sler yapılmaktadır. Uygulama ¸co˘ gun-lukla 09:00-17:00 saatleri arasında kullanılmakta ve bu saatler arasında ayakta olması beklenmektedir. Sistem, Windows sunucuları ¨uzerinde ¸calı¸san .net wcf (windows communication framework) uygulamalarından olu¸smaktadır.
2.1 Problem Tanımı
Sistemde yazılımsal bir sorun olu¸sması durumunda m¨u¸steri ¸sikayetine neden ol-unmaması adına ¸cok kısa s¨urelerde sorunun tespit edilmesi ve ¸c¨oz¨umlenmesi beklenmektedir. Soruna neden olan servisin hızlı bir ¸sekilde tespit edilebilmesi i¸cin g¨uncel s¨ure¸c akı¸sının ortaya konulmu¸s olması gerekmektedir. Ancak yazılım g¨uncellemeleri ve yeni s¨ure¸cler eklenmesi ile sistem s¨urekli bir ¸sekilde de˘gi¸smekte ve daha ¨once ortaya konulmu¸s olan statik modeller kısa s¨urede g¨uncelli˘gini yi-tirebilmektedir. Bu ¸calı¸smadaki amacımız log verisini kullanarak otomatik olarak s¨ure¸c modelini ortaya koyabilmektir.
3
Y¨
ontem
Bu b¨ol¨umde i¸slem g¨unl¨u˘g¨u verisi kullanılarak sistemi modellemek i¸cin ortaya koydu˘gumuz y¨ontem anlatılmaktadır. Y¨ontemimiz ile ilgili genel yakla¸sım S¸ekil 2’de verilmi¸s olup detayları devam eden alt b¨ol¨umlerde verilmi¸stir.
Ticari kredi ba¸svuru sistemi aray¨uz¨u ile ger¸cekle¸stirilen aksiyonların her-biri i¸slem olarak tanımlanmı¸stır. Verilerin elde edildi˘gi Ticari kredi ba¸svuru sisteminde tanımlanmı¸s olan i¸s akı¸sını tanımlayan g¨orevlere s¨ure¸c denmekte-dir. S¨ure¸clerin ger¸cekle¸stirilmesi i¸cin ko¸sulan kod par¸caları web servisi olarak tanımlanabilir. Bir s¨ureci olu¸sturan birbiri ile ili¸skili olan ve arka arkaya ko¸sturulan web servislerine ise blok denmektedir.
Başla Müşteri ve Çağrım zamanına göre log verisini sırala Aynı müşteri için arka arkaya çağrılan servislerden blokları çıkar Benzer blokları aynı numara ile tekrar numaralandır Aynı müşteri için bir bloktan sonra gelen bloğu tespit et Bitir Blok özet verisinioluştur
S¸ekil 2. Log verisinden i¸slem bloklarının otomatik olarak ¸cıkarılmasına dair y¨ontemin ¨
ozet akı¸sı.
3.1 ˙I¸slem G¨unl¨u˘g¨u Kayıtlarının Olu¸sturulması
Web servisleri ¸ca˘grıldı˘gında her bir servis ilgili veritabanına, ¸ca˘grılma zamanı, servis adı, cevap verme s¨uresi, servisin girdi ve ¸cıktı alanlarını i¸ceren i¸slem g¨unl¨u˘g¨u kaydını olu¸sturmaktadır. Servisin girdi ve ¸cıktısındaki bilgiler kullanılarak ilgili ¸ca˘grıda ge¸cen m¨u¸steri numarası, ¸ca˘grı sonucunda i¸s hatası veya sistem hatası alınıp alınmadı˘gı hazırlanan program ile otomatik ¸cıkarılmı¸stır. Verita-banında her bir servis ¸ca˘grımında tutulan kayıtlara ait bilgiler Tablo 1’de ver-ilmi¸stir.
Tablo 1. ˙I¸slem g¨unl¨u˘g¨u tablosunda tutulan bilgiler. Alan adı Alanın a¸cıklaması
M¨u¸steri numarası Servisin hangi m¨u¸steri i¸cin ¸ca˘grıldı˘gı C¸ a˘grım zamanı Servis ¸ca˘grısı ba¸slangı¸c anı
Yanıt s¨uresi Milisaniye cinsinden servisin yanıt verme s¨uresi C¸ a˘grılan servisin adı Sistemde tanımlı olan servis adı
˙I¸s hatası Servis ¸ca˘grısı sonucunda i¸s hatası alınıp alınmadı˘gı Sistem hatası Servis ¸ca˘grısı sonucunda sistem hatası alınıp alınmadı˘gı
3.2 ˙I¸slem Bloklarının C¸ ıkarılması
Kullanıcılar ekrandan tek bir i¸slem yaptıklarında arka tarafta birden ¸cok servis ¸ca˘grılabilmektedir. Ekrandan yapılan tek bir i¸slemde arka arkaya ¸ca˘grılan servisler aynı i¸slem blo˘gu i¸cinde de˘gerlendirilmi¸stir. Bir m¨u¸steri i¸cin yapılan bir i¸sleme ait servis ¸ca˘grılarını ¸cıkarabilmek i¸cin ¨oncelikle i¸slem g¨unl¨u˘g¨u kayıtları m¨u¸steri nu-marası ve ¸ca˘grım zamanına g¨ore sıralı bir ¸sekilde olu¸sturulmu¸stur.
Servislerin arka arkaya ¸ca˘grıldı˘gı sonucuna ula¸sabilmek i¸cin, o m¨u¸steri i¸cin ¸ca˘grım zamanı ve yanıt s¨uresi alanındaki veri kullanılmı¸stır. Bir m¨u¸steri i¸cin bir servis ¸ca˘grıldıktan ve yanıt alındıktan sonra aynı m¨u¸steri i¸cin 1 saniye i¸cinde sıradaki servis ¸ca˘grılmı¸ssa aynı i¸slem blo˘gu i¸cinde de˘gerlendirilmi¸stir.
3.3 Benzer ˙I¸slem Bloklarının Tespiti
˙I¸slem blokları ¸cıkarıldıktan sonra benzer bloklar tespit edilmi¸stir. Ekrandan aynı i¸slem farklı m¨u¸steriler i¸cin yapıldı˘gında arka tarafta ¸ca˘grılan servisler birebir aynı olmayabilmektedir. Bunun birinci sebebi servis ¸ca˘grım ¸cıktıları ¨on belle˘ge (cache) alınabilmekte, ¨on belle˘ge alınan veri ekrandaki ilgili i¸slem tekrar yapıldı˘gında, ¨
on bellek s¨uresince kullanılabilir durumdaysa servis ¸ca˘grımlarından ilgili olanlar yapılmamaktadır. ˙Ikinci nedense, birbirinin ¸cıktılarını kullanmayan servisler ola-bildi˘gi i¸cin servislerin ¸ca˘grımları asenkron yapılabilmektedir, dolayısıyla sıralama da de˘gi¸sebilmektedir.
Bu nedenlerden dolayı, iki blokta ¸ca˘grılan servisler, sıraya bakılmaksızın % 70 oranında tutuyorsa bloklar aynı olarak de˘gerlendirilmi¸s ve buna g¨ore numar-alandırılmı¸stır.
3.4 ˙I¸slem Blokları Arası Ge¸ci¸sler
Bloklar tespit edildikten sonra aynı m¨u¸steri i¸cin ekrandan arka arkaya yapılan i¸slemlerin (blokların) neler oldu˘gu belirlenmi¸stir. Bir blo˘ga ait ba¸slangı¸c ve biti¸s zaman bilgisi elimizde bulunmaktadır. Kullanıcılar ekrandan bir m¨u¸steri i¸cin i¸slem yaptıklarında, belli bir s¨ure i¸cinde, tamamlamaları gereken di˘ger i¸slemi yap-maktadırlar. Ancak ekran a¸cıkken i¸slemin hemen tamamlanması gerekmemekte, kullanıcılar aralar verebilmektedirler. Bu nedenle 20 dakika kadar bir s¨ure i¸cinde aynı m¨u¸steri i¸cin yapılmı¸s olan i¸slem bloklarının arka arkaya geldikleri varsayılmı¸s-tır. Buna ek olarak, kullanıcılar i¸slemleri yarım bıraktıktan sonra tekrar ba¸sa
d¨onebilmektedir-ler. Ancak ba¸slangı¸c i¸slemi sabit oldu˘gundan di˘ger bloklardan ba¸slangı¸c i¸slemine ge¸ci¸s tespit edilirse s¨urecin yeniden ba¸sladı˘gı varsayılmı¸stır.
Sonu¸c olarak, i¸slem g¨unl¨u˘g¨u verisinden yola ¸cıkılarak i¸slem blo˘gu ¨ozet ¸cıktısı olu¸sturulmu¸stur. Bu ¸cıktı, servis adı, ilgili blok numarası, sonra ¸ca˘grılan blok numaraları alanlarını i¸cermektedir. Olu¸sturulan veriye ait alanlar ve a¸cıklamaları Tablo 2’de verilmi¸stir:
Tablo 2. Sonu¸c olarak olu¸sturulan i¸slem blo˘gu ¨ozet tablosunda tutulan bilgiler.
Alan adı Alanın a¸cıklaması
Servis adı Sistemde tanımlı olan servis adı
˙Ilgili blok Servisin ait oldu˘gu i¸slem blo˘guna verilen numara Bu bloktan sonraki i¸slem blo˘gu ˙Ilgili i¸slem blo˘gundan sonra gelen olası i¸slem blokları
Algoritma sonucunda bloklara ait numaralar elde edilmi¸s, alan bilgisine sahip yazılımcı tarafından numaralandırılmı¸s olan i¸slem blokları yaptıkları i¸se g¨ore isimlendirilmi¸stir.
3.5 S¨ure¸c Modelinin Ortaya Konulması
Elde edilen veriden s¨ure¸c modelinin g¨orselle¸stirilmesi i¸cin Graphviz isimli bir uygulama kullanılmı¸stır [5]. Graphviz a¸cık kaynak bir grafik g¨orselle¸stirme uygu-lamasıdır. A˘g olu¸sturma, biyoinformatik, yazılım m¨uhendisli˘gi, veritabanı ve web tasarımı, makine ¨o˘grenmesi ve di˘ger teknik alanlarda g¨orselle¸stirme amacıyla kullanılmaktadır. Servis adı, ait oldu˘gu blok ve ilgili bloktan sonra ¸ca˘grılan blok bilgilerini i¸ceren veri Graphviz uygulamasının girdi olarak aldı˘gı formata ¸
cevrilmi¸stir.
4
Vaka C
¸ alı¸
sması Sonu¸
cları
Bu b¨ol¨umde yapılan ¸calı¸smaya ait ¸cıktı ¨ornekleri ve ortaya ¸cıkan model sunulmu¸stur. End¨ustriyel vakadan 2 g¨un boyunca 800,000 adet i¸slem g¨unl¨u˘g¨u kaydı elde edilmi¸stir.
¨
Ornek kayıtlarda web servisin girdisinde ge¸cen orijinal m¨u¸steri numaraları ¸sifrelenerek ilgili m¨u¸steri numaraları elde edilmi¸stir. Web servisin ¸cıktısından da i¸s hatası veya sistem hatası alınıp alınmadı˘gı ortaya konmu¸stur. 0 de˘geri hata alınmadı˘gını, 1 de˘geri ise hata alındı˘gını ifade etmektedir. Elde etti˘gimiz i¸slem g¨unl¨u˘g¨u verisine ait ¨ozet bilgi Tablo 3’te, ¨ornek bazı kayıtlarsa Tablo 4’te verilmi¸stir.
Tablo 3. Elde edilen veriye ait ¨ozet bilgi.
Kayıt adedi Zaman aralı˘gı Farklı web servis adedi Dosya boyutu
Tablo 4. ¨Ornek i¸slem g¨unl¨u˘g¨u kayıtları.
M¨u¸steri C¸ a˘grım zamanı Yanıt C¸ a˘grılan servisin adı ˙I¸s Sistem
no. s¨uresi hatası hatası
(ms) 0 07.05.2019 08:34:50.477 46 ELGBT:retrieveBasicInfo 0 0 0 07.05.2019 08:34:50.513 93 ELGBT:retrieveCustomerGroupsAndFirms 0 0 0 07.05.2019 08:34:57.843 31 AppMngUI:IsEligible 0 0 0 07.05.2019 08:34:57.873 62 ELGBT:findMessage 0 0 0 07.05.2019 08:35:43.100 15 AppMngUI:RetrieveDBParameters 0 0
B¨ol¨um 3’te anlatılan y¨ontemle i¸slem g¨unl¨u˘g¨u kayıtları gruplanarak i¸slem blokları elde edilmi¸s, bu bloklardan birbirine benzeyenler aynı blok olarak nu-maralandırılmı¸stır. Tablo 5’te ¨ornek iki i¸slem blo˘gu verilmi¸s, baz alınan blokta ge¸cen 6 adet servisten 5’i di˘ger blokta da ge¸cti˘gi, dolayısıyla % 83 oranında benzedi˘gi i¸cin (5/6) aynı blok olarak de˘gerlendirilmi¸stir.
Tablo 5. Benzer iki i¸slem blo˘gu.
Baz alınan blokta ge¸cen servisler Benzer olarak de˘gerlendirilen blokta ge¸cen servisler AppMngUI:retrieveFinancialInfo AppMngUI:retrieveScore AppMngUI:retrieveCustomerByReferenceId AppMngUI:calculateProfileRate AppMngUI:retrieveProductParameterList AppMngUI:calculateCorporateProductProposedRate AppMngUI:retrieveFinancialInfo AppMngUI:retrieveCustomerByReferenceId AppMngUI:retrieveScore AppMngUI:calculateProfileRate AppMngUI:calculateCorporateProductProposedRate
Sonu¸c olarak ilgili servis, ait oldu˘gu i¸slem blo˘gu ve bu bloktan sonra gelebilen olası i¸slem blokları ortaya konulmu¸s, ¨ornek bazı kayıtlar Tablo 6’da verilmi¸stir. 800.000 adet i¸slem g¨unl¨u˘g¨u kaydından 12 adet i¸slem blo˘gu ¸cıkarılmı¸stır. Bu blok-lar alan bilgisine sahip yazılımcı tarafından isimlendirilmi¸s, elde edilen s¨ure¸c akı¸sı ise S¸ekil 3’te verilmi¸stir. C¸ ıkarılan s¨ure¸c akı¸sı ekibimiz dı¸sından s¨ure¸c bilgisine sahip analist tarafından da incelenerek i¸slem bloklarının ve bu bloklar arasındaki ge¸ci¸slerin do˘gru oldu˘gu teyit edilmi¸stir.
Tablo 6. ˙I¸slem blo˘gu tablosu ¨ornek kayıtları.
Servis adı ˙Ilgili blok Bu bloktan sonraki i¸slem blo˘gu
AppMngUI:retrieveMainProductValueList 2 3
AppMngUI:retrieveReferenceDataList 2 3
AppMngUI:retrieveProductBriefInfoList 3 4,8,9
AppMngUI:RetrieveDBParameters 3 4,8,9
5
Sonu¸
c ve Gelecek C
¸ alı¸
smalar
Bu ¸calı¸smayla bir bankacılık uygulamasına ait i¸slem g¨unl¨uklerinden i¸slem blok-larını ve bu bloklar arası ge¸ci¸sleri ¸cıkardık ve s¨ure¸c modelini ortaya koyduk.
¨
Onceki ¸calı¸smamızda [6] web servislerinin belli aralıklarda ortalama yanıt d¨onme s¨ureleri ve ka¸c kez ¸ca˘grıldıkları bilgilerini kullanarak aralarındaki ba˘gımlılıkları ortaya ¸cıkarabilece˘gimizi g¨orm¨u¸st¨uk. ¨On¨um¨uzdeki d¨onemde ise hem web servis hem de i¸slem blo˘gu bazlı olarak sistemde bir anomalite olup olmadı˘gına dair tah-minleme yapılması i¸cin ¸calı¸smalarımıza devam edece˘giz. Bu sayede kullanıcıların ekranlarda yapamadı˘gı veya sayısında d¨u¸s¨u¸s olan bir i¸slem blo˘gu oldu˘gunda otomatik olarak uyarı verebilece˘gimizi ¨ong¨ormekteyiz.
Kaynak¸
ca
1. Van Der Aalst, W., Adriansyah, A., De Medeiros, A. K. A., Arcieri, F., Baier, T., Blickle, T., ..., Burattin, A. (2011, August). Process mining manifesto. In Interna-tional Conference on Business Process Management (pp. 169-194). Springer, Berlin, Heidelberg.
2. Van der Aalst, W. M., Reijers, H. A., Weijters, A. J., van Dongen, B. F., De Medeiros, A. A., Song, M., Verbeek, H. M. W. (2007). Business process mining: An industrial application. Information Systems, 32(5), 713-732.
3. Poncin, W., Serebrenik, A., Van Den Brand, M. (2011, March). Process mining software repositories. In 2011 15th European Conference on Software Maintenance and Reengineering (pp. 5-14). IEEE.
4. Gadler, D., Mairegger, M., Janes, A., Russo, B. (2017). Mining Logs to Model the Use of a System. International Symposium on Empirical Software Engineering and Measurement, 2017, 334–343.
5. Ellson, J., Gansner, E., Koutsofios, L., North, S. C., Woodhull, G. (2001). Graphviz—open source graph drawing tools. In International Symposium on Graph Drawing (pp. 483-484). Springer, Berlin, Heidelberg.
6. Akta¸s, E. U., C¸ alpur, M. C¸ ., Yıldırım, ¨U. ¨U., Yıldırım, E. (2018) Inferring Depen-dencies Among Web Services with Predictive and Statistical Analysis of System Logs. Turkish National Software Architecture Conference.
