Схема BG051PO001-4.3.05 „Развитие на професионалното образование и обучение в сътрудничество с работодателите” Договор: BG051PO001-4.3.05 – 0022 Име на проект: „Образователни паркове за развитие на професионално знание и компетенции в областта на...
О
ПЕРАТИВНА
ПРОГРАМА
„РАЗВИТИЕ НА ЧОВЕШКИТЕ РЕСУРСИ” 2007-2013
МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА
Схема BG051PO001-4.3.05 „Развитие на професионалното образование и обучение в сътрудничество с работодателите”
Инвестира във вашето бъдеще!
Договор: BG051PO001-4.3.05 – 0022
Име на проект: „Образователни паркове за развитие на професионално знание и компетенции в областта на компютърните технологии и системи в колаборация с IT сектора“
Бенефициент:
Професионална гимназия по компютърни
технологии и системи –
гр. Правец
ДЕЙНОСТ 6.
Разработване
на електронно съдържание за специализираните
професионални курсове,
заложени за професионално обучение в
4
образователни парка
Отчетен
период: 01.03.2014 г. – 31.03.2014 г.
ДИСЦИПЛИНА: ТЕХНОЛОГИЯ НА ПРОГРАМИРАНЕТО
Тема 2. Жизнен цикъл на програмна система. Модели на изпълнение на жизнения цикъл. Създай и фиксирай (build and fix model). Водопад (waterfall model). Бърз прототип (rapid prototyping model). Спирала (spiral model)
От гледна точка на концепцията за преобразуване на данни (информация) от едно представяне в друго жизненият цикъл на една програмна система от идеята за нейното създаване през реализацията и експлоатацията и изхвърлянето й от употреба се описва със следните етапи [32]:
1. Дефиниране (специфициране) на проблем за решаване;
2. Изготвяне на задание;
3. Проектиране;
4. Програмиране;
5. Тестуване и настройка;
6. Демонстрация и предаване на клиента (краен потребител);
7. Експлоатация и съпровождане.
Създаването на програмно осигуряване се описва като последователност от процеси за преобразуване на данни, започващи от описанието (спецификацията) на задачата и завършващи с работоспособна програма (инструкции за компютър) за решаването на задачата. Видно е, че програмирането е само етап при решаването на задачата, а програмното осигуряване се явява съвкупност от информационни елементи (данни и команди), описващи решението на проблема.
Постановката с етапи в жизнения цикъл позволява да се посочат източниците (причините) за грешките в ПО. Приема се, че създаването на ПО е съвкупност от процеси на транслация (трансформация) на данни от едно представяне в друго. Става дума за превод на първоначално формулирана задача в различни междинни решения до получаването на програма като набор машинни команди. Тогава причините за грешките, които се локализират в окончателния продукт се дължат на непълен и/или неточен превод на данни от едно междинно представяне в друго [17]. Ето защо грешките не винаги са вътрешно присъщи на програмите. Причините за грешките могат да се формулират като:
1. Неточности при преход от описание на проблема към формулиране на задание;
2. Неточности при преход от задание към изготвяне на проект;
3. Неточности при преход от готов проект към реална програмна система.
Жизненият цикъл на програмните системи може да бъде формулиран и в по-кратък вид [46] като последователност от следните етапи:
1. Системен анализ (Systems Analysis);
2. Системно проектиране (Systems Design);
3. Системна реализация (Systems Implementation);
4. Ситемна поддръжка (Systems Support).
Системният анализ е началният етап от жизнения цикъл. Той включва изучаване на текущото състояние на проблема, определяне на специфични потребности и изисквания, начална оценка на алтернативни решения. Този етап завършва с изготвяне на задание за проектиране, което съдържа уточнените изисквания на потребителя към системата.
Системното проектиране завършва със спецификация за реализация. Тази спецификация съдържа общо и детайлно описание на компютърното решение, избрано при анализа. Формулираните спецификации се дават на програмистите за реализация.
Системната реализация включва създаването на работеща програмна система. Програми се пишат, тестуват и настройват. Бъдещите потребители се обучават за работа с новата програмна система.
Ситемната поддръжка включва експлоатация и съпровождане след внедряване на системата. Възможно е чрез обратна връзка с програмистите да се репрограмират отделни модули за подобряване характеристиките на системата. Допуска се този етап да завърши с формулиране на изисквания за разработка на нова система, с което цикълът анализ, проектиране, реализация и поддръжка се затваря.
Друга трактовка за процеса на проектиране, разработка и реализация на един програмен продукт се дава в [48], където жизненият цикъл на програмните системи се формулира като последователност от следните фази:
1. Формулиране на изисквания (Requirements phase) - 3%;
2. Описание на проблема (Specification phase) - 4%;
3. Планиране (Planning phase) - 2%;
4. Проектиране (Design phase)-6%;
5. Реализация (Implementation phase) - 12%;
6. Интегриране (Integration phase) - 6%;
7. Поддържане/съпровождане (Maintenance phase) - 67%.
Относителният дял на всяка една фаза е представен в проценти.
Цел на фаза формулиране на изисквания е в диалог (интервю) с потребителя да се определят възможно най-точно неговите потребности - от каква програмна система се нуждае той. Фазата се нарича още системен анализ.
Целта на фаза описание на проблема е след определяне на потребностите да се създаде документ, който описва проблема и точно отразява какво следва да прави програмният продукт.
Целта на фаза планиране е оценка на необходимото време и ресурси за изпълнение на проекта - каква продължителност, колко проектанти и програмисти, какви разходи ще изисква проектът.
Целта на фаза проектиране е следваща детайлизация. Ако във фаза описание се казва какво трябва да прави продуктът, сега при проектирането се създава документ, който предписва как продуктът ще постигне целта си. Продуктът се разбива на съставни компоненти, всеки от които се проектира.
Целта на фаза реализация е програмиране на продукта. Изборът на инструментален програмен език се фиксира в документа за описание на проблема. Всеки модул се кодира и тестува.
Целта на фаза интегриране е свързване на отделните модули в завършен продукт. Тази фаза завършва с успешно провеждане на тест за приемане, с който клиентът потвърждава, че продуктът отговаря на изискванията в документа за описание.
Целта на фаза поддържане/съпровождане е отразяване на промени в продукта, след като е предаден на потребителя. Промените могат да се предизвикват от необходимостта да се отстранят възникнали грешки (bugs, corrective maintenance) или да се добавят нови функционални възможности към досегашните, с които разполага продуктът (enhancement maintenance).
От практиката са известни следните модели на изпълнение на жизнения цикъл на един програмен продукт с неговите седем фази [48]:
1. Създай и фиксирай (Build and Fix model). Продуктът се създава и предава на клиента без да се провеждат фази описание на проблема, планиране и проектиране. Клиентът посочва какви евентуални промени да се направят. След извършване на промените продуктът се предоставя на клиента. Този процес продължава, докато изискванията на клиента се удовлетворят. Моделът е приложим за малки по обем проекти като студентски задачи и учебни демопримери.
2. Водопад (Waterfall model). Този модел се нарича още лавинообразен или каскаден [50]. Последователно се изпълняват фазите от жизнения цикъл. Резултатът от всяка фаза се подлага на проверка за валидност (verify and test) и само след положителен резултат от проверката се пристъпва напред към следваща фаза. Особено внимание се отделя на диалога (интервюто) с клиента за получаване на необходимата информация за определяне на изискванията и формулиране на документа за описание на проблема. Предимството на модела е наличието на документация, съпътстваща всяка фаза. Недостатъкът на модела е, че по време на отделните фази клиентът не разполага с работеща макар и неокончателна версия на продукта, а разполага само с документация, от която слабо се информира за потенциалните възможности на разработвания продукт. Така клиентът не може да получи реална визуална представа за продукта преди предоставянето му в крайната фаза на жизнения цикъл.
3. Бърз прототип (Rapid Prototyping model). При този модел първата фаза за определяне на изискванията освен с данни за съставяне на документ за описание на проблема, завършва и с предварителна груба и примитивна реализация на продукта, наречена бърз прототип (rapid prototype). Клиентът получава възможност за визулана представа относно бъдещия продукт и реална оценка на функционалните му възможности. Така той преценява дали се удовлетворяват или не съответните изисквания. Клиентът експериментира с прототипа и прави забележки, които се отразяват непосредствено в прототипа. Този процес трае, докато клиентът бъде удовлетворен. Едва сега се създава описанието на проблема, който става спецификация за реализация на продукта.
4. Спирала (Spiral model). Основно внимание се отделя за оценка на рисковете, свързани с реализацията на продукта и извършване на действия, които разрешават проблемите и водят до минимизиране на рисковете. Възможни са различни рискове. Например опасението, че крайният продукт няма да удовлетвори изискванията на клиента. Удачно решение за разрешаване на този риск е да се създаде и предостави своевремнно на клиента работещ прототип на бъдещия продукт. Друг възможен риск се крие в опасението, че разходите за реализация на продукта няма да се възстановят.Удачно решение за разрешаване на този риск е да се провежда преди началото на всяка нова фаза прецизен икономически анализ и по-нататъшната реализация на продукта да продължава само след положителна икономическа прогноза. Изобщо анализ на възможните рискове се провежда преди всяка фаза от реализацията на проекта. Две условия обуславят прилагане на спирален модел съгласно [49]. Наличие на голям по обем проект, както и изискването клиент и разработчик на проекта да са от една организация.
Три категории специалисти са ангажирани при създаването на една програмна система. Те могат да бъдат групирани така:
1. Възложител, краен потребител (client, end user);
2. Проектант (systems analyst, systems designer, systems consultant, management consultant, operations analyst, information analyst, data analyst, business analyst, solution designer);
Програмист (developer, applications programmer, systems programmer). Примерно разпределение на участниците в жизнения цикъл на програмната система по етапи с показано в табл. 4.1.
Програмистите и проектантите са специалисти с различна квалификация.
Какви са изискванията към програмиста? Той трябва да владее програмен език или програмни езици, конкретна операционна система и набор системни помощни програми.
Каква квалификация е нужна на проектанта? Наред с уменията на квалифициран програмист той трябва да бъде с много богата професионална култура. Необходими са познания по принципи и системи за работа с бази данни, комуникации на данни, микрокомпютри, софтуер за компютри -програмни езици и операционни системи, машинна графика, сигурност на данните, изкуствен интелект, експертни системи и др. Проектантът трябва да бъде комуникативен. Много важно е да бъдат разбрани и правилно формулирани изискванията на потребителя, а това зависи от умението на потребителя да общува.
В [17,48] са описани различни схеми за обединяване на специалистите, работещи върху реализацията на програмен проект в колективи:
1. Бригада на водещия програмист (chief programmer team). Това е екип с главен програмист и редови програмисти.
2. Екип с двама ръководители. Той включва главен програмист (team leader) и управител (team manager);
3. Екип с йерархична подчиненост на три нива. Тези нива включват ръководител на проект (project leader), един или няколко ръководители на екипи (team leader) и редови програмисти (programmer).
Тема 3. Определяне на етапите при разработка. Xxxx на формулиране на изискванията и описание на проблема.
Три етапа предшестват програмирането в жизнения цикъл на програмните системи. Тук се включват дефиниране на проблем за решаване, изготвяне на задание за проект и проектиране. Тези три етапа приключват със завършен проект за програмиране. Ще представим основните процеси и дейности, които се изпълняват при проектирането на голяма програмна система [17].
1. Изисквания. Формулирането на изискванията описва очакванията на крайния потребител от готовия програмен продукт.
2. Цели. Целите определят какви задачи за решаване трябва да се поставят, за да се удовлетворят изискванията на потребителя от x. X.
3. Предварителен външен проект. Формата на взаимодействие (диалог) с потребителя се изгражда в най-общ вид без подробности.
4. Детайлен външен проект. Уточняват се всички подробности на взаимодействието с потребителя.
5. Архитектура (фасада) на програмната система. Фиксира се множеството програми, изграждащи програмната система.
6. Всички структури от данни за работа на програмната система се проектират и описват.
7. Структура на отделна програма. Проектира се структурата на всяка една програма от общото множество по т. 5. Специално внимание се отделя на дейността за избор на алгоритъм.
8. Логика на модули. Проектира се логиката на отделните модули, ' изграждащи отделна програма по т. 7.
Изброената поредица от действия е идейна и не следва да се третира като задължителен канон. Възможно е някое действие да липсва: например ако програмната система не работи с външни данни или структурата й е от единствен програмен модул. Обратно, възможно е определено действие да се натовари с повече от описаните дейности: например изборът на инструментален програмен език е дейност, която може и следва да се включи на различни места в горната схема - т. З, 7 или 8.
Изборът на най-добър алгоритъм е важен фактор за получаване на ефективна и коректна програмна система. Известно е, че за решаване на определен проблем като правило са възможни множество алгоритмични решения. Недобра практика е при проектирането да се избере първият дошъл на ум алгоритъм, който може би не винаги е най-доброто възможно решение. Поуката и за проектанти, и за програмисти е, че един час повече, използван при проектиране за избор на удачен алгоритъм, може да спести много часове за програмиране, тестуване и настройка. Естествено е да се прави анализ на временната и пространствената сложност на възможните алтернативи при избора на алгоритъм.
Недостатъците, които се проявяват на етап изготвяне на задание, и необходимостта от систематичност при провеждането на етап проектиране са наложили развитието на различни методи и техники за описание на заданието и формулиране на резултатите от процеса на проектиране:
Словесен подход. Средството за проектиране се нарича обикновен естествен език. Касае се за прилагане на ограничен, структуриран естествен език, наричан още псевдоезик, който се комбинира с традиционни синтактични изразни средства на програмните езици от високо ниво като оператори за цикъл и разклонение. Така се получава хибрид, който след това се уточнява и прецизира във формата на конкретна програма. Приложение на този подход може да се види и в книгата на Xxxxxxxxx/Xxxxxxx „The C Programming Language" [37]. Проектирането и реализацията на програма, филтрираща най-дългия текстов ред от входния поток, въведен от клавиатурата, се описва в т. 4.1. Разновидност на словесния метод с ориентация към обектно ориентираното проектиране и програмиране е дадена от R. Xxxxxx в статията „Program Design by Informal English Descriptions" (Comm of the ACM, vol 26, no 11). Предлага се описанието на проблема за решаване да се направи в изречение на естествен език. След това съществителните имена се маркират като кандидати за означаване на обекти и/или шаблони на класове, а глаголите се маркират като кандидати, с които се именуват методите на избраните класове. Например от изречението „Стекътсъхранява и извежда данни." не е трудно да се състави описание на клас стек с два метода за съхранение на данни в стек и извеждане на данни от стек.
//
class Stack
{
void push(int ..) // метод за съхранение (запис) на данни в стек
{ - }
int pop() //
метод за извеждане (четене) на данни от
стек
{ ... }
};
//
Схеми на потока данни (data flow diagrams DFD). За разлика от процедурните блоксхеми, схемите на потока данни не показват как се предава управлението при изпълнение на една програма. Те не задават проверки на условия и циклични обработки. Тези схеми показват само потока на данните (data flow), които се обработват - откъде идват, къде се съхраняват, къде се извеждат резултати, кои са процесите, обработващи данните. Работи се с физически схеми на потока данни (physical DFD), които се отнасят до физическата обработка на данните и логически схеми на потока данни (logical DFD), които третират логическата обработка на данните.
Йерархични диаграми. Съставя се йерархична структурна и функционална диаграма (visual table of contents) за проектираната програмна система. Значими компоненти (функции) от системата се маркират. За всяка от означените функции се съставя диаграма на обработките по класическия модел на изчислителен процес (Input, Process, Output). По тази причина диаграмите са известни като IPO-схеми. С тях се описват функционалните изисквания на потребителя и те му дават нагледна представа за бъдещата програмна система без да съдържат описания на конкретни структури от данни или първични текстове на конкретен програмен език.
Таблици на решение (Decision Tables). Те са средство за описание на даден проблем, което позволява систематична формулировка на всички възможни варианти на входни условия във формата на правила. За всяко от записаните правила се задава адекватна потребителска реакция, наречена действие. Таблиците на решение са средство за общуване между проектант, краен потребител и програмист. Съставят се от проектанта. Те са информативни за потребителя и служат като отправна точка за програмиста. Подробно таблици на решение са описани в [28].
Блоксхеми (flowcharts). Ще поясним блоксхемите като метод с приложение в проектирането. Трябва да се знае, че те са средство, приложимо както в проектирането (процесът завършва с продукт блоксхема), така и в програмирането (процесът започва с продукт готова блоксхема). За разлика от схемите на потока данни, блоксхемите показват потока на управлението. Те описват какви действия се извършват в зависимост от едни или други условия при изпълнението на една програма с конкретен набор входни данни. В този смисъл като друго означение на блоксхема може да се ползва и терминът control flow diagram (CFD).
От гледна точка на практиката всяка блоксхема се състои от следните конструктивни елементи:
1. Блокдействие с един вход и един изход;
2. Блокразклонение с един вход и два или повече изхода;
3. Елемент начало с един изход;
4. Елемент край с един вход;
5. Елемент сливане с два или повече входа и един изход.
От гледна точка на теорията блоксхемата е абстрактна структура -насочен (ориентиран) ацикличен граф, който указва реда на изпълнение на операторите в една програма.
Всеки оператор от програмата се представя като възел в графа. Всяко възможно предаване на управлението се представя като дъга (линия, свързваща два възела) в графа. Ако един възел има една входяща и една изходяща дъга, той описва оператор за действие от програмата и се нарича функционален възел. Ако един възел има една входяща и две или повече изходящи дъги, той описва управляащ оператор от програмата и се нарича предикатен възел. Третият възможен тип възли има две или повече входящи дъги и една изходяща дъга и се нарича възел за сливане. Възлите за сливане не влияят по никакъв начин на обработваните данни. Управляващата структура на всяка една блоксхема се конституира чрез формиране на комбинации от функционални възли, предикатни възли и възли за сливане.
Изпълнение на една блоксхема се нарича последователността от действията, написани във функционалните блокове, през които минава пътят (управлението). Дървото на изпълненията представя множеството от възможните последователности от действия през всички възможни клонове на блоксхемата [15].
CRC-карти. Това е техника с приложение в обектно ориентираното проектиране. Съкращението означава Class (Клас), Responsibilities (Отговорности, Действия), Collaborators (Сътрудници). За всеки клас от проблемната област се строи структура по подобие на фиг. 4.1.
Отляво в колона се изброяват отговорностите на класа. Това са действията (един или няколко метода), които проектираният клас ще изпълнява. Отдясно срещу всяка отговорност се изброяват класове (обекти), които ще се активират при изпълнение на съответното действие. Това е начин за изясняване на връзките между класовете в общия модел. Ниска степен на обвързване (low coupling) между класовете е характерна за добрите обектно ориентирани модели [53]. Обратно, признак за некачествено създаден обектно ориентиран модел в съответната предметна област е случаят на CRC-карта с отговорност, на която съответстват много сътрудници.
Изпълнението на етапите проектиране, а в последствие и програмиране се реализира чрез спазването на определена техника (методика). Възможни са следните подходи:
Тотално проектиране/програмиране. Тук няма никакава специална идея или замисъл. Целият проект се замисля като един модул, който се свежда до работеща програма. Намира ограничено приложение за малки по обем учебни и/или демонстрационни програми.
Модулно проектиране/програмиране. Проектите/програмите се разделят на логически части и последователно се проектират/програмират. Предимството се състои в разделянето на голям проект или програма на по-малки логически обососбени части, решаването на всяка от които е по-лека задача от решаването на проекта като цяло. Типични изисквания, които се поставят при обособяване на модулите, имат за цел да осигурят:
1. Независимост. Всеки модул е самостоятелна единица и не зависи от останалите. Може да се замени с друг без това да влияе на останалите.
2. Приемлив размер. В [14] се цитират данни от компютърни компании и софтуерни фирми, които налагат различни практически нормативи. Модулът е част от програма, който се пише, тестува и настройва за 1 месец. Модулът съдържа не повече от 100 оператора на програмен език от високо ниво.
Възходящо (bottom-up) проектиране/програмиране. Отделните модули на дадена програмна система се разработват (проектират/програмират) отначало отделно и след това се обединяват в единно цяло. Основният недостатък на този подход се крие във факта, че грешки в проектирането често се откриват едва при настройката (обединяването) на модулите в едно цяло, след като много модули са написани и се оказват безполезни.
Низходящо (top-down) проектиране/програмиране Основната идея е в противовес на възходящото проектиране. Управляващите програми се съставят отначало (проектират, програмират, тестуват и настройват), а функционалните изпълнителни модули се добавят в процеса на разработката на цялата система. Обичайно низходящото проектиране започва с логическо проектиране. Така се обезпечава съгласуваност на работата между отделните програмни модули.
При възходящото проектиране програмните модули не се проверяват като съставна част на цялата система до края на разработаката им.
При низходящото проектиране програмните модули се проверяват веднага за съвместимост към системата. Ако те не са готови, тяхното място се заема от празни програмни единици (stubs).
Низходящата методика допуска ранното откриване и отстраняване на допуснати грешки при проектирането/програмирането. Това става в периода, когато програмите са все още при разработчика. Обратно, възходящата методика е предпоставка за откриването на грешките на по-късен етап при комплексната настройка на програмната система. Това е недостатък, защото разработчикът на конкретните модули е приключил работа и е възможно да работи по друг проект.
Описаните no-горе методи и техники за проектиране (словесен, схеми на потока данни, йерархични диаграми, таблици на решение, блоксхеми), както и методиките за тяхното провеждане (тотално, модулно, възходящо, низходящо проектиране/програмиране), произтичат от принципите на структурния анализ и проектиране на системи (SSAD - Structured Systems Analysis and Design) и са свързани със структурното програмиране. Еволюцията на структурното програмиране доведе до развитие на обектно ориентираното програмиране, а това наложи и нови тенденции в анализа и проектирането на програмни системи. Водещият принцип от структурния анализ и синтез на системи мислене чрез функции (Thinking in Functions) остава класически, но се счита остарял и неактуален. Той се измества от наложилия се съвременен притцип мислене чрез обекти (Thinking in Objects), който е валиден за обектно ориентирания анализ и синтез на системи. Развиха се множество методи за обектно ориентиран анализ, синтез, проектиране и програмиране на програмни системи. Най-известните от тях според [53] са:
1. Метод за обектно ориентирано проектиране OOD (Object Oriented Design) с автор Гр. Буч (Xxxxx Xxxxx);
2. Метод за обектно моделиране ОМТ (Object Modeling Technique) c автор Xx. Ръмбау (Xxxxx Xxxxxxxx);
3. Метод за обектно ориентирано софтуерно инженерство OOSE (Object Oriented Software Engineering) c автор X. Xxxxxxx (Xxxx Xxxxxxxx).
Тримата цитирани автори работят за фирмата Rational Software (http:// xxx.xxxxxxxx.xxx) от 1994-95 г. Там те обединяват усилия за разработка на унифициран метод за обектно ориентирано проектиране (Unified Method). B резултат се ражда езикът за описание и моделиране на обекно ориентирани системи, известен с абревиатурата UML (Unified Modeling Language). Най-характерното за този език е, че на проектанта се предоставя възможност в унифициран диаграмен вид (фиг. 4.2.) да изобрази класовете/обектите, с които се описва задачата за решаване.
Диаграмата за всеки клас/обект съдържа раздел наименование на класа, раздел елементи данни и раздел методи на класа. Всеки елемент или метод може да бъде предшестван от представка +, - или #. Така се описват квалификаторите за видимост public, private или protected. Атрибут за статично (static) обявяване на компонент се задава допълнително с $. Ако практическият проблем е достатъчно елементарен, той се описва само с диаграмата на един обект. Реалните проблеми се описват с множество взаимосвързани класове/ обекти. Проектирането продължава с изграждане на връзки между диаграмите на класовете/обектите. Обобщено връзките между класовете се наричат асоциация (association) и се означават с линия, която свързва диаграмите на класовете. Връзка от тип асоциация между клас А и клас Б е показана на фиг. 4.3.
Наследяването между базов и породен клас е връзка, която се нарича още връзка тип „е" („is a"). Като пример за наследяване са показани връзките между класовете Мраз, Хладилник и Домакински уред. Те са представени на фиг. 4.4. и се изговарят по следния начин. Мраз е марка (вид) хладилник. Хладилник е вид домакински уред.
Мраз е клас, който има свои характеристики, но наследява и характеристиките на класа Хладилник.
Хладилник е клас, който има свои характеристики, но наследява и характеристиките на класа Домакински уред.
Агрегацията е връзка от тип част - цяло, която се нарича още връзка тип „има" („has") или връзка тип „е част от" („is a part of). Този тип асоциация е илюстриран на фиг. 4.5 с пример за връзка между класовете Ястие и Хранителен продукт. Дадено ястие има (съдържа) хранителни продукти. Даден хранителен продукт е част от едно или повече ястия.
Този тип връзки имат и характеристика кардиналност (cardinality). Връзката се надписва в двата края с числа (стойности или диапазон от стойности), които показват броя обекти от съответния клас, които участват в асоциацията. Възможни стойности за означаване са:
1 - един обект;
* - неопределен брой обекти;
0..1 - нула или един обект;
0..* - нула или повече обекти;
1 ..* - един или повече обекти.
Обогатената връзка от тип агрегация с въведена кардиналност от двете страни е показана на фиг. 4.6. Тя съответства на следната схема. Едно или повече ястия съдържат три или повече хранителни продукта. Три или повече хранителни продукта са част от едно или повече ястия.
Следващата връзка се нарича композиция и е разновидност на агрегацията. При композицията цялото напълно притежава (strongly owns) своите компоненти [53]. Всички действия с обектите от целия клас (копиране, преместване, разрушаване) влекат същите действия, които се извършват над обектите, които го съставят. Обектите компоненти са притежание на точно един определен обект от класа цяло. Затова стойността, с която се означава връзката от страната на цялото, е 1. Примерът, който е показан на фиг. 4.7, описва връзка композиция между клас Жилищен блок и клас Апартамент.
Жилищен блок има (съдържа) апартаменти. Апартаментът е част от жилищен блок.
Не е възможно един конкретен апартамент да е част от няколко жилищни блока. Той принадлежи на точно един жилищен блок. По тази причина с отчитане на кардиналността описанта връзка композиция означава: Един жилищен блок (конкретен обект) има 17 апартамента.
Изготвил:….......
Xxxx Xxxxxx
11