Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы ТРПО срез.doc
Скачиваний:
3
Добавлен:
01.04.2025
Размер:
1 Мб
Скачать
☆
  • Характеристика объектов автоматизации

    • краткие сведения об объекте автоматизации

    • сведения об условиях эксплуатации и характеристиках окружающей среды.

    4. Требования к системе (см. ответ 4)

    5. Состав и содержание работ по созданию системы – перечень стадий и этапов работ

    • сроки исполнения;

    • состав организаций — исполнителей работ;

    • вид и порядок экспертизы технической документации;

    • программа обеспечения надежности;

    • программа метрологического обеспечения;

    6. Порядок контроля и приемки системы – виды, состав, объем и методы испытаний системы

    • общие требования к приемке работ по стадиям;

    • статус приемной комиссии.

    7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие – преобразование входной информации к машиночитаемому виду

    • изменения в объекте автоматизации;

    • сроки и порядок комплектования и обучения персонала.

    8. Требования к документированию – перечень подлежащих разработке документов

    9. Источники разработки – документы и информационные материалы, на основании которых разрабатывается ТЗ и система.

    .

    1. Дайте определение «Интерфейс пользователя». Определите основные элементы интерфейса пользователя. Кратко охарактеризуйте основные принципы проектирования пользовательского интерфейса.

    Интерфейс пользователя, он же пользовательский интерфейс (UI — англ. user interface) – разновидность интерфейсов, в котором одна сторона представлена человеком (пользователем), другая – машиной/устройством.

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

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

    ИП объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на взаимодействие пользователя с ПО:

    • набор задач пользователя, которые он решает при помощи системы;

    • используемая системой метафора (например, рабочий стол в MS Windows®);

    • элементы управления системой;

    • визуальный (дизайн экранов программы;

    • средства отображения информации, отображаемая информация и форматы;

    • устройства и технологии ввода данных;

    • диалоги, взаимодействие и транзакции между пользователем и компьютером;

    • обратная связь с пользователем;

    • порядок использования программы и документация на нее.

    Графический интерфейс пользователя, графический пользовательский интерфейс (ГПИ) (англ. Graphical user interface, GUI) — разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т.п.), представленные пользователю на дисплее, исполнены в виде графических изображений.

    К общим принципам, лежащим в основе графического пользовательского интерфейса, относятся:

    • графический режим работы;

    • представление ряда объектов пиктограммами;

    • многооконность;

    • использование указывающего устройства – мыши;

    • наглядность;

    • стандартизация всех основных действий и элементов (все программы для данной графической среды выглядят и ведут себя совершенно одинаково, используют одинаковые принципы функционирования);

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

    Основные принципы проектирования пользовательского интерфейса:

    естественность интерфейса

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

    согласованность интерфейса

    Согласованность позволяет пользователям переносить имеющиеся знания на но­вые задания, осваивать новые аспекты быстрее, и благодаря этому фокусировать внимание на решаемой задаче

    дружественность интерфейса

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

    принцип «обратной связи»

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

    простота интерфейса

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

    1. Объясните сущность структурного подхода к разработке по. Выделите основные модели структурного подхода. Охарактеризуйте основные принципы структурного подхода.

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

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

    Ключевые понятия структурного подхода:

    Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

    Функция – совокупность операций, сгруппированных по определенному признаку.

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

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

    Выделяют 2 вида моделей структурного подхода:

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

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

    Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:

    • принцип "разделяй и властвуй" – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

    • принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

    • SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы. В дальнейшем ее заменила методология IDEF0;

    • DFD (Data Flow Diagrams) – диаграммы потоков данных;

    • IDEF3 – метод создания процессов;

    1. Охарактеризуйте метод функционального моделирования SADT. Проанализируйте значение моделей AS-IS и TO-BE.

    Методология SADT разработана Дугласом Россом в 1973г. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

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

    Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга

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

    Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.

    Рис. 1 Функциональный блок и интерфейсные дуги

    В дальнейшем методология SADT была принята в качестве федерального стандарта США под наименованием IDEF0. К основным элементам IDEF0 онтносятся

    • функциональный блок;

    • интерфейсная дуга;

    • декомпозиция;

    • глоссарий

    Построение функциональной модели КАК ЕСТЬ позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов.

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

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

    1. Опишите назначение методологии моделирования бизнес-процессов idef0. Выделите и охарактеризуйте ее основные понятия.

    Методологию IDEF0 можно считать следующим этапом развития графического языка описания функциональных систем SADT.

    В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

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

    Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

    Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. После чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.

    В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

    Точка зрения определяет основное направление развития модели и уровень необходимой детализации.

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

    В основе методологии лежат основные понятия:

    1. Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

    По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль). Вход, Выход, Управление, Механизм.

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

    С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. В IDEF0 различают четыре типа стрелок: Вход, Выход, Управление, Механизм.

    Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода)

    Выход (Output) - материал или информация, которые производятся работой

    Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа

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

    3. Декомпозиция является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

    Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.

    4. глоссарий (словарь описания) (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента.

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

    Диаграммы потоков данных (Data Flow Diagram – DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных.

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

    В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов, хранение объектов, поставка и распространение объектов.

    При создании диаграммы потоков данных используются четыре основных понятия:

    • потоки данных;

    • процессы (работы) преобразования входных потоков данных в выходные;

    • внешние сущности;

    • накопители данных (хранилища).

    потоки данных;

    процессы (работы) преобразования входных потоков данных в выходные;

    внешние сущности;

    накопители данных (хранилища).

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

    В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. Имя процесса может содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по отгрузке продукции")

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

    Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

    К преимуществам методики dfd относятся:

    • возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

    • возможность проектирования сверху вниз, что облегчает построение модели "как должно быть";

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

    1. Опишите назначение методологии моделирования структуры баз данных erd. Выделите и охарактеризуйте ее основные понятия.

    Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (Entity-Relationship Diagram). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

    Для моделирования ERD-диаграмм используется методология IDEF1X. IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы.

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

    Основные элементы erd:

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

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

    Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Минск, Варшава и т.д

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

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

    Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

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

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

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

    1. Объясните отличия структурных и объектно-ориентированных методик к разработке по. Систематизируйте основные преимущества и недостатки методик.

    Как структурные методики, так и ОО методики имеют своей целью разработку работоспособных программных продуктов, однако данные методики имеют некоторые отличия друг от друга.

    Структурные методики рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы.

    Основное отличие структурной от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

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

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

    Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена.

    Главными достоинствами ОО подхода по сравнению со структурными методами являются:

    • использование на стадии анализа моделей близких к реальности;

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

    • естественная работа с разнородной информацией, используемой в мультимедиа системах;

    • создание более открытых систем;

    • полное использование описательных возможностей объектно-ориентированных языков программирования.

    • объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем.

    • объектная модель естественна, поскольку ориентированна на человеческое восприятие мира.

    К недостаткам объектно-ориентированного подхода относятся:

    • высокие начальные затраты. Этот подход не дает немедленной отдачи.

    • Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов.

    • Диаграммы, отражающие специфику объектного подхода, менее наглядны.

    • Невозможность проведения детального анализа процессов;

    • Неполнота и незавершенность некоторых видов диаграмм, возможность их неверной интерпретации

    Несомненным достоинством функциональных моделей является:

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

    • наглядность представления.

    • Возможность проведения глубокого анализа бизнес-процессов, выявление узких мест, комплексное применение позволяет выявить все возможные рассогласования и неточности;

    • Применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания,

    • проверенность временем и широкое распространение среди аналитиков и разработчиков

    Главные недостатки структурных моделей:

    • процессы и данные существуют отдельно друг от друга – помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане.

    • Сложность восприятия иерархически упорядоченной информации;

    • Необходимость следования жесткой структуре, которая не всегда необходима

    1. Объясните сущность объектно-ориентированного подхода к разработке по. Охарактеризуйте основные составляющие объектно-ориентированной методологии. Выделите основные понятия объектного подхода.

    В основе ОО подхода лежит представление о том, что программную систему необходимо разрабатывать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию.

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

    Составными частями объектно-ориентированной методологии (ООМ) являются:

    • объектно-ориентированный анализ;

    • объектно-ориентированное проектирование;

    • объектно-ориентированное программирование.

    Обьектно-ориентированное программирование – это методология программирования, которая основана на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса, а классы образуют иерархию на принципах наследования.

    В данном определении можно выделить три части:

    1) объектно-ориентированное программирование использует в качестве элементов конструкции объекты, а не алгоритмы;

    2) каждый объект является реализацией определенного класса;

    3) классы организованы иерархически.

    Методы программирования, прежде всего, подразумевают правильное и эффективное использование механизмов языков программирования.

    Объектно-ориентированное проектирование.

    Методы проектирования основное внимание направляют на правильное и эффективное структурирование сложных систем.

    Объектно-ориентированное проектирование – это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления как логической и физической, так статической и динамической моделей проектируемой системы.

    Именно поддержка объектно-ориентированной декомпозиции отличает объектно-ориентированное проектирование от структурного проектирования.

    Объектно-ориентированный анализ.

    На объектный подход оказали влияние предыдущие этапы развития программных средств. Традиционные приемы структурного анализа основаны на потоках данных в системе.

    Объектно-ориентированный анализ (ООА) направлен на создание моделей, более близких к реальности, с использованием объектно-ориентированного подхода; это методология, при которой требования формируются на основе понятий классов и объектов, составляющих словарь предметной области.

    На результатах ООА формируются модели, на которых основывается объектно-ориентированное проектирование; объектно-ориентированное проектирование в свою очередь создает основу для окончательной реализации системы с использованием методологии объектно-ориентированного программирования

    Основными понятиями объектно-ориентированного подхода являются объект и класс.

    Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс.

    Класс – это множество объектов, связанных общностью структуры и поведения

    Операцией называется определенное воздействие одного объекта над другим, с целью вызова соответствующей реакции

    Атрибут – это свойство класса, которое может принимать множество значений.

    1. Определите и охарактеризуйте основные принципы объектно-ориентированного подхода к разработке по. Разъясните, что послужило толчком к развитию объектно-ориентированного подхода

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

    Как показала практика, традиционные методы процедурного программирования не способны справиться ни с нарастающей сложностью программ и их разработки, ни с необходимостью повышения их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии разработки ПО, которая была бы способна решить весь этот комплекс проблем. Ею стал объектно-ориентированный подход.

    К основным понятиям объектно-ориентированного подхода относятся объект и класс.

    Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс.

    Класс – это множество объектов, связанных общностью структуры и поведения

    К основным принципам ОО подхода относятся:

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

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

    Полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу.

    Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов

    Модульность - это свойство системы, связанное с возможностью декомпозиции на ряд внутренне связанных, но слабо связанных между собой модулей.

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

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

    Иерархия – ранжированная (упорядоченная) система абстракций

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

    1. Объясните сущность унифицированного языка моделирования uml (Unified Modeling Language). Охарактеризуйте основные понятия языка: диаграмма, класс, объект, атрибут, операция.

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

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

    UML не является языком программирования. Программный код можно получить на основе созданной модели с помощью инструментальных средств, поддерживающих UML и содержащий генераторы кода. С другой стороны, на основе исходного кода можно вставить UML-модели уже существующих программ.

    UML позволяет отображать и статическую структуру, и динамическое поведение системы. Система моделируется как группа дискретных объектов, которые взаимодействуют друг с другом таким образом. В статической структуре задаются типы объектов, значимые для системы и ее реализации, а также отношения между этими объектами. Динамическое поведение определяет историю объектов и их взаимодействие для достижения конечно цели.

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

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

    Классы – это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой.

    Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс.

    Атрибут – это свойство класса, которое может принимать множество значений

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

    1. Перечислите и кратко охарактеризуйте основные типы диаграмм, используемые в uml. Проанализируйте, какие диаграммы относятся к статическому описанию поведения системы, а какие к динамическому.

    UML позволяет отображать и статическую структуру, и динамическое поведение системы. Система моделируется как группа дискретных объектов, которые взаимодействуют друг с другом таким образом. В статической структуре задаются типы объектов, значимые для системы и ее реализации, а также отношения между этими объектами. Динамическое поведение определяет историю объектов и их взаимодействие для достижения конечно цели.

    С помощью диаграмм UML разработчики создают различные модели системы. Разнообразие моделей позволяет разработчикам отразить различные аспекты системы:

    • Диаграмма вариантов использования (use case diagram)

    Варианты использования и их диаграммы применяются для визуализации функциональных возможностей системы.

    Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой.

    • Диаграмма классов (class diagram)

    Диаграмма классов используется для отображения объектов системы и их отношений.

    • Диаграмма состояний (statechart diagram)

    Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий

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

    • Диаграмма деятельности (activity diagram)

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

    • Диаграммы взаимодействия (interaction diagrams)

    Диаграммы взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Делятся на: Диаграммы последовательности (sequence diagram) и Диаграммы кооперации (collaboration diagram). Из диаграмм последовательности и кооперативных диаграмм аналитики и разработчики уяснят, насколько логично работает система, поймут ее объекты и соотношения между ними.

    • Диаграмма компонентов (component diagram)

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

    • Диаграмма топологии (развертывания) (deployment diagram)

    Диаграммы развертывания применяют для визуализации проекта распределенных систем

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

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

    Статические диаграммы

    Динамические диаграммы:

    Диаграмма вариантов использования (use case

    Диаграмма классов (class diagram)

    Диаграмма компонентов (component diagram)

    Диаграмма топологии (deployment diagram)

    Диаграмма состояний (statechart

    Диаграмма деятельности (activity diagram)

    Диаграммы взаимодействия (interaction diagrams)

    Диаграмма последовательности (sequence diagram)

    Диаграмма кооперации (collaboration diagram)

    1. Дайте определение case-технологии. Выделите основные достоинства case-средств. Охарактеризуйте основные компоненты case-средств.

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

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

    Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования программного обеспечения

    Таким образом, среди достоинств CASE можно выделить следующие:

    • улучшают качество создаваемого ПО за счет средств автоматического контроля;

    • позволяют за короткое время создавать прототип будущей системы, что дает возможность на ранних этапах оценить ожидаемый результат;

    • ускоряют процесс проектирования и разработки;

    • освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части;

    • поддерживают развитие и сопровождение разработки;

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

    Интегрированный case-пакет содержит четыре основных компонента:

    1. Репозиторий – основа CASE-пакета. Представляет собой средство централизованного хранения всей информации о проектируемом ПО в течение всего ЖЦ. Репозиторий должен обеспечивать:

    • поддержку большой системы описаний и характеристик;

    • распространение действия нового или скорректированного описания на информационное пространство всего проекта;

    • синхронизацию поступления информации от различных пользователей;

    • хранение версий проекта и его отдельных компонент;

    • сборку любой запрошенной версии;

    • проверка информации на корректность, полноту и состоятельность;

    • надежные меры по защите от ошибок и потерь информации.

    1. Средства ввода – предназначены для ввода данных в репозиторий, а также для организации взаимодействия с CASE-пакетом. Должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т. д.

    2. Средства анализа, проектирования и разработки – предназначены для того, чтобы обеспечить планирование и анализ различных описаний, а также их преобразование в процессе разработки.

    3. Средства вывода – служат для документирования, управления проектом и кодовой генерации.

    Примеры CASE-средств:

    BPwin (AllFusion Process Modeler), Erwin (AllFusion Data Modeler), IBM Rational Rose, Silverrun, Designer/2000 (Oracle), PowerBuilder, CASE.Аналитик , DataBase Designer (Oracle), Vantage Team Builder.

    1. Дайте определение и перечислите принципы методологии создания программных продуктов RAD (Rapid Application Development). Выделите основные элементы данной методологии. Приведите примеры сред программирования, использующих методы RAD.

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

    RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. С конца XX века RAD получила широкое распространение и одобрение. Методологию RAD также часто связывают с концепцией визуального программирования.

    Методология RAD предполагает использование специальных программных средств быстрой разработки, а также CASE-средств. Благодаря этому значительно ускоряется разработка графического интерфейса, и создание прототипов.

    Элементы RAD:

    • небольшая команда программистов (от 2 до 10 человек);

    • короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

    Основные принципы методологии RAD

    • разработка приложений итерациями;

    • необязательность полного завершения работ на каждом из этапов жизненного цикла;

    • обязательное вовлечение пользователей в процесс разработки ИС;

    • необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

    • необходимое использование генераторов кода;

    • cоздание прототипа для уточнения требований заказчика.

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

    • тестирование и развитие проекта, осуществляемые одновременно с разработкой;

    • ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

    Среды разработки, использующие принципы RAD:

    • Borland C++ Builder

    • Borland Delphi

    • Microsoft Visual Studio

    • Macromedia Flash

    Macromedia Dreamweaver

    1. Охарактеризуйте методологию экстремального программирования xp (Extreme Programming). Выделите основные приемы, воплощенные в данной методологии.

    Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях.

    ХР – это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный способ разработки программного обеспечения, предусматривающий низкий уровень риска

    От других методик ХР отличается по следующим признакам.

    • Благодаря использованию чрезвычайно коротких циклов разработки ХР предлагает быструю, реальную и постоянно функционирующую обратную связь.

    • В рамках ХР используется планирование по нарастающей, в результате общий план проекта возникает достаточно быстро, однако при этом подразумевается, что этот план эволюционирует в течение всего времени жизни проекта.

    • В рамках ХР используется гибкий график реализации той или иной функциональности, благодаря чему улучшается реакция на изменение характера бизнеса и меняющиеся в связи с этим требования заказчика.

    • ХР базируется на автоматических тестах, разработанных как программистами, так и заказчиками. Благодаря этим тестам удается следить за процессом разработки, обеспечивать корректное эволюционирование системы и без промедления обнаруживать существующие в системе дефекты.

    • ХР основана на оральном обмене информацией, тестах и исходном коде. Три этих инструмента используются для обмена сведениями о структуре системы и ее поведении.

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

    • ХР базируется на тесном взаимодействии программистов, обладающих самыми обычными навыками и возможностями.

    • ХР основывается на методиках, которые удовлетворяют как краткосрочным инстинктам отдельных программистов, так и долгосрочным интересам всего проекта в целом.

    Основные приемы:

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

    Коллективное владение означает, что каждый несёт ответственность за весь код. Таким образом, каждый вправе вносить изменения в любой участок кода. Парное программирование поддерживает эту практику: работая в парах, все программисты получают доступ ко всем частям кода. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.

    Заказчик всегда рядом

    Xp утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

    Игра в планирование

    Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.

    Рефакторинг

    Рефакторинг — это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.

    Частые небольшие релизы

    Версии продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.

    1. Дайте определение понятиям «Тестирование» и «Отладка» программного обеспечения. Охарактеризуйте тестирование белого и черного ящика. Проанализируйте основные этапы тестирования.

    Отладка (debug, debugging)– процесс поиска, локализации и исправления ошибок в программе

    Тестирование ПС  это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ

    Тестирование ПО – процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований

    Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения.

    Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:

    Отладка = Тестирование + Поиск ошибок + Редактирование

    Тестирование – процесс многократного повторения программы с целью обнаружения ошибок. Тестирование – составная часть отладки.

    При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. При таком тестировании тестируется логика программы, внутренняя структура программы

    При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. В этом случае тестируется спецификация, т.е. вход/выход без учета знаний о структуре программы.

    Этапы тестирования

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

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

    • Разработка тестов (тестового кода для тестируемой системы).

    • Выполнение тестов: реализация тестовых циклов.

    • Анализ результатов: решается вопрос об устранении ошибок и йелесообразности тестирования на другом наборе тестовых данных

    1. Дайте определение понятия «Документирование программного обеспечения». Выделите и охарактеризуйте основные виды документации на программное обеспечение

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

    Документирование ПО – процесс формализованного описания информации, созданной в течение жизненного цикла программного обеспечения

    При разработке Программных Продуктов создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПП, как средство управления разработкой ПП и как средство передачи пользователям информации, необходимой для применения и сопровождения ПП.

    Можно выделить следующие основные виды документации на ПО

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

    • Техническая — документация на код, алгоритмы, интерфейсы, API.

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

    • Пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала. Пользовательская документация описывает то, как использовать программу. Обычно, пользовательская документация представляет из себя руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Примеры: руководство пользователя, руководство администратора

    Существует три подхода к организации пользовательской документации

    • Вводное руководство (англ. tutorial), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач.

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

    • Алфавитный справочник команд и задач

    • Маркетинговая

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

    - подогреть интерес к продукту у потенциальных пользователей

    - информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем что они получат

    - объяснить положение продукта по сравнению с конкурирующими решениями

    1. Опишите понятие «Модульное программирование». Выделите основные характеристики программного модуля. Проанализируйте преимущества и недостатки модульности при разработке по.

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

    Программный модуль  это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса.

    Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы.

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

    Программы разбиваются на модули для того, чтобы:

    • упростить их разработку и реализацию;

    • облегчить чтение программ;

    • упростить их настройку и модификацию;

    • облегчить работу с данными, имеющими сложную структуру;

    • избежать чрезмерной детализации алгоритмов;

    • обеспечить более выгодное размещение программ в памяти ЭВМ.

    К основным характеристикам программного модуля относят:

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

    Прочность(связность) модуля  это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести.

    Выделяют:

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

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

    Сцепление модуля  это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей.

    Рутинность модуля  это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему.

    +

    –

    Модульные программы легко составлять и отлаживать. Функциональные компоненты такой программы могут быть написаны и отлажены порознь.

    Модульность требует большей дополнительной работы

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

    Модульный подход иногда требует большего времени процессора

    Разработкой модульной программы легче управлять.

    Сложности в проектировании большого количества модулей

    1. Охарактеризуйте стандарт iso/iec 12207. Перечислите группы процессов жизненного цикла по и опишите основные процессы жизненного цикла программного обеспечения.

    Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Самым известным стандартом является стандарт ISO/IEC 12207 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов. Последняя редакция стандарта – 2008 год.

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

    В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

    1. Основные процессы:

    • заказ;

    • поставка;

    • разработка;

    • эксплуатация;

    • сопровождение.

    2. Вспомогательные процессы:

    • документирование;

    • управление конфигурацией;

    • обеспечение качества;

    • разрешение проблем;

    • аудит;

    • аттестация;

    • совместный анализ;

    • верификация

    3. Организационные процессы:

    • создание инфраструктуры;

    • управление;

    • обучение;

    • усовершенствование.

    Стандарт ISO/IEC 12207 детально определяет перечень работ каждого процесса ЖЦ, однако не устанавливает конкретной модели ЖЦ ПО в виде последовательности фаз, стадий и этапов.

    1. Охарактеризуйте этап сопровождения программного обеспечения. Проанализируйте значимость данного этапа в структуре жизненного цикла по.

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

    Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:

    • исправление ошибок;

    • адаптация к изменениям внешней для ПО среды;

    • усовершенствование ПО по требованиям заказчика.

    Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) ЖЦ к существующей программе, но не разработке новой программы.

    Согласно стандарту 34.601 «АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ» этап сопровождения включает в себя:

    • Выполнение работ в соответствии с гарантийными обязательствами:

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

    • Послегарантийное обслуживание:

    анализ функционирования системы;

    выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений; установление причин этих отклонений;

    устранение выявленных недостатков и обеспечению стабильности эксплуатационных характеристик ИС;

    внесение необходимых изменений в документацию на ИС.

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

    1. Дайте характеристику case-средствам bPwin (AllFusion Process Modeler) и eRwin (AllFusion Data Modeler). Опишите их назначение и возможности в разработке программных продуктов.

    Типичными представителями интегрированных средств моделирования являются программные средства BPwin и ERwin.По своей функциональной ориентации они относятся к Case-средствам предназначенным для анализа и проектирования.

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

    Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольника, данные – в виде стрелок.

    BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD, каждая из которых предназначена для решения своих специфических задач. В BPwin возможно построение смешанных моделей, т.е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

    Модель в BPwin представляет собой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс в виде разбиения его на шаги и подпроцессы. С помощью соединяющих дуг описываются объекты, данные и ресурсы, необходимые для выполнения функций.

    Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности.

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

    Область применения средства eRwin

    ERwin – средство концептуального моделирования баз данных (БД), использующее методологиюERD и IDEF1X. Erwin используется для построения модели данных. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и реинжиниринг существующей БД.

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

    ERwin имеет два уровня представления модели – логический и физический. На логическом уровне данные не связаны с конкретной СУБД. Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например, «Фамилия сотрудника», «Отдел». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

    Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. В физической модели содержится информация о всех объектах БД ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога.

    Таким образом, данные программные средства предоставляют достаточный инструментарий для разработчиков для моделирования и проектирования программного продукта, а также создания структуры разрабатываемой базы данных.

    1. Дайте определение понятия «Информационная безопасность». Охарактеризуйте методы защиты программного обеспечения от несанкционированного доступа.

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

    Защита информации - это комплекс мероприятий, направленных на обеспечение информационной безопасности.

    Существующие методы и средства защиты информации компьютерных систем (ИС) можно подразделить на четыре основные группы:

    • Методы и средства организационно-правовой защиты информации;

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

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

    • методы и средства инженерно-технической защиты информации;

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

    • криптографические методы и средства защиты информации;

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

    • для защиты конфиденциальности информации, передаваемой по открытым каналам связи;

    • для аутентификации (подтверждении подлинности) передаваемой информации;

    • для защиты конфиденциальной информации при ее хранении на открытых носителях;

    • для обеспечения целостности информации (защите информации от внесения несанкционированных изменений) при ее передаче по открытым каналам связи или хранении на открытых носителях;

    • для защиты программного обеспечения и других информационных ресурсов от несанкционированного использования и копирования.

    • Программно-аппаратные методы и средства защиты информации.

    К основным аппаратным средствам защиты информации относятся:

    • устройства для ввода идентифицирующей пользователя информации (магнитных и пластиковых карт, отпечатков пальцев и т. п.);

    • устройства для шифрования информации;

    • устройства для воспрепятствования несанкционированному включению рабочих станций и серверов (электронные замки и блокираторы).

    К основным программным средствам защиты информации относятся:

    • программы идентификации и аутентификации пользователей ИС;

    • программы разграничения доступа пользователей к ресурсам ИС;

    • программы шифрования информации;

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

    1. Дайте определение «Com-технология». Охарактеризуйте принцип ее работы.

    Component Object Model, COM (Объектная модель компонентов) — стандартная компонентная модель, реализованная на платформе Microsoft. Технология СОМ предоставляет пользователю компонентный подход к разработке программного обеспечения. Каждый компонент обладает набором средств, достаточных для того, чтобы другая программа, обратившись к компоненту, могла получить определенные услуги.

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

    На основе COM были созданы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+ и др.

    Технология COM разработана, в основном, под платформу Windows, что ограничивает область ее применения. Одной из целей COM является обеспечение стандартизации программных компонентов. Для программного обеспечения понятие стандартизации означает наличие средств, с помощью которых объекты и компоненты, разработанные на разных языках, поставляемые различными производителями и работающие в разнородных средах, могут взаимодействовать без каких-либо изменений в своих исполняемых (двоичных) кодах.

    В соответствии с технологией COM любая часть программного обеспечения реализует свои сервисы как один или несколько объектов СОМ. Каждый такой объект поддерживает один или несколько интерфейсов, состоящих из методов. Метод – это функция или процедура, которая выполняет некоторые действия и может быть вызвана программным обеспечением, использующим данный объект (клиентом объекта). Методы, составляющие каждый из интерфейсов, обычно определенным образом взаимосвязаны. Клиенты могут получить доступ к сервисам объекта СОМ только через вызовы методов интерфейсов объекта – у них нет непосредственного доступа к данным объекта.

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

    Р ис. 1 Объект com и его интерфейсы