object-oriented database systemscsci 397c-16 unified modeling language (uml) prepared by: keith...

Unified Modeling Language(UML)

Prepared By: Keith Bryant02 Nov 99 -

Object-Oriented Database Systems CSCI 397C-16




Agenda UML - What is it. UML - Where and how did it originate. Structural Diagram Overview Behavioral Diagram Overview Design Processes Using UML

– Use Case Diagrams– Use Case Narratives– Class Diagrams– Design Class Diagrams– Class-Responsibility-Collaboration (CRC) Cards– System Sequence Diagrams– Contracts– Interaction Diagrams– Collaboration Diagrams




Unified Modeling Language (UML) - What is it? UML is a modeling language used as a “language whose

vocabulary and rules focus on the conceptual and physical representation of a system”.

Its purpose is to “visualize, specify, construct, and document the artifacts of a software-intensive system”.




The History of UML - From Whence It Came?

Object-oriented programming languages originated in the late seventies and early eighties.

Object-oriented modeling languages originated as a set of methodologies needed for analysis and design of OO applications and programs.

By the early nineties, many OO modeling languages were in existence, including:

– Object-Oriented Software Engineering (OOSE) - Booch & Jacobson

– Object Modeling Technique (OMT) - Rumbaugh

– Fusion

– Yourdon OOSE & OMT became the more recognized and accepted

methodologies.




The History of UML - From Whence It Came?

By the mid-nineties, a common set of expectations and ideas began to form.

These two primary modeling languages began to evolve toward one another.

The primary authors, Booch, Jacobson, and Rumbaugh recognized the need to unify these modeling languages.

Hence, the Unified Modeling Language (UML) was born. This unification is a significant step in the OO world since a

recognized language can now be utilized. Common creative energies can now be focused toward improving

and extending one language as compared to opposing, competing languages.




Unified Modeling Language (UML) - What is it?

UML Version 1.0 was submitted to the Object Management Group (OMG) in January 1997 as a proposed standard modeling language.

UML Version 1.1 was submitted for standardization in July 1997 and was officially adopted by OMG in November 1997.

Maintenance is now officially performed by the OMG Revision Task Force (RTF).

Version 1.2 was released in June 1998 with Version 1.3 being released in October 1998.

Both these versions were generated through the OMG RTF. Please refer to the OMG website for information regarding the

OMG organization, http://www.omg.org/ Formal UML documentation may also be obtained from the OMG

website, http://www.omg.org/uml/




UML Diagrams

UML contains two different types of modeling diagrams.

– Structural Type Diagrams (Static Representations) Class Diagrams Class-Responsibility-Collaboration (CRC) Cards Object Diagrams Component Diagrams Deployment Diagrams

– Behavioral Type Diagrams (Dynamic Representations) Use Case Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams




Structural Diagrams

Classes: Defines classes, interfaces, collaborations, and relationships.

Class-Responsibility-Collaboration (CRC) Cards:

Defines a high-level description of class responsibilities.

Objects: Defines objects and their relationships at a given point in time.

Components: Defines components and their relationships from a perspective of a software architecture.

Deployment: Defines a configuration from a perspective of a hardware computing architecture.




Behavioral Diagrams

Use Case: Defines a set of use case specifications, actors, and their associated relationships.

Sequence: Defines a set of interactions or messages between objects relative to order or time.

Collaboration: Defines a set of interactions or messages between objects relative to time.

Statechart: Defines a type of state machine that consists of states, transitions, and events.

Activity: Defines the flow from activity to activity. These emphasize the flow of control among

objects.




Use Case Diagram

Help

InstallInstaller

Compile Application

Execute Application

Transfer Application

Construct Application

Configure Application

Applicati

A use case diagram graphically illustrates a set of activities within a system.

Use case diagrams are primarily used to denote external interactions to a system.

The stick figures represent actors that externally participate or stimulate the interaction.

The arrows demonstrate that there are relationships between the actors and the activities denoted by the ovals.




Use Case Narratives

Use Cases describe a set of interactions with a system. Boundaries are identified to distinguish between external events and

internal events. The external events define external influences on a system. The internal events define the system response to these external

influences. Several different types of Use Case narratives can be utilized.

– High Level: Typically used within initial conceptual designs.

– Expanded: Used to provide more detail by including actions and responses. Usually does not include implementation details.

– Real: Uses the same format as expanded use cases. Includes specific implementation aspects, I/O, frameworks, dialogs, etc. Typically used within detailed design.




Use Case: Construct Application Software

Actors: Programmer

Purpose: Utilize the installed drive elements to construct a drive application.

Overview:Since the USS drive software add-in is an optional software product that is incorporated into the Micro/WINproduct, new components and elements will become visible.

Type: Primary and essential.

Rank: High

Cross Reference: Functions: R1.x

Typical Course of Events

Actor Action System Response

