Yazılım Mimarisi ve Tasarımı

1. Ders

Soyutlama;

 Bir şeyin en önemli, temel veya ayırt edici taraflarını öne çıkarıp daha az önemli, önemsiz veya
saptırıcı ayrıntılarını bastıran veya görmezden gelen herhangi bir model.
 Ortak noktaları vurgulamak için farklılıkların kaldırılmasının neticesi.
 Bir varlığın onu diğerlerinden ayıran temel özellikleridir.
 Bakanın perspektifine göre bir sınır çizer
 Somut bir görünüm olmayıp bir şeyin mükemmel özünü ortaya koyar.
 Soyutlama bir varlığın onu diğer tüm varlık türlerinden ayıran temel özelliklerin odaklanarak
karmaşıklığı yönetmemizi sağlar.
 Bir soyutlama , alana ve perspektife bağlıdır.
o Bir bağlamda önemli olan başka bir bağlamda önemsiz olabilir
 Objected Oriented, soyutlamalar kullanarak, problem alanından sistemimizi modellememize
izin verir.
 Öncelikli hedefi çıkarım/istidlal yapılarının (inference structures) geliştirilmesi olan matematik
için
o enformasyonu/malumatı dikkate almamaktır.
 Öncelikli hedefi etkileşim kalıplarının (interaction patterns) geliştirilmesi olan bilgisayar
biliminde ise
o Enformasyonu kapamadır(örtmedir) (information hiding).
 Bilgisayar biliminin temel faaliyeti yazılım üretimidir ve bu faaliyet, esas olarak çıkarım
yapılarının yaratılması ve kullanılmasıyla değil, etkileşimin modellemesiyle kendini gösterir
 Her yazılım sistemi, ister bir işletim sistemi, ister birden fazla makineye dağıtılmış bir ağ
sistemi veya tek kullanıcılı bir programı olsun, çeşitli şekillerde görevler, iş parçacıkları veya
süreçler olarak adlandırılan varlıkların dikkatlice düzenlenmiş bir etkileşimidir.
 Özetle, soyutlama felsefede, matematikte ve mantıkta belirli özellikleri göz ardı ederek
özgeliği (mahsusa) ortadan kaldırma süreci olarak nitelendirilmiştir
 Soyutlama
o Karmaşıklığı, bir varlığı, onu diğer tüm varlıklardan ayıran en temel özelliklerine
odaklanarak yönetmektir.
 Büyük yazılım sistemlerinin tasarımı ve onaylanmasındaki kilit sorun,
o Herhangi bir zaman diliminde dikkate alınması gereken karmaşıklık veya ayrıntı
miktarını azaltmaktır.
 İki yaygı nve etkili çözüm yönetmi
o Ayrıştırma ve
o Soyutlama.
 Ayrıştırma:
o Bir görevi, onu iki veya daha fazla ayrılabilir alt göreve bölerek ayrıştırır.
o Ne yazık ki, birçok sorun için ayrılabilir alt görevler, bütünüyle çekip çevrilme
bakımından hala çok karmaşıktır.
 Soyutlama:
o Bir sorunun karmaşıklığı soyutlama yoluyla azaltılabilir.
 o Soyutlama, bir nesnenin veya olayın niteliklerinden, belirli bir bağlamda ilgili olanları
olmayanlardan ayırmak için bir mekanizma sağlayarak, herhangi bir zamanda
anlaşılması gereken ayrıntı miktarını azaltmaya hizmet eder.
 Soyutlama, bir modülün amacını uygulamasından ayırır.
 Modülerlik, bir çözümü modüllere ayırır;
o soyutlama, bir programlama dilinde uygulamadan önce her modülü açıkça belirtir.
 Soyutlama, insanlar olarak karmaşıklıkla başa çıkmanın temel yollarından birilin
 Dahi Diikstra ve Hoare Şunu Öneriyor:
o "Soyutlama,gerçek dünyadaki belirli nesneler, durumlar veya süreçler arasındaki
benzerliklerin tanınmasından ve bu benzerliklere yoğunlaşma ve şimdilik farklılıkları
görmezden gelme kararından kaynaklanır" [42].
 Shaw bir soyutlamayı şöyle tanımlar:
o "Sistemin,bazı ayrıntılarını vEya özelliklerini vurgularken diğerlerini bastıran bir
sistemin basitleştirilmiş bir açıklaması veya şartnamesi. İyi bir soyutlama, okuyucu
veya kullanıcı için önemli olan ayrıntıları vurgulayan ve en azından Şu an için önemsiz
veya dikkat dağıtıcı ayrıntıların bastıran bir soyutlamadır "[43].
 Berzins,Gray ve Naumann Şunu ileri sürüyor:
o "Bir kavram, ancak, sonunda onu gerçekleştirmek mekanizmadan için kullanılacak
bağımsız olarak tanımlanabildiği, anlaşılabildiği ve analiz edilebildiği takdirde bir
soyutlama olarak nitelendirilir” [44].
 Karmaşıklığın azaltılması
o - kullanıcılar ve uygulayıcılar için bir sorun [5] ve yazılım mühendisliğinde Önemli bir
hedef—
 karmaşık bir kavramı veya sistemi tanımlamak için bir dizi bağımsız soyutlama oluşturarak
ilerletilebilir [8, 13]
 soyutlamaların özü belirli bir bağlamla ilgili bilgileri korumak ve bu bağlamla ilgisi olmayan
bilgileri unutmaktır.
 Soyut bir veri yapısı, çeşitli alternatiflerle çalışma yapmaya izin vermek için gerekli esnekliği
sağlar.
 Soyutlama ve sarmalama tamamlatıcı kavramlardır.
o Soyutlama bir nesnenin gözlemlenebilir davranışına odaklanırken
o Sarmalama bu davranışa yol açan uygulamaya odaklanır.
 Soyutlama "insanların ne yaptıklarına dair düşünmelerine yardımcı olurken"
 Sarmalama "program değişikliklerinin sınırlı çabayla güvenilir bir şekilde yapılmasına izin
verir" [5 1]
 Sarmalama, farklı soyutlamalar arasında açık engeller sağlar ve böylece ilgilerin açık bir
şekilde ayrılmasına götürür.
 Soyutlama Paradigmasını Neden Seçiyoruz?
o I. Karmaşıklığın azaltılması
 - kullanıcılar ve uygulayıcılar için bir sorun [5] ve yazılım mühendisliğinde
önemli bir hedef — karmaşık bir kavramı veya sistemi tanımlamak için bir dizi
bağımsız soyutlama oluşturarak ilerletilebilir [8, 1 3]
o 2. Örtme
 Soyutlama, bir alt sistemin yalnızca dış arayüzlerdeki davranış yönlerini
görünür bırakarak iç işleyişini gizlemek için kullanılabilir.
o 3. Maliyeti Düşürme
  Değişiklikler, aksi takdirde olacaklarından daha az modülü etkilediğinden,
bağımsız soyutlamaların yazılım onarımı ve geliştirmesi üzerinde etkisi vardır
o
o
o 4. Soyutlamaların doğruluk ispantında da yeri vardır
 Bunlar pratik büyüklükteki sistemler için yönetilebilir iseler karmaşık bir
ispatın parçalarını ayırmak için soyutlamalardan faydalanmalıdır [20].
 Veri soyutlama, onları nasıl uyguladığınıza değil, işlemlerin veri toplama ile ne yaptığına
odaklanır.
 Çözümün diğer modülleri hangi işlemleri gerçekleştirebileceklerini "bilirler", ancak verilerin
nasıl saklandığını veya işlemlerin nasıl gerçekleştirildiğini "bilmezler”.
 Tüm soyutlamaların statik ve dinamik özellikleri vardır.
 Örneğin, bir dosya nesnesi, belirli bir bellek aygıtında belirli bir yer kaplar; bir adı ve içeriği var.
Bunların hepsi statik özelliklerdir.

2. Ders

Sınıflandırma;

 Sınıflandırma, bilgiyi düzenIeme aracıdır.

 Nesne esaslı tasarımda
o şeyler arasındaki ayniyeti (sameness) tanımayı, anahtar soyutlamalar ve
mekanizmalar içindeki ortaklığı meydana çıkarmamızı sağlar.

Uygun Sınıflandırmanın Önemi

 Sınıfların ve nesnelerin tanımlanması nesne esaslı analiz ve tasarımın çetin bir parçasıdır.
 Tanımlama hem keşif hem de icar içerir.
 Keşif yoluyla, problem alanımızın kelime dağarcığını oluşturan anahtar
o soyutlamaları ve mekanizmaları tanırız.[l]
 İcat(buluş) yoluyla, nesnelerin işbirliği yapışını belirleyen
o o yeni mekanizmaların yanı sıra genelleştirilmiş soyutlamalar tasarlarız.[l]
 Sınıflandırma temelde ayniyeti (sameness) bulma sorunudur.
o Ortak bir yapı veya
o Ortak bir davranış
 Bu tür sınıflandırmalar.
o Gözlemlerin insan tarafından anlaşılması ve ardından bilimsel bir teorinin
geliştirilmesini kolaylaştırır.
 Sınıflandırma bize nasıl yardım eder:
o sınıflar arasında
 genelleştirme, özelleştirme ve toplama hiyerarşilerini belirlemeye.
o Nesneler arasındaki
 ortak etkileşim kalıplarını tanıyarak, uygulamanın ruhu olarak hizmet eden
mekanizmaları icat etmeye.
 Sınıflandırma,
o Modülleştirme hakkında karar vermemizde de bize rehberlik eder.
 Bu bildirimler arasında bulduğumuz aynılıklara bağlı olarak
o belirli sınıfları ve nesneleri
 
 aynı modülde veya farklı modüllerde bir araya getirmeyi seçebiliriz.
o Coupling ve cohesion aynı zamanda bir tür aynılığı gösterir.
 Sınıflandırma, islemlerin
o işlemcilere tahsis edilmesinde de rol oynar.
 Paketleme, performans veya güvenilirlik ilgisine bağlı olarak
o belirli süreçleri aynı işlemcide veya farklı işlemcilerde bir araya getirir.

Sınıflandırmanın Artımlı ve Tekrarlı Doğası

 Sınıflandırmanın artımlı ve yinelemeli doğası, sınıf ve nesne hiyerarşilerinin oluşturulmasını

doğrudan etkiler.
 Bu deneyime dayanarak, mevcut alt sınıflardan (türetme, derivation) yeni alt sınıflar
oluşturmaya karar verebiliriz.
 Büyük bir sınıfı birkaç küçük sınıfa bölebiliriz (factorization),
 veya daha küçük olanları birleştirerek (composition) daha büyük bir sınıf oluştururuz.
 Bazen, daha önce fark edilmeyen ortak noktaları bile keşfedebilir ve yeni bir sınıf (soyutlama,
abstraction) tasarlamaya başlayabiliriz.

Sınıflandırmanın Zorluğu

 Bazı sınıflandırmalar diğerlerinden daha iyi olsa da, "mükemmel” sınıflandırma diye bir şey
yoktur.
 Herhangi bir sınıflandırma, sınıflandırmayı yapan gözlemcinin bakış açısına göredir.
 Akıllı sınıflandırma, muazzam miktarda yaratıcı içgörü / kavrayış gerektirir.

Sınıfları ve Nesneleri Tanımlama

 Klasik ve modern yaklaşımlar

o Tarihsel olarak sınıflandırmaya yalnızca üç genel yaklaşım olmuştur
 Klasik Sınıflandırma , Kavramsal Kümeleme, Prototip Teorisi
 Klasik Sınıflandırma
o Özellikler ve etkiler
 nesneler arasında aynîlik için ölçü olarak ilgili özellikleri kullanır.
 bu yaklaşım her zaman tatmin edici değildir:
 Herhangi bir doğal kategori için kategoride olmayan tüm örnekleri dışarıda
bırakan ve kategorideki tüm örnekleri içeren bir özellik listesi oluşturmak
pratik olarak imkansız görünmektedir.
 Kavramsal Kümeleme
o Bilginin nasıl temsil edildiğini açıklama girişimlerinden türer.
o Nesnelerin ihtimali bir kümelenmesinden fazlasını temsil eder.
o Nesnelerin değişen uygunluk derecelerinde bir veya daha fazla gruba ait olabileceği
bulanık(çok değerli ) küme teorisi ile yakından ilişkilidir.
o Kavramsam kümeleme “en uygun”a odaklanarak mutlak sınıflandırma hükmü verir.
o Bir alan hakkında daha fazla bilgi, akıllı bir sınıflandırma elde etmeyi kolaylaştırır.
 Prototip Teorisi
o Bir nesneler sınıfı, prototipik bir nesne tarafından temsil edilir ve bir nesne, ancak ve
ancak bu prototipe önemli yönden benziyorsa, bu sınıfın üyesi olarak kabul edilir
Software Design

 Tasarım, hem Mimari, Bileşenler, Arayüzler ve Bir sistem veya bileşenin karakteristiklerini
tanımlama süreci olarak hem de bu sürecin bir sonucu olarak tanımlanır.
 Yazalım tasarımı
o Bir yazılım inşası için temel hizmeti görecek
 İç yapı tarifini elde etmek üzere yazılım talep ve ihtiyaçlarının çözümlendiği
bir yazılım mühendisliği ömür aşamaları faaliyetleridir.
 Yazılım tasarımı(sonuç)
