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 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 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

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 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) { adi = ad; takimi = takim; 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) Ö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 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 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 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 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? 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? 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. 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. 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. 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. Soru Cevap Kullanıcı Arayüzü

120 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. 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. 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. Form Kullanıcı Arayüzü

124 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. 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 Şekil1. Ba ğ ıntı ilişkisinde ba ğ ıntı adı ve yönü Sınıflar Arası İ lişkiler

148 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; Sınıflar Arası İ lişkiler

149 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 Sınıflar Arası İ lişkiler

150 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. Sınıflar Arası İ lişkiler

151 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. Sınıflar Arası İ lişkiler

152 Ş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 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. 3. Ba ğ ımlılık İ lişkisi(Dependency)

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

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 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 - 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 KS1Sipariş verme Birinci AktörMüşteri İ lgililer ve BeklentilerKahve 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şullarMüş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ış1.Müşteri sipariş etmek istedi ğ ini belirtir. 2.Müşteri teslimat için adını ve adresini, teslimat bilgilerinden farklıysa fatura bilgilerini girer. 3.Müşteri ödeme şeklini seçer ve gerekli ödeme bilgilerini girer. 4.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 DERS SONU Kaynak: Ders kitabı(Sistem Analizi ve Tasarımı) Google wikipedia


"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ı