‫تمرينات در ‪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 :‫سؤال‬...
‫• ساختار‬
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 ‫انواع‬
)1 ‫ و‬9 ‫ (فصل های‬Software Architecture in Practice :‫منبع‬
• 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 ‫ روش‬:‫مثال‬
•
COnstructive COst 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‬‬
View ‫ متناظر هر‬UML ‫ نمودار‬:‫ سؤال‬...
Conceptual and analysis viewpoint
Viewpoint
UML diagram
Description
Analysis focused
Class
Describe system entities in
response to a scenario.
Often refer to as a view of
participating classes or VOPC
Analysis interaction
interaction
Interaction diagram between
objects for analysis
Analysis overall
Class
Combination of all classes
from all focused analysis
viewpoints
Context
Use case
Show the external system
actors and the system under
design
‫آزمايشگاه سيستم های هوشمند‬
26
View ‫ متناظر هر‬UML ‫ نمودار‬:‫ سؤال‬...
Logical design viewpoints
Viewpoint
UML diagram
Description
Component
Component
Component communications
Component interaction
Interaction
Interactions among components
Component state
State/activity
State transition/activity diagram
for a component or for a set of
components
Layered subsystem
Packages
Layering and subsystem design
Logical data
Classes
Critical data views used for
integration
Subsystem interface
dependency
Class
‫آزمايشگاه سيستم های هوشمند‬
Subsystem dependencies and
interfaces
27
View ‫ متناظر هر‬UML ‫ نمودار‬:‫ سؤال‬...
Environment/physical viewpoint
Viewpoint
UML diagram
Description
Deployment
Deployment
Mapping of software to
hardware for distributed
systems
Physical data
Deployment
Physical view of a
particular database
Process
Deployment
Show the processes of a
particular system instance
Process state
State
Show the dynamic states
of a process
‫آزمايشگاه سيستم های هوشمند‬
28