مقدمه ای بر طراحی و معماری سیستم ها

در این بخش قصد داریم در مورد جمع آوری، طبقه بندی و تجزیه و تحلیل نیازمندی ها به عنوان اولین گام در طراحی یک سیستم در مقیاس بزرگ صحبت کنیم.

اما قبل از پرداختن به جزئیات، اجازه دهید ابتدا کمی انگیزه پیدا کنیم.

الزامات سیستم فقط یک کلمه رسمی برای فهمیدن و محدود کردن مواردی است که دقیقاً باید برای مشتری خود بسازیم. به عنوان مهندس نرم افزار، ما نباید در دریافت الزامات غیررسمی برای وظیفه ای که باید انجام دهیم، تازه وارد باشیم.

اما وقتی صحبت از طراحی یک سیستم در مقیاس بزرگ می‌شود، تفاوت‌های کمی با الزامات معمولی که برای پیاده‌سازی یک روش، یک الگوریتم یا یک کلاس استفاده می‌کنیم، وجود دارد. اولین تفاوت دامنه و میزان انسداد الزامات و به ویژه راه حلی است که باید طراحی کنیم.

به عنوان مثال، هنگامی که ما وظیفه داریم یک متد یا یک الگوریتم را در یک پایه کد موجود پیاده سازی کنیم، معمولاً می دانیم ورودی و خروجی چه شکلی هستند. ما همچنین تا حدودی به زبان های برنامه نویسی که قرار است استفاده کنیم محدود شده ایم. همانطور که ما به یک مانع سطح بالاتر مانند طراحی یک کلاس، یک ماژول، یک کتابخانه یا یک برنامه می رویم، دامنه راه های ممکن برای حل مشکل بزرگتر و بزرگتر می شود زیرا درجات آزادی بیشتری داریم.

همچنین دامنه مشکل آنقدر زیاد می شود که حتی تجسم اجرای آن را برای ما سخت می کند. بنابراین وقتی از ما خواسته می شود که یک سیستم کامل را طراحی کنیم، ممکن است آنقدر احساس غرق شدن کنیم که حتی ندانیم از کجا شروع کنیم.

به عنوان مثال، تصور کنید از شما خواسته می‌شود یک سیستم ذخیره‌سازی فایل، یک راه‌حل پخش ویدئو، یا یک سرویس خودروی اشتراکی طراحی کنید، باید مقیاس آن به میلیون‌ها کاربر در روز ارائه شود. سخت است که در چنین کاری غرق نشوید. دومین چالش و تفاوت با آنچه که معمولاً به آن عادت کرده ایم، سطح ابهام است. دلیل این ابهام دو چیز است. اول از همه، در بسیاری از موارد، الزامات حتی از جانب یک مهندس نیست، و حتی گاهی اوقات آنها از یک فرد بسیار فنی نیز ارائه نمی شوند. بنابراین مشتری یا مدیر محصول ممکن است چیزی سطح بسیار بالا را بخواهد. و این مسئولیت ماست که این درخواست ها را به الزامات دقیق و فنی تبدیل کنیم.

این الزامات فنی به عنوان پایه ای برای ساخت معماری نرم افزار ما عمل خواهند کرد. دلیل دوم برای سطح بالای ابهام، دریافت الزامات خاص در حال حاضر بخشی از راه حل است. این ممکن است در ابتدا برای ما کمی عجیب به نظر برسد، اما باید به خاطر داشته باشیم که مشتری همیشه دقیقاً نمی داند به چه چیزی نیاز دارد.

confused mr bean

تنها چیزی که آنها با اطمینان می دانند مشکلی است که باید حل کنند. برای نشان دادن این موضوع، بیایید یک مثال خاص بزنیم.

