درس: مهندسي نيازمندي ها استاد: دكتر عبداله زاده دانشجو: خيرالنسا مرچانت Four Dark Corners Of Requirements Engineering

1. 5 درس: مهندسي نيازمندي ها استاد: دكتر عبداله زاده دانشجو: خيرالنسا مرچانت Four Dark Corners Of Requirements Engineering

2. Four Dark Corners of Requirement Engineering چكيده: • مهندسي نيازمندي ها بدنه بزرگي از دانش را تشكيل مي دهند اما چهار گوشه ضعيف و يا تاريك دارند. • در اين مقاله طبيعت دقت نيازمندها، مشخصه ها ، دامنه دانش و طبيعت دقت و رابطه بين آنها را بيان مي كند و مينيمم استاندارد ها را براي زبان نيازمنديها ارائه مي دهد. • اطلاعات كنترل شده مورد نياز RE و نيز رابطه انجمني بين دامنه دانش و بهبود نيازمندي ها را نشان مي دهد.

3. مقدمه: در RE بدنه دانش شامل terminology, methods, languages, tools, issues acknowledged to critical مي باشند . شرح مسائل و ارائه راه حل ها براي dark corners به قرار زير مي باشد: 1- تمام terminology هاي مورد استفاده در RE بايستي زمينه ساز واقعيت محيطي كه ماشين ميخواهد ساخته شود ، باشد . 2- تمايل يا نيازي به توصيف ساخت ماشين نيست بلكه در مواقعي كهمحيط به دو روش زير توصيف ميشود: • محيطي كه بدون ماشين باشد • محيطي بجاي ماشين باشد اميد واريم باعث ايجاد ماشين شود .

4. 3- با در نظر گرفتن اينكه توصيفات فرمال روي action متمركز اند ضروري است كه مشخص كنيم چه action هايي توسط ماشين و چه actionهايي توسط محيط كنترل ميشوند . 4- نقش اوليه دامنه دانش در RE حمايت از بهبود نيازمندي ها براي پياده سازي مشخصات است. مشخصات درست در رابطه با دامنه دانش معين باعث رضايت نيازمندي ها ميشود . • چهار گوشه تاريك RE بصورت رندم انتخاب نشده اند بلكه آنها با هم توصيف كننده طبيعت دقت نيازمندي ها ، مشخصات ، دامنه دانش و نيز دقت طبيعت رابطه بين آنها هستند و مينيمم استاندارد ها را براي اطلاعات زبان نيازمندي ها ارائه مي دهند و قادر به تكميل مفهوم RE بصورت موفقيت آموزي مي باشند . • هدف اين مقاله شرح دادن طبيعت RE ، نشان دادن اهميت برخي اطلاعاتي كه بصورت ضمني يا غيابي اند و حل برخي مسائل زمينه ساز persistent مي باشد .

5. Grounding Formal Representation - 2 • designation(تعريف) : براي ايجاد معناي premitive term نياز به توليد informal explaination داريم كه اين explaination بايستي شفاف ، مكتوب و از حفاظت بالاي برخوردار باشد . • The difference between assertion & definition: اين تفاوت توسط Branchman ارائه شده است . لازم به ذكر است كه مفهوم designation روي تعريف و تاكيد تاثير بسزايي دارد. • تاكيد:s( student (s) c enrolled ( s, c)) • Designation دانشجو ميتواند withdrawl, metric, graduated باشد. • Designation براي ثبت نام (enrolled) را داريم . تاكيد با نشان دادن رابطه بين دو دنياي واقعي ، آنرا(دنياي واقعي ) را محدود مي كند . اين امر ممكن است دو حالت درست و نادرست داشته باشد و صحت آن قبل از استفاده اثبات ميشود .

