Справочник программиста в стихах. От проектирования до внедрения

Глава 5. Структурное моделирование

Декомпозиция

Декомпозиция нужна,

Для изучения системы.

Ее использование нам

Даёт систему постепенно

Делить на части до тех пор,

Пока любая из частей

Не станет ясной на обзор,

Позволив разобраться в ней.

Нотации моделирования

Есть много всяческих нотаций

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

Чтоб можно было собираться

Как разработчикам программ,

Так и заказчикам, и прочим

Участникам и «налегке»

Всем разъясняться на рабочем

Одном наглядном языке.

IDEF (Integrated DEFinition)

Методологии семейства

IDEF (Айде́ф) дают создать модели

Систем, предоставляя средства

Различных видов построения.

IDEF0 (Айдее́ф ноль) – этап начальный

Анализа систем – их функций.

На этом виде диаграммы

Есть ряд известных всем конструкций.

Процессы – функции системы,

Потоки данных: управления –

Обычно сверху от процессов,

Выходы справа, входы слева.

Такая форма представления

Бизнес-процессов позволяет

Показывать их отношения –

Соподчиненность отражая.

Диаграммы потоков данных (Data flow diagrams, DFD)

Один из нескольких подходов

Для изучения систем

Их функций и границ народу

Известный многим, хоть не всем –

Подход структурный и системный –

На основании DFD (Дээфдэ́).

С разбором функций постепенным

Для составления ТЗ.

Начальный уровень – контекстный –

На нем есть основной процесс

С потоками взаимодействий

С внешними сущностями. Здесь

Определяются границы

Для построения системы

По документам и страницам

Взаимодействующим с нею.

В дальнейшем изучении будем

Декомпозировать процесс мы

На подпроцессы – список функций

Для изучаемой системы.

Элементы DFD-диаграмм

Для построения моделей

Потоков данных применяют

Нотации. Для этих целей

В них элементы выделяют:

Процесс – указывают смело

Для отражения функций, целей,

Обозначают, что ей делать

Как в целом также и отдельно.

Внешняя сущность – для показа

Объектов вне нашей системы

И демонстрации их связи

С системным основным процессом.

Хранилище – оно же база

Тех данных, что хранят в системе.

Его располагают сразу

На первом уровне модели.

Поток – графическое средство

Показа связей диаграммы:

От внешней сущности к процессу

И от процесса к базе данных.

Словарь данных

Словарик данных помогает

Потокам данных описания

Сформировать. Предоставляет

Их в виде текстового знания.

Так, чтобы было всем понятно,

Что именно передаётся

Между процессов. Аккуратно

В итоге всё в БД сведётся.

Спецификация процессов

Для описания процессов,

Когда нет смысла в их делении,

Бывает применить полезно

Другие средства в объяснении:

Спецификации, к примеру,

Как описание в виде текста,

Да хоть обычную блок-схему,

Иль флоу-форму – всё уместно.

Глава 6. Объектно-ориентированное моделирование

Унифицированный язык моделирования (Unified Modeling Language, UML)

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

В унифицированном виде

При описании программ

Язык объектный примените –

Универсальный – UML (Юмээ́л).

В нём моделируйте процессы

Программных и бизнес-систем

В разных разрезах и контекстах.

Виды диаграмм UML2

Диаграмма классов (Class diagram)

Статическая диаграмма

Структуры кода и системы –

Пожалуй, диаграмма классов,

Одна из главных в Юмээле.

На ней показывают классы,

Их методы и атрибуты.

И связи между ними сразу

Здесь тоже есть в их общей сути.

Диаграмма прецедентов (Use case diagram)

На диаграмме прецедентов

Показывают отношения –

Связи от юзеров системы

К ее вариантам выполнения.

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

Взаимодействие объектов

Показывают диаграммой

Последовательности выполнения.

На ней представлены программа

И пользователь, и другие

Участники, как вертикали.

И сообщения между ними

По времени их протекания.

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

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

Показаны библиотеки,

Модули, файлы и пакеты

