Каковы наиболее практичные методы объектно-ориентированного моделирования программного обеспечения в реальных проектах? - PullRequest
5 голосов
/ 03 июня 2010

Я хочу разработать большой проект, но я действительно не знаю, как лучше всего моделировать мой проект. Нужно ли мне даже моделировать мой проект? Каковы наиболее практичные методы моделирования программного обеспечения ООП в реальных проектах? Какие самые лучшие и самые полезные?

Ответы [ 4 ]

1 голос
/ 04 июня 2010

Часто требуется захватить сложную структуру классов, которые есть в вашей ОО-системе, поэтому для моделирования используются диаграммы классов из UML. Вы также можете описать взаимодействия классов, для которых полезны диаграммы последовательности. Есть и другие UML-диаграммы, и у каждой есть своя цель. Если вы ищете подход к моделированию, попробуйте взглянуть на Unified Process, который является методом разработки, который создан авторами UML и довольно интенсивно использует UML, а также описывает, как можно использовать UML.

0 голосов
/ 20 июня 2010

Лучше всего Visual Studio 2010 Ultimate, другие слишком громоздки. В противном случае используйте легкие инструменты, такие как yuml, см. http://askuml.com для образцов.

0 голосов
/ 06 июня 2010

Моделирование (дизайн) - самая важная часть каждого проекта. Фактически, с течением времени мы жертвуем производительностью, чтобы получить более высокий уровень дизайна. Почему .NET Framework популярен (по сравнению со старыми инструментами)? В большинстве случаев его библиотеки являются обертками над традиционными API Win32, что является пустой тратой производительности, вместо этого он обеспечивает лучший дизайн, который облегчает изучение и использование. Поэтому, если ваш проект имеет хороший дизайн, его будет легко понять, разработать, отладить, поддерживать и расширять. Другой пример - сам ООП, который имеет классы, интерфейсы ... и кучу вызовов конструктора / деструктора. Концепции ООП заимствованы из психиатрии и того, как человек видит мир.

Вот два разных понятия: 1) Методология проектирования 2) Методология управления проектом

Их много, и я не назову ни хорошего, ни плохого. Каждый из них соответствует сценарию. Что касается методологии проектирования, то я предпочитаю DDD (Domain Driven Design), так как он отображает терминологию и концепции отраслевого домена. Поэтому, если у вас есть проблема с решением, что делать, если произошло A-> B-> C, просто вы можете спросить специалиста в области, и он скажет, что они делают в реальном мире. DDD хорош для достаточно старых отраслей, которые обладают накопленной мудростью. Я не буду больше писать о дизайне, так как мы не знаем о проекте.

Методологии управления проектами (например, гибкие) - это способ построения здания по карте (дизайн). Целью управления проектами является оптимальное использование ресурсов (время, деньги, человеческие ресурсы ...). Это делается через структуру разбивки работ и делает работу как можно более параллельной. Наиболее известная методология управления проектами - это традиционная методика, в которой мы делаем все по порядку, как это делают инженеры-строители (фундамент, конструкция, стены ...). Это было хорошо на протяжении многих веков, вплоть до последних десятилетий (индустрия программного обеспечения), поскольку в традиционном управлении проектами вы знаете, где вы находитесь, куда хотите идти и как туда добраться. Таким образом, вы можете купить свою мебель для дома, который еще есть! Индустрия программного обеспечения претерпела очень быстрые изменения в инструментах и ​​методах, потому что она была новой, и на тысячах неудачных проектов не было основано ни одной лучшей практики. Много раз, когда проект начинался, у него были изменения из-за изменений в разработке инструментов и структур. Другим источником изменений является масштаб проекта (куда идти). Программное обеспечение является нематериальным продуктом, поэтому вы легко попадете в ловушку оценки времени. Для разработки программного обеспечения наилучшей практикой являются итерационные методологии. Итеративные методологии предполагают работающее неполное решение, которое вы сделаете более полным на следующей итерации, а не нерабочее частично завершенное. Это требует временных затрат, вместо этого вы уверены, что решение работает и, если возникнут какие-либо проблемы, вы обнаружите их на ранних стадиях. Вот почему у нас есть ночные сборки!

0 голосов
/ 04 июня 2010

Agile методология в настоящее время является то, что рекомендуется. Если вы добавите кусочек UML, то будет лучше: -)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...