- •1) Дайте определение структур аис. Функциональным и обеспечивающим
- •2. Приведите примеры развития Internet/Intranet технологий.
- •3. Приведите классификация моделей разрабатываемого программного обеспечения,
- •Вопрос 1.Приведите схему структуры информационной системы как совокупность обеспечивающих подсистем. Дайте определение каждой подсистеме.
- •Вопрос 2. Дайте определение поисковым системам, Опишите ох основные возможности.
- •Вопрос 3. Дайте описание диаграммы переходов состояния.
- •3 Билет
- •2. Приведите примеры использования Internet-технологии в электронной коммерции.
- •Билет №4:
- •1. Дайте определение классической, централизованной архитектуры ис.
- •3. Дайте описание Методология idef0.
- •Кейлоггеры
- •Вопрос 1.Дайте определение Архитектуры распределение систем.
- •2. Дайте описание технологии хранилищ данных.
- •3. Дайте описание Методу описания процессов idef3.
- •Приведите основные типы информационных систем. Ответ:
- •Дайте описание общей схеме взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования .
- •Билет №10
- •1.Обьясните какие управленческие функции решают ис.
- •2.Дайте определение четырём основным уровням распределённой архитектуры.
- •3.Дайте описание интегрированной модели сложной системы в нотации uml
- •Приведите три основных уровня управления, которые решаются с внедрением аис.
- •Дайте описание общих задач обработки данных.
- •Дайте описание диаграммы вариантов использования.
- •Билет 12
- •Вопрос1. Приведите категории на которые можно разделить информацию, которую использует менеджер в повседневной деятельности и в процессе принятия решений.
- •Вопрос2. Опишите классы структур асу.
- •Децентрализованная структура.
- •Централизованная структура.
- •Централизованная рассредоточенная структура.
- •Иерархическая структура.
- •Вопрос3. Дайте описание Диаграммы классов.
- •1.Какие функции решают системы знаний?
- •2.Приведите алгоритмы и опишите операции над данными.
- •3.Дайте описание диаграммы состояний.
- •Вопрос 1. Дайте определение принципа реализации ис с применением архитектуры файл-сервер.
- •Вопрос 2. Дайте определение целей автоматизации производства.
- •Вопрос 3. Дайте описание диаграммыкомпонентов.
- •18 Билет.
- •5. Средства документирования.
- •6. Средства тестирования.
- •Билет №19:
- •1.Особенности применения языка программирования Visual Basic при построении информационной системы по архитектуре файл - сервер на
- •2. Дайте описание функциональной структуры предприятия.
- •3. Приведите классификацию case-средств по типам и категориям.
- •Дайте описание принципа работы трехзвенной клиент-серверной архитектуре.
- •Дайте описание класcификации информационных систем.
- •3 Дайте описание Диаграммы переходов состояний.
- •Вопрос 2
- •1.Дайте описание основных характеристик субд ibm db2.
- •Приведите блок схему и объясните принцип построения обобщенной архитектуры субд.
- •Дайте описание модели быстрой (rad) разработки приложений.
- •Билет27
- •Вопрос1
- •Вопрос2
- •Вопрос3
- •12 Правил Кодда
- •1. Дайте определение структур аис. Функциональным и обеспечивающим
- •1.Приведите схему структуры информационной системы как совокупность обеспечивающих подсистем. Дайте определение каждой подсистеме.
- •2.Опишите назначение и методику «реинжиниринга бизнес-процессов»
- •3.Дайте описание интегрированной модели сложной системы в нотации uml.
3. Дайте описание Методу описания процессов idef3.
IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
Единицы работы — Unit of Work (UOW) — также называемые работами (activity), являются центральными компонентами модели.
Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style:
Старшая (Precedence)
сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Отношения (Relational Link)
пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow)
стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели.
В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки.
IDEF3 - это структурный метод, показывающий причинно-следственные связи и события. Он также показывает, как организована работа, и какие пользователи работают с моделируемой системой. IDEF3 состоит из двух методов. Process Flow Description (PFD) - описание процессов, с описанием того, как организована работа между различными элементами моделируемой системы. Object State Transition Description (OSTD) - описание переходов состояний объектов, с описанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.
С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. Сценарием называется описание последовательности изменения свойств объекта в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение ее свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух потоков: (1) документы, определяющие структуру и последовательность процесса (технологические указания, описания стандартов) и (2) документы, отображающие ход его выполнения (результаты экспертиз, отчеты о браке).
Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:
документировать имеющиеся данные о технологии процесса;
определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;
определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса (например, изменение технологических свойств конечного продукта);
содействовать принятию оптимальных решений при реорганизации технологических процессов;
разрабатывать имитационные модели технологических процессов по принципу «как будет, если...» [14].
IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция может быть представлена в виде отдельного процесса средствами IDEF3. Но функциональное моделирование в IDEF3 отличается от моделирования в IDEF0 и DFD, тем что она отражает функции системы во временной последовательности их осуществления.
Билет№8
Вопрос №1
Архитектура Веб-приложений
Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.
Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.
основные особенности веб-архитектуры:
отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет автоматически реализовать клиентскую часть на всех платформах;
возможность подключения практически неограниченного количества клиентов;
благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных;
доступность при работоспособности сервера и каналов связи;
недоступность при отсутствии работоспособности сервера или каналов связи;
достаточно низкая скорость Веб сервера и каналов передачи данных;
относительно объема данных – архитектура Веб систем не имеет существенных ограничений.
Вопрос №2 Корпоративная информационная фабрика — это логическая архитектура программно-аппаратного решения по производству, складированию, управлению и доставке данных для поддержки принятия стратегических и тактических решений вмасштабе организации. Концепция CIF, предложенная классиком в области теории хранилищ данных Биллом Инмоном в серии его работ, подразумевала системно организованное взаимодействие репозиториев оперативных данных (Operational Data Store), центрального ХД, витрин данных и системы интеллектуального анализа данных (Data Mining) за счет создания технологических цепочек переработки и доставки данных.
В абстрактной форме процесс производства информации в CIF был представлен в аналогии с производством некоторого продукта. В соответствии с этим были выделены основные стадии производства информации (новых данных): получение исходных данных (сырья), их преобразование (производство отдельных деталей), складирование данных, создание информационных продуктов (из деталей готовой продукции) и доставка данных их потребителям (распределение конечной продукции).
"Корпоративная информационная фабрика"
Вопрос №3 Методология объектно-ориентированного программирования
Методология объектно-ориентированного программирования пришла на смену процедурной или алгоритмической организации структуры программного кода, когда стало очевидно, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработки, ни с повышением их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии программирования, которая бы позволила решить весь этот комплекс проблем. Такой методологией стало объектно-ориентированное программирование (ООП).
Объектно-ориентированное программирование (ООП, Object-Oriented Programming) - совокупность принципов, технологий , а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов.
Принцип, в соответствии с которым знание о наиболее общей категории разрешается применять для более частной категории, называется наследованием.
Наследование тесно связано с иерархией классов, определяющей, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам. При этом если общий или родительский класс (предок) обладает фиксированным набором свойств и поведением, то производный от него класс (потомок) должен содержать этот же набор свойств и подобное поведение, а также дополнительные, которые будут характеризовать уникальность полученного класса. В этом случае говорят, что производный класс наследует свойства и поведение родительского класса.
Следующий принцип ООП - инкапсуляция. Инкапсуляция характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей.
Полиморфизм также один из основных принципов ООП. Под полиморфизмом (греч. Poly - много, morfos - форма) понимается свойство объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, к какому из классов относится тот или иной метод.
Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы.
Прежде, чем начать программирование классов, их свойств и методов, необходимо определить сами эти классы. Более того, нужно дать ответы на следующие вопросы: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированного анализа и проектирования (ООАП).
Билет №9
