usecase يحتوي على أكثر من 50 عملية process ؟ هل هذا معقول؟

الشمري كتب:

السلام عليكم ..

لدي مشروع ، قمت بتحليله و وصل الأمر الان إلى أن usecase لوحدها ستحمل أكثر من 50 عملية - process - ..

طبعاً أعرف أن usecase هو high level وتصوّر عام للنظام وتفاعله مع المستخدم .. وبلا بلا بلا .. ولكن الواقع يقول أن أضيف هذا الكم الهائل لأن هذا نظامي الذي نتج ! فمثلاً :

- عملية :ارسال رسالة ،

- عملية :حذف رسالة ،

- عملية :اضافة مجموعة ،

- عملية : بحث عن مجموعة ،

الخ ..

كلها عمليات تظهر للمستخدم النهائي ويتفاعل معها ( كأزرار ) ..

السؤال :

- هل في الأنظمة الكبيرة يحصل هذا الأمر ؟ هل هذا شيء طبيعي ؟

-بعض الزملاء اقترحوا دمج أكثر من عملية في عملية واحدة ، مثلاً : دمج عملية اضافة مجموعة + حذف مجموعة + تحرير مجموعة = ادارة مجموعة ؟ هل هذا صحيح ؟

وعليكم السلام ورحمة الله وبركاته ..

هذا شيء طبيعي جداً .. لا تنزعج.

لقد كنت أقوم بتطوير Framework معين داخل أحد الشركات وأحد أجزاؤه فقط تعدى هذا الرقم بمراحل .. لدرجة أننا قمنا بطباعة الـ Use Cases على حوالي 4 ورقات A3 حتى يمكن إلصاقها على الـ White Board من أجل عمل الفريق. فما بالك بالـ Framework كاملاً .. وما بالك بالنظام الذي سيستعمل الـ Framework.

أيضاً فكرة الدمج جيدة لتقليل العدد ولكن في النهاية قد تحتاج مثلاً Add Message في Use Case أخرى وتستخدم علاقة Include أو Extend مثلاً .. ولهذا عندها ستحتاج إلى هذا التفصيل.

وهذا يرجع إلى حالة مشروعك.

بالمناسبة لقد عزفت منذ زمن عن القيام بمثل هذه الأشكال والـ UML أو على الأقل عزفت عن التقيد بها بشكل رئيس أثناء تطوير البرمجيات بصفة عامة.

جزاك الله خيراً

ممتاز ، جزاك الله خير أخي .. أرحتتني ..

اقتباس

بالمناسبة لقد عزفت منذ زمن عن القيام بمثل هذه الأشكال والـ UML أو على الأقل عزفت عن التقيد بها بشكل رئيس أثناء تطوير البرمجيات بصفة عامة.

لماذا ؟

لو الأمر بيدي كان تجاهلت كل هذه البيروقراطية .. ولكنه مشروع أكاديمي وأنا مجبر على هذا .

اقتباس

لدرجة أننا قمنا بطباعة الـ Use Cases على حوالي 4 ورقات A3 حتى يمكن إلصاقها على الـ White Board من أجل عمل الفريق.

جيد ، لدي سؤال آخر كنت أريد كتابته في موضوع مستقل ، ولكن جاءت الفرصة :-) :

في مشروع أكاديمي ، أريد أن أطبع ER-Diagram و Class Diagram و Use Case Diagram الخ .. ولكن كل واحدة منها يحتاج لأكثر من A4 ، ماذا أفعل في هذه الحالة ؟ هل يجوز أن أقوم بالتالي :

- تقسيم ER-Diagram على أكثر من ورقة ولكن وبسبب وجود Entity مشتركة بين الوورقتين ، ستجدني اكرر نفس Entity مرة أخرى في كل ورقة ، ونفس الامر مع class diagram وبقية الاشكال .

هل يجوز هذا ؟

السؤال الثاني:

- في usecase ، لدي عمليتين :

1- ارسال رسالة Send Msg

2- قراءة رسالة Read Msg .

ولدي شخصيتين 2 actors ،

Manager : يستطيع يقوم بكلا العمليتين .

User : يستطيع يقرأ الرسالة فقط .

السؤال :

عند محاولة رسم العلاقة بين الشخصية والعملية ، هل ارسم شيء كهذا :

الصورة في الأعلى : المدير يتفاعل مع كلا العملتين ؟ هل من الضروري توصيل خط بينه وبين Read ؟ أم استغني عن هذا لأن المدير اذا تفاعل مع Read فهو User .. وبالتالي لاداعي لهذا الخط لوجوده مع User .. أي أنه شيء كهذا :