فرض کنید از ما خواسته شده است که یک سرویس درخواست خودرو طراحی کنیم که به مردم امکان می‌دهد به رانندگانی بپیوندند که آماده سفر هستند می‌کنند و مایلند مسافران را در ازای پرداخت هزینه در مسیر خود ببرند. این ممکن است تمام الزاماتی باشد که ما از مشتری دریافت می کنیم، و این به ما بستگی دارد که چیزهایی مانند این را بپرسیم که آیا این یک سرویس real time خواهد بود یا مسافران باید از قبل با رانندگان تماس بگیرند.

driver application

اپلیکیشن موبایل یا دسکتاپ یا شاید هر دو، آیا می‌خواهیم پرداخت را از طریق سیستم خود فعال کنیم یا مسافران باید مستقیماً بصورت نقدی به رانندگان پرداخت کنند؟

در برخی موارد، مشتری حتی ممکن است بلافاصله پاسخ آن سؤالات را نداند تا زمانی که واقعاً آن سؤالات را نپرسیم. به همین دلیل است که در اکثر مصاحبه‌های طراحی سیستم، یکی از مواردی که مورد آزمایش قرار می‌گیرد، توانایی ما برای شفاف‌سازی و پرسیدن آن سؤالات قبل از موعد است. زیرا همانطور که می بینیم، پرسیدن آن سوالات و جمع آوری آن نیازها بخشی از راه حل است و آنچه را که برای طراحی و ساختن نیاز داریم تا حد زیادی محدود می کند.

حال، اگر همه الزامات را درست انجام ندهیم، چه اتفاقی می‌افتد؟ آیا نمی توانیم این کار را به صورت تدریجی انجام دهیم؟ چرا نمی توانیم به سادگی چیزی بسازیم و ببینیم که آیا مشتری را راضی می کند؟ و اگر اینطور نشد، چیز مهمی نیست. ما فقط می توانیم آن را fix کنیم، نمی توانیم؟ بالاخره ما اینجا ساختمان یا پل نمی سازیم. به طور مشابه، هیچ هزینه زیادی برای مواد در نرم افزار وجود ندارد، مانند مهندسی مکانیک، برای مثال، یا ساخت یک ساختمان. خب، جهشی ذهنی که ما باید اینجا انجام دهیم از پروژه‌های کوچکی مانند ساختن یک متد یا چند کلاس که می‌توانیم به راحتی کد را چندین بار بازنویسی کنیم تا زمانی که به درستی برسیم، سیستم‌های مقیاس بزرگ پروژه‌های بزرگی هستند که نمی‌توان آنها را به راحتی یک شبه تغییر داد. این پروژه ها مهندسان و برنامه نویسان زیادی را می گیرند.

طراحی و اجرای این نوع از سیستم ها ممکن است ماه ها طول بکشد، که باعث می شود هزینه زمان مهندسی بسیار قابل توجه باشد. آنها همچنین اغلب نیاز به خرید سخت افزار و گاهی اوقات لایسنس نرم افزار از قبل دارند. و این پروژه ها معمولاً شامل قراردادهایی با تعهدات زمانی و تعهدات مالی هستند. همچنین عدم تحویل به موقع محصول به مشتریان یا کاربران ممکن است صدمات جبران ناپذیری به شهرت و وجهه برند ما وارد کند، بنابراین دریافت الزامات از قبل کاملاً حیاتی است.

بنابراین اکنون که انگیزه لازم برای سیستم مورد نیاز را به دست آوردیم، بیایید یک قدم جلوتر برویم و یاد بگیریم که الزامات را به چند دسته طبقه بندی کنیم که کاملا تأثیرات متفاوتی بر معماری و طراحی ما دارد.

انواع نیازمندی ها

سه نوع اصلی نیازمندی‌ها، ویژگی‌های سیستم هستند که به نام‌های نیازمندی‌های عملکردی، ویژگی‌های کیفیت، که به‌عنوان نیازمندی‌های غیرعملکردی نیز شناخته می‌شوند، و محدودیت‌های سیستم، که اساساً محدودیت‌ها و مرزهای سیستم هستند، شناخته می‌شوند.

ویژگی های عملکردی سیستم

