ТРПО в.2 (Романцов Д.Ю.) Аттестация ПОИТ 2017г (245гр)

ТРПО в.2 (Романцов Д.Ю.) Аттестация ПОИТ 2017г (245гр)

1) Назовите основные этапы в моделях жизненного цикла ПО.

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

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

3) Прокомментируйте особенности модели жизненного цикла в экстремальном программировании.

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

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

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

Рисунок 2.10 – Модель ЖЦ в экстремальном программировании

4) Смоделируйте внешний вид трёх основным моделей: каскадной, с промежуточным контролем, спиральной.

Рисунок 2.3 – Модель ЖЦ с промежуточным контролем

Рисунок 2.9 – Изображение хода работ по спиральной модели

Структурное проектирование (виды диаграмм IDEF, схемы алгоритмов).

1) Назовите, какие из следующих методов моделирования и диаграмм существуют в структурном проектировании: IDEF0, IDEF1X, IDEF2, IDEF3, IDEF4, IDEF8, IDEF14, DFD, ERD.

2) Опишите основные положения структурного проектирования.

3) Продемонстрируйте блоки для построения схем алгоритмов.

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

Методология функционального моделирования (IDEF0).

1) Назовите рисунок с типом влияния блоков друг на друга «обратная связь по управлению».

2) Изложите основные принципы функционального моделирования.

3) Составьте перечень операций создания IDEF0 диаграмм и запишите по ним рекомендации.

4) Скорректируйте диаграмму на рисунке 2, чтобы избежать ошибок.

1) Назовите основные отличительные факторы диаграмм DFD от IDEF0.

3) Конкретизируйте принципы и порядок составления диаграммы DFD.

4) Интерпретируйте, какую информацию предоставляет предложенная контекстная диаграмма.

1) Различите на диаграмме ключевые поля у сущностей.

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

4) Смоделируйте с помощью IDEF1 базу данных «Магазин», содержащую следующие таблицы и поля: таблица сотрудники (ФИО, адрес, телефон, должность); таблица должности (с полями определиться самостоятельно); таблица товары (наименование, стоимость); таблица продажи (сотрудник, товар, количество, дата продажи).

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

2) Сформулируйте трудности, возникающие при неиспользовании классов в программировании.

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

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

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

3) Классифицируйте модификаторы области видимости.

1) Public (общедоступный) – члены класса, находящиеся в данном разделе, доступны из любой точки программы. Public поля, свойства и методы – внешне видимая часть объекта, дающая доступ к внутренней организации класса. Избегайте создание полей публичными –вместо этого определяйте свойство для обращения к ним.

2) Private (закрытый) – члены класса, доступные только внутри реализации класса и в пределах модуля, в котором объявлен класс, в наследниках уже не доступны. Это жизненно важная часть концепции ООП, в которой класс рассматривается как черный ящик. Если метод был вынесен в приватную группу, то разработчик этого класса не рекомендует обращаться к нему из внешнего кода. Ограничение НЕ работает в юните, в котором описан и реализован класс, распространяется лишь на другие юниты.

3) Strict private (Delphi XE) – когда вы описываете методы как приватные они все равно видны по крайней мере в рамках одного unit, т.е. это отношение "friend" в терминах C++. Указание strict private означает действительно приватный метод или свойство, и оно не видимо никому, кроме самого класса даже в рамках unit.

4) Protected (защищённый) – члены класса доступны только в модуля где он описан/реализован, в реализации текущего класса и его наследников. Большинство членов, внутренних для класса должны быть protected. Часто это дает подклассам полезный доступ к ним. Используйте private, когда вы уверены, что хотите сохранить материал полностью локальным, например, метод проверки значения свойства. Вы, возможно, захотите сделать защищенные методы виртуальными, чтобы позволить подклассам изменять их. Ограничение НЕ работает в юните, в котором описан и реализован класс, оно распространяется лишь на другие юниты.

5) Strict protected (Delphi XE) – по образу и подобию strict private – только такие методы будут видимы самому классу и его наследникам.

6) Published (публикуемый, Delphi) – устанавливает правила видимости те же, что и public. Особенность в том, что для элементов published, компилятор генерирует информацию о типах, что позволяет превращать объекты в компоненты визуальной среды разработки. Секцию published разрешено использовать только тогда, когда для самого класса или его предка включена директива компилятора $TYPEINFO. Только один constructor может быть объявлен как published, overload версии должны быть определены как public. Published свойства не могут возвращать массивы.

