Влезте в архитектурата и процеса на J2EE

В търговския свят използваме Java 2 Enterprise Edition (J2EE) за решаване на бизнес проблеми, за разработване на търговски софтуер или за предоставяне на договорни услуги за проекти на други фирми. Ако дадена компания иска да изгради уебсайт за електронен бизнес, използвайки многостепенна архитектура, тя обикновено включва мениджъри, архитекти, дизайнери, програмисти, тестери и експерти по бази данни през целия жизнен цикъл на разработката.

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

Обичам да използвам RUP за разработка на J2EE по три причини. Първо, RUP е ориентиран към архитектурата; той разработва изпълним прототип на архитектура, преди да ангажира ресурси за пълномащабно развитие. Второ, RUP е итеративен и базиран на компоненти. Базовата линия на архитектурата често включва рамка или инфраструктура за улесняване на добавянето на компоненти чрез итерации за персонализиране и разширяване на функционалността на системата, без да се засяга останалата част от системата. Трето, RUP използва стандартен за индустрията език, UML, за визуално моделиране на архитектура и компоненти на системата. RUP има четири различни фази на развитие: начало, разработване, изграждане и преход. Тази статия обаче обхваща осем основни дейности, свързани с развитието на J2EE от техническа гледна точка по начин, който поддържа архитектурния фокус.

I. Анализ на изискванията

Анализът на изискванията описва какво трябва или не трябва да прави системата, така че разработчиците и клиентите да могат да създадат първоначален бизнес договор. Можете да документирате функционални изисквания в бизнес концепции, речници на домейни, случаи на употреба и макети на потребителския интерфейс (UI). Нефункционални изисквания, като например изпълнение и транзакции, посочвате в документ за допълнителни изисквания. Можете да създадете макет на потребителски интерфейс на високо ниво на хартия или в HTML, в зависимост от това колко дълбоко сте въвлечени в проекта.

Фигура 1 показва два примерни случая на използване на типична система за електронен бизнес. Случаят на viewOrderупотреба ни казва, че потребителят влиза в системата чрез уеб интерфейс, вижда списък с поръчки и щраква върху връзка, за да види подробности за поръчката на конкретна поръчка за покупка. Случаят на addLineItemsупотреба ни казва, че потребителят разглежда продуктов каталог, избира интересни продукти и ги добавя към поръчка за покупка.

II. Обектно-ориентиран анализ

Анализаторите генерират проблемни модели на домейни: класове, обекти и взаимодействия. Вашият анализ не трябва да съдържа никакви технически подробности или подробности за изпълнението и трябва да съдържа идеален модел. Обектният анализ ви помага да разберете проблема и да придобиете знания за проблемната област. Трябва да поддържате чист модел на домейн без технически подробности, защото бизнес процесът се променя много по-бавно от информационните технологии.

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

Резултатът от изискванията и обектните анализи е входната точка за развитие на архитектурата J2EE. За да разработите архитектура, избирате вертикална част - често критична част, като например обектния модел на домейн за поръчка - за обектен дизайн, внедряване, тестване и внедряване. (Вертикалната част, концепция за RUP, е малка част от системата. Отправната точка е подмножество от случаи на употреба, както е показано на фигура 1, и модели за анализ на домейни, както е показано на фигура 3. Изпълнението на вертикална част води до напълно функционална мини-система, включваща всички нива, като например потребителски интерфейс JavaServer Pages (JSP), бизнес обекти от средно ниво като Enterprise JavaBeans (EJB) и често бази данни.) Можете да приложите опит, придобит от прототип на обект на домейн и нека тези знания служат като насока за проектиране на етапа на проектиране на обекти.