SİSTEM ANALİZİ VE TASARIMI

... konulu sunumlar: "SİSTEM ANALİZİ VE TASARIMI"— Sunum transkripti:

1 SİSTEM ANALİZİ VE TASARIMI
GELİŞMİŞ SİSTEM ANALİZİ

2 GELİŞMİŞ SİSTEM ANALİZİ
Bu bölümde geleneksel metodlar yerine modern veya gelişmiş sistem analizi yöntemleri üzerinde durulmuştur. Günümüzde işverenler artık daha hızlı ve daha etkili çözüm yolları istemektedirler. Bu ihtiyacı eski metodlar karşılamadığından, yeni sistem analiz yöntemleri ortaya çıkmıştır. Bu yöntemlere “gelişmiş sistem analizi” veya “modern sistem analizi” yöntemleri denmektedir. En çok kullanılan iki yöntem “Hızlı Uygulama Geliştirme (Rapid Application Development - RAD)” ve “Nesne Yönelimli (Object Oriented - OO)” analizdir.

3 Hızlı Uygulama Geliştirme (HUG)
Hızlı Uygulama Geliştirme (HUG) bir bilgi sistemi geliştirme işlemi hızlandırmasıdır. HUG, yazılım geliştirme aşamalarının hemen hepsini kapsayan ve daha kısa bir sürede tamamlayan bir yazılım geliştirme yöntemidir. Geleneksel yöntemlerde analiz, tasarım, geliştirme ve test etme aşamaları birbiri ardına gelir ve uzun zaman alır. HUG’da ise bu aşamalar bir arada ele alınır. Bu aşamaların gerçekleştirilmesi tekrarlanan bir yapı içinde, gereksinimlerin belirlenmesi, tasarım, geliştirme, test etme, kullanıcının gözden geçirmesi, birleştirici uygulama tasarımı (JAD) aşamaları ile olur. Geleneksel yöntemlere göre daha iç içe ve sıkıştırılmış bir yöntemdir.

4 GELENEKSEL GELİŞTİRME sikilastirma
Planlama Analiz Tasarım Gelistirme Test Yayılma Tasarim Gereksinim Belirleme Planlama Gelistirme Yayılma JAD Test Kullanıcı Değerlendirmesi HUG

5 Hızlı Uygulama Geliştirme (HUG)
HUG için vurgulanabilecek iki sınırlılık vardır; ölçeklendirilebilirliğin düşüklüğü ve ayrıntı özelliklerinin eksikliği. Kısa sürede gerçekleştirilen sistemlerde önemsiz bazı ayrıntıların eksikliği oluşabilir. HUG küçük takımlarla gerçekleştirilebilecek, çok kapsamlı ve çok büyük olmayan projelerde daha uygundur.

6 HUG’un Özellikleri Aşamalarda etkinliklerin ayrılması
Sürekli bütünleştirme Kayıt altına almaktan kodlamaya yoğunlaşma Taslakların etkili kullanımı Sürekli müşteri katılımı HUG’un 4 temel bileşeni; yöntem (methodology), insanlar (people), yönetim (management) ve araçlar (tools).

7 HUG’un Bileşeni: Yöntem
Yöntem (methodology) bileşeni kapsamında gerçekleştirilenler; Sistem geliştirmede kullanılabilecek en uygun tekniklerin bulunup, bu tekniklerin sırasına karar verme. Sonuçta ürün olarak ortaya çıkacak gelişmekte olan prototipleri kullanma. Gereksinim belirleme ve tasarım için çalıştaylar yürütme. Modelleme, prototip oluşturma, kodlama ve tekniklerin uygulaması açısından en etkili ve verimli durum araçlarını belirleme vs...

8 HUG’un Bileşeni: İnsanlar
HUG uygulamalarında daha çok aşağıdaki insanlar etkili olmaktadır; Destekleyiciler (Sponsors) Kullanıcı Eşgüdümcüsü (User Coordinator) Gereksinim Planlama Ekibi (Requirements Planning Team) Kullanıcı Tasarım Ekibi (User Design Team) Kullanıcı Denetim Kurulu (User Review Board) Eğitim Yöneticisi (Training Manager) Proje Yöneticisi (Project Manager) Geliştirme Ekibi (Construction Team) Çalıştay Lideri (Workshop Leader)

