بررسی اجمالی مفاهیم معماری سازمانی و استاندارد ISO/IEC/IEEE – ۴۲۰۱۰

/
/
/

مقدمه
کلمه معماري(۱) يادآور يك طرح و ديد همه‌جانبه و كلان بر ساختار و رفتار موجوديتي است كه داراي خواصي چون پيچيدگي و پويائي بوده و تهيه و نگهداشت آن مستلزم داشتن توجه‌ای ويژه به جامعيت ، يكپارچگي ، انعطاف پذيري و تعامل‌پذيري است.
در حوزه مباحث فناوري اطلاعات ابتدا مفهوم معماری در محدوده سخت‌افزار و سپس نرم‌افزار مطرح گردید. زماني كه موضوع استفاده مجدد از قطعات از پيش ساخته شده مورد توجه واقع شد و اين سئوال مطرح گردید که كه با چه تركيب و تلفيقي از عناصر موجود مي‌توان سيستم جديدی را طراحي نمود؟ تجربه ساير رشته‌هاي علوم و مهندسي ثابت كرده است كه هر جا نياز به طراحي موجوديت يا سيستمي‌ باشد كه ابعاد يا پيچيدگي آن از يك حد معيني فراتر رفته ، يا نيازمندي‌هاي خاصي را تحميل نمايد، نگرش ويژه و همه جانبه اي را نيازخواهد داشت كه دراصطلاح به آن معماري گفته مي‌شود.
امروزه معماری نه تنها در سخت‌افزار و نرم‌افزار اهمیت یافته بلکه در مدیریت جنبه‌های مختلف سازمان نیز نیاز به تدوین معماری ضروری شده است. معماري سازماني(۲) شامل مدل‌هاي كسب‌و‌كار، فرآیندها ، داده‌ها ، سيستم‌هاي پشتيباني‌كننده ، شبکه و همچنين زيرساخت‌هاي فناوری براي هر دوي معماري وضع موجود(۳) و وضع مطلوب(۴) است. در یک معماري سازماني استانداردها ، ملاحظات امنيتي و يك طرح انتقال جزء الزامات می باشند.
از ویژگی های معماری سازمانی نقش پررنگ فناوری اطلاعات است و لذا گاهی از آن با عنوان “معماری فناوری اطلاعات سازمانی” نامبرده می شود، همین موضوع نقطه تمایز آن با سایر رویکردهای بهبود سازمانی مانند “مهندسی مجدد فرآیند” یا “طراحی ساختار سازمانی” می‌باشد. از طرف دیگر معماری فناوری اطلاعات سازمانی با رویکردهایی همچون طرح جامع فاوا(۵) و برنامه راهبردی فاوا(۶) هم خانواده بوده و به نوعی دربرگیرنده آنها نیز می‌باشد.
لزوم معماري سازماني را مي‌توان در ظهور سازمان‌هاي بزرگ، نياز به طراحي و توسعه سيستم‌هاي اطلاعاتي پيچيده ، ظهور سيستم‌هاي اطلاعاتي با منظورهاي خاص و اهميت انعطاف پذيري سازمان‌ها در برابر فشارهاي بيروني نظير تغيير كسب و كار ، تغيير مأموريت‌ها و ساختارهاي سازماني و تغييرات سريع فناوري ارزيابي نمود.

(۱) Architecture
(۲) Enterprise Architecture
(۳) As-Is
(۴) To-Be
(۵) ICT Master Plan
(۶) ICT Strategic Plan

