Navigation

• Main Page

• Random Page
• Create a new Page
• All Pages
• Categories

• Administration
• File Management

• Login/Logout
• Language Selection
• Your Profile
• Create Account

Quick Search

Advanced Search »

Bu bölüm UML ve CBD metodlarının nasıl kullanılacağını örnekler ile anlatmaktadır.

UML İngilizce Unified Modelling Language (Genelleştirilmiş Modelleme Dili) kelimelerinin baş harflerinden meydana gelir. Modelleme sırasında kullanılacak bir dizi şematik gösterimi teşkil eder. Genelde Nesne Yönelimli sistemlerin analiz ve modelleme aşamalarında kullanılır. Nesnelerin birbirleri arasındaki ilişkilerini ve kendi iç yapılarını gösterir. Bir standart olarak Object Management Group (OMG) tarafından dünyaya yayılmaktadır. Sahibi de OMG’dir. Şu anki en son versiyonu 2.0’dır. Programlama dilinden ve işletim sisteminden bağımsız bir modelleme dilidir.

CBD İngilizce Component Based Development (Modül (ben PETEK diyorum) Tabanlı Geliştirme) kelimelerinin baş harflerinden oluşur. Nesne Yönelimli olmayan sistemlerde Hizmet Bazlı Mimari’leri (Service Oriented Architecture SOA) uygulayabilmek amaçlı geliştirilmiş bir yapıdır. Fakat Nesne Yönelimli sistemlerde de kullanılabilir. CBD’de her modülün bir arayüzü, bir veritabanı, kendine has özellikleri ve iş kuralları vardır. Modüller bir araya gelerek daha karmaşık modülleri ortaya çıkartabilirler. Her modülün girdileri, çıktıları ve hata durumlarında ürettikleri hata mesajları vardır. Genelde IBM Mainframe sistemi için geliştirilmiş fakat Windows veya Unix bazlı sistemlerde de kullanılmaktadır. CBD kavram olarak her türlü projeye uygulanabilir.

Öncelikle OO analiz konularından başlayarak bir giriş yapmak istiyorum. Sırası ile UML ve CBD konularına geçeceğiz. İlk olarak OO analiz sırasında aşama aşama ne tür belgelere ihtiyaç duyuluyor buna bakalım.

Edit

İş gereksinimlerini modelleme aşaması

Bu aşama “iş problemlerine” çözümler bulunması ve çözümlerin yazılımlar yolu ile hayata geçirilmesine öncülük eder. İşi analiz edecek olan ekip İş Analisti’dir (Business Analyst). İş analistleri sektörden aldıkları iş bilgisini yazılımcıya aktarırlar. Bu aktarım sırasında kullanılacak haberleşme dili UML olmalıdır. Bu sayede aktarılan bilginin anlaşılabilirliği arttırılmış olur. Analizler ilk olarak Senaryoların ortaya çıkarılması ile başlar. İş analistlerinin üretmesi gereken belgelere bir bakalım. Burada anlatılan her belgeyi üretmek gerekli değildir, projenin gerekliliklerine göre değiştirilebilir yada yenileri eklenebilir.

Edit

Senaryo belgesi

Senaryolar analizi yapılan iş ile müşterileri veya bulunduğu piyasanın hareketleri ile aralarında geçen olaylardır. Olayların tümünün doğrudan işi etkilemesi gerekir. İşin verdiği tepkiler ve sonuçları burada tanımlanır ve Senaryolar olarak belgelendirilir. Senaryolar ortaya çıkartılırken takip edilecek metod müşteri yada kullanıcı grubu ile yapılacak aylık toplantılardır. Bu toplantılarda senaryolar gözden geçirilir, kullanılacak sistemler belirlenir ve senaryolar ortaya çıkartılmaya çalışılır. Kullanıcı grubunun kadrosu her toplantıda aynı olmalıdır ve değişmemelidir. Proje ekibinde her senaryodan bir analist sorumlu olmalıdır. Tüm senaryoları yönetecek ve toplantıları organize edecek bir İş Gereksinimleri Analisti (konusunda uzman ve deneyimli) bulunmalıdır. İGA hem toplantıların planını hem de konuşulacak konuları ortaya çıkarır ve ekibi bu konulardan haberdar eder. UML ve OO analiz konularında eğitim verecek düzeyde olması gerekir. Bu belgenin ingilizce ismi Use-Case’dir.

Edit

İşleme modeli belgesi

Bu arada İş Analisti tek tek senaryoları ele alırken İşleme Modeli’nide ortaya çıkarır. İşleme Modeli analizi yapılan işin nasıl işlediğini ve senaryoların nasıl birbirleri ile bağlantıda bulunduklarını ve aralarındaki ilişkileri anlatır. Her senaryonun girdi ve çıktıları göz önüne alınarak Genel İşleme Modeli oluşturulur. Bu belgenin ingilizce ismi Business Process Model’dir.

Edit

İş kuralları kütüğü belgesi

Ortaya çıkan mevcut ve yeni iş kuralları bu belgede numara verilerek kayıt edilir. İş kuralları, analizin ilk aşamalarında, Senaryo belgeleri içinde ortaya çıkartılırken, belli bir miktarı geçtiklerinde ayrı bir belgede toplanması gerekir. Bir kaç senaryo aynı iş kurallarına bağlantılı olarak çalışıyor olabilir. Her senaryo belgesi için aynı iş kuralını tekrar tekrar yazmak yerine bu belgedeki kayıt numarası ile çağırmak daha mantıklı olur ve zamandan kazandırır. İş kuralları, Değişim ve İstekler Kontrolüne bağlıdır. Bu belge üzerinde yapılacak değişiklikler çok iyi gözden geçirilmeli ve projenin diğer kısımları üzerindeki etkisi çok iyi tanımlanmalıdır. Bu belgenin ingilizce ismi Business Rules Register’dır.

Edit

Sözlük belgesi

Proje içinde ortaya çıkan deyimlerin ve bilinmeyen kelimelerin bu belgede toplanması gerekir. Senaryo, İş Modeli yada İş Kuralları Kütüğü içinde sözlükte kayıtlı kelimeler geçiyorsa sözlük belgesine bir bağlantı verilmelidir. Eğer belli devlet yasalarının kullanımı söz konusu ise onlarda bu belge içinde yer alır. Projede kullanılacak hesaplama formülleri ve bu formüllerin parametrelerinin nerelerden geldiği de belirtilir. Sözlük, Değişim ve İstekler Kontrolü’ne bağlı olmayan bir belgedir ve sürekli güncellenebilir. Buna rağmen her proje ekibi üyesinin değişikliklerden haberdar olması gerekir ve Proje Yöneticisinin değişikliği onaylaması gerekir. Bu belgenin ingilizce ismi Glossary of Terms’dür.

Edit

Genel proje gereksinimleri belgesi

