Проектирование программных систем Лекция МОДЕЛИРОВАНИЕ СИСТЕМ Король Иван

Проектирование программных систем Лекция МОДЕЛИРОВАНИЕ СИСТЕМ Король Иван Андреевич

Проектирование программных систем v v v Лекция: МОДЕЛИРОВАНИЕ СИСТЕМ 1. Моделирование и программирование 2. Понятие спецификаций 3. Проблема типовых элементов в программировании 4. Эволюция подходов к управлению программными проектами 5. Модели процесса разработки программного обеспечения 6. Что надо делать для успеха программного продукта

Моделирование и программирование Моде ль (фр. modèle, от лат. modulus — «мера, аналог, образец» ) — это упрощенное представление реального устройства и/или протекающих в нем процессов, явлений. Моделью системы (или какого-либо другого объекта или явления) может быть формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами.

Моделирование и программирование q q q Собираясь сделать пристройку к дому, вы, вероятно, не начнете с того, что купите кучу досок и будете сколачивать их вместе различными способами, пока не получите что-то приблизительно подходящее. Для работы вам понадобятся проекты и схемы, так что вы скорее всего начнете с планирования и структурирования пристройки. Обратите внимание, что ваш результат будет тогда долговечнее. Вы же не хотите, чтобы работа разрушилась от небольшого дождика.

Моделирование и программирование n n Любые достаточно большие программы являются сложными системами. Проблема сложности преодолевается путем декомпозиции задачи. Базовая парадигма в подходе к любой большой задаче ясна: необходимо «разделять и властвовать» , т. е. декомпозировать и управлять.

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

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

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

Понятие спецификаций q q q Ø Ø Первичные спецификации составляют в терминах решаемой задачи, а не программы. В ходе выполнения проекта спецификации последовательно претерпевают изменения до программных документов стадий и вплоть до документации, которая необходима для эксплуатации и сопровождения программы. Уже в первичных спецификациях можно выделить две части: функциональную и эксплуатационную.

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

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

Понятие спецификаций n n n К тестированию хорошо составленных внешних спецификаций можно привлечь потенциальных пользователей еще до разработки внутренних спецификаций. Пользователю можно показывать макеты экранов в порядке выполнения программы, а сам он может готовить данные для тестирования всех функций программы. Внешние спецификации обычно фиксируются в ТЗ или ЭП, но могут быть уточнены в ТП.

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

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

Типовые элементы Объектно-ориентированные языки программирования дали четыре новых механизма использования кубиков: n 1) механизм классов, порождающих при выполнении любое количество однотипных объектов, например, ряд однотипных кнопок; n 2) возможность тиражирования объектов от породившей программы во все новые программы; n 3) динамически линкуемые библиотеки с порождающими объекты классами; n 4) механизм сборки программ из «кубиков» — объектов в процессе их выполнения.

Типовые элементы q Первый механизм (классов) облегчил развитие систем визуального программирования, при работе в которых значительная часть программы может быть создана путем отбора мышкой стандартных «кубиков» .

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

