1. CS 360 Lecture 6

2.  A model is a simplification of reality  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.  UML  “Unified Modeling Language”  Expresses an idea, not detailed description on functionality.  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.  An industry-standard process for specifying, visualizing, constructing, and documenting information about software systems.  Simplifies the complex process of software design. 3

4.  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.  Means of discussion about an existing or proposed system  Way of documenting an existing system  Models should be an accurate representation of the system but need not be complete.  Detailed system description that can be used to generate a system implementation  Models have to be both correct and complete. 5

6.  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 6

7.  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 7

8.  Actors:  A role that a user plays with respect to the system.  Use case:  A set of scenarios that describing an interaction between a user and a system.  System boundary:  rectangle diagram representing the boundary between the actors and the system. 8

9. 9 Library System Borrow Order Title Fine Client Employee Supervisor Boundary Actor Use Case

10. 10 Boundary Actor Use Case

11.  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 11

12.  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. 12

13. 13 Account_Name - Customer_Name - Balance +addFunds( ) +withDraw( ) +transfer( ) Attributes Operations Class Name

14. 14 Operations Class Name Attributes

15. 15 Subtype2 Supertype Subtype1 Inheritance is a required feature of object orientation Promotes code reuse and flexability Regular Customer Loyalty Customer Example:

16.  Sequence diagrams  Used to model the interactions between the actors and the objects 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. 16

17.  Used to model the interactions between the actors and the objects within a system.  Shows the sequence of interactions that take place during a particular use case.  Example:  User making a phone call 17

18. 18 CallerPhoneRecipient Picks up Dial tone Dial Ring notificationRing Picks up Hello

19. 19

20.  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. 20

21.  State Diagrams show the sequences of states an object goes through during its life cycle  abstraction of all possible behaviors 21 Unpaid Start End Paid Invoice created paying Invoice destroying

22. 22 Yellow Red Green Traffic Light State Transition Event Start

23.  UML is a standardized specification language for object modeling  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. 23

24.  An informal modeling technique to show the logic behind part of a system.  Example: University Admission Decision adminDecision (application) if application.SAT == null then error (incomplete) if application.SAT > S1 then accept(application) else if application.GPA > G1 then accept(application) else if application.SAT > S2 and application.GPA > G2 then accept(application) else reject(application)  Pseudo-code  can be informal, or  a standard used by a software development organization, or  based on a regular programming language.  What matters is that its interpretation is understood by everybody involved. 24

25.  Rapid prototyping is the most comprehensive of all modeling methods  Specifying requirements by building a system that demonstrates the functionality of key parts of the required system  Particularly valuable for user interfaces 25

26.  A data dictionary is a list of names used by the system  Name (e.g., "start date")  Brief definition (e.g., what is "date")  Where is it used (e.g., source, used by, etc.)  May be combined with a glossary  As the system is developed, the data dictionary in the requirements is the basis of the system data dictionary, which is part of the final specification. 26

27.  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. 27