هنا لم أضع علاقة بين المدير و Read لأني أعتقد أن العلاقة بين Usre و Read تكفي باعتبار أن Manager هو في النهاية User .

الأسئلة كثيرة .. لكنّي متشتت قليلاً :/ .

اقتباس

لماذا ؟

لو الأمر بيدي كان تجاهلت كل هذه البيروقراطية .. ولكنه مشروع أكاديمي وأنا مجبر على هذا .

بما أنك مجبرٌ على هذا .. فإذن لا خيار لديك.

ولكن في حالة أنك تملك الخيار .. فاستخدام الـ UML بصفة عامة له ميزات وعيوب .... سأذكر العيوب فهي أهم في معرض الحديث:

1) الـمزامنة أو Synchronization بين الكود والبرنامج وبين هذه الأشكال .. فلا عجب أنك في وسط البرنامج قد يتغير متطلب ما أو يتغير التصميم بطريقة ما هنا يجب عليك أن تقوم بتحديث كل الأشكال والملفات المتعلقة بهذا التحديث! أنا أسميها Synchronization Hassle! وهذا أخطر عيب! خاصة إن أردت أن يطابق التصميم البرنامج إذا كنت تستخدمه كـ Documentation.

2) الوقت اللازم لبناء هذه الأشكال يستغرق وقتاً لا بأس به حقاً وفي الغالب معظم هذا الوقت لو استغل في كتابة كود سيتم تسليم العميل شيء يفيد عمله أو كما يقولون Delivered Business Value .. وأيضاً الوقت الضائع في عملية الـ Synchronization كما أسلفت.

ومهما كانت مزايا هذه الأشكال فلن تشفع مقابل هذه العيوب بالنسبة لي.

اقتباس

في مشروع أكاديمي ، أريد أن أطبع ER-Diagram و Class Diagram و Use Case Diagram الخ .. ولكن كل واحدة منها يحتاج لأكثر من A4 ، ماذا أفعل في هذه الحالة ؟ هل يجوز أن أقوم بالتالي :

- تقسيم ER-Diagram على أكثر من ورقة ولكن وبسبب وجود Entity مشتركة بين الوورقتين ، ستجدني اكرر نفس Entity مرة أخرى في كل ورقة ، ونفس الامر مع class diagram وبقية الاشكال .

لا يستحب هذا وهذه الطريقة ستكون مشتتة هكذا للمناقشين أو حتى فريق العمل. من الأفضل طباعة هذه الأشكال على أفرخ ورقية ذات مقاس أكبر كـ A3 أو غيرها. أو حتى أفرخ ورقية كبيرة من التي تعلق على الحوائط فهي أفضل. ولكن إن كان يجب عليك استخدام الـ A4 فهذه مشكلة في نظري لأكثر من سبب:

1) لا يمكن أن تعطي الدكتور مثلاً مجلد من 20 - 30 - 100 صفحة عبارة عن Use case .. طبعاً لن يقرأه لأنه غالباً لن يفهم ما الذي يحدث.

2) الوقت اللازم لتنسيق هذه الصفحات حتى لا يحدث تكرار أو سوء تنظيم!

اقتباس

حاول اللجوء للحل الأول أفضل.

- في usecase ، لدي عمليتين :

1- ارسال رسالة Send Msg

2- قراءة رسالة Read Msg .

ولدي شخصيتين 2 actors ،

Manager : يستطيع يقوم بكلا العمليتين .

User : يستطيع يقرأ الرسالة فقط .

الشكل الأول الذي أرسلته أنت أخي الشمري .. لا يوضح العلاقة بين المدير ولا المستخدم كما يؤدي إلى وجود Redundancy وغالباً سيؤدي إلى تصميم خاطيء لأنني كمصمم قد أقوم بعمل Two Classes لا علاقة بينهما وهما الـ User والـ Manager وأكتب في كلا الـ Classes نفس الدالة Read Message وقد يأتي مطور ويطور كل دالة على حدة ويختلف حينها الـ Implementation وستكون غالباً كارثة إن تم تطوير أمور أخرى عليها!

أما الشكل الثاني الذي أرسلته أخي الشمري فلم يبين أصلاً أن المدير يمكنه قراءة الرسائل لأنه لا يوضح العلاقة بين الـ User والـ Manager على الإطلاق.