o Yazılım mimarisini,
 Yazılımın bileşenlerine nasıl ayrıştırıldığını ve kurulduğu ve bu bileşenler
arasındaki arayüzleri tasvir eder.
o Ayrıca
 Bileşenlerini , inşasını mümkün kılacak ayrıntıda tasvir etmelidir.
 Yazılım tasarımı yazılım geliştirmede önemli bir rol oynar:
o yazılım mühendisleri yazılım tasarımı esnasında hayata geçirilecek çözümün taslağını
biçimlendiren çeşitli modeller üretirler
 Bu modelleri, çeşitli talep ve ihtiyaçları yerine getirmemize imkan verip vermediğini tespit
etmek için çözümleyip irdeleyebiliriz.
o Ayrıca alternatif çözümleri ve ödesimleri sınayabilir ve irdeleyebilir..
 Nihayet, sonuç modelleri İnşa ve testin girdisi ve başlangıç noktası olarak
kullanmaya ilaveten sistemi verify ve validate etmek gibi sonraki geliştirme
faaliyetlerini planlamak için kullanabiliriz.


 ISO 12207’e göre;
o Yazılım tasarımı
 Yazılım talep ve ihtiyaçları analizi ve yazılım inşası arasında denk düşen iki
faaliyeti içerir:
 Yazılım mimarisi tasarımı
 Yazılım detaylı tasarımı
o Yazılım mimari tasarımı
 Bazen üst düzey tasarım diye de adlandırılır
 Yazılımın üst düzey yapısı ve düzenlemesini geliştirir ve çeşitli bileşenlerini
tanımlar
o Yazılım detaylı tasarımı
 Her bileşeni, inşasını kolaylaştıracak yeterli ayrıntıda tanımlar.
 Yazılım tasarımı temelleri
o Genel yasarım Kavramları : Problem çözme
o Yazılım tasarımı bağlamı : SDLC
o Yazılım Tasarım Süreci : Mimari, Detay
 Yazılım Tasarımında Temel Meseleler :
o Eşzamanlılık
o yazılımı parçalara ayırmakla ilgilidir :
 süreçler, görevler ve İplikler (threads) ve
o İlintili meselelerle ilgilenmektir:
 yeterlik, atomiklik, senkronizasyon ve planlama
 o Görünümün Kontrolü ve İdaresi
 Verilerin nasıl organize edileceği ve akışın nasıl kontrol edileceğinin
o yanı sıra
 tepkisel ve geçici olayların nasıl çekip çevrileceği ile ilgilidir.
o Veri kalıcılığı
 Uzun ömürlü verileri nasıl çekip çevirileceği ile ilgilenir.
o Bileşenlerin Dağıtımı
 yazılımın donanıma nasıl dağıtılacağı (bilgisayar donanımı ve ağ donanımı
dahil), bileşenlerin nasıl iletişim kurduğu ve heterojen yazılımlarla başa
çıkmak için ara katman yazılımının nasıl kullanılabileceği ile ilgilenir.
o Hata Ayırmayı Çe
o kip Çevirme ve Hata Toleransı Hataların
 nasıl önleneceği, nasıl katlanılabileceği süreç hataları ve o istisnaî koşullarla
ile ilgilidir.
o Etkileşim ve Sunum
o Güvenlik

Kalite Analizi ve İrdelenmesi

 Kalite Nitelikleri
o Kalite Nitelikleri
o Kalite nitelikleri arasında ilginç bir ayrım vardır:
o çalışma zamanında fark edilebilir(örneğin performans, güvenlik, kullanılabilirlik,
işlevsellik), çalışma zamanında fark edilemeyenler(örneğin, değiştirilebilirlik ,
taşınabilirlik, yeniden kullanılabilirlik, test edilebilirlik) ve mimarinin kendine özgü
nitelikleriyle ilgili olanlar (örneğin kavramsal bütünlük, doğruluk, tamlık)
 çeşitli araç ve teknikler yazılım tasarım kalitesinin analiz edilmesine ve değerlendirilmesine
yardımcı olabilir.
 Yazılım tasarım incelemeleri:
o Tasarım eserlerinin kalitesini belirlemek için resmi ve gayriresmi tekniler
o Senaryoya dayalı teknikler;
o Talep ve ihtiyaçların -requirements- takibi.
 Yazılım tasarımı incelemeri aynı zamanda güvenliği de değerlendirebilir.
 Kurulum çalıştırma ve kullanıma yönelik yardımlar
3. Ders

Modülerlik

 Cohesive (sıkı ve türdeş) bir modülü parçalamak coupling’i (bağlılık) arttırır. Okunurluğu
azaltır.
 Bir dizi standart parça veya ayrı birimden daha girift bir yapı inşa edilmesi
 Mantıklı bir gruplandırma var. Nesne esaslı çalışmalarda “class”
 Yapısal veya işlevsel çalışmalarda “function”
 Bir program modülünün “model”i üç parçadan oluşur:
o İnput
o Process
o Output
 Karmaşıklık (girift)liği etkileyen faktörler
o Modül büyüklüğü
 o Programın modüller arasındaki ilişki
o Modülün iç unsurları arasındaki ilişki
 Modüller arasında veri geçişi,
o Eğer modüller arasında parametre vasıtaysıyla ise AÇIK VERİ İRTİBATI
o Eğer modüller aynı veriyi referans alıyorsa ÖRTÜK VERİ İRTİBARI var demektir.

Veri irtibatı Karmaşıklığı

 Modüller arasında irtibatın giriftliği kontrol edilmeli ve azaltılmalıdır.

 Bu irtibatın irdelenmesi için iki temel ölçüt vardır:
o Coupling (bağlılık)
o Cohesion (sıkılık ve türdeşlik)

Karmaşıklık Kontrodlü

 Parçala ve Yönet taktiği,

o Giriftliği kontrol etmek ve
o Anlaşılabilirliği artırmak için en iyi yoldur.
 Giriftlik/Karmaşıklık/Complexity
 Modüller bağımsız ofiadıkça ve
o Aralarındaki etkileşim sınırlandırılmadıkça kontrol edilemez.

Bağımsızlık ölçüsü

 Modüller arası bağımlılık COUPLİNG

 Modül ögeleri arasında ilişki gücü COHESİON

Coupling’i Etkileyen unsurlar

 Modüller arasında geçen veri elemanı sayısı

 Modüller arasında geçen kontrol verisi miktarı
 Modüller tarafından kullanılan ortak global veri elemanlarının sayısı

Coupling Türleri

 Data coupling (veri bağı)

 Stamp coupling (damga bağı)
 Control coupling (kontrol bağı)
 Common coupling (ortak bağ)
 Content coupling (içerik bağı)

Data Copuling (Veri Bağı)

 İki modül birbiriyle doğrudan bir parametre olarak geçilen bir değişken veya dizin (tablo)
aracılığıyla iletişim kurarlarsa, iki modül veri bağlıdır.
 Veriler, program kontrol amaçları için değil problem ilişkili işlemede kullanılır.

Stamp Coupliing (Damga Bağı)

 İki modül bileşik veri öğesi (örneğin,kayıt) aracılığıyla iletişim kurarlarsa, iki modül damga
bağlıdır.
  Bileşik veri Öğesi, bir modül tarafından kendisine iletilse bile kullanılmayan veri parçalarını
içerebilir.

Control Coupling (Kontrol Bağı)

 Bir modülden gelen veriler, diğerinin talimat icra sırasını yönlendirmek için kullanılıyorsa, iki
modül kontrol bağlıdır (örneğin, bir modülde bir "flag” başka bir modülde karşılaştırma için
kullanılır).

Common Coupling (Ortak Bağ)

 İki modül aynı global veri alanlarını paylaşıyorlarsa iki modül ortak bağlıdır.

Content Coupling (İçerik bağı)

 Bir modül başka bir atıfta bulunuyorsa veya başka bir modülü değiştiriyorsa (örneğin, bir
modül kodundan başka bir modüle dallanma veya düşme) iki modül içerik bağlıdır.

DeCoupling Kılavuzu

 Modülleri bağımsız yapma çalışması.

 En iyi, program tasarımı esnasında yapılır.
 Data coupling azaltmak için:
o Sadece gerekli olan veriyi geçir.
 Stamp Coupling azaltmak için:
o Bileşik veri elemanları sadece kullanılacak verileri ihtiva etsin.
 Control Coupling azaltmak için:
o Mümkün olduğunca sayısını azalt.
 Çommon coupling azaltmak için:
o Ortak veri alanı kullanmaktan kaçın.
 Çontent coupling hepten kaldır.

Cohesion

 Cohesion ,bir modül içindeki öğelerin ne kadar güçlü bağa sahip olduğunu ölçer.
o Coincidental (tesadüfi), en zayıf ve en az arzu edilen seviyedir;
o Functional (işlevsel) ise en güçlü ve en arzu edilen düzeydir.
 Functional (işlevsel), Sequential(dayalı sıralı) Communicational (iletişimsel), Procedural (sıralı),
Temporal (geçici), Logical (mantıksal), Coincidental(tesadüfi)

Function (işlevsel)

 Bir modüldeki her Öğe, bir ve yalnızca bir işlevin gerekli ve temel bir parçasıdır.
 Modülün her parçası diğeriyle ilişkilidir ve modül, çalışması için gerekli olan her şeyi içerir.
 Örnek
o
o
o MODULE NETPAY,
CALCULATE GROSS.
CALCULATE TAXES.
CALCULATE NET PAY.
Sequential (Dayalı Sıralı)

 Bir modülün Öğeleri, bir işlemin çıktısının diğerinin girdisi olduğu işlemler dizisinin farklı
bölümlerinin İfasıyla ilişkilidir.
 Örnek.
o MODULE INVENTORYUPDATE
GET INVENTORY INPUT.
CONVERT INVENTORY INPUT.
UPDATE INVENTORY MASTER.

Communicational (İletişimsel)

 Bir modülün bütün unsurları aynı verileri kullanır.

 Örnek,
o MODULE PROCESS TRANSACTION
READ TRANSACTION.
EDIT TRANSACTION.
PROCESS TRANSACTION.

Procedural (sıralı)

 Bir modülün öğelerinin tümü bir prosedürün parçasıdır - belirli bir sırada atılması gereken
belirli bir adımlar dizisi.
 Örnek,
o MODULE LOOP
DO UNTIL NO MORE ORDERS.
READ ORDER
PR&CESS ORDER
END DO

Temporal (geçici)

 Bir modülün Öğeleri zaman bakımından ilişkilidir, ancak belirli bir sırada meydana gelmesi
veya aynı veriler üzerinde çalışması gerekmez.
 Bir modülün öğeleri zamanlama bağımlılıklarına dayalı bir ilişkidedir. Örneğin, birçok sistem,
sistem açılırken başlatılması gereken görünüşte ilgisiz şeylerin bir listesine sahiptir; bu farklı
görevler geçici olarak sıkı ve türdeştir.
 Örnek

o INITIALIZE.
 SET COUNTERS.
 ZERO OUT TABLES.
 OPEN FILES.

Logical (mantıksal)

 Bir modülün unsurlarının tümü, belirli bir eylem sınıfını gerçekleştirmeye yöneliktir.
  Modüller içindeki veriler mantıksal olarak ilişkilidir, işlevsel olarak değil.
 Örneğin, bilgileri metinden, serileştirilmiş nesnelerden veya akışlardan dönüştüren bir modül
düşünün, Eylemler birbiriyle ilişkilidir, ancak işlevler oldukça farklıdır.
 Örnek
o MODULE EDIT
EDIT TRANSACTION
EDIT MASTER
EDIT TERMINAL INPUT

Coincidental(tesadüfi)

 Bir modülün öğeleri. temelde herhangi bir ortak işlev. prosedür,veri veya herhangi başka bir
şeyle ilişkili değildir,
 Bir modüldeki Öğelerin, aynı kaynak dosyada olmaktan başka bir ilişkisi yoktur;
 Bu cohesionun en olumsuz biçimini temsil eder.
 Örnek,
o MODULEX
READ TRANSACTION.
PROCESS PRİNT ERROR.
READ OLD MASTER.
ZERO COUNTERS.
1. Functioanl (işlevsel) Tek işlev
2. Sequential Dayalı sıralı
3. Communicational (iletişimsel) Aynı veri
4. Procedural Adım adım sıralı
5. Temporal (geçici) Aynı zamanlı
6. Logical (mantıksal) Mantıksal ilişki var, işlevsel yok
7. Coincidental(tesadüfi) Ortak unsur yok

Cohesion

 Seviyeler arasındaki ölçek süreklidir, kesikli değildir;

 Çünkü herhangi iki seviyeyi ayıran keskin bir çizgi çizemeyiz.
 Ayrıca, cohesion niceliksel değil niteliksel bir ölçü olduğundan ölçek doğrusaldır.

Cohesion Türünün Tespiti

 Modülün işlevini tarif etmenin tek yolu bileşik bir cümle kullanmaksa, modül en büyük
ihtimalle "sequential”, ”communicational”, veya "Iogjçal” dır.
 2. Bir modülün işlevinin tarifi, "ilk", "sonraki,” "sonra” veya 'tümü” gibi zamana yönelik
kelimeler içeriyorsa, modül muhtemelen ”temporal” veya “procedural” cohesiona sahiptir
 Modülün işlevi, bir öğe sınıfı için (ör., tüm işlem türleri) bazı işlemleri gerçekleştirmek olarak
