Методи проектування програмного забезпечення
План заняття
Глава 1. Структурний підхід до проектування ПО
Глава 2. Об'єктно-орієнтований підхід до проектування ПО
Глава 3. Зв'язок структурного і об'єктно-орієнтованого підходів
Глава 1. Структурний підхід. Сутність структурного підходу …
Проблема складності великих систем …
Жоден розробник не в змозі зрозуміти всю систему в цілому.
Основні підходи до вирішення проблеми :
Гасло «Розділяй і володарюй».
Ієрархічна декомпозиція.
Проблема складності великих систем
Необхідно скласти правильну декомпозицію.
К-ть зв'язків між окремими підсистемами має бути мінімальною;
Зв'язність окремих частин усередині кожної підсистеми має бути максимальною;
Взаємодія між підсистемами:
кожна підсистема повинна інкапсулювати свій вміст (приховувати його від інших систем);
кожна підсистема повинна мати чітко певний інтерфейс з іншими підсистемами.
Структурний підхід до розробки ПО
функціонально-модульний(структурний) підхід - структура системи описується в термінах ієрархії її функцій і передачі інформації між окремими функціональними елементами.
Базові принципи структурного підходу:
принцип ієрархічного впорядкування - організація в деревовидні структури;
· принцип абстрагування - виділення істотних аспектів системи і відвернення від неістотних;
· принцип несуперечності - обгрунтованість і узгодженість елементів системи;
· принцип структуризації даних - дані мають бути структуровані і ієрархічно організовані.
Структурний підхід до розробки ПЗ.
Потрібні моделі, що описують функціональну структуру системи і відношення між даними.
Найбільш поширеними є :
DFD (Data Flow Diagrams) – діаграми потоків даних;
SADT (Structured Analysis and Design Technique – метод структурного аналізу і проектування) - моделі і відповідні функціональні діаграми;
ERD (Entity-Relationship Diagrams) – діаграми «сутність - зв'язок».
Загальні відомості
Функціональна модель SADT відображує функціональну структуру об'єкту, тобто дії і зв'язки між цими діями.
Елементи методу грунтуються на наступних концепціях:
графічне представлення блокового моделювання. Функція відображується у вигляді блоку, а інтерфейси входу-виходу дугами.
строгість і точність. Обмеження кількості блоків на кожному рівні декомпозиції (правило 3-6 блоків), зв'язність діаграм (номери блоків), унікальність міток, синтаксичні правила для графіки, розділення входів і управлінь.
Відділення організації від функції (виключення впливу адміністративної структури організації на функціональну модель).
Глава 1. Структурний підхід. Метод функціонального моделювання SADT…
Склад функціональної моделі …
Результатом використання методу SADT є модель, яка складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного.
Функція
А0
Вхід
Управління
Механізм
Вихід
Глава 1. Структурний підхід. Метод функционального моделирования SADT…
Состав функциональной модели.
Однією з найбільш важливих особливостей методу є поступове введення все більших рівнів деталізації створення діаграм, що відображують модель.
Загальний вид.
А0
А-0
Структура SADT-моделі. Декомпозиція діаграм
Детальніше представлення
А1
А2
А3
А4
А0
А41
А42
А43
А4
А421
А422
А423
А42
Верхня діаграма є батьківською для нижньої діаграми
Глава 1. Структурний підхід Метод функціонального моделювання SADT
Побудова ієрархії діаграм
А11
А12
А13
А1
Батьківський блок
А121
А122
А123
Ця керуюча дуга переноситься з батьківської діаграми
Ця вхідна дуга переноситься з батьк. діаграми
Ця дуга продовжується на батьків. діаграмі
А12
Глава 1. Структурный підхід. Моделювання потоків даних (процесів)
Загальні відомості
Діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог до проектованої системи.
Головна мета вистави - продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити стосунки між цими процесами.
Для побудови DFD використовуються дві різні нотації :
Метод Йордана;
Метод Гейна – Сэрсона.
Глава 1. Структурний підхід Моделювання потоків даних (процесів)
Склад діаграм потоків даних …
Основні компоненты діаграм потоків даних :
зовнішні сутності;
системи і підсистеми;
процеси;
накопичувачі даних;
потоки даних.
Склад діаграм потоків даних …
Зовнішнєю сутністю є матеріальний об'єкт або фізична особа - джерело або приймач інформації, наприклад замовники, персонал, постачальники, клієнти, склад.
Платник податків
1
Склад діаграм потоків даних
Система представляє в найзагальнішому вигляді саму інформаційну систему. Або цю роль виконує декомпозированный набір підсистем.
ГНИ
1
Підсистема по роботі з физ. обличчями
Поле номера
Поле імені
Поле фізичної реалізації
Склад діаграм потоків даних …
Процес - перетворення вхідних потоків даних у вихідні відповідно до певного алгоритму.
Нал. инспектор
1.1
Перевірити платника на заборгованість
Поле номера
Поле імені
Поле фізичної реалізації
Склад діаграм потоків даних …
Накопичувач даних – це абстрактний пристрій для зберігання інформації, яку можна у будь-який момент помістити в накопичувач і через деякий час витягувати, причому способи приміщення і витягання можуть бути будь-якими. На діаграмі ідентифікується буквою «D» довільним числом.
D1
Реєстр платників податків
Склад діаграм потоків даних
Потік даних – інформація, передавана через деяке з'єднання від джерела до приймача. Потік даних зображається лінією, стрілкою, що закінчується, яка показує напрям потоку.
1.5
Відділ звітності
Регіональна ГНИ
Сформувати звітність по прибутковому податку
1
Звітність по прибутковому податку
Побудова ієрархії діаграм потоків даних …
Головна мета побудови ієрархії DFD полягає в тому, аби зробити вимоги до системи ясними і зрозумілими на кожному рівні деталізації.
Для досягнення цього доцільно :
розміщувати на кожній діаграмі від 3 до 6-7 процесів;
не захаращувати діаграми не істотними на даному рівні деталями;
декомпозицію потоків даних здійснювати паралельно з декомпозицією процесів;
вибирати ясні, такі, що відображають суть справи імена процесів і потоків.
Глава 1. Структурний підхід. Моделювання потоків даних (процесів).
Побудова ієрархії діаграм потоків даних.
Кожен процес може бути деталізований за допомогою DFD або (якщо процес елементарний) специфікацій.
Специфікація процесу повинна формулювати його основні функції так, щоб надалі фахівець, що виконує реалізацію проекта, смог выполнить их или розробити відповідну програму. Специфікація є кінцевою вершиною ієрархії.
Рішення про завершення деталізації процесу і використання специфікації приймається аналітиком.
Глава 1. Структурний підхід. Сравнительный анализ SADT-моделей анализ SADT-моделей и DFD…
Співвідношення вживання цих двох різновидів структурного аналізу в існуючих CASE-средствах складає для DFD - 90 % і для SADT – 10%.
Адекватність засобів вирішуваним завданням. SADT успішно працює лише при описі добре специфікованих і стандартизованих бізнес-процесів. Якщо ж йдеться не про системи взагалі, а про інформаційні системи, то тут DFD поза конкуренцією. Наявність в DFD специфікацій процесів нижнього рівня дозволяє здолати логічну незавершеність SADT.
Глава 1. Структурний підхід. Порівняльний аналіз SADT-моделей та DFD
Узгодженість з іншими засобами структурного аналізу. Узгодження SADT-модели з ERD практично неможливе або носить штучний характер. У свою чергу, DFD і ERD взаємно доповнюють один одного.
Інтеграція з подальшими стадіями ЖЦ ПО (перш за все із стадією проектування). DFD можуть бути легко перетворені в моделі проектованої системи. Більш того, відомий ряд алгоритмів автоматичного перетворення ієрархії DFD в структурні карти різних видів. Формальні ж методи перетворення SADT-диаграмм в проектні рішення відсутні.
Глава 1. Структурний підхід. Функціональні моделі
Призначені для опису функціональної структури проектованої системи.
Ієрархія екранних форм моделюється за допомогою діаграм послідовностей екранних форм.
Техніка структурних карт (схем) використовується на стадії проектування для опису структурних схем програм. Найчастіше застосовуються дві техніки :
структурні карти Константайна (для опису стосунків між модулями).
структурні карти Джексона (для опису внутрішньої структури модулів, що є базовими будівельними блоками програмної системи).
Основні поняття …
Мета моделювання даних полягає в забезпеченні розробника концептуальною схемою бази даних.
Найбільш поширеним засобом моделювання даних є діаграми «сутність-зв'язок» (ERD).
Базовими поняттями ERD є :
сутність (Entity);
зв'язок (Relationship);
атрибут (Attribute).
Основні поняття
Сутність (Entity) – реальний або уявний об'єкт, що має істотне значення для даної наочної області. Кожне єство повинне володіти унікальним ідентифікатором.
Зв'язок (Relationship) – пойменована асоціація між двома єствами, значима для даної наочної області.
Атрибут (Attribute) – любая характеристика єства, значима для даної наочної області і призначена для кваліфікації, ідентифікації, класифікації, кількісної характеристики або вираження стану сутністі.
Метод Баркера
Дана нотація використовується в CASE-засобі Oracle Designer.
Перший крок моделювання – витягання корисної інформації з вихідних даних і виділення єств.
Автомашина
Покупець
Продавець
Контракт
Метод Баркера…
Другий крок моделювання – ідентифікація зв'язків. Степени связи – один и много. Обязательность – обов'язкова і необов'язкова.
Багато
Один
Необов'язкова
Обов'язкова
Контракт
Продавець
Покупець
Автомашина
Метод Баркера…
Третій крок моделювання – ідентифікація атрибутів.
Контракт
Продавець
Покупець
Автомашина
#І/Н (ідентифікаційний номер)
*дата
*ціна
#І/Н
* ім'я
*адреса
телефон
#І/Н
*им'я
*адреса
телефон
#Р/Н
*рік
*марка
*модель
*ціна
Метод Баркера…
Окрім перерахованих основних конструкцій модель даних може містити ряд додаткових
Супертипи і підтипи - одне єство є узагальнювальним поняттям для групи подібних єств.
Летательный аппарат
Вертолёт
Другой тип
Аэроплан
Планер
Самолёт
Підтипи
Супертипи
Метод Баркера…
Зв'язки, що взаємно виключають – кожен екземпляр сутністі бере участь лише в одному зв'язку з групи зв'язків, що взаємно виключають.
А
В
С
Глава 1. Структурний підхід Моделювання даних
Метод Баркера
Рекурсивний зв'язок – сутність може бути пов'язана сама з собою.
Непереміщувані (non-transferable) зв'язки – екземпляр сутністі не може бути перенесений з одного екземпляра зв'язку в іншій.
А
В
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Концептуальной основой объектно-ориентированного подхода является объектная модель.
Основными ее элементами являются:
Абстрагирование;
Инкапсуляция;
Модульность;
Иерархия.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Основные понятия объектно-ориентированного подхода – объект и класс.
Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение.
Класс – это множество объектов, связанных общностью структуры и поведения.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм.
Полиморфизм может быть интерпретирован, как способность класса принадлежать более чем одному типу.
Наследование означает построение новых классов на основе уже существующих.
Объектно-ориентированная система изначально строится с учетом ее эволюции.
Глава 2. Объектно-ориентированный подход. Сущность подхода.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы.
Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки.
По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области в объекты и классы информационной системы.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описания процесса моделирования.
Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов.
Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования.
Процесс – это описание шагов, которые необходимо выполнить при разработке проекта.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг.
Главными в разработке UML были следующие цели:
Представить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими;
Обеспечить независимость от конкретных языков программирования и процессов разработки;
Обеспечить формальную основу для понимания этого языка моделирования;
Предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
Интегрировать лучший практический опыт.
Глава 2. Объектно-ориентированный подход. UML.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Стандарт UML версии 1.1 предлагает следующий набор диаграмм для моделирования:
Диаграммы вариантов использования;
Диаграммы классов;
Диаграммы поведения системы;
Диаграммы состояний;
Диаграммы взаимодействия;
Диаграммы деятельности;
Диаграммы реализации;
Диаграммы компонентов;
Диаграммы размещения.
Глава 2. Объектно-ориентированный подход. Диаграммы классов ...
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Диаграммы классов являются центральным звеном объектно-ориентированных методов.
Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними.
Имеются два основных вида статических связей:
Ассоциации (Представляют собой связи между экземплярами классов).
Подтипы (частный клиент является разновидностью клиента).
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами.
Построение диаграмм классов можно рассматривать в различных аспектах:
Концептуальный аспект – диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации).
Аспект спецификации – модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне).
Аспект реализации – модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.
Глава 2. Объектно-ориентированный подход. Диаграммы классов…
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Ассоциации.
Ассоциации представляют собой связи между экземплярами классов ( личность работает в компании, компания имеет ряд офисов).
С концептуальной точки зрения ассоциации представляют собой концептуальные связи между классами.
Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Атрибуты.
На концептуальном уровне наличие атрибута «имя Клиента» указывает на то, что Клиенты обладают именами.
На уровне спецификации этот атрибут указывает на то, что объект Клиент может сообщить свое имя и обладает некоторым механизмом его определения.
На уровне реализации Клиент содержит поле (называемое также переменной или элементом данных), соответствующее его имени.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Операции.
Операции представляют собой процессы, реализуемые классом.
Операции делятся на два типа:
Запрос- операция, не изменяющая наблюдаемого состояния класса, результатом ее является некоторое значение, извлекаемое из класса. Наблюдаемым состоянием объекта является состояние, которое можно определить посредством связанных с ним запросов.
Модификатор- операция, изменяющая наблюдаемое состояние объекта.
Глава 2. Объектно-ориентированный подход. Диаграммы классов...
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Обобщение.
Типичный пример обобщения включает частного и корпоративного клиентов.
На концептуальном уровне, Корпоративный клиент является подтипом Клиента, если все экземпляры Корпоративного клиента являются экземплярами Клиента.
В рамках модели спецификации смысл обобщения заключается в том, что интерфейс подтипа должен включать все элементы интерфейса супертипа.
Обобщение в аспекте реализации связано с наследованием в языках программирования.
Глава 3. Связь структурного и объектно-ориентированного подходов…
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Главный недостаток структурного подхода заключается в следующем: процессы и данные существуют отдельно друг от друга.
В объектно-ориентированном подходе основная категория модели – класс – объединяет в себе на элементарном уровне, как данные, так и операции, которые над ними выполняются (методы).
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное преимущество объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом:
“объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.”
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Преимущества объектного подхода:
Объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств.
Объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем.
Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира.
Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
Глава 3. Связь структурного и объектно-ориентированного подходов.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Основой взаимосвязи между структурным и объектным подходом является общность ряда категорий и понятий обоих подходов.
Переход организации на объектно-ориентированную технологию – это смена мировоззрения.
Авторский коллектив.
ИТЛаб ВМК ННГУ, 14.05. 2003
Методы проектирования ПО © Пастухов В.А.
Мееров Иосиф Борисович – куратор проекта
Яценко Антон – лидер проекта
Коваленко Антон
Пастухов Виталий
Жеглов Андрей