الشكل الصحيح في المرفقات. وهذا لأن المدير عبارة عن مستخدم ولذا تقوم باستخدام علاقة الـ Generlization ... كما هو موضح بالشكل.

جزاك الله خيراً

السلام عليكم

أخ عبد المنعم أنا دراستي نظري لن في مجال بحثي هو إستخدام UML لعمل description of software architecture و هذه المزامنة ضرورية للحفاظ علىالتوافق بين الكود وsoftware architecture.

لأن دراسة functional and non functional requirements تتم على architecture description يعني عندما لا يكون الكود متزامن معاها ماراح يكون يعبر عنه وكل analysis التي نقوم بها على description ليس لها معنى لأنه تمثل نظام آخر غير الموجود في الكود.

نينا كتب:

السلام عليكم

أخ عبد المنعم أنا دراستي نظري لن في مجال بحثي هو إستخدام UML لعمل description of software architecture و هذه المزامنة ضرورية للحفاظ علىالتوافق بين الكود وsoftware architecture.

لأن دراسة functional and non functional requirements تتم على architecture description يعني عندما لا يكون الكود متزامن معاها ماراح يكون يعبر عنه وكل analysis التي نقوم بها على description ليس لها معنى لأنه تمثل نظام آخر غير الموجود في الكود.

وعليكم السلام ورحمة الله وبركاته أخت نينا

نعم .. ولهذا أنا لا أحب الاستخدام المفرط للـ UML إلا فيما ندر أو فيما وجب الاستخدام فيه حسب الحاجة والمشروع والقيود طبعاً.

جزاكي الله خيراً

أحمد عبد المنعم كتب:

بما أنك مجبرٌ على هذا .. فإذن لا خيار لديك.

ولكن في حالة أنك تملك الخيار .. فاستخدام الـ UML بصفة عامة له ميزات وعيوب .... سأذكر العيوب فهي أهم في معرض الحديث:

1) الـمزامنة أو Synchronization بين الكود والبرنامج وبين هذه الأشكال .. فلا عجب أنك في وسط البرنامج قد يتغير متطلب ما أو يتغير التصميم بطريقة ما هنا يجب عليك أن تقوم بتحديث كل الأشكال والملفات المتعلقة بهذا التحديث! أنا أسميها Synchronization Hassle! وهذا أخطر عيب! خاصة إن أردت أن يطابق التصميم البرنامج إذا كنت تستخدمه كـ Documentation.

2) الوقت اللازم لبناء هذه الأشكال يستغرق وقتاً لا بأس به حقاً وفي الغالب معظم هذا الوقت لو استغل في كتابة كود سيتم تسليم العميل شيء يفيد عمله أو كما يقولون Delivered Business Value .. وأيضاً الوقت الضائع في عملية الـ Synchronization كما أسلفت.

ومهما كانت مزايا هذه الأشكال فلن تشفع مقابل هذه العيوب بالنسبة لي.

لا يستحب هذا وهذه الطريقة ستكون مشتتة هكذا للمناقشين أو حتى فريق العمل. من الأفضل طباعة هذه الأشكال على أفرخ ورقية ذات مقاس أكبر كـ A3 أو غيرها. أو حتى أفرخ ورقية كبيرة من التي تعلق على الحوائط فهي أفضل. ولكن إن كان يجب عليك استخدام الـ A4 فهذه مشكلة في نظري لأكثر من سبب:

1) لا يمكن أن تعطي الدكتور مثلاً مجلد من 20 - 30 - 100 صفحة عبارة عن Use case .. طبعاً لن يقرأه لأنه غالباً لن يفهم ما الذي يحدث.

2) الوقت اللازم لتنسيق هذه الصفحات حتى لا يحدث تكرار أو سوء تنظيم!

الشكل الأول الذي أرسلته أنت أخي الشمري .. لا يوضح العلاقة بين المدير ولا المستخدم كما يؤدي إلى وجود Redundancy وغالباً سيؤدي إلى تصميم خاطيء لأنني كمصمم قد أقوم بعمل Two Classes لا علاقة بينهما وهما الـ User والـ Manager وأكتب في كلا الـ Classes نفس الدالة Read Message وقد يأتي مطور ويطور كل دالة على حدة ويختلف حينها الـ Implementation وستكون غالباً كارثة إن تم تطوير أمور أخرى عليها!