tarif edilirse, modül muhtemelen logical cohesiona sahiptir.
 Modülün işlevi "başlatma”, "temizleme” veya "yeniden düzenleme” olarak tarif edilebiliyorsa,
modülün temporal cohesion’ı vardır.

Kalite Nitelikler

 Kalite nitelikleri talep ve ihtiyaçları,

o Bir uygulamanın işlevsel talep ve ihtiyaçların nasıl karşılandığının birçok yüzünü
yakalayan işlevsel olmayan talep ve ihtiyaçların parçasıdır.
  Tasarım / Koşu / Sistem / Kullanıcı Nitelikleri

Tasarım Kaliteleri

 Kavramsal Bütünlük (Conceptual Integrity)

o Kavramsal bütünlük, genel tasarımın tutarlılığını, sıkılık ve türdeşliğini tanımlar. Bu,
bileşenlerin veya modüllerin tasarlanma yolunun yanı sıra kodlama tarzı ve değişken
adlandırma gibi faktörleri içerir.
 Müdahale Edilebilirlik (Bakım ve idamesi yapılabilirlik) (Maintainability)
o Sistemin ne derece kolaylıkla değiştirilebileceğidir. Bu değişiklikler,
 İşlevsellik eklendiği veya değiştirildiğinde, hataları düzeltildiğinde ve yeni iş
ihtiyaçları giderildiğinde, bileşenleri, hizmetleri, özellikleri ve arabirimleri
etkileyebilir
 Tekrar Kullanılabilirlik (Reusability)
o Bileşenlerin ve alt sistemlerin diğer uygulamalarda ve diğer senaryolarda kullanılma
müsaitliğini tanımlar. Tekrar kullanılabilirlik, bileşenlerin ikilenmesini ve ayrıca
devreye alınma süresini en aza indirir.

Koşu Kaliteleri

 Erişilebilirlik/Ulaşılabilirlik (Availability)
o Sistemin işlevsel ve çalışır durumda olduğu zaman nispetini tanımlar, Önceden
tanımlanmış bir süre boyunca sistemin toplam kapalı kalma süresinin yüzdesi olarak
ölçülebilir. Ulaşılabilirlik, sistem hatalarından, altyapı sorunlarından, kötü niyetli
saldırılardan ve sistem yükünden etkilenecektir.
 Failures
 MTBF
 Recoverabilit
 Replication
 Bir arada çalışabilirlik (Interoperability)
o Bir sistemin veya farklı sistemlerin, harici taraflarca yazılan ve çalıştırılan diğer harici
sistemlerle iletişim kurarak ve bilgi alışverişinde bulunarak başarılı bir şekilde
çalışabilmesidir. Bir arada çalışabilir bir sistem, bilgilerin harici olduğu kadar dahili
olarak değiştirilmesini ve yeniden kullanılmasını kolaylaştırır.
 Yönetilebilirlik (Manageability)
o İ
 Performans
o Belirli bir zaman aralığında herhangi bir eylemi gerçekleştirmek İçin bir sistemin tepki
verme gücünün bir göstergesidir.
 Gecikme(latency) veya througput olarak ölçülebilir.
 Gecikme, herhangi bir olaya tepki vermek için geçen süredir. Througput
(avarage, pick), belirli bir süre içinde gerçekleşen olay sayısıdır.
 Response Time (guaranteed, avarage)
 Deadlines (süre sonu)
 Güvenilirlik (Reliability)
 o Bir sistemin zaman içinde çalışır durumda kalma yeteneğidir. Güvenilirlik, bir sistemin
belirli bir zaman aralığında niyetlenilen işlevlerini yerine getirmede başarısız olmama
ihtimali olarak ölçülür.
 Ölçeklenebilirlik (Scalability)
o Ölçeklenebilirlik, sistemin, yükteki artışları sistem performansı etkilenmeden çekip
çevirmesi veya kolaylıkla genişletebilmesidir.
 Request Load
 Simutaneous Connections
 Datasize Deployment

 İntikal (Deployment)
o Bir uygulamayı gittikçe artan bir kullanıcı tabanına intikal ettirme veya değiştirme
çabası nasıl büyür?
o Bu, dağıtım, yapılandırma ve yeni sürümlerle güncelleme çabalarını içerecektir.
o İdeal çözüm, bir uygulamayı yeni bir kullanıcıya dinamik olarak intikal ettirip
yapılandırabilen, kayıt bilgilerini edinen otomatik mekanizmalardır.
 Güvenlik (Security)
o Güvenlik, bir sistemin tasarlanan kullanım dışında kötü niyetli veya kazara eylemleri
önleme, bilgi ifşasını veya kaybını önleme yeteneğidir.
o Güvenli bir sistem, varlıkları korumayı ve bilgilerin yetkisiz değiştirilmesini önlemeyi
amaçlar.
 Kimlik Doğrulama (Authentication): Uygulamalar, kullanıcılarının ve iletişim
kurdukları diğer uygulamaların kimliğini doğrulayabilir.
 Yetkilendirme (Authorization): Kimliği doğrulanmış kullanıcılar ve
uygulamalar, sistemin kaynaklarına tanımlı erişim haklarına sahiptir. Örneğin,
bazı kullanıcılar uygulamanın verilerine salt okudur erişime sahipken, diğerleri
okuma-yazma hakkına sahip olabilir.
 Kimliğin ispatlanmasının ardından kişiye bazı kaynaklara erişime izin
verecek anahtar veya şifre verilir.
 Gizlilik (Confidentiality): Yetkili varlıklar haricinde bilgileri anlaşılmaz kılar.
 Bütünlük (veri bütünlüğü) : Bu bir mesajın içeriğinin aktarım sırasında
değiştirilememesini sağlar.
 Verilerin oluşturduğu, iletildiği veya saklandığı haliyle yetkisiz bir
şekilde değiştirilmemiş olarak kalır.
 İnkâr edilememe (Nonrepudiation): Bir mesajı gönderenin teslim delili vardır
ve
alıcı, gönderenin kimliğinden emin olur. Bu, mesaj alışverişine katılımlarını
sonradan reddedemeyeceği anlamına gelir.

Sistem Kaliteleri

 Desteklenebilirlik (Supportability)
o Sistemin, düzgün çalışmadığı sorunları tespit etmek ve çözmek için yararlı bilgiyi
sağlama yeteneğidir
 Test Edilebilirlik (Testability)
 o Sistem ve bileşenleri için test kriterleri oluşturmanın ve kriterlerin karşılanıp
karşılanmadığını belirlemek için bu testleri gerçekleştirmenin ne kadar kolay
olduğunun bir ölçüsüdür
o İyi test edilebilirlik, bir sistemdeki arızaların zamanında ve etkili bir şekilde izole
edilebilmesini daha mümkün kılar.
 Kullanılabilirlik (Usability)
o Kullanılabilirlik, uygulamanın, sezgiye elverişliliği, yerelleştirilme ve küreselleştirilme
kolaylığı, engelli kullanıcılar için iyi erişim sağlayışı ve genel olarak İyi bir kullanıcı
tecrübesi sayesinde, kullanıcı ve/veya müşterinin talep ve ihtiyaçlarını ne çapta
karşıladığını tanımlar.
 Bütünleştirme (Entegrasyon)
o Bir uygulamanın daha geniş bir uygulama bağlamına yararlı bir şekilde dahil
edilebilmesinin kolaylığı ile ilgilidir
 Veri entegrasyonu
 API
 Veri Entegrasyonu (Integration/Data Integration)
o bir uygulamanın işlediği verileri diğer uygulamaların erişebileceği şekilde depolamayı
içerir.
o Bu, veri depolama için standart bir ilişkisel veri tabanı kullanmak kadar basit olabilir
veya verileri XML gibi bilinen bir biçime veya diğer uygulamaların alabileceği virgülle
ayrılmış bir metin dosyasına çıkarmak için mekanizmalar uygulamak kadar basit
olabilir.
o
o
o Veri entegrasyonuyla, verilerin diğer uygulamalar tarafından kullanılma (veya kötüye
kullanım) yolları, orijinal veri sahibinin neredeyse kontrolü dışındadır.
o Bunun nedeni, uygulama mantığının dayattığı veri bütünlüğü ve iş kurallarının
atlanmasıdır.
o Alternatif, birlikte çalışabilirliğin bir API aracılığıyla elde edilmesidir.
o Bu durumda, uygulamanın sahip olduğu ham veriler, verilere kontrollü harici erişimi
kolaylaştıran bir dizi işlevin arkasında gizlenir.
o Bu şekilde, API uygulamasında iş kuralları ve güvenlik uygulanabilir.
o Verilere erişmenin ve uygulama ile entegre olmanın tek yolu, sağlanan API'yi
kullanmaktır.
 Taşınabilirlik (Portability)
o Bir uygulama, geliştirildiğinden farklı bir yazılım / donanım platformunda kolaylıkla
yürütülebilir mi?
o Taşınabilirlik, uygulamayı gerçekleştirmek için kullanılan yazılım teknolojisi
tercihlerine ve üzerinde çalışması gereken platformların özelliklerine bağlıdır.
o Kolayca taşınabilir kod tabanları, uygulamanın geri kalanını etkilemeden
değiştirilebilen izole edilmiş ve küçük bir bileşen setinde kapsüllenmiş platform
bağımlılıklarına sahip olacaktır.
 Birlikte Çalışabilirlik (Interoperability)
o Birlikte çalışabilirlik,
 iki veya daha fazla sistemin belirli bir bağlamda, arayüzler aracılığıyla anlamlı
bilgi alışverişinde bulunma derecesine dairdir.
Yazılım Mimarisi Nedir

 Yazılım öğeleri, bunlar aralarındaki ilişkiler ve her ikisinin özelliklerince oluşturulan bir sistem
hakkında mantık yürütmek için gerekli yapılar kümesi
 Bir sistemin yazılım mimarisi bir sistem hakkında mantık yürütmek için gerekli olan ve yazılım
ögelerini, onların aralarındaki ilişkileri ve her ikisinin özelliklerini içeren yapılar kümesidir
 Bu tanım sistemin "erken” veya “büyük” tasarım kararlarından bahseden diğer tanımlarla
çelişir.
 Pek çok mimari karar erken ancak hepsi değil. (özellikle Çevik veya Spiral geliştirme
projelerinde)
 Erken alınan kararların çoğu mimarî değildir.
 Bir karara bakıp "esas” olup olmadığını söylemek zordur. Bazen bunu sadece zaman gösterir.
 Öte tanımlanması oldukça kolaydır ve sistem tasarımı için güçlü bir araç oluştururlar.
 Yapı bir ilişki tarafından bir arada tutulan unsurlar kümesidir. Tanımımızın ilk ve en belirgin
iması budur. Yazılım sistemleri bircok oluşur ve hiçbir yapı tek başına mimari olma iddiasında
değildir.
 Mimari yapıların üç önemli kategorisi vardır.
o Module
o Component and connector
o Allocation

Modül Yapıları (Module Structures)

 Bazı yapılar sistemleri ‘hayata geçirme birimleri'ne ayırır ki biz bunlara modül diyoruz.
 Modüllere bilirli hesaplamalı (Computational) sorumluluklar atanır ve programlama ekipleri
için iş atamalarıbıb/ödevlerinin temelini oluştıurur.
o (Team A works on the database, Team B works on the business rules, Team C works
on the user interface,etc.).
 Büyük projelerde, bu modüller alt ekiplere atamak üzere alt bölümlere ayrılır.
 Modül Yapıları statik yapılardır. Sistemin işlevlerinin bölünüp uygulama ekiplerine atanmasına
odaklanır.

Component And Connector Yapıları

 Dinamiktir. Sistemin işlevlerini yerine getirmek için çalışma esnasında öğelerin hangi yolla
birbiriyle etkileşimde bulunduğuna odaklanır.
 Runtime yapılara bileşen ve bağlayıcı (c&c) yapılar diyoruz
 Bizim kullanımımızda bir bileşen her zaman bir runtime varlıktır.

Allocation Yapılar

 Tahsis yapıları, yazılım yapılarını sistem ortamlarıyla (Örgüt ortamı, Geliştirme Ortamı,
Kurulum Ortamı, İcra Ortamı) örtüştürmeyi tanımlar

Bu akıl yürütme sistemin bazı “stakeholder”larca önemsene nir niteliği hakkında olmalıdır.

Bunlar aslında;
  Sistem tarafından sağlanan işlevsellik
 Arıza halinde sistemin erişilebiliriği/kullanılabilirliği
 Sistemde belirli değişiklikler yapmanın zorluğu
 Sistemin kullanıcı taleplerine cevap verme kabiliyeti

Mimari aslında bir soyutlamadır

 Bir mimari sistem hakkında mantık yürütmek için bir faydası olamayan unsurlara dair belirli
bilgileri bilhassa göz ardı eder.
 Bir mimari öğenin dışarısında hiçbir sonucu olmayan bilgileri atar.
 Bir mimari belirli ayrıntıları seçer ve diğerlerini bastırır.
 Öğelerin özel ayrıntıları -yalnızca iç uygulamayla ilgili ayrıntılar- mimari değildir.
 Sisteme öğeleri, nasıl düzenlendikleri, nasıl etkileşime girdikleri, nasıl bir araya getirildikleri,
sistem mantığımızı destekleyen özelliklerin neler oldığu açısından bakmamızı sağlar
 Bir soyutlama, karmaşıklığı uysallaştırmak için gereklidir.

