PDA

View Full Version : سوال: مشخص كردن Actor؟



majid325
پنج شنبه 07 آذر 1387, 01:12 صبح
سلام
داشتم بدون تحليل و دور از مباحث oop كار ميكردم.
حالا ميخوام سيستم رو تحليل كنم (به كمك شما عزيزان)
2 الي 3 روز هم مطالب روي وب رو مطالعه كردم
متوجه شدم كه بايد بعد از نياز سنجي به تحليل سيستم بپردازم و حالا شروع كردم به تحليل و اونطور كه متوجه شدم قبل از هر كاري بايد (كلمه بايد رو زياد جدي نگيريد) Actor ها رو مشخص كنم، در تحليل هاي زيادي ديدم كه مثلا متصدي امور ثبت و متصدي امور انبار رو 2 actor ميگيرند،
ولي من تو سيستمم قسمتي هست كه ميشه مشاغل جديد ايجاد كرد و بعد اين مشاغل رو به افراد مختلف نسبت ميدم و هر شغل يك سري دامنه كاري (Use Case ) ثابت داره كه باز هم ممكن هست اين دامنه كاري به وسيله مدير كم و زياد بشه ، حالا با اين توصيف actor هاي من چي يا كي هستن؟ (تقريبا مثلEPolicy در اكتيو دايركتوري)
خودم فكر ميكنم actor هاي من مشاغل باشند :متفکر: كه در اين حال به چه صورت حالت پوياي Use Case رو پياده سازي كنم؟
يا اصلا كارم درست هست يا نه و يا از پايه اشتباه هست؟
با تشكر

اوبالیت به بو
پنج شنبه 07 آذر 1387, 01:53 صبح
باز هم ممكن هست اين دامنه كاري به وسيله مدير كم و زياد بشه
به نظر من كار زياد جالبي نيست. من مخالف Customize كردن سيستم نيستم اما اگر مدير سيستم اشتباه اجازه فعاليت در قسمت هاي حساس سيستم رو به Actor پايين تر بده فاجعه ميشه. چون هر كس بايد در قسمت مربوط به خودش كار كنه.


اصلا كارم درست هست يا نه و يا از پايه اشتباه هست؟

خير. اما اگه بتونيد خودتون Actor ها رو كنترل كنيد خيلي بهتر ميشه. يعني خودتون اجازه فعاليت در قسمت هاي مختلف سيستم رو به كاربراتون بدين. هرچند كه انتخاب با خودتونه.

majid325
پنج شنبه 07 آذر 1387, 02:11 صبح
سلام و تشكر

actor هاي من چي يا كي هستن؟
پس actor من همون مشاغل هستند؟

به نظر من كار زياد جالبي نيست. من مخالف Customize كردن سيستم نيستم اما اگر مدير سيستم اشتباه اجازه فعاليت در قسمت هاي حساس سيستم رو به Actor پايين تر بده فاجعه ميشه. چون هر كس بايد در قسمت مربوط به خودش كار كنه.

خوب دقيقا تو سيستم هاي عامل server به اين صورت عمل ميشه براي دسترسي دادن به user ها .
اگر بخواهيم اشتباه مدير را وسط بكشيم ممكنه كه يه مدير اشتباهي ركوردي با محتواي ارزشمند تري رو delete كنه !

خير. اما اگه بتونيد خودتون Actor ها رو كنترل كنيد خيلي بهتر ميشه. يعني خودتون اجازه فعاليت در قسمت هاي مختلف سيستم رو به كاربراتون بدين. هرچند كه انتخاب با خودتونه.

خوب سيستم به اين صورت هست كه ممكن هست همچين اتفاقي رخ بده.

راستي من رو بجا آوردين( نمايشگاه)