9 HUG’un Bileşeni: Yönetim
Sistem geliştirme sürecinde özellikle HUG’da yönetim çok önemlidir. Müşteriler, yapım ekibi, kullanıcılar arasındaki uyumun sağlanması, herkesin üzerine düşen işi zamanında ve iyi derecede yapabilmesi için güdülenmeleri yönetim eyleminin bir parçasıdır. Sistem geliştirme aşamasının başından sonuna kadar tüm durumlarda yönetim söz sahibi ve yönlendiricidir.

10 HUG’un Bileşeni: Araçlar
HUG’un gerçekleşmesi için yapılabilecek bütün işlemler için çeşitli araçlar bulunmaktadır. HUG sürecinde gerçekleştirilen işlemler ve bu işlemlerin gerçekleşmesinde kullanılabilecek araçların bir kısmı aşağıdaki gibidir; Veri bütünleştirme Geliştirme çevreleri Gereksinim toplama Veri modelleme Kod oluşturan yazılımlar

11 Veri Bütünleştirme Daha önce sistemin gelişiminde kullanılabilecek verilerin uygun bir şekilde bütünleştirilmesi önemi üzerinde durulmuştu. Veri bütünleştirme işlemi kullanılabilecek bir çok araç bulunmaktadır. IBM Rational Rapid Developer, MS SQL Server, Host Integration Server, MS BizTalk veri bütünleştirmede kullanılan araçların bir kaçıdır.

12 Geliştirme Çevreleri Microsoft Visual Studio .NET, Sun Java Studio Creator, Borland C# Builder, IBM WebSphere Studio Application Developer geliştirme çevrelerinden bazılarıdır.

13 Gereksinim Toplama Gereksinim toplama işlemi için kullanılabilecek en etkili ve verimli yöntem modelleme yardımı ile gereksinim toplama olacaktır. Modelleme yapmak için kullanılan en önemli teknoloji UML’dir. UML “Unified Modelling Language - Birleştirilmiş Modelleme Dili” yazılım geliştirme sürecinde kullanmaları için yaratılmıştır, UML bir programlama dili değildir. Herhangi bir yönelimli programlama dili ile geliştirilecek herhangi bir yazılımın gelişim basamaklarının modellenmesi UML ile mümkündür. MS Visio, IBM Rational Rose, Poseidon bunlara birer örnektir.

14 Veri Modelleme Bu işlem için de UML teknolojisi kullanılmaktadır. Gereksinim toplanması aşamasında sonra gereksinimlerin düzenlenmesi gerekmektedir.

15 Kod Oluşturan Yazılımlar
Birçok yazılımda bulunan ve tekrar tekrar yapılmasının bir getirisi olmayan kod parçacıkları bulunmaktadır. Yazılımlar bu tür kodlar için ek bir çaba ve zaman harcamak istemezler. Bu tür kodlar bir programlama dili için bir veritabanı sistemine bağlanma, ondan veri okuma, yazma vs.. gibi işlemleri yapacak kodlardır.

16 Nesne Yönelimli Analiz ve UML
Nesne Yonelimli (Object-Oriented) kavramı sistemleri dolayısıyla varolan herşeyi bir nesne olarak görebilme düşüncesi ile ilgilidir. Daha çabuk geliştirilebilen, daha kaliteli, daha kolay geliştirilebilen, daha az bakım gerektiren yazılımlar geliştirebilmek için bu kavramı çıkarmıştır. Günümüze kadar nesne yönelimli yaklaşım gelişmiş ve artık büyük sistemlerin analiz ve tasarım aşamalarında kullanılmakta olan bir yaklaşım olmuştur.

