Особиста бугалтерія

1.   Спроектувати застосування, розділене на рівні, а також представити у вигляді UML діаграми(-ам) функціонал згідно з варіантом.

1.1.   Представити загальну архітектуру застосування, зв’язки між рівнями.

1.2.   Представити діаграми класів кожного рівня.

2.   Розробити застосування на мові C#, яка відповідає вимогам у варіанті. Відокремити рівні доступу до даних, бізнес логіки та представлення. Для демонстрації роботи використати WebAPI.

1.1.   Верхній рівень – представлення (UI), для взаємодії з користувачем. Реалізація – як окремий проект в рішенні (solution). UI повинен бути  ASP.NET WebAPI. При цьому на рівні UI повинні бути тільки операції взаємодії з користувачем (без бізнес логіки). UI повинен бути максимально простим, неперевантаженим великою кількістю операцій.

1.2.   Проміжний рівень – бізнес логіка, реалізована як бібліотека в рішенні. На цьому рівні реалізований основний функціонал застосування.

1.3.   Нижній рівень – бібліотека для доступу до даних. Використати Entity Framework code first. Доступ до даних організувати з використанням шаблонів проектування Repository та Unit of Work (UoF). Репозіторії надають доступ до набору сутностей (entities) певного типу.  UoW є точкою єдиного доступу до репозіторіїв та контексту Entity Framework.

3.   Шари взаємодіють між собою за наступним принципом: представлення використовує бізнес-логіку, бізнес-логіка – рівень доступу до даних. Для передачі даних крізь шари використовується технологія відображення  (mapping). Для зменшення залежностей між рівнями використати DI (Ninject чи Autofac).

4.   При необхідності для більшої ізоляції основних рівнів можуть вводитися додаткові рівні (наприклад, винесення Repository та UoW).

5.   Діаграма(-и) та вихідний код повинні відповідати основним принципам проектування: OOP, SOLID, Law of Demeter (LoD), DRY, YAGNI, KISS, cohesion – coupling, inheritance with caution.

6. Введені користувачем дані повинні валідуватися.

7. Передбачити обробку виняткових ситуацій.

8. Юніт тести повинні бути написані на NUnit чи XUnit з використанням DI і покривати мінімум 50% функціоналу.

Варіант 1

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

Базові операції додавання/ оновлення/ видалення/ отримання інформації по кожній сутності: категорії/ підкатегорії (будь-який рівень вкладеності), рахунки, типи операцій (доходи/ витрати)

- можливість роботи і з декількома типами рахунків доходів / витрат (наприклад, стипендія, зарплата, депозит / кредит в банку і т.д.)

- групування витрат по типах

- кожний дохід / витрата повинен бути прив'язаний до рахунку / типу

- можливість перерахувати кошти з одного рахунку на інший

- можливості аналізу по всіх рахунках / типах і по кожному окремо (дохід, витрата, баланс) за різні часові проміжки

- додатковий бал - реалізація спільних рахунків для різних користувачів (наприклад, витрати по кредиту за квартиру можуть проводиться з рахунків всіх членів сім'ї, які мають дохід)