Küba ERP envanter modülü için yazılım mimarisi

özet

Mevcut çalışmada Küba ERP'nin Envanter Modülü için Servis Odaklı Mimari önerisi ortaya çıkarılmıştır, böylece: taşınabilir, güvenli, ölçeklenebilir ve diğer sistemlerle entegre edilebilir ve aynı zamanda başkalarına genişletilebilir ERP modülleri.

erp-hizmet odaklı-mimari

Yazılım mimarisinin tanımlanması ve tanımlanması için önerilen hedefe ulaşmak için, onu oluşturan unsurlar ve konuyla ilgili en prestijli yazarların yanı sıra Envanter Yönetim Sistemi ve Depolar (SIGIA).

Mimarinin tanımının ve tanımının başarısı, esas olarak gelişimi sırasında alınan mimari kararlara, karar verilen en uygun teknolojiye ve tasarımın dikkate alındığı sistemin kendisinin olumlu bir şekilde gelişmesine izin veren yönlerine bağlı olacaktır. bileşenler arasındaki ilişkiler ve konfigürasyonlar ve geliştirilen sistemin yapısının düzenlenmesine izin vererek, tüm ekibe neyin geliştirilmekte olduğu hakkında net bir fikir verir.

Anahtar kelimeler

Yazılım mimarisi, stil, desen, bileşen, çerçeve, Servis Odaklı Mimari (SOA), web servisi, entegrasyon, Kurumsal Kaynak Planlaması (ERP), XML, SOAP, UDDI, WSDL.

Giriş

Sovyet Sosyalist Cumhuriyetler Birliği'nde sosyalizmin ortadan kalkması ve 1990'larda ABD'nin Küba'ya yönelik ablukasının yoğunlaşmasıyla Küba ekonomisi felç oldu. Bu nedenle, ülkenin ekonomi politikasını yeniden tasarlama sürecine ihtiyacı vardı. O zamandan beri, ulusun durumunu mümkün olan en düşük sosyal maliyetle aşmak amacıyla aşamalı bir ekonomik önlemler programı uygulanmaya başlandı.

Ülkenin karşılaştığı ekonomik zorlukların bir sonucu olarak, Küba devleti ekonominin çeşitli stratejik sektörlerine yatırım yapmaya başladı ve en iyi örnek olan toplumda bilgisayarlaşma düzeyini yükseltmek için büyük miktarda kaynak tahsis etmeye başladı. Güvenilir ve güncel, yüksek kaliteli yazılım üretmek ve dünya pazarına yerleştirmek için Bilgisayar Bilimleri Üniversitesi'nin oluşturulmasıdır. Bu stratejinin bir sonucu olarak, günümüzün teknolojik taleplerini karşılayan daha verimli ve daha kaliteli iş sistemleri elde edilmiştir.

İş geliştirme ile başlayan şirketler, üretimlerinde veya verdikleri hizmetlerde daha fazla verimlilik elde etmek için çalışırlar. Bu nedenle iş süreçlerinin otomasyonuna izin veren ve böylece onları daha verimli hale getiren bilgisayar sistemlerinin kullanılması. Bunu mümkün kılan sistemlerden biri, bir şirketin tüm iş süreçlerini tek bir uygulamada entegre eden ve otomatikleştiren bilgi yönetim sistemleri olan Kurumsal Kaynak Planlama (ERP):, lojistik, muhasebe, proje yönetimi, envanterler, depo kontrolü, siparişler, bordro, insan kaynakları.

ERP'ler, iş kullanıcılarına destek, karar verme için etkili bilgi yönetimi, hızlı yanıt süreleri ve toplam operasyon maliyetlerinde azalma sağlar. (Martínez ve diğerleri, 2001).

Bir şirketin kaynaklarının planlanmasındaki en önemli süreçlerden biri envanter sistemleridir ve bu nedenle ERP sistemlerinin geliştirilmesinde sağlam bir temel oluşturmaktadır.

Günümüz ekonomisinde envanter yönetimi, üretkenliğin kritik bir bileşeni olduğu için işletme yönetimi sorunlarının zirvesine ulaşmıştır. Stoklar çok yüksek tutulursa, maliyet finansal likidite sorunları olan bir şirketin oluşmasına neden olabilir. Öte yandan, stok seviyesinin yetersiz kalması halinde, müşterilere tatmin edici bir şekilde hizmet edilemeyebilir, bu da azalan kar ve piyasa kaybı ile sonuçlanabilir (Sanchez, 2006). Dolayısıyla, sağlıklı stoklar taşımanın, depodaki hareketli ürünler söz konusu olduğunda herhangi bir şirket ve endüstriye daha fazla güvenilirlik sağlayacağı görülebilir.

En Cuba existen Sistemas de Gestión de Inventarios, entre ellos se tienen: El Sistema de Inventario del Patrimonio Cultural y Natural (SIP), como su nombre lo indica fue creado con fines patrimoniales como: el registro, el control y la conservación de los mismos. El Sistema Informatizado para el Procesamiento del Inventario Forestal (INVENFOR 1.0), realizado con el fin de registrar y procesar los datos obtenidos del inventario forestal en función de estimar los parámetros dasométricos de los Rodales de forma tal que tribute a una planificación del manejo forestal más eficiente. Otros ejemplos de sistemas son: DRIM, FONDUS, SI e IHMM 2000 de la empresa GET (Grupo de Electrónica para el Turismo), este último con el objetivo de usarse en las instalaciones hoteleras.

Hepsinin ortak bir yanı var ve bu sistemlerin çoğunun belirli şirketlerin işletilmesi için uzmanlaşmış olması nedeniyle esnek değil, tasarımlarında kapalı, envanter yönetimi sürecini standartlaştırmak zor ve diğer sistemlerle entegrasyon, çözülmesi önerilen temel unsurlar.

Bu, daha esnek, modern, böylece en son teknoloji ile donatılmış şirketlerin ve ülkenin mevcut ihtiyaçlarını karşılayan yeni bir envanter yönetim sisteminin geliştirilmesinin gerekliliğidir. dost, güvenilir ve güvenli, ayrıca diğer sistemlerle entegre olabiliyor. Tam olarak müşterilerin özel ihtiyaçlarına göre yapılandırılabilmesi, Maliye ve Fiyatlar Bakanlığı tarafından oluşturulan yeni düzenlemelere uymasıdır. Kısacası, eski sistemlerin sağlamadığı tüm yeni gereksinimleri karşıladığı için artık kullanılmamaktadır.

Herhangi bir yazılım sisteminin tatmin edici bir şekilde geliştirilmesi ve aynı zamanda belirli bir kalite ve düşük maliyeti garanti etmesi için, bu sürece rehberlik eden geliştirme metodolojilerinin kullanılması gerekir. Geliştirme sürecindeki önemli bir unsur, geliştirilen sistemin yapısını organize etmeyi ve anlamayı sağlayan ve tüm ekibe geliştirilmekte olan şey hakkında net bir fikir veren yüksek seviyeli bir tasarım anlayışıdır.

Yazılım geliştirme sürecinde, sürecin kendisini sınırlayan ve engelleyen durumların ortaya çıktığı bir gerçektir. Bunlar arasında aşağıdakileri görebilirsiniz: kıt yeniden kullanım, yazılım öğelerinin zayıf seçimi, mimari stiller, mimari desenler, iletişim protokolleri, tasarım öğelerinin bileşimi, tasarım öğelerine işlevselliğin atanması, araçlar, çerçeveler, senkronizasyon sorunları ve verilere erişim, programcılar programın yapmasını istedikleri sürece herhangi bir şekilde kod yazarak ölçeklenebilirlik, performans ve maliyet konularında tüm bunları etkiler. Tüm bu sorunların çözümü bir Yazılım Mimarisinin doğru tanımında ve açıklamasındadır.

Yazılım Mimarisi, sistemleri daha modüler hale getirme ve bileşenlerin yeniden kullanılmasına izin verme ihtiyacından kaynaklanır, böylece uygulanması maliyeti önemli ölçüde azaltır. Ayrıca, sistemin elemanları arasında düşük bir bağlantının korunmasına izin verir, ancak çok yüksek bir uyumla, bileşenlerin yapısı, iletişim yolları ve aralarındaki ilişkiler açıkça belirlendiğinden.

Yukarıdakilerin hepsi aşağıdaki sorunun tanımlanmasına yol açtı :

Envanter Yönetim Sisteminin geliştirme sürecinde, ölçeklenebilir, güvenli, taşınabilir ve diğer iş yönetim sistemleriyle entegre olmasını sağlayan üst düzey tasarım kararları nasıl verilir?

Araştırma, çalışma amacına odaklanmaktadır: Envanter Yönetim Sisteminin Geliştirme Süreci. Bunun için aşağıdaki genel hedef önerilmektedir : Envanter Yönetim Sisteminin ölçeklendirilebilir, güvenli, taşınabilir ve diğer iş yönetim sistemleriyle bütünleştirilebilmesini sağlayan Servis Odaklı Yazılım Mimarisi önerin.

Eylem alanı olarak tanımlama : Envanter Yönetim Sistemi için Yazılım Mimarisi.

Araştırma, önerilen hedefi gerçekleştirmek için aşağıdaki görevler kullanılarak gerçekleştirilmiştir :

Farklı mimari yaklaşımlar, nasıl geliştikleri, ana eğilimler ve tanımların yanı sıra iş sistemlerinin geliştirilmesinde gelişen en önemli mimari stiller hakkında bilgi edinmek için Yazılım Mimarisi sanatının bir çalışmasının yapılması. Kullanılacak mimari stiller, bunların kullanımını ve bunların uygulanmasını gerekçelendirir.Kullanılacak çerçevelerin ve geliştirme araçlarının tanımlanması, Mimarinin tanımı ve tanımı, uzman kriterlerine göre doğrulama.

Görevleri yerine getirmek için aşağıdaki yöntemler kullanıldı:

Teorik Yöntemler

Tarihsel - Mantıksal: Mimari model ve yaklaşımların geliştirilmesindeki güncel eğilimleri belirlemek. Analitik - Sentetik: Araştırmada işlenen bilgilerden sonuçlara varmak ve önerilen mimari modelin özelliklerini belirlemek. Sistemik Yöntem: Sistem elemanlarını ve ilişkilerini tanımlamak.

Ampirik yöntemler

Ölçüm: Vaka çalışmasının kritik durumlarında yanıt sürelerinin değerlendirilmesi için.

Olası sonuçlar

Envanter Yönetim Sistemi için ölçeklendirilebilir, güvenli, taşınabilir ve diğer işletme yönetim sistemleriyle bütünleştirilebilmesini sağlayan Hizmet Odaklı Yazılım Mimarisi için öneri.

Mevcut çalışma üç bölüm halinde yapılandırılmıştır

Bölüm 1: Teorik Temel

Bu bölümde araştırmanın teorik temeli, Yazılım Mimarisi sanatının yanı sıra farklı mimari yaklaşımlar, ana eğilimler ve tanımlar üzerine yapılan bir araştırmaya dayanılarak gerçekleştirilmektedir. Patlayan, avantajlarını ve dezavantajlarını ortaya koyan en önemli mimari stiller üzerinde bir çalışma yapılmıştır. Kısacası, araştırmanın temelini oluşturan teorik çerçevenin modellenmesine izin verecek tüm bu yönler.

