Intro to Modelling and UML

Transcription

1 CSCD01 Engineering Large Software Systems Intro to Modelling and UML Joe Bettridge Winter 2018 With thanks to Anya Tafliovich and Steve Easterbrook

2 Getting Started So, you ve just started working on a large, highly complex, open source project, of which you have never seen before Where do you start? The documentation? Sorry it s really not great Wikipedia? There go three hours, but hey! Now you know the air-speed velocity differences between un-laden African and European Swallows Reverse engineer it! (Side note: Who has used MPL before?)

3 Reverse Engineer the code By doing this we want to: Recover valuable design information about the code Build a higher level view of components to gain better understanding Three key things to be looking for: 1. The Structure of the code Determine code dependencies Find out what are the components, and what has been coupled 2. The Behaviour of the code How does the code interact in it s current form Can be done using execution tracing 3. The Function of the code What is the purpose of this code in respect to the end user?

4 Why we should build models Modelling can guide your exploration It can help you understand what questions need to be asked It can inform you on key design decisions that were made It can help you uncover underlying problems that can later be corrected Modelling can help us check our understanding Reason about the model Does it have the properties we would expect? Why or why not? Models can be animated (many software suites available) to help gain a better understanding Modelling can hep us communicate Provides a useful abstraction to focus on the points that need to be communicated and still don t overwhelm with all the intermediary details Throw-away modelling? Modelling code isn t so much about getting a perfect answer The exercise of modelling derives insights which are more valuable than the model itself

5 Dealing with Complex problems Abstraction Ignore the details in order to see the bigger picture i.e., Treat similar objects as the same object by ignoring the differences You can later take a closer look at these differences, and identify why they exist Warning: Every time you abstract, you are making decisions over what is important, and what is not Decomposition Partition problem into different, more manageable pieces Look at each piece independently Warning: The parts are rarely as independent as we think We can also separate different concerns or views, and describe them independently. This is slightly different than decomposition, as it does not partition the problem space.

6 UML Unified Modelling Language What is UML? UML is a notation There is no modelling method associated with it Was intended as a design notation Has become an industry standard (we use it a lot.) Owned by IBM after the purchase of Rationale Software Standard meta-model ISO formal/ (A light and breezy 758 page read ) The Object Model Group manages the standard. (Yes it says OMG UML on the front of the standard book)

7 UML Unified Modelling Language The standardized meta-model splits the diagrams into two key areas: Behavioural and Structural Some important Diagrams we will use: Class Diagrams Package Diagram** Sequence Diagram Use Case diagrams State Machine Diagrams Activity Diagrams **Package diagram often is built into the class diagram to help organize it

8 Important Diagrams UML Class Diagrams Information about structural relationships between data items. Describes modular structure of the system. UML Package Diagrams Depicts the overall architectural dependencies between components within the system. Often shown as part of class diagram. UML Sequence Diagrams Shows individual scenario interactions between the user and system. Can also show sequencing of messages. UML Use Case Diagram Describes the users view of the system. Shows the way in which different actors can interact with the system. Identifies key requirements. UML State Machine Diagram Shows how system responds to events the dynamic behaviour of the system (event ordering, reachability, deadlock, etc.). UML Activity diagrams Depicts the business processes of the system. Used to identify concurrency and synchronization as well as dependencies between tasks.

9 What are classes? Classes describe a group of objects with: Similar properties / attributes Common behaviour / operations Common relationships to other objects Common meaning (Semantics) Example Employee: has a name, employee number, and department. Employees can be hired, fired, and can work on multiple projects Name (mandatory) Operations (optional) name : String employeenumber : int department : String Employee hire() : void fire() : void assignproject(projectid : int) : void Attributes (optional)

10 The Full Notation Attribute name Visibility: +,-,~,# Attribute Type Employee Class name + name : String [1] = Anonymous {readonly} + employeenumber : int [1] + department : String [*] # hire() : void # fire() : void ~ assignproject(projectid : int) : void Other properties Default value Multiplicity Operation name parameters Return value

11 Associations Objects do not exist in isolation. It is important to be able to represent relationships between them. Good thing for us, UML provides this ability. Relationships in UML represent the connections between different things. In UML there are different types of already defined relationships: Association Aggregation and composition Generalization / Realization Dependency A complete class diagram will show not just the classes, but also their associations with one another

12 Class association Full syntax (rarely used) Employee name : String employeenumber : int department : String hire() : void fire() : void assignproject(projectid : int) : void 1..* projectstaff Works On * projectlist name : String projectid : int Project startproject() : void completeproject() : void

13 Association Multiplicity This is the place to ask questions about the relationship: Can a campaign be managed without staff? If Yes, the association is optional at the Staff end (0..*) If no, then it is not optional one or more (1..*) If it must be managed by exactly one and only one one (1) What about the other end of the association? Does every member of staff have to manage exactly one campaign? If not, do they have to manage more than one? None? Some examples of specifying multiplicity: Optional (0 or 1) 0..1 Exactly One 1 or 1..1 Zero or More 0..* or * One or More 1..* A range of values 2..5

14 Navigability / Visibility

15 Bidirectional Association

16 Generalization and Aggregation

17 Generalization and Aggregation

18 Generalizations

19 Dependencies

20 Interfaces

21 Annotations

22 What UML Class diagrams can show

23 A practice example

24 Questions