до лабораторних робіт по курсу

« Принципи проектування інформаційних систем»

Для спеціальності 6.080201 – “Інформатика”

Харків 2007

Введение

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

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

Краткие теоретические сведения

1.1. Типичные компоненты архитектуры программного продукта

Типичные компоненты архитектуры программного продукта и типичные требования к ПО

Ø Организация программы

Ø Основные классы системы

Ø Организация данных

Ø Бизнес–правила

Ø Пользовательский интерфейс

Ø Управление ресурсами

Ø Безопасность

Ø Производительность

Ø Масштабируемость

Ø Взаимодействие с другими системами (интеграция)

Ø Интернационализация, локализация

Ø Ввод-вывод данных

Ø Обработка ошибок

1. Организация программы.

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

2. Основные классы системы.

При разработке архитектуре крайне желательно проработать все основные классы, которые будет реализовать данные системы. Необходимо стараться, чтобы примерно 20% всех классов определяли 80% функциональности системы.

3. Организация данных.

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

4. Бизнес–правила.

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

5. Пользовательский интерфейс.

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

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

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

6. Управление ресурсами.

Архитектура системы должна включать план управления ограниченными ресурсами такими как: соединение с БД, потоки, дескрипторы. При разработке драйверов в обязательном порядке необходимо проработать способ управления памятью и способы доступа к устройствам.

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

7. Безопасность.

Архитектура всегда должна определять все необходимые меры безопасности для разрабатываемой системы. Зачастую система безопасности может быть вынесена в отдельную подсистему безопасности, разделенную на 2 составляющие:

- будет обеспечивать защиту данных в системе;

- будет обеспечивать безопасность системы с точки зрения несанкционированного доступа.

8. Производительность.

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

9. Масштабируемость.

Масштабируемость – возможность системы адаптироваться к росту требований. Архитектура должна учитывать, каким образом может быть расширена система или реагировать на рост числа пользовательских серверов, запросов, транзакций, количества записей в БД.

10. Взаимодействие с другими системами (интеграция).

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

11. Интернационализация, локализация.

Интернационализация – реализация в программе поддержки региональных стандартов.

Локализация – перевод интерфейса программы на какой-то конкретный язык.

12. Ввод-вывод данных.

При разработке архитектуры следует уделить внимание обработке ошибок, связанных с вводом, выводом и записью данных.

13. Обработка ошибок.

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

14. Отказоустойчивость.

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

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

15. Надежность.

Надежность – способность системы противостоять различным отказам и сбоям.

Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние.

Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя.

Чем меньше отказов и сбоев за какой-то определенный интервал времени, то система считается надежнее.

Чем дальше, тем тяжелее будет найти ошибку.

Чем сложнее система, тем больше вероятность отказов и сбоев.

16. Возможности реализации разрабатываемой архитектуры.

При разработке архитектуры должен быть проведен анализ, насколько реально разработать систему с заданными требованиями производительности способную работать на заданных аппаратных средствах.

17. Избыточная функциональность.

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

18. Принятие решение о приобретении готовых компонент ПО.

Перед принятием решения об использовании компонент сторонних разработчиков необходимо обязательно провести всесторонний анализ этих компонент и уделить внимание следующим вопросам:

- наличие исходного кода компонент;

- правило лицензирования;

- совместимость этих компонент с предполагаемой средой разработки;

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

- наличие квалифицированной технической поддержки со стороны разработчиков этих компонент.

19. Стратегия изменений.

Архитектура должна четко описывать стратегию изменения путей улучшения и развития разрабатываемой системы. На уровне архитектуры необходимо предусмотреть возможности периодического обновления системы с использованием различных update и service pack.

Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры:

1. Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование.

2. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами.

3. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы.

4. Приведено ли описание самых важных классов и их обоснование.

5. Приведено ли описание организации БД.

6. Определены ли все бизнес правила.

7. Описано ли их влияние на систему.

8. Описана ли стратегия проектирования пользовательского интерфейса.

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

10. Приведено ли описание стратегии ввода-вывода данных.

11. Проведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры.

12. Проведен ли анализ надежности проектируемой системы.

13. Проведен ли анализ вопросов масштабируемости и расширяемости системы.

1.2. Рекомендации по разработке исходного кода

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