17 Nesne Yönelimli Analiz ve UML
Genel olarak nesne dokunulabilen veya görülebilen veya varlığı anlaşılabilen veya düşünce ve eylemlerin kendisinden etkilendiği varlıklar olarak tarif edilir. Diğer taraftan yazılım sektöründe nesne zamanda ve mekanda var olan anlamında kullanılmaktadır. Sonuç olarak yazılım sektöründe nesne hem somut hem soyut varlıkları temsil etmek için kullanılabilir. UML ve görsel modellemenin daha iyi anlaşılabilmesi için, nesne yönelimli yaklaşımla ilgili bilinmesi gereken temel bir kaç kavram vardır. Bazıları; sarmalama, kalıt ve çok biçimliliktir.

18 Sarmalama (Encapsulation)
Nesne yönelimli yaklaşımda, sınıflara ait bazı ayrıntıların dışarıdan görülebilmesi istenmez. Bu ayrıntıların saklanması için sarmalama yapılır. Sarmalama bir sistem nesnesine veya bazı elemanlara ait veriyi, iç yapıyı ve uygulama ayrıntılarını gizleyen bir mekanizmadır. Sarmalama ile bütün etkileşimler, işlemler için genel bir arayüz ile sağlanır. Gizlenen niteliklere özel (private) denir.

19 Banka Modelinde Sarmalama

20 Kalıt (Inheritance) Daha önceki konularda nesnenin, bir sınıfın üyesi olduğu ve üyesi olduğu sınıfa ait bütün özellikleri taşıdığı vurgulanmıştı. Aslında buna benzer bir durum sınıflar için de geçerlidir. Her sınıf bir başka sınıfın alt sınıfıdır ve ait olduğu sınıfın tüm özelliklerini taşır. Bu durum sınıflar arasında alt sınıf (child class) ve üst sınıf (parent class) denebilecek bir hiyerarşinin oluşmasına yol açmaktadır. Bu bağlamda her sınıfın üyesi olduğu sınıfın genel özellikleri ve kendine özel nitelikleri taşıdığı söylenebilir.

21 Kalıt Hiyerarşisi Örneği

22 Çok Biçimlilik (Polymorphism)
Çok biçimlilik bir sistemdeki işlemlerin gerçekleşmesi için kullanılacak yöntemin dinamik olarak seçilmesine olanak sağlar. Yöntemin farklılığı çoğu zaman ilgili olduğu nesneye göre ortaya çıkmaktadır. Çok biçimlilikle beraber aynı işlem farklı yöntemlerle tekrar tekrar kullanılmış olur. Bununla beraber gerçekte hangi yöntemin kullanıldığının bilinmemesine rağmen istekler arasında iletişim kurulabilir.

23 Çok Biçimlilik (Polymorphism)

24 Görsel Modelleme Pek çok insan yapacağı işleri bir plana göre yapar. Yapılan planların bazıları tablolar, bazıları metinler, bazıları şekiller ve şemalar ile ifade edilebilir. Genellikle bir sistem üzerinde bir değişiklik yapılmak istendiği zaman planlar görsel yapılır. Bunun en büyük nedenlerinden biri sistemi bir deneme tahtası gibi kullabilme olanağının olmamasıdır. Görsel modelleme sistem, kullanıcılar, yöneticiler, yazılımcılar, sistem analizi vs. arasında ortak dilde anlaşmayı sağlamalıdır.

25 Grafiksel Gösterim Grafiksel gösterim açısından en çok bilinen ve kullanılan üç standard bulunmaktadır. Bu standardlar Booch, Object Modeling Technology ve UML’dir. Sektörde en çok kullanılan görsel modelleme yöntemi UML’dir.

26 Birleştirilmiş Modelleme Dili (UML)
UML kendine ait kuralları ve anlam bütünlüğü olan bir dildir. Bu bağlamda UML ile modellenecek herşeyin bu kural ve anlamlara uyması gerekmektedir. UML bir sistemin sadece görsel sunumunu yapmakla kalmaz, aynı zamanda o sistemin kapsamı ile ilgili de bilgi sunar. UML bir seri standardlaştırılmış şekil yardımıyla yazılım ve sistem geliştiricilerin bir takım geliştirme işlemlerinin gerçekleştirmelerini kolaylaştırmak için geliştirilmiştir.

