معمار سخت افزار - ویکی‌پدیا، دانشنامهٔ آزاد

(در محیط‌های اتوماسیون^[۱] و مهندسی^[۲]، مهندس سخت افزار یا معمار رشته‌های مهندسی الکترونیک^[۳] و مهندسی برق^[۴] را با تخصص‌های فرعی در سیستم‌های آنالوگ، دیجیتال یا الکترومکانیکی در بر می‌گیرد)

معمار سیستم‌های سخت افزاری یا معمار سخت افزار مسئول موارد زیر است:

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

زمیته سازی[ویرایش]

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

کاربران و حامیان مالی[ویرایش]

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

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

الزامات سطح بالا[ویرایش]

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

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

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

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

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

تجزیه و تحلیل هزینه و فایده[ویرایش]

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

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

طبقه‌بندی و لایه بندی[ویرایش]

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

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

معمار باید نیازمندی‌های سخت افزاری را به اجزا یا زیرسیستم‌های اصلی که در حیطه یک مهندس سخت افزار واحد، یا مدیر مهندسی یا معمار زیرمجموعه هستند، اختصاص دهد. در حالت ایده‌آل، هر یک از اجزا یا زیر سیستم‌های سخت‌افزاری به‌اندازه کافی یک شی مستقل است که می‌توان آن را به‌عنوان یک جزء کامل، جدا از کل، با استفاده از یک بستر آزمایشی ساده برای تأمین ورودی‌های شبیه‌سازی شده و خروجی‌های ضبط آزمایش کرد؛ یعنی نیازی به دانستن نحوه عملکرد یک سیستم کنترل ترافیک هوایی برای طراحی و ساخت زیرسیستم مدیریت داده برای آن نیست. فقط لازم است که محدودیت‌هایی را بدانیم که انتظار می‌رود زیر سیستم تحت آنها کار کند.

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

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

آزمون پذیرش[ویرایش]

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

ارتباط خوب با کاربران و مهندسان[ویرایش]

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

منابع[ویرایش]