Download
1 / 28
290 likes | 486 Vues
تمرينات در LSS سری سوم. افشين لامعی دانشجوی دکترای نرم افزار 86231905. سؤال: Prototype Design Pattern. از نوع Creational Design Pattern است. نوع Object به وسيله يک نمونه، تعريف و ايجاد Object جديد، Clone میشود.
E N D
تمرينات در LSSسری سوم افشين لامعی دانشجوی دکترای نرم افزار 86231905
سؤال: Prototype Design Pattern • از نوع Creational Design Pattern است. • نوع Object به وسيله يک نمونه، تعريف و ايجاد Object جديد، Clone میشود. • عدم نياز به استفاده از Subclass های Creator مربوطه در برنامه کلاينت. • کم کردن هزينه توليد Object جديد
...سؤال: Prototype Design Pattern • نحوه ايجاد: • ساختن يک کلاس پايه Abstract دارای متد Clone • استقاق کلاس های ديگر از اين کلاس پايه و پياده سازی Clone در آنها • فراخوانی Clone توسط کلاينت، به جای استفاده از new و ايجاد يک کلاس جديد
...سؤال: Prototype Design Pattern • ساختار
سؤال: چک ليستی برای کنترل کیفيت و عملکرد معماری سيستم From http://www.opengroup.org/ • What other applications and/or systems require integration with yours? • Describe the integration level and strategy with each. • How geographically distributed is the user base? • What is the strategic importance of this system to other user communities inside or outside the enterprise? • What computing resources are needed to provide system service to users inside the enterprise? Outside the enterprise and using enterprise computing assets? Outside the enterprise and using their own assets? • How can users outside the native delivery environment access your applications and data? • What is the life expectancy of this application? • Describe the design that accommodates changes in the user base, stored data, and delivery system technology. • What is the size of the user base and their expected performance level? • What performance and stress test techniques do you use? • What is the overall organization of the software and data components? • What is the overall service and system configuration? • How are software and data configured mapped to the service and system configuration?
... سؤال: چک ليستی برای کنترل کیفيت و عملکرد معماری سيستم • What proprietary technology (hardware and software) is needed for this system? • Describe how each and every version of the software can be reproduced and re-deployed over time. • Describe the current user base and how that base is expected to change over the next 3 to 5 years. • Describe the current geographic distribution of the user base and how that base is expected to change over the next 3 to 5 years. • Describe the how many current or future users need to use the application in a mobile capacity or who need to work off-line. • Describe what the application generally does, the major components of the application and the major data flows. • Describe the instrumentation included in the application that allows for the health and performance of the application to be monitored. • Describe the business justification for the system. • Describe the rationale for picking the system development language over other options in terms of initial development cost versus long term maintenance cost. • Describe the systems analysis process that was used to come up with the system architecture and product selection phase of the system architecture. • Who besides the original customer might have a use for or benefit from using this system? • What percentage of the users use the system in browse mode versus update mode? • What is the typical length of requests that are transactional? • Do you need guaranteed data delivery or update, or the system tolerate failure? • What are the up-time requirements of the system? • Describe where the system architecture adheres or does not adhere to standards. • Describe the project planning and analysis approach used on the project.
... سؤال: چک ليستی برای کنترل کیفيت و عملکرد معماری سيستم • بر اساس RUP : • ميزان استقلال پردازش ها از يکديگر • نحوه تبادل پيام ها (همزمانی و غيرهمزمانی) • تعداد Component ها، وابستگی و ميزان پيچيدگی ارتباط آنها • ميزان استفاده از الگوهای طراحی و الگوهای معماری • ميزان استفاده از Package ها
انواع Stakeholder ها و خواسته های آنهامنبع: Software Architecture in Practice (فصل های 9 و 1) • Developing organization’s management • Low cost, keeping people employed. • Marketing • Neat features, short time to market, low cost, parity with competing products • End user • Behavior, performance, Security, Reliability, usability
انواع Stakeholder ها و خواسته های آنها • Maintenance organization • Modifiability, extensibility • Customer • Low cost, timely delivery, not changed very often
سؤال: مسائل مربوط به ريسک • مخاطره يا ريسک عبارت است از احتمال رخدادی که دارای اثر منفی (Impact) بر پروژه نرم افزاری باشد. • ريسک به دو شکل بيان میشود • توصيف شرايط منجر به رخداد خرابی • توصيف خود خرابی • مثال: شرکتی قرار است طی زمان محدودی، برای اولين بار با استفاده از فناوری OO محصولی توليد و به مشتری بدهد. پرسنل کليدی بايد در زمينه OO آموزش ببينند. • ريسک: با توجه به نبود تجربه، ممکن است محصول نيازمندی های کارآيي و کيفيت مورد نظر را برآورده نکند.
... سؤال: مسائل مربوط به ريسک • برخی ريسک ها قابل شناسايي و برخی غيرقابل شناسايي هستند که اطلاعی از احتمال وقوع آنها نداريم. • ريسک ممکن است قابل پيش بينی يا غيرقابل پيش بينی باشد. • برای مقابله با ريسک، روش های کنشی و واکنشی وجود دارد. • برخی ريسک ها غيرقابل کنترل هستند مانند حوادث طبيعی. • Risk Mitigation يا کاهش ريسک، فعاليتی است که پس از شناخت و اوليت بندی Risk Impact ها انجام میدهيم تا اثر مخرب ريسک را بر پروژه کاهش دهيم. • ريسک را میتوان با عدد، درصد يا مقادير کيفی مثل High وlow نشان داد.
... سؤال: مسائل مربوط به ريسک • نقطه ارجاع در منحنی ريسک، نقطه ای است که از آن پس ادامه پروژه به صلاح نمیباشد.
سؤال: مسائل مربوط به تخمينمنبع: Applied Software Project Management, O’Reilly • در مهندسی نرم افزار عبارت است از برآورد هزينه وزمان برای انجام يک پروژه نرم افزاری. • متداول ترين روش های تخمين در مهندسی نرم افزار: • Parametric Estimating • Wideband Delphi • COCOMO • SLIM • SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk. Minimum time and staffing concepts based on Brooks's Law • Function Point Analysis • Proxy-based estimating (PROBE) (from the Personal Software Process) • The Planning Game (from Extreme Programming) • Program Evaluation and Review Technique (PERT) • Analysis Effort method • TruePlanning Software Model Parametric model that estimates the scope, cost, effort and schedule for software projects.
... سؤال: مسائل مربوط به تخمين • مثال: روش COCOMO : • COnstructiveCOst Model • ارائه شده توسط Barry Bohem • استفاده از يک فرمول رگراسيون پايه بر اساس داده های Historical پروژه و مشخصات پروژه فعلی • روش اوليه، هزينه را بر اساس تابعی از سايز برنامه (LoC) تخمين میزند. • قابل اعمال به پروژه های زير: • Organic projects - are relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements. • Semi-detached projects - are intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements. • Embedded projects - are software projects that must be developed within a set of tight hardware, software, and operational constraints.
سؤال: CORBA(مطلب زير برای ارائه در کلاس آماده شده اما فرصت ارائه فراهم نشد) • CORBA مخفف Common Object Request Broker Architecture است. • توسط گروه OMG ارائه شده است. • يک معماری و زيرساخت مستقل از vendor برای ارتباط برنامه ها در محيط های شبکه ای ارائه میکند.
موارد استفاده CORBA • Middleware مناسب در سطح Enterprise ، که به راحتی انواع ماشين ها از Mainframe گرفته تا کامپيوترهای جيبی را يکپارچه میکند. • سرورهايي با تعداد کلاينت زياد، hit rate بالا و نيازمند قابليت اعتماد بالا. • در سيستم های real-time و Embedded-System ها نيز قابل استفاده است.
تعاريف • اشياء، واحد سازنده برنامه ها بوده و بيانگر عملکردها و داده ها هستند. معمولاً (نه هميشه) معادلی در دنيای واقعی دارند. • اشياء معمولاً دارای چندين نمونه هستند، مثل نمونه های مختلف يک کارت اعتباری که متعلق به مشتريان مختلف است. • برای هر نوع شیء، يک رابط با OMG IDL تعريف میشود. کلاينت برای استفاده از عملکردهای شیء، بايد از رابط IDL استفاده کند. جداسازی رابط از پياده سازی، اساس CORBA است که توسط IDL فراهم میشود. • IDL مستقل از زبان های برنامه سازی است اما نگاشت آن به تمام زبان های معروف، توسط OMG ارائه شده است.
... تعاريف • پياده سازی اشياء (کد اجرایی و داده ها) کاملاً از ديد کلاينت ها پنهان است. • دسترسی کلاينت ها به اشياء منحصراً از طريق رابط های ارائه شده، با فراخوانی عملکردهای توصيف شده با IDL و فقط با پارامترهای اجازه داده شده، امکانپذير است.
... تعاريف • نوشتن و کامپايل IDL های مربوطه درون Client Stub و Server Skeleton • Stub و Skeleton در نقش پراکسی برای کلاينت و سرور کار میکنند. • نوشتن اشياء متناظر کلاينت و سرور. • کلاينت و سرور میتوانند به دو زبان مختلف يا در دو ORB مختلف نوشته شوند. • ORB يک واسط جهت فراخوانی های راه دور و ارائه پاسخ دريافتی به کلاينت است.
فراخوانی از راه دور • دريافت اشاره گر به سرور توسط کلاينت. • روش های مختلفی از جمله Naming Service and the Trader Service برای دريافت اشاره گر وجود دارد) • فراخوانی عملکرد مربوطه. • تنها تفاوت با حالت قبل، remote بودن سرور است که توسط ORB تشخيص داده شده و درخواست به سمت شبکه فرستاده میشود. • کلاينت دقيقاً جزئيات عملکرد مورد فراخوانی را میداند (نوع سرور، پارامترهای ورودی و خروجی و ...) • سازگاری ميان ORB ها به وسيله پروتکل IIOP تأمين میشود.
مطالعه بيشتر • CORBA Basics (www.omg.org) • Common Object Request Broker Architecture: Core Specification (http://www.omg.org/technology/documents/corba_spec_catalog.htm) • (CORBA success stories) http://www.corba.org
مسائل موجود در استفاده از Versoion • انتخاب Version صحيح • استفاده از Proxy • استفاده از Bitmap • انتخاب فايل ها برای Load • دسته بندی Version ها بر اساس نوع کامپايلر مربوطه • ناهمگونی فايل های Repository • استفاده از Middle ware برای ذخيره سازی همگون • طبقه بندی فايل ها با استفاده از انديس • وابستگی Version ها • ثبت به عنوان ويژگی هر Version • تنها ذخيره Baseline • استفاده از جدول Lookup
... سؤال: نمودار UML متناظر هر ViewConceptual and analysis viewpoint آزمايشگاه سيستم های هوشمند
... سؤال: نمودار UML متناظر هر ViewLogical design viewpoints آزمايشگاه سيستم های هوشمند
... سؤال: نمودار UML متناظر هر ViewEnvironment/physical viewpoint آزمايشگاه سيستم های هوشمند