Bu belgede proje için gerekli alt yapı anlatılır. Alt yapı hem geliştirme hemde hayata geçtiğinde çalışacağı ortamı kapsar. Eğer proje sonucu ortaya çıkan ürünün çalışacağı bilgisayar alt yapısında özel bir gereksinim varsa belirtilmelidir. Kullanılacak yan araçlar (yazıcı, nokta vuruşlu yazıcı, barkod okuyucu, yazar kasa, tartı aletleri, kontrol sistemleri vb.) ve bunların kullandığı port numaraları ve bağlantı şekilleri açıkça belirtilmelidir. Ürünün çalışacağı bilgisayarların ekran çözünürlüğü, hafıza miktarı, disk kapasitesi gibi bilgilerde bulunmalıdır. Kullanılacak üçüncü parti yazılımların tüm ayrıntıları belirtilmelidir. Örneğin projenin hayata geçebilmesi için bir Web sunucu gerekiyorsa tüm ayrıntıları ile gerekli herşey açıklanmalı ve desteği istenen teknolojiler tanımlanmalıdır. Örneğin PHP desteği isteniyorsa Web sunucunun bu desteği verebilmesi veya bir ISAPI dll yardımı ile eklenebilir türden olması gerekir. İşletim sistemleri ve gerekli parçalarının tanımlanması gerekir. Örneğin projeniz Windows XP service Pack1 ile gelen winhttp.dll dosyasını kullanıyorsa ürünün kurulduğu test ve kullanım ortamlarında bu öngereksinimin olmasına dikkat edilmelidir. Satın alınması gereken yazılımların yapması gereken işlerde burada tanımlanır. Eğer mümkünse firmaların adresleri, telefonları veya örütbağ adresleri ile kontak kurulacak kişilerin listesi burada yapılır. Yazılan projenin mevcut projeleri etkileyip etkilemediği ve ne gibi değişikliklere yol açacağı da burada bir çözüme kavuşturulur. Sistemin arayüzleri belirlenerek dış sistemler ile nasıl haberleşeceği ve giriş/çıkış verilerinin neler olacağı tanımlanarak dış sistemlerin bu gereksinimleri destekleyip desteklemediği araştırılır. Örneğin eğer yeni sistem, Sistem B ile konuşamıyorsa hizmet X müşteriye sunulamaz. Bu durumda test ve kullanıcı ortamlarında Sistem B’nin varlığından ve istediğimiz işi yaptığından emin olmalıyız. Eğer projeniz mevcut sistemler üzerinde değişiklik gerektiriyorsa bu değişimin içeriği ayrıntılı biçimde tanımlanmalıdır. Ürünün kullanıcı tarafından ne kadar zamanda öğrenilebileceği ve kolaylıkla hazmedilebilmesi için ne gibi geliştirmelerin yapılması gerektiği tanımlanmalıdır. Ürünün ağ kaynaklarını ne kadar kullanacağı ve günlük kaç işlemin gerçekleşeceği ve kaç kullanıcının ürünü kullanacağı bilgileri tanımlanmaya çalışılır. Kullanıcıların coğrafik olarak nerede olacakları ve ne şekilde ürünü kullanacakları belirtilir. Eğer güvenli bir biçimde korunması gereken bir veri üzerinde çalışılıyorsa, güvenlik sistemlerinin nasıl kullanılacağı, kullanıcı hakları ve kısıtlamaları, veri tabanına erişim ve ağ kaynaklarını kullanım hakları belirlenmelidir. Ürünün lisanlama işleyişi ve lisansların kontrolü belirtilmeli ve bunları kontrol edecek sistemler burada ortaya çıkartılmalıdır. Kurulum, kullanıcı yardım kılavuzları, ve her türlü kullanıcı belgesi bu belgede belirtilmelidir. Görülüyor ki analiz aşamasında, ileride koda dönüşmeyecek her türlü bilgi bu belge içinde toplanıyor ve tüm bu gereksinimler hem test ekibi için hemde yazılım geliştirme ekibi için bir temel yardım kaynağı oluyor. Bu belgenin ingilizce ismi Non-Functional Requirements’dır.

Edit

İş nesne modeli belgesi

Bir işi analiz ederken ortaya çıkan sınırlardan dışarıya her uzantıda farklı bir sistemin hizmetleri kullanılır. Analiz edilen iş kendi içinde de belli parçalara ayrılır. Her parçanın (nesne) bir arayüzü ve haberleşme için kullandığı mesajları vardır. İş Nesne Modeli, tüm iş nesneleri ve dışarıdan heberleşilen tüm nesneleri gösteren modele denir. Çok genel bir gösterim şeklidir ve veritabanı modeli ile yada sınıf şemaları ile karıştırılmaması gerekir. Görünüş olarak sınıf şemalarına benzer fakat sınıf isimleri firmanın bir bölümünü yada başka bir sistemin parçasının adı olur. Büyük sistemi kolayca görmek, dışarıya ne gibi mesajlar gidiyor ve ne gibi sistemler ile alış veriş içinde olduğumuz belirlemek için idealdir. İş Nesne Modeline giren her sistem ve/veya parçası yazılı olarak anlatılmalıdır. Bu şemaların bir UML aracı ile çizilmesi şarttır. Bu belgenin ingilizce ismi Business Object Model’dir.

Edit

Tool-Tip kayıt kütüğü belgesi

Tool-Tip’ler her hangi bir ekran nesnesi (text-box, buton, drop-down, liste kutusu) üzerine fare ile gelindiğinde yada durum barında (status bar) ortaya çıkan kısa yardımlardır. Kullanıcıyı sunulan bilgi, yada girilecek veri konusunda bilgilendirirler. Tüm Tool-Tip’lerin kayıt edilerek belgelendirilmesi gerekir. Her Tool-Tip bir numara verilerek kaydedilir. Bu belgenin ingilizce ismi Tool Tips Register’dır.

Edit

Mesaj kayıt kütüğü belgesi

İş kurallarına göre kullanıcının girdiği verinin kontrolü ve sonrasında çıkacak mesajları kapsar. Mesajlar Bilgilendirme, Uyarı, Hata (Informational, Warning, Error) olarak üçe ayrılır ve her hatanın bir numarası olmalıdır. Örneğin bir programda iş kuralına göre 8 karakterden az şifreye izin verilmiyordur fakat kullanıcı şifresini tanımlarken 5 karakter girmiştir. Butona bastığında iş kuralına göre girilen şifre kontrol edilir ve kriterlere uymadığı saptanır, ve kullanıcıya bir hata mesajı ile bilgilendirme yapılır. Bu mesajda kullanıcıdan en az 8 karakter girmesi istenir. Mesajda ki tamam tuşuna basınca girilen şifre silinerek boşaltılır ve imleç şifre kutusuna konumlanarak yeni şifre girişi için beklemeye geçer. İşte tüm bu işlemler öncesi ve sonrasıyla belgelendirilmelidir. Bu belgenin ingilizce ismi Message Register’dır.

Edit

Kullanıcı arayüzü gereksinimleri ve dizaynı belgesi

Tüm yukardaki belgeler ilk sürümlerini verdiğinde Kullanıcı Arayüzlerini planlamaya geçebiliriz. Kullanıcı Grubu toplantılarında İş Senaryolarına göre adım adım gidilerek sunumu ve girişi yapılacak verinin düzeni ortaya çıkartılır. Ekranlarda neler isteniyor, düzeni nasıl olmalı gibi problemlerin kullanıcı tarafından önerilmesi ve tartışılması gerekir. Ekran akışları ve standardı şemalar ile belirlenmelidir. Çok karmaşık sistemlerde mantıksal olarak sistemi bölerek ve her parçaya bir isim vererek işi kolaylaştırabiliriz. Böylece gelecekte yazacağımız modüllerde ortaya çıkar. Her ekran konrolünün (buton, text-box, liste kutusu) ismi, açıklaması, yaptığı iş, Tool-Tip numarası ve Mesaj numarası bu belgede yer almalıdır. Bu belge ilk sürümünü verirken ekran prototipleri geliştirilebilir. Kullanıcı Grubu Toplantılarında bu prototipler kullanılarak onay alınmaya çalışılır. Bu belgenin ingilizce ismi User Interface Requirements’dır.

Edit

Sistem modelleme aşaması

Edit

Uygulama mimarisi belgesi

Bu belge uygulama için önemli olan modülleri listeler ve özelliklerini anlatan belgelere bağlantılar verir. Aşağıdaki gibi bir tablo şeklinde olabilir.

İsim	Tip	Bağlantı
Hizmetin yada modülün genel ismi	Hizmet/Modül API Uygulama/RDBMS Diğer	Bu hizmet yada modülü anlatan belgeye bağlantı

Ayrıca her modülün sistemde hangi mimari katmana oturduğunu da gösterir. Ayrı bir başlık altında incelenir ve projede üretilen her modülün hangi katmanlarda yer aldığını ve diğer katmanlardaki modüller ile nasıl haberleştiğini gösterir.

Kurulum yapılacak yapıyıda burada belirtebiliriz. Ürünü kuracağımız donanım ve yazılım yapısını bir şema ile anlatmamız gerekir.

Bu şema kurulumun genel bir planını gösterir. Fazla ayrıntı verilmez. Kurulum yapılacak yapının ağ mimarisi genel olarak tanımlanır.

