Рассылка закрыта
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
Служба Рассылок Городского Кота
ПРОГРАММИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ
4-й выпуск
Рад приветствовать своих старых и новых читателей !
Слово ведущему рассылки
Приношу извинения за задержку с выпуском. Были проблемы с доступом. На данный момент они закончились и я рад снова приступить к нормальному режиму работы.
Спасибо всем, кто присылает мне свои письма, к сожалению я чисто физически не могу на все отвечать, но читаю все ваши послания.
И другая новость. Как вы уже заметили рассылка сменила название на "Технологии разработки программ" (подтверждение получил только что, прямо перед отправкой выпуска вам, а вернее сказать во время этого увлекательного процесса). Теперь рассылка о "маслянном масле" стала более созвучной русскому языку.
Теперь маленькая новость. Открыт архив рассылки по адресу
http://trbps.newmail.ru. Я не веб-дизайнер, но вроде получилось неплохо. В стиле программ под DOS: маленький размер, никакой графики и неплохо смотрится. Если есть какие-нибудь предложения, замечания по оформлению и содержанию - пишите.И еще. Я решил нумеровать все выпуски подряд без букв и других символов. Так что этот выпуск некоторые могут считать 3b.
Технологии программирования
МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
В предыдущих выпусках были рассмотрены основные идеи модульного программирования, они были упомянуты мной, читателями, приславшими мне свои письма. Но все же они кажутся иногда противоречивыми, иногда слишком совершенными. А это значит, что пора разбираться в теории, чтобы понять как данный подход вам может облегчить жизнь. Итак, приступим.
Приступая к разработке каждой программы, следует иметь в виду, что она, как правило, является большой системой, и поэтому мы должны принять меры для ее упрощения. Для этого такую программу разбивают по частям, которые называют программными модулями.
Программный модуль это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса.
Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т
.е. как средство накопления и многократного использования программистских знаний).Не всякий программный модуль способствует упрощению программы. Для оценки приемлемости модуля используют некоторые критерии. Хольт предложил два общих критерия: хороший модуль снаружи проще, чем внутри; хороший модуль проще использовать, чем построить. Майерс предлагает использовать более конструктивные характеристики программного модуля для оценки его приемлемости: размер модуля, прочность модуля, сцепление с другими модулями, рутинность модуля.
Размер модуля измеряется числом содержащихся в нем операторов (строк). Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой структуре программы. Большие - неудобны для изучения и изменений
.Прочность модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести.
Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей.
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль называется рутинным, если результат (эффект) обращения к нему зависит только от значения его параметров. Использование модулей, хранящих предысторию, может привести к появлению в программе хитрых (неуловимых) ошибок.
В качестве модульной структуры программы принято использовать древовидную структуру, включая дерево со сросшими ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки) показывают статическую подчиненность модулей, то есть каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит. При этом модульная структура, в конечном счете, должна включать и совокупность спецификаций модулей, образующих эту программу.
Спецификация программного модуля содержит синтаксическую спецификацию его входов, позволяющую построить правильное обращение к нему (к любому его входу), и функциональную спецификацию модуля (описание семантики функций, выполняемых модулем по каждому из его входов).
В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы, что и будет темой следующего выпуска.
CASE
В последнее время сложилась своеобразная культура проектирования жизненного цикла компании, производства, деятельности. Естественно, в настоящих условиях такого рода проектирования производятся на базе компьютерных технологий. Примером такого рода является CASE-проетирование (Computer-Aided Software/System Engineering) - относительно новое направление в современных компьютерных технологиях. Эта область научного подхода к управлению бизнес-процессом настоящее время интенсивно развивается. Тем не менее, затруднительно дать точное общее определение CASE средств. По одному из определений, это совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддерживаемаякомплексом взаимосвязанных средств автоматизации. Постараемся в данной статье дать общее представление о CASE-технологиях.
Прежде всего, CASE не является следствием каких-либо революционных открытий. Базой CASE-развития стали методологии "классического" системного анализа.
Для программного обеспечения (ПО) основным является понятие жизненного цикла (ЖЦ), как правило, разбиваемого на этапы: анализ требований, проектирование, кодирование, тестирование и отладка, эксплуатация и сопровождение.
На разных этапах развития информационных технологий существовали различные модели жизненных циклов: каскадная (70-80годы) - переход на следующий этап после полного окончания работ по предыдущему, поэтапная с промежуточным контролем (80-85годы) - итерационная модель разработки ПО с циклами обратной связи между этапами. Современная - спиральная модель ориентированна на развитие и модификацию ПО в процессе его проектирования, посредством накопления и повторного использования программных средств, моделей, прототипов. Несомненным преимуществом данной модели является и анализ риска издержек в процессе проектирования. Очевидно, что в свете изложенного первые две модели уже становятся устаревшими и бесперспективными.
Таким образом, в этом случае наиболее важными этапами ЖЦ являются первые два этапа (анализ и проектирование).
При успешном прохождении этих этапов следующие не представляют особой сложности и, наоборот, неразрешенные или неучтенные вопросы, возникающие на данных этапах, способны привести к неразрешимым проблемам, вплоть до неудачи проекта в дальнейшем.
Остановимся кратко на особенностях Анализа и Проектирования.
Анализ требований
является первым этапом ЖЦ программного продукта. Этот этап должен решить ключевые для проекта вопросы -- Каковы требования, предъявляемые к системе
?- Каковы средства, предоставляемые системе для решения предоставленных задач?
Эти вопросы должны определить исходную архитектуру, интерфейс продукта, ограничения, налагаемые на ресурсы.
Проектирование
отвечает на вопрос "Как система будет удовлетворять предъявленным к ней требованиям?".Результатом этого этапа должен стать проект системы, содержащий достаточно информации для реализации системы на его основе в рамках бюджета выделенных ресурсов и времени.
Бурным развитием CASE системы обязаны тому, что изначально они ориентированны на применение именно в начале жизненного цикла.
В своем развитии CASE средства прошли два основных этапа.
На первом этапе CASE - технология, предназначенная для системных аналитиков и проектировщиков, не ориентированная на поддержку полного жизненного цикла. Она включает средства поддержки графических моделей, проектирования спецификаций, словарей данных.
CASE на втором этапе - отличается более развитыми возможностями и исчерпывающим подходом к жизненному циклу. Прежде всего, необходимо указать поддержку автоматической кодогенерации на различных языках третьего и четвертого поколений, обеспечивающая построение скелета продукта, доступного к ручной корректировке и дополнению. Также обеспечивается функциональная поддержка графических требований, спецификаций проектирования, информации по управлению проектом, анализа и связывания системной информации. Обеспечиваются средства тестирования, верификации, анализа сгенерированных программ и генерации документов по проекту.
При использовании CASE систем изменяется распределение трудозатрат по фазам ЖЦ (ниже приведена таблица сравнения трудозатрат)
Таблица 1.
Анализ |
Проектирование |
Кодирование |
Тестирование |
|
Традиционная разработка |
20% |
15% |
20% |
45% |
Структурная методология |
30% |
30% |
15% |
25% |
CASE |
40% |
40% |
5% |
15% |
Итак, при разработке с использованием CASE-систем основной объем работы распределен на начальные этапы ЖЦ, на которых важен творческий фактор. Использование CASE сводит к минимуму рутинную работу на этапе кодирования и значительно уменьшает время тестирования продукта - "Фактически CASE представляют собой новый тип графически ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО"
.По материалам статьи CASE-проектирование: необходимый инструмент в бизнес-проектировании? (к сожалению автор указан не был)
Вопросы ведущего
Какую модель жизненного цикла вы применяете при разработке программ (если применяете конечно) ?
Заключение
Наконец-то многие из вас смогли узнать, что такое CASE средство и как используется. Но нетрудно видеть, что у вас все равно встали новые вопросы, касающиеся использования новых понятий, с которыми большинство из вас мало сталкивалось: словари данных, верификация и другие. Надеюсь, дальнейшие выпуски помогут вам разобраться с этими и многими другими пока еще новыми для вас понятиями.
Ваши вопросы
На мой адрес пришло несколько интересных вопросов, касающихся разработки программных систем.
1. Какими документами в настоящее время регламентируется вопрос о затратах в человеко-деньго-часах
на создание программного продукта той или иной сложности.
Как мне сказали в Союзе были некоторые документы вроде СНИПы (санитарные нормы.....
дальше не знаю) которые, как-то этот вопрос регулировали. А что есть сейчас, или
хотя бы как назывались старые? Я для себя рассчитаю чего и как и попробую обосновать
эту цифру перед руководством (от автора рассылки: интересно было бы
узнать результат такого опыта).
2. Мы пишем программы на всем заимствованном. А есть ли какие либо ограничения на этот счет и какие документы регламентируют порядок создания и распространения программ, созданных на базе нелицензионных продуктов?
3. Помогите найти людей имеющих опыт работы с Designer2000 или хотя бы обладающих
документацией по нему.
4. Есть ли CASE средства для иерархических баз данных, или упоминания о нереализованных в софте методах или идеях проектирования для иерархических баз данных ?
5. Как получить авторское право на программу (систему) ? Где и что для этого нужно ? Какие документы регламентируют право на получения авторского права ?
Ответы присылайте мне (trbps@newmail.ru) с пометкой наши вопросы .
Ответы на ваши вопросы
1. Для оценки трудозатрат используется книга с наименованием "Тарифы на выполнение работ, услуг на предприятиях электронной промышленности" (за точность названия не ручаюсь), утвержденная каким-то министерством. Так там в качестве оценки трудоемкости работ было принято количество операторов и коэффициент сложности программы (шесть градаций). Я пользовался этой книгой для расчета стоимости разработки программного обеспечения встроенных систем. Объем ПЗУ, по предварительным оценкам, на 75% заполнялся кодом, количество байт кода делил на 4 - четыре байта на команду ассемблера (система команд PDP-11) - получал количество команд и умножал на коэффициент для разработки операционных систем (один из самых высоких), так как удалось доказать заказчику, что для него разрабатывается не модуль обработки данных (самый маленький коэффициент) - на этом заказчик вначале настаивал, а именно операционная система со своим языком общения с пользователем, диагностиками, драйверами и т.д. (a-v-k@mail.ru)
Ведущий рассылки:
В свою очередь хочется добавить, что сейчас используются различные методы оценки трудозатрат: по количеству строк кода, по сложности реализуемого алгоритма, по количеству реализуемых модулей (при коллективной работе) и даже по объему документации. Как видно, все эти способы носят бюрократический характер и их сложно использовать на начальном этапе работ.2. На второй вопрос в этой рассылке я могу ответить и сейчас, но не очень подробно: я не помню какие именно документы регламентируют данную проблему, но все же отвечу.
Если вы пишите программы на заказ и не хотите обладать авторским правом на нее, то никаких ограничений нет (кроме вашей совести и требований заказчика). В случае же, если вы будете регистрировать свою программу (на предмет авторского права или еще чего-то), то во-первых от вас потребуют соблюдение всех ГОСТов, во-вторых потребуют лицензию на программное обеспечение, использованное вами при написании программы.
Если кто из вас знает более подробно по данным проблемам, напишите пожалуйста мне.
Ссылки
http://www.interface.ru - Фирма Интерфейс занимается разработкой и продажей программного обеспечения. Одним из своих направлений она выбрала развитие CASE средств в России. На сервере компании вы сможете ознакомиться с ценами на различные CASE средства и найти большое число статей по данной тематике (включая даже описания конкретных систем). Здесь же вы сможете бесплатно (!) получить демо-версии некоторых программ.
Сотрудничество
Жду от вас интересных писем, ссылок, материалов и ответов на ваши и мои вопросы.
Поиск
- Ищутся соавторы, авторы, практики и т.п. с целью оказания рассылке информационной поддержки.
- Ищется РЕКЛАМОДАТЕЛЬ. Пока всего 3050 подписчиков, но это тоже не мало, тем более, что это число постоянно увеличивается
С уважением, Сергей (
trbps@newmail.ru, trbps@ok.ru )Архив рассылки доступен по адресу:
http://trbps.newmail.ru
http://www.citycat.ru/
E-mail: citycat@citycat.ru |
В избранное | ||