مهندسی سیستم (بخش چهارم)
مقدمه ای بر عناصر سیستم

مهندسی سیستم (بخش چهارم)

مقدمه ای بر عناصر سیستم :


نویسنده: مهندس آرش حسینی


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


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


اهمیت مفهوم عناصر سیستم :


این مفهوم به 3 علت بسیار مهم می باشد :

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

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

·        عناصر سیستم یک نقطه ورود برای تخصیص الزامات مشخصات عملکرد چند لایه می باشد.


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


حل مشکل برای کاهش پیچیدگی :


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



شناخت کلاس عناصر سیستم به کمک دامنه :


کلاس های عناصر دامنه سیستم مورد نظر :

·        افراد

·        امکانات

·        تجهیزات

·        منابع عملیاتی

·        داده رویه ها

·        پاسخ های سیستم


کلاس های عناصر دامنه محیط عملیاتی :

·        نقش ها و ماموریت ها

·        ساختار سازمانی

·        محدودیت های عملیاتی

·        منابع

·        سیستم های دست ساخته

·        محیط طبیعی

·        محیط القا شده


فهم ارتباطات عناصر سیستم :


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


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




ارتباط فیزیکی موجودیت ها :


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



رویکرد معماری منطقی و فیزیکی :


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

·        نیازمندی دامنه راه حل

·        دامنه راه کار عملیاتی

·        دامنه راه کار رفتاری

·        دامنه راه کار فیزیکی



سطح انتزاع سیستم و مفاهیم  آن سطح :


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


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


پایه ریزی یک قاب مفاهیم مرجع :

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





فهم سطح انتزاع در سیستم :


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


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


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


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




نویسنده: مهندس آرش حسینی

رزومه 

مهندسی سیستم (بخش چهارم)
Fatemeh Shakhsian ۱۴۰۲/۰۳/۰۴ ۰۸:۳۶:۳۱
اشتراک گذاری این پست
بایگانی
ورود برای ارائه نظر
مهندسی سیستم (بخش سوم)
چرخه حیات سیستم؛ معماری سسیتم