Unified Modeling Language (UML)

Unified Modeling Language (UML)
The Three Amigos Unified Modeling Language (UML) P.S.Suryateja Asst. Professor CSE Department Vishnu Institute of Technology

Outline Introduction to UML Structural Modeling Importance of modeling
Principles of modeling Object oriented modeling Overview of UML Conceptual model of the UML Architecture Software development life cycle (RUP) Structural Modeling Classes Relationships Common mechanisms Diagrams Class diagrams Advanced classes Advanced relationships Object diagrams

Outline (cont…) Behavioral Modeling Architectural Modeling
Interactions Interaction diagrams Use cases Use case diagrams Activity diagrams Events and signals State machines State chart diagrams Architectural Modeling Components Deployment Component diagrams Deployment diagrams Common modeling techniques

Prerequisites Object orientation concepts Software engineering

Objectives Learn what is UML.
Learn why UML is relevant to developing software systems. Learn how to speak the language effectively. Learn how to apply UML.

Outcomes Ability to read UML models. Ability to develop UML models.

Software System - Definition
Software [Set of programs] (Source Code) + Configuration files, system documentation, end-user documentation, test results, maintenance records etc…

Software System - Examples
Operating systems Computer reservation systems Air traffic control systems Military command and control systems Telecommunication networks Content management systems Database management systems Expert systems etc…

Introduction to Modeling

Modeling What? How? Why? Where?

Model A model is a simplified representation of the real thing/system.
A model captures the important aspects of the thing being modeled. A model is expressed in a medium that is convenient for working.

Model (cont…) Construction

Model (cont…) Software Design

Modeling (cont…) What? Why? Where? How?
The art and science of developing models. Why? To understand the system in a better/easier way. Where? Design phase (most of the time). How? That is what UML is for.

Importance of Modeling
We build models to: Communicate the structure and behavior of the system. Visualize and control the system's architecture. Understand the system we are building in a better manner. Manage risks.

Principles of Modeling
The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Every model may be expressed at different levels of precision. The best models are connected to reality. No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.

Software Design

Object Oriented Analysis and Design
OOAD is a software engineering approach that models a system as a group of interacting objects. The notation for representing these models is UML. OOA focuses on what the system does. Models consists of use-case, class and interaction diagrams. OOD focuses on how the system does it. Detailed diagrams.

Object Oriented Modeling
Two approaches for developing models Algorithmic Perspective Object-Oriented Perspective Traditional approach Fundamental unit is function Functional decomposition Difficult to maintain Modern approach Fundamental unit is object or class Communication through messages Easy to maintain and enhance

What are Models For? To capture and precisely state requirements and domain knowledge so that all stakeholders may agree and understand them. To think about the system design. To capture design decisions in a mutable form separate from the requirements. To generate usable work products.

What are Models For? (cont…)
To organize, find, filter, retrieve, examine, and edit information about large systems. To explore multiple solutions economically. To master complex systems.

What is in a Model? Syntax Semantics Presentation

Modeling work process Sketching: Use informal tools such as whiteboard and Post-It notes Organization: Organize the informal sketch in a tool to produce more formal diagrams Specifying: Specify the details of the diagram (iterative process as more and more is learned about the model) Integrating, Verifying and Validating: Check the diagram against other diagrams, and verify and validate that requirements are correctly met. Prototyped and Tested: Make a prototype and test it (a number of diagrams may be prototyped in one step) Evaluate: Evaluate the result. Go back and correct any deficiencies. Ref: UML 2 Tool Kit by Eriksson, Penker, Lyons, Fado

Introduction to UML

UML - Introduction What? How? Why? Where?

UML – Introduction (cont…)
What? A modeling language for visualizing, specifying, constructing and documenting the artifacts of a software system. Why? UML is a industry standard modeling language. Where? Design phase (most of the time). How? That is what the subject is about.

UML Applicable Domains
Enterprise information systems Banking and Financial services Telecommunications Transportation Defense Retail Medical electronics Scientific Distributed web-based services

Why Unified? UML is unified across several domains:
Across historical methods and notations Across the development lifecycle Across application domains Across implementation languages and platforms Across development processes Across internal concepts

History of UML A major upgrade to UML at the end of 2003:
The Three Amigos History of UML Prehistory Fusion 1st unification attempt OMT, Booch, CRC Booch & Rumbaugh (OMT) join Rational Jacobson (Objectory) joins UML work begins Object Management Group RFP UML proposal accepted by OMG 1994 1995 1996 1997 Schlaer/ Mellor Booch (OMT) Coad/ Yourdon becomes an industry standard 2004 2003 UML 1.x UML 2.0 Ongoing UML development A major upgrade to UML at the end of 2003: Greater consistency More precisely defined semantics New diagram types Backward compatible Latest Version: 2.4.1 Published on Aug 2011

Overview of UML UML Visualizing Specifying Constructing Documenting

UML is a Language for Visualizing
Problems with non-standard modeling (textual): Communicating conceptual models to others is error-prone unless everyone involved speaks the same language. There are some things about a software system you can't understand unless you build models. If the developer who created the code never wrote down the models that are in his or her head, that information would be lost forever.

