Билет №1 Понятие жизненного цикла

ЖЦ ПО — период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом: ISO/IEC 12207: 1995. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи. Каждый процесс разделен на набор действий, каждое действие — на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по необходимости. В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы:

1. пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

3. четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение).

Билет №2 Основные процессы

1.Процесс приобретения. Действия и задачи заказчика.

1)инициирование приобретения (потребности в приобретении; анализ требований);

2)подготовку заявочных предложений (требования; перечень программных продуктов);

3)подготовку и корректировку договора (выбор к поставщика; закл. договора с поставщиком);

4)надзор за деятельностью поставщика;

5)приемку и завершение работ (тесты., завершение работ только в случае удовлетворения всех условий приемки.).

2.Процесс поставки. Действия и задачи. Поставщика.

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

2)подготовку ответа на предложения (разработка плана управления проектом); 3)подготовку договора; 4)планирование; 5)выполнение и контроль; 6)проверку и оценку; 7)поставку и завершение работ.

3.Процесс разработки. Включает:

1)подготовительную работу (выбора модели ЖЦ ПО); 2)анализ требований к системе (определение ее функциональных возможностей); 3)проектирование архитектуры системы (определении компонентов ее оборудования, ПО и операций); 4)анализ требований к ПО (требований к используемым данным; требований к установке и приемке); 5)проектирование архитектуры ПО (разработку предварительной версии пользовательской документации); 6)детальное проектирование ПО (обновление (при необходимости) пользовательской документации); 7)кодирование и тестирование ПО (тестирование каждого компонента ПО и базы данных на соответствие предъявляемым к ним требованиям); 8)интеграцию ПО (сборку разработанных компонентов ПО в соответствии с планом интеграции); 9)квалификационное тестирование ПО; 10)интеграцию системы (заключается в сборке всех ее компонентов); 11)квалификационное тестирование системы; 12)установку ПО; 13)приемку ПО (оценку результатов квалификационного тестирования ПО).

4.Процесс эксплуатации. Включает:

1)подготовительную работу (планирование действий и работ); 2)эксплуатационное тестирование; 3)эксплуатацию системы; 4)поддержку пользователей (оказании помощи и консультаций при обнаружении ошибок).

5.Процесс сопровождения. Только, когда необходимы изменения (модификации) программного продукта. Включает: 1)подготовительную работу; 2)анализ проблем и запросов на модификацию ПО; 3)модификацию ПО; 4)проверку и приемку; 5)перенос ПО в другую среду; 6)снятие ПО с эксплуатации.

Билет №3 Вспомогательные процессы

1. Процесс документирования. Формализованное описание информации, созданной в течение ЖЦ ПО. Тут планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех лиц, таких, как руководство, технические специалисты и пользователи системы.

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

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

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

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

6. Процесс совместной оценки. Он предназначен для оценки состояния работ по проекту и ПО, создаваемого при выполнении данных работ (действий).

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

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

Билет №4 Организационные процессы

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

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

3. Процесс усовершенствования. Он предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО. Данный процесс включает следующие действия: 1)создание процесса;2)оценку процесса;3)усовершенствование процесса.Усовершенствование процессов ЖЦ ПО направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии.

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

Билет №5 Модели ЖЦ

Модель ЖЦ - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует. Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Стандарт описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать. Модель ЖЦ определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО. Наибольшее распространение получили следующие две основные модели ЖЦ ПО: каскадная модель и спиральная модель. Преимущества применения каскадной: -на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; -выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Основным недостатком каскадной являются: существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ. Ее особенностью является: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования.

Стадии: Формирование требований к ПО - Проектирование - Реализация - Тестирование - ВВод в действие - Эксплуатация и сопровождение.

Билет №6 Стадии

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

1. Формирование требований к ПО (-планирование работ; - проведение обследования деятельности автоматизируемого объекта (организации), в рамках которого осуществляются: предварительное выявление требований к будущей системе - построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей "AS-IS" ("как есть"), и "ТО-ВЕ" ("как должно быть")).

2. Проектирование (- разработка системного проекта. На этом этапе дается ответ на вопрос: "Что должна делать будущая система?" - разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование.).

