Рассылка закрыта
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
Служба Рассылок Городского Кота
9-й выпуск
Проголосовало всего 73 человека из 6700 ? Меня это удивило... Не ожидал. Голосование я не закрываю до следующего выпуска, так что очередь за вами. И еще, на сервере голосований имеется какая-то забавная ошибка: только один раздел "CASE" не считает голоса, Спасибо тем, кто откликнулся на мой призыв поиска материалов для библиотеки, а также тем, кто собирается это сделать. Набралось около 15 Мб, они даже лежат уже на сервере... а вот времени на аннотацию не хватает. Постараюсь исправиться к следующей неделе. Присылайте свои вопросы и ответы, советы, критику (давно ее не слышал - странно), мысли, тексты ! Как всегда смотрите вакансии в конце рассылки. Надеюсь помогут.
Как мы уже видели, нисходящее проектирование включает разбиение большой задачи на меньшие подзадачи, которые могут рассматриваться порознь. Здесь, видимо, уместно сформулировать некоторые важные предпосылки для успешного применения нисходящего проектирова 1. Представляется, что ключом к успешному нисходящему проектированию может служить формализованное и строгое описание проектировщиком входов, функций и выходов всех модулей программы или системы. 2. Как только вы убедитесь, что некоторая часть задачи может быть реализована в виде отдельного модуля, постарайтесь больше не думать об этом, т. е. не уделяйте слишком много внимания тому, как именно он будет реализован. 3. Внимательно следите за тем, чтобы вас (или группу проектировщиков) не вовлекли в обсуждение несущественных деталей задачи. 4. Проектированию структуры данных следует уделять не меньше внимания, чем проектированию процессов или алгоритмов. Во многих случаях в состав этих данных входят требования к межмодульным интерфейсам, и проектирование этих модулей не продвинется существен Более подробно некоторые из этих предпосылок обсуждаются ниже. Спецификация интерфейсов. Ранее мы отметили, что одним из наиболее важных элементов нисходящего проектирования является формализованный подход к спецификации входов, функций и выходов, которые должны быть реализованы каждым модулем. Ничто не устраивается само собой. Напротив, поверхностное восприятие нисходящего проектирования рождает у программиста ложное чувство самоуверенности. Именно по этой причине в некоторых организациях были предприняты энергичные попытки формализовать этапы Некоторые программисты жалуются, что процесс проектирования программы или вычислительной системы нельзя описать столь формально, что он представляет последовательность интуитивных попыток, в которых формируется решение. Они часто отмечают, что итеративный Старайтесь не обращать внимания на детали описания модулей нижних уровней. Как было отмечено выше, многие программисты увлекаются описанием несущественных деталей проекта, в то время как требуется сосредоточить внимание на более высоких его уровнях. Здесь 1.Некоторые программисты признают, что они могут обсуждать как единственно осязаемые вещи только мелкие подробности. Большую часть построений, касающихся верхних уровней проекта, они находят слишком абстрактными и неопределенными. Поскольку в своем больши 2. Многие группы программистов подтверждают, что основная проблема для них заключается в дисциплине. Даже понимая, что они напрасно тратят время на обсуждение тривиальных аспектов проекта, они обнаруживали, что их внимание неизменно оказывается привлеченн 3. Наконец, в некоторых группах заявили, что успех всего проекта может зависеть от того, смогут ли они найти удовлетворительное решение для определенного модуля нижнего уровня. Тревожит то, что многие проектировщики программ, углубившись в проектирование Ограничивайте размеры модулей в нисходящем проектировании. Проектируя, вы должны также помнить хорошее правило: страница-две текста за один прием. На каждой стадии проектирования программы вам надо пытаться записать в явном виде реализацию некоторого моду Тщательно проектируйте структуру данных. Наконец, следует подчеркнуть, что обычно в проектировании описание структуры данных имеет не менее важное значение, чем описание алгоритмов. В большинстве случаев идеология нисходящего проектирования применима к оп Некоторые разработчики систем утверждают, что в основном структура базы данных известна заранее. Для них, например," представляется очевидным, что их прикладные экономические программы обращаются к главному файлу, файлу изменений и некоторым другим типам Однако в более общем случае мы должны считать, что база данных, о которой здесь идет речь, включает входные данные всей программы, ее выходные данные и различные файлы, таблицы и другие вспомогательные переменные, которые передаются в программе из одного Может оказаться, что для успешного нисходящего проектирования программных модулей некоторые элементы базы данных должны быть определены до мельчайших подробностей на относительно ранних этапах проектирования, но это не всегда нужно. Возможны случаи, когда Важно заметить, что мы делаем различие между подробным и негибким проектированием структуры данных. Основное назначение нисходящего проектирования - служить средством разбиения большой задачи на меньшие подзадачи таким образом, чтобы каждую подзадачу можн На этом мы, пожалуй, и закончим тему нисходящего проектирования. Тех, кому понравился этот подход к проектированию программ, могу обрадовать, что существуют технологии не только нисходящего проектирования, но и кодирования, и даже тестирования. Вот пожалу Естественно, что теория без практики тяжеловата для изучения. Поэтому я предлагаю вам в следующем выпуске ознакомиться с примером нисходящего проектирования программы.
2. Стоит ли рассмотреть технологию HIPO ? 3. Один из читателей спросил меня, и мне стало очень интересно узнать ваше мнение. Почему в качестве IT -специалистов требуются в основном молодые люди (обычно до 30) ? Жду ответов.
Вопрос: В случае проектирования многопользовательской системы, в которой, существует несколько ролей или наборов прав, для различных пользователей, возможно ли (а может быть и следует) вводить в качестве актор а (Actor) абстрактных пользователей системы? Или возм Ответ: (прислал Андрей) Вопрос вообще достаточно запутан, но, видимо, состоит в том: следует ли включать внешние сущности в моделируемую систему. Однажды, много лет назад, человек создавший свою методологию проектирования (OOSE) Ивар Джекобсон ответил на этот вопрос. Да, конеч Согласно тому же Джекобсону, построение такой диаграммы -- первое, что следует делать при выполнении объектно-ориентированного анализа, именно по причине того, что это позволяет определить место системы среди всего внешнего, определить как функционал моде Вопрос: Можно ли привести пример расчета трудозатрат на написание программы ? Ответ: Ответ есть ! Мне просто нужно время для его анализа и редактирования.
http://www.cetus-links.org/oo_uml.html - Множество ссылок на материалы по объектно-ориентированому программированию и языку UML. http://got2.mmtel.ru/net/gost/index.htm - ГОСТЫ на проектирование и разработку программного обеспечения http://ekarat.chat.ru/ - Еще одна авторская страничка читателя рассылки. Есть немного интересных статей по математике и программированию, особенно мне запомнилась статья "Проектирование классов в шутку и в серьез". Советую почитать ! Присылайте свои ссылки.
В рамках сотрудничества между авторами рассылок, посвященных программированию, предлагаю вам подписаться на рассылки: "Программируем на Visual Basic" - рассылка посвящена практическим вопросам программирования на MVB. "Секреты программирования в Delphi" - все или почти все о Delphi "Новости библиотеки алгоритмов" - то, что иногда не хватает программистам - алгоритмов на все случаи жизни !
Образование - высшее Заработная плата от 400 у.е./месяц На постоянную работу, полный рабочий день Город: Москва Персона для контакта: Алексей Яцкевич E-mail: apl_mail@mail.ru Дополнительная информация: Требуется программист с хорошим знанием Visual C++ и MFC. Желательно знание технологии COM/DCOM
Требуется программист
на должность программист.
Организации Moscow
office of offshore
software company требуется руководитель проекта
на должность Software
Project Manager.
Требуется руководитель структурного подразделения
на должность руководитель структурного подразделения.
|
http://www.citycat.ru/
E-mail: citycat@citycat.ru |
В избранное | ||