UML is a Language for Specifying
Specifying means building models that are precise, unambiguous and complete. UML addresses the specification of all important decisions regarding: Analysis Design Implementation

UML is a Language for Constructing
UML models can be directly connected to various programming languages such as Java, C#, VB etc. Forward engineering Reverse engineering Round trip engineering

Forward Engineering Example
Customer - cid - cname - mobile - + purchase( ) + login( ) + logout( ) + search( ) class Customer { private int cid; private String cname; private String mobile; private String ; public void purchase( ) { … } public void login( ) { … } public void logout( ) { … } public void search( ) { … } }

Reverse Engineering Example

Roundtrip Engineering Example

UML is a Language for Documenting
UML addresses the documentation of a system's architecture and all of its details. UML provides a language for expressing requirements and for tests. UML provides a language for modeling the activities of project planning and release management.

Conceptual Model of UML

Conceptual Model of UML
UML building blocks (syntax) Rules (semantics) Common mechanisms

UML Building Blocks

Structural Things

Behavioral Things

Grouping Things

Annotational Things

Relationships in UML Dependency Association Generalization Realization

Diagrams Class diagram Object diagram Use case diagram
Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram

Common Mechanisms Specifications Adornments Common divisions
Extensibility mechanisms Stereotypes Tagged values Constraints

Software Architecture

Architecture Development View Logical View Physical View
Programmers & software managers End user Development View Logical View Integrator System Engineer Physical View Developed by Philippe Kruchten

Architecture Vs Design
Overall System (Architecture) Specific Subsystem (Design)

Unified Process

Software Development Life Cycle
Rational Unified Process (RUP)

Unified Process The Unified Software Development Process is an industry standard software engineering process It is commonly referred to as the "Unified Process" or UP It is the generic process for the UML It is free - described in "The Unified Software Development Process", ISBN: " UP is: Use case (requirements) driven Risk driven Architecture centric Iterative and incremental UP is a generic software engineering process. It has to be customised (instantiated) for your project In house standards, document templates, tools, databases, lifecycle modifications, … Rational Unified Process (RUP) is an instantiation of UP RUP is a product marketed and owned by Rational Corporation RUP also has to be instantiated for your project

RUP - Inception Inception Elaboration Construction Transition Requirements – establish business case and scope. Capture core requirements Analysis – establish feasibility Design – design proof of concept or technical prototypes Implementation – build proof of concept or technical prototype Test – not generally applicable Focus Goals Establish feasibility of the project - create proof of concept/technical prototypes Create a business case Scope the system - capture key requirements Identify critical risks

RUP - Elaboration Requirements – refine system scope and requirements
Inception Elaboration Construction Transition Requirements – refine system scope and requirements Analysis – establish what to build Design – create a stable architectural baseline Implementation – build the architectural baseline Test – test the architectural baseline Focus Goals Create an executable architectural baseline Refine Risk Assessment and define quality attributes (defect rates etc.) Capture use cases to 80% of the functional requirements Create a detailed plan for the construction phase Formulate a bid which includes resources, time, equipment, staff, cost

RUP - Construction Focus
Inception Elaboration Construction Transition Requirements – uncover any requirements that had been missed Analysis – finish the analysis model Design – finish the design model Implementation – build the Initial Operational Capability Test – test the Initial Operational Capability Focus Goals Complete use case identification, description and realization Finish analysis, design, implementation and test Maintain the integrity of the system architecture Revise the Risk Assessment

RUP - Transition Correct defects
Prepare the user site for the new software and tailor the software to operate at the user site Modify software if unforeseen problems arise Create user manuals and other documentation Provide customer consultancy Conduct post project review Inception Elaboration Construction Transition Requirements – not applicable Analysis – not applicable Design – modify the design if problems emerge in beta testing Implementation – tailor the software for the user site. Fix bugs uncovered in beta testing Test – perform beta testing and acceptance testing at the user site Focus Goals

Hello World Example

Example : Hello World import java.awt.*; import java.applet.*;
public class HelloWorld extends Applet { public void paint(Graphics g) g.drawString(“Hello World”, 10, 10); }

Example : Hello World (cont…)
paint( ) g.drawString(“Hello World”, 10, 10)

Applet HelloWorld paint( ) Graphics

Object Component Container Panel Applet HelloWorld

Structural Modeling

Structural Modeling Structural models represents the structural elements composing a system or function. These models reflect the static relationships of a structure. Class diagrams, object diagrams, component diagrams and deployment diagrams.

Classes

Classes A class is a collection of similar (attributes, operations, relationships) objects. Classes are used to capture the vocabulary of the system. Class is represented as a rectangle in UML.

Classes - Example

Classes - Name A class name is a textual string.
Every class must have a name that distinguishes it from every other class. A class name may contain any number of letters, numbers and punctuation marks except : which is used to separate a class from its package. A class name always starts with a uppercase letter.

Classes – Name (cont…) Simple names Path name

Classes - Attributes An attribute is a named property.
These attributes are similar for all the objects of the class. Graphically the attributes are listed in a compartment below the class name. The first letter in the attribute name will be in lowercase and the first letter of the rest of the words will be in uppercase.

