E3: Define architecture and design
Model the structure and behavior of the Dronology drone system in UML. Software Engineering 2026W, JKU.
10.11., 23:59One PDF on Moodle, uploaded by one team member. The slide says 2024, so confirm the year on Moodle.
taskWhat you hand in
- 1team
- Class diagram
Classes with attributes, operations and relationships including multiplicities. Start from the basic class diagram XML. - 2each
- Sequence diagrams
Two supporting use cases per member, all different across the team, so a team of 5 hands in 10. Never SC11; it's the lecture example. - 1team
- State-machine diagram
States of a UAV, tied to at least one of your sequence diagrams. Name the supporting use case(s) it is based on.
Grading: correct UML notation and nothing missing
Class 40%
Sequence 40%
State 20%
Every part is graded once for the whole team.
ruleConsistency
Every class, method and relationship in a sequence or state-machine diagram must exist in the class diagram. Not everything has to appear everywhere, but nothing may contradict.
Class diagram
⟶
UAV declares +takeOff()Sequence
a service calls
⟶
a service calls
takeOff()State machine
Ready to Flying on
Ready to Flying on
takeOffarchDronology layers
UIRouteCreationUAVRealTimeFlightViewUAVControlUAVVideoFeedMapsRouteAssignment
ServicesRouteManagementServiceFlightManagementServiceAreaMappingServiceRegistrationManagementService
CoreFlightRouteManagerFlightManagerAreaMappingCreatorFlightZoneManagerUAVRegistrationManagerRuntimeMonitoringUAVGCSMiddleware
Who may message whom
- UI talks only to Services
- Core talks only to Services
- UI never talks to Core directly
- Calls inside one layer are fine
- An actor can also be a component, like the UAV
Keep these colors for lifelines and classes so the layer is visible at a glance, as in the lecture examples.
cdClass diagram
| Association | objects are related | |
| Generalization | subclass is a superclass | |
| Realization | implements an interface | |
| Dependency | one uses another | |
| Aggregation | shared part, book on a shelf | |
| Composition | owned part, dies with the whole |
Multiplicity: 1 exactly one, 0..1 optional, 0..* any number, 1..* at least one.
What every class needs
FlightManagementService
+ victimFoundAlert()
10..*
UAV
- uavId
- status
- status
+ takeOff()
- Name,
- attributes,+ operations() - Relationships with multiplicity on both ends, including zero
- Classes for real entities or responsibilities, not every noun in the text
sdSequence diagram
The lecture's SC11 example, trimmed. Time runs downward.
| Lifeline | name: Class box with a dashed line down; actors as stick figures |
| Activation | narrow bar while the object is busy |
| Call | solid line, filled arrowhead |
| Return | dashed line, open arrowhead; answer every call |
| Create | dashed arrow into a new lifeline box |
| Destroy | ✕ at the end of the lifeline |
| Self call | arrow looping back to the same lifeline |
alt | if / else, mutually exclusive |
opt | runs only if the guard is true |
loop | repeats while the condition holds |
From use case to diagram
- Pick a supporting use case and read its main success scenario.
- Take the actors from Primary and Supporting actors.
- Map each system part to an architecture component: "DroneResponse" is a service, "video stream" is UI UAVVideoFeed.
- Turn each scenario step into a message, respecting the layers.
- Add every message as an operation on the receiving class in the class diagram.
stmUAV state machine
Illustrative. Use only states your chosen use cases support.
| State | condition over time, rounded box: Flying |
| Event | triggers a transition: takeOff |
| Guard | condition that allows it: [checks ok] |
| Effect | action on the transition: / clearRoute() |
| Start, end | filled dot, ringed dot |
An event is not a state. takeOff happens; Flying is where the UAV is. Model one UAV only, and match every event to an operation in the class diagram.
tooldiagrams.net
- Download the basic class diagram XML from Moodle.
- In diagrams.net: File, Import from, Device.
- Use only the UML/SysML shape library.
- File, Export as, PDF (all pages), then merge into one PDF.
Documentation
checkBefore you upload
- One class diagram with attributes, operations, relationships and multiplicities
- Two sequence diagrams per member, all use cases different, none of them SC11
- Messages respect the layers: UI and Core only talk through Services
- One UAV state machine, with its source use case(s) named
- Every message, event and class also appears in the class diagram
- One member uploads a single PDF to Moodle