همانطوریکه عنوان گردید یکی‌از بهترین راه حل‌هاي توسعه و استفاده بهینه از فناوري اطلاعات در سازمان‌ها، استفاده از معماري سازمانی است.تاثیر معماري سازمانی تا بدانجا است که عدم استفاده از آن در سازمان ها به
منزله ناتوانی سازمان در مدیریت بهینه فناوري اطلاعات محسوب می‌شود. مطمئنا سازمانی که نتواند به صورت بهینه از منابع فناوري اطلاعات خود استفاده کند، نمی تواند جایگاهی را در شرایط رقابتی آینده براي خود تصور نماید.
تاریخچه
در سال ۱۹۸۷ جان زکمن(۱) با چاپ مقاله “چهارچوبی برای معماری سیستم‌های اطلاعاتی” مفهوم معماری سازمانی را پایه‌گذاری نمود. در این مقاله زکمن به چالش و چشم‌انداز معماری‌های سیستم‌های اطلاعاتی اشاره می‌کند. چالش به مدیریت سیستم‌های توزیع شده همراه با پیچیدگی در حال افزایش، مربوط است. زکمن می‌گوید:
“هزینه و موفقیت کسب‌و‌کار، به طور روزافزون به سیستم‌های اطلاعاتی کسب‌و‌کار و رویکردی نظام‌مند برای مدیریت این سیستم‌ها ، بستگی دارد”]۱[
سپس زکمن در سال ۱۹۹۲ میلادی در مقاله ” توسعه و برقراری چهارچوبی برای سیستم های اطلاعاتی معماری” این چشم انداز را مطرح نمود که ارزش و چالاکی کسب و کار می‌تواند بوسیله رویکرد همه‌جانبه برای معماری سیستم‌ها بهتر درک شود. یعنی هر موضوع از هر منظر خاص خودش نگاه شود. رویکردهای چند بُعدی برای معماری سیستم‌هایی که زکمن توضیح می‌دهد ابتدا «چهارچوب معماری سیستم‌های اطلاعاتی» نام گرفت و به سرعت به «چهارچوب معماری سازمانی» تغییر نام یافت. ]۲[
در سال ۱۹۹۲ میلادی وزارت دفاع آمریکا(۲) پروژه‌ تحقیقاتیTAFIM (3)را با هدف تهیه یک طرح جامع برای انسجام و هماهنگی کلیه منابع اطلاعاتی در داخل مجموعه وزارت آغاز نمود. در سال ۱۹۹۴ میلادی این وزارت با انتشار بیانیه‌ای کلیه واحدهای تابعه خود را ملزم به اجرای نتایج TAFIM و انطباق سیستم‌های اطلاعاتی خود با آن نمود.

(۱) John Zachman
(۲) United States Department of Defense (DoD)
(۳) Technical Architecture Framework for Information Management (TAFIM)
از آن تاریخ تاکنون TAFIM همواره در حال بازنگری و اصلاح بوده و در حال حاضر نگارش ۳ آن توسط وزارت دفاع آمریکا مورد استفاده قرار می‌گیرد. این تجربه وزارت دفاع آمریکا ، مورد استقبال سایر وزارتخانه‌ها و موسسات دولتی آمریکا قرار گرفت و روش‌ها و الگوهای بکار رفته در TAFIM در سایر سازمان‌ها نیز به کار گرفته شد. براساس تجربیات بدست آمده از پروژه TAFIM ، در سال ۱۹۹۶ میلادی قانونی بنام کلینگر-کوهن(۱) در کنگره آمریکا به تصویب رسید که بر طبق این قانون و بر پایة نتایج TAFIM ، همه وزارتخانه‌ها و سازمان‌های دولتی آمریکا ملزم به تنظیم معماری فناوری اطلاعات سازمانی خود شدند. همچنین مسئولیت تدوین، اصلاح و اجرای معماری فناوری اطلاعات در هر سازمان برطبق این قانون برعهدة مدیر ارشد فناوری اطلاعات سازمان قرار گرفت.
در سال ۱۹۹۶ میلادی سازمان برنامه و بودجه آمریکا نیز بر لزوم هماهنگی طرح‌ها و هزینه‌های انجام شده توسط موسسات دولتی آمریکا با معماری فناوری اطلاعات سازمان تاکید نمود. پس از آن تاریخ اغلب موسسات دولتی آمریکا از جمله وزارتخانه‌ها، سازمان‌ها، نیروی انتظامی و دانشگاه‌هایی که از بودجه دولتی استفاده می‌کنند، پروژه‌هایی را برای تنظیم و تدوین معماری فناوری اطلاعات خود آغاز نمودند. سپس شورای مدیران ارشد فناوری اطلاعات آمریکا سندی را منتشر ساخت که حاوی چهارچوب معماری سازمانی دولت فدرال بود که سند معماری اطلاعات دولت فدرال محسوب می‌شد و به صورت مستمر در حال بازنگری و اصلاح است.
تجارب كشورهاي پيشگامي همچون كانادا، امريكا، آلمان، انگلستان، استراليا و دانمارك حاكي از اين امر است كه تنها مسيري كه مي تواند سرمايه‌گذاري در بخش فناوري اطلاعات را ساماندهي نمايد تدوين چهارچوبي به منظور ارايه و ارزيابي معماري سازماني در مقياس ملي است. در ادامه فهرستي از چهارچوبهاي تدوين شده در اين كشورها كه عملاً تحت عنوان «چهارچوب تعامل پذيري» نامگذاري شده ارايه می گردد.
۱ – كانادا : در سال ۲۰۰۰ ميلادي چهارچوب (FAP) Federated Architecture Program ارائه گردید.اين چهارچوب يك معماري مشترك در سطوح حرفه، اطلاعات و فني ايجاد نموده كه به ابزاري قدرتمند براي اعمال مديريت تبديل شده است.
۲ – آمريكا : از سال ۱۹۹۶ ميلادي قانوني را تحت عنوان قانون كلينگر – كوهن(۱) به منظور حمايت از معماري اطلاعات ملي در كنگره به تصويب رسانده است.
(۱) Clinger–Cohen Act (CCA)

همچنين چهارچوب FEAF(1) و بسياري از چهارچوبهاي ديگري كه در سازمانها و وزارتخانه‌هاي مختلف امريكا رواج دارد، حاكي از اهميت گسترده موضوع در سطح ملي است.
۳ – آلمان : دولت آلمان در چند سال اخير برنامه SAGA(2) را به عنوان يك چهارچوب معماري حاوي استانداردهاي مشترك براي فناوري اطلاعات تدوين نموده است.
۴ – انگلستان : دولت انگلیس چهارچوب تعامل پذير دولت الكترونيك e-GIF(3) كه كاتالوگي از استانداردهايي است براي تعيين حداقل مجموعه اطلاعات مربوط به مشخصات مورد نياز براي مطابقت با سياست‌هاي فني در سطح پروژه دولت الكترونيك مي‌باشد، تدوين نموده است.
۵ – استراليا : چهارچوب فني تعامل پذيري در دولت استراليا به عنوان بستري كه تامين كننده خدمات از طريق تشريح مجموعه‌اي از سياست‌ها و استانداردهاي توافق شده به منظور به جريان درآمدن اطلاعات در ميان وزارتخانه‌ها و دستگاه قضايي در نظر گرفته شده است.
۶ – دانمارك : تشكيل كميته NEAC(3) به منظور تدوين چهارچوب ملي معماري سازماني در نظر گرفته شده است كه در ادامه به بررسي بيشتر آن خواهيم پرداخت.
وزارت علوم، فناوري و نوآوري دانمارك مقاله‌اي را تحت عنوان معماري سازماني در سال ۲۰۰۳ منتشر نمود كه در آن توصيه‌هاي كليدي به شرح ذيل در خصوص ملزومات نهادينه شدن اين امر آمده است.
• بخش دولتي در سطح كلان لازم است مسئوليت فعال نمودن معماري سازماني را به عهده داشته باشد.
• دولت مي‌بايستي يك چهارچوب معماري سازماني مورد توافق را به منظور برنامه‌ريزي سيستم‌هاي اطلاعاتي با هدف خاص” ايجاد تعامل پذيري” فراهم نمايد.
• تلاش گسترده‌اي به منظور افزايش آگاهي، توسعه دانش و نيز ايجاد صلاحيت‌هايي عمومي با توجه به مفاهيم معماري سازماني ضروري مي‌نمايد.

همچنين در اين گزارش بيان شده است كه يك چنين چهارچوب مشترك معماري سازماني مي‌بايستي داراي عناصر زير باشد.
• هماهنگ كننده‌اي مشترك از طريق ايجاد يك كميته‌ معماري سازماني ملي
• متدولوژيهاي عمومي كه فرآيندها، مفاهيم و نيز استانداردهاي مورد نياز معماري سازماني را بيان نمايد.

(۱) Federal Enterprise Architecture Frameworke
(۲) Standards and Architectures for eGovernment Applications
(۳) E-Government Interoperability Framework
(۴) National Enterprise Architecture Committee

• گزينه‌هاي مشتركي با توجه به استانداردها و زيرساختهاي مورد استفاده براي معماري
• ابزار عمومي براي مثال استفاده از بانكهاي اطلاعاتي مشترك و كتابخانه‌هاي حاوي مدلهاي تعامل، توصيف فرآيندها، تعاريف داده‌اي، عناصر نرم افزاري و الگوهاي زيرساختي
۷ – ایران : فعالیت‌های ابتدایی در ایران شامل فعاليت‌هاي پراكنده‌اي در جهت توجه به امر معماري سازماني در دستگاه‌هاي مختلف می‌باشد كه برخي از آنها به شرح ذيل است.
• وزارت جهاد كشاورزي : از سال ۱۳۷۸ تدوين معماري سازماني به شكل اجراي پروژه Pilot در يك معاونت و از سال ۱۳۸۲ تعميم آن به ستاد وزارت با استفاده از چهارچوب پنج لايه‌اي DOE مطابق استاندارد NIST صورت پذیرفته است.
• وزارت راه و ترابري : سرمايه گذاري گسترده‌اي در جهت آشنايي و بهره برداري از معماري سازماني نموده است. اگر چه چهارچوب DOE مورد شناسايي اين سازمان قرار گرفته است اما فعلاً فاقد يك چارچوب معين در تدوين طرح معماري است.
• وزارت دفاع : چهارچوب C4ISR به عنوان طرح مطالعاتي مورد بررسي قرار گرفته و دوره‌هايي را نيز برگزار نموده‌اند.
• وزارت امور خارجه : چهارچوب Zachman در تدوين طرح كلان وزارت مورد نظر قرار گرفته است.
در ایران معماری سازمانی ابتدا با نام معماری اطلاعات توسط دکتر فریدون شمس و همکارانش مطرح و سپس کمیته فنی معماری اطلاعات ایران را راه‌اندازی گردید. در سال ۱۳۸۵ شمسی برای اولین بار معماری سازمانی در
دوازدهمین کنفرانس بین‌المللی انجمن کامپیوتر ایران به عنوان یک زمینه مستقل ارائه و با تلاش‌های دکتر فریدون شمس ، مجوز ایجاد دوره کارشناسی ارشد معماری سازمانی در دانشگاه شهید بهشتی صادر شد.
با گسترش نیاز موجود در کشور برای فراگیری و به‌کارگیری نظام‌مند رویکرد معماری سازمانی سرانجام با پشتکار وزارت ارتباطات و فناوری اطلاعات ، آزمایشگاه مرجع مدیریت طرح های معماری سازمانی در سازمان فناوری اطلاعات به صورت کامل راه اندازی شد. بخش ستادی این آزمایشگاه در سازمان فناوری اطلاعات ایران مستقر است
و بخش فنی و اجرایی آن از سال ۹۱ در دانشگاه شهید بهشتی راه‌اندازی گردیده است. ماموریت بخش ستادی آزمایشگاه،سیاست گذاری و نظارتی است. در حالیکه ماموریت بخش فنی آزمایشگاه معماری سازمانی که در دانشگاه
شهید بهشتی مستقر است، تدوین اسناد مرجع فنی، ارزیابی طرح های معماری سازمانی و آموزش و فرهنگ سازی است.با تلاش آزمایشگاه معماری سازمانی ، وزارت ارتباطات و فناوری اطلاعات اقدام به تصویب و ابلاغ بخشنامه‌ای خطاب به دستگاه‌های اجرایی کشور نمود که در آن ضمن تشویق دستگاه‌ها، از آنها خواسته شده برای تدوین طرح‌های معماری از ضوابط و شاخص‌های اعلام شده توسط سازمان فناوری اطلاعات پیروی نموده و در صورت دارا بودن طرح معماری سازمانی ، گواهی تاییدیه را از آزمایشگاه فنی معماری سازمانی سرویس‌گرا اخذ نمایند.
استاندارد ISO/IEC/IEEE-42010
استاندارد ISO/IEC/IEEE-42010 بر پایه مفاهیمِ مدل مفهومی شرح توصیفی معماری(۱) ارائه شده است. در این استاندارد برای نمایش مدل مفهومی از نمودار کلاس UML برای نشان دادن کلاس‌های اشخاص و روابط موجود استفاده می‌شود. این استاندارد برپایه استاندارد IEEE 1471-2000 طراحی شده است.
چهارچوب اولیه
استاندارد ISO/IEC/IEEE-42010 در سال ۲۰۱۱ میلادی ارائه و از واژگان و مفاهیم استفاده شده در آن به عنوان زمینه‌ای برای درک مفهوم توصیف معماری استفاده می‌شود.

در اولین چهارچوب ارائه شده این استاندارد ، نمودار ۱ عرضه شده است. در نمودار ۱ شاهد وجود سیستم(۲) ، محیط(۳) ، ذی‌نفعان(۴) ، معماری(۵) و شرح توصیفی معماری(۶) هستیم. در این چهارچوب ، سیستم وجود دارد و در محیط واقع شده است.

(۱) Architectuer Description Conceptual Model
(۲) System
(۳) Environment
(۴) Stakeholders
(۵) Architecture
(۶) Architecture Description

محیط خود می تواند شامل سیستم‌های دیگر باشد. ذی‌نفعان در یک سیستم دارای منافع بوده و این منافع به عنوان اولویت‌ها(۱) شناخته می‌شوند. هدف سیستم یکی از اولویت‌های مهم مورد توجه ذی‌نفعان می‌باشد. سیستم‌ها دارای معماری هستند و شرح توصیفی معماری برای بیان معماری استفاده می‌شود.
در استاندارد ISO/IEC/IEEE-42010 ، سیستم از یک نگاهدارنده نظیر سازمان ، خط تولید ، یک سرویس ، یک زیرسیستم یا نرم‌افزار استفاده می‌نماید. سیستم می تواند طبیعی یا ساخته دست بشر باشد. سیستم در محیط خود ساکن است و با آن دارای تعامل است. محیط تعیین کننده طیف وسیعی از تاثیرات بر سیستم است. محیط در معنای وسیع‌ترین مفهوم در نظر گرفته می‌شود و شامل مفاهیم توسعه(۲) ، عملیات(۳) ، فنی(۴) ، سیاسی(۵) و قانونی(۶) می‌باشد که تمامی این مفاهیم می توانند بر روی معماری اثرگذار باشند. این تاثیرات به عنوان اولویت‌ها یا Concerns شناخته می شوند.
سیستم دارای معماری است. در استاندارد ISO/IEC/IEEE-42010 ، مفاهیم اساسی و مشخصات سیستم بر پایه عناصر ، روابط و اصول طراحی و تکامل در محیط تجسم پیدا می‌کند. شرح توصیفی معماری(۷) یک دستاورد جهت بیان معماری است. معماران و سایر ذی‌نفعان سیستم از شرح توصیفی معماری جهت درک ، آنالیز و مقایسه معماری استفاده می کنند. AD‌ها موضوع اصلی استاندارد ISO/IEC/IEEE-42010 می باشند.

(۱) Concerns
(۲) Developmental
(۳) Operational
(۴) Technical
(۵) Political
(۶) Requlatory
(۷) Architecture Description (AD)
هسته شرح توصیفی معماری(۱)
استاندارد ISO/IEC/IEEE-42010 حول مفاهیم مطرح شده در نمودار ۲ بسط داده شده است.

نمودار ۲ نشان می دهد که محتویات یک AD و روابط بین عناصر ، هنگام اعمال استاندارد جهت تولید شرح توصیفی معماری برای بیان معماری برخی سیستم‌های مورد نظر به چه صورت می‌باشد.
شرح توصیفی معماری ، محصولی کاری برای بیان معماری سیستم مورد نظر است. استاندارد ISO/IEC/IEEE-42010 نیازمندی‌های AD‌ها را مشخص می نماید. یک AD ، توصیف یک معماری احتمالی و امکان‌پذیر برای سیستم است. شکل‌گیری یک AD می تواند به شکل یک سند ، مجموعه‌ای از مدل‌ها ، مدل مخزن(۲) یا حالت‌‌های دیگری که توسط استاندارد تعریف نشده ، باشد. در استاندارد ISO/IEC/IEEE-42010 ، سیستم به عنوان نگهدارنده طیف وسیعی از موضوعات مورد استفاده قرار می گیرد.
(۱) The Core of Architecture Description
(۲) Model Repository
AD می تواند برای یک سیستم ساخته شده توسط انسان متشکل از سخت‌افزار ، نرم‌افزار ، داده ، افراد ، فرآیندها ، امکانات رویه‌ای ، مواد ، موجودیت‌هایی با رخداد طبیعی ، محصولات و سرویس‌های نرم‌افزاری ، برنامه‌های کاربردی انفرادی ، زیر‌سیستم‌ها ، سیستم‌های مبتنی بر سیستم و عناصری که در سازمان بکارگیری می شوند در نظر گرفته شود. AD دارای زبان شرح توصیفی معماری(۱) می‌باشد که می تواند مشتمل بر نمودار جریان داده(۲) ، نمودار کلاس(۳) ، نمودار وضعیت(۴) و سایر مدل‌ها باشد.عناصر دیگری که در این استاندارد مشاهده می‌شود عناصری مانند نقاط دیدگاه معماری(۵)، دیدگاه‌ها(۶) و تناظرات(۷) می باشد. ]۳[
ذی‌نفعان در نمودار ۲ می‌توانند شامل مشتری ، مالک ، کاربر ، مصرف‌کننده ، تهیه‌کننده ، طراح ، نگاهدارنده ، ممیز و صادرکننده گواهینامه معماری باشند. اولویت‌ها نیز می تواند شامل اهداف سیستم ، قابلیت ، ساختار ، رفتار ، هزینه ، قابلیت پشتیبانی ، ایمنی و ایجاد قابلیت همکاری باشد.
در استاندارد ISO/IEC/IEEE-42010 نقاط دیدگاه معماری مشتمل بر دیدگاه روابط تصمیم‌گیری(۸) ، دیدگاه مشارکت ذی نفعان(۹) ، دیدگاه زمانی تصمیم(۱۰) و دیدگاه جزئیات تصمیم(۱۱) می‌باشد. یک دیدگاه می تواند شامل انواع مدل ، نمادها ، روش‌های مدل‌سازی و تکنیک‌های تحلیلی باشد. ]۴[

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

(۱) Architecture Description Language (ADL)
(۲) Data Flow Diagram
(۳) Class Diagram
(۴) State Diagram
(۵) Architecture viewpoint
(۶) Viewpoints
(۷) Correspondences
(۸) Decision Relationship viewpoint
(۹) Stakeholder involvement viewpoint
(۱۰) Decision Chronological viewpoint
(۱۱) Decision Detail viewpoint

فرانکو و باربوسا در مقاله “تحلیل قابلیت اطمینان تکامل معماری نرم‌افزار” که در سال ۲۰۱۳ میلادی در ششمین کنفرانس محاسبات قابل اعتماد ارائه شده ، جهت تبدیل و ترجمه شرح توصیفی سیستم در یک ADL ، فرآیند نمایش داده شده در نمودار ۴ را پیشنهاد نموده‌اند. ]۵[

فرآیند بر اساس رویکرد پیشنهادی فرانکو و باربوسا با پشتیبانی از تفسیرهای ذیل برای ساخت دقیق مدل سیستم می‌باشد:
• مشخصات جریان کنترل سیستم(۱)
• تخصیص استفاده سیستم از مشخصات(۲)
• مشخصات قابلیت اطمینان اجزاء(۳)
مطابق نمودار ۴ ، به عنوان ورودی ، فایل ADL که شامل اجزاء تشکیل دهنده معماری(۴) و مشخصات مورد نیاز می‌باشد دریافت شده و جهت تولید یک مدل احتمالی استفاده می گردد. رویکرد پیشنهاد شده جهت تفکیک محتویات فایل ورودی ADL و ترجمه اقلام تفکیک شده مطابق استاندارد ISO/IEC/IEEE-42010 می‌باشد.
پس از تفکیک شدن فایل ، برنامه کاربردی مورد استفاده ، ترجمه معماری را با ساخت یک مدل احتمالی توسط یک زبان سطح بالای رسمی(۵) تا ایجاد یک فایل PRISM ادامه می‌دهد. در ادامه یک ابزار بررسی کننده مدل PRISM فایل تولید شده را بررسی و گزارش نهایی را ارائه می نماید.

(۱) Specification of the control flow of the system
(۲) Assignment of system usage profile
(۳) Component reliability specification
(۴) Architectural Constituents
(۵) High-Level Formal Language
منابع
۱٫ John Zachman , “A Framework for Information Systems Architecture” , 1987 , IBM Systems Journal, vol. 26, no. 3
۲٫ John Zachman , “Extending and Formalizing the Framework for Information Systems Architecture” , 1992 , IBM Systems Journal, vol. 31, no. 3
۳٫ Yanja Dajsuren, Christine M. Gerpheide, Alexander Serebrenik , “Formalizing Correspondence Rules for Automotive Architecture Views” , Eindhoven University of Technology , The Netherlands
۴٫ Uwe van Heesch , Paris Avgeriou , Rich Hill , “Forces on Architecture Decisions – A Viewpoint” , 2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture
۵٫ Jo˜ao M. Franco, Raul Barbosa, M´ario Zenha-Rela , “Reliability Analysis of Software Architecture Evolution” , University of Coimbra, Portugal , 2013 , Sixth Latin-American Symposium on Dependable Computing

——————————
فرشاد وحیدپور

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text