Analysis classes¶
The first software structure derived from the use cases: what the user touches (boundary), what coordinates (control) and what holds information (entity).
Source¶
@startuml
!theme plain
hide empty members
skinparam linetype polyline
top to bottom direction
class CheckoutScreen <<boundary>>
class CreateOrderController <<control>>
class Order <<entity>>
class OrderLine <<entity>>
class Product <<entity>>
class Customer <<entity>>
CheckoutScreen --> CreateOrderController
CreateOrderController --> Order
CreateOrderController --> Product
CreateOrderController --> Customer
Order *-- OrderLine
OrderLine --> Product
@enduml
Stereotypes¶
| Stereotype | Role |
|---|---|
<<boundary>> |
Interface between the actor and the system: a screen, an endpoint |
<<control>> |
Coordination of one use case |
<<entity>> |
Domain information, taken from the domain model |
Conventions¶
- Arrows point down, from boundary to control to entity.
- One control class per use case.
- Entity names are the ones in the domain model.
In Pro
Pro adds one analysis collaboration per use case, with numbered messages, and the analysis card that links it to the requirements and the design.