أما الشكل الثاني الذي أرسلته أخي الشمري فلم يبين أصلاً أن المدير يمكنه قراءة الرسائل لأنه لا يوضح العلاقة بين الـ User والـ Manager على الإطلاق.

الشكل الصحيح في المرفقات. وهذا لأن المدير عبارة عن مستخدم ولذا تقوم باستخدام علاقة الـ Generlization ... كما هو موضح بالشكل.

جزاك الله خيراً

السلام عليكم

اخي احمد اريد التنويه وبصراحة اتوقع الرسمة بها شيء اما انا المخطا او انت

اتوقع ان المدير هو موروث من المستخدمين

المدير هو يملك بعض الصلاحيات زيادة عن المستخدم

من وجه اخر

لو اتيت الى بنك كمودع هنا انت فاعل

ولو اتيت له كمقترض هنا انت كذلك فاعل

العلاقة بين الاثنتين علاقة ربط مع فاعل بينهما كما ذكرت علاقة Generlization

ولذلك برايي ان كنت تقصد اخي الشمري ان المستخدم هنا الشخص الذي يعمل على الحاسب برايي

ان تضع اب مجرد لهما وليكن

usergeneral

وتشتق منها فاعلين

الفاعل الاول هو المستخدم user

والفاعل الثاني هو المدير manager

اعذروني اخوتي رسمتي على الرسام وليش عندي لا الفيزو ولا الرايشنوال روز

بكل الاحوال هنالك خطا برسمتي فقط بجهة الاسم لم اعدلها تذكرتها بعد رفع الصورة

اتمنى الرد حتى اعرف ان كان خطا ام صح

أخي XFile

إذا نظرنا للصورة التي أرفقتها .. فستجد أنك قمت بإضافة Actor لا قيمة له في الشكل لأنه لا يقوم بأي وظيفة!

حاول أن تفرق بين الـ Use Case Diagram والـ Class Diagram فلكل منهما فكر وطريقة.

في الشكل الذي أرفقته أنا شرحه كالتالي:

المدير ما هو إلا نوع من أنواع مستخدمي البرنامج ولهذا فهو يقوم بكل وظائف المستخدم بجانب بعض الوظائف الأخرى. ولهذا فأي سهم يخرج من المستخدم إلى أي Use Case يعتبر بالتبعية خارج من الـ Manager دون رسم ذلك في الشكل فهذا بقصد تخفيف الأسهم الكثيرة التي ستظهر في البرامج الكبيرة.

ولكن في الشكل الذي أرفقته أنت .. هناك سهمان مكرران واحد يخرج من المستخدم وواحد من المدير وكلاهما إلى نفس الـ Use Case مما يعطي انطباعاً أن لكل منهما طريقة في استخدام هذه الـ Use Case في حين أن الـ Actor الذي وضعته وهو General User لم يخرج منه سهم واحد وبالتالي فهو يتيم في الشكل ولا فائدة منه على الإطلاق.

جزاك الله خيراً

صحيح انا اخذها اكاديمي بس معدلي بالجامعة في هاي المادة كان 96

صح كلامك بهذه الحالة

طبعا انا عممت الحالة على حالة لو بحالات استخدام كثيرة

ولكن بهذه الحالة وبهذه الرسمة اكيد كلمي غلط

ولكن بكلامك اخي احمد ايضا لا يجوز وجود علاقة تعميم بين المدير والمستخدم لو اخذته بالعكس كان افضل

الفكرة افترض التالي

بنظام امتحانات

الطالب ومدير الموقع لهم نفس امكانية قراءة رسالة المدير يكتبها او تعليق بالصفحة الرئيسية

هن كهذا المثال المدير يكتب ويقرا والطالب يقرا فقط

اما لو اردنا تقديم امتحان وقراءة النتيجة

الطالب يقرا امتحان ويقراء النتيجة

اما المدير يقرا النتيحة وغير قادر تقديم امتحان

يعني انا جاوبت بشكل عام بحيث ما يكون هناك احتمال للخطا في حال اصبح تضارب كما في المثال المرفق اي لا يمكنك الحكم على الحالة بين المدير والمستخدم العادي

علاقة التعميم تحل متل هذا الاشكال

اي حسب الحالة بتمنى تكون فهمت قصدي بس حسب حالتك بتصمم وهاي بتعود للمصمم

والله اعلى واعلم

بالتوفيق وجزاك الله كل خير

مشكورين يا أخوان على هذه المعلومات ،

شخصياً سأختار الـ Generalization ، اقتنعت بها :-) .

بالتوفيق يارب