Ürünün parçalarının hangi platformlara kurulacağı hakkında da bilgi vermek gerekir. Modüllerin kimi parçaları veritabanı sunucusu üzerinde çalışıyorken, diğer bir parçası istemci tarafında hizmet veriyor olabilir. Dağınık sistemlerde her modül farklı bir sunucuda çalışıyor olabilir ve aralarındaki haberleşme için belli kanalları kullanıyor olabilirler. Tüm bu ayrıntıyı da Ağ Kurulumu başlığı altında bu belgeye dahil edebilirsiniz. Eğer standart dışı bir haberleşme protokolü kullanılacaksa bununda belirtilmesi gerekir. Bu belgenin ingilizce ismi Application Architecture’dır.

Edit

Harici arayüz gereksinimleri belgesi

Geliştirdiğimiz sistem ile dış sistemler arasındaki haberleşmeleri ele alan bir belgedir. Giriş/Çıkış verilerini, mesajları ve verinin düzenini belirler. Dış sistemler senaryo şemalarında AKTÖR olarak belirirler. Öncelikle kendi ürettiğimiz arayüzü ve bağlantı kuracağımız dış sistemin arayüzünü tanımlayarak işe başlamamız gerekir. Bağlantı kuracağımız arayüzden hangi hizmetleri kullanacaksak bunları da ayrıntılı belirtmemiz gerekir. Eğer bağlantı kurmak istediğimiz dış sistemde bizim istediğimiz hizmetler yok ise bu hizmetleri ayrıntılı biçimde yazarak istememiz gerekir. Bu belgenin ingilizce ismi External Interface Requirements’dır

Edit

Veritabanı dizayn belgesi

Bu belge geliştirilecek ürünün veritabanı hakkında ayrıntılı bilgi içerir. Her tablo ve saha açıklamaları ile beraber yazılır. Kullanılacak Stored-Procedure ve SQL programcıkları yazılır ve test edilir. Bir Entity Relationship Şeması ile tablolar arasındaki ilişkiler gösterilir. Veritabanının uygulanacağı sisteme özel durumlar varsa bunlarda belirtilir. Anahtar sahalar, tabloların büyüme hızı, öngörülen işlem kapasiteleri ve tahmini kayıt kapasiteleri belirtilmelidir. Belgenin ilk sürümden sonra değişiklik istenirse tüm kontrol Veritabanı Yöneticilerine bırakılır. Bu belgenin ingilizce ismi Database Design’dır.

Edit

Hizmet modeli belgesi

Her modülün sunduğu çeşitli hizmetler vardır. Mesela aritmetik modülü isminde bir modülümiz olsun. Bu modülün sunduğu hizmetler Toplama(), Çıkarma(), Çarpma() ve Bölme() olsun. Siz Muhasebe modülünü yazarken Aritmetik modülünün sunduğu bu hizmetleri kullanacaksınız, bu hizmetleri oturup tekrar yazmaya gerek yoktur. Her hizmetin bir giriş verisi ve çıkış verisi ile hata durumlarında üreteceği mesajları vardır. Hizmetler o modülün arayüzünü oluştururlar ve dış dünya ile bağlantı kuracağı kapılarıdır. Herhangi bir sistem yada kullanıcı bu hizmetleri kullanarak modül ile haberleşir ve istediği işleri yaptırmaya çalışır. Bu arada veritabanı ile ilgili işlemleride gerçekleştiriyor olabilir. Aritmetik modülü, yapılan her işlemin kaydını ve kimin yaptığını veritabanında saklayabilir.

Bir modülün arayüzüne ait tüm hizmetlerin genel olarak anlatıldığı belgeye Hizmet Modeli denir. Tüm hizmetler bir tablo içinde sıralanır ve kendi operasyon belgelerine bağlantılar verilir. Bu belgenin ingilizce ismi Service Model’dir.

Edit

Nesne devamlılığı belgesi

Bu belge proje içinde varolan nesnelerin ne tür biçimlere dönüştüğünü gösterir. Örneğin bir sınıf nesnesi bir veritabanı tablosuna yada XML belgesine dönüşebilir. Modelleme sırasında ortaya çıkan sınıf kütüphaneleri yada modüller ve modüllere ait hizmetler, veritabanı tabloları veya XML belgeleri ile karşılaştırmalı tablolar halinde üretilmelidir. Bu belgenin ingilizce ismi Object Persistence Document’tir.

Edit

Hizmet operasyon belgesi

Bir modül arayüzü veya sınıf içerisinde hizmet olarak bulunan fonksiyonların giriş, çıkış ve hata mesajları ile tüm algoritmasının anlatıldığı belgedir. Çözüm getirilen Senaryolara, gerçeklenen iş kurallarına bağlantı verilir. Yani tekrar tekrar yazmak yerine iş kuralı yada senaryo belgesinin yeri ve sayfa numarası belirtilir. Giriş ve çıkış verileri formatları ile beraber verilir. Hata durumlarında üretilecek mesajlar belirtilir. Bu belgenin ingilizce ismi Service Operation Document’tir.

Edit

Prototipleme aşaması

Tüm bu belge üretimi devam ederken ekran prototipleri de dizayn edilir ve kullanıcı grubu toplantılarında onaya sunulur. Toplantılar sonucunda ekranlar değişikliğe uğrayacaktır. Kullanıcının aktif katılımı ile sunumu yapılacak verinin düzeni belirlenir. Prototipler Visio gibi bir programlama yapılabileceği gibi yazılım geliştirme için kullanacağınız araç ile de yapılabilir. Hem böylece elinizde yazılım sürecinde kullanabileceğiniz hazir temalar olmuş olur.

Edit

Örnek Proje ile OO ve UML

Bu bölümde UML ile adım adım bir projenin nasıl uygulanacağını analiz aşamasından başlayarak test işlemlerine kadar ele alacağız. Örnek firma olarak kullanacağımız firma bir personel taşıma firması. Bünyesinde barındırdığı minibüs, otobüs gibi araçlar ile personeli evinden işine, işinden evine; belli güzergahlar içerisinde taşıyan bir yapıya sahip. Ayrıca kişilerin özel olarak araç kiralamak istediği durumlarda da yardımcı olmakta. Firmamızın ismi AntTur olsun. Bu arada yazılım firmamızın ismide BİG Yazılım olsun. Üç arkadaşın baş harfleri. Projeye kısa olarak ATOS diyelim (AntTur Otomasyon Sistemi).

AntTur’un sahibi Ahmet Bey bize gelerek, bünyesinde çalışan araçların kayıtlarını tutmak, hangi firmaların servislerini çektiğini görmek, hangi güzergahlardan gittiğini, ne kadar benzin ve yol masrafı yaptığını, boşta olan araçların listelerini görmek gibi bir dizi işlemi otomatize etmek istediğini belirtti. Ayrıca müşteri ile firma arasındaki ilişkileri daha yakın tutmak için düşündüğü bir dizi yeni işlemi de kullanıma örütbağ üzerinden açmak istediğini belirtti. Bunun için piyasada hazır bir program bulamadığını ve bu projeyi yapıp yapamayacağımızı sordu. Tabii ki bizde üstesinden gelebileceğimizi söyleyip bu işi aldık. BİG Yazılım ve Ahmet Bey arasında geçen ilk toplantıda müşteri istekleri kaba taslak ortaya çıkmıştı. Yapılacak iş mevcut isteklerin detaylandırılıp, müşteriye düşünmesi için zaman tanımak ve yeni isteklerin ortaya çıkmasına zemin hazırlamaktır.

BİG Yazılımdan İlker Bey, bu projeye atanmış ve proje yöneticisi olarak görevine başlamıştır. İlker Bey ilk olarak 2 ayını Ahmet Bey’in ofisinde geçirecek ve personel taşıma işini analiz edecek, problemlerin ne kadarının bir bilgisayar programı ile çözülebileceğini araştıracaktır. Her hafta sonunda yönetim kuruluna yada bağlı olduğu birime rapor vererek analizin ne aşamada olduğunu, daha fazla zamana ihtiyacı olup olmadığını, ortaya çıkan müşteri ihtiyaçlarının bir listesini ve bu ihtiyaçların çözülebilirlik derecelerini de raporunda belirtecektir. İlker Bey aynı zamanda Sistem Modelleme ve Analiz konularında firmadaki en yetkili kişidir ve UML ve OO hakkında firma içi eğitimleri yönetmektedir. İlk raporda yer alacak iş senaryoları “Genel Senaryolar” olacaktır. Bu genel senaryolar oluşturulacak sistemin yapısını ana hatları ile ortaya koyar. Başka bir deyişle müşteri isteklerinin, analizci gözü ile nasıl çözüme kavuşturulacağını ortaya koyar. Analiz aşamasında senaryolar 3 aşamada incelenir ve sırası ile detaylandırılarak oluşturulur.