3. Реализация. 4. Тестирование. 5. Ввод в действие. 6. Эксплуатация и сопровождение. 7. Снятие с эксплуатации.

Билет №7 Каскадная модель

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

Стадии: Формирование требований к ПО - Проектирование - Реализация - Тестирование - ВВод в действие - Эксплуатация и сопровождение.

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

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

На начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: 1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; 2) за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

Билет №8 Спиральная модель

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

Билет №9 RAD

Одним из возможных подходов к разработке является способ быстрой разработки приложений, или RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих:

• небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

• короткого, но тщательно проработанного производственного графика (до 3 месяцев);

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

Жизненный цикл ПО в соответствии с подходом RAD включает четыре стадии:

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

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

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

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

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

Билет №10 Понятие метода и технологии проектирования ПО ИС

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

На более формальном уровне метод определяется как совокупность следующих составляющих:

1. концепций и теоретических основ. В качестве таких основ могут выступать структурный или объектно-ориентированный подход;

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

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

Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО. Технология проектирования ПО определяется как совокупность технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ПО. Технологическа операция: исходные данные в стандартном представлении; результаты в стандартном представлении. Исполнители, инструментальные средства; методические материалы, инструкции, нормативы и стандарты.

Современная технология проектирования ПО ЭИС должна обеспечивать: -соответствие стандарту ISO/IEC 12207 (поддержка всех процессов ЖЦ ПО); -гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время. - минимальное время получения работоспособного ПО ЭИС; -независимость получаемых проектных решений от средств реализации ЭИС; -поддержка комплексом согласованных CASE-средств.

Билет №11 Сущность структурного подхода к проектированию программного обеспечения

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

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

1. принцип "разделяй и властвуй" (построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера); 2. принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Второстепенные: 1..принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;2.принцип непротиворечивости — обоснованность и согласованность элементов системы;3.принцип структурирования данных — данные должны быть структурированы и иерархически организованы.

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

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

2.SADT(Structured Analysis and Design Technique — метод структурного анализа и проектирования,) — модели и соответствующие функциональные диаграммы;

3.ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".

Диаграммы потоков данных и диаграммы "сущность-связь" — наиболее часто используемые в CASE-средствах виды моделей.

Билет №12 SADT

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

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

2. строгость и точность (Правила SADT включают: ограничение количества блоков на каждом уровне, связность диаграмм, уникальность меток и наименований, синтаксические правила для графики, разделение входов и управлений)

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

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

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

Функция: Управление, механизм, вход, выход.

Билет №13 Построение иерархии диаграмм

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

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

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

Билет №14 Типы связей в SADT

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

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

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

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

4.процедурная(функции сгруппированы вместе благодаря тому, что они выполняются в течение одной и той же части цикла или процесса.);

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

6.последовательная(выход одной функции служит входными данными для следующей функции);

7.функциональная(элементы функции влияют на выполнение одной и только одной функции).

В математических терминах необходимое условие для простейшего типа функциональной связи имеет следующий вид: С = g(B) = g(f(A)).

Билет №15 Моделирование потоков данных. DFD

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

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

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

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

Билет №16 Состав диаграмм потоков данных

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

1.внешние сущности (объект или физ. лицо, предст. собой источник или приемник информации, например заказчики, персонал, поставщики, клиенты, склад. Внешняя сущность обозначается квадратом);

2.системы и подсистемы (При построении модели сложной ЭИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд подсистем );

3.процессы (Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. );

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

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

Билет №17 Построение иерархии диаграмм потоков данных

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

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

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

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

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

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

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

Для достижения этого целесообразно пользоваться следующими рекомендациями:

1.размещать на каждой диаграмме от 3 до 6-7 процессов.

2.не загромождать диаграммы не существенными на данном уровне деталями

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

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

Билет №18 Моделирование данных. Основные понятия

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

Билет №19-22 Методы моделирования данных

1)МЕТОД БАРКЕРА(Данная нотация используется в CASE-средстве Oracle Designer. . Метод Баркера можно пояснить на примере моделирования данных компании по торговле автомобилями. Исходными данными для построения ERD являются результаты интервью, проведенного с персоналом компании (Главные менеджер, Продавец, Администратор).Первый шаг моделирования — извлечение информации из интервью и выделение сущностей. Второй шаг моделирования — идентификация связей.Тр е т и й шаг моделирования — идентификация атрибутов.)

