Bölüm 1: Giriş
1.1. Nesneye Dayalı Çözümleme ve Tasarımın Tanımı
Bu bölümde derste işlenecek olan konular kısaca tanıtılacaktır. Dersin ilerleyen bölümlerinde ise bu konular ayrıntılı olarak açıklanacaktır.
Nesneye Dayalı Çözümleme (Analysis): Problem (uygulama) domenindeki, yani gerçek dünyadaki sınıflar veya nesneler (kavramlar) belirlenip tanımlanır.
Bu aşamada amaç problemi çözmek değil, anlamaktır.
Örnek: Kütüphane otomasyonundaki kavramlar: Kütüphane, kitap, üye, görevli vs.
Nesneye Dayalı Tasarım (Design): Yazılım (çözüm) domenindeki, yani bilgisayardaki sınıflar (ve nesneler) oluşturulur. Burada sınıfların içerikleri (özellik ve davranış) ve sınıflar arası ilişkiler tam olarak tanımlanır.
Tasarım tamamlandıktan sonra bir programlama dili (C++, Java, C#) kullanılarak kodlama yapılır.
Aşağıdaki şekilde küçük bir örnek üzerinde sınıfların değişik domenlerdeki biçimleri gösterilmiştir.
Şekil 1.1: Sınıfların Değişik Domenlerde Temsil Edilmesi
1.2. Genel Bir Örnek
Bu örnekte, dersle öğretilecek olan çözümleme ve tasarım aşamaları kısaca gösterilecektir. Henüz ilgili konular anlatılmadığından bu aşamada yapılanları ve UML diyagramlarını tüm ayrıntılarıyla anlamak mümkün değildir. Amaç yazılım geliştirmenin aşamalarını genel hatlarıyla göstermektir. Dersin ilerleyen bölümlerinde bu konular ayrıntıları ile açıklanacaktır.
Zar Oyunu: Oyuncu iki zar atar. Zarların üste gelen yüzeylerindeki sayıların toplamı 7 ise oyuncu kazanır, aksi durumda kaybeder.
Bu yazılımın gerçeklenmesinde şu temel aşamalardan geçilir:
1.2.1. Kullanım Senaryolarının (Use Case) Belirlenmesi
Yazılım geliştirmenin ilk aşaması isteklerin (requirements) belirlenmesidir. İstekleri belirlemek için kullanılan en geçerli yöntem kullanım senaryoları (use case) yöntemidir.
Bu yöntemde tasarımı yapılan sistem ile kullanıcıları arasında gerçekleşebilecek tüm olaylar numaralandırılarak adım adım yazılır.
Örnek:
Ana senaryo:
- Oyuncu iki zarı yuvarlar.
- Sistem zarların üstündeki değerleri ve toplamlarını gösterir.
- Oyun sona erer.
Alternatif akışlar:
- Üste gelen değerlerin toplamı 7'dir. Oyuncuya kazandığı bildirilir.
- Üste gelen değerlerin toplamı 7'den farklıdır. Oyuncuya kaybettiği bildirilir.
Kullanım senaryoları bölüm 3' te ayrıntılı olarak açıklanacaktır.
1.2.2. Uygulama Domeninde Modelleme (Analiz)
Uygulamayı (gerçeklenecek olan sistemi) oluşturan kavramlar (sınıflar), bunların özellikleri ve aralarındaki ilişkiler belirlenir.
Bu aşamada elde edilen sınıflar gerçek dünyadaki sınıflardır. Oluşturulan modelin amacı problemi çözmek değil, anlamaktır.
Bu konu bölüm 4' te ayrıntılı olarak açıklanacaktır.
Şekil 1.2: Zar Oyunu Uygulama Domeni Modeli
1.2.3. Yazılım (Çözüm) Domeninde Modelleme (Tasarım)
Bu aşamada tasarım yapılarak sistemin sorumlulukları uygun yazılım sınıflarına atanır.
Tasarım sonucu iki farklı diyagram ile ifade edilir.
1. Etkileşim Diyagramı
2. Sınıf Diyagramı
1.2.4. Kodlama
1.2.5. Sınama
Bu örnek ile kısaca açıklanan ilk üç konu dersin ilerleyen bölümlerinde ayrıntılı olarak anlatılacaktır.
1.2.3.1. Etkileşim Diyagramı
Sınıfların (nesnelerin) davranışları ve aralarındaki etkileşim belirlenir.
Şekil 1.3: Zar Oyunu Etkileşim Diyagramı
1.2.3.2. Sınıf Diyagramı
Sınıfların sahip olacakları üyeler (özellikler ve davranışlar) programda yer alacağı şekilde belirlenir. Bu aşamadaki model problemin çözümünü oluşturur.
Tasarım aşamasında tasarım kalıplarından (design patterns) yararlanılır.
Şekil 1.4: Zar Oyunu Sınıf Diyagramı
1.3. Nesneye Dayalı Analiz ve Tasarım NEDEN Gerekli? Yazılım Dünyasındaki Problemler
Aşağıdaki problemler iyi bir yazılım geliştirme tekniğini zorunlu kılmaktadır:
- Donanım maliyetleri azalırken yazılım maliyetleri artmaktadır.
- Yazılımların boyutları ve karmaşıklığı artmaktadır.
- Yazılımların bakım maliyetleri çok yüksektir.
- Donanım problemleri ile çok az karşılaşılırken yazılım hataları sıklaşmaktadır.
En büyük sorun yazılım maliyetlerinin yüksekliğidir.
| Yazılım Geliştirme Aşamalarının Maliyetleri: | |
| İsteklerin Çözümlenmesi (Requirements): | %3 |
| Tasarım: | %8 |
| Kodlama (Programlama): | %7 |
| Sınama: | %15 |
| Bakım: | %67 (Maliyeti çok yüksek) |
Maliyeti yükselten bir unsur da hataların geç belirlenmesi ve kolaylıkla giderilememesidir.
| Hataların Giderilme Maliyetleri (Belirlendikleri aşamaya göre): | |
| İsteklerin Çözümlenmesi (Requirements): | 1 Birm |
| Tasarım: | 1.5 - 2 Birim |
| Kodlama (Programlama): | 5 - 10 Birim |
| Sınama: | 10 - 15 Birim |
| Bakım: | 15 - 100 Birim |
Çözüm:
- Yazılım geliştirme hem bir bilim dalı hemde bir sanattır.
- Kolay ve kesnin bir reçete yoktur; sezgiler ve deneyim çok önemlidir.
- Aşağıdaki unsurlar doğru şekilde kullanıldıklarında işler kolaylaşır, başarı olasılığı yükselir.
- Uygun yazılım geliştirme süreçleri:
- Yinelemeli (iterative) ve evrensel (evolutionary) yöntemler
- Tümleştirilmiş geliştirme süreci (The Unified Process - UP)
- Uygun yazılım geliştirme süreçleri:
- Nesneye Dayalı Yöntem
- Yardımcı araçlar
- UML (Unified Modeling Language)
- Yazılım Geliştirme Programları
- Tasarım kalıpları (Design Patterns)
1.4. Bir Yazılımın Kalitesi
Yazılım dünyasındaki kişileri ikiye ayırabiliriz: Yazılımın kullanıcıları ve yazılımı geliştirenler. Bu kişilerin bakış açılarına göre kaliteli bir yazılımda aşağıdaki özellikler bulunmalıdır:
Kullanıcı
- Bir yazılım istenen işi doğru olarak yapılmalıdır (useful).
- Program kolay kullanılabilir olmalıdır (usable).
- Program uygulamanın gerektirdiği kadar hızlı çalışmalıdır.
- Program, sistem kaynaklarını (işlemci, bellek, disk, iletişim ağı vb.)
- Yazılım sağlam olmalıdır.
- Yazılımı güncellemek kolay olmalıdır.
Yazılım geliştiren
- Yazılımın bakımı kolay olmalıdır.
- Yazılım projesi yeterli bir süre içinde tamamlanmalıdır.
- Yazılımın modülleri yeni projelerde tekrar kullanılabilmeli (reusable).
- Yazılımı geliştirme maliyeti düşük tutulabilmelidir.
Yukarıda sıralanan kalite kriterlerini sağlamak için programlama dilini bilmek yeterli değildir. Programlama dilinin desteklediği nesneye dayalı çözümleme ve tasarım yöntemleri bilmek ve uygun şekilde kullanabilmek gerekir.
1.5. Nesneye Dayalı Programlama Yöntemi
1.5.1. Programlama Nedir?
İnsanlar günlük hayatta kullandıkları konuşma dilleri ile çeşitli kavramları birbirlerine anlatmaya çalışırlar. Benzer şekilde bilgisayar programcıları da çözülmesi gereken problemlerle ilgili kavram ve varlıkları, kullandıkları programlama dili ile bilgisayarda ifade etmeye çalışırlar.
Programlama, yaşadığımız gerçek dünyadaki problemlere ilişkin çözümlerin bilgisayarda ifade edilmesidir. Bunu yapabilmek için, kodlamaya geçilmeden önce tasarım aşamasında, problemi oluşturan varlıkların bilgisayarda ifade edilebilecek şekilde modellerinin oluşturulması gerekmektedir.
Nesneye Dayalı Yöntem bu modellerin oluşturulmasında ve gerektiğinde sistemin güncellenmesinde diğer yöntemlere göre bazı avantajlar sağlar.
Şekil 1.5: Programlama: problem uzayından çözüm uzayına geçiş
1.5.2. Nesneye Dayalı (Object-Oriented) Programlama Yönteminin Temel Özellikleri
- Gerçek dünya nesnelerden oluşmaktadır.
- Çözülmek istenen problemi oluşturan nesneler, gerçek dünyadaki yapılarına benzer bir şekilde bilgisayarda modellenmelidir.
- Nesnelerin yapıları iki bölümden oluşmaktadır:
- 1. Nitelikler (özellikler ya da durum bilgileri)
- 2. Davranışlar (yetenekler)
- Nesneler belli bir sorumluluğu yerine getirmek üzere tasarlanırlar
Tasarım yapılırken sistemin işlevi değil, sistemi oluşturan varlıklar esas alınır. Bu nedenle tasarım yapılırken sorulması gereken soru,
"Bu sistem ne iş yapar?" değil,
"Bu sistem hangi nesnelerden oluşur?" olmalıdır.
Hangi unsurların nesne olarak modellenebilir:
- İnsan kaynakları ile ilgili bir programda; memur, işçi, müdür, genel müdür.
- Grafik programında; nokta, çizgi, çember, silindir.
- Matematiksel işlemler yapan programda; karmaşık sayılar, matris.
- Kullanıcı arayüzü programında; pencere, menü, çerçeve
1.5.3. Nesne Nedir?
Yazılım geliştirme sürecinde sisteme üç farklı bakış açısı ile görmek mümkündür. (Fowler, UML Distilled, Addison-Wesley.)
- Kavramsal (conceptual) perspektif: Problem domeninde (gerçek dünya) model oluşturulur. Analiz aşamasındaki bakış açısıdır.
- Betimleme (specification): Yazılım domenindeyiz. Ancak yazılımın kodunu değil sadece arayüzlerini görüyoruz ve sınıflar arası etkileşimi dikkate alıyoruz. Tasarım aşamasındaki bakış açısıdır.
- Gerçekleme (implementation): Yazılımın kodu.
Yazılım geliştirmenin değişik aşamalarında nesneler değişik bakış açılarıyla ele alınırlar.
Kavramsal düzeyde nesne belli bir sorumluluğu (sorumlulukları) yerine getiren bir varlıktır.
Betimleme düzeyinde nesne değişik hizmetler veren metotlara sahip bir varlıktır. Bu metotlar kendisi veya başka nesneler tarafından canlandırılabilirler.
Gerçekleme aşamasında nesne veri ve fonksiyonlardan oluşan bir modüldür.
1.5.3.1. Örnek
Nesne Örneği: Grafik Programındaki nokta
Örnek olarak bir grafik programı yazıldığını ve bu nedenle düzlemdeki noktaları modellemek gerektiğini düşünelim.
Düzlemdeki bir noktanın özellikleri; x-y koordinatlarıdır.
Davranışları ise, noktanın düzlemde yer değiştirmesi, renginin değişmesi, ekranda görünmesi ve ekranda kaybolmasıdır.
Buna göre, örnek olarak düşünülen Nokta modeli şu bölümlerden oluşacaktır:
x ve y koordinatları için iki adet tamsayı değişken: x , y
Noktanın koordinatlarını değiştirerek düzlemde yer değiştirmesini etmesini sağlayan fonksiyon: hareket ,
Noktanın ekranda görünmesini sağlayan bir fonksiyon: gorun ,
Noktanın ekrandan silinmesini sağlayan bir fonksiyon: kaybol .
Model bir defa oluşturulduktan sonra, ana programda bu modelden bir çok nesne yaratılabilir.
Şekil 1.6: Bir nesnenin modeli (Sınıf yapısı)
1.5.3.2. Nesneye Dayalı Bir Programın Yapısı
Nesneye dayalı bir programın yapısı aşağıdaki animasyonda verilmiştir.
Şekil 1.7: Nesneye Dayalı Bir Programın Yapısı
1.5.4. Nesneye Dayalı Programlama Kavramlarını Kısaca Anımsatma
Bu başlık altında şu konulara değineceğiz.
|
1.5.4.1. Sınıf Üyelerine Erişimin Denetlenmesi (Açık/Kapalı Prensibi)
Sınıfı oluşturan programcı sınıf yapısının doğru çalışmasından sorumludur.
Sınıfı nesne tanımlamak için kullanan programcı sınıfı iç yapısını bilmek zorunda değildir (kapalı).
Bilmesi gereken tek şey nesnelere nasıl mesaj yollanacağıdır (açık).
Bu özellikleri sağlamak için, sınıfı yazan programcı, sınıfın bazı üyelerini gizleyerek (data hiding) onlara sınıf dışından erişilmesini engelleyebilir. Bir sınıfın içindeki üyelere erişimi denetleyen üç farklı etiket bulunmaktadır: public (açık), private (özel) ve protected (korumalı).
Bir sınıfın içindeki açık elemanlar o sınıfın dışarıya verdiği hizmetleri (services) tanımlarlar. Bunların tümüne sınıfın arayüzü (interface) denir.
Özel üyeler sınıfın gerçeklenmesiyle (implementation) ilgili olduklarından sınıfın kullanıcılarını ilgilendirmezler.
Bir sınıf iyi hizmet verebilecek kadar açık, kullanıcıyı ayrıntılar ile uğraştırmayacak ve sınıfın zarar görmesine izin vermeyecek kadar kapalı olmalıdır.
1.5.4.2. Sınıflar (Nesneler) Arasındaki İlişkiler (Relations)
Bir uygulamanın yapısal analizi büyük ölçüde gerekli sınıfların ve sınıflar arasındaki ilişkilerin belirlenmesine dayanır.
Nesneye dayalı dünyada sınıflar arasında; bağlantı (association), sahip olma (aggregation), -dan oluşma (composition), katılım (inheritance) gibi ilişkiler olur.
1.5.4.3. Bağlantı (Association)
Sınıflar arasında hizmet alma/vermeye dayalı en genel ilişkidir. UML diyagramlarında aşağıdaki gibi gösterilir.
Eğer ok kullanılmazsa bağlantı çift yönlüdür.
1.5.4.4. İç İçe Nesneler: Nesnelerin Başka Sınıfların Üyesi Olması (Aggregation / Compositon)
Bir sınıfın üyeleri sadece hazır veri tipleri (char, int, double....) olmak zorunda değildir. Bir sınıfın üyeleri başka sınıftan tanımlanmış nesneler de olabilirler.
Sınıflar arası bu ilişkiye sahip olma ilişkisi (has a relation) adı verilir.
Aşağıdaki örnekte karmaşık sayıları tanımlamak üzere bir sınıf (ComplexKes) oluşturulmuştur. Bu sınıfın reel ve sanal kısımları bayağı kesirlerden oluşacaklardır. Bayağı kesirler ise (Kesir) sınıfından tanımlanan nesneler ile oluşturulacaktır.
1.5.4.5. Sahip Olma İlişkisi (Aggregation / Compositon Farkı)
Sahip olma ilişkisinin (has a relation) iki ayrı türü vardır:
- Toplama, bir araya getirme (Aggregation): İçerilen nesneler (alt parçalar) kendi başlarına da kullanılırlar. Sadece o nesneye ait parçalar değillerdir.
Örneğin havaalanında uçaklar vardır.
- Meydana gelme (Composition): Alt parçalar o nesneyi meydana getirmek için oluşturulmuşlardır; kendi başlarına kullanılmazlar.
Örneğin otomobilin motoru vardır.
1.5.4.6. Temsil (Delegation)
Nesneye dayalı programlamanın önemli kavramlarından biri de temsildir (delegation).
Bir sınıf/nesne bazı hizmetleri yerine getirmek için başka varlıkları (sınıf/nesne) görevlendirebilir. Diğer bir deyişle kendisini temsil etmesini sağlar.
Örnek: Bir yığın sınıfı tasarlanırken bu sınıfın içine daha önceden varolan bir liste sınıfı yerleştirilebilir.
Bu örnekte yığın sınıfı push işlemi için Liste sınıfının add hizmetini kullanacaktır.
Temsil görevli nesne bulununcaya kadar birden fazla aşama sürebilir.
1.5.4.7. Kalıtım (Inhertiance), (Generalization/Specialization)
Varolan genel bir sınıftan daha özel başka bir sınıf türetilebilir.
Bu türetimde üst sınıfın ayrıntılarının bilinmesine ve kaynak kodunun elde edilmesine gerek yoktur.
Yararı tekrar kullanılabilirliktir (reusability).
Sistemin genel kısımları önce kodlanır. Daha özel kısımlar genel kısımlardan türetilir. Ortak özelliklerin yeniden yazılmasına gerek kalmaz.
1.5.4.8. Çok Şekillilik (Polymorphism)
Aynı mesaja farklı sınıflardan yaratılmış olan nesneler farklı tepkiler verirler.
Mesajı gönderen taraf bu mesajı hangi sınıftan bir nesneye gönderdiğini bilmek zorunda değildir.
Aşağıdaki örnekte Müdür sınıfı Öğretmen sınıfında türetilmiştir. Her iki sınıfta da farklı bir göster metodu vardır.
Eğer goster fonksiyonu sanal (virtual) olarak tanımlanmazsa yukarıdaki satırda her zaman Ogretmen sınıfındaki fonksiyon çağırılır.
goster fonksiyonu sanal olarak tanımlandığında çok şekillik özelliği kazanır. Bu durumda ptr işaretçisi hangi tipte bir nesneye işaret ediyorsa ona ait sınıftaki goster fonksiyonu canlanır. Bu durumda hangi metodun çağırılacağına program çalışırken (run-time) karar verilmiş olur.
1.5.4.9. Kurucu Fonksiyonlar (Constructors)
Kurucu fonksiyonlar üyesi oldukları sınıftan bir nesne yaratılırken kendiliğinden canlanırlar.
Bu tür fonksiyonlar bir nesnenin kurulması aşamasında yapılması gereken işleri, örneğin verilere uygun başlangıç değerleri atamak için kullanılırlar.
Kurucu fonksiyonlar üyesi oldukları sınıf ile aynı ismi taşırlar.
Kurucular parametre alırlar, ancak geri dönüş değerleri yoktur. Geri dönüş tipi olarak herhangi bir tip (void bile) yazılmaz.
Kurucu fonksiyonlar nesne yaratılırken sınıfın dışından sınıfın açık (public) üyeleri arasında yer almalıdırlar.
1.5.4.9.1. Parametresiz Kurucu Fonksiyonlar (Default Constructor)
Bu tür kurucu fonksiyonların ya parametre listeleri boştur, ya da tüm parametrelerin bir başlangıç değeri vardır.
Ana programda kurucu fonksiyonların çağrılması için özel bir deyim yazılmaz. Nesnelerin yaratıldığı satırlarda kurucu fonksiyon her nesne için bir defa çalışır.
1.5.4.9.2. Parametreli Kurucu Fonksiyonlar
Kurucu fonksiyonlar da diğer üye fonksiyonlar gibi gerektiğinde parametre alacak şekilde tanımlanabilirler.
Bu durumda sınıftan nesne yaratan programcılar, nesneleri tanımladıkları satırlarda kurucu fonksiyonlara uygun tipte ve sayıda argümanı vermek zorundadırlar.
1.5.4.10. Yok Edici Fonksiyonlar (Destructors)
Bu fonksiyonlar üyesi oldukları sınıftan yaratılmış olan bir nesne bellekten kaldırılırken kendiliğinden çalışırlar.
Bir nesnenin bellekten kaldırılması için ya nesnenin yaşam alanı sona ermelidir (tanımlandığı blok sona ermiştir) ya da dinamik bellekte tanımlanmış olan bir nesne delete operatörü ile bellekten silinmelidir.
Yok edici fonksiyonlar da kurucular gibi sınıf ile aynı ismi taşırlar, ancak isimlerinin önünde 'tilda' simgesi (~) yer alır. Yok ediciler parametre almazlar ve geriye değer döndürmezler. Bir sınıfta sadece bir adet yok edici fonksiyon olabilir.
C++ standart arşivinde katarları tanımlamak için string adında hazır bir sınıf vardır.
1.5.4.11. Sabit Nesneler ve Sabit Fonksiyonlar
Diğer veri tiplerinde olduğu gibi bir nesne de sabit (const) olarak tanımlanabilir. Bunun anlamı nesnenin veri alanlarının program boyunca doğrudan ya da dolaylı olarak (fonksiyon çağırarak) değiştirilemeyeceğidir.
Derleyiciler sabit olarak tanımlanan nesnelerin içeriklerinin değişmemesi için bu nesnelerin üye fonksiyonlarının çağırılmasına izin vermezler.
Sınıfın yazarları üye veriler üzerinde değişiklik yapmayan fonksiyonları da sabit (const) olarak bildirmelidirler. Sabit nesneler için sadece sabit fonksiyonlar çağırılabilirler.
void Nokta::goster() const
{
cout << "X= " << x << ", Y= " << y << endl;
}
int main()
{
const Nokta sn(10,20); // sabit nokta
Nokta n(0,50); // sabit olmayan nokta
sn.goster(); // Doğru
sn.git(30,15); // HATA!
n.git(100,45); // Doğru
return 0;
}
Sınıfın verileri üzerinde değişiklik yapmayan fonksiyonların sabit olarak tanımlanmaları hata olasılığını ve hata çıktığında incelenmesi gereken fonksiyonların sayısını azaltmaktadır. Bu nedenle bu özelliğe uyan tüm üye fonksiyonlar sabit olarak tanımlanmalıdır.
1.5.4.12. Nesnelerin Fonksiyonlara Parametre Olarak Aktarılması
Aksi zorunlu olmadıkça, nesneler fonksiyonlara referanslar yoluyla aktarılmalı. Benzer şekilde fonksiyonlardan geri döndürülen nesneler için de eğer mümkünse referanslar kullanılmalıdır.
Parametre aktarımında referanslar kullanılmazsa nesnelerin içerdiği değerler yığına kopyalanır (call by value). Eğer sınıfın içinde bir kopyalama fonksiyonu varsa yığına kopyalama işi için de programcının yazdığı bu fonksiyon canlanacaktır.
Nesnelerin fonksiyonlara değer olarak aktarılması hem bellekte daha fazla yer harcanmasına neden olur hem de programın çalışmasını yavaşlatır. Bu nedenle, eğer aksi zorunlu değilse, fonksiyonlara nesnelerin değerleri değil referansları aktarılmalıdır. Bu işlem Java' da derleyici tarafından yapılır. C++' da ise programcının parametre aktarım şekline karar vermesi gerekir.
Referans yoluyla aktarılan nesnelerin içeriklerinin fonksiyon içinde değiştirilmesi istenmiyorsa bu aktarım sabit referanslar ile yapılmalıdır.
1.5.5. Nesneye Dayalı Yöntemin Değerlendirmesi
Nesneye dayalı yöntemin değerlendirmesi şu şekilde yapılır:
Gerçek dünya nesnelerden oluştuğundan bu yöntem ile sistemin daha gerçekçi bir modeli oluşturulabilir. Program daha anlaşılır olur.
- Nesne modellerinin (sınıfların) içindeki veriler sadece üye fonksiyonların erişebileceği şekilde düzenlenebilirler. Veri saklama (data hiding) adı verilen bu özellik satesinde verilerin herhangi bir fonksiyon tarafından bozulması önlenir.
- Programcılar kendi veri tiplerini yaratabilirler.
- Bir nesne modeli oluşturduktan sonra bu modeli çeşitli şekillerde (aggregation, inheritance) defalarca kullanmak mümkündür (reusability).
- Programları güncellemek daha kolaydır.
- Programların bakımını yapmak daha kolaydır.
- Nesneye dayalı yöntem takım çalışmaları için uygundur.
Değerlendirme Soruları-1
Değerlendirme Soruları-2
Bölüm 2: Tümleştirilmiş Yazılım Geliştirme Süreci (The Unified Process - UP)
2.1. Tümleştirilmiş Yazılım Geliştirme Süreci (The Unified Process - UP) Temel Özellikleri
Günümüzün karmaşık problemlerini çözmek ve bölüm 1' de tanıtılan kalite kriterlerini sağlamak için yazılım projelerini uygun şekilde planlamak ve belli bir disiplin altında bu plana uymak gerekir.
Yazılımcılara planlama konusunda yol gösteren çeşitli yazılım geliştirme süreçleri oluşturulmuştur. Spiral yöntemi ve çağlayan (waterfall) yöntemi bunlara örneklerdir.
Nesneye dayalı yazılım geliştirmek için var olan yöntemlerin deneyimler sonucu kabul gören en iyi özellikleri bir araya getirilerek tümleştirilmiş yazılım geliştirme süreci (The Unified Process - UP) oluşturulmuştur.
Şekil 2.1' de gösterilen UP' nin temel özellikleri şunlardır:
- Yinelemeli (iterative): Problemdeki istekler (requirements) bir bütün olarak yerine getirilmeye çalışılmaz. Önce problemin (isteklerin) bir kısmı ele alınır. Problemin bu kısmı bağımsız bir proje olarak ele alınır ve hedeflenen istekleri yerine getiren sınanmış tam bir ürün ortaya çıkartılır. Ardından bir sonraki yinelemeye (iterasyon) geçilir ve yeni istekler ele alınır. Her iterasyon sonunda hedefe daha yakın bir ürün elde edilir.
- Arttırmalı ve evrensel (incremental, evolutionary): Her iterasyon adımında yeni istekler ele aldığından iterasyonlar sonucunda elde edilen ürünlerin özellikleri artar ve hedeflenen yazılım ürününe yaklaşırlar.
- Risk güdümlü (risk-driven): İlk iterasyonlarda en riskli kısımlar gerçeklenmelidir. Böylece daha projenin ilk aşamalarında ortaya çıkabilecek problemler görülebilir ve gerekli önlemler alınabilir. Örneğin zaman planı gözden geçirilir, ekibe yeni elamanlar alınabilir, bütçe güncellenebilir.
Şekil 2.1' de gösterildiği gibi her yineleme (iterasyon) adımında bütün bir yazılım projesi varmış gibi davranılır. Gerekli tüm aşamalardan geçilerek sınanmış, çalışır bir ürün elde edilir.
Şekil 2.1: UP: Yinelemeli ve evrimsel yazılım geliştirme
2.2. Yinelemeli Sürecin Yararları
Yinelemeli sürecin yararları aşağıdaki şekilde sıralanmaktadır:
- Değişen isteklere uyum: Yazılım geliştirmedeki en büyük problemlerden biri isteklerin değişmesidir. Yinelemeli çalışma sayesinde istekler değişirse bir sonraki yineleme adımında değişikliklere uyum sağlanabilir.
- Erken geri besleme: Her iterasyondan sonra müşteriden (yazılımın kullanıcısı) geri besleme alınarak beklentilerin en ölçüde karşılandığı sınanmış olur. Eğer bir uyumsuzluk varsa erkenden önlem alınır.
- Büyük sistemlerde çözümlenme kolaylığı: Büyük ve karmaşık bir sistemi bir bütün olarak tek adımda çözümlemek (anlamak) zor olacaktır. Bu nedenle istekleri parça parça ele almak sistemi anlamak ve tasarlamak açısından kolaylık sağlar.
- Her iterasyonda deneyim kazanılması: Her yineleme adında yazılım ekibi o kunu ile ilgili deneyim kazanır ve elemanlar birbirini daha iyi tanır.
- Risklerin erken giderilmesi (eğer mümkünse): Riskli kısımlar ilk iterasyonlarda ele alındığından eğer bir problem varsa bu problemlere karşı önlemler mümkün olduğu kadarıyla erken alınmış olur.
- Erken ürün elde etme, takımda moral yükselmesi: Her iterasyon sonunda bir ürün elde edildiğinden zaman içinde hedefe yaklaşıldığı görülür ve yazılım ekibi çalışmalarının sonuçlarını görerek moral kazanır.
2.3. UP'nin Kullanılmasına Yönelik Öneriler
UP' nin kullanılmasına yönelik öneriler şunlardır:
|
- Temel oluşturan yapılar (çekirdek) önce gerçeklenmeli: Yüksek riskli kısımlardan başka önce ele alınması gereken modüller sistemin temelini (iskeletini) oluşturan yapılardır.
- Sürekli kullanıcılardan geri besleme alınmalı, isteklere uyulmaya dikkat edilmeli.
- Her iterasyondan sonra ürün tam olarak sınanmalı: Her iterasyonda bir ürün oluşturulduğu unutulmamalı ve bu ürün tam olarak sınanmalıdır. Aksi durumda hatalar geç fark edilir ve bunları düzeltme maliyeti yüksek olur.
- Kullanım senaryoları yöntemi (use case) uygulanmalı: Bu yöntem Bölüm 3'te ayrıntılı olarak açıklanacaktır.
- Görsel modelleme (UML) kullanılmalı. UML tasarımların ifade edilmesini ve takım elemanları arasında iletişimi kolaylaştırır.
- Bir iterasyonda elde edilen deneyim diğer iterasyonda kullanılmalı.
2.4. Tümleştirilmiş Süreçte (UP) Yazılım Projesi Aşamaları
Tümleştirilmiş süreçte (UP) bir yazılım projesi aşağıda açıklanan aşamalardan geçilerek gerçeklenir.
- Başlangıç (Inception): Bu aşama da kabaca projenin vizyonu ortaya konur. İstekler ayrıntıya girilmeden genel olarak ele alınır ve fizibilite değerlendirmesi yapılır. Bu aşama sonunda projeye girip girmemeye karar verilir.
- Ayrıntılandırma (Elaboration): Bu aşamada daha gerçekçi çözümleme yapılır ve istekler ayrıntılı olarak ele alınır. Çekirdek yapı ve yüksek riskli kısımlar yinelemeli olarak bu aşamada oluşturulur.
- Tamamlama (Construction): Daha az riskli ve düşük öncelikli kısımların yinelemeli olarak gerçeklenmesi.
- Yayım (Transition): Beta testleri, piyasaya sürme çalışmaları.
Şekil 2.2: UP'de Yazılım Projesi Aşamaları
2.5. Derste Kullanılacak Örnek Sistem
Dersteki örnekler çoğunlukla "NextGen" adı verilen ve her hangi bir dükkanda (market, giyim mağazası) çalışabilecek bir POS (point of sale) sistemi üzerinde verilecektir. Bu örnek, dersin başvuru kitabından alınmıştır:
"Craig Larman, Applying UML and Patterns , An Introduction to OOA/D and Iterative Development, 3/e, Prentice Hall PTR, 2005."
Örnek sistem, müşterilerin ürünleri satın almaları, fatura oluşturma, indirimli ve promosyonlu toplam bedelleri hesaplama, vergilerin belirlenmesi, müşterilerin ürün iade etmesi ve bir dükkanda gerek duyulacak benzeri işlerin bilgisayarla yapılmasını sağlayacaktır.
Şekil 2.3' te de gösterildiği gibi yazılımın üç katmandan oluştuğu düşünülmüştür.
- Arayüz katmanı dış dünya ile ilikşkiyi sağlamaktadır. Bu ders kapsamında arayüz katmanının tasarımı yapılmayacaktır. Ancak bu katmanın diğer katmanlar ile bağlantısı üzerinde durulacaktır.
- Uygulama mantığı (iş) katmanı asıl işlemleri yapan (istekleri yerine getiren) katmandır. Bu katmandaki sınıfların (Satış, Ödeme, Terminal vb.) tasarımı bu dersin konusunu oluşturmaktadır.
- Teknik hizmetler katmanı uygulama mantığı katmanına destek veren sınıflardan oluşur. Örneğin işlem kayıtlarının (log) tutulması, veri tabanı kayıtları ve sorguları gibi.
Şekil 2.3: Örnek sistemin katmanlı yapısı
Değerlendirme Soruları
Bölüm 3: İsteklerin Çözümlenmesi (Requirement Analisys)
3.1. İsteklerin Kategorileri
İstekler, bir sistemin sahip olması gereken yetenekler ve sağlaması gereken koşulların tarifidir. İstekler FURPS+ modeli ile kategorize edilebilir. FURPS kısaltması aşağıdaki sözcüklerin baş harflerinden oluşmaktadır.
Functionality (İşlevsellik): İşlevleri, yetenekleri, güvenlik
Usability (Kullanılabilirlik): İnsan ile etkileşimi, yardım, dokümantasyon
Realiability (Güvenirlik): Hataların sıklığı, düzeltilebilmesi, öngörülebilmesi
Performance (Performans): Hız, verimlilik, doğruluk
Supportabilty (Desteklenebilme): Güncellenebilme, bakım yapılabilmesi, seçeneklerin ayarlanabilmesi, uluslararası uyum
+ Diğer ikinci faktörler:
Gerçekleme: Kullanılan dil, araçlar, kaynaklardaki (bellek, işlemci hızı) sınırlama
Arayüz: Diğer birimler ile etkileşimi
İşletme: İşletme (kullanım) ile ilgili beklentiler
Paketleme
Hukuki işlemler: Lisans, patent alma gibi işlemler.
İstekler kabaca işlevsel olanlar ve diğerleri olarak iki gruba da ayrılabilir.
Bir sistemden beklenenler araştırılırken bu kategoriler kullanılarak isteklerin unutulması önlenmiş olur.
3.2. Kullanım Senaryolarının (Use-Cases) Tanımı
Kullanım senaryoları, isteklerin anlaşılmasını ve ifade edilmesini sağlayan bir yöntemdir.
Özellikle işlevsel isteklerin ifade edilmesinde kullanılır.
Fikir ilk olarak Ericsson' da çalışan Ivar Jacobson adlı İsveçli bir mühendis tarafından oluşturulmuştur. Daha sonra Rational' de çalışmıştır, şimdi kendi firmasındadır.
http://www.ivarjacobson.com
3.2.1. Senaryo
Anlamlı bir sonuca (amaca) ulaşmak için aktör ile sistem arasında gerçekleşen olayların belli bir zinciridir. Bir sistemin çalışması sırasında birden fazla senaryo gerçekleşebilir.
Olası tüm senaryolar kullanım senaryolarını (use case) oluştururlar.
Bir otomatik para çekme makinesinde (ATM) müşteri ile sistem arasında gerçekleşebilecek olan olayların oluşturduğu senaryolar şunlar olabilir.
- Müşteri kartını makineye takar.
- Sistem şifreyi sorar.
- Müşteri şifreyi girer.
- Sistem şifreyi onaylar.
- Müşteri para çekme işlemini seçer.
- Müşteri çekeceği para miktarını seçer.
- Sistem parayı, makbuzu ve kartı verir.
Yukarıdaki akış bu sistemdeki olası senaryolardan sadece biridir. Aynı sistemde geçerli olan diğer bir senaryo:
- Müşteri kartını makineye takar.
- Sistem şifreyi sorar.
- Müşteri şifreyi girer.
- Sistem şifrenin yanlış olduğunu bildirir ve şifreyi tekrar ister.
- Müşteri şifreyi girer
- Sistem şifrenin yanlış olduğunu bildirir, kartı alıkoyar ve işlemi sonlandırır.
Aynı sistemdeki başka bir senaryo da müşterinin bakiyesinin yeterli olmaması durumuyla ilgili olabilir.
Aynı sistemdeki başka bir senaryo da müşterinin bakiyesinin yeterli olmaması durumuyla ilgili olabilir.
Yazılım dünyasındaki önemli isimleri kullanım senaryoları ile ilgili orijinal tanımları aşağıda verilmiştir:
(Jacobson, Booch, Rumbaugh 1999):
"A use case specifies a sequence of actions, including variants, that a system performs and that yields an observable result of value to a particular actor."
(Cockburn 2000):
"A use case is a collection of possible sequences of interactions between the system under discussion and its external actors, related to a particular goal."
Bu konu ile ilgili ayrıntılı bilgi aşağıdaki kaynaklarda bulunabilir.
- http://www.rational.com/uml/
- http://alistair.cockburn.us/usecases/usecases.html
- http://www.pols.co.uk/use-case-zone/
- http://www.mcs.vuw.ac.nz/research/object/Papers/euc-html/
3.2.2. Aktör
Sistemin kullanıcılarını tanımlamak için kullanılan mekanizmadır.
- Aktör tasarlanmakta olan sitemin kullanıcısı ya da o sistemden etkilenen diğer birimlerdir; insan, başka bir sistem, bir cihaz olabilir.
- Aktörler tasarlanacak olan sistemin dışında kalan birimlerdir.
- Aktör sistemden hizmet isteğinde bulunabilir, sisteme hizmet verebilir.
Farklı gruplara ayrılırlar:
Birincil aktör (Primary Actor):
Sistemden asıl faydayı sağlayan, işlemleri başlatan kullanıcı.
Destek Aktörü:
Sisteme bilgi (destek) sağlayan aktör. Genellikle bir bilgisayar sistemidir.
Diğer Aktörler:
Bu aktörler sistemi doğrudan kullanmazlar ve sisteme bilgi desteği vermezler ancak o senaryoda gerçekleşen olaylarla ilgilenirler ve bu olaylardan etkilenmezler.
Aktörlere ilişkin örnekler derslerin ilerleyen bölümlerinde verilecektir.
3.2.3. Birincil Aktör ve Sistemin Sınırları
Üzerinde çalıştığımız sistemi hangi düzeyde incelediğimize ve sınırlarını ne şekilde çizdiğimize bağlı olarak birincil aktörler değişiklik gösterir.
Kullanım senaryolarını yazarken sistemin sınırlarını doğru olarak belirlemek, nelerin dışarıda nelerin içeride olacağına doğru karar vermek gerekir.
Şekil 3.1' de sistemin hangi düzeyde incelendiğine bağlı olarak aktörlerin nasıl değiştiği gösterilmiştir.
Şekil 3.1: Birincil Aktör ve Sistemin Sınırları
Şekil 3.1' de görüldüğü gibi o anda tasarlamakta olduğumuz sistem sadece terminal (kasa) programı ise bu durumda sistemin birincil aktörü (kullanıcısı) kasa görevlisidir.
Ancak dükkan sistemini bir bütün olarak inceliyorsak kasa görevlisi bu sistemin içinde bir parçadır ve aktör değildir. Bu durumda birincil aktör müşteridir. Vergi dairesi ise bu sistemden etkilenen diğer aktördür.
3.3. Kullanım Senaryolarının Yazılması
3.3.1. Kullanım Senaryolarının İfade Edilmesi
Kullanım senaryolarının ifade edilmesi:
|
3.3.2. Kullanım Senaryolarında Yer Alan Bölümler
Her kullanım senaryoları grubunun (use case) bir adı ve numarası vardır. İsimden sonra şağıdaki bölümler gelir.
- Önsöz (Preface) Bölümü
- Ana Başarılı Senaryo (Temel Akış) Bölümü
(Main Success Scenario or Basic Flow) - Uzantılar (Alternatif Akışlar) Bölümü
(Extensions or Alternate Flows) - Özel İstekler Bölümü
(Special Requirements) - Sıra Dışı Durumlar Bölümü
(Exceptions) - Teknolojik Beklentiler Bölümü
3.3.2.1. Önsöz (Preface) Bölümü
Aşağıdaki alt bölümlerden oluşur:
- Birincil Aktör (Primary Actor):
Sistemden asıl faydayı sağlayan, işlemleri başlatan kullanıcı. - İlgililer ve Beklentileri (Stake holders and interests):
Sistemin çalışmasından etkilenen ve bu sistemden beklentileri olan unsurlar (diğer aktörler).
Birincil aktör, destek aktörü ve diğer aktörlerin belirlenmesi sistemin sınırlarını çizer.
Kullanım senaryoları ilgililerin (aktörlerin) tüm beklentilerini karşılayan tüm olayları ve sadece onları içerir.
Tüm ilgililerin ve beklentilerin ilk başta belirlenmesi önemlidir. Aksi durumda senaryolarda bazı durumlar unutulabilir ve bu eksiklik ancak ileriki aşamalarda anlaşılabilir.
- Ön koşullar (Preconditions):
Belli bir senaryo grubunu (use case) oluşturan olayların başlaması için sağlanması gereken koşullar. Bu koşullar senaryo içinde test edilmez, doğru oldukları varsayılır. - Son koşullar (Postconditions, Success Guarantees):
Senaryolar tamamlandığında sistemin ulaşacağı durum. Son koşullar ilgililerin beklentilerine (amaçlarına) denk düşer.
3.3.2.2. Ana Başarılı Senaryo (Temel Akış) Bölümü (Main Success Scenario or Basic Flow)
Sistemin en doğal çalışma şekli adım adım yazılır. Her adım numaralanır.
Koşullar ve dallanmalar içermez. Etken cümleler kullanılır; "kim ne yapar" açıktır.
Adımlar üç farklı gruba ayrılır:
- Kullanıcılar ile sistem arasında etkileşim, tetikleme.
- Onaylama (çoğunlukla sistem tarafından)
- Sistemde durum değişikliği, bir bilginin kayıt edilmesi.
Örnek:
- Müşteri şifresini girer.
- Sistem ekrana müşterinin adını çıkartır.
- ...........
Belirsiz ve edilgen cümleler kullanılmaz.
Örnek: "Toplam belirlenir." Bu uygun bir senaryo cümlesi değildir. Kim belirleyecek? Sistem mi? Aktörlerden biri mi?
3.3.2.3. Uzantılar (Alternatif Akışlar) Bölümü (Extensions or Alternate Flows)
Ana senaryonun dışında kalan başarılı/başarısız sonuçlara götüren tüm senaryolar sıralanır. Ana senaryodan (temel akış) dallanmalar şeklinde yazılırlar. Ana senaryoda hangi adımdan buraya gelinecekse o adımın numarası kullanılır.
Alternatif akışa (dallanma) neden olan koşullar aktörler ya da sistem tarafından fark edilecek şekilde yazılmalı. Alternatif senaryolar ile aktörlerin tüm amaçları sağlanmış olmalı.
Örnek:
Ana senaryoda 2. Müşteri şifresini girer satırı varsa, temel akışta şifrenin doğru olduğu durum ele alınır. Şifrenin yanlış girilmesi durumu ise aşağıda gösterildiği gibi uzantılarda incelenir.
Uzantılar:
2a. Müşteri şifresini yanlış girmiştir.
- Sistem hata mesajı verir ve şifreyi yeniden ister.
3.3.2.4. Diğer Bölümler
Sıra Dışı Durumlar Bölümü (Exceptions) :
Sistemde hatalar oluştuğunda yapılacaklar sıralanır. Bazı tasarımcılar bu bölümdeki olayları da uzantılar bölümünde ele alırlar.
Özel İstekler Bölümü (Special Requirements) :
İşlevler ile ilgili olmayan istekler bu bölümde belirtilir. Bu istekler genellikle hız, güvenirlilik, rahat kullanım gibi kalite kriterlerine yöneliktir.
Teknolojik Beklentiler Bölümü :
Kullanıcıların ön gördükleri donanım özellikleri burada sıralanır. Örneğin giriş/çıkış işlemlerinin hangi cihazlar ile yapılması istendiği bu bölüme yazılır.
3.3.2.5. Örnek
Metin (text) tipindeki bir kullanım senaryoları grubuna örnek olarak bir marketteki satış noktası (POS) uygulaması verilmiştir. Bir sistemde bir çok senaryo grubu bulunabilir.
Örneğin market sisteminde de satış işlemleri bir senaryolar grubu, ürün iadesi de başka bir senaryolar grubu olabilir. Bu örnekte satış işlemleri (Process Sale) senaryo grubu gösterilmiştir.
3.3.2.5.1. Senaryo Grubu (Use Case) SG1: Satış İşlemleri
- Konu: NextGen POS Market Sistemi
- Birincil Aktör: Kasa Görevlisi
- İlgililer (Aktörler) ve Beklentileri (Stakeholders and Interests):
- Kasa Görevlisi: Bilgilerin doğru ve hızlı girilmesi, toplamın doğru hesaplanması, para üstünün doğru hesaplanması
- Satış Elemanı: Komisyonun doğru hesaplanması ve kayıt edilmesi
- Müdür: Yetkili işlemleri (kasa görevlisinin yapamadığı) kolaylıkla yapabilmek
- Vergi Dairesi: Vergilerin doğru hesaplanabilmesi ve toplanabilmesi
- Kredi Kartı Asıllama Merkezi: Ödeme bilgilerinin doğru formatta gelmesi ve asıllama bilgilerinin kayıt edilmesi
- Ön Koşullar (Preconditions): Kasa görevlisi sisteme giriş yapmıştır.
- Son Koşullar (Postconditions): Satış bilgileri kayıt edilmiştir. Vergi doğru olarak hesaplanmıştır. Muhasebe ve envanter kayıtları güncellenmiştir. Komisyon kayıt edilmiştir. Fatura oluşturulmuştur. Kredi kartı onayı kayıt edilmiştir.
3.3.2.5.2. Ana Başarılı Senaryo (Doğal Akış) (Main Success Scenario or Basic Flow)
- Müşteri ödeme noktasına almak istediği ürün ve hizmetler ile gelir.
- Kasa görevlisi yeni bir satış başlatır.
- Kasa görevlisi ürün kodunu sisteme girer.
- Sistem satış kalemini (maddesini) kayıt eder ve ürünün tanıtıcı bilgisini, fiyatını ve o anda kadar oluşan toplamı gösterir.
Kasa görevlisi 3ncü ve 4ncü maddeleri ürün kalmayıncaya kadar tekrar eder.
- Sistem toplamı verhilerle birlikte gösterir.
- Kasa görevlisi müşteriye toplamı söyler ve ödeme yapmasını ister.
- Müşteri ödeme yapar ve sistem ödeme bilgilerini alır.
- Sistem tamamlanan satış bilgilerini kayıt eder; satış ve ödeme ile ilgili bilgileri muhasebe ve envarter sistemlerine (bunlar dış sistemlerdir) gönderir.
- Sistem faturayı oluşturur.
- Müşteri ürün ve hizmetler ile ayrılır.
Uzantılar (Alternatif Akışlar - Extensions or Alternate Flows):
*a. Herhangi bir anda müdür yetkili bir işlem yapmak ister ve şifresini girer:
- Sistem müdür-yetkisi konumuna geçer.
- Müdür yetkili bir işlem gerçekleştirir. Örneğin satışı iptal eder, bir ürünün fiyatını indirir vs.
- Müdür sistemden çıkar.
- Sistem normal konuma (kasa görevlisi yetkisi) geçer.
Uzantılar (Alternatif Akışlar - Extensions or Alternate Flows) Devamı:
*b. Herhangi bir anda sistemde bir hata oluşur:
Bu durumlarda bilgilerin kayıt edilmesi ve sistemin kaldığı yerden devam edebilmesi istenir.
1. Kasa görevlisi sistemi yeniden başlatır, sisteme giriş yapar ve sistemin önceki durumdan devam etmesini ister.
2. Sistem önceki durumu oluşturur.2a. Sistem önceki durumu oluştururken anormallik sezer.
1. Sistem hata uyarısı verir, hatayı kayıt eder ve temiz (başlangıç) duruma geçer.
2. Kasa görevlisi yeni bir satış başlatır.
3a. Geçersiz bir ürün kodu (Sistemde bulunamadı):
1. Sistem hata uyarısı verir, ürünü reddeder.
2. Kasa görevlisi hataya tepki verir:2a. Ürünün üstünde okunabilir bir kod vardır:
1. Kasa görevlisi kodu sisteme elle (manual) girer.
2. Sistem ürünün tanıtıcı bilgisini ve fiyatını gösterir.2b. Ürünün üstünde kod yoktur, ama fiyatı yazılıdır:
1. Kasa görevlisi müdürden yetkili bir işlem yapmasını ister.
2. Müdür şifresini girer.
3. Kasa görevlisi fiyatı elle girer.
3b. Aynı üründen bir taneden fazla alınmıştır (5 şişe içecek):
1. Kasa görevlisi ürün kodunu ve adetini sisteme girer.
3-6a. Müşteri kasa görevlisine bir ürünü almaktan vazgeçtiğini söyler:
1. Kasa görevlisi satıştan çıkarılacak ürünün kodunu sisteme girer.
2. Sistem ürünü satıştan çıkarır ve geçerli toplamı gösterir.
3-6b. Müşteri alışverişten vazgeçtiğini söyler:
1. Kasa görevlisi satışı iptal eder.
Uzantılar (Alternatif Akışlar - Extensions or Alternate Flows) Devamı:
5. Müşteri indirim hakkı olduğunu söyler (müşteri kartına sahiptir):
1. Kasa görevlisi müşteri kodunu sisteme girer.
2. Sistem indirimi uygular ve yeni toplamı gösterir.
7a. Nakit ödeme:
1. Kasa görevlisi ödenen nakit miktarı sisteme girer.
2. Sistem para üstünü gösterir ve para çekmecesini açar.
3. Kasa görevlisi müşteriden ödemeyi alır ve para üstünü verir.
4. Sistem nakit ödemeyi kayıt eder.
7b. Kredi kartı ile ödeme:
1. ....
7c. Çek ile ödeme:
1. ....
Özel İstekler (Special Requirements):
- Düz kare monitör. Yazılar 1 metre uzaklıktan okunabilmeli.
- Kredi kartı sorgulamasının cevabı en geç 30 saniyede gelmeli.
- ....
Teknolojik Beklentiler (Technology Variations List):
*a. Müdür kendisini sisteme bir kart okutarak ya da tuş takımından şifresini girerek tanıtır.
3a. Ürün kodları bir barkod okuyucu ile veya tuş takımından elle girilebilir.
7b. Kredi kartı bilgiler kart okuyucu ile veya tuş takımından elle girilebilir.
....
Açık noktalar (Open Issues):
- Vergi kanunlarındaki değişim sistemi nasıl etkiler?
- Kasa görevlisi mesaisi bittiğinde sistemden çıkarken para çekmecesini de almalı mı?
- Müşteri kart okuyucuları doğrudan kendisi kullanabilir mi, yoksa kasa görevlisi ile mi sisteme erişmeli?
- ....
3.4. Kullanım Diyagramları (Use Case Diagram)
Kullanım senaryoları sadece düz metin (text) olarak değil, istendiğinde metin yerine UML diyagramı olarak da ifade edilebilirler.
Kullanım diyagramlarında, kullanım senaryolarının aktörler ile ve kendi aralarındaki ilişkileri grafik olarak gösterilir. Şekil 3.2' de kullanım diyagramlarının genel yapısı gösterilmiştir.
Şekilde de görüldüğü gibi bir sistemin içinde bir çok senaryo grubu bulunabilmekte ve değişik aktörler değişik senaryo grupları ile ilişkili olabilmektedir.
Ayrıca senaryoların kendi aralarında da içerme (include) ve genişletme (extend) ilişkileri bulunabilmektedir. Bu ilişkilerin anlamları aşağıda açıklanmıştır:
- İçerme (includes, uses):
Birçok senaryo grubunda kullanılan başka bir senaryo grubudur. Örneğin otomasyon sistemini kullanmak için giriş yapılması gerekir. Bir senaryonun içinden bir alt programa dallanıp geri dönmek gibidir. - Genişletme (extends):
Senaryo grupları doğal akışa göre hazırlanır. Çeşitli koşullar altında bu doğal akıştan sapmalar olabilir. Genişletme ilişkisi ana senaryodan ayrılma noktasından sonra yapılanları belirtir.
Şekil 3.2' de de görüldüğü gibi UML diyagramlarında bir şeklin anlamını açıklayan özel sözcükler (sterotype) <<...>> simgeleri arasına yazılır.
Aktörler çizgi adam şeklinde gösterildiği gibi bir dikdörtgen ile de ifade edilebilir. Bu durumda dikdörtgenin anlamını belirtmek için "streotype" kullanılır
Şekil 3.2: Kullanım Diyagramı (Use Case Diagram)
3.4.1. Örnek
Örnek: Öğrenci otomasyon sistemine ilişkin kullanım diyagramı
Şekil 3.3' te örnek olarak bir öğrenci otomasyon sisteminin bir kısmına ait kullanım diyagramı gösterilmiştir.
Örnek istemin içinde dört adet senaryo grubu bulunmaktadır:
- Sisteme giriş
- Derse kayıt
- Geç kayıt
- Sınıf listesi göster
Bu senaryo gruplarının arasında çeşitli ilişkiler geçerlidir. Örneğin derse kayıt ve sınıf listesini göster senaryoları sisteme giriş senaryosunu içermektedir. Çünkü derse kayıt senaryoları yürütülürken sisteme giriş senaryosunun de yürütülmesi gereklidir.
Diğer taraftan geç kayıt senaryosu derse kayıt senaryosunu genişletmektedir. Normal işlemler derse kayıt senaryolarında belirtilmektedir. Eğer öğrenci belirtilen sürede kayıt olmamışsa geç kayıt senaryosuna geçilmektedir.
Ayrıca aktörlerin aralarında da nesneye dayalı programlamadan anımsayacağımız genelleşme/özelleşme (generalization/specialization) ilişkisi bulunabilmektedir.
Örnekte kullanıcı adını verdiğimiz bir aktör vardır. Öğrenci ve öğretmen bu kullanıcının özel halleridir. Danışman ise öğretmen aktörünün özel bir halidir.
Kullanım diyagramı incelendiğinde tüm kullanıcıların (öğretmen ya da öğrenci) sisteme giriş senaryolarında aynı şekilde rol oynadıkları görülür.
Derse kayıtta ise öğrenci, sınıf listesini göster senaryolarında ise öğretmen aktörleri rol oynamaktadır. Geç kayıt senaryolarında öğretmen aktörünün özel bir hali olan danışman aktörü yer almaktadır.
Şekil 3.3: Örnek Kullanım Diyagramı (Öğrenci Otomasyon Sistemi)
3.5. Etkileşim Diyagramı (Interaction Diagram)
Şekil 3.4: Örnek Etkileşim Diyagramı
Kullanım diyagramları sadece istemde hangi senaryo gruplarının ve hangi aktörlerin yer aldığını gösterir.
Aktörler ile sistem arasına geçen olayları yani senaryoların adımlarını göstermek için etkileşim diyagramları (interaction diagram) çizilir.
Örnek POS sistemine etkileşim diyagramı Şekil 3.4' te gösterilmiştir. Bu örnekte aktör kasa görevlisidir. Kasa görevlisi ile sistem arasındaki mesaj akışı (etkileşim) diyagramda gösterilmiştir.
Senaryoları ifade ederken aynı anda hem metin tipi senaryo yazımına hem de UML ile kullanım diyagramlarını ve etkileşim diyagramlarını çizmeye gerek yoktur.
Senaryoları belirtmek için metin tipi yazım ya da diyagram gösteriminden biri tercih edilir.
3.6. Kullanım Senaryolarının Yazılması
Kullanım senaryoları, yazılım siparişini veren firma ile görüşülerek yazılır. Bu görüşmelerde sistemin nasıl çalışacağı açıkça ortaya konmalıdır. Yazılımı doğrudan kullanacak olan kişilerle de görüşmeler yapılmalıdır. Bu görüşmelerde aşağıdaki sorular sorularak senaryoların yazılmasında gerekli olan bilgilere ulaşılabilir.
Aktörlerin belirlenmesi ve aktörlerden yararlanarak sistem davranışının belirlenmesi için sorulabilecek sorular aşağıdaki animasyonda verilmiştir.
- Sistemin temel işlevlerini kim kullanacak?
- Günlük işleri yapmak üzere kim sistemin desteğine gerek duyar?
- Sistemin bakımını ve işletmesini kim yapacak?
- sistem hangi cihazları kullanacak?
- hangi diğer sistemler ile etkileşimde bulunacak?
- Bu sistemin sonuçları kimi ilgilendirir?
Aktörlerin belirlenmesi için sorulabilecek sorular
- Aktörlerin temel işleri nedir?
- Aktör sistem bilgilerine erişmeli mi? Erişim tipi?
- Aktör dış durumlardaki değişiklikleri bildirecek mi?
- Durum değişiklikleri (hangileri?) aktöre bildirilecek mi?
- Aktör hangi işlevlere gerek duyar?
Aktörlerden yararlanarak sistem davranışının belirlenmesi için sorulabilecek sorular
Diğer Sorular: Bazı davranışlar aktörlerden yola çıkarak belirlenemeyebilir. Bu durumda aşağıdaki soruları da sormakta yarar vardır:
- Sistemin gerek duyduğu girişler ve çıkışlar nelerdir?
- Sistem hangi dış olaylardan etkilenir?
- Şu andaki sistemin (eğer firmada aynı iş için kullanılan eski bir sistem varsa) eksikleri ve problemleri nelerdir?
- Periyodik olarak gerçekleştirilen işler var mı?
3.7. Kullanım Senaryoları Yönteminin Yararları
İsteklerin doğru ve eksiksiz olarak belirlenebilmesi yazılımın kalitesi açısından önemlidir. Kullanım senaryoları yöntemi bu noktada aşağıdaki yararları sağlar:
- Kolay anlaşışır. Müşteri (yazılımın kullanıcısı) ile yazılım hazırlayacak grup arasında iletişimi kolaylaştırır.
- Sistemde gerekli olan unsurların belirlenmesini kolaylaştırır, unutulmalarını önler.
- Sınama (verification) olanağı sağlar. Gerçeklenen sistem senaryolar ile sınanabilir. Tamamlanmış olan yazılıma senaryolar uygulandığında eğer sistem her adımda senaryoda yazılmış olayları yerine getiriyorsa yazılımın sağlanması yapılmış olur.
- Kullanım senaryoları nesneye dayalı değildir. Bu yöntem gerekirse başka programlama yöntemleri için de kullanılabilir. Diğer taraftan kullanım senaryoları nesneye dayalı modelleme için uygun bir başlangıç noktası oluştururlar. Bundan sonrali bölümlerde çözümleme ve tasarlama konuları anlatılırken kullanım senaryolarının bu yararı da gösterilecektir.
Değerlendirme Soruları-1
Değerlendirme Soruları-2
Bölüm 4: Analiz: Uyguluma (Problem) Dömeninin Modellenmesi
4.1. Giriş
Problem domeninin yani gerçek dünyanın modelinin oluşturulması, problemi daha iyi anlayabilmek için problemin kağıt üstünde bir resminin oluşturulması anlamına gelir.
Bu modeli oluşturmak problemin çözümlenmesi (analysis) aşamasını oluşturur. Bu nedenle bu aşamada problemi çözmek için değil anlamak için çaba gösterilir.
Problemi çözmek ise tasarım aşamasının konusudur.
İsteklerin çözümlenmesinde (modellenmesinde) oluşturulan kullanım senaryoları (use case) nesneye dayalı özellikler taşımaz. Uygulama domeninin modellenmesinde ise nesneye dayalı yöntem kullanılacaktır.
Uygulama domeninin modelinde gerçek dünyayı (yani tasarlanacak olan sistemi) oluşturan kavramsal sınıflar ve nesneler yar alır. Bu model oluşturulurken yazılım sınıfları (çözüm) düşünülmez, çünkü bu aşamada henüz program yazılmıyor.
Model UML kullanılarak görsel hale getirilir.
Uygulama domeninin modeli aşağıdaki bilgileri içeren sınıf diyagramları ile belirtilir:
- Gerçek dünyadaki kavramsal sınıflar ve nesneler (Yazılım sınıfları/nesneleri değil!)
- Sınıflar arasındaki ilişkiler (bağlantılar - association),
- Sınıfların nitelikleri (attributes)
Örnek olarak Şekil 4.1' de bu ders boyunca üzerinde çalışılacak olan POS (market satış) sisteminin analiz modeli tamamlandığında çizilecek olan sınıf diyagramının bir kısmı gösterilmiştir.
Şekil 4.1' deki diyagramın nasıl oluşturulduğu ve kullanılan simgelerin anlamları ilerleyen bölümlerde açıklanacaktır.
Şekil 4.1: Örnek bir sınıf diyagramı
4.2. Kavramsal Sınıfların Belirlenmesi (Bulunması)
Kavramsal sınıflar gerçek dünyadaki somut ve soyut varlıklara karşı düşen sınıflardır. Örneğin; öğretmen, öğrenci, ders, işçi, banka hesabı, para, satış vb.
Çözümlemenin (analiz) ilk aşamasını kavramsal sınıfların (conceptual class) belirlenmesi oluşturur.
En çok kullanılan iki temel yöntem:
|
İki yöntem birlikte de kullanılabilir.
4.2.1. Kavramsal Sınıfların Kategorileri
Deneyimlerden yararlanılarak uygulama domenindeki sınıfların hangi kategorilerde yer aldığı belirlenmiş ve bir liste yapılmıştır. Modellenecek olan uygulama incelenerek bu listedeki kategorilere uyan unsurlar belirlenmeye çalışılır.
Bazı kategoriler ve örnek kavramsal sınıflar:
- Fiziksel ve somut nesneler: Ürün, terminal, uçak
- İşlem (Trasaction): satış, Ödeme, rezervasyon
- İşlem Kalemleri (Transaction line itemes): Satış kalemi
- İşleme veya hizmetle ilgili ürün ve kalemler: Ürün, uçuş, yemek
- İşlemin ve Hizmetin Yeri: dükkan, havalimanı, sınıf
- Kişilerin ve kuruluşların rolleri: Müşteri, yolcu, öğretmen, havayolu şirketi, dükkan
- İşlem kayıtlarının tutulduğu yerler: Satış defteri, uçuş planı
- Nesnelerin tanıtıcı bilgileri (description): Ürün tanımı, uçuş tanımı
- Kataloglar (Nesnelerin tanıtıcı bilgilerini tutarlar): Ürün kataloğu, uçuş kataloğu
- Başka nesneler içerebilen taşıyıcılar (container): Dükkan, kutu, uçak
- Taşıyıcılarda yer alan nesneler: (Ürün, yolcu)
- Finans elemanları: Çek , kart
4.2.2. Kavramsal Sınıfların İsimler Yardımıyla Belirlenmesi
Kavramsal sınıfların belirlenmesinde kullanılan ikinci yöntem ise senaryolarda ve problemin tanımında yer alan isim ve isim tamlamalarından yararlanılmasıdır.
Kullanım senaryolarında yer alan tüm isimler ve isim tamlamaları işaretlenir.
Çoğunlukla ilk aşamada gereğinden fazla sınıf elde edilir. Daha sonra uygulanan eleme yöntemi ile gereksiz sınıflar ayıklanır.
Bu yöntemin uygulanmasına örnek olarak ders notlarının 3.3. bölümünde yazılan SG1 numaralı "Satış İşlemleri" senaryo grubu ele alınacaktır.
Yinelemeli (iterative) yazılım geliştirmede her yinelemede (iteration) senaryoların sadece bir kısmı üzerinde çalışılıyor olabilir. Bu örnekte de sadece senaryo grubunun doğal akış kısmı ele alınmış ve burada isim ve isim tamlamaları işaretlenmiştir.
Her ismin bir defa işaretlenmesi yeterlidir.
Ana Başarılı Senaryo (Doğal Akış)
(Main Sucess Scenario or Basic Flow)
- Müşteri ödeme noktasına almak istediği ürün ve hizmetler ile gelir.
- Kasa görevlisi yeni bir satış başlatır.
- Kasa görevlisi ürün kodunu sisteme girer.
- sistem satış kalemini (maddesini) kayıt eder ve ürünün tanıtıcı bilgisini, fiyatını ve o anda kadar oluşan toplam (tutarı) gösterir.
Kasa görevlisi 3ncü ve 4ncü maddeleri ürün kalmayıncaya kadar tekrar eder.
- Sistem toplamı vergilerle birlikte gösterir.
- Kasa görevlisi müşteriye toplamı söyle ve ödeme yapmasını ister.
- Müşteri ödeme yapar ve sistem ödeme bilgilerini alır.
- Sistem tamamlanan satış bilgilerini kayıt eder; satış ve ödeme ile ilgili bilgileri muhasebe ve envarter sistemlerine (bunlar dış sistemlerdir) gönderir.
- Sistem faturayı oluşturur.
- Müşteri ürün ve hizmetler ile ayrılır.
4.2.2.1. Gereksiz Sınıfların Elenmesi
Senaryolardaki tüm isimler kavramsal sınıflara karşılık gelmez. Gereksiz sınıfların elenmesi gerekir. Hangi sınıfların gereksiz olduğu aşağıda sıralanmıştır:
Fazlalık sınıflar (Redundant classes):
Aynı unsuru ifade eden iki sınıftan daha tanımlayıcı olan alınır. Örneğin: Kişi - müşteri sınıflarından müşteri daha belirleyicidir.
İlgisiz sınıflar (Irrelevant classes):
Problemin çözümü ile ilgili olmayan ya da çözümlemenin o iterasyonunda ilgilenilmeyen unsurlar elenir. Örneğin Vergi, kredi kartı.
Belirsiz sınıflar (Vague classes):
Sınırları iyi çizilmemiş, fazla geniş (kaba) tanımı olan sınıflar elenir. Bunlar çoğunlukla başka sınıfların parçalarıdır ya da birden fazla sınıftan oluşurlar. Örneğin: Muhasebe sistemi.
Nitelikler (Attributes):
Nitelikler de isimler ile ifade edildiğinden sınıflar ile karıştırılabilirler. Kendi başlarına varlıkları anlamlı olmayan sadece başka sınıfların niteliklerini oluşturan unsurlar olası sınıflar listesinden silinirler. Örnek: Miktar.
İşlemler (Operations):
Sadece başka nesneler üzerinden uygulanan işlemler sınıf olamaz. Kendi nitelikleri olan ve başka olaylardan etkilenen işlemler ise sınıftır. Örneğin "ödeme" bir işlem gibi görünmekte ancak kendine ait özellikleri (miktar, para birimi, tarih vb.) olduğundan tek başına bir sınıftır.
Gerçekleme unsurları (Implementation constructs):
Gerçekleme aşamasını ilgilendiren unsurlaruygulama domeninin çözümlenmesinde yer almazlar. Örneğin: Veri tabanı.
Gereksiz sınıflar elenirken bazı fazlalıkların kalması çok olumsuz bir durum yaratmaz çünkü analiz aşamasındaki fazlalık sınıflar tasarım aşamasında elenebilir. Bu nedenle analiz aşamasında bazı sınıfların unutulmasındansa fazlalık sınıfların olması yeğlenir.
4.2.3. Problem Domeni Modelini Oluşturmada Haritacı (Mapmaker) Yöntemi
Gerçek dünyanın haritasını oluşturmada yaralanılan kavramlar burada da kullanılabilir:
- Fiziksel Dünyadaki gerçek isimleri kullanın. Haritadaki şehirlerin isimleri ile gerçek dünyadaki şehirlerin isimleri aynıdır. Kavramsal sınıflara gerçek dünyadaki isimleri verin. Örneğin; satış, dükkan.
- İlgisiz özellikleri dışlayın. Siyasi bir haritada dağlar ve ovalar gösterilmez. Problemin çözümünü ilgilendirmeyen veya o yineleme adımında ele alınmayacak unsurları analiz domenine koymayın.
- Var olmayan şeyleri eklemeyin. Analiz yaparken sadece gerçekte var olan unsurları modele koyun. Yorum yaparak var olmayan unsurları sisteme eklemeyin.
4.2.4. Örnek POS Sistemine Ait Kavramsal Sınıflar
Örnek probleme ilişkin kavramsal sınıflar Şekil 4.2' de gösterilmiştir. Her sınıfın anlamını açıklayan bir sözlük hazırlanması yararlı olacaktır.
Şekil 4.2: Örnek sisteme ilişkin kavramsal sınıflar
Bu sınıflar belirlendiğinde çözümlemenin (analiz) ilk adımı tamamlanmış olur. Bundan sonra kavramsal sınıflar arasındaki bağlantıların (ilişkilerin) ve sınıfların niteliklerinin belirlenmesi gerekir.
4.2.5. Betimleme (Specification or description) Sınıflarına Gerek Duyulması
Dükkanda satılan malzemelerle ilgili fiyat, tip numarası gibi bilgilerin o malzemeye ilişkin nesnelerde tutulması (nitelik olduğu) öngörülebilir.
Ancak dükkandaki o cinsten tüm malzeme satıldığında (nesneler yok olduğunda) o malzemeyle ilgili bilgiler de kaybolur.
Böyle sistemlerde bir nesneyi betimleyen bilgilerin Şekil 4.3' te gösterildiği gibi başka sınıflarda tutulması gerekir.
Şekil 4.3: Betimleme sınıfları
Ne zaman gerek duyulur?
- Bir malzeme ya da hizmetle ilgili bilgilere o malzeme ya da hizmetin var olup olmamasından bağımsız olarak erişmek gerekli ise,
- Bir nesnenin yok edilmesi bilgi kaybına neden oluyorsa,
- Gereksiz bilgi tekrarını önlüyorsa.
4.3. Kavramsal Sınıflar Arasındaki Bağlantıların Belirlenmesi
Uygulama domeninin modeli oluşturulurken ilk aşamada kavramsal sınıflar bulunur.
İkinci aşamada ise bu sınıflar arasındaki bağlantılar (associations) belirlenir.
4.3.1. Bağlantıların UML Diyagramlarında Gösterilmesi
Bağlantılara ilişkin UML notasyonu sekil 4.4' te gösterilmiştir:
Şekil 4.4: Bağlantılara ilişkin UML notasyonu
4.3.2. Çoğullama (multipicity) Sayısı
Çoğullama sayısı o sınıftan kaç tane nesnenin, diğer sınıftan kaç tane nesne ile belli bir anda geçerli olarak ilişkilendirilebileceğini gösterir.
Çoğullama sayısı, modeli nasıl kullanacağımıza bağlıdır. Şekil 4.5' teki örnekte bir malın tükenip depoda bulunmaması bizi ilgilendiriyorsa Depo ucuna ait çoğullama sayısı 0..1 olabilir. Aksi durumda bu sayının 1 olması yazılım açısından daha uygundur.
4.3.3. Bağlantıların Bulunmasına İlişkin Yöntemler
Bu konuda da değişik yöntemler kullanılmaktadır:
|
Bu bölümde yaygın bağlantılar listesinden yararlanılacaktır.
4.3.3.1. Yaygın Bağlantılar Listesi (Common Associations List)
Bu yöntemde, kavramsala sınıflar arasında aşağıdaki ilişkilerin varlığı aranır:
- A ve B birbirleri ile ilgili işlemlerdir. Ödeme - Satış, Rezervasyon - İptal
- A, B işleminin bir maddesidir (kalemidir). Satış - Satış kalemi
- A, B işleminin bir ürünü veya hizmetidir. Ürün - Satış kalemi (veya Satış)
- A, B işlemi ile ilgili bir roldür. Müşteri - Ödeme
- A, B'nin fiziksel veya mantıksal bir parçasıdır. Koltuk - Uçak, Satış kalemi - Satış
- A, B tarafından içerilir. terminal - Dükkan, Yolcu - Uçak
- A, B'nin tanımlayıcısıdır. Ürün tanımlayıcı - Ürün
- A'nın kaydı B tarafından tutulur. Satış - Terminal
- A, B'nin üyesidir. Kasa görevlisi - dükkan, Pilot - Havayolu şirketi
- A, organizasyonda B'nin bir alt bölümüdür. Departman - Dükkan
- A, B'yi yönetir, kullanır veya B'ye sahiptir. Kasa gösrevlisi - Terminal
- A, B'ye komşudur, yanında yer alır. Satış kalemi - satış kalemi, Şehir - Şehir
Bu yöntemde, iki kavram arasındaki ilişkiye ait bilgi belli bir süre sistem tarafından bilinmesi gerekiyorsa (need-to-know association) göz önüne alınır.
İki kavram arasındaki ilişki tasarlanan sistem açısından gerekli değilse dikkate alınmaz. Örneğin Satış - Müdür bağlantısı gerekli olmayabilir.
4.3.3.2. Kullanım Senaryolarındaki Fiillerden Yararlanmak
Diğer yöntemde ise kullanım senaryolarındaki fiiller dikkate alınarak tüm olası bağlantılar (ilişkiler) listelenir.
Aşağıdaki maddeler dikkate alınarak gereksiz bağlantılar ayıklanır:
- Önceki aşamada elenmiş olan sınıflar arasındaki bağlantılar gereksizdir.
- Sistemin amacı açısından gereksiz/ilgisiz olan bağlantılar.
- Gerçekleme aşamasını ilgilendiren bağlantılar.
- Faaliyet (Actions): Örnek ATM cihazı kredi kartı kabul eder. Bu cümle bir ilişkiyi değil müşteri ile ATM arasındaki etkileşimleri içerir.
- Üçlü (ternary) bağlantılar ikili bağlantılar şeklinde ifade edilmelidir.
- "Memur hesap ile ilgili işlemleri girer." ifadesini
- "Memur işlemleri girer." "İşlemler hesapla ilgilidir." şeklinde ikiye bölmek gerekir.
- Başka bağlantılardan tğretilebilen (derived) ilişikiler edenebilir.
Örnek:
"Satış dükkanda gerçekleşir" ilişkisi, "satış terminalde yapılır" ve "terminal dükkanda bulunur" ilişkilerinden türetilebilir.
Genellikle UML diyagramında iki sınıf arasında birden fazla yol varsa, çözümlemede fazlalık (türetilebilir) ilişkiler olduğu düşünülebilir.
Her türetilebilir ilişkinin elenmesi doğru değildir. sistem açısından önemli olanlar kalabilir. Örneğin toplumda Baba - kardeş yerine Amca ilişkisi kullanılmaktadır.
4.3.4. Bağlantıların Bulunmasına İlişkin Öneriler
- Sistemin tasarımını ilgilendiren bağlantılara (need-to-know) yoğunlaşmak gerekir.
- Bağlantılara doğru isimler atanmalı. Tip adı - fiil - tip adı
Bağlantının adı sadece bir ya da bir kaç işlemin adı değil bir ilişkinin ifadesi olmalıdır.
Bağlantıları içeren örnek UML sınıf diyagramları Şekil 4.7' de gösterilmiştir.
Şekil 4.7: UML'de Bağlantıların Gösterilmesi
- Gerekli olan yerlere rol adları da yazılmalıdır. Roller bağlantının iki ucunu oluştururlar.
- Sahip olma, oluşma (aggregation, compositon) ilişkilerini ayrıntılı olarak belirlemek bu aşamada gereksizdir.
- Bu aşamada bazı bağlantıların unutulması sistem tasarımını çok etkilemez.
- Kavramsal sınıfların doğru olarak belirlenmesi bağlantılardan daha önemlidir.
- Gereğinden fazla bağlantı modelin anlaşırlılığını azaltabilir.
4.3.4.1. Örnek POS Sisteminin Bağlantıları Da İçeren UML Sınıf Diyagramı
Derste ele alınan örnek POS sisteminin bağlantıları da içeren UML sınıf diyagramı şekil 4.8' de gösterilmiştir.
Şekil 4.8: Örnek POS Sisteminin Bağlantıları da İçeren UML Sınıf Diyagramı
4.4. Kavramsal Sınıfların Niteliklerinin (Attributes) Belirlenmesi
Bir sınıfın nitelikleri, o sınıftan nesneler yaratıldığında nesnelere özgü değerler alabilen verilerdir.
Bu aşamada amaç, üzerinde çalışılan senaryoları ilgilendiren nitelikler bulmaktır.
Nitelikler genellikle basit veri tipleri (int, string, bool, date) ifade edilirler.
Eğer bu aşamada nitelik olarak düşünülen veri daha karmaşık bir tipte ise o verinin bir bağlantı ya da ayrı bir sınıf olma olasılığı yüksektir.
Şekil 4.9'da gösterilen örnekte Terminal, Kasa Görevlisi tarafından kullanılan bir varlıktır ama onun niteliği değildir.
Şekil 4.9: Örnek POS Sisteminin Bağlantıları da İçeren UML Sınıf Diyagramı
4.4.1. Karmaşık Niteliklerin Gösterilmesi
Bazı durumlarda nitelikler basit veri tiplerinden oluşmazlar.
Eğer bir nitelikte aşağıdaki özellikler varsa başka bir sınıf ile ifade edilmesi doğru olur.
- Birden fazla alandan oluşuyorsa: Telefon no, ad/soyad
- Üzerinde işlem yapılıyorsa: Kredi kartı numarası onaylanması
- Kendi nitelikleri varsa: Fiyatın geçerlilik tarihi olabilir.
Bu tip nitelikler şekil 4.10' da gösterildiği gibi iki farklı şekilde de ifade edilebilir.
Şekil 4.10: Karmaşık Niteliklerin Gösterilmesi
4.4.2. Birimleri Olan Niteliklerin Gösterilmesi
Birimleri olan büyüklükleri de basit veri tipleri ile göstermek doğru olmaz. Örneğin şekil 4.11' de gösterildiği gibi satışın tutarını sadece sayı olarak ifade etmek yarar sağlamaz. Bunun yerine bilinen bir veri tipi olan Para kullanılabilir.
Şekil 4.11: Birimleri Olan Niteliklerin Gösterilmesi
4.4.3. Niteliklerin Özelliklerinin Gösterilmesi
Eğer çözümleme (analiz) sırasında kavramsal sınıfların özellikleri hakkında daha fazla bilgi elde edilmişse bunlar da diyagramlar da belirtilir.
Örneğin niteliklere ilişkin erişim hakları diyagramlarda gösterilebilir. "+" simgesi bir niteliğin açık (public), "-" simgesi ise özel (private) oldupunu belirtir.
"/" simgesi ise bir niteliğin diğer niteliklerden türetilebilen (elde edilebilen) (derived) bir nitelik olduğunu belirtir.
Şekil 4.12' de niteliklerin sınıf diyagramlarında nasıl yer alacağı gösterilmiştir.
Şekil 4.12: Niteliklerin Özelliklerinin Gösterilmesi
Analiz aşamasında elde edilen sınıflar sadece problemdeki kavramların resmidir, yazılım sınıfları değillerdir. Tasarım aşamasında yazılım sınıfları oluşturulurken kavramsal sınıflar kaynak olarak kullanılacaktır. Örnek POS sistemine ilişkin uygulama domeni modelinin bir kısmı Şekil 4.13'te UML sınıf diyagramı şeklinde gösterilmiştir.
Şekil 4.13: Örnek POS Sisteminin kısmi uygulama modeli
4.5. Kullanım Senaryolarında Sözleşmeler (Contracts)
Birçok uygulamada kullanım senaryolarını (use-case) yazmak isteklerin modellenmesi için yeterlidir. Bazı durumlarda karmaşık işlemlerin daha iyi anlaşılabilmesi için sözleşmeleri yazmak yararlı olur.
Sözleşmeler, ön koşullar sağlandığında sistemdeki işlemler gerçekleştirilince sistemin (uygulama domeni nesnelerinin) alacağı durumların (son koşullar) tarif edilmesidir.
Senaryolarda, aktörler ile sistem arasındaki etkileşim belirtilir. Sözleşmelerde ise sistem içi nesnelerdeki değişim de belirtilebilir.
Sözleşmelerin yazılmasında izlenecek yöntem:
- Sistem etkileşim diyagramlarından işlemler belirlenir.
- Karmaşık işlemler için sözleşmeler yazılır.
- Sözleşmelerde önemli olan son koşullardır. Son koşullar aşağıdaki kategorilerden oluşur:
- Bir nesne (instance) yaratma yok etme
- Bir niteliğin güncellenmesi
- Bir bağlantı oluşturma, koparma
Sözleşmelerde sözü edilen nesneler uygulama domeni (gerçek dünya) nesneleridir.
Sözleşmeleri yazmaktaki amaç problemi çözmek değil anlamaktır. Senaryoların yazılmasına benzer şekilde, sözleşmelerin de bölümleri ve bir yazım biçimleri vardır.
Sözleşmelerin bölümleri:
- Sözleşmenin numarası ve adı
- Sözleşmenin ait olduğu işlem
- Referans: Sözleşmenin ilgili olduğu kullanım senaryosu
- Ön koşullar: Sözleşmenin sağlanabilmesi (o işlemin gerçekleşmesi) için işleme gelindiğinde gerçekleşmesi zorunlu olan ön koşullar.
- Son koşullar: Sistemde meydana gelecek olan değişiklikler. Nesne yaratma, nesneleri ilişkilendirme, nitelikleri güncelleme. Dikkat: buradakiler gerçek dünya nesneleridir.
Son koşullar yazılırken geçmiş zaman kipi kullanılır. Çünkü bu bölümde yazılan maddeler, işlem gerçekleştiğinde sistemdeki nesnelerin hangi durumlara geldiğini belirtmektedir.
Bu bölümdeki örneklerde, örnek POS sistemine ait SG1: Satış İşlemleri kullanım senaryolarındaki bazı işlemlere ilişkin sözleşmelerin yazılması gösterilmiştir.
4.5.1. Örnek
Bu örnekte, şekil 4.14' te gösterilen senaryoda yer alan urunGir işlemi için sözleşme yazılmıştır. Sözleşmenin adı urunGir numarası ise SO2' dir.
Şekil 4.14: Örnek Etkileşim Diyagramı
Sözleşme (Contract) SO2: urunGir
İşlem: urunGir(urunkodu: UrunKodu, miktar: integer)
Referans: Senaryo Grubu SG1: Satış İşlemleri
Ön Koşul: Bir satış başlamış olmalı
Son Koşullar:
- Bir SatışKAlemi nesnesi sk yaratıldı. (Nesne yaratma)
- sk o anda geçerli olan Satış ile ilişkilendirildi. (Bağlantı oluşturma)
- sk.miktar girişte verilen miktara eşitlendi. (Nitelik güncelleme)
- sk, urunKodu kullanılarak uygun UrunTanımlayıcı ile ilişkilendirildi. (Bağlantı oluşturma)
Burada sözü edilen nesneler (örneğin sk), bağlantılar ve niteliklerin hepsi uygulama domeni ile ilgilidir.
Sözleşmeler, uygulama modelinde bazı değişiklikler (eklemeler) yapılmasına neden olabilirler. Aşağıdaki örnekte SatisBitir() işlemi için sözleşme yazılmıştır. Bu sistemde, biten satışların silinmediği sadece "bitti" olarak işaretlendiği varsayılmıştır. Sözleşme yazılırken Satış sınıfında bitti_mi adlı mantıksal (Boolean) bir niteliğin olduğu görülür ve bu nitelik analiz modeline eklenir. Bu nitelik analiz yapılırken gözden kaçmış olabilir.
Örnek: endSale
Sözleşme (Contract) SO3: satisBitir
İşlem: satisBitir()
Referans: Senaryo Grubu SG1: Satış İşlemleri
Ön Koşul: Bir satış başlamıştır
Son Koşul: Satış.bitti_mi niteliğine doğru (true) değeri atandı (Nitelik güncelleme)
Sözleşmeler o işlemin nasıl yapılacağını göstermezler. "Nasıl?" sorusunun cevabı tasarımda aranır.
Değerlendirme Soruları-1
Değerlendirme Soruları-2
Bölüm 5: UML Etkileşim Diyagramları (Interaction Diagrams)
5.1. Etkileşim Diyagramlarının (Interaction Diagrams) Türleri
Tasarım yöntemlerini incelemeden önce tasarımı ifade etmek için kullanılacak olan UML etkileşim diyagramları incelenecektir. UML' de iki tür etkileşim diyagramı vardır:
|
5.1.1. İletişim Diyagramları (Communication Diagrams)
Bu diyagramların eski adı UML 1.x'te: İşbirliği Diyagramları (Collaboration Diagrams)
Nesneler arası etkileşim (mesajlar) bir graf şeklinde gösterilir.
Şekil 5.1: Örnek bir İletişim Diyagramı
Özellikleri:
+ Az yer kaplar.
+ Mesajların dallanmalarını göstermek kolaydır.
- Mesajların sıralarını anlamak zordur.
İletişim diyagramları bölüm 5.2' de ayrıntılı olarak açıklanmıştır.
5.1.2. Ardışıl Diyagramlar (Sequence Diagrams)
Nesneler yan yana gösterilir. Etkileşimler (mesajlar) oluştukları sıra ile yukarıdan aşağıya doğru çizilirler.
Şekil 5.2: Örnek Bir Ardışıl Diyagram
Özellikleri:
- Her yeni nesne çizimin sağına eklenir.
- Fazla yer kaplar.
- Mesajların zaman içinde sıralarını anlamak daha kolaydır.
Ardışıl diyagramları bölüm 5.3' te ayrıntılı olarak açıklanmıştır. Bir tasarımda nesneler arası etkileşimi göstermek için iki diyagram tipinden biri seçilerek kullanılır.
5.2. İletişim (Communication) Diyagramları (Örnek)
Örnek:
Şekil 5.3' te, ders boyunca üzerinde çalışılacak olan POS (market satış) sisteminin tasarımı tamamlandığında çizilecek olan iletişim diyagramlarından biri gösterilmiştir.
Terminal, Satis ve Odeme sistem tasarlanırken oluşturulacak sınıfların adıdır. Bu nedenle Türkçe karakterler kullanılmamıştır. Sınıf adının önüne iki nokta (:) sembolünün yazılması o sınıftan yaratılan bir nesne anlamına gelir.
Buna göre : Terminal yazımı, Terminal adlı sınıftan yaratılmış herhangi bir nesne anlamına gelir.
Şekil 5.3: Örnek bir İletişim Diyagramı
Diyagramın Açıklaması:
Şekilde gösterilen UML iletişim diyagramının anlamı aşağıda açıklanmıştır:
Terminal adlı sınıftan yaratılmış bir nesnenin odemeYap(verilenNakit) adlı metodu canlandırıldığında bu metodun içinde Satis adlı sınıftan yaratılan bir nesneye odemeYap(verilenNakit) adlı başka bir mesaj gönderilir. :Satis nesnesi bu metodun içinde Odeme adlı sınıftan bir nesne yaratır.
Konuyu daha iyi açıklamak için Satis sınıfına ait program kodu C++ dilinde aşağıda verilmiştir.
private:
Odeme * odeme;
public:
void odemeYap(const Para& verilenNakit){ // Satis’in odemeYap metodu
odeme = new Odeme(verilenNakit); // Odeme sınıfından nesne yaratılıyor
// Diğer işlemler ...
}
// Diğer üyeler ...
};
UML diyagramlarından kodlamaya (programlamaya) nasıl geçildiği bölüm 5.8'de ayrıntılı olarak açıklanacaktır.
5.2.1. Mesaj Sıra Numaraları
Mesajlar gönderildikleri sıraya göre numaralanırlar. İlk mesaja numara verilmez.
Bir mesajın neden olduğu diğer mesajlara da sebep mesajın numarasına bağlı alt numaralar verilir.
Şekil 5.4' te, ClassA' nın bir nesnesi ClassB' nin bir nesnesine msg2 mesajını yolladığında ClassB' nin nesnesi de ClassC' nin nesnesine msg3 mesajını gönderecektir. msg3 sonlandığında tekrar msg2' ye dönülecektir.
Hatırlatma: Mesaj göndermek nesneye dayalı programlamada bir nesnenin metodunun çağırılmasını anlamına gelir.
Şekil 5.4: İletişim Diyagramlarında mesaj sıralarının gösterilmesi
5.2.2. Kendine Mesaj
Şekil 5.5: İletişim diyagramlarında kendine mesaj gönderme |
Nesneler kendilerine de mesaj gönderebilirler, yani kendi metotlarını çağırabilirler.
Şekil 5.5' teki örnekte, :Terminal nesnesi, msg1 metodunun içinde kendi sil metodunu çağırmaktadır.
5.2.3. Nesne Yaratma
Bir mesaj nesne yaratılmasını sağlamak için gönderiliyorsa normal olarak bu mesaja create adı verilir ve bir kurucu fonksiyon (constructor) çağrısı olarak yorumlanır.
Eğer başka bir isim verilirse <> tanımlayıcısı kullanılır.
Şekil 5.6' da her iki durum da gösterilmiştir. Bu örnekte, :Terminal nesnesi :Satis nesnesini yaratmaktadır.
Şekil 5.6: İletişim Diyagramlarında nesne yaratma
5.2.4. Koşullu Mesajlar
Bu tür mesajlar sadece belli bir koşul gerçekleştiğinde gönderilebilirler. Eğer köşeli parantez içinde verilen koşul gerçekleşmemişse o mesaj gönderilmez, sonraki mesaja geçilir.
Şekil 5.7' de verilen örnekte A sınıfından yaratılan nesnenin mesaj1 metodunun içinde renk değeri sınanmaktadır. Eğer renk = mavi koşulu doğru ise :A nesnesi, :B nesnesine hesapla() mesajını gönderecektir.
Koşul doğru değilse bir sonraki mesajla (örneğin 2 numaralı) devam edilecektir.
Bu durum programlamadaki if-then yapısına karşı düşmektedir.
Şekil 5.7: İletişim Diyagramlarında koşullu mesajlar
5.2.5. Karşılıklı Dışlamalı Mesajlar
Nesneler arası etkileşim, belli bir koşula bağlı olarak farklı yollar izleyebilir.
Şekil 5.8' de verilen örnekte "test" koşuluna bağlı olarak a ya da b yollarından biri izlenecektir.
Diyagramda gösterilen sistem SınıfA' dan yaratılan nesneye msg1() mesajının gelmesi ile çalışmaya başlar. Bu metodun içinde test koşuluna bakılır. Eğer test=true ise 1a numaralı msg2 SınıfB'den yaratılan nesneye gönderilir ve msg3() ile devam edilir.
Eğer test=true değil ise 1b numaralı msg4 SınıfD' den yaratılan nesneye gönderilir.
Koşullara bağlı mesajlar gönderildikten sonra SınıfA' dan yaratılan nesne SınıfE' den yaratılan nesneye koşulsuz olarak 2 numaralı msg6 mesajını gönderir.
Şekil 5.8: İletişim Diyagramlarında karşılıklı dışlamalı mesajlar
5.2.6. Döngüler (İterasyonlar)
UML iletişim diyagramlarında tekrarlamalar (döngüler) "*" sembolü ile gösterilir. Şekil 5.9' da verilen örnekte Simulator sınıfından yaratılan nesne, i = 1' den N' e kadar Random sınıfından yaratılan nesneye nextInt() mesajını defalarca gönderecektir.
Bu metot çağrısında geri gönderilen değer num adlı bir değişkende tutulmaktadır.
Eğer tekrarın kaç defa yapılacağı tasarım aşamasında belli değilse, kodlama aşamasına bırakılmışsa ya da problemin yapısından dolayı açıkça belli ise döngü koşulu yazılmadan sadece "*" simgesi de kullanılabilir.
Şekil 5.9: İletişim Diyagramlarında döngüler
5.2.7. Çoklu Nesneler (Multiobject)
Bazı durumlarda bir çok nesneden oluşan yapılara (list, vector, map, set vb.) aynı mesajın gönderilmesi gerekir. Bu tür yapılara çoklu nesne (multiobject) denir.
Bu nesne grupları UML' in önceki sürümlerinde (UML 1.X) iki dörtgen şeklinde gösterilir.
Şekil 5.10' da verilen örnekte, :Satis nesnesi, SatisKalemi cinsinden nesneler içeren bir yapıdaki (dizi veya liste olabilir) tüm elemanlara tek tek alttoplamHesapla mesajını gönderiyor.
Şekil 5.10: UML 1.x' te çoklu nesnelerin gösterilmesi
UML' in yeni sürümünde (UML 2.0) çoklu nesne gösterilmiş, değiştirilmiştir. Şekil 5.11' de gösterildiği gibi iki dörtgen şeklinden vazgeçilmiş ve köşeli parantez kullanılmıştır.
Bu örnekte, SatisKalemi cinsinden bir çok nesne içeren bir yapı (dizi veya liste olabilir) gösterilmektedir ve madde[i]: bu yapıdaki i. elemandır.
Şekil 5.11: UML 2.0' da çoklu nesnelerin gösterilmesi
5.3. Ardışıl (Sequence) Diyagramlar (Örnek)
Örnek:
Şekil 5.3' te, iletişim diyagramı verilen POS (market satış) sisteminin ardışıl diyagramı şekil 5.12' de gösterilmiştir. Her iki diyagram da aynı bilgileri içermektedir.
Bu diyagramda da Terminal, Satis ve Odeme, sistem tasarlanırken oluşturulacak sınıfların adıdır. Bu nedenle Türkçe karakterler kullanılmamıştır. Sınıf adının önüne iki nokta (:) sembolünün yazılması o sınıftan yaratılan bir nesne anlamına gelir. Buna göre :Terminal yazımı, Terminal adlı sınıftan yaratılmış herhangi bir nesne anlamına gelir.
Şekil 5.12: Örnek bir UML Ardışıl Diyagramı
5.3.1. Geri Dönüşler
Mesajlardan geri dönüşleri göstermek çoğunlukla gerekli değildir. Gerekli olduğu durumlarda geri dönüşler kesik çizgi ile gösterilir.
Çağırılan metodun geri döndürdüğü değer istenirse mesajın başına yazılır istenirse geri dönüş çizgisinin üstüne yazılır. Şekil 5.13'te verilen örnekte her iki yöntem de gösterilmiştir.
Örnekte, msg2() mesajı geriye a değerini döndürnketedir. Benzer şekilde msg3() çağrısı da geriye paraUstu değerini döndürmektedir. msg4() ve msg5() çağrıları ise geriye değer döndürmemektedir.
Şekil 5.13: UML ardışıl diyagramlarında metotlardan geri dönüşler
5.3.2. Kendine Mesaj
Şekil 5.14: Ardışıl diyagramlarda kendine mesaj gönderme |
Şekil 5.14' teki örnekte :Terminal nesnesi, msg1 metodunun içinde kendi sil metodunu çağırmaktadır.
5.3.3. Nesne Yok Etme
Şekil 5.15' teki örnekte :Satis nesnesi, önce n :Odeme esnesini yaratmakta daha sonra da yok etmektedir. Bu işlemler C++' da new ve delete operatörleri ile yapılır.
Şekil 5.15: Ardışıl diyagramlarda nesne yok etme
5.3.4. Koşullu Mesajlar
Bu tür mesajlar sadece belli bir koşul gerçekleştiğinde gönderilebilirler. Eğer köşeli parantez içinde verilen koşul gerçekleşmemişse o mesaj gönderilmez, sonraki mesaja geçilir.
Şekil 5.16' da verilen örnekte A sınıfından yaratılan nesnenin msg1 metodunun içinde önce :B nesnesine msgx() mesajını gönderilmektedir. Ardından msg1 metodunda renk değeri sınanmaktadır. Eğer renk = mavi koşulu doğru ise :A nesnesi, :B nesnesine hesapla() mesajını gönderecektir.
Daha sonra (koşul doğru olsa da olmasa da) bir sonraki mesajla (msgy() ) devam edilecektir.
UML 2.0' da karşılıklı dışlamalı durumları göstermek için "opt" anahtar sözcüğü kullanılır. Bu durum programlamadaki if-then yapısına karşı düşmektedir.
Şekil 5.16: İletişim Diyagramlarında koşullu mesajlar
5.3.5. Karşılıklı Dışlamalı Mesajlar (UML 1.X)
Nesneler arası etkileşim, belli bir koşula bağlı olarak farklı yollar izleyebilir.
Şekil 5.17' de verilen örnekte "X>10" koşuluna bağlı olarak :B ya da :C nesnelerine hesapla mesajı gönderilir. Şekil 5.17' deki diyagram UML' in bir önceki sürümünde (1.X) kullanılan gösterilime göre çizilmiştir. Bu gösterilimde nesnelerin isimlerinin altı çizilmektedir. Örneğin :A yazımı A sınıfından yaratılan nesne anlamına gelmektedir. UML2.0 sürümüyle bu gösterilim değiştirilmiştir ve nesne isimlerinin altı çizilmekten vazgeçilmiştir.
Günümüzde hala UML 1.X sürümleri ile yapılan çizimlerle karşılaşmak mümkün olduğundan bazı örneklerde eski sürümlere de yer verilmiştir.
Şekil 5.18' de UML 2.0' da karşılıklı dışlamalı mesajların ardışıl diyagramlarda nasıl çizildiği gösterilmiştir.
Şekil 5.17: UML 1.x'te ardışıl diyagramlarda karşılıklı dışlamalı mesajlar
5.3.6. Karşılıklı Dışlamalı Mesajların Yeni Biçimi (UML 2.x)
UML 2.0' da karşılıklı dışlamalı durumları göstermek için "alt" anahtar sözcüğü kullanılır. Bu sözcüğün yanına koşullardan biri yazılır. Koşul gerçekleşmediği durumlarda gönderilecek mesajlar ise kalın bir kesik çizgiden sonra sıralanır. Bu grubun başına "else" anahtar sözcüğü yazılır.
Şekil 5.18' de UML 2.0' da karşılıklı dışlamalı mesajların ardışıl diyagramlarda nasıl çizildiği gösterilmiştir.
Şekil 5.18: UML 2.0'da ardışıl diyagramlarda karşılıklı dışlamalı mesajlar
5.3.7. İterasyonlar (Döngüler)
Şekil 5.19' da UML' in eski sürümü 1.5' te tek mesajlı bir döngü yapısı gösterilmiştir.
Bu örnekte Simulator sınıfından yaratılan nesne, i = 1' den N' e kadar Random sınıfından yaratılan nesneye nextInt() mesajını defalarca gönderecektir.
Şekil 5.19: UML 1.X' te ardışıl diyagramlarda döngüler
Şekil 5.20' de ise aynı sistem UML' in 2.0 sürümü ile gösterilmiştir. UML' in yeni sürümünde döngüler "loop" anahtar sözcüğü ile belirtilmektedir.
Şekil 5.20: UML 2.0'da ardışıl diyagramlarda döngüler
5.3.8. Çok Mesajlı Döngüler
Bir döngünün içinde birden fazla mesaj da gönderilebilir. Şekil 5.21' de verilen örnekte Simulator sınıfından yaratılan nesne, i = 1' den N' e kadar önce Random sınıfından yaratılan nesneye nextInt() mesajını, ardından da Programmer sınıfından yaratılan nesneye work(hours) mesajını defalarca göndermektedir.
Döngü sona erdikten sonra Simulator sınıfından yaratılan nesne, Programmer sınıfından yaratılan nesneye eat() mesajını göndermektedir.
Şekil 5.21: UML 2.0'da ardışıl diyagramlarda çok mesajlı döngüler
5.3.9. Nesne Gruplarına (Multiobject) Mesajlar (UML 1.X)
Bir çok nesneden oluşan yapılara (list, vector, map, set vb.) çoklu nesne (multiobject) denir.
Bu nesne grupları UML' in önceki sürümlerinde (UML 1.X) iki dörtgen şeklinde gösterilir.
Şekil 5.22' de verilen örnekte :Satis nesnesi, SatisKalemi cinsinden nesneler içeren bir yapıdaki (dizi veya liste olabilir) tüm elemanlara tek tek alttoplamHesapla mesajını gönderiyor.
Bu örnek UML' in 1.X sürümünde verilmiştir.
Şekil 5.22: UML 1.x ardışıl diyagramlarında çoklu nesnelerin gösterilmesi
5.3.10. Nesne Gruplarına (Multiobject) Mesajlar (UML 2.0)
UML' in yeni sürümünde (UML 2.0) çoklu nesne gösterimi değiştirilmiş, iki dörtgen şeklinden vazgeçilmiş ve köşeli parantez kullanılmıştır.
Şekil 5.22' de UML 1.x ile verilen örneğin aynısı Şekil 5.23' te UML 2.0 ile verilmiştir.
Bu örnekte, SatisKalemi cinsinden bir çok nesne içeren bir yapı (dizi veya liste olabilir) gösterilmektedir ve madde[i]: bu yapıdaki i. elemandır.
Şekil 5.24' teki örnekte ise döngü koşulu olarak bir i sayacı kullanılmıştır. i< strong=""> koşulu geçerli olduğu sürece döngü devam edecektir.<>
Döngünü her adımının sonunda ise i sayacı bir arttırılacaktır.
Şekil 5.23: UML 2.0 ardışıl diyağramlarında çoklu nesnelerin gösterilmesi
Şekil 5.24: UML 2.0'da döngülerde koşul ve sayaç kullanımı
5.3.11. Diyagramlar Arası Etkileşim (Interaction)
Altprogram çağırmak gibidir. Çok tekrarlanan işlemler için kullanılır.
Başka diyagramdan alınacak olan kısım ana diyagramın içinde "ref" bloğu ile belirtilir. Bu bloğun içine aynı isimdeki ardışıl diyagramın yerleşeceği anlaşılır. Bkz. Şekil 5.25.
Şekil 5.25: Diyagramlar arası etkileşim
Değerlendirme Soruları
Bölüm 6: Tasarım Kalıplarına (Design Patterns) Giriş
Bölüm 7: Tasarım Modelinin (Design Model) Oluşturulması Senaryoların Gerçeklenmesi (USE-CASE Realization)
Bölüm 8: Kodlama
Bölüm 9: Tasarımda İkinci İterasyon ve İleri GRASP Kalıpları
Bölüm 10: GOF Tasarım Kalıpları
1- Uygun yazılım geliştirme teknikleri kullanılmadığında ortaya çıkan problemler hangileridir?
yazılımın zamanında tamamlanamaması
bütçenin açılması
hata çıkması
yazılımın yeni gereksinimlere uyarlanamaması
bakım maliyetinin yüksek olması
2- Tümleşik modelleme dili nedir?
Tümleşik modelleme dili veya kısaca UML, analiz ve tasarımların ifade edilmesinde yaygın olarak kullanılan ve endüstri standardı haline gelmiş görsel yöntemdir.
3- Tasarım sonucu hangi diyagramlarla ifade edilir?
etkileşim diyagramı
sınıf diyagramı
4- Nesneye dayalı analiz ve tasarım neden gereklidir?
En önemli sebep, yazılım maliyetlerinin yüksekliğidir.
5- Yazılım dünyasındaki kişiler hangi gruplara ayrılır?
yazılımın kullanıcıları
yazılımı geliştirenler
6- Kaliteli bir yazılımda hangi özellikler bulunmalıdır?
Yazılım, istenen işi doğru yapmalıdır.
Kolay kullanılabilmelidir.
Hızlı çalışmalıdır.
Sistem kaynaklarını gereğinden fazla kullanmamalıdır.
Sağlam olmalıdır.
Yazılımı güncellemek kolay olmalıdır.
Yazılımın bakımı kolay olmalıdır.
Yazılım projesi yeterli sürede tamamlanmalıdır.
Yazılım modülleri yeni projelerde yeniden kullanılabilmelidir.
Yazılım geliştirme maliyeti düşük tutulabilmelidir.
EK: JAVA
Bilgisayarda kullandığımız her türlü programa ne ad verilir?
Yazılım
Java programlama dilinde komut satırları hangi karakterle sonlandırılmalıdır?
Noktalı Virgül
Yaygın olarak kullanılan nesne yönelimli programlama dilleri nelerdir?
Java programlama dili hangi firma tarafından geliştirilmektedir?
Programlama dili ile yazılmış bir programı makine dili ile yazılmış amaç veya hedef programa çeviren yazılım hangisidir?
Bir Java editörü ile yazdığımız kaynak dosyamızı (.java uzantılı) derlediğimizde (javac ile) dosya uzantımız ne olur?
.class
Java derleyici, kütüklerin ___ kütük adı uzantısı ile yüklenmesini bekler.
.java
Java programlama dili hangi dilin gramer yapısını kullanır?
C ve C++
Yaygın olarak kullanılan Java editör programları nelerdir?
IntelliJ IDEA, Eclipse, NetBeans, Visual Studio Code
Java dilinde açıklama (yorum) satırları için kullanılan operatör hangisidir?
Tek satır için // ve birden fazla satır için /* ... */
Java'nın "Bir kere yaz, her yerde çalıştır" felsefesini mümkün kılan sanal yazılım nedir?
Java'da tam sayı (150) ve ondalık sayı (85.5) tanımlamak için hangi temel veri tiplerini kullanırız?
Komut satırında (javac) derleme yaparken Türkçe karakter hatasını çözmek için hangi parametre kullanılır?
-encoding CP1254
Bir .java dosyasının çalışmaya başladığı ilk noktayı tanımlayan metot hangisidir?
Çalışma zamanında çıktı almak için ekrana yazdırma görevini hangi komut yerine getirir?
System.out.println()
Bir programdaki değişkenlerin değeri değişmeden kalan, sabit değerler için kullandığımız terim nedir?
Java'da bir .java dosyası içinde kaç tane public class bulunabilir?
Yalnızca bir
Java'da iki sayıyı toplamak veya iki metni birleştirmek için kullanılan operatör hangisidir?
+ operatörü
Bilgisayarın sahip olduğu kaynaklar ile bilgisayar kullanıcısı arasında arayüz görevi yapan yazılımlara ne denir?
işletim sistemi
Bir java editörü ile yazılan kaynak dosyası derlendiğinde dosya uzantısı ne olur?
class
Java dilinde tek satırlık yorum için kullanılan operatör hangisidir?
//
Java dili günümüzde hangi firma tarafından geliştirilmektedir?
Oracle
Java dilinde değişkenleri sabit olarak tanımlamak için değişkenlerin önüne hangi deyim getirilir?
Java hangi dilin gramerini kullanır?
C
Java'da char verisi hangi sınıfın içine gömülür?
Hiç yorum yok:
Yorum Gönder