Enabling Programmes to Deliver UML Dr Kevin Howard khoward@sula.co.uk Tel:07534 679944
Why use the UML for Systems Engineering ? UML (Unified Modelling Language) OMG Industr y standar d UML For Systems?
Enabling Programmes to Deliver Elements of the UML
Elements of The UML > Actors > Use cases – And use case Diagrams > Classes – And class diagrams > Sequence Diagrams > State Diagrams > Objects – And structured class diagrams
Actors Defines elements that interface with the system Actor name external system human user Is described by > a name > a textual description (role, missions,…) environment
Use Case > A use case – A coherent unit of functionality – Provided by the system or a sub-system – To fulfil specific needs of an actor or actors use case activation is controlled by events Use case name Actor name
Structure of use cases – a name – a textual description • pre conditions • events that trigger the use case Use case name • main and alternative scenarios • exception Description in • post conditions UML tool – requirements Defined in a requirement management tool
Use Case Diagram > Use Cases connect together – To tell a story of system behaviour and use – Use Case Diagrams show relationships • and dependencies Operation view Driver Route Proving Area Clearance Mark Route Route «include» Clearance Operator «include» Neutralisation Communication relationship «include» Mark Mines «include» «extend» System Detect Mines Mine border Location «include» «include» «include» «include» Ground Record Classification
Use Case Relationships TELL A STORY! Extend : Additional behaviour non-essential to the completion of primary use Association : communication path between an actor and use case Request catalogue Place order Extension use case (additional behaviour) Additional behaviour into Arrange payment the base use case actor generalisation generalisation : A more universal representation of specific use Include : Additional behaviour Arrange credit necessary to perform primary use Inherits from "arrange payment" use case and adds specific features
Class – An abstraction – Describes a group of objects with common: • Properties (attributes) • Services (operations) • Relationships Bicycle Class name Speed attributes Vibration Transport() Operations Reduce_Vibration()
System or component A component A single class that needs no further partitioning Can be implemented from the description Sub-systems A singularity of a class and a package A System A component A System
Class Adopt a naming convention Model properties (e.g. weight, acceleration, fuel Class name consumption) attribute1 Model calculated information (e.g. acceleration = attribute2 F(weight, engine torque, transmission ratio,...)) or static information may have default values operation1() represent budget of the system attributes operation2() Model behaviour of the class (e.g. start, accelerate, stop, turn) Associated with the functional requirements
Class Diagram {constraint} Keyboard Subclass (child) Mouse Generalisation Input_Device Superclass (parent) Connection between classes Association Window Parts Point Panel Header Aggregation Scrollbar Aggregate Polygon Composite or structured class Parts Composition is a form of aggregation with strong ownership and coincident lifetime of part with the whole
Class Diagram Engine Power Ouput Attitude Sensor Attitude Sensor RPM Gear * Altitude Sensor Aircraft Position 1 X Position Autopilot Y Position Set Position Direction Sensor Wind Speed Sensor Speed Calibration Constant Value Calibrate
Association – It is an association that is also a class – It defines a set of features that belongs to the relationship itself and not to any of the classes Person Company Job Salary
Sequence Diagram > An interaction between actors, the system or the sub-systems – chronological order – it shows the set of messages they send to each other Communication between objects – expects a response The System Actor name Actor name This is a comment that message(data) explains the first sequence service1(data) Time constraint Service2() This is a comment that service3(data) explains the second sequence service4(data)
A Sequence Diagram Detect Mines Instance Instance Instance Instance Instance Instance :GPR :Fusion :IR :Metal :Position :Display Description Mine Ground Trigger mine detection. mine present Report detection Report Confirm position Request Position time Position report Position report Environment update State request State assessment Ground state Ground report Ground report Assess report Assess Request coroboration Coroborate Request coroboration Coroborate Coroborated Coroborated Declare detection Detection
State Diagram > Models the dynamic behaviour of a class – Primarily event-driven idle onHook working offHook Ready For each state the connecting services provided connected by the system are defined
State Diagram On Event Y get State 1 and perform Event Y / Action4 Action4 State 1 Action1 is performed entry/Action1 On Event X, perform Action2 event X/ Action2 exit/ Action 3 On Event Z perform Action3 and Event Z leave State1 Based upon Rational Unified Process
System States Example Availability Unavailable Unavailable /Operational ::In Maintenance ::In Maintenance ::In Maintenance /F ault Available Available /pac k /F ault ::Transporting ::Transporting ::Transporting ::Stored ::Stored ::Stored /unpack /P ac k /Unpack /M obile /Operational /S tatic ::Standby ::Standby ::Standby /S tart /S tow ::In Transit ::In Transit ::In Transit /S top /Configure /Configure /S tow ::Operating ::Operating ::Operating ::Training ::Training ::Training
Package > Packages – Groups the model elements within a boundary – May include other packages > Defines responsibilities – A framework for information management – Support permission and configuration control The package can have further description by using a stereotype <<stereotype>> NAME
Package ACM <<Logical Component>> <<Logical Component>> CPDLCEquipedAircraft ACMManager 1 * <<Logical Component>> 1 CPDLCConnection *
Package example Baseline Protocol BTID system ::LowLevel BTID system ::LowLevel Protocol Protocol ::Non-realtim e processing ::Non-realtim e processing 1 1 1 ::Real tim e control ::Real tim e control ::Real tim e control 1 1 1 1 ::User Interface ::User Interface Antenna m m W m m W RF_IF 1 2 1 1 ::Interrogate Antenna ::Interrogate Antenna 1 ::Transm itter ::Transm itter ::Transm itter 1 1 1 1 ::IF Processing ::IF Processing 1 1 1 2 1 1 1 1 1 1 ::Transpond Antenna ::Transpond Antenna ::Receiver ::Receiver ::Receiver
Interfaces UML Interface management Primarily for software Expected and provided functionality …Not very good for systems - its only addresses functionality
Structured Class class TransportationSystem abs:ABSBrakeSystem :WheelAssembly O..4 magneticPluse: Energy loadForce:Mech av1: wheel1:Wheel SpeedSensor pFrequency force:Mech ecu1:Electronic Control Unit tire1:Tire <<control>> force: valvePosition:Signal HydraulicFluid whCyl1: mv1: ModulatorValve WheelCylinder loadForce:Mech pPositionSignal pHydraulicOut pHydraulic pHydraulicIn pHydraulicIn pVerticalLoad
Layered Interface Specification Information Layer Problem Logical Solution Codification Layer Assurance Protocol Solution Management Layer Security Carrier Layer Transport Physical Solution Solution Physical Layer
Stereotype <<Interface 1>> Interface 1 Connector M Connector F <<Interface 1>> <<Interface 1>> <<Interface 1>> Owns <<Signal 2>> <<Signal 1>> Owns Signal Signal <<Signal 2>> Event 1 <<Signal 1>> Attributes Owns Event 2 Frequency Attributes . Volts Frequency Amps Event 3 Volts Amps Operations Codify Operations Encrypt External Codify Decrypt Encrypt Provided Service Decrypt External Required Service . Provided Service Provided Service Required Service . API Provided Service State State
Modelling System A System B Provided Service Required Service Required Service Provided Service <<Interface 1>> . . Provided Service Required Service Connector M Connector F
Recommend
More recommend