
- •Проектирование асоиу в современных условиях
- •Принципы создания асоиу
- •Разработчик ас в современной системе разделения труда.
- •Особенности рынка асоиу и программного обеспечения.
- •Асоиу как объект проектирования
- •Аспекты представления асоиу. Функциональное представление асоиу.
- •Аспекты представления асоиу. Структурное представление асоиу.
- •Аспекты представления асоиу. Компонентное представление асоиу.
- •Проектирование асоиу и программного обеспечения как сложной системы. Понятие простых и сложных систем, признаки сложной системы. Способы борьбы со сложностью.
- •Методы проектирования программного продукта как сложной системы: структурный, объектный, потоковый.
- •Описание бизнес-процессов. Концепция. Форматы графических схем бизнес-процессов.
- •Модели объекта автоматизации. Методика функционального проектирования idef0 (Integrated deFinition 0).
- •Моделирование бизнес-процессов спецификация требований на основе структурного подхода
- •Модели объекта автоматизации. Методика информационного проектирования idef3.
- •Модели объекта автоматизации. Методика dfd. Примеры диаграмм.
- •Автоматизация проектирования. Case – системы bPwin. Примеры диаграмм
- •Автоматизация проектирования. Case – системы eRwin. Примеры диаграмм.
- •Организация процесса конструирования программного обеспечения ас.
- •Понятие метода и технологии конструирования.
- •Классический жизненный цикл программных систем. Макетирование.
- •Инкрементная модель стратегии конструирования
- •Спиральная модель.
- •Тяжеловесные и облегченные процессы. Xp-процессы.
- •Унифицированный процесс проектирования по асоиу
- •Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика rup.
- •1.Определение требований
- •2.Анализ
- •3.Проектирование
- •4.Реализация
- •5.Тестирование
- •Унифицированный язык моделирования. Предметы, отношения и диаграммы в uml.
- •Руководство программным проектом
- •Процессы руководства проектом.
- •Измерения, меры и метрики. Размерно-ориентированные метрики.
- •Измерения, меры и метрики. Функционально-ориентированные метрики.
- •Измерения, меры и метрики. Метрики объектно-ориентированных программных систем.
- •Набор метрик Чидамбера и Кемерера
- •Использование метрик Чидамбера-Кемерера
- •Оценка проекта на основе loc и fp метрик.
- •Оценка проекта на основе loc и fp метрик.
- •Стандартизация проектирования ас и программного обеспечения
- •Общие понятия стандартизации. Международные и национальные организации, разрабатывающие стандарты.
- •Национальные организации, разрабатывающие стандарты
- •Нормативные документы по стандартизации и виды стандартов
- •Стандарты в области программного обеспечения ас
- •Стандарты комплекса гост р 34. Стадии и этапы проектирования ас, определяемые стандартом гост 34.602.
- •Стандарты комплекса гост р 34. Содержание технического задания на создание ас, гост 34.601.
- •Процессы жизненного цикла программного средства, определяемые в стандарте гост p исо/мэк 12207.
- •Фазы разработки и внедрения асоиу.
- •Фаза «Обоснование»
- •Фаза «Создание»
- •Реализация автоматизированной системы
- •Тестирование программного продукта
- •Основные понятия и принципы тестирования, тестирование «белого» и «черного» ящиков
- •Тестирование «черного ящика»
- •Тестирование «белого ящика»
- •Особенности тестирования «белого ящика»
- •Тестирования базового пути. Цикломатическая сложность программного обеспечения.
- •Потоковый граф
- •Цикломатическая сложность
- •Тестирования условий. Тестирования циклов Способы тестирования условий
- •Тестирование ветвей и операторов отношений
- •Способ тестирования потоков данных
- •Тестирование циклов
- •Простые циклы
- •Вложенные циклы
- •Объединенные циклы
- •Неструктурированные циклы
- •Особенности объектно-ориентированного тестирования по.
- •Изменение методики при объектно-ориентированном тестировании
- •Тестирование объектно-ориентированной интеграции
- •Объектно-ориентированное тестирование правильности
- •Управление качеством ас
- •Процесс управления качеством. Обеспечение и планирование качества.
- •Процесс управления качеством
- •Планирование качества
- •Контроль качества. Измерение показателей программных систем
- •Контроль качества
- •Измерение показателей по
- •Стандарт исо/мэк 15504. Модель зрелости конструирования программных систем. (смм).
- •Модели качества процессов конструирования
- •V. Высокая оптимизация/Optimizing
- •IV. Управляемость/Managed
- •III. Начало оптимизации (Определенность) /Defined
- •II. Контроль/Repeatable
- •I. Начальный уровень (хаос)/Initial
- •Гост исо/мэк 12119-2000. Требования к качеству пакетов программ.
- •1 Область применения
- •3 Требования к качеству
- •Описание продукта
- •3.1.1 Общие требования к содержанию
- •3.1.2 Обозначения и указания
- •3.1.4 Формулировки надежности
- •3.1.5 Формулировки практичности
- •3.2 Документация пользователя
- •3.3 Программы и данные
- •Гост исо/мэк 12119-2000. Указания по тестированию пакетов программ.
- •4 Указания по тестированию
- •4.1 Необходимые условия для тестирования
- •4.2 Работы по тестированию
- •4.3 Протоколы тестирования
- •4.4 Отчет о тестировании
- •4.5 Дополнительное тестирование
- •Документация автоматизированной системы
- •Предпроектная документация. Материалы обследования объекта автоматизации. Техническое задание. Договорная документация.
- •Проектная документация.
- •Рабочая документация.
- •Эксплуатационная документация
- •Организационно-распорядительная документация. Оформление документации.
- •Интегрированная система управления производством класса erp (Enterprise Recourse Planning).
- •Концепция erp II – Enterprise Resource and Relationship Processing (Управление внутренними ресурсами и внешними связями предприятия)
Унифицированный процесс проектирования по асоиу
Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика rup.
Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира.
Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:
абстрагирование (abstraction);
инкапсуляция (encapsulation);
модульность (modularity);
иерархия (hierarchy).
Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:
типизация (typing);
параллелизм (concurrency),
устойчивость (persistence).
Абстрагирование - это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа.
Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта.
Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.
Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов - агрегация.
Типизация — это ограничение, накладываемое на класс объектов и препятствующее взаимозаменяемости различных классов (или сильно сужающее ее возможность). Типизация позволяет защититься от использования объектов одного класса вместо другого или по крайней мере управлять таким использованием.
Параллелизм — свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.
Устойчивость — свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).
Основные понятия объектно-ориентированного подхода — объект и класс.
Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение.
Класс — это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов - одна из самых сложных задач объектно-ориентированного проектирования.
Понятие полиморфизма может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.
Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации. Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели ранних стадий могут быть непосредственно подвергнуты сравнению с моделями реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.
Рабочие процессы RUP и диаграммы UML
|
|
Rational Unified Process (RUP) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software. Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).
Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Поэтому процесс управляется вариантами использования (Use Case) системы, или иначе – прецедентами.
Для реализации требований заказчика в установленные сроки, Унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации. Фазы и основные потоки работ процесса показаны на рис. 1, там же даны примерные трудозатраты работ по фазам.
Рис. 1 Фазы и потоки работ RUP
Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта. Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель — проектный план, а аналитик — модели системы. RUP позволяет определить когда, кому и какой артефакт необходимо создать, доработать или использовать.
Одним из интереснейших классов артефактов проекта являются модели, которые позволяют разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем. Каждая модель является самодостаточным взглядом на разрабатываемую систему и предназначена как для очерчивания проблем, так и для предложения решения. Самодостаточность моделей означает, что аналитик или разработчик может из конкретной модели почерпнуть всю необходимую ему информацию, не обращаясь к другим источникам.
Модели позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще до вкладывания значительных средств в разработку, позволяют увидеть ее глазами будущих пользователей снаружи и разработчиков изнутри еще до создания первой строки исходного кода. Большинство моделей представляются UML диаграммами.
Применение UML экономит ресурсы разработки, поскольку позволяет получить представление о системе быстрее, чем при создании макетов и прототипов, затратив на это несравнимо меньше ресурсов.
Диаграммы позволяет легче общаться членам проекта между собой, и, что особенно ценно, вовлекают в процесс конечных пользователей системы. Моделирование позволяет уменьшить риски проекта, поскольку программистам всегда легче делать то, что ясно и понятно, чем идти к неопределенному результату.