6. تعريف :student (s) = c enrolled (s , c) مانع(جلوگيري)designation دانشجو ميشود و جهان واقعي را با formal vocabulary بدون محدويت بسط ميدهد . و ميتواند بي فايده يا misleading باشد اما هيچگاه false نمي شود . تفاوت بين تعريف و تاكيد بخاطر designation است اگر designation مد نظر نباشد آنگاه آندو تفاوت واقعي با هم ندارند . • Goal Regress: بگفته Dardenne 1993:" RE براي رضايت اهداف است“ . اما اهداف را به تنهايي بعنوان نقطه شروع در RE قرار دادن خوب نيست بلكه بايد به عقب برگشت و قدم ها را تك تك برداشت تا اطلاعات بصورت پديده designation قابل درك باشد . مثال turnstile-coin slot-enter zoo • Identity:designation به ما در تعيين معناي همساني كمك مي كند .فرض كنيم مشخصات بافر پيوسته را در temporal logic داريم اين مشخصات شامل محدويتي است اگر message جاري در كانال ورودي قرار گيرد m است و اگر قبلا گرفته باشد m’ است و ايندو همسان نمي باشند.و به قول آقاي Wing اين خواص يك فرضيه محيطي است.

7. Designation خوب براي message term شامل اطلاعات ايجاد message و استفاده آن ميباشد بگونه اي كه: ”روندي كه procedure send –msg را براي انتقال داده به روند ديگر صدا مي زند و message نتيجه صدا زدن send-msg و انتقال داده است .“ بنا براين براي هر call يك send-msg منفرد براي message ايحاد ميشود. اگر اين send-msg شامل قراردادن message ها در بافر دنباله اي باشد message m, m’ حتما منفرد(distinct) خواهد بود . 3- Previous Approaches to the Problem • Wing: براي دوري از explicit internal state محدويت هاي مينيمم روي machine state بصورت تاكيد قرار ميدهيم و به آن property-oriented specification techniques گويند . (مثل تكنيك هاي جبري،axiomatic ....)

8. Liskov & Ziles:Model-oriented Specification techniques را ارائه داد كه در آن system state بصورت چكيده و خيلي خلاصه با ايتفاده از ساختار رياضي مثل مجموعه ها ، روابط و tuples ارائه ميشوند. اما اين تكنيك ريسك بالاي براي اجراي implementation bias دارد . • Jones: Model-oriented state براساس مجموعه state هاي نهفته بنا شده است . Model biased ميشود اگر عناصر مختلف مجموعه state ها غير قابل تشخيص توسط دنباله اي از عمليات باشد . توصيه Jones استفاده از stateهاي unbiased است اما مشكل اينست كه تعريف با توجه به مجموعه عمليات ميباشد . • Lamport: براي حل مشكل implementation bias تمركز روي روابط بين specification , implementation اي كه آنرا satisfy مي كند دارد . • در اينجا ماشين unspecified state S دارد . هر state داراي عناصر Ci كه تابع ميباشد است.

9. Ci: SVi اين رابطه از state به سمت مجموعه مقادير state است. اين specification باياس روي implementation ندارد چون “specification state”بصورتC1(s),C2(s),… Cn (s) است و كاملا با “implementation state” S  s متفاوت است . 3.2 - Requirements Exists only in the enviornment Developerها پيشنهاد دادند كه كامپيوتري ساخته و به محيط جاري وصل شود تا رفتار آن رضايت بخش باشد اما با مشكل ورودي و خروجي روبرو شدند كه پديده اي در محيط است . تفاوت اوليه در RE توسط دو grammatical mood تسخير ميشوند كه عبارنتد از : • Indicative mood: محيطي را توصيف مي كند كه ماشين درش نيست يا بدون توجه به عمليات ماشيني باشد، و به اين حالت عموما assumption (فرضيات) يا دامنه دانش(knowledge domain) گويند . • Optative mood: محيطي كه علاقه و اميد به بودن دارد وقتي كه ماشين به محيط وصل ميشود. Optative mood را عموما requirements يا نيازمندي ها گويند .

10. در اين مبحث (3.2) مشكل پياده سازي باياس را نداريم زيرا هيچ statement اي در باره ماشين پيشنهادي نيست بلكه درباره توصيفات محيط است . بنابراين از طراحي و indicative statement پائيني برخوردار است. مثالي تئوسط Gries & Schneider بصورت منطقي در سال 1993 ارائه شده است كه در آن action به دو صورت فرض شده است 1-atomic 2- sequential. Van Schouwan, Panes &Madey رابطه بين دو مشخصه NAT ,RAQ را اينطور بيان كرده اند: NAT: محدويتي روي مقادير كمي محيطي است كه توسط طبيعت و سيستم هاي install شده پيشين تحميل ميشودو در indicative mood مي باشد . RAQ: محدويتي روي مقادير كمي محيطي است كه توسط ماشين تحميل ميشوند و در Optative mood است.

