Файл: Основы проектирования программ. Этапы создания программ (Общие положения теории проектирования)ного обеспечения.pdf

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

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

Независимо от формулировки цель как результат деятельности может быть задана формально характеризующие степень ее достижения через показатели качества.

Требования^[57] к показателям качества могут быть заданы в трех видах^[58]:

1. приравнять;

1. ограничить;
2. добиться экстремума.

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

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

Учитывая вышесказанное, методика проектирования целей выглядит таким образом. Строится описание надсистемы и определяются показатели, характеризующие эффективность ее функционирования. Затем определяются функции, которые должны выполняться проектируемым объектом, и конкретные требования к ним через показатели качества надсистемы — этим определяются цели в пространстве потребностей. При дальнейшей конкретизации объекта до уровня его показателей качества исследуется влияние последних на показатели надсистемы. Это позволяет выразить цели через показатели качества^[59] объекта — задать их в пространстве показателей качества. Дальнейшая конкретизация объекта позволяет определить связи между показателями качества и значениями параметров и переменных состояния, также выразить цели через требования к ним — описать их в пространстве состояний.

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

2.3. Проектная процедура постановки задачи разработки программы

Проектная процедура основывается на владении системным подходом применительно к анализу программных систем^[60]. Изначально рассматривается система - человек, программа, ЭВМ, другие объекты, пример: технические, выполняющее весь комплекс обработки информации. Дальше элементы рассматриваются по отдельности для уточнения требований. Программа имеет только информационный вход и выход. Облегчить генерацию целей на первичных этапах позволяет модель "черного ящика^[61]", рис. 2.

Суть проектной процедуры:

Шаг 1. Проанализируйте выход системы, определите состав и форму выходных данных.

Шаг 2. Проанализируйте вход системы, определите форму и состав входных данных.

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

Шаг 4. Определите ограничения.

Рис. 2. Модель "черного ящика" проектируемого объекта

Шаг 5. Определите основные алгоритмы обработки информации и рассчитайте время их выполнения.

Шаг 6. Доопределите ограничения.

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

При выполнении данной проектной процедуры нужно расширить ряд исследуемых вариантов с использованием "метода проб и ошибок", "метода аналогий", "метода морфологического синтеза решений". Совокупность функций системы, ограничений и условий их существования называется множеством потребительских свойств системы^[62].

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

3. ТЕХНОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

3.1. Этапы и модели объектно-ориентированной технологии

Объектно-ориентированная технология создания программ^[63] основывается на так называемом объектном подходе. Одним из проявлений этого подхода является: сначала довольно долго создаются и оптимизируются объектная модель и иные модели и лишь затем осуществляется кодирование.

Обычно проектируемая программная система первоначально представляется в виде трех моделей которые взаимосвязаны^[64]:

1) Объектная модель (представляет структурные и статические аспекты системы);

2) Динамическая модель (описывает работу отдельных частей системы);

3) Функциональная модель (рассматривается взаимодействие частей системы в процессе ее работы).

Данные виды моделей позволяют рассмотреть три взаимно-ортогональных представления системы в одной системе обозначений.

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

Так как при разработке объектно-ориентированного проекта используется много моделей, которые необходимо увязать в единое целое.

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

1. Определение объектов
2. Подготовку словаря объектов для того, чтобы исключить возможность синонимичных понятий и уточнения имен, выделения классов, классификацию объектов
3. Определение взаимосвязи между объектами
4. Определение методов и атрибутов объектов (проектирование интерфейсов и определение уровней доступа)
5. Исследование качества модели

Используя функциональную модель^[65], можно начинать работу с динамической моделью, наделяя объекты необходимыми данными и методами.

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

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

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

Объектную модель можно описать следующим образом:

1) Основные элементы модели – сообщения и объекты;

2) Объекты создаются, используются и уничтожаются аналогично динамическим переменным в обычных языках программирования;

3) Выполнение программы заключается в создании объектов и передаче им последовательности сообщений.

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

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

Абстрагирование концентрирует внимание на внешних особенностях объекта, позволяет отделить самые существенные особенности поведения от несущественных. Выбрать правильный набор абстракций для заданной предметной области главная задача объектно-ориентированного проектирования^[67].

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

Инкапсуляция и абстракция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, инкапсуляция занимается внутренним устройством^[68]. Часто инкапсуляция дополняется сокрытием информации, маскировкой внутренних деталей, не влияющих на внешнее поведение. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы объекта, скрыты от внешних компонентов.

При объектно-ориентированном проектировании необходимо физически разделить объекты и классы^[69] (логическую структуру проекта). Такое разделение делает возможным повторно использовать в новых проектах код модулей, ранее написанных. Модулю соответствует отдельный файл исходного текста. На выбор разбиения на модули могут влиять некоторые внешние обстоятельства. При групповой разработке программ распределение работы осуществляется, по принципу модулей, правильное разделение проекта минимизирует связи между участниками.

Принципы абстрагирования, модульности и инкапсуляции являются взаимодополняющими. Логически объект определяет границы определенной абстракции, а модульность и инкапсуляция делают их физически незыблемыми^[70].

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

3.2. Стадии и этапы разработки программ по ГОСТ 19.102-77

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

Таблица 1. Стадии разработки, этапы и содержание работ^[71]