7) Automated (автоматический, Delphi) – совпадает с разделом public, описание разрешается размещать только для наследников класса TAutoObject при создании серверов автоматизации COM.

8) Implementation (реализация, Rational Rose) – атрибут класса доступен любому другому классу в рамках текущего пакета.

9) Default access (Open ModelSphere) – условность моделирования, которая подразумевает, что в конкретном языке программирования, если не указан явно спецификатор доступа, то используется какой-то из них по умолчанию. Обычно это public или private.

4) Смоделируйте с помощью диаграммы классов принцип наследования.

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

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

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

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

Отметим факторы, усложняющие определение возможного эффекта от CASE-средств:

· широкое разнообразие качества и возможностей CASE-средств;

· разнообразие практики внедрения CASE-средств в различных организациях;

· отсутствие детальных метрик и данных для проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

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

Чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных “подводных камней” использования CASE-средств. Среди наиболее важных проблем выделяются следующие:

· достоверная оценка отдачи от инвестиций в CASE-средства затруднительна;

· внедрение CASE-средств может представлять собой достаточно длительный процесс и при этом возможно снижение продуктивности из-за необходимости осваивать новое;

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

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

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

· негативное отношение персонала к внедрению новой технологии.

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

1) Назовите элементы диаграммы вариантов использования.

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

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

Графически эктор изображается либо "человечком", подобным тем, которые мы рисовали в детстве, либо (если это возможно в case средстве) символом класса с соответствующим стереотипом, как показано на рисунке.

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

3) Классифицируйте отношения на диаграмме вариантов использования.

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

1) Назовите, какие разделы класса показывает графическая нотация.

Ответ: название класса и его родитель, поля и методы, свойства.

2) Объясните формат написания методов класса.

Ответ: После того как в модуле описан класс, необходимо описать реализацию всех его методов (если они есть) исключая абстрактные. В языках программирования высокого уровня встречается реализация методов двух видов: inline и outline. Суть первого в том, что мы реализуем метод сразу же после его описания, т.е. прямо в теле класса. При втором методе реализация находиться ниже описания класса в этом же модуле, как сделано в Delphi или вынесена в отдельный файл, как в C++. Inline реализация в стандарте object pascal отсутствует.

Чтобы компилятор понял, к какому классу относится конкретная подпрограмма, перед её названием указывается имя соответствующего класса и точка, т.е. используется уточнение имени. Например, реализуем один метод из листинга 9.5.

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

Доступ к полям и методам объекта происходит с помощью уточненных имен через точку, например: MyClass.Draw(). Кроме того, как и при работе с записями, допустимо использование оператора with, например: with MyClass do Draw().

Обратите внимание, что внутри методов класса обращения к полям и другим методам выполняются как к обычным переменным и подпрограммам без уточнения экземпляра объекта. Такое упрощение достигается путем использования в пределах метода псевдопеременной self (стандартный идентификатор, но его использование не является обязательным). Физически self представляет собой дополнительный неявный параметр, передаваемый в метод при вызове. Напоминаем, что методы класса хранятся в памяти отдельно от объектов и в единственном экземпляре, поэтому чтобы определить какой объект в данный момент должен обрабатывать метод и используется данная переменная. Чтобы пояснить сказанное, напишем отдельный метод SetActive, представив его в виде обычной процедуры (не метода класса) листинг 9.7. При этом нам придётся явно передать экземпляр объекта на обработку в параметре функции, пусть это будет self.

3) Прокомментируйте отношения между классами на диаграмме классов.

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями или связями в языке UML являются:

· Отношение наследования (обобщения generalization relationship)

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

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой в виде V на одном из ее концов. На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рис. 5.3). На данном рисунке изображены два класса: Класс_А и Класс_Б, при этом Класс_Б является источником, а Класс_А – клиентом этой зависимости.

Рисунок 11.30 – Графическое изображение отношения зависимости на диаграмме классов

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

· «access» – служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;

· «bind» – класс-клиент может использовать некоторый шаблон для своей последующей параметризации;

· «derive» – атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;

