Служба Рассылок Городского Кота

Еще раз здравствуйте, уважаемые читатели ! Я что-то засомневался, что это 9-й выпуск, возникло предположение, что 13-й А все дело в том, что вся моя система за время отсутствия рассылки в ваших ящиках рухнула, исчезли многие мной любимые программы. Да и сервер CityCat преподнес подарок с модификацией формы отправки. Надеюсь ;-) этот выпуск (9-й) дойдет до вас полностью.

Кстати, спасибо тем кто написал мне об этом.

И да простят меня читатели текстовых версий...

Очень рад вас видеть, даже немного соскучился !

Дела, дела... Как они много времени требуют, а ведь еще и рассылка. Извиняюсь за долгий перерыв, надеюсь вы меня поймете: ведь я занимаюсь рассылкой в свободное время.

Проголосовало всего 73 человека из 6700 ? Меня это удивило... Не ожидал. Голосование я не закрываю до следующего выпуска, так что очередь за вами. И еще, на сервере голосований имеется какая-то забавная ошибка: только один раздел "CASE" не считает голоса, хотя код в порядке (вернее стал в порядке, после сообщения доброго читателя - спасибо). Буду разбираться с www.voting.ru.

Спасибо тем, кто откликнулся на мой призыв поиска материалов для библиотеки, а также тем, кто собирается это сделать. Набралось около 15 Мб, они даже лежат уже на сервере... а вот времени на аннотацию не хватает. Постараюсь исправиться к следующей неделе.

Присылайте свои вопросы и ответы, советы, критику (давно ее не слышал - странно), мысли, тексты !

Как всегда смотрите вакансии в конце рассылки. Надеюсь помогут.

Как мной и обещалось сегодня будет рассмотрено нисходящее проектирование в более практическом аспекте.

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

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

2. Как только вы убедитесь, что некоторая часть задачи может быть реализована в виде отдельного модуля, постарайтесь больше не думать об этом, т. е. не уделяйте слишком много внимания тому, как именно он будет реализован.

3. Внимательно следите за тем, чтобы вас (или группу проектировщиков) не вовлекли в обсуждение несущественных деталей задачи.

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

Более подробно некоторые из этих предпосылок обсуждаются ниже.

Спецификация интерфейсов. Ранее мы отметили, что одним из наиболее важных элементов нисходящего проектирования является формализованный подход к спецификации входов, функций и выходов, которые должны быть реализованы каждым модулем.

Ничто не устраивается само собой. Напротив, поверхностное восприятие нисходящего проектирования рождает у программиста ложное чувство самоуверенности. Именно по этой причине в некоторых организациях были предприняты энергичные попытки формализовать этапы нисходящего проектирования. Интересно то, что многие из этих попыток нашли свое отражение в руководствах по проектированию, используемых в области автоматизированной обработки данных, как средство организации и управления комплексной разработкой проектов соответствующих систем. Одним из наиболее интересных и широко распространенных приемов такого формализованного подхода к нисходящему проектированию является созданная на фирме IBM методология иерархических диаграмм "вход - обработка - выход" или сокращенно HIPO. Не следует, однако, думать, что HIPO является единственно возможной методологией. Главное здесь состоит в том, что в нисходящем проектировании следует использовать некоторый формализованный и регламентированный подход к документированию; в противном случае программисты и проектировщики обнаруживают тенденцию к слишком неформальному описанию.

Некоторые программисты жалуются, что процесс проектирования программы или вычислительной системы нельзя описать столь формально, что он представляет последовательность интуитивных попыток, в которых формируется решение. Они часто отмечают, что итеративный процесс и что трудности, возникающие на нижнем уровне проекта, часто вынуждают переосмысливать решения, принятые на более высоком уровне. Безусловно, некоторые этапы процессов проектирования относятся к этому типу; на самом деле никто и не мыслит себе создание законченного проекта как процесс, напоминающий единый порыв блестящего гения. В особенности, если перед нами случай, когда проектирование выполняется группой людей, то мы должны быть готовы к тактике "два шага вперед, шаг назад"; нам следует допускать, что проектировщики могут изменить свое мнение о ранее выбранной реализации некоторого модуля; мы можем согласиться с тем, что первая попытка создания проекта программы выглядит несколько расплывчатой неопределенной. Это ни в коей мере не нарушает основных принципов нисходящего проектирования. После "мозгового штурма" и достаточно полного неформального обсуждения деталей проекта определенного уровня программы все-таки следует потребовать, чтобы эта часть проекта была записана формально (в терминах входов, функций и выходов), прежде чем мы перейдем. к проектированию следующего уровня. Если трудности, возникшие при проектировании уровня номер N+1, действительно вызывают необходимость повторного проектирования уровня номер N, то это и следует сделать; и тем не менее нам представляется, что такой подход к решению задачи остается регулярным.

