Yazılım Tasarımı ve Yazılım Mimarisi [kapalı]

Birisi Yazılım Tasarımı ve Yazılım Mimarisi arasındaki farkı açıklayabilir mi?

Daha spesifik olarak; birisine size 'tasarım' sunmasını söylerseniz - onların ne sunmasını beklersiniz? Aynı şey 'mimarlık' için de geçerli.

Şu anki anlayışım:

• Tasarım: Belirli bir modül / sistemin bir parçası için UML diyagramı / akış şeması / basit tel kafesler (UI için)
• Mimari: bileşen diyagramı (sistemin farklı modüllerinin birbirleriyle ve diğer sistemlerle nasıl iletişim kurduğunu gösteren), hangi dilin kullanılacağı, kalıplar ...?

Yanlışsam düzelt. Wikipedia'nın http://en.wikipedia.org/wiki/Software_design ve http://en.wikipedia.org/wiki/Software_architecture ile ilgili makaleleri olduğunu belirtmiştim , ancak bunları doğru anladığımdan emin değilim.

Haklısın evet. Bir sistemin mimarisi 'iskeleti'dir. Bir sistemin en yüksek soyutlama düzeyidir. Ne tür bir veri depolama mevcut, modüller birbirleriyle nasıl etkileşime giriyor, hangi kurtarma sistemleri mevcut. Tasarım desenleri gibi, mimari desenler de vardır: MVC, 3 katmanlı katmanlı tasarım, vb.

Yazılım tasarımı, ayrı modüllerin / bileşenlerin tasarımı ile ilgilidir. X modülünün sorumlulukları, işlevleri nelerdir? Y sınıfı? Ne yapabilir, ne yapmaz? Hangi tasarım desenleri kullanılabilir?

Kısacası, Yazılım mimarisi daha çok tüm sistemin tasarımı ile ilgilidir, yazılım tasarımı ise modül / bileşen / sınıf seviyesinde vurgulanır.

SDLC'nin (Yazılım Geliştirme Yaşam Döngüsü) bazı açıklamalarında bunlar değiştirilebilir, ancak vicdan farklıdır. Aynı zamanda: farklı (1) aşamalar , (2) sorumluluk alanları ve (3) karar verme düzeyleri .

• Mimari daha büyük resimdir: çerçeve, dil, kapsam, hedefler ve üst düzey metodolojilerin seçimi ( Rasyonel , şelale , çevik vb.).
• Tasarım daha küçük resimdir: kodun nasıl organize edileceğine dair plan; sistemin farklı bölümleri arasındaki sözleşmelerin nasıl görüneceği; projenin metodolojilerinin ve hedeflerinin sürekli uygulanması . Bu aşamada şartname yazılır.

Bu iki aşama farklı nedenlerle harmanlanmış görünecektir .

1. Daha küçük projeler genellikle planlamayı aşamalara ayırmak için yeterli alana sahip değildir.
2. Bir proje daha büyük bir projenin parçası olabilir ve bu nedenle her iki aşamanın bazı kısımlarına zaten karar verilmiştir. (Halihazırda mevcut veritabanları, sözleşmeler, standartlar, protokoller, çerçeveler, yeniden kullanılabilir kod vb. Vardır)
3. SDLC hakkında daha yeni düşünme yolları (bkz. Çevik metodolojiler ) bu geleneksel yaklaşımı bir şekilde yeniden düzenler. Tasarım (daha az ölçüde mimari) SDLC boyunca bilerek yapılır . Tüm sürecin tekrar tekrar gerçekleştiği genellikle daha fazla yineleme vardır .
4. Yazılım geliştirme karmaşık ve yine de planlanması zordur, ancak müşteriler / yöneticiler / satış görevlileri genellikle orta akıştaki hedefleri ve gereksinimleri değiştirerek bunu zorlaştırır. Tasarım ve hatta mimari kararlar , plan olsun ya da olmasın projede daha sonra yapılmalıdır .

