ВАНЯ ЛАЗАРОВА

CASE ТЕХНОЛОГИИ

София, 2009 г.

2

3

ВАНЯ ЛАЗАРОВА

CASE ТЕХНОЛОГИИ

Computer-aided software engineering

Учебник за специалност „Бизнес информатика”

Издателство „Фльорир”, София

4

CASE технологии (Computer-aided Software Engineering) © Ваня Лазарова, автор, 2009 г. © ИК „Фльорир”, издател, 2009 г. Рецензенти: доц. д.р Ст. Стоянова, доц. д-р Д. Велев ISBN: 978-954-410-004-9

5

СЪДЪРЖАНИЕ

1. Определение .......................................................... 11

1.1. Предимства от използването на CASE

инструменти ............................................................ 13

1.2. Недостатъци при използването на

автоматично генериран код ................................... 14

2. UML – общи понятия .............................................. 16

2.1. История на UML ............................................... 17

2.2. Цели и сфери на приложение на UML ............ 19

3. Модели на софтуерните системи и UML

диаграми ..................................................................... 21

3.1. Класификация на моделите и типовете

UML диаграми ......................................................... 21

3.2. Дефиниране на типовете диаграми –

нотации и мета-модели .......................................... 25

4. Типове структурни UML диаграми ......................... 26

4.1. Диаграма на класовете (class diagram)........... 27

4.2. Диаграма на обектите (object diagram) ........... 31

4.3. Диаграма на съставна структура

(Composite structure diagram) ................................. 32

4.4. Диаграми на пакети (package diagram) ........... 34

6

4.5. Диаграми на физическата структура на

системата ................................................................ 35

5. Типове функционални UML диаграми ................... 40

5.1. Диаграма на случаите на употреба (Use

case diagram) ........................................................... 41

5.2. Диаграма на дейностите (Activity diagram) ..... 43

5.3. Диаграма на състоянията (State Machine

diagram) ................................................................... 44

5.4. Диаграми на взаимодействията ...................... 47

6. Приложение на UML за проектиране на

информационни системи ........................................... 52

6.1. При проектиране на високо ниво .................... 52

6.2. При детайлно проектиране –

проектиране на класовете ...................................... 54

7. Пример “Информационна система за детска

градина” ...................................................................... 56

7.1. Цели и обхват на системата ........................... 56

7.2. Диаграма на случаите на употреба (Use

Case Diagram) ......................................................... 57

7.3. Диаграми на класовете .................................... 59

7.4. Диаграми на последователностите ................ 64

7.5. Диаграма на дейностите ................................. 66

7

7.6. Компонентна диаграма .................................... 68

7.7. Релационен модел на базата данни ............... 70

8. Средства за визуално и декларативно

програмиране – общ преглед ..................................... 72

8.1. Увод .................................................................. 72

8.2. Примерна задача ............................................. 78

9. Визуално и декларативно програмиране при

разработване на настолни системи .......................... 81

9.1. Стъпка 1. Създаване на нов проект ................ 81

9.2. Стъпка 2. Дизайн на потребителския

интерфейс ............................................................... 82

9.3. Стъпка 3. Добавяне на код към събития ........ 90

9.4. Стъпка 4. Стартиране и тестване ................... 92

10. Визуално и декларативно програмиране при

създаване на уеб-базирани системи ......................... 95

10.1. Стъпка 1. Създаване на нов проект .............. 95

10.2. Стъпка 2. Дизайн на потребителския

интерфейс ............................................................... 97

10.3. Стъпка 3. Добавяне на код към събития .... 102

10.4. Стъпка 4. Стартиране и тестване ............... 103

11. Компютърно подпомагане на кодирането ......... 106

8

11.1. Контекстна помощ и автоматично

дописване (intellisense) ......................................... 107

11.2. Вмъкване на програмни фрагменти

(snippets) ............................................................... 109

11.3. Обобщение ................................................... 115

12. Уеб базирани системи за управление на

съдържанието ........................................................... 117

12.1. Какво е CMS? ............................................... 117

12.2. DotNetNuke ................................................... 119

12.3. Модули предназначени за

администратора на сайта ..................................... 120

12.4. Модули предназначени за крайните

потребители .......................................................... 126

12.5. Добавяне на страници към сайта.

Главно меню ......................................................... 132

12.6. Сфера на приложение на CMS

технологията ......................................................... 139

13. Заключение ......................................................... 145

ПРИЛОЖЕНИЕ 1 Ресурси, достъпни в интернет .... 148

ПРИЛОЖЕНИЕ 2 Речник на използваните

термини ..................................................................... 150

Използвана литература ............................................ 154

9

Въведение

Настоящият учебник разглежда различните CASE технологии, предназначени за анализ и проектиране на бизнес информационни системи.

В целия учебник е използвано английското наименование CASE (Computer-aided Software Engineering), тъй като то е придобило известност сред информатиците и се използва, без да се превежда на български.

Особено внимание в учебника е обърнато на три технологии: езика UML като основно технологично средство за автоматизирано програмиране, на средствата за визуално и декларативно програмиране и на средствата за компютърно подпомагане на кодирането.

В глава 1 е дадено определение на CASE технологиите и са обсъдени предимствата и недостатъците на използването на UML за автоматизирано програмиране чрез CASE инструментите.

В глава 2 е разгледана класификацията на типовете диаграми, които се дефинират в UML. Разграничават се два основни класа диаграми: структурни диаграми и функционални диаграми.

В глави 3, 4 и 5 е направен обзор на типовете диаграми, включени в тези два класа. За всеки тип диаграми е разгледано тяхното предназначение и са илюстрирани с примери. По-подробна информация за типовете диаграми може да бъде намерена онлайн в сайтовете, посочени в приложение 1.

10

В глава 6 е обсъдено приложението на UML за проектиране на информационни системи. Разгледани са предимствата и недостатъците на UML диаграмите в сравнение с описателните начини за документиране на програмните системи.

В глава 7 е представен един учебен пример, с който се илюстрира използването на различните типове диаграми.

В глава 8 се прави общ преглед на средствата за визуално програмиране и е представен пример.

В глава 9 е направен общ преглед на визуалното и декларативното програмиране конкретно при разработване на настолни системи.

Глава 10 е посветена на визуалното и декларативното програмиране при създаване на уеб-базирани системи

В глава 11 са разгледани някои средства за компютърно подпомагане на кодирането. –

Глава 12 е посветена на уеб базираните системи за управление на съдържанието.

Накрая в глава 13 е направено кратко обобщение на изложеното в учебника.

Учебникът “CASE технологии” е предназначен за студентите от специалност “Бизнес информатика”, които изучават дисциплината “CASE технологии за анализ и проектиране на БИС” в рамките на бакалавърския курс на обучение в УНСС.

Учебникът може да се ползва също така и от студенти от други специалности, които се интересуват от тази специфична проблематика.

11

1. Определение

CASE (Computer-aided software engineering) – компютърно подпомагано софтуерно инженерство, се нарича използването на специализирани програми за подпомагане на програмирането и поддръжката на софтуера; респективно програмните средства се наричат CASE инструменти.

Разграничават се два големи класа CASE инструменти:

- Структурни (Structured) CASE инструменти, които се базират на структурното (необектно ориентирано) програмиране. Тези продукти са характерни за периода до 90-те години на ХХ в.

- Обектно-ориентирани (ОО) CASE инструменти, които се развиват заедно с обектно-ориентираното програмиране.

OO CASE инструментите, които тук разглеждаме, са свързани с езика UML в два аспекта:

- предоставят средства за построяване на UML диаграмите;

- позволяват, въз основа на диаграмите на класовете, автоматично да се генерира програмен код на някои от популярните езици за обектно ориентирано програмиране.

