k_voprosam_1x

1. Жизненный цикл информационной системы.
Жизненный цикл информационной системы — период времени, который начинается с
момента принятия решения о необходимости создания информационной системы и
заканчивается в момент ее полного изъятия из эксплуатации.
Полный жизненный цикл информационной системы включает в себя, как правило,
стратегическое планирование, анализ, проектирование, реализацию, внедрение и
эксплуатацию.
2. Модели жизненного цикла ИС
Модель жизненного цикла ИС — структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного
цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности
проекта и специфики условий, в которых система создается и функционирует.
Модель ЖЦ ИС включает в себя:
стадии;
результаты выполнения работ на каждой стадии;
ключевые события — точки завершения работ и принятия решений.
Модель жизненного цикла отражает различные состояния системы, начиная с момента
возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода
из употребления.
Наиболее типичными моделями жизненного цикла ИС являются
• каскадная модель Последовательное выполнение всех этапов проектирования
и реализации ИС, полная определенность требований к компонентам
ИС Любые изменения на ранних этапах приводят к повторному выполнению
последующих этапов работ (принцип «от начала и до конца»),
• спиральная модель Особый акцент делается на начальных этапах жизненного
цикла ИС анализе и проектировании Реализуемость технических решений
проверяется путем создания прототипов ИС или отдельных частей На
основании полученных разработок уточняются требования к ИС, выполняется
корректировка спецификаций ИС, создается новая версия Если результаты
удовлетворительные, выполняется переход на следующий этап с параллельным
завершением работ предыдущих этапов__
3. Методология проектирования. Каноническое проектирование.
Методология - это учение о структуре, логической организации, методах и средствах
деятельности. Методология проектирования информационных систем описывает
серию шагов, моделей и подходов, которые, если им тщательно следовать, вероятнее
всего приведут к хорошо работающим приложениям. Хотя методологии не
гарантируют того, что программные средства будут замечательными, они, благодаря
ясному общему представлению, помогают охватить все важные шаги или элементы,
которые надлежащим образом учитываются.
Каноническое проектирование ЭИС отражает особенности ручной технологии
индивидуального (оригинального) проектирования, осуществляемого на уровне
исполнителей без использования каких-либо инструментальных средств, позволяющих
интегрировать выполнение элементарных операций. Как правило, каноническое
проектирование применяется для небольших локальных ЭИС.
В основе канонического проектирования лежит каскадная модель жизненного цикла
ЭИС. Процесс каскадного проектирования в жизненном цикле ЭИС в соответствии с
применяемым в нашей стране ГОСТ 34601-90 «Автоматизированные системы стадий
создания» делится на следующие семь стадий:
• исследование и обоснование создания системы;
• разработка технического задания;
• создание эскизного проекта;
• техническое проектирование;
• рабочее проектирование;
• ввод в действие;
• функционирование, сопровождение, модернизация.
4. Методологий проектирования. Типовое проектирование.
Основные понятия и классификация методов типового проектирования
Методы типового проектирования ЭИС предполагают создание системы из готовых
покупных типовых элементов (типовых проектных решений). Для этого
проектируемая ЭИС должна быть декомпозируема на множество составляющих
компонентов (подсистем, комплексов задач, программных модулей и т.д.), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения.
Далее закупленные типовые элементы, как правило, включающие программные
продукты, настраиваются на особенности конкретного предприятия или
дорабатываются в соответствии с требованиями проблемной области.
5. Процессы жизненного цикла ИС.
Процесс определяется как совокупность взаимосвязанных действий, преобразующих
входные данные в выходные. Описание каждого процесса включает в себя перечень
решаемых задач, исходных данных и результатов.
В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы
ЖЦ ПО делятся на три группы:
Основные процессы ЖЦ ИС: процесс заказа, поставки, разработки, эксплуатации,
сопровождения.
Вспомогательные процессы ЖЦ ИС: процесс документирования, управления
конфигурацией, обеспечения качества, верификации, аттестации, совместного анализа,
аудита, решения проблем.
Организационные процессы ЖЦ ИС: процесс управления, создания инфраструктуры,
усовершенствования, обучения.
6. Процессы ЖЦ ИС. Процессы планирования.
Стадии жизненного цикла ИС
Жизненный цикл – период создания и использования ИС, охватывающий ее различные
состояния, начиная с момента возникновения необходимости в данной
автоматизированной информационной системе и заканчивая моментом ее полного
выхода из употребления у пользователей. Суть жизненного цикла разработки ИС в
различных подходах одинакова и сводится к выполнению следующих этапов:
Планирование проекта – непрерывный процесс, направленный на определение и
согласование наилучшего способа действий для достижения поставленных целей проекта
с учетом всех факторов его реализации.
Процессы планирования осуществляются на протяжении всего жизненного цикла проекта,
начиная с предварительного укрупненного плана в составе концепции проекта, и
заканчивая детальным планом работ завершающей фазы проекта. При этом происходит
уточнение и детализация планов по мере прогресса проекта.
Основным результатом этого этапа является План проекта.
Процесс планирования не завершается разработкой и утверждением первоначального
плана проекта. В ходе осуществления проекта могут происходить изменения как внутри
проекта, так и во внешнем окружении, которые требуют уточнения планов, а часто
значительного перепланирования. Поэтому процесс планирования может продолжаться на
протяжении всего проекта.
Планирование осуществления проекта может включать следующие процедуры:
Планирование целей и содержания проекта
Календарное планирование работ проекта
Планирование затрат и финансирования проекта
Планирование качества
Организационное планирование
Планирование коммуникаций
Планирование управления рисками
Планирование контрактов
Разработку сводного плана проекта.
7. Процессы ЖЦ ИС. Процессы определения требований к ИС.
Эксплуатация ИС (сопровождение, модернизация). Сбор рекламаций и статистики о
функционировании ИС, исправление недоработок и ошибок, оформление требований к
модернизации ИС и ее выполнение
Функциональные требования к информационной системе, которые описываются, в том
числе, и с помощью моделей процессов и структур данных, являются только частью
общих требований, которые содержаться в техническом задании. Раздел требований к
информационной системе технического задания может содержать следующие подразделы:
• требования к функциональным характеристикам. (В этом разделе должны быть указаны
требования к составу выполняемых функций, организации входных и выходных данных.)
• требования к надежности . (В разделе должны быть определены требования к
обеспечению надежного функционирования: контроль входной и выходной информации,
время и механизмы восстановления после программных и аппаратных отказов. В этом
разделе описывается организация системы безопасности, включая подсистемы контроля
доступа, шифрования и т. п.)
• настраиваемость. (Определяются требования к адаптационным возможностям ПО, то
есть указывается, какие изменения в методах управления и бизнес процессах должны быть
предусмотрены)
• условия эксплуатации (В этом разделе описывается необходимое обслуживание, которое
ребуется для работы системы, например, создание резервных копий, реиндексерование баз
и т. п., а так же требования к квалификации персонала (пользователей и обслуживающего
персонала). )
• требования к информационной и программной совместимости. (Требования к
нформационным структурам на входе и выходе, методам решения, исходным кодам,
зыкам программирования и программным средствам, используемым программой)
• требования к документации (В этом разделе указывается предварительный состав
программной документации, и при необходимости, специальные требования к ней)
8. Процессы ЖЦ ИС. Процессы проектирования.
Проектирование (техническое и логическое проектирование). В соответствии с
требованиями формируются состав автоматизируемых функций (функциональная
архитектура) и состав обеспечивающих подсистем (системная архитектура),
проводится оформление технического проекта ИС;
Проект – (от латинского projectus - брошенный вперед) – это скачок в развитии. То есть,
необходимым элементом проекта должна быть новизна. Если нет новизны, то это подскок
на месте, а не бросок вперед.
Полный процесс проектирования включает в себя целеполагание, уточнение проектной
ситуации, анализ проектной ситуации, дивергенцию, трансформацию, конвергенцию,
гармонизацию, экспертизу и защиту.
Анализ – это разложение на части.
Дивергенция – расхождение, расширение границ.
Конвергенция – схождение, соединение.
Трансформация – изменение формы.
Гармонизация – устранение конфликтов, противоречий.
Экспертиза – проверка, оценка.
9. Процессы ЖЦ ИС. Процессы кодирования.
Реализация (рабочее и физическое проектирование, кодирование). Разработка и
настройка программ, формирование и наполнение баз данных, формулировка рабочих
инструкций для персонала, оформление рабочего проекта;
В
ходе
этапа
кодирования
(программирования),
отталкиваясь
от
результатов моделирования, реализуется система в виде компонентов – исходных текстов
программ, сценариев, двоичных файлов, исполняемых модулей и т. д.
Более конкретно, целью кодирования являются:
Ø
Планирование необходимой на каждой итерации сборки системы.
Мы используем инкрементный подход к разработке, результатом чего является реализация системы посредством последовательности малых управляемых шагов.
Ø
Распределение системы путем отображения исполняемых
компонентов на узлы модели размещения. Эта деятельность базируется на активных
классах, обнаруженных в ходе анализа.
Ø
Реализация классов и подсистем проектирования, обнаруженных
входе моделирования, Так, классы проектирования реализуются в виде файлов компонентов, содержащих исходные тексты программ.
В рабочем процессе тестирования проверяются результаты реализации путем
тестирования каждой подсистемы, включая как внутренние и промежуточные, так и финальные версии системы, передаваемые внешним агентам.
Задачей тестирования являются:
Ø
Планирование тестов, необходимых на каждой итерации, включая
тесты на целостность и системные тесты. Тесты на целостность необходимо проводить
после каждой подсистемы, в то время как системные тесты требуются только в конце
итерации.
Ø
Проектирование и реализация тестов для создания тестовых
примеров, определяющих предмет тестирования, процедур тестирования, определяющих
метод проведения тестирования, и, по возможности, – исполняемых тестовых компонентов для автоматизации тестирования.
Ø
Проведение разнообразных тестов и систематическая обработка
результатов каждого теста. Подсистемы, в которых обнаруживаются дефекты,
подвергаются повторному тестированию. После этого может произойти возврат к
предшествующим рабочим процессам с целью исправления серьезных ошибок.
10. Процессы ЖЦ ИС. Процессы интеграции.
Внедрение (опытная эксплуатация). Комплексная отладка подсистем ИС, обучение
персонала, поэтапное внедрение ИС в эксплуатацию по подразделениям организации,
оформление акта о приемо-сдаточных испытаниях ИС;
Автоматизированная система управления технологическим процессом
Системная интеграция:
– это комплексное решение по объединению разнородных подсистем в
единое пространство.
В процессе создания АСУТП встает необходимость решения проблемы по
соединению разнородных подсистем в одно целое. Подсистемы могут
различаться назначением, областью применения, сложностью, объемом,
новизной, адаптируемостью, количественными характеристиками, местом
расположения и т.д.
Так же в процессе создания АСУТП существует необходимость
отслеживания соответствия подсистем заданным характеристикам, на каждом
этапе жизненного цикла, для чего в процессе интеграции необходимо проводить
верификацию и валидацию
Этапы системы интеграции:
Планирование интеграции на стадии замысла
Интеграции на стадии разработки системы
Интеграции на стадии производства
Интеграции на стадии ввода
11. Процессы планирования. Планирование инфраструктуры проекта.
Планирование ресурсов проекта
Планирование инфраструктуры начинается с формирования требований. Как правило,
требования к компьютерному оборудованию и сопутствующей инфраструктуре
формируются на основе анализа внутренней информации компании, включающей оценку
характеристики работы компьютерного оборудования. Инфраструктуру необходимо
оценить относительно задач различного профиля, и проводить ее оценку на следующих
уровнях:



рабочие места;
сеть;
системы (серверы приложений и баз данных). Рекомендуется назначать
ответственного за обеспечение команды
проекта оборудованием, созданием рабочей среды, библиотеки проекта. Работы по
созданию инфраструктуры проекта необходимо контролировать. Для членов команды
проекта на территории заказчика должны быть подготовлены рабочие места, оснащенные
офисным оборудованием, телефонами, персональными компьютерами, принтерами,
комнатами для ведения переговоров, учебными аудиториями и прочими материальными
ресурсами. Одним из обязательных элементов инфраструктуры является библиотека
проекта.
Пример процедуры создания инфраструктуры проекта
Для создания инфраструктуры необходимо:

обеспечить поставки материальных ресурсов - требуется заказать или запросить
необходимые ресурсы;



организовать установку оборудования - обеспечить доставку, провести установку и
тестирование оборудования;
обеспечить сервисное обслуживание оборудования - разработать график
сервисного обслуживания;
протестировать рабочую среду на предмет ее совместимости с требованиями к
функциональности, совместимости и доступности.
ПЛАНИРОВАНИЕ — ОСНОВА УПРАВЛЕНИЯ РЕСУРСАМИ ПРОЕКТА
Планирование — процесс, который доложен осуществляться в соответствии с проектносметной документацией, основываясь на общем плане проекта. В процессе планирования
должен быть произведен общий анализ работ и ресурсов. Необходимо учитывать
ограничение ресурсов и их прогнозное распределение на основе графиков потребности в
ресурсах. Планирование ресурсов проекта — очень важный процесс, который является
основой не только определения во времени потребностей в ресурсах, но и основой
планирования поставок ресурсов, основой определения возможности обеспечения
ресурсами для заключения контрактов по закупкам ресурсов, а так же основой для того,
чтобы благоразумно распределять уже закупленные ресурсы по работам проекта.
Ресурсное планирование - основная составляющая управления проектами. Ресурсное
планирование это не только разработка и анализ ресурсов и работ, которые направлены на
достижение целей проекта, это еще и разработка системы распределения ресурсов,
контроль над ходом работ (сравнение фактических и плановых параметров работ, выбор
корректирующих действий), выбор исполнителей.
12. Типовое проектирование. Основные процессы при проектировании на
платформе 1С. Ограничения платформы.
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов.
Основополагающим требованием для применения методов типового проектирования является
возможность декомпозиции проектируемой ИС на множество составляющих компонентов
(подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных
компонентов выбираются имеющиеся на рынке типовые проектные решения, которые
настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному
использованию) проектное решение.
Система проектирования прикладных решений (СППР) предназначена для проектирования
прикладных решений (конфигураций) на платформе «1С:Предприятие» и ведения технической
документации проекта.
Система проектирования прикладных решений разработана как конфигурация на платформе
«1С:Предприятие 8.2».
Проектирование при помощи СППР охватывает следующие этапы:









Описание автоматизируемых процессов
Создание логической модели проектируемой системы
Разработка архитектуры
Проектирование детальных сценариев работы пользователей
Разработка прав доступа
Подготовка справки
Работа с требованиями
Управление изменениями в проекте
Прочие возможности
Подробнее: http://v8.1c.ru/model/
Ограничения:


В версии 7.7 при использовании базы данных в формате DBF размер файла базы данных
ограничен 1 или 2 гигабайтами. Данная проблема связана с FoxPro-совместимым
форматом доступа к DBF.
В версиях 8.х наблюдаются проблемы с отображением модальных окон при использовании
технологии Microsoft RemoteApp, что делает данную технологию неприменимой.
13. Типовое проектирование. Основные процессы при проектировании на
платформе MS DAX.
14. Типовое проектирование. Основные процессы при проектировании на
платформе Oracle.
ПО КОНСПЕКТУ ЛЕКЦИЙ ИВАНОВА
Выделяется два метода внедрения систем:
1) Application Implementation method
2) Data warehouse method
Фазы----------------------------------------------------------
Определение
Анализ
Принятие
Разработка
операций
решения
Определение бизнес
требований
Отображение бизнес
требований
Разработка архитектуры
Разработка дополнительной функциональности
Конвертация данных
Документирование
Переход
Промышленная
эксплуатация
Тестирование функциональности/
производительности
Обучение проектной группы
об. конеч.
польз.
Ввод в эксплуатацию
Ввод в
эксплуатацию
 работы
Фазы:
1) Определение – определение требований, …
2) Анализ операций – документирование будущих бизнес процессов
3) Принятие решения. Результат фазы – модель бизнес решения
4) Разработка. Результат фазы – ПО + документация
5) Переход. Производится тестирование и прием зак. работ.
6) Промышленная эксплуатация. Обеспечение работоспособности бизнес решения,
устранение мелких недостатков.
Методология определяет:
1) Требования к проектной группе на уровне состава, квалификации, ролей,..
Обязанности в проектной команде, наличие сотрудников заказчика.
2) Регламентирование работы до уровня операций
3) Виды документации и их содержание, определяет жизненный цикл всех
документов
15. Анализ объекта автоматизации. Методологии анализа.
Анализ является первым этапом создания ИС, на котором требования заказчика
уточняются, формализуются и документируются. Фактически на этом этапе дается ответ
на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху
всего проекта.
Целью анализа является преобразование общих, расплывчатых знаний об исходной
предметной области в точные определения и спецификации, а также генерация
функционального описания системы. На этом этапе специфицируются:





внешние условия работы системы;
функциональная структура системы;
распределение функций между человеком и системой, интерфейсы;
требования к техническим, информационным и программным компонентам
системы;
условия эксплуатации.
Разработка перечисленных выше спецификаций при создании ИС, предназначенной для
автоматизации управленческих процессов, в общем случае, проходит четыре стадии.
Структурный анализ начинается с исследования того, как организована система
управления предприятием, с обследования функциональной и информационной
структуры системы управления. По результатам обследования аналитик на первой стадии
анализа строит обобщенную логическую модель исходной предметной области,
отображающую ее функциональную структуру, особенности основной деятельности и
информационное пространство, в котором эта деятельность осуществляется. Используя
специальную терминологию, можно сказать, что аналитик строит модель "как есть".
Вторая стадия работы, к которой привлекаются заинтересованные представители
заказчика, а при необходимости и независимые эксперты, состоит в анализе модели "как
есть", выявлении ее недостатков и узких мест, определение путей совершенствования
системы управления на основе выделенных критериев качества.
Третья стадия анализа, содержащая элементы проектирования, - создание
усовершенствованной обобщенной логической модели, отображающей реорганизованную
предметную область или ее часть, которая подлежит автоматизации. Эту модель можно
назвать моделью "как надо".
Заканчивается процесс разработкой "карты автоматизации", представляющей собой
модель реорганизованной предметной области, на которой обозначены "границы
автоматизации".
Основным документом, отражающим результаты работ первого этапа создания ИС,
является техническое задание на проект (разработку), содержащее, кроме
вышеперечисленных определений и спецификаций, также сведения об очередности
создания системы, сведения о выделяемых ресурсах, директивных сроках проведения
отдельных этапов работы, организационных процедурах и мероприятиях по приемке
этапов, защите проектной информации и т.д.
16. Анализ объекта автоматизации. Инструментальные средства поддержки
процессов анализа.
Для целей моделирования систем вообще, и структурного анализа в частности,
используются три группы средств, отображающих:



функции, которые система должна выполнять;
процессы, обеспечивающие выполнение указанных функций;
данные, используемые при выполнении функций, и отношения между этими
данными.
Среди всего многообразия средств решения указанных задач в методологиях структурного
анализа наиболее часто и эффективно применяемыми являются:



FDD (Functional Decomposition Diagrams) - диаграммы функциональной
декомпозиции;
DFD (Data Flow Diagrams) - диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь"
Все они содержат графические и текстовые средства моделирования: первые - для
удобства демонстрации основных компонентов модели и их связей, вторые - для
обеспечения точного определения компонентов и связей.
При помощи этих средств строятся как логические модели исходной и реорганизованной
систем управления, так и логическая модель автоматизированной системы управления подробное описание того, что и как должна делать система, освобожденное, насколько это
возможно, от рассмотрения путей реализации.
CASE-технология
Ниже перечислены основные виды и последовательность работ, рекомендуемые при
построении логических моделей предметной области в рамках CASE-технологии анализа
системы управления предприятием.
1. Проведение функционального и информационного обследования системы управления
(административно-управленческой деятельности) предприятия:






определение организационно-штатной структуры предприятия;
определение функциональной структуры предприятия;
определение перечня целевых функций структурных элементов - подразделений и
должностных лиц;
определение круга и очередности обследования структурных элементов системы
управления согласно сформулированным целевым функциям;
обследование деятельности выделенных структурных элементов;
построение FD-диаграммы системы управления с указанием структурных
элементов и функций, реализация которых будет моделироваться на DFD-уровне.
2. Разработка моделей деятельности структурных элементов и системы управления в
целом:





выделение множества внешних объектов, оказывающих существенное влияние на
деятельность структурного элемента;
спецификация входных и выходных информационных потоков;
выявление основных процессов, определяющих деятельность структурного
элемента и обеспечивающих реализацию его целевых функций;
спецификация информационных потоков между основными процессами
деятельности, уточнение связей между процессами и внешними объектами;
оценка объемов, интенсивности и других необходимых характеристик
информационных потоков;


разработка иерархии диаграмм потоков данных, образующих функциональную
модель деятельности структурного элемента;
объединение DFD-моделей структурных элементов в единую модель системы
управления предприятием.
3. Разработка информационных моделей структурных элементов и модели
информационного пространства системы управления:












определение сущностей модели и их атрибутов;
проведение атрибутного анализа и оптимизация сущностей;
идентификация отношений между сущностями и определение типов отношений;
разрешение неспецифических отношений;
анализ и оптимизация информационной модели;
объединение информационных моделей в единую модель информационного
пространства.
Разработка предложений по автоматизации системы управления предприятия:
определение границ автоматизации - составление перечня автоматизируемых
структурных элементов, разбиение процессов основной деятельности на
автоматические, автоматизированные и ручные;
составление перечня подсистем и логических АРМов (автоматизированных
рабочих мест), определение способов их взаимодействия;
разработка предложений по очередности проектирования и реализации подсистем
и отдельных логических АРМов, входящих в состав ИС;
разработка требований к средствам базового технического обеспечения ИС;
разработка требований к средствам базового программного обеспечения ИС.
Логическая модель, отображающая деятельность системы управления предприятия и
информационное пространство, в котором эта деятельность протекает, представляют
собой "снимок" положения дел (функциональная структура, роли должностных лиц,
взаимодействие подразделений, принятые технологии обработки управленческой
информации, автоматизированные и неавтоматизированные процессы и т.д.) на момент
обследования. Эта модель позволяет понять, что делает и как функционирует предприятие
с позиций системного анализа, сформулировать предложения по улучшению ситуации.
Модель является не просто реализацией начальных этапов работы и основанием для
формирования технического задания на ее последующие этапы. Она представляет собой
самостоятельный результат, имеющий большое практическое значение.
Построенная модель является законченным результатом по следующим причинам:
1. Она включает в себя модель существующей неавтоматизированной технологии,
принятой на предприятии. Формальный анализ этой модели позволяет выявить
узкие места в управлении предприятием и сформулировать рекомендации по его
улучшению (независимо от того, предполагается ли дальнейшая разработка
автоматизированной системы или нет).
2. Она независима и отделяема от конкретных разработчиков, не требует
сопровождения и может быть безболезненно передана другим лицам. Более того,
если по каким-либо причинам предприятие не готово к реализации проекта в
данный момент времени, модель может быть "положена на полку" до тех пор, пока
в ней не возникнет необходимость.
3. Она позволяет осуществлять эффективное обучение новых работников конкретным
направлениям деятельности предприятия, так как соответствующие технологии
содержатся в модели.
4. С ее помощью можно осуществлять предварительное моделирование
перспективных направлений деятельности предприятия с целью выявления новых
потоков данных, взаимодействующих процессов и структурных элементов.
5. Она обеспечивает распространение накопленного опыта на других предприятиях,
дает возможность унифицировать административно-управленческую и
финансовую деятельность этих предприятий.
Развитие логической модели предметной области, ее последовательное превращение в
модель целевой ИС, позволит интегрировать перспективные предложения руководства и
ведущих сотрудников предприятия, экспертов и системных аналитиков, сформировать
видение новой, реорганизованной и автоматизированной деятельности предприятия.
17. Анализ объекта автоматизации. Методологии анализа. SADT, ГОСТ 50.1.028.
SADT (Structured Analysis and Design Technique) — методология структурного анализа и
проектирования, интегрирующая процесс моделирования, управление конфигурацией
проекта, использование дополнительных языковых средств и руководство проектом со
своим графическим языком. Процесс моделирования может быть разделен на несколько
этапов: опрос экспертов, создание диаграмм и моделей, распространение документации,
оценка адекватности моделей и принятие их для дальнейшего использования. Этот
процесс хорошо отлажен, потому что при разработке проекта специалисты выполняют
конкретные обязанности, а библиотекарь обеспечивает своевременный обмен
информацией.
Наиболее удобным языком моделирования таких процессов является методология SADT
SADT-МЕТОДОЛОГИЯ – совокупность методов, правил и процедур, предназначенных
для построения функциональной структуры сложных иерархических систем в виде
модели, которая должна дать ответ на некоторые заранее определенные вопросы. В основе
этого метода мо-делирования систем лежит описание системы, создаваемого с помощью
естественного языка, позволяющего свободно описать функционирование моделируемой
системы. На основе гра--фических средств SADT/IDEF0 дескриптивное описание
системы снабжается изображением ее модели, которое практически полностью устраняет
возможную неоднозначность семантического описания. SADT - это методология,
разработанная специально для того, чтобы облегчить описание и понимание
искусственной системы средней сложности и ее среды до определения требований к
программному обеспечению или к чему-либо другому.
В основе методологии SADT лежат два основных принципа:
1. SA-блоки, на основе которых создается иерархическая многоуровневая модульная
систе-ма, каждый уровень которой представляет собой законченную систему
(блок), поддержи-ваемую и контролируемую системой (блоком), находящейся над
ней.
2. Декомпозиция. Использование этой концепции позволяет разделить каждый блок,
пони--маемый как единое целое, на свои составляющие, описываемые на более
детальной диа-грамме. Процесс декомпозиции проводится до достижения нужного
уровня подробности описания. Диаграмма ограничивается 3-6 блоками для того,
чтобы детализация осуществ-лялась постепенно. Вместо одной громоздкой модели
используется несколько небольших взаимосвязанных моделей, значения которых
взаимно дополняют друг друга, делая понятной структуризацию сложного объекта.
Применение SADT методологии основано на формализованном процессе создания
системы, при разбиении его на следующие фазы:







анализ - определение того, что система будет делать;
проектирование - определение подсистем и их взаимодействие;
реализация - разработка подсистем по отдельности;
объединение - соединение подсистем в единое целое;
тестирование - проверка работы системы;
установка - введение системы в действие;
функционирование - использование системы.
Обычно SADT-методология применяется на ранних этапах жизненного цикла
информационной системы.
SADT-МОДЕЛЬ - это точное, полное и адекватное текстовое и графическое описание
системы имеющей конкретное назначение, выполненное в виде иерархически
организованной со-вокупности диаграмм, созданных на основе стандартного
представления данных..
В SADT-моделях используются как естественный, так и графический языки. Для
передачи информации о конкретной системе источником естественного языка служат
люди, описываю-щие систему, а источником графического языка - сама методология
SADT.
SADT выделяется среди современных методологий описания систем благодаря своему
широкому применению, т.к. SADT:


является единственной методологией, легко отражающей такие системные
характеристики, как управление, обратная связь и исполнители. Это объясняется
тем, что SADT изначально возникла на базе проектирования систем более общего
вида в отличие от других структурных методов, "выросших" из проектирования
программного обеспечения;
в дополнение к имеющимся концепциям и стандартам для создания систем
добавлены развитые процедуры поддержки коллективной работы;


предназначена для применением на ранних стадиях создания системы;
можно сочетать с другими структурными методами. Это достигается
использованием графических SADT-описаний в качестве схем, связывающих
воедино различные методы, примененные для описания определенных частей
системы с различным уровнем детализации.
18. Анализ объекта автоматизации. Методологии анализа. RUP, UML.
Rational Unified Process (RUP) – одна из лучших методологий разработки программного
обеспечения, созданная в компании Rational Software. Основываясь на опыте многих
успешных программных проектов, Унифицированный процесс позволяет создавать
сложные программные системы, основываясь на индустриальных методах разработки.
Одним из основных столпов, на которые опирается RUP, является процесс создания
моделей при помощи унифицированного языка моделирования (UML).
UML (англ. Unified Modeling Language — унифицированный язык моделирования) —
язык графического описания для объектного моделирования в области разработки
программного обеспечения. UML является языком широкого профиля, это открытый
стандарт, использующий графические обозначения для создания абстрактной модели
системы, называемой UML-моделью. UML был создан для определения, визуализации,
проектирования и документирования, в основном, программных систем. UML не является
языком программирования, но в средствах выполнения UML-моделей как
интерпретируемого кода возможна кодогенерация.
Использование UML не ограничивается моделированием программного обеспечения. Его
также используют для моделирования бизнес-процессов, системного проектирования и
отображения организационных структур.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения
в графических обозначениях для представления общих понятий (таких как класс,
компонент, обобщение (generalization), объединение (aggregation) и поведение), и больше
сконцентрироваться на проектировании и архитектуре.
Принципы
В основе RUP лежат следующие принципы:


Ранняя идентификация и непрерывное (до окончания проекта) устранение
основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе
(анализ и построение модели прецедентов (вариантов использования)).




Ожидание изменений в требованиях, проектных решениях и реализации в процессе
разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит
архитекторам.
Жизненный цикл разработки
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале
продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных
на данную итерацию целей, создать или доработать проектные артефакты и получить
промежуточную, но функциональную версию конечного продукта. Итеративная
разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и
устранять риски на ранних стадиях проекта, а также эффективно контролировать качество
создаваемого продукта.
Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых
включает в себя одну или несколько итераций:
Графическое представление процесса разработки по RUP
19. Анализ объекта автоматизации. Методологии анализа. ARIS.
ARIS (акроним от англ. Architecture of Integrated Information Systems) — методология и
тиражируемый программный продукт для моделирования бизнес-процессов организаций.
Продукт и методология принадлежат немецкой компании Software AG как результат
поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера
(нем. August-Wilhelm Scheer).
Методология
Среди большого количества возможных методов описания можно выделить следующие:
1. eEPC (англ. extended event-driven process chain) — метод описания процессов;
2. ERM (англ. entity-relationship model) — модель «сущность-связь» для описания
структуры данных;
3. UML (англ. unified modeling language) — объектно-ориентированный язык
моделирования.
Технология ARIS Script позволяет в автоматическом режиме производить:
1. Формирование нормативных документов на основании моделей ARIS (например,
паспорт процесса, регламент процесса).
2. Формирование аналитических отчётов на основании моделей ARIS.
3. Интеграцию ARIS Toolset с другими приложениями и базами данных.
4. Формирование базы моделей ARIS на основании готовых спецификаций.
Концепция архитектуры ARIS.
Архитектура ARIS создает основу для разработки и оптимизации интегрированных
информационных систем, а также для описания их реализации. Выбор уровней и типов
описаний формирует архитектуру ARIS, которая используется в качестве модели для
построения процессов, связанных с управлением бизнесом, их анализа и оценки.
Типы моделей.
В ARIS представлены более 100 видов моделей. Как выбрать наиболее подходящие с
точки зрения подхода к описанию деятельности предприятия?
Как правило, в основе описания бизнес-процессов лежат цепочки процессов. Цепочки
могут описаны как диаграммой VAD, которая рассматривает процесс со стратегических
точек зрения и детальные диаграммы eEPC (от Extended Process Chain - расширенная
цепочка процесса). eEPC-диаграммы являются стержнем, который описывает ход каждого
процесса на предприятии (конечно когда рассматривается процессный аспект
деятельности).
Потребности в моделировании организационно-штатных структур покрывают различные
диаграммы, в том числе диаграмма Organization Chart - модель орг. структуры
предприятия.
Потребности в моделировании данных и информационных хранилищ могут быть
обеспечены при использовании всевозможных ERM- и UML-диаграмм. Эти диаграммы
дают полное представление о структуре данных и составе информационных средств
предприятия.
Функциональные модели предназначены для моделирования функциональной структуры,
когда процессный подход не применим или недостаточно укрепил позиции в организации.
Существуют модели выходов/управления, которые не рассматриваются в программных
средствах ARIS, но занимают не менее важное место в процессе моделирования. Эти
диаграммы содержатся в других разделах и в каждой части здания ARIS есть свои
диаграммы выходов и управления.
Некоторые диаграммы невозможно отнести к тому или иному признаку, т.к. их
характеристики подпадают под многие параметры. В этом случае в ARIS активно
практикуется метод "свободного" моделирования, когда используются те диаграммы,
которые интуитивно понятны, как специалистам в области консалтинга, так и руководству
и программистам, реализующим отдельные программные модули.
Таким образом, мы зафиксировали в архитектуре ARIS набор типов моделей, каждая из
которых «расписывается » по уровням. Вместе с описанием проблем бизнеса, которое
служит стартовой точкой для анализа, они составляют тринадцать компонент архитектуры
ARIS. Теперь необходимо выбрать и представить методы описания каждой компоненты
архитектуры.
Критерии для выбора этих методов следующие:





простота и выразительность средств изображения,
поддержка смыслового содержания , для отображения специфики предмета,
возможность использования полного набора методов для различных типов
приложений,
степень знакомства с методами и наличие необходимой литературы,
определенная степень независимости методов от технической реализации в
информационных и коммуникационных системах.
Всем этим характеристикам удовлетворяет программное обеспечение ARIS компании IDs
Sheer.
ARIS - это одновременно и нотация, и методология, и программный продукт, и
архитектура. Когда говорят ARIS, то человек, прочитавший данную статью и другие
книги, например, выпущенные компаниями "Весть-Мета Технология" и "Логика Бизнеса",
всегда уточнит, о чем идет речь.
20. Процессы проектирования. Проектирование системной архитектуры.
Проектирование — процесс разработки проекта, то есть комплекта документации,
предназначенной для создания определённого объекта, его эксплуатации, ремонта и
ликвидации, а также для проверки или воспроизведения промежуточных и конечных
решений, на основе которых был разработан данный объект. Проектирование —
длительный процесс и включает этапы от подготовки технического задания до испытания
опытных образцов.
Проектирование, независимо от его содержания, это составная часть планирования.
Объектом проектирования может быть материальный предмет, выполнение работы,
оказание услуги.
Проектирование обладает своей методологией, которая
включает структуру деятельности, принципы и нормы деятельности, субъектов, объект и
его модели, методыи др.
Системное проектирование комплексно решает поставленные задачи, принимает во
внимание взаимодействие и взаимосвязь отдельных объектов-систем и их частей как
между собой, так и с внешней средой, учитывает социально-экономические и
экологические последствия их функционирования. Системное проектирование
основывается на тщательном совместном рассмотрении объекта(модели, элементная база)
проектирования и процесса(структура, принципы,законы,методы) проектирования,
которые в свою очередь включают ещё ряд важных частей,
21. ПП. Методики описания системной архитектуры.
Системное проектирование должно базироваться на системном подходе. На сегодняшний
день нельзя утверждать, что известен его полный состав и содержание применительно к
проектной деятельности, однако можно сформулировать наиболее важные из них:

Практическая полезность:

деятельность должна быть целенаправленной, устремленной на удовлетворение
действительных потребностей реального потребителя или определенной
социальной, возрастной или иной групп людей;

деятельность должна быть целесообразной. Важно вскрыть причины,
препятствующие использованию существующих объектов для удовлетворения
новых потребностей, выявить вызывающие их ключевые противоречия и
сконцентрировать усилия на решении главных задач;
деятельность должна быть обоснованной и эффективной. Разумным будет
использование не любого решения задачи, а поиск оптимального варианта;
Единство составных частей:



целесообразно любой объект, сложный ли он или простой, рассматривать
как систему, внутри которой можно выделить логически связанные более простые
части — подсистемы, единство частных свойств которых и образует качественно
новые свойства объекта-системы;

разрабатываемые объекты предназначены для людей, ими создаются и
эксплуатируются. Поэтому человек также обязан рассматриваться в качестве
одной из взаимодействующих систем. При этом должно приниматься во внимание
не только физическое взаимодействие, но и духовно-эстетическое воздействие;
внешняя, или как её ещё называют — жизненная среда, также должна
рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом;
Изменяемость во времени:



учёт этапов жизненного цикла объекта;

учёт истории и перспектив развития и применения разрабатываемого объекта, а
также областей науки и техники, на достижениях которых базируются
соответствующие разработки.
22. ПП. Архитектурные стили и шаблоны проектирования.
Шаблон (нем. Schablone) — в строительстве приспособление или инструмент для
вытягивания профильного карниза.
Шаблоны проектирования (паттерн, англ. design pattern) — это многократно
применяемая архитектурная конструкция, предоставляющая решение общей проблемы
проектирования в рамках конкретного контекста и описывающая значимость этого
решения. Паттерн не является законченным образцом проекта, который может быть прямо
преобразован в код, скорее это описание или образец для того, как решить задачу, таким
образом, чтобы это можно было использовать в различных ситуациях. Объектноориентированные шаблоны зачастую показывают отношения и взаимодействия между
классами или объектами, без определения того, какие конечные классы или объекты
приложения будут использоваться. Алгоритмы не рассматриваются как шаблоны, так как
они решают задачи вычисления, а не проектирования.
В 70-х годах двадцатого века архитектор Кристофер Александер (Christopher Alexander)
составил набор шаблонов проектирования. В области архитектуры эта идея не получила
такого развития, как позже в области программной разработки.
Архитектурный стиль, иногда называемый архитектурным шаблоном – это набор
принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для
семейства систем. Архитектурный стиль улучшает секционирование и способствует
повторному использованию дизайна благодаря обеспечению решений часто
встречающихся проблем. Архитектурные стили и шаблоны можно рассматривать как
набор принципов, формирующих приложение.
К ним относят такие шаблоны как клиент/сервер, многоуровневая архитектура,
компонентная архитектура, архитектура, основанная на шине сообщений, и сервисноориентированная
В следующей таблице перечислены основные фокусные области и соответствующие
архитектурные стили.
архитектура
Категория
Связь
Развертывание
Предметная область
Структура
Архитектурные стили
Сервисно-ориентированная
архитектура (SOA), шина сообщений
Клиент/сервер, N-уровневая, 3уровневая
Дизайн на основе предметной области
(Domain Driven Design)
Компонентная, объектноориентированная, многоуровневая
архитектура
23. ПП. Проектирование информационной архитектуры.
Информационная архитектура – систематизация информационного содержимого сайта и
навигации по нему.
Цель информационной архитектуры – упрощение поиска нужной информации при
помощи грамотно размещенных гиперссылок и организация комфортного пребывания
посетителя на сайте.
Проектирование информационной архитектуры состоит из анализа содержимого ресурса и
процесса разработки его структуры, которая будет помогать пользователю, находить
необходимую информацию (например, поиск нужного товара, получение ответа на вопрос
и др.).
Сайт, имеющий правильно спроектированную информационную архитектуру, имеет
следующие достоинства:

высокое положение в индексе поисковых систем: информационная архитектура
выделяет ключевые элементы, используемые поисковыми системами для
вычисления релевантности страниц (например, названия страниц, ключевые слова
и фразы, названия каталогов, файлов и др.);



улучшение Usability: информационная архитектура упрощает работу с ресурсом
(оптимальное расположение ключевых элементов навигации);
файлы удобно размещены и разбиты по категориям, как следствие, меньше
затрачивается времени на их поиск;
пропадает необходимость полного обновления сайта при добавлении новых
материалов.

24. ПП. Построение ER модели. Виды нотаций.
Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель
данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз
данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые
могут устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-модели в
конкретную схему базы данных на основе выбранной модели данных
(реляционной,объектной, сетевой или др.).
ER-модель представляет собой формальную конструкцию, которая сама по себе не
предписывает никаких графических средств её визуализации. В качестве стандартной
графической нотации, с помощью которой можно визуализировать ER-модель, была
предложена диаграмма сущность-связь (ER-диаграмма)
Нотация Питера Чена
Множества сущностей изображаются в виде прямоугольников, множества отношений
изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией.
Если отношение не является обязательным, то линия пунктирная. Атрибуты
изображаются в виде овалов и связываются линией с одним отношением или с одной
сущностью.[3]
Прочие натации






Bachman notation
EXPRESS
IDEF1x
Martin notation
(min, max)-Notation
UML
25. ПП. Построение логической модели данных.
Логическое (даталогическое) проектирование — создание схемы базы данных на
основе конкретной модели данных, например, реляционной модели данных. Для
реляционной модели данных даталогическая модель — набор схем отношений, обычно с
указанием первичных ключей, а также «связей» между отношениями, представляющих
собой внешние ключи.
Процесс формирования логической модели включает в себя следующие работы:
определение атрибутов (Attributes);
уточнение состава сущностей области хранения детальных данных (System of Records);
сопоставление данных систем-источников атрибутам сущностей логической модели
данных;
 определение иерархий (Hierarchy);
 определение состава и типов медленно меняющихся измерений (SCD);
 определение основных бизнес-запросов (Business Queries) - групп запросов
пользователей к определенному набору данных;
 проведение GAP-анализа:
o анализ логической модели (с учетом имеющихся данных в системах-источниках) на
предмет выявления требований, которые не могут быть удовлетворены;
o принятие решений по требованиям, которые не могут быть удовлетворены;
 определение состава и структуры агрегатов (Summary Area), витрин данных (Data Marts);
 определение состава значений (Domains) для измерений и иерархий;
 формирование рабочего документа с описанием логической модели;
 проведение внешнего аудита модели - сопоставление логической модели и требований
на уровне показателей;
 согласование логической модели с функциональными специалистами Заказчика.



