Unified Modeling Language I.

Transcription

1 Unified Modeling Language I. Software engineering Szoftvertechnológia Dr. Balázs Simon BME, IIT

2 Outline Software engineering Modeling Unified Modeling Language (UML) UML Diagrams: Use Case Diagram Activity Diagram Component Diagram Deployment Diagram Dr. Balázs Simon, BME, IIT 2

3 Software engineering Dr. Balázs Simon, BME, IIT 3

4 Software engineering Software is everywhere: operating systems (Windows, Unix, Android, ios, etc.) office tools (Word, Excel, Chrome, Firefox, Photoshop, etc.) entertainment (YouTube, Facebook, etc.) everyday tools (hairdryer, washing machine, etc.) safety critical systems (cars, airplanes, rockets, nuclear power plants, robotic surgery, etc.) Software engineering is the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software Systems and software engineering - Vocabulary, ISO/IEC/IEEE std 24765:2010(E), Dr. Balázs Simon, BME, IIT 4

5 Why is software engineering hard? Software can be very large Windows 10: ~50 million lines of code the complete Google software codebase in 2015: ~2 billion lines of code, changes a day large software cannot be written by a single person The software industry is young (~50 years old) we have had roads, bridges and buildings for thousands of years we have widely accepted standards and prebuilt parts in the construction industry the software industry doesn t have the range of prebuilt standard components that other industries have Most of the software is custom built since there are no prebuilt components for everything constructing the software is a creative process most parts of a software are new and unproven, hence they must be tested but the inherent complexity of the software makes it hard to test Dr. Balázs Simon, BME, IIT 5

6 Why is software engineering hard? Custom built software is ordered by the users of the software, who don t know what they want users do not have the expertise of a software engineer, they can t specify exactly what they want users usually don t know what they really want until they can see it and try it out the time and money resources assigned to develop the software can easily run out due to the changing requirements estimating the time and money for a software development project is an art, not a science software engineers must prepare for changing requirements in advance Software engineer programmer software engineers design the software before they start coding in the design they have to take into account the needs of the users and the changing requirements software engineers must know which algorithm to apply and when experienced software engineers do things quicker and better, with less code and with fewer defects Dr. Balázs Simon, BME, IIT 6

7 Software development processes Software development consists of the following processes: Requirements analysis and specification: finding out what the user wants Design: designing the architecture, components and behavior of the software Implementation: developing and integrating the components Testing: systematic discovery and debugging of defects Delivery: installing the software for end users, education of users Maintenance: keeping the software running, fixing bugs These are not steps! These are processes that follow the development of the software throughout its entire life cycle! Software is usually developed in multiple iterations all of the above processes can be involved in each iteration, usually in the following order: Requirements Design Implementation Testing Delivery Maintenance each process may have a different importance depending on the iteration, e.g. requirements analysis is more important in the first iteration, while maintenance is more important in the later iterations Dr. Balázs Simon, BME, IIT 7

8 Unified Modeling Language (UML) Dr. Balázs Simon, BME, IIT 8

9 Modeling A model is a simplified reflection of reality A good model emphasizes essential details and omits irrelevant ones Example: Budapest underground map essential details: names of stops order of stops transfer points irrelevant details: streets distances between stops color of the tunnel Dr. Balázs Simon, BME, IIT 9

10 Other modeling examples Model of the solar system: essential details: mass, speed and distance of planets irrelevant details: e.g. atoms the planets are built of Wind tunnel model of a plane: essential details: shape, aerodynamics irrelevant details: e.g. number of seats, food served, pilot Ticket reservation model of a plane: essential details: number of seats, food served irrelevant details: e.g. shape, aerodynamics, pilot Dr. Balázs Simon, BME, IIT 10

11 Views The essential and irrelevant details depend on: what the model is used for who will read the model The more information the model has to cover the more complex it becomes Sometimes the same model is used for multiple purposes and viewed by different target audiences we can create many views of the same model each view shows only the relevant details for the given purpose and to the given target audience Example: same model with different views: Dr. Balázs Simon, BME, IIT 11

12 UML Unified Modeling Language Standard for modeling software systems standardized by Object Management Group (OMG) The UML standard defines multiple diagram types: each diagram provides one view of a model of a system The UML standard specifies: syntax: how the elements of a diagram (view) look like semantics: what the model shown in a diagram means Both the syntax and the semantics are important The semantics shown in different diagrams must be consistent with each other, otherwise, the underlying model is meaningless and useless Dr. Balázs Simon, BME, IIT 12

13 UML semantics There are two main important aspects of a model in UML: Structural semantics (static semantics): defines the meaning of model elements about individuals in the domain being modeled, which may be true at some specific point in time Behavioral semantics (dynamic semantics): defines the meaning of model elements that make statements about how individuals in the domain being modeled change over time Different diagram types show different aspects of a model Dr. Balázs Simon, BME, IIT 13