Старайтесь не обращать внимания на детали описания модулей нижних уровней. Как было отмечено выше, многие программисты увлекаются описанием несущественных деталей проекта, в то время как требуется сосредоточить внимание на более высоких его уровнях. Здесь, по-видимому, уместно спросить: "В чем причина этого?" и "Что в связи с этим можно предпринять?". Наблюдая несколько групп программистов, попавших в эту ловушку, и спрашивая, что ввергло их в обсуждение мелочей, я понял, что тут могут быть выделены три основные причины.

1.Некоторые программисты признают, что они могут обсуждать как единственно осязаемые вещи только мелкие подробности. Большую часть построений, касающихся верхних уровней проекта, они находят слишком абстрактными и неопределенными. Поскольку в своем большинстве они не имеют достаточного опыта в проектировании такого рода (в действительности возникает вопрос, имеют ли они вообще какой бы то ни было опыт в проектировании программ?), то им трудно общаться друг с другом. И все они соглашаются с тем, что по крайней мере конкретные детали проекта могут служить для них предметом обсуждения.

2. Многие группы программистов подтверждают, что основная проблема для них заключается в дисциплине. Даже понимая, что они напрасно тратят время на обсуждение тривиальных аспектов проекта, они обнаруживали, что их внимание неизменно оказывается привлеченным именно к этим аспектам. Во многих случаях это отражение трудностей управления; в группе не нашлось достаточно авторитетного человека, который настоял бы на том, чтобы обсуждение несущественных предметов было отложено.

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

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

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

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

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

Может оказаться, что для успешного нисходящего проектирования программных модулей некоторые элементы базы данных должны быть определены до мельчайших подробностей на относительно ранних этапах проектирования, но это не всегда нужно. Возможны случаи, когда для работы со структурой данных, необходимых программе, просто выделяется отдельный модуль, который обрабатывает и выполняет запросы, но здесь встает вопрос об интерфейсе между модулями (особенно между модулем работы с БД и верхними, обращающимися к нему).

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

На этом мы, пожалуй, и закончим тему нисходящего проектирования. Тех, кому понравился этот подход к проектированию программ, могу обрадовать, что существуют технологии не только нисходящего проектирования, но и кодирования, и даже тестирования. Вот пожалуй мы этим подходам и посвятим несколько выпусков.

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

1. После прочтения теоретического материала о модульном программировании интересно было бы узнать от вас: чем отличается функция от модуля, да и отличается ли вообще ?

2. Стоит ли рассмотреть технологию HIPO ?

3. Один из читателей спросил меня, и мне стало очень интересно узнать ваше мнение. Почему в качестве IT -специалистов требуются в основном молодые люди (обычно до 30) ?

Жду ответов.

!!!??? Как видите новых вопросов не прибавилось. Неужели ничто никого не интересует.

Вопрос:
В случае проектирования многопользовательской системы, в которой, существует несколько ролей или наборов прав, для различных пользователей, возможно ли (а может быть и следует) вводить в качестве актор а (Actor) абстрактных пользователей системы? Или возможно только рассмотрение в качестве акторов лишь элементов системы - в данном случае пользовательские интерфейсы, связанные с тем или иным набором прав (ролью) пользователей. Иными словами, возможно ли включение на этапе объектного анализа в модель системы объектов заведомо лежащих за пределами программной системы, но определенным образом взаимодействущих с нею?

Ответ: (прислал Андрей)
Вопрос вообще достаточно запутан, но, видимо, состоит в том: следует ли включать внешние сущности в моделируемую систему. Однажды, много лет назад, человек создавший свою методологию проектирования (OOSE) Ивар Джекобсон ответил на этот вопрос. Да, конечно, но не требуется раскрывать их устройство, поскольку они суть внешние относительно моделируемой системы. Следовательно, вопрос состоит в том, как отделить внешние сущности от системы. Для этой цели Джекобсон предложил Use Case диаграмму, которая ныне входит в состав нотации UML. Именно там акторами отображаются внешние относительно моделируемой системы сущности, а наборами сценариев (Use Case) -- функциональности создаваемой системы. Согласно тому же Джекобсону, построение такой диаграммы -- первое, что следует делать при выполнении объектно-ориентированного анализа, именно по причине того, что это позволяет определить место системы среди всего внешнего, определить как функционал моделируемой системы, так и его связь с внешними сущностями. Советую обязательно построить Use Case, это поможет определиться.

Вопрос: Можно ли привести пример расчета трудозатрат на написание программы ?
Ответ: Ответ есть ! Мне просто нужно время для его анализа и редактирования.

http://www.delfin.ru/misc/stas - Авторская страница читателя рассылки. Имеется неплохой материал по проектированию информационных систем.

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

"Новости библиотеки алгоритмов" - то, что иногда не хватает программистам - алгоритмов на все случаи жизни !

- Ищется РЕКЛАМОДАТЕЛЬ.
- Ищутся соавторы, авторы, практики и т.п. с целью оказания рассылке информационной поддержки.