Aklımda Kalası Kelimeler

* давайте работать вместе
* Zarf ve Mazruf, Zerafet(xHoyratlık) ile aynı kökten(za-ra-fe) gelir
* Bedesten
* Suç subuta ermiştir - Suç sabit olmuştur
UML etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
UML etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

29 Temmuz 2011 Cuma

UML 2





Referanslar:
  1. teodorfilimon.com
  2. www.ibm.com
  3. www.agilemodeling.com
  4. wikipedia.com
  5. www.ce.yildiz.edu.tr
  6. www.cs.drexel.edu


MODEL : ÖRNEK, NUMUNE, KALIP
MODELLING (MODELLEMEK) : KALIBINI ÇIKARTMAK


Kalıbı çıkartılmış(modellenmiş) bir sistem düşünüyorum. Yani sistemin her türlü bilgisini içeren bir kalıbımız var.

Elbise mankeni olsun bu sistem. Ve çıkan cam elyaftan yapılmış mankenin ölçüleri ideal bir insan ölçüsünde. Ayrıca başını sağa, sola çevirebiliyoruz. Kolunu yukarı-aşağı, ayaklarını yine aynı şekilde HAREKET ettirebiliyoruz.

DIAGRAM : Diyagram, Şema, Taslak

STATIC : Sabit, Değişmez, Durgun
STRUCTURE : Yapı, Bünye, Bina

İşte bu elbise mankenimizin ölçüleri, rengi v.s. bizim için statik(değişmez, sabit) bilgileri gösteren taslak, yapı(STRUCTURE) diyagramıdır(şeması, taslağı). Yapı taslağı; sınıfları, bileşenleri içerir.

BEHAVIORAL : Davranış, Davranışsal
Hareket edebilmesi(hareketleri ile görsel etkileşime geçebilmesi) ise davranışsal(behaivoral) taslağıdır(diyagramıdır). Davranışsal diyagramlar ise yöntemleri(METHODS), işbirliklerini(COLLABRATIONS) ve aktiviteleri(ACTIVITIES) içerir. Collaboration will be in one of two forms: a request for information or a request to perform a task. İşbirliklerini çıkartmak için sınıfın her sorumluluğunu düşünerek şu soruyu sormalıyız: "Sınıfın bu sorumluluğu yerine getirmek için yeteneği var mı?" Eğer bu sorunun cevabı "HAYIR" ise, bu işi yapacak yeni bir sınıf aramak gerekir.

UML : Unified Modelling Language (Birleşik Modelleme Dili)
İşte UML de hem statik, hem de davranışsal taslaklarını esas alır.

Yapısal Taslaklar(Structural Diagrams), sistem türlerini(sınıfları) ve bunların örneklerini(nesneleri) gösteren yanı sıra, yapı diyagramlarının kendi iç yapısı arasındaki ilişkiyi göstermektedir. Yazılımın hayat çevrimi boyunca gerekecektir.

Yapısal Taslak(structural diagram), bir diyagram olmayıp UML 2 nin ana kategorilerinden birisidir (diğer behavioral diagram-davranışsal taslak-).

Sınıf Diyagramı(Class Diagram), yapısal taslağın bir türü olup, sistemin tiplerini diğer taslakların kullanımı için en önemli taslaktır.
UML modellerinin çoğu şu türleri içerir:
  • Sınıf(class)
  • Arayüz(interface)
  • Veri Tipi(Data Type)
  • Bileşen(Component)
Bu türlere sınıflandırıcılar(classifiers : Veri tipi ve arayüz içeren genel kavram) denir. Sınıflandırıcıyı teknik olarak bir sınıf gibi düşünebiliriz. Ancak yukarıdaki türlerin genel adı olduğuda akıldan çıkartılmamalıdır.

Aşağıdaki gösterim bir havayolu şirketinin uçuşunu gösteren bir sınıf diyagramıdır. 3 Bölmeden oluşan bu diyagramda ilk satır sınıfın adını, ikinci satır uçuş sınıfının özelliklerini ve üçüncü satır ise uçuş sınıfının işlemlerini(method) göstermektedir. Geniş bir sistem modeli gösteriminde sadece birinci satır(sınıf adı) gösterilir.Bu sınıf tanımında görüldüğü gibi uçuş süresi "dakika" olarak gösterilmiştir. Kullanıcıya anlamlı gelmesi için özelliğin türü dakika, dolar v.s. olabilir.

Bir sınıf özelliğinin başlangıç değeri olabilir. Örneğin aşağıdaki sınıf tanımında hesap açıldığında 0 bakiye ile açılmalıdır.

Miras(Inheritance)