11. 3.3 - Consequences • بهترين تجربه پيشنهادي اينست كه نيازمندي ها شامل چيزي جز اطلاعات محيطي نباشد. • نتيجه ديگر درباره دامنه دانش است كه اگر specification state را machine state در نظر بگيريم آنگاه مسئله پياده سازي باياس پيش مي آيد كه باعث مينيمم شدن specificationميشود. بنابراين چيزي غير ضروري وابسته به تابع ماشين پيشنهادي نباشد . • تفاوت ديگر در رابطه با designation است كه در آن ماشين پياده سازي شده internal stateاي كه environment state را مينيمم ميكند نگهداري ميشود. 4-Control of Actions در مهندسي نيازمندي ها هميشه با دو فعاليت يا عامل سروكار داريم يكي عامل محيطي و ديگري عامل ماشيني ميباشد . اگر زبان نيازمندي ها يا روش ها براي ارائه واكنش يا كنترل كافي باشد آنگاه به augment(افزايشي) ويا formal language مناسبي دارد .

12. 4.2- Two Necessary Expressive Capabilities • در اينجا چگونگي استفاده از قابليت هاي مهندسي را توصيف مي كند . • زبان نيازمندي ها توصيف مجموعه معين ”action types“ ها را افراز مي كند . • هر action types ميتواندenvironment controlled يا machine controlled باشد بسته به agent اي دارد كه كنترل ، اجرا يا مسئوليت انجام action را دارد. • اگر action گاهي environment controlled و گاهي machine controlled باشد آنگاه تقسيم به دو subtypeميشود . • هر action type ميتواند shared و يا unshared باشد. اگر shared باشد آنگاه بين environment و machine مي باشد . اگر unshared باشد آنگاه به environment اختصاص دارد و به ماشين تعلق ندارد . • بنابراين سه دسته بندي براي action داريم : 1-Environment-controlled / unshared 2-Environment-controlled/shared 3- machine-controlled/shared

13. ملزوماتديگر اينكه محدود كردن سه دسته بندي actionها ست. و مهندسي نيازمندي ها بايد قادر به تاييد دو action ، indicative و optative روشها باشد . مثالBuchi automata توسط Alpern & Schnider 1987 ارائه شده كه شامل pure safety و pure liveness و يا هر دو ويژگي دارا ميباشد. • - پنج action type در gate complex داريم : 1- pay 2- push 3- enter 4- lock 5- unlock (شكل 1)

15. شكل 1

16. مثال بعدي در رابطه با آسانسور(lift) و مراحل آنرا با مثال قبلي مقايسه كرده است و شامل: 1-begin grouping2- end grouping waiting3-motor on4- motor off 5- motor down 6- motor up 7- request light on 8- request light off مي باشد كه جز action type هاي machine controlled هستند . شكل 2

17. شكل 2

18. 4.2- Examples of Control issues : • مشخصه هايA-Z • Formal notion براي كنترل وجود ندارد . • كاربرانZ فرض ميكنند Specification statemachine state Operation state  interface between machine & environment را ميدهد . • Software Cost Reduction توسط Heitmeyer در سال 1995 ارائه شد كه در آن تكيه بر محدويت هاي ماشين و محدود سازي قابليت هايي براي محدويت هاي environment بود( limited Capabilities for constraining the environment)با train & trainXing پياده سازي ميشود. • روشي ديگري بنام CSP توسط Hoare در سال 1985 ارائه شد كه براي كنترل action ها expressive بود .

