An Brief Introduction to

1

• An Brief Introduction to
• the Unified Modeling Language
• Presented by
• Michael Liedtke
• Jing Wang
• 11/28/01
• Course BAD 64045/74045
• Systems Development Methodologies

2
Presentation Overview

• Brief History of UML (Unified Modeling Language)
• Introduction to the Unified Modeling Language
• UML DiagramsDiagramsDiagrams..
• More UML Basics
• Modeling in UML
• Example
• Wrap-up and class activity

3
Brief History of UML

• The UML definition was led by Rational Software's
  industry-leading methodologists, Grady Booch,
  Ivar Jacobson, and Jim Rumbaugh.
• The language has gained significant industry
  support from various organizations via the UML
  Partners Consortium and has been submitted to and
  approved by the Object Management Group (OMG) as
  a standard (November 17, 1997).

4
Primary Design Goals of UML

• The primary design goals of UML per the OMG
  specification are
• Provide users with a ready-to-use, expressive
  visual modeling language to develop and exchange
  meaningful models
• Furnish extensibility and specialization
  mechanisms to extend the core concepts
• Support specifications that are independent of
  particular programming languages and development
  processes
• Provide a formal basis for understanding the
  modeling language
• Encourage the growth of the object tools market
• Support higher-level development concepts such as
  components, collaborations, framework and
  patterns
• Integrate best practices

5
Companies working with UML

• Hewlett-Packard (www.hp.com)
• i-Logix (www.ilogix.com)
• IBM (www.ibm.com)
• ICON Computing (www.iconcomp.com)
• IntelliCorp (www.intellicorp.com)
• MCI Systemhouse (uml.systemhouse.mci.com)
• Microsoft (www.microsoft.com)
• ObjecTime (www.objectime.com)
• Oracle (www.oracle.com)
• Platinum Technology (www.platinum.com)
• Ptech (www.ptechinc.com)
• Rational Software (www.rational.com)
• Reich Technologies (www.projexion.com)
• Sterling Software (www.sterlingsoftware.com)
• Taskon (www.sn.no/taskon)
• Unisys (www.unisys.com)

6
What is Unified Modeling Language (UML)

• The UML is a graphical language for
• Visualizing
• Specifying
• Constructing
• and Documenting
• the artifacts of a system-intensive process.

7
Handy UML Dictionary Link

• http//www.softdocwiz.com/UML.htm

8
Visualizing

• Explicit model facilitates communication
• Some structures transcend what can be represented
  in programming language
• Each symbol has well-defined semantics behind it

9
Specifying

• UML addresses the specification of all important
  analysis, design, and implementation decisions.

10
Constructing

• Forward engineering generation of code from
  model into programming language
• Reverse engineering reconstructing model from
  implementation
• Round-trip engineering going both ways

11
Documenting

• Artifacts include
• Deliverables, such as requirements documents,
  functional specifications, and test plans
• Materials that are critical in controlling,
  measuring, and communicating about a system
  during development and after deployment

12
Critical Components of UML Diagrams..
DiagramsDiagrams.

• OBJECT Diagram
• CLASS Diagram
• USE CASE Diagram
• STATE Diagram
• SEQUENCE Diagram
• ACTIVITY Diagram
• COLLABORATION Diagram
• COMPONENT Diagram
• DEPLOYMENT Diagram

13
1 - OBJECTS

• What An OBJECT is in the Real World
• According to Webster, an OBJECT is
  something that is, or is capable of being,
  seen, touched or otherwise sensed.

14
1 - OBJECTS

• What an OBJECT is in the Data World
• An OBJECT is an abstraction of some thing in
  the real world, which carries both the data
  describing the real world object and the
  operation (program code ) that have the only
  allowable access to that data.
• Examples
• employees, students, customers etc.

15
1 OBJECTSAn Example of Real World OBJECT A
Cup of Coffee

• Data

• Coffee
• Coffee maker
• Sugar
• Milk
• Cup

• Operation

• Put coffee and water in
• the coffee maker and boil it
• Put the coffee in the cup
• Add sugar and milk

16
1 OBJECTSExample of Real World OBJECTS
Employees

• Data

• Employee Number
• Hours Worked
• Salary Rate
• Tax Rate

• Operations (code)

• Input Employee No.
• Retrieve Hours Worked.
• Retrieve Salary Rate
• Calculate Gross Salary
• Retrieve Tax Rate
• Calculate net income