Повечето съвременни ОО CASE инструменти поддържат езиците за машинно-независимите платформи .NET (C#; VB) и J2EE (Java).

12

В таблица 1 са показани четири CASE инструменти и поддържаните от тях програмни езици.

CASE Продукт [Производител]

Генерира код на

Цена на лиценз за 1 работно място

J2EE (Java)

.NET (C# , VB)

Rational Rose XDE [IBM]

+

+

EUR 2607 (Rational Rose for MS Visual Studio)

Power Designer 12.0 [Sybase]

+ + $2995 до $7495

Enterprise Architect [Sparx Systems]

-- + $239

EclipseUML [Omondo]

+ -- Безплатен (отворен код)

Таблица 1. Функционалност и цени на някои CASE системи.

Данните са извадка от една обширна справочна таблица, в която по-нататък ще бъде представена функционалността на повече от 100 CASE системи. Посочената цена е за лиценз за 1 работно място при закупуване на 1 до 5 лиценза. Цените намаляват при закупуване на по-голям брой лицензи.

13

1.1. Предимства от използването на CASE инструменти

Някои от основните предимства от

използването на CASE инструментите са:

Увеличават продуктивността на програмистите. CASE инструментите осигуряват автоматизация на програмирането и намаляват времето за завършване на много задачи. Програмистът се съсредоточава повече върху логиката на програмата и по-малко върху кодирането на тази логика. Това е валидно само след усвояване на работата с тези инструменти на професионално ниво (вж. раздела за недостатъците).

Повишават прецизността на програмния код. Използването на CASE инструменти води до ранното отстраняване на дефекти. Значението на ранното отстраняване на грешките е много важно. По-малко усилия и време се изразходват, ако корекциите се направят на по-ранен етап, какъвто е етапът на проектиране.

Намаляване на времето за поддръжка. С използване на CASE инструменти се създава много по-добра документация на програмния код. Това от своя страна води до по-бързо и по-ефективно извършване на определени

14

изменения във вече функционираща система.

Активно участие на потреби-телите. CASE инструментите могат да бъдат използвани, за да се даде възможност на потребителя (непрогра-мист) да вземе по-голямо участие в процеса, тъй като диаграмите са разбираеми за потребителя, за разлика от програмния код. Това, от своя страна, води до по-добро приемане на системата; може също да намали времето за обучение на потребителите.

1.2. Недостатъци при използването на автоматично генериран код

Ще посочим три недостатъка на

съвременните CASE инструменти.

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

15

Висока цена. Повечето фирми, които се занимават с малки проекти, не инвестират в CASE инструменти, защото считат, че цената им е висока. Цените, посочени в таблица 1 по-горе, показват, че продуктите на водещите фирми, които са най-качествени и с най-пълен функционален обхват, са много скъпи (над $2000).

Един от начините да се преодолее тази пречка е да се използват продукти с приемливи цени (между $200 и $400), но с не толкова голям обхват. Друг начин, възможен при използване на Java (но не и при използване на C#), e да се прилагат CASE инструменти с отворен код, които са безплатни.

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

Преодоляването на този недостатък трябва да се търси по пътя на утвърждаване на UML като постоянен инструмент в работата на програмистите. Тогава няма да е нужно допълнително обучение по използване на CASE инструменти в рамките на даден проект.

16

2. UML – общи понятия

UML (Unified Modeling Language – Унифициран език за моделиране) e графичен език за специфициране, конструиране и документиране на софтуерни системи. UML позволява еднородно (унифицирано) моделиране на софтуерни системи в два аспекта:

- UML е препоръчителен стандарт в софтуерната индустрия, възприет от много водещи фирми. Това позволява системните модели, разработвани от различни екипи, да бъдат описани с еднакви графични средства и респективно – разбираеми за голям кръг от специалисти извън разработващия екип.

- UML е независим от конкретните програмни езици и това създава възможност да се моделират по единен начин системи, които са много различни от гледна точка на тяхната програмна реализация

UML дефинира правилата за изграждане на различни типове диаграми (графични модели), които служат за графично представяне на различни аспекти на софтуерните системи.

По отношение на детайлността на моделирането се разграничават три нива:

- Моделиране на високо ниво (High level modeling). На това ниво се представя системата като цяло и нейните основни

17

модули. При създаване на нова система обобщеният модел се използва като начална скица на системата. Ето защо това ниво се нарича също ниво на скица (sketch).

- Детайлно моделиране (Detail modeling). На това ниво се разработват модели, които показват детайли от структурата и функционирането на отделни подсистеми и модули.

- Моделиране на ниво на програмиран код. На това ниво се разработват диаграми на класовете (class diagrams). Една диаграма на клас представя в графичен вид характеристиките на един клас в обектно-ориентиран език за програмиране (свойства, методи, отношения на наследяване).

2.1. История на UML

През 80-те и 90-те години на ХХ в. заедно с развитието на обектно-ориентираните езици за програмиране (като С++) започват да се развиват и графични системи (наричани “моделни нотации” или “графични езици”) за обектно-ориентирано моделиране.

Едни от най-популярните методи за обектно-ориентирано моделиране от този период са:

- Object-modeling technique (OMT), разработен от Румбау (Rumbaught);

18

- Booch’s method, разработен от Грейди Буук (Booch);

- Object-oriented software engineering (OOSE), разработен от Айвър Джейкъбсън (Jacobson).

През 1996 г. Rational Software Corporation стига до заключението, че наличието на много езици за моделиране забавя развитието на обектно-ориентираната технология, затова възлага на Грейди Буук, Айвър Джейкъбсън и Джим Румбау да създадат една обща система от типове диаграми.

Проектът включва не само изобретените от тях нотации, но и разработки на други автори. Например включен е методът OOram (Object Oriented Role Analysis Method – Метод на обектно-ориентирания ролеви анализ), разработен през 1996 г. от Риинскуг (Reenskaug) от Университета в Осло, Норвегия.

Под техническото ръководство на „тримата амигос” (така наричали Грейди Буук, Айвър Джейкъбсън и Джим Румбау) през 1996 г. е организиран международен консорциум UML Partners, който завършва спецификацията на езика Unified Modeling Language (UML).

Версия 1.0 на UML е приета от Object Management Group (OMG) през януари 1997 г.

OMG е международна неправителствена организация за препоръчителни стандарти в областта на обектно-ориентираните софтуерни технологии. Създадена е през 1989 г. от 11 компании, между които Hewlett-Packard, IBM, Sun Microsystems, Apple Computer, American Airlines и Data General.

19

Следват няколко малки ревизии (UML версии 1.3, 1.4, 1.5), които поправят недостатъците на първата версия на UML. През 2004 г. OMG прие версия 2.0.

От 2005 г. UML (версия 1.4.2) е официален стандарт на международната организация за стандарти ISO (International Standardization Organization) – ISO 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML).

2.2. Цели и сфери на приложение на UML

Основната цел на UML е да се предостави

една добре развита система от средства за моделиране, която да не е зависима от конкретен език за програмиране. UML моделите, създавани за една система от даден екип, са разбираеми за софтуерни специалисти (проектанти и програмисти) от други екипи.

Основна област на приложение на UML е проектирането на нови системи. UML позволява при големи проекти с участието на много специалисти всички части от проекта да са разработени по еднакъв начин. Освен това UML позволява лесно да се обменя опит между различни екипи и да се използват най-добрите практики.

Друга сфера на приложение на UML са случаите, когато се налага сложни системи да се анализират и поддържат от специалисти, които не са участвали в разработката. Целта е – въз основа на програмния код, наличната

20

документация (но не във вид на UML диаграми) и фактическото функциониране на системата – да се създаде модел на системата със средствата на UML. Този вид дейност се нарича реверсивно софтуерно инженерство (reverse software engineering).

Използването на UML на ниво на програмен код (диаграми на класовете) е съществен фактор в развитието на съвременните средства за обектно-ориентирано програмиране. Разработват се специални програмни средства, които могат автоматично да трансформират клас-диаграмите в програмен код на определен обектно-ориентиран език за програмиране (примерно C#, C++, Java). Тези програмни средства се наричат CASE (Computer-Aided Software Engineering) инструменти. Разра-ботчиците чертаят UML диаграми на класовете, които се компилират директно в изпълним код. Очевидно тази употреба на UML поставя много високи изисквания към CASE инструментите.

21

3. Модели на софтуерните системи и UML диаграми

3.1. Класификация на моделите и типовете UML диаграми

Общият модел на една софтуерна система се разглежда като изграден от два взаимодопълващи се модела:

(a) Структурен модел (structural model), който показва структурата на системата и подсистемите, използвайки обекти, атрибути, операции и връзки.

(b) Функционален модел (Functional model), наричан още динамичен модел (Dynamic model), който показва функционалността на системата и измененията на

системата във времето. Всяка UML диаграма е частично

графично представяне на един от двата системни модела. В UML 1.0 от 1997 г. са дефинирани 10 типа диаграми. В UML 2.0 от 2004 г. са добавени още три типа диаграми.

Структурен модел и структурни диаграми

Диаграмите, които представят аспекти на структурния модел, се наричат структурни

22

диаграми. Към структурните диаграми се отнасят следните 6 типа:

Първите четири типа диаграми представят логическата структура на системата (която не зависи от организацията на програмите във файлове и от тяхното разположение върху компютрите):

o Class diagrams (диаграми на класовете),

o Object diagrams (обектни диаграми),

o Package diagrams (диаграми на пакетите),

o Composite structure diagrams (диаграми на съставна структура).

Следващите два типа диаграми представят физическата структура на системата:

o Component diagrams (компонентни диаграми),

o Deployment diagrams (диаграми на разгръщане на системата).

Функционален модел и

функционални диаграми Диаграмите, които представят аспекти на

функционалния модел, се наричат функционални диаграми или поведенчески (behavioral). Към функционалните диаграми се отнасят следните 7 типа:

o Activity diagrams (диаграми на дейностите),

o Use case diagrams (диаграми на случаите на употреба),

23

o State machine diagrams (диаграми на състоянията);

И четири типа диаграми на взаимодействията:

o Sequence diagrams (диаграми на последователностите),

o Communication diagrams (диаграми на комуникациите),

o Interaction overview diagrams (диаграми за преглед на взаимодействията),

o Timing diagrams (времеви диаграми).

24

Фиг. 1. Класификация на типове UML диаграми (източник [7]).

25

3.2. Дефиниране на типовете диаграми – нотации и мета-модели

За всеки тип диаграми UML дефинира нотация и мета-модел.

Нотацията (notation) са графичните елементи, които се виждат в моделите; това е графичният синтаксис на езика за моделиране. Например нотацията за диаграма на клас дефинира как се представят елементи и концепции като клас, асоциация и множественост.

Тук възниква въпросът какво точно се има предвид под асоциация и клас.

Мета-модел (meta-model) в UML се нарича формалното дефиниране или неформалното описание на основните понятия, използвани в UML диаграмите. Официалната спецификация на езика UML съдържа формални дефиниции на основните понятия при всеки тип диаграми. Но в повечето практически ръководства начинът на използване на графичните нотации и тяхната интерпретация се обясняват чрез интуитивни, неформални описания и примери.

26

4. Типове структурни UML диаграми

UML 2 описва 6 типа структурни диаграми, показани в таблица 2.

Типове диаграми

Предназначение Произход

Class diagram (диаграма на класовете)

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

UML 1

Object diagram (диаграма на обектите)

Представя обектите (инстанции на класове) в система в даден момент

UML 1

Composite structure diagram (диаграма на съставна структура)

Изобразява вътрешната структура на класовете

Ново в UML 2

Package diagram (диаграма на пакетите)

Йерархична структура по време на компилиране

UML 1

Диаграми на физическата структура

Component diagram (компонентна диаграма)

Структура и връзки на компоненти

UML 1

27

Deployment diagram (диаграма на разгръщане)

Показва физическата схема на една система

UML 1

Таблица 2. Типове структурни диаграми в UML 2.0.

4.1. Диаграма на класовете (class diagram)

Диаграмата на класовете описва класове (в смисъла на обектно-ориентираното програмиране) и различните видове взаимоотношения, които съществуват между тях.

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

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

Фиг. 2. Пример за диаграма на клас.

28

Диаграмите на класовете представят и

връзките между класовете (зависимости и отношения на наследяване). На фигура 3 са показани графичните компоненти (различни видове стрелки), чрез които се описват връзките между класовете.

Фиг. 3. Нотация на диаграмите на класовете.

Важна връзка е генерализация (generalization). Генерализация се използва, когато два класа си приличат (подобни са), но имат някои разлики. Фигура 4 е пример за генерализация.

29

Фиг. 4. Пример за диаграма на класове с отношение на генерализация (наследяване).

От гледна точка на обектно-ориентираното програмиране това отношение се реализира чрез наследяване (inheritance). Класовете “Corporate Customer” и “Personal Customer” се дефинират като наследници на класа “Customer”.

Друг вид връзка между два класа е асоциацията (association). Представя се чрез непрекъсната линия между двата класа, като посоката на стрелката е от класа източник към класа цел. Връзката може да се характеризира с множественост (multiplicity) – означение за това: колко на брой обекта може да реализират обозначеното с линията отношение. Най-често срещани видове множественост са:

30

1 (точно един обект),

0...1 (0 или 1),

* ( няма горна граница). При атрибутите има различни термини,

които се отнасят за множествеността:

Optional (незадължителен) означава долна граница 0.

Mandatory (задължителен) означава долна граница, равна на 1 или повече.

Single-valued (с една стойност) означава горна граница 1.

Multivalued (с множество стойности) означава горна граница повече от 1.

На фигура 5 е показан пример за асоциация.

Фиг. 5. Пример за диаграма на класове с отношение на асоциация.

31

4.2. Диаграма на обектите (object diagram)

Диаграмата на обекти (object diagram) представя обектите (т.е. инстанции на класовете) в една система в определен момент. Тази информация не може да се представи с диаграмите на класовете, които показват дефинициите на класовете. Например на фигура 6а e показана диаграмата на класовете с два класа – Computer и Repository. На фигура 6б e показана диаграмата на обектите, в която са представени 2 обекта (с имена ws101 и ws104) от клас Computer и един обект (с име nw) от клас Repository.

(a) Диаграма на класовете

32

(b) Диаграма на обектите

Фиг. 6. Пример за диаграма на обектите (източник [3]).

4.3. Диаграма на съставна структура (Composite structure diagram)

В UML 2 е добавен тип диаграми, който

дава възможност да се изобрази вътрешната структура на клас. Основни елементи на тези диаграми са:

- Части (parts) – относително обособени части от класа, представят се графично чрез правоъгълници, в които е вписано име на частта. Когато частта е обект от даден клас, се записва име_на_обекта: име_на_класа.

- Конектори (connector) – връзки между частите, представят се с линии, които свързват правоъгълниците.

33

- Портове (ports) – точки на взаимодействие, обикновено променлива, чрез която се осъществява връзката между частите. Графично това е допирната точка на конектор до един правоъгълник.

Според документацията на UML всички програмни модули, които могат да се представят като състоящи се от свързани части, се означават с абстрактния термин „структуриран класификатор” (structured classifier). Диаграмите на съставна структура могат да се прилагат за всички „структурирани класификатори”, не само за класове. Но примерите в ръководствата по UML са единствено за класове.

На фигура 7 е представена композитна диаграма на класа car. Четирите части са обекти от класа Wheel. Тези обекти са представени вътре в класа, като съставни части на всяка инстанция на класа.

34

Фиг. 7. Пример за диаграма на съставна структура (източник [5]).

4.4. Диаграми на пакети (package diagram)

Пакетът (package) представлява

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

В един UML модел всеки клас е член на един-единствен пакет. Пакетите от своя страна могат да бъдат членове на други пакети и така се получава йерархична структура, в която пакетите от най-горно ниво се разделят на подпакети с техни собствени подпакети и така нататък, докато йерархията стигне най-ниското

35

ниво – класовете. Един пакет може да съдържа както подпакети, така и класове.

Фиг. 8. Пример за диаграма на пакети.

Забележка: UML позволява “пакетите” да

се използват и като контейнери за други типове диаграми, но това се прилага много рядко.

4.5. Диаграми на физическата структура на системата

UML дефинира два типа диаграми, които

представят физическата структура на системата:

o Component diagram (компонентна диаграма),

o Deployment diagram (диаграма на разгръщане на системата).

36

Компонентна диаграма (Component diagram)

Компонентната диаграма представя

графично физическия аспект на обектно-ориентираната софтуерна система – как тя е организирана във файлове и зависимостите между тях. Софтуерните компоненти включват:

Компоненти на сорс-кода (source code components), като се показват съществуващите между тях зависимости при компилация.

Изпълними компоненти (executable components) – във вид на .exe .dll или друг тип файлове, като се показват връзките между тях при изпълнение.

На фигура 9 е показана нотацията, използвана при компонентните диаграми, а на фиг. 10 е показан един пример за компонентна диаграма.

Фиг. 9. Нотация на компонентните диаграми.

37

Фиг. 10. Пример на компонентна диаграма.

Диаграма на разгръщането (deployment diagram)

Диаграмата на разгръщането (deployment diagram) показва кои софтуерни компоненти на какъв хардуер работят.

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

- Устройството (device) е хардуерно устройство; това може да бъде компютър или по-прост хардуер, свързан към система.

- Средата за изпълнение (execution environment) e софтуер, който хоства или съдържа друг софтуер; например операционна система или процес-контейнер.

Възлите съдържат софтуерните компоненти на системата, обикновено файлове.

38

Тези файлове могат да бъдат изпълними (например файлове с разширение „.ехе”, двоични файлове, DLL файлове, JAR файлове, асемблита или скриптове) или файлове с данни, конфигурационни файлове, HTML документи и т.н. Ако в един възел има показан софтуерен компонент, това означава, че този компонент се разгръща в този възел. Връзки (connections) индикират комуникационния път между два възела.

Фигура 11 показва графичната нотация в диаграмите за разгръщане, а фигура 12 съдържа един пример за диаграма на разгръщане.

Фиг. 11. Нотация на диаграмите за разгръщане.

39

Фиг. 12. Пример за диаграма на разгръщането.

40

5. Типове функционални UML диаграми

UML 2 описва 7 типа функционални

диаграми, показани в таблица 3.

Типове диаграми

Предназначение Произ-ход

Use case diagram (диаграма на случаите на употреба)

Как потребителите взаимодействат със системата

UML 1

Activity diagram (диаграма на дейностите)

Процедурно и паралелно поведение

UML 1

State Transition diagram (диаграма на състоянията)

През какви състояния преминава даден обект. Друго название State Machine diagram

UML 1

Диаграми на взаимодействията

Communication diagram (комуникационна диаграма)

Взаимодействие между обекти; ударение върху връзките Предишно название Collaboration diagram (диаграма за сътрудничеството)

UML 1

Sequence diagram

Взаимодействие между обекти;

UML 1

41

(диаграма на последователностите)

ударение върху последователностите

Timing diagram (времева диаграма)

Взаимодействие между обекти; ударение върху синхронизацията

Нова в UML2

Interaction overview diagram (диаграма за преглед на взаимодействие)

Комбинация от диаграми на последователностите и диаграми за дейностите

Нова в UML 2

Таблица 3. Типове функционални диаграми в UML 2.0.

5.1. Диаграма на случаите на употреба (Use case diagram)

Диаграма на случаите на употреба се

използва за специфициране на функционал-ните изисквания към разработваната софтуер-на система – от гледна точка на различните типове потребители и външни клиенти. Състои се от актьори (actor), случаи на употреба (use cases) и връзките между тях.

Актьор е някой или нещо извън системата, което взаимодейства със случаите на употреба, написани за тази система.

Сценарий (scenario) е серия от стъпки, описващи взаимодействието между потре-

42

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

Use case (communication) relationship показва връзката между актьори и случаи на употреба. Фигура 13 показва елементите на диаграмите на случаи на употреба.

Фиг. 13. Нотация на диаграмите на случаите на употреба (източник [9]).

Фиг. 14. Пример за диаграма на случаите на употреба.

43

5.2. Диаграма на дейностите (Activity diagram)

Диаграмите за дейност изобразяват

дадена дейност (някакъв относително сложен комплекс от действия) чрез графично представяне на последователността от действия. Този тип диаграми е наследник на алгоритмичните блок-схеми (flowchart).

Диаграмата има един символ за начало и един символ за край. Действията се изобразяват като правоъгълници, а преходите от едно действие към друго със стрелки. Условното разклонение се означава с ромб. Символът „вилица” (fork) се използва за изобразяване на паралелно разклоняване на процесите. Удебелената черта, но с няколко входящи стрелки и с една изходяща, означава обединяване на процеси в един общ процес (join).

Нотацията, използвана за диаграмите за дейност, е показана на фигура 15; пример е показан на фигура 16.

Фиг. 15. Нотация на диаграмите на дейност (източник [9]).

44

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

Фиг. 16. Пример за диаграма на дейност (източник [4]).

5.3. Диаграма на състоянията (State Machine diagram)

Диаграмата на състоянията представя последователността от състояния, през които

45

преминава даден обект. Това е една силно разширена версия на нотацията за диаграма на състоянията и преходите на крайни автомати, използвана в математическата теория на автоматите.

Най-често диаграмите се използват за представяне на последователните състояния, през които преминава един обект от даден програмен клас. Състоянията (states) на обекта се представят като правоъгълници. Преходите (transition) от едно състояние към друго се представят чрез стрелки. Обектът има едно начално състояние и няколко крайни състояния. Тригерите (trigger events) са събития, които инициират даден преход (респективно, ако събитието не възникне, преходът е невъзможен).

Фиг. 17. Нотация за диаграмите на състоянията (източник [9]).

46

Фиг. 18. Пример 1 за диаграма на състоянията (източник [4]).

С този тип диаграми могат да се описват и абстрактни обекти с голяма степен на обобщение, примерно състоянията на даден модул. Няколко състояния могат да бъдат обединени в едно суперсъстояниe (superstate).

Фиг. 19. Пример 2 за диаграма на състоянията.

47

5.4. Диаграми на взаимодействията

При диаграмите на взаимодействията

се предполага, че дейността на системата може да се разглежда като колективна дейност на множество от относително обособени участници (actors). Като “участници” могат да се дефинират програмни компоненти. Това може да са големи подсистеми, но може да са отделни инстанции на даден клас. Понякога като “участници” се дефинират и лица, взаимодействащи със системата (потребители, администратори). Диаграмите на взаимодействията представят графично взаимодействия между различните участници. “Взаимодействията” най-често са обмяна на съобщения: заявки към даден участник да извърши дадено действие и съобщения за завършване на дадено действие от участник.

UML включва 4 типа диаграми на взаимо-действията:

o Диаграма на комуникации (communication diagrams),

o Диаграма на последователността (Sequence diagram),

o Времева диаграма (Timing diagram) [UML2],

o Диаграма за преглед на взаимодействията (Interaction overview diagram) [UML2].

48

Диаграма на комуникациите (communication diagrams)

Диаграмата на комуникациите (communication diagrams) позволява свободно разполагане на правоъгълници, символизиращи участници, чертане на стрелки за визуализиране на начина на свързване на участниците и използва номериране за последователността на съобщенията. В UML 1.x тези диаграми се наричат диаграми на сътрудничеството (collaboration diagrams).

Диаграма на последователността (Sequence diagram)

Диаграмата на последователността (Sequence diagram) показва взаимодействията между обектите, подредени във времева последователност. Оста на времето е отгоре–надолу.

Фиг. 20. Пример за диаграма на последователността.

49

Времева диаграма (Timing diagram)

Времевата диаграма (Timing diagram) е

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

Фиг. 21. Пример за времева диаграма.

Времеви диаграми се използват при проектиране на софтуер, при който е важно да се спазват точно времевите интервали между

50

събитията; това е предимно софтуер за вграждане в технически устройства (embedded software) или за системи за управление на производствени процеси в реално време (real-time systems).

Диаграма за преглед на взаимодействията (Interaction overview diagram)

Диаграмата за преглед на взаимодействията дава възможност за представяне на връзки между диаграми на взаимодействията от трите типа: диаграма на комуникациите, диаграма на последо-вателността, времева диаграма.

Методът за конструиране на диаграмата е подобен на този на диаграмата на дейностите; използват се същите моделиращи елементи – стрелки за преход, ромб за условен преход и правоъгълници. Всеки от правоъгълниците представя една диаграма на взаимодействията. Диаграмата или е нарисувана в правоъгълника, или в правоъгълника е показано името на диаграмата, а в горния ляв ъгъл има препратка [ref], чрез която в нов прозорец се показва съответната диаграма.

51

Фиг. 22. Пример на диаграма за преглед на взаимодействията (източник [4]).

52

6. Приложение на UML за проектиране на

информационни системи

Оценката за полезността от използване на UML диаграмите е различна както по отношение на нивото на проектиране – високо ниво или детайлно ниво (ниво на класовете), така и по отношение на отделните типове диаграми.

6.1. При проектиране на високо ниво

Предимства

При проектиране на високо и средно ниво на обобщение най-често се използват структурните и функционалните диаграми. От структурните диаграми най-често се използват:

Диаграми на пакетите (Package diagrams),

Диаграмите, които представят физическата структура на системата – компонентната диаграма (Component diagram) и диаграмите за разгръщане на системата (Deployment diagram).

От функционалните диаграми най-често се използват:

Диаграмите на случаи на употреба (Use case diagrams),

53

Диаграма на последователностите (Sequence diagram).

Диаграмите на случаи на употреба и диаграмите на последователностите са се наложили като задължителна част от проектите на всяка по-голяма софтуерна система. Те дават лесно разбираема картина на функционалността на системата от гледна точка на потребителите (в статичен и в динамичен аспект).

Недостатъци

Диаграмите представят определена информация в нагледен и удобен за бързо възприемане вид, но не могат да заменят описателната документация.

Например диаграмата за разгръщане на системата показва къде се разполагат отделните програми. Но тя не съдържа информация за това как протича инсталационният процес, какви са изискванията към операционната система, към техническите устройства и други важни данни, които се описват в едно “ръководство за инсталиране на системата”.

По отношение на описанието на системата от потребителска гледна точка ситуацията е сходна. Use case диаграмите и диаграмите на последователностите са много удобни, но не дават пълната информация за проектираното взаимодействие между потребителите и системите. Това затруднява възприемането им от потребителите.

Почти всички съвременни софтуерни системи са с графичен потребителски

54

интерфейс (Graphical User Interface GUI). Дизайнът на диалоговите форми е важна част от проекта на GUI, която не е включена в изразните средства на UML.

6.2. При детайлно проектиране – проектиране на класовете

Предимства

При проектиране на класовете се използват от структурните диаграми:

Диаграми на класовете (Class diagrams),

Диаграми на обектите (Object diagrams),

Диаграми на съставна структура (Composite structure diagrams);

и от функционалните диаграми:

Диаграма на дейностите (Activity diagram).

Тези диаграми изразяват аспекти на класовете, които много трудно могат да бъдат представени “описателно”. Диаграмите са често единствената документация на класовете освен коментарите в сорс-кода.

Недостатъци

Диаграмите на класовете представят най-съществената част от описанието на един клас – неговите методи и свойства, и затова се възприемат лесно от програмистите. Но ситуацията е коренно различна при диаграмите на обектите (Object diagrams) и диаграмите на

55

съставна структура (Composite structure diagrams). Често тяхното използване се отхвърля от програмистите с мотива, че са излишни.

Освен това, когато не се използват CASE продукти, при промяна на програмния код трябва ръчно да се актуализират и диаграмите, т.е. поддържането на актуалното състояние на диаграмите е допълнително натоварване за програмиста.

Използването на CASE продукти има от своя страна и други недостатъци като високата цена и необходимостта от задълбочено практическо познаване на същността на процесите.

56

7. Пример “Информационна система за детска градина”

7.1. Цели и обхват на системата

Примерният UML модел на

информационна система за детска градина е изграден в съответствие със следните фактически данни за обекта:

- Детската градина има 20 групи - Една група може да има между 15 и 25

деца - Учителите, които се занимават с децата

са две категории: (а) Общообразователни учители. Един

общообразователен учител обучава само една група.

(б) Учители по музика. Един учител по музика преподава на няколко групи.

- За всяко дете се изисква съхраняване на следните данни: име, рождена дата, адрес, телефонен номер за връзка с родителите, дата на постъпване в детската градина.

- За всеки учител се изисква съхраняване на следните данни: име, адрес, телефонен номер образование.

Учителите имат право на ползване на системата само в справочен режим.

Въвеждането и промяната на данни ще се извършва от двама администратори на системата, които е възможно и да не са учители.

57

Има специално изискване да се поддържат журнали със записи на историята на промените на данните в системата.

В следващите раздели са представени UML диаграмите на информационната система, създадени с програмата Visual Paradigm for UML 6.2.

7.2. Диаграма на случаите на употреба (Use Case Diagram)

Фиг. 23. Диаграма на случаите на употреба

58

Предвидени са следните потребители (actors) и сценарии, в които те могат да участват:

Потребители на системата: Администратор – има права както за

четене така и за модифициране/добавяне на данни и проследяване на исторически журнални записи

Учител – има права само за четене на данни от системата

Всички сценарии изискват първоначална регистрация в системата за да се определи съответната роля (права на достъп) на потребителя.

59

7.3. Диаграми на класовете Entity Class Diagram

Фиг. 24. Диаграма на класовете

Диаграмата на класовете представя

модела на различните обекти, които участват в системата - класовете същности (entity classes), както следва:

60

• User – обединява двата типа потребители (администратор и учител).

• Teacher (General_Teacher or Music_Teacher) – наследява user с нови допълнителни атрибути.

• Group – детска група, която е свързана с един общообразователен учител и един по музика.

• Child – включва личната информация за едно дете от дадена група.

• History_Log – журнални записи на историята на промените на данни в системата.

• Roles – потребителски роли: администратор и учител (имат различни права за достъп).

61

Business Class Diagram

Фиг. 25. Диаграма на бизнес клас

62

Логическият слой на системата може да се раздели на 3 модула, които си комуникират и зависят един от друг:

• UserModule (SystemUser) - той осъществява връзката с UI модула и крайните потребители на системата.

• ActionModule (SystemOperation_Manager) – извършва различни операции, за които са подадени заявки от UserModule. Той е свързващото звено на UserModule с EntityModule, който капсулира данните.

• SecurityModule – предоставя методи за аутентификация при логване и оторизация при заявки до ограничени за ползване методи.

63

User Interface Class Diagram

Фиг. 26. Диаграма на класовете за потребителския

интерфейс

64

Тази диаграма представя класовете, свързани с графичния интерфейс на системата, който се състои от:

• Login форма – за първоначална регистрация в системата.

• Main форма – за избор на операция. • Различни форми за визуализация и

модификация на данни в системата (за потребител, дете, група и история на промените на данните).

7.4. Диаграми на последователностите

Administrator Sequence Diagram На фиг.27 е представена диаграмата на

последователностите на администратора.

65

Фиг. 27. Диаграма на последователностите за

администратор

Диаграмата на последователностите представя обработката на заявка към операция с ограничен достъп, в случая – ModifyUser, но

66

разсъжденията са аналогични и за останалите операции за добавяне или модификация.

Teacher Sequence Diagram

Фиг. 28. Диаграма на последователностите за учител

Диаграмата представя обработката на

заявка към операция за ReadOnly достъп до данни, която е разрешена за всички потребители на системата, в случая – GetUsers, но разсъжденията са аналогични и за останалите операции за преглед на данни.

7.5. Диаграма на дейностите Activity Diagram – Action Process Flow

67

Фиг. 29. Диаграма на дейностите

Диаграмата на дейностите представя

поредицата от действия, които се извършват по време на обработката на дадена операция.

1. Регистрация на потребителя 2. Аутентификация 3. Заявка за операция 4. Оторизация (проверка дали

операцията е достъпна за текущия потребител)

5.1. При отказан достъп – генерира се съобщение за грешка

Изход от системата 5.2. При успешен достъп – операцията се

извършва

68

6.1. Ако операцията е успешна – генерира се исторически запис за операцията

6.2. Ако операцията не е успешна – генерира се съобщение за грешка

7. Изход от системата

7.6. Компонентна диаграма Component Diagram На фиг. 30 е представена компонентната

диаграма.

69

Фиг. 30. Компонентна диаграма

Компонентната диаграмата представя в по-общ план отделните нива на системата. Специфичната реализация на всеки един от компонентите е разгледан по-подробно в клас

70

диаграмите, докато тук се вижда взаимодействието между тях.

Слоевете са: • Потребителски интерфейс • Логическо ниво • Ниво на достъп до данните (Data access

level DAL) Връзката с базата данни се прави само

през класовете от най-ниското ниво - DAL. Класове на това ниво съответствуват на определени типове индивиди, типове физически обекти, или типове абстрактни обекти, които се наричат с общия термин “същности”. Съответно, класовете на ниво на достъп до данните се наричат “класове на същностите” (entity classes).

7.7. Релационен модел на базата данни

Програмата Visual Paradigm предоставя и

средства за създаване на релационен модел на базата данни, както и автоматично преобразуване на този модел в дефиниции на таблици на езика SQL.

71

Фиг. 31. Релационен модел на базата

Visual Paradigm съдържа средства за подпомагане на програмиста при обвързване на релационен модел на базата данни от една страна, с “класовете на същностите” дефинирани в DAL. В някои случаи това съответствие просто – един клас съответствува на една таблица.; и данните за един обект съответстват на един ред от таблицата.

В други случай обаче, съответствието е по-сложно. Данните за една “същност” може се съхраняват няколко таблици в релационната база данни. Тогава за актуализация на данните в базата данни в съответствие с промените в програмните обекти за “същностите” са необходими по-сложни обработки.

72

8. Средства за визуално и декларативно програмиране –

общ преглед

8.1. Увод До тук разгледахме CASE инструменти,

които са базирани на използването на UML. Втората голяма група от CASE

инструменти са средства за визуално програмиране (СВП, на английски Visual Programming Tools).

При използване на средства за визуално програмиране, програмистът разработва програмата в два режима:

- В режим „дизайн” програмистът може да извършва промени в графични изображения на компонентите на програмата.

- В режим „кодиране” програмистът може да променя кода на програмата, представен във вид на текст.

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

Работата с визуалните средства се допълва от средства за задаване на стойности на свойства на компонентите по декларативен начин, т.е. задаване на стойностите чрез избор

73

от меню, когато свойството има малък брой възможни стойности, или чрез попълване на стойностите в определени полета. Тези вид средства за подпомагане на програмирането се наричат средства за декларативно програмиране. Тези средства нямат връзка с т.н. езици за декларативно програмиране; тук става въпрос за подпомагане на програмирането с езици за обектно-ориентирано програмиране, като VB, C#, Java.

Средствата за визуално и декларативно програмиране се разработват и разпространяват не като самостоятелни софтуерни продукти, а като част от някоя интегрираната среда за разработка (Integrated Development Environment IDE), заедно със средства тестване, компилиране, управление на проекти и други инструменти, които тук няма да разглеждаме.

В тази и следващите глави ще разгледаме средствата за визуално програмиране включени в две от най-често използваните днес интегрирани среди за разработка:

- Visual Studio 2005 на Microsoft, за езици C#, Visual Basic и други (за .NET 2.0)

- NetBeans 6.5 – отворен код на NetBeans community съвместно с Sun Microsystems – за езика Java (за J2ЕЕ 1.4 и Java EE 5)

Средствата за визуално програмиране не са свързани пряко с използването на UML диаграми и повечето съвременни СВП нямат собствени инструменти за работа с UML диаграми. Връзката между СВП и UML базираните CASE инструменти се осъществява

74

засега чрез допълнителни продукти. Като пример ще разгледаме продукта Smart Development Environment (SDE) на фирмата Visual Paradigm, предназначен за интегриране в голям брой среди за програмиране. В частност, SDE има варианти за интегриране с разглежданите от нас две среди за визуално програмиране:

- SDE-VS – за интегриране с MS Visual Studio 2005;

- SDE-NB – за интегриране с NetBeans 6.5 Средствата за визуално програмиране

служат главно за разработване на графичния потребителски интерфейс. Паралелно с текстовото представяне на програмния код се поддържа графично изображение на потребителския интерфейс.

Основната цел при създаването на средствата за визуално програмиране е те най-точно да отразяват, от една страна, характеристиките на потребителския интерфейс и от друга страна, синтаксиса на съответния програмен език.

Особено голяма роля имат средствата на визуално програмиране при начинаещи програмисти, които използват тези средства на научаване на синтаксиса на езика. Но тяхното използване е ефективно и за програмисти с опит в даден програмен език. Някои противници на средствата на визуално програмиране твърдят, че е „едно и също” дали един опитен програмист ще напише нужния код или ще попълни параметри в определен панел, въз основа на който системата ще генерира програмния код. Но професионалните

75

програмисти са по правило опитни не само в познаването езика за програмиране; те са опитни и в използването на средствата на визуално програмиране. Създаването на един и същ програмен текст отнема неколкократно по-малко време, когато се използват средствата за визуално програмиране.

Основни инструменти в средствата за визуално програмиране са:

- панели с графични компоненти за потребителския интерфейс (бутони, текстови полета, етикети и т.н.);

- панели за настройка на параметрите на графичните компоненти.

В режим „дизайн” програмистът може да „издърпа” с мишката (“drag-and-drop”) даден графичен компонент в работната област и да го разположи на нужното място. След това може да зададе стойности на параметрите на компонента. Средствата на визуално програмиране преобразуват тези действия в команди на съответния програмен език.

На фигурата се виждат трите основни средства използвани при визуалното програмиране в Visual Studio:

- Работната област в режим дизайн

(“Design”) в средата на екрана. В нея са изобразени трите компонента – един етикет, един бутон и едно текстово поле.

- Панелът с компоненти на графичния интерфейс („Toolbox”), разположен в ляво от работната област.

- Панелът за редактиране на свойствата на компонентите („Properties”), разположен в дясно от работната област. В най-горния ред се

76

виждат името и типът на компонента, чийто свойства са представени в даден момент.

Фиг. 32. Разположение на панелите във Visual Studio

Превключването на работната област от режим „дизайн” към режим „кодиране” се извършва чрез двата етикета (“Source” и “Design”), разположени непосредствено под работната област.

Начинът по който са разположени трите панела не е фиксиран. Програмистът може да ги разположи по начин, който счита за удобен. Но в рамките на този и следващите примери, ние ще поставяме вляво панела с компоненти на графичния интерфейс, а вдясно - панела за редактиране на свойствата на компонентите.

77

Текстовият редактор за код на VS.NET поддържа всички утвърдени съвременни функции на редакторите за програмен код – синтактично оцветяване за по-лесно визуално възприемане на кода и намаляване на грешките, автоматично довършване на започнат израз, автоматично извеждане на помощна информация по време на писане, средства за навигация по кода и много други. Тези помощни средства в редактора на кода не се отнасят към методите на визуалното програмиране и затова ще ги разгледаме отделно в глава 11.

На следващата фигура е показан екранът в NetBeans IDE 6.5.

Фиг. 33. Панелите на NetBeans IDE, разположени по същия начин, както при Visual Studio

Панелите и в тази система са подвижни и могат да бъдат разположени по начин който е най-удобен за програмиста. Тук ние ще

78

използваме еднаква подредба на панелите при примерите с NetBeans IDE и с Visual Studio 2008, за да подчертаем приликите между двете системи. Ще видим че в много аспекти двете системи са изградени по един и същ начин и имат почти еднакви функции.

8.2. Примерна задача Примерът въз основа на който ще

разгледаме визуално-декларативните инстру-менти за подпомагане на програмирането е следният:

Трябва да се създаде програма, която да преобразува температурни градуси, зададени по скалата на Фаренхайт (наричани по-нататък кратко “градуси Фаренхайт”) във градуси по скалата на Целзий (наричани кратко “градуси Целзий”). Нека означим градусите Фаренхайт

tFahrenheit, а градусите Целзий tCelsius

Формулата за преобразуване е

tCelsius = (tFahrenheit - 32) * (5/9) Екранът трябва да изглежда като на

фиг. 34. Потребителят трябва да въведе данните в дясното поле, да натисне бутонът “=” и резултатът да се изведе в лявото поле.

Фиг. 34. Проект на екрана

79

Ще разгледаме по отделно разработката на програмата в два варианта:

- В глава 8 – при създаване на настолно приложение.

- В глава 9 – при създаване на уеб базирано приложение.

Процесът на разработване на едно относително просто приложение може да бъде разделен на четири стъпки.

Стъпка 1. Създаване на проект - Избира се съответния тип проект. За

всеки от типовете проекти, средата за разработка създава по подразбиране някакъв набор от компоненти. Ако програмистът не желае никакви предварително създадени компоненти, то трябва да избере типа “празен проект”.

- Задава се име на проекта и директория за съхранение на файловете от проекта.

Стъпка 2. Създаване на потребителски интерфейс

- Създават се нужните екранни форми. - Във всяка от формите се добавят

нужните контроли. - Редактират се свойствата на контролите

(шрифт, рамка, фон, и други) за да получи формата желания външен вид.

- Код се добавя само за навигация между формите, т. е. извикване на една форма от друга.

Стъпка 3. Създаване на код за обработка на събитията

- Създават се функции свързани с определени събития (натискане на

80

бутон, въвеждане на данни във входно поле, и други).

- Добавя се необходимия код за обработка на събитията.

Стъпка 4. Стартиране и тестване на програмата

- Стартира се програмата. - Проверява се дали програмата

функционира правилно, чрез няколко тестови случая (за които предварително се знае какъв е очакваният правилен резултат).

- Ако програмата не функционира правилно, се връщаме към някоя от предходните стъпки.

Ще проследим използването на визуално-декларативните средства за подпомагане на програмирането на всяка от четирите стъпки:

- в среда на Visual Studio 2008 - в среда на NetBeans IDE 6.5

Паралелният анализ на средствата в двете среди ни дава възможност да видим общите характеристики и различията на използваните средства за визуално и декларативно програмиране.

Няма да описваме детайлно всички елементарни действия (като отваряне на програмата, избор на команди и отваряне и затваряне на менюта и т.н.), тъй като смятаме, че те до голяма степен са познати. Ще се спираме на тези стъпки, които имат особености и се нуждаят от пояснения.

81

9. Визуално и декларативно програмиране при

разработване на настолни системи

9.1. Стъпка 1. Създаване на нов проект

Стъпка 1 със Visual Studio 2008 (VB) Създаваме нов проект, като типът му е

“Windows -> Windows Application” (фиг.35). Задаваме име на проекта WindowsApplication1 и директория за съхранение на файловете от проекта.

Фиг. 35. Избор на тип нов проект във Visual Studio

82

Стъпка 1 със NetBeans IDE 6.5 (Java) Създаваме нов проект, като типът му е

Java Desktop Application” (фиг.36). Задаваме име на проекта Desktop Application1 и директория за съхранение на файловете от проекта.

Фиг. 36. Избор на тип нов проект в NetBeans IDE 6.5

9.2. Стъпка 2. Дизайн на потребителския интерфейс

Стъпка 2 със Visual Studio 2008 (VB) Към проекта добавяме нов елемент, като

от инсталираните готови макети избираме последователно Form и About box (фиг.37)

Фиг. 37. Избор на елемент във Visual Studio

83

За да можем да използваме възможностите на визуалното програмиране, трябва да приключим в режим Design. Готовият елемент изглежда по следния начин:

Фиг. 38. Изглед на формата About box

Сега трябва да се редактира формата Form1. Тъй като във формата липсва меню, трябва да се добави. Добавяме главно меню като издърпваме компонент MenuStrip.

84

Фиг. 39. Добавяне на главно меню.

В главното меню посочваме следните

елементи: - File - Help

o About

Фиг. 40. Елементи на главното меню

Превключваме в режим Source за да

видим кода към елементите на менюто:

85

Фиг. 41. Генерираният автоматично сорс код за Form1

Информацията, която се появява в About

box се попълва от Assembly Information, която е автоматично генерирана. Променяме необходимите текстове (например в Title и Description).

Фиг. 42. Автоматично генерирана асемблирана

информация

86

Когато се попълни тази информация, тогава вида в About се променя автоматично.

Фиг. 43. Вид на About

На следващата фигура е представен панелът с компоненти на графичния интерфейс „Toolbox”. Някои от тях се използват във Form1.

Фиг. 44. Панелът „Toolbox”.

Във формата се използват следните компоненти: елемент “етикет” Label, елемент „текстово поле” TextBox и елемент „бутон”

87

Button - извличаме ги последователно с мишката от панела „Toolbox” и ги подреждаме в областта за дизайн. Панелът „Properties” е достъпен и чрез него също могат да се задават стойности на свойствата на компонентите TextBox и Button. Например за бутона въвеждаме текст “=”

При изпълнение формата изглежда по следния начин:

Фиг. 45. Окончателен вид на формата

Стъпка 2 със NetBeans IDE 6.5 (Java) В средата на NetBeans IDE файлът, който

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

88

Фиг. 46. Параметричен файл DesktopApplication1.properties

Тогава автоматично генерираният

прозорец “About” ще изглежда по следния начин:

Фиг. 47. Прозорец “About”

Изборът на елементи става от прозореца Palette.

89

Фиг. 48. Прозорец Palette.

Крайният вид на формата DesktopApplication1View.java, създаден с NetBeans IDE е подобен на този, създаден с Visual Studio.

Фиг. 49. DesktopApplication1View.java

90

9.3. Стъпка 3. Добавяне на код към събития

Стъпка 3 със Visual Studio 2008 (VB) На следващата стъпка към събитието

„натискане на бутон” асоциираме функция. Отварянето на панела за въвеждане на код във функцията, става чрез двойно кликване върху бутона. Функцията взема въведеното число в текстовото поле за градуси по Фаренхайт, прави необходимите преобразувания според формулата и извежда получения резултат в текстовото поле градуси по Целзий.

Съдържанието на работната област в режим „кодиране” е показано на следващата фигура. Програмистът има възможност да редактира кода. Текстовия редактор оцветява различно елементите, което много подпомага програмирането.

Фиг. 50. Код на програмата за изчисление

91

Стъпка 3 със NetBeans IDE 6.5 (Java) 3a. Създаване на функция свързана

със събитие на контрол

Тук, за съжаление, не можем да отворим

свързаната с бутона функция, чрез двойно кликване. Трябва да извикаме контекстното меню с десен бутон на мишката, и оттам - през две допълнителни менюта - да стигнем до търсената функция mouseClicked.

Фиг. 51. Добавяне на функция към бутона в NetBeans

3б. Добавяне на код във функцията

Въвеждането на код тук също е улеснено,

като отделните компоненти се разграничават цветово.

92

Фиг. 52. Добавяне на код към функцията

9.4. Стъпка 4. Стартиране и тестване

Стъпка 4 със Visual Studio 2008 (VB)

Стартираме тестването на изготвената форма. Тестваща програма извършва проверки за синтаксиса, логическа проверка на въведените данни и съвместимост на извършваните операции. Това тестване се извършва постъпково, като изпълнението спира при първата грешка и на екрана се извежда редът, където е открита грешката и съобщение за грешка. Ако обаче по време на тестването не се открие грешка програмата се изпълнява и на екрана се появява основната форма. Ако извикаме и формата About, резултатът ще изглежда по следния начин.

93

Фиг. 53. Двата екрана на приложението Windows

Application1

Трябва да отбележим, че единственият

програмен код, който е въведен директно, е кодът във функцията Button1_click. Генерирането на останалата част от кода е пак резултат от действията на програмиста, но това са действия извършвани върху графични обекти и попълване на полета в панелите за свойства на обектите, а не писане на програмен код.

Стъпка 4 със NetBeans IDE 6.5 (Java)

При стартирането на приложението Desktop Application1, резултатът, който се получава е посочен на фиг. 54.

94

Фиг. 54. Двата екрана на приложението Desktop

Application1

Казваме че две развойни среди са

равносилни, ако позволяват създаването на приложения които са сходни както във визуален, така и във функционален аспект. Резултатът от разгледания пример показва, че Visual Studio 2008 и NetBeans IDE 6.5 са равносилни.

Основното различие между двете приложения е в средата за изпълнение. Едното приложение е изпълнимо от виртуалната машина на .NET Framework 2.0 (наричана Common Language Runtime - CLR), Другото приложение е изпълнимо от виртуалната машина Java Virtual Machine (JVM) 5.0.

95

10. Визуално и декларативно програмиране при създаване

на уеб-базирани системи

В тази глава ще опишем създаването на същия проект, но като уеб-базирана система. Ще ползваме развойните среди и езици за програмиране от предходната глава: - Visual Studio 2008 с езика Visual Basic , и - NetBeans IDE 6.5. с езика Java.

10.1. Стъпка 1. Създаване на нов проект

Стъпка 1 със Visual Studio 2008 (ASP)

Избираме от главното меню File–> NewProject. Избираме за език за програмиране Visual Basic, а типът на приложението - Web.

От прозореца за избор на вида проекта, избираме “ASP.NET Web Application”.

Фиг. 55. Избор на уеб приложение

96

Стъпка 1 със NetBeansIDE 6.5 (JSP)

Тази стъпка е по-сложна за изпълнение в средата NetBeansIDE и е разделена на последователност от няколко подстъпки. На първо място от прозореца ChooseProject избираме категорията JavaWeb, а от проекти Web Application.

Фиг. 56. Избор на категория на проекта

С бутон Next преминаваме нататък, където избираме името на проекта и мястото, където ще се съхранява. В следващия прозорец се избира версията на продукта, с която искаме да работим и името на сървъра. Обикновено той е един и е избран по подразбиране. Следващата подстъпка от генерирането на проекта изисква да се избере рамката (framework) на проекта.

97

Фиг. 57. Избор на framework на проекта

След като се натисне бутонът Finish празният проект е създаден.

10.2. Стъпка 2. Дизайн на потребителския интерфейс

Стъпка 2 със Visual Studio 2008 (ASP)

Във Visual Studio 2008 кодът реализиращ динамичната сървърна страница е разделен в два файла:

- <pagename>.aspx, в случая Default.aspx, който съдържа само HTML тагове и ASP контроли;

- <pagename>.aspx.vb, в случая Default.aspx.vb който съдържа само кодът на Visual Basic.

Респективно, програмистът работи в два отделни панела с тези файлове.

Това разделяне не е задължително, но файловете се генерират по тази начин.

98

Фиг. 58. Страница Default.aspx във режим Design

Същата страница в режим Source за писане на код изглежда по следния начин (фиг.59).

Фиг. 59. Страница Default.aspx в режим Soure

Може да се използва и режим Split (фиг. 60), при който екранът се разделя на две части, като в горната се вижда сорс кода на приложението, а в долната част графичният

99

вид. Елементът, който в момента е избран в Design, автоматично се маркира в сорс кода.

Фиг. 60.

Стъпка 2 със NetBeans IDE 6.5 (JSP)

За да се създаде потребителският интерфейс с NetBeans IDE, се използва палитрата от готови елементи Palette, чийто вид е показан на фиг.61. Програмистът има на разположение бутони, текстови полета, етикети, които чрез издърпване може да премести върху работната област.

100

Фиг. 61.Вградени готови елементи

Докато във Visual Studio, всеки елемент от

ASP е достъпен от кода чрез неговото име (ID), то тук връзката се осъществява експлицитно чрез специален атрибут Binding.

За свързване на даден елемент с код, трябва да се извика контекстното меню (при маркиран елемент) и от него да се избере Add Binding Attribute (фиг. 62).

101

Фиг. 62. Свързване на елемент с код

На фиг. 63 се вижда, че двете текстови

полета са свързани с кода чрез имената, указани в атрибута binding – Page1.textField_fahrenheit и Page1.textField_celsius.

Фиг. 63. Имената на полетата, свързани с кода

102

10.3. Стъпка 3. Добавяне на код към събития

Стъпка 3 със Visual Studio 2008 (ASP)

Избираме режим „дизайн” и кликваме два пъти върху контрола „Button1”.

Автоматично се отваря файл default.aspx.vb, който съдържа кода на Visual Basic.NET свързан със събития на default.aspx. Създадена е функция с име Button1_Click и програмистът трябва да въведе в тялото на функцията нужните команди.

Фиг. 64. Въвеждане на командите във функцията

Button1_Click

Стъпка 3 със NetBeans IDE 6.5 (JSP)

Действието, при което се извършва преобразуването на въведената стройност в температура в градуси по Целзий, е натискането на бутона, затова се извиква

103

функцията button1_action. Въвежда се съответния код за изчисление.

Фиг. 65.

10.4. Стъпка 4. Стартиране и тестване

Стъпка 4 със средствата на Visual Studio 2008 (ASP)

Избираме първоначалната страница на проекта default.aspx и стартираме тестването. Тестващата програма проверява кода и ако срещне синтактическа или логическа грешка издава съобщение и спира на грешния ред. Този ред се извежда на екрана, заедно с предложение за онлайн помощ за решаване на проблема. Ако обаче не се открие грешка, то страницата се отваря. За целта може да се използва който и да е популярен браузер - Mozilla Firefox, Internet Explorer или друг. В случая е избран с Mozilla Firefox, като резултатът е следният:

104

Фиг. 66. Уеб страницата, създадена с Visual Studio 2008

(ASP)

Стъпка 4 със средствата на NetBeans IDE 6.5 (JSP)

Тестването на страницата в средата NetBeans IDE протича по аналогичен начин. Бутонът, с който се стартира тестването изглежда по същия начин, както във Visual Studio 2008. Ако не се открият грешки, страницата се визуализира чрез избрания браузер.

В конкретния случай за да се визуализира уеб страницата, създадена с NetBeans използваме браузера Internet Explorer.

105

Фиг. 67. Уеб страницата, създадена с NetBeans IDE

Резултатите от изпълнението на двете

web приложения, създадени с различни програмни среди са аналогични.

106

11. Компютърно подпомагане на кодирането

Средствата за подпомагане на програмирането, основани на визуалния подход са много ефективни при разработка на потребителския интерфейс. Но при кодирането на алгоритмите програмистът трябва да използва изразните средства на програмния език.

Третият клас от CASE инструменти, който ще разгледаме, са средствата за компютърно подпомагане на кодирането. Тези средства са насочени към подпомагане на програмирането на определен програмен език, чрез “подсказване” на езикови изразни средства по време на въвеждането на програмен код.

Към този клас се отнасят два типа инструменти:

А) Средства за извеждане на контекстна помощ и автоматично дописване на изрази. Този тип инструменти са известни с името IntelliSense, което Microsoft използва за собствените си средства от този тип. За да различаваме общото понятие от фирмения термин на Microsoft, ще изписваме общото понятие с малки букви - intellisense.

Б) Средства за вмъкване на програмни фрагменти. Програмните фрагменти се наричат на английски code snippets; от там и самите инструменти за вмъкване на програмни фрагменти се наричат понякога snippets инструменти.

107

11.1. Контекстна помощ и автоматично дописване (intellisense)

Използване на intellisense във Visual Studio 2008

Контекстната помощ се показва автоматично, когато курсора се позиционира върху:

- точка след име на обект или клас – показва списък със свойствата и методите.

- отваряща скоба след име на метод – показва възможните параметри.

За извикване при вече написан текст, контекстната помощ се извиква с клавишната комбинация CTRL+SPACE

Фиг. 68. Контекстна помощ за свойства и методи на класа String

108

Фиг. 69. Контекста помощ за параметрите на метод

Автотипното дописване на ключови думи

или потребителски дефинирани имена на променливи, също се извършва с клавишната комбинация CTRL+SPACE.

Използване на intellisense във NetBeans IDE 6.5

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

Фиг. 70. Автоматично извеждане на методите и

свойствата на обект в NetBeans IDE 6.5

Контекстната информация за

параметрите на даден метод не се извежда автоматично при позициониране върху

109

отварящата скоба. Тук, за разлика от Visual Studio, информацията за параметрите трябва да се извика с клавишната комбинация CTRL+SPACE. В отделен панел се извежда и по-подробна информация за използването на съответния метод.

Фиг. 71. Специален панел с подробна информация за

избрания метод

11.2. Вмъкване на програмни фрагменти (snippets)

Вмъкване на програмни фрагменти във Visual Studio 2008

Във Visual Studio има два начина за вмъкване на програмни фрагменти (snippets)

Първи начин: Меню с програмни фрагменти

110

В прозореца на сорс кода, кликваме с

десен клавиш на мишката и отваряме контекстното меню. От контекстното меню избираме Insert Snippet (фиг. 72). Програмните фрагменти са разделени в няколко групи. Избираме групата с управляващите структури (фиг. 73). Управляващи структури също са разделени на групи (фиг. 74):

- Команди за условни преходи и цикли - Дефиниране на изброими типове,

интерфейси и структури - Управление на събитията при грешка - Дефиниране на свойства, процедури и

събития

Фиг. 72. Контекстното меню съдържащо Inset Snippet

111

Фиг. 73. Избор на група управляваща структура

Фиг. 74. Изборна на подгрупа управляваща структура

Фиг. 75. Избор на команда

Всеки фрагмент има кратко име. На фиг.

75 се вижда, че краткото име на “Try…Catch…End Try” e “TryC”. Краткото име може да се използва при следващо извикване на фрагмента, по начина описан по-долу.

От групата фрагменти за управление на събитията при грешка избираме желаната от нас управляваща структура. Вмъкнатият код е:

112

Фиг. 76

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

Втори начин: Търсене на програмен

фрагмент по кратко име Въвежда се краткото име на фрагмента,

след него се въвежда въпросителен знак (например въвеждаме “TryC?”). При натискане на клавиша за табулация се показва контекстно меню със списък на всички фрагменти, като е позициониран търсеният фрагмент. При кликване с мишката се вмъква съответния фрагмент.

Наборът от фрагменти може да се разширява и модифицира от потребителя чрез “Code Snippets Manager” (фиг. 77).

Стартира се от главното меню Tools> Code Snippets Manager.

113

Фиг. 77. Диалогов прозорец за разширяване и

модифициране на набора от фрагменти

Вмъкване на програмни фрагменти във NetBeans IDE 6.5

Средата NetBeans поддържа три начина за вмъкване на програмни фрагменти.

Първи начин: чрез менюто “Insert code” Менюто “Insert code” се извиква от

главното меню Source> Insert code … или с клавишна комбинация ALT+INS.

114

Фиг. 78.

Но в това меню не са включени управляващи структури, като “try …catch”. Тези структури и други команди на езика Java, могат да се вмъкнат в кода чрез контекстната помощ.

Втори начин: чрез контекстната помощ Въвежда се началната ключова дума и се

натиска клавишната комбинация CTRL+SPACE.

Когато селектираме някой от вариантите на командата, в отделен панел се извежда и фрагмент, който може да бъде вмъкнат чрез двойно кликване.

Фиг. 79. Фрагмент в отделен панел

115

Нека да си припомним, че в Visual Studio, чрез контекстната помощ само се показва формата на командата, но не се вмъква фрагмент.

Трети начин: чрез кратко име И тук както в Visual Studio, фрагментите

имат кратки имена. Например, избрания вариант на управляващата структура “try …catch” има краткото име “trycatch”

Ако знаем краткото име, можем да го напишем и след него да натиснем клавиша за табулация TAB. На фигурата е показан вмъкнатия код:

Фиг. 80. Вмъкнат код чрез краткото име на управляващата

структура

11.3. Обобщение Няма стандарти за разработването на

инструментите за подпомагане на програмирането, и би могло да се очаква, че тези инструменти ще се различават твърде много. Но както видяхме, противно на това очакване, обхватът на предлаганите средства във Visual Studio и NetBeans IDE е приблизително еднакъв. Нещо повече, видяхме, че те са сходни дори в подробности от

116

начина на визуализация, и подробности в конкретния начин на работа. Например, вмъкването на фрагмент в кода по кратко име се извършва с клавиша за табулация TAB. Никакъв стандарт, никаква формална конвенция не е задължила създателите на Visual Studio и NetBeans IDE да използват един и същ клавиш.

Един ретроспективен преглед показва, че съществуващото сходство е характерно само за последните версии на Visual Studio и NetBeans IDE. Колкото по-ранни версии разглеждаме, толкова по-големи разлики ще откриваме. Тенденцията към унифициране на средствата за визуално и декларативно програмиране, през последните години обхваща и други широко използвани IDE, като: JDeveloper на Oracle и Rational Business Developer на IBM.

Съвременното практическо унифициране на средствата за визуално и декларативно програмиране е свидетелство, че тези инструменти са постигнали едно високо ниво на технологична зрялост.

Ползата от унификацията е главно за програмистите разработващи приложен софтуер. Динамиката на пазара на софтуер често принуждава програмистите да преминават от използване на една програмна среда към друга. Благодарение на унификацията на инструменталните среди, този преход е по-бърз и по-лесен.

117

12. Уеб базирани системи за управление на съдържанието

12.1. Какво е система за управление на съдържанието (CMS)?

Системи за управление на

съдържанието, означавани най-често само абревиатурата CMS (от англ. Content management system), е клас от системи за създаване, редактиране и изтриване на съдържанието на уеб сайт.

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

Основни преимущества на CMS: - Децентрализирана поддръжка. - За да се поддържа сайта обикновено е

достатъчен уеб браузер. Може да се редактира навсякъде, по всяко време.

- Системата е създадена за технически необучени редактори.

- Хора със средни знания по обработка на документи могат да създават много лесно съдържание, и то без XHTML познания.

- Възможност за настройка на правата за достъп.

118

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

- Дизайнът на целия сайт остава непроменен.

- Тъй като съдържанието се съхранява отделно от дизайна, съдържанието на всички автори остава непроменено от дизайна.

- Навигацията се генерира автоматично. - Менюто обикновено e въз основа на

съдържанието в базата данни, генерира се автоматично и това премахва опасността да се направят връзки към несъществуващи страници.

- Съдържанието се съхранява в база данни.

- Съхраняването на съдържанието на централно място позволява да се ползва същото на различни места на страницата и да бъде форматирано за различни устройства (уеб браузер, мобилен телефон/ WAP, PDA, принтер).

- Динамично съдържание - Всекидневно обновяване. - Не е необходимо да ползваме уеб

дизайнер или програмист за всяко едно малко изменение - имаме пълен контрол над страницата. - Насърчаването на бързи

обновявания, подсилването на отговорността при редакторите за съдържанието чрез журнали и

119

поощряване на сътрудничеството между авторите.

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

12.2. DotNetNuke DotNetNuke e с отворен код и е

реализирана на Visual Basic за платформата ASP.NET.

Това я прави особено удобна за целите на нашия курс.

Видове модули От гледна точка на това кой е разработчик

на модулите, се различават три вида модули – - Основни модули - безплатни модули с

отворен код, които се разпространяват с DotNetNuke. С версия 4.х се разпространяват около 25 модула.

- Комерсиални модули – модули, разработени от трети фирми, които се разпространяват срещу заплащане.

- Частни модули – модули, създадени за конкретния сайт.

Според това за каква група потребители са предназначени модулите, те се делят на:

- модули предназначени за крайните потребители,

- модули предназначени за администратора на сайта.

120

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

12.3. Модули предназначени за администратора на сайта

Повечето от основните модули в

DotNetNuke са предназначени за администратора на сайта. Списъкът на включените в DotNetNuke административни модули е показан на фигурата.

Фиг. 81. Административни модули включени в

DotNetNuke

Тези модули са безплатни модули с

отворен код, които се разпространяват с DotNetNuke. Те рядко се променят при настройката на сайта, тъй като не са видими

121

при взаимодействието на сайта с крайните потребители. Тяхното изменение влияе единствено върху работата на администратора на сайта.

Ще разгледаме един от най-често използваните модули – модулът “Потребителски акаунти”.

Модулите имат два субмодула: потребителския интерфейс, и субмодул за настройка. Последователно ще разгледаме уеб страниците, включени в двата субмодула.

А) Потребителски интерфейс. Потребителският интерфейс на този

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

