Proqram təminatı və proqram təminatının hazırlanması

Kimsə Software Design və Software Architecture arasındakı fərqi izah edə bilərmi?

Daha dəqiq olaraq; Kimsə sizə "dizayn" ilə tanış olmanızı söyləyirsə - bunlardan nə gözləyirsiniz? Eyni "memarlıq" üçün də gedir.

Mənim əsl anlayışım:

  • Dizayn: sistemin xüsusi bir modul / hissəsi üçün UML diaqramı / blok diaqramı / sadə çərçivələr (istifadəçi interfeysi üçün).
  • Memarlıq: komponent diaqramı (sistemin müxtəlif modulları bir-biri ilə və digər sistemlərlə necə qarşılıqlı olduğunu göstərir), hansı dil istifadə edilməlidir, şablon ...?

Yanlış olsam məni düzəlt. Vikipediyanı http://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Software_architecture saytında məqalələr var, amma əminəm ki, onları düzgün başa düşdüm.

342
01 апр. Mads Mobæk təyin 01 Apr. 2009-04-01 13:00 '09 saat 13:00 'da, 2009-04-01 13:00
ответ 41 cavab
  • 1
  • 2

Bəli, haqlısın. Sistemin arxitekturası onun "skeleti" dir. Bu, sistemin ən yüksək səviyyədə soyudulmasıdır. Modulların bir-biri ilə qarşılıqlı əlaqəsi olan, hansı bərpa sistemlərinin mövcud olduğu hansı məlumatların saxlanması mövcuddur. Dizayn nümunələri ilə yanaşı, memarlıq nümunələri də var: MVC, üç səviyyəli çoxsəviyyəli dizayn və s.

Proqram inkişafı fərdi modulların / komponentlərin dizaynıdır. X modulunun vəzifələri və funksiyaları hansılardır? Y sinifindən? O nə edə bilər və nə deyil? Nə dizayn nümunələrini istifadə edə bilərəm?

Beləliklə, proqram dizaynı modul / komponent / sinif səviyyəsini vurğulayır, proqram təminatı dizaynı bütün sistemin dizaynı ilə daha çox bağlıdır.

329
01 апр. cavab Razzie 01 apr verilir . 2009-04-01 13:19 '09 saat 13:19 'da 2009-04-01 13:19

SDLC (proqram inkişafı dövrünün dövrü) bəzi təsvirlərində onlar bir-birini əvəz edirlər, lakin konsensus onlar fərqlidir. Eyni zamanda: müxtəlif (1) mərhələlər, (2) məsuliyyət sahələri və (3) qərarların qəbul səviyyəsi.

  • Memarlıq daha ümumi bir şəkil: çərçivələr, dillər, sahələr, məqsədlər və yüksək səviyyəli metodikaların seçilməsi ( Rational , şəlalə , çevik və s.).
  • Dizayn daha kiçik bir şəkil: kodun necə təşkil ediləcəyi planı; sistemin müxtəlif hissələrinə aid olan müqavilələrə necə baxmaq lazımdır; Layihə metodologiyalarının və məqsədlərinin daimi tətbiqi. Spesifikasiya bu mərhələdə yazılmışdır.

Bu iki mərhələ müxtəlif səbəblərlə birləşir.

border=0
  • Kiçik layihələr tez-tez planlaşdırma mərhələləri bölmək üçün kifayət qədər imkanları yoxdur.
  • Layihə daha böyük bir layihənin bir hissəsi ola bilər və buna görə də hər iki fazın hissələri artıq həll edilmişdir. (Mövcud verilənlər bazaları, sazişlər, standartlar, protokollar, çərçivələr, təkrar istifadə kodu və s. Mövcuddur).
  • SDLC haqqında daha yaxşı düşünmə yolları ( Çevik metodologiyalara bax) bir az bu ənənəvi yanaşmanın yenidən qurulmasıdır. Dizayn (daha az dərəcədə memarlıq) SDLC ərazisində baş verir. Tez-tez bütün proseslərin yenidən və baş verdiyi yerlərdə daha çox yinelemeler var.
  • Hər hansı bir halda proqram inkişafı çətin və mürəkkəbdir, lakin müştərilər / menecerlər / satıcılar, adətən, axının ortasında hədəfləri və tələbləri dəyişdirməyi çətinləşdirirlər. Dizayn və hətta arxitektura həlləri, bir plan olub-olmadığı təqdirdə, sonradan layihədə istifadə edilməlidir.