И связи между ними всеми.

Диаграмма развёртывания/размещения (Deployment diagram)

На диаграмме размещения

Показывают наложение

Программного обеспечения

На аппаратные решения.

Глава 7. Техническая документация

Техническое задание3

Для выполнения проекта

С известным качеством и сроком

Весьма полезным документом

ТЗ является. Во многом

Его задача – однозначность

При понимании системы.

В ТЗ описаны задачи

Проекта так, чтоб были всеми

Они восприняты в едином

Ключе и смысле, и трактовок

Различных не было в картине

И описании разработок.

Частное техническое задание

Когда проект большой ведётся,

И разработчиков в нём много,

На подсистемы создаётся

Задание частное в итоге.

Технический проект4

Все описания дальнейших

Проектных принятых решений

Технический проект содержит,

В нём излагают о системе

Устройство, алгоритмы, схемы,

От базы данных до внедрения

И эффективности системы.

На языке для исполнения:

Когда ТЗ для всех понятно,

ТП – уже для программиста –

В нём не столь нужно деликатно

Искоренять все жаргонизмы.

Руководство пользователя

Когда написана система,

Для помощи в работе с нею

Полезна текстовая схема,

Чтоб описать её идею

Для пользователей и просто

Помочь в процессе изучения

Её работы – руководство.

Обычно в нем обозначение

Дается следующим вопросам:

Обзор и ссылки, назначение

Системы, функции и способ

Их применения, и решение

Проблем возможных при работе

И при типичном применении.

Полезный документ для многих,

При изучении приложения.

Руководство администратора

Администратору в работе

Инструкция нужна другая –

В ней описание даёте

Как доступ, роли назначают,

Как заполняют базы данных

И разворачивают сервер,

Как исправлять ошибки надо,

Коль есть известные примерно.

Программа и методика испытаний5

Когда проект идёт к внедрению,

Бывает нужен документ,

В котором есть определение,

Как «тестить» каждый элемент.

Программа тестов-испытаний

При разработке под заказ

Даёт возможность понимания,

Что как проверить и, подчас,

Нужна не менее задания

На разработку, ведь по ней

Проводится согласование

С заказчиком системы всей.

В ней нужен список всех условий

Для выполнения работ,

Сценарий, тесты, по которым

Заказчик проверять пойдёт.

Часть 2. Архитектура ПО

Архитектура

Архитектура приложения –

Борьба со сложностями в нём.

И без неё, как наваждение,

Затраты потекут ручьём,

Потом безудержным потоком

На проведение небольших,

Казалось бы, работ. Итогом –

Перерасход сил трудовых.

Программная архитектура –

Есть описание частей

Системы – вся её структура,

Устройство, отношения в ней –

Все те решения, что в дальнейшем

Затратно будет изменять.

Поэтому вопрос важнейший

Их, в целом, правильно принять.

Хорошая архитектура

Даёт возможность широко

Сопровождения процедуру

Вести удобно и легко.

Вся суть здесь в разделении кода

На модули и компоненты.

С таким предположением, чтобы

Ослабить связи элементов.

Охватить проект единой мыслью?

Память нужна программисту для жизни,

Больше, пожалуй, чем многим другим.

Помнить все связи объектов капризных,

Чтоб, ненароком, их не упустить.

Чтобы не вышло неведомых багов,

Нужно, частенько, проект в голове

Как-то держать. Если код одинаков,

Распределен в однотипной канве,

Это становится проще немного.

Если же связи не слишком сильны

Между частями его, то дорога

Эта заметно полегче. Увы

Все ухищрения работают явно,

Пусть хорошо, но эффект всё ж размыт.

Память нужна, чтобы помнить хотя бы

То, для чего код программный открыт.

Глава 8. Парадигмы программирования

Императивное программирование

В императивной парадигме

Код – для процессора команды,

Что будут выполнены в ритме

Последовательном, как ни странно.

Мы пишем то, как надо сделать,

И ожидаем, что так будет.

Здесь можно весь контроль изведать,

Но просто что-то перепутать.

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

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

Обозначает результаты –

И представляет описание

Того, что нам в итоге надо.

В ней нет значений переменных,

Нет точной логики работы.

Примером может быть отменным

HTML (Аштиэмэ́ль), SQL (Сикьюэ́ль) коды.

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

При парадигме процедурной

Все операторы и строки –

Команды кода – можно будет

Делить на целостные блоки.

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

В структурной парадигме сутью

Явилось оформление кода

В иерархической структуре –

В формате иерархий блоков.

За счёт того, что между ними

Нет безусловных переходов,

Ограничениями такими

Даёт облегчить тесты кода.

Объектно-ориентированное программирование

При ООП программу строят

Из блоков кода и их данных.

Структуру классами готовят,

И создают их экземпляры,

Как по шаблону, для хранения

И обработки данных, чтобы,

В больших проектах упрощения

Таким путём добыть немного.

Функциональное программирование

В функциональной парадигме

Все вычисления ведутся

В «математическом режиме» –

В формате вычисления функций

Без сохранения состояний.

Используются лишь входные

Их аргументы. Позволяя

Убрать ошибки основные

В многопоточных вычислениях,

Но и цена идёт большая –

Для получения значения

Расчёт сначала повторяя.

Аспектно-ориентированное программирование

В аспектной парадигме можно

Сквозные функции системы,

Которые бывает сложно

Не поместить в другие темы,

К примеру, логи и проверки,

Авторизацию, профайлинг,

Отметить в качестве аспектов.

К примеру, атрибутов в шарпе.

Обобщённое программирование

При обобщённой парадигме

Для обработки разных данных

Используются алгоритмы,

Что пишутся универсально.

Примером могут быть шаблоны –

Дженерик-функции и классы.

Параметрический, в итоге,

Полиморфизм состоялся.

Глава 9. Принципы проектирования

Глобальное проектирование прежде всего (Big Design Up Front)

Прежде всего подумать стоит

И спроектировать систему.

И это, может, сэкономит

Нам кучу времени, проблемы

Предотвратив на ранних сроках.

Так изменить ТЗ – не долго,

А код бессмысленный намного

Дороже написать без толку.

Предметно-ориентированное проектирование (Domain-driven design, DDD)

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

На основании бизнес-правил –

То бишь проблемного подхода –

Модель предметную составим.

Система, как набор моделей

Предметной области, позволит

Облегчить построение в целом

Её структуры и ускорит

Её развитие в дальнейшем.

Понизит сложность изучения

Частей системы для скорейших

Их написания и внедрения.

Придерживайся простоты (Keep it simple, stupid, KISS)

Усложняя, упрощай –

Избегай ненужных дебрей,

В простоте все сохраняй,

Ищи лучшее решение.

Чем система проще будет,

Тем надёжнее она,

Усложнение всё погубит,

И запутает весьма.

Бритва Оккама (Occam’s Razor, OR)

Не нужно сущность создавать,

Когда ей нет особой роли.

Не нужно нового, когда

Подходит то, что есть дотоле.

Не повторяйте себя (Don’t Repeat Yourself, DRY)

Не надо повторять себя –

Решай единожды задачи.

Ведь если надо будет взять

И сделать что-либо иначе,

Во всех повторах повторить

Придётся эти изменения

И ничего не пропустить –

Довольно сложно в выполнении.

До написания кодов

Полезно изучить систему:

Вполне возможно, код готов

И кем-то был когда-то сделан.

Вам это не понадобится (You Aren’t Gonna Need It, YAGNI)

Пишите только то, что надо,

Прямо сейчас, а не в грядущем.

Это уменьшит вам затраты.

Не нужно делать, что не нужно.

Преждевременная оптимизация (Avoid Premature Optimization)

Не нужно слишком рано код

Оптимизировать упорно.

И лишь когда проект готов,

Оптимизации достойна

Становится программа вся.

И начинать полезно будет

С тех мест, что явно тормозят,

