Introduction to UML: Structural and Use Case Modeling

2 Software development process has 5 stages Requirements analysis and definition: Establish the application’s goals and constraints in consultation with users Design: Establish the system’s architecture Implementation and unit testing: Realize the design as a set of programs or program units Unit testing verifies that each unit meets its specification Integration and system testing: Integrate the program units and test as a complete system Maintenance: Correct errors, improve implementation, and enhance the system’s services as new requirements are discovered

3 What is the primary driver of software costs?  Most money and effort spent in testing and maintenance  But: 85% of errors are introduced during requirements analysis and design

4 Background What are object-oriented (OO) methods? OO methods provide a set of techniques for analyzing, decomposing, and modularizing software system architectures In general, OO methods are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs What are the benefits of OO? OO enhances key software quality factors of a system and its constituent components What is the rationale for using OO? In general, systems evolve and functionality changes, but objects and classes tend to remain stable over time

5 Background Software Quality Factors: Object-oriented techniques enhance key external and internal software quality factors, e.g., 1. External (visible to end-users) (a) Correctness (b) Robustness and reliability (c) Performance 2. Internal (visible to developers) (a) Modularity (b) Flexibility/Extensibility (c) Reusability (d) Compatibility (via standard/uniform interfaces)

6 Background OOA, OOD, and OOP Object-oriented methods may be applied to different phases in the software life-cycle, e.g., analysis, design, implementation, etc. OO analysis (OOA) is a process of discovery Where a development team models and under- stands the requirements of the system OO design (OOD) is a process of invention and adaptation Where the development team creates the abstractions and mechanisms necessary to meet the system's behavioral requirements determined during analysis

7  Who are users for this system? How to design a registration management system?

8  Who are users for this system?

9  What is the role for each user? How to design a registration management system?

10 How to design a registration management system?  What is the role for each user?

11 Difference between XML and UML  What is XML?  What is UML?

12 XML stands for EXtensible Markup Language XML was designed to describe data and to focus on what data is. (Widely used in database management) HTML was designed to display data and to focus on how data looks. (used on WWW)  What is XML?

13 UML stands for Unified Modeling Language In the field of software engineering, UML is a standardized specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.  What is UML?

14 Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication. Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge. It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools).  What is UML?

15 Unified Modeling Language (UML) used for both database and software modeling version 1.1 was adopted in November 1997 by the Object Management Group (OMG) as a standard language for object-oriented analysis and design Initially based on a combination of the Booch, OMT (Object Modeling Technique) and OOSE (Object- Oriented Software Engineering) methods, UML was refined and extended by a consortium of several companies, and is undergoing minor revisions by the OMG Revision Task Force. Ivar Jacobson is known as the father of Use Cases.

16 1.Structural Modeling with UML Structural model: a view of an system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations. 2.Use Case Modeling with UML use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).  Topics on UML

17 What you will learn: what the UML is and what is it not UML’s basic constructs, rules and diagram techniques how the UML can model large, complex systems how the UML can specify systems in an implementation-independent manner how UML, XML Metadata Interchange (XMI) and Meta Object Facility (MOF) can facilitate metadata integration

18 Quick Tour Why do we model? Why do we develop the UML? Foundation elements Unifying concepts Language architecture Relation to other OMG technologies

19 Modeling is a way of thinking about the problems using models organized around the real world ideas. A modeling method comprises a language and also a procedure for using the language to construct models. modeling is the only way to visualize your design and check it against requirements before your crew starts to code. Why do we model?

20 Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem solutions Decrease development costs Manage the risk of mistakes Why do we model?

21 Tijuana “shantytown”: The Challenge

22 Fallingwater: The Vision

23 Why do we model graphically? Graphics reveal data. Edward Tufte The Visual Display of Quantitative Information, bitmap = 1 megaword. Anonymous visual modeler

24 The UML is a graphical language for specifying visualizing constructing documenting the artifacts of software systems Added to the list of OMG adopted technologies in November 1997 as UML 1.1 Minor revisions are in UML 1.2 (1998), 1.3 (1999), 1.4 (2001), and 1.5 (2003). Major revision is UML 2.0, completed in The current standard. Quick Tour

