РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. - презентация

1 РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

2 ЛЕКЦИЯ 4 ТЕМА: МЕТОДЫ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПО

3 ПОНЯТИЯ МЕТОДА И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПО Метод проектирования ПО представляет собой организованную совокупность процессов создания ряда моделей, которые описывают различные аспекты разрабатываемой системы с использованием четко определенной нотации. На более формальном уровне метод определяется как совокупность составляющих, в том числе: концепций (теоретических основ), нотаций и процедур. В качестве концепций (теоретических основ) могут выступать структурный и объектно- ориентированный подходы.

4 В качестве нотаций (систем условных обозначений), используемых для построения моделей статической структуры и динамики поведения проектируемой системы, обычно используются графические диаграммы.

5 Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО. Технология проектирования определяется как совокупность технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ПО.

6 Требования к технологии Современная технология проектирования должна обеспечивать: 1. Соответствие стандарту ISO / IEC 12207: Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время. 3. Возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3-7 чел.), с последующей интеграцией составных частей.

7 4. Минимальное время получения работоспособного ПО ЭИС. Речь идет не о сроках готовности всей ЭИС, а о сроках реализации отдельных подсистем. Практика показывает, что даже при наличии полностью завершенного проекта внедрение ЭИС идет последовательно, по отдельным подсистемам. 5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования). 6. Поддержка комплексом согласованных CASE- средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО.

8 Реальное применение любой технологии проектирования ПО ЭИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся: 1. Стандарт проектирования. 2. Стандарт оформления проектной документации. 3. Стандарт интерфейса конечного пользователя с системой.

9 Ресурсы для ЖЦ сложных ПС Общее понятие - доступные ресурсы жизненного цикла ПС - включает в себя финансовые, временные, кадровые и аппаратурные ограничения, в условиях которых происходит создание и совершенствование ПО.

10 Одной из основных задач при системном проектировании ПС является экономический анализ и определение необходимых ресурсов для создания и для всего ЖЦ программных средств в соответствии с требованиями контракта и ТЗ.

11 Наиболее общим видом ресурсов, используемых в ЖЦ ПС, являются допустимые финансово-экономические затраты или эквивалентные им величины трудоемкости соответствующих работ.

12 Время разработки, или допустимая длительность разработки определенных версий ПС является невосполнимым ограниченным ресурсом реальных проектов.

13 Кадры специалистов можно оценивать численностью, а также тематической и технологической квалификацией, которые всегда ограничены.

14 Вычислительные ресурсы, доступные разработчикам ПС объектных и технологических ЭВМ являются одним из важнейших факторов, определяющим достижимое качество сложных ПС.

15 Обобщенными ресурсами проекта ПС являются: доступные по стоимости совокупные трудовые, временные и материальные затраты, необходимые для приобретения, создания, модификации и эксплуатации компонентов и всего комплекса программ.

16 В таблице представлен вариант относительного распределения затрат ресурсов по этапам работ для сложных встроенных ПС реального времени, который можно использовать как базу для приближенных оценок.

17

18 На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие которых обусловлено разными способами декомпозиции систем. Первый подход - функционально-модульный, или структурный. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй подход - объектно-ориентированный, использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.

19 СТРУКТУРНЫЙ ПОДХОД: МЕТОДЫ SADT И DFD Стандарты семейства IDEF IDEF0 - стандарт функционального моделирования IDEF1 - стандарт информационного моделирования ("ER- диаграммы"). IDEF3 - определяет методологию моделирования процессов (построения технологических карт).

20 В структурном подходе используют различные виды моделей (диаграмм) и методов; наиболее распространенные среди них: DFD (Data Flow Diagrams) - диаграммы потоков данных; SADT (Structured Analysis and Design Technique) – метод структурного анализа и проектирования - модели и соответствующие функциональные диаграммы (лежит в основе стандарта IDEF0) ; ERD (Entity-Relationship Diagrams) - диаграммы "сущность - связь". Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

21 Метод функционального моделирования SADT Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой- либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Её представляют в виде блоков и дуг SADT, которые составляются в диаграммы.

