22
приведено описание этапов жизненного цикла АИС, рассмотрены основные
модели ЖЦ, описаны термины проектирования АИС и основные технологии
для этого.
23
ГЛАВА 2. ПРИНЦИПЫ РАЗРАБОТКИ АИС
2.1. Технологии проектирования ИС
Методологии, технологии, инструментальные средства проектирования
(так называемые CASE-средства) составляют базу проекта любой АИС.
Методология реализуется с помощью конкретных технологий и
поддерживают их стандарты, инструментальные средства и методики,
которые обеспечивают реализацию процессов ЖЦ.
Технологии проектирования определяются как множество трех
компонентов:
– пошаговой процедуры, которая определяет последовательность
технологических действий проектирования (рисунок 9);
– критериев, правил, применяемых для оценки результатов
реализации технологических операций;
– подходов (графических или текстовых средств), применяемых для
описания проектируемой АИС.
Рисунок 9 – Представление операции проектирования
Технологические инструкции, которые составляют основное
содержание технологий, должны состоять с описания последовательности
24
операций, условий, по которым выполняется операция, и описания самих
операций. [22]
Технология разработки, проектирования, сопровождения АИС должна
удовлетворять таким требованиям:
– технология должна выполнять поддержку полного ЖЦ ПО АИС;
– технология должна обеспечивать достижение целей разработки
АИС;
– технология должна обеспечивать все возможности выполнения
крупных проектов как подсистем (возможность декомпозиции программного
проекта на составные компоненты, разрабатываемые группами создателей
ограниченного количества с последующей интеграцией компонентов).
Опыт разработки АИС показывает, что для увеличения эффективности
работ надо разбить проект на слабо связанные отдельные по функциям и
данным подсистемы.
Реализация таких подсистем должна выполняться также отдельными
группами разработчиков. При этом надо обеспечивать координацию ведения
проекта и исключить процесс дублирования результатов работ для каждой
проектной группы, что может возникнуть по наличию общих данных или
функций;
– технология должна давать возможность для ведения работ по
разработке проекта отдельных подсистем группами (3-7 человек). Стоит
отметить, что это обусловлено принципами управляемости персонала и
повышения производительности с помощью минимизации количества
внешних связей;
– технология должна выполнять обеспечение минимального
времени получения работоспособной ИС. Стоит отметить, что речь идет не
непосредственно о сроках готовности АИС, а о сроках для реализации
отдельных ее подсистем.
Реализация АИС в целом в самые короткие сроки может требовать
привлечения огромного числа разработчиков, а эффект может оказаться
25
немного ниже, чем при непосредственной реализации его отдельных
подсистем в более короткие сроки меньшим количеством разработчиков.
Практика показывает, при наличии завершенного полностью проекта,
внедрение выполняется последовательно по подсистемам; [14]
– технология должна предусматривать все возможности для
управления конфигурацией программного проекта, ведения его версий и
составляющих, возможность выпуска автоматической проектной
документации;
– технология должна обеспечивать полную независимость
выполняемых решений по проекту от средств реализации АИС (систем
управления БД (СУБД), операционных систем (ОС), ЯП и систем
программирования проекта);
– технология должна поддерживаться комплексом согласованных
ранее CASE-средств, обеспечивающих полную автоматизацию процессов,
которые выполняются на всех стадиях выполнения ЖЦ.
Реальное применение практически любой технологии проектирования,
сопровождения и разработки АИС в конкретной организации или конкретном
проекте невозможно без выполнения выработки ряда стандартов
(специальных правил, соглашений), что должны соблюдаться полностью
всеми участниками проекта.
Стоит отметить, что к таким стандартам можно отнести такие:
– стандарт оформления документации;
– стандарт проектирования;
– стандарт разработки пользовательского интерфейса.
Стандарт проектирования АИС должен устанавливать такие основные
параметры: [2]
– набор необходимых моделей (или диаграмм) для каждой стадии
проектирования;
– правила фиксации разного рода проектных решений на
специальных диаграммах, в том числе: правила именования объектов, набор
26
атрибутов по всем объектам и правила для их заполнения на стадиях, правила
оформления созданных диаграмм, включая все требования к размерам и форме
объектов, и т. п.;
– требования к реализации конфигурации рабочих мест
программистов, включая настройки ОС, настройки применяемых CASE-
средств и т. п.;
– механизм совместного обеспечения работы над выполняемым
проектом:
1) правила интеграции всех подсистем проекта;
2) правила поддержки проекта в одинаковом состоянии для всех
разработчиков;
3) правила проверки разных проектных решений на их
непротиворечивость.
Стандарт оформления документации должен устанавливать такие
требования:
– комплектность, структуру и состав документации на каждой из
стадий проектирования;
– требования для ее оформления (включая требования по
содержанию разделов, пунктов и т.п.),
– правила рассмотрения, подготовки, согласования или
утверждения документации с непосредственным указанием предельных
сроков выполнения;
– требования к непосредственной настройке издательских систем,
используемых в качестве встроенных средств подготовки документации;
– требования по настройке CASE-средств при обеспечении
подготовки документации.
Стандарт пользовательского интерфейса должен устанавливать такие
атрибуты:
– правила оформления экранов, расположение и состав окон и
компонентов управления;
27
– правила для использования мыши и клавиатуры;
– правила для оформления текстов;
– перечень сообщений;
– правила для обработки реакции на действия пользователя.
Стоит отметить, что самым популярным подходом для проектирования
АИС является структурный подход.
Сущность рассматриваемого подхода заключается в поэтапной
декомпозиции каждой составной части АИС на специальные
автоматизируемые функции. [39]
Процесс разбиения системы часто продолжается до того момента, пока
не получаться конкретные функций или процедуры непосредственно которые
можно уже «разобрать» на программные операторы.
На рисунке 10 показан пример использования этих двух подходов:
Рисунок 10 – Пример методов проектирования
При проектировании ПО по направлению "снизу-вверх" от самых
подробных задач постепенно к полностью всей ИС, ее целостность может не
28
применяться, при этом очень часто начинаются проблемы в плане
информационной совместимости.
Все наиболее современные методологии, которые применяются в
структурном подходе базируются на перечне нескольких принципов, а
именно:
– принцип иерархического упорядочивания;
– принцип под названием "разделяй и властвуй".
Стоит отметить, что в работе присутствуют и второстепенные
принципы, главными из которые являются:
– принцип абстрагирования;
– принцип формализации;
– принцип непротиворечивости;
– принцип структурирования информации.
В структурном анализе применяются в основном 2 группы средств,
которые иллюстрируют функции, выполняемые системой, а также отношения
между используемыми данными.
Каждой такой группе средств соответствуют виды моделей (или
диаграмм), наиболее распространенными для которых являются такие
подходы: [36]
– SADT;
– DFD;
– ERD.
2.2. Этапы проектирования ИС
Основой каждой АИС является хранилище данных, которое
представлено разработанной БД. То есть, без правильно созданной БД
функционирование АИС практически невозможно.
После реализации самых первых стадий ЖЦ, а именно, анализ и
планирование, определение требований для АИС, сбор и анализ будущих
29
пользователей, начинается процесс непосредственной разработки ядра АИС,
которым является база данных.
Эта последовательность действий включает в себя полный цикл
разработки базы и начинается с реализации концептуального
проектирования.[3]
Первая стадия рассматриваемого процесса проектирования состоит в
создании анализируемой части инфологической модели данных (МД). Стоит
отметить, что почти всегда ее отображают в реляционном варианте (рисунок
11):
Рисунок 11 – Пример инфологической модели
Построение ее можно осуществить по четкой последовательности:
– создание представлений;
– интеграция представлений в концептуальную МД.
30
Проектирование более сложных АИС разными атрибутами
осуществляется применение так называемого нисходящего подхода, который
использует такую последовательность:
– разработка МД с сущностями и связями;
– выполнение нисходящих уточнений. [33]
Концептуальная модель – это описание, которое реализуется с
использованием человеческих языков, формул, графиков и иных методов, что
являются полностью понятными всем людям, которые работают над базой
АИС.
Самой главной целью концептуального моделирования считается
возможность обеспечение самых естественных способов для представления
той информации, что будет хранится в разрабатываемой БД.
В результате концептуальную МД пытаются построить аналогично с
человеческим языком.
Самыми главными конструктивными компонентами для
концептуальных моделей будут сущности, а также атрибуты, связи между
ними. [27]
При определении так называемой концептуальной модели необходимо
принять во внимание такое:
– БД АИС должна удовлетворять вновь возникающим требованиям
для всех пользователей;
– БД АИС легко должна расширяться при расширении предметной
области;
– БД АИС должна изменяться при изменении аппаратной и
программной среды.
Целью разработки модели данных является практическое обеспечение
разработчика ИС схемы БД в форме определенной модели или нескольких
локальных, которые легко могут относительно быть отображены в систему
БД.
31
Наиболее распространенным инструментом моделирования данных
считаются диаграммы "сущность-связь" (ER-диаграммы) (рисунок 12).
Рисунок 12 – Пример ER-диаграммы в нотации П.Чена
С их помощью могут определяться важные для области применения
объекты (сущности), а также их свойства (параметры) и отношения друг с
другом.
После этого непосредственно концептуальная МД уточняется и
преобразуется в так называемую логическую МД. [21]
Дальнейшее проектирование БД АИС будет опираться на так
называемую реляционную МД, поэтому на этапе ее логического
проектирования рассмотрим подробно проектирование реляционной БД для
АИС.