YAZILIM MODELLEME VE TASARIM

Transkript

1 YAZILIM MODELLEME VE TASARIM «UML - Tümleştirilmiş Yazılım Geliştirme Süreci» Özer Çelik Matematik-Bilgisayar Bölümü

2 UML NEDİR? Yazılım ve donanımların bir arada düşünülmesi gereken, Zor ve karmaşık programların, Özellikle birden fazla yazılımcı tarafından kodlanacağı durumlarda, Standart sağlamak amacıyla endüstriyel olarak geliştirilmiş grafiksel bir dildir. Programlama dili-diyagram çizme ve ilişkisel modelleme dili

3 UML NEDİR? UML 'in doğuşu son yıllarda yazılım endüstrisindeki en büyük gelişmelerden biri olarak kabul edilebilir. UML 1997 yılında yazılımın, diyagram şeklinde ifade edilmesi için bir standartlar komitesi tarafından oluşturuldu. Diğer dallardaki mühendislerin standart bir diyagram çizme aracı -Programcıların UML

4 UML NEDİR? UML yazılım sisteminin önemli bileşenlerini tanımlamayı, tasarlamayı ve dokümantasyonunu sağlar Yazılım geliştirme sürecindeki tüm katılımcıların (kullanıcı, iş çözümleyici, sistem çözümleyici, tasarımcı, programcı,...) gözüyle modellenmesine olanak sağlar, UML gösterimi nesneye dayalı yazılım mühendisliğine dayanır.

5 UML AVANTAJLARI Yazılımın geniş bir analizi ve tasarımı yapılmış olacağından kodlama işlemi daha kolay ve doğru olur Hataların en aza inmesine yardımcı olur Geliştirme ekibi arasındaki iletişimi kolaylaştırır Tekrar kullanılabilir kod sayısını artırır Tüm tasarım kararları kod yazmadan verilir Yazılım geliştirme sürecinin tamamını kapsar resmin tamamını görmeyi sağlar

6 GRAFİKSEL GÖSTERİMLER

7 GRAFİKSEL GÖSTERİMLER Bu grafiksel gösterimler aynı şeye farklı şekillerde bakabilmeyi sağlar.

8 4 + 1 BAKIŞ Bir yazılım sistemi oluşturulurken sadece tek boyutta analiz ve modelleme yapılmaz. Bu amaçla; yazılım geliştirme sürecinin farklı aşamalarında farklı UML diyagramlarını kullanmak gerekmektedir. 4+1 bakış, bu diyagramları sınıflandırmak ve yazılım yaşam çevrimindeki kullanım yerlerini ortaya koymak için kullanılan bir kavramdır.

9 4 + 1 BAKIŞ 1. Kullanıcı Bakışı (User View) 2. Yapısal Bakış (StructuralView) 3. Davranış Bakışı (BehavioralView) 4. Gerçekleme Bakışı (ImplementationView) 5. Ortam Bakışı (Environment View)

10 4 + 1 BAKIŞ 1- Kullanıcı Bakışı (User View) Müşteri gereksinimlerini ortaya koymak ve müşteriye, sistemi tanıtmak amacı ile kullanılan bakış açısıdır. Bazı kaynaklarda; kullanım senaryosu (use case) bakışı olarak da açıklanmaktadır. Bu amaçla "kullanım senaryosu" (use case) diyagramları kullanılmaktadır.

11 4 + 1 BAKIŞ 2- Yapısal Bakış (StructuralView) Sistemin nelerden meydana geldiğini gösteren bakış açısıdır. Bu amaçla; "sınıf" (class) diyagramları ve "nesne" (object) diyagramları kullanılmaktadır.

12 4 + 1 BAKIŞ 3- Davranış Bakışı (BehavioralView) Sistemin dinamik yapısını ortaya koyan bakış açısıdır. Bu amaçla; «ardışık" (sequence), "işbirliği" (collaboration), "durum«(state) ve «etkinlik" (activity) diyagramları kullanılmaktadır.