25 Define an easy-to-learn but semantically rich visual modeling language Unify the Booch, OMT, and Object modeling languages Include ideas from other modeling languages Incorporate industry best practices Address contemporary software development issues scale, distribution, concurrency, executability, etc. Provide flexibility for applying different processes Enable model interchange and define repository interfaces UML Goals

26 OMG UML Evolution 1970: First object-oriented languages (Simula-67, Smalltalk). 1980:More than 50 different OOAD languages cause the users trouble to find complete and appropriate tools. 1992:New iterations of methods appear. Booch ‘93, OOSE (Jacobson), OMT-2 (Rumbaugh) 1995:Unification, UML 0.9 by Booch, Rumbaugh 1997:Standardization, UML 1.1 by Booch, Rumbaugh, Jacobson. Object Management Group (OMG) adapts UML as OOAD standard 1999:Evolving standard in version :Major revision in version 2.0

27 OMG UML Evolution

28 OMG UML Specification UML Summary UML Semantics UML Notation Guide UML Example Profiles Software Development Processes Business Modeling Model Interchange Model Interchange Using XMI Model Interchange Using CORBA IDL Object Constraint Language

29 Focus: the Language language = syntax + semantics syntax = rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases, clauses) semantics = rules by which syntactic expressions are assigned meanings UML Notation Guide – defines UML’s graphic syntax UML Semantics – defines UML’s semantics

30 Building blocks Well-formed rules Foundation Concepts

31 The basic building blocks of UML are: model elements (classes, interfaces, components, use cases, etc.) relationships (associations, generalization, dependencies, etc.) diagrams (class diagrams, use case diagrams, interaction diagrams, etc.) Simple building blocks are used to create large, complex structures cf. elements, bonds and molecules in chemistry cf. components, connectors and circuit boards in hardware Building Blocks

32 Diagram: Class View

33 Diagram: Instance View

34 Well-Formed Rules Well-formed: indicates that a model or model fragment adheres to all semantic and syntactic rules that apply to it. UML specifies rules for: naming scoping visibility integrity execution However, during iterative, incremental development it is expected that models will be incomplete and inconsistent.

35 Well-Formed Rules (cont’d) Example of syntactic rules: Class Basic Notation: A class is drawn as a solid- outline rectangle with three compartments separated by horizontal lines. Presentation Option: Either or both of the attribute and operation compartments may be suppressed. Example of syntactic guideline: Class Style Guideline: Begin class names with an uppercase letter.

36 Unifying Concepts class-instance dichotomy e.g., an object is an instance of a class OR a class is the classifier of an object specification-realization dichotomy e.g., an interface is a specification of a class OR a class is a realization of an interface analysis-time vs. design-time vs. run- time modeling phases (“process creep”) usage guidelines suggested, not enforced

37 Structural Modeling What is structural modeling? Core concepts Diagram tour When to model structure Modeling tips

38 What is structural modeling? Structural model: a view of an system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations.

39 Structural Modeling: Core Elements

40 Structural Modeling: Core Elements (cont’d) ¹ An extension mechanism useful for specifying structural elements.

41 Structural Modeling: Core Relationships

42 Structural Modeling: Core Relationships (cont’d)

43 Show the static structure of the model the entities that exist (e.g., classes, interfaces, components, nodes) internal structure relationship to other entities Do not show temporal information Kinds static structural diagrams class diagram object diagram implementation diagrams component diagram deployment diagram Structural Diagram Tour

44 Static Structural Diagrams Shows a graph of class elements connected by static relationships. kinds class diagram: class view object diagram: instance view

45 Classes

46 Classes: compartments with names

47 Classes: method body

48 Types and Implementation Classes

49 Interfaces: Shorthand Notation

50 Interfaces: Longhand Notation

51 Associations

52 Association Ends

53 Ternary Associations

54 Composition

55 Composition (cont’d)

56 Generalization

57 Generalization

58 Dependencies

59 Dependencies

60 Derived Attributes and Associations

61 Objects

62 Composite objects

63 Links

64 Constraints and Comments

65 Class Diagram Example

66 Implementation Diagrams Show aspects of model implementation, including source code structure and run-time implementation structure Kinds component diagram deployment diagram

67 Shows the organizations and dependencies among software components Components may be specified by classifiers (e.g., implementation classes) implemented by artifacts (e.g., binary, executable, or script files) Component Diagram

