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

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

Лекция 1.1. Определение проекта и проектирования. Основные особенности и проблемы современных программных проектов

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

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

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

1 структурная, функциональная и информационная сложность объекта внедрения;

2 высокая техническая сложность, из-за наличия подсистем, обеспечивающих управление транзакциями, аналитическую обработку данных, безопасность;

3 отсутствие полных аналогов и высокая доля вновь разрабатываемого ПО;

4 наличие унаследованного ПО и необходимость его интеграции с разрабатываемым ПО;

5 территориально распределенная и неоднородная среда функционирования;

6 большое количество участников проектирования, разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и опыту;

7 значительная длительность жизненного цикла ПО.

Лекция 1.3. Общие принципы проектирования систем. Модели программного обеспечения и их место в процессе проектирования

Одна из основных проблем при создании больших и сложных систем, в том числе ПО, – это проблема сложности. Подход к решению этой проблемы основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО. Принципы декомпозиции:

1 слабая связанность – low coupling (количество связей между отдельными подсистемами должно быть минимальным);

2 сильное сцепление – high cohesion (связность отдельных частей внутри каждой подсистемы должна быть максимальной).

Структура ПО должна удовлетворять следующим требованиям:

1 каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

2 каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

В рамках обоих подходов используются наглядные графические модели (схемы и диаграммы) для описания архитектуры ПО с различных точек зрения. Примеры: блок-схемы, диаграммы «сущность – связь», диаграммы классов. Модель ПО – это формализованное описание системы ПО на определенном уровне абстракции. Каждая модель описывает конкретный аспект системы, использует набор диаграмм или формальных описаний и документов заданного формата, а также отражает точку зрения и является объектом деятельности различных людей с конкретными интересами, ролями или задачами. Модели служат полезным инструментом анализа проблем, обмена информацией между всеми заинтересованными сторонами, проектирования ПО. Моделирование способствует более полному усвоению требований, улучшению качества системы и повышению степени ее управляемости.

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

Моделирование не является целью разработки ПО. Диаграммы – это лишь наглядные изображения. Причины, побуждающие прибегать к их использованию:

1. Графические модели помогают получить общее представление о системе, сказать о том, какого рода абстракции существуют в системе и какие ее части нуждаются в дальнейшем уточнении.

2. Графические модели образуют внешнее представление системы и объясняют, что эта система будет делать, тем самым облегчают общение с заказчиком.

3. Графические модели облегчают изучение методов проектирования, в частности объектно-ориентированных методов.

В процессе создания ПО используются следующие виды моделей:

1 модели деятельности организации (или модели бизнес-процессов):

o модели "AS-IS" ("как есть"), отражающие существующее положение;

o модели "AS-TO-BE" ("как должно быть"), отражающие представление о новых процессах и технологиях работы организации;

2 модели проектируемого ПО, которые строятся на основе модели "AS-TO-BE", уточняются и детализируются до необходимого уровня.

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

Для облегчения труда разработчиков и автоматизированного выполнения некоторых рутинных действий используются CASE-средства (Computer Aided Software Engineering). В настоящее время CASE-средства обеспечивают поддержку большинства процессов жизненного цикла ПО, что позволяет говорить о CASE-технологиях разработки ПО. CASE-технология – это совокупность методов проектирования ПО и инструментальных средств для моделирования предметной области, анализа моделей на всех стадиях ЖЦ ПО и разработки ПО.

1. Боггс У., Боггс М. UML и Rational Rose 2002: Пер. с англ. – М.: ЛОРИ, 2004.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000. – Глава 2.

3. Вендров А. М., Малышко В. В. Объектно-ориентированный анализ и проектирование с использованием языка UML.: Методическое пособие – М.: Издательский отдел факультета ВМиК МГУ, 2002.

4. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005.

Лекция 2.2. Варианты использования и диаграммы вариантов использования. Диаграммы взаимодействия

Вариант использования – это ответные действия ПО, являющиеся реакцией на событие, инициируемое извне. Вариант использования описывает типичное взаимодействие между пользователем и ПО. Он отражает представление о поведении системы с точки зрения пользователя. На диаграммах варианты использования представляются в виде овалов.

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

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

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

1. Не следует моделировать связи между действующими лицами, поскольку это не относится к системе.

2. Не следует соединять стрелкой два варианта использования.

3. Каждый вариант использования должен быть инициирован действующим лицом.

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Детально функциональные требования описываются в документе, называемом «сценарий варианта использования» или «поток событий». Он подробно документирует процесса взаимодействия действующего лица с системой, реализуемого в рамках варианта использования.

Описание потока событий включает следующие разделы:

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

1 следует использовать простые предложения;

2 нужно явно указывать в каждом пункте, кто выполняет действие – действующее лицо или система;

3 не следует включать в потоко событий слишком незначительные действия;

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

5 некорректные действия пользователя и внутренние ошибки следует описывать в альтернативных потоках.

В диаграммах вариантов использования может присутствовать несколько типов связей:

1 связи коммуникации (линия со стрелкой, обозначающая связь между вариантом использования и действующим лицом);

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

3 связи расширения (пунктирная линия со стрелкой, указывающая на особый случай, описанный в абстрактном варианте использования);

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

Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов в рамках потока событий. На диаграмме отображается ряд объектов и сообщения, которыми они обмениваются между собой. Сообщение – это средство, с помощью которого объект-отправитель запрашивает у объекта-получателя выполнение одной из его операций. Существует два вида диаграмм взаимодействия: диаграммы последовательности и коммуникационные диаграммы (ранее называемые кооперативными).

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

Вторым видом диаграмм взаимодействия являются коммуникационные диаграммы. Как и диаграммы последовательности, они отображают поток событий варианта использования. На коммуникационных диаграммам внимание сконцентрировано на связях между объектами. Из них легче понять связи между объектами, однако, труднее уяснить последовательность событий. Объекты и/или действующие лица, обменивающиеся сообщениями соединяются линиями, над которым в виде стрелок обозначаются сообщения. Нумерация сообщений указывает их последовательность во времени.

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000. – Главы 17, 18.

2. Вендров А. М., Малышко В. В. Объектно-ориентированный анализ и проектирование с использованием языка UML.: Методическое пособие – М.: Издательский отдел факультета ВМиК МГУ, 2002.

3. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005. – Главы 4, 9, 12.

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000. – Главы 8, 12, 19, 24, 29, 30.

3. Леоненков В. А. Самоучитель UML. – СПб: BHV, 2001.

4. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005. – Главы 3, 5, 7, 8, 10, 11, 14

1. Буч Г., Якобсон А., Рамбо Дж. UML. Серия «Классика CS». 2-е изд.: Пер. с англ. – СПб.: Питре, 2006. – Глава 12.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 2.

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.

Лекция 3.2. Определение требований к системе. Варианты использования

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

Требования к ПО оформляются в виде ряда документов и моделей. Словарь предметной области (глоссарий) определяет общую терминологию для всех моделей и описаний требований к системе. Технические требования содержат описание нефункциональных требований. Функциональные требования к системе моделируются и документируются с помощью вариантов использования.

1. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2002.

2. Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Глава 9.

3. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Главы 5, 6.

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

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

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

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.

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

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

2. Коналлен Дж. Разработка Web-приложений с использованием UML.: Пер. с англ. – М.: Вильямс, 2001. – Глава 10.

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

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

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 5.

2. Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002.

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

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

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: