Глава 5. Структурное моделирование
Декомпозиция нужна,
Для изучения системы.
Ее использование нам
Даёт систему постепенно
Делить на части до тех пор,
Пока любая из частей
Не станет ясной на обзор,
Позволив разобраться в ней.
Есть много всяческих нотаций
Для построения диаграмм,
Чтоб можно было собираться
Как разработчикам программ,
Так и заказчикам, и прочим
Участникам и «налегке»
Всем разъясняться на рабочем
Одном наглядном языке.
Методологии семейства
IDEF (Айдеф) дают создать модели
Систем, предоставляя средства
Различных видов построения.
IDEF0 (Айдееф ноль) – этап начальный
Анализа систем – их функций.
На этом виде диаграммы
Есть ряд известных всем конструкций.
Процессы – функции системы,
Потоки данных: управления –
Обычно сверху от процессов,
Выходы справа, входы слева.
Такая форма представления
Бизнес-процессов позволяет
Показывать их отношения –
Соподчиненность отражая.
Один из нескольких подходов
Для изучения систем
Их функций и границ народу
Известный многим, хоть не всем –
Подход структурный и системный –
На основании DFD (Дээфдэ).
С разбором функций постепенным
Для составления ТЗ.
Начальный уровень – контекстный –
На нем есть основной процесс
С потоками взаимодействий
С внешними сущностями. Здесь
Определяются границы
Для построения системы
По документам и страницам
Взаимодействующим с нею.
В дальнейшем изучении будем
Декомпозировать процесс мы
На подпроцессы – список функций
Для изучаемой системы.
Для построения моделей
Потоков данных применяют
Нотации. Для этих целей
В них элементы выделяют:
Процесс – указывают смело
Для отражения функций, целей,
Обозначают, что ей делать
Как в целом также и отдельно.
Внешняя сущность – для показа
Объектов вне нашей системы
И демонстрации их связи
С системным основным процессом.
Хранилище – оно же база
Тех данных, что хранят в системе.
Его располагают сразу
На первом уровне модели.
Поток – графическое средство
Показа связей диаграммы:
От внешней сущности к процессу
И от процесса к базе данных.
Словарик данных помогает
Потокам данных описания
Сформировать. Предоставляет
Их в виде текстового знания.
Так, чтобы было всем понятно,
Что именно передаётся
Между процессов. Аккуратно
В итоге всё в БД сведётся.
Для описания процессов,
Когда нет смысла в их делении,
Бывает применить полезно
Другие средства в объяснении:
Спецификации, к примеру,
Как описание в виде текста,
Да хоть обычную блок-схему,
Иль флоу-форму – всё уместно.
Глава 6. Объектно-ориентированное моделирование
Для построения диаграмм
В унифицированном виде
При описании программ
Язык объектный примените –
Универсальный – UML (Юмээл).
В нём моделируйте процессы
Программных и бизнес-систем
В разных разрезах и контекстах.
Виды диаграмм UML2
Статическая диаграмма
Структуры кода и системы –
Пожалуй, диаграмма классов,
Одна из главных в Юмээле.
На ней показывают классы,
Их методы и атрибуты.
И связи между ними сразу
Здесь тоже есть в их общей сути.
На диаграмме прецедентов
Показывают отношения –
Связи от юзеров системы
К ее вариантам выполнения.
Взаимодействие объектов
Показывают диаграммой
Последовательности выполнения.
На ней представлены программа
И пользователь, и другие
Участники, как вертикали.
И сообщения между ними
По времени их протекания.
На диаграмме компонентов
Показаны библиотеки,
Модули, файлы и пакеты
И связи между ними всеми.
На диаграмме размещения
Показывают наложение
Программного обеспечения
На аппаратные решения.
Глава 7. Техническая документация
Для выполнения проекта
С известным качеством и сроком
Весьма полезным документом
ТЗ является. Во многом
Его задача – однозначность
При понимании системы.
В ТЗ описаны задачи
Проекта так, чтоб были всеми
Они восприняты в едином
Ключе и смысле, и трактовок
Различных не было в картине
И описании разработок.
Когда проект большой ведётся,
И разработчиков в нём много,
На подсистемы создаётся
Задание частное в итоге.
Все описания дальнейших
Проектных принятых решений
Технический проект содержит,
В нём излагают о системе
Устройство, алгоритмы, схемы,
От базы данных до внедрения