Инструментальные средства 1. Жизненный цикл ИИ Инструментальные средства-совокупность программных продуктов, обеспечивающих технологию разработки, отладки и внедрения создаваемых новых продуктов. Информационная система-программно-аппаратная система, предназначенная для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающая, в соответствии с заложенной в нее логикой обработки, возможность получения, модификации и хранения информации. Основной задачей ИС-удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. Жизненный цикл информационной системы-это непреврывный процесс с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации. Стандарт, определяющий структуру ЖЦ-ГОСТ Р ИСО/МЭК 12207-02. Согласно стандарту, структура ЖЦ основывается на 3 группах процессов: • • Основные процессы ➢ Заказ ➢ Поставка ➢ Разработка ➢ Эксплуатация ➢ Сопровождение Вспомогательные процессы(обеспечивают выполнение основных процессов) ➢ Документирование-работы по разработке, выпуску, редактированию, распространению и сопровождению документов, в которых нуждаются все заинтересованные лица ➢ Управление конфигурацией-включает работы: определение и установление состояния программных объектов в системе, управление изменениями и выпуском объектов, обеспечение полноты, совместимости и правильности объектов; управление хранением, обращением и поставкой объектов. ➢ Обеспечение качества-работы по обеспечению соответствия создаваемой системы и реализуемых процессов ЖЦ установленным требованиям и утвержденным планам. ➢ Верификация-работы соответствующего субъекта(заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации. ➢ Аттестация-работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы. ➢ Совместный анализ-работы по оценке состояния или результатов какойлибо работы(системы) • ➢ Аудит-работы независимых(по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора ➢ Разрешение проблем-работы по анализу и устранению проблем, обнаруженных при реализации проекта Организационные ➢ Управление проектами-работы по планированию и управлению процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности ➢ Создание инфраструктуры проекта-работы по установлению и обеспечению инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, ИС, методики, стандарты и условия разработки, эксплуатации или сопровождения системы. ➢ Усовершенствование-работы по оценке, контролю и улучшению процессов ЖЦ ➢ Обучение-работы по планированию и проведению обучения персонала, включая разработку чебных материалов. Приэтом под персоналом понимается не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. 2. Модель ЖЦ Модель ЖЦ любого конкретного ПО определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Наиболее распространены в настоящее время модели ЖЦ: ➢ Каскадная(1970 предложена У.Ройсом) ➢ Инкрементная ➢ Спиральная(1980 Б.Боэм) 1)Каскадная стратегия(однократный проход, водопадная или классическая модель) подразумевает линейную последовательность прохождения стадий создания ИС. Переход с одной стадии на следующую происходит только после того, как будет полностью заврешена работа на текущей. +Достоинства: ✓ На каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. ✓ Выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы(денежные, материальные, людские) -Недостатки: ✓ Реальный процесс разработки ИС редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем. ✓ ЖЦ основан на точной формулировке исходных требований к ИС. Реально в начале проекта требования заказчика определены лишь частично ✓ Результаты разработки доступны заказчика только в конце проекта. Если требования изложены неточно, то система не удовлетворяет потребностям заказчика 2)Инкреметная стратегия-подразумевает разработку ИС с линейной последовательностью стадий, но в несколько инкрементов, т.е. с запланированным улучшением продукта. В начале работы над проектом определяются все основные требования к системе, после чего выполняется ее разработка в виде последовательности версий. При этом каждая версия является законченным и работоспособным продуктом. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и тд, пока не будет получена полная система. Данная модель ЖЦ характереа при разработке сложных и комплексных систем, для которых имеется четкое видение того, что собой должен представлять конечный результат. Разработка версиями ведется в силу разного рода причин: o Отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект o Отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки o Требований поэтапного внедрения и освоения продукта конечными пользователями +-Достоинства/Недостатки: Такие же как и у классической. Но тут заказчик может увидеть результаты. 3)Спиральная стратегия-подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий. Данная модель ЖЦ характерна при разработке новаторских систем. В начале работы над проектом у заказчика и разработчика нет четкого видения итогового продукта или 100% уверенности в успешной реализации проекта. В связи с этим принимается решение разработки системы по частям с возможностью изменения требований или отказа от ее дальнейшего раззвития. +Достоинства: ✓ Позволяет быстрее показать пользователям системы работоспособный продукт, активизируя процесс уточнения и дополнения требований ✓ Допускает изменение требований при разработке ИС, что характерно для большинства разработок, в том числе типовых. Обеспечивает большую гибкость в управлении проектом ✓ Позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой иттерации. ✓ Позволяет совершенствовать процесс разработки ✓ Уменьшить риски заказчика -Недостатки: o Увеличивает неопределенность у разработчика в перспективах развития проекта o Затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа выполнена. План составляется на основе статистических данных из опыта. Правильный выбор модели позволяет грамотно планировать объемы финансирования, сроки и ресурсы, необходимые для выполнения работ. 3. Инструментальные средства этапа анализа и проектирования. Основные понятия и классификация CASE-средств В соответствии с этапами ЖЦ ИС для их разработки можно использовать следующие категории инструментальных средств: Case-средства(computer aided software engineering)-программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Требования к методикам реализации и программным инструментальным средствам ➢ Реализацию крупных проектов принято разбивать на стадии анализа(описание бизнес логики ПО), проектирования(определить модули и архитектуру будущей системы), кодирование, тестирования и сопровождения. ➢ Крупный проект невозможно реализовать в одиночку. Необходимо иметь средства координации и управления коллективом разработчиков. ➢ ЖЦ создания сложной ИС сопоставим с ожидаемым временем ее эксплуатации. Для создания крупной ИС необходим инструмент значительно уменьшающий время ее разработки ➢ Инструментальные средства, на которых реализуется крупный проект, были достаточно гибкими к изменяющимся требованиям. CASE-технология-представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать ПО, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Методология определяет шаги и этапность проекта и правила использования методов, с помощью которых разрабатывается проект. CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. • • • Метод- процедура или техника генерации описаний компонентов ИС (пример:проектирование потоков и структур данных) Нотация-отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках. Инструментальные средства CASE-специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС. Архитектура CASE-средства ➢ ➢ ➢ ➢ ➢ ➢ Репозиторий Графические средства моделирования ПО Верификатор диаграмм Средства разработки документации проекта Средства администрирования проекта Сервис Репозиторий-содержит информацию об объектах проектируемой ИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В нем хранятся описание следующих объектов: ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ Проектировщикови их прав доступа к различным компонентам системы Организация структур Диаграмм Компонентов диаграмм Свзей между диаграммами Структур данных Программных модулец Процедур Библиотеки модулей и тд Графические средства моделирования ПО позволяет выполнять следующие операции: ➢ ➢ ➢ ➢ Создавать элементы диаграмм и взаимосвязи между ними Задавать описания элементов диаграмм Задавать описания связей между элементами диаграмм Редактировать элементы диаграмм, их взаимосвязи и описания Верификатор диаграмм-служит для контроля правильности построения диаграмм в заданной методологии проектирования. Функции: ➢ Мониторинг правильности построения диаграмм ➢ Диагностика и выдача сообщений об ошибках ➢ Выделение на диаграмме ошибочных элементов Средства разработки документации проекта-позволяет получить информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например, по времени, автору, элементам диаграмм, диаграмме или проекту в целом. Средства администрирования проекта-представляет собой инструменты для выполнения следующих функций: ➢ ➢ ➢ ➢ Инициализации проекта Задания начальных параметров проекта Назначения и изменения прав доступа к элементам проекта Мониторинга выполнения проекта Сервис-набор системных утилит по обслуживанию репозитория. Функции: ➢ Архивации данных ➢ Восстановления данных ➢ Создание нового репозитория Класификация CASE-средств В качестве критериев классификации CASE-средств используют: • • • • • Ориентацию на этапы ЖЦ Функциональную полноту Тип используемой модели Степень независимости от СУБД Допустимые платформы 1)Типы CASE-средств по ориентации на этапы ЖЦ: ➢ Средства анализа, предназначенные для построения и анализа моделей ПО ➢ Средства анализа и проектирования, поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций. Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных. ➢ Средства проектирования БД, обеспечивающие моделирование данных и генерацию схем БД для наиболее распространенных СУБД ➢ Средства реинжиринга, обеспечивающие анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций. Вспомогательные средства включают: ➢ ➢ ➢ ➢ Средства планирования и управления проектом Средства конфигурационного управления Средства тестирования Средства документирования 2)По функциональной полноте типы CASE-средств: ➢ Системы, предназначенные для решения частных задач на одном или нескольких этапах ЖЦ ➢ Интегрированные системыт, поддерживающие весь ЖЦ и связанные с общим репозиторием. 3)По типу используемых моделей ➢ Структурные-основаны на методах структурного и модульного программирования, структурного анализа и синтеза ➢ Объектно-ориентированные-основаны на методах объектно-ориентированного анализа и проектирования ➢ Комбинированные-поддерживает одновременно структурные и объектноориентированные методы. 4)По степени независимости: ➢ Независимые системы-поставляются в виде автономных систем, не входящих в состав конкретных дисциплин. ➢ Встроенные СУБД 4. Инструментальные средства поддержки функциональноориентированных методологий анализа и проектирования Функциональные методологии рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методологии заключается в четком отделении функций(методов обработки данных) от самих данных. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации о текущей работе. Методологии: • IDEF-семейство нотаций, стандарт МО США, рекомендован правительство РФ для применения в гос.учреждениях, основной инструмент CA Erwin Process Modeler(Computer Associations) • • ARIS(Architecture of Integrated Information Systems)-методология и нотация для професионального моделирования бизнес-процессов, инструмент ARIS Tooleset (IDS Scheeer AG) BPMN(Business Process Model and Notation)-нотация и модель бизнес-процессов. Разработана BPM и поддерживается Object Management Group после слияния организаций. Семейство IDEF 1) Стандарт IDEF0-методология функционального моделирования. Метод IDEF0 предназначен для моделирования выполнения функций объекта путем создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Функциональная модель представляет собой структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции 2)IDEF1-методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи. 3) IDEFX1-методология построения структур данных. Относится к типу методологий «Сущность-Связь» (ER-Entity Relationship) и используется для моделирования БД, имеющих отношение к рассматриваемой системе. 4)IDEF2-методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта почти отказались. Но в настоящее время применяются алгоритмы и их компьютерные реализации, позволяющие превращать набор статистических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри»(CPN-Color Petri Nets) 5)IDEF3-методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. Она имеет прямую взаимосвязь с методологией IDEF0-каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3. 6)IDEF4-методология построения объектно-ориентированных систем. Отображают структуру объектов и заложенные принципы их взаимодействия, позволяя анализировать и оптимизировать сложные объектно-ориентированные системы. 7)IDEF5-методология онтологического исследования сложных систем. Онтология систем может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. 1.CAERwin Process Modeler(BPwin) -используется для проведения анализа и оерганизациибизнес-процессов Поддерживает методологии: • • • IDEF0(функциональная модель) IDEF3(WorkFlow Diagram) DFD(DataFlow Diagram) IDEF0-модель предполагает наличие сформулированной цели и единственного субъекта и одной точки зрения. Цель: Что должна показывать модель? Точка зрения: перспектива, с которой наблюдалась система при построении модели. В пункте меню Model/Model Properties можно внести области, цели и точки зрения. Purpose-цель, Definition-определение модели и описание области. Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели. Модель AS-IS-как есть. Можно искать недостатки организации Модель TO-BE-как будет Основу методологии IDEF) составляет графический язык описания бизнес-процессов. Модель в данной нотации представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Модель может содержать 4 типа диаграмм: • • • • • Контекстную (только одна в одной модели) Диаграммы декомпозиции Диаграммы дерева узлов Диаграммы только для экспозиции(FEO) Swimlane-диаграммы Контекстная диаграмма представляет собой общее описание системы и ее взаимодействия с внешней средой. Далее следует декомпозиция. Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи их. Диаграммы для экспозиции-строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо специальных целей. Swimlane-диаграммы-являются разновидностью диаграммы IDEF3, ПОЗВОЛЯЮЩЕЙ ЯВНО ОПИСАТЬ РОЛИ И ОТВЕТСТВЕННОСТИ ИСПОЛНИТЕЛЕЙ В конкретной технологической операции. Можно использовать слияние или расщепление моделей для коллективной работы над проектом. Это достигается с помощью стрелок вызова. 2.CA Erwin Data Modeler (Erwin) Используется для построения модели данных. Erwin имеет два уровня представления модели-логический и физический. На логическом уровне данные представляются безотносительно конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физичсекий уровень данных-это отображение системного каталога, который зависит от реализации конкретной СУБД. Erwin позволяет проводить процессы прямого и обратного проектирования БД. Это значит, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Erwin интегрируется со средствами разработки клиентской части-PowerBuilder, SQL Windows, Visual Basic, Delphi, что позволяет автоматически генерировать код приложения, который готов к компиляции и выполнению. 3.CA Erwin Data Model Validor(Erwin Examiner) Инструмент для проверки структуры БД и создаваемых в ERWIN моделей, позволяющий выявлять недочеты и ошибки проектирования. 4.CA Erwin Model Manager (ModelMart) Совместное моделирование всеми участниками работ. Позволяет формировать библиотеки стандартных решений, включающие наиболее удачные фрагменты реализованных проектов. Семейство продуктов ARIS Среда описания и анализа бизнес-процессов ARIS включает в себя методологическую основу(Architecture of Integrated Information Systems) и ее программную реализацию в виде семейства продуктов ARIS, разработанных компанией IDS Scheer AG. Методология ARIS рассматривает предприятие как совокупность 4 взглядов: • • • • Взгляд на организационную структуру Взгляд на структуру функций Взгляд на структуру данных Взгляд на структуру процессов При этом каждый из этих взглядов разделяется еще на 3 уровня: • • • Описание требований Описание спецификации Описание внедрения Таким образом ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS делит бизнес-модели на 4 группы: • • Группа «Оргструктура»-состоит из моделей, с помощью которых описывается Орг.структура компании. Группа «Функции»-состоит из моделей, используемых для описания стратегических целей компании, функций и прочих элементов функциональной деятельности организации. • • Группа «Информация»-состоит из моделей, с помощью которых описывается информация, используемая в деятельности организации. Группа «Процессы»-состоит из моделей, используемых для описания бизнеспроцессов, а также различных взаимосвязей между структурой, функциями и ифнормацией. Преимущества: Эргомичность и высокая степень визуализации бизнес-моделей. Смысловое значение имеет цвет, что повышает восприимчивость и читабельность схем бизнес-моделей. Имеет наибольшее количество различных объектов, используемых при построении бизнесмоделей, что увеличивает их аналитичность. Позиционирует себя как конструктор, из которого под конкретный проект в зависимости от его целей и задач разрабатывается локальная методология, состоящая из небольшого количества требуемых бизнес-моделей и объектов. В проектах наиболее часто используются следующие модели: • • • Модель «Диаграмма целей»-OD-применяется для описания стратегических целей компании, их иерархической упорядоченности, а также связей целей с продуктами и услугами, производимыми компанией и бизнес-процессами, поддерживающими их производство. Модель «Дерево функций»-FT-описывает функции, выполняемые в компании и их иерархию. Данная модель часто применяется для построения дерева бизнеспроцессов. Модель «Диаграмма окружения процесса»-FAT-позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов. Семейство продуктов ARIS состоит из 2 основных продуктов ARIS Easy Design и ARIS Toolset и множества функциональных модулей. ARIS Toolset(ARIS Easy Design)-единая среда моделирования, которая представляет собой совокупность 4 основных компонентов: • • • • Explorer(Проводник) Designer(средство для графического описания моделей) Таблиц(для ввода различных параметров и атрибутов) Мастеров(Wizards) Различие в функционале. Easy Design ориентирован на сбор информации и документирование, когда ARIS Toolset позволяет еще и проводить комплексный анализ, семантические проверки информации(+скрипты для отчетов, анализа и семантических проверок) Нотация ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты. Система моделирования анализа деятельности подерживает следующие функциональные требования: ⚫ Анализ бизнес-среды ⚫ Разработка стратегии предприятия ⚫ Формирование общего видения компании (глобальный уровень) ⚫ Формирование детального описание процессов компании (вплоть до процессов рабочих мест) ⚫ Формирование организационной и функциональной структуры, структур данных ⚫ Описание требований к информационным системам поддержки деятельности ⚫ Проектирование интегрированных информационных систем ⚫ Проведение документирования результатов проекта (создание комплекта документов, закрывающих этапы проекта, регламентирующих работу предприятия в рамках новой системы управления, описывающих систему управления в соответствии с требованиями стандартов качества) ⚫ Проведение анализа разработанных моделей (количественный и сравнительный, анализ, анализ семантики, анализ стоимостных и временных характеристик) ⚫ Разработка информационных систем (формирование баз данных, генерация программных кодов) ⚫ Интеграция моделей с функционирующими информационными системами (актуализация организационной структуры, номенклатуры, показателей) Oracle Designer Oracle Designer представляет собой интегрированную CASE-среду для автоматизации процессов всех этапов жизненного цикла сложной прикладной системы, включая формулировку и анализ требований, детальный анализ предметной области, проектирование, программирование, тестирование и оценка, сопровождение, обеспечение качества, управление конфигурацией, управление проектом, документирование системы. В основе CASE-технологии и инструментальной среды Oracle лежит методология структурного проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов. В качестве основных этапов процесса разработки системы выделяются ⚫ моделирование и анализ бизнес-процессов ⚫ разработка концептуальных моделей предметной области, ⚫ проектирование прикладной системы и реализация. В состав Oracle Designer входят удобные средства поддержки первого этапа, позволяющие строить наглядные представления процессов и взаимосвязей между ними и анализировать их с использованием средств мультимедиа. На втором этапе разрабатываются детальные концептуальные модели предметной области, описывающие особенности предметной области, характер решаемых задач, информационные потребности и ресурсы, технологические ограничения и так далее. Результатом являются модели двух типов - информационная, отражающая существующие информационные структуры и взаимосвязи между ними, и функциональная, описывающая технологию и способы обработки информации, используемые в данной области. На этапе проектирования на основании концептуальных моделей вырабатываются технические спецификации будущей прикладной системы - определяется структура и состав базы данных, специфицируется набор программных модулей. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит на основании данных концептуальных моделей. И наконец, на этапе реализации создаются программы, отвечающие всем требованиям проектных спецификаций. Использование генераторов приложений, входящих в состав Oracle Designer, позволяет полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность. Все модели и спецификации, относящиеся к проекту прикладной системы и возникающие на различных этапах ее жизненного цикла, хранятся в централизованной базе данных – репозитории. Структура репозитория, представляющего собой базу данных Oracle, позволяет хранить не только метаданные, но и различные файлы, содержащие документацию, исходные тексты программ, исполняемые модули. 5. Инструментальные средства поддержки объектно-ориентированной методологии анализа и проектирования Объектные методологии рассматривают моделируемую организацию как набор взаимодействующих объектов-производственных единиц. Объект определяется как осязаемая реальность-предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует структурам организации. Rational Rose - CASE-средство фирмы Rational Software Corporation (США) предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов . В составе Rational Rose можно выделить 6 основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ. Диаграммы вариантов использования- показывают, какая функциональность должна быть реализована в системе, основные функции, которые должны быть включены в сиcтему (use case), их окружение (actors) и взаимодействие функций с окружением. Воздействующие объекты (actors) не являются частью системы - это конечные пользователи или другие программы, взаимодействующие с проектируемой информационной системой. Функциональность (use case) – последовательность действий, выполняемых системой, которые приводят к определенным результатам, необходимым для конкретного воздействующего объекта. Репозиторий представляет собой объектно- ориентированную базу данных. Средства просмотра обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации. В результате разработки проекта с помощью CASE-средств Rational Rose формируются следующие документы: ⚫ диаграммы классов; ⚫ диаграммы состояний; ⚫ диаграммы сценариев; ⚫ диаграммы модулей; ⚫ диаграммы процессов; ⚫ спецификации классов, объектов, атрибутов и операций ⚫ заготовки текстов программ; ⚫ модель разрабатываемой программной системы. Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций). Sparx Systems Enterprise Architect Enterprise Architect (EA) – CASE-инструмент для проектирования и конструирования программного обеспечения. EA поддерживает спецификацию UML2.0+, описывающую визуальный язык, которым могут быть определены модели проекта. Некоторые из ключевых функций ЕА: ⚫ создание элементов UML-моделей широкого круга назначения; ⚫ размещение этих элементов в диаграммах и пакетах; ⚫ документирование созданных элементов; ⚫ генерация кода для конструируемого ПО; реверс-инжиниринг имеющегося кода на некоторых EA поддерживает все модели/диаграммы UML 2.0.: Структурные Диаграммы: • Класс • Объект • Соединение • Пакет • Компонент • Развертывание Поведенческие Диаграммы: • Регистр Использования • Связь • Последовательность • Краткий обзор Взаимодействия • Действие • Состояние • Синхронизация Архитектура EA Архитектурно Enterprise Architect представляет собой программу – рабочее место EA, из которого осуществляется соединение через собственный драйвер БД с проектным репозитарием, организованным в виде базы данных. В качестве базы данных по умолчанию используется Microsoft Jet. Также в качестве сервера БД могут использоваться SQL Server, MySQL, Oracle 9i и 10g, PostgreSQL, Adaptive Server Anywhere, MSDE Server, Progress OpenEdge. На рабочем месте хранятся пользовательские настройки этого рабочего места, такие как настройки отображения панелей инструментов, набор горячих клавиш и т.д. В проектном репозитарии хранятся следующие элементы моделирования: ⚫ объекты модели, такие как UML-элементы и пакеты; коннекторы, которые связывают взаимодействующие объекты; диаграммы, отображающие объекты, коннекторы и ссылки на другие диаграммы. При этом один элемент может быть отображен на нескольких диаграммах, но физически как объект базы данных он хранится только в одном экземпляре. Т.о. удаление элемента на диаграмме не вызывает удаление объекта из репозитория. Также в проектном репозитории хранится дополнительная и служебная информация: ⚫ дополнительные справочники, такие как глоссарий, авторов моделей, задач, проблем, дефектов и пр.; ⚫ настроечные справочники, такие как типы стереотипов, пользовательских тегов, шаблонов отчетов и т.п. ⚫ шаблоны проектирования, такие как UML-паттерны и UML-профили, позволяющие сохранять и быстро воспроизводить типовые решения, смоделированные ранее. ⚫ 10базовые ⚫ 1 Для линии, т.е. моментальные снимки состояния пакетов в XML-формате. обмена информацией между репозиториями используется экспорт/импорт файлов xml Используя EA, можно выполнять форвард и реверс-инжиниринг ActionScript, C++, C#, Delphi, Java, Python, PHP, VB.NET and Visual Basic классов, синхронизировать код и элементы моделей, проектировать и генерировать элементы баз данных. Из моделей может быть быстро создана документация в стандартном rtf-формате и импортирована в Word для финального редактирования, так же доступна генерация HTML- документов. Т.о. EA – современный инструмент, который поддерживает все аспекты цикла разработки, обеспечивая полную трассировку от начала проектирования до размещения и поддержки. Также он обеспечивает поддержку тестирования, управления сопровождением и изменениями. 6. Проектирование пользовательского интерфейса. Интерфейс-совокупность возможностей, способов и матодо взаимодействия двух систем. Человеко-машинный интерфейс-это методы и средства обеспечения непосрдественно взаимодействия между оператором и технической системой, предоставляющих возможности оператору управлять этой системой. Интерфейс пользователя(UI)-разновидность интерфейсов, в котором одна сторона представлена человеком(пользователей), а другая-машиной. Представляет собой совокупность средств и методов при помощи которых пользователь взаимодействует с различными машинами, устройствами. Подходы к проектированию интерфейсов: 1)Инженерно-технический(Machine-Centered) 2)Когнитивный(Human-Centered) Эти два подхода представляют автоматизированную систему на самом верхнем уровне детализации и рассматривают процесс разработки интерфейса либо с позиции человекаоператора, либо со стороны функциональных возможностей компьютера. 1. Подход основан на предположении, что человек работает с компьютером подобно самому компьютеру, т.е. по опредеелнному алгоритму. Методика алгоритмического моделирования GOMS(Goals-Operations-MethodsSelectionrules), представляющая этот подход, предполагает, что результат, получаемый при выполнении пользователей некоторой задачи есть цель. Для ее достижения пользователь может выполнять элементарные действия-операторы. Последовательность операторов, позволяющая достичь цели называется методом. Правила выбора, основанные на принципе «есть-то», позволяют изменять поток управления. Пользователь вынужден думать как разработчик при таком подходе. 2. Когнитивный подход пришедший на смену алгоритмическому моделированию, рассматривает пользователя как центральную фигуру процесса взаимодействия с системой. Факторы определяющие успешность выполнения задачи оператором-это качество предоставления и управления информацией с точки зрения возможностей и ограничений человека. Методологии разработки интерфейсов • Проектирование, ориентированное на дейстельность(Activity-Centered Design ACD) Эта методология рассматривает систему «человек-компьютер», как комплекс связанных деятельностных понятий и представлений. Теория деятельности, лежащая в основе этого подхода, представляет компьютер в качестве инструмента, с помощью которого человек решает различные задачи, а именно деятельность человека влияет на процесс. Согласно принципам теории деятельности весь поток активности пользователя можно разложить на последовательность связанных задач и подзадач, логические этапы. Это позволяет анализировать цели, внешние и внутренние задачи, порядок и вид операций пользователя, совершаемых для достижения итогового результата, а по результатам анализа разработать интерфейс, наиболее подходящий для данного вида деятельности. • Целеориентированное проектирование(Goal-oriented design) Эта методология разработки пользовательских интерфейсов основана на предположении о том, что тщательное изучение целей пользователя и понимание того, к чему он стремится, позволяет решить проблему «когнитивного трения». Когнитичное трение-Понятие введенное А.Купером и характеризующее отношение человека к сложной вещи(например к компьютеру), как к другому человеку. Такое отношение возникает в ситуации, когда человек не может понять того, как и почему вещь работает(или не работает) Метод Купера: По идее Купера, направлять разработку продукта должны специалисты по дизайну зваимодействия. В простейшем случае результатом работы дизайнеров является документ, описывающий внешний дизайн продукта(не графический, не только графический точнее, а дизайн взаимодействия), в соответствии с которым будут действовать разработчики. Метод Купера базируется на 3 китах: • • «персоны»-выдуманные представители целевой аудитории, не «общие» и расплывчатые, а максимально детализированные Цели пользователей: личные (не чувствовать себя глупым) практические и корпоративные (максимизировать объем продаж) Сценарии работы с продуктом • Проектирование, ориентированное на пользователя(USER-Centered Design) • Дизайн, ориентированный на пользователя-методология, получившая оправданную популярность и применяемая не только при разработке программного обеспечения. Ее суть сводится к изучению потребностей и возможностей конечных пользователей и адаптации продукта под них. Это концепция создания продуктов,в том числе и ПО, которыми люди хотели бы пользоваться. В 1992 году международная организация по стандартизации ИСО представила группу стандартов ИСО 9241 «Эргономические требования для офисной работы с видеодисплейными терминалами» В 2006 году они поличили общее название «Эргономика взаимодействия «человексистема»» Для независимых разработчиков стандарты-не более чем рекомендации. Крупные компании и сообщества разработчиков зачастую применяют собственные регламентирующие документы и руководства по проектированию пользовательского интерфейса, используемые, как правило, в конкретной технологии или системе. Так, например, консорциум W3 продвигает Web Accessibility Initiative (WAI)-совокупность рекомендаций, придерживаясь которых веб-мастера могут создавать сайты с учетом пользователей с ограниченными возможностями. Гугл, Майкрософт и Эпл представляют для разработчиков приложений собственные спецификации и руководства по созданию пользовательских интерфейсов под свои платформы. Принципы разработки пользовательского интерфейса: 2 закона дизайна интерфейсов: Джеф Раскин, специалист по компьютерным интерфейсам в своей книге «The Human Interface» на основе законов робототехникиА.Азимова сформулировал 2 закона разработки польз.интерфейсов: • • Компьютер не должен вредить вашей работе или своим бездействием допустить причинение вреда вашей работе. Компьютер не должен тратить ваше время или требовать от вас больше работы, чем в действительности необходимо. 3 общих принципа проектирования пользовательских интерфейсов “Shareware профессиональная разработка и продвижение программ”: • • • Программа должна помогать выполнить задачу, а не становиться этой задачей При работе с программой пользователь не должен ощущать себя дураком Программа должна работать так, чтобы пользователь не считал компьютер дураком. 10 эвристических правид Якоба Нильсена Эвристика-совокупность приемов и методов, облегчающих решение практических задач. Юзабилити-эргономическая характеристика степени удобности предмета для применения пользователями при достижении определенных целей в некотором контексте. 1)Видимость состояния системы 2)Равенство между системой и реальным миром Система должна разговариать с пользователем на его языке, предоставление информации организовано. 3)Свобода действий пользователя Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы путем отмены или повтора операций. 4)Последовательность и стандарты Принцип последовательности означает использование одних и тех же понятий и средств для отражения схожих образов и выполнения однотипных задач. 5)Предупреждение ошибок Система должна быть разработана так, чтобы минимизировать число ситуаций, в которых пользователь может совершить ошибку. 6)Понимание лучше, чем запоминание Все объекты, функции, действия должны быть видны пользователю. Пользователь должен иметь простой доступ к контексной справке. 7)Гибкость и ээффективность использования Интерфейс должен быть удобен. Горячие клавиши, тулбары, контексные меню 8)Эстетичный и минималистичный дизайн 9)Распознавание и исправление ошибок Сообщения ошибок должны быть написаны простым языком, без кодов. 10)Справка и документация Справочная информация должна быть доступна для поиска Принципы Ларри Константина ➢ Структурный принцип: Проектирование интерфейса должно вестись целенаправленно. Группировка связанных объектов и разделения несвязаных. ➢ Принцип простоты ➢ Принцип видимости ➢ Принцип обратной свзяи ➢ Принцип толерантности ➢ Принцип повторного использования Этапы разработки пользовательского интерфейса: (функциональность, эстетичность, производительность) 1. Проектирование Функциональные требования: определение цели разработки и исходных требований Анализ пользователей: определение потребностей пользователей, разработка сценариев, оценка соответствия сценариев ожиданиям пользователей Концептуальное проектирование: моделирование процесса, для которого разрабатывается приложение Логическое проектирование: определение информационных потоков в приложении Физическое проектирование: выбор платформы, на которой будет реализован проект и средства разработки 2. Реализация Прототипирование:разработка бумажных или интерактивных макетов экранных форм Конструирование: создание приложения с учетом возможности изменения дизайна 3. Тестирование Юзабилити-тестирование:тестирование приложения различными пользователями, в том числе и с ограниченными возможностями Анализ пользователей:методы и средства 1)Персонификация-составление детализированных типовых профилей потенуиальных пользователей, относящихся к разным группам. Анализ профилей помогает смоделировать такие поведенческие аспекты, как цели, желания, потребности, предпочтения и ожидания пользователей. 2)Анализ контекста-сбор всей доступной информации о том, что именно делают пользователи в процессе выполнения конкретной задачи. Результаты анализа являются основой для составления сценариев использования USE CASE. 3)Сценарии использования-описывают поведение пользователей при решении производственных задач в определенном контексте. Они позволяют моделировать поведение пользователей, исследовать вопросы юзабилити на самых ранних этапах проектирования, определять цели пользователей, обойтись минимальными ресурсами итд Сложность заключается с неоьходимостью разработки такого количества сценариев, которое покрывало бы большое количество различных ситуаций.
