Що се отнася до добрия дизайн на OO, дръжте го просто

Веднъж мой бивш студент изтърси нелепото твърдение: "Не мога да направя обектно-ориентиран дизайн (ОО); нямам пари!" По-нататък се оказа, че според него дизайнът на OO изисква продукт, наречен Rational Rose, който по това време струва около 500,00 на място. В съзнанието му, без Rational Rose, дизайнът не беше възможен. За съжаление този вид болдердаш е широко разпространен; твърде много хора смятат, че ОО е високотехнологичен процес, изискващ високотехнологични инструменти. На практика инструментите с прекомерно високи цени стоят неизползвани на рафта (или са изключително недостатъчно използвани).

Имайки предвид това, в тази статия обсъждам различни инструменти за проектиране на ОО, как работят и защо мисля, че не са полезни. Също така обяснявам как работя и какво се оказва полезно (поне за мен; можете да не се съгласите).

Инструментите не ви водят през процеса

Всеки успешен дизайн на OO, който съм измислил, е следвал приблизително същия процес:

  • Научете за проблемната област (счетоводство, планиране на уроци и т.н.)
  • Разработете в тясна консултация с потребител на живо декларация за проблем, която изчерпателно описва проблема на потребителя, както и всички решения на ниво домейн. Този документ не описва компютърна програма.
  • Извършете официален анализ на случая на употреба, в който определям задачите, необходими за решаване на проблема на потребителя, отново, като работя в тясно сътрудничество с реален краен потребител. Обикновено създавам диаграма на дейността на UML (Unified Modeling Language) за всеки нетривиален случай на употреба. (UML е символично представяне на софтуера като картина.)
  • Започнете да изграждате динамичен модел, показващ обектите в системата и съобщенията, които тези обекти изпращат един на друг, докато се изпълнява конкретен случай на употреба. За тази цел използвам диаграма на UML последователност .
  • Едновременно улавям полезна информация на диаграмата на статичния модел . Забележка: Никога не правя статичен модел (диаграма на класа) първо. Изхвърлих твърде много статични модели, които се оказаха безполезни, след като започнах да правя динамичния модел. Вече не съм готов да губя времето, необходимо за правене на статичния модел във вакуум.
  • Гореспоменатите стъпки обикновено дават два или три случая на употреба, след което започвам да кодирам, като фиксирам модела, ако е необходимо.
  • И накрая, работя върху друг случай на употреба, както е описано, рефакторинг на дизайна и кода, както е необходимо, за да се съобрази с новия случай.

Нито един от днешните инструменти за проектиране не ви води през този процес. В по-голямата си част те са надценени програми за рисуване, които не работят особено добре, дори като инструменти за рисуване. (Rational Rose, която считам за една от най-слабоспособните в партидата, дори не поддържа целия UML.)

Инженерингът за двупосочно пътуване е принципно погрешен процес

Тези инструменти не само не работят добре, но единственият трик, който тези инструменти изпълняват - генериране на код - е безполезен. Почти всички инструменти за проектиране на ОО следват идеята за двупосочен инженеринг, в който започвате в инструмент за проектиране, като посочите своя дизайн в UML. Създавате два основни набора диаграми: статичния модел, показващ класовете в дизайна, техните взаимоотношения помежду си и методите, които те съдържат; и динамичния модел, който представлява набор от диаграми, които показват обектите в системата, изпълняващи различни задачи по време на изпълнение.

След като завършите модела, натискате вълшебен бутон и инструментът генерира код. Кодът, генериран от инструмент, обаче не е особено добър поради две причини: Първо, в много инструменти се създават скелети за дефинициите на класове, но методите са просто празни мъничета - динамичният модел се игнорира. Второ, нито един инструмент не поддържа напълно UML, най-вече защото никой не може. UML е самостоятелен език, който насърчава импровизацията и голяма част от действителното съдържание на дизайна се изразява в коментари, които обикновено се игнорират от инструмента за проектиране.

В резултат на това хаквате генерирания код (повечето магазини наистина го хакват). В рамките на няколко седмици кодът обикновено има малко или нищо общо с оригиналния дизайн. Всъщност вие на практика изхвърляте дизайна си и отново изпадате в синдрома на УИСКИ (Защо някой все още не „кодира?“). Години и години неуспешни програми ми доказват, че кодирането без дизайн увеличава общото време за разработка поне с три пъти и води до много по-бъги код.

Сега идва процесът на двупосочно пътуване: Отваряте инструмента си, натискате вълшебния бутон и импортирате кода, теоретично възстановявайки дизайна, така че да отразява действителното състояние на кода. Подобно обратно инженерство обаче не работи. Инструментите обикновено създават нови диаграми на класа, но никога не актуализират динамичния модел. Тъй като динамичният модел е от основно значение за процеса, вашият дизайн вече е безполезен, освен ако не се върнете и не го актуализирате на ръка, нещо рядко се прави.

С риск да се повторя, процесът на двупосочно пътуване насърчава програмистите да игнорират дизайна изцяло и само да кодират, след което да реверсират кода на изображения на всеки толкова често. В тази ситуация обаче програмистите не проектират; те хакват код, след което създават снимки на получената бъркотия. Хакерството не е равен на дизайна.

Въпреки че дизайнът наистина е итеративен процес (дизайнът се променя при разработването на кода), трябва да започнете итерация, като първо модифицирате дизайна, след което рефакторирате кода, за да отрази новия дизайн. За да направите това, ще трябва да можете да посочите целия софтуерен продукт в инструмента (когато натиснете магическия бутон, ще се изведе напълно функционална програма) и процесът ще бъде еднопосочен, без обратен инженеринг механизъм.

Инструментите CASE

Инструментите CASE (компютърно подпомагано софтуерно инженерство) като Rational Rose обикновено поставят двупосочното инженерство в основата на продукта. Тъй като обаче двупосочният инженеринг не прави нищо полезно, много разработчици използват инструментите като скъпи програми за рисуване. От наличните инструменти мисля, че си заслужава да се разгледат три (въпреки че не използвам нито един от тях):

  • Безплатният инструмент с отворен код ArgoUML, написан на Java, върши сравнително добра работа с UML диаграми. Най-новата версия дори се опитва да ви преведе през процеса (с незначителен успех досега, но това е добро начало).
  • GDPro на Embarcadero, по-рано разпространяван от Advanced Software, предлага добра поддръжка за група, работеща върху един софтуерен дизайн, но има и недостатъци в този отдел. Например, дизайнерът не може да провери диаграма на динамичен модел, докато автоматично заключва класовете, свързани с обекти на динамичния модел.
  • TogetherSoft's Together ControlCenter заобикаля проблема с обратното пътуване, като не го прави. Кодът и дизайнът се появяват на екрана едновременно, а когато промените единия, другият се променя автоматично. Заедно ControlCenter не поддържа добре групи от програмисти.
  • Трябва да спомена накратко и Visio на Microsoft. Visio е програма за рисуване, която поддържа UML след мода, но поддръжката му имитира мизерния потребителски интерфейс на Rational Rose. Различни шаблони за рисуване за UML фигури във Visio работят по-добре от вградената поддръжка на UML, включително един в раздела „Елементи“ на моя уебсайт.

И така, ако мисля толкова зле за тези инструменти, какво да използвам? Досега най-продуктивните инструменти за OO-дизайн са бяла дъска (стая с бели дъски от стена до стена, от пода до тавана е идеална) и подложки Post-it с размер на флипчарт, листове от които можете да отлепите и пръчка на стената. Използвал съм ги за проектиране на значителни проекти с голям успех. Нещо повече, работата върху бяла дъска отнема значително по-малко време от борбата с инструмент OO CASE.

Единствената трудност при подхода на бялата дъска е събирането на информацията на дъската. Белите дъски, които се печатат, съществуват, но са скъпи, неприлични и твърде малки. Един изчистен хардуерен продукт, който проследява движението на писалката през бялата дъска и улавя ударите на писалката в компютъра. Други дъски работят като гигантски таблетки за дигитайзер. Тези решения обаче се оказват твърде ограничаващи; дизайнът се извършва едновременно върху дъски в няколко офиса, върху салфетки, върху парчета хартия и т.н. Не можете да носите 300-килограмова дъска за печат до местното кафене.

И така, какво работи

И така, какво трябва да прави една майка? Как да заснемете тези артефакти, за да ги архивирате в компютъра, така че те да направят разумна документация, както са, без да се налага да ги прехвърлят в програма за рисуване?

Решението:

  1. Цифров фотоапарат
  2. Прекрасен софтуерен продукт, наречен Whiteboard Photo от Pixid

За съжаление цифровата снимка често създава изображения, незадоволителни за документация. За да компенсира, Whiteboard Photo превръща цифровите снимки в нещо полезно. Тук снимките наистина струват хиляда думи. Фигура 1 показва типична цифрова снимка на бяла дъска.

Фигура 2 илюстрира друг пример.

Фигура 3 показва как Whiteboard Photo трансформира Фигура 1.

И ето как Фигура 2 изглежда след снимката на Whiteboard Photo направи своята магия.

Както показват изображенията, разликата е невероятна. За да трансформирам оригиналното изображение в почистена версия, аз просто натиснах Ctrl-L. Софтуерът автоматично открива границите на бялата дъска, коригира за изкривяването, причинено от заснемането на снимката от ъгъл (необходимо за избягване на отблясъците от светкавицата), подбира линиите на дизайна и ги рисува. Всичко, от което продуктът се нуждае, за да постигне съвършенство, е разпознаване на ръкопис, но аз го гъделичкам в розово, както стои. Вече мога да изготвя чертежи с качество на документацията директно от оригиналната дъска, без да губя часове, като въвеждам чертежа в някакво куцо извинение за инструмент CASE.

Не го усложнявай

Според моя опит, когато става въпрос за OO дизайн, нискотехнологичните инструменти работят най-добре. Всъщност те са по-бързи, по-лесни за използване и се представят добре в среди за сътрудничество. Досега установих, че комбинацията от бяла дъска, цифров фотоапарат и Whiteboard Photo предлага най-добрия метод за вкарване на програмни дизайни в машина.

Алън Холуб предоставя консултантски услуги, обучение и наставничество в дизайна на ОО, процеса на ОО и програмирането на Java. Той редовно представя интензивен семинар за дизайн на ОО за тези, които се интересуват от бързо развитие на своите умения за ОО. (Намерете повече информация на //www.holub.com.) Алън работи в компютърната индустрия от 1979 г., последно като главен технологичен директор в NetReliance, Inc. Той е широко публикуван в списания (Journal of Dr. Dobb, Programmers Journal, Byte и MSJ, наред с други). Алън има осем книги, най-новата от които - „Укротяване на нишките Java“ (APpress, 2000; ISBN: 1893115100) - обхваща капаните и клопките на нишките за Java. Преподава OO дизайн и Java за Университета на Калифорния, Berkeley Extension (от 1982 г.).

Научете повече за тази тема

  • За безплатния инструмент за проектиране на ArgoUML с отворен код отидете на

    //argouml.tigris.org/

  • GDPro на Embarcadero можете да намерите на

    //www.embarcadero.com

  • Ще намерите повече информация за TogetherSoft's Together ControlCenter на адрес

    //www.togethersoft.com

  • Началната страница на Microsoft Visio

    //www.microsoft.com/office/visio/default.htm

  • Отидете на страницата на продукта Pixid Whiteboard Photo за повече информация относно този интересен инструмент

    //www.pixid.com/home.html

  • Уебсайтът на Алън Холуб включва страницата му „Goodies“, където ще намерите съвети за дизайн на ОО, основни правила за програмиране и бележки от някои от разговорите на Алън

    //www.holub.com/goodies/goodies.html

  • JavaWorld е обектно-ориентиран дизайн и програмиране Index предлага множество статии насочени дизайн

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Ще намерите още страхотни отзиви в JavaWorld е индекс на продукта Коментари

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Прочетете повече коментари в JavaWorld е Index Commentary

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • За съвети и уроци, обхващащи дизайнерски модели, инструменти за разработка, настройка на производителността, сигурност, тестване и други, регистрирайте се за нашия приложен бюлетин Java

    //www.javaworld.com/subscribe

  • Говорете в нашата дискусия за теория и практика на програмирането

    //forums.idg.net/[email protected]@.ee6b806

  • Ще намерите изобилие от свързани с ИТ статии от нашите сестрински публикации в .net

Тази история „Когато става въпрос за добър дизайн на OO, дръжте го просто“ първоначално е публикувана от JavaWorld.