Реферат: Разработка ИС музыкального магазина Аккорд с использованием диаграмм UML

Федеральное агентство по образованию

ГОУ ВПО «Санкт-Петербургский государственный

инженерно-экономический университет»

Филиал в г. Чебоксары

Кафедра инженерных наук и информационных технологий

Отчет

по учебной практике по специализации

на тему «Разработка ИС музыкального магазина «Аккорд»

с использованием диаграмм UML»

Выполнил:

студент гр 92-05

Моргалев С. О.

Проверила:

Алякина А. А.

Чебоксары 2010

Содержание

Введение___________________________________________________________4

1. Виды диаграмм UML _____________________________________________6

1.1. Диаграмма прецедентов___________________________________________7

1.2. Диаграмма классов_______________________________________________9

1.3. Диаграмма последовательностей___________________________________10

1.4. Диаграмма состояний____________________________________________11

1.5. Диаграмма деятельности_________________________________________12

2. Разработка ИС музыкального магазина «Аккорд»_____________________14

2.1. Предварительная информация_____________________________________14

2.1.1.Краткая информация о компании_________________________________14

2.2.Видение выполнения проекта______________________________________15

2.3 .Отчет об обследовании___________________________________________15

2.3.1.Анализ существующего уровня автоматизации______________________15

2.3.2.Общие требования к ИС_________________________________________16

2.3.3.Формы документов_____________________________________________17

2.3.4.Описание системы учета_________________________________________18

2.3.5. Список типовых хозяйственных операций и их отражение в провод- ках_______________________________________________________________19

2.3.6.Организационная диаграмма_____________________________________20

2.3.7.Описание состава автоматизируемых бизнес-процессов______________21

2.3.8.Диаграммы прецедентов_________________________________________21

2.3.9.Физическая диаграмма__________________________________________23

2.3.10.Описания бизнес-процессов_____________________________________23

2.3.11.Формирование бизнес-процессов________________________________24

2.3.12. Спецификации настроек ИС____________________________________29

2.3.13. Проектирование реализации операций бизнес-процесса в информационной системе____________________________________________31

Заключение________________________________________________________34

Список использованной литературы___________________________________35

Приложение________________________________________________________36

Введение

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

Наиболее известными визуальными моделями, используемыми для проектирования компьютерных систем и их программных обеспечений, являются диаграммы языка UML и стандарта IDEF0, таблицы и диаграммы стандарта IDEF1X. Эти визуальные модели имеют математическую основу в виде теорий графов, множеств и матриц.

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

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

Интеграция информационной системы и системы управления на процедурном уровне обеспечивается на этапе консалтинга путём разработки, оптимизации и согласования бизнес-процессов. Бизнес-процессы разрабатываются в тесной связи с другими документами организационного дизайна компанией. Например, права участников бизнес-процессов должны быть согласованы со структурой управления, а выполняемые функции - с должностными инструкциями. При внедрении ИС необходимо детализировать бизнес-процессы до документов ИС, что позволяет в дальнейшем использовать их, в качестве инструкций операторов, а также для формирования сценариев обучения пользователей.

В результате изучения состава, содержания и процедур формирования основных документов, которые создаются в процессе типового проектирования информационной системы, требуется разработать диаграммы бизнес-процессов на основе их вербального описания, которое получается в результате обследования деятельности гипотетического предприятия «Аккорд».

Целью моей работы является разработка документов, необходимых для настройки типовой ИС, и проектирование реализации операций бизнес-процесса в информационной системе.

1.Виды диаграмм UML

Свою историю унифицированный язык объектно-ориентированного моделирования ведет с конца 80х - начала 90х годов. Собственно создание UML началось в 1994 году. В это время Грэйди Буч (Grady Booch) и Джеймс Рэмбо (James Rambaugh) начали объединять несколько методов объектно-ориентированного моделирования в фирме Rational Software. И уже в 1995 году была представлена спецификация метода, названного Unified Method. Первая версия UML была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре версия UML 1.1 была принята на вооружение основными компаниями - производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett-Packard и производителями CASE-средств, которые реализовали поддержку UML в своих программных продуктах (Paradigm Plus, Microsoft Visual Modeler for Visual Basic, Delphi и др.)

