Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 127

В этой модели отсутствует иерархия участников группы, потому что вопрос кто кому подчинѐн? теряет смысл. Однако существует несколько моментов, на которые также следует обращать внимание:

−большая численность группы проекта может требовать много времени на общение, чтобы реализовать первую характеристику;

−высшее руководство имеет ограниченный контроль над процессами внутри группы;

−участники группы должны полностью понимать и принимать свои роли.

Для небольших проектов некоторые роли могут быть совмещены (рис. 8-2), и могут выполняться одним человеком.

Рис. 8-2. Совмещение ролей

Как правило, в основной состав проектной группы входят аналитик, разработчик и тестер (рис. 8-3).

Рис. 8-3. Основной состав группы

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

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

Для очень больших проектов состав разработчиков разбивается на подгруппы, деятельность которых координируется.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 128

Подгруппы могут быть функциональными, или, в свою очередь, тоже могут быть разбиты на ещѐ меньшие подгруппы. Это даѐт возможность организовать параллельную работу над проектом. Каждая группа от самого высокого до самого низкого уровня состоит не более чем из трѐх-семи человек (рис. 8-4). Группы работают в тесном контакте друг с другом и обеспечивают процессы жизненного цикла.

Рис. 8-4. Подгруппы группы проекта

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

9. АВТОМАТИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

При разработке сложных программных продуктов группой участников важно решать такие вопросы, как:

−Организация взаимодействия разработчиков.

−Осуществление контроля над версиями.

−Организация безопасного хранения компонент.

−Организация повторного использования компонент.

−Обеспечение интеграции инструментов, используемых разработчиками.

9.1.Визуальное моделирование

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

Визуальное моделирование помогает в разработке сложных программных продуктов. Его использование существенно облегчает достижения таких целей, как повышение качества, сокращение стоимости и поставка в запланированные сроки.

История развития программного обеспечения показала, что процесс проектирования становится практически неосуществимым без наличия:

−стандарта для описания моделей;

−инструмента, поддерживающего такой стандарт и позволяющего визуально отображать модели.

Множество компаний занялись разработкой подобного стандарта и инструментов. В результате появился на свет Unified Modeling Language. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 129

поддержке UML. Среди этих средств можно выделить Rational Rose, ArgoUML, Magic draw, Select Enterprise, JUDE.

Средства визуального моделирования позволяют:

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

−Описать систему в наглядной для человека графической форме с применением стандартной нотации (например, UML).

−Показать различные аспекты ПС при помощи моделей (например, функционирование – Use case View, логическую организацию – Logical View, физиче-

скую структуру – Component View, Deployment View).

−Найти необходимые решения, относящиеся к программной реализации (например, сценарии взаимодействия Sequence Diagrams, параллельные потоки

Activity Diagrams, потоки данных Collaboration Diagrams).

−На основе моделей создавать проект в виде исходных текстов на различных языках программирования (например, С++, JAVA, Ada, Visual Basic).

−Спроектировать базу данных и получить еѐ логическую модель из объектной модели ПС.

−Выявить повторно используемые программные компоненты, что даѐт возможность сократить объѐм кодирования.

−Выполнять построение моделей из программного кода и базы данных при проектировании унаследованных систем (reverse engineering).

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

Однако, создание ПС – это не только построение модели. Чем сложнее и шире проект, тем в большей степени он требует инструментальной поддержки всех этапов жизненного цикла.

9.2. CASE-средства

CASE (Computer-Aided Software Engineering) – система автоматизированной разра-

ботки программ, или CASE-средство.

К CASE-средствам относятся инструментальные средства для автоматизации процессов жизненного цикла программного обеспечения.

Современные CASE-средства имеют следующие отличительные черты:

−Наличие графических средств описания и документирования обеспечивает разработчикам удобный интерфейс и развивает их творческие возможности.

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

−Использование специальным образом организованного хранилища (репозитория) проектных артефактов позволяет разработчикам найти соответствующие проектные решения.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 130

Интегрированное средство автоматизированной разработки поддерживает полный жизненный цикл и содержит следующие основные компоненты:

1.Репозиторий. Обеспечивает хранение версий проекта и его отдельных частей, синхронизацию поступления сведений от разных разработчиков при коллективной разработке, контроль данных на полноту и непротиворечивость.

2.Графические средства анализа и проектирования. Обеспечивают создание и ре-

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

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

4.Средства конфигурационного управления6. Помогают организовать деятельность по систематическому учѐту и контролю внесения обоснованных изменений в программное обеспечение. Система конфигурационного управления даѐт возможность отследить существующие проектные объекты и их состояния, загруженность исполнителей и выполнение ими технических заданий.

5.Средства документирования. Обеспечивают генерацию различной проектной документации в соответствии с существующими стандартами на основе хранимых в репозитории данных.

6.Средства тестирования. Обеспечивают автоматизированную проверку программного обеспечения на соответствие требованиям и критериям качества.

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

Основными компонентами CASE-средств являются средства для поддержки ана-

лиза, проектирования и документирования.

9.3. Среда JUDE Community

JUDE – инструментальное средство моделирования программных систем японской компании Change Vision.

Название JUDE является аббревиатурой от Java and UML Developers Environment.

В1996 году, нынешний CEO (chief executive officer) компании Кенджи Хиранабе

пришѐл к выводу, что в недалѐком будущем будет востребована среда для объект- но-ориентированного проектирования. Он собрал несколько добровольцев, и они создали JOMT, впоследствии переименованный в JUDE.

В1999 году JUDE стал распространяться бесплатно. Однако в 2004 году проект был разделен на два: JUDE Community и JUDE Professional. Продукт JUDE Professional

обладает большей функциональностью по сравнению с бесплатной версией.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

1.Создание UML-диаграмм: Activity diagram, Use Case diagram, Sequence diagram, Collaboration diagram, Class diagram, Statechart diagram, Component diagram, Deployment diagram.

2.Редактирование: автоматическое размещение элементов на диаграмме; клонирование диаграмм; добавление элементам на диаграмме цветов и их градаций.

3.Импорт и экспорт: экспорт диаграмм в изображения форматов PNG и JPG; экспорт диаграмм для импорта в другие среды в формате BMP, JPEG, PNG; экспорт классов в виде HTML-документации (формат javadoc).

4.Генерация Java-кода из диаграмм классов.

5.Генерация классов из Java-кода.

Рекомендуемая литература

1.Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование./ Пер. с англ. – 2-е изд. – СПб., М.: Символ, 2008.

2.Буч Г., Максимчук Р. А. и др. Объектно-ориентированный анализ и проектирование с примерами приложений./ Пер. с англ. – 3-е изд. – М., СПб., Киев: Вильямс,

2008.

3.Канер С. и др. Тестирование программного обеспечения. / Пер. с англ. – Киев.: ДиаСофт, 2000.

4.Коуд П., Норт Д., Мейфилд М. Объектные модели. Стратегии, шаблоны и приложения. / Пер. с англ. – М.: ЛОРИ, 1999.

5.Крачтен Ф. Введение в Rational Unified Process. . / Пер. с англ. – 2-е изд. – М.:

Вильямс, 2002.

6.Ларман К. Применение UML 2.0 и шаблонов проектирования. / Пер. с англ. – 3-е изд. – М.: Вильямс, 2007.

7.Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. / Пер. с англ. – 2-е изд. – СПб.: Питер, 2007.

8.Раскин Д. Интерфейс: новые направления в проектировании компьютерных систем. / Пер. с англ. – СПб.: Символ-Плюс, 2003.

9.Скотт К. UML. Основные концепции. / Пер. с англ. – М.: Вильямс, 2002.

10.Фаулер М. UML. Основы./ Пер. с англ. – 3-е изд. – М.: Символ, 2005.

11.Якобсон А., Буч Г., Рамбо Д. Унифицированный процесс разработки программного обеспечения. / Пер. с англ. – СПб.: Питер, 2002.

12.http://jude.change-vision.com/

13.www.retional.com

14.www.booksites/maciaszek

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011