Бизнес и IT-проекты Рынок ПО в России и в мире Немного статистики
Для того чтобы бизнес был успешным, необходимо (но не достаточно) выполнение многих условий:
Продукт должен выходить на рынок надлежащего качества;вовремя;интересным потенциальным пользователям.
Расходы должны соответствовать изначальному бюджету.
Рис. 1.1. Статистика успешности IT-проектов. По данным The Standish Group International, Extreme Chaos
К сожалению, ситуация такова, что многие проекты не удовлетворяют этим, казалось бы естественным, условиям. Рассмотрим некоторую статистику (рис. 1.1)1).
Приведем расшифровку степени успешности проектов:
Проваленные: закончились неудачей - цель вообще не была достигнута.Испытавшие большие проблемы: закончились созданием продукта, но превысили бюджет или (и) не уложились во время или (и) имеют лишь частичную функциональность.Успешные: закончились созданием продукта, уложились в бюджет и время. Вся планируемая функциональность реализована.
Как видите, доля успешных проектов неуклонно возрастает, оставаясь по-прежнему сенсационно малой. И это притом, что в 2004 году на разработку программных средств ушло около 3 700 000 000$.
Рассмотрим еще один любопытный график:
Рис. 1.2. Доля успешных проектов в зависимости от их бюджета.
Данная диаграмма2) говорит о том, что с ростом размера проекта (бюджет характеризует в данном случае размер и сложность задачи) шансы на его успех катастрофически падают.
Поговорим о текущем положении отрасли в России. В конце 90-х годов, обсуждая этот вопрос, мы приводили следующие качественные характеристики:
Хорошие программисты.Грамотные аналитики.Недостаток хороших управленцев.Проблемы с документированием и локализацией.Проблемы с рекламой и продвижением.
Прошло всего 5 лет, и ситуация существенно изменилась к лучшему. Объем экспорта программного обеспечения из России в 2005 г. превысил 1 млрд.$ (для сравнения экспорт в автомобильной отрасли составил 380 млн.$, в атомной энергетике - 850 млн.$). Объем IT-рынка в 2004 г. составил 9,2 млрд.$, в 2005 г. рост составил 22,1% (в то время как мире всего порядка 6%)! Конечно, доля нашего рынка в объемах мирового IT-рынка по-прежнему невелика (объем IT-рынка в мире в 2005 г. составил 900млрд.$), но тенденция выглядит обнадеживающе. При этом объем рынка разработки программного обеспечения в России в 2005г. составил 1,4млрд.$ ( от всего IT-рынка). В среднем этот показатель в России растет на 40-50% в год. 3)
Таким образом, основные тенденции на сегодняшний день представляются следующими:
Быстрый рост объемов IT-рынка, рынка ПО.Укрепление позиций российских компаний.По-прежнему малая доля в мировых объемах.
Для того чтобы повысить объемы рынка, необходимо повысить показатель успешности проектов, для чего отрасль нуждается не только в новых технологиях, но и в грамотных специалистах, способных эти технологии применять. Надеемся, что вы пополните эту, без сомнения почетную и востребованную когорту.
IT-проекты
Будем понимать под IT-проектами проекты в области информационных технологий. Будем далее рассматривать лишь те IT-проекты, целью которых является разработка программного обеспечения.
Зададимся следующими вопросами:
Что такое программное обеспечение (ПО)?Чем ПО отличается от обычной программы?Вчера мы с другом написали "Калькулятор". Определенно, это программа. Является ли она ПО?
Компонентное программирование
Компонентное программирование - представляет собой развитие объектно-ориентированной технологии. В отличие от ООП введен следующий уровень абстракции - классы объединяются в компоненты.
Компонент:
программный код в виде самостоятельного модуля;может быть использован в неизменном виде;может допускать настройку;обладает поведением (функциональностью).
Основной принцип компонентного программирования: сборка приложения из готовых компонент, в общем случае написанных на разных языках.
Компонент изолирован от внешнего мира своим интерфейсом - набором методов (их сигнатурами). Компонентная программа - набор независимых компонент, связанных друг с другом посредством интерфейсов.
 |
