И. Соммервилл - Инженерия программного обеспечения (1133538), страница 75
Текст из файла (страница 75)
Системная архитектура стронтсл иа основе уже имеющихся (готовых) компонентов (рис. )4.5). Риг. 14.5. 11]кгцегс ирввктирввпиил г лвввгвриым игиввлзвввниглг кютвнвгпввв В данном случае трсбоваиип к системс изменяются с учетом имеющихся компонентов, выбранных лдя повторного использования. Системная архитектура также базируется па имеющихся компонентах.
Конечно, такой подход предполагает определенные компромиссы в реализации требований. Хотя такал система может оказаться менее эффекгиггпай, чем система, разработанная без повторного ишюльтования компонентов, этот недостаток комисгюирустся более низкой стоимостью разработки, более высокими тсмпамп создания системы и ее паэьппепиой надежностью. Обычно покамионеитиыгг процесс реализации системы пэляется либо процессом лта. кетированип (прототипирования), либо п(зоцессом пошаговой разработки. Вместе с библиотеками колщопеитов можно использовать стапдартныс языки программирования, паприлгер ]ага.
Лльтернатиггай ему (и более распространенным пзыком) лплястся язык сце. париса, который спепнально разработан для интегрирования повторно используемых компонентов и обеспечивает бгвструю разработку програлгм. Первым языком сценариев, разработанным для иитсграцгии иоптарио используемых компонентов, был Сп!х кйсй (58].
После него разработано множество других языков сце. париса, например лг(ктга! Вал(с и ТС(./ТК. В работе (268] обсуждаются преимущества языков сценариев, в том числе отсутствие определения типов данных, и тот факт, что они не компилируются, а интерпретируются. 14. Проектирование с повторным использованием компонентов 291 Пожалуй, главной проблемой, связанной с покочпонентной разработкой систем, является их сопровождение и модернизация.
При изменении требований к системс часто в компоненты необходимо внести изменения, соответствующие новым требованиям, однако в большинстве случаев это невозможно, поскольку исходный код компонентов недоступен. Также, как правило. не подходит альтернативный вариант: замена одного компонента другим. Таким образом, необходима дополнительная работа по адаптации повторно используемых компонентов, что приводит к повышению стоимости обслуживания системы.
Однако, поскольку разработка с повторным использованием компонентов позволяет быстрее создавать ПО, орщнизации согласны оплачивать дополнительные расходы па сопровождение и модернизацию систем. 14.1.1. Объектные структуры приложений Первые сторонники объектно.ориентированной разработки ПО иолагалн, что ианбо. лес подходящими абстракциями для повторного использования явллютсл объекты. Однако, как следует из предыдущего раздела объелты обычно слишком мелкие струзпурные единицы.
чересчур "привязанные" в конкретному приложению. Очевидно, что в процессе объектно-ориентпрожцпюго проектирования вместо повторного использования оГ>ъектов намного эффективнее повторно использовать круппомодульиые абстракции, так называемые объектные структурь> приложения. Объекгныс структуры приложения представллют собой структтры подсистем, состоя. щих нз множества абстрактных и конкретных классов объектов н интерфейсов между ними [343].
Отдельные летали подсистем рсалнз> ются с помощью компонентов и обеспечивают конкретные реализации абстрактных классов. Объектные структуры, как правило. пе являются сами >ю себе приложениями. Обычно приложения строятся посредством интегрирования нескольких объектных структур. Существует трн ос>ювных класса объелтных структур [ 113 [.
1. уйму>расэ>[>ухе>у[>м сигме>. Обеспечивают разработлу инфраструктур для сцггсм связи [коммуникационных систем], пользовательских интерфейсов и компиляторов [306]. 2. Иявмг(>л>знэвямг ел[>укэ>1У>ь>. Как правило, состолт из набора станлартов и связанных с ними классов объектов, обеспечивающих взаимодействие и обмен ланпыми между компонентами. К этому типу структур отпосятсл СОКВЛ. СОМ и ПСОМ от М]сгозоуц а также ]а>а Веапх [264 [.
Данный тип объектных структур рассматривалсл в главе 11 при обсуждении архитектур распределенных объслтов. 3. Сэрукглурм яясту>умеяякмьяь>х с[яд [>па[>лбээжи п[>илозкеяий, Связаны с отдельными прикладными областями, такими как телекоммуникации цли финансы [30]. Опи встраиваются в систему знаний области прпложснил н щ>ллсржпвают разработку приложений конечного пользователя. Да>н>ыс структуры свлзаиы с семействами приложений, которые рассматрпваютсл в разделе 14.2. Объектная структура — это обобщенная структура, которую можно детализировать и расширить при создании конкретной подсистемы или приложения. Детализация объектной структуры обычно предполагает добавление конкретных классов.
наследующих методы от абстрактных классов объектной стрултуры. Крол>с того, определяются методы, ко. торые вызыва>отел в ответ на события, опрсдслсщ>ые объектной структурой. На момент пащюапия книги были достаточно хорошо разраГютаны гмн]>раструкгуры систем, особенно те из нпх, которые свлзаны с графическими интерфейсами пользователя. Их постепенно вь>теснлют структуры инструментальных сред разработки приложений 292 Часть Ш. Проектирование (77). Попытаемся разобрать наиболее эффективные представления и организацию данныхх объектных структур. Одной из самых известных и распространенных объектных структур для графических интерфейсов пользователя (СШ) является объектная структура "модель-представление- контроллер" (рис.
14.б). Эта модель появилась в 1980-х годах как метод проектиронапия графических интерфейсов пользователя, который поддерживает различные представления объекта и различает взаимодействия с каждым из этих представлений. Ввод данных нальзонатолвм Зш и обнова моде Рис. 14.6. Обхгнни~пл ст~уктурп "модель — пумдсншвление-ион п~оллор" Объектные структуры часто реализуются в виде паттернов (см. раздел 14.2). Например. объектная структура "модель-представление-контроллер" включена в паттерн Обозреватель. описанный во врезке 14.1, а также в ряд других паттернов, подробно рассмотренных в работе [124).
Основные недостатки объектных структур — их сложность и время, необходимое для того, чтобы научиться работать с ними. Для полного изучения объектных структур может пояадобитьсн несколько месяцев. Именно поэтому в больших организациях пекоторыс разработчики ПО специализируютсл по объектным структурам.
Нет никаких сомнений в эффективности данного подхода к повторному использованию, однако высокие затраты на изучение объектных структур ограничивают его повсеместное распространение. 14.1.2. Повторное использование коммерческих программных продуктов Термин "коммерческие программныс продукты" можно применить к любому компоненту, созданному псзавпспыыл~ производителем. Вместе с тем пол этим термином часто подразумевается программное обеспечение системного уровня.
Л также предпочитаю говорить о коммерческих системах. функциональность, предлагаемая зтил1и системал1и, намного шире функциональности более специализированных компонентов, и поэтолгу увс" личивается потенциальный выигрыш, полученный от повторного использования. Некоторыс типы коммерческих систем используются повторно па протяжении многих лет. Лучшим примером тому, по.видимому, сл)окат базы данных. Очень немногис разработчики создают собственные системы управления базами данных. Но до недавнего времени существовало лишь несколько больших коммерческих систем, таких как системы управления базами данных и мониторы телеобработки, используемые повторно.
Новыс подходы к проектированию систем, предоставляющие программам доступ к системным функциям, показывают, что созлание больших систем (например, систем алек. 14. Проектирование с повторным использованием компонентов 29$ тронной коммерции) посредством интегрирования ряда коммерческих систем сегодня рассматривается как один из приемлемых вариантов проектирования. Благодаря функциональности, предлагаемой этими системами, сокращение финансовых и временных затрат может достичь величины, сравнимой с разработкой нового ПО "с нуля".
Более того, уменьшаются риски, так как коммерческие системы уже существуют и разработчики моьут увидеть, удовлетворяют ли они предъявляемым к ним требованиям. В принципе использование крупномодульных коммерческих систем не отличаетсл от использования любого другого более специализированного компонента. Для этого необходимо изучить интерфейсы системы н использовать их для организации взаимодействия с друтими системными компонентами, также необходимо разработать системную архитектуру, которая поддерживала бы коммерческие системы при совместной работе. Однако тот факт, что коммерческие программные продукты представляют собой крупные системы и часто продаются как отдельные автономные системы, вносит дополнительные проблемы. Прн интеграции таких систем моьуг возникнуть, как ььинимум.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