Classes – Attributes (cont…)
Attributes may be represented only with names or along with the type and an initial value.

Classes - Operations An operation is an implementation of service that can be requested from any object of the class to affect its behavior. These operations are similar for all the objects of the class. Operations are listed in a compartment below the attributes compartment.

Classes – Operations (cont…)
An operation may be represented only with its name or along with the parameters or with the return type.

Classes - Responsibilities
A responsibility is the contract of a class that specifies that the objects of that class will have the same attributes and operations. The attributes and operations are the features by which the class’s responsibilities are carried out. Graphically responsibilities can be modeled in a separate compartment at the bottom of the class icon.

Classes – Responsibilities (cont…)
Responsibilities are represented just as plain text. A well-structured class will have one or more responsibilities. Responsibilities can be gathered by using techniques like CRC cards and use case analysis.

Classes – Responsibilities (cont…)

Common Modeling Techniques - Modeling the Vocabulary of a System
To model the vocabulary of a system: Identify those things that users or implementers use to describe the problem or solution. Use CRC cards and use case-based analysis to help find these abstractions. For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes. Provide the attributes and operations that are needed to carry out these responsibilities for each class.

Common Modeling Techniques - Modeling the Vocabulary of a System

Common Modeling Techniques - Modeling the Distribution of Responsibilities in a System
To model the distribution of responsibilities in a system: Identify a set of classes that work together closely to carry out some behavior. Identify a set of responsibilities for each of these classes. Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own. Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little.

Common Modeling Techniques - Modeling the Distribution of Responsibilities in a System

Common Modeling Techniques - Modeling Non-software Things
To model non-software things: Model the thing you are abstracting as a class. If you want to distinguish these things from the UML's defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give a distinctive visual cue. If the thing you are modeling is some kind of hardware that itself contains software, consider modeling it as a kind of node, as well, so that you can further expand on its structure.

Common Modeling Techniques - Modeling Non-software Things

Common Modeling Techniques - Modeling Primitive Types
To model primitive types: Model the thing you are abstracting as a type or an enumeration, which is rendered using class notation with the appropriate stereotype. If you need to specify the range of values associated with this type, use constraints.

Common Modeling Techniques - Modeling Primitive Types

Relationships

Relationships The classes in the models generally collaborate with each other in a number of ways. Most of the classes will have connections with other classes known as relationships. Three main relationships: Dependency Generalization Association

Relationships - Example
Dependency Generalization Association

Dependency A dependency is a using relationship.
Dependency is represented graphically as a dashed directed line. The dependency is directed towards the thing being used.

Dependency – Example

Generalization Generalization is often called as “is-a” relationship.
Generalization is a relationship between a general thing and a specific thing. Generalization specifies that the object of a child can be used at any place where the object of the parent is used.

Generalization (cont…)
Generalization is represented as a solid directed line with a large open arrow head pointing towards the general thing.

Association An association is a structural relationship. It specifies that objects of one thing are connected to objects of another thing. An association can be specified on the same class or between two classes or between more classes. An association is represented graphically as a solid line connecting two things.

Association - Name An association can have a name. It specifies the type of relationship between the things it is connecting. We can give a direction to the name by providing a direction triangle that point in the direction you intend to read the name

Association - Role A class plays a specific role in an association relationship. The role is represented under the association and close to the class icon.

Association - Multiplicity
While modeling, it is important to specify how many objects may be connected across an association. That “how many” is known as the multiplicity of the association.

Association - Aggregation
While modeling, sometimes we might want to represent “Whole/Part” relationship. In this relationship, one thing acts as whole, while the other thing is a part of this whole thing. Such relationship is known as aggregation or also called as “has-a” relationship. An aggregation is represented graphically by adorning an association with a open diamond at the whole end.

Association – Aggregation (cont…)

Common Modeling Techniques - Modeling Simple Dependencies
To model this using relationship: Create a dependency pointing from the class with the operation to the class used as a parameter in the operation.

Common Modeling Techniques - Modeling Single Inheritance
To model inheritance relationships: Given a set of classes, look for responsibilities, attributes, and operations that are common to two or more classes. Elevate these common responsibilities, attributes, and operations to a more general class. If necessary, create a new class to which you can assign these elements (but be careful about introducing too many levels). Specify that the more-specific classes inherit from the more-general class by placing a generalization relationship that is drawn from each specialized class to its more-general parent.

Common Modeling Techniques - Modeling Single Inheritance

Common Modeling Techniques - Modeling Structural Relationships
To model structural relationships: For each pair of classes, if you need to navigate from objects of one to objects of another, specify an association between the two. This is a data-driven view of associations. For each pair of classes, if objects of one class need to interact with objects of the other class other than as parameters to an operation, specify an association between the two. This is more of a behavior-driven view of associations. For each of these associations, specify a multiplicity (especially when the multiplicity is not *, which is the default), as well as role names (especially if it helps to explain the model). If one of the classes in an association is structurally or organizationally a whole compared with the classes at the other end that look like parts, mark this as an aggregation by adorning the association at the end near the whole.

Common Modeling Techniques - Modeling Structural Relationships

Common Mechanisms

