Проектирование программного обеспечения

    Сегодня процесс создания сложных программных приложений невозможно представить без разделения на этапы жизненного цикла. Под жизненным циклом программы будем понимать совокупность этапов:
    • Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
    • Проектирование структуры программы
    • Кодирование (набор программного кода согласно проектной документации)
    • Тестирование и отладка
    • Внедрение программы
    • Сопровождение программы
    • Утилизация

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

    UML — является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

    Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):
    • Диаграмма вариантов использования (use case diagram)
    • Диаграмма классов (class diagram)
    • Диаграмма состояний (statechart diagram)
    • Диаграмма последовательности (sequence diagram)
    • Диаграмма кооперации (collaboration diagram)
    • Диаграмма компонентов (component diagram)
    • Диаграмма развертывания (deployment diagram)


    Диаграмма вариантов использования (use case diagram)


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

    image

    Диаграмма классов (class diagram)


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

    image

    Диаграмма состояний (statechart diagram)


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

    image

    Диаграмма последовательности (sequence diagram)


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

    image

    Диаграмма кооперации (collaboration diagram)


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

    image

    Диаграмма компонентов (component diagram)


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

    image

    Диаграмма развертывания (deployment diagram)


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

    image

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

    Я убежден, что программист в первую очередь это кодер – он НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…. Проектировщик же должен начиная от абстрактных диаграмм (описывающих предметную область) до диаграмм представляющих структуру данных, классов и процессов их взаимодействия, детально шаг за шагом все расписать. То есть сложность работы и зарплата проектировщика должна быть на порядок выше чем у программиста == кодера. Простите за крамолу....
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 36

      +2
      Всем прекрасен RUP, одно но — цикл «проектирование» — «UML-спеки» — «кодирование» крайне длителен и неповоротлив; и в случае, если рахитекторы профакапили хотя бы одну итерацию, выдав кривой дизайн, 80% можно считать, что продукт не выйдет в срок.
      Ну а так как все предусмотреть невозможно, в RUP приходится или брать архитекторов за космические деньги, или хз… привыкать и терпеть, наверное :)
        +5
        Я не хочу преуменьшать заслуги разработчиков, тестировщиков и других ролей, но архитекторы — это 80% успеха проекта.
        И да, они стоят очень дорого и при этом экономят массу времени тестировщикам, разработчикам и деньги заказчика. Т.ч. заплатить 100К архитектору и 30К всем остальным — будьте уверены, продукт получится качественый и выйдет в срок (если взять за основу идеальную ситуацию).
          +1
          Я об этом и говорю ) У нас было соотношение ~~ 250К против 30-40К :)

          Впрочем, существует противоположная точка зрения — минимум формализма при разработке, откуда растут ноги Agile. Опираясь на мнение Брукса, я могу сказать, что и сам пока не готов ответить, какой подход эффективнее для среднего по размерам проекта. Вероятно, профессионал сможет заставить проект «взлететь» в любом подходе — только управление рисками будет кардинально отличаться.

          BTW, крупные проекты (100К ч/часов) только так и решаются — Agile из-за своих обильных коммуникаций «каждый с каждым» здесь сливает.
            0
            Не понял, как коммуникации «каждый с каждым» влияют на успех Agile в крупных проектах
              +1
              Будуемдумать, что это вопрос, и вы ждете ответа.

              Крупному проекту соответствует крупный штат разработчиков — начиная с 30-50 чел. одних и более. В такой ситуации:
              а) в Agile возникает слишком много малоэффективных коммуникаций, чтобы оставалось время еще и на работу — тут более естественна специализация по принципу роли «архитектор» — «кодер» — «сопровождение» и т.п. А для того, чтобы управлять «слоистой» командой, мало плана «на пальцах», типа скрам-бэклога — приходится подходить более формально. Малоэффективных — потому что задействованы слишком много, чтобы можно было с пользой пообщаться в форме диалога.
              б) по сравнению с scrum-командой в 3 человека, где опоздание на пару дней одной команды решается так: «сместим фокус-фактор в следующей, а в этой дожмем, благо пару дней всего», в большой команде это — потерянный человеко-месяц, что крайне недопустимо. Это еще одна причина большей формализации процесса.
                0
                Да, это был вопрос.

                Я не развиваю холивар, я просто довольно недавно начал свое знакомство с Agile и хотел бы разобраться.

                В моем понимании, Agile вообще и Scrum в частности хорошо масштабируются. Я даже где-то читал, что Yahoo! успешно использовали Scrum на проекте в 700 разработчиков. И способствуют этому несколько специальных техник (Scrum of scrums, компонентные команды, участие архитектора в роли Product owner'а). И это не только устраняет недостатки, но и дает преимущества перед «слоистой командой».

                По моему мнению большая «слоистость» и формализация делают команду неповоротливой. Любые факапы на ранних этапах и изменения требований на поздних стоят очень дорого.
            0
            мой бывший архитектор так напридумывал, что сайт еле крутится…
            да, опытный архитектор — это 80% успеха
          +6
          «Проектирование» отнюдь не эквивалентно «проектирование при помощи UML». Кроме того, большинство проектов куда как сильнее зависит от фазы «анализ предметной области и создание ТЗ». Людям, которые способны проектировать большие и сложные системы, данная статья не нужна. А остальным надо рассказывать о другом и по-другому.

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

          Ладно, не буду дальше придираться к мелочам (а это можно сделать). Лучше спрошу: какова была цель написания статьи?
          Много умных мыслей, красиво оформленные рисунки, но вот я никак не могу представить себе реального применения тому, что тут написано.
          Конкретно об UML можно было написать куда как лучше и предметнее.

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

          Вы, случаем, не лектор в ВУЗе?

          ЗЫ: Хватит экономить на работниках! Программист, который может, если припрет, и в архитектуру залезть, и заказчику письмицо написать, и покритиковать что-либо, будет в ~10 раз более производителен «кодера». А стоить будет не сильно дороже.

          ЗЗЫ: Прошу прощения за корявый комментарий. Мыслей много, а выразить их все в одном комментарии тяжело.
            0
            >>Ладно, не буду дальше придираться к мелочам (а это можно сделать). Лучше спрошу: какова была цель написания статьи?
            Цель статьи показать что такой подход суеществует и в определенных условиях эффективен. Можно все разложить в голове по полочкам и не забыть не один пункт из тз — что кстати может поставить под угрозу всю работу.

            >>А стоить будет не сильно дороже.
            Не соглашусь, как раз на порядок дороже. Зарплата архиектора может а 5 раз превыышать зарплату кодера.

            >>А остальным надо рассказывать о другом и по-другому.
            Статья не несет практической пользы — только теоритическую, а так же расширяет кругозор.
              0
              Я говорю просто о толковых программистах, которые еще не доросли до архитекторов. Таких тоже хватает. И именно из таких, возможно, и вырастают эти самые архитекторы. Так вот у них запросы по з/п не будут большими.

              А вот кодеры за 25-30к рублей — это ужасно. Качество кода у них такое, что заставляет серьезно задуматься об экономической эффективности их найма.

              > Статья не несет практической пользы — только теоритическую
              Теоретическую? Какую именно? Что UML можно использовать при описании любых процессов? Стоило ли при этом писать статью о проектировании?
                0
                согл с цитатой:
                >>Статья не несет практической пользы — только теоретическую
                >Теоретическую? Какую именно? Что UML можно использовать при
                >описании любых процессов? Стоило ли при этом писать статью о >проектировании?

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

                статья имела бы реальную ценность, если бы был бы рассмотрен на примере конкретный проект с конкретными диаграммами.
              0
              1. Программисты не должны лезть в архитектуру. Должны надеть украинскую повязку от гриппа и кодить, кодить и ещё раз кодить.
              2. Письма заказчику должны писать Product manager'ы или QA
              3. Тестировщики должны писать test case'ы и тестить

              но, если уж совсем подпёрло, то можно и совмещать:
              Combine roles within a team
                +2
                Программист, который не способен разобраться в архитектуре и, если надо, внести в нее изменения (пусть и с согласования), не будет работать качественно. Он также не будет работать продуктивно. Качество его кода будет ужасным.
                Кроме того, архитектору нужна обратная связь. Абсолютно правых людей не бывает. Кто будет давать ему эту самую обратную связь?

                QA тоже ничего не должен заказчику писать. Проблема в том, что часто бывает так, что просят «опиши это», а потом, быстро пробежавшись взглядом, пересылают заказчику.

                Поймите, что вы говорите об огромных проектах. Таких мало. Очень мало. И рассказывать надо о таких не как о теории, а как об опыте Microsoft, к примеру.

                Как думаете, насколько были бы успешны facebook, vkontakte, twitter и т.п., если бы следовали этим правилам неукоснительно?
                  0
                  Если бы facebook, vkontakte, twitter следовали бы правилам неукоснительно, то они были бы неуспешны скорее всего, ненадо впадать в крайности.
                  Правила всегда можно нарушить.
              0
              Почему то в этом описании начисто забыты фазы тестирования. Между тем использование RUP — это одна из возможностей сделать «прозрачным» тестирование и обеспечение качества.
                0
                Спасибо, поправил
                  0
                  Неплохо было бы разделить процесс анализа и формирования ТЗ на бизнес анализ (вариантов использования, определения границ системы) и системный анализ.
                    0
                    Поддержу!
                    Это разделение необходимо, так как без хорошего погружения в объектную область (а это отдельная этап, чаще длинее чем формирование ТЗ) никогда не составишь отличного ТЗ, а как следствие косяки в дальнейших этапах.
                      0
                      Полностью согласен
                      0
                      Мы видимо на немножко разных языках говорим… Специально посмотрел в нескольких словарях, везде определение слова «утилизация» сводится к «использование ресурсов, не находящих прямого применения по назначению». А что вы подразумеваете под этим словом?
                        +1
                        не соглашусь с последним утверждением — про только кодера.
                        Отлично, если у вас очень крутой архитектор, но в реальности — на кого попадете.
                        можете попасть на такого «профессионала», что выть будете. а если у профессионала еще 20 лет работы опыта и железобетонная увереность в своей правоте — удачи.
                        зачастую реализовывать то, что подсовывают — это самоубийство. он будет проектировать, он — программировать и все будет хорошо. так не бывает. не напишите вы хорошую программу с кодерами.
                          0
                          >>Отлично, если у вас очень крутой архитектор, но в реальности — на кого попадете.
                          У нас крутой =)

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

                            разработчик, который не задумывется об архитектуре — это плохой разработчик — кодер.

                            а если бы был плохой? вы бы реализовывали 3 wrapper класса для одного поля, которое содержит одно поле String id?

                            Я видел столько проектов, которые загибались из-за архитекторов… и все были с космическими зарплатами.
                            Если проект в стиле абсолтной монархии — это огромные риски, сосредоточенные на одном человеке. анархия — еще хуже.
                            конституционная монархия — наш выбор :)

                            на самом деле — это два взгляда на проблемму управления проектами. есть 2 отличные книги -«Человеческий фактор» и «Мифический человекомесяц».
                            ваше мнение очень странное, если вы сам — программист. или вы архитектор? все равно странно. может вы заказчик?
                            в любом случае мне вас не переубедить.
                            но я думаю, вы поменяете свое мнение на этот счет со временем.
                          +2
                          вы это в реальной жизни пробовали?
                          причем, когда заказчик новые хотелки на ходу придумывает.

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

                            новые поделки — это приложение к договору, тоесть все капризы за ваши деньги =) — для этого и надо максимально формализовать чтобы было меньше мисандестендинга
                              +1
                              Да-да-да. Это вы веб студиям расскажите.
                                0
                                В 90% случаев заказчик понятия не имеет, чего хочет. И не будет, пока не получит готовую систему и не начнет ее пользовать.

                                Был бы заказчиком, ни за что не пошел бы туда, где вытягивают все требования в начале, дают подписать а потом размахивают этой бумажкой каждый раз когда требования уточняются/меняются.
                                  0
                                  >>90% случаев заказчик понятия не имеет
                                  Откуда взята информация?

                                  >>Был бы заказчиком, ни за что не пошел бы туда, где вытягивают все требования в начале
                                  С другой стороны ведь можно сказать: «Был бы исполнителем, ни за что бы не имел дело с теми кто меняет всои требования каждый день и при отсутствии формальной доказательной базы», но в целом вы правы
                                  0
                                  мне кажется у вас не очень много опыта, раз вы так говорите. без обид. тысячу раз пройдено, написанно в умных книжках и прочее: «Никогда разработка проекта не идет, как задумывалось».
                                  и я говорю не только о веб-студиях, но и о огромных многомиллионных системах. есть такие умники — вы только кодеры… не бывает такого. это, извините — идиотизм.
                                  +1
                                  Это и есть развитие реальной системы. Без грамотной документации оно превращается в головную боль. Даже хорошие разработчики через полгода забывают что и как они сделали. И в этом нет ничего необычного и неверного. Не говоря уже о ситуации со сменой разработчиков. Поддерживать системы с документацией на тяп-ляп — это ужасно. Сначала проводишь реверс-инженеринг, строишь все диаграммы, создаешь тест-лабу… И все это лишние затраты времени и денег.
                                    0
                                    Поддерживаю, но разумеется это для масштабных проектах.
                                  –2
                                  Статью не читал. В чем мораль этого копипаста?
                                    0
                                    можно картинки посмотреть, станет понятно
                                    0
                                    А не могли бы Вы раскрыть для кого и для чего составляются эти диаграммы?
                                    Цель какова?
                                    Цель? Шоб було?
                                      0
                                      цель чтобы «на бумаге» была целостная и поэтапная картина разработки
                                      0
                                      Забавно в 2013, когда на дворе сплошной agile читать этот самоуверенный бред.

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

                                      Самое читаемое