Welcome to My Blog 👋

• Magic Pushbutton : Frontend elemanların kodları arasına iş mantığını sağlayan kodların yazılması ile oluşur.
• Functional Decompozition : Birbirinden alakasız statik fonksiyonları tek bir sınıfa toplanması ile oluşan bir anti pattern'dır.
• Database as IPC : Farklı uygulamalar arasındaki iletişimin bir veritabanı üzerinden yapılması ile oluşur.
• Swiss Army Knife : Kullanılmayan, gereksiz kod parçalarının bulunduğu yazılımlarda görünür.
• Busy Waiting : Zaman alan işlemleri aynı thread üzerinde yaparak uygulamanın yanıt vermemesi durumunu oluşturan kodlara denir.
• Soft Coding : İş mantığını konfigürasyon dosyası gibi dosyalarda kodlanmasına denir.
• Lasagna Coding : Gereğinden fazla katmandan oluşan kodlara denir.
• Spagetti Coding : Soyutlama gibi tasarım prensipleri uygulamadan yazılmış karmaşık kodlara denir.
• God Object : Birden fazla amacı olan çok fazla kod bulunan sınıflara denir.
• Error Hiding : Uygulamada oluşan hataları handle eden ve bu hataları loglamayarak üstünü kapatmaya çalışan yazılımlarda görünür.
• Copy Paste Programing : Hız kazandırdığı düşüncesiyle yapılan ancak daha sonradan çok fazla soruna yol açabilecek bir tekniktir.

• Abstract Factory
• Builder
• Factory Method
• Object Pool
• Prototype
• Singleton

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

• Chain Of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

• Soyut sınıf ve saf sanal fonksiyonlar kullanılarak.
• Interface yani arayüzler kullanılarak.

public class Ciz{

     public void sekilCiz(Sekil sekil){
         sekil.sekilCiz();
     }
}

public class Sekil {
    
    public void sekilCiz(){
        
    }
}

public class Kare extens Sekil {
    
    public void sekilCiz(){
        
    }
}

public class Daire extens Sekil {
    
    public void sekilCiz() {
        
    }
}

public class Ciz{

     public void sekilCiz(Sekil sekil){
         sekil.sekilCiz();
     }
}

public interface Sekil {
    
    public void sekilCiz();
}

public class Kare implements Sekil {
    
    public void sekilCiz(){
        
    }
}

public class Daire implements Sekil {
    
    public void sekilCiz() {
        
    }
}

• Yazılımda olacak paydaşları doğru bir şekilde çıkararak bunları yazılıma aktarmamız gerekir. Gerçek dünya nesneleri olarak düşünerek bunların yazılımdaki karşılıkları olan sınıfları çıkarmalıyız. Bunu yaparken her bir paydayı ayırmalıyız. Örneğin müşteri, satıcı olan ve hatta bu tiplerin alt türlerinin de bulunduğu bir yazılımda tüm bu paydaşlar için tek bir sınıf yaparsak daha sonraki herhangi bir değişiklikte işin içinden çıkılamaz bir karmaşıklık oluşur. Bunun için buraki tüm paydaşları amacına göre tek tek ayırarak sistemi tasarlamamız gerekir.
• Bir sınıfı tasarladığımızda o sınıfın üyeleri yani özellik ve fonksiyonları mantıksal açıdan birbirlerine yakın olmalı ve benzer bir amaç için var olmalıdırlar. Yani aynı sınıfta birbirinden amaç olarak uzak olan iki üye olmamalıdır. Böyle bir durum var ise muhtemelen yanlış bir tasarım yapıyoruz demektir.
• Bir sınıfı tasarladığımızda o sınıfın tek bir amacı olmalıdır. Birden fazla amaca hizmet eden sınıflar kötü tasarımı gösterirler. Yazılımda bir değişiklik olacağı zaman muhtemelen bir amaca yönelik olur. Eğer sınıflarımızı doğru bir şekilde tanımlarsak herhangi bir ihtiyaçta çok az kod değişimi yaparak belki de hiç kod değiştirmeden sadece biraz kod ekleyerek problemi çözebiliriz.
• Tasarladığımız sınıflar genellikle birbirleri ile etkileşim içerisinde olurlar. Bu kaçınılmaz bir durumdur ancak bu bağımlılıklar kodda bir değişiklik yapmak istediğimizde karşılaştığımız en büyük problemdir. Bu yüzden sınıfların arasında mümkün olduğunca az bağımlılık yaratmalıyız ve yarattığımız bağımlılıkların seviyesini mümkün olduğunca düşürmeliyiz. Bu seviyeyi düşürmenin en güzel yolu da polimorfizm'dir.
• Tasarladığımız sınıflarda yeniden kullanılabilirliği düşünmeliyiz. Örneğin bir sınıfa eklediğimiz özellikler başka sınıflarda da kullanılabilecek genel özellikler ise bu özellikleri tekrar tekrar yazmak yerine yeniden kullanılabilirliği sağlayarak genelleştirmeli ve tüm sınıflarımızda kullanmalıyız. Böylelikle genel yapıda bir değişiklik yapmak istediğimizde tüm sınıflarda değişiklik yapmak yerine tek bir noktada değişiklik yapabiliriz.
• Tasarladığımız sistemlerde değişimin olmaması imkansızdır. Yazılım sistemlerinde değişim kaçınılmaz bir durumdur. Bu yüzden sistemimizi buna göre tasarlamak zorunda olmalıyız. Sistemimizi buna göre tasarlarken dikkat etmemiz gereken nokta bir değişiklikte kod değişikliği yapmak yerine sisteme yeni kodlar eklemek olmalıdır. Çünkü sınıflar arasındaki bağımlılıktan dolayı yapılacak bir kod değişiminin etkisi çok büyük olacaktır. Bu yüzden kod değişimi yerine kod eklemesi yapmalıyız ve sistemimizi buna göre tasarlamalıyız. Bunu yapmanın en kolay yolu polimorfizm'dir.