Bölüm 2:

Bu bölümde araştırmanın teorik tasarımında ortaya çıkan soruna çözüm önerisi getirilmiş, Bilişim Bilimleri Üniversitesi tarafından verimli projelerde kullanılmak üzere önerilen Artefakt Dokümanı Mimarlık Tanımı tarafından verilmiştir.

Bölüm 3:

Bu bölüm, Stok Yönetim Sistemi için önceki bölümde yapılan mimari teklifi destekleyecek araçları açıklamaktadır. Ayrıca, kalite açısından önerilen çözümün bir analizi yapılır.

Bölüm 1: Teorik Temel

Giriş

Bu bölümde araştırmanın kuramsal temeli, Yazılım Mimarisi sanatının yanı sıra farklı mimari yaklaşımlar, ana eğilimler ve tanımlar üzerine bir çalışma yürütülmektedir. Envanter Yönetim Sisteminin geliştirilmesi için doğru olanı seçmek için avantajlarını ve dezavantajlarını ortaya koyan, iş ve yönetim sistemlerinin geliştirilmesinde gelişen en önemli mimari stillerin incelenmesi. Yazılım Mimarisi, mimari modelleme dilleri, günümüzün bir meydan okuması olarak Servis Odaklı Mimari tarzı ve Yazılım Mimarisinde kalitenin farklı düzeylerinin analizi.

Yazılım Mimarisi Sanatı

Yazılım Mimarisi, sadece birkaç yıllık sürekli çalışmanın genç bir uygulamasıdır. Kökleri 60'lı yıllarda var, ancak 90'lı yıllara kadar Dewayne Perry ve Alexander Wolf, bugün bilinen anlamda ortaya koymadı.

Benzer şekilde Bass bunu şu şekilde tanımlar: “Bir bilgisayar veya program sisteminin Yazılım Mimarisi, yazılım bileşenlerini, dışarıdan görünen bileşenlerin özelliklerini ve ilişkileri içeren sistem yapılarının yapısıdır. onların arasında." (Pressman, 2002).

Öte yandan, birçok mimar tarafından uluslararası olarak en çok tanınan tanım endüstri tarafından vergilendirilir ve bu nedenle aşağıdakileri ifade eden IEEE 1471'e aittir: «Yazılım Mimarisi, bileşenlerinde, bunların arasındaki ilişkilerde yer alan bir sistemin temel organizasyonu ve çevre ve tasarım ve evrimine rehberlik eden ilkeler. » (Reynoso, 2006).

Yazılım Mimarisi'nin var olan çok sayıda tanımına rağmen, büyük çoğunluk bunun sistemin geniş yapısına (yüksek düzeyde soyutlama), aralarındaki bileşenlerden ve ilişkilerden oluşan bir yapıya atıfta bulunduğunu kabul eder. Yazılım Mimarisinin, bir Bilgisayar Sisteminin yazılım öğelerinin yapısı ve organizasyonu olarak tanımlandığı şey için, bu öğelerin nasıl ve hangi koşullar altında iletişim kuracağı.

Yazılım Mimarisinin şu olduğu sonucuna varılabilir: herhangi bir geliştirme yönteminden bağımsız bir disiplin, yüksek düzeyde sistem soyutlamasını temsil eder ve işlevsel olmayan gereksinimlere yanıt verir, çünkü bunlar uygulamayı modellemek ve tasarlamaktan memnun olur. Aynı şekilde Yazılım Mimarisi'nin olmadığı sonucuna varılabilir: yazılım tasarımı, olgun bir düzenleme, akademide endüstride olduğu gibi ele alınır.

1.2.1.2. stil

Genel olarak, kişi mimarlık hakkında bir şekilde söz konusu olduğunda, yakından ilişkili olan belirli bir şeye atıfta bulunur: sınıflandırmalar. Gerçek şu ki, sadece sınıfsal bir mesele değil, aynı zamanda her mimari formun büyük bir ilişkisi vardır ve araçlar, kavramlar, deneyimler ve problemlerle ilişkilidir.

Bu sınıflandırmalar, mimari sınıflar, mimari türler, tekrarlayan arketipler, türler, topolojik paradigmalar, ortak çerçeveler ve birkaç düzine diğerleri gibi çeşitli şekillerde çağrılmıştır. On yıldan fazla bir süredir bu mimari niteliklere denir: stiller veya alternatif olarak mimari desenler. Stiller sadece yüksek düzeyde soyutlama ile betimsel teorik mimaride kendini gösterir; her yerde kalıplar. (Reynoso ve diğerleri, 2004)

Stilin ilk açık tanımları Dewayne Perry ve Alexander Wolf tarafından Ekim 1992'de önerilmiş gibi görünüyor. Disiplinin temel yönlerinden biri olarak mimari stiller hakkında akıl yürütmeler yapıyorlar. “Stil, bir tür artikülasyon veya mimari organizasyon tanımlayan tanımlayıcı bir kavramdır. Stil seti, yazılım yapılarının olası temel biçimlerini kataloglarken, karmaşık biçimler temel stillerin bileşimi ile ifade edilir ”(Perry ve diğerleri, 1992).

Pressman'a göre (Pressman, 2002), bir stil, sistemin gerektirdiği bir işlevi yerine getiren bir dizi bileşeni, bileşenler arasında iletişimi, koordinasyonu ve işbirliğini sağlayan bir dizi konektörü, bileşenlerin sistemi oluşturmak için nasıl entegre edildiğini ve tasarımcının sistemin tüm bölümlerini anlamasını kolaylaştıran anlamsal modelleri tanımlar. Mimari tarz aynı zamanda bir inşaat modelidir.

Stiller bileşenleri, konektörleri, yapılandırmaları ve kısıtlamaları birleştirir. Bir stilin açıklaması doğal dilde veya diyagramlarda formüle edilebilir, ancak bunu bir Mimari Tanımlama Dili (ADL) veya Resmi Şartname Dilleri'nde (LFE) yapmak en iyisidir.

Şu sonuca varılabilir:

Bir stil, AS'nin dört “C” sini (elemanlar, konektörler, konfigürasyonlar ve kısıtlamalar) tasarlar ve daha sonra tasarım yoluyla rafine edilecek çözüm yapılarını sentezlemeye yarar. Betonarme konfigürasyonlar, mimari hatalardan kaçınarak uygulamaların olası kalıplarını tanımlar, farklı fonksiyonel olmayan gereksinimler setinden önce alternatif mimarileri bilinen avantaj ve dezavantajlarla değerlendirmeyi sağlar.

1.2.1.3. Desen

Çerçeve kavramı, yazılım sistemi geliştirmenin birçok alanında kullanılmaktadır. Web uygulamalarının, masaüstü uygulamalarının, tıbbi uygulamaların, oyun geliştirmenin ve aklınıza gelebilecek herhangi bir alanın geliştirilmesi için çerçeveler bulabilirsiniz.

Genel olarak, çerçeve terimi, bir uygulamanın geliştirilmesi için özelleştirilebilir ve değiştirilebilir bileşenlerden oluşan bir yazılım yapısına değinmektedir. Başka bir deyişle, bir çerçeve, belirli bir uygulama geliştirmek için son parçaların eklenebileceği eksik ve yapılandırılabilir bir genel uygulama olarak düşünülebilir.

Özet olarak, bir çerçeve, bir uygulama geliştirmek için özel ihtiyaçlarına göre programcı tarafından uyarlanması gereken bir uygulamanın iskeletidir.

1.2.2. Trendler

Günümüzde Yazılım Mimarisi okullarının varlığını açıkça onaylayan hiçbir şey olmamasına veya şu anda her birinin özelliklerini analiz eden bir referansta, şu anda altı akım geniş bir şekilde ayırt edilebilir. Bu akımlardan birine ait olmak deterministik bir şeyi temsil etmez, çünkü farklı zamanlarda Yazılım Mimarisi'nin bazı uygulayıcıları farklı çerçevelerde çalışan farklı işler yaparlar ya da sadece kavramlarını değiştirirler.

Yazılım Mimarisi okullarının önerilen bölümü aşağıdaki gibidir:

Mühendislik ve nesneye yönelik tasarımın bir aşaması olarak mimarlık. Açıkçası Grady Booch'un; Ona göre, Yazılım Mimarisi "geliştirme sırasında uygulanan tüm stratejik ve taktik kararların oluşturduğu bir sistemin mantıksal ve fiziksel yapısıdır." Diğer tanımlar, Yazılım Mimarisinin bu bakış açısıyla, Kruchten 4 + 1 modelinin beş klasik görünümü ile açıklanabilecek organizasyon, yapısal elemanların seçimi, davranış, kompozisyon ve mimari stil hakkındaki kararlarla ilgili olduğunu ortaya koymaktadır. (Reynoso, 2006) Statik bir stil, ADL ve görüş modeline dayanan yapısal mimari. Bu eğilimin temsilcileri çoğunlukla Carnegie Üniversitesi'nden akademisyenlerdir, aynı zamanda akademideki baskın Yazılım Mimarisinin vizyonudur ve Yazılım Mimarisini tanımak için en önemli çabayı göstermiş olmasına rağmen disiplini, kategorileri ve araçları endüstriyel uygulamada hala tam olarak anlaşılamamıştır. Hareketin içinde farklı bölümler görebilirsiniz. Menlo Park'taki SRI'da Mark Moriconi grubu tarafından temsil edilen "boxoloji" nin gayri resmi bir varyantı ve daha biçimci bir tarafı var. Prensip olarak, formalizasyon açısından üç yöntem tanınabilmektedir; daha gayri resmi olanlar sözlü açıklamalar veya kutu diyagramlar kullanırlar,ara karakterleri ADL'leri kullanır ve en talepkar CHAM ve Z gibi resmi şartname dillerini kullanır. Mevcut süre boyunca, mimari tasarım sadece en yüksek soyutlama seviyesi değil, aynı zamanda çakışmak zorunda değildir. uygulamaların açık yapılandırması; programlama dillerine veya kod parçalarına referanslar nadiren bulunur ve genel olarak hiç kimse sınıflar veya nesneler hakkında konuşmaz. Bazı katılımcılar veri modelini Yazılım Mimarisi'nin (Shaw, Garlan, vb.) Kaygılarından hariç tutarken, diğerleri ilgisi konusunda ısrar etmektedir (Medvidovic, Taylor). (Reynoso, 2006)programlama dillerine veya kod parçalarına referanslar nadiren bulunur ve genel olarak hiç kimse sınıflar veya nesneler hakkında konuşmaz. Bazı katılımcılar veri modelini Yazılım Mimarisi'nin (Shaw, Garlan, vb.) Kaygılarından hariç tutarken, diğerleri ilgisi konusunda ısrar etmektedir (Medvidovic, Taylor). (Reynoso, 2006)programlama dillerine veya kod parçalarına referanslar nadiren bulunur ve genel olarak hiç kimse sınıflar veya nesneler hakkında konuşmaz. Bazı katılımcılar veri modelini Yazılım Mimarisi'nin (Shaw, Garlan, vb.) Kaygılarından hariç tutarken, diğerleri ilgisi konusunda ısrar etmektedir (Medvidovic, Taylor). (Reynoso, 2006)Radikal mimari yapısalcılık. Bu, UML dünyası ile daha çatışmacı bir tutum alan, çoğunlukla Avrupa olan önceki trendden kopukluktur. Bu hareket içinde, biri Yazılım Mimarisi için nesne yönelimli modellemenin alaka düzeyini tamamen dışlayan en az iki eğilim vardır ve diğeri de UML'nin yeni meta modellerini ve stereotiplerini duruma göre düzeltici olarak tanımlamaya çalışır. (Reynoso, 2006) Desenlere dayalı mimari. Nesneye yönelik tasarımdan kaynaklanan bir modelin önemini kabul ederken, modellemede UML ile metodolojide olduğu kadar sıkı bir şekilde bağlanmamıştır. Bu varyantın referans olarak tanıdığı desenlerin metni Buschmann ve diğerleri tarafından POSA serisidir ve ikincil olarak Dörtlü Bant metnidir. Tasarım, mimari stillere benzer şekilde tanımlanan önceden var olan desenleri tanımlamak ve ifade etmekten oluşur. (Reynoso, 2006) Süreç mimarisi. 21. yüzyılın başından beri, SEI merkezli ve bazı birinci nesil Carnegie Mellon mimarlarının ve ikincisinin birçok yeni isminin katılımıyla: Rick Kazman, Len Bass, Paul Clements, diğerleri arasında. Yazılım Mimarisine özgü yaşam döngüsü modelleri ve gereksinimleri ortaya çıkarma teknikleri, beyin fırtınası, tasarım, analiz, alternatif seçim, geçerlilik, karşılaştırma, kalite tahmini ve ekonomik gerekçe oluşturmaya çalışır. (Reynoso, 2006) Senaryolara dayanan mimari. En yeni akış. Hollanda merkezli, ağırlıklı olarak Avrupa hareketidir. Yazılım Mimarisi bağlantısını, bazen klasik yapısal mimaride bulanıklaşan, sistemin gereksinimleri ve işlevselliği ile kurtarır. UML kullanım senaryoları genellikle bu akışta gayri resmi veya ara sıra bir araç olarak kullanılır, çünkü kullanım senaryoları olası senaryolardan biridir. Kullanım örnekleri nesne yönelimli değildir. Bu yöntemle ilgili yazarlar, ATAM, CBAM, QASAR ve diğer SEI yöntemlerinin kodlayıcıları dışında, Eindhoven Teknik Üniversitesi, Brije Üniversitesi, Groningen Üniversitesi ve Philips Research'ün Hollandalı mimarları olmuştur. (Reynoso, 2006)

