ما هي فوائد ومخاطر الانتقال إلى نهج الهندسة المعمارية التي تحركها النموذج؟

Question

أنا أعمل في شركة تضم حوالي 350 موظفًا ونحن بصدد النمو. لا يتم تنظيم قاعدة بياناتنا الحالية بشكل جيد للغاية ، ونحن نبحث في كيفية تحسينها على الفور (من خلال تنظيم كائنات في مساحات الأسماء ، وفصل المخاوف ، وما إلى ذلك) والانتقال إلى نهج بنية مدفوعة النموذج ، حيث نضع تصميم كل شيء مع UML وتصميمه أولاً مع UML ، ثم إنشاء رمز من هذا النموذج. لقد بحثنا بشدة في SPARX Systems Enterprise Architect (وهو UML 2.0 قادر) ونفكر أيضًا في الأدوات في VS 2010. أعرف أن هناك أدوات أخرى ( أعتقد أنه يمكننا إنفاق 1500 دولار لكل ترخيص في هذه المرحلة.

أنا لا أبحث عن إجابات حول الأداة الأفضل من آخر ، ولكن المزيد عن التجارب التي تنتقل من بيئة ترميز رعاة البقر (أي التخطيط والتصميم القليل ، فقط القفز والبدء في الترميز) إلى بنية مدفوعة النموذج. إذا نظرنا إلى الوراء هل كان من المفيد لمؤسستك؟ ما هي نقاط الألم؟ ما هي المخاطر؟ ما هي المنافع؟

Answer 1

لا يتم تنظيم قاعدة بياناتنا الحالية بشكل جيد للغاية ، ونحن نبحث عن كيفية تحسينه على الفور [...] والانتقال إلى نهج الهندسة المعمارية التي تعتمد على النموذج ، حيث نقوم بتصميم كل شيء وتصميمه أولاً مع UML ، ثم ننشئ رمزًا من هذا النموذج.

أولاً ، من الرائع أن تدرك أنت وشركتك أن هناك بعض أوجه القصور في عملية تطوير البرمجيات الخاصة بك وأن هناك أ الاستعداد للتحسين.

ومع ذلك ، يبدو أن هناك الكثير من العمل أمامك ، وأشياء كثيرة لتحسينها في اتجاهات مختلفة. نصيحتي الأولى هي عدم محاولة التغيير كل شىء ذات مرة. الناس يترددون بشكل عام في التغييرات ، ويحتاج الجميع إلى بعض الوقت لهضم تغييرات جديدة. من المهم أيضًا إنشاء فهم مشترك حول ما يجب إعداده. لن يتم إنشاء هذا الفهم المشترك في يوم واحد. مثل هذا التغيير يتطلب أ التزام منتصف أو طويل الأجل.

ثم ، فيما يتعلق بـ MDA ، من المهم ملاحظة أنه يتطلب بعضًا انضباط. اعتمادًا على فريقك ، قد يعمل الجزء الأول على ذلك أولاً بطريقة لإعداد الخطوة التالية ، والتي ستكون تقديم MDA. أنا أقول ذلك لأنك تقول أن لديك عملية "رعاة البقر" ، مما يعني أن الناس ربما اعتادوا على فعل كل ما يريدون-إنه أمر لا يوجد في MDA.

ثم يأتي مقدمة MDA نفسها. هناك طريقة مختلفة للقيام MDA (ولن أتوسع حول thsat هنا) ، ولكن الطريقة السائدة للقيام بذلك ، هي ما يسمى الهندسة ذهابا وإيابا. المشكلة الأكبر إذن هي الحفاظ على النموذج والمصدر متزامن.

(رأيي هو أن MDA يؤدي إلى عائد إيجابي على الاستثمار فقط إذا كان من الممكن إعادة استخدام النموذج للعديد من المشاريع. وهذا يعني أنه يجب أن تكون قد حددت الأشياء التي تقوم بها مرارًا وتكرارًا ، ولديك رؤية واضحة كافية حول المشكلة تكون قادرًا على إنشاء نموذج وتحولات كاملة بما فيه الكفاية يمكنك إعادة استخدامها عبر المشروع. لا أعتقد أن MDA يعمل إذا كان كل مشروع مختلفًا تمامًا ؛ الوقت الذي يقضيه في الحصول على النموذج بشكل صحيح والتحول ، وما إلى ذلك سيكون أكبر من العمل فقط مع التعليمات البرمجية والوثائق.)

يتمثل Appraoch آخر في عدم القيام MDA تمامًا - لا تنشئ رمزًا من النموذج - ولكن لزيادة الوعي بالأشخاص حول مشكلة النمذجة والتصميم ، على سبيل المثال مع UML. وبهذه الطريقة ، لن تواجه مشكلة ذهابًا وإيابًا ولكن لا تزال تعمل على تحسين استحقاق عملية تطوير البرمجيات الخاصة بك.

Answer 2

لقد فعلنا ذلك مرة واحدة مع نظام مخطط لوجستيات 3 MLOC ، وقد عمل بشكل جيد. ومع ذلك ، أدركنا في وقت مبكر أن UML لن تكون كافية. كان ببساطة منفرجًا جدًا لالتقاط مستوى التفاصيل اللازمة للمواصفات. كانت أفضل طريقة في الواقع لاستخدام الرمز الزائف (كان الجميع يستخدمونها على أي حال لتوصيل الأفكار)! هكذا تم الإدراك. شعرت UML وكأنها خطوة بعيدا عن الوضوح.

عندما بدأت الأفكار تضيق إلى حل ما ، تم استخدام نظام التحكم في الإصدار من أجل تتبع تغييرات الكود الزائفة (وحالات الاستخدام وما إلى ذلك). لذلك ، اتبع الجميع في المجموعة التغييرات. تمت ترجمة أجزاء بتات إلى البت إلى رمز فعلي إلى جانب الوثائق والمراجع إلى الدوافع والمناقشات.

في النهاية ، كان النقل من طراز إلى رمز سلسًا للغاية. كان الجزء الجميل حقًا ، IMHO ، استخدام VCS الذي سمح لك برؤية رمز الزائفة الأصلي دون تبديل البيئة.

Answer 3

لقد كتبت أطروحة البكالوريوس حول تطوير البرمجيات التي تحركها النموذج وأريد فقط أن أحذرك ، من المهم حقًا استخدام نهج جيد لفعل ما تنوي شركتك. هناك العديد من الأشياء التي قد تسوء ، مثل EG Editing Code Mater مباشرة ، والقدرة على توليد مرة واحدة فقط ، سيتم محو الكود الذي تم تحريره يدويًا بعد الجيل ، يجب عليك القيام ببعض تحليل المجال لإنشاء نموذج ميتا جيد واستخدام جيد إطار توليد الكود ... من فضلك لا تفهمني خطأ ، أعتقد أن MDSD رائع ، ولكن فقط اعتن بنفسك كيف ستفعل ذلك. تشير MDA الأصلية والكتب حولها إلى تطبيقات سيئة للغاية ، وهي مكلفة للغاية وهشة للغاية. أقترح عليك النظر إلى موقع Voelter.de ، حيث يمكنك العثور على أوراق وعروض تقديمية وبيدات من Markus Voelter ، وهو مستشار ذو خبرة كبيرة في هذا المجال.

Answer 4

بالنسبة لي ، الجانب الرئيسي هو أن تكون براغماتية في بعض الأحيان. لا ينبغي أن يكون النمذجة نشاطًا منطقيًا (لا ننظم نموذجًا أو غير نموذج). يجب أن نكون قادرين على تكييف مستوى النمذجة/الدقة مع خصائص المشروع (انظر على سبيل المثال ما يفعله الأشخاص الذين يعملون على النمذجة الرشيقة) والشركة. قد تكون النمذجة القليلة جدًا أو كثيرًا مشكلة (مع القليل جدًا ، قد لا ترى الفوائد ، فقد يكون الكثير من الشركاء ، خاصة إذا كنت تبدأ في الانتقال أو لم يكن لديك الأدوات المطلوبة)

في بوابة/مدونة (مدونتي (http://modeling-languages.com) غالبًا ما نناقش حول فوائد النمذجة أو كيفية استخدام النمذجة. قد تجدها مثيرة للاهتمام