27 UML ile gercekleştirilen en temel görevler:
1. Belirginleştirme (Kesinleştirme) 2. Görselleştirme 3. Mimari Tasarım 4. Yapım 5. Benzetim ve Test Etme 6. Dökümantasyon

28 UML Şemaları Birçok alanda pek çok şekilde etkili ve verimli kullanabilen UML’in kullanım yerlerine göre özelleşmiş şemaları bulunmaktadır. Nerede hangi şemanın kullanılacağı geliştirilen sistemin durumu ve beklentilerine göre değişmektedir. UML kullanarak geliştirilebilen görsel şemaların başlıcaları aşağıda verilmiştir;

29 Kullanım Durumu Şemaları (Use-Case Diagrams)
Kullanım durumu şemaları sistem kullanıcılarının sistemle, sistem bileşenlerinin birbirleriyle vb. etkileşimlerini görselleştirmeyi sağlarlar. Bununla beraber sistemin alt sistemler şeklinde gösterimi de mümkündür. Ayrıca sistemin çalışma şeklini gösteren şemalardır. Sistemde yer alan elemanların sistemin diğer bileşenlerini nasıl kullandıkları ve bu kullanımla neleri gerçekleştirdikleri kullanım durumu şemaları ile gösterilebilir.

30 Kullanım Durumu Şemaları (Use-Case Diagrams)
Bir kullanım durumu şemasında bulunması gereken üç temel bileşen vardır. Bu bileşenler; senarya, aktör ve ilişkilerdir. Senaryo: gerçeklestirilen bir dizi eylemin sıralı bir şekilde ifade edilmesidir. Senaryo kimini, hangi eylemi, hangi sırayla gerçekleştirdiğini anlatır. Aktör: kullanım durumu kapsamında sistem kullanıcılarının gerçekleştirdikleri görevler kümesini temsil eder. Ilişkiler: sistemde yer alan durum ve aktörlerin ilişkilerinin gösterimi dışında kalan ilişkiler de kullanım durumu şemalarında da gösterilebilirler.

31 Kullanım Durumu Şemaları (Use-Case Diagrams)
İlişki: bu ilişkiler kapsam (include), genelleme (generalization), genişletme (extend) ilişkileridir. Kapsam ilişkiler birden fazla kullanım durumunda yer alanların, her kullanım durumunda tekrar tekrar yapılmaması için yapılan ilişkilendirmelerdir. Genelleme ilişkileri, normal bir nitelik üzerindeki değişimin tanımlanması durumunun hesapsız yapılması için kullanılan ilişkilerdir. Genisletme ilişkileri, normal bir nitelik üzerindeki değişimin tanımlanması durumunda değişimin ayrıntılı ve belli ölçülere bağlı olarak yapılması için kullanılan ilişkilerdir.

32 Kullanım Durumu Şemaları (Use-Case Diagrams)

33 Kullanım Durumu Şemaları (Use-Case Diagrams)

34 Etkinlik Şemaları (Activity Diagrams)
Sistem geliştirmede en önemli etkenlerden biri de işlerin gerçekleşme süreçleridir. Nesneler üzerindeki kontrol veya nesneler arasındaki veri akışı gösterilmek istendiğinde etkinlik şemalari kullanılır. Bu gösterimde ilişkiler üzerinde durulmaz. Etkinlik diyagramları ile sistemde zamana bağlı olarak nesneler arasında ve insanla arasında gidişat sırasının gösterilmesi sağlanır. Kısacası bir etkinlik için olası bütün işlem akış durumları etkinlik şemaları ile gösterilebilmektedir.

35 Etkinlik Şemaları (Activity Diagrams)
Başlangıç: Akışlar: İşlemler: Çatallanma ve Birleştirme: Kararlar: Bitiş:

36 Etkinlik Şemaları (Activity Diagrams)