1. Genel Senaryolar
2. Müşteri Hedefleri
3. Detay Fonksiyonlar

Edit

Senaryolar (Use Cases)

Burada UML’in ingilizce kelimelerinden biraz bahsedelim. Bu kitapta bahsettiğim “senaryo” terimi UML’de adı geçen “Use Case”’dir. Genel Senaryolar dediğimiz ise “Summary” olarak adlandırılır. Müşteri Hedefleri “User Goal” ve Detay Fonksiyonlar’da “Sub-function” olarak geçer. Bu terimlerin açıklamalarını ileride göreceğiz. Kavramların hepsini birden aynı anda vermektense yeri geldikçe örnekler ile açıklamak, konunun anlaşılması için daha iyi olacaktır sanırım.

İlker Bey ilk haftalık çalışmasından sonra müşteri isteklerini hemen hemen ortaya çıkarmış ve başlıklar halinde belirlemiştir. Sürekli müşteri tarafında işin içerisinde bulunmuş ve işi analiz etmeye çalışmıştır. Çıkardığı sonuçları Ahmet Bey ile paylaşmış ve gerçekten bu problemlere çözüm arayıp aramadığını sorgulamıştır. Ahmet Bey çıkartılan her sonuçtan haberdardır. Yavaş yavaş müşteri istekleri ortaya çıkmış ve bu isteklere bilgisayar ortamında çözüm aranmaya başlanmıştır. İlker Bey burada ortaya çıkartılan senaryoları daha sonra yazılım ekibine aktaracaktır.

Şimdi İlker Bey’in ilk hafta sonunda Yönetim Kuruluna verdiği rapora bir göz atalım. İlk raporda yer alacak genel senaryo başlıklarına dikkat ediniz. Bu genel senaryolar yönetim kuruluna konu hakkında bilgi verecek ve planlama aşamalarında yardımcı olacaktır.


Bu raporda dikkat edilmesi gereken konulara bir bakalım. Öncelikle İlker Bey ve Yönetim kurulu arasındaki bilgi akışı çok üst seviyede ve detay bilgi barındırmıyor. Böylelikle Yönetim Kurulu üyeleri işin devam ettiğini ve ana hatları ile konunun ne olduğunu biliyorlar, zaten daha da fazla bilgiye ihtiyaçları yok. Personel Taşıma işi konusunda ve bu iş içerisinde kullanılan deyimler hakkında da bilgi sahibi oluyorlar (servis çekme). Projenin “İş Senaryoları Detaylandırma” safhasına geldiğinide görüyorlar. Bundan sonra Yönetim Kurulu’nun tek ihtiyacı yüzde rakamlarıdır. Proje yüzde kaç bitti, finansmanın yüzde kaçı harcandı, yazılımcılar yüzde kaç işlerini bitirdi vs gibi.

İlker Bey konumu itibarı ile Ant Tur ile BİG Yazılım arasındaki köprü görevini görür ve bilgi akışını sağlar. Buradaki iletişim ne kadar akışkan ve güçlü olursa daha sonra ileride çıkacak aksaklıkların çoğu önlenmiş olur.

Son paragrafta Ahmet Bey’in genel senaryoları test ettiğinden bahsediliyor. Evet Ahmet Bey çıkartılan bu senaryolardan haberdardır ve hepsini okuyarak doğruluğunu kabul etmiştir. Böylece her senaryonun büyük sistem içerisindeki güvenliği arttırılmıştır. Yani senaryolardan hepsi gerçekten müşterinin çözüm aradığı konulardır, boşuna ürettiğimiz bir senaryo yoktur.

Burada eXtreme Programing’den bahsedelim. Bu metodolojide her aşamadan sonra bir test yer alır. Amaç ürün ortaya çıkartıldığında hiç bir hatanın (veya en az hatanın) olmamasıdır. Testler projede payı olan herkes tarafından yapılır. Müşteri, sistem analist, proje lideri, yönetim kurulu, programcılar, test ekibi, destek ekibi vb projeye en ufak bir katkısı olan kişi test işlemlerinde yer almalıdır. Tabii ki her biri farklı testler yapacak ve ortaya çıkacak ürünün hatasız ve isteklere tam cevap verecek bir ürün olmasına dikkat edeceklerdir. Ayrıca standartlara uyulup uyulmadığını da test edeceklerdir.

İlker Bey’in bu ilk raporundan sonra yapacağı iş Genel Senaryolar’ı yazmak olacaktır. Bu işlem gene müşteri tarafında ve belli standartlara göre yapılacaktır.

Bu arada kağıt israfını önlemek ve ağaçları korumak amaçlı olarak, üretilen hiçbir belge yazıcıdan basılmaz, ve hiç bir yere kağıda basılı biçimde taşınmaz. Zaten kağıda basılmış belgelerin sürüm kontrolü çok güç olur. Bir toplantıya girdiğinizde her kesin en son sürüm belgelere sahip olması gerekir. Bu da ancak belgeleri sayısal ortamda tutmak ile mümkün olur. Ahmet Bey’in, Yönetim Kurulunun, İlker Bey’in ve yazılım uzmanlarının birer bilgisayarı olduğuna göre ve hepside e-mektup kullanabildiğine göre belgeleri kağıda basmak pek iyi bir uygulama değildir.

Senaryolar yazılırken dikkat edilecek pek çok konu var. Öncelikle senaryoların BİG Yazılım içinde belli bir biçimi olmalıdır. Oluşturulacak şablon Word belgeleri ile bu problem rahatça çözülür. Ayrıca bu senaryoların hepsi belli bir dizin altında toplanmalı ve herkesin kolayca ulaşabileceği bir yerde durmalıdır. Belli zaman aralıklarında yedeğinin alınmasıda gereklidir. Şablonun nasıl doldurulacağı bilgiside şablon içinde bulunmalıdır.

Projeye verdiğimiz kısa isim gibi (ATOS) senaryolara da bir kısa isim verelim (SN). Her senaryonun bir ismi ve numarası olmalıdır. Firma içindeki kültür ve bilgi akışı bu koyulan kurallar sayesinde herkesin anlayabileceği bir seviyeye gelmiş olmaktadır. Eğer firmanız UML ve CBD gibi kavramları kullanmaya başlayacaksa, öncelikle eğitim için vakit ve nakit harcayıp her çalışanın aynı seviyede bilgiye sahip olmasına özen gösterin. Firma içindeki iletişimin aynı iletişim kanalları ve sistemleri kullanılarak yapılması, üretkenliği müsbet biçimde etkiler. Her şeyin belli bir standartta olması ve herkesin bu standartları bilmesi haberleşmeyi akışkan kılar.

Burada biraz durup önemli bir konudan bahsetmek istiyorum. Firmanızda yeni çalışmaya başlayacak kişilere ne gibi işlemler uyguluyorsunuz. Firmanızın belli bir düzeni var mı? Firmanızda kullandığınız her ürünün bir eğitim kitapçığı vb. var mı? Firmanızda uyulması gereken kuralları anlatan bir dosyanız var mı? İçörütbağınızda projeler ve eğitim ile ilgili yeterli miktarda bilgi mevcut mu? Yeni kişilere yeterli eğitimi veriyor musunuz? Eğer bu sorulara samimi olarak evet cevabı verebiliyorsanız, yolun yarısını katetmiş oluyorsunuz. Diğer yarısıda mevcut bilgiyi güncel tutmaktan geçiyor.

Yukarıda bahsettiğimiz 3 çeşit senaryo modelinin ana şablonuna bir göz atalım. Bu senaryo İlker Bey’in ilk raporunda geçen ilk maddenin yazılmış halidir.


