Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf

В результате осуществления стадии структурирования системы получаются следующие виды моделей:

• модель хранилища данных;
• модель клиент-сервер;
• трехуровневая модель;
• модель абстрактной машины.

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

Рисунок 5. Модель хранилища данных.

Клиент-серверная модель используется для проектирования распределенных систем, в которых компоненты системы распределены по серверам. Для передачи данных в клиент-серверных системах применяются сетевые протоколы, например, протокол TCP/IP. Структура клиент-серверной модели представлена на рисунке 6.

Рисунок 6. Клиент-серверная модель.

Развитием клиент-серверной модели является трехуровневая модель. Структура трехуровневой модели представлена на рисунке 7.

Рисунок 7. Трехуровневая модель.

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

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

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

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

Рисунок 8. Модель абстрактной машины.

---

Модель является совокупностью следующих слоев:

• Операционная система;
• СУБД;
• Управление объектом;
• Управление версиями.

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

Рассмотрим модели управления. Выделяют следующие виды моделей управления:

• модель централизованного управления;
• модель событийного управления.

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

1. Модель вызов-возврат.
2. Модель менеджера, используемая в системах параллельной обработки.

Структура модели «Вызов-возврат» представлена на рисунке 9.

Рисунок 9. Структура модели «Вызов-возврат».

На рисунке 10 представлена структура модели менеджера.

Рисунок 10. Структура модели менеджера.

В модели событийного управления системой управление осуществляется внешними событиями. Существуют следующие виды моделей событийного управления:

• широковещательная модель;
• модель, управляемая прерываниями.

В широковещательной модели, представленной на рисунке 11, каждая подсистема уведомляет обработчика о своем интересе к конкретным событиям. Во момент, когда такое событие происходит, обработчик пересылает его подсистеме, которая может обработать это событие. Функции управления в обработчик не встраиваются.

Рисунок 11. Структура широковещательной модели.

На рисунке 12 представлена структура модели, управляемой прерываниями. В этой модели все прерывания разбиваются на группы, которые в совокупности образуют вектор прерываний. Каждому типу прерывания соответствует конкретный обработчик. Каждый обработчик запускает конкретный процесс.

Рисунок 12. Структура модели, управляемой прерываниями.

Рассмотрим процесс декомпозиции подсистем на модули. Различают следующие модели модульной декомпозиции:

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

---

Выбор способа декомпозиции подсистемы на модули зависит от сложности разбиваемой подсистемы.

2. Этапы проектирования программного продукта

Процесс проектирования программных продуктов включает следующие этапы:

1. Эскизный проект системы.
2. Техническое проектирование.
3. Рабочий проект системы.

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

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

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

Основу эскизного проекта составляют документы, которые были разработаны на стадии предпроектного обследования предметной области. К этим документам относятся: отчет о предпроектном обследовании, аван-проект, техническое задание на создание программного продукта и технико-экономическое обоснование проекта.

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

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

---

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

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

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

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

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

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

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

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

---

Этап технического проектирования включает в себя следующие стадии:

1. Разработку проектных решений по системе и ее частям.
2. Разработку документации на систему и ее части
3. Разработку и оформление документации на поставку изделий для комплектования системы или технических требований на их разработку.
4. Разработку заданий на проектирование в смежных частях проекта объекта автоматизации.

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

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

В состав комплекта документ, содержащих общесистемные проектные решения входят следующие документы:

• ведомость технического проекта;
• пояснительная записка к техническому проекту;
• описание автоматизируемых функций;
• ведомость покупных изделий;
• описание постановки задач (комплекса задач);
• локальный сметный расчет;
• проектная оценка надежности системы.

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

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

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

---