Common Mechanisms The extensibility features provided by UML to represent additional information over the basic UML notations are the common mechanisms. The common mechanisms in UML are: Notes Adornments Stereotypes Tagged Values Constraints

Note Note is an annotational thing in UML.
Note is used to specify: requirements, observations, reviews, explanations, constraints and other comments. Note is graphically represented as a rectangle with a dog ear at the top right corner.

Note - Example Node Note Processor: Intel Core i7 Server RAM: 8GB
HDD: 1PTB

Adornments Adornments are textual or graphical elements that are added to the basic UML notations to specify extra information. Example: Client bill.exe report.exe contacts.exe Anonymous compartment (Adornment)

Extensibility Mechanisms
To represent additional information over the basic notations like class, use case, association etc, UML provides extensibility mechanisms. Extensibility mechanisms in UML are: Stereotypes (extends the building blocks) Tagged Values (extends the properties) Constraints (extends the semantics)

Stereotypes As we know UML provides basic elements or building blocks. For example, consider a class. A class’s basic notation is a rectangle with three compartments. Sometimes while creating software blueprints, we might want to represent some elements visually which are not available in UML. For example, in a deployment diagram, I want to represent a router. UML does not provide a notation for a router.

Stereotypes (cont…) So, I must create a new visual representation (icon) for a router. How? UML already provides a concept known as stereotype using which we can create new building blocks. Using stereotypes we create new or extend the existing building blocks. Stereotypes are represented using guillemets (<< >>)

Stereotypes - Examples
<<interface>> Movable Named stereotype Named stereotype with icon <<exception>> Underflow <<Router>> Digicom AX00 Stereotyped element as icon

Tagged Values Every UML element has its own properties. For example, a class has its own attributes and operations which apply to all its instances. To represent i.e., extend the properties of an element UML provides tagged values. Tagged values are represented as text enclosed in braces { }, and placed under the element name.

Tagged Values - Example
Server {processors = 3} <<library>> trans.dll {serverOnly} Tagged value Value of tag

Constraints Constraint is mechanism provided by UML to add a new rule or modify the existing rule (semantics) on an element. Constraints are represented as text enclose in braces { } and placed beside the associated element.

Constraints - Example Person owner Bank Account {xor} constraint
Corporation owner

Constraints - Example

Diagrams

Diagrams Modeling (creating blueprints) is about creating a simplification or abstraction of the end software system. Modeling involves creating different diagrams. A diagram is a collection of vertices and edges according to graph theory (mathematics). In UML, these vertices are things and edges are replaced with relationships.

Diagrams (cont…) Diagrams Structural Diagrams Behavioral Diagrams
Class Diagrams Object Diagrams Implementation Diagrams Component Diagrams Deployment Diagrams Use Case Diagrams State Chart Diagrams Activity Diagrams Interaction Diagrams Sequence Diagrams Collaboration Diagrams

Diagrams - Overview Diagram Elements Purpose View Class Diagram
Class, Interface, Collaboration and Relationships To model the structure/skeleton of the software system Static design view Static process view (active classes) Object Diagram Objects and Relationships To model the structure of the software system Component Diagram Components and Relationships To model the components in the software system Static Implementation view Deployment Diagram Nodes and Relationships To model the runtime structure of the software system Static Deployment view Use Case Diagram Use cases, actors and relationships To model the behavior of the system Static use case view Sequence Diagram Objects and messages To model the time ordering of messages Dynamic view Collaboration Diagram To model the structural organization of the objects Statechart Diagram States, transitions, events and activities To model the behavior as a sequence of state changes Activity Diagram Activities, transitions and other control flow symbols To model the behavior as a set of activities

Advanced Classes

Classifiers An modeling element that can have an instance is a classifier. Examples: classes, usecases, nodes, components etc..

Classifiers (cont…)

Classifiers - Examples

Classifiers – Examples (cont…)
Description Class A class is a blueprint or a template for its objects Interface An interface is a collection of operations that must be realized by another element Datatype A type whose values have no identity Signal An asynchronous event communicated between objects Component Physical replaceable part of the system Node A physical existing at runtime which represents a computational resource Use case Collection of actions that a role performs on the system or the system does for a user. Sub system A grouping of elements which specify the behavior of a part of the system

Advanced Classes We know that the basic notation of a class in UML is a rectangle with three compartments. UML also allows to specify more information over this basic notation such as: Visibility Scope Abstract, root, leaf and polymorphic elements Multiplicity Advanced attributes Advanced operations

Visibility The visibility feature of a classifier allows us to specify the accessibility of a certain classifier feature. Four access specifiers in UML: Symbol Name Description + Public Accessible by all other classifiers # Protected Accessible only by the descendents and the classifier itself ~ Package Accessible by all the classifiers with the same package - Private Accessible only by the classifier in which they are available

Visibility - Example Student - sid - sname - rollno # email # mobno
+ register( ) + login( ) + logout( )

Scope A feature that can be applied to a classifier’s attributes and operations that specifies their existence in all of its instances or existence of only one copy. Scope Description instance Each instance of the classifier contains a value of the feature classifier One copy of the feature’s value is shared by all the instances of a classifier

Scope - Example Cse Student - sid - sname - rollno # email # mobno
+ branch : String = CSE Classifier scope + register( ) + login( ) + logout( )