Авторы и разработчики UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы. UML определяет нотацию и метамодель. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования.

Универсальный язык объектного моделирования UML не зависит от языков программирования и, вследствие этого, может поддерживать любой объектно-ориентированный язык программирования. Он является открытым и позволяет расширять ядро.

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

Языки и методы моделирования состоят, как правило, из следующих составных частей:

3 Концепции моделирования, их семантика.

4 Визуальное представление элементов моделирования

5 Правила применения элементов моделирования.

Первый компонент - это элементы модели, второй - нотация и третий - принципы использования.

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

Второе значительное достоинство - упрощение общения заказчика и разработчика. Это связано как с повышенной наглядностью модели, так и с ее гибкостью и динамичностью.

Само собой, решаются вопросы уменьшения времени, затрачиваемого на разработку проекта, его стоимости и повышения качества.

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

На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:

• описывает видимую пользователем функцию,

• может представлять различные уровни детализации,

• обеспечивает достижение конкретной цели, важной для пользователя.

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

На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: "использование" и "расширение" (рис. 1.1). Связь типа "расширение" применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа "использование" позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.

Рис. 1.1 Диаграмма прецедентов учебного заведения

1.2.Диаграмма классов (class diagram)

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

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

Классы используются в процессе анализа предметной области для составления словаря предметной области разрабатываемой системы. Это могут быть как абстрактные понятия предметной области, так и классы, на которые опирается разработка и которые описывают программные или аппаратные сущности.

Диаграмма классов - это набор статических, декларативных элементов модели. Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки.

Рис. 1.2. Диаграмма классов учебного заведения

1.3.Диаграмма последовательностей (sequence diagram)

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

Рис. 1.3 Диаграмма последовательностей работы лифта

1.4.Диаграмма состояний (statechart diagram)

Д иаграммы состояний (Statechart diagrams) используются для описания поведения сложных систем. На диаграммах состояний представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.

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

Рис. 1.4 Диаграмма состояний прохождения академического курса

1.5.Диаграмма деятельности (activity diagram)

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

Основными элементами диаграмм деятельности являются :

•овалы, изображающие действия объекта;

• линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И"};

• ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");

• стрелки — отражают последовательность действий, могут иметь метки условий.

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

Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания).

Рис. 1.5 Диаграмма деятельности оформления заказа в интернет-магазине

Глава 2. Разработка ИС музыкального магазина «Аккорд»

2.1. Предварительная информация

2.1.1.Краткая информация о компании «Аккорд»:

Магазин «Аккорд» закупает музыкальные инструменты и концертное оборудование в крупных компания России и зарубежных стран и продаёт их в розницу и оптом.

Основные бизнес-процессы компании - закупки, складирование запасов, продажи, взаиморасчеты с поставщиками и покупателями.

Уровень конкуренции для компании в последнее время возрос, так как на рынок вышли 2 новых конкурента, к которым перешла часть клиентов и ряд наиболее квалифицированных сотрудников ООО «Аккорд».

По предварительным данным компания намерена увеличить количество магазинов до 3 (на данный момент один магазин).

Адреса и телефоны

Чебоксары, 428000, улица Афанасьева, д.10а

Телефон: (8352) 666-666, факс: (8352) 777-77

Контактные лица

Иванов Иван Иванович – Генеральный директор

Петров Петр Петрович – Исполнительный директор

Сидоров Алексей Алексеевич – Директор по маркетингу

Сотрудники:

На момент проведения Диагностики штат организации составляет 5 человек. Основными целями проекта автоматизации организации «Аккорд» являются:

· Разработка и внедрение комплексной автоматизированной системы поддержки логистических процессов компании.

· Повышение эффективности работы всех подразделений компании и обеспечение ведения учета в единой информационной системе.

2.2. Видение выполнения проекта и границы проекта

В рамках проекта развертывание новой системы предполагается осуществить только в следующих подразделениях ООО «Аккорд»:

· Отдел закупок;

· Отдел приемки;

· Отдел продаж;

· Отдел маркетинга;

· Группа планирования и маркетинга;

· Группа логистики;

· Учетно-операционный отдел;

· Учетный отдел;

· Отдел сертификации

· Бухгалтерия (только в части учета закупок, продаж, поступлений и платежей).

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

