Технология на проектирането

Слайд 1

СОФТУЕРНО
ИНЖЕНЕРСТВО

Слайд 2

ТЕХНОЛОГИЯ
НА ПРОЕКТИРАНЕТО

Слайд 3

ТЕХНОЛОГИЯ НА ПРОЕКТИРАНЕТО
Технологията на проектиране означава използване на определена формална система за описание на процесите в системата, набор от техники и средства за спазване на определен ред (дисциплина) на разработване на продукта.

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

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

Слайд 4

ПОДХОДИ ЗА ПРОЕКТИРАНЕ

Разграничават се два основни подхода към проектиране:
- Функционален подход;
- Обектноориентиран подход.

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

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

Слайд 5

ФУНКЦИОНАЛЕН ПОДХОД

Разграничават се два основни етапа на функционалното проектиране:
предварително (понякога наричано външно) проектиране;
детайлно (понякога наричано вътрешно) проектиране.

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

Слайд 6

ФУНКЦИОНАЛЕН ПОДХОД

При детайлното проектиране (component-level) софтуерната система се представя като йерархия от „черни" кутии, които трябва да се реализират като обособени програмни части, наречени модули.
Модулът е функционално обособен и стандартно оформен елемент, който е основна, самостоятелно разработвана, тествана и документирана единица. При първата стъпка се създава схема на структурата, описваща основните модули, потока на данните и потока на управление между тях. При втората стъпка се специфицират модулите. Всеки модул има име и четири основни атрибута:
— вход и изход;
— основна функция;
— механизъм за реализация на функцията;
— вътрешни данни.

Слайд 7

ОБЕКТНО-ОРИЕНТИРАН ПОДХОД

Основни понятия:

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

Слайд 8

ОБЕКТНО-ОРИЕНТИРАН ПОДХОД

Подклас – частен случай на клас.
Йерархия на класовете - подкласовете наследяват атрибутите и операциите на суперкласа, но могат да имат и специфични за тях атрибути и операции.
Капсулиране - подробностите на вътрешната реализация остават скрити; данните и операциите са обединени в едно именовано цяло — класа, което улеснява повторното му използване; връзките между „капсулираните" обекти са опростени, защото не зависят от вътрешните структури от данни.
Наследяване - всеки подклас придобива автоматично (наследява) всички атрибути и операции на съответния суперклас. Така се осигурява повторно използване на структурите данни и алгоритми.
Полиморфизъм - дава възможност различни операции да имат едно и също име. Така се осигурява настроеваемост и гъвкавост, защото с унифицирано извикване могат да се реализират специфични обработки

Слайд 9

ОБЕКТНО-ОРИЕНТИРАН ПОДХОД

Обектно-ориентираното проектиране се извършва на две нива, съответстващи на външното и детайлното проектиране при функционалния подход — проектиране на системата и проектиране на обектите.
При проектирането на системата се определя архитектурата. Създаденият модел се декомпозира на подсистеми, като се описва предназначението на всяка подсистема и връзките между тях. Проектират се още потребителският интерфейс и логическата организация на данните.
При проектирането на обектите за всеки обект се съставя интерфейсно описание и описание на реализацията. Интерфейсното (протоколно) описание определя всички съобщения, получавани от обекта, и съответните операции, които обектът извършва при получаване на съобщенията. Описанието на реализацията (implementation description) специфицира свързаните с обекта структури данни и алгоритмите за всяка операция.

Слайд 10

ОБЕКТНО-ОРИЕНТИРАН АНАЛИЗ

Целта на обектно ориентирания анализ (ООА) е създаването на модел, представящ статичните и динамични характеристики на класовете и взаимоотношенията между тях. Създадени са различни методи за ООА, използващи различни съвкупности от диаграми и означения.
Моделирането на системата помага на аналиста да опише функционалността на системата. Моделите се използват в процеса на комуникация с потребителите и останалите участници в екипа.
Различните модели представят системата под различна перспектива:
- Външна перспектива показваща контекста или обкръжението на системата;
- Поведенческа перспектива показваща поведението на системата;
- Структурна перспектива показваща архитектурата на данните в системата.