maryam_ch
پنج شنبه 07 آذر 1387, 08:29 صبح
به نظر من اینکه مدير سيستم شاید اشتباه کنه دلیل قانع کننده ای نیست .
و البته با اینکه مشاغل رو بگیرید Actor هم از نظر من صحیح نیست چون ما کسانی رو که به سیستم خدمت می دن و یا از خدمات سیستم استفاده می کنن رو به عنوان Actor می گیریم.اما اگه خود مشاغل رو به عنوان Actor بگیرید چه طور می خواهید فعالیت اونها رو که طبیعتا با هم فرق دارن رو توی usecase, sequence diagram و... نشون بدین؟
این طور که به نظر میرسه actor های شما حالت پویا دارند و اصلا یکی از فعالیت های مدیر ایجاد actor هست من فکر می کنم قضیه به این سادگی ها نباشه اگه اجازه بدین من سوال شما رو با یکی از اساتید در میون بگذارم و ان شاءالله امروز یا فردا جوابتون رو می دم.

اوبالیت به بو
پنج شنبه 07 آذر 1387, 10:19 صبح
اگر بخواهيم اشتباه مدير را وسط بكشيم ممكنه كه يه مدير اشتباهي ركوردي با محتواي ارزشمند تري رو delete كنه !
خوب شما بايد جلوي اين كار رو بگيريد. مدير نبايد اشتباه كنه. حالا اگه شما بگي اين ديگه مشكل من نيست مشكل اونهاست درست نيست. مثل اين مي مونه ما يه هواپيما بسازيم و توش رو پر از بمب كنيم. بعد به خلبان بگيم اگه اين دكمه رو بزني بمب ها فرود مياد. حالا اگه خلبان اون دكمه رو بزنه و يه شهر رو منفجر كنه آيا ميشه گفت كه اين تقصير من نيست مشكل اونهاست؟ شما چرا بمب رو گذاشتي كه بعداً اين حرف زده بشه.

نظر من اینکه مدير سيستم شاید اشتباه کنه دلیل قانع کننده ای نیست
دقياقاً همين هستش. نبايد شما اجازه بديد مدير سيستم اشتباه كنه.

نكته: يه چيزي هستش كه تويه تحليل ها اشتباه در نظر گرفته ميشه اين هستش كه معمولاً اينجوري گفته ميشه كه مدير سيستم همه كاره هستش در صورتيكه اين طوري نيستش. درسته كه Actor ما مدير سيستم هستش اما بازهم نبايد بعضي كارها رو انجام بده. تويه يه سازمان مدير انفورماتيك اون بخش آيا مي تونه به بخش مديريت مالي اون سازمان نفوذ كنه؟
دو تا جواب داره:
بله: بله هست چون مديره(!!) كمي منطقي نيست. شايد تو امور مالي يه چيزي هستش كه فقط مدير كل و مدير مالي دسترسي به اون رو دارن. دليلي وجود نداره چون مديره پس بايد اختيار تام داشته باشه.
خير: كمي كار ما رو پيچيده مي كنه اما آينده پروژه كه معلوم نيست به شكست مي خوره يا نه رو معلوم مي كنه و ديد مارو بازتر مي كنه.

majid325
جمعه 08 آذر 1387, 17:44 عصر
این طور که به نظر میرسه actor های شما حالت پویا دارند و اصلا یکی از فعالیت های مدیر ایجاد actor هست من فکر می کنم قضیه به این سادگی ها نباشه اگه اجازه بدین من سوال شما رو با یکی از اساتید در میون بگذارم و ان شاءالله امروز یا فردا جوابتون رو می دم.

خيلي ممنون ، سوال من رو خوب متوجه شدين.

majid325
جمعه 08 آذر 1387, 17:51 عصر
obalit جون عزيز ، تشكر ميكن كه پيگير موضوع هستيد و من هم چند تا توضيح منطقي براي توضيحات شما داشتم ولي ترجيحاْ ميخوام در مورد سوال اصلي بحث بشه، انشاالله بعد از گزشتن از اين موضوعات در تاپيك جدايي اين مسئله رو با هم برسي ميكنيم.

maryam_ch
جمعه 08 آذر 1387, 18:43 عصر
سلام
می بخشید دیر شد.
حقیقت مطلب اینه که استاد (تجربیات مفیدی در رمینه های مختلف Object oriented دارند)من هم زمان واسه ی فکر کردن می خواست.اینه که هفته ی آینده جوابتونو میدم.
اما در مورد ایرادی که obalit هم ذکر کرده بود به ایشون گفتم و ایشون هم صحبت این دوستمونو رد کرد.
با یک نفر دیگه هم می خوام مشورت کنم .
موفق باشید