122

Фиг. 82. Страница за въвеждане на нов потребител

Втората форма се използва за разглеждане на списъка на регистрираните потребители и избор на редове за редактиране или изтриване.

123

Фиг. 83. Списък на регистрираните потребители

Други две форми се използват за

самостоятелно регистриране на потребители и за логване на потребителя в началото на сесията. Тези форми се извикват чрез опциите Register и Login, които са включени в началната страница на сайта.

Фиг. 84. Форма за логване на потребителя

124

Фиг. 85. Форма за първоначално регистриране

Формата за регистрация съдържа само входни полета за потребителското име и паролата:

Фиг. 86. Форма за влизане

125

Б) Субмодул за настройка Администраторът на сайта може да

определи кои характеристики да се записват в профила на потребителите и кои от тях да са задължителни. Това се извършва чрез формата показана на следващата фигура.

Фиг. 87. Профил на потребителите

Тази форма е много характерна за настройката на един модул; администраторът трябва да избере подходящите за случая атрибути от предварително фиксиран списък от атрибути.

Но при модула “Потребителски акаунти” е включена и една много рядко срещана възможност за настройка – възможността да се

126

добавят атрибути. Това се извършва чрез формата показана на следващата фигура.

Фиг. 88. Добавяне на атрибути към профила

Причината поради която разширяването на характеристиките на модулите е рядко срещано свойство, е че това изиска добавяне на полета в някоя от таблиците на базата данни.