Her sistem bir tür muhakemeyi desteklemek için öğeleri ve aralarındaki ilişkileri kapsar.

Davranış unsurların birbiriyle nasıl etkileşime girdiğini somutlaştırır ve bu açıkça mimari tanımının bir
parçasıdır.

Structures and Views

- Bir view , sistem stackholderları tarafından yazılan ve okunan şekliyle coherent bir mimari
unsurlar kümesinin temsilidir.
- Bir dizi öğenin ve aralarındaki ilişkilerin temsilini ihtiva eder.
- Bir yapı yazılımda ve donanımında var olduğu haliyle bir unsurlar kümesidir.
- Kısaca bir yapının temsilidir.
- Mimarlar yapıyı tasarlar. Bu yapının “view”larını dökümante ederler.

Modül Yapıları

- Sistemin inşa edilmesi ve tedarik edilmesi gereken bir dizi kod veya veri birimleri olarak nasıl
yapılandırılacağına ilişkin kararları içerir
- Herhangi bir modül yapısında öğeler bir tür modüllerdir.
- Modüller tayin edilmiş işlevsel sorumluluk alanlarıdır;
- Modül yapıları aşağıdakilere cevap verir;
o Her bir modüle atanan birincil işlevsel sorumluluk ?
o Bir modülün başka hangi yazılım öğelerini kullanmasına izin verilmektedir?
o Başka hangi yazılımı gerçekte kullanır ve bunlara bağlıdır?
o Hangi modülleri diğer modüllerle genelleştirme veya özelleştirme yoluyla
irtibatlandırılır?
-
-
- Bileşen ve bağlayan yapıları sistemin,
o Koşu davranışı ve etkileşimlerine sahip bir öğeler kümesi olarak nasıl
yapılandırılacağına ilişkin kararlar içerir.
o Öğeler,
 Hizmetler, eşler, istemciler, sunucular, filtreler veya diğer birçok koşu öğesi
türü gibi runtime bileşenleridir.
o Bağlayanlar,
  Çağrı dönüşü, süreç senkronazisyon operatörleri, kanallar ve sair gibi
bileşenler iletişim araçlarıdır.
- Bileşen ve bağlayan görünümleri aşağıdakileri cevaplar
o Başlıca yürütme bile bileşenleri nelerdir ve çalıştırılırken nasıl etkileşirler?
o Başlıca paylaşılan veri depoları nelerdir?
o Sistemin paylaşılan veri depoları nelerdir?
o Veriler sistemde nasıl ilerler?
o Sistemin hangi bölümleri paralel olarak çalışabilir?
o Sistemin yapısı yürürken değişebilir mi, değişirse nasıl değişir?
- Bileşen ve bağlayan görünümleri sistemin, runtime performansı, güvenlik, erişilebilirlik ve
dahası hakkında soru sormak için hayati önemdedir.
- Tahsis yapıları yazılım öğeleri ile yazılımın oluşturduğu ve yürütüldüğü bir veya daha fazla
harici ortamdaki ögeler arasındaki ilişkiyi gösterir.
- Tahsis görünümleri aşağıdaki sorulara cevap verir.
o Her bir yazılım ögesi hangi işlemci üzerinde çalışır?
o Geliştirme, test etme ve sistemin inşası sırasında her öge hangi dizinlerde veya
dosyalarda depolanır?
o Geliştirme ekiplerine verilen her bir yazılım ögesi ödevi nedir?
- Yapılar, sahip oldukarı analitik ve mühendislik gücü nedeniyle yazılım mimarisine bakış
açımızda önemli bir rol oynamaktadır.
- Her yapı ilgili kalite özelliklerinden bazıları hakkında mantık yürütmek için bir perspektif sağlar
- Örneğin:
o Hangi modüllerin diğer hangi modülleri kullandığını içeren modül yapısı bir sistemin
genişletilebilmesi veya daraltılmasının kolaylığına sıkı sıkıya bağlıdır. (Modül)
o Paralelliği sistem bünyesinde barındıran eş anlılık yapısı, bir sistemin kilitlenme ve
performans darboğazlarından kurtarılma kolaylığına sıkı sıkıya bağlıdır.
(Concurrency/Eşanlılık)
o İntikal yapısı performans erişilebilirlik ve güvenlik hedeflerine ulaşılmasına sıkı sıkıya
bağlıdır (Deployment structure/İntikal)
- Ayrıştırma yapısı
o Birimleri “bir-alt modülüdür” ilişkisi ile birbiriyle irtibatlı modüllerdir.
o Modüllerin
 Kolayca anlaşabilecek kadar daha küçük modüllere tekrarlı olarak nasıl
ayrıştırıldığını gösterir.
o Ayrıştırma yapısı, büyük ölçüde, olası değişikliklerin yerelleştirilmesini temin ederek
sistemin değiştirilebildiğini belirler
o Bu yapı genellikle gerliştirme projesinin dökümantasyon yapısı proje entegrasyonu ve
test planlarını ihtiva eden organizyonu için temel olarak kullanır.
o Bu yapıdaki birimler, “segment” veya “alt sistem” gibi kuruluşa has adlara sahip olma
eğilimdedir.
- Uses(Kullanır) yapıları
o Buradaki birimler aynı zamanda modüller belki de sınıflardır.
o Bu birimler bağımlılığın özel bir biçimi olan kullanır ilişkisi ile irtibatlıdır.
o İki yazılımdan birinden, birinin doğruluğu, diğerinin çalışan sürünün(bir saplamanın
aksine) doğruluğunu gerektiriyorsa, biri diğerini kullanıyor demektir.
o Bu yapı, işlevsellik eklenebilecek veya faydalı işlevsel alt kümeler çıkarsanabilecek
sistemler yapabilmek için kullanılır.
 o Bir sistemin bir alt kümesini kolayca oluşturma yeteneği, artırımlı geliştirmeye izin
verir.
- Tabaka (Layer) Yapısı
o Bu yapıdaki modüllere tabakalar adı verilir.
o Bir tabaka, yönetilen bir arabirim vasıtasıyla sıkı ve türdeş bir hizmet kümesi sağlayan
soyut bir “sanal makine”dir.
o Tabakaların diğer tabakalar; sıkı bir yönetim tarzıyla kullanmasına izin verilir
 Katı tabakalı sistemlerde bir tabakanın sadece tek bir başka tabaka
kullanmasına izin verilir.
o Bu yapı bir sisteme; taşınabilirlik, yani dayandığı bilgisayar zeminini taşıma yeteneği
verir.
- Sınıf (Class/Genelleştirme) Yapısı
o Bu yapıdaki modüllere sınıflar denir
o İlişkisi; “-den miras” veya “-in bir oluşudur”
o Bu yapı
 Benzer davranış veya yetenek hakkında muhakeme yürütmeyi destekler
o Sınıf yapısı, birine
 Yeniden kullanım ve işlevselliğin artırımlı eklenişi üzerine akıl yürütme izni
verir.
o Nesneye yönelik analiz ve tasarım sürecini takip eden bir projede eğer herhangi bir
belge mevcutsa o genellikle bu yapıdır
- Veri Modeli (Data Model)
o Statik bilgi yapısını, veri varlıkları ve ilişkileri açısından tarif eder.
 Mesela bir bankacılık sisteminde varlıklar tipik olarak Hesap, Müşteri ve
krediyi içerir.
 hesap, hesap numarası tür, durum ve cari bakiye gibi çeşitli niteliklere
sahiptir.
- Tüm bileşen ve bağlayan yapılarıdaki ilişki;
o Bileşen ve bağlayanların birbirine nasıl bağladığıını gösteren ektir.
- Bağlatanlar,”çağırır” gibi aşina yapılar olabilir.
- Hizmet yapısı
o Birimler, SOAP (simple object Access protocol) gibi hizmet koordinasyon
mekanizmaları sayesinde bir arada çalışan servislerdir.
o Hizmet yapısı,
 Anonim ve birbirinden bağımsız olarak geliştirilmiş olabilcek bileşenlerden
oluşan bir sistem mühendisliğine yardımcı olur.
- Eşanlılık yapısı
o Bu yapı, paralellik fırsatlarını ve kaynak çekişmesinin ortaya çıkabileceği verileri tespit
etmeye yardımcı olur
o Birimler bileşenlerdir. Bağlayanlar onların iletişim mekanizmalarıdır. Bileşenler
mantıksal silsilede düzenlenmiştir.
- İntikal (Deployment)
o İntikal yapısı yazılımın donanımı işleme ve iletişim ögelerine nasıl atandığını gösterir.
o Ögeler yazılım ögeleri(genellikle C&C görünümünden bir süre.),donanım varlıkları ve
iletişim yollarıdır.
- Hayata geirme (Implementation)
 o Yazılım ögelerinin, sistemin geliştirme, birleştirme veya yapılandırma kontrol
ortamlarındaki dosya yapılarıyla nasıl örtüştürüldüğünü gösterir.
o Bu geliştirme faaliyetinin yönetimi ve inşa süreçleri için hayatidir.
- İş atama yapısı
o Bu yapı, modülleri hayata geçirme ve birleştirme sorumluluğunu onu yapacak
ekiplere yükler.
o Bir iş atama yapısının mimarinin bir parçası olması işi kimin yapacağına ilişkim kararın
mimari ve idari sonuçları olduğunu açıkça ortaya koymaktadır.
o Mimar, her ekip için gerektridiği uzmanlığı bilecektir.
o Bu yapı aynı zamanda ekipler arasındaki ana iletişim yollarını da belirleyecektir.

- Yapıların birbirleriyle ilişkilendirilmesi

o Bir yapının unsurları, diğer yapıların unsurlarıyla ilişkili olacaktır ve bu ilişkiler
hakkında mantık yürütmeye ihtiyacımız vardır.
 Bir ayrıştırma yapısındaki bir modül, bileşen ve bağlayan yapılarından biri,
birinin bir parçası veya bir bileşenin birkaç bileşeni ve bağlayanı olarak
belirebilir.
o Genel olarak yapılar arasındaki örtüşmeler çoğa çoktur.

Bakış Açıları ve Görünümler (Viewpoints and Views)

- Stakeholders sistemi oluşturduğumuz kişilerdir.

- Bir mimar olarak rolünüzün önemli bir parçası, onların karmaşık, örtüşen ve çoğu zaman
çatışan ihtiyaçlarını karşılayan bir mimari yaratmak için 'Paydaşlar' ile nasıl çalışılacağını
bilmektir.
- Viewpoints(and views) endişelerin ayrılması ilkesine dayalı olarak mimari tanımlama sürecini
ve mimari tanımlamayı yapılandırmaya yönelik bir yaklaşımdır.
- Viewpoints belirli bir dizi görüşle açıklanan, bir mimarinin oluşturulmasına rehberlik edecek
kanıtlanmış mimari bilgiyi içerir (her görünüm, kılavuzun belirli bir bakış açısına
uygulanmasının sonucudur)
- Mimari sorular:
o Mimarinizin ana işlevsel unsurları nelerdir?
o Bu unsurlar birbirleriyle ve dış dünyayla nasıl etkileşime girecekler?
o Hangi bilgiler yönetilecek saklanacak ve sunulacak?
o Bu işlevsel ve bilgi enformasyonal unsurlarının desteklenmesi için hangi fiziksel
donanım veya yazılım unsurları gerekli olacaktır?
o Hangi operasyonel özellikler ve yetenekler sağlanacaktır?
o Hangi geliştirme, test destekleme ve çalışma ortamları sağlanacaktır?
- Bütün bir soruları tek bir mimari görünümde sağlayamazsınız. Bundan kaçınmamız lazım
- Böyle bir eğilim herhangi bir ‘stakeholder’a yetersiz kalacaktır.

Functional/Logical Viewpoints

- Sistemin işlevsel yapısının mantıksal bir gösterimidir.

- Sistemin; işlevsel unsurlarını, sorumluluklarını, arayüzlerini ve etkileşimlerini tanımlar.
 - İşlevsel bakış açısında birçok mimari tasarımın temel taşı genellikle stakeholderların okunması
için bir tanımlamayı içerir.
- Bilgi yapısı, eşzamanlılık yapısı, dağıtım yapısı gibi diğer benzer yapıların şeklini yönlendirir.
- Bir sistemin değişme, güvence altına alma, çalışma sırasındaki performans yeteneği gibi kalite
unsurlarında da önemli etkisi var.

Informational Viewpoints

- Mimarinin nasıl olduğunu anlatır; bilgileri saklar, işler, yönetir ve dağıtır.

- Bilgisayar sisteminin en önemli amacı informasyonu herhangi bir form içerisinde manipüle
etme yeteneğidir.
- Bu analizin amacı ise içerik, yapı, sahiplik, gecikme referans ve veri geçişi hakkındaki büyük
soruları yanıtlamaktadır.

Process Viewpoint

- Process yürütülebilir bir birim oluşturam işlerin görevlerin gruplandırılmasıdır.

