22 Ocak 2013 Salı

Sistem Analizi


MODEL NEDİR VE NEDEN MODELLERİZ?
            Model, gerçeğin basitleştirilmiş halidir. Yani, karmaşık bir sistemi modelleyerek onu daha basit bir dille ifade edebiliriz; böylece geliştirmekte olduğumuz sistemi daha iyi anlayabilir ve olası hatalarımızı uygulamaya geçirmeden görebiliriz.
           Aslında, kendimiz için küçük bir kulübe yapmak istersek birkaç ağaç, biraz da saman yeterli olacak ve sonunda işe yarar bir yapı çıkacaktır. Ufak tefek hatalar olsa da bu çok sorun olmayacaktır, çünkü bu sorunu başlangıçtaki isteklerimizden biraz kısararak, ya da işe en baştan başlayarak çözebiliriz. Fakat iş büyük çapta bir bina yapımına geldiğinde, o bina için mimari plan çıkarmak zorunlu hale gelir. Artık işe en baştan başlama gibi bir olanağımız yoktur, istekler biz binanın yapımına başladığımızdan sonra bile değişebilir veya müşteri yeni isteklerle gelebilir. Bu bina yapımına da kulübe gibi başlayabiliriz tabi. Ama bu işi tek başımıza yapamayacağımıza göre, binayı istenen şekilde, işe yarar bir biçimde bitirebilmek için doğru zamanda, doğru yerde olan ve doğru bilgilere sahip çalışma arkadaşlarımız olmalı. Ancak, gerçek hayatta böyle çalışma arkadaşları pek fazla bulunmuyor.
             Büyük ve karmaşık yazılım projeleri için de durum çok farklı değildir. Başarısız projelerin hepsi değişik sebeplerden ötürü, kendilerine has bir biçimde çökerken, başarılı kurumların sahip olduğu en önemli özelliklerden birisi doğru modellemenin kullanılmasıdır. Modelleme yapılırken şu 4 ilke dikkate alınmalıdır,
·  Modeller iyi seçilmeli, doğru modeller en karmaşık problemleri çözme de yardımcı olabileceği gibi, yanlış model seçimi sizi yanıltabilir ve ilgisiz konulara odaklanmanıza neden olabilir.
·  Farklı detay seviyelerine sahip modelleriniz olmalı, bazen binanıza üstten bakarak genel yapısını incelemeniz gerekebilir, bazen de bir odanın yer döşemesiyle ilgilenirsiniz.
·  En iyi modeller gerçekle bağlantılı olanlardır, binanız için tasarladığınız fiziksel bir model gerçek hayatta olması gerektiği gibi davranmıyorsa, o modelin pek de değeri yoktur.
·  Yalnız bir model hiçbir zaman yeterli değildir, örneğin bir bina yapıyorsanız, zemin planlarının yanında elektrik, ısınma ve su gereksinimleri için de planlar oluşturmalısınız.
UML NEDİR?
            UML, yazılımın modellenmesi ve planlanması için kullanılan standart bir dildir. Bir program ya da yazılım geliştirme dili değildir.Modelleme kanıtlanmış ve kabul edilmiş bir mühendislik tekniğidir. Model gerçeğin basitleştirilmiş halidir. Model sayesinde anlaşılması güç yazılımları basit bir dille ifade edebiliriz. Bu da yazılımın anlaşılmasını kolaylaştırır, sistem gereksinimlerini ve davranışlarını daha iyi anlamamızı ve hatalarımızı kolaylıkla görüp en düşük seviyeye indirgememizi sağlar.
·         UML yazılım mühendisliğinde nesneye yönelik sistemleri modellemede kullanılan açık standart olmuş bir görsel modelleme dilidir.
·         Yazılım geliştirmenin çözümlemeden bakıma kadar tüm aşamalarında ekipler ve bireyler arasındaki iletişimin düzgün yürütülmesi için kullanılmaktadır.
·         Yazılımın yaşam döngüsü içinde farklı görev gruplarının projeye ve sisteme farklı bakış açıları vardır. Bundan dolayı UML çeşitli bakış açılarını ifade eden diyagramlar içermektedir.
           Çok zengin bir dil olmasından dolayı, Yazılım Mühendisliği’nin bir  çok yönden ihtiyaçlarını karşılamaktadır.