1.2.3. Yazılım Mimarisi ve Tasarım Arasındaki Fark

Yazılım Mimarisi akademik topluluğu, tasarımın mimariyle karıştırılmasından büyük ölçüde farklıdır, ancak konuya atıfta bulunurken bazı uygulayıcılar her iki alan arasındaki ilişkiyi çok belirsiz bırakır.

Mimarlık ve tasarım bir dereceye kadar aynı amaca hizmet eder. Bununla birlikte, Yazılım Mimarisi, sistem yapısına ve bileşen ara bağlantılarına odaklanır ve kendisini daha düşük seviyeli soyutlamaların modellenmesine odaklanan nesne yönelimli tasarım gibi geleneksel yazılım tasarımından ayırır. algoritmalar ve veri türleri gibi. Yüksek seviyeli mimari geliştirildikçe, konektörleri ön plana çıkarak daha düşük seviyeli mimari elemanlara yayılarak mimarinin tasarıma dönüşmesine neden olabilir. (Reynoso ve diğerleri, 2004).

Yazılım Mimarisi, yazılım tasarımında nispeten yeni bir disiplindir ve aslında tasarım metodolojilerinin yanı sıra analiz metodolojilerini de kapsar. Çağdaş yazılım mimarı, sistem analisti, sistem tasarımcısı ve yazılım mühendisi olarak rollerin bir kombinasyonunu gerçekleştirir. Ancak mimari, işlevlerin yer değiştirmesinden daha fazlasıdır. Mimarlık kavramı, analiz ve tasarım faaliyetlerini daha geniş ve daha tutarlı bir tasarım çerçevesine koymaya çalışır. Ancak mimarlık bir yandan analiz ve diğer yandan tasarım toplamından biraz daha entegre. Metodolojilerin ve modellerin entegrasyonu AS'yi analiz ve tasarım tekniklerinin basit yan yana getirmesinden ayıran şeydir. (Albin, 2003).

Mimarlık daha yüksek bir soyutlama düzeyi ile ilgilidir; prosedürlerle değil bileşenlerle ilgilenir; arabirimlerle değil, bu bileşenler arasındaki etkileşimlerin; algoritmaların, prosedürlerin ve türlerin değil, bileşenlerin ve etkileşimlerin üzerine uygulanan kısıtlamaların Kompozisyona gelince, mimarinin kaba taneli, tasarımın prosedürel ince bileşimi vardır; Mimarideki bileşenler arasındaki etkileşimler, üst düzey bir protokolle (kelimenin teknik olmayan anlamıyla) ilgili olmakla birlikte, tasarımdakiler prosedür tipi etkileşimlerle (mesajlar, rutin çağrılar) ilgilidir (Perry, 1997).

Dolayısıyla, Yazılım Mimarisinin yazılım tasarımı olmadığı sonucuna varılabilir, çünkü yüksek bir soyutlamada bir projenin geliştirilmesinde daha erken bir aşamada meydana gelir, bileşenler, konektörler, konfigürasyonlar, kısıtlamalar ile ilgilenir, tasarımı detaylara bırakır Prosedürler, algoritmalar ve veri türleri gibi daha düşük seviyeli, daha rafine mimari unsurlar.

Yazılım Mimarisinin Soyutlama Düzeyleri

1.3.1. Mimari Tarzlar

1.3.1.1. Stil Sınıflandırması

Kaç tane ve stilleri nelerdir?

Mary Shaw ve David Garlan (Garlan ve diğerleri, 1994) tarafından yapılan bir çalışmada, daha önce “mimariler” olarak adlandırılan şeyin “tasarım modelleri” ile iç içe geçtiği aşağıdaki sınıflandırmayı öneriyorlar:

Boru filtreleri Veri soyutlama ve nesne yönlendirme organizasyonu Örtülü, olaya dayalı çağırma Katmanlı sistemler Havuzlar Tablo odaklı tercümanlar Dağıtılmış işlemler. Belirli bir dağıtılmış işlem biçimi, örneğin, istemci-sunucu mimarisi, ana program / altyordam organizasyonları, alana özgü yazılım mimarileri, durum geçiş sistemleri, kontrol süreç sistemleri, heterojen tarzlar.

Bass, Clements ve Kazman'ın (Bass ve diğerleri, 1998) temel bir metni olan Uygulamada Yazılım Mimarisinde, beş grupta stil sınıflarının sistemleştirilmesi sağlanmıştır:

Veri akışı (veri akışı, "yukarı akış" ın ne olduğunu alıcı kontrolü olmadan)
- Sıralı parti işlemi Veri akışı ağı Boru filtreleri
Çağrı ve geri dönüş (genellikle tek bir denetim iş parçacığında) hesaplamaya hakim tarz
- Ana Program / Altyordamlar Özet Veri Türleri Nesneler Çağrı Tabanlı İstemci-Sunucu Katmanlı Sistemler
Bağımsız bileşenler (neredeyse her zaman eşzamanlı olarak, bağımsız süreçler arasındaki iletişim kalıplarının hakimiyeti altındadır)
- Olaya yönelik sistemler İletişim süreçleri
Veri merkezli (bağımsız hesaplamalar tarafından manipüle edilen karmaşık merkezi depolama hakimdir)
- Havuz Yazı Tahtası
Sanal makine (bir talimatın başka birine çevrilmesi ile karakterize edilir)
- Çevirmen

Stiller, desenlerden farklı olarak birkaç tanedir ve inceleme sırasında varsayılan en güncel, özlü sınıflandırma şu şekilde sınıflara ayrılmıştır (Reynoso, 2005):

Veri Akışı Stilleri
- Boru ve filtreler
Veri Merkezli Stiller
- Arduvaz veya Depo Mimarileri
Çağrı ve Dönüş Stilleri
- Model-Görünüm-Denetleyici (MVC) Katmanlı Mimariler Nesne Odaklı Mimariler
Mobil Kod Stilleri
- Sanal Makine Mimarisi
Heterojen stiller
- Proses kontrol sistemleri Özellik Tabanlı Mimariler
Eşler Arası Stiller
- Olay Tabanlı MimarilerHizmet Odaklı Mimariler (SOA) Kaynak Tabanlı Mimariler

1.3.1.2. En Popüler Stiller

1960'larda ve 1970'lerde sunacağı işlevsel hizmetler açısından bir uygulama yapılandırmak doğaldı. Aslında, analiz ve yapılandırılmış tasarım gibi metodolojiler, daha sonra uygulama içindeki prosedürlere dönüştürülen hiyerarşik bir işlevsel ayrışmadan başlamıştır. Uygulamaların artan karmaşıklığı ve bunları geliştirme ihtiyacı ile bu yaklaşım yeterli değildi. 80'li ve 90'lı yıllarda nesneye yönelik yazılım geliştirme, diğer amaçların yanı sıra, daha sürdürülebilir uygulamaların oluşturulmasına izin vermek için popüler hale geldi. (Casallas ve diğerleri, 2005)

Bugün, nesneler yeterli görünmüyor, artık iyi olmadıkları için değil, sorun değiştiği için. Bu değişiklikler teknolojik ilerlemelerin ve müşteri beklentilerindeki artışın bir sonucudur. Örneğin, işlevsel olmayan özellikler daha kritik hale geldi ve uygulama entegrasyonu sorunu bir öncelik haline geldi. Esnek mimarilere sahip olmak ve kullanılan araçlardan mümkün olduğunca bağımsız olmak gerekir. (Ek 1) 'de sistem mimarilerinin yıllar içinde nasıl geliştiği gösterilmiştir.

Nesneye Dayalı Mimari

Bu mimari türü, Nesne Tabanlı Mimariler, Veri Soyutlama ve Nesneye Yönelik Organizasyon gibi çeşitli şekillerde bilinir.

Bu stilin bileşenleri soyut veri türlerinin nesneleri veya daha doğrusu örnekleridir. David Garlan ve Mary Shaw'un klasik karakterizasyonunda nesneler, yönetici olarak adlandırdıkları bir bileşen sınıfını temsil eder, çünkü kendi temsillerinin bütünlüğünü korumaktan sorumludurlar. Bu yönün önemli bir özelliği, bir nesnenin dahili temsiline diğer nesnelerden erişilememesidir. (Garlan ve diğerleri, 1994)

Billy Reinoso'ya (Reynoso ve diğerleri, 2004) göre, nesne yönelimli mimarilerin özellikleri özetlenecekse, şöyle söylenebilir:

Tarzın bileşenleri OO ilkelerine dayanır: kapsülleme, kalıtım ve polimorfizm. Bunlar aynı zamanda modelleme, tasarım ve uygulama birimleridir ve nesneler ve etkileşimleri, uygulamanın mimarisinin ve yapısının tasarımında endişelerin merkezinde yer alır Arayüzler uygulamalardan ayrıdır. Genel olarak, nesnelerin dağılımı şeffaftır ve teknolojinin son durumunda, nesnelerin yerel veya uzak olması önemli değildir. Dağıtılmış sistemler için nesne yönlendirmesine en iyi örnek, arabirimlerin Arayüz Açıklama Dili (IDL) kullanılarak tanımlandığı Ortak Nesne İsteği Aracı Mimarisi (CORBA); Bir Nesne İsteği Aracısı, dağıtılmış ortamlarda istemci nesneleri ve sunucu nesneleri arasındaki etkileşimlere aracılık eder.bir arabirimin birden çok sınıf tarafından uygulanabileceği kabul edilebilir. Tarzın birçok çeşidi vardır; örneğin bazı sistemler nesnelerin eşzamanlı görev olmasına izin verir; diğerleri ise nesnelerin birden fazla arayüze sahip olmasına izin verir.

Avantajı:

Bir nesnenin istemcilerini etkilemeden uygulanmasını değiştirebilirsiniz.Nesne geliştirme ortamında yeniden kullanılabilir bir varlıktır

Dezavantajları:

Prosedürel bir çağırma yoluyla başka bir nesneyle etkileşim kurmak için kimliği bilinmelidir. Basamaklı yan etki sorunları sunar: A B ve C kullanırsa, C'nin B üzerindeki etkisi A'yı etkileyebilir. büyük sistemler için çok iyi. Katmanlı Mimari

Garlan ve Shaw, katmanlı stili hiyerarşik bir organizasyon olarak tanımlar, öyle ki her katman hemen üstün katmana hizmet sağlar ve hemen alt katman tarafından sağlanan faydaları kullanır (Reynoso ve diğerleri, 2004). (Ek 2'ye bakınız)

Katmanlı bir tarzda, bağlayıcılar etkileşimin biçimlerini belirleyen protokollerle tanımlanır. Topolojik stil kısıtlamaları, her bir katmanın sadece bitişik katmanlarla çalışmasını gerektiren bir veya daha az titiz bir sınırlama içerebilir ve bir katmanın elemanlarının sadece aynı diğer elemanlarla anlaşılmasını sağlar; eğer bu talep gevşetilirse, tarzın saf olmayı bırakması ve sezgisel kapasitesinin bir kısmını kaybetmesi beklenir (MSDN, 2004); Doğal olarak, bir tabakayı geri kalanını etkilemeden değiştirme olasılığı da doğal olarak kaybolur, montajın esnekliğini azaltır ve bakımını zorlaştırır.

Bazen, birçok seviyenin aşırı geçişinin, nihai performans bozulmalarını içerdiği ileri sürülmektedir; Ancak, birçok kez daha, katmanlı mimarinin saflığı, onu iyileştirmek için kesin olarak feda edilir: örneğin, iş kurallarını veritabanlarının saklı prosedürlerine yerleştirmek veya kullanıcı arabirimi katmanında sorgu talimatlarını ifade etmek.

avantaj

Modülerlik (bir dereceye kadar) Artan soyutlama seviyelerine dayanan tasarımı destekler, bu da uygulayıcıların karmaşık bir problemi artımlı adımlara bölmesine olanak tanır.Geniş kullanım sağlar.Sistem evrimini kolayca destekler; değişiklikler sadece komşu katmanları etkiler Uygulamalar bitişik katmanlarla arayüzlere saygı gösterilerek değiştirilebilir.

Dezavantajları

Gerekli katmanlama hakkında bir önsel düşünmek zordur: Katmanlar arasındaki iletişimin formatları, protokolleri ve aktarımı genellikle özel ve tescillidir.Tüm sistemler katmanlanamaz. Bileşen tabanlı mimari

Şu anda yazılım geliştirmede, yeni uygulama uzantılarının veya eksiksiz uygulamaların oluşturulması için kullanılabilen mevcut yazılımın parçalarının veya modüllerinin yeniden kullanılmasından büyük bir ihtiyaç duyulmaktadır. Mühendislik süreçlerinde yeniden kullanımdan bahsederken, "bileşen" kavramı çok örtüktür, çünkü uygulamaları oluşturmak için kullanılabilen yazılımın verimli kısımları "yazılım bileşenleri" olarak bilinir.

Bu terimin birkaç tanımı vardır (Yazılım Bileşeni):

Krutchen'e göre, bir bileşen, iyi tanımlanmış bir mimari bağlamında bir işlevi yerine getiren, sistemin önemsiz, neredeyse bağımsız ve değiştirilebilir bir parçasıdır. Bir bileşen bir dizi arabirime uyar ve bunların fiziksel olarak gerçekleştirilmesini sağlar. (Brown ve diğerleri, 1998). Carnegie Mellon Üniversitesi'ndeki Yazılım Mühendisliği Enstitüsü (SEI), bir yazılım bileşeninin ne olması gerektiğine ilişkin farklı görüşleri birleştirmek amacıyla bir tanım formüle etti: “bir bileşen bir uygulamadır işlevsellikte opak, üçüncü taraf kompozisyonuna tabi ve bir bileşen modeliyle uyumludur ”(Bachmann, et al., 2000). Szyperski'ye göre, bir yazılım bileşeni sözleşmeye bağlı olarak belirlenmiş arayüzlere ve sadece açık bağlam bağımlılıklarına sahip bir kompozisyon birimidir.Bir yazılım bileşeni bağımsız olarak dağıtılabilir ve üçüncü taraflarca kompozisyona tabidir. (Szyperski, 2002).

Tanımların çoğunun, servisler tarafından serbest bırakılan, bir dizi arayüz olarak görülen ve onlar.

Özellikleri:

Bileşenlerin en önemli özelliklerinden biri, tekrar kullanılabilir olmalarıdır. Bunun için bileşenler en azından aşağıdaki karakteristik özellikleri karşılamalıdır:

Tanımlanabilir: Bir bileşenin, kataloglarını ve bileşen depolarında arama yapmayı kolaylaştıran açık ve tutarlı bir kimliği olmalıdır. Yalnızca arabirimi aracılığıyla erişilebilir: bileşen, yalnızca karakteristik işlem kümesini (arabirim) açıklamalı ve uygulama ayrıntılarını gizlemelidir. Bu özellik, bir bileşenin aynı arabirimi uygulayan bir bileşenle değiştirilmesine olanak tanır. Hizmetler değişmezdir: bir bileşen tarafından arabirimi aracılığıyla sunulan işlemler değişmemelidir. Bu hizmetlerin uygulanması değiştirilebilir, ancak arabirimi etkilememelidir. belgeli- Bir bileşen, bileşen havuzlarında arama, değerlendirme, yeni ortamlara uyum sağlama, diğer bileşenlerle entegrasyon ve destek bilgilerine erişim konularında aramayı kolaylaştıracak yeterli belgelere sahip olmalıdır.

Bileşen stilinin baskın değerlendirmesi, nesne modeline göre daha fazla çok yönlülüğünün yanı sıra hizmet odaklı stile kıyasla daha düşük uyarlanabilirliğini de vurgulamaktadır (Reynoso ve diğerleri, 2004).

Avantajı:

Yazılımın yeniden kullanımı. Daha yüksek düzeyde yazılımın yeniden kullanılmasına yol açar. Testleri basitleştirin. Monte edilmiş bileşenlerin tamamını test etmeden önce bileşenlerin her birini test ederek testlerin yapılmasına izin verir. Sistem bakımını basitleştirin. Bileşenler arasında zayıf bir bağlantı olduğunda, geliştirici, sistemin diğer bölümlerini etkilemeden bileşenleri gerektiği gibi güncelleyebilir ve / veya ekleyebilir. Daha yüksek kalite. Bir bileşen bir uzman veya kuruluş tarafından oluşturulup sürekli olarak iyileştirilebildiğinden, bileşen tabanlı bir uygulamanın kalitesi zamanla artacaktır.

Dezavantajları:

Bileşenler yoksa, geliştirilmeleri ve çok zaman kaybedilmeleri ve bu bileşenlerin yeni bir sürümün çıkması durumunda çakışmalar olabileceği gerçeği varsa, bu bileşenlerin yeniden uygulanması gerekebilir. sistem geliştiricilerinin elinde. Servis Odaklı Mimari (SOA)

Servis Odaklı Mimari (SOA) gevşek bağlı ve yüksek oranda birlikte çalışabilir uygulama servislerinden oluşur. Birbirleriyle iletişim kurmak için, bu hizmetler platformdan ve programlama dilinden bağımsız resmi bir tanıma dayanır (örneğin WSDL: Web Hizmetleri Açıklama Dili). Arayüz tanımı, bir uygulamanın özelliklerini kapsar ve onu üreticiden, programlama dilinden veya geliştirme teknolojisinden (Java veya.NET gibi) bağımsız hale getirir.

Bu mimari ile, arayüz bir standardın ardından tanımlandığı için geliştirilen yazılım bileşenlerinin çok yeniden kullanılabilir olması amaçlanmıştır; bu nedenle, CSharp'de geliştirilen bir hizmet bir Java uygulaması tarafından kullanılabilir.

SOA'nın en göze çarpan özelliklerinden biri, sağlayıcının her iki tarafça paylaşılacak iletişim, ulaşım ve yol ve çıkış verilerinin kurallarını belirlediği sözleşmelere dayanmasıdır. Daha fazla SOA özelliği görmek için bakınız (Ek 3).

SOA nedir?

SOA kavramsal bir mimaridir, iş fonksiyonlarını birlikte çalışabilir hizmetler olarak organize eder, hizmetlerin iş ihtiyaçlarını karşılamak için yeniden kullanılmasını sağlar SOA standartlara dayalıdır, üretici bağımsızlığıdır SOA kurumsal düzeyde bir BT stratejisidir.

SOA, inşa edilecek sistemin iş süreçlerinin, bu süreçleri kapsayan ve iyi tanımlanmış arabirimler yoluyla çağrılabilen yüksek uyum ve düşük kuplajlı bağımsız hizmetler olarak görüldüğü bir mimari tarzıdır.

SOA değil

SOA bu şekilde değildir:

Proje Geliştirme Metodolojisi, İş Mimarisi Metodolojisi.

Mimari bir stil olarak SOA

Bileşen: ServiceConnectors: Önce, RPC - Şimdi, iletiyi iletme Yapılandırma: Dağıtılmış Kısıtlamalar (Kısıtlama): Düşük anlaşma, programlama modeli bağımsızlığı, platform bağımsızlığı, taşıma ve protokol ile endüstri sözleşmesi

avantaj

Karar vermeyi geliştirin.
- Birleşik panoramik. Daha iyi kalitede daha fazla bilgi.
Çalışan verimliliğini artırın.
- Sistemlere optimum erişim. BİT sınırlaması yok
Müşteriler ve tedarikçiler ile ilişkilerin güçlendirilmesi.
- Müşterilere daha fazla yanıt verme.
Daha üretken ve esnek uygulamalar Daha güvenli ve daha yönetilebilir uygulamalar.

Dezavantajları

Diğerlerinin yanı sıra şebeke iletişimi, mesaj boyutu sayesinde arama süreleri ihmal edilemez. Bu mutlaka güvenilir mesajlaşma kullanımını gerektirir: Hizmetin yanıtı, ağdaki sorunlar, yapılandırma ve diğerleri gibi harici yönlerden doğrudan etkilenir.Güvenilmez iletişimleri, öngörülemeyen mesajları, yeniden denemeleri, sıra dışı mesajları vb.

1.3.2. Mimari Desenler

En yaygın mimari desen sistemlerinden ikisine ayrılan ve aynı olan yaygın olarak kullanılan bir sınıflandırma vardır: Pattern Oriented Software Architecure (POSA) (Buschmann ve diğerleri, 1996) ve Enterprise Uygulama Mimarisi Pattern (PEAA).) (Fowler ve diğerleri, 2002).