Количество рабочих мест пользователей - 5.

2.3. Отчет об обследовании

2.3.1. Существующий уровень автоматизации

Список программного обеспечения, используемого компанией на момент обследования

1) "1С: Предприятие 7.7" ("Бухгалтерия", "Торговля", "Зарплата", "Кадры", "Касса", "Банк") для работы бухгалтерии.

2) Две собственные разработки на базе конфигуратора "1С" - "Закупки" и "Продажи".

3) Собственная разработка на базе FOXPRO для финансового отдела.

4) Excel для планирования продаж.

Таблица 1

Существующий уровень автоматизации

2.3.2. Общие требования к информационной системе

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

Ключевые функциональные требования к информационной системе:

1. Мощные средства защиты данных от несанкционированного доступа. Разграничения доступа к данным в соответствии с должностными обязанностями.

2. Возможность удаленного доступа.

3. Управление запасами. Оперативное получение информации об остатках на складе.

4. Управление закупками. Планирование закупок в разрезе поставщиков.

5. Управление продажами. Контроль лимита задолженности с возможностью блокировки формирования отгрузочных документов.

6. Полный контроль взаиморасчетов с поставщиками и клиентами.

7. Получение управленческих отчетов в необходимых аналитических срезах - как детальных для менеджеров, так и агрегированных для руководителей подразделений и директоров фирмы.

2.3.3. Примеры форм отчетных документов

Таблица 2

Примеры форм отчетных документов

2.3.4. Описание системы учета

ООО "Аккорд" использует типовой российский план счетов, три аналитики (контрагенты, договора, регионы).

Таблица3

Фрагмент плана счетов компании

2.3.5.Список типовых хозяйственных операций и их отражение в проводках

Фрагмент описания справочников, используемых для автоматизации организации "Аккорд", приведен в таблице.

Таблица 4

Справочники, используемые для автоматизации компании

Код справочника отражает уровни иерархии. Справочники клиентов и договоров имеют трехуровневую структуру. Справочник поставщиков - двухуровневую структуру. В коде справочника для отображения уровня применен символ подчеркивания. Например, в коде справочника клиентов первый уровень обозначен символами "Pl"-покупатель; второй уровень - "Pk"-постоянные клиенты.

2.3.6.Организационная диаграмма

Рис. 2.1. Организационная диаграмма ООО «Аккорд»

2.3.7. Описание состава автоматизируемых бизнес-процессов

Бизнес-процессы компании, подлежащие автоматизации, приведены в следующей таблице:

Таблица 5

Бизнес-процессы, подлежащие автоматизации

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

2.3.8 Диаграммы прецедентов

Проектирование любой АИС лучше всего начинать с построения диаграммы прецедентов, описывающей внешнюю границу АИС. Такая диаграмма называется главной диаграммой прецедентов. Главная диаграмма прецедентов показана на Рис.2.2.

Рис.2.2. Диаграмма прецедентов ООО «Аккорд»

2.3.9 Физическая диаграмма

Взаимодействие с внешними контрагентами представлено на рис.2.3.

Рис.2.3. Физическая диаграмма ООО «Аккорд»

2.3.10 Описания бизнес-процессов

Бизнес-процессы компании, подлежащие автоматизации, приведены в следующей таблице:

Таблица 6

Бизнес-процессы, подлежащие автоматизации

2.3.11.Формирование бизнес-процессов.

Бизнес – процесс «Планирование закупок, формирование заказов поставщикам»

Общее описание бизнес- процесса.

1. Менеджер группы планирования и маркетинга ежесуточно получает от контрагентов данные внешней и внутренней статистики продаж медикаментов в виде отчетов продаж.

2. Для планирования закупок медикаментов менеджер группы планирования и маркетинга еженедельно на основании статистики продаж производит расчет потребности в товаре. В результате расчета формируется Таблица потребностей в товаре.

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

4. Менеджер отдела закупок ежемесячно на основании Таблицы потребностей в товаре и списка выбранных поставщиков формирует графики поставок с указанием сроков и периодичности, но без количества поставки.

