Разработка новой системы или настройка существующей системы.
В случае разработки собственной системы последующие этапы являются традиционными: по спецификациям технического проекта осуществляется программирование модулей, их тестирование и отладка.
Настройка существующей системы осуществляется по следующим этапам:
Наполнение системы фактическими данными;
Построение процедур их обработки;
Интеграция процедур внутри автоматизированных рабочих мест;
Интеграция автоматизированных рабочих мест в систему.
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических операций проектирования ;
критериев и правил, используемых для оценки результатов выполнения технологических операций;
нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Понятие и примеры архитектуры ИС.
Архитектура системы: по ANSI/IEEE Std 1471-2000: «фундаментальная организационная структура системы, воплощенная в ее компонентах, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией". "Архитектура ИС - это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой". "Архитектура ИС - это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения"
Типовые варианты архитектуры: модель файлового сервера (File Server - FS), модель доступа к удаленным данным (Remote Data Access - RDA), модель севера базы данных (DataBase Server - DBS), модель сервера приложений (Application Server - AS)
ФС: на клиентской машине расположен компонент представления и прикладной компонент, на сервере компонент доступа к ресурсам.
Недостатки ФС:
высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипулирования данными ("данные - это файлы"), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы), т.е. управление параллельной работой, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД; проблема «толстого клиента» - Windows, интерфейс, коды приложения и полная копия СУБД могут перегрузить даже мощный компьютер
RDA
На клиентской машине – компонент представления и прикладной компонент, на сервере только компонент доступа к ресурсам.
Плюсы RDA
Основное достоинство RDA-модели - унификация интерфейса "клиент-сервер" в виде языка SQL; Перенос компонента представления и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД, сводя к минимуму общее число процессов операционной системы; Уменьшается загрузка сети, так как по ней передаются от клиента к серверу не запросы на ввод-вывод (как с ФС), а запросы на языке SQL, их объем существенно меньше.
Минусы RDA
Взаимодействие клиента и сервера посредством SQL-запросов по-прежнему значительно загружает сеть; Удовлетворительное администрирование приложений в RDA-модели практически невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные)
DBS
На клиентской машине – компонент представления, а на сервере – прикладной компонент (SQL) и компонент доступа к ресурсам.
Плюсы DBS:
Возможность централизованного администрирования прикладных функций; Снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур); Возможность разделения процедуры между несколькими приложениями; Экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры
Минусы DBS:
Ограниченность средств, используемых для написания хранимых процедур. Сфера их использования ограничена конкретной СУБД, в большинстве СУБД отсутствуют возможности отладки и тестирования разработанных хранимых процедур.
Сервер приложений
Представляет собой процесс, выполняющийся на компьютере клиента, отвеч.за интерфейс с пользователем. Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и наз-ся сервером приложения. Доступ к информационным ресурсам осуществляет менеджер ресурсов (например SQL-сервер), из прикладных компонентов доступны БД, почтовые службы, очереди и т.д. Модель AS, реализованная на компьютере, где функционирует менеджер ресурсов, избавляет от необходимости направления SQL-запросов по сети, что повышает производительность системы.
Понятие программной инженирии. Её основные концепции, структура и стандарты. Содержание программной инженирии.
Программная инженерия есть применение определенного систематического измеримого подхода при разработке, эксплуатации и поддержке программного обеспечения. Необходимость в программной инженерии как в специальной области знаний была осознана мировым сообществом в конце 60-х годов прошлого века, более чем на 20 лет позже рождения самого программирования, если считать таковым знаменитый отчет фон Неймана "First Draft of a Report on the EDVAC", обнародованный им в 1945 году. Рождением программной инженерии является 1968 год – конференция NATO Software Engineering, г. Гармиш (ФРГ), которая целиком была посвящена рассмотрению этих вопросов. В сферу программной инженерии попадают все вопросы и темы, связанные с организацией и улучшением процесса разработки ПО, управлением коллективом разработчиков, разработкой и внедрением программных средств поддержки жизненного цикла разработки ПО. Программная инженерия использует достижения информатики, тесно связана с системотехникой, часто предваряется бизнес-реинжинирингом. Немного подробнее об этом контексте программной инженерии.
Информатика (computer science) – это свод теоретических наук, основанных на математике и посвященных формальным основам вычислимости. Сюда относят математическую логику, теорию грамматик, методы построения компиляторов, математические формальные методы, используемые в верификации и модельном тестировании и т.д. Трудно строго отделить программную инженерию от информатики, но в целом направленность этих дисциплин различна. Программная инженерия нацелена на решение проблем производства, информатика – на разработку формальных, математизированных подходов к программированию.
Системотехника (system engineering) объединяет различные инженерные дисциплины по разработке всевозможных искусственных систем – энергоустановок, телекоммуникационных систем, встроенных систем реального времени и т.д. Очень часто ПО оказывается частью таких систем, выполняя задачу управления соответствующего оборудования. Такие системы называются программно-аппаратными, и участвуя в их создании, программисты вынуждены глубоко разбираться в особенностях соответствующей аппаратуры.
Бизнес-реинжиниринг (business reengineering) – в широком смысле обозначает модернизацию бизнеса в определенной компании, внедрение новых практик, поддерживаемых соответствующими, новыми информационными системами. При этом акцент может быть как на внутреннем переустройстве компании так и на разработке нового клиентского сервиса (как правило, эти вопросы взаимосвязаны). Бизнес-реинжиниринг часто предваряет разработку и внедрение информационных систем на предприятии, так как требуется сначала навести определенный порядок в делопроизводстве, а лишь потом закрепить его информационной системой.
Согласно SWEBOK 2004, программная инженерия включает в себя 10 основных и 7 дополнительных областей знаний, на которых базируются процессы разработки ПО. К основным областям знаний относятся следующие области:
Software requirements — программные требования.
Software design — дизайн (архитектура).
Software construction — конструирование программного обеспечения.
Software testing — тестирование.
Software maintenance — эксплуатация (поддержка) программного обеспечения.
Software configuration management — конфигурационное управление.
Software engineering management — управление в программной инженерии.
Software engineering process — процессы программной инженерии.
Software engineering tools and methods — инструменты и методы.
Software quality — качество программного обеспечения.
Дополнительные области знаний включают в себя:
Computer engineering — разработка компьютеров.
Computer science — информатика.
Management — общий менеджмент.
Mathematics — математика.
Project management — управление проектами.
Quality management — управление качеством.
Systems engineering — системное проектирование.
Назначение, содержание и соотношение SWEBOK и PMBOK.
SWEBOK (Software Engineering Body of Knowledge) — документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society. Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).
Документ является одним из трёх документов, созданных совместными усилиями IEEE-CS и ACM, призванных обеспечить следующее:
определить необходимый набор знаний и рекомендуемые практики;
определить этические и профессиональные стандарты;
определить учебную программу для студентов, аспирантов и продолжающих обучение.
Эта книга представляет собой первый компонент необходимый набор знаний и рекомендуемые практики.
Документ делит знания по программной инженерии на 10 областей знаний (Knowledge Areas):
Software Requirements — требования к ПО.
Software Design — проектирование ПО.
Software Construction — конструирование ПО.
Software Testing — тестирование ПО.
Software Maintenance — сопровождение ПО.
Software Configuration Management — управление конфигурацией.
Software Engineering Management — управление IT проектом.
Software Engineering Process — процесс программной инженерии.
Software Engineering Tools and Methods — методы и инструменты.
Software Quality — качество ПО.
Свод знаний по управлению проектами представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK (Project Management Body of Knowledge) фиксирует части Свода знаний по управлению проектами, которая обычно считается хорошей практикой. PMI использует этот документ в качестве основного справочного материала для своих программ по профессиональному развитию. Является Американским национальным стандартом.
В настоящем стандарте описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат. Эти процессы разделены на пять групп, называемых «группы процессов управления проектом».
PMBOK выделяет 44 основных процесса, которые происходят при управлении проектами. Эти процессы с одной стороны распределяются по 5ти группам процессов (например группа процессов планирования или группа процессов исполнения) а с другой, каждый из них относится ровно к одной из 9ти, определяемых PMBOK областей знаний. (например — управление сроками или управление качеством).
Каждый из процессов подробно описан. Описания процессов и составляют основной объем 400 страничного мануала. Описания хорошо структурированы. В частности, каждое из описаний процессов обязательно включает 3 основные части:
- Входы
- Выходы
- Инструменты и методы
Входами процесса являются либо артефакты, полученные при выполнении другого процесса, либо некоторые знания из внешней по отношению к проекту среды.
Выходами процесса являются некоторые артефакты. Это или документы, или части создаваемого продукта ну или сам продукт.
Надо заметить, что говоря об артефактах-документах, PMBOK довольно четко описывает их цель и смысл, а также говорит что должно в них входить, однако PMBOK НЕ задает шаблонов для своих документов, оставляя это на усмотрение менеджеров проектов, либо разработчиков методологий, основанных на PMBOK.
Наиболее ценным содержимым PMBOK является часть «инструменты и методы» в которой собраны все известные авторам практики, относящиеся к данному процессу. Стремление включить именно ВСЕ практики иногда приводит к появлению в этой части описания процесса забавных по своей банальности утверждений. Однако, возможно, такое восприятие является следствием личного опыта, и, возможно, для кого-то столь же банальными покажутся совсем другие части. При этом, многие из предлагаемых практик оказались лично для меня новыми и интересными.
Понятие жизненного цикла ПО. Модели жизненного цикла и их сравнительный анализ.
Жизненным циклом программного обеспечения называют период от момента появления идеи
создания некоторого программного обеспечения до момента завершения его поддержки фирмой-
разработчиком или фирмой, выполнявшей сопровождение.
Каскадная модель (Постановка задачи – Анализ – Проектирование – Реализация – Модификация). Первоначально (1970-1985 годы) была предложена и использовалась
каскадная схема разработки программного обеспечения , которая предполагала, что
переход на следующую стадию осуществляется после того, как полностью будут завершены
проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.
Достоинствами такой схемы являются:
• получение в конце каждой стадии законченного набора проектной документации,
отвечающего требованиям полноты и согласованности;
• простота планирования процесса разработки.
Именно такую схему и используют обычно при блочно-иерархическом подходе к разработке
сложных технических объектов, обеспечивая очень высокие параметры эффективности
разработки. Однако данная схема оказалась применимой только к созданию систем, для которых в
самом начале разработки удавалось точно и полно сформулировать все требования. Это умень-
шало вероятность возникновения в процессе разработки проблем, связанных с принятием
неудачного решения на предыдущих стадиях. На практике такие разработки встречается крайне
редко.
Модель с промежуточным контролем. Схема, поддерживающая итерационный характер
процесса разработки, была названа схемой с промежуточным контролем . Контроль,
который выполняется по данной схеме после завершения каждого этапа, позволяет при
необходимости вернуться на любой уровень и внести необходимые изменения.
Основная опасность использования такой схемы связана с тем, что разработка никогда не
будет завершена, постоянно находясь в состоянии уточнения и усовершенствования.
Спиральная модель. Для преодоления перечисленных проблем в середине 80-х годов XX в,
была предложена спиральная схема. В соответствии с данной схемой программное
обеспечение создается не сразу, а итерационно с использованием метода прототипирования,
базирующегося на создании прототипов. Именно появление прототипирования привело к тому,
что процесс модификации программного обеспечения перестал восприниматься, как
«необходимое зло», а стал восприниматься как отдельный важный процесс.
Прототипом называют действующий программный продукт, реализующий отдельные
функции и внешние интерфейсы разрабатываемого программного обеспечения.
На первой итерации, как правило, специфицируют, проектируют, реализуют и тестируют
интерфейс пользователя. На второй - добавляют некоторый ограниченный набор функций. На
последующих этапах этот набор расширяют, наращивая возможности данного продукта.
Основным достоинством данной схемы является то, что, начиная с некоторой итерации, на
которой обеспечена определенная функциональная полнота, продукт можно предоставлять
пользователю, что позволяет:
• сократить время до появления первых версий программного продукта;
• заинтересовать большое количество пользователей, обеспечивая быстрое продвижение
следующих версий продукта на рынке;
• ускорить формирование и уточнение спецификаций за счет появления практики
использования продукта;
• уменьшить вероятность морального устаревания системы за время разработки.
Классификация и характеристика процессов создания ПО. Примерная структура стоимости проекта ИС.
Процесс жизненного цикла определяется как совокупность взаимосвязанных действий,
преобразующих некоторые входные данные в выходные.
Основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение.
Организационные процессы: управление, усовершенствование, создание инфраструктуры, обучение.
Вспомогательные процессы: документирование, управление конфигурацией, обеспечение качеством, верификация, аттестация, совместная оценка, аудит, разрешение проблем.
Стадии разработки ПО по ГОСТ 19.102-77:
Постановка задачи. В процессе постановки задачи четко формулируют назначение
программного обеспечения и определяют основные требования к нему. Каждое требование
представляет собой описание необходимого или желаемого свойства программного обеспечения.
Различают функциональные требования, определяющие функции, которые должно выполнять
разрабатываемое программное обеспечение, и эксплуатационные требования, определяющие
особенности его функционирования.
Анализ требований и определение спецификаций.
Для получения спецификаций выполняют анализ требований технического задания,
формулируют содержательную постановку задачи, выбирают математический аппарат
формализации, строят модель предметной области, определяют подзадачи и выбирают или
разрабатывают методы их решения. Часть спецификаций может быть определена в процессе
предпроектных исследований и, соответственно, зафиксирована в техническом задании.
На этом этапе также целесообразно сформировать тесты для поиска ошибок в проектируемом
программном обеспечении, обязательно указав ожидаемые результаты.
Проектирование. Основной задачей этого этапа является определение подробных
спецификаций разрабатываемого программного обеспечения. Процесс проектирования сложного
программного обеспечения обычно включает:
• проектирование общей структуры - определение основных компонентов и их взаимосвязей;
• декомпозицию компонентов и построение структурных иерархий в соответствии с
рекомендациями блочно-иерархического подхода;
• проектирование компонентов.
Реализация. Реализация представляет собой процесс поэтапного написания кодов программы
на выбранном языке программирования (кодирование), их тестирование и отладку.
Сопровождение. Сопровождение - это процесс создания и внедрения новых версий
программного продукта.
Модели ЖЦ ПО MSF, RUP и XP.
Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение.
Фаза начала проекта (Inception). Определяются основные цели проекта, бюджет проекта, основные средства его выполнения — технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта.
Фаза проработки (Elaboration). Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.
Фаза построения (Construction). Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.
Фаза передачи (Transition). Цель фазы — сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.
Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Основными фазами модели MSF являются:
Создание общей картины приложения (Envisioning).На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: "Организован костяк команды" и "Создана общая картина решения".
Планирование (Panning). Включает планирование и проектирование продукта. На основе анализа требований разрабатывается проект и основные архитектурные решения, функциональные спецификации системы, планы и календарные графики, среды разработки, тестирования и пилотной эксплуатации. Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес-требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. И уже на стадии физического проектирования задача рассматривается с точки зрения программистов, уточняются используемые технологии и интерфейсы.
Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа - "Окончательное утверждение области действия проекта". Продукт готов к внешнему тестированию и стабилизации. Кроме того, заказчики, пользователи, сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.
Стабилизация (Stabilizing). Подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), проверяется сценарий развертывания продукта. Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы.
Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.
Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
Основными фазами модели можно считать:
«Вброс» архитектуры – начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.
Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории использования являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.
Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта.
Разработка проводится в соответствии с планом и включает только те функции, которые были отобраны на этапе планирования.
Тестирование проводится с участием заказчика, который участвует в составлении тестов.
Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования.
По завершению цикла делается переход на следующую итерацию разработки
Понятие канонического проектирования ИС. Состав и содержание технического задания на разработку ИС.
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.
Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:
Стадия 1. Формирование требований к ИС.
обследование объекта и обоснование необходимости создания ИС;
формирование требований пользователей к ИС;
оформление отчета о выполненной работе и тактико- технического задания на разработку.
Стадия 2. Разработка концепции ИС.
изучение объекта автоматизации;
проведение необходимых научно-исследовательских работ;
разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
разработка предварительных проектных решений по системе и ее частям;
разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект.
разработка проектных решений по системе и ее частям;
разработка документации на ИС и ее части;
разработка и оформление документации на поставку комплектующих изделий;
разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
разработка рабочей документации на ИС и ее части;
разработка и адаптация программ.
Стадия 7. Ввод в действие.
подготовка объекта автоматизации;
подготовка персонала;
комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний ;
проведение опытной эксплуатации ;
проведение приемочных испытаний.
Стадия 8. Сопровождение ИС.
выполнение работ в соответствии с гарантийными обязательствами;
послегарантийное обслуживание.
Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. Состав и содержание технического задания:
Общие сведения
полное наименование системы и ее условное обозначение
шифр темы или шифр (номер) договора;
наименование предприятий разработчика и заказчика системы, их реквизиты
перечень документов, на основании которых создается ИС
плановые сроки начала и окончания работ
сведения об источниках и порядке финансирования работ
порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств
2. Назначение и цели создания (развития) системы
вид автоматизируемой деятельности
перечень объектов, на которых предполагается использование системы
наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС
3. Характеристика объектов автоматизации
краткие сведения об объекте автоматизации
сведения об условиях эксплуатации и характеристиках окружающей среды
4. Требования к системе
Требования к системе в целом:
требования к структуре и функционированию системы
требования к персоналу
показатели назначения
требования к надежности, безопасности, эргономике, транспортабельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации
Требования к функциям (по подсистемам) :
перечень подлежащих автоматизации задач
временной регламент реализации каждой функции
требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точности, достоверности выдачи результатов
перечень и критерии отказов
Требования к видам обеспечения:
математическому (мат. модели, методы, типовые и разрабатываемые алгоритмы)
информационному (организация данных, обмен данными между компонентами системы, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов)
лингвистическому (языки программирования, языки взаимодействия пользователей с системой, системы кодирования, языки ввода- вывода)
программному
техническому
метрологическому
организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала)
методическому (состав нормативно-технической документации)
5. Состав и содержание работ по созданию системы
перечень стадий и этапов работ, сроки исполнения
состав организаций — исполнителей работ
вид и порядок экспертизы технической документации
программа обеспечения надежности, программа метрологического обеспечения
6. Порядок контроля и приемки системы
виды, состав, объем и методы испытаний системы
общие требования к приемке работ по стадиям
статус приемной комиссии
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
преобразование входной информации к машиночитаемому виду
изменения в объекте автоматизации
сроки и порядок комплектования и обучения персонала
8 Требования к документированию
перечень подлежащих разработке документов
перечень документов на машинных носителях
9 Источники разработки
документы и информационные материалы, на основании которых разрабатывается ТЗ и система
Функционально- и объектно-ориентированные методологии описания предметной области. Особенности, составляющие и области применения.
Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные).
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.
Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.
С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.
В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции ( операции, действия, работы), которые на диаграммах связываются между собой потоками объектов. Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления. При функциональном подходе объектные модели данных в виде ER-диаграмм "объект — свойство — связь" разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.
Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться.
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые могут обращаться к атрибутам этого класса.
Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов). В случае наследования функций можно абстрагироваться от конкретной реализации процедур ( абстрактные типы данных ), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам ( полиморфизм ) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше.
При объектно-ориентированном подходе изменяется и принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы.
Для объектно-ориентированного подхода разработаны графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям.
При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели предметной области.
Моделирование бизнес-процессов инструментальными средствами. Возможности, составные части и особенности применения BPWin.
Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.
BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer.
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель.
Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Диаграмма деревьев узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами.Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели — Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако составляющей стандарта IDEF0.
BPwin имеет мощный инструмент генерации отчетов. Отчеты по модели вызываются из пункта меню Report. Всего имеется семь типов отчетов:
Model Report. Включает информацию о контексте модели — имя модели, точку зрения, область, цель, имя автора, дату создания и др.
Diagram Report. Отчет по конкретной диаграмме. Включает список объектов ( работ, стрелок, хранилищ данных, внешних ссылок и т. д.).
Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели ( работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.
Activity Cost Report. Отчет о результатах стоимостного анализа. Будет рассмотрен ниже.
Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелкии информацию о разветвлении и слиянии стрелок.
Data Usage Report. Отчет о результатах связывания модели процессов и модели данных.
Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.
Информационное обеспечение ИС: понятие, назначение, составные части и их краткая характеристика.
Информационное обеспечение ИС является средством для решения следующих задач:
однозначного и экономичного представления информации в системе (на основе кодирования объектов);
организации процедур анализа и обработки информации с учетом характера связей между объектами (на основе классификацииобъектов);
организации взаимодействия пользователей с системой (на основе экранных форм ввода-вывода данных);
обеспечения эффективного использования информации в контуре управления деятельностью объекта автоматизации (на основе унифицированной системы документации ).
Информационное обеспечение ИС включает два комплекса: внемашинное информационное обеспечение ( классификаторы технико-экономической информации, документы, методические инструктивные материалы) и внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структурыинформационной базы: входных, выходных файлов, базы данных).
Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации информационной базы.
Классификатор — это документ, с помощью которого осуществляется формализованное описание информации в ИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения [21].
По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальныеклассификаторы.
Международные классификаторы входят в состав Системы международных экономических стандартов (СМЭС) и обязательны для передачи информации между организациями разных стран мирового сообщества.
Общегосударственные (общесистемные) классификаторы, обязательны для организации процессов передачи и обработки информации между экономическими системами государственного уровня внутри страны.
Отраслевые классификаторы используют для выполнения процедур обработки информации и передачи ее между организациями внутри отрасли.
Локальные классификаторы используют в пределах отдельных предприятий.
Для полной формализации информации недостаточно простой классификации, поэтому проводят следующую процедуру — кодирование. Кодирование — это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Кодирование реализует перевод информации, выраженной одной системой знаков, в другую систему, то есть перевод записи на естественном языке в запись с помощью кодов. Система кодирования — это совокупность правил обозначения объектов и группировок с использованием кодов. Код — это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Код базируется на определенном алфавите (некоторое множество знаков). Число знаков этого множества называется основанием кода. Различают следующие типы алфавитов: цифровой, буквенный и смешанный.
Основной компонентой внемашинного информационного обеспечения ИС является система документации, применяемая в процессе управления экономическим объектом. Под документом понимается определенная совокупность сведений, используемая при решении технико-экономических задач, расположенная на материальном носителе в соответствии с установленной формой.
Система документации — это совокупность взаимосвязанных форм документов, регулярно используемых в процессе управления экономическим объектом. Отличительной особенностью системы экономической документации является большое разнообразие видов документов.
Существующие системы документации, характерные для неавтоматизированных ИС, отличаются большим количеством разных типов форм документов, большим объемом потоков документов и их запутанностью, дублированием информации в документах и работ по их обработке и, как следствие, низкой достоверностью получаемых результатов. Для того чтобы упростить систему документации, используют следующие два подхода:
проведение унификации и стандартизации документов;
введение безбумажной технологии, основанной на использовании электронных документов и новых информационных технологий их обработки.
Унификация документов выполняется путем введения единых форм документов. Таким образом, вводится единообразие в наименования показателей, единиц измерения и терминов, в результате чего получается унифицированная система документации.
Унифицированная система документации (УСД) — это рационально организованный комплекс взаимосвязанных документов, который отвечает единым правилам и требованиям и содержит информацию, необходимую для управления некоторым экономическим объектом. По уровням управления, они делятся на межотраслевые системы документации, отраслевые и системы документации локального уровня, т. е. обязательные для использования в рамках предприятий или организаций.
Внутримашинное информационное обеспечение включает макеты (экранные формы) для ввода первичных данных в ЭВМ или вывода результатной информации, и структуры информационной базы: входных, выходных файлов, базы данных.
Под электронными формами документов понимается не изображение бумажного документа, а изначально электронная (безбумажная) технология работы; она предполагает появление бумажной формы только в качестве твердой копии документа.
Электронная форма документа (ЭД) — это страница с пустыми полями, оставленными для заполнения пользователем. Формы могут допускать различный тип входной информации и содержать командные кнопки, переключатели, выпадающие меню или списки для выбора.
Основной частью внутримашинного информационного обеспечения является информационная база. Информационная база (ИБ) — это совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач.
К числу базовых файлов, хранящихся в информационной базе, относят основные, рабочие, промежуточные, служебные и архивные файлы.
Основные файлы должны иметь однородную структуру записей и могут содержать записи с оперативной и условно-постоянной информацией.Оперативные файлы могут создаваться на базе одного или нескольких входных файлов и отражать информацию одного или нескольких первичных документов. Файлы с условно-постоянной информацией могут содержать справочную, расценочную, табличную и другие виды информации, изменяющейся в течение года не более чем на 40%, а следовательно, имеющие коэффициент стабильности не менее 0,6.
Рабочие файлы создаются для решения конкретных задач на базе основных файлов путем выборки части информации из нескольких основных файлов с целью сокращения времени обработки данных.
Промежуточные файлы отличаются от рабочих файлов тем, что они образуются в результате решения экономических задач, подвергаются хранению с целью дальнейшего использования для решения других задач. Эти файлы, так же как и рабочие файлы, при высокой частоте обращений могут быть также переведены в категорию основных файлов.
Служебные файлы предназначаются для ускорения поиска информации в основных файлах и включают в себя справочники, индексные файлы и каталоги.
Архивные файлы содержат ретроспективные данные из основных файлов, которые используются для решения аналитических, например прогнозных, задач. Архивные данные могут также использоваться для восстановления информационной базы при разрушениях.
Понятие и использовании требований к ПО и спецификаций ПО. Современное состояние стандартов в области проектирования ПИС.
Требование — это условие или характеристика, которой должно удовлетворять разрабатываемое ПО. Функциональные требования определяют действия, которые должно выполнять ПО, без учета физических ограничений. Нефункциональные требования не описывают поведение ПО, но описывают его атрибуты или атрибуты окружения.
Целями процесса анализа и моделирования требований являются:
достижение соглашения между Разработчиком и Заказчиком о том, что должно делать ПО;
ограничение функциональности ПО; создание базиса для планирования разработки проекта;
определение пользовательского интерфейса;
составление Спецификации требований (Технического задания).
Для достижения поставленных целей технология предусматривает создание следующих документов: - Модель требований; - Спецификация; - Глоссарий.
Эти документы описывают, что должно делать ПО (но не как оно это делает!). Источниками информации являются эксперты заказчика и потенциальные конечные пользователи.
Модель требований служит для достижения соглашения между заказчиком, пользователями и разработчиками. Она позволяет заказчикам и пользователям убедиться в том, что ПО будет делать то, что они ожидают, а разработчикам создать то, что требуется. Модель требований включает актеров и варианты использования (use cases). Каждый вариант использования детально описывается, последовательно показывается, как ПО взаимодействует с актерами и что оно делает в каждом варианте использования. Эта модель является основой всего жизненного цикла ПО, она используется при дизайне, реализации и тестировании.
Спецификация описывает все требования к ПО (функциональные и нефункциональные). Она представляет собой текстовый документ, который определяет набор требований к конечному продукту (но не к процессу его разработки) и не содержит деталей реализации. Спецификация составляется как результат совместной работы аналитиков из Разработчика и экспертов Заказчика и является базисом для достижения соглашения между заказчиком и исполнителем.
Глоссарий определяет терминологию, общую для всех моделей и текстовых описаний ПО. Он расширяет глоссарий, созданный при обследовании организации.
Среди наиболее известных стандартов можно выделить следующие:
- ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [4].
- ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5].
- Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.
- Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML [6].
- Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
- Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
Элементы языка и канонические диаграммы языка UML. Программные средства построения диаграмм UML.
UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;
содержит механизмы расширения и специализации базовых концепций языка.
UML — это стандартная нотация визуального моделирования программных систем, на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.
Пакет (package) — общецелевой механизм для организации различных элементов модели в множество, реализующий системный принцип декомпозиции модели сложной системы и допускающий вложенность пакетов друг в друга.
Пакет – основной способ организации элементов модели в языке UML. Каждый пакет владеет всеми своими элементами, т.е. теми элементами, которые включены в него. Про соответствующие элементы пакета говорят, что они принадлежат пакету или входят в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие.
Модель является подклассом пакета и представляет собой абстракцию физической системы, которая предназначена для вполне определенной цели. Именно эта цель предопределяет те компоненты, которые должны быть включены в модель и те, рассмотрение которых не является обязательным. Другими словами, модель отражает релевантные аспекты физической системы, оказывающие непосредственное влияние на достижение поставленной цели. В прикладных задачах цель обычно задается в форме исходных требований к системе, которые, в свою очередь, в языке UML записываются в виде вариантов использования системы. В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм.
Диаграмма (diagram) — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика. Нотация канонических диаграмм - основное средство разработки моделей на языке UML.
В нотации языка UML определены следующие виды канонических диаграмм:
вариантов использования (use case diagram) - описывают функциональность ИС, которая будет видна пользователям системы.
классов (class diagram) - позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними.
кооперации (collaboration diagram) - На кооперативных диаграммах объекты (или классы ) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией.
последовательности (sequence diagram) - используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают "время жизни" объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта.
состояний (statechart diagram) - определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий.Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.
деятельности (activity diagram) - представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.
компонентов (component diagram)- назначение: разделение системы на элементы, которые имеют стабильный интерфейс и образуют единое целое. Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем.
IBM Rational Rose; Borland Together; Microsoft Visio; Sparx Systems Enterprise Architect; Gentleware Poseidon; SmartDraw; Dia; Telelogic TAU G2; StarUML
Методика формирования требований к ПО и их спецификаций на основе диаграмм вариантов использования (эффективные варианты использования).
На этапе формирования требований, прежде всего, необходимо определить область действия разрабатываемой системы и получить точное представление о желаемых возможностях системы.
Основой разработки требований является модель системных прецедентов, отражающая выполнение конкретных обязанностей внутренними и внешними исполнителями с использованием ИС.
Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания прецедентов, содержащие определения используемых данных и точную последовательность их выполнения. Описание осуществляется в соответствии с принятым в организации шаблоном, который обычно включает следующие разделы:
заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);
краткое описание прецедента;
ограничения;
предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);
постусловия (возможные состояния системы после выполнения прецедента);
предположения;
основная последовательность действий;
альтернативные последовательности действий и условия, их инициирующие;
точки расширения и включения прецедентов.
В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы.
На рис. 12.9 представлена модель системных прецедентов для бизнес-прецедента " Оказание медицинской помощи ". Исходя из цели создания системы, в модели системных прецедентов отражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением клинических записей.
Рис.
12.9.
Модель системных прецедентов
Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС.
Внутренний исполнитель " Персонал центра " и выполняемый им ручной процесс преобразован в системный прецедент "Предоставление доступа к клиническим записям ". Внешние исполнители (например, " Производитель медицинского оборудования ") непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей. В модели отражены два специальных типа связи между прецедентами (на рис. 12.9 соответствующие прецеденты выделены тенью):
" включает " — один прецедент в процессе своего исполнения обязательно выполняет некий блок действий, составляющих другой прецедент;
" расширяет " — когда прецеденты подобны по своим действиям, но один несет несколько большую функциональную нагрузку.
Таким образом, результатом разработки модели системных прецедентов является не только исчерпывающий перечень функций, которые должны быть реализованы в проектируемой системе, но и подробное описание необходимой реализации этих функций.
Диаграммы классов в UML, их нотация и семантика. Типы классов для моделирования программного обеспечения и бизнес-систем. Отображение интерфейса класса на диаграмме.
Классы — это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой.
В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Если используется составное имя (в начале имени добавляется имя пакета, куда входит класс ), то имя классадолжно быть уникальным в пакете.
Атрибут — это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов.
Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.
Графически класс в нотации языка UML изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих секциях могут указываться имя класса, атрибуты и операции класса.
Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними.
Между классами возможны различные отношения, представленные на рис. 11.2:
зависимости, которые описывают существующие между классами отношения использования;
обобщения, связывающие обобщенные классы со специализированными;
ассоциации, отражающие структурные отношения между объектами классов.
Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса " товар ") может повлиять на использующий его элемент ( класс " строка заказа "). Часто зависимости показывают, что один класс использует другой в качестве аргумента.
Обобщение — это отношение между общей сущностью (родителем — класс " клиент ") и ее конкретным воплощением (потомком — классы "корпоративный клиент " или " частный клиент "). Объекты класса -потомка могут использоваться всюду, где встречаются объекты класса -родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым.
Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа (" клиент " может сделать "заказ "). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рис. 11.3). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.
Язык UML содержит два специальных расширения: профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и профиль для бизнес-моделирования (The UML Profile for Business Modeling).
В рамках первого из них предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении различных диаграмм:
Управляющий класс (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, причем количество посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых ими. Управляющий класс отвечает за координацию действий других классов. У каждой диаграммы классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий этого варианта использования. Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом <<control>> (рис. 5.3, а).
Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс-сущность содержит информацию, которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса или прекращением работы моделируемой системы, связанные с выключением системы или завершением программы. Как правило, этот класссоответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<entity>> (рис. 5.3, б).
Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный классможет быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<boundary>> (рис. 5.3, в).
Рис. 5.3. Графическое изображение классов для моделирования программного обеспечения
В рамках второго профиля также предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении моделей бизнес-систем:
Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<worker>> или <<internalWorker>> (рис. 5.4, а).
Сотрудник для связи с окружением (caseworker) – класс, служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<caseWorker>> (рис. 5.4, б).
Бизнес-сущность (business entity) — специальный случай класса-сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<business entity>> (рис. 5.4, в).
Рис. 5.4. Графическое изображение классов для моделирования бизнес-систем
Диаграммы кооперации в UML: определение кооперации, назначение диаграмм, элементы диаграмм и нотация. Примеры.
Диаграммы кооперации предназначены для описания динамических аспектов моделируемой системы. Обычно они применяются для того, чтобы:
показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета";
распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы;
описать логику выполнения сложных операций, особенно в тех случаях, когда один объект взаимодействует еще с несколькими объектами;
изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.
Кооперация (collaboration) - это статическая конструкция для моделирования набора сущностей, взаимодействующих друг с другом. Кооперация определяет набор взаимодействующих ролей, используемых вместе, чтобы показать некую функциональность. Кооперация часто реализует некоторыйпаттерн (шаблон проектирования).
Кооперация изображается в виде эллипса с пунктирной границей (например, кооперация резервного копирования связывает компьютер, программное обеспечение и дисковый накопитель, все внутри эллипса).
Смысл
диаграммы вполне понятен: для печати
документа из некоторого приложения
необходимо выбрать из всех доступных
некий конкретный принтер. Символ
композиции применен для того, чтобы
показать, что принтер входит в состав
набора объектов. 
Мультиобъект показывает, что на "дальнем" конце ассоциации находится не один, а целый набор объектов. Такая конструкция используется, чтобы показать операцию, которая нацелена на целый набор объектов. Мультиобъект изображается как два прямоугольника, смещенных по отношению друг к другу, что создает впечатление "колоды карт". Сообщение, отправленное мультиобъекту, означает сообщение к набору объектов
Диаграммы видов деятельности: назначение, особенности и отличия от блок-схем, виды.
Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид диаграмм может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции, причем, как мы увидим далее, предоставляют для этого больше возможностей, чем "классическая" блок-схема. Диаграммы деятельности описывают переход от одной деятельности к другой, в отличие от диаграмм взаимодействия, где акцент делается на переходах потока управления от объекта к объекту.
Действия
показаны скругленными прямоугольниками,
как в блок-схеме, - мы узнаем даже ромбик
символа принятия решения с обозначениями
условий возле переходов. Да, отличия от
блок-схемы не так уж сильны. Более того,
эти отличия выглядят как логичное
расширение нотации блок-схем. Обратим
внимание на то, что начало и конец уже
не изображаются одинаковым безликим
кружком. Начало теперь закрашено, а
конец изображен в виде символа,
напоминающего кошачий глаз.
Без пояснений понятен также смысл символа жирной горизонтальной палочки - он означает распараллеливание, а затем опять слияние воедино ( синхронизацию ) потоков управления, т. е. операции "информирования клиента" и "осуществления выборки данных" выполняются одновременно. Нотация проста: несколько потоков управления сливаются в один или один поток разделяется на несколько. Третьего не дано.
Еще одно отличие от блок-схемы: На диаграмме деятельностей можно не только показать параллельно выполняемые действия, но и указать состояния объектов.
Диаграммы компонентов в UML: назначение, обозначение и особенности применения.
Полный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов и диаграмму развертывания.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
визуализации общей структуры исходного кода программной системы;
спецификации исполняемого варианта программной системы;
обеспечения многократного использования отдельных фрагментов программного кода;
представления концептуальной и физической схем баз данных.
Для представления физических сущностей в языке UML применяется специальный термин - компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента используется специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри большого прямоугольника записывается имя компонента и, при необходимости, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации.
Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае, интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса должно начинаться с заглавной буквы "I" и записываться рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.
В общем случае отношение зависимости также было рассмотрено ранее. Напомним, что зависимость не является ассоциацией, а служит для представления только факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу).
Диаграммы развёртывания в UML.
Для представления общей конфигурации и топологии распределенной программной системы в UML предназначены диаграммы развертывания.
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Разработка диаграммы развертывания, как правило, является последним этапом спецификации модели программной системы.
При разработке диаграммы развертывания преследуют следующие цели:
определить распределение компонентов системы по ее физическим узлам;
показать физические связи между всеми узлами реализации системы на этапе ее исполнения;
выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.
Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий определенным вычислительным ресурсом. В качестве вычислительного ресурса узла может рассматриваться наличие некоторого объема электронной или магнитооптической памяти или процессора. В последней версии языка UML понятие узла расширено и может включать в себя не только вычислительные устройства, но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы.
Графически на диаграмме развертывания узел изображается в форме трехмерного куба. Узел имеет собственное имя, которое указывается внутри его графического символа. Сами узлы могут представляться как в качестве типов, так и в качестве экземпляров.
Кроме изображений узлов на диаграмме развертывания указываются отношения между ними. В качестве отношений выступают физические соединения между узлами и зависимости между узлами и компонентами, изображения которых тоже могут присутствовать на диаграммах развертывания.
Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением.
Разработка диаграммы развертывания начинается с идентификации всех аппаратных, механических и других типов устройств, которые необходимы для выполнения системой всех своих функций. В первую очередь специфицируются вычислительные узлы системы, обладающие памятью и/или процессором. При этом используются имеющиеся в языке UML стереотипы, а в случае их отсутствия разработчики могут определить новые стереотипы. Отдельные требования к составу аппаратных средств могут быть заданы в форме ограничений, свойств и помеченных значений.
Процесс проектирования ПО и его связь с диаграммами UML
UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм.
На этапе создания концептуальной модели для описания бизнес-деятельности используются модели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов – модели бизнес-объектов и диаграммы последовательностей.
На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использованием диаграмм классов, диаграмм последовательностей и диаграмм состояний.
На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания.
Ниже приводятся определения и описывается назначение перечисленных диаграмм и моделей применительно к задачам проектирования ИС (в скобках приведены альтернативные названия диаграмм, использующиеся в современной литературе).
Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде.
Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.
Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).
Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.
Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.
Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.
Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.
Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.
На рис. 12.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..." (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.
