1. What Is the Unified Modeling Language ?

• The Unified Modeling Language (UML) is describe in The Unified Modeling Language for Object-Oriented Development written by Grandy Booch, Jim Rumbaugh, and Ivar Jacobson.
• Available from http:\\www.rational.com
• Based on the authors’ personal experiences
• Incorporates contributions from other methodologi
• Co-submitted to the OMG by Rational Software, Miscrosoft, Hewlett-Packard, Oracle, Texas Instruments, MCCI Systemhouse and others.

2. Inputs to UML

3. Evolution of the UML

4. Benefits of the Unified Modeling Language

• Defines a seamless mapping from analysis to design to implementation
• Defines an expressive and consistent notation
• Makes it easier to communicate with others
• Helps point out omissions and inconsistencies
• Supports both small and large-scale analysis and design

5. Objectives: Iterative and Incremental Development

To be able to:

• Define an iterative and incremental development process
• List the phases, the products and the major activities for each phase of an iterative and incremental development process
• Define an iteration and list its activities

6. System Behavior
Objectives:System Behavior
You will be able to:

• Define system behavior
• Define use cases and actors
• Understand how to document use cases
• Use a use case diagram to show the actors, the use cases, and their interactions
• Define scenarios for use cases

• System behavior is how a system acts and reacts
• The outwardly visible and testable activity of a system
• System behavior is captured in use cases
• They describe the system, its environment, and the relationship between the system and its environment

8. Major Concepts in Use Case Modeling

9. What is a Use-Case Model?

• A use-case model is a model of the system’s intended functions (use cases) and its surroundings (actors)
• The same use-case model is used in requirements analysis, design and test
• The use case model’s primary purpose is to communicate the system’s functionality and behavior to the customer or end user

• Is used to communicate with the end users and domain experts
• Provides buy-in at an early stage of system development
• Insures a mutual understanding of the requirements
• Is used to ideantify
• Who will interact with the system and what the system should do
• What interfaces the system should have
• Is used to verify
• All requirements are captured
• That the developers have understood the requirements

11. Actors

• Actors are not part of the system, they represent roles a user of the system can play
• An actor may actively interchange information with the  system
• An actor may be a passive recipient of information
• An actor can represent a human, a machine or another system

 

• A use case models a dialogue between actors and the system
• A use case in initiated by an actor to invoke a certain functionality in the system
• A use case is a complete and meaningful flow of events.
• Taken together, all use cases constitute all possible ways of using the system

 

• System specification/problem statement
• Domain relevant literature
• Interviews with domain experts
• Personal knowledge of the domain
• Legacy systems

• A use case diagram is drawn to illustrate that use cases and actors interacts by sending stimuli to one another.

 

Use cases are documented in

• A brief description
•   The purpose of the use case in a few lines
• Detailed flow of events
• Description of the primary and alternate flow of events that occur when the use is initiated
• Documentation should read like a dialogue between the actor and the use case

16. Objects and Classes

You will be able to :

• Define and give example of objects
• Define and give example of classes
• Description the relationship between classes and objects
• Define stereotypes

17. What  is an Object?

• Informally, an object represents an entity either physical, conceptual, or software
• An object is a concept, abstraction, or thing with sharp boundaries and meaning for an application
• An object is something that has :
• State
• Behavior
• Identity

• The state of an object is one of the possible conditions in which an object may exits
• The state of an object normally changes over time
• The state of an object is usually implemented by a set of properties (call attributes),with the value of the properties, plus the link the object may have with other objects

• Behavior determines how an object acts and reacts
• Behavior defines how an object reacts to requests from other objects
• The visible behavior of an object is modeled by the set of messages it can respond to(the operations the object can perform)

• Each objects has a unique identity, even if its state is identical to that of another object

• There are many objects identified for any domain
• A class is a description of a group of object with common properties(attributes), common behavior(operations), common relationships to other objects (associations and aggregations), and common semantics
• An object is an instance of a class
• A class is an abstraction in that it:
• Emphasizes relevant characteristics
• Suppresses other characteristics
• Abstraction help use deal with complexity

22. The Relationship Between Classes and Objects

• A class is an abstracts definition of an object
• It defines the structure and behavior of each object in the class
• It serves as a template for creating objects
• Object may be grouped into classes

23. Representing Classes

• A class is represented using a compartmented rectangle

 
 24. Class Compartments
A class is comprised of three sections

• The first section contains the class name
• The second section shows the structure(attributes)
• The third section show the behavior (operations)

25. Stereotypes

• A stereotype is a new type of modeling element that extends the semantics of the metamodel.
• They must be based on existing types or classes in the metamodel
• Every class may have at most one stereotype
• Common stereotypes
• Boundary class
• Entity class
• Control class
• Exception class
• Metaclass
• Utility class
• Stereotypes are shown in the class name compartment enclosed in << >>

26. Boundary Class

• A boundary class models communication between the system’s surroundings and its inner workings
• Typical boundary classes
• Windows(user interface)
• Communication protocol(system interface)
• Printer interface
• Sensors
• In the “Register for Courses” scenario, a Schedule Form is created to accept information from boundary.

27. Interfaces to Other Systems

• A boundary class is also used to model an interface to another system.
• The important characteristics of this type of boundary class are:
• The information to be passed to the other system
• The communication protocol used to “talk” to the other system
• In the “Register for Courses” scenario, information must be sent to the external Billing System
• A class called Billing System is created to hold the interface to the external system.

28. Entity Class

• An entity class models information and associated behavior that is generally long-live(persistent)
• It can reflect a real-life phenomenon
• It may also be needed for the internal tasks of the system
• The value of its attributes are often provided by an actor
• The behavior is surroundings-independent
• Entity classes in the “register for Courses “ ,use case
• Course
• Schedule
• Catalogue
• Course Roster

29. Control Class

• A Control class model control behavior specific to one or more use cases
• A control class
• Create, initializes and deletes controlled objects
• Control the sequencing or coordination of execution of controlled objects
• Controls concurrency issues for controlled classes
• Is, most of the time, the implementation of an intangible object
• In the “Register for Courses” scenario, a Registration Manager class control the registration process

• An interaction diagram is a graphical representation of interaction between objects
• There are two kinds of interaction diagrams
• Sequence diagram
• Collaboration diagrams
• Each provides a different view of the same interaction
• Sequence ->time order
• Collaborations -> data flow

31. Sequence Diagram

• A sequence diagram shows object interaction arrayed in time sequence
• The diagram shows
• The object participating in the interaction
• The sequence of messages exchanges
• A sequence diagram contains :
• Objects with their lifelines
• Message exchanged between object in ordered sequence
• Focus of control(optional)
 

• A collaboration diagram is an alternate way to represent the messages exchanged by a set of objects
• The diagram shows object interactions organized around the objects and their link to each other
• A collaboration diagram contain :
• Objects
• Links between object
• Message exchanged between objects
• Data flowing between objects, if any