19. 5- The Role of Domain Knowledge: Domain Knowledge - پلي براي گپ هاي بين requirements و specification است . Requirement هايي كه specificationنيستند بكمك domain knowledge تبديل به specification مي شوند . اگر K را Domain Knowledge فرض كنيم، آنگاهs=specification و K براي ارضاي r=requirement كافيست و داريم : S,K  R 5.1- Environmental constrains • نيازمندي هايي كه داراي environmental constrains به تنهايي براي ارضا machine acting كافي نمي باشند بلكه نياز به دامنه دانش و مشخصات براي satisfy كردن نيازمندي ها دارد . • نياز مندي هايي كه environmental constrains هستند بايستي اول توسط demonstration و يا توسط Specified properties بهمراه domain knowledge اثبات شوند . شكل 3

20. شكل 3

21. 5.2- unshared information: برخي نياز مندي هايي كه مستقيما قابل پياده سازي نباشند را unshared information گويند. unshared information با استفاده از domain knowledge بهبود مي يابند . 5.3- Future reference : برخي نيازمندي هايي كه مستقيما قابل پياده سازي نيستند چون به آينده وابسته اند. مثال liveness requirement از محيط switching كه در ارتباط وابسته به آخرين رقم شماره گيري شده مي باشد (منظور dialing number ). مانند unshared information نيازمندي هاي مراجع آينده بكمك domain knowledge ارضا ميشوند . 6- Four Corners mark a foundation 6.1- Terminology & Applicability -environment: قسمتي از دنياي واقعي متناسب با توسعه پروژه هاي نرم افزاري. -machine: ماشين كامپيوتري كه ساخته ميشود وبا محيط در ارتباط است درنتيجه توسعه پروژه هاي نرم افزاريست.

22. -designation : توصيف informal معناي atomic formal در رابطه با محيط است. • Definition : توصيف صوري atomic formal با استفاده از تعاريف ديگر يا designation terms . • Statement : indicative mood كه توصيفي از محيط است بجاي يا در غايب ماشين است. • Statement : Optative mood كه توصيفي از محيط است در حضور ماشين است • Shared: action در محيطي است كه در آن ماشين شركت دارد . • unshared: action در محيط است كه در آن ماشين شركت ندارد . • environment-controlled: actionاي است كه توسط محيط مقدار دهي اوليه ، اجرا و كنترل ميشود . • machine-controlled: actionاي است توسط ماشين مقدار دهي اوليه ، اجرا و كنترل ميشود وقتي كه با محيط در ارتباط ميباشد.

23. Requirement -: يك optative property است كه نياز هاي مشتري در رابطه با پروژه توسعه نرم افزاري نمايش ميدهد . • A Statement of domain knowledge يا domain assumption: indicative property اي متناسب با توسعه پروژه نرم افرازيست . • Specification: optative property اي كه مستقيما قابل پياده سازي و ارضا كننده نيازمندي ها مي باشد . 6.2- Notation: شامل چهار قانون زير است : 1- هر atomic term بايستي designated يا defined باشد يعني هر جه گفته ميشود در رابطه باenvironment . 2- جدول 2 هر action متناسب با محيط دسته بندي شده را نشان مي دهد . 3- هرگاه نياز به نمايان كردن خواص محيطي باشد ، action هر سه دسته بندي بايستي محدود شوند . 4- هر property يا assertion بايستي بصورت requirement ، statement of domain knowledge يا specification شناسايي شوند .

24. جدول 2

25. 6.3- Completion: با پنج مورد زير RE بطور كامل ارضا((satisfy ميشوند: 1- مجموعه R به ما نيازمندي هاي مشتري را با توجه به پروژه توسعه نرم ا فزاري ميدهد. 2- مجموعه K به ما statements of domain knowledgeرا ميدهد كه براي محيط true است . 3- مجموعه S به ما specification را ميدهد. اعضاي s محيط را محدود نمي كنند و بصورت unshared actions يا state component و refer to future نمي باشند . 4- اثبات S, K Rنشان ميدهد كه پياده سازي S ، R را ارضا ميكند . 5- K،S محدوداند به محيط بنابراين S,K,R با هم محدود ميباشند .

26. Reference • PAMELA ZAVE & MICHAEL JACKSON, “Four Dark Corners of Requirements Engineering”, ACM Transaction on Software Engineering and Methodology, Vol(6), No(1), pp(1-30), Jan 1997.