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

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ç

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

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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

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.

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

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.

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.

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.

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.

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.

Sınıf

Alanlar, Metotlar, Erişim Belirleyicileri

Alanların Varsayılan Değerleri

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); } } }

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.

Örneğin; Aşağıdaki kod bloğu derleme zamanı hatası ile sonuçlanır.

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.

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

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

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.

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.

Yapıcı Metotlar(Constructor)

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.

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

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(); } } }

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

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.

6.DERS

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

1-Kapsülleme

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

Ö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; } }

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

namespace Kalitim { //Otomatik olarak System.Object sınıfından türer. class Calisan { } }

namespace Kalitim { //Her iki kullanım da doğrudur. class Calisan : System.Object { } //ya da class Calisan : object }

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

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(); } } }

Ç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; } } }

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(); } } }

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

Ç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; } } }

7.DERS

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.

Taslak veri akış diyagram örneği

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.

Birinci Düzey VAD örneği

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.

İkinci Düzey veri akış diyagramı

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.

Faturalama Sistemi ER Diyagramı

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.

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.

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.

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.

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.

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.

DERS 8 SİSTEM TASARIMI

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.

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

Ö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

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

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.

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.

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.

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.

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.

GENEL TASARIM İş yüklerinin tahmini

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.

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.

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.

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.

10.Hafta

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ı

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

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.

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

İyi bir kodlamada dikkat edilmesi gereken durumlar:

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.

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.

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.

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ü

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.

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.

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

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

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.

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:

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

Bu raporlarda bir tablo halinde aşağıdaki hususlar bildirilmelidir:  Projenin;

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.

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.

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

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.

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.

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.

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.

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

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

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.

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)

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.

Şekil1. Bağıntı ilişkisinde bağıntı adı ve yönü

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;

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

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.

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.

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

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.

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.

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.

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

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.

Şekil 6. Oluşum ilişki örneği

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

1.1. Aktörler Şekil1.1. Kahve sitesi sistemi aktörleri

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.

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.

1.2. Kullanım Senaryoları Şekil1.2. Kahve sitesi sistemi için kullanım senaryosu diyagramı

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.

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.

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.

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

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.

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

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:

Benzer bir sunumlar

Proje hakkında

Geri bildirim

Giriş

Sosyal ağ üzerinden giriş yapmak:

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:

Benzer bir sunumlar

Proje hakkında

Geri bildirim