12.4. Модули предназначени за крайните потребители

Като пример ще разгледаме един много

прост модул предназначен за крайните потребители - модулът “Книга за гости”.

А. Потребителски интерфейс.

127

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

Фиг. 89. “Книга за гости”

128

Потребителският интерфейс на “Книгата за гости” включва още една страница предназначена само за администратора на сайта (недостъпна за крайните потребители). В тази страница записите от “Книгата за гости” се извеждат в грид, с възможност за редактиране и изтриване на редове.

Фиг. 90. “Книга за гости” с възможност за редактиране от

администратора

Б. Субмодул за настройка Субмодулът за настройка на “Книгата за

гости” е уеб страница представя множество от

129

параметри, чрез които може да се модифицира страницата с потребителския интерфейс.

Могат да се изберат част от предвидените входни полета (но не могат да се добавят нови).

Друга група от параметри, показани на следваща фигура, позволява да се промени разположението на полетата в таблицата с наличните съобщения. Забележете, че се използват т.н. “тагове за заместване” които служат да се обозначат местата в реда на таблицата, където трябва да се изведат определени елементи на съобщението.

130

Фиг. 91. Възможности за редактиране

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

131

Фиг. 92. Два начина за разглеждане на “Книгата за гости”

132

12.5. Добавяне на страници към сайта. Главно меню