14 UML diagram types Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 14

15 Use Case Diagram Dr. Balázs Simon, BME, IIT 15

16 Use Case Diagram Requirements Design Implementation Testing Delivery Maintenance Captures the functional requirements of the system what the system is supposed to do and how the system is used models the users and the scope of the system simple enough for stakeholders to understand it Example: Pac-Man game Control Pac-Man Player View Maze Dr. Balázs Simon, BME, IIT 16

17 Use Case Diagram Actor Control Pac-Man Use case Player Association View Maze Actor: a role of a user that interacts with the system can be a person or an outside system (a physical user can interact with the system in multiple roles) Use case: represents a dialog between users and the system from the users point of view a specific sequence of actions and interactions between the actors and the system Association: connects an actor with a use case he/she/it is involved in Dr. Balázs Simon, BME, IIT 17

18 Use case description example: Buy item Buy item Customer Cashier Use case: Buy item Actors: Customer, Cashier Main Success Scenario: 1. The Customer picks the item 2. The Customer hands the item to the Cashier 3. The Cashier records the item 4. The Cashier asks for money from the Customer 5. The Customer pays the amount to the Cashier 6. The Cashier gives the item and the receipt to the Customer Alternative 5.A: 5.A.1. The Customer has not enough money 5.A.2. The Customer leaves empty handed Dr. Balázs Simon, BME, IIT 18

19 Use Case Diagram: Relationships Between an actor and a use case: Association: connects an actor with a use case he/she/it is involved in Between actors: Generalization: the special actor is a kind of general actor the special actor can do all the use cases the general actor can Between use cases: Generalization: the special use case is a kind of general use case the special use case makes the behavior of the general use case more specific <<extend>>: the extending use case provides some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more extended use cases at their extension points <<include>>: the behavior of the included use case is inserted at some point into the including use case Dr. Balázs Simon, BME, IIT 19

20 Relationship examples Association Login Generalization Customer Login via Google Login via Facebook Include Generalization Place order Modify order <<extend>> <<include>> Extend Make payment Manage user privileges Dr. Balázs Simon, BME, IIT Admin 20

21 Use case description template (not defined in UML) Title: goal the use case is trying to satisfy usually: verb + noun Actors: the participants of the use case Main Success Scenario: numbered list of steps step: <a simple statement of the interaction between the actor and the system> Alternate Scenarios: separately numbered lists, one per Alternative Alternative: <a condition that results in different interactions from.. the main success scenario> an alternative deviating from main step 7 is numbered 7.A., etc. Dr. Balázs Simon, BME, IIT 21

22 Use case description example: Buy item Buy item Customer Cashier Use case: Buy item Actors: Customer, Cashier Main Success Scenario: 1. The Customer picks the item 2. The Customer hands the item to the Cashier 3. The Cashier records the item 4. The Cashier asks for money from the Customer 5. The Customer pays the amount to the Cashier 6. The Cashier gives the item and the receipt to the Customer Alternative 5.A: 5.A.1. The Customer has not enough money 5.A.2. The Customer leaves empty handed Dr. Balázs Simon, BME, IIT 22

23 More detailed use case description There is no standard way to write the content of a use case The template from the previous slides shows the most common form But there can be many more fields in a use case description (Cockburn s fully dressed use case): Title, Primary Actor, Goal in Context, Scope, Level, Stakeholders and Interests, Pre-conditions, Post-conditions (Minimal Guarantees, Success Guarantees), Trigger, Main Success Scenario, Extensions, Technology & Data Variations List Possible other fields: Unique identifier, Frequency of use, Exceptional cases, Covered requirements Dr. Balázs Simon, BME, IIT 23

24 Use Case Diagram: System boundary box (optional) System boundary box: a box that sets a system scope to use cases all use cases outside the box are outside the scope of that system System name Webshop Login Login via Google Customer Login via Facebook Place order <<include>> <<extend>> Make payment Modify order System boundary Manage user privileges Admin Dr. Balázs Simon, BME, IIT 24

25 Use Case Diagram: Package (optional) Package: allows putting different elements in a group Package name Order management Place order <<extend>> <<include>> Make payment Customer Modify order Package User management Login via Google Login Login via Facebook Manage user privileges Admin Dr. Balázs Simon, BME, IIT 25

26 UML diagram types Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 26

27 Activity Diagram Dr. Balázs Simon, BME, IIT 27

28 Activity Diagram Requirements Design Implementation Testing Delivery Maintenance Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency Activity diagrams are typically used for modeling: the behavior captured by a single use case a business process or workflow between users and the system the steps of an algorithm Activity diagrams provide a formal way of describing functional requirements as workflows Activity diagrams can be developed in various levels of detail e.g. first at a high abstraction level, then at a lower abstraction level by refining the steps Dr. Balázs Simon, BME, IIT 28

