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

инфа о теории программирования

здравствуйте!!!

ищется сабж... а именно:
- "Типичные ошибки программного обеспечения: программные,
алгоритмические, системные, технические";
- "Задачи и этапы отладки программ";
- "Задачи сопровождения программ";
- "Неавтоматизированное и автоматизированное проектирование. Подходы к
проектированию программных продуктов";
- "Модульное программирование";
- "Функциональное программирование";
- "Приемы надежного программирования, организация программного
контроля";
- "Каналы утечки информации. Их классификация".

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

заранее спасибо...

PS извините, что не в ту конференцию, просто очень нужно... мошт кто
знает, или есть у кого... а надо очень...

Ответить   Mon, 6 Jun 2005 19:15:42 +0400 (#379702)

 

Ответы:

В сообщении от 1118074542 секунд после начала Эпохи Unix Вы написали:

А почему бы не написать от себя? Или от других... :)
Предлагаю всем желающим дополнить/изменить, ниже приведенный материал.

Алгоритмические ошибки: думал одно, написал другое; не предусмотрел все
возможные ситуации (например отрицательное значение величины).
Системные (систематические): постоянно путаю "U" и "E" на клавиатуре,
но компилятор часто мне об этом сообщает. Системные (ошибки операционной
системы): блин, програ нормальная, но у вас мало памяти или нет прав
доступа... Технические: отрубили электричество :).

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

Выпуск новых релизов (в том числе и устраняющих ошибки), тех.
поддержка, написание документации.

Ну это мне кажется чем том-то из ряда научной фантастики :)

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

Просто забываем про С++, Java и Python...

Спросите у ребят из Microsoft.

Любой канал, предназначенный для передачи информации, при
определенных условиях может стать каналом утечки информации. Условий
два:

1. Злоумышленник получил контроль над каналом.
2. Злоумышленник получил/передал информацию через этот канал.

Ответить   Konstantin Korikov Mon, 6 Jun 2005 20:41:13 +0300 (#379777)

 

написать-то мона... но если профессора енто не устроит??? им мля тока
теорию подавай... шоп научным языком и прочим геморроем...

ну это попробуем соврать профессору да преукрасить... смогем...

пасип...

а поподробнее, да как оно должно быт в теории, а не на практике...
теория и практика сильно расходятся... тем более в программинге...

фантастика-не фантастика, а отвечать надо...

это-т знаем, да как бы это растянуть на полчаса рассказа???

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

LOL... =)

алло!!! микрософт??? здрасте... у меня к вам вопросец...

ну про защиту информации ничего сложного... там "свой" профессор
будет... не 60-ти летний пердун, который сам не сможет программу
написать, но все-таки преподает программинг... вместе с ентим мы
нюками баловались в сетке... ;) свой товарисч... но все равно
спасибо...

огромное спасибо всем, кто помог бедному студенту... если кто еще
поможет, тож пасип... с меня 5х0.5 при встрече... =)

Ответить   Mon, 6 Jun 2005 23:35:00 +0400 (#379842)

 

В сообщении от 1118090100 секунд после начала Эпохи Unix Вы написали:

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

Меня не раз спасало умение навешать лапшу от себе, но по теме. Иногда,
имея недостаточные знания удавалось даже получить отлично. Думаю, не
стоит недооценивать себе. Сегодня ты студент, а кто знает, может завтра
станешь преподом. К тому же, разница между преподом и студентом только в
том, что первый официально зачислен на работу.

Ответить   Konstantin Korikov Wed, 8 Jun 2005 20:00:58 +0300 (#381176)

 

Немого с опозданием. Сам сейчас занят учебой.

В сообщении от 1118090100 секунд после начала Эпохи Unix Вы написали:

:) Я не теоретик, но попробую сочинить.

Выпуск релизов, которые несут только исправления ошибок, положительно
влияют на общую стабильность программного продукта. Сопроводитель может
даже сделать специальную нумерацию версий, например релизы с версиями
1.0, 2.0, 3.0, N.0 несут новые возможности (и, к сожалению, новые
ошибки), а релизы с версиями 1.1, 1.2, 1.3, 2.1, 2.2, 2.3, N.M, несут
только исправления ошибок. Таким образом пользователи могут
выбирать, в зависимости от их потребностей, между стабильными релизами,
но имеющими меньше возможностей, и нестабильными, но имеющими больше
возможностей.

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

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

Вот некоторые советы: в начале дать определение, отвечающее на вопрос
"Что же такое модульное программирование?"; после чего перечислить
достоинства, потом недостатки; потом описать способы реализации; можно
сделать выводы.

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

Я сам такой :)

Ответить   Konstantin Korikov Wed, 8 Jun 2005 19:32:21 +0300 (#381177)

 

Здравствуйте Konstantin Korikov
В сообщении от 6 Июнь 2005 21:41 Konstantin Korikov написал(a):

По опыту отладки чужих программ
- ошибки обращения к файлам (нет файла, который хочет считать программа,
или он есть, но нет к нему доступа (прав) )
- ошибки работы с сетью - например программа пытается воспользоваться
функцией gethostbyname, а такого hostname нет ни в DNS ни в /etc/hosts
- программа запрашивает шрифт, которого нет в системе.

Выдернули CD (датчик ....), к которому обращается программа, после чего
программа вылетела.

Это вам учебник 80-x годов надо - представьте что вы пишете на чистом
ассемблере, на бумаге, а с компьютером работает другой человек -
оператор или-же вы, но с компа вас в любой момент могут попросить :)
(я думаю точные определения и этапы были в лекции препода - это всё
достаточно субъективно). Попытаюсь сообразить что-нибудь
"наукообразное":

Задачей отладки программы является выявление и устранение ошибок
находящихся в её коде.

Этапы - представь что ты в работаешь в отладчике Borland С или Kdevelop

1 Изучение текста программы
2 Выявление веток, циклов и переходов программы
3 Составление примера входных данных программы, с тем что-бы
задействовать все ветки программы.
4 Проверка работы программы на этом примере.
5 В случае выявления ошибки, установка точек останова в точках, где
можно выявить ошибки (тут какую-нибудь теорию неплохо привести как эти
точки определять).

и т.д.
N Исправление ошибок, новый этап проверки и отладки.
Кстати у нас всегда при планировании написания программы (а если вы
помните, раньше у нас всё планировали). На написание программы давали
время, допустим, 1 месяц а на её отладку - 2 (важна пропорция).

Тут, как я понимаю - упор на исправление ошибок. (просто по духу
вопросов - новый релиз, это новый заказ).

CVS, Subversion (и анологичные в Windows).
Ключевое слово - автоматизированное, т.е. с участием компьютера (не
путать с автоматическим - без участия человека).

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

PS Четко помню, что где-то в середине 80-х годов, будучи студентом читал
я такую книжку.
PPS Да, забавное путешествие по времени :)

Ответить   Tue, 7 Jun 2005 08:04:54 +0400 (#379924)