Bir önceki Makalemizde bir modelleme mantığına neden ihtiyaç duyulduğuna, bize ne kazandıracağına, ne kaybettireceğine değinmiştik. UML i güçlü olarak nasıl kullanabileceğinizi göstermeye çalışmıştım.
Bu makalede UML ile analiz yapma mantığının beklide en önemli diyagramı olan Use Case e değineceğim. Bildiğim kadarı ile Use Case diyagramları ilk kez 1960 lı yıllarda Ericsson firmasında kullanılmaya başlanmış. UML ile analiz yapmak demek analizin bir çıktısı olarak kullanabileceğiniz bir diyagram oluşturabilmek, analizdeki ihtiyaçlarınızı anlatabiliyor olmak ve en önemlisi de ortak olarak herkesin anlayabileceği yorumlayabileceği bir diyagram olarak gösterebiliyor olmaktır.
İyi bir Use Case diyagramı çizebilmek için iyi bir analiz yapmanız gerekmektedir. İyi bir analizi yaparken de, kolay anlaşılır, basit, sade ve iş adımlarını bir senaryo olarak düşünmek gerekir. Use Case diyagramları iş analizi yaparken kullanacağınız diyagram şeklidir. Dolayısı ile içerisinde teknik bilgiyi çok fazla içermez.
Use Case UML diyagramlarının içinde en çok kullanılan diyagramlardan bir tanesidir. Use Case diyagramını mutlaka görmüş ya da kullanmışsınızdır. Use Case diyagramı diğer UML diyagramlarından farklı bir diyagramdır. Kuralları çok daha azdır. Daha çok işi kuş bakışı anlatmakla ilgilidir ve kullanıcıdan kullanıcıya modellemesi değişebilir.
Use Case diyagramı sistemin iş yapma yöntemlerini belirttiğim gibi kuş bakışı tasarlamanızı sağlar. Bu kuş bakışı tasarımda, işi kimin yaptığı ve ne işler yaptığı ile ilgilidir. İşi yapan kişiler, işlemleri tetikleyen kişilerdir ve onların yaptığı işlemleri adım adım göstermektir olay. Buradaki soru işareti yaptıkları işleri hangi seviyede göstereceğiniz. Yine önceki makalede belirttiğim gibi bunun kesin bir tanımı yok, önemli olan sizin standardınızın nasıl olduğu, sizin UML i okumasını istediğiniz kişilerin nasıl anladığıdır. Use Case diyagramlarının mantığı basit olduğu için müşterilerinize kısa bir tanıtımla üzerinde konuşabiliyor, diyagramları inceliyor olabilirsiniz. Oluşturduğunuz analiz dokümanlarına da ekleyerek, hem müşteriye hem de teknik kişilere iş kurallarını bu kuralları kimlerin gerçekleştireceğini anlatabilirsiniz.
Use Case diyagramı basit olmalıdır, müşterilerde inceleyeceği için gereksiz teknik bilgiden kaçınılmalıdır. Örneğin sistemin mail attırmasını istiyorsanız, “Exchange Server mail atar” gibi bir deyim yerine “Mail gönderilir” gibi daha basit bir tanımlama tercih ederseniz anlaşılabilirlik çok daha artar.
“Kullanıcı SMS gönderir”
Bu kelime bir Use Casedir. Use Case, kelime anlamına bakıp, birebir çevirdiğiniz de kullanım durumu demektir. Peki kullanım durumunu ne demektir ?. Kullanım durumu bir sistemin, başka bir sistem ya da kullanıcı grubu tarafından, bir amaç için, bu amacın bir sonucu olacak şekilde yaptığı işlemleri ve akışları anlatan diyagram şeklidir. Bir kullanım durumu, aslında senaryolardan oluşmuş bir işlemin akışıdır. Biraz sonra Use Case diyagramının elemanlarının neler olduğunu ve ne amaçla kullanıldığını inceleyeceğiz ama önce senaryo nun ne olduğuna bakalım.
Senaryo kavramı aslında ikiye ayrılır. Birincisi kullanım senaryoları (Use Scenario) , ikincisi ise kullanıcı senaryolarıdır. (User Scenario) Bu iki tipte Use Case lerden türeyen tiplerdir. Kullanım senaryoları, belli, spesifik, özel bir aktör için yapılan iştir. Örneğin “Cenk SMS gönderir” yada “Cenk Turkcell ile SMS gönderir” gibi örneklenebilir, aslında yapılan iş temel olarak Use Case de yapılan iştir, sadece yapan kişi ve yapılan iş biraz daha özeleşmiştir ancak yapılan sonuçta “SMS göndermek” tir. Cenk’in telefon etmesi ile, satış takımının telefon etmesi farklı kullanım senaryolarıdır. Diğer senaryo tipi olan kullanıcı senaryoları da sistemi kullanacak bir kişinin gözünden bütün sistemi anlatır. Bunun için bütün sistemin Use Casenin belirlenmiş olması gerekmektedir aslında. Kullanıcı senaryoları, bir kitaptaki kahramanın kendi hayatını, kendi gördüklerini, yaşadıklarını anlatmasına benzer. O kahramanın yerinde herhangi biriside olabilirdi, ama o kahraman özel olarak yaşayıp bunları görmüştür. Yani “Cenk SMS gönderir”, “Cenk e cevap SMS i gelir”, “Cenk cevap SMS indeki kodu Web sitesine girer” gibi devam edilebilir.
Senaryoların kullanılması için belirttiğim gibi bütün Use Caselerin yani genel durumların belirli olması gerekmektedir, ondan sonra bu spesifik kullanıcıların üzerine gidilmesi sistemi çok daha başarılı modellemenizi, bir konuyu unutmamanızı sağlar. Özellikle Kullanıcı Senaryosunu kendi oluşturduğunuz Use Case ler üzerinden müşteriniz ile konuşarak deneyiniz. Eksik bir noktanın kalmaması çok önemlidir.
Yukarıdaki örnekleri verirken spesifik bir kullanıcı yada bir kullanıcı grubu kullanılır gibi kelimeler kullandım, bu kullanıcıların kimler olduklarını ve bizim Use Case diyagramlarımızda ne işe yaradıklarını tam olarak konuşmadık. Bu kullanıcılara Use Case diyagramların aktör denir. Diyagramlarda aktörler çok kolay ve basit olması açısından çöp adamlar ile gösterilirler. Aktör, bizim yazacağımız yazılımın dışındaki bir kişi ya da kişi grubu, dışarıdaki bir sistem yada teknik araçlar olabilirler, aktörler bizim sistemimize bir işlem yaparlar, bu işlemi de belirli bir amaç için yapmaları gerekmektedir. Olay gerçekleştiğinde bu amacı sağlamalıdırlar. Bir aktör bizim sistemimizle iletişime girdiğinde bir den çok amacı olabilir, ancak biz bunları tek tek gösteririz ki karmaşıklık olmasın.
Aktörleri ve Use Case leri tanıdık, aktörler ile Use Case leri birleştiren çizgiye de, ilişki (Associations) denir. Şimdi analiz yaparken Use Case leri nasıl belirleyeceğinize bakalım, çok temel olarak “Kullanıcı SMS gönderir” kelimesine bakalım, yukarıda da belirttiğimiz gibi aslında bu bir Use Case dir. “Kullanıcı” kelimesi aktör, “SMS” kelimesi kapsamı, “gönderir” kelimesi ise amacı anlatır. Böyle bir Use Case diyagramı aşağıdaki gibi gösterilebilir,
Gördüğünüz gibi olduça basit, bu Use Case i biraz daha büyütelim
Bu Use Case diyagramında gördüğünüz gibi bir aktör birden çok Amaçla (Use Case ile) iş yapabilirken, bir amacı (Use Case i) gerçekleştiren birden çok kullanıcıda olabilir.
Önceki makalelerde de belirttiğim gibi, Use Case ler diyagram olarak kullanır. Ancak Use Case leri yazarak da oluşturabilirsiniz. Bu da çok geçerli bir yöntemdir, eğer müşteriniz Use Case diyagramlarını okumayı red ediyorsa, bir sonraki makalede yazacağımız Aktivite diyagramlarını da kullanarak, Use Case lerinizi adım adım yazabilirsiniz. Diyagram çizmeyerek yazmanız bile analizlerinizi çok güçlü kılacaktır.
Use Case diyagramlarında aslında çok fazla özellik vardır. Ancak bu özellikler çok da fazla kullanılmaz aslında, kullanıldığında diyagramı güçlendirir, daha detaylı bilgi verir, ancak kompleksliğide arttırdığı için, çok bilinmez, dolayısı ile de okunamaz, bir müddet sonra yavaş yavaş kullanılmaz, bu konulara hızlıca değinmek istiyorum. kapsamlı bir UML dokümanı gördüğünüz zaman en azından okuyabilmenizde yardımcı olması adına,
İlki “System Boundary” diye geçen bazı kaynaklarda “Domain” olarak da anlatılan aslında kapsamınızı tuttuğunuz bir dikdörtgendir, bu dikdörtgenin içindeki Use Case ler bu kapsam içindedir anlaşılır.
İkincisi olarak İlişki (Associations) ın özelliklerini inceleyelim, adında anlaşılacağı gibi iki nesne arasında ilişki kurmak ile ilgilidir. Örneğin bir aktör ü başka bir aktörden türetebilirsiniz (Generalization ilişkisi, bildiğimiz OO daki inheritance gibi.) Bu daha çok senaryoları oluşturmak ile ilgilidir. Daha detay bilgi vermek bazında işinizi görebilir, üçgen şeklindeki ok ile gösterilir.
Bunların dışında temel olarak kullanılan iki tane daha ilişki tipi vardır. Extends (genişletir), Uses (kullanır, içerir) bu ikisi genelde çok birbirine karıştırılır. Aslında temeli mantığı çok basittir.
Extends de var olan bir Use Case i geliştirip yeni işlemler ekleyerek kullanırız, Uses de ise varolan bir Use Case i diğer bir adım içinde aynen kullanırız.
Bu iki tipte, aynı türetme mantığındaki gibi kullanılır, tek fark üzerindeki tipleridir. (UML de bu tiplere, Stereotype yani şablon denilir) Extends için “<>”, Uses için “<>” kullanılır.
Use Case dokümanları ile ilgili genel bilgileri inceledik, basit Use Case diyagramları çizdik, bu makale serisi tamamlandıktan sonra komple bir sistemi çizdiğimizde bu diyagramlar çok daha anlaşılır olacaktır. Unutmayın bilgisayar dünyasında hep olduğu gibi, ne kadar çok yaparsanız okadar iyi olursunuz, Use Case diyagramlarını bu bilgiler ışığında oluşturmaya çalışın. Başta olmuyormuş gibi gelecek ama bir müddet sonra okadarda zor olmadığını göreceksiniz.
Bir sonraki makalede Use Case ler ile birlikte İş analizi yapmak için kullanılan diyagramlardan olan aktivite diyagramlarına değineceğim, o zaman Use Case diyagramları da daha anlam kazanacaktır.
İstek eleştiri ve önerileriniz için aşağıdaki mail adresimi kullanabilirsiniz.
Levent Cenk ÇAĞLAR
levent@cenkcaglar.com
Bu makalede UML ile analiz yapma mantığının beklide en önemli diyagramı olan Use Case e değineceğim. Bildiğim kadarı ile Use Case diyagramları ilk kez 1960 lı yıllarda Ericsson firmasında kullanılmaya başlanmış. UML ile analiz yapmak demek analizin bir çıktısı olarak kullanabileceğiniz bir diyagram oluşturabilmek, analizdeki ihtiyaçlarınızı anlatabiliyor olmak ve en önemlisi de ortak olarak herkesin anlayabileceği yorumlayabileceği bir diyagram olarak gösterebiliyor olmaktır.
İyi bir Use Case diyagramı çizebilmek için iyi bir analiz yapmanız gerekmektedir. İyi bir analizi yaparken de, kolay anlaşılır, basit, sade ve iş adımlarını bir senaryo olarak düşünmek gerekir. Use Case diyagramları iş analizi yaparken kullanacağınız diyagram şeklidir. Dolayısı ile içerisinde teknik bilgiyi çok fazla içermez.
Use Case UML diyagramlarının içinde en çok kullanılan diyagramlardan bir tanesidir. Use Case diyagramını mutlaka görmüş ya da kullanmışsınızdır. Use Case diyagramı diğer UML diyagramlarından farklı bir diyagramdır. Kuralları çok daha azdır. Daha çok işi kuş bakışı anlatmakla ilgilidir ve kullanıcıdan kullanıcıya modellemesi değişebilir.
Use Case diyagramı sistemin iş yapma yöntemlerini belirttiğim gibi kuş bakışı tasarlamanızı sağlar. Bu kuş bakışı tasarımda, işi kimin yaptığı ve ne işler yaptığı ile ilgilidir. İşi yapan kişiler, işlemleri tetikleyen kişilerdir ve onların yaptığı işlemleri adım adım göstermektir olay. Buradaki soru işareti yaptıkları işleri hangi seviyede göstereceğiniz. Yine önceki makalede belirttiğim gibi bunun kesin bir tanımı yok, önemli olan sizin standardınızın nasıl olduğu, sizin UML i okumasını istediğiniz kişilerin nasıl anladığıdır. Use Case diyagramlarının mantığı basit olduğu için müşterilerinize kısa bir tanıtımla üzerinde konuşabiliyor, diyagramları inceliyor olabilirsiniz. Oluşturduğunuz analiz dokümanlarına da ekleyerek, hem müşteriye hem de teknik kişilere iş kurallarını bu kuralları kimlerin gerçekleştireceğini anlatabilirsiniz.
Use Case diyagramı basit olmalıdır, müşterilerde inceleyeceği için gereksiz teknik bilgiden kaçınılmalıdır. Örneğin sistemin mail attırmasını istiyorsanız, “Exchange Server mail atar” gibi bir deyim yerine “Mail gönderilir” gibi daha basit bir tanımlama tercih ederseniz anlaşılabilirlik çok daha artar.
“Kullanıcı SMS gönderir”
Bu kelime bir Use Casedir. Use Case, kelime anlamına bakıp, birebir çevirdiğiniz de kullanım durumu demektir. Peki kullanım durumunu ne demektir ?. Kullanım durumu bir sistemin, başka bir sistem ya da kullanıcı grubu tarafından, bir amaç için, bu amacın bir sonucu olacak şekilde yaptığı işlemleri ve akışları anlatan diyagram şeklidir. Bir kullanım durumu, aslında senaryolardan oluşmuş bir işlemin akışıdır. Biraz sonra Use Case diyagramının elemanlarının neler olduğunu ve ne amaçla kullanıldığını inceleyeceğiz ama önce senaryo nun ne olduğuna bakalım.
Senaryo kavramı aslında ikiye ayrılır. Birincisi kullanım senaryoları (Use Scenario) , ikincisi ise kullanıcı senaryolarıdır. (User Scenario) Bu iki tipte Use Case lerden türeyen tiplerdir. Kullanım senaryoları, belli, spesifik, özel bir aktör için yapılan iştir. Örneğin “Cenk SMS gönderir” yada “Cenk Turkcell ile SMS gönderir” gibi örneklenebilir, aslında yapılan iş temel olarak Use Case de yapılan iştir, sadece yapan kişi ve yapılan iş biraz daha özeleşmiştir ancak yapılan sonuçta “SMS göndermek” tir. Cenk’in telefon etmesi ile, satış takımının telefon etmesi farklı kullanım senaryolarıdır. Diğer senaryo tipi olan kullanıcı senaryoları da sistemi kullanacak bir kişinin gözünden bütün sistemi anlatır. Bunun için bütün sistemin Use Casenin belirlenmiş olması gerekmektedir aslında. Kullanıcı senaryoları, bir kitaptaki kahramanın kendi hayatını, kendi gördüklerini, yaşadıklarını anlatmasına benzer. O kahramanın yerinde herhangi biriside olabilirdi, ama o kahraman özel olarak yaşayıp bunları görmüştür. Yani “Cenk SMS gönderir”, “Cenk e cevap SMS i gelir”, “Cenk cevap SMS indeki kodu Web sitesine girer” gibi devam edilebilir.
Senaryoların kullanılması için belirttiğim gibi bütün Use Caselerin yani genel durumların belirli olması gerekmektedir, ondan sonra bu spesifik kullanıcıların üzerine gidilmesi sistemi çok daha başarılı modellemenizi, bir konuyu unutmamanızı sağlar. Özellikle Kullanıcı Senaryosunu kendi oluşturduğunuz Use Case ler üzerinden müşteriniz ile konuşarak deneyiniz. Eksik bir noktanın kalmaması çok önemlidir.
Yukarıdaki örnekleri verirken spesifik bir kullanıcı yada bir kullanıcı grubu kullanılır gibi kelimeler kullandım, bu kullanıcıların kimler olduklarını ve bizim Use Case diyagramlarımızda ne işe yaradıklarını tam olarak konuşmadık. Bu kullanıcılara Use Case diyagramların aktör denir. Diyagramlarda aktörler çok kolay ve basit olması açısından çöp adamlar ile gösterilirler. Aktör, bizim yazacağımız yazılımın dışındaki bir kişi ya da kişi grubu, dışarıdaki bir sistem yada teknik araçlar olabilirler, aktörler bizim sistemimize bir işlem yaparlar, bu işlemi de belirli bir amaç için yapmaları gerekmektedir. Olay gerçekleştiğinde bu amacı sağlamalıdırlar. Bir aktör bizim sistemimizle iletişime girdiğinde bir den çok amacı olabilir, ancak biz bunları tek tek gösteririz ki karmaşıklık olmasın.
Aktörleri ve Use Case leri tanıdık, aktörler ile Use Case leri birleştiren çizgiye de, ilişki (Associations) denir. Şimdi analiz yaparken Use Case leri nasıl belirleyeceğinize bakalım, çok temel olarak “Kullanıcı SMS gönderir” kelimesine bakalım, yukarıda da belirttiğimiz gibi aslında bu bir Use Case dir. “Kullanıcı” kelimesi aktör, “SMS” kelimesi kapsamı, “gönderir” kelimesi ise amacı anlatır. Böyle bir Use Case diyagramı aşağıdaki gibi gösterilebilir,
Gördüğünüz gibi olduça basit, bu Use Case i biraz daha büyütelim
Bu Use Case diyagramında gördüğünüz gibi bir aktör birden çok Amaçla (Use Case ile) iş yapabilirken, bir amacı (Use Case i) gerçekleştiren birden çok kullanıcıda olabilir.
Önceki makalelerde de belirttiğim gibi, Use Case ler diyagram olarak kullanır. Ancak Use Case leri yazarak da oluşturabilirsiniz. Bu da çok geçerli bir yöntemdir, eğer müşteriniz Use Case diyagramlarını okumayı red ediyorsa, bir sonraki makalede yazacağımız Aktivite diyagramlarını da kullanarak, Use Case lerinizi adım adım yazabilirsiniz. Diyagram çizmeyerek yazmanız bile analizlerinizi çok güçlü kılacaktır.
Use Case diyagramlarında aslında çok fazla özellik vardır. Ancak bu özellikler çok da fazla kullanılmaz aslında, kullanıldığında diyagramı güçlendirir, daha detaylı bilgi verir, ancak kompleksliğide arttırdığı için, çok bilinmez, dolayısı ile de okunamaz, bir müddet sonra yavaş yavaş kullanılmaz, bu konulara hızlıca değinmek istiyorum. kapsamlı bir UML dokümanı gördüğünüz zaman en azından okuyabilmenizde yardımcı olması adına,
İlki “System Boundary” diye geçen bazı kaynaklarda “Domain” olarak da anlatılan aslında kapsamınızı tuttuğunuz bir dikdörtgendir, bu dikdörtgenin içindeki Use Case ler bu kapsam içindedir anlaşılır.
İkincisi olarak İlişki (Associations) ın özelliklerini inceleyelim, adında anlaşılacağı gibi iki nesne arasında ilişki kurmak ile ilgilidir. Örneğin bir aktör ü başka bir aktörden türetebilirsiniz (Generalization ilişkisi, bildiğimiz OO daki inheritance gibi.) Bu daha çok senaryoları oluşturmak ile ilgilidir. Daha detay bilgi vermek bazında işinizi görebilir, üçgen şeklindeki ok ile gösterilir.
Bunların dışında temel olarak kullanılan iki tane daha ilişki tipi vardır. Extends (genişletir), Uses (kullanır, içerir) bu ikisi genelde çok birbirine karıştırılır. Aslında temeli mantığı çok basittir.
Extends de var olan bir Use Case i geliştirip yeni işlemler ekleyerek kullanırız, Uses de ise varolan bir Use Case i diğer bir adım içinde aynen kullanırız.
Bu iki tipte, aynı türetme mantığındaki gibi kullanılır, tek fark üzerindeki tipleridir. (UML de bu tiplere, Stereotype yani şablon denilir) Extends için “<
Use Case dokümanları ile ilgili genel bilgileri inceledik, basit Use Case diyagramları çizdik, bu makale serisi tamamlandıktan sonra komple bir sistemi çizdiğimizde bu diyagramlar çok daha anlaşılır olacaktır. Unutmayın bilgisayar dünyasında hep olduğu gibi, ne kadar çok yaparsanız okadar iyi olursunuz, Use Case diyagramlarını bu bilgiler ışığında oluşturmaya çalışın. Başta olmuyormuş gibi gelecek ama bir müddet sonra okadarda zor olmadığını göreceksiniz.
Bir sonraki makalede Use Case ler ile birlikte İş analizi yapmak için kullanılan diyagramlardan olan aktivite diyagramlarına değineceğim, o zaman Use Case diyagramları da daha anlam kazanacaktır.
İstek eleştiri ve önerileriniz için aşağıdaki mail adresimi kullanabilirsiniz.
Levent Cenk ÇAĞLAR
levent@cenkcaglar.com