17
1 - OBJECT Diagram

• An OBJECT is an instance of a class a
  specific thing with specific values of the
  attributes and behavior
• UML Format is as presented below

Name of Class
Name of instance
18
1 - OBJECT Model

• The components of an OBJECT Model
• 1) CLASS diagrams
• 2) Behavior Diagrams
• 3) STATEchart Diagrams
• 4) Collaborations CRC Cards
• 5) SEQUENCE Diagrams
• 6) ACTIVITY Diagrams

19
2 - CLASS Diagram

• A CLASS is a Category or group of things that
  have similar attributes
• These diagrams provide representations that
  developers work from.
• It Enable analysts to talk to clients in the
  clients terminology, thereby stimulating clients
  to reveal important details about problems they
  want to solve.

Class Attributes Behaviors
20
2 - Example of a CLASS Diagram in the Real World
21
2 - Example of a CLASS in the Data World
22
2 - Types of CLASSES

• Entity Classes Classes found in the real world
  and incorporated in the CLASS diagram (employee,
  sales report).
• Interface Classes Model data flows with the user
  and with other systems (GUI and data protocols).
• Control Classes Model operations that do not fit
  in any existing CLASS
• Abstract Classes Classes that have no direct
  instances (often introduced at design time to
  exploit inheritance and polymorphism)

23
2 - SubCLASSES and Inheritance

• SubCLASS A subCLASS is made of selected
  instances from another CLASS, referred to as the
  parent CLASS or superCLASS.
• Inheritance Inheritance is when a subCLASS
  instance, in addition to the attributes and
  behavior of itself, also has all the attributes
  and behavior of its parent CLASS.
• The characteristic of inheritance enhances the
  reusability of OOP (object oriented programming),
  and hence reduce programming effort and bugs.

24
2 - Example of subCLASS and inheritance

• Person
• Name
• Address
• Age
• Sex
• Employee Customer
• wage rate balance owing
• Vac. Earned Balance
• Vac. Taken overdue
• YTD Earned YTD Purchase
• YTD Tax
• YTD Overtime

25
2 - CLASS Diagrams

• Seven steps in drawing CLASS Diagrams
• 1) Candidate classes
• 2) Define classes
• 3) Establish associations
• 4) Expand many-to-many associations
• 5) Attributes
• 6) Normalization
• 7) Operations (behavior)

26
Step 1 Candidate Classes

• Entity classes
• An entity is represented in English as a noun.
  So make a list of nouns that might name entity
  classes, candidates for inclusion in the system.
• Four ways to generate the list
• 1) client interview
• 2) from the requirement model other
  documentation
• 3) brainstorming

27
Interface Classes Control Classes

• Interface classes if you have a OOGUI class
  library, then most of the user interface classes
  will be defined in the library. Published
  protocols can be used freely for data
  communication interface and process control.
• Control classes created for operations that need
  data and operations from many other classes, or
  dont appear to belong to any of the classes you
  have. It might have just this operation and a few
  attributes to support it.

28
Step 2 Define Classes

• Each candidate class must be subjected to 3
  checks
• 1) Real-world identifier
• Objects have identity. If this
  candidate is the name of a
• class that matters, then its instance
  must have identity.
• They are distinct and we can tell them
  apart.
• 2) Definition
• A class documents the users jargon, the
  words they use
• every day in their job.
• 3) Sample attributes and behaviors
• A class must carry some data and be
  capable of some
• behavior.

29
Step 3 Establish Associations

• Discovering the verb
• An association is a relationship expressing
  the interactions between instances of two
  classes, represented by the verb that describes
  what they do to each other.
• Establish the multiplicity
• Capturing all possible interactions
• Attitude of the users

30
Example Associations
31
Step 4 Expand Many-to-Many Association

• Customer buys Product
• Name Description
• customer initiates sale
  has product
• Name 1
  Namedescrip. 1 descrip.
• Customer Sales Product
• Name Address Name Descrip. Qty Descrip. Price
• Bo here Jo coffee 2 coffee 1.00
• Jo there Jo donuts 3 donut 0.50
• Ko far Ko donuts 4

32
Step 5 6 Attributes Normalization

• Attribute Go through the model, box by box, and
  list for each class all the attributes that you
  can think of.
