(هدف ۲) طراحی، پیاده‌سازی، اعتبارسنجی، و مبنا قراردادنِ معماری

از آنجایی که هدفِ دوم فازِ معماری، مرتبط با معماری، دستاوردها، و فعالیت‌های مرتبط با آن می‌باشد، نخست باید تعریف مختصری از معماری داشته باشیم. «معماری نرم‌افزار» به صورت مفهومی، در برگیرنده‌ی تصمیم‌های کلیدی مرتبط با فراورده‌ی نرم‌افزاری است. برخی از این تصمیم‌ها، عبارتند از:

  • مهم‌ترین اجزاء سازنده‌ی ساختار سیستم، واسط‌های مربوط به این اجزاء و نیز تصمیم‌های مرتبط با خرید، ساخت، و یا استفاده‌ی مجدد از این اجزاء ساختاری.
  • توصیفی از چگونگی تعامل میان اجزاء سازنده در زمانِ اجرا (به منظور پیاده‌سازی مهم‌ترین سناریوهای شناسایی شده)
  • پیاده‌سازی و تستِ یک پیش‌الگو (پروتوتایپ) از معماری، به منظورِ اعتبارسنجی کارکِردِ سیستم، اطمینان از حل‌شدن ریسک‌های فنی عمده، دارا بودن شرایط کیفی مورد انتظار، کارایی، مقیاس‌پذیری، و هزینه.