- Süreçler, process mimarisinin taktiksel olarak kontrol edilebileceği seviyeyi temsil eder.
(başlatıldı, kurtarıldı, yeniden yapılandırıldı ve kapatıldı)
- Ayrıca, işlem yükünün daha fazla dağıtılması veya daha iyi kullanılabilirlik için işlemler
çoğaltılabilir.
- Yazılım bir dizi bağımsız göreve bölünmüştür.
- görev, tek bir işlem düğümünde ayrı ayrı planlanabilen ayrı bir kontrol iş parçacığıdır.
- Sistemin eşzamanlılık yapısını açıklar ve eş zamanlı olarak bunun nasıl koordine edildiğini ve
kontrol edildiğini açıkça tanımlamak için işlevsel öğeyi eşzamanlılık birimleriyle eşleştirir.
- Bu, sistemin kullanacağı süreç ve iş parçacığı yapılarını ve bunların çalışmasını koordine etmek
için kullanılan süreçler arası iletişim mekanizmalarını gösteren modellerin oluşturulmasını
gerektirir.

Development / Implementation Viewpoint

- Yazılım geliştirme sürecini destekleyen mimariyi açıklar.

- Geliştirme görünümü, ilgili mimarinin yönlerini ilgili paydaşlara iletir; Sistemin oluşturulması,
test edilmesi, bakımı ve geliştirilmesi
- Tasarım yazılımı yapısı, modüllerin, alt sistemlerin ve katmanların tanımlanması ve yazılım
geliştirmeyle doğrudan ilgili konular

Deployment / Physical Viewpoint

- Sistemin çalışma zamanı ortamlarında sahip olduğu bağımlılıkların yakalanması da dahil

olmak üzere, sistemin devreye alınacağı ortamı açıklar.
- Bu görünüm, sisteminizin ihtiyaç duyduğu donanım ortamını (öncelikle gereken işlem
düğümleri, ağ ara bağlantıları ve disk depolama tesisleri), her öğe için teknik ortam
gereksinimlerini ve yazılım öğelerinin bunları çalıştıracak çalışma zamanı ortamıyla
eşlenmesini yakalar.

Operation Viewpoint

- Sistemin üretilmesi aşamasında nasıl çalıştırılacağı, yönetileceği ve destekleneceğini açıklar.

- En basit sistemler dışındaki tüm sistemler sistemin kurulması yönetilmesi ve çalıştırılması
tasarım aşamasında dikkate alınması ve planlanması gereken önemli görevlerdir.
 - Bu operasyonel bakış açısının amacı da sistem taraflarının bu operasyonel ilgilerinin ele almak
için sistem çapında stratejiler belirlemek ve bunlara yönelik çözümler üretmektir.

7.Ders

- Çalışma Soruları
- Yazılım mimarisi tanımından hareketle onun neyi ihtiva ettiğini yazınız
o Yazılım unsurları ve aralarındaki ilişkiler ile bu ikisinin özelliklerini
- Yazılım mimarisi için ne gereklidir?
o Bir sistem hakkında fikir yürütmek içindir.
- Yazılım mimarisi kategorileri
o Module
o Component and connector (bileşen ve bağlayan
o Allocation (tahsis)
- Modül nedir ?
o Sistemin hayata geçirilme birimi.
- Tahsis yapıları neyi tanımlar? Örnek veriniz.
o Yazılım yapılarının sistem ortamlarıyla örtüşmesini tanımlar.
o Bir ekibe bir işin (modül) yüklenmesi veya bir yazılımın bir donanıma yüklenmesi.
- Bir yapı ne zaman mimardir?
o Bir yapı, sistem ve sistemin özellikleri hakkında akıl yürütmeyi destekliyorsa
mimaridir. Muhakeme, sistemin bazı "stakeholded'larca Önemsenen bir niteliği
hakkında olmalıdır. Bir mimari, sistem hakkında mantık yürütmek için bir faydası
olmayan unsurlar hakkındaki belirli bilgileri bilhassa göz ardı eder.nBir mimari, belirli
ayrıntıları seçer ve diğerlerini bastırır. Öğelerin özel ayrıntıları -yalnızca iç uygulamayla
ilgili ayrıntılar- mimari değildir.
- Mimari soyutlama sisteme hangi açılardan bakmamızı sağlar?
o Öğeleri , nasıl düzenlendiklerini , nasıl etkileşime girdikleri, nasıl bir araya
getirildikleri, sistem mantığımızı destekleyen özelliklerinin neler olduğu vb. açısından
bakmamızı sağlar.
- Bu soyutlama niçin gereklidir?
o Bu soyutlama bir mimarinin karmaşıklığını uysallaştırmak için gereklidir.

- Her bir ögenin davranışı ne zaman mimarinin bir parçası olarak görülür?
o Bu davranış sistem hakkında mantık yürütmek için kullanılabildiği ölçüde mimarinin
bir parçasıdır.
o Bir unsurun davranışının başka bir unsuru etkilediği veya bir bütün olarak sistemin
kabul edilebilirliğini etkilediği ölçüde bu davranış yazılım mimarisinin bir parçası
olarak değerlendirilmeli ve belgelenmelidir.
- View nedir?
o Bir view sistem stekeholderları (paydaş) tarafından yazılan ve okunan şekliyle,
coherent bir mimari unsurlar kümesinin temsilidir.
o Bir view bir dizi ögenin ve aralarındaki ilişkilerin temsilini ihtiva eder.
o Bir modül “view” seçilen notasyondaki şablona göre dökümante edilen ve bazı sistem
stakeholderlerı tarafından kullanılan bu yapının temsilidir.
- Şu soruların cevabına hangi view yardımcı olur?
o Her bir yazılım ögesi hangi işlemci üzerinde çalışır?
 
o Geliştirme test etme ve sistem oluşturma sırasında her öğe hangi dizinlerde veya
dosyalarda depolanır?
o Geliştirme ekiplerine verilen her bir yazılım ögesi ödevi nedir?
- Aşağıdaki soruları cevaplamamıza yarayan yapı hangisidir?
o Her bir modüle atanan birincil işlevsel sorumluluk nedir? Modül Yapıları (Module
Structures)
o Hangi modüller diğer modüllerle genelleştirme veya özelleştirme yoluyla
irtibatlandırılır? Modül Yapıları (Module Structures)
o
o Başlıca yürütme bileşenler nelerdir ve koşulurken nasıl etkileşir? Component and
connector (bileşen ve bağlayan)
o Başlıca paylaşılan veri depoları nelerdir? Component and connector (bileşen ve
bağlayan)
o Sistemin hangi bölümleri kopyalanır(ikilenri)? Component and connector (bileşen ve
bağlayan)
o Veriler sistemde nasıl ilerler? Component and connector (bileşen ve bağlayan)
o Sistemin hangi bölümleri paralel olarak çalışabilir? Component and connector
(bileşen ve bağlayan)
o
o Her bir yazılım öğesi hangi işlemci üzerinde çalışır? Allocation (tahsis)
o Geliştirme, test etme ve sistem oluşturma sırasında her öge hangi dizinlerde veya
dosyalarda depolanır? Allocation (tahsis)
o Geliştirme ekiplerine verilen her bir yazılım ögesi ödevi nedir? Allocation (tahsis)
- ………………… sistemin, inşa edilmesi veya tedarik edilmesi gereken bir dizi kod veya veri
bilimleri olarak nasıl yapılandırılacağına ilişkin kararları içerir. (Modül Yapıları) Module
Structure
- ………………… sistemin koşu davranışı ve etkileşimleri sahip bir ögeler kümesi olarak nasıl
yapılandırılacağına ilişkin kararları içerir. (Bileşen ve Bağlayan) Component an Connector
- ………………… yazılım oluşturulduğu ve yürütüldüğü bir veya daha fazla harici ortamdaki ögeler
ile yazılım ögeleri arasındaki ilişkiyi gösterir. (Tahsis) Allocation

Yazılım Kalite Nitelikleri :

- Kalite nitelikleri gerekleri, bir uygulamanın talep ve ihtiyaçlarının nasıl karşılandığının birçok
yüzünü yakalayan işlevsel olmayan talep ve ihtiyaçlarının parçasıdır.
- Kalite niteliklerinin ana ve alt gruplarını yazınız.
o 1 Tasarım Kaliteleri
 Erişilebilirlik / Kavramsal Bütünlük / Bir arada çalışabilirlik
o 2 Koşu Kaliteleri
 Müdahale edilebilirlik / Yönetilebilirlik / Performans / Güvenilirlik / Tekrar
Kullanılabili Ölçeklenebilirlik / Güvenlik
o 3 Sistem Kaliteleri 4 Kullanıcı Kaliteleri
 Desteklenebilirlik / Test Edilebilirlik Kullanıcı Tecrübesi /
Kullanılabilirl
- Kavramsal bütünlük neyi tanımlar?
o Conceptual Integrity
  Kavramsal bütünlük genel tasarımın tutarlılığını ve sıkılığı ve türdeşliğini
tanımlar.
- Performans Kalite nitelikleri neyle ölçülür?
o Gecikme(latency) veya througput olarak ölçülebilir.
o Gecikme herhangi bir olaya tepki vermek için geçen süredir.
o Throughput (avarage, pick) belirli bir süre içinde gerçekleşen olay sayısıdır.
o Response Time (guaranted avarage)
o Deadlines ( süre sonu)
- Güvenilirlik
o Authentication (tanıma)
 Something you know
 Password or pin
 Something you have
 Plastic cards ya da el tipi kişiselleştirilmiş hesaplayıcı
 Something is yours
 Fingerprints, retina scans, handwritten singatures, face/voice
recognition
o Confidentiality(Gizlilik)
o Authorization (Yetkilendirme)
o Integrity (Bütünlük)
o Nonrepudiaation (İnkar etme)
- Modülerleştirme sözlükler ne diyor ?
o Bir dizi standart parça veya ayrı birimden daha grifit bir yapı inşa edilmesi.
- Modül kalitesinin iki esası
o Loosely Coupling (gevşek bağ)
 Bağın ve bağlılığın gevşek olması
o Highly Cohesive
 Yüksek bir sıkılık ve türdeşlk olmalı
- Couplingi etkileyen faktörler
- Aşağıdaki artışlar veya bunlardan her birinin sonucu modül kalitesi bakımından olumlu mudur
olumsuz mudur?
o Modüller arasında geçen veri elemanı sayısı artarsa ?
o Modüller arasında geçen kontrol verisi sayısı artarsa?
o Modüller tarafından kullanılan ortak global veri elemanlarının sayısı artarsa?
 Ne kadar çok global veri elemanı paylaşılırsa, bağ o kadar güçlü olur.
- Bir modül çağrısındaki (call) parametre sayısının çokluğu çağrılan modülün birden fazla
function icra etmesi demektir.
o Ne kadar çok olursa girifitlik o kadar artar veya bağ o kadar güçlü olur
- Ortak veya global veri elemanlarının fazlaca kullanımı giriftliği artırır. Neden?
o Anlamayı ve değişiklik yapmayı zorlaştırır.
o Birden gazla kaynaktan veriye müdahale riski vardır.
- Coupling türlerini makbul olandan olmayan göre sıralayınız.
o Data coupling
o Stamp coupling (damga,mühür)
o Control coupling
o Common coupling
o Content coupling
 - Modüller arasındaki veri arayüzü bağının giriftliğini dikkate almayan modülleştirme tight
couplinge yol açar.
- Modüller tarafından kullanılan ortak global veri elemanlarının sayısı
o Ne kadar çok global veri elemanı paylaşılırsa, bağ o kadar güçlü olur.

- Cohesion neyi ölçer

o Modülün elemanları arasındaki sıkılık ve türdeşlik
- Cohesion türleri
o Functional (işlevsel),
o Sequential(dayalı sıralı)
o Communicational (iletişimsel),
o Procedural (sıralı), Temporal (geçici),
o Logical (mantıksal),
o Coincidental(tesadüfi)

10. HAFTA

 Kalıplar ve Taktikler
o Kalıp nedir?
 Bir mimari kalıp şunların arasında ilişki kurar:
 Bir bağlam (context). Problem çıkaran bir dünyada tekrarlayan genel bir
durum bir problem. Veri bağlamda yer alan uygun şekilde genelleştirilmiş
problem. Bir çözüm(solution) . Problemin, uygun şekilde soyutlanmış başarılı
bir mimarisi.
 Bir Çözüm. Problemin, uygun şekilde soyutlanmış başarılı bir mimarisidir. Bir
kalıp için çözüm şunlar tarafından belirlenir ve tanımlanır:
 Unsur tipleri kümesi (ör. Veri depoları, süreçler ve nesneler)
 Etkileşim mekanizmaları ve bağlayanları kümesi (ör. Metot çağrısı,
olaylar, mesai yolu)
 Bileşenlerin topolojik deseni
 Topolojiyi, eleman davranışını ve etkileşim mekanizmalarını kapsayan
anlamsal kısıtlar kümesi
o Genel Bakış
 Faydalı ve yaygın olarak kullanılan kalıplar.
 Bu kataloğun kapsamlı olması amaçlanmamıştır.
 Temsili olması amaçlanmamıştır
o Runtime zamanı ögelerinin kalıpları veya istemci-sunucu =
client-server)
o Tasarım zamanı ögeleri (tabakalar/katmanlar)
 Her bir kalıp için bağlam, problem ve çözüm listeliyoruz
o Çözümün bir parçası olarak her bir kalıbın unsurlarını
ilişkilerini ve kısıtlarını kısaca açıklarız.
 Bir kalıp uygulaması “ya hep ya hiç” önerisi değildir.
 Uygulamadı mimarlar iyi bir tasarım ödeşimi olduğunda bunları