37 Sıra Şemaları (Sequence Diagram)
Sıra şemaları nesneler arasındaki etkileşimi gösterirler. Her ne kadar iletişim şemaları da nesneler arasındaki etkileşimi gösteriyor olsalar da iletişim şemaları daha çok nesneler arasındaki bağlantı üzerinde durmaktadırlar. Sıra şemaları nesnelerin birbirlerine gönderdikleri ve birbirlerinden aldıkları mesajların zaman sırasını esas alarak gösterir.

38 Sıra Şemaları (Sequence Diagram)

39 İşbirliği Şemaları (Collaboration Diagrams)
İşbirliği şemaları bazı kaynaklarda “Etkileşim Şemaları (Interaction Diagrams)” şeklinde de geçmektedir. Yapıları açısından sıra şemaları ile işbirliği şemaları birbirlerine oldukça benzer özellikler taşımaktadırlar. Bir önceki konuda sıra şemalarının zaman akışı içinde, nesnelerin birbirleri ile olan etkileşimlerini mesajlaşmaları aracılığı ile gösterdiklerinden söz edilmişti. Bu gösterimler işbirliği şemalarında da bulunmaktadır. Bununla beraber sıra şemaları zaman tabanlı ve etkileşimi ön plana çıkaran şemalardır. Diğer taraftan işbirliği şemaları hem zaman hem mekan tabanlı şemalardır.

40 İşbirliği Şemaları (Collaboration Diagrams)
İşbirliği şemaları nesnelerin birbirleri ile olan etkileşimlerini, ilgili elemanları ve ilişkileri göstermektedirler. Bu bağlamda işbirliği şemaları sıra şemalarının daha kapsamlı biçimi olarak düşünülebilir. Bu iki şema bilgi kaybı olmadan birbirlerine dönüştürülebilirler.

41 İşbirliği Şemaları (Collaboration Diagrams)

42 Sınıf Şemaları (Class Diagram)
Geliştirilebilecek her sistemde bir çok nesne bulunmaktadır ve her nesne bir sınıfın üyesidir. Bu bağlamda sistem kapsamında gözlemlenebilecek bir çok sınıf olduğu söylenebilir. Sistemler üzerinde analiz ve tasarım yapılırken sistemde yer alan nesnelere ait bilgiler kullanılmaktadır. Nesnelerin sınıflar tarafından temsil edilmesi sistem geliştirmede, veri elde etme ve kullanma vb. yönlerinden önemlidir.

43 Sınıf Şemaları (Class Diagram)
Sınıf şemaları sistemde yer alan nesne ve sınıfların tanımlamalarının ve birbirleri ile olan ilişkilerinin görselleştirildiği şemalardır. Sınıf şemalarında nesneler, sınıflar, arayüzler ve bunlar arasındaki ilişkiler ve işbirlikleri bulunmaktadır. Sınıf şemalarında yer alması gereken temel elemanlar vardır. Bunlar; sınıf, arayüz ve paket.

44 Sınıf Şemaları (Class Diagram)
Sınıf; geliştirilen sistemde bulunan, islevselliği olan ve islevselliği tanımlanabilen varlıktır. Arayüz; sistem içinde bazı genel kuralları tanımlayan ve sınıflamayı sağlayan birim. Paket; özellik veya ilişkisel açıdan birbirine yakın veya benzer sınıf ve arayüzlerin bir arada değerlendirilmesine olanak sağlar.

45 Sınıf Şemaları (Class Diagram)

46 Görsel Modelleme ve Yazılım Geliştirme
Yazılım sektöründe UML ile görsel modelleme sağlanabilmektedir. Teknoloji cağı da denebilecek olan günümüzde hemen her sektörde var olan sistemler çok hızlı bir şekilde değişimler ve dönüşümler geçirmektedirler. Öyle ki bazı sistemlerde yapılan değişimlerden sistemin büyük bir bölümünün bilgisi olmamaktadır. UML bu tür çalışmalar için oldukça uygun bir yapıya sahiptir. Bu nedenle UML diğer yöntemlere göre, yazılım geliştirmede oldukça iyi sonuçlar vermektedir. UML yardımı ile sistemin değerlendirilmesi, analizi ve tasarımı daha kaliteli bir şekilde yapılabilmektedir.