В началото на разработката на един сайт

с DotNetNuke, има празна начална страница Home показана на фигурата. Различават се петте панела на страницата: горен, ляв, централен, десен и долен.

Фиг. 93. Начало на разработка на сайт

Инструментите за работа със страниците са разположени в контролния панел, в горната част на екрана.

Фиг. 94. Инструменти за работа със страниците

Функциите за работа със страниците на сайта са следните:

- Add - добавяне на нова страница, - Settings - редактиране на

характеристиките на страницата - Delete – изтриване на страница - Copy – копиране на страница на друго

място в рамките на същия сайт

133

- Export - копира страница в посочена директория

- Import – добавя към сайта съществуваща страница от посочена директория

Чрез Settings извикваме панел за настройка на страницата. На фигурата е показана само част от формата за настройка на страницата, която включва три параметъра, които ще разгледаме:

- Parent Page – параметърът указва дали дадена страница е подчинена на някаква страница. (родителска страница) Тази йерархична организация на страниците се използва при изграждане на главното менюто на сайта.

- Include in Menu – параметърът указва дали името на страницата да се включи като елемент на главното меню на сайта. Менюто представя имената на страниците в йерархията в която са дефинирани.

- Permissions

Фиг. 95. Дефиниране на меню

Добавяме три нови страници с параметри:

134

Include_in_menu = true

Permisions > all_Users.View_Page = true Указваме следната йерархична

съподчиненост на страниците:

Home [Parent Page = None Specified] -Home-child1 [Parent Page = Home] -Home-child2 [Parent Page = Home]

Art [Parent Page = None Specified] Главното меню на сайта при изпълнение

има вида

Фиг. 96. Изглед на менюто след добавяне на страници

По този начин имаме набор от четири страници, и достъпът до тях е осигурен чрез главното меню.

Сега ще разгледаме начина по който в страниците се влагат модули от вида “TEXT/HTML” - контейнер за текст с форматиращи характеристики в формат HTML.

Функционалната група за добавяне на модули се намира в контролния панел (до групата с функциите за работа със страниците).

135

Фиг. 97. Функционалната група за добавяне на модули

Указват се следните данни за модула който ще влагаме:

- Module - избира се модул от списък с наличните модули - в случая избираме “TEXT/HTML”

- Title - заглавие с което ще е представен модула в страницата

- Visibility – възможни са два режима на видимост на модула: (а) еднаква с видимостта на страницата или (б) само за редактора на страницата – така се влагат модули които имат помощна функция и нямат интерфейс с крайните потребители

- Pane – указва се в коя от петте панела на страницата да се вложи модула: горен, ляв, централен (панел за съдържанието), десен или долен.