13 4 + 1 BAKIŞ 4- Gerçekleme Bakışı (Implementation View) Sistemin alt modüllerini ortaya koyan bakış açısıdır. Bu amaçla; "bileşen" (component) diyagramları kullanılmaktadır.

14 4 + 1 BAKIŞ 5- Ortam Bakışı (Environment View) Donanımın, fiziksel mimarisinin ortaya konduğu bakış açısıdır. Bu amaçla; "dağıtım" (deployment) diyagramları kullanılmaktadır.

15 SINIF DİAGRAMLARI Sınıf Diyagramları UML 'in en sık kullanılan diyagram türüdür. Sınıflar nesne tabanlı programlama mantığından yola çıkarak tasarlanmıştır. Sınıf diyagramları bir sistem içerisindeki nesne tiplerini ve birbirleri ile olan ilişkileri tanımlamak için kullanılırlar.

16 SINIF DİAGRAMLARI Sınıfların bir adı nitelikleri ve İşlevleri vardır Bunlara ek olarak notes Constraints

17 SINIF DİAGRAMLARI

18 NESNE ÖRNEĞİ Kimlik: Öğrenci123 Durum: ad: Ali Yılmaz öğrencino: yıl: 2007 Metotlar: dersekle() derssil() danısmanata()

19 SINIF TANIMLARI Alanlar (fields):nesne özelliklerini tanımlayan değişkenler, adları ve türleri ile. Metotlar (methods):metot adları, döndürdüğü tür, parametreleri, ve metotu gerçekleştiren program kodu

20 UML Diyagramı

21 SINIF ERİŞİM Public: diğer sınıflar erişebilir. UML de + sembolü ile gösterilir. Protected: aynı paketteki (package) diğer sınıflar ve bütün alt sınıflar (sub classes) tarafında erişilebilir. UML de # sembolü ile gösterilir. Package: aynı paketteki (package) diğer sınıflar tarafında erişilebilir. UML de ~ sembolü ile gösterilir. Private: yalnızca içinde bulunduğu sınıf tarafından erişilebilir (diğer sınıflar erişemezler). UML de sembolü ile gösterilir.

22 UML Nesne Gösterimi

23 SINIF DIAGRAMLARI Sınıflar arasındaki ilişkiyi göstermek için iki sınıf arasına düz bir çizgi çekilir. İlişkiyi gösteren çizginin üzerine ilişkinin türü yazılır.

24 SINIF DIAGRAMLARI Bazı durumlarda sınıflar arasındaki ilişki, bir çizgiyle belirtebilecek şekilde basit olmayabilir. Bu durumda ilişki sınıfları kullanılır. İlişki sınıfları bildiğimiz sınıflarla aynıdır. Sınıflar arasındaki ilişki eğer bir sınıf türüyle belirleniyorsa UML ile gösterilmesi gerekir.

25 SINIF DIAGRAMLARI Müşteri ile Sipariş sınıfı arasında ilişki vardır. 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.

26 KALITIM (INHERITANCE) Eğer eşyalar arasında genellemeler yapabiliyorsak genellemeyi yaptığımız eşyalarda ortak özelliklerin olduğunu biliriz. Mesela, "Hayvan" diye bir sınıfımız olsun. Memeliler, Sürüngenler, Kuşlar da diğer sınıflarımız olsun. Memeliler, Sürüngenler ve Kuşlar sınıfının farklı özellikleri olduğu gibi hepsinin Hayvan olmasından dolayı birtakım ortak özellikleri vardır.

27 KALITIM ÖRNEK

28 İÇERME (AGGREGATIONS) Bazı sınıflar birden fazla parçadan oluşur. Bu tür özel ilişkiye "Aggregation" denir. Mesela,bir TV 'yi ele alalım. Bir televizyon çeşitli parçalardan oluşmuştur. Ekran, Uzaktan Kumanda, Devreler vs.. Bütün bu parçaları birer sınıf ile temsil edersek TV bir bütün olarak oluşturulduğunda parçalarını istediğimiz gibi ekleyebiliriz. Aggregation ilişkisini 'bütün parça' yukarıda olacak şekilde ve 'bütün parça'nın ucuna içi boş elmas yerleştirecek şekilde gösteririz.

