В теории модульная архитектура позволяет повторно использовать код, и система получается более гибкой. На практике это практически невозможно реализовать.

Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом деле работает система, что она делает и как она это делает. Кроме того, модели являются средствами коммуникаций между разработчиками, но для этого они должны быть понятны каждому. Вот для этого в RUP используется UML, который позволяет разработчикам говорить на одном языке.

Качество продукта - одна из важнейших его характеристик. Заявляется, что RUP ориентирован на достижение приемлемого уровня качества, однако в процессе адаптации этой методологии с качеством могут возникать проблемы, если адаптация будет не совсем удачной.

Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика либо на изменяющиеся условия внешней среды. RUP имеет процессы, которые позволяют эффективно отслеживать изменения.

RUP является адаптируемым процессом, то есть его можно настраивать под нужды конкретной команды и под конкретный проект. Более того, это делать совершенно необходимо, поскольку в противном случае эффективность использования RUP будет стремиться к нулю. Чем меньше команда, тем легче должен быть процесс. То есть надо создавать минимум артефактов и вводить минимум ролей. Из общего описания RUP можно взять только те процессы, роли и артефакты, которые действительно нужны команде для разработки качественного продукта в срок и в пределах бюджета.

При разработке планируется использование объектно-ориентированного подхода. В рамках выбранных инструментов разработки сочетание объектно-ориентированного анализа, проектирование и программирование должны дать максимальный результат. Структурный подход заключается в декомпозиции (разбиении) системы на автоматизируемые функции, при котором система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и подзадачи. Процесс разбиения продолжается вплоть до конкретных процедур. В отличие от структурного подхода, объектно-ориентированный подход состоит в объектной декомпозиции предметной области, то есть система представляется не набором функций, а совокупностью объектов, взаимодействующих друг с другом. Объектно-ориентированный подход в большей степени реализует модель реального мира и соответствует естественной логике человеческого мышления.

В рамках применения объектно-ориентированного подхода мы собираемся использовать UML. UML представляет собой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем. Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования в частности. Выбор средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей сложных систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели [19].

Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к объектно-ориентированному подходу это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений, каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления. Феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы.

Глава 2: Исследование

Число итераций этой фазы трудно предсказать заранее, однако обычно оно не превосходит двух, а основное внимание уделяется этапу сбор требований. Задачи фазы "Исследование" четко определены ее целями: описание основных характеристик Системы, снижение вероятности реализации основных рисков и подготовка обоснования проекта с точки зрения его связи с основными задачами бизнеса. На этой стадии:

· выделяется предметная область действия системы, то есть определяются границы применения приложения и его взаимоотношение с другими системами;

· предлагается предварительная архитектура, в частности, уточняются новые, сложные и рискованные элементы приложения;

· выявляются основные риски;

Фаза завершается формулировкой целей проекта.

Подробный анализ требований заказчика позволил создать единую картину функциональности будущей системы. Прежде всего были определены 3 пользователя системы:

Продавец – лицо, работающее на контрольно-кассовом аппарате.

Администратор – лицо, ведущее количественный учет товаров.

Менеджер – управляющий компанией.

Затем были выделены функции каждого пользователя:

Пользователь	Функция	Описание
Продавец	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Расход	Создание и изменение расходной накладной
Администратор	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Приход	Создание и изменение приходной накладной
	Редактирование накладных	Управление уже сохранёнными расходными и приходными накладынми
	Редактирование списка "Поставщики"
	Редактирование списка "Каталог"
	Редактирование списка "Магазины"
Менеджер	Авторизация	Вход в Систему по своему логину и паролю
Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
Создание отчета об остатках	Просмотр количественной информации по остаткам на складах
Создание отчета об оборотах	Просмотр финансовой информации по оборотам компании

В результате детализации ряда функций была построена следующая диаграмма вариантов использования:

Глава 3: Проектирование

Фаза "Проработка" обычно ограничивается двумя-тремя итерациями. На этой фазе основное внимание уделяется созданию базовой архитектуры приложения, более или менее детальной оценке стоимости и выработке предварительного графика. Основные работы, выполняемые на этой стадии следующие:

· создание базовой архитектуры приложения, включающей все функциональные возможности, признанные важными всеми участниками проекта;

· выявление основных рисков, включая план, стоимость и график управления ими на следующих стадиях;

· сбор схем использования, покрывающих минимум 80% функциональных возможностей системы;

На этой фазе основное внимание уделяется этапам анализа и проектирования. На этапе анализа требования к приложению анализируются и формулируются на языке разработчиков. Этап "анализ" - промежуточный между сбором требований и проектированием приложения.

Принципиальное отличие RUP от многих других итеративных подходов состоит в большом внимании к разработке архитектуры системы. Архитектура в RUP включает в себя тип организации системы и используемые типовые решения. Кроме того, архитектура в RUP — это еще и ключевая часть кода (обычно, до 20% общего объема), которая позволяет продемонстрировать соответствие системы основным функциональным и нефункциональным требованиям. Поэтому в RUP часто говорится о понятии "архитектурный каркас" [10]. Ориентация на архитектуру означает, что разработку программного обеспечения начинают с разработки архитектурного каркаса, а затем наращивают дополнительную функциональность, максимально используя отработанные при создании каркаса типовые решения. Это дает возможность использовать RUP для решения таких заведомо сложных задач, как разработка систем с использованием новых технологий (например, языков программирования или платформ), а также снижает трудоемкость разработки, позволяя избегать многократного решения схожих задач.

Основным инструментом разработчика на данном этапе выступает TogetherDesigner 2005. Проектирование ведется на языке UML с использованием минимально необходимого набора диаграмм для упрощения дальнейшего процесса разработки, а именно: диаграмм классов, диаграмм последовательностей, диаграмм компонентов и диаграмм развертывания.

Автоматизированная система складского учета в ЗАО "Белгородский бройлер" (стр. 3 из 10)

Глава 2: Исследование

Глава 3: Проектирование