Abstract, Root, Leaf and Polymorphic elements
An abstract class can be represented in UML with the class name represented in italics. A class without any parents is a root class. A root class can be represented as a class tagged with {root} property. A class without child class(s) is a leaf class. A leaf class can be represented as a class tagged with {leaf} property. Abstract methods or polymorphic methods are also represented in italics similar to abstract classes.

Abstract, Root, Leaf and Polymorphic elements - Example

Multiplicity The multiplicity feature of a class allows us to specify the number of instances a class can have. The multiplicity can be applied to the class itself and to attributes also. The multiplicity of a class is specified at the top right corner of the class symbol. The multiplicity of an attribute is specified after the attribute name within square brackets.

Multiplicity - Example
Car engine [1] wheel [4] door [4] horn move() 1

Attributes The syntax of an attribute is as follows:
[visibility] name [multiplicity] [: type] [=initial value] [{property string}] Some examples: origin Name only + origin Name and visibility origin : Point Name and type head : *Item Name and complex type name [0..1] : String Name, multiplicity and type origin : Point = {0,0} Name, type and initial value id : Integer {frozen} Name and property

Attributes (cont…) The three predefined properties that can be used with attributes in UML are: changeable No restrictions on modifying the attributes value addOnly For attributes with multiplicity greater than one, values may be added but not removed or altered once it is created frozen Once created the value of an attribute cannot be changed

Attributes - Example Student - sid {frozen} - sname - rollno {frozen}
# + marks {addOnly} + register( ) + login( ) + logout( )

Operations The syntax of an operation in UML is as follows:
[visibility] name [(parameters-list)] [: return-type] [{property-string}] Some examples: origin Name only + origin Name and visibility origin : Point Name and type head : *Item Name and complex type name [0..1] : String Name, multiplicity and type origin : Point = {0,0} Name, type and initial value id : Integer {frozen} Name and property

Operations (cont…) The syntax of a parameter in the parameters list as follows: [direction] name :type [=initial value] Direction may be any one of the following: in An input parameter, may not be modified out An output parameter, may be modified inout An input parameter, may be modified

Operations (cont…) There are four predefined properties that can be applied to the operations in UML: isQuery Execution of the operation does not change the state of the system. sequential Denotes that the operation is suitable for sequential access only. guarded Indicates that the operation guarantees integrity in case of concurrent access. Concurrent calls will be performed in a sequential manner. concurrent Denotes that the operation can be called concurrently and the integrity of the object will be preserved. Operation executes on the object concurrently.

Advanced Relationships

Advanced Relationships
We can represent additional information over the basic representation of the relationships: Dependency Generalization Association

Dependency Dependency relationship is also known as the using relationship. When one thing uses another thing, such relationship is represented using a dependency. Basic representation of a dependency is as shown below: Source Target

Dependency (cont…) Eight stereotypes that can be applied to dependency between classes are: bind Specifies that the source instantiates (creates object) the target template using the given actual parameters derive Specifies that the source may be computed from the target friend Specifies that the source is accessible by the target regardless of the visibility of the source element instanceOf Specifies that the source object is an instance of the target classifier instantiate Specifies that the source creates instances of the target powertype Specifies that the target is a powertype of the source. A powertype is a classifier whose objects are the children of a given parent. refine Specifies that the target is at a lower level of abstraction than the source use Specifies that the source element depends on the target for its functionality.

Dependency (cont…) Examples: <<bind>> TList T DoubleList
IntegerList <<bind>> <<derive>> Grade class Evaluate calSum() calAvg() calGrade() : Grade <<derive>>

Dependency (cont…) <<friend>> Graphics - drawString()
- drawOval() DrawObject create() delete() <<friend>> <<instanceOf>> manoj : Student Student <<instanceOf>> <<instantiate>> HTML Editor HTML Page <<instantiate>>

Dependency (cont…) <<powertype>> Car Vehicle
<<refine>> Order <<refine>> dateOfOrder amount shippmentDate recordShippment() <<use>> Order <<use>> OrderItem

Dependency (cont…) Two stereotypes that can be applied to dependency between packages: access Specifies that the source package has the right to access the elements of the target package import Specifies that the public elements of the target package enter the namespace of the source package as if they were declared in the source. Examples: UI Graphics <<access>> UI Graphics <<import>>

Dependency (cont…) Two stereotypes that apply to dependency between use cases: extend Specifies that the target use case extends the functionality of the source use case include Specifies that the source use case incorporates the behavior of the target use case to function as a whole. Examples: Login Change Password <<extend>> Withdraw Money Card Validation <<include>>

Dependency (cont…) Three stereotypes that apply to dependency among objects: become Specifies that the source object becomes the target object at some point in time call Specifies that an operation in source calls another operation of the target copy Specifies that the target is an exact, but independent copy of the source

Dependency (cont…) Examples: e1 : Employee role = employee
role = manager <<become>> s1: Student ev : Evaluator <<call>> c1: Car c2 : Car <<copy>>

Dependency (cont…) One stereotype that applies to dependency in the context of state machines: send Specifies that the source, an operation whose target is a signal, sends the target signal One stereotype that applies to dependency in the context of subsystem: trace Specifies that the source element has a conceptual connection to the target which individually belong to different models Student S1 : Student <<trace>>

Generalization Used to represent parent-child or generalization- specialization relationships. Also known as is-a relationship. Basic representation of a generalization relationship is a solid line with hollow arrow head.

One stereotype can be applied on generalization: implementation Specifies that the child inherits the implementation of the parent but does not support its interfaces, there by violating the principle of substitutability.

Four constraints can be applied on generalization relationship: complete Specifies that no additional children are permitted incomplete Specifies that additional children are permitted disjoint Specifies that the objects of the parent may not have more than one of the children as a type overlapping Specifies that the objects of the parent may have more than one of the children as a type.

Association A semantic relationship which specifies a connection between two things is the association. Basic representation of an association is a solid line. Over the basic notation, we can represent much more information like: Navigation Visibility Qualification Composition Association Class

Association - Navigation
A directed association specifies the ability to navigate from one thing to another. Navigability is represented as a stick arrow head.

Association - Navigation
Example Order Products contains

Association - Visibility
We can specify the visibility of the things that participate in the association relationship. With the access specifiers on roles we can limit the visibility of a thing from other things outside the association relationship.

Association - Visibility
Example UserGroup User Password +user +owner -key

Association - Qualification
This feature of an association allows one thing in the association to identify a set of the instances of another thing. Such mechanism is known as qualification. The attributes set which is used to identify a set of instances is known as a qualifier. A qualifier is represented as text inside a rectangle which is attached to the corresponding instance.

Association - Qualification
Example Bank Person accountNumber : int account holder 1 1..*

Association – Association Class
In association relationship, sometimes, the association might have attributes or operations like a class. In such cases, we can model such behavior as an association class. An association class is represented as a class symbol attached to the association with a dashed line.

Association – Association Class
Example Person Company 1..* * employer employee Job description dateHired salary

Association - Composition
In association relationship, if one thing is a part of another thing, such relationships are known as aggregations. In a whole-part relationship like aggregation if the life cycle of the part tightly depends on the life cycle of the whole, such relationships are known as compositions. Compositions are represented as solid lines with solid diamond head.

Association - Composition
Example Department College part of

Association (cont…) Along with the features mentioned before there are six constraints which can be applied on the association: implicit Specifies that the relationship is not physical, but rather conceptual ordered Specifies that the objects at one end of the association are in a certain order changeable Links between objects can be added, removed addOnly New links may be added from an object on the opposite side of the association frozen After adding a link it might not be modified later xor Indicates that among a set of associations, only one can be applied for each object

Realization A semantic relationship in which one thing provides the specification and the other thing provides the implementation for that specification is the realization. A realization is graphically represented as a dashed line with hollow arrow head which points the thing providing the specification.

Realization – Examples
<<interface>> Parser HTMLParser scan() parse() Htmlparser.dll Parser Validate User Validation

CRC (Class-Responsibility-Collaborator) Cards
Introduced by Beck & Cunningham (1989) Online Shopping System

Class Diagram

Class diagram Class diagram is used to model the static design view of the system. A class diagram contains: Classes Interfaces Collaborations Generalization, dependencies and associations

Class diagram – Common Uses
Class diagrams are commonly used for: Modeling the vocabulary of the system Modeling the collaborations Modeling the logical database schema

Class diagram - Example

Object Diagram

Object diagram An object diagram allows us to model the instances of classes in a class diagram. Object diagrams are used to model the static design view of the system. An object diagram contains: Objects Links

Object diagram – Example

Class and Object Diagrams

Behavioral Modeling

Behavioral Modeling Behavioral modeling involves modeling the dynamic aspects of the software system. The dynamic aspects comprises of the behavior represented as: Messages States Activities and more…

Use Case Diagram

Use Cases Use cases specify what the system does for its users.
A use case specifies part of the functionality provided by the system. Use case concept was introduced by Ivar Jacobson

Use Cases (cont…) An use case is defined as “a set of actions performed by the system, which produces an observable result that is, typically, of some value to one or more actors or other stakeholders of the system”. Use cases are connected to actors through associations.

Use Cases (cont…) Use case is one of the classifiers in UML.
An instance of use case is known as a scenario. Use case is graphically represented as a hollow ellipse.

Library :: Make Reservation
Use Cases – Example Order product Library :: Make Reservation Validate user Simple Names Path Name

Describing Use Cases Use case description includes:
Objective of the use case How the use case is initiated Flow of messages between actors and the use case Alternate flow in the use case How the use case finishes and its value to the actor

Actors An actor is one which uses or interacts with the software system (subject). Actor can be a person or another system (logical or physical). Use case is always initiated by an actor by sending a message. This message is know as the stimulus.

Actors (cont…) Actors are of two types:
Active actors Passive actors Actor is graphically represented as a stickman or as a class symbol stereotyped as actor.

Organizing Use Cases We can use packages to group related use cases.
We can use generalization relationship between general and specific use cases. We can separate common behavior using include dependencies and separate optional behavior using extend dependencies.

Organizing Use Cases - Packages
College Information System

Organizing Use Cases - Packages
Use cases in the library package

