Реферат "Стандартизация разработки прикладного программного обеспечения" Группа: ио-20-1 Студент: Медяков Д. И



Скачать 383,44 Kb.
страница3/4
Дата22.09.2022
Размер383,44 Kb.
#190070
ТипРеферат
1   2   3   4
Связанные:
реф
This text is called Childhood is not the happiest time
Стандарт UML.
UML (Unified Modeling Language, Универсальный язык моделирования) представляет собой международный стандарт, использующий графические обозначения для создания объектной модели в области разработки программного обеспечения.
UML был создан ведущими специалистами в области объектно-ориентированного анализа и проектирования программных систем, из корпорации Rational SoftWare.
Язык UML предназначен для визуального построения моделей программных систем. Графические UML-модели, при помощи соответствующих программных средств, переводятся в программный код конкретной среды разработки.
Основным элементом языка UML является диаграмма, графически отображающая, во-первых, понятия, входящие в разрабатываемую систему, во-вторых, связи между понятиями. Принято восемь типов диаграмм.
1. Диаграмма прецедентов или вариантов использования (Use Case Diagram) (рис. 1). Данная диаграмма применяется для формализации выдвигаемых заказчиком требований и синхронизации его взгляда на систему с взглядом исполнителя.

Рисунок 1 пример use case diagram
2. Диаграмма видов деятельности (Active Diagram) (рис. 2). Диаграммы видов деятельности позволяют в наглядном виде представить на экране любые последовательности операций и редактировать их. Они в некоторой степени напоминают блок-схемы алгоритмов.

Рисунок 2 пример Active Diagram
3. Диаграмма взаимодействия (Interactive Diagram) (рис. 3). Данные диаграммы дополняют диаграммы видов деятельности и поясняют, как в системе происходит обмен сообщениями между различными классами и объектами.

Рисунок 3 пример Interactive Diagram
4. Диаграмма классов (Class Diagram). Представляет собой основной тип диаграмм, описывающий классы программ и взаимосвязи между ними.
5. Диаграмма состояний (State Diagram). Данная диаграмма определяет, какие состояния могут принимать классы системы в ходе работы программы, и формализует переходы между состояниями системы.
6. Диаграмма кооперации (Collaboration Diagram). Данная диаграмма объясняет, каким способом разные классы модели взаимодействуют друг с другом.
7. Диаграмма компонентов (Component Diagram). Диаграммы компонентов уточняют конкретные особенности реализации определенного языка программирования или конкретной компонентной технологии.
8. Диаграмма развертывания (Deployment Diagram). Данная диаграмма позволяет фиксировать техническую структуру создаваемой программной системы и сформировать накладываемые ограничения.
Язык UML признан в качестве стандарта независимым консорциумом OMG (Object Management Group), занимающимся стандартизацией объектных технологий. В настоящий момент, всеми вопросами развития языка UML занимаются специалисты OMG.

Примеры


Пусть есть 2 компании, назовём их Standard и Diversity. Компании разрабатывают web-приложения, в каждой из них работает одинаковое количество программистов, распределённых по 2 командам.
В компании Standard решили стандартизировать разработку, и все пишут на одном стеке с подробным регламентом разработки. В компании Diversity разработчики постоянно экспериментируют и пробуют разные технологии, в разных командах используют разные языки. Посмотрим, как стандартизация влияет на решение разных задач.
Шаблон приложения
Бизнес двух компаний развивается, они постоянно создают новые приложения. В компании Standard разработчики решили создать для них общий шаблон, чтобы команды могли быстро стартовать и не терять время на разработку типичных архитектурных решений. В шаблон кроме самых базовых вещей решили включить модуль запросов к серверу, стандартизировали обработку ошибок, показ уведомлений, модальных окон и т.д. А в Diversity команды каждый раз пробуют новые модули и решения независимо друг от друга
Если обе команды создают стандартные части приложений одинаково, быстро и на автомате, то Standard работает быстрее, так как они выигрывают в плане производительности, так как устранили расход времени на решение повторяющихся задач. А значит, стандартная архитектура экономит время.
Библиотека стандартных решений
Общая библиотека готовых решений (или даже не одна) рано или поздно появляется в каждой компании, которая создаёт ПО. Разработчики обычно ищут подходящее опенсорсное (или платное) решение или создают собственную библиотеку.
В Standard взвесили за и против и решили сами создать одну общую библиотеку готовых компонентов (календари, поисковые строки с автодополнением и прочее) с прицелом на собственную дизайн-систему. Diversity продолжает эксперименты с технологиями и даже может похвастать наличием нескольких библиотек в одном приложении. Под каждую отдельную задачу подбирается идеально подходящий модуль. Это интересная задача, но иногда такие модули требуют большого количества времени для интеграции.
Обе компании пришли к одному выводу: использование библиотек готовых решений высвобождает время разработчиков для реализации бизнес-логики, т.е. создания ценности для заказчика.
Тестирование
Ещё один плюс, который есть у компании Standard во время использования общих решений — это уменьшение количества ошибок в приложениях. Дело в том, что общие решения, которые используются в обеих командах, тестируются в разных сценариях, и с каждым новым приложением этих сценариев становится всё больше. Уверенность компании в надёжности общих решений и библиотек растёт со временем. Одна из аксиом тестирования — нет ПО без ошибок, поэтому увеличенный ресурс тестирования общих решений постоянно повышает качество конечного продукта. Diversity подвергается большему риску, постоянно интегрируя новые решения. Ей приходится тратить значительные усилия для поддержания необходимого качества своих приложений.
Ротация проектов и людей
Ситуация на рынке изменилась, обеим компаниям пришлось на некоторое время приостановить разработку в одной из команд, тогда как другой команде наоборот, добавили работы и сократили сроки вывода продукта на рынок.
Standard быстро усилила вторую команду разработчиками из первой, избежав простоя и поиска новых разработчиков. Переход на другой проект не занял много времени, разработчики снова погрузились в знакомую среду. Так же легко Standard решает и другие вопросы с перераспределением людей по проектам, будь то переходы из команды в команду из-за личных предпочтений или объединение команд.
В Diversity руководство встало перед сложным выбором: переучивать разработчиков первой команды на технологии второй, с чем, кстати, не все будут согласны, или открывать вакансии и набирать новых разработчиков. В любом случае потребуется дополнительное время для усиления второй команды, и может быть простой в работе первой.
Может показаться, что Standard всё время экономит время и деньги благодаря стандартным решениям в разработке. Это так, но картина будет неполной, если не учесть издержки на сам процесс стандартизации.
Стандартизацию нужно направлять, кто-то должен разработать сами стандарты, написать регламенты, создать инфраструктуру, постоянно мотивировать коллег к пользованию стандартными решениями, контролировать их правильное понимание и применение. Для этого требуются время и усилия, которые Diversity может потратить на новый проект, обучение или улучшение условий труда. Сами стандарты кто-то должен постоянно пересматривать и совершенствовать, иначе компанию ждёт технологический застой.


Скачать 383,44 Kb.

Поделитесь с Вашими друзьями:
1   2   3   4




База данных защищена авторским правом ©psihdocs.ru 2022
обратиться к администрации

    Главная страница