tehnologia (1018792), страница 28
Текст из файла (страница 28)
Это вызвано двумяпричинами:• диаграммы потоков данных более детально по сравнению с функциональнымидиаграммами отображают специфику многочисленных в настоящее время информационныхсистем: не требуют строгой типизации обрабатываемой информации, предусматриваютвозможность хранения данных,конкретизируют взаимодействие с внешним миром, предусматривают получениекомплексной модели программного обеспечения и т. п.;• разработан метод построения проектных спецификаций (структурных карт Джексонаили Костантайна) по диаграммам потоков данных, что позволяет автоматически создаватьтакие спецификации.В табл.
5.3 представлены данные о моделях, поддерживающих соответствующий пакет, ав табл. 5.4 - нотации представления соответствующей информации.Несмотря на то, что последнее время все большее распространение получают объектноориентированные средства разработки программного обеспечения, структурныеметодологии продолжают совершенствовать. Их усТаблица 5.3НазваниеBPWinФирмаLogic WorksФункции+Данные-CASE АналитикCASE/4/0DatabaseDesignerЭйтексMicroTOOLOracle++-+++++-Design/IDEFDesigner/2000EasyCASEERWinI-CASE YourdanProkit*WORKMeta SoftwareOracleEvergreen CASELogic WorksCAYENNEBENCHMDIS+++++++++++++-S-DesignerSybase/Powersoft++-CSA+++Visible Systems++_SILVERRunVisible AnalystWorkbenchСобытия-165Таблица 5.4НазваниеНотация DFD СпецификацииCASE АналитикГейн-СарсонCASE/4/0Designer/2000I-CASE YourdanEasyCASEProkit*WORKBENCHS-DesignerSILVERRunVisible AnalystWORKBENCHСтруктурныйязыкПоведениеСтруктурные карты3GLУправляющие потокиУордМеллор(c STD)УордМеллор(c STD)STDГейн-СарсонГейнСарсон,Иордан--Константайн--Константайнпроизвольная-Управляющие потоки—ГейнСарсон,Иордан--КонстантайнИордан(расширенная)Гейн-СарсонГейнСарсон,ИорданИорданСтруктурныйязыкДжексонДжексонКонстантайнКонстантайнпешно применяют при разработке многих программных продуктов, например, дляуточнения требований к системам, основной частью которых являются базы данных, оченьчасто используют диаграммы потоков данных.Контрольные вопросы и задания1.
Что понимают под структурной и функциональной схемами программногообеспечения? В каких случаях их применяют? Чем отличаются структурные и функциональные схемы программного обеспечения с различной архитектурой?2. На каких свойствах программных систем основан метод пошаговой детализации?Почему с его применением получают только структурные алгоритмы? В чем, по-вашему,заключается основная сложность данного метода?3. Как используется метод пошаговой детализации при разработке алгоритмов иструктуры программного обеспечения?4. Используя метод пошаговой детализации, разработайте алгоритм сложения чисел (n,m < 1000), записанных римскими цифрами: I - 1; II - 2; III - 3; IV - 4; V - 5; VI-6; IX-9; X10; L-50; С-100; D-500; М-1000.5.
Для чего строят структурные карты Константайна? Постройте структурные картыКонстантайна для задания 4. Чем структурные карты Джексона отличаются от структурныхкарт Константайна?7. Что положено в основу методик Джексона и Варнье-Орра? Чем различаются данныеметодики?8. Какие вопросы решают при проектировании структур данных? Какие характеристикипроектируемых структур при этом учитывают? Предложите несколько вариантов структурданных для программы задания 3. Какая из них является лучшей и почему?9.
Для каких разработок целесообразно использовать структурные методологии?1666. АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕСПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯПРИ ОБЪЕКТНОМ ПОДХОДЕМодели разрабатываемого программного обеспечения при объектном подходе основаны на предметах и явлениях реального мира. В основе этих моделей также лежитописание требуемого поведения разрабатываемого программного обеспечения, т. е. егофункциональности, но это поведение связывается с состояниями элементов (объектов)конкретной предметной области.Таким образом, на этапе анализа ставятся две задачи:• уточнить требуемое поведение разрабатываемого программного обеспечения;• разработать концептуальную модель его предметной области с точки зрения поставленных задач.6.1.
UML - стандартный язык описания разработки программныхпродуктов с использованием объектного подходаВ основе объектного подхода к разработке программного обеспечения лежит объектнаядекомпозиция, т. е. представление разрабатываемого программного обеспечения в видесовокупности объектов, в процессе взаимодействия которых через передачу сообщений ипроисходит выполнение требуемых функций (рис. 6.1).Однако при объектном подходе так же, как при структурном подходе, сразу можновыполнить декомпозицию только очень простого программного обеспечения. Поэтому назаре эпохи объектно-ориентированного программирования были предложены различныеметоды анализа и проектирования программного обеспечения в рамках объектного подхода,использующие различные модели и нотации.
Спорить о достоинствах и недостатках этихметодов и моделей можно было бесконечно. Эта ситуация получила название «войныметодов».Конец «войне методов» положило появление в 1995 г. первой версии языка UML(Unified Modeling Language - унифицированный язык моделирования - см. приложение),который в настоящее время фактически признан167стандартным средством описания проектов, создаваемых с использованием объектноориентированного подхода. Его создателями являются ведущие специалисты в этой области:Гради Буч, Ивар Якобсон и Джеймс Рамбо, которые использовали в своем языке все лучшее,что появилось в подходах этих авторов во время «войны методов».Спецификация разрабатываемого программного обеспечения при использовании UMLобъединяет несколько моделей: использования, логическую, реализации, процессов,развертывания (рис. 6.2).Модель использования представляет собой описание функциональности программногообеспечения с точки зрения пользователя.Логическая модель описывает ключевые абстракции программного обеспечения(классы, интерфейсы и т.
п.), т. е. средства, обеспечивающие требуемую функциональность.Модель реализации определяет реальную организацию программных модулей в средеразработки.Модель процессов отображает организацию вычислений и оперирует понятиями«процессы» и «нити». Она позволяет оценить производительность, масштабируемость инадежность программного обеспечения.И, наконец, модель развертывания показывает особенности размещения программныхкомпонентов на конкретном оборудовании.Таким образом, каждая из указанных моделей характеризует определенный аспектпроектируемой системы, а все они вместе составляют относительно полную модельразрабатываемого программного обеспечения.Всего UML предлагает девять дополняющих друг друга диаграмм, входящих вразличные модели:168• диаграммы вариантов использования (см.
§ 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фактически стал стандартом описания подобных разработок.1696.2.
Определение «вариантов использования»Разработку спецификаций программного обеспечения начинают с анализа требований кфункциональности, указанных в техническом задании. В процессе анализа выявляютвнешних пользователей разрабатываемого программного обеспечения и перечень отдельныхаспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспектыповедения программного обеспечения были названы «вариантами использования» или«прецедентами» (use cases).Примечание. Варианты использования основаны на неформальном описании сценариевфункционирования проектируемых программных систем, применяемом многими разработчиками программного обеспечения в 1980-1990 голах.Вариант использования представляет собой характерную процедуру примененияразрабатываемой системы конкретным действующим лицом, в качестве которого могутвыступать не только люди, но и другие системы или устройства.Не следует путать вариант использования с конкретными операциями будущей системы.Каждый вариант использования связан с некоторой целью, имеющей самостоятельноезначение, например для текстового редактора Формирование оглавления - это вариантиспользования, а Связывание заголовков со специальными стилями - операция, которуюнеобходимо выполнить, чтобы стало возможно автоматическое построение оглавления.В зависимости от цели выполнения конкретной процедуры различают следующиеварианты использования:• основные - обеспечивают требуемую функциональность разрабатываемогопрограммного обеспечения:• вспомогательныеобеспечиваютвыполнениенеобходимыхнастроексистемы и ее обслуживание (например, архивирование информации и т.
п.):• дополнительные - обеспечивают дополнительные удобства для пользователя (какправило, реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов нипри разработке, ни при эксплуатации).Вариант использования можно описать кратко или подробно. Краткая форма описаниясодержит: название варианта использования, его цель, действующих лиц, тип вариантаиспользования (основная, второстепенная или дополнительная) и его краткое описание.Краткое описание варианта использования Выполнение задания системы решениякомбинаторно-оптимизационных задач можно представить в следующем виде:170Название вариантаЦельДействующие лицаКраткое описаниеТип вариантаВыполнение заданияПолучение результатов решения задачиПользовательРешение задачи предполагает выбор задачи, выборалгоритма, задание данных и получениерезультатов решения.ОсновнойОсновные варианты использования обычно описывают подробно, стараясь отразитьособенности предметной области разрабатываемого программного обеспечения.
Подробнаяформа, кроме указанной выше информации, включает описание типичного хода событий ивозможных альтернатив. Типичный ход событий представляют в виде диалога междупользователями и системой, последовательно нумеруя события. Если пользователь можетвыбирать варианты, то их описывают в отдельных таблицах. Также отдельно приводятальтернативы, связанные с нарушением типичного хода событий. Ниже представленоподробное описание варианта использования Выполнение задания:Вариант использования Выполнение задания Типичный ходсобытийДействия исполнителя/.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
