Построитель графиков на C#

      1.2. Основные этапы разработки программных продуктов 

      До  того, как начать программирование классов, их свойств и методов, необходимо определить, чем же являются сами эти классы. Более того, нужно дать ответы на такие вопросы, как: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами.

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

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

      Как показано на рис.1.3, разработка программных продуктов обычно включает следующие этапы жизненного цикла:

• Выявление сущности требований к программному продукту (концептуализация).
• Разработка модели требуемого поведения системы (анализ).
• Создание архитектуры для реализации (проектирование).
• Итеративное выполнение реализации (эволюция).
• Управление эволюцией продукта в ходе эксплуатации (сопровождение).

       Рис.1.3 Процесс проектирования 

      Основная  философия разработки программных продуктов состоит в постепенном развитии. Как его определяет Вонк, "при разработке методом [2]

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

      1.2.1. Концептуализация 

      Концептуализация - определение понятий, отношений и механизмов управления, необходимых для описания решения задач в избранной предметной области.

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

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

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

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

      1.2.2. Анализ разрабатываемого приложения 

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

          Как утверждает Меллор, “цель анализа – дать описание задачи [2]. Описание должно быть полным, непротиворечивым, пригодным для чтения и обозрения всеми заинтересованными сторонами, реально проверяемым.” Говоря простым языком, цель анализа – представить модель поведения системы.

      Надо  подчеркнуть, что анализ сосредоточен не на форме, а на поведении. На этой стадии неуместно заниматься проектированием классов. Анализ должен объяснять, что делает система, а не то, как она это делает. Любое, сделанное на стадии анализа (вопреки этому правилу) утверждение о том "как", может считаться полезным только для демонстрации поведения системы, а не как проверяемое требование к ее проектированию. В этом отношении цели анализа и проектирования весьма различны. В анализе мы ищем модель мира, выявляя абстракции (т.е. классы и объекты их роли, обязанности и взаимодействия), существенные с точки зрения клиента (pис.1.4). В проектировании мы изобретаем искусственные персонажи, которые реализуют поведение, требуемое анализом. В этом смысле, анализ - это деятельность, которая сводит вместе пользователей и разработчиков системы, объединяя их написанием общего словаря предметной области. Нестоит стремиться к исчерпывающему пониманию поведения системы. Также нестоит делать полный анализ до начала проектирования т.к. это не только невозможно, но и нежелательно. Процесс построение системы поднимает вопросы о ее поведении, на которые нельзя дать гарантированный ответ, занимаясь только анализом. Достаточно выполнить анализ всех первичных элементов поведения  

       Рис.1.4 Абстракция фокусируется на существенных с точки зрения   наблюдателя характеристиках объекта. 

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

      ДеШампо считает, что результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов [2]. На этом этапе применяют диаграмму классов для иллюстрации их поведения и взаимодействия между ними.

      Степень совершенства анализа будет измеряться, в частности, его полнотой и простотой.  
 
 

      1.2.3. Проектирование разрабатываемого приложения 

      Этап  проектирования структуры программы  заключается в разработке детальной  схемы, на которой указываются классы, их свойства

и методы, а также различные взаимосвязи меду ними. Результатом должна

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

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

      Имеется два основных результата проектирования: описание архитектуры и выработка общих тактических приемов.

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

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

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

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

      1.2.4. Эволюция приложения 

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

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

      Таким образом, эволюция - это и есть процесс  разработки программы. Как пишет  Андерт, проектирование "есть время  новшеств, усовершенствований, и неограниченной свободы изменять программный 

код, чтобы  достигнуть целей [2]. Производство - управляемый методичный процесс подъема качества изделия к надлежащему уровню".

        Пейдж-Джонс называет ряд преимуществ такой поступательной [2] разработки:

• Обеспечивается обратная связь с пользователями, когда это больше   всего необходимо, полезно и значимо.
• Пользователи получают несколько черновых версий системы для сглаживания перехода от старой системы к новой.
• Менее вероятно, что проект будет снят с финансирования, если он   вдруг выбился из графика.
• Главные интерфейсы системы тестируются в первую очередь и   наиболее часто.
• Более равномерно распределяются ресурсы на тестирование.
• Реализаторы могут быстрее увидеть первые результаты работы системы, что их морально поддерживает.
• Если сроки исполнения сжатые, то можно приступить к написанию и отладке программ до завершения проектирования.

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