Файл: "Разработка информационной системы менеджера по продажам салона сотовой связи".docx
Добавлен: 25.10.2023
Просмотров: 272
Скачиваний: 9
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
-
Реализацию проектов по созданию ИС принято разбивать на стадии анализа (прежде чем создавать ИС, необходимо понять и описать бизнес-логику предметной области), проектирования (необходимо определить модули и архитектуру будущей системы), непосредственного кодирования, тестирования и сопровождения. Известно, что исправление ошибок, допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем на текущей, откуда следует, что наиболее критическими являются первые стадии проекта. Поэтому крайне важно иметь эффективные средства автоматизации ранних этапов реализации проекта. -
Проект по созданию сложной ИС невозможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков. -
Жизненный цикл создания сложной ИС сопоставим с ожидаемым временем ее эксплуатации. Другими слонами, в современных условиях компании перестраивают свои бизнес-процессы примерно раз в два года, столько же требуется (если работать в традиционной технологии) для создания ИС. Может оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания ИС жизненно необходим инструмент, значительно (в несколько раз) уменьшающий время разработки ИС. -
Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно внесение изменений в проект на поздних этапах создания ИС – весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям.
На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям.
Для проведения анализа и реорганизации бизнес-процессов предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему нужно стремиться (модель ТО-ВЕ). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как “внешняя ссылка” и “хранилище данных”, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент “перекресток”, что позволяет описать логику взаимодействия компонентов системы.
На основе модели BPwin можно построить модель данных. Для построения модели данных Computer Associates предлагает мощный и удобный инструмент – AHFusion ERwin Data Modeler (ERwin). Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Computer Associates предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели – механизм двунаправленной связи BPwin – ERwin [10].
ERwin имеет два уровня представления модели – логический и физический, причем модель данных может содержать как оба этих уровня, так и только один из них. Модели, содержащие только один уровень, могут быть синхронизированы, что особенно удобно при создании гетерогенных информационных систем. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных – это, по существу, отображение системного каталога, который зависит от конкретной реализации СУБД. Создание одного логического уровня и нескольких соответствующих ему физических позволяет вести одновременную разработку баз данных для нескольких СУБД. ER-win позволяет проводить процессы прямого и обратного проектирования баз данных. Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования.
Для больших, содержащих сотни таблиц моделей данных существенной проблемой становится поиск и исправление ошибок. Решение этой проблемы вручную – слишком трудоемкая задача, которая может недопустимо затянуть выполнение проекта. ALLFusion Data Model Validator (ERwin Examiner) – основанный на базе знаний инструмент, который позволяет анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу поиска и исправления ошибок. ERwin Examiner может использовать в качестве источника метаданных готовую модель ERwin, DDL-скрипт или провести обратное проектирование базы данных (стрелки 3 и 4).
При проектировании больших ИС ключевой проблемой является создание качественной документации по моделям. BPwin и ERwin позволяют генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования моделей. Отчеты могут быть экспортированы в распространенные форматы – текстовый, MS Office, HTML и др. Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin поддерживает также экспорт и импорт модели в текстовый файл формата IDL, который является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.
Создание современных ИС, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Computer Associates предлагает систему ModelMart – хранилище моделей, к которому открыт доступ для участников проекта создания ИС. ModelMart удовлетворяет всем требованиям, предъявляемым к средстнам разработки крупных ИС, а именно:
-
Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются 3 режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются при помощи специального модуля. В дополнение к стандартным средстнам организации совместной работы ModelMart позволяет сохранять множество версий, снабженных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям. -
Создание библиотек решений. ModelMart позволяет формировать библиотеки стандартных решений, содержащие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости “сборки” больших систем. На основе существующих баз данных с помощью ERwin возможно восстановление моделей (обратное проектирование), которые в процессе анализа пригодности их для новой системы могут объединяться с типовыми моделями из библиотек моделей. -
Управление доступом. Для каждого участника проекта определяются права доступа, в соответствии с которыми они получают возможность работать только с определенными моделями. Права доступа могут быть определены как для групп, так и для отдельных участников проекта. Роль специалистов, участвующих в различных проектах, может меняться, поэтому в ModelMart можно определять права доступа и управлять правами доступа участников проекта к библиотекам, моделям и даже к специфическим областям модели.
Архитектура ModelMart. ModelMart реализована на архитектуре клиент-сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются ERwin и BPwin. В ModelMart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа.
При разработке крупных проектов критическим становится время реализации проекта. Одним из решений проблемы может стать автоматическая генерация кода приложения CASE-средствами на основе модели предметной области. Эту задачу решает технология кодогенерации, основанная на объектно-ориентированном проектировании. Существует несколько CASE-средств, поддерживающих языки объектно-ориентированного проектирования, в том числе ставший в последнее время стандартом UML. Одним из них является AHFusion Component Modeler (Paradigm Plus). Этот инструмент позволяет строить объектные модели и генерировать на основе полученной модели приложения на языках программирования C++, Visual Basic, Java и др. Поскольку генерация кода реализована на основе знаний предметной области, полученный код адекватно отражает бизнес-логику. Paradigm Plus поддерживают не только прямую генерацию кода, но и обратное проектирование, т. е. создание объектной модели по исходному коду приложения.
На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
-
схема базы данных (на основании ER-модели, разработанной на этапе анализа); -
набор спецификаций модулей системы (они строятся на базе моделей функций).
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
-
будет ли это архитектура “файл-сервер” или “клиент-сервер”; -
будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО; -
будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться; -
будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя. Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта); -
будут ли для достижения должной производительности использоваться параллельные серверы баз данных.
Этап проектирования завершается разработкой технического проекта ИС.
На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:
-
обнаружение отказов модуля (жестких сбоев); -
соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы, и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.