Слайд 11

ТИПОВЕ МОДЕЛИ

Моделирането е процес на изграждане на компютърно-базирани символни структури, които представляват абстрактно някаква част от обкръжаващата ни действителност.
Модел на данните – показва как данните се обработват на различните етапи.
Композиционен модел – показва как обектите са съставени от други обекти
Архитектурен модел – показва основните подсистеми.
Класификационен модел – показва как обектите имат общи характеристики
Модел на стимулите и реакциите – показва реакциите на системата на определени събития.
Модел на процесите - показва цялостния процес и процесите поддържани от системата.
Модел на поведението - служат за описание на общото поведение на системата

Слайд 12

УНИФИЦИРАН ЕЗИК ЗА МОДЕЛИРАНЕ

За стандартизирано описание на моделите в обектно ориентираното проектиране е създаден т. нар. Унифициран език за моделиране - Unified Modeling Language (UML).
Унифицираният език за моделиране се е наложил като утвърден стандарт за моделиране на софтуерни системи.
Езикът UML може да се използва за моделиране във всички фази на разработването и за всякакви софтуерни системи. Използването му се подпомага от инструментални средства (Microsoft Visio, IBM Rational Rose, Poseidon и др.), които изчертават диаграмите,
съхраняват информацията за всички модели
и представянията им, осигуряват многопотребителска
работа и дори могат да генерират автоматично код.

Слайд 13

УНИФИЦИРАН ЕЗИК ЗА МОДЕЛИРАНЕ

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

Deployment View
Implementation View
Process View
Design View
Use Case View
Функционалност
Производителност
Скалируемост
Производство
Поведение
Сглобяване на системата
Конфигурационен
мениджмънт.
Топология на системата
Разпределение
Доставка и инсталиране
Логическо представяне
Физическо представяне

Слайд 14

USE-CASE VIEW

Use Case aнализът е техника за описание на бизнес процес от гледна точка на потребителя на системата.
Обхваща поведението на системата както тя изглежда за потребителите, аналитиците и тестерите.
Специфицира въздействията, които оформят архитектурата.
Статичните аспекти се представят от use-case диаграми.
Динамичните аспекти се представят в interaction, statechart (state machine), and activity диаграми.

Слайд 15

DESIGN VIEW

Обхваща класовете, интерфейсите и взаимодействията.
Поддържа функционалните изисквания на системата.
Статичните аспекти се представят от class and object диаграмите.
Динамичните аспекти се представят в interaction, statechart, and activity диаграми.

Слайд 16

PROCESS VIEW

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

Слайд 17

IMPLEMENTATION VIEW

Обхваща компонентите и файловете използвани за сглобяване и пускане в експлоатация на реалната система.
Адресиран към конфигурационния мениджмънт.
Статичните аспекти се представят от component диаграми.
Динамичните аспекти се представят в interaction, statechart и activity диаграми.

Слайд 18

DEPLOYMENT VIEW

Обхваща възлите, които формират хардуерната топология на системата.
Адресиран към разпространение, доставка и инсталиране.
Статичните аспекти се представят от deployment диаграми.
Динамичните аспекти се представят в interaction, statechart и activity диаграми.

Слайд 19

ВИДОВЕ UML ДИАГРАМИ

Слайд 20

ВИДОВЕ UML ДИАГРАМИ

Диаграма на случаи на употреба (Use-case diagram) - Описват поведението на системата от гледна точка на потребителя. Представят начина на взаимодействие между потребител и система.
Клас диаграмa (Class diagram) - Описват класовете от обекти (атрибути и методи) и връзките между тях (асоциации, наследяване, ...).
Диаграмa на последователност (Sequence diagram) - Описват схематично взаимодействието между потребителите и системата. Отделните действия са подредени във времето - последователно.
Диаграма на дейност (Activity diagram) - Описват потока на работните процеси (workflow). Построяват се с помощта на блок-схеми.

Слайд 21

ВИДОВЕ UML ДИАГРАМИ

Диаграма на комуникация (Communication diagram) - Описва взаимодействията между обек

Регистрирайте се за пълен достъп