0. Указатель/вопросы.
Жизненный цикл информационной системы (программного изделия) и пять его критических этапов: 1) анализ требований, 2) проектирование, 3) кодирование (программирование), 4) тестирование и отладка, 5) эксплуатация и сопровождение. Основные задачи этапов анализа требований и проектирования спецификаций системы.
Три модели жизненного цикла: 1) каскадная, 2) поэтапная с промежуточным контролем, 3) спиральная.
Понятие структурного системного анализа. Двенадцать принципов структурного анализа: принцип «разделяй и властвуй»; принцип иерархического упорядочивания, а также принципы: 1) абстрагирования, 2) формализации, 3) упрятывания, 4) концептуальной общности, 5) полноты, 6) непротиворечивости, 7) логической независимости, 8) независимости данных, 9) структурирования данных, 10) доступа конечного пользователя.
Базовые средства структурного анализа, иллюстрирующие: 1) функции, которые система должна выполнять; 2) отношения между данными. Соответствующие методики: 1) DFD (Data Flow Diagrams) — диаграммы потоков данных; 2) ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь». Их взаимосвязи и взаимовлияния. Компоненты логической модели.
Наиболее часто используемые инструментальные средства: функциональная модель SADT (Structured Analysis and Design Technique) или модель бизнес-процессов IDEF0, модель IDEF3. Их взаимосвязи и взаимовлияния. Компоненты логической модели.
Диаграммы потоков данных (DFD) как наиболее известные и часто используемые средства функционального моделирования. Основные и вспомогательные объекты диаграмм. Декомпозиция потока данных. Построение функциональной модели в виде иерархии диаграмм потоков данных.
Нотации Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson) диаграмм потоков данных (DFD). Четыре вида основных символов: 1) поток данных; 2) процесс; 3) хранилище (накопитель) данных; 4) внешняя сущность (терминатор). Контекстная диаграмма и детализация процессов.
Словарь данных как текстовое средство моделирования, предназначенное для описания структуры потоков и хранилищ данных. Содержимое словаря данных. Тип потока данных, атрибуты потока данных. Словарь проекта.
Спецификация процесса (миниспецификация) и наиболее часто применяемые методы ее задания: структурированные естественные языки, таблицы и деревья решений, визуальные языки проектирования. Аналитическое сравнение четырех различных методов.
Основные символы структурированного естественного языка и три его управляющие структуры: 1) последовательная конструкция; 2) конструкция выбора; 3) итерация. Соглашения, принятые при использовании структурированного естественного языка.
Таблица решений (матрица, отображающая множество входных условий в множество действий) — шаги построения. Таблица решений и дерево решений — рекомендации по предпочтениям.
Визуальные языки проектирования спецификаций — FLOW-формы и четыре вида их символов: последовательная обработка, условный выбор, case-выбор, циклы. Особенности диаграмм Насси-Шнейдермана.
Диаграммы «сущность-связь» (ERD) как базовые средства информационного моделирования. Нотации Чена и Баркера и их средства моделирования данных (наиболее популярные). Этапы построения информационной модели, включая нормализацию. ER-подход.
Шесть видов символов ERD в нотации Чена: 1) независимая сущность; 2) зависимая сущность; 3) ассоциированная сущность; 4) неограниченное (обязательное) отношение; 5) ограниченное (необязательное) отношение; 6) существенно-ограниченное отношение. Пять значений связи («0 или 1»,«0 или более»,«1»,«1 или более»,«p:q»). Три типа отношений: 1*1 (один к одному); 1*n (один к многим); n*m (многие к многим). Диаграммы атрибутов.
Категоризация сущностей. Общая сущность, сущность-категория. Декомпозиция сущности на категории. Узел-дискриминатор и диаграммы категоризации.
Нотация Баркера для ERD: графические особенности; подтип и супертип. Характеристики сущности и связи. Три этапа построения модели ERD: 1) Идентификация сущностей, их атрибутов, первичных и альтернативных ключей; 2) Идентификация отношений между сущностями и указание типов отношений; 3) Разрешение неспецифических отношений (т.е. типа n*m).
Нотация модели ERD – метод IDEF1. Независимы и зависимые сущности. Идентифицирующая и неидентифицирующая связь. Мощность связей. Создание и уровни логической модели данных в ERWin.
Концепции и методы нормализации; первая, вторая и третья нормальные формы нормализованных схем по Кодду (Codd); алгоритм приведения в 3НФ. Разрешение неспецифического отношения.
Модель требований (или логическая модель) системы, как совокупность множества взаимосвязанных диаграмм (IDEF0, DFD, IDEF3, ERD), текстов и словаря данных. Назначение модели требований — описание, что должна делать система без ссылок на то, как это делается.
Проектирование как фаза жизненного цикла, на которой вырабатывается реализация требований пользователя, порожденных и зафиксированных на фазе анализа. Построение модели реализации (или физической модели), демонстрирующей, как система будет удовлетворять предъявленным к ней требованиям. Модель реализации как расширение модели требований, состоящее из взаимосвязанных диаграмм , текстов и словаря данных.
Сущность и принципы объектно-ориентированного подхода (ООП). Отличие от структурного подхода. Концептуальная основа ООП. Основные понятия. Конечный результат.
Унифицированный язык моделирования UML. Цели разработки языка. Содержание стандарта UML версии l.1, принятый в 1997 г.
Диаграммы вариантов использования. Назначение, компоненты. Типы действующих лиц. Типы связей.
Диаграммы классов. Аспекты использования. Компоненты. Стереотипы классов. Типы отношений.
Диаграммы состояний. Их назначение, использование и компоненты.
Диаграммы взаимодействия объектов. Их назначение, использование и компоненты.
Диаграммы деятельностей. Их назначение, использование и компоненты.
Принципиальное различие, сравнение и взаимосвязь структурного и объектно-ориентированного подходов.
Концептуальные основы CASE (Computer-Aided Software/System Engineering)-технологий. Эволюция CASE как самостоятельной дисциплины в программотехнике.
Шесть этапов CASE-модели жизненного цикла программного продукта (прототипирование — проектирование спецификаций — контроль проекта — кодогенерация — системное тестирование — сопровождение) и ее отличия от пяти этапов традиционной модели (анализ — проектирование — кодирование — тестирование — сопровождение). Сравнение традиционной разработки программных проектов и разработки с применением CASE-технологий.
CASE-средства автоматизации методологий системного анализа и проектирования. Состав, структура и функциональные особенности современных CASE-средств. Архитектура CASE—пакета: 1) средства централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозиторий); 2) редактор диаграмм; 3) верификатор диаграмм; 4) администратор проекта; 5) документатор проекта.
Схема постановки и решения задачи: 1) формулирование задачи (1. формулирование цели, 2. описание исходных данных, 3. формулирование модели, 4. формулирование результата, 5. формулирование критерия оценки результата); 2) формализация задачи (1. формализация цели, 2. определение объектов и свойств, 3. определение способов вычисления свойств, 4. формирование таблицы «объекты-свойства», 5. формализация критерия оценки результата); 3) выбор способа решения задачи (1. определение возможности использования ЭВМ, 2. выбор математического аппарата для решения задачи, 3. определение алгоритмов решения, 4. формирование схемы обработки данных); 4) решение задачи (1. составление технологической схемы обработки, 2. прохождение технологической схемы на ЭВМ, 3. анализ результата с помощью критерия оценки); 5) интерпретация результата (1. согласование результата с моделью, 2. дальнейшее использование результата).
Классификация CASE-средств по типам (анализ и проектирование; проектирование баз данных и файлов; программирование; сопровождение и реинжениринг; окружение; управление проектом), по категориям (tools — вспомогательная программа; toolkit — пакет разработчика; workbench — инструментальное средство) и по уровням (Upper CASE; Middle CASE; Lower CASE).
Пример инструментального средства — пакет ERWin. Основные функции пакета и особенности используемых средств структурного системного анализа.
Пример инструментального средства — пакет AllFusion Process Modeler (BPWin). Основные функции пакета и особенности используемых средств CCA.
Технология проектирования: понятие, виды, классификация.
АСОИУ: назначение, особенности, сферы применения.
1. Жизненный цикл информационной системы (программного изделия) и пять его критических этапов: 1) анализ требований, 2) проектирование, 3) кодирование (программирование), 4) тестирование и отладка, 5) эксплуатация и сопровождение. Основные задачи этапов анализа требований и проектирования спецификаций системы.
Проектирование ИС — процесс перехода от первичного описания ИС в виде технического задания к описанию ее в виде проектной документации, достаточного для создания системы. Технологии проектирования предполагают поэтапную разработку системы. Этапы разработки могут разделяться на стадии.
Жизненный цикл (ЖЦ) — совокупность стадий и этапов, которые проходит система, а также период времени, начинающийся между моментом принятия решения о создании системы и моментом прекращения функционирования системы. Цикл — процесс создания и развития ПО.
Жизненный цикл разработки системы включает следующие стадии:
1. Предпроектная. Планирование, анализ требований. Разработка концепции ИС. Исследование и анализ существующей системы, цели ИС анализ требований создаваемой ИС, оформление ТЗ на разработку ИС. Описание потоков данных ИС (входные, выходные), роли пользователей ИС и т.д.
2. Проектирование (техническое, логическое). Необходимо дать ответ на вопрос, как система будет реализовывать предъявленные к ней требования. Выработка архитектуры системы, разбиение на подсистемы и распределение функций между ними, проектирование базы данных.
3. Реализация проекта (программирование). Разработка и настройка программ, наполнение баз данных, создание рабочих инструкций для персонала.
4. Тестирование и отладка созданных программ, внедрение. [3 вида тестов.] Тесты модулей — тестирование отдельных классов, модулей. Интеграционные/компонентные тесты — тестирование взаимодействия модулей системы между собой. Системные тесты — тестирование системы в целом (как ее видит конечный пользователь).
Поэтапное внедрение системы в эксплуатацию, оформление акта о приемо-сдаточных испытаниях системы.
5. Эксплуатация (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании системы, исправление ошибок и недоработок, оформление требований к модернизации системы и ее выполнение.
Задачи этапа анализа требований.
Установление «границ» системы. Проблема «растяжения рамок». Программист не должен добавлять в систему то что захочет, т. к. это растягивает время реализации. Чтобы пресечь такое растяжение времени, устанавливаются рамки. Программист реализует систему только в установленных рамках (следуя требованиям).
Формализация требований. Некоторые задачи, которые ставит заказчик, могут пониматься разными людьми по разному (программист может реализовать не то, что имел в виду заказчик); могут быть нечетко сформулированы и т. п. Этот этап также предназначен для установления четких и понятных требований.
Уточнение требований. На этапе может возникнуть ситуация, когда собранные требования являются неполными или противоречивыми. Тогда следует уточнять у заказчика непонятные моменты и фиксировать все, что необходимо разработчикам и проектировщикам для реализации данных требований.
Структуризация требований. Декомпозиция, категоризация. Декомпозиция — детализация, разбиение задач на более мелкие. Категоризация — структурирование по функциональным областям (# областей: требования к поиску инфы, бизнес-требования, требования к возможностям пользователя).
Определение приоритетов. Приоритеты характеризуют важность требований и сроки их реализации. Заказчики и пользователи определяют функциональность, которую они хотят получить в первую очередь и согласовывают ее с разработчиками. С помощью приоритетов можно планировать этапы разработки, релизы ПО. Обычно используется 3 значения: высокий, средний и низкий.
Анализ требований включает 3 типа деятельности:
Сбор требований. Взаимодействие с заказчиком и пользователями для определения их требований.
Анализ требований. Анализ на корректность (понятность, полнота, однозначность, противоречивость) и решение проблем, если таковые имеются.
Документирование требований. Требования могут быть задокументированы в различных формах — простое описание, сценарии использования, пользовательские истории, спецификации процессов.
Задачи этапа проектирования.
Исследование структуры системы и взаимосвязей ее элементов.
В результате деятельности на этапах анализа и проектирования должен быть получен проект системы, содержащий достаточно информации для реализации системы на его основе в рамках выделенных ресурсов и времени.
2. Три модели жизненного цикла: 1) каскадная, 2) поэтапная с промежуточным контролем, 3) спиральная.
Модель жизненного цикла — структура, определяющая последовательность выполнения и связи процессов, действий и задач на протяжении ЖЦ. Каскадная и спиральная модели — одни из самых распространенных.
1. Каскадная модель разбивает ЖЦ на 5 этапов, выполняемых последовательно:
Недостатки:
Часто возникает потребность в возврате к предыдущим этапам для уточнения или пересмотра ранее принятых решений. В результате модель принимает вид “модели с промежуточным контролем”.
Существенное запаздывание с получением результатов.
Требования к ИС "заморожены" в виде ТЗ на все время ее создания, и в случае неточного изложения требований или их изменения за время создания ПО, модель автоматизируемого объекта устаревает к моменту реализации.
2. Модель с промежуточным контролем. Основные этапы аналогичны каскадной модели. Итерационная модель разработки с циклами обратной связи между этапами.
Достоинства:
Возможность поэтапной корректировки.
Возможность возврата к предыдущему этапу.
Недостатки:
Сложность оценки трудоемкости из-за повторений.
Сложность оценки качества.
Требует жесткого управления и контроля.
3. Спиральная модель. Делает упор на начальные этапы — анализ и проектирование. Реализуемость технических решений проверяется на этих этапах созданием прототипов. Позволяет преодолеть большинство недостатков каскадной модели.
Каждый виток спирали соответствует созданию фрагмента или версии ПО. Главная задача при работе по спиральной модели — как можно быстрее показать пользователю работоспособный продукт, чтобы уточнить и дополнить требования.
Достоинства:
Разбиение большого объема работы на небольшие части, в которых сначала реализуются наиболее приоритетные функции.
Активное участие пользователей.
Гибкий процесс разработки. Предполагает возможность эволюции ЖЦ, развитие и изменение ПО. Существенно упрощено внесение изменений в проект при изменении требований.
Повышенная вероятность предсказуемого поведения системы. Отдельные элементы ИС интегрируются постепенно. Интеграция производится фактически непрерывно. Она начинается с небольшого количества элементов, поэтому возникает гораздо меньше проблем при ее проведении.
Уменьшение уровня рисков. Риски обнаруживаются во время интеграции, поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый уровень рисков снижается с большой скоростью. Интеграция выполняется уже на первой итерации и в начале выявляются многие аспекты проекта (пригодность используемых инструментальных средств и ПО, квалификация разработчиков и т. п.).
Упрощает повторное использование компонентов. Гораздо проще выявить общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться.
Повышение надежности и устойчивости системы. Ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы.
Отсутствие различий между разработкой нового ПО и изменением существующего.
Недостатки:
Определение момента перехода на следующий этап — основная проблема спирального цикла. Для ее решения обычно вводятся временные ограничения на каждый из этапов жизненного цикла. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
3. Понятие структурного системного анализа. Двенадцать принципов структурного анализа: принцип «разделяй и властвуй»; принцип иерархического упорядочивания, а также принципы: 1) абстрагирования, 2) формализации, 3) упрятывания, 4) концептуальной общности, 5) полноты, 6) непротиворечивости, 7) логической независимости, 8) независимости данных, 9) структурирования данных, 10) доступа конечного пользователя.
Структурный подход к разработке ИС заключается в ее декомпозиции. Система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и т. д. Процесс разбиения продолжается вплоть до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. При разработке системы "снизу-вверх" от отдельных задач к системе целостность теряется, возникают проблемы при стыковке отдельных компонентов.
Принципы структурного анализа. 2 базовых принципа:
Принцип «разделяй и властвуй». Решение сложных проблем разбиением их на множество меньших независимых задач, легких для понимания и решения.
Принцип иерархического упорядочения. Организация составных частей проблемы в иерархические древовидные структуры.
Игнорирование любого из дополнительных принципов может привести к непредсказуемым последствиям. Остальные принципы:
1) Принцип абстрагирования. Выделение существенных аспектов системы и отвлечение от несущественных.
2) Принцип формализации. Необходимость строгого методического подхода к решению проблемы.
3) Принцип упрятывания. Сокрытие информации, лишней на конкретном этапе — каждая часть "знает" только необходимую ей информацию.
4) Принцип концептуальной общности. Применение единого подхода к проектированию на всех этапах ЖЦ (структурный анализ, структурное проектирование, структурное программирование, структурное тестирование).
5) Принцип полноты. Контроль на присутствие лишних элементов.
6) Принцип непротиворечивости. Согласованность элементов — каждый элемент системы независим и не вступает в конфликт с остальными.
7) Принцип логической независимости. Концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования.
8) Принцип независимости данных. Модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, физической структуры и распределения.
9) Принцип структурирования данных. Данные должны быть структурированы и иерархически организованы.
10) Принцип доступа конечного пользователя. Пользователь должен иметь средства доступа к базе данных, которые он может использовать без программирования.
Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независимо от типа разрабатываемого ПО и используемых методологий. Руководствуясь всеми принципами, можно на ранних стадиях понять, что будет представлять из себя создаваемая ИС, обнаружить промахи и недоработки, что облегчит работу в дальнейшем (на следующих этапах ЖЦ) и понизит стоимость разработки.
4. Базовые средства структурного анализа, иллюстрирующие: 1) функции, которые система должна выполнять; 2) отношения между данными. Соответствующие методики: 1) DFD (Data Flow Diagrams) — диаграммы потоков данных; 2) ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь». Их взаимосвязи и взаимовлияния. Компоненты логической модели.
Для целей моделирования систем, и структурного анализа в частности, используются три группы средств, иллюстрирующих:
функции, которые система должна выполнять,
отношения между данными,
зависящее от времени поведение системы (аспекты реального времени),
Для решения этих задач наиболее часто и эффективно применяются следующие:
DFD (Data Flow Diagrams) — диаграммы потоков данных, совместно со словарями данных и спецификациями процессов (миниспецификациями).
ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".
STD (State Transition Diagrams) — диаграммы переходов состояний.
Все они содержат графические и текстовые средства моделирования: первые — для удобства визуального представления и демонстрации основных компонент модели, вторые — для обеспечения точного определения ее компонент и связей.