BLG4146 - Sistem Analizi ve Tasarımı Öğr. Grv. Aybike ŞİMŞEK
Analiz Evresi Temel amaç Yeni kurulan sistemden ne bekleniyor Bu sistem ne yapmalı Sistemi kullanacak bireyler ne istiyorlar İşletme fonksiyon ve faaliyetleri incelenmeli, sistemin nasıl çalıştığı en ince ayrıntısına kadar araştırılmalıdır. Yapılan işlemler Bilgilerin toplanması Sistem gereksinimlerinin tanımlanması Prototiplerin oluşturulması Alternatif çözüm önerilerinin sunulması Önerilerin gözden geçirilmesi ve alternatiflerin değerlendirilmesi 2
Sistemin çözümlenmesi Mevcut sistemin fiziksel yapısının çıkarılması Mevcut sistemin mantıksal yapısının çıkarılması Yeni sistemin mantıksal yapısının oluşturulması Yeni sistemin fiziksel modelinin oluşturulması 3
Mevcut sistemin fiziksel yapısının çıkarılması Mevcut sistem incelenir İşler fiziksel olarak nasıl yürütülüyor, sistem nasıl işliyor? Örneğin öğrenci kayıt süreci Öğrenciler öğrenci işlerinden 3 adet öğrenci kayıt formu alır Kayıt formu öğrenci ve danışmanı ile beraber doldurulur Çakışan dersler verilmez 30 krediden fazla ders verilmez Üst sınıftan ders verilmez Öğrenci ve danışman tarafından imzalanır Öğrenci işlerinde onaylatılır Onaylanan formlardan biri öğrencide, biri danışmanda, biri ise öğrenci işlerinde kalır Öğrenci işleri bu formdaki bilgileri öğrencinin dosyasına işler ve form öğrencinin dosyasında kalır Öğrenci işleri öğrencinin seçtiği her dersi ilgili dersin kayıt formuna işler. 4
Mevcut sistemin mantıksal yapısının çıkarılması Birinci adımda ortaya çıkarılan fiziksel model ikinci adımda daha genel mantıksal modele dönüştürülür. Matbu kayıt formu öğrenci ve danışmanı ile beraber doldurulur. Öğrenci işlerinde onaylatılır. Öğrenci işleri bu formdakileri öğrencinin dosyasına ve ders kayıt formuna işler. 5
Yeni sistemin mantıksal yapısının oluşturulması Genellikle eski sistemin mantıksal modeliyle yeni sistemin mantıksal modeli ya birebir aynı veya çok benzeri olur. 6
Yeni sistemin fiziksel modelinin oluşturulması İki veya üçüncü adımda ortaya çıkan mantıksal model temel alınır ve bilişim sistemine bunların nasıl aktarılacağı belirlenir. Genelde metinsel anlatım yerine veri akış modelleri çizilir. Bu veri akış modelleri kullanıcı arayüzlerinin tasarımına ışık tutar. 7
Analiz evresinde müşterinin istekleri ve gereksinimleri araştırılır. Gereksinim, sistemin herhangi bir görevi yerine getirebilmesi için ihtiyaç duyduğu özelliklerdir. Ortaya çıkacak olan özellikler sistemin amacına hizmet etmeli ve her zaman NE sorusunun yanıtı olmalıdır. 8
Sistem Gereksinimleri 1. İşlevsel Gereksinimler 2. Teknik ve Kaynak Gereksinimleri 3. Sistem Arayüzleri 4. Veriyle İlgili Gereksinimler 5. Güvenlik Gereksinimleri 6. Kullanıcılar ve İnsan Faktörü 9
İşlevsel Gereksinimler Sistemin yürüteceği daha çok hesaplamalı, işlevsel gereksinimler belirlenmelidir. Örn. Vergi hesaplamaları, üç aylık bilanço, öğrenci not dökümü, not ortalaması veya kredi hesabı Daha sonra bunlar program yazımı aşamasında birer fonksyion, alt prosedür vs. haline getirilecektir. 10
11
Teknik ve Kaynak Gereksinimleri Sistemin işletim ortamının anlatıldığı bölümdür. Sistemin performans sorgulaması, çevre birimleri burada ortaya çıkarılır. Örneğin istemci/sunucu mimarisi kullanılıp kullanılmayacağı, bilgisayar yapılandırma özellikleri veya en az konfigürasyon, sunucu kapasitesi, işletim sistemi vs. belirlenmelidir. Bütün bunlara bağlı olarak veritabanı sistemi, programlama dili değişecektir. Ne tür yazılım, donanım ve bunların miktar ve özellikleri dışında yeni sistemin hem inşası hem de kullanımı için gerekli olan personel sayısı, bu elemanların vasıflarının ne oalcağı bu aşamada belirlenir. 12
13
14
Veriyle İlgili Gereksinimler Sistem arayüzleri raporunu tamamlayan bölümdür. Uygulamada ayrı ayrı raporlar olabileceği gibi bir arayüz raporu ile beraber de hazırlanabilir. Girdi ve çıktılar için özel bir format var mıdır? Veriler ne kadar sıklıkla alınıp gönderilmektedir? Sayısal veriler hangi hassasiyette hesaplanmalıdır? Sistemde varsayılan olarak gelmesi gereken veri var mıdır? Sistemin işleyeceği veri günlük, haftalık, aylık ne kadar olmalıdır? Veriler veritabanında nasıl tutulmalıdır? Yedeklemeler nerede ve ne kadar yaşlı veriler için yapılmalıdır? 15
16
Güvenlik Gereksinimleri Sisteme girişler kontrollü mü olacaktır? Kullanıcı yetkilendirmeleri nelerdir? Sistem ne sıklıkla yedeklenmelidir? 17
Kullanıcılar ve İnsan Faktörü Kullanıcılar ve insan faktörü sistem analizinin en can alıcı noktalarından birisidir. Sistemi kim ya da kimler kullanacak? Birden fazla türde kullanıcı olacak mı? Kullanıcıların bilgisayar kullanma düzeyleri nedir? Ne kadar eğitim verilmelidir? 18
19
Yazılım İsterleri Çözümlemesi Bir bilgisayar programının başarısı öncelikle müşteri isteklerini tam olarak karşılamasına bağlıdır. Yazılım isterleri çözümleme aşaması Müşterinin yazılımdan bekledikleri belirlenir Gereksinimler açıklığa kavuşturulur Yazılım isterleri modellenir ve tanımlanır Böylece sonraki aşamalar için temel oluşturulur. 20
İster İster nedir? İster Çeşitleri Kullanıcı ve sistem isterleri nelerdir? İşlevsel (functional) ve işlevsel olmayan (non-functional) isterler nelerdir? 21
İster Nedir? İster(gereksinim): Gerekli olan, istenen veya ihtiyaç duyulan. IEEE 729 Kullanıcı tarafından bir problemi çözme ya da bir hedefi gerçekleştirmek için ihtiyaç duyulan durum ya da yetenek Bir sistemin, bir kontrat, standard, belirtim ya da başka bir resmi belgenin şartlarını yerine getirmek için karşılaması ya da sahip olması gereken durum ya da yetenek. Bir sistemin gereksinimleri, o sistem tarafından sağlanan hizmetlerin ve işlevsel kısıtlamaların tanımıdır. 22
İsterler Neden Önemlidir? İsterlerden kaynaklı hatalar geç aşamalarda fark edilir Genellikle yanlış bilgi, ihmal ve tutarsızlık kaynaklıdır Bu durumda da düzeltilme maliyetleri yüksek olur 23
İster Çeşitleri İsterleri neye göre sınıflandıracağız? Detay seviyesine göre Okuyucu kim? (kullanıcı veya sistem) İşlevsel veya işlevsel olmayan İsterleri farklı detay seviyelerinde yazmak gereklidir çünkü farklı okuyucular onları farklı şekillerde kullanacaklardır 24
İster Okuyucuları 25
Kullanıcı İsterleri İşlevsel ve işlevsel olmayan gereksinimleri tanımlamalı, böylece detaylı teknik bilgiye sahip olmayan sistemin kullanıcıları tarafından da anlaşılabilmelidir. Kullanıcı isterleri,doğal dil, basit tablo ve formlar ve şemalar ile tanımlanır. Sadece sistemin harici davranışlarını belirtmeli ve mümkün olduğunca tasarım özelliklerine girmekten kaçınmalıdır. Çoğunlukla, teknik-olmayan okuyucular tarafından okunurlar. 26
Sistem İsterleri Kullanıcı isterlerinin daha detaylı belirtimidir Sistemi tasarlamak için temel oluşturur İdeal olarak, basitçe, harici davranış ve kısıtlamaları tanımlar. Tasarım ve uygulama ile ilgilenmemelidir. Fakat pratikte, tasarım bilgisi bulundurabilir. İster belirtimine yardımcı olabilmek için bir başlangıç mimarisi tasarlanabilir tasarımda yeniden kullanılabilir Başka var olan sistemlerle arayüzü bulunabilir tasarıma kısıt getirir İşlevsel olmayan isterlere özel bir mimariye karar verilebilir tasarıma kısıt getirir. 27
İşlevsel ve işlevsel-olmayan İsterler Sistem ve kullanıcı isterleri aynı zamanda işlevsel ve işlevsel-olmayan isterler olarak da kendi içlerinde sınıflandırılırlar. 28
İşlevsel İsterler İşlevleri ve sistem hizmetlerini tanımlar Yazılımın çeşidine, beklenen kullanıcıya ve yazılımın kullanılacağı sistem çeşidine bağlıdır İşlevsel kullanıcı isterleri sistemin NE yapması gerektiğini söyleyen genel anlatımlardır İşlevsel sistem isterleri ise sistem hizmetlerini detaylı olarak anlatmalıdır(örn. Girdi, çıktı, beklentiler) Sistem çeşitli girdilere nasıl tepki verecek ve bazı durumlarda sistem ne şekilde davranacak. Bazen işlevsel isterler açık olarak sistemin NE yapmaması gerektiğini de söylerler 29
İşlevsel-Olmayan İsterler Her hangi bir işlev ile direk ilgisi olmayan isterlerdir Sistem tarafından sunulan hizmet ve işlevlerin kısıtlamalarıdır. Örn. Güvenilirlik, karşılık süresi, depolama isterleri, sistem arayüzlerinde kullanılan veri gösterimleri İşlevsel olmayan isterler işlevsel olanlara göre daha kritik olabilir. Eğer bunlar karşılanmazsa sistem kullanılamaz (örn. Bir uçak sistemi güvenilirlik gereksinimini karşılamazsa kullanım için emniyetli olarak belgelendirilemez) Sadece geliştirilen yazılım ile değil süreç ile de ilgilidir (kalite standartları, CASE araçları) 30
İşlevsel Olmayan İster Çeşitleri 31
İşlevsel-olmayan ister örnekleri Ürün isterleri X için kullanıcı arayüzü frame ya da Java applett içermeyen basit HTML şeklinde uygulanacaktır Kurum isterleri Sistem geliştirme süreci ve teslim edilebilir belgeler XYZ standardına uyacaktır Harici isterler Sistem, kütüphane sistemini kullanan çalışanlara kullanıcıların adı ve kütüphane referans numarası dışında başka kişisel bilgilerini açıklamayacaktır 32
İşlevsel-olmayan ister örnekleri (dvm) İşlevsel olmayan isterler diğer işlevsel olmayan ya da işlevsel isterler ile çakışabilir ya da etkileşebilir. Örn. Sistem tarafından kullanılacak maksimum hafıza 4MB den fazla olmayacak. Sistem ADA kullanılarak yazılacak. Ada programını istenen 4MB den düşük hafıza isteri ile derlemek mümkün olmayabilir. Başka bir geliştirme dili seçimi Hafızayı artırma 33
İşlevsel-olmayan isterlerin ölçümü Doğruluğunu sınamak zordur: Kullanılabilecek olası ölçüm yolları(metric)vardır. Bazılarını belirlemek zordur: bakım gibi Mümkün olduğunca doğruluğu sınanabilecek işlevselolmayan ister yazmaya çalışılmalıdır 34
İşlevsel-olmayan ister ölçütleri (metrics) 35
İşlevsel-olmayan ister örnekleri Sistem, deneyimli bir kontrolör tarafından kolayca kullanılmalı ve kullanıcı hataları en aza indirilecek şekilde organize edilmelidir. Doğruluğu sınanabilecek şekilde yeniden yaz: Deneyimli kontrolörler sistem fonksiyonlarını 2 saatlik bir eğitim sonrasında kolaylıkla kullanabileceklerdir. Bu eğitimden sonra, deneyimli kullanıcıların ortalama hata yapma oranı günde 2 defayı geçmeyecektir. 36
İşlevsel ve işlevsel-olmayan isterlerin ilgisi Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isteri bir takım işlevsel isterlerin oluşmasına neden olabilir Kimlik denetleme özelliği: oturum yönetimi,cookie,vb Kimlik denetleme işlevi hem işlevsel hem işlevsel-olmayan istere örnektir. Her iki çeşit ister arasında net bir ayrım yoktur. 37
İster Çözümleme Aşamaları Çözümleyici (Analist): Yeteri deneyime sahip yazılım isteri çözümlemesi yapan kişi Çözümleme çalışmaları beş başlık altında incelenebilir: Problemin anlaşılması Problemin çözümlenmesi Modelleme Belirtim Gözden geçirme 38
İsterlerin Değişmesi İsterlerin çözümlenmesi ne kadar iyi yapılırsa yapılsın, süreç sırasında da isterlerde değişiklik meydana gelebilir: Müşteri ve geliştirici arasındaki iletişimin yeterli olmaması Bu aşamaya çabuk geçebilmek için bazı varsayım ya da kabullenmeler yapılmış olması Müşterinin ne istediğini tam bilememesi ve sık sık fikir değiştirmesi Geliştiricinin deneyim eksikliği Ayrıntılı tasarıma geçilince yeni isterlerin gerekliliğinin ortaya çıkması 39
İsterlerin Belirlenmesi Sistemin başarısı, sistemden ne istendiğinin doğru olarak algılanmasına bağlıdır Bunun için düzeylere ayrılmış sistem isterlerinden Yazılım İsterleri belirtimi (SRS, Software Requirements Specifications) çıkartılmalıdır. Düzey1: Uygulama alanı isterleri Düzey2:Kullanıcı isterleri Düzey3:İşlevsel isterler 40
İsterlerin Düzeyleri 41
Düzey 1: Uygulama alanı isterleri 42
Düzey 2: Kullanıcı İsterleri 43
Düzey 3: İşlevsel İsterler 44
Yapısal Çözümleme Veri akışı ve denetimi gösterilerek sistemin işlevlerinin ve davranışının modellenmesi Hem çözümlemede hem de tasarımda kullanılabilen bir yöntemdir Veri Akış Diyagramı Davranış Modellemesi Süreç etkinleştirme Tablosu Durum geçiş diyagramı Süreç belirtimi Karar tabloları Varlık İlişki diyagramı Veri Sözlüğü 45
VAD - Veri Akış Diyagramı Sistem içinde her verinin nasıl taşındığı ve bu veri akışını sağlayan fonksiyonların (işlevlerin) neler olduğu veri akış diyagramında (VAD-DFD, Data Flow Diagram)tarif edilir. Sistemin varlıkları Süreçleri Sistemdeki veri depoları Ve bunlar arasındaki verinin nasıl aktığını gösterir 46
VAD-Veri Akış Diyagramı (dvm) Bilgi bilgisayar sistemi içerisinde akarken dönüşür Sistem çeşitli formlarda girdi alır ve bu girdileri yazılım, donanım ve insan elemanları ile işleyerek çeşitli formdaki çıktılara dönüştürür. VAD verinin girişten çıkışa dek olan dönüşümü ve bilginin taşınmasını gösteren grafiksel bir tekniktir 47
VAD Simgeleri 48
VAD Kuralları 49
VAD Kuralları (dvm) 50
VAD Kuralları (dvm) 51
VAD Düzeyleri VAD bir sistemi ya da yazılımı her hangi bir soyutlama düzeyinde göstermek için kullanılabilir. VAD artan bilgi akışı ve işlevsel detayları içerecek şekilde çeşitli seviyelere bölünebilir. Seviye 0 olarak gösterilen VAD aynı zamanda kapsam diyagramı (temel sistem modeli) olarak da adlandırılır: Tüm sistem tek bir balon içerisinde gösterilerek girdi ve çıktılar gelen ve çıkan oklar ile ifade edilirler. 52
VAD Düzeyleri (dvm) Seviye 0 olan VAD daha detaylı bilgi akışı ve süreçleri içerecek şekilde ek süreçlere (balonlara) ayrılır. Seviye 1 VAD 5 ya da 6 süreç (balon) ve bunlar arasındaki akışları gösterir. Seviye 1 de gösterilen süreçler kapsam modelinde yer alan ana sistemin alt fonksiyonlarını içerir 53
VAD Örneği Seviye 0 Diyagram 54
VAD Örneği Seviye 1 Diyagram 55
VAD Örneği Süreç 2.0 için Seviye 2 Diyagram 56
Genişletilmiş Veri akışı Gerçek zamanlı sistemler için veri akış diyagramı simgeleri genişletilmiştir. Denetim süreci: Daha çok dış etkileşimden doğan denetim işaretlerini veya olayları girdi olarak alır ve bir tetiklemeye yol açan başka denetim işaretleri üretir. Sürekli veri akışı: Bir süreçten gelen veya bir sürece giden ancak süreklilik taşıyan veri akışını göstermek üzere kullanılır. 57
Genişletilmiş Veri akışı Denetim akışı: Daha çok kontrol sistemlerinde kullanılan, mantıksal (boolean) ve ayrık (discrete) bir değer taşıyan tetikleyici bir öğeyi gösterir. Denetim deposu: Denetim öğesinin bir ya da daha fazla denetim süreci tarafından kullanılabilmesini sağlayan saklama yerini gösterir. 58
VAD çizim yöntemi Süreç hikayesi gramer olarak ayrıştırılır. (tüm isim ve fiiller ayrıştırılır) Eş anlamlı olan isim ve fiiller atılır. Gramatik ayrıştırmaya dayalı olarak bir model çıkmaya başlar: Tüm fiiller sistem süreçleridir: VAD içerisinde balonlar içerisinde yer alır Tüm isimler harici varlıklar, veri öğesi ya da veri deposudur. Seviye 0 VAD çizilir Seviye 0 Seviye 1 modele detaylandırılır. Daha sonra da Seviye1 deki süreçler Seviye2 olarak detaylandırılırlar 59
Senaryo-Basit bordro sistemi 60
Senaryo-Basit bordro sistemi Seviye 0 Diyagramı 61
Senaryo-Basit bordro sistemi (dvm) Seviye 1 diyagramı 62
Senaryo-Basit bordro sistemi (dvm) Süreç 2.0 için Seviye 2 Diyagramı 63
Yapısal Çözümleme Veri akışı ve denetimi gösterilerek sistemin işlevlerinin ve davranışının modellenmesi Hem çözümlemede hem de tasarımda kullanılabilen bir yöntemdir Veri Akış Diyagramı Davranış Modellemesi Süreç etkinleştirme Tablosu Durum geçiş diyagramı Süreç belirtimi Karar tabloları Varlık İlişki diyagramı Veri Sözlüğü 64
Davranış Modellemesi Davranış modelinde sistemin durumları ve bu durumlar arasında geçişlere neden olan olaylar gösterilir. Bazı çözümleme yöntemleri veri akış diyagramı ile denetim diyagramını ayrı ayrı oluştururlar. Veri akışındaki süreç modelinde bir veri girdisi bir denetim çıkışına neden oluyorsa bir veri koşulu oluşmuş olur. Bu durum veri akışında bir denetim belirtimi halinde gösterilir. Bir davranış modeli olarak kullanılan denetim belirtimi bir süreç etkinleştirme tablosu, bir durum geçiş diyagramı ve sözde kod şeklinde bir açıklama içerir. 65
Süreç Etkinleştirme Tablosu Durum geçiş diyagramı ile beraberce oluşturulur. Durum geçişinde bir olay oluştuğu zaman akış modelindeki hangi sürecin etkinleşeceğini gösteren bir matris şeklidedir. Düşey olarak durum geçiş koşulu oluştuğunda yapılacak eylemler, yatay olarak da etkinleştirilecek süreçler bulunur. Genellikle 0 etkilenmeyecek süreci, 1 etkinleştirilecek süreci göstermek için kullanılır. 66
Süreç Etkinleştirme Tablosu 67
Durum Geçiş Diyagramı Durum geçiş diyagramı çeşitli durumları ya da çalışma kipleri bulunan her türlü sistemin çözümlemesi için kullanılabilir. Bunun yanında özellikle ani tepkileri olan gerçek zamanlı sistemlerin çözümlemesinde neyin ne zaman olacağını anlatarak hem geliştiriciye hem de belgeleri okuyan kullanıcıya yarar sağlar. Her diyagram bir başlangıç durumuyla başlar ve mutlaka bir sonlanma durumuna sahiptir. Durumlar ya da kipler kutu şeklinde, geçişler ok ile gösterilir. Her duruma mutlaka erişilmeli ve her durumdan çıkış mutlaka bulunmalıdır. Durum geçişlerine neden olan ve sistem tarafından fark edilen koşul ve bu geçiş sonrasında sistemin gerçekleştireceği eylem, geçişi gösteren okun yanındaki yatay bir çizginin alt ve üstünde belirtilir. Bir durumdan bir başka duruma olabilecek tüm geçişler aynı diyagramda gösterilir. 68
Durum Geçiş Diyagramı 69
Süreç Belirtimi Süreç belirtimi veri ve denetim akış diyagramlarının en son düzeyindeki süreçlerin iç yapılarının tanımlanmasında kullanılır. Genellikle sözde kod şeklinde bir tanımlamadır. Tamamen düz metinsel anlatımda kullanılabilir. Her iki yöntemde de belirli bir şablon oluşturulur, kısımlar tanımlanır ve bu kısımlar doldurulur (süreç adı, ön koşul, son koşul, girdi, çıktı, yapılan işlemler, kısıtlar, aykırı durumlar vs.) Her süreç için kullanılacak algoritmalar, formüller, tablo ve diyagramlar bu belirtimde yer alabilir. 70
Sözde Kod Örneği 71
Sözde Kod Örneği 72
Karar Tabloları Metinsel açıklamalar süreç belirtimleri için yeterli olmayabilir. Özellikle karmaşık kararlara göre bir takım çıktılar üretilecekse bunu düz metin olarak ifade etmek anlaşılabilirliği azaltabilir. Bu amaçla yazılımın akışına etki edecek dallanmaları daha düzenli bir şekilde göstermek için karar tablosu kullanılır. Tablodaki satırlara koşullar, sütunlara da yapılacak işlem ve kurallara ait numaralar yerleştirilir. Her koşula ilişkin kural evet-hayır, doğru-yanlış ya da koşulun yanıtı şeklinde (cinsiyet:erkek-kadın, var olanlara X işareti gibi) işaretlenir. Bazen de çeşitli sayısal değerler girilebilir. 73
Karar tablosu, sistemin mantığını adım adım yerine tablo biçiminde gösteren bir araçtır. Akış şemalarının alternatifi olabileceği gibi birlikte de kullanılabilirler. Karar tabloları 4 ana bölümden oluşur: 1. Tablonun sol üst bölümüne mümkün olan tüm şartlar yazılır. 2. Sol alt bölümde, şartların kombinasyonları sonucu yapılan tüm mümkün faaliyetler listelenir. 3. Kurallar, sağ üst bölümde oluşturulur. Şartın durumuna bağlı olarak şartın karşılığındaki olasılıkları ifade eden gösterimler kullanılır. Örneğin; Evet, Hayır ı temsil için E ve H harfleri kullanılır. 4. Sağ alt bölümde ise, verilen bir kural için geçerli olan faaliyetlerin gösterilmesini sağlayan ve onay anlamında olan X işaretleri yerleştirilir. 74
Karar Tabloları (dvm) 75
76
Varlık İlişki Diyagramı Büyük sistemlerde kullanılan verilerin belirli bir düzen içinde tanımlanması, hangi varlığın hangi varlıkla ilişkisinin olduğunun gösterilmesi gerekmektedir. Bu ilişkileri göstermek, veri deposunda varlıkları ayırt etmek için kullanılacak anahtarları tanımlamak için veri depolarında bulunan veri yapıları, varlık ilişki diyagramı (entity relationship diagram) ile gösterilir. Buradaki varlıktan kasıt veritabanı tarafındaki tablodur. 77
Varlık İlişki Diyagramı (dvm) Varlıklar ve aralarındaki ilişkiler en az ve en çok olarak bilinen aşağıdaki kurallarla tanımlanabilir: 1,1: Bir adet A varlığı yalnızca 1 adet B varlığı ile ilişkilidir. 1,n: Bir adet A varlığı 1den fazla B varlığı ile ilişkilidir. m,n: Birden fazla A varlığı birden fazla B varlığı ile ilişkilidir. 1,3: Bir adet A varlığı 3 adet B varlığı ile ilişkilidir. 78
Varlık İlişki Diyagramı (dvm) 79
80
81
Veri Sözlüğü Yapısal çözümlemenin bir parçası olarak sistemde kullanılan tüm nesneler diğer bir deyişle akışı olan veriler bir listede toplanarak veri sözlüğü (data dictionary) oluşturulur. Sözlük genellikle otomatik bir araç tarafından oluşturulur. Her bir nesne için aşağıdaki bilgiler tutulur: Bir özel ve tek isim İçerik anlatımı Nasıl ve nerede kullanılacağı Verinin sayısal, saymal(enumeration), string gibi tanımlı tipi Varsayılan değer Alt ve üst sınır değerleri 82
SORULARINIZ 83