Контрольные вопросы и задания

1. Что понимают под структурной и функциональной схемами программного обеспечения? В каких случаях их применяют? Чем отличаются структурные и функ­циональные схемы программного обеспечения с различной архитектурой?

2. На каких свойствах программных систем основан метод пошаговой детализации? Почему с его применением получают только структурные алгоритмы? В чем, по-вашему, заключается основная сложность данного метода?

3. Как используется метод пошаговой детализации при разработке алгоритмов и структуры программного обеспечения?

4. Используя метод пошаговой детализации, разработайте алгоритм сложения чисел (n, m < 1000), записанных римскими цифрами: I - 1; II - 2; III - 3; IV - 4; V - 5; VI-6; IX-9; X- 10; L-50; С-100; D-500; М-1000.

5. Для чего строят структурные карты Константайна? Постройте структурные карты Константайна для задания 4. Чем структурные карты Джексона отличаются от структурных карт Константайна?

7. Что положено в основу методик Джексона и Варнье-Орра? Чем различаются данные методики?

8. Какие вопросы решают при проектировании структур данных? Какие харак­теристики проектируемых структур при этом учитывают? Предложите несколько ва­риантов структур данных для программы задания 3. Какая из них является лучшей и почему?

9. Для каких разработок целесообразно использовать структурные методоло­гии?

6. Анализ требований и определение спецификаций программного обеспечения при объектном подходе

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

Таким образом, на этапе анализа ставятся две задачи:

• уточнить требуемое поведение разрабатываемого программного обеспечения;

• разработать концептуальную модель его предметной области с точки зрения по­ставленных задач.

6.1. UML - стандартный язык описания разработки программных продуктов с использованием объектного подхода

В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, т. е. представление разрабатываемого про­граммного обеспечения в виде совокупности объектов, в процессе взаимо­действия которых через передачу сообщений и происходит выполнение тре­буемых функций (рис. 6.1).

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

Конец «войне методов» положило появление в 1995 г. первой версии языка UML (Unified Modeling Language - унифицированный язык моделиро­вания - см. приложение), который в настоящее время фактически признан

стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создателями являются ведущие специалисты в этой области: Гради Буч, Ивар Якобсон и Джеймс Рамбо, ко­торые использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов».

Спецификация разрабатываемого программного обеспечения при ис­пользовании UML объединяет несколько моделей: использования, логичес­кую, реализации, процессов, развертывания (рис. 6.2).

Модель использования представляет собой описание функциональности программного обеспечения с точки зрения пользователя.

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

Модель реализации определяет реальную организацию программных модулей в среде разработки.

Модель процессов отображает организацию вычислений и оперирует по­нятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность программного обеспечения.

И, наконец, модель развертывания показывает особенности размещения программных компонентов на конкретном оборудовании.

Таким образом, каждая из указанных моделей характеризует определен­ный аспект проектируемой системы, а все они вместе составляют относи­тельно полную модель разрабатываемого программного обеспечения.

Всего UML предлагает девять дополняющих друг друга диаграмм, вхо­дящих в различные модели:

• диаграммы вариантов использования (см. § 6.2);

• диаграммы классов (см. § 6.3, 7.3 и 7.4);

• диаграммы пакетов (см. § 7.1);

• диаграммы последовательностей действий (см. § 6.4 и 7.4);

• диаграммы кооперации (см. § 7.3);

• диаграммы деятельностей (см. § 6.5 и 7.4);

• диаграммы состояний объектов (см. § 7.4);

• диаграммы компонентов (см. § 7.5);

• диаграммы размещения (см. § 7.6).

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

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

UML и предлагаемая теми же авторами методика Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм UML можно построить также средствами про­граммы Microsoft Visual Modeler и других CASE-средств. По данным «USA Today» в настоящее время 49 из 50-ти ведущих компьютерных компаний ис­пользуют UML при разработке программного обеспечения с использованием объектного подхода, что и позволяет говорить о том, что сегодня UML фак­тически стал стандартом описания подобных разработок.