بیایید در مورد اولین نوع الزامات، ویژگی های سیستم صحبت کنیم. این الزامات اساساً رفتار سیستم را توصیف می کنند. به عبارت دیگر، آنچه سیستمی که ما طراحی می کنیم در واقع انجام می دهد. این الزامات به راحتی با هدف سیستم گره خورده است. آنها همچنین الزامات عملکردی نامیده می شوند زیرا اساساً سیستم ما را به عنوان یک تابع black box توصیف می کنند. ورودی یا رویدادهای خارجی کاربر، ورودی های آن تابع هستند و نتیجه یا نتیجه عملیات انجام شده توسط سیستم ما، خروجی آن تابع است.

ذکر این نکته مهم است که ویژگی ها یا الزامات عملکردی به سادگی عملکرد سیستم ما را دیکته می کنند اما معماری آن را تعیین نمی کنند.

و به طور کلی هر معماری می تواند به هر ویژگی دست یابد، این چیزی است که کار ما را به عنوان معمار نرم افزار بسیار دشوار می کند. اکنون، بیایید به چند نمونه از ویژگی ها یا الزامات عملکردی در مثال درخواست خودرو نگاه کنیم. یکی از الزامات کاربردی می تواند به شرح زیر باشد:

هنگامی که یک مسافر به اپلیکیشن ما وارد می شود، اپلیکیشن باید نقشه ای با رانندگان نزدیک در شعاع پنج کیلومتری نمایش دهد. در اینجا ورودی سیستم ما اقدام ورود کاربر است و خروجی نمای نقشه با راننده های نزدیک است.

بیایید مثال دیگری بزنیم.

هنگامی که سفر به اتمام رسید، در صورتی که پرداخت به صورت اعتباری باشد سیستم کارت اعتباری راننده را شارژ و مقداری از آن را هم به عنوان کارمزد سیسم برداشت می کند و در انتها از موجودی کیف پول مسافر کسر می کند و درصورتی که پرداخت به صورت نقدی باشد از کارمزد اپلیکیشن از کیف پول راننده کسر می گردد.

در اینجا اتمام سفر رویداد ورودی است و انتقال پول نتیجه عملیات است.

الزامات غیرعملکردی سیستم

حال بیایید در مورد نیازهای نوع دوم، ویژگی های کیفی یا الزامات غیرعملکردی صحبت کنیم. ویژگی‌های کیفی ویژگی‌هایی هستند که سیستم باید در مقابل آنچه که سیستم باید انجام دهد، داشته باشد. نمونه هایی از این کیفیت ها عبارتند از مقیاس پذیری، در دسترس بودن، قابلیت اطمینان، امنیت، عملکرد، و این لیست بسته به سیستم می تواند ادامه یابد و تغییر کند.

برخلاف الزامات عملکردی، ویژگی های کیفیت معماری نرم افزار سیستم ما را دیکته می کند. راه دیگری برای بررسی این موضوع این است که معماری نرم افزار ویژگی های کیفیت سیستم را تعریف می کند. و معماری های مختلف ویژگی های کیفی متفاوتی را در اختیار ما قرار می دهند. آخرین نوع الزامات، محدودیت های سیستم است. چند مثال شامل ضرب الاجل های دقیق، بودجه محدود، یا تعداد مهندسانی است که می توانند روی پروژه ما کار کنند. چنین محدودیت‌هایی ممکن است ما را مجبور به انجام معاملات و فداکاری‌های خاصی در طراحی‌مان کند و ما را به سمت تصمیم‌های معماری نرم‌افزاری خاصی سوق دهد که اگر آن محدودیت‌ها را نداشتیم، نمی‌گرفتیم. از سه نوع الزاماتی که در این سخنرانی یاد گرفتیم گاهی اوقات به عنوان محرک های معماری نیز یاد می شود. زیرا آنها اساسا تصمیمات معماری ما را از یک جهان نامتناهی از امکانات به سمت یک راه حل هدایت می کنند که نیازهای مشتریان ما را برآورده می کند.