Главная страница Случайная страница Разделы сайта АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
💸 Как сделать бизнес проще, а карман толще?
Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже.
Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал.
Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее. ✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать». Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами! Проектирование программ: язык моделирования
Язык моделирования — это, по сути, фикция, набор соглашений по поводу принципов предварительного моделирования программы на бумаге. Тем не менее без этого этапа невозможно создать эффективный профессиональный программный продукт. Давайте договоримся изображать классы на бумаге в виде треугольников, а отношения наследования между ними — в виде пунктирных стрелок от базового класса к производному. Для примера смоделируем класс Geranium (Герань), произведенный от класса Flower (Цветок), как показано на рис. 18.1.
Рис. 18.1. Схематическое изображение наследования класса
На рисунке видно, что Geranium — особый вид Flower, и это вполне соответствует действительности. Если мы с вами договоримся графически изображать таким способом наследования классов, то будем прекрасно понимать друг друга. Со временем мы, вероятно, захотим моделировать многие сложные отношения и разработаем свой набор соглашений и правил по созданию диаграмм, отображающих взаимосвязи объектов программы. Конечно, нам также придется довести эти соглашения до сведения других сотрудников, которые работают или будут работать вместе с нами над общим проектом. Возможно, мы будем взаимодействовать с другими фирмами, имеющими свои соглашения, и надо будет потратить время, чтобы выработать общие принципы, позволяющие избежать возможных недоразумений. В таком случае было бы полезным существование единого языка моделирования, понятного для всех. (В действительности эту прекрасную идею реализовать ничуть не проще, чем заставить всех жителей Земли говорить на эсперанто.) Тем не менее такой язык был создан, и имя ему — UML (Unified Modeling Language — унифицированный язык моделирования). Его задача состоит в том, чтобы добиться единообразия в отображении взаимоотношений между объектами в диаграммах. В соответствии с соглашениями языка UML нашу схему, представленную на рис. 18.1, следовало бы изобразить иначе (рис. 18.2).
Рис. 18.2. Те же отношения наследования, но с учетом соглашений UML
В соответствии с соглашениям и UML классы изображаются в виде прямоугольников, а наследование — в виде стрелки, направленной от производного класса к базовому. Направление стрелки противоречит тому, что подсказывает интуиция большинства из нас, но это не страшно: когда мы все договоримся, система заработает как надо. Соглашения UML совсем несложные. Диаграммы нетрудно понимать и использовать. Мы рассмотрим эти соглашения на конкретных примерах в ходе освоения этой главы, что гораздо проще изучения UML вне контекста. Хотя этой теме можно посвятить целую книгу, по правде говоря, это будет пустая трата времени и бумаги, поскольку язык UML вполне соответствует принципу: лучше один раз увидеть на практике, чем десять раз прочитать.
|