Новые книги

Стив Бланк, гуру стартап-движения, говорит, что главное для начинающего предпринимателя – это «выйти из офиса», то есть начать напрямую узнавать у клиентов, что им нужно. Однако получите ли вы действительно важную информацию, зависит от того, какие вопросы вы будете задавать. Кстати, самый популярный вопрос – «Нравится ли вам наша идея или продукт»? – неверен. Это все равно, что спрашивать маму, по душе ли ей ваша идея: она любит вас и в любом случае похвалит, не желая расстраивать. Так же поступают и 99 % клиентов. В общем, чтобы быть успешным предпринимателем, надо знать, как и что именно спрашивать, и по книге Роба Фитцпатрика вы научитесь это делать!

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

Перед вами краткое, полезное и написанное с хорошим юмором практическое руководство по эффективному общению предпринимателя с клиентами. Оно поможет вам сэкономить время, деньги и нервы.
Книга «Rational Rose 2000 и UML. Визуальное моделирование» является исчерпывающим руководством по использованию инструмента (Rational Rose 2000), процесса (Rational Unified Process) и языка (UML) для визуального представления, определения, описания и создания программной системы. Здесь изложены основы процесса разработки и дано четкое объяснение каждого этапа и элемента. Автор следует упрощенному варианту методологии Rational Unified Process и описывает процесс разработки от задумки до системного анализа и проектирования. На простом практическом примере, проходящемчерез всю книгу, наглядно демонстрируются итеративный процесс разработки, средства языка UML и возможности среды моделирования Rational Rose. В приложениях рассматриваются вопросы генерации кода и возвратного проектирования в программе Rational Rose 2000 для языков C++, Visual C++ и Visual Basic.

В книге также обсуждаются следующие темы:

— создание функций;

— поиск объектов и классов;

— стереотипы и пакеты в языке UML;

— сценарии и диаграммы взаимодействий;

— способы взаимодействия объектов;

— ассоциативные и агрегационные отношения;

— поведение и структура классов;

— наследование и отношения суперкласс/подкласс;

— поведение объектов и диаграммы переходов и состояний;

— проверка целостности модели;

— определение, представление и описание системной архитектуры;

— итерационный процесс планирования.

Определение зависимостей

2.2.3. Определение зависимостей

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

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

Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:

  • зависимости между исключенными классами должны быть исключены, либо переформулированы в терминах оставшихся классов (см. пример в п. 2.3.3);
  • нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены (см. пример в п. 2.3.3);
  • действия: зависимость должна описывать структурные свойства прикладной области, а не малосущественные события (см. примеры в п. 2.3.3);
  • тренарные зависимости: большую часть зависимостей между тремя или большим числом классов можно разложить на несколько бинарных зависимостей, используя в случае необходимости квалификаторы (см. примеры в п. 2.3.3); в некоторых (очень редких) случаях такое разложение осуществить не удается; например, тренарная зависимость "Профессор читает курс в аудитории 628" не может быть разложена на бинарные без потери информации;
  • производные зависимости: нужно исключать зависимости, которые можно выразить через другие зависимости, так как они избыточны (см. пример в п. 2.3.3); при исключении избыточных (производных) зависимостей нужно быть особенно осторожным, так как не все дублирующие одна другую зависимости между классами избыточны; в некоторых случаях другие зависимости позволяют установить только существование еще одной производной зависимости, но не позволяют установить кратность этой зависимости; например, в случае, представленном на рисунке 2.36, фирма имеет много служащих и владеет многими компьютерами; каждому служащему предоставлено для персонального использования несколько компьютеров, кроме того, имеются компьютеры общего пользования; кратность зависимости предоставлен_для_использования не может быть выведена из зависимостей служит и владеет; хотя производные зависимости и не добавляют новой информации, они часто бывают удобны; в этих случаях их можно указывать на диаграмме, пометив косой чертой.

Рис. 2.36. Неизбыточные зависимости

Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:

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

Назад | Содержание | Вперед