Introduction to UML

1. Introduction to UML Fall 2005 OOPD John Anthony

2. What We’ll Discuss • What is UML (and a bit of history) • Why we need UML • Three UML usage modes • Some Important Diagrams • Use Case Diagrams • Class Diagrams • Sequence Diagrams • State Diagrams • Deployment Diagrams

3. What is UML • Unified Modeling Language (UML) is a family of graphical (and textual) notations that describes different aspects of a software system. • UMLhelps you specify, visualize, and document models of software systems, including their structure and design. • An Open standard controlled by the Object Management Group (OMG). http://www.omg.org/gettingstarted/what_is_uml.htm http://www.omg.org/

4. Rebecca Wirfs-Brock Ivar Jacobson Jim Odell Grady Booch Peter Coad Steve Mellor Jim Rumbaugh Sally Shlaer History of UML Pre 1988 1994 Booch (Rational) & Rumbaugh (left IBM) begin to unify under Rational Software Corporation Rational buys Objectory and aquires Ivar Jacobson brining the Object Oriented Software Engineering (OOSE) Rational releases 0.8 of the Unified Method at OOPLSA ‘95 1995 1996 UML .9 and .91 released OMG gets more involved to ensure CASE tool interoperability. Need to keep Rational honest!!!! Contributors icnlude: DEC, HP, i-Logix, Intellicorp, INBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, Unisys, etc. 1997 UML 1.0 released 1997 - 2003 OMG releases UML versions 1.2, 1.2, 1.3, 1.4, 1.5 2004 OMG releases UML 2.0

5. Goals of UML • Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. • Provide extensibility and specialization mechanisms to extend core concepts. • Be independent of particular programming languages and development processes. • Provide a formal basis for understanding the modeling language. • Encourage the growth of the OO tools market. • Support higher-level development concepts such as collaborations, frameworks, patterns and components. • Integrate best practices.

6. Why Do We Need UML? /** *Creates a new instance of Athlete. *@param name - the name of the athlete */ We need a standard notation for describing the structure and behavior of a system. public Athlete(String name ) { if(name == null || name.equals("")) { this.name = this.DEFAULT_NAME; } this.name = name; }

7. UML Diagram Types

8. UML Diagram Types (con’t)

9. Use Case(s) • A technique for capturing the functional requirements of a system. • They describe the interaction between the user (actor) and the system. • They help to communicate the scope of a development project. • An actor can be any entity that performs a role with a given system • UML provides guidance on Use Case diagrams but not the contents of a Use Case (referred to as a Use Case Specification).

10. Scenario Managers are responsible for creating teams that, in turn, are responsible for creating various products. The creation of the team is based on approval from a product development advisory committee. Products are often created by assembling existing components in novel ways. Each team may be composed of any number of team members. On occasion, teams may be combined to form larger teams. The state of a team can be described as following; formed, on hold, active, and completed. Teams follow a process during the discovery and creation of a product. The major steps include Survey, Focus, Investigate, Transition, Develop.

11. Alternative Behaviors • What happens if the investigation phase does not warrant moving into the transition phase? • What if the Advisory Committee does not approve the creation of a team?

12. Example Use Case Specification Form a Team Type: Main Success Scenario | Alternate Main Success Scenario: • Manager logs into the Idea Generation system. • Manager enters a new idea into the Idea Generation (the system) application. • Manager creates a business case and cost benefit model to justify the creation of the team. • Manager enters the proposes team members, start date, and estimated completion date into the system. • Manager uploads business case and cost benefit model into the system. • Manager receives appointment to present the new idea to the advisory committee. • Manager adds any additional details that me relevant to the new idea. • Manager receives approval from the advisory committee. • Manager notifies team members and holds a kick-off meeting. Extensions: 5a. Manager does not receive approval from advisory committee due missing information in cost benefit model 1. Manager adds missing information to cost benefit model (return to MSS step 4).

13. Use Case Diagrams • Provides a summarized graphical representation of a set of Use Case Specifications. • They reveal the actor(s), the Use Cases, and the relationships between them. • Two types of Use Case relationships:<<include>> - used when a Use Case will invoke another Use Case. Analogy: method invocation<<extend>> - used when a Use Case may invoke another Use Case. Analogy: hardware interrupt inheritance – represents a specialization of the parent use case

14. Example Use Case Diagram actor use case system boundary

15. Class Diagrams • Provides a structural view of the classes of a system, their features, andthe inter-relationships between the classes • Probably the most popular UML diagram used to convey system structure

16. The Class Icon class name attributes methods + updateStatus( status: int) : void visibility methodname variable name type return type

17. Visibility

18. Associations • Associations are any type of relationship between two classes. • Composition – when something is part of something else. • Aggregation – when something contains a collection of things that are not part of it. • Another way to tell them apart – if the “part” has the same lifespan as the whole, then its composition. • At the end of the day, the most important goal is to model the association. Don’t fret about Composition vs. Aggregation. When should you model a relationship as an attribute vs. an association?

19. Dependency • There are other types of relationships that are not based on composition or aggregation. • A dependency exists when one class depends on behavior of another. For example, consider the relationship between a team and a product.

20. Multiplicity The multiplicity of a property is an indication of how many objects may fill the property. • 1 – only one object can be associated with the property • 0..1 – zero or one object may be associated with the property • * - any number of objects may be associated with the property

21. Generalization • Depicts the “is a” relationship.

22. Sequence Diagrams Shows the sequence of interactions between objects. Benefits include: • Validate and flesh out the logic and completeness of a particular scenario • Explore designs by allowing you to visually step through the sequence of messages • Indicates which classes may be highly coupled (i.e. receiving many messages) • Depicts instantiation and length of life of an object. Major Challenge • The level of detail is dependent on the intent of the diagram (more on this later).

23. Consider the Below Code Sample public void createNewTeam() { Team aTeam = new Team(this.generateUniqueTeamID()); for(int developerCount=0; developerCount < 3; developerCount++) { InnovationLabDeveloper developer = new InnovationLabDeveloper(); developer.setEmployeeID(new Double(Math.random()).toString()); aTeam.addTeamMember(developer); } aTeam.updateStatus(Team.FORMED); this.sendNotification(); } From the class Manager

24. Example Sequence Diagram

25. Types of Interaction Frames

26. (simple) State Diagram State diagrams are used to describe the behavior of a system.  State diagrams describe all of the possible states of an object as events occur.  Each diagram usually represents objects of a single class and track the different states of its objects through the system. 

27. Activity Diagram Activity Diagrams support the description of business processes and workflows. They can also be used to depict a complex sequence of events that may not be reflective a functional requirement. A key feature of Activity diagrams is the ease of showing parallelism.

28. Example Activity Diagram

29. Example Activity Diagram (con’t)