• Normalization The process of ensuring that every
  attribute is attached to the class of objects
  that it truly describes.

33
The Final CLASS Diagram
34
3 - USE CASE

• A USE CASE is a sequence of actions, including
  variants, that a system performs to yield an
  observable result of value to an actor.
• An actor is a coherent set of roles that human
  and/or non-human users of USE CASES play when
  interacting with those USE CASES.

35
3 - USE CASE Diagram

• Sales Reporting System
• request sales update
• summary sales report
• Sales
• Manager prepare
• request sales sales summary
  sales
• summary clerk
• request detailed
• Sales figures
• Supervisor
• report to
• sales manager

36
3 - USE CASE Diagram

• Washing Machine User
• Wash
• Clothes
• The purpose of the USE CASE Model is
• To document what functions the system should
  offer to the users
• To construct the developers view of what the
  users want
• To provide a starting point for discovering the
  object classes
• To provide a starting point for discovering the
  operations for each class

37
4 - STATE Chart Diagrams

• How do you know if you need a STATE chart
  diagram?
• Class has an interesting or complex life or
  operation cycle

38
4 - STATE Chart in Real World (the Life Cycle of
a Library Book)

• Start books in subscriber
  send books in
• shelved state sign-out
  message signed out state
• Book changes to
  subscribe sends Books updates
• checked in state check-in
  message date/ time out
• establishes link
• 
  to
  subscriber
• Book update librarian sends book
  changes
• Date/time in shelve yourself to
  shelved
• Book archives message state
• Link to subscriber
• book updates date/time shelved

39
4 - STATE chart in Data World
40
4 STATE Diagram
Soaking

• STATE Diagrams capture the reality of changing
  from one STATE to another.

Washing
Rinsing
Spinning
41
5 SEQUENCE Diagram

• SEQUENCE Diagrams show the time-based dynamics
  of interaction
• For the washing machine example, invoking the
  Wash clothes USE Case might yield
• Water enters the drum through a pipe
• Drum stays stationary for x minutes
• Water stops entering
• Drum rotates back and forth for x minutes
• Soapy water leaves to drain
• Clean water enters
• Drum continues rotation
• Water stops entering
• Rinse water exits
• Drum rotation becomes uni-directional for x
  minutes
• Drum stops and wash is done

42
5 SEQUENCE Diagram
Water Pipe
Drum
Drain
Send fresh water Remain Stationary Stop Rot
ate back and forth Send soapy water Send
fresh water Rotate back and forth Send
rinse water Stop Rotate unidirectionally
Stop
43
6 ACTIVITY Diagram

• ACTIVITY Diagrams show the sequence of
  activities that occur within a USE CASE or within
  an OBJECTS behavior
• For example, steps 4-6 of the SEQUENCE diagram
  would be.

Rotate drum for x minutes
Empty soapy water
Restart water input
44
7 COLLABORATION Diagram

• The COLLABORATION Diagram shows how the
  elements of a system work together to accomplish
  objectives.
• In the washing machine example, an internal
  timer is added to the set of classes that
  constitute the washing machine. After a period
  of time, the timer stops the flow of water and
  starts the drum rotating back and forth.

45
7 COLLABORATION Diagram
Internal Timer
1. Stop
Water Pipe
2. Rotate back and forth
Drum
46
8 COMPONENT Diagram

• Software development proceeds via COMPONENTS
• COMPONENTS are geared to computer systems
• A UML component diagram is represented by

Component 1 Dependency Component 2
47
9 - DEPLOYMENT Diagram

• DEPLOYMENT Diagrams show physical architecture
  of a system such as
• Computers/Devices
• Connections
• Software on each machine

48
9 DEPLOYMENT Diagram
ltltProcessorgtgt Network server Linux 2.4.2 kernel
ltltProcessorgtgt SGI Workstation Irix 6.5
ltltProcessorgtgt Dell Dimension 4300 Windows 2000 Pro
49
10 - The CONTEXT Diagram

• Purpose To show how our system is related to the
  world beyond itself.
• 1. To graphically depict the project scope
• 2. To model the flows of data to and from the
  
• external entities that our system must
  interact
• with

50
Example CONTEXT Diagram

• Imports Sales Reporting invoices
  Packing Slips
• Revenue Documentation System Vendors
• Dept. orders
• Purchases Orders
• receipts
• Customers
• Census Invoices
• Bureau statistics
  Packing Slips