От остального не убудет.

Глава 10. Проектирование слоёв, звеньев и подсистем

Границы и зависимости подсистем

Чтоб нам систему развивать

Удобно было и приятно,

Её полезно разделять

Так, чтобы было не затратно

В дальнейшем части отделить

В процессы, сервисы и службы,

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

Как монолит – бывает нужно.

Сей выбор можно отложить

И написать систему в целом

Так, чтобы можно было жить

Ей в разных звеньях и разделах.

Как независимую часть

Отдельным модулем, проектом –

В основе – лучше прописать

Всю бизнес-логику. При этом

Взаимодействия вокруг –

Фреймворки, базы данных

И интерфейсы – в виде слуг

И плагинов непостоянных.

Слои абстракции

Для упрощения создания

Больших систем их делят на

Слои, что больше пониманья

Дают для каждого звена.

Слои в себе скрывают сложность,

Давая только интерфейс

Для тех что выше и возможность

Замены внутренностей здесь.

Слои, что ниже, в общем целом,

О верхних знать не должны,

Над ними могут, между делом,

И новые быть введены.

Глобальных данных быть не может,

Всё состояние – внутри.

Конкретных связей, функций – тоже –

Лишь интерфейсы между них.

Благодаря такой структуре

Слои возможно заменять.

Внутри слоёв в архитектуре

Всю сложность лишнюю скрывать.

Звенья

Систему можно разделить

На несколько частей, к примеру,

На сервер и клиент. Решить,

Как будет лучше это сделать,

Обычно, первый из шагов

Архитектуры приложения.

Ряд слабосвязанных узлов

Отдельных называют звенья.

Файл-сервер

Для файл-серверных систем

Предполагается возможность

Хранения данных в файлах. Всем

К ним должен быть открытый доступ.

Двухзвенная архитектура клиент-сервер

Двухзвенная архитектура

Предполагает два звена

И два подхода, как структура,

И логика разделена.

Удаленный доступ к данным (Remote Data Access, RDA)

В модели RDA (Эрдэа́), иначе –

Доступа к удаленным данным –

Вся логика и все задачи

На стороне клиент-программы,

А в базе лишь хранение данных.

При этом больше трафик и

Выше возможность нежеланных

Вмешательств с третьей стороны.

DBS (Database Server)

В модели сервера баз данных,

Иначе – в DBS (Дэбээ́с)-модели –

Клиент – собрание форм экранных,

А логикой владеет сервер.

Но мощь хранимых процедур,

Которыми реализуют

Здесь логику, и их структур,

Пред кода силами пасуют.

Многозвенная архитектура

Сервер приложений (Application Server, AS)

В модели «сервер приложений»

Есть основные три звена:

«Клиент» ведёт отображение,

А серверов, обычно, два.

«Сервер баз данных» для хранения.

И сервер приложения, где

Проходят бизнес-вычисления.

Быть может не один вполне.

Модель подобная сложнее,

Но есть и целесообразность:

Поддержка проще и прямее,

Гораздо выше безопасность.

Многозвенная web-архитектура

Другой вариант трёхзвенки – это

Веб-приложение. Для него

Сервер баз данных будет где-то

И сервер приложения. Но

На сервере и вычисления,

И построение интерфейса.

И лишь одно отображение

В веб-браузере на клиенте.

Микросервисы

Когда систему разделяют

На много маленьких программ,

Их все отдельно запускают

В процессах, службах, тут и там…

По сути, функция – программа –

Отдельный код и разработчик.

Для масштабирования – славно,

Для эффективности – не очень.

Глава 11. Проектирование компонентов

Сложность интеграции изменений единого крупного проекта при командной работе

Когда система велика,

В едином связном коде очень

Бывает сборка не легка,

И каждый новый разработчик

Здесь добавляет свой кусок

При интеграции системы,

На это тратится часок,

А у кого-то и неделя.

Компонент

При разработке код программ

Подразделяют на проекты.

Они потом помогут нам

Разрезать всё на компоненты.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.