68 Components

69 Component Diagram

70 Component Diagram with Relationships

71 Deployment Diagram Shows the configuration of run-time processing elements and the software components, processes and objects that live on them Deployment diagrams may be used to show which components may run on which nodes

72 Deployment Diagram (1/2)

73 Deployment Diagram (2/2)

74 When to model structure Adopt an opportunistic top-down+bottom-up approach to modeling structure Specify the top-level structure using “architecturally significant” classifiers and model management constructs Specify lower-level structure as you discover detail re classifiers and relationships If you understand your domain well you can frequently start with structural modeling; otherwise If you start with use case modeling (as with a use-case driven method) make sure that your structural model is consistent with your use cases If you start with role modeling (as with a collaboration-driven method) make sure that your structural model is consistent with your collaborations

75 Structural Modeling Tips Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain. Focus on using basic constructs well; add advanced constructs and/or notation only as required. Defer implementation concerns until late in the modeling process. Structural diagrams should emphasize a particular aspect of the structural model contain classifiers at the same level of abstraction Large numbers of classifiers should be organized into packages

76 Interface-Based Design Interface-based design is a design approach that emphasizes the specification of system interfaces separates the specification of service operations (interfaces) from their realization (implementation) CORBA IDL is typically used for interface- based design of CORBA applications defines interfaces for business and system objects without constraining their implementations defines the structure of an distributed application doesn’t allow you to specify object behavior or class relationships other than generalization

77 Interface-Based Design (cont’d) The following example shows how UML can model the interfaces for a Point of Sale application originally specified in CORBA IDL.

78 Example: Interface-based design module POS { typedef long POSId; typedef string Barcode; interface InputMedia { typedef string OperatorCmd; void barcode_input(in Barcode item); void keypad_input(in OperatorCmd cmd); }; interface OutputMedia { boolean output_text(in string string_to_print ); }; …..

79 Example: Interface-based design ….. interface POSTerminal { void login(); void print_POS_sales_summary(); void print_store_sales_summary(); void send_barcode( in Barcode item); void item_quantity( in long quantity); void end_of_sale(); }; #endif /* _POS_IDL_ */

80

81 Use Case Modeling What is use case modeling? Core concepts Diagram tour When to model use cases Modeling tips Example: Online HR System

82 What is use case modeling? use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).

83 Use Case Modeling: Core Elements

84 Use Case Modeling: Core Relationships >

85 Use Case Modeling: Core Relationships (cont’d) >

86 Shows use cases, actor and their relationships Use case internals can be specified by text and/or interaction diagrams Kinds use case diagram use case description Use Case Diagram Tour

87 Use Case Diagram

88 Use Case Relationships

89 Actor Relationships

90 Use Case Description: Change Flight n Actors: traveler, client account db, airline reservation system n Preconditions:  Traveler has logged on to the system and selected ‘change flight itinerary’ option n Basic course  System retrieves traveler’s account and flight itinerary from client account database  System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.  System asks traveler for new departure and destination information; traveler provides information.  If flights are available then  …  System displays transaction summary. n Alternative courses  If no flights are available then …

91 When to model use cases Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven method start with use cases and derive your structural and behavioral models from it. If you are not using a use-case driven method make sure that your use cases are consistent with your structural and behavioral models.

92 Use Case Modeling Tips Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams Factor out common usages that are required by multiple use cases If the usage is required use > If the base use case is complete and the usage may be optional, consider use > A use case diagram should contain only use cases at the same level of abstraction include only actors who are required Large numbers of use cases should be organized into packages

93 Example: Online HR System

94 Online HR System: Use Case Relationships

95 Online HR System: Update Benefits Use Case n Actors : employee, employee account db, healthcare plan system, insurance plan system n Preconditions:  Employee has logged on to the system and selected ‘update benefits’ option n Basic course  System retrieves employee account from employee account db  System asks employee to select medical plan type; include Update Medical Plan.  System asks employee to select dental plan type; include Update Dental Plan.  … n Alternative courses  If health plan is not available in the employee’s area the employee is informed and asked to select another plan...

96 UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation- independent manner 10-20% of the constructs are used 80-90% of the time Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior Use case modeling specifies the functional requirements of system in an object-oriented manner Ideas to Take Away