• statistics
• Gov. Watchdogs

51
CRC (Class-Responsibility-Collaboration) Card

• Components of CRC
• 1) Server 2) Client
• 3) Responsibility data and operations
• 4) Collaboration a request from a client to
  a server
• client server client server
• request for service request for help
• object 1 object 2 object 3
• data data data
• operation operation operation
• response response

52
Sample CRC

• Class Identifier
• Receivable Account
• Account No.
• Respon. Collab.
• Data Acct. No.
• Customer No.
• Description
• Balance receivables
• Balance 30 days transaction
• Balance 60
• Balance 90
• Operation
• Print Statement
• Add Transaction to balance

• Class identifier
• Receivables Transaction
• Transaction No.
• Respon. Collab.
• Data Acct. No.
• Trans. No.
• Date
• Cash Amount.
• Operation
• post to account
• print statement line

53
More UML Basics

• Messages
• Polymorphism
• Modeling

54
Message

• Definition
• A request from one OBJECT (sender) asking the
  second OBJECT (receiver) to perform one of its
  operations the protocol for communication
  between OBJECTS the mechanism to invoke behavior.

55
An Example of Real World Message
56
An Example of Data World Message

• Expense
  Employee
• Retrieve Employee No.
• Report

57
Polymorphism

• Polymorphism is the ability to write several
  versions of a method (function) in different
  classes of a subclass hierarchy, give them the
  same name, and rely on the OO environment to
  establish which version should be executed.
• The characteristics of a polymorphism also
  enhances the reusability of OOP.

58
Example of Polymorphism in Real World
59
Example of Polymorphism in Data World
60
Reasons to Model

• To communicate the desired structure and behavior
  of the system
• To visualize and control the systems
  architecture
• To better understand the system and expose
  opportunities for simplification and reuse
• To manage risk

61
Principles of Modeling

• Choice of models to create very influential as
  far as how to attack problem and shape solution
• Every model may be expressed at different levels
  of precision
• Best models connected to reality
• No single model is sufficient

62
Activities and Phases of the OODLC (I)
63
Activities and Phases of the OODLC (II)
64
Requirements Model

• Purpose To document the users needs in full
  detail in a way that is both understandable for
  the users and usable by the developers as a
  starting point to develop a system.
• Components
• 1. Project Scope
• 2. Initial Feasibility Analysis
• 3. Context Diagram
• 4. Use case script model
• 5. Interface Descriptions

65
Requirements ModelProject Scope

• Purpose To make sure that the objectives of the
  system fit in with the objectives of the
  business.
• What should be included in the project scope
• 1. What the eventual system will do
• 2. What functions will be part of the system
• 3. Which users it will service
• 4. What will not be part of the system (not
  always)

66
Requirements ModelExample Project Scope

• A system to track product sales and purchases,
  inventory valuation, and stock on hand. It will
  produce sales reports at various cycles, and will
  allow random and ad-hoc queries.

67
Requirements ModelInitial Feasibility Analysis

• Operational feasibility Will the proposed system
  do the job being asked for and will it work in
  this company?
• Technical feasibility Do we have the hardware,
  software and technical know how to do it?
• Schedule feasibility Can the development take
  place within schedule constraints?
• Economic feasibility Will the costs be
  practical?

68
Resources and Links

• SAMS-Teach Yourself UML in 24 Hours Schmuller
  SAMS Publishing 1999
• http//www.rational.com/uml/index.jsp
• http//home.earthlink.net/salhir/whatistheuml.htm
  lreferences
• http//www.softdocwiz.com/UML.htm
• http//www.cetus-links.org/oo_uml.htmloo_uml_util
  ities_tools MEGA LINKS!!
• http//www.uml-zone.com/
• http//www.codeproject.com/cpp/oopuml.aspIntroduc
  tion
• http//www.iconixsw.com/Spec_Sheets/UnifiedOM.html
  
• http//stud2.tuwien.ac.at/e8726711/ummw1.html
• http//technology.monster.com/articles/uml/
• http//www.objectsbydesign.com/tools/modeling_tool
  s.html choosing a UML tool
• http//www.objectsbydesign.com/tools/umltools_byPr
  oduct.html list of tools
• http//www.holub.com/class/uml/uml.html
• http//www.rational.com/media/products/rup/upm/ad2
  000-05-05.htm