Отправляет email-рассылки с помощью сервиса Sendsay

Мастер программист

Подписаться Бесплатная новостная рассылка Подписчиков 18 RSS
←   Ноябрь 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней ни разу не выходила


Открыта: 11-10-2008

Автор
Master Mind

Статистика

18 подписчиков
0 за неделю
←   Все выпуски   →

Мастер программист Статья 6. Моделирование


Статья 6.

 Моделирование

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

На помощь нам приходит моделирование.

Мы абстрагируемся от лишних деталей и сложностей. Идеализация объектов помогает рассмотреть его с разных сторон.

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

Но, данные исследований надо документировать. Для этого есть много методик, но стандартом "де факто" является UML.

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

И общение посредством диаграмм UML удобно№ Есть множество инструментов для работы с ним: IBM Rational Rose, Borland Together Designe, Model Maker и другие. Есть даже системы по модели строящие приложение (так называемые MDA - Model Driven Architecture)

    Многие средства разработки позволяют из кода воссоздать модель и поменять ее синхронно измененениям. Это может и Borland JBuilder и Microsoft Visual Studio Pro.

    Это все - положительные стороны моделирования.

    Рассмотрим и подводные камни.

Многие из нас помнят, каково это - попасть в "паралич анализа".

    Подробная детализация на старте тормозит проект и забирает энергию у дальнейшего творческого программирования.

    В конце получается "талмуд" системы и отсутствие желания его воплощать.

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

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

    И велика вероятность пойти не туда, куда надо. Как говориться:"Если ты не знаешь, куда идти - ты попадешь не туда".

    А в нашем бизнесе - это чревато излишними затратами средств и времени. Как же нам решить проблему сложности и трудоемкости моделирования не впадая в крайности?

    Есть несколько решений.

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

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

    Все дополнения и изменения документируются и откладываются до начала следующей итерации разработки версии программы.

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

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

    А путешествовать, как мы знаем, лучше на легке.

 

      Эта система хорошо проявила себя в работе и часто применяется в ХР (Экстремальном программировании). Она носит название AM (Agile Modeling) - гибкое моделирование.

Как ни странно, ее основное правило - смирение.  Нужно смириться, что модели не идеальны. Что мы недостаточно умны для осознания системы полностью. Что модели устаревают.

 

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

Нет предела совершенству.

 

    Так что пожелаю Вам приятного моделирования.

До встречи. С уважением, Владимир.
В избранное