26. ПП. Построение физической модели данных.
Физическое проектирование — создание схемы базы данных для конкретной СУБД.
Специфика конкретной СУБД может включать в себя ограничения на именование
объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того,
специфика конкретной СУБД при физическом проектировании включает выбор решений,
связанных с физической средой хранения данных (выбор методов управления дисковой
памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание
индексов и т.д.
Процесс формирования физической модели заключается в:








определении правил наименования объектов базы данных;
разработке объектов хранения (таблиц, материализованных представлений, кубов и т.п.);
определении состава полей (Columns) и их типов данных (Data Types);
формирование первичных (Primary Keys) и внешних ключей (Foreign Keys);
уточнении состава значений (Domains) для измерений и иерархий;
проектирование состава и структуры разделов (Partitions), индексов (Indexes),
последовательностей (Sequences) и т.д.
формирование рабочего документа с описанием физической модели;
согласование физической модели с техническими специалистами Заказчика.
27. ПП. Шаблоны информационной архитектуры.
Мы уже отмечали выше актуальность интеграции приложений и использования общих
компонент информационных систем (сервисов). Отражением этого факта является
существующая тенденция выделения данных аспектов в отдельные области архитектуры
предприятия. Существенную роль при реализации этих областей играют
стандартизованные элементы.
Подобно тому, как проект здания может включать в себя элементы ранее созданных
конструкций, так и реализация поддержки бизнес-процесса в информационной системе
может использовать уже известные фрагменты программного кода и/или типовые
конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить
сроки выполнения решения, с другой – уменьшить риски за счет использования
фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании
подходящих шаблонов (patterns). Английский термин "pattern" имеет различные варианты
перевода, в том числе "образец", "шаблон" и т.п. В данном случае мы будем использовать
русский термин "шаблон", оставляя кальку "паттерн" для обозначения аналогичных
объектов в области программной архитектуры. Шаблоны являются как бы проверенными
способами построения какой-то части системы.
Одним из удачных определений шаблонов является следующее: "Шаблон – это общее
решение некоторой повторяющейся проблемы в определенном контексте" [4.34].
Рис. 7.7. Шаблон – решение проблемы в контексте
То есть важным аспектом, связанным с шаблонами, является то, что они сопровождаются
определенными обоснованиями того, почему данное решение является хорошим в
условиях заданного контекста. Шаблоны являются следующим шагом в понимании и
применении моделей. Шаблон показывает, что делает некоторую модель хорошим
решением и как создать некоторое решение для определенной проблемы.
Осознание важности шаблонов привело к тому, что, например, методика описания
архитектуры Gartner выделяет шаблоны в качестве отдельного "слоя" архитектуры.
Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий
вклад в формирование исходного понятия "pattern" принадлежит известному архитектору
Кристоферу Александеру. В своей фундаментальной работе 1987 года [4.35] он выделил
более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между
офисами и др. Согласно Александеру, каждый такой прототип фактически определяет
рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале
Александер выделяет контекст, воздействующие силы и особенности применения данного
шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это
пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор,
найденное решение обеспечивает Катарсис.
Исходной целью этих работ Александера была не разработка каких-то новых идей, а,
напротив, анализ накопленного опыта строительства – как отдельных зданий, так и целых
городов – с целью выявления удачных архитектурных решений и способствовавших этому
факторов. Конечно, критерии определения удачности в данной области во многом
субъективны, так как зависят от общества, использующего данные постройки. В области
информационных технологий такими критериями могут быть полнота выполнения
требований, долговечность, эффективность реализации, а также, в соответствии с [4.36],
ориентация, прежде всего, на расширение, а не на ограничение возможностей
организации. Еще одним важным понятием из строительной архитектуры, которое нашло
свое отражение в сфере информационных технологий, стал язык шаблонов (Pattern
Language). В соответствии с определением Коупа, он является коллекцией
взаимодействующих между собой шаблонов, образующих систему.
В приведенном выше определении шаблона имеется три ключевых словосочетания:

Общее решение. Это означает, что шаблон не дает полного законченного решения. Он,
скорее, определяет класс проблемы и то, как эта проблема может быть решена с использованием
определенного подхода, с демонстрацией аргументов в пользу этого подхода. Сила шаблона
состоит в том, что он сформулирован на достаточно высоком уровне абстракции, чтобы быть
использованным в большом количестве ситуаций;

Повторяющаяся проблема. Это означает, что шаблоны используются в тех случаях, когда
проблема не является уникальной, и они наиболее полезны для решения часто встречающихся
проблем;

Определенный контекст. Это означает, что шаблон обеспечивает решение проблемы,
границы которой в общих чертах определены. Понимая условия, в которых предлагаемое
решение в форме шаблона является хорошим, вы далее строите свое собственное решение на
основе этого шаблона.
В области информационных технологий первоначально шаблоны получили признание в
области программной архитектуры. В широко известной работе группы авторов [4.37]
(которых в англоязычной литературе по числу авторов книги часто называют "бандой
четырех") описаны типовые конструкции для объектно-ориентированных языков
программирования, таких как C++. Большое количество ссылок по данной тематике и
примеров приведены на http://www.patterns.com. Но оказывается, что понятие шаблона
оказывается весьма эффективно и в области архитектуры предприятия в целом!
В отношении информационных технологий можно сказать, что шаблоны являются
логическими моделями технологий: это проектировочные идеи, которые могут быть
многократно использованы в рамках предприятия в целом [4.38]. Как правило, эти
решения служат, в каком-то смысле, индустриальными стандартами и обычно существуют
продолжительное время. Их можно рассматривать как некоторые схемы, которые
определяют компоненты решения, т.е. логический уровень проектирования (например,
сервер данных или сервер приложений), и которые показывают роли, взаимодействия и
связи компонент на этом уровне абстракции.
Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или
программного обеспечения. Как проиллюстрировано рисунком 7.8, интерес представляет
другое: как серверы взаимодействуют между собой и как они совместно обеспечивают
работу с системой клиента, использующего персональный компьютер? Какие роли играет
каждый компонент? Какие типы коммуникаций необходимы между ними?
Рис. 7.8. Шаблон показывает взаимодействие компонент системы между собой
Важность шаблонов для архитектуры предприятия в целом обусловлена следующими
причинами:

если используются корректные шаблоны, то вероятность получения адекватно
работающей физической реализации архитектуры возрастает;

разработка и использование шаблонов в рамках предприятия в целом обеспечивает
преимущества, связанные с их многократным использованием для решения различных проблем.
Это дает архитекторам возможности по использованию опыта и стандартизации решений при
создании новых систем;

использование шаблонов отделяет логический уровень от физического уровня
архитектуры. Это позволяет создать долговременно работающие решения и придает гибкость,
поскольку на последующем этапе эти достаточно постоянные конструкции могут быть связаны с
конкретными технологическими решениями.
Можно сказать, что архитектурные концепции (методики) и шаблоны являются двумя
инструментами для успешного, быстрого, эффективного с точки зрения затрат создания
моделей и реализации систем с минимальными рисками. Принято идентифицировать
шаблоны, которые относятся к различным доменам архитектуры (бизнес-шаблоны,
шаблоны инфраструктуры и т.д.) и различным уровням абстракции архитектуры.
Рис. 7.9. Архитектура, шаблоны и модели
В рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для
предприятия число различных шаблонов составляет порядка 30. Это включает шаблоны
использования унаследованных и старых клиент/серверных систем, модели для будущей
архитектуры (например, сервис-ориентированной) и т.д.
Описание шаблонов может выполняться с различной степенью детализации и
соответствия реальным условиям. В зависимости от этого уровня можно рассматривать
элементы языка шаблонов различной степени абстракции – идиомы, шаблоны дизайна
(design patterns) и рамочные модели (frameworks). При этом идиомы представляют собой
шаблоны самого "низкого уровня", которые зависят от конкретной технологии. Шаблоны
дизайна обладают определенной независимостью, но в то же время не могут
рассматриваться как система в целом. Хорошим примером являются шаблоны
стандартных классов. Например, понятие "Фабрики Объектов" в объектноориентированных приложениях, вообще говоря, не зависит от выбора конкретного языка
программирования и может быть реализовано схожим образом и на С++, и на Java.
Наконец, рамочные модели представляют собой "частично законченные" системы,
которые либо демонстрируют наиболее принципиальные элементы реализации, либо
являются полностью работоспособными системами для определенных упрощенных,
ограниченных или идеализированных внешних условий. Эти модели могут быть
использованы как основа для специализированных доработок, а также для быстрого
создания модели системы в целом на основе таких отдельных компонент.
Далее концепция шаблонов была расширена и в область инфраструктуры, так что теперь
можно вести речь о соответствующих комплексных программно-аппаратных решениях.
Для нашего рассмотрения наибольший интерес представляют шаблоны достаточно
высокого уровня. Применение таких решений значительно облегчает задачу реализации
новых элементов информационных систем. Каждый такой шаблон может объединять
конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную
платформу или несколько распределенных платформ, интерфейсы, метаданные и т.п.
Типичными примерами являются шаблон B2B (Business-to-Business) для взаимодействия с
Клиентами/Поставщиками или B2E (Business-to-Employee), описывающий взаимодействие
между информационной системой и сотрудниками.
Инфраструктурные шаблоны можно определить как стандартизированный набор
требований, компонент и сервисов, которые в совокупности формируют необходимую
адекватную инфраструктуру для данной прикладной системы и реализации логики
бизнес-процессов
[4.39].
Рисунок
7.10
иллюстрирует
общее
определение
инфраструктурного шаблона в форме многоуровневой классификации функций и
примерного списка технологических компонент на каждом уровне.
Рис. 7.10. Пример инфраструктурного шаблона
Организация инфраструктуры с помощью набора шаблонов позволяет единообразно
определять компоненты и функциональные возможности, в результате чего эта часть ИТинфраструктуры может многократно использоваться для различных типов прикладных
систем, имеющих общие требования к инфраструктуре. Это соответствует тому принципу,
который мы сформулировали в лекции 6, когда говорили о том, что различные стили и
типы прикладных систем и бизнес-процессов предъявляют различные требования к
инфраструктуре. Таким образом, вместо того, чтобы строить инфраструктуру для каждого
приложения, ее разрабатывают как набор нескольких шаблонов, каждый из которых
оптимально предназначен для определенной группы прикладных систем так, как показано
на рис. 7.11.
Рис. 7.11. От традиционной архитектуры – к архитектуре, использующей инфраструктурные
шаблоны
Большой интерес при создании бизнес-архитектуры предприятия представляют бизнесшаблоны. В соответствии с [4.34] описание бизнес-шаблона включает:



описание поддерживаемой бизнес-функции;
данные, которые требуются для выполнения описанной бизнес-функции;
бизнес-компоненты, которые являются представлением данных и функций бизнеса на
языке информационных технологий;

возможно, описание инфраструктуры, которая необходима для поддержки функций,
данных и компонент.
Заинтересованным в этом вопросе читателям мы рекомендуем статью [4.34], которая
опубликована в журнале Microsoft, посвященном вопросам архитектуры; в электронном
виде публикацию можно найти по адресу http://msdn.microsoft.com/architecture/journ/.
В качестве другого примера рассмотрим возможности предложенных компанией IBM
"шаблонов для электронного бизнеса" [4.40].
Так как практически все приложения для электронного бизнеса сталкиваются с
необходимостью решения таких вопросов, как масштабируемость, надежность,
доступность, безопасность, то представляется, что использование относительно
небольшого числа стандартизованных решений может оказаться полезным. Эти решения
можно, в свою очередь, подразделить в зависимости от уровня абстракции –
соответственно на бизнес-шаблоны, архитектурные шаблоны, шаблоны уровня
приложений и т.п. При этом:

бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между
участниками процесса;

шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру
системы;

шаблоны уровня приложений (Application pattern) определяют различные варианты
взаимодействия между пользователями, приложениями и данными в системе, а также
соответствующий прототип уровня выполнения;

шаблоны уровня выполнения (Runtime pattern) описывают привязку компонент системы к
физическим узлам и определяют конкретные возможные продукты и их комбинации.
В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (см. табл.
7.1).
Кроме этого, выделяют также два служебных шаблона: соответственно интеграции
доступа и интеграции приложений.
Эти шаблоны предназначены для описания таких типовых областей, как:

интерактивная – взаимодействие пользователя с предприятием (например, продажа
товаров и услуг не по каталогам) – U2B;

программное взаимодействие между приложениями различных предприятий (B2B);

коллективная работа пользователей, включая электронную почту, обмен мгновенными
сообщениями, общие форумы и т.п. – U2U;

поиск информации в каталогах и базах данных, анализ данных, подписки – U2D;

взаимодействие между приложениями "в рамках предприятия", в том числе и не
обязательно с использованием web-интерфейсов;

централизованный доступ к системе на уровне выбранного интерфейса (портал) или на
более общем уровне (Web, речевая телефония, мобильные устройства и т.п.);

обеспечение безопасности.
Шаблоны могут быть использованы по отдельности или в комбинации при реализации
более сложных комплексных решений. Для идентификации классов этих решений
общеупотребительным стали аббревиатуры, использующие сходное звучание в
английском языке цифры 2 и отношения между двумя сторонами – системы типа B2B,
B2C и т.д. Например, традиционный электронный магазин (B2C) может включать
элементы прототипов U2D (User-to-Data – работа пользователя с каталогом товаров), U2B
(User-to-Business – оформление заказа), U2U (User-to-User – консультация у продавца или
обращение в службу поддержки).
Для реализации на практике единой архитектуры предприятия особое значение
приобретают шаблоны интеграции приложений. Прежде всего, стоит выделить две
категории, связанные с уровнем реализации взаимодействия, – интеграция на уровне
процессов и интеграция на уровне данных. Первая категория используется, если данные
из одного процесса непосредственно используются в другом процессе, связанном с
первым. Примером может служить использование средств обмена сообщениями для
гарантированной доставки данных из филиала банка в центральное отделение. Другая
категория связана с синхронизацией данных между несвязанными непосредственно между
собой процессами (например, загрузка агрегированных данных из системы биллинга
клиентов в систему управления маркетингом).
Собственно шаблоны строятся на основе набора предварительно определяемых общих
служб, которые могут входить в шаблон в необходимой комбинации. Примерами таких
общих служб могут являться:

преобразование данных (в частности, объединение/разделение, подстановки, округления,
перевод c языка на язык, использование XSL для преобразования XML->XML и т п);

маршрутизация
сообщений
(в
том
числе
оптимизация
маршрута,
мультипликация/демультипликация для доставки один-ко-многим, динамическая маршрутизация
в зависимости от содержания и т.п.);

гарантированная доставка;

репозиторий сообщений и метаданных;

управление транзакциями, в том числе распределенными;

планирование задач и активностей;

журналирование и аудит;

управление нагрузкой (в том числе поддержка кластеров, динамическая балансировка,
горячая замена и т.п.);

управление системами, в том числе обнаружение ошибок, мониторинг параметров;

служба каталогов;

безопасность, включая шифрование данных.
Аналогичные архитектурные шаблоны в терминологии Microsoft представляют собой
Решения уровня предприятия [4.41]. Они группируются в виде специальной модели в
соответствии с уровнем абстракции и архитектурным доменом (см. рис. 7.12).
Рис. 7.12. Категоризация архитектурных шаблонов Microsoft
При этом область шаблонов как бы "ограничена сверху" за счет включения в
рассмотрение только реляционных баз данных, многоуровневой (layered) архитектуры
объектно-ориентированных приложений и N-звенных систем. За счет такого ограничения
(в частности, из рассмотрения исключены OLAP-системы и монолитные или исполняемые
на одной платформе приложения) удается достичь существенной глубины проработки. В
состав набора входят шаблоны для представления информации через Web, поддержки
распределенных систем, предоставления сервисов, обеспечения производительности и
надежности систем.
28. ПП. Проектирование программной архитектуры.
Архитектура программного обеспечения (англ. software architecture) —
это структура программы или вычислительной системы, которая включает программные
компоненты, видимые снаружи свойства этих компонентов, а также отношения между
ними. Этот термин также относится к документированию архитектуры программного
обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации
между заинтересованными лицами (англ. stakeholders), позволяет зафиксировать принятые
на ранних этапах проектирования решения о высокоуровневом дизайне системы и
позволяет использовать компоненты этого дизайна и шаблоны повторно в других
проектах.
Языки описания архитектуры
Языки описания архитектуры (ADLS) используются для описания архитектуры
программного обеспечения. Различными организациями было разработано несколько
различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете
Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в
UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в
Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими
элементами для всех этих языков являются понятия компонента, коннектора и
конфигурации.
Примеры архитектурных стилей и моделей
Есть много распространенных способов разработки программных модулей и их связей, в
том числе:




















Blackboard
Клиент-серверная модель (client-server)
Архитектуры, построенные вокруг базы данных (database-centric architecture)
Распределенные вычисления (distributed computing)
Событийная архитектура (event-driven architecture)
Front end and back end
Неявные вызовы (implicit invocations)
Монолитное приложение (monolithic application)
Peer-to-peer
Пайпы и фильтры (pipes and filters)
Plugin
Representational State Transfer
Rule evaluation
Поиск-ориентированная архитектуры
Сервис-ориентированная архитектура
Shared nothing architecture
Software componentry
Space based architecture
Структурированная
Трех-уровневая
29. ПП. Модели описания программной архитектуры.
Модель Захмана
Основная идея заключается в том, чтобы обеспечить возможность последовательного
описания каждого отдельного аспекта системы в координации со всеми остальными. Для
любой достаточно сложной системы общее число связей, условий и правил обычно
превосходит возможности для одновременного рассмотрения. В то же время отдельное, в
отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к
неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть
столбцов, которая приведена на рисунке 1. Заметим, что в модели именно пять строк,
просто отображенная на рисунке шестая строка соответствует уже не уровню описания
архитектуры, а уровню работающей системы или предприятия в целом.
Рис. 1. Модель Захмана
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному
уровню управления предприятием, если речь идет об архитектуре предприятия или
использования информационной системы.
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко
описывают существующее окружение, планы и цели. Если проводить аналогию со
строительством, то эти уровни содержат сведения о местонахождении и назначении
постройки ("особняк" для отдыха в престижном коттеджном поселке в элитной зоне), а
также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего
дома. Следующий уровень "логической модели" уже является более конкретным, но все
равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен
показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка "Контекст"
соответствует уровню интересов высшего руководства и собрания акционеров. Второй
уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий
уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры,
отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают
детали, которые представляют интерес для ИТ-менеджеров, проектировщиков,
разработчиков.
На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же
категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем
абстракции и детализации. В содержание этих колонок входят:






используемые данные (что?)
процессы и функции (как?)
места выполнения этих процессов (где?)
организации и персоналии–участники (кто?)
управляющие события (когда?)
цели и ограничения, определяющие работу системы (зачем?)
Первая строка соответствует уровню планирования бизнеса в целом ( бизнес-модель ). На
этом уровне вводятся достаточно общие основные понятия, определяющие бизнес –
например, продукты и услуги, клиенты, расположение объектов бизнеса, а также
формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка
определяет контекст всех последующих строк.
Вторая строка ( концептуальная модель ) предназначена для определения в терминах
бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень ( логическая модель ) соответствует рассмотрению с точки зрения
Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах
информационных систем, включая различные типы данных, правила их преобразования и
обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется
привязка данных и операций над ними к выбранным технологиям реализации. Например,
здесь может быть определен выбор реляционной СУБД, или средств работы с
неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные
модели оборудования, топологию сети, производителя и версию СУБД, средства
разработки и собственно готовый программный код. Многие из работ на данном уровне
часто выполняются субподрядчиками.
Последний, шестой уровень описывает работающую систему. На этом уровне могут
быть введены, в том числе, такие объекты, как инструкции для работы c системой,
фактические базы данных, работа службы HelpDesk. Надо заметить, что в исходной
работе Захмана содержание этого уровня не детализируется. При развитии модели, как
будет показано ниже, отмечены возможности рассмотрения аспектов функционирования
работающей системы с точки зрения, например, конечного пользователя или
эксплуатирующих служб.
Рассмотрим теперь, как осуществляется последовательная детализация отдельных
аспектов описания системы, для чего обратим внимание на различные колонки таблицы.
Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен.
Так, первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе
данные. На верхнем уровне достаточным будет простое перечисление основных
объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в
семантическую модель высокого уровня и обычно описываются в виде диаграммы
"сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее
существенных бизнес-ограничений. На третьем уровне эта модель приводится к
нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень
представляет собой физическую модель данных в системе (в объектно-ориентированном
подходе – иерархию классов). Следующий уровень содержит описание модели на языке
управления данными для формирования таблиц, готовые библиотеки классов, табличные
пространства СУБД. Наконец, последний уровень может описывать фактические наборы
данных, в том числе такие характеристики, как журналы доступа, размеры реально
занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно
отметить определенное несовершенство данной модели при использовании объектноориентированного подхода – фактически модель предписывает раздельное рассмотрение
данных (свойств) и функций (методов) классов.
Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной
детализации описания того, как миссия предприятия реализуется на уровне отдельных
операций. В частности, на первом уровне достаточным будет простое перечисление
бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая
впоследствии детализируется в операции над данными и архитектуру приложений
(уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец,
исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в
рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение
компонент системы и сетевую организацию. На уровне планирования бизнеса здесь
достаточно определить расположение всех производственных объектов. На следующем
уровне эти объекты объединяются в модель со связями, характеризующими
взаимодействие между собой, – будь то обмен информацией или поставки товаров. На
третьем уровне системной архитектуры осуществляется привязка компонент
информационной системы к узлам сети. Четвертый уровень служит для определения
физической реализации в терминах аппаратных платформ, системного программного
обеспечения, а также средств промежуточного уровня (так называемое "middleware"),
используемых для интеграции различных компонент информационной системы между
собой. Типичным примером могут являться брокеры запросов или средства обмена
сообщениями. На пятом уровне определяются используемые протоколы и спецификации
каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На
уровне планирования бизнеса здесь представлен список подразделений предприятия и
выполняемые ими функции. На следующем уровне приводится полная организационная
диаграмма, а также могут быть определены общие требования к информационной
безопасности. Далее последовательно определяются участники бизнес-процессов и их
роли (в RUP используются диаграммы событий и описание вариантов использования),
требования к интерфейсам пользователя и правила доступа к отдельным объектам,
физическая их реализация на уровне кода или операторов определения доступа к
таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики
бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз,
начиная от календарного плана (уровень 1) и основных параметров, характеризующих
выполнение бизнес-процессов, – например, требование ко времени оформления сделки
(уровень 2). На третьем уровне определяются события, вызывающие изменение состояния
информационных объектов и инициацию операций над ними. На следующем уровне эти
события транслируются в программные вызовы (триггеры) или передаваемые сообщения.
Пятый уровень определяет физическую реализацию обработки таких событий. Наконец,
на 6-м уровне – фактическая история функционирования системы.
Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и
задает порядок перехода от задач бизнеса к требованиям и элементам информационных
систем. Исходной точкой является бизнес-стратегия, которая затем последовательно
транслируется в бизнес-план, затем в правила и ограничения для реализации бизнеспроцессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в
состав информационных систем и, в дальнейшем, в их физическую реализацию.
Такая модель описания в целом полезна для идентификации возможных ограничений. Эти
ограничения могут "распространяться" как от верхних уровней к нижним (например,
указание руководства компании о выборе тех или иных средств, продуктов или принципов
работы), так и в обратном направлении – например, возможности существующих
технологий беспроводной связи в значительной степени определяют спектр предлагаемых
услуг и организацию бизнес-процессов у провайдеров этих услуг.
Важным принципом предложенной модели является необходимость последовательного
перехода при углублении детализации рассмотрения. Пропуск отдельных элементов,
например, прямой переход от описания модели бизнес-процесса к физической реализации
системы требует "привлечения магии" и почти всегда приводит к неудаче. На практике
это часто случается при попытке разработки программы на основании только устного
описания требований пользователя.
Основными характеристиками данной модели Захмана являются следующие:






простота для понимания как техническими, так и нетехническими специалистами;
целостность в отношении предприятия, то есть каждая проблема может быть
соотнесена с предприятием в целом;
поддержка обсуждений сложных вопросов с использованием относительно
небольшого количества нетехнических понятий;
возможность применения для планирования, позволяющего лучше принимать
решения за счет того, что решение никогда не будет выноситься "в пустоте" (в
отрыве от остальных аспектов деятельности предприятия);
применимость для решения задач, то есть возможность работать с абстракциями и
сущностями, выделяя и изолируя отдельные параметры системы без потери
восприятия Предприятия как целого;
нейтральность, то есть независимость от каких-либо инструментов; благодаря
этому каждый инструмент и методология могут быть отображены на данную
модель и могут явно показать, что они делают и чего они не делают.
Созданная модель архитектуры служила простым, но мощным инструментом по
применению системного подхода для планирования работ по созданию и использованию
информационных систем и их стыковки. Захман писал, что схема архитектуры позволяет
концентрироваться на отдельных аспектах системы и в то же время не терять ощущения
общего контекста или "холистической" перспективы (то есть, взгляда на предприятие в
целом). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка
систем субподрядчиками, находящимися "вне контекста", уже около пятидесяти лет
составляет причину появления неинтегрируемых и не поддерживающих предприятие
должным образом систем, которые к тому же весьма дорого заменять.
Cтруктура и модель описания ИТ-архитектуры Gartner
Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и
усложняющихся уровней:




Среда бизнес-взаимодействия (Business Relationship Grid);
Бизнес-процессы и стили бизнес-процессов;
Шаблоны;
Технологические строительные блоки (кирпичики – bricks).
Рис. 8.3. Уровни модели архитектуры Gartner
При этом уровни ИТ-архитектуры соответствуют различным уровням выполнения
операций реального бизнеса так, как показано на рисунке 2:
Рис. 2 Архитектура ИТ в бизнес-контексте
В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнесруководителями и ИТ-специалистами и в какой-то степени соответствуют тому, что мы
называли бизнес-архитектурой, а нижние два уровня входят во внутреннюю компетенцию
ИТ-службы:

верхний уровень Среды бизнес-взаимодействия описывает новую модель
"виртуального" бизнеса, а также все, что связано с кооперацией предприятий и
бизнесом B2B. Этот уровень соответствует понятию "отраслевой нервной системы"
взаимодействующих предприятий. Он получил развитие в связи с
распространением Интернет как среды взаимодействия, и связан с понятиями



доступа, межорганизационного взаимодействия;
второй уровень Стили бизнес-процессов описывает, как организация выполняет
свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие
как обработка заказа, мониторинг производственных процессов, анализ
использования критически важных ресурсов, совместная работа с информацией;
следующий уровень Шаблоны описывает модели и алгоритмы, которые могут
широко использоваться для решения различных задач на предприятии. Отметим,
что шаблоны охватывают не только область программного обеспечения, но и
соответствующие сетевые и вычислительные ресурсы. Примерами шаблонов
является трехуровневая архитектура прикладных систем (интерфейс-логикаданные), использование "толстого" клиента в архитектуре клиент/сервер,
хранилища данных. Что касается приложений, то упор сделан на использовании
шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в
виде модульного набора различных типов сервисов. Это, в том числе, позволяет в
перспективе интегрировать приложения как web-сервисы.
нижний уровень Строительные блоки (Bricks) соответствует технологической
архитектуре и включает в себя операционные системы, серверы, базы данных, сами
данные и пр.
Этот подход является адекватным с точки зрения того, что он раскрывает руководству
механизм влияния решений в области ведения бизнеса на решения в области
использования ИТ на предприятии. Как предлагают первые верхние два уровня модели,
архитектура становится особенно важной по мере того, как модели ведения бизнеса
развиваются в сторону все "более виртуальных" структур ("расширенных организаций"),
успех которых будет в существенной степени зависеть от рациональной реализации
архитектуры.
Методика META Group
По мнению META Group, "архитектура является одновременно некоторым
структурированным описанием информационных технологий предприятия и его
информационных технологий (т.е. конечным результатом, включающим определенные
артефакты- стандарты, утверждения, касающиеся общего видения, архитектурные
документы), процессом создания и обновления артефактов архитектуры и группами
людей, вовлеченных в этот процесс". Соответственно этим представлениям методика
компании уделяет достаточно подробное внимание всем трем составляющим
архитектуры. При этом отличительной особенностью методики META является более
детальное и формализованное описание именно процесса разработки архитектуры и всех
его составляющих.
Объединяющим для всех доменов архитектуры META Group является процесс
формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух
документов: Видения общих требований (CRV – Common requirements Vision) и
Принципах концептуальной архитектуры (CA – Conceptual Architecture).
На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих
требований включает в себя:




анализ тенденций развития внешней для предприятия среды, включая
технологические тенденции;
бизнес-стратегии и основные движущие силы с точки зрения бизнеса;
требования к информационным системам со стороны бизнеса;
требования к технологической архитектуре, которая обеспечивает адекватные
возможности для информационных систем с точки зрения потребностей бизнеса.
Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически
связанный набор принципов, обеспечивающий общее руководство для развития
информационных систем предприятия и технологической инфраструктуры. На этом же
этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры.
Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым
состоянием архитектуры.
Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону
желаемого состояния архитектуры.
При этом данная методика предлагает формализованные шаблоны, обеспечивающие
разработку Видения общих требований и Концептуальной архитектуры.
30. ПП. Шаблоны программной архитектуры.
В разработке программного обеспечения, шаблон
проектирования или паттерн (англ. design pattern) — повторимая архитектурная
конструкция, представляющая собой решение проблемы проектирования в рамках
некоторого часто возникающего контекста.
Обычно шаблон не является законченным образцом, который может быть прямо
преобразован в код; это лишь пример решения задачи, который можно использовать в
различных ситуациях. Объектно-ориентированные шаблоны показывают
отношения и взаимодействия между классами или объектами, без определения того, какие
конечные классы или объекты приложения будут использоваться.
«Низкоуровневые» шаблоны, учитывающие специфику конкретного языка
программирования, называются идиомами. Это хорошие решения проектирования,
характерные для конкретного языка или программной платформы, и потому не
универсальные.
На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой
архитектуру всей программной системы.
Польза
Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого
класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает
дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут
ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация
терминологии, названий модулей и элементов проекта.
Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение,
пользоваться им снова и снова.
Типы шаблонов проектирования
Основные
Порождающие шаблоны (англ. Creational patterns) — шаблоны проектирования, которые
абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа
создания, композиции и представления объектов. Шаблон, порождающий классы,
использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий
объекты, делегирует инстанцирование другому объекту.
Использование
Эти шаблоны оказываются важны, когда система больше зависит от композиции объектов, чем от
наследования классов. Получается так, что основной упор делается не на жестком кодировании
фиксированного набора поведений, а на определении небольшого набора фундаментальных
поведений, с помощью композиции которых можно получать любое число более сложных. Таким
образом, для создания объектов с конкретным поведением требуется нечто большее, чем
простое инстанцирование класса.
Порождающие шаблоны инкапсулируют знания о конкретных классах, которые применяются в
системе. Они скрывают детали того, как эти классы создаются и стыкуются. Единственная
информация об объектах, известная системе, — это их интерфейсы, определенные с помощью
абстрактных классов. Следовательно, порождающие шаблоны обеспечивают большую гибкость
при решении вопроса о том, что создается, кто это создает, как и когда. Можно собрать систему из
«готовых» объектов с самой различной структурой и функциональностью статически (на этапе
компиляции) или динамически (во время выполнения).
Иногда допустимо выбирать между тем или иным порождающим шаблоном. Например, есть
случаи, когда с пользой для дела можно использовать как прототип, так и абстрактную фабрику. В
других ситуациях порождающие шаблоны дополняют друг друга. Так, применяя строитель, можно
использовать другие шаблоны для решения вопроса о том, какие компоненты нужно строить, а
прототип часто реализуется вместе с одиночкой. Порождающие шаблоны тесно связаны друг с
другом, их рассмотрение лучше проводить совместно, чтобы лучше были видны их сходства и
различия.
Перечень порождающих шаблонов

абстрактная фабрика (abstract factory); порождающий шаблон проектирования, позволяющий
изменять поведение системы, варьируя создаваемые объекты, при этом сохраняяинтерфейсы.
Он позволяет создавать целые группы взаимосвязанных объектов, которые, будучи





созданными одной фабрикой, реализуют общее поведение. Шаблон реализуется созданием
абстрактного класса Factory, который представляет собой интерфейс для создания
компонентов системы (например, для оконного интерфейса он может создавать окна и
кнопки). Затем пишутся наследующиеся от него классы, реализующие этот интерфейс.
строитель (builder); Отделяет конструирование сложного объекта от его представления, так что
в результате одного и того же процесса конструирования могут получаться разные
представления.
Фабричный метод (англ. Factory Method) — порождающий шаблон проектирования,
предоставляющий подклассам интерфейс для создания экземпляров некоторого класса. В
момент создания наследники могут определить, какой класс инстанциировать. Иными
словами, Фабрика делегирует создание объектов наследникам родительского класса. Это
позволяет использовать в коде программы не специфические классы, а манипулировать
абстрактными объектами на более высоком уровне. Также известен под названием
виртуальный конструктор.ленивая инициализация (lazy initialization);
Объектный пул (англ. object pool) — порождающий шаблон проектирования, набор
инициализированных и готовых к использованию объектов. Когда системе требуется объект,
он не создаётся, а берётся из пула. Когда объект больше не нужен, он не уничтожается, а
возвращается в пул.прототип (prototype);
одиночка (singleton)- Гарантирует, что у класса есть только один экземпляр, и предоставляет к
нему глобальную точку доступа. Существенно то, что можно пользоваться
именно экземпляром класса, так как при этом во многих случаях становится доступной более
широкая функциональность. Например, к описанным компонентам класса можно обращаться
через интерфейс, если такая возможность поддерживается языком.
прототип (prototype) - Задаёт виды создаваемых объектов с помощью экземпляра-прототипа и
создаёт новые объекты путём копирования этого прототипа.Проще говоря, это паттерн
создания объекта через клонирование другого объекта вместо создания через конструктор.
Структурные шаблоны — шаблоны проектирования, в которых рассматривается вопрос
о том, как из классов и объектов образуются более крупные структуры.
Использование
Структурные шаблоны уровня класса используют наследование для составления
композиций из интерфейсов и реализаций. Простой пример — использование
множественного наследования для объединения нескольких классов в один. В результате
получается класс, обладающий свойствами всех своих родителей. Особенно полезен этот
шаблон, когда нужно организовать совместную работу нескольких независимо
разработанных библиотек.
Шаблоны
 Адаптер, Adapter или Wrapper/Обёртка — структурный шаблон проектирования,
предназначенный для организации использования функций объекта, недоступного
для модификации, через специально созданный интерфейс.
 Bridge, Мост — шаблон проектирования, используемый в проектировании
программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они





могли изменяться независимо». Шаблон bridge (от англ. — мост)
использует инкапсуляцию, агрегирование и может использовать наследование для
того, чтобы разделить ответственность между классами.
Компоновщик (англ. Composite pattern) — шаблон проектирования, относится к
структурным паттернам, объединяет объекты в древовидную структуру для
представления иерархии от частного к целому. Компоновщик позволяет клиентам
обращаться к отдельным объектам и к группам объектов одинаково.
Декоратор, Decorator — структурный шаблон проектирования, предназначенный
для динамического подключения дополнительного поведения к объекту. Шаблон
Декоратор предоставляет гибкую альтернативу практике создания подклассов с
целью расширения функциональности.Известен также под менее
распространённым названием Обёртка (Wrapper)[источник?], которое во многом
раскрывает суть реализации шаблона.
Шаблон Facade (Фасад) — Шаблон проектирования, позволяющий скрыть
сложность системы путем сведения всех возможных внешних вызовов к
одному объекту, делегирующему их соответствующим объектам системы.
Приспособленец (англ. Flyweight) - это объект, представляющий себя как
уникальный экземпляр в разных местах программы, но по факту не являющийся
таковым.
Шаблон Proxy (определяет объект-заместитель англ. surrogate иначе заменитель англ. placeholder) — шаблон проектирования, который
предоставляет объект, который контролирует доступ к другому объекту,
перехватывая все вызовы (выполняет функцию контейнера).
Поведенческие шаблоны (англ. behavioral patterns) — шаблоны проектирования, определяющие
алгоритмы и способы реализации взаимодействия различных объектов и классов.
Использование
В поведенческих шаблонах уровня класса используется наследование, чтобы определить
поведение для различных классов. В поведенческих шаблонах уровня объекта
используется композиция. Некоторые из них описывают, как с помощью кооперации
несколько равноправных объектов работают над заданием, которое они не могут
выполнить по отдельности. Здесь важно то, как объекты получают информацию о
существовании друг друга. Объекты-коллеги могут хранить ссылки друг на друга, но это
усиливает степень связанности системы. При высокой связанности каждому объекту
пришлось бы иметь информацию обо всех остальных. Некоторые из шаблонов решают эту
проблему.
Примеры
Цепочка обязанностей — поведенческий шаблон проектирования, предназначенный для
организации в системе уровней ответственности.
Шаблон рекомендован для использования в условиях:

в разрабатываемой системе имеется группа объектов, которые могут обрабатывать
сообщения определенного типа;
 все сообщения должны быть обработаны хотя бы одним объектом системы;
 сообщения в системе обрабатываются по схеме «обработай сам либо перешли другому»,
то есть одни сообщения обрабатываются на том уровне, где они получены, а другие
пересылаются объектам иного уровня.
Команда — шаблон проектирования, используемый при объектно-ориентированном
программировании, представляющий действие. Объект команды заключает в себе само действие
и его параметры.Создание структуры, в которой класс-отправитель и класс-получатель не зависят
друг от друга напрямую. Организация обратного вызова к классу, который включает в себя классотправитель.
Шаблон Интерпретатор (англ. Interpreter) — поведенческий шаблон проектирования, решающий
часто встречающуюся, но подверженную изменениям, задачу. Также известен как Little (Small)
Language
Шаблон Посетитель (Visitor) — поведенческий Шаблон проектирования.
Описывает операцию, которая выполняется над объектами других классов. При
изменении Visitor нет необходимости изменять обслуживаемые классы.
Хранитель (также известный как Memento, Token, Лексема) — поведенческий шаблон
проектирования.
Позволяет не нарушая инкапсуляцию зафиксировать и сохранить внутреннее состояния
объекта так, чтобы позднее восстановить его в этом состоянии.
Шаблон Посетитель (Visitor) — поведенческий Шаблон проектирования.
Описывает операцию, которая выполняется над объектами других классов. При
изменении Visitor нет необходимости изменять обслуживаемые классы.
Частные
Шаблоны параллельного программирования (Concurrency)
Используются для более эффективного написания многопоточных программ, и
предоставляет готовые решения проблем синхронизации.
Double checked locking (блокировка с двойной проверкой) — шаблон проектирования,
применяющийся в параллельном программировании. Он предназначен для уменьшения
накладных расходов, связанных с получением блокировки. Сначала проверяется условие
блокировки без какой-либо синхронизации; поток делает попытку получить блокировку
только если результат проверки говорит о том, что ни один другой поток не владеет
блокировкой.
На некоторых языках и/или на некоторых машинах невозможно безопасно реализовать
данный шаблон. Поэтому иногда его называют анти-паттерном.
Обычно он используется для уменьшения накладных расходов при реализации ленивой
инициализации в многопоточных программах, например в составе шаблона
проектирования Одиночка. При ленивой инициализации переменной, инициализация
откладывается до тех пор, пока значение переменной действительно понадобится при
вычислениях.
Планировщик (англ. Scheduler) — шаблон проектирования, обеспечивающий механизм
реализации политики планирования, но при этом не зависящий ни от одной конкретной
политики. Управляет порядком, в соответствии с которым потокам предстоит выполнить
последовательный код, используя для этого объект, который явным образом задаёт
последовательность ожидающих потоков.
Однопоточное выполнение (англ. Single Threaded Execution) — известный также под
названием англ. Critical Section. Шаблон проектирования препятствующий конкурентному
вызову метода, тем самым запрещая параллельное выполнение этого метода.
31. ПП. Проектирование инфраструктуры.
ИТ-инфраструктура — это комплекс взаимосвязанных систем передачи данных,
аппаратных и программных информационных систем, служб и набор средств управления,
настольными и переносными компьютерами, серверами, системами хранения данных,
сетевыми устройствами, операционными системами и приложениями, удовлетворяющих
потребностям бизнеса, действующих в режиме повышенной готовности,
отказоустойчивости и безопасности, и имеющие потенциал для масштабирования, не
снижающего эффективность управления информационной системой.
32. ПП. Проектирование интерфейсов.
Процесс проектирования пользовательских интерфейсов
- Анализ деятельности пользователя
- Создание концепции пользовательского интерфейса
- Прототипирование
- Тестирование с пользователями
Основные понятия
Дизайн-проектирование – это проектирование рентабельных продуктов, услуг и сред,
соответствующих практическим, физическим и эмоциональным потребностям широкого круга
людей (Kim Goodwin)
Usability – «степень, с которой продукт может быть использован определёнными пользователями
при определённом контексте использования для достижения определённых целей с должной
эффективностью , продуктивностью и удовлетворённостью ». ( ISO 9241-11 ) При этом
относительная важность всех трех аспектов определяется контекстом.
Интерфейс пользователя – система правил и средств, регламентирующая и обеспечивающая
взаимодействие программы с пользователем/
Критерии дружественности интерфейса
- Эффективность
- Продуктивность
- Удовлетворенность
- Безопасность
Подходы к проектированию
- Инженерно-технический подход
- Когнитивный подход
- Ориентированный на пользователя (User Centered)
- Деятельностный (Activity-Centered)
- Экспертный (Gen i us)
- Целе-ориентированный (Goal Centered Design) ИТ МГППУ 2009 г.
Пограничные предметные области
- Эргономика
- Человеко-компьютерное взаимодействие
- Психология труда
- Инженерная психология
- Информационная архитектура
- Дизайн Системный анализ
- Психология восприятия
- Экспериментальная психология и т.д.
История развития инженерной психологии
Начало ХХ в. – впервые начинает изучаться трудовая деятельность человека и ее физиологические
основы американским инженером Ф. Тейлором и его учениками. Немецкий психолог Штерн
предлагает термин «Психотехника», а в 1908 немецкий психолог Мюнстерберг оформляет
психотехнику как науку, определяя её содержание и методы 20-е гг. Первые исследования
инженерно-психологического типа в России, проводились в рамках психологии труда и
психотехники 40-х гг. Возникает наука Инженерная психология и первоначально развивается как
направление традиционной психологии труда руками психологов США и Англии. 50 гг.
Определяются в общих чертах закономерности приёма и переработки информации человеком
(образование в Англии Эргономического научно-исследовательского общества) 57 г. Инженерная
психология определена как самостоятельная область исследований в СССР, создана первая
лаборатория индустриальной психологии. 60-е годы В СССР проводятся секции и симпозиумы по
инженерной психологии и психологии труда, и конференции по инженерной психологии.
Возникают лаборатории. 60-х гг. — вырабатываются общие принципы организации
взаимодействия человека и ЭВМ. Эти рекомендации нашли практическое применение при
автоматизации процессов управления на производстве, в авиации, космонавтике и т. д. В конце
60-х гг. западные ученые стали заниматься синтезом, проектированием человеческой
деятельности в больших системах, а так же вносить определённый вклад в разработку
мероприятий по повышению эффективности их функционирования. В 70 е и 80-е гг. В.П.Зинченко
совместно с В.М.Муниповым и со специалистами из научно-исследовательских организаций
Министерства обороны СССР и другими осуществлял большую координационную работу по
развитию эргономики в СССР и странах-членах СЭВ
Процесс создания программного продукта
- Анализ бизнес-требований, выявление заинтересованных лиц и их целей
- Проектирование программного продукта и его интерфейса
- Программная реализация продукта на основе проекта , графический дизайн, наполнение
контентом
- Тестирование и пилотное внедрение
- Внедрение в эксплуатацию
Процесс проектирования интерфейса
- Анализ бизнес-процессов и деятельности пользователей
- Формализация информации в виде диаграмм бизнес-процессов и сценариев
- Выработка концепции
- Прототипирование интерфейса
- Уточнение прототипов
- Тестирование с пользователями
- Получение обратной связи от пользователей и ее анализ
Стандарты и руководства
- IBM (представление интерфейса, согласованность, состав компонент, принципы проектирования)
- ISO 14915 регламентирует мультимедийный интерфейс
- ISO 9241 требования по эргономике к офисной работе с визуальными дисплейными
терминалами
- ISO 13407 описание процесса проектирования, ориентированного на пользователя
- 2007 Microsoft Office System User Interface Design Guidelines
33. Процессы верификации. Понятия качества. Оценка качества. Тестирование.
Процессом жизненного цикла ПО называется группа видов деятельности,
выполняемых для решения определенного набора связанных задач по разработке или
сопровождению ПО. На сегодняшний день нет четко определенного общего списка
процессов, который не вызывал бы возражений у тех или иных исследователей и
практиков. Международные стандарты ISO 12207 [15], IEEE 1074 [28], ISO 15288 [29],
ISO 15504 [30] используют несколько отличающиеся системы процессов.
качества (quality assurance), собственно верификация, валидация, совместные
экспертизы (joint review) и аудит (audit). Тестирование целиком отнесено к
валидации. Кроме того, выделен процесс разрешения проблем (problem
resolution), для которого верификация и валидация поставляют входные данные
(те самые проблемы).
— группу
деятельностей по оценке (evaluation), которая включает экспертизы (review),
аудиты, прослеживание требований и тестирование. Еще несколько видов
деятельности, которые можно отнести к верификации и валидации, разбросаны
по другим процессам — сбор и анализ метрик, анализ осуществимости,
определение потребностей в улучшении ПО, валидация программы обучения.
качеством, оценивание,
верификацию и валидацию.
аудиты (один процесс), управление качеством, обеспечение качества и
экспертизы (review). Тестирование считается частью других процессов
Тестирование (testing) является методом верификации, в рамках которого
результаты работы тестируемой системы или компонента в ситуациях из выделенного
конечного набора проверяются на соответствие проектным решениям, требованиям,
общим задачам проекта, в рамках которого эта система разрабатывается или
сопровождается. Ситуации, в которых выполняется тестирование, называют
тестовыми ситуациями (test situations, test purposes), а процедуры, описывающие
процесс создания этих ситуаций и проверки, которые необходимо выполнить над
полученными результатами, — тестами.