· «import» – открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;

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

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

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

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами – классом «Компания» и классом «Сотрудник» (рис. 11.31). Они связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс «Сотрудник», а вторым – класс «Компания».

Рисунок 11.31 – Изображение отношения бинарной ассоциации между классами

Тернарная ассоциация и ассоциации более высокой арности в общем случае называются N-арной ассоциацией. Такая ассоциация связывает некоторым отношением 3 и более классов, при этом один класс может участвовать в ассоциации более чем один раз. N-арная ассоциация графически обозначается ромбом, от которого ведут сплошные линии к символам классов данной ассоциации. Обычно линии проводятся от вершин ромба или от середины его сторон. Некоторый класс может быть присоединен к ромбу пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей N-арной ассоциации, а сама N-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация, в свою очередь, является классом с соответствующим обозначением в виде прямоугольника и является самостоятельным элементом языка UML – ассоциацией-классом (Association Class). N-арная ассоциация не может содержать символ агрегации ни для какой из своих ролей.

Рисунок 11.32 – Графическое изображение тернарной ассоциации между тремя классами

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

Так, для рассмотренного ранее примера (см. рис. 11.31) кратность "1" для класса «Компания» означает, что каждый сотрудник может работать только в одной компании. Кратность «1..*» для класса «Сотрудник» означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Заметим, что вместо кратности «1..*» записать только символ "*" нельзя, поскольку последний означает кратность «0..*». Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Но такая кратность вполне приемлема в других ситуациях, как это видно из рассмотренного выше примера (рис. 11.32).

Частным случаем отношения ассоциации является так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на тот факт, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается строка-ограничение «{хог}». Например, счет в банке может быть открыт для клиента, в качестве которого может выступать физическое лицо (индивидум) или компания, что изображается с помощью исключающей ассоциации (рис. 11.33).

Рисунок 11.33 – Изображение исключающей ассоциации между тремя классами

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

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

В качестве примера отношения агрегации рассмотрим взаимосвязь, которая имеет место между сущностью «Грузовой автомобиль» и такими компонентами, как «Двигатель», «Шасси», «Кабина», «Кузов». Нетрудно представить себе, что грузовой автомобиль состоит из двигателя, шасси, кабины и кузова.

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой «целое». Остальные классы являются его «частями» (рис. 11.34).

Рисунок 11.34 – Графическое изображение отношения агрегации в языке UML

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

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой «целое». Остальные классы являются его «частями» (рис. 11.35).

Рисунок 11.35 – Графическое изображение отношения композиции в языке UML

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

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

Рисунок 11.36 – Графическое изображение отношения обобщения в языке UML

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

Рисунок 11.37 – Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

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

· {complete} – означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может;

· {incomplete} – означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно восполнить их перечень не изменяя уже построенную диаграмму. Пример – диаграмма класса «Автомобиль», для которой указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего каталога;

· {disjoint} –запрет множественного наследования;

· {overlapping} – противоположность п.3, означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

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

Рисунок 11.38 – Вариант графического изображения отношения обобщения классов с использованием строки-ограничения

4) Преобразуйте приведённую диаграмму так, чтобы в ней присутствовал класс-родитель.

1) Чем различаются техническое задание и технический проект.

2) Опишите назначение и требования к техническому проекту.

3) Выявите и прокомментируйте неточности в приведённом участке технического проекта.

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

Заголовок раздела: основные технические характеристики изделия.

Описание: Разработанная программа должна обладать интуитивно понятным интерфейсом. На форме будут размещаться компоненты.)

1. Инструкции не хватает деталей, вряд ли пользователь решить свою задачу за два простых действия.

2. Раздел должен содержать: планируемое число форм, язык программирования и IDE, примерное число строк программного кода, используемый фреймворк, поддерживаемая ОС, требования к компьютеру.

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

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

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

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

3) Сформируйте перечень элементов с описанием для составления диаграмм состояний.

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

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

Рисунок 11.58 – Графическое изображение состояний на диаграмме состояний

Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния (рис. 11.58а). В противном случае в первой из них записывается имя состояния, а во второй – список некоторых внутренних действий или переходов в данном состоянии (рис. 11.58б). При этом под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, «истина» или «ложь»).

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

Список внутренних действий.Эта секция содержит перечень внутренних дейс

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...

Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...

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

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: