System architecture is a reflection of organization hierarchy.
Modelling
Used to handle complexity: lots of functionality, interactions (possible concurrent) and constraints.
Identifying components: reuse existing libraries/resources.
Abstraction levels have been raised over the years to try reduce complexity?
Representations/models/visuals are good if:
- You know the notation: syntax and keys
- You understand the context: vocabulary
- The purpose is clear
Visual representations should:
- Be unambiguous
- Clearly state what they represent
- Identify who they target
Representations are a model of reality. All models are wrong; some models are useful.
Class Diagrams
Every organization has their own business rules, their own vocabulary, and concepts (with relations to each other).
Domain concepts:
- Will be logically manipulated
- Will be stored in the database
- Should be responsible for their states/logic (encapsulation)
Class diagrams are a static representation (not business logic). The semantics of all elements must be clear and fully unambiguous.
The terminology used by the client should also be used by in the code.
Tactics
Architecture tactics:
- Relate one quality attribute to one architectural decision
- Tackle one concern at a time
Architecture style and design patterns:
- Are reusable, off-the-shelf, conceptual solutions
- Must be taken into account throughout the whole project
- May encompass multiple tactics
These shape the system design early on:
- Architecture drift can occur faster than you expect: taking the easiest path in the short term may cause issues later
- Re-engineering may be painful or impractical
Documentation
README files should state:
- Context/objectives
- Authors, contributors, version, other pointers
- Deployment procedures, testing, dependencies
- Describe content and refer to licensing
Wiki pages:
- External analysis (e.g. wireframe, architecture, decisions)
- Manual tests (and results), DoXs, action points
- Organized into categories
- Should have a landing page
- Should be updated
- See ADR, MADR
Stories as Use-Case Scenarios
From a story it is difficult to:
- Put users in relation with features
- Identify system boundaries (e.g. interfaces, APIs)
- Evaluate what domain entities are created/read/updated
- Understand business/logical processes (e.g. controls)
- Understand entity properties
Robustness diagrams:
웃 ------ |-o -----> ⥀ ----- o̲ ◆-----> o
actor boundary control entity property
- Boundary: interface
- Control: process/method of the interface
OR:
- Entity/boundary/control = MVC
Example: As a user, I want to search for events by their types, location or date so that I will be able to subscribe to them later.
user event interface subscribe
웃 -------- o-| -------> ⥀
| |
| |
v event
search ⥀ ---------- o ◆--- o location
◆ ◆
| \
date \
type
Partial scenarios
As a user, I want to do x so that value: the value does not need to be implemented in the story, the story acts as justification for the task.
Wireframes
- Identify details in forms
- Domain concepts and attributes
- Allows discussion of general layout
c.f. robustness diagrams:
- Controls: what will be supplied between subprocesses
- Entities:refine semantics of model elements
- Transitions: from screen to screen