Файл: Практические задания.pdf

Добавлен: 25.10.2018

Просмотров: 2977

Скачиваний: 5

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

 

 

31 

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

книжки,  баланса  счета,  составление  отчетов  и  т.  д.  Это  традиционный  способ 

упорядочивания детальных требований; 

•  по состояниям (то есть путем указания детальных требований, приме-

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

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

в  которых  может  находиться  процесс  (начало,  реакция,  охлаждение  и  т.  д.). 

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

программу, находящуюся в конкретном состоянии. 

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

каждого  состояния  сильно  отличаются.  Например,  бухгалтерская  система  мо-

жет вести себя по-разному в зависимости от ее состояний, таких как «Конфигу-

рация», «Исполнение» или «Сохранение».  


background image

 

 

32 

Заключение 

В  методических  указаниях  приведено поэтапное  формирование  требова-

ний  к  разработке  программного  обеспечения.  На  основании  определения  кон-

цепции    программного  средства  и  выявления  пожеланий заказчика    определя-

ются  сценарии  работы  и  бизнес  роли  пользователей.  Определяются  функцио-

нальные и не функциональные требования к ПП, а также  их контроль. На ос-

новании профилей пользователей разрабатывается, протопит пользовательского 

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

и эргономичность с учетом принципов хорошего экранного дизайна: подходя-

щего типа окон, системного меню и др.  

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

теоретические знания и формируют практические навыки по разработке техни-

ческого задания к программному продукту. 

Представленный  теоретический  и  справочный  материал  позволяет  ис-

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


background image

 

 

33 

Список использованных источников 

1 Кулямин, В. В.  Технологии программирования. Компонентный подход: 

/  В.  В.  Кулямин .  -  М.:  Интернет-Университет  Информационных  Технологий;  

БИНОМ. Лаборатория знаний, 2011. - 463 с. : ил. ISBN 978-5-94774-544-3 (БИ-

НОМ.ЛЗ), ISBN 5-9556-0067-1 (ИНТРУИТ.РУ) 

2  Орлов,  С.  А.   Технологии  разработки  программного  обеспечения:  раз-

работка сложных программных систем: учеб. для вузов / С. А. Орлов .- 3-е изд. 

- CПб. [и др.] : Питер, 2004. - 527 с.: ил. ISBN 5-94723-145-Х 

3  Пилон,    Д.  Управление  разработкой  ПО/  Д.  Пилон,  Р.  Майлз.  –  СПб.: 

Питер, 2011. – 464 с.: ил. ISBN 978-5-459-00522-6 

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

Брауде. – СПб.: Питер, 2004. – 655 с.: ил. ISBN 5-94723-663-Х 

5  Гагарина,  Л.  Г.   Технология  разработки  программного  обеспечения: 

учеб. пособие для вузов по направлению "Информатика и вычислительная тех-

ника" / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул; под ред. Л. Г. Гагариной. 

-  М.  :  ИД  «ФОРУМ»:  ИНФРА-М,  2008.  –  400  с:  ил.  ISBN  978-5-8199-0342-1 

(ИД «ФОРУМ») ISBN 978-5-16-003193-4 (ИНФРА-М)  

6 Иванова, Г. С.  Технология программирования: учебник для вузов / Г. С. 

Иванова .- 3-е изд., перераб. и доп. - М. : МГТУ им. Н.Э. Баумана, 2006. - 336 с.: 

ил. ISBN ISBN 5-7038-2077-4 


background image

 

 

34 

Приложение А 

Унифицированный язык моделирования 

 

UML  –  стандартный  язык  для  написания  моделей  анализа,  проектирова-

ния  и  реализации  объектно-ориентированных  программных  систем  (Unified 

Modeling Language). UML может использоваться для визуализации, специфика-

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

UML – это не визуальный язык программирования, но его модели прямо транс-

лируются в текст на языках программирования (Java, C++, Visual Basic, Ada 95, 

Object Pascal) и даже в таблицы для реляционной БД. 

Словарь  UML  образуют  три  разновидности  строительных  блоков:  пред-

меты, отношения, диаграммы. 

Предметы – это абстракции, которые являются основными элементами в 

модели,  отношения  связывают  эти  предметы,  диаграммы  группируют  коллек-

ции предметов. 

 

Предметы в UML 

 

В UML имеются четыре разновидности предметов: 

 

структурные предметы; 

 

предметы поведения; 

 

группирующие предметы; 

 

поясняющие предметы. 

Эти  предметы  являются  базовыми  объектно-ориентированными  строи-

тельными блоками. Они используются для написания моделей. 

Структурные  предметы  являются  существительными  в  UML-моделях. 

Они  представляют  статические  части  модели  –  понятийные  или  физические 

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

1. Класс – описание множества объектов, которые разделяют одинаковые 

свойства, операции, отношения и семантику (смысл). Класс реализует один или 


background image

 

 

35 

несколько интерфейсов. Как показано на  рисунке 1, графически класс отобра-

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

ствами (атрибутами) и операциями. 

 

Рисунок  1  Классы 

 

2.  Интерфейс   набор  операций, которые определяют услуги  класса или 

компонента. Интерфейс описывает поведение элемента, видимое извне. Интер-

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

ких  услуг.  Интерфейс  определяет  набор  спецификаций  операций  (их  сигнату-

ры),  а  не  набор  реализаций  операций.  Графически  интерфейс  изображается  в 

виде  кружка  с  именем,  как  показано  на  рисунке    2.  Имя  интерфейса  обычно 

начинается с буквы «I». Интерфейс редко показывают самостоятельно. Обычно 

его присоединяют к классу или компоненту, который реализует интерфейс. 

 

Рисунок  2  Интерфейсы 

 

3.  Кооперация  (сотрудничество)  определяет  взаимодействие  и  является 

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

печения  коллективного  поведения  более  сложного,  чем  простая  сумма  всех 

элементов. Таким образом, кооперации имеют как структурное, так и поведен-

ческое измерения. Конкретный класс может участвовать в нескольких коопера-