Buradaki dizayn sadece bir öneridir ve kendi isteğinize göre şablonu değiştirebilir, gerekliliklere göre yeni sahalar ekleyebilir ve Word şablonlarına “header, footer” ekleyerek firmanızın ismini, logonuzu, belgenin sürüm bilgilerini, sayfa numaralarını, belgenin bulunduğu dizini, en son üzerinde çalışan kişi vb. gibi bilgileride koyabilirsiniz. Hatta bir veritabanı hazırlayıp bu bilgileri tutacak bir program hazırlamak ta mümkün, önemli olan ne kadar zamanınız ve naktiniz var? Senaryoda adı geçen alanlara bir bakalım.

Edit

Senaryo başlığı

Senaryo başlığı proje ismi ve senaryonun kısaltılmış hali ile senaryonun numarasından ve isminden oluşur. Ek olarak en sona sürüm numarasınıda ekleyebilirsiniz fakat çokta gerekli değildir.Yani:
proje ismi + SN + senaryo numarası + Senaryo ismi + (sürüm no)
Örneğimizde “ATOS.SN1 Araç Yönetimi” senaryo başlığıdır. Proje ismi ve SN1 nokta işareti ile birbirinden ayrılmıştır.

Edit

SN#

Senaryonun numarasını tutar. Her senaryoya birden başlayarak bir numara vermek gerekir.

Edit

SN isim

Senaryonun ismi burada belirtilir. Açıklayıcı bir kelimeyi takiben bir fiilden oluşur. Birincil Aktörün yapmak istediği işi belirtir. Örneğin “Yeni Müşteri Oluşturma”, “Araç Yönetimi” vs.

Edit

Kapsam

Senaryonun kapsamı belirtilir. Kapsam ileride ortaya çıkacak modüllerin (component) isimleri olarak düşünülebilir. Örneğimizden anlaşılacağı üzere dizayn aşamasına geçtiğimiz zaman “Araç” isminde bir modülümüz olacaktır. Kapsamlar, üzerinde tartışılan sistemlerde olabilir (İş Süreci, Sistem, Alt-Sistem). Bu üç sistem için oluşturulan Senaryo’ları Şeffaf-Kutu (white-box), yada Kara-Kutu (black-box) olarak tanımlamamızda gerekir. Şeffaf-kutu olan senaryoların girdi ve çıktı’ları ile içinde geçen tüm işlemler ve veri yapısı tamamen Aktör’ler tarafından bilinir. Öbür taraftan Kara-Kutu senaryolarının sadece girdileri ve çıktıları bilinir. Bu konuyu Modül-Tabanlı Geliştirme konusunda daha ayrıntılı anlatacağım. Henüz modüllerimizi kodlayıp, kullanıma sunmadığımız için sadece bu kadar bilmemiz yeterlidir.

Edit

Hedef seviye

Hedef Seviye, senaryonun 3 aşamalı senaryolandırma sınıflarından hangisine ait olduğunu söyler (Genel Senaryolar, Müşteri Hedefleri, Detay Fonksiyonlar). Senaryoları bu şekilde sınıflandırmanın amacı, analizin belli bir düzen içerisinde olmasını sağlamak içindir. Konu hakkında genel bilgi sahibi olmak isteyen yönetici ekibi sadece Genel Senaryo sınıfındaki senaryoları okuyarak işin ne olduğunu kavrayabilirler. Genel Senaryolar, sistemi tanımlayıcı 3 ana görevi yerine getirir.

1. Büyük sistem içerisinde Müşteri Hedeflerinin nereye oturduğunu gösterir
2. Müşteri Hedeflerinin hayat döngülerini belirtir
3. Bir kitabın içindekiler bölümü gibi daha alt seviye senaryoların başlıklarını belirtir

Müşteri Hedefleri ise gerçekte birincil aktörlerin yapmak istedikleri işleri belirtir. Müşteri Hedefi olan bir senaryo “Aktör bu senaryoyu uyguladıktan sonra sistemden mutlu bir şekilde ayrılacak mı?” sorusuna “Evet” yanıtını vermeye çalışmaktadır.

Detay Fonksiyonlar, Müşteri Hedeflerinin yerine getirilmesi için atılacak adımları belirler. Detay fonksiyonları sadece gerçekten ihtiyacınız varsa ekleyin. Örneğin “Sisteme Oturum Aç”, “Ürün bul”, “Müşteri bul” gibi işlemler birer detay fonksiyondur.

Edit

Aktörler

Aktör, senaryo ile ilişkili olan veya senaryoyu kullanan kişi veya sistemdir. Unutmayın bir senaryoyu başka bir sistemde kullanabilir. Her senaryo için en azından bir adet birincil aktör olmalıdır. Eğer senaryoyu kullanan başka aktörler de varsa onlarıda sıralamak gerekir.

Edit

Hedef

Senaryonun hedefini belirtir. Sadece, senaryo ile yapılması amaçlanan iş anlatılır. Senaryo NE işe yarar sorusuna cevap verir. Bir paragraftan fazla olmamalı ve senaryoyu okuyan kişiye genel bir bilgi vermelidir. Detay bilgi barındırmaz.

Edit

Amaç

Senaryonun sistemde NEREYE oturduğunu söyler. Bir işi veya sistemi analiz ederken, o sistemi parçalara bölmek ve küçük parçalar halinde ele almak bize zaman kazandırır. Bu açıdan bakıldığında her senaryo büyük sistemin bir parçasıdır ve genelde diğer senaryolar ile ilişki içerisindedir. Ayrıca “Amaç” senaryonun sistem için NEDEN önemli olduğunu da söyler.

Edit

Olgunluk

Olgunluk senaryonun hangi süreçte olduğunu gösterir. Renkler ile kodlama UML diline oturmuş bir gösterim biçimidir.

1. Kırmızı, İş süreci senaryosu tanımlanır fakat henüz detaylandırılmamıştır.
2. Turuncu, Senaryonun iş akışı şekillenmeye başlar ve sorular bölümünde sorular belirmiştir. Turuncu seviyesi biraz uzun sürdüğü için Turuncu1 Turuncu2... biçiminde çoğaltılabilir.
3. Sarı, Senaryo, kontrol mekanizmaları için yayınlanabilir bir hale gelmiştir. Senaryonun bitirilebilmesi için temel adımlar ortaya çıkarılmış ve alternatif adımlardan önemli olanlar tamamen genişletilmiştir. Ayrıca senaryonun büyük sistem içerisindeki durumuda güvenli bir hale gelmiştir (Gerçekten sistemin bu senaryoya olan ihtiyacı ortaya çıkartılmıştır).
4. Yeşil, Senaryo bir sonraki süreç için hazırdır, fakat henüz onaylanmamıştır. Şablondaki tüm sahalar doldurulmuş ve Soru kısmında hiç bir soru kalmamıştır.
5. Mavi, Senaryo onaylanmış ve bitmiştir. Son Gereksinim Modeli’nde yerini alır.
6. Gümüş, Senaryo başka bir projede yeniden kullanılmıştır. Küçük değişiklikler yapılmış olabilir.
7. Altın, Senaryo birden fazla başka projede değişiklik yapılmadan kullanılmıştır.

Edit

Varsayımlar

Senaryonun çalışabilmesi için oluşacak varsayımları burada listeleriz. Her zaman karşımıza çıkmasada bazı durumlarda gerekli olabilmektedir.

Edit

Sorular

Senaryonun tamamlanabilmesi için ortaya çıkması gereken konuların sorulduğu bölümdür. Yeşil konumuna gelmiş bir senaryonun Sorular kısmında hiç bir soru olmaması gerekir.

Edit

Ön durumlar

Senaryonun işlemeye başlayabilmesi için gerekli ön durumları belirtir. Ön durumlar gerçeklenmeden senaryo işleme başlayamaz. Numaralı bir liste şeklinde ve hiyerarşik bir yapıda olması gerekir.

Edit

Başarılı bitiş durumları

Senaryo bittikten sonra, sistemin alacağı durumdur. Ana iş akışı sonunda yada Alternatif iş akışları sonucunda oluşacak her türlü başarılı bitiş durumu burada numaralı liste biçiminde not edilir.

Edit

Minimum bitiş durumu