küçük şekillerde ihlal etmeyi seçebilirler.
 Kalıplar gösterdikleri baskın öge türlerine göre kategorize edilebilir
  Modül kalıpları modülleri , bileşen ve bağlayan (c&c) kalıpları
bileşenler ve bağlayanları, tahsis yapıları, yazılım ögelerinin (modüller
bileşenler ve bağlayıcılar) ve yazılım dışı ögelerin bir kombinasyonunu
gösterir.
o Tabakalı Kalıp (Layered Pattern)
 Bağlam
 Bütün karmaşık (girift) sistemler bir sistemin parçalarını bağımsız
olarak geliştirmek ve evriltmek ihtiyacını yaşar.
 BU sebeple sistem geliştiricileri açık ve iyi dokümante edilmiş ilgi
ayrımına ihtiyaç duyarlar. Öyle ki sistem modülleri bağımsız olarak
geliştirilebilsin ve idame edilebilsin.

 Problem
 Yazılımı öyle bir şekilde bölümlenmeye ihtiyaç duyar ki modüller,
o taşınabilirliği, değiştirilebilirliği ve tekrar kullanımı
desteleyerek parçalar arasında zayıf bir etkileşim ile
geliştirilebilirsin ve evriltilebilsin.
 Çözüm
 Bu ilgi ayrımına ulaşmak için tabakalı(katmanlı) kalıp, yazılımı
tabakalara böler.
 Her tabaka sıkı ve türdeş hizmetler kümesini veren bir modüller
gruplamasıdır. Bu kullanım tek yönlü olmalıdır.
 Tabakalar tamamen bir yazılım kümesi bölümüdür ve her bölüm bir
genel ile ortaya çıkar.
o Tabakalı Kalıp çözümü
 Genel Bakış
 Tabakalı kalıp tabakaları (sıkı hizmetler kümesini veren bir modüller
gruplaması) ve tabakalar arasında tekyönlü 'kullanma izinli' ilişkisini
tanımlar.
 Unsurlar
 Tabaka bir çeşit modüldür. Tabaka tanımı içerdiği modülleri
tanımlamalıdır.
 İlişkiler
 Kullanma izinli. Tasarım tabaka kullanım kurallarını ve müsaade
edilen istisnaları tanımlamalıdır.
 Kısıtlar
 Her yazılım parçası tam olarak bir tabakaya tahsis edilir.
 En az iki tabaka olmalıdır (genellikle üç veya daha fazla).
 'Kullanım izinli' ilişkisi dairevi olmamalıdır (ör. Alt bir tabaka bir
üstteki tabakayı kullanamaz).
 Zayıf yönler
 Tabakaların eklenmesi, bir sisteme önyüz maaliyeti ve karmaşıklık
ekler
 Tabakalar performans kaybını artırır.
o Tabakalı Kalıp
 Bileşenler arasında ilgi ayrımı
  Yalıtım tabakaları
 Yalıtım tabakaları kavramı mimarinin bir katmanında yapılan
değişikliklerin genellikle diğer katmanlardaki bileşenleri etkilememesi
demektir.
 Yalıtım tabakaları kavramı aynı zamanda bir katmanın diğer
katmanlardan bağımsız olması ve böylece mimarideki diğer
katmanların iç çalışmasını bilmemesi veya çok az bilmesi demektir

 Model – Görünüm – Denetleyici (MVC)

o Bağlam
 Kullanıcılar arayüzü yazılımı, etkileşimli bir uygulamanın tipik olarak en sık
değiştirilen kısmıdır.
 Kullanıcılar sıklıkla verilere farklı perspektiflerden bakmak ister (çubuk grafik
veya pasta grafik gibi). Bu temsillerin her ikisi de verilerin mevcut durumunu
yansıtmalıdır
o Problem
 Kullanıcı arayüzü/arabirimi işlevselliği, uygulama işlevselliğinden nasıl ayrı
tutulabilir ve
 hatta kullanıcı girişine veya temeldeki uygulamanın veri değişikliklerine nasıl
cevap verebilir ?
 Ve temeldeki uygulamanın verileri değiştiğinde, kullanıcı arayüzünün çoklu
görünümleri nasıl oluşturulabilir, idame edilebilir ve koordine edilebilir?
o Çözüm
 MVC modeli uygulama işlevselliğini üç tür bileşene ayırır.
 Uygulama verilerini içeren bir MODEL
 Temeldeki verilerin bir kısmını görüntüleyen ve kullanıcıyla etkileşime
giren bir GÖRÜNÜM
 Model ve görünüm arasında aracılık eden ve durum değişikliklerinin
bildirimlerini yöneten bir DENETLEYİCİ
 Model uygulama verilerinin veya durumunun bir temsildir ve uygulama
mantığını içerir veya buna bir arayüz sağlar
 Görünüm kullanıcı için modelin bir temsilini üreten veya bazı kullanıcı girdi
biçimlerine veya her ikisine imkân veren bir kullanıcı arayüzü bileşeni
 Denetleyici kullanıcı eylemlerini model ve görünüm değişikliklerine
dönüştürerek model ve görünüm arasındaki etkileşimi yönetir.
 o İlişkiler
 Bildirir ilişkisi model görünüm ve denetleyici oluşlarını birbirine bağlayıp ilgili
durum değişiklik öğelerini bildirir
o Kısıtlar
 MVC’nin her birinin en az bir oluşu olmalıdır.
 Model bileşeni denetleyici ile doğrudan etkileşime girmemelidir
o Zayıf Yönleri
 Katlanılan karmaşıklık basit kullanıcı arayüzleri için değmeyebilir.
 MVC soyutlamaları bazı kullanıcı arayüzü araç takımları için uygun olmayabilir.
o Model
 Uygulama durumunu sarmalar, durum sorgularını cevaplar, uygulama
işlevselliğini açığa vurur, değişiklik görünümlerini bildirir
o View
 Modelleri işler, modellerden güncelleme talep eder, kullanıcı tavırlarını
denetleyiciye gönderir, denetleyicinin görünüm seçmesine imkân verir.
o Controller
 Uygulama davranışlarını tanımlar, kullanıcı eylemelerini model
güncellemeleriyle örtüştürür, karşılık için görünüm seçer, her işlevsellik için
bir tane

 İstemci-Sunucu Kalıbı
o Bağlam
 Çok sayıda dağıtık istemcinin erişmek istediği ve bizim erişimi ve hizmet
kalitesini kontrol etmek istediğimiz paylaşılan kaynaklar ve hizmetler vardır.
o Problem
 Ortak kaynaklar ve hizmetler kümesini yönetirken, ortak hizmetleri ayırmakla
ve bu değişiklikleri tek veya az sayıda yerde yapmakla yeniden kullanımı
teşvik edebiliriz.
 Kaynakları kendisini birden çok sunucuya (fizikî) dağıtırken, bu kaynakların ve
hizmetlerin kontrolünü merkezileştirerek — Ölçeklenebilirliği ve erişilebilirliği
geliştirmek İsteriz.
o Çözüm
 Istemciler bir dizi hizmet sağlayan sunucudan sunucu hizmeti talebiyle
etkileşimde bulunurlar.
 Bazı bileşenler hem istemci hem de sunucu gibi davranabilirler.
 Tek bir merkezî veya birden çok dağıtık sunucu olabilir
o Genel Bakış
 İstemciler sunucularla ihtiyaç duydukları hizmetleri isteyerek ve bu taleplerin
sonucunu bekleyerek etkileşimi başlatırlar.
 o Unsurlar
 İstemci sunucuya hizmet almak için başvuran bileşendir. İstemciler istedikleri
hizmetleri tarif eden sahiptir.
 Sunucu istemcilere hizmetleri sağlayan bileşendir. Sunucular sağladıkları
hizmetleri tarif eden portlara sahiptir.
 Talep/cevap bağlayıcısı:
 Bir istemci tarafından bir sunucuya hizmet başvurusu için kullanılan
ve talep/cevap protokol” barındıran bir veri bağlayıcısıdır.
 Önemli özellikleri çağrıların yerel veya uzak olup olmaması ve verinin
şifreli olup olmamasıdır.
o İlişkiler
 'Bağlılık'(rabıta) ilişkisi istemcileri sunucular ile eşleştirir.
o Kısıtlar
 İstemciler sunuculara talep/cevap bağlayıcıları ile bağlanırlar.
 Sunucu bileşenleri diğer sunucuların istemcileri olabilir.
o Zayıf yönleri
 Sunucu performans darboğazına girebilir.
 Sunucu arızanın tek merkezi olabilir.
 İşlevselliğin hangi tarafa (sunucuya mı istemciye mi) yerleştirileceğine dair
kararlar sıklıkla karmaşıktır ve sistem kurulduktan sonra değiştirilmesi
maliyetlidir

11. Hafta

o Service Orianted Architecture Pattern

 Bağlam
 Bir dizi hizmet sağlayıcılar tarafından sunulur (ve tarif edilir) ve
hizmet tüketicileri tarafından tüketilir.
 Hizmet tüketicilerinin hayata geçirilmelerine daire herhangi bir
ayrıntılı bilgiye sahip olmadan bu hizmetleri anlayabilmesi ve
kullanabilmesi gerekir.
 Problem
o Farklı platformlarda çalışan ve farklı uygulama dillerinde
yazılmış farklı kuruluşlar tarafından tedarik edilen ve internet
üzerinden dağıtılan dağıtık bileşenlerin bir arada
çalışabilirliğini nasıl destekleyebiliriz
o Makul performans güvenlik ve ulaşılabilirlik elde ederken
hizmetleri nasıl bulabilir ve anlamlı koalisyonlar halinde nasıl
birleştirebiliriz
 Çözüm
 Hizmet odaklı mimari SOA kalıbı, hizmetleri tedarik
eden ve tüketen dağıtık bileşenlerin bir koalisyonunu
tarif eder
 Hizmet tedarikçi bileşenleri ve hizmet tüketici
bileşenleri, farklı uygulama dillerini ve platformlarını
kullanabilir.
 Hizmetler büyük ölçüde tek başınadır; hizmet
tedarikçileri ve hizmet tüketicileri genellikle bağımsız
 olarak yerleştirilirler ve çoğu zaman farklı sistemlere
ve hatta farklı kuruluşlara aittirler.
 Bileşenlerin, diğer bileşenlerden talep ettikleri
hizmetleri ve tedarik ettikleri hizmetleri tarif
eden .arayüzleri vardır
 Bir hizmetin kalite nitelikleri, bir hizmet düzeyi
sözleşmesi (SLA) ile belirlenebilir ve garanti edilebilir.
 Bazı durumlarda, bunlar yasal bağlayıcılardır.
 Bileşenler, birbirlerinden hizmet talep ederek kendi
bilişimlerini gerçekleştirirler.
 Bu kalıptaki unsurlar, fiili durumda, — bir web tarayıcısında çalışan
JavaScriptten ana bilgisayarda çalışan CICS işlemlerine kadar farklı biçimler
alabilen hizmet sağlayıcıları ve hizmet tüketicilerini içerir.
 Bir SOA Hizmet sağlayıcı ve hizmet tüketici bileşenlerine ek olarak aracı
şeklinde hareket eden ve hizmetleri sunan kullanabilir:
o Aracılar ve Altyapı Hizmetleri
 ESB (dvm ı var):
 Hizmet çağrısına bir kurumsal hizmet veri yolu (ESB) aracılık edebilir.
 Bir ESB, servis tüketicileri ve servis tedarikçileri arasındaki mesajları
yönlendirir.
o ESB mesajları bir protokol veya teknolojiden diğerine
dönüştürebilir, çeşitli veri dönüşümleri (örn., format, içerik,
bölme, birleştirme), güvenlik kontrolleri yağabilir ve
hareketleri yönetebilir.
o Bir ESB kullanmak, çalışabilirliği güvenliği ve değiştirilebilirliği
destekler.
o Tabii ki, bir ESB aracılığıyla İletişim kurmak İlave yük getirerek
performansı düşürür ve ek bir arıza noktası oluşturur.
o Bir ESB olmadığında, hizmet sağlayıcılar ve tüketiciler
birbirleriyle noktadan noktaya iletişim kurar.
 Hizmet sunucularının bağımsızlığını artırmak için SOA mimarilerinde bir
hizmet kaydı kullanılabilir,
 Kayıt, hizmetlerin koşu zamanında kaydedilmesine İzin veren bir
bileşendir.
 Bu, hizmet sağlayıcının konumunu ve kimliğini gizleyerek sistem
değiştirilebilirliğini artıran hizmetlerin koşu zamanında keşfedilmesini
mümkün kılar.
 Bir kayıt, aynı hizmetin birden çok canlı sürümüne bile izin verebilir.
 Orkestra Sunucu:
 Bir orkestra sunucusu (veya düzenleme motoru), bir SOA sistem
indeki çeşitli hizmet tüketicileri ve tedarikçileri arasındaki etkileşimi
düzenler.
 Belirli bir olayın meydana gelmesi üzerine (örneğin, bir siparişi talebi
geldi) komut dosyalarını yürütür
o İyi tanımlanmış iş süreçlerine veya dağıtılmış bileşenlerle
veya sistemlerle etkileşimleri içeren iş akışlarına sahip
uygulamalar,
  Bir orkestra sunucusu kullanarak değiştirilebilirlik, birlikte çalışabilirlik
ve güvenilirlik kazanır.
 Ticari olarak ulaşıla bilir birçok orkestra sunucusu, çeşitli iş akışı veya
