UML Sole dee

Introduction
A model is an abstract representation of a system, constructed to understand the system prior to building or modifying it. A model is simplified representation of reality, because reality is too complex or large. Most modeling techniques used for analysis and design involve graphic languages. These graphic languages are sets of symbols. The symbols are used according to certain rules of methodology for communicating the complex relationships of information more clearly than descriptive text. The main goal of most CASE tools is to aid us in using these graphic languages, along with their associated methodologies.

 Use-case model. The use-case model defines the outside (actors) and inside (use-case) of the systems' behavior. Domain object model. Objects of real world are mapped into the domain object model. Analysis object model. The analysis object mode presents how the source code should be carried out and written. Implementation model. The implementation model represents the implementation of the system. Test model. The Test model constitutes the test plans, specifications, and reports.

 UML is a language for specifying, visualizing, documenting and constructing the artifacts of software systems, as well as for business modeling and other non-software systems. Grady Booch and James Rumbaugh started work to unite the Booch method and the OMT-2 method. As an object-oriented modeling language, all the elements and diagrams in UML are based on objectoriented paradigms. UML was developed having the RUP model in mind. This model is
Iterative and incremental Architecture centric Use case driven

Steps in UML
During requirements End product of design gathering we develop the Design classes, packages Use case diagram and subsystems Use case description Class diagram Supplementary State chart diagram specification Object diagram Analysis artifacts Describe run time architecture Analysis classes Identify active classes and Use case realization threads Sequence and Process diagram collaboration diagram Activity diagram Class diagram (if required) Describe distribution Deployment diagram

Views/Architecture of UML

Diagrams in UML
The UML defines nine graphical diagrams: Functional diagram
Use case diagram

Static view diagrams(Structural diagrams)

Class diagram Object diagram

Dynamic view diagram(Interaction diagrams)

State diagram Interaction diagram
Sequence diagram collaboration diagram

Activity diagram

Implementation diagram
Component diagram Deployment diagram

Use Case Model

A use case model consists of
Use cases Actors System modeled

A use case model is described in UML as a use case diagram (UCD)and a use case model can be divided into a number of use case diagrams.

Primary purpose of Use Case To decide and describe the functional requirements of the system To give a clear and consistent description of what the system should do. This allows the model to be used throughout the development process To provide a basis for performing system tests that verify the system To provide the ability to trace functional requirements into actual classes and operations in the system Relationship between use cases Extends relationship - it is a generalization relationship where one use case extends another by adding actions to a general use case. The extending use case may include behavior from the use case being extended, depending on conditions of extension. Uses relationship - it is a generalization relationship where one use case uses another use case, indicating that as part of the specialized use case, the behavior of the general use case will also be included. Grouping - when a number of use cases handle similar functionality or are related they can be bundled in a UML package.

Actors An actor is someone/something that interacts with the system. An actor can be a human being or another system. Actors can be ranked and they can be primary actors(they use systems main functionality ) or secondary actors(they use secondary functions of the system like managing Dbs, backups etc.) Actors can be active in which case they initiate an use case or they can be passive in which case they participate in an use case. They are classes in UML with stereotype <<actor>> and hence can have the same relationship as classes. In UCD only generalization relationship is used to describe common behavior among a number of actors.

Include vs Extends

College Use Case System

Example : Use Case Diagram

Use Case Description

Priority
The importance of this use case to the project.

Status
Where are we in developing this use case. How certain are we that it is correct and complete.

Preconditions
Assumptions made.

Post conditions
The state the system will be left in.

 Flow of Events
Either a numbered list or an activity diagram. Both could be included if that would improve clarity.

User Interface
If the use case interacts with people then include a description of the user interface, possibly using story boards.

Scenarios
A list of scenarios used, together with a brief description of what each does.

Other Requirements
Non functional requirements that impact this use case.

Class Diagram
Class diagrams show the static structure of the model, in particular, the things that exist (such as classes and types), their internal structure, and their relationships to other things A class in a class diagram can be directly implemented in an OOP language that has the construct for a class. To create a class diagram, the classes have to be identified and described and when a number of classes exist, they can be related to each other using a number of relationships.

Class
A class is drawn as a solid-outline rectangle with at most three compartments separated by horizontal lines. The top name compartment holds the class name and other general properties of the class (including stereotype) The middle compartment holds a list of attributes The bottom compartment holds a list of operations

The Object
OBJECT

Object Identity Object State

Attributes contained in data structures Procedures which can operate on the data structures

Object behaviour

20

 Example

Attribute An attribute is shown as a text string that can be parsed into the various properties of an attribute model element. where visibility is one of: + public visibility # protected visibility - private visibility

Relationships Notations
Association Aggregation Composition Generalization

Association
It is an structural, static relationship between two or more classes May be a reflexive association from a class to itself A binary association is drawn as a solid path connecting two class symbols Or-association specifies that objects of a class may participate in at most one of the associations at time.

Associations & Cardinality Class1 Exactly One (default) Association Name Class2 Class * Class

Zero or more
Optional (zero or one) One or more Numerically specified
24

0..1 Class

1.. * Class
1..5,8 Class

Cardinality Examples
Employee
Name:String Number:EmpNo 1..* Dept Name:Name 0..1

Member

Rent

Video

Customer

Has

Account
AccNo:Account Balance: Real

25

Aggregation
Represents a has-a (whole-part) relationship An object of the whole has objects of the part
Company

Department

Composition

Generalization
Single Inheritance

Multiple Inheritance

Example
General
Car

Specific
Estate Saloon Hatchback Coupe

29

Class Diagram
1 owns Customer contains 1..* Portfolio 1..* handles 1 Trader

0..* 0..*
Instrument

Bond
31

Stock

Stock Option

Sequence Diagram
A sequence diagram shows an interaction arranged in time sequence.
In particular, it shows the objects participating in the interaction by their lifelines and the messages that they exchange arranged in time sequence It does not show the associations among the objects Better for real-time specifications and for complex scenarios.

A sequence diagram has two dimensions

The vertical dimension represents time. Normally time proceeds down the page The horizontal dimension represents different objects. There is no significance to the horizontal ordering of the objects

ATM withdrawal

Message A message is a communication between objects that conveys information with the expectation that action will ensue The receipt of a message is one kind of event A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object The arrow is labeled with the name of the message (operation or signal) and its argument values The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction A message may also be labeled with a guard condition

Activity Diagram
Activity diagrams are an alternative way of showing the logical structure of the use case details. They are useful with more complex use cases, and provide a graphical way of detailing the algorithm. Components of an activity diagram are
Activities: rounded rectangle Decisions: diamond Guards on decisions: text inside [ ] Fork initiating parallel activity: solid bar Join terminating parallel activity: solid bar Start: solid circle, Stop: donut

Component Diagram
A component diagram is a graph of components connected by dependency relationships A component diagram shows the dependencies among software components
Source code components : components that exist at compile time Binary code components : components that exist at link time Executable components : components that exist at run time

Dependencies, are shown as dashed arrows from a client component to a supplier component that it depends on in some way

 The diagram may also be used to show interfaces and calling dependencies among components, using dashed arrows from components to interfaces on other components. The kinds of dependencies are language-specific and may be shown as stereotypes of the dependencies. A component diagram has only a type form, not an instance form To show component instances, use a deployment diagram

Interface

Realization

Dependency