UML’NİN GELİŞİM SÜRECİ
            1989-1994 yılları yazılım mühendisliğinde metot savaşları olarak bilinen bir dönemdir. Sistemleri modellemek için kullanılan birçok modelleme dili vardı. 90’ların ortalarına doğru öne çıkan 3 yöntem vardır:
       Booch
Yaratıcısı Grady Booch’dur. Tasarım ve gerçekleştirimde mükemmel.
       OMT (Object Modelling Technology - Nesne Modelleme Teknolojisi)
Yaratıcısı Jim Rumbaugh. Analiz ve veri yoğunluğu çok olan sistemler için uygun.
       OOSE (Object Oriented Software Engineering - Nesneye Yönelik Yazılım Mühendisliği)
Yaratıcısı Ivar Jacobson. Use-Case adı verilen güçlü bir teknik içeriyordu.
·         1994 yılında Grady Booch (Booch) ve Jim Rumbaugh (OMT) Rational firmasının çatısı altında sahip oldukları iki yöntemi birleştirecek bir yöntem yaratmak için çalışmaya başladılar.
·         Firmaya 1995 yılında Ivar Jacobson’ın (OOSE) da katılmasıyla, 3 Amigolar olarak bilinen grup, kendi yöntemlerinin güçlü yönlerini birleştirip bir sistem modelleme dili olarak UML’i geliştirdiler.
·         1997’de OMG (Object Management Group), UML’yi sahiplendi ve açık standart olarak geliştirmeye başladı.
UML’YE NEDEN GEREK VAR?
·         Hataların kolaylıkla fark edilip en düşük seviyeye indirgenmesi.(Risk, zaman, maliyet)
·         Yazılım üretiminde başarı oranının düşük olması.
·         Yazılımda paylaşım önemlidir. Tüm ekibin aynı dili konuşabilmesi gerekmektedir.
·         Sistemin tamamını basit bir dille ve görsellikle görebilmek ve tasarlayabilmek gerekli.
·         Modellenmiş ve dokümante edilmiş bir yazılımın tanıtımının kolay olması.
·         Yazılım kalitesini arttırma.
UML’NİN AVANTAJLARI
·         Kodlama kolaylığı sağlar.
·         Kullanılan tekrar kod sayısı ayırt edilebilir bu sayede verim sağlanır.
·         Mantıksal hataların minimum seviyeye düşürülmesini sağlar. Bütün sistem tasarlandığı için oluşabilecek hataların düzeltilmesi de daha kolaydır.
·         Geliştirme maliyetinin düşmesini sağlar.
·         UML diyagramları ile yazılım tamamını görebileceğimiz için verimli bellek kullanımı sağlanabilir.
·         Karmaşık sistemlerde değişiklik yapmayı kolaylaştırır.
·         UML ile dokümanlaştırılmış kodları düzenlemek daha az zaman alacaktır.
·         UML diyagramlarını kullanan yazılımcılar aynı dili konuşacaklarından kolay iletişim sağlanır. Ayrıca müşteriler ve teknik sorumlular diyagramlar üzerinden kolaylıkla iletişim kurabilirler.
UML DİYAGRAMLARI
·         Grafiksel bir dil olan UML, modelleme için değişik diyagramlar kullanır. Diyagramlar, bir sistem modelini kısmen tarif eden grafiklerdir.
·         UML 2.0, 3 bölümde incelenen 13 farklı diyagram içerir.
1-Yapısal diyagramlarda modellenen sistemde nelerin var olması gerektiği vurgulanır.
     2-Davranış diyagramlarında modellenen sistemde nelerin meydana gelmesi gerektiğini belirtir.
