ВВЕДЕНИЕ. Разработка информационной системы подчиняется определённому жизненному циклу (lifecycle)

Разработка информационной системы подчиняется определённому жизненному циклу (lifecycle). Жизненный цикл определяет этапы, так что информационная система переходит с одного этапа на другой, начиная с зарождения концепции системы и заканчивая этапом её сворачивания. Жизненный цикл разработки системы может быть представлен с различной степенью детализации этапов. На укрупнённом уровне жизненный цикл может включать только три этапа:

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

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

Граница между анализом и проектированием очень размыта. Эти понятия определены на общей непрерывной области.

Анализ Проектирование

что, требования, как,

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

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

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

1. Установление требований.

2. Спецификация требований.

3. Проектирование архитектуры.

4. Детализированное проектирование.

5. Реализация.

6. Интеграция.

7. Сопровождение (или окончательное сворачивание).

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

Задачей этапа определения требований является определение, анализ и обсуждение требований с заказчиками.

Этап спецификации заключается в моделировании требований с использованием определённого метода (например, UML). В моделях спецификации предлагаемое решение рассматривается с разных точек зрения, проверяется непротиворечивость и полнота требований.

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

Архитектурное проектирование представляет собой описание системы в терминах составляющих её модулей. Выбор основных модулей современной информационной системы должен соответствовать трёхзвенной архитектуре (three-tier architecture). Решаются вопросы, касающиеся клиентской (пользовательский интерфейс) и серверной (база данных) частей системы, а также логики приложения. Логика приложения может поддерживаться или не поддерживаться отдельным аппаратным обеспечением. Уровень логики приложения может выполняться на клиентской машине или на сервере, т.е. он скомпилирован в виде клиентского или серверного процесса и реализован как динамически подключаемая библиотека (Dynamic Link Library – DLL), интерфейс прикладного программирования (Application Programming Interface – API), удалённый вызов процедуры (Remote Procedure Calls) и т.д.

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

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

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

Сопровождение состоит из различных стадий: поддержка эксплуатации; адаптивное сопровождение; эволюционное сопровождение. Поддержка эксплуатации (housekeeping) связана с задачами сопровождения, необходимыми для поддержания системы в состоянии готовности к применению пользователями. Адаптивное сопровождение (adaptive maintenance) связано с анализом работы системы, настройкой её функционирования применительно к изменениям внешней среды и адаптацией системы для достижения заданной производительности и пропускной способности. Под эволюционным сопровождением (perfective maintenance) понимают модификацию системы для удовлетворения новых или существенно изменившихся требований.

В конечном итоге продолжение сопровождения системы становится нецелесообразным. Сворачивание (phasing out) обычно осуществляется по причинам, которые имеют мало общего с утратой полезности программного обеспечения. Система по-прежнему может оставаться вполне пригодной для использования, однако становится непригодной для дальнейшего сопровождения. К самым распространённым причинам изъятия системы из эксплуатации относятся следующие:

1. Архитектура системы не удовлетворяет предлагаемым изменениям.

2. Отсутствие надлежащей документации для расширения системы.

3. Аппаратная и/или программная платформы, на которых реализована система, подлежит замене, а видимых путей для адаптации нет.

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

1. Тестирование по спецификации (по методу “чёрного ящика”).

2. Тестирование по программному коду (по методу “белого ящика”).

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

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

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

Целью настоящего курса является:

- изучение создания моделей анализа и проектирования;

- изучение создания различных диаграмм языка UML;

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

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

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

В качестве инструментального средства проектирования изучается Rational Rose 2001, в качестве языка моделирования изучается унифицированный язык моделирования UML (Unified Modeling Language). Рассматриваются прикладные аспекты использования объектной технологии моделирования информационных систем для решения практических задач.

Основная идея объектно-ориентированного анализа и проектирования (Object-Oriented Analysis and Design), которые изучаются в данной дисциплине, состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий или сущностей). Например, в случае библиотечной информационной системы среди понятий и сущностей реального мира будут присутствовать Библиотека, Клиент, Книга. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и операции. Например, программный объект CBook (Книга) может содержать атрибут Title (Название), операцию Give (Выдать книгу).

Объектная технология даёт возможность работы с новым стилем программирования, управляемым событиями (event-driven), – который поддерживается современными GUI -интерфейсами. Программа состоит из программных объектов, которые выполняются случайным, непредсказуемым образом, и программа не завершается до тех пор, пока пользователь не прекратит её выполнение. Объекты “бездействуют”, ожидая наступления инициированного пользователем события, чтобы начать вычисление; для выполнения задачи они могут запросить другие объекты о предоставлении им услуги, после чего снова впадают в “спячку”, но сразу “поднимаются по тревоге” – стоит только пользователю инициировать другое событие.

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

Дата добавления: 2014-01-07