Minimum bitiş durumları, senaryonun bitiş durumu ne olursa olsun (başarılı yada başarısız) her zaman doğru olacak durumlardır. Örnek olarak bir senaryo başarılı veya başarısız biçimde sonlanırsa, senaryonun çalıştırıldığına dair sonuç kütüklerine bir kayıt eklenir. Kütüklere kayıt ekleme işlemi her iki durumda da geçerlidir.

Edit

Tetikleyici (seçmeli)

Tetikleyici bu senaryonun işlenmesini başlatan olaydır. Bazen senaryonun ilk adımı tetikleyici adım olabilir. O zaman burada tekrar etmenin gereği yok. Fakat tetikleyici olaylar birden fazla ise burada listelemek iyi olur.

Edit

Ana iş akışı

Senaryonun hedefine ulaşabilmesi için gerekli adımların sıralanması ile oluşturulur. Bu akış aktör ile sistem arasında geçen konuşmadır. Senaryonun akışı ön koşullardan sonlanma koşullarına doğru olmalıdır. Her hangi bir hata durumunu barındırmaz. Her türlü ön koşulun ve tahmin edilemez hataların ortaya çıkmayacağı var sayılır.

Her adım için:

1. Bir hedefin başarıldığını gösterin
2. Aktörün nasıl tepki verdiğini yakalamaya çalışın, kullanıcı arayüzünü değil.
3. Her adım bir aktör ile başlar (Aktör şu işlemi yapar, Sistem şu bilgiyi gönderir)
4. Aktörlerin isimleri ile kullanılmasına özen gösterin, çünkü aynı işi yapan birden fazla aktör olabilir.

Edit

Alternatif iş akışları

Ana iş akışında belirli durumlara göre sapmalar olabilir veya parametrik yapılarda işlemler parametrelere göre değişebilir veya senaryodaki problemin başka bir çözüm yolu olabilir. Buna göre alternatif çözüm yollarını ve hata durumlarındaki senaryonun vereceği yanıtı bu kısımda ele alıyoruz. Buradaki numaralı listeye bir bakalım. Diyelimki 3 adımdan oluşan bir ana iş akışınız var. Birinci adım için 2 adet alternatif çözümünüz olsun. İlk çözümü 1a olarak isimlendireceğiz. İkinciyi de 1b. Alternatif çözümlerin adımlarına 1a1, 1a2 de diyebiliriz fakat çok fazla karıştırmamak için baştaki adım numarasını düşürüyoruz.
1a. Ana akışın 1. adımına alternatif olabilecek 1. durum
a1. Adım 1
a2. Adım 2
1b. Ana akışın 1. adımına alternatif olabilecek 2. durum
b1. Adım 1
b2. Adım 2
3a. Ana akışın 3. adımına alternatif olabilecek 1. durum
a1. Adım 1
a2. Adım 2


Evet yukarıdan da anlaşıldığı gibi üçüncü adım içinde bir adet alternatif çözümümüz mevcut.

Edit

İş kuralları

Burada senaryo uygulanırken dikkat edilmesi gereken iş kurallarını listeliyoruz. Listelenen iş kuralları zaman içerisinde değişebilir. Tüm senaryolar kırmızıdan maviye doğru yol alırken iş kuralları da kendi içinde değişir ve gelişir. Senaryolar mavi olduktan sonra iş kurallarının tümü tek bir dosyada toplanır ve senaryolardan çıkartılır. Senaryolar maviden sonra sadece iş kuralı dosyasına bir referans numarası tutarlar. Genelde iş kuralının numarası referans amaçlı kullanılır.

İş kuralları 2 türlüdür. Birincisi, doğrulanmaması sonucu senaryoyu bitiren kurallar. Bunlar doğrulanması zorunlu kurallardır. İkincisi, doğrulanmaması sonucu senaryo işlemeye devam eder fakat aktör bu konuda bilgilendirilir. Bu tür iş kurallarıda seçmeli iş kurallarıdır. İş kuralları tesbit edilirken seçmeli mi yoksa zorunlu mu olduğu belirtilmelidir.

Edit

Notlar

Tüm bu sahalardan herhangi birine girmeyen ve senaryoyu ilgilendiren her türlü bilgi bu alana yazılır.

Edit

İlişkili diyagramlar

Senaryonun daha iyi anlaşılabilmesi için bir aktivite diyagramı veya veri akışı diyagramı bu alana eklenebilir. Yeri geldikçe bu diyagramları açıklayacağım.

Senaryo belge şablonlarını tıkızda bulabilirsiniz. Unutmayın farklı projeler veya firmalar için farklı şablonlar gerekebilir. Gereksinimlerinize göre şablonları değiştirmekten kaçınmayın. Tüm firma içinde aynı şablonu kullanmak iletişimin hızlı olabilmesi için daha sağlıklıdır. Firmadan firmaya şablon değişebilir ama firma içindeki projelerde kullanılan senaryo şablonları aynı olmalıdır.

Buraya kadar bir senaryonun nasıl ortaya çıktığını ve geliştirildiğini ele aldık. Şimdi senaryolarda adı geçen aktör terimini inceleyelim.

Edit

Aktör

Aktör sistemle senaryolar yolu ile ilişkide bulunan birimdir. Aktör genel bir terimdir ve senaryolar içinde kullanabilmek için öncelikle bir sıfat kazandırılması gerekir. Örneğin “Son Kullanıcı” bir aktördür. Senaryoyu kullanacak olan birim bir grup insan da olabilir örneğin “Muhasebe Bölümü” muhasebe ile ilgili senaryoları kullanacak bir grup insanı simgeler. Aktörler başka bir program veya sistem de olabilir. Örneğin EFT modülü sizin yazdığınız “Müşteri Bul” senaryosunu kullanmak isteyebilir. “Müşteri Bul” aynı zamanda “Muhasebe Bölümü” tarafından da kullanılıyor olabilir. Aktöre verdiğimiz sıfat UML dilinde “stereotype” olarak bilinir ve aktörün UML gösterimi “Cin Ali” şeklindedir. Her UML nesnesinin bir stereotype’ı vardır. Sırası geldikçe bunları göreceğiz. Aktör eğer bir sistemi temsil ediyorsa sıfatı sistemin ismi olacaktır.

İngilizce terimleri veriyorum fakat bunları kullanmayın, maalesef UML modelleme programlarında mecburen kullanacaksınız fakat Türkçe ne demek istediğini çok iyi bilmeniz gerekiyor.

Burada senaryo olarak bahsedilen analiz sistemi “Use-Case” olarak bilinir ve UML modellemede “Use-Case Diagram” olarak şekillendirilir. Senaryo şemaları, aktör ve senaryolar arasındaki ilişkiler ile senaryoların kendi aralarındaki ilişkilerini gösterir.

Edit

Sınıf şemaları

UML’in en fazla kullanılan ve doğrudan yazılım ile ilgili olduğu için yazılım mühendislerinin en iyi bildiği şema tipidir. Class olarak isimlendirilmesinin sebebi belli aynı özelliklere sahip veri ve fonksiyonların bir çatı altına toplanmasından kaynaklanıyor. Kafanızda bir model oluşturması açısından bir kaç örnek vereyim.

Bir ilkokul sınıfı düşünün. Boş bir oda, sıralar, karatahta gibi şeyler içinde mevcut. Bu, sınıfı tanımlayan genel bir anlatım ve ilkokul sınıfının “class” durumunu gösterir. İlk ders ile birlikte öğrenciler sınıfa doluşur ve öğretmen eğitime başlar. Sınıf artık “class” durumundan “object (nesne)” durumuna geçmiştir. Öğrenciler sınıfın sahalarıdır (fields). Öğretmen sınıfın bir fonksiyonudur ve öğretme fonksiyonunu gerçekleştirir. Öğretme fonksiyonu içinde öğrencilerin öğrendikleri bilgiler değişir ve gelişir. Bu arada ilk ders ile beraber sınıfta bir isim kazanmıştır, örneğin “3. sınıf” ve nesne haline gelmiştir. Bu sınıfın üç tür durumu var. Bunlar “derste”, “tenefüste” veya “tatilde”. Ayrıca derste ise hangi derste olduğunu gösterecek bir de göstergesi var, örneğin matematik, hayat bilgisi gibi. Ders günü sonunda 3. sınıfta ortadan kalkar ve tekrar boş bir oda haline gelir. Yani hafızadan silinir fakat kodu hala elinizdedir yada şeması.

