1.5. Методология разработки программного обеспечения.
Возрастающая сложность современного программного обеспечения привела к созданию специальной научной дисциплины — компьютерной инженерии (Software Engineering), основной задачей которой является создание эффективных методов разработки сложных программных систем.
1.5.1. История развития.
Объектно-ориентированные методологии разработки программного обеспечения (первое направление) стали интенсивно развиваться с конца 80-х годов. В 1997 г. OMG (Object Management Group) приняла UML, появившийся в результате слияния ряда известных методологий, в качестве стандарта языка объектно-ориентированного моделирования. Еще одним объектно-ориентированным подходом является методология ROOM, созданная для разработки систем реального времени. Одновременно в течение последних 20 лет международным комитетом ITU развиваются стандарты для разработки телекоммуникационных систем (второе направление): SDL, MSC и т.д. Кроме того, с 70-х годов развиваются структурные методологии разработки программного обеспечения (третье направление): SADT, IDEF-стандарты, метод Йордана и т.д. В настоящее время эти методологии прочно закрепились в области разработки информационных систем. Они являются эффективным средством анализа систем в целом и успешно применяются.
В данной работе описывается объектно-ориентированная методология Real. Методология Real основывается, главным образом, на UML, SDL, ROOM и отражает перечисленные интеграционные тенденции. Помимо стандартных для объектно-ориентированного подхода черт в Real добавлены дополнительные возможности, направленные на две специальные области программного обеспечения: для информационных систем и для систем реального времени.
Естественно, что Real не претендует на то, чтобы покрыть все возможности программных продуктов соответствующих областей. В то же время, учитывая современный уровень развития локальных и глобальных информационных сетей и возрастающую сложность программного обеспечения, в информационных системах все большую популярность приобретает технология клиент-сервер, т.е. многие информационные системы приобретают ярко выраженный событийно-ориентированный аспект, который глубоко проработан в методологиях разработки программного обеспечения систем реального времени. С другой стороны, большие распределенные системы реального времени нуждаются, как правило, в хранении, доступе и передаче огромного количества информации (например, тарификационной и аутентификационной), а не только управляющих сигналов и данных трафика. Таким образом, методология Real подходит для разработки программного обеспечения обеих областей, но наиболее эффективна для их пересечения.
1.5.2. Разработка программного обеспечения систем реального времени
Основное назначение Real применительно к системам реального времени — проектирование сложной управляющей логики с последующей возможностью автоматической генерации кода. Отметим, что методология Real не ориентирована специальным образом на разработку оборудования и программного обеспечения, непосредственно с ним контактирующего (драйверов устройств и т.п.), а также сетевых протоколов нижнего уровня. Однако мы считаем, что для этих задач она подходит примерно в той же степени, как и UML.
Как показывает практика, прямые ветки сложных алгоритмов достаточно удобно и наглядно определять с помощью сценариев. На начальных этапах разработки системы нужно четко определить логику всех взаимодействий. При этом правила поведения системы в ошибочных ситуациях в большинстве случаев можно доработать позднее. По сценариям можно сгенерировать STD- или SDL-диаграммы и продолжить создание спецификаций уже в этом стиле, учитывая все допустимые варианты поведения системы.
В терминах Real основной структурной единицей системы реального времени является объект. Объекты взаимодействуют друг с другом через интерфейсы. Под взаимодействием понимается посылка сообщений, вызов методов и обращение к атрибутам интерфейса. Поскольку в последнее время все большее число систем реального времени становятся распределенными и сетевыми, понятие интерфейса приобретает особую важность. Раньше ситуация была иной, примером чего служат ранние версии языка SDL, в которых интерфейсы отсутствовали. Интерфейсы Real сильно отличаются от портов (gate) SDL (составом, способом связи с классами) и интерфейсов UML (составом, способом связи с классами, способом изображения), а также интерфейсов в ROOM (составом и способом изображения).
В системах реального времени важную роль играют абстракции точек входа и выхода у различных компонент программного обеспечения. Поэтому в модель классов Real был добавлен из ROOM специальный элемент — порт.
Компонента программного обеспечения, определенная в виде класса с портами и интерфейсами, может иметь конечно-автоматное поведение, описываемое в терминах поведенческой модели Real. Поведенческая модель, в свою очередь, представляется двумя альтернативными нотациями: первая основана на варианте STD, представленном в ROOM, вторая — на расширенном конечном автомате SDL. С помощью STD-нотации удобно определять поведение компонент системы на ранних этапах разработки: множество мелких деталей можно временно убрать из поля зрения. В то же время на SDL-диаграммах можно наглядно изобразить мельчайшие подробности алгоритмов.
Эта возможность становится полезной на поздних этапах проектирования. При этом информацию, изображенную на STD-диаграммах, можно ”загрузить” на SDL-диаграммы, таким образом, результаты ранних этапов при переходе к более формальной спецификации не будут потеряны. В рамках Real, STD и SDL нотации предназначены для описания единой поведенческой модели, так что всегда возможно и обратное — загрузка на STD-диаграмму результатов работы с SDL-редактором. На поведенческую модель Real сильно повлияла технология SDL/PLUS 20: так же не используются типы данных и выражения SDL, но применяется более гибкая стратегия связи с языками реализации [7] вместо заранее фиксированного языка [11].
... элементов, глобальное пространство имен, а также лавинообразную первоначальную загрузку сети. Таким образом ОСРВ SPOX имеет необходимые механизмы для создания отказоустойчивой распределенной операционной системы реального времени, концепция построения которой описана в главе 2. 4.3 Аппаратно-зависимые компоненты ОСРВ Модули маршрутизации, реконфигурации, голосования реализованы как аппаратно- ...
... запрошенный ею ресурс, произошло связанное с ней внешнее событие, исчерпался заданный интервал времени и т. п. Заканчивая рассмотрение основных принципов планирования задач, необходимо отметить, что тема эта далеко не исчерпана. Диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где ...
... же порты ввода-вывода или линии запроса прерывания. С такими проблемами, как конфликты различных частей аппаратуры, приходится иметь дело в основном именно операционным системам. Наконец, в-восьмых, при разработке операционных систем часто учитывается необходимость совместимости с предыдущей версией операционной системы. Система может иметь множество ограничений на длину слов, имена файлов и т. ...
... заявить, что все его ресурсы доступны для всех пользователей группы. Такая схема может быть многоуровневой (группы делятся на подгруппы и т.д.) с соответственным распределением прав и возможностей. Сейчас появляются операционные системы, в которых права доступа могут определяться не только такой иерархической структурой, но и могут быть более сложными, т. е. права доступа можно добавлять, нарушая ...
0 комментариев