POSA kategorileri

POSA mimari desen referans kitabında, desenler aşağıdaki gibi bölünmüştür:

Çamurdan Yapıya: Bu desenler, bileşenlerin veya nesnelerin bolluğundan kaçınmaya yardımcı olur. Özellikle, bir sistem görevinin birlikte çalışan alt görevlere kontrollü bir şekilde ayrıştırılmasını desteklerler. Dağıtık Sistemler İnteraktif Sistemler Adaptif Sistemler

(Ek 4) 'te POSA modellerinin listelenen kategorilerdeki dağılımı gösterilmiş ve daha sonra (Ek 5)' te bazılarının kısa bir açıklaması gösterilmiştir.

PEAA Kategorileri

PEAA'da (Fowler ve diğerleri, 2002), iş uygulamalarının mimarisine yönelik çok sayıda deseni tanımlarlar.

PEAA'da aşağıdaki desen kategorileri tanımlanmıştır:

Katmanlama: Bir sistemi katmanlara bölme modelleri. Etki alanı mantığının organizasyonu: Etki alanı nesnelerini düzenleme yolları. İlişkisel Veritabanlarına Eşleme: Etki alanı mantığı ve veri havuzları arasındaki iletişim ile ilgilidir. Nesne modelleri ve ilişkisel veritabanları arasındaki eşlemeyi içerir. Web Sunumu: Web sunumu, son yıllarda iş uygulamalarının üstesinden gelmesi gereken zorluklardan biridir. Web ince istemciler birçok avantaj sağlar, bunlardan biri dağıtım kolaylığıdır (istemci bilgisayarlara yazılım yüklemek gerekmez). Bu kategori, web sunumunu yönetmek için bir dizi desen içerir. (Welicki, 2007)Eşzamanlılık: Eşzamanlılığın yönetimi. Günümüzün web tabanlı uygulamalarının yüksek eşzamanlılık yönetimi ihtiyaçları vardır. Oturum Durumu: Web sunucularında oturum yönetimi modelleri. Dağıtım Stratejileri: Nesnelerin, istemcilerdeki ampirik bilgiye dayanarak, birden fazla konumda dağıtılması.

(Ek 6) 'da, PEAA'da tanımlanan modellerin yukarıda açıklanan kategorilere dağılımı gösterilmektedir.

Mimari örüntü ve mimari üslup terimleri genellikle karışıktır ve disiplinin birçok öğrencisi bu konuda belirsiz görünmektedir. Mimari üslup ile mimari örüntü arasında açık bir karşılaştırma yapmak amacıyla (Ek 7), bu kavramlar arasındaki yaklaşım temelinde inşa edilen bazı farklılıkları ortaya koymaktadır (Buschmann ve diğerleri, 1996).

1.3.3. Soyutlama Düzeyleri Arasındaki İlişki

(Ek 8) 'de mimari üslup, mimari örüntü ve tasarım örüntüsü kavramları arasındaki soyutlama ilişkisi gösterilmiştir.

Stiller ve desenler, mimarın yazılım sisteminin kompozisyonunu ve davranışını tanımlamasına yardımcı olur ve bunların uygun bir kombinasyonu kalite gereksinimlerini karşılamaya izin verir, böylece yazılım sisteminin zaman içinde dayanmasını sağlar.

Ancak, yazılım sisteminin organizasyonu, sistemin geliştirilmesinde yer alan herkesin erişimine açık olmalıdır, çünkü bunlar arasında bir iletişim mekanizması oluşturur. Bu, mimariyi farklı şekillerde temsil ederek elde edilir, böylece bir kalite sistemi elde etmek amacıyla, ilgili herkes tarafından anlaşılabilecek ve analiz edilebilecek şekilde bir açıklama elde edilir. Bu açıklamalar mimari görünümler, UML gibi gösterimler ve mimari tanımlama dilleri aracılığıyla oluşturulabilir (Bengtsson, 1999).

Mimari görüşler, farklı soyutlama seviyeleri yoluyla, kalkınmaya katılanları ilgilendiren çeşitli konuları vurgular. Bu nedenle, bir mimarinin bu bakış açılarını ve geliştirme sürecine dahil olan herkese sistemin kalite özelliklerini sorgulama yollarını analiz etmek ilginçtir.

1.3.4. çerçeveler

Bölüm 1.2.1.4'te bir çerçevenin ne olduğu hakkında kısa bir tanım verilmiştir, bu nedenle bu bölüm onlar hakkında daha fazla bilgi vermeye çalışacaktır.

Bir çerçevenin temel amaçları şunlardır: geliştirme sürecini hızlandırmak, mevcut kodu yeniden kullanmak ve diğerlerinin yanı sıra kalıpların kullanımı gibi iyi geliştirme uygulamalarını teşvik etmek.

Çerçeve kullanıcısının işi, bir yandan sağladığı bileşenleri seçmek, başlatmak, genişletmek ve yeniden kullanmak ve diğer yandan çerçevede birleştirilmesi gereken belirli bileşenler geliştirerek çerçevenin mimarisini tamamlamak ve böylece çerçevenin getirdiği yapısal kısıtlamaların ardından farklı uygulamalar geliştirebilecekler.

Bir çerçeve kullanmanın avantajları nelerdir?

Standart kullanımından türetilenler; diğerleri arasında:

Programcının uygulamanın küresel bir yapısını düşünmesine gerek yoktur, ancak çerçeve “doldurulması” gereken bir iskelet sağlar. İşbirliğini kolaylaştırır. Başka bir programcının kaynak koduyla, hatta kendi programıyla savaşmak zorunda kalan herkes, onu anlamanın ve değiştirmenin ne kadar zor olduğunu bilecektir; bu nedenle tanımlanmış ve standartlaştırılmış her şey zamandan tasarruf sağlayacak ve işbirlikçi gelişmeler için çalışacaktır.. Gelişimi kolaylaştırmak için özel çerçeveye uyarlanmış araçlar (yardımcı programlar, kütüphaneler) bulmak daha kolaydır.

Her ne kadar çerçevelerin kullanımı bir yazılım sisteminin geliştirilmesi için iyi bir uygulama olsa da, biliniyor olsun ya da olmasın birinin kullanılması gerektiği anlamına gelmez. Bu, projenin büyüklüğüne ve geliştirme ekibi ile mimarın sahip olduğu deneyime bağlı olacaktır.

Güvenli programlama ilkelerinden birine göre, neden önceden tanımlanmış bir çerçeve kullanmıyorsunuz ve diğer geliştiricilerin çalışmalarından yararlanmıyorsunuz, başka bir deyişle, tekerleği neden yeniden icat ediyorsunuz? Test edilmiş, çalışan ve çalışır durumda olan bir şeyiniz varsa, aynı şeyi yapan bir şey yapmaya gerek yoktur, bu çok yararlı değildir ve sadece zaman kaybı gibi komplikasyonlar getirebilir.

Bir çerçevenin kullanımının belirli bir başlangıç maliyetini (öğrenme eğrisi) ima ettiği doğrudur, ancak bu bir yazılım projesinin geliştirilmesi sırasında uzun vadede telafi edilen bir şeydir.

SOA: Bugünün Zorluğu

Hizmet Odaklı Mimari, hizmetlerin uygulamaların geliştirilmesi için temel yapılar olarak kullanımını tanımlayan bir yazılım mimarisi konseptidir. İş süreçlerini oluşturmak için belirli dizilerde çağrılabilen erişilebilir, iyi tanımlanmış arayüzlere sahip işlevlerin bağımsız hizmetler olarak tanımlandığı bir uygulama mimarisidir.

SOA, daha az kaynakla daha fazlasını yapma zorluğunu aşmanın en iyi yolu olarak ortaya çıkmıştır. Yeniden kullanım ve entegrasyonu daha kolay hale getirmeyi vaat ederek geliştirme süresini azaltmaya ve kurumsal çevikliği artırmaya yardımcı olur. Şaşırtıcı olmayan bir şekilde, BT kuruluşlarının% 80'i, temel web hizmetlerine sahip SOA kullanan uygulamalar kullanıyor. SOA, hem iş ortamında hem de teknolojik altyapıdaki değişikliklerle yüzleşmek için daha fazla esneklik sağlar ”(Reynoso, 2005).

2003 yılında küresel bilgi teknolojisi (BT) endüstrisinin önde gelen araştırma ve analiz sağlayıcısı Gartner şunları söylüyor: “2008 yılına kadar SOA, monolitik mimarilerin 40 yıllık egemenliğini sona erdiren yazılım mühendisliğinin hakim uygulaması olacak. (olasılık 0.7) ”(Natis, 2003).

1.4.1. SOA kullanma nedenleri

Bir şirketin SOA yaklaşımını ve daha özel olarak web hizmetlerine dayalı bir SOA yaklaşımını benimsemesinin birkaç nedeni vardır:

Yeniden Kullanım: SOA'daki değişimin temel faktörü, iş hizmetlerinin yeniden kullanılmasıdır. Bir şirket içinde ve iş ortaklarıyla birlikte işletme işlevleri, web hizmetleri olarak gösterilebilir ve yeni iş gereksinimlerini karşılamak için yeniden kullanılabilir. Birlikte çalışabilirlik: Gevşek bir şekilde birleşmiş bir mimarinin amacı, hangi platformda olursa olsun müşterilerin ve hizmetlerin iletişim kurmasıdır. Web servisleri ile iletişim protokolleri platformdan, kodlama dilinden ve işletim sisteminden bağımsızdır, böylece iş ortakları ile iletişimi kolaylaştırır. Ölçeklenebilirlik: SOA hizmetleri gevşek bağlandığından, bu hizmetleri kullanan uygulamalar kolayca ölçeklendirilir. Bunun nedeni, istemci uygulamaları ile kullandıkları hizmetler arasında çok az bağımlılık olmasıdır. Esneklik: Hizmetler arasında zayıf bağlantı sağlayan bir başka özelliktir. Bunlardan birinin uygulanmasındaki herhangi bir değişiklik, arayüz korunduğu sürece geri kalanını etkilemez. Maliyet verimliliği: SOA mimarileri, mevcut hizmetlerin yeniden kullanılmasını sağlamaya dayanmaktadır. Bu hizmetleri ortaya çıkarmak için web hizmetlerini kullanarak, mevcut web altyapısı neredeyse tüm kuruluşlarda yeniden kullanılır, böylece maliyet önemli ölçüde sınırlandırılır.

1.4.2. SOA elemanları

Bu mimari, son kullanım uygulamaları veya diğer hizmetler için uygulamaya hizmet olarak işlevsellik sağlayan dağıtılmış sistemler oluşturmanın bir yolunu sunar.

