1. System modeling and the Unified Modeling Language (UML) CS 560 1

2. Models for requirements analysis and Specification A model is a simplification of a component or system being designed.  We build models to better understand the system being developed.  We build models of complex systems because we cannot comprehend such a system in its entirety. Models can be formal or informal.  The more complex a project becomes, the more valuable a formal model becomes. 2

3. Principles of software Modeling UML  “Unified Modeling Language”  Expresses an idea, not detailed description on functionality.  Specific protocols/languages not needed  Used to describe a software system at a high level of abstraction.  Serves as a bridge between the requirements specifications and the implementation.  Is process and programming language independent. 3

4. Models: Diagrams and documentation in UML In UML, a model consists of a diagram and documentation.  A diagram is the graphical representation of a set of elements representing components of the software system.  Each diagram is supported by technical documentation that specifies the components represented. A diagram without documentation is of little value. 4

5. Types of UML Diagrams Use Case Diagrams  Interactions between a system and its environment Class Diagrams  Shows the object classes in the system and the associations between those classes Sequence Diagrams  Interactions between actors and the system, and between system components State Diagrams  Shows how the system reacts to internal and external events 5

6. Use Case Diagrams (Documentation) A use case is a model of the interaction between  External users of a software product (actors) and  The software product itself describes a set of scenarios captures user requirements contract between client and software developers 6

7. Use Case Diagrams Actors:  A role that a user plays with respect to the system. Use case:  Scenarios that describing an interaction between actors and the system. System boundary:  rectangle diagram representing the boundary between the actors and the system. 7

8. Use Case Diagrams (Library) 8 Library System Borrow Order Title Fine Client Employee Supervisor Boundary Actor Use Case

9. Class Diagrams (Documentation) A class diagram depicts classes and their interrelationships  Used for describing structure and behavior in the use cases  Used for requirement capture, end-user interaction  Detailed class diagrams are used for developers  Used for communicating software connections/requirements 9

10. Class Diagrams Each class is represented by a rectangle subdivided into three compartments  Name  Attributes  Operations Modifiers are used to indicate visibility of attributes and operations.  ‘+’ is used to denote Public visibility  ‘#’ is used to denote Protected visibility  ‘-’ is used to denote Private visibility By default, attributes are hidden and operations are visible. 10

11. Class Diagrams (bank account) 11 Account_Name - Customer_Name - Balance +addFunds( ) +withDraw( ) +transfer( ) Attributes Operations Class Name

12. Class Diagrams (shapes) 12 Operations Class Name Attributes

13. Sequence Diagrams (Documentation) Used to model the interactions between the actors and the components within a system. Shows interactions of specific use cases. Objects and actors are listed along the top of the diagram, with a dotted line drawn vertically from these.  Interactions between objects are indicated by arrows. 13

14. Sequence Diagrams (Telephone Call) 14 CallerPhoneRecipient Picks up Dial tone Dial Ring notificationRing Picks up Hello

15. Sequence Diagrams (Booking Website) 15

16. State Diagrams (documentation) Models the behavior of the system in response to external and internal events. Shows the system’s responses to stimuli  often used for modelling real-time systems. Shows states as nodes, and events as edges between these nodes.  When an event occurs, the system moves from one state to another. 16

17. State Diagrams (Billing Example) State Diagrams show the sequences of states an object goes through during its life cycle  abstraction of all possible behaviors 17 Unpaid Start End Paid Invoice created paying Invoice destroying

18. State Diagrams (Traffic Light Example) 18 Yellow Red Green Traffic Light State Transition Event Start

19. Reliable data Transfer Protocol State Diagram sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call 0from above Wait for ACK1  rdt_rcv(rcvpkt)    19

20. UML Diagrams Several UML diagrams: Use-case diagram: models the interaction between actors and software Class diagram: a model of classes showing the static relationships among them. Sequence diagram: shows the way objects interact with one another as messages are passed between them. State diagram: shows states, events that cause transitions between states. 20

21. Modeling tools: pseudo-code An informal modeling technique to show the logic behind part of a system. Pseudocode can be informal. What matters is that its interpretation is understood by everybody involved. Example: University Admission Decision adminDecision (application) if application.SAT == null error (incomplete) if application.SAT > S1 accept(application) else if application.GPA > G1 accept(application) else if application.SAT > S2 and application.GPA > G2 then accept(application) else reject(application) 21

22. Software Modeling: key points A model is an abstract view of a system that ignores system details.  System models can be developed to show the system’s context, interactions, structure and behavior. Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the product.  Describes interactions between a system and external actors. Structural models show the organization and architecture of a system.  Class diagrams are used to define the static structure of classes in a system. 22