IV. Проектирование информационных систем

1. Жизненный цикл программного изделия. Модели жизненного цикла.

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

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

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

1. Предпроектная. Планирование, анализ требований. Разработка концепции ИС. Исследование и анализ существующей системы, цели ИС анализ требований создаваемой ИС, оформление ТЗ на разработку ИС. Описание потоков данных ИС (входные, выходные), роли пользователей ИС и т.д.

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

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

4. Тестирование и отладка созданных программ, внедрение. [3 вида тестов.] Тесты модулей — тестирование отдельных классов, модулей. Интеграционные/компонентные тесты — тестирование взаимодействия модулей системы между собой. Системные тесты — тестирование системы в целом (как ее видит конечный пользователь).

Поэтапное внедрение системы в эксплуат., оформление акта о приемо-сдаточных испытаниях системы.

5. Эксплуатация (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании системы, исправление ошибок и недоработок, оформление требований к модернизации и ее выполнение.

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

1. Каскадная модель разбивает ЖЦ на 5 этапов, выполняемых последовательно:

Недостатки:

· Часто возникает потребность в возврате к предыдущим этапам для уточнения или пересмотра ранее принятых решений. В результате модель принимает вид “модели с промежуточным контролем”.

· Существенное запаздывание с получением результатов.

· Требования к ИС "заморожены" в виде ТЗ на все время ее создания, и в случае неточного изложения требований или их изменения за время создания ПО, модель автоматизируемого объекта устаревает к моменту реализации.

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

Достоинства:

· Возможность поэтапной корректировки.

· Возможность возврата к предыдущему этапу.

Недостатки:

· Сложность оценки трудоемкости из-за повторений.

· Сложность оценки качества.

· Требует жесткого управления и контроля.

3. Спиральная модель. Делает упор на начальные этапы — анализ и проектирование. Реализуемость технических решений проверяется на этих этапах созданием прототипов. Позволяет преодолеть большинство недостатков каскадной модели.

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

Достоинства:

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

· Активное участие пользователей.

· Гибкий процесс разработки. Предполагает возможность эволюции ЖЦ, развитие и изменение ПО. Существенно упрощено внесение изменений в проект при изменении требований.

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

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

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

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

· Отсутствие различий между разработкой нового ПО и изменением существующего.

Недостатки:

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

2. Сущность структурного и объектно-ориентированного подходов к проектированию информационных систем.

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

Принципы структурного анализа. 2 базовых принципа:

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

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

Игнорирование любого из дополнительных принципов может привести к непредсказуемым последствиям. Остальные принципы (всего 12):

1) Принцип абстрагирования. Выдел. существ. аспектов системы и отвлеч. от несуществ.

2) Принцип формализации.

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

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

5) Принцип полноты. Контроль на присутствие лишних элементов.

6) Принцип непротиворечивости. Согласованность элементов — каждый элемент системы независим и не вступает в конфликт с остальными.

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

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

Для решения этих задач наиболее часто и эффективно применяются следующие нотации: DFD (Data Flow Diagrams) — диаграммы потоков данных вместе с словарями данных и спецификациями процессов, ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь", STD (State Transition Diagrams) — диаграммы переходов состояний.

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

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

В процессе проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования.

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

Процесс разработки системы позволяет решить следующие задачи:

· определение перечня артефактов, которые должны быть разработаны;

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

· определение задач отдельных исполнителей и всей группы разработчиков в целом;

· выбор критериев контроля и оценки полученных результатов.

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

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

Говоря об объектно-ориентированном подходе, в первую очередь отмечают наследование, инкапсуляцию и полиморфизм. Эти механизмы и принципы проектирования более естественно и полно реализованы в объектно-ориентированном подходе по сравнению со структурным.

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

В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:

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

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

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

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

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

о повторного использования компонентов;

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

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

3. Диаграммы потоков данных (DFD). Основные и вспомогательные объекты диаграмм. Построение функциональной модели в виде иерархии диаграмм потоков данных.

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

Основные объекты DFD (символы).

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

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

· Внешняя сущность (терминатор) — внешний по отношению к системе объект, обменивающийся с ней информационными потоками. Предполагается, что не участвует в обработке. [Вспомогательный?]

· Хранилище данных (накопитель) — структура для хранения информационных объектов. «Срез» потока во времени. [Вспомогательный?]

Детализация/декомпозиция, иерархия диаграмм.

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

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

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

4. Диаграммы «сущность – связь» (ERD). Типы отношений (один к одному, один к многим, многие ко многим). Построение схемы базы данных на основе ERD диаграмм.

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

Данная нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор средств моделирования данных, включая ERD, диаграммы атрибутов, диаграммы декомпозиции. Эти диаграммные техники используются для проектирования реляционных баз данных.

Сущности, отношения и связи в нотации Чена

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

Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

Типы отношений:

1) 1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.

2) 1*п (один-к-многим). Отношения данного типа являются наиболее часто используемыми.

3) n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных ассоциативных сущностей и с введением новых отношений).

Пример: каждый БАНК ИМЕЕТ один или более БАНКОВСКИХ СЧЕТОВ. Кроме того, каждый КЛИЕНТ МОЖЕТ ВЛАДЕТЬ (одновременно) одной или более КРЕДИТНОЙ КАРТОЙ и одним или более БАНКОВСКИМ СЧЕТОМ, каждый из которых ОПРЕДЕЛЯЕТ в точности одну КРЕДИТНУЮ КАРТУ (отметим, что у клиента может и не быть ни счета, ни кредитной карты). Каждая КРЕДИТНАЯ КАРТА ИМЕЕТ только один зависимый от нее ПАРОЛЬ КАРТЫ, а каждый КЛИЕНТ ЗНАЕТ (но может и забыть) ПАРОЛЬ КАРТЫ.

Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей. Учитывает такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п.

Построение схемы базы данных на основе ERD диаграмм:

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

· Список сущностей предметной области.

· Список атрибутов сущностей.

· Описание взаимосвязей между сущностями.

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