14. Понятие шаблона проектирования.

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

Автоматное программирование — весьма удобный и гибкий инструмент, который позволяет решать поставленную задачу в терминах, близких понятиям предметной области. Например, задача о программировании поведения лифта в многоэтажном доме превращается в весьма формализованную модель автомата со следующим состояниями: “Лифт едет вверх”, “Лифт едет вниз”, “Лифт стоит на этаже N” и приходящими от жильцов дома событиями: “Нажата кнопка Вниз на N-ом этаже” и “Нажата кнопка Вверх на N-ом этаже”.

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

Для решения этой проблемы существует ООП и шаблоны Visitor и State.

15. Онтологический подход к проектированию ис.

16. Объектно-структурное моделирование ис.

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

Суть функционального разбиения хорошо отражена в известной формуле:

“Программа=Данные + Алгоритмы”.

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

Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: "разработка, основанная на компонентах" (Component Based Development - CBD). При этом используется иной принцип декомпозиции - система разбивается на “активные сущности” – объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении “клиент/сервер”. Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения "объекту-серверу" эквивалентна вызову соответствующего метода объекта.

Так вот, если при проектировании информационная система разбивается на объекты (компоненты), то UML может быть использован для ее визуального моделирования. Если используется функциональная декомпозиция ИС, то UML не нужен, и следует использовать другие (структурные) нотации.

Отдельная тема для обсуждения – нужно ли программировать в объектах (компонентах)? Споры на эту тему относятся к разряду “религиозных войн”. Есть убежденные сторонники в обоих лагерях. Уместно заметить, что все современные RAD-средства программирования используют библиотеки компонент, позволяющие повторно использовать отлаженный программный код, что значительно облегчает сборку программных приложений. Такое "сборочное программирование" стало возможным за счет использования объектов и привело к изменению квалификационной оценки программистов за рубежом - "программист - это тот, кто умеет программировать в компонентах", т.е. это не "писатель программного кода", как принято считать у нас.

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

единообразно понимаются всеми разработчиками, вовлеченными в проект и

являются средством коммуникации в рамках проекта.

Унифицированный Язык Моделирования (UML):

не зависит от объектно-ориентированных (ОО) языков программирования,

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

может поддерживать любой ОО язык программирования.

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