ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 933
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
– номер покупателя, N
д
– номер детали,
С
д
- количество деталей. Результатами выполнения команды являются сообщения на дисплей менеджера OM = L (N
п
, N
д
, С
д
) и преобразова- ния системы P = L (N
п
, N
д
, С
д
). Эта таблица решений, сопровождае-
243 мая небольшим описанием, является прекрасной внешней специфика- цией команды.
Рис. 5.36. Пример таблицы решений
Таблицы решений представляют собой наглядный и строгий способ отражения отношений между входными и выходными данными. Чтобы оценить достоинства такой таблицы, можно попробовать выразить ин- формацию, представленную в таблице обычным словесным описанием.
Таблицы решений уникальны по своим достоинствам в качестве средст- ва общения между разработчиком внешнего проекта, пользователем и программистом. С одной стороны, в них легко может разобраться поль- зователь, просматривая внешние спецификации. С другой стороны, они служат идеальными исходными данными для программиста, разрабаты- вающего логику программы. Кроме того, существуют методы проверки таблиц решений на неполноту, избыточность и неоднозначность. К со- жалению, таблицы решений по необъяснимым причинам редко исполь- зуются на практике.
Для любой сложной функции пользователя задача об установлении соотношений между выводами, системными преобразованиями и вво- дами способом причины и следствия – не тривиальная работа. В целом внешние спецификации описывают каждый возможный ввод в систему, как правильный, так и неправильный и реакцию системы на каждый из
244 вводов. Внешние спецификации должны точно и полно описывать внешние интерфейсы (сопряжения) при минимальных предположениях о внутреннем устройстве системы.
5.4.4. Проверка правильности внешних спецификаций
Рассмотренные до сих пор вопросы касались интерфейса “пользова- тель – программная система”. Дальнейшие действия по проектированию должны быть сосредоточены на разработке архитектуры системы. По этой причине и вследствие трудностей, обсуждавшихся при разработке качественной внешней спецификации, проверка полноты и точности внешней спецификации проекта является крайне важной.
На этом этапе должна быть занята активная позиция в отношении ошибок. Цель всякой проверки правильности или тестирования – найти как можно больше ошибок, а не показать, что спецификации не содер- жат ошибок. Очень важно понимать это тонкое различие [18]. Необхо- димо проверять спецификации, когда они находятся в черновой форме, так как может возникнуть психологический барьер при проверке доку- мента, имеющего “законченную” печатную форму.
В [18] предлагается шесть методов проверки правильности, приме- няемых к внешним спецификациям. Эти методы не исключают друг друга и рекомендуются для последовательного применения.
1.
Контроль по правилу “n плюс – минус один” и групповой кон-
троль специалистами. Специалисты уровня n – 1 ищут ошибки перево- да, а специалисты уровня n + 1 которые могут привести к ошибкам в последующих процессах. Спецификации должны сверяться с целями путем рассмотрения каждой из них и последующего определения адек- ватности отражения цели в спецификациях. Подробную внешнюю спе- цификацию должны оценивать люди, отвечающие за разработку перво- начального внешнего проекта, проектирование структуры программ и баз данных и люди, отвечающие за подготовку документации пользова- теля.
2.
Контроль со стороны пользователя. Крайне важно получить обзор и одобрение первоначальной и подробной спецификации со сто- роны организации пользователя. Если разрабатывается проект, незави- симый от пользователя, то контрольная группа создается из специали- стов проектирующей организации с теми же целями. В ее задачу будет входить оценка спецификаций с точки зрения пользователя.
3.
Контроль по таблицам решений. Если в спецификациях ис- пользуются таблицы решений (а должно быть именно так по [М]), тогда для проверки на полноту (поиск всех пропущенных условий) и неодно- значность (идентичные условия приводят к разным выходным данным или преобразованиям) могут быть применены “механические” методы.
4.
Ручная имитация (прокрутка спецификаций). Эффективный прием проверки детальных внешних спецификаций – подготовка тестов и последующее использование детальных спецификаций для имитации поведения системы. Этот процесс оценки проектного документа мето-
245 дом его “выполнения” на тестовых данных часто называется сквозным контролем.
Для проверки отдельных внешних функций должны быть выполне- ны следующие действия. Кто-то (не автор спецификации) должен сна- чала построить “тесты на бумаге” для этой функции, т.е. список кон- кретных входных данных (допустимых и недопустимых). Вместе с ав- тором спецификаций он потом имитирует ввод этих данных в систему, используя спецификации как описание поведения системы. Всякий раз, когда оказывается, что спецификация описывает выходные данные или преобразование для какого-либо набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка. Эту последо- вательность проверки внешних функций можно представить следующей схемой (рис. 5.37).
Рис. 5.37. Последовательность проверки внешних функций
Прежде чем начать сквозной контроль, обычно бывает необходимо установить исходное состояние системы, например, описать начальные состояния всех файлов, а затем обновлять это состояние по мере ис- пользования тестов. Подобным образом можно тестировать и комбина- ции функций, строя тесты, представляющие собой сложные сценарии.
246
Важно отметить, что цель всякого такого сеанса сквозного контроля
- обнаруживать ошибки, но не исправлять их с лету. Исправление оши- бок нужно отложить до тех пор, пока не будут обнаружены по возмож- ности все ошибки. Также важно, чтобы строил тесты и интерпретировал спецификации кто-то другой, не автор, так как последний будет “читать между строк”.
5.
Имитация за терминалом. В этом случае вместо того чтобы просто читать список тестов, как при ручной имитации, один из прове- ряющих садится за терминал (персональный компьютер), вводит тесто- вые данные и получает результаты, так, как если бы терминал был под- ключен к настоящей программной системе (рис. 5.38).
Для имитации еще один участник проверки, вооружившись специ- фикациями, садится за другой компьютер. Небольшая программа, спе- циально разработанная для такой проверки, связывает эти компьютеры, передавая входные данные с терминала “пользователя” на терминал
“имитатора”, а выходные данные – обратно по командам “имитатора”
(рис. 5.38).
Считается, что этот метод очень ценен, поскольку он помогает обна- ружить в спецификациях все недочеты по части психологических фак- торов. В процессе внешнего проектирования он особенно полезен для изучения альтернативных вариантов решения проблемы психологиче- ских факторов.
Рис. 5.38.
6.
Функциональные диаграммы. Этот метод заимствован из про- ектирования переключательных схем и позволяет проектировщику представить спецификации булевской логической диаграммой (функ- циональной диаграммой), которая затем преобразуется в таблицу реше- ний.
247
Литература к главе 5
1.
IBM
Rational
Software
Modeler. http://www.interface.ru/fset.asp?Url=/rational/RSM.htm
2.
SWEBOK http://ru.wikipedia.org/wiki/SWEBOK
3.
UML. http://ru.wikipedia.org/wiki/UML
4.
Амсден Д. Фиксация требований с помощью инструментов
Business Motivation Model, IBM Rational RequisitePro и IBM Rational
Software
Modeler. http://www.ibm.com/developerworks/ru/library/r-
0401_amsden/index.html#author1 5.
Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. 2-е изд. – СПб.: Питер, 2006. – 575 с.
6.
Буч Г., Рамбо Д., Якобсон И. Язык UML, Руководство пользова- теля. 2-е изд. : Пер. с англ. Мухин Н. – М.: ДМК Пресс, 2007. – 496 с.
7.
Вендров А.М. Проектирование программного обеспечения эко- номических информационных систем. Учебник для вузов. 2-е изд. – М.:
Финансы и статистика, 2006 8.
Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разра- ботки программного обеспечения: учебное пособие / под ред. Л.Г. Гага- риной. – М.: ИД «ФОРУМ»: ИНФРА-М., 2008. – 400 с.
9.
Гантер Р. Методы управления проектированием программного обеспечения: Пер. с англ. – М.: Мир, 1981. – 392 с.
10. Гибс Д. Управление проектами с помощью IBM Rational Unified
Process. Практические уроки. Пер. с англ. – М.: КУДИЦ-ПРЕСС. – 2007.
– 304 с.
11. Диаграмма потоков данных (DFD). Графический язык диаграм- мы. http://e-educ.ru/bd14.html
12. Зиглер К.. Методы проектирования программных систем: Пер. с англ. – М .: Мир, 1985. – 328 с.
13. Калянов Г.Н. CASE: структурный системный анализ (автомати- зация и применение). М.: ЛОРИ. 1996 14. Кватрани Т., Палистрает Д. Визуальное моделирование с помо- щью IBM Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-
ПРЕСС. – 2007. – 192 с.
15. Классификация видов моделей. http://www.uml3.ru/index.php?option=com_content&view=article&id=36:ki nd-of-models&catid=3:software-design
16. Колин Ю. Применение Rational Software Architect в разработке, управляемой моделями: Часть 1. Обзор парадигмы разработок, управ- ляемых моделями с шаблонами. http://www.ibm.com/developerworks/ru/library/1121_yu/index.html?S_TAC
T=105AGX63&S_CMP=NWLTR&ca=dnn-rut2405 17. Ларман К. Применение UML 2.0 и шаблонов проектирования.
3-е издание. Вильямс. 2006, 736 с.
18. Майерс Г. Надежность программного обеспечения: Пер. с англ.
– М .: Мир, 1980. – 360 с.
248 19. Метод функционального моделирования
SADT. http://dic.academic.ru/dic.nsf/politology/1766/%D0%9C%D0%B5%D1%82
%D0%BE%D0%B4 20. Методологии функционального моделирования. http://www.mstu.edu.ru/study/materials/zelenkov/ch_5_3.html
21. Новичков А., Карабанова Г. Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятель- ности с использованием
RSA.
–
http://www.ibm.com/developerworks/ru/library/r-rsa/index.html#author1 22. Общий обзор и концепция разработки, управляемой моделями. http://www.ibm.com/developerworks/ru/library/mdd/ch1/ch1.html#author1 23. Описание подключаемого модуля RUP для управляемой моде- лями разработки систем, http://www.interface.ru/home.asp?artId=21714 24. Основы
Программной
Инженерии
(по
SWEBOK). http://swebok.sorlik.ru/1_software_requirements.html
25. Полис Г., Огастин Л., Лоу К., Мадхар Д. Разработка программ- ных проектов на основе Rational Unnified Process (RUP). – М.: ООО
«Бином-Пресс», 2009. – 256 с.
26. Применение Rational Software Architect в разработке, управляе- мой моделями: Часть 1. Обзор парадигмы разработок, управляемых мо- делями с шаблонами. http://www.cmcons.com/articles/drugie_stati/primenenie_rational_software_
architect_v_razrabotke_upravljaemojj_modeljami_chast_1_obzor_paradigmy
_razrabotok_upravljaemykh_modeljami_s_shablonami/
27. Технология программирования и создание программных про- дуктов. http://www.cs.nuos.edu.ua/textbooks/SWDevelop/SaprSW1/index.htm
28. Турский В. Методология программирования: пер. с англ. – М.:
Мир, 1981. – 264 с.
29. Халл Э., Джексон К., Дик Д. Разработка и управление требова- ниями. Практическое руководство пользователя. Telelogic, 2005 30.
Химонин Ю. Сбор и анализ требований к программному про- дукту. http://www.pmi.ru/profes/Software_Requir http://ru.wikipedia.org/wiki/UML ements_Khimonin.pdf
249
Глава 6
ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ
ПРОГРАММНЫХ СИСТЕМ
6.1. Методология проектирования
По мнению авторов фундаментальных монографий [19, 20, 24, 41] всякую методологию проектирования программных систем можно представить набором желаемых характеристик результата проектирова- ния и руководящих принципов процесса проектирования. Выше уже отмечалось, что формирование желательных целей проектирования сво- дится к определению требований и целей проектирования. Что касается принципов проектирования, то они определяют сам процесс проектиро- вания и методы проектирования.
Принципы проектирования – это обычно независимые от предмет- ной области стратегии, положенные в основу проектирования. Однако есть принципы, относящиеся специально к проектированию программ- ных (и других) систем для компьютеров.
Методы проектирования – это обычно зависимые от области при- ложения (предметной области) тактические средства, определяющие те или иные этапы процесса проектирования. Сам процесс проектирования подразумевает принятие решения о форме и содержании предмета про- ектирования. Метод должен помогать разработчику в упорядочении принимаемых решений. Методы проектирования опираются, в конеч- ном счете, на свойства мыслительного процесса разработчика и обеспе- чивают определенные алгоритмы принятия решений.
Кроме того, метод проектирования должен помочь разработчику сконцентрировать свое внимание на определенных аспектах или частях проектируемой системы, взятых по отдельности. Это особенно важно при разработке больших программных систем (например, операцион- ных систем), где сложность системы заранее исключает всякую воз- можность охватить сразу все детали. Тем не менее разработчик должен точно понимать общие характеристики всей системы, по мере того как они проясняются во время проектирования.
Основные принципы (стратегии) процесса проектирования, дающие разработчику возможность справиться со сложностью системы – это
декомпозиция и абстракция.
Базовая парадигма (давно известная) в подходе к решению большой задачи – ”разделяй и властвуй”. К сожалению, буквальное следование этому принципу по-прежнему предполагает долгий путь к решению задачи. Самым важным является то, каким образом осуществляется это разделение. Понятно, что по мере возрастания размера программной системы монолитная структура становится неудобной, поскольку ее текст труден для понимания (никто не может понять миллионы строк современных операционных систем). Поэтому программа должна быть
250 разбита на ряд небольших программ (модулей), которые сообща выпол- няют требуемую функцию.
Корректность такого разбиения (декомпозиции) становится все бо- лее важной по мере роста программной системы. Это обусловлено сле- дующими причинами:
1. В процесс разработки программной системы вовлекается все большее количество людей. Регулярные контакты между исполнителя- ми снижают вероятность разногласий, касающихся того, кто и что дол- жен делать, и уменьшают возможность серьезных последствий, возни- кающих в подобных ситуациях.
2. Полезное время жизни программы (рабочая стадия) начинается с момента передачи потребителю. Однако работа над программой не за- канчивается. Работа по модификации и сопровождению программы мо- жет потребовать больше времени, чем время, потраченное на ее разра- ботку. При этом неразумно начинать работу с полной переделки про- граммы. Лучше внести изменения в уже существующую структуру программы. Поэтому важно, чтобы структура программы допускала возможность такой модификации. Для этого необходимо, чтобы части программы были независимы друг от друга с тем, чтобы изменение в одной части могло быть сделано без изменений других частей.
3. Со временем модификация программ, время жизни которых дос- таточно велико, выполняется уже не разработчиками программ, Все эти факторы предполагают структурирование программ таким образом, чтобы они были легко понимаемыми.
Таким образом, большие программные системы целесообразно раз- рабатывать путем декомпозиции задачи.
Декомпозиция является полезным и экономящим время способом решения задач в самых различных областях. Однако это не панацея, и при неграмотном использовании может принести массу неприятностей.
Часто большие или плохо понимаемые задачи поддаются декомпозиции с большим трудом. К числу распространенных проблем относится си- туация, при которой создание отдельных компонентов, способных ре- шить соответствующие задачи, не приводит к тому, что объединение компонентов позволяет решить исходную задачу. Это является одной из причин, по которой интеграция системы оказывается затруднительной.
К тому же нужно помнить и тот факт, что разбиение любой задачи на подзадачи (это наиболее ярко проявляется в математических задачах) и оптимальное решение этих подзадач не дает оптимального решения общей задачи.
Абстракция – эффективный способ декомпозиции, осуществляемый посредством изменения списка детализации. Когда разработчик абстра- гируется от проблемы, он предполагает игнорирование ряда подробно- стей с тем, чтобы свести задачу к более простой. Задачи абстрагирова- ния и последующей декомпозиции типичны для процесса создания про- граммной системы: декомпозиция используется для разбиения про- граммы на компоненты (модули), которые могут быть затем объедине- ны, позволив решить основную задачу; абстрагирование предполагает
д
– номер детали,
С
д
- количество деталей. Результатами выполнения команды являются сообщения на дисплей менеджера OM = L (N
п
, N
д
, С
д
) и преобразова- ния системы P = L (N
п
, N
д
, С
д
). Эта таблица решений, сопровождае-
243 мая небольшим описанием, является прекрасной внешней специфика- цией команды.
Рис. 5.36. Пример таблицы решений
Таблицы решений представляют собой наглядный и строгий способ отражения отношений между входными и выходными данными. Чтобы оценить достоинства такой таблицы, можно попробовать выразить ин- формацию, представленную в таблице обычным словесным описанием.
Таблицы решений уникальны по своим достоинствам в качестве средст- ва общения между разработчиком внешнего проекта, пользователем и программистом. С одной стороны, в них легко может разобраться поль- зователь, просматривая внешние спецификации. С другой стороны, они служат идеальными исходными данными для программиста, разрабаты- вающего логику программы. Кроме того, существуют методы проверки таблиц решений на неполноту, избыточность и неоднозначность. К со- жалению, таблицы решений по необъяснимым причинам редко исполь- зуются на практике.
Для любой сложной функции пользователя задача об установлении соотношений между выводами, системными преобразованиями и вво- дами способом причины и следствия – не тривиальная работа. В целом внешние спецификации описывают каждый возможный ввод в систему, как правильный, так и неправильный и реакцию системы на каждый из
244 вводов. Внешние спецификации должны точно и полно описывать внешние интерфейсы (сопряжения) при минимальных предположениях о внутреннем устройстве системы.
5.4.4. Проверка правильности внешних спецификаций
Рассмотренные до сих пор вопросы касались интерфейса “пользова- тель – программная система”. Дальнейшие действия по проектированию должны быть сосредоточены на разработке архитектуры системы. По этой причине и вследствие трудностей, обсуждавшихся при разработке качественной внешней спецификации, проверка полноты и точности внешней спецификации проекта является крайне важной.
На этом этапе должна быть занята активная позиция в отношении ошибок. Цель всякой проверки правильности или тестирования – найти как можно больше ошибок, а не показать, что спецификации не содер- жат ошибок. Очень важно понимать это тонкое различие [18]. Необхо- димо проверять спецификации, когда они находятся в черновой форме, так как может возникнуть психологический барьер при проверке доку- мента, имеющего “законченную” печатную форму.
В [18] предлагается шесть методов проверки правильности, приме- няемых к внешним спецификациям. Эти методы не исключают друг друга и рекомендуются для последовательного применения.
1.
Контроль по правилу “n плюс – минус один” и групповой кон-
троль специалистами. Специалисты уровня n – 1 ищут ошибки перево- да, а специалисты уровня n + 1 которые могут привести к ошибкам в последующих процессах. Спецификации должны сверяться с целями путем рассмотрения каждой из них и последующего определения адек- ватности отражения цели в спецификациях. Подробную внешнюю спе- цификацию должны оценивать люди, отвечающие за разработку перво- начального внешнего проекта, проектирование структуры программ и баз данных и люди, отвечающие за подготовку документации пользова- теля.
2.
Контроль со стороны пользователя. Крайне важно получить обзор и одобрение первоначальной и подробной спецификации со сто- роны организации пользователя. Если разрабатывается проект, незави- симый от пользователя, то контрольная группа создается из специали- стов проектирующей организации с теми же целями. В ее задачу будет входить оценка спецификаций с точки зрения пользователя.
3.
Контроль по таблицам решений. Если в спецификациях ис- пользуются таблицы решений (а должно быть именно так по [М]), тогда для проверки на полноту (поиск всех пропущенных условий) и неодно- значность (идентичные условия приводят к разным выходным данным или преобразованиям) могут быть применены “механические” методы.
4.
Ручная имитация (прокрутка спецификаций). Эффективный прием проверки детальных внешних спецификаций – подготовка тестов и последующее использование детальных спецификаций для имитации поведения системы. Этот процесс оценки проектного документа мето-
245 дом его “выполнения” на тестовых данных часто называется сквозным контролем.
Для проверки отдельных внешних функций должны быть выполне- ны следующие действия. Кто-то (не автор спецификации) должен сна- чала построить “тесты на бумаге” для этой функции, т.е. список кон- кретных входных данных (допустимых и недопустимых). Вместе с ав- тором спецификаций он потом имитирует ввод этих данных в систему, используя спецификации как описание поведения системы. Всякий раз, когда оказывается, что спецификация описывает выходные данные или преобразование для какого-либо набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка. Эту последо- вательность проверки внешних функций можно представить следующей схемой (рис. 5.37).
Рис. 5.37. Последовательность проверки внешних функций
Прежде чем начать сквозной контроль, обычно бывает необходимо установить исходное состояние системы, например, описать начальные состояния всех файлов, а затем обновлять это состояние по мере ис- пользования тестов. Подобным образом можно тестировать и комбина- ции функций, строя тесты, представляющие собой сложные сценарии.
246
Важно отметить, что цель всякого такого сеанса сквозного контроля
- обнаруживать ошибки, но не исправлять их с лету. Исправление оши- бок нужно отложить до тех пор, пока не будут обнаружены по возмож- ности все ошибки. Также важно, чтобы строил тесты и интерпретировал спецификации кто-то другой, не автор, так как последний будет “читать между строк”.
5.
Имитация за терминалом. В этом случае вместо того чтобы просто читать список тестов, как при ручной имитации, один из прове- ряющих садится за терминал (персональный компьютер), вводит тесто- вые данные и получает результаты, так, как если бы терминал был под- ключен к настоящей программной системе (рис. 5.38).
Для имитации еще один участник проверки, вооружившись специ- фикациями, садится за другой компьютер. Небольшая программа, спе- циально разработанная для такой проверки, связывает эти компьютеры, передавая входные данные с терминала “пользователя” на терминал
“имитатора”, а выходные данные – обратно по командам “имитатора”
(рис. 5.38).
Считается, что этот метод очень ценен, поскольку он помогает обна- ружить в спецификациях все недочеты по части психологических фак- торов. В процессе внешнего проектирования он особенно полезен для изучения альтернативных вариантов решения проблемы психологиче- ских факторов.
Рис. 5.38.
6.
Функциональные диаграммы. Этот метод заимствован из про- ектирования переключательных схем и позволяет проектировщику представить спецификации булевской логической диаграммой (функ- циональной диаграммой), которая затем преобразуется в таблицу реше- ний.
247
Литература к главе 5
1.
IBM
Rational
Software
Modeler. http://www.interface.ru/fset.asp?Url=/rational/RSM.htm
2.
SWEBOK http://ru.wikipedia.org/wiki/SWEBOK
3.
UML. http://ru.wikipedia.org/wiki/UML
4.
Амсден Д. Фиксация требований с помощью инструментов
Business Motivation Model, IBM Rational RequisitePro и IBM Rational
Software
Modeler. http://www.ibm.com/developerworks/ru/library/r-
0401_amsden/index.html#author1 5.
Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. 2-е изд. – СПб.: Питер, 2006. – 575 с.
6.
Буч Г., Рамбо Д., Якобсон И. Язык UML, Руководство пользова- теля. 2-е изд. : Пер. с англ. Мухин Н. – М.: ДМК Пресс, 2007. – 496 с.
7.
Вендров А.М. Проектирование программного обеспечения эко- номических информационных систем. Учебник для вузов. 2-е изд. – М.:
Финансы и статистика, 2006 8.
Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разра- ботки программного обеспечения: учебное пособие / под ред. Л.Г. Гага- риной. – М.: ИД «ФОРУМ»: ИНФРА-М., 2008. – 400 с.
9.
Гантер Р. Методы управления проектированием программного обеспечения: Пер. с англ. – М.: Мир, 1981. – 392 с.
10. Гибс Д. Управление проектами с помощью IBM Rational Unified
Process. Практические уроки. Пер. с англ. – М.: КУДИЦ-ПРЕСС. – 2007.
– 304 с.
11. Диаграмма потоков данных (DFD). Графический язык диаграм- мы. http://e-educ.ru/bd14.html
12. Зиглер К.. Методы проектирования программных систем: Пер. с англ. – М .: Мир, 1985. – 328 с.
13. Калянов Г.Н. CASE: структурный системный анализ (автомати- зация и применение). М.: ЛОРИ. 1996 14. Кватрани Т., Палистрает Д. Визуальное моделирование с помо- щью IBM Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-
ПРЕСС. – 2007. – 192 с.
15. Классификация видов моделей. http://www.uml3.ru/index.php?option=com_content&view=article&id=36:ki nd-of-models&catid=3:software-design
16. Колин Ю. Применение Rational Software Architect в разработке, управляемой моделями: Часть 1. Обзор парадигмы разработок, управ- ляемых моделями с шаблонами. http://www.ibm.com/developerworks/ru/library/1121_yu/index.html?S_TAC
T=105AGX63&S_CMP=NWLTR&ca=dnn-rut2405 17. Ларман К. Применение UML 2.0 и шаблонов проектирования.
3-е издание. Вильямс. 2006, 736 с.
18. Майерс Г. Надежность программного обеспечения: Пер. с англ.
– М .: Мир, 1980. – 360 с.
248 19. Метод функционального моделирования
SADT. http://dic.academic.ru/dic.nsf/politology/1766/%D0%9C%D0%B5%D1%82
%D0%BE%D0%B4 20. Методологии функционального моделирования. http://www.mstu.edu.ru/study/materials/zelenkov/ch_5_3.html
21. Новичков А., Карабанова Г. Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятель- ности с использованием
RSA.
–
http://www.ibm.com/developerworks/ru/library/r-rsa/index.html#author1 22. Общий обзор и концепция разработки, управляемой моделями. http://www.ibm.com/developerworks/ru/library/mdd/ch1/ch1.html#author1 23. Описание подключаемого модуля RUP для управляемой моде- лями разработки систем, http://www.interface.ru/home.asp?artId=21714 24. Основы
Программной
Инженерии
(по
SWEBOK). http://swebok.sorlik.ru/1_software_requirements.html
25. Полис Г., Огастин Л., Лоу К., Мадхар Д. Разработка программ- ных проектов на основе Rational Unnified Process (RUP). – М.: ООО
«Бином-Пресс», 2009. – 256 с.
26. Применение Rational Software Architect в разработке, управляе- мой моделями: Часть 1. Обзор парадигмы разработок, управляемых мо- делями с шаблонами. http://www.cmcons.com/articles/drugie_stati/primenenie_rational_software_
architect_v_razrabotke_upravljaemojj_modeljami_chast_1_obzor_paradigmy
_razrabotok_upravljaemykh_modeljami_s_shablonami/
27. Технология программирования и создание программных про- дуктов. http://www.cs.nuos.edu.ua/textbooks/SWDevelop/SaprSW1/index.htm
28. Турский В. Методология программирования: пер. с англ. – М.:
Мир, 1981. – 264 с.
29. Халл Э., Джексон К., Дик Д. Разработка и управление требова- ниями. Практическое руководство пользователя. Telelogic, 2005 30.
Химонин Ю. Сбор и анализ требований к программному про- дукту. http://www.pmi.ru/profes/Software_Requir http://ru.wikipedia.org/wiki/UML ements_Khimonin.pdf
249
Глава 6
ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ
ПРОГРАММНЫХ СИСТЕМ
6.1. Методология проектирования
По мнению авторов фундаментальных монографий [19, 20, 24, 41] всякую методологию проектирования программных систем можно представить набором желаемых характеристик результата проектирова- ния и руководящих принципов процесса проектирования. Выше уже отмечалось, что формирование желательных целей проектирования сво- дится к определению требований и целей проектирования. Что касается принципов проектирования, то они определяют сам процесс проектиро- вания и методы проектирования.
Принципы проектирования – это обычно независимые от предмет- ной области стратегии, положенные в основу проектирования. Однако есть принципы, относящиеся специально к проектированию программ- ных (и других) систем для компьютеров.
Методы проектирования – это обычно зависимые от области при- ложения (предметной области) тактические средства, определяющие те или иные этапы процесса проектирования. Сам процесс проектирования подразумевает принятие решения о форме и содержании предмета про- ектирования. Метод должен помогать разработчику в упорядочении принимаемых решений. Методы проектирования опираются, в конеч- ном счете, на свойства мыслительного процесса разработчика и обеспе- чивают определенные алгоритмы принятия решений.
Кроме того, метод проектирования должен помочь разработчику сконцентрировать свое внимание на определенных аспектах или частях проектируемой системы, взятых по отдельности. Это особенно важно при разработке больших программных систем (например, операцион- ных систем), где сложность системы заранее исключает всякую воз- можность охватить сразу все детали. Тем не менее разработчик должен точно понимать общие характеристики всей системы, по мере того как они проясняются во время проектирования.
Основные принципы (стратегии) процесса проектирования, дающие разработчику возможность справиться со сложностью системы – это
декомпозиция и абстракция.
Базовая парадигма (давно известная) в подходе к решению большой задачи – ”разделяй и властвуй”. К сожалению, буквальное следование этому принципу по-прежнему предполагает долгий путь к решению задачи. Самым важным является то, каким образом осуществляется это разделение. Понятно, что по мере возрастания размера программной системы монолитная структура становится неудобной, поскольку ее текст труден для понимания (никто не может понять миллионы строк современных операционных систем). Поэтому программа должна быть
250 разбита на ряд небольших программ (модулей), которые сообща выпол- няют требуемую функцию.
Корректность такого разбиения (декомпозиции) становится все бо- лее важной по мере роста программной системы. Это обусловлено сле- дующими причинами:
1. В процесс разработки программной системы вовлекается все большее количество людей. Регулярные контакты между исполнителя- ми снижают вероятность разногласий, касающихся того, кто и что дол- жен делать, и уменьшают возможность серьезных последствий, возни- кающих в подобных ситуациях.
2. Полезное время жизни программы (рабочая стадия) начинается с момента передачи потребителю. Однако работа над программой не за- канчивается. Работа по модификации и сопровождению программы мо- жет потребовать больше времени, чем время, потраченное на ее разра- ботку. При этом неразумно начинать работу с полной переделки про- граммы. Лучше внести изменения в уже существующую структуру программы. Поэтому важно, чтобы структура программы допускала возможность такой модификации. Для этого необходимо, чтобы части программы были независимы друг от друга с тем, чтобы изменение в одной части могло быть сделано без изменений других частей.
3. Со временем модификация программ, время жизни которых дос- таточно велико, выполняется уже не разработчиками программ, Все эти факторы предполагают структурирование программ таким образом, чтобы они были легко понимаемыми.
Таким образом, большие программные системы целесообразно раз- рабатывать путем декомпозиции задачи.
Декомпозиция является полезным и экономящим время способом решения задач в самых различных областях. Однако это не панацея, и при неграмотном использовании может принести массу неприятностей.
Часто большие или плохо понимаемые задачи поддаются декомпозиции с большим трудом. К числу распространенных проблем относится си- туация, при которой создание отдельных компонентов, способных ре- шить соответствующие задачи, не приводит к тому, что объединение компонентов позволяет решить исходную задачу. Это является одной из причин, по которой интеграция системы оказывается затруднительной.
К тому же нужно помнить и тот факт, что разбиение любой задачи на подзадачи (это наиболее ярко проявляется в математических задачах) и оптимальное решение этих подзадач не дает оптимального решения общей задачи.
Абстракция – эффективный способ декомпозиции, осуществляемый посредством изменения списка детализации. Когда разработчик абстра- гируется от проблемы, он предполагает игнорирование ряда подробно- стей с тем, чтобы свести задачу к более простой. Задачи абстрагирова- ния и последующей декомпозиции типичны для процесса создания про- граммной системы: декомпозиция используется для разбиения про- граммы на компоненты (модули), которые могут быть затем объедине- ны, позволив решить основную задачу; абстрагирование предполагает