Boş bir oda hali sınıfın şemasıdır. Öğrencilerin nereye oturacağı öğretmenin nerede duracağı ve işlenecek derslerin haftalık programının belirtildiği tablo sınıfın planını oluşturur. Öğrenciler sınıfın alanlarıdır. Yani veriyi tutan değişkenleri. Öğretmen ise sınıfın yegâne fonksiyonudur. Öğretme işi ile sınıfın alanlarının barındırdığı bilgiyi yeniler veya yeni bilgiler ekler. İlk ders ile birlikte bu şema somut bir hal kazanır ve işlemeye başlar. İşte bu noktada nesne haline geçer. İlk tenefüs zili çalınca sınıfın durumu “tenefüste” olur ve öğretme fonksiyonunu yürüten öğretmen sınıfı tenefüse çıkarır ve öğretme işine ara verir. Son dersten sonra sınıfa son verilir.

Bir gün bir koro çalışması için bir kaç sınıfın tüm öğrencileri toplanarak bir çalışma yapmaya karar verirler. Tüm koro öğrencilerinin aynı zamanda kendi sınıfları vardır ve bu özel çalışma için bir araya gelmişlerdir. Sınıflarında öğrendikleri tüm disiplini ve bilgiyi beraberlerinde getirirler ve yeni bir sınıf oluştururlar. Yani kendi sınıflarında müzik dersinde öğrendikleri tüm bilgi ve deneyimlerini bu yeni koro sınıfı için kullanırlar, fakat matematik dersindeki bilgileri koro sınıfı için gereksiz olduğundan kullanmazlar. Kendi sınıflarında öğrendikleri bilgiyi bu koro sınıfına miras olarak getirirler. Burada farklı sınıfların bir araya gelmesi ile yeni bir sınıf kurulmuş ve farklı bir iş için uğraş vermektedirler. İlkokul bitipte ortaokul başladığında sınıfların tipleri değişir. Her ders için farklı öğretmeler gelmeye başlar. Yani bir sınıfın artık birden fazla fonksiyonu vardır. Sınıfın durumları değişmemiştir hala “tenefüste”, “derste” ve “tatilde” durumları vardır. İlkokuldan gelen bilgiler hala mevcuttur ve yenileri eklenmektedir. İlkokul bilgileri miras yolu ile gelmiştir fakat sınıfın yeri ve tipi değişmiştir. Her ders için farklı sınıflara gidiliyordur. Buda çoklu form (polymorphism) oluşturur. Farklı sınıflarda farklı davranışlar ile öğrenen öğrenci hala bir öğrencidir.

Sınıf (class), nesnenin planıdır. UML gösterimde sınıf aşağıdaki gibi gösterilir. 3 bölümden oluşur. İlk bölümde sınıfın ismi yer alır. İkinci bölümde sınıfın sahaları ve üçüncü bölümde de sınıfın fonksiyonları yer alır. Sınıf hafızada yer aldığı zaman artık bir nesne haline gelir.

Sınıfın alanlarını temsil eder. Sınıf kendi bünyesinde barındıracağı veriyi bu alanlarda saklar. Alanlar sınıfa özel (private), herkese açık (public), korumalı (protected), paket (package) olarak dört tip erişilebilirlik derecesine ayrılırlar. Kullanılan programlama diline göre başka tipleride olabilir. UML şemalarında aşağıdaki işaretler ile gösterilir.

1. + herkese açık
2. - sınıfa özel
3. ~ paket
4. # korumalı

UML modelleme programlama dilinden bağımsızdır fakat kullanacağınız dile göre değişikliklere izin verecek kadar esnektir. Kullandığınız programlama dilinin özelliklerine göre erişilebilirlik derecelerini ekleyip çıkartabilirsiniz. UML modelleme yazılımları, bir model için dil seçimi yaptığınızda o dilin özelliklerini kullanmanıza izin verir.

Modelleme sırasında ben yanlızca + ve – işaretlerini kullanıyorum. Diğer işaretler genelde modelleme sırasında ortaya çıkmıyor. Ancak analizler ilerleyip kodlamaya geçildiğinde iş kuralları ile birlikte yada ihtiyaca göre belirleniyorlar.

Edit

Alanlar (attributes)

Bir sınıfın özelliğidir. UML gösteriminde tavsiye edilen biçimi:

