Отправляет email-рассылки с помощью сервиса Sendsay

Технологии разработки программ

Рассылка закрыта

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Март 2000   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
29.03.2000
23:21:35
23:21:35
30
31
Автор Гость

Статистика

11.541 подписчиков
за неделю
←   Все выпуски   →

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


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

ПРОГРАММИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ

3-й выпуск (a - ваши письма)

Здравствуйте, уважаемые читатели!

Заранее поздравляю всех женщин и особенно моих подписчиц с замечательным праздником 8 Марта. Желаю вам всегда оставаться такими красивыми, обаятельными и привлекательными.

Слово ведущему рассылки

Количество подписчиков превысило 3000 человек, с чем можно вас и поздравить.

Как вы уже наверно заметили, рассылка носит название 3а. Это еще одна моя инновация.

Дело все в том, что я получаю от многих из вас очень интересные письма и мне очень жалко не довести их до глаз всех моих подписчиков. Поэтому теперь будут 2 выпуска в неделю (ну конечно же по мере накопления ваших писем): а- ваши письма и b- теория и практика. Соответственно, лишние рубрики из основного выпуска будут убраны.

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

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

ВАШИ ПИСЬМА

Письмо 1.

Я выражаю глубокую признательность Андрею Королеву (a-v-k@mail.ru), за его письма и, особенно, его мнения, которые стали неотъемлемой частью рассылки (у меня была даже мысль организовать такую рубрику ;-). Итак, Андрей о модульном программировании:

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

Как-то удалось подсмотреть процесс написания картины "из головы" художником-профессионалом. Он неторопливо набирал краску и (по моему впечатлению) хаотически наносил мазки на холст, но через некоторое время стала просматриваться картина, и тут я понял - он пишет картину целиком и знает место каждого мазка в ней. Представьте себе программиста, который напишет сначала все присваивания, потом - циклы и т.д. Бред. Мы обучены мыслить не образами, а понятиями. Или наоборот, человек образного восприятия мира не захочет заниматься написанием программ.

Что нам делать, чтобы представит целое? Правильно. Определить понятия в силу своей продвинутости в предметной области, их логические связи и укрупнено представить взаимодействие их в динамике. К чему мы пришли? К модулям. Значит, модульное программирование - технический прием представления в целом достаточно сложного объекта за счет введения ограничений на детализацию этого представления. Другими словами, если возможно уместить в голове программу в целом на уровне кода, то нет необходимости подниматься на уровень абстрагирования и применять модульное программирование.

Вывод: модульность программы - вопрос личного представления программиста о решаемой им проблеме в некоторой предметной области (отсюда несравнимость модульности).

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

Андрей Королев (a-v-k@mail.ru)

Письмо 2.

Следующее письмо я приведу с сокращениями и малыми изменениями (да простит меня автор !).

В свое время (около 11-15 лет назад) не существовало монополии конкретной операционной среды и, тем более, языка программирования. Существовало несколько десятков языков, порой принципиально различных, и их версий. В те годы было "модно" (а я бы сказал - "правильно") выбирать конкретный язык как средство реализации алгоритма решения какой-либо задачи. Т.е. программисты получали задачу, проектировали алгоритм решения, а потом выбирали язык реализации исходя из специфики задачи и возможностей языка и платформы.

Этот подход чуть было не вызвал к жизни целую науку, областью которой было создание научных методов и технологий проектирования и верификации алгоритмов и программ. Туда же входило и проектирование инструментальных средств. Концепция модульного программирования рассматривалась как естественное следствие применяемой технологии разработки и как средство, обеспечивающее возможность формального (!!!) доказательства правильности программ (т.е. соответствия программ спецификациям).