Ek 9, servis odaklı bir mimaride gözlemlenebilecek unsurları göstermektedir. İçinde, biri mimarinin fonksiyonel yönlerini, diğeri hizmet kalitesinin yönlerini kapsayan iki bölge ayırt edilebilir. Öğeler aşağıda kısaca açıklanmıştır (Endrei ve diğerleri, 2004):

Özellikleri
- Ulaşım: Hizmet taleplerini bir hizmet tüketicisinden bir hizmet sağlayıcısına ve sağlayıcıdan tüketiciye verilen yanıtları taşımak için kullanılan mekanizmadır. Servis iletişim protokolü: bir servis sağlayıcı ve bir servis tüketicisinin neyin talep edildiğini ve neyin cevaplandığını bildirdiği kabul edilmiş bir mekanizmadır. Hizmet Açıklaması: Hizmetin ne olduğunu, nasıl çağrılması gerektiğini ve hizmetin başarıyla çağrılması için gereken verileri açıklamak kabul edilen bir şemadır. Hizmetler: Kullanılabilen geçerli bir hizmeti açıklar. İş süreçleri: bir iş gereksinimini karşılamak için belirli bir dizi kuralla çağrılan bir hizmet koleksiyonudur. Hizmet Kaydı: hizmet sağlayıcıların hizmetlerini yayınlamak için kullanabileceği hizmet açıklamalarının ve verilerinin yanı sıra kullanılabilir hizmetleri bulmak veya bulmak için hizmet tüketicilerinin bulunduğu bir depodur.
Hizmet kalitesi
- Politika: bir servis sağlayıcının servisi tüketicilere sunduğu bir dizi koşul veya kuraldır. Güvenlik: Hizmet tüketicilerine erişimin tanımlanması, yetkilendirilmesi ve kontrolü için uygulanabilen bir dizi kuraldır. İşlemler: Tutarlı bir sonuç sunmak için bir grup hizmete uygulanabilecek öznitelikler kümesidir. Yönetim: sağlanan veya tüketilen hizmetleri yönetmek için uygulanabilecek öznitelikler kümesidir.

SOA işbirlikleri, hizmet tüketicisinin belirli bir ölçütleri karşılayan bir hizmet bulmak için hizmet kayıt defterini sorgulayarak bir hizmeti dinamik olarak bulduğu yayımlama, bulma ve çalıştırma paradigmasını izler. Hizmet varsa, kayıt defteri tüketiciye sözleşme arabirimini ve sağlayıcı hizmetinin adresini sağlar. (Endrei ve diğerleri, 2004)

Ek 10, Hizmet Odaklı Bir Mimarideki birlikte çalıştıkları varlıkları (roller, operasyonlar ve eserler) göstermektedir.

(Ek 10) 'daki şemada gösterilen her bir işletme tüketici, tedarikçi ve / veya sicil rolünü üstlenebilir:

Bir servis, tüketici bir arayüz sözleşmesine uygun hizmet gerektiren bir uygulama, yazılım modülü veya başka bir hizmet, ve servisi gerçekleştirir. Bir servis sağlayıcı kabul eder ve yürütür sorgular bir ağ adreslenebilir bir varlıktır. hizmet tüketicisinin hizmetini keşfedebilmesi ve hizmete erişebilmesi için hizmetlerini ve arabirim sözleşmesini hizmet kaydında yayımlar Hizmet hizmet kaydı, hizmet havuzu içeren hizmetlerin bulunmasını mümkün kılmaktan sorumludur. kullanılabilir ve servis sağlayıcıların arayüzlerinin ilgili tüketiciler tarafından görülmesini sağlar.

Operasyonlar:

Yayınla. Bir hizmete erişmek için açıklaması, bir tüketicinin onu keşfedebilmesi ve çağırabilmesi için yayınlanmalıdır. Keşfedin. Hizmet tüketicisi, hizmet kayıt defterine başvurarak belirli ölçütleri karşılayan bir hizmet bulur. Bağla ve Çağır. Tüketicinin bir hizmet açıklaması elde edildikten sonra, tüketici hizmeti hizmet açıklamasındaki bilgilere göre çağırır.

Son olarak, hizmet odaklı bir mimarideki eserler şunlardır (Alvez ve diğerleri, 2006):

Hizmet. Yayınlanmış bir arabirim aracılığıyla kullanılabilen ve hizmet tüketicisi tarafından çağrılabilen bir hizmet. Hizmet Tanımı. Hizmet açıklaması, hizmetten gelen sorgu ve yanıtların biçimini belirterek hizmet tüketicisinin hizmet sağlayıcısıyla nasıl etkileşime gireceğini belirtir. Bu açıklama aynı zamanda önkoşullar, post-koşullar ve / veya hizmet kalitesi düzeylerini de belirleyebilir.

Yukarıda sözü edilen analizi inceleyerek, bu tür mimarideki temel unsurun hizmet olduğu sonucuna varılabilir, ancak sadece bu cihazla bir SOA tasarlayamadı. Bir SOA oluşturmak için, operasyonlar, hizmetler, mesajlar ve iş süreçlerinin birleştirilmesi temel olarak gereklidir.

1.4.2.1. Hizmet Türleri

Temel Hizmetler: Veri veya mantık odaklı olabilir ve karmaşık hesaplamalar, veri erişimi ve karmaşık iş kuralları gibi özellikleri içerebilir. Aracılık hizmetleri: adaptör hizmetleri, cepheler vb. Genellikle vatansız hizmetlerdir. İşlem hizmetleri: işlem mantığını kapsülleyen iş hizmetleri. Devleti koruma eğilimindedirler ve BPM araçlarında bulunabilirler. Kamu hizmetleri: üçüncü taraflarca erişilebilen hizmetler (kuruluşun dışında).

Bir iş hizmeti, tam işlevsel anlamı olan ve aşağıdakilerden oluşan, yeniden kullanılabilir bir yazılım bileşenidir (bkz. Ek 11):

Sözleşme: amaç, işlevsellik, kullanım şekli ve hizmet kısıtlamalarının belirlenmesi. Arayüz: hizmeti kullanıcılara sunma mekanizması. Uygulama: mantık veya veri erişimi içermelidir.

1.4.3. Web servisleri

Servis Odaklı Mimariler, Nesne Odaklı Mimarilerin aksine, yüksek oranda birlikte çalışabilir ve gevşek bağlı uygulama servislerinden oluşur. Bu hizmetlerin, ne olduklarından farklı olarak dağıtılmış bir bileşenin karmaşıklığındaki evrim olarak görülebildiği yerlerde (Alvez ve diğerleri, 2006):

İstemci uygulamalarınızla bileşenlerden çok daha az birleşmiş Bileşenlerden daha az ayrıntı düzeyi, uçtan uca bir uygulamanın parçası olarak tasarlanmaları ve uygulanmaları gerekmez, bağımsız olarak denetlenir ve yönetilirler. ve platformdan bağımsız. Performans ve kaynak tüketimi riskini bile olsa, ağdaki konumları hakkında şeffaftırlar, böylece ölçeklenebilirliği ve hata toleransını garanti ederler.

Genel olarak, hizmetler, tasarlandıkları sorunun çözümü ile ilgili hem iş mantığı hem de veri yönetimini içerir. Bir hizmet, kendi iş kuralları, verileri, yönetim ve işletim prosedürleri, ölçeklenebilirlik, güvenlik, hata toleransı, istisna işleme ve yapılandırma politikalarına sahip bağımsız bir uygulama olarak çalışır. İleti tabanlı bir arabirim kullanarak tüm işlevlerini ortaya çıkarır, bu nedenle hizmetle iletişim yöntem çağrıları yerine iletiler aracılığıyla yapılır. Bu mesajların anlaşılması için gerekli tüm bilgileri içermesi veya bunlara referansta bulunması gerekir.

Web hizmetleri uygulamaları nasıl iletir, nasıl oluşturuldukları, hangi işletim sistemi veya platformda çalıştırıldıklarına ve bunlara erişmek için hangi cihazların kullanıldığına bakılmaksızın bilgilerin paylaşılmasına izin vererek uygulamaları iletir. İletişim, XML mesajlarının değişimi ve iletişim protokolünden bağımsız olması ile karakterizedir. Bu bağımsızlığı sağlamak için, SOAP aktarım protokolünün (Basit Nesne Erişim Protokolü: Basit Nesne Erişim Protokolü) oluşturulması sayesinde XML mesajı her protokol için uygun şekilde sarılır. (Alvez ve diğerleri, 2006)

XML'de ifade edilen Web Hizmetleri Açıklama Dili (WSDL), hizmete nasıl erişileceğini, hangi işlevlere sahip olduğunu, hangi bağımsız değişkenlere ihtiyaç duyduğunu ve her birinin ne döndürdüğünü açıklar.

İlgili diğer temel teknoloji Evrensel Tanımlama, Keşif ve Entegrasyon (UDDI: Evrensel Açıklama, Keşif ve Entegrasyon) teknolojisidir. UDDI, sunulan hizmetleri yayınlayabileceğiniz, hizmet türünün özelliklerini verebileceğiniz ve arama yapabileceğiniz bir web hizmetleri dizinidir.

Özetle, SOAP hizmetler arasında temel birlikte çalışabilirlik için bir XML protokolü tanımlar, WSDL hizmetleri tanımlamak için ortak bir dil sunar ve UDDI hizmetleri programlı olarak yayınlamak ve keşfetmek için gereken altyapıyı sağlar. Bu spesifikasyonlar birlikte, uygulamaların altta yatan platformdan bağımsız olarak gevşek bağlı bir modeli takip ederek etkileşime girmesine izin verir.

1.4.3.1. İlişkili Teknolojiler

WSDL

Web hizmetlerinin açıklama dili, Eylül 2000'de Microsoft, IBM ve Ariba tarafından doğmuştur ve web üzerindeki gelişimi yönlendiren World Wide Web Konsorsiyumu (W3C) hizmetlerinin açıklaması için bir standart oluşturmaktadır. (Endrei ve diğerleri, 2004)

Esasen WSDL, servis sağlayıcı ile müşteri arasında servis sağlayıcının belirttiği bir sözleşmedir (Alvez ve diğerleri, 2006):

Hangi işlevler çağrılabilir Bu işlevler tarafından hangi tür veriler kullanılır Mesaj göndermek ve almak için hangi aktarım protokolü kullanılacaktır (genellikle, yalnızca SOAP mesajları değil) Hizmetlere nasıl erişilir. Temel olarak, hizmetler hangi URL'ler tarafından kullanılır.

SABUN

Dağıtılmış ve merkezi olmayan bir ortamda yapılandırılmış bilgi alışverişi için basit bir protokoldür. Farklı süreçlerdeki iki nesnenin XML verilerinin değişimi yoluyla nasıl iletişim kurabileceğini tanımlar. Çeşitli temel protokoller üzerinden değiş tokuş edilebilen bir mesaj formatı sağlayarak genişletilebilir bir mesajlaşma çerçevesi tanımlamak için XML kullanır. Çerçeve, herhangi bir programlama modelinden veya herhangi bir uygulamanın belirli bir anlambiliminden bağımsız olacak şekilde tasarlanmıştır (W3C, 2007).

