Перечень тем для проектирования программных систем

Введение

Контрольная работа – это работа, которую студент заочной формы обучения направления подготовки 09.04.04. выполняет самостоятельно по выданному заданию и при консультации преподавателя на основе изученного теоретического материала по дисциплине «Методология программной инженерии. Системные основы».

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

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

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

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

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


Нормативные ссылки

 

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

ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам Р 50-77-88 Рекомендации.

ГОСТ Р 1.5-2012 Стандартизация в Российской Федерации. Стандарты национальные. Правила построения, изложения, оформления и обозначения

ГОСТ Р 7.0.5-2008 СИБИД. Библиографическая ссылка. Общие требования и правила составления

ГОСТ 2.301-68 ЕСКД. Форматы

ГОСТ 7.9-95 СИБИД. Реферат и аннотация. Общие требования

ГОСТ 7.82-2001 СИБИД. Библиографическая запись. Библиографическое описание электронных ресурсов. Общие требования и правила составления

 


 

Задание на выполнение контрольной работы

 

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

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

обследование, системный анализ существующей системы и выявление ее недостатков;

— обобщение результатов системного анализа и создание предварительной концепции новой или модернизированной системы и ее программных средств;

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

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

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

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

— основы предварительного структурного проектирования и современных технологий системного анализа и проектирования сложных комплексов программ;

— методы разработки требований к характеристикам качества и распределения ресурсов, необходимых для реализации проектов сложных ПС и баз данных;

— задачи и принципы системного проектирования обеспечения безопасности и защиты комплексов программ от различных угроз;

— планирование жизненного цикла и управление качеством ПС, а также выбор инструментальных средств для поддержки всего их ЖЦ;

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

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

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

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

— наличие совокупности нескольких, тесно взаимодействующих, компонентов;

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

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

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

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

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

— совокупность предварительных исходных требований к функциям и характеристикам комплекса программ;

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

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

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

— проекты планов жизненного цикла, гарантирования требуемого качества ПС, защиты и обеспечения безопасности его функционирования;

— результаты технико-экономического обоснования целесообразности и основных направлений продолжения проектирования и всего ЖЦ ПС;

 

 

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

— предварительный план организации работ, требования к составу и квалификации специалистов для выполнения проекта и всего жизненного цикла ПС;

— проект формализованноготехнического задания и спецификации требований к ПС, а также предложения по его финансированию и обеспечению ресурсами;

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

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

 

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

Основные принципы и правила структурирования ПС и БД можно объединить в группы, которые отражают:

— стандартизированную структуру целостного построения ПС и/или БД определенного класса;

— унифицированные правила структурного построения функциональных программных компонентов и модулей;

— стандартизированную структуру базы данных, обрабатываемых программами;

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

— унифицированные правила организации и структурного построения межмодульных интерфейсов программных компонентов;

— унифицированные правила внешнего интерфейса и взаимодействия компонентов ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса, защиты и контроля системы.

 

При помощи CASE-средства Rational Rose построить модель программного обеспечения.

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

1) составление глоссария проекта;

2) создание модели вариантов использования;

3) анализ вариантов использования;

4) проектирование системы;

 

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

При проектировании системы требуется:

– создать иерархию классов системы;

– разместить классы по пакетам (использовать деление: пользовательский интерфейс – управление – данные; или другое в зависимости от постановки задачи);

– связать объекты с классами, сообщения на диаграммах взаимодействия – с операциями;

– каждый класс снабдить описанием, которое должно включать в себя краткое описание (ответственность класса), описание атрибутов в виде таблицы (имя, описание, тип), таблицу с описанием операций (имя, описание, сигнатура);

– для классов указать стереотипы;

– построить диаграммы классов системы, отображающие связи между классами;

– для описания поведения экземпляров отдельных классов построить

диаграммы состояний;

– разработать (если это требуется вариантом задания) схему базы данных и отобразить ее на диаграмме «сущность – связь».

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

 

Перечень тем для проектирования программных систем

1 Разработка проекта приложения торгового предприятия.