Organizing Use Cases - Generalization

Organizing Use Cases (cont…)

Use Case Diagrams Use case diagrams model the static use case view of a software system. Specifies what the system does. Use case diagram contains: Use cases Actors Associations, dependencies and generalizations

Use Case Diagram – Example

Interaction Diagrams

Interactions Interaction is a collection of messages that are exchanged between objects. A message can be an invocation or operation or a signal. Using interaction diagrams we can model the flow of control in two ways: By focusing on the time ordering of messages. By focusing on the structural organization of the objects.

Interactions - Example
message sendDetails(u,p) u : User v : Validator Link object object

Interactions (cont…) A link is a semantic connection between the objects. A link is an instance of an association. Following stereotypes can be applied on links: association Specifies that the corresponding object is visible by association Self Specifies that the corresponding object is visible as it is the dispatcher of the operation Global Specifies that the corresponding object is visible as it is in an enclosing scope Local Specifies that the corresponding object is visible as it is in local scope parameter Specifies that the corresponding object is visible as it is a parameter

Person 1..* 1 Company +setSalary(s : String) +assign(d : Department) employee employer assign(development) p : Person : Company

Interactions (cont…) A message is the specification of communication among objects that conveys information with the expectation that activity will succeed. An action takes place when a message is sent. UML allows us to model following actions: Call Invokes an operation on an object Return Returns a value to the caller Send Sends a signal to the object Create Creates an object Destroy Destroys an object

Interactions – Sequencing
In case of nested messages or to explicitly specify the order of the messages we can use sequence numbers. Prefix the message name with a sequence number followed by a colon ( : ).

Interactions – Sequencing (cont…)
There are two types of control flows: Procedural flow of control Flat flow of control Procedural flow of control is represented as a solid line with solid arrow head. Flat flow of control is represented as a solid line with stick arrow head.

Interactions – Sequencing (cont…)
2 : clickAt(p) 2.2 : putRecentPick(I) : View c : Controller : Cache 2.1 : I = findAt(p) 1 : liftHandset() 2 : assertCall() c : Caller : Telephone : Exchange

Interaction diagrams Interaction diagrams are used to model the interactions among objects. There are two types of interaction diagrams: Sequence diagrams Collaboration diagrams

Sequence Diagrams A sequence diagram focuses on the time ordering of messages. Objects are arranged at the top along the x-axis. Messages are arranged from top to bottom along the y-axis.

Sequence Diagrams (cont…)
Two distinctive features of a sequence diagram: Object life line Focus of control

Sequence Diagrams (cont…)

Collaboration Diagrams
A collaboration diagram focuses on the structural organization of the objects in an interaction. First the objects are plotted and then the objects are connected through links. Then, the messages are represented.

Collaboration Diagrams (cont…)
To denote the order of messages we can use sequence numbers. Two distinctive features of a collaboration diagram: Paths Sequence number

Collaboration Diagrams (cont…)

Activity Diagrams

Activity Diagrams Activity diagram is used to model the behavior of a system in terms of flow of control between activities. Activity diagram contains: Action and activity states Transitions Objects

Activity Diagrams (cont…)
Action is an atomic computation. Activity is a non-atomic computation. Both action and activity states are represented as a rounded rectangle or the lozenge symbol. Simple action Enter User Details expression result := getAvg() + 20;

Activity Diagrams (cont…)
An activity state can have additional details like entry and exit actions. Make Payment entry / Select Product

Activity Diagrams - Transitions
A transition is a path from one action or activity state to another which represents the flow of control. Make Payment Select Product Start state Stop state

Activity Diagrams - Branching
We can represent alternate flows of control using the decision symbol which is graphically represented as a diamond. A decision symbol can have one incoming transition and two or more outgoing transition. The flow of control branches based on a boolean expression which is known as a guard condition. A guard condition is represented in square brackets.

Activity Diagrams - Branching

Activity Diagrams – Fork and Join
Sometimes, we might want to represent parallel or concurrent flow of control. To represent the transformation of sequential flow of control into concurrent flow, we use a fork. To represent the transformation of concurrent flow of control into sequential flow, we use a join.

To represent a fork and join we use horizontal or vertical synchronization bars. At a fork, the flow of control above the synchronization bar is sequential and below the bar, the flow is concurrent. At a join, the flow of control above the synchronization bar is concurrent and below the bar, the flow is sequential.

Activity Diagrams – Swimlanes
When a activity diagrams become more and more complex and you want to visually distinguish the activities that belong to a certain object, you can use a swimlane. A swimlane is a semantic group or collection of all the activities that belong to a particular object.

A swimlane is visually represented as a vertical box. Transition can move across from one swimlane to another but never does a activity or action state crosses from one swimlane to another.

Events and Signals

Events and Signals In UML, we can model the behavior either through interactions or as a sequence of state changes in a object. An event is a stimulus which causes an object to move from one state to another. An event can be any one of the following: Signal Call Passage of time Change in state

Events and Signals (cont…)
An event can be visually represented as text or using a stereotyped class symbol.

There are two types of events: Internal events External events External events are the events passed between the system and a user. Internal events are the events passed within the system.