iş süreci dili standartlarını destekler.
o SOA'da kullanılan temel bağlayıcı türleri
 1. SOAP. Web hizmetleri teknolojisinde iletişim için standart protokoL
 Hizmet tüketicileri ve sağlayıcıları, tipik olarak http’nin üzerinde istek/cevap
XML mesajlarını değiş tokuş ederek etkileşime girer.
 2. REST Representational State Transfer. Bir hizmet tüketicisi, engellenmeyen
HTTP istekleri gönderir. Bu istekler, hizmet sağlayıcıya bir kaynağı
oluşturmasını, almasını, güncellemesini veya silmesini söylemek için dört
temel HTTP komutuna (POST, GET, PUT, DELETE) dayanır.
 3. Asynchronous messaging, Asenkron mesajlaşma, bir "ateşle ve unut" bilgi
alışverişi. Altyapının mesajı başarıyla ilettiği varsayıldığından, katılımcıların
alındı teyidi için beklemelerine gerek yoktur.
 Mesajlaşma bağlayıcısı noktadan-noktaya veya yayınla-abone ol olabilir.
 Pratikte, SOA ortamları
 az önce listelenen üç bağlayıcının (SOAP, REST, asenkron mesajlaşma)
bir karışımını içerebilir,
 eski protokoller ve diğer İletişim alternatifleri (Örneğin,SMTP, Basit
Posta Aktarım Protokolü) ile birlikte.
 IBM'in WebSphere MQ’su Microsoft’un MSMQ’su (Microsoft Message
Queuing) veya Apache’nin ActiveMQ’su gibi ticari ürünler, eşzamansız
mesajlaşma sağlayan altyapı bileşenleridir.
o Gördüğünüz gibi SOA kalıbı tasarlama ve uygulama bakımından oldukça karmaşık
olabilir
 dinamik bağlama (dynamic binding) ve
 meta verilerin birlikte kullanımı nedeniyle.
o Bu kalıpla ilgili diğer olası sorunlar arasında,
 hizmetler ve istemciler arasında araya giren ara yazılımın performans yükü ve
 performans garantilerinin yokluğu hizmetlerin paylaşılması ve genel olarak
istekte bulunanın denetimi altında olmaması nedeniyle yer alır.
o Bu zayıflıkların tümü "broker” kalıbıyla paylaşılır, bu şaşırtıcı değildir çünkü SOA kalıbı
"broker” tasarım kavramlarının ve hedeflerinin çoğunu paylaşır.
o Ayrıca, kullandığınız hizmetlerin evrilişini genel olarak kontrol etmediğiniz için, yüksek
ve planlanmamış bakım maliyetlerine katlanmak zorunda kalabilirsiniz.

















 Microservices Architecture Pattern

 Belli başlı uygulama bileşenleri, daha küçültülmüş ayrık olarak yerleştirilen

birimlerdir.
 Dağıtık mimari.
 Monolitik uygulamalara ve hizmet odaklı mimarilere uygulanabilir bir
alternatiftir.
 Bu mimari kalıp hala evrilmektedir. Sektörde bu modelin neyle ilgili olduğu ve
nasıl uygulandığı konusunda çok fazla kafa karışıklığı var.
 Genel mimari modele uygulanan birkaç ortak temel kavram vardır.
 Bu kavramlardan ilki, ayrı yerleştirilmiş birimler kavramıdır. ŞekiI 4- I 'de
gösterildiği gibi, mikro hizmet mimarisinin her bir bileşeni ayrı bir birim olarak
yerleştirilir ve
etkili ve düzenli bir teslimat yoluyla
o daha kolay yerleştirme.
o artırılmış ölçeklenebilirliğe ve uygulama içinde
o yüksek derecede uygulama ve bilesen ayrıştırmasına imkân tanır.
 Hizmet Bileşenleri
o Belki de bu kalıpla anlaşılması gereken en önemli kavram, hizmet
bileşeni kavramıdır.
o Hizmet bileşenleri,
 Tek amaçlı bir işlevi (örneğin, belirli bir şehir veya kasaba için
hava durumu sağlama) veya
 büyük bir iş uygulamasının bağımsız bir bölümünü (örneğin,
hisse senedi ticareti yerleştirme veya oto-sigorta oranlarının
belirlenmesi) temsil eden
 bir veya daha fazla modülü (e.g.Java sınıfları) ihtiva eder,
o Hizmet bileşeni doğru ayrıntı düzeyini tasarlamak, bir mikro hizmet
mimarisindeki en büyük zorluklardan biridir.
 Dağıtık Mimari
o Mikro hizmet mimarisi modeli içindeki bir diğer anahtar kavram,
dağıtık mimari olmasıdır, yani mimarideki tüm bileşenlerin
 birbirinden tamamen ayrılması ve bir tür uzaktan erişim protokolü
(JMS, AMPQ,REST, SOAP,RMI, vb.) ile erişilebilirliğidir.
 Karşılaştırma
o Mikro hizmet mimarî tarzı doğal olarak iki ana kaynaktan evrilmiştir.
 tabakalı mimarî kalıp kullanılarak geliştirilen monolitik
uygulamalar ve hizmet odaklı mimarî kalıp aracılığıyla
geliştirilen dağıtık uygulamalar.
o Monolitik uygulamalar tipik olarak, tek bir yerleştirilebilir birimin
parçası olan sıkı irtibatlı bileşenleri ihtiva eder, bu da

 uygulamayı değiştirmeyi, test etmeyi ve yerleştirmeyi
zorlaştırır (dolayısıyla tipik olarak çoğu büyük BT mağazasında
bulunan ortak "aylık yerleştirme” döngülerinin yükselişi
artar).
o Mikro hizmet mimarî kalıbı, uygulamayı, ayrı geliştirilebilen, test
edilebilen ve diğer hizmet bileşenlerinden bağımsız olarak
yerleştirilebilen birden çok yerleştirilebilir birime (hizmet bileşenleri)
ayırarak bu sorunların üstüne gider.
o Mikro hizmet mimarî kalıbına götüren diğer evrimsel yol, hizmet
odaklı mimari modelini (SOA) uygulayan uygulamalarda bulunan
sorunlardır.
o SOA modeli, çok güçlüdür ve eşsiz düzeyde soyutlama, heterojen
bağlantı, hizmet düzenlemesi (tertibat) ve iş ve ET hedeflerinde
uyumu vadeder. Ancak:
 karmaşık, pahalı, her yerde bulunur, anlaşılması ve
uygulanması zordur ve genellikle çoğu uygulama için fazla
gelmektedir.
o Mikro hizmet mimarî tarzı, hizmet kavramını basitleştirerek,
düzenleme ihtiyaçlarım ortadan kaldırarak ve bağlantı ve hizmet
bileşenlerine erişimi basitleştirerek bu karmaşıklığın üstüne gider.
 Topolojiler
o En yaygın ve popüler olarak üç ana topoloji öne çıkmaktadır:
 API REST-tabanll topoloji,
 uygulama REST-tabanll topoloji ve
 merkezîleştirilmiş mesajlaşma topoloj isi.
o API-REST

o
  API REST-tabanll topoloji, bir tür API (uygulama programlama
arabirimi) aracılığıyla küçük, kendine yeten bireysel hizmetler
sergileyen web siteleri için kullanışlıdır, Şekil 4-2 'de
gösterilen bu topoloji, geri kalan hizmetlerden bağımsız
olarak belirli iş fonksiyonlarım gerçekleştiren bir veya iki
modül içeren çok küçültülmüş hizmet bileşenlerinden (bu
nedenle mikro hizmetler adı verilir) oluşur.
 Bu topolojinin örnekleri arasında ,Yahoo, Google ve Amazon
tarafından bulunan bazı yaygın tek-amaçlı bulut tabanlı
REŞTful web hizmetleri vardır.

o APPLICATİON REST

o
 Uygulama REST-tabanll topoloji, istemci taleplerinin basit bir
API katmanı yerine geleneksel web-tabanlı veya güçlü-istemci
iş uygulaması ekranları aracılığıyla alınmasıyla API REST-
tabanlı yaklaşımdan ayrılmaktadır.
 Şekil 4-3 'te gösterildiği gibi, uygulamanın kullanıcı arabirimi
katmanı, ayrı olarak dağıtılan hizmet bileşenlerine (iş
işlevselliği) basit REST-tabanlı uzaktan erişen ayrı bir web
uygulaması olarak yerleştirilir.
 Bu topolojideki hizmet bileşenleri,API-REST tabanlı
topolojidekilerden farklıdır, çünkü bu hizmet bileşenleri
küçültülmüş tek eylem hizmetlerinden ziyade
 daha büyükçe ve
 daha İri tanelidir;
 genel İş uygulamasının küçük bir bölümünü temsil
eder.
 Bu topoloji, nispeten düşük derecede karmaşıklığa sahip
küçük ve orta ölçekli iş uygulamaları için yaygındır.
o Merkezi Mesajlaşma Tabanlı
 o
 Mikro hizmet mimarisi modelindeki diğer bir yaygın yaklaşım,
