The course learning objective is to understand modern software design and practice design and modeling methods in a team project

Official course page https://www.hse.ru/en/ma/se/courses/646474885.html

• Course topics
  • Module 1
  • Module 2
• Team project
• Course practice
• Course grading
• Books
• Resources
• Contacts

Project 1 and Project 2 are team projects. Expect to work on each of the projects in as a team of 3-5 persons.

First project is about developing software requirements and requirements modeling using DDD. Main activities are product requirements analysis, feature and use case decomposition, define project scope. As a result for the project, expect to detail 3-4 use cases or 5-6 user or job stories in 2-3 features for a medium sized project.

What you will learn:

• requirements analysis: use cases, job/user stories, data flow models, functional decomposition
• DDD: ubiquitous language, domain contexts, concept/noun phrase extraction, domain modeling, responsibility analysis, class design: service, entity, aggregate, value object, and others
• UML2: class diagrams, use cases, activities and interaction design
• ERD: data design, Entity-Relationship modeling

In this project you decompose an analysis model of the system into services (microservices), develop APIs and architect an application along microservices architecture (MSA). You apply architectural patterns, RDBMS and NoSQL data design and data access patterns, SOLID and OOD design patterns to microservices. As a result you will have a design model of a microservices application, that implements requirements developed in Project 1. Expect to design 3-5 communicating microservices.ачи первого задания.

What you will learn:

• DDD: decompose and integrate bounded context, develop a design model for services and resources
• MSA: OpenAPI for RESTful web services, hexagonal architecture, SOLID, GoF design patterns, Backend-for-Frontend and other patterns
• Data: ER data design, schema-on-read method, Hub-and-Spoke data architecture, NoSql data models
• UML2: component diagram, data-flow modeling and others

Students analyse and design a microservices or monolithic application in teams of 3-4 persons. This includes elaboration of the initial problem, requirements specification, architectural and detailed design using modeling languages.

Students may switch teams once during each Module. Teams may switch project topics before Module 2 starts.

In companion to the team projects, students solve software design problems and study design of existing open source systems.

Individual assignments also include writing a short essay on a research topic in software design from a list provided by instructors.

Module grade = 0.1 * Attendance + 0.45 * Team Project + 0.1 * Essay + 0.35 * Practice

Module grade cannot exceed 10. The final grade is an average of Module 1 and Module 2 grades rounded up.

Attendance is 0..10 and covers lectures and practice sessions, 10 is all but one week of absence.

Team Project is 0..12 is proportional to project score achieved by the team, score includes completed project assignments during the practice and the final project report in each Module. Score 9 is given for a project well-done, a greater score may be achieved for larger projects, more detailed solutions or more complex project topics.

Essay is {0, 5, 10}.

Practice is 0..10 is proportional to individual activity during the practice sessions, including reporting for the team, reports at the blackboard etc.

1. Newman, S. Building microservices. - O'Reilly Media, Inc. - 2021.
2. Vernon, V. Implementing domain-driven design. - Addison-Wesley. - 2013.
3. Freeman, E., & Robson, E. Head First Design Patterns. - O'Reilly Media. - 2020.
4. Sommerville, I. Software Engineering 10th ed. - PEarson Higher Ed. - 2015.

1. Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
2. Getting Started with Domain-Driven Design

Additional sources:

1. Notation summary for UML 2 uml2-notation.zip
2. Meyer B., Object-oriented software construction 2nd Ed. - Pearson. - 2005
3. Microsoft. Azure application architecture fundamentals, [https://docs.microsoft.com/en-us/azure/architecture/guide/| at microsoft.com]]
4. UML 2.5.1 Specification at OMG. (http://www.omg.org/spec/UML/)

Classical papers on software design:

1. (discussion) P. Ralph, R. Mohanani. Is Requirements Engineering Inherently Counterproductive?
2. N. Wirth. Program Development by Stepwise Refinement. (http://www.inf.ethz.ch/personal/wirth/Articles/StepwiseRefinement.pdf)
3. D. Parnas. On the Criteria to be used in Decomposing System into Modules (http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)
4. D. Garlan, M. Shaw. An Introduction to Software Architecture (http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf)
5. Kent Beck, Ward Cunningham. A Laboratory For Teaching Object-Oriented Thinking / OOPSLA89 (http://c2.com/doc/oopsla89/paper.html)
6. Doug Rosenberg, Kendall Scott, The ICONIX Process, (http://www.informit.com/articles/printerfriendly.aspx?p=167902)
7. B. Liskov. Programming with abstract data types
8. Friedrich Steimann, Philip Mayer. Patterns of Interface-Based Programming
9. Rebecca Wirfs-Brock, Object-oriented design. A responsibility-driven approach
10. Robert C. Sharblet, Samuel S. Cohen. The object-oriented brewery. A comparison of two object-oriented development methods
11. P. Krutchen. Architectural Blueprints—The “4+1” View Model of Software Architecture, (http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf)
12. IEEE Recommended practice for architectural description of software intensive systems, (http://www.win.tue.nl/~wsinmak/Education/2II45/software-architecture-std1471-2000.pdf)
13. M. Fowler. Who need an Achitect?, http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
14. D. Greer, Interactive Application Architecture, http://aspiringcraftsman.com/2007/08/25/interactive-application-architecture/
15. Frank DeRemer, Hans Kron. PROGRAMMING-IN-THE LARGE VERSUS PROGRAMMING-IN-THE-SMALL (google it)
16. The Agile Method and Other Fairy Tales (google it)
17. A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT (google it)
18. Edward V. Berard. Be Careful With “Use Cases”
19. (beware!)Chidamber Kemerer Metrics Suite. A Measurement Theory Perspective
20. McCabe. A complexity measure

Design patterns:

1. Antipatterns Wiki, http://c2.com/cgi/wiki?AntiPatternsCatalog
2. Error handling patterns, http://c2.com/cgi/wiki?ExceptionPatterns
3. Microservices patterns, https://microservices.io
4. GoF. Design Patterns: elements of reusable object-oriented software
5. DoubleDispatch and DoubleDispatchExample, https://wiki.c2.com/?DoubleDispatch
6. Jenifer Tidwell, Designing Interfaces
7. Scott Ambler, Process Patterns
8. Martin Fowler, Analysis Patterns
9. Martin Fowler, Patterns of Enterprise Application Architecture
10. G. Hohpe, Enterprise Integration Patterns
11. D. Greer, Interactive Application Architecture, http://aspiringcraftsman.com/2007/08/25/interactive-application-architecture/
12. Pattern-Oriented Software Architecture (несколько томов), http://www.cs.wustl.edu/~schmidt/POSA/
13. C++ Idioms, http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms
14. Linda Rising - Patterns Almanac 2000, http://www.smallmemory.com/almanac/

Prof. Anton S. Khritankov, Ph.D.