Unified Modeling Language - Lecture Slides | CMSC 435, Study notes of Software Engineering

Download Unified Modeling Language - Lecture Slides | CMSC 435 and more Study notes Software Engineering in PDF only on Docsity! cmsc435 - 1 UML cmsc435 - 2 Objectives ● Documenting user requirements using the UML notation ● Description of the various components of UML ● The use of Use Cases cmsc435 - 3 Unified Modeling Language ● The UML is an international industry standard graphical notation for describing software analysis and designs. ● UML is a modeling language or graphical/diagrammatic notation for object-oriented programming – a way to express the “blueprints” of your system. Within UML, there are several types of diagrams:
Use case
Class
Sequence
State
Activity diagram cmsc435 - 4 Use cases ● A scenario is a sequence of actions that illustrates behavior. A scenario may be used to illustrate an interaction or the execution of a use case instance. ● Use cases are used to describe scenarios.
A use case is a specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors ● A set of scenarios makes up a use case cmsc435 - 9 Identifying the use cases ● What functions will the actor want from the system? ● Does the system store information? What actors will create, read, update or delete this information? ● Does the system need to notify an actor about chances in the internal state? ● Are there any external events the system must know about? What actor informs the system of those events? cmsc435 - 10 Use case diagram ● Only actions within the system boundary need to be modeled and built as part of the software Use case Actor System boundary cmsc435 - 11 Use case flow of events X Flow-of-Events for the <name> Use Case X.1 Preconditions. What needs to happen (in another use case) before this use case can start? What state must the system be in before the use case? X.2 Main Flow. The main flow is a series of declarative steps. X.3 Sub-flows. Sub-flows break down the main flow and other sub-flows to improve document readability. X.4 Alternative Flows. The alternative flows define exceptional behavior that can interrupt the normal flow. Often alternative flows indicate what is to be done under error conditions. To determine alternative flows, ask yourself, “What could possibly go wrong?” for each of the actions in the main flow and the sub-flows. Note: X is a unique identifier for each use case. cmsc435 - 12 UC8 Flow of Events for the Buy House Use Case 8.1 Preconditions: 1. It is the player’s turn. 2. The player has not rolled the dice. 3. The player has monopoly on one or more color groups. 8.2 Main Flow: When a player has all the tradable cells in a color group, this player is said to have monopoly on the color group. A player may build house(s) in the property cells in the color groups the player has monopoly on by pressing the Buy House button before he or she rolls the dice [S1] [E1 – E2]. The price of the house is determined by the cell. After buying the house(s), the status of the player is updated and displayed on the game board [UC13]. 8.3 Subflows: [S1] When the Buy House button is clicked, the Buy House dialog shows up. The player selects the monopoly color group and the number of houses from that dialog. After clicking on OK in the dialog box, the player pays the fee, and the houses are created. All the property cells in the selected color group have the same number of houses. 8.4 Alternative Flows: [E1] Nothing happens if the player does not have enough money. [E2] The player can build at most five houses in a cell. A use case is one path through this flow. cmsc435 - 13 Buy House use case [Inclusion of other use cases] Actor Use case [E1] Use case [S1] Use case [UC13] <<include>> <<include>> ● [S1] – Own monopoly and buy house ● [E1] – Not enough money to buy houses ● [E2] – Have 5 houses on properties Use case [E2] <<include>> cmsc435 - 14 Extend relationship ● Use case 2 extends the actions of use case 1. Use case [GotoJail] Use case [UC13] <<extend>> Use case 2 Use case 1 <<extend>> cmsc435 - 19 Class diagrams ● Class diagrams are used in both the analysis and the design phases. ● The class diagram describes the types of objects in a system and the various kinds of static relationships that exist among them:
- private
# protected
+ public ● You should have seen these in courses like CMSC330 in understanding C++ classes. They can represent the signatures of C++ classes. -Operation1 #Operation2 +Operation3 -Attribute1 #Attribute2 +Attribute3 ClassName cmsc435 - 20 Static relationships ● Inheritance (generalization): superclass class ● Aggregation (association): superclass class 1 * class “is-a” superclass superclass “has-a” class ● Composition (association): superclass class 1 * Class “exists within” superclass cmsc435 - 21 Cardinality of associations Cardinality and modality UML symbol One-to-one and mandatory 1 One-to-one and optional 0..1 One-to-many and mandatory 1..* One-to-many and optional * With lower bound l and upper bound u l..u With lower bound l and no upper bound l..* cmsc435 - 22 Monopoly class diagram cmsc435 - 23 Sequence diagram of ATM withdrawal ● Seen earlier ● Structure
the vertical dimension represents time;
The horizontal dimension represents different objects.
Arrows represent flows from use cases cmsc435 - 24 State diagrams ● Based on finite state machines (Did you learn this in CMSC330 or elsewhere?)
A state is represented by a rounded rectangle.
A start state is represented by a solid circle.
A final state is represented by a solid circle with another open circle around it.
A transition is a change of an object from one state (the source state) to another (the target state) triggered by events, conditions, or time. Transitions are represented by an arrow connecting two states.