3-Davranış diyagramlarının bir alt kümesi olan Etkileşim diyagramlarında ise modellenen sistemdeki elemanlar arasındaki veri ve komut akışı gösterilir.
ž  YAPISAL DİYAGRAMLAR

  •          Sınıf (Class) diyagramı
  •           Nesne (Object) diyagramı
  •            Bileşen (Component) diyagramı
  •            Paket (Package) diyagramı
  •    Dağılım (Deployment) diyagramı
  •           Birleşik Yapı (Composite Structure) diyagramı
-----Class Diyagramları----
n  UML’de sınıflar OOP mantığından yola çıkılarak düşünülmüştür
n  Sınıfların bir adı,özellikleri (attributes) ve işlevleri(functions) vardır.
n  Bunlara ek olarak “notes” (sınıf hakkında ekstra bilgiler) ve “Constraints” adlı sınıfla ilgili çeşitli özel koşullara ait bilgilerde bulunabilir.
Class’lar arasındaki ilişkilere örnekler…
1-)     İnsan sınıfından Ali nesnesi ve Kitap sınıfından ‘Uml Kitabı’ nesnesi ve aralarındaki ‘okuma’ ilişkisini gösteriyor.
2-)       Burada Müşteri ile Kitapçı sınıfı arasında "satın alma“ ilişkisi var.Fakat müşteri satın alırken ücret ödemek zorundadır.Bu ilişkiyi göstermek için ücret sınıfı ilişki ile kesikli çizgi ile birleştirilir.
3-)       Burada 1 yüzbaşı 100 Er'e komut(emir) verebilir anlamı çıkmaktadır .
----Nesne (Object) diyagramı----
            Nesne (Object) diyagramı, modellenen sistemin yapısının belirli bir andaki bütün ya da kısmi görünüşü tarif edilir. Bir nesne(object) sınıfın (class) bir örneğidir. Bu tür diyagramlarda sınıfın yerine gerçek nesneler kullanılır. Bu sayede modellenen sistemin yapısının belirli bir andaki bütün ya da kısmi görünüşü tarif edilir.




----Bileşen (Component) diyagramı----
           Bileşen (Component) diyagramı, bir yazılım sisteminin hangi tür bileşenlere ayrıldığını ve bu bileşenlerin nasıl birbiriyle ilişkili olduğunu betimler. Bir bileşen genellikle bir veya birden fazla sınıf, arayüz ve iletişime karşılık gelir.
           Bir yazılım projesi birden fazla bileşene yani component’e ayrılarak programcılar arasında paylaştırılabilir. Bu component’ler programcılar tarafından birbirlerinden bağımsız geliştirilirler ve en sonunda da birleştirilirler. Bu birleştirme işlemi component diyagramındaki gibi olmalıdır.
----Paket (Package) diyagramı----
            Paket (Package) diyagramı, bir sistemin hangi mantıksal gruplara bölündüğünü ve bu gruplar arasındaki bağımlılıkları betimler.
             Bir sistemin hangi mantıksal gruplara bölündüğünü ve bu gruplar arasındaki bağımlılıkları betimler. Fazla detaya inmeden genel hatlarıyla modelleme yapılır, bu diyagram sistemin temel mantığı oluşturulurken kullanılmalıdır.

----Dağılım (Deployment) diyagramı----
            Dağılım (Deployment) diyagramı, sistemde kullanılan donanımları, bu donanımların içinde yer alan bileşenleri ve bu bileşenlerin arasındaki bağlantıları gösterir.  Gösterim genel olarak artifakt, gelişim spesifikasyonları, bağlantılar ve dağılım ilişkilerinini içerir.
----Birleşik Yapı (Composite Structure) diyagramı----
           Birleşik Yapı (Composite Structure) diyagramı, bir sınıfın iç yapısını ve bu yapının mümkün kıldığı iletişimleri tarif eder.Birleşik Yapı Diyagramları özellikle bir Sınıflandırıcı ve onun çevresi ile olan alışverişlerini gösterir. Bu amaçla parça ve konnektör gösterimleri kullanılır. Mesela bir araba sınıflandırıcı olarak düşünülürse ona ait dört tekerlek "parça" ve o tekerlekler arasındaki bağlantılarda "konnektör" olarak gösterilebilir.


YARARLANILAN KAYNAKLAR:



En Güzel Tasarımlar için