A signal is a named object that is sent asynchronously by one object and then received by another. Exceptions are the famous examples for signals. In UML, we can model the signals that an operation can send as a dependency stereotyped with signal.

A call event represents the dispatch of an operation from one object to another. A call event, in general, is synchronous.

A time event represents the passage of time. In UML, we model the time event using the after keyword followed by an expression that evaluates a period of time. A change event represents an event that represents a change in state or the satisfaction of some condition. In UML, change event is modeled using the keyword when followed by some Boolean expression.

State Machine

State Machines A state machine is a behavior that represents the sequences of states that an object undergoes during its lifetime in response to events, together with its responses to those events. The state of an object is a condition or situation during the life of an object during which it satisfies some condition, performs some activity or waits for some event.

State Machines (cont…)

A state is graphically represented as a rectangle with rounded corners. A state can be divided into five parts: Name A textual string which distinguishes one state from other states Entry/exit actions Actions executed on entering and exiting the state Internal transitions Transitions that are handled without causing a change in state Substates The nested structure of a state, involving disjoint or concurrent substates Deferred events A list of events that are not handled in that state, but are postponed or queued for handling by the object in another state

A transition is a relationship between two states indicating that an object in one state will perform certain actions and enter another state when a specified event occurs and specified conditions are satisfied. A transition has five parts: Source state The state affected by the transition Event trigger The event whose reception changes the state of the object Guard condition A boolean expression which is evaluated when the transition is triggered Action An executable atomic computation that is performed on or by an object Target state The state that is active after the completion of the transition

A transition is visually represented as a solid directed line from source state to target state.

Advanced States UML allows us to represent more advanced information in a state like: Entry and exit actions Internal transitions Activities Deferred events

State Machines – Substates
A substate is a state included in another state. In UML, we render a composite state just like a normal state, but with an optional graphic compartment that shows a nested state machine. Substates may be nested to any level.

State Machines – Substates (cont…)

There are situations in which we might want the state machine to remember the last substate that was active prior to leaving the composite state. A history state allows a composite state that contains sequential substates to remember the last substate that was active in it prior to the transition from the composite state. In UML, a history is represented as a hollow circle with the symbol ‘H’

Concurrent substates allow us to specify two or more state machines that execute in parallel in the context of the enclosing object. Each concurrent substate is divided from each other with a dashed line.

State Chart Diagrams A state chart diagram models the flow of control from one state to another state of an object. A state chart diagram contains: States Transitions

State Chart Diagrams (cont…)
State machine for an ATM

Architectural Modeling

Components

Components A component is a physical replaceable part of a system.
Examples of components include: Source code files Executables Libraries Tables Files Documents

Components (cont…) Some more examples: ActiveX Control Java Bean
Web Page Web Server Firewall Style Sheet Database etc…

Components (cont…) Components are the physical elements that contain the logical elements like classes, interfaces etc… A component is graphically represented as tabbed rectangle.

Components (cont…)

Components (cont…) Components Vs Classes:
Components are physical things, whereas, classes are logical abstractions. Components are at a higher level of abstraction than a class. Components only contain operations, whereas, a class can have both attributes and operations.

Components (cont…) The relationship between a component and its classes can be represented using dependencies.

Components (cont…) An interface contains a set of operations which specify a service to a class or a component. The relationship between a component and an interface can be shown in two ways: Canonical form Iconic form

Components (cont…) There are three kinds of components:
Deployment components (Dlls, Exes) Work product components (Source code files) Execution components (COM+ objects)

Components (cont…) UML defines five stereotypes that can be applied to components: executable Specifies a component that may be executed on a node library Specifies a static or dynamic object library table Specifies a component that represents a database table file Specifies a component that represents a document containing code or data document Specifies a component that represents a document

Components (cont…)

Component Diagram Component diagram is used to model the static implementation view of a system. A component diagram contains: Components Interfaces Dependency, generalization, association and realization relationships

Component Diagram - Example

Deployment

Deployment A node is a physical component that exists at runtime.
A node generally comprises of some kind of memory and often processing capabilities. Examples of nodes can be: PC Laptop Router Other embedded systems

Deployment (cont…) Using nodes we can model the architecture of our software system. A node in UML is graphically represented as a cube.

Deployment (cont…) Nodes and Components: Both have names
Both may participate in dependency, generalization and association relationships. Both may be nested Both may have instances Both may participate in interactions

Deployment (cont…) Nodes Vs Components:
Components participate in the execution of a software system, whereas, nodes execute components. Component is a physical package of logical elements like classes, whereas, node physically deploys components.

Deployment (cont…)

Deployment Diagrams A deployment diagram is used to model the static deployment view of software system. A deployment diagram contains: Nodes Dependency and association relationships

Deployment Diagrams (cont…)
Common uses: To model embedded systems To model client/server systems To model fully distributed systems

Deployment Diagrams (cont…)

Forward Engineering

CASE STUDY Vending Machine

Vending Machine

Unified Modeling Language (UML)

Similar presentations

Presentation on theme: "Unified Modeling Language (UML)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Unified Modeling Language (UML)

Similar presentations

Presentation on theme: "Unified Modeling Language (UML)"— Presentation transcript:

Similar presentations

About project

Feedback