понедельник, 12 апреля 2010 г.

Анализ задачи

Анализ должен объяснить, что делает система, а не то, как она это делает.

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений

на
Ярлыки: ,

4 комментария:

  1. Анонимный18 апреля 2010 г. в 17:06

    Боюсь на этот раз Гради зарвался: "Анализ - метод исследования объектов путём выделения и рассмотрения их отдельных частей..."
    У-у-упс, боюсь если говорить "вообсче" то выделять части без "как" не очень-то получится!

    ОтветитьУдалить
  2. Sergey Teplyakov19 апреля 2010 г. в 11:24

    @nonp: Вынужден с вами не согласиться. Возможно для других областей знаний в процессе анализа невозможно абстрагироваться от того "как" функционирует некоторая сущность (хотя я и сомневаюсь), то в разработке ПО вам просто необходимо во время анализа не обращать внимания на детали реализации. Если говорить утрировано, то вы ведь разговаривая с заказчиком (менеджером, владельцем проекта и т.п.) не общаетесь в терминах языков программирования? Либо вам настолько повезло, что ваши пользователи или заказчики в этом что-либо понимают. Но в целом, при общении с такими людьми аналитик/архитектор все же говорит в терминах бизнес-логики, в терминах задачи, при этом он пытается как раз таки понять, "что" именно хочет заказчик или менеджер, а то "как" это сделает разработчик, остается его личным делом (лишь бы реализация отвечала некоторым изначально оговоренным критериям).
    Аналогично, хороший менеджер дает задачи своим подчиненных тоже в терминах того, что он хочет получить, а не то, как это должно быть сделано. Поскольку без абстрагирования от этих деталей просто невозможно работать с крупными системами и нормально общаться на более высоком уровне абстракции.

    ОтветитьУдалить
  3. Анонимный22 апреля 2010 г. в 15:36

    Ну в таком ключе я согласен. Но тогда получается что это самое "как" на самом деле имеет некоторые пределы, уровни абстракции.

    ОтветитьУдалить
  4. Sergey Teplyakov22 апреля 2010 г. в 23:57

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

    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)