public class Ciz{

     public void sekilCiz(EnumDegeri){
         if(EnumDegeri == Kare) {
             Kare kare = new Kare();
             kare.kareCiz();
         } else if(EnumDegeri == Daire) {
             Daire daire = new Daire();
             daire.daireCiz();
         } 
     }
}

public class Sekil {
    
    public void sekilCiz(){
        
    }
}

public class Kare extens Sekil {
    
    public void kareCiz(){
        
    }
}

public class Daire extens Sekil {
    
    public void daireCiz() {
        
    }
}

public class Ciz{

     public void sekilCiz(Sekil sekil){
         sekil.sekilCiz();
     }
}

public class Sekil {
    
    public void sekilCiz(){
        
    }
}

public class Kare extens Sekil {
    
    public void sekilCiz(){
        
    }
}

public class Daire extens Sekil {
    
    public void sekilCiz() {
        
    }
}

• Bir yazılımın sisteminin değişime karşı gösterdiği direnç ne kadar yüksekse o yazılım sisteminin kalitesi o kadar kötüdür. Yani değişen ihtiyaçlar doğrultusunda bir yazılımda değişiklik yapılması ihtiyacı olduğunda karşılaşılan problemler ne kadar çoksa o yazılım tasarımı da o kadar kötüdür. Bu yüzden iyi bir yazılım tasarlanırken esneklik çok önemlidir.
• Yazılımın modüleritesi yani yeniden kullanılabilirliği ne kadar düşükse yazılım tasarımı da o kadar kötüdür. Yazılım parçaları modüler şekilde tasarlanmalı ve başka sistemlerde de kullanılabilmelidir. Bu şekilde yazılımın parçaları daha kolay değiştirilebilir ve anlaşılabilir.
• Yazılım sisteminde değişiklik yapılması gerektiğinde bu değişiklikler yazılımın tasarımını değiştirmeye zorluyorsa o yazılımın tasarımı kötü bir tasarımdır.

• Her paket sol üst köşesinde küçük bir dikdörtgen olan bir dikdörtgen şeklinde çizilir.
• Palet adları bu dikdörtgenler içerisine yazılır.
• Paketler arasındaki bağımlılıklar kesikli ok ile bağımlı olan paketten bağlı olunun pakete doğru gösterilir.
• Paketler mantıksal olarak daha üst paketler içerisinde yer alabilir.

• Çoğu UML diyagramında standart haline gelmiş olduğu gibi Communication diyagramlarda da nesneler dikdörtgen şeklinde çizilir.
• Nesneler arasındaki iletişim yani yazılımsal anlamda metot çağırımları çağıran metottan çağırılan metoda doğru bir ok ile gösterilir. Bu ok üzerine metot bilgisi eklenir.
• Bu diyagramda zaman çizelgesi olmadığından, dinamik yapıyı takip edebilmek için nesneler arasındaki iletişimlere numaralar verilir. Genel akıştan ayrılarak alt bir akış oluşuyorsa o zaman o akışın başladığı numara alt dallarına ayrılır. Örneğin 2 numaraları etkileşimde o nesne kendi içerisinde farklı işlemler yapacak ise bu işlemler 2.1, 2.2 gibi numaralandırılır.