|
|
1)
Источник: The Standish Group International. Данные взяты с http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html, http://www-128.ibm.com/developerworks/rational/library/feb06/marasco/
2)
Источник: The Standish Group International. Данные взяты с http://www.infoworld.com/infoworld/img/33FEmyth2_ch2.gif
3)
Источник: Светлана Шляхтина, Компьютер Пресс, 27 января 2006г. Данные взяты с http://www.aplana.ru/news
Модульное программирование
Технология модульного программирования - оформившаяся в начале 70-х годов XX века идея разработки больших программных систем [1.4]. Это фундаментальная концепция, являющаяся основой всех современных подходов к проектированию и реализации. В то же время суть ее проста и отражает широко известные научные и технические методы, заключающиеся в поиске и реализации некоторого базового набора элементов, комбинации которых дают решение всех задач из определенного круга.
Если концепция структурного программирования предлагает некоторый универсальный алгоритмический базис, то модульное программирование состоит в разработке под конкретную задачу или круг задач (предметную область) собственного базиса в виде набора модулей, позволяющего наиболее эффективно по целому ряду критериев построить программный комплекс. Модули, входящие в базис, это целые программы (в отличие от примитивов структурного программирования), решающие некоторые подзадачи основных задач.
С применением модульного программирования появляются возможности коллективной разработки программ как набора "независимых" частей, последовательного уменьшения сложности методом разбиения сложной задачи на более простые подзадачи, наконец, возможности повторного использования созданного ранее кода.
О предмете
Задачи нашего предмета:
Изучить причины неудач IT-проектов.Выявить способы устранения этих причин.Научиться применять эти способы на практике.
Объектно-ориентированное программирование
Развитие аппаратной базы привело к возможности решения при ее помощи все более или более сложных задач, а, значит, разработки все более и более сложных программ. Программы стали большими (даже очень большими), а разработка - коллективной. Объем работы увеличился, коллективы разрослись, код "разбух", и появились новые проблемы, которых не было раньше. Неожиданно выяснилось, что возможности структурного и модульного программирования ограничены и зачастую уже не позволяют добиваться желаемого результата (либо ничего не работает, либо проект не укладывается в сроки, либо в бюджет, либо через год после написания программы выясняется, что ее невозможно модифицировать и т.д.).
Объектно-ориентированная технология в некоторой степени решила большинство описанных проблем. В отличие от рассмотренных ранее технологий, объектно-ориентированная технология работает на стадиях анализа, проектирования и программирования. В основе технологии лежат объектная модель и объектная декомпозиция [1.3].
К основным принципам объектной модели часто относят следующие:
абстракция;инкапсуляция;иерархия (наследование, агрегация);полиморфизм;модульность.
Суть объектной декомпозиции состоит в выделении в предметной области классов и объектов, а также связей между ними, и лишь потом данных и алгоритмов, которыми характеризуется каждый класс. Таким образом, именно классы становятся основным "строительным блоком" в ООП, тогда как ранее таковыми блоками являлись алгоритмы.
Причины неудачи IT-проектов
Почему IT-проекты терпят неудачи?
Почему, казалось бы, хорошо спланированный проект не укладывается во временные рамки?
Почему по прошествии некоторого времени выясняется, что имеющегося бюджета недостаточно?
Почему полученный в итоге продукт не пользуется спросом?
Проблема сложна и многогранна. Трудно перечислить все возможные причины неудачи. Остановимся кратко на некоторых из них, представляющихся нам наиболее существенными.
Причина 1. Нереалистичные временные рамки.
Правильно оценить время, необходимое для выполнения проекта, - сложная задача, решение которой часто не под силу даже опытным менеджерам. Существуют специальные критерии, которые помогают принимать правильные решения, такие как учет времени в человеко-часах и т.д. Тем не менее, задача остается сложной, колоссальное значение в ней имеет грамотный учет рисков (далее мы поговорим про это подробнее).
Причина 2. Недостаток количества исполнителей.
Иногда менеджер решает сэкономить, иногда переоценивает возможности своих сотрудников, иногда в ходе разработки выясняется, что задача сложнее, чем казалось на самом деле, - проблема недостатка рабочих рук, так или иначе, возникает достаточно часто.
Причина 3. Размытые границы проекта.
Одна из наиболее серьезных причин неудачи проекта - нечетко сформулированные цели, неоднократно меняющиеся в ходе разработки. Поверьте, многоэтажные дома и дачные домики строятся на основе применения разных технологий и материалов. Если вам доведется управлять проектом - сделайте все, чтобы четко сформулировать требования к системе в соответствии с пожеланиями пользователя. Мы поговорим про это подробнее в подразделе "Управление требованиями".
Причина 4. Недостаток средств.
Известны две крайности при планировании бюджета: чрезмерное раздувание (подход пессимиста) и чрезмерное уменьшение (подход оптимиста). Использование первого подхода чаще всего (если только ваш заказчик не совсем дилетант) приводит к тому, что ваша команда теряет проект. "Слишком дорого, сэр. Мы идем к Вашим конкурентам".
Второй подход часто применяется не только в силу оптимизма менеджмента, но и в рекламных целях, чтобы любой ценой выиграть проект. "Мы сейчас напишем меньше всех, а там видно будет". Увы, в дальнейшем приходится расплачиваться за демпинговые меры. Качественно реализовать проект за выделенные деньги оказывается просто невозможным. Представляется разумным оценивать бюджет реально с некоторой перестраховкой на случай непредвиденных ситуаций (заболел ключевой сотрудник, вышло из строя дорогостоящее оборудование...). Не выиграем этот проект - выиграем другой. Хуже, если выиграем, но провалим. В нашу состоятельность больше могут и не поверить.
Причина 5. Нехватка квалифицированных кадров.
Нехватка квалифицированных специалистов - одна из существенных проблем отрасли. Технологии развиваются с такой скоростью, что профессионалы вынуждены все время обновлять свои знания. Относительная новизна самой области IT, с одной стороны, становящееся повсеместным внедрение информационных технологий во все сферы человеческой деятельности, с другой, а, значит, все возрастающий спрос на специалистов ведут к существенной нехватке квалифицированных кадров. Конечно, все хотят принять на работу лучших. Но опыт показывает, что их не так много, и на всех не хватает. Умение из потока кандидатов выбрать тех, кто вам нужен, очень важное качество специалистов по кадрам. Часто к подбору сотрудников рекомендуют привлекать всех членов команды. То, как новичок впишется в коллектив, совсем не последнее дело.
Программирование
На протяжении всего времени обучения на факультете мы изучаем программирование. Программирование (Computer science) - молодая, активно развивающаяся область.
Долгое время человечество волнует вопрос о том, к какому роду деятельности относится программирование. В 60-х - 70-х годах XX века данный вопрос активно обсуждался на научных конференциях. Существовало 2 популярных точки зрения: "программирование это искусство" и "программирование это наука". К единому мнению придти так и не удалось. В настоящий момент мы можем добавить к этим популярным трактовкам еще одну: "программирование это бизнес". Чтобы понять, что программирование это бизнес, достаточно посмотреть, какими числами выражаются доходы современных IT-компаний. Так, например, по данным www.microsoft.com доход корпорации Microsoft за 2005 финансовый год составил 39,70 млрд. $. Впечатлены? Вам нравится этот бизнес? Тогда приступим к изучению курса.
Программы и программное обеспечение (программные продукты)
Программное обеспечение (Software) - набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207).
Таким образом, программное обеспечение - это не просто программа. Это еще и документация и руководство пользователя.
Вместо словосочетания "программное обеспечение" часто используют другое - "программный продукт". Будем далее считать, что это одно и то же. Одно из главных свойств программного продукта - продаваемость. Продаваемость - залог успеха бизнеса по разработке программного обеспечения. Если вы собираетесь что-то разработать, это должно быть востребовано на рынке. В противном случае вы потратите деньги на разработку (зарплата сотрудников, накладные расходы, налоги, аренда помещения...) и ничего не получите взамен. Вы можете написать замечательную программу. Реализовать там новый быстрый алгоритм. Она может великолепно работать, но если она никому не нужна, то вы (как компания) на пути банкротству. Допустим, в таких программах, как ваша, действительно есть потребность. Допустим, вы год упорно работали, и вот, казалось бы, настал ваш звездный час: все готово, все модули написаны, отлажены, собраны вместе и, как вам кажется, работают. Один "маленький" момент портит всю картину - если у
вас нет хорошего (!) руководства пользователя (инструкции), желательно, в русскоязычном и англоязычном вариантах, то вашу программу никто не купит, особенно за границей. Если у вас все есть, но нет специалистов по рекламе, то про вашу программу никто не узнает. Если ...
Подытожим: программный продукт - это программа со всей сопутствующей документацией, программа, которую можно продать, либо извлечь из нею финансовую выгоду другим образом.
Вернитесь мысленно к пункту 1.2 и еще раз попробуйте ответить на поставленные вопросы. Получилось? Тогда перейдем к краткому обзору текущего состояния дел в отрасли разработки ПО в России и в мире.
Структурное программирование
Возникновение концепции структурного программирования [1.4, 1.5, 1.6] связывается с именем известного голландского ученого Э. Дейкстры - в 60-х годах прошлого века он сформулировал основные ее положения.
Принцип, на котором зиждется технология структурного программирования - фундаментальная научная и техническая идея о выделении множества базисных элементов, с помощью которых можно выразить (из которых можно собрать) любой объект из некоторого широкого набора.
Итак, основной принцип технологии структурного программирования гласит: для любой простой программы можно построить функционально эквивалентную ей структурную программу, т.е. программу, сформированную на основе фиксированного базисного множества, включающего структуру последовательного действия, структуру выбора одного из двух действий и структуру цикла, то есть многократного повторения некоторого действия с проверкой условия остановки повторения.
Рис. 1.3. Блок-схемы базисных алгоритмических конструкций
На рисунке 1.3 представлено изображение указанных алгоритмических конструкций в виде блок-схем. Здесь прямоугольник обозначает обобщенное действие, ромб - проверку условия, стрелки - переход от одного действия к другому.
Под простой программой в данном случае понимается программа, имеющая ровно один вход и один выход по управлению, такая, что через все ее функциональные блоки проходит путь от входа до выхода.
Изложенный принцип представляет собой теорему о структурировании. Ее точная формулировка и доказательство не входят в нашу задачу, желающие могут обратиться к монографии [1.6].
Базисные алгоритмические конструкции обладают важным свойством - они в точности удовлетворяют определению простой программы, то есть имеют один вход и один выход, что обеспечивает возможность осуществлять их суперпозицию. Любая из трех структур может быть подставлена в остальные или в саму себя.
Таким образом, центральный технологический принцип структурного программирования состоит в том, что формулировку алгоритма и его запись в виде программы рекомендуется выполнять на основе базиса из трех алгоритмических конструкций, применяя при необходимости их суперпозицию. Результатом последовательного применения этого принципа будет более ясная структура программы (в особенности, если использовать выделение структурных уровней с помощью отступов), что, несомненно, облегчит поиск в ней ошибок и упростит ее модификацию.
Технологии программирования - путь к успеху в разработке ПО
Технология - совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства [1.1].
Уже в 60-х-70-х годах XX людям было ясно, что ввиду роста сложности решаемых при помощи компьютера задач неимоверно возрастает стоимость разработки программ. Причем, если стоимость аппаратуры растет умеренными темпами, а иногда и вовсе падает, то со стоимостью разработки программ ничего поделать не удается. Именно тогда вопрос о том, как оптимизировать процесс разработки, вышел на первый план.
Для того чтобы ответить на этот вопрос, потребовалось определить, куда уходят средства, за счет чего возрастает стоимость разработки программных систем?
Создание любой программной системы выполняется по некоторой схеме. Данная схема представляет собой последовательность стандартных этапов (очень приблизительно эта схема может выглядеть так: анализ, проектирование, разработка, тестирование, модификация). Именно на этих этапах и возникают существенные финансовые затраты. Для их оптимизации необходимо было понять, что программирование есть обычный технологический процесс, по характеру возникающих проблем мало чем отличающийся от, скажем, строительства дома или корабля.
Для сокращения затрат необходимо было конкретизировать схему, упорядочить действия, выполняемые на каждом этапе, разработать методы решения возникающих на разных этапах проблем. В довершении ко всему, схема подразумевает возвраты назад (циклы), в тех случаях, когда обнаруживается ошибка предыдущего этапа.
В результате кропотливой работы большого количества специалистов на каждом этапе и подэтапе возникли и продолжают появляться и совершенствоваться специальные технологии, позволяющие решать задачи в заданные сроки с заданным качеством.
Итак, технология программирования - совокупность методов, приемов и средств для сокращения стоимости и повышения качества разработки программных систем.
В любой серьезной компании, занимающейся разработкой программного обеспечения, на каждом этапе процесса разработки применяется большое количество разных технологий. Над созданием программного продукта работают представители таких специальностей как: аналитики, управленцы (менеджеры), тестеры, кодировщики, (программисты), технические писатели, системные администраторы, специалисты по повторному использованию, дизайнеры, специалисты по эргономике и др. Сейчас мы вспомним то, что вам должно быть известно из курса "Основы программирования", - ту часть технологий, которая наиболее устоялась и имеет отношение к общим вопросам анализа, проектирования и разработки: структурное, модульное, объектно-ориентированное и компонентное программирование.
Цели лекции
В предыдущей лекции мы познакомились с базовыми понятиями и обсудили ряд проблем, которые возникают при разработке программного обеспечения. В данной лекции мы кратко рассмотрим основные понятия программной инженерии - отрасли, имеющей непосредственное отношение к разработке ПО. Заметим, что по программной инженерии написано большое количество объемных книг (см., например, предыдущий раздел). Существует масса терминологии, подходов, схем, стандартов, технологий... В этой лекции мы не ставим цели объять необъятное. Подробный курс по программной инженерии будет прочитан позже (его место в учебном плане - 3-4 курс). В нашем курсе мы постараемся лишь познакомиться с этой важной и сложной дисциплиной. Так, мы коснемся некоторой терминологии, немного затронем теорию, кратко поговорим о проблемах. На других лекциях мы поговорим о практических подходах к решению данных проблем.
Цели программных инженеров
Целями программных инженеров являются:
Создать качественный продукт.Уложиться в бюджет.Уложиться в сроки.
Разберем по очереди эти вопросы.
Инженеры и программные инженеры
Говоря о программной инженерии, необходимо выяснить, кто такие инженеры.
За ответом обратимся к Большой Советской Энциклопедии:
Инженер (франц. ingenieur, от лат. ingenium - способность, изобретательность), специалист с высшим техническим образованием. Первоначально - название лиц, управлявших военными машинами [2.5].
Понятие гражданский инженер появилось в 16 в. в Голландии применительно к строителям мостов и дорог, затем в Англии и др. странах. Первые учебные заведения для подготовки инженеров были созданы в 17 в. в Дании, в 18 в. - в Великобритании, Франции, Германии, Австрии и др. В России первая инженерная школа основана Петром I в 1712 в Москве. В Петербурге были открыты Горное училище, приравненное к академиям (1773), Институт инженеров путей сообщения (1809), Училище гражданских инженеров (1832, с 1882 - Институт гражданских инженеров), Инженерная академия (1855). С 19 в. за рубежом стали различать инженеров-практиков, или профессиональных инженеров (по существу специалистов, имевших квалификацию техника), и дипломированных инженеров, получивших высшее техническое образование (Civil Engineer) [2.5].
Итак, инженер - дипломированный специалист, имеющий высшее техническое образование. Нетрудно догадаться, что программный инженер - инженер в области разработки программного обеспечения.
Источник материала
При написании данной лекции активно использовались материалы Иана Соммервилля (Ian Sommerville) - одного из наиболее уважаемых авторов в данной области.
Источник (на английском языке):
http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6Ian Sommerville. Software Engineering. 6th Editionhttp://www.comp.lancs.ac.uk/computing/resources/IanS/SE7Ian Sommerville. Software Engineering. 7th Edition.
Источник (на русском языке):
Иан Соммервиль. Инженерия программного обеспечения. 6 изд, и.д. "Вильямс", 2002.
Итерационный подход
Часто подходы, перечисленные ранее, используется в совокупности. В том смысле, что на некоторых стадиях при их детализации можно пользоваться как каскадной, так и эволюционной моделью. Полезность этого обусловлена реальными условиями, в которых, в частности, требования почти всегда меняются в ходе разработки. Соответственно, необходимо иметь возможность адекватно реагировать, а именно, выполнять новую итерацию, заново проходя все или почти все этапы с целью создания того, что будет удовлетворять пожеланиям пользователя.
Рассмотрим две популярные гибридные модели, использующих различные особенности перечисленных выше моделей, и основанные на итерациях.
Эволюционная модель (Evolutionary development)
Суть эволюционной модели состоит в том, что многие стадии повторяются неоднократно. Так, после анализа требований производится разработка некоторого прототипа, удовлетворяющего этим требованиям. После этого прототип может быть показан пользователям. Далее - уточнение требований и вновь проектирование, реализация, отладка и тестирование. В результате нескольких повторений этого процесса на выходе получается продукт, удовлетворяющий пожеланиям пользователей. Заметим, что вместе с продуктом развивается и документация к нему.
Недостатки эволюционного подхода в плохой структурированности системы, отсутствия внятного подробного проекта на начальных этапах, необходимости в средствах быстрой разработки. Соответственно, подход хорошо подходит для малых и средних проектов.
Качественный программный продукт
Должен предоставлять требуемую функциональность.
Если вы создали продукт, который не нужен конечным пользователям, вы не сможете его продать и не только не получите прибыль, но и не окупите затраты на его создание.
Должен быть удобным в сопровождении.
ПО должно допускать развитие в связи с изменением потребностей пользователей. Если Вы начинаете разрабатывать программный продукт, обязательно учитывайте, что мир не стоит на месте. Допустим, вы автоматизируете крупное предприятие, ориентируясь на его конкретную структуру. Подумайте над таким вопросом: какие изменения и как вы будете вносить в программную систему в том случае, если на предприятии добавится пара новых подразделений? Ваш проект должен быть достаточно гибким, чтобы поддерживать его расширение без ущерба для реализованной ранее части. Поймите, что клиент будет готов оплатить модификацию, но не создание программы с нуля.
Должен быть надежным.
Возможные неполадки в работе не должны нанести существенный, тем более невосполнимый, ущерб. Если ваша программа рассчитывает орбиту полета спутника, вам придется потратить уйму времени на то, чтобы убедиться, что она работает правильно.
Должен быть эффективным.
ПО должно эффективно использовать имеющиеся ресурсы. Вряд ли клиент согласится полностью поменять свою аппаратную базу без должного обоснования. Вот в этот момент и придется задуматься об алгоритмической оптимизации, оптимизации кода…
Должен быть удобным в использовании.
ПО должно приниматься пользователями "на ура", работа должна быть удобной и естественной. Помните, что персонал, которому предстоит работать с программой, скорее всего не придет в восторг от ее появления. Постарайтесь сделать процесс обучения как можно более простым.
Каскадная модель (Waterfall model)
Суть каскадной модели состоит в следующем:
Требования к системе определяются на начальном этапе и далее не меняются.Процесс создания ПО разбивается на следующие стандартные этапы: определение требований, проектирование, кодирование и тестирование модулей, интеграция и тестирование продукта, эксплуатация и сопровождение.Каждый этап может начаться лишь тогда, когда закончился предыдущий.
Достоинства каскадной модели в простоте и хорошей структурированности. Основные недостатки связаны с прямолинейностью и отсутствием гибкости. Дело в том, что неизменность требований является мифом. Требования менялись, меняются и будут меняться всегда в ходе разработки. Каскадная модель не учитывает этот факт. В итоге, если ничего не предпринимать, конечный продукт будет отличаться от потребностей пользователей. Более того, скорее всего и документация в конце не будет отражать реальной ситуации (например, ТЗ, составленное в начале не будет совпадать с тем, что получится в конце). Поэтому каскадная модель в чистом виде перспективна лишь для очень больших проектов, где хорошая структурированность выходит на первые роли, а также в тех случаях, когда требования хорошо осознаны и зафиксированы в самом начале.
Модель пошаговой разработки
Модель пошаговой разработки (Миллс) состоит в выполнении стандартных шагов. В итоге каждого шага - работающий прототип. Требования фиксированы во время шага. Для шага можно применять каскадную или эволюционную модель.
Особенность состоит в том, что наиболее важные для заказчика компоненты разрабатываются в самом начале, в результате чего он может оценить, насколько конечный продукт будет соответствовать его потребностям, и при необходимости внести коррективы.
Одно из ответвлений - Экстремальное программирование.
Модели процесса
Итак, некий "каркас" процесса обычно выглядит так:
Спецификация.Разработка.Аттестация.Модернизация.
Сам этот "каркас" можно приводить в жизнь по-разному. Существуют общие модели процесса, которые определяют, как организовать работу по "каркасу" на практике. Фактически, модель процесса - некое абстрактное представление процесса на верхнем уровне. Так, модель не рассматривает детально содержимое каждого из этапов. Модель рассматривает состав этапов и способы их претворения в жизнь.
Рассмотрим некоторые устоявшиеся модели процесса разработки программного обеспечения.
Область действия программной инженерии
Программная инженерия имеет дело со всеми аспектами создания ПО.
В западной литературе часто используются термины: software engineering, system engineering и computer science. В чем разница?
Computer science имеет дело с теорией и основами разработки ПО.
System engineering связано с вопросами разработки систем с участием компьютеров (архитектура, дизайн, интеграция, ПО...).
Software engineering - часть System engineering, имеющая дело с разработкой ПО.
Итак, computer science предоставляет собой безусловно важный, но преимущественно теоретический базис. На практике его недостаточно. К числу открытых можно отнести следующие проблемы:
Поиск финансирования.Работа с заказчиком.Подбор персонала.Этические вопросы. Микроклимат в коллективе. Команда.Обеспечение качества программного продукта....
Всем этим занимается программная инженерия и программные инженеры.
Понятие процесса
Процесс создания программного обеспечения - совокупность мероприятий, целью которых является создание или модернизация программного обеспечения [2.1, 2.2, 2.3].
Выделяют 4 основных мероприятия (стадии) процесса:
Спецификация: формулирование спецификаций определяет основные требования к ПО (что должна делать система).
Разработка: создание ПО в соответствии со спецификациями.
Аттестация: проверка ПО на соответствие потребностям заказчика.
Модернизация: развитие ПО в соответствии с изменившимися потребностями заказчика.
Все стадии основаны на специальных технологиях. Например, рассмотренные кратко в предыдущей лекции модульное, структурное, объектно-ориентированное, компонентное программирование относятся к стадии Разработки.
Каждая организация может организовать процесс создания программного обеспечения так, как ей это представляется разумным. Этот процесс может иметь разную степень формализации. Так, создание продукта может идти по принципу "вечером обсудили и договорились", но этот принцип работает только для команд из 2-3 человек в достаточно простых проектах. Возможна другая крайность - каждое действие жестко определено и прописано в описании процесса. В этом случае возникает необходимость длительного предварительного обучения сотрудников работе в рамках этого, безусловно, сложного описания. Подобный подход, конечно, порождает и другие накладные расходы. Например, то, что вполне могло бы быть решено в частной беседе, теперь приходится долго и нудно "проводить" через соответствующий формализм. Пожалуй, такая степень формализации может пойти на пользу для очень больших, тем более распределенных, коллективов, решающих задачи большой сложности. Для небольшого или среднего проекта описанная степень формали зации принесет больше вреда, чем пользы (хорошая аналогия - забивание гвоздей микроскопом).
Несмотря на естественные отличия в описаниях процессов, как правило, в нем присутствуют рассмотренные стадии. Они могут иначе называться, детализироваться, но от них никуда не уйти.
Существуют известные, хорошо проработанные процессы: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и другие.
Эти процессы (ко второму в большей степени применим термин методология) имеют свои разновидности и могут применяться как для малых и средних компаний и проектов, так и для больших.
Процесс создания программного обеспечения
Сразу оговоримся, что по данному разделу написано немало литературы. Существуют многостраничные книги, ГОСТ-ы, стандарты... На сегодняшний день мы можем смело утверждать, что при некотором общем теоретическом (философском) и практическом понимании того, что происходит в отрасли, и что нужно делать для лучшей организации при создании программного обеспечения, терминология в данной области абсолютно не устоялась. Мы в данном курсе ориентируемся на вариант И. Соммервилля. При этом рекомендуем ознакомиться и с другими книгами и материалами. Каждая новая книга предложит вам новую терминологию. Не пугайтесь этого. Пройдет время, и терминология устоится. Общий смысл изложения во многих книгах по программной инженерии совпадает.
Программная инженерия как инженерная дисциплина
Теперь попробуем ответить на вопрос, что такое программная инженерия.
Программная инженерия (инженерия программного обеспечения, software engineering) - инженерная дисциплина, связанная с теорией, методами и средствами профессиональной разработки ПО [2.1, 2.2, 2.3].
Как было выяснено ранее, программное обеспечение представляет собой собственно программы плюс вся сопутствующая документация. На протяжении последних десятилетий стоимость разработки ПО неуклонно растет, в результате чего эта стоимость становится весьма высокой. Программная инженерия способствует решению этой проблемы.
Программные инженеры и научная среда
Взаимодействие с научной средой - один из способов повышения эффективности деятельности. Возможная выгода от сотрудничества с учеными:
Новые технологии.Новые методы, алгоритмы.Анализ новых перспективных разработок.Исследовательская работа в смежных областях.
Помощь ученых жизненно необходима в по крайней мере в двух ситуациях:
Там, где в принципе не решить задачу своими силами.Там, где есть специалисты, но нет времени и ресурсов для исследований.
Этот подход широко применяется современными IT-компаниями: Intel, Microsoft, IBM и другими.
Создание ПО должно укладываться в бюджет
Если вы не укладываетесь в бюджет, вам придется просить дополнительные деньги на разработку. Иногда вам пойдут на встречу, иногда нет. В любом случае, ваша репутация пострадает. Посмотрим, из чего чаще всего состоят расходы на создание ПО:
60% - разработка;40% - тестирование.
Думая о том, сколько денег потратить разработку, не забывайте, что последующие этапы отнимут не меньше средств.
Расходы на развитие иногда могут превысить расходы на создание, впрочем, многое тут зависит от того, как вы выполнили проектирование. Детали зависят от специфики предметной области, требований к ПО, используемых подходов к организации разработки.
Создание ПО должно укладываться в сроки
Залог успеха - строгое соблюдение следующих принципов:
Грамотное планирование.Анализ возможных рисков и способы реагирования.Борьба за четкие границы проекта.Мотивирование сотрудников.
Спиральная модель разработки
Спиральная модель (Боэм) оказалась чрезвычайно популярной. Суть ее состоит в том, что вместо действий с обратной связью происходит выполнение различных этапов по спирали. Каждый виток спирали соответствует 1 итерации. Заранее фиксированных фаз нет, их состав зависит от потребностей.
Каждый виток разбит на 4 сектора: определение целей, оценка и разрешение рисков, планирование, разработка и тестирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
Главное отличие от других моделей состоит в акценте на анализ и преодоление рисков (об этом мы еще будем говорить более подробно в 3 разделе нашего курса).
Вспоминая предыдущую лекцию
Наша предыдущая лекция целиком была посвящена знакомству с терминологией и введению в предмет. Сформулируем кратко некоторые выводы:
Программирование (Computer science) - молодая, активно развивающаяся область, за полвека своего развития преодолевшая огромный путь. Будучи как искусством, так и наукой, в наше время термин программирование приобрел качественно новую окраску, став одной из отраслей бизнеса.Под IT-проектами можно понимать любые проекты в области информационных технологий. Мы далее будем рассматривать лишь те IT-проекты, целью которых является разработка программного обеспечения.Программное обеспечение (Software) - набор компьютерных программ, процедур и связанной с ними документации и данных. Таким образом, программное обеспечение - это не просто программа. Это еще и документация и руководство пользователя. Вместо термина программное обеспечение часто используют термин программный продукт.Для того чтобы бизнес, связанный с разработкой ПО, был успешным, необходимо выпускать качественное ПО, интересное потенциальным пользователям, делать это в срок, укладываться в имеющийся бюджет. К сожалению, доля проваленных проектов по-прежнему катастрофически высока.Анализ рынка ПО в мире показывает большие темпы роста. В отрасль вкладываются огромные деньги. В России в отрасли IT наблюдается бум. Отрадный факт - укрепление Российских IT-компаний.Основными причинами неудачи IT-проектов являются:
Причина 1. Нереалистичные временные рамки.
Причина 2. Недостаток количества исполнителей.
Причина 3. Размытые границы проекта.
Причина 4. Недостаток средств.
Причина 5. Нехватка квалифицированных кадров.
Технологии программирования - путь к успеху в разработке ПО. Использование различных технологий позволяет преодолевать сложность решаемых задач и, соответственно, сложность создания качественного ПО. Среди основных технологий можно выделить следующие: структурное программирование, модульное программирование, объектно-ориентированное программирование, компонентное программирование.
Актеры и варианты использования в UML
Программная система не функционирует сама по себе. Программная система функционирует под воздействием актеров (Actor) - пользователей, машин и других программ. При этом актер ожидает, что система ведет себя строго определенным образом. Актер оказывает воздействие - система выдает ожидаемый результат. В случае, если ожидаемого результата нет, требования пользователя не удовлетворены со всеми вытекающими отсюда результатами. Таким образом, актер в UML - человек, машина или программа, воздействует на систему, является внешним по отношению к ней. Модель того, как воздействие приводит к результату, называется Вариантом использования (Use case). Актеры и варианты использования имеют специальные обозначения в UML:
Рис. 3.5.
Актеры и варианты использования общаются посредством посылки сообщений. Сообщения могут идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и может быть опущена.
Рис. 3.6.
Выделим актеров и варианты использования в рассмотренном ранее примере с системой бронирования билетов (SRS). Анализ постановки задачи показывает наличие у системы двух актеров: "Пользователь" и "Администратор". Определимся с вариантами использования. Необходимо отметить, что выбор актеров и вариантов использования до некоторой степени условен и может отличаться у разных специалистов по анализу и проектированию. Принятые проектные решения определяют дальнейший выбор архитектуры системы и существенно влияют на успех всего процесса разработки. При этом "хороших" вариантов может быть несколько.
Перечень Вариантов использования для нашей задачи может быть, например, таким:
Забронировать билет.Подобрать рейс.Работать с данными.Управлять рейсами.Работать с БД аэропорта.
Для визуального представления актеров, вариантов использования и отношений между ними в UML предусмотрена специальная диаграмма - диаграмма вариантов использования. Ниже приведена диаграмма для рассматриваемого примера:
Рис. 3.7.
Приведем некоторые дополнительные соображения [3.3]:
При таком моделировании обращают внимание на поведение системы, а не на ее реализацию.Хорошая модель описывает основное поведение системы, не являясь слишком подробным.Подобная модель позволяет проверить, удовлетворит ли система требования заказчика.Система средних размеров может быть описана большим количеством вариантов использования.Варианты использования могут описываться разными сценариями.
На последнем пункте остановимся подробнее. Очевидно, название варианта использования не дает полного представления о том, как он претворяется в жизнь. Для описания сценария работы варианта использования UML содержит специальные средства. Основное из них - диаграмма действия.
Диаграмма действия это блок-схема, которая отображает динамику в поведении системы. Заметим, что эта диаграмма может использоваться не только для описания сценариев Варианта использования.
Приведем пример соответствующей диаграммы для варианта использования Бронирование билетов в системе SRS.
Рис. 3.8.
Алгоритмическая и объектная декомпозиции Классы и объекты
Принципиально можно выделить 2 вида разбиения предметной области на составляющие элементы:
Алгоритмическая декомпозиция (основные элементы программы - строительные блоки - алгоритмы).Объектная декомпозиция (основные элементы программы - виды абстракций (классы) и представители этих классов (объекты)).
В соответствии с алгоритмической декомпозицией предметной области мы при анализе задачи пытаемся понять, какие алгоритмы необходимо разработать для ее решения, каковы спецификации этих алгоритмов (вход, выход), и как эти алгоритмы связаны друг с другом. В языках программирования данный подход в полной мере поддерживается средствами модульного программирования (библиотеки, модули, подпрограммы).
В рамках объектной декомпозиции мы пытаемся выделить основные содержательные элементы задачи, разбить их на типы (классы). Далее для каждого класса абстракций мы определяем его свойства (данные) и поведение (операции), а также, как эти классы абстракций взаимодействуют друг с другом.
На сегодняшний день объектный подход и его основы - объектная модель и объектная декомпозиция - поддерживаются современными объектно-ориентированными языками программирования (Object Pascal, C++, Java, C#…).
Анализ и проектирование Некоторые частные вопросы
Внимание! Презентации семинаров к данной лекции находятся
В прослушанных ранее программистских дисциплинах неоднократно рассматривалась типовая схема решения задач с использованием вычислительной техники. При этом особое внимание уделялось тому, что непосредственное программирование или написание кода начинается далеко не сразу. Более того, этапы, предшествующие разработки не менее важны и сложны. Примерная схема, отражающая процесс от постановки задачи до выпуска готового продукта может выглядеть так:
Рис. 3.1.
Или в укрупненном виде:
Рис. 3.2.
3-я часть и элементы 2-ой части этой цепочки изучаются в курсе "Методы программирования".
1-я и 2-я части составляют объект изучения отдельного курса "Анализ и проектирование".
В настоящий момент в анализе и проектировании преобладает объектный подход (изучен в 1-2 семестрах).
Вспомним суть объектного подхода.
Анализ постановки - полное описание
Задача является математической. Система должна уметь решать однокритериальную задачу поиска кратчайших путей на графах. Критерий - цена.Система распределенная: так как в каждом аэропорте своя база направлений полетов самолетов, то знают о рейсе только аэропорты-соседи по рейсам.
Объекты системы: распределенное хранилище рейсов, покупатель билетов, менеджер рейсов.
Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.
Среди причин:
Отсутствие рейсов в желаемом направлении даже с учетом пересадок.Нехватка денег.
В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.
Менеджер рейсов: должен иметь следующие возможности:
создания и удаления аэропортов в системе.создания и удаления рейсов в аэропортах.
Ассоциация
Ассоциация - связь между сущностями (классами, объектами). Ассоциация показывает наличие структурной связи между экземплярами (объектами). Структурная связь реализуется через поле класса. В обозначениях UML направление может быть не указано (двусторонняя связь).
Рис. 3.18.
Частные случаи ассоциаций: агрегация и композиция
Агрегация предполагает, что 0 или более объектов одного типа включены в 1 или более объектов другого типа.
Композиция - вариант агрегации, в котором каждый объект второго типа может быть включен ровно в 1 объект первого типа.
Рис. 3.21.
Диаграммы UML
Диаграммы UML предназначены для визуального отображения моделей и их компонентов.
UML 2.0 содержит 13 типов диаграмм. В том числе:
Структурные диаграммы (6).Диаграммы поведения (3).Диаграммы взаимодействия (4).
Рассмотрим каждую из групп подробнее:
Структурные диаграммы:
Диаграмма классов - показывает классы, их атрибуты и связи между классами.Диаграмма компонентов - показывает компоненты и связи между ними.Структурная диаграмма - показывает внутреннюю структуру классов и связи с внешним миром.Диаграмма развертывания - показывает, как ПО размещается на аппаратуре (серверах, рабочих станциях...).Диаграмма объектов - показывает структуру системы в конкретный момент времени, объекты, их атрибуты...Диаграмма пакетов - показывает, как система раскладывается на крупные составные части и связи между этими частями
Диаграммы поведения:
Диаграмма действия - показывает потоки информации в системе.Диаграмма состояния - представляет собой конечный автомат, показывающий функционирование системы.Диаграмма вариантов использования - показывает работу системы с точки зрения пользователей.
Диаграммы взаимодействия
Диаграмма кооперации - показывает структурную организацию участвующих во взаимодействии объектов.Диаграмма взаимодействия (новация UML 2.0).Диаграмма последовательности - показывает временную упорядоченность событий.Временная диаграмма - диаграмма связана с временными рамками проекта.
Достоинства повторного использования Виды повторного использования
Достоинства повторного использования (по Соммервилю, [3.1]):
Повышение надежности.Уменьшение проектных рисков.Эффективное использование специалистов.Соблюдение стандартов (пример: пользовательский интерфейс).Ускорение разработки.
Повторное использование достигается за счет следующих приемов (видов использования):
Компонентная разработка. Часть компонентов уже разработаны ранее, имеют четко описанный интерфейс. Они используются в качестве "кирпичиков" в новой системе.Использование паттернов (шаблонов) проектирования. Применяются известные подходы к решению некоторых встречавшихся ранее проблем.Использование стандартных прикладных (MKL, MFC…) и системных (API) библиотек.
| По материалам www.wikipedia.org, www.uml.org |
| Закрыть окно |
Идея повторного использования Важность повторного использования
Повторное использование - применение уже существующих наработок в разрабатываемом ПО.
Повторное использование - важный элемент проектирования. Необходимо проектировать новые элементы системы с тем, чтобы их в последствии можно было применять при разработке других систем. Кроме того, при проектировании системы необходимо рассматривать возможность использования того, что уже есть и работает.
Девиз: не надо изобретать велосипед, если он уже изобретен.
Идея визуального моделирования
Вспомним, в чем состоит основная проблема в разработке ПО? Проекты не укладываются в сроки, бюджет, не удовлетворяют требованиям.
Как решать эту проблему? На помощь приходит моделирование. Под моделью обычно понимают упрощенное представление объектов и явлений реального мира.
Ответим на вопрос, зачем строят модели? Модели строят для того, чтобы лучше понять исследуемую систему.
Классики проклассифицировали задачи и принципы моделирования. Приведем здесь эту, несомненно, важную, классификацию.
Задачи моделирования [3.3]:
Визуализация системы в ее некотором состоянии.Определение структуры и поведения системы.Получение шаблона для создания системы.Документирование принятых решений.
Принципы моделирования [3.3]:
Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.Каждая модель может быть воплощена с разной степенью абстракции.Лучшие модели - те, что ближе к реальности.Наилучший подход при разработке сложной системы - использовать несколько почти независимых моделей.
Как уже упоминалось ранее, одним из наиболее популярных подходов к моделированию является объектный подход. В соответствии с этим подходом в результате OOA и OOD мы получаем "хороший" проект программной системы, прозрачный, удовлетворяющий требованиям, удобный для тестирования и отладки, коллективной разработки, развиваемый, допускающий повторное использование компонентов.
К сожалению, даже использование таких мощных средств, как объектный подход, не гарантирует нам успех. К сожалению, в больших проектах сложность моделируемого объекта (и, соответственно, сложность проекта) такова, что проект слишком велик для адекватного восприятия одним человеком, по крайней мере, в уме.
Это и означает необходимость визуального моделирования.
Идея визуального моделирования состоит в графическом отображении обсуждаемых и принимаемых проектных решений. При этом достигаются следующие цели:
Визуализация упрощает понимание проекта в целом.Визуализация помогает согласовать терминологию и убедиться, что все одинаково понимают термины.Визуализация делает обсуждение конструктивным и понятным.
Для визуального моделирования нужна специальная нотация или язык.
UML (unified modeling language) - это язык для визуализации, специфицирования, конструирования, документирования элементов программных систем [3.3]. UML - язык общего назначения, предназначенный для объектного моделирования.
Интерфейсы
Определимся с тем, что мы в данном случае понимаем под Интерфейсом.
Интерфейс определяет границу между спецификацией того, что делает абстракция, и реализацией того, как она это делает [3.3].
Интерфейс - это набор операций, используемых для специфицирования услуг, предоставляемых классом или компонентом [3.3].
Смысл использования Интерфейса состоит в отделении деталей реализации от функциональности. Так, класс, подсистема, компонент обычно предоставляют некоторую функциональность, которой могут пользоваться другие классы, подсистемы, компоненты. Описание этой, доступной извне, функциональности содержится в Интерфейсе.
Во многих языках программирования понятие Интерфейс включено в объектную модель, что сообразно отражается на синтаксисе (Object Pascal, Java и др.). С++, к сожалению, не содержит понятия Интерфейс, поэтому Интерфейсы моделируются посредством использования классов.
увеличить изображение
Рис. 3.12.
История языка UML
Рассмотрим кратко историю языка UML1). К 1994 году существовало несколько нотаций для визуального отображения принимаемых проектных решений и несколько методов анализа и проектирования. В 1994 году состоялось знаковое событие - Grady Booch и James Rumbaugh, сотрудники фирмы Rational Software, объединили свои методы проектирования и анализа, создав так называемый Unified method. С этого момента процесс стандартизации договоренностей вошел в рабочий ритм. Приведем важные вехи этого пути:
1994: Grady Booch & James Rumbaugh (Rational Software) объединили методы Booch (проектирование) и OMT (анализ) ->Unified method.1995: присоединился Ivar Jacobson (автор метода OOSE). Впоследствии группа авторов Booch, Rumbaugh и Jacobson вместе выпустила не одну книгу, ставшую бестселлером (например, см. список литературы). Эту троицу шутливо называли "three amigos", намекая на то, как жарко они спорили по поводу принимаемых решений.1996 - Идея о Unified Modeling Language (three amigos).1996 - создан консорциум UML Partners под руководством three amigos.Июнь, Октябрь 1996 - UML 0.9 & UML 0.91.Январь 1997 - спецификации UML 1.0 предложены OMG (Object Management Group).Август 1997 - спецификации UML 1.1 предложены OMG.Ноябрь 1997 - UML 1.2 - результат адаптации OMG.Июнь 1999 - UML 1.3.Сентябрь 2001 - UML 1.4.Март 2003 - UML 1.5.
Принятый стандарт:
ISO/IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.Октябрь 2004 - UML 2.0.
Классы
Рис. 3.9.
Обозначения модификаторов доступа:
| + | public |
UML предусматривает возможность написания комментариев
UML предусматривает возможность написания комментариев (заметок). Делается это следующим образом:
Рис. 3.16.
Компоненты
Компонент - физическая заменяемая часть системы, совместимая с одним набором интерфейсов и обеспечивающая реализацию какого-либо другого [3.3]. Компонент может разрабатываться и тестироваться независимо от системы.
Виды компонентов:
Исходные файлы (.cpp, .h, .java…).Бинарные файлы (.dll, .ocx…).Исполняемые файлы (.exe).
По смыслу компонент представляет собой реализацию подсистемы. На этапе проектирования мы работаем с подсистемами. На этапе реализации - с компонентами.
Рис. 3.15.
Краткое описание
На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.
При формулировании требований менеджеры упомянули, что рейсы спланированы так, что до пункта назначения можно долететь с пересадками. Одно из требований заключалось в том, чтобы система помогала покупать билеты в зависимости от пожеланий пользователя.
Кратность
Кратность - способ конкретизации характера отношения. Показывает тип отношения 1:1, 1:M, N:1, N:M.
Рис. 3.20.
| Вид кратности | Значение |
| * или 0..* | ?0 |
| 1..* | ?1 |
| обычно 0 или 1 | |
| 1 | Ровно 1 |
| 3,5..6 | {3,5,6} |
Модели UML
UML позволяет описывать систему следующими моделями:
Модель функционирования (показывает, как описывается функциональность системы с точки зрения пользователя).Объектная модель (показывает, как выглядит проект системы с точки зрения объектного подхода).Динамическая модель (показывает, как взаимодействуют друг с другом компоненты системы в динамике, с течением времени). Демонстрирует, какие процессы происходят в системе.
Направление и навигация
Заметим, что наличие направления связано с понятием Навигация. Навигация означает, что в направлении стрелки один объект "видит" другой, в то время как обратное не выполняется.
Рис. 3.19.
Отношения между элементами модели
UML поддерживает следующие виды отношений между элементами модели:
Зависимость.Ассоциация.Обобщение (наследование).Реализация (для Интерфейса).
Отношения показывают наличие связей между элементами модели и семантику этих связей.
Рассмотрим каждый из этих типов отношений.
Пакеты
Пакет - структурная единица для группировки элементов модели, в частности, классов.
Пакет - это способ организации элементов модели в более крупные блоки, которыми впоследствии позволяется манипулировать как единым целым. Хорошо спроектированный пакет группирует семантически близкие элементы, которые имеют тенденцию изменяться совместно [3.3].
Рис. 3.13.
Подсистемы
На этапе проектирования системы классы и пакеты могут объединяться в подсистемы. Подсистема - структурная единица. Каждая подсистема имеют свою область ответственности и реализует некоторую функциональность. Подсистема реализует Интерфейс, который описывает ее поведение. В рассматриваемом учебном примере SRS примерами подсистем являются: подсистема бронирования билетов; подсистема доступа к данным...
Рис. 3.14.
Понятия UML
Для описания структуры: Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет.
Для описания поведения: Действие, Событие, Сообщение, Метод, Операция, Состояние, Вариант использования.
Для описания связей: Агрегация, Ассоциация, Композиция, Зависимость, Наследование.
Некоторые другие понятия: Стереотип, Множественность, Роль.
ООП и структуры хранения Стек
Постановка задачи:
Необходимо разработать структуру хранения Стек.
Примечания:
Не учитывать необходимость перераспределения памяти.Считать, что элементы целого типа.
Анализ и проектирование.
Данные:
MemSize - максимальное количество элементов.DataCount - количество элементов в стеке.pMem - указатель на память для хранения значений.
Операции:
IsFull - проверка на полноту.IsEmpty - проверка на пустоту.Get - взять элемент с вершины.Put - положить элемент в стек.
Рис. 3.3.
Рассмотрим финальный результат нашего проектирования (используется нотация UML):
Рис. 3.4.
Принципы объектного подхода
Рассмотрим наиболее важные принципы объектного подхода.
Абстрагирование применяется при решении многих задач. Любая построенная нами модель позволяет абстрагироваться от реального объекта, подменяя его изучение исследованием формальной модели. Абстрагирование в ООП позволяет выделить основные элементы предметной области, обладающие одинаковой структурой и поведением. Такое разбиение на классы позволяет существенно облегчить анализ и проектирование системы.
Инкапсуляция - важнейший элемент объектного подхода. Суть его заключается в скрытии деталей внутренней реализации. Инкапсуляция оказывает положительное влияние на защиту данных и существенно повышает шансы безболезненной замены одной из частей системы ее новой версией при условии сохранения интерфейса.
Иерархия помогает разбить задачу на уровни и постепенно ее решать, постепенно увеличивая детализацию рассмотрения. Иерархия упорядочивает абстракции. К счастью, разные иерархии можно обнаружить практически в любой системе. Агрегация и наследование - примеры таких иерархий. Они подчеркивают тот факт, что новые абстракции могут быть созданы на основе уже имеющихся.
Полиморфизм позволяет иметь естественные имена и выполнять действия, релевантные ситуации, разбираясь на этапе работы программы, какой из методов необходимо вызвать. Полиморфизм неразрывно связан с наследованием и поздним связыванием.
Составные части объектного подхода
Как было сказано ранее, основами объектного подхода являются объектная модель и объектная декомпозиция. Рассмотрим кратко составные части объектного подхода, грамотное выполнение которых, как правило, приводит к созданию качественного программного продукта.
Объектный подход:
OOA (object oriented analysis) - объектно-ориентированный анализ.OOD (object oriented design) - объектно-ориентированное проектирование.OOP (object oriented programming) - объектно-ориентированное программирование.
Рассмотрим кратко эти ключевые понятия (определения Г. Буча):
Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области [3.2].
Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы [3.2].
Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования [3.2].
В русскоязычной литературе, как правило, под аббревиатурой ООП рассматривают все 3 составляющих объектного подхода. Далее и мы будем следовать этому принципу.
Курсы из цикла "Методы программирования" и, конкретнее, "Объектно-ориентированное программирование" преимущественно концентрируются на OOP. Данный курс, по крайней мере, его теоретическая часть основное внимание уделяет OOA и OOD.
Структура системы и ее описание средствами UML
В данном разделе рассматриваются элементы UML, предназначенные для описания структуры проектируемой программной системы. Наше изложение устроено следующим образом: для стандартных понятий, известных из курса ООП, мы приводим только обозначения. Для других прежде всего даем определение и краткую характеристику. Итак, приступим.
Вместо введения
При изучении материалов по визуальному моделированию и языку UML в качестве основного источника рекомендуется классическая книга [3.3]:
Г. Буч, Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя. - ДМК-Пресс, Питер, 2004.
Дополнительно рекомендуется следующая книга: G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004.
Большое количество материалов может быть найдено на сайте www.uml.org.
Вспоминая предыдущую лекцию
Наша предыдущая лекция целиком была посвящена введению в программную инженерию. При этом мы охватили следующие темы:
Программная инженерия, основные понятия
Инженеры и программные инженерыПрограммная инженерия как инженерная дисциплинаОбласть действия программной инженерииЦели программных инженеровПрограммные инженеры и научная среда
Процесс создания ПО
Понятие процесса. Основные фазы.Модель процесса. Каскадная и эволюционная модель.Итерационный подход. Модель пошаговой разработки и спиральная модель.
Зависимость
Зависимость - связь между сущностями (классами, объектами). Зависимость показывает, что изменения в одной сущности могут повлиять на другую сущность. Зависимость - не структурная связь. Возникает через локальную, глобальную переменные или параметр метода.
Рис. 3.17.
