Индустрия программирования
Индустрия программирования
Сапожник без сапог или Индустрия ли программирование?
Искусство программирования, наука программирования или индустрия программирования - так будет называться сегодняшняя дискуссия. Однако позвольте мне несколько изменить вопрос. Я бы сформулировал его так: что нужно, чтобы сделать программирование индустрией? Что такое PowerBuilder, Delphy, C++, Tcl/Tk, о которых вам уже рассказывали или еще будут рассказывать? Инструменты, причем инструменты, так скажем, "индпошива", которые позволяют в зависимости от таланта мастера получить плохое, хорошее или даже выдающееся изделие.
А что такое индустрия? Это прежде всего такие технологии и методы организации производства, которые позволяют получать стабильно высококачественный продукт быстро и дешево.
Если вы скажете, что в программировании нет крупносерийного производства (если не считать проблемы тиражирования дискет и компактов), что здесь штучный продукт и к нему нельзя подходить с мерками, скажем, производства автомобилей, я позволю себе с вами не согласиться.
Чтобы выпускать хороший автомобиль, нужно, во-первых, иметь хороший проект.
И в программировании это требование едва ли не важнее, поскольку: новый проект автомобиля бывает нужен раз в три или пять лет, а многие из вас выполняют три-пять достаточно крупных проектов в год; новый автомобиль можно довести до необходимого уровня уже запустив в производство, в программировании же часто приходится ограничиваться первым экземпляром.
Во-вторых, для производства автомобиля вам нужны грамотные и энергичные технологи, которые решат, что как лучше делать, какими инструментами воспользоваться, какую дополнительную оснастку разработать или закупить. И в программировании вам необходимо выбрать инструментарий, в частности, ту же СУБД и язык программирования или билдер, проработать типовые решения, определить состав библиотеки стандартных функций или классов.
После этого и начинается массовое производство. Если это автомобиль, то расставляются рабочие вдоль конвейера и обучаются достаточно простым операциям.
Если это программирование, то программистам-кодировщикам раздаются задания на программирование отдельных модулей, форм или как вы их у себя называете. И здесь, что бы вы ни производили, на первый план выходят вопросы соблюдения технологической дисциплины и взаимозаменяемости работников.
Каждый сборщик на конвейере должен затянуть все гайки, которые ему положено, с требуемым усилием, чтобы автомобиль не заклинило и чтобы он не развалился, сойдя с конвейера. Каждый кодировщик, участвующий в проекте, должен не забыть, что "... по ключу F1 должен вызываться Help, по ключу F2 должно записываться в базу содержимое экранной формы, а по ключу F3...", что необходимо предусмотреть ситуацию, когда по условию не выбралось ни одной записи, что в используемой версии языка есть такой-то bug, а поэтому такую-то конструкцию лучше не применять, чтобы программа не зависла и не вылетела.
Короче говоря, производство программ - это действительно производство, и подходить к нему надо как к производству. A la ger com a la ger.
Отличие же его от остальных производств - прежде всего в технической оснащенности производителя.
Она потенциально очень велика, поскольку в руках у производителя здесь один из наиболее интеллектуальных инструментов, известных человеку, - компьютер. Вспомните научно-популярные книжки, в которых описывается мощь современной вычислительной техники.
Она может и это, и то, и решения оптимальные принимать, и чертежи чертить, и уж не знаю что еще. И учит ее этому не кто иной, как Программист, причем с большой буквы. Вот уж, наверно, кто получает от компьютера все, что тот может дать. Как бы не так! Выше я перечислил основные фазы разработки крупного программного обеспечения, не важно, информационной системы или еще чего-либо.
Чем же компьютер помогает программисту на различных этапах этого процесса? На стадии подготовки проекта - назовите ее разработкой эскизного и технического проекта, как это называлось при социализме, стадиями анализа задачи и глобального проектирования системы или модным ныне сокращением BPR - компьютер чаще всего выступает в роли... пишущей машинки! Аналитик, если у него есть соответствующие навыки, если от него требует заказчик, если от него этого требуют программисты и кодировщики, пишет текст. Компьютер с его интеллектуальной мощью, конечно, помогает - следит за орфографией.
В дело вступают собственно программисты - начинается разработка библиотеки стандартных функций или классов. Да, роль компьютера резко возрастает. Он теперь не только пишущая машинка, но и канцелярский шкаф! Причем интеллектуальный! Он позволяет всем участникам проекта видеть все программы, написанные остальными, но взять на редактирование текст позволяет только одному программисту! Ай да интеллектуальная мощь! Дальше в дело вступают программисты-кодировщики. Те, кто, используя разработанные библиотеки функций или классов, приспосабливает их к конкретным таблицам и экранным формам.
Компьютер выступает тут еще в одной роли - копира.
И, на мой взгляд, все современные системы визуального программирования и билдеры, которые позволяют создавать программы без или почти без ручного программирования, здесь практически ничего не меняют. На долю человека все равно остается масса рутинного, однообразного, малоинтеллектуального труда, когда и совершается основная масса ошибок.
И кроме того, это же не комплексная автоматизация, эти инструменты не поддерживают всего жизненного цикла проекта.
Что получается? Группа высокоинтеллектуальных разработчиков, оснащенная самой мощной интеллектуальной техникой, вручную разрабатывает проект, хорошо если не пожалев времени на то, чтобы изложить его на бумаге.
После этого в дело вступают наиболее квалифицированные программисты. Эти еще кое-как оснащены: ERwin там для создания базы данных, средства разработки библиотек классов или готовые библиотеки. А дальше идут кодировщики, пишущие основную массу текста "по образцу" и вносящие в него основную массу ошибок, которые потом долго отлавливаются и исправляются.
Конечно, объектный подход позволяет вам сократить количество кодировщиков и вносимых ими ошибок. Выход? Как бы не так! Тут вы легко можете попасть в другую западню. Какой программист любит документировать программу? А вносить исправления в чужую достаточно сложную, но плохо документированную программу? И уход любого члена команды ставит под удар весь проект.
Интеллектуальная мощь компьютера на службе программиста Та безрадостная картина, которую я нарисовал, всего лишь иллюстрация типичного на сегодня положения дел в России. Если не вдаваться в детали, это явные последствия слишком быстрого распространения персоналок и недостатка денег на действительно крупные проекты.
В индустриальном же и тем более постиндустриальном мире существуют и активно используются инструменты, позволяющие аналитику, как побочный продукт своего труда, получить качественно оформленный проект, программисту тщательно проработать библиотеки, а кодировщику ограничиться внесением вручную небольших и хорошо документированных фрагментов текста программы, возложив всю рутинную работу на компьютер.
И именно о такой технологии, позволяющей действительно рассматривать программирование как вполне индустриальную отрасль производства, а не нечто непонятное на грани искусства и ремесленничества, я вам расскажу.
Инструменты, позволяющие поднять программирование до индустриального уровня, традиционно называются CASE-средствами, где CASE это не чемодан, а Computer Aided Software/System Engineering.
Основу технологии, предлагаемой нашей фирмой, составляют CASE-средства фирмы Cayenne: Vantage Team для структурного подхода к проектированию (хочу подчеркнуть, к проектированию, а не программированию) и ObjectTeam for OMT для объектного подхода.
Для тех, кто следит за рекламными и другими публикациями нашей фирмы, поясню. I-CASE Yourdon фирмы Westmount, Vantage Team builder фирмы CADRE и Vantage Team фирмы Cayenne - это один и тот же продукт, также как один продукт, хотя и разных версий, I-CASE OMT фирмы Westmount и ObjectTeam for OMT фирм CADRE и Cayenne. Короче, названия меняются, а продукты остаются.
В дальнейшем я буду вам рассказывать про один из этих продуктов, про Vantage Team. Это связано с тем, что я сам больше работал с ним, поскольку предпочитаю в проектировании структурную терминологию. Мне, возможно по многолетней привычке, она кажется более естественной для аналитика-непрограммиста и более понятной для заказчика-непрограммиста. Возможности ObjectTeam for OMT в целом аналогичны, но, пользуясь ими, приходится придерживаться объектной терминологии.
VantageTeam фирмы CADRE позволяет использовать метод структурного проектирования Yourdon'а с некоторыми дополнениями. В целом метод представляется весьма естественным и достаточно прост в освоении как разработчиком, так и заказчиком.
То есть вы без проблем можете обсуждать с заказчиком детали проекта, почти не тратя времени на то, чтобы обучить его своему языку, в частности, благодаря графическому представлению основных результатов разработки.
В соответствии с выбранным методом работа над проектом разбивается на четыре фазы: анализ, архитектура (в соответствии с отечественными традициями - глобальное проектирование), дизайн (соответственно - детальное проектирование) и программирование.
Анализ - постановка задачи, общие принципы решения В фазе анализа VantageTeam Builder предоставляет ряд графических редакторов для работы с диаграммами различных типов. Это диаграммы потоков данных, используемые как для описания взаимодействия системы с внешним миром (контекстная диаграмма), так и для определения структуры процесса обработки информации (диаграммы потоков данных более низких уровней).
При желании вы можете сформировать формализованное описание требований к разрабатываемой системе в виде списка событий и откликов. В этом случае обеспечивается контроль соответствия контекстной диаграммы и списка событий. Кроме того обеспечивается контроль правильности декомпозиции диаграмм при переходе с уровня на уровень.
Для анализа структуры и разработки модели данных предлагается весьма широкий спектр средств, включающий в себя диаграммы структуры данных, диаграммы отношений сущностей и текстовое описание в форме Бакуса-Науэра. Различные типы диаграмм сравниваются между собой на непротиворечивость.
Архитектура - общие принципы решения задачи С использованием оригинальных диаграмм архитектуры системы вы можете разработать архитектуру вычислительного комплекса и уточнить аппаратное оснащение рабочих мест проектируемой системы.
Определяется распределение задач между вычислительными средствами, в том числе между клиентом, сервером и промежуточным слоем, если вы их используете, а также потоки данных между вычислительными средствами, задачами (отдельными исполняемыми модулями) и процессами обработки информации в составе одной задачи. Создаются спецификации (формализованные описания) процессов обработки информации нижнего уровня. При необходимости возможно введение управляющих потоков и управляющих процессов и их описание с помощью специальных диаграмм.
Для описания необходимой структуры базы данных используются диаграммы отношений сущностей в нотации Чена. Они позволяют указывать различные типы реляционных отношений между таблицами (общее, тотальное, слабое, рекурсивное), связи различной мощности (1-1, 1-N, N-N), а также различные суб- и супертипы, ассоциированные сущности и связи с атрибутами.
Для описания полей таблиц используется механизм логических типов данных и логических ограничений, практически полностью поддерживающий понятие домена. Возможно задание внешних (используемых при работе с заказчиком и в документации) и внутренних (программных) имен таблиц и полей.
В фазе архитектуры начинается логическое проектирование интерфейса системы с использованием диаграмм последовательности экранных форм. Они позволяют указывать как условия переходов между экранными формами, так и выполняемые при этом действия.
Дизайн - детальная проработка основных решений на логическом уровне Фаза дизайна завершается "за один шаг до программы". Здесь осуществляется окончательная отработка модели данных, функциональной модели и проектирование интерфейса системы с помощью как уже упоминавшихся диаграмм, так и ряда специальных типов диаграмм, позволяющих однозначно сформулировать требования к интерфейсу и программе.
Разработка структуры базы данных предполагает привязку логических типов данных к типам данных конкретной СУБД и языка программирования. Также определяются необходимые политики поддержания целостности базы по ссылкам при основных действиях (INSERT, UPDATE, DELETE) с различными таблицами.
В основу разработки приложения положены интегрированные диаграммы последовательности экранных форм. В фазе дизайна в этих диаграммах для каждой формы указывается имя диаграммы содержания экранной формы и имя структурной схемы программного модуля, реализующего соответствующий процесс обработки информации.
Диаграммы содержания экранных форм позволяют указать таблицы и их поля, представленные в форме, способ их представления (список - полноэкранная форма), а также основные функциональные возможности (доступность таблиц для записи или только для чтения информации). При этом неявно определяется разделение таблиц на группы, включающие в себя одну основную (базовую) таблицу и связанные с ней отношением N-1 словари. На диаграмме можно указать необходимость открытия просмотрового окна (формы Look Up) для организация поиска значений в соответствующем словаре.
Структурные схемы программ - универсальное средство описания функциональных возможностей приложения. Они позволяют описать любую программу с произвольной точностью (до функции, до группы операторов, до отдельного оператора, до отдельных составляющих оператора типа структуры AFTER FIELD в операторе INPUT). Основными элементами структурных схем являются заголовок или вызов функции, хэт-модуль (модуль со "шляпой", что соответствует используемому для него обозначению), позволяющий записать произвольные конструкции на языке программирования и указания относительно их размещения в программном файле (например, из любого хэт-модуля можно добавить определение еще одной переменной в секцию описания глобальных, модульных или локальных переменных, добавить в файл описание еще одной функции и т. п.), операторы выбора (MENU, IF, IF... ELSE, CASE), операторы повтора (WHILE, FOR) и библиотечные (предопределенные или стандартные модули), представляющие собой весьма мощный инструмент быстрой разработки приложений.
Диаграммы структуры данных и аналогичные им по нотации диаграммы структуры управляющих потоков могут использоваться для определения структуры и типов программных переменных, если вы предполагаете программирование всей или части системы на С.
А. В. Закис,руководитель аналитической группы DataX/FLORIN, Inc. Продолжение следует
Сапожник без сапог или Индустрия ли программирование?
Искусство программирования, наука программирования или индустрия программирования - так будет называться сегодняшняя дискуссия. Однако позвольте мне несколько изменить вопрос. Я бы сформулировал его так: что нужно, чтобы сделать программирование индустрией? Что такое PowerBuilder, Delphy, C++, Tcl/Tk, о которых вам уже рассказывали или еще будут рассказывать? Инструменты, причем инструменты, так скажем, "индпошива", которые позволяют в зависимости от таланта мастера получить плохое, хорошее или даже выдающееся изделие.
А что такое индустрия? Это прежде всего такие технологии и методы организации производства, которые позволяют получать стабильно высококачественный продукт быстро и дешево.
Если вы скажете, что в программировании нет крупносерийного производства (если не считать проблемы тиражирования дискет и компактов), что здесь штучный продукт и к нему нельзя подходить с мерками, скажем, производства автомобилей, я позволю себе с вами не согласиться.
Чтобы выпускать хороший автомобиль, нужно, во-первых, иметь хороший проект.
И в программировании это требование едва ли не важнее, поскольку: новый проект автомобиля бывает нужен раз в три или пять лет, а многие из вас выполняют три-пять достаточно крупных проектов в год; новый автомобиль можно довести до необходимого уровня уже запустив в производство, в программировании же часто приходится ограничиваться первым экземпляром.
Во-вторых, для производства автомобиля вам нужны грамотные и энергичные технологи, которые решат, что как лучше делать, какими инструментами воспользоваться, какую дополнительную оснастку разработать или закупить. И в программировании вам необходимо выбрать инструментарий, в частности, ту же СУБД и язык программирования или билдер, проработать типовые решения, определить состав библиотеки стандартных функций или классов.
После этого и начинается массовое производство. Если это автомобиль, то расставляются рабочие вдоль конвейера и обучаются достаточно простым операциям.
Если это программирование, то программистам-кодировщикам раздаются задания на программирование отдельных модулей, форм или как вы их у себя называете. И здесь, что бы вы ни производили, на первый план выходят вопросы соблюдения технологической дисциплины и взаимозаменяемости работников.
Каждый сборщик на конвейере должен затянуть все гайки, которые ему положено, с требуемым усилием, чтобы автомобиль не заклинило и чтобы он не развалился, сойдя с конвейера. Каждый кодировщик, участвующий в проекте, должен не забыть, что "... по ключу F1 должен вызываться Help, по ключу F2 должно записываться в базу содержимое экранной формы, а по ключу F3...", что необходимо предусмотреть ситуацию, когда по условию не выбралось ни одной записи, что в используемой версии языка есть такой-то bug, а поэтому такую-то конструкцию лучше не применять, чтобы программа не зависла и не вылетела.
Короче говоря, производство программ - это действительно производство, и подходить к нему надо как к производству. A la ger com a la ger.
Отличие же его от остальных производств - прежде всего в технической оснащенности производителя.
Она потенциально очень велика, поскольку в руках у производителя здесь один из наиболее интеллектуальных инструментов, известных человеку, - компьютер. Вспомните научно-популярные книжки, в которых описывается мощь современной вычислительной техники.
Она может и это, и то, и решения оптимальные принимать, и чертежи чертить, и уж не знаю что еще. И учит ее этому не кто иной, как Программист, причем с большой буквы. Вот уж, наверно, кто получает от компьютера все, что тот может дать. Как бы не так! Выше я перечислил основные фазы разработки крупного программного обеспечения, не важно, информационной системы или еще чего-либо.
Чем же компьютер помогает программисту на различных этапах этого процесса? На стадии подготовки проекта - назовите ее разработкой эскизного и технического проекта, как это называлось при социализме, стадиями анализа задачи и глобального проектирования системы или модным ныне сокращением BPR - компьютер чаще всего выступает в роли... пишущей машинки! Аналитик, если у него есть соответствующие навыки, если от него требует заказчик, если от него этого требуют программисты и кодировщики, пишет текст. Компьютер с его интеллектуальной мощью, конечно, помогает - следит за орфографией.
В дело вступают собственно программисты - начинается разработка библиотеки стандартных функций или классов. Да, роль компьютера резко возрастает. Он теперь не только пишущая машинка, но и канцелярский шкаф! Причем интеллектуальный! Он позволяет всем участникам проекта видеть все программы, написанные остальными, но взять на редактирование текст позволяет только одному программисту! Ай да интеллектуальная мощь! Дальше в дело вступают программисты-кодировщики. Те, кто, используя разработанные библиотеки функций или классов, приспосабливает их к конкретным таблицам и экранным формам.
Компьютер выступает тут еще в одной роли - копира.
И, на мой взгляд, все современные системы визуального программирования и билдеры, которые позволяют создавать программы без или почти без ручного программирования, здесь практически ничего не меняют. На долю человека все равно остается масса рутинного, однообразного, малоинтеллектуального труда, когда и совершается основная масса ошибок.
И кроме того, это же не комплексная автоматизация, эти инструменты не поддерживают всего жизненного цикла проекта.
Что получается? Группа высокоинтеллектуальных разработчиков, оснащенная самой мощной интеллектуальной техникой, вручную разрабатывает проект, хорошо если не пожалев времени на то, чтобы изложить его на бумаге.
После этого в дело вступают наиболее квалифицированные программисты. Эти еще кое-как оснащены: ERwin там для создания базы данных, средства разработки библиотек классов или готовые библиотеки. А дальше идут кодировщики, пишущие основную массу текста "по образцу" и вносящие в него основную массу ошибок, которые потом долго отлавливаются и исправляются.
Конечно, объектный подход позволяет вам сократить количество кодировщиков и вносимых ими ошибок. Выход? Как бы не так! Тут вы легко можете попасть в другую западню. Какой программист любит документировать программу? А вносить исправления в чужую достаточно сложную, но плохо документированную программу? И уход любого члена команды ставит под удар весь проект.
Интеллектуальная мощь компьютера на службе программиста Та безрадостная картина, которую я нарисовал, всего лишь иллюстрация типичного на сегодня положения дел в России. Если не вдаваться в детали, это явные последствия слишком быстрого распространения персоналок и недостатка денег на действительно крупные проекты.
В индустриальном же и тем более постиндустриальном мире существуют и активно используются инструменты, позволяющие аналитику, как побочный продукт своего труда, получить качественно оформленный проект, программисту тщательно проработать библиотеки, а кодировщику ограничиться внесением вручную небольших и хорошо документированных фрагментов текста программы, возложив всю рутинную работу на компьютер.
И именно о такой технологии, позволяющей действительно рассматривать программирование как вполне индустриальную отрасль производства, а не нечто непонятное на грани искусства и ремесленничества, я вам расскажу.
Инструменты, позволяющие поднять программирование до индустриального уровня, традиционно называются CASE-средствами, где CASE это не чемодан, а Computer Aided Software/System Engineering.
Основу технологии, предлагаемой нашей фирмой, составляют CASE-средства фирмы Cayenne: Vantage Team для структурного подхода к проектированию (хочу подчеркнуть, к проектированию, а не программированию) и ObjectTeam for OMT для объектного подхода.
Для тех, кто следит за рекламными и другими публикациями нашей фирмы, поясню. I-CASE Yourdon фирмы Westmount, Vantage Team builder фирмы CADRE и Vantage Team фирмы Cayenne - это один и тот же продукт, также как один продукт, хотя и разных версий, I-CASE OMT фирмы Westmount и ObjectTeam for OMT фирм CADRE и Cayenne. Короче, названия меняются, а продукты остаются.
В дальнейшем я буду вам рассказывать про один из этих продуктов, про Vantage Team. Это связано с тем, что я сам больше работал с ним, поскольку предпочитаю в проектировании структурную терминологию. Мне, возможно по многолетней привычке, она кажется более естественной для аналитика-непрограммиста и более понятной для заказчика-непрограммиста. Возможности ObjectTeam for OMT в целом аналогичны, но, пользуясь ими, приходится придерживаться объектной терминологии.
VantageTeam фирмы CADRE позволяет использовать метод структурного проектирования Yourdon'а с некоторыми дополнениями. В целом метод представляется весьма естественным и достаточно прост в освоении как разработчиком, так и заказчиком.
То есть вы без проблем можете обсуждать с заказчиком детали проекта, почти не тратя времени на то, чтобы обучить его своему языку, в частности, благодаря графическому представлению основных результатов разработки.
В соответствии с выбранным методом работа над проектом разбивается на четыре фазы: анализ, архитектура (в соответствии с отечественными традициями - глобальное проектирование), дизайн (соответственно - детальное проектирование) и программирование.
Анализ - постановка задачи, общие принципы решения В фазе анализа VantageTeam Builder предоставляет ряд графических редакторов для работы с диаграммами различных типов. Это диаграммы потоков данных, используемые как для описания взаимодействия системы с внешним миром (контекстная диаграмма), так и для определения структуры процесса обработки информации (диаграммы потоков данных более низких уровней).
При желании вы можете сформировать формализованное описание требований к разрабатываемой системе в виде списка событий и откликов. В этом случае обеспечивается контроль соответствия контекстной диаграммы и списка событий. Кроме того обеспечивается контроль правильности декомпозиции диаграмм при переходе с уровня на уровень.
Для анализа структуры и разработки модели данных предлагается весьма широкий спектр средств, включающий в себя диаграммы структуры данных, диаграммы отношений сущностей и текстовое описание в форме Бакуса-Науэра. Различные типы диаграмм сравниваются между собой на непротиворечивость.
Архитектура - общие принципы решения задачи С использованием оригинальных диаграмм архитектуры системы вы можете разработать архитектуру вычислительного комплекса и уточнить аппаратное оснащение рабочих мест проектируемой системы.
Определяется распределение задач между вычислительными средствами, в том числе между клиентом, сервером и промежуточным слоем, если вы их используете, а также потоки данных между вычислительными средствами, задачами (отдельными исполняемыми модулями) и процессами обработки информации в составе одной задачи. Создаются спецификации (формализованные описания) процессов обработки информации нижнего уровня. При необходимости возможно введение управляющих потоков и управляющих процессов и их описание с помощью специальных диаграмм.
Для описания необходимой структуры базы данных используются диаграммы отношений сущностей в нотации Чена. Они позволяют указывать различные типы реляционных отношений между таблицами (общее, тотальное, слабое, рекурсивное), связи различной мощности (1-1, 1-N, N-N), а также различные суб- и супертипы, ассоциированные сущности и связи с атрибутами.
Для описания полей таблиц используется механизм логических типов данных и логических ограничений, практически полностью поддерживающий понятие домена. Возможно задание внешних (используемых при работе с заказчиком и в документации) и внутренних (программных) имен таблиц и полей.
В фазе архитектуры начинается логическое проектирование интерфейса системы с использованием диаграмм последовательности экранных форм. Они позволяют указывать как условия переходов между экранными формами, так и выполняемые при этом действия.
Дизайн - детальная проработка основных решений на логическом уровне Фаза дизайна завершается "за один шаг до программы". Здесь осуществляется окончательная отработка модели данных, функциональной модели и проектирование интерфейса системы с помощью как уже упоминавшихся диаграмм, так и ряда специальных типов диаграмм, позволяющих однозначно сформулировать требования к интерфейсу и программе.
Разработка структуры базы данных предполагает привязку логических типов данных к типам данных конкретной СУБД и языка программирования. Также определяются необходимые политики поддержания целостности базы по ссылкам при основных действиях (INSERT, UPDATE, DELETE) с различными таблицами.
В основу разработки приложения положены интегрированные диаграммы последовательности экранных форм. В фазе дизайна в этих диаграммах для каждой формы указывается имя диаграммы содержания экранной формы и имя структурной схемы программного модуля, реализующего соответствующий процесс обработки информации.
Диаграммы содержания экранных форм позволяют указать таблицы и их поля, представленные в форме, способ их представления (список - полноэкранная форма), а также основные функциональные возможности (доступность таблиц для записи или только для чтения информации). При этом неявно определяется разделение таблиц на группы, включающие в себя одну основную (базовую) таблицу и связанные с ней отношением N-1 словари. На диаграмме можно указать необходимость открытия просмотрового окна (формы Look Up) для организация поиска значений в соответствующем словаре.
Структурные схемы программ - универсальное средство описания функциональных возможностей приложения. Они позволяют описать любую программу с произвольной точностью (до функции, до группы операторов, до отдельного оператора, до отдельных составляющих оператора типа структуры AFTER FIELD в операторе INPUT). Основными элементами структурных схем являются заголовок или вызов функции, хэт-модуль (модуль со "шляпой", что соответствует используемому для него обозначению), позволяющий записать произвольные конструкции на языке программирования и указания относительно их размещения в программном файле (например, из любого хэт-модуля можно добавить определение еще одной переменной в секцию описания глобальных, модульных или локальных переменных, добавить в файл описание еще одной функции и т. п.), операторы выбора (MENU, IF, IF... ELSE, CASE), операторы повтора (WHILE, FOR) и библиотечные (предопределенные или стандартные модули), представляющие собой весьма мощный инструмент быстрой разработки приложений.
Диаграммы структуры данных и аналогичные им по нотации диаграммы структуры управляющих потоков могут использоваться для определения структуры и типов программных переменных, если вы предполагаете программирование всей или части системы на С.
А. В. Закис,руководитель аналитической группы DataX/FLORIN, Inc. Продолжение следует
Компьютерная газета. Статья была опубликована в номере 13 за 1997 год в рубрике программирование :: разное