Səhnələri və ya məsuliyyət sahələri hər yerdə birləşdiyi və olmasına baxmayaraq, qərarların hansı səviyyədə olacağını bilmək həmişə yaxşıdır. (Biz bununla davamlı olaraq davam edə bilərik. Mən bunu bir xülasədə saxlamağa çalışıram). Mən bitirəcəyəm: Layihənizdə rəsmi bir memarlıq və ya layihə mərhələsi yoxdur / AOR / sənədləşmə kimi görünsə belə, bunu hər kəs bilir və ya etməz. Heç kimə bir arxitektura verməyə qərar verməsə, onda bir səhv səhv baş verir, yəqin ki, yoxsuldur. Dizayn üçün də eyni. Onların təqdimatının heç bir rəsmi mərhələsi olmadığı təqdirdə, bu anlayışlar daha vacibdir .

80
24 дек. Patrick Karcher tərəfindən verilmiş cavab 24 dekabr 2009-12-24 18:39 '09 at 18:39 'da 2009-12-24 18:39

Memarlıq strateji, dizayn tərtibdir.

Memarlıq çərçivəsində çərçivələr, alətlər, proqramlaşdırma paradiqmaları, komponentlərə əsaslanan proqram təminatının inkişaf standartları və yüksək səviyyəli prinsiplər daxildir.

Dizayn dizayn nümunələri, proqramlaşdırma deyimləri və refactoring kimi yerli məhdudiyyətlərlə əlaqəli bir fəaliyyət olsa da.

55
24 дек. Dekabrın 24-də Chris Kannon tərəfindən verilmiş cavab 2009-12-24 18:44 '09 at 18:44 'da 2009-12-24 18:44

Mən bunu arxitektura və dizayn arasında sadə bir fərq axtarırdıq.
Onlara baxmağın bu yolu haqqında nə düşünürsünüz?

  • Memarlıq
  • - "nə" qururuq;
  • biz necə qururuq;
38
28 марта '12 в 20:36 2012-03-28 20:36 Cavab George S. tərəfindən verildi 28 mart '12 saat 20:36 2012-03-28 20:36
  • Memarlıq kompüter və ya kompüter sisteminin konseptual strukturu və məntiqi təşkilatı deməkdir.

    Dizayn, yaradılmış bir sistemin və ya obyektin görünüşünü və funksiyasını və ya əməliyyatını göstərmək üçün yaradılmış bir plan və ya rəsmdir.

  • Əgər "arxiv" bir komponent varsa, daha böyük bir sistemdə necə davranırsınız.

    Eyni komponenti "dizayn" etsəniz, necə davranırsınız.

Bütün memarlıq dizayndır, lakin bütün dizayn memarlıq deyil.

Dizaynın What hissəsi, konkret bir tətbiq WhatWhatHow mimarinin kəsişməsi.

Memarlıq və dizaynın fərqləndirilməsi üçün görüntü :

2019

21
19 дек. Cavab verdi TryinHard 19 Dekabr. 2013-12-19 07:56 '13 'da 7:56' de 2013-12-19 07:56

Mən hesab edirəm ki, sən doğru deyirəm

Memarlıq sistem elementləri üçün sistem tələblərinin paylanmasıdır. Memarlıq haqqında dörd bəyanat:

  • Dil və ya nümunələr kimi qeyri-funksional tələbləri təqdim edə bilər.
  • Komponentlər, interfeyslər, vaxt və s. Arasındakı qarşılıqlı əlaqəni müəyyən edir.
  • Yeni xüsusiyyətləri təqdim etməməli,
  • Sistem elementlərin yerinə yetirilməsi üçün lazım olan funksiyaları vurğulayır.

Memarlıq mühüm bir addımdır. sistemin mürəkkəbliyi bölünsə.

Məsələn: evinizi düşünün, mətbəxiniz üçün bir memarın ehtiyacınız yoxdur (yalnız bir element iştirak edir), lakin tam bir bina üçün bir qapı və dam kimi bir sıra qarşılıqlı anlayışlar lazımdır.

Dizayn bu funksiyanı həyata keçirilməsinin informativ təqdimatıdır. Bu, maraqlı tərəflərlə rəy və müzakirələr almaq üçün nəzərdə tutulub. Bu yaxşı bir təcrübə ola bilər amma əhəmiyyətli bir inkişaf addımı deyil .