29 Reminder from earlier: Buy item use case Buy item Customer Cashier Use case: Buy item Actors: Customer, Cashier Main Success Scenario: 1. The Customer picks the item 2. The Customer hands the item to the Cashier 3. The Cashier records the item 4. The Cashier asks for money from the Customer 5. The Customer pays the amount to the Cashier 6. The Cashier gives the item and the receipt to the Customer Alternative 5.A: 5.A.1. The Customer has not enough money 5.A.2. The Customer leaves empty handed Dr. Balázs Simon, BME, IIT 29

30 Activity Diagram example: Buy item use case I. Customer Cashier Partition name Initial node Pick an item Activity Partition Partition Hand item over Control flow item Object Record item Object flow Ask money [ not enough money ] [ has enough money ] Leave empty handed Pay money money Accept money Dr. Balázs Simon, BME, IIT 30 Give item and receipt

31 Activity Diagram example: Pick an item Buy item use case II. Hand item over item Record item Guard condition Decision node [ not enough money ] [ has enough money ] Ask money Leave empty handed Pay money Final node item and receipt money Accept money Give item and receipt Leave with item and receipt Final node Dr. Balázs Simon, BME, IIT 31

32 Activity Diagram Activity: used to model the individual steps in the behavior specified by the Activity Diagram Initial node: acts as a starting point for executing an activity has no incoming edges an activity can have multiple initial nodes: in this case several flows start in this activity Control flow: directed connection between two activities (source and target) designates flow of execution: the target activity is started when the source activity is completed Final node: at the final node the execution flow is stopped Decision: chooses between outgoing control flows based on their guard conditions at most one outgoing flow is executed Guard condition: condition attached to a control flow the flow can only become active if the guard condition evaluates to true Dr. Balázs Simon, BME, IIT 32

33 Activity Diagram Partition: a user (role) or part of the system along a dimension drawn as a swimlane activities inside the swimlane are performed by the corresponding user (role) or system part partitions can be hierarchic: they can have subpartitions Partition name: name of the user (role) or part of the system corresponding to the given partition shown in the header of the swimlane notation Object: represents data that can be passed between activities Object flow: carries data between activities Dr. Balázs Simon, BME, IIT 33

34 Activity Diagram: decision and merge Decision: chooses between outgoing flows at most one outgoing flow is executed based on the guard conditions Merge: brings together multiple flows without synchronization if multiple incoming flows are active, merge is executed multiple times Guard condition [ item in stock ] Retrieve item Merge Select item Decision Send item Make item [ out of stock ] Dr. Balázs Simon, BME, IIT Guard condition 34

35 Activity Diagram: fork and join Fork: flow is split into multiple concurrent (parallel) flows Join: synchronizes (awaits) multiple flows by default all incoming flows must complete so that the Join can be executed (this behavior can be overridden through a join expression) Fork Reserve flight Join Select destination Select departure and return time Reserve hotel Print reservations Rent a car Dr. Balázs Simon, BME, IIT 35

36 Activity Diagram: call activity Call activity: a call activity invokes another activity the behavior of the invoked activity can also be described by an Activity Diagram hence, activities can be nested within each other Activity Diagrams can show different levels of detail Call activity Take time off work Make travel reservations Travel Dr. Balázs Simon, BME, IIT 36

37 Activity Diagram: final nodes Two kinds of final node: Activity final node: ends the entire behavior shown in the Activity Diagram, all the flows are stopped Flow final node: only the given flow is stopped, other flows in the diagram continue to execute Initial node Activity final node Make rocket part Build part into rocket [ rocket complete ] Launch rocket [ no more parts to be built ] [ parts missing ] [ more parts to be built ] Flow final node Dr. Balázs Simon, BME, IIT 37

38 Activity Diagram: signals Activities can also be started by events (signals) instead of an initial node Events can be accepted at the beginning or even in the middle of a behavior described by an Activity Diagram Actions related to signals: Accept event action: waits for an event (signal) to occur, and starts a new flow when it does Send signal action: sends a signal, which can be accepted by an accept event action Accept event action Accept event action Receive order Process order Request payment Payment confirmed Ship order Send signal action Dr. Balázs Simon, BME, IIT 38

39 Activity Diagram: time events Accept time event action: starts a flow in the activity diagram at a definite point in time Examples: End of month Create monthly report Accept time event action Wait 2 hours Make ice cream Put the ice cream into the freezer Eat the ice cream Accept time event action Dr. Balázs Simon, BME, IIT 39

40 UML diagram types Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 40

41 Component Diagram Dr. Balázs Simon, BME, IIT 41

42 Component Diagram Requirements Design Implementation Testing Delivery Maintenance A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. (Szyperski) The Component Diagram shows the components of a system and the connections between them The Component Diagram is usually used during design, but can be successively refined in deployment and runtime Dr. Balázs Simon, BME, IIT 42

