Giriş Yansı - 2 Hafta - 6 Tasarım Tasarım, Sistem Analizi çalışması sonucunda üretilen Mantıksal Modelin Fiziksel Modele dönüştürülme çalışmasıdır. Fiziksel Model geliştirilecek yazılımın; hangi parçalardan oluşacağını, bu parçalar arasındaki ilişkilerin neler olacağını, parçaların iç yapısının ayrıntılarını, gerekecek veri yapısının fiziksel biçimini (dosya, veri tabanı, hash tablosu, vektör, vs) tasarımını içerir. 1 Yansı - 3 Yansı - 4 Tasarım Kavramları Modülerlik Soyutlama (abstraction): Detayları gizleyerek yukarıdan bakabilme imkanı sağlanır. İyileştirme (enhancement): Soyutlama düzeyinde irdeleme bittikten sonra, daha alt seviyelere inilerek tanımlamalarda ayrıntı, bazen de düzeltme yapılarak tasarımın daha kesinlik kazanması sağlanır. Modülerlik (modularity): Sistemi istenen kalite faktörleri ışığında parçalara ayrıştırma sonucu elde edilir. Bütün karmaşıklığın tek bir modülde toplanması yerine, anlaşılabilir ve dolayısıyla projenin zihinsel kontrol altında tutulması için sistem bir çok modüle ayrılır. Modüller, isimleri olan tanımlanmış işlevleri bulunan ve hedef sistemi gerçekleştirmek üzere tümleştirilen birimlerdir. Yansı - 5 Yansı - 6 Sistem ve modülleri İşlevsel Bağımsızlık derinlik Sistem A B C A A A A Giriş yelpazesi Çıkış yelpazesi=3 A A A A Modüllere parametre ile veri gönderilir ve sonuç değer alınır. Bu modülü çağıran program parçası sadece bu sonucu kullanabilir. Çağrılan modülün işlevsel olarak yaptıkları ile ilgili değildir. genişlik 1
Veri Tasarımı Yansı - 7 Verilerin Düzenlenmesi Yansı - 8 Yapı Tasarımı, arayüz tasarımı ve süreç tasarımından önce yapılması gereken ilk tasarım veri tasarımıdır. Bilgi saklama ve soyutlama bu işlem için önemli kavramlardır. Değişik tekniklerle veri toplama işlemi gerçekleştikten sonra bu verilerin düzenlenmesi gerekir. Her alınan bilgi incelenmeli ve sistem tasarımcılarının anlayabileceği şekilde sunulmalıdır. Bu eylemi gerçekleştirmek için en bilinen ve kullanılan bazı yöntemler; veri akış şemaları, varlık ilişkili şemalar, karar tabloları ve karar ağaçlarıdır. Veri tasarımında dikkat edilecek konular Yansı - 9 Veri Akış Şemaları Yansı - 10 Değişik veri yapıları değerlendirilmelidir. Bütün veri yapıları ve bunlar üzerinde yapılacak işlemler tanımlanmalıdır. Alt düzeyde tasarım kararları tasarım süreci içerisinde geciktirilmelidir. Bazı çok kullanılan veri yapıları için bir kütüphane oluşturulmalıdır. Kullanılacak programlama dili soyut veri tiplerini desteklemelidir. Veri akış şemaları (Data Flow Diagram - DFD) ile verinin sisteme girişini, sistemde işlenişini, işleniş esnasında sistem içindeki hareketleri, işlendikten sonra sistem içinde saklanması veya sistem dışına gönderilmesi gibi aşamalarda izledigi yol görsel olarak ifade edilir. Verinin işleyiş sırasında kimler tarafından ve ne şekilde işlendiği de gözler önüne seriliyor. Veri Akış Şemaları Veri akış şemaları fiziksel ve mantıksal olarak ikiye ayrılırlar. Fiziksel Veri Akış Şemaları: bu şemalar uygulama bağımlı şemalardır. Gerçek sistemde yer alan donanım, değişik bölümlerdeki değişik insanlar vb. Bu şemalarda yer alır. Mantıksal Veri Akış Şemaları: sistemdeki eylemlerin nasıl gerçekleştiğinden çok sistemde nelerin yer aldığı üzerinde durulur. Yansı - 11 Veri Akış Şeması Elemanları Veri Akış Şeması Elemanları İşlem(Process): veri üzerinde gerçekleşen iş birimidir. Veri Akışı (Data Flow):işlemler arası verinin akışını gösterir Veri Depolama (Data Storage):verinin mantıksal depolanması Dış Varlık (External Entity):verinin kaynağı yada gideceği yerdir. Özellikler Numarası, adı, tipi, tanımlaması, girdilerin ve çıktıların veri akışı, notlar Numarası, adı, tipi, tanımlaması, başka isim, nitelik, notlar Numarası, adı, tipi, tanımlaması, başka isim, nitelik, notlar Etiketi, tipi, tanımlaması, başka isim, nitelik, notlar Yourdon & Coad İŞLEM VERI AKIŞI Veri Deposu Dış Varlık Gösterimi Gane & Sarson İŞLEM VERI AKIŞI Veri Deposu Dış Varlık Yansı - 12 2
Veri Akış Şemaları Yansı - 13 Veri Akış Şemaları Yansı - 14 Bu elemanlar kullanılarak bir veri akış şeması çizilebilir ancak dikkat edilmesi ve uyulması gereken bazı kurallar bulunmaktadır. Her işlem için bir giriş bir de çıkış veri akışı olmalıdır Her işlem kendine gelen veriyi işleyip yeni bir veri üretmelidir. Her veri deposu en az bir tane veri akışına katılmalıdır. Her dış varlık en az bir veri akışına katılmalıdır Bir veri akışı en az bir işleme eklenmelidir. Veri akış şemalarında genelden özele denebilecek bir yapıyla ele alınmaktadır. Bu yapının daha iyi işleyebilmesi için veri akış şemaları katmanlardan oluşur. Bu katmanlarda sistem en üst katmanda en genel durumuyla en alt katmanda ise istenen en özel birimiyle ifade edilir Yansı - 15 Yansı - 16 Örnek Bu kurallar doğrultusunda, bir kumaş fabrikasından kumaş alıp, aldığı kumaşı işleyip müşterilerine satan bir firmanın veri akış şeması: KUMAŞ FABRIKASI DİKİŞ MÜŞTERI Şekilde kumaş fabrikası ve müşteri dış varlık, dikiş ise işlemdir. Bu elemanlar arasında ilişki olduğunu gösteren oklar ise veri akışını ifade etmektedir. İlişki: kumaş fabrikasından gelen kumaşlar dikiş işleminden geçip müşteriye sunulmakta, aynı zamanda müşterilerden bir karşılık alınıp kumaş fabrikasına verilmektedir. Varlık İlişkili Şemalar Yansı - 17 Varlık İlişkili Şemalar Yansı - 18 Varlık ilişkili şemalar (Entity Relationship Diagram ERD) sistemin kullanacağı veritabanı tasarımında kullanılır. Bir sistemdeki varlıkların birbirleriyle olan karşılıklı ilişkileri görsel olarak ifade eden şemalardır. Varlık ilişkili şemaları sistemde gerçekleşen bütün işlemlerin veritabanı eksenli düşünülmesi ile ortaya çıkan şemalardır. Sistemde yer alan bütün veriler varlıklara ve bu varlıklar arasındaki ilişkilere aktarılır. Varlık İlişki Şeması Elemanları Varlık (Entity): verinin depolanmak istendiği somut veya mantıksal nesnelerdir. Varlıklar; görevler, olaylar, yerler, somut nesneler ve kavram olarak beş şekilde sınıflandırılır. İlişki (Relationship): iki varlığın veritabanı içinde veriyi nasıl paylaştıklarını ifade eder. Simgeler VARLIK İLİŞKİ Nitelik (Attribute): varlığın özelliklerini tanımlar. NİTELİK 3
Yansı - 19 Yansı - 20 Örnek Örnek yazar KID ese radı KİTAPLAR KullID adı KULLANICILAR adresi Yukarıdaki örnek bir kütüphane sisteminin kitap ödünç verme modülü için hazırlanmış basit bir varlık ilişki şemasıdır. Bu şemada ÖDÜNÇ-VERİLEN-KİTAPLAR, KİTAPLAR ve KULLANICILAR birer varlık olarak yer almaktadır. 1:N ÖDÜNÇ-VERİLEN- KİTAPLAR 1:N Şemada 1:N ifadesi ilişkinin nasıl bir ilişki olduğunu ifade eder. KullID, Adı gibi ifadeler de varlığın bazı değerlerini tutmaya yöneliktir ve varlığın niteliklerini ifade eder. KID KullID Iade tarihi Yansı - 21 Yansı - 22 Yapısal Tasarım Ayrıntı Tasarım- Süreç Tasarımı Yapısal Tasarımın ana hedefi modüler bir yapı geliştirip modüller arasındaki kontrol ilişkilerini temsil etmektir. Ayrıca yapısal tasarım bazen de veri akışlarını gösteren biçime dönüştürülebilir. Veri Akışları Üç parçada incelenebilir Girdi Akışı Çıktı Akışı İşlem Akışı Süreç tasarımı; veri, yapı ve arayüz tasarımından sonra yapılır. İdeal şartlarda bütün algoritmik detayın belirtilmesi amaçlanır. Ayrıca süreç belirtiminin tek anlamı olması gerekir, değişik şahıslar tarafından farklı yorumlanmamalıdır. Doğal diller kullanılabilir (açıklamalarda, çünkü doğal dil tek anlamlı değildir) Süreç Tanımlama Dili (PDL) Yansı - 23 Yansı - 24 Yapısal Program Yapıları Karar Tabloları Yapısal programlamanın temel amacı; program karmaşıklığını en aza indirmek, program anlaşılabilirliğini artırmaktır. Bazen karmaşık koşul değerlendirmeleri yapmak gerekir. Bunların düzenli bir gösterilimi karar tablolarında yapılabilir. Bu amaçla şu yapıları kullanılır; Ardışıl İşlem yapısı Koşullu işlem yapısı Döngü yapısı GOTO kullanımı uygun değildir. Öncelikle, bütün işlemler saptanmalı, sonra ön koşullar belirlenmelidir. Belirli işlemler ile belirli koşulları birleştirerek tablo oluşturulur. Alt tarafta ise işlemler benzer satırlar olarak gösterilir. 4
Yansı - 25 Yansı - 26 Karar Tabloları Karar Tabloları Sistemde yer alan bütün verileri ve etkinlikleri görülebilmesi hatta olası durumların sezilebilmesi ve gözden kaçırılmaması için etkili bir şekilde kullanılabilirler. Karar tabloları, karar verme mantığının tablolar üzerinde ifade edilmesiyle oluşur. Karar tabloları bir sistem işlemini anlaşılabilir olması için o işlemin koşulları ve çalışma biçimini ayırarak sunar. Bir karar tablosunu meydana getiren 4 eleman vardır. 1. Koşullar: bir karar tablosunda gerekli olan bütün sınamaların listelemesi bazı kaynaklarda şartlar şeklinde de kullanılmaktadır. 2. Eylemler: karar tablosunda yer alan bütün işlemlerin listelenmesi, bazı kaynaklarda faaliyetler şeklinde de kullanılmaktadır. 3. Koşul Kuralları: koşulların gerçekleşmesinde karşılaşılabilecek olası durumları listelemesi 4. Eylem Kuralları: koşul kurallarına göre karar verilen eylemin belirtilmesi. Yansı - 27 Yansı - 28 Karar Tablosu Örneği-Hesap Karar Ağaçları Kurallar 1 2 3 4 Hesap Geçerli X X X X Şifre Geçerli X X X Karar verme aşamalarının kök dallanmalı bir yapıyla ortaya çıktığı durumlarda oldukça verimli kullanılan bir yöntem olan karar ağaçları dallanmaların grafiksel olarak gösterildiği şemalardır. Yeterli Nakit Var X Yeterli Bakiye Var X X Karar ağaçları kararların, olayların, bir sorunun sonuçları ile ilgili durumların iki boyutlu grafiklerle sunulmasıdır. Bakiye Bildirme İşlemi Para Çekme İşlemi Para Yatırma İşlemi X X X Karar ağaçları, sistemle ilgili olası, beklenen, alternatif durumları belirlemek için kullanırlar. Bununla beraber birbiri ardına gelen kararlar dizisinin nasıl ilerlediğini gösteren yolda karar ağaçları ile ifade edilebilir. Para Gönderme İşlemi X Karar ağaçları kök denebilecek bir tek durumla başlar ve her biri bir çıktı (karar) olan birden fazla eylemle son bulur. Yansı - 29 Yansı - 30 Karar Ağacı Örneği Program Tanımlama Dili Program Tanımlama Dilleri süreç belirtiminde doğal dillerin programlama dili ile sentezlenmesi şeklinde ortaya çıkmıştır. Hangi programlama dilinin kullanılacağından bağımsız özellikler bulunmalıdır. DO Hesap Numarasını Oku IF (hesap numarası geçerli değil) başlangıca dön işlem türünü iste IF (para yatırma islemi) { para_yatir(); Başlangıca dön} IF (yeterli bakiye yok) başlangıca dön WHILE 5
Tasarlanması Gereken Ortak Alt Sistemler Yetkilendirme altsistemi Güvenlik altsistemi Yedekleme altsistemi Veri transferi altsistemi Arşiv altsistemi Dönüştürme altsistemi Yansı - 31 Yetkilendirme Alt Sistemi Özellikle kurumsal uygulamalarda farklı kullanıcıların kullanabilecekleri ve kullanamayacakları özellikleri ifade eder. İşlev bazında yetkilendirme Ekran bazında yetkilendirme Ekran alanları bazında yetkilendirme Oracle veri tabanına erişim konusunda yetkilendirme yapmaktadır. Yansı - 32 Güvenlik Alt Sistemi Yansı - 33 Yedekleme Alt Sistemi Yansı - 34 Yapılan bir işlemde, işlemi yapan kullanıcının izlerinin saklanması işlemleri. LOG files (Sistem günlüğü) Her bilgi sisteminin olağandışı durumlara hazırlıklı olmak amacıyla kullandıkları veri tabanı (sistem) yedekleme ve yedekten geri alma işlemlerinin olması gerekmektedir. Veri İletişim Alt Sistemi Yansı - 35 Arşiv Alt Sistemi Yansı - 36 Coğrafi olarak dağıtılmış hizmet birimlerinde çalışan makineler arasında veri akışının sağlanması işlemleri Çevirim içi veri iletimi (real-time) Çevirim dışı veri iletimi (disketler, teypler) Belirli bir süre sonrasında sık olarak kullanılmayacak olan bilgilerin ayrılması ve gerektiğinde bu bilgilere erişimi sağlayan alt sistemlerdir. Aktif veri tabanı. 6
Yansı - 37 Yansı - 38 Dönüştürme Alt Sistemi Kullanıcı Arayüz Tasarımı Geliştirilen bilgi sisteminin uygulamaya alınmadan önce veri dönüştürme (mevcut sistemdeki verilerin yeni bilgi sistemine aktarılması) işlemlerine ihtiyaç vardır. Kullanıcı ile ilişkisi olmayan arayüzler Modüller arası arayüz Sistem ile dış nesneler arası arayüz Kullanıcı arayüzleri Kullanım kolaylığı ve öğrenim zamanı esastır Program=arayüz yaklaşımı vardır Yansı - 39 Yansı - 40 Genel Prensipler Bilgi Gösterimi Veri giriş formlarının tutarlı olması Önemli silmelerde teyit alınmalı Yapılan çoğu işlem geri alınabilmeli Hataların affedilmesi, yanlış girişte kırılmama Komut isimlerinin kısa ve basit olması Menülerin ve diğer etkileşimli araçların standart yapıda kullanımı Yalnızca içinde bulunulan konu çerçevesi ile ilgili bilgi gösterilmeli Veri çokluğu ile kullanıcı bunaltılmamalı, grafik ve resimler kullanılmalı Tutarlı başlık, renkleme ve kısaltma kullanılmalı Hata mesajları açıklayıcı ve anlaşılır olmalı Değişik tür bilgiler kendi içinde sınıflandırılmalı Rakamsal ifadelerde analog görüntü verilmeli (%89 değil) Yansı - 41 Yansı - 42 Veri Girişi Kullanıcı Arayüz Prototipi Kullanıcı hareketleri en aza indirilmeli Gösterim ve girdi sahaları birbirinden ayrılmalı (renk) Kullanıcı uyarlamasına izin verilmeli, kullanıcı bazı özellikleri tanımlayabilmeli Tasarım çalışması sonucunda, daha önceden gereksinim çalışması sırasında hazırlanmış olan kullanıcı arayüz prototipi, ekran ve rapor tasarımları biçimine dönüşür. Ekranlar son halini alır, raporlar kesinleşir. Kullanıcıya gösterilerek onay alınır. Kullanılan konu ile ilgili gereksiz komutlar deaktifleştirilmeli Bütün girdiler için yardım kolaylıkları olmalı Tüm programın tek elden çıktığının ifade edilebilmesi açısından tüm ekranların aynı şablon üzerine oturtulması önerilmektedir. Menü Çubuğu Araç Çubuğu Gövde (Değişebilir) Durum Çubuğu 7
Başlangıç Tasarım Gözden Geçirme Yansı - 43 Ayrıntılı Tasarım Gözden Geçirme Yansı - 44 Yapılan tasarım çalışmasının bir önceki geliştirme aşaması olan analiz aşamasında belirlenen gereksinimleri karşılayıp karşılamadığının belirlenmesidir. Sistem gereksinimlerine yardımcı olan kullanıcılar Sistem analizini yapan çözümleyiciler Sistemin kullanıcıları Tasarımcılar Yönlendirici Sekreter Sistemi geliştirecek programcılar dan oluşan bir grup tarafından yapılır. Başlangıç tasarımı gözden geçirme çalışmasının başarılı bir biçimde tamamlanmasından sonra, tasarımın teknik uygunluğunu belirlemek için Ayrıntılı Tasarım Gözden Geçirme çalışması yapılır. Bu çalışmada; Çözümleyiciler Sistem Tasarımcıları Sistem Geliştiriciler Sekreter den oluşan bir ekip kullanılır. Yansı - 45 Yansı - 46 Tasarım Kalite Ölçütleri Bağlaşım Bağlaşım (Coupling) Tasarımı oluşturan modüller arası ilişki ile ilgilidir. Modüller arası bağlılığın ölçülmesi için kullanılan bir ölçüttür. Yüksek kaliteli bir tasarımda bağlaşım ölçümü az olmalıdır. Bağlılık-Yapışıklık (Cohesion) Modüllerin iç yapısı ile ilgilidir. Bağlaşımın düşük olması Hatanın dalgasal yayılma özelliğinin azaltılması Modüllerin bakım kolaylığı Modüller arası ilişkilerde karmaşıklığın azaltılması nedenleri ile istenmektedir Yansı - 47 Yansı - 48 Yalın Veri Bağlaşımı Karmaşık Veri Bağlaşımı Herhangi iki modül arası iletişim yalın veriler (tamsayı, karakter, boolean, vs) aracılığı ile gerçekleştiriliyorsa bu iki modül yalın veri bağlaşımlıdır şeklinde tanımlanır. Herhangi iki modül arasındaki iletişimde kullanılan parametrelerin karmaşık veri yapısı (kayıt, dizi, nesne, vs) olması durumunda modüller karmaşık veri paylaşımlı olarak tanımlanır. 8
Yansı - 49 Yansı - 50 Denetim Bağlaşımı Ortak Veri Bağlaşımı İki Modül arasında iletişim parametresi olarak denetim verisi kullanılıyorsa bu iki modül denetim bağlaşımlı olarak tanımlanır. Eğer iki modül ortak bir alanda tanımlanmış verilere ulaşabiliyorsa bu iki modül ortak veri bağlaşımlı olarak tanımlanır. Verilerin ortak veri bağlaşımlı olmaları şu nedenlerden dolayı fazla istenmez; Ortak veri alanını izlemek zordur. Ortak veri kullanan modüllerde yapılan değişiklikler diğer modülleri etkiler. Ortak veri üzerinde yapılacak değişikliklerde bu veriyi kullanacak bütün modüller göz önüne alınmalıdır. Yansı - 51 Yansı - 52 İçerik Bağlaşımı Bağlılık-Yapışıklık Modüllerin iç içe tasarlanması sonucu, bir modülün başka bir modül içerisinde tanımlanmış veri alanına erişebilmesi olanaklaşır ve bu durum içerik bağlaşımına yol açar. Bir modülün kendi içindeki işlemler arasındaki ilişkilere ilişkin bir ölçüttür. Modül gücü olarak ta tanımlanır. Tasarımda bağlılık-yapışıklık özelliğinin yüksek olması tercih edilir. Yapışıklık ile Bağlaşım ters orantılıdır. Yansı - 53 Yansı - 54 İşlevsel Yapışıklık Sırasal Yapışıklık İşlevsel Yapışık bir modül, tek bir iş problemine ilişkin sorunu çözen modül olarak tanımlanır. Maas_Hesapla, Alan_Hesapla gibi Bir modülün içindeki işlemler incelendiğinde, bir işlemin çıktısı, diğer bir işlemin girdisi olarak kullanılıyorsa bu modül sırasal yapışık bir modül olarak adlandırılır. Ham_Veri_Kaydını_Düzelt Duzeltilmis_Ham_Veri_Kaydini_Dogrula Dogrulanmis_Kaydi_Gonder 9
Yansı - 55 Yansı - 56 İletişimsel Yapışıklık Yordamsal Yapışıklık Bir modülün içindeki farklı işlemler aynı girdi ya da çıktıyı kullanıyorlarsa bu modül iletişimsel yapışık bir modül olarak adlandırılır. Yordamsal Yapışık modüldeki işlemler arasında denetim ilişkisi bulunmaktadır. İşlemlerin birbirleri ile veri ilişkisi yoktur, ancak işlem sırası önemlidir. Sicil_No_yu_Al Adres_Bilgisini_Bul Telefon_Bilgisini_Bul Maas_Bilgisini_Bul Ekran_Goruntusunu_Yaz Giris_Kaydini_Oku Yansı - 57 Yansı - 58 Zamansal Yapışıklık Mantıksal Yapışıklık Bir modül içindeki işlemlerin belirli bir zamanda uygulanması gerekiyor ve bu işlemlerin kendi aralarında herhangi bir ilişkisi yok, yani işlemlerin sırası önemli değil ise, zamansal yapışıklık vardır. Mantıksal olarak aynı türdeki işlemlerin bir araya toplandığı modüller mantıksal yapışık olarak adlandırılır. Dizilere değer atama işlemleri Alarm_Zilini_Ac Kapiyi_Ac Kamerayi_Calistir Gelişigüzel Yapışıklık Yansı - 59 İşlemler arasında herhangi bir ilişki bulunmaz. Ara_Kayit_Oku B_dizisine_baslangic_deger_ata Stok_kutugu_oku Hata_iletisi_yaz Unified ModelLing Language (UML) Bütünleşİk Modelleme DİLİ 60 10
UML NEDİR? Yansı - 61 UML NEDİR? Yansı - 62 UML, yazılımın tasarımı ve planlanması için kullanılan standart bir dildir. UML yazılım mühendisliğinde nesneye yönelik sistemleri modellemede kullanılan açık standart olmuş bir görsel modelleme dilidir. 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. 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 TARİHİ Yansı - 63 UML YE NEDEN GEREK VAR? Yansı - 64 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. Yansı - 65 Yansı - 66 UML NİN AVANTAJLARI-1 UML NİN AVANTAJLARI-2 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. 11
UML Temel Konvensiyonlar UML DİYAGRAMLARI Yansı - 68 Bütün UML diyagramları düğüm ve kenarlardan oluşan graflardan oluşur Nodes are entities and drawn as rectangles or ovals Dikdörtgenler sınıfları veya durumları gösterir Oval şekiller fonksiyonları gösterir Sınıfların isimlerinde alt çizgi yoktur SimpleWatch Firefighter Durumların alt çizgisi vardır mywatch:simplewatch Joe:Firefighter İki düğüm arasındaki kenar onların arasındaki ilişkiyi belirtir 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. Yapısal diyagramlarda modellenen sistemde nelerin var olması gerektiği vurgulanır. Davranış diyagramlarında modellenen sistemde nelerin meydana gelmesi gerektiğini belirtir. 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. DAVRANIŞ DİYAGRAMLARI Yansı - 69 Durum Diyagramları Event Initial state Davranış Diyagramları: button1&2pressed Blink Hours button2pressed Increment Hours Kullanım Senaryosu (Use-Case) diyagramı Transition button1pressed Durum (Statechart) diyagramı Faaliyet (Activity) diyagramı State button1&2pressed Blink Minutes button2pressed button1pressed Increment Minutes Stop Blinking Blink Seconds button2pressed Increment Seconds Final state Tek bir objenin dinamik davranışını tarif eder YAPISAL DİYAGRAMLAR Yapısal Diyagramlar Sınıf (Class) diyagramı Yansı - 71 Sınıf Diyagramları Sınıf diyagramları sisteminin yapısını temsil eder Association Class Nesne (Object) diyagramı Bileşen (Component) diyagramı Paket (Package) diyagramı Dağılım (Deployment) diyagramı Birleşik Yapı (Composite Structure) diyagramı Multiplicity 2 PushButton state push() release() Attribute 1 1 LCDDisplay blinkidx blinkseconds() blinkminutes() blinkhours() stopblinking() referesh() Watch 1 1 1 2 Battery Load Operations 1 Time Now 12
Yansı - 73 ETKİLEŞİM DİYAGRAMLARI Etkileşim Diyagramları Sıralama (Sequence) diyagramı İletişim (Communication) diyagramı Etkileşime Bakış (Interaction Overview) diyagramı Sıralama Diyagramları Actor Message Object Lifeline :WatchUser :Watch :LCDDisplay pressbutton1() blinkhours() pressbutton1() blinkminutes() pressbutton2() incrementminutes() refresh() pressbutton1and2() commitnewtime() :Time Zaman Akış (Timing) diyagramı Activation stopblinking() Sistemin objeler arasındaki dinamik davranışını mesaj olarak tarif eder Yansı - 75 Yansı - 76 USE CASE DİYAGRAMLARI USE CASE DİYAGRAMLARI Analiz aşamasında Use Case Diyagramları kullanılır. Tasarım aşamasında ise modellerin 3 tipi ortaya konulur. 1. Sınıf Diyagramları 2. Durum Diyagramları 3. Etkileşim Diyagramları Sistemin çok basit bir şekilde modellenmesini ve işlerin detayının (senaryonun) metin olarak anlatılmasını içerir. Aktörden gelen bazı isteklere karşı sistemin yaptığı aktiviteleri gösterir. Gelişmenin erken safhalarında yapılandırılır. Amaç Sistemin içeriğini belirtmek. Sistemin gereksinimlerini elde etmek. Sistemin mimarisini geçerli kılmak. Analistler ve uzmanlar tarafından geliştirilir. USE CASE DİYAGRAMLARI Yansı - 77 USE CASE DİYAGRAMLARI BİLEŞENLERİ Yansı - 78 Aktör Sistemin kullanıcılarıdır. Aktörler genelde belirli bir rol ifade ederler. Diğer aktörlerle bağlantılı olabilirler bu bağlantı bir ok ile gösterilir. Sistem sınırları dışında gösterilir. 13
Yansı - 79 Yansı - 80 USE CASE DİYAGRAMLARI BİLEŞENLERİ USE CASE DİYAGRAMLARI BİLEŞENLERİ Use case Sistemin destekleyeceği işler. Use case Sistem sınırı İçerisinde sistemin ismi yazılıdır. Sistemin kapsamını gösterir. Sistem Sistem fonksiyonelliğinin büyük bir parçasını gösterir. Diğer bir use case ile genişletilebilir. Diğer bir use case içerebilir. Sistem sınırları içinde gösterilir. Bağıntı ilişkisi Aktör ve use case ler arasındaki bağıntıyı gösteren çizgidir. * * Yansı - 81 USE CASE DİYAGRAMLARI BİLEŞENLERİ Inclusion (içerme) ilişkisi USE CASE DİYAGRAMLARI BİLEŞENLERİ Extension (eklenti) ilişkisi Yansı - 82 Bu metotla bir use case içindeki adımlardan birini başka bir use case içinde kullanabiliriz. Bu metodla varolan bir Use Case 'e yeni yeni adımlar ekleyerek yeni use case 'ler yaratılır. Inclusion yöntemini kullanmak için <<include>> şeklindeki bir ifade kullanılır. Kullanmak istediğimiz use case 'ler arasına çektiğimiz noktalı çizginin üzerine <<include>> yazısını yazarız. <<include>> Inclusion'da olduğu gibi extension 'ları göstermek için yine use case 'ler arasına noktalı çizgiler konur ve üzerine <<extend>> ibaresi yazılır. <<extend>> Yansı - 83 Yansı - 84 USE CASE DİYAGRAMLARI BİLEŞENLERİ Genelleme ilişkisi: Özelleşmiş use case ile daha genel use case arasındaki ilişkidir. Özelleşmiş use case den temel use case e doğru bir ok ile gösterilir. 14
Yansı - 85 Yansı - 86 Use Case Diyagramı Yansı - 87 Yansı - 88 Include & Extend Yansı - 89 Yansı - 91 Genelleme 15
Yansı - 92 serhatkilicarslan.com( Slides için teşekkürler) M. Erhan Saridogan, Martin Fowler UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed., Addison-Wesley, 2003 Grady Booch,James Rumbaugh,Ivar Jacobson The Unified Modeling Language User Guide, Addison Wesley, 2 nd edition, 2005 Open Source UML tools http://java-source.net/open-source/uml-modeling Diğer UML slides 16