- Insert – начина на разполагане на модула спрямо другите налични модули в същия панел; опциите са две: (а) top – над другите, и (б) bottom – под другите.

- Align – начина на подравняване – ляво, центрирано, или дясно.

Задаваме име на модула “My text”, След като натиснем бутона “add” , модулът галерия се добавя в централния панел.

136

Фиг. 98. Задаване име на модула “My text”,

За да редактираме съдържанието на модула, кликваме върху “Edit Text” . Отваря се форма за редактиране на текста, която работи по начин аналогичен с HTML редактор MS Visual Studio в режим Design.

Фиг. 99. Форма за редактиране на текста

Има възможност за превключване на редактора в режим Source. Но тук, за разлика от MS Visual Studio, няма никакъв синтактичен контрол при въвеждането на кода, така че писането на код е рисковано.

137

Фиг. 100. Въвеждане на код

След потвърждаване на направените промени с “Update” , страницата има следния вид в режим на изпълнение.

Сега ще премахнем заглавието на модула “My text” което в случая е излишно, и ще преместим този модул в горния панел на страницата.

От контекстното меню на модула избираме опцията настройки (Settings), и изтриваме заглавието.

Местене и премахване на модул се извършва чрез контекстното меню за съответния модул.

138

Фиг. 101. Местене и премахване на модул

За опцията преместване се предлага подменю указващо в кой панел на страницата да се премести модула. Преместваме модулът с текста в горния панел.

При изпълнение страницата изглежда по следния начин:

Фиг. 102. Готов вид на страницата

139

12.6. Сфера на приложение на CMS технологията

Изграждането на сайт по технологията

на CMS се състои главно в извършването на следните дейности:

1) избор на модули, които да реализират функции нужни за постигане на целите на сайта;

2) разполагане на модулите в страниците на сайта;

3) настройка на избраните модули, в съответствие с конкретните изисквания;

4) координация на работата на модулите.

За влагането на модулите в страници се използва същата функционалната група която използвахме за влагане на модул “TEXT/HTML”. Единствената разлика е че трябва да се избере подходящия за целите на сайта модул.

Изграждането на сайтове по тази технология е много по-просто, в сравнение с разработването на обикновено ASP.NET приложение c Visual Studio, и разбираем за хора които не са професионални програмисти. Въпреки това, сферата на приложение на CMS технологията е силно ограничена. Ще разгледаме два основни фактора, водещи до това ограничение.

Първият фактор е, че един модул със дадена функционалност за крайния потребител, се разработват многократно по-трудно, отколкото обикновено ASP.NET приложение, което реализира същата

140

функционалност. Времето за създаването на една “книга за гости” е приблизително 2 часа за един програмист, докато създаването на един модул “Книга за гости” може да отнеме няколко седмици. Не е рентабилно изготвянето модули които да се прилагат еднократно, за определен сайт със строго специфична функционалност. Производителите на софтуер създават предимно модули, които имат многобройни потенциални потребители, и респективно, могат да се продават на относително ниски цени. Примерно, разгледаният по-горе модул “Книга за гости” струва 10 долара (http://marketplace.dotnetnuke.com/p-30-guestbook-pro-41.aspx).

Фирмата Biz Modules (www.bizmodules.net) предлага ефектни модули за галерии от фотоснимки и филми, реализирани чрез Adobe Flash, на цени под 100 долара.

Фиг. 103. Готови модули

141

Респективно, CMS технологията е рентабилна за сайтове състоящи се от

- текстове и илюстрации, които могат да се поставят като съдържание на TEXT/HTML модули, и

- често срещани функции като: “книга за гости”, “галерия” от снимки или филми, “форум” и други, които са реализирани чрез модули с цени приемливи за разработващия сайта.

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

Най-удачно приложение CMS технологията намира в обществения сектор, за изграждане на публични информационни сайтове. Пример за много успешно приложение на технологията е порталът на обществените училищата в Омаха, САЩ (http://www.ops.org). Той включва сайтове на почти всички начални и средни училища.

142

Фиг. 104. Приложение CMS технологията

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

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

143

впечатлението е за уникалност на всеки сайт. На следващите две фигури са показани главните страници на два училищни сайта.

Фиг. 105. Главните страници на два училищни сайта, направени с CMS технологията

144

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

145

13. Заключение В настоящия учебник разгледахме

различните CASE технологии за автоматизирано изграждане на информационни системи.

В първата час на учебника разгледахме технологиите основани на приложение на UML.

Разгледани бяха типовете диаграми (графични модели), както и предимствата и недостатъците при използването на UML за проектиране на информационни системи и автоматизация на програмирането. Някои от основите изводи са:

Използването на CASE инструменти, базирани на UML, спомага съществено за повишаване на качеството на програмния код.

UML се налага като международен стандарт и спомага за обмен на информация и опит между софтуерни специалисти от различни екипи.

UML осигурява разнообразие от нотации за представянето на много аспекти от софтуерните системи.

При проектирането на системите UML диаграмите позволяват да се опишат прецизно структурните и функционалните аспекти на системите, макар че те само допълват, а не заменят описателните документи.

Използването на CASE инструменти прави възможно създаването на много по-добра документация на програмния код. Това води до по-бързо и по-

146

ефективно извършване на определени изменения във вече функционираща система.

CASE дават възможност на потребителя да вземе по-голямо участие в процеса.

Цените на някои CASE инструменти са все още твърде високи. Но на пазара има фирми, които предлагат CASE инструменти с цени, които са приемливи и за малки фирми с ограничени бюджети.

Вторият клас CASE инструменти които разгледахме са средствата за визуално и декларативно програмиране. Разгледахме пример, как се използват тези средства в две развойни среди - Visual Studio 2008 и NetBeans IDE. Показахме, че две развойни среди са равносилни, т.е. позволяват създаването на приложения които са сходни както във визуален, така и във функционален аспект.

Една от най-характерните черти в развитието на съвременните средства за визуално и декларативно програмиране е тенденцията към унификация, макар че липсват международни стандарти за този клас технологични инструменти.

Третият клас от CASE инструменти, който разгледахме - средствата за компютърно подпомагане на кодирането също бележат тенденция към уеднаквяване, независимо от програмния език, към който са насочени.

Последният разгледан клас инструменти - CMS технологията, се използват за бързо създаване на уеб страници дори и от

147

неспециалисти. Дейностите по изграждането на сайта при използване на технологията CMS се свеждат до избор на готови модули, разполагането им върху страниците на сайта, настройка на избраните модули и координация на работата помежду им.

148

ПРИЛОЖЕНИЕ 1

Ресурси, достъпни в интернет

Visual Studio 2008 Express Edition

Продуктът е достъпен безплатно на адрес http://www.microsoft.com/express/download/

Express Edition, за разлика от Professional edition, е разделен на няколко самостоятелно обособени модула за инсталиране. За да изпълните примерите, трябва да инсталирате модулите:

Visual Basic 2008 Express Edition

Visual Web Developer 2008 Express Edition

NetBeans 6.5 – отворен код на NetBeans community съвместно с Sun Microsystems – за езика Java (за J2ЕЕ 1.4 и Java EE 5)

DotNetNuke http://demo.dotnetnuke.com/ Unified Modeling Language (UML)

http://www.uml.org/ Официална страница на UML. UML Specification Page

http://www.jeckle.de/uml_spec.htm Страница с препратки към официалните

документи за спецификация на UML 1.x и 2.0. UML Resources Center

http://umlcenter.visual-paradigm.com/ Сайтът UML Resources Center съдържа

документация за UML 1.х и 2.0 във вид на PDF файлове и кратки учебни филми за всеки тип диаграми.

Enterprise Architect User Guide http://www.sparxsystems.com.au/EAUserGuide/index.html

149

Ръководството за потребителя на продукта Enterprise Architect (на фирмата Sparks), което съдържа пълно описание на всички UML типове диаграми с препратки към официалната спецификация на OMG.

UML Tools (Drawing & CASE) http://www.jeckle.de/umltools.html

Сайтът съдържа информация за около 100 CASE продукта. В табличен вид е показано за всеки продукт: кои типове диаграми поддържа и код на кои езици за програмиране генерира.

150

ПРИЛОЖЕНИЕ 2

Речник на използваните термини

CASE Computer-aided software engineering

(компютърно-подпомагано софтуерно инже-нерство) – Специализирани програми за авто-матизация на програмирането и поддръжката на софтуера.

CMS - Content management system - Системи за управление на съдържанието, означават се най-често само абревиатурата CMS.

DotNetNuke – система за управление на съдържанието с отворен код, реализирана на Visual Basic за платформата ASP.NET.

GUI (Graphical User Interface) – Графичен потребителски интерфейс – Съвкупността от условни графични изображения, които се ви-зуализират на монитора (менюта, радио бутони, текстови области и т.н.), чрез които се осъществява взаимодействието между потребителя и софтуерната система.

ISO (International Standardization Organization) – Международна организация за стандарти.

OMG (Object Management Group) – Международна неправителствена организация за препоръчителни стандарти в областта на обектно-ориентираните софтуерни технологии.

UML (Unified Modeling Language) – Уни-фициран език за моделиране – графичен език за специфициране, конструиране и документиране на софтуерни системи.

151

Времеви диаграми (timing diagrams) – Тип диаграми в UML, които представят взаимодействията между обектите с детайлно отчитане на времевите интервали (сравни с диаграми на последователностите).

Диаграми на случаите на употреба (use case diagrams) – Тип диаграми в UML, които показват как потребителите взаимодействат със системата.

Диаграми на дейностите (activity diagrams) – Тип диаграми в UML, които представят логическите връзки и последователността на действията.

Диаграми на класовете (class diagrams) – Тип диаграми в UML, които представят свойства и методи на класовете.

Диаграми на комуникациите (communication diagrams) – Тип диаграми в UML, които представят взаимодействията между обекти, като се акцентира на информационните връзки (съобщенията) между обектите.

Диаграми на пакетите (package diagrams) – Тип диаграми в UML, които представят йерархична структура на частите на програмната система; най-често пакетите обхващат групи логически свързани класове.

Диаграми на последователностите (sequence diagrams) – Тип диаграми в UML, които представят взаимодействие между обекти с ударение върху последователностите (сравни с времевите диаграми).

Диаграми за преглед на взаимодействията (interaction overview diagrams) – Комбинация от диаграми на

152

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

Диаграми на разгръщане на системата (deployment diagrams) – Тип диаграми в UML, които представят физическите устройства, върху които се инсталират компонентите на една софтуерна система.

Диаграми на съставна структура (composite structure diagrams) – Тип диаграми в UML, които представят вътрешната структура на класовете.

Диаграми на състоянията (state machine diagrams) – Тип диаграми в UML, които представят през какви състояния преминава даден обект.

Компонентни диаграми (component diagrams) – Тип диаграми в UML, които представят структура и връзки на софтуерни компоненти, обособени в самостоятелни файлове.

Мета-модел (meta-model) – Формалното дефиниране или неформално описание на основните понятия, използвани в UML диаграмите.

Множественост (multiplicity) – Свойство на връзките между класовете. Означение за това: колко на брой обекта може да реализират дадена връзка. Използва се в диаграмите на класовете.

Нотация (notation) – Графичните елементи, които се използват в моделите; това е „графичният синтаксис” на езика за моделиране.

Обектни диаграми (object diagrams) – Тип диаграми в UML, които представят

153

обектите (инстанции на класове) в една система в даден момент.

Реверсивно софтуерно инженерство (reverse software engineering) – Дейност, при която се създава модел на системата въз основа на програмния код, наличната документация (но не във вид на UML диаграми) и фактическото функциониране на системата.

Структурен модел (structural model) – Модел на системата, който показва структурата и подструктурата на системата, използвайки обекти, атрибути, операции и връзки.

Структурни диаграми (structural diagrams) – Типове диаграми, които изразяват аспекти на структурния модел на системата.

Тригери (trigger events) – Събития, които инициират даден преход от едно състояние към друго на обект от даден програмен клас. Използват се в диаграми на състоянията.

Функционален модел (functional model) – Модел на системата, който показва функционалността на системата и измененията на системата във времето.

Функционални диаграми (functional diagrams) – Типове диаграми, които изразяват аспекти на функционалния модел на системата.

154

Използвана литература

[1] UML Specification Page http://www.jeckle.de/uml_spec.htm

[2] UML Resources Center http://umlcenter.visual-paradigm.com/

[3] Enterprise Architect User Guide http://www.sparxsystems.com.au/EAUserGuide/index.html

[4] Practical UML: A Hands-On Introduction for Developers http://dn.codegear.com/article/31863

[5] Rational Software Architect: Designing a software application by using models http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=/com.ibm.rsa.nav.doc/topics/trootdesignmodel.html

[6] UML Tools (Drawing & CASE) http://www.jeckle.de/umltools.html

[7] Unified Modeling Language (UML) http://en.wikipedia.org/wiki/Unified_Modeling_Language

[8] The Unified Modeling Language (UML)

http://www.matrice.co.uk/uml.asp

[9] Kostaras, John. Unified Modeling Language

Description and a methodology of use, 2000

155

[10] Unified Modeling Language (UML) Tutorial http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm

[11] Van Damme, Mario. Object Oriented CASE

Tools: Lost Opportunities and Future

Directions, 2006

http://www.developerdotstar.com/mag/articles/oo_c

ase.html

[12] Мартин Фаулър, UML основи,

СофтПрес, 2007

156

Ваня Лазарова CASE ТЕХНОЛОГИИ

Computer-aided Software Engineering Учебник за специалност „Бизнес информатика”

Редактор: Красимир Георгиев

Технически редактор: Георги Димитров Коректор: Елка Димитрова

Българска, първо издание

Формат: 108х84/32 Цена: 5,00 лв.

Издателство „Фльорир”

Печат: ПБ Верен, София ISBN: 978-954-410-004-9