Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

SİSTEM Sistem, bir hedef veya amacı gerçekleştirmek üzere bir arada çalışan birbiriyle ilişkili parçalardan oluşan ve girdi-çıktıları olan sınırları.

Benzer bir sunumlar


... konulu sunumlar: "SİSTEM Sistem, bir hedef veya amacı gerçekleştirmek üzere bir arada çalışan birbiriyle ilişkili parçalardan oluşan ve girdi-çıktıları olan sınırları."— Sunum transkripti:

1 SİSTEM Sistem, bir hedef veya amacı gerçekleştirmek üzere bir arada çalışan birbiriyle ilişkili parçalardan oluşan ve girdi-çıktıları olan sınırları belirlenmiş bir bütündür. Sistem tanımında üç temel kavram vardır: Bileşen, İlişki, Amaç

2 1.1.Sistemin Özellikleri Ayrıca sistemler, çıktıları kontrol etme ve ölçme değerlendirme yoluyla girdiler ve sistem üzerinde iyileştirme yapmak için geri beslemeye sahiptir.(feed-back) Girdi-----İşlem------çıktı FEED-BACK

3 1.2.Genel Sistem Teorisi Genel sistem teorisiyle sistemlerde belirlenen özellikler, bilgi sistemlerinin yapısının da anlaşılmasına olanak sağlar. Genel sistem teorisinin başlıca özellikleri; Sistemler, girdileri çıktılara dönüştürür. Sistemler disiplinler arasıdır. Bir bilim dalında bulunan ürün, kural ya da yöntem başka bir bilim dalında kullanılabilir. Sistemler hiyerarşiktir.

4 Bilgi Sistemi Tarafları
Sistem geliştirme yaşam döngüsü içinde farklı konumlardaki bireyler birarada çalışmaktadır. Bir bilgi sisteminin tarafları, Kullanıcı Yönetici Programcı Bilgi sistem destek personeli Sistem analisti

5 Bilgi Sistemi Tarafları
Kullanıcı Sistem analistleri ve tasarımcıları tarafından yapılan genel bir yanılgı ile bütün müşteriler aynı kategoriye konulmamalıdır. Her kullanıcının bilgisayar bilgisi ve deneyimi olmadığı gibi görev ve sorumlulukları sonucu kullanacakları sisteme yaklaşımları da farklı olacaktır

6 Bilgi Sistemi Tarafları
Yönetici Geliştirilen sistemin büyüklüğüne göre yöeticiyi; Proje yöneticisi Üst düzey(işletme) yöneticisi İki farklı açıdan elle almak mümkündür. Büyük ölçekli projelerde, projenin uzun süreli başarıya ulaşması için gerekli kriterlerin belirlenmesinden ve proje ekibinin idaresinden proje yöneticisi sorumludur.

7 Bilgi Sistemi Tarafları
Programcı Analist ve programcının sistem geliştirme yaşam döngüsündeki görevleri tam olarak ayrılmıştır. Zamanla yarışan ve giderek daha karmaşık yapıya sahip olan programların söz konusu olduğu günümüzde ise daha çok CASE(Computer aided software engineering) araçları kullanılarak kodun büyük bölümü otomatik olarak üretilmektedir. Ancak CASE araçlarının programcının yerini tam olarak aldığı söylenemez. Kod üreticileri sayesinde programcılar, zamanlarını optimizasyona ve üretilen kodun sisteme entegrasyonuna ayırmaktadırlar.

8 Bilgi Sistemi Tarafları
Bilgi Sistem Destek Personeli(Operasyonel Personel) Sistemin sürekliliğii sağlamak amacıyla ağ iletişiminden, donanımdan, veri güvenliğinden ve ilgili bilgisayar programlarını çalışmasından çıktıların düzenlenmesine kadar birçok konuda desteğin verilmesinden sorumludur. Sistem analisti, sistemin tarafları arasında anahtar rolü üstense de sistemin başarılı olması tek başına sistem analistine bağlı değildir.

9 Sistem Analistinin Beceri ve Görevleri
Genel olarak sistem analistinin hem işletme yönetimi hem de bilgi sistemleri konusunda bilgi sahibi olması beklenir. Böylece sistem analisti, işletmenin karşılaştığı sorunları ve karşılaştığı iş fırsatlarını fark ederek bilgi sistemindeki ihtiyaçlarını belirlenmesini ve iş akışının oluşturulacak bilgi sistemine yansımasını kolayca sağlamaktadır.

10 Sistem Analistinin Beceri ve Görevleri
Sistem analisti, çözümü ortaya koyarken müşteri ihtiyaç ve isteklerini belirlemelidir.

11 Nesne Yönelimli Programlama Giriş
Nesne Yönelimli Programlama yaklaşımı 1960’lı yılların sonuna doğru ortaya çıkmıştır. O dönemde yazılım dünyasında karşılaşılan sorunlara çözüm olması amacıyla geliştirilmiştir. Yazılımların kapsamı, içeriği ve karmaşıklığı ile birlikte boyutları da sürekli artış gösteriyordu. Bu artış ile beraber, yazılan kodu hızlı bir şekilde gelişime açık ve esnek tutmak için gereken bakım maliyeti, zaman ve çaba da artmaktaydı. Nesne Yönelimli Programlama, bu sorunlara bir çözüm olarak geliştirilmiştir.

12 Nesne Yönelimli Programlama Çözümleri
Kapsülleme(encapsulation), kalıtım(inheritance) ve çok biçimlilik(polymorphism) gibi yazılımın bakımını ve aynı yazılım projesi üzerinde ekip çalışmasını kolaylaştıran kavramları da yazılım dünyasına kazandırmıştır. Sağladığı bu avantajlardan dolayı Nesne Yönelimli Programlama, günümüzde geniş çaplı yazılım projelerinde yaygın bir biçimde tercih edilip kullanılmaktadır.

13 Nesne Tabanlı Programlama Dilleri
Nesne tabanlı programlama dilleri, nesne kullanımını desteklemelerine rağmen, kalıtım gibi nesne yönelimli programlama dillerine özgü özgü özellikleri taşımazlar. Nesne yönelimli programlama dillerine örnek olarak; ABAP/4, Simula, Smalltalk, C++, Object Pascal, Objective-C, Eiffel, Python, Java, C Sharp, Visual Basic.Net ve RealBasic’i sayabiliriz. Nesne tabanlı olup da nesne yönelimli olmayan programlama dilleri, nesne ve sınıfları desteklese de kalıtımdan yoksundur.

14 Nesne Yönelimli Programlamanın Faydaları Nelerdir?
Parçalar Halinde Programlama Nesne Yönelimli Programlamada bir problemin çözümü parçalara ayrılarak ele alınabilir. Burada her bir parçanın ayrı bir sınıf olduğu söylenebilir. Nesnelerin de sınıflar sayesinde yaratıldıklarını zaten biliyorsunuz.

15 Nesne Yönelimli Programlamanın Faydaları Nelerdir?
Gerçek Hayat Nesneleriniş Uygulamaya Taşıma ve Düzenli Kodlama Sınıflar ve nesneler, gerçek hayat problemlerini bilgisayar ortamına taşımada kolaylıklar sağlar. İstediğimiz her şeyi nesne olarak tanımlayarak üzerinde işlem yapabiliriz. Ayrıca sınıflar, kodlarımızın düzenli bir biçimde durmasını da sağlar. Bu sayede, program üzerinde yapılacak olan değişiklikler için zaman kaybı olmaz.

16 Nesne Yönelimli Programlamanın Faydaları Nelerdir?
Bir Kere Kodlayıp Defalarca Kullanma Nesne yönelimli programlamanın özelliklerinden birisi de bir defa kodladıktan sonra, aynı işlemleri tekrar kodlamamaktır. Yani çok sık kullanacağımız bir işlevi her kullanışımızda tekrar yazmak yerine o işlevi bir sınıf haline getirerek yeri geldiğinde sınıfın nesnesini çağırarak, ihtiyaç duyulan işlevi rahatlıkla kullanabiliriz. Böylelikle projede harcanacak toplam mesai de kısalmış olur.

17 Prosedürel Yaklaşıma Örnek
Fortran, Pascal ve C, prosedürel yaklaşımı esas alan programlama dillerinden bazılarıdır.

18 Prosedirel Programlama Yaklaşımında Sınırlamalar
Yazılım geliştirme mühendislerini daha iyi bir yol aramaya iten bu sınırlamaları, iki temel başlık altında ele alabiliriz. Tekrar Kullanılmama Prosedürel programlama yaklaşımında prosedürler, uygulama içersinde bir defa yazılıp istenilen yerlerde çağrılırlar. Ancak bir uygulamaya ait prosedürler, başka bir uygulama tarafından kullanılamazlar. Çünkü kod parçaları birbirlerine bağlıdır ve belirli bir seriyi takip eder.

19 Prosedirel Programlama Yaklaşımında Sınırlamalar
Kolay Değiştirilmeme Prosedürel yaklaşım kullanılarak geliştirilen büyük bir uygulama kolayca modifiye edilemez. Yazılan bütün kodlar birbirlerine sıkı sıkı bağlıdır ve bir yerde yapılan değişikliğin, uygulamanın bir çok yerine etkilerini ele almak gerekir. Oysa bir yazılım uygulamasının dinamik ihtiyaçlara cevap verebilmesi, değişiklikleri sessizce yansıtabilmesi gerekmektedir

20 Nesne Yönelimli Dillerin Evrimi
Algol-Simula-Smalltalk-C with Classes(C++)-OAK, Java

21 Nesne Yönelimli Dillerin Evrimi
Algol Algol(ALGOrithmic Language), 1950’lerin ortalarında Fortan dilindeki problemleri gidermek için dizayn edilen bir dildir. Bunun yanında Algol, Pascal gibi bazı dillerin ortaya çıkmasında rol oynamıştır. ALGOL köşeli parantezli ifade bloklarını kullanır. Ayrıca onları sınırlandırmak için BEGIN END bloklarını kullanan ilk programlama dilidir.

22 Nesne Yönelimli Dillerin Evrimi
Simula Hemen hemen bütün nesne tabanlı ve Nesne yönelimli dillerin atası 1960’larda geliştirilen Simula dilidir. Simula ALGOL fikri üzerine inşa edilmiş bir dildir; ancak kapsülleme(encapsulation) ve kalıtım(inheritance) konsetlerini eklemiştir. Belki daha da önemlisi, karmaşık sistemleri tanımlama ve simülasyon geliştirme dili olarak kullanılan Simula’nın, programlama dünyasını spesifik problem alanına özel kod yazma disiplini ile tanıştırmasıdır

23 Nesne Yönelimli Dillerin Evrimi
Smaltalk Simula, Smaltalk dilinin birincil esin kaynağıdır. Bu fikir sonraları farklı geliştirmeler ile desteklenmiştir. Smaltalk hem bir dili hem de bir uygulama geliştirme ortamını temsil eder. Saf nesne yönelimli bir dil olan Smaltalk dilinde her şey bir nesne olarak ele alınır. Smaltalk, günümüzde yaygın olmasa da kendisini takip eden bütün nesne yönelimli diller onun konseptinden etkilenmiştir. Bu yüzden önemli bir kilometre taşıdır.

24 Nesne Yönelimli Dillerin Evrimi
C with Classes(C++): Orijinal adı C with Classes olan C++ dili; Bjarne Stroustrup adlı bir akademisyen tarafından, doktora tezinde uygulama geliştirirken karşılaştığı sorunlardan yola çıkarak 1979’da geliştirilmeye başlanmış, 1985’de ilk versiyonu yayınlanmıştır. Bu yeni dilin geliştirilme aşamasında başta C ve Simula olmak üzere ALGOL 68, Ada gibi dillerden esinlenmiştir. Genellikle C dilinin daha gelişmiş hali olarak nitelendirilir.(Tip Kontrolü, Aşırı yüklenmiş fonksiyonlar, statik fonksiyonlar, abstract sınıf, protected üyeler gibi dil yenilikleri gelmiştir).

25 Nesne Yönelimli Dillerin Evrimi
OAK Doksanlı yılların hemen başında, Sun Microsystems çalışanlarından James Gosling ve küçük grubu; eğlence platformları, mikrodalga fırınlar vb. dijital olarak kontrol edilen tüketici aletleri için ileri seviye uygulamalar geliştiriliyorlardı. Bu programları C++ ile yazmak zor olduğu için 1991 yılında OAK adı verilenn bir dil oluşturdular.

26 Nesne Yönelimli Dillerin Evrimi
Java Geliştirme aşamasında OAK, genel amaçlı bir programlama dili haline geldi ve 1995 yılında adı değiştirilerek Java 1.0 sürümü ile duyuruldu. “Write Once, Run Anywhere”(Bir kez yaz, her yerde çalıştır) yani platform bağımsız uygulama geliştirmek hedefinde olan Java dilinin esas hedefi, yaygınlaşan internet erişimine ayak uydurarak web uygulamalarının kolayca geliştirileceği bir platform haline gelmekti. Java teknolojisi ile uygulama geliştirmek ve çalıştırmak için Java Virtual Machine kullanılması gereklidir ve derlenen kaynak kodlar, platform bağımsızlık hedefi için Java Byte Code adında ortak bir ara dile dönüştürülmektedir.