Bir sınıfın özelliklerini başka bir sınıfa geçirmek için miras kullanılır. Bu tarafını biliyor olmalıyızki UML öğrenmeye geldik değilmi. Miras almayı gösterme şekli önemli kısmıdır. Düz, kesiksiz bir çizgi ve kapalı, içi boş bir üçgen ok başıyla miras alma gösterilir.
Yukarıdaki resimde "BankAccount" sınıfı ve "withdrawal" metodunun eğik yazılmıştır. Çünkü "BankAccount" sınıfı "abstract sınıf" (soyut sınıf) ve "withdrawal" metodu "abstract method" (soyut metot) olarak gösterilmiştir.

ASSOCIATION : Ortaklık, işbirliği, birleşme

Ortaklık, İşbirliği


Ortaklıklar (iş birlikleri), sınıfların örnekleri arasındaki ilişkileri gösteren bağlantılardır.
5 tip ortaklık(association) vardır.
  1. bi-directional (çift yönlü)
  2. uni-directional(tek yönlü)
  3. Association Class(İşbirliği Sınıfı)
  4. Aggregation (includes Composition aggregation)(Toplama)
  5. Reflexive
En çok çift ve tek yönlü işbirlikleri kullanılmaktadır.

Çift Yönlü (Bi-Directional)

Örneğin uçuş sınıfı, uçak sınıfıyla çift yönlü bir işbirliği içindedir. Bu ortaklık, iki sınıfın nesneleri arasında paylaşılan statik bir ilişkiyi temsil etmektedir. Bi-directional ilişkide her iki taraftaki sınıfta etkileşim içindedir. Bir çift yönlü bir ilişki iki sınıf arasındaki düz bir çizgi ile gösterilir.

Yukarıdaki şekilde, Flight sınıfı Plane hakkında bilgi sahibidir. Aynı zamanda uçak sınıfıda uçuş sınıfından haberdardır.
Plane(uçak) sınıfının rol adı hemen yanında "assignedPlane" olarak belirlenmiş. Uçak sınıfının yanındaki 0..1 ile Flight(uçuş) sınıfından üretilmiş bir örneğinin "ya 1 uçak nesnesi ile ilişkisi var ya da henüz bir uçak nesnesi tayin edilmemiş" tanımı yapılıyor.
Flight(uçuş) sınıfının rol adı ise "assignedFlights" (atanmış uçuşLAR -0..*-) olarak belirlenmiş. Her uçak nesnesi ya 0 uçuşla ya da sonsuz uçuşlarla(örneğin son 5 yıllık uçuşlar gibi) ilişkilidir.

Çokluk değerleri ve onların ilişkileri
GöstergeAnlam
0 .. 1Sıfır ya da bir
1Sadece tek bir
0..*Sıfır veya daha fazla
*Sıfır veya daha fazla
1..*Bir veya daha fazla
3Sadece üç
0..5Sıfır ya da Beş
5..15Beş ila On Beş

Tek Yönlü (Uni-Directional)

İki sınıfla ilgili bir ilişki ama sadece bir sınıf bu ilişkiden haberdardır. Çift yönlü ilişki, düz bir çizgi ile belirtilir.Rapor sınıfı hangi sınıfı raporladığını bilmeli ama raporlanan sınıfın Rapor sınıfını bilmesi gereksizdir. Yukarıdaki resimde, OverdrwanAccountsReport sınıfı BankAccount sınıfını biliyor ama BankAccount sınıfı aralarındaki bu ilişkiyi bile bilmiyor.Tek yönlü ilişki, ilişkiden habersiz sınıfa doğru düz bir çizgi ve ucu açık bir ok ile belirtilir. Bu şekilde olan bağlar "esnek bağ" olarak tanımlanır ve sistem değişikliklerini daha uyumlu hale getirir.

Paketler

Sınıflar paket (namespace) adı verilen mantıksal kümelere ayrılabilir.
Amaç: Kendi içerisinde anlam bütünlüğü olan ve belli bir amaca yönelik olarak birlikte kullanılabilecek sınıfları bir araya toplamaktır.

Büyük bir sistemi modellerken bir çok sınıfımız ortaya çıkacaktır. Bu sınıfları namespace gibi klasörler altında toplamak sistemin modellenmesini ve organizasyonunu kolaylaştıracaktır.Büyük bir dikdörtgende gösterilecek tüm üyeler(konuya özel sınıflar) ve en üstte paketin(konunun) adı olmalı.
Eğer tersi durumda göstermek istersek yani paketin üyelerini(konuya özel sınıfları) paketin dışında göstermek istersek aşağıdaki gibi sınıflardan pakete düz çizgiler çizer ve paketin altında içi artı olan bir dairede birleştiririz.

