فصل 8 – Process and Deployment

1. فصل 8 –Process and Deployment به نام خدا فصل 10 Process and Deployment Design برگرفته از کتاب Large-Scale Software Architecture – Jeff Garland, Richard Anthony اسماعیل رضایی آزمايشگاه سيستم هاي هوشمند بهار 87 آزمايشکاه سيستم هاي هوشمند (http://ce.aut.ac.ir/islab) طراحي زيرسيستم ها

2. Process and Deployment Design موضوع کلی :بیان چندviewpoint در رابطه با طراحی و ساخت سیستم های بزرگِ توزیع شده. این مطالب بخشی ویژگی های معماریاز قبیل • Reliability • Fault tolerance • Performance را تحت تاثیر قرار می دهند. سیستم هایی که نیاز دارند این Viewpoint ها در ساخت آنها مد نظر باشد: • Enterprise systems • Telecommunication systems • Web systems

3. Process and Deployment Design viewpoint هایی که در این فصل بحث می شوند : • Physical data • Deployment • Process • سازندگان نرم افزار ها در طراحی ناگزیر به توجه به سخت افزار سیستم هستند. بنابراین توجه به سخت افزار می تواند طراحی و ساختار Component را تحت تاثیر قرار دهد. • برای مثال اگر پردازش توزیع شده باشد و یا متمرکز روی یک ماشین باشد، در performance بسیار متفاوت خواهد بود.

4. Physical data viewpoint • این Viewpoint ارتباط بین سرورها ،مولفه ها(Component) و داده را بیان می کند. • مدیریت فیزیکی داده ها، تاثیر مستقیم بر طراحی و ساخت نرم افزار دارد . • می تواند در تعیین Performance و Availability یک نرم افزار بسیار مؤثر باشد. • بسته به اینکه محل ذخیره داده ها در فایل یا Data object باشد، منطق برنامه برای مدیریت مکان های فیزیکی ذخیره داده ها متفاوت خواهد بود . • اینکه داده ها چگونه ذخیره شده و چگونه مدیریت می شوند، در منطق نرم افزا برای بهینه کردن فضای ذخیره سازی و بالا بردن Performance سیستم در دسترسی به داده ها تعیین کننده است.

5. مثالی از Physical data view • تعدادی از data storage که توسط یک database server مدیریت می شوند. • در هر data storage ، مکانیزم ذخیره سازی با یک stereotype مشخص شده است. Figure 10-1: Physical Data View

6. مدل کردن ویژگی های دیگر ذخیره سازی • در این مدل علاوه براینکه نیاز داریم بدانیم چه database هایی توسط یک سرور کنترل می شوند، نیازداریم که پارامترهای اصلی ای که بر Performance سرور تاثیر دارند، بدانیم. پارامترها : • Transaction rate • Growth rate • Archive policy روش های نمایش پارامتر ها : • بیان مستقیم روی مدل • استفاده از یک جدول جانبی

7. مدل کردن ویژگی های دیگر ذخیره سازی بیان مستقیم ویژگی ها روی مدل

8. مدل کردن ویژگی های دیگر ذخیره سازی استفاده از یک جدول کمکی Table 10.2 Physical data storage attributes

9. مدل کردن ویژگی های دیگر ذخیره سازی • Transaction rate و growth rate مهمترین تعیین کننده های performance یک سرور هستند. • ویژگی های Growth rate و Archive policy نیاز سیستم برای منابع ذخیره سازی را تعیین می کنند. • سیستم های با نرخ بالا،برای داشتن کارایی مناسب نیازمند دقت زیاد در طراحی هستند.در مواردی ممکن است نیاز به توزیع کردن باشد، که چگونه توزیع کردن طراحی را تحت تاثیر قرار می دهد. • Transaction rate تعیین کننده اندازه سرور خواهد بود. • پایگاه داده های با نرخ بالای transaction ممکن است، نیازمند سخت افزار ویژه بوده و یا نیاز به توزیع شدن روی چند سرور داشته باشند. • در مواردی ممکن است، چند پایگاه داده با transaction rateپایین ترکیب شده و از یک سرور برای آنها استفاده شود

10. مدل کردن جزئیتر Physical storage • در سیستم های بزرگ از چندین تکنولوژی ذخیره سازی استفاده می شود. • بدلیل بزرگ بودن مسئله امکان استفاده سلسله مراتبی از پایگاه داده وجود دارد. مدیریت این ساختار سلسله مراتبی • توسط DBMS • توسط Application • استفاده از Locking در مدیریت ساختارسلسله مراتبی • سازماندهی فیزیکی درست ،طراحی منطقی را تحت تاثیر قرار می دهد.

11. یک مثال از مدل کردن جزئی Physical storage ساختار سلسله مراتبی ساخته شده از Database ها و Container ها بسیاری از OODB ها دارای ساختار سلسله مراتبی هستندکه باید مستقیما توسط App کنترل شوند. Figure 10-3: Detailed Storage Hierarchies

12. Physical data viewpoint Table 10-1 Physical Data Viewpoint

13. Process Viewpoint طراحی سیستم های توزیع شده، به دلیل intercommunication process issues ها ،پیچیده است. از جمله این issue ها : • تعداد دفعات ایجاد و از بین بردن Process ها • Process failure and recovery • failure و recover کردن ارتباطات بین مولفه ها در داخل یک process . طراحی صحیح Process ها و ارتباطات آنها تاثیر مستقیم در reliability و fault tolerance سیستم است. اجتناب از process های co-dependent : روش تشخیص co-dependency : • وجود حلقه در process view ، میتواند منجر به co-dependency در زمان اجرا شود. راه حل در صورت وجود: • ترکیب کردن و بوجود آوردن یک process • ایجاد یک process دیگر که co-dependent functionality را انجام دهد.

14. یک مثال از Process Viewpoint

15. جزئیات Process Viewpoint • این view در بردارنده Process ها و ارتباطات بین آنها است. • هر Process نام منحصر به فرد دارد. • خطوط بین Process ها نمایش دهنده ارتباط بین آنها است .(originator , receiver) • با یک tag روی هر process ، مشخص می شود که persistent و یا transient است. Persistent : process هایی که برای دریافت درخواست کاربران و پاسخگویی منتظر هستند. از قبیل info server که همیشه در حال اجرا است و منتظر درخواست کاربر. Transient : Client process هایی که توسط یک کاربر و یا توسط process management در داخل سیستم start می شوند. Process های کلیدی در این process view : • info server • database server بدین دلیل که دیگر process ها برای رسیدن به داده های کاربران به آنها نیاز دارند. مشکل : • info server تنها process است که باید ترافیک از تمام سیستم های خارجی را تحمل کند. • Info server به دلیل عدم replication یک single point of failure است .

16. Process Viewpoint استفاده از Process view برای reengineering ،سیستم هایی که documentation ضعیفی دارند: • تحلیل سیستم موجود به صورت مجموعه ای از process ها • ساخت یک مدل اولیه از process ها و ارتباطات آنها • استخراج functionality ها و توزیع شدگی سیستم موجود از مدل Process View و View های دیگر : process view با component view و deployment view همپوشانی دارد. • با ایجاد deployment view نیازی به ایجاد process view نیست. • زمانی که ضرورت بیان جزئیات گره های فیزیکی نباشد، ازprocess view استفاده می شود. • هر گاه تناظر یک به یک بین component ها و process ها وجود داشته باشد، Process view و Component View معادل هستند.

17. Process ها و Component ها اضافه کردن component ها به process ها • اضافه کردن component ها به process ها می تواند اطلاعات با ارزشی را به آن بیفزاید . • با این کار، هدف هر یک از process ها و وبویژه آنهایی که چند مولفه دارند، روشن تر می شود. نحوه اضافه کردن : • نمایش component های هر process، داخل آن. • نامگذاری component ها و برداشتن نام process ها . • نمایش ارتباطات بین component ها با خطوط • نمایش interface هایی که در ارتباط بین component ها استفاده می شوند.

18. Process ها و Component ها Figure 10-5: Process View with Components

19. مدیریت Process و Component استفاده از Component Framework ها برای ساخت Application ها • فراهم نمودن ابزار استاندارد برای آسان کردن مدیریت Component ها. ابزار هایی که Framework فراهم می کند • ابزاری برای اجرای آسان Component ها • Monitoring • Check pointing • Log کردن فعالیت های برنامه اجزای اصلی یک Component Framework • مولفه Process Management • مولفه Component Management

20. مولفه Process Management برای هر Process یک مولفه Process Management وجود دارد و اعمال زیر را انجام می دهد: • پیکر بندی منابع برای Process مربوطه • Load کردن، اجرا ،پیکربندی و مقدار دهی اولیه برای هر یک از Component های آن Process . • فراهم کردن یک Interface برای کنترل status ها،alarm ها، نمایش performance سیستم، انجام تغییرات در پیکربندی و داشتن دستورات ساده برای مدیرت سیستم. برای هر Component یک مولفه Component Management وجود دارد که تعاملات مربوط به آن مولفه را مدیریت می کند. و اعمال زیر را انجام می دهد: • Load کردن،پیکربندی، مقدار دهی اولیه،start ، stop آن Component. • پاسخ دادن به دستورات مولفه Process Management . • فرهم کردن status ، آمار ها و alarm ها برای Process Management .

21. Process and component management framework Figure 10-6: Process and Component Management Framework

22. Deployment Viewpoint Node چیست ؟ • یک عنصر سخت افزاری که قابلیت اجرای component ها در process ها و thread ها را دارد. Deployment viewpoint چیست ؟ • در این view نگاشت بین process ها )و یا component ها( و سخت افزار توصیف می شود. • این view با اضافه کردن node ها به process view یا component view ساخته می شود. • برای تولید deployment view ابتدا باید process view و component view را تهیه کرد. • در صورتیکه جایگاه هر یک از process ها در سخت افزار سیستم مشخص باشد، داشتن این view برای توصیف سیستم ضرورت ندارد. • در ایجاد یک سیستم پس از اینکه component های سیستم تعریف شدند، برای تصمیم گیری در خرید سخت افزار سیستم می توان از آن استفاده کرد. • در صورتیکه در این view تنها process ها استفاده شوند، مسیر ارتباط بین process ها را رسم می کنیم . • در صورتیکه هم از process ها و هم از component ها استفاده شود، ارتباطات comp-to-comp را رسم می کنیم.

23. Deployment Viewpoint with process Figure 10-10: Deployment View with Annotated Nodes

24. Figure 10-10: Deployment View with Annotated Nodes

25. طراحی Scalable node Scalable Node چیست ؟ • عناصری که به عنوان یک نقطه مقیاس پذیری در معماری سیستم مطرح هستند. Deployment viewpoint می تواند برای مدل کردن Scalable node ها به کار رود. • در این view ، data و process باید به نحوی طراحی شوند که امکان رویارویی سیستم با ، بارمحاسباتی و داده ای متفاوت و همچنین رویارویی با fault را فراهم کنند. • این عناصر باید امکان Load balancing و Fault tolerance را برای سیستم فراهم کنند. • با فراهم نمودن log file ها و ثبت آنچه در سیستم اتفاق می افتد امکان recovery در زمان وقوع failure فراهم می شود. • ملاحظاتی از قبیل تعداد عناصر برای Fault tolerance بودن سیستم، باید بیان شوند.

26. طراحی Scalable node Figure 10-12: Scalable Server Design

27. طراحی Backup و Archive در بسیاری از سیستم های بزرگ برای نمایش راه حل استفاده شده برای backup و archive از deployment view استفاده می شود؟ Backup data : • یک کپی از داده های در حال تغییر ، که تنها در صورت وقوع failure در سسیستم مورد استفاده قرار می گیرد. Archive data : • یک کپی همیشگی از داده هایی که محتوای آنها دیگر تغییر نخواهند کرد. این کپی برای مراجعات تاریخی و بررسی سابقه داده ها مورد استفاده خواهد بود. روش هایی که برای backup مورد نظر هستند: • استفاده از log file برای ثبت تغییرات • انتقال periodic داده ها به backup server . روش هایی که برای archive مورد نظر هستند: • استفاده از ابزار های اماده برای ذخیره archive data • نوشتن کد برنامه توسط سازندگان سیستم برای انتخاب و انتقال داده ها به محل ذخیره سازی

28. Tools • Microsoft visio 2003 • Power Designer 12.5

29. منابع Main resource: Large-Scale Software Architecture, Jeff Garland, Richard Anthony,2002 Further reading UML User Guide,Booch,1999.

30. با تشکر