27

28

29

30

31 Programlamada Nesneler
Nesne, bir varlık ya da konsepti programatik olarak açıklayan soyut bir ifadedir. Nesneler, kendi özellikleri ve davranışları hakkında da bilgi bilgi barındırırlar. Nesneler, hem daha ileride kişisel kullanım için, hem de başka programcıların kullanması için hazırlanabilirler. Başka bir programcının bizim hazırladığımız nesneyi kullanarak işlem yapması durumunda, bu programcıya nesne kullanıcısı denir.

32 Programlamada Nesneler
Windows formu üzerine yerleştirilen metin kutusu(TextBox), liste kutusu(ListBox), buton(Button) vb. sayısız kontrollerin de birer nesne olduğunu biliyorsunuz. Microsoft geliştiricileri, bu kontrolleri biz uygulama geliştiricilerin kullanabilmeleri için yazmışlardır. Bir geliştirici, bu kontrollerin belli işleri yapabildiğini bilir.

33 Sınıf Programlama yaparken sınıf ve nesne kavramlarının birbirinden ayırt edilmesi gerekir. Sınıf, bir nesnenin tanımıdır;davranışlarını yansıtan karakteristiklerin ve nesnede olması gereken özelliklerin neler olduğunu belirleyen bir şablondur.

34 Sınıf

35

36

37 Alanlar, Metotlar, Erişim Belirleyicileri

38

39 Alanların Varsayılan Değerleri