2 Разработка проекта приложения организации взаимодействия с клиентами предприятия.

3 Разработка проекта приложения организации социальной сети.

4 Разработка проекта приложения почтового сервера.

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

6 Разработка проекта приложения для туристического агентства.

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

8 Разработка проекта приложения для организации документооборота предприятия.

9 Разработка проекта приложения для логистической компании.

10 Разработка проекта приложения для финансового учреждения.

11 Разработка проекта программного обеспечения Интернет-магазина

12 Разработка проекта приложения строительного предприятия.

13 Разработка проекта приложения для сервисного центра.

14 Разработка проекта приложения для рекламного агентства.

15 Разработка проекта приложения для риэлтерского предприятия.

16 Разработка проекта приложения для IT- отдела предприятия.

17 Разработка проекта приложения для отдела кадров предприятия.

18 Разработка проекта приложения для экономического отдела предприятия

19 Разработка проекта приложения для медицинского учреждения.

20 Разработка проекта приложения для автотранспортного предприятия.

21 Разработка проекта приложения для образовательного учреждения.

22 Разработка проекта приложения для учреждения социального обеспечения.

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

 

 

Содержание и оформление контрольных работ

 

Контрольная работа выполняется на листах формата А4 по ГОСТ 2.301-68. Текст может быть выполнен рукописно или с помощью средств компьютерной техники. Рукописный текст может быть записан на одной стороне листа формата А4 с высотой прописных букв не более 10 мм. Текст следует размещать, соблюдая размеры полей:

правое –15 мм;

левое – 30 мм;

верхнее - 15 мм;

нижнее – 25 мм.

При оформлении текста, заголовков, иллюстраций, таблиц, и приложений следует руководствоваться с требованиями ГОСТ Р 1.5-2002, ГОСТ 2.105-95, используя стандартную терминологию, а при ее отсутствии принятую в технической литературе.

Листы контрольной работы нумеруют арабскими цифрами. Номер листа проставляют на нижнем поле листа справа. На титульном листе номер листа не проставляют.

Требования к структуре и содержанию разделов контрольной работы:

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

- Нормативные ссылки (обязательность выполнения раздела должна быть оговорена в задании на контрольную работу), в которых приводятся ссылки на использованные при выполнении контрольной работы ГОСТы, СНиПы и др.;

- Введение, в котором кратко излагаются цель контрольной работы;

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

- Список использованных источников, в которых приводятся сведения об использованных источниках, упомянутых в тексте контрольной работы в порядке их упоминания по ГОСТ 7.1-2003.

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

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

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

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

 


Список рекомендуемой литературы

 

1 Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки – СПб.: Питер, 2005

2 Арлоу Дж., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование – СПб. Символ-Плюс, 2007

3 Базы данных. Проектирование и разработка / Р. Фрост, Д. Дей, К. Ван Слайк; пер. с англ. А. Ю. Кухаренко. – М.: НТ Пресс, 2007. – 592 с. : ил. – (Самоучитель).

4 Брауде Э. Технология разработки программного обеспечения. Пер.с англ. — СПб.: Питер, 2004.

5 Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. 3-е изд. – М.: Вильямс, 2008.

6 Г. Буч, И. Якобсон, Дж. Рамбо «UML. Классика CS». 2-е изд. – СПб.: Питер, 2006.

7 Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2007.

8 Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения. Пер. с англ. — СПб.: БХВ-Петербург, 2005.

9 Липаев, В.В. Программная инженерия. Методологические основы: Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. — М. : ТЕИС, 2006. — 608 с. — 1000 экз. — ISBN 5-7598-0424-3 (в пер.).

10 Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2006.

11 Липаев В.В. Системное проектирование сложных программных средств для информационных систем. Изд. второе переработанное и дополненное. – М.: Синтег. 2002

12 Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2010.

13 Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007.

14 Фаулер М. Архитектура корпоративных программных приложений. – М.: Вильямс, 2007.

15 Фримен Э., Фримен Э. и др. Паттерны проектирования – СПб: Питер, 2011.