merkezîleştirilmiş mesajlaşma topolojisidir.
 Bu topoloji (Şekil 4-4'te gösterilmiştir), ' uzaktan erişim için
REST kullanmak yerine hafif bir merkezîleştirilmiş mesaj
aracısı (ActiveMQ, HornetQ vb.) kullanmasını bir taraf
koyarsak, önceki uygulama REST-tabanll topolojiye benzer.


 Merkezîleştirilmiş mesajlaşma topolojisi tipik olarak daha
büyük iş uygulamalarında veya kullanıcı arayüzü ile hizmet
bileşenleri arasındaki taşıma katmanı üzerinde daha karmaşık
kontrol gerektiren uygulamalarda bulunur.
 Daha fazla sağlamlık.
 Ölçeklenebilirlik: daha iyi ölçeklenebilirlik sağlar ve
 Test edilebilirlik ve zayıf bağlılık: devamlı teslimatı daha kolay
destekleyebilir
 Yerleştirme: gerçek zamanlı ürün yerleştirme yeteneği sağlar
 Sözleşme oluşturma
 Bakım-idame ve
 Yönetişim
 Uzaktan sistem ulaşılabilirliği ve
 Uzaktan erişimle kimliklendirme ve yetkilendirmeyi içeren
karmaşık sorunlar

12. Hafta

Object-Oriented Analysis and Design with UML

 Modelleme
o Bir sistemi olması istediğiniz gibi görselleştiemenize yardımcı olur.
o Bir sistemin yapısını ve davranışını belirlemenize izin verir.
o Size bir sistem kurmanızda rehberlik edecek bir şablon verir.
o Verdiğiniz kararları belgeler.
 1. Modeller, sistemi istediğiniz gibi görselleştirmenize yardımcı olur. Bir model, yazılım
ekibinin geliştirilmekte olan sistemin vizyonunu iletmesine yardımcı olur. Bir yazılım ekibinin
yalnızca spesifikasyon ve requirements belgelerinde açıklanan bir sistem hakkında birleşik bir
vizyona sahip olması zordur. Modeller sistemin anlaşılmasını sağlar
 2. Modeller bir sistemin davranış yapısını belirlemenize İzin verir. Bir model, sistemi
kodlamadan Önce sistem davranışının ve yapısının nasıl belgeleneceğine İmkan tanır.
 3. Modeller, bir sistem oluştururken size yol gösterecek bir şablon sunar. Bir model inşaa
sırasında paha biçilmez bir araçtır, Bir geliştirici için yol haritası görevi görür. Bir geliştiricinin,
requirements belgesindeki ifadeler konusunda kafasının karışması nedeniyle yanlış davranışı
kodladığı bir durumla karşılaştınız mı? Modelleme bu durumu hafifletmeye yardımcı olur.
 Modellemenin 4 İlkesi
o Oluşturduğunuz model, sorunun üstüne nasıl gidileceğini etkiler.
o Her model farklı kesinlik seviyelerinde ifade edilebilir.
o En iyi modeller gerçeklikle bağlantılıdır.
o Tek bir model yeterli değildir.

 Abstraction (Soyutlama)
o Öğrenci, üniversitedeki derslere kayıtlı kişidir.
o Profesör, üniversitede ders veren kişidir.
o Kurs, üniversite tarafından sunulan bir sınıftır.
o Bir kurs teklifi, haftanın günleri ve saatleri de dahi I olmak üzere bir kurs İçin Özel bir
tekliftir,
 Sarmalama(Encapsulation)
o Sarmalamanın anahtarı nesne'nin mesaj arayüzüdür. Nesne arayüzü, nesne ile
kurulan bütün iletişimin önceden tanımlı bir dizi operasyon sayesinde olmasını
güvenceye alır. Nesne içindeki veriye ancak nesne'nin operasyonu ile erişilebilir. Başka
hiçbir nesne bu nesnenin içine uzanamaz ve onun nitelik değerlerini değiştiremez.
o Mesela Professor Clark'ın en fazla ders yükünü her dönem üç dersten dört derse
çıkarması gerekmektedir. Bir başka nesne Professor Clark'a en fazla ders yükünü
dörde çıkarması isteğinde bulunacaktır. MaxLoad niteliği SetMaxLoad() operasyonu ile
değiştirilecektir.
o Sarmalama bu örnekte faydalıdır çünkü isteyen nesne "en çok” ders yükünün nasıl
artırılacağını bilmek ihtiyacında değildir. Gelecekte "en çok” ders yükünü
tanımlamada kullanılan değişken sayısı artırılabilecektir fakat bu isteyen nesneyi
etkilemeyecektir. İsteyen nesne Professor Clark nesnesi için operasyon arayüzüne
dayanmaktadır.
 Modülerleştirme (Modularity)
o Kompleks sistemleri daha küçük modüllere parçalamak ayırmak
 Hiyerarşi (Hierarchy)
 o Soyutlamaların ağaç benzeri bir yapıda herhangi bir sıralaması veya rütbelendirilmesi.
Türler: Toplama hiyerarşisi, sınıf hiyerarşisi, kapsama hiyerarşisi, kalıtım hiyerarşisi,
bölüm hiyerarşisi, uzmanlık hiyerarşisi, tür hiyerarşisi. (Nesne Teknolojisi Sözlüğü,
Firesmith, Eykholt, 1995)
 Hiyerarşi, öğeleri belirli bir sırada veya rütbede düzenler (örneğin, karmaşıklık
ve sorumluluk). Bu organizasyon bakış açısına bağlıdır. Belirli bir kavramın
farklılıklarını veya varyasyonlarını tanımlamak için bir hiyerarşi kullanmak,
daha açıklayıcı ve tutarlı soyutlamalar ve daha iyi bir sorumluluk dağılımı
sağlar.
 Herhangi bir sistemde birden çok soyutlama hiyerarşisi olabilir (örneğin, bir
finansal uygulamanın farklı müşteri ve hesap türleri olabilir).
 Hiyerarşi, bir organizasyon şeması veya işlevsel bir ayrıştırma değildir.
 Hiyerarşi taksonomik bir düzenlemedir. Hiyerarşi kullanımı, benzerlikleri ve
farklılıkları tanımayı kolaylaştırır. Örneğin botanik, bitkileri ailelere göre
düzenler. Kimya, elementleri periyodik bir tabloda düzenler.

Obje Nesne Nedir?

 Bir nesne, iyi tanımlanmış bir sının olan bir varlıktır- Yani. nesnenin amacı açık olmalıdır.
 Bir nesnenin iki temel bileşeni vardır: nitelikler ve eylemler. (attributes and operations)
 Nitelikler ve ilişkiler, bir nesnenin durumunu temsil eder. Eylemler, nesnenin davranışını
temsil eder.
 Daha Resmi Bir Tanım: Bir nesne iyi tanımlanmış bir sınıra (boundary) ve durumu (state) ve
davranışı (behavior) sarmalayan (encapsulate) bir kimliğe sahip bir varlıktır.
 Bir nesnenin Durumu vardır. Durum, bir nesnenin ömrü boyunca, bazı koşulları sağlayan, bazı
faaliyetleri ifa eden veya bazı olayları bekleyen bir şart veya haldir. Bir nesnenin durumu
normalde zamanla değişir.
 Bir Nesnenin Davranışı vardır. Davranış, bir nesnenin nasıl hareket edip nasıl tepki vereceğini
belirler. Bir nesnenin görünür davranışı, cevaplayacağı bir dizi mesajla (nesnenin
gerçekleştirebileceği işlemler) modellenir.

Sınıf Nedir?

 Bir sınıf, aynı nitelikleri, eylemleri, ilişkileri ve anlamı paylaşan bir dizi nesnenin tarifidir.
 Nesne, bir sınıfın tezahürüdür (oluşudur).
 Sınıf bir soyutlamadır, şöyle ki
o İlgili özellikleri vurgular.
o Diğer özellikleri bastırır.

Sınıf ve nesneler arasındaki ilişki

 Sınıf, bir nesnenin soyut tanımıdır.

o Sınıftaki her nesnenin yapısını ve davranışını tanımlar.
o Nesne oluşturmak için bir şablon görevi görür.
  Sınıflar nesne koleksiyonları değildir.
 Sınıf, aynı sorumlulukları, ilişkileri, işlemleri, nitelikleri ve anlambilimi paylaşan bir dizi
nesnenin açıklamasıdır.
 Bir nesne bir sınıf tarafından tanımlanır. Bir sınıf, içindeki tüm nesnelerin yapısı ve davranışı
için bir şablon tanımlar. Bir sınıftan oluşturulan nesnelere aynı zamanda sınıfın örnekleri de
denir.
 Sınıf statik açıklamadır; nesne o sınıfın koşu zamanı oluşudur.
 Gerçek dünya nesnelerinden modelleme yaptığımız için, yazılım nesneleri gerçek dünya
nesnelerini temel alır ancak yalnızca sistem bağlamında var olurlar.
 Gerçek dünyadaki nesnelerden başlayarak, umursamadığınız şeyleri soyutlayın. Daha sonra bu
soyutlamaları alın ve onları önemsediğiniz şeylere göre kategorilere ayırın veya sınıflandırın.
Modeldeki sınıflar bu sınıflandırma işleminin sonucudur.
 Bu sınıflar daha sonra yazılım nesneleri oluşturmak için çalışan bir yazılım sistemi içinde
şablonlar olarak kullanılır. Bu yazılım nesneleri, başlangıçta başladığımız gerçek dünya
nesnelerini temsil eder.
 Gerçek dünya nesnelerini temsil etmeyen bazı sınıflar/nesneler tanımlanabilir. Tasarımı
desteklemek için oradalar ve "yalnızca yazılımdır".

Sınıf İlişkileri

Genelleştirme

 Bir sınıfın bir veya daha fazla sınıfın yapısını ve/veya davranışını paylaştığı sınıflar arasındaki
ilişki.
 Bir alt sınıfın bir veya daha fazla üst sınıftan miras aldığı bir soyutlamalar hiyerarşisini tanımlar
o Tek miras
o Çoklu kalıtım
 "Bir tür" ilişkidir

Polymorphism

 Birçok farklı uygulamayı tek bir arayüzün arkasına gizleyebilme yeteneği,

Yapısal davranışsal modelleme (structural behavioral modeling)

Tüm nesne yönelimli sistem geliştirme yaklaşımları use case dayalı, mimari merkezli,
yinelemeli ve artımlı yaklaşımlardır. Use case , bir sisteminin çevresi ile etkileşime girme biçimini
temsil etmenin resmi bir yoludur. Temel olarak bir use case, bir iş bilgi sistemindeki iş süreçlerine üst
düzey bir genel bakıştır. Pratik açıdan bakıldığında, use case er nesne yönelimli bir sistemin tam
temelini temsil eder. Use caseler cari sistemi (yani, as-is sistemi) veya geliştirilmekte olan yeni sistemi
(yani, to-be sistemi) belgeleyebilir. Nesneye yönelik sistemlerin kullanım senaryosu odaklı olduğu göz
önüne alındığında, kullanım senaryoları use caseler aynı zamanda test (bkz. Bölüm 12) ve kullanıcı
arayüzü tasarımı (bkz. Bölüm 10) için de temel oluşturur. Kullanım senaryosu odaklı testin iki biçimi
takip edilecek talimatlar (daha sonra açıklanacaktır). bu bölüm) ve rol yapma (Bölüm 5'te anlatılmıştır)
dır.

Mimari merkezli bir perspektiften bakıldığında, use case modellemesi, süreci ve

destekleyici sistemleri çalıştıran iç mekanizmalardan ziyade kullanıcıların süreci nasıl gördüklerini
göstermesi açısından bir iş sürecinin harici veya işlevsel bir görünümün oluşturulmasını destekler.
Nesne yönelimli sistem geliştirme yaklaşımları artımlı ve yinelemeli bir şekilde geliştirilir. Her ne kadar
üç mimari görüşü sırayla sunsak da, bu öncelikle pedagojik nedenlerden dolayı yapılmaktadır. Bir iş
bilgi sisteminin talep ve ihtiyaçlarını tam olarak kavramak ve temsil etmek için yalnızca iş süreci ve
işlevsel modeller (bu bölümde açıklanmıştır) boyunca yineleme yapmanız gerekmeyeceğini, aynı
zamanda üç mimari görününmün tamamında da yineleme yapmanız gereceğini göreceksiniz.

Faaliyet diyagramları genellikle iş süreçlerine ve use case modelimize ilişkin anlayışımızı

geliştirmek için kullanılır. Teknik olarak, bir faaliyet diyagramı her türlü süreç modelleme faaliyeti için
kullanılabilir. Süreç modelleri bir iş sisteminin nasıl çalıştığını gösterir. Gerçekleştirilen süreçleri veya
faaliyetleri ve nesnelerin (verilerin) bunlar arasında nasıl hareket ettiğini gösterirler. Bir süreç modeli,
bilgisayarlı olsun ya da olmasın, cari bir sistemi (yani, as-is sistemi) veya geliştirilmekte olan yeni bir
sistemi (yani, to-be sistemi) belgelemek için kullanılabilir. Günümüzde pek çok farklı süreç modelleme
tekniği kullanılmaktadır.

Faaliyet diyagramları ve kullanım senaryoları mantıksal modellerdir; iş alanının

etkinliklerini, bunların nasıl yürütüldüğünü tavsiye etmeden açıklayan modellerdir. Mantıksal
modeller bazen problem alanı modelleri olarak da adlandırılır. Bir kullanım senaryosu veya faaliyet
diyagramını okumak, prensip olarak, bir faaliyetin bilgisayar ortamında mı yoksa manüel olarak mı
gerçekleştirildiğini, bir bilgi parçasının kâğıt üzerinde mi yoksa Web aracılığıyla nu toplandığını veya
bilginin bir dosya dolabına mı yoksa büyük bir veri tabanına nu yerleştirildiğini göstermemelidir. Bu
fiziksel ayrıntılar, mantıksal modeller fiziksel modellere dönüştürüldüğünde tasarım sırasında
tanımlanır. Bu modeller, sonuçta sistemi oluşturmak için gereken bilgileri sağlar. Analistler, öncelikle
mantıksal faaliyetlere odaklanarak, uygulama ayrıntılarıyla dikkatleri dağılmadan işin nasıl yürümesi
gerektiğine odaklanabilirler.

İlk adım olarak proje ekibi, kullanıcılardan talep ve ihtiyaçları toplar (bkz. Bölüm 3).
Toplanan talep ve ihtiyaçları kullanarak, proje ekibi daha sonra kullanım senaryoları ve kullanım
senaryosu diyagramları vasıtasıyla iş süreçlerini ve ortamlarını tanımlar. Ardından, kullanıcılar, iş
süreçlerini etkinlik diyagramları biçiminde modellemek için ekiple yakın işbirliği içinde çalışır ve ekip,
her kullanım durumu için bir kullanım durumu açıklaması oluşturarak kullanım senaryosu ve etkinlik
diyagramlarında açıklanan iş süreçlerini belgelendirir. Sonunda takım doğrulandı! Her üç modelin
(kullanım senaryosu diyagramı, aktivite diyagramı/diyagramlan ve kullanım senaryosu açıklamaları)
birbiriyle uyumlu olmasını sağlayarak iş süreçlerini yönetir ve doğrular. Nihayet ekip, üç modelin de
(kullanım senaryosu diyagramı, faaliyet diyagramı/diyagramlan ve kullanım senaryosu açıklamaları)
birbiriyle uyumlu olmasını sağlayarak iş süreçlerini doğrular ve geçerler. İş süreçlerine ilişkin cari
anlayış fonksiyonel modellerde belgelendikten sonra ekip yapısal modellemeye geçmeye hazırdır
 Mimari merkezli bir perspektiften bakıldığında yapısal modelleme, sistemin temeldeki iş
süreçlerini desteklemek için nasıl yapılandırıldığını göstermesi açısından bir iş bilgi sisteminin dahili
yapısal veya statik görünümünün oluşturulmasını destekler. Nihayet, iş süreci ve işlevsel modellemede
olduğu gibi, sadece yapısal modeller (bu bölümde anlatılmıştır) arasında yineleme yapmanız
gerekmediğini, aynı zamanda bir iş bilgi sisteminin gereksinimlerini tam olarak yakalamak ve temsil
etmek için üç mimari görünümün (işlevsel, yapısal ve davranışsal) tamamını yinelemeniz gerekeceğini
göreceksiniz.

Yapısal model, bir iş sistemi tarafından kullanılan ve oluşturulan nesneleri temsil etmenin
resmi bir yoludur. Haklarında malumat yakalanan insanları, yerleri veya şeyleri ve bunların birbirleriyle
nasıl ilişkili olduğunu gösterir. Yapısal model, modelin zamanla daha ayrıntılı ve daha az kavramsal
hale geldiği yinelemeli bir süreç kullanılarak çizilir. Analizde analistler, nesnelerin nasıl saklandığını,
oluşturulduğunu veya değiştirildiğini belirtmeden nesnelerin mantıksal organizasyonunu gösteren
kavramsal bir model çizerler. Bu model herhangi bir uygulama veya teknik ayrıntı içermediğinden
analistler, modeli sistemin gerçek iş gereksinimleriyle eşleştirmeye daha kolay odaklanabilirler.

Tasarımda analistler kavramsal yapısal modeli, nesnelerin veritabanlannda ve yazılımda

nasıl düzenleneceğini yansıtan bir tasarım modeline evriltirler. Bu noktada model reduncancy
(lüzumsuz fazlalık) açısından kontrol edilir ve analistler nesnelerin çekilmesini kolaylaştırmanın
yollarını araştırır. Tasarım modelinin özellikleri tasarım bölümlerinde ayrıntılı olarak tartışılmaktadır.