40 Alanların Varsayılan Değerleri
namespace SinifKullanimi {    class Televizyon    {        public int ekran;        public string marka;        public bool lcdMi;    }    class Program        public static void Main()        {            Televizyon tv = new Televizyon();              //0 değerini almıştır.            Console.WriteLine("tv.ekran : {0}", tv.ekran);            //boş (null) değer almıştır.            Console.WriteLine("tv.marka : {0}", tv.marka);            //false değer almıştır.            Console.WriteLine("tv.lcdMi : {0}", tv.lcdMi);              }    } }

41 Varsayılan Değerler ve Lokal Değişkenler
Bir tip üyesi içersinde tanımlanan lokal değişken için ise senaryo oldukça farklıdır. Bir lokal değişken tanımlandığında, kullanılması için öncelikle ona bilinçli olarak değer ataması yapılması gerekir. Yani lokal değişkenlerde varsayılan değer ataması söz konusu değildir.

42 Varsayılan Değerler ve Lokal Değişkenler
Örneğin; Aşağıdaki kod bloğu derleme zamanı hatası ile sonuçlanır.

43 Varsayılan Değerler ve Lokal Değişkenler

44 Varsayılan Değerler ve Lokal Değişkenler
NOT: Lokal değişkenleri kullanmak için başlangıç değeri verilmesi zorunluluğunun Geçerli olmadığı tek bir istisna durum vardır: Eğer lokal değişken bir metoda Output parametresi olarak aktarılmak üzere kullanılırsa, başlangıç değer ataması Yapılmasına gerek yoktur. Çünkü zaten metot içersinde kendisine mutlaka bir Değer atanmak zorundadır.

45 Nesne Alanlarına Erişmek
Bir nesne alanına sadece kendisini içeren sınıf nesne örneği üzerinden erişilebilir. Doğrudan sınıf adına erişilmez. Bu da gösteriyor ki bir alanla çalışabilmek için öncelikle nesne örneğinin belleğe çıkarılmış olması gerekir

46 Nesne Alanlarına Erişmek
namespace SinifKullanimi {        class Program     {            public static void Main(string[] args)            {                Oyuncu o1 = new Oyuncu();                o1.adi = "Emre";                o1.takimi = "Newcastle United";                o1.formaNo = 5;                FormaDegistir(o1 , 9);                 Console.WriteLine("{0} {1}, {2}" ,                o1.formaNo , o1.adi , o1.takimi);                Console.ReadLine();            }              static void FormaDegistir(Oyuncu oyuncu, int yeniNo)                oyuncu.formaNo = yeniNo;        } }

47 Nesne Alanlarına Erişmek
Yukarıdaki kodda öncelikle bir Oyuncu nesnesi örneklenmektedir. Ardından her bir alanın değeri verilir, forma numarasının değiştirilmesi için FormaDegistir() metodu çağrılır. Son olarak o1 referansının işaret ettiği Oyuncu nesnesi ile ilişkili olan her bir alanın değeri ekranda gösterilir. Görüldüğü gibi bir alana değeri verilmeden önce Oyuncu nesnesine ihtiyaç duyulmaktadır. Dolayısıyla alanlara değer atanırken ve değerlerine erişilirken o1 değişkeni, alan isimlerinin ön eki gibi kullanılmaktadır.

48 Yapıcı Metotlar(Constructor)
C# gibi nesne yönelimli dillerin en büyük avantajlarından birisi, bir sınıf nesne örneği oluşturulduğu anda otomatik olarak çağrılan özel bir metodun tanımlanabilmesidir. Bu metoda yapıcı(constructor) adı verilir. Varsayılan yapıcı metot, nesne içerisinde belleğe çıkarılacak olan bütün alanların doğru varsayılan değerleri almasını sağlar. Peki nesne oluşturulduğu anda çağrılan yapıcı metoda isim olarak ne verilir de derleyicinin bu işi otomatik olarak yapması sağlanır. C# dilinde kullanılan yapıcı metotlar, bulundukları sınıfla aynı isimdedirler.

49 Yapıcı Metotlar(Constructor)

50 Yapıcı Metotlar(Constructor)

51 Yapıcı Metotların Parametrik Olması
Nesne kullanıcısı nesne ile çalışmaya başladığında(yani nesne örneği oluşturulmasının hemen ardından) genellikle iş sınıf içersinde tanımlanmış alanların değerlerinin verilmesidir. Oyuncu sınıfı gibi birçok sınıf ile çalışılırken, bir tane nesne için değeri gerekli bazı alanlara atama yapılmadan o nesne ile çalışmanın fazla bir anlamı olmayabilir. Bu sebeple, nesne referansı üzerinden ilgili değişkenler çağrılır ve sırayla değerleri verilir. Öyleyse, daha nesne örneği oluşturulurken bu alanların alacağı değerlerin belli olması doğru olacaktır. Bu durumda nesne, alanlarının varsayılan değerleri ile değil, çalışacak gerçek değerleri ile belleğe çıkar. Sınıflar bu iş için, varsayılan yerine kendi yapıcı metotlarımızın yazılması imkanını sunarlar. Bu şekilde, nesne kullanıcısına nesneyi oluşturma anında durum verilerine başlangıç değerlerinin verilmesi için kolay bir yol sunulmuş olur.

52 namespace YapiciMetotKullanimi
{    class Oyuncu    {    //Kendi yazdığımız yapıcı metot, nesnenin         //durum verilerine kullanıcıdan alınan         //parametre değerlerini aktarıyor        public Oyuncu(string ad, string takim,byte formaNumarasi)        {    adi = ad;            takimi = takim;            formaNo = formaNumarasi;            Console.WriteLine("Parametrik yapıcı metot çalıştı");     }         //Varsayılan yapıcı metot        public Oyuncu()        { Console.WriteLine("Varsayılan yapıcı metot çağrıldı...");        }          public string adi;       public string takimi;       public byte formaNo;          public string BilgiVer()        {   return string.Format("{0} {1} - {2}", formaNo, adi, takimi);        public void TakimDegistir(string yeniTakim)        {  takimi = yeniTakim;    } }

53 Yapıcı Metotların Parametrik Olması

54 Yapıcı Metotların Parametrik Olması
namespace YapiciMetotKullanimi {        class Program        {            public static void Main(string[] args)            {                //Varsayılan yapıcı metot                 //(constructor) çağrılır.                Oyuncu o1 = new Oyuncu();          Console.WriteLine(o1.BilgiVer() + "\n");                //Parametreli yapıcı metot                                 //çağrılır.                Oyuncu o2 = new Oyuncu("Tuncay", "Middlesbrough", 9);                Console.WriteLine(o2.BilgiVer());                Console.ReadLine();            }        } }

55 Yapıcı Metotların Parametrik Olması
namespace YapiciMetotKullanimi {    class Oyuncu    {        public string adi;        public string takimi;    public byte formaNo;        public Oyuncu(string ad)        {       adi = ad;        }        public Oyuncu(string ad, string takim)        {   adi = ad;            takimi = takim; public Oyuncu(string ad, string takim, byte formaNumarasi)            formaNo = formaNumarasi;         public string BilgiVer(){   return string.Format("{0} {1} - {2}", formaNo, adi, takimi);           public void TakimDegistir(string yeniTakim)        {  takimi = yeniTakim;    } }

56 Erişim Belirleyicileri(Access Modifiers)
Sınıf(class) ya da yapı(struct) üyelerinin(metorlar, alanlar, yapıcı metotlar vb.) erişim düzeyleri, tanımlandıklarında belirtilmek zorundadır. Eğer üye, bir erişim belirleyici anahtar kelimesi kullanılmadan tanımlanırsa, otomatik olarak private ataması yapılır.

57 6.DERS

58 Nesne Yönelimli Temel Prensipleri
Kapsülleme(Encapsulation) Kalıtım(Inheritance) Çok Biçimlilik(Polymorphism)

59 1-Kapsülleme

60 Özellik(Property Tanımlamak)
1-Kapsülleme Özellik(Property Tanımlamak) Örneğın kullanıcı klavyeden küçük harf girmesi gerekirken büyük harf girmiş ise; Bu durumda kapsülleme mantığı ile karakterlerin otomatik olarak küçülmesi sağlanır. Bir başka örnek: Girilen sayı negatif ise bu sayıyı otomatik olarak pozitife döndür şeklinde Gerçekleştirir.

61 Özellik(Property Tanımlamak)
1-Kapsülleme Özellik(Property Tanımlamak) namespace Kapsulleme {    class Kitap    {                private string _kitapAdi;        public string KitapAdi        {            get            {      return _kitapAdi;            }            set            {                  //Burada atama öncesi gerekli                   //kontroller yapılır. Herşey yolunda                   //ise atama gerçekleştirilir.                 _kitapAdi = value;        }         }

62 2-Kalıtım’a(Inheritance) Neden İhtiyaç Duyulur?

63 2-Kalıtım’a(Inheritance) Neden İhtiyaç Duyulur?
namespace Kalitim {    //Otomatik olarak System.Object sınıfından türer.    class Calisan    {    } }

64 2-Kalıtım’a(Inheritance) Neden İhtiyaç Duyulur?
namespace Kalitim {    //Her iki kullanım da doğrudur.    class Calisan : System.Object    {    }      //ya da      class Calisan : object }

65 2-Kalıtım’a(Inheritance) Neden İhtiyaç Duyulur?

66 2-Kalıtım’a(Inheritance) Neden İhtiyaç Duyulur?
namespace Kalitim {    class Calisan    {        private int _sskNo;        private string _adi;        private double _maasi;        public int SskNo        {            get { return _sskNo; }            set { _sskNo = value; }        }         public string Adi            get { return _adi; }            set { _adi = value; }        public double Maasi            get { return _maasi; }            set { _maasi = value; }    } } namespace Kalitim {    class Mudur : Calisan    {        //Bir müdür, departmanın ne kadar kar yaptığını bilmelidir.        private double _departmanKar;        public double DepartmanKar        {            get { return _departmanKar; }            set { _departmanKar = value; }        }    }         class SatisElemani : Calisan        //Bir satış elemanı ne kadar satış yaptığını bilmelidir.        private int _satisSayisi;        public int SatisSayisi            get { return _satisSayisi; }            set { _satisSayisi = value; }    } }

67 2-Kalıtım’a(Inheritance) Neden İhtiyaç Duyulur?
namespace Kalitim    {        //Bir türeyen sınıf nesnesi       oluşturulup temel sınıf üyelerine        erişilir.        class Program        {            public static void Main(string[] args)            {                //Yeni bir Mudur nesnesi oluşturulur.                Mudur cem = new Mudur();                //Calisan temel sınıfından miras alınan üyeler                cem.SskNo = ;                cem.Adi = "Cem Suskun";                cem.Maasi = 1000;                  //Mudur sınıfı tarafından tanımlanan üyeler                cem.DepartmanKar = ;                Console.ReadLine();            }        }    }

68 Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur?

69 Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur?
namespace CokBicimlilik {    class Calisan    {            public void ZamYap(double zamMiktari)        {            //Atama, doğrudan temel sınıftaki üyeye yapılır.            _maasi += zamMiktari;        }         }     }

70 Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur?
namespace CokBicimlilik {        class Program        {            public static void Main(string[] args)            {                //Her çalışana zam yapılsın. Mudur mdr = new Mudur( , "Tarık Ali", 1000, 20000);                mdr.ZamYap(250);    Console.WriteLine("mdr.Maasi : {0}", mdr.Maasi); SatisElemani sts = new SatisElemani( , "Sena Sevim", 750, 220);                sts.ZamYap(150);                Console.WriteLine("sts.Maasi : {0}", sts.Maasi);               Console.ReadLine();            }        } }

71 Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur
Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur? Temel Sınıf Davranışlarını Ezmek: Virtual ve Override namespace CokBicimlilik {    class Calisan    {        //ZamYap() metodu varsayılan olarak, bir uygulama         //mantığına sahip. Türeyen sınıflar bu uygulamayı                  //değiştirmek ve aynen kullanmak konusunda özgürler.        public virtual void ZamYap(double zamMiktari)        {            this._maasi += zamMiktari;        }        public virtual string BilgiVer()            return this.SskNo + " / " + this.Adi + " / " + this.Maasi;                //Diğer üyeler    } }

72 Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur
Çok Biçimlilik(Polymorphism) Neden İhtiyaç Duyulur? Temel Sınıf Davranışlarını Ezmek: Virtual ve Override namespace CokBicimlilik {     class SatisElemani : Calisan     {        //Diğer üyeler                 public override void ZamYap(double zamMiktari)        {            double ekstraZam = 0;            if ((SatisSayisi > 0) && (SatisSayisi < 50))            {                ekstraZam = 30;            }            this._maasi += (zamMiktari + ekstraZam);         }        public override string BilgiVer()            string temelBilgi = base.BilgiVer();            temelBilgi += " / " + this.SatisSayisi;            return temelBilgi;        }     } }

73 7.DERS

74 SİSTEM ANALİZİ Veri Akış Diyagramı Düzeyleri
Veri akış diyagramlarında belirli bir sıra izlenir. Ön inceleme sonucunda taslak veri akış diyagramları oluşturulur. Taslak veri akış diyagramı, temel alınarak birinci düzey ve ikinci düzey ayrıntılı veri akış diyagramları çizilir.

75 Taslak veri akış diyagram örneği

76 Veri Akış Diyagramı Düzeyleri
Faturalama sistemi örneğinin birinci düzey veri akış diyagramı Şekil 7.3’te görüleceği gibi dört alt sistemden oluşmaktadır. VAD’de numaralandırılan her alt sisteminin hangi kaynaklarla ve alt sistemle ilişkili olduğu genel olarak görülmektedir. Bu sistemde hastaya ait özel bilgilerin daha önce hasta dosyasına kaydedildiği kabul edilmektedir. Bu nedenle faturalama sisteminde hastadan sadece sigorta formuna ait bilgiler alınmaktadır. VAD’nın okumanın en kolay yolu soldan sağa doğru okumaktır.

77 Birinci Düzey VAD örneği

78 Veri Akış Diyagramı Düzeyleri
İkinci düzey VAD’da ise bir önceki basamakta çizilen veri akış diyagramında detaylandırılamayan alt sistemlerde gerçekleştirilen işlemler ayrıntılı olarak gösterilir. Faturalama sisteminde yer alan fatura hazırlama sisteminin ikinci düzey veri akış diyagramı Şekil 7.4’de gösterilmektedir.

79 İkinci Düzey veri akış diyagramı

80 Varlık İlişki Diyagramı
Bilgi sisteminde yer alan veri nesneleri arasındaki ilişkiler, varlık ilişki diyagramında(Entity Relationship Diagram, ERD veya ER) grafiksel olarak tarif edilir.

81 Faturalama Sistemi ER Diyagramı

82 Varlık İlişki Diyagramı Belirleyiciler
Varlık kaydını tek olarak belirleyen niteliklerdir. Bir varlığın özel bir kaydını işaret eder ve birincil anahtar alanlar olarak adlandırılırlar. Personel örneği düşünülürse bir şirkette aynı sicile sahip başka bir kişi olamaz. Chen tipi modelde anahtar alanlar altı çizilli şekilde gösterilir.

83 Varlık İlişki Diyagramı Hesaplanmış/Türetilmiş Nitelikler
Varlığın diğer nitelikleri üzerinden hesaplama veya çeşitli fonksiyonların uygulanması sonucu bulunabilen niteliklerdir. Örneğin personelin çalışma süresi işe giriş tarihinden hesaplanabilir. Bu tip nitelikler Chen modelinde kesik çizgili daire halinde gösterilir.

84 Varlık İlişki Diyagramı Eşleşen Kayıt Sayısı
İlişkili iki varlık arasında karşılıklı olarak oluşabilecek kayıt sayısıdır. Bu sayıyı belirlemek için önce bir varlık kaydı düşünülür. Sonra diğer varlıkta bu kayda karşı kaç kayıt oluşabileceği hesaplanır. Daha sonra diğer varlığa göre eşleşen kayıt sayısını bulmak için bu analiz tersten tekrarlanır. İlişkiler için eşleşme türleri bire bir(one to one), bire çok(one to many), çoğa-çok(many to many) olabilir.

85 Varlık İlişki Diyagramı Eşleşen Kayıt Sayısı Bire-bir(1:1) İlişki
Bir varlık kaydına karşılık ilişkili varlıkta yalnızca tek bir kayıt oluşabileceğini gösterir. Her çalışanın bir telefonu vardır Her telefon yalnızca bir çalışana aittir.

86 Varlık İlişki Diyagramı Eşleşen Kayıt Sayısı Bire-Çok(1:N) İlişki
Bir varlık kaydına karşılık ilişkili diğer varlıkta kayıt sayısı 1….N olabilir. Bir birim birçok personele sahip olabilir. Her personel yalnızca bir birimde çalışabilir.

87 Varlık İlişki Diyagramı Eşleşen Kayıt Sayısı Çoğa-Çok(N:N) İlişki
Bir çalışan aynı anda birden fazla projede görevlendirilebilir. Proje en az üç personele atanmalıdır.

88 DERS 8 SİSTEM TASARIMI

89 TASARIMA GEÇİŞ Analiz safhasının tamamlanmasından sonra, tasarımın başlangıç adımlarına başlanır. Bu evrede, analizde sorulan NE sorusuyla elde edilen bilgilerin, nasıl yapılacağı, nasıl gerçekleştirileceği ortaya konulur. Uygulama evresinden önceki adımdır. Yazılımı oluşturulacak her parçanın özellikleri, ayrıntıları, sınırları, kullanıcıların yetkileri gibi hususların tamamı bu evrede yapılır. Tasarım yapılmadan doğrudan uygulamaya geçiş, analizle olan bağın kopmasına neden olur ve analiz evresindeki emekler de boşa gitmiş olur.

90 SİSTEM TASARIMI Sistem tasarımı, belirlenmiş olan bir dizi gereksinimin, ana sistem içerisinde işlevsel bir öğe haline getirilmesi, başka bir deyişle yazılım şekline dönüştürülmesidir. Sistem tasarımı: Ön Tasarımı Ayrıntılı Tasarım

91

92 ÖN TASARIM Ön tasarımda, sistemin belirlenmiş olan amaç ve hedeflere nasıl ulaştırılabileceğine ilişkin tanımlar geliştirilmektedir. Bunun için; sistemin işlevleri tanımlanmakta ve modül adı verilen bağımsız öğelere ayrılmakta, veri yapıları oluşturulmakta, modül arabirimleri kurulmakta, kısıtlar belirtilmektedir. Bir rapor halinde düzenlenen ön tasarım, incelenerek kabul edilmekte ya da tekrar düzeltilmektedir

93 AYRINTILI TASARIM Ayrıntılı tasarımda, ön tasarım aşamasında oluşturulan modüller alt modüllere ayrılmakta ve ayrıntılı olarak tanımlanmaktadır. Kütükler, ekran görüntüleri ve rapor biçimleri tasarlanmakta, programlar için ayrıntılı planlar düzenlenmektedir. Böylece hazırlanan tasarım raporu incelemeye sunulmaktadır. Ayrıntılı tasarım raporu kabul edilince program planları bir bilgisayar dilinde kodlanarak dış belleklere aktarılmaktadır. Geliştirme sürecinin her aşamasında “kalite kontrol” yapılır. Son aşamada sistem testten geçirilir. Bu amaçla, sistem projesini planlanmasında bir “sistem denetleme planı” ve son aşamasında da “test planı” düzenlenmektedir. Test; önce her bir modülün, sonra da bir bütün halinde sistemin testten geçirilmesi ve onaylanması ile tanımlanmaktadır

94 TASARIMA GEÇİŞ Tasarım evresinde aşağıdaki konular ele alınır:
Ağ tasarımı ve güvenliği Yazılımın yapısal mimarisi Veritabanı tasarımı Kullanıcı arayüzü tasarımı Sistem arayüzü tasarımı Prototip tasarımı Sistem kontrollerinin tasarımı Genel olarak tasarım yukarıdan aşağıya doğru kademeli olarak yapılmalıdır. Öncelikle genel ve kavramsal seviyedeki Mimari Tasarım yapılmalıdır. Daha sonra bu mimari tasarımın üzerinde ayrıntılara girilmeli ve program ayrıntıları, kod tasarımları gibi şeyler eklenmelidir.

95 GENEL TASARIM Genel tasarım, sistemin alt yapısını belirleme ve sistem mimarisinin oluşturulmasını kapsamaktadır. Sistem analizinde oluşturulan sistem gereksinimleri girdi olarak kullanılır.

96 GENEL TASARIM Sistem Alt Yapısının Belirlenmesi
İşletmede var olan donanımın , yazılımın ve ağ yapısının belirlenip sistem çözümüne uygun alt yapının belirlenmesi. Envanter Belirleme: Sistem analisti, var olan sistemin alt yapısının durumunu görmek için; Donatım modelini üreticisini Donatım durumunu (kullanılıyor, bakıma ihtiyacı var, çalışır durumda vb.) Donatım yaşını Donatım planlanan yaşını Donatımın işletme içindeki fiziksel yerini Donatım sorumlu çalışanı veya bölümü Donatım finansal durumunu (işletmenin kendi malı, kiralık veya leasing yapılmış vb. şeklinde) belirlemelidir.

97 GENEL TASARIM Bilgisayar Donanımı ve Yazılım Alımı Adımları
Envanter listesi elde edildikten sonra önerilen sistem için gerekli olan alt yapıyla kıyaslaması yapılır. Bu bilgiyle yeni alt yapının sistem ihtiyaçlarını nasıl karşılayacağı planlanır.

98 GENEL TASARIM İş yüklerinin tahmini
Sistem analisti, ,sistemin var olan ve planlanan iş yüklerini hesaplayarak donanımın alt yapı kapasitesinin bu iş yüklerine göre yeterlilik durumunu belirler. Hesabın tam olarak yapılmasıyla işletmenin sahip olduğu donanımın her yeni sistemin kurulmasıyla gereksiz yere büyümesi ve karmaşıklaşması önlenebilir. Bir sonraki slaytdaki tabloda belirlenen işe göre var olan sistemle önerilen sistem arasında zaman ve maliyet karşılaştırılması yapılmaktadır. Tablodan da anlaşılacağı üzere bu işletmede halen elle yürütülen işin bilgisayar ortamında yapılması önerilmektedir. Var olan sistemde bu işin nasıl yapıldığı anlatılırken önerilen bilgisayar tabanlı sistemde nasıl yapılacağı belirtilip maliyet/saat, harcanan insan ve bilgisayar zamanı karşılaştırılmaktadır.

99 GENEL TASARIM İş yüklerinin tahmini

100 DONANIM DEĞERLENDİRME
Bundan önceki adımda tahmin edilen iş yüklerine ve mevcut bilgisayar envanterine göre değerlendirme yapılarak projenin ihtiyaçları belirlenir. Gerçekleştirilmesi muhtemel sistemi konfigürasyonuna göre satıcılardan alınacak bilgi bu aşamada önem kazanmaktadır. Sonuç olarak iş yüklerinin farklı sistemler üzerinde simülasyonu yapılarak karşılaştırması yapılır. Bu kıyaslama sürecinde sistem analisti ve kullanıcıların göz önünde bulundurması gereken kriterler: Sistemin toplam kapasitesi (Herhangi bir problem oluşmadan aynı zamanda kaç işlem gerçekleştirildiği) CPU’nun atıl zamanı Önerilen belleğin büyüklüğü Değerlendirme sonucunda var olan sistem donanımı, hiç değiştirilmeden yeni sistemde de kullanılacağı gibi yenilebilinir ya da küçük değişiklikler yapılarak kullanılabilir.

101 YAZILIM DEĞERLENDİRME
Günümüzde paket yazılımların sayısının giderek artması sonucu donanım seçiminde olduğu gibi yazılım seçiminde de sistem analisti satıcılarla karşı karşıya gelmektedir. Bu nedenle sistem analisti, yazılım değerlendirme kriterlerine göre yazılım alım kararını üst yönetimle beraber vermelidir.

102

103 Satın Alma Şeklini Belirleme
İşletme finansal durumuna bağlı olarak bilgisayar donanımı satın almak yerine leasing yapabilir veya kiralayabilir. Her üç yönteminde avantajları olduğu gibi dezavantajları vardır. İşletme yönetimi bu kararı verirken sadece bütçesine göre değil uzun dönem stratejilerine göre hareket etmelidir. Satın alıp almama kararındaki en belirgin etkenlerden biri de sistemin planlanan süresidir. Kiralama ve leasing maliyetleri göz önüne alındığında sistemin üç yıldan daha fazla kullanılması planlanıyorsa donanımı satın almak daha cazip olmaktadır. Ancak sistem üç yıldan daha kısa ömürlü olacaksa bu durumda leasing işletme için iki açıdan yararlı olacaktır. Bilgisayar teknolojisi çok hızlı değiştiği için satın alma durumunda işletmenin de yatırımı da o ölçüde hızlı eskiyecektir. İşletme bilgisayar donanımına yatırması gereken bütçeyi başka bir alanda değerlendirme olanağı bulacaktır.

104

105 Leasing Nedir? Leasing Türleri Nelerdir?
Leasing terimi dilimizde kiralama olarak geçmektedir. Terimi biraz daha açarsak; karşılığı kira ile ödenmek üzere, belirlenmiş bir zaman için, arazinin veya binanın belirli bir bölümünün kiralayan (lessor) tarafından, kiracıya (leasee) temlik edilmesidir. Daha genel bir tanımla leasing birinin malının bir başkası tarafından kullanılması için tasarlanmış bir sözleşmedir. Leasing faaliyeti kendi içerisinde birkaç şekilde sınıflandırılabilir. Bunlardan en çok karşılaşılanı süre açısından yapılan sınıflamadır: ·         Finansal leasing: Uzun vadeli kiralama faaliyeti olup sözleşme sonunda kiracının malı satın alma hakkı olmaktadır. ·        Operasyonel leasing: Bu leasinglerde genellikle kiralama kısa süreli olarak yapılmaktadır. Birkaç saat, birkaç gün gibi yapılan kiralamalar bu leasing türüne girmektedir. Bu leasing türünde kiracının malı satın alma hakkı bulunmamaktadır. Yukarıda bahsedilen leasinglerin yanında sat ve geri kirala, hem finansal hem operasyonel leasingi içeren kombinasyon leasingi ve sentetik leasing gibi leasing türleri de vardır. Finansal ve operasyonel leasing türleri arasındaki farklara genel olarak baktığımızda aşağıdaki unsurların ön plana çıktığını görmekteyiz:[1] ·         Kiralama sözleşmesi koşullarına göre malın mülkiyeti kiracıya geçiyorsa, ·         Sözleşme bitiminde kiracı malı gerçek değerinin altında bir bedelle alabiliyorsa, ·         Sözleşmenin süresi kiralanan varlığın ekonomik ömrünün %75’ini kapsıyorsa, ·         Kira sözleşmesi süresince kiracının ödemelerinin bugünkü değeri kiralanan varlığın değerinin %90’ını buluyorsa Bu bir finansal kiralama sözleşmesidir.

106 10.Hafta

107 Ayrıntılı Tasarım Tasarım sürecinde ilk iş, çıktıların belirlenmesidir. Böylece girdi ve saklama ortamları, veri tabanı gereksinimleri ortaya konmuş olmaktadır. Ayrıntılı tasarım kapsamında Çıktı tasarımı Girdi tasarımı Kullanıcı Arabırim Ekran tasarımı

108 Ayrıntılı Tasarım 1-Çıktı Tasarımı
Çıktı, bilgi sisteminin kullanıcılara verdiği bilgidir. Sistem analistleri, en yararlı çıktıyı elde etmek üzere kullanıcılar ile etkileşimli çalışmalar yapmaktadır. Çıktı tasarımında aşağıdaki amaçlar göz önünde bulundurulmalıdır: Belirlenen amaca hizmet verme Kullanıcı için anlamlı olma Uygun miktarda olma Çıktıların hangi kullanıcılara dağıtılacağının doğru belirlenmesi Çıktının zamanında sağlanması Doğru çıktı yönteminin seçilmesi

109 Ayrıntılı Tasarım 1-Çıktı Tasarımı
Çıktılar kullanıcıları etkileyecek şekilde olmalıdır: Bilgilerin alfabetik-kronolojik veya maliyete göre yönlendirilmesi Kabul edilebilir sınırların belirlenmesi Grafik tipi-rengi ve ölçeğinin belirlenmesi Örneğin bazı renklerin özel anlamları vardır. İşletmecilikte bütçe değerlerinin kırmızı ile gösterilmesi problem belirtir. Bir bütünün paylaşım oranlarını ortaya çıkarmak için pasta grafik tipi, birden fazla veri grubunu kıyaslamak için ise çubuk grafik tipi daha uygundur. Yönetim bilişim sistemi ve karar destek sistemlerinde, ekran çıktılarının kullanıcıyı etkileyecek biçimde yönlendirilmesi önem kazanmaktadır.

110 Ayrıntılı Tasarım 2-Girdi Tasarımı
Girilen verinin kalitesi çıktı kalitesini de belirler. Bilgi işlemde “hatalı veri girerseniz, hatalı çıktı alırsınız” kuralı geçerlidir. İyi tasarlanan girdiler, aşağıdaki amaçları sağlamalıdır. Etkinlik: Form ve ekran görüntülerinin yönetim bilgi sisteminde belli bir amacının olması Doğruluk: Sistem analizinde tanımlanan tüm işlemleri yerine getirmesi Kullanım kolaylığı: Bilgi girişi kullanıcılarının fazla zamanını almaması ve ergonomik olması Uyumluluk: Bir formda diğerine ya da ekran görüntüsüne geçişte düzenin değişmemesi Basitlik: Gereksiz ayrıntıya yer verilmemesi ve karmaşık olmaması Çekicilik: Ekran ve form yapılarının güzel görünmesi

111 İyi bir kodlamada dikkat edilmesi gereken durumlar:

112 Ayrıntılı Tasarım 3- Form Tasarımı
Form tasarımında şu hususlara dikkat etmek gerekir: 1.Formların doldurulması kolay olmalıdır. 2.Formlarda doldurulması zorunlu olmayan alanlar bulunmamalıdır. 3.Formlar göze hitap etmeli, değişiklik yaratma uğruğna, anlaşılmaz hale getirilmemelidir. 4.Formlarda amaç dışında bilgiler bulunmamalıdır. 5.Sistemde bulunan bilgiler formda bir daha istenmemelidir. 6.Cep telefonları gibi küçük cihazlar için farklı yapıda form düzenlenmesi düşünülmelidir. 7.Formda giriş yapılan bir hücre ya da kutucukta, giriş yapılacak verinin tamamının görülebilmesi için yeterli boşluk bırakılmalıdır.

113 Ayrıntılı Tasarım 3- Form Tasarımı
Form tasarlarken önce akış şemalarından yararlanarak yukarıdan aşağıya doğru tüm işlemler form üzerinde yerini alır. Daha sonra bu işlemler, mantık ve kullanım sırasına göre gruplara ayrılarak düzenlenir. Bir formda olması gereken bölümler şöyledir: 1.Baş kısım: Burada gerekirse logo, amblem gibi şeyler kullanılmalıdır. Bazı kurumlarda bu işaretler zorunlu olabilir. 2.Form Tanımı: Bu formun ne amaçla ve kimler tarafından doldurulacağının açıklanması 3.Açıklamalar: Formun nasıl doldurulacağının açıklanması, gerekirse örnek verilmesi gerekir. 4.Form Ana Kısmı: Bu kısım birden fazla bölümden oluşabilir. 5.İmza İsim: Görünür bir yerde olmalıdır. 6.Toplamlar: Eğer form değerlerden oluşuyorsa mutlaka toplam hanesi olmalıdır. 7.Yorum Bölümü: Form dolduran kişinin eklemek istediği konular olacağı düşünülerek formda mutlaka diğer, açıklama adı altında bir kısım olmalıdır.

114 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı
Kullanıcı arayüzleri bilişim sistemiyle (yazılım kodları), kullanıcı (insan) arasında iletişim sağlayan bilgisayar programıdır. Kullanıcı arayüzleri birçok kullanıcı için en önemli şeydir. Bazıları kullanıcı arayüzünü programın kendisi kabul ederler belki de haklıdırlar. Bu anlamda, sistem analistinin de kullanıcı arayüzlerine önem vermesi gerekir. Kullanıcı arayüzleri iki ayrı bölümden oluşur: 1.Sunuş: Bilgisayardan insana Tamamen kullanıcıya hitap eden üzerinde komutların, seçeneklerin olduğu, görselliği olan kısımdır. 2.İşlem: İnsandan bilgisayara Kullanıcının komutunu alıp, bilgisayarın anlayacağı şekle, kod bütününe çeviren kısımdır.

115 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı
Kullanıcı arayüzü türleri şunlardır: Komut Satırı Kullanıcı Arayüzü Soru Cevap Kullanıcı Arayüzü Menü Kullanıcı Arayüzü Form Kullanıcı Arayüzü Grafik Kullanıcı Arayüzü

116 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 1
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.1. Komut Satırı Kullanıcı Arayüzü İlk kuşak arayüz türlerindendir. Kullanıcı yapmak istediği işlem için kendisine ayrılan yere komut girerek, bir tuş yardımıyla komutu başlatır. Görselliği az olduğu için ilgi çekici değildir. Genellikle uzman kişiler tarafından, kendilerine esneklik tanındığı için tercih edilir. MSDOS, Linux, UNIX gibi işletim sistemlerinde kullanılan arayüzdür.

117 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 2
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.2. Soru Cevap Kullanıcı Arayüzü Soru cevap kullanıcı arayüzünde bilgisayar, kullanıcıya yanıtlaması için ekran üzerinde bir soru sorar. Kullanıcı klavyeyi kullanarak bu soruya, bazen seçenekleri tercih ederek, yanıt verir. Bilgisayar verilen yanıta göre, bir sonraki adıma geçer. Bu tür programlar, karar ağacı şeklinde programlanmışlardır. Verilen yanıta göre, ağaç üzerinde uygun dala gidilerek izleğin en sonunda yaprak denilen sonuca ulaşılır. Deneyimsiz kullanıcılar için oldukça iyi olan bu arayüz tipi deneyimli kullanıcılar için sıkıcı olabilir. Daha çok, sorun çözme, modem ayarları gibi konularda tercih edilir.

118 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 2
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.2. Soru Cevap Kullanıcı Arayüzü Aşağıdaki yeni donanım bulma sihirbazı menüsünde uygun seçenek seçilip, NEXT tıklandığında diğer arayüz , daha sonra da her şey yolunda giderse

119 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 2
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.2. Soru Cevap Kullanıcı Arayüzü

120 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 3
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.3. Menü Kullanıcı Arayüzü Menü kullanıcı arayüz, standart bilgisayar kullanıcısının sıklıkla karşılaştığı bir arayüzdür. Ekranda bir form üzerinde ya da web sayfasında kullanıcıya çeşitli menüler sunulur. Bu menüler genellikle üstte olabileceği gibi iki yanda ve ya ekranın alt tarafında da olabilir. İç içe geçmiş menülerle yerden kazanıldığı gibi, birbirleriyle ilgili olan komutlar da bir araya toplanmış olur. Bir ekran üzerinde, ön tarafta kalan menü maddeleri 9’u geçmemelidir. Standart bir programda bu 7 ile 9 arasında olmalıdır. Aynı zamanda, 3 TIK kuralı ihlal edilmemelidir. Bir programın, özellikle bir web sitesinin herhangi bir yerine kullanıcının en fazla 3 TIKla gidebilmesi gereği 3 TIK kuralı olarak adlandırılır.

121 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 3
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.3. Menü Kullanıcı Arayüzü Aşağıda Excel programının menüsünde görüldüğü gibi File, Edit, View, Insert, Format, Tools, Data, Windows ve Help olmak üzere toplam 9 ayrı menü maddesi vardır:

122 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 4
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.4. Form Kullanıcı Arayüzü Form Arayüzleri, daha çok internet web sayfalarında, üyelik, kayıt, satış gibi işlemler için karşımıza çıkan arayüzlerdir. Bu arayüzlerde, mümkün olduğunca kullanıcıya az işlem yaptırmak gerekmektedir. Örneğin, doğum yeri girilecekse Manisa sözcüğünü klavyeden girmek yerine, liste kontrolünden kullanıcının seçmesi istenmelidir. Aksi durumda çok farklı il isimleriyle karşılaşabilirsiniz. Bu arada yurt dışı doğumlu, oturma izni olup da vatandaş olmayanlar gibi sıra dışı durumlar için DİĞER seçeneği de listede yer almalıdır.

123 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 4
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.4. Form Kullanıcı Arayüzü

124 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 5
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.5. Grafik Kullanıcı Arayüzü Grafik Kullanıcı Arayüzünde ana menü her zaman ekranda olur. Ana menü üzerindeki, menü maddeleri veya düğmeler tıklandığında ayrı bir form ekrana gelir. Ekrana gelen her form diğerinden bağımsızdır. Dolayısıyla, kullanıcı eş zamanlı olarak birkaç form üzerinde çalışabilir. Bu nedenle, bir form açıldığında diğerinin otomatik olarak kapanmaması gerekir. Ancak kullanıcının kullanmadığı halde gereksiz yere sürekli açık form tutması programın işleyiş performansını hatta programın türüne göre bilgisayarın genel performansını düşürebileceği gibi, bazı istenmeyen ve ön görülemeyen hatalara da neden olabilir. Bu nedenle, sistem analisti tasarım aşamasında, hangi formların eş zamanlı olarak kullanılacağını belirleyip, yazılım ekibine vereceği tanımlamalarda bu durumu bildirmelidir. Bu tür, arayüzlerde kullanılması gerekmeyen kontroller, pasifi gri renkte ama görünür olabilir. Kullanılabilir hale geldiğinde kontroller tekrar aktif hale otomatik olarak dönüşür ve rengi koyulaşır.

125 Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3. 5
Ayrıntılı Tasarım 3- Kullanıcı Arabirim Tasarımı 3.5. Grafik Kullanıcı Arayüzü Daha çok FTP, Anti virüs yazılımları gibi programlarda kullanılan bu arayüz türüne örnek, aşağıda verilmiştir.

126 Ayrıntılı Tasarım 4- Ekran Tasarımı
Kağıt üzerinde hazırlanan formlar sonuçta bilgisayar sistemlerinde karşımıza ekran görüntüsü olarak çıkacaktır. Formlarda olduğu gibi ekran görüntüleri de yalın ve basit olmalıdır. Ekran boyutlarının küçük olacağı düşünülerek, ekran çok kalabalık tutulmalıdır. Bir ekrandan diğerine geçiş kolay ve anlaşılır olmalı, geriye dönüşler mümkün olmalıdır. Ekrana girilecek değerlerin kontrolü mümkünse girilirken yapılmalı, diğer ekran görüntüsüne geçerken ortaya çıkan hatalardan ötürü, girilmiş değerler kaybolmamalıdır. Ortalama bir kullanıcı için ekranın en fazla %40!ı gerekli bilgilerle doldurulmalıdır. Sağ tuş özelliği kullanılarak menüler hakkında bilgi verilmelidir. Mutlaka büyütme küçültme düğmeleri olmalıdır. Özellikle web tabanlı programlarda, 3 TIK özelliği unutulmamalıdır. Yatay ve dikey kaydırma çubukları kullanılabilir ancak, temel tek bir ekran görüntüsü içinde her şeyi verebilmektedir.

127 Sistem Çözümleme ve Sonlandırma
Analiz evresinin sonunda elde edilen bilgiler bir araya toplanarak, belirli format ve düzen içinde çeşitli rapor, dosya, şema ya da tablo haline dönüştürülür. Tasarım aşamasına geçilmeden önce, yapılması gereken bu son işlemler : 1. Olay Tablolarının 2. Durum Formlarının 3. İşlevsel analiz Raporların 4. İş Akış Şemalarının

128 Sistem Çözümleme ve Sonlandırma 1-Olay Tabloları
Sistem analistleri, çözümledikleri sistemi ortaya koymak için veri akış şemaları dışında olay tabloları da kullanırlar. Olay tabloları, kurum işleyişi doğrultusunda herhangi bir işlemin nasıl yürütüldüğünü ayrıntılarıyla anlatan tablolara verilen isimdir. Olay tablolarında, her bir işlem tek tek ele alınarak, bu işlemi kimin başlattığı, ne işlem yapıldığı belirtilir. Sonuçta işlemi başlatan ve hangi noktaya veya kişiye, nasıl bir bilgi ya da verinin gönderileceği gibi şeyler yazılır. Olay tabloları hem manüel hem de otomatik olarak yapılan tüm işlemleri içerir.

129 Sistem Çözümleme ve Sonlandırma 1-Olay Tabloları
İlk sütunda verilen olay yapılacak işlemin kendisidir. İstemci/kullanıcı ise bu olayı başlatan, işlemesini isteyen kişi ya da başka bir işlemdir. Örneğin, üye kayıt olayı müşteri tarafından istenirken, parola üretimi Üye Kayıt Olayı tarafından istenmektedir. Tetikleyici ise işlemin dönmesi için gerekli olan parametreler veya değişkenlerdir. İşlem sütununda, bu işlemin ne yapacağı ayrıntılı olarak yazılır. İşlem sonlandıktan sonra kullanıcıya nasıl bir ekran görüntüsü veya kullanıcının nereye yönleneceği ise yanıt sütununda belirtilir. Bu kullanıcının kim olduğu ise hedef sütununa yazılır.

130 Sistem Çözümleme ve Sonlandırma 2-Olay Tabloları
Bir başka çözümleme tekniği ise durum formları kullanmaktır. Durum formlarıyla yapılan çalışma, aslında olay tablolarıyla aynı amaca yönelik hazırlanan başka formatta bir analizdir. Sistem analizi ekibine uyacak, anlaşılır herhangi düzende bir durum formu kullanılabilir. Durum formları tasarımcıya yazdığımız sistemi açıklama raporlarıdır. Gerektiğinde kullanıcıyla birlikte gözden geçirilerek, eksik ve hatalar önlenmiş olur, aynı zamanda, bazen o ana kadar hiç açılmamış konularda kullanıcıdan bilgi edinilebilir. Tasarımcıysa, bu belgeleri kullanarak arayüz program gibi modüller tasarlayabilir.

131 Sistem Çözümleme ve Sonlandırma 2-Olay Tabloları

132 Sistem Çözümleme ve Sonlandırma 3-İşlevsel Analiz Raporları
İşlevsel analiz raporları, çeşitli tekniklerle elde ettiğimiz bilgiler ışığında, tasarım ekibine yönlendireceğimiz, ayrıntılı analiz raporlarıdır. Bu raporlarda, kullanıcıların ve işletmenin isteği doğrultusunda, sistemin nasıl işleyeceği, gerekli fonksiyonlar ve çözümleri, varsa matematiksel hesaplamalar ve bunlarla ilgili algoritmalar yer alır. Ayrıca, herhangi bir sarf malzemesi ya da ek donanım gereksinimi, dönüştürme ve mevcut sistemlere etkisi de yine bu raporlarda değerlendirilebilir.

133 Sistem Çözümleme ve Sonlandırma 3-İşlevsel Analiz Raporları
Durum formları gibi, İşlevsel Analiz Raporları da sadece baştan aşağıya yeni bir sistemin kurulmasında değil, aynı zamanda mevcut bilişim sisteminde yapılacak ek, iyileştirme ve yenileme işlemlerinde de kullanılır. Örneğin, bir hastanede kullanımda olan bir bilişim sistemi olsun; ilerleyen zaman içinde, değişik ihtiyaçlarla, örneğin görüntülü 3G üzerinden muayene uygulaması başlatılmak istenirse, mevcut bilişim sistemine ek olarak, Web üzerinden muayene isteği, Web formu, hekim arayüzü gibi tüm işlemleri ayrıntılı bir şekilde özetleyen işlevsel analiz raporları hazırlamak gerekecektir.

134 Sistem Çözümleme ve Sonlandırma 3-İşlevsel Analiz Raporları
Bu raporlarda bir tablo halinde aşağıdaki hususlar bildirilmelidir:  Projenin;

135 Sistem Çözümleme ve Sonlandırma 3-Örnek İşlevsel Analiz Raporu
Aşağıdaki işlevsel analiz raporu, bir bankanın kredi kampanyası için kredi başvuru ve onay sürecinin otomasyona eklenmesi amacıyla hazırlanmıştır. Analiz raporu aşağıdaki gibi bir künye sayfasıyla başlamalıdır.

136 Sistem Çözümleme ve Sonlandırma 3-Örnek İşlevsel Analiz Raporu
Daha sonra sürümlere göre yapılan değişiklikleri belirten aşağıdaki gibi bir tablo sunulmalıdır. Bu tabloda söz konusu işlem için o ana kadar yapılmış değişikliklerin tamamı ve tasarım ekibiyle paylaşılacak olan işlemler listelenmelidir. Daha sonraki kısımda yapılması gerekenler ayrıntılı olarak maddeler halinde anlatılmalıdır.

137 Sistem Çözümleme ve Sonlandırma Arayüz ve Sistem Açıklamaları

138 Sistem Çözümleme ve Sonlandırma İşlevsel Analiz Formu Arayüz Örneği
Arayüz ve sistem açıklamaları dışında arayüzler de rapora konulmalıdır.

139 Sistem Çözümleme ve Sonlandırma İşlevsel Analiz Formu Arayüz Örneği
Bu arayüz örneklerine tasarım ekibinin ne kadar bağlı kalacağı, ne kadarının olduğu gibi kalacağı, ne kadarını değiştirerek kullanacağı, sistem analiz ve tasarımı ekibinin çalışma ilkelerine bağlıdır. Bu arayüzler, elle, kağıt üzerine taslak olarak çizilebileceği gibi Visible Analist, Visio gibi programlarla, hatta doğrudan .NET platformu gibi ortamlarda dahi çizilebilir.

140 Sistem Çözümleme ve Sonlandırma 4. İş Akış Şemaları
İş akış şemaları, veri akış şemalarıyla birlikte veya ayrı olarak kullanılır. Bu şemalar, kurum içinde elde edilen bilgilere dayanarak kurumdaki tüm işlemlerin nasıl yapıldığını, kimlerin dahil olduğunu gösteren, tüm iş süreçlerini şematik gösteren çizimlerdir. Bu çizimler daha sonra, tasarımcı ve programcılar için önce kaba koda daha sonra da gerçek kodlara dönüşeceği unutulmamalıdır. Yazılımcılar, çoğu zaman iyi bir program akış şeması hazırlamakla zamanlarını geçirir ve çoğunlukla da zorlanırlar. Bunun nedeni, yazılımcı, programcı ya da sistem analist, genelde önündeki yazılıma odaklanır. Sanki, yazılım iş yerinin süreçlerinden bağımsızmış gibi bireysel hareket ederler ve bu da işlerini zorlaştırır.

141 Sistem Çözümleme ve Sonlandırma 4. İş Akış Şemaları
Oysa, günümüzde iyi yazılımcı, yazılım öncesi aşamaları ve proje sırasında birden fazla kişiyle aynı projeyi çalışabilen ve bir yandan sistem çözümlemesi yaparken bir yandan da belgelendirmeyi sağlayabilen yazılımcıdır. İyi yazılımcı ya da sistem analist ve tasarımcıları tasarım öncesi süreçleri iyi yöneten ve evreler arasında eş güdümü sağlayan kişilerdir. Sistemin kurulacağı kurumda daha önceden ISO 9000 Kalite Standartları çerçevesinde veya başka bir nedenle hazırlanmış iş şemaları olabilir. Sistem analizi ekibi, bu iş şemalarını doğruluk ve geçerliliğini kontrol etmek şartıyla kullanabilir. Bu gibi, daha önce kurum tarafından hazırlanmış belgeler sistem analistlerinin işini kolaylaştıracaktır.

142 SİSTEM ANALİZ VE TASARIMI 11.Hafta
Öğr. Gör. Sezer YILDIZ Beykoz Lojistik Meslek Yüksekokulu Bilgisayar Teknolojileri

143 Konular Nesneye Yönelik Programlama Sınıflar Arası İlişkiler
Konu ile ilgili ödev Nesneye Yönelik Sistem Analizi

144 Nesneye Yönelik Programlama
Nesneye yönelik programlamada yazılımlar birbirleriyle iletişim kurabilen nesneler topluluğu olarak tasarlanır ve gerçekleştirilirler. Kod işletimi nesnelerin içinde yapılır ve her nesne bir diğer nesneye ileti göndererek ondan hizmet alabilir. Bu nedenle nesneye yönelik programlama “nesnelere ileti gönderme yoluyla programlama” olarak da isimlendirilir. Nesneler metodlar (methods) ve nitelikler’den (attributes) oluşur. Nitelikler, nesnelerin sahip oldukları verilere, metodlar ise bunlar üzerinde yapılabilecek işlemlere karşılık gelir. Bir başka deyişle nesne, kendisini işleyecek kod kesimini kendisi ile birlikte tanımlayan ve taşıyan ve kendi tanımladığı biçimden daha farklı amaçlarla kullanılamayan veri türü olarak yorumlanabilir.

145 Sınıflar Arası İlişkiler
Sınıf diyagramları kendi başlarına bir şey ifade etmez ancak aralarındaki ilişkilerle birlikte incelendiklerinde anlamlıdır. Unified Modelling Language (Bütünleşik Modelleme Dili) Nesneye yönelik sistemlerin analiz ve tasarımında standart olarak kullanılan modelleme dili UML’dir. UML içerisinde sınıflar arasında 5 farklı ilişki tanımlanabilir; Bağlantı İlişkisi (Association) Genelleme/Kalıtım İlişkisi (Generalization/Inheritance) Bağımlılık(Dependency) -İçerim(Aggregation),Oluşum(Composition) Abstract – İnterface İlişkisi Sarmalama(Encapsulation)

146 Sınıflar Arası İlişkiler
1. Bağlantı İlişkisi (Association Class) Bağıntı ilişkisi, sınıf diyagramlarında en çok kullanılan ve en basit ilişki türüdür. Çoğu zaman referans tutma biçimindedir. İki nesne arasında var olan bağıntının çokluları (n:m), ilişki bağıntı sınıfı ile ifade edilebilir. Bağıntı ilişkisi iki nesne arasına çizilen düz çizgi ile belirtilir.  Bağıntı  ilişkileri için tanımlanmış bilgiler aşağıdaki gibidir; Bağıntının Adı Sınıfın bağıntıdaki rolü Bağıntının çokluğu Bağıntı adı, iki sınıf arasındaki ilişkinin küçük bir açıklamasıdır. Bu açıklama ile birlikte yön bilgisi de belirtilebilir. 

147 Sınıflar Arası İlişkiler
Şekil1. Bağıntı ilişkisinde bağıntı adı ve yönü

148 Sınıflar Arası İlişkiler
Sınıf diyagramlarında sınıflar arasında bire n ilişki kurulabilir. Bir sınıf, n tane başka bir sınıf ile ilişkiliyse buna bire-çok (1-n) ilişki denir. Şekil 2. Bağıntı ilişkisinde çokluk gösterimi Şekil2’de işçi-işveren ilişkisinde bir şirketin en az bir işçisi olduğu (1..*), bir işçinin ise 0 ya da herhangi bir sayıda(*) şirkette işçi olarak çalışmış olabileceği ifade edilmektedir. İki sınıf arasında yalnızca tek bir bağıntı çizilmesi gibi bir kısıt yoktur. En temel bağıntı ilişki tipleri aşağıdaki gibi listelenebilir;

149 Sınıflar Arası İlişkiler
En temel bağıntı ilişki tipleri aşağıdaki gibi listelenebilir; Bire-bir Bire-çok Bire-bir veya daha fazla Bire-sıfır veya bir Bire-sınırlı aralık (mesela:bire-[0,20] aralığı) Bire-n (UML de birden çok ifadesini kullanmak için '*' simgesi kullanılır.) Bire-Beş yada Bire-sekiz

150 Sınıflar Arası İlişkiler
Diğer bir ilişki türü ise bir sınıfın kendisiyle kurduğu ilişkidir.Bu tür ilişkiler genellikle bir sınıfın sistemde birden fazla rolü varsa ortaya çıkar.Bu tür ilişkilere "reflexive associations" denir. Bu tür bir ilişki UML ile aşağıdaki gibi gösterilir.  Şekil 3. Reflexive ilişki örneği Şekil3’i inceleyecek olursak , patron bir eleman olmasına rağmen kendisi gibi eleman olan birden çok çalışandan sorumludur diyebiliriz.

151 Sınıflar Arası İlişkiler
2. Sınıflar Arasında Türetme (Inheritance) ve Genelleme (Generalization) İlişkisi Nesne tabanlı programlama tekniğinin en önemli parçası türetme (inheritance) dir. Türetme yoluyla bir sınıf başka bir sınıfın var olan özelliklerini alarak, o sınıf türünden başka bir nesneymiş gibi kullanılabilir. Bir sınıfın işlevleri türetme yoluyla genişletilecekse, türetmenin yapılacağı sınıfa taban sınıf (base class), türetilmiş olan sınıfa da türemiş sınıf (derived class) denir. Şekilsel olarak türemiş sınıftan taban sınıfa bir ok olarak belirtilir.

152 Sınıflar Arası İlişkiler
Şekil 4. UML’de türetme örneği UML 'de türetme Şekil 4’da gösterilmiştir. Türetme ağacında daire ve kare birer şekildir. Sınıflar arasındaki türetme işlemi ucu açık üçgen ve düz bir çizgiyle gösterilir. Bu durumda "Şekil" sınıfı ana sınıf (parent class), daire ve kare ise yavru (sub class) sınıflardır. Türetmeye sınıflar arası ilişki açısından baktığımızda türetmenin "is kind of" (bir çeşit) ilişkisinin olduğu görülür.

153 Sınıflar Arası İlişkiler
Nesneler arasında ortak özellikler varsa bunu her sınıfta belirtmenin yerine ortak özellikleri bir sınıfta toplayıp diğer sınıfları ondan türetip yeni özellikler ekleyerek organizasyonu daha etkin hale getirebiliriz. Tabi istersek ortak özelliklerin toplandığı sınıf ile gerçek nesneler oluşturmayı engelleyebiliriz. Bu tür sınıflara "abstract class" denir. Bir sınıfın "Abstract" olması için Sınıf ismini italik yazmamız gerekmektedir.

154 Sınıflar Arası İlişkiler
3. Bağımlılık İlişkisi(Dependency) Bir sınıfın nesnesinin diğer bir sınıfın nesnesini kullanması ya da ona bağımlı olması söz konusudur. Bağımlı sınıftan bağımsız sınıfa doğru kesik kesik olan düz bir çizgiyle gösterilir. Örnekteki RaporOluştur sınıfı rapor sınıfını kullanmak, yani Rapor sınıfına bağlı olmaktadır.Rapor sınıfında yapılacak herhangi bir değişiklik, RaporOluştur sınıfında değişiklik yapılmasına neden olacaktır.

155 Sınıflar Arası İlişkiler
3.1. Kümeleme-İçerme (Aggregations) Bağıntı İlişkisi Birden fazla parçadan oluşan sınıflar arasındaki ilişkiye "Aggregation" denir. Aggregation ilişkisini 'bütün parça' bir sonraki slaytta olacak şekilde ve 'bütün parça'nın ucuna içi boş elmas yerleştirecek şekilde gösteririz. İçi boş elmas ile gösterilen ilişkilerde herbir parça ayrı bir sınıftır ve tek başlarına anlam ifade ederler.

156 Sınıflar Arası İlişkiler
Şekil 5. İçerim ilişki örneği İki sınıf arasındaki “sahiptir” veya içerir türünden bağıntıları modellemekte kullanılır.

157 Sınıflar Arası İlişkiler
3.2. Birleştirme-Oluşum (Composition) Bağıntı İlişkisi Parça bütün arasında çok güçlü bir ilişki yoktur. Ama bazı durumlarda bütün nesneyi yarattığımızda parçalarının da yaratılmasını isteriz. Bu tür ilişkilerin gösterilmesine ise "COMPOSITE ASSOCATION" denir. Bu ilişki diğerine göre daha güçlüdür. Bu tür ilişkilerde bütün nesne yaratıldığında parçalar da anında yaratılır. Bazı durumlarda, takılacak parçalar duruma göre değişebilir. Bu durumda takılacak parçalar "constraint(koşul)" ile belirtilir.

158 Sınıflar Arası İlişkiler
Şekil 6. Oluşum ilişki örneği

159 Sınıflar Arası İlişkiler
Oluşum ilişkisinde parçanın yaşam süresi doğrudan bütünün yaşam süresine bağlıdır. Bütün nesnesi yaratılmadan parça nesnesi yaratılamaz ve bütün tarafındaki nesne silindiğinde parça nesnelerde onunla birlikte silinmelidir.

160 Sınıflar Arası İlişkiler
Yukarıdaki bağıntıda aşağıdaki ilişkiler yer almaktadır; Her okulun sıfır ya da daha fazla öğrencisi yer almaktadır. Her okulda bir ya da daha fazla bölüm vardır. Her bölüm tek bir okula bağlıdır. Her bölüm bir ya da daha fazla sayıda ders açmaktadır. Her bölüm bir ya da daha fazla öğretim üyesine sahiptir. Her bölümün öğretim üyelerinden seçilmiş bir başkanı vardır. Her öğretim üyesi bir ya da daha fazla bir bölümde görev yapmaktadır.

161 Sınıflar Arası İlişkiler
Her öğretim üyesi sıfır ya da daha fazla sayıda ders vermektedir. Her ders bir ya da daha çok bölüm tarafından açılır. Her dersi sıfır ya da daha fazla sayıda öğrenci almaktadır. Her derse en az bir tane öğretim üyesi atanmıştır. Her öğrenci bir ya da daha fazla sayıda okula kayıtlıdır. Her öğrenci sıfır ya da daha fazla sayıda ders alabilir. Her öğretim üyesi ya tekbir bölümün başkanıdır ya da hiçbir bölümün başkanı değildir.

162 Sınıflar Arası İlişkiler
Kümeleme-İçerme (Aggregations) ile Birleştirme- Oluşum(Composition) Kavramları İle İlgili Örnek Bir Olay: Örneğin bir şirketin çeşitli birimleri olabilir. Örneğin muhasebe, satın alma, yönetim gibi birimler şirkete bağlıdır ve yalnızca bir şirkete bağlı olabilirler. Ayrıca bu birimlerde çalışan kişiler de bulunur. Dolayısıyla birimler ile kişiler arasında da bir ilişki vardır. Şayet şirket kapanacak olursa, birimler anlamını yitirir ve artık bu birimlerin varlığından söz edilemez. Ancak bu birimlerde eskiden çalışan kişiler varlığına devam eder, ayrıca bu kişiler şirket varken de birden fazla birimde veya şirkette de çalışabilmektedir. Bu örnekte şirket ve bağlı birimlerini bir oluşum(composition) şeklinde düşünmek gerekir. Buna mukabil birimleri bağlı kişiler ile birimler arasında da bir Kümeleme-İçerme (Aggregations) bulunmaktadır.

163 3. Abstract-İnterface Uml Açıklaması
Sınıflar Arası İlişkiler 3. Abstract-İnterface Uml Açıklaması

164 Abstract-İnterface Sınıflar Arasındaki Farklar
Interfaceler çoklu kalıtımı sağlamaya yardımcı abstract classlar ise çoklu kalıtımı desteklemez. Interfacelerde metodların içerisini dolduramayız ama abstract classlarda doldurabiliriz Böylece bütün alt sınıfların belli bir özelliğe sahip olmasını sağlayabiliriz. Interface ile yapabildiğimiz herşeyi hatta daha fazlasını abstract classlar ile de yapabiliriz. Eğer türeteceğimiz classlarda belli başlı varsayılan özellikleri tekrar tekrar kopyala-yapıştır yapmak istemiyorsak o zaman abstract class kullanmamız gerekir. Çünkü abstract classlarla bir metodu tüm alt classlarda varsayılan metod şeklinde tanımlayabiliriz ve alt classlarda bunları tekrar yazmamıza gerek kalmaz kalıtımla aktarılmış olur. Kalıtım sağlamak istiyorsak abstract classlar kullanmamız gerekir. Abstract classları kullanmak hız açısından avantaj sağlar. Interface de yeni bir metod yazdığımız zaman bu interfaceden implement ettiğimiz tüm classlarda bu metodun içini tek tek doldurmak gerekiyor ancak abstract classlarda durum farklıdır burada bir metod tanımlayıp içini doldurduğumuzda abstract sınıfımızdan türetilmiş bütün sınıflar bu özelliği kazanmış olur.

165 4. Sarmalama(Encapsulation)
Sınıflar Arası İlişkiler 4. Sarmalama(Encapsulation) Verilerin ve kodların dış etkenlerden korumaktır. Özellikleri: * Bir nesnenin dış dünyadan soyutlanıp iç dünyasında işlem yapması * Başka kod ve sınıflar tarafından kulanılmaması için koruyucu bariyer görevi görür. *Kodları erişilmez hale getirir. *Nesne tabanlı programlamanın temel ilkelerinden birisidir. Not : Class içinde bir değişkene ulaşılmaması için private olarak tanımlamalısınız. Encapsulation programcıya nesneleri koruma gücünü verir.

166 4. Sarmalama(Encapsulation)
Sınıflar Arası İlişkiler 4. Sarmalama(Encapsulation) - Sınıflarımızda dışarıdan bilinmesi gerekmeyen özellikleri ve metodları gizlemek için private deyimini kullanıyoruz. - Private özellikler sadece sınıfın içinden görülebilen, değiştirilebilen özelliklerdir.

167 Nesneye Yönelik Sistem Analizi
Yazılım geliştirme yaşam döngüsü açısından nesneye yönelik sistem analizi, geleneksel yapısal yaklaşım ile aynı aşamalara sahiptir. Planlama,analiz, tasarım, gerçekleştirme ve aşamalarda gerçekleştirilen aktivitelerde aynıdır.Her iki yaklaşım, geliştirme aşamalarında modelleme üstünde dursalar da, değişik açılardan ele alırlar. Örneğin sistem analisti, veri akış diyagramları yerine, etkileşim diyagramları kullanır. İki yaklaşım arasındaki temel fark, sistem aktivitelerini göstermek için kullanılan diyagramların farklılığı ve çeşitliliğidir.

168 Nesneye Yönelik Sistem Analizi
Nesneye yönelik yaklaşımda uygulamanın gereksinimlerini tanımlamak için birbiriyle ilişkili ancak bağımsız iki diyagramdan yararlanılır. Gereksinimlerin tam bir tanımını yapmak için bu iki diyagram bir arada kullanılır. Diyagramlar genellikle paralel hazırlanırlar.

169 Nesneye Yönelik Sistem Analizi
Sınıf diyagramı, bir sistemdeki tüm nesnelerin sınıf tanımlarını ve ilişkilerini göstermek için kullanılır. Aynı zamanda her sınıfın özellikleri ve işlemleri de bu diyagramda belirtilir. Kullanım senaryosu diyagramlar ise, yeni sistemdeki kullanımların, senaryoların belirlenmesi için kullanılır. Genel olarak, sistemin nasıl kullanılacağını modeller. Not:Yazılım nesneleri gibi tasarıma yönelik detaylarla bu aşamada ilgilenilmez.

170 Nesneye Yönelik Sistem Analizi
1.Kullanım Senaryosu Modellenmesi(Use-Case Modeling) Bir sistemin davranışı, dış olaylara verdiği tepkilerdir. Senaryolar, anlamlı bir sonuca ulaşmak için aktör ile sistem arasında gerçekleşen olaylardır. Aktör ise bir senaryoyla etkileşime geçen kimse kısaca sistemin kullanıcısıdır. Aktör, senaryodan kullanabileceği bir sonuç bekler. Sadece bir diyagram değil, tüm sistemin beklenen davranışını açıklayan bir modeldir.

171 Nesneye Yönelik Sistem Analizi
1.1. Aktörler Aktörler UML’de kullanım senaryosu diyagramları çizilirken çöp adamlarla ifade edillir. Ancak, aktör özelliklere ve işlemlere de sahip olabileceğinden, normal bir sınıf şeklinde de gösterilebilir.

172 Nesneye Yönelik Sistem Analizi
1.1. Aktörler Nesneye yönelik sistem analizi ve diyagramları örneklemek için, bir alışveriş sitesi örneği verilmiştir. Sistemin genel yapısı, aşağıda özetlenmiştir. Site, kahve satışı yapmaktadır. Hazır kahveler satın alınabileceği gibi, müşteri dilediği çeşitleri harmanlayarak özel kahve siparişi de verebilmektedir Bir alışverişte birden fazla çeşit kahve siparişi verilebilir.

173 Nesneye Yönelik Sistem Analizi
1.1. Aktörler Siparişi tamamlamak için, müşteri teslimat ve ödeme formları doldurulur. Kredi kartı ve banka havalesi ile ödeme yapılabilir. Arka planda, müşterinin bilgileri ve ödemesi doğrulanır. İstenen özelliklerdeki sipariş, kahve sağlanan depodan alınır, fatura basılır ve müşteriye gönderilir.

174 Nesneye Yönelik Sistem Analizi
1.1. Aktörler Tasarlanacak olan sistemin sınırları dahilinde nelerin olup olmayacağı, belirlenecek aktör ve senaryoları değiştirir. Sistemin genel akışına adım adım bakalım; Müşteri, hazır bir kahve seçer. Özellikleri ile fiyatı da gösterilir. Müşteri, istediği kahveleri harmanlayarak kendine özel kahve oluşturabilir. Fiyat da seçilen kahvelere göre yeniden hesaplanır.

175 Nesneye Yönelik Sistem Analizi
1.1. Aktörler Müşteri, 1. ve 2. adımları tekrarlayarak alışverişine devam eder. Müşteri, siparişini siteden verir. Siparişi tamamlamak için teslimat ve fatura bilgileri, ödeme detaylarını içeren bir form doldurur. Sipariş sisteme girilince, müşteri ve ödeme bilgileri doğrulanır. İstenen özelliklerdeki kahve, sağlayıcı depodan alınır, faturası basılır. Sipariş, fatura ile birlikte müşteriye gönderilir. Bu tariflere göre temel olarak iki aktör bulunmaktadır. Bunları bir sonraki slaytta görebilirsiniz.

176 Nesneye Yönelik Sistem Analizi
1.1. Aktörler Şekil1.1. Kahve sitesi sistemi aktörleri

177 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Herhangi bir senaryoyla ilişkisi bulunmayan bir aktör, sistemde gereksizdir. Ancak, hiçbir aktörle ilişkide olmayan senaryolar bulunabilir. Bu tip senaryolar, kullanım senaryosu modellemesinde ana senaryolara yardımcı olurlar. Kullanım senaryolarının UML gösterimi elips şeklindedir. Senaryonun adı, elipsin içine ya da altına yazılabilir.

178 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Genelde aktör ve senaryoların etkileşimde olması beklenir. Ancak, bir senaryo başka bir senaryoyla da ilişkili olabilir. Bir aktörün direk olarak bir başka aktörle etkileşimde olması önerilmez. Aralarında mutlaka etkileşimi sağlayan bir senaryo bulunmalıdır. Şekil1.2 ‘de, kahve sitesi sisteminin kullanım senaryosu diyagramı görülmektedir.

179 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Şekil1.2. Kahve sitesi sistemi için kullanım senaryosu diyagramı

180 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Kullanım senaryoları arasında üç farklı ilişki tanımlanabilir. İçerme(Include-Use): Bir senaryoda kullanılan başka bir senaryoyu belirtir. Örneğin Şekil1.2’de Sipariş verme senaryosunun içinde, müşterinin ödeme ve teslimat bilgilerini girmesi gereklidir. Genişletme(Extend):Senaryolar doğal akışlarına göre hazırlanırlar. Özel durumlarda sapmalar olabilir. Bu gibi senaryolarda genişletme ilişkisi ile gösterilir. Şekil1.2’de “Kahve seçimi” senaryosunu, “özel kahve hazırlama” senaryosu genişletmektedir.

181 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Özelleştirme(Specilization): Sınıflar arası türetme ilişkileri gibi, senaryolar da türetilebilir. Her senaryo, bir senaryo dökumanı ile ayrıca detaylandırılmalıdır. Bu sayede bir aktör herhangi bir senaryoyu etkinleştirdiğinde sistemin neler yapacağı açıklanmış olur.

182 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Senaryo dökumantasyonunda; Senaryo adı İlgili aktörler(Birinci aktör,ilgililer) Senaryonun gerçekleşebilmesi için gerekli ön koşullar Senaryo tamamlandığında sistemin ulaşacağı durumu tanımlayan son koşullar Senaryonun temel akışı Özel durumlarda yürütülecek akışlar yer alır.

183 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Bir sonraki slaytta kahve sitesi sisteminin, “sipariş verme” senaryo dokümantasyonu örnek olarak verilmiştir.

184 Nesneye Yönelik Sistem Analizi
1.2. Kullanım Senaryoları Senaryo KS1 Sipariş verme Birinci Aktör Müşteri İlgililer ve Beklentiler Kahve sitesi: Müşterinin siparişi doğru ve eksiksiz kaydedilmeli, ödeme ve teslimat doğru alınmalı. Depo:Siparişteki kahve ve miktarları doğru ve eksiksiz olmalı Ön koşullar Müşteri alışveriş sitesinde olmalı, sunulan seçenekler ile istediği kahveyi oluşturmalıdır. Son koşullar Ödeme ve teslimat bilgileri doğrulanmıştır. Müşterinin siparişi sistem veritabanına teslimat yapılmak üzere kaydedilmiştir. Ana akış Müşteri sipariş etmek istediğini belirtir. Müşteri teslimat için adını ve adresini , teslimat bilgilerinden farklıysa fatura bilgilerini girer. Müşteri ödeme şeklini seçer ve gerekli ödeme bilgilerini girer. Sistem siparişi için benzersiz bir tanımlayıcı kod üretir, müşteri hesap bilgileri ile birlikte kaydeder. Alternatif akış Müşteri gerekli tüm bilgileri sağlamadan siparişi tamamlar. Sistem bir hata mesajı vererek eksik olan bilgilerin tamamlanmasını ister.

185 SİSTEM ANALİZ VE TASARIMI Ders 10(12.Hafta)
Öğr. Gör. Sezer YILDIZ Beykoz Lojistik Meslek Yüksekokulu Bilgisayar Teknolojileri

186 Konular Nesneye Yönelik Sistem Analizi
Kullanım(Use Case) Senaryosu Modellemesi Sınıf(Class) Modellemesi

187 1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi
Nesneye yönelik analizde iç durumu sınıf modeli ile tanımlanır. Bu modellemede sınıflar ile birlikte özellikleri, işlemleri, bağlantıları, bütünleşmeler, bileşimler, genelleştirmeler de yer alır. Sınıf diyagramı ile tüm bu öğeler görselleştirilir. Nesneye yönelik sistem analizi sırasında kullanım senaryosu modellemesi ile sınıf modellemesi, birbirine paralel olarak ilerler. Her iki modelde de , diğerine destek bilgisi sağlar. Kullanım senaryoları ile sınıfların belirlenmesi kolaylaşırken, sınıflar da gözden kaçırılan kullanım senaryolarının belirlenmesine yardımcı olur. Bu iki model ile uygulama alanının modeli oluşturulmuş olur. Tasarlanacak sistem tüm yönleriyle anlaşılır.

188 1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi
Sınıf modellemesinde yer alan sınıflar, gerçek dünyayı oluşturan kavramsal nesnelerdir. Sınıfları belirlemek için, kullanım senaryolarında yer alan isimlerden ve isim tamlamalarından yararlanılabilir. Bir önceki dersimize örnek olarak verilen kahve sitesi kullanım senaryosundaki isimler ve tamlamaları verilmiştir.

189 1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi
Müşteri sipariş etmek istediğini belirtir. Müşteri teslimat için adını ve adresini, teslimat bilgilerinden farklıysa fatura bilgilerini girer. Müşteri ödeme şeklini seçer ve gerekli ödeme bilgilerini girer. Sistem sipariş için benzersiz bir tanımlayıcı kod üretir, müşteri hesap bilgileri ile birlikte veritabanına kaydeder.

190 1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi
Bunun gibi tüm kullanım senaryolarındaki isimler bulunarak aday sınıflar elde edilebilir.

191 1. Nesneye Yönelik Sistem Analizi 1. 2. Sınıf Modellemesi 1. 2. 1
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Özelliklerin Belirlenmesi Bir sınıfın özellikleri, yaratılan nesnelere özgü değerler alan verilerdir. Not: Birden fazla alandan oluşan, üzerinde işlem yapılan, kendi niteliklerine sahip olan kavramlar, bir sınıfın özelliği değil ayrı bir sınıf olarak ifade edilmelidir.

192 1. Nesneye Yönelik Sistem Analizi 1. 2. Sınıf Modellemesi 1. 2. 2
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Bağlantıların Belirlenmesi Bağlantılar, nesnelerin işbirliği ilişkilerinin çıkarılmasına yardımcı olmaktadır. Sistem gerçekleştirildiğinde sınıflar arasındaki bağlantılar, bu sınıflardaki belirli özellikleri ile temsil edilir. Analiz aşamasında ise, bağlantılar çizgiler ve çoğullama simgeleri ile gösterilir.

193 1. Nesneye Yönelik Sistem Analizi 1. 2. Sınıf Modellemesi 1. 2. 2
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Bağlantıların Belirlenmesi Bağlantıların belirlenmesi için, sınıfların belirlenmesinde olduğu gibi kullanım senaryolarından yararlanılır. Senaryolarda yer alan fiiller, olası bağlantılardır. Ayrıca senaryoda yer alan faaliyetler de bağlantı değil, etkileşimi ifade eder. Bu yüzden bağlantı, bir ya da birkaç işlemi değil bir ilişkiyi temsil etmelidir.

194 1. Nesneye Yönelik Sistem Analizi 1. 2. Sınıf Modellemesi 1. 2. 3
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Sınıf Diyagramı Bu diyagramda kavramsal sınıflar, aralarındaki ilişkiler ve sınıfların nitelikleri yer alır. Şekil1.1’de kahve sitesi sistemi için sınıf diyagramı gösterilmiştir. Sınıfların henüz işlemleri bulunmamaktadır. İşlemlerin belirlenmesi, sınıfların sorumluluklarının belirlenmesi demektir ve nesneye yönelik yaklaşımda tasarım safhasını oluşturur.Sınıf diyagramına işlemler de eklendiğinde, sistemin davranışı da gösterilmiş olur.

195 1. Nesneye Yönelik Sistem Analizi 1. 2. Sınıf Modellemesi 1. 2. 3
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Sınıf Diyagramı Kahve sitesi sınıfı, uygulamanın ana sınıfı olarak düşünülebilir. Sitede bulunan Müşteri ve Kahve sınıflarının sahibi Kahve Sitesi sınıfıdır. Bir müşterinin hiç Siparişi olmayabilir. Bunun yanında müşteri birden fazla sipariş de verebilir. Bir Siparişin tek bir Ödemesi olabilir. Siparişin durum özelliğine bağlı olarak, Faturası olmayabilir. Bir siparişin en fazla bir faturası olabilir. Bir siparişte bir veya birden fazla Sipariş Kalemi yer alabilir. Burada Sipariş Kalemi soyut sınıf olarak tanımlanmıştır.

196 1. Nesneye Yönelik Sistem Analizi 1. 2. Sınıf Modellemesi 1. 2. 3
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Sınıf Diyagramı Uygulamada kendi üzerinden bir nesne yaratılmayacaktır. Bu durumda uygulamada bir siparişi kalemleri, ya StandartKalem ya da ÖzelKalem olacaktır. Kahve sınıfı Sipariş Kalemi sınıfına kümeleme ilişkisi ile bağlıdır. Başka bir deyişle Kahve, Sipariş Kalemi sınıfından türeyen nesnelerde yer alan bir nesne olacaktır. Özel Kalem sınıfının birçok kahve nesnesinden oluştuğu görülmektedir. Bu yüzden ÖzelKalem sınıfı içinde Kahveleri tutan bir liste yapısına ihtiyaç duyulmuştur.

197 Şekil 1.1. Kahve sitesi sistemi için sınıf diyagramı
1.Nesneye Yönelik Sistem Analizi 1.2.Sınıf Modellemesi Sınıf Diyagramı Şekil 1.1. Kahve sitesi sistemi için sınıf diyagramı

198 Nesneye Yönelik Sistem Analizi 1
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması Bir bankanın ATM cihazı için yazılım geliştirilecektir. ATM, banka kartı olan müşterilerin hesaplarından para çekmelerine, hesaplarına para yatırmalarına ve hesapları arasında para transferi yapmalarına olanak sağlayacaktır. ATM, banka müşterisi ve hesapları ile ilgili bilgileri, gerektiğinde merkezi banka sisteminden alacaktır.

199 ATM uygulama yazılımının kullanıcıları: Banka müşterisi
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması ATM uygulama yazılımının kullanıcıları: Banka müşterisi Merkezi Banka Sistemi Aktörler

200 Nesneye Yönelik Sistem Analizi 1
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması Belirlenen aktörler ATM’den ne istiyorlar ? Aktör: Banka müşterisi Para çekme Para yatırma Para transferi Aktör: Merkezi Banka Sistemi Günlük özet alma

201 Nesneye Yönelik Sistem Analizi 1
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması Aktör: Banka müşterisi Bankada hesabı ve banka kartı olan, ATM’den işlem yapma hakkı olan kişidir. Use case: Para çekme Banka müşterisinin nasıl para çekeceğini tanımlar. Para çekme işlemi sırasında banka müşterisinin istediği tutarı belirtmesi ve hesabında bu tutarın mevcut olması gerekir.

202 Nesneye Yönelik Sistem Analizi 1
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması

203 Nesneye Yönelik Sistem Analizi 1
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması

204 Nesneye Yönelik Sistem Analizi 1
Nesneye Yönelik Sistem Analizi 1.Örnek bir kullanım senaryosu problemi ATM uygulaması

205 Nesneye Yönelik Sistem Analizi 2.Örnek bir kullanım senaryosu problemi
-Kullanıcı Aktörünün Alıcı ve Satıcı türlerine sahip olduğunu, -Kullanıcı’nın Sisteme Bağlan UC(Use-Case)’ini çalıştırdığında bu iki Aktör’den birine dönüştüğünü göreceğiz. -Kullanıcı sisteme bağlanmadan bir teklif vermek isterse (Varsayım: O anda olan bir müzayedeye kayıtsız bir izleyici olarak katılım mümkün), sistem onu Sisteme Bağlanmaya zorlayacaktır: -Teklif Ver extends Kataloga Bak ve Teklif Ver includes Sisteme Bağlan. -Kullanıcı bir Alıcı dönüştüğünde dilediği zaman Teklif Ver UC’ini çalıştırarak, bir teklif verebilir. - Satıcı Aktörleri ise Sisteme Bağlan UC’ini çalıştırdıktan sonra, - Açık Artırma Kur’abilir ve Açık Artırma Seansı Başlat’abilirler. - Eğer Açık Artırma Seansı Başlat’ırlarsa Sayaç belli bir süre saymaya başlar. Bu süre sonunda Sayaç Açık Artırmayı Kapat’ır ve Alıcı ile Satıcıları müzayedenin bittiğinden haberdar eder.

206 Nesneye Yönelik Sistem Analizi 2.Örnek bir kullanım senaryosu problemi

207 Nesneye Yönelik Sistem Analizi 3.Örnek bir kullanım senaryosu problemi
Bir diğer örneğimiz ise ürün işlemleri, elimizde bir ürünümüz ve bu ürünümüzün silinmesi için kullandığımız bir fonksiyonumuz var. Biz ürünü sildiğimizde o ürün pasif konuma geçiyor. Diğer bir fonksiyonumuz ise pasif ürünün silinmesi işlemidir. Biz bu ürünleri silmemiz için önce bir ürün kontrolü fonksiyonumuz vardır. Diğer bir fonksiyonumuz ise ürün ödeme fonksiyonudur. Ödeme yapılır iken kredi kartı bilgilerinin kontrolü gerekmektedir. Diğer bir fonksiyonumuz ise kart bilgileri kontrol fonksiyonudur. Bir sonraki slaytta bu senaryonun Use Case diyagramı çizilmiştir.

208 Nesneye Yönelik Sistem Analizi 3.Örnek bir kullanım senaryosu problemi

209 Nesneye Yönelik Sistem Analizi Özet
Uygulamanın gereksinimlerini tanımlamak için paralel olarak geliştirilen sınıf ve kullanım(kullanıcı) senaryosu(use-case) modellemeleri yapılır. Kullanım senaryosu modellemesi, sistemdeki kullanımların, senaryoların belirlenmesini sağlayarak sistemin nasıl kullanılacağını modeller. Böylece sistemin beklenen davranışını açıklar.Senaryolar, anlamlı bir sonuca ulaşmak için sistemle aktör arasında gerçekleşen olaylardır. UML’de modelleme, kullanım senaryosu diyagramı ile yapılır. Bunun yanında her senaryo için bir doküman da hazırlanır. Karmaşık işlemlerden oluşan senaryoların anlaşılabilirliğini arttırmak için sözleşme de yazılabilir.

210 Nesneye Yönelik Sistem Analizi Özet
Sistemin iç durumu, sınıf modellemesi ile belirtilir. Sınıflar ile özellikleri, işlemleri, bağlantılar, bütünleşmeler, bileşimler, genelleştirmeler de sınıf diyagramı ile görselleştirilir. Modelde yer alan sınıflar, gerçek dünyayı oluşturan kavramsal nesnelerdir. Not: Analiz sürecinde amaç problemin doğru, mantıklı, anlaşılır ve test edilebilir modelini oluşturmaktır. Problemin çözümü, tasarım sürecine bırakılır.

211 Nesneye Yönelik Sistem Analizi ÖDEV
Siteye gelen bir kullanıcı kayıtsız şartsız makale başlıklarını görebilmektedir. Online olan kullanıcı Siteyi tavsiye edebilir, siteye üye olabilir,kitapları inceleyebilir. Ancak makale okuması ve kaynak kod indirebilmesi için siteye üye girişi yapmalıdır. Makale okuması ve kaynak kod indirebilmesi için gereken şart siteye üye olmaktır. Siteye bağlanan bir kullanıcının site üzerindeki hareketlerini gösteren use- case diyagramını çiziniz.

212 2.Nesneye Yönelik Sistem Tasarımı
Tasarım aşamasında analizi yapılarak modellenen sistemin mantıksal çözümü oluşturulur. Burada önemli olan, sınıfların aralarındaki etkileşimlerin belirlenmesidir. Bu sayede sistemin parçalarının bir arada nasıl çalışacağı, hangi sorumluluğun hangi sınıfa ait olacağı ortaya konulur. Yazılım nesnelerine metotların eklenmesi ve istekleri yerine getirmek üzere mesajların oluşturulması ile nesnel tasarım gerçekleştirilir. Kısacası, nesneye yönelik tasarımının amacı sorumlulukların ilgililere atanmasıdır. Atanan sorumlulukları yerine getirmek üzere sınıflarda metotlar oluşturulur. Bir sorumluluğu gerçekleştirmek için bir nesne başka nesnelerle işbirliği içinde çalışabilir.

213 2.Nesneye Yönelik Sistem Tasarımı
Nesneye yönelik sistem tasarımı sırasında nesnelerin birlikte çalışmalarını göstermek amacıyla etkileşimli diyagramları çizilir. Bunlar işbirliği ve ardışıl diyagramlarıdır. Etkileşim diyagramları ile birlikte tasarlanan sistemin son durumunu gösteren tasarım sınıf diyagramı da çizilir.

214 2.Nesneye Yönelik Sistem Tasarımı 2.1.Tasarım Kalıpları
Yazılım sınıflarının belirlenmesinde ve onlara uygun sorumlulukların atanmasında tasarım kalıpları yaygın olarak kullanılmaktadır. Sıklıkla karşılaşılan, tanımlanabilir bir probleme sistematik bir çözüm getiren prensiplere, tasarım kalıpları adı verilir.

215 2. Nesneye Yönelik Sistem Tasarımı 2. 1. Tasarım Kalıpları 2. 1. 1
2.Nesneye Yönelik Sistem Tasarımı 2.1.Tasarım Kalıpları Yaratıcı(Creator) Bir sınıftan nesne yaratma sorumluluğunun kime verileceğini belirleyen kalıptır. Aşağıdaki koşullar geçerli olduğunda B sınıfına A sınıfından nesne yaratma sorumluluğu verilir: B, A nesnelerini içeriyorsa(kümeleme ilişkisi dahil) B, A nesnelerinin kaydını tutuyorsa B, A nesnelerini sıkı bir biçimde kullanıyorsa A ’nın yaratılması için gerekli verilere B sahipse Kahve sitesinde, SiparişKalemi nesnesini kimin yaracağı örnek olarak verilebilir. Uygulama modeli incelenirse bir siparişin birçok SiparişKalemi içerdiği görülür. Bu yüzden sipariş kalemlerini yaratma sorumluluğu siparişindir.

216 2. Nesneye Yönelik Sistem Tasarımı 2. 1. Tasarım Kalıpları 2. 1. 2
2.Nesneye Yönelik Sistem Tasarımı 2.1.Tasarım Kalıpları Bilginin Uzmanı(Expert) Nesnelere sorumluluk atamanın temel prensibidir. Bir sorumluluğun o bilginin uzmanına, onu yerine getirecek veriye sahip olan sınıfa atanmasını tanımlar.

217 2. Nesneye Yönelik Sistem Tasarımı 2. 1. Tasarım Kalıpları 2. 1. 3
2.Nesneye Yönelik Sistem Tasarımı 2.1.Tasarım Kalıpları Az Bağımlılık(Low Coupling) Bağımlılık, bir birimin diğerlerine ne kadar bağlı olduğu, haklarında ne kadar bilgi sahibi olduğu ve işleri yerine getirebilmek için ne kadar diğer birimlere bağlı olduğunu gösteren bir ölçüttür.

218 2. Nesneye Yönelik Sistem Tasarımı 2. 1. Tasarım Kalıpları 2. 1. 4
2.Nesneye Yönelik Sistem Tasarımı 2.1.Tasarım Kalıpları Denetçi(Controller) Kullanıcı arabiriminin arkasında durarak sistem olaylarını alma ve kontrol etme sorumluluğunu alarak yönlendirmeyi sağlamaktadır.

219 2.Nesneye Yönelik Sistem Tasarımı 2.2. Etkileşim Diyagramları
Kullanıcı arabiriminin arkasında durarak sistem olaylarını alma ve kontrol etme sorumluluğunu alarak yönlendirmeyi sağlamaktadır.

220 Sınıflar Arası İlişkiler
Şekil 5. İçerim ilişki örneği İki sınıf arasındaki “sahiptir” veya içerir türünden bağıntıları modellemekte kullanılır.


"SİSTEM Sistem, bir hedef veya amacı gerçekleştirmek üzere bir arada çalışan birbiriyle ilişkili parçalardan oluşan ve girdi-çıktıları olan sınırları." indir ppt

Benzer bir sunumlar


Google Reklamları