Transcript sistem analizi ve tasarımı

GELİŞMİŞ SİSTEM ANALİZİ
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.
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.
GELENEKSEL GELİŞTİRME
Planlama
Tasarım
Analiz
Gelistirme
Test
sikilastirma
Tasarim
Planlama
Gereksinim
Belirleme
Gelistirme
JAD
Test
Kullanıcı
Değerlendirmesi
Yayılma
HUG
Yayılma
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.
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).
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...
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)
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.
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
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.
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.
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.
Veri Modelleme
 Bu işlem için de UML teknolojisi kullanılmaktadır.
Gereksinim toplanması aşamasında sonra
gereksinimlerin düzenlenmesi gerekmektedir.
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.
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.
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.
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.
Banka Modelinde Sarmalama
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.
Kalıt Hiyerarşisi Örneği
Ç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.
Çok Biçimlilik (Polymorphism)
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.
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.
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.
 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
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;
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.
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.
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.
Kullanım Durumu Şemaları (Use-Case
Diagrams)
Kullanım Durumu Şemaları (Use-Case
Diagrams)
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.
Etkinlik Şemaları (Activity Diagrams)
 Başlangıç:
 Akışlar:

 İşlemler:
giriş mesajı
 Çatallanma ve Birleştirme:
 Kararlar:
 Bitiş:
Etkinlik Şemaları (Activity Diagrams)
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.
Sıra Şemaları (Sequence Diagram)
İş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.
İş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.
İşbirliği Şemaları (Collaboration
Diagrams)
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.
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.
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.
Sınıf Şemaları (Class Diagram)
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.
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.
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.
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.
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.
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.
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ı.