43 Component Diagram example: Mobile+web application An overview Component Diagram shows components related by dependencies Dependency: A depends on B means that if B changes then the change may affect A, too The kind of the dependency is not specified Lack of dependency where there are no dependency arrows <<component>> Mobile client Component <<component>> Business logic <<component>> Data <<component>> Website Dependency (Website depends on Business logic) Dr. Balázs Simon, BME, IIT 43

44 Component notation Three possible notations, they are equivalent: rectangle with icon rectangle with component keyword (stereotype) rectangle with component keyword (stereotype) and icon Icon Stereotype Stereotype Icon Website <<component>> Website <<component>> Website Dr. Balázs Simon, BME, IIT 44

45 Component Diagram example: Computer A more detailed Component Diagram shows components with their provided and required interfaces and the connections between them Component Provided interface <<component>> Business logic Interface name Required interface <<component>> Mobile client IClient IWeb <<component>> Website IData <<component>> Data Dr. Balázs Simon, BME, IIT 45

46 Component Diagram example: Computer Provided and required interfaces can be wired through dependencies Component <<component>> Business logic Provided interface Required interface IClient IClient IWeb IData Dependency Interface name IData <<component>> Mobile client IWeb <<component>> Website <<component>> Data Dr. Balázs Simon, BME, IIT 46

47 Provided and required interfaces Three possible notations, they are equivalent: component with lollipops and sockets component with compartments component with realizations and dependencies Provided interface (lollipop) IClient <<component>> Business logic IData Required interface (socket) Dr. Balázs Simon, BME, IIT IWeb Provided interfaces compartment <<component>> Business logic provided interfaces IWeb IClient required interfaces IData Required interfaces compartment <<interface>> IWeb <<component>> Business logic <<use>> <<interface>> IData Interface (see later...) <<interface>> IClient Realization Dependency 47

48 Composite component A composite component is implemented by other components Externally provided and required interfaces are exposed through ports Delegation connectors connect externally provided and required interfaces to internal components that realize or require them Port IWeb IWeb <<component>> Game logic <<component>> Business logic internal structure ISaveLoad IData Port IData IClient Delegation connector IClient <<component>> Save and load Delegation connector Dr. Balázs Simon, BME, IIT 48

49 UML diagram types Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 49

50 Deployment Diagram Dr. Balázs Simon, BME, IIT 50

51 Deployment Diagram Requirements Design Implementation Testing Delivery Maintenance The Deployment Diagram specifies constructs that can be used to define the execution architecture of a system and the assignment of software artifacts to system elements Deployment Diagrams can be used to model the hardware and software topology of the system The Deployment Diagram is usually used during delivery for planning the deployment architecture Dr. Balázs Simon, BME, IIT 51

52 Deployment Diagram example: Mobile+Web application The architecture of the system is shown as nodes and communication paths between them Node Communication path :Android :IBM server :MySQL server Dr. Balázs Simon, BME, IIT 52

53 Artifacts example: Mobile+web application An artifact represents some (usually reifiable) item of information that is used or produced by a software development process or by operation of a system e.g. executable file, script, database table, document, etc. An artifact can be a manifestation of a component <<artifact>> client.apk <<manifest>> <<component>> Mobile client Component Artifact <<component>> Business logic <<component>> Data Manifestation <<artifact>> Website.jar <<component>> Website <<manifest>> <<artifact>> Business.jar <<manifest>> <<artifact>> Data.sql <<manifest>> Dr. Balázs Simon, BME, IIT 53

54 Deployment Diagram example: Mobile+Web application Artifacts can be deployed to nodes Dependencies can also be shown between artifacts Node Communication path :Android <<artifact>> client.apk :IBM server <<artifact>> Website.jar :MySQL server <<artifact>> Data.sql <<artifact>> Business.jar Artifact Dependency Dr. Balázs Simon, BME, IIT 54

55 Deployment Diagram example: Mobile+Web application The deployed artifacts can also be assigned to nodes using dashed arrows with deploy keyword (stereotype) (this diagram is equivalent with the one on the previous slide) Node Communication path :Android :IBM server :MySQL server Deployment <<deploy>> <<deploy>> <<deploy>> <<deploy>> <<artifact>> client.apk <<artifact>> Website.jar <<artifact>> Business.jar <<artifact>> Data.sql Artifact Dependency Dr. Balázs Simon, BME, IIT 55

56 UML diagram types Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 56

57 Summary Dr. Balázs Simon, BME, IIT 57

58 Summary Software engineering Modeling Unified Modeling Language (UML) UML Diagrams: Use Case Diagram Activity Diagram Component Diagram Deployment Diagram Dr. Balázs Simon, BME, IIT 58

59 UML diagram types Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 59