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

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

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

При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки ИС модели, как правило, претерпевают существенные изменения (переход or «As Is» к «То Be») и в окончательном виде модель «То Ве» рассматривают в качестве модели проектируемой ИС.

Различают функциональные, информационные, поведенческие и структурные модели.

• Функциональная модель системы описывает совокупность выполняемых

системой функций.

• Информационная модель отражает структуры данных – их состав и

взаимосвязи.

• Поведенческая модель описывает информационные процессы (динамику

функционирования), в ней фигурируют такие категории, как состояние

системы, событие, переход из одного состояния в другое, условия перехода,

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

• Структурная модель характеризует построение системы – состав подсистем, их взаимосвязи.

Содержанием последующих этапов нисходящего проектирования (согласно ГОСТ 34.601-90, это стадия разработки технического проекта, рабочей документации, ввода в действие) являются уточнение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначальное наполнение, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования. Эти работы составляют содержание рабочего проектирования. После этого следуют закупка и инсталляция программно-аппаратных средств, внедрение и опытная эксплуатация системы.

---

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

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

3. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

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

Инструментальные средства обычно объединяются через общий репозиторий, структура которого является собственностью разработчика пакета инструментальных средств. Центральный репозиторий позволяет проектировщику найти нужный проект, компонент и соответствующую проектную информацию. Обычно для создания общего репозитория инструментов используются системы баз данных типа Sybase или Oracle. Эти пакеты инструментальных средств содержат большое количество средств языков программирования четвертого поколения, предназначенных для генерирования программного кода на основе системной архитектуры, они также могут генерировать базы данных. Пакеты инструментальных средств обычно закрыты, т.е. не рассчитаны на добавление пользователями собственных инструментов или на изменение средств пакета, в который входят:

---

— редакторы диаграмм, предназначенные для создания диаграмм потоков данных, иерархий объектов, диаграмм «сущность-связь», эти редакторы не только имеют средства рисования, но и поддерживают различные типы объектов, используемых в диаграммах;

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

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

— средства генерирования отчетов на основе информации из центрального репозитория автоматически генерируют системную документацию;

— средства создания форм определяют форматы документов и экранных форм;

— средства импортирования и экспортирования позволяют обмениваться информацией из центрального репозитория различным инструментальным средствам;

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

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

4. ПРЕИМУЩЕСТВА И НЕДОСТАТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

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

4.1 Преимущества объектно-ориентированного проектирования

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

---

Как указывалось в главе 2, использование объектной модели приводит к созданию систем, обладающих пятью свойствами хорошо структурированных сложных систем: иерархическая структура, относительность выбора элементарных компонентов (например, несколько уровней абстракций), разделение функций, общая структура и устойчивые промежуточные формы. Объектная модель образует концептуальную основу для системы обозначений и процесса объектно-ориентированной разработки. Таким образом, эти выгоды присущи самому методу. Кроме того, в главе 2 отмечались и преимущества, вытекающие из следующих свойств объектной модели (а значит и процесс объектно-ориентированной разработки).

• Апелляция к когнитивным способностям человека.

• Создание гибких систем, допускающих модификацию.

• Стимулирование повторного использования программных компонент.

• Уменьшение риска, связанного с разработкой.

• Использование выразительной мощи объектно-ориентированных языков программирования.

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

4.2 Недостатки объектно-ориентированного проектирования

Теневой стороной объектно-ориентированной технологии являются связанные с ней риски. Новаторское исследование этих рисков было проведено в статье Хантоса (Hantos), который указал, что "классические объектно-ориентированные концепции Бертрана Мейера (Bertrand Meyer) превратились в список десяти основных не зависящих от методологии программирования рисков, предложенный Барри Боемом (Barry Boehm)". Анализируя работу Мейера, Хантос сформулировал следующий список объектно-ориентированных концепций, которые были преобразованы в список рисков Боема.

• Уникальный способ определения архитектуры и экземпляров структур

данных.

• Сокрытие информации с помощью абстракции и инкапсуляции.

• Наследование, позволяющее организовывать родственные элементы.

• Полиморфизм, позволяющий выполнять операции, которые можно

автоматически адаптировать к типу структуры.

• Специальные методы анализа и проектирования.

• Объектно-ориентированные языки.

• Среды разработки, облегчающие создание объектно-ориентированных

---

систем.

• Разработка по контракту — мощный метод для решения проблем,

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

• Управление памятью, автоматически освобождающее неиспользуемые

участки.

• Распределение объектов, облегчающее создание мощных распределенных

систем.

• Объектные базы данных, позволяющие преодолеть границы типов данных

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

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

1. Дефицит кадров.

2. Нереалистичные графики работ, сметы и процессы.

3. Дефицит готовых коммерческих продуктов, внешних компонентов и

наследуемого программного обеспечения.

4. Недостатки архитектуры, эффективности или пользовательского

интерфейса.

5. Несогласованность между требованиями к пользовательскому интерфейсу.

6. Непрерывный поток изменяющихся требований.

7. Недостатки сторонних субподрядчиков.

8. Развитие компьютерных наук.

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

Хантос изобразил полученные результаты в виде диаграммы отображения, из которой следует, что риски традиционной разработки программного обеспечения, указанные Боемом, характерны и для объектно-ориентированного анализа и проектирования. В качестве положительного свойства Хантос показал, что некоторые понятия объектно-ориентированного анализа и проектирования позволяют уменьшить риски, описанные Мейером. В частности, концепция "архитектуры и экземпляров" позволяет уменьшить риск, связанный с "непрерывным потоком изменяющихся требований" и "недостатками сторонних субподрядчиков". Концепция "абстракции и инкапсуляции" также позволяет уменьшить риск, связанный с "непрерывным потоком изменяющихся требований".

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

---