<tip (+ - ~ #)> <alan ismi>: <veri tipi> <array genişliği> = <ilk değeri> {<özellik, yazı ile>}

Bir örnek verecek olursak:

- Soyisim: string[1] = “Yeniceri” {readOnly}

İlk olarak (-) işareti ile bu alanın erişilebilirlik derecesini belirtiyoruz. Soyisim: bu alanın ismi yani sınıfın alana erişmek için kullanacağı belirteçtir. string alanın barındıracağı veri tipini belirtir. [1] alanın bu tip veriden kaç tane barındıracağını belirtir. “Yeniceri” alanın ilk tanımlandığında alacağı veridir. {readOnly} kısmı ek özellikleri tanımlamak için kullanılır. Yeri geldikçe bu özellikleri anlatacağım.

Edit

İlişkiler (associations)

İki sınıf arasındaki ilişkiyi belirlemek amacı ile oluşturulmuş bir alandır. Güncel hayattan bir örnek verelim. Sülale ve aile ilişkisinde soyisminiz sizin hangi sülaleye mensup olduğunuzu belirtir. Soyisimleri aynı olan Ahmet, Mehmet, Hüseyin evlenip kendi başlarına bir aile oluşturur. Soyisimleri aynı olan bu üç kişi sülalenin genetik mirasını barındırırlar ve yeni nesillere bunu aktarırlar. Soyisim burada ilişki belirten alandır. Soyisim hem ailenin bir alanıdır hemde sülalenin bir alanıdır. UML şemaları üzerinde çok farklı görünmesine rağmen ilişkiler ve alanlar aslında aynı şeydir.

İlişkilerin UML gösterim biçimi alanlar ile aynıdır. Şemalar da ise iki sınıf arasında ok biçiminde gösterilir. Okun gittiği yön hedef sınıftır. Hedef sınıf üzerindeki alanlardan bir tanesi, ilişkiyi tanımlamak açsısından esas sınıf üzerine gelir.

Yukarıdaki şemada Servis sınıfı üzerindeki AracPlaka sahasının tipine dikat edin. Tip olarak Arac sınıfı verilmiştir. Yani

Edit

İlişki Çeşitleri

Yukarıdaki şemada ilişkiyi Türkçeleştirerek okursak ortaya şöyle bir şey çıkar.

Soldan sağa: Her Servis pek çok araca sahip olabilir. Sağdan sola: Her Araç sadece bir serviste çalışabilir.

Her iki ilişkide de zorunluluk yok. Yani Araçlar ve Servisler kendi başlarına var olabilirler. Bu tür ilişkilere 1-To-Many yani “Bire Çoklu” ilişkiler denir.

Gelecek konular

Programda nasıl gözükecek

İki yönlü ilişkiler (bidirectional)

Fonksiyonlar (operations)

Genelleme (generalization)

Not ve Yorumlar

Bağımlılık (dependency)

Constraint kuralları

Desing by contract

Sorumluluklar

Statik fonksiyon ve alanlar

Aggregation and composition

Arayüzler

Edit

Sıralı işlem şemaları (sequence diagrams)

Her yazılım parçası bir kaç sınıftan oluşur. Her sınıfın kendi içinde belli servisleri olabileceği gibi tüm yazılım parçasının dışarıya sunduğu hizmetler de vardır. Bu tür hizmetler arayüzlerde toplanarak dış kullanıma açılır ve arayüzler vasıtası ile yazılım parçaları kendi aralarında haberleşir. Bir senaryo belgesine göre bir işin başarılabilmesi için farklı yazılım parçalarının sunduğu hizmetlerin belli bir sırada kullanılması gerekliliği vardır. Bu tür isteklere cevap verebilecek şema Sıralı İşlem Şemasıdır. Nesnelerin hayat süreçlerini görmek için iyi bir yöntemdir. Edit

Döngü ve durumsal işlemler

Edit

Senkron ve asenkron

CRC kartları

Edit

İşlem akış şemaları (collaboration diagrams)

Edit

Nesne şemaları (object diagrams)

Nesne şemaları bir işlem sırasında nesnelerin durumlarını gösterir. Sınıfın kendisini değil sınıftan oluşan nesneyi ele alır. Edit

Paket şemaları (package diagrams)

Sınıflar nesne yönelimli sistemlerin temel yapısını oluştururlar. Binlerce sınıftan oluşmuş çok büyük bir yapıyı ele aldığınızda sınıf şemalarının okunması zor olabilir. Paket şemaları ile sınıfları mantıksal olarak ayırarak gruplar ve okunmasını kolaylaştırırız. Sadece sınıfları değil tüm UML birimlerini paketlemek mümkündür. Paketleride başka paketler içinde gruplandırmak mümkündür. Analiz edilen sistemin karmaşıklığına bağlı olarak paketler çoğaltılabilir. Çözülmesi güç problemleri yada sistemleri farklı paketlere bölerek ufak ufak çözme yoluna gidebiliriz. Hem yapılacak iş daha net ortaya çıkar hemde büyük sistemin karmaşıklığı ile uğraşmamız oluruz. Ayrıca çözüme kavuşturduğumuz her ufak yapı taşı bize bir sonraki adım için motivasyon verecektir.

Paketleri .NET çerçevesi içinde isim alanları (namespace) olarak düşünebiliriz. Bu durumda paket içinde bulunan her sınıfın özel bir ismi olması zorunluluğu vardır.

Kurumsal bir uygulamayı paket şemaları ile kurgulayabilirsiniz. Sınıf şemalarından daha sade ve anlaşılabilir olacaktır.

Edit

İşlem durum şemaları (state machine diagrams)

Tek bir nesnenin ömrü boyunca gireceği durumları analiz etmek amaçlı geliştirilmiştir.

Edit

Aktivite şemaları (activity diagrams)

Okulda öğrendiğimiz Akış Şemalarına benzer. Tek fark olarak bunda paralel işlemleri şematik olarak gösterebiliriz.

Edit

İletişim şemaları (communication diagrams)

Sıralı işlem şemaları gibi sınıflar arası ilişkileri göstermek amaçlı oluşturulmuştur. Sıralı işlem şemalarında her işlem belli bir sıra içinde yer alır, fakat iletişim şemalarında sınıfları ve mesajları istediğiniz yere oturtabilirsiniz. Eski ismi “Collaboration Diagrams”’dır ve İşlem akış şemaları ile karıştırılmamalıdır. Edit

Modül şemaları (component diagrams)

Edit

Zamanlama şemaları (timing diagrams)

Edit

Kurulum ve yayımlama şemaları (deployment diagrams)

Kurulum ve yayınlama şemaları sistemin hangi parçalarının hangi donanım ve yazılım üzerinde çalışacağını göstermektedir. Donanım belli bir bilgisayar yada bir kart olabilir, yazılım donanımın etrafında sistemi yayınlamak amaçlı bir işletim sistemi yada uygulama sunucusu veya web sunucusu olabilir.

Edit

Modül-Tabanlı analiz ve geliştirme

Edit

Modül Nedir?

Modül (Petek) dışarıdan bağımsız olarak çalışan, daha büyük ölçekli modülleri oluşturmak amaçlı yada uygulamalarda kullanılmak amaçlı üretilmiş yazılım parçasıdır. Bir peteğin 3 aşamalı geliştirme evresi vardır. Bunlar:

1. Petek Tanımı – Peteğin davranışlarını tanımlar.
2. Petek Uygulaması – Petek tanımını gerçekleyen dizayn ve kod.
3. Petek Programı – Belli servislerin bir araya gelerek belli bir işi yapmak için oluşturdukları yapı.

Bir peteğin iç yapısı dışarıdan bağımsızdır. Yani tanımı ve uygulaması tektir. Aynı işleri yapan başka bir petek bulunmaz. Peteği kullanan yazılımı bozmadan peteğin uygulaması değiştirilebilir. Çünkü yazılım, peteğin sadece tanımını kullanıyordur. Bir petek şeffaf-kutu (Tanım ve Uygulama evreleri) yada kara-kutu (Tanım ve Program) olarak kullanıma sunulur. Bir peteğin yaptığı işler bir veya birden fazla, programlanabilir arayüz ile kullanılır.

Arayüz, ilişkili operasyonların gruplanmış halidir. Her operasyon kendi başına çağrılabilecek bir fonksiyonellik sunar. Arayüzler aksi belirtilmedikçe petekten bağımsızdır. Bir arayüz bir kaç petek tarafından kullanılabilir. Peteğin her operasyonu (servisi) şu özelliklere sahiptir: Servis Özelliklerini anlatan bir belgesi vardır. Davranışlarını ve nasıl çağırılacağını belirtir. Bir arayüzün üyesidir. Çalışıp sonlandığı zaman, bağlı olduğu peteğin veri yapısını ve özelliklerini bozmaz. Hata ile sonlansa bile yaptığı tüm işi geri alabilecek kapasitede olması gerekir. Yarıda kalırsa devam edecek kapasitede de olması gerekir. Bir petek, sunduğu servislerin ve arayüzlerin aynısını sunan bir petek ile değiştirilebilir. Bir petek başka bir peteğin servislerini çağırıyor olabilir. Bir petek kendine ait bir veri yapısı barındırıyor olabilir. (Kendine ait veri tabloları olabilir.) Bir peteğe ait veri tabloları başka bir petek tarafından direk olarak kullanılmamalıdır. Her işlem için peteğin sunduğu servisler kullanılır. Eğer istenen hizmeti yerine getirecek servis yoksa petekte değişikliğe gidilir.

Edit

Bir Peteğin sürüm tipleri

Bir peteğin iki adet sürüm tipi vardır. Şeffaf-kutu ve Kara-kutu. Şeffaf-kutu olarak müşteriye sunulan peteklerin kaynak kodu müşteriye açıktır. Müşteri kodun dizaynını ve çalışmasını test edebilir. İstediği platformlarda kodu yeniden derleyebilir ve değişiklik yapabilir. Kara-kutu olarak sunulan petekler sadece derlenmiş program (.exe yada .dll) olarak sunulurlar. Müşteri kaynak kodunu ve dizaynı göremez. Şeffa-kutu petekler ile birlikte Uygulama Modeli, tüm Operasyon Özellikleri belgeleri ve İlgili UML şemaları müşteriye verilmelidir. Kara-kutu petekler ile Tanımlama Modeli, derlenmiş programlar, modülün özelliklerini belirten belgeler ve UML modelleri müşteriye verilmelidir.

Edit

Modül Kullanmanın Yararları

Modüller Nasıl Belirleniyor? SOA (Hizmet Tabanlı Mimariler) Arayüzlerin Tanımlanması Modullerin Kullanıma Sunulması CBD 96 Standartları Yazılım uzmanlarının birlikte çalışması Versiyon kontrolu Örnek Proje

Edit

Ansiklopedi

Borland StarTeam MS Source Safe Rational ClearCase CVS Belge arşivi

Edit

Veritabanı geliştirme ve değişikliklerin uygulanması

Modelleme Uygulama Versiyon kontrolü

Edit

Proje için standart formlar

Aşağıda açıklamaları bulunan formların örneklerini ve şablonlarını kitap ile birlikte verilen tıkızda bulabilirsiniz. Edit

Senaryo formları

Edit

Değişiklik isteği formları

Edit

Test formları

Edit

Unit test

Edit

Sistem test

Edit

Regression test

Edit

Modül tanım formları (component model specifications)

Edit

SQL sablo sheet’leri

Edit

Hata formları

Edit

Internal ve external dizayn formları

Edit

Servis içerik formları (service specifications)

Edit

Modül içerik formları

Edit

Sözlük

Tüm şekillerin açıklamaları Kısaltmaların anlamları İngilizce kelimelerin anlamları Tıkız Örütbağ Use Case Object Component Class Sequence Diagrams Collaboration Diagrams Package Diagrams State Diagrams Activity Diagrams Deployment Diagrams Component Diagrams UML OO CBD Service Unit Test System Test End to End Testing SQL