Опубликован: 10.10.2006 | Доступ: свободный | Студентов: 6098 / 464 | Оценка: 4.26 / 3.88 | Длительность: 31:30:00
Лекция 11:

Проектирование и развитие

11.5 Свод правил

В этой лекции мы затронули много тем, но как правило не давали настоятельных и конкретных рекомендаций по проектированию. Это соответствует моему убеждению, что нет "единственно верного решения". Принципы и приемы следует применять тем способом, который лучше подходит для конкретных задач. Для этого нужен вкус, опыт и разум. Все-таки можно указать некоторый свод правил, который разработчик может использовать в качестве ориентиров, пока не наберется достаточно опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.

Эти правила можно использовать в качестве отправной точки в процессе выработки основных направлений для проекта или организации или в качестве проверочного списка. Подчеркну еще раз, что они не являются универсальными правилами и не могут заменить размышления.

  • Узнайте, что вам предстоит создать.
  • Ставьте определенные и осязаемые цели.
  • Не пытайтесь с помощью технических приемов решить социальные проблемы.
  • Рассчитывайте на большой срок
    • в проектировании, и
    • управлении людьми.
  • Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.
  • Проектируйте в расчете на изменения:
    • гибкость,
    • расширяемость,
    • переносимость, и
    • повторное использование.
  • Документируйте, предлагайте и поддерживайте повторно используемые компоненты.
  • Поощряйте и вознаграждайте повторное использование
    • проектов,
    • библиотек, и
    • классов.
  • Сосредоточьтесь на проектировании компоненты.
    • Используйте классы для представления понятий.
    • Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.
    • Проводите строгую типизацию интерфейсов всегда, когда это возможно.
    • Используйте в интерфейсах типы из области приложения всегда, когда это возможно.
  • Многократно исследуйте и уточняйте как проект, так и реализацию.
  • Используйте лучшие доступные средства для проверки и анализа
    • проекта, и
    • реализации.
  • Экспериментируйте, анализируйте и проводите тестирование на самом раннем возможном этапе.
  • Стремитесь к простоте, максимальной простоте, но не сверх того.
  • Не разрастайтесь, не добавляйте возможности "на всякий случай".
  • Не забывайте об эффективности.
  • Сохраняйте уровень формализации соответствующим размеру проекта.
  • Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.

Еще некоторые правила можно найти в \S 12.5

11.6 Список литературы с комментариями

В этой лекции мы только поверхностно затронули вопросы проектирования и управления программными проектами. По этой причине ниже предлагается список литературы с комментариями. Значительно более обширный список литературы с комментариями можно найти в [2].

  1. Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa, Canada. pp. 12-27. Описание модели итеративного проектирования и повторного проектирования с некоторыми примерами и обсуждением результатов.
  2. Grady Booch: Object Oriented Design. Benjamin Cummings. 1991. В этой книге есть детальное описание проектирования, определенный метод проектирования с графической формой записи и несколько больших примеров проекта, записанных на различных языках. Это превосходная книга, которая во многом повлияла на эту лекцию. В ней более глубоко рассматриваются многие из затронутых здесь вопросов.
  3. Fred Brooks: The Mythical Man Month. Addison Wesley. 1982. Каждый должен перечитывать эту книгу раз в пару лет. Предостережение от высокомерия. Она несколько устарела в технических вопросах, но совершенно не устарела во всем, что касается отдельного работника, организации и вопросов размера.
  4. Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4. April 1987. Сводка различных подходов к процессу развития больших программных систем с очень полезным предостережением от веры в магические рецепты ("золотая пуля").
  5. De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987. Одна из немногих книг, посвященных роли человеческого фактора в производстве программного обеспечения. Необходима для каждого менеджера. Достаточно успокаивающая для чтения перед сном. Лекарство от многих глупостей.
  6. Ron Kerr: A Materialistic View of the Software "Engineering" Analogy. in SIGPLAN Notices, March 1987. pp 123-125. Использование аналогии в этой и следующей лекциях во многом обязано наблюдениям из указанной статьи, а так же беседам с Р. Керром, которые этому предшествовали.
  7. Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87 (Addendum). Orlando, Florida. pp 17-34. Исследуется как использование наследования может повредить концепции абстрактных данных. Укажем, что в С++ есть специальные языковые средства, помогающие избежать большинство указанных проблем ( \S 12.2.5).
  8. C. N. Parkinson: Parkinson's Law and other Studies in Administration. Houghton-Mifflin. Boston. 1957. Одно из забавных и самых язвительных описаний бед, к которым приводит процесс администрирования.
  9. Bertrand Meyer: Object Oriented Software Construction. Prentice Hall. 1988. Страницы 1-64 и 323-334 содержат хорошее описание одного взгляда на объектно-ориентированное программирование и проектирование, а также много здравых, практических советов. В остальной части книги описывается язык Эйффель (Eiffel).
  10. Alan Snyder: Encapsulation and Inheritance in Object-Oriented Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45. Возможно первое хорошее описание взаимодействия оболочки и наследования. В статье так же на хорошем уровне рассматриваются некоторые понятия, связанные с множественным наследованием.
  11. Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener: Designing Object-Oriented Software. Prentice Hall. 1990. Описывается антропоморфный метод проектирования, основанный на специальных карточках CRC (Classes, Responsibilities, Collaboration) (т.е. Классы, Ответственность, Сотрудничество). Текст, а может быть и сам метод тяготеет к языку Smalltalk.
Дарья Федотова
Дарья Федотова
Сергей Березовский
Сергей Березовский

В рамках проф. переподготовки по программе "Программирование"

Есть курсы, которые я уже прошел. Но войдя в курс я вижу, что они не зачтены (Язык Ассемблера и архитектура ЭВМ, Программирование на С++ для профессионалов). Это как?

Роман Островский
Роман Островский
Украина
Оксана Пагина
Оксана Пагина
Россия, Москва