29 Örnek Sınıf Diyagramı

30 Nesne Diyagramları Nesne Diyagramları nesneler ve aralarındaki bağıntıları gösterirler. Nesneler, sınıfların somut örnekleri olduğundan sınıf özelliklerinin değer almış halidirler

31 Kullanım Senaryoları (Use-Case Model) İsteklerin anlaşılmasını ve ifade edilmesini sağlayan bir yöntemdir. Özellikle işlevsel isteklerin ifade edilmesinde kullanılır. Senaryolar sadece bir doküman değildir. Senaryolar olmadan sistemin ne yapması gerektiği ne olarak belirlenemez.

32 Kullanım Senaryoları (Use-Case Model) 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.

33 Kullanım Senaryoları (Use-Case Model) Örnek: Bir otomatik para çekme makinesinde (ATM) müşteri ile sistem arasında gerçekleşebilecek olan olayların oluşturduğu senaryolar şunlar olabilir. 1. Müşteri kartını makineye takar. 2. Sistem şifreyi sorar. 3. Müşteri şifreyi girer. 4. Sistem şifreyi onaylar. 5. Müşteri para çekme işlemini seçer. 6. Müşteri çekeceği para miktarını seçer. 7. Sistem parayı, makbuzu ve kartı verir. Yukarıdaki akış bu sistemdeki olası senaryolardan sadece biridir. Aynı sistemdeki başka bir senaryo da müşterinin bakiyesinin yeterli olmaması durumuyla ilgilidir.

34 Kullanım Senaryoları (Use-Case Model) 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 birbilgisayar sistemidir.

35 Kullanım Senaryoları (Use-Case Model) 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 olaylar dan etkilenirler. 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.

36 Birincil Aktör ve Sistemin Sınırları

37 Birincil Aktör ve Sistemin Sınırları

38 Birincil Aktör ve Sistemin Sınırları

39 Birincil Aktör ve Sistemin Sınırları

40 Kullanım Senaryolarının Yazılması Kullanım senaryolarının ifade edilmesi: İhtiyaçların ve istenen özelliklerin listelenmesi şeklinde DEĞİL. Sistem kara kutu olarak ele alınır. Sistemin iç yapısı görülmez, sistemin dışarıya(aktörlere) karşı sorumlulukları ifade edilir. Aktörler ile sistem arasındaki etkileşim etken cümleler ile ifade edilir. "Ne yapar?" sorusu cevaplanır, "Nasıl yapar?«değil. Sistemin sorumluluklarını nasıl yerine getireceği daha sonra gelinecek olan tasarım aşamasında ele alınacak problemdir. Kullanım senaryolarını yazdığımız şimdiki aşamada ise sadece istekler anlaşılmaya çalışılıyor. Sistemin bitmiş hali hayal edilerek bu sistem çalıştığında oluşabilecek senaryolar yazılır.

41 Kullanım Senaryolarının Yazılması 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şağıdaki bölümler gelir a) Ö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ı.

42 Kullanım Senaryolarının Yazılması İ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.

43 Kullanım Senaryolarının Yazılması Ön koşullar(preconditions): Belli bir senaryo grubunu (use case) oluşturanolayları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ğı durumlardır. Son koşullar ilgililerin beklentilerine (amaçlarına)denk düşer

44 Kullanım Senaryolarının Yazılması b) 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ümlelerkullanılır; kim ne yapar açıktır. Adımlar üç farklı gruba ayrılır: 1. Kullanıcılar ile sistem arasında etkileşim, tetikleme 2. Onaylama (çoğunlukla sistem tarafından) 3. Sistemde durum değişikliği, bir bilginin kayıt edilmesi. Örnek: 1. 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?

45 SORULARINIZ