47 Görsel Modelleme ve Yazılım Geliştirme
Yazılım sektöründe maliyet açısından değerlendirme ölçütü olarak kabul edilen temel iki unsur vardır; zaman ve mekan. Zaman kavramı işlemler için gerekli olan süre ile ilgilidir. Zaman işlemlerin gerçekleşmesi sürecinin başından sonuna kadar geçen süre olarak da tanımalanabilir. Mekan veya yer olarak ifade edilen ikinci ölçüt verilerin bulunduğu fiziksel alanla ilgilidir. Üzerinde işlem yapılan veya kaydedilen verilerin verimli ve etkili şekilde tutulması yazılım sektörünün önde gelen değerlendirme ölçütlerindendir.

48 Görsel Modelleme ve Yazılım Geliştirme
Görsel modelleme yardımı ile yazılım geliştirme 4 temel aşamada gerçekleşmektedir. Bunlar; başlangıç, olgunlaşma, yapım ve geçiş aşamalarıdır.

49 Başlangıç (Inception)
Bir çok sistemde gelişim sürecinin başlaması bir fikirle olmaktadır. Bu fikir sistemin içindeki insanlardan veya yazılım geliştiricilerinden gelebilmektedir. Fikir ortaya atıldıktan sonra fikirle ilgili bir takım sorular ortaya çıkmaya başlar; Bu değişiklik yapılabilir mi? Bu değişiklik nasıl yapılabilir? Bu değişikligi yapmanın maliyeti nedir? Bu değişiklik gerçekleştiğinde sistem gerçekten yarar elde etmiş olacak mı? Başlangıç aşamasını sistemin anlaşıldığı aşama olarak da niteleyebiliriz. Sistemin fizibilite çalışmasının ve gereksinim analizinin yapılması bu aşamada olur.

50 Olgunlaşma (Elaboration)
Sistem değişimine yönelik sunulan fikir veya fikirler kabul edilip başlangıç aşaması olumlu gerçekleştikten sonra olgunlaşma aşamasına geçilir. Bu aşamada yapılacak değişiklik ile ilgili analiz ve tasarımlar yapılır. Sistem geliştirme sürecinin akışı, kullanılacak yazılım ve donanımlar vb. bu aşamada belirlenir. Yapım aşamasında gerçekleştirilecek işlemlerin alt yapısı olgunlaşma aşamasında olur. Yapım aşamasının başlayabilmesi ve sorunsuz devam etmesi için gereken hazırlıklar olgunlaşma aşamasında yapılır.

51 Yapım (Construction) Olgunlaşma aşamasından sonra yapım aşamasına geçilir. Bu aşamada gerçekleştirilecek sistem gelişimin ürünleri ortaya çıkmaya başlar. Olgunlaşma aşamasında elde edilen verilerle gelişmiş sistemin yapım işlemi başlar.

52 Geçiş (Transition) Geçiş aşaması geliştirilen sistemin hayata geçirilmesi aşamasıdır. Bu aşamada eski sistemden yeni sisteme geçiş gerçekleştirilir. Yapım aşaması sonucunda elde edilen yeni sistem kullanıcıların hizmetine sunulur. Yapım aşamasında test edilip kontrolden geçen yazılım bu aşamada sistemin gerçek kullanıcılarının onayına sunulur. Belirlenen süre sonunda yazılımın istenilen niteliklerde ve sorunsuz olduğu sistem kullanıcıları tarafından onaylanırsa geçiş süreci gerçekleşmiş olur. Eğer gerekli görülürse yazılım üzerinde değişiklik yaparlar. Geçiş aşamasının sonunda kullanıcılar şu ürünler verilir; kullanma kılavuzu, son durum test raporu, geliştirilen yazılımın yükleme dosyası.