• Sınıf ve nesne gösterimleri class diyagramlarda olduğu gibi dikdörtgen şeklinde çizilir.
• Sistemdeki her olay ayrı bir diyagram olarak çizilir ve bu olay içerisindeki kullanılan tüm sınıflar yatay bir düzlemde çizilir.
• Zaman çizelgesi dikey olarak kesikli bir çizgi olarak çizilir.
• Nesnelerin sistemde aktif olduğu yani kullanıldığı zamanları göstermek için ilgili sınıfın zaman çizgisi üzerine dikdörtgen çizilir.
• Nesneler arasındaki etkileşim yani yazılım anlamında metot çağırımları, çağıran metottan çağırılan metoda doğru çizilen bir ok ile gösterilir.
• Nesnelerin yaratılması veya yok edilmesi stereotype'lar ile gösterilir.
• Metotların dönüş değerleri çağırılan metottan çağıran metoda doğru kesikli bir ok ile gösterilir. Bu gösterim opsiyoneldir. 
• Sekron metot çağırımları içi dolu bir ok ile gösterilirken, asenkron metot çağırımları normal bir ok ile gösterilir.

• Sistemin başlangıç durumu içi dolu yuvarlak şeklinde çizilir.
• Sistemin sonlanma durumu içi boş yuvarlağın içinde daha küçük içi dolu bir yuvarlak olacak şekilde çizilir.
• Sistemin durumları kenarları yuvarlatılmış dikdörtgenler şeklinde çizilir.
• Tetikleyici olaylar sistemin durumları arasına düz bir çizgi şeklinde çizilir. Bu olaylar ile sistemin durumu değişir. Olaylar ile ilgili açıklayıcı bilgi veya kodlamadaki metot karşılıkları çizgi üzerine yazılabilir.
• Karar ifadeleri baklava şeklinde dikdörtgen olarak çizilir.

• Bütün nesne yok edildiğinde parça da yok ediliyorsa
• Parça bir yere taşındığında bütün de onunla taşınması gerekiyorsa
• Parça kolaylıkla başka bir bütüne dahil edilemiyorsa

public class Insan{

     private Araba araba;
}

public Class Araba{
    
}

• Sınıflar dikdörtgen şeklinde çizilir.
• Sınıfların çizildiği dikdörtgenler dikey olarak 3 parçaya ayrılır. İlk parçaya sınıfın ismi yazılır. İkinci parçaya sınıfın özellikleri yani değişkenler yazılır. Üçüncü parçaya sınıfın yaptığı işlemler yani metotlar yazılır.
• Yazılan özellikler için erişim belirleyici + özellik ismi + :özellik tipi şeklinde belirtim yapılır.
• Yazılan metotlar için erişim belirleyici + metot ismi + (metot parametreleri) + dönüş tipi şeklinde belirtim yapılır.
• Erişim belirleyiciler için semboller kullanılır. Bu semboller public için +, private için -, protected için # şeklindedir.
• Nesneler tek parça dikdörtgen şeklinde çizilir ve içerisine nesne bilgisi yazılır.
• Yazılacak nesne bilgisi nesne adı + sınıf adı şeklinde belirtilir.

UML diyaramlarda iki nesne veya sınıf arasında bir ilişki belirtilirken, bu iki çizim arasına bir çizgi çizilir. Ayrıca daha sonra ilişki türüne göre bu çizgi üzerine eklemeler yapılır. İlişki türleri ilerleyen yazılarda anlatılacaktır. 
Nesne veya sınıflar arasında bir ilişki belirtirken bu ilişkiye bir isim verilir. Bu ilişkiyi açıklayan anlamlı bir isim verilmelidir. Bu ilişkiyi belirten düz çizginin tam ortasına yazılır.

Multiplicity

İlişkide bulunan nesnelerin sayısını belirtmek için kullanılır. Örneğin yukarıdaki örnekte Kitap sınıfı içerisinde bir üye barındırabilir veya hiç barındırmayabilir. Yani bir kitabı bir üye ödünç almış olabilir veya o kitabı hiç bir üye ödünç almamış olabilir. Bu örnekte bir kitabı birden fazla üyenin ödünç alamayacağı gösterilmiştir.

• Aktörler basit bir çubuk adam şeklinde belirtilir.
• Operasyonlar elips şeklinde belirtilir.
• Aktörlerin hangi operasyonları yapabilecekleri, aktörler ile operasyonlar arasına düz bir çizgi çizilerek belirtilir. Buna association denir.
• Elemanlar arasındaki bağımlılıklar kesikli çizgi ile gösterilir. Örneğin bir use case operasyonunun içerisinde bir başka use case operasyonunu kullanması durumunda bir bağımlılık oluşur.

• Visio
• Enterprise Architect
• Rational Rose
• Visual Modeller
• Umbrello
• Visual Paradigm

• Proje başlangıcında modelleme bir zaman kaybı gibi görünsede ilerleyen süreçlerde çıkabilecek hataları azalttığı ve geliştirme süresini kısalttığı için proje süresinde ciddi bir iyileştirme sağlar.
• Projedeki gereksinimlerin ve risklerin proje başlangıcında ortaya çıkmasını sağlayarak daha sonradan başarısız olacak bir projenin geliştirmesine başlamadan bu durumun görünmesini sağlar.
• Projenin kalitesini arttırır.