پیشگفتار
در گروه تلگرامی نیازمندیهای نرم افزاری، گفتگوی جالبی انجام شد که بد ندیدم بخشهایی از آن را در اینجا بازگو کنم. از دوستان گرامی، جناب آقای قاقالو و نوذری سپاسگزارم که در این گفتگو مشارکت داشتند.
دوستان عزیزی که علاقهمند به حضور در این گروه هستند، میتوانند به این آدرس مراجعه فرمایند: گروه تلگرامی نیازمندیها
گفتگوی تلگرامی
آقای قاقالو:
حس کردم گروه خیلی سوت و کوره هست گفتم یه بحث کوچیکی تو حوزه تحلیل شروع کنیم. اونم اینکه:
برای تحقق مورد کاربرد در سطح تحلیل چه کارهای باید انجام بدیم؟
من این کارها رو انجام میدم:
۱- یک مورد کاربرد انتخاب میکنم.
۲- سه نوع کلاس سطح تحلیل با کلیشه entity, boundary و control رو پیدا میکنم.
۳- رفتارها و صفات مربوط به هر کلاس سطح تحلیل رو شناسایی میکنم.
۴- روابط بین کلاس های سطح تحلیل رو مشخص میکنم.
نتیجه ۴ گام بالا میشه یک نمودار کلاس با سه نوع کلاس سطح تحلیل که صفات و رفتار هر یک شناسایی شده و روابط بین کلاس های سطح تحلیل نیز مشخص شده است.
نمودار کلاس روابط ساختاری و ایستای کلاس های مربوط به مورد کاربرد را مشخص میکنه.
۵- در این گام در صورت نیاز به مشخص کردن روابط پویایی بین نمونه های کلاس های سطح تحلیل اقدام به آماده کردن نمودار توالی میکنم.
۶- گام های بالا رو برای هر یک از موارد کاربرد تکرار میکنم.
۷- در گام آخر هم نمودار کلاس حاصل از تحقق هر مورد کاربرد را با هم ترکیب میکنم.
نتیجه کارم میشه یک نمودار کلاس سطح تحلیل مربوط به کل نرم افزارم که قرار است توسعه داده بشه
شما چطور عمل میکنید؟
مهرداد:
ضمن تشکر از آقای قاقالوی عزیز، اگر اجازه بفرمایید من هم نظرم را عرض کنم.
با گامهای دو به بعد برای تحلیل گر سیستم موافق نیستم.
اگر اشتباه نکنم در خود آر یو پی، این کار به تحلیلگر سیستم سپرده نشده است.
گام دو به بعد “فضای طراحی و تکنولوژی شی گرایی” دارد که لااقل در ایران تحلیل گران فاقد این مهارت هستند
آقای نوذری:
سلام وقت بخیر. من نظر آقای قاقالو رو قبول دارم. فقط باید به یک مساله مهم توجه کرد. همونطور که ایشون نوشتن، باید دقت شود که فعالیت های 2 به بعد “در سطح تحلیل” انجام شود. با توجه به اینکه تحلیل از نظر انتزاع سطحی بالاتر از طراحی دارد، اگر این دقت نظر انجام شود در فضای “طراحی” نخواهیم افتاد. موضوع یا نگرانی که استاد عزیزم مهندس مهرداد، با عنوان “فضای طراحی و تکنولوژی شی گرایی” اشاره فرمودن نگرانی به جایی هست. ولی مانع از انجام گام های 2 به بعد که جناب قاقالو ذکر کردن نخواهد شد. به نظر من باید نگرانی مهندس مهرداد رو صرفا با عبارت “جلوگیری از افتادن در فضای تکنولوژی” بیان کرد. چون (1) طراح کسی هست که Artifact تحلیلگر رو می گیره و روی اون تکنولوژی سوار می کنه و (2) تحلیل رو با رویکرد شیئ گرایی و در سطح بالایی از انتزاع هم میشه انجام داد.
این مساله مثل طراحی منطقی و فیزیکی دیتابیس می مونه. چیزی که استاد عزیزم مهندس مهرداد فرمودن، مثل این می مونه که بگیم برای طراحی منطقی دیتابیس نیازی به مشخص کردن موجودیت ها یا به بیان من جداول منطقی وجود ندارد، چرا که احتمال ورود به مدلسازی فیزیکی و درگیر شدن مدلساز با مسائل اون بعد خواهد شد.
موضوع یا توضیحی که باید به نوشته آقای قاقالو اضافه بشه این هست که با این مراحل ما داریم System Analysis رو انجام میدیم. ولی اگه بخوایم Business Analysis انجام بدیم اون وقت موضوع متفاوت خواهد بود.
آقای قاقالو:
اگر بخواهیم با دقت بیشتری به موضوع مطرح شده نگاه کنیم میبینیم که در RUP یک فعالیتی با نام use case analysis وجود داره و نقشی که مسول انجام این فعالیت هست Designer می باشد. در این فعالیت تقریبا تمام گام هایی که در بالا ذکر شد انجام میشه اما توسط طراح و نه تحلیلگر سیستم.
اما نکته قابل توجه این هست که تحلیل گر سیستم اگر بتونه دو گام اول رو انجام بده حتی بدون توجه به سه نوع کلاسی که در بالا مطرح شد خیلی موثر خواهد بود و طراح میتونه از خروجی کار تحلیلگر سیستم بهره کافی رو ببره. چون تحلیلگر سیستم درک کامل و خوبی از موارد کاربرد داره. درک و فهمی که طراح نسبت به موارد کاربرد نداره.
اساسا تحقق مورد کاربرد در سطح تحلیل که در فعالیت use case analysis انجام میشه وظیفه طراح هست و نه تحلیلگر سیستم. اما تحلیلگر سیستم میتونه نقش مثبت و موثری در این فعالیت داشته باشه.
در مقابل فعالیت use case analysis فعالیتی دیگر با عنوان use case design وجود داره که که مسئولیت انجام اون با طراح هست و این جایی هست که به طور واقعی حرف از تکنولوژی به میان میاد یعنی به عنوان مثال زبان برنامه نویسی و کیفیت مطرح میشه.
مهرداد:
خوشحال هستم که این گفتگو شکل گرفته است.
اگر اجازه دهید چند نکته را عرض کنم.
1) به نظرم قیاس مدل «تحلیل نرمافزار» بر مبنای «تکنولوژی شیءگرایی» با «مدل منطقی پایگاه داده» ما را به اشتباه خواهد انداخت.
در مدل منطقی پایگاه داده اثری از «رفتار» (behaviour) و «کارکرد» (function) نیست. ما فقط «ساختار» را در مدل مفهومی پایگاه داده داریم.
در مدل تحلیل نرمافزار ما علاوه بر ساختار، کارکرد و رفتار را نیز خواهیم داشت. به عبارت سادهتر، شما علاوه بر شناسایی، کلاسها، صفات کلاسها، روابط ساختاری باید متدهای کلاسها و نحوهی تعامل آنها را برای تحقق سناریوی مد نظر «شناسایی» یا «اختراع» کنید.
اجازه دهید یک مثال ساده عرض کنم. سناریوی ثبت فاکتور که کاربر اطلاعات مشتری و اقلام خریداری شده را وارد میکند و سپس سیستم باید در هر مرحله قیمت هر ردیف از فاکتور و همزمان با آن قیمت کل فاکتور را محاسبه کند و نمایش دهد را در نظر بگیرید.
تحلیل نرمافزار یعنی این که:
– کلاسها، صفات و روابط ساختاری بین کلاسها را پیدا کنید
– تعیین کنید که هر کلاس باید چه متدها و مسئولیتهایی داشته باشد
– تعیین کنید که کلاسها چگونه با یکدیگر تعامل کنند تا سیستم بتواند قیمت ردیف و قیمت کل فاکتور را نشان دهد.
برای نمونه به سوالهای زیر پاسخ دهید
– کلاس فاکتور و قلم فاکتور چه متدهایی دارند؟ (لطفا از ذخیره، ویرایش، حذف، … نام نبرید) چگونه این متدها را پیدا میکنید؟
– قیمت ردیف و قیمت کل فاکتور را کدام کلاس محاسبه کند؟ فاکتور + فاکتور، قلم فاکتور + یک کلاس جدید + …
-این کلاس برای آن که بتواند قیمت کل و قیمت ردیف را حساب کند باید با کدام کلاسها پیغام پسغام کند؟
بیشک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.
از نقش تحلیلگر سیستم چنین انتظاری نمیرود. اگر بخواهیم کمی صادقانه صحبت کنیم، تعداد کمی از برنامهنویسان دارای این مهارت هستند، چه رسد به تحلیلگران.- کلاس فاکتور و قلم فاکتور چه متدهایی دارند؟ (لطفا از ذخیره، ویرایش، حذف، … نام نبرید) چگونه این متدها را پیدا میکنید؟
– قیمت ردیف و قیمت کل فاکتور را کدام کلاس محاسبه کند؟ فاکتور + فاکتور، قلم فاکتور + یک کلاس جدید + …
-این کلاس برای آن که بتواند قیمت کل و قیمت ردیف را حساب کند باید با کدام کلاسها پیغام پسغام کند؟
بیشک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.
از نقش تحلیلگر سیستم چنین انتظاری نمیرود. اگر بخواهیم کمی صادقانه صحبت کنیم، تعداد کمی از برنامهنویسان دارای این مهارت هستند، چه رسد به تحلیلگران.
آقای نوذری:
سلام استاد وقت بخیر. مرسی از وقتی که میگذارید. اینجا واسه من حکم کلاس درس رو داره.
منظور از چیزی که نوشتم مقایسه تحلیل نرم افزار با مدلسازی دیتابیس نبوده. من فقط می خواستم به نوعی این موضوع رو بگم که فعالیت هایی از جنس تحلیل رو میشه پیدا کرد که توی سطحی پایین تر، طراح هم با اونها سر و کله میزنه. به نظر من واسه این که بحث قوام بگیره بیایید از انتها حرکت کنیم تا به ابتدای صحبت برسیم. به این معنا که یه سری از Term ها را روش بحث کنیم. تا بتونیم نهایتا به تعریفی روشن از تحلیل و فعالیت هایی که تحلیلگر باهاشون درگیر هست برسیم. استاد من با فرمایش شما: “بیشک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.
از نقش تحلیلگر سیستم چنین انتظاری نمیرود. اگر بخواهیم کمی صادقانه صحبت کنیم، تعداد کمی از برنامهنویسان دارای این مهارت هستند، چه رسد به تحلیلگران.” کاملا موافقم. ولی به نظر من حتی اگه بخش از چند فعالیتی که شما اسم بردید مثل شناسایی و تعامل کلاس ها(البته در سطح تحلیل) و … به طراح سیستم سپرده شود، در اصل و اساسا بخشی از فعالیت تحلیلگر به او سپرده شده است.
شاید به نوعی بتوان گفت تحلیل سیستم در واقع به نوعی “طراحی اولیه” یا به عبارتی “طراحی در سطح بالایی از انتزاع” می باشد. این مطلب در کتاب زیر به تفصیل آمده است:
Use Case Driven Object Modeling with UML, Theory and Practice. By: Doug Rosenberg and Matt Stephens
این کتاب فصلی با عنوان ROBUSTNESS ANALYSIS دارد. در این بخش از کتاب هدف از ROBUSTNESS ANALYSIS این طور بیان شده است:
To get from use cases to detailed design (and then to code), you need to link your use casesto objects. The technique we describe in this chapter, robustness analysis, helps you to bridgethe gap from analysis to design by doing exactly that. In a nutshell, it’s a way of analyzing youruse case text and identifying a first-guess set of objects for each use case. These are classifiedinto boundary objects, entity objects, and controllers (which are often more like functionsthan objects).
همچنین در ادامه بیان شده است که تحلیل یا تکنیکی که نویسنده از آن با عنوان Robustness Analysis نام برده است برای پر کردن فاصله یا گپی است که بین تحلیل و طراحی وجود دارد:
نویسنده کتاب در ادامه در خصوص شکل فوق و تشریح Robustness Analysis این توضیح را بیان نموده است:
Looking at Figure 5-1, robustness analysis sort of takes place in the murky middle groundbetween analysis and design. If you think of analysis (i.e., the use cases) as the “what” anddesign as the “how,” then robustness analysis is really preliminary design. During this phase,you start making some preliminary assumptions about your design, and you start to thinkabout the technical architecture (also see Chapter 7) and to think through the various possibledesign strategies. So it’s part analysis and part design.
همچنین وی برای مدلسازی و ترسیم نمودارها نیز چنین اصطلاحی را با توضیح زیر بیان می نماید:
… a robustness diagram is an object picture of a use caseAnatomy of a Robustness DiagramA robustness diagram is somewhat of a hybrid between a class diagram and an activity diagram.It’s a pictorial representation of the behavior described by a use case, showing bothparticipating classes and software behavior, although it intentionally avoids showing whichclass is responsible for which bits of behavior. Each class is represented by a graphical stereotypeicon (see Figure 5-2). However, a robustness diagram reads more like an activity diagram(or a flowchart), in the sense that one object “talks to” the next object. This flow of action isrepresented by a line between the two objects that are talking to each other.
There’s a direct 1:1 correlation between the flow of action in the robustness diagram andthe steps described in the use case text.
مهرداد:
پیشنهاد میکنم ابتدا چند عبارت زیر را از هم تفکیک کنیم
تحلیل سیستم
تحلیل نیازمندیها
تحلیل (در ادبیات ما در ایران)
تحلیل نرمافزار
طراحی نرمافزار
آن چه در ایران به نام تحلیل شناخته میشود به «تحلیل نیازمندیها» و به عبارت درستتر «نیازمندیها» نزدیکتر است (requirements)
تحلیل نیازمندیها کاری است که ما از «تحلیلگر سیستم» انتظار داریم.
دقت بفرمایید که «تحلیل نرمافزار» به کلی با «نیازمندیها» متفاوت است. (به پسوند نرمافزار دقت بفرمایید)
تحلیل نرمافزار همان طور که فرموده بودید «پیش طراحی» است. به عبارت سادهتر تکنیکی است برای گذار از نیازمندیها و ورود به طراحی نرمافزار.
روباستنس آنالسس، تکنیکی است در «تحلیل نرمافزار» که به طراح نرمافزار کمک میکند کلاسها، آبجکتها و مکانیزمها و … را شناسایی کند بدون آن که درگیر موضوعات کیفی و تکنولوژی ساخت محصول گردد. همان طور که در شکل به روشنی مشخص است، «تحلیل نرمافزار» قرار است شکاف بین نیازمندیها (در شکل یوزکیسها) به طراحی نرمافزار را پرکند.
همان طور که عرض کردم فکر میکنم که «تحلیل نرمافزار» به مهارتها و دانش طراحی نرمافزار نزدیکتر است تا دانش و مهارت «تحلیلگر سیستم».
البته این فقط یک دستهبندی مفهومی است. ما میتوانیم افرادی را پیدا کنیم که به خوبی از عهدهی همهی این کارها بر آیند. ولی باید بدانیم که «جنس» این کارها با هم متفاوت است.
جمعبندی بنده از فرمایشات حضرتعالی این است که ما برداشتهای یکسانی از واژهها نداریم، وگرنه در باقی قضایا همنظر هستیم.
سپاسگزارم از این که چراغ این خانه را روشن نگه میدارید و امیدوارم که بقیهی دوستان نیز مشارکت بیشتری داشته باشند.
شاد باشید
آقای نوذری:
مرسی استاد از صحبت هاتون. خیلی استفاده کردیم.
با شما و فرمایشتون: “جمعبندی بنده از فرمایشات حضرتعالی این است که ما برداشتهای یکسانی از واژهها نداریم، وگرنه در باقی قضایا همنظر هستیم.” کاملا موافقم. توی پست قبلی هم اشاره کرده بودم. چه قدر قشنگ از لحاظ مفهومی چندتا Term بالا رو از هم تفکیک کردین. اجازه بدین من هم یه موضوع دیگه رو به نقل از پرسمن اشاره کنم. و اون “مهندسی کردن سیستم” قبل از شروع “مهندسی کردن نرم افزار” هست:
Software engineering occurs as a consequence of a process called systemengineering. Instead of concentrating solely on software, system engineeringfocuses on a variety of elements, analyzing, designing, and organizing thoseelements into a system that can be a product, a service, or a technology for thetransformation of information or control.
The system engineering process is called business process engineering whenthe context of the engineering work focuses on a business enterprise. When aproduct (in this context, a product includes everything from a wireless telephoneto an air traffic control system) is to be built, the process is called productengineering…
… Before software can be engineered, the ”system” in which it resides must be understood. To accomplish this, the overall objective of the system must be determined; the role of hardware, software, people, database, procedures, and other system elements must be identified; and operational requirements must be elicited, analyzed, specified, modeled, validated, and managed. These activities are the foundation of system engineering.
به نظر من تحلیل سیستم خودش جزئی از فرآیندی بزرگتر به نام مهندسی سیستم هست.همونطور که جنابعالی اشاره کردین جنس این فعالیت ها با هم متفاوت هست. دوستان اگه پست هایی که قبل از عید در خصوص “تحلیل کسب و کار بر پایه BABOK” توی گروه نوشته بودیم رو ملاحظه کنند، شاید بد نباشه. اونجا من به صورت ضمنی و بعضا صراحتا خیلی سعی کردم خط کشی انجام بدم. و مراتب تحلیل رو نشون بدم. من به شدت به بحث انتزاع در فعالیت های سیستم اعتقاد دارم. و طبعا توی این طیف انتزاعی فعالیت ها با هم متفاوت خواهد بود. دلیل اینکه تعریف مهندسی سیستم رو از کتاب پرسمن آوردم هم نشون دادن این مساله بود.
گزیده:
The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want. Steve McConnell