5. Ежемесячно после определения потребности в товаре менеджер группы логистики рассчитывает необходимое количество закупок. Необходимое количество закупок рассчитывается на основании фактических запасов на складе, необходимого минимального и максимального уровня запасов. Нормы минимального и максимального количества запасов устанавливаются в днях. При расчете необходимого количества закупки учитывается также время товара в пути. Таким образом, данный расчет должен обеспечить возможность бесперебойного отпуска товара со склада. По результату расчетов формируется план заявок на месяц.

6. Затем в группе логистики ежедневно по плану заявок, графику поставок, прайс-листам поставщиков формируются заказы поставщикам.

7. Если предстоит сделать заказ импортному поставщику, то менеджер группы логистики рассчитывает затраты на сертификацию, создается отчет о затратах на сертификацию. Затраты на сертификацию проверяются на соответствие внутрифирменным нормам. Данная операция производится по мере необходимости.

8. Если затраты на сертификацию превышают внутрифирменные нормы, то менеджер группы логистики повторяет процесс формирования заказов поставщикам. Формируются новые заказы.

9. Ежедневно подготовленный заказ поставщику акцептуется, заказ должен подписать менеджер по логистике и директор Департамента маркетинга и управления товарными запасами.

10. Ежедневно менеджер группы логистики направляет заказ в отдел закупок. Менеджер отдела закупок направляет заказ поставщику.

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

Рис.2.4 Диаграмма действий бизнес-процесса « Планирование закупок, формирование заказов поставщикам»

Формирование таблицы операций.

Таблица 7

Описание операций

Таблица 8

Формирование таблицы описания документов

Пример документа на оформление заказа приведен в приложении.

2.3.12. Спецификации настроек ИС

Логистика

· Прогноз закупок, продаж, запасов.

· Описание хранения с использованием склада, палет и размещения.

· ABC-анализ по заданным пользователем критериям ABC-анализа по реализации, себестоимости и марже.

· Просмотр номенклатуры на карантинном складе на любом этапе контроля качества.

· Поддержка штрих-кодов.

Сводное планирование

· Расчет потребности в материалах и мощностях.

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

· Возможность расчета краткосрочных потребностей на основе существующих заказов и/или прогнозного планирования.

· Получение сводного плана по заказам.

· Система может предложить внести следующие изменения к существующим и спланированным заказам: Увеличение количества заказа, Уменьшение количества заказа, Отложить выполнение заказа или закупки

Учет договоров

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

· Привязка накладных и оплат к конкретному договору (указание договора в строках журналов ГК, заказах, закупках, накладных и оплатах с последующим переносом в проводку по клиенту/поставщику)

· Включение атрибутов договоров в предложения по оплате

· Автоматическое/периодическое сопоставление проводок по контрагентам и договорам

· Форма ручного сопоставления в рамках договоров

· Сальдо расчетов в рамках отдельного договора

· Номер договора в проводках по курсовой разнице

· Переход от моделей предметной области к функциональной модели системы

2.3.13. Проектирование реализации операций бизнес-процесса в информационной системе

Таблица 9

Реализация операций бизнес-процесса

"Планирование закупок и размещение заказов поставщикам"

Заключение

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

В данной работе было проведено обследование бизнес-процесса «Планирование закупок, формирование заказов поставщикам» деятельности организации «Аккорд».

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

Данный этап проектирования информационной системы завершает стадию разработки технического задания и позволяет перейти к дальнейшей разработке ИС – стадии рабочего проектирования.

Список использованной литературы:

1. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 2004. – 351 с.

2. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 2005. – 252 с.

3. Лемке Джуди. Microsoft Office Visio 2003. Шаг за шагом: практ.пособие/ Пер. с англ. – М.: «СП ЭКОМ», 2006. -252 с.

4. Леоненков А. Самоучитель UML. Серия "Самоучитель". - СПб.: BHV-Санкт-Петербург, 2007 - 304 с.: ил.

5. Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 2005. – 196 с.

6. Мейер М. Теория реляционных баз данных. – М.: Мир, 2006. – 608 с.

7. Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информационных технологий / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.:Интернет-Университет Информационных технологий, 2005. – 304 с.

Приложение

Шбл=16+8+3*(64+8)+0,5*5+2,2*5=253,5

Шгр=3*(18+1)=57, 33, 9, 48, 27, 18, 21

Вбл=8+8+20+9*8+6*2+0,5*5+2,2*5+11=140,7