· Следовать принятым правилам именования классов, объектов, методов и переменных

· Размещать комментарии в исходном коде;

· Избегать повторяемости кода;

· Реализация метода должна занимать не более 2-х экранов;

· Избегать слишком большой вложенности циклов. Стремиться сократить размеры циклов.

· Класс должен иметь хорошую связность (свойства и методы класса должны описывать только 1 объект);

· Интерфейс класса должен формировать согласованную абстракцию

· Метод должен принимать разумно минимальное число параметров

· Отдельные части класса должны изменяться совместно с другими частями класса

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

· Разрабатывать классы таким образом, чтобы исключить необходимость параллельно изменять несколько иерархий наследования

· Разрабатывать универсальные блоки case т.е. сделать реализацию блока case таким образом, чтобы ее можно было вызывать в нужном количестве мест в программе

· Родственные элементы данных, используемые вместе, должны быть организованы в классы. Если вы неоднократно используете один и тот же набор элементов данных, то целе-сообразно объединить эти данные и выполняемые над ними операции в отдельный класс

· Метод должен использовать в основном элементы собственного класса.

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

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

· Данные, передаваемые в метод только для того, чтобы он их передал другому методу, называются «бродячими». При возникновении таких ситуаций постарайтесь изменить архитектуру классов и методов, чтобы от них избавиться от таких данных

· Избавляться от объектов-посредников. Если роль класса сводится к перенаправлению вызовов методов в другие классы, то лучше всего такой объект-посредник устранить и выполнять вызовы других классов непосредственно;

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

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

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

· Стараться избегать использования в коде глобальных переменных. Глобальными должны быть только те переменные, которые в действительности используются всей программной. Все остальные переменные должны быть либо локальными, либо должны стать свойствами каких-либо объектов

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

1.3. Представления модели и диаграммы в языке UML

Основная область	Представления	Диаграммы	Основные концепции
Структурная	Статическое представление	Диаграмма классов	Класс, ассоциация, обобщение, зависимость, реализация, интерфейс
	Представление проектирования	Внутренняя структура	Соединитель, интерфейс, часть, порт, обеспеченный интерфейс, роль, требуемый интерфейс
		Диаграмма кооперации	Соединитель, кооперация, использование кооперации, роль
		Диаграмма компонентов	Компонент, зависимость, порт, обеспеченный интерфейс, тре-буемый интерфейс, подсистема
	Представление Use Case	Диаграмма Use Case	Актер, ассоциация, расширение, включение, элемент Use Case, обобщение элемента Use Case
Динамическая	Представление конечных автоматов	Диаграмма автомата	Завершение перехода, осуществле-ние деятельности, эффект, событие, область, состояние, переход, триггер
	Представление деятельности	Диаграмма деятельности	Действие, деятельность, поток управления, узел управления, поток данных, исключение, область расширения, разделение, слияние, объектный узел, контакт
	Представление взаимодействия	Диаграмма последовательности	Спецификация вхождения, спецификация исполнения, взаимодействие, фрагмент взаимодействия, операнд взаимодействия, линия жизни, сообщение, сигнал
		Диаграмма коммуникации	Кооперация, сторожевое условие, сообщение, роль, порядковый номер
Физическая	Представление развертывания	Диаграмма развертывания	Артефакт, зависимость, манифестация, узел
Управление моделью	Представление уп-равления моделью	Диаграмма пакетов	Импорт, модель, пакет
	Профиль	Диаграмма пакетов	Ограничение, профиль, стереотип, теговая величина

2. Порядок выполнения лабораторных работ

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

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

2. Представление Use Case для системы с указанием актеров и узлов. При выполнении данного этапа должны быть построены диаграммы Use Case, диаграмма компонентов, диаграмма кооперации, а также должны быть представлены соответствующие описания актеров, узлов и компонентов системы.

3. Диаграмма последовательности, диаграмма внутренней структуры и диаграмма основных классов системы.

4. Диаграмму пакетов основных программных сервисов системы идиаграмма развертывания.

5. Обоснование выбора архитектуры системы (тонкий или толстый клиент), обоснование выбора среды разработки, СУБД и операционной системы.

