1) Анализ средств проектирования информационных систем
Современные СП могут быть разделены на две большие категории. Первую составляют CASE- системы (как независимые (upper CASE), так и интегрированные с СУБД), обеспечивающие проектирование БД и приложений в комплексе с интегрированными средствами разработки приложений "клиент-сервер" (например, Westmount I-CASE+Uniface, Designer/2000+Developer/2000). Их основное достоинство заключается в том, что они позволяют разрабатывать всю ИС целиком (функциональные спецификации, логику процессов, интерфейс с пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой категории, как правило, обладают существенной сложностью, широкой сферой применения и высокой гибкостью. Вторую категорию составляют собственно средства проектирования БД, реализующие ту или иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в комплексе со средствами разработки приложений. К средствам этой категории можно отнести такие, как SILVERRUN+JAM, ERwin/ERX+PowerBuilder и др. Помимо указанных категорий, СП можно классифицировать по следующим признакам:
степени интегрированности: (отдельные локальные средства, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС и полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
степени открытости;
доступным платформам.
В разряд СП попадают как относительно дешевые системы для персональных компьютеров (ПК) с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-систем, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами. Применение СП требует от потенциальных пользователей специальной подготовки и обучения. Опыт показывает, что внедрение СП осуществляется медленно, однако по мере приобретения практических навыков и общей культуры проектирования эффективность применения этих средств резко возрастает, причем наибольшая потребность в использовании СП испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки. На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми СП:
Westmount I-CASE;
Uniface;
Designer/2000+Developer/2000 (ORACLE);
SILVERRUN+JAM;
ERwin/ERX+PowerBuilder.
Приведенный список не претендует на полноту. Кроме того, на рынке постоянно появляются как новые (для отечественных пользователей) системы, так и новые версии и модификации перечисленных систем (например, CASE/4/0, System Architect и т.д.). Таблица характеристик СП
-
СП
West-mount I-CASE + Uniface
Designer/2000+Developer/2000
SILVER-RUN + JAM
ERwin/ERX + PowerBuilder
Поддержка полного жизненного цикла ИС
+
+
+
+
Обеспечение целостности проекта
+
+
-
-
Независимость от платформы
+ (ORACLE, Informix, Sybase, Ingres и другие, dbf-файлы)
- (целевая СУБД - только ORACLE)
+ (ORACLE, Informix, Sybase, Ingres и другие)
+ (ORACLE, Informix, Sybase, поддержка ODBC)
Одновременная групповая разработка БД и приложений
+
- *)
- *)
- *)
*) разработчики приложений могут начинать работу с базой данных только после завершения ее проектирования.
Несмотря на некоторые недостатки, я буду использовать Designer/2000+Developer/2000.
По оценке аналитической компании Gartner, PowerDesigner является инструментальным средством моделирования №1 в мире! Важной особенностью PowerDesigner является то, что для построения указанных моделей менеджерам и бизнес-аналитикам не требуется помощь ИТ-специалистов. PowerDesigner - УНИКАЛЬНОЕ ПРОМЫШЛЕННОЕ СРЕДСТВО МОДЕЛИРОВАНИЯ, объединяющее в единую интегрированную среду разработки все существующие уровни моделирования информационных систем.
2)На этапе предварительного обследования деятельности предприятия (той деятельности, которую необходимо автоматизировать) используется компонентаDesigner/2000 - средство построениядиаграмм деловых процессов BPR(Business Process Modeler). С его помощь возможно не только построить модель всех процессов, протекающих в ходе повседневной деятельности организации (предприятия), но и произвести ряд анализов, способных выявить узкие места. Даже без последующего создания приложения, такая модель позволяет лучше понять как протекает деятельность организации и найти пути по ее улучшению.
Построение ДПД:
В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Построение иерархии диаграмм потоков данных Первым шагом при построении иерархии ДПД является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Прокат автомобилей [1] Сбор заявок [1.1] Прием заявок [1.1.1] Анализ заявок [1.1.2] Сохранение заявок [1.1.3] Сбор сведений о клиенте [1.2] Прием информации о клиенте [1.2.1] Анализ информации о клиенте [1.2.2] Сохранение информации о клиенте [1.2.3] Сбор сведений о наличии авто [1.3] Запись сведений о наличии ВС [1.3.3] Анализ сведений о наличии авто [1.3.2] Прием сведений о наличии авто [1.3.1] Запрос инфо [1.4] проверка информации о клиенте [1.5] подготовка сведений о клиенте [1.5.1] проверка сведений о клиенте [1.5.2] сохранение данных [1.5.3] Передача машины клиенту [1.7] приём машины [1.7.1] Прием сведений [1.7.2] Подготовка данных для передачи и передача [1.7.3] регистрация машины на данного клиента [1.6] Оформление заказа [1.6.3] Подбор авто [1.6.1] регистрация машины на клиента [1.6.2]
А) 1 уровень
В) 2 уровень
С) 3 уровень
1) Сбор заявок
2) Сбор сведений о клиенте
3) Сбор сведений о наличии авто
4) Проверка информации о клиенте
5) Регистрация автомобиля на данного клиента
6) Передача автомобиля клиенту
3)Следующий этап – инфологическое моделирование.
Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по БД. И это описание должно быть настолько ёмким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно оно не должно быть привязано к конкретной СУБД.
Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД.
Модель «сущность-связь» (ER-модель).
Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определённым правилам.
Это модель в большей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент несомненно является базовой для разработки сложных программных систем.
В основе ER-модели лежат следующие базовые понятия:
атрибут - логически неделимый элемент информации, отображающий некоторую качественную или количественную характеристику сущности;
сущность – агрегация атрибутов, характеризующих соответственно ей объект или событие;
связь указывает на наличие отношений между информационными объектами.
Для сущности задаётся имя, которое должно быть уникальным в рамках модели. Имя должно быть краткое, но в то же время давать исчерпывающие сведенья об информационном объекте, представляемым данной сущности.
Для атрибута указывается имя, ключевой или неключевой атрибут, обязательный или необязательный.
Связи в ER-модели являются бинарными ( задаются между двумя сущностями) или рекурсивными( сущность связана сама с собой).
Для каждого конца связи задаётся:
имя;
степень множественности( 1:1; 1:М; М:М);
степень обязательности;
ключевая или неключевая связь.
1) Определение сущностей. Исходя из задачи выделим следующие сущности: 1) Кредитная карта; 2) Клиент; 3) Заявка; 4) Паспорт; 5) База данных МВД; 6) База данных автомобилей.