İşbirlikleri(associations) ile ilgili kalan 3 işbirliği tipini ilerleyen kısımlarda göreceğiz (İşbirliği sınıfları(association class), Toplama(Aggregation) ve Reflexive İşbirliği(Reflexive Association)).


Arayüzler (Interfaces)

Arayüzlerde sınıflar gibi veri tipleridir. Sınıflardan nesneler örneklenirken arayüzler bir sınıf tarafından uygulandıktan sonra örneklenebilirler. Aşağıdaki resimde olduğu gibi, Profesör ve Öğrenci sınıfları Kişi arayüzünü uygulamış oldukları için bu sınıflar aynı zamanda Kişi tipindedirler. Arayüzleri gösterirken sınıflardan farklı olarak "<<interface>>" şeklinde gösterilir. UML 2 de sınıflar içinde "<<class>>" yazmanızda sakınca yok ama buna gerekte yok.
Resimdeki yapının kalıtım olmadığı çizginin kesikli olmasından anlaşılıyor. Kesikli çizgili, kapalı ve içi doldurumlamış ok, bize gerçekleştirme ya da uygulama olduğunu gösterir.

Sıra Ortaklıklarda anlatılmamış 3 tipte (Association Class, Aggregation, Reflexie Association)

Association Class (Ortaklık Sınıfı)

Normal sınıflar gibidirler tek farkı, birincil iki sınıf arasındaki ilişkiyi noktalı bir çizgi ile kesmesidir.Yukarıdaki resimde sıkUçan yolcu sınıfı ile uçuş sınıfı arasındaki ilişkiye kazanılan mil puanları tutan bir MileageCredit sınıfının dahil olması gösteriliyor.

when an association itself has attributes or operations of its own …
or when it participates in relationships with other classes

22 Temmuz 2010 Perşembe

O kadar çizdik bir kenarda dursun

21 Aralık 2009 Pazartesi

UML Diyagramları ile Tasarım Şablonları



Gang of Four Tasarım Şablonları UML diyagramları

Behavioral patterns
  • * Chain of responsibility
  • * Command
  • * Interpreter
  • * Iterator
  • * Mediator
  • * Memento
  • * Observer




    C# Örnek:
    namespace ConsoleApplication1
    {
        class Program
        {
            static void Main(string[] args)
            {
                var duygu = new EvAbone();
                Aydinlik aydinlik = new Aydinlik();
                aydinlik.Attach(duygu);
    
                EsnafAbone cem = new EsnafAbone();
                aydinlik.Attach(cem);
                
                aydinlik.HaberVer();
                Console.Read();
            }
        }
    
        interface IAbone
        {
            void HaberAl();
        }
    
        class EsnafAbone : IAbone
        {
            public void HaberAl()
            {
                // Telefon
                Console.WriteLine("telefon et");
            }
        }
    
        class EvAbone : IAbone
        {
            public void HaberAl()
            {
                // Kapıya bırak
                Console.WriteLine("kapıya bırak");
            }
        }
    
        abstract class Gazete
        {
            List<IAbone> aboneler = new List<IAbone>();
            public void Attach(IAbone abone)
            {
                aboneler.Add(abone);
            }
    
            public void Remove(IAbone abone)
            {
                aboneler.Remove(abone);
            }
    
            public void HaberVer()
            {
                aboneler.ForEach(a =>
                {
                    Console.WriteLine(a);
                    a.HaberAl();
                });
            }
        }
    
        class Hurriyet:Gazete
        {
            private bool bHurriyetGeldi = false;
        }
    
        class Aydinlik:Gazete
        {
            private bool bAydinlikGeldi = false;
        }
    }

    Javascript Örnek:
    function Olay(){
      var arrAboneler = [];
      
      this.AboneEkle = function(abone){
        arrAboneler.push(abone);
      }
      
      this.AboneCikart = function(abone){
        arrAboneler.splice(abone);
      }
    
      this.Notify = function(_obje) {
        arrAboneler.forEach(function(abone){
          abone.Calistir(_obje)
        });
      }
    
    }
    
    function Ihale(){
      var aboneler=[]; 
      
      this.f_ekle = function(ihale){
        this.Notify(ihale);
      }
    }
    
    Ihale.prototype = new Olay();
    
    // Abonemiz Elastic Search'e eklemek olsun
    function Elastic(){
    
      this.Calistir = function(_obje){
         console.log('elastice yazıldı');
         console.log(_obje);
      }
    }
    
    elastic = new Elastic();
    
    // Abone olacağımız konu ihale olacak:
    ihale = new Ihale;
    ihale.AboneEkle(elastic);
    
    // Şimdi bir olay tetikleyelim:
    ihale.f_ekle({a:1});

    Güzel bir referans.


    Bir nesnenin kendi durumunda olabilecek değişikliklerin haberdar edilmesi gereken başka nesneler varsa (nesneler arasında ilişki varsa) bu tasarım kalıbı kullanılır.
    Örneğin: Bir hisse kağıdındaki hareketden haberdar edilecek müşteriler, bir blog sitesinde meydana gelecek değişimden haberdar edilecek abonelerin haberdar edilmesi gibi.

    Blog sitemizdeki değişimleri abonelere bildirmek isteyelim. Buna göre blog sitemiz abonelerin listesini tutmalı. Ama abonelerimiz çeşitli tiplerde olabilir. Hisse senedindeki değişimden haberdar olmak isteyen bireysel yatırımcı, kurumsal yatırımcı, denetleme kurumu, SPK gibi abonler olabilir. Bu abone tiplerinin ortak bir tipte toplanması için bir arayüz ya da bir soyut sınıftan türetilmesi gerekir.

    Yukarıdaki anlatıma göre:
    Subject: Durum bilgisinin değişimini abonelere bildirecek nesnenin soyut sınıfı/arayüzü.
    Observer: Abonelerin türediği sınıf.
    Concrete Observer/Subject: Nesnelerin türediği sınıflar.

    Depişimini haber verecek sınıfların(ki bunlar Subject atasından türetilmiş olmalı), abonelerini (ki abonelerde Observer sınıfından türetilmiş olmalı(ki update() metotları olsun)) ekleyip, çıkartabilmesi gerekiyor. Bunun için Attach(Observer obj) ve Detattach(Observer obj) metotları olacak. Birde tüm bu değişimleri abonelerine bildirmek için Notify() metodu olacak. Notify metodu aslında abonelerinin update metodunu çağıracak. Update metodu Observer ata sınıfından gelen bir metotdu. Update metodu her sınıfın kendi içinde sağladığı (implement) bir metot olduğu için her abone sınıf tipi gelen değişim bilgisinde kendine özgü bir iş yapacak

  • * State
  • * Strategy




    Referans: doFactory.com




  • * Template method
  • * Visitor