1. This use case begins when the programmer begins toprogram the application.

2. The programmer opens the drive instruction tree leaf for thedrive instruction elements. 3.

The system expands the leaf to display all driveelements.

4. The programmer positions the cursor within theprogramming area at the point where the instruction ischosen to be placed.

5. The system highlights the cursor.

6. The programmer places the instruction element by draggingor double clicking the desired element.

7. The system places the element at the cursor position.

8. The system places a "????" marker for each parameterto demonstrate that configuration is required.

9. The system underlines each parameter to demonstratethat the current parameter is not valid.

10. The programmer selects a parameter of the instruction inorder to configure the variable in absolute addressing mode. 11.

The system will automatically validate the variablememory type and address. An invalid type will beprevented from being entered.

Alternative Courses:

Line 2: The system may provide assistance in identifying the type of element.

Line 6: The system will prevent placing of an element if it the context of the instruction is invalid for the selected position. Line 10: If the system has been configured for symbolic programming, a listing of alphabetically sorted variables that closely

match the variable being typed by the programmer will be provided.

Use Case Narratives




Identifying Classes and Objects Once Use Cases have been created, conceptual models can be

developed using the information contained within the Use Cases. Conceptual models will include objects, associations between

objects, attributes of the objects, and multiplicity between objects. Many different methods exist for identifying concepts and objects.

However, one effective method is the identification of nouns and noun phrases contained within the Use Cases.

Each individual noun phrase can identify a specific concept or object.

Many objects will form the basis of Class Diagrams and Design Class Diagrams.




Class Diagrams Each rectangle defines a class with the name represented in the first

compartment. Attributes of the class are represented in the second compartment. Operations of the class are represented in the third compartment. Attributes and operations can be denoted as public or private as

depicted with the attached icons.

Application

SelectParms()PlaceInstruction()

InstructionTree

ins : integer

OpenTreeLeaf()GetLeafInfo()SelectInstruction()

HandleInstParms

ValidateParms()SaveParms()

HandleSymParms

ValidateParms()SaveParms()

SymbolTable

Name : stringMemType : intMemAddr : intDataType : intComment : string

SelectSymbolTable()DisplaySymbolTable()ConfigureSymbolInfo()ValidateParms()SaveParms()

Name

Attributes

Operations




Design Class Diagrams Design Class Diagrams are used to model static representations of

a system. Design Class Diagrams are similar to the Object Relationship

Model of OSM. They will typically include the following characteristics:

– Classes or objects participating within a given diagram.

– Associations or Relationships between these classes or objects.

– Multiplicity or the number of instances of the associations.

– Attributes of the class or object.

– Operations of the class or object.

– Dependencies and generalizations.




Design Class Diagrams - Conceptual Modeling

AssociationsMultiplicity

Describes Describes

Describes

Defines

Defines

Contains

Presented In Defines

Contains

Sent To

Records

MonitorsConfigures

1

11

Contains

1

1..8

1

1..30

1 1..30

1

1..126

1

1

1

*

*

1

*

1..512

1

*

1 *

Contains

*

*

1

1

Drive Status

Drives

Programmer

SymbolTable

Name : stringMemType : intMemAddr : intDataType : intComment : string

SelectSymbolTable()DisplaySymbolTable()ConfigureSymbolInfo()ValidateParms()SaveParms()

Program Area

Controller

SymbolsApplication

SelectParms()PlaceInstruction()

Instructions

InstructionTree

ins : integer

OpenTreeLeaf()GetLeafInfo()SelectInstruction()

Parameter

Tree Leafs

InstructionSpecification

Instruct Name : stringInstruct Type : intNumParms : intLeaf Name : stringSortOrder : int

Defines1 *

* *




Class-Responsibility-Collaboration (CRC) Cards CRC cards can be used as alternatives to Design Class Diagrams. CRC cards are intended to provide a more simplified approach in

identifying classes and their respective responsibilities. The approach is simplified since the CRC method is intended to

capture a high-level description of the purpose of the class. The class descriptions should fit on a 4 x 6 index card. This approach forces the descriptions to be concise and conceived

at a higher level. In addition to the responsibilities, collaborations with other classes

are defined. These collaborations indicate other classes that will fulfill a

portion of the listed responsibilities.




Class-Responsibility-Collaboration (CRC) Cards CRC cards contain three (3) primary components of information,

Class Name, Responsibility of the Class, and any Collaborations with other classes.

Symbol Table Controller

Responsibility Collaboration

Processes the externally generated windows symboltable messages by routing to the appropriate domainclass.

Symbol Table.

Symbol Table

Responsibility Collaboration

Initiate the symbol table application.

Display the symbol table.

Check the validity of the configured information. Handle Symbol Parameters

Save the configured information. Handle Symbol Parameters




System Sequence Diagrams System Sequence Diagrams are used to identify time ordering of