6. Прототип интерфейса. Должны быть разработаны основные интерфейсы системы с учетом требований к интерфейсам. В отчете должны быть представлены изображения интерфейсов, которые можно разработать в графическом или HTML редакторе или с использованием какой-либо среды разработки программного обеспечения. Основным требованием к прототипу интерфейса является предоставление возможности представить как будет выглядеть система в будущем.

При оформлении отчета необходимо руководствоваться требованиями, предъявляемыми к курсовым работам. Объем отчета по лабораторным работам должен быть 15-20 страниц.

Рекомендуемое содержание отчета следующее:

1. Концепция системы

1.1. Описание проблемной области

1.2. Постановка задачи.

1.3. Описание основной функциональности системы

1.4. Структурная классификация системы

1.5. Анализ сложности компонентов системы

2. Архитектура системы

2.1. Представление Use Case

2.2. Диаграмма кооперации

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

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

2.5. Диаграмма внутренней структуры

2.6. Диаграмма основных классов системы

2.7. Диаграмма пакетов основных программных сервисов системы

2.8. Выбор архитектуры системы и обоснование технических решений

2.9. Обоснование выбора среды разработки, СУБД и операционной системы

2.10.Диаграмма развертывания системы

2.11. Требования к программному и аппаратному обеспечению

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

3.1. Описание интерфейса пользователя

3.2. Основные компоненты интерфейса пользователя

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

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

Система оценивания

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

№ етапу	Найменування етапу	рейт. оцінка

1.	Разработка лабораторной работы согласно задания и показ результатов выполнения преподавателю
2.	Защита лабораторной работы: ответы на теоретические вопросы	2-7
	Загальна кількість	5-10

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

Лабораторная работа №1.

Концепция системы. Система проектирования ArgoUML. Представление Use Case и диаграмма кооперации.

До начала выполнения данной работы студенты должны самостоятельно подготовить следующие разделы для отчета:

1.1. Описание проблемной области

1.2. Постановка задачи.

1.3. Описание основной функциональности системы

1.4. Структурная классификация системы

1.5. Анализ сложности компонентов системы

В ходе выполнения данной лабораторной работы студенты должны изучить принципы работы с системой ArgoUML, разработать представление Use Case и диаграмму кооперации. Также должны быть представлены необходимые описания для компонентов представления Use Case.

Контрольные вопросы

1. Какой результат структурной классификации системы применительно к Вашему заданию?

2. Каким образом осуществляется анализ сложности системы и в каком виде представляется результат?

3. Что такое представление Use Case?

4. Какие основные компоненты используются в представлении Use Case?

5. Для чего используется представление Use Case?

6. Что такое диаграмма кооперации?

7. Дайте характеристику актеров, ассоциаций и расширений применительно к Вашему заданию.

Лабораторная работа №2.

Разработка архитектуры информационной системы. Разработка диаграммы компонентов и диаграммы последовательности

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

Контрольные вопросы

1. Дайте характеристику диаграммы компонентов

2. Что такое компонент?

3. Для чего предназначен обеспеченный интерфейс?

4. Что такое требуемый интерфейс?

5. Дайте характеристику диаграммы последовательности.

6. Что такое спецификация вхождения?

7. Что такое спецификация исполнения?

8. Что такое фрагмент взаимодействия?

Лабораторная работа №3.

Разработка диаграммы внутренней структуры, диаграмма основных классов системы и диаграммы пакетов

В ходе выполнения данной лабораторной работы необходимо разработать:

1. Диаграмму внутренней структуры

2. Диаграмму основных классов системы

3. Диаграмму пакетов

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

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

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

Контрольные вопросы

1. Дайте характеристику диаграммы внутренней структуры

2. Что такое соединитель и интерфейс?

3. В чем отличия обеспеченного и требуемого интерфейсов?

4. Что такое диаграмма основных классов системы?

5. Объясните понятия класса и ассоциации

6. Объясните понятия обобщения и зависимости

7. Дайте характеристику диаграммы пакетов

8. Что такое ограничение. Приведите пример ограничения

Лабораторная работа №4.

Обоснование выбора средств разработки, операционной системы и СУБД. Требования к программному и аппаратному обеспечению. Диаграмма развертывания системы.

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

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

Контрольные вопросы

1. Для чего используется диаграмма развертывания

