Рассылка закрыта
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
Доброе время суток, многоуважаемые читатели !
Слово ведущему
Очень рад, что число технологов прибавляется и прибавляется. Недавно, мы пересекли рубеж в 4000 человек и уже близки к 4500. Уважаемые новые подписчики, архив рассылки вы можете найти по адресу http://trbps.newmail.ru.
Хочу обратиться ко всем своим подписчикам. Практически у каждого из вас есть книга в электронном варианте, посвященная тематике рассылки (CASE, технологии программирования и прочее). Пытаясь создать полноценный сайт, посвященный технологиям программирования, обращаюсь к вам с просьбой поделится ими с остальными читателями. Сообщите мне, пожалуйста, о вашем желании на мой электронный адрес
trbps@newmail.ru.Как говорится: Родина вас не забудет !
И еще. Ищется ЛЮБАЯ литература по системному подходу для моделирования гипер-динамических систем.
ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ
Продолжаем обсуждение модульного программирования. Познакомившись в прошлом выпуске с теорией модульного программирования, многие из вас задают себе вопрос: а как это можно реализовать ? Действительно, сложно найти одинаковый подход в проектировании системы. Но все таки, я попытаюсь изложить вам уже сложившиеся методы проектирования модульной структуры программы.
Методы разработки структуры программы.
Как уже отмечалось раньше, в качестве модульной структуры программы принято использовать древовидную структуру, включая дерево со сросшими ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки) показывают статическую подчиненность модулей, т.е. каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит. Другими словами, каждый модуль может обращаться к подчиненным ему модулям, т.е. выражается через эти модули. При этом модульная структура программы, в конечном счете, должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит, во-первых, синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования правильное обращение к нему (к любому его входу), и, во-вторых, функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов).
В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода: метод восходящей разработки и метод нисходящей разработки.
Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. На первый взгляд такой порядок разработки программы кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется текстов используемых им модулей - для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе.
Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы (так называемые заглушки). Каждый имитатор модуля представляется весьма простым программным фрагментом, сигнализирующим, в основном, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров (иногда с их распечаткой) и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом большой объем "отладочного" программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами.
Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать.
В рассмотренных методах восходящей и нисходящей разработок (которые мы будем называть классическими) модульная древовидная структуру программы должна разрабатываться до начала программирования модулей. Однако такой подход вызывает ряд возражений: представляется сомнительным, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно. На самом деле это делать не обязательно: так при конструктивном и архитектурном подходах к разработке программ модульная структура формируется в процессе программирования модулей.
Конструктивный подход к разработке программы представляет собой модификацию нисходящей разработки, при которой модульная древовидная структура программы формируется в процессе программирования модуля. Сначала программируется головной модуль, исходя из спецификации программы в целом, причем спецификация программы является одновременно и спецификацией ее головного модуля, так как последний полностью берет на себя ответственнее за выполнение функций программы. В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются подзадачи (внутренние функции), в терминах которых программируется головной модуль. Это означает, что для каждой выделяемой подзадачи (функции) создается спецификация реализующего ее фрагмента программы, который в дальнейшем может быть представлен некоторым поддеревом модулей.
Архитектурный подход к разработке программы представляет собой модификацию восходящей разработки, при которой модульная структура программы формируется в процессе программирования модуля. Но при этом ставится существенно другая цель разработки: повышение уровня используемого языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, каждая из которых может использоваться при решении разных задач в создается в расчете на то, что при разработке той или иной программы заданной предметной области в рамках конструктивного подхода могут оказаться приемлемыми некоторые из этих модулей. Это позволяет существенно сократить трудозатраты на разработку конкретной программы путем подключения к ней заранее заготовленных и проверенных на практике модульных структур нижнего уровня. Так как такие структуры могут многократно использоваться.
Существуют и другие методы разработки программ, которые в основном являются модификациями представленных подходов. В настоящее время наиболее часто используется нисходящие проектирование и программирование, которое более подробно с примерами будет представлено в следующем выпуске.
CASE
Некоторые из вас обратили внимание на таблицу, опубликованную в прошлом выпуске. Мне хочется более детально рассмотреть ее. Приведу ее еще раз.
Таблица: Распределение трудозатрат по фазам жизненного цикла
|
Анализ |
Проектирование |
Кодирование |
Тестирование |
|
|
Традиционная разработка |
20% |
15% |
20% |
45% |
|
Структурная методология |
30% |
30% |
15% |
25% |
|
CASE |
40% |
40% |
5% |
15% |
Жизненный цикл программного обеспечения (ПО) - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Обычно жизненный цикл делится на фазы: анализ, проектирование, кодирование, тестирование и сопровождение. Каждая из этих фаз соответствует определенным работам, выполняемым группой программистов (одним программистом), и естественно требует затрат (временных, денежных, умственных и прочих).
Почему же с использованием CASE средств основные затраты приходятся на первые две фазы: анализ и проектирование ? Это связано с тем, что они, по своей сути, требует более творческого подхода. Так как именно на них реальную предметную область требуется превратить в набор неких абстракций, подлежащих программированию и в своей совокупности представляющих модель анализируемой области. Здесь очень сильно напрашивается тот художественный подход, приведенный в письме Андрея Королева (выпуск 3a).
Как-то удалось подсмотреть процесс написания картины "из головы" художником-профессионалом. Он неторопливо набирал краску и (по моему впечатлению) хаотически наносил мазки на холст, но через некоторое время стала просматриваться картина, и тут я понял - он пишет картину целиком и знает место каждого мазка в ней... Что нам делать, чтобы представит целое? Правильно. Определить понятия в силу своей продвинутости в предметной области, их логические связи и укрупнено представить взаимодействие их в динамике... Другими словами, если возможно уместить в голове программу в целом на уровне кода, то нет необходимости подниматься на уровень абстрагирования...
аналитик от кодера отличается тем же, чем художник отличается от маляра: первый покрывает стены фресками, второй стены покрывает краской. Магомед Магомедов (
ya-yuray@mtu-net.ru)А ведь действительно, нам - программистам - иногда очень сложно представить на глазок всю предметную область сразу, тут и приходят на помощь разные диаграммы, схемы и прочие вспомогательные зарисовки . И подчас мы понимаем, как много времени уходит на это.
..То есть при использовании дополнительного инструментария (например такого как CASE) мы приходим к естественному увеличению затрат. Тогда возникает закономерный вопрос: Значит теперь затраты на разработку программы больше ? А зачем мне это надо ? . На этой вопрос нет однозначного ответа. Мне кажется, именно на этот вопрос читатель хочет получить ответ от меня.
Однако, вместе с увеличением затрат, CASE позволяют вам облегчить жизнь самого аналитика (проектировщика), представляя предметную область в виде диаграмм и схем. Мало того, они позволяют автоматически генерировать код программы, генерировать документацию, проводить тестирование...
Но именно из-за этих однако снижается сложность анализа, проектирования, программирования, тестирования и сопровождения.
Ну вот, мы и закончили маленький анализ, казалось бы простой таблицы. Но в ней есть маленькие неточности, а именно то, что в связи с применением CASE средств меняется жизненный цикл программного обеспечения. Но это не означает, что меняется сама сущность разработки системы. Система проходит такие же фазы (анализ, проектирование...), но по элементам работ делится на этапы: прототипирование, проектирование спецификаций, контроль проекта, кодогенерация, системное тестирование и сопровождение. Это, так называемая, CASE-модель жизненного цикла.
ВОПРОСЫ ВЕДУЩЕГО
1. Знакомы ли вы с понятием жизненного цикла ПО ? Если да, то просматриваются ли его фазы в процессе разработки и сопровождения ваших программ ?
2. Вопрос к знатокам CASE. Могли бы вы привести альтернативную модель жизненного цикла CASE-проектирования ?
Ваши вопросы
1. Помогите найти людей имеющих опыт работы с Designer2000 или хотя бы обладающих документацией по нему.
2. Есть ли CASE средства для иерархических баз данных, или упоминания о нереализованных в софте методах или идеях проектирования для иерархических баз данных ?
3. Имеются ли примеры расчета трудозатрат (временных или денежных) на написание программ ?
Ответы на ваши вопросы
Вопрос:
Как получить авторское право на программу (систему) ? Где и что для этого нужно ? Какие документы регламентируют право на получения авторского права ?
Ответ: (прислал Тальгат Билалов talgat_b@mail.ru)
Авторское право возникает непосредственно в момент создания (написания) программы. Авторское право можно зарегистрировать. Регистрация программы производится Федеральным Институтом Промышленной Собственности.
Для регистрации нужны следующие документы:
1. Заявка на регистрацию программы на специальном бланке. В заявке указываются наименование
программы, автор(ы) и правообладатель. Автор и правообладатель не всегда одно и то
же лицо.
2. Реферат стандартной формы с кратким описанием программы, авторов и указанием средств
разработки. Средства разработки должны быть легально приобретенными и зарегистрированными
ранее.
3.Фрагменты текстов исходных кодов с ключевыми авторскими моментами. Не более 50
листов.
4.Документ об оплате регистрационного сбора, который составляет порядка 4 МРОТ (минимальный
размер оплаты труда). Плюс оплата, при желании, каждого авторского свидетельства,
в случае с несколькими авторами ( порядка 1 МРОТ за каждое). Плюс оплата, при желании,
публикации о регистрации в специальном бюллетене (порядка 1 МРОТ).
Процесс регистрации после подачи всех документов занимает порядка двух месяцев. Можно
воспользоваться ускоренной регистрацией (меньше месяца), но это стоит примерно в
два раза дороже.
После регистрации выдается свидетельство, которое можно повесить в рамочку :-)
Ссылки
http://pclub.da.ru На сервере имеется электронная версия книги Гради Буч Объектно-ориентированный анализ и проектирование (с примерами приложений на С++)", а также много полезных материалов для программистов.
Сотрудничество
Жду от вас интересных писем, ссылок, материалов и ответов на ваши и мои вопросы.
В рамках сотрудничества между авторами рассылок, посвященных программированию, предлагаю вам подписаться на рассылки:
Программируем на Visual Basic - рассылка посвящена практическим вопросам программирования на MVB.
Весь РУНЕТ на одной страничке - обзоры сайтов РУНЕТа (часто попадаются и ссылки на ресурсы по программированию).
| В избранное | ||