SOAP'ın XML kullanması, insanlar tarafından anlaşılma kolaylığı gibi avantajlara sahiptir, ancak aynı zamanda mesajların daha uzun olması nedeniyle dezavantajları vardır.

UDDI

Web hizmetleri teknolojisinde yer alan standartlar grubunun merkezi bir öğesidir. Potansiyel müşterilerin servis sağlayıcılarla buluştuğu aracıdır. SOA bağlamında hizmetlerin yayınlanması ve keşfedilmesi için standart bir yöntem tanımlar (Alvez ve diğerleri, 2006).

UDDI belirtimi, WSDL belirtimi ile hemen hemen aynı zamanda, aynı şirketlerden doğmuştur. Geçerli sürüm, Yapılandırılmış Bilgi Standartlarını Geliştirme Örgütü (OASIS) tarafından yönetilen, Ağustos 2003'ten kalma bir özellik olan 3.0'dır. Bu spesifikasyonların uygulanmasına SOAP yoluyla bir dizi kayıt ve danışma web hizmeti sağlayan “UDDI Kaydı” denir.

Bir UDDI kaydının işlevsel amacı, web hizmetleri hakkındaki verilerin ve meta verilerin temsilidir. Hem halka açık bir ağda hem de bir kuruluşun iç altyapısı içinde kullanım için bir UDDI kayıt defteri, web uygulamalarını sınıflandırmak, kataloglamak ve yönetmek için standartlara dayalı bir mekanizma sunar, böylece diğer uygulamalar tarafından keşfedilebilir ve tüketilebilir.

UDDI'da veri yapıları

Bir UDDI kaydında depolanan bilgiler, "UDDI veri yapıları" olarak adlandırılan bir gruptur. Spesifikasyonda tanımlanan XML'deki bu yapılar, istemcinin UDDI kayıt defteri ile değiştireceği yapılardır. Bu yapıların her bir örneği, Benzersiz Benzersiz Tanımlayıcı (UUID) adlı bir tanımlayıcı ile benzersiz bir şekilde tanımlanır (OASIS, 2004).

Ana üst düzey yapılar aşağıdaki gibidir (Alvez ve diğerleri, 2006):