می‌توان از مدلی تحت عنوانِ «معماری ۱+۴» برای توصیف معماری استفاده کرد. این مدل جنبه‌ها یا منظرهای مختلف معماری را با توجه به انتظارات هر یک از ذینفعان آن، در قالب مجموعه‌ای از منظرها بخش‌بندی‌ و توصیف می‌نماید. سندِ معماری نرم‌افزار که یکی از دستاوردهای مهم در چارچوب فرایند توسعه‌ی نرم‌افزار و بیانگر برخی ملاحظات مهم از معماری می‌باشد، نیز با توجه به همین مدل، سازماندهی می‌شود.
بنابراین، معماری بسیار فراتر از طرح و نقشه‌ است و علاوه بر ملاحظات ساختاری، شامل مسائل مرتبط با رفتارِ زمانِ اجرای سیستم، کارایی، و حتی ملاحظات مرتبط با هزینه و زمان نیز می‌‌باشد. برای اینکه معماری بتواند به خوبی ملاحظات مذکور را در خود، نشان دهد، باید شکلِ نرم‌افزاری داشته باشد. در واقع، معماری باید قابل اجرا (executable) باشد.
با ایجاد یک معماری قابلِ اجرا که پیش‌الگویِ معماری‌گونه (Architectural Prototype) نیز نامیده می‌شود، اِمکان بررسی و تأییدِ پاسخ‌گو بودن به نیازهای شناسایی‌شده، فراهم می‌گردد. آیا پایه و زیربنای مناسب و مستحکمی برای بنا کردن کلِ سیستم به وجود آمده است؟ همانگونه که تا استحکام و اطمینان از معماری و پاسخ‌گو بودن آن، اقدام به ایجاد یک ساختمان جدید نمی‌نمایید. می‌دانید که اگر معماری قابل اتکایی نداشته باشید، یا ساختمان فرو خواهد ریخت، یا به موقع تحویل‌نشده، و یا هزینه‌ی ساخت آن از مقدار پیش‌بینی اولیه فراتر می‌رود. این فرو ریختن ممکن است در حین ساخت و یا بعد از آن اتفاق بیافتد. آثار و تبعاتِ ناشی از داشتن یک معماری نامناسب در ساخت یک ساختمان، واضح و روشن است و می‌توان آنرا لمس نمود. امّا، متأسفانه چنین امری در رابطه با نرم‌افزار چندان محسوس نیست. خیلی بیشتز از میزانی که نگرانِ معماری یک ساختمان و یا یک پل هستیم، باید مراقب و نگرانِ معماری یک فراورده‌ی نرم‌افزاری باشیم. در بسیاری از موارد قوانین حاکم بر پدیده‌های فیزیکی به خوبی شناخته‌شده و با طراحی (و بدون اقدام به ساخت) می‌توان درباره‌ی معماری اشیاء فیزیکی نظیر ساختمان به اطمینان دست یافت. اما، در حیطه‌ی نرم‌افزار چنین نیست. به طور قطع، چیزی که بتواند نگرانی‌های ما را نسبت به معماری یک سیستم نرم‌افزاری رفع نماید، نمی‌تواند صرفاً چند طرح و نقشه باشد؛ ما به چیزی نیاز داریم که صحّت، کارایی، مقرون به صرفه‌بودن، و ملاحظاتی از این دست را اثبات نماید. تجربه نشان داه است که تنها و مطمئن‌ترین راهکار موجود برای اثبات معماری یک سیستم یا سرویس نرم‌افزاری، پیاده‌سازی پیش‌الگویِ معماری‌گونه از آن می‌باشد. حتی به واسطه‌ی اینکه مثلاً از فلان چارچوب استاندارد مانند JEE یا .Net استفاده می‌کنیم، نباید به هیچ وجه، اثباتِ کارایی معماری را فراموش نماییم.
در پایان فازِ معماری، به اصطلاح، معماری سیستم مبنا (baseline) قرار داده شده و تثبیت می‌گردد. مبنا قرار گرفتن معماری بدان معناست که شما می‌توانید از معماری‌‌تان به عنوان یک مرجعِ مستحکم و قابلِ اعتماد برای بنا نمودنِ بقیه‌ی سیستم استفاده نمایید. از این نقطه به بعد، هر گونه تصحیح و تغییری در معماری، باید با احتیاط و تنها در صورتی‌که دارای دلیل منطقی باشد، انجام شود. توجه داشته باشید که هر چه پروژه دارای پیچیدگی‌های فنی بیشتری باشد، تثبیت معماری مهم‌تر و حیاتی‌تر خواهد بود.
در واقع با تثبیت معماری و رساندن آن به وضعیت مبنا قرار گرفتن، راه‌حلِ مسأله، اثبات می‌گردد. مادامی که به یک راه‌حلِ اثبات شده نرسیده‌ایم، به هیچ وجه واردِ فازِ بَعد، یعنی فازِ ساخت، نخواهیم شد.
شکل‌گیری معماری، قالبِ کلی و ماهیّت‌ِ آن، با پیاده‌سازی برخی از مواردِ کاربرد (use case) که به اصطلاح از نظر معماری قابل ملاحظه می‌باشند، انجام می‌شود. در طی فاز استارتاپ، حدود بیست تا سی درصد از مواردِ کاربرد شناسایی شده است. این مواردِ کاربرد، نقش ارزنده‌ای در شکل‌گیری ماهیتِ سیستم و تعریفِ آن ایفا می‌نمایند. برخی از همین مواردِ کاربرد، در شکل‌گیری معماری نیز نقش دارند.
البته توجه داشته باشید که علاوه بر مواردِ کاربردِ اشاره‌شده، باید برخی از عناصرِ خاص از نیازمندی‌ها که عمدتاً نیازمندی‌های غیر وظیفه‌مندی (Non-functional Requirements) می‌باشند را نیز شناسایی نمایید. البته شناسایی مواردِ کاربرد مهم به لحاظ معماری و نیز نیازمندی‌های غیر وظیفه‌مندی، از مشکل‌ترین و در برخی موارد پیچیده‌ترین فعالیت‌های پروژه می‌باشد. همکاری میان نقش‌های «مهندس فرایند»، «معمار»، و «مدیر پروژه»، تأثیر بسیار زیادی بر تثبیتِ موفق‌آمیز معماری دارد.
برای اطمینان از پوشش مناسبِ تمام ملاحظات معماری، ممکن است انتخاب و پیاده‌سازی جزئی چند موردِ کاربردِ غیر مهم نیز لازم باشد. طراحی بانک اطلاعاتی، توصیف معماری در زمانِ اجرا (یعنی بررسی ملاحظاتی مانند همروندی، پردازه‌ها، تِـرِدها (threads)، و توزیع‌شدگی فیزیکی)، شناسایی مکانیزم‌های معماری، پیاده‌سازی سناریو‌های حیاتی، یکپارچه‌سازی مؤلفه‌ها، و تستِ سناریوهای حیاتی، از دیگر فعالیت‌های مهم در فاز معماری است. بدین ترتیب، بخش عمده‌ا‌ی از ریسک‌های قابل ملاحظه‌ی سیستم و پروژه، رفع خواهند شد.

تماس با ما

در حال ارسال

Log in with your credentials

Forgot your details?