2. Что такое артефакт?

3. Объясните понятие «зависимость» применительно к диаграмме развертывания и приведите пример

4. Укажите критерии, которые Вы использовали при выборе операционной системы. Объясните, почему именно этими критериями Вы руководствовались.

5. В чем состоят отличия тонкого и толстого клиентов?

6. В чем состоят отличия интранет веб приложения и веб сайта?

7. Обоснуйте, почему Ваша системы сможет обеспечить обслуживание необходимого числа клиентов.

Лабораторная работа №5.

Разработка прототипа интерфейса

Данная лабораторная работа предполагает, что будет разработан прототип интерфейса

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

Контрольные вопросы

1. Какие требования предъявляются к интерфейсу пользователя.

2. Назовите основные теоретические предпосылки, связанные с проектированием интерфейса

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

4. Объясните, в каких случаях следует использовать элементы интерфейса сторонних разработчиков. Какие трудности могут при этом возникать.

5. На какие факторы следует обращать внимание при выборе компонентов сторонних разработчиков.

Задания на лабораторные работы

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

а) Компания, занимающаяся разработкой программного обеспечения. В данном случае ресурсами предприятия являются:

- сотрудники

- компьютеры

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

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

б) Компания, занимающаяся производством мебели

в) Компания, занимающаяся сборкой и продажей компьютеров

г) Компания, занимающаяся ремонтом и обслуживанием автомобилей

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

2. Система управления кадрами на предприятии

3. Система управления отношениями с поставщиками

4. Система управления отношениями с клиентами

5. Система управления недвижимостью. Данная система должна представлять собой распределенную веб систему (веб сайт) с использованием которой, владелец недвижимости, обслуживающий персонал и люди, которые используют недвижимость, могут осуществлять обмен информацией по различным вопросам ее обслуживания. В качестве сервеной ОС должна использоваться ОС Windows 2003 Server, а в качестве базы данных - MS SQL SERVER 2005.

6. Разработать систему управления складами предприятия расположенными в 3-х городах

7. Разработать систему интернет магазина по продаже книг

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

9. Разработать систему управления проектами для компании, занимающейся разработкой программного обеспечения

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

11. Разработать систему учета оплаты услуг для интернет провайдера

12. Разработать систему автоматизации формирования заявок на выполнение ремонтных работ и поставки запасных частей для электроэнергетической компании.

13. Разработать систему управления и мониторнга состояния проектов в инвестиционной компании.

14. Разработать систему продажи и бронирования авиационных билетов

15. Разработать систему управления процессом транспортировки контейнеров. Перевозка контейнеров может осуществляться морским железнодорожным и автомобильным транспортом.

16. Разработать систему автоматизации документооборота компании

17. Разработать систему электронного «аукциона» для поставщиков строительных материалов. Предполагается, что заказчик будет размещать запрос на поставку строительных материалов для некоторого строительного объекта, а поставщики должны иметь возможность разместить свои коммерческие предложения.

18. Разработать автоматизированную систему истории болезни. Данная система представляет собой набор автоматизированных рабочих мест для врачей различных специальностей и предназначена для медицинских учреждений, в которых работают специалисты различного профиля (поликлиники). Система должна позволять хранить историю болезни пациента, информацию о проведенных обследованиях, назначениях лекарств и результатах лечения. Врач должен иметь возможность на своем рабочем месте вносить информацию о процессе обследования и лечения пациента.

19. Разработать систему управления процессом обработки корреспонденции для компании экспресс доставки почтовых отправлений. Предполагается, что данная компания имеет собственных парк транспортных средств, таких как автомобили и самолеты.

20. Разработать систему управления грузовыми перевозками для автотранспортной компании.

21. Разработать систему учета основных средств производства на предприятии. В частности в системе должны учитываться ремонты и модернизация всех основных средств.

22. Разработать систему учета резюме для отдела кадров компании. Данная система кроме учета резюме должна обеспечивать возможность формирования расписания проведения собеседований, отслеживание результатов собеседования и хранить информацию по кандидатам.

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

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

Приложение 1. Нотация UML

В этом приложении дается краткое изложение нотации UML. Сюда вошли все основные ее элементы, однако мы не стали приводить здесь все возможные их вариации.