Типовые элементы q q q Согласно третьему механизму возникли СОМтехнологии. COM (англ. Component Object Model — объектная модель компонентов; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для созданияпрограммного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. На основе четвертого механизма из базы готовых «кубиков П-объектов» создаются все новые «кубики» и из них новые программы.

Управление программными проектами За 50 лет развития программной инженерии накопилось большое количество моделей разработки ПО. q «Как получится» . Разомкнутая система управления. Полное доверие техническим лидерам. q Представители бизнеса практически не участвует в проекте. Планирование, если оно и есть, то неформальное и словесное. Время и бюджет, как правило, не контролируются. q

Управление программными проектами «Водопад» или каскадная модель. q Жесткое управление с обратной связью. q Лучше, но не эффективно. q «Гибкое управление» . q «Планы — ничто, планирование — все» (Эйзенхауэр, Дуайт Дэвид) q

Управление программными проектами q q Классические методы управления перестают работать в случаях, когда структура и свойства управляемого объекта нам не известны и/или изменяются со временем. Если рабочая группа проекта не может обеспечить требуемую эффективность и поэтому постоянно работает в режиме аврала, то это приводит не к росту производительности, а к уходу профессионалов из проекта.

Модели процесса разработки ПО n n n Модели (или, как еще любят говорить, методологии) процессов разработки ПО принято классифицировать по «весу» – количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели. Наиболее распространенные современные модели процесса разработки ПО представлены на рис. 2. 8.

Модели процесса разработки ПО

Выбор модели процесса Алистер Коуберн, один из авторов «Манифеста гибкой разработки ПО» [14] проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и «гибких» до тяжелых (СММ-5) за последние 20 лет [15, 16]. Он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что: q У каждого проекта должна быть своя модель процесса разработки. q У каждой модели — свое время.

Выбор модели процесса Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с «Законом 4 -х П» (рис. 2. 10). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

Выбор модели процесса

Успех программного продукта q q Стив Макконнелл в своей книге [17] приводит тест программного проекта на выживание. Этот чек-лист из 33 -х пунктов, который необходимо процитировать с небольшими корректировками. Руководитель программного проекта должен его периодически использовать для внутреннего аудита своих процессов. Чтобы программный проект стал успешным, необходимо: Четко ставить цели. n Определять способ достижения целей. n Контролировать и управлять реализацией. n Анализировать угрозы и противодействовать им. n Создавать команду. n

Успех программного продукта Ставим цели 1. 1. Концепция определяет ясные недвусмысленные цели. 1. 2. Все члены команды считают концепцию реалистичной. 1. 3. У проекта имеется обоснование экономической эффективности. 1. 4. Разработан прототип пользовательского интерфейса. 1. 5. Разработана спецификация целевых функций программного продукта. 1. 6. С конечными пользователями продукта налажена двухсторонняя связь

Успех программного продукта Определяем способ достижения целей 2. 1. Имеется детальный письменный план разработки продукта 2. 2. В список задач проекта включены «второстепенные» задачи (управление конфигурациями, конвертация данных, интеграция с другими системами). 2. 3. После каждой фазы проекта обновляется расписание и бюджет 2. 4. Архитектура и проектные решения документированы 2. 5. Имеется план обеспечения качества, определяющий тестирование и рецензирование. 2. 6. Определен план многоэтапной поставки продукта. 2. 7. В плане учтены обучение, выходные, отпуска, больничные. 2. 8. План проекта и расписание одобрен всеми участниками команды.

Успех программного продукта Контролируем и управляем реализацией 3. 1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта. 3. 2. У проекта есть менеджер, причем только один! 3. 3. В плане проекта определены «бинарные» контрольные точки. 3. 4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта. 3. 5. Между руководством и разработчиками установлены доверительные отношения. 3. 6. Установлена процедура управления изменениями в проекте. 3. 7. Определены лица, ответственные за решение о принятии изменений в проекте. 3. 8. План, расписание и статусная информация по проекту доступна каждому участнику. 3. 9. Код системы проходит автоматическое рецензирование. 3. 10. Применяется система управления дефектами

Успех программного продукта Анализируем угрозы q 4. 1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление. q 4. 2. Руководитель проекта отслеживает возникновение новых рисков. q 4. 3. Для каждого подрядчика определено лицо, ответственное за работу с ним.

Успех программного продукта Работаем над созданием команды q 5. 1. Опыт команды достаточен для выполнения проекта. q 5. 2. У команды достаточная компетенция в прикладной области. q 5. 3. В проекте имеется технический лидер. q 5. 4. Численность персонала достаточна. q 5. 5. У команды имеется достаточная сплоченность. q 5. 6. Все участники привержены проекту.

Успех программного продукта Оценка и интерпретация теста q Оценка: сумма баллов, каждый пункт оценивается от 0 до 3: q 0 — даже не слышали об этом; q 1 — слышали, но пока не применяем; q 2 — применяется частично; q 3 — применяется в полной мере. Поправочные коэффициенты: q для малых проектов (до 5 человек) — 1. 5; q для средних (от 5 до 20 человек) — 1. 25.

Успех программного продукта Результат: q <40 — завершение проекта сомнительно. q 40 -59 — средний результат. В ходе проекта следует ожидать серьезные проблемы. q 60 -79 — хороший результат. Проект, скорее всего, будет успешным. q 80 -89 — отличный результат. Вероятность успеха высока. q >90 — великолепный результат. 100% шансов на успех. Этот чек-лист перечисляет, что надо делать для успеха программного проекта, но не дает ответ на вопрос как это следует делать.

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

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

ВЫВОДЫ q • Чтобы программный проект стал успешным, необходимо: n Четко ставить цели. n Определять способ достижения целей. n Контролировать и управлять реализацией. n Анализировать угрозы и противодействовать им. n Создавать команду.

Контрольные вопросы n n n n 1. В чем суть моделирования? 2. Какие типы абстракций вы знаете? 3. Что такое первичная функциональная спецификация? 4. Что такое внутренние функциональные спецификации? 5. В чем суть процедурной абстракции и абстракции данных? 6. Что такое структурное программирование? 7. Парадигмы модульного программирования и объектно-ориентированного программирования?

Контрольные вопросы n n n 8. Что представляет из себя объектноориентированное программирование? 9. Какие современные методы моделирования ПО? 10. Какие плюсы и минусы тяжелых и легких моделей процессов разработки программного обеспечения? 11. Какие механизмы использования «кубиков» дали объектно-ориентированные языки программирования? 12. Что необходимо для успеха программного проекта?

Проектирование программных систем Лекция МОДЕЛИРОВАНИЕ СИСТЕМ Король Иван Андреевич