2)МЕТОД IDEF1(позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. Сущность в методе IDEF1X является не зависимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.Каждой сущности присваиваются уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.)

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

1)первичный/альтернативный: сущность может иметь несколько идентификаторов)

2)простой/составной: идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов — составным

3)абсолютный/относительный: если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным.

Билет №23 Сущность ООП-подохода к реализации

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

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

2) инкапсуляция (это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение);

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

4) иерархия (это ранжированная или упорядоченная система абстракций, расположение их по уровням).

Кроме основных имеются еще три дополнительных элемента:

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

2)параллелизм (свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.);

3)устойчивость (свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве ).

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

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

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

Билет №24 Унифицированный язык UML

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

Главными в разработке UML были следующие цели:

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

2)предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;

3)обеспечить независимость от конкретных языков программирования и процессов разработки;

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

5)стимулировать рост рынка объектно-ориентированных инструментальных средств;

6)интегрировать лучший практический опыт.

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

1)диаграммы классов (class diagrams) — для моделирования статической структуры классов системы и связей между ними;

2)диаграммы состояний (statechart diagrams) — для моделирования поведения объектов системы при переходе из одного состояния в другое;

3)диаграммы деятельностей (activity diagrams) — для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей;

4)диаграммы реализации (implementation diagrams):

диаграммы компонентов (component diagrams) — для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) — для моделирования физической архитектуры системы.

Билет №26 Диаграммы классов

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

1. ассоциации (например, клиент может сделать заказ);

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

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

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

2) аспект спецификации - модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);

3) аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

Билет №27 Ассоциации, атрибуты и операции

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

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

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

Билет №28 Механизм пакетов

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

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

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

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

Билет №29 Диаграммы взаимодействия

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

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

-Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

-Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

-Каждая Строка заказа проверяет состояние определенного Запаса товара:

Если данная проверка удовлетворяется (результат — true), то Строка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.

Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы.

Билет №30 Диаграммы последовательности.

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

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

Билет №31 Кооперативные диаграммы

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

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

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

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

Билет №32 Диаграммы состояний

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

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

Билет№33 Диаграммы деятельности

Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов. За каждой деятельностью может следовать другая деятельность. Такое следование образует простую последовательность. Например, за деятельностью Положить Кофе в Фильтр следует деятельность Вставить Фильтр в Автомат. Деятельность Поискать Напиток активизирует на выходе два действия.

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

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

1. анализ варианта использования

2. анализ потоков работ в различных вариантах использования

3. анализ взаимодействия объектов.

4. анализ поведения объекта в течение его жизненного цикла.

Билет №34 Диаграммы компонентов

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

Билет №35 Диаграммы размещения

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

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

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

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

ПК включает два компонента: пользовательский интерфейс и клиентскую часть приложения.

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

Билет№36 ADO.NET

Эта модель доступа к данным создана специально для использования в Web-приложениях. Если раньше в ADO упор делался на постоянное соединение с базой данных, то в технологии использования ADO.NET изначально заложена возможность работы приложения в состоянии "разрыва" соединения с базой данных. В ADO.NET обеспечивается возможность работы со всеми совместимыми с OLE DB источниками данных как в локальных сетях в рамках традиционных Windows-приложений, так и в глобальных сетях (Интернет) в рамках Web-приложений.

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

В объектной модели ADO.NET можно выделить несколько уровней.

1.Уровень данных. Это по сути дела базовый уровень, на котором располагаются сами данные (например, таблицы базы данных MS SQL Server).

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

3.Уровень приложения. Это набор объектов, позволяющих хранить и отображать данные на компьютере конечного пользователя.

ADO.NET для манипуляции с данными могут использоваться команды, реализованные в виде SQL-запросов или хранимых процедур (Datacommand). Например, если вы хотите получить некий набор информации базы данных, вы формируете команду SELECT или вызываете хранимую процедуру по ее имени.

В ADO.NET в качестве единого формата для передачи данных используется XML-формат.