اوبالیت به بو
شنبه 09 آذر 1387, 20:23 عصر
اما در مورد ایرادی که obalit هم ذکر کرده بود به ایشون گفتم و ایشون هم صحبت این دوستمونو رد کرد.

یعنی مدیر می تونه هرجا که خواست حرکت کنه؟
هر کاری که خواست می تونه انجام بده؟ اگه اختلاص بشه چی؟
و ...

Elham_gh
یک شنبه 10 آذر 1387, 07:53 صبح
دوست عزيز
نه مشاغل ، نه افرادي كه اين مشاغل را مي گيرندهيچ كدوم Actor سيستم شما نيستند.Actor شما كسي است كه اين مشاغل رو ايجاد مي كنه.
در مورد مدير سيستم-هر سيستمي يك همه كاره داره.كه هر كاري رو مي تونه تو سيستم انجام بده. حتي تو سيستم عامل ها و Application ها هم همين نقشي مثل Administrator يا sa يا ... هست كه قدرت مطلق است.به هر حال هر سرزميني يك خدا مي خواد :) و اين ناقض هيچي نيست.
در مورد دوستمون كه در مورد اختلاص و اينا گفتن بايد بگم كه سيستم بايد مكانيسم log داشته باشه (بسته به حساسيت سيستم log ها جزئي تر مي شن) و اين بايد بتونه سيستم دستكاري ها رو ثبت كنه. معمولا مدير سيستم با مدير سيستم عامل با مدير پايگاه داده متفاوت است كه احتمال پاك كردن رد پا نباشه. اما اگه سيستم مهم باشه و اين 3 نقش يكنفر باشن مقصر متولي سيستم است.

maryam_ch
یک شنبه 10 آذر 1387, 08:29 صبح
با تشکر ار Elham_gh که همیشه جوابای قشنگی داره.
Elham_gh جان میشه خواهش کنم بیشتر توضیح بدین.

Elham_gh
یک شنبه 10 آذر 1387, 08:46 صبح
دوست من maryam_ch ، ممنون از لطفت
اما توضيح بيشتر در مورد Actor ها مي خواي يا مدير سيستم؟

KambizZandi
یک شنبه 10 آذر 1387, 22:32 عصر
Actor ها براساس نوع سيستم تعيين ميشن. اما در حالت کلي به شخصي گفته ميشه که قراره با برنامه کاري رو انجام بده.
مثلا اگر سيستم شما چيزي شبيه اتوماسيون هست بنابراين Actor هاي شما شخص نيستن، بلکه جايگاه سازماني هستن.
مثلا مدير واحد سازماني يا معاون اون واحد يک Actor هست.
حالا اگر سيستم شما بر اساس کارمندان هم بخواد کار کنه اونوقت کارمندان هم به جمع Actor ها اضافه ميشن.
اما در مورد بحث کنترل دسترسي و مدير سيستم بهترين حالت اينه که به اسم "مدير سيستم" يا هر اسم ديگه اي که قراره همه کاره باشه توجه نکنيد. بلکه مجوزهايي که به يک نفر داده ميشه مهمه و از اون مهمتر اينکه کسي که خودش يک مجوزي رو نداره قطعا نميتونه به ديگري هم اين مجوز رو بده.

maryam_ch
دوشنبه 11 آذر 1387, 07:24 صبح
میشه خواهش کنم راجع به اینکه گفتین مدیر سیستم با مدیر پایگاه داده و...متفاوته توضیح بیشتری بدین.
ممنون

Elham_gh
دوشنبه 11 آذر 1387, 13:56 عصر
میشه خواهش کنم راجع به اینکه گفتین مدیر سیستم با مدیر پایگاه داده و...متفاوته توضیح بیشتری بدین.
ممنون

خوب هر برنامه ای Built-in یک admin داره.
مثلا وقتی windows نصب می کنید یک کاربر مدیر داره که به همه چیز دسترسی داره و قابل حذف کردن نیست, به اسم Administrator.وقتی SQL Server نصب می کنید , اون هم یک همچین کاربرBuilt-in ی دارد به نام Sa. و یا برنامه های دیگر به همین ترتیب.خوب مسلما برنامه ای هم که شما می نویسید باید چنین کاربری داشته باشد که قدرت مطلق در حیطه فعالیت خودش است و امکان ایجاد کاربران دیگر و تغییر اجازه های دسترسی آنان را دارد.

