از کدنویسی تا تفکر سیستمی در نرم افزار

سیستم چیست؟

برای درک فرآیند تفکر سیستمی، ابتدا باید مفهوم سیستم را به خوبی درک کنیم. سیستم چیست و اصولا به چه چیزی میگوییم سیستم؟

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

بنابراین وقتی میگوییم سیستم، معمولا به سه نکته اشاره میکنیم:

• اجرا یا عناصر: هر سیستم از چند جز تشکیل شده است.
• روابط و تعامل ها: این اجزا از طریق قوانین یا فرآیندهای مشخصی با هم در ارتباط هستند.
• هدف یا خروجی: یک سیستم برای دستیابی به یک هدف یا تولید یک خروجی مشخص ایجاد میشود.

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

بنابراین میتوانیم از طریق این نکات وجود یک سیستم را به روشهای زیر تشخیص دهیم:

• وجود چند جز که با هم کار میکنند.
• وجود هدف یا نتیجه مشخص.
• وجود ارتباطات و بازخوردها بین اجزا.
• وجود محدودیت‌ ها و محیطی که سیستم در آن عمل میکند.

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

بعنوان مثال، عملیات ورود کاربران به یک سامانه را برای شما ساده سازی و تشریح میکنم و میبینیم که آیا این عملیات میتواند یک سیستم باشد؟

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

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

تفکر سیستمی

پس از درک مفهوم سیستم، وقت آن است که به موضوع تفکر سیستمی بپردازیم. منظور از تفکر سیستمی چیست و یک برنامه نویس چطور میتواند سیستمی فکر کند و این چه تاثیری در او و عملکرد او ایجاد میکند؟

یک برنامه نویس را (بدون توجه به سطح آن - حرفه ای یا غیر حرفه ای) در نظر بگیرید که درک کاملی از تمام اجزای یک سیستم دارد. اما اگر به شکل بالا که نمونه یک سیستم ساده ی Authentication (احراز هویت) است نگاه کنید، میبینید که خطوطی که تعامل اجرا را با یکدیگر شکل داده اند درنهایت اجزا را به یک دیگر متصل کرده و تشکیل یک سیستم داده اند.

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

حال بیایید همان شکل شماتیک را بدون خطوط متصل کننده اجزا ببینیم:

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

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

مسیر رسیدن به تفکر سیستمی برای یک برنامه نویس چگونه است؟

من یک رودمپ مشخص برای شما ترسیم میکنم. مسیری که خودم رفتم و از نظر من پاسخگو است.

ابتدا باید بتوانید دید معماری و طراحی خودتان را تقویت کنید. بهتر است اول به سراغ مفاهیم معماری ساده و متداولی مثل MVC/MVVC بروید. بعد ذهن خودتان را به سمت معماری های سرویس گرا (SOA)، میکروسرویس ها و Event-driven هدایت کنید. این معماری ها به دلیل وجود کامیونیتی های بسیار منابعی غنی از یادگیری معماری و اصول آنرا به در اختیارتان قرار میدهند.

سپس شروع به تمرین کنید: طراحی سیستمهای کوچک. بعنوان مثال با چند ماژول ساده شروع کنید و سعی کنید قابلیتها و محدودیتهای ناشی از تعامل با سایر ماژول ها مدل کنید.

مدل سازی در نرم‌افزار به فرایند ایجاد نمایش های مبهم یا پیچیدهٔ یک سیستم به صورت ساده و قابل فهم است تا بتوان با آن طراحی، تحلیل و پیاده‌سازی را بهتر انجام داد. مدل‌ها نماینده‌ ای انتزاعی (ساده شده) از بخش‌های مختلف سیستم‌ اند که الزامات، رفتارها و ارتباطات بین اجزا را بیان می‌کنند بدون اینکه به جزئیات پیاده‌سازی ریزه‌کاریهای کد اشاره کنند.

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

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

پیشنهاد میکنم هر هفته یک پروژه یا بخشی از سیستم را به طور هدفمند بررسی کنید. اینکه چخ مشکلاتی دارد؟ رفتارها چگونه است؟ چه بازخوردی از کاربران یا سایر اجزا میگیرید؟

سپس هر دوهفته یک "بازبینی معماری" ساده انجام دهید. آیا شرایط تغییر میکند؟ آیا طراحی پاسخگوی نیازهای آینده است؟

استفاده از نقشه های معماری

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

در این بین من شخصا علاقه خاصی به UML دارم. حتی اگر در ابتدایی ترین قدمهای ورود به عرصه ی طراحی یک سیستم باشید، تنها با رسم چند شئی از UML میتوانید یک سیستم ساده طراحی کنید. اما آنچه باید در UML در تفکر سیستمی به دنبالش باشید، مدلهای ساختاری یا Structure diagrams است. 

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

اما فایده ی ذاتی مدلهای ساختاری UML چیست؟ میتونم به طراحی قابل نگهداری اشاره کنم. شما با مشاهده کلاسها و روابط میتوانید نقاط تکرار، وابستگی های سنگین و نقص ها را در طراحی تان کشف کنید.