22 Основная идея этой методологии - построение древовидной функциональной модели предприятия.

23 На рисунке - дерево узлов функциональной модели.

24 Каждый узел соответствует отдельному фрагменту описания - диаграмме. Модель представляет собой совокупность иерархически выстроенных диаграмм, каждая из которых является описанием какой-либо функции или работы.

25

26 Состав функциональной модели Результатом применения метода SADT является модель, состоящая из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно.

27 Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) - справа. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей снизу.

28 Общее представление

29 Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.

30 Иерархия диаграмм

31

32 Соответствие интерфейсных дуг родительской (а) и детальной (б) диаграмм

33 Пример обратной связи

34

35 Иерархия диаграмм

36

37 МОДЕЛИРОВАНИЕ ПОТОКОВ ДАННЫХ (ПРОЦЕССОВ) Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

38 В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень, на котором процессы становятся элементарными и детализировать их далее невозможно.

39 Основными компонентами диаграмм потоков данных являются: внешние сущности; системы и подсистемы;

40 процессы; накопители данных; потоки данных.

41 Поток данных между процессом и внешней сущностью

42 Моделирование данных Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), нотация которых впервые была введена Питером Ченом в 1976 г.

43 Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области. Каждая сущность должна обладать уникальным идентификатором. Каждая сущность должна обладать некоторыми свойствами: иметь уникальное имя; обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь; обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. Каждая сущность может обладать любым количеством связей с другими сущностями модели.

44 Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

45 Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Экземпляр атрибута - это определенная характеристика определенного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность- связь" атрибуты ассоциируются с конкретными сущностями.

46 Степень и обязательность связи

47 Отображение связи "продавец - контракт"

48 Диаграмма "сущность-связь" без атрибутов

49 Диаграмма "сущность – связь" с атрибутами

50 Объектно-ориентированный подход Унифицированный язык моделирования (UML) является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем.

51 Диаграмма классов, показывающая Агрегацию между двумя классами Диаграмма прецедентов для упрощенной модели работы ресторана

52 ИТ И СРЕДСТВА АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИС

53 Компонентная архитектура Опыт разработки "готовых" ИС позволил сформировать новый подход к созданию больших ИС систем, основанный на "сборке" систем из программных "компонент" различных фирм- производителей.

54 Краткий перечень программных продуктов и производителей

55 Фирма Rational Software - безусловный лидер в области объектно-ориентированного анализа и проектирования информационных систем с компонентной архитектурой.

56 Rational Unified Process (RUP) методология разработки программного обеспечения, созданная компанией Rational Software. Суть работы в рамках Рационального Унифицированного Процесса - это создание и сопровождение моделей.

57 Эта методология, основана на использовании унифицированного языка моделирования (UML - Unified Modeling Language в настоящее время принят в качестве стандарта ), поддержана целым спектром инструментальных программных средств: визуального моделирования, совместной разработки, автоматизированного тестирования, документирования, охватывающих ЖЦ создания ПС..

58 Поддерживаются основные языки программирования С++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки - MS Visual Studio, Delphi, PowerBuilder.

59 Rational Rose - хорошо сбалансированный программный продукт с удобным интерфейсом и набором инструментов моделирования, ориентированным как на разработчиков программных систем, так и на бизнес- и системных аналитиков. На базе Rational Rose был создан Visual Modeler - средство визуального проектирования, включенное в состав среды разработки Microsoft Visual Studio (начиная с версии 6.0).

60 Широкую известность и признание у аналитиков всего мира получили CASE- средства BPWIN и ERWIN, спектр продуктов компании Computer Associated.

61 Пакеты, предназначенные для визуального моделирования объектно- ориентированных программных систем, поддерживающих стандарты UML - Paradigm Plus (программный продукт фирмы Computer Associated) и SELECT (SELECT Software).

62 Средство визуального моделирования Select ориентировано в основном, на аналитиков, он может использоваться и разработчиками программных систем. Этот продукт, также, поддерживает UML и компонентную технологию проектирования программных систем.