Модульная структура стала появляться в программах как средство облегчить жизнь программиста и естественно следовала из реализации методов "Сверху-вниз". Т.е. если изначально (на первом круге существования) концепция модульности должна была облегчить переносимость и модифицируемость программ, а также их коллективную разработку и возможность формальной (!!! - математическими методами) верификации, то потом, в эру PC, превратилась в инструмент ленивого программиста, который, используя модули, стал просто накапливать и переносить свой опыт в другие проекты.

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

Александр (aalx@euro.ru)

Письмо 3.

Это письмо без комментариев. Хотя один добавлю: ну очень интересное.

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

В частности, иногда стоит просто взять словарь и взвесить на слух...

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

Хотя по смыслу и реализации больше подходит наборная касса или игрушка LEGO. Т.е. у вас есть набор элементов с зацепками-связями и вы можете попытаться построить...

И вот здесь вы получаете результат настолько же близкий к решению вашей задачи, насколько с помощью LEGO вы можете изобразить реальный объект. Если вы хотите изобразить игрушечный домик или табуретку, то набора поставленных в ЯЩИКЕ элементов вам скорее всего хватит. Но если вы пожелаете изобразить действующую модель стиральной машины, то можете встать в тупик - в ЯЩИКЕ нет подходящих элементов и нет возможности из доступных в ЯЩИКЕ элементов и методов сформировать что-то подходящее.

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

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

С помощью Case-технологии выполнена действительно поставленная задача - снизить количество кодировщиков и связанные с ними проблемы и ошибки, отдав это на мощности и стандартные процедуры компьютеру. Честь и слава Case-средствам!

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

То же самое творится сейчас в информатике - с реляционными таблицами и SQL: научились работать и пока вычислительных средств с трудом хватало на хранение и обработку в лоб таких таблиц - все остальные информационные модели просто отбрасывались. А сейчас вылазит то, что и давно было ясно - нельзя, используя только квадраты, представлять окружности, сколько не увеличивай мощности - сложность взаимосвязей возрастает, а результат все равно не достигается, нужна другая основа представления информационной модели.

А все Case-средства пока никуда не ушли от SQL, поэтому и прорыва там не ожидается. То есть прорыв должен быть на другом уровне - Case - это инструмент сборки, а нужны новые элементы.

Сергей (shu@dimas.ru )

Ваши вопросы

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

1. Какими документами в настоящее время регламентируется вопрос о затратах в человеко-деньго-часах на создание программного продукта той или иной сложности.
Как мне сказали в Союзе были некоторые документы вроде СНИПы (санитарные нормы..... дальше не знаю) которые, как-то этот вопрос регулировали. А что есть сейчас, или хотя бы как назывались старые? Я для себя рассчитаю чего и как и попробую обосновать эту цифру перед руководством (от автора рассылки: интересно было бы узнать результат такого опыта).

2. Мы пишем программы на всем заимствованном. А есть ли какие либо ограничения на этот счет и какие документы регламентируют порядок создания и распространения программ, созданных на базе нелицензионных продуктов?

3. Помогите найти людей имеющих опыт работы с Designer2000 или хотя бы обладающих
документацией по нему.

Ответы присылайте мне (trbps@newmail.ru) с пометкой наши вопросы .

Ответы на ваши вопросы

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

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

Если кто из вас знает более подробно о данной проблеме, напишите пожалуйста мне.

??? Многие задают мне вопросы о том, что я буду рассматривать в рассылке. Отвечу просто: то, что вы меня спрашиваете, но только не сразу.

Сотрудничество

Жду от вас интересных писем, ссылок, материалов и ответов на ваши и мои вопросы.

Поиск

- Ищутся соавторы, авторы, практики и т.п. с целью оказания рассылке информационной поддержки.

- Ищется РЕКЛАМОДАТЕЛЬ. Пока всего 3050 подписчиков, но это тоже не мало, тем более, что это число постоянно увеличивается

С уважением, Сергей (trbps@newmail.ru, trbps@ok.ru )

http://www.citycat.ru/
E-mail: citycat@citycat.ru
В избранное