- •Гагарина. Л.Г., Федоров а.Р., Федоров п.А. Введение в архитектуру проектирования программного обеспечения Москва
- •Оглавление
- •5.11. Паттерны grasp
- •Глава 1. Архитектура как форма концептуального существования по
- •1.1. Определения архитектуры по и ее значимость
- •1.2. Место архитектурных решений
- •1.3. Роль архитектурных решений
- •1.4. Архитектурные концептуальные схемы. Определение и ретроспектива
- •Глава 2. Нормативные практики архитектурного описания по
- •2.1. Основные понятия
- •2.2. Содержание стандарта
- •2.3. Представления схемы ieee-1471
- •Глава 3. Рациональный процесс архитектурного моделирования
- •3.1. Архитектурные парадигмы
- •3.2. Примеры архитектурных стилей и моделей
- •Глава 4. Сравнительное сопоставление архитектурных видов
- •4.1. Сопоставление систем видов
- •4.2. Примеры систем видов
- •Языки описания архитектуры
- •Глава 5. Проектирование с учетом будущих изменений.
- •5.1. Что такое паттерн проектирования.
- •5.2. Как решать задачи проектирования с помощью паттернов
- •3. Зависимость от аппаратной и программной платформ.
- •5.4. Порождающие паттерны
- •5.4.1. Паттерн Фабричный метод (Factory Method) - уровень класса
- •Классический вариант фабричного метода, когда интерфейс фабричных методов объявляется в независимом классе-фабрике, а их реализация определяется конкретными подклассами этого класса (Рис. 33).
- •Реализация паттерна Factory Method на основе обобщенного конструктора
- •Void info() {
- •Void info() {
- •Void info() {
- •Int main()
- •V.Push_back( Warrior::createWarrior( Infantryman_id));
- •V.Push_back( Warrior::createWarrior( Archer_id));
- •V.Push_back( Warrior::createWarrior( Horseman_id));
- •Void info() {
- •Void info() {
- •Void info() {
- •Int main()
- •5.4.2. Паттерн Одиночка (Singleton) - уровень объекта
- •Классическая реализация Singleton
- •If(!p_instance)
- •Singleton Мэйерса
- •Улучшенная версия классической реализации Singleton
- •Void initialize( Singleton* p );
- •Void SingletonDestroyer::initialize( Singleton* p ) {
- •If(!p_instance) {
- •Использование нескольких взаимозависимых одиночек
- •Int main()
- •5.4.3. Паттерн Абстрактная фабрика (Abstract Factory) - уровень объекта
- •Пример кода для паттерна Abstract Factory
- •Void info() {
- •Int main()
- •5.4.4. Паттерн Строитель (Builder) - уровень объекта
- •Void info() {
- •Int main()
- •Infantryman
- •Infantryman
- •5.4.5. Паттерн Прототип (Prototype) - уровень объекта
- •Void info() {
- •Void info() {
- •5.4.6. Обсуждение порождающих паттернов
- •5.5. Структурные паттерны
- •5.5.1. Паттерн Адаптер, обертка (Adapter, wrapper)
- •Адаптер объекта применяет композицию объектов.
- •Int main()
- •Void adjust() {} // Настройка датчика (защищенный метод)
- •5.5.2. Паттерн Мост (Bridge)
- •Void log( string & str );
- •Достоинства паттерна Bridge
- •5.5.3. Паттерн компоновщик (Composite)
- •Описание паттерна Composite
- •Virtual void addUnit(Unit* p) {
- •Int main()
- •Virtual CompositeUnit* getComposite() {
- •Void addUnit(Unit* p);
- •Достоинства паттерна Composite
- •Недостатки паттерна Composite
- •5.5.4. Паттерн декоратор (Decorator , wrapper, обертка)
- •Реализация паттерна Decorator
- •Int width, height;
- •5.5.5. Паттерн фасад (Facade)
- •Void submitNetworkRequest()
- •If (_engineer.CheckOnStatus())
- •5.5.6. Паттерн приспособленец (Flyweight)
- •Структура паттерна приспособленец (Flyweight)
- •Icon(char *fileName)
- •Icon *FlyweightFactory::_icons[];
- •5.5.7 Паттерн заместитель (Proxy, surrogate, суррогат)
- •Void draw()
- •Int balance;
- •5.5.8. Обсуждение структурных паттернов
- •5.6. Паттерны поведения
- •5.6.1. ПаттернЦепочка обязанностей (Chain of Responsibility)
- •Void setNext(Base *n)
- •5.6.2. Паттерн Command (команда)
- •Реализация паттерна Command
- •5.6.3. Паттерн Interpreter (интерпетатор)
- •Совместное использование паттернов Interpreter и Template Method
- •Int interpret(char*); // interpret() for client
- •Virtual void interpret(char *input, int &total)
- •Int index;
- •If (!strncmp(input, nine(), 2))
- •Virtual char one(){}
- •Int items[10];
- •Int main()
- •5.6.5. Паттерн Mediator (посредник)
- •Virtual void changed();
- •Void Widget::changed()
- •Int main()
- •5.6.6. Паттерн Memento (хранитель)
- •Int _state;
- •Void static redo()
- •Int main()
- •Integer: 11
- •5.6.7. Паттерн Observer (наблюдатель)
- •Int value;
- •5.6.8. Паттерн State
- •Void setCurrent(State *s)
- •5.6.9. Паттерн Strategy
- •Void compress( const string & file ) {
- •5.6.10. Паттерн Template Method (шаблонный метод)
- •Void a()
- •V.Visit(this);
- •V.Visit(this);
- •V.Visit(this);
- •Int main()
- •5.6.12. Обсуждение паттернов поведения
- •5.7. Дальнейшее развитие идеи паттернов проектирования
- •5.8. Архитектурные системные паттерны
- •5.9. Паттерны управления
- •5.9.1. Паттерны централизованного управления
- •5.10. Паттерны интеграции корпоративных информационных систем
- •5.10.1. Структурные паттерны интеграции
- •5.10.2. Паттерны по методу интеграции
- •5.10.3. Паттерны интеграции по типу обмена данными
- •5.12. Антипаттерны (anti-patterns)
- •Глава 6. Архитектура и характеристики качества
- •6.1. Специфика требований к качеству по
- •6.2. Подход к построению архитектуры с позиций качества
- •6.3. Подходы к оцениванию архитектуры
Глава 2. Нормативные практики архитектурного описания по
2.1. Основные понятия
Каждая из рассмотренных выше концептуальных архитектурных моделей разрабатывалась для решения конкретных задач создания бизнес-архитектуры предприятий, процессов управления в военной или политической сфере, хотя их использование при разработке ПО тоже возможно. Но эти модели не совсем подходят для «архитектуры ПО» как отдельной и важной проблемной области.
Изучение и обобщение накопленного опыта при построении концептуальных архитектурных моделей привело к разработке стандарта IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems [11] (Рекомендуемое для практики описание архитектуры систем, интенсивно использующих ПО).
В стандарте представлены обзор его области применимости (границы, цели, предполагаемые пользователи и соглашения по рекомендуемой практике), ссылки на родственные стандарты, концептуальный каркас (контекст архитектурного описания, заинтересованные в разработке ПО лица, архитектурная деятельность в рамках жизненного цикла ПО, использование архитектурных описаний), практика архитектурных описаний (документирование архитектуры, идентификация заинтересованных лиц и их интересов, селекция архитектурных точек зрения, архитектурные виды, соответствие в совокупностях архитектурных видов, обоснования архитектур, образцы использования) и ряд приложений (библиография, замечания по терминологии, образцы точек зрения, отношения с другими стандартами).
Стандарт позиционирован его разработчиком (IEEE Architecture Planning Group) как «рекомендуемая практика». Он не является стандартом архитектуры, процесса построения архитектуры или метода разработки архитектуры, он предоставляет разработчикам ПО рекомендации для описания архитектуры (Architectural Description, AD). Эти рекомендации используют модальности «должен» (без обязательности) и «можно» (как вариант). Но рекомендации базируются на большом опыте успешных разработок ПО и приняты мировыми лидерами индустрии разработки ПО.
Цели и задачи стандарта IEEE 1471-2000:
- нацелен на архитектурноге описание (АО) систем, интенсивно использующих программное обеспечение, в которых программная составляющая оказывает существенное влияние на проектирование, конструирование, развертывание и эволюцию системы как целого;
- предполагает, что организации и предприятия, решившие использовать стандарт, должны сами решать, в каком объеме и как он будет внедряться в разработки ПО;
- дает широкие рамки интерпретации архитектуры, как средства, пригодного для процесса разработки ПО;
- исходит из того, что описание архитектуры может быть согласовано широким кругом лиц, вовлеченных в разработку ПО, в то время как система, проект, процесс и организация работ такой возможности обычно не предоставляют (из-за специфики разнородной профессиональной компетенции и языка);
- определяет концептуальную структуру (систему понятий) для описания архитектуры и ее использования;
- устанавливает термины и понятия для архитектурного мышления;
- устанавливает концептуальный каркас и словарь для рассуждений об архитектурной форме существования ПО в виде архитектурного описания;
- обеспечивает средства для рассуждений об архитектурном описании в контексте лиц, вовлеченных в процесс разработки ПО, жизненного цикла ПО и использования АО;
- служит как базис для развития ПО на ранних этапах разработки, когда доступно только общее представление о проекте;
- вводит в системы требований для разработки ПО специальный раздел «архитектурных требований»;
- идентифицирует и устанавливает тождество в описаниях архитектур и пропагандирует озвученное в архитектурной практике;
- открывает возможность для эволюции таких практик, как достигших достаточной инструментально-технологической зрелости;
- служит как базис для развития предметной области, в которой существует только общая терминология;
- вносит надежду разработчикам ПО, что следование его рекомендациям внесет в разработку такие позитивы деятельности как «быстрее», «лучше» и «дешевле».