همینطور مشخص میشود چه ارتباطی با دیگر ذینفعان غیرفنی پروژه خواهید داشت. مانند مدیرپروژه یا تحلیلگران کسب و کاری.

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

جایگاه تحلیل در تفکر سیستمی

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

تفکر سیستمی به بازخوردهای مثبت و منفی اهمیت میدهد.تحلیل کمک میکند تا بفهمیم چه بازخوردهایی وجود دارد، چگونه موجب پایداری یا ناپایداری میوشند و چگونه تاخیرها میتوانند رفتار سیستم را تغییر دهند. با مدلسازی که در بالا اشاره کردم میتوانید مسیر این بازخوردها را دنبال کنید.

همچنین تحلیل کمک میکند تا لایه های تصمیم گیری و قیود را مشخص کنید و میتوانید ببینید در چه جاهایی تصمیم ها و فشارهای فنی به یکدیگر میرسند. این کار به طراحی راهکارهایی با پایداری بلندمدت و قابلیت ارتقا میکند.

تحلیل قبل از اجرا به تشخیص اثرات جانبی تغییرات در یک جز میپردازد که برای جلوگیری از شکستهای غیرمنتظره در سیستمهای پیچیده حیاتی است. 

در تحلیل میتوانید از سناریوی جادویی what-if پاسخ سیستم به تغییرات را پیشبینی کنید.

سناریوهای what-if، تمرینی است برای بررسی “اگر فلان اتفاق بیفتد چه میشود؟” با هدف درک اثرات احتمالی و انتخاب بهینه، بسیار در تحلیل یک سیستم و واکنش به بازخوردها موثر است.

اما شروع یک تحلیل در کمک به تفکر سیستمی چگونه باید باشد؟ از نظر من همیشه با سوال های کلیدی شروع کنید:

- هدف سیستم چیست؟
- کاربران چه کار میخواهند انجام دهند؟
- چه بازخوردی وجود دارد؟

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

تمرینی برای تفکر سیستمی

امیدوارم تا اینجا مفهوم تفکر سیستمی، اجزای آن و کاربرد آن برای شما روشن باشد. اگر بخواهید میتوانید با تمرین زیر این مسیر را ادامه دهید: طراحی یک سیستم مدیریت موجودی ساده با دیدگاه تفکر سیستمی.

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

گامها:

1. تعیین هدف سیستم

• مثلاً: نگهداری موجودی به‌گونه‌ای که هزینه نگهداری کمین باشد و سطح سرویس مشتری بالا بماند.

2. شمای کلی اجزا (IDEA را در ذهن تمرین کنید)

• Demand (تقاضا)
• Inventory (موجودی)
• Reorder Point/Order Quantity (نقطه بازنشانی و مقدار سفارش)
• Supplier/Lead Time (فروشنده و زمان تحویل)
• Costs (هزینه‌های نگهداری، خرید، کاهش موجودی، تاخیر در تحویل)

3. مشخص کردن بازخوردهای کلیدی

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

4. مدل ساده (زبان ساده یا نمودار کُدی)

• یک مدل مفهومی با سه متغیر:
  • موجودی فعلی (I)
  • تقاضای دوره‌ای (D)
  • سفارش جدید (Q)
• قوانین ساده:
  • اگر I <= reorder_point، سفارش جدید به اندازه (Q) داده می‌شود.
  • هزینه‌ها: نگهداری = نگه‌داشتن موجودی در هر دوره، خرید=قیمت واحد * مقدار سفارش، کمبود = هزینه بابت عدم تامین در صورت کمبود.

5. سناریوهای what-if ساده

• سناریو A: تقاضا افزایش می‌یابد (D ↑)
• سناریو B: زمان تحویل از supplier طولانی‌تر می‌شود (Lead Time ↑)
• سناریو C: قیمت واحد کالا کاهش می‌یابد (قیمت ↓)
  برای هر سناریو: تخمین کنید چگونه I، هزینه‌ها و احتمال کمبود تغییر می‌کند.

6. تحلیل نتایج

• مقایسه سه سناریو با حالت پایه: کدام سناریو کمترین هزینه کل را دارد با حفظ سرویس مناسب؟
• سوالات تفکر سیستمی: آیا تغییر در یک جزء (مثلاً Lead Time) چه اثراتی بر سایر اجزا دارد؟ آیا باید تغییراتی در reorder_point یا Q بدهیم؟

7. مستندسازی و بازخورد

• نتیجه‌گیری مختصر بنویسید: چه بازخوردهایی وجود داشت؟ آیا مدل به اندازه کافی منعکس کننده رفتار سیستم است؟ چه Einschränkungenی دارد؟
• اگر امکان دارد، با تیم یا همکارانتان مرور کنید تا دیدگاه‌های جدید بیایند.

خلاصه پاسخ به سوال شما:

• هدف این تمرین فهم بازخوردها، قیود سیستم و اثرات متقابل تغییرات است.
• با داشتن یک مدل ساده از موجودی و سفارش و اجرای چند سناریو، شما به تجربه عملی تفکر سیستمی می‌رسید.

 

پایان/ چهارشنبه 19 آبانماه 1404

 

محمد مهدوی کیا

بازگشت