Векторное представление строк
Представление строк в виде векторов, принятое в большинстве универсальных языков программирования, позволяет работать со строками, размещенными в статической памяти. Кроме того, векторное представление позволяет легко обращаться к отдельным символам строки как к элементам вектора - по индексу.
Самым простым способом является представление строки в виде вектора постоянной длинны. При этом в памяти отводится фиксированное количество байт, в которые записываются символы строки. Если строка меньше отводимого под нее вектора, то лишние места заполняются пробелами, а если строка выходит за пределы вектора, то лишние (обычно справа строки) символы должны быть отброшены.
Элементы строки можно размещать в памяти произвольно, если каждый элемент снабдить явным указанием места, где находится следующий за ним элемент. В этом случае каждый элемент строки должен состоять из двух полей: в одном поле (Element) – символ сроки, в другом (Adrcled) – ссылка на следующий элемент строки (адрес следующего элемента).
Каждая такая пара называется звеном. Ссылки сцепляют звенья в одну
цепочку.
Вопрос № 2. Математические основы информатики. Математические модели. Конструктивное определение математических моделей.
Математическая модель — приближенное описание объекта моделирования, выраженное с помощью математической символики.
Математические модели появились вместе с математикой много веков назад. Огромный толчок развитию математического моделирования придало появление ЭВМ. Применение вычислительных машин позволило проанализировать и применить на практике многие математические модели, которые раньше не поддавались аналитическому исследованию. Реализованная на компьютере математическая модель называется компьютерной математической моделью, а проведение целенаправленных расчетов с помощью компьютерной модели называется вычислительным экспериментом.
Конструктивное описание
Математическая модель − это формальная система, представляющая собой конечное собрание символов и совершенно строгих правил оперирования этими символами в совокупности с интерпретацией свойств определенного объекта некоторыми отношениями, символами или константами.
Билет №12
Вопрос № 1. Недостатки файловой системы. Реляционные базы данных.
1. Структура записи файла известна только программе, в которой он создан. Изменение структуры требует изменения программ, использующих этот файл с данными. Таким образом, программы зависят от данных.
2. Проблемы с авторизацией доступа. Можно использовать средства ОС по разграничению доступа. Такое решение возможно, но неудобно. Нужны централизованные методы доступа к информации.
3. Проблемы с организацией многопользовательского доступа. Системы управления файлами обеспечивают многопользовательский режим, но имеют особенности, затрудняющие применение для БД. При чтении данных несколькими пользователя проблем не возникает. Внесение же изменений требует синхронизации действий пользователей. Обычно при открытии файла указывается режим (чтение/запись). Если к этому моменту файл открыт другим процессом в режиме изменения, то ОС либо сообщает, что файл невозможно открыть, либо действие блокируется до закрытия другого процесса. В любом случае либо одновременно несколько пользователей не могут модифицировать БД, либо процесс выполняется медленно.
Реляционная база данных — это совокупность взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного типа. Строка таблицы содержит данные об одном объекте (например, товаре, клиенте), а столбцы таблицы описывают различные характеристики этих объектов — атрибутов (например, наименование, код товара, сведения о клиенте). Записи, т. е. строки таблицы, имеют одинаковую структуру — они состоят из полей, хранящих атрибуты объекта. Каждое поле, т. е. столбец, описывает только одну характеристику объекта и имеет строго определенный тип данных. Все записи имеют одни и те же поля, только в них отображаются различные информационные свойства объекта.
В реляционной базе данных каждая таблица должна иметь первичный ключ — поле или комбинацию полей, которые единственным образом идентифицируют каждую строку таблицы. Если ключ состоит из нескольких полей, он называется составным. Ключ должен быть уникальным и однозначно определять запись. По значению ключа можно отыскать единственную запись. Ключи служат также для упорядочивания информации в БД.
Вопрос № 2. Абстрагирование, формализация. Данные как формализованная информация.
Абстрагирование - метод теоретического познания, заключающийся в мысленном отвлечении от несущественных свойств, связей, отношений предметов и одновременном выделении, фиксировании одной или нескольких интересующих исследователя сторон этих предметов.
Результат, получаемый в процессе абстрагирования - абстракция.
Формализация - метод теоретического познания, заключающийся в использовании специальной символики, позволяющей отвлечься от изучения реальных объектов, от содержания описывающих их теоретических положений и оперировать вместо этого некоторым множеством символов (знаков). Например, широко используемые в науке математические описания различных объектов, явлений.
Для построения любой формальной системы необходимо:
задать алфавит, то есть определенный набор знаков;
задать правила, по которым из исходных знаков этого алфавита могут быть получены "слова", "формулы";
задать правила, по которым от одних слов, формул данной системы можно переходить к другим словам и формулам.
Данные представляют собой информацию в формализованном виде (в цифровой форме), позволяющем автоматизировать её сбор, хранение и дальнейшую обработку в ЭВМ. С этой точки зрения информация является абстрактным понятием, рассматриваемым безотносительно к её семантическому аспекту, а под количеством информации обычно понимается соответствующий объём данных. Однако одни и те же данные могут быть закодированы различным образом и иметь при этом различный объём, поэтому иногда рассматривается также понятие "ценность информации", которое связано с понятием информационной энтропии и является предметом изучения теории информации.
Билет №13
Вопрос № 1. Методологии системного структурного анализа. Диаграммы потоков данных.
Имеющиеся методики системного анализа еще не получили достаточно убедительной классификации, которая была бы принята единогласно всеми специалистами. Например, Ю. И. Черняк делит методы системного исследования на четыре группы: неформальные, графические, количественные, и моделирование. Достаточно глубокий анализ методик различных авторов представлен в работах В.Н. Волковой, а также Ю.П. Сурмина.
В качестве простейшего варианта методики системного анализа можно рассматривать такую последовательность:
1) постановка задачи;
2) структуризация системы;
3) построение модели;
4) исследование модели.
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Состав диаграмм потоков данных
Основными компонентами диаграмм потоков данных являются:
• внешние сущности;
• системы и подсистемы;
• процессы;
• накопители данных;
• потоки данных.
Вопрос № 2. Определение системы, применяемое в теории управления и информатики.
Билет №14
Вопрос № 1. Информационно-поисковые системы.
Информационно-поисковая система (ИПС) — это cистема, обеспечивающая поиск и отбор необходимых данных в специальной базе с описаниями источников информации (индексе) на основе информационно-поискового языка и соответствующих правил поиска. Главной задачей любой ИПС является поиск информации релевантной информационным потребностям пользователя. Очень важно в результате проведенного поиска ничего не потерять, то есть найти все документы, относящиеся к запросу, и не найти ничего лишнего. Поэтому вводится качественная характеристика процедуры поиска — релевантность.
Релевантность — это соответствие результатов поиска сформулированному запросу.
Вопрос № 2. CASE –технологии, как средства автоматизации системного структурного анализа.
Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:
подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:
CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;
реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.
Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения. Можно перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:
широкое разнообразие качества и возможностей CASE-средств;
относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;
широкое разнообразие в практике внедрения различных организаций;
отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
широкий диапазон предметных областей проектов;
различная степень интеграции CASE-средств в различных проектах.
Вследствие этих сложностей доступная информация о реальных внедрениях крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.
Для успешного внедрения CASE-средств организация должна обладать следующими качествами:
Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;
Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;
Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.
Если организация не обладает хотя бы одним из перечисленных качеств, то внедрение CASE-средств может закончиться неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.
Для того, чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных "подводных камней" использования CASE-средств. Среди наиболее важных проблем выделяются следующие:
достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;
внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;
отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;
CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;
некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, при этом, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение;
негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также постоянным затратам на обучение и повышение квалификации персонала.
Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:
высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;
приемлемый уровень отдачи от инвестиций в CASE-средства.
Билет №15
Вопрос № 1. Жизненный цикл программного обеспечения информационных систем, модели жизненного цикла.
К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла :
- каскадная;
- инкрементная;
- спиральная.
Дальнейшее рассмотрение моделей жизненного цикла ведется с использованием терминологии классического жизненного цикла.
3.2. Каскадная стратегия
Каскадная стратегия (однократный проход, водопадная или классическая модель) подразумевает линейную последовательность выполнения стадий создания информационной системы (рис.3.1). Другими словами, переход с одной стадии на следующую происходит только после того, как будет полностью завершена работа на текущей.
Рис.3.1. Каскадная стратегия
Данная модель применяется при разработке информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования.
Достоинства модели:
- на каждой стадии формируется законченный набор документации, программного и аппаратного обеспечения, отвечающий критериям полноты и согласованности;
- выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские).
Недостатки модели:
- реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;
- жизненный цикл основан на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;
- основной недостаток – результаты разработки доступны заказчику только в конце проекта. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС заказчик получает систему, не удовлетворяющую его потребностям.
3.3. Инкрементная стратегия
Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта.
Рис.3.2. Инкрементная стратегия
В начале работы над проектом определяются все основные требования к системе, после чего выполняется ее разработка в виде последовательности версий. При этом каждая версия является законченным и работоспособным продуктом. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система.
Данная модель жизненного цикла характерна при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат (информационная система). Разработка версиями ведется в силу разного рода причин:
- отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
- отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
- требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у ее пользователей неприятие и только «затормозить» процесс перехода на новые технологии. Образно говоря, они могут просто «не переварить большой кусок, поэтому его надо измельчить и давать по частям».
Достоинства и недостатки этой стратегии такие же, как и у классической. Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора.
3.4. Спиральная стратегия
Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.
Рис. 3.3. Спиральная стратегия
Данная модель жизненного цикла характерна при разработке новаторских (нетиповых) систем. В начале работы над проектом у заказчика и разработчика нет четкого видения итогового продукта (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта (риски очень велики). В связи с этим принимается решение разработки системы по частям с возможностью изменения требований или отказа от ее дальнейшего развития. Как видно из рис.3.3, развитие проекта может быть завершено не только после стадии внедрения, но и после стадии анализа риска.
Достоинства модели:
- позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
- допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;
- обеспечивает большую гибкость в управлении проектом;
- позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
- позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации;
- уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.
Недостатки модели:
- увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;
- затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа выполнена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.
Вопрос № 2.Информационное обеспечение органов полиции. Учёты.
Информация, используемая в органах внутренних дел, содержит сведения о состоянии преступности и общественного порядка на обслуживаемой территории, о самих органах и подразделениях, их силах и средствах. В дежурных частях, у оперработников, участковых инспекторов милиции, следователей, сотрудников экспертно-криминалистических подразделений, паспортно-визовых аппаратов, других подразделений на документах первичного учета, в учетных журналах и на других носителях накапливаются массивы данных оперативно-розыскного и оперативно-справочного назначения, в которых содержатся сведения:
• о правонарушителях и преступниках;
• о владельцах автомототранспортных средств;
• о владельцах огнестрельного оружия;
• о событиях и фактах криминального характера, правонарушениях;
о похищенных и изъятых вещах, предметах антиквариата; а также другая, подлежащая хранению, информация.
Службы и подразделения органов внутренних дел характеризуются данными:
• о силах и средствах, которыми располагает орган;
• о результатах их деятельности.
Перечисленные выше сведения используются при организации работы подразделений и принятии практических мер по борьбе с преступностью и правонарушениями1.
Кроме указанных сведений широко используется научная и техническая информация, необходимая для совершенствования деятельности органов внутренних дел.
1 Организация деятельности информационных работников горрай-линорганов внутренних дел' Сб. материалов для занятий в системе служебной подготовки / Под ред. Ю.А Буничева - М.: ГИЦ МВД РФ, 1995.
В информационном обеспечении органов внутренних дел центральное место занимают учеты, которые используются для регистрации первичной информации о преступлениях и лицах, их совершивших.
Учет - это система регистрации и хранения информации о лицах, совершивших преступления, о самих преступлениях и связанных с ними фактах и предметах.
Учет подведомственных МВД преступлений охватывает 95% криминальных проявлений и дает достаточно полную картину оперативной обстановки в стране и ее регионах.
В целом по России в последние годы с помощью информации, содержащейся в учетах, раскрывается от 19 до 23% совершаемых преступлений, или почти каждое четвертое от общего числа по линии уголовного розыска1.
Билет №16
Вопрос № 1. Методологии и технологии проектирования информационных систем.
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);
критериев и правил, используемых для оценки результатов выполнения технологических операций;
нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Рис. 1.4. Представление технологической операции проектирования
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:
технология должна поддерживать полный ЖЦ ПО;
технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие:
стандарт проектирования;
стандарт оформления проектной документации;
стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
комплектность, состав и структуру документации на каждой стадии проектирования;
требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),
правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
правила использования клавиатуры и мыши;
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя.
Вопрос № 2. Типичные структуры данных. Списки. Справка и запись.
1. Линейная структура (список) – упорядоченная структура, в которой адрес данного однозначно определяется его номером (список учебной группы; дома, стоящие на одной улице).
В списках новый элемент начинается с новой строки. Если элементы располагаются в строчку, нужно внести разделительный знак между элементами. Поиск осуществляется по разделителям (чтобы найти, например, десятый элемент, надо отсчитать девять разделителей).
Записи – структура данных, состоящая из фиксированного числа компонент, называемых полями, каждая из которых может иметь свой тип. Записи позволяют в удобной форме представлять ведомости, таблицы, картотеки, каталоги и лр. данные.
Билет №17
Вопрос № 1. Списки. Двунаправленные, кольцевые, иерархические, ассоциативные списки, информационные сети.