messages. These diagrams depict a set of objects and the messages sent to

and from these objects. System Sequence Diagrams can correspond to Use Case

Narratives. In this case, system events and system operations are modeled.

– System events are events that are generated from external stimuli.

– System operations are operations that occur as a result of a system event.




System Sequence Diagrams

Programmer System

SelectSymbolTable(Name)

System Sequence Diagram -- Configure Use Case

ConfigureSymbolInfo(Name : String, Address : Integer, Comment : String, DataType : Integer)

SaveParms(Name : String, Address : Integer, Comment : String, DataType : Integer)

ValidateParms(Name : String, Address : Integer, Comment : String, DataType : Integer)

DisplaySymbolTable(Name)




Contracts

A Contract is a document that expands upon each system event and system operation specified within a Sequence Diagram.

Its purpose is to provide specific information associated with each event or operation.

Primary components of the contract are exception conditions, pre-conditions, and post-conditions.

Pre-conditions are assumptions regarding the state of the system at the beginning of the operation.

Pre-conditions should describe:

– Conditions describing testing scenarios should be included.

– Conditions required for the success of the operation should also be included.




Contracts

Post-conditions are assumptions regarding the state of the system after the operation.

These are described as:

– Visualizing the system as a stage before the operation.

– Lower a curtain and initiating the operation.

– Raising the curtain and describing the changes on the stage. Post-conditions should describe:

– Instance creations and deletions.

– Attribute modifications.

– Associations that have been formed or broken. Exception conditions may also be specified within contracts. These

will typically be system type exceptions. Notes may also be included. These should include specific design

details and documentation.




Contracts

Contract Name: ConfigureSymbolInfo (Name : String, Address : Integer, Comment : String, DataType : Integer)

Responsibilities: This operation provides the ability to configure symbol information.

Type: System

Cross Reference: R9.x

Notes: The drives symbol table is provided as part of the drives add-in installation.

Exceptions:

Output:

Pre-Conditions:

1. The symbol table area must have focus.

2. The cursor must be positioned within the symbol address area.

Post-Conditions:

1. The symbol name, address, data type, and comment will be displayed consistent with the programmer's input.

2. The symbol address, data type, and comment was associated with the symbol name. (Association Formed)




Interaction Diagrams

Interaction type diagrams utilize information created during a “conceptual design phase” and begin the formulation of the “detailed design phase”.

Interaction diagrams depict message interactions between instances and classes defined in the class model.

The message interactions are obtained from the information specified within Contract post-conditions.

Two different types of interaction diagrams can utilized. These are collaboration diagrams or sequence diagrams.

– Collaboration diagrams depict interactions in a graphical or network format.

– Sequence diagrams depict interactions in a type of matrix format.

Collaboration diagrams appear to be more expressive and flexible.




Collaboration Diagramsby Controller

:SymTbl Controller

: SymbolTable

: HandleSymParms

: HandleSymParms

1: ConfigureSymbolInfo(Name : String, Address : Integer, Comment : String, DataType : Integer)

3: SaveParms(Name : String, Address : Integer, Comment : String, DataType : Integer)

2: ValidateParms(Name : String, Address : Integer, Comment : String, DataType : Integer)

Instance

First Message Parameters

Directionof

Message

Message #

Link Line




Collaboration Diagrams

Collaboration diagrams can be very expressive. As partially expressed in the previous example, the following

notations may be represented:

– Message Sequencing including Internal Object Messages.

– Message Parameters.

– Return Values.

– Iteration Clauses.

– Instance Creations.

– Conditional Messages.

– Conditional Message Paths.

– Collections.

– Messages to Multiple Objects.




Diagram Development Process Sequencing

Use Case Narratives Class

DiagramsUse Case Diagrams

Nouns Phrases

Sequence Diagrams

System Events & Operations

Contract Diagrams

System Events & Operations

Collaboration Diagrams

Post Conditions




References

Booch, Rumbaugh, and Jacobson, “Unified Modeling Language User Guide”, Addison-Wesley © 1999, ISBN 0-201-57168-4.

Rumbaugh, Jacobson, and Booch, “Unified Modeling Language Reference Manual”, Addison-Wesley © 1999, ISBN 0-201-30998-X.

Fowler and Scott, “UML Distilled: Applying the Standard Object Modeling Language”, Addison-Wesley © 1997, ISBN 0-201-32563-2.

Larsen, “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design”, Prentice Hall © 1998, ISBN 0-137-48880-7. (CSCI 311 - Object-Oriented Analysis and Design)

Rational Rose Professional Edition 1998. Several other books are also available. Please refer to the Addison

Wesley Object-Technology series.

object-oriented database systemscsci 397c-16 unified modeling language (uml) prepared by: keith...

Documents

u uml version

unified modeling language

agenda u uml

u version

u maintenance

u formal uml documentation

history of uml

recognized language