Creational patterns



Structural patterns

  • * Adapter


    Bir projemiz var ve bu projede bir sürü Interface ve Class'larımız olsun.

    Bir gün dışarıdan bir sınıfı(örneğin SMS atan bir apiyi) projemize dahil etmemiz gereksin.

    Tabi o gün kullanılan Turkcell(En azından yerli sermaye az da olsa) GSM operatörü yerine, ileride başka bir GSM operatörü ve onun API'sini de kullanabileceğimizi düşünerek sistemimize, bu sınıfı dahil etmemiz gerekecektir.

    Bir adaptör sınıfı yazmamız gerekecek.

    1. Method : Class Adapter
    Sistemde mesaj atması gereken sınıfların uyguladığı arayüzü, kullanan bir sınıf oluştururuz. Bu sınıf aynı zamanda TurkcellApi sınıfını da miras alarak kısa mesaj atma metotlarını kullanmamızı sağlayabilir. Böylece TurkcellApi sınıfı dışarıdan gelip sisteme adapte edilen bir tip olarak kullanılabilir.

    2. Method: Object Adapter
    Sistemde mesaj atması gereken sınıfların uyguladığı arayüzü, kullanan bir sınıf oluştururuz. Bu sınıf aynı zamanda TurkcellApi sınıfından bir property (field, değişken ne derseniz deyin) içerir ve tüm kısa mesaj işlerini yeni sınıfımızın bu değişkenine yaptırılır. Böylece TurkcellApi sınıfndan(tipinden) bir değişkeni yeni sınıfımızda kullanarak sisteme adapte etmiş oluruz.



  • * Bridge
    Bridge tasarım şablonu, modelleme esnasında oluşan soyut oluşumlar ve bunların implementasyonunu ayırmak için kullanılır. Bu yöntem sayesinde sınıf hiyerarşileri daha esnek bir hale getirilebilir, çünkü üst sınıflar bünyelerinde barındırdıkaları soyut metodları bir interface sınıfına taşıyarak, alt sınıfların istedikleri bir implementasyonu kullanmalarına izin verirler.
    BridgeTasarimSablonu



  • * Composite


  • * Decorator


  • * Facade






    Facade objeleri genellikle Singleton dır. Çünkü sadece bir tane Facade objesi gereklidir.

  • * Flyweight



  • * Proxy