نمی دونم توضیحات در همین حد لازم داشتید یا خیر

majid325
دوشنبه 11 آذر 1387, 19:23 عصر
با تشكر از دوستان سعي ميكنم تا يه تحليلي از مطالب بدست بيارم و نتيجه تصميم گيريم رو فردا با شما دوباره مشورت كنم.

Elham_gh
چهارشنبه 13 آذر 1387, 10:01 صبح
میشه خواهش کنم راجع به اینکه گفتین مدیر سیستم با مدیر پایگاه داده و...متفاوته توضیح بیشتری بدین.
ممنون

http://barnamenevis.org/forum/showthread.php?t=133544

maryam_ch
سه شنبه 03 دی 1387, 06:53 صبح
با اینکه میدونم خیلی دیردارم جواب میدم اما به دلایل مختلف دسترسی به استادم رونداشتم اما بلاخره از یکی از اساتید سوالم رو پرسیدم جوابی که دادند این بود:
اصلا" اون فعالیت ها و یا به اصطلاح Actor ها دیگه در محدوده ی کاری ما نیستند(چون runtime دارن به وجود میان و ما در زمان طراحی نمیدونیم که اصلا" چی هستند یا قراره باشند) بنابراین فقط همون مطالبی که در زمان طراحی برامون مطرح هستش رو مدل می کنیم مثلا" اینکه Actor ی به نام مدیر داریم که یکی از usecase هاش تعریف پست جدیده و...
امیدوارم جوابم نوش داروی پس از مرگ سهراب نباشه ولی قضیه برای خودمم جالب بود این بود که گفتم شاید دوستان دیگر هم بخوان جواب قطعی در این خصوص بگیرند.

kablayi
شنبه 14 دی 1387, 18:28 عصر
سلام...
ببخشید که خودمو قاطی میکنم ...
ولی دیدم یه توضیح در مورد actor ها بنویسم بد نیس !!!!!


در کل ما سه نوع actor داریم :



main actor: کاریری که بطور مستقیم از سیستم خدمات میگیره(مشتری) و یا با سیستم کار میکنه (اپراتور)
supporting actor: زیر سیستمی که بطور مستقیم از سیستم خدمات میگیره و یا به سیستم خدمات میده (زیرسیستم پرداخت الکترونیکی)
offstage actor: زیر سیستمی که بطور غیرمستقیم از سیستم خدمات میگیره و یا به سیستم خدمات میده ()(سیستم مالیاتی)

Elham_gh
یک شنبه 15 دی 1387, 11:30 صبح
سلام...
ببخشید که خودمو قاطی میکنم ...
ولی دیدم یه توضیح در مورد actor ها بنویسم بد نیس !!!!!


در کل ما سه نوع actor داریم :



main actor: کاریری که بطور مستقیم از سیستم خدمات میگیره(مشتری) و یا با سیستم کار میکنه (اپراتور)
supporting actor: زیر سیستمی که بطور مستقیم از سیستم خدمات میگیره و یا به سیستم خدمات میده (زیرسیستم پرداخت الکترونیکی)
offstage actor: زیر سیستمی که بطور غیرمستقیم از سیستم خدمات میگیره و یا به سیستم خدمات میده ()(سیستم مالیاتی)


اين تقسيم بندي رو tools خاصي يا كس خاصي انجام داده؟

kablayi
یک شنبه 15 دی 1387, 17:17 عصر
سلام...
این تقسیم بندی رو از کتاب Applying UML and Patterns, Third Edition خونده بودم ...
انتشارات Addison Wesley Professional کتاب جامع و کاملیه مولفش هم Craig Larman هست


پیشنهاد میکنم اگر به مباحث UML علاقمندید این کتابو حتما بخونید ...

به عنوان مثال برای بدست آوردن use case ها و actor ها روابط assosiation و ... یه سری قوانین جامعی برای هر سیستمی که تحلیل میکنید ، آورده که کاربردی هستند ...

نمونش همین تعارفی که برای Actor ها ذکر کرده ...

موفق باشید ....