Mətbəx dizaynı mətbəxdən əvvəl təqdim olunduğunu görmək yaxşı olardı, amma yemək üçün vacib deyildir:

Mən bunu düşünsəm, aşağıdakıları göstərə bilərsiniz:

  • Memarlıq
  • ictimaiyyət / mühəndislər üçün daha ətraflı səviyyədə soyuducu səviyyədə hazırlanmışdır.
  • dizayn ictimaiyyət üçün daha az ətraflı soyutma səviyyəsində nəzərdə tutulmuşdur.
15
16 марта '11 в 13:03 2011-03-16 13:03 cavab 16 mart 2011-ci il tarixində saat 13 : 03 -də verilmişdir

Xatırladım:

  • Dizaynı heç kimdən soruşmadan dəyişə bilərik.
  • Mimariyi dəyişdirsək, onu birinə (qrup, müştəri, maraqlı tərəflər, ...)
14
24 нояб. Cavab Peter Gfader tərəfindən verilir 24 noyabr. 2012-11-24 02:31 '12 at 2:31 am 2012-11-24 02:31

Hesab edirəm ki, dizayn və arxitektura haqqında söhbət etdiyimiz zaman müəyyən etmək üçün aşağıdakı qaydanı istifadə etməyimiz lazımdır: yaratdığınız proqramın elementləri proqramlaşdırma dilinin sintaksisinə uyğun olaraq birləşdirilə bilərsə, o zaman heç bir Memarlıq olmadığı təqdirdə Dizayndır.

Beləliklə, məsələn, sinfi diaqram və ya ardıcıllıq diaqramını görürsəniz, sinfi sintaksisindən istifadə edərək, bir sinif və onun əlaqəsini obyekt yönümlü proqramlaşdırma dili ilə əlaqələndirə bilərsiniz. Bu, aydın bir dizayndır. Bundan əlavə, bu, müzakirənin proqram sistemini tətbiq etmək üçün istifadə edəcəyi proqramlaşdırma dili ilə bağlı olması ilə nəticələnə bilər. Java istifadə edirsinizsə, əvvəlki nümunə tətbiq olunur, çünki Java obyekt yönümlü bir proqramlaşdırma dilidir. Paketler ve bağımlılıkları gösteren bir diyagramla qarşılaşırsanız, bu da bir dizayndır. Bir element (bu halda paket) Java sözdəminimi ilə uyğun ola bilərsiniz.

İndi Java proqramınızın modullara bölündüyünü və hər modul paketlərin bir dəsti olduğunu (bir jar fayl yerləşdirmə vahidi kimi təqdim olunur) və modulları və onun bağımlılıklarını ehtiva edən bir diaqram və sonra da, Java (ən azı Java 7-dən əvvəl) bir modulun (paketlərin dəstini) sözdiziminə uyğunlaşması üçün heç bir yol yoxdur. Ayrıca, bu diagramın, proqram modelinizin soyutlanması səviyyəsindən yuxarı bir addımı təmsil etdiyini də fərq edə bilərsiniz. Yuxarıda göstərilən hər hansı bir diaqram (qaba dənəvərli) Java proqramlaşdırma dilində hazırlandıqda bir memarlıq təmsilçisini təmsil edən paket diaqramıdır. Digər tərəfdən, Modula-2 inkişaf etdirdiyiniz halda, modul diaqramı Dizayndır.