Aşamalar veya sorumluluk alanları birlikte karışsa ve her yerde gerçekleşse bile, hangi düzeyde karar alma sürecinin olduğunu bilmek her zaman iyidir. (Bunu sonsuza dek devam ettirebiliriz. Bir özet tutmaya çalışıyorum.) Şununla bitireceğim: Projenizde resmi bir mimari veya tasarım aşaması / AOR / belgesel yok gibi görünse de, herhangi birinin bilinçli olarak yapıyor ya da yapmıyor. Hiç kimse mimarlık yapmaya karar vermezse, muhtemelen zayıf olan varsayılan bir mimari oluşur. Tasarım için aynen. Bunları temsil eden resmi aşamalar yoksa, bu kavramlar neredeyse daha önemlidir .

Mimari stratejik, Tasarım ise taktikseldir.

Mimarlık, çerçeveler, araçlar, programlama paradigmaları, bileşen tabanlı yazılım mühendisliği standartları, üst düzey ilkelerden oluşur.

Tasarım, tasarım modelleri, programlama deyimleri ve yeniden düzenleme gibi yerel kısıtlamalarla ilgili bir faaliyettir.

Bunu mimarlık ve tasarım arasında basit bir ayrım aradığım için buldum;
Onlara bu şekilde bakmak hakkında ne düşünüyorsun:

• mimarlık yaptığımız "ne" dir;
• tasarım "nasıl" inşa ediyoruz;

1. Mimari, bir bilgisayarın veya bilgisayar tabanlı sistemin kavramsal yapısı ve mantıksal organizasyonu anlamına gelir.

   Tasarım, bir sistemin veya bir nesnenin yapılmadan önce görünümünü ve işlevini veya işleyişini göstermek için üretilen bir plan veya çizim anlamına gelir.

2. Bir bileşeni “mimarlarken”, daha büyük sistemde nasıl davranacağını tanımlarsınız.

   Aynı bileşeni "tasarlıyorsanız", bileşenin dahili olarak nasıl davrandığını tanımlarsınız.

Tüm mimari tasarımdır, ancak tüm tasarım mimari değildir.

Whatbölüm Tasarım, Howsomut uygulama ve kesişim Whatve HowMimarlık.

Farklılaştırma Mimarlık ve Tasarım için resim :

Ayrıca, mimari açıdan önemli olmayan, yani tasarımın mimari dalına ait olmayan tasarım kararları da vardır. Örneğin, algoritmanın seçimi, veri yapısının seçimi gibi bazı bileşenlerin iç tasarım kararları.

Bileşen sınırı dışında görünmeyen herhangi bir tasarım kararı, bir bileşenin iç tasarımıdır ve mimari değildir. Bunlar, tasarımları sistem seviyesi mimarinin getirdiği mimari kısıtlamaları kırmadığı sürece, bir sistem mimarının modül tasarımcısının takdirine veya uygulama ekibine bırakacağı tasarım kararlarıdır.

İyi benzetme sağlayan bağlantı

Haklı olduğunu söyleyebilirim, kendi sözlerimle;

Mimari , sistem gereksinimlerinin sistem öğelerine tahsis edilmesidir. Bir mimariyle ilgili dört ifade:

1. Dil veya kalıplar gibi işlevsel olmayan gereksinimler getirebilir.
2. Bileşenler, arayüzler, zamanlama vb. Arasındaki etkileşimi tanımlar.
3. Yeni işlevler getirmez,
4. Sistemin gerçekleştirmeyi amaçladığı (tasarlanmış) fonksiyonları elemanlara tahsis eder.

Mimari, sistemin karmaşıklığı alt gruplara ayrıldığında önemli bir mühendislik aşamasıdır .

Örnek: Evinizi düşünün, mutfağınız için bir mimara ihtiyacınız yok (sadece bir unsur dahil), ancak tüm binanın kapılar ve çatı gibi bazı etkileşim tanımlarına ihtiyacı var .