BusinessEntity. Temel şirket bilgilerini içerir: irtibat kurulacak kişi, tanımlanan taksonomilerden birine göre bir şirket sınıflandırması ve şirketin faaliyetlerinin doğal bir dil tanımı. PublisherAssertion. Bir şirket, örneğin ortaklar veya müşteriler olarak diğer şirketlerle olan ilişkisini açıklayabilir. Bu ilişkilerin her biri bir PublisherAssertion olarak modellenmiştir. BusinessService. Bu öğe, bir şirket tarafından sunulan hizmetleri gösterir. Bu hizmetler web hizmetleri olabilir veya olmayabilir. Bir BusinessEntity, bir veya daha fazla businessService öğesinden oluşur ve bir businessService öğesi birkaç BusinessService öğesi tarafından kullanılabilir. BindingTemplate. Bu öğe, teknik açıklamalara (örneğin, teknik kılavuzlara işaret eden URL'ler) ve web hizmetleri için erişim URL'lerine referanslar içerir. Her BusinessService öğesinde bir veya daha fazla BindingTemplate öğesi bulunabilir. TModel. Bu öğe, web hizmeti ve davranışıyla nasıl etkileşimde bulunduğunuzu açıklar. Verileri arasında WSDL belgesinin bulunduğu URL bulunur. Hizmetin dahil edilebileceği kategoriler burada da görünebilir (BusinessEntity'de görünebilecek kategorilerden farklı olabilir).

1.4.4. Hizmetlerin Kompozisyonu

Bir iş sürecini tamamlamak için bir yazılım sisteminin fiziksel dağılımları ve heterojenlikleri ne olursa olsun diğer sistemlerle etkileşime girmesi gerektiği durumlarda, Servis Odaklı Mimariler daha faydalıdır.

Hizmet Odaklı Mimarilerden ve daha doğrusu web hizmetlerinin kullanımından hizmet kompozisyonu adı verilen yeni bir konsept ortaya çıkar. Bu kompozisyon sadece iş sürecinin modellenmesine izin vermekle kalmaz, aynı zamanda SOA'nın veri ve uygulamaların entegrasyonu yoluyla sunduğu potansiyeli en üst düzeye çıkarır.

Hizmetlerin bileşimi, iki veya daha fazlasının, bireysel kapasitelerinin kapsamı dışındaki gereksinimleri çözmek için birbirleriyle işbirliği yapmalarına izin veren bir mekanizma bulmayı içerir. Karşılanması gereken temel gereksinimlerin bazıları şunlardır (Alvez ve diğerleri, 2006):

Hizmetlerle eşzamansız etkileşimler: uzun süreler boyunca gerçekleşen süreçler oluşturma imkanı vermek için. Hizmetler arasında eşzamanlı etkileşimler: Bu, verimlilikte önemli bir artış sağlayan paralel işleme sağlar. Özel durum işleme: Bileşenlerinden en az biri başarısız olursa, birden çok hizmeti temel alan bir işlem başlatılamayabilir. Hataların meydana gelmesi göz önünde bulundurulmalı ve bunların giderilmesi için mekanizmalar sağlanmalıdır. İşlem bütünlüğü: uzun süren bir işlem sonunda başarısız olabilir, bu durumda daha önce yapılmış olan eylemlerin bir kısmının geri alınması gerekebilir.

Hizmetler arasında işbirliğini ifade etmek için yaygın olarak kullanılan iki terim, orkestrasyon ve koreografidir. Her ikisi de doğrudan kompozisyonla ilgilidir, ancak hizmetler arasındaki etkileşimin tamamlayıcı yönlerine odaklanır.

Orkestrasyon

Bir süreç, tek bir varlık tarafından tamamen kontrol edildiğinde bir hizmet düzenlemesi olarak düşünülebilir. Bu işlem, bileşen hizmetleriyle olan etkileşimleri ve bu etkileşimleri doğru şekilde yürütmek için gereken mantığı tam olarak tanımlar. Bu tür bir süreç özel ve yürütülebilir olarak anlaşılabilir, çünkü yalnızca süreci düzenleyen kuruluş, düzenlenmekte olan süreci izleyen kontrol akışını ve bilgiyi bilir. Bu şekilde, farklı hizmetleri kullanan, aralarında akan bilgileri işleyen, örneğin bazı hizmetlerin çıktı verilerini bir başkasının girdi verilerine dönüştüren bir süreç oluşturulur. Burada, her katılımcı kuruluş kendi sürecini uygular ve kontrol eder (Cubillos, et al., 2004).

Koreografi

Süreç, tanımlandıkları dile veya platforma bakılmaksızın her tür bileşen uygulaması arasındaki işbirliğini tanımladığında hizmetlerin koreografisidir. Koreografi süreci tek bir katılımcı tarafından kontrol edilmez. Orkestrasyondan farklı olarak, koreografi herkese açık, yürütülebilir olmayan bir süreç olarak görülebilir. Herkese açık olduğu için, tüm katılımcı varlıkların bilmesi gereken ortak bir davranışı tanımlaması ve çalıştırılamaz olması nedeniyle, kuralları daha fazla belirleyen bir iş protokolü olarak görülmesi amaçlanmıştır (Cubillos, et al., 2004).

1.4.5. SOA ve Web Hizmeti

Bir SOA genellikle yanlış anlaşılır ve web hizmetleriyle karıştırılır. SOA, sistem tasarımına bir yaklaşımdır, teknolojik kaynakların nasıl entegre edileceğini ve hangi hizmetlerin ortaya çıkacağını yönlendirir. Buna karşılık, web hizmetleri SOA çözümünü yürütmek için belirli standartları ve dil protokollerini kullanan bir uygulama metodolojisidir.

Hizmet Odaklı Mimari, iş işlevlerini arabirimlerin yayınlanmasıyla diğer uygulamalar tarafından kullanılmak üzere programlanarak erişilebilen yazılım hizmetleri olarak gösteren gevşek bağlı yazılım çözümleri tasarlama ve oluşturma yöntemidir. Web hizmetleri, Servis Odaklı Mimari'nin bir uygulamasını temsil eder, ancak Temsili Durum Transferi (REST) gibi tüm SOA uygulamaları web hizmetleri olarak kabul edilemez.

Buna rağmen, web hizmetleri mevcut teknoloji ve görünüşe göre burada kalmak için teknoloji. Aslında, WSDL gelişmeye devam ediyor ve web servisleri ile ilgili açıklama dilinin ötesindeki tüm teknolojiler bunu çok hızlı bir şekilde yapmaya devam ediyor.

Öte yandan, Hizmet Odaklı Mimariler, mevcut uygulama olsa da web hizmetlerinden çok daha geniş bir kavramdır.

Bir web hizmeti aşağıdaki durumlarda SOA'dır (Reynoso, 2005):

Arayüzler web protokollerine (HTTP, SMTP, FTP) dayanmaktadır Mesajlar XML tabanlıdır.

1.4.6. SOA Olgunluk Modeli

Olgunluk Modeli Nedir?

Bir iş mimarisinin SOA kullanımına ilişkin mevcut durumunun ölçülmesine ve bir evrim yolunun oluşturulmasına izin verir.

Neden Olgunluk Modeli?

İyi uygulamalar da dahil olmak üzere katmanlı öğrenmeyi etkinleştirir İletişim için temel oluşturur ve yetenekleri genişletir Yol programlarının oluşturulmasına yardımcı olur Artımlı SOA uyarlaması oluşturma temelini oluşturur

Bu bölümde önerilen olgunluk modeli beş seviyeden oluşmaktadır: başlangıç hizmetleri, mimari hizmetler, iş hizmetleri, işbirliği, iş ölçümleri ve iş optimizasyonları. Bu seviyeler bir SOA'nın kârında ölçeklendirmeye izin verecektir, çünkü bu tür mimarilerde daha azdan daha fazlasına gider (Bkz. Ek 12). Bu olgunluk modeli, SOA ve entegrasyon altyapıları da dahil olmak üzere ticari uygulama platformları sağlamaya adamış tanınmış bir yazılım şirketi olan Progress Software Corporation tarafından önerilmektedir. Yazılım pazarında, SONIC ESB olarak tanınan ürünler bulunmaktadır.

ADL'ler ve UML

ADL

Mimari Açıklama Dilleri (ADL: Mimari Açıklama Dili), bir mimariyi oluşturan uygulamaları programlamadan, yeterliliğini analiz etmeden, kritik noktalarını belirlemeden ve sonunda davranışını simüle etmeden önce modellemenizi sağlar. Yazılım Mimarisi akademik topluluğu tarafından iyi tanınıyorlar, ancak yazılım projelerinde kullanılmadıkları için endüstriyel uygulamalarda aynı kabul görmekten hoşlanmıyorlar.

Bu tedarik, bir sistemi bileşenlere ve konektörlere ayırmak için mimari soyutlamaları ve mekanizmaları belirlemek, bu elemanların konfigürasyon oluşturmak için nasıl birleştiğini ve mimari veya stil ailelerini tanımlamak için yapıları tedarik eder. (Reynoso ve diğerleri, 2004)

ADL'ler, kullanıcıya sağladıkları soyutlama ile karakterize edilir ve bu diller tarafından sağlanan görünümlerin çoğu, ağırlıklı olarak mimari bilgiler içerir ve dil tarafından sağlanan analiz, mimari düzeydeki bilgilere dayanır.

ADL'lerin önerdiği avantajlardan bazıları şunlardır:

Açıklamalar veya üst düzey belgeler de dahil olmak üzere, ürettikleri veya yanıt verdikleri olayların türü gibi davranışı ve ilişkili öğelerini tanımlamak mümkündür: Sistemle ilgili bilgilerin girilip korunabilmesi kolaylığı. farklı analiz türleri için gerektiğinde rafine edilebilirler.

Yukarıda bahsedilenlerin hepsine rağmen, ADL'lerin uygun olduğu söylenebilir, ancak şimdi sürüm 2.0 ile birlikte UML'nin kalıcılığı nedeniyle henüz önemli olmadığı gösterilmiştir (Reynoso ve diğerleri, 2004).

UML

Birleşik Modelleme Dili (UML), Nesneye Dayalı Yazılım Sistemleri yazılım geliştirme sürecinde ortaya çıkan öğelerin oluşturulması, belirlenmesi, görselleştirilmesi ve belgelenmesi konusunda uzmandır. Diyagramlar oluşturmak için bir araya gelen çeşitli grafik öğelerden oluşur ve bir dil olduğu için bu öğeleri birleştirmek için kuralları vardır. Sınıflar, ilişkiler, etkileşim davranışları, ambalajlama ve diğerleri için destek sunar. Bu öğeler, bu dil tarafından sunulan sınıflar, nesneler, kullanım senaryoları, sıra, işbirliği, durumlar, etkinlikler, bileşenler ve geliştirme gibi çeşitli diyagramlarla temsil edilebilir.

Hiç bir ADL olarak nitelendirilmemesine rağmen, kendi başına bir ADL kadar değil, diğer ADL'leri ve özellikle C2 ve Wright'ı simüle etmek için bir meta dil olarak kullanılabileceği kanıtlanmıştır (Reynoso ve diğerleri, 2004).

UML'de bunlar tanımlanır:

Elemanlar (temel yapı taşlarını oluşturan soyutlamalar) İlişkiler (Elemanları bağlama) Diyagramlar (Bir eleman setinin grafiksel gösterimi)

UML, yazılım bileşenlerinin tanımlanması için Kruchten 4 + 1 modelinin fiziksel görünümüne karşılık gelen, yazılım bileşenlerinin donanımdaki izdüşümünün açıklaması için bir gösterim sağlar (Kruchten, 1999).

UML'de bileşenler, paketler, kütüphaneler ve işbirliği gibi yazılım mimarileriyle ilişkili bazı kavramlar için destek vardır, bu nedenle mimarinin temel öğelerinin UML ile çok iyi modellenebileceği söylenebilir. Ancak, mimarinin tam bir temsili için, diğer araçlar ve diller gerekli olacaktır, çünkü toplam temsil sadece bileşenleri arasında mevcut iletişim değil, aynı zamanda iyi bir mimari tasarım elde etmek için yapılan her şeyi belgelemek ve haklı göstermek gerekir.

Yazılım Mimarisinde Kalite

Oluşturulacak Yazılım Sistemlerinin Yazılım Mimarisi, yüksek kalitede olmasını sağlamak için önemli bir faktör haline gelir. İyi bir Yazılım Mimarisine sahip olmak son derece önemlidir, çünkü bu tüm Yazılım Sistemlerinin kalbidir ve sistemle ilişkili kalite seviyelerinin ne olacağını belirler.

Yukarıdan bakıldığında, bir mimariyi değerlendirme hedeflerinin, inşa edilecek sistemin paydaşların ihtiyaçlarını ve ne ölçüde karşıladığını sağlamak için gereklilikleri, kalite niteliklerini ve kısıtlamaları sağlayıp sağlayamayacağını bilmek olduğu sonucuna varılabilir. Yapısında ve özelliklerinde ortaya çıkan yazılım sistemini etkileyebilecek potansiyel risklerin analiz edilmesine ve tanımlanmasına ek olarak.

İşlevsel olmayan gereksinimlere kalite özellikleri de denir. Kalite özelliği, bir öğeyi etkileyen bir kalite özelliğidir. Burada karakteristik terim işlevsel olmayan yönleri ve terimin bileşenini ifade eder (Gómez, 2007).

Değerlendirme teknikleri

Kalitatif ve kantitatif olarak sınıflandırılan bir grup değerlendirme tekniği vardır (Brey ve diğerleri, 2005) (bkz. Ek 13):

Sorgulama veya nitel teknikler. Mimariyi sormak için nitel sorular kullanıyorlar
- Açık. Uygulama Alanına Erken, Sisteme Özgü. Gelişmiş mimari.
Ölçme teknikleri. Mimarlığa nicel ölçümler yapılmasını önermektedir.
- Birleştirme, modül yapışkanlığı, kalıtım derinliği, değiştirilebilirlik, simülasyonlar, prototipler ve deneyler gibi mimari metrikleri kullanır

Genel olarak, mimari yapım aşamasındayken nitel değerlendirme teknikleri kullanılırken, mimarlık halihazırda uygulandığında nicel değerlendirme teknikleri kullanılır (Gómez, 2007).

Bir Mimarlık hangi nitelikler için değerlendirilebilir?

Genel olarak konuşursak, Bass kalite özelliklerinin iki kategoride bir sınıflandırmasını oluşturur (Camacho ve diğerleri, 2004):

Yürütme yoluyla gözlemlenebilir: sistemin çalışma zamanında davranışı tarafından belirlenen öznitelikler. Bu özelliklerin bazılarının açıklaması (Ek 14) 'te sunulmaktadır. Yürütme yoluyla gözlemlenemez: sistemin geliştirilmesi sırasında oluşturulan öznitelikler. Bu özelliklerin bazılarının açıklaması (Ek 15) 'te sunulmaktadır.

Mimarinin değerlendirilmesi hangi sonuçları doğurur?

Değerlendirme yapıldıktan sonra bir rapor hazırlanmalıdır. Değerlendirmeye katılan kişiler tarafından düzeltilebilmesi için bir ön belge olarak sunulması gerektiğidir. Raporun içeriği iki tür soruyu cevaplamaktadır (Gómez, 2007):

Sistem için en uygun mimari tasarlandı mı? Sistemin inşa edilmesi için önerilen mimarilerden hangisi en uygun mimaridir?

Rapor, bu soruları yanıtlamanın yanı sıra şunları da belirtiyor:

Kalite özelliklerinin karşılanma derecesi Değerlendirilmekte olan mimari için gerekli kalite özelliklerinin öncelikli listesi Riskler ve risk yok

Bugün, bir yazılım mimarisini değerlendirmek için, bazıları diğerlerinden daha spesifik olan belirli kalite özelliklerine uyumu doğrulayan çeşitli yöntemler vardır, örneğin: Mimari Değişim Analizi Yöntemi (ATAM), Bosch (2000), Aktif Tasarım İncelemesi (ADR), Ara Tasarım için Aktif İncelemeler (ARID), Losavio (2003).

Belirli bir kalite niteliğini değerlendiren başka mimari değerlendirme yöntemleri de vardır: Mimari Düzey Değiştirilebilirlik Analizi (ALMA), Yazılım Mimarisinin Performans Değerlendirmesi (PASA), Senaryoya Dayalı Mimari Düzey Kullanılabilirlik Analizi (SALUTA) ve Tek Kullanımlık Ağ Analizi (SNA).

Değerlendirme yönteminin ne kadar spesifik olup olmadığına bakılmaksızın, büyük çoğunluğun ortak bir yanı vardır: senaryo tekniği, mimarinin sistemin gerektirdiği kalite özelliklerine ne ölçüde tepki verdiğini doğrulamanın bir yolu olarak kullanılır.

Bir değerlendirme yöntemi diğerinden daha iyi değildir, daha ziyade belirli koşullar altında belirli bir kalite özelliğini değerlendirir. Dolayısıyla koşullara ve neyi değerlendirmek istediğinize bağlı olarak, kullanılan değerlendirme yöntemi olacağı sonucuna varılmıştır (bu sadece bir tane olmak zorunda değildir).

Yazılım Mimarisi ve Kalite Nitelikleri Arasındaki İlişki

Herhangi bir yazılım sisteminin geliştirme sürecinde, belirli ve belirli kalite özelliklerine ulaşılmasına izin veren mimari tasarım kararları verilir. Bunun için mimar sık sık bu kararın diğer kalite özellikleri üzerindeki etkisini sorgulamalıdır.

Bir yazılım mimarisine dahil edilen her karar potansiyel olarak kalite özelliklerini etkileyebilir (Bass ve diğerleri, 2000). Bu nedenle, bu tür kararların alınmasının genellikle aşağıdaki gibi sonuçları olduğu söylenebilir:

Kararın nasıl teklif edilen kalite özelliklerine ulaşılmasına izin verdiğini açıklayan argümanların formüle edilmesi Böyle bir karar vermenin diğer kalite özellikleri üzerindeki etkisine ilişkin sorular.

Kalite Öznitelikleri ve Yazılım Mimarisi arasındaki ilişkinin çeşitli yararları vardır (Camacho ve diğerleri, 2004):

Mimar, mevcut analizleri yeniden kullanabilir ve anlaşmaları anında değil açıkça belirleyebileceğinden, mimari analiz ve tasarım sürecini büyük ölçüde geliştirir. Mimar, mimari bileşenlerin bir veya daha fazla özelliği üzerindeki etkisini anladığında kalite, gerekli görüldüğünde bir bileşen grubunu başka bir bileşenle değiştirebilir.. Mimari ve kalite öznitelikleri arasındaki ilişki kodlandıktan sonra, üçüncü taraf sertifikasyonu sağlayacak bir test protokolü oluşturmak mümkündür.

Kısmi sonuçlar

Bu bölüm için önerilen hedeflerden aşağıdakiler sonuçlandırılabilir:

Bu bölüm boyunca, disiplindeki ana yönler ortaya çıkmıştır: ana tanımların anlayışı, mevcut eğilimler, iş uygulamaları dünyasında en yeni ve en yaygın stiller, özelliklerini, avantajlarını ve dezavantajlarını ortaya çıkarmak. Mimari üsluplar ve çerçeveler gibi kavramların anlaşılmasına yardımcı olan mimari örüntüler ve mimari soyutlama düzeyleri incelenmiştir. Yazılım Mimarisinde kalite gibi konular da ele alınmış ve mimarinin belirlenen kalite parametrelerine ne ölçüde uyduğunu doğrulamak için kullanılan ana kalite nitelikleri ve yöntemleri tanımlanmıştır.Aynı şekilde, Servis Odaklı Mimariler, günümüzde şirketlerin deneyimlediği değişen iş ve sisteme entegrasyon kolaylığı karşısında sisteme daha fazla esneklik sağlayacağından, çözüm teklifinde uygulanmasına izin veren mevcutun maksimum üssü olarak analiz edildi. bu tür bir mimari sağlar.

İş ortakları: Şirketin veya şirketin ortak sahibi olan kişi ya da şirket, diğer bir deyişle, şirketin bir parçası olduğu şirketin ortağıdır.

Orijinal dosyayı indirin