(fragman http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

6
14 июля '11 в 5:58 2011-07-14 05:58 Cavab Enrique Molinari tərəfindən 14 iyul 'da saat 05:58 ' də verildi

Mən şəxsən bu kimi idim:

"Dizayner istifadəçi bir düyməyə basarkən nə baş verdiyinə diqqət yetirir və memar on min istifadəçi düyməni basarkən nə olur."

Mark Cade və Humphrey Sheila tərəfindən Java ™ EE üçün SCEA təlimatı

5
12 апр. Tavi tərəfindən 12 apreldə cavab verildi 2010-04-12 20:04 '10 at 8:04 PM 2010-04-12 20:04

Mən bir çox şərhlə razıyam; əslində, biz memarlıq dizaynı və proqram təminatı sistemlərinin ətraflı inkişafı arasındakı fərqləri tanıyırıq.

Dizaynerin məqsədi spesifikasiyada dəqiq və spesifik olmalıdır, baxmayaraq ki, inkişaf üçün zəruridir; Memar əsasən sistemin strukturunu və qlobal davranışını ətraflı dizayn üçün tələb olunan şəkildə eyni şəkildə müəyyən etməyə çalışır.

Yaxşı bir memar hip-spesifikasiyanı maneə törədir - arxitekturanın həddindən artıq müəyyənləşdirilməməsi, lakin ən bahalı emal risklərini təqdim edən aspektlər üçün müəyyən edilmiş kifayət qədər (memarlıq) həllər olmamalı və effektiv bir şəkildə ("icma" ətraflı dizayn, yəni. Yerli funksionallıq üçün dəyişkənlik.

Həqiqətən, memarlıq prosesi və ya həyat dövrü sadəcə bu mövzunu izləyir - mənalı biznes tələbləri üçün bir struktur müəyyənləşdirmək və daha konkret nəticələr üçün dizayn mərhələsində daha çox detallar buraxmaq üçün kifayət dərəcədə soyutma səviyyəsi.

5
17 июня '12 в 0:54 2012-06-17 00:54 Cavab Ajay Shendye tərəfindən 17 İyun '12 'də 0:54 2012-06-17 00:54' də verilir

Memarlıq dizayndır, lakin bütün dizayn memarlıq deyil. Buna görə də, möhkəm bir şəkildə, memarlıq dizaynı və qeyri-memarlıq dizaynı ayırmaq üçün daha məqsədəuyğun olardı. Və fərq nədir? Bu asılıdır! Hər bir proqram memarının fərqli cavabları ola bilər (ymmv!). Cavab almaq üçün heuristikanı inkişaf etdiririk, məsələn, "sinif diaqramları memarlıq və ardıcıllıq diaqramları dizayndır". Ətraflı məlumat üçün DSA kitabına baxın .

Məlum olduğu kimi, memarlıq dizayndan daha yüksək səviyyədə soyutma səviyyəsindədir və ya memarlıq mantıksızdır və dizayn fizikidir. Lakin bu konsepsiya, ümumiyyətlə qəbul edilmiş olsa da, praktikada yararsızdır. Mantıksal və fiziki arasında yüksək və ya aşağı abstraction arasında bir xətt çəkirsiniz? Bu asılıdır!

Beləliklə, mənim təklifim:

  • vahid layihə sənədini yaratmaq.
  • Bu layihə sənədini oxucuların daha çox istifadə edildiyi kimi, istədiyiniz və ya daha yaxşı bir şəkildə adlandırın. Nümunələr: "Software Architecture", "Software Specification".
  • Bu sənədləri təqdimatlara ayırın və başqa bir təqdimatın zərifliyi kimi təqdimat hazırlaya bilərsiniz.
  • çapraz istinadlar və ya hiperlinklər əlavə etməklə sənəddə görünüşlər əldə edə bilərsiniz
  • sonra dizaynın geniş, lakin səthi görünüşünü və təqdimatın həyata keçirilməsinə yaxınlaşdıran daha yüksək səviyyəli təqdimatlara sahib olacaqsınız, bu da dizaynın dar, lakin daha dərin detallarını göstərəcəkdir.
  • Bir neçə baxış ( burada ) ilə bir memarlıq sənədinin bir nümunəsinə baxa bilərsiniz.

Bütün bunları söylədikdən sonra daha vacib bir sual soruşmalıyıq: nə qədər dizayn kifayətdir? Yəni bir dizaynı (diaqramlarda və ya nüsxədə) təsvir etməmə dayandırmalı və kodlaşdırmaya davam etməlidir?

5
24 апр. Apr 24-də Paulo Merson tərəfindən verilmiş cavab 2013-04-24 21:34 '13 at 9:34 pm 2013-04-24 21:34

Uzun müddət əvvəl uzaq bir yerdə, filosoflar bir-birindən çox fərqlənirlər. Memarlıq çox tələbat olan bir əlaqəsidir. Memarlıq komponentləri var. Dizayn onu tələb edən məzmundur. Dizayn xüsusiyyətləri, keyfiyyətləri, xüsusiyyətləri var. Biz adətən dizaynın memarlıqda olduğunu düşünürük. Dualistic düşüncə orijinal çox verir. Amma memarlıq da dizayndır. Bu, qarşımızda olanları - birini və ya digərini nəzərdən keçirməkdir.

3
05 апр. cavab verildi buzzcoda 05 Apr 2012-04-05 18:44 '12 at 18:44 2012-04-05 18:44

Mimariyi dizayndan ayırmaq üçün başparmak qaydasına görə bu məqaləni çox xoşuma gəldi:

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

Gərginliyin / yerin hipotezini çağırdı. Yerli və intensional olmayan proqram təminatı xarakterli bəyanat memarlıqdır. Yerli və intensional olan bəyanatlar konstruktivdir.

3
23 янв. Cavab LindsayBradford tərəfindən 23 Yanvar verilir 2012-01-23 07:58 '12 at 07:58 2012-01-23 07:58

Proqram təminatı arxitekturası "problemləri ilə bağlıdır ... alqoritmlər və hesablamaların məlumat strukturları hüdudlarından kənarda.

Arxitektura, xüsusilə ... tətbiqetmə detallarına (məsələn, alqoritmlər və məlumat strukturları) müraciət etmir. Memarlıq dizaynı OOD-dan (obyekt yönümlü dizayndan) daha çox zəngin abstraksiyalar ehtiva edir.

Dizayn dizayn elementlərinin modullaşdırılması və ətraflı interfeyslərinə, onların alqoritmlərinə və prosedurlarına, arxitekturanı dəstəkləmək və tələblərə cavab verən məlumat növlərinə yönəlib.

"memarlıq" tez-tez "dizayn" üçün sadə bir sinonim kimi istifadə olunur (bəzən "yüksək səviyyəli" sifətdən əvvəl). Və bir çox insanlar "dizayn naxışları" ilə müqayisədə "memarlıq nümunələri" termini istifadə edirlər.

Bu linki yoxlayın.

Tərslərin təsviri Memarlıq, dizayn və tətbiq

3
24 дек. Cavab Tebo 24 dekabrda verilir . 2009-12-24 18:50 '09 da 18:50 'da, 2009-12-24 18:50

Olduqca subyektiv, amma alacağam:

Memarlıq Ümumi sistem dizaynı, digər sistemləri ilə əlaqəli interfeys, hardware tələbləri, ümumi komponent dizaynı və məlumat axını.

Dizayn Dizaynı və ümumi sistemdə bir komponentin hərəkəti. Bu da digər komponentlərlə əlaqəli bir komponent API ehtiva edəcək.

3
24 дек. Cavab Jesse Vogt 24 dekabr. 2009-12-24 18:46 '09 at 18:46 2009-12-24 18:46

Bir proqramın və ya hesablama sisteminin proqram arxitekturası proqram komponentləri olan bir sistemin strukturu və ya strukturu, bu komponentlərin xarici görünən xüsusiyyətləri və onların arasındakı əlaqələrdir.

(Vikipediyadan, http://en.wikipedia.org/wiki/Software_architecture )

Proqram inkişafı problemlərin həlli və proqram həlli planlaşdırma prosesidir. Proqramın məqsəd və xüsusiyyətlərini müəyyən etdikdən sonra, proqram tərtibatçıları bir həll planı hazırlamaq üçün dizaynerləri inkişaf etdirəcək və ya istifadə edəcəklər. Bu komponentlə və aşağı səviyyəli alqoritmlə, eləcə də memarlıq görünüşü ilə bağlı problemləri əhatə edir.

(Vikipediyadan, http://en.wikipedia.org/wiki/Software_design )

Daha yaxşı deyə bilmərəm :)

3
24 дек. Cavab Larry Watanabe tərəfindən verilir 24 dekabr. 2009-12-24 18:45 '09, 18:45 'da, 2009-12-24 18:45

Yaxşı sual ... Hər iki şərtdən istifadə edərsəniz aralarındakı xətt çətin bir parlaq, kəskin xəttdir, imho olsa da, Memarlıq bir şeyin qurulması və ya inşa edilməsi ilə bağlı daha çox texniki və ya struktur qərarları, xüsusilə də, tətbiqdən sonra dəyişdirmək çətin olacaq (və ya daha çətin olacaq), Dizayn isə daha sonra dəyişdirmək asan olan həllər (məsələn, metod adları, sinif ↔ fayl təşkilatı strukturu, dizayn nümunələri, tək və ya statik müəyyən bir problemi həll etmək üçün cue sinfi və s.) və / və ya sistemin və ya tətbiqin görünüşünə və ya estetik aspektlərinə təsir edən (insan interfeysi, istifadə rahatlığı, görünüş, və s.).

3
24 дек. 24 dekabrda Charles Bretan tərəfindən cavab verildi. 2009-12-24 18:42 '09 da 18:42 'de 2009-12-24 18:42' de

Bəli, mənə doğru səslənir. Dizayn nə edəcəyiniz və memarlıq dizaynın bitləri və hissələrini birləşdirən bir vasitədir. Bu, agnostik bir dil ola bilər, amma istifadə ediləcək texnologiyaları, yəni, istifadə edəcəkdir. LAMP v Windows veb xidməti və RPC.

3
01 апр. Cavab MrTelly- ə verilib 01 Aprel. 2009-04-01 13:05 '09 saat 13:05 'da 2009-04-01 13:05

Mən Patrik Carcher kimi arxitekturanı görürəm - böyük şəkil. Məsələn, bir bina üçün memarlıq təmin edə, onun struktur dəstəkini, pəncərələrini, qeydləri və çıxışlarını, su drenajını və s. Amma siz mərtəbənin yerləşdirilməsini, kabin mövqeyini və s.

Bina inşa edərkən, hər ofis üçün bir plan hazırlamadınız. Hesab edirəm ki, proqram təminatı üçün də eyni.

Layihəni "layout mimarisi" olaraq dizayn edə bilərsiniz ...

3
24 дек. cavab mr-sk 24 dec tərəfindən verilir . 2009-12-24 18:45 '09, 18:45 'da, 2009-12-24 18:45

Memarlıq:
Структурная проектная работа на более высоких уровнях абстракции, которые реализуют технически значимые требования к системе. Архитектура закладывает фундамент для дальнейшего проектирования.

Дизайн:
Искусство наполнять то, что архитектура не проходит через итеративный процесс на каждом уровне абстракции.

3
ответ дан Joshua Ramirez 24 дек. '09 в 18:55 2009-12-24 18:55

если кто-то строит корабль, то его "архитектурные элементы" будут двигателем, корпусом, электрическими цепями и т.д. Для него конструкция двигателя будет "проектной работой".

Если он затем делегирует строительство двигателя другой команде, они создадут "архитектуру двигателя"...

Итак - это зависит от уровня абстракции или детализации. Архитектура одного человека может быть чужим дизайном!

2
ответ дан Gernot Starke 21 окт. '12 в 17:59 2012-10-21 17:59

Архитектура программного обеспечения лучше всего использовать на системном уровне, когда вам нужно проектировать бизнес и функции, идентифицируя более высокие уровни архитектуры в приложениях.

Например, ваш бизнес посвящен "Прибыль и убытки" для трейдеров, а ваши основные функции включают "оценку портфеля" и "расчет риска".

Но когда Software Architect будет подробно описывать его решение, он поймет, что:

"оценка портфеля" не может быть только одним приложением. Его нужно усовершенствовать в управляемых проектах, таких как:

  • GUI
  • Launcher
  • Диспетчерская
  • ...

(потому что задействованные операции настолько огромны, что их нужно разделить между несколькими компьютерами, при этом все время контролируется через общий графический интерфейс)

a Дизайн программного обеспечения рассмотрит различные приложения, их технические отношения и их внутренние подкомпоненты.
Он будет создавать спецификации, необходимые для последнего Архитектурного уровня ( "Техническая архитектура" ) для работы (с технической точки зрения или поперечной компоненты), а также для проектных групп (более ориентированных на реализацию бизнес-функций), чтобы начать их соответствующие проекты.

2
01 апр. cavab VonC 01 apr verilir . '09 в 14:00 2009-04-01 14:00

Архитектура - это "дизайнерские решения, которые трудно изменить.

После работы с TDD, что практически означает, что ваш дизайн постоянно меняется, я часто сталкивался с этим вопросом. Вышеприведенное определение извлекается из шаблонов архитектуры корпоративных приложений, Martin Fowler

Это означает, что архитектура зависит от языка, структуры и домена вашей системы. Если вы можете просто извлечь интерфейс из своего Java-класса за 5 минут, это уже не решение архитектуры.

2
ответ дан ekeren 24 марта '13 в 19:17 2013-03-24 19:17

Архитектура - это высокий уровень, абстрактный и логичный дизайн, тогда как дизайн программного обеспечения - это низкий уровень, подробный и физический дизайн.

1
ответ дан imran 24 февр. '11 в 8:32 2011-02-24 08:32

Версия отзыва Cliff:

Дизайн: Реализация решения на основе спецификаций желаемого продукта.

Архитектура: фундамент/инструменты/инфраструктура/компоненты, которые поддерживают ваш дизайн.

Это довольно широкий вопрос, который вызовет множество @.

1
ответ дан kd7 24 дек. '09 в 18:43 2009-12-24 18:43

Разработка программного обеспечения имеет более длинную историю, тогда как термин "архитектура программного обеспечения" составляет всего 20 лет. Следовательно, сейчас он переживает растущие боли.

Академики склонны видеть Архитектуру как часть более широкой области разработки программного обеспечения. Хотя растет признание того, что Arch является полем внутри него.

Практикующие склонны рассматривать Arch как решения высокого уровня, которые являются стратегическими и могут быть дорогостоящими в проекте для отмены.

Точная линия между Arch и дизайном зависит от домена программного обеспечения. Например, в области веб-приложений в настоящее время наиболее популярна многоуровневая архитектура (Biz Logic Layer, Data Access Layer и т.д.). Части нижнего уровня этой Arch считаются дизайном (диаграммы классов, сигнатуры методов и т.д.). ) Это будет определено по-разному в областях встроенных систем, операционных систем, компиляторов и т.д.

1
ответ дан LWoodyiii 29 дек. '10 в 16:03 2009-12-29 16:03

Нет окончательного ответа на этот вопрос, потому что "архитектура программного обеспечения" и "дизайн программного обеспечения" имеют довольно много определений, а также нет канонического определения.

Хороший способ думать об этом - Лен Басс, Пол Клементс и выражение Рика Казмана о том, что "вся архитектура - это дизайн, но не весь дизайн - архитектура" [Архитектура программного обеспечения на практике]. Я не уверен, что я вполне согласен с этим (поскольку архитектура может включать в себя другие действия), но она отражает суть архитектуры - это проектная деятельность, которая касается критического подмножества дизайна.

Мое немного легкомысленное определение (найдено на страница определений SEI ) заключается в том, что это набор решений, которые, если они сделаны ошибочно, то ваш проект будет отменен.

Полезная попытка отделить архитектуру, дизайн и реализацию, поскольку концепции были сделаны Амноном Иденом и Риком Казманом несколько лет назад в исследовательском документе под названием "Архитектура, проектирование, реализация", который можно найти здесь: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf . Их язык довольно абстрактен, но упрощенно говорят, что архитектура - это дизайн, который может использоваться во многих контекстах и ​​предназначен для применения в системе, дизайн (ошибочный) дизайн, который может использоваться во многих контекстах, но применяется в определенной части системы, а реализация - это дизайн, специфичный для контекста и применяемый в этом контексте.

Таким образом, архитектурное решение может быть решением интегрировать систему через обмен сообщениями, а не RPC (так что это общий принцип, который может применяться во многих местах и ​​предназначен для применения ко всей системе), конструктивное решение может быть используйте структуру потокового/подчиненного потока в модуле обработки запросов ввода (общий принцип, который можно использовать где угодно, но в этом случае используется только в одном модуле), и, наконец, решение по реализации может заключаться в том, чтобы переносить обязанности по обеспечению безопасности с Запрос-маршрутизатор для обработчика запроса в модуле диспетчера запросов (решение, релевантное только этому контексту, используемому в этом контексте).

Bu kömək edir!

1
ответ дан Eoin 14 окт. '13 в 0:49 2013-10-14 00:49

Кроме того, обратитесь к: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

1
ответ дан Durga Vaddi 04 июля '11 в 9:39 2011-07-04 09:39

Мне нравится определение и объяснение Roy Thomas Fielding о том, что такое архитектура программного обеспечения в его статье: Архитектурные стили и дизайн сетевых архитектурных приложений

Архитектура программного обеспечения представляет собой абстракцию элементов времени выполнения программной системы в течение некоторого этапа ее работы. Система может состоять из множества уровней абстракции и многих этапов работы, каждая со своей собственной архитектурой программного обеспечения.

Он подчеркивает "элементы времени выполнения" и "уровни абстракции".

1
ответ дан Jacky 12 янв. '13 в 17:14 2013-01-12 17:14

Архитектура и дизайн тесно связаны; основное различие между ними действительно связано с тем, с каким мы сталкиваемся. Архитектура обращена к стратегии, структуре и цели, к абстрактному. Дизайн обращается к реализации и практике, к конкретному.

1
ответ дан Hassan Ali 06 нояб. '13 в 17:33 2013-11-06 17:33
  • 1
  • 2

Другие вопросы по меткам или Задайте вопрос