Tasarım , işlevin (önerilen) uygulamasının bilgilendirici bir temsilidir. Geri bildirim almak ve paydaşlarla tartışmak amaçlanmıştır. İyi bir uygulama olabilir , ancak temel bir mühendislik adımı değildir .

Mutfak kurulmadan önce mutfak tasarımını görmek güzel olurdu, ancak pişirme gereksinimi için gerekli değildir :

Bunu düşünürsem şunu söyleyebilirsin:

• mimari, daha ayrıntılı bir soyutlama düzeyinde bir kamu / mühendis içindir
• tasarım, daha az ayrıntılı bir soyutlama düzeyinde halka yöneliktir

Hatırlatıcım:

• Tasarımı birine sormadan değiştirebiliriz
• Mimariyi değiştirirsek onu birisine (ekip, müşteri, paydaş, ...) iletmemiz gerekir.

Sanırım Tasarım ve Mimari hakkında ne zaman konuştuğumuzu belirlemek için aşağıdaki kuralı kullanmalıyız: Oluşturduğunuz bir yazılım resminin unsurları bire bir programlama dili sözdizimsel yapı ile eşleştirilebiliyorsa, Mimari değilse Tasarım'dır.

Bu nedenle, örneğin, bir sınıf diyagramı veya bir sıra diyagramı görüyorsanız, Sınıf sözdizimsel yapısını kullanarak bir sınıfı ve bunların ilişkilerini Nesne Tabanlı Programlama diliyle eşleyebilirsiniz. Bu açıkça Tasarım. Ayrıca, bu tartışmanın bir yazılım sistemini uygulamak için kullanacağınız programlama dili ile bir ilişkisi olduğu tabloya getirebilir. Java kullanıyorsanız, Java Nesne Odaklı Programlama Dili olduğu için önceki örnek geçerlidir. Paketleri ve bağımlılıklarını gösteren bir şema bulursanız, Tasarım da budur. Öğeyi (bu durumda bir paket) Java sözdizimsel yapısıyla eşleyebilirsiniz.

Şimdi, Java uygulamanızın modüllere bölündüğünü ve her bir modülün (bir kavanoz dosyası dağıtım birimi olarak temsil edilir) bir paket kümesi olduğunu ve modül ve bağımlılıklarını içeren bir diyagramla sunulduğunu varsayalım, yani Mimari. Java'da bir modülü (bir paket kümesi) sözdizimsel bir yapıya eşlemenin bir yolu yoktur (en azından Java 7'ye kadar değil). Bu şemanın, yazılım modelinizin soyutlama düzeyinde bir adım daha yüksek olduğunu da fark edebilirsiniz. Bir paket şemasının üzerindeki herhangi bir şema (daha büyük taneli), Java programlama dilinde gelişirken bir Mimari görünümü temsil eder. Öte yandan, Modula-2'de gelişiyorsanız, bir modül diyagramı bir Tasarımı temsil eder.

( Http://www.copypasteisforword.com/notes/software-architecture-vs-software-design adresinden bir parça )

Şahsen, bunu beğendim:

"Tasarımcı, bir kullanıcı bir düğmeye bastığında olanlarla ilgileniyor ve mimar on bin kullanıcı bir düğmeye bastığında olanlarla ilgileniyor."

Mark Cade ve Humphrey Sheil tarafından hazırlanan Java ™ EE Eğitim Kılavuzu için SCEA

Birçok açıklamaya katılıyorum; esasen mimari tasarım ile yazılım sistemlerinin ayrıntılı tasarımı arasındaki ayrımı biliyoruz.

Tasarımcının amacı, şartnamelerde geliştirme için gerekli olduğu kadar kesin ve somut olmaktır; mimar, temel olarak, ayrıntılı tasarımın başlaması için gereken ölçüde sistemin yapısını ve küresel davranışını belirtmeyi amaçlamaktadır.

İyi bir mimar hiper spesifikasyonları önleyecektir - mimari aşırı tanımlanmamalı, ancak yeterli olmalıdır (mimari) kararlar, yalnızca ele alınması için en pahalı riskleri sunan ve etkili bir şekilde bir çerçeve ("ortaklık") sağlayan yönler için oluşturmalıdır. detaylı tasarım üzerinde çalışılabilir, yani yerel işlevsellik için değişkenlik.

Gerçekten de, mimari süreç veya yaşam döngüsü sadece bu temayı takip eder - (mimari olarak) önemli iş gereksinimleri için yapıyı özetlemek ve daha somut çıktılar için tasarım aşamasına daha fazla ayrıntı bırakmak için yeterli düzeyde soyutlama.

Mimari tasarımdır, ancak tüm tasarım mimari değildir. Bu nedenle, açık konuşmak gerekirse, mimari tasarım ile mimari olmayan tasarım arasında ayrım yapmaya çalışmak daha anlamlı olacaktır . Ve fark nedir? Değişir! Her yazılım mimarının farklı bir yanıtı olabilir (ymmv!). Buluşsal yöntemlerimizi 'sınıf diyagramları mimarlık ve sıra diyagramları tasarım' gibi bir cevap bulmak için geliştiriyoruz. DSA kitabına bakın fazla .

Mimarinin tasarımdan daha yüksek bir soyutlama düzeyinde olduğunu veya mimarinin mantıklı olduğunu ve tasarımın fiziksel olduğunu söylemek yaygındır. Ancak bu fikir, yaygın olarak kabul edilse de, pratikte işe yaramaz. Yüksek veya düşük soyutlama, mantıksal ve fiziksel arasındaki çizgiyi nerede çiziyorsunuz? Değişir!

Benim önerim:

• tek bir tasarım belgesi yarat.
• bu tasarım belgesini istediğiniz şekilde veya daha iyi, okuyucuların daha alıştığı şekilde adlandırın. Örnekler: "Yazılım Mimarisi", "Yazılım Tasarım Spesifikasyonu".
• bu belgeyi görünümlere ayırın ve başka bir görünümün ayrıntılandırılması olarak bir görünüm oluşturabileceğinizi unutmayın.
• çapraz referanslar veya köprüler ekleyerek belgedeki görünümleri gezinilebilir hale getirme
• tasarımın geniş ancak sığ bir görünümünü gösteren daha yüksek düzey görünümlere ve dar ancak daha derin tasarım ayrıntılarını gösteren uygulamaya daha yakın görünümlere sahip olacaksınız.
• çoklu görünüm mimarisi belgesine ( burada ) bir göz atmak isteyebilirsiniz .

Tüm bunları söyledikten sonra , sormamız gereken daha alakalı bir soru şudur: ne kadar tasarım yeterlidir? Yani, tasarımı tanımlamayı ne zaman bırakmalıyım (diyagramlarda veya nesirlerde) ve kodlamaya geçmeliyim?

Evet, kulağa doğru geliyor. Tasarım yapacağınız şeydir ve mimari, tasarımın parçalarının ve parçalarının bir araya getirileceği yoldur. Bu dil agnostik olabilir, ancak normal olarak kullanılacak teknolojileri belirtirdi, yani LAMP v Windows, Web Service v RPC.

Bir programın veya bilgi işlem sisteminin yazılım mimarisi, yazılım bileşenlerini, bu bileşenlerin harici olarak görülebilir özelliklerini ve aralarındaki ilişkileri içeren sistemin yapısı veya yapılarıdır.

(Wikipedia'dan, http://en.wikipedia.org/wiki/Software_architecture )

Yazılım tasarımı, bir yazılım çözümü için problem çözme ve planlama sürecidir. Yazılımın amacı ve özellikleri belirlendikten sonra, yazılım geliştiricileri bir çözüm planı geliştirmek için tasarımcıları tasarlayacak veya istihdam edecektir. Mimari görünümün yanı sıra düşük seviyeli bileşen ve algoritma uygulama konularını içerir.

(Wikipedia'dan, http://en.wikipedia.org/wiki/Software_design )

Kendim daha iyi söyleyemezdim :)

Mimarlığı Patrick Karcher'ın yaptığı gibi görüyorum - büyük resim. Örneğin, bir binaya mimariyi sağlayabilir, yapısal desteğini, pencereleri, girişleri ve çıkışları, su drenajını vb. Görüntüleyebilirsiniz. Ancak zemin düzenini, kabin pozisyonlarını vb.

Yani binayı tasarlarken her ofisin düzenini tasarlamamışsınızdır. Aynı şey yazılım için de geçerli.

Düzeni tasarlamayı "Düzeni tasarlamak" olarak görebilirsiniz ...

Güzel soru ... Aralarındaki çizgi neredeyse parlak bir çizgi olmasa da, imho, eğer her iki terimi de kullanıyorsanız, o zaman Mimarlık bir şeyin nasıl inşa edileceği veya inşa edileceğine dair daha teknik veya yapısal kararları, özellikle de zor olacak kararları ( Tasarım daha sonra kolayca değiştirilebilen kararları kapsar (yöntem adları, sınıf <-> dosya organizasyon yapısı, tasarım modelleri, belirli bir sorunu çözmek için tekli veya statik bir sınıf kullanılıp kullanılmayacağı gibi) vb.) ve / veya bir sistemin veya uygulamanın (İnsan Arayüzü, kullanım kolaylığı, görünüm ve his vb.) görünümünü veya estetik yönlerini etkileyenler.

Yazılım mimarisi , “hesaplamaların algoritmalarının ve veri yapılarının ötesinde” sorunlarla ilgilenir.

Mimari özellikle ilgili değildir… uygulamaların ayrıntıları (örn. Algoritmalar ve veri yapıları.) Mimari tasarım, genellikle OOD tarafından sağlanandan daha zengin bir soyutlama koleksiyonu içerir ”(nesne yönelimli tasarım).

tasarlamak , tasarım öğelerinin modülerleştirilmesi ve ayrıntılı arabirimleri, algoritmaları ve prosedürleri ve mimariyi desteklemek ve gereksinimleri karşılamak için gereken veri türleri ile ilgilidir.

“Mimari” genellikle “tasarım” ile eşanlamlı olarak kullanılır (bazen “üst düzey” sıfatından önce gelir). Birçok kişi “mimari desenler” terimini “tasarım desenleri” ile eşanlamlı olarak kullanmaktadır.

Bu bağlantıya göz atın.

Mimari, Tasarım ve Uygulama Terimlerini Tanımlama

Mimari:
Teknik açıdan önemli gereksinimleri sisteme taşıyan daha yüksek soyutlama seviyelerinde yapısal tasarım çalışmaları. Mimari, daha fazla tasarım için temel oluşturuyor.

Tasarım:
Her soyutlama katmanında yinelemeli bir süreçle mimarinin yapmadığı şeyleri doldurma sanatı.

Mimariyi tasarımdan ayırmak için bu kuralı gerçekten beğendim:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

Buna Niyet / Yerellik hipotezi denir. Yerel olmayan ve boyutsal olan yazılımın niteliğine ilişkin açıklamalar mimari niteliktedir. Yerel ve içsel ifadeler tasarımdır.

... uzun zaman önce uzak bir yerde filozoflar bir ve birçok arasındaki ayrım konusunda endişeli. Mimarlık, birçoğunu gerektiren ilişki ile ilgilidir. Mimarinin bileşenleri vardır. Tasarım, içeriği gerektiren içerikle ilgilidir. Tasarımın özellikleri, nitelikleri, özellikleri vardır. Tipik olarak tasarımın mimaride olduğunu düşünüyoruz. Dualist düşünce, çoğunu ilkel olarak verir. Ancak mimari de tasarımın içindedir. Önümüzde olanı - tek ya da çok - görüntülemeyi seçtik.

Oldukça öznel ama benim almak:

Mimari Diğer sistemlerle etkileşimler, donanım gereksinimi, genel bileşen tasarımı ve veri akışı dahil sistemin genel tasarımı.

Tasarım Bir bileşenin genel sistemdeki organizasyonu ve akışı. Bu, diğer bileşenlerle etkileşim için bileşenin API'sını da içerir.

Yazılım mimarisi en iyi, iş ve projelerin daha yüksek mimari seviyelerle tanımlandığı uygulamaları projelere yansıtmanız gerektiğinde sistem düzeyinde kullanılır.

Örneğin, işletmeniz tüccarlar için "Kâr ve Zarar" ile ilgilidir ve ana işlevleriniz "portföy değerlendirmesi" ve "risk hesaplama" yı içerir.

Ancak bir Yazılım Mimarı çözümünü detaylandıracağı zaman, şunu fark edecektir:

"portföy değerlendirmesi" sadece bir uygulama olamaz. Aşağıdaki gibi yönetilebilir projelerde rafine edilmesi gerekir:

• GUI
• Başlatıcı
• hareket memuru
• ...

(içerdiği işlemler o kadar büyük olduğundan, ortak bir GUI aracılığıyla her zaman izlenirken birkaç bilgisayar arasında bölünmeleri gerekir)

Yazılım tasarımı farklı uygulamaları, teknik ilişkilerini ve dahili alt bileşenlerini inceler.
Son Mimari katmanın ("Teknik Mimari") üzerinde çalışması için (teknik çerçeve veya enine bileşenler açısından) ve proje ekiplerinin ( işletme fonksiyonlarının uygulanmasına daha fazla odaklanılması ) başlaması için gereken spesifikasyonları üretecektir. ilgili projeleri.

eğer birisi bir gemi inşa ederse, motor, gövde, elektrik devreleri vs. onun "mimari unsurları" olacaktır. Onun için motor yapımı "tasarım işi" olacak.

Daha sonra motorun yapımını başka bir ekibe devrederse, bir "motor mimarisi" yaratacaklar ...

Yani - soyutlama veya detay seviyesine bağlıdır. Bir kişinin mimarisi, annelerin tasarımı olabilir!

Mimarlık, "değiştirilmesi zor tasarım kararlarıdır".

Pratik olarak tasarımınızın her zaman değiştiği anlamına gelen TDD ile çalıştıktan sonra, kendimi sıklıkla bu soru ile mücadele ederken buldum. Yukarıdaki tanım , Kurumsal Uygulama Mimarisi Kalıpları'ndan alınmıştır, Martin Fowler

Bu, mimarinin sisteminizin Diline, Çerçevesine ve Etki Alanına bağlı olduğu anlamına gelir. Java Class'ınızdan 5 dakika içinde bir arabirimi ayıklayabiliyorsanız, artık bir mimari karar vermez.

Cliff Notes sürümü:

Tasarım: İstenen ürünün özelliklerine göre bir çözüm uygulamak.

Mimari: Tasarımınızı destekleyen temel / araçlar / altyapı / bileşenler.

Bu, birçok yanıtı çağıracak oldukça geniş bir sorudur.

Mimari, bir sistem oluşturmak için ortaya çıkan tasarım desenlerinin koleksiyonudur.

Sanırım Tasarım tüm bunları bir araya getirmek için kullanılan yaratıcılık mı?

Yazılım mimarisi terimi neredeyse 20 yaşındayken, yazılım tasarımı daha uzun bir geçmişe sahiptir. Bu nedenle, şu anda büyüyen ağrılardan geçiyor.

Akademisyenler Mimarlık'ı daha geniş yazılım tasarımı alanının bir parçası olarak görme eğilimindedir. Her ne kadar Arch'ın kendi içinde bir alan olduğuna dair artan bir kabul var.

Uygulayıcılar Arch'ı stratejik olan ve geri alınacak bir projede maliyetli olabilecek üst düzey tasarım kararları olarak görme eğilimindedir.

Arch ve tasarım arasındaki kesin çizgi, yazılım etki alanına bağlıdır. Örneğin, Web Uygulamaları alanında, katmanlı mimari şu anda en popüler hale gelmektedir (Biz Mantık Katmanı, Veri Erişim Katmanı, vb.) Bu Arch'ın daha alt düzey bölümleri tasarım (sınıf diyagramları, yöntem imzaları vb.) ) Bu, gömülü sistemlerin, işletim sistemlerinin, derleyicilerin vb. Alanlarında farklı tanımlanır.

Mimari yüksek, soyut ve mantıklı bir tasarım, yazılım tasarımı ise düşük, ayrıntılı ve fiziksel bir tasarımdır.

Ayrıca bakınız: http://en.wikipedia.org/wiki/4%2B1_Architecture_View_Model

Roy Thomas Fielding'in makalesinde yazılım mimarisinin ne olduğuyla ilgili tanımını ve açıklamasını seviyorum: Mimari Stiller ve Ağ Tabanlı Yazılım Mimarilerinin Tasarımı

Yazılım mimarisi, işletiminin bir aşaması sırasında bir yazılım sisteminin çalışma zamanı öğelerinin bir soyutlamasıdır. Bir sistem, her biri kendi yazılım mimarisine sahip birçok soyutlama seviyesinden ve birçok çalışma aşamasından oluşabilir.

"Çalışma zamanı öğelerini" ve "soyutlama düzeylerini" vurgulamaktadır.

Buna kesin bir cevap yoktur, çünkü "yazılım mimarisi" ve "yazılım tasarımı" nın oldukça fazla tanımı vardır ve ikisi için de kanonik bir tanım yoktur.

Bunu düşünmenin iyi bir yolu Len Bass, Paul Clements ve Rick Kazman'ın "tüm mimari tasarımdır, ancak tüm tasarım mimari değildir" ifadesidir [Uygulamada Yazılım Mimarisi]. Buna tamamen katıldığımdan emin değilim (çünkü mimari başka aktiviteler de içerebilir) ancak mimarinin tasarımın kritik alt kümesiyle ilgilenen bir tasarım faaliyeti olduğu gerçeğini yakalar.

Biraz saygısız tanımım ( SEI tanımları sayfasında bulundu ), yanlış yapılırsa projenizin iptal edilmesine neden olan kararlar kümesidir.

Mimari, tasarım ve uygulamayı kavram olarak ayırmaya yönelik faydalı bir girişim, Amnon Eden ve Rick Kazman tarafından birkaç yıl önce burada bulunabilen "Mimarlık, Tasarım, Uygulama" başlıklı bir araştırma makalesinde yapıldı: http: //www.sei.cmu .edu / kütüphane / varlıklar / ICSE03-1.pdf . Onların dili oldukça soyut ama simplistically onlar söylüyorlar mimarisi birçok bağlamlarda kullanılabilir ve sistem boyunca uygulanmak üzere içindir tasarımdır, tasarım birçok bağlamlarda kullanılabilir ancak belirli bir kısmında uygulanan (err) tasarımdır sistemin ve uygulama bağlamında tasarım özeldir ve bu bağlamda uygulanır.

Mimari bir karar, sistemi RPC yerine mesajlaşma yoluyla entegre etme kararı olabilir (bu nedenle birçok yerde uygulanabilen ve tüm sisteme uygulanması amaçlanan genel bir prensiptir), bir tasarım kararı bir master kullanmak olabilir / giriş girdisi işleme modülündeki / slave iş parçacığı yapısı (herhangi bir yerde kullanılabilen ancak bu durumda yalnızca bir modülde kullanılan genel bir ilke) ve son olarak, bir uygulama kararı güvenlik için sorumlulukları İstek Yönlendiricisinden taşımak olabilir İstek Yöneticisi modülündeki İstek İşleyicisine (yalnızca bu bağlamla ilgili, bu bağlamda kullanılan bir karar) başvurun.

Umarım bu yardımcı olur!