Загрузка...
Учебная работа. Реферат: Этапы разработки программного продукта 2
1.Кодирование программки.
Написание технического задания
Разработка программ начинается с постановки технического задания. От того, как грамотным и четким оно будет, почти во всем зависит продуктивный итог. Требования к будущему ПО должны быть кропотливо проанализированы и буквально сформулированы. На этом шаге основная задачка – собрать как можно больше инфы, для этого стоит пообщаться и с управлением, и с теми, кто будет конкретно воспользоваться софтом. Итогом этого шага обязано стать техническое задание, детально описывающее деяния программного продукта и ожидаемых от нее результатов.
Программирование — процесс и искусство сотворения компьютерных программ и/либо программного обеспечения при помощи языков программирования. Программирование соединяет внутри себя элементы искусства, базовых наук (до этого всего информатика и математика), инженерии, спорта и ремесла.
Кодирование программного обеспечения – фактически разработка программки либо написание кода программки. Применяемые технологии различны и у всякого спеца в данной для нас сфере есть свои предпочтения. На данном шаге осуществляется создание ПО с учетом выставленного технического задания.
Кодирование — процесс написания программного кода, скриптов, с целью реализации определённого метода на определённом языке программирования.
Некие путают такие понятия, как программирование и конкретно кодирование. Кодирование является только частью программирования, вместе с анализом, проектированием, компиляцией, тестированием и отладкой, сопровождением.
В узеньком смысле слова, программирование рассматривается как кодирование алгоритмов на данном языке программирования. Под программированием также может пониматься разработка логической схемы для программируемой логической интегральной схемы, также процесс записи инфы в ПЗУ. В наиболее широком смысле программирование — процесс сотворения программ, другими словами разработка программного обеспечения.
1.1. понятие кодировки и декодирования.
Внедрение электронно-вычислительных машин для переработки инфы явилось коренным шагом в совершенствовании систем планирования и управления на всех уровнях народного хозяйства. Но при всем этом, в отличие от обыденных методов сбора и обработки инфы, появились трудности преобразования инфы в знаки, понятные для машинки. Неотъемлемым элементом этого процесса является кодирование инфы. Кодом принято именовать совокупа знаков, соответственных элементам инфы либо ее чертам. Сам процесс составления кода в виде совокупы знаков либо перечня сокращений для соответственных частей и черт именуется кодировкой. В литературе термин код время от времени заменяется схожим ему термином шифр Цель кодировки заключается в том, чтоб представить информацию в наиболее малогабаритной и комфортной форме для оперирования при передаче и обработке инфы ; приспособить кодированную информацию к обработке на вычислительных устройствах ; обеспечить внедрение некого определенного способа поиска , сортировки и упорядочения инфы.
Принципная схема обработки инфы состоит из поиска, сортировки и упорядочения , в какой кодирование является частью операции ввода данных в виде входных кодов. В итоге обработки инфы получаются выходные коды, которые опосля их декодирования выдаются как итог проведенной обработке. Декодирование является операцией, оборотной кодированию. Если при кодировке происходит преобразование инфы в сигналы в виде определенного сочетания знаков , соответственных данному объекту либо его характеристике , то при декодировании , напротив , по данному коду определяется соответственный объект либо его признаки. К примеру, в телефонном справочнике указан код , т.е. номер телефона , связанный с неким элементом (лицом либо учреждением ). Операция декодирования состоит из набора кода номера телефона , который в виде сигналов поступает в АТС , где декодируется при помощи электронной схемы.
1.2. процесс кодировки.
Процесс кодировки инфы может выполняться или ручным , или автоматическим методом. При ручном , неавтоматическом методе кодировки вручную отыскивается подходящий код в за ранее составленном каталоге кодов и записывается в документе в виде цифровых либо алфавитно-цифровых знаков. Потом документ поступает в вычислительный центр , где оператор при помощи клавишного устройства перфорирует записанную информацию на перфокарте либо перфоленте. Потом перфокарты либо перфоленты вводятся в ЭВМ , информация кодируется в машинный (двоичный) код. Таковым образом информация два раза кодируется вручную : при записи ее на документ и при переноски данных на машинные носители. При автоматическом методе кодировки человек производит запись на естественном языке в виде слов, цифр и принятых обозначений в документе , который читается особым автоматом. Этот автомат за ранее шифрует документ и записывает все данные на магнитную ленту в двойном коде. Лента потом вводится в ЭВМ , где информация при помощи “машинного словаря “ опять кодируется в наиболее маленький машинный код, удачный для ее поиска, сортировки и обработки. Ввод инфы в ЭВМ в виде буквенно-цифрового текста на естественном языке и кодировке в машине просит хранения в памяти ЭВМ словаря, в каком любому слову соответствует определенный код.По этому словарю машинка сама шифрует текст. При всем этом отпадает необходимость в систематизации и кодировке инфы по ее смысловому содержанию, потому что котируются сами слова, выражающие определенные свойства предметов. Огромное обилие технических черт и остальных данных, относящихся к производству и потреблению бессчетных видов продукции, не дозволяет включить все нужные данные для их производства в код продукции, потому что этот код содержал бы огромное число знаков. Потому задачка кодировки продукции состоит в том, чтоб иметь может быть наиболее маленький код, по которому в памяти машинки можно было бы отыскать подробную информацию о всех нужных данных, относящихся к любому изделию. Таковым кодом является главный код.
Для всякого главного кода в памяти ЭВМ должен храниться массив данных, которые извлекаются из памяти и употребляются для решения разных задач. Этот массив инфы должен быть единым для всех решаемых задач, к примеру каталогом продукции, где в одном месте хранятся все нужные данные о любом предмете. Разделение его на ряд отдельных массивов, записанных, к примеру, на разных участках магнитной ленты, нецелесообразно, потому что это привело бы к повторению одной и той же инфы и повышению размера хранимой инфы. Основное требование к главному коду — конкретный поиск ЭВМ признаков, относящихся к данному предмету, для которого главный код является адресом. Главный код быть может просто порядковым регистрационным номером и не нести какой-нибудь определенной инфы о продукции либо, напротив, быть может построен по определенной системе систематизации и содержать определенную информацию о главных признаках продукции, полностью ее определяющих. 2-ой метод кодировки наиболее эффективен, потому что регистрационный код не дает способности выполнить подготовительную сортировку инфы по ее содержанию. Главный код дозволяет создавать сортировку карточек продукции по основным определяющим признакам. Детальная спецификация и ее другие свойства находятся в за ранее отсортированных карточках.
1.3. Виды кодов.
Код , знаки которого соответствуют определенным предметам либо чертам , именуется прямым кодом . Если код конкретно не содержит информацию о предмете либо его признаках , а представляет адресок , указывающий положение инфы , где содержится нужные сведения , то он именуется адресным кодом. Адресный код применяется для сокращения кода и резвого поиска огромных массивов инфы. За единицу количества инфы принимается 1 бит, т.е. один двоичный разряд (0 либо 1). Буковкы, десятичные числа и остальные знаки снутри ЭВМ представляются в виде групп двоичных разрядов. Операция представления их в таком виде именуется двоичным кодировкой. Группа из n двоичных чисел дозволяет закодировать 2n разных знаков. Таковая группа именуется б.
Наиболее большой единицей информацией является машинное слово , представляющее собой последовательность знаков , занимающих одну ячейку в памяти машинки. Зависимо от ЭВМ машинного слова может колебаться в границах— от 16 до 64 двоичных разрядов. машинное слово быть может командой , числом либо буквенно-цифровой последовательностью. Обычно машинное слово употребляется как единое целое в ЭВМ , хотя на неких машинках допускается обработка частей машинного слова. Массив инфы, содержащий 1024 машинных слова , именуется страничкой. Любой отдельный блок памяти содержит обычно 16 и наиболее страничек. Положение (адресок) слова в памяти определяется кодом адреса, содержащим номер блока, странички и номера слова в данной для нас страничке. Для упорядочения инфы о огромном количестве объектов , также для облегчения их поиска и сортировки по данным признакам либо чертам применяется систематизация этого огромного количества.
Систематизация—это условное разбиение огромного количества на ряд классов , подклассов и остальных группировок по принятой системе счисления и по данным признакам и чертам.
Классификационный код—это таковой код , в каком отдельными знаками либо группой знаков представлен любой из классифицируемых признаков либо любая определенная черта предмета. структура и число знаков классификационного кода полностью определяется принятой систематизацией огромного количества , которая , в свою очередь , зависит от поставленных целей и задач. В классификационном коде любой знак заключает внутри себя определенную информацию о определенном признаке либо характеристике предмета. В отличии от этого порядковый ,либо регистрационный код , содержащий присвоенный данному предмету порядковый номер при его регистрации без учета его признаков и черт , может служить лишь адресом для поиска местоположения инфы о данном предмете. В почти всех вариантах используются смешанные коды , в каких имеется как классификационная часть , так и порядковые номера для перечня классифицируемых предметов огромного количества.
2. Тестирование.
наличие ошибок – обычное явление, настоящую рабочую программку нереально сделать безошибочно с первой пробы. Во время тестирования более важны: умение тестировщика отыскать в программке слабенькие места и умение программера поправить неверную часть кода, не затронув при всем этом рабочие участки. Более принципиальные участки неоднократно проверяются разными способами.
одной из самых запущенных тем в правилах сохранности, касающихся разработки программного обеспечения, является тема тестирования и документирования. Это весьма принципиальные составляющие разработки программного обеспечения, которые затрагивают и вопросцы сохранности. программка полного тестирования может посодействовать найти трудности до того, как они проявят себя в эксплуатируемом программном продукте. Не считая того, соответственная документация нужна тем, кто проводит тестирование, чтоб было понятно, что необходимо инспектировать. Потому, такие правила должны начинаться с требований по тестированию и документированию. Формулировка может смотреться последующим образом.
Все собственные разработки должны быть протестированы и задокументированы перед сдачей их в промышленную эксплуатацию.
Принципиально отметить, что эта формулировка устанавливает требование, но не тип тестирования либо формат документации. Данное предложение нужно включить в правила для всего программного обеспечения и в процедуры.
2.1.Тестирование программного обеспечения.
Почти все организации, специализирующиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, растрачивают на тестирование, что составляет млрд баксов по всему миру в целом. И все таки, невзирая на большенные финансовложения, познаний о сущности тестирования очевидно не хватает и большая часть программных товаров неприемлемо ненадежно даже опосля «основательного тестирования».
О состоянии дел лучше всего свидетельствует тот факт, что большая часть людей, работающих в области обработки данных, даже не может верно найти слово «тестирование», и это по сути основная причина неудач.
«Тестирование — процесс, подтверждающий корректность программки и демонстрирующий, что ошибок в программке нет.» Главный недочет подобного определения состоит в том, что оно совсем некорректно; практически это практически определение антонима слова «тестирование». Читатель с неким опытом программирования уже, возможно, осознает, что нереально показать отсутствие ошибок в программке. Потому определение обрисовывает неосуществимую задачку, а потому что тестирование часто все таки производится с фуррором, по последней мере с неким фуррором, то такое определение логически неправильно. Правильное определение тестирования таково: Тестирование — процесс выполнения программки с намерением отыскать ошибки.
Нереально гарантировать отсутствие ошибок в нетривиальной программке; в наилучшем случае можно попробовать показать наличие ошибок. Если программка верно ведет себя для приличного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно только утверждать, что не понятно, когда эта программка не работает. естественно, если есть предпосылки считать данный набор тестов способным с большенный вероятностью найти все вероятные ошибки, то можно гласить о неком уровне убежденности в корректности программки, устанавливаемом этими тестами.
Психические опыты демонстрируют, что большая часть людей, поставив цель (к примеру, показать, что ошибок нет), ориентируется в собственной деятель на достижение данной для нас цели. Тестовик подсознательно не дозволит для себя действовать против цели, т. е. приготовить тест, который выявил бы одну из оставшихся в программке ошибок. Так как мы все признаем, что совершенство в проектировании и кодировке хоть какой программки недостижимо и потому любая программка содержит некое количество ошибок, самым плодотворным применением тестирования будет отыскать некие из их. Если мы желаем достигнуть этого и избежать психического барьера, мешающего нам действовать против поставленной цели, наша цель обязана состоять в том, чтоб отыскать как можно больше ошибок. Сформулируем основополагающий вывод:
Если ваша цель — показать отсутствие ошибок, вы. их отыщите не очень много. Если же ваша цель — показать наличие ошибок, вы отыщите значительную их часть.
Надежность нереально внести в программку в итоге тестирования, она определяется корректностью шагов проектирования. Лучшее решение трудности надежности — с самого начала не допускать ошибок в программке. Но возможность того, что получится идеально спроектировать огромную программку, нескончаемо мала. Роль тестирования состоит как раз в том, чтоб найти местопребывание малочисленных ошибок, оставшихся в отлично спроектированной программке. Пробы при помощи тестирования достигнуть надежности плохо спроектированной программки совсем бесплодны.
Тестирование оказывается достаточно необыкновенным действием (вот почему оно и считается сложным), потому что этот процесс разрушительный. Ведь цель проверяющего— вынудить программку сбиться. Он доволен, если это ему удается; если же программка на его тесте не сбивается, он не удовлетворен.
Еще одна причина, по которой тяжело гласить о тестировании — это тот факт, что о нем понятно весьма малое. Если сейчас мы располагаем 5% тех знании о проектировании и фактически программировании (кодировке), которые будут у нас к 2000 г., то о тестировании нам понятно наименее 1%
2.2. Главные определения.
Хотя в тестировании можно выделить несколько разных действий, такие определения, как тестирование, отладка, подтверждение, контроль и испытание, нередко употребляются как синонимы и, к огорчению, для различных людей имеют различный смысл. Хотя обычных, принятых определений этих определений нет, попытка сконструировать их была предпринята на симпозиуме по тестированию программ. Нашу систематизацию разных форм тестирования мы начнем с того, что дадим эти определения, слегка их дополнив и расширив их перечень.
Тестирование (testing), как мы уже узнали,—процесс выполнения программки (либо части программки) с намерением (либо целью) отыскать ошибки.
подтверждение (proof) — попытка отыскать ошибки в программке безотносительно к наружной для программки среде. Большая часть способов подтверждения подразумевает формулировку утверждений о поведении программки и потом вывод и подтверждение математических теорем о корректности программки. Подтверждения могут рассматриваться как форма тестирования, хотя они и не подразумевают прямого выполнения программки. Почти все исследователи считают подтверждение кандидатурой тестированию — взор почти во всем неверный; наиболее тщательно это дискуссируется в гл. 17.
Контроль (verification) — попытка отыскать ошибки, выполняя программку в испытательной, либо моделируемой, среде.
Испытание (validation) — попытка отыскать ошибки, выполняя программку в данной настоящей среде.
Аттестация (certification) — знатное доказательство корректности программки, аналогичное аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации производится сопоставление с неким заблаговременно определенным эталоном.
Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» нередко употребляются как синонимы, под ними предполагаются различные виды деятель. Тестирование — деятельность, направленная на обнаружение ошибок; отладка ориентирована на установление четкой природы извесной ошибки, а потом — на исправление данной для нас ошибки. Эти два вида деятель соединены — результаты тестирования являются начальными данными для отладки.
Тестирование модуля, либо автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех других модулей). Тестирование модуля время от времени включает также математическое подтверждение.
Тестирование сопряжении (integration testing) — контроль сопряжении меж частями системы (модулями, компонентами, подcистемами).
Тестирование наружных функций (external function testing) — контроль наружного поведения системы, определенного наружными спецификациями.
Всеохватывающее тестирование (system testing) — контроль и/либо испытание системы по отношению к начальным целям. Всеохватывающее тестирование является действием контроля, если оно производится в моделируемой среде, и действием тесты, если производится в среде настоящей, актуальной.
Тестирование приемлемости (acceptance testing) — проверка соответствия программки требованиям юзера.
Тестирование опции (installation testing) — проверка соотетствия всякого определенного варианта установки системы с целью выявить любые ошибки, возникшие в процессе опции системы.
Дела меж этими типами тестов и проектной документацией, на которой основывается тест.
2.3. Философия тестирования
Тестирование программного обеспечения обхватывает целый ряд видов деятель, очень аналогичный последовательности действий разработки программного обеспечения. Сюда входят постановка задачки для теста, проектирование, написание тестов, тестирование тестов и, в конце концов, выполнение тестов и исследование результатов тестирования. Решающую роль играет проектирование теста. Вероятен целый диапазон подходов к выработке философии, либо стратегии проектирования тестов, изображенный на рис.2. Чтоб ориентироваться в стратегиях проектирования тестов, стоит разглядеть два последних подхода, находящихся на границах диапазона. Необходимо подчеркнуть также, что почти все из тех, кто работает в данной для нас области, нередко бросаются в одну либо другую крайность.
Приверженец (либо сторонница) подхода, соответственного левой границе диапазона, проектирует свои испытания, исследуя наружные спецификации либо спецификации сопряжения программки либо модуля, которые он тестирует. Программку он разглядывает как темный ящик. Позиция его такая: «Меня не интересует, как смотрится эта программка и выполнил ли я все команды либо все пути. Я буду удовлетворен, если программка будет вести себя так, как обозначено в спецификациях». Его эталон — проверить все вероятные композиции и значения на входе.
Сторонник подхода, соответственного другому концу диапазона, проектирует свои испытания, изучая логику программки. Он начинает с того, что стремится приготовить достаточное число тестов для того, чтоб любая команда была выполнена по последней мере один раз. Если он незначительно наиболее искушен, то проектирует испытания так, чтоб любая команда условного перехода производилась в любом направлении хотя бы раз. Его эталон — проверить любой путь, каждую ветвь метода. При всем этом его совершенно (либо практически совершенно) не заинтересовывают спецификации.
Ни одна из этих крайностей не является неплохой стратегией. Читатель, но, уже, возможно, увидел, что 1-ая из их, а конкретно та, в согласовании с которой программка рассматривается как темный ящик, предпочтительней. К огорчению, она мучается тем недочетом, что совсем невыполнима. Разглядим попытку тестирования очевидной программки, получающей на входе три числа и вычисляющей их среднее арифметическое. Тестирование данной для нас программки для всех значений входных данных нереально. Даже для машинки с относительно низкой точностью вычислений количество тестов исчислялось бы млрд. Даже имей мы вычислительную мощность, достаточную для выполнения всех тестов в разумное время, мы издержали бы на несколько порядков больше времени для того, чтоб эти испытания приготовить, а потом проверить. Такие программки, как системы настоящего времени, операционные системы и программки управления данными, которые сохраняют «память» о прошлых входных данных, еще ужаснее. Нам потребовалось бы тестировать программку не только лишь для всякого входного значения, да и для каждой последовательности, каждой композиции входных данных. Потому исчерпающее тестирование для всех входных данных хоть какой разумной программки невыполнимо.
Эти рассуждения приводят ко второму базовому принципу тестирования: тестирование — неувязка в значимой степени финансовая. Так как исчерпающее тестирование нереально, мы должны ограничиться кое-чем наименьшим. Любой тест должен давать наивысшую отдачу по сопоставлению с нашими затратами. Эта отдача измеряется вероятностью тою, что тест выявит не обнаруженную до этого ошибку. Издержки измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Считая, что Издержки ограничены бюджетом и графиком, можно утверждать, что Искусство тестирования, по существу, представляет собой Искусство отбора тестов с наибольшей отдачей. Наиболее того, любой тест должен быть представителем некого класса входных значений, так чтоб его правильное выполнение создавало у нас некую убежденность в том, что для определенного класса входных данных программка будет производиться верно. Это обычно просит некого познания метода и структуры программки, и мы, таковым образом, смещаемся к правому концу диапазона.
2.4 Интеграция модулей.
Вторым по значимости нюансом тестирования (опосля проектирования тестов) является последовательность слияния всех модулей в систему либо программку. Эта сторона вопросца обычно не получает достаточного внимания и нередко рассматривается очень поздно. Выбор данной для нас последовательности, но, является одним из самых актуально принципиальных решении, принимаемых на шаге тестирования, так как он описывает форму, в какой записываются испытания, типы нужных инструментов тестирования, последовательность программирования модулей, также тщательность и экономичность всего шага тестирования. По данной для нас причине такое решение обязано приниматься на уровне проекта в целом и на довольно ранешней его стадии.
Имеется большенный выбор вероятных подходов, которые могут быть применены для слияния модулей в наиболее большие единицы. В большинстве собственном они могут рассматриваться как варианты 6 главных подходов, обрисованных в последующих 6 разделах. сходу же за ними идет раздел, где предложенные подходы сравниваются по их воздействию на надежность программного обеспечения.
2.1.1. Восходящее тестирование.
При восходящем подходе программка собирается и тестируется снизу ввысь. Лишь модули самого нижнего уровня («терминальные» модули; модули, не вызывающие остальных модулей) тестируются изолированно, автономно. Опосля того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов интегрированной функции языка либо оператор присваивания. Потом тестируются модули, конкретно вызывающие уже испытанные. Эти модули наиболее высочайшего уровня тестируются не автономно, а вкупе с уже испытанными модулями наиболее низкого уровня. процесс повторяется до того времени, пока не будет достигнута верхушка. тут заканчиваются и тестирование модулей, и тестирование сопряжении программки.
При восходящем тестировании для всякого модуля нужен драйвер: необходимо подавать испытания в согласовании с сопряжением тестируемого модуля. Одно из вероятных решении — написать для всякого модуля маленькую ведомую программку. Тестовые данные представляются как «интегрированные» конкретно в эту программку переменные и структуры данных, и она неоднократно вызывает тестируемый модуль, с каждым вызовом передавая ему новейшие тестовые данные. Имеется и наилучшее решение: пользоваться программкой тестирования модулей — это инструмент тестирования, позволяющий обрисовывать испытания на особом языке и избавляющий от необходимости писать драйверы.
2.1.2. Нисходящее тестирование.
Нисходящее тестирование (называемое также нисходящей разработкой не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое, При нисходящем подходе программка собирается и тестируется сверху вниз. Изолировано тестируется лишь головной модуль. Опосля того как тестирование этого модуля завершено, с ним соединяются (к примеру, редактором связей) один за иным модули, конкретно вызываемые им, и тестируется приобретенная композиция. процесс повторяется до того времени, пока не будут собраны и испытаны все модули.
При всем этом подходе немедля возникает два вопросца: что созодать, когда тестируемый модуль вызывает модуль наиболее низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на 1-ый вопросец заключается в том, что для имитации функций недостающих модулей программируются модули-заглушки», которые моделируют функции отсутствующих модулей. Фраза «просто напишите заглушку» нередко встречается в описании этого подхода, но она способна ввести в заблуждение, так как задачка написания заглушки» может оказаться трудной. Ведь заглушка изредка сводится просто к оператору RETURN, так как вызывающий модуль обычно ждет от нее выходных характеристик. В таковых вариантах в заглушку встраивают фиксированные выходные данные, которые она постоянно и возвращает. Это время от времени оказывается неприемлемым, потому что вызывающий модуль может рассчитывать, что итог вызова зависит от входных данных. Потому в неких вариантах заглушка обязана быть достаточно утонченной, приближаясь по трудности к модулю, который она пробует моделировать.
Увлекателен и 2-ой вопросец: в которой форме готовятся тестовые данные и как они передаются программке? Если б головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост:
Испытания пишутся в виде обыденных для юзеров наружных данных и передаются программке через выделенные ей устройства ввода. Так, но, случается изредка. В отлично спроектированной программке физические операции ввода-вывода производятся на нижних уровнях структуры, так как физический ввод-вывод — абстракция достаточно низкого уровня. Потому для того, чтоб решить делему экономически отлично, модули добавляются не в строго нисходящей последовательности (все модули 1-го горизонтального уровня, потом модули последующего уровня), а таковым образом, чтоб обеспечить функционирование операций физического ввода-вывода как можно резвее. Когда эта цель достигнута, нисходящее тестирование получает существенное преимущество: все последующие испытания готовятся в той же форме, которая рассчитана на юзера.
Остается еще один вопросец: в которой форме пишутся испытания до того времени, пока не будет достигнута эта цель? Ответ: они врубаются в некие из заглушек.
Нисходящий способ имеет как плюсы, так и недочеты по сопоставлению с восходящим. Самое существенное достоинство — в том, что этот способ совмещает тестирование модуля, тестирование сопряжении и отчасти тестирование наружных функций. С сиим же соединено другое его достоинство — когда модули ввода-вывода уже подключены, испытания можно готовить в комфортном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения относительно осуществимости программки в целом либо если в проекте программки могут оказаться суровые недостатки.
Преимуществом нисходящего подхода весьма нередко считают отсутствие необходимости в драйверах; заместо драйверов для вас просто следует написать «заглушки». Как читатель на данный момент уже, возможно, осознает, это преимущество спорно.
Нисходящий способ тестирования имеет, к огорчению, некие недочеты. Главным из их является тот, что модуль изредка тестируется конкретно сходу опосля его подключения. Дело в том, что основательное тестирование неких модулей может востребовать очень утонченных заглушек. Программер нередко решает не растрачивать массу времени на их программирование, а заместо этого пишет обыкновенные заглушки и инспектирует только часть критерий в модуле. Он, естественно, собирается возвратиться и окончить тестирование рассматриваемого модуля позднее, когда уберет заглушки. Таковой план тестирования точно не наилучшее решение, так как о отложенных критериях нередко запамятывают.
2-ой узкий недочет нисходящего подхода заключается в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программки до того, как вся программка будет вполне спроектирована. Эта мысль на 1-ый взор кажется экономной, но обычно дело обстоит совершенно напротив. Большая часть опытнейших проектировщиков признает, что проектирование программки — процесс итеративный. Изредка 1-ый проект оказывается совершенным. Обычный стиль проектирования структуры программки подразумевает по окончании проектирования нижних уровней возвратиться вспять и подправить верхний уровень, внеся в него некие усовершенствования либо исправляя ошибки, или время от времени даже выкинуть проект и начать все поначалу, поэтому что разраб в один момент узрел наилучший подход. Если же головная ) часть программки уже запрограммирована и оттестирована, то возникает суровое сопротивление хоть каким улучшениям ее структуры. В итоге за счет таковых улучшений обычно можно сберечь больше, чем те некоторое количество дней либо недель, которые рассчитывает выиграть проектировщик, приступая к программированию очень рано.
2.1.3. Измененный нисходящий способ
Нисходящий подход имеет еще один значимый недочет, касающийся полноты тестирования. Представим, что есть большая программка и кое-где поближе к нижнему ее уровню находится модуль, созданный для вычисления корней квадратного уравнения. Для данных входных переменных А, В и С он решает уравнение .
При проектировании и программировании модуля с таковой функцией постоянно следует осознавать, что квадратное уравнение может иметь как действительные, так и всеохватывающие корешки. Для полной реализации данной для нас функции нужно, чтоб результаты могли быть действительными либо всеохватывающими числами (либо, если доп Издержки на нахождение всеохватывающих корней не оправданы, модуль должен по последней мере возвращать код ошибки в случае, когда входные коэффициенты задают уравнение с всеохватывающими корнями). Представим, что определенный контекст, в каком употребляется модуль, исключает всеохватывающие корешки (т. е. вызывающие модули никогда не задают входных характеристик, которые привели бы к всеохватывающим корням). При строго нисходящем способе время от времени бывает нереально тестировать модуль для варианта всеохватывающих корней (либо тестировать неверные условия). Можно попробовать оправдывать это тем, что, так как такое уравнение никогда не будет дано модулю, никого не обязано заботить, работает ли он и в этих вариантах. Да, это индифферентно на данный момент, но окажется принципиальным в дальнейшем, когда кто-то попробует употреблять модуль в новейшей программке либо видоизменять старенькую программку так, что станут вероятными и всеохватывающие корешки.
Эта неувязка проявляется в различных формах. Применяя нисходящее тестирование в четком согласовании с предшествующим разделом, нередко нереально тестировать определенные логические условия, к примеру неверные ситуации либо защитные проверки. Нисходящий способ, не считая того, делает сложной либо совершенно неосуществимой проверку исключительных ситуаций в неком модуле, если программка работает с ним только в ограниченном контексте (это значит, что модуль никогда не получит довольно полный набор входных значений). Даже если тестирование таковой ситуации в принципе осуществимо, нередко бывает тяжело найти, какие конкретно необходимы испытания, если они вводятся в точке программки, удаленной от места проверки соответственного условия.
способ, именуемый измененным нисходящим подходом, решает эти трудности: требуется, чтоб любой модуль прошел автономное тестирование перед подключением к программке. Хотя это вправду решает все перечисленные трудности, тут требуются и драйверы, и заглушки для всякого модуля.
2.1.4. способ огромного скачка.
Возможно, самый всераспространенный подход к интеграции модулей — способ «огромного скачка». В согласовании с сиим способом любой модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сходу.
Способ огромного скачка по сопоставлению с иными подходами имеет много недочетов и не много плюсов. Заглушки и драйверы нужны для всякого модуля. Модули не интегрируются до самого крайнего момента, а это значит, что в течение долгого времени суровые ошибки в сопряжениях могут остаться необнаруженными. способ огромного скачка существенно усложняет отладку.
И все таки большенный скачок не постоянно нежелателен. Если программка мала и отлично спроектирована, он может оказаться применимым. Но для больших программ способ огромного скачка обычно пагубен.
2.1.5. Бета — тестирование программного обеспечения.
иной метод проверки, — бета-тестирование. В этом случае создатели программного обеспечения разрешают юзерам испытать подготовительные версии товаров. Но большая часть разрабов, с говорят, что наружные бета-тестеры не выявляют такового огромного количества ошибок.
Высококачественный и действенный итог можно гарантировать только лишь при ответственном и детализированном выполнение всякого из приведенных шагов.
3. Мало из теории справочных систем
3.1. Описание.
Справочная система программки, либо просто файл справки, предназначен для предоставлению юзеру программки полной и исчерпающей инфы, о том как работать с программкой и для чего же данный программный продукт нужен. Справочная система обязана удовлетворять последующим требованиям:
Давать полное описание по вопросцам использования программки.
Иметь графические материалы по вопросцам использования программки.
Быть доступной для вызова из хоть какой формы программки.
Иметь контекстные описания и комфортную систему поиска инфы.
Иметь мало вероятный размер.
Справочная система программного продукта пишется всей группой разрабов проекта. люди, отвечающие за информационное {наполнение} программки, пишут материалы о предназначении программного продукта, дают описание информационного заполнения и советы по использованию программки. Создатели программного кода, дают описание функций программки, предназначения частей интерфейса и способов конкретной работы. Также, программеры, создают сборку справочной системы и ее интеграцию в программку. Справочная система программки, проходит первичное тестирование. Целью первичного тестирования, является выявление недочетов, к которым относятся мертвые гиперпереходы в справочной системе, несоответствия описания — настоящим программным интерфейсам и дефицитность предложенной инфы, для работы с программкой неподготовленного юзера. Первичное тестирование, делается всей группой разрабов программного продукта. Делается совместное чтение материалов собранной справочной системы. Все вопросцы, предложения и замечания документируются. Потом следует общее обсуждение выявленных проблемных мест. Целью данного обсуждения, является определение перечня нужных исправлений в справочной системе.
Тестирование и принятие в эксплуатацию
Чтоб выявить все вероятные недоделки в программном обеспечении и нарушения требований сохранности, нужно создать управление по тестированию. Опосля того, как программное обеспечение прошло шаг тестирования, оно обязано быть принято в эксплуатацию (подписано управлением) и установлено в настоящей системе. Хотя эти процедуры и не относятся к правилам информационной сохранности, определенные детали могут быть отражены в правилах. В контексте информационной сохранности нужно выслеживать и предотвращать отказы в работе, вызванные тем, что в инсталлированном программном обеспечении имеются ошибки, либо оно может нежданно делать непредсказуемые операции.
Когда тестирование удачно завершено, в правилах следует зафиксировать, что нужно создать методику проведения установки новейшего программного обеспечения. Не имеет значения, доработанное ли это программное обеспечение либо оно является полностью новейшей разработкой: в методике нужно предугадать оповещение юзеров программного обеспечения о проведении установки, рабочую документацию и метод проведения повторной установки в случае появления каких-то заморочек. Все эти вопросцы можно выразить в 3-х маленьких формулировках правил.
Принятое опосля окончания тестирования программное обеспечение обязано быть снабжено методикой установки в настоящую систему. В методику следует включить процедуры по выгрузке из системы программного обеспечения, если это нужно.
установка не обязана проводиться без подготовительного извещения юзеров о том, что им нужно представить отчет о ошибках.
Принятое в эксплуатацию программное обеспечение не обязано инсталлироваться без соответственной рабочей документации.
Требования к документации
наличие документации — это не требование обеспечения сохранности. Документация нужна для осознания персоналом того, каким образом эксплуатировать систему и как работает сама система. Эта документация нужна будущим разрабам для исследования программных интерфейсов с целью найти, как эти интерфейсы должны работать в дальнейшем. Познание интерфейсов очень открывает сущность работы системы программного обеспечения, оно нужно при проведении анализа способности появления в системе заморочек и побочных эффектов, которые могут отразиться на информационной сохранности системы.
В документацию на систему обязана заходить не только лишь пользовательская документация. В согласовании с требованиями разрабам следует представить документацию на весь проект, на любой программный модуль и их интерфейсы. Таковым образом реально избежать дублирования в работе, также задокументировать заложенные в программное обеспечение функции управления, на которые распространяются требования сохранности. правило, в каком изложены эти советы, быть может таковым.
процесс разработки программного обеспечения должен включать разработку пользовательской и технической документации, в какой описано, как работает программное обеспечение, как им управлять, его входные и выходные данные, интерфейсы с системой и остальные составляющие, также применяемые средства обеспечения сохранности.
Внедрение и сопровождение разработанной программной системы
Во время внедрения ПО длится улучшаться интерфейс, в редчайших вариантах выявляются ошибки. Опосля того, как принято решение о том, что программный комплекс удачно внедрен осуществляется сопровождение. Во время сопровождения Компания, занимающаяся разработкой программ, вовремя усовершенствует программный продукт, обновляя его в согласовании с животрепещущими требованиями рынка и производства.
Согласованная работа на всех шагах – залог фуррора программного продукта. Хорошо составленное техническое задание, обеспечивающее спеца нужной для работы информацией, увеличивает эффективность работы в пару раз. Иммено потому, весьма принципиально чтоб любой из шагов производился проф разрабами. Профессионализм исполнителей — залог удачной реализации загаданного проекта.
Подмена версий и управление конфигурацией
Как было описано в прошлых разделах, опосля проведенного тестирования и сдачи программного обеспечения в эксплуатацию может показаться необходимость выгрузить из системы программное обеспечение; методами, обеспечивающими выгрузку программного обеспечения являются подмена версии либо управление конфигурацией. Исходя из убеждений сохранности, для внесения конфигураций в управление конфигурацией нужно знать саму конфигурацию системы и ее компонент. Зная, что обязано быть в системе и в сети, админы сумеют докладывать о нарушениях сохранности системы и искажениях в результатах работы программ в системе.
Некие положения управления конфигурацией повторены в правилах разработки программного обеспечения. Но не все. что подступает для системы, быть может позаимствовано из правил разработки программного обеспечения. Эти положения включены сюда, чтоб выделить их значимость для процесса разработки программного обеспечения, также для того, чтоб обеспечить сохранность установки операционной системы и даже разработанных ранее программных товаров. В правилах сохранности нужно регламентировать последующие виды работ: процедуры запроса на конфигурации, требования тестирования и процедуры установки. Эту программку можно утвердить при помощи последующей формулировки.
программка управления конфигурацией обязана быть составлена для поддержания конфигурации всех находящихся в эксплуатации систем, включая операционные системы, взятое программное обеспечение и средства обеспечения сохранности.
Процедуры запросов на подмену версий
Одним из главных моментов, отражающихся на сохранности, при подмене версий и управлении конфигурацией, является возможность выслеживать конфигурации. В случае появления заморочек админы, чтоб установить вызвавшую их причину, могут исследовать программное обеспечение системы и остальные установленные программные модули. Первым шагом для обеспечения трассировки системы обязана стать разработка правила, официально разрешающего изменение процедур управления для всех систем, находящихся в эксплуатации. В этом правиле предусматривается, что запросы на выполнение конфигураций в системе, а по мере необходимости и пересмотра правил сохранности, должны подаваться в письменном виде.
Для подмены версий и управления конфигурацией обязано быть официально разрешено изменение процедур управления для всех систем, находящихся в эксплуатации. Эти процедуры содержат в себе подачу письменных запросов на внесение конфигураций, сопровождение начальных модулей разработанного и сданного в эксплуатацию программного обеспечения, также проверку средств управления сохранностью.
В правилах не отражены ни определенные способы выполнения этих работ, ни программное обеспечение, которое быть может применено в работе. Снова напомним, что это относится к деталям реализации.
Управление конфигурацией и опции защиты
Считается неминуемым, что установленное программное обеспечение имеет ошибки. Некие из этих ошибок могут доставить проблемы в работе. Остальные могут отражаться на сохранности. Предметом споров меж спецами по защите и системными админами будет то, каким образом восстанавливать программное обеспечение, в каком обнаружены трудности с защитой. С одной стороны, нужно решить делему немедля, чтоб предупредить появление новейших заморочек. Но, установка патчей, даже переданных поставщиком, может привести к неожиданным результатам.
Большие организации располагают возможностью создавать полигоны, чтоб тестировать данные конфигурации перед установкой их в настоящую систему. Наиболее маленькие организации не могут дозволить для себя таковой роскоши и обязаны проводить патчи на настоящих системах. В любом случае, неважно какая организация может включить эти детали в процедуры и создать правила для таковых ситуаций. Формулировка правил может смотреться последующим образом.
В управление конфигурацией должны быть включены процедуры тестирования и установки исправленных средств защиты, приобретенных от разрабов и поставщиков.
Управление конфигурацией и обновление
В один прекрасный момент, работая в одной организации над таковыми правилами, управляющий задал вопрос у создателя книжки о том, как создать правила, которые принудят программистов переносить их обновления в исходники программ опосля обновления объектного пакета. Это был всепригодный магазин, где бесцеремонные программеры тестировали и обновляли исполняемые модули программ, не обновляя исходики. С появлением новейших заморочек создатели забывали о том, что были обновлены исполняемые модули программ, и, когда они вносили еще одно исправление в исходники, старенькые трудности появлялись опять.
Для почти всех организаций это не неувязка, так как у их работают бывалые спецы, которые не допустят такового подхода к работе. Так как неувязка является животрепещущей, в главном, для огромных вычислительных систем, нет смысла хлопотать о всепригодных правилах для решения данной для нас трудности в хоть какой организации. Чтоб в вашей организации такового не случилось, включите в правила ординарную формулировку.
Bсе обновления программного обеспечения своей разработки должны проводиться на исходниках программ, а не на сделанных на их базе исполняемых модулях.
Тестирование перед установкой
одна из угроз, подстерегающих того, кто управляет внесением конфигураций в программное обеспечение, состоит в том, что он может разрешить установку до того, как проведено тестирование. Тестирование помогает узнать, может ли программное обеспечение нормально работать в системе, и не покажутся ли новейшие трудности с сохранностью. Есть соблазн проводить патчи без подготовительного тестирования, в особенности патчи по сохранности, переданные поставщиком программного обеспечения.
Правилами обязано быть установлено требование проводить тестирование и обновление этих патчей независимо от того, поступают они от поставщика либо являются своей разработкой организации. Правила не должны регламентировать выполнение тестирования непременно на особых системах, но должны устанавливать условия тестирования Это дозволит организации с ограниченными ресурсами создать пригодную для ее системы методику тестирования. Не плохая общая формулировка правил смотрится последующим образом.
Все программное обеспечение обязано тестироваться и утверждаться перед его внедрением в производственной среде. Это правило распространяется как на программное обеспечение и обновления, предоставляемые поставщиком, так и на программное обеспечение и обновления, разработанные самой организацией.
Создание документации юзера
Документация на программное обеспечение — это документы, сопровождающие некое программное обеспечение (ПО ) — программку либо программный продукт. Эти документы обрисовывают то, как работает программка и/либо то, как её употреблять.
Документирование — это принципиальная часть в разработке программного обеспечения, но нередко ей уделяется недостаточно внимания.
Типы документации
Существует четыре главных типа документации на ПО :
строительная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть применены при разработке ПО
техно — документация на код, методы, интерфейсы, API
пользовательская — управления для конечных юзеров, админов системы и другого персонала
рекламная
Строительная/проектная документация
Проектная документация обычно обрисовывает продукт в общих чертах. Не описывая того, как что-либо будет употребляться, она быстрее отвечает на вопросец «почему конкретно так?» К примеру, в проектном документе программер может обрисовать обоснование того, почему структуры данных организованы конкретно таковым образом. Описываются предпосылки, почему какой-нибудь класс сконструирован определённым образом, выделяются паттерны, в неких вариантах даже даются идеи как можно будет выполнить улучшения в предстоящем. ничего из этого не заходит в техно либо пользовательскую документацию, но всё это вправду принципиально для проекта.
Техно документация
Это конкретно то, что предполагают под термином документация большая часть программистов. При разработке программки, 1-го только кода, обычно, недостаточно. должен быть предоставлен некий текст, описывающий разные нюансы того, что конкретно делает код. Таковая документация нередко врубается конкретно в начальный код либо предоставляется вкупе с ним.
Схожая документация имеет очень выраженный технических нрав и в главном употребляется для определения и описания API, структур данных и алгоритмов.
Нередко при составлении технической документации употребляются автоматические средства — генераторы документации, такие как Doxygen, javadoc, NDoc и остальные. Они получают информацию из особым образом оформленных объяснений в начальном коде, и делают справочные управления в каком-либо формате, к примеру, в виде текста либо HTML.
Внедрение генераторов документации и документирующих объяснений почти всеми программерами признаётся комфортным средством, по разным причинам. А именно, при таком подходе документация является частью начального кода, и одни и те же инструменты могут употребляться для сборки программки и одновременной сборки документации к ней. Это также упрощает поддержку документации в животрепещущем состоянии.
Пользовательская документация
В отличие от технической документации, сфокусированной на коде и том как он работает, пользовательская документация обрисовывает только то, как употреблять программку.
В случае, если продуктом является программная библиотека, пользовательская документация и документация на код стают весьма близкими, практически эквивалентными понятиями. Но в общем случае, это не так.
Обычно, пользовательская документация представляет из себя управление юзера, которое обрисовывает каждую функцию программки, также шаги, которые необходимо выполнить для использования данной для нас функции. Не плохая пользовательская документация идет ещё далее и предоставляет аннотации о том что созодать в случае появления заморочек. Весьма принципиально, чтоб документация не вводила в заблуждение и была животрепещущей. Управление обязано иметь чёткую структуру; весьма полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют огромное
Существует три подхода к организации пользовательской документации. Вводное управление (англ. tutorial), более полезное для новейших юзеров, поочередно проводит по ряду шагов, служащих для выполнения каких-то обычных задач. Направленный на определенную тематику подход, при котором любая глава управления посвящена некий отдельной теме, больше подступает для совершенствующихся юзеров. В крайнем, 3-ем подходе, команды либо задачки организованы в виде алфавитного справочника — нередко это отлично воспринимается продвинутыми юзерами, отлично знающими, что они отыскивают. Жалобы юзеров обычно относятся к тому, что документация обхватывает лишь один из этих подходов, и потому отлично подступает только для 1-го класса юзеров.
В почти всех вариантах создатели программного продукта ограничивают набор пользовательской документации только интегрированной системой помощи (англ. Online help), содержащей справочную информацию о командах либо пт меню. Работа по обучению новейших юзеров и поддержке совершенствующихся юзеров перекладывается на личных издателей, нередко оказывающих значительную помощь разрабам.
нужно располагать маркетинговые материалы, с тем чтоб заинтриговать людей, обратив их внимание на продукт. Таковая форма документации имеет целью:
подогреть Энтузиазм к продукту у возможных юзеров
информировать их о том, что конкретно делает продукт, с тем чтоб их ожидания совпадали с тем что они получат
разъяснить положение продукта по сопоставлению с конкурирующими решениями
одна из не плохих рекламных практик — предоставление слогана — обычный броской фразы, иллюстрирующей то, что мы желаем донести до юзера, также характеризующей чувство, которое создаёт продукт.
Нередко случается так, что коробка продукта и остальные рекламные материалы дают наиболее ясную картину о способностях и методах использования программки, чем всё остальное.
Метрика программного обеспечения (англ. software metric) — это мера, позволяющая получить численное
Так как количественные способы отлично зарекомендовали себя в остальных областях, почти все теоретики и практики информатики пробовали перенести данный подход и в разработку программного обеспечения. Как произнес Том ДеМарко, «вы не сможете надзирать то, что не сможете измерить».
Обобщённое программирование ( Шаблоны ) — парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно использовать к разным типам данных, не меняя само это описание. В том либо ином виде поддерживается различными языками программирования. способности обобщённого программирования в первый раз возникли в 70-х годах в языках CLU и Ada, а потом в почти всех объектно-ориентированных языках, таковых как C++, Java, Object Pascal[1], D и языках для платформы .NET.
Общий механизм
средства обобщённого программирования реализуются в языках программирования в виде тех либо других синтаксических средств, дающих возможность обрисовывать данные (типы данных) и методы (процедуры, функции, способы), параметризуемые типами данных. У функции либо типа данных очевидно описываются формальные параметры-типы. Это описание является обобщённым и в начальном виде конкретно применено быть не может.
В тех местах программки, где обобщённый тип либо функция употребляется, программер должен очевидно указать фактический параметр-тип, конкретизирующий описание. к примеру, обобщённая процедура перестановки местами 2-ух значений может иметь параметр-тип, определяющий тип значений, которые она меняет местами. Когда программеру необходимо поменять местами два целых значения, он вызывает функцию с параметром-типом «целое число» и 2-мя параметрами — целыми числами, когда две строчки — с параметром-типом «строчка» и 2-мя параметрами — строчками. В случае с данными программер может, к примеру, обрисовать обобщённый тип «перечень» с параметром-типом, определяющим тип хранимых в перечне значений. Тогда при описании настоящих списков программер должен указать обобщённый тип и параметр-тип, получая, таковым образом, хоть какой хотимый перечень при помощи 1-го и такого же описания.
Компилятор, встречая воззвание к обобщённому типу либо функции, делает нужные процедуры статического контроля типов, оценивает возможность данной конкретизации и при положительной оценке генерирует код, подставляя фактический параметр-тип на пространство формального параметра-типа в обобщённом описании. естественно, что для удачного использования обобщённых описаний фактические типы-параметры должны удовлетворять определённым условиям. Если обобщённая функция ассоциирует значения типа-параметра, хоть какой определенный тип, использованный в ней, должен поддерживать операции сопоставления, если присваивает значения типа-параметра переменным — определенный тип должен обеспечивать корректное присваивание.
Методы реализации
Понятно два главных метода реализации поддержки обобщённого программирования в компиляторе.
Порождение новейшего кода для каждой конкретизации. В этом варианте компилятор разглядывает обобщённое описание как текстовый шаблон для сотворения вариантов конкретизаций. Когда компилятору требуется новенькая способ обеспечивает наибольшее быстродействие, так как варианты конкретизаций стают различными фрагментами программки, любой из их быть может оптимизирован для собственного типа-параметра, к тому же в код не врубаются никакие излишние элементы, связанные с проверкой либо преобразованием типов на шаге выполнения программки. Недочетом его будет то, что при активном использовании обобщённых типов и функций с разными типами-параметрами размер откомпилированной программки может весьма очень возрастать, так как даже для тех фрагментов описания, которые для различных типов не различаются, компилятор всё равно генерирует отдельный код. Этот недочет можно затушевать путём частичной генерации общего кода (часть обобщённого описания, которая не зависит от типов-параметров, оформляется особым образом и по ней компилятор генерирует единый для всех конкретизаций код). Зато данный механизм даёт естественную возможность сотворения особых (обычно — очень вручную оптимизированных) конкретизаций обобщённых типов и функций для неких типов-параметров.
Порождение кода, который во время выполнения делает преобразование фактических параметров-типов к одному типу, с которым практически и работает. В этом случае на шаге компиляции программки компилятор только инспектирует соответствие типов и включает в код команды преобразования определенного типа-параметра к общему типу. Код, определяющий функционирование обобщённого типа либо функции, имеется в откомпилированной программке в единственном экземпляре, а преобразования и проверки типов производятся динамически, во время работы программки. В этом варианте порождается, как правило, наиболее малогабаритный код, но программка оказывается в среднем медлительнее, чем в первом варианте, из-за необходимости выполнения доп операций и наименьших способностей оптимизации. Не считая того, в компилированный код для типов-параметров далековато не постоянно врубается динамическая информация о типах (в первом варианте она есть, если совершенно поддерживается, так как конкретизации для всякого типа-параметра различны), что описывает некие ограничения на применение обобщённых типов и функций. Подобные ограничения есть, к примеру, в J
]]>