Skip to content

ArtyomAfanasov/Software-Design

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 

Repository files navigation

CLI-Design

Домашние задания по курсу "Проектирование программного обеспечения" МатМеха СПбГУ.

1. CLI

Спроектировать простой интерпретатор командной строки, поддерживающий команды:

  • cat [FILE] — вывести на экран содержимое файла* ;
  • echo — вывести на экран свой аргумент (или арг* ументы);
  • wc [FILE] — вывести количество строк, слов и б* айт в файле;
  • pwd — распечатать текущую директорию;
  • exit — выйти из интерпретатора.

При этом должны поддерживаться:

  • одинарные и двойные кавычки (full and weak quoting);
  • окружение (команды вида “имя=значение”), оператор $;
  • вызов внешней программы, если введено что-то, чего интерпретатор не знает;
  • пайплайны (оператор «|»).

Примеры

:>echo "Hello, world!"

Hello, world!

:> FILE=example.txt

:> cat $FILE

Some example text

:> cat example.txt | wc

1 3 18

:> echo 123 | wc1 1 3

:> x=ex:> y=it:> $x$y

Решение должно удовлетворять следующим нефункциональным требованиям:

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

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

Обратите внимание, реализовывать этот проект не нужно!

Roguelike — это довольно популярный жанр компьютерных игр, названный в честь игры Rogue, 1980 года выхода. Характеризуется:

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

Примеры:

https://en.wikipedia.org/wiki/NetHack https://en.wikipedia.org/wiki/Angband_(video_game) https://en.wikipedia.org/wiki/Ancient_Domains_of_Mystery

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

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

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

Также требуется:

  • использовать шаблон «Стратегия» для поддержки различных поведений мобов (агрессивного, трусливого, пассивного);
  • использовать шаблон «Состояние» для динамического переключения поведения мобов
    • мобы с низким здоровьем должны переключаться в трусливый режим;
    • по мере восстановления здоровья переходить в исходный.
  • использовать шаблон «Абстрактная фабрика» для создания мобов и предметов на карте;
  • использовать шаблон «Команда» для поддержки взаимодействия с пользователем.

На что обратить внимание:

  • на разделение системы на компоненты — решения вида «большой клубок классов» будут оценены очень низко;
  • на прослеживаемость потока управления — должно быть понятно, с какого места запускается программа, кто кому передаёт управление;
  • что все имеют необходимые для своей работы данные — например, стратегии поведения мобов знают про карту;
  • на баланс детальности и читаемости диаграммы — она должна быть достаточно детальна, чтобы при реализации не требовалось принимать серьёзных архитектурных решений, но при этом обозрима. Например, старательно выписывать все методы классов и все поля не надо, но ключевые методы и поля всё-таки нужны.

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

About

SPBU homework on software design.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published